[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