[Talk-ca] cleaning up after the GeoBase import

James Ewen ve6srv at gmail.com
Thu Jun 11 20:10:55 BST 2009


On Thu, Jun 11, 2009 at 12:09 PM, Mepham,
Michael<Michael.Mepham at nrcan-rncan.gc.ca> wrote:

> I would reword the chances of “slim to none” to read “very high to high”.


Wow, the winds of bureaucracy do shift every once and a while! Okay,
if that's the case then I have to rethink what we can do to make
things acceptable for everyone.

Since GeoBase stores every road segment between junctions as
individual ways, and OSM and GeoBase could potentially be sharing data
in both directions, then we need to try and keep the data structure as
compatible as possible.

I still don't like the fact that it makes editing the ways difficult
due to the vast number of segments that comprise the ways. It also
means that the renderer puts many duplicate tags on a single logical
way that is made up of many segments.

So, instead of manipulating the data to fit the way the editors and
renderer work, we need to modify the way the editors and renderers
work.

How about something like this? If I select a segment of a way, and
change an attribute that is common to way segments that are connected
to this way segment, then the editor changes the common attribute for
all connected ways that share the identical attribute. ie. If I want
to fix a spelling error such as "Main Bulevard" on a street that is
comprised of 60 segments, all I would have to do, is select one
segment, change the name to "Main Boulevard", and the editor would
propagate the changes up and down the way through all segments that
have the same existing spelling error, correcting the whole way.

We have this type of problem right now, since we have to cut the ways
where attributes change, such as when the roadway crosses a bridge. If
you want to fix that same road across a bridge, you need to select the
segments on either side of the bridge, as well as the segment on the
bridge, and correct each one separately.

Also, within the renderer, it would look for adjoining segments that
share attributes, and render appropriately. For the end user, I can
only think of one attribute that this would readily affect, and that
is the name/number tagging. With multiple segments, we get far too
many road names/numbers on the map.

> So – keep the faith.  We (GeoBase) like what you (OSM) are doing and hope to
> be able to work in a partnership soon!

It's a good thing for all involved... Geobase can leverage the
hundreds of volunteer mappers out there, and OSM can leverage the
millions of dollars worth of taxpayer funded mapping being done by the
various municipal, provincial and national bodies.

Hmm, I wonder if I can get a tax reduction based on the amount of OSM
data I contribute?

James
VE6SRV




More information about the Talk-ca mailing list