Polygonize after simplifying ways fails

[ckgoo...@gmail.com]

Hi.  I have a table of LINESTRING geometries  and I aggregate them into the Polygonize function to get a polygon geometry.  If I use the Simplify function on the LINESTRINGS to reduce the number of points I am getting cases where  Polygonize returns -1.

I did find there was an E-09 difference in the y values from the original start and end points  between my original and simplified LINESTRINGS but I updated my simplified geometry  back to have original values for these two points but Polygonize still fails.

I am not completely sure, but it feels impossible that a polygon made up of LINESTRINGS will become invalid if the constituent lines are simplified.

Does anyone have any thoughts on why I am getting these Polygonize failures?

Unfortunately I’m unable to visualise the simplified LINESTRINGS as I’m blind.

Best, Chris

[sandro furieri]

Il 2025-12-12 22:54 ckgoo...@gmail.com ha scritto:
> I am not completely sure, but it feels impossible that a polygon made
> up of LINESTRINGS will become invalid if the constituent lines are
> simplified.
>
> Does anyone have any thoughts on why I am getting these Polygonize
> failures?
>

Hi Chris,

There are some important differences between LINESTRINGs and POLYGON
RINGs.

1) a LINESTRING is valid if it has at least two points; there are
no other requirements.

2) a RING instead has much more stringent requirements:
* must form a closed figure, with the first and last points
coinciding.
* there must be no points of self-intersection (hourglass
figures).
* there must never be overlapping segments.
* must not contain spikes.

When you apply ST_Simplify() to your Linestrings it is very
likely that the modified geometries will then violate some
requirement that prohibits creating a valid RING.

I don't know if your POLYGON contain internal holes;
in this case, a further requirement arises: the internal
RINGs can never intersect the external one, they must
necessarily be completely contained within it.
It is quite evident that the upstream simplification
of the Linestrings could easily create violations of
this constraint.

Note that there are two different functions:
- ST_Simplify() which is suitable for Linestrings
- ST_SimpplifyPreserveTopolog() it's instead made
specifically for Polygons, and ensures that no
violations occur regarding the internal Rings.

Conclusions: It's the very idea of ​​simplifying
Linestrings in advance that is conceptually flawed,
because this way you are ignoring all the constraints
required by Polygon Rings.

The only consistent approach is to first aggregate
all the Linestrings, and only at the end simplify
the Polygon.
Possibly using ST_SimplifyPreserveTopology() and
not the simple ST_Simplify()

best regards,
Sandro

[sandro furieri]

Hi Chris,

I'm sorry if I stopped replying to you in recent days, but I was
busy with a very urgent job.

When I went to reread your messages once again I realized something
didn't add up.

> I did find there was an E-09 difference in the y values from the
> original start and end points between my original and simplified
> LINESTRINGS but I updated my simplified geometry back to have
> original values for these two points but Polygonize still fails.
>

I did a quick check using a dataset of about a thousand Linestrings
(srid=4326); these are very varied road routes with a number of points
rangin from a few dozen to several thousand, and with lengths in
the range between 1 and 50 km.
I used ST_Simplify() with three different gradually increasing
tolerance factors.

In no case did I detect any shifts in the starting and ending
points, which always remain absolutely unchanged, as I expected.

This leads me to suspect that your problem might arise right
here, from something that introduces subtle errors in the
coordinates but that can't be directly attributed to
ST_Simplify(); check your procedures better.

-------------------------------------

Second point; it is clear that your procedure for simplifying
OSM WAYs introduces something that prevents you from
reconstructing all the Polygons.

I think I understand that you throw all the simplified
linestrings together in a single pass.
But in this way a single failure is enough to cause the
operation as a whole to fail.

You should always be able to trace the ID code of each
single WAY (simplified linestring), just as you should
be able to trace the code of the RELATION which corresponds
to a single polygon.

Try to reconstruct your polygons one at a time, using only
the simplified WAYs that are needed on a case-by-case basis.

I would expect that in most cases it should work, while only
in a minority of cases do I expect possible failures.
This should allow you to limit the problem, which is
certainly the first step to take to understand what
the factors may be may be noise introduced by
ST_Simplify() which prevents the polygons from
being correctly reconstructed.

bye Sandro