Hi all, James did a good summery explaining the concept of 'social impact of Bulk Importing', perhaps better than i did.
Just substitute the word 'geobase' for 'the data source', and it really can apply internationally. And suffixing it with the assumption that the geobase-source-file.osm is available to use (and download from somewhere). Cheers, Sam On Wed, Oct 28, 2009 at 5:10 PM, James Ewen <ve6...@gmail.com> wrote: > On Wed, Oct 28, 2009 at 1:19 AM, Sam Vekemans > <acrosscanadatra...@gmail.com> wrote: > > > This message is directed to the talk-ca list, as it serves as a summery > for > > the latest and greatest. In a month or so, I'll be able to summarize in > 1 > > page. But for now, I've put a lot of thought into the below message, > so, > > although long and rambley... it's the best answer i got :) > > Wow, Sam... I made it through the whole spiel, and even stayed with > your thought process through the whole thing... that's a first! 8) > > > > Here's the low-down. (social impact) > > We respect the integrity of the local area mapper who spent a > considerable > > amount of time either tracing from imagery, or tracing from there own GPS > > tracks.... and place this on a HIGHER priority than that of > geobase/canvec > > data. > > So, again... this is Openstreetmap, where its a collaborative community > who > > builds the map. ... we respect the integrity of the local area mapper who > > spent a considerable amount of time either tracing from imagery, or > tracing > > from there own GPS tracks.... and place this on a HIGHER priority than > that > > of geobase/canvec data. > > > I think this type of statement is what is causing problems. We should > not use a blanket statement that OSM data of any quality is sacred... > OSM data is a living database that everyone can work on. Data that > you, I, or anyone else enters into the database is not locked into the > database never to be modified. If another user comes along and wants > to add tags, modify the way to (hopefully) increase the accuracy of > the data, or even remove the data should the real world object the > data is representing should be removed or destroyed. > > The issue is that data being imported by a bulk import script should > not be blindly imported damaging or destroying work that has been done > by a real live OSM user. The key concept in that statement is BULK > IMPORT SCRIPT. > > If a user has the complete GeoBase file for the area and is putting > the time and effort into verifying and checking the GeoBase data > versus the OSM data, and comes up with the conclusion that the GeoBase > data does a better job of describing the way, then they should feel > free to modify/remove the lower quality OSM data, and copy the better > quality GeoBase data into the OSM database. > > Another concept to remember is that there does not have to be an > exclusion clause. One does not have to choose to go with only OSM data > or GeoBase data. One could use a high resolution OSM GPS trace based > way, and copy the GeoBase tags onto the OSM way. There's also the > possibility that some of the tags on a low quality OSM way might be > useful if copied onto the higher quality GeoBase way. > > What we need to do, is to take the best data that we can find from > whatever source is available (that meets OSM guidelines), and merge > that into the database. The bulk import scripts are written to do > that, but only where an easy decision can be made, which is based only > on the easily determined logical choice... Is there any existing OSM > data at this location? If the answer is no, then import the GeoBase > data. > > We need to have real people make the harder decisions where the > GeoBase data and OSM data overlap. That's where we are at in areas > that have been imported, and people are seeing holes between the > GeoBase data, and OSM data. > > Feel free to get your fingers dirty... get in there and make an > informed decision about what data to include in the OSM database. Just > don't blindly wipe out existing OSM data to import a bunch of bulk > data. > > It's not a GeoBase versus OSM issue, but rather a data quality issue, > and it is up to the OSM community to get in there and determine which > data has the best quality, and if required merge both sources to come > up with an even better final product. > > I did the same type of thing when I was tracing hundreds of kilometres > worth of highways with my GPS. I would upload the GPS trace to OSM, > and then manually work my way along the highway checking my trace > versus the OSM way. I would copy the tags from the OSM way to the GPS > based way, I'd chop the GPS trace into pieces where I turned off one > highway, and onto the next. Using aerial imagery, I would insert > bridges, or other things that wouldn't be contained in a GPS trace. > > I didn't just wholesale delete every road in the area so I could > upload my data. I used the GPS trace as another source, and using my > knowledge, made the best decisions to improve the OSM database. > > Here are some examples... > > There was a very rough trace of the Alaska Highway done from the low > resolution Yahoo Imagery available. When I travelled that portion of > the highway on my way to the Maxhamish Lake area, I recorded my GPS > track. I uploaded and converted that track in changeset 718156 [1]. I > copied tags from the existing way, and then converted my trace into a > way. I connected the new highway to the existing side roads, and > closed the changeset. Another user tcjfr has been poking at the way, > making modifications, and improving the database since then as can be > seen in the history of way number 27400400 [2]. > > This is type of thing that we should be doing with the GeoBase data > where OSM data exists. > > Another highway, #77 the Liard Highway (27346793 [3]) did not even > exist in OSM when I drove it. I simply used my GPS trace to create the > way, and added my own tags. > > This is similar to what the scripts are doing, where no data exists, > just get after it and put new data into the database. > > We need to ensure that we don't put out the wrong message! The message > is not "If OSM data exists, GeoBase data has to be thrown away.", but > rather if OSM data exists, we need to make intelligent decisions on > how to incorporate the GeoBase data into the OSM data through a > merging process." > > We need to still ensure that blind bulk imports do not damage or > destroy existing data (from whatever source). > > James > VE6SRV > > > [1] http://www.openstreetmap.org/browse/changeset/718156 > [2] http://www.openstreetmap.org/browse/way/27400400 > [3] http://www.openstreetmap.org/browse/way/27346793 > > _______________________________________________ > Talk-ca mailing list > talk...@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-ca >
_______________________________________________ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
