WikiProject Belgium/GRB

From OpenStreetMap Wiki
Jump to: navigation, search

Description

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.

Source(dutch): see https://www.agiv.be/producten/grb/objectcatalogus/entiteiten/wpi-puntvormige-inrichting

Entity list

Adp

  • Adp: Administrative parcels: Not useful due to convention that these don't belong in OSM

Ano

  • 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

  • Gba: Building attachment: Partially useful for OSM.
Object description Mapping Import
afdak Overhead roof building=roof Imported
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.

Gbg

Object description Mapping Import
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

  • 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

  • Gvp : point of a building with annotated measurement method. Not useful for OSM.

Knw

  • Knw : Different man-made objects . Are imported and easily remapped due to detailed distinctions
Object description Mapping Import
overbrugging A bridge man_made=bridge Imported
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=watertower Imported and exported: man_made=watertower
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)
staketsel man_made=pier N/A Not imported

Lbz

  • Lbz : zones used for internal management of GRB, no use in OSM

Sbn

  • Sbn : railway area
Object description Mapping Import
railway area The bedding (or street) where rails are located. (split per type of usage: train, tram and metro) landuse=? Not imported.

Trn

  • 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

  • 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

  • Wga : highway-related feature
Object description Mapping Import
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

  • 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

  • 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

  • Wkn : way knode (endpoint of a way), only one case is useful. Import Toolset defaults: Skipped for now

Wni

  • Wni : lenghtwise highway element. Import Toolset defaults: Skipped for now
    • 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

  • 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.

Wri

  • Wri : manhole covers manhole=* ? Import Toolset defaults: Skipped for now

Wrl

  • Wrl : railway when crossing the highway: too restricted for OSM. Import Toolset defaults: Not imported.

Wti

  • 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

  • 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

  • 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:

Wlas

  • 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.

Overnoding problem

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.

Automated simplification

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.

Manual simplification

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.


Additional information

Import Toolset

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)


Special:WhatLinksHere/WikiProject_Belgium/GRB