Refactor GeoPackage-JS lib with minimal dependencies to make it reusable

[sfkeller]

This is a feature proposal: Refactor GeoPackage lib with minimal dependencies to make it reusable in other JS code. That would help other projects and widen the community of this nice GeoPackage-JS project.

[brianbancroft]

+1

I tried using this library in a client application the other month, and have seen it as unsuitable for use in JS client apps due to its size. At 19.2MB size of this library is much larger than others and causes Parcel (a popular bundling/tree-shaking tool in the JS ecosystem) to crash when building with default settings.

[danielbarela]

I am fully on board with this. If anyone would like to take this task on and submit a pull request that would be great.

[andreasplesch]

I think it would be first necessary to think about how to refactor and/or split up the library. Perhaps along functionality:

• reading geopackage into javascript data structures: geojson for vector, arrays for raster ?
• manipulating: reprojection, adding/removing features
• writing: just geopackage ?
• conversion: writing/generating buffers for other formats
• rendering: canvas, ObjectURL, DataURL

Or along dependencies:

• sqlite3: reading/writing
• proj4: manipulating/rendering
• geojson: conversion
• canvas: rendering

Or app requirements:

• mapshaper: reading and converting to internal format ?
• my need: reading and reprojection to EPSG:4326, and perhaps webmercator, rendering, no manipulation or writing

How much of the large size is due to all the projections supported by proj4 ? Not much, proj4s is only 80kb

[kylebarron]

Looking the published example, gp.js is 4.2MB compressed and 18.1MB uncompressed, which is huge for a browser library.

In the loaders.gl project, we've reimplemented a minimal GeoPackage parser from scratch. We've only implemented reading of vector data, so it doesn't handle every edge case, but the JS part is 43KB minified and gzipped (including proj4.js), plus the sql.js wasm bundle, which is 333KB brotli compressed. That's 91% smaller than geopackage-js, so it might be a good reference for some people on this thread. Happy to share details or any other info if it would help.

[danielbarela]

That sounds like a good alternative for people with minimal needs. We are currently in the process of releasing a new version which should decrease the package size and I will report back to this thread when we are done. While library size is important, this library is meant to be a full and complete implementation of the entire spec and thus, library size does tend to increase due to that. Once again, I will report back on any library size improvements when we release the new version.