|
| 1 | +### geos/wasm |
| 2 | + |
| 3 | +GEOS and WebAssembly. |
| 4 | + |
| 5 | +Braindump: |
| 6 | + |
| 7 | +I don't think WebAssembly will constitute a big performance advantage for |
| 8 | +geographical operations. However, what I do want is battle-tested geometry |
| 9 | +operations. I love Turf, and continue to contribute to Turf, but a lot of Turf's |
| 10 | +geometry algorithms are implemented from scratch and aren't nearly as robust as |
| 11 | +GEOS. |
| 12 | + |
| 13 | +Then Turf uses JSTS for a few of its operations. JSTS - JavaScript port of JTS, |
| 14 | +which is a port of GEOS - has gotten a lot better. Maybe JSTS is the real best |
| 15 | +option: it gives roughly the code of GEOS, albeit removed two steps from the |
| 16 | +original, but doesn't have the full serialization cost of a WASM library. |
| 17 | + |
| 18 | +That said, JSTS is large - we've been trying to remove it from Turf for years |
| 19 | +and years, and it's not _exactly_ the same set of bugs as GEOS. If I have bugs, |
| 20 | +I want all of the GEOS things to have bugs! And the roaring success of, say, |
| 21 | +Shapely, indicates that GEOS's level of bugs is pretty tolerable. |
| 22 | + |
| 23 | +So, the goal of GEOS/WASM is that maybe: |
| 24 | + |
| 25 | +- We can get the same features/bugs as GEOS, with fewer steps to the source than |
| 26 | + JSTS. |
| 27 | +- We can just use GEOS for a lot of stuff. |
| 28 | +- Maybe it'll be fast, or small? I don't really know, this is all TBD. I've |
| 29 | + tinkered with WebAssembly but don't know that much about it. |
| 30 | + |
| 31 | +## Other routes |
| 32 | + |
| 33 | +- Maybe rust-geo is robust? But it [doesn't have |
| 34 | + buffering](https://github.com/georust/geo/issues/641), so probably a no-go. |
| 35 | + |
| 36 | +## Implementation options |
| 37 | + |
| 38 | +- Emscripten: oldest and most established option. |
| 39 | +- Zig: I like Zig, and maybe this would make the toolchain simpler, and I'd much |
| 40 | + prefer to write Zig than C or C++. But on the |
| 41 | + other hand, maybe it'd make the process way less documented. |
| 42 | +- Clang: looks like it does WASM directly, too. Looks like Emscripten _uses_ |
| 43 | + LLVM's native support now. |
| 44 | + |
| 45 | +## Notes |
| 46 | + |
| 47 | +Okay, so step one is as painful as expected. Getting the basic GEOS example to compile |
| 48 | +using any tool is hard. I can't get it compiled with Zig, Emscripten or cc. It's because |
| 49 | +of import paths and stuff. I haven't messed with C in ages. |
| 50 | + |
| 51 | +Looks like there are other people compiling GEOS as a prereq for other stuff. |
| 52 | + |
| 53 | +- https://github.com/bugra9/gdal3.js |
| 54 | + |
| 55 | +Okay, so far seeing: |
| 56 | + |
| 57 | +- I'll need to compile GEOS first, then compile the bindings per the [docs](https://emscripten.org/docs/compiling/Building-Projects.html#using-libraries). |
| 58 | + Trying to compile GEOS separately isn't working yet. |
| 59 | + |
| 60 | +``` |
| 61 | +CXXFLAGS="-fexceptions -DRENAME_INTERNAL_LIBTIFF_SYMBOLS -s ERROR_ON_UNDEFINED_SYMBOLS=0" CFLAGS=" -fexceptions -DRENAME_INTERNAL_LIBTIFF_SYMBOLS -s ERROR_ON_UNDEFINED_SYMBOLS=0" emconfigure ./configure --enable-shared=no --disable-inline |
| 62 | +``` |
0 commit comments