Adding better metadata to GeoAdmin 3D Tiles

[RobertoMinelli]

Dear all,

I have a question about CesiumJS, 3D Tiles, and the GeoAdmin API.

Each 'feature' (i.e., Cesium3DTileFeature) in your implementation of the Cesium3DTileset specification only contains a little number of properties with respect to the one contained in the KLM files part of your swissBUILDINGS3D 2.0 dataset. In particular, you only include the properties belonging to the <ExtendedData> tag. To be clear, I mean these:

<ExtendedData>
<SchemaData schemaUrl="doc.kml#kml_schema_ft_n_p">
<SimpleData name="UUID">36811E50-3A02-404B-AD3F-2BB6CB940500</SimpleData>
<SimpleData name="DATUM_AENDERUNG">20160226000000</SimpleData>
<SimpleData name="DATUM_ERSTELLUNG">20160226000000</SimpleData>
<SimpleData name="ERSTELLUNG_JAHR">2016</SimpleData>
<SimpleData name="ERSTELLUNG_MONAT">2</SimpleData>
<SimpleData name="REVISION_JAHR">2016</SimpleData>
<SimpleData name="REVISION_MONAT">2</SimpleData>
<SimpleData name="GRUND_AENDERUNG">Verbessert</SimpleData>
<SimpleData name="HERKUNFT">3D-GebCH_T2016</SimpleData>
<SimpleData name="HERKUNFT_JAHR">2015</SimpleData>
<SimpleData name="HERKUNFT_MONAT">6</SimpleData>
<SimpleData name="OBJEKTART">Gebaeude Einzelhaus</SimpleData> <SimpleData name="ORIGINAL_HERKUNFT">3D-GebCH_T2016</SimpleData>
<SimpleData name="GEBAEUDE_NUTZUNG">n_p</SimpleData>
</SchemaData>
</ExtendedData>

The <Location> property — that can be beneficial for a number of uses — does not figure among the properties of a 'feature'. Instead, this is available in the KML files.

Here the corresponding <Location> property for the <Placemark> above:

<Location>
<longitude>9.05441937714414</longitude>
<latitude>46.0933781323267</latitude>
<altitude>0</altitude>
</Location>

I was wondering whether it is possible to integrate it into the 3D tileset offered by your API. It would be fantastic as it would allow me to do things like coloring the map given the distance from a point, as it is done in this example.

Thank you in advance, I wish you all a good day.

Roberto

[davidoesch]

@oterral can you check why this info is not available?

[RobertoMinelli]

Thank you @davidoesch and @oterral, I would really appreciate this feature.

[oterral]

We can add it if I regenerate the tileset, but does Topo allow us to publish the coordinates?

[RobertoMinelli]

The coordinates of EGIDs are already part of the layer ch.bfs.gebaeude_wohnungs_register (Register of Buildings and Dwellings). So I believe that it is possible to publish them.

From a software engineering point of view, instead, I believe you should have the concept of Building as first class entity. A Building is a collection of 1+ features (i.e., a Cesium3DTileFeature with an UUID).

My proposal is the following:

You introduce the concept of Building. Each Building:

• has unique ID that identifies it;
• knows a list of EGIDs that are inside its perimeter.

Each feature (Cesium3DTileFeature):

• knows the ID of the Building that contains the feature.

In this way, we can have a precise and efficient way to obtain, given a 2D point and the clicked feature, the list of all EGIDs of the Building that contains the feature.

These are only my 2 cents.

Best, Roberto

[davidoesch]

The data owner of buildings (swisstopo) is informed. The data owner of EGID (BFS and Canton) will be contacted.

[beat-github]

The inclusion of EGID is a key objective for the ongoing development of swissBUILDINGS3D. If an EGID exists for a building, the partitioning of the building will be defined using this identifier in the future. In addition, the EGID will be included as an attribute or key in the data model.

Unfortunately, we can not give you any time frame for this implementation. We are currently developing methods for an efficient allocation of EGID to our building data.

[RobertoMinelli]

Hi @beat-github, yes I totally agree that swissBUILDINGS3D should include the list EGIDs.

By "partitioning of the building" you mean the different UUIDs that compose each building?

1+ UUIDs = 1 building and 1 building = 0+ EGIDs. Right?

[beat-github]

I'm not sure to understand your equation (1+ UUIDs = 1 building and 1 building = 0+ EGIDs) right.

With the help of the EGID we will try to do a logical division of the building (partitioning) at swissBUIDLDINGS3D. The concrete implementation is currently being defined. We work on it...

[RobertoMinelli]

I am saying, correct me if I am wrong that:

Each building is composed by 1+ UUID (I think this is what you call 'partitioning')

Each building has 0 or more EGIDs associated to it.

Am I right?

Best, R

On Apr 16, 2018, at 16:21, Tschanz [email protected] wrote:

I'm not sure to understand your equation (1+ UUIDs = 1 building and 1 building = 0+ EGIDs) right.

With the help of the EGID we will try to do a logical division of the building (partitioning) at swissBUIDLDINGS3D. The concrete implementation is currently being defined. We work on it...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[oterral]

SO @davidoesch what do we do for the Latitude Longitude , do you want I add it for the next release of swissbuildings ?

[davidoesch]

This has to be defined by the data owner. I'm waiting for feedback on this

[oterral]

Still no clear answer ?

[oterral]

@davidoesch

[davidoesch]

Topo needs to redeliver the data. See internal mail

[RobertoMinelli]

Hey, what is going on?

I received many notifications and I realized that two years have passed since my post, and you are still debating on the addition of coordinates to UUIDs in the swissBUILDINGS3D dataset (which are already part of the layer ch.bfs.gebaeude_wohnungs_register (Register of Buildings and Dwellings).

There is a single thing you should be focusing if you want to create a useful swissBUILDINGS3D dataset, which is what I suggested two years ago: Introduce the concept of BUILDING and not of random, unordered, unlinked pieces (e.g., UUIDs that are either a facade, two facades, a piece of roof).

Each Building should have:

• a unique ID that identifies it (which is not the UUID);
• a list of EGIDs that are inside its perimeter.

Then, there are low-level features (e.g., UUIDs, Cesium3DTileFeature) which:

• know the ID of the Building that contains them;
• know their coordinates (this is what you are discussing).

With this model, we could start reasoning about buildings. Combine pieces of information, visualize them, interact with them (e.g., given a 2D point obtain the list of all EGIDs of this Building).

[boecklic]

Sorry for the spam, a plugin has gone wild. No new comments were added, just existing comments reposted.

[RobertoMinelli]

Still, I believe that this is a very important issue that should be addressed.

[xawill]

I agree

[davidoesch]

Dataowner is informed

[mbuchi]

Are there any updates on this request?

It would be very beneficial for our research, too, since otherwise it is almost impossible to cross-reference the datasets if the EGID is not included. This would be the perfect primary key that is already public.

We realized that EGID is also not part of SwissBUILDINGS 3D 2.0, at least not in the Geodatabase format? Has this request been declined or is there any other reason for that?

[davidoesch]

@RafBov are there and Plans by swisstopo to add EGID to TLM?