INSPIRE Data Specifications Special Interest Group

| Share
Group discussion > Buildings


3109 days ago

The INSPIRE Drafting Team for Data Specifications has drafted the description and scope for the theme 'Buildings'.

Is there any European initiative or obligation in your country with a particular requirement related to this theme? We invite you to provide your comments on this description and scope, providing the rationale for any changes you propose and uploading related material if possible.

The INSPIRE Thematic Working Groups, who will elaborate the guidance documents as a base for the INSPIRE Implementing Rules and support for the implementation, will use these discussions as a basis for their work.

Note: Related material can be uploaded to the files section. Please use the title of the discussion as one of the tags for the file.


Dan Olausson
1638 days ago


We are supposed to publish our records of buildings and ruins but I have some minor issues. There are a couple of features that you refer to in chapter 11 portrayal that only can be provided using GeoServer. Was that your intention?

For the viewservice there should be a layer named BU.Building and publishing objects of the Building-type. But The type Building has no geometry. Geometries are stored in BuildingGeometry2D. It is possible at least to publish complex WMS-layers, but why would you? 

There are three different types of styles here point, line and polygon. In the code-snippet you refer to a non-standard function geometryType. Since the SLD/SE-standard is missing this basic functionality, we need to make some kind of work-around. This work-around only works for GeoServer. Was that your intention? An other work-around is to have an extrageometrytype-field in the response.

Would I be totally wrong if I interpreted the specs that you would like some nice images with points, lines and areas symbolizing the buildings and a WFS answer on getfeatureinfo?

/Dan Olausson


Dominique Laurent
1597 days ago

The INSPIRE data specifications for theme Buildings have been developped using the INSPIRE methodology, i.e. taking into account both user requirements and existing data. It is why multiple representations of buildings are allowed in the INSPIRE model. This has been done using an attribute geometry that may take several values and that is defined as a data type (with the geometry itself and some information about what this geometry represent, e.g. roofedge or footprint, how accurate this geometry is and if the geometry has to be used for portrayal through the "reference").

It is not true to say that the type Building has no geometry; type Building has at least one geometry but this geometry is not just a simple attribute but a complex one defined by the data type BuildingGeometry2D.

The fact  that this model raises issues for view services and that only GeoServer is able to deal with this type of modelling (also used in theme AD)  was not detected during the development of INSPIRE data specifications; typically, no one complained about it during the phase of review and tests by SDIC/LMO.

I still consider the modelling of geometries in theme BU (and AD) as good; the solution would/might be to upgrade the WMS/WMTS in order to enable them to display easily this kind of data. May be, the ARE3NA project might fund this upgrade at least for other open-source servers as deegree or MapServer.


Dan Olausson
1582 days ago

The building model is not the problem that I run into. I like the model its simple and flexible. The problem is the view service specification.

To understand complex-data most people use one of to methods. The filter-model and the table-model.

  • The filter model or xml-model is thinking of the data as a xml-file where all classes are instantiated as tags.
  • The table-model or database-model is to think of the objects inserted into database tables with different relations.

If you use the filter-model and you like to display a Building. You filter the instantiated building object. There you see geometry that you use as base for the image. You use data instantiated from BuildingGeometry2D as base of the image.

If you use the table-model and like to display a Building. You see the table building and it has no printable data. But it has a relation to an other table with geometry-data. You use data in the table BuildingGeometry2D as base of the image.

The results are identical, we display data formated from BuildingGeometry2D. Not very surprising, as we actually have no other data that we can display as an map-image. But still there is a big difference here since in the first answer we display complex-data and the second simple, but the results are identical.

WMS has a strange function 'GetFeatureInfo'. This functions can be used to build complete image-centric web applications or to display pop-pups on map-objects. And it is at this stage we have difference in the results from the models.

If you use the filter-model, the answer for a GetFeatureInfo-query would of course be information about the Building-object that contained the geometry.

If you use the table-model, the answer for a GetFeatureInfo-query would of course be about the geometry-object that you see on the map.

We have to different answers to the same question, this is not optimal.

Lets go back to what WMS is all about. It is a Service to get Map-images on to the Web. And as a image-service, a GetFeatureInfo query is about the graphical component you can see on the map. Therefore the most correct answer is the geometry-object. Still it is information about the object.

There is an other service in close relation to WMS that is called WFS. Web Feature Service is not an 'map on the web' service, it's a computer to computer protocol for feature information. If you ask the WFS for a feature at a certain coordinate you get a strictly defined answer, the feature.

My theory is that; If you want a feature you should ask the feature-service and if you want a map you should ask the map-service.

The work-around here is to rewrite the GetFeatureInfo-queries and pass them to the WFS service. Is that really a good idea?

The other problem with portrayal is a bit strange. The SLD/SE specification is missing some parts that actually forces you to only have one type of geometries per layer. Point-layer, line-layer and polygon-layer. But having these layer-collections are not very practical. The usual work-around is to add a geometry-type-flag in the data. With this flag SLD/SE can select different styling depending on the geometry-type. An other work-around is to implement an non-standard function in the SLD/SE to create this flag on the fly. If you add the type flag to the data, you can use the standard.

You are right we should use ARE3NA to update the SLD/SE standards to handle different geometry types.

The most annoing part is that I read the spec twice and did not notice any of these things...