European Commission logo
INSPIRE Community Forum

One address with many positions

Does any member state have a good solution for addresses that have more than one geographical position (address locations) and do not have different specification attribute values for each of these positions, as it is required in Data Specification on Addresses – Technical Guidelines, Annex II, Section 5.5.1(2)?

If an address has more than one position, the specification attribute shall be populated with a different value for each of these.”

The problem lies for us in the more detailed Address Database System (ADS) than INSPIRE requires. We have given every building in the cadastral parcel an address. That creates a situation where we have more than one geographical position for one address. The simplest way to illustrate the situation is to take a farm complex in rural area. In most cases it consist 1 residential building and 2-3 farm buildings (barn, woodshed, workshop, etc). We have given unique identification (ID) code for all of the buildings and then created an address for them. It means that we have about 4 different geographical positions with 4 different ID-s and with 4 identical addresses. These addresses do not differ anyway for INSPIRE, but they differ for us by the ID code.

For now, when we have converted that kind of addresses to measure up to INSPIRE requirements we have lost all farm buildings addresses locations because they do not have different geographical positional spetsification values that have given in the attribute code list values of “GeometrySpetsificationValues”. But we would like to represent address data in our INSPIRE geoportal as detail as it is in our ADS.

 

Does anyone have an idea how to represent the attribute data differently for all of these address positions? Even if they are made with one method and do not have different address spetsification value like “postalDelivery“ or “entrance“ (we think that these buildings should be classified as “building” values).

The picture on the left is describing the situation how we are representing our addresses in INSPIRE geoportal at the moment and the picture on the right is illustrating how we would like to show our addresses.

  • Dominique LAURENT

    By Dominique LAURENT

    In my point of view, the issue come from the confusion between Address and AddressableObject.

    Unfortunately, in the INSPIRE model, the core feature type has been called “Address” whereas “AddressableObject” would probably have been better.

     

    Thematic Cluster example:

    -          there are 4 addressable objects (buildings)

    -          they have the same address (same locator, same address components)

    -          these addressable objects  have the same geometrySpecification = building

     

    France example:

    In rural areas, we often have unstructured address (without thoroughfare name and house number), i.e. several addressable objects,  for us only inhabited buildings, have the same address whose level of detail is limited to an AdressAreaName or even just an AdminUnitName. This occurs typically in small village. In these cases, the geometrySpecification may be adressAreaName or AdminUnit5thOrder (municipality) or, in best cases,  parcel (if we have this kind of information from taxation office)

    We have made our transformations using following principles:

    -          there are n addressable objects => there are n addresses

    -          they have the same address (no locator, same address components)

    -          they have the same geometrySpecification  (adressAreaName or  AdminUnit5thOrder (municipality) or parcel).

    -          they may have the same geometry (cases adressAreaName,  AdminUnit5thOrder (municipality)) or they may have different geometries (cadastral parcel)

    [NOTE: we can't conform to INSPIRE because we don’t have locator that is mandatory in INSPIRE]

     

     

    At short term, I think we might interpret the INSPIRE definition of “Address” as if it was “addressable object” (in fact, it is what we did in IGN). At longer term, this might deserve a modification in INSPIRE IR.