Here's an issue I encountered while using turf.js to simply polygons due to the spec of the Polygon object.
What rendering I wanted to simplify:
What I got with reduction turf.js:
I feel the cause of the problem is a loss of context induced by defining the ring of a polygon with a single closed line : all points are given the same attention and subjected to being overseen by any geometric simplification algorithm.
In my case, some corner-stones (points that are bound to more than 2 ways of the same admin_level in the DB) were skipped or adjusted by the algorithm because the multiple association infos lost : they're just points in a closed line.
It leads to the gaps and overlaps on the second rendered map.
A solution to this issue would be to be able to define the rings (outer and inner) of a polygon as a closed MultiLine object so single edges can be simplified independently of others to any required precision while allowing easier operations with of adjacent polygons,
Pros:
- allows to simplify any edge of a polygon in a predictable way by whichever simplification algorithm while still keeping the main geometric properties.
- helps reducing storage, IO and processing costs while keeping rendering manipulations accurate with any given precision scale and pleasant to the end user.
Cons:
- adds a nested level in the polygon members hierarchy
- thus causes a breaking change in already existing GeoJson objects
A proposal to alleviate the cons would be to tag the GeoJson object with the spec version it is defined on from this point, defaulting to the current version if not explicitly specified.
Here's an issue I encountered while using turf.js to simply polygons due to the spec of the Polygon object.
What rendering I wanted to simplify:
What I got with reduction turf.js:
I feel the cause of the problem is a loss of context induced by defining the ring of a polygon with a single closed line : all points are given the same attention and subjected to being overseen by any geometric simplification algorithm.
In my case, some corner-stones (points that are bound to more than 2 ways of the same admin_level in the DB) were skipped or adjusted by the algorithm because the multiple association infos lost : they're just points in a closed line.
It leads to the gaps and overlaps on the second rendered map.
A solution to this issue would be to be able to define the rings (outer and inner) of a polygon as a closed MultiLine object so single edges can be simplified independently of others to any required precision while allowing easier operations with of adjacent polygons,
Pros:
Cons:
A proposal to alleviate the cons would be to tag the GeoJson object with the spec version it is defined on from this point, defaulting to the current version if not explicitly specified.