Docs that use ST_BuildArea are wrong but they are more beautiful than the right docs would be

[robe]

As noted in ​https://lists.osgeo.org/pipermail/postgis-devel/2020-October/028646.html

at least these doc images are wrong

​http://postgis.net/docs/manual-3.0/ST_BuildArea.html

and

​http://postgis.net/docs/manual-3.0/ST_LongestLine.html

It's so sad because the wrong docs are way more beautiful than what the right docs would be. So so sad. Can we have the old build area behavior back so I don't have to fix the docs to show depressingly simple images.

[strk]

The commit which changed behavior was [b6023cb85cdb6029297af712cdd0dc03237408e6/git], landing in 2012, and referencing #1806 - so presumably behavior changed in PostGIS-2.0.1 — behavior was changed to be faster. The reason why BuildArea was written was for Topology, and the new behavior is still good for Topology

[strk]

(NOTE: the input still needed to be noded, in PostGIS-2.0.1, so we're left to find out how you created the BuildArea examples)

[strk]

Ok I think I got it: the non-noded input in the documentation would have resulted in only 2 polygons out of Polygonizer, and the iterative symdifference would result in the given image.

Now, with the new algorithm, you just never get that result from that input with ST_BuildArea. But you can get it with ST_MakeValid, if the input is an invalid MULTIPOLYGON

[robe]

Brilliant. Yes applying ST_MAkeValid before the ST_BuildArea seems to give me the beautiful results back for both ST_BuildArea and ST_LongestLine.

Guess we should tell people to always use ST_MAkeValid after ST_Collect of Polygons because ST_Collect is stupid and always results in degenerate MULTIPOLYGON.

[robe]

Only unsatisfying thing about this is then there is no need for ST_BuildArea anymore as ST_MakeValid does all the work.

[Regina Obe <lr@…>]

In a1bbe50/git:

So ST_BuildArea ain't what it used to be 10 years ago, but luckily ST_MakeValid does what old ST_BuildArea did, so move examples to ST_MakeValid from ST_BuildArea and party like it's 2010. references #4763

[robe]

Note also raised at ​https://trac.osgeo.org/geos/ticket/1054 and closed there as well as something that was never intended to work.