European Commission logo
INSPIRE Community Forum

Natural identifiers in Buildings

My name is Michal Med and I‘m employee of Czech Office for Surveying, Mapping and Cadastre. My job contains almost everything about practical part of INSPIRE implementation, I‘ve already took part in implementation of INSPIRE themes Addresses, Administrative Units and Cadastral Parcels here in Czech Republic. My goal this summer is to prepare data and services for the theme Buildings. Your e-mail is in Data specification as a contact e-mail. As I prepared first version of data transformation from our databases to GML, I discussed that with our working group. Most of buildings come from database of territorial identification, the rest from cadastral database, quite a lot of them is in both databases (but we know which they are). Problem is, that both databases have different identifiers. We solve this problem by creating a table called ‚bridge‘, which connects objects from both databases, assigning them new identifier. But neither database identifiers, nor bridge identifier is natural identifier. As a natural identifier I mean something, which identifies object in a real world. For buildings, natural identifier is house number (building identifier prefix, building identifier and part of municipality) as in theme Addresses. The problem is, that in data structure of Buildings, there is no place for this identifier, except association role Address, whis is only association role, and moreover, it’s only in extended version of Buildings application scheme. In my oppinion, this feature shall be in Base schema, because it’s simply the most important information about building (together with geometry). Opinions in our working group are different. Some thinks, that information in INSPIRE shouldn’t be duplicated and this natural identifier of buildings is basically contained in the theme Addresses. But association to address shall be therefore in Base schema. Others thinks, that natural identfier is so important, that it shall be writyten in a single element straight in buildings. Other problem with natural identifier is, that not all of buildings have it. Some buildings have no descriptor. Do you know, if there are similar situation in other countries with natural identifier? I think, that similar problem should be in most of European countries. Do you have some recommendation on how to solve this problem?

  • Dominique LAURENT

    By Dominique LAURENT
    • In TWG BU, we thought there are no natural identifiers of buildings, i.e. identifiers of real world objects ; the main reason is that there are not even “natural buildings” as the  segmentation of buildings is not always obvious and depends (for complex buildings) quite a lot on your point of view (e.g. cadastral / topographic).  Typically, a house with a join garage might be considered as a single building , as a building with 2 building parts or as 2 separate buildings. Another example is the standard CityGML that is quite blurry about definitions and distinction between Building and BuildingPart.


    • We never considered that the address might be an identifier of buildings:


    • The identifier must be unique
    • But several buildings may have same address (e.g. in rural areas where the address is just the village name)
    • And a building may have several addresses
    • => As the relation between AD-BU is [0…*], addresses can’t be used as identifiers


    • The buildings (as features in a dataset) must have a unique identifier (the INSPIRE identifier) and may have several “external references”, i.e. their business identifier in an external information system. This external reference may be used as “bridge” between the INSPIRE data set and other databases.


    • In TWG BU, we had  lots of discussion about links between addresses or cadastral parcels  and buildings to be in core or extended schemas ; the decision was to have them only in extended schema as this information was not considered as necessary for X-border or pan-European use cases but it is true it is significant information at national level.


    • I would so encourage you to adopt an extended profile of INSPIRE. It is just very infortunate that JRC has not yet published the updated .XSD file for Buildings Extended 2D schema!!!
  • Michal MED

    Let me react to this (very old) question I've asked and suposed to be closed. As far as i can see, the response Dominique wrote here is more or less the same I've got to my originally postred question in mail.

    Right now, we're just before launching Extended Buildings in Czech Republic, so this is how was it solved:

    • first let me say that we wrote our own extended buildings schemas. I've already posted it here in cluster, but repeating is mother of wisdom (as we Czechs say)
    • ​Natural identifier is not meant like INSPIRE identifier and it's not meant to be unique in general. In my oppinion it would be enough to have external references. There wa sa misunderstood with the word 'identifier', which is in IT world always meant as unique. Therefore have I wrote a lot about what I really mean -- how to identify one building among many in the real world
    • WHAT has been done to naturally identify it? This is our best practice:
      1. name element contains house number and type of the number
      2. for buildings, addressRepresentation element contains both name of the municipalty and part of the municipality, where the building belongs to
      3. for buildingParts, addressRepresentation contains name of the municipality and link to the INSPIRE AD feature. It's good to be said, that buildingParts in our implementation are treated basically as a building part with separate entrance, which allways have ONE MAIN associated address point in DB (can have more, but one is main) and every building has at least one buildingPart (most of them only one)
      4. for buildingsexternalReference refers to building in all information systems where the building is listed
      5. for buildingParts, externalReference referes to buildingPart with separated entrance and detailed information in Information system of terrestrial identification, addresses and real estates, which contains the information about natural identification as how we get it.



  • Dominique LAURENT

    By Dominique LAURENT

    The use of externalReference looks quite conform to what was expected by TWG BU. In opposite, I have the feeling it's not the case for addressRepresentation and name.:

    - the "name" (in INSPIRE core schema) is supposed to be  the real name (e.g. Sagrada Familia) of specific buildings and not a house number

    - the INSPIRE data type AddressRepresentation (if used in your extended schema that I did not take time to look at) may include all the address components but normally not the link to the AD feature.

  • Michal MED

    a) in Czech Republic, we don't need names, but identification, so we used attribute name for its natural name, which is number
    b) AddressRepresentation has attribute AddressFeature, that may content URI

                    <gn:nativeness codeSpace=""/&gt;
                    <gn:nameStatus codeSpace=""/&gt;
                    <gn:sourceOfName>Český úřad zeměměřický a katastrální</gn:sourceOfName>
                    <gn:pronunciation xsi:nil="true" nilReason="unpopulated"/>
                <ad:addressFeature xlink:href=";version=2.0.0&amp;request=getFeature&amp;typename=Address&amp;CRS=urn:ogc:def:crs:EPSG::5514&amp;featureId=24646075"/&gt;