RFC: SMHI STRÅNG irradiance + Lantmäteriet roof geometry for PV prediction, performance scoring & map-drawn arrays

[HuggeK]

Status — 2026-07-31. Implemented, and open as four stacked draft PRs:
#718 plane-of-array wiring ·
#734 STRÅNG + source coverage ·
#735 roof geometry + building picker ·
#736 optional vostok shading.

Where the implementation departed from the proposal below, it is recorded in the
comments rather than edited into this text:
why it became four PRs, and what probing STRÅNG's live API settled
· why you now pick a building first.

Summary

This RFC proposes using two Swedish open-data sources to sharpen FTW's PV modeling:

1. SMHI STRÅNG — modelled solar irradiance, to (a) score how real panels actually performed against a weather-expected baseline, and (b) calibrate the forward PV predictor.
2. Lantmäteriet open geodata — building footprints + LiDAR — to derive roof tilt/azimuth automatically and let users draw their panels on a map instead of typing tilt/azimuth by hand.

Everything is additive and optional; nothing changes the control tick, dispatch, or the optimizer contract.

What FTW already has (so we build on it, not around it)

• A forecast.Provider interface with met_no, openweather, open_meteo (shortwave), forecast_solar (multi-plane PVGIS); results persist to a forecasts table that already has a solar_wm2 column.
• sunpos.POA(t,lat,lon,tilt,az) — plane-of-array physics already in-tree, but currently driven by its own clear-sky model and not wired into the twin.
• A self-learning PV twin (RLS + residual σ) and an MPC whose Python optimizer already accepts pv_w per slot plus a robust pv_low_w / pv_high_w band.
• config.Weather.PVArrays[] = {name, kWp, tilt_deg, azimuth_deg}, edited today in the Weather settings tab with a Leaflet point-picker + a Three.js 3D preview.
• Tiered history_* tables + DailyEnergy() giving measured PV Wh/day.

Key finding: STRÅNG is historical, not a forecast

STRÅNG is an analysis/reanalysis product (hourly, ~2.5 km, 1999→present, ~1-day lag, CC BY 4.0, no API key). It has no forward horizon. So its value is not "STRÅNG predicts tomorrow" — it is:

• a high-quality historical irradiance truth to score PV performance, and
• a calibration / warm-start source for the existing forward predictor.

Forward forecasting stays on open_meteo / forecast_solar / SMHI metfcst.

STRÅNG API specifics & the SMHI forecast-API migration

Point time-series REST:
https://opendata-download-metanalys.smhi.se/api/category/strang1g/version/1/geotype/point/lon/{lon}/lat/{lat}/parameter/{p}/data.json
with from / to / interval. Parameters: 117 = Global irradiance (GHI), 122 = Diffuse (verify the others against the live apidocs). Diffuse / direct-horizontal exist only from 2017-04-18.

For the forward horizon, note SMHI's forecast API migrated pmp3g → snow1gv1 (old endpoint retired 2026-03-31); confirm whether it exposes shortwave radiation or only cloud cover before relying on it.

Proposal & phasing (crawl → walk → run)

#	Phase	Value	Effort
1	POA-per-array wiring — project GHI onto each panel plane (uses the existing sunpos physics)	High	Low
2	STRÅNG client + performance scoring — expected-vs-actual performance ratio, shading/soiling/degradation signal, new GET /api/pv/performance, dashed "expected" history overlay	High	Medium
3	STRÅNG-calibrated prediction — train the twin on POA, warm-start its cold prior, feed a ±σ band into the optimizer's existing pv_low_w / pv_high_w (no contract change)	Medium	Medium
4	MapLibre "draw your array" — MapLibre GL JS (BSD-3) + Terra Draw (MIT), lazy-loaded like today's Leaflet; the numeric editor stays as a fallback	Medium	Medium
5	Roof-geometry module — optional module (like the optimizer): Lantmäteriet building-vector + LiDAR → RANSAC/DBSCAN roof segmentation → tilt/azimuth/kWp → auto-fills pv_arrays	High	High
6	Auto-fill + provenance badge — map polygons inherit roof-segment geometry; "Lantmäteriet data from <date>" from the STAC datetime	Medium	Low-Med

Roof geometry: method, tooling, data & licensing

• Method — the SPAN paper (Yavuzdoğan, Renewable Energy 2023, DOI 10.1016/j.renene.2023.119022): LiDAR → RANSAC plane fit + DBSCAN clustering → per-segment tilt/azimuth → PVGIS yield (~84 % roof-segment accuracy). Reference implementation is an open-source QGIS plugin.
• Optional shading — vostok ("Voxel Octree Solar Toolkit", C++) for shadow-aware per-point irradiance from neighbouring buildings/trees.
• Data — Byggnad Nedladdning, vektor (building footprints) + Laserdata Nedladdning, Skog (LiDAR, 1–2 pts/m², STAC API live 2026-06-01), both STAC, EPSG:3006, free CC BY 4.0 but gated behind a Geotorget account + OAuth2 → users bring their own credentials.

Proposed shape: an on-host, opt-in, automatic optional module

The roof module is a separate optional module (sibling to the optimizer) with a versioned roof_model.json contract, independent failure/update semantics, and a safe unavailable state — it only ever pre-fills the user-editable pv_arrays, never touching control.

• Runs on the FTW host, core-invoked via POST /api/roofmodel/derive (the existing subprocess pattern), opt-in and default-off, onboarding-time only, off the control tick, in its own time-boxed process.
• Automatic: on derive it writes segments straight into pv_arrays and stamps provenance — no manual JSON-shuffling. Derived values remain user-editable afterward.
• Credentials (geotorget_username / geotorget_token) are stored redacted, exactly like today's weather.api_key.

Is on-host invocation possible under the GPL? (yes — arm's-length subprocess, no bundling)

The FTW-authored roofmodel/ module uses permissive libraries only (laspy BSD, scikit-learn BSD for RANSAC/DBSCAN, pystac-client, pyproj), and reimplements the SPAN method (an algorithm, not copyrightable code) — so the module itself ships with FTW without GPL obligations.

vostok is GPL-3.0, so it stays an optional, user-installed external tool invoked at arm's length (a separate process, over the CLI + files) only if present on the host and opted in. Under the FSF's mere-aggregation / arm's-length rule, invoking a separate GPL program by subprocess does not make FTW a derivative work — so FTW's own permissive license is unaffected, even when vostok runs on the same host. The single obligation is distribution: FTW must not bundle or redistribute the vostok binary — the user installs it themselves; with vostok absent, shading is simply skipped (safe unavailable). Nothing (vostok, PDAL, laspy) is ever auto-installed on the host.

This is the standard interpretation of the GPL for arm's-length subprocess use, not formal legal advice — worth a maintainer confirmation of the distribution boundary before shipping.

Why on-host is acceptable despite LiDAR weight: derivation is a one-shot onboarding step, not a runtime tick — it runs in a separate, time-boxed, cancellable process and never blocks dispatch or the control loop.

Provenance ("show when the data is from")

Reuse FTW's existing fetched_at_ms epoch-ms convention. The roof model carries captured_at_ms (from the STAC item properties.datetime, or the laser strip datum field) plus derived_at_ms, surfaced via GET /api/roofmodel and rendered as a "Lantmäteriet data from <date>" badge on the map. Lantmäteriet is backfilling STAC properties.datetime through autumn 2026, so the UI degrades gracefully to "capture date unknown" until then.

Open questions for maintainers

1. Appetite for a third optional module (roofmodel/, on-host, opt-in) alongside the optimizer — vs. keeping roof derivation entirely out-of-repo (import JSON only)?
2. MapLibre GL JS in the no-build web app: CDN+SRI (like Leaflet) vs vendored (like Three.js)? Basemap preference (OSM raster vs self-hosted PMTiles vs a Lantmäteriet orthophoto overlay)?
3. Is a GET /api/pv/performance endpoint + a dashed "expected (STRÅNG)" history overlay the right first slice to land (Phases 1–2, no keys, high value)?
4. Any objection to a STRÅNG backfill path writing to a new irradiance_history table (keeping forecasts forward-only)?

Risks

• STRÅNG is historical-only → a calibration/scoring source, not a forward feed.
• Geotorget access has lead time → request early even though the roof module ships last.
• STAC properties.datetime backfill runs through autumn 2026 → provenance dates may be missing; the UI degrades to "date unknown".
• LAZ processing weight → onboarding-only, off-tick, time-boxed, opt-in.
• GPL tooling (vostok, SPAN) is kept external (user-installed, invoked at arm's length, never bundled).
• The optimizer band's pv_low_w / pv_high_w are site-signed ≤ 0 (generation negative) — the low/high↔pessimistic/optimistic mapping needs a direct unit test.

---

Attribution: SMHI STRÅNG and Lantmäteriet data are licensed CC BY 4.0. This text is preserved as originally posted; the implementation and its departures from it are in the comments.

[HuggeK]

Update: the plan has changed, and it is now four PRs

Two things drove the revision. @frahlg's review of #718 pointed out — correctly —
that one branch carrying both a live user-visible feature and an unreferenced
client is not reviewable. And investigating STRÅNG against the live API answered
a question the original RFC left open.

Everything below is implemented, tested and open as draft PRs.

---

What the investigation changed

STRÅNG's parameter set, measured rather than assumed

SMHI's apidocs pages currently 404, so the RFC's parameter list was a best
guess. Probing codes 100–130 against the live API returns data for exactly
116–122 and 404 for everything else. Names were then confirmed from their
magnitudes on a clear day at Stockholm (2026-06-21):

Code	Quantity	Noon value
116	CIE-weighted UV (mW/m²)	146.6
117	Global horizontal (GHI)	810.5
118	Direct normal (DNI)	917.2
119	Sunshine duration (min/h)	60.0
120	PAR	357.9
121	Direct horizontal	723.0
122	Diffuse (DHI)	87.5

Two independent checks pin the identification: 121 + 122 = 723.0 + 87.5 =
810.5, exactly parameter 117 (direct + diffuse = global), and 119 caps at
exactly 60 — minutes within an hour. The RFC's guess that 122 was diffuse holds;
the rest is new.

Cloud cover does not exist in STRÅNG — but it is derivable

Worth stating plainly since it came up: STRÅNG is a radiation model and
publishes no cloud-cover parameter. Parameter 119 is the way in — sunshine
duration is minutes per hour above the WMO 120 W/m² beam threshold, so
1 − minutes/60 is the fraction of the hour the sun spent obscured. That is an
observed quantity rather than an inferred cloud field, which makes it better
grounded than a forecast provider's cloud percentage, and coarser in one
direction: it cannot see thin cirrus that dims without blocking.

The trap this walked into, and the fix

The first working version reported 100% cloud cover at midnight, confidently,
every night — sunshine duration is zero at night because there is no sun. The
same failure appears near sunrise and sunset, where the beam crosses ten or more
air masses and cannot reach the threshold even under a spotless sky. Stockholm's
20:00Z hour that day reads GHI 2.5 W/m² and 0 minutes of sunshine, because the
sun is six minutes from setting.

So CloudCover(lat, lon) takes a location and declines to answer unless the sun
clears 5° of elevation during the hour, returning an explicit unknown
rather than defaulting to clear or overcast. It samples the hour's start,
midpoint and end, because the hour in which the sun crosses that line has both a
start and a midpoint below it (02:00Z: 1.59°, 4.34°, 7.25°) and would otherwise
be thrown away despite carrying a real half-hour of sunshine.

The domain is measured, and the bounds are honestly advisory

STRÅNG's extent was probed rather than assumed: data at lat 53.5 and 72.5 but not
53.0 or 73.5, at lon 0 and 30 but not −2 or 35. Berlin, London, Paris, Reykjavík,
Sydney and New York all return nothing; Stockholm, Tromsø, Helsinki and Copenhagen
all work.

But the grid is rotated relative to lat/lon, so a box can only ever be a
superset — all four corners of the declared box were probed and every one returned
no data. Coverage therefore reports false as definitive and true as "worth
trying", with the upstream API as the final word. The same applies to Sweden for
Lantmäteriet: no rectangle traces a diagonal country, so the box admits Oslo, and
that is resolved by the STAC search returning no tiles rather than by geometry.

---

The four PRs

PR	What	Size
#718	Plane-of-array wiring — project irradiance onto each panel plane	+341/−22, 5 files
#734	STRÅNG as an irradiance source + coverage metadata + MapLibre	stacked on #718
#735	Roof geometry from Lantmäteriet	stacked on #734
#736	Optional vostok shading	stacked on #735

#718 — plane-of-array wiring

Narrowed to exactly what @frahlg suggested: the half that is user-visible today.
Radiation providers previously produced one flat rated × (W/m² / 1000) estimate
that ignored orientation entirely — a south-facing 35° roof and a flat one got the
same forecast. Now GHI is projected onto each configured plane, with an Erbs split
for providers that publish only global horizontal. No new config, endpoint or
dependency. Forecast.Solar is deliberately untouched, since it already returns
site-calibrated watts and projecting again would scale it twice.

#734 — STRÅNG source + coverage metadata

The STRÅNG client, the performance scoring that consumes it, and the calibration
factor that feeds back into the forward forecast. Plus the part that answers
#726: a coverage registry and
GET /api/data-sources that report, per source, where it works and whether it
reaches this site.

Stockholm    forecast: all 4 OK | irradiance: OK STRÅNG | price: all 3 OK
Berlin       forecast: all 4 OK | irradiance: NO STRÅNG | price: OK ENTSO-E, NO Elpriset
Sydney       forecast: all 4 OK | irradiance: NO STRÅNG | price: none

This makes an existing silence explicit — STRÅNG is Nordic-only and every price
provider is European, so sites elsewhere were getting empty results with no
explanation. Scoring now declines to start outside the domain rather than retrying
nightly forever.

Also here: mpc.PVBand, which discharges the sign-mapping correctness risk the
RFC flagged. Generation is negative, so low is the optimistic bound; the
invariant low ≤ base ≤ high ≤ 0 is asserted over a table including NaN and ±Inf.
And the Leaflet → MapLibre GL JS 6 swap.

#735 — roof geometry

Answers open question 1 — yes to a third module, structured exactly like the
optimizer: roofmodel/, spawned at arm's length, communicating through one
versioned roof_model.json.

SPAN's method (RANSAC per surface, then DBSCAN to split faces sharing a plane but
not a location), reimplemented from its description — no code from the GPL QGIS
plugin, and dependencies are numpy/scikit-learn/requests, all BSD.

Two choices worth surfacing for review:

• SWEREF 99 TM is implemented directly rather than via pyproj. It is one
  projection with fixed parameters, and a full PROJ build is disproportionate on a
  Pi. Verified against the projection's exact analytic properties — easting on the
  central meridian is exactly 500000 at every latitude — and by sub-millimetre
  round trips from Smygehuk to Treriksröset.
• Auto-applying derived arrays to config is deliberately not wired. The RFC
  sketched automatic auto-fill; this returns the proposal instead. Derivation is a
  best guess from a point cloud that may be years old, and silently rewriting an
  operator's panel config is a change they should make knowingly. Easy to add if
  you disagree — it is a behaviour decision, not an implementation detail.

#736 — optional vostok shading

Each face is run twice, once against real occlusion geometry and once with
shadowing off; the ratio is the shading factor. Taking a ratio makes the result
independent of vostok's units, sky model and chosen year, since all three cancel.

The GPL boundary is exactly as the RFC proposed: separate process, files and a
command line, never linked, never bundled, never auto-installed. Absent
vostok, shading_factor is omitted rather than set to 1.0 — "we did not look"
and "we looked and it is clear" are different claims, and only the second
justifies trusting the yield estimate. Since vostok is usually absent, collapsing
them would be the common case, not the edge case.

A maintainer should sanity-check that licensing reading before it ships. It is
the standard interpretation, not legal advice.

---

Answers to the RFC's open questions

1. Third optional module? Implemented as one, mirroring the optimizer. feat(roofmodel): derive PV array geometry from Lantmäteriet open geodata #735.
2. MapLibre: CDN or vendored? CDN, pinned, lazy-loaded — same as Leaflet was.
   v6 is ESM-only and code-split, so it loads via dynamic import; the stylesheet
   keeps an integrity hash but the JS relies on version pinning, since SRI does not
   propagate to a module's own imports and hashing the entry point would leave the
   478 KB shared chunk unverified anyway. Basemap unchanged: the same OSM raster
   tiles and attribution.
3. Is /api/pv/performance + a dashed overlay the right first slice? It is in
   feat(weather): add STRÅNG as an irradiance source and declare source coverage #734, but feat(forecast): project irradiance onto each PV array's plane #718 turned out to be the better first slice — smaller, and it
   improves every radiation provider with no new surface at all.
4. irradiance_history as a new table? Yes, done that way; forecasts stays
   forward-only.

What is not built

Terra Draw "draw your array" (RFC phase 5-manual). The MapLibre swap in #734 is
the groundwork; polygon drawing is not started, and is the natural next slice if
these land.

Still needed from you

The live Lantmäteriet fetch is the one path not exercised end-to-end — it needs
Geotorget credentials for Byggnad-vektor and Laserdata-skog, which are the
operator's own. The HTTP layer is tested against a fake session, including the
documented quirk that properties.datetime is still being backfilled through 2026
with the laser strip datum as fallback. Same for vostok: adapter written to the
documented interface, exercised against a stub, .sol key names worth checking
against a real build.

Attribution: SMHI STRÅNG and Lantmäteriet data are CC BY 4.0.

[HuggeK]

Update: you now pick your building, and the roof is read from that footprint

Since this morning's update
two commits landed on #735 (98677c2,
934eda4),
with #736 rebased on top. All four PRs are green.

This closes the gap the RFC left widest: derive a roof is meaningless until you
say whose roof.

---

Why a picker — the measurement that forced it

Before this, a derive segmented a radius: your roof, the neighbour's, the garage,
the trees. I assumed picking a building was a usability nicety. It is not — it is
a correctness fix, and the mechanism is worth stating because it is not obvious.

RANSAC fits infinite planes. A roof at azimuth 180° is z = f(y) with no x
term at all, so the plane it defines does not stop at the wall — it extends across
the entire tile. Any second building that happens to share that pitch and ridge
orientation lies on the same plane, not merely a similar one.

A synthetic tile: a 12 × 12 m house and an 8 × 8 m garage, both at 35°, ridges
aligned, 40 m apart. Labelling every return by which surface it came from and
running one RANSAC pass over the tile:

first plane grabs 860 points:
     house-south: 576   <- all of them
    garage-south: 256   <- all of them, 40 m away
     house-north:  17   (near-ridge, within threshold)
    garage-north:  11

Both buildings' south faces are consumed as one surface. Only the DBSCAN pass
afterwards separates them, and only because they happen to be far apart in space
— a tuning parameter is all that stands between two buildings and a single merged
roof.

The sharpest evidence that this is a global effect rather than a proximity one:
the corruption does not change with distance. Sweeping the gap from 3 m to
40 m gives byte-identical output every time.

gap	south segments	areas
3 m	2	92.4, 41.7 m²
5 m	2	92.4, 41.7 m²
12 m	2	92.4, 41.7 m²
40 m	2	92.4, 41.7 m²

A neighbourhood method would fade with distance. This does not fade, because the
plane is infinite.

Clipping to the picked footprint restores the isolated result exactly. The
garage segmented alone gives one face, 225 points, 34.3 m², 34.9° / 180.2°.
Clipped out of the shared tile it gives one face, 225 points, 34.3 m²,
34.9° / 180.2° — the same numbers, not merely close ones. The neighbour stops
being a variable.

Two honest caveats about those numbers, since they cut against the headline

In this particular scene the unclipped area is coincidentally closer to truth.
The garage's true south face is 39.1 m². Unclipped it reads 41.7 m² (+7%);
clipped it reads 34.3 m² (−12%). If you only compared against truth you would
prefer the contaminated answer. The reason to clip is not that the number is
nearer, it is that the number is attributable: unclipped, nothing tells the
operator which of the two segments is theirs, and the contamination is arbitrary
rather than bounded.

The −12% is a separate systematic, and it is mine. Area is derived as
point_count / density / cos(tilt), so it is exactly proportional to the fraction
of returns a face keeps; DBSCAN drops boundary and near-ridge points, so a face
recovers ~88% of its true area at 8 pts/m². kWp inherits that error directly.
It is one more reason derived arrays are a proposal, not a measurement — and
at Laserdata Skog's real 1–2 pts/m² the edge effect will be proportionally larger,
which is worth remembering before anyone reads a derived kWp as a quote.

What it looks like in use

• The module gains --mode buildings: STAC-search byggnad-nedladdning-vektor
  around the site, return footprints as GeoJSON, nearest first.
• Core gains GET /api/roofmodel/buildings; the MapLibre map from feat(weather): add STRÅNG as an irradiance source and declare source coverage #734 draws
  them, and clicking one selects it.
• Read roof from LiDAR posts that building_id to
  POST /api/roofmodel/derive, which clips the cloud to the footprint before
  segmenting.
• The model records which building it used, plus returns_used /
  returns_in_radius — the honest measure of whether footprint and scan actually
  agree. A building newer than the 2018 scan lands zero returns on its footprint
  and gets told so in those words, rather than returning an empty array.
• Coordinate frames are detected by magnitude rather than trusted: GeoJSON
  mandates WGS84, Lantmäteriet publishes EPSG:3006, and a SWEREF easting is
  ~200 000–900 000 — unmistakable against a longitude.

Geotorget credentials now have somewhere to go

The RFC promised these would be "stored redacted, exactly like today's
weather.api_key". That is now implemented rather than promised: the token is
stripped from every API response, a save that omits it preserves what is stored
(so the UI never has to round-trip a secret it was never shown), and a
has_geotorget_token boolean lets the settings tab say a token is stored
without shipping it to the browser. Five tests cover exactly that boundary.

There is a short docs/roof-geometry.md:
which two Geotorget products to order, where the key goes, what a derived kWp does
and does not mean, and a table of the failure messages with what each one means.

A correction to this morning's comment

I wrote that "auto-applying derived arrays to config is deliberately not wired…
this returns the proposal instead." That is now half true and the difference
matters.

A successful derive fills the arrays into the editor — you see real numbers in
the form, with the 3D preview updating — and then stops, with "Review them and
press Save." Nothing is written to config until you press Save. So the guarantee
I argued for holds (your panel config never changes behind your back), but the
proposal no longer dies in an API response; it lands where you can see and edit it.
That is the shape I should have built the first time.

The roofmodel tests were not actually running in CI

Worth flagging separately, since it is a repository issue rather than a feature.
test.yml ran optimizer/tests but nothing ever ran roofmodel/tests — the new
module's entire Python suite was invisible upstream. There is now a roofmodel (Python) job mirroring the optimizer's, wired into the change classifier and the
rollup. It runs 75 tests on #735 and 93 on #736.

It found two real bugs immediately, both invisible on Windows

The Go tests stub the Python module with a fake executable. The stub returned
"sh" with the module name as an argument, so on a real Linux runner dash tried to
open a script named ftw_roofmodel and exited 2. Underneath that sat a second
bug the first was hiding: dash strips quotes from unquoted JSON, so the stub's
error payload arrived unparseable — while cmd.exe preserves them, which is
exactly why it passed locally and failed upstream.

Both are gone: the tests now re-exec the test binary itself as the stub
(TestMain + an env var + os.Executable()), so no shell is involved on any
platform. Verified by cross-compiling the package with GOOS=linux go test -c and
running it under WSL before pushing, rather than by pushing and watching.

Still not built

Terra Draw free-hand polygon drawing (RFC phase 5-manual). Picking a published
footprint is not the same thing as drawing your own, and for the array-geometry
case the footprint is the better input anyway — it is surveyed, and it is the thing
the LiDAR gets clipped to. Free-hand drawing is still the right answer for
ground-mount arrays and for roofs Lantmäteriet has not mapped.

Still needed from you

Unchanged, and now the only thing standing between this and a real roof: the live
Lantmäteriet fetch has never run against the real service. Every layer is tested
against fakes, and the full chain — pick → clip → segment → project onto the plane
→ score against STRÅNG — has been exercised end to end, but against a synthetic
tile, so it demonstrates that the pieces fit, not that the parsing matches
Lantmäteriet's real payloads. If byggnad-nedladdning-vektor turns out to deliver
tiles rather than per-building features, extraction needs a GeoPackage reader;
inline geometry and GeoJSON assets are handled today, and anything else fails with
a message that says so.

Same caveat as before on vostok: written to the documented interface, exercised
against a stub, .sol key names still worth checking against a real build.

Attribution: SMHI STRÅNG and Lantmäteriet data are CC BY 4.0.

[HuggeK]

Update: the ingest layer now matches what Lantmäteriet actually publishes

Pushed to #735 (ee93827),
with #736 rebased. Both green.

This settles a question I left open in the last
update,
and corrects something I got wrong there.

Both products are STAC APIs behind one account, differing only in what their
items point at: Byggnad Nedladdning, vektor delivers GeoPackage, and
Laserdata Nedladdning, Skog delivers LAZ organised as COPC (Cloud Optimized
Point Cloud). Assets are now selected by declared media type rather than by
guessing at key names — a catalogue that calls its asset punktmoln instead of
data keeps working, and a thumbnail is never handed back as a point cloud.

The correction

I wrote that "inline geometry and GeoJSON assets are handled today". Only the
first was true. _features_from_item returned an empty list for anything
asset-backed — which is the normal case for Byggnad-vektor, so the building
picker would have found nothing at all against the real service. Both paths exist
now, and the GeoJSON one is tested rather than asserted.

GeoPackage without GDAL

A GeoPackage is a SQLite database holding geometry as a short header followed by
standard WKB — two published specifications with fixed layouts. Decoding what a
roof model needs costs about a hundred lines of sqlite3 and struct, against a
GDAL/fiona dependency that does not install on a Pi without a compiler and drags
in a second projection stack. Same reasoning as implementing SWEREF 99 TM
directly. Curves, triangulated surfaces and extended binary types are rejected
explicitly rather than mis-parsed, because a wrong ring silently clips the wrong
LiDAR.

The fixtures are built from the spec, not from the decoder

A decoder tested against blobs its own encoder produced agrees with itself and
proves nothing. The fixtures here are assembled byte by byte from OGC 12-128r19
clause 2.1.3 and OGC 06-103r4 clause 8.2, with the layout asserted inline (the
header is 8 bytes before the envelope; an xy envelope is four doubles). Covered:
both byte orders, 2D and 3D rings, interior rings, multipolygons, the empty-geometry
flag, and a corrupt row that must not take the rest of the tile with it.

Picking a building now makes it cheap as well as correct

COPC orders its points into an octree with the index at a known offset, so a
reader can range-request only the nodes covering a region. Since the operator has
already said which building, that footprint's bounding box is exactly the query
COPC exists to answer — kilobytes instead of a 2.5 km tile running to hundreds of
megabytes. That is the difference between a derive being feasible on a Pi and not.

Best-effort, in this order: plain .laz, a host that ignores Range, or a laspy
without COPC support all fall back to reading the tile whole — slower, same
answer. A server that ignores Range answers 200 with the entire body, which
would otherwise pass for a successful partial read, so that is detected on the
status code rather than assumed away. The model records which path ran as
source.fetch, since it also decides what returns_in_radius is counted over.

Also corrected: the coplanar measurement

The 93% / two-fragment figures I quoted for the garage do not reproduce, and are
gone from the code comments and the docs. What a fresh run shows is stronger:
labelling every return by source surface, one pass over a house and a garage 40 m
apart consumes all 576 of the house's south-face returns and all 256 of
the garage's as a single plane — identically at every separation from 3 m to 40 m.
Distance-invariance is the signature of a global infinite-plane fit; a proximity
effect would fade. Clipping restores the isolated result exactly.

Still needed from you, unchanged: Geotorget credentials for the live fetch.
Everything above is tested against fakes and a synthetic tile. If the real items
turn out to carry something other than GeoPackage or GeoJSON, the failure now
names the format instead of silently returning nothing.

Attribution: SMHI STRÅNG and Lantmäteriet data are CC BY 4.0.