[OSM-talk] API v7

[Henry Loenwind]

Hi,

first, the following are some half-baked ideas I just want to get out of 
my head because I need the space they are taking up ;)


Over the last weeks I have seen many discussions about how to tag some 
stuff. Sometimes the solution was easy, but many times there just was no 
solution at all. And more often than not, someone would pull some 
giganto relation out of the hat, that would mean that we would have more 
relations than ways at the end. I wanted to add to those discussions, 
but I also often did not find a good solution.

Then it struck me. We are clinging to our current data model really 
hard. Too hard. Maybe we need to start exploring how to extend it to 
make mapping easier, instead of trying to put everything ways and nodes 
cannot do into relations? (I said "start exploring", emphasis on that!)

Reoccurring problem 1: Way splitting. At the moment we need split ways 
at every point there is some change to them. While this is much better 
than segments were, recombining them with relations just demotes ways to 
segments and makes relations our new ways. Nothing gained. Going the 
opposite way, by not splitting the ways and giving parts of them 
different properties with relations is not much better---there is no 
support for including parts of a way in a relation, so the relations 
will contain one way and (hopefully) two nodes an some obscure meaning 
how to cut the way. (Note: "obscure" meaning "not in the data model".)

Reoccurring problem 2: Two side of a coin, oops, a way. Most ways have 
two sides, often they are the same, but also often they are not. 
Different maximum speeds, or different access rules, sometimes even 
different highway types (highway=residential, oneway=yes on one side, 
highway=cycleway the other). No clean way to model this, too. There are 
some tags for common cases, like cycleway=opposite, but that's all.


So far for the problems. Please discuss my view on the problems (above) 
independently from my ideas on solving them (below). Mixing discussions 
on problem and solution usually lead to nothing.


At the moment a way can only be tagged as a whole. There is no way to 
say that a tag only applies to the left side of the street, or to the 
second half. There are some proposals for the former, like 
"right:maxspeed=30" or "maxspeed.left.hgv.atnight=25". One of them may 
be the correct way to go, but my idea includes another solution "for free".

With API.5, a way looks like this:

<way id="35" ...>
   <nd ref="1"/>
   <nd ref="22"/>
   <nd ref="333"/>
   <nd ref="4444"/>
   <tag k="highway" v="secondary"/>
</way>

Let's see how it changes with some additions:

<way id="35" ...>
   <nd ref="1"/>
   <nd ref="22" p="P1"/>
   <nd ref="333" p="P2"/>
   <nd ref="4444"/>
...

Not much yet, I only added a free-text field to th nd-element, "p" for 
"position". It would be optional and only constrained that it must be 
unique within the way.

Now add 2 more attributes to the tag-element:

...
   <tag k="highway" v="secondary"/>
   <tag k="bridge" v="yes" from="P1" to="P2"/>
</way>

Whow, we just added a bridge without cutting the way into 3 parts. Neat, 
but not quite where I'm headed. One more:

...
   <tag k="bridge" v="yes" from="P1" to="P2" side="both"/>
   <tag k="maxspeed" v="30" from="P1" to="P2" side="left"/>
   <tag k="maxspeed" v="50" from="P2" to="P1" side="right"/>
</way>

Now, there is one little bit of information hidden here. Try to find 
out: Is this street in the UK or on mainland Europe?

Ok, there's no way to find out, as there are more countries driving on 
the left side than just the UK. But this street would be in one of them. 
Why? Easy, the tags now have a direction (from, to), together with the 
side (that is relative to the way's direction), we can say that e.g. the 
maxspeed=30 part is on the left side of the way going in the direction 
of the way.

(Some notes: (1) "both" would be the default for "side" when no value 
was given. (2) "side/from/to" may of course be abrv., e.g. to s/f/t. 
Maybe even "both/left/right" (b/l/r?))

So, this would allow us to (a) tag parts of a way diffeently, (b) tag 
the two directions of a way differently, and (c) tag the two sides of a 
way differently. (Yes, there is a difference between b and c, and it is 
important.) But there is still more: (d) we can now also tag nodes on a 
way with a direction:

...
   <tag k="highway" v="bus_stop" from="P1" to="P1" side="left"/>
   <tag k="highway" v="bus_stop" from="P2" to="P2" side="right"/>
...

However, to fully use this feature, we would have to abandon the generic 
"name" tag. Or else there would be just no way to know what the name is 
for---the way or something tagged to a part of the way? However, there 
should not be that many features that can be tagged additionally onto a 
way in a useful and meaningful manner. Things that have their own way or 
node at the moment should keep it. Only some node features, like bus 
stops or traffic lights or gates, are really part of the way they belong 
to and would better be expressed that way instead of as extra nodes. 
Others, like lamp posts or subway entrances,---even though they re on 
the sidewalk (that is part of the road)---are better mapped as 
independent nodes. But I think, we can leave the details of this for the 
future.


Let's have a quick look at some of the possible problems with this approach:

Q: What happens if a new node is inserted?

A: Nothing. The node will just be there, no disturbance, as the parts of 
the way are still addressed by the "named" nodes. Add as many node into 
the middle of the example above as you like, it won't hurt.

Q: What happens if a node with a p-tag is deleted?

A: The API would reject the upload while the p-tag's value is still in 
use by some tags. Same as if you try to delete a node that s still used 
by a way.

Q: How shall renderers handle ways with different highway tags for the 
two sides?

A: They may just bark, and ignore highway tags that have a side or 
from/to tags. Or they may do the clever thing and switch from rendering 
whole streets to half streets. That is, to paint each side of the street 
independently all the time.

Q: What about a way with overlapping tags, e.g. one that is secondary 
for the whole length and primary from A to B? (or worse: secondary from 
A to C and primary from B to D, with nodes in the order ABCD)

A: Should be handled the same as ways that are tagged 
"highway=primary;secondary" at the moment. That is, you may enter that 
kind of data, but no data consuming software will recognize it. (and 
hopefully your editor will warn you about it)

Q: Is the p-tag really needed? Couldn't from and to just give the number 
of the node in the way?

A: They cold, but then you way would break if someone inserted a new 
node. And break badly. And I'd hate to put the burden to prevent 
breakage onto the editors. BTW: The editors should abstract the p-tag 
away from the user some day, of course.

Q: Implementation or we're not interested.

A: Sure, give me a SVN account and I'll change the server software. I'd 
also need an admin account for the main server. And YOU'LL take the 
blame that starting next week not a single client will be able to talk 
to the server, won't you?

Q: Was the last answer fair to all who spent much of their free time 
contributing to OSM?

A: Was the last question fair to me? I also spent time on OSM, and not 
just writing on some mailing list but also mapping, writing software, 
and tutoring at workshops. So I have the same right to post my ideas and 
opinions here as anybody else. And if someone finds my ideas rubbish, 
they are entitled to their opinion, too. So what? We are no closed 
gentleman's club, that only accept people with the same opinions and 
perfect manners...

cu
Henry

PS: The last two Q/A pairs were a shot into the dark, but I really have 
the feeling (call it experience) they would have come up on their own...