Henry Loenwind wrote: > 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 ;)
I think you brought up some valid points. The echo so far proves that you touched regions "for the experts only"[TM], nothing the average mapper feels able to discuss. But nevertheless it has to be discussed. > 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".) As Frederik pointed out: Why in general are split ways bad? No matter how you turn it around, a way will always be split at a certain level. As an example: A primary street running from village A to B might change its name somewhere in the middle, but using the same reference number. And each part of the named street has two different maxspeeds (inside the village and outside). With the current model, we have four ways. Using relations, one could group each two ways with the same name to be "one named street". From the data models perspective, this sounds preferable. But what is gained with this approach? The current tools force mappers to think in internal data structures. But that's because the tools do not comfortably, automagically create relations based on user input. There are two ways with a shared node and the same name? Then make the name a relation. Of course this could be done internally in the API, transparently, just to optimize data storage or whatever this is good for, and me might end up having two different API modes, one with relations, and one without (all tags within relations mapped as attributes to every single way), or the API data model becomes more and more obscured by the editing tools, because it simply does not help mappers to be forced to think about all the internal stuff. The point is: If the development goes away from presenting ways and relations to the mapper, then it becomes less and less relevant to the mapper to worry about how it is all stored in the "data blackbox". > 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. While I don't see the point with splitting ways, here you have a valid point - but let me state the problem I see a bit different. I don't like the method of current "oneway street" tagging, because it interferes with other street tagging relying on the direction of the street. This somehow relates to your suggestion: > <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"/> > > ... > <tag k="highway" v="bus_stop" from="P1" to="P1" side="left"/> > <tag k="highway" v="bus_stop" from="P2" to="P2" side="right"/> > ... The problem I see is not where streets are actually tagged as oneway streets - it's all streets without them that make the problem. Because if a oneway street is accidentially reversed, this error will eventually be noticed and corrected. But every normal street might be reversed without any noticable impact as of today. But there is a need to tag not just the direction of the main traffic component of the street (e.g. motorized, fast, four-wheeled), but to add facilities for "the others": pedestrians, cyclists and so on. Using current tagging, you would be able to add a tag "both sides of this street have a cycleway". And this might be rendered as a blue (or blue dotted, to mimik the pure cycleway) border on the street. How do I tag that only one side of the street has a cycleway or a sidewalk/pavement. I could use "cycleway=left", but where is "left". It has to depend on the direction of the way (although I don't really like this directional word for this task, there should be some other way to encode this fact). But the direction is directly connected with the oneway tag, and I really doubt that the editors, which until now have an easy task reversing a way, will be able to consider and adjust all tags connected with the direction of the way. I'd suggest to let the original creator of a way define its direction, and then to never touch it again. Every tagging which relies on the ways direction can either be along it's direction, or against it. All current oneway streets would be "oneway=1" or "oneway=yes". This would be extended to "onway=-1" for new oneway streets which run agains the new ways direction. If a mapper has to change the direction of the oneway street, he will only change the oneway tag - not the way, avoiding to mess with any other directional tagging which might be invented in the future. If the direction of a way cannot be changed, every additional tagging (cycleways, bus stations, maxspeeds and so on) can rely on this information to be eternal. If it really has to be changed, there's always the option to create a new way, deleting the old one, and apropriately move the tagging from the old to the new way. I'd think that this suggestion has a much smaller impact on the current database, because it could be implemented ad hoc through a generel agreement not to use the "reverse way" features currently available in the editors, eventually removing them and enforcing the "no reverse" rule in the API (there will always be mappers who "mess" with the data unintentionally, that's normal OSM business). Useful tagging schemes would be created almost instantly, I think. Disclaimer: ;) I hope I explained my point as precise as I could, but I apologize if I upset anyone by making any words to harsh or by ignoring any gentleman behaviour - it is unintentional, English is not my native language. Regards, Sven _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
