[Talk-ca] cleaning up after the GeoBase import
William Lachance
wrlach at gmail.com
Fri Jun 12 20:58:53 BST 2009
On Thu, 2009-06-11 at 19:24 -0600, James Ewen wrote:
>
> > This basically amounts to
> > asking everyone who writes tools/products that read/write OSM data
> > (which go far beyond the OSMARender and Potlatch editor, see for
> example
> > the developer tools at http://cloudmade.com) to accomodate us.
>
> Well, if you can glean from my writings the concept that I was
> attempting to communicate, you would understand that the suggestion
> that I made would work with existing OSM data, as well as with the
> GeoBase sourced data. The GeoBase data just magnifies the effect
> because of the much higher degree of way fragmentation.
>
> With existing OSM sourced data, if I want to change a tag on a roadway
> that is made up of 3 segments, due to a bridge in the middle of the
> roadway, I have to select and change the tag on each of the 3
> segments. I am simply suggesting that the editing software be made a
> little smarter in that it would be able to follow the selected tag
> information, and allow you to change all the adjoining segments that
> have the same tag value. This would work very nicely with the existing
> data, and for the GeoBase sourced data, it would work the same, just
> that there would be more segments in the data.
Right, you have to split up a way if the tags change as you describe.
However, there's also the (at the very least implied) convention that a
way should not be split if the tags don't change. At best, the way we're
doing things will unneccessarily enlarge the OSM layer for Canada by
putting in redundant road tagging information into the database. At
worst, you cause problems with third party tools.
Look at this from another angle: Should we split up all the existing OSM
road data that people have put in to add in GeoBase UUID information?
Maybe I'm missing something, but I frankly just don't see the purpose in
tagging our data differently from the rest of the world, when we can
achieve the desired end (comparing OSM data to geobase) in an analytical
way simply by comparing the geometry and histories of both data sets
using tools like RoadMatcher. Perhaps this is a question we should put
to the larger openstreetmap community? I will fully admit I've only been
using and contributing to this project only sporadically for about a
year.
> If I were to take a 200 metre long section of roadway, and define it
> using "International Conventions" within the OSM structure, it is very
> possible that I could have a bunch of segments, where perhaps the
> number of lanes change, the surface type changes, a bridge exists, and
> just for fun, it becomes a one way street. If each of these segments
> has a road name associated with it, the renderer can end up placing a
> bunch of names along that section of street. If however the renderer
> were instructed to look for all the segments with the same name, and
> only place a single name on that section until XX distance away, it
> would make the map look better.
Ok, I take your point. Perhaps the openstreetmap tile renderers could
handle these sorts of cases better. :) Though I think that's a separate
issue from what we're discussing above.
--
William Lachance <wrlach at gmail.com>
More information about the Talk-ca
mailing list