What you need

How to use

Suggested order

GRB geojson vector data toolset.

You can you use the search below to focus on an area. Good search strings are "Streetname, City", with the semicolon. This helps geocoding. First zoom to your area of interest, the source layer (=GRB vector layer) will load with the bounding box limits. Once you have zoomed in on

your area of intereset, you can load the overpass data. This will match on source:geometry:oidn and source:geometry:entity (oidn is only unique per entity layer). You should hit the Filter button now before exporting
this to JOSM. Try to keep the areas small, there is a max size limit a request for JOSM can have.

Change 'verdieping' to building, there is usually a way underneath this building , make sure to connect this way on the sides of the building and split the interior part off, tag this way with for example: highway=footway , tunnel=building_passage. This will fix the validator warnings you will get.

Excess node removal (disabled)

The server returns a simplified version of the vector, the following postgis function is used ST_SimplifyPreserveTopology($geomfield, 0.2). It seems to be good enough to keep nice round shapes while lowering the overnoding.

It turned out that doing this should happen in JOSM, when structures are attached to one another. Doing so here will prevent geojsontoosm from combining nodes as references. It does a good job connecting everyting that it exports within boundaries, but it will not attach a node to a way, it only joins adjacant nodes within a certain margin. In JOSM you do: CTRL+y

Key/Tag details

man_made = bridge

The GRB database contains the outlines of the bridge. In OSM we can use man_made = bridge for this. Please check the wiki rules on completing the area around these structures. You need to do some connecting work.

man_made = mast

man_made = mast is a hard one. In GRB they outlines are described using a way, that information is quite exact in fact. The issue here transforming this to OSM is that we use a single node there. It would be easy to reduce the way to a node in order to facilitate merging. At the moment I keep the ways, so you need to search in JOSM for these type of ways to verify if a node exists.

man_made = *

These are the counts for the rest of the man_made object. GRB and OSM matching for these structures is fairly straightforward.

 count |   man_made   
    41 | pier
   127 | breakwater
 44385 | storage_tank
  1232 | works
   648 | chimney
   738 | watertower
   169 | groyne
    63 | tower
 10037 | mast
  4892 | bridge

building = house or shed

In short: rule of thumb: used a simple convertion using hoofdgebouw/house and bijgebouw/shed. GRB makes no significant deeper differentiation. Bigger structures will usually need adjusting, when merging you should get notified. In JOSM you can search for big buildings using area queries. It's very powerful, then you zoom too the bigger buildings and merge down.

in GRB there is a difference between 2 distinct type of buildings. The big divider is usually having an address or not. Type-1 buildings from GRB translate to building = house. You need to use AGIV background to make sure of that as the bigger buildings tend to be hangars, churches or greenhouse's from time to time. That's why you need to merge the data with OSM instead of just replacing buildings. The combination of both DB's make it better.

Type=2 buildings are now translated to 'shed'. There the general rule is that you also need AGIV background to check if they are garages. GRB makes no difference. Usually shed is ok, but you often can tell it's a garage. Sometimes larger buildings are marked as shed as well. Usually it's also safe to mark those 'hangar'. The main difference there is that they don't have a specific address attached using current matching rules.

building = 'gebouw afgezoomd met virtuele gevels'

We delete these virtual buildings from the database.

building = *

These are the different types of buildings after import, note that these are changed (and some get extra tags) using database queries. Some of them probably need to be purged.
 done |   count  |               building               
OK    |  2113333 | shed
OK    |  2490213 | house
NO    |    93334 | garage
NO    |    51183 | verdieping
OK    |   213350 | roof
NO    |       57 | tunnelmond
DEL   |      854 | gebouw afgezoomd met virtuele gevels
OK    |    18631 | industrial
NO    |     6246 | pijler
NO    |      218 | rooster
NO    |      542 | loopbrug
NO    |      993 | uitbreiding

highway = steps

Again, this needs attention. in GRB it represents the outlines of a step. In OSM we actually use a way to tag steps. highway = steps can't be an area according to the wiki. You will have to manually replace those with way's as far as I know. I believe it's better to keep this data in the database so the editor can draw the steps better.

 count | highway 
 23291 | steps