Re:Earth tech blog, applied

Publicado el 31 de octubre de 2026

The subject is the 23 Japanese-language posts listed on pages 1–3 of reearth.engineering (the English versions have the same content, so they were left out). For each post I read the body and compared it with the current geoportal code (main as of 2026-10-12, e1c5b43) to judge whether it can be used. Evidence in the code is given as file:line. Places marked "guess" are estimates that have not been confirmed by production measurement or by checking the code.

Conclusion

  • No post can be used as-is right away. Re:Earth is built on Cloudflare Workers, Go, Cesium and GCP. geoportal uses C#, MapLibre and deck.gl on a single VPS (memory cap 1.8GB), so there was no post whose tools could be brought over directly.
  • 11 posts have ideas that can be partly used. The one with the biggest expected effect is the cache design in "the post on generating terrain tiles on the fly". It stores tiles with the tile "version" in the key and returns 304 via ETag, and is expected to make tile delivery for external layers faster.
  • Weaknesses in the actual code were found in 2 places. One is that the MINEM monthly production archives are loaded entirely into memory to be extracted; the other is that deck.gl layers in the 3D view may be misaligned with the terrain.
  • The techniques explained in the 9 3D-rendering posts (RTC, culling, SSE, Draco, RTIN) are all already inside MapLibre, deck.gl and loaders.gl. There is no need to implement them ourselves.

Verdict list

Date — Post — Verdict — Where geoportal would use it

  • 2026-06-17 — Terrain tiles without pre-generation — Idea usable — Versioned cache and ETag for external layer tiles (priority 1)
  • 2024-06-21 — Extracting a 100GB zip with Go and GCS — Idea usable — Extract the MINEM monthly production archives via disk
  • 2025-01-31 — Polygons following terrain with a stencil — Idea usable — Check whether the H3 layer follows the terrain in the 3D view
  • 2025-12-19 — PLATEAU remote MCP server — Idea usable — Once there are users, expose the catalog, concessions and payments via MCP
  • 2024-07-24 — Screenshots with GPU runner + Playwright — Idea usable — Borrow only the method for judging that rendering has finished
  • 2024-10-11 — For GraphQL, TanStack Query — Idea usable — Candidate to replace useAsyncResource (not urgent)
  • 2026-01-23 — Fast, low-memory XML processing (gosax) — Idea usable — Mostly already practiced. Use when supporting WFS that returns only GML
  • 2025-07-15 — 3D model compression 1: Edgebreaker — Idea usable — Use Draco when delivering drone meshes
  • 2024-09-12 — LOD algorithms in 3DCG — Idea usable — Add LOD if the drillhole 3D view becomes heavy
  • 2024-07-08 — Heatmaps in Cesium — Idea usable — The ideas of log-scale coloring and contour lines
  • 2024-06-07 — Spatial partitioning in 3DCG — Idea usable — Use three-mesh-bvh if click picking becomes slow
  • 2025-11-14 — Vector tiles with DuckDB — Not usable — PostGIS ST_AsMVT already does the same thing
  • 2026-09-07 — Basemaps painted with a brush — Not usable — The cache-key idea is the same as in the terrain tile post
  • 2026-05-14 — Intro to RBAC (Cerbos) — Not usable — RLS carries the core of authorization
  • 2025-10-28 — High-precision rendering at global scale (RTC/RTE) — Not usable — Already implemented inside deck.gl and MapLibre
  • 2025-11-21 — 3D model compression 2: rANS — Not usable — A matter internal to libraries
  • 2024-11-20 — Terrain LOD with RTIN — Not usable — MapLibre terrain is a uniform grid
  • 2024-07-17 — Tile rendering with culling and SSE — Not usable — Already implemented in loaders.gl
  • 2025-04-11 — MongoDB on a stateful MIG — Not usable — We use neither MongoDB nor GCP
  • 2024-11-28 — Monorepo and Terraform — Not usable — We use neither Terraform nor CI
  • 2026-09-16 — Tempura (Google Cloud PAM) — Not usable — GCP has been cancelled
  • 2024-08-02 — Environment variables in nginx with envsubst — Not usable — We do not use nginx (with a side finding)
  • 2024-05-31 — A blog with Astro and Notion — Not usable — We do not have a blog

Tile delivery

As background, here is the current state of tile delivery in geoportal. Our own layers and imported external layers have their tiles generated on the fly by the PostGIS function core.render_tile (db/schema.sql:1141, FeatureRepository.cs:292-303). For external layers that are not imported, every tile request queries ArcGIS for the extent, converts the returned GeoJSON to MVT with ST_AsMVT, and returns it (TilesController.cs:593-632, FeatureRepository.cs:358-400). There is no server-side tile cache; there is only Cache-Control: max-age=300 for the browser (TilesController.cs:45). ETag is not used either.

Terrain tiles without pre-generation — assembling terrain meshes on the fly at the CDN edge — Idea usable — 2026-06-17 · Post · Priority 1

Key points of the post: Re:Earth Terrain generates terrain tiles (quantized-mesh, Terrarium, Terrain-RGB) on Cloudflare Workers for every request. The encoder is written in Rust and compiled to WASM. The source data is PMTiles, and only the needed ranges are read using HTTP Range GET.

What matters in this post is the cache design. The ETag is computed from the tileset name, version, format and z/x/y, and if If-None-Match matches, it returns 304 without generating. The cache has two tiers: the edge Cache API (tier 1) and R2 (tier 2). To retire old tiles, instead of deleting files, it bumps the version to switch the key prefix and cleans up the old ones with cron. The first generation takes about 2.4 seconds, but a cache hit returns in about 86 ms.

How geoportal would use it: Without using Cloudflare or R2, move only the caching idea into the C# tile delivery. Store external layer MVTs in the existing disk area filestore (line 191 of the compose file) under the name tiles/{layer_id}/{version}/{z}/{x}/{y}.mvt. The "version" is the ID of the last successful sync run for imported layers, and the date for layers that are not imported. On top of that, add ETag and 304 responses. The code's own comment says that the upstream of external layers changes only on a daily basis (TilesController.cs:44). So the current design, which fetches the same tile from upstream again and again, is considered very wasteful. The change is around TilesController.cs:253-286 and is expected to amount to little more than adding a read and a write (guess).

Costs and risks:

– Memory barely increases. Disk usage, on the other hand, grows, so setting a cap and cleaning up is essential. In the past the disk filled up and the DB was down for 25 hours.

– If the version key is wrong, old tiles keep being served. For a product whose core is showing changes, getting this wrong is fatal.

– The terrain-specific technology (quantized-mesh and the Rust encoder) is not used. That is because the 3D view is served well enough just by calling setTerrain on AWS Terrarium elevation tiles (basemaps.ts:73-81).

Before starting, measure, for external layers that are not imported, what share of a single tile's wait time is taken by the upstream response. The size of the effect has not been measured yet.

No pre-conversion needed! Loading GIS data into DuckDB and displaying vector tiles — Not usable — 2025-11-14 · Post

Key points of the post: The DuckDB in this post runs only inside the browser (DuckDB-WASM running in a Web Worker). The steps are: read GeoJSON with st_read(), convert to Parquet if needed, build an R-Tree index, and then call ST_AsMVTGeom and ST_AsMVT. The result is passed to MapLibre's addProtocol('duckdb', …). Reading an 800MB GeoJSON can take more than 30 seconds, and the limit per tile is 50,000 features. MultiPolygon cannot be handled, so it must be split with ST_Dump, and no cache is implemented.

Verdict for geoportal: MVT is already generated with the same PostGIS functions (FeatureRepository.cs:378-397), so adopting this post's approach would only mean replacing it with DuckDB. In the plan to keep diffs in files (under consideration since 2026-10-07), the concern was that "server-side DuckDB could exceed the 512MB cap", but this post is about the browser side, so it does not answer that concern. The only conceivable use is aggregating large files uploaded by users entirely within the browser, but that is not among the current requirements.

Costs: DuckDB-WASM and the spatial extension alone add tens of MB of dependencies (guess). It would also mean adding a parallel path for the same purpose.

Maps became pictures again — painting tiles with a brush the moment they are requested — Not usable — 2026-09-07 · Post

Key points of the post: The Rust rendering engine ezu and the brush engine hokusai are compiled to WASM and paint a picture-style basemap on Cloudflare Workers. ezu treats a style as a processing flow graph and draws by combining 85 kinds of processing components. The cache has three tiers: the browser (immutable, max-age=1y), the edge, and R2. Old entries are not deleted; they are invalidated by switching three versions: style, processing pipeline and data date. Unknown queries (such as ?cb=) are ignored so that the same picture does not get multiple URLs. Random numbers and label placement are determined from world coordinates and the 8 surrounding tiles, so tile seams do not shift. The first render takes 0.9–13.9 seconds; a cache hit takes 45–55 ms.

Verdict for geoportal: The basemaps read Esri and OSM rasters directly (basemaps.ts:57-68), and a mining business map has no need for a painterly look. Only two points can be borrowed: "put several independently movable versions into the key" and "do not split the cache key on unknown queries", and both can be included in the plan for applying the terrain tile post.

Sync, import and operations

A challenge toward fast, low-memory XML processing (gosax) — Idea usable — 2026-01-23 · Post

Key points of the post: gosax is a SAX-style (process-while-reading) XML parser written in Go that does not hold the whole input in memory. It is made fast by passing data without copying, avoiding heap allocation by not using interfaces, expressing state transitions as functions, and finding delimiters with SIMD/SWAR. In a test counting the elements of a 223MB XML, Go's standard encoding/xml took 3.09 seconds, while gosax took 0.22 seconds. It is used for PLATEAU's CityGML processing.

Current state of geoportal: I was worried that we might be loading large XML entirely into memory, but that was not the case. WFS features are received as GeoJSON (OgcFetch.cs:285) and read one at a time with Utf8JsonReader (ArcGisFetch.cs:880-885). Only metadata such as GetCapabilities is loaded whole into a DOM as XML (OgcFetch.cs:70-84, 330-334). xlsx is already processed while reading with XmlReader (TabularParsers.cs:75, 115).

Proposed application: The .NET counterpart of gosax is XmlReader. Use it only in the following two cases. One is if measurement shows that Capabilities reach tens of MB; in that case, switch to extracting only the needed elements while reading. SENAMHI's WMS has 1,199 layers, but the size of its Capabilities has not been measured. The other is if it becomes necessary to support a WFS that responds only in GML.

Costs: The processing that assumes the current tree structure (Child and Walk in OgcFetch.cs) would be rewritten as a state machine, so the code would become longer and harder to read. Metadata is read only once per run, so there is almost no speed benefit.

Extracting a huge 100GB zip file with Go and GCS — Idea usable — 2024-06-21 · Post

Key points of the post: At first the whole archive was read into memory and extracted, which made about 4GB the limit. This is because Go's zip requires an input that can be read at arbitrary positions. So they changed to writing to disk before extracting, and ran a flow of extracting one file, uploading it and deleting it, while limiting the degree of parallelism. The processed position is recorded so that, if interrupted, it can resume from where it left off. They say they were ultimately able to extract zips of up to 500GB.

Current state of geoportal: A weakness matching this post was in the actual code. The MINEM monthly production import receives the per-year archive whole into memory with ReadAsByteArrayAsync (UpstreamHttpClient.cs:503-517). It opens that with a MemoryStream and also copies the xlsx inside entirely into another MemoryStream (TabularParsers.cs:22-48). On top of that, it keeps accumulating the rows for all years into a single list (DataFileSource.cs:408-420). The worker's memory cap is 512MB (line 132 of the compose file). Note that orthophoto uploads are already written to disk in chunks and can resume midway (LayersController.cs:1250).

Proposed application: Change the receive to ResponseHeadersRead and write the body directly to a temporary file on filestore. Open ZipArchive and SevenZipArchive with a FileStream, extract the xlsx inside to a temporary file as well, and delete it when done.

Costs: Creating and cleaning up temporary files adds a few dozen lines. If the 7z is in solid format, it must be decompressed from the beginning up to the target file, so the time does not get shorter. The actual size of the archives has not been measured. I guess a monthly table is a few MB to a few tens of MB, so the worker's peak memory should be measured in production first.

Building a MongoDB replica set on Google Cloud stateful MIG for zero-downtime rolling updates — Not usable — 2025-04-11 · Post

This is a method for running MongoDB replication yourself on Google Cloud stateful MIG (a mechanism that replaces instances while keeping disks, names and internal IPs), placing a vote-only node (Arbiter) in another zone, and updating without downtime. geoportal does not use MongoDB; the DB is a single PostGIS container (postgis/postgis:16-3.4, 512MB of memory). GCP has been cancelled and production is a single VPS. There are not enough machines or memory to replicate, and with no users yet the policy is that it is fine to stop it, so there is nothing to borrow.

Terraform with a monorepo and GitHub Actions — CI/CD optimization that uses side effects — Not usable — 2024-11-28 · Post

This is a technique where, when a shared Terraform component (module) changes, the environments that use it are considered changed too, and terraform plan/apply for those environments runs automatically. geoportal uses neither Terraform nor CI; what is built on a Mac is carried over ssh and deployed with compose. There is also only one environment, so there is no practical benefit.

Tempura — multi-provider privileged access management built on Google Cloud PAM — Not usable — 2026-09-16 · Post

A service that receives Google Cloud PAM approval and expiry events and calls Terraform providers directly to grant and revoke temporary permissions for DB users and GitHub teams. geoportal has neither GCP nor PAM, and the only operator is Hal. In the future, when temporarily handing admin permissions to customers or outside collaborators, the idea of "grant with an expiry and revoke reliably" will be a useful reference.

Embedding environment variables into an nginx Docker image with envsubst — Not usable — 2024-08-02 · Post

The official nginx image expands ${VAR} in /etc/nginx/templates/*.template at startup. Also, by creating config.json in a script under /docker-entrypoint.d/, even a static frontend can read settings at runtime. geoportal's frontend is served not by nginx but by the Next.js standalone server (Dockerfile.next:20-33), so this cannot be used as-is.

A separate problem was found during the investigation. The compose file passes NEXT_PUBLIC_API_BASE: /api at runtime (line 152 of the compose file). However, Next.js embeds NEXT_PUBLIC_* into the code at build time, so this setting is probably not taking effect. The default in the code is also /api (frontend/src/lib/api.ts:56), so for now there is no actual harm (this is a guess; the build output has not been checked).

Building an engineering blog with Astro and Notion — Not usable — 2024-05-31 · Post

A system (Astrotion) that uses Notion as the place for drafts and builds a static blog at Astro build time. It caches Notion API responses per block and also generates OGP images automatically. geoportal has no blog, and the public sites for customers are built from content the site builder saves in the DB (SitesController). There is nothing to borrow.

Authorization, AI integration and frontend

Intro to RBAC: how Re:Earth implements authorization — Not usable — 2026-05-14 · Post

Key points of the post: Cerbos is a service that uses YAML policies to decide "whether this person may perform this operation on this resource". At Re:Earth, each service defines resources, operations and roles in Go, and CI generates YAML from them and distributes it to Cerbos on Cloud Run. Each service queries the "account service" with a JWT, and the account service looks up per-workspace roles from the DB and has Cerbos decide. The post says they adopted neither OPA, because its learning cost is high, nor a home-grown solution, because it would require building everything down to audit logs.

Verdict for geoportal: The core of authorization in geoportal is "which rows are visible", and PostgreSQL RLS decides that. db/schema.sql has 32 occurrences of ENABLE ROW LEVEL SECURITY and 50 of CREATE POLICY. The API sets app.organization_ids per connection (DatabaseSession.cs:150-157). Cerbos can only answer whether an operation is allowed, so it cannot replace RLS. Even for whether an operation is allowed, the scale is just 4 roles checked in one place, AdministratorGate (Authorization.cs:13, 21-70). Introducing it would add one resident process and mean holding authorization in two places, so discrepancies between them would become a new source of incidents.

Search PLATEAU data with AI! We released a remote MCP server — Idea usable — 2025-12-19 · Post

Key points of the post: An MCP server that makes the MLIT PLATEAU data usable from LLMs, published without authentication. There are 3 kinds of tools: catalog search (region, dataset, data type), CityGML search (looking up URLs and building attributes from mesh codes, spatial IDs or lat/lon rectangles), and retrieval of the specification's table of contents and sections. The example implementation uses Go's mcp-go and places Streamable HTTP in stateless mode at /mcp.

How geoportal would use it: The way the tools are divided applies directly to geoportal. The catalog maps to sync.catalog (about 12,000 layers), regional search to search by RUC or concession code, and the specification to the articles of mining law. The catalog and search APIs already exist (/sync/catalog and /records/search in openapi.yaml). Add one /mcp endpoint to the existing ASP.NET Core API and expose 3–5 tools with the official MCP SDK for C#. What matters is running the tools through the existing DatabaseSession. That way RLS applies as-is and no separate authorization path is needed.

Costs and timing: Concessions and payments are per-organization data, so they cannot be published without authentication. OAuth or API keys must be prepared for MCP clients. The current cookie authentication cannot be used as-is. Since there are no users yet, work will start once there are users. "Consultants can look up concessions from AI" could become a differentiator when selling (guess).

Not just Apollo Client! Why TanStack Query is recommended for GraphQL — Idea usable — 2024-10-11 · Post

Key points of the post: A post about dropping Apollo Client and moving to a setup that wraps typed functions generated with graphql-request and codegen in TanStack Query. The reason given is that TanStack Query can handle any function that returns a Promise, so the code barely changes even when switching to REST. The cache is managed with queryKey and staleTime, and on updates the cache is rewritten directly with setQueryData. The post's sample code has an error that references an undefined variable.

Current state of geoportal: GraphQL is not used. Types are generated from OpenAPI, and the client is gathered in one file, frontend/src/lib/api.ts. List screens load data with a 38-line home-grown hook, useAsyncResource (8 screens). Changes to the layer list are announced to each screen with a home-grown event, announceLayersChanged (api.ts:97). Direct fetch calls that do not go through api.ts also remain in the site builder and signup.

Proposed application: Replace useAsyncResource with useQuery and announceLayersChanged with invalidateQueries(['layers']), and delete the old mechanism in the same change. Where the viewer and the drawer fetch the same layer or the same run repeatedly, traffic would drop. However, the current 38 lines are sufficient, so the gain is small. It is enough to introduce it once double fetching or inconsistent display actually becomes a problem.

Taking screenshots of a Cesium application with GitHub GPU runners and Playwright — Idea usable — 2024-07-24 · Post

Key points of the post: They run Playwright on GitHub GPU runners (T4, about $0.07 per minute), capture the Cesium screen and compare it with the previous image. networkidle takes about 60 seconds, so they do not use it. Instead, they take screenshots at a fixed interval and consider rendering finished when there is no change 3 times in a row. On ordinary runners without a GPU it reportedly took more than an hour.

Verdict for geoportal: geoportal has no CI, and scripts/gates.sh does not check the screen. Past UI defects have mostly been visual problems such as a single line of CSS, so screen comparison itself has value. GPU runners, however, are overkill. What we borrow is only the method for judging that rendering has finished, and MapLibre's idle event would judge it more reliably (guess). The production VM is shared with magicform, so running Chromium should be limited to short, one-off runs. Basemaps and upstream WMS change daily, so exact-match comparison is not possible. The map area must be masked, or a tolerated difference threshold must be set for the comparison.

3D rendering

As background, here is the current state of 3D in geoportal. Cesium is not used. The 3D viewer is simply the same MapLibre map as in 2D, with elevation applied via setTerrain and tilted 60 degrees (MapStage.tsx:251-264). deck.gl draws overlaid on the same canvas, and the only layer used is H3HexagonLayer for density display (useDensityLayer.ts:116-123). @deck.gl/mesh-layers and @deck.gl/extensions are installed but not used anywhere. The drillhole 3D view is a separate three.js screen that draws in local coordinates with the mean hole position as the origin, and the intervals are combined into a single InstancedMesh (Sondajes3D.tsx:258, 450-484).

Rendering polygons that follow the terrain using the stencil test — Idea usable — 2025-01-31 · Post · Worth checking now

A technique that draws a polygon as a solid sandwiching the terrain from above and below. It adds to the stencil value on back faces, subtracts on front faces, and fills only pixels whose value is not 0. This avoids both moving vertices to match the terrain, which is computationally heavy, and baking into a texture, which has resolution and memory problems.

When terrain is enabled, MapLibre draws 2D layers into textures per tile and drapes them over the terrain (maplibre-gl-dev.js:64986, 70998), so layers such as concessions already follow the terrain. What has not been confirmed is deck.gl's H3 layer, which is drawn at height 0, so in mountainous areas it may be buried in the ground or floating. First capture the H3 layer in the 3D view to check, and if it is misaligned, add deck.gl's TerrainExtension or move the density display to a MapLibre layer. We will not build the stencil approach ourselves.

Rendering models with high precision in global-scale scenes (RTC / RTE) — Not usable — 2025-10-28 · Post

GPUs compute in 32-bit floating point, so drawing global-scale coordinates as they are makes vertices jitter. RTC holds coordinates as offsets from the tile center; RTE splits coordinates into high and low values and takes the difference from the camera in the shader. deck.gl automatically switches to the offset-from-center approach at high zoom (project.glsl.js:160-175 in @deck.gl/core, WEB_MERCATOR_AUTO_OFFSET). The drillhole 3D view also uses the mean position as the origin, so it is already in RTC form. When placing drone models with deck.gl in the future, specifying coordinateSystem: METER_OFFSETS will be all that is needed.

Techniques for compressing 3D models 1: Edgebreaker — Idea usable — 2025-07-15 · Post

An algorithm that replaces the connectivity of a triangle mesh with 5 symbols, C, L, E, R and S, compressing it to an average of under 2 bits per triangle. Google's Draco uses it, and Eukarya is developing draco-oxide, a Rust version of Draco. geoportal does not handle 3D models at present. If we come to deliver drone photogrammetry meshes, we will Draco-compress glTF with gltf-transform or similar and read it with loaders.gl's DracoLoader, which is already among the dependencies. There is no need to write the algorithm ourselves.

Techniques for compressing 3D models 2: what is rANS — Not usable — 2025-11-21 · Post

rANS is a kind of compression method that assigns codes according to a probability distribution (entropy coding); it is as fast as Huffman coding and achieves compression ratios close to the theoretical limit. Draco, JPEG XL, AV1 and Zstd use it. There is no situation where geoportal would use it directly; if used at all, it would be indirectly through Zstd or Draco.

What is RTIN, which builds hierarchical LOD in real time — Not usable — 2024-11-20 · Post

A way of building terrain meshes that keeps splitting a square into right isosceles triangles and refines only where the elevation interpolation error exceeds the tolerance. The post says about 10,000 vertices could be reduced to about 1,000 in flat areas. MapLibre's terrain is not RTIN but a uniform 128×128 grid (maplibre-gl-dev.js:70530). What uses RTIN (martini) is @loaders.gl/terrain, which deck.gl's TerrainLayer uses. Dropping MapLibre's terrain for TerrainLayer would go against the policy of sharing the same state between 2D and 3D, so we leave it as it is.

LOD algorithms in 3DCG — Idea usable — 2024-09-12 · Post

A post comparing DLOD, which switches level of detail in steps (three.js LOD); CLOD, which changes it continuously; HLOD, which draws distant models together; the approach that turns a mesh into a tree of small clusters, like Unreal Engine's Nanite; and RTIN for terrain. The drillhole 3D view is already combined into a single draw call with InstancedMesh. If holes number in the tens of thousands and it gets heavy, switch distant cylinders to lines with three.js LOD.

Optimizing tile rendering on the Earth ellipsoid with culling and SSE — Not usable — 2024-07-17 · Post

It explains managing tiles in a quadtree, excluding tiles outside the screen and tiles beyond the horizon (culling), and determining level of detail by converting geometric error into on-screen pixel error (SSE). MapLibre selects only the visible tiles even from a tilted viewpoint. When using 3D Tiles, @loaders.gl/tiles computes SSE through deck.gl's Tile3DLayer. When showing drone 3D Tiles, adjusting maximumScreenSpaceError will be all that is needed.

Rendering beautiful heatmaps fast in Cesium — Idea usable — 2024-07-08 · Post

A method that turns a table of values into an image with Canvas and passes GLSL to a Cesium material to draw interpolation, log scale, matplotlib color maps and contour lines. It uses GroundPrimitive to follow the terrain. Since we have no Cesium, the implementation cannot be used as-is. Density display is already done with H3, and MapLibre also has a standard heatmap layer. What we borrow is the idea of log scale and contour lines; for example, coloring grades on a log scale can be written with MapLibre's interpolate expression.

Data structures and mechanisms for spatial partitioning in 3DCG — Idea usable — 2024-06-07 · Post

It compares data structures for partitioning space so that only nearby objects are compared with each other. The subjects are grids, quadtrees, octrees and BVH (three-mesh-bvh in three.js). On geoportal's server side there is the PostGIS GiST index, and the map uses a tile quadtree, so both already follow this idea. Drillhole click picking checks all intervals in turn (Sondajes3D.tsx:551). If intervals exceed tens of thousands and clicks become slow, add three-mesh-bvh. So far there is no measurement showing it is slow.

What to do next

Order — Task — Condition to start

The figures from the posts were taken from summaries that an agent read with WebFetch. Figures such as "from 976 minutes to 9 minutes for 270,000 files" in the "100GB zip" post may have been filled in at the summarizing stage, so check the original before quoting them.

  • 1 — For external layers that are not imported, measure what share of a single tile's wait time is taken by the upstream response. If it is large, add the versioned disk cache and ETag — Depends on the measurement
  • 2 — In the MINEM monthly production import, measure the worker's peak memory and the actual size of the archives. If they are large, switch to extraction via disk — Depends on the measurement
  • 3 — Capture the 3D view to check whether the H3 density layer follows the terrain — Can be done now
  • 4 — Expose the catalog, concessions and payments via MCP — Once there are users

Sources

  • Re:Earth tech blog, https://reearth.engineering/ (pages 1–3, 23 Japanese-language posts).
  • 3ARWS.NET, Re:Earth tech blog, applied: https://3arws.net/notes/reearth-tech-blog.en.html