WikiProject Belgium/GRB

From OpenStreetMap Wiki
Jump to: navigation, search

Description of GRB data types and usefulness for OSM.


  • Adp: Administrative parcels: Not useful due to convention that these don't belong in OSM
  • Ano: Anomalies (mistakes and new developments): should be used together with other data types, to see if a new development is happening or a mistake is reported
  • Gba: Building attachment: Partially useful for OSM:
    • afdak : building=roof
    • loopbrug: ??? pedestrian, mostly covered bridge connecting two buildings (can be found between high office towers or in factories)
    • trap : ??? a stair area connected to a building (like in front of an entrance of a big building)
    • zichtbare onderkeldering : No idea what this is
    • ingezonken garagetoegang : ramp of a garage entrance below ground level
    • uitbreiding : AFAIK, a regular building=*
    • verheven garagetoegang : ramp of a garage entrance above groun level
    • verdieping: building that's not on the ground (so you can walk below it), but not a roof either.
  • Gbg: Regular building (GeBouw aan de Grond, building on the ground)
    • hoofdgebouw : building=*
    • bijgebouw : side building: building=shed/hangar/...
    • gebouw afgezoomd met virtuele gevels : Doesn't belong in OSM. This building is roughly estimated from street-side measurements without aerial data (so the depth of the building is always 5m)
  • Gvl : The building sides split up by measurement method used (measured from the street, from imagery, estimated, ...) can be useful to deduce the quality of the buildings, but not wanted in OSM.
  • Gvp : point of a building with annotated measurement method. Not useful for OSM.
  • Knw : Different man-made objects
  • Lbz : zones used for internal management of GRB, no use in OSM
  • Sbn : railway area landuse=? (split per type of usage: train, tram and metro)
  • Trn : public terrain that doesn't fall under highway area (mostly unregulated parking space). Very sparse data, so not useful for an import
  • Wbn : highway area landuse=* every crossing is a different area, so it uses the "plumbing" principle, but it overlaps other landuses where separation isn't clear (in rural areas). Slightly over-noded, possibly not suited for import.
  • Wga : highway-related feature
    • bushok : amenity=shelter + PT tags
    • telefooncabine : (there should be none left in Flanders as the last one was removed on Oct 1 2015)
    • overdekte fietsstalling : amenity=bicycle_parking + covered=yes
    • bergplaats : storage shed, no idea how to map
  • Wgo : highway border per usage type (no areas, but the borders can be combined to areas)
    • grens circulatiezone zwakke weggebruiker (Wcz) : boundary of the pedestrian area (not every way has this, cannot always be close)
    • rand van de rijbaan (Wrb) : boundary of the motorised area (most inner boundary, can always be closed)
    • grens onverharde zone (Woz) : boundary of the paved zone (cannot be closed, is cut at every place where a private paved area touches a highway - like a service way or path), probably not suited for import
  • Wgr : ditch waterway=drain (not oriented in a meaningful way)
  • Wkn : way knode (endpoint of a way), only one case is useful:
  • Wni : lenghtwise highway element
    • verhoogde boord- of kantsteen : kerb=yes (looks like this data isn't very consistent, so perhaps not suited for import)
    • muur, stootband : small wall, enough for barrier=wall ?
    • vangrail : guard rail barrier=guard_rail
    • niet-afgeboorde verhoging : rest-category, not mappable
  • Wpi : pointshaped highway element
  • Wri : manhole covers manhole=* ?
  • Wrl : railway when crossing the highway: too restricted for OSM
  • Wti : transversal highway feature (lower edges of a traffic_calming=table/bump/hump or upper edge of a road lowering (inversed table))
  • Wtz : water area natural=water, these are tagged a lot wider than the average upper water level, and often include the grassy riverbanks. So perhaps not suited for import due to differing definitions
  • Wvb : highway=motorway/trunk/ ... /service/track Follows the center line, and contains the following info about the road.
    • Left and right name (equal in most cases) : name=*, name:left=* and name:right=* (left and right aren't needed in OSM when they are equal)
    • National reference ("ng" means no reference) : ref=*
    • Left and right municipality name (equal in most cases, unequal on boundaries) : not needed in OSM
    • surface (paved or unpaved): surface=* (though more difersity is sometimes wanted in OSM)
    • road class, choice among:
  • Wlas : streams and rivers (everything wider than 3m) with name and name of watershed

Buildings import

Quality of GRB data

GRB building data has two quality levels: measured and drawn from aerial imagery.

  • The measured data is always very precise (more precise than anything we can achieve), but may be outdated a few months.
  • The data derived from aerial imagery is about as good as we can achieve in OSM with mapping from correctly aligned pictures.

In general, everything that can be measured from public roads is also measured. So the front sides of the buildings are measured, the back sides aren't.


The GRB buildings data seems to have around 10% useless nodes. This mostly comes from their measurement process. If they can't measure a back corner of a house, they measure a point in the side wall. That measurement point is then used to map the rest from imagery. But that measurement point is always on a straight line, so useless to OSM.

As the difference made by the node to the shape is always very close to zero (the only difference is a rounding error), it's easy to delete these nodes with the simplify-area tool from JOSM (a plugin) using very strict settings (1m deviation, 10° angle, 3m² area f.e.).

Combining with CRAB data directly

According to the documentation, a GRB-to-CRAB table is included for certain data types so all buildings with addresses also have that info (In a .dbf file. This file name starts with 'Tbl' and then the datatype follows and then 'Adr' . ex: TblAdpAdr46024B500.dbf and TblGbgAdr46024B500.dbf ) It makes the process a lot easier, though we must also still take the errors in CRAB into account (which is why the CRAB import has been done manually so far). These addresses do not always match with AGIV, hence it's important to use these on buildings that haven't got any addressing yet. We should still use the CRAB import tool to correct and review this data later on. Luckily, this tool has quality indicators on board to monitor completeness.