Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rgwood opened this issue Jan 31, 2018 · 11 comments

Comments

@rgwood
Copy link

commented Jan 31, 2018

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:
sw_van_zoom12

And at zoom level 13:
sw_van_zoom13

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):

sw_van_circles

This occurs elsewhere in the city too:

kits12

kits13

kits14

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

@ericfischer

This comment has been minimized.

Copy link
Contributor

commented Jan 31, 2018

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

This comment has been minimized.

Copy link
Author

commented Jan 31, 2018

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:
kits13
kits14

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.

@ericfischer

This comment has been minimized.

Copy link
Contributor

commented Jan 31, 2018

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.

@ericfischer

This comment has been minimized.

Copy link
Contributor

commented Jan 31, 2018

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

This comment has been minimized.

Copy link
Author

commented Jan 31, 2018

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.

@ericfischer

This comment has been minimized.

Copy link
Contributor

commented Feb 7, 2018

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

@rgwood

This comment has been minimized.

Copy link
Author

commented Feb 7, 2018

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.

@ericfischer

This comment has been minimized.

Copy link
Contributor

commented Feb 7, 2018

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

@rgwood

This comment has been minimized.

Copy link
Author

commented Feb 7, 2018

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

This comment has been minimized.

Copy link
Author

commented May 4, 2018

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.

@ericfischer

This comment has been minimized.

Copy link
Contributor

commented May 4, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.