- 1 Description
- 2 Entity list
- 3 Quality of GRB data
- 4 Additional information
This page describes all different GRB data types (entities) and their details. We also add the OSM mappings and the level of usefulness for OSM for each unique subtype by mapping objects.
- 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.
|loopbrug||pedestrian raised bridge, mostly covered bridge connecting two buildings (can be found between high office towers or in factories)||?||Not imported|
|trap||a steps area connected to a building (like in front of an entrance of a building) source data uses area. Problem, Proposed tag cannot be placed on area by tag convention, see highway=steps. Mapper needs to change this manually to a way. Good source data however.||highway=steps||Imported. Exported as an area (needed for manual mapper to correct this to way).|
|zichtbare onderkeldering||We have no clue what this is.||?||Not imported|
|ingezonken garagetoegang||ramp of a garage entrance below ground level||?||Not imported|
|uitbreiding||AFAIK, a regular building. The meaning of the word is extension, only a few in the source data like that||building=*||Imported and exported|
|verheven garagetoegang||ramp of a garage entrance above ground level||?||Not imported|
|verdieping||building that's not on the ground (so you can walk below it), but not a roof either. Need user verification. Usually in OSM a footway is already there. Connect the corners and tag accordingly||building=* but add level tags and/or tunnel=building_passage on the way below||Imported and exported.|
- Note: in this context, imported means "imported into our working database", not "imported into OSM"! Exported means "loaded into JOSM". Which "exported" objects are imported into OSM is then up to mapper discretion.
- Gbg: Regular building (GeBouw aan de Grond, building on the ground). use Replace Geometry function from JOSM utilsplugin.
|hoofdgebouw||A building, almost always has associated address information||building=*||default: building=house. When merging with existing buildings the building key is often cause of conflict, which is good because OSM data is often better categorised that GRB. GRB only makes 2 major distinctions, this one and bijgebouw. Toolset also checks if the building has address data or not to decide over the type of building.|
|bijgebouw||secondary/adjacent building. Never has associated address data.||building=shed/hangar/...||default: building=shed Watch out for existing hangars/greenhouse/garage. You need to resolve any conflict when merging with an existing OSM building.|
|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).||N/A||This building is imported, not exported (since it shares nodes sometimes with other objects). Postprocessing will remove the way from Postgis DB that provides GRB vector layer for the toolkit.|
- 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 . Are imported and easily remapped due to detailed distinctions
|waterbouwkundige constructie||In the extract I used: bogus data||Not wanted in OSM.||Not imported|
|cultuurhistorisch monument||Small elements, most likely chapels, but there's no subdivision.||Not interesting now||Skipped for import.|
|hoogspanningsmast / openbare TV-mast||Tall construction sporting wires or antennas||power=tower / man_made=mast||Imported and exported: man_made=mast only. TV mast seems less accurate.|
|pijler||???||Skipped for import.|
|rooster||???||Skipped for import.|
|schoorsteen||chimney||man_made=chimney||Imported and exported.|
|koeltoren||Cooling tower||man_made=tower + tower:type=cooling||Imported and exported.|
|silo / opslagtank||storage tank||man_made=storage_tank or man_made=silo||Imported and exported: man_made=storage_tank, man_made=silo|
|cabine||Electrical, gas or other cabine||N/A||Skipped for now.|
|watertoren||water tower||man_made=water_tower||Imported and exported: man_made=water_tower|
|tunnelmond||tunnel exit||probably doesn't belong in OSM||Not imported in DB.|
|chemische installatie||man_made=works||Chemical installation, piping, long structures commonly found in petrochemical and heavy industries.||Imported and exported: man_made=works|
|golfbreker (strandhoofd en lage havendam)||Breakwater installation, a bit vague on subtypes.||man_made=groyne (perhaps also man_made=breakwater)|||Not imported (remapping a bit unclear)|
|havendam||Another type of breakwater installation.||man_made=breakwater||Not imported (remapping a bit unclear)|
- Lbz : zones used for internal management of GRB, no use in OSM
- Sbn : railway area
|railway area||The bedding (or street) where rails are located. (split per type of usage: train, tram and metro)||landuse=?||Not imported.|
- Trn : public terrain that doesn't fall under highway area (mostly unregulated parking space). Very sparse data, so not useful for an import. Import Toolset defaults: Not imported.
- 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. Import Toolset defaults: Not imported.
- Wga : highway-related feature
|bushok||shelter at a bus stop||amenity=shelter + PT tags||Skipped for import.|
|telefooncabine||Public telephone cabin. There should be none left in Flanders as the last one was removed on Oct 1 2015.||N/A||Not imported|
|overdekte fietsstalling||Covered bycicle parking||amenity=bicycle_parking + covered=yes||Skipped for import.|
|bergplaats||storage shed (not really compairable with OSM shed)||no idea how to map||Not imported|
- Wgo : highway border per usage type (no areas, but the borders can be combined to areas) Import Toolset defaults: Skipped for now
- grens circulatiezone zwakke weggebruiker (Wcz) : boundary of the pedestrian area (not every way has this, cannot always be close). Import Toolset defaults: Skipped for now
- rand van de rijbaan (Wrb) : boundary of the motorised area (most inner boundary, can always be closed). Import Toolset defaults: Skipped for now
- 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. Import Toolset defaults: Skipped for now
- Wgr : ditch waterway=drain (not oriented in a meaningful way). Import Toolset defaults: Skipped for now. But it can be used to draw manually. In JOSM validation will actually check the waterflow and warn about direction so you can fix the orientation problem. But it needs to be connected to other waterways. But it is easy addition when editing.
- Wkn : way knode (endpoint of a way), only one case is useful. Import Toolset defaults: Skipped for now
- Wni : lenghtwise highway element. Import Toolset defaults: Skipped for now
- Wpi : pointshaped highway element. Import Toolset defaults: Skipped for now but good candidate to add when test phase show good results. Seems quite accurate and detailed in cities area's.
- paal : pole, mix between highway=street_lamp and man_made=power_pole, sometimes both
- meerpaal : mooring pole
- bovengrondse brandkraan : fire hydrant (above ground) emergency=fire_hydrant
- grenspaal : boundary stone historic=boundary_stone
- praatpaal, paal met publieke telefoon : emergency phone emergency=phone
- Wri : manhole covers manhole=* ? Import Toolset defaults: Skipped for now
- Wrl : railway when crossing the highway: too restricted for OSM. Import Toolset defaults: Not imported.
- Wti : transversal highway feature (lower edges of a traffic_calming=table/bump/hump or upper edge of a road lowering (inversed table)). Import Toolset defaults: Skipped for now
- 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. Import Toolset defaults: Not imported.
- Wvb : highway=motorway/trunk/ ... /service/track Follows the center line, and contains the following info about the road. Import Toolset defaults: Skipped for now.
- 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:
- autosnelweg : highway=motorway
- weg met gescheiden rijbanen die geen autosnelweg is : highway=trunk or highway=primary
- weg, bestaande uit één rijbaan highway=primary/ ... / track
- rotonde highway=* + junction=roundabout
- speciale verkeerssituatie : ???
- verkeersplein : ?? pedestrian highway ??
- op- of afrit, behorende tot een niet-gelijkgrondse verbinding : highway=motorway_link or highway=trunk_link
- op- of afrit, behorende tot een gelijkgrondse verbinding : highway=*_link
- parallelweg : highway=tertiary/unclassified/service
- ventweg : same as parallelweg?
- in- of uitrit van een parking : highway=service + service=parking_aisle
- in- of uitrit van een dienst : highway=service
- wandel- en/of fietsweg, niet toegankelijk voor andere voertuigen : highway=path/footway/cycleway (though most are unmapped)
- tramweg, niet toegankelijk voor andere voertuigen | railway=*
- dienstweg : highway=service
- Wlas : streams and rivers (everything wider than 3m) with name and name of watershed. Import Toolset defaults: Skipped for now
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 data is continuously updated by the government. Every change on the terrain that requires permits, is communicated to the GRB team. Once or twice a year, surveyors visit all places that have changed. Everyone can make an "anomaly" to communicate an error in the data. Often, building data will be updated even before it is visible in yearly updated aerial photography, though not always.
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.
The vector layer is exported and simplified with the best algorithm we tested. Even the default percentage in the website is carefully chosen after hundreds of manual tests and validation. Right before sending it to JOSM, all objects are glued together, nodes are joined to ways where needed.
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.). Use the plugin to assist the automated process. It uses safe margins to prevent excessive distortion. The simplify plugin is very good in optimizing it even further. The OSM database stays protected from excessive data like this.
The semiautomated toolset will join the combination of different entities described here. It will make sure roofs are attached to buildings and that silo connect to the works they belong to. So everything that shares a node within a small margin will be joined. This avoids hundreds of warnings in JOSM and makes it modular enough.
Where possible, defaults for the import work are mentioned. The way this DB is set up is that the whole process is automated and repeatable.
Concerning semi-automated import/merge toolset it should be clear that not everything is now imported and/or combined, there is a lot of ground to cover here. We focus on buildings, in particular in combination with address data. Only a fraction of the described entities are now treated. Creating the correct mappings on OSM tags requires study of all the data. Exceptions here determine what is considered a safe candidate for semi-automated processing.
The Import Tool toolset matches the address data of the imported entities. It will pre parse addresses from GRB datafiles to figure out what to address and how. it will do a few things intelligently:
- It will match address data and map to OSM addr:*=* keys.
- Special care for the numbering scheme. Different house numbering methods are filtered and made consistent. The default when in doubt is to drop the address data and not match it with the building unique ID's.
- Address (specifically house numbers) designations is filtered with local knowledge in mind, e.g. How we would all write it on a letter sent with the postal service. For OSM that means we sanitized to the current addressing rules. If that didn't work out, address data is dubious and dropped.
- Buildings that have 2 different streetnames (this seems to be possible in GRB data but not in OSM) in the source data are exported without address tags by default. To complete that data we have the existing toolset: http://crab-import.osm.be/import.html (alternative http://aptum.bitless.be/ ). It's compatible and complimentary, together reaching the virtual 100% addressing is possible.
Post processing with CRAB
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, the CRAB tool has quality indicators on board to monitor completeness. The recommended way to get good addressing is use to GRB tool before CRAB. Use CRAB tool to complete and verify (it has built in validation checks too)