Work in progress, still not submited to import mailing list.
This page tries to unifies all resources around import of "Registar prostornih jedinica" to OSM. This data carries geodata information of all boundaries in Serbia.
OSM thread (Serbian): https://forum.openstreetmap.org/viewtopic.php?id=68288
Web app: https://opendata.geosrbija.rs/
Serbian parliament ratified opening this data in 14. December 2019. (Сл. гласник РС 86/2019). Announcement can be found in Serbian cadaster agency here and web application that hosts this data is located here.
Since this is government data, license defined is here: https://data.gov.rs/sr/terms/. However, we are still actively looking to get license of this data that comes from cadaster web site itself.
Defining new/updated metadata
So far, here are changes we plan to introduce with this:
- we clarified on forum what naselja ("settlements") are (admin_level=9) and that "mesne zajednice" ("local communities") will be admin_level=10, but will not be imported at this point. So, we will focus on admin_level 4-9
- We also defined new tag "ref:sr:maticni_broj" that we plan to add on admin_level=(7,8,9), similar to German de:regionalschluessel and de:amtlicher_gemeindeschluessel
- All level relations will have associated "subarea" members, so we have proper hierarchical structure
- We also agreed that we will treat government data as "truth", even if that means there are gaps (but not including country borders)
- source for all imports is planned to be "source=RGZ_Import"
Since we already have boundaries in OSM, only thing we can do here is try to conflate and "fix" existing boundaries. So far, we are discussing potential options.
Here is OSM file with all admin_level=9 boundaries imported in OSM: https://kokanovic.org/rpj-v1.7z.
We also analyzed how much are boundaries accurate today. For this, we created software that is measuring accuracy by two metrics: 1. area of intersection between OSM and cadaster / area of cadaster. 2. sum of distances over all points in cadaster polygons to nearest OSM polygon
In general, results we got are really good with averages and 50th percentile for metric 1 of 98% (98% of area is same in OSM and cadaster today). This means that
Conflation/import work planned
Based on results of analysis, we do not plan to remove any existing boundaries and create new ways/relations. We plan to work with existing boundaries, conflating them as necessary. Currently, there are some efforts that we like to do
Results of analysis also got us relation IDs, so we can easily add them to OSM. Remaining (unmatched) relations will need to be added manually, either by finding them manually, or adding "settlement" if it doesn't exist. To ensure that we don't lose this tag, we will incorporate ability to detect and warn if admin_level 7,8,9 do not have "ref:sr:maticni_broj" tag in Serbian OSM Lint tool.
Same as with previous item. We first need to match all admin_level=7,8 with cadaster data and once it is done, we can add subarea members where missing. Serbian OSM Lint tool will help to ensure this data is present in future.
Manual procedure for fixing boundaries
Kosovo recently got through this similar procedure, as described in here: https://lists.openstreetmap.org/pipermail/imports/2019-November/006113.html. When we tried to compare data from OSM files generated by Kosovo government and Serbia government, they match 100%. Only difference is around Kopaonik area at query (https://www.openstreetmap.org/way/562935476) near "Pančićev vrh", where Kosovo claims bit more territory, but OSM and Serbian government agree. Other than that, OSM borders generally agree with both government sources, but there are some anomalies here and there. We contacted Kosovo OSM mappers over OSM forum and will continue over there.
Bosnia and Hercegovina