[OSM-dev] Ponderings about an improved tagging scheme
Andy Robinson (blackadder-lists)
ajrlists at googlemail.com
Fri Feb 20 11:02:38 GMT 2009
Frederik Ramm wrote:
>Sent: 20 February 2009 1:48 AM
>To: Steve Hill
>Cc: dev at openstreetmap.org
>Subject: Re: [OSM-dev] Ponderings about an improved tagging scheme
>Steve Hill wrote:
>>> Your concept is utterly unworkable of course with the current software
>> Would you like to explain why it is utterly unworkable?
>Every single OSM tool treats relations as some "nice to have" extra,
>whereas I understood your concept to make them central. A way would not
>have any meaning by itself but only in the context of a relation. I
>believe this would require a major re-write of many tools to remain
>halfway efficient, thus my verdict of "utterly unworkable with the
>current software landscape".
There is also the point that it has to be easily understandable to
contributors. Relations are only just starting to be understood by a few
dedicated mappers, anything that increases complexity on other objects will
require a very slick editor interface to bury that complexity from the
contributor, especially as I very much hope in the not to distant future we
might seen the emergence of very simple editor functions for adding POI's
and the like by a much wider populace.
>> I'm not sure what you mean by this - Every object on a map is a
>> geometric object, so what are you claiming is the difference between "a
>> geometric object with some properties" and an "object with some
>An object with some properties among which them one is the geometry.
>The difference is about the identity of the object. Our current model
>makes the geometry the identity; a way is defined mainly by its
>geometry, and everything else is secondary. A way, as the central
>meaningful object class in our database, is "a line on the map with some
>In contrast, if you make a relation (or some other object type) your
>central object, then your central object class will become abstract; no
>more will it be something that can be drawn on the map by itself. An
>object would be something like "the M25 between exit 23 and 24", and
>among its many attributes there will be one that specifies the geometry.
>(There need not even be - if you know that the road exists but are
>unable to enter its geometry then you could just leave that empty, just
>as you can today enter a road without knowing its name.)
>But maybe I really misunderstood you and you didn't want to go quite
>> 1. the tagging schemes between relations and other objects are unified.
>> So the tags "type=road, classification=primary", etc. can be applied to
>> either a way, or a relation consisting of ways.
>> 2. the "type" tag can be used to define a context for normal objects,
>> much as it does for relations. So rather than having to understand that
>> a large number of fairly arbitrary tags, such as "highway=road" and
>> "amenity=school" define what the object is, you now only have to know
>> that the "type" tag is going to define what the object is.
>I see. That's much more down-to-earth then.
A type tag was on my original list of tags for Map Features but I dropped it
as superfluous. My only thought since the start for re-instigating it was to
get over the problem of separating a physical description from the non
physical descriptions of an object. But our imperfect system works for now
and I could always rejig the data for my mapped areas to add this separation
when I've got nothing else left to map. For now its just trying to be too
perfect, and would require more time for data entry which is somewhat
counter productive in getting a workable set of data complete.
>I'm not into re-designing the tagging world at all, but I have often
>said that I would like to reach an understanding where a relation can be
>used instead of a way in every context, which bears some similarity with
>what you're saying but doesn't require the strict type stuff. I thought
>that if you had a relation that was tagged "highway=motorway" then this
>should be treated like a way by everyone, with the exception that an
>extra recursion is required to get at the geometry. A route relation as
>we know it today would then be able to have relations as members (in
>addition to ways), and these would be "flattened" for processing.
>Your concept, then, boils down to another old question: Should we have
>the logic be in the software (ah, this one has a highway tag, so it
>probably is a road) or should we have the logic in the database
>(type=highway). We have the same issue with many other things; for
>example say you want to distinguish between different types of water
>bodies. Then you can either tag the full hierarchy like so:
>natural=water, water=lake - or you can do a natural=lake and expect
>everyone to know that lake is a "subclass" of water.
The human brain is quite good at working these things out. I would therefore
hope that this extends to programming written by humans.
>Putting the logic in the database makes processing easier but creates
>room for inconsistency and burdens the database with a lot of
>unnecessary information. Putting the logic in the software makes writing
>software harder and creates the danger of different pieces of software
>working to different specification.
>> Both of these points seem compeltely workable with the current software.
>Yes, sure, but to be honest it now seems to me like an exercise in
More information about the dev