WikiProject Belgium/Building and address import/AIV GRB building import/The import guidelines applied

On this page we highlight for each import guideline how we fulfil it.

Import guideline	Required	GRB import
Step 1.1 – Prerequisites	n/a	The GRB data for Belgium contains building outlines, addresses, objects.
Step 1.2 – Community Buy-in	acceptance by the community	Several discussions on the GRB can be found on the talk-be list and the Matrix room. Nobody has spoken out against the import in the 2 years it has been in preparation, a lot of people give their support.
Step 1.3 – Documentation	license, updating the catalogue and the import	The GRB is provided by law under an ODbL compatible license.
Step 1.4 – Import Review	n/a	The import has been the subject of long discussions in irl, on the Belgian mailing list and in our Matrix room. Several test cases have been performed with limited impact in areas with few existing buildings. Dense, advanced areas have also been tested. The tagging has been revised accordingly.
Step 1.5 – Uploading	dedicated user accounts	Data is uploaded using JOSM, dedicated accounts might not be needed as this tool is to assist existing mappers, we prefer drip-feeding the OSM DB. The importer is made aware that they bear the responsibility for the data they add, and that they should check it.
2. Make sure data license is OK	yes	see Step 1.3
3. Document your import on the wiki	yes	see step 1.3 and separate section below
4. Use a dedicated user account	maybe	see step 1.5
5. Check tags	n/a	See separate section below. Some tags should be manually translated, verdieping is one of them. That is usually a floor with a road below but it's not possible to determine this automatically. It can also be a second legal entity/object on top of the other. But since we have Mapillary/OpenStreetCam and free 10 cm detailed aerial imagery from AIV we can determine as a human the correct action. Keep, merge, retag or drop.
6. Work small – you have time	n/a	The merge will be timeless. GRB is also updated and we have accounted for this. The DB(s) will be updated with new information at select intervals. Updates require everything to be rebuilt from zero since it uses the OSM schema and we cannot guarantee that buildings have the same osm_id each import. Hence we use source:* tags to match this data. Keep the changesets small.
7. Don't screw up the data!	yes	The merge is incremental and fluent, since we aren't bulk importing, but rather trickle feeding OSM changes for major screwups is small. Deletes are not really part of the plan unless a complicated merge has to be performed, that's the main reason this is not more than semi-automatic.
8. Don't put data on top of data	yes	The current buildings will NOT be replaced, the mapper is required to use the Replace Geometry plugin (Ctrl+Shift+G) to merge new geometries with existing building data. This is essential in order to account for changes easily.
9. Simplifying	yes	The GRB data is very accurate and comes with government pledged Q/A guarantee, so it suffers from what we call overnoding: too many nodes in an arc and/or circles. An option in the webinterface is provided with a very sane default to prevent this. Sometimes small tweaks are needed with the slider. In the background all different entities are unconnected objects, they will be glued to each other when exporting to JOSM, preventing many validator warnings.