[PROJ] PROJ7 in JavaScript

[Howard Butler]

> On Oct 2, 2020, at 8:21 PM, Richard Greenwood <richard.greenwood at gmail.com> wrote:
> 
> I am mistaken regarding web assembly support in Node. https://www.joyent.com/blog/improved-wasm-support-coming-to-node <https://www.joyent.com/blog/improved-wasm-support-coming-to-node>
Yes. Emscripten will also degrade to plain JavaScript as well, so that is an option for runtimes that can't consume wasm.

> On Fri, Oct 2, 2020 at 1:43 PM Richard Greenwood <richard.greenwood at gmail.com <mailto:richard.greenwood at gmail.com>> wrote:
> Proj 6 and 7 don't really add any new functionality. Proj does forward in inverse projections and it does datum transformations with 3 & 7 parameters transforms and grid shift transforms. Proj4js supports most of the commonly used projections and the 3 & 4 param datum transforms.

Proj4js doesn't support WKTv2 consumption or emission, and it doesn't support PROJJSON [1].  At the very least, interoperability suffers when crossing the proj4js boundary when trying to communicate coordinate system descriptions.

> It doesn't support grid shift transforms and grid shift transforms are what are "heavy" in terms of the size of the required data. I thought a lot about adding grid shift support and considered a server-side option like Javier mentions, but it's a lot of moving parts for pretty limited use cases. Like how many web mapping apps need the precision of a grid shift transform? And for those that do, how do you build a generic enough mechanism to cover the variations in scale, platform, online/offline, etc.?

I think the combination of COGs at cdn.proj.org <http://cdn.proj.org/> and geotiff.js would allow for the construction of JavaScript support for high performance incremental grid access similar to the current PROJ runtime's incremental implementation. There would be no need to cache GBs of grid files, and the data is hosted today as web native as you can get as COGs in CloudFront. 

I think it is a mistake to see JavaScript support as only "web mapping apps". I think a WASM port of PROJ is a worthy goal for a number of reasons, but the community has to want it bad enough to invest to make it happen. To date, that hasn't been demonstrated.

Howard

[1] https://proj.org/specifications/projjson.html <https://proj.org/specifications/projjson.html> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201003/024b528d/attachment-0001.html>