On 12 Jun 2009, at 18:54, Richard Degelder wrote:
William Lachance wrote:
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?
The simple answer is that at some point we are going to have to.
If
On Wed, Jun 17, 2009 at 2:02 PM, SteveC st...@asklater.com wrote:
On 12 Jun 2009, at 18:54, Richard Degelder wrote:
William Lachance wrote:
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?
The
(Sorry for repeating myself) it's not only splitting; larger
streets and highways consist of a way for each direction in GeoBase.
This is also the recommended way to map those in OSM (see for example
http://josm.openstreetmap.de/wiki/Introduction, Conventions), but often
they are not, at least in
Good point.
Each road SHOULD be a relation which is made up of street (address
block numbered sections).
Geobase already does this 1st part well.
What if we start doing this:?
Create a relation route, called 'theNameOfTheRoad' and have it
attributed to each segment. And step 2 would be to remove
Dear All,
I'm surprised by the panic and outrage I'm hearing in this thread.
I'm not aware of anybody creating an OSM-CA branch of tagging that is
incompatible with community standards. The conversations I've been
involved in have been aimed at making the very best interpretation of
the
On Fri, 2009-06-12 at 20:48 -0400, Steve Singer wrote:
On Fri, 12 Jun 2009, William Lachance wrote:
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
- William Lachance arranged a host of electrons thusly: -
Having the uuids around also make it easier to talk about
differences/errors between OSM and geobase data. Someone can look
at a road in OSM and easily find the original GeoBase road (using
your favourite gis tool) and compare
Sat, Jun 13, 2009 at 10:08 AM, William Lachancewrl...@gmail.com wrote:
On Sat, 2009-06-13 at 10:28 -0400, Gerald A wrote:
On Sat, Jun 13, 2009 at 1:36 AM, Corey Burger corey.bur...@gmail.com
wrote:
snip
1) start fresh (streets/road-wise), enjoy correct topology
and
Corey,
In my original message (as opposed to a snippet you quoted), I
suggest that matching geobase UUID is equivalent to throwing out the
data, if not position-wise, then topology-wise. We can take the easy
way or a hard way, but end result will be pretty much the same.
Avoiding pissing off
Hmm, did I say more authoritative? I thought it was something like
more consistent and topologically correct.
On Sat, Jun 13, 2009 at 10:28:56AM -0400, Gerald A (geraldabli...@gmail.com)
wrote:
On Sat, Jun 13, 2009 at 1:36 AM, Corey Burger corey.bur...@gmail.comwrote:
snip
1) start
On Sat, Jun 13, 2009 at 2:07 PM, Michael
Barabanovmichael.baraba...@gmail.com wrote:
Corey,
In my original message (as opposed to a snippet you quoted), I
suggest that matching geobase UUID is equivalent to throwing out the
data, if not position-wise, then topology-wise. We can take the easy
Meanwhile, for the existing process I've added After the Import section to
http://wiki.openstreetmap.org/wiki/Geobase_NRN_-_OSM_Map_Feature
It's also mentioned it in How can I help.
http://wiki.openstreetmap.org/wiki/GeoBase_Import
Michael.
On Sat, Jun 13, 2009 at 02:34:29PM -0700, Michael
That's a possibility, though RoadMatcher is the tool for exactly this
purpose. For now, after the import, in problematic places I compare
the topologies by opening the resulting .osm file from geobase2osm
script (not the standalone, but the whole thing) as another layer. Then
data can be
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.
On Fri, Jun 12, 2009 at 1:58 PM, William Lachancewrl...@gmail.com wrote:
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.
Yup, that's what I was doing
William Lachance wrote:
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?
The simple answer is that at some point we are going to have to.
If we want to add the attributes available from GeoBase, and to
Ah, I hate replying to myself.
Another issue is relationship of street data to other features from Canvec.
I'm pretty sure that e.g. bridges are aligned between road data and
river and railroads in GeoBase. I'm also pretty sure it's not the case for a
lot of current OSM data.
One other idea
On Thu, Jun 11, 2009 at 12:18 AM, Michael Barabanov
michael.baraba...@gmail.com wrote:
Another way of incorporating the updates (without using UUIDs) would
be to re-run roadmatcher. Given that we'll like will want to do it
anyway (geobase will have new roads), maybe preserving UUIDs isn't a
On Thu, Jun 11, 2009 at 12:09 PM, Mepham,
Michaelmichael.mep...@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
On Thu, Jun 11, 2009 at 2:40 PM, William Lachancewrl...@gmail.com wrote:
I have to say that as someone who uses OSM data in my own projects, I
really don't like the idea of creating our own OSM-CA mapping and
tagging conventions. Do we really want to be formatting our OSM data
differently
On Wed, Jun 10, 2009 at 12:25 PM, Richard Weaitrich...@weait.com wrote:
On Wed, 2009-06-10 at 14:51 -0400, si...@mungewell.org wrote:
What's the current thinking on this?
It seems that various geobase imports have created a load of short ways
with unconnected nodes (multiple nodes at same
Do you know how widespread the multiple nodes are?
So I fixed Okotoks by hand last night, around 'me' there are issues in:
Black Diamond/Tuner Valley -
http://www.openstreetmap.org/?lat=50.6866lon=-114.2629zoom=14layers=B000TTF
High River -
On Wed, Jun 10, 2009 at 3:53 PM, Richard Degelderrtdegel...@gmail.com wrote:
Simon,
Combining the ways will defeat the possibilities of further use of the
GeoBase data for the area. Unfortunately the GeoBase NID is unique for the
single segment only and combining multiple segments will make
Simon,
Combining the ways will defeat the possibilities of further use of the
GeoBase data for the area. Unfortunately the GeoBase NID is unique for
the
single segment only and combining multiple segments will make adding
additional data based on those unique NIDs, such as address data,
Another way of incorporating the updates (without using UUIDs) would
be to re-run roadmatcher. Given that we'll like will want to do it
anyway (geobase will have new roads), maybe preserving UUIDs isn't a
big deal after all. Another reason we'd likely use another roadmatcher
run for things like
25 matches
Mail list logo
