[OSM-dev] Ponderings about an improved tagging scheme

[Frederik Ramm]

Hi,

Steve Hill wrote:
>> Your concept is utterly unworkable of course with the current software 
>> landscape,
> 
> 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 
> properties"?

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 
attributes added".

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 
that far.

> 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 
cosmetics ;-)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"