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... _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
