Geometry issues

[kkaefer]

This ticket is for collecting issues we find with the geometry in our vector tiles:

• make sure the polygons for a zoom level aren't overly detailed. this is currently happening with zoom level 6 for example
• fix clipping; this introduces very weird artifacts that are visible in our mapnik-rendered image tiles, but especially apparent when zooming in
• find other ways to reduce the buffer size; oscim's data sizes are about 20x smaller than ours!? (when zooming into a particular point from the world view)
• don't reencode the street lines again for label layers; find a more efficient way to define label layers
• ideally, we'd only load every other (or every third) zoom level rather than every zoom level. minimum rendered tile size should be something like 512 or 1024 so that we only need to load 1-2 tiles per map view
• remove objects with only coincident points that should be lines. this happens when scaling very small lines and rounding them to integers. we have code that eliminates duplicate points that result from this, but we don't have any code that removes entire line segments like this
• combine long lines, there are thousands of very short line segments that should be joined. this allows us to draw proper line joins
• merge double-carriageway roads on low zoom level tiles
  • use centerline of adjacent roads
• combine long road segments in a tile on low zoom levels
  • easier simplification?
• broken border/admin lines on z3, z4, z5
• broken roads (motorway vs. motorway_link?, bridges!)
• merge large water polygons that have the same tags. This allows us to draw fewer edge antialiasing fragments and removes weird artifacts.
  • many water polygons are duplicates and overlapping, sometimes because the OSM source data is that way and sometimes because we have generalized and non-generalized polygons in the same data source
  • we store lots of small river polygon segments, but not the actual rivers in low zoom levels. might be good to store them instead and throw away riverbank polygons (and just retain the lakes)
  • a better metric to determine what riverbank polygon to retain, we should use something like the maximum circle we can fit into the polygon at any location (e.g. using a delaunay triangulation?)
  • no overlapping rtree polygons
  • line thinning for narrow rivers => convert to waterway
  • prevent "broken" rivers, water polygons that are part of a river but are
    too small to be included in a tile

[kkaefer]

mapbox/mapnik-internal#5

[kkaefer]

• Merge building polygons on zoom level 13

[ansis]

wishlist item: a line property that provides the length of the beginning of the line for lines that start off-screen. I'm not sure how to put this into words, hopefully the diagram helps. This would be let us make dashed lines and line markers seamless across tiles and zoom levels.

    ______
   |      |
---|----- |
   |______|


|__|--------- this length

[ansis]

• indication of which zoom level a feature first appears at (for fading, scaling)

[kkaefer]

On Friday, I imported a small extract and played around with the data produced by the vector tiles. In particular, I focussed on landuse polygons at low zoom levels (7-12). Basically what is going on is that we're generalizing on import, once for z7/8/9 and once for z10/11/12. While the generalization is okay for zoom level 9, using the same data for z7 just adds a lot of gratuitous detail. In addition, we're dropping small geometries based on total area.

For areas like forests or parks at low zoom levels, these are the things we should improve:

• Join disconnected or overlapping areas
• Join areas that are separated by a narrow strip, essentially do a dilate/erode step
• Simplify a lot to remove gratuitous detail

While all of these individual area ways have distinct values and are sometimes named, we're currently dropping all of that information, so there's no reason to keep the geometries distinct.

Rather than operating on a vector level, we could also do those steps on a bitmap level and run a connected component analysis to generate vectors from the binary image, although that might be pretty costly cpu-wise too.

[mourner]

@yhahn @ajashton closing here, could you please make sure all items here are solved or tracked elsewhere?