Just to add couple of things I forgot in previous mail: * CC to [email protected] * Produced .osm is done using custom script doing conversion CSV->SHP, reprojection (from EPSG 32634) using ogr2ogr and script from [2]. Big thanks to Guillaume Rischard for pointing me to this script and for all advises! * Way fixing described in manual instructions is leveraging UtilsPlugin2[3] and "Replace geometry" tool
Thanks, Branko [1] https://lists.openstreetmap.org/pipermail/imports/2019-November/006113.html [2] https://github.com/maxerickson/michigantownships [3] https://josm.openstreetmap.de/wiki/Help/Plugin/UtilsPlugin2 On Sat, Jan 18, 2020, at 22:17, Branko Kokanovic wrote: > Hi, > Announcing here that we plan to add some tags to Serbian boundaries on > admin_level=9[1] as Serbian community received open data set of > boundaries from government[2] (all admin levels). > > We did some preliminary analysis and this government data seems really > good. It also turns out we mostly have all boundaries with good enough > accuracy[3]:) (average of 95% of common boundary area between > government and OSM data) Because of this, at this moment we do not plan > to improve existing geometries more (but see "open question" at the end > of mail), and we decided to preserve existing history, so we also do > not want to delete existing ways and import it from scratch. However, > we did wrote procedure for manually fixing existing ways[4] to match > government boundaries if we want it to be 100% correct. > > So far, plan is only to add new tag `ref:sr:maticni_broj` (similar to > de:regionalschluessel and de:amtlicher_gemeindeschluessel) which is > official reference in cadaster of > districts/municipalities/cities/settlements and to improve subarea role > (add where missing). We will ensure both of these are in place by > leveraging existing Serbian lint tool[5] (by emitting warning if > boundary don't have `ref:sr:maticni_broj` or subarea). > > OSM file with all admin_level=9 boundaries prepared from government > data is here [6]. We are actively working in open, in this repo[7] for > all current and future analysis about this data and potential automated > conflations. All of our decisions are discussed in forum here[8]. > > Licence is fully open for "all purposes" and opening data is ratified > in parliament in December, and present in official journal (Сл. гласник > РС 86/2019). It can be found (for this and other Serbian government > data) at [9]. > > We *do not* plan to touch any country boundaries, just internal ones > (although, plan is to contact bordering countries' forums, just to see > how much we do differ based on their open data, if any). > > **Open question**: if anyone can work with us and help how to conflate > existing OSM ways shared between admin_level=9 boundaries, so they are > aligned better with produced .osm file[4] (government data), any tips, > resources, what to watch out... please shout out! Current 95% accuracy > that we have is good, and writing tool to "move"/"add" nodes of > boundary ways while watching out for various edge cases is possible, > but not really justifiable effort. If there is existing > solution/half-solution in the wild that we can take and adopt, it might > be a better way forward! > > Thanks, Branko > > [1] https://wiki.openstreetmap.org/wiki/Serbia/RGZ_Import > [2] https://opendata.geosrbija.rs/ > [3] https://kokanovic.org/rpj-analysis.csv > [4] https://wiki.openstreetmap.org/wiki/Serbia/RGZ_Import/Uputstvo (in > Serbian) > [5] https://gitlab.com/stalker314314/serbian-osm-lint > [6] https://kokanovic.org/rpj-v1.7z > [7] https://gitlab.com/stalker314314/prostorne-jedinice-import > [8] https://forum.openstreetmap.org/viewtopic.php?id=68288 > [9] https://data.gov.rs/sr/terms/ > > _______________________________________________ > Imports mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/imports > _______________________________________________ Imports mailing list [email protected] https://lists.openstreetmap.org/listinfo/imports
