[Dachs-support] Spherepoly line segment overlap

Sebastian Walter sebastian.walter at fu-berlin.de
Wed Jan 3 18:03:47 CET 2018


Hi Markus,

Thank you for keeping up with this.

The polygons come unaltered from the data's labels, and are stored in a 
PG database and PostGIS. I made an experiment with the postGIS 
ST_simplify function (a Douglas-Peucker implementation), which reduces 
the coordinates of our example to the following:
160.186005 44.483501 158.231003 44.4636 158.253998 44.465 158.395996 
41.412899 158.539993 36.9044 160.156006 36.912498 160.289993 44.473301 
160.186005 44.483501

Here's what I get out from gavo.utils.pgsphere.SPoly.asPgSphere for this 
simplified geometry:
spoly 
'{(2.7957732029,0.7763835553),(2.7616519811,0.7760362173),(2.7620533195,0.7760606519),(2.7645316522,0.7227914403),(2.7670448739,0.6441032885),(2.7952496215,0.6442446252),(2.7975881358,0.7762055317),(2.7957732029,0.7763835553)}';

But the postgres command (and gavo imp) still fails:
select spoly '{(2.7957732029,0.7763835553), ...
ERROR:  spherepoly_from_array: a line segment overlaps or polygon too large
LINE 1: select spoly '{(2.7957732029,0.7763835553),(2.7616519811,0.7...

The polygon now looks pretty nice in the (attached) screenshot.

Thanks!

Sebastian



On 01/03/2018 04:35 PM, Markus Demleitner wrote:
> Hi Sebastian,
> 
> On Wed, Jan 03, 2018 at 02:07:51PM +0100, Sebastian Walter wrote:
>> Your method works well but now I come across several erroneous import lines,
>> the first few of which I'm happy to post here (as preferred, in the -D
>> format).
>> I manually checked the first one only (granule_uid h3211_0000.nd3.07) and
>> the geometry seems to be "valid" (also no pole). Please see attachments.
> 
> Hm -- looking at the first polygon I'd say that pgsphere is right
> (within its limits; you could of course argue that pgsphere should be
> able to deal with this kind of thing).
> 
> I've made a plot of the segments with arrowheads for clarity
> (attached as PDF), and you can see that at least two segments are
> odd.  I've not tried to identify the bad spots, but I'll add that
> it's not just pgsphere that coughs with this polygon specification --
> HEALPix's query_polygon method coughs with it as well.  And HEALPix
> is the basis of MOCs, which you don't want to miss out on :-)
> 
> Where do these Polygons come from?  I suspect just throwing out
> points that are too close to each other might make them palatable to
> pgsphere.
> 
> Incidentally, if you want to experiment outside of DaCHS, here's what
> you could say to get a pgsphere literal for a list of x,y...
> coordinates in degrees:
>    
>    #!/usr/bin/python
> 
>    coos = "160.186005 44.483501 158.231003 44.4636 158.253998 44.465..."
>    from gavo.utils import pgsphere
>    poly = SPoly.fromDALI([float(s) for s in coos.split()])
>    print poly.asPgSphere()
> 
> The result will be something like
> 
>    spoly '{(2.7957732029,0.7763835553),(2.7616519811,0.7760362173),...
> 
> and you can directly say something like
> 
> # select spoly '{(2.7957732029,0.7763835553),(2.7616519811,0.7760362173),(2.7620533195,0.7760606519)}':
> 
> on the postgres command line to figure out if the polygon has come
> out good (you'll get an error message if not).  This one, made up of
> the first three points of your polygon, incidentally, is good.
> 
>           -- Markus
> 
> 
> 
> _______________________________________________
> Dachs-support mailing list
> Dachs-support at g-vo.org
> http://lists.g-vo.org/cgi-bin/mailman/listinfo/dachs-support
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2018-01-03 17-56-27.png
Type: image/png
Size: 5152 bytes
Desc: not available
URL: <http://lists.g-vo.org/pipermail/dachs-support/attachments/20180103/d3eb4389/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5427 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.g-vo.org/pipermail/dachs-support/attachments/20180103/d3eb4389/attachment-0002.bin>


More information about the Dachs-support mailing list