Re: [Talk-ca] Appel aux contributeurs de Montréal
Bonjour a tous... Je suis ALCE Samuel Paul. Je suis a Montreal depuis quelques jours et j'aimerais bien participer activement au differents activites OSM tout comme j'ai l'habitude de le faire avant... Je suis actuellement libre et je peux aider dans les travaux sur les provinces comme a signaler Bruno. faites moi part de vos activites... Merci... --- Original Message --- From: Pierre Béland pierz...@yahoo.fr Sent: May 16, 2014 4:40 AM To: Bruno Remy bremy.qc...@gmail.com, talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Appel aux contributeurs de Montréal Bonjour Bruno, On pourrait se faire un chat ou autre réunion virtuelle et voir comment nous pouvons avancer de ce côté. Je devrais aussi avoir plus de temps libre à partir de la semaine prochaine. Pierre De : Bruno Remy bremy.qc...@gmail.com À : talk-ca@openstreetmap.org talk-ca@openstreetmap.org Envoyé le : Vendredi 16 mai 2014 1h41 Objet : [Talk-ca] Appel aux contributeurs de Montréal Bonjour à tous, Ces derniers temps, je n'ai pas pu m'investir autant que désiré dans le projet commun avec l'équipe des contributeurs de Montréal. Je fais appel à vous, Pierre, Charles, et les autres? Peut-on réaligner nos efforts sur ce que l'on a commencé au niveau de la province? ;) Au plaisir! -- Bruno Remy ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Routing tool for openstreetmap.ca?
Another big thanks here to those involved in setting this up! I do have a suggestion for the site. Perhaps it is already implemented elsewhere, in which case maybe all I need is to be reminded of its location so I can update my bookmarks. I think it would be great to have access to a routing engine using as current a Canadian data extract as possible... like daily or even more recent. I seem to remember that a year or so ago, we had access to one that was ostensibly for Europe only, but which did include fairly recent Canadian data. I remember using it while doing some CanVec imports. Darned if I can find it now. It really was a great help. I remember that in my case, it highlighted the need for special access= tagging of emergency-only crossovers on divided highways. I've found a few sites that route off of OSM data, but the data are not always current as far as I can tell... and while being a separate issue, the routing plugin on JOSM hasn't worked for me for many months now. Anyway, like I said, if there is an existing tool, please let me know. Otherwise, I think one based on up-to-date Canadian data would be a big help not only for mapping, but provide a great public service as well. Thanks, Samuel Longiaru Kamloops, BC ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Routing tool for openstreetmap.ca?
- Original Message - From: Richard Weait rich...@weait.com To: Simon Wood si...@mungewell.org Cc: Talk-CA OpenStreetMap talk-ca@openstreetmap.org Sent: Mon, 22 Apr 2013 12:14:42 -0600 (MDT) Subject: Re: [Talk-ca] Routing tool for openstreetmap.ca? On Mon, Apr 22, 2013 at 1:51 PM, si...@mungewell.org wrote: http://map.project-osrm.org/ For Canadian data and the rest of the world. Updates the data twice a day, as I understand it. So is there a way to 'teach' that better routes? Blairmore to Calgary was routed through Fort McLeod (257km)... when the faster/shorted route is via Highway 22 and 533 across to Nanton (217km). It might say something about my driving, but that would take a little over 2hrs rather than suggested 3hr4. Yes, I average more that 70km/hr... I'm not familiar with either route, or with your driving style. :-) Routers using OSM data will make assumptions where speed limit data in not available so you might be running into issues where the assumptions don't match your driving experience on the ground. In past, I've found that there are connectivity problems in the OSM data, when routers make suggestions taht I wouldn't expect. In fact, that was one of the things we were using the test instance of OSRM for; finding discontinuities, bad one-ways, and other tagging / mapping errors. Richard, Thanks for the link to the OSRM site, but I don't think that was it. I'm familiar with that project and recently have been following the dev list. At least as the demo site stands, it does give crazy routings for the area of South Australia where I am right now. And while it may be related to speed limit tags, it's not for the lack of them, but because they exist. The unpaved roads here have been correctly tagged with max_speed=100. While that is the statutory limit for unsigned rural roads in South Australia, it is not reasonable in practice. When OSRM sees that, it coughs up routes that suggest one exit reasonably good motorways and jump onto unpaved roads. Here's a good example: http://osrm.at/2Vl When routing from Adelaide to the Roseworthy Campus, OSRM routes one off the M20 and onto unpaved roads when staying on the M20 for one more exit, then exiting to Redbanks Road is the much more logical choice. The fact that OSRM updates data twice a day is encouraging. I didn't see that anywhere. But I've found that the Gosmore engine, at least as implemented by http://yournavigation.org makes more reasonable assumptions and so comes up with more logical routes. The problem there, however is that yournavigation appears to be using worldwide data over 2 months old. And hence my suggestion for an implementation of a routing feature that uses reasonable assumptions (or as best as we can agree to) and utilizing the latest Canadian data possible. It could be based on either the OSRM engine or the Gosmore engine I would imagine. It seems to me that the OSRM routing could benefit greatly by a 0.6 penalty for unpaved roads as had been suggested a few time before, but they don't seem to want to go that way. Thanks, Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Routing tool for openstreetmap.ca?
- James Ewen ve6...@gmail.com wrote: On Mon, Apr 22, 2013 at 3:33 PM, Samuel Longiaru longi...@shaw.ca wrote: It seems to me that the OSRM routing could benefit greatly by a 0.6 penalty for unpaved roads as had been suggested a few time before, but they don't seem to want to go that way. Why incur a penalty just because the roadway is unpaved? A better solution would be to have the ability to request paved roads only when routing. That way the user could decide whether an unpaved roadway should be selected or not. I suppose the best solution would be to allow the user to select whether unpaved roads can be used for routing, and also allow the user to select the penalty to apply for unpaved. I fight with my GPS all the time. I tell it to never use unpaved roads, but it will put me onto them quite often. Then on the other hand it can try and send me on long detours some times when I know I want to take that 2 mile shortcut on gravel to save 40 miles on pavement. It's pretty tough to teach a computer to be as wishy-washy as a human! -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca Paved roads only option? Yes, that's one way. Essentially giving unpaved roads a penalty value (factor) of 0. Then unpaved roads wouldn't be routed on. But consider the case where you are on an unpaved road and wish to route somewhere using the 'avoid unpaved roads' option. It would seem to me that in that case, the engine will need to assess a reasonable penalty for unpaved roads and minimize that penalty by getting you to paved roads by the quickest or shortest means. So either way you stack it, at some point, you need to assign a penalty. Right now, on the OSRM site, you can neither assign a penalty nor elect a paved-roads only option. All roads are reated equally. The yournavigation site must be doing something different, as it yields different (and more logical) results. I'd love to see a routing engine with a desireability factor that could be adjustable. If you really loathe unpaved roads, you could set the unpaved roads desirability factor low (i.e., apply a greater penalty for unpaved roads). And if you don't really care all that much whether you take paved or unpaved, then set the factor high. If your GPS had that, then maybe you wouldn't be fighting with it so much. :) Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] canvec data offset
But which is the rightposition? When one is given to be 3 cm's off the other, neither is more accurate, given the data collection technique. I think you are beyond the accuracy of the data themselves at that level. While merging and then combining a stream or a road that crosses a tile boundary, trying to decide which node is more accurate is one of those questions best asked only during periods of intensive navel contemplation. Take either one. The precision of the data exceed their accuracy I would guess by several orders of magnitude. Is the next node along the way mapped to 3 cm accuracy? Or the next, or the next? No. Here is an example where good enough is TRULY good enough. It's all the science can bear. Sam -Original Message- From: michael bishop cle...@nbnet.nb.ca To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org Subject: Re: [Talk-ca] canvec data offset Date: Mon, 30 Jan 2012 18:01:04 -0400 yeah, thats what i had to do for every node but part is the issue there, is that when i merge 2 nodes, it doesnt always go to the 'right' position' need to manualy select them in the right order to make it go in the right direction, it seems more like an error in the canvec data then an extra step i need to do on every tile almost looks like floating point rounding errors, but not sure why some tiles are ok and others arent On 01/30/2012 05:56 PM, Samuel Longiaru wrote: Have you tried just zooming back a bit in JOSM and merging them? It's part of my stitching process for each tile. I've never had a merge refused because of a 3 cm difference (but, of course I've never looked that closely to see how far apart they were actually). We're dealing with precision here... not accuracy at that level. Sam -Original Message- From: michael bishop cle...@nbnet.nb.ca To: Samuel Longiaru longi...@shaw.ca Subject: Re: [Talk-ca] canvec data offset Date: Mon, 30 Jan 2012 17:42:42 -0400 yeah, its not much, but its enough to screw up josm when trying to combine things between the 2 tiles have to fix each node on the border one by one, no real patern to which direction they are shifted even along a solid line (the edge of the tile), the nodes are going updown and zig-zagging across the edge On 01/30/2012 05:31 PM, Samuel Longiaru wrote: I can hardly put my finger to my nose to within .03 meters... and that's not even drunk. :) Sam L. Kamloops -Original Message- From: michael bishop cle...@nbnet.nb.ca To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org Subject: [Talk-ca] canvec data offset Date: Mon, 30 Jan 2012 17:11:27 -0400 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] Canadian-specific boundary tweaks for MkGMap
Good Afternoon Everyone, I've been lurking on the MkGMap developers list for several months now and see that recently, they have solved some major issues regarding finding streets when OSM is imported for use on Garmin GPS's... without the use of MapSource! They are now moving on to the problem of locating by house number. That's a great accomplishment and the developers deserve a lot of credit.!!! Very well done. Don't know if anyone else has been playing with this, but in short, there may need to be some Canadian-specific tweaks placed into the default style files that are packaged with MkGMap. Through adjustments to the MkGMap command line options, I've been able get the location function to work fairly well in my Nuvi 255, but have run into the issue where I can find Granville Street in Vancouver but Hastings Street can only be found under Gastown and Dundas Street under Capitol Hill. These should all be found in Vancouver. My first guess is that the administrative boundary levels need to be tweaked, not in OSM but in the MkGMap style files where some recasting can take place. They already have country-specific tweaks for about 20 European countries but nothing for Canada yet. I was just wondering if anyone has a customized MkGMap style file that works logically with the way administrative boundaries have been set up in Canada? If so, and we can show that it works well with r2179, their most recent stable version, we could probably pass it on to them for inclusion in the packaged style files so that the location function will work by default on Canadian extracts. Assuming you're willing to share of course :) Thanks... Sam Longiaru, Kamloops, BC ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canadian-specific boundary tweaks for MkGMap
Ah... well that could be the issue. I was not aware of that. I thought those were established a while ago through a GeoBase import. Thanks. Sam -Original Message- From: Paul Norman penor...@mac.com To: 'SAMUEL LONGIARU' longi...@shaw.ca, talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Canadian-specific boundary tweaks for MkGMap Date: Sun, 22 Jan 2012 15:25:57 -0800 The administrative boundaries in the lower mainland are not complete. I’ve been looking for a source for the rest of them, but haven’t found one. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] import complaints
I /think/ I'm responsible for that big error in Hudson Bay. I've fixed it, but can't quite figure out how two small mistakes caused that big glitch. Perhaps the real problem is that the coastlines are updated only a few times a year, I fixed the problem as soon as I saw it, and yet it will persist on all levels. (I don't know if this can be changed, don't interpret this as a demand or passing of the blame for the error) In regards to the imports. I mostly import in areas without any decent aerial imagery, or in some cases people (though in some cases images came after the import) . If someone is willing to pay me to map these areas (I don't mind donating time, but I need to eat/get there) and give me good aerial imagery and a high quality GPS I will swear off Canvec, but that doesn't seem likely. Sam Dyck On 11-12-02 04:56 PM, talk-ca-requ...@openstreetmap.org wrote: We could ban imports. But we still want to have access to external sources. So let's start treating external like we treat aerial imagery. When you do a foot survey you take notes and photos and draw sketches. Then you map it by referring to your notes and photos and sketches and aerial imagery. That's how we notice that the aerial imagery is three years old doesn't show the new shopping plaza or extension on the old mill. And we consider all of those sources then take the best we can from every source and put it in OSM. That's why OSM is so good where we have a rich community. OSM is better than any other single source. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Fwd: [OSM-talk] Argh, Canvec imports
Hi I /think/ I'm responsible for the problems in Hudson Bay. The issue was I forgot to delete the intermittent coastline from Canvec and only discovered my error once the coastline was updated. I've fixed the problem, but I have no idea if I am responsible for that big blob of grey in the southern half (I didn't do any editing there, I have to wait until the next update to find out). I've seen coastline errors many times before, I remember there was a large one in Southern Ontario for a while, and Newfoundland had several until recently. Here is the problem: -Editors don't notice their mistakes until the coastline is updated, so they stick around in the data for a while -When the mistakes are fixed it takes a few weeks for the corrections to show up on mapnik -Coastlines are handled differently than the natural=water tag, which confuses people -Mapnik doesn't render natural=water at high levels -Mapnik ignores the water=intermittent tag I'm not suggesting we use natural=water (that would be a terrible idea), there just needs to be a way for editors to check the rendering of their coastlines. Sam Dyck ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Proposal: Removing imported aboriginal land
I have been finding many of these here in south central BC and have been leaving them of course, but consistently find that they are very highly over digitized. I have been simplifying their boundaries in JOSM and and find that I can easily get a 20 or 30-fold reduction in nodes without changing the boundaries. Seems like a reasonable first step to take. Sam Longiaru Kamloops -Original Message- From: john whelan jwhelan0...@gmail.com To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org Subject: [Talk-ca] Proposal: Removing imported aboriginal land Date: Thu, 27 Oct 2011 18:09:10 -0400 First nations is fun. Treaties were negotiated with England, Queen Victoria I think it was, at a nation to nation basis, in recognition of the assistance that the natives had given the British. Canada is the only country in the commonwealth were such treaties were made. Everywhere else the English simply proclaimed themselves as owning everything. They are tagged with admin_level=4, the same as provinces, which misrepresents their importance. An interesting observation. Are you saying that a province rates above a nation or below it? Viewable to Z4, - this is more a rendering issue than anything else. No one has edited them to improve them. - We could throw out quite a bit of OSM based on that. My take would be given we don't have as many mappers on the ground as we would like and some one may find this information to be of value so leave it in the map until it fades away because of the CT tags. You never know some one might take an interest in it and update it, currently it would seem to be the best information available. Cheerio John On 27 October 2011 17:39, Paul Norman penor...@mac.com wrote: In 2010 acrosscanadatrails imported Aboriginal reserves. An example is http://www.openstreetmap.org/browse/relation/1016901 These are viewable all the way out to z4. I propose removing these for a few reasons. 1. From what I’ve seen, no one has edited these to improve them. 2. Acrosscanadatrails has not agreed to the CTs. He has indicated his contributions are public domain, so the data could be downloaded and reimported, but I do not believe that should be done. 3. The tagging is questionable, with two FIXMEs. They are tagged with admin_level=4, the same as provinces, which misrepresents their importance. 4. The tagging for aboriginal lands is not settled. See http://wiki.openstreetmap.org/wiki/Talk:Key:boundary#First_Nations for some discussion. Although this shouldn’t stop people from mapping them, I believe it should stop them from being imported. ___ 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] Coastline on low zoom levels
Hi Everyone The sparse selection of North American lakes at low zoom levels on the mapnik layer has become embarrassing. Could we get the file used to generate the coastlines at low resolutions updated. Lakes missing: - Southern half of Lake Winnipeg - Lake Manitoba - Almost all of Great Slave Lake - Great Salt Lake - Lake of the Woods - Smallwood Reservoir - Lake Simcoe - Lesser Slave Lake And many others around the world. Sam Dyck ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] User:CANVEC
Hi Maybe I missed something here, but who exactly is User:CANVEC http://www.openstreetmap.org/user/CANVEC? They only joined in July and their edits have been confined to Ellesmere Island, southeastern Quebec and northwestern New Brunswick. Not suprisingly, all their edits are Canvec imports. A review of Talk-ca messages shortly before and after account creation yields no information. Sam Dyck ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Tagging Cardlock gasoline
Hi everybody I have been away from the internet for much of the summer and am now entering information gathered in my travels into OSM. However I encountered some problems with some fuel stations. Many stations in rural Canada, particularly those owned by consumer co-ops are cardlocks: unstaffed stations that require the customer to insert a punchcard, they will receive a monthly bill for their purchases in the mail. As such most travellers cannot use them. Any suggestions as to how to tag them? Sam Dyck ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Corrupted upload... workflow question and best practices
Good Morning Everyone, Not sure if this is the correct place to post this but it doesn't seem like a JOSM problem or a Newbies issue either. Maybe someone can direct me elsewhere if this isn't the best place. OK... so I'm slowly plodding along importing CanVec data into south central BC. Yesterday, however, I encountered a problem that may be a result of my workflow process and I need some guidance in order to help avoid the same thing in the future. For the past 5 or 6 days, I have been working on 82L3.1.2 - a file that covers the southern part of Vernon, BC as well as parts of Okanagan and Kalamalka Lakes. There was already some existing OSM... some of which I had Bing-mapped myself several months ago and bits and pieces by several other account holders. As I could see this was going to be a particularly painstaking import, I decided to save the OSM download layer locally on my machine and merge item by item from the CanVec layer down onto it. By yesterday, the new composite OSM layer was looking pretty good. Considerable data had been added and some old OSM... such as my previous Bing mapping, had been deleted and replaced with the CanVec. Also, I had made other edits such as removing abbreviations, added turning circles, etc. I saved it one more time locally, then uploaded it to the server. In the course of uploading, there was a synchronization error on one node... a gas station in the original OSM that I had repositioned. The error stated that I had version 1 of the node, whereas there was an existing version 2. I synchronized that data point only and from what I could tell, the upload proceeded normally. However, checking the server later, it was clear that the upload did not go well. Over 6,000 data points had been uploaded with no corresponding ways. Some pre-existing OSM... such as my earlier mapping that I had deleted from the working copy had not deleted from the server, resulting in duplicate ways. There really seemed to be no pattern to the failure. Some water features uploaded, some didn't. Some highways did, some didn't. There was also no time-related pattern. Errors were not related to just my earlier or later edits. It was an equal-opportunity failure across the data set. Some time ago, I experienced occasional upload errors where nodes were being uploaded but not the ways. I was advised on the list at that time to cut the batch size from 2000 points down to 500. I did so and until now have had no further failures. I was also advised to just try to upload again as sometimes that's enough. So I tried re-uploading last night but it didn't recover. I can't remember the issue exactly in that case, but by then what was on the server was in such a mess I wasn't surprised. In any event... by 2 AM last night the south Vernon area was in pretty good shape again. There might be a couple of minor road-network issues to fix and some land-use and stream features that need restored. I still have probably another day or so of cleanup to get it to where it should be. So where did I screw up? Clearly, downloading an area from the server and working on it locally for a week before uploading is not best practices and can lead to synchronization errors... although in this case, it's hard to see how the error associated with a single gas station node could lead to such widespread failure. But when faced with a synchronization error like this, is it best to synchronize the whole data set or only the offending points? Is that where I went wrong? And just what are best practices for importing where it is clear that the job will take a long period of time? Make a couple of edits and upload? Make a couple more edits and upload? Is this the best approach? Or is there something in my procedure or in the tools that I'm missing that will help avoid this in the future. Thanks in advance, Sam L. Kamloops ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Kamloops Data
Hi Matthew... Great to have another active mapper in Kamloops. I think that now makes two. Anyway, I've contacted you off list to see if we can get together and get something organized. I would be happy to help. The City does have a beautiful data set, subsets of which could be a worthwhile addition. Thanks for getting this started. Sam Longiaru Kamloops -Original Message- From: Matthew Buchanan matthew.ian.bucha...@gmail.com To: talk-ca@openstreetmap.org Subject: [Talk-ca] Kamloops Data Date: Fri, 29 Jul 2011 14:35:46 -0700 Hello I'm a new user to OSM and I've been enjoying it so far. I have done some edits to various places in BC that I know well. I posed a question, seen below at the OSM forum regarding data from the City of Kamloops that is freely available. I received permission from the GIS Coordinator at the City to use whatever data I want . http://forum.openstreetmap.org/viewtopic.php?id=13208 I thought I'd discuss it on this list as well. So far I've only imported a subset of building outlines, trees, and parks. I went through the data to clean it up before I imported using JOSM. Are there any users from the Kamloops area here? -- Matthew Buchanan -- Kamloops, BC ___ 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] Ping John Whelan?
Hate to jump in where it's not wanted but... Just wondering if there is some kind of middle ground solution here. John clearly does not feel comfortable with having his imports in the database and so has removed them. Not something we would like to see happen too often, but it has happened. Is it possible to restore his original imports and the subsequent edits by others, but do so using another account name so that John's is not associated with the data? I would think that this should meet John's desire to have his name removed from the data, and from our perspective, could constitute a new import. In this case, I would think that John could take some comfort in knowing that he did what he felt he needed to do... namely remove the data that he did not feel comfortable with anymore... for whatever reason. We could then restore the data without having to do through the painstaking process of reimporting from a CanVec source and re-edit. It would simply be an import under another account. Changing the licensing mid-stream is bound to cause some issues many of which will be totally unforeseen. There has to some kind of reasonable solution here. Thanks, Sam -Original Message- From: john whelan jwhelan0...@gmail.com To: Richard Weait rich...@weait.com Cc: Talk-CA OpenStreetMap talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Ping John Whelan? Date: Tue, 07 Jun 2011 14:12:24 -0400 To recap: The objective of moving to ODBL is to give a stronger legal position for the database. This position can be undermined if any included data has not been directly created by a mapper in the field. In my edits I have included at least one bus stop from GTFS data, I don't have the rights to license it under CC-by-ODBL. At the time it was done my expectation was that this information would become available under CC-by-SA in the short term this has not happened. I have included information from a source that had other information on it. Not a major crime but it is technically a breach of copyright. The two paragraphs above basically undermine any legal case that OSM would have concerning Ottawa data unless the data is removed when brought to your attention which is why I haven't specifically mentioned them before. Note it has now been brought to your attention and the responsibility for the integrity of the database is now yours if you choose not to accept the deletions. There are probably a few other instances in there somewhere. I have requested that my CT status be reverted. I have tried to request that my change sets / data be removed and I have manually deleted the suspect data which I think is all I can reasonably do. If you revert the deleting edits then you undermine the legal case for protecting the OSM database. If my CT status was reverted then the older data would be deleted in time by OSM. I saw a post to that effect recently from Frederick in a reply to some one who mentioned they couldn't accept the new CT. That and Fredrick's comment that people were deleting data that wasn't added under the new CT triggered the decision to remove the data I had added to the project. Basically the sooner its done the less impact it will have. Leave it around and others will edit it so their edits get lost as well. There has been some discussion that I think you are aware of within OSM about imports. Basically the new CT is not import friendly. As a contributor you are responsible for the data you add to the project. This includes ensuring that only data that meets the licensing can be included. I don't think anyone can say what the license in future will be changed to or even if it will be changed. Essentially this means I cannot give an undertaking to CANVEC that OSM license will be compatible and acceptable in the future when I don't know what that license will be. OSM I think is changing to be a map that is done by people on the ground with GPS devices. That's fine, I have surveyed and added a number of footpaths and I'm more than happy to add them to the project. I think if you look at Google you'll see imported bus stops. I don't think OSM will ever be reliable enough for people to use it for bus stops unless they are imported. In North America today I think regretfully Google and Bing have essentially won when we look at what people use. OSM is a very niche product. It happens to be one I personally like very much. The Ottawa map I have hosted in Google documents using Maperitive is still the only one I know of where you can find WLAN locations that are wheelchair accessible and the data is searchable. To protect the OSM database I think you have to remove my edits. I'll add the footpaths etc that have been manually surveyed back in later. Thanks Cheerio John On 7 June 2011 13:24, Richard Weait rich...@weait.com wrote: On Tue, Jun 7, 2011 at 12:24 PM, john whelan jwhelan0...@gmail.com wrote: I would be extremely happy to see all my
Re: [Talk-ca] Railways duplicated in CanVec data
What? Didn't know that. We should be importing under a separate account? How is that to be set up? Sorry if I've been doing this wrong. Thanks. Sam -Original Message- From: Richard Weait rich...@weait.com To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Railways duplicated in CanVec data Date: Thu, 02 Jun 2011 12:02:55 -0400 On Thu, Jun 2, 2011 at 12:00 PM, Nakor Osm nakor@gmail.com wrote: I have also noticed that some tiles does not have all street names. For example the tile covering Pointe-a-la-Croix, QC and Campbellton, NB have all street names on QC side but only a few ones on NB side. You shouldn't be importing canvec data with your personal account. It should be an import / bot account. ___ 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
OK... I can set up one dedicated to Canvec imports. That's no problem if that is the preferred practice. I do remember now reading that reference in the Wiki that states Consider creating a new user for the import but I interpreted the reason for doing so as not applicable as I was not adding anything to the source tags. So I did what was asked... I considered it... but I didn't do it. Also, I am not blindly or mechanically importing but editing and tweaking as I go, so I guess there is a gray area as to what is CanVec and what is personal. I also label all the changesets as CanVec imports so that they are more obvious in my own edit history. But if it makes things easier to track... I'll continue from now on under a different account. Thanks for the guidance. Sam -Original Message- From: Richard Weait rich...@weait.com To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Railways duplicated in CanVec data Date: Thu, 02 Jun 2011 20:55:06 -0400 On Thu, Jun 2, 2011 at 6:51 PM, Samuel Longiaru longi...@shaw.ca wrote: What? Didn't know that. We should be importing under a separate account? How is that to be set up? Sorry if I've been doing this wrong. http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_account http://wiki.openstreetmap.org/wiki/Automated_Edits/Code_of_Conduct http://wiki.openstreetmap.org/wiki/Data_working_group/Mechanical_Edit_Policy Indeed. Separate accounts for each import source are the current best practice. Not everybody is following this obviously. No harm in trying to follow all of the best guidelines. ___ 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] Winnipeg Transit addresses
Hi everyone I was browsing through Winnipeg Transit's new PDDL API and experimenting with the possibility of getting data from it. I discovered a way to use a wildcard search to generate and XML file with all addresses on a street that start with the same number. I found a small street and manually created an OSM XML file for all address which I double checked against Bing and found it accurate. I did not import it. Is it worth creating a script to attempt to do this on a larger scale, especially if the servers are throttled at 100 requests per IP per key per minute? One advantage is it only has actual address, the reality of nonexistent houses (where the house numbers skip several on a street, e.g. my house is 725, my neighbour is 729, I have looked hard for 727 but can't find it) is one of the biggest problems with interpolation. If you want to play around with the API you can use my key. http://api.winnipegtransit.com/locations:414+osb?api-key=gFUVjeJObwFawLhOK75q Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Railways duplicated in CanVec data
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] 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] 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 To: Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca Cc: Samuel Longiaru longi...@shaw.ca, talk-ca talk-ca@openstreetmap.org 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
OK Daniel... thank you for the information and the reasoning behind it. It seems that at least in the areas I've been importing, all is working correctly in regards to the islands and wood, even the wooded islands without the use of the natural=land tags. This area also renders correctly on my Garmin with the data having gone through MkGMap and so the tags seems to be correct for that process as well. Thanks, Sam -Original Message- From: Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca To: Samuel Longiaru longi...@shaw.ca, talk-ca talk-ca@openstreetmap.org Subject: RE: [Talk-ca] CanVec natural=land tags and untagged ways Date: Wed, 18 May 2011 10:25:10 -0400 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] Importing MLI park boundaries
But per http://wiki.openstreetmap.org/wiki/Community_Updates/2011-03-07#ODbL_phase_3_delayed_due_to_Creative_Commons, phase 3 has been delayed. Or has this changed? Sam On 11-03-26 05:18 AM, Tom Hughes wrote: On 26/03/11 04:03, Samuel Dyck wrote: Let me clarify, will the so called tainted data still be up for the near future, or will I be spending my week preforming hectic Canvec imports to save street names I gathered with a pen and paper? It doesn't look good for me http://osm.informatik.uni-leipzig.de/map/?zoom=12lat=49.88177lon=-97.17517layers=B0. Please ignore Sam - there is no data removal planned for next week. I think he has confused the stages of the license change process - the next stage is to ask people to accept or decline the license before they can edit. It is not the point at which the license will change and problem data may have to be removed. It is not even the point at which people who decline will not be able to edit any more. More details about the implementation plan can be found here: http://wiki.openstreetmap.org/wiki/Open_Data_License/Implementation_Plan As I understand things it is Phase 3 which we are close to entering, not Phase 5. Tom ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Importing MLI park boundaries
So there is poor communication between the board and the community? I hate to argue, but the License change still has a large TODO notice next to the No option. This is a problem. Sam On 11-03-26 11:17 AM, Tom Hughes wrote: On 26/03/11 16:12, Samuel Dyck wrote: But per http://wiki.openstreetmap.org/wiki/Community_Updates/2011-03-07#ODbL_phase_3_delayed_due_to_Creative_Commons, phase 3 has been delayed. Or has this changed? Those community updates are exactly that - written by a member of the community and not authoritative in any way. In this case I don't believe that what is written there is an accurate summary of the situation at all. Tom ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Importing MLI park boundaries
*Decline*. You do not agree to the new OpenStreetMap Contributor Terms and, specifically, you refuse to re-license your existing contributions for use under the ODbL. (TODO: add more on what this means). Here. http://www.osmfoundation.org/wiki/License/We_Are_Changing_The_License#What_Are_The_Choices.3F Stage 3 is is very late, and no reason is given as to why. As for the update, why is it not monitored? Sam On 11-03-26 11:36 AM, Tom Hughes wrote: On 26/03/11 16:33, Samuel Dyck wrote: So there is poor communication between the board and the community? I hate to argue, but the License change still has a large TODO notice next to the No option. This is a problem. As I thought I had explained that community update was not a communication from the board or LWG or anybody else official so I'm not sure how you can read into it anything about communication between the board and the community. I have no idea what TODO notice you are talking about - obviously code changes will be needed to implement future phases of the implementation plan and I understand that those are in progress. Tom ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Importing MLI park boundaries
I see, my bad. I'm just a little frustrated about the lack of communication. I should say that I have already accepted the new terms (sorry Sam). On 11-03-26 11:48 AM, Tom Hughes wrote: On 26/03/11 16:42, Samuel Dyck wrote: *Decline*. You do not agree to the new OpenStreetMap Contributor Terms and, specifically, you refuse to re-license your existing contributions for use under the ODbL. (TODO: add more on what this means). Here. http://www.osmfoundation.org/wiki/License/We_Are_Changing_The_License#What_Are_The_Choices.3F I think that's just out of date, like so much in the wiki. New users signing up are sent to a different wiki page when they decline: http://wiki.openstreetmap.org/wiki/Contributor_Terms_Declined Stage 3 is is very late, and no reason is given as to why. I believe the main reason is because of the ongoing attempt to improve the contributor terms to deal with various issues which people raised with them. Unfortunately reworking them takes time because of the need to keep passing each draft over to the lawyers for review. As for the update, why is it not monitored? I don't know - maybe the board has established a Community Monitoring Group yet? Maybe you should suggest it to them? You seem to have me confused with somebody in authority ;-) Tom ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Importing MLI park boundaries
Thanks Sam. Now hopefully no one on the other boards will rip into me for daring to import. :) You might also want to look at the MLI provincial forest data and the other goodies on the admin. boundaries list. (I don't know what you are interested in). Sadly with the exception of the Winnipeg Transit, the City of Winnipeg doesn't believe in open data. Sam On 11-03-26 12:15 PM, Sam Vekemans wrote: I guess the OpenStreetMap Foundation's Map (odbl only) has not yet been started. Since the date of step 5 is 'to be determined'. So that's a good reason why i'm actively working on the alternative(s) :-) ... To get back on topic, I'll get back to this list once i have the rules.txt/.pl script and shp/.osm files available of the MLI park boundary data, since many would like to see this data on the various map APIs. cheers, Sam p.s. i'll probably be done it before step 5 roles around :-) On 3/26/11, Samuel Dycksamueld...@gmail.com wrote: I see, my bad. I'm just a little frustrated about the lack of communication. I should say that I have already accepted the new terms (sorry Sam). On 11-03-26 11:48 AM, Tom Hughes wrote: On 26/03/11 16:42, Samuel Dyck wrote: *Decline*. You do not agree to the new OpenStreetMap Contributor Terms and, specifically, you refuse to re-license your existing contributions for use under the ODbL. (TODO: add more on what this means). Here. http://www.osmfoundation.org/wiki/License/We_Are_Changing_The_License#What_Are_The_Choices.3F I think that's just out of date, like so much in the wiki. New users signing up are sent to a different wiki page when they decline: http://wiki.openstreetmap.org/wiki/Contributor_Terms_Declined Stage 3 is is very late, and no reason is given as to why. I believe the main reason is because of the ongoing attempt to improve the contributor terms to deal with various issues which people raised with them. Unfortunately reworking them takes time because of the need to keep passing each draft over to the lawyers for review. As for the update, why is it not monitored? I don't know - maybe the board has established a Community Monitoring Group yet? Maybe you should suggest it to them? You seem to have me confused with somebody in authority ;-) Tom ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Importing MLI park boundaries
Hi Everyone The Canvec data for MB provincial park boundaries is horribly inaccurate and this bothers me greatly. The government of Manitoba offers good boundary data and a bunch of other cool stuff though the Manitoba Lands Initiative, which I believe we can use, but I've never converted Shapefiles to an API 0.6 compatible osm file (or at all really). How would I best do this? Sam Dyck ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Importing MLI park boundaries
I'm using an Ubuntu derived distro, so I should be good. Tyler converted the MLI building data and has been importing it into OSM already. I've read thought the terms, do I need to clear a import with someone? Sam On 11-03-25 03:32 PM, Paul Norman wrote: I prefer http://wiki.openstreetmap.org/wiki/Ogr2osm to do the conversions. To convert you have to write a python function that maps the shapefile tagging to osm tagging. This is not technically very hard, but mapping to osm tags is very easy to get wrong. If you're using Windows, I'd suggest using VirtualBox and Ubuntu to run it. -Original Message- From: Samuel Dyck [mailto:samueld...@gmail.com] Sent: Friday, March 25, 2011 12:12 PM To: talk-ca@openstreetmap.org Subject: [Talk-ca] Importing MLI park boundaries Hi Everyone The Canvec data for MB provincial park boundaries is horribly inaccurate and this bothers me greatly. The government of Manitoba offers good boundary data and a bunch of other cool stuff though the Manitoba Lands Initiative, which I believe we can use, but I've never converted Shapefiles to an API 0.6 compatible osm file (or at all really). How would I best do this? 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] Importing MLI park boundaries
Thanks Sam, that saves me a lot of work. Is all the tainted data being removed Friday, or just yours? Sam On 11-03-25 10:29 PM, Sam Vekemans wrote: Hi, The National Parks data will be removed from the osm api next friday, as it will be considered 'tainted data' since the person who uploaded the data doesn't agree to the new contributor terms. This helps, as it makes it easier to add in the Manitoba parks data. Since knowone volunteered, the conversion script for the MLI data will be availbale on github :) and the shape files on koordinates.com Soon(TM) cheers, sam On 3/25/11, Samuel Dycksamueld...@gmail.com wrote: Hi Everyone The Canvec data for MB provincial park boundaries is horribly inaccurate and this bothers me greatly. The government of Manitoba offers good boundary data and a bunch of other cool stuff though the Manitoba Lands Initiative, which I believe we can use, but I've never converted Shapefiles to an API 0.6 compatible osm file (or at all really). How would I best do this? 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] Importing MLI park boundaries
Let me clarify, will the so called tainted data still be up for the near future, or will I be spending my week preforming hectic Canvec imports to save street names I gathered with a pen and paper? It doesn't look good for me http://osm.informatik.uni-leipzig.de/map/?zoom=12lat=49.88177lon=-97.17517layers=B0. Sam Dyck On 11-03-25 10:56 PM, Sam Vekemans wrote: That is upto the OpenStreetMap Foundation to decide on what todo, as they will effectivelly 'own' all the rights to the data, including all tainted data. We (as a community) do not have a say in this matter, unfortunatly. cc'd the lists, it's up to them to reply back. cheers, sam On 3/25/11, Samuel Dycksamueld...@gmail.com wrote: Thanks Sam, that saves me a lot of work. Is all the tainted data being removed Friday, or just yours? Sam On 11-03-25 10:29 PM, Sam Vekemans wrote: Hi, The National Parks data will be removed from the osm api next friday, as it will be considered 'tainted data' since the person who uploaded the data doesn't agree to the new contributor terms. This helps, as it makes it easier to add in the Manitoba parks data. Since knowone volunteered, the conversion script for the MLI data will be availbale on github :) and the shape files on koordinates.com Soon(TM) cheers, sam On 3/25/11, Samuel Dycksamueld...@gmail.com wrote: Hi Everyone The Canvec data for MB provincial park boundaries is horribly inaccurate and this bothers me greatly. The government of Manitoba offers good boundary data and a bunch of other cool stuff though the Manitoba Lands Initiative, which I believe we can use, but I've never converted Shapefiles to an API 0.6 compatible osm file (or at all really). How would I best do this? 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
[Talk-ca] CanVec Vs. TIGER
Hi everyone I'm at home recovering from dental surgery, so I've had the opportunity to get a lot of imports done. But I've been importing along the US border alot, and have ran into some trouble with TIGER Data and need some advice. My problems are as follows: -Importing near the geopolitical oddity know as the Northwest Angle https://secure.wikimedia.org/wikipedia/en/wiki/Northwest_Angle, I encountered a disagreement about the coastline of The Lake of the Woods. Canvec and data ends 150m north where TIGER data begins. (thought they are both roughly on the same Longitude). An inspection using Landsat and some surprisingly decent Bing imagry strongly favour Canvec and show the TIGER boundary to be full of twists and lagoons that don't appear to exist. How to I reconcile this? The Canvec boundaries appear to follow the exterior edge of a white surface that Canvec calls wetland, but may be ice. Sadly the one place of this lake I know has no white surface nearby. -TIGER is full of duplicate nodes. When I run Validator to check Canvec data I will often get 20+ duplicate node warnings from a TIGER road I partially downloaded. I can fix this without downloading the entire area of the way, but they I just hit more ways with problems. Thanks Sam Dyck ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Mapping cut blocks in wooded areas
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 To: 'talk-ca' talk-ca@openstreetmap.org 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 over time, we can keep mapping !-) Daniel From: Samuel Longiaru [mailto:longi...@shaw.ca] Sent: March-04-11 21:45 To: talk-ca Subject: [Talk-ca] Mapping cut blocks in wooded areas Hi Everybody, I've been importing CanVec mostly south of Kamloops for the past several weeks and am going to take some time now to go back and bring stuff up to date. One question I have though is in regards to how to treat cut blocks in the wooded areas. I see according to the map features wiki, that the CanVec imported tag of natural=wood is technically not correct, at least for here, as wood is to be reserved only for completely reserved/unmanaged areas. I guess most of what I have should really be mapped as landuse=forest but I have not made the change because what is under timber lease and what is not would be difficult to determine. In one sense it's all managed to some degree or other. But my point is rather what should be done
Re: [Talk-ca] Did I just find a potentially significant bug in JOSM?
Dan... Have to admit that I VERY rarely if ever use the fix button, and then only after I've isolated the issue for a specific error or warning. I do errors first, then warnings. But after each correction, I revalidate to refresh the list. Maybe that's overkill, but it keeps the exceptions from being thrown. I think you're getting the exceptions because you've modified the data, but have not updated the list. Usually, I just highlight the specific error or warning, hit the SELECT button, then the 3 key to go there. I fix it manually if I can, then re-validate. Then move to the next issue. I'm too much of a scaredy-cat to highlight a whole class of errors and let JOSM fix them automatically. Like I said, I'm not sure JOSM likes me. I'll try selecting an unnamed way warning and fixing to see what happens. If it removes the way well, that's certainly ONE way to fix it. Sam L. -Original Message- From: Dan Charrois d...@syz.com To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org Subject: [Talk-ca] Did I just find a potentially significant bug in JOSM? Date: Mon, 07 Mar 2011 17:42:09 -0700 I've spent the past several hours trying to find out out why some of my edits resulted in some accidental road removals. I think I've found the problem, which seems to relate to an apparent bug in JOSM, or at least a preference somewhere set to something unintuitive that I haven't been able to find - as such, I thought it would be best to communicate with the group to see if anyone's experienced this problem before, or at least give a heads up as to what has been happening to me in case it's inadvertently happening to others. I downloaded an area around the Beaumont, Alberta region to try and add some roads from Canvec that don't exist in OSM (roads which I could have sworn I've added when I worked on the same area a month or two ago). I then saved this downloaded area, along with the changes I made, to an .osm file in JOSM. I ran the Validator which found a few duplicate nodes and such. Telling it to fix errors, it did its thing. And then, I clicked on warnings and told it to fix those. Lo and behold, some (though not all) of the roads I'd just added suddenly disappeared. Since validation was the last step in my process before I uploaded the data, and I was often zoomed all the way out when I did so, I hadn't noticed this happen before, but it probably had been going on right before I uploaded my changes. In particular, sometimes I would replace lower quality OSM roads with better Canvec data, and if JOSM was deleting some of those Canvec roads I'd added in its fix warnings validation step, those original OSM roads would have disappeared without replacements. I tried to isolate further exactly what it was doing, and at least in this situation it looks like it may be related to unnamed ways. I have 41 unnamed ways in my data. If I click on the unnamed ways folder specifically in the warnings validation dialog, it doesn't give me the option to fix them - it shouldn't, since it doesn't know what to call them anyway. But if I click on the parent (root) icon just labelled Warnings, the fix button is enabled, and I thought it was just supposed to fix all the enclosed warnings in categories that it is able to fix. When I click to fix all warnings like this, in the progress bar, I see that it spends some time fixing unnamed ways. And then those ways are gone when it's done. I was using JOSM 3751, so I checked for updates and found that 3961 was available. I've updated my JOSM to see if it's still an issue. But now, when I do the global fix warnings on the data set, it gets part way through, then consistently gives me an unexpected exception (coding error). When I dismiss that dialog, I find that those roads have again been removed, so it seems as though this is still a problem. The unexpected exception isn't encouraging either. I suppose that I can work around the problem by selectively choosing fix in the validations warning area for each of the separate categories, instead of doing them all at once. Though now I'm unsure as to whether or not there is still an underlying problem with fixing warnings that may give rise to an inadvertent loss of data. At the very least, I wanted to make a posting about it so that others can be warned away from having the same problems I have run into. If anyone is interested in trying to duplicate the problems I'm having, just let me know your email address and I can send you the .osm file I'm working with (compressed, it's about 600 kB). And of course, if anyone has any ideas, or suggestions about something stupid I'm doing, please let me know! Dan -- Syzygy Research Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[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
Re: [Talk-ca] Did I just find a potentially significant bug in JOSM?
No, if I highlight an unnamed way warning, and select it, the fix key is grayed out. That makes sense. Sam L. -Original Message- From: Samuel Longiaru longi...@shaw.ca To: Dan Charrois d...@syz.com Cc: Talk-CA OpenStreetMap talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Did I just find a potentially significant bug in JOSM? Date: Mon, 07 Mar 2011 18:13:37 -0800 Dan... Have to admit that I VERY rarely if ever use the fix button, and then only after I've isolated the issue for a specific error or warning. I do errors first, then warnings. But after each correction, I revalidate to refresh the list. Maybe that's overkill, but it keeps the exceptions from being thrown. I think you're getting the exceptions because you've modified the data, but have not updated the list. Usually, I just highlight the specific error or warning, hit the SELECT button, then the 3 key to go there. I fix it manually if I can, then re-validate. Then move to the next issue. I'm too much of a scaredy-cat to highlight a whole class of errors and let JOSM fix them automatically. Like I said, I'm not sure JOSM likes me. I'll try selecting an unnamed way warning and fixing to see what happens. If it removes the way well, that's certainly ONE way to fix it. Sam L. -Original Message- From: Dan Charrois d...@syz.com To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org Subject: [Talk-ca] Did I just find a potentially significant bug in JOSM? Date: Mon, 07 Mar 2011 17:42:09 -0700 I've spent the past several hours trying to find out out why some of my edits resulted in some accidental road removals. I think I've found the problem, which seems to relate to an apparent bug in JOSM, or at least a preference somewhere set to something unintuitive that I haven't been able to find - as such, I thought it would be best to communicate with the group to see if anyone's experienced this problem before, or at least give a heads up as to what has been happening to me in case it's inadvertently happening to others. I downloaded an area around the Beaumont, Alberta region to try and add some roads from Canvec that don't exist in OSM (roads which I could have sworn I've added when I worked on the same area a month or two ago). I then saved this downloaded area, along with the changes I made, to an .osm file in JOSM. I ran the Validator which found a few duplicate nodes and such. Telling it to fix errors, it did its thing. And then, I clicked on warnings and told it to fix those. Lo and behold, some (though not all) of the roads I'd just added suddenly disappeared. Since validation was the last step in my process before I uploaded the data, and I was often zoomed all the way out when I did so, I hadn't noticed this happen before, but it probably had been going on right before I uploaded my changes. In particular, sometimes I would replace lower quality OSM roads with better Canvec data, and if JOSM was deleting some of those Canvec roads I'd added in its fix warnings validation step, those original OSM roads would have disappeared without replacements. I tried to isolate further exactly what it was doing, and at least in this situation it looks like it may be related to unnamed ways. I have 41 unnamed ways in my data. If I click on the unnamed ways folder specifically in the warnings validation dialog, it doesn't give me the option to fix them - it shouldn't, since it doesn't know what to call them anyway. But if I click on the parent (root) icon just labelled Warnings, the fix button is enabled, and I thought it was just supposed to fix all the enclosed warnings in categories that it is able to fix. When I click to fix all warnings like this, in the progress bar, I see that it spends some time fixing unnamed ways. And then those ways are gone when it's done. I was using JOSM 3751, so I checked for updates and found that 3961 was available. I've updated my JOSM to see if it's still an issue. But now, when I do the global fix warnings on the data set, it gets part way through, then consistently gives me an unexpected exception (coding error). When I dismiss that dialog, I find that those roads have again been removed, so it seems as though this is still a problem. The unexpected exception isn't encouraging either. I suppose that I can work around the problem by selectively choosing fix in the validations warning area for each of the separate categories, instead of doing them all at once. Though now I'm unsure as to whether or not there is still an underlying problem with fixing warnings that may give rise to an inadvertent loss of data. At the very least, I wanted to make a posting about it so that others can be warned away from having the same problems I have run into. If anyone is interested in trying to duplicate the problems I'm having, just let me know your email address and I can send you the .osm file I'm working with (compressed, it's about
Re: [Talk-ca] Here we go again...
Hi Dan, Your procedure sounds pretty similar to mine, and working around Kamloops likely is equivalent in terms of the kinds of features we see. You probably do this as well, but before running the validator, I step around the edge of the import and connect streams, powerlines, and anything else that I think needs connecting. The auto-fix on duplicate nodes just seems to merge the nodes but doesn't combine the ways. As you, I very rarely have found the need to import a road as previous GeoBase or other imports have already provided the same information. I simplify some features as well (streams and some lake shorelines mostly) but I try to remember to simplify before merging the selection onto the OSM layer. Simplifying later often gives the warning that you are deleting nodes outside the uploaded data area. If I get a conflict, this is where it happens. You do, however, seem to have much better luck than I have had on failed imports. On 4 or 5 different occasions, an upload has hung (sometimes for hours) and a cancel has resulted in nodes only (no way information) being uploaded to the server. This behavior is quite consistent. The result is 6-8,000 isolated nodes blasted across the import block. I've then had to download the area from OSM and manually remove each node. Rather frustrating. I don't know the ins and outs of the OSM backend, but could you be picking up errors at that point? JOSM never seems to sort it out for me. :( Sam L Kamloops ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Here we go again...
OK... I had been using chunks of 2000, but will make it smaller. Hopefully that helps. Thanks Sam L -Original Message- From: john whelan jwhelan0...@gmail.com To: Samuel Longiaru longi...@shaw.ca Cc: Dan Charrois d...@syz.com, Talk-CA OpenStreetMap talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Here we go again... Date: Sun, 06 Mar 2011 12:12:00 -0500 In JOSM when uploading go to advanced configuration or the advanced tab and use upload data in chunks of objects. Drop the chunk level down to 400 or 500 and it goes much smoother. Cheerio John On 6 March 2011 11:15, Samuel Longiaru longi...@shaw.ca wrote: Hi Dan, Your procedure sounds pretty similar to mine, and working around Kamloops likely is equivalent in terms of the kinds of features we see. You probably do this as well, but before running the validator, I step around the edge of the import and connect streams, powerlines, and anything else that I think needs connecting. The auto-fix on duplicate nodes just seems to merge the nodes but doesn't combine the ways. As you, I very rarely have found the need to import a road as previous GeoBase or other imports have already provided the same information. I simplify some features as well (streams and some lake shorelines mostly) but I try to remember to simplify before merging the selection onto the OSM layer. Simplifying later often gives the warning that you are deleting nodes outside the uploaded data area. If I get a conflict, this is where it happens. You do, however, seem to have much better luck than I have had on failed imports. On 4 or 5 different occasions, an upload has hung (sometimes for hours) and a cancel has resulted in nodes only (no way information) being uploaded to the server. This behavior is quite consistent. The result is 6-8,000 isolated nodes blasted across the import block. I've then had to download the area from OSM and manually remove each node. Rather frustrating. I don't know the ins and outs of the OSM backend, but could you be picking up errors at that point? JOSM never seems to sort it out for me. :( Sam L Kamloops ___ 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 vs. GPS
Hey everyone I am presently preparing a careful import of Canvec data into Mantario area. I have stumbled across a trail that appears to be a GPS track. The problem is that while this trail did not overlap with the old old low detail lake data, it conflicts in some areas with the Canvec data. Which data should I adjust? The overlap between the two ranges for 17cm to 30m. An inspection using Landsat (sadly the best imagery for the region) favours Canvec. I realize that this is a tricky subject. I'm assuming Godwin's law does not apply to this list. Sam Dyck ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Secret routing demo.
Yes... I believe you have that correct now. No barrier as I remember. Thanks. The interchange at Highway 93 (Icefields Parkway) and the TransCanada was not routing correctly coming south off the Parkway. I made some minor edits there and hopefully that will fix it, but the Bing coverage is poor. Also, there has been a lot of construction through there as they twin the highway. Anybody with better local knowledge willing to give it a go? It's a bit of a dog's breakfast right now. http://osm.org/go/WOMm6ScJD-- Sam L. -Original Message- From: Adam Dunn dunna...@gmail.com To: talk-ca@openstreetmap.org, Samuel Longiaru longi...@shaw.ca Subject: Re: [Talk-ca] Secret routing demo. Date: Sat, 05 Mar 2011 08:38:46 -0800 Hwy 1;97/5 interchange west of Kamloops: heading east on 1, then changing to south on 5, motorway_link incorrectly tagged as oneway. Sam L, should [http://www.openstreetmap.org/browse/way/24446790] be a two-directional single carriageway or one way dual carriageways (has a concrete Jersey barrier in the centre)? I've set it to two-directional for now. Adam On Sat, Mar 5, 2011 at 8:14 AM, Andrew Allison andrew.alli...@gmail.com wrote: On Sat, 2011-03-05 at 08:06 -0500, Richard Weait wrote: On Sat, Mar 5, 2011 at 7:13 AM, Richard Weait rich...@weait.com wrote: I've fixed some continuity errors, etc. on Hwy 417 near Ottawa. I'm working now on the rest of 417, then I'll tackle 416. Ottawa is a mess. A disaster. Well my first test route, failed. I'm going to have to start inserting a lot of no left turn's signs into the map. Can't say it was a high priority in my mind before. ___ 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] Here we go again...
I'll second what Richard said. This whole argument of talk could have been avoided (or at least delayed) if someone had tried contacting me before I was accused. Perhaps I'm just upset but in my opinion it's better to raise the issue with the user first than on a list. We don't want another vreimer but I've found these trouble makers, are usually just misguided. Sa, Dyck ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Secret routing demo.
Amen to that. Now THIS would make a great JOSM tool. Just to test locally around an interchange or some such thing you're working on. That would be cool. This is catching the logic errors that other tools aren't. Sam L. -Original Message- From: Adam Dunn dunna...@gmail.com To: talk-ca talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Secret routing demo. Date: Sat, 05 Mar 2011 11:43:21 -0800 SNIP This site is great for finding route errors. OSM will really improve thanks to this. I can't believe how many errors there were, and major ones that would prevent road trip planning for travellers. Thanks Richard, and the other programmers involved! Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Routing errors, turn restrictions and median crossovers
I'm getting a number of crazy routings that suggest doing U-turns via emergency median crossovers. The crossovers are in the imports and they all throw errors in regards to service roads connected to motorways. I guess they could all get turn restrictions applicable to all but public service vehicles but does existing routing software make the distinction as to vehicle type anyway? Any suggestion as to how to treat these? We really don't want these kinds of routes. Thanks, Sam L. Kamloops ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Routing errors, turn restrictions and median crossovers
So just a blanket restriction on each one? I see the Public Service Vehicle class includes buses and the like which wouldn't use the crossovers anyway so that won't do it. Didn't see a way to tag for public emergency vehicle access only. Sam -Original Message- From: Russell Porter cont...@russellporter.com To: Samuel Longiaru longi...@shaw.ca Subject: Re: [Talk-ca] Routing errors, turn restrictions and median crossovers Date: Sat, 05 Mar 2011 20:35:52 -0800 Access=no? On Sat, Mar 5, 2011 at 8:00 PM, Samuel Longiaru longi...@shaw.ca wrote: I'm getting a number of crazy routings that suggest doing U-turns via emergency median crossovers. The crossovers are in the imports and they all throw errors in regards to service roads connected to motorways. I guess they could all get turn restrictions applicable to all but public service vehicles but does existing routing software make the distinction as to vehicle type anyway? Any suggestion as to how to treat these? We really don't want these kinds of routes. Thanks, Sam L. Kamloops ___ 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] Routing errors, turn restrictions and median crossovers
OK... access=no, emergency=yes. I'll tag one like that and see what the routing software does after the next update. Thanks... Sam -Original Message- From: Adam Dunn dunna...@gmail.com To: talk-ca talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Routing errors, turn restrictions and median crossovers Date: Sat, 05 Mar 2011 20:46:00 -0800 Rather than turn restrictions, what about tagging the service way itself as access=no,emergency=yes, or something similar? There's also an abandoned tag for access=emergency [http://wiki.openstreetmap.org/wiki/Proposed_features/emergency_vehicle_access]. Adam On Sat, Mar 5, 2011 at 8:00 PM, Samuel Longiaru longi...@shaw.ca wrote: I'm getting a number of crazy routings that suggest doing U-turns via emergency median crossovers. The crossovers are in the imports and they all throw errors in regards to service roads connected to motorways. I guess they could all get turn restrictions applicable to all but public service vehicles but does existing routing software make the distinction as to vehicle type anyway? Any suggestion as to how to treat these? We really don't want these kinds of routes. Thanks, Sam L. Kamloops ___ 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] Secret routing demo.
Hi Richard, Yeah, that's sounds quite useful. How do we do it? Sam L. Kamloops -Original Message- From: Richard Weait rich...@weait.com To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org Subject: [Talk-ca] Secret routing demo. Date: Fri, 04 Mar 2011 18:54:06 -0500 Dear talk-ca, There is a new secret demo of routing on OSM data for Canada. The demo server could go away without notice, and it doesn't update data regularly, but it seems to be blindingly fast. Also, it only works for part of Europe. Except it secretly works for part of Canada too! So far, I'm using this to test routing connectivity for the Trans Canada, and for major roads in my area. So far, i see that there is a continuity problem in Eastern Nova Scotia and I hear that there is a problem near the Manitoba / Ontario border. In both cases if you try a route, it looks funny or fails to route. Looking funny is often either a route that goes the long way 'round, or goes backwards, then forward, or past the destination then back. The fix is to go find the overlapping nodes that aren't connected, or the missing bridge or backwards oneway tag, and fix them. Great fun! It should help find import issues where we haven't properly stitched imports to existing data. Again, this router isn't yet updating often, so maybe we can put things we find and fix in this thread, so we don't chase our tails? Then maybe ask for an update after the weekend? What do you think? Feel like doing some secret routing repair? ;-) And thanks to Frederik at Geofabrik, for adding Canada to this demo. This is pretty cool. 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] Mapping cut blocks in wooded areas
Hi Everybody, I've been importing CanVec mostly south of Kamloops for the past several weeks and am going to take some time now to go back and bring stuff up to date. One question I have though is in regards to how to treat cut blocks in the wooded areas. I see according to the map features wiki, that the CanVec imported tag of natural=wood is technically not correct, at least for here, as wood is to be reserved only for completely reserved/unmanaged areas. I guess most of what I have should really be mapped as landuse=forest but I have not made the change because what is under timber lease and what is not would be difficult to determine. In one sense it's all managed to some degree or other. But my point is rather what should be done with the cut blocks, which in some areas constitute up to 50% or more of the forested area. http://osm.org/go/WJ1cj_R is a typical area. It seems improper to keep them as wooded when they are clearly not, and yet most are replanted and will be wooded again someday... or at least that's what they keep telling us. I started mapping them as it truly gives a more accurate representation of the current state of affairs on the ground... but thought I'd better get some guidance before proceeding too far. Thanks, Sam L. Kamloops ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Secret routing demo.
Thanks Richard. I tested it on the Trans Canada heading east of Kamloops towards Banff. It was routing through Edmonton. Wha??? Tracked it down to a divided section of the TC west of Field where both sides of the highway were marked as westbound. KeepRight didn't pick it up in this case. Fixed. Thanks for the link. Very quick indeed. Sam L -Original Message- From: Richard Weait rich...@weait.com To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Secret routing demo. Date: Fri, 04 Mar 2011 22:19:01 -0500 On Fri, Mar 4, 2011 at 6:54 PM, Richard Weait rich...@weait.com wrote: Dear talk-ca, There is a new secret demo of routing on OSM data for Canada. The demo server could go away without notice, and it doesn't update data regularly, but it seems to be blindingly fast. Also, it only works for part of Europe. Except it secretly works for part of Canada too! Oops. guess I should have included the link! http://routingdemo.geofabrik.de/ I've found that routing even extends over the border a short way too, though I've only checked a few places so far. ___ 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
Well, that was my feeling as well. Maps are living things and designed to be changed. OK... if the blocks look like they have greened up after replanting or otherwise, I will leave the cut blocks as wooded, otherwise they will be mapped as a hole. Thanks... Sam L -Original Message- From: Daniel Begin jfd...@hotmail.com To: 'Samuel Longiaru' longi...@shaw.ca, 'talk-ca' talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Mapping cut blocks in wooded areas Date: Fri, 04 Mar 2011 23:18:58 -0500 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 over time, we can keep mapping !-) Daniel From:Samuel Longiaru [mailto:longi...@shaw.ca] Sent: March-04-11 21:45 To: talk-ca Subject: [Talk-ca] Mapping cut blocks in wooded areas Hi Everybody, I've been importing CanVec mostly south of Kamloops for the past several weeks and am going to take some time now to go back and bring stuff up to date. One question I have though is in regards to how to treat cut blocks in the wooded areas. I see according to the map features wiki, that the CanVec imported tag of natural=wood is technically not correct, at least for here, as wood is to be reserved only for completely reserved/unmanaged areas. I guess most of what I have should really be mapped as landuse=forest but I have not made the change because what is under timber lease and what is not would be difficult to determine. In one sense it's all managed to some degree or other. But my point is rather what should be done with the cut blocks, which in some areas constitute up to 50% or more of the forested area. http://osm.org/go/WJ1cj_R is a typical area. It seems improper to keep them as wooded when they are clearly not, and yet most are replanted and will be wooded again someday... or at least that's what they keep telling us. I started mapping them as it truly gives a more accurate representation of the current state of affairs on the ground... but thought I'd better get some guidance before proceeding too far. Thanks, Sam L. Kamloops ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
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 To: 'talk-ca' talk-ca@openstreetmap.org 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 over time, we can keep mapping !-) Daniel From: Samuel Longiaru [mailto:longi...@shaw.ca] Sent: March-04-11 21:45 To: talk-ca Subject: [Talk-ca] Mapping cut blocks in wooded areas Hi Everybody, I've been importing CanVec mostly south of Kamloops for the past several weeks and am going to take some time now to go back and bring stuff up to date. One question I have though is in regards to how to treat cut blocks in the wooded areas. I see according to the map features wiki, that the CanVec imported tag of natural=wood is technically not correct, at least for here, as wood is to be reserved only for completely reserved/unmanaged areas. I guess most of what I have should really be mapped as landuse=forest but I have not made the change because what is under timber lease and what is not would be difficult to determine. In one sense it's all managed to some degree or other. But my point is rather what should be done with the cut blocks, which in some areas constitute up to 50% or more of the forested area. http://osm.org/go/WJ1cj_R is a typical area. It seems improper to keep them as wooded when they are clearly not, and yet most are replanted and will be wooded again someday... or at least that's what they keep telling us. I started mapping them as it truly gives a more accurate representation of the current state of affairs on the ground... but thought I'd better get some guidance before proceeding too far. Thanks, Sam L. Kamloops ___ 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] Reply to concerns about CanVec imports in Quebec
Hi Everyone I've had a busy week. Sorry I wasn't paying attention to the discussions. I will be frank. I have never imported Canvec data outside of Manitoba (except where the tiles overlapped into Saskatchewan. I deny any involvement in the area surrounding Aylmer, Quebec. It is possible I may have made small edits there and they may have been part of a Canvec import elsewhere, but I personally did not knowingly perform any imports. Thank you. I apologize for any confusion. Samuel Dyck ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] My CanVec imports in the Ottawa area
Cross posted on Talk-ca Hi Everyone I've had a busy week. Sorry I wasn't paying attention to the discussions. I will be frank. I have never imported Canvec data outside of Manitoba (except where the tiles overlapped into Saskatchewan. I deny any involvement in the area surrounding Aylmer, Quebec. It is possible I may have made small edits there and they may have been part of a Canvec import elsewhere, but I personally did not knowingly perform any imports. Thank you. I apologize for any confusion. Samuel Dyck ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Simplifying CanVec imports
Yes, the import seems to be quite a selective process! Very tedious at times. And now that I am getting into areas where there actually is some existing OSM data and I have spent so much time hand editing in the past, I'm pretty careful to select the better data on a way-by-way basis. Sometimes the CanVec data wins out, sometimes not. In regards to simplifying, however, I am quite pleased to note that I have not seen displacement or removal of a node that sits at the edge of a tile. I'm sure they are just taken as end points. Simplifying a feature that will ultimately run from one tile to the next still yields duplicate nodes at the boundary when the next file is brought in. The stitching procedure is the exactly the same. Merge nodes and combine ways where appropriate. I just think it is a great tool that admittedly may only have limited applications. But I think that this situation is definitely one of them. Sam -Original Message- From: john whelan jwhelan0...@gmail.com To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org Cc: Samuel Longiaru longi...@shaw.ca Subject: Re: [Talk-ca] Simplifying CanVec imports Date: Sun, 13 Feb 2011 18:41:21 -0500 There are always issues when you want to replace one set of data with another. People may have added labels such as the name in French, replace the import and you lose the French. Where the CANVEC tiles meet ways are connected by overlapping points. Any simplification at this point that moves a point on a way means the way doesn't get joined where the tiles meet. This is why it''s so tempting to start over from CANVEC 7 then add in the detail, amenities, shops etc. At least you can have confidence that the road names are correct. Cheerio John ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Simplifying CanVec imports
Good Morning Everyone, For the past couple of weeks I have been importing CanVec data into an area southwest of Kamloops. There was very little (if any) existing OSM data in the area. I've gotten into a bit of a rhythm, merging and stitching all of 92I07 and about half of 92I10 but started becoming concerned about the high data density, particularly associated with streams in the area. Most import files at the level of 92 I 07.0.0 for example, are runnning 10-15k nodes. At that rate, that is somewhat near 200,000 nodes for an area at the level of 92I07. Yikes! I guess the question in my mind is just how many data do we want to import at this level and what are the practical implications for server processing and overload. I expect that this level would be fairly consistent across most of Western Canada. Even now, I haven't been able to call up a complete map in the openstreet.org view tab for the past 4 or 5 days... 25-50% of the map being covered with ... more OSM coming soon tiles. I looked at the Simplify Way function in JOSM and applying it to just the water data, have been able to eliminate 5-8k nodes from each file, thereby cutting the data in nearly half. I really don't see any significant degradation in the map quality as a result. Without simplifying, the data nodes in some places are incredibly (and undeservedly ) dense. The only discussion I've been able to find on the simplify tool is some rather old discussion that took place during development. So just wondering if simplifying these data is a reasonable approach. Right now, I am going back to the imported areas, calling them up from OSM, simplifying the water, and re-uploading the simplified data. In the future, I will just simplify in JOSM before uploading the file in the first place. Anyway, does anyone have any issues with my approach here? Is it worth simplifying or am I being overly concerned about data density and its longer term implications? Thanks, Sam Longiaru Kamloops, BC ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] How should a noob proceed?
G'morning Everyone, Thanks to all who responded to my request for advice and guidance. As a result I received some excellent instruction as how how to import CanVec data. I've since been able to upload two adjacent files to the database... both from a remote area SW of Kamloops. One had no existing OSM data at all and the other had only a small section of an unpaved road. The import has led to several questions regarding stitching data at boundaries, but I should probably best pursue those problems off-list. Anyway, thanks again. Sam Longiaru Kamloops, BC ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] How should a noob proceed?
Regarding your specific import Sam, could you link to it for us? I see the wooded areas on the border, but that sounds a little further than away from Kamloops than you. Share! ;-) Were these full size NTS tiles or sub tiles? Are they of a manageable size for stitching. How long did it take? Should we make a group effort of stitching before moving on the the next import? Many open questions. :-) Best regards, Richard OK... well if you think that my questions are relevant here... then sure... maybe a wider audience is best anyway. Perhaps I'm falling into the noobie trap of assuming that I'm the only one that doesn't know this stuff. I've just sent the message (copied below) to Steve Singer who was kind enough yesterday to get back with some pretty specific advice. It's funny in that my questions to him were pretty much right along what you are posing, Richard. One file was about 14,500 'objects' and the other 12,500. After merging the CanVec layer and the (almost non-existent) OSM data layer, JOSM choked on the first file upload and got into a Retry loop. I figured that 14,000+ points was too big a request and so found the Advanced tab and asked for an upload in 2000 object chunks. That worked. I'm sure that this approach of uploading a whole CanVec file will not be practical once the merges become more complicated and I will sure resort to working on and uploading only small sections of a sheet at a time. But for this area, where there is very little to edit, the full file approach works. I'm just going to work on these two files for the time being, cleaning them up as I import, and learning the procedure better. Also, I just have to get better with JOSM I see. Pretty steep learning curve I've found. OK... crux of my message to Steve is below... it includes a link to the area Thanks in advance. Sam Steve... Last night I imported two adjacent CanVec files... 92I07.0.0 and 92I07.0.1. The process was pretty easy as the only overlap with existing OSM data was one unpaved road, which I deleted from the CanVec layer before merging. I went back this morning to review the imports and have a few questions. If you don't mind, could you please take a look at http://osm.org/go/WJ1AWUau and give me your opinion. I think this small area along the boundary of the two imports shows most of the issues. 1) At first, I thought I should get rid of the boundary between the north and south sheets, but then realized that doing so for each import would eventually lead to massive relations of wooded area. So would you agree that I should leave the bounding ways alone, only working on merging or joining cross-boundary objects such as roads, railroads, etc., or should I treat the bounding ways somehow ? 2) I am surprised in that the registry between the different objects in the CanVec data is not better than it is... at least in this area. For the most part, the boundary of the wood (whether outer or inner) seems to be shifted westward in relation to the lake outlines which are at least fairly consistent with the Bing imagery. This internal shift within the CanVec data seems to triggering a lot of errors... overlapping areas, crossing ways, etc. The shift seems to line up across both sheets. Is this expected, and if so, should I just correct errors as usual, using the Bing imagery as a guide? Or is this error something that happened when converting the data to OSM format? 3) And this is a real noob question... in JOSM some nodes along a single isolated ways such as lake shores are marked with small boxes and some with +. Can't seem to find any difference or rhyme or reason. What is the significance of those? Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Bilingual operator names
Hi When I tag government facilities, I put the name in the predominant local language (English in Manitoba) in the name tag. Put the English name in the English name tag and the French name in the French name tag. But what about the operator tag? For example Winnipeg has a facility know in English as the Centre for the Commercialization of Biomedical Technology, which is run by the organization known in English as the National Research Council and in French as Le conseil national de recherches Canada (that is the capitalization used on their website). So when put them in the operator tag, how do I handle the name. Do I - Create operator:en and operator:fr tags? - Put both names in the operator tags? Thanks Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Bilingual operator names
I took your advice and went east to Ottawa. I assumed that Parliament Hill would be a good model to follow. Sadly it is tagged exclusively in English as is the Supreme Court. Perhaps someone with with better French than myself should fix that. On the other side of the Ottawa River, The Museum of Civilization sets a better example by using a slash, which is what I will use. Sam On 11-01-25 07:23 PM, Sam Vekemans wrote: Some would argue that including a 'space' and forward slash '/' and French name, to be all on the same line. (some datasets do this) and others would argue that 'french rendermap' should show all french. . so it's osm, it's not perfect ... so just check out another federal facility that has french and copy :) Some would argue that we need a 'strict set of rules' ... and others argue 'free form rules with the masses and loudest' :) cheers, sam On 1/25/11, Samuel Dycksamueld...@gmail.com wrote: Hi When I tag government facilities, I put the name in the predominant local language (English in Manitoba) in the name tag. Put the English name in the English name tag and the French name in the French name tag. But what about the operator tag? For example Winnipeg has a facility know in English as the Centre for the Commercialization of Biomedical Technology, which is run by the organization known in English as the National Research Council and in French as Le conseil national de recherches Canada (that is the capitalization used on their website). So when put them in the operator tag, how do I handle the name. Do I - Create operator:en and operator:fr tags? - Put both names in the operator tags? Thanks Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Purging vreimer
Hi I've been looking at replacing much of vriemer's work in manitoba with Canvec data. Even replacing one tile is a daunting task, so I thought I'd ask the opions of others before I start work staring with Canvec tile 062H10. What do people think? Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Purging vreimer
Another thing we need to think about. Whatever you position on the license change, it is doubtful vreimer will take the trouble to consent to the new terms. So we should probably gat all his stuff removed anyways. Sam Sam On 11-01-14 09:50 PM, Sam Vekemans wrote: What would be great is to extract an .osm file containing only vreimer's edits. Is this possable? It would be great to have this file, so then after vreimer's edits gets removed reom the osm api, they can be used to make other maps. and added into other api's :-) On 1/14/11, Samuel Dycksamueld...@gmail.com wrote: Hi I've been looking at replacing much of vriemer's work in manitoba with Canvec data. Even replacing one tile is a daunting task, so I thought I'd ask the opions of others before I start work staring with Canvec tile 062H10. What do people think? Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Schools becoming prisons in Canvec 7
Hi I've been merging the street names from Canvec 7 in areas in Manitoba with Canvec 6 imports sans street names. And I noticed that what CanVec 6 called schools have all become prisons in Canvec 7. Now I aware of prison overcrowding problems but I doubt that all the schools in southern Manitoba have become penitentiaries. How would I go about reporting this error? Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] While we're talking about canvec.osm
Hi I was importing tile 062F12 (MB/SK border near The Pas MB) when I noticed that the portion of the CN Turnberry rail line that would go in the tile is missing. What's interesting is that since that line has VIA service the stations along the line are shown. Was this a deliberate omission because it is a remote area or a simple error? Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Merging canvec data into existing lakes
Hi How would I take canvec lake data into already mapped lakes that stretche outside the canvec tile? Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Merging canvec data into existing lakes
Awesome, thanks. Sam On 10-11-18 09:41 PM, Adam Dunn wrote: This kind of depends on quality of each source (has the lake been modified since either OSM or Canvec traced it?). I'll assume you're talking about a case where Canvec has better positional data than OSM, but you don't want to wipe out OSM completely, or it could be a while before you import the lake in other tiles (some lakes can span many Canvec tiles and we don't want half-lakes on our maps!) First check the lake in OSM to make sure there aren't any interesting tags that could get lost (boat launches, alternative names, etc.) If there's nothing of particular interest in OSM currently, what I do is split (keyboard command 'p' in josm) the lake in OSM and Canvec at the boundary of the tile, then delete the OSM data in the tile I'm importing, and the line of the lake along the boundary in Canvec. So instead of having two closed lakes (two O figures), I now have two non-closed lakes (one will be a U shape, the other an upside-down U). Then merge the nodes (keyboard 'm') and combine the ways (keyboard 'c'). In the end you'll have one lake that is using Canvec data where you just imported, and original OSM data where you haven't yet. When you get around to importing the other areas, you split/merge/combine again so the whole lake is now Canvec sourced. Adam On Thu, Nov 18, 2010 at 4:00 PM, Samuel samueld...@gmail.com mailto:samueld...@gmail.com wrote: Hi How would I take canvec lake data into already mapped lakes that stretche outside the canvec tile? Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org mailto: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] The most peculiar quirks of JOSM
Hi Everyone So I'm took advantage of the long weekend to fool around with CanVec imports, and I discovered to root of many of my problems. It appears that while I am editing, some areas from CanVec loose all their tags, eventually leaving me with a map scattered of untagged ways. I am running JOSM 3514. Is this an isolated problem? It's late now, so tomorrow I'll do some poking around and maybe file a bug report. Wishing you all a pleasant Thanksgiving Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] More CanVec import problems
This is odd, I thought I checked for that, when I opened that same file in JOSM it did some up as part of a relation. Oh well, whatever. I have no free time for a while and a Russian novel to finish for a course, but I'll eventually get to uploading it. Thanks Sam On 10-10-03 08:03 PM, Adam Dunn wrote: I'm sorry, I misread your email. I thought the untagged way was currently in OSM, but you are saying it's in the Canvec file. I downloaded 062G01 from ftp://ftp2.cits.rncan.gc.ca/osm/pub/062/G/062G01.zip (the ftp says last modified July 13, so there haven't been any updates or corrections to it), and I still don't see any bad ways. There are some ways that have no tags, but that is because they are members of relations. It is normal for relations that are multipolygons to not have tags on some of the ways. See [http://wiki.openstreetmap.org/wiki/Multipolygon] for more about multipolygons. I've taken a screenshot of a way in 062G01.0.osm near 49.1000, -98.3150. You can see the way is highlighted in white with directional arrow whiskers. In the Properties pane there are no tags for the way itself, but it does say it's a member of a wood multipolygon with 83 members total. Do you not get something similar? You would then right-click the relation listed, Select relation, and then copy-paste from one layer to another. Adam On Sun, Oct 3, 2010 at 3:53 PM, Adam Dunn dunna...@gmail.com mailto:dunna...@gmail.com wrote: In Josm, you can check out the history (the blue book in the toolbar opens up the history pane, or you can go to Tools-Object History, or you can press ctrl-h). If it's a new way (past day or so) then just wait a bit. If it's old (more than a month and hasn't been edited since), then see if it matches something logical on Canvec or Yahoo Aerial, and either update/tag or delete. If it's a way that you yourself just recently uploaded, then something may have gone wrong in the upload process. I just downloaded the area in Josm, and don't see any untagged ways. Could you send a link to the way (for example [http://www.openstreetmap.org/browse/way/69488706]) so that other people can see what you're talking about? (You can get it in your web browser by going Tools-Info About Element or pressing ctrl-i) Adam On Sun, Oct 3, 2010 at 12:38 PM, Samuel samueld...@gmail.com mailto:samueld...@gmail.com wrote: So I tried, importing tile 062G01, but looking at it in JOSM I discovered one massive untagged way. Do I just need to wait for the OSM XML data to be refreshed? Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org mailto: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] Fwd: Re: CanVec import troubles
Original Message Subject:Re: [Talk-ca] CanVec import troubles Date: Mon, 27 Sep 2010 21:19:49 -0500 From: Samuel samueld...@gmail.com To: Adam Dunn 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 mailto: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
Re: [Talk-ca] CanVec import troubles
Hi Everyone So I had some computer trouble for a few days, limiting my access to email. Firstly thanks to everyone for tolerating questions from someone who until recently knew almost nothing about GIS. I have a few more questions that I hope should clear everything up. Firstly, in response to what Daniel was saying, I took a closer look at that trail, It appears it is actually a winter road. But since the lake coastline data is a real lake, why would I delete it, would the CanVec data replace it? Also why is only one of the sub tiles forested on the map? Also Tyler, where are you getting the find building data from MLI? I couldn't find it on their website, unless your tracing it from their Ariel imagery. Sam On 10-09-20 08:32 AM, Bégin, Daniel wrote: Bonjour Samuel, I've had a look at the problem using the history provided with the data overlay (+ sign on top right corner of http://www.openstreetmap.org/?lat=56.12056lon=-96.20386zoom=15layers=M ) ... - Original Canvec data you imported - wood, water, ferry route and trails *Edited by efred at 2010-09-15T08:10:57Z *Edited by sammuell at 2010-09-13T02:09:21Z - The ferry route on land looks like a displaced copy of the nearby Canvec ferry route *Edited by sammuell at 2010-09-13T02:07:22Z - The trail is in the water because you did not remove/edit the the water area that was there before your import. This water looks like the natural=coastline;source=PGS imported few years ago to add large water bodies in Osm. *Edited by vreimer at 2010-02-10T00:10:52Z *Edited by PA94 at 2009-11-22T18:16:21Z *Edited by PA94 at 2009-11-22T17:52:42Z *Edited by roberteals at 2008-12-12T16:37:13Z This water is inconsistent with the Canvec data you imported. Remove this water area and the trails will get on land as expected !-) Cheers, Daniel -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Samuel Sent: 19 septembre 2010 17:40 To: Tyler Gunn Cc: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] CanVec import troubles Only one of the subtiles in forested, there are ferries on land and trails on water Tyler Gunn wrote: On Sun, 19 Sep 2010 14:32:42 -0500, Samuelsamueld...@gmail.com wrote: Hi I've been playing around with importing CanVec, and imported some data, but as you can see here (http://www.openstreetmap.org/?lat=56.059lon=-96.291zoom=11layers= M), it is a terrible mess. Where did I go wrong and how do I fix it? It seems okay to me. What exactly did you notice is going wrong with it? 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
[Talk-ca] Islands of Manitoba in Nunavut
While where on data problems, what's up with these things on the MB-NU border (http://www.openstreetmap.org/?lat=60.0183963775635lon=-95.9642028808594zoom=13). The source given is geobase. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] CanVec import troubles
Hi I've been playing around with importing CanVec, and imported some data, but as you can see here (http://www.openstreetmap.org/?lat=56.059lon=-96.291zoom=11layers=M), it is a terrible mess. Where did I go wrong and how do I fix it? Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec import troubles
Only one of the subtiles in forested, there are ferries on land and trails on water Tyler Gunn wrote: On Sun, 19 Sep 2010 14:32:42 -0500, Samuel samueld...@gmail.com wrote: Hi I've been playing around with importing CanVec, and imported some data, but as you can see here (http://www.openstreetmap.org/?lat=56.059lon=-96.291zoom=11layers=M), it is a terrible mess. Where did I go wrong and how do I fix it? It seems okay to me. What exactly did you notice is going wrong with it? Thanks, Tyler ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Random nodes after canVec import
Hi So data for morris has been imported (Thank you John), but looking at the data in JOSM show hundreds of blank nodes in town. Do these serve a purpose? Also I noticed that some data is being imported from the Manitoba Lands initiative. I noticed that they have maps of many small towns and that the one for Morris had names for streets I either didn't get to or were unlabled. The license looked fine, can we copy their information? Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Importing CanVec
Hi After thinking about it for a while, I realized that I can keep relying on others to do CanVec imports for me, so I resolved to figure out how to do it myself. I have a few questions. 1. Can and import be done using just JOSM? 2. If not, how do I convert the SHP file to OSM XML? 3. How do I merge the existing OSM data into the CanVec data? Thanks Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Importing CanVec
Thanks, I'm importing tile 064A01 and I'll see how that goes. Sam john whelan wrote: The CANVEC data is available her ftp://ftp2.cits.rncan.gc.ca/osm/pub Read this page first: http://wiki.openstreetmap.org/wiki/CanVec especially the bit about the tiles. I would suggest you load up a tile in JOSM then hit the download arrow to bring in the same area from OSM. I usually resize the JOSM window to keep the downloaded area roughly the same as the leaded file. Then use layers inspect the downloaded area. Back to the CANVEC tile and select the items you want to import. Use Edit merge selection, back to the data layer and hit the upload button. I suggest selecting one attribute at a time so if there are no roads there select highway=whatever then merge it up. JOSM and the upload process isn't 100% reliable so by keeping the uploads fairly small it seems to work better. Cheerio John On 12 September 2010 21:22, Samuel samueld...@gmail.com wrote: Hi After thinking about it for a while, I realized that I can keep relying on others to do CanVec imports for me, so I resolved to figure out how to do it myself. I have a few questions. 1. Can and import be done using just JOSM? 2. If not, how do I convert the SHP file to OSM XML? 3. How do I merge the existing OSM data into the CanVec data? Thanks Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Morris
Hi I had an opportunity to visit the town of Morris, Manitoba (http://www.openstreetmap.org/index.html?mlat=49.355mlon=-97.365zoom=15layers=B000FTF). Seeing as little mapping had been done in that area, I resolved to map it. My usual technique involves surveying the streets at home, then printing out the map and making notes. Unfortunately Yahoo! aerial imagery for that area is non existent and I couldn't get the Geobase WMS server to serve the Geobase imagery in JOSM. So I downloaded the appropriate GeoTIFF from Geobase and built the unstable version of Merkaartor from source, the build I created was just that, unstable. So I tried converting the TIFF to a JPEG and using JOSM's Piclayer plugin, which sadly also failed, as did my attempts at downloading the NRN and CanVec data directly and importing it into JOSM and an older version of Merkaartor. I tried using actual GIS software, but realized that I know very little about how to use it and didn't have time to learn. By this time it was getting pretty late and I had to get up early the next morning. So I opened up the Geobase image in Inkscape and created a rough trace of the roads from that. So I know have a rough sketch of the roads and names to go with them, however, I need someone to import the roads into OSM for me so I can finish the job. The Canvec Dataset is 62H6. Thanks Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Uploading geobase imagery
Hi Would it be possible to get the geobaseOrthoimage imagery up as and alternative to the Yahoo! Ariel imagery in Potlatch? In many rural areas the 10 metre imagery has significantly better resolution. Sam From: talk-ca-requ...@openstreetmap.org talk-ca-requ...@openstreetmap.org To: talk-ca@openstreetmap.org Sent: Monday, February 16, 2009 8:30:57 PM Subject: Talk-ca Digest, Vol 12, Issue 10 Send Talk-ca mailing list submissions to talk-ca@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-ca or, via email, send a message with subject or body 'help' to talk-ca-requ...@openstreetmap.org You can reach the person managing the list at talk-ca-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-ca digest... Today's Topics: 1. CanVec /geobase NIDs (Sam Vekemans) 2. Re: OSM Geobase import: giving a try (Frank Steggink) 3. OSM GeoBase import: giving a try (Richard Degelder) 4. Re: OSM Geobase import: giving a try (Steve Singer) 5. Re: GeoBase Wiki edits (Steve Singer) 6. Re: GeoBase Wiki edits (Sam Vekemans) 7. Automatch for importing NHD (Sam Vekemans) 8. Re: OSM Geobase import: giving a try (Frank Steggink) -- Message: 1 Date: Sun, 15 Feb 2009 13:44:06 -0800 From: Sam Vekemans acrosscanadatra...@gmail.com Subject: [Talk-ca] CanVec /geobase NIDs To: stegg...@steggink.org, talk-ca@openstreetmap.org Message-ID: 9dbbf3b20902151344k4741f45fk1b346be3a5f83...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, welcome to the team! I look forward to seeing the progress on the 021L07 area. Your questions were already answered, and thank you, as it gives me a better idea of how to make the wiki more clear :) re: nids i brought up the issue again as it needs to be further explained on the wiki, (with respect to CanVec also) as there is always 2 sides to decisions. -notion of 'expectancy' needs to be adressed in 1 page or less, and clearly understood. I am more in favor of using the 'automatch' for ALL map features. Does anyone know that the python script line that adds the OSM tags from the Database file. Hopefully someone can help? Trial error is the other method :) cheers, Sam -- Message: 2 Date: Sun, 15 Feb 2009 18:05:48 -0500 From: Frank Steggink stegg...@steggink.org Subject: Re: [Talk-ca] OSM Geobase import: giving a try To: Steve Singer ssinger...@sympatico.ca Cc: talk-ca@openstreetmap.org Message-ID: 49989fcc@steggink.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi Steve, Thanks for your response. Yes the wiki needs a cleanup, I've been hoping someone else would do it since that doesn't seem to be happening I will try to find sometime soon to delete all obsolete information from the wiki pages. I'll try to do some cleanup, once I have a better understanding of th eefforts of others. Yes please try to keep nids for data that actually comes from geobase. Not importing could limit us in the future. In what way would it limit us? When we'll receive a new dataset from Geobase? Or do you hint towards other datasets which are linked to the NID? In that case that additional data can't be linked to existing database, because that doesn't contain the NID attributes. b. How can we guarantee that the final import will be consistent? (See also my first question.) Depends what you mean by consitent. 1. Using consistent tags for things, the best way to ensure this is to look at what others are doing and share your scripts. 2. data consistency, ie roads line up and are joined between different imports or between the existing and geobase data. Right now we have no automated consistency tools, we are depending on people to manually line up/connect ways post import. Both meanings were intended. I wonder if automatic consistency will work. It seems to have a too high chance of failure. You are free to use your own processes and software. I don't think any two people are doing the exact same thing for importing. This is the process I follow You don't need to use roadmatcher, you just need to have some method of avoiding hundreds of duplicate roads. I actually wanted to use PostgreSQL/PostGIS, but it seems that no OSM data can be exported from it. At least not when OSM data was previously imported through osm2pgsql. Maybe it will work to keep the Geobase data in Postgis, export as OSM, and then apply some postprocessing (fixing in JOSM). For comparision purposes what I've done with the larger areas in Alberta: 1. Populate a postgis database with the NRN shapefile 2. Populate a postgis database with the OSM data using osm2pgsql 3. Generate a NRN and OSM shapefile for the area that I'm interested in using
[Talk-ca] NHN lake of the woods
Hi It looks like the NHN data is flawed because of the fact that the Lake of the Woods passes through the US. I will continue with mapping as normal. I notice that I am not the only one mapping the lake. I pay much more attention to detail than others. Is that okay? Sam __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at http://ca.toolbar.yahoo.com.___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
