geopoly - rules re data entry

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

geopoly - rules re data entry

Graham Hardman
Hi,

The documentation for the geopoly module states that the vertices must
be defined in a counter-clockwise order so that the interior of the
polygon is on the left of the element as it is drawn.

However, I have discovered that a polygon transformed with geopoly_xform
can result in a polygon having vertices reading clockwise. For instance,
a polygon mirrored about either the x or y axis will produce this
effect. The geopoly module allows these transformed polygons to be added
to the table. If I then create an exact same polygon shape having
counterclockwise order for the vertices and use the geopoly_overlap
function to test it against the one with clockwise order I find the
result = 4, meaning the polygons are regarded as identical.

My question then is, is it really necessary to ensure a counterclockwise
order when a polygon shape is entered for the first time in the table.

regards,

Graham
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: geopoly - rules re data entry

Richard Damon
On 11/17/18 8:37 PM, Graham Hardman wrote:

> Hi,
>
> The documentation for the geopoly module states that the vertices must
> be defined in a counter-clockwise order so that the interior of the
> polygon is on the left of the element as it is drawn.
>
> However, I have discovered that a polygon transformed with geopoly_xform
> can result in a polygon having vertices reading clockwise. For instance,
> a polygon mirrored about either the x or y axis will produce this
> effect. The geopoly module allows these transformed polygons to be added
> to the table. If I then create an exact same polygon shape having
> counterclockwise order for the vertices and use the geopoly_overlap
> function to test it against the one with clockwise order I find the
> result = 4, meaning the polygons are regarded as identical.
>
> My question then is, is it really necessary to ensure a counterclockwise
> order when a polygon shape is entered for the first time in the table.
>
> regards,
>
> Graham
>
My guess would be that SOME operations will need the vertices in the
right order, and others will work regardless of order.

--
Richard Damon

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: geopoly - rules re data entry

Richard Hipp-3
On 11/17/18, Richard Damon <[hidden email]> wrote:
> On 11/17/18 8:37 PM, Graham Hardman wrote:
>>
>> My question then is, is it really necessary to ensure a counterclockwise
>> order when a polygon shape is entered for the first time in the table.
>>
> My guess would be that SOME operations will need the vertices in the
> right order, and others will work regardless of order.
>

Yeah.  For example, the geopoly_area() routine returns a negative
number if the vertexes rotate iCW instead of CCW (which is also a
convenient way to figure out of the order is incorrect).  I'm not sure
what other routines malfunction, but I suspect most of them will.

There is a new routine on trunk (and soon to be in 3.26.0) named
geopoly_ccw() that puts the vertexes in the correct CCW order if they
are not already so.  This routine was added because I discovered that
many legacy GeoJSON files do not follow the rules and put polygon
vertexes in CW order.  I suppose it can also be used after
geopoly_xform() to make sure that the vertexes are in the correct
order there, too.

--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: geopoly - rules re data entry

Graham Hardman
Thanks for the clarification and news of the up-coming additions. This
issue will not impede me for the moment.

Oh, and by the way - the pragma compile_options sql command is still not
including geopoly in the return list. (using 3.25.3)

Graham

On 18-11-2018 3:57 pm, Richard Hipp wrote:

> On 11/17/18, Richard Damon <[hidden email]> wrote:
>> On 11/17/18 8:37 PM, Graham Hardman wrote:
>>>
>>> My question then is, is it really necessary to ensure a
>>> counterclockwise
>>> order when a polygon shape is entered for the first time in the
>>> table.
>>>
>> My guess would be that SOME operations will need the vertices in the
>> right order, and others will work regardless of order.
>>
>
> Yeah.  For example, the geopoly_area() routine returns a negative
> number if the vertexes rotate iCW instead of CCW (which is also a
> convenient way to figure out of the order is incorrect).  I'm not sure
> what other routines malfunction, but I suspect most of them will.
>
> There is a new routine on trunk (and soon to be in 3.26.0) named
> geopoly_ccw() that puts the vertexes in the correct CCW order if they
> are not already so.  This routine was added because I discovered that
> many legacy GeoJSON files do not follow the rules and put polygon
> vertexes in CW order.  I suppose it can also be used after
> geopoly_xform() to make sure that the vertexes are in the correct
> order there, too.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: geopoly - rules re data entry

Richard Hipp-3
On 11/18/18, Graham Hardman <[hidden email]> wrote:
> Thanks for the clarification and news of the up-coming additions. This
> issue will not impede me for the moment.
>
> Oh, and by the way - the pragma compile_options sql command is still not
> including geopoly in the return list. (using 3.25.3)

Please download and try the prerelease snapshot from
https://sqlite.org/download.html as both issues should now be fixed.
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: geopoly - rules re data entry

Thomas Kurz
In reply to this post by Richard Hipp-3
> I discovered that
>many legacy GeoJSON files do not follow the rules and put polygon
>vertexes in CW order.

As far as I know, the Open Geospatial Consortium defines polygons with CCW order (and iCW inner rings) as "seen from top", and an iCW exterior ring (with CCW inner rings) as "seen from bottom".

That might explain the difference (if it's not just wrong by mistake).

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: geopoly - rules re data entry

David Raymond
In reply to this post by Graham Hardman
The general rule is that if you're walking the border in the order that it's given, then your left hand is inside the area, and your right hand is outside. That allows you to define holes, multipolys, etc in the same format without needing extra flags.

Remember that "polygon" is a very loosely used term here. So it's perfectly legit to enter a "poly" as a single line/border in a clockwise direction. That just means that your "poly" is infinite in the plane and has a single hole in it.

So if a mirroring function is just inverting the sign of all the X or Y coordinates and not re-ordering the verticies in each sub-border, then it's a bug. And if it's treating a shape as equivalent to "everything except that shape" then it's also a bug.


(Unrelated note: I know the module is "geo <space> poly" as two words, but I can't help but always pronounce it in a way that rhymes with monopoly. Would anyone be up for a game of Mono Poly?)



-----Original Message-----
From: sqlite-users [mailto:[hidden email]] On Behalf Of Graham Hardman
Sent: Saturday, November 17, 2018 8:37 PM
To: [hidden email]
Subject: [sqlite] geopoly - rules re data entry

Hi,

The documentation for the geopoly module states that the vertices must
be defined in a counter-clockwise order so that the interior of the
polygon is on the left of the element as it is drawn.

However, I have discovered that a polygon transformed with geopoly_xform
can result in a polygon having vertices reading clockwise. For instance,
a polygon mirrored about either the x or y axis will produce this
effect. The geopoly module allows these transformed polygons to be added
to the table. If I then create an exact same polygon shape having
counterclockwise order for the vertices and use the geopoly_overlap
function to test it against the one with clockwise order I find the
result = 4, meaning the polygons are regarded as identical.

My question then is, is it really necessary to ensure a counterclockwise
order when a polygon shape is entered for the first time in the table.

regards,

Graham
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users