GRB Building import preparations - feedback needed

For this particular occasion, I’ll try and post this in english.

It’s a public secret that Glenn has been working on an import method, to get chunks of building data from GRB into OSM.
In an attempt to get as many usefull tags along with a such import, there’s work going on, which we label as ‘preprocessing’ data.

The general idea is that, based on elements like building sizes, building heights (according to DHMV), tags in the GBA baselayer, and the OSM landuses it’s contained within, we have an ‘as close as possible’ approximation of what type of building we have. So no import with just ‘building = yes’, but we want to try and figure out which are houses, which are shops, which are appartments, …

The work that’s been done so far (mind you, it’s a work in progress and bound to update every now and then) can be viewed here:

From that link, it’s best if you select the option ‘enable info window’ on the top left of your screen, and in the layer menu on the right, check the GRB-GBA layer.
If you’ve got that set up, upon hovering your mouse over buildings, you’ll see a list of data attributes.

We are particularly looking for your feedback on the contents of the field ‘auto_building’: Where it makes incorrect assumptions, and ideally how you feel we could have detected the correct use.

For reference, this is how it should look:

Hi Tim,

In Leuven there are many tall buildings with flats, which are not apartment buildings, just large houses with student rooms in them. Is it possible to detect the roof shape and take that into account? Apart from that it’s looking good. It would be nice to use more colours for distinguishing between building=apartment and building=house and possibly other types.



A few remarks/clarifications. The “flat” problem in Leuven cannot come from the logic in the postprocessing phase since nowhere in the code I assign a flat in the decision tree, I haven’t covered that one yet. You need to look at the “detection_method” field to know where it came from. I’m 100% sure that flats in this case comes from OSM data. If a building is marked as a flat in OSM, we regard this information to be of more value than the automated selection so we retain this information. So if those flats are wrong, you can just go in JOSM now already and change them, the OSM data is imported regularly so fixing OSM will also improve this postprocessing.

the detection_method is what interests me the most in case of a problem, feel free to copy/paste the key/value pairs from the information pane to report a problem.

The look/feel from this viewer is really not my priority, I just whipped it up real fast to have a slippy map where I can view the data visually. I can do distinguish between values but take into account that we’re dealing with several different databases here. The vector layer is the GRB export-ready data, it’s not OSM data, the houses are not OSM sourced, the tag “building” is used to select colors, not the auto_building tag (yet). the “building” tag is in fact how the database processing phase filled out the value, basically, 3 main values: house, yes and shed

The use of ‘shed’ has been drastically lowered using this method.

So, in nutshell : this is what we do to determine the auto_building value:

  • we check for roofs first as they are an exception
  • we check OSM data for a building that exists in that place
  • we check for landuse where the building is encompassed by

We use the following variables are taken into account in one or more ways

  • area size of the OSM building
  • area size of the GRB building
  • area size of the overlap between GRB building and existing OSM building
  • presence of addr:* tags
  • presence of addr:flats tag
  • height of the building
  • existing OSM value for building at the same place (with enough overlap)
  • combination of all the above , from simple to complex parsing

landuses covered:

  • village_green, residential, industrial, commercial, farmyard, farmland, meadow, grass, retail

source DB’s used :

  • GRB
  • 3D GRB
  • belgium pbf OSM dump (daily)

3D data is matched exactly on OIDN , UIDN and entity. 3DGRB data is much older than GRB data so exact matching can fail when a building got an update and it’s UIDN changed.

3D data is not good enough to spot roof shapes, it’s good enough to spot a tower/peak at a church but it’s not used in that way yet.

I’ve received a request from Jakka to elaborate on some of the data fields used.

Copying my reply (in dutch) here for reference:

detection_method = debug hulp zodat ik snel weet welk stukje code van toepassing was, staat ook meer info in , bv: “derived from OSM landuse: retail” , dwz: landuse logica gebruikt, en value ervan was ‘retail’. kan ook zijn : ‘calculated-derived (has nr , not too tall)’ , dat wil dan gewoon zeggen: ik heb gezien dat er een huisnummer aanwezig is en niet echt groot is.

size_source_landuse= oppervlakte van gematchte landuse (kunnen meer matches zijn maar er is al preselectie)
auto_target_landuse= landuse dat van toepassing is hier.
size_grb_building = oppervlakte dit gebouw in GRB

meest geavanceerde is dit

detection_method: “from existing OSM building source: house ,hits (1)”
auto_building = house
size_shared = 747.81
size_source_building = 747.81

wil zoveel zeggen als : er is een huis in de OSM data dat oftewel gans binnen het GRB huis ligt, oftewel kruisen de huizen deels (omwille van kleine en grote verschillen tss data komt dit zeer vaak voor als je de huizen vergelijkt.). Wanneer ze kruisen, bedraagt de oppervlakte van de deelverzameling wat er in size_shared staat. size_source_building is de oppervlakte van dat specifiek gebouw in OSM.

hits wil zeggen het aantal kruissingen, dus als er 3 staat dan kruist het nieuwe GRB gebouw met 3 bestaande gebouwen. Daar gebeurd dat een berekening op om selectie te maken, bv: hoeveel percentage het huis deelt met het ander gebouw. Als dat bv maar 0.01% is , dan overlappen de woning maar een heel klein beetje, te weinig om met zekerheid te zegggen dat we de OSM tag zomaar moeten overnemen. In de praktijk is dit een van de meest voorkomende situaties en vermijd je zo dat lichte crossing buildings in de bron teveel invloed hebben op de selectie.

Additional info / where we’re at (well, where Glenn is at).

As a ‘proof of concept’, have a look at this:

Basically, it shows the difference between current OSM, and what it would look like with all GRB buildings in it.
Move the slider at the to slide the border between the two styles. I’ve deliberately picked an area with alot of missing buildings.

This shows the huge potential there is to be adding buildings.
However, before we can actually put it to use, we need to get working on the ‘administrative side’ of things.
There’s no option to ‘just import this and hope we get away with it’, we’re doing this by the books.

Which means we’ll need to make a proper, documented case before we move ahead.
And in that area, Glenn is looking for some help. I’d probably be best if I let him specify what exactly he needs though.

Re-post one day later, after Escada noticed reply never arrived for moderation :

Waarde Tim,

Eens wat gebouwen in een gevarieerde buurt - van oorsprong huizen / van oorsprong appartementen / huizen omgebouwd tot appartementen in Antwerpen > Berchem bekeken : veel appartementsgebouwen die ook als zodanig werden gebouwd staan als house getagd.

Op OSM > edit een aantal van die gebouwen bekeken : allen zijn daar building=yes, van die welke niet als app’t zijn getagd werden sommige als house, andere als app’t herkend.

Sommige auto-building tags = house zijn voor een HN-max en HN-p99 van 22 meter, terwijl een ander gebouw met HN = 16 correct als residential en apartments werd aangemerkt. Dat (app’t gebouw) ernaast dan weer niet, en dat aan de andere zijde straat evenmin.

Hoe kan ik u hiermee voort helpen Serie prentjes op Mapillary met mijn OSM u/name?

Met de hand building=apartments en floors=n invoeren lijkt tijdrovend; hebt u toegang tot een adressen en bussen bestand? (ongetwijfeld! CRAB!)

Met als immer vr. gr.,


Voor wat betreft Mapillary: als je locatie doorgeeft (adres in de buurt) kijk ik wel even de info na volgens je comment.
Ik pluis even uit wat voor criteria aangenomen is voor de selectie als apartment.

Crab is geen slecht idee - misschien kunnen we conclusies trekken uit een hoger aantal geregistreerde adresposities binnen de footprint van het gebouw. Het aantal verdiepingen achterhalen lijkt me minder evident.

Voortgaand op CRAB : hoe open ik zo’n .gml bestand onder windows10?

LibreOffice > scalc.exe is al een tijdje met verve aan de slag, zonder resultaat.

Google geeft diverse (betaalde en kosteloze) pakketten ; Tatukgis is een Poolse firma die een free viewer beschikbaar stelt : zie ik daarmee ‘alles’ waar het de adres info betreft, of is er een betere keuze?