[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] 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] 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] 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] 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
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
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] 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
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
