<div dir="ltr"><div>This provided some output for me:</div><br><div>select st_straightskeleton(ST_Rotate(ST_SnapToGrid(ST_Rotate('POLYGON((256 760,518 760,518 630,674 630,674</div><div>239,673 239,127 239,127 240,126 240,126 513,127 513,127 514,126 514,126</div><div>630,255 630,256 630,256 760),(128 629,128 423,270 423,270 422,271</div><div>422,271 240,672 240,672 629,128 629),(258 759,258 631,516 631,516</div><div>759,258 759),(128 421,128 240,269 240,269 421,128 421))'::geometry, 0.001), 0.001), -0.001));</div><div><br></div><div class="gmail_quote"><div dir="ltr">чт, 18 янв. 2018 г. в 17:44, Stephen Woodbridge <<a href="mailto:woodbri@swoodbridge.com">woodbri@swoodbridge.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1/18/2018 3:54 AM, Martijn Meijers wrote:<br>
> Hi,<br>
><br>
> I think the problem with this input is that there is *a lot* of parallel<br>
> lines, meaning that in the algorithm of skeleton construction many<br>
> things happen at exactly the same time (if you see it as a wavefront<br>
> propagation). I also tried with my Python implementation [1], but this<br>
> also crashes (-:<br>
><br>
> One option I'd try is to slightly perturb/add some randomness to your<br>
> input coordinates (to take away the lines being exactly parallel) and<br>
> see if that goes through...<br>
<br>
This data is generated from a scan of a building floor plan by passing<br>
it through st_dumpaspolygons(rast, 1, true) so it will always have lots<br>
of parallel lines. This is just one of ten similar drawings but its the<br>
only one that fails. I'll be running a larger set today and may have<br>
some additional failures.<br>
<br>
I tried Regina's suggestion of using ST_ApproximateMedialAxis and<br>
ST_SubDivide but that also seems to hang in my work flow. I'll take<br>
another look through my queries to make sure I incorporated it correctly.<br>
<br>
How would you go about perturbing the input coordinates?<br>
<br>
Thanks,<br>
   -Steve<br>
<br>
> Martijn<br>
><br>
><br>
> [1] <a href="https://bitbucket.org/bmmeijers/grassfire/" rel="noreferrer" target="_blank">https://bitbucket.org/bmmeijers/grassfire/</a><br>
><br>
> On 18-01-18 02:21, Stephen Woodbridge wrote:<br>
>> Hi Regina,<br>
>><br>
>> Thanks, this is a great idea. I rework my queries to work in<br>
>> ST_ApproximateMedialAxis and ST_SubDivide and see how that does.<br>
>><br>
>> -Steve<br>
>><br>
>> On 1/17/2018 8:13 PM, Regina Obe wrote:<br>
>>> Steve,<br>
>>><br>
>>> One more thought.  Can you try this and see if it works.  I think<br>
>>> ST_StraightSkeleton and ST_ApproximateMedialAxis are having issues,<br>
>>> because in this case your holes are so big that it almost cuts into<br>
>>> another.<br>
>>><br>
>>> So to work around the issue, you can subdivide the polygon and then<br>
>>> do the analyze like this:<br>
>>><br>
>>> SELECT  ST_ApproximateMedialAxis(ST_SubDivide('POLYGON((256 760,518<br>
>>> 760,518 630,674 630,674<br>
>>> 239,673 239,127 239,127 240,126 240,126 513,127 513,127 514,126 514,126<br>
>>> 630,255 630,256 630,256 760),(128 629,128 423,270 423,270 422,271<br>
>>> 422,271 240,672 240,672 629,128 629),(258 759,258 631,516 631,516<br>
>>> 759,258 759),(128 421,128 240,269 240,269 421,128 421))'::geometry,<br>
>>> 12));<br>
>>><br>
>>> You might need to tweak with the subdivide param.<br>
>>><br>
>>> <a href="http://postgis.net/docs/manual-dev/ST_Subdivide.html" rel="noreferrer" target="_blank">http://postgis.net/docs/manual-dev/ST_Subdivide.html</a><br>
>>><br>
>>> The subdivide cuts right into the holes turning them not into holes<br>
>>> so you end up with simple polygons that approximate medial axis can<br>
>>> handle.<br>
>>><br>
>>> Once you are done you can run ST_Union on your set of Linestrings.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> -----Original Message-----<br>
>>> From: postgis-devel [mailto:<a href="mailto:postgis-devel-bounces@lists.osgeo.org" target="_blank">postgis-devel-bounces@lists.osgeo.org</a>] On<br>
>>> Behalf Of Stephen Woodbridge<br>
>>> Sent: Wednesday, January 17, 2018 2:47 PM<br>
>>> To: PostGIS Development Discussion <<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a>><br>
>>> Subject: [postgis-devel] Problem in st_StriaghtSkeleton - Hangs!<br>
>>><br>
>>> Hi all,<br>
>>><br>
>>> I have run into a problem using st_StraightSkelton() where it appears<br>
>>> to hang at 100 cpu. Maybe an endless loop?<br>
>>><br>
>>> select st_straightskeleton('POLYGON((256 760,518 760,518 630,674 630,674<br>
>>> 239,673 239,127 239,127 240,126 240,126 513,127 513,127 514,126 514,126<br>
>>> 630,255 630,256 630,256 760),(128 629,128 423,270 423,270 422,271<br>
>>> 422,271 240,672 240,672 629,128 629),(258 759,258 631,516 631,516<br>
>>> 759,258 759),(128 421,128 240,269 240,269 421,128 421))'::geometry);<br>
>>><br>
>>> POSTGIS="2.3.3 r15473" GEOS="3.5.1-CAPI-1.9.1 r4246" SFCGAL="1.2.2"<br>
>>> PROJ="Rel. 4.9.2, 08 September 2015" GDAL="GDAL 1.11.3, released<br>
>>> 2015/09/16" LIBXML="2.9.3" LIBJSON="0.11.99" RASTER<br>
>>><br>
>>> Can anyone reproduce this?<br>
>>> Any idea how to work around it?<br>
>>><br>
>>> Is there a non-CGAL version of skeleton?<br>
>>><br>
>>> Thanks,<br>
>>>     -Steve<br>
>>><br>
>>> ---<br>
>>> This email has been checked for viruses by Avast antivirus software.<br>
>>> <a href="https://www.avast.com/antivirus" rel="noreferrer" target="_blank">https://www.avast.com/antivirus</a><br>
>>><br>
>>> _______________________________________________<br>
>>> postgis-devel mailing list<br>
>>> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
>>> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
>>><br>
>>> _______________________________________________<br>
>>> postgis-users mailing list<br>
>>> <a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
>>> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> postgis-users mailing list<br>
>> <a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
>> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a><br>
><br>
> _______________________________________________<br>
> postgis-users mailing list<br>
> <a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a><br>
<br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a></blockquote></div></div>