Skip to content

feat: serve each building's usage class from its source function code #210

Closed

Description

@jravani

Problem

GET /api/v1/buildings returns function_code exactly as the source dataset stores it: the ALKIS Gebäudefunktion in Germany (for example 31001_1000), null for the Netherlands, Austria and Czechia. Every consumer then needs its own per-country code table to know what a building is used for.

Each data provider describes use differently: a different code list, or a different attribute altogether. In EnerPlanET a 3D building with no OSM outline currently cannot be classified and is treated as residential, for example DEBY_LOD2_7672144 (about 5,500 m², THD campus).

The knowledge of what a source code means belongs next to the source data, in one tool, so that adding a region is a change here only.

Proposal

  • A mapping per dataset from the source use attribute and its codes to a usage class, kept with the country or region configuration. For Germany it follows the official ALKIS Gebäudefunktion code list.
  • Applied in the pipeline step that extracts function_code; the result is stored with the building.
  • Served on GET /api/v1/buildings next to function_code:
    • use_type: a neutral use category (for example residential, office, education, retail, industry, agriculture, other);
    • residential: boolean;
    • both null when the code is missing or unmapped.
  • Adding a region means adding its mapping here; consumers need no change.

To agree before building

  • The use_type vocabulary. Consumers map it to their own categories (EnerPlanET maps it to pylovo's building classes), so it stays neutral and is not tied to any one consumer.
  • Where the code lists live (a file per country in the configuration, or a table in the database) and the source and licence of each list.
  • How mixed-use codes are classified.

Done when

  • German buildings carry use_type and residential derived from their ALKIS code.
  • Netherlands, Austria and Czechia return null until a mapping is added.
  • OpenAPI description and changelog updated; an integration test covers known German codes.

Activity

  1. jravani commented on Oct 25, 2026

    @jravani
    MemberAuthor

    Delivered in v0.12.0: Germany from the ALKIS function code (#211) and the Netherlands from BAG units (#217). Austria and Czechia return null until their source data has a use mapping.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions