2012/5/23 Martin Koppenhoefer <dieterdre...@gmail.com>: > 2012/5/23 Martin Vonwald <imagic....@gmail.com>: >>> So I end up with 4 ways (highway, 2 sidewalks, cyclelane), one >>> relation (area) and some nodes (lowered kerbs). Of course this is more >>> complex, but you also get a whole lot more of detail, >> I see it the other way around: the increase in complexity does not >> justify the increase in detail. > I fail to understand this sentence. Did you mean it the other way > round? (increase in detail does not justify the increasing > complexity?)
double complexityIncrease=newComplexity/oldComplexity-1.0; double detailIncrease=newDetail/oldDetail-1.0; boolean notGoodIdea=(complexityIncrease > detailIncrease); Better? ;-) >>> especially if >>> there is more stuff to take into account (geometry not perfectly >>> parallel, barriers which are (partially) between the sidewalk and the >>> road, ability to map barriers on the sidewalk only, etc. >> If one would allow to change the width of the xway-parts, you could >> map geometry that is not perfectly parallel. > what exactly are these xways? How would they end up in the database? > Is it another osm-feature (besides ways, nodes, rels), or is it a way > with special tags? How do they relate to current ways? Yes, I do think about them as new feature. And yes, before you start: I know it is completely unrealistic. I just wanted to state how I think that it could(!) work. Maybe it is possible to simulate their properties with existing features, but I'm afraid it would be too fragile. >>>> If I >>>> want to move the "street" I have to move seven ways. >>> why would you want to move a street that you have surveyed up to this >>> level of detail? I think this is hypothetical (and btw: it is 6 in >>> your example). >> >> Japan moved a few meters not so long ago. > this won't be a problem and you know this: simply move the whole of > Japan, as it is an island this is trivial (if the movement is the same > everywhere). Your question was "why would you want to move a street...?". This was one answer out of approx. 1.2 quadrillions possible. Once again: Facts changes! >>>> If I want to add >>>> a junction I have to add a node to every way. >>> Yes, (see above, really not likely that you map a street with 5 ways >>> in every detail and then you discover that you "forgot" a whole >>> junction). >> I didn't forget the junction - it was just built. Facts changes! > > I don't see what is the particular problem (whether you have to > integrate something later or map it from scratch), see below: > > >>> Of course the junction will be more complex to map compared >>> to a simple node, but this is also one of the reasons you are doing >>> it: to get more details how the junction looks like. >>>> If the connecting road >>>> is also represented by seven ways I would have to connect... no, I >>>> don't count now... a lot of ways. >>> actually you would have to connect only those ways that are >>> intersecting in reality, not all of them (see above). >> >> I know, but this is still "a lot" compared to "one". > Well, won't those parallels in your "xway" somehow have to be > connected or not as well? How do they magically intersect? Magically they don't. At least I don't know how they could. The connection of those "parts" would be the same effort as with the area-relation (more or less). >>>> Now I want to add a route relation for a bicycle route. For this I >>>> have to split the "street". >>> not at all, you will have the cyclelane where you put the relation to >>> and you will _not_ have to split the street. >> Then I misunderstood the proposal. That would be good. > I have to apologize for the current state of this proposal, it really > isn't documented very well and I wouldn't even be astonished to find > some contradictions in it. Definitely needs some illustrations and > examples as well. I could have read more carefully. But illustrations are never a bad idea. >> The way I think about it, it would be quite simple: just draw the >> ways/lanes/barriers/whatever as they are, but they magically glue >> together and the width of each part is automatically determined. Don't >> ask me about details! I figured this out just a few hours ago. > you will at some point have to tell the editor/database/dataconsumer > which lanes and barriers and stuff belong together. I don't yet > understand how you would achieve this, as you seem to refuse to use a > relation for this. It is not possible to do it just spatially (at > least not in some cases). The xway consist of "parts" (think of them as lanes or similar), therefore the parts belong to the xway. It's just the same as a lot of ways and the area-relation, but without an explicit relation and with improved handling of the "parts". BTW: You seem to have missed my main objection: >> You will not map every street with this detail I guess, but you could >> do it for situations that are complex in the real world. > See - that's the main problem of this approach. It is much too complex > for the common situations, so we should only use it in complex > situations. And this will lead to a continuous switch between this > approach and "standard" mapping. Imagine that: every now and then a > simple road, specified by one way with some tags, magically changes to > four, five, (how many was it) ways and a relation and just a few > meters further collapses back to a single way. Do you think, that this > is understandable? Maintainable? Once more: I think, that it would be possible to simulate this "xway-feature" with the current available features, but you would need strong editor support that hides a lot of the complexity. As long as (just my favorite example) you have to move <x> ways to move a street by a few meters, this will no succeed. At least in my opinion. But I would be happy if you prove me wrong :-) cheers, Martin _______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
