[OSM-dev] Advice sought on polygon-with-hole drawing

[Andy Allan]

On Mon, Mar 17, 2008 at 2:28 PM, Andy Robinson (blackadder)
<blackadderajr at googlemail.com> wrote:

>  >Direction is important for one-way roads but shoudn't be for areas.
>  >Coastline is an understandable exception.
>
>  And even that's easy for a user to swap around without realising the affect.

Indeed.

>  In reality though, since it's a wiki, when an error is spotted it gets
>  corrected, so we could take the same view with areas, if it renders the
>  wrong way around its going to get fixed pretty quickly.

Hmm. If there's a 50/50 chance of any car-park doing a planet-span, I
don't think we'll ever see the map again :-)

> A new user is
>  probably going to find it a lot easier to understand that an area has to
>  point in the clockwise direction than to have to add some complicated
>  tagging to non closing areas to render properly, so for this approach I
>  don't feel its too much to ask.

Perhaps more complicated things will require more complicated rules,
but I really think we should avoid requiring direction for
non-directional features as much as possible. Inner/outer sounds much
easier to understand to me than alternating directions, since the
former is an intrinsic feature of the real-world object where the
latter is just a consequence of our data model.

> For closed areas then it will always be
>  possible to overrule if the rendering engine so decides.

Which it'll have to do to avoid planet-spans. So if all renders *must*
ignore way orientation for 3-node areas, then there's no
right-hand-rule for this case at all and any claims to the contrary
are a waste of time and energy to the mappers. Unless we want to be
strict on our inputs (no planet-spanning areas permitted, so no
anti-clockwise 3-node areas) and therefore overcomplicate the API, or
make every editor and bulk-uploader strictly follow the convention, we
may as well let the renders ignore the direction for this case.

Again, perhaps it'll need to be more complicated for the more complex
situations, but I want to nip in the bud any idea that basic areas
must have a clockwise orientation.

Cheers,
Andy

>  Cheers
>
>  Andy
>
>
>
>  >
>  >Cheers,
>  >Andy
>  >
>  >>  It's simple, it's validatable (albeit the current JOSM validator get's
>  >>  it wrong), it means that coastline is not an exception, it makes the
>  >>  maths simpler. It might even mean that you don't need relationships to
>  >>  associate inner and outer -  Any system that gets 1 segment of an area
>  >>  should be able to know which side of that segment the feature is on.
>  >>
>  >>
>  >>  | Also, my idea would allow a way to serve as an "inner" member of one
>  >>  | multipoly at the same time as as an "outer" member of another; I think
>  >>  | you couldn't get that with evenodd.
>  >>
>  >>  That's really ugly. There should be 2 ways. They can share nodes if that
>  >>  ~ is wanted. If you really want to use only one way, then you could put
>  >a
>  >>  direction=-1 tag or something in the relationship that defines the
>  >>  tagging for the inner area, but I still don't like that. I think that if
>  >>  the edge of an area crosses through something you should know what is on
>  >>  each side of it without having to consider special tags for exceptional
>  >>  cases.
>  >>
>  >>
>  >>  Robert (Jamie) Munro
>  >>  -----BEGIN PGP SIGNATURE-----
>  >>  Version: GnuPG v1.4.6 (Darwin)
>  >>  Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>  >>
>  >>  iD8DBQFH2lboz+aYVHdncI0RAgafAKCJBEW2LG9F6Rczm4gp+EU8/8Qt+gCgpMqE
>  >>  M1p5oF0jvynuW31P8KNnu7o=
>  >>  =c5+U
>  >>  -----END PGP SIGNATURE-----
>  >>
>  >>
>  >>
>  >>  _______________________________________________
>  >>  dev mailing list
>  >>  dev at openstreetmap.org
>  >>  http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>  >>
>  >
>  >_______________________________________________
>  >dev mailing list
>  >dev at openstreetmap.org
>  >http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>
>