<br><div class="gmail_quote">On Fri, Mar 14, 2008 at 11:39 AM, bvh <<a href="mailto:bvh-osm@irule.be">bvh-osm@irule.be</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Fri, Mar 14, 2008 at 10:43:54AM +0000, Robert (Jamie) Munro wrote:<br>
> Yes. That is what I am saying. 1 simple rule:<br>
><br>
> *All* areas should be colour on the right (i.e. clockwise)<br>
><br>
> It's simple, it's validatable (albeit the current JOSM validator get's<br>
> it wrong), it means that coastline is not an exception, it makes the<br>
> maths simpler. It might even mean that you don't need relationships to<br>
> associate inner and outer -  Any system that gets 1 segment of an area<br>
> should be able to know which side of that segment the feature is on.<br>
><br>
> | Also, my idea would allow a way to serve as an "inner" member of one<br>
> | multipoly at the same time as as an "outer" member of another; I think<br>
> | you couldn't get that with evenodd.<br>
><br>
> That's really ugly. There should be 2 ways. They can share nodes if that<br>
> ~ is wanted. If you really want to use only one way, then you could put a<br>
> direction=-1 tag or something in the relationship that defines the<br>
> tagging for the inner area, but I still don't like that. I think that if<br>
> the edge of an area crosses through something you should know what is on<br>
> each side of it without having to consider special tags for exceptional<br>
> cases.<br>
<br>
</div>I disagree. Requiring mappers to add two ways that overlap<br>
completly is with the goal of making the math simpler is<br>
shifting the burden from software to users.<br>
</blockquote><div><br>Sometimes this is unavoidable.  Consider a commercial area (landuse=commercial) surrounded by a residential area (landuse=residential).  It's not possible to create a single way that can be used as the boundary for both these features as they would both need to specify different values for the landuse tag.<br>
<br>This raises a whole other issue about using the same path for multiple purposes (for example, highway=primary and railway=tram).  This works fine at first sight, until you consider secondary tags like name.  If you wanted to mark the name of the highway as Powell Street, and the name of the tram as the Powell-Mason Line, you'd have a problem.<br>
<br>Given that almost everything could potentially have a name tag it seems short-sighted to try to use a single way to describe two different features, even when they share exactly the same path.  Note, this is not the same as two ways sharing the same *nodes*. This should be encouraged.<br>
 <br>80n<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Could you elaborate on your last sentence? What problem can we<br>
now not solve because it is more difficult to find out at<br>
which edge a feature lies? Maybe there are others to achieve it?<br>
<br>
cu bart<br>
<div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev" target="_blank">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev</a><br>
</div></div></blockquote></div><br>