Re: [sqlite] geopoly - rules re data entry

2018-11-19 Thread David Raymond
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  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:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Graham Hardman
Sent: Saturday, November 17, 2018 8:37 PM
To: sqlite-users@mailinglists.sqlite.org
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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] geopoly - rules re data entry

2018-11-18 Thread Thomas Kurz
> 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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] geopoly - rules re data entry

2018-11-18 Thread Richard Hipp
On 11/18/18, Graham Hardman  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
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] geopoly - rules re data entry

2018-11-17 Thread 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  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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] geopoly - rules re data entry

2018-11-17 Thread Richard Hipp
On 11/17/18, Richard Damon  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
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] geopoly - rules re data entry

2018-11-17 Thread 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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


[sqlite] geopoly - rules re data entry

2018-11-17 Thread 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
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users