I propose a similar UI as Google Maps to indicate and navigate the different levels in a building/area, which crudely means that we render the respective floor tags when a particular floor is selected. But, here also comes the question of GeoDataBuilding.

In T6274#96978, @mnafees wrote:

I propose a similar UI as Google Maps to indicate and navigate the different levels in a building/area, which crudely means that we render the respective floor tags when a particular floor is selected.

Sounds good to me.

In T6274#96978, @mnafees wrote:

But, here also comes the question of GeoDataBuilding.

@rahn gave an elaborate answer by mail, quoting it here:

Currently all buildings are rendered based on GeoDataGeometry ( https://developers.google.com/kml/documentation/kmlreference#geometry ) information: It's just a loose set of (GeoData)Polygons ( https://developers.google.com/kml/documentation/kmlreference#polygon ) and (GeoData)LinearRings ( https://developers.google.com/kml/documentation/kmlreference#linearring ) which are ALL rendered in the order of z-Value.
Keep in mind that the general structure of GeoData-classes is modelled after KML:

https://developers.google.com/kml/documentation/kmlreference

Currently we really render ALL polygons and associated places - even those obscured inside different floor levels. And of course this takes precious time and drags down performance.
So instead we should just either render the roof or those elements which are available in the "current" level that the user selected.
Currently this is not possible since we lack an entity that provides information about the general structure of the building (minimum level, maximum level, which polygons are associated with which level etc.).

This is why we need to introduce GeoDataBuilding which would hold information e.g. on

• minimum floor level
• maximum floor level
• a set of (GeoData)Multigeometry ( https://developers.google.com/kml/documentation/kmlreference#multigeometry ) entries that correspond to floor levels (so that we can e.g. only render those floor levels below the currently selected one).
• a multigeometry that points to the roof polygons
• other possible meta data like: total height of the building, type, etc.
  
  Initially we could just start with an implementation that just holds the minimum and maximum floor level PLUS a MultiGeometry object as a member that points to the whole set of Polygons and placemarks that belong to the building.
  
  So
• GeoDataBuilding would inherit from GeoDataGeometry
• It would have members + setters and getters for the minimum/maximumLevel as well as for the MultiGeometry that contains the polygons.
• Since there is no Building element as part of the KML spec we need to add it to the mx-namespace in the parser (mx:Building).
• The whole implementation should be consistent with other classes like GeoDataPlacemark, GeoDataPolygon, GeoDataLinearRing, GeoDataGeometry, GeoDataMultigeometry. So please check those classes.
  
  Now once you've created such a class we need to integrate it:
• Inside the parser we need to build GeoDataBuilding objects and evaluate its properties during parsing. This is the actual challenge since the OSM data doesn't hold any semantic relationships that would be of use - so we need to determine that information ourself.
• In the Renderer (GeometryLayer) we need to use the GeoDataBuilding objects in order to properly and efficiently render the buildings. So this code needs to be adapted.
  
  Only once all this refactoring is done (which is non-trivial and pretty complex work) we can start to look into further details:
• Optimizing the code base so that only those polygons inside a building are rendered which don't get obscured by the roof or by the currently selected floor level (this is again non-trivial since this needs some self-developed heuristics).
• show the current floor level in a highlighted manner
• Adding a UI that allows to select the current floor level for a given building (this is the really easy and simple part which can only be really done once all the other hard stuff is there).

I don't agree with

Since there is no Building element as part of the KML spec we need to add it to the mx-namespace in the parser (mx:Building).

though: We parse that information from OSM files, not KML. When we write it back to OSM or KML, it must correspond to the original data. Introducing an artificial building tag is not needed.

@juditbartha For this, I will need to cooperate with you :)

D7252