Possibility to use other projections ?

[flemmens]

Would it be possible to use other projections than 4326 for the JSON sources ? Especially 3857 could be very useful as this is the standard projection of OSM and many other geographic resources. For now time is lost in converting these sources from 3857 to 4326 before using in tippecanoe.

[e-n-f]

Internally and in the output tiles everything is essentially converted to EPSG:3857 anyway, although with the size of the world plane considered to be 2^32 instead of whatever the EPSG:3857 unit is (meters?). (I'm not sure what you mean about OSM, though: planet.osm coordinates are written in WGS84 degrees in the XML.) The main concerns I have are:

• Non-WGS84 CRSes are deprecated in GeoJSON so what's the best way to talk about them? As another command-line option?
• I'm not sure how to handle a wide variety of projections without having to drag in a gigantic library like GDAL

If the "how to talk about it" problem is addressed, though, the "how to do it" problem could be a handful of special cases for the few projections that anyone is likely to care about in practice.

[flemmens]

Internally and in the output tiles everything is essentially converted to EPSG:3857 anyway

That is precisely my point, 3857 is the standard projection used by all tiled maps and it would be more logical to use it as default than 4326, we could avoid a lot of conversions and speed-up the whole process. By OSM I mean OpenStreetmap and all derivated products, usually GIS OSM data are stored in 3857 since this is the "natural" projection for this map. And most of the time, when you import a PBF planet data (for instance to PostGIS with imposm) you will get 3857 by default.

I don't think other projections than 3857 or 4326 would be useful, it is easy to convert any file with ogr2ogr or similar tools, it just takes more time. But as you said, if you have to convert the data in 3857 anyway to output the tiles, it make sense to be able to use this projection for the source data as well.

Of course this is just a suggestion, your program works great and the extra step to convert my data to 4326 is not a big deal, but I guess other people would be interested in this.

[e-n-f]

I don't think I've ever actually seen a shapefile or GeoJSON file that is projected in EPSG:3857. I think I have only seen it used implicitly in tiles. Tippecanoe uses WGS84 not because it is very common, not because I think it is necessarily the right thing for all data to use.

If you can point me to some sample GeoJSON files that use EPGS:3857, I can look into adding support for it. It would be valuable to have a lossless input format that doesn't suffer from the rounding errors that sometimes come from WGS84 conversion.

[anandthakker]

Hi @ericfischer -- I don't have an example of something like this, but I'm starting some research into what it would take to render non-web-mercator maps with mapbox gl js.

My (possibly naive) thinking is that, as long as the world can be projected onto a square coordinate system, vector tiles shouldn't really "care" how it got there, and once the geometries are encoded in vector tiles, gl-js will be happy to render them.

What would you think about something like a --raw-coordinates option, wherein the input is expected to look just like GeoJSON, but the coordinates are assumed to be already projected onto a 2^32 x 2^32 plane? I know it's a little weird since it would no longer be compliant GeoJSON, but that seems inevitable unless/until it becomes worthwhile to support non-GeoJSON inputs.

[e-n-f]

Totally true @anandthakker—nothing on the rendering side actually cares what the original projection was. Maybe just passing coordinates through like you say is the best thing to do. Non-WGS84 coordinates in GeoJSON are just deprecated, not undefined, so I think that's OK.

[anandthakker]

@ericfischer cool! Happy to put in a PR for this, but given how long it's been since I've touched a C/C++ project, it will probably be quite a while before I'll have enough time to sit down and grok how the pieces fit together here well enough to do so properly. Will do so if you don't beat me to it in the next few weeks!

[e-n-f]

Working on this in #253

[e-n-f]

OK, --projection=EPSG:3857 works now.

[anandthakker]

Thanks @ericfischer !

[wandergis]

This is so cool! 👍