You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Reporter: Cyclestreets [Submitted to the original trac issue database at 10.48am, Tuesday, 18th September 2012]
This is an idea I was discussing with gravitystorm a few months ago, and it came up again with a recent discussion with smsm1 in the context of the England Cycling Data project. (I'm not speaking on their behalf though.)
The suggestion is that, while editing in P2 on the main OSM website, an indicator would appear that there are external data layers available in this area for merging. (Ideally this would only appear if the data hasn't been marked as merged already, but that is an extra step.)
Background:
There are likely to be an increasing number of data sources that are opened that might be useful to incorporate into OSM, but only through a manual inspection and merging process.
Two recent examples of considerable relevance to cycling users (e.g. us) are:
In both cases, these are not directly available in people's standard workflows - they require going to another location to do and thus are out-of-mind. I have often found myself on the P2 installation on the main site looking at a routing bug or thinking about data to patch, and thinking, "it would be useful to see what the DfT data has in this location".
Getting layers pre-plugged in to P2 where the community feels that the data is worthy of manual merging, and indicating to people that it is unfinished in the area currently being edited, would thus become much more of an 'itch to scratch' and consequently increase the merging rate.
It would also create a clear message that automated imports are to be avoided, and maybe create a norm for merging good practice.
The text was updated successfully, but these errors were encountered:
Reporter: Cyclestreets
[Submitted to the original trac issue database at 10.48am, Tuesday, 18th September 2012]
This is an idea I was discussing with gravitystorm a few months ago, and it came up again with a recent discussion with smsm1 in the context of the England Cycling Data project. (I'm not speaking on their behalf though.)
The suggestion is that, while editing in P2 on the main OSM website, an indicator would appear that there are external data layers available in this area for merging. (Ideally this would only appear if the data hasn't been marked as merged already, but that is an extra step.)
Background:
There are likely to be an increasing number of data sources that are opened that might be useful to incorporate into OSM, but only through a manual inspection and merging process.
Two recent examples of considerable relevance to cycling users (e.g. us) are:
The England Cycling Data project: http://wiki.openstreetmap.org/wiki/England_Cycling_Data_project which contains a wealth of useful detailed data about cycling attributes from the DfT (UK Department for Transport). For this project, we funded the creation of a merging tool that Andy was able to create using the P2 layers infrastructure. Currently the merging layers are installed at http://www.cyclestreets.net/edit/locate/ and see http://www.cyclestreets.net/blog/2012/09/03/england-cycling-data-project/
Bike Shop locator: http://www.cyclestreets.net/blog/2010/09/10/get-all-uk-bike-shops-in-osm/ This is a dataset of UK bike shops supplied to us by the bike industry. smsm1 wrote a specialised tool for this, but having this in P2 directly would make things easier.
In both cases, these are not directly available in people's standard workflows - they require going to another location to do and thus are out-of-mind. I have often found myself on the P2 installation on the main site looking at a routing bug or thinking about data to patch, and thinking, "it would be useful to see what the DfT data has in this location".
Getting layers pre-plugged in to P2 where the community feels that the data is worthy of manual merging, and indicating to people that it is unfinished in the area currently being edited, would thus become much more of an 'itch to scratch' and consequently increase the merging rate.
It would also create a clear message that automated imports are to be avoided, and maybe create a norm for merging good practice.
The text was updated successfully, but these errors were encountered: