[OSM-dev] Restrict key names on order to retain reusability of OSM

Andy Robinson (blackadder) blackadderajr at googlemail.com
Fri Feb 15 09:57:25 GMT 2008

Stefan Keller wrote:
>Sent: 15 February 2008 8:32 AM
>To: Jochen Topf
>Cc: dev at openstreetmap.org
>Subject: Re: [OSM-dev] Restrict key names on order to retain reusability of
>Look: It seems to be debate about unstructured, semi-structured and
>structured data. What you're celebrating is something around semi-
>structured data.
>Marcus reminded my that OSM allows for a building to be more than just a
>shop, but a gas-station a fuel-station, lit, car-wash, etc. That's right,
>but keep in mind, that I *don't* propose to change the current internal OSM
>schema and I *won't* restrict the number of key on your side. I propose
>only to restict the character set of keys. I'm showing a use case where
>parts of the OSM data gets out into a usual application environment and I
>hope OSM was'nt meant to stick in it's free but "closed world".
>So let's say for my application I'm happy with one attribute (type="shop")
>or two. You know that in a more application oriented environment you do
>stick to a schema with a distinct number of attributes and take care of
>each of them.
>Having said that, if you want multivalued attributes and lossless data
>exchange there are many possibilities in my example schema to either sync'
>back based on the ID or store all the additional key/values you may receive
>from the users (e.g. in a attribute). This again to the prize that there is
>no usable index in the application schema (except for the ).
>Rob wrote:
>> You use building=shop in your examples but there is absolutely nothing
>> to stop someone using (apologies in advance for my lack of language
>> skills) construcción=almacén or ??????=?????.
>Good example: How to make a map of more than one country when you an me
>can't interpret "construcción" and "??????" being buildings?

It's probably worth pointing out that the OSM project is principally not a
map project, it’s a project to collect geodata. Producing maps is the most
logical output (street maps obviously for instance) but some of the things I
put into OSM I'm not expecting to see on a conventional map.

We all know we can make life easier for those using the OSM data if its
structured and follows a rule book but this is unnecessarily restrictive for
community contributors who don’t want to follow a rule book (or can't easily
do so) from contributing. It’s the community contributors that are vital to
OSM's success, not those that display or use map data. Plenty will argue the
old adage of rubbish in rubbish out but that’s not really valid here because
it is possible to make use of even the most obscure information that is
contained within the database. Accepted that some of it might not be easily
machine readable for display on a map or in a navigation device, but so long
as someone understands it and finds it useful then it has value.

The reality is that the vast majority of the data has a loose structure that
works. The bulk of the data can be used easily and produces great maps if
that’s what your interest is. Beyond that the world is your oyster and so
any form of restriction isn't a benefit. Our argument is a philosophical
rather than technical one. Anything that makes it more restrictive for
contributors to add data is always going to be voted down. Find an argument
that has positive benefits to data contributors for any language, age group
and walk of life etc around the globe and you will find sympathetic support.



More information about the dev mailing list