|Used on these elements|
|Status: in use|
|Tools for this tag|
This tag should only be used on Norwegian kindergartens, details of the import is below. The tag can be used on a node, area or relation as appropriate, but the value must be unique (there can only be 1 openstreetmap node/area/relation with any given nsrid).
The Norwegian Directorate for Education and Training (utdanningsdirektoratet) has released a dataset about all kindergartens in Norway, available at data.udir.no/baf. Kindergartens which are manually associated with a Key:no-barnehage:nsrid will be kept automatically updated with changes in the data.udir dataset. This automatic update does not overwrite any modified openstreetmap values, a key-value is only modified if the previous opensteetmap data agrees with the previous data.udir value. See below for more details. A (norwegian) website has been setup to track progress and to view and/or download extracted data, please see: barnehagefakta_osm_data
See Tag:amenity=kindergarten for how to map a kindergarten, as an example of tags from data.udir
- contact:phone=64 85 31 00
- name=Villenga barnehage
- operator=Villenga barnehage AS
The id can be used in the following urls (using "1021328" as an example)
- http://barnehagefakta.no/api/barnehage/1021328 (Raw api .json result)
- http://barnehagefakta.no/barnehage/1021328 (a kindergarten comparison page)
- 1 Import Plan Outline
- 2 Goals
- 3 Schedule
- 4 Import Data
- 5 Data Preparation
- 6 Data Merge Workflow
- 7 QA
Import Plan Outline
The following is a (partially) filled in copy of the Import/Plan_Outline
The goals are
- Provide mappers with a simple view of the NBR data which is relevant to OSM.
- Keep any added tags up-to-date with changes from NBR.
- To provide a consistent set of tags for kindergarten data in Norway
This will be an ongoing community conflation/import. As an initial step, kindergartens allready in OSM must be associated with the current NBR tags, after which an automatic script will keep the tags up-to-date. After that, kindergartens missing from OSM should be added, based on local knowledge.
Links to sources.
Data source site: http://data.udir.no/baf/
Data license: http://data.norge.no/nlod
Type of license: NLOD, Norwegian Licence for Open Government Data.
Link to permission: Approval from Utdanningsdirektoratet (in Norwegian) - http://lists.nuug.no/pipermail/kart/2015-October/005780.html
OSM attribution: https://wiki.openstreetmap.org/wiki/Contributors#Norway
ODbL Compliance verified: yes
OSM Data Files
The prepared OSM data can be found under http://obtitus.github.io/barnehagefakta_osm_data
.osm files are made available for each municipalities, e.g. http://obtitus.github.io/barnehagefakta_osm_data/data/0101/barnehagefakta.osm where 0101 is the municipalities id.
The inital conflation/importing will be done manually. See Manual Workflow below.
An automated scripts has been written to keep kindergartens which are manually associated with a Key:no-barnehage:nsrid automatically updated with changes in the data.udir dataset. This automatic update does not overwrite any modified openstreetmap values, a key-value is only modified if the previous opensteetmap data agrees with the previous data.udir value.
The automated script relies on https://github.com/xificurk/osmapis for the upload to the OSM database. The manual part can be done in JOSM with the provided .osm files, or any other OSM editor by copying from the webpage http://obtitus.github.io/barnehagefakta_osm_data
Data Reduction & Simplification
The dataset contains meta-data which are not relevant to OSM and some data which the local community has decided not to include. The original data contains nodes (single lat/lon), but these can be merged to existing closed ways (areas) or relations as appropriate.
See above for example tags. Not all kindergartens contain all of the keys.
Changesets should contain source=data.udir.no.
The github code can be found here: https://github.com/obtitus/barnehagefakta_osm the main 'transformation' is in barnehagefakta_osm.py.create_osmtags()
Data Transformation Results
Data Merge Workflow
This will be a community import. The scripts, automated edits and webpage is maintained by OSM User:Øystein Bjørndal.
Based on local knowledge or previous OSM data, add all missing tags from data.udir. There are a couple of starting points for contributing:
Option A: Using the webpage
- Find a missing or incorrect kindergarten here: http://obtitus.github.io/barnehagefakta_osm_data.
- Using your favorite OSM editor, copy tags from the "Tags fra NBR" column into OSM. This is particularly simple in JOSM, as it allows you to paste all of the key=value pairs directly.
Option B: Using JOSM
- Find the barnehagefakta.osm for the municipality you are interested in: http://obtitus.github.io/barnehagefakta_osm_data.
- Download and open in JOSM
- Copy nodes over to the appropriate node, area or relation.
Option C: POI importer
- Open JOSM and ensure "Enable remote control" is enabled by going to "Preferences" -> "Settings for the remote control feature.".
- Using the POI_Importer zoom in on the area of interest: http://poi-importer.github.io/#map=5/65.3577/18.7646&datasets=NOkg
- After nodes are no longer grey, click a flag and press either the "Import Data" or "OSM Data" buttons on the popup. Please note the following warnings: The tool looks for amenity=kindergarten in a small radius around the NBR data point, it will therefore miss kindergartens already in OSM:
Option D: Using Python
If you want to conflate a large number of kindergartens, the following python script might be useful: https://github.com/obtitus/barnehagefakta_osm/blob/master/conflate_osm.py feel free to open an issue if stumble on some bugs.
- For each modification in data.udir
- Ignore if the no-barnehage:nsrid value has not been added to OSM
- Auto update if previous OSM data matches exactly previous data.udir
- Mark as conflicting if the OSM data does not match previous data.udir.
- The initial data.udir data says that contact:phone=1
- This is modified in OSM to the (correct) contact:phone=123456789. The automated script will not notice, as the data.udir data has not been modified.
- data.udir updates the phone number to contact:phone=987654321. The script compares the previous value ('1') with the OSM value ('123456789'), as these do not match, the conflict must be manually handled.
Conflation will be manually handled, with the exception of the trivial case of the OSM data matching the previous data.udir data as described above. Any dump of the data.udir nodes into OSM is highly discurraged.
Feel free to add to the QA!
Do you need the id no-barnehage:nsrid=*?
The id is necessary for keeping the information up-to-date. This is especially important for keeping the contact:* tags updated. (Kindergartens have a tendency to stay stationary and keep their names, but we expect the contact, operator and capacity tags to change over time).
None of the other tags can be realistically used for a one-to-one mapping, as the name in OSM does not need to match the name in the dataset and the name might also be used on other objects (like bus-stops).