About mapping rules

[gioagu]

Hi,

first of all, this is not an issue per se, but just an info request. I refer to your comment:

"All objects having an identifier are registered in the CITYOBJECT table. In terms of CityGML and ADEs, this means all types derived from gml:AbstractGMLType and not just types derived from core:AbstractCityObjectType."

It seems to me that this applies to ADE objects only. For "standard" CityGML objects (not derived from _CityObject), the classic mapping rules still apply, i.e. they are no data stored in the CITYOBJECT table. E.g. Addresses, Appearances. etc.

• Did I understand correctly?
• Are these ADE mapping rules documented somewhere?

Thanks for your help!

[thomashkolbe]

Hi Giorgio,

the ADE mapping rules are provided in Zhihang's PhD thesis: https://mediatum.ub.tum.de/node?id=1574231

One of the appendices has a listing of all rules.

We are going to start the development of the new version of the 3DCityDB for CityGML 3.0 in the next weeks. It will be also a topic how to best map the GML / GFM object hierarchy onto the database schema.

We are currently looking for all sorts of comments on the 3DCityDB as feedback to be considered for the new developments. Could you provide us with some thoughts on your experiences? What is good / what is bad when working with the 3DCityDB? What are features / structures that shouldn't be changed (much)? What could / should be improved?

Best regards Thomas

Am 11.05.21 um 12:50 schrieb Giorgio Agugiaro:

Hi,

first of all, this is not an issue per se, but just an info request. I refer to your comment:

"All objects having an identifier are registered in the CITYOBJECT table. In terms of CityGML and ADEs, this means all types derived from |gml:AbstractGMLType| and not just types derived from |core:AbstractCityObjectType|."

It seems to me that this applies to ADE objects /only/. For "standard" CityGML objects (not derived from _CityObject), the classic mapping rules still apply, i.e. they are no data stored in the CITYOBJECT table. E.g. Addresses, Appearances. etc.

• Did I understand correctly?
• Are these ADE mapping rules documented somewhere?

Thanks for your help!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/3dcitydb/energy-ade-citydb/issues/7, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUILVQIHZPSWHA265HOT43TNEDYLANCNFSM44VDAZ6Q.

--

---

Prof. Dr. Thomas H. Kolbe Email: @.*** Chair of Geoinformatics WWW: http://www.gis.lrg.tum.de Technische Universität München Secretary: +49 89 289-22578 Department of Aerospace and Geodesy & Phone: +49 89 289-23888 Department of Civil, Geo, and Fax : +49 89 289-22878 Environmental Engineering
Arcisstraße 21, 80333 München, Germany

Chairman of the Round Table Geoinformation Systems (Runder Tisch GIS e.V.) http://www.rundertischgis.de/

Member of the Leonhard Obermeyer Center - TUM Center of Digital Methods for the Built Environment http://www.loc.tum.de

[gioagu]

Hi Thomas,

thanks for your quick reply. I will have a look at the thesis of Zhihang. One of the reasons is to understand how to "tweak" the current rules, as (I hope) the number of resulting tables might be further reduced (e.g. in the case of the Energy ADE).

I will try to provide some constructive thoughts about the current implementation of the 3DCityDB - but I guess somewhere else than here in energy-ade-github :-)

All the best,

G.

[clausnagel]

Hi Giorgio, yes you are right, it mostly applies to ADE object types. The reason is that we didn't want to touch the core schema when we added the ADE support. Not all feature or object tables of the core schema (like address or appearance) are linked with cityobject (i.e., they do not reference the id column of cityobject with a foreign key) and we didn't change this. Thus, adding a tuple for them in cityobject would not make sense. For the same reason we also kept the table name cityobject and didn't change it to something more general.

As Thomas wrote, we are about to start the work on the next major version of the 3DCityDB. This will also allow us to redesign the core schema and make it more consistent.