# simplify tiled geometries while preserving anything on the edge

I have a dataset of polygons split into evenly sized tiles. How can I go about simplifying them, but not along the tile edges, so that there aren't any gaps between continuous features when the tiles are aligned with one another? For instance, here are two unsimplified tiles:

After simplification, a "seam" forms between the two halves of Antarctica:

Here are Gists of the non-simplified and simplified GeoJSON files. I'm currently splitting the original geometries into tiles and then simplifying, and one solution appears to be reversing that order (simplifying and tiling afterwards), but that's unfortunately not feasible for architectural reasons. A PostGIS solution is preferred, but alternatives are welcome!

• maybe look at using hairy tiles - where features can extend beyond the edge – Ian Turton May 30 '15 at 8:45
• It is the tiling that is causing the seams, not the simplification, no? There is the function ST_SimplifyPreseveTopology, but I don't think this will help in your case. – John Powell Jun 1 '15 at 15:02
• @JohnBarça, no, it's the simplification. The first image shows the tiled geometries without simplification, and they're fine. The seam only appears when simplification is introduced. – sevko Jun 1 '15 at 15:04
• I've ended up answering and accepting my own answer, but if a better answer comes along I'll likely accept it instead. – sevko Jun 5 '15 at 15:41

After some investigation, I settled on the following solution: simplify the polygons before cutting out a tile. My initial solution would:

1. identify all of the overlapping/contained geometries for a tile bounding box
2. cut out the precise tile, clipping any geometries that extended over the edge
3. simplify all of the geometries, which creates the on-border seams whenever a geometry right on the edge shifted off it

I switched 2.) and 3.) around, so that we simplify all of the geometries first, and then extract the tile, which means that any geometries that end up inside of it are always aligned perfectly with the sides. Note that this incurs a performance hit, since, for example, you might be creating a tile containing a bit of the US coastline, and would have to simplify the entire US coastline polygon before cutting out the tile you want, rather than cutting it out first and then simplifying a much smaller geometry. To get around this, I introduced another step before the simplification:

1. identify all of the overlapping/contained geometries for a tile bounding box
2. cut out a tile slightly larger (in my case, by an arbitrary factor of 0.1) than the tile you'll ultimately want to create, so as to reduce the amount of unnecessary simplification that has to be performed in the next step
3. simplify all of the geometries in the larger tile
4. cut out the precise desired tile from the larger one, clipping any geometries that extended over the edge

This means that geometries are still simplified along borders that lie outside of the tile that will ultimately be cut out, but we're doing it for a much smaller one than would otherwise be the case (for instance, we're no longer simplifying the entire US poly, but just the area that slightly surrounds our desired tile). Since simplification doesn't happen along the tile edge, this still solves the seam problem.

## alternative solution

An alternative solution that I considered but didn't explore was just implementing my own version of the Douglas-Peucker simplification algorithm, which is what ST_Simplify uses internally (again, using PostGIS here), and hardcoding a conditional somewhere that prevents it from simplifying away points that lie on the tile boundary. Could just copy the libgeos simplification implementation that PostGIS relies on and bolt that on somewhere inside of it. This seems like it'd be error-prone and might be a bad idea, but it's probably doable.