fix: serve and link buildings extracted at LOD3 - #147
Merged
Merged
Conversation
Extraction writes LOD3 input to lod3_building and lod3_surface, but the on-request queries read only the lod2_ tables and -link-pylovo batched only LOD2 buildings. A database built from LOD3 data, such as Prague's CityGML, therefore served no buildings and linked none. The five on-request queries now read the lod2_ and lod3_ tables together through UNION ALL; both come from the same DDL, so their columns match. -link-pylovo runs one pass per LOD schema, since building_feature_id is only unique within one schema, and the building limit spans both passes. A database holding both levels of one area returns those buildings twice.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
v0.7.2 read the lod2_ and lod3_ tables with SELECT * under UNION ALL, which assumes both have the same columns. A database built by an earlier release does not: area_below_precision was added to lod2_surface alone, and neither surface table has length or width. On such a database every buildings and geometry call failed with "each UNION query must have the same number of columns". The union now reads a named column list that every release's tables carry. area_below_precision is derived in the query with the same definition script 08 stores, so a table without the column still serves.
TestServer_ServesOlderReleaseSchema drops the surface columns an older release lacked. length and width exist only from the length/width change onward, so a branch without them failed the ALTER before the test reached the queries it checks.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Extraction writes LOD3 input to
lod3_buildingandlod3_surface, but nothing read those tables: the on-request queries were built on thelod2_prefix only, and-link-pylovobatched only LOD2 buildings. A database built from LOD3 data served no buildings and linked none, without an error.internal/onrequest/query.go: the five queries readlod2_andlod3_together throughUNION ALL. Both tables come fromsql/schema/main/01_create_main_tables.sql, so the columns match. No new setting.-link-pylovoruns one pass per LOD schema, becausebuilding_feature_idis only unique within one schema. The link SQL already reads{lod_schema}; each task now carries the LOD it batches.BUILDING_LIMITspans both passes.Verified
TestServer_ReadsLOD3BuildingsandTestRunPyLovoLinkBuild_LinksLOD3Buildingsfail before the change (no buildings returned; nobuilding_linkrow) and pass after.TestPyLovoLinkJobQueue_WithBatchesnow asserts the LOD each task carries.go vet ./...,go test ./...and theinternal/process,internal/onrequestandinternal/apiintegration suites pass.GET /api/v1/buildingsfor a 300 m box returns 331 buildings with 3,340 surfaces, where the current server returns none.Release
Also cherry-picked onto
release/v0.7.xand taggedv0.7.2. No schema change.