coalesce-smallest-as-needed option leaving polygons in wrong place?

[rgwood]

Hi,

I'm using Tippecanoe on a set of polygons and am running into what might be a bug in the coalesce-smallest-as-needed option. It seems to put a small number of polygons in the wrong place at lower zoom levels. Apologies if I'm misunderstanding how the feature works, and please let me know if I can do anything else to help identify/reproduce the issue.

Details

I have a set of polygons (~100k) that represents all of the properties in a city. I'm trying to perform some simple visualization using Mapbox GL JS (all properties zoned like this vs. all properties zoned like that).

If I run Tippecanoe with -f -z 15 -Z 8 -l default -Bg it turns out like this. Not bad, but I'd like to maintain the original area covered by the polygons even when viewing the entire city.

Next I ran Tippecanoe with -f -z 15 -Z 8 -l default -Bg --coalesce-smallest-as-needed --maximum-tile-bytes=250000 and this is how it turned out. It looks much better but now some of the polygons are in the wrong location at lower zoom levels.

I'm using --maximum-tile-bytes=250000 for demonstration purposes, the problem is still present with 500k tiles but a bit less obvious.

Examples

These are all from my map at https://stoic-rosalind-23887f.netlify.com which uses a Mapbox-hosted .mbtiles file. I created the tiles by running Tippecanoe with -f -z 15 -Z 8 -l default -Bg --coalesce-smallest-as-needed --maximum-tile-bytes=250000

See the bottom left of the map at zoom level 12:

And at zoom level 13:

Note the polygon that changed from yellow to blue. If I click on that tile to get more info at zoom level 12, I can tell that 1) it's a polygon that should be yellow according to its features, 2) it's definitely in the wrong place. This image shows where the yellow polygon is vs. where it should be (and is located at higher zoom levels):

This occurs elsewhere in the city too:

Note the yellow tiles (surrounded by blue) which disappear as we zoom in.

[e-n-f]

The essence of --coalesce-smallest-as-needed is to merge together features that shouldn't legitimately be merged based on their attributes, but must be merged to make the tiles small enough. It prioritizes geometric completeness over attribute correctness.

If you want to coalesce only those features that really ought to be coalesced because they have identical attributes, please use --coalesce instead. (But that may not be sufficient if there are not enough features with identical attributes.)

Or do I misunderstand the issue?

[rgwood]

Hmm. I'm still a little confused by this behaviour. It seems like some attributes are ending up fairly far from their original location at lower zoom levels – not in adjacent features, but several features away.

For example, the handful of yellow tiles that show up at zoom level 13 but disappear (correctly) at zoom level 14:

I would expect some attributes to disappear at lower zoom levels (or maybe end up in a merged feature comprised of multiple adjacent features) – but instead it seems like these attributes have "jumped over" a bunch of features to end up where they are.

[e-n-f]

OK, that is kind of weird. There is some slop to the logic of which features can be as-needed coalesced: it is not actually by nearest neighbor (which would be very slow to calculate), but is based on adjacency of the feature bounding box centers in quadkey order. This is usually similar to actual adjacency, but because it is linearized it can jump around at tile boundaries, which I think must be what is happening here. (You can see this sequence in the order that features appear in tippecanoe-decode output: if two features are adjacent in this order, --coalesce-smallest-as-needed can consider merging them.)

For a data set like yours with only one attribute (single-family vs multifamily zoning), a regular, exact --coalesce should be better and sufficient. If you do this and your features aren't being coalesced, you must have other unequal attributes that are preventing the coalescing. I would suggest using -x to get rid of the other attributes or -y to select only the ones that are actually used in the style.

If you can't do that and don't like what --coalesce-smallest-as-needed does, I would suggest using --drop-densest-as-needed instead of the default behavior of trying to lower the tile resolution to make the tiles smaller, since, as you have seen, lowering the resolution usually looks bad.

[e-n-f]

I wonder if I could change it to still use the linearized order, but skip coalescing when the ground distance between two features is an outlier from what you would generally expect from the difference between their quadkeys.

[rgwood]

Thanks for the quick response!

I should have mentioned that I'm also including a number of distinct attributes (address, area, year built...) that are not used for styling but can be seen in a popup by clicking on a feature. So I don't think I'll be able to use --coalesce in the way you suggest (since adjacent features will almost never have identical attributes), and if I recall correctly --drop-densest-as-needed leaves pretty noticeable gaps in the map.

For now I'll probably keep using --coalesce-smallest-as-needed and accept some inaccuracy at lower zoom levels.

[e-n-f]

Is the GeoJSON for this parcel data available? The file from http://data.vancouver.ca/datacatalogue/ doesn't seem to include the zoning.

[rgwood]

Hi, for sure: https://vancouverspecial.blob.core.windows.net/share/parcels.geojson

It's a custom extract created by joining up a few different open data sources. I'm colouring tiles based on the sfh_only attribute.

[e-n-f]

Thanks! Downloading now. Which tippecanoe options are you using with it?

[rgwood]

The examples above (from the map at https://stoic-rosalind-23887f.netlify.com) were created by running tippecanoe -o parcels.mbtiles parcels.geojson -f -z 15 -Z 8 -l default -Bg --coalesce-smallest-as-needed --maximum-tile-bytes=250000.

[rgwood]

Did you have any luck with this approach?

I wonder if I could change it to still use the linearized order, but skip coalescing when the ground distance between two features is an outlier from what you would generally expect from the difference between their quadkeys.

[e-n-f]

Sorry, I have not had a chance to do any more work on polygon coalescing recently.

[dythbj]

Sorry, I have not had a chance to do any more work on polygon coalescing recently. @e-n-f ,Hi,Is this problem solved?