[OSM-dev] Ponderings about an improved tagging scheme
frederik at remote.org
Fri Feb 20 01:48:16 GMT 2009
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".
> 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.
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.
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
Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
More information about the dev