[PROJ] PROJ7 in JavaScript

Lesparre, Jochem Jochem.Lesparre at kadaster.nl
Sat Oct 3 12:16:58 PDT 2020


At the Dutch NMA, I have had questions on the possibilities to do the Dutch transformation including precise datum transformation using the horizontal and vertical grid shift files in Java or JavaScript. So, I agree with Howard that there would be demand for PROJ in JavaScript.

Regards, Jochem


From: PROJ <proj-bounces at lists.osgeo.org> On Behalf Of Howard Butler
Sent: zaterdag 3 oktober 2020 15:19
To: Richard Greenwood <richard.greenwood at gmail.com>
Cc: proj <PROJ at lists.osgeo.org>
Subject: Re: [PROJ] PROJ7 in JavaScript




On Oct 2, 2020, at 8:21 PM, Richard Greenwood <richard.greenwood at gmail.com<mailto: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

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


Disclaimer:
De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.
Gebruik van de inhoud van dit bericht door anderen zonder toestemming van het Kadaster
is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan verzoeken wij u
dit direct te melden aan de verzender en het bericht te vernietigen.
Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.

Disclaimer:
The content of this message is meant to be received by the addressee only.
Use of the content of this message by anyone other than the addressee without the consent
of the Kadaster is unlawful. If you have received this message, but are not the addressee,
please contact the sender immediately and destroy the message.
No rights can be derived from the content of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20201003/5822fbf3/attachment.html>


More information about the PROJ mailing list