Last year, I attended a great talk at the FOSS4G conference in Fremantle about a high quality footpath dataset created by the City of Canning. The video is on youtube if you want to watch it yourself.
The dataset is available under an open licence, so I wanted to bring all that hard work to OSM too! I got a waiver signed, and I’ve been tinkering away getting ready for an import of sorts, and I’m looking for input from the community. The details are written up on the wiki, but I’ll summarise here.
There are two POI datasets on the portal that I also wish to import: city managed benches and bins. I intend to upload each of those sets through JOSM. A question for locals: Can any further tags be inferred from the classifications in the dataset? I.e. are there any consistent patterns in the canning managed bins and seats. Do all of the benches have backrests? Is slats vs batons meaningful? Are "Green Bin"s all material=plastic? That sort of thing.
Conflation of the POI data with OSM is pretty straightforward, and the source data has Asset IDs that I have been told are stable. Is there any value in tagging features with their asset id for easier conflation against future version of the same datasets? Even though this data falls outside of the “verifiable on the ground” category?
The main motivation for this project is the footpath dataset. I wasn’t able to come up with a good conflation of the existing OSM data and the source data, so I have set up a manual tracing workflow. I have rendered the source data into a raster tile layer for use in editing tools, and set up a local HOT Tasking Manager project to manage it. The dataset has also been translated to .osm files, which I intent to use for selective copy-paste during tracing sessions.
I would LOVE to hear from anyone who is able to do a decent conflation on these footpath networks. Maybe someone who is willing to set up a Hootenanny instance with me?
I am seeking feedback on this import plan. Share any improvements or concerns you have.
I am also seeking help in the tracing of the new footpaths: join in on the project!
I would suggest to also add operator:wikidata=Q56477868 alongside operator=City of Canning.
In general I wouldn’t add their asset IDs. You can still track what was added/modified/deleted in their future datasets by referring back to the one at the time of import. Then I’d just rely on-re-conflating again in the future. External IDs make it harder for future mappers to know what they should do with that ID when editing and make the data less “native” to OSM.
I wouldn’t add source on the object, instead use a source on the changeset. In the future as mappers improve the data, the source becomes less useful, is it still source=City of Canning, if it’s been moved, tags added since the original import?
Your jq scripts are gold! I’ve tried and failed to do more complex transformations with jq and always reverted back to JS, so lots for me to learn from.
I would suggested to copy across the ways directly into JOSM rather than tracing them from a raster, you’ll get a smoother more accurate way.
You can open the GeoJSON in another JOSM layer, then copy across those as you work through manually fixing topology.
Regardless of these suggestions I’m happy with the proposal and you have my vote of approval.
That’s true, but for lots of this it looks like there’s going to be a fair bit of aligning existing ways rather than adding new features. It feels a bit quicker to me to just drag things to where they should be.
I think it’s important for shared paths to have foot=designated + bicycle=designated (assuming they are signposted/marked as such) this says both modes of travel are explicitly indicated for use on the way. Then regardless of which highway value is used highway=footway or highway=cycleway or highway=path the shared nature of the path is clear.
I live in the City of Canning, but a lot of what you’re talking about goes over my head. If you have any specific queriesas to what’s on the ground that’s not too far away, I’d be happy to help.
I agree with the reasoning behind omitting asset ids and source tags. That’s a good point about comparing new version of the dataset against the last imported version (using asset ID as needed) for propagating updates!
And thanks for that wikidata tag.
I have updated the proposed tagging on the wiki page, and will update the hosted data files later.
This is my first time using jq properly, so I spent a while learning to put those scripts together; it’s a pretty strange language, that’s for sure.
Good point that highway=footway is the wrong tag for the shared paths, I had overlooked that.
As @aharvey mentioned, foot=designated + bicycle=designated is correct.
Perth uses highway=cycleway and highway=path interchangeably for shared paths, so I’m going to stick with highway=path for simplicity. The source data claims that SP are at least 2.5m wide, but nothing else about quality or features.
I agree that source=* tags should not be added; however, I think external reference numbers are fine for nodes. They can be an issue on ways because, as mentioned above, a way in OSM will not always correlate directly to to a single external reference edge, but nodes should be fine.