Tile border seams

[leblowl]

Hey all,

Unfortunately I can't post issues to mapzen/TileStache, so I'll add this here. I am still having issues with seams on tile borders. I haven't looked into it too much, but I thought I'd let ya'll know. It looks like its just occurring with water.

tilezen/TileStache#34

[rmarianski]

When looking at our tiles with the tangram renderer, I only see these seams where the earth and water layers don't match up, ie there's "dead space" in the tiles that is not covered by any data. I did this by configuring a different color than water for the background, like red.

@leblowl: does this sound like what you're seeing?

I can think of a few approaches to try and solve this:

1. infer the earth data: ie earth = tile square - water
2. "snap" the earth to the water data in a post processing step
3. explore using an alternate simplification strategy

I like option 1, because it would reduce the number of queries we run, and it should always prevent these seams.
2 is another perspective on the first option, but less efficient. This would be more advantageous if we provided additional property data in our earth layer, but we don't at the moment.
About 3, certain other algorithms might be better at producing more consistent results, but unless they work across layers, there would still be concern that they wouldn't always align. And we really just need earth and water to align exactly to prevent these seams, not the other layers.

@nvkelso , @bcamper any thoughts?

[leblowl]

I've seen the seams where earth and water layers don't match up, but I was referring to the little grey lines in the photo above where the water layer tiles have a little margin between them. I'm using mapbox-gl-js for rendering also.

[rmarianski]

Is it easy for you to get the z,x,y tile coordinates for the adjacent tiles where this is happening?

[leblowl]

It looks like it is occurring on all water tiles. I'm also getting some psql errors, so I'll try to correct those & make sure nothing is related.

Here is an upclose shot of water tile intersections:

[leblowl]

So just as an update, I tested this with vector.mapzen.com's tile service & I am getting the same issues when specifying the fill-outline-color in mapbox-gl-js. Here is another image showing the details:

[jak2030]

Hey, I have a similar issue when trying to use earth or water layers. One example:

(Road layer loads great!)

• using leaflet + geojsons

[nvkelso]

@jak2030 Water and earth should probably be filled only in client render, not stroked. What use case are you trying to solve (re the roads + water + land render)?

The gaps between earth & water vector polygon areas sounds like a bug.

@rmarianski I think the source OSM data just has data for coastline (water), and earth is implied by taking the web merc unit boundary (±180/±!90 web merc bbox) - water. But there should be a more consistent generalization for all data, can we trouble shoot why this snapping / quantification is different between the features? Would switching to VW simplification resolve this problem?

[rmarianski]

I dug deeper into the seams, and to me it looks like the data in the tiles is correct. I loaded it up into qgis, and when I used the same color for all tiles, things looked like they matched up. I did have to select that the fill and border be the same color, otherwise there indeed was a seam in between that was empty.

This is a screenshot with both fill and border set to red after loading some tiles into qgis. Sorry for the red, just attempting to make any gaps striking :)

I manually inspected some of the water tiles that were just water, and it looks like the numbers on the adjacent borders do match up exactly. It's important to note that we don't include additional data beyond the tile boundaries. Sometimes renderers expect the tiles to bleed over into one another slightly. We use the exact bounds for the tiles, and don't buffer them.

For example, adjacent columns:
http://vector.mapzen.com/osm/water/6/5/29.json
http://vector.mapzen.com/osm/water/6/6/29.json
http://vector.mapzen.com/osm/water/6/7/29.json

And adjacent rows:
http://vector.mapzen.com/osm/water/6/5/29.json
http://vector.mapzen.com/osm/water/6/5/30.json
http://vector.mapzen.com/osm/water/6/5/31.json

@nvkelso for the earth layer we currently are issuing queries to the database. We use the data from openstreetmapdata.com [1] for zooms >= 9, and use natural earth data for the lower zooms. It could be that the land polygons dataset is derived exactly like you're mentioning though, I'm not sure. I'd personally like to move to deriving this data ourselves dynamically by subtracting the water from the bounding box. That should resolve the issue with earth not aligning with water.

[1] http://openstreetmapdata.com/data/land-polygons

[leblowl]

So I finally looked into this a little more & got an update regarding mapbox-gl-js: mapbox/mapbox-gl-js#1738

It sounds like his answer follows what you were suspecting with the renderer requiring a little bleed. This solves it for me, closing now. Thank you!