Re: [Talk-ca] Fixme Files
Bonjour Osmers First, a few personal news... I am currently transferring my files to François and Nicolas who will take over with the Openstreetmap community. François is already an Osm contributor and Nicolas might soon be a contributor as well. This is not bad news for me as I will soon retire from NRCan and move to St-John's to start a PhD. As someone said ... Go East Old Man! - or something like this !-) Now, about fixme files... - As pointed out by Pnorman, some of the fixme files aren't zipped with related .osm : It will be fixed - The comparison isn't picking up on highway=unclassified : I'll see what can be done to make it run properly. Nicolas should work on it next week. Then, If the community agree, available fixme files will then be included with the corresponding Canvec.osm zip files. Finally, the entire Canvec content will eventually be processed the same way. I think it will be very helpful to the community and to NRCan! Cheers, Daniel -Original Message- From: Adam Dunn [mailto:dunna...@gmail.com] Sent: July 28, 2012 15:55 To: Pierre Béland Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Fixme Files Thanks for the mappaint style Pierre. That comes in very handy! (Following two paragraphs relate to 092G02.1.1.0, you will need to get correct Canvec files from main ftp, as the included files are incorrect, as pointed out by PNorman) Looks like the comparison isn't picking up on highway=unclassified? The notes tag doesn't specify unclassified as being covered, and this seems to be the case from the files. Take a look at this shopping mall area: [http://www.openstreetmap.org/?lat=49.192201lon=-122.948192zoom=18layers=M]. Both Canvec and OSM have the service roads marked as unclassified, and are of equal geometry (in fact, it is a GeoBase import that mbiker did), and yet they are marked as committed (missing in OSM). Across the highway to the south [http://www.openstreetmap.org/?lat=49.187566lon=-122.945054zoom=18layers=M], there are several roads that are tagged unclassified in Canvec 10, but the tagging on OSM has been changed to residential. The fixme file does not contain them (no changes necessary). It would appear that handling unclassified should be included or notification that it's a tagging issue, rather than a commit. (This is from 021I02.0.2.3) It also seems as though you are using newer Canvec data (11?) to generate the fixme file? Looking at random new residential area in Moncton [http://www.openstreetmap.org/?lat=46.071156lon=-64.756724zoom=18layers=M], there are no roads in OSM or the included Canvec files, but the Fixme file lists roads as being present. I guess this is a sneak preview of what will be coming in Canvec 11? The roads are partially constructed when looking at Bing imagery. So far this is some really really great information. Lets iron out the bugs and we'll have an awesome system to work with. Adam On Sat, Jul 28, 2012 at 12:00 PM, Pierre Béland infosbelas-...@yahoo.fr wrote: To facilitate the visualization of Canvec Fixme files and comparison with OSM data in JOSM, I made a Custom Mappaint stylesheet and added Imagery sources to the JOSM Imagery Sources. The file canvec-fixme.mapcss, enclosed in this message, highlights objects with different colors based on the Fixme messages. This helps distinguish the various warning messages related to objects described in the Canvec Fixme file. To use this Stylesheet, save it on your local disk and install it in JOSM from the Mappaint Preferences menu. This will be added to the Map Styles List. The objects are colored based on the Fixme message as described below : COLOR RED Commited - Canvec feature does not match any Osm feature. Missing/Misclassified Osm feature? GREEN Omited - Osm feature does not match any Canvec feature. Missing/Misclassified Canvec feature? BLUE Unmatched - OSM and Canvec geometries are significantly different.Geometries need to be fixed? YELLOWAttributed - Osm and Canvec geometries matched but some common attributes differ. Attributes need to be fixed? I also added Geobase / Canvec Imagery sources in the JOSM Wiki Map page (https://josm.openstreetmap.de/wiki/Maps). To select these Imagery sources in JOSM, select the WMS-TMS Preferences menu. Click on the Refresh button at the right of the smallmap. Then, in the CA section of the list of providers, you can activate Canvec, Geobase Hydro or Geobase roads Imageries. I hope that both the stylesheet and the Imagery sources will simplify the comparison of the Canvec Fixme files with the OSM database. Pierre De : Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca À : talk-ca@openstreetmap.org talk-ca@openstreetmap.org Envoyé le : Vendredi 27 juillet 2012 12h31 Objet : [Talk-ca] Fixme Files Bonjour, Here are some Fixme file samples for Calgary, Moncton, Montreal, Ottawa, St
[Talk-ca] Fixme Files - Differences Between Canvec and Osm
Bonjour, As mentioned in a previous email (1), NRCan is now comparing Osm and Canvec data for planning road network update field work. It is an helpful information and we have decided to provide Osm community with detected differences. We think that these differences will help the community to keep Osm database up-to-date, as the provided differences will have the following fixme tag values ... Commission - Canvec feature does not match any Osm feature. Missing/Misclassified Osm feature? Omission - Osm feature does not match any Canvec feature. Missing/Misclassified Canvec feature? Unmatched - OSM and Canvec geometries are significantly different. Geometries need to be fixed? Attributes - Osm and Canvec geometries matched but some common attributes differ. Attributes need to be fixed? Only significant differences are provided. Some fixme file samples should be available this weekend. Each Fixme file will be included with its corresponding Canvec.osm zip file I will wait for your comments !-) Daniel Note 1: http://lists.openstreetmap.org/pipermail/talk-ca/2012-May/004777.html ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] News from Canvec - address data for NB and missing rivers.
Bonjour, A few words to let you know that ... - the next release of Canvec.osm will include addresses for NB. The block-face addresses were generated using SNB address points. It might be available before this fall. - rivers are missing in about 471 Canvec.osm files from the last Canvec release. The files will be replaced soon. Daniel -Original Message- From: Connors, Bernie (SNB) [mailto:bernie.conn...@snb.ca] Sent: June 21, 2012 14:14 To: 'webmas...@the506.com'; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Proposed import: Service New Brunswick address data J.P., Service New Brunswick (SNB) has started a project to create the New Brunswick Road Network (NBRN). The NBRN will actually be produced through the Department of Public Safety and it's agency - Ambulance New Brunswick. SNB will provide some guidance, QC, and funding. I mention the NBRN project because the NBRN data will include block-face addressing on the road segments. Is it possible that the NBRN data will be a better data source for addressing in OSM instead of the civic address points? I don't know the answer but I hope this information will be helpful. Bernie. -- Bernie Connors, P.Eng Land Information Infrastructure Unit, SNB bernie.conn...@snb.ca -Original Message- From: webmas...@the506.com [mailto:webmas...@the506.com] Sent: Thursday, 2012-06-21 14:51 To: talk-ca@openstreetmap.org Subject: [Talk-ca] Proposed import: Service New Brunswick address data Hello...long time reader, first time poster. You may know me as the one who did (sometimes botched) the bulk of Canvec imports in New Brunswick. That job was completed last week. As you may be aware, Canvec does not include road name or addressing data in New Brunswick. I have generally been using a combination of the StatsCan and Service New Brunswick databases to add road names by hand. It was a long and arduous process that took over a year, but it's finished. Service New Brunswick maintains a publicly-available geocoded database of civic address points in the province (http://www.snb.ca/gdam-igec/e/2900e_1f_i.asp), and their license (http://www.snb.ca/gdam-igec/e/2900e_1e_v.asp) is compatible with OSM. My experience is that the database is very accurate in urban areas, but there are still a lot of gaps in rural areas. Any records that do not currently have a civic number attached will not be imported, and duplicate addresses will be ignored. There are currently very few addresses in NB in the OSM database. They are mostly in downtown Fredericton and uptown Saint John, and those areas will be checked by hand to avoid duplicates. In the rest of the province, an attempt will be made to merge the data with existing ways whenever possible. Each point would have the following tags: addr:housenumber= addr:street= addr:city= addr:province=NB addr:country=CA addr:source=SNB addr:SNBid=unique ID from the SNB database The plan is to break up the import by county, with the smaller less populous counties done first to work out the kinks and check for integrity with existing OSM data. Imports would be made from the 506imports account. Any comments? J.P. Kirby (the506) ___ 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] Re : British Columbia Regional District boundary data
Bonjour David, Bonjour Corey Welcome into OSM community. You'll find that there is nothing better than an active community to find odd features in authoritative data! Cheers, Daniel From: David E. Nelson [mailto:denelso...@yahoo.ca] Sent: June 6, 2012 17:59 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Re : British Columbia Regional District boundary data BTW, as the import progresses north along the BC Coast, that stairstep pattern is going to reappear on the sea boundary of other Regional Districts. This pattern, again, was found in the original boundary data as obtained from DataBC. - David E. Nelsonhttp://members.shaw.ca/nelsonmedia/ From: Corey Burger corey.bur...@gmail.com To: David E. Nelson denelso...@yahoo.ca Cc: talk-ca@openstreetmap.org talk-ca@openstreetmap.org Sent: Wednesday, June 6, 2012 2:44:19 PM Subject: Re: [Talk-ca] Re : British Columbia Regional District boundary data Looks good according to me. Corey On Wed, Jun 6, 2012 at 2:41 PM, David E. Nelson denelso...@yahoo.camailto:denelso...@yahoo.ca wrote: Yes, I set up the second user account British Columbia Regional Districts, as recommended by the import guidelines on the OSM Wiki. I accidentally duplicated a way on the Canada-U.S. Border. I believe that I have now fixed that, and the borders now share a way, as they properly should. Can you confirm? - David E. Nelson From: Corey Burger corey.bur...@gmail.commailto:corey.bur...@gmail.com To: Pierre Béland infosbelas-...@yahoo.frmailto:infosbelas-...@yahoo.fr Cc: talk-ca@openstreetmap.orgmailto:talk-ca@openstreetmap.org talk-ca@openstreetmap.orgmailto:talk-ca@openstreetmap.org Sent: Wednesday, June 6, 2012 1:50:18 PM Subject: Re: [Talk-ca] Re : British Columbia Regional District boundary data Pierre, David N is the real person behind that user. Corey On Wed, Jun 6, 2012 at 1:34 PM, Pierre Béland infosbelas-...@yahoo.frmailto:infosbelas-...@yahoo.fr wrote: Looking at this into JOSM, I see that this step way is a new way166383324 distinct from the Canada-US border. It was created by British Columbia Regional Districts user. This was probably as is in the original data and not detected. Pierre De : Corey Burger corey.bur...@gmail.commailto:corey.bur...@gmail.com À : Andrew Lester a-les...@shaw.camailto:a-les...@shaw.ca Cc : talk-ca@openstreetmap.orgmailto:talk-ca@openstreetmap.org Envoyé le : Mercredi 6 juin 2012 16h15 Objet : Re: [Talk-ca] Re : British Columbia Regional District boundary data I just looked at the layer in the CRD's database and we have it following the US Border, than that stepped pattern. No idea where that mistake came from. Corey On Wed, Jun 6, 2012 at 1:11 PM, Andrew Lester a-les...@shaw.camailto:a-les...@shaw.ca wrote: Note that this CRD map (http://crdatlas.ca/media/8187/crd_adminbounds2009.pdf) shows the boundary following the US border. Otherwise, it looks good. I live in the CRD, so I figured I'd better check it out! Andrew Lester -Original Message- From: David E. Nelson [mailto:denelso...@yahoo.camailto:denelso...@yahoo.ca] Sent: Wednesday, June 06, 2012 1:05 PM To: talk-ca@openstreetmap.orgmailto:talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Re : British Columbia Regional District boundary data That stairstep pattern was found in the original DataBC Tantalis RD boundary data, which should mean that that is the area geographically gazetted to the CRD by the Province. - David E. Nelson - Original Message - From: Corey Burger corey.bur...@gmail.commailto:corey.bur...@gmail.com To: Pierre Béland infosbelas-...@yahoo.frmailto:infosbelas-...@yahoo.fr Cc: talk-ca@openstreetmap.orgmailto:talk-ca@openstreetmap.org talk-ca@openstreetmap.orgmailto:talk-ca@openstreetmap.org Sent: Wednesday, June 6, 2012 1:02:47 PM Subject: Re: [Talk-ca] Re : British Columbia Regional District boundary data Pierre, I see the steps too. I suspect that might be a drawing error, but I need to look more closely. (for the record, I am an employee of the CRD in Regional Planning) Corey On Wed, Jun 6, 2012 at 12:59 PM, Pierre Béland infosbelas-...@yahoo.frmailto:infosbelas-...@yahoo.fr wrote: David, I forgot to discuss about the boundary itself. Why the southern part look like steps and do not follow the red line division? Pierre De : David E. Nelson denelso...@yahoo.camailto:denelso...@yahoo.ca À : talk-ca@openstreetmap.orgmailto:talk-ca@openstreetmap.org talk-ca@openstreetmap.orgmailto:talk-ca@openstreetmap.org Cc : impo...@openstreetmap.orgmailto:impo...@openstreetmap.org impo...@openstreetmap.orgmailto:impo...@openstreetmap.org Envoyé le : Mercredi 6 juin 2012 15h10 Objet : Re: [Talk-ca] British Columbia Regional District boundary data The first Regional District,
Re: [Talk-ca] New Roads to map?
Bonjour Sam, thanks for the clue, we were about to miss it! About the comparison check, it looks at changes in street names. However, we would like to have your list of changes for Winnipeg, just to make sure !-) Best regards, Daniel -Original Message- From: Sam Dyck [mailto:samueld...@gmail.com] Sent: June 4, 2012 13:03 To: Bégin, Daniel Cc: talk-ca@openstreetmap.org Subject: Re:New Roads to map? Bonjour Daniel Sorry for the late reply, I've been working in the bush for the past month. In regards to Road Network updates, the town of Churchill, MB has no roads in Canvec. Getting their requires a two day train trip and it's cheaper to fly to Europe, so since their is no good Bing imagery I haven't added them to OSM. MLI has a map, but it's just a GIF. So keep that in mind when planning the update. Also, will the comparison check street names? If not I can give you a list of street name changes in Winnipeg. Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] New Roads to map?
Bonjour Osmers, I told you in previous emails that we were to use Osm to help us updating the Canvec product. Over the last year I developed a process/software that compare Osm and Canvec data to find significant changes between both datasets. We successfully used it last year, in New-Brunswick, to plan field work for road network updating. We will soon use it again to detect significant differences between Osm and Canvec Road Networks. The detected changes will be used for planning the road network updates of Newfoundland, Manitoba and New-Brunswick. So, if you ever have some gpx tracks that lies in a drawer somewhere, and if these tracks are related to new roads, mapping these roads before the summer will help us a lot. Thanks in advance! Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Canvec.osm Product -Completed!
Bonjour OSMers! Canvec.osm product conversion completed last week! I will soon reprocess the files to create and add metadata (Metadata.txt) into each .zip file. At the same occasion, I will correct some potential oddities identified by Paul Norman. What is new: * There is no more Here be Dragons areas in the Canvec product! NRCan completed mapping Canada at 50K scale about 2 months ago. Almost 100 years after Canada started mapping at this scale (approximately!-) * Municipal Boundaries for SK,MB,NB,YT,NT and NU - linear - are available Changes from previous release: * Water definition (natural=water) now fits the Osm coastline definition (high water level). * Format of the ZippedOsm.txt in ftp site has changed. * The .osm files are now created with a osm version='0.6' upload='false' tag to prevent accidental upload. The data can still be uploaded, it just gives another warning before the upload so that the mapper can double-check his action. http://wiki.openstreetmap.org/wiki/CanVec#CanVec_10http://wiki.openstreetmap.org/wiki/CanVec Thanks to those who are maintaining this wiki page :-) Let me know if you find unexpected problems in the data. Cheers, Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canadian imports: good or bad?
Bonjour Steve, I'm pretty comfortable with your propositions and wording, as a contributor :-) However, as data provider representative, my emails on this list aimed at providing information to help the community to better understand the product, not decide for them. So I invite the rest of the community to comment on it! Best regards, Daniel Ps: I'll write a little something about accuracy ( from home, as a contributor!-) -Original Message- From: Steve Singer [mailto:st...@ssinger.info] Sent: April 25, 2012 22:03 To: Bégin, Daniel Cc: Paul Norman; talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Canadian imports: good or bad? On Wed, 25 Apr 2012, Bégin, Daniel wrote: Steve, Paul, I was on the impression that the consensus was more about using Canvec where it is the best available source and, when it is not, the data could be imported, but only after an exhaustive verification using available data/imagery. 'best available source' as a standard has appeal to me, and I think this varies by layer (ie your comments in the other email about older hydrography) I think often people are importing all of the layers at once when without evaluating what they are importing. Whatever is the consensus, it should be documented in the wiki. Agreed. I think right now we have consensus on saying: * The osm-ca community wants to import Canvec data * The imports should be done carefully to avoid duplicating objects * Coastlines and large lakes should only be imported by experienced users (which is basically what the wiki already says) Paul proposed two additional guidelines here: http://lists.openstreetmap.org/pipermail/talk-ca/2012-April/004721.html 1. The buildings data from CanVec should not be imported unless it can be verified against imagery, in which case you might as well trace the buildings from imagery. Ie if the imagery (and there is no other source like a local mapper) isn't good enough to verify the buildings then don't import them. It seems, to me, that so many of the 20+ year old building data is no longer valid that we might want to discourage the use of this layer without Do we have consensus on this point? 2. There is not a consensus among the community that CanVec data can be imported without verifying the data for internal consistency and where possible against imagery. I like the sentiment but I don't like the 'negative wording' it doesn't tell people what we DO have consensus on, so it doesn't tell them what they can import. Nor does it explicitly prevent any sort of import. My wording from this morning apparently wasn't good either. How about * When importing Canvec data you should verify that the data you are importing is consistent with other data. For example check that forests aren't sitting in lakes. Sometimes the different Canvec layers are not consistent because the data comes from different sources. You should try to fix consistency issues as you import data. (anyone should feel free to propose some better wording) Is there something we can say in the guidelines to help people judge accuracy? (In most of the areas I map I've found the Canvec data lines up VERY well with Bing and my GPS traces) Steve Furthermore, I think that internal consistency/accuracy/existence should be defined... consistency: ? Accuracy: Bing imageries in urban areas are pretty good and easy to correct, if necessary, using available GPS tracks. It is not the case outside these areas. I suspect that Bing imageries are not always corrected using a good digital elevation model. It means that in hilly areas, the image shows an object somewhere on the ground while the object is actually somewhere else, due to Z distortion. Existence: Again, outside urban areas, the resolution of Bing imageries doesn't allow for detailed validation. You won't be able to see small objects, even if they are there! Best regards, Daniel -Original Message- From: Steve Singer [mailto:st...@ssinger.info] Sent: April 25, 2012 07:12 To: Paul Norman Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canadian imports: good or bad? On Wed, 25 Apr 2012, Paul Norman wrote: 2. There is not a consensus among the community that CanVec data can be imported without verifying the data for internal consistency and where possible against imagery. If no one disagrees with the fact there is not a consensus that importing CanVec without minimal verification is acceptable I'll go ahead and document on the Wiki, using Andrew Allison's examples. +1. Is there enough support to use the positive rather than the negative language, ie 'There is consensus among the community that Canvec data should only be imported when the data elements have been verified for internal consistency/accuracy/existence with the available imagery' Steve ___ Talk-ca mailing list Talk-ca
[Talk-ca] Oddities and sort of things in Canvec
Paul, About duplicated waterbody coastline ways east of Westham Island: It is the result of a complex case, where a combination of 3 waterbody types (Channel, River, Ocean) and 3 water permanency types (Permanent, Intermittent, Unknown) are touching each other around a coastal Island. That is a natural oddity !-) I haven't foreseen such a combination in transforming the Canvec waterbody definition into something that matches Osm definition. The process has been changed and the data will be corrected soon. About missing Delta-Richmond border: Boundaries are published when available. They are usually provided by the Provinces. As there is no agreement yet, with the BC government, there is no Delta-Richmond border to search for. About the missing metadata.txt file: On Friday, 2012-04-20 17:37 I wrote: I will soon include metadata generation in the conversion process. Soon did not mean that soon !-) I will probably provide them in the following weeks, while reprocessing the files to eliminate waterbody coastline potentially duplicated ways, like the case you just raised. Daniel -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: April 25, 2012 05:23 To: Bégin, Daniel Subject: Oddities in 092G03 I was looking at 092G03.3.1.osm and found a couple of oddities The first is that there is no way for the Delta-Richmond border. This approximately runs down the South arm of the Fraser. The second is that for the largish island just SE of the middle the east coast of it has both a natural=coastline and a natural=water way. The choice between what is part of the ocean and marked by coastline vs. what is part of the river and marked by a closed way or multipolygon is fairly arbitrary but it's duplicated here. Also, was there supposed to be a text file indicating the age of the features in the zip file? I didn't find one Paul ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canadian imports: good or bad?
Haaa! It makes sense... Originally, hydrography and vegetation were fitting together. Now that we are gradually replacing the older hydrography with newer data from provinces, we find vegetation in water. It will be corrected when we will replace the vegetation with a new one extracted from satellite images 5 years ago. The same thing can happen between hydrography and road network. Thank for the clarification Daniel -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: April 25, 2012 16:13 To: Bégin, Daniel; 'Steve Singer' Cc: talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Canadian imports: good or bad? From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] Subject: RE: [Talk-ca] Canadian imports: good or bad? Steve, Paul, I was on the impression that the consensus was more about using Canvec where it is the best available source and, when it is not, the data could be imported, but only after an exhaustive verification using available data/imagery. Whatever is the consensus, it should be documented in the wiki. Furthermore, I think that internal consistency/accuracy/existence should be defined... consistency: ? CanVec sometimes contradicts itself, for example it has trees in the water frequently. The coastline example I sent to you earlier would also be another example of where the data doesn't make sense. There are a few others that I've encountered. Typically what happens is one data source is significantly older than the other so CanVec says the land is being used for two contradictory uses at the same time. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canadian imports: good or bad?
Bonjour James, Really interesting suggestion! Actually, it is a natural step in data consideration : - First, you need data; - Then, you need information about the data! So, I will soon include metadata generation in the conversion process. A Metadata.txt file will be added to each .zip file. This file will contain the following information about .osm files content. - DateRange: Years range at which the data was captured/validated - CMAS: Circular Map Accuracy Standard Value in meters (Circular Accuracy at 90%) - TagValue: Corresponding Osm feature tag The content of the Metadata.txt file will look like this... DateRange CMAS TagValue - 2006-2011 03 highway=unclassified 2005-2011 03 highway=track 2005-2011 03 highway=secondary ... 1974-1974 25 tourism=attraction 1974-1974 25 railway=station 1974-1974 25 railway=rail 1974-1974 25 power=line 1974-1974 25 natural=wood 1974-1974 25 natural=wetland 1974-1974 25 natural=water ... 1974-1974 -1 natural=beach 1974-1974 -1 natural=bay 1974-1974 -1 leisure=nature_reserve Note: -1 stands for unknown values I'm completing tests and I'll add it to the conversion process. Regards, Daniel -Original Message- From: James A. Treacy [mailto:tre...@debian.org] Sent: April 17, 2012 15:26 To: Bégin, Daniel Cc: Paul Norman; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canadian imports: good or bad? Daniel, As always, your work is really appreciated. Would it be possible, for at least some of the data, to have the age of the data included in the releases? While age by itself is not necessarily indicitave of the quality of the data, it is a factor that could help users when deciding to use it or not. For example, if I saw a road that was surveyed and built within the last 5 years I'd tend to put some trust in its location. If the data was 25 years old, not so much. On Tue, Apr 17, 2012 at 05:34:30PM +, Bégin, Daniel wrote: Bonjour Paul, and all osmers Let me summarize the situation regarding NRCan-Canvec data. Good news... - about a thousand files (maps) are brand new around Ellesmere Island - Road network is updated every year for most of the provinces Old stories... - YK,NT,NU were checked for changes about 10 years ago using 20m resolution imageries. Some areas were updated using this imagery. - We are replacing some of our hydrographic network with provincial data (BC was the first replaced). It is usually more than 10 years old , our is older than 25. Much older stories... Actually, the rest of the NRCan-Canvec content is older than 25 years (average 30, older 64). It concerns southern Canada... - Buildings, railroads and other structures (obviously) - Vegetation (wooded areas) - could soon be replaced with a 5 year old automated classification using 30m imagery - Wetlands - Built-up areas You should not be surprise that some features are not up-to-date... I know that I've already done this exercise before but it is important that the community is aware of the limitation of the data. This is the same for all NRCan digital product (Canvec, Toporama, ...) and worst for paper maps :-( As mentioned in another email, the main objective of providing the Canvec.osm product was to help the community to focus on updating available data instead of recapturing everything from scratch. And from there, eventually use it to update our products. Since then, as a lot of Canvec data was imported, and updated ... - we now use OSM data for changes detection (it help us planning GPS field campaign for road updating in some provinces) - we are looking at using OSM data to help us updating the entire Canvec Product! It looks like a win-win situation for me! Best regards, Daniel Note: If anybody think this information should be added to the Canvec wiki page, you can use the above information -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: April 17, 2012 05:00 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canadian imports: good or bad? From: Ian Bruseker [mailto:ian.bruse...@gmail.com] Sent: Sunday, April 15, 2012 9:31 PM To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canadian imports: good or bad? On 2012-04-15, at 6:37 PM, Steve Singer st...@ssinger.info wrote: I also feel that not of all data sources are equal. Even within Canvec some layers are excellent (ie roads and lakes in most of the country) while others are often so out of date it isn't worth the time to import (ie buildings in much of Southern Ontario) That's the third mention in a row of bad building data in Canvec. I'll chime in on that to say I found a hospital in St. Albert, Alberta that was marked as having come from an import. The hospital hasn't been there for 20 years. The new building is several kilometers away. Not just bad, full on dangerous if someone
Re: [Talk-ca] Canadian imports: good or bad?
Bonjour Paul, and all osmers Let me summarize the situation regarding NRCan-Canvec data. Good news... - about a thousand files (maps) are brand new around Ellesmere Island - Road network is updated every year for most of the provinces Old stories... - YK,NT,NU were checked for changes about 10 years ago using 20m resolution imageries. Some areas were updated using this imagery. - We are replacing some of our hydrographic network with provincial data (BC was the first replaced). It is usually more than 10 years old , our is older than 25. Much older stories... Actually, the rest of the NRCan-Canvec content is older than 25 years (average 30, older 64). It concerns southern Canada... - Buildings, railroads and other structures (obviously) - Vegetation (wooded areas) - could soon be replaced with a 5 year old automated classification using 30m imagery - Wetlands - Built-up areas You should not be surprise that some features are not up-to-date... I know that I've already done this exercise before but it is important that the community is aware of the limitation of the data. This is the same for all NRCan digital product (Canvec, Toporama, ...) and worst for paper maps :-( As mentioned in another email, the main objective of providing the Canvec.osm product was to help the community to focus on updating available data instead of recapturing everything from scratch. And from there, eventually use it to update our products. Since then, as a lot of Canvec data was imported, and updated ... - we now use OSM data for changes detection (it help us planning GPS field campaign for road updating in some provinces) - we are looking at using OSM data to help us updating the entire Canvec Product! It looks like a win-win situation for me! Best regards, Daniel Note: If anybody think this information should be added to the Canvec wiki page, you can use the above information -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: April 17, 2012 05:00 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canadian imports: good or bad? From: Ian Bruseker [mailto:ian.bruse...@gmail.com] Sent: Sunday, April 15, 2012 9:31 PM To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canadian imports: good or bad? On 2012-04-15, at 6:37 PM, Steve Singer st...@ssinger.info wrote: I also feel that not of all data sources are equal. Even within Canvec some layers are excellent (ie roads and lakes in most of the country) while others are often so out of date it isn't worth the time to import (ie buildings in much of Southern Ontario) That's the third mention in a row of bad building data in Canvec. I'll chime in on that to say I found a hospital in St. Albert, Alberta that was marked as having come from an import. The hospital hasn't been there for 20 years. The new building is several kilometers away. Not just bad, full on dangerous if someone actually believed the data in OSM and tried to find help when they were hurt. :-( I thought it was just BC but it sounds like it's everywhere. Would I be correct in summarizing the opinions so far as 1. The buildings data from CanVec should not be imported unless it can be verified against imagery, in which case you might as well trace the buildings from imagery. 2. There is not a consensus among the community that CanVec data can be imported without verifying the data for internal consistency and where possible against imagery. ___ 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] canvec and other external sources
Bonjour Richard, I've modified my scripts to produce .osm files having the appropriate xml tag... osm version='0.6' upload='false'. I'll introduce it in the Canvec.osm conversion process later today. Eventually, all of Canvec.osm files - Release 10 and later - will be processed that way. Thanks to Paul Best regards, Daniel -Original Message- From: Richard Weait [mailto:rich...@weait.com] Sent: April 9, 2012 09:20 To: Talk-CA OpenStreetMap Subject: [Talk-ca] canvec and other external sources Dear all, Paul Norman pointed this out to me. If canvec, or other external source data is created as an osm file, with osm version='0.6' upload='false' instead of the ordinary osm version=0.6 that will protect a mapper who uses that data from a class of embarrassing accidents. When using a canvec file for reference, a mapper might have several file layers open in JOSM. Pressing upload with the wrong layer selected may upload data that was not intended or that duplicates existing data. upload=false gives the mapper another chance to catch their error. A dialogue box is presented before uploading a layer based on a file with upload=false. To be clear, the data can still be uploaded. Another warning is offered before the upload so that the mapper can double-check the action. Do we agree that this would be an improvement to the CanVec data? Daniel, would you consider making this change for future CanVec product? 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] Canvec.osm Product - Running!
Bonjour OSMers! Canvec.osm product conversion is running since 08:30 - Sherbrooke time. It is based on Canvec Release 10. All files will be reprocessed. From south to north, east to west, except for a few priorities. What is new: * There is no more Here be Dragons areas in the Canvec product! NRCan completed mapping Canada at 50K scale about 2 months ago. Almost 100 years after Canada started mapping at this scale (approximately!-) * Municipal Boundaries for SK,MB,NB,YT,NT and NU - linear - are available Changes from previous release: * Water definition (natural=water) now fits the Osm coastline definition (high water level). * Format of the ZippedOsm.txt in ftp site has changed. http://wiki.openstreetmap.org/wiki/CanVec#CanVec_10http://wiki.openstreetmap.org/wiki/CanVec Thanks to those who are maintaining this wiki page :-) Let me know if you find unexpected problems in the data. Cheers, Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Administrative Boundary
Bonjour, I'm working on the Canvec.osm - release 10 - conversion process and I'd like to double check an answer I got from Paul concerning administrative boundaries. Release 10 will contain up to three administrative boundary types where available ... - Regional - Upper Municipality - Municipality The Osm admin_level tag usually correspond to the gdf_level ISO standard . In GeoBase product, the value of these boundaries were identified as gdf_level 6,7 and 8 respectively. In Openstreetmap wiki, the admin_level were set to 5,6 and 8 respectively. Is the difference between both are caused by a problem with the wiki or a consensus on the community? If it is a documented consensus, I'll keep the values of the wiki. If not, I'll use the the values from GeoBase. Comments? Daniel From: Paul Norman [mailto:penor...@mac.com] Sent: February 14, 2012 15:09 To: Bégin, Daniel; talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Administrative Boundary The levels in your initial email Available administrative boundary will be included in the next release of Canvec.osm. From the wiki, here is the tagging values I'm going to use... Municipal Regional: boundary=administrative; admin_level=5 Upper municipality: boundary=administrative; admin_level=6 Municipality:boundary=administrative; admin_level=8 From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] Sent: Tuesday, February 14, 2012 12:07 PM To: Paul Norman; talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Administrative Boundary Hi Paul, are you saying that I should use ... ISO value for admin_level (6 7 - actually what is used in the GeoBase product), or what is identified in the wiki (5 6) http://wiki.openstreetmap.org/wiki/Admin_level Question mark! Daniel From: Paul Norman [mailto:penor...@mac.com]mailto:[mailto:penor...@mac.com] Sent: February 14, 2012 14:57 To: Bégin, Daniel; talk-ca@openstreetmap.orgmailto:talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Administrative Boundary From the wiki, those look consistent with what I've seen locally, although naturally I can't comment about Quebec. From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca]mailto:[mailto:daniel.be...@rncan-nrcan.gc.ca] Sent: Monday, February 13, 2012 5:54 AM To: Paul Norman; talk-ca@openstreetmap.orgmailto:talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Administrative Boundary Bonjour Norman, ISO Level 7 (Upper municipality) refers to an administrative area like the County of Peterborough (ON), while the ISO Level 6 (Municipal Regional) refers to an administrative area like Eastern Townships in Québec (a group of county - a level that exist only in Québec) Regards, Daniel From: Paul Norman [mailto:penor...@mac.com]mailto:[mailto:penor...@mac.com] Sent: February 9, 2012 17:15 To: Bégin, Daniel; talk-ca@openstreetmap.orgmailto:talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Administrative Boundary Can you give an example of a municipal regional or upper municipality? Looking at the global usage, admin_level=5 is seldom used. I would think that Municipal Regional would be 6 and upper municipality would be 7, but I can't really say without examples. I would also suggest that these features in the .osm file not be closed - just have the boundary, don't handle it like lakes where you have multiple areas you need to join where they cross tile bounds. From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca]mailto:[mailto:daniel.be...@rncan-nrcan.gc.ca] Sent: Thursday, February 09, 2012 1:39 PM To: talk-ca@openstreetmap.orgmailto:talk-ca@openstreetmap.org Subject: [Talk-ca] Administrative Boundary Bonjour again! Available administrative boundary will be included in the next release of Canvec.osm. From the wiki, here is the tagging values I'm going to use... Municipal Regional: boundary=administrative; admin_level=5 Upper municipality: boundary=administrative; admin_level=6 Municipality:boundary=administrative; admin_level=8 http://wiki.openstreetmap.org/wiki/Admin_level (Canada) Municipality admin_level=8 corresponds to gdf order in ISO standard. Municipal Regional Area and Upper Municipality (admin_level=5 and 6) are different from what the ISO standard says (gdf order=6 and 7). Is someone can confirm that admin_level=5 and 6 is really what is expected? Thanks again Daniel Bégin Centre d'information topographique de Sherbrooke Topographic Information Center of Sherbrooke Ressources Naturelles Canada / Natural Ressources Canada 2144, rue King Ouest, bureau 010 Sherbrooke (Québec) J1J 2E8 (819) 564-5600 ext.242, dbe...@nrcan.gc.camailto:dbe...@nrcan.gc.ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Bug in canvec street names
Bonjour Paul, As the data is provided by provinces/territories (GeoBase NRN), names, over-noding, and other problems have to be resolved there first. However, for simple correction (double spaces in names) I have taken the initiative to correct them automatically. For the rest, like over-noding, I do not have the time to setup filtering and make sure the result is appropriate for the entire country :-( I'll send this information to the NRN team. Thanks Daniel -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: March 11, 2012 20:46 To: Bégin, Daniel Cc: talk-ca@openstreetmap.org Subject: Bug in canvec street names In 092G03.2.2.1.osm I noticed streets named East 51st Avenue with two spaces between East and 51st. Additionally most of the lanes are tagged highway=service lanes=1 surface=unpaved but are paved, and should also have service=alley. They're also over-noded. This may be an issue with the underlying NRN data. I've been fixing the NRN alleyways as I do license cleanup. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Intro and a question
Bonjour Steve and Bernie, Agreed with Bernie, I'll go a bit deeper in what has already been said... NRCan highway=(vehicle) were obtained using GPS (better than 5 meters 90%) NRCan highway=footway have been obtained from aerial photography (30 meters 90%) and are usually more that 30 years old. Standard GPS device will usually give an accuracy better than 10 meter 90% in good conditions (no obstacles - mountains, buildings, trees) It would not be unusual to get a GPS track off by quite a few meters in forest/mountain area. Imagery can also be affected by distortion in such areas - if no appropriate corrections were done. However, if you have many GPS tracks that seem glued together, take yours !-) Best regards, Daniel -Original Message- From: Connors, Bernie (SNB) [mailto:bernie.conn...@snb.ca] Sent: March 1, 2012 14:04 To: 'Steve Roy'; Talk-CA OpenStreetMap Subject: Re: [Talk-ca] Intro and a question Steve, I have had a look at your GPS trace and the OSM data in the Lac Le Jeune area with the Potlatch 2 editor. It appears to me that your GPS trace matches quite well with the Bing imagery in the area. Since you are familiar with the area you could accomplish more by simply digitizing from the Bing imagery and supplementing with GPS traces when necessary. I would trust your GPS trace to be more accurate than the CanVec data in the area. It is really up to you to decide if you want to reposition existing data or delete it and digitize new features. I find that sometimes the CanVec data has many nodes and it is time consuming to reposition each node. The CanVec data is using the tag highway = footway where it appears that it is suitable for vehicles. I suggest highway = track is more appropriate. It looks like another user has already digitized some highway = track in this area and created some duplicate ways such as this one: http://www.openstreetmap.org/user/SRW/traces/1187039 With your local knowledge it should be easy to identify these duplicate ways and remove the less accurate data. Bernie. -- Bernie Connors New Maryland, NB bernie.conn...@unb.ca -Original Message- From: Steve Roy [mailto:st...@ssni.ca] Sent: Thursday, 2012-03-01 14:14 To: Talk-CA OpenStreetMap Subject: [Talk-ca] Intro and a question Hi I thought I'd introduce myself and also ask a couple of questions. I live in New Westminster BC and spend a lot of time in the Lac Le Jeune area as we have a family cabin there. I want to start adding data in the Lac Le Jeune area that I collect with my GPS when out hiking, biking, 4x4ing, sledding etc. There are numerous trails and roads in the area that aren't on OSM. I have managed to add a couple of forestry roads so far but want to know the best way to combine my edits with current roads and tracks on the map.There are parts of existing roads and tracks shown on the map and they are from NRCan-CanVec-7.0.Some match with my GPS track, others are off by quite a few meters. Should I: -Leave the existing NRCandata as is and add my data (i.e. my track lays over the NRCan track) -Combine the two and move the nodes of the NRCan? -Or leave the existing NRCan track as-is and join bits of my track to nodes on the NRCan data? This is the area where I want to add tracks and trails: http://www.openstreetmap.org/?lat=50.4798lon=-120.4541zoom=14layers=M http://www.openstreetmap.org/?lat=50.4798lon=-120.4541zoom=14layers=M This is a GPS trace I have uploaded: www.openstreetmap.org/user/SRW/traces/1187039 http://www.openstreetmap.org/user/SRW/traces/1187039 Thanks Steve -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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] Aboriginal Lands
Bonjour All, Paul propose not to include aboriginal lands in the next Canvec.osm release. I would like to have more feedback from the community before excluding it :-) Regards, Daniel -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: February 13, 2012 18:55 To: Bégin, Daniel Cc: talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Aboriginal Lands Then I don't think they should be included in canvec.osm -Original Message- From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] Sent: Monday, February 13, 2012 6:04 AM To: Paul Norman Cc: talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Aboriginal Lands Bonjour again Paul, An example is not yet available but yes, it will form closed area split like large lake. That is a limitation of the Canvec.osm product for the moment :-( Daniel -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: February 13, 2012 05:35 To: Bégin, Daniel; 'Tyler Gunn'; talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Aboriginal Lands Does this mean that they would form closed areas split like large lakes are? If so, this makes them unsuitable for importing into OSM without significant work. Can we see an example area so that we know what you are proposing? -Original Message- From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] Sent: Thursday, February 09, 2012 1:54 PM To: Tyler Gunn; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Aboriginal Lands Bonjour Tyler, Aboriginal Lands are already available in shape and gml format on GeoBase website. It provides a dataset for the entire country. The Canvec product is produced on 50K map sheet coverage. The Aboriginal Lands, if provided through Canvec.osm product, will complied to the 50K map sheet coverage. Best regards, Daniel -Original Message- From: Tyler Gunn [mailto:ty...@egunn.com] Sent: February 9, 2012 16:38 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Aboriginal Lands It is possible to include Aboriginal Lands in the next release of Canvec.osm. However, I'm trying to find a consensus in the community concerning the tags/values to use? I've found some links to... - boundary=administrative; admin_level =aboriginal_land - boundary=administrative; admin_level =2 to 4 - boundary=protected_area; protect_class=24 I'm curious how this information would be represented given the distribution of CanVec data in a tiled format? Given that administrative boundaries tend to span larger areas, I don't know if it would make sense to split these at tile boundaries. Were you thinking to provide these boundaries in a separate file of sorts? How these boundaries are represented should perhaps be driven from where they fit into the overall picture in terms of how Canada is split up? When I think of things like the country, provinces, territories, cities/towns/etc, these all fit nicely into the boundary=administrative and admin_level hierarchy. We have separate boundary types for provincial parks, national parks, etc, and I'd probably interpret the aboriginal lands the same way. So I think its entirely reasonable to represent these as: boundary=aboriginal_land Tyler ___ 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] Administrative Boundary
Hi Paul, are you saying that I should use ... ISO value for admin_level (6 7 - actually what is used in the GeoBase product), or what is identified in the wiki (5 6) http://wiki.openstreetmap.org/wiki/Admin_level http://wiki.openstreetmap.org/wiki/Admin_level Question mark! Daniel From: Paul Norman [mailto:penor...@mac.com] Sent: February 14, 2012 14:57 To: Bégin, Daniel; talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Administrative Boundary From the wiki, those look consistent with what I've seen locally, although naturally I can't comment about Quebec. From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] Sent: Monday, February 13, 2012 5:54 AM To: Paul Norman; talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Administrative Boundary Bonjour Norman, ISO Level 7 (Upper municipality) refers to an administrative area like the County of Peterborough (ON), while the ISO Level 6 (Municipal Regional) refers to an administrative area like Eastern Townships in Québec (a group of county - a level that exist only in Québec) Regards, Daniel From: Paul Norman [mailto:penor...@mac.com] Sent: February 9, 2012 17:15 To: Bégin, Daniel; talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Administrative Boundary Can you give an example of a municipal regional or upper municipality? Looking at the global usage, admin_level=5 is seldom used. I would think that Municipal Regional would be 6 and upper municipality would be 7, but I can't really say without examples. I would also suggest that these features in the .osm file not be closed - just have the boundary, don't handle it like lakes where you have multiple areas you need to join where they cross tile bounds. From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] Sent: Thursday, February 09, 2012 1:39 PM To: talk-ca@openstreetmap.org Subject: [Talk-ca] Administrative Boundary Bonjour again! Available administrative boundary will be included in the next release of Canvec.osm. From the wiki, here is the tagging values I'm going to use... Municipal Regional: boundary=administrative; admin_level=5 Upper municipality: boundary=administrative; admin_level=6 Municipality:boundary=administrative; admin_level=8 http://wiki.openstreetmap.org/wiki/Admin_level http://wiki.openstreetmap.org/wiki/Admin_level (Canada) Municipality admin_level=8 corresponds to gdf order in ISO standard. Municipal Regional Area and Upper Municipality (admin_level=5 and 6) are different from what the ISO standard says (gdf order=6 and 7). Is someone can confirm that admin_level=5 and 6 is really what is expected? Thanks again Daniel Bégin Centre d'information topographique de Sherbrooke Topographic Information Center of Sherbrooke Ressources Naturelles Canada / Natural Ressources Canada 2144, rue King Ouest, bureau 010 Sherbrooke (Québec) J1J 2E8 (819) 564-5600 ext.242, dbe...@nrcan.gc.ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Aboriginal Lands
Paul, I understand that the aboriginal lands (if included), and administrative boundary, should be presented as ways, not multipolygons. It is on my duty list! Daniel -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: February 14, 2012 15:24 To: 'Connors, Bernie (SNB)'; Bégin, Daniel; talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Aboriginal Lands I'm not so concerned with the aboriginal lands as with municipal boundaries. Aboriginal lands are unlikely to span multiple sub-tiles unless they lie on an edge, but cities often cover several sub-tiles. Is converting the boundaries from polygons to linestrings an option? -Original Message- From: Connors, Bernie (SNB) [mailto:bernie.conn...@snb.ca] Sent: Tuesday, February 14, 2012 5:56 AM To: 'Bégin, Daniel'; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Aboriginal Lands If the Aboriginal lands are easily available from another source (GeoBase) and including them in Canvec.osm is going to make the data more complex I think the aboriginal lands should be excluded from Canvec.osm. -- Bernie Connors, P.Eng Service New Brunswick (506) 444-2077 45°56'25.21N, 66°38'53.65W www.snb.ca/geonb/ -Original Message- From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] Sent: Tuesday, 2012-02-14 09:05 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Aboriginal Lands Bonjour All, Paul propose not to include aboriginal lands in the next Canvec.osm release. I would like to have more feedback from the community before excluding it :-) Regards, Daniel -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: February 13, 2012 18:55 To: Bégin, Daniel Cc: talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Aboriginal Lands Then I don't think they should be included in canvec.osm -Original Message- From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] Sent: Monday, February 13, 2012 6:04 AM To: Paul Norman Cc: talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Aboriginal Lands Bonjour again Paul, An example is not yet available but yes, it will form closed area split like large lake. That is a limitation of the Canvec.osm product for the moment :-( Daniel -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: February 13, 2012 05:35 To: Bégin, Daniel; 'Tyler Gunn'; talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Aboriginal Lands Does this mean that they would form closed areas split like large lakes are? If so, this makes them unsuitable for importing into OSM without significant work. Can we see an example area so that we know what you are proposing? -Original Message- From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] Sent: Thursday, February 09, 2012 1:54 PM To: Tyler Gunn; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Aboriginal Lands Bonjour Tyler, Aboriginal Lands are already available in shape and gml format on GeoBase website. It provides a dataset for the entire country. The Canvec product is produced on 50K map sheet coverage. The Aboriginal Lands, if provided through Canvec.osm product, will complied to the 50K map sheet coverage. Best regards, Daniel -Original Message- From: Tyler Gunn [mailto:ty...@egunn.com] Sent: February 9, 2012 16:38 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Aboriginal Lands It is possible to include Aboriginal Lands in the next release of Canvec.osm. However, I'm trying to find a consensus in the community concerning the tags/values to use? I've found some links to... - boundary=administrative; admin_level =aboriginal_land - boundary=administrative; admin_level =2 to 4 - boundary=protected_area; protect_class=24 I'm curious how this information would be represented given the distribution of CanVec data in a tiled format? Given that administrative boundaries tend to span larger areas, I don't know if it would make sense to split these at tile boundaries. Were you thinking to provide these boundaries in a separate file of sorts? How these boundaries are represented should perhaps be driven from where they fit into the overall picture in terms of how Canada is split up? When I think of things like the country, provinces, territories, cities/towns/etc, these all fit nicely into the boundary=administrative and admin_level hierarchy. We have separate boundary types for provincial parks, national parks, etc, and I'd probably interpret the aboriginal lands the same way. So I think its entirely reasonable to represent these as: boundary=aboriginal_land Tyler ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-ca] Administrative Boundary
Bonjour Norman, ISO Level 7 (Upper municipality) refers to an administrative area like the County of Peterborough (ON), while the ISO Level 6 (Municipal Regional) refers to an administrative area like Eastern Townships in Québec (a group of county - a level that exist only in Québec) Regards, Daniel From: Paul Norman [mailto:penor...@mac.com] Sent: February 9, 2012 17:15 To: Bégin, Daniel; talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Administrative Boundary Can you give an example of a municipal regional or upper municipality? Looking at the global usage, admin_level=5 is seldom used. I would think that Municipal Regional would be 6 and upper municipality would be 7, but I can't really say without examples. I would also suggest that these features in the .osm file not be closed - just have the boundary, don't handle it like lakes where you have multiple areas you need to join where they cross tile bounds. From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] Sent: Thursday, February 09, 2012 1:39 PM To: talk-ca@openstreetmap.org Subject: [Talk-ca] Administrative Boundary Bonjour again! Available administrative boundary will be included in the next release of Canvec.osm. From the wiki, here is the tagging values I'm going to use... Municipal Regional: boundary=administrative; admin_level=5 Upper municipality: boundary=administrative; admin_level=6 Municipality:boundary=administrative; admin_level=8 http://wiki.openstreetmap.org/wiki/Admin_level http://wiki.openstreetmap.org/wiki/Admin_level (Canada) Municipality admin_level=8 corresponds to gdf order in ISO standard. Municipal Regional Area and Upper Municipality (admin_level=5 and 6) are different from what the ISO standard says (gdf order=6 and 7). Is someone can confirm that admin_level=5 and 6 is really what is expected? Thanks again Daniel Bégin Centre d'information topographique de Sherbrooke Topographic Information Center of Sherbrooke Ressources Naturelles Canada / Natural Ressources Canada 2144, rue King Ouest, bureau 010 Sherbrooke (Québec) J1J 2E8 (819) 564-5600 ext.242, dbe...@nrcan.gc.ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] British Columbia Coastlines
Amazing task! And I understand that we should eventually have a look in Greater Vancouver, Victoria, Nanaimo and Sidney area for better data. Cheers, Daniel -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: February 13, 2012 03:00 To: talk-ca@openstreetmap.org Subject: [Talk-ca] British Columbia Coastlines For the last couple of weeks I have been replacing the portions of the BC coastline which were PGS or CT-dirty imports with the latest CanVec/GeoBase data. I elected to use GeoBase since it's coastlines require less manual processing to get into workable form. This process is now finished, with the exception of the basins that are in the US and have data in GeoBase and the 08OA000 and 08OB000 basins (Haida Gwaii) which are in progress. Before replacing any coast, I compared it with the GeoBase data for accuracy. For most of BC's 25000 km of coastline the data was PGS data and easily replaced. The only places where there was substantial coastline retained were in Greater Vancouver, Victoria, Nanaimo and Sidney. The quality of the OSM coastline data exceeds that of GeoBase/CanVec in these areas. All the data was run through JOSM's simplify function with a max-error of 1.5m. On later runs, short ways were combined into larger ones after simplification. The search expression (parent child selected | parent selected) nodes:-1000 was used in doing this. In the process I identified many unmapped rivers where I needed to join two sections of coastline together. Where bing imagery showed a river, I added a brief tracing. Most of the bing imagery was low-resolution Landsat or higher-resolution imagery from the BC government, the same as is found on their openmaps WMS server. In the process, I ran JOSM's validator tool over most of the coastline and fixed other unrelated errors. Statistics: The .osm files were 232 MB on disk before simplification The total number of objects uploaded is approximately 1.5 million Surprisingly, no errors were found by coastcheck in the coastline, indicating my procedures worked There are 47 NHN basins with coastline, varying in complexity and size from 5k nodes before simplification to 150k nodes before simplification ___ 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] Aboriginal Lands
Bonjour again Paul, An example is not yet available but yes, it will form closed area split like large lake. That is a limitation of the Canvec.osm product for the moment :-( Daniel -Original Message- From: Paul Norman [mailto:penor...@mac.com] Sent: February 13, 2012 05:35 To: Bégin, Daniel; 'Tyler Gunn'; talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Aboriginal Lands Does this mean that they would form closed areas split like large lakes are? If so, this makes them unsuitable for importing into OSM without significant work. Can we see an example area so that we know what you are proposing? -Original Message- From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] Sent: Thursday, February 09, 2012 1:54 PM To: Tyler Gunn; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Aboriginal Lands Bonjour Tyler, Aboriginal Lands are already available in shape and gml format on GeoBase website. It provides a dataset for the entire country. The Canvec product is produced on 50K map sheet coverage. The Aboriginal Lands, if provided through Canvec.osm product, will complied to the 50K map sheet coverage. Best regards, Daniel -Original Message- From: Tyler Gunn [mailto:ty...@egunn.com] Sent: February 9, 2012 16:38 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Aboriginal Lands It is possible to include Aboriginal Lands in the next release of Canvec.osm. However, I'm trying to find a consensus in the community concerning the tags/values to use? I've found some links to... - boundary=administrative; admin_level =aboriginal_land - boundary=administrative; admin_level =2 to 4 - boundary=protected_area; protect_class=24 I'm curious how this information would be represented given the distribution of CanVec data in a tiled format? Given that administrative boundaries tend to span larger areas, I don't know if it would make sense to split these at tile boundaries. Were you thinking to provide these boundaries in a separate file of sorts? How these boundaries are represented should perhaps be driven from where they fit into the overall picture in terms of how Canada is split up? When I think of things like the country, provinces, territories, cities/towns/etc, these all fit nicely into the boundary=administrative and admin_level hierarchy. We have separate boundary types for provincial parks, national parks, etc, and I'd probably interpret the aboriginal lands the same way. So I think its entirely reasonable to represent these as: boundary=aboriginal_land Tyler ___ 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] Aboriginal Lands
Bonjour! It is possible to include Aboriginal Lands in the next release of Canvec.osm. However, I'm trying to find a consensus in the community concerning the tags/values to use? I've found some links to... - boundary=administrative; admin_level =aboriginal_land - boundary=administrative; admin_level =2 to 4 - boundary=protected_area; protect_class=24 Waiting for comments Thanks Daniel Bégin Centre d'information topographique de Sherbrooke Topographic Information Center of Sherbrooke Ressources Naturelles Canada / Natural Ressources Canada 2144, rue King Ouest, bureau 010 Sherbrooke (Québec) J1J 2E8 (819) 564-5600 ext.242, dbe...@nrcan.gc.ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Administrative Boundary
Bonjour again! Available administrative boundary will be included in the next release of Canvec.osm. From the wiki, here is the tagging values I'm going to use... Municipal Regional: boundary=administrative; admin_level=5 Upper municipality: boundary=administrative; admin_level=6 Municipality:boundary=administrative; admin_level=8 http://wiki.openstreetmap.org/wiki/Admin_level (Canada) Municipality admin_level=8 corresponds to gdf order in ISO standard. Municipal Regional Area and Upper Municipality (admin_level=5 and 6) are different from what the ISO standard says (gdf order=6 and 7). Is someone can confirm that admin_level=5 and 6 is really what is expected? Thanks again Daniel Bégin Centre d'information topographique de Sherbrooke Topographic Information Center of Sherbrooke Ressources Naturelles Canada / Natural Ressources Canada 2144, rue King Ouest, bureau 010 Sherbrooke (Québec) J1J 2E8 (819) 564-5600 ext.242, dbe...@nrcan.gc.ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Aboriginal Lands
Bonjour Tyler, Aboriginal Lands are already available in shape and gml format on GeoBase website. It provides a dataset for the entire country. The Canvec product is produced on 50K map sheet coverage. The Aboriginal Lands, if provided through Canvec.osm product, will complied to the 50K map sheet coverage. Best regards, Daniel -Original Message- From: Tyler Gunn [mailto:ty...@egunn.com] Sent: February 9, 2012 16:38 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Aboriginal Lands It is possible to include Aboriginal Lands in the next release of Canvec.osm. However, I'm trying to find a consensus in the community concerning the tags/values to use? I've found some links to... - boundary=administrative; admin_level =aboriginal_land - boundary=administrative; admin_level =2 to 4 - boundary=protected_area; protect_class=24 I'm curious how this information would be represented given the distribution of CanVec data in a tiled format? Given that administrative boundaries tend to span larger areas, I don't know if it would make sense to split these at tile boundaries. Were you thinking to provide these boundaries in a separate file of sorts? How these boundaries are represented should perhaps be driven from where they fit into the overall picture in terms of how Canada is split up? When I think of things like the country, provinces, territories, cities/towns/etc, these all fit nicely into the boundary=administrative and admin_level hierarchy. We have separate boundary types for provincial parks, national parks, etc, and I'd probably interpret the aboriginal lands the same way. So I think its entirely reasonable to represent these as: boundary=aboriginal_land Tyler ___ 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] canvec data offset
Bonjour, I'll have a look to see if I can do something for it in the next release. I suspect that might be caused by data resolution. Lat and Lon are stored in decimal degrees with 7 digits precision (48.1234567). The 7th digit will provide a precision around 0.001 meter. The 6th digit a precision around 0.027 meter witch look like your 0.03 meter. Cheers Daniel -Original Message- From: michael bishop [mailto:cle...@nbnet.nb.ca] Sent: January 30, 2012 16:11 To: Talk-CA OpenStreetMap Subject: [Talk-ca] canvec data offset ive been working with canvec for a few days now, and ive noticed some of the data is offset by 0.03 meters its not matching up with nearby tiles for example 021O10 doesnt match up with 021O07 ive noticed the problem on other tiles aswell, but didnt think to write them down ___ 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] canvec data offset
Bonjour Frank, The problem is not related to a NAD27-NAD83 conversion. With Michael's example, I am now sure that the problem is related to the quadtree clipper. I must find a way to round quadtree's tiles coordinates to a proper value. Thanks to Michael Best regard, Daniel -Original Message- From: Frank Steggink [mailto:stegg...@steggink.org] Sent: January 31, 2012 11:56 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] canvec data offset I've seen some of these deviations as well during Canvec import. Because they are so small ( 1 meter), I just decided to glue the polygons together, so any slivers are gone. It is inconvenient though. Could it be related to that some sheets were originally still in NAD27, instead of NAD83 (which is approximately WGS84, as used by OSM)? Frank On 31-1-2012 15:06, michael bishop wrote: the south east corner of 021O10.0 is at 47.534 by -66.7500013 the north east corner of 021O07.1 (should be exact same node), is at 47.500 by -66.750 the exact offset differs from corner to corner, some are off more then others, some are off in a different direction On 01/31/2012 08:11 AM, Bégin, Daniel wrote: Bonjour, I'll have a look to see if I can do something for it in the next release. I suspect that might be caused by data resolution. Lat and Lon are stored in decimal degrees with 7 digits precision (48.1234567). The 7th digit will provide a precision around 0.001 meter. The 6th digit a precision around 0.027 meter witch look like your 0.03 meter. Cheers Daniel -Original Message- From: michael bishop [mailto:cle...@nbnet.nb.ca] Sent: January 30, 2012 16:11 To: Talk-CA OpenStreetMap Subject: [Talk-ca] canvec data offset ive been working with canvec for a few days now, and ive noticed some of the data is offset by 0.03 meters its not matching up with nearby tiles for example 021O10 doesnt match up with 021O07 ive noticed the problem on other tiles aswell, but didnt think to write them down ___ 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] StatCan Boundaries
Bonjour, About city boundaries, Canadian Geopolitical Boundaries are available under geobase web site... http://www.geobase.ca/geobase/en/data/admin/index.html Furthermore, we are working on integrating Geopolitical Boundaries information in Canvec.osm for the next release. Hope it helps, Daniel -Original Message- From: Gordon Dewis [mailto:gor...@pinetree.org] Sent: January 17, 2012 08:59 To: Olivier Hill; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] StatCan Boundaries Disclaimer: Speaking strictly for myself and not the government statistical agency I work for. Hi... I believe this came up a year or two ago and that the answer at the time was no. But, I will ask the licensing people at work and see what they say. Cheers! --G --Original Message-- From: Olivier Hill To: talk-ca@openstreetmap.org Subject: [Talk-ca] StatCan Boundaries Sent: Jan 17, 2012 08:53 Hello all, Nice meeting some of you in the Toronto Meetup yesterday. For those that remember, I asked a question about city boundaries and sources of data. Can the data from StatCan be used in OSM? I'm referring to this product for example: http://geodepot.statcan.gc.ca/2006/040120011618150421032019/02152114040118250609120519_05-eng.jsp Best, Olivier -- http://www.olivierhill.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] Tagging Rail POIs - Help please
Bonjour Sam, You're right! As we don't have the resources to update the entire map content, we might have to rely on you folks and use your work to update NRCan maps. Daniel -Original Message- From: Sam Dyck [mailto:samueld...@gmail.com] Sent: January 11, 2012 11:20 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Tagging Rail POIs - Help please Canvec has the same problem, stations that had service many years ago are still tagged as stations, even if they been replaced by new stations. Smith Falls, Ontario has three stations shown, one is the current VIA Rail station, one is a former station and the third is not even on a track. Sam Dyck ___ 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 complaints
Really good idea! Daniel -Original Message- From: Steve Singer [mailto:ssinger...@sympatico.ca] Sent: 4 décembre 2011 09:23 To: Connors, Bernie (SNB) Cc: Talk-CA OpenStreetMap Subject: Re: [Talk-ca] import complaints On Fri, 2 Dec 2011, Connors, Bernie (SNB) wrote: Richard, Do you have a link to Import Guidelines that are specific to Canvec data? I think http://wiki.openstreetmap.org/wiki/CanVec needs to have some specific guidelines for canvec imports. In particular 1. A caution to avoid importing coastlines or large lakes unless you have substantial experience importing canvec and understand how coastlines get generated/rendered in OSM. We have had enough problems/complaints with coastlines that I think we need a specific caution. 2. A warning to avoid duplicate features. (one might argue that this is obvious but the generic import guidelines don't actually mention this and clearly people are importing a lot of duplicate features) 3. To check keeprite (or something similar) after your import so you can find/fix some of the problems you will create. If no one objects I will update the above mentioned wiki page to reflect include those warnings. Steve Bernie. -- Bernie Connors, P.Eng Service New Brunswick (506) 444-2077 45°56'25.21N, 66°38'53.65W www.snb.ca/geonb/ -Original Message- From: Richard Weait [mailto:rich...@weait.com] Sent: Friday, 2011-12-02 13:23 To: Talk-CA OpenStreetMap Subject: [Talk-ca] import complaints dear all, I've heard some LOUD complaints about imports in Canada. Please be sure to follow the import guidelines, including special import accounts, and please be sure to check your work and fix errors. Latest issue appears to be a large broken water polygon. 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] FW: Open Data Hackfest - OpenStreetMap experts welcome
Hi folks, I'm forwarding an email that can be an interest for you! Daniel -Original Message- From: Richard Akerman [mailto:sci...@gmail.com] Sent: 24 novembre 2011 11:44 To: sail.not.s...@gmail.com; jwhelan0...@gmail.com; Bégin, Daniel Subject: Open Data Hackfest - OpenStreetMap experts welcome Hi, I wanted to reach out to the OpenStreetMap community, particularly those in Ottawa, to let you know that Open Data Ottawa is organising a hackfest, December 3, 1pm to 4pm at City Hall It's free to register, there's more information at http://blog.opendataottawa.ca/post/13145401469/the-hack-is-back-december-3rd-at-city-hall We'd love to have map and technology experts to help us improve OSM and learn how to use it in applications and websites. If there are other people or channels I should send this info to, please let me know. Thanks, -- Richard Akerman sci...@gmail.com http://scilib.typepad.com/ Twitter: @scilib ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Canvec.osm Product - Running!
Bonjour OSMers! Canvec.osm product conversion is running since 07:30 - Sherbrooke time. It is based on Canvec release 8.0. All files will be reprocessed. From south to north, east to west, except for a few priorities. What is new: * Updated road for BC,AB,SK,ON,NS,YK,NT * New files very far up north Changes from previous release: * Swapped amenity=school/prison tag values corrected * Misspelled tag value on highway=unclassified corrected. * Duplicated railway=rail features removed. * Single node natural=land within natural=water inner polygon created only if a name tag is attached to it. * Multiple consecutive spaces in name tag are removed. * name:fr/name:en applied on all features when available. * Surface orientation respects right-hand rule. * Missing large polygons should have been corrected (to confirm). http://wiki.openstreetmap.org/wiki/CanVec#CanVec_8 Thanks to those who are maintaining this wiki page :-) Let me know if you find unexpected problems in the data. I'll be out of the office for a week. I'll check/answer your emails when I'm back. Cheers, Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] NTS tile 040P
Bonjour James, When I clik on the link you provide I can see all expected 040PXX files (the directory is not empty). May be you are trying to access them through http? Have a look at http://geogratis.gc.ca/geogratis/en/faq.html#q4 We don't have the ressources to provide the community with something else for the moment. Regards, Daniel -Original Message- From: James A. Treacy [mailto:tre...@debian.org] Sent: June 7, 2011 16:06 To: talk-ca@openstreetmap.org Subject: [Talk-ca] NTS tile 040P Hello, I believe I am looking for a subtile of 040P but the directory ftp://ftp2.cits.rncan.gc.ca/osm/pub/040/P/ is empty. This brings up a related point: Is there a web page that makes it easy to find the tile you want? A mashup would be ideal. I took a quick look at the openstreetmap OpenLayers api and it has at least some of the capability needed. In fact, given a list of the centers of the tiles, we could use the example, http://wiki.openstreetmap.org/wiki/Openlayers_POI_layer_example with trivial modifications to display an icon on each one. Clicking on an icon would display the URL for the corresponding osm file. Here is what textfile.txt would look like: lat lon title description iconiconSizeiconOffset 48.9459301 9.6075669 040J03.3.osmTo get the .osm file for this tile go tobrftp://ftp2.cits.rncan.gc.ca/osm/pub/040/J/040J03.zip Ol_icon_blue_example.png24,24 0,-24 [the coordinates in the above are not correct] There are some issue, though, which I can go into if people like this idea. -- James (Jay) Treacy tre...@debian.org ___ 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] Railways duplicated in CanVec data
Bonjour Frank, Thank for the comments. I'll see what can be done. I have been assigned to some other projects. I'll try to keep in touch with the community (as NRCan contact) but I'm not in charge of the Canvec conversion process anymore. I should transfer the process to someone else but he/she has not been identified yet. I will be there to help correcting the process using comments I received by email and the page mentioned by Adam. Cheers! Daniel -Original Message- From: Frank Steggink [mailto:stegg...@steggink.org] Sent: May 29, 2011 04:18 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Railways duplicated in CanVec data @Daniel: I finally got around to add a few more issues to the page mentioned by Adam last week. I'm not sure if you or anyone else also encountered them, but here they are: * Some roads are tagged as highway=unclasified (with one 's'). These are mostly linking roads, and usually have the name Voie (in Quebec) * Most, if not all, road names (in highways and address nodes) have multiple consecutive spaces. * Some buildings are tagged as highway=services (with an 's' in the end), usually service stations near motorways. * (and another thing: the JOSM validator is complaning that many water areas should be reversed) Another thing I'm missing is names on large rivers, which are added as natural=water (multi)polygons. Is there a way to get those names, or perhaps would it be possible to generate centerlines (which can be tagged with waterway=river; name=*)? I've attempted to draw a few centerlines myself, but it's very time-consuming. I also wonder if there is any sight on an improved release of the Canvec OSM product, which has improved many of the known issues of the current release. I'm also still thinking about how to deal with road names, and Canvec vs. Geobase roads in general in Quebec. It's not clear how to proceed with that, especially since the boots on the ground option is nearly impossible. Other than that I'm still very glad with the offerings given by the NRCan :) Frank On 11-05-29 03:10 AM, Adam Dunn wrote: Indeed. In fact, this issue has already been listed on the wiki page: http://wiki.openstreetmap.org/wiki/CanVec#CanVec_7 :) Adam On Sat, May 28, 2011 at 9:06 AM, Samuel Longiarulongi...@shaw.ca wrote: I've been importing in south central BC and have noticed that there is a consistent duplication of railway = rail ways in the CanVec data. No big deal as if I forget, it is caught by the validator, but there must be a glitch somewhere in converting to OSM? Thanks ___ 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] Off-topic: general Canvec issues
Bonjour Brent, I'm forwarding your email to the manager in charge of the Canvec product. There are many project teams working on rethinking Canadian mapping nowadays. May it is just the good timing to have your requests consider! Regards, Daniel From: Brent Fraser [mailto:bfra...@geoanalytic.com] Sent: May 18, 2011 11:27 To: Bégin, Daniel Cc: talk-ca@openstreetmap.org Subject: Off-topic: general Canvec issues Daniel, While this is not directly related to OpenStreetMap, I'm posting this here since the OSM community seems to be the most active set of public users of Canvec data. The goal of this post is to improve Canvec (and therefore hopefully improve OSM). As a method of testing the latest release of Mapserver (http://mapserver.org/), I attempted to use Canvec v7 to render a CanTopo http://geogratis.cgdi.gc.ca/geogratis/en/product/search.do?id=A6291EF5-F3FC-A29F-3162-DE4DB194FD38 style map. See my mapserver post http://lists.osgeo.org/pipermail/mapserver-users/2011-May/068731.html for more details on my efforts. While the issues I covered on the Mapserver email list are specific to Mapserver rendering shortcomings, there were a few other issues related to the Canvec data. One of the main issues I ran into was the Toponymy (TO) layer http://wiki.openstreetmap.org/wiki/CanVec:_Toponymy_%28TO%29 is represented by point geometry preventing me from rendering the mountain range text (for example) in a curved manner as done in CanTopo. Is there any possibility of having NRCan change the geometry to LINESTRING? Or perhaps having a _TO_1580009_1 (linestring) shapefile for those names representing linear features in addition to the existing _TO_1580009_0 (point) shapefile? Some of the other less serious issues (these can be handled by pre-processing the Canvec data): Contour layer (FO_1030009_1): no attribute for major/minor contours preventing bolding of major contours Stream Layer (HD_1470009_1): major streams broken at tributary intersections preventing single label for streams Thanks! -- Best Regards, Brent Fraser ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec natural=land tags and untagged ways
Bonjour Samuel, Adam, and all. The purpose of the island conversion from area into point was to maintain toponyms without having the problem caused by natural=island tag for areas Your question just make me realised I should have simply removed island areas when there were no toponyms attached to it! I should be able to correct it for the next release. Best regards, Daniel From: Samuel Longiaru [mailto:longi...@shaw.ca] Sent: May 18, 2011 11:53 To: Adam Dunn Cc: talk-ca Subject: Re: [Talk-ca] CanVec natural=land tags and untagged ways Adam is correct here in that the natural=land tags I was talking about are on single nodes on islands in lakes. All have had a way surrounding them tagged as inner. None of the nodes that I have come across and deleted have had a name tag attached and so didn't seem to be serving any purpose. The name thing is good to know though and so I will be sure to check to see if any other tag is attached to them before deleting. Sam Original Message- From: Adam Dunn dunna...@gmail.com mailto:adam%20dunn%20%3cdunna...@gmail.com%3e To: Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca mailto:%3d%3fiso-8859-1%3fq%3fb%3de9gin%3d2c%3f%3d%20daniel%20%3cdaniel.be...@rncan-nrcan.gc.ca%3e Cc: Samuel Longiaru longi...@shaw.ca mailto:samuel%20longiaru%20%3clongi...@shaw.ca%3e , talk-ca talk-ca@openstreetmap.org mailto:talk-ca%20%3ctalk...@openstreetmap.org%3e Subject: Re: [Talk-ca] CanVec natural=land tags and untagged ways Date: Wed, 18 May 2011 08:38:48 -0700 The natural=island tag that Daniel is referring to used to be applied to the way of the island. This is the old way of doing things (pre-Canvec 7). I think the natural=land tag that Samuel is referring to is a single node at the centre of the island (Canvec 7). The natural=land node is there for the purpose of retaining toponymy (naming). Many islands don't have names and you can just delete the node, but some of these nodes will have the name of the island, so you should either keep the node or transfer the name of the island over to the island's outer way. For water body relations (not coastal), it is sufficient to have just a closed inner way polygon; you don't need a natural=land tag (or any other tags). I'm not that experienced with coastal tagging, but I think having a way going the correct direction around the island and tagged as natural=coastline is how to tag an island in the ocean/sea. One shouldn't need a natural=land in that case either (in fact, according to the wiki, having natural=land as the sole tag on a costal island is not the correct way of doing things [1]). The two cases where natural=land is required is when the island is only a node (too small to be a way polygon), or when you aren't using relations and need to have an island way polygon (but this is obsoleted by using relations). I thought the tagless ghost ways were a byproduct of how JOSM deletes relations, I didn't know it was part of the Canvec export's construction. They can be tossed. Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec natural=land tags and untagged ways
Hi Samuel, about a year ago, I removed natural=island ways from the Canvec data. Unless I'm confused (it appends sometime !-) it was applied for Release 7... The problem was that islands were/are overlaying all other features on rendering, including corresponding natural=wood features (ie : wooded islands renders white spot instead of green) If you still have natural=island features you should be in an area where the Release 7 could not be produced (about 30 files for the country) About the ghost ways, it was decided to create the Canvec product that way to ease partial/layer import (for example, import hydrography without wooded areas). However, once you have modified the data to merge both features, I don't see the need to keep ghost ways. Regards, Daniel From: Samuel Longiaru [mailto:longi...@shaw.ca] Sent: May 18, 2011 09:42 To: talk-ca Subject: [Talk-ca] CanVec natural=land tags and untagged ways Good morning everyone, I've been working for the last couple of months importing Canvec data into south-central BC and have almost completed the eastern half of 92I. I also have been lurking on the MkGMap list and one of the comments there today got me thinking that maybe I've been doing something wrong. Just wanted to get some comment here if I might. I can go back and fix things if need be. The procedure I have been using for importing is essentially a reflection of what I would normally do should I be mapping an area from scratch. I select a feature like wood, wetland, water, etc. from my CanVec data layer, check it against the existing OSM, merge where appropriate and delete the feature from my CanVec data layer so I can keep track of what I have done. At the end of this process, I am usually left with a couple of things in the CanVec layer which I discard. For example, after merging wood, I delete it from the CanVec layer and in many cases am left with another untagged way that follows the wood boundary. This way has no tags at all and is not part of any relationship. As it normally would not be present should I have just traced the wood using Potlatch or JOSM, I delete it and do not import it into OSM. I have also been ignoring the natural=land tags that appear on islands in lakes. I have not been importing this tag since if I understand things correctly, it is sufficient to have islands tagged only as inner members of relationships. As a check, I have gone back and examined the rendered OSM maps, and all wood and islands are rendering correctly. I have also imported some of my imported CanVec data into my Garmin Nuvi through Lambertus's site and all render correctly as well. In response to a query on the MkGMap list as to why oceans were not rendering as blue on someone's Garmin (I have this problem too by the way) the comment was made that islands needed to be tagged as natural=land. I'm not sure that is actually the case but it did get me thinking about the island tags I have been discarding and the other superfluous CanVec data I have also been tossing. Is it OK to toss these natural=land tags? And what is going on with these ghost ways that appear under under the boundaries to wooded areas? OK to toss them as well? ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Routing issue / Probleme de routage
Bonjour Nakor, Mon hypothèse première est qu'il doit y avoir un bris dans la continuité du réseau routier entre Rivière-du-Loup et Rimouski. Cependant, le bris doit cependant apparaître sur tout les segments de la région si aucun chemin alternatif parallèle à la route 132 est sélectionné. Ce qui me surprendrait! Daniel -Original Message- From: Nakor [mailto:nakor@gmail.com] Sent: April 13, 2011 15:51 To: talk-ca@openstreetmap.org Subject: [Talk-ca] Routing issue / Probleme de routage Bonjour, Quelqu'un aurait-il une idee de la raison de ce routage particulier : http://open.mapquest.com/link/4-J9uff4Tn Si on ajoute Rimouski come point intermediaire le chemin est bien plus direct Does anyone know why this strange routing happens: http://open.mapquest.com/link/4-J9uff4Tn If I add Rimouski as a waypoint everything is fine. Merci, N. ___ 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] Duplicate rail lines in 092H06
Hi Michael, I expect to start the conversion process in June Cheers, Daniel From: Michael Barabanov [mailto:michael.baraba...@gmail.com] Sent: April 11, 2011 20:12 To: Bégin, Daniel Cc: Adam Dunn; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Duplicate rail lines in 092H06 Daniel, When is the next version expected? On Mon, Apr 11, 2011 at 5:36 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Bonjour Adam, It has been detected in January and the problem is not limited to 092H06. I was on the impression that I sent an email on Talk-ca about that but, as I didn't find any email in my outbox, it seems I didn't! It will be corrected in the next release. Best regards, Daniel -Original Message- From: Adam Dunn [mailto:dunna...@gmail.com] Sent: April 10, 2011 12:24 To: Bégin, Daniel Subject: Duplicate rail lines in 092H06 Haven't checked other areas, but 092H06 has duplicate ways with the same tags for rail lines. Adam ___ 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] Duplicate rail lines in 092H06
Bonjour Adam, It has been detected in January and the problem is not limited to 092H06. I was on the impression that I sent an email on Talk-ca about that but, as I didn't find any email in my outbox, it seems I didn't! It will be corrected in the next release. Best regards, Daniel -Original Message- From: Adam Dunn [mailto:dunna...@gmail.com] Sent: April 10, 2011 12:24 To: Bégin, Daniel Subject: Duplicate rail lines in 092H06 Haven't checked other areas, but 092H06 has duplicate ways with the same tags for rail lines. Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Duplicate rail lines in 092H06
Short answer - Canada -Original Message- From: Adam Dunn [mailto:dunna...@gmail.com] Sent: April 11, 2011 16:04 To: Bégin, Daniel Cc: talk-ca@openstreetmap.org Subject: Re: Duplicate rail lines in 092H06 What is affected by this? Is it BC only or all of Canada? Does it affect only ways tagged railway=rail or others as well? I will add it to the list of known issues at http://wiki.openstreetmap.org/wiki/CanVec#CanVec_7 Adam On Mon, Apr 11, 2011 at 5:36 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Bonjour Adam, It has been detected in January and the problem is not limited to 092H06. I was on the impression that I sent an email on Talk-ca about that but, as I didn't find any email in my outbox, it seems I didn't! It will be corrected in the next release. Best regards, Daniel -Original Message- From: Adam Dunn [mailto:dunna...@gmail.com] Sent: April 10, 2011 12:24 To: Bégin, Daniel Subject: Duplicate rail lines in 092H06 Haven't checked other areas, but 092H06 has duplicate ways with the same tags for rail lines. Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Canvec Product/Wooded area
Bonjour à tous, I have been informed that some wooded area are missing - usually an entire sub-tile. This problem should have been resolved for the next release. Thank you Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Woods along Canvec Borders
Bonjour Adam, You have just learn what is an edgematch problem! This problem of mismatched lines/polygons at the edge of NTS mapsheets is usually caused by a difference in imagery/photography acquisition dates. Each year, we were contracting out imagery/photography acquisition over areas convering many NTS mapsheets. The problem arise at the edge of two areas when many years passed between each contract. Things are changing over time out there !-) Daniel -Original Message- From: Adam Dunn [mailto:dunna...@gmail.com] Sent: March 18, 2011 14:19 To: Bégin, Daniel Subject: Woods along Canvec Borders When importing Canvec data within a single NTS tile (092H05.x.x), the border between sub-tiles lines up and matches very well. It's a simple task to merge nodes along the border and join ways/areas if necessary. Doing a border between NTS tiles (092Hx) doesn't tend to work out as well. Sometimes it seems to be okay, but sometimes it looks like there's a serious mismatch. In attached screenshot, you can see how natural=wood appears to mismatch from 092H05.3.3 (left of screen) to 092H06.0.0 (right). I don't think it's a bug in how JOSM drawing fills polygons either. Both of those tiles are Canvec 7, downloaded within the past month. Ideas? Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Reporting Canvec errors
Bonjour Samuel, James, and all Please, feel free to contact me for any problem concerning Canvec data I'm providing to the OSM community. I will relay the message to whom it concerns if necessary. If you use standard Canvec product (.gml, shp or file gdb), it is possible to flag potential discrepancies on CanVec data or metadata, by communicating with GeoGratis Client Services: geogi...@nrcan.gc.ca. Daniel -Original Message- From: Samuel Dyck [mailto:samueld...@gmail.com] Sent: March 7, 2011 21:21 To: talk-ca@openstreetmap.org Subject: [Talk-ca] Reporting Canvec errors Hi I've racked up a list of errors is Canvec data. We've probably gone over this before, but how do I report errors and out of date information in Canvec. Sam Dyck ___ 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] Mapping cut blocks in wooded areas
Hi all, just for your information. The Canvec vegetation layer will be replaced by a state of the art image classification. It is based on a subset of the GeoBase Land Cover product. I don't know if cut blocks will be included or excluded of the wooded areas. Daniel From: Connors, Bernie (SNB) [mailto:bernie.conn...@snb.ca] Sent: March 7, 2011 08:29 To: 'Bryan Crosby'; 'talk-ca' Subject: Re: [Talk-ca] Mapping cut blocks in wooded areas Bryan, I would have to agree with your argument. I have some knowledge of the forestry GIS that is used here in NB and it would be a daunting task to include cut blocks in the forest. There is more than enough OSM work in Canada just getting the road network built it would be counterproductive to spend a lot of time on forest cut blocks. Bernie. -- Bernie Connors, P.Eng Service New Brunswick (506) 444-2077 45°56'25.21N, 66°38'53.65W www.snb.ca/geonb/ From: Bryan Crosby [mailto:azubr...@gmail.com] Sent: Saturday, 2011-03-05 01:58 To: 'talk-ca' Subject: Re: [Talk-ca] Mapping cut blocks in wooded areas I would tag it as natural=wood as I don't feel that there is any distinction between a 2-year old stand and a 250 year old stand in terms of being wood, or forest. They are merely different ages. Licensees maintain incredibly accurate and up-to-date maps that indicate the different openings and their respective stages of development. They have dedicated GIS guys that maintain these maps as fast as techies bring it in. I suppose, in theory, an OSM tag could be used to indicate the stage of opening development, but one would require the date of harvesting, the date of planting and the dates of the silviculture surveys to accurately assess the phase. Unless you are a forester you won't have access to that information and would be guessing. I just feel that attempting to seriously map out such temporary features accurately goes way beyond the ability of OSM (at this point, at least). Bryan From: Samuel Longiaru [mailto:longi...@shaw.ca] Sent: March-04-11 9:43 PM To: talk-ca Subject: Re: [Talk-ca] Mapping cut blocks in wooded areas I very much see your point which is why I was asking for some direction. I guess it comes down to whether the map should reflect what we see at some given snapshot in time, or whether it is reflecting the overall landuse scheme. In short, while standing in the middle of a clear-cut, would it be more accurate that my map show that spot as wooded or not wooded? Sam L. -Original Message- From: Bryan Crosby azubr...@gmail.com mailto:bryan%20crosby%20%3cazubr...@gmail.com%3e To: 'talk-ca' talk-ca@openstreetmap.org mailto:'talk-ca'%20%3ctalk...@openstreetmap.org%3e Subject: Re: [Talk-ca] Mapping cut blocks in wooded areas Date: Fri, 04 Mar 2011 21:11:20 -0800 RE: cut-blocks As someone who has spent done time as a forest technician, I strongly advise against mapping forestry activity. Cut block spatial data changes daily and any images used to trace are out of date. There are literally tens of thousands of clear cuts in British Columbia alone and there is absolutely no way OSM mappers would be able to keep up with changes. Keep in mind that most clearcuts on crown land (and in some cases, private land) are temporary openings in various stages forest development. A 2 year old stand is just as much a forest as a 25 year old free-to-grow stand or a 250 year old stand of timber. I believe that mapping a privately held 'Christmas' tree farm would be pertinent, but these are radically different from commercial forestry openings. I would also advise extreme caution in using images to map forest development roads unless are working on a high traffic mainline. Many spur roads are in various stages of deactivation. It may look like a road from the outdated image, but it may have been completely deactivated and replanted. A site inspection is the only way to be sure. Bryan British Columbia From: Daniel Begin [mailto:jfd...@hotmail.com] Sent: March-04-11 8:19 PM To: 'Samuel Longiaru'; 'talk-ca' Subject: Re: [Talk-ca] Mapping cut blocks in wooded areas Hi Samuel, About tagging forested areas, I would use landuse=forest only if it is obvious on the field that the area is managed/harvested, as for landuse=orchard or landuse=vineyard. We have a lot of Christmas tree plantations in the area and I map them as landuse=forest because it is obvious on the imagery and on the field. If it is difficult to determine if an area is under timber lease or not, because it looks the same, I would keep it natural=wood... About Cut blocks, I would map the hole they create that wooded area. If the area is replanted, then some OSM contributor will remove the hole you map in 10-20 years from now! Mapping the reality is the best we can do and because the reality changes
Re: [Talk-ca] Notes on a Saskatchewan import
Bonjour Brent, For your information ... Canvec: Next Release will include the current GeoBase road network, including street names GeoBase Road Network: Next release will include address ranges if completed GeoSask Road Network: is older (2004) than Canvec (2010) Cheers, Daniel -Original Message- From: Brent Fraser [mailto:bfra...@geoanalytic.com] Sent: March 1, 2011 10:41 To: talk-ca@openstreetmap.org Subject: [Talk-ca] Notes on a Saskatchewan import To All, I finally had got around to doing my first OSM data import session. I had some spare time and was frustrated with the lack of OSM progress in Saskatchewan, so I imported a Canvec sub tile for Melfort Sask (http://www.openstreetmap.org/?lat=52.8086lon=-104.6061zoom=12layers=O). It was surprisingly easy, thanks to the great work of Daniel Bégin in supplying .osm formatted Canvec data, and Steve Singer's blog on importing Canvec (http://scanningpages.wordpress.com/2010/08/08/openstreetmap-canvec-importing/). I used Josm to import the geometry and Potlatch to add the street names (the street naming was tedious, but somehow felt rewarding). For others planning to do some OSM work in Saskatchewan, here's a summary of free and license-friendly sources of street GIS data: Canvec (.osm format) ftp://ftp2.cits.rncan.gc.ca/osm/pub - old geometry - no street names - no address ranges GeoSask Road Network ftp://portaldata:freed...@ftp.isc.ca/PackagedData/Sask_Highways/SURN09.zip - geometry same as Canvec (old) - complete street names, but poor capitalization and spelling: MACLOED AVENUE - no address ranges Geobase Road Network http://www.geobase.ca/geobase/en/search.do?produit=nrnlanguage=en - new geometry - complete street names, poor capitalization and spelling: Macloed Avenue - no address ranges StatsCan http://geodepot.statcan.gc.ca/2006/040120011618150421032019/1814062006_05-eng.jsp - newer geometry but positional accuracy poor - incomplete street names (unless you combine NAME and TYPE attributes) MacLeod AVE - has address ranges -- Best Regards, Brent Fraser ___ 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] Firing Range Mistagged as Cemetery?
Bonjour Adam, This time I'm not behind this range-cemetery conversion !-) The source dataset I used to create the Canvec.osm product (Canvec.gml) also describes the area as a cemetery. I'll forward your finding to the appropriate people. Thank you Daniel -Original Message- From: Adam Dunn [mailto:dunna...@gmail.com] Sent: February 22, 2011 21:59 To: talk-ca; Bégin, Daniel Subject: Firing Range Mistagged as Cemetery? A couple years ago, before the CFB closed down, there was a firing range for the military. A high school has since been built there, but you can see [1] for the approximate position (the range still appears in Yahoo and Bing). I was doing some Canvec 7 import for my area, and noticed that this area was marked as a cemetery. I think that Canvec 7 might have an issue with mistagging military=range or sport=shooting as landuse=cemetery (in a similar way to the already identified comical school-prison mistag). Unfortunately I don't know of any other ranges where I can test this theory. Might be something to look into. Or maybe it really was a cemetery before the military took over? Adam [1] http://www.openstreetmap.org/browse/node/281579645 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Revert in Aylmer is complete
Bonjour Jonathan, NRN (source of Canvec road network) was not supposed to contain any planned street but I understand that some have been included accidentally in Quebec. Field work might be necessary until the next NRN version is available and included in Canvec product. Daniel -Original Message- From: Jonathan Crowe [mailto:jonathan.cr...@gmail.com] Sent: February 23, 2011 11:45 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Revert in Aylmer is complete Richard, thank you. The reversion is coming up in Mapnik now -- I didn't have to check in an editor after all -- and things look back to normal as far as I can tell. If there are glitches, they can't be very widespread. I notice that the addr:interpolation ways are still there, which all in all I think is a good thing. They can be a little off in some of the newer developments (e.g., around Wilfrid-Lavigne north of Allumettières); older streets match up better with the addr:interpolation ways. And it's somewhat ghostly to see them where there are no streets. These are things that can be tweaked manually -- but still less work than we would otherwise have faced. [1] I'm reluctant to trace in street ways between the ghost addr:interpolation ways without confirming on the ground the existence of the street, in case the imported data includes streets on the drawing boards that have not yet been built (which I spotted in at least a couple of areas, unless the City of Gatineau has been busy over the winter). I plan on surveying these streets in the spring, unless someone else who lives closer beats me to it. [1] http://osm.org/go/cIhDQbn1M- Jonathan Crowe The Map Room: A Weblog About Maps http://www.maproomblog.com ___ 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] Mapping of wetlands in Montreal
I would agree with Olivier, Non-GeoBase themes have not been updated in southern Canada for 20 years - with few exceptions Daniel -Original Message- From: Olivier Hill [mailto:olivier.h...@gmail.com] Sent: February 3, 2011 08:41 To: Richard Weait Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Mapping of wetlands in Montreal Richard, I can tell you right now that the Ducks Illimited Data is *WAY* more recent. They have used special 3D techniques to identify small areas that were not known before to be wetlands. They can also better classify. For example, CanVec has lakes beside my home, they don't exist, it's more likely to be small wet saturated soil. Best, Olivier On Wed, Feb 2, 2011 at 11:26 PM, Richard Weait rich...@weait.com wrote: On Wed, Feb 2, 2011 at 9:23 PM, Olivier Hill olivier.h...@gmail.com wrote: Hello, FYI I have contacted them to see whether we could have access to that data and permission to import on OSM. English: http://www.ducks.ca/aboutduc/news/archives/prov2011/110131.html French: http://www.ducks.ca/fr/apropos/nouvelles/archives/prov2011/110131.htm l Great collection of wetlands in the Montreal CMM. It's not clear whether it's public data or not, we will see... Great way to save wetlands if we are aware of them when looking at our map. There is a canvec data theme for saturated soils that likely includes this information. It would be interesting to see which source is more up to date. -- http://www.olivierhill.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] User: Acrosscanadatrails wiki.openstreetmap housecleaning effort
Bonjour Grant and Frederik, I understand that you are helping Sam in an osm-wiki housecleaning effort? It seems that some of the pages you marked for deletion were actually created/edited by me to support the community with the content of the Canvec product... http://wiki.openstreetmap.org/wiki/CanVec The following pages should not have been marked for deletion and I'd like to see them back to the wiki http://wiki.openstreetmap.org/wiki/CanVec:_Hydrography_(HD) http://wiki.openstreetmap.org/wiki/CanVec:_Administrative_boundaries_(LI) http://wiki.openstreetmap.org/wiki/CanVec:_Water_saturated_soils_(SS) http://wiki.openstreetmap.org/wiki/CanVec:_Toponymy_(TO) http://wiki.openstreetmap.org/wiki/CanVec:_Transportation_(TR) http://wiki.openstreetmap.org/wiki/CanVec:_Vegetation_(VE) I did not have a look at those pages for a while but let me know if you think they should be cleaned for any reason. I'll do the job. Regards, Daniel Bégin Centre d'information topographique de Sherbrooke Topographic Information Center of Sherbrooke Ressources Naturelles Canada / Natural Ressources Canada 2144, rue King Ouest, bureau 010 Sherbrooke (Québec) J1J 2E8 (819) 564-5600 ext.242, dbe...@nrcan.gc.ca From: Sam Vekemans [mailto:acrosscanadatra...@gmail.com] Sent: February 2, 2011 16:02 To: Talk-CA OpenStreetMap Cc: Grant Slater; Frederik Ramm Subject: [Talk-ca] User: Acrosscanadatrails wiki.openstreetmap housecleaning effort Hi all, (talk-ca list). With thanks to Frederik Grant, who have kindly flagged all of my wiki contribution pages for deletion, i have now fully backed-up all of these pages. For some of the pages, they were accidentally flagged, which should be kept. I put a note on each of these pages, as some of them might be kept. Since others have made edits after i created the page, there is no reason to delete the work. http://wiki.openstreetmap.org/wiki/Special:Contributions/Acrosscanadatrails I noted a few with This one is fine, Daniel from NRCan actually edited it. (should be kept) For the rest of them, it was mostly a 'housekeeping effort', as alot of the pages that i created (back in 2008) were relating to my (independent) Across Canada Trails project, where the material has no place on this OpenStreetMap wiki. I now have my own wikia website http://acrosscanadatrails.wikia.com/wiki/Across_Canada_Trails_Wiki so all of the material that i requested to be removed will be found on this website instead (not right away, but eventually). I have kept a copy of the pages on GoogleDocs in a private folder, as well as for some of the bigger pages, they are kept archived on mediafire.com http://www.mediafire.com/acrosscanadatrails The pages will be removed perminanly from the OpenStreetMap foundation servers, with 24 hours (or less or more if they decide to), but the actual information remains safe and now backed up elsewhere. Hopefully the wiki will be a bit cleaner now :) Cheers, Sam --- Across Canada Trails - Beyond 2017 - The National Trails Network Victoria, BC Canada Twitter: @Acrosscanada Blog: http://acrosscanadatrails.posterous.com/ Facebook: http://www.facebook.com/sam.vekemans Skype: 'Sam Vekemans' Member, CommonMap Inc. http://commonmap.org/ IRC: irc://irc.oftc.net #CommonMap Also find us on Facebook, Twitter and LinkedIn ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Canvec.osm Product -Completed!
Bonjour OSMers! Canvec.osm Product conversion is completed - except for 31 files that should be reprocessed in the following weeks - see the list at the end of this email. What's new ... - The vegetation has been updated for some areas in eastern Canada. - Quebec road network now includes addressing; - Manitoba road network now includes street name; Schema upgrade ... - landform=beach replaced by natural=beach - for rendering - aeroway=runway replaced by aeroway=apron - more realistic - natural=land area converted to point - unhide features and keeps toponyms - Some fixme comments were clarified Identified problems ... - Tagging error on school/prison that will be fixed on next release. Cheers, Daniel Files not processed 002E13 011D12 012A07 012P08 023G16 023J09 031M08 042J15 042O01 042P12 043B02 043F09 043G03 043G04 043G15 043K06 043L08 043L13 043M01 043N02 043N04 052L15 053J04 053P13 053P14 062F14 063C03 063N07 082G01 083G02 095C14 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Street name upload
Salut osmers, Is there an easy way (an application of some kind) that can be used to transfer street name from Canvec street network/Karlsruhe schema to name tag on existing road network. This release of Canvec.osm in Quebec area has addressing/street name, but manual transfer of street name on existing road network takes up to 95% of uploading time. Any ideas? Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec tiles in Manitoba missing? Schools becoming prisons in Canvec 7?, and more...
Bonjour Tyler, Samuel, Olivier, Richard and all The Canvec.osm conversion process is still running... Some .gml Canvec files (input file of the conversion process) were corrupted in Manitoba. The .gml files have just been replaced, so they should be available (.osm) in the following days. The beta version of the fme application I'm using to convert the files has a problem. So far, there is about 30 files that can't be processed properly - including 031H12. I'm waiting for a new version. There is a bug in school/prison tagging process. Ponctual (node) schools are tagged prison while surface (way) prisons are tagged school. It should be corrected in the following weeks. Cheers, Daniel -Original Message- From: Tyler Gunn [mailto:ty...@egunn.com] Sent: December 30, 2010 20:53 To: talk-ca@openstreetmap.org Cc: Bégin, Daniel Subject: Canvec tiles in Manitoba missing? Hello, I notice that a good part of Southern Manitoba has been re-converted with the Canvec 7.0 data. Great work Daniel! Kudos! I'm glad I no longer need to name all the streets!!! Are the tiles processed sequentially? I'm just curious because I notice some tiles are not processed whether most of the others in an area are. For example: 062G01.zip 21-Dec-2010 15:37 1.0M 062G02.zip 13-Jul-2010 00:11 878K 062G03.zip 21-Dec-2010 15:41 1.7M 062G04.zip 21-Dec-2010 15:44 1.4M 062G05.zip 21-Dec-2010 15:47 1.5M 062G06.zip 21-Dec-2010 15:50 1.1M 062G07.zip 13-Jul-2010 00:28 964K 062G08.zip 21-Dec-2010 15:53 714K 062G09.zip 13-Jul-2010 00:34 1.0M 062G10.zip 13-Jul-2010 00:37 972K 062G11.zip 21-Dec-2010 16:00 850K 062G12.zip 21-Dec-2010 16:03 1.0M 062G13.zip 13-Jul-2010 00:50 1.1M 062G14.zip 21-Dec-2010 16:07 1.3M 062G15.zip 21-Dec-2010 16:11 1.4M 062G16.zip 13-Jul-2010 01:00 1.1M Note that 062G13, for example, is not processed. Just curious if that means there's no newer data available for that tile? Thanks! Tyler -- Tyler Gunn ty...@egunn.com http://www.egunn.com/ ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Manitoba Highway Naming -- Need some French translationadvice
Hi Tyler,
I'm a bit confuse. Is it really written Provincial Trunk Highway XY on street
corners? If not, is it necessary to add a name tag (english or french) when the
information is already available?
Highway=trunk
Ref=XY
name=Provincial Trunk Highway XY ?
I understand that we usually name highways based on what can be found on street
corners.
However, to answer your question, Route provinciale secondaire 254 seems OK
(actually it looks a bit ackward, - not because french - but because it sounds
strange for me, even in english)
Regards,
Daniel
-Original Message-
From: talk-ca-boun...@openstreetmap.org
[mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Tyler Gunn
Sent: January 4, 2011 22:29
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Manitoba Highway Naming -- Need some French translationadvice
In my most recent Canvec Imports of MB I'm trying to nail down the french names
for Provincial Roads and Provincial Trunk Highways in Manitoba. So far the
general scheme I'm using for naming is as follows:
Provincial Trunk Highway:
Any highway where ref=[0-9]{1-2} (ie one or two digit route number) highway =
primary name = Provincial Trunk Highway XY name:en = Provincial Trunk Highway
XY name:fr = Route provinciale à grande circulation XY
Provincial Road:
Any highway where ref=[0-9]{3,3} (ie a 3 digit route number) highway =
secondary name = Provincial Road XYZ name:en = Provincial Road XYX name:fr =
Route provinciale secondaire XYZ
The french names for the provincial road and provincial trunk highway are based
on what I've seen in various government publications such as the Highway and
Transportation Act (http://web2.gov.mb.ca/laws/statutes/ccsm/h050e.php).
I'm basing the convention of road classification based on what I've observed
having lived here forever, and also based on the MB government highway
classification standards (http://www.gov.mb.ca/mit/mcd/mcpd/mhcs.html).
The main thing I'd like to ask if if my french equivalents make sense. Ie is
Provincial Road 254 = Route provinciale secondaire 254? What about roads where
there are two routes? Ie. Provincial Trunk Highway 3 83; is this Route
provinciale à grande circulation 3 83?
Thanks!
Tyler
___
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] [Tagging] 0-0 address lines
Bonjour Sam, and Nathan, Actually there is no such thing as default value in Canvec road network. The data is provided to NRCan by each province/territory. The first house number address value along a particular side (left or right) of a Road element have the following values: [-1,0,1..n] where 0 is used when no value applies. The value -1 is used when the value is unknown. I can have thoses addresses removed for the next release Cheers, Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Sam Vekemans Sent: December 20, 2010 21:54 To: Tag discussion, strategy and related tools; Talk-CA OpenStreetMap Subject: Re: [Talk-ca] [Tagging] 0-0 address lines Hi, You might want to ask the talk-ca list... instead of tagging list :) It's the default value for CanVec when the data is not available. Every 6 months, the source data (as Natural Resources Canada made .osm files) gets updated. So more provinces will have housenumbers, in time :) ... the 1st priority is roadnames. . but alas, this is OSM, and it is possable to remove it. Or is it? Thanks, Sam On 12/20/10, Nathan Edgars II nerou...@gmail.com wrote: There are a lot of ways in Canada like http://www.openstreetmap.org/browse/way/71852646 that have addr:housenumber = 0 at both ends. Is this a bad import or legitimate way of tagging? ___ Tagging mailing list tagg...@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging -- Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails ___ 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] Canvec.osm Product - Running!
Hi Robert, It depends on you !-) If you are not concerned by updates in Quebec and in Manitoba, and if you like to remove natural=land areas manually, and convert runway to apron before capturing corresponding runway and taxiway, then I guess you should resume your imports. You can also check the status of the conversion for your area using the following link ftp://ftp2.cits.rncan.gc.ca/osm/pub/ZippedOsm.txt instead of waiting that the entire country is finished! Cheers, Daniel -Original Message- From: Robert Shand [mailto:b...@shand.org.uk] Sent: November 30, 2010 16:56 To: Richard Weait Cc: Bégin, Daniel; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canvec.osm Product - Running! Thanks Daniel! So if I'm working on importing canvec data - should I wait until the tiles I'm importing are complete before I continue? B On 2010-11-30, at 5:46 PM, Richard Weait wrote: On Tue, Nov 30, 2010 at 4:43 PM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Bonjour OSMers! Canvec.osm Product conversion is running since 16:10 - Sherbrooke time. It is based on the new Canvec release (7.0). Thank you, Daniel! ___ 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] Highway=trunk
Olivier wrote: In that case, the 50 between Gatineau and Lachute would in part be classified as motorway, parts as trunk? Hé, I actually map that segment! (in my other life). I initially tagged this segment as motorway because the trunk designation is not used in Québec. It is now tagged trunk, as expected looking at the wiki - and I don't complaint here!-) because it seems right to me. This example matches the proposed wiki definition and the road classification in Canvec product. However, I can't confirm -for the moment- that the NHS (http://www.comt.ca/reports/NHS-Map-08.pdf) has been used in GeoBase/Canvec Roads classification. Regards, Daniel -Original Message- From: Olivier Hill [mailto:olivier.h...@gmail.com] Sent: November 4, 2010 08:06 To: Bégin, Daniel Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Highway=trunk Bonjour Daniel, I understand that initially the roads in Québec were tagged using this classification... http://wiki.openstreetmap.org/wiki/Canada:Quebec http://wiki.openstreetmap.org/wiki/EN:Canada:Quebec Funny the page says: Trunk: ??? (should use National Highway Service roads); The concept of trunk is not really used in Québec, at least by French people. So, local mapper won't use it. Absolutely. I just found out what NHS means actually. The difference between trunk/motorway is based on carriageways (single/dual). So the wiki should say: motorway if dual, trunk if NHS and single carriageway? In that case, the 50 between Gatineau and Lachute would in part be classified as motorway, parts as trunk? [1] [1] http://www.openstreetmap.org/?lat=45.68321lon=-74.05471zoom=15layers=M Best regards, Olivier -- http://www.olivierhill.ca/ ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Map Error
Hi all, I would agree with Gordon, it looks pretty much like an artifact left over after the NAD27-NAD83 conversion. These artifacts were corrected when the map were digitized but obviously not in this case. Sam, this does not happen across the country along the NTS border lines. You find edge match problems due to differences in time of aerial photography, aerial photography interpretation, and so on, but not the NAD27-NAD83 conversion. About GeoBase NHN data, it should be the same because, as explained before, they all come from the same source. However, the QC team is already having a look and I will get back to you soon. Thanks, Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Sam Vekemans Sent: October 25, 2010 00:40 To: gor...@pinetree.org; Bob Dustan Cc: talk-ca Subject: Re: [Talk-ca] Map Error Hi, Yes. Thats most likely correct. This happens across the country along the NTS border lines. You might want to check the GeoBaseNHN data, as it could be better. (since its organized in water basins)[1] Then we can go 1 level deeper, into the Land Information Ontario dataset. A WMS layer is available [2] as well as the source shp files. (I do have direct access to it (via a data warehouse loginID) [1] wms layer for JOSM (found on this page http://wiki.openstreetmap.org/wiki/Geobase/NHN_-_OSM_Map_Feature) http://wms.cits.rncan.gc.ca/cgi/wms_en.cgi?map=/export/wms/mapfiles/rhn/geobase_rhn.mapversion=1.1.1service=WMSrequest=Getmaplayer=HYDRO_AGGREGATformat=image/pngSTYLE=defaultlayers=GEOBASE_RHN_NHN; [2] http://wiki.openstreetmap.org/wiki/Land_Information_Ontario#Data_Access_-_WMS_Layers You'll have to dig... i'm not exactly sure where the river WMS is.. but i do remember seeing it. The Ontario servers are considerably slower than NRCan, so you'll need to be patient :) You might want to try using Merkaartor, as it can handle WMS layers alot better. http://wiki.openstreetmap.org/wiki/Merkaartor Cheers, Sam P.S. great to hear from another Ibycus Topo user :) One of my projects is to make a better version of it, now that more data is available. I don't know if Dale Atkin is planning on doing the same at some point. --- Across Canada Trails - Beyond 2017 - The National Trails Network Victoria, BC Canada Twitter: @Acrosscanada Blog: http://acrosscanadatrails.posterous.com/ Facebook: http://www.facebook.com/sam.vekemans Skype: 'Sam Vekemans' IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) IRC: irc://irc.oftc.net #CommonMap The Common Map channel (an open chat room) On Sun, Oct 24, 2010 at 2:16 PM, Gordon Dewis gor...@pinetree.org wrote: Interesting. I wonder if it's an artefact left over after the NAD27-NAD83 conversion. --Gordon -Original Message- From: Bob Dustan bob.dus...@gmail.com Sender: talk-ca-boun...@openstreetmap.org Date: Sun, 24 Oct 2010 14:30:45 To: talk-catalk-ca@openstreetmap.org Subject: [Talk-ca] Map Error Hi, I was importing CanVec data for 031E07 and noticed what appears to be an error in the map. A section of the Oxtongue River seems to be repeated nearby in 031E06. In OSM you can see it at: http://www.openstreetmap.org/?mlat=45.317mlon=-79.0zoom=15layers=M If you use JOSM or Merkaator to view this area and enable the NRCan WMS, you'll see that the error is also in the WMS version of the map. The error also appears in The Atlas of Canada (Toporama) web site at: http://atlas.nrcan.gc.ca/site/english/maps/topo/map?layers=nodata_ntdb _50k%20north_arrow%20other_features%20million_grid%20t50k_grid%20grid_ 50k_3%20roads%20hydrography%20boundary%20builtup%20vegetation%20popula ted_places%20railway%20power_network%20manmade_features%20designated_a reas%20water_features%20water_saturated_soils%20relief%20contours%20to ponymy%20contourscale=140.00mapxy=1281552.5697346777%20-2736 73.4692181579map_layer[northarrow]_class[0]_style[0]=ANGLE%20-14.5876 61326428645mapsize=750%20666urlappend= The error also appears in the Ibycus map. Also, if you look north along the boundary between these 2 map sections, you will see other discrepancies. I have topo maps of the area that I bought at least 10 years ago. They appear to be scans of paper maps. When I line up the 2 map sections, everything lines up (roads, rivers, elevation lines, etc.). It seems to me that some errors (albeit fairly minor) were introduced in the digital form of the map. Then the errors were propagated to CanVec. Is there a way to get the map corrected? Bob ___ 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
Re: [Talk-ca] Fwd: Re: CanVec import troubles
Hi all, The problem behing these missing tags was corrected a month ago (problem of missing peaks). I can reprocess your area or you can wait for the next release in november. What would you prefer? Daniel -Original Message- From: Tyler Gunn [mailto:ty...@egunn.com] Sent: September 29, 2010 08:53 To: Bégin, Daniel Cc: Adam Dunn; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Fwd: Re: CanVec import troubles On Wed, 29 Sep 2010 08:09:02 -0400, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Hi, I will have a look as soon as possible and I'll get back to you. I've encountered similar issues further up in Northern Manitoba where some rivers are missing tags and lakes are missing tags. Thanks, Tyler -- -- Tyler Gunn ty...@egunn.com ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Fwd: Re: CanVec import troubles
Sam wrote: So will this be a Diff [...] stored in a different folder? Not yet. It is going to be a different (and much more complex) process. I will have a discussion with the community before launching it !-) Cheers, Daniel -Original Message- From: samvekem...@gmail.com [mailto:samvekem...@gmail.com] On Behalf Of Sam Vekemans Sent: September 30, 2010 10:53 To: Tyler Gunn Cc: Bégin, Daniel; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Fwd: Re: CanVec import troubles Hi, Also, because each tile is slowly being dropped in, it's easy to use the filter tool for when selecting what data to import. So a quick filter for 'natural=peak' would find them all, and add them in. I don't see a rush for it either :) November to start the next round? Cool. So will this be a Diff (smaller set of the changes), stored in a different folder in the ftp site? or will it replace what is currently stored? Great work! Cheers, Sam On Thu, Sep 30, 2010 at 7:37 AM, Tyler Gunn ty...@egunn.com wrote: On Thu, 30 Sep 2010 10:36:15 -0400, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Hi all, The problem behing these missing tags was corrected a month ago (problem of missing peaks). I can reprocess your area or you can wait for the next release in november. What would you prefer? I'm in no rush for the Manitoba stuff as there is plenty to import in the lower half of the province where the problem has not made itself apparent. Thanks, Tyler -- Tyler Gunn ty...@egunn.com ___ 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] Fwd: Re: CanVec import troubles
Hi,
I will have a look as soon as possible and I'll get back to you.
Daniel
From: Adam Dunn [mailto:dunna...@gmail.com]
Sent: September 28, 2010 14:17
To: Bégin, Daniel
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Fwd: Re: CanVec import troubles
Daniel: in the area that Samuel is working with, there appear to be ways and
relations that are missing tags.
I opened 064A01.0.osm, and the extreme south-west corner has a way where the
only tag is source=CanVec 6.0 - NRCan. There are no other tags for this way
(water? wood? wetland?). Similar ways exist about 1/3 of the way up the western
border. The relation the runs the entire length of the northern border has only
the tags {type=multipolygon, source=CanVec}, though it should probably also
have the natural=water tag.
Samuel: this doesn't negate the problems importing relations you are
experiencing, but will cause you some headaches. Wait for Daniel to respond
before continuing to import.
Adam
On Tue, Sep 28, 2010 at 11:08 AM, Adam Dunn dunna...@gmail.com wrote:
Sam: I'll take one of the water relations as an example. snip
Play around with Josm and learn from your mistakes and things will get
easier.
Adam
On Mon, Sep 27, 2010 at 7:20 PM, Samuel samueld...@gmail.com wrote:
Original Message
Subject:Re: [Talk-ca] CanVec import troubles
Date: Mon, 27 Sep 2010 21:19:49 -0500
From: Samuel samueld...@gmail.com mailto:samueld...@gmail.com
To: Adam Dunn dunna...@gmail.com mailto:dunna...@gmail.com
Hi
So how would I replace the previously uploaded data with fresh
CanVec Data. I can't seem to get rid of the old data without cauing conflicts.
Sam
On 10-09-25 06:43 PM, Adam Dunn wrote:
On Sat, Sep 25, 2010 at 1:31 PM, Tyler Gunn
ty...@egunn.com wrote:
I'm not 100% sure what happened with the Canvec
data you uploaded, but it looks like the tags are missing from lot of the ways.
The wooded areas are not showing up because they're not marked natural=wood,
and the watered areas are not showing up water because they're not marked
natural = water.
Were these areas originally relations? Remember that to
select a relation (including the tags) in Josm, you have to double-click on the
relation in the relation list, or select it in the list and click on the dotted
square button, or right-click the relation in Member of and select the
relation. Simply highlighting the way is not sufficient. It sounds like this is
what may have happened.
Adam
___
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] Sinking islands...
Sorry, it will not be possible for the moment. Maybe for an other release. Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Lennard Sent: September 23, 2010 15:57 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Sinking islands... On 23-9-2010 17:28, Bégin, Daniel wrote: - Transform the natural=land areas into points - no merging necessary, no name lost; I'd rather see island names applied to polygons, not points. It would make it much easier in a renderer to decide to show an island's name based on size. -- Lennard ___ 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] CanVec Contour Lines
Hi Michael, Sam It could have been in separated files. However, it is too expensive regarding available resources. I'm using fme workbenches so, I don't have any python script to publish. Daniel -Original Message- From: G. Michael Carter [mailto:mikeycarter1...@gmail.com] On Behalf Of G. Michael Carter Sent: September 29, 2010 11:56 To: Bégin, Daniel Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] CanVec Contour Lines Wasn't sure if I came across right. I was thinking as separate files. Contour lines are not in the OSM, told they will never in there, at one point. Michael On 29/09/10 11:48 AM, Bégin, Daniel wrote: Hi Michael, I understand your need and I did some tests. On average, adding contours means twice the amount of disk space/processing time, generates up to 10 times more .osm files. I'll keep the process as it is now. Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of G. Michael Carter Sent: September 27, 2010 17:26 To: Talk-CA OpenStreetMap Subject: [Talk-ca] CanVec Contour Lines Would it be possible to get the Contour Lines as OSM files? I import them into my GPS from the shp files. Just though it would be nice to have without the manual conversion step I do. If not, no big deal. Just thought I'd ask. Michael ___ 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] Sinking islands...
Cool, So, what should be done for the next release? - Keep the natural=land areas - everybody will have to merge each island to get the proper rendering; - Transform the natural=land areas into points - no merging necessary, no name lost; - Remove the natural=land areas - name will be lost for next release (1); I'm inclided to implement the second proposition - Easier for me and for most of the contributors; Daniel 1- The name should be found in both Canvec Island and Named feature (natural=land areas and place=island points) within the next year. From: G. Michael Carter [mailto:mikeycarter1...@gmail.com] On Behalf Of G. Michael Carter Sent: September 23, 2010 10:48 To: Bégin, Daniel Cc: Talk-CA OpenStreetMap Subject: Re: [Talk-ca] Sinking islands... I've been taking all three objects and merging them. So the inner is natural=wood, with name. http://www.openstreetmap.org/?lat=45.45968lon=-80.42647zoom=16layers=M Seems to be rendering ok. Childs and Osawa are examples. On 23/09/10 10:38 AM, Bégin, Daniel wrote: You are right :-( Two solutions are possible for the next release... - Convert natural=land area into point feature - the easy solution to always keep the name available; - Associate the name to the inner component - If it renders properly. The second one is much more complex (from my side). Can someone try it and send me the conclusion? Daniel From: G. Michael Carter [mailto:mikeycarter1...@gmail.com] On Behalf Of G. Michael Carter Sent: September 23, 2010 10:14 To: Bégin, Daniel Cc: Talk-CA OpenStreetMap Subject: Re: [Talk-ca] Sinking islands... I notice for islands with names the name tag is on the natural=land. On 23/09/10 10:00 AM, Bégin, Daniel wrote: Bonjour Michael, 2010-08-16 11:54 [Talk-ca] Canvec.osm Product - Running! I wrote natural=land area features are a duplicate of natural=water inner polygon. It will be removed for the next release. Point features will still be there. I understand that natural=land has priority in the rendering. Rendering will then move any overlapping features under the natural=land feature. It means you are better remove natural=land area before importing. The standard case for an island is - an inner component of a relation type=multipolygon : natural=water - a polygon : natural=land - a polygon : natural=wood Remove the polygon natural=land and the polygon natural=wood will render properly in the hole created by the inner component of the natural=water multipolygon. Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of G. Michael Carter Sent: September 23, 2010 09:09 To: Talk-CA OpenStreetMap; talk...@openstreetmap.org Subject: [Talk-ca] Sinking islands... I was importing data in the Georgian Bay area and I noticed something. If an island is natural=land it renders in mapnik as white, regardless of the outer multipolygon. if you have natrual=wood or possibly others, it sinks if it's not role=inner. This is at least what I've observed so far. It's rather hard to figure out when the mapnik tiles get cached and don't refresh in a timely fashion. :-) ___ 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] Missing islands and coastline
Hi, From my understanding, natural=coastline is just a way to map large water areas. - The advantage of using this tag is that it can be composed by multiple ways without the need of a relation type=multipolygon or doesn't need that all ways be joined togeter to get a single closed way. - The problem using this tag is that processing is a complicated matter and It has not been updated since several months (!) http://wiki.openstreetmap.org/wiki/Coastline http://wiki.openstreetmap.org/wiki/Coastline_error_checker So, you can delete a coastline without problems as long the way(s) you are deleting create a closed feature (like small island or lake). If you delete a larger coastline (to replace it by a Canvec natural=water polygon for example) you must make sure to join both undeleted coastline extremities to remove all gaps. Actually, for large water area, I find it easier to replace segments of the original coastline with corresponding geometry of the Canvec water feature... - Cut both coastline/Canvec water feature overlapped segments; - Delete the overlapped coastline segment; - Change the natural=water tag of the Canvec segment for natural=coastline; - Join both Canvec segment extremities to the original coastline; - Check for the direction of the coastline. The rule is water on the right. Once every overlapped Coastline/Canvec water feature are replaced, remove unused Canvec segments. Use the Validator (including upload check option) to find problems in the coastline. Hope it helps Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of G. Michael Carter Sent: September 23, 2010 11:56 To: Nakor Cc: talk...@openstreetmap.org; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Missing islands and coastline The mix of natual=water and natural=coastline is because their dual objects. The natural=coastline is needed as the great lakes (as far as I know) is connected to the ocean. So deleting the coastline would delete portions of the Atlantic Ocean. What I'm doing is enclosing the Canadian side of the great lakes, (object http://www.openstreetmap.org/browse/relation/1120169 (which needs to be loaded in sections in JOSM) My reasons: 1. Coastline's need to be complete to render properly. So if your loading Toronto island (Lake Ontario) into a system, you have to pull half the worlds oceans to get it to render properly... as with incomplete data a rendering engine can't till which side contains the water. Having a enclosed relation allows you to pull just that area. 2. It's currently impossible to tell if a coastline object is fully enclosed inside JOSM editing. But if you have a enclosed relation object (with type natural=water) where just one side is the coastline. You can easily tell by downloading the relation (aka 1120169) 3. Naming. Can't name a sting of coastline as easy as a single relation. As for coastlines inland (like Lake Simcoe) make absolutely no sense to me as it's not a coastline. So my thought, if you have a natural=water object that more accurately represents the body of water... use it to replace the interior coastline. But that's just my take... On 22/09/10 12:46 PM, Nakor wrote: Michael, The relation in question is http://www.openstreetmap.org/browse/relation/1124369 but hit a wall here. I cannot modify it (both Potlatch and JOSM time out). Isle Royale (which was my initial concern) is still missing on a couple zoom levels. Before I continue trying to fix this it seems there are a mix of natural=water and natural=coastline for the Great Lakes. I'd like to have this consistent over the Great Lakes but am not sure which one to use. Please comment which one would be better/worse and why? Thanks, N. On 9/20/2010 10:20 AM, G. Michael Carter wrote: It was brought to my attention there was some problems in Lake Superior area, but the problems seem to be all over the great lakes. There's a user, who's name I don't have handy, creating massive relationship objects of the great lakes. I think this might be sinking a lot of the islands. The island objects were last modified by this user in the cases I checked. However, if you refresh the mapnik (aka /dirty) the tiles everything seems to be refreshing ok. Just wanted to let people know.If you find some area underwater refresh the tiles, before investigating. Michael ___ 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] CANVEC 6.0 OSM Files leisure=sport_centre
Thanks John, It will be corrected for the next release this fall. Daniel -Original Message- From: john whelan [mailto:jwhelan0...@gmail.com] Sent: 13 septembre 2010 18:35 To: Bégin, Daniel Cc: Talk-CA OpenStreetMap Subject: CANVEC 6.0 OSM Files leisure=sport_centre I think according to wiki.openstreetmap.org/wiki/Map_Features it should be leisure=sports_centre Cheerio John ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Merging huge wooded areas?
Bonjour Tyler and all, From my own experience, I would strongly recommend not to merge large adjacent wooded (or anything else) areas. Furthermore, If I remember well, Frank Steggink tried the same and he decided to keep distinct relations - no merging. One of the reasons behind Canvec data tiling was editing tools abilities to deal with large polygon - and often complex relations. Even our own systems have sometime hard time to deal with it! Cheers, Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Tyler Gunn Sent: 2 septembre 2010 07:13 To: Talk-Ca Talk-Ca Subject: [Talk-ca] Merging huge wooded areas? Okay, so how is everyone handling huge wooded areas? Take the massive green blob here for an example: http://www.openstreetmap.org/?lat=51.599lon=-101.054zoom=10layers=M It literally spans over an entire NTS tile (062N*). I tried (as much as possible) to ensure all outer/inner members of the wooded area are part of a single relation, but in retrospect that wasn't the right approach as you can still see the lines between the NTS sub-tiles. So I'm thinking in this situation what I really need to do (once the entire extent of this wooded area has been imported) is download the entire area accompanied by the woods, and use the JOIN command in JOSM to merge the smaller wooded areas into one big massive one. The end result would be one HUGE way that traces the entire outside of the wooded area. All of the inside divisions between the tiles would be eliminated, and the end result would be a huge outer way and lots of inner ways. I could then just split up the huge outer way as necessary to make sure no one part of the way is longer than 2000 nodes. Does this sound reasonable? Or am I over-complicating it? Thanks! Tyler -- -- Tyler Gunn ty...@egunn.com ___ 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] Fwd: GeoBase vs CanVec
What is the relationship between CanVec data and GeoBase data? See http://wiki.openstreetmap.org/wiki/CanVec For Road network, CanVec data and GeoBase data are the same with few exceptions... - Attribute names are different, but the content is not. - GeoBase geometry is splitted at province boundaries, Canvec at 50K mapsheet boundaries. Does the CanVec and GeoBase versions carry the same nid? Yes Confirmed - Geobase:addressRangeNid = Canvec:ADRANGENID Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Bégin, Daniel Sent: 1 septembre 2010 09:01 To: Brendan Morley; john whelan Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Fwd: GeoBase vs CanVec Hi Brendan, I haven't checked but they are supposed to be the same Daniel -Original Message- From: Brendan Morley [mailto:morb@beagle.com.au] Sent: 1 septembre 2010 08:33 To: john whelan Cc: Bégin, Daniel; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Fwd: GeoBase vs CanVec On 24/08/2010 1:56 AM, john whelan wrote: The CANVEC tiles contain the full street name. Ottawa has a number of streets that were imported from Geobase that did not include a street name, contained abbreviation or only part of the name. This maybe because of the way the import was done but the CANVEC data seemed cleaner in this regard. Cheerio John For a given street segment, does the CanVec and GeoBase versions carry the same nid? Or can you only match on the Hausdorff distance? (I'm talking about the original data sets, not just the way they were imported into OSM.) Brendan On 21/08/2010 9:52 AM, Brendan Morley wrote: Hello Canadian mappers, Sam Vekemans suggested I ask the following here: What is the relationship between CanVec data and GeoBase data? ___ 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] Coastal water - Canvec
Bonjour Lennard, Few months ago there was a discussion on Talk-CA list about the availability of intermittent coastal water representation in mapnik. Now that the Canvec product (http://wiki.openstreetmap.org/wiki/CanVec) has been made available, there is going to be a lot of intermittent water (http://wiki.openstreetmap.org/wiki/CanVec:_Hydrography_(HD)) uploaded in osm database. As you proposed, I've done the following... 1.) open a trac ticket with component=mapnik Ticket #3188 2.) include one or two link to places where it is used http://www.openstreetmap.org/?lat=50.2095lon=-66.3944zoom=12layers=M : a large coastal bay with intermittent water (could have been tag water=tidal;surface=grass instead of just water=intermittent) http://www.openstreetmap.org/?lat=50.1256lon=-66.6402zoom=14layers=M : a long beach along a coastal intermittent water area (the coastline splitting landform=beach and water=intermittent areas, both having surface=sand). Don't hesitate to contact me to get further explanations Cheers, Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Lennard Sent: 23 février 2010 09:53 To: Talk-CA OpenStreetMap Subject: Re: [Talk-ca] flying rhinoceros [Previously Coastal water (Eau côtière) = Ocean ( Océan )] Bégin wrote: 4.) determine which zoom levels need to render this 5.) attach the icon as an SVG file 16x16 pixel in size 6.) create a patch adding the rules to all the zoomlevels from step #4 Points 4,5,6 are mostly for osmarender. Point 6 is less obvious. I've had a look at the mapnik wiki and did not get the answer I was looking for. Do you have an example of a patch that could do the jobs? I have a personal interest in these coastal features, so I'd say do only points 1 and 2 for mapnik. We'll get it from there. -- Lennard ___ 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] [OpenStreetMap] #3188: Coastal intermittent water representation - Canvec
Lennard, I (now) understand that features are discussed on the wiki but decision are taken on Tagging list. Am I right ?-) I'll write a note on the wiki water_content page, what else should I do to make things properly? Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Lennard Sent: 26 août 2010 14:21 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] [OpenStreetMap] #3188: Coastal intermittent water representation - Canvec On 26-8-2010 20:02, Bégin, Daniel wrote: Well, what can I say? the Canadian community agreed on using water_cover proposal almost a year ago and the entire canadian contry is now available in .osm format using this proposal... What do you think? I'm fine with either schema. We can always retag our NL stuff, so that's not a factor. As far as mapnik is concerned, it also makes no difference either way. It currently treats all natural=wetland the same, so that's not ideal either. Better support for these tags is needed for both tagging schemes. It's just that I was under the impression that wetland=* had won out over water_cover, not just on the wiki (but who reads that thing? :)) and also in practice. A note on the water_cover wiki page that the tagging has been adopted for the CanVec conversion and will start to appear in OSM shortly might be helpful. I don't remember, but has this been on the lists? -- Lennard ___ 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] Intermittent water
Hi folks, Since last year I have been working with the Canadian Osm community to have the entire Canadian 50K map content (Canvec product) available in .osm format. http://wiki.openstreetmap.org/wiki/CanVec The product is now available and is being uploaded in osm database by the Canadian community ... http://www.openstreetmap.org/?lat=44.354lon=-79.343zoom=9layers=M http://www.openstreetmap.org/?lat=50.1841lon=-66.4949zoom=12layers=M The intermittent water tagging schema used was this one http://wiki.openstreetmap.org/wiki/Proposed_features/Water_cover. It was chosen with the community, mainly because it was very similar to the original data schema (Canvec product) but also because the wiki pages were saying that the proposal was still at Draft stage (not deprecate). Can we still have discussion about that and have it approved - even if it is a bit late ?-) Regards, Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] editing a canvect building question
Hi Michael, I can't guaranty anything but I'll try to include it in the process for the next release Daniel -Original Message- From: G. Michael Carter [mailto:mikeycarter1...@gmail.com] On Behalf Of G. Michael Carter Sent: 19 août 2010 10:53 To: Bégin, Daniel Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] editing a canvect building question Would it be possible to get a text file like this: 030L05.osm -8042.4244862 -79.803944142.5 030L11.osm -79.5 42.6160398 -79.144986342.75 Where the columns are GridName, MinLon, MinLat, MaxLon, MaxLat Michael ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec.osm Product - Running!
Bonjour Sam, The total file size is about 17Gb. I would suggest you to wait a bit before copying them all. I've just found that the datasets produced after 10-08-18 06:00:00 doesn't have tags on it. I'm reprocessing them. It sould take less than 24hrs. However the rest of the files are ok. Daniel -Original Message- From: samvekem...@gmail.com [mailto:samvekem...@gmail.com] On Behalf Of Sam Vekemans Sent: 23 août 2010 10:48 To: Bégin, Daniel; Talk-CA OpenStreetMap Subject: Re: [Talk-ca] Canvec.osm Product - Running! hi, Great work! and ahead of schedual too (i think) What is the total file size of the entire canvec-osm.zip file set? i ask as i want to download the entire set for the garminmapset of Canada. thanks, sam On 8/23/10, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Hi all, Actually, Canvec files conversion is completed! - The process ran for 46 days; - 114828 .osm files were created and ... - Compressed into 13117 .zip files If the community import the whole Canvec content, there will be white spaces remaining on the map because some area have never been mapped at 50K scale - around 450 NTS maps are still missing on Ellesmere and Baffin Island. It should be completed within the next few years. Be patient! Next Canvec delivery is planned for this fall, including ... - Updated Road Network for Quebec - Road Network Addressing for Manitoba - Updated hydrography in BC for coastal area Have fun! Daniel Note: French Canvec wiki pages are coming slowly. I still hope to complete them before the end of the summer! English - http://wiki.openstreetmap.org/wiki/CanVec http://wiki.openstreetmap.org/wiki/CanVec French - http://wiki.openstreetmap.org/wiki/FR:CanVec http://wiki.openstreetmap.org/wiki/FR:CanVec -- Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec.osm Product - Running!
Bonjour Adam and all, The listing of all zipped .osm files is now available on ftp site. The listing is updated each time a new .zip file gets available. If a .zip file is replaced, the corresponding information is also replaced. The listing has more than 100 thousands entries (4Mb). The listing can be found at ftp://ftp2.cits.rncan.gc.ca/osm/pub/ZippedOsm.txt It contains the size in bytes, creation date/time and the name of each .osm file. The entries are sorted by creation date/time. Length Date TimeName ... 682094 10-08-17 10:17 057F11.1.osm 916134 10-08-17 10:17 057F11.0.osm 1372948 10-08-17 10:17 057F11.3.osm 2365038 10-08-17 10:17 057F11.2.osm 833421 10-08-17 10:20 057F12.2.osm 972300 10-08-17 10:20 057F12.1.osm 1350751 10-08-17 10:20 057F12.0.osm 644138 10-08-17 10:20 057F12.3.osm 528423 10-08-17 11:07 057F13.0.osm 1099678 10-08-17 11:07 057F13.3.osm 1471351 10-08-17 11:07 057F13.2.osm 571030 10-08-17 11:07 057F13.1.osm Hope it helps Daniel From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Bégin, Daniel Sent: 16 août 2010 15:38 To: Adam Dunn Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canvec.osm Product - Running! Hi Adam, I understand the expected usage but It will not be possible on short terms. However, I will try to create a listing of all .osm files using a time field. If possible, it should be updated at each .zip file creation for the next release - a new .zip file should triggered an update of the listing for each .osm subtitle. Daniel From: Adam Dunn [mailto:dunna...@gmail.com] Sent: 16 août 2010 14:46 To: Bégin, Daniel Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canvec.osm Product - Running! I was intending for the file listing to be sorted alphabetically, while the rss one would be sorted chronologically. Having a timestamp field in the file listing could work though. The advantage to having the RSS/Atom format is that people can plug it into RSS/Atom/xml readers if they use any. Adam On Mon, Aug 16, 2010 at 9:27 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Bonjour Adam, About point 1... I'll see what can be done and, if possible, I will produce it for this release. About point 2... If the text file proposed on point 1 have a date and time field, you could get all the information you are looking for in a single .txt file. Am I right? Cheers, Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Over-classification of rural roads in Canvec data?
Tyler, James, FYI, NRN roads are more up to date than anything found in the MLI 20K seamless maps. The 1:20 000 topographic data was compiled from 1989 to 2001 and has not since then been edited. Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Tyler Gunn Sent: 16 août 2010 07:08 To: James Ewen Cc: Talk-Ca Subject: Re: [Talk-ca] Over-classification of rural roads in Canvec data? On further reflection I'm going to re-classify my down-graded tertiaries back to tertiary. The entire Canvec dataset is this way, so we might as well keep the country consistent. It's such a minor point really in my mind, why make things over complicated. Tyler ___ 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] Canvec.osm Product - Running!
Hi all, an update on product conversion. So far ... - The process have been running for 42 days; - 11415 files have been processed - an average of 270 files a day; To come this week ... - 052A06 - The rest of the files Miscellaneous ... natural=peak It was supposed to be there but obviously it is not. I'll find the problem and it will be included in the next release. natural=land area features are a duplicate of natural=water inner polygon. It will be removed for the next release. Point features will still be there. Canvec Product Description - Features, geometry and tiling description: http://wiki.openstreetmap.org/wiki/CanVec French Canvec wiki pages I still hope to produce it before the end of the summer! Cheers, Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec.osm Product - Running!
Bonjour Adam, About point 1... I'll see what can be done and, if possible, I will produce it for this release. About point 2... If the text file proposed on point 1 have a date and time field, you could get all the information you are looking for in a single .txt file. Am I right? Cheers, Daniel From: Adam Dunn [mailto:dunna...@gmail.com] Sent: 16 août 2010 12:08 To: Bégin, Daniel Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canvec.osm Product - Running! For the next release, would it be possible to get: 1. A text file (stored on the ftp) that lists all the quadtree-tiles output. Some people might want to write scripts that can do work based on available CanVec osm files, but it would help to know how much subdividing occurred. Currently, we must download the zip file to determine if 092H04.0.1.2 exists or if the tiling stopped at 092H04.0.1. 2. An RSS or Atom feed of the tiles that have been processed. Not as useful as (1), but some people might be interested in knowing the latest without searching around the ftp. This would be most useful when already processed tiles get re-processed, or when tiles get processed in a different order (such as 052A06). Thanks for the great releases! Adam On Mon, Aug 16, 2010 at 8:53 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Hi all, an update on product conversion. So far ... - The process have been running for 42 days; - 11415 files have been processed - an average of 270 files a day; To come this week ... - 052A06 - The rest of the files Miscellaneous ... natural=peak It was supposed to be there but obviously it is not. I'll find the problem and it will be included in the next release. natural=land area features are a duplicate of natural=water inner polygon. It will be removed for the next release. Point features will still be there. Canvec Product Description - Features, geometry and tiling description: http://wiki.openstreetmap.org/wiki/CanVec French Canvec wiki pages I still hope to produce it before the end of the summer! Cheers, Daniel ___ 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] Canvec.osm Product - Running!
Hi Adam, I understand the expected usage but It will not be possible on short terms. However, I will try to create a listing of all .osm files using a time field. If possible, it should be updated at each .zip file creation for the next release - a new .zip file should triggered an update of the listing for each .osm subtitle. Daniel From: Adam Dunn [mailto:dunna...@gmail.com] Sent: 16 août 2010 14:46 To: Bégin, Daniel Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Canvec.osm Product - Running! I was intending for the file listing to be sorted alphabetically, while the rss one would be sorted chronologically. Having a timestamp field in the file listing could work though. The advantage to having the RSS/Atom format is that people can plug it into RSS/Atom/xml readers if they use any. Adam On Mon, Aug 16, 2010 at 9:27 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Bonjour Adam, About point 1... I'll see what can be done and, if possible, I will produce it for this release. About point 2... If the text file proposed on point 1 have a date and time field, you could get all the information you are looking for in a single .txt file. Am I right? Cheers, Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Canvec.osm Product - Running!
Hi all, an update on product conversion. So far ... - The process have been running for 22 days; - 6021 files have been processed - an average of 300 files a day; To come this week ... - Yukon and Northwest territories To come later ... The rest of the 13116 Canvec files Miscellaneous ... Duplicated vegetation was found on 337 original Canvec.gml files. - see attached - Original Canvec.gml files have been replaced; - Osm version will be reprocessed this week; XY coordinates swap was found on 366 original Canvec.gml files. - see attached - Original Canvec.gml files have been replaced; - Osm version will be reprocessed this week; Canvec Product Description - Features, geometry and tiling description: http://wiki.openstreetmap.org/wiki/CanVec Tag value set to -1 - Means that the value is not know by the provider (usually the provincial government) Cheers, Daniel 012I13 012J09 012J16 012P04 013I10 015D04 015M13 016F13 021G05 024O01 025C06 025E11 025E13 025I05 025J09 026A10 026E09 026F06 026P04 026P05 027B05 027B14 027D06 027G03 033D05 033M02 034M07 034M08 035M09 035M10 035N14 036D01 036D08 036G16 036H13 036I05 036I12 036I14 036J08 036P11 037B02 037G16 038B16 038C02 038C03 038C10 038C12 042J04 042J05 042J06 042J09 042J10 042J11 042J12 042J13 042J14 042J16 042K12 042P09 043A02 043A06 043A11 043A12 043A13 043G01 043G09 043O03 043O06 043O07 044D03 044I02 045I13 045M09 045N04 045O02 045O12 045P09 046I14 046J02 046J03 046J07 046N14 046P03 046P11 046P13 047D10 048C03 048C07 048C08 048C09 048C16 048D03 048D06 048D07 048D10 048D16 048E06 048G09 049A11 049A12 049C02 049C03 049C05 053O06 053O11 053O12 053O13 053O16 054B02 054B04 054B13 054F08 054F09 054L03 055J10 055M11 056I05 056J08 057D11 057E12 057H09 058A01 058C02 058C06 058C07 058C08 058C09 058C10 058C11 058C15 058D05 058D06 058D07 058D11 058G03 058G08 058G14 058H11 059B03 059B04 063E13 063G07 063G08 064K06 067D05 068B06 068F16 069B05 069B06 069B12 069C04 069G06 069H12 073O11 074C01 074C04 074C13 074F02 074F04 074F09 074F12 074F13 074F15 074F16 074K01 074K07 074K08 077B13 078B14 078B16 078C03 079A02 079A03 079A08 079B04 079C06 079C11 079C14 079C15 079D09 079D14 079D15 079F03 079F04 079F06 082B16 084I11 084O14 084P06 084P11 085A15 085G04 085J02 085K14 085L09 085M12 087B01 087F07 087G08 087G13 087H10 088B04 088D01 088D02 088D13 088E11 088E13 088F01 088F02 088F06 088F07 088G02 088G07 088G10 088G16 088H02 088H03 088H15 089A07 089A08 089A10 089A12 089A15 089B02 089D02 089D04 089E01 089E04 092A13 092G16 094F07 094F11 095D06 095D15 095G05 095G06 095L09 095L12 095L13 095M07 095M11 096D02 096D03 096D04 096D05 096D06 096D07 096D08 096D12 096E15 096G09 096H14 096I16 096P14 096P16 097H04 098B15 098F07 098H09 098H10 099A04 099D01 102I14 104L16 104M02 104M06 105D12 105D15 105F04 105F05 105F08 105G05 105G07 105G08 105N03 105N08 105N16 105O11 105O14 106A01 106A05 106A07 106A08 106A09 106A10 106A13 106A14 106A15 106A16 106B01 106B02 106B04 106B05 106B06 106B09 106B10 106B11 106B13 106B14 106B15 106B16 106E02 106E04 106E05 106E08 106E09 106F16 106G01 106H04 106L05 107C02 114O08 115B02 115B06 115C01 115C08 115G08 115G09 115G14 115G15 116C14 116C16 116F07 116F09 116F11 116F14 116F15 116F16 116G02 116G03 116G04 116G05 116G06 116G10 116G11 116G12 116G13 116G14 116H01 116H02 116H04 116H05 116H08 116I08 116J03 116J04 116K01 116K02 116K03 116K06 116K07 116K11 116K15 117A09 117B15 117D01 117D11 120C09 120D13 120E13 120F07 120F16 120G03 340E09 340E15 340E16001K11 001K12 001K13 001K14 001K15 001L13 001L14 001L16 001M01 001M03 001M04 001M05 001M06 001M07 001M08 001M09 001M10 001M11 001M12 001M13 001M14 001M15 001M16 001N02 001N04 001N05 001N06 001N07 001N11 001N13 001N14 001N15 002C02 002C03 002C04 002C05 002C06 002C10 002C11 002C13 002D02 002D04 002D05 002D08 002D09 002D10 002D11 002D12 002D13 002D14 002D15 002D16 002E01 002E02 002E03 002E04 002E05 002E06 002E07 002E08 002E09 002E10 002E11 002E12 002E13 002E14 002F03 002F04 002F05 002F06 002F12 002L04 002L11 002L12 002L13 002L14 002M04 002M05 002M06 002M11 002M12 002M13 003D04 003D05 003D12 003D13 003E04 003E05 011C13 011D05 011D10 011D11 011D13 011D14 011D15 011D16 011E01 011E02 011E03 011E04 011E05 011E06 011E07 011E08 011E09 011E10 011E11 011E12 011E13 011E14 011E15 011E16 011F03 011F04 011F05 011F06 011F07 011F09 011F10 011F11 011F12 011F13 011F14 011F15 011F16 011G13 011J04 011K01 011K02 011K03 011K04 011K05 011K06 011K07 011K08 011K09 011K10 011K11 011K15 011K16 011L01 011L02 011L03 011L04 011L05 011L06 011L07 011L08 011L11 011L12 011L13 011M01 011M04 011M08 011N01 011N02 011N04 011N05 011N11 011N12 011N13 011N14 011O09 011O10 011O11 011O14 011O15 011O16 011P08 011P09 011P10 011P11 011P12 011P13 011P14 011P15 011P16 012A01 012A02 012A03 012A04 012A05 012A06 012A07 012A08 012A09 012A10 012A11 012A12 012A13 012A14 012A15 012A16 012B01 012B02 012B03 012B06 012B07 012B08 012B09 012B10 012B11 012B15 012B16 012E01 012E02 012E03 012E05 012E06 012E07 012E08 012E09 012E10 012E11 012E12 012E13 012E14 012F04 012F05
Re: [Talk-ca] Converted Stats Can Boundaries files.
I agree with Richard, Here is more information... The first Osm Canadian/Provinces/Territories boundaries were imported from GeoBase in 2008 - actually the original contributor just confirmed me. These imported GeoBase boundaries were, and still being used, for GeoBase products definition - NRN, NHN, ... I understand that one of the primary objective for StatCan, creating similar boundaries, is to make census field work easier - not necessarily geometrically accurate! So, their boundaries might be different from GeoBase boundaries - and Osm - because it serves another purpose. The same applies to many georeferenced StatCan products, like Road Network ... Regards, Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Richard Weait Sent: 23 juillet 2010 12:37 To: Talk-CA OpenStreetMap Subject: Re: [Talk-ca] Converted Stats Can Boundaries files. On Fri, Jul 23, 2010 at 10:50 AM, Sam Vekemans acrosscanadatra...@gmail.com wrote: hi talk-ca, because it is an entire complex web of relations, were 1 way has 2 or more relations attached to it, i'd recomment the solution on the wiki, if we want to preserve the rule that all bountaries need to be relations. then the 1st task is the look at the povince file, and remove the existing boundary data that will cause duplicate ways. I presume you mean keep the existing data and don't use the duplicate data from the file. then once each province is all clear, then 1 person can upload it all at once. Come on now, you aren't really suggesting removing existing boundary data just to add it back in, are you? That doesn't sound very considerate of the previous mappers. Have you looked at the relative technical merits of the existing boundary data and the StatsCan data Tyler just converted? Are they from the same source, or is one of provably lower quality? How about starting with a smaller test than a complete province? Would anyone care to take a look at their neigbourhood and the related and adjacent boundaries? ___ 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] Canvec.osm Product - Running!
Hi all, an update on product conversion. So far ... - The process have been running for 22 days; - 6021 files have been processed - an average of 300 files a day; To come this week ... - Yukon and Northwest territories To come later ... The rest of the 13116 Canvec files Miscellaneous ... Duplicated vegetation was found on 337 original Canvec.gml files. - see attached - Original Canvec.gml files have been replaced; - Osm version will be reprocessed this week; XY coordinates swap was found on 366 original Canvec.gml files. - see attached - Original Canvec.gml files have been replaced; - Osm version will be reprocessed this week; Canvec Product Description - Features, geometry and tiling description: http://wiki.openstreetmap.org/wiki/CanVec Tag value set to -1 - Means that the value is not know by the provider (usually the provincial government) Cheers, Daniel 012I13 012J09 012J16 012P04 013I10 015D04 015M13 016F13 021G05 024O01 025C06 025E11 025E13 025I05 025J09 026A10 026E09 026F06 026P04 026P05 027B05 027B14 027D06 027G03 033D05 033M02 034M07 034M08 035M09 035M10 035N14 036D01 036D08 036G16 036H13 036I05 036I12 036I14 036J08 036P11 037B02 037G16 038B16 038C02 038C03 038C10 038C12 042J04 042J05 042J06 042J09 042J10 042J11 042J12 042J13 042J14 042J16 042K12 042P09 043A02 043A06 043A11 043A12 043A13 043G01 043G09 043O03 043O06 043O07 044D03 044I02 045I13 045M09 045N04 045O02 045O12 045P09 046I14 046J02 046J03 046J07 046N14 046P03 046P11 046P13 047D10 048C03 048C07 048C08 048C09 048C16 048D03 048D06 048D07 048D10 048D16 048E06 048G09 049A11 049A12 049C02 049C03 049C05 053O06 053O11 053O12 053O13 053O16 054B02 054B04 054B13 054F08 054F09 054L03 055J10 055M11 056I05 056J08 057D11 057E12 057H09 058A01 058C02 058C06 058C07 058C08 058C09 058C10 058C11 058C15 058D05 058D06 058D07 058D11 058G03 058G08 058G14 058H11 059B03 059B04 063E13 063G07 063G08 064K06 067D05 068B06 068F16 069B05 069B06 069B12 069C04 069G06 069H12 073O11 074C01 074C04 074C13 074F02 074F04 074F09 074F12 074F13 074F15 074F16 074K01 074K07 074K08 077B13 078B14 078B16 078C03 079A02 079A03 079A08 079B04 079C06 079C11 079C14 079C15 079D09 079D14 079D15 079F03 079F04 079F06 082B16 084I11 084O14 084P06 084P11 085A15 085G04 085J02 085K14 085L09 085M12 087B01 087F07 087G08 087G13 087H10 088B04 088D01 088D02 088D13 088E11 088E13 088F01 088F02 088F06 088F07 088G02 088G07 088G10 088G16 088H02 088H03 088H15 089A07 089A08 089A10 089A12 089A15 089B02 089D02 089D04 089E01 089E04 092A13 092G16 094F07 094F11 095D06 095D15 095G05 095G06 095L09 095L12 095L13 095M07 095M11 096D02 096D03 096D04 096D05 096D06 096D07 096D08 096D12 096E15 096G09 096H14 096I16 096P14 096P16 097H04 098B15 098F07 098H09 098H10 099A04 099D01 102I14 104L16 104M02 104M06 105D12 105D15 105F04 105F05 105F08 105G05 105G07 105G08 105N03 105N08 105N16 105O11 105O14 106A01 106A05 106A07 106A08 106A09 106A10 106A13 106A14 106A15 106A16 106B01 106B02 106B04 106B05 106B06 106B09 106B10 106B11 106B13 106B14 106B15 106B16 106E02 106E04 106E05 106E08 106E09 106F16 106G01 106H04 106L05 107C02 114O08 115B02 115B06 115C01 115C08 115G08 115G09 115G14 115G15 116C14 116C16 116F07 116F09 116F11 116F14 116F15 116F16 116G02 116G03 116G04 116G05 116G06 116G10 116G11 116G12 116G13 116G14 116H01 116H02 116H04 116H05 116H08 116I08 116J03 116J04 116K01 116K02 116K03 116K06 116K07 116K11 116K15 117A09 117B15 117D01 117D11 120C09 120D13 120E13 120F07 120F16 120G03 340E09 340E15 340E16001K11 001K12 001K13 001K14 001K15 001L13 001L14 001L16 001M01 001M03 001M04 001M05 001M06 001M07 001M08 001M09 001M10 001M11 001M12 001M13 001M14 001M15 001M16 001N02 001N04 001N05 001N06 001N07 001N11 001N13 001N14 001N15 002C02 002C03 002C04 002C05 002C06 002C10 002C11 002C13 002D02 002D04 002D05 002D08 002D09 002D10 002D11 002D12 002D13 002D14 002D15 002D16 002E01 002E02 002E03 002E04 002E05 002E06 002E07 002E08 002E09 002E10 002E11 002E12 002E13 002E14 002F03 002F04 002F05 002F06 002F12 002L04 002L11 002L12 002L13 002L14 002M04 002M05 002M06 002M11 002M12 002M13 003D04 003D05 003D12 003D13 003E04 003E05 011C13 011D05 011D10 011D11 011D13 011D14 011D15 011D16 011E01 011E02 011E03 011E04 011E05 011E06 011E07 011E08 011E09 011E10 011E11 011E12 011E13 011E14 011E15 011E16 011F03 011F04 011F05 011F06 011F07 011F09 011F10 011F11 011F12 011F13 011F14 011F15 011F16 011G13 011J04 011K01 011K02 011K03 011K04 011K05 011K06 011K07 011K08 011K09 011K10 011K11 011K15 011K16 011L01 011L02 011L03 011L04 011L05 011L06 011L07 011L08 011L11 011L12 011L13 011M01 011M04 011M08 011N01 011N02 011N04 011N05 011N11 011N12 011N13 011N14 011O09 011O10 011O11 011O14 011O15 011O16 011P08 011P09 011P10 011P11 011P12 011P13 011P14 011P15 011P16 012A01 012A02 012A03 012A04 012A05 012A06 012A07 012A08 012A09 012A10 012A11 012A12 012A13 012A14 012A15 012A16 012B01 012B02 012B03 012B06 012B07 012B08 012B09 012B10 012B11 012B15 012B16 012E01 012E02 012E03 012E05 012E06 012E07 012E08 012E09 012E10 012E11 012E12 012E13 012E14 012F04 012F05 012G01
Re: [Talk-ca] Converted Stats Can Boundaries files.
Sorry Sam, I don't want to argue with anybody. I wrote ... I agree with Richard, ... because Richard's comments were based on commonly agreed Osm rules. The rest of the email was just information, no arguments. Regards, Daniel -Original Message- From: samvekem...@gmail.com [mailto:samvekem...@gmail.com] On Behalf Of Sam Vekemans Sent: 27 juillet 2010 12:34 To: Bégin, Daniel; Talk-CA OpenStreetMap; Tyler Gunn; Michel Gilbert Subject: Re: [Talk-ca] Converted Stats Can Boundaries files. hi, i'll counter that argument with this. Tyler converted each province as separate .osm files. michel gilbert did a great job at converting the province boundaries and importing. note: it was only 1 person who imported all provincial boundaries. its commonly agreed that boundaries, and the enire 'boundary web' should actually consist of only 1 strand for each boundary line. think of it like a spiders web. if you were to paint inside each 'whole' you actually go over each strand 2 or more times in the process. unlike the whysical world, where thereis a boundary line, its clear that on 1 side is the municapality of 1 area and the other is of the next town/area. there needs not to be a 'nutral zone'. however, those rules are not set in stone, all boundaries dont need to be a relation, i prefer that the lowest boundary level (local community) gets mapped as polygons, then the next level up gets mapped as relations, so it just uses the same 'strand' Complexity which is better? On 7/27/10, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: I agree with Richard, Here is more information... The first Osm Canadian/Provinces/Territories boundaries were imported from GeoBase in 2008 - actually the original contributor just confirmed me. These imported GeoBase boundaries were, and still being used, for GeoBase products definition - NRN, NHN, ... I understand that one of the primary objective for StatCan, creating similar boundaries, is to make census field work easier - not necessarily geometrically accurate! So, their boundaries might be different from GeoBase boundaries - and Osm - because it serves another purpose. The same applies to many georeferenced StatCan products, like Road Network ... Regards, Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Richard Weait Sent: 23 juillet 2010 12:37 To: Talk-CA OpenStreetMap Subject: Re: [Talk-ca] Converted Stats Can Boundaries files. On Fri, Jul 23, 2010 at 10:50 AM, Sam Vekemans acrosscanadatra...@gmail.com wrote: hi talk-ca, because it is an entire complex web of relations, were 1 way has 2 or more relations attached to it, i'd recomment the solution on the wiki, if we want to preserve the rule that all bountaries need to be relations. then the 1st task is the look at the povince file, and remove the existing boundary data that will cause duplicate ways. I presume you mean keep the existing data and don't use the duplicate data from the file. then once each province is all clear, then 1 person can upload it all at once. Come on now, you aren't really suggesting removing existing boundary data just to add it back in, are you? That doesn't sound very considerate of the previous mappers. Have you looked at the relative technical merits of the existing boundary data and the StatsCan data Tyler just converted? Are they from the same source, or is one of provably lower quality? How about starting with a smaller test than a complete province? Would anyone care to take a look at their neigbourhood and the related and adjacent boundaries? ___ 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 -- Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Converted Stats Can Boundaries files.
Hi Michael, you are right - for the moment, because ... It should be available on GeoBase before the end of summer - or soon after !-) - Administrative boundaries/names for levels 6-8; - Geometries provided by local authorities, except for AB; About accuracy comparison with StatCan... The accuracy could be/not be the same, I haven't check yet. It depends on StatCan data provider, but I know they are legitimately not targeting accuracy. Daniel From: Michael Barabanov [mailto:michael.baraba...@gmail.com] Sent: 27 juillet 2010 16:28 To: Bégin, Daniel Cc: Talk-CA OpenStreetMap Subject: Re: [Talk-ca] Converted Stats Can Boundaries files. Answering my own question.. no, doesn't seem like GeoBase contains boundaries for cities (http://www.geobase.ca/geobase/en/data/admin/index.html). So StatsCan seems to be the only source of vector data for this? On Tue, Jul 27, 2010 at 11:56 AM, Michael Barabanov michael.baraba...@gmail.com wrote: Hi Daniel, Are you saying that GeoBase actually contains (let's say) city boundaries/names, and those are probably geometrically more accurate? On Tue, Jul 27, 2010 at 7:59 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: I agree with Richard, Here is more information... The first Osm Canadian/Provinces/Territories boundaries were imported from GeoBase in 2008 - actually the original contributor just confirmed me. These imported GeoBase boundaries were, and still being used, for GeoBase products definition - NRN, NHN, ... I understand that one of the primary objective for StatCan, creating similar boundaries, is to make census field work easier - not necessarily geometrically accurate! So, their boundaries might be different from GeoBase boundaries - and Osm - because it serves another purpose. The same applies to many georeferenced StatCan products, like Road Network ... Regards, Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Richard Weait Sent: 23 juillet 2010 12:37 To: Talk-CA OpenStreetMap Subject: Re: [Talk-ca] Converted Stats Can Boundaries files. On Fri, Jul 23, 2010 at 10:50 AM, Sam Vekemans acrosscanadatra...@gmail.com wrote: hi talk-ca, because it is an entire complex web of relations, were 1 way has 2 or more relations attached to it, i'd recomment the solution on the wiki, if we want to preserve the rule that all bountaries need to be relations. then the 1st task is the look at the povince file, and remove the existing boundary data that will cause duplicate ways. I presume you mean keep the existing data and don't use the duplicate data from the file. then once each province is all clear, then 1 person can upload it all at once. Come on now, you aren't really suggesting removing existing boundary data just to add it back in, are you? That doesn't sound very considerate of the previous mappers. Have you looked at the relative technical merits of the existing boundary data and the StatsCan data Tyler just converted? Are they from the same source, or is one of provably lower quality? How about starting with a smaller test than a complete province? Would anyone care to take a look at their neigbourhood and the related and adjacent boundaries? ___ 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] Canvec Product - Warnings
Hello again, Two warnings about data transferred... 1- Someone have found that the vegetation is duplicated in some files. This is a problem with the original Canvec.gml product. As soon the scope of the problem is identified and the original product corrected, the .osm files will be replaced. 2- Polygons with tag natural=land are translated from Canvec/GeoBase features Island. These features are copies of surrounding waterbody's inner ways. It could be removed without loosing any relevant information. It will not be part of the next release. Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CANVEC data for Ottawa
For all, If you don't know how to get Canvec files, you can use the link provided in Osm wiki under Canvec Product - Datasets http://wiki.openstreetmap.org/wiki/CanVec Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of john whelan Sent: 17 juillet 2010 12:28 To: Talk-CA OpenStreetMap Subject: [Talk-ca] CANVEC data for Ottawa How do I find it and is it available yet? I suspect it isn't. Thanks John ___ 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] CANVEC data for Ottawa
Hi Michael, The situation you describe affects only BC watersheds that touches the Ocean - manual operations are needed to adjust GeoBase Data. GeoBase data should be integrated to Canvec product for the next release. Daniel From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Michael Barabanov Sent: 17 juillet 2010 13:07 To: Sam Vekemans Cc: Talk-CA OpenStreetMap Subject: Re: [Talk-ca] CANVEC data for Ottawa One word of caution on Canvec: at least for streams and lakes, I found that NHN has better data around the area where I live. Before copying these from Canvec, I'd advise checking NHN for the area. On Sat, Jul 17, 2010 at 9:34 AM, Sam Vekemans acrosscanadatra...@gmail.com wrote: Hi, Yes 031G05 ftp://ftp2.cits.rncan.gc.ca/osm/pub/031/G/ is here ftp://ftp2.cits.rncan.gc.ca/osm/pub/031/G/031G05.zip Cheers, Sam Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails On Sat, Jul 17, 2010 at 9:28 AM, john whelan jwhelan0...@gmail.com wrote: How do I find it and is it available yet? I suspect it isn't. Thanks John ___ 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] User sundance
Hi Tyler, Next Canvec Release will contain MB addressing - name and karlsruhe schema - for areas you won't have time to copy tags in josm. Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of ty...@egunn.com Sent: 18 juillet 2010 11:37 To: talk-ca@openstreetmap.org Subject: [Talk-ca] User sundance I heard back from user Sundance. He is indeed legit and was using yahoo to get a rough sketch of the roads in rural mb.So I don't think he's a continuation of vreimer. Speaking of vreimer; glad to have canvec now as most of rural mb was added by vreimer. The unfortunate part is that canvec data has no names so to do a proper replacement of his data with canvec I'll have to copy the names of small town streets from stats can. Not so bad as I converted stats can nrn to a series ways with just name and name:source tags to make copying tags in josm easier Aaaanywho... Sent from my iPhone ___ 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] ArcGis
Hi guys, ArcGis - a big player in GIS softwares - is introducing an add-in to connect and edit Osm data as done with Merkator or Josm http://geo.geek.nz/development/arcgis-10-editing-add-in-for-openstreetmap/?utm_source=feedburnerutm_medium=feedutm_campaign=Feed%3A+mandown+%28geo.geek.nz%29 Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec.osm Product - Running!
Hi all, an update on canvec.osm conversion Last Monday I wrote: To come this week ... - MB, SK, AB and BC (southern part of each province) It should be completed today :-) Next to come: latitudes 52.0 to 56.0, from east to west. Cheers, Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Bégin, Daniel Sent: 12 juillet 2010 11:30 To: James Ewen Cc: Talk-CA OpenStreetMap Subject: Re: [Talk-ca] Canvec.osm Product - Running! Ooops! Sorry James - and other westerners (lol), I wrote: To come this week ... - MA, SK, AL and BC southern part I mean: - MB, SK, AB and BC (southern part of each province) Cheers Daniel -Original Message- From: James Ewen [mailto:ve6...@gmail.com] Sent: 12 juillet 2010 10:05 To: Bégin, Daniel Subject: Re: [Talk-ca] Canvec.osm Product - Running! On Mon, Jul 12, 2010 at 4:46 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: To come this week ... - MA, SK, AL and BC southern part Look at that... those nasty government types out east are going to convert Canvec data for Massachusets and Alabama, leaving out Manitoba and Alberta! sniff sniff No wonder we always feel left out and unappreciated! Daniel: a GIS geek that doesn't know his two letter provincial abbreviations? For shame! 8) James VE6SRV PS if you had screwed up the two letter abbreviation for British Columbia, we would have had to slap you! ___ 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] FW: 001K11 area
I all, I understand that the problem on 001K11 area extents to 011Kxx and 011Lxx. The problem is fixed and the files will be reprocessed (except 001k11 001k12 001k13 that have already been reprocessed) Daniel -Original Message- From: Bégin, Daniel Sent: 6 juillet 2010 16:59 To: 'Sam Vekemans'; Talk-CA OpenStreetMap Subject: RE: 001K11 area Salut tous le monde, 001k11 001k12 001k13 will be reprocessed. There was an error in the Canvec to Osm tag conversion that we didn't see in the samples. We are correcting the conversion process and it will return to the normal around 17:00 Sherbrooke time. Daniel -Original Message- From: samvekem...@gmail.com [mailto:samvekem...@gmail.com] On Behalf Of Sam Vekemans Sent: 6 juillet 2010 12:48 To: Bégin, Daniel; Talk-CA OpenStreetMap Subject: Re: 001K11 area Correction, The only effects the 001k11 001k12 001k13 areas. All the other ones seem fine. I put a not on it in my file version. Thanks, Sam On Tue, Jul 6, 2010 at 9:17 AM, Sam Vekemans acrosscanadatra...@gmail.com wrote: Hi, Im just looking at the 001k11 area and i j see a few features nodes that say 'natural=land', and So i think there must be an error somewhere. Looking at 001k14 area, and the canvec.osm files seem fine. :) Thanks, Sam Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] JOSM Difference?
Bonjour, I agree with Sam, no easy way to do the job in Josm :-( However, I previously wrote ([Talk-ca] Canvec.osm Future): Canvec and Openstreetmap data will be compared to find differences between them [... Snip ...] future versions of Canvec, including Omission and Commission files, will be made available for Osm community. This means NRCan has a process that do it for roads. We will start to compare datasets this fall. The differences found will be made available on the ftp site as - Commission files (what is in Canvec but not in OSM); - Omission files (what is in Osm but not in Canvec); This process will be much longer that the current conversion process !-) We will start with few provinces - roads only. If it goes right, we will expand it to all provinces and themes. I will keep you informed Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Sam Vekemans Sent: 6 juillet 2010 21:08 To: G. Michael Carter; Talk-CA OpenStreetMap Subject: Re: [Talk-ca] JOSM Difference? Nope :) Painfull copy/paste. And hide/show canvec.osm layer to see whats missing. I just work in a small corner of the tile and work my way around, deleting the copied in features from the canvec.osm file as i go, and save this 'smaller version' locally on my computer as a working copy. The Validator Plugin also helps, Sam On 7/6/10, G. Michael Carter mi...@carterfamily.ca wrote: Is there any way to apply a minus on the OSM files? ie: Select a CanVec grid, and open in JOSM. Then click a download button and it removes any object which are identical? ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca -- Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails ___ 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] Priority on OSM/CanVec
Hi folks, The priorities will be changed before 14:00 (Sherbrooke time). First in-First out priority !-) 062Hxx, 062Ixx, 062Nxx, 031Cxx, 031Dxx, 031Exx , 031Fxx, 041Hxx, 041Lxx, and the rest of the data as scheduled Daniel From: samvekem...@gmail.com [mailto:samvekem...@gmail.com] On Behalf Of Sam Vekemans Sent: 6 juillet 2010 11:21 To: G. Michael Carter; Bégin, Daniel; Tyler Gunn Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Priority on OSM/CanVec Hi Daniel, Tyler Mikey, et all You might want to email Daniel directly :) It looks like the process is going very well. And seems to be going in a full NTS tile area at a time. You can tell from the 'Last Modified date' in the directory ftp://ftp2.cits.rncan.gc.ca/osm/pub/ Its important to be making sure that the data that is converted is correct. So converting without actually being their watching the process ie. if server times out as many are trying to download it at once :-) So we dont want to have fragmented files made available :) Or at least thats what i'm noticing when making these Garmin Maps. Cheers, Sam P.S. And there was also a hint/request from Adam for the rest of 092G and 092H (for the lower mainland Vancouver area) On Tue, Jul 6, 2010 at 7:36 AM, Tyler Gunn ty...@egunn.com wrote: If we're talking priority, then I'd love to see more of Manitoba, specifically these areas I'm very familiar with: 062H - Winnipeg 062I - Gimli 062N - Dauphin area Thanks! Tyler ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca On Tue, Jul 6, 2010 at 7:29 AM, G. Michael Carter mi...@carterfamily.ca wrote: Could I get a higher priority on: 031 C - Bon Echo PP area 031 D - Barrie 031 E - Algonquin 031 F - Algonquin 041 H - Parry Sound 041 L - Killarney PP area Thanks, Michael -- G. Michael Carter Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F: 1-519-941-0009 Google Talk: xmpp:mikeycarter1...@gmail.com http://www.openstreetmap.org/?lat=43.9216lon=-80.105zoom=14layers=B000FTF http://livedvd.carterfamily.ca/ ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca osm_logo.resized.pngfedora.png___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Accuracy of CanVec vs Yahoo?
Bonjour Michael About accuracy: Canvec should usually be better than 10m (90%) for road network and 30m for other features. We know that Yahoo imagery often have offsets. However, you better have plenty of gps tracks to take a decision. By the way, there is no park boundaries in Canvec product -for the moment. About contents: Yahoo imagery is usually more up-to-date than Canvec - except for road network and for hydrography in some provinces. I agree with Richard, the details always matter. You may sometime have to choose between accuracy and completeness... Daniel From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of G. Michael Carter Sent: 6 juillet 2010 12:12 To: talk-ca@openstreetmap.org Subject: [Talk-ca] Accuracy of CanVec vs Yahoo? When importing the data do we favour yahoo existing data in OSM (which is obviously traced from satellite imagery) or CanVec? I'm assuming CanVec for parks would be based on official park boundaries rather than yahoo, line of site on open spaces. So parks would be better coming from CanVec. But what about buildings? Mikey -- G. Michael Carter Contact: H: 1-519-940-8935 | W: 1-905-267-8494 | M: 1-519-215-1869 | F: 1-519-941-0009 Google Talk: xmpp:mikeycarter1...@gmail.com http://www.openstreetmap.org/?lat=43.9216lon=-80.105zoom=14layers=B000FTF http://livedvd.carterfamily.ca/ osm_logo.resized.pngfedora.png___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] 001K11 area
Salut tous le monde, 001k11 001k12 001k13 will be reprocessed. There was an error in the Canvec to Osm tag conversion that we didn't see in the samples. We are correcting the conversion process and it will return to the normal around 17:00 Sherbrooke time. Daniel -Original Message- From: samvekem...@gmail.com [mailto:samvekem...@gmail.com] On Behalf Of Sam Vekemans Sent: 6 juillet 2010 12:48 To: Bégin, Daniel; Talk-CA OpenStreetMap Subject: Re: 001K11 area Correction, The only effects the 001k11 001k12 001k13 areas. All the other ones seem fine. I put a not on it in my file version. Thanks, Sam On Tue, Jul 6, 2010 at 9:17 AM, Sam Vekemans acrosscanadatra...@gmail.com wrote: Hi, Im just looking at the 001k11 area and i j see a few features nodes that say 'natural=land', and So i think there must be an error somewhere. Looking at 001k14 area, and the canvec.osm files seem fine. :) Thanks, Sam Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec edition 6.0 GMLs, projections and lat/long axis order
Hi all, It has no influence on the Canvec.osm product. Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Gerald Sent: 5 juillet 2010 14:04 To: talk-ca@openstreetmap.org Subject: [Talk-ca] CanVec edition 6.0 GMLs,projections and lat/long axis order A month ago Brendan wrote The only problem is that ogr2ogr doesn't seem to recognise the GML coordinates are coming in latitude-longitude (Y,X) order. . . . Today Natural Resources Canada told me After verification it seem like your interpretation is just fine; the latitude and longitude are effectively swapped. We are glad you informed us of this discrepancy and the information as been transmit to the person in charge. We will advise you once the problem is fixed. -- Gerald ___ 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] Canvec.osm Product - Running!
Bonjour Adams, Attempting to estimate how many days until your area gets uploaded? Common! Very difficult to predict, and too soon to do that... - I can tell you that it is a 24h/7days process. - I can tell you, from my experience, that you never know when it is finished until it's finished! But, let supposed everything keeps going right, it should be finished in two month. The process is ordered using the file name (NTS) first 3 digit in a way that files are roughly processed from South to North and East to West. By the way, I mentioned in an earlier email that files can be prioritise - if you ask for :-) Regards, Daniel From: Adam Dunn [mailto:dunna...@gmail.com] Sent: 5 juillet 2010 15:14 To: Bégin, Daniel Cc: Talk-CA OpenStreetMap Subject: Re: [Talk-ca] Canvec.osm Product - Running! Will this be running only during office hours, or overnight? I'm attempting to estimate how many days until my area gets uploaded :) Adam On Mon, Jul 5, 2010 at 8:40 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Bonjour OSMers! Canvec.osm product conversion is running since 08:00 this morning (Sherbrooke time). - So far 010xxx, 020xxx, and 030xxx NTS files have been processed - including Toronto (030M11); - We should be able to complete 030xxx and 040xxx today; - To come 001xxx, 011xxx, 021xxx, and so on; What is comming on... - Quebec road network will be updated in the next release; - Manitoba road network will get addressing in the next release; - The vegetation should be updated for the entire country next year. Thanks to all of you that have looked and gave comments on the product. We will eventually get a very nice Osm map coverage over Canada. Cheers, Daniel ___ 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] Canvec.osm Product - Last Call !!!
Bonjour Adam - and all, Needs to fix something? So far... Toponymy - too many spaces along with cardinal direction: It seems to be a problem with some of the original BC data. I will log it to appropriate authorities to have the source corrected. No program fixes needed. It will have to be done by local mappers when necessary. Toponymy - Derived from NHN data: When toponyms becomes available in NHN data, they are included in the next Canvec release - usually within less than 6 months Reefs - duplicate way tagged natural=water: In Canvec Product, a reef creates a hole in the surrounding water area. I did not changed the Canvec data model, except for addressing schema. If you use the duplicate way tagged natural=water, it should be to define an inner polygon in a Multipolygon relation. I would suggest to check the rendering for each scenario - even if we are not supposed to map for the rendering... Coastline - changing natural=water for natural=coastline for coastal water: It all depends on the definition of coastal water! The Canvec data is derived from GeoBase NHN. If something is identified as a coastal water body in NHN product, it will be tagged natural=coastline in Canvec.osm. If not, it will tagged as natural=water. No fixes need. Cheers, Daniel From: Adam Dunn [mailto:dunna...@gmail.com] Sent: 30 juin 2010 14:47 To: Bégin, Daniel Cc: Talk-CA OpenStreetMap Subject: Re: [Talk-ca] Canvec.osm Product - Last Call !!! @Daniel: Not fixing the triple space thing that goes along with cardinal directions? @All: Reefs are currently being made with a duplicate way marked as natural=water. Is this necessary? I'm not experienced with tagging maritime objects. A while ago, Sam asked about having natural=water changed to natural=coastline for coastal waters, but I see it isn't fixed yet. When Yan did the NHN nl_flow conversion, he decided to put the name data into name:1, his reasoning being that NHN sl_water and NHN waterbody also have the name tags, and those would eventually be imported, and the name tags could come from those (and just double checked against the nl_flow name:1). Now there's talk of not doing NHN since it's all included in CanVec. The current samples from Daniel don't have names on the hydrological features (at least the Vancouver 092G06 area), however. Is more NHN data going to be included in future CanVec data, or should names be copied over from nl_flow? Adam On Tue, Jun 29, 2010 at 1:27 PM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Bonjour à tous, The Canvec.osm Product engine is ready to launch. I have used it to create a new version of the sample files. http://wiki.openstreetmap.org/wiki/CanVec Have a look at them and check if everything is as expected. If there is no problem detected until next week, it should be turned ON on monday morning (10-07-05). Cheers, Daniel ___ 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] Canvec.osm Product - Last Call !!!
Bonjour à tous, The Canvec.osm Product engine is ready to launch. I have used it to create a new version of the sample files. http://wiki.openstreetmap.org/wiki/CanVec Have a look at them and check if everything is as expected. If there is no problem detected until next week, it should be turned ON on monday morning (10-07-05). Cheers, Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Natural Landform key/values
Thanks Sam, I'm a bit on a rush right now but I will provide you with at least coordinate where it can be found... Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Sam Vekemans Sent: 22 juin 2010 22:05 To: Talk-CA OpenStreetMap; Daniel Begin Subject: [Talk-ca] Natural Landform key/values Hi all, We wont see some of these feature until we start working on the data in the far north of Canada. But it would be good to clearly define what the terms mean. I started making the wiki pages, but it needs more work http://wiki.openstreetmap.org/wiki/CanVec:_Relief_and_landforms_%28FO%29 http://wiki.openstreetmap.org/wiki/Tag:natural%3Dlandform http://wiki.openstreetmap.org/wiki/Tag:landform%3Desker http://wiki.openstreetmap.org/wiki/Tag:landform%3Dmoraine http://wiki.openstreetmap.org/wiki/Tag:landform%3Dglacial_debris http://wiki.openstreetmap.org/wiki/Tag:landform%3Dpingo http://wiki.openstreetmap.org/wiki/Tag:landform%3Dtundra_polygon http://wiki.openstreetmap.org/wiki/Tag:landform%3Draised_beach All of these do ned their own wiki page templates with the appropriate icons. Some of the icons can be borrorowed from the NRCan pdf maps as a start :) Cheers, Sam P.S. Daniel would we be able to get a sample are which includes this feature? I dont think its available in any of the samples. Thanks. Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails ___ 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
