|
How do fundamental changes to OpenStreetMap's underlying data model work? How are these proposed, discussed, and decided on? What sort of things are important to consider throughout this process? I am a researcher at a university. My group has a potentially very large grant coming in, with an interest in making housing data publicly available in a consistent way across the US (and ideally, the world). For example, how would we go about discussing with the OpenStreetMap community the possibility of -- and pros and cons of -- creating fields in the OSM database to store data about residential parcels (such as appraised value, last sale date, sale price etc) and buildings (such as number of bedrooms or bathrooms, number of units, rent, etc). We can assume extremely generous funding for this project and ongoing updates to the data on an ongoing basis. What is the process for this kind of proposal and conversation? What are the key concerns or issues involved? Is this sort of housing data appropriate for the OSM project and mission? |
|
First, it looks like you are not asking for a change of the data model, just for some additional tags. The change of the data model would be very difficult, adding some tags is easier. Generally there is no one process to make decisions about new tags. Most tags are simply added, hopefully after some (informal) discussions with knowledgeable mappers who can give advice. Then there is the question of what belongs in OSM and what doesn't. There are no hard and fast rules here, but some guidelines. An obvious one is "general usability": Is this something that is generally useful (almost everybody drives down roads) or something very specialized only for a very limited audience (I would expect your project to fall somewhere in the middle, but leaning towards specialized). One very important one is "verifyability": Can somebody who stands in the world somewhere verify that the data mapped there is correct. For a road this is obvious. Your project falls through here. You data is coming from somewhere else and no check is possible for the average mapper. This has a flip side: Your data is, I assume, coming from some authoritative source and it makes sense to have the checks and the uniformity of data guaranteed by that source. You don't want any random Joe to change the house prices. But in OSM that is possible. So why do you want this information in OSM when you already have a source that is (probably) updated systematically? This is the most important issue here. What do you expect some bringing this data into OSM where you have to keep it updated in a cumbersome process when you can easily keep the data outside and combining it with the OSM data as needed. There is always the problem of conflation, of matching your data to OSM data. This process is always messy, but it isn't worse when combining the data every time you use it compared to one on import and then everytime the data source is updated. Find a way to combine the two data sources automatically upon use and everybody will be happier. In developed countries this can usually be done relatively easily using addresses. If OSM is missing address data, help completing that and you have something to match against. 4
Just as a further point: adding a number of the details that were mentioned is going to be a non-starter in many many countries for legal reasons (privacy etc), Naturally that applies equally to all possible platfomrs.
(11 Jul '17, 08:15)
SimonPoole ♦
|
