[GEOS] #1054: BuildArea behavior changed intentional? and when did it happen

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[GEOS] #1054: BuildArea behavior changed intentional? and when did it happen

geos-2
#1054: BuildArea behavior changed intentional? and when did it happen
------------------------+--------------------------
 Reporter:  robe        |      Owner:  geos-devel@…
     Type:  defect      |     Status:  new
 Priority:  major       |  Milestone:
Component:  Default     |    Version:  3.6.2
 Severity:  Unassigned  |   Keywords:
------------------------+--------------------------
 strk suggested I put the ticket
 https://trac.osgeo.org/postgis/ticket/4763

 Here as PostGIS uses GEOS directly for ST_BuildArea.

 The issue is:


 {{{
 SELECT ST_BuildArea('MULTIPOLYGON(((186.464466094067
 193.535533905933,187.222148834902 194.157348061513,188.086582838175
 194.619397662556,189.024548389919 194.903926402016,190
 195,190.975451610081 194.903926402016,191.913417161825
 194.619397662556,192.777851165098 194.157348061513,193.535533905933
 193.535533905933,194.157348061513 192.777851165098,194.619397662556
 191.913417161825,194.903926402016 190.975451610081,195
 190,194.903926402016 189.024548389919,194.619397662556
 188.086582838175,194.157348061513 187.222148834902,193.535533905933
 186.464466094067,13.5355339059327 6.46446609406726,12.777851165098
 5.84265193848727,11.9134171618254 5.38060233744356,10.9754516100806
 5.09607359798385,10 5,9.02454838991936 5.09607359798385,8.08658283817455
 5.38060233744357,7.22214883490199 5.84265193848727,6.46446609406726
 6.46446609406726,5.84265193848728 7.22214883490199,5.38060233744357
 8.08658283817455,5.09607359798385 9.02454838991935,5
 9.99999999999999,5.09607359798385 10.9754516100806,5.38060233744356
 11.9134171618254,5.84265193848727 12.777851165098,6.46446609406726
 13.5355339059327,186.464466094067 193.535533905933)),((150
 90,149.039264020162 80.2454838991936,146.193976625564
 70.8658283817455,141.573480615127 62.2214883490199,135.355339059327
 54.6446609406727,127.77851165098 48.4265193848728,119.134171618255
 43.8060233744357,109.754516100806 40.9607359798385,100 40,90.2454838991937
 40.9607359798385,80.8658283817456 43.8060233744356,72.22148834902
 48.4265193848727,64.6446609406727 54.6446609406725,58.4265193848728
 62.2214883490198,53.8060233744357 70.8658283817454,50.9607359798385
 80.2454838991934,50 89.9999999999998,50.9607359798384
 99.7545161008062,53.8060233744356 109.134171618254,58.4265193848726
 117.77851165098,64.6446609406725 125.355339059327,72.2214883490197
 131.573480615127,80.8658283817453 136.193976625564,90.2454838991934
 139.039264020161,99.9999999999998 140,109.754516100806
 139.039264020162,119.134171618254 136.193976625564,127.77851165098
 131.573480615127,135.355339059327 125.355339059327,141.573480615127
 117.77851165098,146.193976625564 109.134171618255,149.039264020162
 99.7545161008065,150 90)))'::geometry);
 }}}

 Used to look like:


 [[Image(before_gaping_hole.png)]]

 But now looks like

 [[Image(after_gaping_hole_no_more.png)]]

 --


 {{{
 SELECT ST_BuildArea('MULTIPOLYGON(((91 50,79 22,51 10,23 22,11 50,23 78,51
 90,79 78,91 50)),((91 100,79 72,51 60,23 72,11 100,23 128,51 140,79 128,91
 100)),((91 150,79 122,51 110,23 122,11 150,23 178,51 190,79 178,91
 150)),((141 50,129 22,101 10,73 22,61 50,73 78,101 90,129 78,141
 50)),((141 100,129 72,101 60,73 72,61 100,73 128,101 140,129 128,141
 100)),((141 150,129 122,101 110,73 122,61 150,73 178,101 190,129 178,141
 150)))'::geometry);
 }}}


 Used to Look like:

 [[Image[before_beautiful_beehive.png]]

 After

 [[Image[after_boring_beehive.png]]

 I think this has been (broken for me) and it's unclear if this was an
 intentional change or not. I personally prefer the old behavior, but as I
 review more I can understand how someone may have decided the new behavior
 was more predictable and thus better.


 So it's been like this I would say probably since 3.6 (maybe even as early
 as 3.5). One pattern I see with the failures is they are all invalid
 polygons. So perhaps it's doing an UnaryUnion or something before feeding
 to ST_BuildArea.

--
Ticket URL: <https://trac.osgeo.org/geos/ticket/1054>
GEOS <http://trac.osgeo.org/geos>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1054: BuildArea behavior changed intentional? and when did it happen

geos-2
#1054: BuildArea behavior changed intentional? and when did it happen
------------------------+---------------------------
 Reporter:  robe        |       Owner:  geos-devel@…
     Type:  defect      |      Status:  new
 Priority:  major       |   Milestone:
Component:  Default     |     Version:  3.6.2
 Severity:  Unassigned  |  Resolution:
 Keywords:              |
------------------------+---------------------------
Changes (by robe):

 * Attachment "before_gaping_hole.png" added.


--
Ticket URL: <https://trac.osgeo.org/geos/ticket/1054>
GEOS <http://trac.osgeo.org/geos>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1054: BuildArea behavior changed intentional? and when did it happen

geos-2
In reply to this post by geos-2
#1054: BuildArea behavior changed intentional? and when did it happen
------------------------+---------------------------
 Reporter:  robe        |       Owner:  geos-devel@…
     Type:  defect      |      Status:  new
 Priority:  major       |   Milestone:
Component:  Default     |     Version:  3.6.2
 Severity:  Unassigned  |  Resolution:
 Keywords:              |
------------------------+---------------------------
Changes (by robe):

 * Attachment "after_gaping_hole_no_more.png" added.


--
Ticket URL: <https://trac.osgeo.org/geos/ticket/1054>
GEOS <http://trac.osgeo.org/geos>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1054: BuildArea behavior changed intentional? and when did it happen

geos-2
In reply to this post by geos-2
#1054: BuildArea behavior changed intentional? and when did it happen
------------------------+---------------------------
 Reporter:  robe        |       Owner:  geos-devel@…
     Type:  defect      |      Status:  new
 Priority:  major       |   Milestone:
Component:  Default     |     Version:  3.6.2
 Severity:  Unassigned  |  Resolution:
 Keywords:              |
------------------------+---------------------------
Changes (by robe):

 * Attachment "before_beautiful_beehive.png" added.


--
Ticket URL: <https://trac.osgeo.org/geos/ticket/1054>
GEOS <http://trac.osgeo.org/geos>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1054: BuildArea behavior changed intentional? and when did it happen

geos-2
In reply to this post by geos-2
#1054: BuildArea behavior changed intentional? and when did it happen
------------------------+---------------------------
 Reporter:  robe        |       Owner:  geos-devel@…
     Type:  defect      |      Status:  new
 Priority:  major       |   Milestone:
Component:  Default     |     Version:  3.6.2
 Severity:  Unassigned  |  Resolution:
 Keywords:              |
------------------------+---------------------------
Changes (by robe):

 * Attachment "after_boring_beehive.png" added.


--
Ticket URL: <https://trac.osgeo.org/geos/ticket/1054>
GEOS <http://trac.osgeo.org/geos>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1054: BuildArea behavior changed intentional? and when did it happen

geos-2
In reply to this post by geos-2
#1054: BuildArea behavior changed intentional? and when did it happen
------------------------+---------------------------
 Reporter:  robe        |       Owner:  geos-devel@…
     Type:  defect      |      Status:  new
 Priority:  major       |   Milestone:
Component:  Default     |     Version:  3.6.2
 Severity:  Unassigned  |  Resolution:
 Keywords:              |
------------------------+---------------------------
Description changed by robe:

Old description:

> strk suggested I put the ticket
> https://trac.osgeo.org/postgis/ticket/4763
>
> Here as PostGIS uses GEOS directly for ST_BuildArea.
>
> The issue is:
>

> {{{
> SELECT ST_BuildArea('MULTIPOLYGON(((186.464466094067
> 193.535533905933,187.222148834902 194.157348061513,188.086582838175
> 194.619397662556,189.024548389919 194.903926402016,190
> 195,190.975451610081 194.903926402016,191.913417161825
> 194.619397662556,192.777851165098 194.157348061513,193.535533905933
> 193.535533905933,194.157348061513 192.777851165098,194.619397662556
> 191.913417161825,194.903926402016 190.975451610081,195
> 190,194.903926402016 189.024548389919,194.619397662556
> 188.086582838175,194.157348061513 187.222148834902,193.535533905933
> 186.464466094067,13.5355339059327 6.46446609406726,12.777851165098
> 5.84265193848727,11.9134171618254 5.38060233744356,10.9754516100806
> 5.09607359798385,10 5,9.02454838991936 5.09607359798385,8.08658283817455
> 5.38060233744357,7.22214883490199 5.84265193848727,6.46446609406726
> 6.46446609406726,5.84265193848728 7.22214883490199,5.38060233744357
> 8.08658283817455,5.09607359798385 9.02454838991935,5
> 9.99999999999999,5.09607359798385 10.9754516100806,5.38060233744356
> 11.9134171618254,5.84265193848727 12.777851165098,6.46446609406726
> 13.5355339059327,186.464466094067 193.535533905933)),((150
> 90,149.039264020162 80.2454838991936,146.193976625564
> 70.8658283817455,141.573480615127 62.2214883490199,135.355339059327
> 54.6446609406727,127.77851165098 48.4265193848728,119.134171618255
> 43.8060233744357,109.754516100806 40.9607359798385,100
> 40,90.2454838991937 40.9607359798385,80.8658283817456
> 43.8060233744356,72.22148834902 48.4265193848727,64.6446609406727
> 54.6446609406725,58.4265193848728 62.2214883490198,53.8060233744357
> 70.8658283817454,50.9607359798385 80.2454838991934,50
> 89.9999999999998,50.9607359798384 99.7545161008062,53.8060233744356
> 109.134171618254,58.4265193848726 117.77851165098,64.6446609406725
> 125.355339059327,72.2214883490197 131.573480615127,80.8658283817453
> 136.193976625564,90.2454838991934 139.039264020161,99.9999999999998
> 140,109.754516100806 139.039264020162,119.134171618254
> 136.193976625564,127.77851165098 131.573480615127,135.355339059327
> 125.355339059327,141.573480615127 117.77851165098,146.193976625564
> 109.134171618255,149.039264020162 99.7545161008065,150 90)))'::geometry);
> }}}
>
> Used to look like:
>

> [[Image(before_gaping_hole.png)]]
>
> But now looks like
>
> [[Image(after_gaping_hole_no_more.png)]]
>
> --
>

> {{{
> SELECT ST_BuildArea('MULTIPOLYGON(((91 50,79 22,51 10,23 22,11 50,23
> 78,51 90,79 78,91 50)),((91 100,79 72,51 60,23 72,11 100,23 128,51 140,79
> 128,91 100)),((91 150,79 122,51 110,23 122,11 150,23 178,51 190,79 178,91
> 150)),((141 50,129 22,101 10,73 22,61 50,73 78,101 90,129 78,141
> 50)),((141 100,129 72,101 60,73 72,61 100,73 128,101 140,129 128,141
> 100)),((141 150,129 122,101 110,73 122,61 150,73 178,101 190,129 178,141
> 150)))'::geometry);
> }}}
>

> Used to Look like:
>
> [[Image[before_beautiful_beehive.png]]
>
> After
>
> [[Image[after_boring_beehive.png]]
>
> I think this has been (broken for me) and it's unclear if this was an
> intentional change or not. I personally prefer the old behavior, but as I
> review more I can understand how someone may have decided the new
> behavior was more predictable and thus better.
>

> So it's been like this I would say probably since 3.6 (maybe even as
> early as 3.5). One pattern I see with the failures is they are all
> invalid polygons. So perhaps it's doing an UnaryUnion or something before
> feeding to ST_BuildArea.

New description:

 strk suggested I put the ticket
 https://trac.osgeo.org/postgis/ticket/4763

 Here as PostGIS uses GEOS directly for ST_BuildArea.

 The issue is:


 {{{
 SELECT ST_BuildArea('MULTIPOLYGON(((186.464466094067
 193.535533905933,187.222148834902 194.157348061513,188.086582838175
 194.619397662556,189.024548389919 194.903926402016,190
 195,190.975451610081 194.903926402016,191.913417161825
 194.619397662556,192.777851165098 194.157348061513,193.535533905933
 193.535533905933,194.157348061513 192.777851165098,194.619397662556
 191.913417161825,194.903926402016 190.975451610081,195
 190,194.903926402016 189.024548389919,194.619397662556
 188.086582838175,194.157348061513 187.222148834902,193.535533905933
 186.464466094067,13.5355339059327 6.46446609406726,12.777851165098
 5.84265193848727,11.9134171618254 5.38060233744356,10.9754516100806
 5.09607359798385,10 5,9.02454838991936 5.09607359798385,8.08658283817455
 5.38060233744357,7.22214883490199 5.84265193848727,6.46446609406726
 6.46446609406726,5.84265193848728 7.22214883490199,5.38060233744357
 8.08658283817455,5.09607359798385 9.02454838991935,5
 9.99999999999999,5.09607359798385 10.9754516100806,5.38060233744356
 11.9134171618254,5.84265193848727 12.777851165098,6.46446609406726
 13.5355339059327,186.464466094067 193.535533905933)),((150
 90,149.039264020162 80.2454838991936,146.193976625564
 70.8658283817455,141.573480615127 62.2214883490199,135.355339059327
 54.6446609406727,127.77851165098 48.4265193848728,119.134171618255
 43.8060233744357,109.754516100806 40.9607359798385,100 40,90.2454838991937
 40.9607359798385,80.8658283817456 43.8060233744356,72.22148834902
 48.4265193848727,64.6446609406727 54.6446609406725,58.4265193848728
 62.2214883490198,53.8060233744357 70.8658283817454,50.9607359798385
 80.2454838991934,50 89.9999999999998,50.9607359798384
 99.7545161008062,53.8060233744356 109.134171618254,58.4265193848726
 117.77851165098,64.6446609406725 125.355339059327,72.2214883490197
 131.573480615127,80.8658283817453 136.193976625564,90.2454838991934
 139.039264020161,99.9999999999998 140,109.754516100806
 139.039264020162,119.134171618254 136.193976625564,127.77851165098
 131.573480615127,135.355339059327 125.355339059327,141.573480615127
 117.77851165098,146.193976625564 109.134171618255,149.039264020162
 99.7545161008065,150 90)))'::geometry);
 }}}

 Used to look like:


 [[Image(before_gaping_hole.png)]]

 But now looks like

 [[Image(after_gaping_hole_no_more.png)]]

 --


 {{{
 SELECT ST_BuildArea('MULTIPOLYGON(((91 50,79 22,51 10,23 22,11 50,23 78,51
 90,79 78,91 50)),((91 100,79 72,51 60,23 72,11 100,23 128,51 140,79 128,91
 100)),((91 150,79 122,51 110,23 122,11 150,23 178,51 190,79 178,91
 150)),((141 50,129 22,101 10,73 22,61 50,73 78,101 90,129 78,141
 50)),((141 100,129 72,101 60,73 72,61 100,73 128,101 140,129 128,141
 100)),((141 150,129 122,101 110,73 122,61 150,73 178,101 190,129 178,141
 150)))'::geometry);
 }}}


 Used to Look like:

 [[Image(before_beautiful_beehive.png)]

 After

 [[Image(after_boring_beehive.png)]

 I think this has been (broken for me) and it's unclear if this was an
 intentional change or not. I personally prefer the old behavior, but as I
 review more I can understand how someone may have decided the new behavior
 was more predictable and thus better.


 So it's been like this I would say probably since 3.6 (maybe even as early
 as 3.5). One pattern I see with the failures is they are all invalid
 polygons. So perhaps it's doing an UnaryUnion or something before feeding
 to ST_BuildArea.

--

--
Ticket URL: <https://trac.osgeo.org/geos/ticket/1054#comment:1>
GEOS <http://trac.osgeo.org/geos>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1054: BuildArea behavior changed intentional? and when did it happen

geos-2
In reply to this post by geos-2
#1054: BuildArea behavior changed intentional? and when did it happen
------------------------+---------------------------
 Reporter:  robe        |       Owner:  geos-devel@…
     Type:  defect      |      Status:  new
 Priority:  major       |   Milestone:
Component:  Default     |     Version:  3.6.2
 Severity:  Unassigned  |  Resolution:
 Keywords:              |
------------------------+---------------------------
Description changed by robe:

Old description:

> strk suggested I put the ticket
> https://trac.osgeo.org/postgis/ticket/4763
>
> Here as PostGIS uses GEOS directly for ST_BuildArea.
>
> The issue is:
>

> {{{
> SELECT ST_BuildArea('MULTIPOLYGON(((186.464466094067
> 193.535533905933,187.222148834902 194.157348061513,188.086582838175
> 194.619397662556,189.024548389919 194.903926402016,190
> 195,190.975451610081 194.903926402016,191.913417161825
> 194.619397662556,192.777851165098 194.157348061513,193.535533905933
> 193.535533905933,194.157348061513 192.777851165098,194.619397662556
> 191.913417161825,194.903926402016 190.975451610081,195
> 190,194.903926402016 189.024548389919,194.619397662556
> 188.086582838175,194.157348061513 187.222148834902,193.535533905933
> 186.464466094067,13.5355339059327 6.46446609406726,12.777851165098
> 5.84265193848727,11.9134171618254 5.38060233744356,10.9754516100806
> 5.09607359798385,10 5,9.02454838991936 5.09607359798385,8.08658283817455
> 5.38060233744357,7.22214883490199 5.84265193848727,6.46446609406726
> 6.46446609406726,5.84265193848728 7.22214883490199,5.38060233744357
> 8.08658283817455,5.09607359798385 9.02454838991935,5
> 9.99999999999999,5.09607359798385 10.9754516100806,5.38060233744356
> 11.9134171618254,5.84265193848727 12.777851165098,6.46446609406726
> 13.5355339059327,186.464466094067 193.535533905933)),((150
> 90,149.039264020162 80.2454838991936,146.193976625564
> 70.8658283817455,141.573480615127 62.2214883490199,135.355339059327
> 54.6446609406727,127.77851165098 48.4265193848728,119.134171618255
> 43.8060233744357,109.754516100806 40.9607359798385,100
> 40,90.2454838991937 40.9607359798385,80.8658283817456
> 43.8060233744356,72.22148834902 48.4265193848727,64.6446609406727
> 54.6446609406725,58.4265193848728 62.2214883490198,53.8060233744357
> 70.8658283817454,50.9607359798385 80.2454838991934,50
> 89.9999999999998,50.9607359798384 99.7545161008062,53.8060233744356
> 109.134171618254,58.4265193848726 117.77851165098,64.6446609406725
> 125.355339059327,72.2214883490197 131.573480615127,80.8658283817453
> 136.193976625564,90.2454838991934 139.039264020161,99.9999999999998
> 140,109.754516100806 139.039264020162,119.134171618254
> 136.193976625564,127.77851165098 131.573480615127,135.355339059327
> 125.355339059327,141.573480615127 117.77851165098,146.193976625564
> 109.134171618255,149.039264020162 99.7545161008065,150 90)))'::geometry);
> }}}
>
> Used to look like:
>

> [[Image(before_gaping_hole.png)]]
>
> But now looks like
>
> [[Image(after_gaping_hole_no_more.png)]]
>
> --
>

> {{{
> SELECT ST_BuildArea('MULTIPOLYGON(((91 50,79 22,51 10,23 22,11 50,23
> 78,51 90,79 78,91 50)),((91 100,79 72,51 60,23 72,11 100,23 128,51 140,79
> 128,91 100)),((91 150,79 122,51 110,23 122,11 150,23 178,51 190,79 178,91
> 150)),((141 50,129 22,101 10,73 22,61 50,73 78,101 90,129 78,141
> 50)),((141 100,129 72,101 60,73 72,61 100,73 128,101 140,129 128,141
> 100)),((141 150,129 122,101 110,73 122,61 150,73 178,101 190,129 178,141
> 150)))'::geometry);
> }}}
>

> Used to Look like:
>
> [[Image(before_beautiful_beehive.png)]
>
> After
>
> [[Image(after_boring_beehive.png)]
>
> I think this has been (broken for me) and it's unclear if this was an
> intentional change or not. I personally prefer the old behavior, but as I
> review more I can understand how someone may have decided the new
> behavior was more predictable and thus better.
>

> So it's been like this I would say probably since 3.6 (maybe even as
> early as 3.5). One pattern I see with the failures is they are all
> invalid polygons. So perhaps it's doing an UnaryUnion or something before
> feeding to ST_BuildArea.

New description:

 strk suggested I put the ticket
 https://trac.osgeo.org/postgis/ticket/4763

 Here as PostGIS uses GEOS directly for ST_BuildArea.

 The issue is:


 {{{
 SELECT ST_BuildArea('MULTIPOLYGON(((186.464466094067
 193.535533905933,187.222148834902 194.157348061513,188.086582838175
 194.619397662556,189.024548389919 194.903926402016,190
 195,190.975451610081 194.903926402016,191.913417161825
 194.619397662556,192.777851165098 194.157348061513,193.535533905933
 193.535533905933,194.157348061513 192.777851165098,194.619397662556
 191.913417161825,194.903926402016 190.975451610081,195
 190,194.903926402016 189.024548389919,194.619397662556
 188.086582838175,194.157348061513 187.222148834902,193.535533905933
 186.464466094067,13.5355339059327 6.46446609406726,12.777851165098
 5.84265193848727,11.9134171618254 5.38060233744356,10.9754516100806
 5.09607359798385,10 5,9.02454838991936 5.09607359798385,8.08658283817455
 5.38060233744357,7.22214883490199 5.84265193848727,6.46446609406726
 6.46446609406726,5.84265193848728 7.22214883490199,5.38060233744357
 8.08658283817455,5.09607359798385 9.02454838991935,5
 9.99999999999999,5.09607359798385 10.9754516100806,5.38060233744356
 11.9134171618254,5.84265193848727 12.777851165098,6.46446609406726
 13.5355339059327,186.464466094067 193.535533905933)),((150
 90,149.039264020162 80.2454838991936,146.193976625564
 70.8658283817455,141.573480615127 62.2214883490199,135.355339059327
 54.6446609406727,127.77851165098 48.4265193848728,119.134171618255
 43.8060233744357,109.754516100806 40.9607359798385,100 40,90.2454838991937
 40.9607359798385,80.8658283817456 43.8060233744356,72.22148834902
 48.4265193848727,64.6446609406727 54.6446609406725,58.4265193848728
 62.2214883490198,53.8060233744357 70.8658283817454,50.9607359798385
 80.2454838991934,50 89.9999999999998,50.9607359798384
 99.7545161008062,53.8060233744356 109.134171618254,58.4265193848726
 117.77851165098,64.6446609406725 125.355339059327,72.2214883490197
 131.573480615127,80.8658283817453 136.193976625564,90.2454838991934
 139.039264020161,99.9999999999998 140,109.754516100806
 139.039264020162,119.134171618254 136.193976625564,127.77851165098
 131.573480615127,135.355339059327 125.355339059327,141.573480615127
 117.77851165098,146.193976625564 109.134171618255,149.039264020162
 99.7545161008065,150 90)))'::geometry);
 }}}

 Used to look like:


 [[Image(before_gaping_hole.png)]]

 But now looks like

 [[Image(after_gaping_hole_no_more.png)]]

 --


 {{{
 SELECT ST_BuildArea('MULTIPOLYGON(((91 50,79 22,51 10,23 22,11 50,23 78,51
 90,79 78,91 50)),((91 100,79 72,51 60,23 72,11 100,23 128,51 140,79 128,91
 100)),((91 150,79 122,51 110,23 122,11 150,23 178,51 190,79 178,91
 150)),((141 50,129 22,101 10,73 22,61 50,73 78,101 90,129 78,141
 50)),((141 100,129 72,101 60,73 72,61 100,73 128,101 140,129 128,141
 100)),((141 150,129 122,101 110,73 122,61 150,73 178,101 190,129 178,141
 150)))'::geometry);
 }}}


 Used to Look like:

 [[Image(before_beautiful_beehive.png)]]

 After

 [[Image(after_boring_beehive.png)]]

 I think this has been (broken for me) and it's unclear if this was an
 intentional change or not. I personally prefer the old behavior, but as I
 review more I can understand how someone may have decided the new behavior
 was more predictable and thus better.


 So it's been like this I would say probably since 3.6 (maybe even as early
 as 3.5). One pattern I see with the failures is they are all invalid
 polygons. So perhaps it's doing an UnaryUnion or something before feeding
 to ST_BuildArea.

--

--
Ticket URL: <https://trac.osgeo.org/geos/ticket/1054#comment:2>
GEOS <http://trac.osgeo.org/geos>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1054: BuildArea behavior changed intentional? and when did it happen

geos-2
In reply to this post by geos-2
#1054: BuildArea behavior changed intentional? and when did it happen
------------------------+---------------------------
 Reporter:  robe        |       Owner:  geos-devel@…
     Type:  defect      |      Status:  new
 Priority:  major       |   Milestone:
Component:  Default     |     Version:  3.6.2
 Severity:  Unassigned  |  Resolution:
 Keywords:              |
------------------------+---------------------------

Comment (by strk):

 BuildArea needs input to be noded. Not sure how it could have worked when
 you first wrote the documentation (would be nice to know).

--
Ticket URL: <https://trac.osgeo.org/geos/ticket/1054#comment:3>
GEOS <http://trac.osgeo.org/geos>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: [GEOS] #1054: BuildArea behavior changed intentional? and when did it happen

geos-2
In reply to this post by geos-2
#1054: BuildArea behavior changed intentional? and when did it happen
------------------------+---------------------------
 Reporter:  robe        |       Owner:  geos-devel@…
     Type:  defect      |      Status:  closed
 Priority:  major       |   Milestone:
Component:  Default     |     Version:  3.6.2
 Severity:  Unassigned  |  Resolution:  wontfix
 Keywords:              |
------------------------+---------------------------
Changes (by robe):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 okay guess by design then -- I've moved examples in PostGIS to
 ST_MakeValid.
 as noted in https://trac.osgeo.org/postgis/ticket/4763

--
Ticket URL: <https://trac.osgeo.org/geos/ticket/1054#comment:4>
GEOS <http://trac.osgeo.org/geos>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel