Management of codelists and codelists' values

[pgcipriano]

Dear all, please find enclosed three Excel files I already shared with some of you in June. 3_Codelist.xlsx 4_CodelistValue.xlsx 2_ApplicationSchema.xlsx

They are examples of "list of applicationSchemas", "list of codelists" and "codelist' values" based on INSPIRE Re3gistry (http://inspire.ec.europa.eu/codelist/) and already extended in GeoSmartCity project (http://hub.geosmartcity.eu/registry/codelist/).

As agreed in Wien, in the CityGML Energy ADE we need something like this. For all the Excel files (in particular for "codelists" and "codelistValue") we need to collect “labels” and “definitions” in different languages (at least German, Italian, French).

We might have the “list of codelists” for Energy ADE (based on the enclosed Excel file "3_codelist") with national labels and definitions before the workshop in Ferrara.

[pascal-schetelat]

As I proposed during the workshop, here is what can be extracted from the uml description to build the 3_Codelist file :

3_Codelist.xlsx

Let me know if there is something missing or if it can be used as a starting point.

[JoachimBenner]

I did not attend the workshop, and therefore I do not know the purpose of this Excel file. However, as basis for collecting the Codelists it seems not very appropriate for me. The table shows all UML elements of the EnergyADE schema, not only the elements of stereotype "Codelist", and for the Codelists itself, it does not contain the already existing entries.

The attached ZIP archive contains a GML dictionary for every EnergyADE 0.7.0 Codelist. I could imagine that defining hierarchical Codelists in an XML format is easier than directly within a flat table, but this surely is a matter of taste. In any case, transformations from GML dictionary to Excel table and vice versa are not very sophisticated.

EnergyADE_0_7_0_Codelists.zip

[pascal-schetelat]

Hello @JoachimBenner,

From what I understood from @pgcipriano explanations, the excel file format would have been used to communicate with INSPIRE, is that right?

[JoachimBenner]

Yes, that's also my understanding. But the Excel file must be restricted on the Codelists and their (hierarchically structured) entries. But we are not forced to directly edit this Excel file, Theoretically, we can use any other format (e.g. GML dictionaries) and generate the Excel table from the dictionaries.

[pascal-schetelat]

Totally agree about the generation of the excel files. I don't mind editing gml dictionaries, especially since revisions are much more tractable in a plain text file, though I wonder if all partners are willing to directly edit xml files?

[pgcipriano]

@gioagu and me prepared the following Google spreadsheet to start editing the definition and labels of the Energy ADE codelists and their values: https://docs.google.com/spreadsheets/d/1QosN8dEW757ht1OqTdTOicw2Yy57syTqrXZA3tcAVUY/edit#gid=454796838

The spreadsheet contains 4 similar sheets (English, Italian, French, German) where to provide definitions into different languages. This spreadsheet is to be used only as a working document, to share the semantics of terms used and their translations, before importing them into the INSPIRE Registry instance of the GeoSmartCity project.

[pgcipriano]

Please note that the codelist BuildingTypeValue is now containing 4 different terms referring only to residential buildings; therefore this codelist should be hierarchical and the 4 terms should be considered as narrower values (2nd level) of a 1st level term residential. In my opinion this will cause a strong overlapping between the BuildingTypeValue codelist and the CurrentUseValue one (hierarchical). I do think we'd better move the 4 existing terms from BuildingTypeValue to CurrentUseValue (under the already existing value “residential”). Furthermore, we'd better rename BuildingTypeValue into BuildingNatureValue having the same definition of the INSPIRE one with terms already referring to typologies of buildings (e.g. stadium): http://inspire.ec.europa.eu/codelist/BuildingNatureValue This INSPIRE codelist is Extensible with values at any level.

The definition of this codelist (in INSPIRE) is:

Values indicating the nature of a building. NOTE 1 : This code list does not aim to be exhaustive as the attribute buildingNature addresses only noticeable buildings. NOTE 2: The values included in this code list address mainly (but not only) two international use cases: air flights where buildings may be obstacles and marine navigation where buildings may be landmarks. NOTE 3: This code list should only be applied for buildings, even if it may be applicable to other constructions (for example, not all dams are buildings).

We might extend the same codelist with 1st level values referring to a third use case (energy simulation) with terms like shopping mall, warehouse, factory, ...

[RomainNouvel]

Careful Piergiorgio, BUILDING USE and BUILDING TYPE must not be confused. Even if buildings are generally built in accordance with their first use, we often see offices in Multi-Family Houses, or Dwellings on the top of skycrapers... without speaking about Mixed-usage buildings!

[JoachimBenner]

I agree with Romain that we must clearly diffentiate between buildingType (Attribute of Building , CodeList BuildingTypeValue) and usageZoneType (Attribute of UsageZone, CodeList CurrentUseValue).

BuildingTypeValue From my point of view, the buildingType should classify the whole building by technical or architectural aspects. Thus, the 4 items in version 0.8.0 are appropriate to classify residential buildings, and we only need to add some classifications for non-residential buildings. I am not very happy with the INSPIRE BuildingNatureValue list. The list seem to be more or less arbitrary and incomplete, and most of the items are irrelevant for the use case "Energy Simulation".

CurrentUseValue The basic idea of the proposal seems to classify the usage of a complete building , but the Energy ADE needs a classification of Usage Zones. A Usage Zone is characterized by one set of specific usage profiles (Heating, Cooling, Lighting, Occupancy, ...). But, most of the usages occuring in the actual proposal cannot be described by one heating, cooling or occapancy profile. A hospital, e.g. contains patient rooms, operational theatres, offices and technical rooms, and each of these room types has different usage profiles.

I therefore propose to take the German norm DIN 18599-10 (plus the usage class "residential") as basis for the CurrentUseValue CodeList, It defines 42 different usages for non-residential buildings, a few of them perhaps can be neglected. Nutzungsklassifikation-DIN-18599.xlsx

[pgcipriano]

I dont't confuse the two codelist, I am only highlighting the fact that, at the moment, they are overlapping and that BuildingType is partial.

Independently from the naming (BuildingNature or BuildingType) I do think we are using the same meaning for defining a list of terms referring to technical and/or architectural characteristichs of buildings (we all agree with Joachim on that).

As mentioned, in INSPIRE the BuildingNatureValue codelist is incomplete BECAUSE it is only focused on 2 particular use cases (air flights and marine navigation):

NOTE 1 : This code list does not aim to be exhaustive as the attribute buildingNature addresses only noticeable buildings. NOTE 2: The values included in this code list address mainly (but not only) two international use cases: air flights where buildings may be obstacles and marine navigation where buildings may be landmarks.

About the proposal to use the classification adopted by DIN, I personally do not agree: other national-based classifications already exist (e.g. https://www.amministrazionicomunali.it/docs/pdf/categorie_catastali.pdf contains the classification of building units from the perspective of the Italian Cadaster) ... but all of them are PARTIAL. The classification adopted by DIN, for instance, does not contain differences between public and private offices, nor schools (that should be narrowed with different levels).

[JoachimBenner]

I can imagine that different countries have different national regulations and that the granularity of the classification system is debatable, but please regard that DIN-18599 does not classify building functions due to the German cadastre. The regulation classifies parts of non-residential buildings with specific usage profiles (and specifies basic parameters of these profiles), which from my point of view makes a big difference.

At least, we should take this regulation, or a comparable one from another country, as starting point for a further refinement. If this is not possible, the best alternative could be to leave the CodeList empty. Then every user can choose his personal classification system.

[RomainNouvel]

Hi @pgcipriano , Having a look to your google doc, I'm a little bit surprised:

• In a multi-language codelist, one value correspond to different labels according to the different language. Then, why to create parallel tables for each codelist in your google doc?
• Why is the hierarchical structure of the codelist (like what you shew us) not considered anymore?

[RomainNouvel]

Hi guys, I've just completed the German translations of the codelists : https://docs.google.com/spreadsheets/d/1QosN8dEW757ht1OqTdTOicw2Yy57syTqrXZA3tcAVUY/edit#gid=454796838 Some CurrentUse fields remain still blank, maybe some native German speaker ( @JoachimBenner , @mlauster ...) could finish the work!

[pgcipriano]

As already anticipated to @RomainNouvel via email (18/5):

1) the shared Google spreadsheet is just to collect definitions and labels; it is divided into separated sheets just to facilitate we all to fill in labels and meanings (definitions). Therefore the Google spreadsheet is NOT structured as the final format to be used in the proposed Codelist Registry. Actually, at the beginning of the github issue you can find samples of XLS files accepted by the Registry: I uploaded months ago but I did not received any comments related to them, thus we realized we needed a more simple way to collect terms and definitions, in different languages.

2) in the Google spreadsheet hierarchies are to be managed as indented bullet points so to better understand the hierarchy itself. In the final version to be uploaded in the Codelist Registry we will structure hierarchies accordingly

[JoachimBenner]

I propose to close this issue and continue the discussion under issue #140

[RomainNouvel]

ok