Skip to content

Report geography no dataset declared - #262

Merged
ccomb merged 4 commits into
mainfrom
quality_geography
Jul 27, 2026
Merged

Report geography no dataset declared#262
ccomb merged 4 commits into
mainfrom
quality_geography

Conversation

@ccomb

@ccomb ccomb commented Jul 26, 2026

Copy link
Copy Markdown
Owner

Why

Nearly every process of some SimaPro databases leaves the Geography field at Unspecified. On Agribalyse 3.2 that is 20 537 of 21 510 entries: the only geography left is the code inside the dataset name — … {FR}, …//[RER], …/CN U. The parser already reads it, which is what makes those databases usable at all, but the result is a reading of a name, not something the source stated. An EcoSpold dataset with no geography is filled in with GLO just as quietly.

Downstream, a declared FR and a guessed FR are the same text, so nothing could tell a maintainer how much of a database's geography is actually source data. The quality report's existing location check only fires when the geography ends up empty — 16 entries on Agribalyse 3.2 — which reads as "geography is fine" on a database that declares almost none.

Final state

Activity carries where its location came from (LocationDeclared, LocationInferredFromName, LocationUnspecified), recorded at parse time because that is the only place the difference still exists. Each parser fills it in: the geography field when it says something, the name fallback when it doesn't, and neither for a dataset the loader had to supply a stand-in for.

The quality report gains an undeclaredGeography check listing every entry whose geography the source never declared, with the reason in the finding. Info severity — the geography stays usable and the numbers stay correct; plain absence is still the missing-metadata warning it always was.

Measured on Agribalyse 3.2 (SimaPro CSV, 21 510 entries): 20 521 read off the name, 16 with none at all, 973 actually declared.

@ccomb ccomb closed this Jul 27, 2026
@ccomb ccomb reopened this Jul 27, 2026
ccomb added 4 commits July 27, 2026 11:30
Nearly every process of some SimaPro databases leaves the Geography
field at "Unspecified" — 20537 of 21510 entries in Agribalyse 3.2 — and
the only geography left is the code inside the dataset name ("… {FR}",
"…//[RER]", "…/CN U"). The parser reads it, which is what makes those
databases usable, but the result is a reading of a name and not a
declaration; an EcoSpold dataset with no geography at all is filled in
with "GLO" just as quietly. Downstream both look like any other
geography, so nothing could tell a maintainer how much of a database's
geography is actually source data.

Activity now carries where its location came from, recorded at parse
time because that is the only place the difference still exists, and the
quality report counts the entries whose geography was not declared. Info
severity: the geography stays usable, and plain absence is still the
missing-metadata warning it was.
The Activity record gained a field in the middle of its Store layout,
which is positional: an old cache decoded by this build would misread
every field after it, at best failing mid-decode with a misleading
"corrupted" message instead of a clean schema-mismatch rebuild. Same
situation as salts 9 and 10, same remedy.
The same lookup was written twice, once for the location and once for
its source.
The "stands in for it" quality finding was only exercised by building
the fixture by hand in QualityReportSpec; nothing proved a real parse of
a geography-less dataset produces the GLO stand-in with
LocationUnspecified. Two tests pin both sides: a declared geography and
the stand-in.
@ccomb
ccomb force-pushed the quality_geography branch from d3eabc5 to db63229 Compare July 27, 2026 09:33
@ccomb
ccomb merged commit 4e032f6 into main Jul 27, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant