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

Stefan Keller sfkeller at gmail.com
Fri May 2 20:26:15 BST 2008


Frederik and all,

Is there now a distinct description on the OSM Wiki, how polygons are
defined in OSM? (e.g. self-intersections allowed? inner holes?)

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?

-- S.
2008/3/17 Andy Robinson (blackadder) <blackadderajr at googlemail.com>:

> Andy Allan [mailto:gravitystorm at gmail.com]
> >Sent: 17 March 2008 4:20 PM
> >To: Andy Robinson (blackadder)
> >Cc: Robert (Jamie) Munro; dev
> >Subject: Re: [OSM-dev] Advice sought on polygon-with-hole drawing
> >
> >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 :-)
> >
>
> I see your concern.
>
> >> 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.
> >
>
> Agreed. I was more concerned with opening the ability to render more
> complex
> and larger areas like we deal with coastlines, but you are right, they
> should be special cases rather than the norm.
>
> Cheers Andy
>
> >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
> >>
> >>
>
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080502/6231fc6f/attachment.html>


More information about the dev mailing list