[Talk-ca] What we dont know from GeoBase
richard at weait.com
richard at weait.com
Fri Jan 2 00:59:22 GMT 2009
James Ewen said:
> On Thu, Jan 1, 2009 at 12:30 AM, Dale Atkin <datkin at ibycus.com> wrote:
>> I'm sorry if some of the above has come off as a little abrupt, but I'm
>> getting a little frustrated over here. I feel like I have a solution
>> should work, [ ... ]
> Dale, I seem to have missed out on your description of your solution.
> Can you 'splain it to me again?
Sorry for the confusion, James. I think you are looking for Sam's
solution, and that my webmail attribution made it look like Dale's
solution. I hate my webmail.
[ ... ]
> I have a proposed concept of how to allow the GeoBase data to be
> merged into the OSM database. It's kind of an offshoot of Sam's
> concept, but bear with me.
> In Potlatch currently, you can click on the little "+" sign on the
> right hand side of the display, where you can choose one of 4 base
> layers, and one of 2 overlays.
Okay, for me it was the checkbox icon on the lower left, but I see what
> If you choose the data overlay, you get
> an object list of all the ways in the displayed area. From there, you
> can click on the way number in the object list, or click on the way in
> the map view. Either of these presents you with the attributes
> associated with the selected way.
> My suggestion is to add a third overlay capability, that being a
> GeoBase layer. All of the GeoBase import would be created at once, but
> held off of the main map in a pending database. To be incorporated
> into the OSM database, one would simply need to go to the area of
> interest, and bring up the GeoBase overlay. If there were no visible
> conflicts on screen, a click on the "Import All" button would merge
> the visible GeoBase data into the OSM database. (More on this later,
> making zero conflict areas automatically imported)
Perhaps. This sounds a little like a recent post regarding josm patches
that helped with the TIGER import and merge. But I believe that the bulk
of TIGER was a straight replacement rather than a merge. I have no idea
where the code patches you suggest are on the difficulty curve though...
I think that putting this function in the main, released potlatch (or
other editor) would be way too open to well-intentioned but under-informed
clicks. ("Hey look, a thousand streets on the edge of a Canadian city.
*click* Goodbye community contributions.")
> In areas where existing OSM data conflicts with GeoBase data, the user
> would be able to select the existing OSM way to check for any
> desirable tags, and have them added to the GeoBase data. The OSM way
> could be deleted and GeoBase way inserted into the OSM database one
> way at a time. (There are issues like ways that extend beyond the
> extents of the visible area.)
Have we classified the types of merges that we might want to do (if we
have the code tools to do them)? Perhaps this is already being built into
the scripts folks are working on.
I see a few things that would, in an ideal world, get merged / preserved
rather then wiped. I'll put that in a separate email.
[ ... ]
> If the initial import script is written cleverly enough, it could work
> on a tile by tile basis, looking for any OSM data.
As far as I know, tiles are only used by the renderers, to make the image
tiles to ship to browsers. I don't think that the database or editors
"know" anything about tiles on their own.
Still, that's a handy unit to work with. I suppose that there is a risk
of having the OSM way and Geobase way running parallel, but either side of
a tile boundary. Then they both get included? Not the worst flaw, but
there will be other edge cases, I'm sure.
[ ... ]
> The big concern is not tossing all of the hard work of the existing
> OSM community out the window, and starting from scratch with a bulk
> GeoBase import. By doing a smart import, importing only into areas of
> zero data, we can get the automation necessary to fill a lot of the
> uncharted territory, but still respect the work of all those who have
> been contributing up till the import.
That would be nice. Imagine "Canada, now 99% Geobase, 1% OSM, plus this
kind of odd-shaped transition area where we're merging one to the other at
the junction." I think we're only trading one problem for another. But
still, having so much data added is tempting.
I suppose I'm having a hard time accepting that my contributions could
have to be wiped and replaced. But that is also just a transition from
one type of contribution to another.
More information about the Talk-ca