You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The 'shard' process halves a geometry (alternating horizontally & vertically) until each shard complexity is below a fixed threshold.
This ensures that the PIP performance is fast and linear.
This process is tested and works well, however, I have seen some geometries which fail to split due to topology errors.
It's pretty rare, it doesn't affect any WOF geometries and less than 1 in 10,000 OSM geometries.
I'll open up a separate issue related to repairing invalid geometries, but this issue is simply to handle the case where sharding fails due to a topology error.
In the case where a shard fails to half, we should:
discard both of the two child halves (the ones created at level+1)
do not delete the parent shard (the one at level)
I attempted to fix this in the past but for some reason IsValid() is returning 1 despite the shard geom being invalid.
It might be that spatialite@5 is better at handling this because it uses LIBRTTOPO instead of GEOS.
The text was updated successfully, but these errors were encountered:
The 'shard' process halves a geometry (alternating horizontally & vertically) until each shard complexity is below a fixed threshold.
This ensures that the PIP performance is fast and linear.
This process is tested and works well, however, I have seen some geometries which fail to split due to topology errors.
It's pretty rare, it doesn't affect any WOF geometries and less than 1 in 10,000 OSM geometries.
I'll open up a separate issue related to repairing invalid geometries, but this issue is simply to handle the case where sharding fails due to a topology error.
In the case where a shard fails to half, we should:
level+1
)level
)I attempted to fix this in the past but for some reason
IsValid()
is returning1
despite the shard geom being invalid.It might be that
spatialite@5
is better at handling this because it usesLIBRTTOPO
instead ofGEOS
.The text was updated successfully, but these errors were encountered: