Opened 13 years ago

Closed 11 years ago

#459 closed defect (fixed)

Union fails to fully node input linework

Reported by: strk Owned by: geos-devel@…
Priority: major Milestone: 3.4.0
Component: Default Version: 3.3.0
Severity: Unassigned Keywords: history
Cc:

Description

Performing the union between the boundary of the polygon and the line reported in http://trac.osgeo.org/postgis/ticket/1115 results in not-fully-noded output.

JTS was reported to work: http://lists.osgeo.org/pipermail/geos-devel/2011-July/005342.html

Change History (6)

comment:1 by strk, 13 years ago

My latest finding is that the Union operation triggered a TopologyException thus entered the heuristics used to reduce precision. In GEOS this is first attempting to compute the union with a version of the input geometries having common bits removed and then re-adding the bits in the result.

So my current assumption is that the noding is lost during re-introduction of the bits. I've already seen similar cases in the past, where re-adding bits resulted in the constitution of an invalid geometry. Indeed passing the result again trough an union makes it properly noded (evidently because on this second union operation there's no TopologyException being thrown).

JTS does SnapRounding as first heuristic, which indeed gives a fully noded result at first try. If we did the same we'd fail on two other known cases: bug #360 and bug #392.

My best bet here is to run a noding test at the end of common bits re-addition and continue trough the heuristics methods list if it fails...

comment:2 by strk, 13 years ago

Milestone: 3.3.13.4.0

This is a design limit, won't be handled in a bugfix release

comment:3 by robe, 11 years ago

strk is this easily doable or can should we punt to 3.5?

comment:4 by strk, 11 years ago

I shall check if snaprounding works for those two failing cases now that the HotPixel bug has been fixed with r3825. Let's keep it.

comment:5 by strk, 11 years ago

Offending inputs (to recap): A: 0102000000080000003C0AD7E32D4E3A4152B81E250A4452412085EB91284A3A417A14AE2719445241285C8F42354A3A41A4703D6A1E445241CCCCCC0C474A3A415C8FC2851E445241C4F5289C4B4A3A415C8FC2C52B445241BE08DEAE534E3A41B1B518AB1F44524100000000604E3A419A9999C9064452413C0AD7E32D4E3A4152B81E250A445241 B: 010200000009000000B89C2EFE364A3A41DFC087291F445241545C8F42354A3A41A4703D6A1E4452418CEC6D6F354A3A41FE7E44D31D44524136C80FA4394A3A412D7F89121D445241409B06043D4A3A415860C1CC1C445241360D6849404A3A4136B46EC91C445241FC25CB4B474A3A41B72FD41F1D445241CDCCCC0C474A3A415C8FC2851E445241181E3474434A3A4116CE6F471F445241

They are 2 linestrings. The first one is closed and makes a valid polygon. The second one is simple and crosses the first one exactly in two points. Theoretically their union would polygonize into 2 rings, but the union operation instead fails to produce a correctly noded result.

comment:6 by strk, 11 years ago

Keywords: history added
Resolution: fixed
Status: newclosed

Fixed with r3853 (trunk only)

Note: See TracTickets for help on using tickets.