Sharing the experience on import of buildings in Brazil
Posted by smaprs on 31 July 2016 in English.Recently in Brazil the OSM community is getting authorized access to georeferenced building material from city governments (in a registry level of detail) for use in OSM.
Some imports of buildings started, for example, in Porto Alegre, São Paulo and Rio de Janeiro. Many members of brazilian OSM community are helping in many ways with these imports.
There have been found some different peculiarities and procedures between each case, also some similarities, that I would like to share a brief comment, after suggested by fellow mappers.
In Porto Alegre, city government office responsible for cartography also released a layer of geodetic survey marks visible in imagery, so it helps much to adjust imagery offset with precise coordinates, and to adjust previous data in OSM in the area when in conflict with the buidings new data. Convertion of the original SHP to WGS84 and its fields to OSM tags has been done in QGIS.
The main issue in Porto Alegre and Rio de Janeiro (this one still under progress) has been on the internal validation of overlapping vertical layers of building parts, to avoid any sort of conflicts, like “duplicated nodes” or “building inside building”. Previously, it was also checked in QGIS for overlapping between the polygons of new buildings and the existing buildings in OSM, so to filter and remove the new ones where there were already mapped in OSM, and saved the rejected ones in a backup file for further eventual interest in replacing geometry.
Both doccumented here:
Porto Alegre building import
Rio de Janeiro building import
The issue of overlapping building parts:
In Porto Alegre, the original data of vertical building parts was converted to the following OSM tags (translated):
-from original BLOCKS=(1:not tagged),2,3,4… to OSM layer=
(0:not tagged),1,2,3,..
In this case it had not shown much overlapping problems (only 0,1% of cases of duplicated nodes to solve), so the validation could run easier. It was done in bunches of around 40.000 objects (around 6.000 building polygons), to keep under the limit of 50.000 objects for uploading in 1 changeset in JOSM.
I’ve called the two steps of validation as “internal”, concerned only on the data of new buildings, and “external”, involving all OSM existing data in the area too.
After some 15 minutes all internal conflicts can be solved. Then some more 30-60 minutes to solve all external conflicts with OSM previous data (like ways crossing buildings), and finally 100% validated and ok to upload.
In Rio de Janeiro, the data of building parts has fields with more precise topographic data, for elevation (ele), height, and top level (we agreed to name it top_ele=*
, at least as a provisory tag, to ensure to keep this data in OSM because it helps much to solve overlapping conflicts).
But in this case there are no tags for separation in vertical parts.
Apart of this, some buildings were originally mapped as multipolygons (for the negative building parts), many others weren’t.
So, when validating, the buildings with more than one part originally tagged as building=*
in vertical arrangement (around 10% of all) have been detected in the class of “building inside building” conflicts (guess there can be more than a million to validate; so it’s comprehensible that I’ve got deeply annoyed every time I have to read these what.3.words again).
These overlappings need to be solved case by case, comparing, in each building, the top level (top_ele=*
) of all its building parts, so to tag these parts as layer=* according to the superior top levels. It’s been working, though it takes a lot of time.
Another possibility could be arranging those cases in 3D relation of type:building
, but in this case, although building:part
being kept in the database, it’s not considered for OSM 2D basics.
Don’t know much about the other experiences in other cities around the world.
Perhaps similar sort of difficulties would be find in many other cases of building imports around the world as it’s increasing in OSM.
As a last comment, I was wondering if wouldn’t it be nice if there was a software/plugin that could do it. I’m not a programmer, dont’ know how to do it. Just have experienced the manual procedures to solve these cases. I was thinking that what some software could do in this case is something like returning the data of JOSM validator warnings of overlappings like “building inside building” (or performing a similar evaluation), and comparing the levels of building parts, so to tag it as layer=*
(alternatively, perhaps creating a relation of type=building
with its respective members for building:part
).
Sorry if it’s not in good english.
Discussion
Comment from Tomio on 1 August 2016 at 18:05
Seu trabalho de importação e todos os tutoriais que vc criou são um marco importante na história das edições do OSM no Brasil. Parabéns. Vc é o cara!!
Comment from smaprs on 1 August 2016 at 18:15
Resolvi publicar o resumo como você tinha sugerido, Tomio, valeu. Duas coisas ainda a almejar: alguns scripts que ajudem a separar layers em buildings ou criar relação type:building, e em decorrência facilitar para que mais braços possam se envolver, já que de todo modo não elimina o trabalho de validação com o existente. Daqui pra frente vão aparecer progressivamente mais cidades com materiais acessível. Abraço