[PROJ] proj-wasm 0.1.0-alpha9

[Javier Jimenez Shaw]

Hi Will

On Wed, 26 Aug 2026 at 17:00, Will Cohen via PROJ <proj at lists.osgeo.org>
wrote:

> Hello all,
>
> An update on the grid fetching and worker questions from the January
> proj.js thread. The latest release of proj-wasm (0.1.0-alpha9,
> https://www.npmjs.com/package/proj-wasm) addresses them as follows:
>
> Grid fetching now works in browsers and Node.js without curl in the build.
> PROJ runs entirely inside workers, and grids come through PROJ's network
> callback API backed by synchronous HTTP requests, which workers permit. In
> Node.js, a small fetch worker bridges those synchronous callbacks to Node's
> async http.
>
> The WASM build is now fully single-threaded, with no pthreads. (Pthreads
> ends up requiring SharedArrayBuffer and COOP/COEP headers, which limits the
> usability of the WASM build to certain environments only.) Instead,
> parallelism now comes from a pluggable pool of workers, each running its
> own module instance, with PROJ contexts pinned to workers. The demo runs
> this pool with network grids enabled:
> https://willcohen.github.io/clj-proj/
>
> This is a slightly different path from Javier's
> https://github.com/jjimenezshaw/wasm-proj, which is exercising the
> ENABLE_EMSCRIPTEN_FETCH option from
> https://github.com/OSGeo/PROJ/pull/4627. I still like the idea of trying
> to use that -- it definitely seems cleaner and less like reinventing the
> wheel -- but I still want PROJ to be able to nab grids without requiring
> that webpages be served with a particular set of headers.
>

What headers are you talking about? I remember that at the beginning of my
research I had to deal with COOP/COEP headers (and we were talking about
it), but not when I published wasm-proj months ago (at least I removed that
part of the code). I am not using any SharedArrayBuffer to talk with the
web worker, just standard serializable messages. Am I missing any detail?
Maybe emscripten is doing that internally, but it is only starting the web
worker I explicitly start.


> I've also since moved this worker plumbing into reusable libraries (
> https://github.com/willcohen/clj-native and
> https://github.com/willcohen/worker-router), and proj-wasm can adopt an
> external pool the caller supplies. This is how backproj (live demo at
> https://willcohen.github.io/backproj/), which uses proj-wasm to
> back-project custom CRSes onto MapLibre, coordinates wasmts geometry
> operations (JTS compiled to wasm) and proj-wasm projection operations in
> one worker pool.
>
> Now that these are settled and the mechanisms to build and hook into PROJ
> on wasm are abstracted out, I plan to reuse them for a similar wasm build
> of GDAL, hopefully without re-embedding PROJ inside it.
>
> With PROJ, JTS (via wasmts), and eventually GDAL, I'm hoping that most GIS
> functionality can happen client side in the browser!
>
> Will
>

Thank you
Javier.


> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260826/71d1e30a/attachment.htm>