[Talk-ca] Canvec-OSM FTP Down?
Just tried to download a tile from http://ftp2.cits.rncan.gc.ca/osm/pub and the server is saying the directory doesn't exist. Hopefully just a temporary thing, but does anybody know what's going on? Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] License of iD Editor
For all the talk about Canadian cities choosing to craft their own license rather than choose a well-known license, I find it interesting that the new iD editor is licensed under the WTFPL. WTF, indeed. It was probably only chosen because it's the same license as Potlatch. At least it's approved by OSI as GPL-compatible. Seeing as how it's OSI approved, I'm not suggesting it be relicensed, but it would've been nice to not have to look it up on Wikipedia before looking at the code. Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Duplicate BC, Canada geometry
Hmm, I think the last time I did imports in BC was back in 2010, and I thought I was careful about leaving the map in a correct and consistent state. Azub's imports are all in the Prince George or north area, and I definitely know I haven't touched that area in a long time. Got any examples or changeset numbers? The nature of doing imports like Canvec tends to be spread over large areas and large amounts of time. Any suggestions on techniques for coordinating efforts? An email to the list saying I'll be working on Prince George area this week? A shared spreadsheet? Adam On Sat, Feb 16, 2013 at 7:27 PM, the Old Topo Depot oldto...@novacell.comwrote: Users Adam Dunn (http://www.openstreetmap.org/user/Adam%20Dunn), alester_imports (http://www.openstreetmap.org/user/alester_imports), and azubimport (http://www.openstreetmap.org/user/azubimport) are duplicating way geometry from multiple sources, in some cases within a few days of each other. Will the three (hopefully there are not more) of you please coordinate your efforts, review your recent work, and de-duplicate way geometry and tagging in BC, Canada (and elsewhere, if applicable). I presume you've been engaging with the import list, copied ... Thanks and best -- John Novak 585-OLD-TOPOS (585-653-8676) http://www.linkedin.com/in/johnanovak/ OSM ID:oldtopos OSM Heat Map: http://yosmhm.neis-one.org/?oldtopos OSM Edit Stats:http://hdyc.neis-one.org/?oldtopos ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Duplicate BC, Canada geometry
Okay, so I was using that spreadsheet back when I was doing my BC import (look at the 91-99 sheet, and some of the 81-89 sheet), but it seemed as if many people weren't using it and it was difficult to maintain. You can also see that Azub's imports seem to post-date mine by 1-2 years. Adam On Sat, Feb 16, 2013 at 8:51 PM, David E. Nelson denelso...@yahoo.cawrote: There is a spreadsheet on Google Docs that serves this very purpose. It's located here. http://spreadsheets.google.com/ccc?key=0Am70fsptsPF2dERFUlBodFFmbmJiR3BBMHR4MzJDM1Ehl=en - David E. Nelson -- *From:* Adam Dunn dunna...@gmail.com *To:* the Old Topo Depot oldto...@novacell.com *Cc:* impo...@openstreetmap.org impo...@openstreetmap.org; talk-ca talk-ca@openstreetmap.org *Sent:* Saturday, February 16, 2013 7:44:45 PM *Subject:* Re: [Talk-ca] Duplicate BC, Canada geometry Hmm, I think the last time I did imports in BC was back in 2010, and I thought I was careful about leaving the map in a correct and consistent state. Azub's imports are all in the Prince George or north area, and I definitely know I haven't touched that area in a long time. Got any examples or changeset numbers? The nature of doing imports like Canvec tends to be spread over large areas and large amounts of time. Any suggestions on techniques for coordinating efforts? An email to the list saying I'll be working on Prince George area this week? A shared spreadsheet? Adam On Sat, Feb 16, 2013 at 7:27 PM, the Old Topo Depot oldto...@novacell.com wrote: Users Adam Dunn (http://www.openstreetmap.org/user/Adam%20Dunn), alester_imports (http://www.openstreetmap.org/user/alester_imports), and azubimport (http://www.openstreetmap.org/user/azubimport) are duplicating way geometry from multiple sources, in some cases within a few days of each other. Will the three (hopefully there are not more) of you please coordinate your efforts, review your recent work, and de-duplicate way geometry and tagging in BC, Canada (and elsewhere, if applicable). I presume you've been engaging with the import list, copied ... Thanks and best -- John Novak 585-OLD-TOPOS (585-653-8676) http://www.linkedin.com/in/johnanovak/ OSM ID:oldtopos OSM Heat Map: http://yosmhm.neis-one.org/?oldtopos OSM Edit Stats:http://hdyc.neis-one.org/?oldtopos ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Disgardable NHN and NRN tags
I'd keep the accuracy:meters around. I've used that for other things (mainly denoting how accurate my gps is in obtaining geodetic survey markers, or what the accuracy is based on number of sample points being averaged). Wouldn't want JOSM to be wiping those out. I think the ways tagged with sub_sea would need to be deleted, not just the tag itself. These tend to be hydrological topology connectors under lakes that show how rivers are connected. The entire way should be deleted to bring it in line with the rest of OSM. Not too sure about the waterway:type tag. Might be used in other places for other things? Can't think of anything stopping us from getting rid of geobase:* tags. Canvec imports don't have this, so it's inconsistent across the country, and it's probably not used anywhere else. Adam On Sun, Jul 29, 2012 at 5:43 PM, Steve Singer st...@ssinger.info wrote: On Sun, 29 Jul 2012, Paul Norman wrote: This is based on http://lists.openstreetmap.org/pipermail/talk-us/2012-July/008830.html, a recent talk-us@ discussion about TIGER tags. Parts of this message are a copy/paste from there. I think the following can be safely dropped: geobase:datasetName geobase:uuid I agree. When I started the geobase road imports it predated the ability to add changeset tags or comments. A lot of my reasoning for having those tags was to be able to traceback objects to their original Geobase objects so we could come up with a way of updating OSM with future versions of the Geobase data. These tags have never (to my knowledge) been used for this and I doubt they would be very useful for this purpose if anyone tried to do so. accuracy:meters waterway:type sub_sea:type Any thoughts? ___ 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] How did you start in OSM?
I probably read the same article as RWeait. Couldn't contribute much, as I didn't have a GPS at the time though. My father got a GPS that Christmas, so I added my home street. I'm pretty sure it was the first street to be added to British Columbia. I think it was a couple months later that the Yahoo aerial imagery was made available, then the NRN road dataset, and now Canvec. I've since gotten a new GPS unit (Garmin is much better than Magellan, especially for us Linux folk), and am now mapping out hiking trails in the Yellowknife area. Adam On Fri, Jul 6, 2012 at 7:16 AM, James Ewen ve6...@gmail.com wrote: On Fri, Jul 6, 2012 at 5:27 AM, Richard Weait rich...@weait.com wrote: Do you remember how you first heard of OSM, or first got mapping? March 2008... not sure how I heard about OSM, I think it was through something geocache related, maybe a post by someone. I went to the OpenStreetMap website signed up and started adding roads in my neighborhood. I went out and drove every road in my neighborhood, came back uploaded the track from my GPS, and got after it. First GPS trace upload March 3,2008. http://www.openstreetmap.org/user/VE6SRV/traces/80805 Found the wiki and created a page for Strathcona County a couple days in... still waiting for anyone to find the page and join in on mapping the area though. http://wiki.openstreetmap.org/wiki/Canada:Alberta:Strathcona_County There's a bit of a difference in the map from when I started! There are a couple map captures on the page. Without the CanVec data, the map would still be looking pretty bleak! -- James VE6SRV ___ 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] BING Maps high resolution in Canada
Don't forget that you can check age at: http://mvexel.dev.openstreetmap.org/bing/ and resolution at: http://ant.dev.openstreetmap.org/bingimageanalyzer/ Hurray! They finally have imagery of Yellowknife available. Well, the eastern half of Yellowknife at least - not my house. How is it that people in the east always get things first? Adam On Thu, Jun 14, 2012 at 12:27 PM, Bruno Remy bremy.qc...@gmail.com wrote: Openstreetmap recently annonced on his tweeter , release of brand new high definition satelite vues of BING in Canada. So... hope it 'll help you were you're mapping ;-) -- Bruno Remy ___ 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] upcoming Canadian press coverage and your local group
We did have the Vancouver meetup about 2 years ago (has it already been 2 years?). Unfortunately it wasn't enough for the genesis of a regular group. I guess I wont get to be in a Vancouver osm group for a while since I will be moving up to Yellowknife in one week. Maybe somebody else lurking on this list is in Yellowknife (or visits Yellowknife on a regular basis when they aren't in a camp)? I'll still try to keep canvec and the upper Fraser valley in sync :) Adam On 2012-04-13, at 12:04, Paul Norman penor...@mac.com wrote: From: Richard Weait [mailto:rich...@weait.com] Subject: [Talk-ca] upcoming Canadian press coverage and your local group Dear all, I expect that OSM will be getting some press coverage in the Canadian media in the near future. This is a wonderful opportunity to launch your long-anticipated local OSM group. I would love to see future awesome Canadian local OSM groups get launched TODAY. Pick a place convenient for you, and not-horrible for others. I use coffee shops and pubs, depending. Pick a time convenient for you and not-horrible for others. I use after work on a weekday. Announce it. Announce it here and in places where locals who aren't already OSMers might find out about it. I use meetup.com, you might use upcoming, or patch or anything else. There is a chance that the upcoming press will lead to new mappers who will be really grateful to have a local help them with their first edits. And you'll get to meet other local mappers who have been waiting for somebody else to start a local group. Be somebody else. :-) Please consider doing this. There is no good reason for Toronto to have all of the fun. :-) There are awesome OSM folks in Ottawa and Montréal, Québec and Sherbrooke and BC and Alberta and the far North. Come on. Meet and talk. Anyone else in the Vancouver area interested in this? I'm busy with exams until mid-next week but I'm free then. I live in New West and commute to UBC or Richmond. ___ 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] Coastline on low zoom levels
Great Slave Lake isn't showing up for two reasons: 1. I haven't finished importing the GSL area because I'm waiting for NRCan to update the canvec files for that area (it's missing wood). 2. Mapnik doesn't render large bodies of natural=water at low zoom. The renderer needs to be fixed. Adam On 2011-10-24, at 15:13, Samuel Dyck samueld...@gmail.com wrote: 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 mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Imported frustrations
I think this comes down to a combination of things: 1. User education. People need to be told to double-check what they are importing, and to also slow down on their imports. Using bulk_upload.py might be okay in the middle of Nunavut where *nothing* exists, but it's a poor choice for any place that has even a couple ways. People also need to be more educated in general editing techniques. It's true that many people just map for the renderer and don't consider routing and other functions. When I was doing GeoBase NRN imports for Vancouver, I would select a small section of roads to import (maybe 10 blocks by 10 blocks), then I would spend an hour or two cleaning up messes that people had made in Potlatch before I could actually do any importing. Bad users abound, it's just that bad users importing are easier to spot because they cover a larger area. 2. Tools. I think OSM could really do with a diff-style program. An ability to view differences between two layers within JOSM would be a great thing. This kind of tool would make imports far easier to perform. See http://en.wikipedia.org/wiki/Diff if you are unfamiliar with diff. So far, the best thing I have seen is OpenJump Roadmatcher Conflation, which was used quite heavily in the GeoBase process. Unfortunately, OpenJump Roadmatcher only works on ways that are not closed (not polygons). Importers should also be forced to run things through JOSM's Validator before they submit. Would it be beneficial to bring back OpenJump? I could take another look at the scripts and maybe come up with some new process for Canvec importing. Adam On Thu, Oct 6, 2011 at 3:00 PM, James Ewen ve6...@gmail.com wrote: On Thu, Oct 6, 2011 at 12:45 PM, Harald Kliems harald.kli...@mail.mcgill.ca wrote: Finding and fixing these errors has been a huge timesuck and not much fun. Wow, using the tool you just showed me made the job of finding and correcting the errors in my local community a very quick and easy task... trying to find duplicate ways is pretty tough just going by what you can see. Finding unconnected ways is a little easier as they show up visibly. I just cleaned up about 20 square miles of area in about 10 minutes. There's an even bigger issue where the canvec imports stop well shy of the existing roads, or issues like this: http://tools.geofabrik.de/osmi/debug.html?view=routing_non_eulon=-112.55995lat=53.71582zoom=13opacity=0.98 I was thinking that it might be an idea where instead of dropping the close match CanVec Imports, that if they were imported, but marked such that they would be easily found and deleted if not desired, or the existing road could be deleted, and the CanVec import modified to make it the new way. Such as in the case above where the CanVec way was left out of the import in deference to the existing road, it would be very easy to just modify the CanVec way to make it part of the database, and delete the less accurate hand drawn way. It's more of a pain to have to go and find the CanVec ways again, and import them so you can delete the hand drawn way. If there were a way to have the CanVec ways that were determined to be duplicates shown on a map (kind of like showing roads under construction), one could easily compare the two ways, and with a simple edit and delete combination, make the CanVec way the one to keep, or a simple delete to remove the CanVec way. Speaking of CanVec imports... anyone going to tackle importing roads into Saskatchewan some day? It gets pretty bleak on that side of the border in a hurry! http://www.openstreetmap.org/?lat=52.091lon=-109.473zoom=9layers=O -- James VE6SRV ___ 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] Visit Vancouver in 7 Sep
I may be making the 2 hour trip from my home in Chilliwack into Vancouver that day, so I might see you there. All depends on other factors though, so no guarantees. Adam On Mon, Sep 5, 2011 at 7:30 PM, Hiroshi Miura miur...@osmf.jp wrote: Hi Canadian mappers! I'm Hiroshi Miura, A Japanese mapper and leader of OSM Japan. I have a plan to visit Vancouver BC. on the way to State of the Map 2011 in Denver! I'll arrive at noon in 7th Sep, tomorrow. Sorry for short notice. It is just 1 day transit, but I wanna enjoy downtown Vancouver with POI mapping, walking and tasty beer seafoods. If anyone is interested in talking with me in evening 7 sep., please contact me on tw, fb or osm message. #You may also be interested in our Ushahidi project: http://sinsai.info/ #and its blog in English: http://sinsai-info-en.blogspot.com/ I'm going to go a pub, Stella's on Cambie Hiroshi -- representative director of OpenStreetMap Foundaiton Japan sub-leader of Sinsai.info - Ushahidi site for Japan disaster response Hiroshi Miura - miur...@osmf.jp facebook: miurahr, twitter: miurahr, osm: miurahr, and others. ___ 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] Your new coastline
A man with one watch will always know the time. A man with two watches will always be in doubt. --Unknown Adam On Fri, Sep 2, 2011 at 2:12 PM, Richard Weait rich...@weait.com wrote: On Fri, Sep 2, 2011 at 4:34 PM, G. Michael Carter mi...@carterfamily.ca wrote: I wish they'd updated the Bing high resolution images In Orangeville there's a new mall, but only one image (of three tiles) has the new mall, the other has the cleared field from when they started. I can only put in half the buildings. Any ideas on how often they update the high res? SteveC asked for suggestions for bing imagery updates, without being able to promise anything, in June. http://lists.openstreetmap.org/pipermail/talk/2011-June/058862.html I guess that half of Orangeville made it onto the list. :-) It is important to remember that every source we use for OSM lies to us in one way or another. We've each been misled at one point or another by our own GPX tracks, old / mis-aligned / unresolvable aerial imagery, our imperfect memories and illegible hand writing, outdated, mis-aligned or just dead wrong vectors from other sources. So we don't always get things right the first time, or when we think we are improving the work of another mapper. That's okay. We can fix it. That's part of what we're all about. ___ 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] Merging ways
There's two methods to join two areas: you can delete the coincident segments and combine the two unclosed polygons (as you have tried), or you can use JOSM's join ways feature. What you are doing (the first method) should have worked, and I don't know why the two ways don't want to stay joined together. Make sure that the two ways are open, and that their coincident nodes are merged together (highlight them both and click 'm' on the keyboard for merge). Then select both ways and 'c' on keyboard for combine. You will get a tag conflict window that allows you to select which tags should apply to the final way, as well as which member of the relation should be kept or removed. In this case you will want to delete the tags on the way (since the relation will have the tags you need), and you will want to keep the member in the relation. For the second way (faster and less involved), you need to 'm'erge all coincident nodes, and make sure there aren't any nodes that are part of only one way or another (all coincident nodes have to be part of *both* ways). Since the coincident nodes in the middle of the lake will disappear when the areas are merged, you can just delete them without worrying about merging. Then select both ways and type 'shift-j' for join areas. Deal with the tag conflicts (again, you won't need tags on the way because the tags are in the relation), and you should be done. Shift-joining areas will handle two ways, a way and relation, or two relations, just as long as they are well formed (nodes are merged properly ahead of time and all of the ways are closed polygons [this won't work where ways have been split at 2000 nodes, since those ways are open polygons and josm won't know how to merge the two areas]). I demonstrate this technique in [http://www.youtube.com/watch?v=OJr_gucFGMY#t=3m45s] Also don't forget to copy over the name of the lake, since Canvec doesn't appear to have the name. Adam On Sat, Aug 20, 2011 at 10:15 PM, James Ewen ve6...@gmail.com wrote: Okay, how do I accomplish this task? I drew the outline of Wolf Lake by hand quite a while ago. I also imported the water features from CanVec as well. Now there are three ways defining the lake. One is the way that I drew by hand. The second is one imported from Canvec which is a simple outline with the tag natural:water. The other half of the lake (split across a CanVec tile boundary) is a multipolygon outer relation because there's an island in the lake. I have tried removing the ways that define the split in the tile, and join the two remaining halves. I can't do that because there's a tag conflict. I removed the tags from the natural:water side, and tried to join the remaining untagged way to the outer relation, but it does not want to stay joined together. One would think that you should be able to simply join the untagged way to the way defining the outer relation, completing the circular way. This should be the simple part, I would assume. The situation where each half of the lake is an outer relation with inner relations would make the process more complex as you would somehow have to make the inner relations on one of the outer relations move over to become inner relations to the other outer relation, while making only one of the outer relations define the whole lake. Having the CanVec data available is excellent, but stitching areas back together where they have been artificially split at a tile boundary is a bit of a bear for me. Anyone of the CanVec import experts out there have a bit of a tutorial lesson for me? Wolf Lake (Hand drawn) http://www.openstreetmap.org/browse/way/78288197 Wolf Lake (Canvec natural:water) http://www.openstreetmap.org/browse/way/81345148 Wolf Lake (Canvec outer relation) http://www.openstreetmap.org/browse/way/81400283 -- James VE6SRV ___ 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] Merging ways
My involvement with OSM predates Potlatch by a couple months, so I learned to edit OSM with JOSM, and that's what feels most natural to me. I get frustrated trying to use Potlatch. The complete opposite of you :) Your data looks good, except for one thing: you tagged the way with the name, whereas the proper thing is to tag the relation with the name. The way should have no tags in this case (there may be other cases where the way would have tags even though is a member of a relation, but not in this case). For 1K, I split at approx the half-way mark. Doesn't need to be exactly half. Linear ways (highways, etc) just get split and left as two ways, whereas polygons (lakes, forests) get split and then made into a multipolygon relation. I think that having boundaries will be inevitable, especially when mapping out forests of Canada (a forest relation could extend hundreds of kilometers!). I'm currently experimenting with making Great Slave Lake a giant multipolygon, which may end up being the largest multipoly in OSM, since GSL is the 9th largest lake in the world, and I expect the 8 larger are tagged with coastline. I'm doing this to see how well the renderers deal with this case. I wouldn't suggest making multipolys so large, and they should be divided at smaller areas. Where to split is up to you, and how large to make a multipoly is up to you, just as long as an individual way does not exceed 2000 nodes. Just to be sure you're aware: http://wiki.openstreetmap.org/wiki/Relation:multipolygon Happy mapping! Adam On Sun, Aug 21, 2011 at 9:33 PM, James Ewen ve6...@gmail.com wrote: On Sun, Aug 21, 2011 at 9:14 AM, Adam Dunn dunna...@gmail.com wrote: There's two methods to join two areas: you can delete the coincident segments and combine the two unclosed polygons (as you have tried), or you can use JOSM's join ways feature. What you are doing (the first method) should have worked, and I don't know why the two ways don't want to stay joined together. Not sure what was going on there, but Potlatch 2 didn't want to play nice. I watched your videos and decided to give JOSM yet another go... I've tried twice before and both times gave up in disgust with trying to figure out the arcane logic behind using JOSM. Perhaps I have learned a bit over the years using other editors, like Merkaartor, but this time I had better luck.I still hate using an editor with defined modes. There are far too many extra button presses to get it to just do what you want. Just to add a node to an existing way I have to press A, then click on the node, then hit ESC to stop adding a way. Why not just shift-click on the way like you do in Potlatch? I found where you can select having JOSM go to modeless like Potlatch but it doesn't seem to make any changes. Anyway, I think I managed to merge a few ways to create a one piece version of Wolf Lake. I don't think I've buggered anything up, but time will tell. About a week from now, if Wolf Lake disappears, we'll know why. Video tutorials like the ones you made are a great help. Trying to follow along in a written help file can be pretty tough if you have no idea what they are telling you to look for, or where to find the buttons to press. The video help was nice and easy to follow, and I was able to replicate the instructions given without having to go back and watch the video again to figure out what you had done. Thanks for the help Adam! BTW, what do you do with an entity that has over 1000 nodes? You said you don't like to make any that big. Do you just arbitrarily cut lakes or forests into bits? Should I just leave the Canvec tile boundaries in place if the lake is too big? When you zoom in, the lines show up, which isn't all that desirable. The only other way to reduce the number of data points would be to reduce the precision level of the depiction of the feature, which also is not desirable. -- James VE6SRV ___ 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] Kamloops Data
You've probably seen my name come up quite often in the Kamloops area, so I will introduce myself a bit. I did the NRN import (government roads) for Kamloops, but I live in Chilliwack. It took a great deal of time (about a week, I believe) to merge the NRN data with the data that was already existing in the area. I don't personally mind if you import a legally cleared source for the area, and will try to answer any questions you have about what I had imported. I believe Samuel Longiaru lives near Kamloops, so you should definitely hear his opinion before going too far. I've taken a look at some of the data you've imported, and my comment so far would be to clean up the tags. You have tags that aren't used in OSM, as well as tags that have all capital letters. If you could convert the tags to match the OSM standards, that would be great. Also delete tags that OSM doesn't want or need (like Shape_Area= and Shape_Leng=, etc) See http://wiki.openstreetmap.org/wiki/Map_Features for an incomplete-but-most-of-what-you-need listing of key value tags. Adam On Fri, Jul 29, 2011 at 2:35 PM, Matthew Buchanan matthew.ian.bucha...@gmail.com wrote: 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] Railways duplicated in CanVec data
Indeed. In fact, this issue has already been listed on the wiki page: http://wiki.openstreetmap.org/wiki/CanVec#CanVec_7 :) Adam On Sat, May 28, 2011 at 9:06 AM, Samuel Longiaru longi...@shaw.ca wrote: I've been importing in south central BC and have noticed that there is a consistent duplication of railway = rail ways in the CanVec data. No big deal as if I forget, it is caught by the validator, but there must be a glitch somewhere in converting to OSM? Thanks ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] CanVec Import Videos
In an attempt to attract more people to CanVec importing, I've started making a series of videos that demonstrates the process. Please see http://wiki.openstreetmap.org/wiki/CanVec#Screencasts_of_CanVec_Imports and let me know what you think. 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
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 On Wed, May 18, 2011 at 7:25 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: 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
Re: [Talk-ca] Merging Canvec with NHN streams
As it turns out, the secret here is to select all the streams, then in the object selection list, select only ways (by clicking the first way, holding shift and clicking the last way, then clicking the select button), so that no nodes are listed in the selection list. By having only ways selected JOSM will only delete ways; nodes will only get deleted if there are no more ways using them and if they have no tags. Adam On Sat, Apr 23, 2011 at 8:58 PM, Adam Dunn dunna...@gmail.com wrote: I have encountered an issue when importing Canvec in areas where NHN has already been imported. It's not so much an error with the data as it is an error with my methods of importing. I'll just put this here in case anyone else is doing similar or has suggestions for better methods. What I've been doing so far: Since the areas I'm working in already have NHN nlflow (but not waterbody), and this data is identical to the streams in Canvec (the only exception I've seen is some large streams in Canvec being tagged river in NHN, which is probably more correct), I filter for water=stream in the Canvec layer, select all the streams and hit the delete button. Then I merge the Canvec layer into the OSM server layer. What I didn't foresee was that deleting the streams to avoid duplicates with the NHN data would also delete the nodes from lakes/ponds in Canvec where the stream intersected. So now the lake and the stream don't connect because the lake is missing a node. On convex lakes, the stream will appear to come up short without touching the lake (since a bay is missing). On concave lakes, the stream will cross the lake outline (since a peninsula is missing), but Validator won't mark this as a problem. Now I'm going back and reconnecting all the streams to lakes, using Canvec files from disk in another layer to verify location of the connection. So beware of this little issue. What techniques do other people use for importing Canvec on top of NHN flow data? Do you take a very manual approach, or do you have some filter/search/validator-fu that allows for quick imports while retaining data validity? Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Merging Canvec with NHN streams
I have encountered an issue when importing Canvec in areas where NHN has already been imported. It's not so much an error with the data as it is an error with my methods of importing. I'll just put this here in case anyone else is doing similar or has suggestions for better methods. What I've been doing so far: Since the areas I'm working in already have NHN nlflow (but not waterbody), and this data is identical to the streams in Canvec (the only exception I've seen is some large streams in Canvec being tagged river in NHN, which is probably more correct), I filter for water=stream in the Canvec layer, select all the streams and hit the delete button. Then I merge the Canvec layer into the OSM server layer. What I didn't foresee was that deleting the streams to avoid duplicates with the NHN data would also delete the nodes from lakes/ponds in Canvec where the stream intersected. So now the lake and the stream don't connect because the lake is missing a node. On convex lakes, the stream will appear to come up short without touching the lake (since a bay is missing). On concave lakes, the stream will cross the lake outline (since a peninsula is missing), but Validator won't mark this as a problem. Now I'm going back and reconnecting all the streams to lakes, using Canvec files from disk in another layer to verify location of the connection. So beware of this little issue. What techniques do other people use for importing Canvec on top of NHN flow data? Do you take a very manual approach, or do you have some filter/search/validator-fu that allows for quick imports while retaining data validity? Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Great Lakes shoreline
Coastline updates vary, depending on Mapnik vs. Osmarender and what zoom level you're looking at. I've done editing to the coastline that represents Great Slave Lake in the Northwest Territories, and edits made on April 2 still have not been rendered by Mapnik, but they have been rendered by Osmarender. Edits made on March 15 are rendered (and have been for a week or two). So right now it takes around a month for coastline changes to be rendered by Mapnik. Adam On Wed, Apr 20, 2011 at 11:44 AM, James A. Treacy tre...@debian.org wrote: On Wed, Apr 20, 2011 at 01:58:39PM -0400, Richard Weait wrote: On Wed, Apr 20, 2011 at 12:29 PM, James A. Treacy tre...@debian.org wrote: Hello, I have been adding canvec data for the last part of the Bruce Peninsula and noticed that the existing shoreline is quite different than that given by the canvec data. The source for the existing coastline is r_coastlines and I have no idea who/what that is. I don't know which is more accurate but the canvec coastline matches much better with the land features. Should the existing coastline be left alone or should it be switched over? Dear Jay, That's the eternal question isn't it? With one source, we just use it. With multiple sources; it's always about evaluation and comparison. ;-) r_coastlines doesn't ring a bell, but I know that PGS coastlines was fairly easy to improve upon. Sounds like you are seeing canvec as a better match to the other land features, which may also be from canvec. I'm not sure you should see that as definitive. But if the canvec is a better match, and yahoo / Bing don't disagree, ... ? I just did a comparison with Bing imagery and there is no comparison: even given the low resolution of the imagery, the canvec coastline for the tip of the Bruce Peninsula is clearly 10x better. Of course, that is no indication that the rest of the coastline for Lake Huron is as good so would check it as I go along. If you decide to proceed, and the water bodies are tagged as coastline, be aware that coastline rendering is sensitive, and does not re-render immediately. Due to time constraints, I wouldn't start this until May. In fact I will have spotty (at best) net connection next week. That is probably a good idea as it will give time for feedback from others. I'd want to start with a test section and see how it goes before proceeding. Do you know how long it is between updates of coastlines? Also, if it goes well I would just proceed and update a large section of the coast. As this would involve a large geographical area, I would give updates to the mailing list to minimize the chance of conflicts. -- James (Jay) Treacy tre...@debian.org ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Routing issue / Probleme de routage
If you set the origin to be Gaspé, and a destination of Cornwall, then MapQuest will take the long way through Miramichi. If you set the destination to Dorval, then MapQuest will go through Rimouski. The difference in destination between Cornwall and Dorval is negligible, and both are far away from the incorrect routing. Perhaps this has to do with incorrect road classification or speed limits? Perhaps MapQuest has pre-calculated a long-distance routing matrix/tree, and that routing matrix/tree is using old data, which is causing the strange errors here? I cannot recreate the routing error in http://routingdemo.geofabrik.de/ Adam 2011/4/13 Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca: Bonjour Nakor, Mon hypothèse première est qu'il doit y avoir un bris dans la continuité du réseau routier entre Rivière-du-Loup et Rimouski. Cependant, le bris doit cependant apparaître sur tout les segments de la région si aucun chemin alternatif parallèle à la route 132 est sélectionné. Ce qui me surprendrait! Daniel -Original Message- From: Nakor [mailto:nakor@gmail.com] Sent: April 13, 2011 15:51 To: talk-ca@openstreetmap.org Subject: [Talk-ca] Routing issue / Probleme de routage Bonjour, Quelqu'un aurait-il une idee de la raison de ce routage particulier : http://open.mapquest.com/link/4-J9uff4Tn Si on ajoute Rimouski come point intermediaire le chemin est bien plus direct Does anyone know why this strange routing happens: http://open.mapquest.com/link/4-J9uff4Tn If I add Rimouski as a waypoint everything is fine. Merci, N. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Duplicate rail lines in 092H06
What is affected by this? Is it BC only or all of Canada? Does it affect only ways tagged railway=rail or others as well? I will add it to the list of known issues at http://wiki.openstreetmap.org/wiki/CanVec#CanVec_7 Adam On Mon, Apr 11, 2011 at 5:36 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Bonjour Adam, It has been detected in January and the problem is not limited to 092H06. I was on the impression that I sent an email on Talk-ca about that but, as I didn't find any email in my outbox, it seems I didn't! It will be corrected in the next release. Best regards, Daniel -Original Message- From: Adam Dunn [mailto:dunna...@gmail.com] Sent: April 10, 2011 12:24 To: Bégin, Daniel Subject: Duplicate rail lines in 092H06 Haven't checked other areas, but 092H06 has duplicate ways with the same tags for rail lines. Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Importing Canvec data, but causing huge issues
I don't have or use Merkaartor, I'm a JOSM fellow. For reference, the lake that you pointed to is in 083H07.1.2 [ftp://ftp2.cits.rncan.gc.ca/osm/pub/083/H/083H07.zip] You're right in that there's nothing wrong with the Canvec data. Well, it does have two duped ways, which could be reduced, but that's not that big a deal. The original data has singular nodes (non-duplicate), and two ways that are duplicates, where one way is a simple natural=water, and the other way is an inner member of a natural=wood relation. Somehow you've managed to upload: Triply-duplicated nodes. Three duplicated ways of which: One is the original natural=water polygon The two other ways are both inner members of 16 identical natural=wood relations. That is to say, you've sexdecupled the natural=wood relation. Not being a Merkaartor person, I can't say exactly what caused this. I would guess that the triple-duplicate nodes would be caused by copy-pasting things individually (you copy paste the water, which will create one set of nodes, then you copy paste woods which will create another set of nodes, which are dupes of the first set). I'm not sure about the sexdecuply duplicated relation or the doubly duplicated wood inner ways. Does Merkaartor have a validation step or plugin (like JOSM has validator)? For how long have these errors been uploaded (how many tiles uploaded are like this)? Adam On Sat, Apr 2, 2011 at 10:01 AM, James Ewen ve6...@gmail.com wrote: Can anyone shed some light on why I am causing problems when importing CanVec data? I am using Merkaartor to import the CanVec OSM tiles located here: ftp://ftp2.cits.rncan.gc.ca/osm/pub I used find to select the desired entity (natural:water), and the copy and paste the features. I then upload the features to the OSM server. However, this process appears to be creating duplicate nodes like crazy. http://matt.dev.openstreetmap.org/dupe_nodes/about.html If you look at some of the uploaded information, you can see that there are multiple copies of some nodes and ways, and some have multiple duplicate tags included. Here's a tight zoom on a lake: http://www.openstreetmap.org/?lat=53.485292lon=-112.80943zoom=18layers=M If you add the data overlay, you can see that there are multiple ways describing this lake. If you find the multipolygon for natural:wood, you'll see that it has 16 tags indicating that it is part of a relation as inner... If the source of this problem the CanVec data itself (unlikely), something Merkaartor is doing (unlikely), or something the wingnut at the keyboard is doing (likely). Whatever the source, what can I do to fix the problem short of stopping working on CanVec to OSM imports? James VE6SRV ___ 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] Did I just find a potentially significant bug in JOSM?
Congratulations on filing a bug report Dan. For those interested, http://josm.openstreetmap.de/ticket/6087 would be the ticket in question. Adam On Mon, Mar 7, 2011 at 9:26 PM, Dan Charrois d...@syz.com wrote: Thanks Adam, and everyone else who responded to my message. I'm glad to learn the bug is repeatable by others - that means I'm not going completely crazy. Plus, it's nice to have a good understanding now why some of the ways I'd uploaded had mysteriously disappeared. I'm glad you were able to distill down the problem so succinctly. validatorfail.osm shows off the bug well, and is much easier to follow what's going on. I'd apparently been lulled into trusting JOSM's ability to fix simple things like duplicate nodes a little too much. It's definitely a time-saver when it works, but not if roads are lost in the process. I'm hoping that a slightly revised procedure of fixing things just one category at a time (rather than at the top-level Warnings category) should be a good workaround. In the meantime, I agree that a bug report should definitely be filed about this. At the very least, disabling top-level fixes would force people to go through category by category. I'm sure I'm not the only one who has trusted (or will trust) that the top-level fix is a good way to reduce the manual workload. Your validatorfail.osm file is a perfect example of how to reproduce the problem, and should probably be included with the bug report - I can definitely try to figure out how to submit the bug report to http://josm.openstreetmap.de/ if you're busy or no one else has yet, and you don't mind my including the file. But as the person who really narrowed down the issue, the honor for reporting it (if there is such a thing) should be yours.. :-) In any case, those blanket fixes will be a thing of the past for me - I'm hoping that the category-by-category approach doesn't cause any issues. Other than this hiccup, I've found JOSM to be quite intuitive and reliable, though as was mentioned, it is a work in progress and likely always will be. It's just a matter of finding where its specific weaknesses are, and then avoiding those. Dan ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Importing MLI park boundaries
Assuming the dataset clears legal, my preferred way of converting shapefiles to osm is using ogr2osm [http://wiki.openstreetmap.org/wiki/Ogr2osm]. You get to write your own tag filters in Python (two samples are provided in the translations directory), as long as you're not doing any complicated automated editing of ways or some such. Last time I used ogr2osm, it wasn't putting version numbers into the output files, so they're not technically API0.6 compatible (Osmosis won't accept them, but JOSM will). It should do just what you need. Adam On Fri, Mar 25, 2011 at 12:11 PM, Samuel Dyck samueld...@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] Did I just find a potentially significant bug in JOSM?
Sam wrote I think you're getting the exceptions because you've modified the data, but have not updated the list. This is definitely an issue I have encountered with Validator. If you run the validator to check for errors, then delete some nodes or ways yourself, then try to use validator's auto-fix, it will attempt to modify objects that you have since deleted. This causes it great confusion and can mess things up. Validator tends to be good about maintaining internal consistency, but not external. I don't do blanket fixes like Dan, I like to drill down a level or two like Sam, just to make sure that Validator is doing things properly. If you do open a ticket for this, be sure to let us know about it (ticket number). Adam On Mon, Mar 7, 2011 at 7:30 PM, Richard Weait rich...@weait.com wrote: On Mon, Mar 7, 2011 at 9:39 PM, Russell P skiinf...@gmail.com wrote: Thats funny, because I submitted a bug just a few hours ago because the latest (dev) build of Validator + JOSm wouldnt merge duplicate nodes on a canvec boundary.. Anyways, clearly JOSM is a work in progress, Yes, it is probably worth making a bug report for both of these. Please note that josm has it's own trac, not on osm.org. http://josm.openstreetmap.de/ ___ 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.
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.
About 100 meters of Hwy 93 was missing just west of BC/Alberta border (yup, just plain gone). Fixed now. Adam On Sat, Mar 5, 2011 at 9:01 AM, Samuel Longiaru longi...@shaw.ca wrote: 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
[Talk-ca] Here we go again...
Anybody got a claim on user user_5365? [http://www.openstreetmap.org/user/user_5365/] This user is doing lots of Canvec importing, and is actually self-identifying as a bot (with the tag bot=yes). Rather disconcerting, considering the fierce debate that happened just a couple weeks ago over on talk@. This user seems to be working mostly in Alberta. Have they made many errors? It would be nice if JOSM had a plugin to assist in spot-checking a user's work (by automatically downloading the areas they worked on, so that they can be looked over). There's a high probability that this was the user who nuked a section of Hwy 93 near BC/AB border, but that could have been one mistake in a sea of excellent quality edits. Let's try and nip this one in the bud before it becomes a problem. Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Here we go again...
I've found the people on talk-ca to be a little calmer, so I thought it would be okay to send a message here. I wouldn't say people here are less opinionated, but I think they are less vociferous about their opinions, and I think that's due to the small size of the list. Shortly after my first message here, I did send a message to the user, asking them to subscribe to the list, and included a link to the archive of my first message. This user has been registered for a number of years, so I figured they might be a regular here. Adam On Sat, Mar 5, 2011 at 10:26 AM, Samuel Dyck samueld...@gmail.com wrote: 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.
Langley, BC: Hwy 1 west to 56 Ave at 1/13 interchange: short section marked as oneway when it shouldn't be. Fixed. Just south of Merritt, at the 5/5C/97A interchange, heading north on 5, then going east on 97C, there's a traffic-lit intersection with 97C. Since 97C is dual carriageway, the intersection is an H design, but the connector of the H is set as motorway_link, which implies oneway. Setting oneway=no. Adam On Sat, Mar 5, 2011 at 10:34 AM, Richard Weait rich...@weait.com wrote: On Sat, Mar 5, 2011 at 1:30 PM, Richard Weait rich...@weait.com wrote: MB TCH: fix bad oneway at PTH 44 Good to Winnipeg, 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] Secret routing demo.
Hwy 99, Sea-to-Sky section (North of Vancouver), just north of Sunset Bay, there's a short section, where it's a single carriageway, but motorway implies oneway. Since Sea-to-Sky has been upgraded (Olympics), it's now dual carriage. 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 On Sat, Mar 5, 2011 at 11:23 AM, Adam Dunn dunna...@gmail.com wrote: Langley, BC: Hwy 1 west to 56 Ave at 1/13 interchange: short section marked as oneway when it shouldn't be. Fixed. Just south of Merritt, at the 5/5C/97A interchange, heading north on 5, then going east on 97C, there's a traffic-lit intersection with 97C. Since 97C is dual carriageway, the intersection is an H design, but the connector of the H is set as motorway_link, which implies oneway. Setting oneway=no. Adam On Sat, Mar 5, 2011 at 10:34 AM, Richard Weait rich...@weait.com wrote: On Sat, Mar 5, 2011 at 1:30 PM, Richard Weait rich...@weait.com wrote: MB TCH: fix bad oneway at PTH 44 Good to Winnipeg, 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] Secret routing demo.
There is the route finding plugin for JOSM, which has been around a while, but I tried to get it running last night, and it doesn't seem to be working anymore (but it worked well in the past). The graph visualization plugin also has some potential, but could use work. Adam On Sat, Mar 5, 2011 at 12:13 PM, Samuel Longiaru longi...@shaw.ca wrote: 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
Re: [Talk-ca] Here we go again...
user_5365 responded through OSM message system. Basically, they were using an automated system to upload small amounts of Canvec data (one or two roads at a time), then they would manually verify and correct, then move on to the next bit of data. They have stopped doing the import due to the site being unstable (the last edit was December). They also say that the site is inaccessible, making it impossible to reply to the post. So now you know the background if you see user_5365 pop up. Adam On Sat, Mar 5, 2011 at 4:37 PM, James Ewen ve6...@gmail.com wrote: On Sat, Mar 5, 2011 at 10:52 AM, Adam Dunn dunna...@gmail.com wrote: Anybody got a claim on user user_5365? [http://www.openstreetmap.org/user/user_5365/] This user is doing lots of Canvec importing, and is actually self-identifying as a bot (with the tag bot=yes). Rather disconcerting, considering the fierce debate that happened just a couple weeks ago over on talk@. This user seems to be working mostly in Alberta. Have they made many errors? It would be nice if JOSM had a plugin to assist in spot-checking a user's work (by automatically downloading the areas they worked on, so that they can be looked over). Nope, but charrois is doing a bunch of canvec importing around Edmonton, but also seems to be removing quite a bit of existing road data. http://www.openstreetmap.org/user/charrois I've sent a message on OSM inviting him/her over here as well. James VE7SRV ___ 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
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
Re: [Talk-ca] Secret routing demo.
In Vancouver, from Hwy 1 heading west onto Brunette Ave heading southwest, the routing software advises to take the offramp going north onto Brunette, then do a u-turn at the Brunette/Bernatchey intersection in order to head south on Brunette. However, if one were to continue along Hwy 1, there is a proper offramp to go south on Brunette. Judging by the map, it looks like the u-turn method is actually shorter in terms of distance, so this is what the routing software chooses to do! (plus the Brunette/Bernatchey intersection is an H style [Brunette being the dual-way], so the software doesn't see it as a u-turn). A no_u_turn relation would fix this issue, but I'm not sure if u-turns are actually restricted there. Also, the routing software attempts to use ferries if it needs to, but doesn't seem to be using the Horseshoe Bay (Vancouver) - Departure Bay (Nanaimo) route even though it all seems okay in data. Adam P.S. pnorman is my hero for the following tag: note=Yes, this track does overlap a road It's nice when people explain their odd ways of mapping (a rail and a road overlapping ways in this case). On Sat, Mar 5, 2011 at 8:36 PM, James Ewen ve6...@gmail.com wrote: Section of highway 2 southbound immediately south of the Anthony Henday was one way northbound not allowing anyone to leave the city of Edmonton! Reversed the flow! James VE6SRV ___ 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.
British Columbia: the highway 97/97C interchange (between kelowna and peachland) had a routing error, but was corrected two days after the data was pulled (by someone I don't know). When you said fast, you weren't kidding! This'll be great to get on the main page (when it works in conjunction with address search, etc). Adam On Fri, Mar 4, 2011 at 9:38 PM, James Ewen ve6...@gmail.com wrote: On Fri, Mar 4, 2011 at 9:25 PM, Samuel Longiaru longi...@shaw.ca wrote: 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. There are more anomalies on the TC-1 east of Golden... anyone familiar with the area care to fix the problems? http://www.openstreetmap.org/?lat=51.27396lon=-116.76355zoom=16 James VE6SRV ___ 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] Determining The Identity Of Features
Richard and Sam beat me to the response, but here's my understanding anyways: You can't copyright fact. The fact that a trail has some name is not copyright-able. Collections of facts are copyright-able, however. Let's say you come across a single trail marker such as that in [http://www.travelpod.com/travel-photo/tombuttle/9/1228407840/10_trail_marker.jpg/tpod.html], or a set of individual trail markers, like in [http://blog.myczechrepublic.com/images/trebon-trail-markers.jpg]. These are stating facts (and could be considered different objects, even when they are nailed to a single tree), and therefore are not copyright (at least not in the Canadian/US system). In order to collect the name of a trail, you would need to visit the trail head to read the marker sign. Now let's say you come across a trail map board, such as [http://outdoors.webshots.com/photo/1120051478042125381wBnHBr]. This would be considered a collection of facts, and is therefore protected under copyright. You don't need to visit a trail head because somebody has already collected the facts for you and assembled them into one place. Adam On Sun, Feb 27, 2011 at 12:02 PM, Chris Bruce ch...@mirrorcomputing.co.uk wrote: Bump! Anyone able to give me some guidance on this? Many thanks. --- On 11/02/2011 12:36, Chris Bruce wrote: Hi there, I've been doing a bit of mapping for the project in the UK, adding some roads and trails generally from my area of mid-Wales. We have a bit of a copyright problem with naming features in the UK that we have actually surveyed. You can see the question and the responses on this link: http://help.openstreetmap.org/questions/1286/determining-the-identity-of-features. The government is being a bit more open and has released some data but there seems to be some discussion about a possible conflict between its licence and the OSM licence. I'm in Canada for a while and thought I'd map some trails while I'm here per your WikiProject Canada page. I'm hiking in Provincial Parks and National Parks in BC at the moment. I guess there will also be Regional Parks. At the trailhead there are generally maps naming the trails and features. Having hiked and tracklogged the trail am I permitted to name the trail or feature in OSM from the information found at the trailheads? (Or do I ask somebody who looks at the sign at the trailhead and then tells me?!!!?) Also I'm aware that NRCan has released a huge amount of data for use. Can I similarly name and draw features from information obtained from those sources, e.g. the Topo tiffs? The reason I ask here is that I know that you guys (authorities!) seem somewhat open about copyright licensing and the uses to which official cartographic data is put and some guidelines for me would be great. Thanks for your time... ___ 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] Anybody want to join me for a one to 1.5 hour webinar?
I'm not much of an Ontario trail user, being 4 provinces away, but I could listen in ;) Any special software required? Adam On Thu, Feb 24, 2011 at 7:50 AM, Richard Weait rich...@weait.com wrote: On Thu, Feb 24, 2011 at 7:32 AM, Ontario Trails ontra...@gmail.com wrote: I only threw out some ideas, I think a dialougue is important, I see huge amount of data going by and we should also talk about OSM and how you guys are doing. Thanks Dear Patrick, Any time this afternoon is great. Or selected spots Friday / Monday. Who else is joining in? 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] List of CanVec Conversions
I've gone through some old emails, and compiled a section for CanVec-OSM conversions on the wiki page. http://wiki.openstreetmap.org/wiki/CanVec#CanVec_Versions Hopefully this will help people who are working on CanVec import. If someone sees a problem in data that has already been uploaded to OSM, they can check against the list to see if was a known issue (but wasn't corrected by the importer) at the time. Check it over to see if I missed anything. Daniel: At the end of CanVec 6 conversion, you preemptively said that BC coastal hydrography would be updated in CanVec 7. Did this actually happen? Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Proposal: Cleanup of NHN ways in BC
Right, the NHN import in the area mentioned was done by MBiker. MBiker was a pretty big mapper for the Vancouver area. He started off doing lots of manual edits by biking around and gps'ing, then he got involved in the NRN road import for east GVRD, then he did NHN for the entire watershed area (08X-something?). The problem with his NHN import was that he bit off more than he could chew. He was going around fixing and cleaning the NHN stuff he imported (like a good importer should do), but he suddenly stopped working on OSM in October. I think maybe the size of the import was too daunting for one man? The process used for importing NHN was different depending on how much was being imported at once. When an entire watershed was done (which is the case here), it was: 1. Download NHN watershed in .osm format from Yan's server. 2. Use one of the bulk upload scripts. 3. Download area from OSM with JOSM and fix any issues. For BC non-coastal watersheds, Canvec is equal to NHN. There was an issue with watersheds abutting against the coast, but I can't remember if this was resolved (and a quick search through my email history turns up nothing). Sam's purpose of the oneway=yes tag was twofold: to get waterflow direction arrows to render, and to show that the flow direction was verified (could have used a direction_verified=yes tag). This goes against the standard for OSM tagging of waterways, since the direction of the way itself implies waterflow direction. Mapnik doesn't render flow direction, but that's a matter of the renderer, not the data, just like Richard said. I don't think Sam's (or MBiker's) imports need to be wiped, since that would mean a couple months from now someone will just do the same thing from Canvec. Or if you are anti-import, you can delete the data, put on some bug spray and hiking boots and go map the streams yourself. Now to get back to the original question. I disagree that connectors should be upgraded to stream. On the talk-us list, they gave the example of a river still running through a man-made reservoir, so upgrading to stream would be okay, but in most cases, I don't think it would be appropriate. I think it would be incorrect to think that Chilliwack River flows underneath Chilliwack Lake or Sweltzer River flows through Cultus Lake. In most cases they shouldn't be rendered, since it only makes sense to have the lake rendered. It's not just a rendering issue though, I think connectors are logically different from normal waterways. The purpose of the connector ways (as far as I can think of) is for topological reasons. It's useful to see how different streams and rivers flow through lakes, and how they are connected to each other. We could ask, for example, can a fish swim from Cultus Lake to Chilliwack Lake, or if ammonium chloride spills into Slesse Creek, where will it end up?. This is why the connector ways are present. You could potentially make a script that analyzes inflowing and outflowing waterways connected to a lake, and makes the connectors automatically, but having the connectors there already makes it easier and verified. The difference between stream and river is size. Are there cases where waterways large enough to be rivers are tagged as stream in NHN? Be careful when selecting the better data based on imagery. The non-NHN waterways are probably traced from Yahoo, so using Yahoo to see which waterway is more accurate has obvious bias towards the non-NHN way. Try to use a third source (Bing), or look to see if there are obvious reasons to choose one over the other (eg. if Yahoo shows a stream redirected around new housing, then Yahoo is probably more accurate than NHN). Be careful removing source tag. We still need to acknowledge Geobase/NRCan as a source of at least part of the data. Keeping an attribution=Geobase Canada or attribution=Natural Resources Canada should be enough. Adam On Tue, Feb 22, 2011 at 7:43 AM, Paul Norman penor...@mac.com wrote: As an aside, the imports in the lower mainland were not done by Sam, but by mbiker. I'm not sure on the exact import process used for the NRN data. If I were to do the imports over again myself I think I'd use CanVec 7.0 which seems to have the same data but I haven't evaluated it in any detail. -Original Message- From: Sam Vekemans [mailto:acrosscanadatra...@gmail.com] Sent: Tuesday, February 22, 2011 6:52 AM To: Kevin Michael Smith; Talk-CA OpenStreetMap Subject: Re: [Talk-ca] Proposal: Cleanup of NHN ways in BC Cool, if i knew how to edit a stylesheet i would :) So t hat's fine. So perhaps then it can be all changed with a bot? ... or is it better to simply wipe my edits? The rivers (without oneway=yes tag) is available in another api, so it's no big deal. cheers, Sam On 2/22/11, Kevin Michael Smith smit...@draconic.ca wrote: On Tue, 2011-02-22 at 06:34 -0800, Sam Vekemans wrote: Great! Were getting somewhere.. Now lets discuss the most appropriate tag that can
Re: [Talk-ca] Proposal: Cleanup of NHN ways in BC
Adding in step 5 sounds just fine. I didn't know about the lack of waterway=river in NHN, since I had already Yahoo traced all the major rivers in my area long before the NHN import had even started, and only had to bring in riverbanks from Canvec :) I'd say I'm in agreement now. Adam On Tue, Feb 22, 2011 at 6:24 PM, Paul Norman penor...@mac.com wrote: Thanks for the background - that explains why some things are the way they are and some of the oddities. For connector ways, I'd estimate that 95% of them are for very small bodies of water without names or for rivers, where it does make sense to talk about the river flowing through. For the relatively rare case of a large body of water I could then revert it to sub_sea=* A typical example of a connector waterway is http://www.openstreetmap.org/browse/way/72831492 NHN had no ways tagged as waterway=river, all the rivers were tagged as waterway=stream or sub_sea=stream. An example of this is the Indian River, which was tagged as sub_sea for approximately 20 km and then was a mix of sub_sea=stream and waterway=stream for the remainder. I've found Bing's imagery in rural areas is often the same as that on the BC openmaps server and very accurately aligned, so I was planning on using Bing. Attribution will be preserved Anyways, back to the concerns about connector waterways. What would you think about if I added in with step 5 reverting sections of waterways under large lakes to sub_sea? I know that after doing all of these steps that some waterways may be mistagged, but it should be significantly fewer than currently and after simplification and joining named ways together it should be easier to go in and edit. -Original Message- From: Adam Dunn [mailto:dunna...@gmail.com] Sent: Tuesday, February 22, 2011 9:38 AM To: Paul Norman Cc: Talk-CA OpenStreetMap Subject: Re: [Talk-ca] Proposal: Cleanup of NHN ways in BC Right, the NHN import in the area mentioned was done by MBiker. MBiker was a pretty big mapper for the Vancouver area. He started off doing lots of manual edits by biking around and gps'ing, then he got involved in the NRN road import for east GVRD, then he did NHN for the entire watershed area (08X-something?). The problem with his NHN import was that he bit off more than he could chew. He was going around fixing and cleaning the NHN stuff he imported (like a good importer should do), but he suddenly stopped working on OSM in October. I think maybe the size of the import was too daunting for one man? The process used for importing NHN was different depending on how much was being imported at once. When an entire watershed was done (which is the case here), it was: 1. Download NHN watershed in .osm format from Yan's server. 2. Use one of the bulk upload scripts. 3. Download area from OSM with JOSM and fix any issues. For BC non-coastal watersheds, Canvec is equal to NHN. There was an issue with watersheds abutting against the coast, but I can't remember if this was resolved (and a quick search through my email history turns up nothing). Sam's purpose of the oneway=yes tag was twofold: to get waterflow direction arrows to render, and to show that the flow direction was verified (could have used a direction_verified=yes tag). This goes against the standard for OSM tagging of waterways, since the direction of the way itself implies waterflow direction. Mapnik doesn't render flow direction, but that's a matter of the renderer, not the data, just like Richard said. I don't think Sam's (or MBiker's) imports need to be wiped, since that would mean a couple months from now someone will just do the same thing from Canvec. Or if you are anti-import, you can delete the data, put on some bug spray and hiking boots and go map the streams yourself. Now to get back to the original question. I disagree that connectors should be upgraded to stream. On the talk-us list, they gave the example of a river still running through a man-made reservoir, so upgrading to stream would be okay, but in most cases, I don't think it would be appropriate. I think it would be incorrect to think that Chilliwack River flows underneath Chilliwack Lake or Sweltzer River flows through Cultus Lake. In most cases they shouldn't be rendered, since it only makes sense to have the lake rendered. It's not just a rendering issue though, I think connectors are logically different from normal waterways. The purpose of the connector ways (as far as I can think of) is for topological reasons. It's useful to see how different streams and rivers flow through lakes, and how they are connected to each other. We could ask, for example, can a fish swim from Cultus Lake to Chilliwack Lake, or if ammonium chloride spills into Slesse Creek, where will it end up?. This is why the connector ways are present. You could potentially make a script that analyzes inflowing and outflowing waterways connected to a lake
[Talk-ca] Firing Range Mistagged as Cemetery?
A couple years ago, before the CFB closed down, there was a firing range for the military. A high school has since been built there, but you can see [1] for the approximate position (the range still appears in Yahoo and Bing). I was doing some Canvec 7 import for my area, and noticed that this area was marked as a cemetery. I think that Canvec 7 might have an issue with mistagging military=range or sport=shooting as landuse=cemetery (in a similar way to the already identified comical school-prison mistag). Unfortunately I don't know of any other ranges where I can test this theory. Might be something to look into. Or maybe it really was a cemetery before the military took over? Adam [1] http://www.openstreetmap.org/browse/node/281579645 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Coastline vs. water
I'm not seeing any problems. Bounding box or way id or screenshots would help. Copied from [1]: At low zoom levels, up to and including zoom level 9, Mapnik renders all the sea as a solid fill of blue, generated from the shapefile shoreline_300 (used for z0-9), which has a relatively low resolution. At high zoom levels the coast polygons used are generated from the natural=coastline tag -- the data is made available to the Mapnik renderer as a large shapefile (processed_p) which is generated every few weeks from planet dumps (note: if you edit coastline at high zooms, be patient for it to render). So you are only affecting the high zoom levels, if I understand correctly. You'll need to make sure the coastline ways create a closed loop of ways, of course. Adam [1]: http://wiki.openstreetmap.org/wiki/Coastline On Mon, Feb 21, 2011 at 11:30 AM, Samuel Dyck samueld...@gmail.com wrote: Hi I changed the tagging on the lower part of Lake Winnipeg from water to coastline so it would show up on lower zoom levels. But now the area I changed has disappeared from higher zoom levels. I know coastline tagged way only update ever few weeks, but I thought it only affected lower levels. I am incorrect? 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] Simplifying CanVec imports
Does simplifying like this cause issues where one feature joins up with another feature? I'm assuming that JOSM won't move end nodes of ways during simplification, so rivers connecting to lakes should be okay, but what about places where there is a common node in the middle of a way? Are there instances of this in Canvec, or does the Canvec conversion process always split ways where there are nodes common to more than one object? If you simplify ways today, how will that affect imports in the future, when the next version of Canvec comes out? Adam On Sun, Feb 13, 2011 at 8:45 AM, Daniel Begin jfd...@hotmail.com wrote: Hi Samuel, It might be a good idea to simplify some features before importing. It is not necessary for all features, and the feature's node density usually varies by provinces/theme. In BC, hydro network is really dense as you already figured out. In Quebec, the new road network often needs to by simplified. I would say just do it if it is required for the tile/theme you are importing Daniel From: Samuel Longiaru [mailto:longi...@shaw.ca] Sent: February-11-11 10:38 To: talk-ca@openstreetmap.org Subject: [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 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] How should a noob proceed?
As the person who did GeoBase import for Kamloops, I thank you for checking over the work! Kamloops already had some mapping done in the area before I started the import, so it was difficult making sure everything was correct. My knowledge of Kamloops is pretty much restricted to the highway and the Costco (cheap pizza on the way to Sun Peaks!). I noted on the import spreadsheet [https://spreadsheets.google.com/ccc?key=0Am70fsptsPF2dERFUlBodFFmbmJiR3BBMHR4MzJDM1Ehl=en#gid=3] for the Kamloops tile (092I09) that lots of roads converted from single way to dual oneways, though in some cases (eg trans-canada near oriole) the single biway was retained. Also be on the lookout for fixme=* tags and note=* tags, as I will put notes for future local mappers in there. I really like to use JOSM. Whichever tool you use, you'll get used to it and learn the little tricks over time. Adam On Sat, Jan 29, 2011 at 1:14 PM, Samuel Longiaru longi...@shaw.ca wrote: Greetings Everyone, I'm quite new at this, having only been involved in the OSM project for the past few months. First post to the group. I think the project is a noble one and see that this is something that I would like to stick with long-term. I have been mapping in and around Kamloops, BC where I seem to be a bit of a lone wolf. There don't seem to any members listed in the area that are doing anything at all. I've spent most of my mapping time correcting errors in the previous GeoBase imports and addressing those noted in Keep Right. Also, I've been linking features (railroads, rivers, etc) that are mapped both east and west of my area. Anyway, I've been following the discussion for the last little while in regards to the Canvec data and it has brought up the question in my mind as to what you see as the most effective use of my time. While I don't mind proceeding as I have, I'm wondering if my time might best be spent reviewing and correcting date that have been imported into the area. I mean, I don't mind mapping the Fraser and North Thompson rivers, or adding lakes and such... but if those data are available elsewhere, then perhaps those data should be imported and I should spend my time reviewing those data from the area I know best... south central BC. Theres's no point in duplicating efforts. My immediate problem is that I am not familiar enough with the tools or the process for even checking out the quality of the Canvec data in this area. I suspect it is better than what is here now. So either if someone were willing to import a block from an area nearby, or be willing to act as a mentor and guide me off list through the process, then perhaps I could proceed a bit more effectively. I've tried to research the process myself, but hate to screw something up if you know what I mean. Thanks for any input and/or assistance. And sorry... yes, another Sam on the list. Sam Longiaru 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
[Talk-es] Vacaciones en Mexico
Please excuse my use of English: In two weeks I am going to go on vacation near Cozumel, Mexico. Is there anybody in the osm-mx community that could tell me more about the current status of mapping in Mexico? I have lots of experience mapping in Canada already. [ http://www.openstreetmap.org/user/Adam%20Dunn] Adam -- Google Translate/Traductor Google -- En dos semanas me voy a ir de vacaciones cerca de Cozumel, México. ¿Hay alguien en la comunidad osm-mx que me dijera más sobre el estado actual de la cartografía en México? Tengo un montón de asignación de experiencia en Canadá ya. [http://www.openstreetmap.org/user/Adam%20Dunn] Adam ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-ca] UBC, Vancouver orthography, and street alignment
Here's the NRN (6.0, but I see 7.0 is now available on the NRN website) 092G06C file that I used for import, if you want that as a reference. Some of the NRN roads (remember this is version 6) were out of date (like the Iona Drive/Theology area). I didn't actually import much from NRN, since most roads were already done and other roads were out of date. Yahoo is definitely off in the north end of campus, but near Fairview it's fairly good. That 100mm orthophoto is pretty good. Not only is it high resolution, but it's fairly recent. The Marine Drive Commons Block is still under construction, but the brick pathways have been laid - this puts the photo at around March/April/May of 2009. It looks like they still have the sprinkler system piping laid out on the ground, but my memory is hazy on when that was installed. Adam On Mon, Nov 1, 2010 at 9:06 AM, Tonkin, Bruce ILMB:EX bruce.ton...@gov.bc.ca wrote: Paul, To verify your data you could also use the Province of BC's WMS Services. Here are two that you may find useful for the UBC Area. Road Network: http://openmaps.gov.bc.ca/mapserver/base2?service=WMSREQUEST=GetMapSER VICE=WMSVERSION=1.1.1LAYERS=DRA_DIGITAL_ROAD_ATLAS_LINE_SPSTYLES=FOR MAT=image/pngBGCOLOR=0xFFTRANSPARENT=TRUESRS=EPSG:4326BBOX=-123. 265021881044,49.2499715666015,-123.232373077585,49.2776350737241WIDTH=1 002HEIGHT=849http://openmaps.gov.bc.ca/mapserver/base2?service=WMSREQUEST=GetMapSER%0AVICE=WMSVERSION=1.1.1LAYERS=DRA_DIGITAL_ROAD_ATLAS_LINE_SPSTYLES=FOR%0AMAT=image/pngBGCOLOR=0xFFTRANSPARENT=TRUESRS=EPSG:4326BBOX=-123.%0A265021881044,49.2499715666015,-123.232373077585,49.2776350737241WIDTH=1%0A002HEIGHT=849 100mm Orthophoto: http://openmaps.gov.bc.ca/imagex/ecw_wms.dll?REQUEST=GetMapSERVICE=WMS; VERSION=1.1.1LAYERS=REGIONAL_MOSAICS_BC_GVRD_WEST_XC100MM_UTM10_2009ST YLES=FORMAT=image/pngBGCOLOR=0xFFTRANSPARENT=TRUESRS=EPSG:4326B BOX=-123.27242922767,49.2358356991024,-123.218014555238,49.2819415443068 WIDTH=1002HEIGHT=849http://openmaps.gov.bc.ca/imagex/ecw_wms.dll?REQUEST=GetMapSERVICE=WMS%0AVERSION=1.1.1LAYERS=REGIONAL_MOSAICS_BC_GVRD_WEST_XC100MM_UTM10_2009ST%0AYLES=FORMAT=image/pngBGCOLOR=0xFFTRANSPARENT=TRUESRS=EPSG:4326B%0ABOX=-123.27242922767,49.2358356991024,-123.218014555238,49.2819415443068%0AWIDTH=1002HEIGHT=849 Thanks, Bruce Tonkin -Original Message- From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of talk-ca-requ...@openstreetmap.org Sent: Sunday, October 31, 2010 5:00 AM To: talk-ca@openstreetmap.org Subject: Talk-ca Digest, Vol 32, Issue 16 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. UBC, Vancouver orthography, and street alignment (Paul Norman) -- Message: 1 Date: Sat, 30 Oct 2010 21:18:03 -0700 From: Paul Norman penor...@mac.com To: talk-ca@openstreetmap.org Subject: [Talk-ca] UBC, Vancouver orthography, and street alignment Message-ID: 000301cb78b2$9c973c60$d5c5b5...@mac.com Content-Type: text/plain; charset=us-ascii UBC in Vancouver has been suffering from issues of building misalignment because the Yahoo orthography is misaligned with the ground and suffers from distortion[1]. The City of Vancouver offers some mapping data [2] which can be used with OSM. I've taken 16 tiles that cover most of UBC and corrected most of the streets to these as these reflect the GPS traces, CanVec data, and my knowledge from being a student. They are also high resolution, being listed as 40cm, but I can easily make out smaller features. I've also done some micro-mapping around the SUB, Buchanan, the Chan Center and Rose garden, and down by CEME. As the process to convert the .ecw files is a long and computationally heavy one if anyone wants the resulting slippymap which can be used with the JOSM slippymap plugin and is regularly at UBC I could burn them onto a CD. I also have all of Vancouver processing to make a slippymap, but it has only been about 25 hours so it is not finished yet. If anyone wants that, it'll take multiple DVDs. Of course, anyone could recreate it from the downloaded files but anticipate gdal2tiles taking about 30-40 hours on a good computer. If anyone notices misaligned streets at UBC and isn't able to get the Vancouver orthography working I'd appreciate knowing and I can align them. [1] http://wiki.openstreetmap.org/w/index.php?title=Canada:British_Columbia :Van
Re: [Talk-ca] UBC, Vancouver orthography, and street alignment
I was under the impression that we cannot use any of this data for OSM. [http://wiki.openstreetmap.org/wiki/Canada_Import_Status] lists Edmonton, Toronto and Vancouver as possible data sources, but this goes against RWeait's Edmontorcouver blogs [ http://weait.com/content/unintended-restrictions]. None of the cities, nor BC, are listed on the main import sources page [ http://wiki.openstreetmap.org/wiki/Import/Catalogue]. When I said the BC 100mm Ortho was nice, I wasn't talking about the license/OSM sense :) Adam On Mon, Nov 1, 2010 at 10:32 AM, Russell P skiinf...@gmail.com wrote: Just to clarify - are we allowed to use the BC orthophotos now as well? Also I might stick the converted Vancouver ortho GeoTIFFs on my web hosting account if they are in demand. Russell On 2010-11-01, at 10:26 AM, Adam Dunn dunna...@gmail.com wrote: Here's the NRN (6.0, but I see 7.0 is now available on the NRN website) 092G06C file that I used for import, if you want that as a reference. Some of the NRN roads (remember this is version 6) were out of date (like the Iona Drive/Theology area). I didn't actually import much from NRN, since most roads were already done and other roads were out of date. Yahoo is definitely off in the north end of campus, but near Fairview it's fairly good. That 100mm orthophoto is pretty good. Not only is it high resolution, but it's fairly recent. The Marine Drive Commons Block is still under construction, but the brick pathways have been laid - this puts the photo at around March/April/May of 2009. It looks like they still have the sprinkler system piping laid out on the ground, but my memory is hazy on when that was installed. Adam On Mon, Nov 1, 2010 at 9:06 AM, Tonkin, Bruce ILMB:EX bruce.ton...@gov.bc.ca bruce.ton...@gov.bc.ca wrote: Paul, To verify your data you could also use the Province of BC's WMS Services. Here are two that you may find useful for the UBC Area. Road Network: http://openmaps.gov.bc.ca/mapserver/base2?service=WMSREQUEST=GetMapSER%0AVICE=WMSVERSION=1.1.1LAYERS=DRA_DIGITAL_ROAD_ATLAS_LINE_SPSTYLES=FOR%0AMAT=image/pngBGCOLOR=0xFFTRANSPARENT=TRUESRS=EPSG:4326BBOX=-123.%0A265021881044,49.2499715666015,-123.232373077585,49.2776350737241WIDTH=1%0A002HEIGHT=849 http://openmaps.gov.bc.ca/mapserver/base2?service=WMSREQUEST=GetMapSER VICE=WMSVERSION=1.1.1LAYERS=DRA_DIGITAL_ROAD_ATLAS_LINE_SPSTYLES=FOR MAT=image/pngBGCOLOR=0xFFTRANSPARENT=TRUESRS=EPSG:4326BBOX=-123. 265021881044,49.2499715666015,-123.232373077585,49.2776350737241WIDTH=1 002HEIGHT=849 100mm Orthophoto: http://openmaps.gov.bc.ca/imagex/ecw_wms.dll?REQUEST=GetMapSERVICE=WMS%0AVERSION=1.1.1LAYERS=REGIONAL_MOSAICS_BC_GVRD_WEST_XC100MM_UTM10_2009ST%0AYLES=FORMAT=image/pngBGCOLOR=0xFFTRANSPARENT=TRUESRS=EPSG:4326B%0ABOX=-123.27242922767,49.2358356991024,-123.218014555238,49.2819415443068%0AWIDTH=1002HEIGHT=849 http://openmaps.gov.bc.ca/imagex/ecw_wms.dll?REQUEST=GetMapSERVICE=WMS; VERSION=1.1.1LAYERS=REGIONAL_MOSAICS_BC_GVRD_WEST_XC100MM_UTM10_2009ST YLES=FORMAT=image/pngBGCOLOR=0xFFTRANSPARENT=TRUESRS=EPSG:4326B BOX=-123.27242922767,49.2358356991024,-123.218014555238,49.2819415443068 WIDTH=1002HEIGHT=849 Thanks, Bruce Tonkin -Original Message- From: talk-ca-boun...@openstreetmap.org talk-ca-boun...@openstreetmap.org [mailto: talk-ca-boun...@openstreetmap.org talk-ca-boun...@openstreetmap.org] On Behalf Of talk-ca-requ...@openstreetmap.orgtalk-ca-requ...@openstreetmap.org Sent: Sunday, October 31, 2010 5:00 AM To: talk-ca@openstreetmap.orgtalk-ca@openstreetmap.org Subject: Talk-ca Digest, Vol 32, Issue 16 Send Talk-ca mailing list submissions to talk-ca@openstreetmap.orgtalk-ca@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-ca http://lists.openstreetmap.org/listinfo/talk-ca or, via email, send a message with subject or body 'help' to talk-ca-requ...@openstreetmap.org talk-ca-requ...@openstreetmap.org You can reach the person managing the list at talk-ca-ow...@openstreetmap.orgtalk-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. UBC, Vancouver orthography, and street alignment (Paul Norman) -- Message: 1 Date: Sat, 30 Oct 2010 21:18:03 -0700 From: Paul Norman penor...@mac.compenor...@mac.com To: talk-ca@openstreetmap.orgtalk-ca@openstreetmap.org Subject: [Talk-ca] UBC, Vancouver orthography, and street alignment Message-ID: 000301cb78b2$9c973c60$d5c5b520$@ http://mac.commac.com Content-Type: text/plain; charset=us-ascii UBC in Vancouver has been suffering from issues of building misalignment because the Yahoo orthography is misaligned with the ground and suffers from distortion[1]. The City of Vancouver offers
Re: [Talk-ca] More CanVec import problems
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 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 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] More CanVec import problems
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 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 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 http://lists.openstreetmap.org/listinfo/talk-ca attachment: josmmultipoly.png___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Fwd: Re: CanVec import troubles
Sam: I'll take one of the water relations as an example. What you would do
is: delete the tagless ways that are currently in OSM and would be linked by
that relation (the ones you had uploaded a week or two ago). This includes
deleting the outer way (the way that represents the outline of the lake),
and the inner way (that surrounds an island). Then make sure to copy the
relation in its entirety and paste that into the OSM layer and upload. Then
run Validator on the data (you can make a selection box around the way so
that Validator will only run on that portion of the data and not the whole
layer). You will get duplicate node errors because the newly copied water
relation ways could share nodes with wood or wetland ways that you have
already uploaded. Merge these nodes, then you should be ready to upload.
The situation is not quite this easy, however. It looks like you (sammuell)
uploaded tagless ways on Sep 12 (take a look at
http://www.openstreetmap.org/browse/way/77328097). Then a bot/human (efred)
went through and deleted duplicate nodes on Sep 15 (again, way 77328097
mentioned above). Then on Sep 19 you uploaded another copy of the same
tagless way again (http://www.openstreetmap.org/browse/way/78124481). So now
there are two copies of these tagless ways in OSM. You will need to delete
both of them from OSM before uploading the proper relation.
I see also that you did not delete the original water body that was uploaded
to OSM two years ago (traced from landsat satellite imagery). Normally you
will delete this original way when uploading the better Canvec data (unless
you are working with some huge lake. If you're working with a large lake
that will take several days or weeks to replace with Canvec, then you want
to split {select a node or two then Tools-Split Way} the lake at the
borders of the Canvec data you are working with, delete the old data that
overlaps with the new Canvec data, and join the new Canvec data to the old
OSM data (merge nodes and combine ways but this can be quite a complex
process especially if you're merging a basic way from the old osm to a
relation in the new canvec).
It looks like some of these problems (like not selecting the whole relation)
is just a matter of experience with Josm. This will come with practice. It
wasn't until about 6 months ago that I figured out relation editing myself,
and I'm still finding little discoveries in Josm. Only two days ago I
figured out how to use Join overlapping areas properly, and it's made me
10% more efficient when importing Canvec on very-sparse areas. Play around
with Josm and learn from your mistakes and things will get easier.
Adam
On Mon, Sep 27, 2010 at 7:20 PM, Samuel samueld...@gmail.com wrote:
Original Message Subject: Re: [Talk-ca] CanVec import
troubles Date: Mon, 27 Sep 2010 21:19:49 -0500 From: Samuel
samueld...@gmail.com samueld...@gmail.com To: Adam Dunn
dunna...@gmail.com dunna...@gmail.com
Hi
So how would I replace the previously uploaded data with fresh CanVec Data.
I can't seem to get rid of the old data without cauing conflicts.
Sam
On 10-09-25 06:43 PM, Adam Dunn wrote:
On Sat, Sep 25, 2010 at 1:31 PM, Tyler Gunn ty...@egunn.com wrote:
I'm not 100% sure what happened with the Canvec data you uploaded, but it
looks like the tags are missing from lot of the ways. The wooded areas are
not showing up because they're not marked natural=wood, and the watered
areas are not showing up water because they're not marked natural = water.
Were these areas originally relations? Remember that to select a relation
(including the tags) in Josm, you have to double-click on the relation in
the relation list, or select it in the list and click on the dotted square
button, or right-click the relation in Member of and select the relation.
Simply highlighting the way is not sufficient. It sounds like this is what
may have happened.
Adam
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Rendering rules and tagging paths and hard shoulders for cycles
Haven't done much bicycle tagging myself. Have you tried tagg...@openstreetmap.org? I would highly recommend including pictures from flickr etc, since different people have different ideas about what a cycle lane is (especially people from different countries). Here in Chilliwack a cycle path is just a hard shoulder, like [ http://www.flickr.com/photos/question_everything/4051911346/] (sometimes not even that wide or clean), but in Europe a cycle path might be more like [ http://www.flickr.com/photos/canadagood/3017259090/] or [ http://www.flickr.com/photos/alanstanton/2319965160/]. Good to include photos of what you're thinking of. Adam On Tue, Sep 28, 2010 at 10:46 AM, john whelan jwhelan0...@gmail.com wrote: I realise there is some differences of opinion on this but I'm looking for guidance. Locally we seem to have a number of these tagged in different ways. CANVEC appears to tag some of them as highway=footway wiki.openstreetmap.org/wiki/Paths seems to have a wide range of acceptable options, including bicycle=designated, bicycle=yes, access=bicycle etc. What is recommended for multi-use paths where cycling is permitted but pedestrians have priority? highway=path highway=path bicycle=yes perhaps? Do we care that some are used as ski trails in winter? Does this suggest dec-march ski april-nov cycle? Ontario is planning to increase paved hard shoulders to promote cycle safety. Quebec I think already has many of these. paved_shoulder=yes shoulder:access:bicycle=yes Has been recommended, any suggestions on rendering rules? Thanks John ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Islands of Manitoba in Nunavut
James Ewen suggested to me off-list that it's possible these were originally Dshpak-style traced lakes. I opened up 055D04.0, and those outlines are definitely lakes. At some point, the lake tags got deleted and the border tags got added. I'm going to just go ahead and delete the current ways, and import Canvec for the area. Give it an hour or two and the area will be fixed. Adam On Sat, Sep 25, 2010 at 9:01 PM, Samuel samueld...@gmail.com wrote: Where did he get this data? It comes with a geobase uuid that partially matches the actual border. It seems he was either hopelessly confused or he knew exactly what he was doing. At this point I'm wondering if all his edits should be removed from the map owing to inaccuracies and unknown sources. Sam On 10-09-25 08:21 PM, Adam Dunn wrote: To those who have been on this mailing list for a while, I'll point out that these were added by vreimer in 2009. Adam On Sat, Sep 25, 2010 at 5:27 PM, Samuel samueld...@gmail.com wrote: 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 mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec import troubles
On Sat, Sep 25, 2010 at 1:31 PM, Tyler Gunn ty...@egunn.com wrote: I'm not 100% sure what happened with the Canvec data you uploaded, but it looks like the tags are missing from lot of the ways. The wooded areas are not showing up because they're not marked natural=wood, and the watered areas are not showing up water because they're not marked natural = water. Were these areas originally relations? Remember that to select a relation (including the tags) in Josm, you have to double-click on the relation in the relation list, or select it in the list and click on the dotted square button, or right-click the relation in Member of and select the relation. Simply highlighting the way is not sufficient. It sounds like this is what may have happened. Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Islands of Manitoba in Nunavut
To those who have been on this mailing list for a while, I'll point out that these were added by vreimer in 2009. Adam On Sat, Sep 25, 2010 at 5:27 PM, Samuel samueld...@gmail.com wrote: 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 mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Any one on Rogers network?
I'm on Shaw Cable (in the Vancouver area), and I get (note for some reason I have tracepath installed instead of traceroute, but effects should be the same): $ tracepath b.tile.openstreetmap.org 1: Hopper.local 0.236ms pmtu 1500 1: 192.168.0.1 0.540ms asymm 2 1: 192.168.0.1 0.592ms asymm 2 2: 70.78.0.113.224ms 3: 64.59.158.14714.354ms 4: rc2wh-tge0-0-0-0.vc.shawcable.net14.368ms 5: rc2so-pos0-7-0-0.cg.shawcable.net28.161ms 6: 66.163.78.22 55.904ms 7: rc2sc-tge0-0-1-0.wp.shawcable.net49.839ms 8: rc1sh-pos13-0.mt.shawcable.net 67.190ms 9: rc1hu-pos2-0-0.ny.shawcable.net 82.192ms 10: rd1ny-pos10-0.ny.shawcable.net 86.237ms 11: xe-0-3-0-204.nyc30.ip4.tinet.net100.426ms asymm 8 12: ge-1-3-0.lon12.ip4.tinet.net177.579ms asymm 10 13: the-jnt-gw.ip4.tinet.net167.451ms asymm 10 14: as0.lond-sbr1.ja.net171.708ms asymm 10 15: LMN-LMN1.site.ja.net170.693ms asymm 10 16: ucl.lmn.net.uk 168.128ms asymm 11 17: no reply 18: no reply repeat Too many hops: pmtu 1500 Resume: pmtu 1500 $ ping b.tile.openstreetmap.org PING b.tile.openstreetmap.org (128.40.168.104) 56(84) bytes of data. ^C --- b.tile.openstreetmap.org ping statistics --- 20 packets transmitted, 0 received, 100% packet loss, time 19004ms None of this adversely affects my OSM viewing though. Note that according to [http://wiki.openstreetmap.org/wiki/Slippy_Map#Mapnik_tile_rendering], If you get 'More OpenStreetMap coming soon...' on a tile, it means there was no data for that tile and it is now in the queue to be rendered. Sometimes if I zoom in really close to an area where nobody has ever zoomed in before, the tile hasn't been rendered yet and I get the coming soon message. If you are finding areas that are rendered and yet you still get coming soon, there could be some other issue at hand. Adam On Fri, Sep 24, 2010 at 1:30 PM, G. Michael Carter mi...@carterfamily.cawrote: For the last month b.tile.openstreetmap.org times out and I get tile coming soon (aka 404 errors) ... and not the only rogers problem I have I might add... When I access it from acanac or bell or rogers 3g network it's fine. Two questions: 1. Any one on rogers? and if so can you send me your traceroute b.tile.openstreetmap.org (linux) or tracert b.tile.openstreetmap.org(windows) 2. Is there a black list on the osm servers that could be causing this? Thanks, Michael ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] ridethecity.com
Don't know much about it, but there is a drop-down box on the top-right that allows you to select from a short list of cities. Toronto is the only Canadian one there. http://ridethecity.com/toronto# Adam On Sun, Sep 5, 2010 at 4:42 PM, john whelan jwhelan0...@gmail.com wrote: I understand its based on OpenStreetMap but does any one know any much about it? Is it implemented in any Canadian cities? Do I assume that roads would have to actually be joined for this or any routing program to work? Thanks John ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Hiding an object
This really sounds like a mapping for the renderer situation (in this case the renderer would be Garmin). This is generally discouraged. You have the address information (in the Karlsruhe schema), but the Garmin converter doesn't support it, so you are adding in extra tags to get better Garmin support. You should be trying to get a really good map database that is agnostic to render engines (be they Mapnik, osmarender, Garmin, or TomTom). It is up to the render engine/converter to improve how it handles the (supposedly) correct database. Having said that, check out http://wiki.openstreetmap.org/wiki/Key:osmarender:render Adam On Tue, Aug 17, 2010 at 2:15 PM, G. Michael Carter mi...@carterfamily.cawrote: Is there a tag to stop mapnik and other rendering engines from rendering an object? My idea for adding campsite numbers hit a brick wall. Seems the reverse engineering of Garmin doesn't support house numbers. So I'm thinking of creating a dual purpose object: addr:city=Rock Point Provincial Park addr:housenumber=56 addr:street=Campsite Roads name=Rock Point Campsite: 56(still working on the name) tourism=camp_site (reason is so it shows up on garmin devices as Lodging) (and possibly other tags still working this out.) On JOSM it renders all the campsite numbers as tent objects. I think this might be very distracting on a map. So I want to hide them from site. But still be there for searching purposes. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec.osm Product - Running!
For the next release, would it be possible to get: 1. A text file (stored on the ftp) that lists all the quadtree-tiles output. Some people might want to write scripts that can do work based on available CanVec osm files, but it would help to know how much subdividing occurred. Currently, we must download the zip file to determine if 092H04.0.1.2 exists or if the tiling stopped at 092H04.0.1. 2. An RSS or Atom feed of the tiles that have been processed. Not as useful as (1), but some people might be interested in knowing the latest without searching around the ftp. This would be most useful when already processed tiles get re-processed, or when tiles get processed in a different order (such as 052A06). Thanks for the great releases! Adam On Mon, Aug 16, 2010 at 8:53 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Hi all, an update on product conversion. So far ... - The process have been running for 42 days; - 11415 files have been processed - an average of 270 files a day; To come this week ... - 052A06 - The rest of the files Miscellaneous ... natural=peak It was supposed to be there but obviously it is not. I'll find the problem and it will be included in the next release. natural=land area features are a duplicate of natural=water inner polygon. It will be removed for the next release. Point features will still be there. Canvec Product Description - Features, geometry and tiling description: http://wiki.openstreetmap.org/wiki/CanVec French Canvec wiki pages I still hope to produce it before the end of the summer! Cheers, Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec.osm Product - Running!
I was intending for the file listing to be sorted alphabetically, while the rss one would be sorted chronologically. Having a timestamp field in the file listing could work though. The advantage to having the RSS/Atom format is that people can plug it into RSS/Atom/xml readers if they use any. Adam On Mon, Aug 16, 2010 at 9:27 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Bonjour Adam, About point 1... I'll see what can be done and, if possible, I will produce it for this release. About point 2... If the text file proposed on point 1 have a date and time field, you could get all the information you are looking for in a single .txt file. Am I right? Cheers, Daniel -- ** ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec Boundries?
An interesting system you've devised there. I'm not aware of any listing of boundaries such as you mentioned, but perhaps Daniel has a verbose log produced by the software that he's using? One of the things I was going to ask about for the next Canvec conversion was an RSS feed (or some similar output) of converted tiles, which would help out programs such as yours. By using the filename of each conversion, the lat/long boundaries are predictable, but you currently need to peek inside the zip files to find out how much quad-tree tiling was done. Adam On Fri, Aug 6, 2010 at 6:42 AM, G. Michael Carter mi...@carterfamily.cawrote: The problem with google docs and wiki, their only useful if people actually maintain what their working on. So for my own personal use I was working on a system to tell where people are working based on the actual data their entering. Problem is I only have the boundaries of the canvec data I've downloaded. (30/31/40/41). ... and even then the boundaries are not 100% accurate, as they tend to over lap. Here's an example of what I have so far... (still matching canvec grids to nodes so data isn't all there yet) I'm also making slippy maps of just the canvec data (again still in progress) ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Merging and Bounding Box Splitting Yan's NLFLOW Data
The Players: Okay, I admit it, I'm not much of a bash scripting person. Actually, I'm not much of a shell scripting person. Everytime I need to use sed or awk, I spend a lot of time Googling to remember correct syntax. So I've written a script, but it doesn't quite work, and I'm hoping lazyweb (read second paragraph of http://en.wikipedia.org/wiki/Lazyweb if you've never heard of lazyweb) can help out. Yan Morin has done a wonderful job of taking the NHN data and converting NLFLOW and WATERBODY over to OSM format [ http://osm.progysm.com/rncan/geobase/nhn_rhn]. Unfortunately, the tool he used bins ways at seemingly random instead of geographically (the purpose of the binning is to write out multiple files that are smaller). Those people who have done importing of nhn flow will know what I'm talking about. So I wrote a script that will take some RWeait sed-foo and combine it with Osmosis to merge all the nhn files and then split/bin them back out using geographical bounding boxes. The Set-Up: Download Osmosis 0.35 from [http://wiki.openstreetmap.org/wiki/Osmosis]. I've written the script to use 0.35 because that's the last release that had official support for API 0.5 files. You could use Osmosis 0.35.1, but things are less guaranteed, I guess. Unzip Osmosis into your home directory, so that the osmosis executable can be found at ~/osmosis-0.35/bin/osmosis. Create a new directory somewhere else in your home folder (perhaps ~/osmfiles/nhn/08HE0X1 or maybe ~/nhnfiles/Tahsis) to store all the files for a single water basin from Yan's server. Download *all* the files for a single water basin into that directory. Download the script (attached) and put it anywhere on your computer, and make it executable (chmod u+x nlflowrebox.bash). The Hook: While in the directory that contains all (and only) the files for one basin, run the following command: ~/path/to/nlflowrebox.bash You'll get a bunch of files, named similar to Split_49.58_-126.00.osm, which is the lat/long of the bottom-right corner of the bounding box for that file. Start importing using Josm. You'll also get a _COMPLETE.osm file, and if the area is really small, or you have lots of ram, you could just use this instead of the bounded files. The Shut-Out: Watch it fail. At least on my computer. If it works on your computer, you're very lucky. For some reason, I keep getting errors about how it can't find the osmosis executable, or how osmosis can't find the file (But it's right there!). If anyone knows how to fix the problem, or how to improve the script in other ways, I'm open to suggestions or patch files (preferably patch files). The Wire: There's a way around the problem though. I've set up the script to print out the two commands that it's attempting to run. So all you have to do is run the command once, then copy the part that says Merge command is ~/osmosis-0.35/bin/osmosis --read-xml-0.5 --write-xml file=NHN_NLFLOW_COMPLETE.osm (only don't copy the Merge command is, just copy the ~/osmosis...) and paste it into the command line and run it. This will create the fully merged complete file. Then you run the nlflowrebox.bash command again and copy the Split Command is ~/osmosis-0.35/bin/osmosis --read-xml .--write-xml file=Split_49.98_-126.80.osm (only don't get the part that says Split Command is, just the stuff after), and paste that into your command line and run it. You'll get all the split files for your importing pleasures. The Sting: There's still some minor problems; dealing with duplicate nodes. You'll find that duplicate nodes are still there where ever two or more streams intersect. Either fix these using Josm validator or send me a .patch. Also, any way that crosses a bounding box boundary will appear in both bounding boxes, so be careful when importing along file edges. The Tale: Here's what I really would've like to see for a splitting/binning system such as this: topologically aware binning. Hydro flow data is almost an acyclic n-ary tree graph (not quite acyclic, but close). It would be nice if there was a binning system that could perform a reverse depth-first search and add ways to a file starting from a leaf way and slowly adding siblings and parents until a max number of ways is reached. Then it continues by adding into a second file, and a third file, etc. This would be better at binning things like rivers/creeks. I don't think such a system exists for OSM, and I certainly don't have the gis skills to pull it off. Chapter titles are courtesy of a Newman/Redford/Shaw movie (though slightly reorganized). Adam nlflowrebox.bash Description: Binary data ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Tags.. Showers, Camp Store, Trailer dumping?
When you say Trailer Dumping area, I guess you're talking about the sani-dump, where a travel trailer will dump excrement, waste water, and other garbage (along with the ability to pick up fresh water). These I tag as amenity=waste_disposal, waste=excrement as per http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dwaste_disposal The camp store would probably be shop=convenience, but it might be shop=outdoor or shop=variety_store depending on what they sell there. The comfort stations which have laundry facilities and showers could probably be tagged as building=yes, washing_machine=yes, shower=yes. See http://wiki.openstreetmap.org/wiki/Proposed_features/Extend_camp_sitefor more ideas. Adam On Tue, Aug 3, 2010 at 8:08 AM, G. Michael Carter mi...@carterfamily.cawrote: I've mapped out Rock Point Provincial Park (well 98% of it I'd say) and how do I tag the Trailer Dumping area, Camp Store, and the comfort stations with showers and laundry? Mikey ___ 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] Hiking trails - Is bad data better than no data?
You've got the right idea. I'm the only hiking trail mapper for the Upper Fraser Valley (so far), and I do basically the same thing. The trails I hike are non-circuits, so I get a track both in and out. Then I upload the track so that future mappers with tracks will be able to average my track plus their track. Then I trace the average of what I have. It's better to have a poor hiking trail on OSM than none at all, since it will make it easier for other OSMers to discover places to go and grab better gps tracks. You can also name the gpx track saying (inaccurate) if you want. For the OSM ways, you can use the tag accuracy=* (where * is some number in meters). It's not an official tag, but the imports have been using it a lot, and it will be visible to other editors (Canadian mappers will be used to seeing it from all the NRN/NHN imports). Hiking trails aren't something included in the government imports, so it's good to get as much as you can. Logging roads as well. Adam On Sun, Jul 25, 2010 at 7:57 PM, Darryl Shpak dar...@shpak.ca wrote: Hey all, A quick question here, since I'm somewhat out-of-touch with OSM best practices right now. Last week I hiked a couple of trails in a local provincial park, and collected traces with intent to map them. However, I know the data is of questionable quality...on the first trail, I walked one segment twice and there's a significant disparity between the two gps tracks, and on the second trail, my GPS was reporting 20-30m position error at times. Neither of these trails existed in OSM at all (no GPS tracks, no ways). I've uploaded my GPS traces and I'm mapping my trails on the assumption that an inaccurate trace is better than no data at all, but wanted to check with the wider community to see what the general consensus was on this. Is there anything special I should tag the trace or way with to indicate that I know the tracks are a little flaky? Sample trail: http://www.openstreetmap.org/?lat=49.69252lon=-95.33649zoom=16layers=M - Darryl ___ 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] Misspelled British Columbia in Protected Areas data
I was importing the boundary for E.C. Manning Prov Park and Cascades Recreation Area, which have so far been missing on OSM, when I realized that British Columbia was spelled wrong in English. This misspelling is right in the original shape file from http://geogratis.cgdi.gc.ca/geogratis/en/collection/detail.do?id=BA8D1149-7714-EC04-343B-6AFEC3BDA84A This misspelling (u versus the second o) is a common mistake made when confusing the spelling of the Canadian province with the spelling of the South American country or the English versus French spellings. This appears to affect every protected area imported from that file into OSM. The country: English: Colombia French: Colombie The province: English: British Columbia (note the u) French: Colombie-Britannique (note the o) What GeoGratis has: PROV_EN=British Colombia (note the incorrect o) PROV_FR=Colombie-Britannique (this is correct) Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Misspelled British Columbia in Protected Areas data
Let's say for example that you have the protected areas shp file downloaded
from the geogratis website, and let's also say you have ogr2osm installed on
your computer. You could potentially download the attached file, and place
it in a folder called translations inside the same folder that the
shapefile is unzipped to. You could then possibly run the following command:
ogr2osm.py -t nrcan_protected protarea.shp
You could then, hypothetically, suggest any changes to the tagging.
Here's what ogr2osm found:
Detected projection metadata:
GEOGCS[GCS_WGS_1984,
DATUM[WGS_1984,
SPHEROID[WGS_1984,6378137.0,298.257223563]],
PRIMEM[Greenwich,0.0],
UNIT[Degree,0.0174532925199433]]
All values for attribute PROV_EN:
{'Alberta / Northwest Territories': 1, 'Ontario': 330, 'Newfoundland and
Labrador': 30, 'Saskatchewan': 196, 'Prince Edward Island': 3, 'British
Columbia': 22, 'Nova Scotia': 38, 'Quebec': 238, 'British Colombia': 287,
'Alberta': 116, 'Manitoba': 64, 'Northwest Territories': 12, 'New
Brunswick': 18, 'Nunavut': 22, 'Yukon': 21}
All values for attribute PROV_FR:
{'Alberta / Territoires du Nord-Ouest': 1, 'Territoires du Nord-Ouest': 12,
'Ontario': 330, 'Nouveau Brunswick': 2, 'Saskatchewan': 196,
'\xcele-du-Prince-\xc9douard': 3, 'Qu\xe9bec': 238, 'Nouvelle-\xc9cosse':
38, 'Colombie-Britannique': 309, 'Yukon': 21, 'Alberta': 116, 'Manitoba':
64, 'Nouveau-Brunswick': 16, 'Nunavut': 22, 'Terre-Neuve-et-Labrador': 30}
(The command line puts out hex values like \xc9, but the osm file has
accented characters)
Adam
On Tue, Jul 20, 2010 at 10:15 AM, Adam Dunn dunna...@gmail.com wrote:
I was importing the boundary for E.C. Manning Prov Park and Cascades
Recreation Area, which have so far been missing on OSM, when I realized that
British Columbia was spelled wrong in English. This misspelling is right in
the original shape file from
http://geogratis.cgdi.gc.ca/geogratis/en/collection/detail.do?id=BA8D1149-7714-EC04-343B-6AFEC3BDA84A
This misspelling (u versus the second o) is a common mistake made when
confusing the spelling of the Canadian province with the spelling of the
South American country or the English versus French spellings. This appears
to affect every protected area imported from that file into OSM.
The country:
English: Colombia
French: Colombie
The province:
English: British Columbia (note the u)
French: Colombie-Britannique (note the o)
What GeoGratis has:
PROV_EN=British Colombia (note the incorrect o)
PROV_FR=Colombie-Britannique (this is correct)
Adam
Translation rules for Natural Resources Canada - Protected Areas
def translateAttributes(attrs):
if not attrs: return
tags = {}
#Standard attribution and source tagging
tags.update({'source':'NRCan Protected Areas Import 2010'})
tags.update({'source:url':'http://geogratis.cgdi.gc.ca/geogratis/en/collection/detail.do?id=BA8D1149-7714-EC04-343B-6AFEC3BDA84A'})
tags.update({'attribution':'Natural Resources Canada'})
# Use the NAME_EN attribute as the name= tag
if attrs['NAME_EN']:
tags.update({'name':attrs['NAME_EN']})
# Use the NOM_FR attribute as the name:fr= tag
if attrs['NOM_FR']:
tags.update({'name:fr':attrs['NOM_FR']})
# Use the PROV_EN attribute as the is_in= tag
if attrs['PROV_EN']:
#fix the English misspelling of British Columbia
if attrs['PROV_EN'] == 'British Colombia':
tags.update({'is_in':'British Columbia'})
else:
tags.update({'is_in':attrs['PROV_EN']})
# Use the PROV_FR attribute as the is_in:fr= tag
if attrs['PROV_FR']:
tags.update({'is_in:fr':attrs['PROV_FR']})
# Depending on the value of TYPE, set leisure, boundary and boundary:type tags
if attrs['TYPE'] == 'PA':
tags.update({'boundary':'national_park'})
tags.update({'leisure':'nature_reserve'})
tags.update({'boundary:type':'protected_area'})
elif attrs['TYPE'] == 'PRFA':
tags.update({'boundary':'national_park'})
tags.update({'leisure':'nature_reserve'})
tags.update({'boundary:type':'Prairie Farm Rehabilitation Association Area'})
elif attrs['TYPE'] == 'MBS':
tags.update({'boundary':'national_park'})
tags.update({'leisure':'nature_reserve'})
tags.update({'boundary:type':'Migratory Bird Sanctuary'})
elif attrs['TYPE'] == 'NWA':
tags.update({'boundary':'national_park'})
tags.update({'leisure':'nature_reserve'})
tags.update({'boundary:type':'National Wildlife Area'})
elif attrs['TYPE'] == 'NP':
tags.update({'boundary':'national_park'})
tags.update({'leisure':'nature_reserve'})
elif attrs['TYPE'] == 'MPA':
tags.update({'boundary':'national_park'})
tags.update({'leisure':'nature_reserve'})
tags.update({'boundary:type':'Marine Protected Area'})
return tags
#sys.exit()
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Fwd: Wiki page on meetup
Sam was replying to an off-list message, so here's the wiki link: http://wiki.openstreetmap.org/wiki/Vancouver/July2010 Once we have a location figured out, I'm going to add the event to the calendar of events on the OSM wiki main page. Anybody know a good place to go? Got any connections? Adam On Sat, Jul 17, 2010 at 1:25 AM, Sam Vekemans acrosscanadatra...@gmail.comwrote: Hi all. For anyone who will be in Vancouver on july 27th and july 28th, please add your names to the wiki page for the RSVP so then we can pick a location which would be best. For the who are remote, attendence is VERY welcome via skype call and video, as your insights are valuable, the more people we have attending, the more lively the debate :-) and also, depending on who attends it will shape the discussions. (we will also have the #osm-ca irc chat open also) i'll be in town for the day on the 28th so im happy to meetup we just need to arrange a time. if your unable to attend, but wanted to, please list your name, so then we can plan for the next meetup in the fall, as part of a trans-canada mapping marathon. cheers, Sam Vekemans Across Canada Trails -- Forwarded message -- From: Adam Dunn dunna...@gmail.com Date: Fri, 16 Jul 2010 10:39:03 -0700 Subject: Wiki page on meetup To: Sam Vekemans acrosscanadatra...@gmail.com http://wiki.openstreetmap.org/wiki/Vancouver/July2010 -- Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Fwd: Wiki page on meetup
1198 W Pender is around the intersection of Bute and Pender. The OSGeo meeting is at 1177 W Hastings (1 street over and 11 address parcels down). They're about 200 meters apart. Have you been there before Alan? Are they accepting of large crowds gathering for 2 hours? My list of people to email is around 50 and I'm hoping for 5 or 6 to show up. I'm sure some of us would buy drinks, of course... Adam On Sat, Jul 17, 2010 at 1:52 PM, Alan McConchie alan.mcconc...@gmail.comwrote: If we want a location really close to the OSGeo meeting, we could go to Waves at 1198 W Pender Street. Free WiFi, probably a lot of power outlets. Alan On Jul 17, 2010, at 8:05 AM, Adam Dunn wrote: Sam was replying to an off-list message, so here's the wiki link: http://wiki.openstreetmap.org/wiki/Vancouver/July2010 Once we have a location figured out, I'm going to add the event to the calendar of events on the OSM wiki main page. Anybody know a good place to go? Got any connections? Adam On Sat, Jul 17, 2010 at 1:25 AM, Sam Vekemans acrosscanadatra...@gmail.com wrote: Hi all. For anyone who will be in Vancouver on july 27th and july 28th, please add your names to the wiki page for the RSVP so then we can pick a location which would be best. For the who are remote, attendence is VERY welcome via skype call and video, as your insights are valuable, the more people we have attending, the more lively the debate :-) and also, depending on who attends it will shape the discussions. (we will also have the #osm-ca irc chat open also) i'll be in town for the day on the 28th so im happy to meetup we just need to arrange a time. if your unable to attend, but wanted to, please list your name, so then we can plan for the next meetup in the fall, as part of a trans-canada mapping marathon. cheers, Sam Vekemans Across Canada Trails -- Forwarded message -- From: Adam Dunn dunna...@gmail.com Date: Fri, 16 Jul 2010 10:39:03 -0700 Subject: Wiki page on meetup To: Sam Vekemans acrosscanadatra...@gmail.com http://wiki.openstreetmap.org/wiki/Vancouver/July2010 -- Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CANVEC data for Ottawa
http://stfu.blogs.ablenet.org/100/how_to_connect_to_irc_with_pidgin_gaim The server you want is irc.oftc.net Once you are on the server, you can type /join #osm-ca to join the channel. There's not really an account managing system that you have to sign up with. OFTC does have nickserv support, but it's optional (I think). Adam On Sat, Jul 17, 2010 at 1:42 PM, john whelan jwhelan0...@gmail.com wrote: Do you have an idiot guide on how to do this? I've picked up Pidgin so I assume its just a matter of getting an account somewhere? The Canvec OSM data looks extremely good. Thanks John On 17 July 2010 12:38, Sam Vekemans acrosscanadatra...@gmail.com wrote: P.S. Feel free to jump on the #osm-ca IRC chat on oftc.net irc://irc.oftc.net/#osm-ca we now have 11 people online :) ... mostly from Canada I use Pidgin Messenger, i find it's the easist. This way, others who are working on the data will know who is working where :) ... and we're all in the same boat, figuring out the best methods. Cheers, Sam On Sat, Jul 17, 2010 at 9:28 AM, john whelan jwhelan0...@gmail.com wrote: How do I find it and is it available yet? I suspect it isn't. Thanks John ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Copying objects with relations between layers in josm
Silly me, I forgot to reply all, and just did a reply. Here's what I said to James originally: In josm, open the relation editor (the button icon has a gear cog) In the relation editor, click the relation you want to copy. At the bottom of the relation editor, click set the current selection to the list of selected relations (the button icon is a mouse cursor inside a square marching ants selection box) Ctrl-c switch layers ctrl-v You should have all the nodes, ways, and the relation connecting the ways copied over. Tyler: just attempted your method in Josm 3359, and it only copied over the nodes and ways, but not the relation. This could be due to different josm versions? Adam On Wed, Jul 14, 2010 at 10:06 AM, Tyler Gunn ty...@egunn.com wrote: On Wed, 14 Jul 2010 12:35:06 -0400, James A. Treacy tre...@debian.org wrote: Hello, What is the best way to copy objects, including a relation, between layers in josm? For example, if there is a wooded area with a hole in it and you copy the desired objects to another layer, the relation is not copied. There must be a way to do this! In the relation list, if you find the relation you can right click it and choose Select all members. Then when you copy and paste the relation as well as all its members come over. Tyler -- -- Tyler Gunn ty...@egunn.com ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec.osm Product - Last Call !!!
I haven't been able to find any other issues with the Vancouver area data, and the solutions to these problems seem reasonable. So I guess it's okay to go ahead with what we have. On the topic of reefs: from what I've seen in comparing Canvec reefs with aerial photography, it looks like reefs will have to be handled on a case-by-case basis anyways. Thus, changing the tag mapping schema for this conversion process probably wouldn't help anyways. On Fri, Jul 2, 2010 at 9:07 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Bonjour Adam - and all, Needs to fix something? So far... *Toponymy - too many spaces along with cardinal direction: * It seems to be a problem with some of the original BC data. I will log it to appropriate authorities to have the source corrected. No program fixes needed. It will have to be done by local mappers when necessary. *Toponymy - Derived from NHN data:* When toponyms becomes available in NHN data, they are included in the next Canvec release - usually within less than 6 months *Reefs - duplicate way tagged natural=water:* In Canvec Product, a reef creates a hole in the surrounding water area. I did not changed the Canvec data model, except for addressing schema. If you use the duplicate way tagged natural=water, it should be to define an inner polygon in a Multipolygon relation. I would suggest to check the rendering for each scenario - even if we are not supposed to map for the rendering... *Coastline - changing natural=water for natural=coastline for coastal water: *It all depends on the definition of coastal water! The Canvec data is derived from GeoBase NHN. If something is identified as a coastal water body in NHN product, it will be tagged natural=coastline in Canvec.osm. If not, it will tagged as natural=water. No fixes need. Cheers, Daniel -- *From:* Adam Dunn [mailto:dunna...@gmail.com] *Sent:* 30 juin 2010 14:47 *To:* Bégin, Daniel *Cc:* Talk-CA OpenStreetMap *Subject:* Re: [Talk-ca] Canvec.osm Product - Last Call !!! @Daniel: Not fixing the triple space thing that goes along with cardinal directions? @All: Reefs are currently being made with a duplicate way marked as natural=water. Is this necessary? I'm not experienced with tagging maritime objects. A while ago, Sam asked about having natural=water changed to natural=coastline for coastal waters, but I see it isn't fixed yet. When Yan did the NHN nl_flow conversion, he decided to put the name data into name:1, his reasoning being that NHN sl_water and NHN waterbody also have the name tags, and those would eventually be imported, and the name tags could come from those (and just double checked against the nl_flow name:1). Now there's talk of not doing NHN since it's all included in CanVec. The current samples from Daniel don't have names on the hydrological features (at least the Vancouver 092G06 area), however. Is more NHN data going to be included in future CanVec data, or should names be copied over from nl_flow? Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Seeking help with BC errors
Sam, you didn't really answer the question. In what way is OSM not complete? As an example, I downloaded the three ways that start at http://www.openstreetmap.org/?mlat=49.07513mlon=-116.14094zoom=17 (the last of the error messages) and all of them have correct connections at both ends of the ways. They don't appear to be out of alignment. It would be easier to fix them by Christmas if we actually knew what was wrong, and how to fix it. Adam On Wed, Jun 16, 2010 at 12:51 AM, Sam Vekemans acrosscanadatra...@gmail.com wrote: Hi Yup, i got those same errors when compiling the Windows Garmin MapSource installer. http://wiki.openstreetmap.org/wiki/Canada:British_Columbia#Downloads Its because OSM is not yet complete. I guess that by christmas, alot of the errors will be picked up. There are a few places where the roads dont align, and so, using the CanVec data, it will get fixed manually. I know that in Nanaimo, there are a few errors. So i do intend on fixing it :) But the majority of the province routes fine with this conversion. I have now uploaded the resulting IMG files for the Province of BC http://wiki.openstreetmap.org/wiki/Canada:British_Columbia#Downloads As more people can use the IMG files, than just the mapsource installer :) When i convert the rest of the countries province .osm files (from Cloudmade extract) I'll include the IMG tiles that i created. For Contour maps, Garmin MapSource has a hard time mixing Contours the routable map. But it's fine to add the contour only tiles to it. I am currently making a GroundTruth Planet Contour IMG file set at 10m, so it will be able to download. Hopefully the BC province mapset will be able in the next month or so :) Cheers, Sam Vekemans Across Canada Trails Victoria, BC On Tue, Jun 15, 2010 at 11:25 AM, angus angus_came...@shaw.ca wrote: I'm a relative newby to osm and this is my first query. Mkgmap returns the following when I attempt to compile BC using mkgmap. SEVERE (Polyline): 0001.osm.gz: Problem writing line (class uk.me.parabola.imgfmt.app.trergn.Polyline) of type 0x10e1e containing 2 points and starting at http://www.openstreetmap.org/?mlat=59.4mlon=-137.01642zoom=17 SEVERE (Polyline): 0001.osm.gz: Subdivision shift is 2 and its centre is at http://www.openstreetmap.org/?mlat=58.97461mlon=-133.32742zoom=17 SEVERE (Polyline): 0001.osm.gz: deltaLong = -42980 SEVERE (Polyline): 0001.osm.gz: Problem writing line (class uk.me.parabola.imgfmt.app.trergn.Polyline) of type 0x10e1e containing 2 points and starting at http://www.openstreetmap.org/?mlat=59.99739mlon=-139.04795zoom=17 SEVERE (Polyline): 0001.osm.gz: Subdivision shift is 0 and its centre is at http://www.openstreetmap.org/?mlat=59.76563mlon=-138.03216zoom=17 SEVERE (Polyline): 0001.osm.gz: deltaLong = -47339 SEVERE (Polyline): 0001.osm.gz: Problem writing line (class uk.me.parabola.imgfmt.app.trergn.Polyline) of type 0x10e1e containing 2 points and starting at http://www.openstreetmap.org/?mlat=59.6mlon=-137.01640zoom=17 SEVERE (Polyline): 0001.osm.gz: Subdivision shift is 0 and its centre is at http://www.openstreetmap.org/?mlat=59.76563mlon=-133.32742zoom=17 SEVERE (Polyline): 0001.osm.gz: deltaLong = -171919 SEVERE (Polyline): 0004.osm.gz: Problem writing line (class uk.me.parabola.imgfmt.app.trergn.Polyline) of type 0x10e1f containing 2 points and starting at http://www.openstreetmap.org/?mlat=49.00053mlon=-114.72617zoom=17 SEVERE (Polyline): 0004.osm.gz: Subdivision shift is 0 and its centre is at http://www.openstreetmap.org/?mlat=49.15504mlon=-115.43354zoom=17 SEVERE (Polyline): 0004.osm.gz: deltaLong = 32966 SEVERE (Polyline): 0004.osm.gz: Problem writing line (class uk.me.parabola.imgfmt.app.trergn.Polyline) of type 0x28 containing 86 points and starting at http://www.openstreetmap.org/?mlat=49.07513mlon=-116.14094zoom=17 SEVERE (Polyline): 0004.osm.gz: Subdivision shift is 0 and its centre is at http://www.openstreetmap.org/?mlat=49.15504mlon=-115.43354zoom=17 SEVERE (Polyline): 0004.osm.gz: deltaLong = -32967 It appears to be map errors but what do these messages mean and how do we fix them? BTW I'm using Cloudmade british_columbia.osm.bz2 (Jun 08), mkgmap r1652, splitter r116 and the most current openmtbmap_style. Alberta compiles cleanly. Thanks, Angus ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec.osm Product almost...
Opened up 092G06.
highway=unclassified is misspelled. The 092G06 data has highway=unclasified
(with one 's').
footway bridges appear to be duplicated on top of the non-bridge footway
that they are a part of. In other words, a [highway=footway] will continue
the entire length of the path (including the bridge), and there is a second
way [highway=footway;bridge=yes] where only the bridge is.
cardinal direction modifiers have 3 spaces after them (eg. West 8th
Avenue). I'm not sure what the standard is for OSM, since the wiki doesn't
seem to talk about it.
railway/road intersections don't have a common node. There is also a very
long rail tunnel that runs from beside the Ironworkers Memorial Bridge down
to near the intersection of Trans-Canada Highway and Willingdon Avenue, but
this tunnel appears to be missing from Canvec.
(as a side note: Canvec has the bridge for Trans-Canada going over Burrard
Inlet called Hwy 1;Second Narrows Bridge;Trans-Canada Highway;TransCanada
Highway {note the Second Narrows Bridge part}. It should actually be called
Ironworkers Memorial Second Narrows Crossing and the rail bridge beside it
is Second Narrows Bridge. See
http://en.wikipedia.org/wiki/Ironworkers_Memorial_Second_Narrows_Crossing)
Other data that I see in error is the standard old source problems
(buildings that have since been constructed/demolished, especially in the
rapid construction that happens at Univ. BC), streams/rivers not having
names (but that was expected).
It's nice to see that highway=*_link is being used. It was a pain trying to
figure those out with NRN.
Adam
On Thu, Jun 17, 2010 at 11:57 AM, Richard Weait rich...@weait.com wrote:
On Thu, Jun 17, 2010 at 1:00 PM, Bégin, Daniel
daniel.be...@rncan-nrcan.gc.ca wrote:
Bonjour!
Before the Canvec.osm production starts, I have produced complete NTS
datasets for samples previously offered - actually I have expanded the
samples to cover the entire NTS tile and add 092G06.
Each NTS dataset have been tiled using a quadtree algorithm - a nice
example
of the result is 092G06 ! The .osm subtiles are zipped all together. We
are still using WinZip but we might eventually move to gzip or bzip.
Have a look!
And, by the way, can you make sure everything is still OK with the data?
Wonderful news, Daniel! And congratulations.
I'll take a look but am slightly {natural=wetland; wetland=swamp}ed,
right now. Is it helpful if I have a look next week?
___
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] BCGNIS Rescind Date
This is rather off-topic, but this list has many knowledgeable people... Does anybody know how to find the date of rescinds/adopts from BCGNIS[1]? My dad is interested in fishing at a lake, and I noticed some naming discrepancies between sources. It appears that one name has been rescinded, with another name adopted. I would like to know when this happened (if possible). Old name: Peterhope Lake [2] New name: Peter Hope Lake [3] I don't think BCGNIS can be used in OSM, but it's fun to look things up on there every now and then. [1] http://archive.ilmb.gov.bc.ca/bcnames/index.html [2] http://archive.ilmb.gov.bc.ca/bcgn-bin/bcg10?name=48268 [3] http://archive.ilmb.gov.bc.ca/bcgn-bin/bcg10?name=34742 Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec.osm samples
If you generate new samples, I can test with the latest josm if you want. Looking at the 082H04 sample file (I modified all the offending tags that were preventing loading so that they had k=adam v=crasher so I could identify them), there doesn't seem to be a pattern to which objects get the null tags. Some are water related, some are roads, some have names, some don't, etc. Don't know where it would be coming from. As for the data itself, most seems quite good. Comparing the sample file to Toporama WMS, I noticed that waterfalls are missing from the sample osm file. Are they available in the Canvec data? It looks like roads that are dead-ends have turning circles by default, with a note to remove if it doesn't actually exist? Interesting choice of how to set things up. Adam On Wed, May 5, 2010 at 1:44 PM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Thanks Adam, obviously it seems there being bad tags in the samples. I'll replace the samples. About the conversion script, it should be OK because I have succesfully created/uploaded many tiles since then using JOSM. http://www.openstreetmap.org/?lat=45.371lon=-72.271zoom=11layers=B000FTF Daniel -- *From:* talk-ca-boun...@openstreetmap.org [mailto: talk-ca-boun...@openstreetmap.org] *On Behalf Of *Adam Dunn *Sent:* 5 mai 2010 16:29 *To:* Talk-CA OpenStreetMap *Subject:* Re: [Talk-ca] Canvec.osm samples Got a response on the error here [http://josm.openstreetmap.de/ticket/4971]. Turns out there is a malformed tag, that doesn't have key or value in it (a null tag) Here's line 16220 (the offending tag): tag/ To compare, here's line 16221 (a properly formed tag): tag k=waterway v=stream/ The josm developer has put in a better error message regarding what the problem is, but josm still will not load the file. So does this come down to there being a bad tag in the original Canvec data, or does the conversion script need some modifying? Adam On Fri, Apr 30, 2010 at 7:02 PM, Sam Vekemans acrosscanadatra...@gmail.com wrote: Ideas: -mention this on the irc #osm-dev chat. As a JOSM develepor might be able to help further -zipping : try .bz2 compression, instead of regular zip, maybe it does something different to the .osm data? -at that same time (with that new josm revision, WMS didnt work for some people) -josm doesnt automatically update all the plugins, when you get a new version of the main exe file, -Osmosis is the tool to combine .osm files, i havent yet been sucessful at merging them (on the command line) -each node would need a new ID, when merging files, maybe there is a max # of features? -Also, i'll check with user:MikeyCarter as he has gone ahead and converted canvec for the Barrie Ontario area, using a customized method. Cheers, Sam On 4/30/10, Adam Dunn dunna...@gmail.com wrote: If I understand correctly, older versions of JOSM would open the file correctly, but new versions will have problems? I'm not the only one here? I got the josm svn from this morning (rev 3213), opened it up in Eclipse, did some debugging, and see that for 082H04_Sample.osm, the error occurs on or near line 16217. It may not be Josm that is at fault, since it seems to handle most other osm files quite well. Please see http://josm.openstreetmap.de/ticket/4971 for the bug that I just filed. Adam On Fri, Apr 30, 2010 at 10:04 AM, Daniel Bégin jfd...@hotmail.com wrote: Hi Adam, I looked at Canvec.osm sample files about one month ago and did not get any problems with an earlier version of JOSM (before 3196). I've just tried using JOSM 3196 and I got the same error message. I'm running on Windows. No good explanation to give :-( Daniel -Original Message- From: Adam Dunn [mailto:dunna...@gmail.com] Sent: April 29, 2010 12:46 To: Sam Vekemans Cc: Daniel Bégin; Talk-CA OpenStreetMap Subject: Re: [Talk-ca] Canvec.osm samples I'm getting NullPointerException in JOSM for all three files, and making sure the line feeds are unix (since I'm on linux) doesn't help. This is with JOSM 3208. Open file: /home/adam/Desktop/021L14_sample.osm (2796211 bytes) org.openstreetmap.josm.io.IllegalDataException: java.lang.NullPointerException at org.openstreetmap.josm.io.OsmReader.parseDataSet(OsmReader.java:586) at org.openstreetmap.josm.io.OsmImporter.importData(OsmImporter.java:42) at org.openstreetmap.josm.io.OsmImporter.importData(OsmImporter.java:34) at org.openstreetmap.josm.io.FileImporter.importDataHandleExceptions(FileImport er.java:57) at org.openstreetmap.josm.actions.OpenFileAction$OpenFileTask.importData(OpenFi leAction.java:263) at org.openstreetmap.josm.actions.OpenFileAction$OpenFileTask.realRun(OpenFileA ction.java:242) at org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRunnable.j ava:83
Re: [Talk-ca] Canvec.osm samples
I'm getting NullPointerException in JOSM for all three files, and making sure the line feeds are unix (since I'm on linux) doesn't help. This is with JOSM 3208. Open file: /home/adam/Desktop/021L14_sample.osm (2796211 bytes) org.openstreetmap.josm.io.IllegalDataException: java.lang.NullPointerException at org.openstreetmap.josm.io.OsmReader.parseDataSet(OsmReader.java:586) at org.openstreetmap.josm.io.OsmImporter.importData(OsmImporter.java:42) at org.openstreetmap.josm.io.OsmImporter.importData(OsmImporter.java:34) at org.openstreetmap.josm.io.FileImporter.importDataHandleExceptions(FileImporter.java:57) at org.openstreetmap.josm.actions.OpenFileAction$OpenFileTask.importData(OpenFileAction.java:263) at org.openstreetmap.josm.actions.OpenFileAction$OpenFileTask.realRun(OpenFileAction.java:242) at org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRunnable.java:83) at org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.java:129) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) .. more stack that goes into java api libraries Caused by: java.lang.NullPointerException at org.openstreetmap.josm.data.osm.Storage$1.getHashCode(Storage.java:317) at org.openstreetmap.josm.data.osm.Storage.getBucket(Storage.java:246) at org.openstreetmap.josm.data.osm.Storage.get(Storage.java:196) at org.openstreetmap.josm.io.OsmReader$Parser.intern(OsmReader.java:126) at org.openstreetmap.josm.io.OsmReader$Parser.startElement(OsmReader.java:273) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501) goes further into xerces I don't know if the stacktrace helps, or if anyone else is having problems with these files. Other .osm files open up fine on my system. I could submit this as a bug report to Josm with the sample file, but wanted to check if anyone else is having problems as well. Adam On Thu, Apr 1, 2010 at 11:05 PM, Sam Vekemans acrosscanadatra...@gmail.comwrote: Thanks, But its oodles of people who help with the process. Speaking of which, i'll have the complete Ibycus 3.0 Garmin MapSource IMG files available for download as single (grouped) .zip files available soon. It will still be at least a year before we get our map to that level. Sam snip For those who are interesting to have a look at sample datasets, you can download them from OSM wiki http://wiki.openstreetmap.org/wiki/CanVec#Sample_Datasets NRCan ftp://ftp2.cits.rncan.gc.ca/osm/pub Have fun (I hope!-) Daniel ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GeoBase Aboriginal lands provincial OSM zip files now available
Taking a look at BC 0006.osm, some questions (I've also imported/uploaded the following examples so others can see): Looking at Skowkale 10 [1] and Upper Sumas 6 [2], both of these reserves have multiple exclaves. They're essentially one large reserve (each) that has been carved up into pieces because public roads run through them. I don't know much about aboriginal land treaties (perhaps each of those pieces really *should* be separate), but perhaps they should be tagged using the example of Use Case: More than one (disjunct) outer ring from [3]. Enclaves (inner/outer polygons) seem to be handled correctly, but exclaves (outer/outer) are not. Is it possible to do this with the script? Looks like there's some encoding errors for the Pekw'xe:yles reserve [4]. The name:fr tag has value with à in it. Should this be an e with accent aigu (accute accent) é, or something else? Any fix for the script for that? [1] http://www.openstreetmap.org/browse/way/55602814 http://www.openstreetmap.org/browse/way/55602810 http://www.openstreetmap.org/browse/way/55602805 http://www.openstreetmap.org/browse/way/55602799 [2] http://www.openstreetmap.org/browse/way/55602817 http://www.openstreetmap.org/browse/way/55602813 http://www.openstreetmap.org/browse/way/55602811 http://www.openstreetmap.org/browse/way/55602809 http://www.openstreetmap.org/browse/way/55602803 http://www.openstreetmap.org/browse/way/55602802 http://www.openstreetmap.org/browse/way/55602801 [3] http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Advanced_multipolygons [4] http://www.openstreetmap.org/browse/way/55602816 Adam ** On Fri, Apr 16, 2010 at 12:31 AM, Sam Vekemans acrosscanadatra...@gmail.com wrote: Hi all, I now have the rest of the province's aboriginal lands .osm files available. http://wiki.openstreetmap.org/wiki/Geobase/Canadian_Aboriginal_Lands#Rules Nunavut is probably the largest file with 15 .osm files in the set, but i dont think there is much interference, so it shouldn't be to hard to upload. Also, (as i mentioned before) some of the tags might need to be changed (if you can think of something better). It's easy to change the tags, in the for each of the .osm files (just select all of the polygons change the tags :) Also, looking at the geobase website, these files do get updated a bit more frequently. But there is a DIFF file that is available, so the script can be run on that file, after all the lands have been uploaded. The recommended use, is to just drop in the data for your local area that your working on.. ... since others might want to drop in data for their own area also. (im contacting local area mappers as i go along, so im trying to make sure i dont interfere with what they are mapping) Cheers, Sam Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans OpenStreetMap IRC: http://irc.openstreetmap.org @Acrosscanadatrails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] On renderers
My personal favourite example that I tell people is http://wiki.openstreetmap.org/wiki/HaptoRender where OSM data is used to print a haptic map for blind users. I think it demonstrates very well the difference between access to final rendered images vs. access to the raw data. Adam On Thu, Apr 8, 2010 at 10:47 AM, Richard Weait rich...@weait.com wrote: On Thu, Apr 8, 2010 at 12:58 PM, Yves Moisan yves.moi...@boreal-is.com wrote: What I'd like to know in fact is how organizations that wish to control how OSM data is rendered have for options. And examples if possible. Any pointers appreciated. Dear Yves, There are a bunch of OSM datasets presented on other sites, here: http://wiki.openstreetmap.org/wiki/List_of_OSM_based_Services ___ 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] Provincial Parks Sample
For those who are still wondering, Manning Park should actually be showing up in http://www.openstreetmap.org/?lat=49.0866lon=-120.7647zoom=12layers=B000FTF The permalink I had in my last post shouldn't have any national or provincial parks in it. Adam On Mon, Apr 5, 2010 at 8:24 PM, Sam Vekemans acrosscanadatra...@gmail.comwrote: Well, because were (as you did) just loading local area parks (that each of us knows of directly). We can change the tagging as we like. Feel free to change the page to whatever tags are better. (and i can re-convert the dataset again with changes) http://wiki.openstreetmap.org/wiki/Geobase/NRCan_Protected_Areas In order to make a WMS layer service. All that is needed is to change the format of the shp files with ogr2ogr make these files available. Then James knows now to make a WMS layer with map.server, where it could be hosted onto the wms.openstreetmap.de site, so then people can just trace from it. If we make it 'transparent' this WMS can be used over top of the Toporama WMS. ... while other features are being added (from the soon to be available canvec data) as .1x.1 degree tiles. For now, i can see that they show up (i corrected your permalink :-) http://www.openstreetmap.org/?lat=49.0345lon=-121.9195zoom=12layers=B000FTF Re: Manning Park. ya, i have no idea about the source of the data. My plan is to contact Parks Canada (as soon as all the parks get loaded in) and share the .dbf file database add in a column for the 'OSM ID' ( http://www.openstreetmap.org/browse/way/54452481) (creating 1 chart per feature type) would make for a good spreadsheet). I would ask them how old the source data is, and ask to get an update from the BC government to update that file. Also, note that the BC Provincial Parks database is under the license that is not compatible with OSM, however, once all of this available data is loaded in the province (and all the Canvec data is loaded). We might see some interest from GeoBC. ... However, i have already contacted GeoBC (and have bugged them enough). It would be better to wait until all of the Vancouver Data is available (city parks), or even better.. other regional area data (Nanaimo CVRD). ... and approach other towns across the province, .. so once more cities regions notice that OSM is populated with all this data. The province has the dataset that will be able to 'fill in the gaps'. Also, after all of the park boundaries are loaded in Ontario (the shp files are available) i can convert it just the same. ... there will be some provincial competition. .. where no province likes to be last... :-) http://wiki.openstreetmap.org/wiki/Land_Information_Ontario#Provincial_Park_Regulated (there is only 337 parks, so it could all be put in 1 or 2 .osm files) but note that some of this could be in CanVec. ... which is why im not converting it yet... anyone want it? Cheers, Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] call for help, importing roads
Well, I'm a complete bozo! The whole open source philosophy is to always be running the latest (stable) version of your software. After all, why not, considering it's open source and all. That's precisely what I *wasn't* doing with OpenJUMP. So it turns out that the latest version of openjump can successfully read all the property tags that I need it to. My sincere apologies for cluttering up this mailing list. I also realize that much of this Albanian mapping stuff belongs on a mailing list set up for Albania, and not on the Canadian list, but this whole process, and much of the software was made for/by Canada. (Besides, there's no talk-al set up yet). Now I have to try and convert geobase2osm.py to work for the Albanian data. You can be sure I'll be back with more inane questions! Adam On Fri, Mar 19, 2010 at 10:25 AM, Adam Dunn dunna...@gmail.com wrote: I opened up my shapefile in QGIS after it had passed through PostGIS, and it turns out that it does have all the tags. So it appears there is nothing technically wrong with my SQL functions. It is OpenJUMP that's not reading the tags properly. I'm thinking maybe OpenJUMP isn't reading the smallint or integer types properly. Does anyone here know more about programming/opening ESRI files in OpenJUMP? Do I have to cast int4 and int2 to some other type in order for OpenJUMP to read them? Anybody know how I would do this without getting casting errors? Adam On Fri, Mar 19, 2010 at 12:03 AM, jamesmikedup...@googlemail.com jamesmikedup...@googlemail.com wrote: On Fri, Mar 19, 2010 at 2:46 AM, Adam Dunn dunna...@gmail.com wrote: The reason why it is functionally useless at this point is because the id/et_id is not being transferred through the process correctly. Perhaps an explanation of the process is in order: The SQL stage is basically for reprojection and selecting a bounding box. If you already had both the government and the OSM roads converted into a Shapefile format, and they both had the same projection, and you were willing to work on the entire country at the same time, then you wouldn't even need SQL. Here are here: http://xhema.flossk.org:8080/mapdata/03/MapAction/tpginc/LL_Roads_OSM.shp Here are the osm data (from cloudmade) http://xhema.flossk.org:8080/mapdata/03/MapAction/tpginc/LL_Roads_OSM.shp You generally don't want to do the whole country at a time (trust me, it's not something you do in OpenJUMP), and you generally need to do some reprojection/format conversion, so we need SQL. What gets spit out of the SQL step is two files, OSM.shp and GOV.shp, and they each have geometry (where the roads are) and id numbers (internal numbers used by each). These two files get loaded into OpenJUMP Roadmatcher, where you find the matches, find the standalones, then output the result. This result file has a list of the id numbers for the roads that are standalone in the government database. Then (for Canada) geobase2osm.py will use the Roadmatcher result file as a mask to see which roads to copy from the government gml file over to an osm file. It does this by looking at the standalone id numbers, and then copying only the roads in the gml that have those ids. I kind of think of it like a transistor. A transistor takes some voltage input and connects it to the output, depending on whether the gate voltage is on or not. The input/output voltages can be large or small, but the gate voltage only needs to be tiny. The gate voltage itself doesn't get passed through to the output. Something like this: gate | input -- transistor -- output Equivalently, geobase2osm.py connects the Government.gml geometry to the Standalone.osm geometry, but only if the Standalone Result ID is on. The Result ID itself doesn't get passed through, it's only used as a gate mask. So we get something like: Result ID# | GovGeometry.gml -- geobase2osm.py -- StandaloneGeometry.osm Since I haven't yet gotten the ID numbers to pass through, we can't use them as a mask for geobase2osm.py, rendering it useless. We can't generate osm files that have no duplicates with what's already on OSM. I see, so the ids are the problem. I can assign them new ids. We can rename the column? Let's say you want to do things more manually. You could run the match process in Roadmatcher, then visually look and see what roads need to be copied over, then go over to JOSM and manually pick out those roads. This is silly, as you could do this faster by skipping Roadmatcher, and just matching by eye within JOSM. I see, well that is what i hoped roadmatcher would help with. Even if I do get ID numbers to transfer through, I don't know how portable geobase2osm.py will be to the Albanian data. What tools have other imports used? Maybe there's something else that uses a slightly different method? OK, well we need
Re: [Talk-ca] Provincial Parks Sample
I've opened the seven files that are in the zip file posted on the wiki. Great that I can import Cultus Lake Park near my house (I didn't know that Cultus Lake Park also included part of Vedder Mountain on the other side of the lake!) along with some others in the area. I don't see Manning Provincial Park though [1]. It should be somewhere around [2]. Many of these are not National Parks (federal), so the tagging needs to be rethought. I see that national_park is well accepted [3] but is very misleading in its wording. Kevin's idea of using admin_level or something similar might work. [1] http://en.wikipedia.org/wiki/E._C._Manning_Provincial_Park [2] http://www.openstreetmap.org/?lat=49.1245lon=-121.9701zoom=13 [3] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dnational_park Adam On Mon, Apr 5, 2010 at 1:03 AM, Sam Vekemans acrosscanadatra...@gmail.comwrote: Hi all, I have loaded the 7 .osm files (in a zip file) and some details on the wiki. http://wiki.openstreetmap.org/wiki/Geobase/NRCan_Protected_Areas#Data I'm mainly working on those parks that cross along the (Across Canada Trails) route network. What i'll be doing is contacting the local are mappers as i go along. As now i'll be much easier for people to be mapping more details. I don't think that this file is available on the Ibycus Topo, so it will be great to see a more complete map when it's loaded in :) ... slowly but surley... there is no rush. :) Anyway, I loaded the Most northern National Park in Canada http://www.openstreetmap.org/?minlon=-79.0394413minlat=81.1524017maxlon=-61.0035376maxlat=83.3456729box=yes this area of the world doesnt get rendered as fast but perhaps when the CanVec data is available, this are will get filled in. ... im sure it'll get some attention. I also loaded Fundy National Park (New Brunswick) http://www.openstreetmap.org/?lat=45.616lon=-64.939zoom=11layers=B000FTF And Pukaskwa national Park (south of Marathon, Ontario) before Wawa, you can see on the coast the Voyageur trail. http://www.openstreetmap.org/?lat=48.34lon=-85.841zoom=11layers=B000FTF And also Cowichan River Provincial Park. http://www.openstreetmap.org/?lat=48.7597lon=-123.8091zoom=14layers=B000FTFT Please check the tags. .. im still not sure about the natural=forest; landuse=wood. If you see at the Ucluelet are a different shade of green. and also look at how the Olympic National Forest in the US got mapped. http://www.openstreetmap.org/?lat=48.071lon=-123.74zoom=10layers=B000FTF ... this is exactly the reason why we map the parks one at a time use care where these things can get verified :) Cheers, Sam On Sun, Apr 4, 2010 at 10:10 PM, Sam Vekemans acrosscanadatra...@gmail.com wrote: hi, On Sun, Apr 4, 2010 at 9:50 PM, Kevin Smith haiet...@draconic.ca wrote: On 04/04/2010 8:38 PM, Sam Vekemans wrote: Hi Kevin, As we were chatting earlier.. (cc:talk-ca list) I just want to show you a sample. http://www.openstreetmap.org/?minlon=-123.8369687minlat=48.7525877maxlon=-123.7812077maxlat=48.7667345box=yes http://www.openstreetmap.org/?minlon=-123.8369687minlat=48.7525877maxlon=-123.7812077maxlat=48.7667345box=yes http://www.openstreetmap.org/browse/changeset/4329006 It appears that the National Protected area's file DOES contain provincial park boundaries. I've converted created 11 .osm files. and i think it's best to just copy in 1 at a time, as there is no rush. This one is interesting because the Cowichan Vally Regional District ALSO has the parks file (but i think it's just for regional parks) It has regional, municipal, and provincial parks, though it only has a few of the parks in the other municipalities and it only gives them names, It doesn't have a field to indicate which parks are at which level. And it doesn't include the portion of PRNP that overlaps the CVRD. And actually I was doing the integration for it while you uploaded that test. I'd already started uploading it when checked the map and saw the addition. Ya, the data appears to have mainly the Provincial National Parks. Anyway... i was thinking creating a new tag boundary=provincial_park kind of like how we have the proposal for boundary=aborigional_lands. It bothers me a little as it's something of a Canadian specific term. as 'state_park' would be the USA equivalent. I'd kind of prefer to see national_park replaced with a more generic term, and then use operator or admin_level. As it is I made the provincial parks in the CVRD data national_park with operator=BC Parks. ok, what i did was list it as 'boundary=national_park' and didn't include an operator tag, As i think it would be on a park by park basis, as to who exactly runs it. The rest are either leisure=park or leisure=nature_reserve (for Nature Parks) with the the municipality they are in as the operator. I've also changed the is_in=* tag to
Re: [Talk-ca] Vancouver campus data
Many bike racks are also under cover (Buchanan and Dempster come to mind), so good luck spotting them on Yahoo. I can also attest to the fact that Yahoo is not very well orthorectified for UBC, especially in the theology department and Gage towers. I think Fairview was okay though... I don't see how using PlantOps maps to plan a day's outing could be considered derivative work though. If Gregory goes to the location on foot and marks a gps point for the bollards on Main Mall near Forestry, then it's his own work. Looking at PlantOps maps to see that there is something interesting in the area shouldn't really count as an original source. Adam P.S. Sorry about the duplicate email Russell. On Mon, Mar 29, 2010 at 7:32 PM, Russell skiinf...@gmail.com wrote: Unfortunately the yahoo imagery in Vancouver isn't good enough to see bike racks anyways :( The yahoo imagery at UBC is distorted also (wavy) on part of the campus. Regardless, if we want to make a demo area at UBC with very high detail mapping, then I would like to help as I am a student out there as well. The orienteering club has done a great job of mapping the campus over the last few years (this is the map from a while ago, now the entire campus is mapped: http://www.orienteeringbc.ca/gvoc/maps/files/UBC.gif) Unfortunately they do trace imagery so it isn't suitable for importing I think. Russell On Mon, Mar 29, 2010 at 7:08 PM, Corey Burger corey.bur...@gmail.com wrote: On Mon, Mar 29, 2010 at 7:00 PM, James Ewen ve6...@gmail.com wrote: On Mon, Mar 29, 2010 at 11:37 AM, Corey Burger corey.bur...@gmail.com wrote: Bicycle racks would certainly be a welcome addition. I look at the number around UVic and shudder. However, who holds copyright on the data? They need to sign off on importing it into OSM if it isn't licensed under fairly liberal terms. If you don't know then it is likely all rights reserved. Plant Ops may not have the ability to do this. Likely you are going to need to clear it through Legal, which can add time and headaches. So this brings up a question for me... If Gregory were to wander around the campus, and mark the bike racks on his GPS, and upload that to OSM, it would be completely kosher. What if Gregory were to plan his outing to collect information by referencing the copyright information in the campus map. Would that make his information a derivative work? I would think not. If you are using the map to navigate, I think there is a pretty strong argument for deriviativeness. Better to simply wander around and find them in a very systematic way. What if Gregory were to reference the location of the bike racks on the campus map, and then use the Yahoo Map images to locate the bike racks, and mark them on OSM. Would that now be a derivative work? This I don't know... Yes, this definitely would be, because there would be no actual ground truthing. Corey ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca -- Russell ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec tile splitter 999x33 a to y 5x5 and/or put on a dedicated API?
It is possible to use Osmosis in this way. From [1]: osmosis --read-xml file=Canvec092C01.osm --bounding-box top=48.05 bottom=48 left=-124.1 right=-124 --write-xml file=Canvec092C01A.osm For my own work with geobase2osm.py I wrote a small bash shell script that will grab coordinates from Frank's site [2] and do most of the work for me, outputting an entire area of Geobase, as smaller files. Maybe something similar could be put in the toolchain for the Canvec process? [1]: http://wiki.openstreetmap.org/wiki/Osmosis#Extracting_bounding_boxes [2]: http://www.steggink.org/geo/nts_area/092C01A Adam On Sun, Mar 28, 2010 at 9:26 AM, Sam Vekemans acrosscanadatra...@gmail.comwrote: Hi all, We are getting more progress on Vancouver Island, thanks to (haitelk) who has just added in more wooded area. And the new CVRD data is in the planning, discussing sorting data phase. :-) What we still need todo is make a tool that will automatically slice the NTS tiles (canvec .osm files) into 25 pieces, so then a local area mapper can easly take 1 square at a time work with it, choosing the data that they need to add in. I think that OSmosis has this ability, has anyone varified this? This will be of great help to everyone, as we are also using the Toporama WMS layer to be tracing using it for reference. Otherwise, if we dont have the 1/25th tile area, its harder to ensure that no 'bulk_implopping' happens where the user gets lazy and doesnt bother to check the area 1st. Since the 1/25th tile size is a standard JOSM working space, we would (just about all of the time), have only 1 mapper is working at a time. (even in the big cities, this size is managable). Oh, this whole CanVec dataset would be great to host on a different API, (like i talked about on my last message for OpenImportsMap does anyone know if perhaps the devAPI would be a good place for it? Or should we make a new one that is dedicated to wholesale imports? Thanks, Sam -- Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans OpenStreetMap IRC: http://irc.openstreetmap.org @Acrosscanadatrails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] FW: Welcome to MyTTC!
Cool, looking at [http://bcer.trams.bc.ca/pics/chilllq.JPG] the railyard was converted into the library/Salish Park/Holiday Inn (now Coast Hotels). Looks like a good use of the railway=abandoned tag? [ http://wiki.openstreetmap.org/wiki/Railway] Adam On Sun, Mar 28, 2010 at 2:48 PM, Sam Vekemans acrosscanadatra...@gmail.comwrote: Hi, Nice ideas :) I wish Victoria, BC would have not dug up the old street-car line and paved it into a road. It would be great to see a rail line that isn't just a tourist train going 2 times a day. ... 1 time per direction. Sorry i cant be of much help right now, directly to you, but hopefully others who are more local would help. :) (For the talk-ca@ discussion list) Hows 'railway=proposed'? As i dont think there are conflicting plans, dont see a problem with it being listed, and not physically connected. Another option is to draw it in as a GPS track (using bikemap.net or Garmin MapSource routable map) and just export that file for viewing overtop of Google earth with the openstreetmap KML layer turned on? (also, OpenOrienteringMap lets you draw on the map a route print it as a PDF. Cheers, Sam On Sun, Mar 28, 2010 at 2:28 PM, Bob Bowles rkbow...@telus.net wrote: Total novice, just found your site, HELP ! Bob Bowles, Langley City, BC -- *From:* Kevin Branigan [mailto:ke...@refactory.ca] *Sent:* Saturday, March 27, 2010 11:44 PM *To:* Bob Bowles *Subject:* Re: Welcome to MyTTC! Hey Bob, Are you just trying to compile the database? I would personally suggest OpenStreetMaps, that way other people could benefit from your hard work - they also have excellent tools to help you with entering the data. If you're a web developer you can use the tools on CloudMade to produce nice looking maps that incorporate your dataset. I sure would like to see that data for the Toronto area, but I'm not sure what I'd do with it to be honest. Thanks for using our site, Kevin On Wed, Mar 24, 2010 at 1:15 AM, Bob Bowles rkbow...@telus.net wrote: Hello Kieran Kevin I'm starting on a personal project to indentify all railbed, past and present, in the entire Fraser Valley. My first source is a map put out by CBRE called Greater Vancouver Industrial Commercial Areas I found all the old streetcar runs at this website - http://bcer.trams.bc.ca/maps.html This site has some good ideas for the South of Fraser region. http://www.box.net/shared/xhs5dlwcg0 There is also a book with all the old logging railbeds, part of a Valley Logging history book I found at a museum. How would you, digitally overlay these and perhaps add other lines as I find them? Further I see 2 pinch points in the Valley, Pattallo railbridge and where hwy 91 hwy 99 meet. Then I need to figure out who owns which sections of railbed. Ideally, I'd like to model an entire transit system. Too much time on my hands now that I'm not driving the streetcars http://www2.bombardier.com/vancouver/index.html -- *From:* my...@refactory.ca [mailto:my...@refactory.ca] *Sent:* Tuesday, March 23, 2010 7:34 PM *To:* rkbow...@telus.net *Subject:* Welcome to MyTTC! Thanks for signing up at MyTTC.ca http://myttc.ca ! You can *totally* respond to this e-mail, we're actual people. We hope you have as much fun using the site as we had building it. If you have any comments or suggestions, please drop us a line! Cheers, Kieran Kevin, refactory ___ 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] call for help, importing roads
So far, I've got the LL_Roads2 files imported in PostgreSQL, and I've written some functions to export them (modified from the NRN process on wiki), but it's not working properly. Using pgAdmin on Linux, I can see what data values there are, and their types: gid serial NOT NULL, id numeric, type character varying(50), category smallint, cat2 smallint, shape_leng numeric, name character varying(30), shape_le_1 numeric, et_id integer, the_geom geometry, When I export this to shp and open in OpenJUMP, I can see that some of the values aren't getting exported properly. gid doesn't seem to be exported at all. id, type, shape_leng, shape_le_1, and the_geom all seem to be fine. Unfortunately, category, cat2, and et_id are all coming up with the value 0, even though they had other values in the original dataset. Name I can't test, since it seems to be null in the original data. Here's the function I'm using: DROP TYPE albania_gov_data; CREATE TYPE albania_gov_data AS ( --Included all Albanian keys, since I don't know what they mean/which are important gid integer, the_geom geometry, id numeric, way_type text, category smallint, cat2 smallint, shape_leng numeric, way_name text, shape_le_1 numeric, et_id integer ); CREATE OR REPLACE FUNCTION select_albania_gov_roadtile(coordinates text) RETURNS SETOF albania_gov_data AS $$ SELECT gid,ST_Transform(the_geom,4326),id,type, --might need 4191 rather than 4326 category,cat2,shape_leng,name,shape_le_1,et_id FROM albania_roadseg WHERE ST_Intersects(ST_Transform(the_geom,4326), ST_GeomFromEWKT($1)) $$ LANGUAGE SQL; CREATE TYPE albania_osm_data AS ( way geometry, osm_id integer, name text ); CREATE OR REPLACE FUNCTION select_albania_osm_roadtile(coordinates text) RETURNS SETOF albania_osm_data AS $$ SELECT ST_Transform(way,4326),osm_id,substr(name,0,80) --might need 4191 rather than 4326 FROM planet_osm_line WHERE ST_Intersects(way,ST_GeomFromEWKT($1)) AND ((highway is not null) OR (railway is not null)) --Albania appears to have railways in gov_data $$ LANGUAGE SQL; Anybody got any ideas? On the data itself: What is the difference between all the files on the ftp? There is LL_Roads, LL_Roads2, LL_Roads_OSM, but a quick check in OpenJUMP, and they all look the same. For my test, I exported an area around Gjirokastra [ http://www.openstreetmap.org/index.html?minlat=40minlon=20maxlat=40.2maxlon=20.2box=yeslayers=B000FTF]. In this area, the id tag was only partially useful: In downtown Gjirokastra (the densely roaded area that is not currently visible on OSM, but is approx bounded by [http://www.openstreetmap.org/browse/way/30455602] and [ http://www.openstreetmap.org/browse/way/36777258]) the id tag seemed to be missing for roads. The id tag was only available in the outer (rural?) areas. Shape_leng was mostly 0.0, except for about 20 roads at the south end of Gjirokastra (out of 2479 roads), in which case it matched up with shape_le_1. This data also includes Footpath as a type, along with the other types I mentioned in my last email. A listing of all the different ways/types/categories in this data would be nice to have. The data is missing a gml file. This is necessary to run the geobase2osm.py step. You could probably use ogr2ogr to do it, but you'd need proper id or et_id, whichever would work better as a unique identifier (probably not id, since it's not available in urban areas!). I did get both the OSM data and the (I assume) government data into openjump roadmatcher, so it would be possible to roadmatch with what I have, but not very useful. Adam On Wed, Mar 17, 2010 at 2:47 PM, Adam Dunn dunna...@gmail.com wrote: Hi, I was kind of hoping someone more knowledgeable in GIS programming would've responded first for the following reasons: geobase2osm.py is an integral part of the whole roadmatching process for Canada, and it's a very Canadian-specific script (there are chunks of code that deal with naming of major trunks on a province-by-province basis using if-else programming). Also, I don't have much experience programming GIS stuff. For example, the Canadian way of doing this uses EPSG 3348 for projection [1]. I did some Google searching, and it looks like you would want to use EPSG 4191 for the Albania area (see [2]), but 2462 might also the one you want to use ([3], although it looks like you get weird projected bounds with it). I don't know why this reprojection is really even necessary. When you look at EPSG 3348 (the Canadian one), the projected bounds are really weird there as well, so maybe it has to be done just to match up with NRN. If the Albania dataset is already in Lat/Long and 4191 is in Lat/Long and OSM is in Lat/Long, maybe you don't need to reproject at all? Someone with more GIS knowledge should know. You'll also want a script to automatically convert
Re: [Talk-ca] call for help, importing roads
The reason why it is functionally useless at this point is because the id/et_id is not being transferred through the process correctly. Perhaps an explanation of the process is in order: The SQL stage is basically for reprojection and selecting a bounding box. If you already had both the government and the OSM roads converted into a Shapefile format, and they both had the same projection, and you were willing to work on the entire country at the same time, then you wouldn't even need SQL. You generally don't want to do the whole country at a time (trust me, it's not something you do in OpenJUMP), and you generally need to do some reprojection/format conversion, so we need SQL. What gets spit out of the SQL step is two files, OSM.shp and GOV.shp, and they each have geometry (where the roads are) and id numbers (internal numbers used by each). These two files get loaded into OpenJUMP Roadmatcher, where you find the matches, find the standalones, then output the result. This result file has a list of the id numbers for the roads that are standalone in the government database. Then (for Canada) geobase2osm.py will use the Roadmatcher result file as a mask to see which roads to copy from the government gml file over to an osm file. It does this by looking at the standalone id numbers, and then copying only the roads in the gml that have those ids. I kind of think of it like a transistor. A transistor takes some voltage input and connects it to the output, depending on whether the gate voltage is on or not. The input/output voltages can be large or small, but the gate voltage only needs to be tiny. The gate voltage itself doesn't get passed through to the output. Something like this: gate | input -- transistor -- output Equivalently, geobase2osm.py connects the Government.gml geometry to the Standalone.osm geometry, but only if the Standalone Result ID is on. The Result ID itself doesn't get passed through, it's only used as a gate mask. So we get something like: Result ID# | GovGeometry.gml -- geobase2osm.py -- StandaloneGeometry.osm Since I haven't yet gotten the ID numbers to pass through, we can't use them as a mask for geobase2osm.py, rendering it useless. We can't generate osm files that have no duplicates with what's already on OSM. Let's say you want to do things more manually. You could run the match process in Roadmatcher, then visually look and see what roads need to be copied over, then go over to JOSM and manually pick out those roads. This is silly, as you could do this faster by skipping Roadmatcher, and just matching by eye within JOSM. Even if I do get ID numbers to transfer through, I don't know how portable geobase2osm.py will be to the Albanian data. What tools have other imports used? Maybe there's something else that uses a slightly different method? Adam On Thu, Mar 18, 2010 at 1:38 PM, jamesmikedup...@googlemail.com jamesmikedup...@googlemail.com wrote: The roads shp files are all the same,, that is true. On Thu, Mar 18, 2010 at 9:19 PM, Adam Dunn dunna...@gmail.com wrote: So far, I've got the LL_Roads2 files imported in PostgreSQL, and I've written some functions to export them (modified from the NRN process on wiki), but it's not working properly. Using pgAdmin on Linux, I can see what data values there are, and their types: gid serial NOT NULL, id numeric, type character varying(50), category smallint, cat2 smallint, shape_leng numeric, name character varying(30), shape_le_1 numeric, et_id integer, the_geom geometry, When I export this to shp and open in OpenJUMP, I can see that some of the values aren't getting exported properly. gid doesn't seem to be exported at all. id, type, shape_leng, shape_le_1, and the_geom all seem to be fine. Unfortunately, category, cat2, and et_id are all coming up with the value 0, even though they had other values in the original dataset. Name I can't test, since it seems to be null in the original data. Here's the function I'm using: DROP TYPE albania_gov_data; CREATE TYPE albania_gov_data AS ( --Included all Albanian keys, since I don't know what they mean/which are important gid integer, the_geom geometry, id numeric, way_type text, category smallint, cat2 smallint, shape_leng numeric, way_name text, shape_le_1 numeric, et_id integer ); CREATE OR REPLACE FUNCTION select_albania_gov_roadtile(coordinates text) RETURNS SETOF albania_gov_data AS $$ SELECT gid,ST_Transform(the_geom,4326),id,type, --might need 4191 rather than 4326 category,cat2,shape_leng,name,shape_le_1,et_id FROM albania_roadseg WHERE ST_Intersects(ST_Transform(the_geom,4326), ST_GeomFromEWKT($1)) $$ LANGUAGE SQL; CREATE TYPE albania_osm_data AS ( way geometry, osm_id integer
Re: [Talk-ca] call for help, importing roads
Hi, I was kind of hoping someone more knowledgeable in GIS programming would've responded first for the following reasons: geobase2osm.py is an integral part of the whole roadmatching process for Canada, and it's a very Canadian-specific script (there are chunks of code that deal with naming of major trunks on a province-by-province basis using if-else programming). Also, I don't have much experience programming GIS stuff. For example, the Canadian way of doing this uses EPSG 3348 for projection [1]. I did some Google searching, and it looks like you would want to use EPSG 4191 for the Albania area (see [2]), but 2462 might also the one you want to use ([3], although it looks like you get weird projected bounds with it). I don't know why this reprojection is really even necessary. When you look at EPSG 3348 (the Canadian one), the projected bounds are really weird there as well, so maybe it has to be done just to match up with NRN. If the Albania dataset is already in Lat/Long and 4191 is in Lat/Long and OSM is in Lat/Long, maybe you don't need to reproject at all? Someone with more GIS knowledge should know. You'll also want a script to automatically convert various attributes in the shp file to tags that are used by OSM. For example, I opened up the Roads_OSM.shp file in OpenJUMP (just the way it is, no changes or reprojections or anything), and I see that one road has the following properties: ID: 175879.0 Type: Well-Kept Gravel Road Category: 2 Cat2: 20 Shape_Leng: 0.0 Name: Shape_Le_1: 774.851 ET_ID: 167693 Most of these you probably won't care about, but Type: Well-Kept Gravel Road should be converted to surface=gravel; and highway=unclassified or residential or track=* depending on what the Category: 2 and Cat2: 20 mean. Another road has Type: Dwelling Area Road, which would probably be highway=residential; I've also seen Type: Village Road, Type: Railway, Type: Seasonal Road, and Type: National Asphalted Road. You can see where geobase2osm.py makes similar mappings for Canada, by looking at lines 63 to 77 in geobase2osm.py [4]. None of the roads I sampled had names associated with them (even the national highway, the name was blank). You'll probably have to match up road names to the roads using one of the other data sets? I would like to help out more, but I'm afraid I don't have the experience. I could lend a hand in modifying the SQL tables and geobase2osm.py, but I would be of limited help there, and I haven't a clue how you would get road names imported. You'll want more expertise help in getting the proper toolchain. [1] http://spatialreference.org/ref/epsg/3348/ [2] http://spatialreference.org/ref/epsg/4191/ [3] http://spatialreference.org/ref/epsg/2462/ [4] http://svn.openstreetmap.org/applications/utils/import/geobase2osm/geobase2osm.py Adam On Wed, Mar 17, 2010 at 12:31 PM, Sam Vekemans acrosscanadatra...@gmail.com wrote: Hi Adam, James is looking to use RoadMatcher, i know its on the wiki, but that page needs to be fixed. Would you be able to explain it? Personally, i now favour tracing WMS, but for massive areas RoadMatcher is the way to go :-) Also, Robert (Bob) Shand from PEI is currently Itching to also learn how its done. Cheers, Sam -- Forwarded message -- From: Michael Barabanov michael.baraba...@gmail.com Date: Wed, 17 Mar 2010 12:13:39 -0700 Subject: Re: [Talk-ca] call for help, importing roads To: jamesmikedup...@googlemail.com jamesmikedup...@googlemail.com Cc: talk-ca@openstreetmap.org Sounds like you just need to convert SHP to OSM. Then you can upload from JOSM. There's a script here (though I haven't tried it): http://redmine.yellowbkpk.com/projects/list_files/geo On Mon, Mar 15, 2010 at 12:48 PM, jamesmikedup...@googlemail.com jamesmikedup...@googlemail.com wrote: Hi, I have been talking to Sam V. who mentioned that you guys are experts in openjump for road importing. before I dig too deep into this myself, let me ask if anyone can help me with my current problem: I have these files from a public domain source, projected into Lat/Lon http://xhema.flossk.org:8080/mapdata/03/MapAction/tpginc/ [image: [ ]] LL_Roads_OSM.dbf http://xhema.flossk.org:8080/mapdata/03/MapAction/tpginc/LL_Roads_OSM.dbf 05-Mar-2010 07:48 53M [image: [ ]]LL_Roads_OSM.prj http://xhema.flossk.org:8080/mapdata/03/MapAction/tpginc/LL_Roads_OSM.prj05-Mar-2010 07:48 143 [image: [ ]]LL_Roads_OSM.shp http://xhema.flossk.org:8080/mapdata/03/MapAction/tpginc/LL_Roads_OSM.shp05-Mar-2010 07:48 35M [image: [ ]]LL_Roads_OSM.shx http://xhema.flossk.org:8080/mapdata/03/MapAction/tpginc/LL_Roads_OSM.shx05-Mar-2010 07:48 1.5M They are from http://tpginc.net/gis/albania/albania.php we would like to find the new roads that are not in OSM and import them. Can anyone help? can you tell me exactly what software to install, I am a bit confused my the many pages and broken links I found for jump. thanks, mike
Re: [Talk-ca] WMS Layer for canvec data / toporama
Thanks for showing me this. You have effectively octupled the amount of work I have to do. :( Seriously, the map will be so awesome after the CanVec import. Adam On Wed, Mar 10, 2010 at 12:09 AM, Sam Vekemans acrosscanadatra...@gmail.com wrote: No worries, thats what is great about leveraging this awesome communities talent. :-) I updated the wiki page with the link. http://wiki.openstreetmap.org/wiki/WikiProject_Canada#Natural_Resources_Canada_-_Toporama_WMS_Layer Cheers, Sam On 3/9/10, Austin Henry ahenry-...@canoe.staticcling.org wrote: - Kevin Michael Smith arranged a host of electrons thusly: - If you look at the GetCapabilities response it lists all the available layers: http://wms.ess-ws.nrcan.gc.ca/wms/toporama_en?VERSION=1.1.1request=GetCapabilitiesservice=wms It's down near the end. Just add all of them to the LAYERS paramater of your GetMap request in the order you want them. Here the result (I just used the order in the GetCapabilities response which seems to work well enough [snip] Ah, excellent. I'm glad you beat me to responding to Sam. I'd been meaning to send him that URL for some time, but life keeps getting in the way of mapping stuff for me. *sigh* I guess this is a roundabout apology for not getting to it. Sorry Sam. cheers, austin. -- Build a man fire, he'll be warm for a day. Set a man on fire, he'll be warm for the rest of his life. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca -- Twitter: @Acrosscanada Blog: http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans OpenStreetMap IRC: http://irc.openstreetmap.org @Acrosscanadatrails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Removing old towns/many tags stripped from town locations
I'm not too familiar with the GEOnet Names Database [1], and it's use in OSM and such, but I did notice something rather odd, where one place in Yoho National Park (BC) [2] had a key/value pair of key=Does Not Exist. Could this be because the town no longer exists (since GEOnet retains obsolete names, as it says on the wiki), and the node should be completely removed? Maybe it should get historic=ruins if there are still some ghost town buildings? As I was looking into this situation, I noticed the history of two place nodes, and many tags were removed (the gns tags). See [2] and [3] to see what I mean. I don't know if it is OSM practice to keep all the gns:xxx tags, or to remove them as has been done. I'm not in the mood for cleaning this up myself. Anybody else want to do it (hopefully automated) if necessary? There are probably other nodes that this happened to. [1] http://wiki.openstreetmap.org/wiki/GNS [2] http://www.openstreetmap.org/browse/node/51972207/history [3] http://www.openstreetmap.org/browse/node/51970759/history Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] vreimer again
I think it should be pointed out that vreimer hasn't made any edits since the blocking, and this buggering up was done beforehand (Feb 13, 2010 to be exact). I just think it's worth noting that this Lesser Slave Lake issue is not about vreimer continuing to make poor editing decisions post-block. It would be quite unfortunate if the blocking has scared vreimer off OSM (rather than participating and learning); somebody who spends as much time as him on OSM would be a good ally, with more mentorship. Adam On Fri, Mar 5, 2010 at 11:15 PM, Apollinaris Schoell ascho...@gmail.comwrote: luckily no other edits have been done on the changeset. quick check shows it's malicious or at least careless deletion revert is done but it seems there are 2 duplicated way which should be deleted, maybe veimar tried to fix it but damaged in Potlatch live mode and has no clue about undo good: http://www.openstreetmap.org/browse/way/45266403 bad: http://www.openstreetmap.org/browse/way/45266460 , http://www.openstreetmap.org/browse/way/45266460 On 5 Mar 2010, at 21:59 , James Ewen wrote: Now he's buggered up Lesser Slave Lake... http://www.openstreetmap.org/browse/way/50259428 How do you revert screw ups? James VE6SRV ___ 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] What Google Copying?
Found another example near Valemount, BC, where NRN has a road called Blackman Road (east of a certain road) and Lheureux (west of certain road). Bing has called the road Chevreux. vreimer got it correct, meaning he's not copying Bing either. It's all so mysterious Adam On Sun, Feb 28, 2010 at 4:50 PM, Sam Dyck samueld...@gmail.com wrote: So I found a subdivision which most certainly does not exist, and may well never exist in Google herehttp://maps.google.ca/maps?f=qsource=s_qhl=engeocode=q=8+Neptune+Baysll=49.918003,-97.039597sspn=0.009243,0.01929ie=UTF8hq=hnear=8+Neptune+Bay,+Winnipeg,+Division+No.+11,+Manitoball=49.847205,-97.168794spn=0.004628,0.009645t=hz=17. The streets are not on Yahoo, Bing, OSM or NRN. The land the streets occupy is owned by Manitoba Hydro and has to high voltage lines that pass through it towards the Taylor and Scotland Yard Stations and Downtown Winnipeg ( OSMhttp://www.openstreetmap.org/?lat=49.85185lon=-97.1602zoom=15layers=B000FTF) and while development is planned nearby, I believe this land is off limits for obvious reasons. This would suggest to me that vreimer either lives in Winnipeg and knows Google is wrong, or doesn't get data from Google (which previous posts also suggested). 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
Re: [Talk-ca] What Google Copying?
I've been looking at StatCan's GeoSearch 2006 map [ http://geodepot.statcan.ca/GeoSearch2006/GeoSearch2006.jsp?minx=4432901.48950264miny=2238764.61686325maxx=4434592.66597324maxy=2239794.02862796LastImage=http://geodepot.statcan.ca/Diss/Output/GeoSearch2006_geodepotfarm531483932432153.gifresolution=Hlang=EswitchTab=0] and it seems like vreimer isn't using that one as a copy. Interestingly, Stats Can and NRN disagree with each other on some of the same points that I noticed in vreimer's differences against NRN, but Stats Can introduces yet another variation of errors in the Valemount area. In other words, vreimer, Google, Bing, NRN, and Stats Can all have slightly different versions of Valemount. Not one of those is exactly like any of the others. For some things that vreimer had differed from NRN, he was a match for Stats Can, but then for some things he was different than Stats Can. For example, the Williams Drive/Juniper/Larch area, vreimer had a topological match to Stats Can (Williams Drive extending past Juniper, and no Larch at all), but Stats Can calls it Williams Rd, whereas NRN says Dr, and vreimer has Dr. I looked at Atlas of Canada, but didn't see a slippy map that shows street names. Is there a map from Atlas of Canada that has street names without having to download the data and open it up in some GIS software? Adam On Sun, Feb 28, 2010 at 5:20 PM, Sam Dyck samueld...@gmail.com wrote: Found another example near Valemount, BC, where NRN has a road called Blackman Road (east of a certain road) and Lheureux (west of certain road). Bing has called the road Chevreux. vreimer got it correct, meaning he's not copying Bing either. It's all so mysterious Adam On Sun, Feb 28, 2010 at 4:50 PM, Sam Dyck samueld...@gmail.com wrote: So I found a subdivision which most certainly does not exist, and may well never exist in Google herehttp://maps.google.ca/maps?f=qsource=s_qhl=engeocode=q=8+Neptune+Baysll=49.918003,-97.039597sspn=0.009243,0.01929ie=UTF8hq=hnear=8+Neptune+Bay,+Winnipeg,+Division+No.+11,+Manitoball=49.847205,-97.168794spn=0.004628,0.009645t=hz=17. The streets are not on Yahoo, Bing, OSM or NRN. The land the streets occupy is owned by Manitoba Hydro and has to high voltage lines that pass through it towards the Taylor and Scotland Yard Stations and Downtown Winnipeg ( OSMhttp://www.openstreetmap.org/?lat=49.85185lon=-97.1602zoom=15layers=B000FTF) and while development is planned nearby, I believe this land is off limits for obvious reasons. This would suggest to me that vreimer either lives in Winnipeg and knows Google is wrong, or doesn't get data from Google (which previous posts also suggested). 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 mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] More Google Copying
Found an instance where OSM spelling doesn't agree with NRN spelling, but does with other map vendors, submitted by the above person. In Valemount, BC, NRN has a road in triangular shape called Beavan Crescent, while 8th Avenue terminates at Ash Street. The above person got the correct triangular shape, but misspelled the road as Bevan Crescent. Interestingly, all of Google, Bing, Yahoo and Mapquest agree with the user's spelling and conflict with NRN spelling, but they all conflict with NRN/user's geometry. http://www.openstreetmap.org/?lat=52.830154lon=-119.256376zoom=18layers=B000FTF (OSM map will be changing soon due to import, so may change by the time you see this). http://maps.google.com/maps?ll=52.830277,-119.255911spn=0.002314,0.006968t=hz=18lci=com.panoramio.all http://www.bing.com/maps/?v=2cp=52.830270779110165~-119.25589308142662lvl=18sty=rwhere1=Valemount%2C%20BC http://ca.maps.yahoo.com/#mvt=mlat=52.830162lon=-119.256176zoom=18 http://www.mapquest.com/mq/8-62utTxKQKPkU Meanwhile, Whitepages confirms the NRN spelling of the road. http://www.whitepages.com/search/FindNeighbors?street=830+beavan+crescentwhere=Valemount%2C+BC It's hard to say who's correct in this situation. Would be nice to have more mappers on the ground who can go to the road and look at the street sign. Perhaps a misspell in the sign led to the mapping companies differing from NRN? Adam On Mon, Feb 22, 2010 at 7:00 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Hi Sam, you wrote And the other solution is to be copying directly from the NRCan paper map sheets. Well, it is almost true if you are not concerned by the accuracy. But if you are, you must know that between 2003 and 2008, 9121 datasets were modified to fit the GeoBase alignment Layer. http://www.geobase.ca/geobase/en/data/imagery/landsat/description.html It improved the data (Canvec) accuracy to better than 30 meters for 93% of the files - average accuracy of 22 meters. In some area the displacement was up to 1200 meters ! Where is the problem? The data is now more accurate but the corresponding paper maps have not been reprinted (.pdf) and are still affected by accuracy problems! BTW, if you are right about the data source you mentionned in More Google Copying tread - it could have been from NTDB data origionally - it shows what you will get in pdf's. Daniel -- *From:* talk-ca-boun...@openstreetmap.org [mailto: talk-ca-boun...@openstreetmap.org] *On Behalf Of *Sam Vekemans *Sent:* 21 février 2010 20:17 *To:* Dan Putler *Cc:* Talk-CA OpenStreetMap; Sam Dyck *Subject:* Re: [Talk-ca] More Google Copying Hi, Yup, i just sent off a nice message. Hopefully it will be recieved. I'll let you know if i get a responce back. On Sun, Feb 21, 2010 at 4:42 PM, Dan Putler dan.put...@sauder.ubc.cawrote: Could the data be from the StatsCan RNF? That would explain the geometry being off, while having street names on the ways. Maybe? Then if that's true... then i think it's fine what the user is doing. Its still improving the map (from a blank map). Once the NRCan data is available, then more work is needed (for everywhere for all the features). But again it's to improve the map. So the fact that the geometry is off. We need to ask, how much off is it? ... if it's within 10meters, then it's still acceptable (as thats the GPS standard, when no other sources are available). Since GeoBase roads just has the basic linework is available. The solution would be to also convert the GeoBaseNRN data for Manitoba, then have the .osm files open in JOSM adjust the OSM data to fit the GeoBase road network geometry. And the other solution is to be copying directly from the NRCan paper map sheets (available as PDFfiles). they just need to be alligned with some identifing points (the sheets have corner coordinates on it) and matched to JOSM points. (i used Garmin MapSource to make a waypoint at the exact corners of the sheet to get it lined up) A manual process, but if it's done by local people while adding more details, it shouldn't be that hard. Cheers, Sam On Sun, 2010-02-21 at 16:34 -0800, Adam Dunn wrote: The NRN site confirms that names are not available in Manitoba (NRN for that province is on version 3) [1]. Sam, maybe you should send a nice email explaining that a blank map is better than an illegal one. This person has made edits to my hometown that I basically had to revert because the geometry was way off. Don't know what his source is... [1] http://www.geobase.ca/geobase/en/data/nrn/status.html Adam On Sun, Feb 21, 2010 at 4:03 PM, Sam Dyck samueld...@gmail.com wrote: About an hour ago he/she was editing in Saskatoon, and has done a lot of work in Rural Manitoba to. On Sun, Feb 21, 2010 at 5:48 PM, Sam Vekemans acrosscanadatra...@gmail.com wrote: Not sure if this link
Re: [Talk-ca] More Google Copying
Did some more comparing in Valemount area. There are a large number of errors in Valemount for the major webmap companies (more errors than I normally see). Here's what I've found, and this time I'm just using the person's username because I don't think it's a mystery anymore. NRN: Birch Street Google: Birch (missing street type) Bing: Birch Rd Yahoo: Birch Rd vreimer: Birch Road NRN: Tamerack Road Google: Tamerack Rd (match NRN) Bing: Tamarak Rd (e-a and missing c) Yahoo: Tamarak Rd (e-a and missing c) vreimer: Tamarack Rd (e-a) NRN: Westridge Forest Service Road Google: Westridge FS Rd Bing: Cranberry Lake Rd Yahoo: Cranberry Lake Rd vreimer: Westridge FS Road NRN: Canoe East Forest Service Road Google: Canoe East FS Rd Bing: Canoe River Forest Rd Yahoo: Canoe River Forest Rd vreimer: Canoe River FS Road NRN: Cedar Street terminates on the north end at 14th Avenue Google: Cedar Street continues through from 14th to 13th, even though a house is in the way on aerial photos, but Google does not show a name for this section of street between 14th and 13th. Bing: also extends Cedar Street from 14th through to 13th Avenue, plowing right through a house, but does not show a name for Cedar street, yet shows the short section between 13th and 14th as being called 14th Ave. Yahoo: exact same thing as Bing (I'm beginning to think the Microsoft-Yahoo deal is showing up here.) vreimer: has Cedar Street 120 meters east of actual position (NRN, Google, Bing all agree on longitude location), extends it from 14th through to 13th Avenue and keeps the name Cedar Street for entire thing. NRN: Williams Drive terminates at northeast end at Juniper Street, while just northwest is a road called Larch Street coming out of Juniper Street. Google: Williams Drive extends past Juniper a couple dozen meters (aerial photos show either a service road or private driveway), while Larch Street is missing Bing: Extends Williams past Juniper, although calls it Rd instead of Drive. Also has Larch Street, though shows no name for it. Yahoo: same as Bing vreimer: Extends Williams Drive past Juniper Street, while Larch Street is missing. Position is 150 meters off. Based on Birch, it would appear he's copying Bing. Based on Tamerack, it's a mix of misspellings. We can see from Westridge that he's *not* copying Bing. Based on Canoe, it appears he's *not* copying Google. Based on Cedar, looks like Google. Based on Williams/Larch, looks like Google. In some places, position is off, other places it's fine. It looks like he actually skipped a major road because of this position confusion (it wouldn't fit in where it should). Adam On Fri, Feb 26, 2010 at 2:57 PM, Adam Dunn dunna...@gmail.com wrote: I agree with Sam. On the face of it, from the evidence we have, this person isn't doing anything damaging. Sure, there's a typo, but that could be a mistake. This person isn't just using one copyrighted source, as the new Winnipeg subdivision example has shown. I don't think anybody can tell whether a copyrighted source is being used at all. Maybe it's old versions of NRN mixed with municipal/city data? Maybe he works for a mapping company or some entity that has access to the latest road information? That would be perfectly legit (given the city/company has agreed). This mapper is quite prolific in the system. They have spent many hours mapping roads all over the country. In fact, many hours per day, practically *every* day. It's quite unfortunate that this person has decided not to participate in our discussions. If the sources are not acceptable then it will be quite a large amount of deletion that will need to be done by OSM administrators. Adam On Fri, Feb 26, 2010 at 1:20 PM, Sam Vekemans acrosscanadatra...@gmail.com wrote: I dont think there is actual 'damage'. Its just that we dont know what the source is for the mapping. Alot of tracing (and it looks like tracing), there is a few versions of the NRCan data that it could be from. So its hard to say whats going on. (quick copying can also resault in spelling erors. Sam On 2/26/10, Richard Weait rich...@weait.com wrote: On Sun, Feb 21, 2010 at 8:17 PM, Sam Vekemans acrosscanadatra...@gmail.com wrote: Hi, Yup, i just sent off a nice message. Hopefully it will be recieved. I'll let you know if i get a responce back. Sam V. did you hear back from vreimer and these unusual edits? Adam D. are you convinced this editor is damaging the map? Submit your evidence to the data working group at d...@openstreetmap.org ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca -- Twitter: @Acrosscanada Blog: http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans OpenStreetMap IRC: http://irc.openstreetmap.org @Acrosscanadatrails ___ Talk-ca mailing list
[Talk-ca] NRN 104 Import Complete
NRN of tile 104 is done import. Includes Dease Lake, Centreville, Telegraph Creek, Cassiar Highway, Klondike Highway and bits of Alaska Highway. Bounding box is http://www.openstreetmap.org/index.html?minlat=56minlon=-136maxlat=60maxlon=-128box=yes NRN full raw osm files are in Mediafire folder http://www.mediafire.com/?sharekey=f5178f4ac8a21af3d9d5c56d04dfa8b0dae5bcb806ed8d909d4bfef7ef5beeff Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] 103 NRN Import Complete
Just finished up import of NRN tile 103. This includes Kitimat, Terrace, the aforementioned Stewart, Prince Rupert, and the Queen Charlotte Islands/Haida Gwaii (rename will happen mid-2010). Bounding box is: http://www.openstreetmap.org/index.html?minlat=52minlon=-136maxlat=56maxlon=-128box=yes Raw NRN file is: http://www.mediafire.com/?dymazzy3dzn Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Tiger positioning not quite correct?
Working on NRN import on BC/Alaska border, in the town of Stewart, and it looks like there is a mismatch in positions between TIGER and NRN. Take a look at Highway 37A as it crosses the border in [1]. See that there is no road to connect to in Alaska. Now take a look at how Google maps has it in [2]. Hwy 37A should connect to International Street (makes sense, given the name). Google maps agrees with NRN to within a couple meters, and Google maps agrees with TIGER to within a couple *hundred* meters. Of course we can't use Google as a data source, so we need someone to go there with GPS. [1] http://www.openstreetmap.org/?lat=55.91394lon=-130.02186zoom=16layers=B000FTFT [2] http://maps.google.com/maps?q=vancouverie=UTF8hq=hnear=Vancouver,+Greater+Vancouver+Regional+District,+British+Columbia,+Canadall=55.913139,-130.017636spn=0.004269,0.013937t=hz=17 Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Olympic Road Closures
I've added the road closures due to venue security zones for the olympics. You can see the two changesets in http://www.openstreetmap.org/browse/changeset/3853294 and http://www.openstreetmap.org/browse/changeset/3859377 Source for this was http://olympichostcity.vancouver.ca/gettingaround/road-parking-restrictions/venue-area-road-closures.htm and http://olympichostcity.vancouver.ca/gettingaround/walking/pedestrian-corridors.htm if anybody wants to check and see if I missed something or messed something up. Canadians don't use OSM much, but I'm worried about what visiting Europeans will think of Vancouver in OSM (since it's more popular in Europe). Maybe there will be a surge of changesets? I'm not going to bother with torch relay road closures, since those are only for 12 hours on Feb 12, Feb 28, and March 12. Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
