Re: [Talk-ca] openstreetmap.ca : français/québ écois...
Bonjour, Je suis surpris de tes conclusions soient aussi rapides. To courriel sur osgeo-qc est apparu hier. Quatre personnes ont répondu à ton message jusqu'à maintenant; c'est ce que tu appelles beaucoup ? Je participe à l'OSM depuis 3 ans, sans avoir utilisé openstreetmap.ca. Le domaine principal combiné au talk-ca sont suffisants pour faire passer l'information considérant les ressources disponibles. Je ne vois comment on maintiendrait un niveau supplémentaire d'information. Tes efforts de traduction por le domaine openstreetmap.ca est un bon exemple qu'il est difficile de maintenir trop de sites. Je trouve que c'est d'encourager la diluation des efforts. L'implication du Québec dans l'OSM est comparable à celui du reste du Canada. Personnellement, je trouve la couverture du territoire est encourageante. De plus, l'initiative GéoBase/CanVec entreprise et future (canvec.osm) apportera une contribution importante. Mettons nos efforts à amener nos organisations à participer au projet, c'est à mon sens une façon concrète et mesurable de participer. Bonne journée, Michel Le 27 mars 2010 03:16, Nicolas Gignac gignac...@gmail.com a écrit : Dear, It is just to let you know that since I did not received any news from the work of French translation I have done one month earlier in the openstreetmap.ca web page, as a member of the OSGeo Local Chapter of Quebec (http://wiki.osgeo.org/wiki/Chapitre_qu%C3%A9b%C3%A9cois), I post my initial idea for an openstreetmap Quebec or French Canada : http://lists.osgeo.org/pipermail/quebec/2010-March/000270.html as well as other project I had in mind (loading script unique to quebec datasets, cloud services over OSM, labaratoty environment for school / research / development area in Quebec, etc.). In this post, many persons in Quebec expressed their support to my initial idea and one of the member offered his help within his organisation as a hosting service for : osm-qc site, open raw datasets specific to Quebec, French documentation unique to Canada / Quebec, loading script, mapping party news in Quebec and so on. Everything that will be unique to Canada an din English will be linked to the actual openstreetmap.ca site, everything that is unique to the French language will be linked to openstreetmap.frand everything general to OSM will be linked to the osm world site. So, we are open to all French Canadian outside Quebec to be part of our project as well, just be sure you follow the discussion on the OSGeo-Quebec mailing list. My last question would be : if we want to use the word openstreetmap in our domain name, do we need to be supported by some people, organization or we can process with this : openstreetmap.qc.ca domain without any problem ? Thanks for letting us know and we will keep you all in touch with our project. Cheers, Nicolas Le 24 mars 2010 11:40, Richard Weait rich...@weait.com a écrit : 2010/3/24 Nicolas Gignac gignac...@gmail.com: It is just to know what is going on with the French part of openstreetmap.ca? I send an email with all the corrections and I still did not received any update... If it cannot be made quickly, can I have write access and do the editing by my self? I haven't seen Jason reply on this thread. Did he indicate to anybody that he would make these changes, or that he would accept help to do so? I haven't seen confirmation that Jason still runs openstreetmap.caeither. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca -- Michel Gilbert ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [OSM Sherbrooke discussion] Re: Geobase / Canvec import workshop in Sherbrooke?
of Quebec too). Also Alex (user:Oxalin) and his friend are willing to lend a hand. So, that would already be 5 persons, if all of them can attend, and 6 including you. And, as mentioned I also hope to get some people from the Montreal area interested. Importing all of the data is a lot of work. I think that road-wise we're about halfway in Quebec. Not too bad, but it could be better, considering that other provinces are finished. Importing is more than just uploading the data to the OSM server, so I want to pay some attention to cleanup an other quality aspects as well. This certainly improves the data quality, which opens the way for things like routing. Although information about the import is available in several places (wiki, talk-ca), it is hard for someone just starting to get going. Unfortunately the guy who took on himself to coordinate the import has a communication style which is hard to follow. Also the wiki pages are outdated, or not entirely correct (as is the current shp-to-osm page). Certainly, someone could improve it, but I think it would be more effective to show in person how things are working, what to look for, etc. Hence this idea. Frank -- To unsubscribe send an email with subject unsubscribe to osm-sherbrooke-discuss...@lists.coactivate.org. Please contact osm-sherbrooke-discussion-mana...@lists.coactivate.org for questions. -- Michel Gilbert ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] no preset nodes
Hi osmers, Is there someone in Alberta can explain what are the no preset nodes for ? There 2 nodes at each way intersections in many cities I checked : Red Deer, Ponoka, Wetaskiwin ... Is this part of the process to connect the way intersections not created during the import ? Thanks, Michel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Fwd: canvec2osm sample area tofino BC _with roads
2009/4/1 Sam Vekemans acrosscanadatra...@gmail.com Hi Simon, Yup, It's kinda cool seeing both the CanVec roads the geobase roads in the same spot. Check out Glenwoodville,AB http://www.openstreetmap.org/?lat=49.3667lon=-113.5167zoom=13layers=B000FTF when viewing the canvec data overtop. I checked the area mentionned below. At intersections the osm ways do not share the same node. Therefore, it means that lines are not connected to each other. At intersections, it is important to share the same node. To duplicate nodes it may look fine cartographically but it does not respect the osm model. I decided to check other locations in Alberta and it seems that the problem is everywhere. Was anyone aware of that problem ? Michel http://sites.google.com/a/acrosscanadatrails.com/www/Home/canvec2osmsamplearea082h05PincherCreekAB.zip Look forward to the feedback, Cheers, Sam -- Forwarded message -- From: Sam Vekemans acrosscanadatra...@gmail.com Date: Wed, Apr 1, 2009 at 11:35 AM Subject: canvec2osm sample area tofino BC _with roads To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org, Michel Gilbert michc...@gmail.com, Steve Singer ssinger...@sympatico.ca, Richard Weait rich...@weait.com Hi all,Yupee, I got the sample area saved (not yet posted to OSM) of Tofino, BC You can view the zip file containing the .OSM files. http://sites.google.com/a/acrosscanadatrails.com/www/Home/canvec2osmsamplearea092f04tofinoBC.zip The addition of the CanVec Roads looks good, so far. But (of course) would need to be fixed up. I compared the geobase2osm roads, and i see that i have included a few more tags that were not included in the geobase2osm script. For now the rules.txt file is available in the same place. http://docs.google.com/Doc?id=d2d8mrd_179gnhs54cwhl=en I'm now working on the wiki chart, to show all of the tags that i use. ... in the next few days it should be done. :-) ... i found this way (adding it to canvec2osm) rather than creating the canvecROADS2osm script seemed to be easier. Didn't take much longer to run the script. For those who can read the rules.txt file let me know if you see any errors. (even if i already spot them, it's good to confirm what the right tags should be. And Steve, my plan is still to wait till you run the geobase2osm script (unfortunatly i dont know how too),,, before loading any of the canvec data on top. If you have a chance, please let me know if it would be fine to be importing the data for .. those areas of very very little to know OSM data.?? . And everyone,.. since the geobase2osm script would detect that canvecROADS were already imported, it would look at them the same way as user created OSM Roads.??? Thought on that anyone? Cheers, Sam Vekemans Across Canada Trails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca -- Michel Gilbert ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Fwd: canvec2osm sample area tofino BC _with roads
Sam, Your Tofino CanVec data has the same problem. At intersections, all the geometries must share the same node. So when you generate the osm ways to create the osm file you must built them with the same node id at intersections. It is true for all the features not only roads. It is easy to see: in josm or potlatch if you try to move the node at an intersection all the features should move. If only one move it means that the node is not shared by the features. I think it is wrong ! Michel 2009/4/1 Michel Gilbert michc...@gmail.com 2009/4/1 Sam Vekemans acrosscanadatra...@gmail.com Hi Simon, Yup, It's kinda cool seeing both the CanVec roads the geobase roads in the same spot. Check out Glenwoodville,AB http://www.openstreetmap.org/?lat=49.3667lon=-113.5167zoom=13layers=B000FTF when viewing the canvec data overtop. I checked the area mentionned below. At intersections the osm ways do not share the same node. Therefore, it means that lines are not connected to each other. At intersections, it is important to share the same node. To duplicate nodes it may look fine cartographically but it does not respect the osm model. I decided to check other locations in Alberta and it seems that the problem is everywhere. Was anyone aware of that problem ? Michel http://sites.google.com/a/acrosscanadatrails.com/www/Home/canvec2osmsamplearea082h05PincherCreekAB.zip Look forward to the feedback, Cheers, Sam -- Forwarded message -- From: Sam Vekemans acrosscanadatra...@gmail.com Date: Wed, Apr 1, 2009 at 11:35 AM Subject: canvec2osm sample area tofino BC _with roads To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org, Michel Gilbert michc...@gmail.com, Steve Singer ssinger...@sympatico.ca, Richard Weait rich...@weait.com Hi all,Yupee, I got the sample area saved (not yet posted to OSM) of Tofino, BC You can view the zip file containing the .OSM files. http://sites.google.com/a/acrosscanadatrails.com/www/Home/canvec2osmsamplearea092f04tofinoBC.zip The addition of the CanVec Roads looks good, so far. But (of course) would need to be fixed up. I compared the geobase2osm roads, and i see that i have included a few more tags that were not included in the geobase2osm script. For now the rules.txt file is available in the same place. http://docs.google.com/Doc?id=d2d8mrd_179gnhs54cwhl=en I'm now working on the wiki chart, to show all of the tags that i use. ... in the next few days it should be done. :-) ... i found this way (adding it to canvec2osm) rather than creating the canvecROADS2osm script seemed to be easier. Didn't take much longer to run the script. For those who can read the rules.txt file let me know if you see any errors. (even if i already spot them, it's good to confirm what the right tags should be. And Steve, my plan is still to wait till you run the geobase2osm script (unfortunatly i dont know how too),,, before loading any of the canvec data on top. If you have a chance, please let me know if it would be fine to be importing the data for .. those areas of very very little to know OSM data.?? . And everyone,.. since the geobase2osm script would detect that canvecROADS were already imported, it would look at them the same way as user created OSM Roads.??? Thought on that anyone? Cheers, Sam Vekemans Across Canada Trails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca -- Michel Gilbert -- Michel Gilbert ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec/Geobase point feature - Render
2009/3/23 Sam Vekemans acrosscanadatra...@gmail.com Thanks, Good call. :-) The point feature building=yes otherwise known as point,CODE,2010010,canvec:CODE,2010010 point,CODE,2010010,building,yes What it does is show up as a little house icon with JOSM for the polygons, they show up as nice shapes.. and when clicked on would simply state this this is a building. outer,CODE,2010012,canvec:CODE,2010012 outer,CODE,2010012,building,yes inner,CODE,2010012,canvec:CODE,2010012 inner,CODE,2010012,building,yes I have not yet received the answer from NRCan about if the location of the node is EXACTLY where the building actually is, or is it just shown in the general area. If it is the former, then this information can be taken into account. The position of buildings may be exact if the acquisition methods was from stereo-digitization. If it came from map scanning they may have been displaced for map representation purposes. My guess is 80% of the buildings in CanVec come from map scanning. What i can do, and i presume that you all would agree, is to add this feature to the not4osm folder so then it could be used as an assistant for the person who is actually uploading the information. However, I would also agree that adding this feature would be similar to me using the Aerial imagery and whereever i spot some THING that looks like a building, quickly tag it as building=yes. ... this information is meaningless to the map user. ... odds are, that right next to it is some other 'building'. Unless the purpose is clearly stated, we dont need to include this feature. Following the new information I received from tilesath...@openstreetmap.org(i have just forwarded the email to talk-ca) we may still want them for mapping purposes. And YES, there are other point features which need to be looked at to see if they are actually useful. As im going through the sharts, i'll now be looking at it. We can list them, then check with the tilesath...@openstreetmap.org talk if they are part of the render feature. For example, when the feature lists 9 or so different feature types, the general practice for both GeoBase CanVec is to state -1 unknown and 0 none ... i would suggest that these features be omitted from the import also. Any thoughts on that? Again it depends if the tilesath...@openstreetmap.org talk confirm that no render is possible. If we really want them display we can ask them ? Michel Cheers, Sam P.S. I was thinking of adding another column to the 11 themes of CanVec charts, for status PPS. I am still finding some features that were accidentally missed when i was copying the data from the feature catelogue to the charts, so it's a good idea to cross-check with the .pdf catelogue to find out what the actual definition was. ~ probably 95% accurate, but always good to check :-) Hi all, Two weeks ago, I worked on the import of CanVec-Buildings using Map feature table on the wiki. I noticed at that time that point buildings imported as building=yes did not appear on the osm map. Sam probably rebembered the discussion about it. So, I sent my question to the tilesath...@openstreetmap.org. It appears that building=yes will be tilesath...@openstreetmap.org rendered on the map only if they are polygons.tilesath...@openstreetmap.org tilesath...@openstreetmap.org To conclude, I think there is no reason to import Canvec point building unless they have specific functions. It may be true for other point features. We should make sure before importing them. cheers, Michel -- Michel Gilbert ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec (part of GeoBase) Import update
Hi Sam all, The idea is good to import building entities. I think we should concentrate on polygon buildings where we'll get important buildings. To tag them you should first prepare a map between osm tags and canvec building attribute. Of cousre the most important attribute is building function. I imported few buildings in Sherbrooke area ( http://www.openstreetmap.org/?lat=45.37976lon=-71.92381zoom=15layers=B000FTF). I tagged the buildings like this: - k=building, v=university or k=building, v=yes - k=amenity, v=university I don't think Canvec has the amenity concept though. Cheers, Michel 2009/2/20 Sam Vekemans acrosscanadatra...@gmail.com Hi all,I posted a link to the screen shot on the wiki page http://wiki.openstreetmap.org/wiki/Canvec2osm I haven't uploaded any of the data, because I haven't figured out how to get the tags on there (especially the NID) I used the shp-to-osm java program (from Ian Dees), and a basic DOS program to name all the shape files. The shapefiles contain more details, as you can see from the other image, viewing from the JUMP program. The wiki charts show how each feature ID# would match up to OSM. From the example, it would be awesome if JOSM could handle importing just the selected item or selected groups of items, rather than uploading everything that was shown. Is that technically possible? Thanks, Sam Vekemans Across Canada Trails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca -- Michel Gilbert ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec (part of GeoBase) Import update
2009/2/20 Sam Vekemans acrosscanadatra...@gmail.com Thanks, What was the method you used to import the buildings? You that I am a FME fan. So I made a quick FME workbench to import the building. I am going to make it more generic and I'll use the chart you prepared (thanks). I'll add my name on the status table for Canvec Import when I be ready to import buildings. I'll update the chart if it needs to be adjusted. Michel The method i discribe should NOT be used, as i dont use the many different building ID's available (the wiki chart has the list of what tags each ID Should get). http://wiki.openstreetmap.org/wiki/CanVec:_Buildings_and_structures 2010009_2.shp includes everything from Train Station Buildings to Educational Buildings (48 or so different building ID's) ... the _2 indicates polygon. And yes, CanVec doesnt distinguish between different educational buildings... lumps them all in to the same category. Also my method does not imort NIDs. Cheers, Sam On 2/20/09, Michel Gilbert michc...@gmail.com wrote: Hi Sam all, The idea is good to import building entities. I think we should concentrate on polygon buildings where we'll get important buildings. To tag them you should first prepare a map between osm tags and canvec building attribute. Of cousre the most important attribute is building function. I imported few buildings in Sherbrooke area ( http://www.openstreetmap.org/?lat=45.37976lon=-71.92381zoom=15layers=B000FTF ). I tagged the buildings like this: - k=building, v=university or k=building, v=yes - k=amenity, v=university I don't think Canvec has the amenity concept though. Cheers, Michel 2009/2/20 Sam Vekemans acrosscanadatra...@gmail.com Hi all,I posted a link to the screen shot on the wiki page http://wiki.openstreetmap.org/wiki/Canvec2osm I haven't uploaded any of the data, because I haven't figured out how to get the tags on there (especially the NID) I used the shp-to-osm java program (from Ian Dees), and a basic DOS program to name all the shape files. The shapefiles contain more details, as you can see from the other image, viewing from the JUMP program. The wiki charts show how each feature ID# would match up to OSM. From the example, it would be awesome if JOSM could handle importing just the selected item or selected groups of items, rather than uploading everything that was shown. Is that technically possible? Thanks, Sam Vekemans Across Canada Trails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca -- Michel Gilbert -- Michel Gilbert ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] FME 2009 OpenStreetMap
Hi all, FME is very usefull for importing geospatial data. I have been using FME to import the boundaries and NRN Geobase (tests) . At this time, FME provides a reader for osm format but not a writer. However FME allows to execute python within your FME workspace. So I simulate an osm writer in python within my FME. If there are other FME users for importing Geobase data, I will be happy to share my workspaces. Michel 2009/1/13 Sam Vekemans acrosscanadatra...@gmail.com Hi, i saw OpenStreetMap listed as one of the formats listed when looking at the press release. I am wondering in what way would this software be helpful? OpenStreetMap is a non-profit foundation (so it might be possable to use it for no cost)? I dont have that much knowledge about how useful it could be, so it would be nice to know. Thanks, Sam Vekemans Across Canada Trails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Geobase Canadian Geopolitical Boundaries - take 2
Hi all, The upload is complete. The boundaries should appear on the next release. Let's start from there. Michel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Maritme borders in Canada
2009/1/1 Sam Vekemans acrosscanadatra...@gmail.com 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.2218lon=-61.9588zoom=13layers=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
Re: [Talk-ca] Deleting Ways
2008/12/30 Richard Weait rich...@weait.com On Tue, 2008-12-30 at 22:52 -0500, Michel Gilbert wrote: The new file with boundaries at 500 nodes is ready for an upload. But first I have to delete the current ones. Dear Michel, Bravo. The first run of the border import is a wonderful improvement, even if imperfect. Thank you for doing it. For the re-upload, may I suggest these changes? source = name of your conversion script and version # then make it available on the wiki / SVN as GPL? created_by = name of your upload script and version # then make it available on the wiki / SVN as GPL? nat_ref does not apply in my opinion. OSM expects ref for highway shields. Use a new tag like geobase:nat_ref = nat_ref# so that it is namespaced and does not break other uses of nat_ref. Use geobase:uuid = uuid# where geobase provides them. I will take your suggestions. I like when people gives good ideas. Right now, I have my two hands deleting the current boundaries. Thanks, Michel Best regards, Richard ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Geobase Geopolitical Boundaries
Hi all, I imported the Geobase Canadian Geopolitical Boundaries as described in a previous thread. The content is defined at the wiki page http://wiki.openstreetmap.org/wiki/GeoBase:_Canadian_Geopolitical_Boundarie s . The upload took about 10 hours. I uploaded 162 305 nodes and 503 ways. I checked out the output using Potlatch. Potlatch behaved strangely, loading ways is very long and I kept getting messages about Adobe Flash Player. I suspect that Potlatch or OSM have problems with heavy ways (many nodes). What can I do to make it work ? I may have to remove the boundaries I have just uploaded. Is there a way to make a bulk removal ? I thought boundary layer was an easy one :-(. Michel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GeoBase to OSM attribute mapping.
2008/12/26 Jason Reid o...@bowvalleytechnologies.com James Ewen wrote: Just looking at some attributes... The alleyway/lane is currently mapped as highway:service. I would suggest that highway:service is more appropriate. Here's the description for a sevice road: Generally for access to a building, motorway service station, beach, campsite, industrial estate, business park, etc.. This is also commonly used for access to parking and trash collection. Sometimes called an alley, particularly in the US. Local/unknown is currently mapped to highway:service. This should probably be highway:road. where that is described as: Road with an unknown classification. This tag should be used temporarily until the road has been properly surveyed. Once it is surveyed the highway tag should be changed to record the appropriate classification. Rapid Transit is currently mapped to highway:bus_guideway. I'm thinking railway:light_rail, at least in Edmonton, our rapid transit system is a light rail transit system. Perhaps other areas of Canada have a rubber tire based guided transit system. When working on another GeoBase to public map project, I ended up making Freeway and Expressway map to the same road type, with Highway mapped to the next lower level. There's no mapping to highway:trunk. I'd have to dig into the NRN deeper to look at sample roads and tags again, but I think our top level roads would map to highway:motorway. This would include such entities as the Queen Elizabeth II Highway (#2) between Edmonton and Calgary, although in some areas the restricted access limits don't quite apply. In Alberta, we haven't tagged anything as highway:motorway. Our top level tag is highway:trunk. This GeoBase/OSM project could work to unify the tagging across the country! What about Freeway - highway:motorway, Expressway - highway:trunk, Highway - highway:primary? James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca The prototype import script (http://svn.openstreetmap.org/applications/utils/import/geobase2osm/) was built using the following: However, there are corrections made to this, mostly to align things with what each province classifies the roads as (a classification that doesn't map directly to geobase as each province has its own). This is to accomplish getting certain things to be correct. For instance, when I last looked at the geobase data there were some highways that were primary in one province, but crossed the border and were a secondary highway in the other. But geobase used the same classification level on both sides. Each province has a set of guidelines as to which number groups mean what, which maps closer to the OSM based guidelines then how Geobase maps the data IMO. Then there are also considerations for things like the NHS highways, which are laid out on the Canadian Tagging Guidelines ( http://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Highway_Tags ) Personally I can't see any real way to do the import without taking the differences between the provinces into account. I think homogeneous tags are very important within OSM. Therefore we should make everything possible to map Geobase road classification Canada wide. Geobase road classification as described in their Feature Cataloguehttp://www.geobase.ca/doc/specs/pdf/GeoBase_FeatureCatalogue_SegmentedView_NRN_2_0_EN.pdf is a result of Provinces and Territories consensus. So the mapping between Geobase ans OSM should be one to one. My proposed tags: freeway motorway expressway primary arterial secondary collector tertiary local/streetresidential I started the feature tagging on the wikihttp://wiki.openstreetmap.org/wiki/Geobase_NRN_-_OSM_Map_Feature . Michel -Jason Reid ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GeoBase Node Import idea ver 1.0
Hi Sam, 2008/12/17 Sam Vekemans acrosscanadatra...@gmail.com Hi there, After some serious review, (writing a hudge essays about the answer to the question. What do you want to get from GeoBase? (Answer: a better free wiki map showing more of Canada) and Why Import GeoBase to openstreetmap? (Answer: because it will make the map better) I came up with new questions and an idea. Question 1: From looking at the entire GeoBase/CanVec collection, which is held in Sherbrook. Is this data stored in a form where the Images/Shapes/Lines are all available a nodes. .. a point in space? So for the images, 4 nodes representing that image cover area. For shapes, all the nodes representing the polygon, which has a relation together so the interface shows it as a shape. For the lines, it contains a series of nodes. If yes, then this should be true. Each node would have all the attributes which GeoBase needs to make the datasets, and to provide the WMS feed, and provide different types of data that you make available for all the different usergroups that GeoBase has. I am afraid to say that the data management model is not as the osm one. Feature classes are stored as point, line and polygons. There are not nodes as I think you expected. The ortho-images (Landsat and Spot) are stored as flat files by NTS and by image scenes. For production purposes we index classes that define the image coverage. To obtain Geobase as nodes we could dissolve the geometry if we want then add the attributes to them. That will make a hell of lot points. Question 2: Out of the CanVec collection which also has NID's, for Images/Shapes/Iines, these are also made up of a series of relations, so it knows that point A,B,C D are all part of the polygon that make up this area... this area is labled. Then, looking at each node individually, your software that you use to extract this data, needs to know the exact coordinates of the node, and how it relates to eachother. Is that right? Here's the Idea: We import to OpenStreetMap the full NRCan/GeoBase/CanVec database.. not as shapes/ways/and lines.. but just as nodes.. and do not connect these nodes. We essentially import a Canada Node dump into OpenStreetMap, which shows all of the attributes that the nodes have. .. making sure to include: -NID -the name in English/French -the object type that NRCan uses. -the date at which the data was collected. -accuracy of the node -maybe the GPS coordinates ... and everything else that is relevant and included on the node. (and everything else which is needed for GeoBase/CanVec/NRCan 's use) -and the date at which it was imported into OSM (is already on there) -and who imported it.. is already on there Then after the Great Canadian – Node Dump Party.. we relax. And know that updates to GeoBase/CanVec/NRCan will be made available sometime.. and shown as more nodes to be added. Then after that.. For those areas which contain no OSM data.. we can go ahead and import all the data as shape file/ways/lines/points.. and make up a possible OSM relation that it could be, we can fix the import script so then it would show it better (closer to what it should be). ... but don't really need to be that picky. (covering up the lonely nodes) ... it's kind of random... as thats whats made for the Ibycus topo map.. it's a match-up which is estimated, as a best guess. ... at least it shows up as the right colour and line type.. so when your looking at it on the Garmin.. its looks good. ... even though the ocean is listed as a lake. .. it's still blue... type=water.. as everything in the NHN thats a shape file.. and everything that is just a line can be a listed as a river. .. go for basics. ... The OpenStreetMap project is this: 'The Free Wiki World map'... It doesn't have to show exactly what GeoBase/NRCan says is there. ... this is why the nodes are imported... the nodes show all the technical details that GeoBase/NRCan/CanVec needs. When an update is available... we only import the new node dataset... and have the latest date attached as another tag. .. (it would anyway, but its important to have in planted in there, along with the source name) So for those areas which contain more data than GeoBase/CanVec (NRCan) has... all that will be made available is the nodes. .. so at all the intersections, there will be a point put in there.. and so, it would be up to the OSM Mappers discretion if they want to move the existing road-node on top of this node.. or leave it the way it is. .. the mappers can use those nodes as a 'guide' .. but not the 'rule' ... after all- we make up our own rules, and debate about it :) ... probably agree to import everything BUT the roads in many cases. :) These nodes will not be recognized by any renderer.. accept the GeoBase renderer, but it pulls the data from the feed. .. the real purpose these serve is to tell users that the road
Re: [Talk-ca] StatsCan Road Network
2008/12/11 Brent Fraser bfra...@geoanalytic.com Kevin, Good point. I got excited by the unrestricted-use claim... Kevin Farrugia wrote: Would the StatsCan Data be available to us though (to input into OSM based on our license)? After reading the license agreement it sounds a bit iffy because of the acknowledgement required even if it is released under an unrestricted use license a greement, but I don't know what exactly is allowed at OSM. Here's an excerpt from the license agreement for the road network: The Geobase NRN has better geometry: it is accurate (published accuracy) and homogeneous. I do not think you will find out what are the sources used by Stats Can for their product. Also, Geobase adopted update cycles and provide a Unique National Identifier to track the changes. For now Geobase does not have a full attributive product for street names and adresses but partners are working to create the NRN 2.0 wich includes those attributes. I think Stats Canada is one of the partners for the NRN 2.0. Michel : 4.2 The Licensee shall reproduce, include and maintain the following notice on all reproductions of the Licensor's Data produced pursuant to Section 3 above: Reproduced with the permission of Statistics Canada 4.3 The Licensee shall incorporate in all reproduction and downstream distribution of the Data all metadata included by the Licensor in the provision of the Data. Gratis, but not truly libre. But they may be willing to make an exception for OSM. Brent Too bad there wasn't a common UID across all of the government databases though, because if there was we would be able to merge the address attributes into the GeoBase/CanVec road network, and address location and network routing would be possible in the future. Hopefully they are working on that, but who knows... -Kevin Farrugia (Kevo) ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canadian data - GeoGratis (and an accuracy rant)
2008/12/10 Matt Wilkie [EMAIL PROTECTED] Hi Brent, thanks for bringing up the oft-overlooked and even more often misunderstood confusion of accuracy over precision. Most (some? all?) of the CanVec data originally came from the 1:50,000 NTS topographic maps . Precision and accuracy is a subject that comes back all the time in Geomatics. Thanks to Wikipediahttp://en.wikipedia.org/wiki/Accuracy_and_precisionto help me explain why the CanVec, Geobase, NTDB documents are rigth when they describe the metadata. Precision as defined by Brent is realted to the computer world not scientific world. Precision is about repetition measures not the number of decimals. Michel For clarity: which had their coordinates rounded off to the nearest metre (in UTM coordinate space), as per the NTDB specification. matt wilkie Geographic Information, Information Management and Technology, Yukon Department of Environment 10 Burns Road * Whitehorse, Yukon * Y1A 4Y9 867-667-8133 Tel * 867-393-7003 Fax http://environmentyukon.gov.yk.ca/geomatics/ Brent Fraser wrote: I'm sure they mean accuracy instead of precision. Precision is just the number of digits stored/displayed, whereas accuracy is how well the data reflects reality. Just because you chose to display coordinates to the nanometer doesn't mean they are that accurate. Not that I want to confuse the issue, but it can be important. Most (some? all?) of the CanVec data originally came from the 1:50,000 NTS topographic maps . Within the past few decades some have been updated from medium-resolution satellite imagery, and some have been updated with data from the various Provincial 1:20,000 mapping initiatives. At any rate, the Quantitative Horizontal Accuracy Value is given in the metadata for each NTS sheet, with a number 30 meters being common. To stir the pot even more, the Manitoba government (https://mli2.gov.mb.ca//) has it's 1:20k topographic maps available for free (and the license looks libre too). Their metadata gives accuracy values (Horizontal_Positional_Accuracy) of 1.25 meters, 2.5 meters, etc. Wow! I expected 20 meters at best. And don't get me started on the accuracy of hand-held navigation-grade GPS receivers... Best Regards, Brent Fraser Richard Weait wrote: Hi folks, From the good folks at Natural Resources Canada (GeoBase). Yes you can use the data found on GeoGratis site . The licences are identical. The only differences are the copyrights, one is GeoBase, the other one is NRCan (GeoGratis). Please note: The data found on GeoGratis could have different planimetric precision and could not fit exactly with the precise GeoBASe data or OSM data. Please refer to the metada info of the files you will be using. I'm sure that we are all excited about the additional data. Please note the guidance regarding precision. Best regards, Richard ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GeoBase Import Rev 2 - where we stand now CanVec (like Ibycus before combined maps)
2008/12/9 Steve Singer [EMAIL PROTECTED] On Mon, 8 Dec 2008, Sam Vekemans wrote: So anyway... No bother with GeoBase anymore... as it's CanVec which has all the data already done. With respect to the road network one thing to consider is update frequency. The Canvec data is updated twice a year, geobase seems to publish when they get the data ready. Right now only 4 provinces/territories have street names and 3 with addresses. I think we are going to be very anxious for the updates that add street names to the other provinces. I am not sure how far canvec lags behind the geobase updates. Pulling the road data from geobase doesn't exclude pulling additional layers from canvec. I think we would still want to deal with each layer (or related layers) as seperate projects. I agree with you entirely. For Geobase themes included in CanVec there will be a lag between 6-12 months. CTIS plans for 2 releases a year. But depends on the timing with the provinces we may miss last minute data delivery. Also I prefer working with Geobase tiling for import. It is easier to work 13 tiles (NRN) than with 13000 NTS 50K tiles. For the National Hydro Network, Geobase tile is the drainage areas. There are about 1000 of them still easier than NTS tiles. Michel Cheers, Sam Steve ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GeoBase wiki pages
2008/12/8 Richard Weait [EMAIL PROTECTED] Does it make sense to split up the GeoBase Import pages by database? Perhaps somebody with some wiki-fu could look at this for us? As we fill things in on the current page it will soon be too long a page to be easily managed. I'm imagining: GeoBase Import - with an introductory paragraph, brief history, and a status table and links for the sub-projects. Move the announcement down the page, or link to it on a separate page? Then separate pages for each sub-project, for example: GeoBase Satellite imagery - description of the data, source and how OSM came to have it. - existing resources: is it in a public WMS? - Plans: can a WMS plugin for josm / potlatch / merkaartor take advantage of the existing WMS? - Who's planning to do what to integrate the resource for OSM use? Perhaps as a table with the specific tasks, task owners, milestones and progress indicators that can migrate back to the summary page? Then similar pages as appropriate for the other sub-projects. Does this seem about right? I like the idea. It will be easier to follow the progress by sub-project. Michel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GeoBase Import - Where we stand now
2008/12/6 Sam Vekemans [EMAIL PROTECTED] Ok, cool :) Lots of great discussion points.Again, I'll try to summarize with this info, and hopefully setting somethings as a foundation. (in story form) Basic questions: What do we want to accomplish with the OpenStreetMap project? and What do we want to accomplish from Geobase? Here's IMO plus adding in everyone else's views (to the best of my ability) By adding features that we are not likely to be able add the map ourselves, we can import GeoBase data. IF the prime purpose IS to complete the road network across Canada, then in doing so this will cause issues. This is because, technically speaking. The GeoBase road database IS ALREADY the complete road network across Canada. Period. With future updates, this database, will ALWAYS be the complete road and official road network for Canada. It's a federally funded database, with the goal of being the complete network. So .. no matter how we twist and turn it, it will still be complete. Soo... However, if the prime purpose is to create a totally free and editable map of the world, we must then treat GeoBase with the same level of indifference that we do to user:Acrosscanadatrails. Just so happens that there will be a few users who are importing the data, and have spent a real long time gathering tracks and points, and converting the points into ways, and labeling them, and is ready to start bringing in the data. Just as user:Acrosscanadatrails did, when he started; He didn't know how this whole thing worked, and so he started adding in roads. .. and just had it as highway=secondary, and highway=road for those ways that he didn't now. ... then he found out that having it as a secondary road, didn't quite match what similar roads where in other towns, he changed it to highway=residential, then someone else came along and changed the name from James St. to James Street and HWY 4 to highway 4. So the point is; Is that we can go ahead and start the import, working at it 1 tile at a time. And just learn as we go along. (use the chart and the talk list to keep the discussion going) (i use User:Acrosscanadatrails as the example for me importing geobase data) So for the areas where User:Acrosscanadatrails did alot of gps tracks and ways, and converted them to ways and points, and has it all sitting waiting for the import. Sadly :( the work he did was for nothing. :( as he found out that a whole mapping team was just in the area and did it all already. So user:Acrosscanadatrails, doesn't need to complain about it, as after all, the GPS Tracks he did, DID get imported to the back-end database. ... and all his points and ways he made got put aside and into the PostGIS database, as after-all, he did take time to write the house numbers down. But these numbers just need to be converted to a point along side the road in the center of where the house is, or real close or converted to a square, where the 1 side is right on the road. but anyways.. after all no renderer's can read his hand writing from his note paper (BTW, I do have bad hand writing :) ..) but he was smart enough to keep track of his own numbers, so these numbers are listed with each point and way he made. So after a while, when user:Acrosscanadatrails started to import roads; he called them 'freeways' instead of 'moterways'. ... perhaps because he's stubborn? and doesn't want to change his ways? ... well fortunately Python script came along to help him translate and speak OSM language. So the next tile import does the conversion already. Fortunatly, user:Acrosscanadatrails still keeps the cross reference number he originally started with. So now user:Bikecanada comes along and imports more data. and imports it slightly different, and tags it differently. .. but thats ok, because other users will come along and fix it to how it should be. So now user:Acrosscanadatrails went around a year later and added in more roads (not thinking if any thing has been added) and goes around and just takes note of all the new subdivisions that came up. Well, he'll just to what he did before... upload his traces to the database, and upload his points and ways he made to the PostGIS database. But this time, the script which converts his previous imports is tweaked so it's much much smarter. ... However, because he knows where his reference points where, he can only add on extra features that would not be added on otherwise. So... he needs to only add in the house numbers, and not add in the actual road. (or he can add in the road class/surface, but only if it hasn't been done) As he knows that there are other users who are around, and have already drawn in cycleways, schools, parks in detail. as well as the local roads. All of the roads that have been drawn in by hand, are well within the same degree of accuracy (10 meters) as the roads that User:Acrosscanadatrails has
Re: [Talk-ca] GeoBase Import - Where we stand now
2008/12/6 Steve Singer [EMAIL PROTECTED] On Sat, 6 Dec 2008, Michel Gilbert wrote: I need some clarification about the parallel database (PostGIS). I am sure I see the whole picture of the Geobase Import process. Who is going to host the change tracking PostGIS database ? How are we going to access it ? I prefer a process model that uses only osm database. I don't see how we are going to maintain the PostGis database for users that access Potlatch or JOSM. May be I have not understood the concept yet. I was thinking that the spatial database would only be used to generate the mappings between the OSM and geobase nodes. Once a OSM node was deemed to be a geobase node the live OSM database would be updated to contain the geobase_nid tag. You wouldn't keep the PostGIS database around, after the initial mapping process has done you will be able to get the 'mappings' from the OSM database by examining everything with a geobase_nid tag. PostGIS was only an example platform for generating automated mappings, you could probably do this in a JOSM plugin (that reads geobase files) and has geometric routines for determine if two lines a essentially the same. Ok. I do not mind to work with spatial database such as PostGIS if it is needed for the import. However when i have done some tests to import Geobase data into osm I did not use intermidiate storage. Here's what i have done: 1. Read osm data (bounding box) 2. Read Geobase data in shape file (same bounding box) 3. Reproject in LCC (it is easier to manipulate data in x,y coordinates) 4. Compare both sources to identify Geobase segments that will be import 5. Tag Geobase segment as osm ways 6. Integrate the geobase to osm ways: 1. snap geobase ways to osm ways (add nodes to existing osm way) 7. Reproject to geographic coordinates 8. Generate osm nodes: 1. existing osm nodes 2. new nodes added to existing osm way (geobase snapped) 3. new nodes for geobase segments 9. Generate osm ways to include new osm nodes 10. Generate new osm ways that came from geobase 11. Generate osm file 12. Then use JOSM to upload the update file Did we figure out the development platform ? The basic script to map the road classes are written to work with JOSM ? or could it be something else. I work with FME (Safe Software) a canadian company in BC. It is a great ETL (Extract,Transform,Load) application. I know it is a commercial product but it could help for the task we have. FME read osm and PostGIS formats and offers many tools to find change detections and manipulate attributes and geometry. FME has a large community, may be even among osm. It could be interesting to find out. This is still open. A lot depends on how much manual intervention is required in the process. If the process can be automated then I think we'd want scripts that can be run in a batch fashion (so not a JOSM plugin) but if each tile is going to need a fair amount of manual massaging then a JOSM plugin is more appealing. We also have to consider what people are willing and able to develop in. I wouldn't exclude FME on the basis that it is commercial it does restrict the pool of developers that could help with any scripting (and might have implications on where/how the import gets run) Good. I am familiar fme. If i participate in the import I'll try to make generic fme workbenches so they'll be sharable among participants. Michel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] terminology
2008/12/5 Richard Weait [EMAIL PROTECTED] You know, I thought highway=motorway should be highway=highway, but this points out a more fundamental issue. :-) Geobase has Freeway and Highway classifications. The migration of TIGER files used motorway. For me, I think homogenous tagging is more important than semantics. Michel http://xkcd.com/503/ ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Import Geobase Geopolitical Boundaries
*7-Zip* is *open source* software for file archiving with a high compression ratio. You can download it at http://www.7-zip.org/. Next time I will compress it as zip file. Michel 2008/12/4 Corey Burger [EMAIL PROTECTED] On Thu, Dec 4, 2008 at 5:56 AM, Steve Singer [EMAIL PROTECTED] wrote: On Tue, 2 Dec 2008, Michel Gilbert wrote: Hi all, I have worked on the Geobase Canadian Geopolitical Boundaries. I took the prov_ab_p_geo83_e.shp file that contains the administrative The results ftp://ftp.cits.rncan.gc.ca/pub/nsprod/mg/osm/ can be seen with JOSM but it is very slow. The file is heavy, What file format is administrativeArea.7z in? It doesn't appear to be gzip,zip or a .osm file. 7z is an alternative zipping format. You might need 7zip or WinRAR (on windows) or the 7zip package on a Linux box. Corey ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Import Geobase Geopolitical Boundaries
Hi all, I have worked on the Geobase Canadian Geopolitical Boundaries. I took the prov_ab_p_geo83_e.shp file that contains the administrative areas: provinces and Territories and convert them as OSM boundaries. First, I prepared Geobase Geopolitical Boundaries - OSM map featureshttp://wiki.openstreetmap.org/wiki/GeoBase_Import#Geobase:_Canadian_Geopolitical_Boundaries, then I created FME Workbench to extract, transform and load the boundary polygons in xml/osm format. The results ftp://ftp.cits.rncan.gc.ca/pub/nsprod/mg/osm/ can be seen with JOSM but it is very slow. The file is heavy, a lots of nodes (162305 nodes) to define the ways. For example, British Columbia boundary has 19673 nodes, Northwest Territories has 49189 ... I found it very difficult to process, very consuming in time and cpus. Comments are welcome. Not ready for an upload yet. Cheers, Michel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] importing GeoBase Data (learning from TIGER)
Hi all, 2008/11/26 Dave Hansen [EMAIL PROTECTED] On Wed, 2008-11-26 at 01:40 -0800, Sam Vekemans wrote: I do think it was important to have things broken up geographically. It makes it much easier if something goes bad to find the data, remove it, an retry. Since the data is broken up into Geobase tiles, perhaps importing by tile area to get more specific. The provinces are rather large, so going at it, by 1 degree x 2 degree would be better?? Yes, it probably would be better. However, there is also the problem of stitching things back together in the end. I never dealt with that part. Also 1x2 degrees probably isn't bad for, say, the Yukon Territories. But, I would imagine that Toronto is going to fit almost entirely into one of those. That might pose a few problems. I think the largest .osm file that I uploaded was Kern county in California. It was 165MB. A regular tile size looks fine to me but will introduce duplicates along the edges. How do we handle polygons that cross the bounding box ? From my experience, uploading data with josm has a limitation number. Beyond that limitation josm stops, therefore leaves a mess in the database. May be there are others ways to upload large amount of data. One thing I never considered, but did come back to bite me a few times was concurrency. I'd upload a node, make a way use it, then come back a few hours later to have another way use the node. But, somebody got to the node before I did. There were three or four of these and I fixed them up by hand. It sucked. :) Well, remember (last week i think it was) when OpenStreetMap was shut down for maintenance? Well, what about convincing the foundation to shut down the server so then all the data can be uploaded at once? That would fix the problem that you had. :) Sure, if you can pull this off, go for it. Otherwise, it isn't *that* difficult of a thing to plan for and fix. Basically, if you notice that some node that you need is gone, you just re-upload a new copy of the original node and make a note of it. It's that simple. Keep a record of everything that you do. Keep good logs and make sure that whatever programs you use to upload the data can be stopped and restarted at any time with no ill effects. This generally means keeping a table of which objects have been uploaded and their id mappings. I think we already discovered that the natural features shapefiles data, shouldnt post any conflect... not a major one that is. ... Every city does have some kind of water feature, and it's probably labeled, but thats about it. and for the other features ya pausing OpenStreetMap to make the import happen. would guarentee no point conflicts. I think bulk-upload.pl http://wiki.openstreetmap.org/wiki/Bulk_import.pl does this pretty well, although I did have to customize it a bit. Ya, as as far as i can see, the way that GeoBase keeps the data is a bit different. each province does have a different way of classing roads. .. so when your literally traveling between provinces.. the pavement is identical.. yet the signs on the roads indicate a different road class. (thats because provincial roads are funded provincially, there is very little discussion between provinces. So each provincial upload would be different. (talk-ca talked about it back in the summer) Yeah, one of the first steps is to come up with a conversion scheme to convert your features into OSM features. -- Dave Geobase has a uniformed road classification. The matching between osm and geobase road classes should be applicable globally. I suspect that local contexts may be necessary in some cases (ramp classification form example). We can start Geobase NRN - OSM Map Feature. I can start this. Cheers, Michel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Geobase import idea render=no
Hi, Thank you Sam to bring good ideas. I agree with you that if we put the data available on OSM it will create a bigger community around the OSM. The 'render=no' tag is a good idea to flag conflicts or potential conflicts. But first, we should develop automatic import processes to load without conflict a large amount of data. The hydrography and boundaries will not introduce conflicts or few. For the roads, it is important to integrate geobase ways to existing osm ways. If we import everything without integration it will require a very large effort with josm or potlach to integrate manually the data. It would be possible to integrate a good part of the road and tag the rest with 'render=no'. Does anyone know how the people proceeded for importing TIGER data ? Cheers, Michel 2008/11/24 Sam Vekemans [EMAIL PROTECTED] Hi, after letting the idea spin in my head a while, here's what i got. Import everything from geobase, and just add the 'render=no' tag. Here's why. 1 we already know that all we need todo is select the group of areas, ways points that we see are not in conflect with anything else, and select the tag, and change it to 'render=yes' so a whole bunch of stuff can be released for rendering. 2 when new data is available, it can simply check to see if the tag exists, can check if it needs updating, and update it, but not be rendered. 3 it wont be a problem as since its not rendered, it will only show when a user sees that the rendered version needs to be fixed, when someone is actually there. 4 in the case where geobase is 'wrong' instead of 'incomplete' the 'wrong version would stay and exist in the database, until physially removed, so the next 'dump of data would show it better. 5 would it be possable to have data over top of eachother where the rendered version was combined? Yes, but it wouldnt make a difference as the latest data dump wont be rendered. So heres are challenge, if we can import this all, and prove to the community that this is the best map available, more and more companies will be using this as the best available data. Then local government would see the merrit of contributing, rather than reinventing the wheel. Looking forward to feedback, Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
