Re: [Talk-ca] GeoBase Goals

[James Ewen]

On Thu, Jan 1, 2009 at 11:30 PM, Sam Vekemans
 wrote:

> I guess you missed my last message (understanding the role Ibycus can &
> could play), but thats OK.

No, I probably saw it, just couldn't figure out what you were trying
to convey, or don't believe that the role is as important as you do.

> I'm scatter-brained by nature, so i am thinking about all aspects of the
> project at once.   I see the project as a complete project "The Across
> Canada Trails Project" ... This includes the paper coil-bound mapbook &
> wikiTravel GPS Guide, and web Slippy map.

Okay, you can do that, but the project at hand for the rest of us is
to import the GeoBase dataset into OSM. There are enough steps and
hurdles to keep us busy with this part of your project.

> I know that it's important to focus on 1 think at a time ... However, it's
> far to easy to get caught-up in the smaller details (which ARE ALL
> important).

Yes, that's one of the things we have to watch out for. We need to
balance watching out for minor details, while still making sure we
don't get bogged down headed towards the end. I don't believe we'll be
able to get everything figured out and perfect on the first pass, but
we also need to make sure we get things close enough that we don't
have to undo everything to fix the mistake.

> So i just keep on asking questions, and report back to the talk-ca list, for
> anyone to find and question if they want clarification :).  I just do the
> bits a pieces that i know how, and make it known when there's going on, so
> others can chime in if they can.

Yup, keep on doing that... sometimes you dig up some good information.

James
VE6SRV

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] GeoBase Goals

[Sam Vekemans]

Thanks James,I guess you missed my last message (understanding the role
Ibycus can & could play), but thats OK.

I'm scatter-brained by nature, so i am thinking about all aspects of the
project at once.   I see the project as a complete project "The Across
Canada Trails Project" ... This includes the paper coil-bound mapbook &
wikiTravel GPS Guide, and web Slippy map.

I know that it's important to focus on 1 think at a time ... However, it's
far to easy to get caught-up in the smaller details (which ARE ALL
important).   We do have an unlimited supply of resources out their,  where
there are scores of people who (as a hobby are masters at what they do) are
all able to help. ... when asked the right questions. :)

So i just keep on asking questions, and report back to the talk-ca list, for
anyone to find and question if they want clarification :).  I just do the
bits a pieces that i know how, and make it known when there's going on, so
others can chime in if they can.

cheers,
Sam

P.S. FYI There's a guy in Newfoundland taking his harley across canada ...


PPS.
Pubs would be included in CanVec Building - ( Bâtiment )- 2010009 as a point
and area... and is type 24 described as "A residential, public, or
commercial building with a function
other than those listed herein. If the "Other" building is not
residential, public, or commercial, its size must be greater
than 10 meters X 10 meters. In the case of farm complexes,
such a building must be greater than 30 meters."
this item is not on GeoBase. ... but might be available :) .. at least it's
in the same type of database files.
type 24 is railway station.   FYI

You can download your local area and see. :)

(there are only 90 entity types, with each having a list sub classes. ...
all of which DO have a field stating on wether or not it's already in
GeoBase)

PPPS..

I've added the slippy map links to the main GeoBase Import page (just
looking for the other locations). ... hope thats OK :)
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Geobase NRN import script

[James Ewen]

On Thu, Jan 1, 2009 at 6:14 PM, Steve Singer  wrote:

> The geobase2osm.py script lets you pass a bounds file (with the -b option).
> This will only include roads that pass through the bounds specified in the
> file.  So you can take the full provincial GML files but only generate .osm
> files for smaller chunks.

Sweet, then that's one tool option that we need to be able to get
things happening.

> As Jason mentions in his other post, adjoining chunks will have duplicate
> ways.  I don't think it will be that difficult to eliminate these duplicates
> though.  We just need a script that searches for two OSM ways with the same
> geobase_nid that occupy the same space, and delete one of them + merge in
> any adjoining ways.

This is a trivial concern compared to merging with existing OSM
contributed data.

James
VE6SRV

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Geobase NRN import script

[James Ewen]

On Thu, Jan 1, 2009 at 5:28 PM, Jason Reid
 wrote:

> In terms of actually adding the data into OSM, the only real solution is to
> use the API and the bulk_upload tool (or a tool with equivalent
> functionality).

But that bulk_upload tool has no provisions for checking for and
possibly matching existing ways, correct?

That's the part that needs to be developed. We pretty much have the
tools and capabilities of taking an existing database, and converting
it into OSM style data. It's the merge with existing data that's the
part that needs attention.

> The tagging will be the single largest issue of contention, not only for the
> upload but for applying updates in the future as well. Take your example of
> Highway 2 for instance. If we upload it as it is in Geobase (which works out
> to be a primary highway I believe), but then you correct it to be what you
> think it is (for instance, highway=motorway), then the update script comes
> along and sets it back to primary, theres the potential for a bit of
> disagreement to take place.

Actually the script currently assigns Highway 2 a trunk status simply
based on ref ==2, but trunk isn't in the wiki attribute translation
page, and according to the OSM description, it is a motorway for quite
a distance south of Edmonton. This is where the merge tool becomes
very important. Anywhere that existing data is found, you're going to
need to have some way of resolving the discrepancy. Most likely it's
going to take some human intervention. The tug-of-war back and forth
between scripts and user needs to be avoided.

> Theres a lot of other cases I've already seen
> where the tagging will be modified, in some cases its where the tagging
> guidelines are tagging for the renderer, or just where the OSM
> classifications don't fit the real world (take part of Highway 40 north from
> Highway 3 for instance, I believe Geobase has it as a Expressway / Highway,
> however in reality its a 2 lane gravel road winding through the mountains
> that in OSM is also tagged as a highway=primary).

Well, according to the government, Highway 40 is a primary highway...
it just happens to have a surface=gravel. Around Hinton, you can get
on some forest service roads that are wider and smoother than Highway
40, but if you tag them as such using the OSM guidelines, you would
think they are tire ruts in the back woods. It's pretty tough to try
and accurately represent the real world with generic tags.

James
VE6SRV

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Maritme borders in Canada

[Michel Gilbert]

2009/1/1 Sam Vekemans 

> Hi there,Reading the discussion about boarders reminds be of the
> interesting situation off the coast of Nova Scotia to Newfoundland, where
> there is an island which is Actually part of France.
> ... there is also an extra part of Quebec, north of Prince Edward Island
> (Magdelene islands).
> So tagging gets interesting.
>
>
> Anyway, Im not sure if Michel was able to remove the 1st round of GeoBase
> import, the GeoPolitical Boarders, so to set it right.  The problem was
> about the number of nodes in a way, and a solution was given (but it's WAY
> beyond my ability to understand :) ... i thought that you might be able to
> be of some help here.
> http://lists.openstreetmap.org/pipermail/talk-ca/2008-December/000483.html
>
> Thanks,
> Sam Vekemans
> Across Canada Trails
>

I am done yet with the deletions. I encountered problems with JOSM. The ways
were deleted but not the nodes partially. Therefore, there are thousand and
thousand orphans nodes that have to be deleted by hand.

>
>
>
> P.S. on another note,
>
> It looks like user pythagore had already did some importing of GeoBase
> roads  (that was back in October). ... was that the sample area? .. probably
> was :)
>
>
> http://www.openstreetmap.org/?lat=47.2218&lon=-61.9588&zoom=13&layers=0B00F
>
> created_by = JOSMnat_ref = cf448c8d7b7c45acb4f82cbfb015ac72highway =
> residentiallanes = 2source = geobase
>
> Richard Weait's option was
> geobase:nat_ref = "nat_ref#"
>
> Or perhaps there's a better option?
>

Of course, it was a proof of concept ;-). I have done : Rimouski, Gaspesia,
Kamploops and Magdelene Islands. For my next boundaries upload, I plan using
the uuid tag to keep the Geobase ID as first proposed by Richard. I think I
prefer geobase:nat_ref. We need to fix this before the next upload.

Michel
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] RoadMatcher

[Steve Singer]

I've been playing around with RoadMatcher 
(http://www.jump-project.org/project.php?PID=RM&SID=OVER) and thought I'd 
share some of my findings.

I've put both a planet.osm dump and some of the NRN provinces into a PostGIS 
database and have pointed roadmatcher at it.  I use auto-match only (no 
adjustments) and generate a listing of OSM ways that are matched to a NRN way.

With this listing we would in theory have the option of

1. Excluding those NRN road segments from the import.  I've modified my version 
of geobase2osm.py to do this and have generated test some test .osm files.  If 
we go this route, then we will need to think about how we will get road names, 
street addresses etc into the excluded ways.

2. We could use that output to delete the osm ways because we see them as 
likely conflicts with the NRN data.

One question is how well does road matcher work, and is it worth the effort in 
running.  I don't have a metric of measuring 'how well' RoadMatcher works.  Nor 
do I yet know what the best RoadMatcher settings are.

I have taken road matcher and generated 'matches' for some tiles and 
excluded these NRN segments from my geobase2osm.py import.

You can bring the .osm files into JOSM (with Open) and view them, comparing 
them to the exisitng OSM ways.  In a perfect world these .osm files won't 
have any overlapping ways with the exisitng OSM data (in practice this isn't 
the case)

NTS 090F, covers the Tofino BC area)
-
http://www.mediafire.com/?zmtm2tov001

It did a decent job of matching many of the smaller roads.

NTS 030M05 (Hamilton to Oakville  Ontario)

http://www.mediafire.com/?dymoxmdlw11


In the spot checks I did roadmatcher missed many matches I was expecting it 
to make. I don't understand why it made some matches but failed to match 
some others.  In other cases the Ontario NRN geometry is strange (they 
sometimes model a residential street with 2 segments, then switch to one 
segment then switch back to two (all in between an intersection).


(NTS 074D , covers Fort McMurray, Albert)

http://www.mediafire.com/?4qtwcgnbn1m

The matching seemed better here than Ontario but it is hard to know which 
ways are duplicates because they are newer than my canada.osm dump and which 
road matcher is missing.

Warning: I've discovered that some of roads in OSM were added after I 
grabbed my canada.osm dump (a number of weeks ago).  This accounts for some 
roads you'd expect to match but didn't but in some cases roadmatcher failed 
to match for no good reason I can see.




It seems to do particularly bad on matching the long low resolution traces of 
major highways but the success rate on shorter ways is more promising.

Also, it looks like it is possible to run roadmatcher in an automated fashion 
for this type of match.  It would require some scripting though and preping 
of input files.

My intent in posting these .osm files is to show what RoadMatcher is capable 
of NOT to get feedback on the tagging of the converted ways (I don't think 
the vesrion of geobase2osm.py incorporates Jason's recent changes)

Please don't try to upload these files to the OSM database (be patient).


Steve


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] types of merges (for an ideal world)

[richard]

In an ideal world, we would be able to snap our fingers and have Geobase
and other data sets merged into OSM in a magical way that allows future
updates, maintains community contributions, and fights climate change.  We
don't live in that ideal world, and snapping my fingers hasn't done the
job.  So it will probably need some code and elbow grease.

There are different types of things that we would like to merge.  Perhaps
some of them are easier than others?  Does it help the coders to list some
of these things?  Mostly I have questions, but here are some possible
categories of merges.

OSM ways with better / more data.  Some OSM ways have names in places
where Geobase has no street names.  We'd want to preserve the street
names.

OSM data that has no Geobase equivalent.  Cycle paths, pedestrian paths
and boardwalks aren't in Geobase are they?  Hopefully we could hang on to
that data, even if we were to strip and replace the road data around it.

POI.  Does Geobase have pubs?  Think of the pubs.  Please think of the
pubs.  Can we save the pubs?  Granted, pubs may have the highest mapper
per address of any business, put still...  (oh, and hospitals too.  What
ever.)

Relations.  Some relations are appearing for transit routes cycle routes
and lakes with islands, etc.  Is that something that we can save / merge?

Other categories or sub-categories?  Or is this worth pursuing?

Best regards,
Richard


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Geobase NRN import script

[Steve Singer]

On Thu, 1 Jan 2009, James Ewen wrote:

> Can you slice the GML file up into chunks? We could manually start the
> import process by manually defining areas where we want to start
> importing data. Areas chosen by users with little or no existing data.


The geobase2osm.py script lets you pass a bounds file (with the -b option). 
This will only include roads that pass through the bounds specified in the 
file.  So you can take the full provincial GML files but only generate .osm 
files for smaller chunks.

As Jason mentions in his other post, adjoining chunks will have duplicate 
ways.  I don't think it will be that difficult to eliminate these 
duplicates though.  We just need a script that searches for two OSM ways 
with the same geobase_nid that occupy the same space, and delete one of them 
+ merge in any adjoining ways.


>
> James
> VE6SRV
>

Steve



___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] types of merges (for an ideal world)

[richard]

In an ideal world, we would be able to snap our fingers and have Geobase
and other data sets merged into OSM in a magical way that allows future
updates, maintains community contributions, and fights climate change.  We
don't live in that ideal world, and snapping my fingers hasn't done the
job.  So it will probably need some code and elbow grease.

There are different types of things that we would like to merge.  Perhaps
some of them are easier than others?  Does it help the coders to list some
of these things?  Mostly I have questions, but here are some possible
categories of merges.

OSM ways with better / more data.  Some OSM ways have names in places
where Geobase has no street names.  We'd want to preserve the street
names.

OSM data that has no Geobase equivalent.  Cycle paths, pedestrian paths
and boardwalks aren't in Geobase are they?  Hopefully we could hang on to
that data, even if we were to strip and replace the road data around it.

POI.  Does Geobase have pubs?  Think of the pubs.  Please think of the
pubs.  Can we save the pubs?  Granted, pubs may have the highest mapper
per address of any business, put still...  (oh, and hospitals too.  What
ever.)

Relations.  Some relations are appearing for transit routes cycle routes
and lakes with islands, etc.  Is that something that we can save / merge?

Other categories or sub-categories?  Or is this worth pursuing?

Best regards,
Richard


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] What we dont know from GeoBase

[richard]

James Ewen said:
> On Thu, Jan 1, 2009 at 12:30 AM, Dale Atkin  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
>> which
>> 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
you mean.

> 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.

Best regards,
Richard


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Geobase NRN import script

[Jason Reid]

James Ewen wrote:
> On Thu, Jan 1, 2009 at 4:17 PM, Jason Reid
>  wrote:
>
>   
>> The script will generate a single OSM file per GML file, so 1 per
>> province currently.
>> 
>
> Any plans on how to merge the OSM and GeoBase files into one database?
>
>   
>> The mapping between the Geobase tags and OSM tags is a work in progress
>> still, it roughly follows whats on the wiki, both on the geobase import
>> and the Canadian tagging guidelines. This is the largest area of the
>> script that needs refinement yet.
>> 
>
> I think this is going to be the single biggest problem once we have
> the database merged. Do we stick with what GeoBase has the roads
> tagged as, or do we change the tags to meet what the OSM descriptions
> are? I see in the script that you are going to be overriding the
> GeoBase tags simply based on highway numbers.
>
>  # Primary (5-100)
>   if ref >= 5 and ref <= 100:
> self.tags['highway'] = 'primary'
>
> # Secondary (500-899, 901, 940)
>   if ref >= 500 and ref < 900:
> self.tags['highway'] = 'secondary'
>
>  # Tag Transcanada/Yellowhead as trunk
>   if ref == 1 or ref == 2 or ref == 3 or ref == 4 or ref
> == 16 or ref == 35 or ref == 43 or ref == 49 or ref == 201 or ref ==
> 216:
> self.tags['highway'] = 'trunk'
>
> Portions of Highways 2 and 16 near Edmonton meet the description of
> Motorway. If we change the attribute to reflect the fact that the
> highway is a restricted access major highway with access ramps, how is
> that going to affect future update imports?
>
> I've looked at the NRN, and seen discrepancies between what is in the
> database, and what exists on the face of the earth. It's going to be
> interesting to see how much the GeoBase database gets modified by OSM
> users to fit their idea of what's out there.
>
> That being said, I don't think this should stop the progress being made.
>
>   
>> You can see some of the initial converted data rendered on the map at
>> http://openstreetmap.ca/map/. This map will be updated periodically as
>> things progress, as a test bed to make sure that things are working. So
>> not all provinces are there yet.
>> 
>
> What I see looks good! I've poked around southwestern Manitoba
> checking out the area where my Dad grew up, and can identify the towns
> just by the highway grid, and the roads in town. Add in hydrography,
> some railway and placenames and it's starting to look like a real map
> that you'd have to pay money for! The road import is looking really
> good. I can't see the attribute tags on that site, but it's a visual
> treat to see all that data.
>
> Can you slice the GML file up into chunks? We could manually start the
> import process by manually defining areas where we want to start
> importing data. Areas chosen by users with little or no existing data.
>
> James
> VE6SRV
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca
>   
In terms of breaking the upload into smaller pieces, we can either slice 
the GML file, or slice the OSM file (using osmosis). Both would be about 
the same in terms of complexity. Either way there will still be an issue 
of duplicate nodes and/or ways where the boundaries are crossed, which 
was the reason for initially wanting to see if we can break it up into 
smaller jurisdictions using the data in Geobase. I believe that the 
TIGER import had this same issue with duplicates along the 'seams'. 
Worst case if we split it up into blocks of a certain size it wouldn't 
be too hard to tell it to start importing the lesser populated areas first.

In terms of actually adding the data into OSM, the only real solution is 
to use the API and the bulk_upload tool (or a tool with equivalent 
functionality). The upload will take quite a bit of time to fully run, 
even if we had all the provinces with full data when we begin. Theres no 
way that we can simple push a button and have it all in the main OSM 
database. Depending on how long it will be until the developers who are 
working on the new API think it will be ready, it may even be an idea to 
hold off the import until it is in place so we can take advantage of its 
new versioning functionality. I'd personally recommend waiting, just as 
I dislike the thought of having to either re-run the export after we've 
already imported some of the data, or convert the raw datafiles.

The tagging will be the single largest issue of contention, not only for 
the upload but for applying updates in the future as well. Take your 
example of Highway 2 for instance. If we upload it as it is in Geobase 
(which works out to be a primary highway I believe), but then you 
correct it to be what you think it is (for instance, highway=motorway), 
then the update script comes along and sets it back to primary, theres 
the potential for a bit of disagreement to take place. There

Re: [Talk-ca] Geobase NRN import script

[James Ewen]

On Thu, Jan 1, 2009 at 4:17 PM, Jason Reid
 wrote:

> The script will generate a single OSM file per GML file, so 1 per
> province currently.

Any plans on how to merge the OSM and GeoBase files into one database?

> The mapping between the Geobase tags and OSM tags is a work in progress
> still, it roughly follows whats on the wiki, both on the geobase import
> and the Canadian tagging guidelines. This is the largest area of the
> script that needs refinement yet.

I think this is going to be the single biggest problem once we have
the database merged. Do we stick with what GeoBase has the roads
tagged as, or do we change the tags to meet what the OSM descriptions
are? I see in the script that you are going to be overriding the
GeoBase tags simply based on highway numbers.

 # Primary (5-100)
  if ref >= 5 and ref <= 100:
self.tags['highway'] = 'primary'

# Secondary (500-899, 901, 940)
  if ref >= 500 and ref < 900:
self.tags['highway'] = 'secondary'

 # Tag Transcanada/Yellowhead as trunk
  if ref == 1 or ref == 2 or ref == 3 or ref == 4 or ref
== 16 or ref == 35 or ref == 43 or ref == 49 or ref == 201 or ref ==
216:
self.tags['highway'] = 'trunk'

Portions of Highways 2 and 16 near Edmonton meet the description of
Motorway. If we change the attribute to reflect the fact that the
highway is a restricted access major highway with access ramps, how is
that going to affect future update imports?

I've looked at the NRN, and seen discrepancies between what is in the
database, and what exists on the face of the earth. It's going to be
interesting to see how much the GeoBase database gets modified by OSM
users to fit their idea of what's out there.

That being said, I don't think this should stop the progress being made.

> You can see some of the initial converted data rendered on the map at
> http://openstreetmap.ca/map/. This map will be updated periodically as
> things progress, as a test bed to make sure that things are working. So
> not all provinces are there yet.

What I see looks good! I've poked around southwestern Manitoba
checking out the area where my Dad grew up, and can identify the towns
just by the highway grid, and the roads in town. Add in hydrography,
some railway and placenames and it's starting to look like a real map
that you'd have to pay money for! The road import is looking really
good. I can't see the attribute tags on that site, but it's a visual
treat to see all that data.

Can you slice the GML file up into chunks? We could manually start the
import process by manually defining areas where we want to start
importing data. Areas chosen by users with little or no existing data.

James
VE6SRV

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Geobase NRN import script

[Jason Reid]

Thanks to some patches from Steve Singer, I've committed a new version 
of the NRN import script to the SVN repository. This version uses the 
python OGR bindings to better process the source data, and Steve also 
worked out a system to merge junction nodes together (earlier versions 
of the script ended up with multiple identical nodes at a junction, 1 
per way). The script can be found at 
http://svn.openstreetmap.org/applications/utils/import/geobase2osm/ if 
you are interested.

For those who are not familiar with what has been mentioned in the past 
about the script, it takes the GML files provided by Geobase and 
converts them to OSM. The conversion is as close to a 1 to 1 as we can 
get it, if there is a linestring in the GML it becomes a way in OSM, a 
point in the GML it becomes a node in OSM. All the relevant tags (nrn id 
#'s, etc) are assigned to the proper OSM entities. The script could 
theoretically be modified in the future to use the shapefiles provided 
by Geobase, however I've had some discussion with individuals at Geobase 
and was assured that the only difference between the gml and shape files 
is the format, the data inside is identical.

The script will generate a single OSM file per GML file, so 1 per 
province currently. What I had envisioned when I first drafted the 
program in October 2007 (following the discussions at FOSS4G 2007, well 
before we had official permission to use the data) was to take these 
files and split them into smaller chunks to upload, either by a certain 
size or some smaller jurisdictions, and likely upload them in a process 
similar to how the TIGER data was incorporated into OSM (a dedicated 
upload script running and uploading each file one after another). The 
biggest issue that I can forsee with multiple people doing the upload is 
the possibility of two people uploading the same section (which is not 
fun to clean up, especially in areas where the geobase data is not the 
only data), and the sheer size of the upload. The GML files alone are 
nearly 8gb before any processing, and that is with the current files 
that only a select few have street names, etc, included.

The mapping between the Geobase tags and OSM tags is a work in progress 
still, it roughly follows whats on the wiki, both on the geobase import 
and the Canadian tagging guidelines. This is the largest area of the 
script that needs refinement yet.

You can see some of the initial converted data rendered on the map at 
http://openstreetmap.ca/map/. This map will be updated periodically as 
things progress, as a test bed to make sure that things are working. So 
not all provinces are there yet.

-Jason Reid

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] What we dont know from GeoBase

[James Ewen]

On Thu, Jan 1, 2009 at 12:30 AM, Dale Atkin  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 which
> should work, and should provide a better overall mapset for everyone, and
> provide means for updating with user data in a means that will be preserved
> across revisions (which I think was the main problem with wiping out the
> database and starting over with public datasources as a base), but I've not
> really gotten any feedback on it. No one has told me "well that won't work
> because 'x'. Or that isn't in line with the OSM philosophy because 'y'.

I read Sam's message last night, and thought about replying, but
declined. I probably would have written in a message that would have
been more abrupt. I raked Sam over the coals already, and didn't think
it would be good to do it again. Sam's trying very hard to make this
import a reality.

I appreciate Sam in the fact that he finds all kinds of stuff and
throws it out in front of me. Most of it I discard, but some of it is
good information that is of importance towards this project. We just
need to focus Sam on the goal, and take the distractions away!

Sam, forget about converting Ibycus to OSM. It's not the way to go. No
one besides yourself thinks it's the way to go. Even Dale says it's a
bad idea. Drop it, and concentrate on getting GeoBase data into OSM.
Forget CanVec as well... the project is GeoBase to OSM.

Dale, I seem to have missed out on your description of your solution.
Can you 'splain it to me again?

There are people working on scripts out there, but they seem to be
keeping them quiet. Maybe there's some communication happening on
other forums, but I don't see it here. I've been communicating with
two individuals who are making progress towards creating scripts to
start the upload of GeoBase data to OSM. Michel is one, and his
geopolitical boundaries upload efforts can be seen be all. There's
another individual working on an NRN import script. I'll leave it up
to him to decide when he wants to go public though. I don't have his
permission to disclose his information.

> Instead we just seem to be talking in circles getting nowhere.

I don't think so, Dale... You're just getting dizzy watching Sam run
in circles! 8) The rest of those with comments all seem to be headed
in the same direction.

I see only 2 real hurdles to be overcome:

1) Decide on which GeoBase attributes get mapped to which OSM attributes.
2) Determine how to merge the new GeoBase data into the OSM database
while still adhering to the OSM Code of Conduct.

We're currently making some progress on #1, with the wiki page showing
proposed attribute mapping.

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. 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)

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.)

I am favouring adding OSM tags to GeoBase ways to get the GeoBase
nodes in place for future comparison. I am guessing that for future
GeoBase updates, we would not only look at GeoBase ID numbers, but
also at node locations. Some relocation of nodes by OSM users will
happen, and having the ability to find these discrepancies would be
nice. A node relocation might have happened by accident, or by design.
Having the future updates highlight this would make it easier to know
if the update should happen, or be left behind because the OSM data is
newer or more accurate.

For future updates from the GeoBase database, the script would compare
GeoBase IDs, and node locations to note whether there has been any
changes made to the data. Where changes are noted, the 

Re: [Talk-ca] OpenStreetMap Canada

[Sam Vekemans]

Thanks, I cc'd to Talk-ca discussion list, as yes, this is a volunteer group
working on the project.
What i plan on doing (hopefully) is getting those regional images, showing
the state of the map as each can be shown on the various wiki pages.

Thanks for keeping us on the radar,
Sam Vekemans
Across Canada Trails

On Thu, Jan 1, 2009 at 8:59 AM, Peter Miller wrote:

>
> On 1 Jan 2009, at 01:58, Sam Vekemans wrote:
>
>  Hi there,
>> It would be great if someone would be able to watch the developments of
>> the Canada Map.
>> For the 2009 year, we plan on having the whole GeoBase Import complete,
>> which amounts to a TONNE of new data being added. Specially watching the
>> Provinces of Yukon, Alberta, & Nova Scotia as these provinces have the more
>> complete dataset available.
>>
>>
> We will see what we can sort out for you.
>
> We should be able to produce an animation for Canada as a whole - we have
> some technical work to do first though so no promises as to dates yet.
>
> I do notice that you also have got good boundaries at level 4 in Canada so
> we should be able to produce still images for each province in the near
> future focused on different tagging. It is still a little early to be sure
> when we will be ready with this stuff but it is on our list.
>
>  We are still in lots of discussions, but would be great to have an eye
>> kept on viewing the progress.
>>
>>
> Are these discussions with the authorities on releasing the data?
>
> Just to be clear - you have sent this email the 'sales' - if you were
> offering real money then some of the above could happen faster, but as a
> rule we expect to provide services for OSM map contributors for free and
> only charge for future products which are aimed as end-users, but I should
> at least ask :)
>
> Regards,
>
>
>
> Peter Miller
> ITO World
>
>
>
>  Thanks,
>> Sam Vekemans
>> Across Canada Trails
>>
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Using geobase postGarmin data to OSM

[Sam Vekemans]

Cool,You made a good point.
re: Using geobase postGarmin format data to OSM.

Because with the Garmin Format, we are limited to the set number of defined
map feature types to choose from.  So all the GeoBase data, needs to fit
into one of the Garmin Categories. .. and in many cases, thats hard to
define when there isnt one.

Unlike sending the data direct from GeoBase to OSM, where we can choose to
tag it what we like, and be happy to know that Garmin does already conform
to OSM standards. ..

..
And ya, the suggestion to make it OpenSource is much more practical.

re: discussion of wipe & replace
I think Richard Weait & Richard Degelder made some pretty good arguments.

Fortunately, bad ideas DO result in further explanation of good idea's and
getting another step closer to the goal.  (although frustrating... it's
still another step forward) :)

re: wiki GeoBase Import Talk page.
Now it looks like there's some tidying up todo on the wiki page, to remove
those irrelevant points ... and explain why they were removed, so for future
import discussions people have something better to work with.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] What we dont know from GeoBase

[Richard Degelder]

On Thu, 2009-01-01 at 00:30 -0700, Dale Atkin wrote:
>  
> 
> From: samvekem...@gmail.com [mailto:samvekem...@gmail.com] On Behalf
> Of Sam Vekemans
> Sent: Wednesday, December 31, 2008 9:43 PM
> To: Richard Degelder; talk-ca@openstreetmap.org; Dale Atkin; Michel
> Gilbert; Mepham, Michael
> Subject: What we dont know from GeoBase
> 
> 
>  
> 
> Hi all, 
> 
> I'll try to separate the ideas into separate discussions :)
> 
> 
>  
> 
> 
> We don't know:
> 
> 
>  
> 
> 
> 1. Is GeoBase/GeoGratis going to make available the dataset so that it
> can be shown as Nodes ONLY?
> 
> 
>  
> 
> Define “Nodes ONLY”. With my understanding of ‘nodes’ its trivial
> (although IMO of limited usefulness) to back this out of the data that
> is already provided. 
> 
>  

GeoBase/GeoGratis will not provide us with their data in the form of
nodes.  If we want to use nodes we are going to have to take their data
and convert it into nodes ourselves.  They provide the data as is and it
is up to the users, in this case ourselves, to convert it into something
meaningful for our purposes.  They neither care about the outcome, at
least to some degree, nor the process to achieve it.

But we are not going to import GeoBase/GeoGratis as nodes.  OSM uses
ways, as does GeoBase although they have a different term for it, and
the attributes are assigned to the way.  Why should we not keep the
format that both the source, GeoBase, and the recipient, OSM, both use?
Converting the source into something different prior to the import and
then requiring that it again be converted into something that is useful,
and happens to be pretty close to the same format that the original data
was in, is a massive waste of time.

Importing everything as a set of nodes, especially when there is not an
obvious relationship or order between them, is going to be meaningless.
As a previous comment on this list that stated that connecting these
nodes in the proper order is a non-trivial task were the order is not
obvious.

Because the ways within OSM are going to have the attributes it makes
sense to work with ways from the beginning.  It is these ways that we
are going to be giving the NIDs and use the nodes as a means of defining
the ways.

Also importing the GeoBase data as a set of nodes would mean that the
import is meaningless on it own.  We are still going to have to connect
these nodes together in order for them to be useful.  Are you proposing
that we make such a massive make work project?  Earlier you eluded to a
billion "pylons" across Canada.  They are meaningless without a lot of
people spending a lot of time with editors connecting them together.
And that effort is not going to be made which will negate the value of
the import.

> 
> We need this because;
> 
> 
> 1.1 - thats how any updates can happen. ... it's like a bar-code for
> everything that is imported, so we know how to deal with it.
> 
> 

GeoBase does not do updates based on nodes but based on the OSM
equivalent of ways.  The relevant data, for GeoBase, is the NID.  As
long as we add the NID the the OSM attributes for the way we can
consider usig it for future updates.  
>  
> 
> ??? Huh ??? I must have missed something major
> here, or some major misunderstanding of something because I don’t see
> how nodes are going to help in the update process (at all). Rather
> they’ll make it more difficult, and just confuse the issue. 
> 
>  
> 
> 
> 1.2 For those areas of EXTREME osm coverage, is handy, because its
> easy to spot where new mapping work is needed.
> 
> 
>  
> 
> 
> 2. Re: Road Name/Numbers
> 
> 
> Is geobase going to have all of the road names and numbers available
> for all the provinces?  and when?
> 
> 
>  
> 
> This is contingent on deals being made with the various provincial
> authorities. Here is the current status:
> 
> http://www.geobase.ca/geobase/en/partners/index.html#nrn
> 
>  
> 
>  
> 
> 
> We need to know this because:
> 
> 
> 2.1 StatsCAN already has available, so it could be an option to grab
> the raw data directly from there?
> 
> 
>  
> 
> This is an *EXTERMELY* bad idea. Trust me. The positional accuracy of
> the StatsCan dataset is garbage, they even say so (although not in
> such extreme language) is one of their write-ups. One might be able to
> use it to manually transfer street names over (or a very clever
> programmer might be able to work out some AI to do it, but that
> wouldn’t be me), but anyone trying to use it for positional accuracy
> will be sadly disappointed. 
> 
>  
> 

Even if StatsCan had extremely accurate data the licensing precludes our
having access to it currently.  So looking at what they offer is a waste
of time.  It is, apparently, going to be incorporated within GeoBase
eventually, and at that time will become available to us, but until that
time it is off limits.  When it is incorporated within GeoBase it will
be related to their NIDs and so will be used to update it OSM if we
want.

>  
> 
> 2.1.1 but does stat

[Talk-ca] Maritme borders in Canada

[Sam Vekemans]

Hi there,Reading the discussion about boarders reminds be of the interesting
situation off the coast of Nova Scotia to Newfoundland, where there is an
island which is Actually part of France.
... there is also an extra part of Quebec, north of Prince Edward Island
(Magdelene islands).
So tagging gets interesting.


Anyway, Im not sure if Michel was able to remove the 1st round of GeoBase
import, the GeoPolitical Boarders, so to set it right.  The problem was
about the number of nodes in a way, and a solution was given (but it's WAY
beyond my ability to understand :) ... i thought that you might be able to
be of some help here.
http://lists.openstreetmap.org/pipermail/talk-ca/2008-December/000483.html

Thanks,
Sam Vekemans
Across Canada Trails


P.S. on another note,

It looks like user pythagore had already did some importing of GeoBase roads
 (that was back in October). ... was that the sample area? .. probably was
:)

http://www.openstreetmap.org/?lat=47.2218&lon=-61.9588&zoom=13&layers=0B00F

created_by = JOSMnat_ref = cf448c8d7b7c45acb4f82cbfb015ac72highway =
residentiallanes = 2source = geobase

Richard Weait's option was
geobase:nat_ref = "nat_ref#"

Or perhaps there's a better option?
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] GeoBase import more questions and ideas

[richard]

Dale asked some things and Sam answered below:
>> I'm of the impression that there are:
>> a) a set of built in 'tags' that the rendering engine uses. (is there an
>> exhaustive list anywhere)

These should get you started.

http://wiki.openstreetmap.org/wiki/Map_Features
http://wiki.openstreetmap.org/wiki/Proposed_features
http://wiki.openstreetmap.org/wiki/Deprecated_features

> Seeing as how you were able to convert the raw GeoBase data into Garmin
> format, there got to be a way to convert that post-IMG file you created to
> OSM format, using what you already created.

Sam, this sounds like a Really Bad Idea.  Converting good data from the
source format into a proprietary, imperfectly reverse engineered format,
then into the open OSM format makes no sense to me.  The Geobase (and
other source) data is rich and diverse.  The OSM format is rich, diverse
and extensible.  The Garmin format is optimized for one use only; to work
on a Garmin handheld.

Why do you suggest that we handcuff the Geobase data by filtering it
through the Garmin format?  Why do you suggest that we poison OSM by
making it reliant on translation through an intermediate, proprietary
format?

There are benefits to going the other way, and converting OSM data to use
on Garmin devices.  See the existing projects here, they already include
reference to the tool Dale uses, cGPSmapper and also to free tools.

http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin

>> Wouldn't the most sensible way to add information be to take the
>> original
>> SHPs and go from there? (including *all* of the database information).

That sounds like the way to go, Dale.  And that is in line with what the
TIGER import and other data imports have done, as far as I know.

> Since you already made up your own GeoBase2garminIMG conversion
> chart/list,
> it would really help if we could see this chart.

This doesn't apply at all for the Geobase conversion and import to OSM,
but I can see it being a helpful addition to displaying OSM data on a
Garmin.  Dale, would you consider Open Source-ing, and contributing your
experience?
http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin

> So far, as we saw Michel Gilbert has been able to;
> get the shape files; attach source tags; attach the OSM map feature, and
> import it.

Again, Bravo, Michel!  The border that you have converted and uploaded is
a big improvement.  Here it is, rendered, in Lake Ontario.  Notice the
previous US import shows the border as hugging the US coast line.
http://www.openstreetmap.org/?lat=43.002&lon=-78.747&zoom=9&layers=B000FTF

> The reason i suggest grabbing the data direct from the .mp file

Really bad idea.  See above.

> The DOWNSIDE of this 5 step process is that it DOES NOT keep the geobase
> NID

That sounds like a further, fatal flaw with the idea of converting through
the Garmin format.  How can future Geobase updates even be considered if
the NIDs / UUIDs are dropped?

Then Sam added:
> in response to the 2nd messages before i send this.
[ ... ]
> who else can also answer the question:  What is the Goal of this Project?

The wiki says it well, on the front page:

  OpenStreetMap creates and provides free geographic data such
  as street maps to anyone who wants them. The project was
  started because most maps you think of as free actually have
  legal or technical restrictions on their use, holding back
  people from using them in creative, productive, or
  unexpected ways.

The project is many different things to many different people.  There are
82,086 OpenStreetMap participants, as of 01 Jan 2009.  I've been fortunate
enough to meet a few hundred OSMers in the last two years.  Some of them
are:

- cyclists who want great cycle maps that don't end at the town line or
state border.
- coders and developers who love making F/LOSS tools.
- entrepreneurs who (plan to) profit from reselling OSM data and services
built upon OSM.
- neighbourhood advocates who want to map the Business Improvement
District, save the local wetlands, or both.
- geography professionals who are intrigued by the F/LOSS approach to GIS
and the OSM tools.
- researchers who are interested in OSM as a source of data.
- data providers who wish to widen the reach of their data.
- entrepreneurs who want to put their company on the map.
- hardware enthusiasts who want to put a map on their PDA, phone, laptop,
watch...

I've never been able to predict in advance who would have questions about
what aspects of OSM, but most would ask about questions about:

- why use OSM compared to {some other online map}
- how to do a survey and contribute data.
- how to get started with the editors.
- how is data rendered.
- when does my contribution appear on the map.
- how to map their specific personal interest.

But then many people would have widely diverging interests that might
cover one or two of:

- how is distributed programming used in tiles at home.
- can OSM show historic maps.
- details of data structure in OSM.
- how to 

[Talk-ca] email message: spam

[Sam Vekemans]

It looks like my last message showed up on the talk-ca list for some reason
from my hotmail account.  I removed talk-ca as a contact of hotmail, so
hopefully it wont show again.
Sorry about that,
Sam
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] GeoBase import more questions and ideas

[Sam Vekemans]

Hi Dale, in answer to the other questions;

I have a question to throw out there...
>

> Can someone point me to an API or tutorial or something for OSM that
>
discusses uploading manipulating the data (in a way that could be scripted)?
>
I've seen the web interface, but obviously that is no good for this kind of
>
thing unless one wants to spend days in front of the computer doing this.
>

We have the d...@openstreetmap.org discussion list, which is for all the
developers of openstreetmap back-end, as its rather complex, only some
people REALLY understand how it works.

if you haven't already done so, the wiki page,
http://wiki.openstreetmap.org/wiki/Develop

Should help a bit, as it shows a mashup of the whole OpenStreetMap Project.

Whats cool about the OpenStreetMap project is that it's a whole bunch of
people who are all working at the project all at the same time, making for
less work for each individual user.  So each program that gets made, gets
added to the repository so then others can copy bits of code from other
programs, to make a much better program.




> I'm of the impression that there are:
>

> a) a set of built in 'tags' that the rendering engine uses. (is there an
>
exhaustive list anywhere)

b) that the user can extend these tags to include custom information

c) that there exists an API for interacting with the database.
>

The tagging standards are always debated, and improved.  There is a file
somewhere which contains all the most used OSM map features  (put just cant
find the link)

And there is no limit on the amount of custom information people want to add
on the tags.
and for the API ...
http://wiki.openstreetmap.org/wiki/Api
on the d...@openstreetmap.org discussion list are those folks who know how to
deal with it.


Seeing as how you were able to convert the raw GeoBase data into Garmin
format, there got to be a way to convert that post-IMG file you created to
OSM format, using what you already created.
http://wiki.openstreetmap.org/wiki/Mkgmap
User: Steve Ratcliffe
 made
that program so maybe he can be of assistance.




> Wouldn't the most sensible way to add information be to take the original
>
SHPs and go from there? (including *all* of the database information).



Would you be able to explain HOW you imported all the data to your base
computer?
(You said that it's pritty much all in the script routeen.)

If your able to post what your Raw scripting was/is ... then the other users
in the community would be able to modify it.
As right now, were just working from scratch, trying to figure out this
geobase monster,
So then when looking to figure out what data is actually available, we have
something to work with,
(obviously, getting the latest information possible is important too)

Since you already made up your own GeoBase2garminIMG conversion chart/list,
it would really help if we could see this chart.

As yes, it would make sense that the import script is able to;
1 - download all the GeoBase/Geogratis data for that tile area.
2 - attach all the Geobase:source tags needed
3 - attach all the OSM map feature types to the data
4 - be able to import it all in bulk or just select certain Geobase features
to import.

So far, as we saw Michel Gilbert has been able to;
get the shape files; attach source tags; attach the OSM map feature, and
import it.

The python script is here
http://svn.openstreetmap.org/applications/utils/import/geobase2osm/
so far it's just the NRN thats been added, and i think it's Jason Reid who
did that scripting work. (so far)

It would be great to add on your chart you used when grabbing GeoBase data,
so the work wont be duplicated.
Then we (the talk-ca list) can work on the hardest part;   Agreeing to how
the stuff should be tagged, so then it will get rendered right. ... the 1st
time.

The reason i suggest grabbing the data direct from the .mp file or (combined
shapesfile) is that it's only with GPSMapEdit that the user could;
1 simply go through it and select only 1 map element,
2 delete the rest of it (reverse selection - delete)
3 then save the file as a new .mp file,
4 use the mp2osm program to convert the file for OSM
5 open up JOSM .. .and open that modified .mp file to check and remove any
unwanted data.. then upload the changes.

The DOWNSIDE of this 5 step process is that it DOES NOT keep the geobase NID
...
BUT the UPSIDE  of this process is that it keeps all the existing OSM data
intact.
and the other upside is that many types of data can be imported in 1 go.
... ie... everything (as well as the Roads) can be imported. .. and the user
can square off the downtown core, and single out only specific map features
that they want.
(attaching the tag from:geobase)

So ...if people like the above idea.. the TODO would be to update the mp2osm
program to show  how to convert it (if not done so already)
http://code.google.com/p/mp2osm/

..
Hope that helps,
Cheers,
Sam Vekemans
Across Canada Trails

[Talk-ca] (no subject)

[Sam Vekemans]

 


hi:   Heya, how are you doing recently ? I would like to introduce you a 
very good company which i knew.They can offer you all kinds of electronical 
products which you need, such as motorcycles, laptops, mobile phones, digial 
cameras, TV LCD, xbox, ps3, gps, MP3/4, etc. Please take some time to have a 
look at it,there must be something you'd like to purchase.Their website: 
aobcc.com
Their Email:ebay_hot#yahoo.com.cn ( Please change＃to @ )Their MSN: 
e.bayhot#hotmail.com   ( Please change＃to @ )


Hope you have a good mood in shopping from their company!Best Regards!___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca