Can't get tippecanoe to output polygons without simplification

[iandees]

I'm trying to generate a dataset of buildings in Detroit to use with OSM QA Tiles for the Detroit Mapping Challenge (osmus/detroit-mapping-challenge#4).

I took a shapefile from their open data site, used ogr2ogr to convert it to GeoJSON. The output of that is available here.

I then pass that through tippecanoe:

$ tippecanoe --version
tippecanoe v1.30.0
$ cat ~/Downloads/detroit-buildings.geojson | tippecanoe \
    --buffer=0 \
    --no-duplication \
    --no-clipping \
    --base-zoom=12 \
    --maximum-zoom=12 \
    --minimum-zoom=12 \
    --no-feature-limit \
    --no-tile-size-limit \
    --no-line-simplification \
    -o ~/Downloads/detroit-buildings.mbtiles
For layer 0, using name "detroitbuildings"
420294 features, 72380821 bytes of geometry, 4 bytes of separate metadata, 28943223 bytes of string pool
  99.9%  12/1100/1513

I then run a tile-reduce job that dumps out a tile's worth straight to GeoJSON through this map function:

module.exports = function(data, tile, writeData, done) {
  var fc = turf.featureCollection(data.buildings.detroitbuildings.features);
  writeData(JSON.stringify(fc) + '\n');
  return done(null, null);
};

The output FeatureCollection is simplified, even though it shouldn't be (the green layer here is the output from tippecanoe via tile-reduce):

[e-n-f]

Thanks for the test case. Whatever is going on here might also explain the mystery of #562. I'll take a look and figure out what is going on.

[e-n-f]

@iandees Can you be more specific about the lat/lon of the particular buildings in this screenshot so I don't have to find them?

[e-n-f]

Found them at 42.42662,-83.28476

[iandees]

👍 For what it's worth, I ran tile-reduce until it spit out one z12 tile and then killed it. I added the output FeatureCollection to QGIS alongside the original FeatureCollection and zoomed into the area of the z12 tile. Not sure where I ended up looking so I'm glad you found something :)

[e-n-f]

I really think the problem here is just insufficient maxzoom. With a specified maxzoom of 12 and the default detail of 12, the tile resolution is only good to 360 / (2 ^ (12 + 12)) / .00000274 ≈ 7.83 feet.

The original GeoJSON is specified to 15 decimal digits, which is clearly excessive, but 8 feet is not enough precision to represent buildings that are only 30 or so feet on a side very well, so rounding error is inevitable.

I would suggest using --maximum-zoom=15 for approximately 1-foot precision.

(If you need to use z12 tiles, increase --full-detail instead, but that will not help with the precision of GL rendering, which has its own maximum tile extent.)

[iandees]

Ah interesting! The primary goal here is to use this for processing an OSM import, not necessarily for visualization. I'll increase the detail and see what happens.

[iandees]

This time around I used

cat ~/Downloads/detroit-buildings.geojson | tippecanoe \
    --buffer=0 \
    --no-duplication \
    --no-clipping \
    --base-zoom=12 \
    --maximum-zoom=12 \
    --minimum-zoom=12 \
    --full-detail=12 \
    --no-feature-limit \
    --no-tile-size-limit \
    --no-line-simplification \
    -o ~/Downloads/detroit-buildings.mbtiles

and got the same sort of thing:

[iandees]

Increasing to z15 tiles seems to have helped, thanks for the suggestion. I had to extract the OSM QA tiles into z15 tiles, too.

I'll close here.

[e-n-f]

@iandees You said --full-detail=12, which is the default. If you want more detail, you need to specify a higher number.

[iandees]

Ah, ok. That's a touch confusing – the name of the flag implies that you're setting the zoom level at which you get full detail. So I was assuming that since I was rendering z12 tiles I would get full detail.

[e-n-f]

Thanks. I'll try to make it clearer in the README what the flag does.

[iandees]

PS Thanks for your time! The Tippecanoe+tile-reduce workflow is a fun to play with and easy to scale up way of doing OSM imports.