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 [email protected] 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.