Cache parsed GPX/FIT GeoJSON to fix large POI-export loads
A several-thousand-waypoint park4night area export re-parses the whole file with REXML on every toggle — ~2.4s for a 5k-waypoint/3.6MB sample, so tens of seconds for a 50k-waypoint one, likely the actual cause behind a "Could not load" report on a 41.5MB export. MapLibre already clusters the waypoint layer client-side, so the bottleneck was never rendering — cache the GeoJSON conversion alongside the source file (invalidated by mtime) instead of a bigger bbox/tiling rework.
This commit is contained in:
1 parent
b6a9c1546e
commit
ddf2ee4990
4 files changed
+94
-9
No files matched your search
@@ -251,7 +251,12 @@ Rendering:: Checking a file fetches `GET /api/gpx/file/<path>`, routed
|
||||
by extension to `Maptool::Gpx` or `Maptool::Fit`
|
||||
(`lib/maptool/gpx.rb`/`fit.rb`) for parsing, and both convert to the
|
||||
same GeoJSON `FeatureCollection` shape so the frontend doesn't need to
|
||||
know which format it got. `Gpx` parses the GPX with REXML: `<wpt>`
|
||||
know which format it got. `GpxStore#geojson` caches that conversion
|
||||
alongside the source file (`<path>.geojson`, invalidated by mtime) —
|
||||
REXML parsing a several-thousand-waypoint POI export (a park4night
|
||||
area export, say) can take tens of seconds, and without a cache that
|
||||
cost repeats on every single toggle rather than just the first one
|
||||
after a save. `Gpx` parses the GPX with REXML: `<wpt>`
|
||||
waypoints become `Point` features (with `name`, `desc` and `time`
|
||||
carried through as properties), each `<trk>` becomes one
|
||||
`MultiLineString` feature (one line per `<trkseg>`), and each `<rte>`
|
||||
|
||||
Reference in new issue
Block a user