tippecanoe-decode produces invalid geojson file

[jmpmcmanus]

When I use tippecanoe-decode to convert mbtiles file to geojson file, like:

tippecanoe-decode cumberfldparallll.mbtiles 12 1151 1621 > tile.geojson

I get a geojson file that produces the following error message, when using http://geojsonlint.com/

Line 1: FeatureCollection object cannot contain a "properties" member Line 2: Feature object cannot contain a "features" member Line 2: GeoJSON features must have a type=feature member Line 2: "geometry" member required

I've not been able to read the geojson file using OpenLayers, because of the "properties" member in the FeatureCollection object. If I remove themL

"properties": { "zoom": 12, "x": 1151, "y": 1621 }, "features": [ { "type": "FeatureCollection", "properties": { "layer": "cumberfldparallll", "version": 2, "extent": 4096 },

I no longer get those error message in geojsonlint, and am able to read the file using OpenLayers. Is there a way of producing a mbtiles or geojson file with tippecanoe that does not have that information? I this an alternative standard for geojson?

Thanks Jim

[e-n-f]

You are correct, and I now see that the GeoJSON spec (https://tools.ietf.org/html/rfc7946) says:

   The GeoJSON "coordinates" and "geometries" members define Geometry
   objects.  FeatureCollection and Feature objects, respectively, MUST
   NOT contain a "coordinates" or "geometries" member.

   The GeoJSON "geometry" and "properties" members define a Feature
   object.  FeatureCollection and Geometry objects, respectively, MUST
   NOT contain a "geometry" or "properties" member.

   The GeoJSON "features" member defines a FeatureCollection object.
   Feature and Geometry objects, respectively, MUST NOT contain a
   "features" member.

I will change the tippecanoe-decode output format to use something other than properties to store the FeatureCollection metadata.

[jmpmcmanus]

Thanks!  Are they functional? On Tuesday, October 30, 2018, 1:24:19 PM EDT, Eric Fischer notifications@github.com wrote:

You are correct, and I now see that the GeoJSON spec (https://tools.ietf.org/html/rfc7946) says: The GeoJSON "coordinates" and "geometries" members define Geometry objects. FeatureCollection and Feature objects, respectively, MUST NOT contain a "coordinates" or "geometries" member.

The GeoJSON "geometry" and "properties" members define a Feature object. FeatureCollection and Geometry objects, respectively, MUST NOT contain a "geometry" or "properties" member.

The GeoJSON "features" member defines a FeatureCollection object. Feature and Geometry objects, respectively, MUST NOT contain a "features" member.

I will change the tippecanoe-decode output format to use something other than properties to store the FeatureCollection metadata.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[e-n-f]

They are there for information, because there is metadata for the tileset as a whole, metadata for each tile within the tileset, and metadata for each layer within the tile, before getting to the features themselves within each layer.

Changing the name of the properties is simple, but geojsonlint rejects nested FeatureCollections, so I need to figure out if that is correct, and, if it is, how else to represent the data hierarchy.

[stevage]

I just ran into this.

Yes, nested FeatureCollections definitely violate the GeoJSON spec. I doubt many tools would be able to handle it.

And alternatively, with the -c flag, it seems to produce newline-delimited GeoJSON.

Either way, not GeoJSON.

Personally, I would rather have valid GeoJSON, and give up the zoom level metadata.

An option might be to put an array of zoom level metadata on the overarching FeatureCollection metadata.

[neelakandan-dhanigachalam]

Any updates on the above issue? Me too encountered the same problem, when decoding geojson from mbtiles using tippecanoe-decode tool. Please assist.

[bartromgens]

They are there for information, because there is metadata for the tileset as a whole, metadata for each tile within the tileset, and metadata for each layer within the tile, before getting to the features themselves within each layer.

Changing the name of the properties is simple, but geojsonlint rejects nested FeatureCollections, so I need to figure out if that is correct, and, if it is, how else to represent the data hierarchy.

This metadata is not worth creating an invalid GeoJSON for me. The GeoJSON files don't work with OpenLayers and several other libraries.

1.19.2 is the latest release that produces valid GeoJSON in my project.

[e-n-f]

Do you have thoughts on how best to indicate the layer name and tile coordinates in output with no nesting? The other practical alternative that I can think of is to tag them with each feature, as tippecanoe-decode --tag-layer-and-zoom does.

[bartromgens]

I only use it to create single tiles (tippecanoe-decode file.mbtiles zoom x y) and thus don't need tile information. I can see the existing solution is best when there are multiple tiles and layers, but that depends on a use case I am not familiar with.