Could not properly place hole to a parent

[palmerj]

I get the following error when running tippecanoe on a large polygon dataset:

tippecanoe -zg -P -f -o parcels-coalesce.mbtiles -D11 --no-polygon-splitting --coalesce-fraction-as-needed --include=id --include=parcel_intent --include=appellation nz_primary_parcels.geojson
For layer 0, using name "nz_primary_parcels"
nz_primary_parcels.geojson:290347: Reached EOF without all containers being closed
In JSON object {"type":"FeatureCollection","name":"nz_primary_parcels","crs":{"type":"name","properties":{"name":"urn:ogc:def:crs:EPSG::4167"}},"features":[]}
nz_primary_parcels.geojson:338068: Found ] at top level
2580390 features, 422301311 bytes of geometry, 35158737 bytes of separate metadata, 65201523 bytes of string pool
Choosing a maxzoom of -z11 for features about 215 feet (66 meters) apart
Choosing a maxzoom of -z13 for resolution of about 47 feet (14 meters) within features
tile 5/31/20 size is 1027657 with detail 11, >500000
Going to try keeping 46.22% of the features to make it fit
tile 5/31/19 size is 1291787 with detail 11, >500000
Going to try keeping 36.77% of the features to make it fit
tile 5/31/20 size is 746651 with detail 11, >500000
Going to try keeping 29.41% of the features to make it fit
tile 5/31/19 size is 827652 with detail 11, >500000
Going to try keeping 21.10% of the features to make it fit
tile 5/31/20 size is 592952 with detail 11, >500000
Going to try keeping 23.56% of the features to make it fit
tile 5/31/20 size is 529787 with detail 11, >500000
Going to try keeping 21.12% of the features to make it fit
tile 5/31/19 size is 621905 with detail 11, >500000
Going to try keeping 16.12% of the features to make it fit
tile 5/31/20 size is 503675 with detail 11, >500000
Going to try keeping 19.92% of the features to make it fit
tile 5/31/19 size is 544664 with detail 11, >500000
Going to try keeping 14.06% of the features to make it fit
tile 5/31/19 size is 511353 with detail 11, >500000
Going to try keeping 13.06% of the features to make it fit
Could not properly place hole to a parent.
Internal error: Polygon cleaning failed. Log in /tmp/wagyu.log

Contents of wagyu.log is:

Could not properly place hole to a parent.
[[[308,1234],[310,1234],[310,1236],[308,1236],[308,1234]],[[310,1234],[309,1235],[309,1234],[310,1234]],[[308,1235],[309,1235],[308,1236],[308,1235]],[[310,1235],[309,1235],[309,1234],[310,1235]],[[309,1232],[309,1231],[310,1232],[309,1232]],[[310,1232],[311,1232],[309,1231],[310,1232]],[[311,1233],[311,1232],[310,1233],[311,1233]],[[311,1232],[310,1232],[310,1231],[311,1232]],[[312,1232],[311,1232],[311,1231],[312,1232]],[[310,1234],[311,1233],[311,1234],[310,1234]],[[310,1235],[309,1234],[310,1234],[310,1235]],[[310,1234],[311,1234],[311,1235],[310,1234]],[[310,1235],[311,1235],[310,1236],[310,1235]],[[311,1234],[310,1234],[310,1233],[311,1234]],[[311,1234],[312,1233],[312,1234],[311,1234]],[[311,1234],[312,1235],[311,1235],[311,1234]],[[311,1235],[311,1236],[310,1235],[311,1235]],[[309,1235],[308,1237],[308,1236],[309,1235]],[[309,1238],[308,1237],[307,1238],[308,1237],[309,1238]],[[309,1239],[308,1239],[309,1238],[309,1239]],[[309,1237],[308,1238],[308,1237],[309,1237]],[[308,1239],[309,1239],[309,1240],[308,1239]],[[309,1239],[308,1240],[310,1239],[309,1239]],[[310,1236],[311,1237],[310,1237],[310,1236]],[[310,1237],[309,1238],[309,1237],[310,1237]],[[311,1236],[311,1235],[310,1236],[311,1236]],[[311,1236],[311,1237],[310,1236],[311,1236]],[[310,1238],[309,1238],[310,1237],[310,1238]],[[310,1239],[309,1239],[310,1238],[310,1239]],[[310,1240],[309,1239],[310,1239],[310,1240]],[[311,1238],[311,1237],[312,1238],[311,1238]],[[311,1239],[312,1238],[311,1238],[311,1239]],[[311,1239],[310,1238],[311,1238],[311,1239]]]

I have validated the source data in spatialite with Is_valid and all polygons are OGC valid.

Dataset used for the command is: https://www.dropbox.com/s/5fr0gxr8zs7jidt/nz_primary_parcels.geojson.gz?dl=1

Tippecanoe version: v1.34.3

[palmerj]

Another questions, why is tippecanoe warning about:

nz_primary_parcels.geojson:290347: Reached EOF without all containers being closed
In JSON object {"type":"FeatureCollection","name":"nz_primary_parcels","crs":{"type":"name","properties":{"name":"urn:ogc:def:crs:EPSG::4167"}},"features":[]}
nz_primary_parcels.geojson:338068: Found ] at top level

This geojosn file dataset has been created using ogr:

ogr2ogr -f GEOJSON nz_primary_parcels.geojson -t_srs EPSG:4167 nz-primary-parcels.gpkg

[e-n-f]

The warning is because -P makes Tippecanoe expect line-delimited GeoJSON, but your input file has a FeatureCollection wrapper around the whole thing. The warning is for the wrapper's extra '[' at the start and ']' at the end.

I'll download your data and see if I can reproduce the polygon problem.

[e-n-f]

Verified that this polygon still fails with the latest changes to Wagyu, so it is not just a matter of upgrading

[palmerj]

The warning is because -P makes Tippecanoe expect line-delimited GeoJSON, but your input file has a FeatureCollection wrapper around the whole thing. The warning is for the wrapper's extra '[' at the start and ']' at the end.

Ok thanks.

[palmerj]

Is there someway to see which feature caused this issue, so I can remove it and continue with my testing?

[palmerj]

Anything I can do to help here?

[e-n-f]

It looks like the failing feature is

id: 7203175
appellation: Lot 1 DP 422905
parcel_intent: Fee Simple Title

according to debugging output added in #763

[palmerj]

Thanks @ericfischer. I will check the feature. For the moment I've rolled back to tippecanoe v1.27.7 which is the last version I used that worked with this dataset.

[palmerj]

It looks like the failing feature is

Just looked at the feature. Looks pretty ok to me. Very simple parcel: https://data.linz.govt.nz/x/67w3HU

[e-n-f]

Thanks. That is very interesting that it used to work. Version 1.27.7 was quite a while ago, but it does include a different version of Wagyu, so I can look at what changed between those versions.

[palmerj]

Thank you.

[Darkfish]

Coincidentally I've just hit the same issue on the same dataset. Have you found any workarounds other than rolling back to v1.27.7 over the past few months?

[e-n-f]

Sorry, I haven't done anything on this, but I should probably just make it drop impossible holes instead of exiting with an error.

[cammanderson]

Hi All, I am encountering the same problem with a large set offered by the Australian Government (ABS mesh data blocks). Is there any plan to resolve this error or is the work around to downgrade to v1.27.7? Appreciate a potential fix to a more up to date version. Thanks!

[semmie1977]

Same problem here.

[arredond]

Also faced the same problem with US Census Blocks and can confirm that downgrading to v1.27.7 worked.

For Mac users (credit to this SO answer):

brew uninstall tippecanoe
brew extract --version=1.27.7  tippecanoe homebrew/cask
brew install [email protected]

[fischja]

@palmerj @Darkfish how were you able to resolve this issue?

@e-n-f I have the same issue in the new felt/tippecanoe repo.

[e-n-f]

@fischja Can you upload a copy of the data file you are having a problem with, and I'll take a look? I no longer have a copy of the nz_primary_parcels and the links above are broken.

[fischja]

@e-n-f are you able to access the data at this link: https://datafinder.stats.govt.nz/layer/111223-meshblock-2023-clipped-generalised/ ? If not I can try and upload the file directly.

[palmerj]

@fischja Can you upload a copy of the data file you are having a problem with, and I'll take a look? I no longer have a copy of the nz_primary_parcels and the links above are broken.

You can get the data again by downloading it from https://data.linz.govt.nz/data/?mv.basemap=Streets&mv.content=layer.50772. You need to login (free), select export in top right, and choosing a format like CSV or Geopackage. After that you can convert it to GeoJSON via OGR2OGR if required.

[e-n-f]

Thanks. I'm downloading it from Koordinates now.

[e-n-f]

I wasn't able to immediately reproduce the problem:

➤ ogr2ogr -f GeoJSONSeq /vsistdout/ /vsizip//Users/enf/Downloads/lds-nz-primary-parcels-SHP.zip/nz-primary-parcels.shp  | gzip > lds-nz-primary-parcels.json.gz
➤ ogr2ogr -f GeoJSONSeq /vsistdout/ /vsizip//Users/enf/Downloads/lds-nz-primary-parcels-SHP.zip/nz-primary-parcels.2.shp  | gzip > lds-nz-primary-parcels.2.json.gz

➤ ./tippecanoe --version
tippecanoe v2.26.1

➤ ./tippecanoe -zg -f -o foo.mbtiles  --no-feature-limit --no-tile-size-limit -P ../lds-nz-primary-parcels*json.gz
For layer 0, using name "ldsnzprimaryparcels2"
For layer 1, using name "ldsnzprimaryparcels"
2691608 features, 566704879 bytes of geometry, 120922410 bytes of string pool
Choosing a maxzoom of -z12 for features typically 195 feet (60 meters) apart, and at least 27 feet (9 meters) apart
Choosing a maxzoom of -z13 for resolution of about 47 feet (14 meters) within features
  99.9%  13/7936/5251  

Can you give an example of a data file and invocation that is failing for you?

[palmerj]

Hmm. It might be that the current dataset has now removed the failing record that was present in 2019. The original dataset is now long gone as cleaned up my dropbox account.

[e-n-f]

Thanks @palmerj. @fischja, are you still seeing failures?