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>>>>