[Imports] Municipality of Örebro, Sweden

Jason Remillard remillard.jason at gmail.com
Fri Oct 31 11:55:34 UTC 2014

Hi Karl,

- You need to setup a wiki page for the import, basically duplicating
the information in this email.
- If you are using your import account, there is no requirement to
have the entire import in one change set. In fact if you upload a
change set that is at the maximum size, it will make it harder to
revert. The address file is 26,000 nodes, which is on the high side,
but not close to the maximum size.
- Please run the JOSM validator over all of the output files. The
address file has the highway tag misspelled (why would you even have a
highway=road tag on a node?).


On Thu, Oct 30, 2014 at 3:45 PM, Karl Wettin <karl.wettin at kodapan.se> wrote:
> Örebro municipality of Sweden release GIS-data as CC0.
> This data can be harvested and post processed to produce a couple of hundred
> thousand nodes with a couple of class tag values:
> name, place:halmet,
> addr:city, addr:place, addr:street, addr:housenumber,
> name, addr:city, addr:place, highway=road
> name, amenity=school, isced:level,
> name, amenity=social_facility, social_facility= assisted_living,
> social_facility:for,
> name, leisure=park
> etc.
> Output is one osm.xml-file per class.
> https://github.com/OpenStreetMap-Sverige/import-orebro-osm-xml/tree/master/osm.xml
> https://github.com/OpenStreetMap-Sverige/import-orebro-osm-xml/archive/master.zip
> Also attempts to find OSM-duplicates in a radius of 500-5000 meters, which
> seems to work really well but could probably be improved by allowing a bit
> of Levenshtein distance, whitespace- and \p{Punct} normalization. Not sure
> how much this would help though, everything looks pretty great when
> inspecting manually.
> Duplicates from source data are written to a common osm.xml (rather than
> written to their individual class-osm.xml) and the duplicates from OSM are
> written (with recursed children) to yet another osm.xml-file.
> Script:
> https://github.com/OpenStreetMap-Sverige/import-orebro-harvester/blob/master/src/main/java/se/kodapan/osm/orebro/Orebro.java
> See line 335 and down to see exactly what classes there are and how the
> duplication detection mechanism works. (And sorry for all the Swedish
> language comments and names.)
> We are now considering the workflow.
> Consensus on #osm.se at irc.oftc.net is along the way "the data looks great,
> let's just commit it and then get started working on it as usual". The
> reaction on #osm has been quite the opposite "make sure any work is in the
> one single commit of the import account".
> I've been considering asking all that can help with manual burdon och
> checking all points to do it at github, add any new things to OSM in a per
> user-changes.osm.xml  to avoid inverted identity conflicts and then to a
> merge before we committ it. If I understand everything correct then that
> would satisfy the people I spoke with on #osm.
> That might be too much to ask of the users. And the data is really clean. We
> really want to just push it in the way it is and start working with it in
> the database as normal using a task project.
> karl
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports

More information about the Imports mailing list