#!/bin/sh
# vi:ft=
set -eux

false

>output.geojsons python3 update.py
/usr/bin/time ogr2ogr -progress output.fgb output.geojsons -fieldTypeToString All
435.00user 11.46system 7:44.82elapsed 96%CPU (0avgtext+0avgdata 348400maxresident)k
6344152inputs+3593840outputs (892major+111020minor)pagefaults 0swaps

 ¶ ls -lh output.*
-rw-rw-r-- 1 josh josh 917M Apr 12 15:38 output.fgb
-rw-rw-r-- 1 josh josh 1.1G Apr 12 15:26 output.geojsons
-rw-rw-r-- 1 josh josh 169M Apr 12 15:23 output.zip


t-rex wants to reproject stuff on the fly and gdal's like oh you're holding it wrong
so we should just pass -t_srs EPSG:3857 when building the FGB so it's ready.


strings end up like (1:Some Stuff) because some of those have an array so
gdal interprets them all as being an array so really we should json stringify
the properties before feeding it to gdal


oh hey gqis finally came back
1,942,396 Point
7 LineString
OK
gave up on letting it finish loading


ERROR 1: Full reprojection failed, but partial is possible if you define OGR_ENABLE_PARTIAL_REPROJECTION configuration option to TRUE
thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: OgrError { err: 6, method_name: "OGR_G_Transform" }', t-rex-gdal/src/gdal_fields.rs:434:50
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2023-04-12 12:45:21.690 INFO GET /ne_10m_admin_0_map_units/1/0/0.pbf HTTP/1.1 500 46 129.557000ms 127.0.0.1


serving the fgb still comes back with a billion attributes on each feature?


ah yeah and we come back with

Extent: (-9392582.035682, 2074195.199547) - (-2436200.965505, 6653078.941942)
Layer SRS WKT:
PROJCRS["WGS 84 / Pseudo-Mercator",

t-rex supports postgis queries but gdal is pretty spartan. could use the .vrt trick

probably don't want to use this t-rex software as is? maybe want to read the .fgb myself instead of going through gdal.

ok yeah giving it an EPSG:3857 .fgb is much faster
