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