[OSM-dev] Ponderings about an improved tagging scheme

G H S tiosancho at hotmail.com
Fri Feb 20 09:24:55 GMT 2009

Hi Jochen.

> Objekts in the real world can't neatly be categorized into types. The
> world is much more complicated than this. So OSM has a different
> approach: We just have attributes of objects called tags. Tags tell you
> *something about* an object, but they don't tell you what it *is*.
> Or, if you want to, you can see it this way: The sum of all the tags on
> an object is the type.

Well, I'm not sure that the kind of objects found on a map can't be categorized by a sufficiently flexible system.  Given the name OpenStreetMap, I'd think there's a finite collection of object types that make sense here.  That collection will have to grow over time, certainly, but we can be smart about classifying objects without imposing a daunting workload on the mapper.  Objects that are deemed "unclassifiable" can rely on the free-form tags.

Plus, the current system seems to be aiming for more organization than just a free-form collection of tags.  Otherwise, wouldn't we just have an attribute called "tags", followed by a delimited series of values?

If we have [attribute]=[value], I'd expect to see a defined collection of attributes somewhere.  As it stands, we seem to have [value]=[some other value].  What constrains the left term, as opposed to the right term?

How about an orderly collection of attributes (which would cover most of what's going on now with things like "highway=" or "natural=") WITH the option of a free-form "tags" attribute for object types and attributes that fall through the cracks?

Given that a major goal of this project is to create a repository of data that are machine-readable and -filterable, wouldn't consistency in tagging help quite a bit?

Windows Live™: E-mail. Chat. Share. Get more ways to connect. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20090220/e9ea2bb2/attachment.html>

More information about the dev mailing list