Spanish Cadastre/Buildings Import/Data Conversion/Problems
Issues related to the reduction of the data set.
Buildings with multipart geometries
The Building data set contains two types of geometries.
For more information consult the wikipedia: WKT
Solution: Buildings with multipart geometry are separated by this algorithm.
Building parts below ground level
The building parts layer contains geometries with the fields:
There are parts of buildings that do not have levels above the ground. These are generally parts that are outside the footprint of the building or that correspond to elements such as stairs. If both the number of levels above and below ground is zero, the part corresponds to a porch.
Solution: During tag transformation it will be assigned building:part=roof to the building parts without levels above and below ground ('numberOfFloorsAboveGround' = 'numberOfFloorsBelowGround' = 0). The algorithm building parts outside the building footprint removes the rest of the building parts below ground.
Reduction of building parts
In the data set of building parts, only two attributes are imported, the number of levels above and below ground. The set contains buildings with adjacent parts that have the same level values. Their number can be reduced by merging the geometries of these parts into one.
Another strategy to further reduce data is to delete those building parts whose levels match the maximum and minimum value for the building. These values can be transferred to the building footprint and the parts, as they do not contain any other information, are redundant and can be deleted. In these cases, the building parts will not cover completely the footprint.
The resulting 3D scheme works correctly on some renders, but not on others.
The left image shows how, for the same data set, with the Glosm render, the value of Key:building:levels of the building prevails over that of its parts. With the OSM2World render, the number of levels of the parts prevails over that of the building and the later is used only in the building areas not covered by parts.
Solution: Algorithm for reduction of building parts.
Detection of swimming pools inside buildings
Some pools may appear located within the building footprint. In these cases, the Cadastre data contains two entries with identical geometry, one in the pool data set and another in the buildings parts data set. The building part with the same shape of the swimming pool is used to define the cavity that holds the water on the roof of the building. Using the tags location=roof and layer=1 in the pool, the matching building part is redundant and can be deleted. The inner rings of building geometries that are equal to the swimming pool can also be deleted. If the entire building is equal to the swimming pool, the reviewed cases show that they are false buildings and can also be deleted.
Sometimes, these swimming pools are not located on the roof of the building, but inside. There is no way to identify these cases automatically and they are left for manual review.
Solution: Algorithm for detection of swimming pools inside buildings.
Building parts outside the footprint
In the 3d model in use, the parts of buildings must be contained within the building's outline. However, in the Cadastre data we can find parts outside the footprint, even after removing the underground parts. The image shows an example. In green the contour of two buildings and in red external parts, on the left the seen from the front and on the right seen from above.
They correspond to building parts on a sloping ground that are below ground to one side and above ground to another. There are two possible solutions. The first is to expand the footprint of the building to encompass the external annexed parts and promote the part to building when it is not attached to the footprint. The second is to eliminate these parts of the import.
You can also find 'orphan' building parts, that is, there is no associated building.
Solution: The algorithm building parts outside the building footprint deletes the parts outside the building footprint if it exists. If it finds parts without an associated building, it does not eliminate them and generates an outline from the union of the parts.
In most cases, the Cadastre building layer has an estimated accuracy of 0.1 meters. We can find closely spaced nodes separated by a few centimeters. They can be consecutive in the same geometry or belong to two adjacent buildings. Its existence can imply topology errors and complicates the resolution of this problem and that of unneded nodes.
The Cadastre data contains an excessive number of nodes for each geometry.
Solution: To identify and delete an algorith to simplify geometries is used.
Issues related with data quality.
The Cadastre data may contain topological errors. Topological errors can result in overlapping geometries instead of being adjacent.
Solution: algorith to simplify geometries.
Vertices with too low angle
The original data contains geometries with vertices that form an angle with the adjacent vertices too small. They look like the result of having made a difference between two polygons with segments that should be adjacent but topologically incorrect. This problem is not detected by the JOSM validation tests.
Another variant is to find two consecutive vertices with low angle (in 'zig-zag').
Solution: The algorithm to delete invalid geometries also deals with this problem.
The original data contains buildings or parts that seem to be the result of having made a difference between polygons with sections that should be adjacent but topologically incorrect. This problem is not detected by the JOSM validation tests
Issues related to the import preparation
Split of data in tasks
It's no convenient to upload to the OSM servers big amounts of data at a time. That's why it is necessary to divide Cadastre data, which cover an entire municipality, into smaller fractions or tasks. It is proposed to use the task manager to create projects for the data to be imported.
We can use the <CadastralZoning> elements to split the data in tasks. These elements can be of two types according to the value of the field <cp:levelName>:
It is important that the ways contained in each task do not share nodes with the ways contained in another task. If not, before uploading a task, it would be necessary to check if there are matches with the existing nodes and merge them to avoid duplicates. For this reason, adjacent blocs are merged before using them.
Througfare names correction
Througfare names in the addresses dataset are in capital letters, without accent marks, they contain abbreviations and information not belonging to the name. It is necessary to correct the names according to the normalization rules (es). In addition, the name of the througfare in the Cadastre data may contain errors or discrepancies with respect to the information collected on the ground.
Solution: Process for througfare names conflation.
Problems with addresses
This image shows some of the problems we can find with the addresses. It is a combination of the OSM map, Cartociudad portal numbers (the small labels) and the converted Cadastral data for buildings and addresses. The addresses of type "entrance" show the icon of a door and those of type "parcel" a blue icon of the number plate.
Solution: Addresses are asigned to diferent elements according to this table: