<div>Frederik and all,</div>
<div> </div>
<div>Is there now a distinct description on the OSM Wiki, how polygons are defined in OSM? (e.g. self-intersections allowed? inner holes?) </div>
<div> </div>
<div>And: Outer boundaries seem to be encoded simply by the fact that first and last point have the same coordinates(?). But how are inner boundaries 'officially' encoded?</div>
<div> </div>
<div>-- S.<br></div>
<div class="gmail_quote">2008/3/17 Andy Robinson (blackadder) <<a href="mailto:blackadderajr@googlemail.com" target="_blank">blackadderajr@googlemail.com</a>>:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Andy Allan [mailto:<a href="mailto:gravitystorm@gmail.com" target="_blank">gravitystorm@gmail.com</a>]<br>
>Sent: 17 March 2008 4:20 PM<br>>To: Andy Robinson (blackadder)<br>>Cc: Robert (Jamie) Munro; dev<br>
<div>>Subject: Re: [OSM-dev] Advice sought on polygon-with-hole drawing<br>><br></div>
<div>>On Mon, Mar 17, 2008 at 2:28 PM, Andy Robinson (blackadder)<br>><<a href="mailto:blackadderajr@googlemail.com" target="_blank">blackadderajr@googlemail.com</a>> wrote:<br>><br>>> >Direction is important for one-way roads but shoudn't be for areas.<br>
>> >Coastline is an understandable exception.<br>>><br>>> And even that's easy for a user to swap around without realising the<br>>affect.<br>><br>>Indeed.<br>><br>>> In reality though, since it's a wiki, when an error is spotted it gets<br>
>> corrected, so we could take the same view with areas, if it renders the<br>>> wrong way around its going to get fixed pretty quickly.<br>><br>>Hmm. If there's a 50/50 chance of any car-park doing a planet-span, I<br>
>don't think we'll ever see the map again :-)<br>><br><br></div>I see your concern.<br>
<div><br>>> A new user is<br>>> probably going to find it a lot easier to understand that an area has to<br>>> point in the clockwise direction than to have to add some complicated<br>>> tagging to non closing areas to render properly, so for this approach I<br>
>> don't feel its too much to ask.<br>><br>>Perhaps more complicated things will require more complicated rules,<br>>but I really think we should avoid requiring direction for<br>>non-directional features as much as possible. Inner/outer sounds much<br>
>easier to understand to me than alternating directions, since the<br>>former is an intrinsic feature of the real-world object where the<br>>latter is just a consequence of our data model.<br>><br>>> For closed areas then it will always be<br>
>> possible to overrule if the rendering engine so decides.<br>><br>>Which it'll have to do to avoid planet-spans. So if all renders *must*<br>>ignore way orientation for 3-node areas, then there's no<br>
>right-hand-rule for this case at all and any claims to the contrary<br>>are a waste of time and energy to the mappers. Unless we want to be<br>>strict on our inputs (no planet-spanning areas permitted, so no<br>
>anti-clockwise 3-node areas) and therefore overcomplicate the API, or<br>>make every editor and bulk-uploader strictly follow the convention, we<br>>may as well let the renders ignore the direction for this case.<br>
><br>>Again, perhaps it'll need to be more complicated for the more complex<br>>situations, but I want to nip in the bud any idea that basic areas<br>>must have a clockwise orientation.<br>><br><br></div>
Agreed. I was more concerned with opening the ability to render more complex<br>and larger areas like we deal with coastlines, but you are right, they<br>should be special cases rather than the norm.<br>
<div>
<div></div>
<div><br>Cheers Andy<br><br>>Cheers,<br>>Andy<br>><br>>> Cheers<br>>><br>>> Andy<br>>><br>>><br>>><br>>> ><br>>> >Cheers,<br>>> >Andy<br>>> ><br>
>> >> It's simple, it's validatable (albeit the current JOSM validator<br>>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<br>
>to<br>>> >> associate inner and outer - Any system that gets 1 segment of an<br>>area<br>>> >> should be able to know which side of that segment the feature is on.<br>>> >><br>
>> >><br>>> >> | Also, my idea would allow a way to serve as an "inner" member of<br>>one<br>>> >> | multipoly at the same time as as an "outer" member of another; I<br>
>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<br>>that<br>>> >> ~ is wanted. If you really want to use only one way, then you could<br>
>put<br>>> >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<br>>that if<br>
>> >> the edge of an area crosses through something you should know what<br>>is on<br>>> >> each side of it without having to consider special tags for<br>>exceptional<br>>> >> cases.<br>
>> >><br>>> >><br>>> >> Robert (Jamie) Munro<br>>> >> -----BEGIN PGP SIGNATURE-----<br>>> >> Version: GnuPG v1.4.6 (Darwin)<br>>> >> Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org</a><br>
>> >><br>>> >> iD8DBQFH2lboz+aYVHdncI0RAgafAKCJBEW2LG9F6Rczm4gp+EU8/8Qt+gCgpMqE<br>>> >> M1p5oF0jvynuW31P8KNnu7o=<br>>> >> =c5+U<br>>> >> -----END PGP SIGNATURE-----<br>
>> >><br>>> >><br>>> >><br>>> >> _______________________________________________<br>>> >> dev mailing list<br>>> >> <a href="mailto:dev@openstreetmap.org" target="_blank">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>>> >><br>>> ><br>>> >_______________________________________________<br>
>> >dev mailing list<br>>> ><a href="mailto:dev@openstreetmap.org" target="_blank">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>
>><br>>><br><br><br>_______________________________________________<br>dev mailing list<br><a href="mailto:dev@openstreetmap.org" target="_blank">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>