[PROJ] proj-wasm 0.1.0-alpha9

[Will Cohen]

Oh neat. Last time I checked, there was still that service worker, but
yeah, it looks like it's totally unnecessary now. I thought that
SharedArrayBuffer (which, I THINK, is still being used internally by
emscripten when pthreads is turned on) always required those headers, but
it looks like you got it to work without, by keeping it in the one worker.
I'll need to think a little more about the effect this has on parallelizing
with multiple workers, and the memory / throughput comparisons with
pthreads. This is cool.

On Wed, Aug 26, 2026 at 3:59 PM Javier Jimenez Shaw <j1 at jimenezshaw.com>
wrote:

> 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/945ad0c5/attachment-0001.htm>