Geometry corrupted by simplification

[pnorman]

In the red box the water has had a point dropped from the region of the green circle which is essential, resulting in the line pointed at by the yellow arrow being out of place. It should be along the tile bounds.

Starting with TEGOLA_OPTIONS=DontSimplifyGeo gives a normal result

The tile in question is 8/40/87 and the relevant part of the TOML file is

...
  [[providers.layers]]
  name = "lz_ocean"
  id_fieldname = "osm_id"
  geometry_fieldname = "way"
  sql = """
  SELECT
      row_number() OVER () AS osm_id,
      ST_AsBinary(way) AS way
    FROM (SELECT
        way
      FROM simplified_ocean_polygons
      WHERE way && !BBOX!
    ) _
  """

...

[[maps.layers]]
name = "water2"
provider_layer = "osm2pgsql.lz_ocean"
min_zoom = 6
max_zoom = 10

The data is loaded from http://data.openstreetmapdata.com/simplified-water-polygons-complete-3857.zip with ogr2ogr -f PostgreSQL -lco GEOMETRY_NAME=way -lco SPATIAL_INDEX=FALSE -lco EXTRACT_SCHEMA_FROM_LAYER_NAME=YES -nln loading.simplified_ocean_polygons PG:dbname=gis data/simplified_ocean_polygons/simplified-water-polygons-complete-3857/simplified_water_polygons.shp but for testing, this should work

ogr2ogr -f PostgreSQL -lco GEOMETRY_NAME=way simplified_ocean_polygons \
  PG:dbname=gis \
  data/simplified_ocean_polygons/simplified-water-polygons-complete-3857/simplified_water_polygons.shp

[ARolek]

@pnorman this sounds like something that will be fixed under #166. The problem shows up with the Douglas Peucker simplification algorithm and right angels. In v0.6.0 I implemented a per layer simplification control so you can turn it off for problem layers without needing to turn it off for everything. the config is dont_simplify under a map layer.

[pnorman]

The problem shows up with the Douglas Peucker simplification algorithm and right angels.

I don't see this as something caused by DP. Scaling everything to 2048 units per tile, I made some measurements. The distance from the missing point to the line is 50, which would put a lower bound on ε.

If I blow up a different part and apply DP by hand, I get

The thin green line is 14 units long, well the bound of ε that would be necessary for this error.

All this being said, there are some tricky constraints on using DP when it comes to tile edges, buffering, and avoiding artifacts. But this isn't one of those class of problems, this is something else.

[pnorman]

I've done a check of my tracked bugs, and this bug is still present in 0.9.x branch.