Re: [Talk-ca] ON prefix on Ontario highways
On Sat, Feb 28, 2015 at 9:25 AM, Jonathan Crowe jonathan.cr...@gmail.com wrote: But it's safe to say that everything else in Ontario can be rendered as a King's Highway, if the number is less than 144 or in the 400s. (Secondary routes have higher numbers in the 500s and 600s.) In Quebec, any route number less than 100 or more than 400 is an autoroute; everything else gets the standard route shield. In Manitoba, provincial roads are numbered 200 and up; anything 199 or lower is a trunk highway. Similar rules apply in Alberta, Saskatchewan, New Brunswick and Nova Scotia: the number indicates the class of route and related marker. Secondary highways disappeared in Alberta in 2000-2001... everything that used to be a secondary is a primary highway now. #1 to 216 are the Primary Core Highways... #500 to 986 are the Primary Local Highways... Nothing really has changed except the higher number series used to be under municipal jurisdiction, now it's provincial. Badging is still the same as before the juggle. http://en.wikipedia.org/wiki/List_of_Alberta_provincial_highways James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Postal Codes
On Tue, Dec 30, 2014 at 7:37 AM, Adam Martin s.adam.mar...@gmail.com wrote: I was reading over the previous discussions held here regarding the issue of obtaining postal codes for use with civic addresses in Canada. I understand that, unless specific permission is obtained, there is no way to utilize the information stored in the Canada Post database, even if that information is manually acquired from the database during a lookup. Anyway, it would appear that obtaining the information from Canada Post is, basically, a dead end. Might I suggest an alternative? Why not a volunteer effort? I can't look up a code and reproduce it on the map, but I can surely put my own postal code and those of my previous addresses into the map. That knowledge has nothing to do with looking it up on their website. Here's where I have a hard time understanding how postal code information can ever be used in OSM. Who created the postal code information? The information can't be traced back to farmer Brown who lived on this lane in 1642, hence the road name Brown Lane. I believe Canada Post created the database, and defines which areas are within the bounds of a particular forward sortation area, local delivery unit. They can change these bounds as necessary. http://en.wikipedia.org/wiki/Postal_codes_in_Canada Since OSM can't use any restricted information sources, and must rely on non-encumbered information, how can Canada Post postal code information ever be considered common knowledge or open data? If you look up my postal code, and put it on an envelope, when I receive that letter, and see my postal code, does it suddenly become public knowledge, and Canada Post loses the right to maintain control? If I print out a Google Map, and hand you that copy, does the Google Map data become non-encumbered? The only way to know the postal code for any specific location is to have at one point referenced the Canada Post database, either directly, or indirectly. Road names, town names etc. can be argued to precede the map databases in a number of cases, and have a legal right to be used. In current towns and cities, when the planners make up road names, it could be thought of that the designers hold the copyright on the road name database (if asserted). I don't see where a completely contrived database of information that is created and controlled by an entity which asserts copyright will ever be able to be used in an unencumbered manner, no matter how many times removed from accessing the database the data is derived. The idea of each person in Canada providing their specific postal code to an OSM database does not remove the hold which Canada Post asserts. It would be illegal for one person to copy the database as a whole, so why would it be legal for 30 million people to copy one piece of the database and pool that information? I love the idea of OSM and would like to see all data available and in use in the OSM database, but I've always had a hard time figuring out the line of distinction between encumbered and unencumbered information sources. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Why does a search for Edmonton show the city out in the country?
If you look at the history, you'll see that way back in the dark ages (Nov 2008), I tried creating a way that defined the city limits of Edmonton. Actually I was creating a way that defined the boundary of Strathcona County, and part of that way was coincident with the City of Edmonton boundary. In the process I decided to create the outline of Edmonton. I was also trying to figure out how to share nodes and ways between two different entities. (Which to this day, I still don't really understand.) This is a remnant of that effort. I would create a way defining the city limits in an attempt to get it to show up on the map. Someone would come along and break it, I would try to fix it, someone would break it, I would try to fix it, etc... I gave up trying to fix it, so you get what you have now... Here's another remnant of part of the boundary between Strathcona County and Lamont County. I see it was just touched a few months ago by someone deciding that the way needed to be named Strathcona County when in fact it is not the county, but rather an administrative boundary between two adjacent entities... but on the brighter side I see Strathcona County is still intact! http://www.openstreetmap.org/browse/relation/50382 There is a city limits boundary (called a county boundary) that looks like it defines Edmonton properly. http://www.openstreetmap.org/browse/relation/2564500 If you look at the history for way 28295454 which you are talking about, you'll see that some dingleberry back in 2008 put a name tag on the way, which then takes you to the center of that way when pointing at Edmonton. http://www.openstreetmap.org/browse/way/28295454/history I just removed the name, type, and area tags from the way. That should stop nominatim from falsely finding it. Yup, now you get a psuedo node in the middle of the relation defining the outline of Edmonton, and a physical node in the reflecting pool at the Legislature with a bunch of tags on it. I really would like to have all of the municipal boundaries on the map of Alberta, but the data is locked up under copyright law. I thought I found a free source of the data, but when I queried why I couldn't access the data, I got a response that said Oops, the note you saw saying the data is freely available is wrong... so sorry, we'll fix that! Interestingly enough, that was a verbal response via telephone. No automated email response, a real live person! -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Larder Lake, Ontario completely missing
On Tue, Oct 1, 2013 at 4:15 PM, James Mast rickmastfa...@hotmail.com wrote:
Anybody want to import this town? It's completely missing in OSM data
except for {66}.
Why ask someone else to import the town? OSM makes it possible for
everyone and anyone to edit the map. That's one of the main premises
behind the OSM model.
--
James
VE6SRV
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Routing tool for openstreetmap.ca?
On Mon, Apr 22, 2013 at 3:33 PM, Samuel Longiaru longi...@shaw.ca wrote: It seems to me that the OSRM routing could benefit greatly by a 0.6 penalty for unpaved roads as had been suggested a few time before, but they don't seem to want to go that way. Why incur a penalty just because the roadway is unpaved? A better solution would be to have the ability to request paved roads only when routing. That way the user could decide whether an unpaved roadway should be selected or not. I suppose the best solution would be to allow the user to select whether unpaved roads can be used for routing, and also allow the user to select the penalty to apply for unpaved. I fight with my GPS all the time. I tell it to never use unpaved roads, but it will put me onto them quite often. Then on the other hand it can try and send me on long detours some times when I know I want to take that 2 mile shortcut on gravel to save 40 miles on pavement. It's pretty tough to teach a computer to be as wishy-washy as a human! -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Routing tool for openstreetmap.ca?
On Mon, Apr 22, 2013 at 7:57 PM, Samuel Longiaru longi...@shaw.ca wrote: If your GPS had that, then maybe you wouldn't be fighting with it so much. :) Or if the database contained road surface information, proper speed limit data, and other valuable information, then the routing engine would have a chance at knowing where to send you. It's a challenge to determine whether the routing engine or the database is to blame for the routing choices. With OSM, we have access to the database, and only ourselves to blame if the information required is not in the database! :) -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] My Android tablet
On Fri, Apr 5, 2013 at 1:01 PM, John Kerr johneddie.k...@gmail.com wrote: Today I tried some mapping with my android tablet. I was trying to trace the outline of a building by walking around it with OSMtracker. I have not played with my files yet because I did notice one thing while doing this and that is I was only accurate to 7 metres. That is not very accurate. So just a few minutes ago I downloaded Vespucci for Android and I hope to give it a try at the same task. John, how will Vespucci increase the accuracy of the your Android device? The accuracy is based on the quality of signals received from the GPS satellites. Working close to the walls of a building will degrade the signals available, and cause possibly even more inaccuracy. Changing the software that is reading the position reported won't make the reported position more accurate. One thing you can do to decrease the inaccuracy is to get a clear unobstructed view of the sky. Moving away from the buildings will do that for you. Have a look at these images I just created... http://wiki.openstreetmap.org/wiki/File:Extension.png A visual depiction of how using a sight line along a building face can help to reduce the position ambiguity of a GPS unit. Standing close to a building blocks the GPS signal reception, degrading position accuracy even more than normal. Moving out away from the building gets a clear sky view, and that combined with the extended length of the wall can be used to reduce the error of the actual measured item. Draw lines between the extended points, and use them as guides to draw the actual building outline. http://wiki.openstreetmap.org/wiki/File:Outline1.png Image showing how using GPS positions captured by extending the sightlines along buildings can then be used to draw the actual building outline. More GPS locations are required to be captured, but GPS position ambiguity is reduced due to being clear of the building obstruction, and also due to the reduction in position error due to mathematical angular error reduction. The further from the building the GPS locations are recorded, less error is introduced into the actual building corner position. I added a bit to my Wiki page... http://wiki.openstreetmap.org/wiki/User:Ve6srv#Extending_Sightlines_to_Reduce_GPS_Error This technique will not remove all error, but can reduce the angular errors when trying to lay out a building outline. You can still have displacement errors (all measured points can be horizontally displace, ie. the whole building might be 2 metres north of where it is supposed to be), but your walls should be closer to true than what you can achieve by walking the perimeter of the building. Complex building shapes are harder to plot using this technique, but you can extrapolate some of the wall locations using this process. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Callsigns...
On Mon, Mar 11, 2013 at 5:15 AM, Harald Kliems kli...@gmail.com wrote: As there already is a database available with the relevant information, I'd voice my usual objections towards importing this data into OSM. The data is not verifiable on the ground (well, I guess it theoretically is if you had appropriate measuring equipment, but still...) Since Colin is talking about the broadcasters, it is pretty easy to have appropriate equipment to verify the frequency... a TV or radio will do that. You can locate the source with a little more equipment, like a directional antenna, and some attenuation. You can get the owner and callsign from listening to the broadcast. Power levels are a little harder to determine remotely though. and probably changes somewhat frequently, making the data in OSM difficult to maintain properly. The local TV and radio stations in my area don't change frequency very often. Many of the radio stations have been on the same frequency and callsign for decades. TV frequencies changed recently due to new regulations, but before that they too were static for many decades. Even when you get into commercial radio the frequencies and callsigns don't change often. Changing a frequency on a radio repeater means changing all the users on that system, a task that isn't undertaken on a whim. Industry Canada assigns the frequencies to the users, and it is a bit of a bear to change frequency assignments. So I don't see the added benefit of having the data in OSM. It's one of those things where the data is of interest to some people and not others. I work in commercial radio, and I have thought about adding radio towers to the database, with frequency assignments etc. It would be very handy for my purposes. My employer might not like me posting all of our frequencies and tower locations though... Not really sure since Spectrum Direct allows people to look up the information anyway. It is always difficult to know what information is of benefit to the OSM database as that is a subjective judgement call. Addresses might be of little use to some users, yet they still are being added to the database. Does their inclusion benefit the database? What percentage of potential users need to require the data before it becomes a benefit? If the data is not included in the database, then potential users of the data won't look at the OSM dataset as a source. If however the data is included in the database, potential new users may be drawn to the dataset. It's the old chicken vs. the egg situation, a catch-22. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Callsigns...
On Sun, Mar 10, 2013 at 5:28 PM, Colin McGregor colin.mc...@gmail.com wrote: This past weekend I did add the tag tower:type communications to the CN Tower, but I want to add the station transmitter information... Probably the only real issue is finding an unencumbered source of station transmitter information. Wikipedia says that the text is available under Creative Commons Attribution-ShareAlike License, but was the information included there derived from an open source? -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Out of date or incomplete NRCan-CanVec-7.0 data
On Mon, Mar 4, 2013 at 12:18 AM, Tony Toews t...@tonytoews.com wrote: I didn't realize you could dig that much deeper into who did what. You can get quite a bit of information... what editor are you using? Or you could update it to reflect reality. Updated. I probably should've joined the nodes to the wooded area polygon or the park so the boundaries are contiguous but I'll figure that out another day. I assumed school yards are part of the residential areas. You can define the schoolyard to reflect that it is a school yard. You can also define the ball diamonds etc. http://www.openstreetmap.org/browse/way/23212591 If you look at the history, the polygon was imported by sammuell from CanVec in an effort to correct data See that's my problem. When I take a look at that polygon I don't know if it's valid out of date data or someone mucking about or what. So I'm glad I asked. Even when digging deeper, you might not know what the person was up to if they didn't put a comment on their changeset. Look at the Brentwood Park polygon above, and tell me what Sundance was doing... there's no comment to reflect the changes made. Thanks muchly for the detailed explanation. Oh Tony, we're just scratching the surface so far! Now you need to go back add the commercial areas, fix all those bad CanVec building outlines etc... There's always more to do in OSM! :) -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Out of date or incomplete NRCan-CanVec-7.0 data
On Sat, Mar 2, 2013 at 6:38 PM, Tony Toews t...@tonytoews.com wrote: I'm just a casual editor who cleans up things I know first hand in a few small towns and a small city.So I went to Landmark, Manitoba and saw an interesting, irregularly shaped out-of-date/incomplete polygon that was added. I don't recall seeing it when I last visited there several months ago but who knows. Residential Area - Source - NRCan-CanVec-7.0 This appears to display a shaded area on the user viewable map. Follow the links to dig deeper into the information available. http://www.openstreetmap.org/browse/way/106216638 The problem is that this is very much out of date or incomplete. Furthermore, for that village/hamlet it's mostly nonsense. Main street, which is the highway running north/south through Landmark is the commercial/industrial road through town although there are houses interspersed among the retail and commercial buildings and feed mill. Furthermore the residential area goes 1.5 blocks west and a few blocks east. So it might as well not even exist. Or you could update it to reflect reality. It is difficult to ensure that every landuse is perfectly represented, but it can be done. In Sherwood Park the residential areas are mapped out, but sometimes the corner store is sitting in a residential landuse, rather than being in a commercial landuse area. Should we delete all landuse polygons because some aren't perfect? Now judging on my memories of that village/hamlet it is probably at least ten years out of date. Fix it today and tomorrow it will only be one day out of date. Ten years from now someone else will be able to complain about it being 10 years out of date! :) Does it serve any useful purpose? Define useful purpose. When you zoom out and look at Winnipeg, do the various coloured areas provide you with any information? Is it safe to delete that polygon or will it come back on some re-import in the future. Would it be better to remove all the inaccurate information from OSM, or to correct/update the inaccurate information? If you look at the history, the polygon was imported by sammuell from CanVec in an effort to correct data provided by vreimer. vreimer was a very prolific OSM user that touched a great deal of the OSM database. Much of the information provided by vreimer was looked upon by locals as being of dubious quality. All attempts to contact vreimer failed, and when a block was put on the account, vreimer disappeared. During the licence change, we lost a lot of valid data that vreimer had touched, and we are still working to replace much of that data to this day. So, delete the information, and someone else *may* come by and replace what you deleted. Update the information, and make a note in the database as to what you did and why, and others can benefit from your updates. Deletion should be reserved for removal of obviously false information. Out of date, or incorrect information should be updated or corrected. We've had some people create towns in the middle of nowhere, and those change sets have been reverted, and removed from the database. Buildings, roads, or other features that have been demolished, or otherwise removed from reality obviously should be removed from the database, but something like the out of date residential area in Landmark Manitoba should be updated, not removed. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Environment Canada Forecast Region boundaries released
On Fri, Jan 25, 2013 at 11:45 AM, Pierre Béland pierz...@yahoo.fr wrote: The place for such data might be better placed in a thematic map were this layer of information is added over the OSM layer. Would that thematic data be stored in another database owned by the user, or a community database? I have a interest in having access to data such as this along with other similar virtual boundaries. It would make sense to have a common repository of such information rather than recreating it over and over again. Is there such a facility available currently? -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Fredericton WMS Offset
On Tue, Jan 8, 2013 at 12:34 PM, nicholas ingalls nicholas.inga...@gmail.com wrote: In reference to the orientation problems, I generally orient according to gps tracks and I also use the road centre lines from the fredericton open data portal to ensure areas are correct. (I know the data hasn't been cleared to use, I simply use it to check the bing imagery) This is the second time in the last little while that a statement like this has been made... What is the official word on the practice of checking non-approved data sources, not for inclusion in OSM, but to ensure what is being included is correct? I understand the concept, but you are using a derivative of data that is not allowed. I can say that I am entering street names from memory, but I'm Just checking Google Maps to ensure I'm spelling the name right. Using non-approved sources to align the Bing imagery is pretty much the same thing. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GPS inaccuracy
On Fri, Nov 23, 2012 at 11:28 AM, Pierre Béland infosbelas-...@yahoo.fr wrote: And it is suggested to deactivate the option Lock on road. If you leave the snap to road function enabled in the GPS, you can conceivably be violating copyright law. If the map database in the GPS is protected under copyright, and you are recording GPS data that is being corrected by the GPS engine to snap to the road, then you are copying road location information based on the map data, NOT the GPS data. This is equivalent to using Google Maps as a background in Potlatch and tracing the road network. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] GPS inaccuracy
This isn't just an issue for OSM... http://www.bbc.co.uk/news/world-asia-20442487 James VE6SRV On Wed, Nov 21, 2012 at 3:35 PM, Daniel Begin jfd...@hotmail.com wrote: Tom wrote: I'm getting the feeling that, short of a definitive survey, a good map is a matter of careful judgement. I was involved in map business for almost 30 years and I met just a few people that could have said that in such simple terms! Thank you Daniel -Original Message- From: Tom Taylor [mailto:tom.taylor.s...@gmail.com] Sent: November-20-12 22:42 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] GPS inaccuracy I redid some of my survey yesterday following Pierre and Bernie's suggestions. The results are more reasonable. After averaging, some of my points were showing error of +/- 2 m or less. In working on the new trace, I learned to shift the Bing images as necessary. Then I found that some buildings fit Bing while neighbours did not. I'm getting the feeling that, short of a definitive survey, a good map is a matter of careful judgement. I suspect at this point I should be writing on the Newbies list rather than this one. Thanks for your tolerance to this point. Certainly I'll still be monitoring this list. Tom taylor ___ 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 -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Internal CanVec conflicts
A really simple answer that gets lost is this: Did you make the edits to the best of your ability, and your edits add value to the OSM project? If so, then it was the right thing to do. We all bring different levels of ability, and may not do things perfectly according to the experts, but if we do the best we can, and are helping to make the map better, that's the goal. Someone may come along and make the data you edited even better, but your efforts are always appreciated. OSM is community project, and the whole community is welcome to help to the extent that their skill set allows. You are also welcome to increase your skill set through learning by reading and asking questions. Welcome to OSM and have fun! On 2012-11-15, at 7:11 AM, Tom Taylor tom.taylor.s...@gmail.com wrote: I've just performed my first edits, in our neighbourhood. One thing I noticed was that some of the buildings are duplicates. I assume this is part of what you are talking about when you mention internal CanVec conflicts. In the case of a local public school, I deleted one of the copies and dragged the other to match the Bing image. Was that the right thing to do? Tom Taylor ___ 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] Edmonton / Strathcona boundary limits
Oops, the original message below was supposed to go to the talk-ca group but I forgot to re-address the message. I'm not sure that I understand why we would expect to see 100% of the Canadian land mass covered by shapes at admin level 6 or any other admin level. Not all of the country is organized and governed at that level. Once the areas that do fall under admin level 6 are defined and displayed, you'll end up with holes where the cities are, but if you add cities to the map, the holes get filled. Now if you were talking about admin levels 8 (city/town/village/hamlet boundaries) and 10 (neighborhoods), I would suggest that these would overlap, since the neighborhoods are a subset of the city. Cities in Alberta are not a subset of a municipal district. BTW, Pierre thank you very much for your help and guidance thus far. I'm making headway on adding features that I have long wanted to ensure were part of the map. James VE6SRV On Fri, Nov 9, 2012 at 11:02 AM, Pierre Béland infosbelas-...@yahoo.fr wrote: James, For such matters, it is important that contributors assure coordination and use the same rules. This is more a OSM technical problem were OSM has to take into account the administrative structure of each province or country. My understanding is that when you build such a hierarchy of boundaries, you should cover all the territory at each level. If there were no level 6 for Edmonton, there would be a hole at level 6. When we look at a map of boundaries at level 6, we expect all the territory to be covered. See http://layers.openstreetmap.fr/?zoom=5lat=52.59638lon=-118.12528layers=B00FFT If Edmonton was not defined at this level, this would create problems. There were discussions before that we both are note aware off. Some people may also know how contributors have addressed this problem in other countries. This is why I suggest that this be discussed ont the talk-ca list. Pierre De : James Ewen ve6...@gmail.com À : Pierre Béland infosbelas-...@yahoo.fr Envoyé le : Vendredi 9 novembre 2012 12h20 Objet : Edmonton / Strathcona boundary limits On Fri, Nov 9, 2012 at 10:06 AM, Pierre Béland infosbelas-...@yahoo.fr wrote: I have duplicated the relation. Now, there are two relations level=6 http://www.openstreetmap.org/browse/relation/2564500 level=8 http://www.openstreetmap.org/browse/relation/2563550 My understanding is that there should be a relation for each level. We should not leave any hole at level 6 and cover all the province territory. Making a search throug Nominatim, it still works fine. From this point, you should discuss this on the talk-ca list before trying to make any modification. Okay, what's the story with this concept? The City of Edmonton is an entity unto itself. It falls under admin_level 8 as per the wiki (http://wiki.openstreetmap.org/wiki/Admin_level) as a city. It is not part of any other administrative jurisiction (i.e. part of a county or other entity) Admin_level 6 defines the boundaries of counties, regional municipalities, improvement districts, etc. Would not having 2 relations, one that defines the city (admin_level 8) and another that defines a non-existent entity (admin_level 6) be considered tagging for the renderer (just to fill a perceived hole)? -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Edmonton / Strathcona boundary limits
On Fri, Nov 9, 2012 at 5:50 PM, Pierre Béland infosbelas-...@yahoo.fr wrote: This is a hierarchical system were you first define level 6 boundaries. Then you can split level 6 in many level 8 boundaries. In such a system, you dont leave holes at the upper level when you only have one child. But for a hierarchy to work, each level above needs to related to the one below. I live in house number 28 on Curlew Crescent in the urban area of Sherwood Park in the specialized municipality of Strathcona County in the province of Alberta, in the country of Canada on the North American continent on the planet Earth. Each of those levels is directly related to the one on either side of it. To do what you suggest for the city of Edmonton would be similar to the below. Shaw Conference Center, 9797 Jasper Ave Northwest, in the city of Edmonton, in the county of Edmonton in the province of Alberta, in the country of Canada on the North American continent on the planet Earth. The problem there is that there is no county of Edmonton. The city of Edmonton is the equivalent of a county as far a looking at the map is concerned. Here's an accurate description: Shaw Conference Center, 9797 Jasper Ave Northwest, in the city of Edmonton, in the province of Alberta, in the country of Canada on the North American continent on the planet Earth. You have examples elsewhere. Paris, France, for example has three relations fort levels 6,7,8. - level 6 : http://www.openstreetmap.org/browse/relation/71525 - level 7 : http://www.openstreetmap.org/browse/relation/1641193 - level 8 : http://www.openstreetmap.org/browse/relation/7444 I do not know the administrative realities of Paris, France. It may actually be part of each of these levels. For the province of Alberta, administrative limits have to be established for both level 6 (county) and level 8 (municipalities). For Edmonton, since the county contains only one city, I have duplicated the relation. The two Edmonton relations, level 6 and level 8 define the same area. - level=6 http://www.openstreetmap.org/browse/relation/2564500 - level=8 http://www.openstreetmap.org/browse/relation/2563550 As above, there is no county of Edmonton. My argument is that creating a shapefile defining a non-existent county just to put a colour on the map is tagging for the renderer. Any municipality declaring itself a city effectively removes itself from the surrounding municipal district. The city of Leduc has no relation to the county of Leduc. The village of Leduc was incorporated in 1899, then changing to a town in 1905. All that time it was part of the county of Leduc, but in 1983 when it declared itself a city, it became an entity separate from the county of Leduc. There may be places where a city can be part of a county (ie. Spokane, Washington is part of Spokane County), but that is not the case in Alberta. I believe Saskatchewan is the same as Alberta where the cities are not part of the adjoining rural municipalities. I'm not sure what the status is across the whole of Canada. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Bing Map of Guelph, Ontario is poor
On Thu, Nov 1, 2012 at 1:46 AM, Paul Norman penor...@mac.com wrote: Of course someone could always purchase imagery, but that can get pricey. And you could still be out of luck due to restrictions in the license of the photography as well. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Demande de vérification, question concernant name=
On Wed, Oct 31, 2012 at 4:18 PM, Daniel Begin jfd...@hotmail.com wrote: I always tag names as name='name used locally'. If a French/English version is used (I mean really used), Then I use name='name used locally', name:fr='French name', name:en='English name. This would seem to make the most sense... In Alberta there are a number of francophone communities scattered about. The Town of Beaumont just south of Edmonton is an example. There's a lot of signage in the town with French language. Most streets and avenues are numbered, but the named roadways are signed both ways... ie. Promenade Riechert Dr. I would think that putting name=Promenade Riechert would be fine, and then have both the english and french explicit variations in the database. I may be naive, but the fact that Canada is a bilingual country is a point of pride for me, and it is something that should be embraced. I feel handicapped by the fact that I am not multi-lingual. I would love to be able to communicate in more than one language. OSM should reflect what is seen on the ground, and have the option to be able to translate if need be. When I go to Mexico, I don't complain that the signs aren't in English, or that the locals don't speak English, but rather I feel inadequate in that I can't communicate properly myself in the native language. However, it sure would be nice to be able to pull up an OSM map and have the option to be able to change all the street names from Spanish to English. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Suivi OSM / OSM Monitoring
On Mon, Oct 29, 2012 at 9:14 PM, Paul Norman penor...@mac.com wrote: I see that Canada is pretty good at the admin2 (Country) level, and the admin4 level (Regions) except for a few islands in the Hudson and James Bay areas. It looks like BC has had the admin6 (Departments) level imported Yes - although they're honestly not particularly valuable data. The admin_level=6 entities are of much less practical importance than the admin_level=8 cities. I guess that all depends upon your perspective... Using the same logic, residential roads are of more importance because they are in the city, as opposed to the primary highways and motorways that connect the cities as they are out in the boonies. County boundaries identify administrative edge of an area just as the city boundaries do. The eastern boundary of the City of Edmonton is also the western boundary of the Specialized Municipality of Strathcona County. Try moving that boundary to the east by a couple miles and you'll see a lot of excrement hitting the fan! I don't know how it works in the rest of the country, but in Alberta, once an area declares itself a City, it gets separated from the county it may have been a part of as far as taxes and other funding are concerned. The urban node of Sherwood Park was for the longest time the world's largest hamlet. With a population of 65,000 it could easily become Alberta's seventh largest city, but to declare itself a city, it would need to draw an administrative boundary. If that boundary included the refineries east of Edmonton, then the rest of Strathcona County would lose a huge tax base, and be left with less money for administration. If the administrative boundary were drawn to just include the urban area, then Sherwood Park would be left with a large residential population used to the service levels available with a much smaller tax base to support them. Therefore the solution is to create the Specialized Municipality of Strathcona County that includes nine hamlets. So, while admin level=6 may be of little importance to you, there are a bunch of politicians, and other municipal government administrators that would argue otherwise. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec imports allowed again?
On Sat, Jul 21, 2012 at 1:09 AM, Paul Norman penor...@mac.com wrote: From: David E. Nelson [mailto:denelso...@yahoo.ca] Subject: [Talk-ca] CanVec imports allowed again? Now that the redaction bot has apparently finished its sweep of Canada, is it safe for CanVec imports to be resumed? I want to try my hand at importing a few tiles around where I live. The bot is still running. It shouldn't impact mapping although uploading frequently is always a good idea. Imports are still not to be done. Are we at the point where we can continue mapping in OSM yet? There's a lot of damaged areas around here that need to be repaired, but it's a waste of time doing so if the bot is still running. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [Talk-us] SOTM US Portland - Call for participation
Could have been worse... it might have been held in Springfield! James VE6SRV On Fri, Aug 3, 2012 at 7:04 PM, Bill Ricker bill.n1...@gmail.com wrote: Do you have a story or project to share at State Of The Map US, Portland Oct 13-14? Now is the time to submit your abstract! ... See you all in Portland! One assumes you mean the new Portland Oregon not old Portland Maine. (Is it too much to expect OSM'ers of all people to realize there are more than one Portland USA? I've rather given up on normals and non-geo-geek geeks, but mappers ...) -- Bill @n1vux bill.n1...@gmail.com ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Creating a relation
In Potlatch2, I should be able to click on a way with another way inside and create a multipolygon relation. I keep running into situations where it won't work, and I can't see a reason why it won't work. Here's a lake: http://www.openstreetmap.org/browse/way/170179011 and a couple islands in the lake: http://www.openstreetmap.org/browse/way/170179004 and http://www.openstreetmap.org/browse/way/170179009 What would be making it impossible to create a lake with two islands with Potlatch2? -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] How did you start in OSM?
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
Re: [Talk-ca] Edmonton OSM gathering
On Fri, Jul 6, 2012 at 8:06 AM, Adam Dunn dunna...@gmail.com wrote: If you are willing to sign up for a free account at itoworld.com, you can use their tool to analyze which users are making edits to osm in certain parts of the world. Looks like I already had an account there... so many tools, it's hard to keep track of all of them. Sign up for the OSM Mapper service, then create an area for Edmonton, then run your analysis. You can view all the users who have made edits to Edmonton, and sort them by number of nodes/ways. Now you can use the OSM internal mailing system to try some outreach to these people and see if they want to attend. Now that is targetted marketing! Not some random website, actual real users. This I can work with... Thanks Adam! I'm supposed to be up that way some time in the future... Maybe we can create an OSM gathering in YK... I'll be back in Ft. Smith in the coming weeks... wanna meet halfway? -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Edmonton OSM gathering
On Thu, Jul 5, 2012 at 7:16 AM, Richard Weait rich...@weait.com wrote: May I suggest that you just do it, and go ahead and set it up and that you reach out through other channels for attendees? If you set up the event on an event-service, like upcoming.com or meetup.com, your event will be seen by _people who are looking for events to attend_. That's awesome, right? You could help new users learn about OSM and make their first edits. The drawback to advertising your event _only_ on this list, is that not all Canadian mappers are on this list. How many OSM mappers in Edmonton are on upcoming.com, or meetup.com? Upcoming.com is a website that is for sale, and on meetup.com, I can't even figure out where OSM might fit in their list. I can't even figure out how to go about finding anything related to OSM on the site. Aha, finally figured it out a bit. I see there's an OSM group in Toronto... now, how do you get people interested in OSM mapping that are members of the OSM community to now move their focus over to this totally unrelated site to be notified of things of interest to members of this site? Seems kind of silly when you say it that way, huh? I encourage mappers in other places to host local events as well. It's fun and a great way to learn from other mappers. Yup, it would be good to share ideas and learn from each other, but I would think that there's a better chance of communicating with people interested in OSM in Canada here than on some other random site. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [talk-ca] Merging ways
On Thu, Jul 5, 2012 at 11:28 AM, Richard Fairhurst rich...@systemed.net wrote: As David said, there isn't, but I'd be happy to look at adding one. That's like a promise of a Christmas present... now I'm all excited! Assuming that (as ever with Potlatch) we go for a 90% solution rather than covering every possible combination... am I right in thinking that you'd like something that combines two areas, with a shared sequence of nodes, into one? Yup, that sounds about right... In other words: A-B-C-D-E-F-G-A and H-I-J-C-D-E-K-L-H become A-B-C-J-I-H-L-K-E-F-G-A (and D is deleted) Ooh, muh brayn hertz! That was hard on the old noggin' but, yeah! That's exactly it. The issue with the Canvec data is that it is processed in tiles, and any way that crosses a tile boundary ends up getting chopped up. Linear ways are pretty easy to fix, just select both sections and join them. Areas are a little more work, as they end up with a common border. It usually isn't too hard to combine these sections. You simply need to cut the node at the start of the slice, and delete the common segment, and then do the same for the other segment. Then select each remaining segment and join them. Automating the process would be very nice as it takes a bit to select the right node, cut it, reselect it, make sure you are on the right section of the split way, and then delete the segment, times 2. Selecting both sections of the split area, and having the program find and remove the common border, and then join the two would be super cool! Here's a perfect example, a little pond that is split across a tile boundary... http://www.openstreetmap.org/browse/way/105928394 http://www.openstreetmap.org/browse/way/81343872 Nodes: 1219746948 (also part of ways 81343872 and 81343872) 1219746952 1219746955 1219746957 1219746959 1219746971 1219746974 1219746978 (also part of way 81343872) 1219746948 (also part of ways 81343872 and 81343872) Nodes: 1219746948 (also part of ways 105928394 and 105928394) 1219746978 (also part of way 105928394) 947636778 947636783 947636784 947636785 947636787 947636788 947636789 947636790 947636791 947636792 947636795 1219746948 (also part of ways 105928394 and 105928394) So we can see that nodes 1219746948 and 1219746978 are the two nodes that are shared on that common border. Remove the common ways between those nodes, and merge the remaining sections together. This is about as simple as it gets. There are other situations where relations are cut, or multiple segments need to be merged because the area crosses the boundary multiple times. However, all these situations get broken down into smaller tasks, where in the end, you do end up merging two sections together just as above. There may be more things to do afterwards, but just automating the merge task would be super! -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Edmonton OSM gathering
On Thu, Jul 5, 2012 at 10:27 PM, Dan Charrois d...@syz.com wrote: While spreading the word as much as possible certainly can't hurt, I'd suggest that at the very least possible events are posted here as well. And BTW - I'm in the Edmonton area, and depending on the date/time/etc. may be interested in attending myself. Yup, you are the only one that I know from the area that's on here, but there may be others lurking that may come out of the woodwork. What would work out better for you? Weekday evening or a weekend event? -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Edmonton OSM gathering
Anyone in the Edmonton area interested in getting together to share ideas? I'm no expert at editing, and maybe you aren't either, but we might be able to share some ideas and together figure a few things out. This need not be any big event, simply a few people with a common interest getting together to share some ideas. If you're interested, speak up. If we get at least two interested people, we can figure out a common location to meet up, sit and have a chat. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec in Potlatch 2
On Tue, Jul 3, 2012 at 7:38 AM, Richard Fairhurst rich...@systemed.net wrote: I've made a little change to Potlatch 2 that will ease the process of loading Canvec data. Potlatch's approach is very much here is some data that you can use to help your mapping, rather than here is some data you can upload in bulk, and the idea is that you load the data as a vector background then pull through the bits you want. Sweet! I was tempted to go to the dark side to be able to import CanVec data with Merkaartor or JOSM, but I missed the intuitive interface that Potlatch provides. Not only do I have my cake, but I get to eat it as well... I think there's even icing on it these days! Thanks for all the work you do making these tools so easy to use and integrated so well! -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Merging ways
So, do dig up an old thread again... is there a way to merge adjoining areas in Potlatch yet? I got a great answer from Adam Dunn on using the JOSM join ways feature. I'd like to be able to do this in Potlatch as it is annoying to have to switch to another editor just to be able to merge these adjoining nodes, and then join the two adjoining areas into a single common area. With the ability to import CanVec directly in Potlatch, having the ability to stitch areas back together right in Potlatch would be nice. I've been searching OSM help, but haven't found the answer yet. I might not be using the correct search terms though. -- James VE6SRV On Sat, Aug 20, 2011 at 11: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
Re: [Talk-ca] Merging ways
On Tue, Jul 3, 2012 at 8:33 PM, David E. Nelson denelso...@yahoo.ca wrote: No. There is no automated process in Potlatch2 that can do a so-called logical union of areas at the moment. The best way to do this right now is manually. You might want to ask the developers of Potlatch2 if they can code it up for you. I guess that truly would be the icing on my cake that I'm eating then! -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Oil Pipeline?
On Tue, Jun 26, 2012 at 11:02 AM, Steve Roy st...@ssni.ca wrote: What's the best way to be able to show there is a trail where the pipeline is? Can I just add a highway/trail on top of the existing pipeline? Or? Does the trail follow exactly over the pipe in the ground? Probably not, it most likely follows the ROW, with deviations here and there, so I would be inclined to create a new way showing the trail. The pipeline shows up when you hit edit because the pipeline is in the database. You're just looking at a map rendering that doesn't display pipelines underground. I don't know of one that does personally, but it would be easy to create one. There's a lot of stuff in the database that doesn't get rendered on the default Mapnik map style. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Canadian imports: good or bad?
On Sun, Apr 15, 2012 at 9:38 AM, Stewart C. Russell scr...@gmail.com wrote: Thanks to all who have provided imports. Keep it up. We have a MAP now! In some areas... there are still vast expanses with little to no information available in OSM. Take this area in Saskatchewan for example: http://osm.org/go/Wk7dy_x-- A pristine area, not sullied by those nasty imports, which chase away the avid OSM enthusiast looking for pristine areas of blank canvas upon which to tag their cartographic masterpiece. CanVec data is available in this area, but no one has taken up the challenge of manually verifying and vetting the process of moving data from CanVec to the OSM database. As Andrew pointed out, it is far less daunting to go in and tweak a road, add more data points to a shore line, or add a POI to an existing area than it is to be faced with an absolutely blank screen. Writer's block morphs into Cartographer's Terror. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Low end smart phones and Open Street Map...
On Mon, Apr 9, 2012 at 5:34 AM, Colin McGregor colin.mc...@gmail.com wrote: Does anyone know how well (or badly) the low end smart phones (such as the Samsung Wave phones) are as GPS track loggers? I grab tracks with my Blackberry and use them to draw roads on OSM. The quality of GPS receivers are about even these days. Give the unit a good view of the sky and it will tell you where you are. I plug mine into the cigar lighter and toss it on the dash of the F-250 while driving down the road. It does a decent job of grabbing location data. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Wind farm access roads that really shouldn't be in OSM
On Tue, Mar 20, 2012 at 12:00 AM, Gerald A geraldabli...@gmail.com wrote: I'm not a big supporter of imports, but if you are going to use them, you should use and verify all of them, not just some bits. I'm not sure if there is a key/tag for unverified, but it might be worth looking at. What's the use of the import then? If you have to go and track every road, and walk around the shore of every lake, and wander down every creek, then you'll have GPS data. Most of Canada will be a blank slate as we do not have enough bodies to capture all of the data manually. The whole concept of importing data was to help fill in the areas where there are no OSM mappers. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Wind farm access roads that really shouldn't be in OSM
On Tue, Mar 20, 2012 at 8:12 AM, Harald Kliems kli...@gmail.com wrote: I can't speak for Gerald, but my point was more about verifiability than about verifiedness. That is, about the question whether a way can _in principle_ be verified vs. whether it actually _has_ been verified. The latter we will have to live with in large parts of Canada; the former I have reservations about. And according to Stewart this is a problem for many of the ways in question here. So if there's a locked gate, and not all OSM mappers can get access, do we remove the roads from the map? We should look at getting a nice big graphic to put on the map that says Here be Dragons! Obviously I'm being a little silly... There are areas that are privately owned, and not accessible to the general public. The Shell Scotford Refinery is a good example: http://osm.org/go/WPrCMJzv- The imagery available for the area is not detailed enough to be able to draw roads, nor even verify where they are. Imagery that is available via sources that can't be used for OSM does not show all of the new expansion area. I have however driven through the area with my GPS, and tracked the roads (and in some cases projected where the roads will be once construction has finished). How many other OSM mappers are going to gain access to the refinery and map out the roads to ensure the accuracy of my mapping? Do my edits stand on their own merit? Now on the other hand, to backup your side of the argument have a look at this way that I ran into today: http://www.openstreetmap.org/browse/way/32377502 If you compare OSM and Google Maps, you can see that both have this road shown, which looks like part of the national road grid. Google goes even further to draw more roads in a grid immediately north of this road. http://sautter.com/map/?zoom=14lat=52.58831lon=-111.2836layers=B0TFFF In reality, there's a gate across the road, and it sure looks like a farmyard in reality. The grid of roads that Google Maps shows is actually the access roads between pens in an old cattle feedlot. Someone obviously was copying roads from an aerial photo and didn't realize what they were looking at. So, this goes to add additional weight behind the verifiability of roads in the OSM database. I wouldn't suggest removing roads that are privately owned from the database, nor removing roads that are not accessible to the general public either. What would be preferable would be to have the roads where access is not available to the public tagged as private, and if gates are in place, put the gates on the map. This is the type of ground-truthing that government boys would like to see come back out of the OSM project. If there were gates on the map, and the road marked as private, I wouldn't have tried to use it as a shortcut to save myself a 20 mile round about road trip. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Wind farm access roads that really shouldn't be in OSM
On Mon, Mar 19, 2012 at 6:07 PM, Stewart C. Russell scr...@gmail.com wrote: But it's not a highway, which implies access. There is no access. The generic use of the word highway implies public access, but in OSM parlance, the term highway is used as a key, and the value assigned indicates the type of way. http://wiki.openstreetmap.org/wiki/Highway Further to that, the access key can be used designate access restrictions. http://wiki.openstreetmap.org/wiki/Access I can draw the outline of my house, and tag it as building:yes, but that does not automatically make my house a publicly accessible structure. It is however still a building. Mapping the road with a gate on it (if there is a gate restricting access), and marking the access restriction would allow others to know that the road exists, and is not accessible to the public. There are many roads in the foothills of Alberta that are privately owned, that have access restrictions on them. By mapping these roads, and the associated restrictions, a person looking to go camping out in the bush can decide which roads to use to get to the desired area. Some roads owned by Sustainable Resource Development (Forestry) have gates that are padlocked to keep the public from driving up to the Forestry Lookout Towers, which tend to be popular destinations for people due to the great views afforded. Google Earth shows the roads in the satellite photos, but it is impossible to see the gates in the photos. Having OSM maps with gates and access restrictions can make it less of an annoyance when you drive for hours just to find your progress to your desired destination blocked. Here's the Mayberne Tower Road: http://www.openstreetmap.org/browse/way/25162913 It's a rough track up to the top of a hill where the Mayberne Forestry Lookout Tower is located, along with a number of communications towers. It is very handy to have on the map because I can show my co-workers the route to our communications tower, and where the locked gate is located. The road is not necessarily accessible to the public, but it still is navigable and used by those authorized. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Re : Duplicated ways
2012/2/26 infosbelas-...@yahoo.fr infosbelas-...@yahoo.fr: Je m'oppose évidemment à ce que tu effaces ces informations. Ceci aurait pour effet de faire disparaitre complètement le sentier de randonnée des cartes. A virtual way that is only in place beside the actual way in order to have a hiking trail appear on a specific map rendering platform would be what is known as tagging for the renderer, which is frowned upon. Showing just one way which depicts the actual location of the way and tagging it appropriately is the correct action. While the information in this linked image from Google Streetview http://g.co/maps/33tg4 is not to be used when mapping, I'm just using this link as a visual indicator to show that there does not appear to be two distinct ways where the OSM map is showing that there are... Accurate information in that database is what should drive the actions of the mapper, not modified mapping techniques to try and make certain features appear on a specific map rendering solution. There is no mention of the map rendering engine/style that would effectively make the trail disappear from the map. Perhaps the use of a different map rendering engine/style sheet may alleviate some concerns. Have a look at how Freemap takes care of rendering multiple layers of types of ways... http://www.free-map.org.uk/freemap/about.html Remember that we are editing the OSM database, not just a single depiction of the data as displayed when processed by a single map rendering engine with a specific style sheet. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Re : Duplicated ways
On Sun, Feb 26, 2012 at 1:05 PM, James Ewen ve6...@gmail.com wrote: Have a look at how Freemap takes care of rendering multiple layers of types of ways... http://www.free-map.org.uk/freemap/about.html Here's another site that caters to hiking and biking. http://hikebikemap.de/?zoom=16lat=45.63281lon=-72.12879layers=BFFFTF Take a look at the options available under the (+) symbol on the right side of the screen. The link above has the Lonvia's Hiking symbols added in. Here's Lonvia's take on the area as well. http://hiking.lonvia.de/?zoom=16lat=45.63054lon=-72.12227route=0.87hill=0.8 The moral of the story is: Don't change the data to get it to look the way you want, but rather change the way you look at the data. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Closed Road Tagging
On Sat, Feb 25, 2012 at 3:04 PM, Paul Norman penor...@mac.com wrote: but is it really a primary if it’s closed until further notice? This a kind of strange comment... why would the classification of a road change due to whether it is open or closed? The Trans-Canada highway washed out last spring during heavy rains in southern Alberta. It was closed until it was repaired. There was to change in the status of the Trans-Canada across the nation due to the closure. There are barriers on the highway in the mountains to shut down the highway during major storms that also don't change the classification of the highway. Obviously a 2 year closure is much longer than a couple weeks, but until the government decides to abandon the roadway, it would still be a primary highway. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Balloon Mapping
Here's the link to the regulations about flying kites and markings... http://www.tc.gc.ca/eng/civilaviation/standards/general-recavi-exemption605_20-appa-2260.htm -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Balloon Mapping
On Thu, Jan 26, 2012 at 2:55 PM, Harald Kliems harald.kli...@mail.mcgill.ca wrote: It's a neat project. Does anybody know what the rules in regulations about this are in Canada? Same as in the US? Canadian regulations are close to US regs, but not quite the same. We regularly fly unmanned non-tethered balloons to 30+ kms with no real issues. We contact ATC and get a NOTAM issued. These balloons are very small and tethered, usually at low altitudes. There are limits on the strength of the tether line, and you'll need to be aware of the maximum altitudes near airports, etc. Here's a link to the Canadian Air Regulations, specifically tether balloons. Look at the index to find more specifics on the type of flight you'd be running. http://laws.justice.gc.ca/eng/regulations/SOR-96-433/page-175.html#h-768 -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] ODbL compliant remapping
I'm still a little confused on how a user that does not accept the new license can simply touch a node or way, and make it so that we have to completely remove the data and recreate it. vreimer seems to have touched a great deal of ways across Canada, which sparked the banning of his account quite a while ago. He is listed as being contacted, but we have never seen a response from this user, at least that I know of. I can understand that if the user modified a tag or something, that we would only need to remove that modification. However I am seeing things where a way from the GeoBase import has somehow been taken over by this user. This means we need to strip out the way, and then completely recreate the way. Here's the deep diff page: http://osm.mapki.com/history/way.php?id=51536611 Obviously this way was created by the GeoBase import robot, but vreimer is shown as the creator. I traced this rail line from the aerial photos years ago, but vreimer is the creator of v1... http://osm.mapki.com/history/way.php?id=51536149 I have to strip out my original work, and retrace the rail line yet again. If after that, someone that does not agree with the license comes along and touches it, then it will need to be stripped out again, and retraced... seems kind of silly that we can't simply touch it again, and reclaim the proper license. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Automated imports of Canvec?
On Thu, Dec 15, 2011 at 1:46 PM, Richard Weait rich...@weait.com wrote: I think that OSM will be complete, and in maintenance mode once we have a mapper on every block. And in what dream world do you live? With a population of 34 million, and an area just under 10 million square kilometres, we've got a long way to go to have one mapper on every block. Right now if every single person in Canada contributed to OSM each person would need to look after more than 0.25 square kilometres of area. We really don't have that kind of participation level in Canada yet. Even if we did, would you be willing to wander up to Ellesmere Island and wander about your assigned chunk of land with your GPS, and gather all the pertinent data for inclusion in the OSM database? Yes. That's a grand goal. As more and more places approach that grand goal, the local data gets better and better. Few important things can change in the real world without a mapper noticing and updating OSM. Maybe, perhaps if you're lucky you might find a few places where there might be a congregation of mappers and it may look like there are lots of helping hands available. For the most part Canada is sparsely populated. Most of the population lives along the US border. If your goal is to map out the densely populated portion of the country and leave the rest a blank slate, then perhaps your goal is attainable. For the rest of us who do not live in the sardine can, the task of mapping the rest of that blank slate is a wholly unattainable goal within our lifetime, the lifetime of our children, their children, and probably even their children. There are millions of square km of wilderness that have never been travelled by humans, and remote sensing is the most cost effective way of mapping the area. Canvec has that data already in hand. In what world does it make sense to reinvent the wheel? Pull in Canvec data in areas where there's no data available, and as mappers have the time, ability, and inclination, updates and changes can be made to increase the accuracy of the data included in the OSM database. While data-processing tools have improved with every generation, I don't think that insufficient automation is the problem. It sure would help. I'm standing as far away from the fence as I can on this issue... well onto the build that tool side. I'm probably one of the problem children causing issues importing Canvec data because I lack the knowledge of how to fix all the errors that are reported by JOSM. I can't even find out where the errors are to fix them, so I import and then go back with Potlatch because I know how to get that program to work. BTW, I'm not flying to Toronto to go to an OSM gathering to learn how to run JOSM... I'm willing to listen to reason (well, _I_ think I'm reasonable,) Yes, you are, and you have a lot of valuable insight, and reasoned arguements. To get some insight into the task at hand, please map out the City of Prince Albert, Saskatchewan. It is in need of additional detail, such as the city streets. It's only 65 square kilometres, so it's not much more than your share of Canada to map if we were able to get 5% of the Canadian population to work on mapping Canada. So far we haven't got strong data to support or refute that imports harm OSM community vs. imports are better than no data. I guess we just stop doing anything and see if there's any change. How about considering a partial import in some places. We've done that in Alberta. The roads were imported in areas where there was nothing before. There's a bunch of work to do to fix where the import stopped and low resolution tracing was left in place. That's getting done slowly. In the mean time, there's data on the map, rather than a blank slate. I still go out of my way to gather GPS tracks and upload them to OSM. I make a bunch of detours into the pull offs and rest areas along the major highways now, to gather information that isn't available in the Canvec data. I can concentrate on adding detail, rather than having to try and splash copious quantities of low quality data across the province to try and get something on the map. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Automated imports of Canvec?
On Thu, Dec 15, 2011 at 9:05 PM, Steve Singer ssinger...@sympatico.ca wrote: If someone were to import a 100% pure canvec data an empty openstreetmap instance and render this as a background WMS layer would this then make editing/importing canvec data in Potlach easier? I think tracing a more verbose version of canvec might be less error prone for many people than importing direct from the .OSM files. That would be nice to have. One of the difficulties with the Canvec import is the fact that the Canvec data gave way in deference to existing OSM data. This means that there are lots of places where we need to connect the two together (not so hard), or where poorly aligned ways were kept and better quality Canvec data was left out. http://www.openstreetmap.org/?lat=53.786lon=-112.0373zoom=14layers=M Being able to see the Canvec data that was left out would be nice. Being able to grab the segments that were left out and import them to replace the poorly aligned ways copied from low resolution images would be even better. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Calgary Area Trail Mapping Project
On Sun, Nov 6, 2011 at 2:35 PM, Paul Norman penor...@mac.com wrote: I was looking at the new truck rendering layer at http://www.itoworld.com/product/data/ito_map/main?view=160 and ran across an import called the Calgary Area Trail Mapping Project. This is, as far as I can tell, the only significant use of hgv=* between Vancouver and Toronto. Does anyone know anything about it? The hgv=* (and other access) tags on http://www.openstreetmap.org/browse/way/26574987 seem somewhat out of place. The Calgary Area Trail Mapping Project is tied in with a local 4X4 club from what I recall... I was in communication with one member a number of years ago. Most of the trails they are adding are for off highway vehicles, ie. four wheel drives, quads, or smaller more maneuverable machines. I ran across some trails from the project when out on a week long horseback riding camp... http://www.openstreetmap.org/?lat=52.0671916007996lon=-115.968310832977zoom=14 The roads there are tagged as hgv=no, and are indeed not suitable for most passenger cars. The hgv classification possibly being mistaken for High Ground-clearance Vehicle rather than Heavy Goods Vehicle. More appropriate would probably be the TRACK, TRACKTYPE and SMOOTHNESS tags. There's no ACCESS value for OHV (Off Highway Vehicles) As with many tags, the use of the tags by the author may not be what the intended us was... -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Imported frustrations
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
Re: [Talk-ca] What should a Canadian style map look like?
On Tue, Sep 13, 2011 at 9:12 AM, Yves Moisan yves.moi...@boreal-is.com wrote: One thing that bugs me is that we need to zoom in quite a bit to see highway and road numbers. Then with CanVec import data, you get a highway number on every segment. CanVec data splits ways at each intersection, no matter how minor. The map rendering engine needs to be smart enough to reduce the number of shields or labels to a sane number. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Merging ways
On Sun, Aug 21, 2011 at 11:41 PM, Adam Dunn dunna...@gmail.com wrote: 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). Ah, yes... Changed that with Potlatch. I'm going to have to figure out how to do that in JOSM. How do you zoom out when selecting an area with the slippy map? All I can do is zoom in. I have to shut down the program to be able to select another area if it's larger than what I am looking at. That's really annoying. I've tried every combination of modifier keys I can think of. 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 I had looked at multipolygons before, and had a rudimentary understanding... I missed the fact that you could define the outlines of the polygon with multiple segments. Thanks for the nudge. I had started importing CanVec tiles around Bonnyville, but never merged the edges as I didn't know how. I also ran into a problem with Merkaartor not being able to handle more than 5000 nodes at a time. Perhaps I can get things working with JOSM. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Merging ways
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] Merging ways
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
Re: [Talk-ca] Geobase vs Canvec
On Tue, May 24, 2011 at 6:04 PM, Nakor Osm nakor@gmail.com wrote: I was looking at Canvec data vs Geobase data around Pointe-à-la-Croix, QC and Campbellton, NB. Geobase is already there but is missing street names. Canvec has street names but all ways are marked surface=unpaved and lanes=-1 which I guess is false. There are also some inconsistency in highway levels. Which one is more to be trusted? Put your boots on the ground. Gather local data and verify for yourself. That's what this OSM project is all about. People getting out there and gathering data that is available for everyone to use. CanVec and GeoBase are shortcuts that we have permission to use, but we should still do our due diligence and ensure the information that we are importing is accurate by verifying the information with real world boots on the ground verification. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Importing Canvec data, but causing huge issues
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
Re: [Talk-ca] Canvec vs. GPS
On Sun, Mar 6, 2011 at 6:57 PM, john whelan jwhelan0...@gmail.com wrote: Being cynical I'd tend to favour CANVEC they tend to have spent more money on their GPS units. Based on experience I'd go the exact opposite way as Canvec data can be extremely old and inaccurate. Today I removed a Canvec way describing the Blackmud Creek from the database. Dan Charrois had imported the waterway from Canvec, and the imported way overlapped the existing way. Remnants of that can be seen here for a short while. http://www.openstreetmap.org/?lat=53.4262lon=-113.4888zoom=14layers=M Both renditions can be seen where the creek crosses Ellerslie Road. Hiigher zoom levels have already been rendered. Canvec buildings are horrendous: http://www.openstreetmap.org/?lat=53.42826lon=-113.49479zoom=17layers=M http://www.openstreetmap.org/?lat=53.4145lon=-113.54344zoom=17layers=M http://www.openstreetmap.org/?lat=53.43157lon=-113.54426zoom=17layers=M Feet on the ground are the best judge of accuracy. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Secret routing demo.
Oop, forgot we were supposed to indicate routing errors corrected here... Southeast of Edmonton, Alberta: Highway 14/21 interchange node not connected fixed. Canvec service road removed from highway 14/Anthony Henday interchange. It would definitely be nice to have this functionality built into the editing tools. I was running Geofabric in one window, and then having to find the same spot in another window with Potlatch to be able to find and correct the source of the error. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Secret routing demo.
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
Re: [Talk-ca] Aylmer/Hull QC: CanVec import overwriting existing edits
On Sun, Feb 20, 2011 at 9:41 AM, Richard Weait rich...@weait.com wrote: I'm a advocate of not importing. I like to think that I have tempered my default no-imports stance with a realistic compromise of the well-considered, carefully executed, limited scope import, that might be a net benefit if everything goes perfectly. That message seems to get diluted when an enthusiastic contributor discovers an interesting dataset, and an import script; all they seem to hear is Hey! Imports! Cool! Watch me go1! I find that frustrating. The not importing would be a bad thing for OSM... truly gathering GPS traces and using them to map an area really is importing data. Even drawing from memory could be considered importing. Of course that's getting a bit silly. I think the more accurate wording Richard alludes to is automatic blind importing. Any work that we do on the OSM project really needs to have a set of eyes that are connected to an intelligent brain go over the data to ensure the best decisions are being made. Whether the source of the information is local knowledge, personally collected GPS traces, non-copyright maps, or government source datasets, it needs to have someone look at what is being imported to the OSM database to ensure things are happening in the best interests of OSM as a whole. The road matcher script that was used to try and find existing roads, and exclude the duplicates worked fairly well to try and keep from causing some of the problems seen in Aylmer. I still find places in Alberta where duplicate roads exist. Usually the culprit is the fact that the first pass at creating roads for OSM were done by hand from low resolution imagery. The road matcher script didn't associate the existing road with the CanVec road, and the CanVec imported road was placed in the OSM database. It takes manual intervention to correct this issue. When using any source data, one has to do due diligence in ensuring that the information being imported into the database is the best quality data available. If I were to set my GPS up to capture a trace with one point every 30 seconds, and then blindly use that trace to replace a high quality version of a road that already exists in the OSM database, we'd probably hear the same complaints. The CanVec data is a huge source for data that is available for import into OSM, but that just means that we have a lot of data to verify as we import it into the OSM data. As Richard has mentioned, we have some powerful tools, we have huge volumes of data available, but using the tools to import the data in an ideal way is still an elusive goal. It takes some time and work to get what we want to happen the way we want it to happen. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] About OSM communication channels
On Thu, Jan 27, 2011 at 4:49 PM, Richard Weait rich...@weait.com wrote: But what about the rest of us reading this list? How is the list working for all of us? Is there anything that we could or should improve about the list? Other than the usual complaint that the list is set up to reply-to the individual rather than the list, but then that degrades into the You're not using the right email program garbage... I just try to remember to fix the screwed up addresses before pressing send. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec data to OSM
On 1/24/11, Dan Charrois d...@syz.com wrote: I did a little test import in my area (083H13), which seemed to work well. Howdy neighbor! (I'm in 083H11) To be sure I wasn't adding duplicate features, I only added the categories for features which didn't already exist in the area (waterway=stream, natural=wood, etc.). We already had good road network data for the area, which has been available for some time, and has been tweaked since, so I definitely didn't want the Canvec data to override that. Actually, keep your eyes open for issues there. Before GeoBase data was available, there were a number of ways that roads got into the database. The initial work was very crude, with major highways just being lines in somewhat the right area. A few of us drove around gathering GPS traces, and brought some of those roads closer to reality. Some of the secondary highways, along with the backroads were traced off low resolution imagery. They can be a little bit out of alignment. When User:GeoBaseStevens did the mass import of road data for Alberta, the routines he used tried to keep from overwriting existing user contributions. As such, there are some roads out there that can be quite a bit out from reality, and even more that are closer, but still not quite right. A few, like a section of highway 43 from Onoway to Whitecourt has been peeled up, and not replaced. If you are playing in the area, and notice things missing or out of alignment, feel free to peel and replace. During a mass import, it was felt that it was important to not blindly erase all user input, and replace with GeoBase data. However, if you are manually looking at the data, and making an informed decision to replace one set with another, that should be acceptable. Check the existing ways for tags that might not be in the CanVec data. Also be aware that there are a lot of errors that were introduced by a User:vreimer. There are highway label tags on roads that aren't highways, duplicate label tags, and other errors such as that. Clean those us as you find them please. A few situations like natural=water took much more effort since we already had data available for the large lakes, but not smaller ones. Not wanting to remove the OSM data already in place, and wanting to avoid duplications with the Canvec data, I went through and did a fair bit of manual editing to make sure I was only adding data for new features, not changing existing ones. Again, the major lakes were probably traced out by a script called LakeWalker. It used aerial imagery to try and find the edge of lakes. Due to the quality of imagery available, some lakes weren't quite accurate. I have poked at some to fix the obvious errors, but most of that is done using the same low resolution imagery. I've done a bit of water import (see around Bonnyville), and would use the same criteria as for replacing roads. If the existing water is less accurate than what you have, peel and replace. Most of what was done previously was done with low quality source data, and it was inserted into the database to simply get something onto the blank screen. I did some forest imports around Bonnyville, but find that the roads dissappear into the trees because the grey for roads is not much different in contrast to the green for the trees. I also ran into an issue with OSM not liking the number of points I was trying to import at once as well... Thanks for your help! I look forward to getting more involved in continuing to add to the OSM resource! Thanks for joining the OSM community... we need more hands and eyes on Alberta... there aren't a lot of us poking around the map up here, especially outside of the big cities. Syzygy Research Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 Hey, aren't you a Pfranc distributor? I've been to your house! James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec data to OSM
Repost of the whole email can be found at the end of this email. Dan, This discussion is probably of benefit to more users across the country, as the GeoBase/Canvec import process is still underway, and others are dealing with similar issues. There are literally thousands of little problems left behind from the import process. Any highway that was close enough according to the import script was dropped. Any roadways that joined into the dropped highway ended up not being joined to the existing highway. This requires manual intervention to connect all those unconnected intersections. GPS traces are fairly accurate these days, but you will find many people that will argue the opposite. It's up to your interpret the data you have before you as to how accurate each is in representing reality. The whole OSM project is based upon crowd sourcing, and leveraging all of the local expertise. Eyes on the ground supersedes any remote monitoring no matter how good it might be. Those local eyes see things as they are currently, and not as it was when the remote monitoring (satellite photos or such) were taken. I pretty sure JOSM can pull up history. I don't use JOSM, so don't know for sure, but history on each way is available in the database. Someone familiar with JOSM will be able to jump in. vreimer has edits in just about every part of Canada, if not the world. The proliferation of his edits is what brought about suspicion as to the accuracy of the information being included in the database. vreimer never had any interaction with anyone in the OSM community that we know of, and because of that lack of communication, the account remains in suspension. Just a simple conversation or two on this reflector would probably reinstate full edit capability to the account. By asking the questions you have, and participating in this discussion would lead most OSM users to believe that you have the right intentions, and will be doing your best to add to the quality of the database. As for the protocol for changing the Google document... I think I just added my notes after the GeoBase import comments to show that I was adding more detail beyond the highway import. I don't know if it's really important to follow an official protocol, it's more about just letting people know that you're working on an area so that there's no duplicated work happening... there's not enough of us working to waste time duplicating work. James VE6SRV On Mon, Jan 24, 2011 at 7:27 PM, Dan Charrois d...@syz.com wrote: Hi James. Thanks for writing! It's nice to hear from someone else on the project who lives in the same area! I'm not sure if this discussion is so local-centric that it is best not carried out on talk-ca, so I'm writing to you directly. If you think it would benefit by being posted to the mail list, feel free - or let me know, and I can repost it there. To be sure I wasn't adding duplicate features, I only added the categories for features which didn't already exist in the area (waterway=stream, natural=wood, etc.). We already had good road network data for the area, which has been available for some time, and has been tweaked since, so I definitely didn't want the Canvec data to override that. Actually, keep your eyes open for issues there. Before GeoBase data was available, there were a number of ways that roads got into the database. The initial work was very crude, with major highways just being lines in somewhat the right area. A few of us drove around gathering GPS traces, and brought some of those roads closer to reality. Some of the secondary highways, along with the backroads were traced off low resolution imagery. They can be a little bit out of alignment. That then explains a lot of what I've found. When I first started looking in detail at OSM data, I found that there were lots of little problems - there were two Highway 651s sitting side by side, for example, where they passed through Legal. I'd removed one of them, connected side streets that weren't connected, etc. And even the highway that remained needed to be adjusted about 100 metres from where it was. Ultimately, GPS traces are about the only good definitive way to narrow down with certainty where the roads absolutely are - I've gotten to driving around lately with the GPS on just to fix roads that I happen to go on. If the CanVec data itself could be trusted 100%, it would be simple to just replace what exists with the CanVec data, but since existing roads have been in the system for awhile, I figured there might be some user edits that we don't want to lose - I know in the past, I've nudged roads around where need be, and I suspect that others in the area have done the same. In general, the policy I'm sort of adopting for myself is that if I GPS trace a road and find that it doesn't match what there is, I'm justified in moving it. But as for CanVec data, I don't trust it definitively unless
Re: [Talk-ca] Purging vreimer
On Fri, Jan 14, 2011 at 8:39 PM, Samuel Dyck samueld...@gmail.com wrote: I've been looking at replacing much of vriemer's work in manitoba with Canvec data. Even replacing one tile is a daunting task, so I thought I'd ask the opions of others before I start work staring with Canvec tile 062H10. What do people think? Is all the data from vriemer flawed? He was a very prolific editor before disappearing after being contacted and asked to communicate with the OSM community. I run across entities with his fingerprint all over the place, but I can not guarantee that there are issues with everything he touched. If everything that had a vriemer edit on it was damaged, it would be very easy to clear it all out, but I don't see that in the areas that I've looked at. Obviously some of the edits were suspect, which is what triggered the block on his user profile, but there never was a consensus to remove all edits by that user. Perhaps what you are seeing in your area is different from what I have observed. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] How to tag London Drugs?
On Thu, Dec 2, 2010 at 5:37 AM, Richard Weait rich...@weait.com wrote: Your suggestion of shop=department_store, plus a POI for amenity=pharmacy, sounds ideal. Remember to add dispensing=yes, to the pharmacy POI if they dispense prescriptions. Just to sate my curiosity, what would a pharmacy sell if it didn't dispense prescriptions? Would 7-11 be a pharmacy because they sell Tylenol? I equate dispensing prescriptions implicitly with the term pharmacy. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Over-classification of rural roads in Canvec data?
On Sun, Aug 15, 2010 at 1:11 PM, Tyler Gunn ty...@egunn.com wrote: The one that I'm somewhat mixed on is the classification of all the minor roads in rural MB; Canvec has all the all the gray roads in the example link above listed as tertiary. Given that I know these roads to be nothing more than dirt/gravel roads between farm properties I have downgraded the lot of them to highway=unclassified. There are a number of reasons why the rural road grid should be tagged as tertiary in my mind. First off the descriptors used in the OSM features pages describe the system of roads found in the UK primarily. The UK is significantly smaller in size than Canada, and the road network found in that country varies considerably from that which can be found in most of Canada. With that in mind we have to interpolate. Unclassified roads used to access a farmyard in the UK might be considered a driveway in Canada. So, if you put all the 1 and 2 digit roads as primary, and all the three digit roads as secondary, you come up with a fairly useful map of the main highways. In the UK, they also have 2 designations above that that would not be used in your definition. You also suggest dropping from secondary down to unclassified. Would there be any tertiary roads in Manitoba? I look at it from an overall mapping standpoint. When you look at the UK, viewing the country as a whole, you can see quite a bit of their major road network. If you were to look at Manitoba at the same zoom level with primary highways being the highest classification, Manitoba would be blank. Primary roads show up at zoom level 7, secondary at 9, tertiary and unclassified at 10, with tertiary being distinguished differently at 13, at least on the Mapnik rendering. Being able to tell which roads should be chosen to get between locations by observing the depiction of the road on the map is of primary importance to me. If you drive all of the road designations down to the low end of the scale in Canada, you end up not being able to distinguish all of the various low grade trails and tracks from each other. In Alberta, we have the provincial road grid generally defined as tertiary. That being the road grid that is laid out along the township grid system, with Range Roads every mile going east/west, and Township Roads every 2 miles going north/south. Roads of lesser importance, and subsequently lower quality (narrower, lower grade pavement) are tagged as unclassified or residential. These roads would include subdivisions. http://www.openstreetmap.org/?lat=53.5202lon=-113.1563zoom=13layers=M The depiction of these roads allows the viewer to make decisions based on visual cues, keeping to the higher grade roads, which are designed to be collectors, rather than shortcutting through residential areas on roads not designed for higher traffic flows. A lot of this thought process is based on how things would end up being rendered, but those rendering rules are based on what type of usage these roads are designed for. I have a GPS from Italy that uses the rendering rules from Italy for depicting the map data for Canada. I have both TeleAtlas and Navteq databases for the unit. Both databases are nearly useless for trying to find a decent route anywhere. Why? Because of the difference in road density between Canada and Europe. If I zoom out far enough to see Edmonton and Fort McMurray, I see no highways. If I zoom in close enough to see highways, I can see where they go to know if I can get to my destination via the highway. The distance between towns and cities in Canada is easily a magnitude greater than in Europe. Cities in Europe can be minutes apart, whereas they are generally hours apart in Canada. Have a poke around Alberta where a great deal of the road grid has been imported from GeoBase, and see what you think of how the road network import looks. We need to be consistent on a national basis... James VE6SRV ___ 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?
I vehemently oppose including bad data in the OSM database. I only insert the best possible data available into database. If your GPS tracks are the best data available, then insert that into the database. Should better data become available, then that should be used to increase the accuracy of the trail data. It's all in the way you look at it! James VE6SRV On 7/26/10, G. Michael Carter mikeycarter1...@gmail.com wrote: You have my vote. Just having the inaccurate data will draw more people to the trail. Higher percent chance of getting more gps data for the area. Sent from my iPhone On 2010-07-25, at 10: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 mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec.osm Product - Running!
On Thu, Jul 22, 2010 at 5:50 AM, Sam Vekemans acrosscanadatra...@gmail.com wrote: what nts tiles # are you in/interested in? Sam, you mentioned the NTS tile number WMS server the other day... perhaps a URL for it might be of use. I've been poking at the NTS tiles around Edmonton, and they aren't lining up with the NTS tile sheet numbers that I am familiar with. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Canvec.osm Product - Last Call !!!
On Tue, Jun 29, 2010 at 2:27 PM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: The Canvec.osm Product engine is ready to launch. Perhaps a little header information on the wiki page that describes what this product can be used for, and how to make use of it would be in order. I'll admit I have been skipping the email bouncing around about this product. I went to the wiki page to find out what it's all about, and I'm none the wiser. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Fwd: Merkaartor and WMS layers
On Mon, Jun 28, 2010 at 7:21 AM, Bob Dustan bob.dus...@gmail.com wrote: On 06/28/2010 12:35 AM, James Ewen wrote: Is that all? Is there anything else you have to do? Do you have to select layers in the Layers window? The layers window gets populated with a tree that has all the available layers. I don't think you have to select layers because they are specified in the URL. In other words, the program seems to automatically check for you. For instance, the URL includes designated_areas and that layer is checked on my system. However, you can check whichever ones you want. I went through and checked every box, put in the projection, and last night got an image. Today without changing anything, it doesn't work... What about Projection, Tile it, Zoom levels, Image format, and Styles settings? In my case, they are: Projection: EPSG:4326 Tile it: unchecked (I don't know what this is for) Zoom levels: 0 (I don't know what this is for) Image format: image/png (same value as in the URL) Styles: blank (I don't know any appropriate values for this) Yeah, that's what I have, and know as much as you do about the settings. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Fwd: Merkaartor and WMS layers
On Sun, Jun 27, 2010 at 8:31 PM, Bob Dustan bob.dus...@gmail.com wrote: In the WMS servers setup dialogue box, I copy/pasted the desired URL from the wiki page (see below) into the Server Url field, typed a name in the Name field, and clicked the Add button. Then I clicked the Ok button to dismiss the dialogue box. Is that all? Is there anything else you have to do? Do you have to select layers in the Layers window? The layers window gets populated with a tree that has all the available layers. What about Projection, Tile it, Zoom levels, Image format, and Styles settings? In the Layers pane, you should see a Map layer. Its title will begin with Map - . This is where you choose which WMS layer to display. Right-click on the Map layer. Then choose WMS Adapter and finally choose the WMS layer that you set up in the previous step. All of the custom WMS layers appear under WMS Adapter. I suggest you start with item 1 below as this WMS server is reasonably responsive. Did all that you have outlined, and get nothing useful for my efforts. There is a serious bug with version 0.16 of Merkaartor -- it doesn't display the WMS layer. So make sure you are using 0.16.1 That's what I'm using. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Mapping Private Roads?
In my opinion, placing the information into the OSM database is not the issue. The issue is more of being able to gather the data legally. In areas where the yahoo imagery is of sufficient resolution to allow tracing, I don't see how any entity could put a case together making it illegal for OSM to include the data in the database. Knowledge is not illegal. Trespassing on private property in order to gather GPS traces on the other hand could land you in trouble. The data obtained is not illegal, but rather the manner in which it was obtained is where one runs up against the legal issue. If the land owner has no objections to gathering the GPS traces, then there should be no issues. I have captured and added many ways in private lands, such as refineries[1], mines[2], oil leases[3], and even Department of National Defense bombing ranges[4]. My access to these areas was always with permission from the land owner. I gather the information, upload and enter the information into the database, and then use the subsequent maps in my reports for my employer, and customer. It works out really nicely, as I can create maps of the area where I am working, and then produce reports with background maps that no one else has available. As a bonus, the OSM project gets more information included in the database, and other uses have access to the same maps. I've had queries about where I got the maps from, as other co-workers have looked for maps, and were unable to find them. James VE6SRV [1] http://sautter.com/map/?zoom=14lat=53.80445lon=-113.09712layers=B0TF [2] http://sautter.com/map/?zoom=13lat=53.57742lon=-117.48367layers=B0TF [3] http://sautter.com/map/?zoom=12lat=59.9385lon=-122.94594layers=B0TF [4] http://sautter.com/map/?zoom=10lat=54.85922lon=-110.59387layers=B0TF ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Google copies GeoBase
On Fri, Apr 30, 2010 at 10:19 PM, Gregory nomoregra...@googlemail.com wrote: Google Streetview has been in Canada since October 09, images from April/May 09. Make that in SOME areas of Canada. The Google StreetView vehicle drove by my place at about 3 in the afternoon on the last day of school last year, but the images showed up around October. Other areas around here showed up much later. I would assume that the Crowsnest Pass area just showed up as Simon is pretty observant. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Data imported from Geobase_Import_2009 and tags
On Mon, Mar 29, 2010 at 9:26 AM, Richard Weait rich...@weait.com wrote: As I understand it, is_in= and addr:city=, addr:state=, tags on nodes / ways / and relations are deprecated in favour of a boundaries. Perhaps a link to a page describing how to define boundaries would be good for the group. http://wiki.openstreetmap.org/wiki/Relation:boundary I think that's what we are talking about. Anyone in the Edmonton area an expert? I need some instruction on how to do all this stuff! The more I learn about OSM, the more confused I get! I think I currently have Strathcona County outlined with the left: right: type of situation. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Buggered up way
Can someone that knows what they are doing have a look at Lesser Slave Lake? It looks like it should be a circular way defining a lake, but something is not right. It is not a circular way. I can't cut it into pieces either. I think there are multiple ways stacked, but don't know how to find out. I clicked on the inspector, and it tells me that there are 79 ways associated with the point I clicked on... There should only be one. http://www.openstreetmap.org/browse/way/45266403 AUUGGG James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Trunk highways.
I was looking at the Canadian tagging page, and saw that they have a list of ways that should be trunk. One of them is the highway from Edmonton to Fort McMurray, so I clicked along the way, and turned it into a trunk rather than just primary. There were also a bunch of problems, due to some unnamed individual merging ways that shouldn't have been. I still need to promote highway 28 to Cold Lake to meet the list of trunk ways. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Highways in Yukon
On Thu, Mar 11, 2010 at 10:43 AM, Tim Francois sk1pp...@yahoo.co.uk wrote: I'm currently working on the Dempster highway with a tracklog I created in the summer, hoping to extend it further north into NWT. The road connecting to the Dempster in the south is the Klondike Highway. However, this paved 'highway' is tagged as a secondary road, whilst the unpaved Dempster is tagged as a primary road. I think the Klondike Highway, and other similar roads in this part of Canada, should be tagged as primary roads. What do others think? This is a problem with the way that highways are tagged in my opinion. The OSM features page sometimes uses physical attributes to describe the roadways. The roadway needs to be tagged for the usage it is designed for. The Dempster Highway is a primary highway linking major centers. (Okay, relatively major centers, relative to barren land...) In OSM terms though, it could probably even be tagged as a trunk as it is a very important road in the area. One has to think about how the final map is going to be displayed. Most of the rendering engines use the classification of the road to determine at what level to display the way. If you classify the Dempster Highway as a track (to fit the description gravel roads in the forest), it will only show up once you have zoomed in so close, that you can't make any use of the map information. I have this type of problem with my GPS. I travel the highway to Fort McMurray quite often. The TeleAtlas database has the primary highway classified as a major road. If I zoom out far enough to see where I am heading, the map screen goes blank. Pretty hard to decide which roads to take when there are none depicted. Once I zoom in close enough to see the roads, I can no longer see my destination, so it is difficult to determine which road I should take to get to my desired destination. Our northern territories don't have a lot of roads, and have a lot of territory. You need to be zoomed well out to be able to see where you are and where you want to be in most cases. The roads between those locations are of major importance if you are attempting to drive between the locales, and as such should be tagged as such. Even if the classification description for the UK suggests that that road classification should be paved with striped lines, and a hard shoulder, in the Yukon, that same classification of road might only be a gravel surface. If it were up to me, classification would denote the importance of the road in the road network, and surface, number of lanes, and other tags would describe the physical attributes of the roadway. My two bits, and then some! James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Highways in Yukon
On Thu, Mar 11, 2010 at 7:18 PM, Richard Weait rich...@weait.com wrote: One has to think about how the final map is going to be displayed. Now that is a little close to tagging for the renderer. Yes, but I've been chastised about that statement before... we are not tagging incorrectly to simply work around the renderer rules, but rather tagging as to road classification importance, which the renderer simply renders differently. If the data stored in the OSM database is not useful to the user, then it may as well not be included. Back to my GPS... the major roads in the TeleAtlas database cause routing problems. The routing routine will take me on a 350 km detour just to stay on highways, rather than a 200 km direct route on what it considers a major road. These major roads are indistinguishable from the highways as far as physical features are concerned. Speed limits are also identical. I'd prefer to have these major roads promoted to the same classification as the highways (in fact they are highways of the same classification as the others)... as a side effect, the renderer in the GPS would end up showing these roads that were previously not visible. Just because the renderer changes the display doesn't mean that I am specifically trying to misrepresent the road for the renderer. The renderers take the tags we use into account when deciding on how to display a way, so it is only appropriate that we also take into account how the renderer will display the tags we are deciding to use. It would be inappropriate to tag a stream as a coastline just to get it to show up on a wide area map... it is however appropriate in my opinion to tag an important major road (read only road) across a large expanse of territory at an appropriate classification level, despite what the rendering engines will do with it. The database and renderers are pretty much married to each other. Without the database, the renderers are useless. Without the renderers, it's pretty hard to visualize the data. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] PR stuff Ottawa Opendata Sat 24th April
On Wed, Mar 10, 2010 at 11:51 AM, Richard Weait rich...@weait.com wrote: Really? With a Google map on their page? Well I hope some OSMers will be there. Hey, some people don't understand the definition of OPEN... just like some people don't understand the word FREE... Here's a free application, you just have to pay to use it more than 3 times, or look at a bunch of advertising, etc... It's all about education! James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Edmonton edits
On Mon, Mar 8, 2010 at 6:04 AM, Sam Vekemans acrosscanadatra...@gmail.com wrote: It looks to be a service road that only city maintenance staff would use. ie. for highway road work, this road serves as a temporary link, and for snow service etc. I haven't been around that area for a while. There's a lot of construction happening which makes access to that area a little difficult. I used to drive through there a bit, but don't go there much anymore. I can probably drop by and have a look to see what they are doing. It also looks to be a service access from the LRT station. That might be what it's used for. I think I recall seeing a new bridge structure there now. Xellos is on my friends list. I'll see if I can get his attention. I have never seen him on this reflector though. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Streets with frontage roads...
Okay, I went for a tour on the weekend, and ran into a place where GoogleMaps had a road that didn't exist. I decided to check OSM, and as expected, the OSM map was more accurate! Anyway, that led to me looking at other roads in the area, and I found this issue. Grandin Road is a 4 lane collector, which I would consider a tertiary, but GeoBase has it as a residential road. On either side of the 4 lane road, beyond a median can be found 2 lane roadways where residents can access their homes, driveways, and park along the street. GeoBase has one access road on one side of the road labelled as Grandin Road, but on the other side of the road, it has no name. All three roads are tagged as residential. I'm thinking that a routing algorithm would not know any better, and might send someone down the side road, rather than down the main throughway. What is the common ground on tagging these things? I would guess that all these roads would get named Grandin Road, as the houses are all addressed as Grandin Road. I was thinking that the 4 lane section get bumped to tertiary as it is a collector road, and as such would be more important than just a plain residential road. The side roads could then stay as residential, or perhaps they would be better tagged at a lower level? Here are some links... This is the area close up on OSM: http://tinyurl.com/grandinosm Here's a streetview from Google so everyone has an idea of what the real world layout looks like http://tinyurl.com/grandingsv Having Google Streetview available is great, as it makes it really easy to share real world views of the area easily. I am constantly amazed at the information we have available these days! James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Google Streetview
On Mon, Mar 8, 2010 at 2:17 PM, si...@mungewell.org wrote: Geobase should have all of the Canadian street names, and we can use those... just need to figure a way to display both to allow easy copying/transferal. GeoBase contains some errors... One road near the area Richard pointed out that Xelloss was working on was labelled at Saskatchewan South Drive North-west by GeoBase. This stuck out, as it didn't look right from my knowledge of the area. The rest of the roadway entered by a local user agreed with my recollection, so I changed the name to match, Saskatchewan Drive South North-west... Yeah, that's proper... I was poking around the area looking to see if the new ramp was in the Google Streetview maps, and happened to see a streetsign with the same road name. This is what triggered the question. I guess that also brings up the question, can I point you at a Google Streetview to discuss issues such as the Grandin Road issue that I posted previously. We aren't using Google data to map the area, or anything, but just consult... Simon. VA6SDW as we seem to be including call signs. Not everyone, just the cool guys... I include mine, as I use it as my username on OSM... ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] vreimer again
On Sat, Mar 6, 2010 at 8:35 AM, Adam Dunn dunna...@gmail.com wrote: 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. Yes, indeed... I should have stated more correctly: Now I've noticed that vreimer has caused a problem with Lesser Slave Lake... In an opensource project like OSM, many hands make light work, but those hands need to be adding to the quality of the product, not just quantity. vreimer is indeed prolific, but at the same time seems to be introducing quite a bit of less than stellar quality information. It would be in everyone's best interest to steer this individual towards more helpful editing of the OSM data. It just gets frustrating when you find data that was previously accurately representing the real world has been rendered less than perfect, and that almost all of these edits all have the same username associated with them. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] vreimer again
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
Re: [Talk-ca] What Google Copying?
Perhaps we can find this vreimer another hobby. I have seen his handy work in my area as well... as a matter of fact he's just poked around the area within the last few hours... He's screwed up some road names and other tagging in the area. http://www.openstreetmap.org/browse/way/32832523 Here he's merged a township road and a range road, and another township road, then split them... It makes the tagging all screwed up for a number of the ways. I don't see how this one individual can have intimate knowledge of so many diverse areas of the country. While adding material to the OSM database may be viewed by some as constructive, adding information from copyrighted sources is destructive. While we can't see a pattern in this users behaviour, it is difficult to believe that the user is familiar with all of the areas that he/she is editing. Merging ways, and leaving behind a mess is indeed destructive. If this were a new user that was just learning, and making tentative edits, and causing small scale issues. It would be easy to believe that they were doing the edits with the best intentions. We would attempt to reign them in and educate them to help them learn the ropes. This individual however is probably one of the most prolific users I've run across, excepting the mass imports done by limited individuals. Is there not some way to yank back on this user's chain and slow him/her down a little? Let's at least find out what they are up to, where the data is coming from, and maybe help educate them a little bit. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Transient roads
Okay, I know we talked about this before, but I can't find an answer in my old email. I'm mapping a road that only exists during the winter months. How do I tag it? Access is limited by season, but access tags seem to be aimed at who can access, rather than when. There are a couple references to winter roads in the BC, Alberta, and Manitoba wiki pages. Does anyone know of any examples of roads with access restrictions based on time/season? James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Attribution (Previously Modifying GeoBase Ways)
On Mon, Jan 25, 2010 at 12:24 PM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Last november, you raised some issues about GeoBase and Canvec attribution rules. The attribution that can be found at http://wiki.openstreetmap.org/wiki/Attribution conformed to the GeoBase and Canvec licences. So, from RNCan perspectives, you may remove the attribution tag whenever you want since the attribution is already specified in the OSM wiki. That makes much more sense than tagging each entity that is derived from GeoBase and Canvec data. An overall attribution still fulfills the attribution requirement, without having to worry about which specific portion of the data is derived from which source. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Modifying GeoBase Ways.
On Mon, Nov 16, 2009 at 9:47 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: 1- replacing ways I don't know the accuracy of a Blackberry but using a garmin gpsmap 60csx (waas on), I sometime get a 10 meters offset between tracks for the same way! I can not speak to the accuracy of the GPS technology in the Blackberry. I do not have any sub-centimetre accuracy equipment with which to compare. So, be cautious before deleting a way that doesn't match your gps track, unless you have multiple tracks that confirm the way is wrong. Multiple tracks with errors only create more ambiguity. There is no guarantee that having multiple GPS tracks will give you an accurate estimate of the actual location of the road being tracked. It is possible that all tracks are offset from reality in the same general direction, rather than being equally distributed, creating an accurate average value. The only way to confirm that the way is incorrect, is to use sub-centimetre accuracy professional level GPS equipment, which is not only out of my reach, but probably most of the people involved in the OSM project. For your information, accuracy of geobase/canvec road segments over Alberta is usually within 2-6 meters. Yes, the key word being usually. However, even within those limits, the GeoBase way can depict a way that does not reflect reality. I could take 5 points that describe a 5 pointed star, and draw that star in the way that describes a road. If all these points are within 6 metres of the actual roadway location, I could argue that my way is an accurate depiction of the roadway is just as accurate as GeoBase... Yes, this is ridiculous, but simply keeping nodes within 2-6 metres of reality does not necessarily mean that the way describes reality. I included links to the GPS track, and also the GeoBase way. I can assure you that the sharp corners, as well as the 90 degree zig-zags do not exist in the real road. The GPS track does not significantly move the roadway from where GeoBase describes it, but rather smooths out the low resolution hand entered track, and removes aberrations in the GeoBase way that do not exist in reality. 2- using geobase/canvec attributes If you consider that the way should still be replaced with your gps track, then it is yours! I dont see why geobase/canvec stuff would be kept. The position of the nodes describing the way, and the way itself would be from my GPS data, and would become property of the OSM project. However, the tags imported from GeoBase would still need to be attributed to GeoBase according to the terms of use from GeoBase. If I change every tag, but keep the GeoBase UUID, do I need to keep a GeoBase attribution tag because the UUID tag belongs to GeoBase. Restrictions imposed by attribution rules makes this a complicated issue. Information in the OSM database which has been entered by another OSM user does not bring up these issues because there's no restrictive attribution issue to deal with. I can keep any tags I feel fit to keep. If you keep the original way but change lanes=2 for lanes=1.5 (let say lanes=1!), I would then keep geobase/canvec stuff. I thing that the osm database will keep a record that you had changed the value of the lanes tag. The issue is that we NEED to edit the GeoBase ways. Changing the location of even one node in a way could really be considered making a new way. We could make a bot that goes out and move a node in each way slightly, and then drop all the GeoBase attribution tags. I understand that the changes made in the OSM database may end up being used by GeoBase to find changes that might be integrated back into the GeoBase database. As for making lanes=1, that would be just as incorrect as the current lanes=2. Lanes=1 would imply that opposing traffic would not be able to pass without one vehicle leaving the road completely, or both being half way off the road. This roadway is wide enough that a regular passenger vehicle has room to move laterally about 1/2 a lane width without leaving the road surface. A single lane width would in my opinion mean that there is very little room for lateral movement before leaving the road surface. I am told over and over again that OSM should tag what's really out there, and not worry about fitting information into existing pigeon holes. If GeoBase does not support a road width of 1.5 lanes, this should not restrict OSM from using such a value. By the way, lanes=2 seems to be a kind of default value when data source is Orthoimage. Yes, that would make sense, since it is impossible to know for a fact the actual width of a roadway from an aerial image. That's where the feet on the pavement are important. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Modifying GeoBase Ways.
Okay, I need some advise... I drove a nice little twisty back road today, and captured it with my Blackberry. I have the trace uploaded to OSM, and have looked at it in relation to the GeoBase way. GeoBase Way http://www.openstreetmap.org/browse/way/31847379 GPS Track http://www.openstreetmap.org/user/VE6SRV/traces/566355 The GeoBase way has an acquisition source of Orthoimage, and it is a little less than a perfect representation of the real way. My GPS track would appear to do a better job of representing the actual way. If I were to replace the existing way with a copy of my GPS track, what should I do with the tags? Do I copy all the tags over? I would plan on replacing the existing way with a track made from my GPS trace. highway:tertiary, is_in: Camrose County, name:Range Road 204a, surface:unpaved will all stay, as they are all still valid descriptors. Should attribution stay? The way is no longer from GeoBase, but the tag information would be. Same for the source tag... some information is from the Geobase_Import_2009, while some is not. geoBase:acquisitionTechnique is no longer Orthoimage, but should this be replaced by a tag stating that it is now GPS tracked? Do I leave the geobase:datasetName:NRN:Alberta, or should that go? I think the geobase:uuid tag should stay to allow future identification against the GeoBase database. lanes:2 probably needs a tweak. The twisty part of this road is not what I would consider 2 lanes. Meeting a regular sized vehicle would require both vehicles to nearly stop, and pass each other with two wheels in the ditch each. I would call this at best 1.5 lanes wide. So, what to do, what to do??? James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Ftp site for Canvec product (.osm)
On Fri, Oct 30, 2009 at 10:31 AM, Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca wrote: Actually, using the site for GeoBase datasets is not possible yet. We have made that site available because: - the Canvec product is under our responsibility (NRCan). - we are pleased to help the community using it. That was the reason I asked... I figured that the space would be limited to data related to NRCan. Best to know that up front so that people know what data can be stored on the site. Thanks again for making the space available. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] GeoBase to OSM converted files
Okay, 'splain this to me nice and slow... Is there a place where the GeoBase to OSM files are stored? Not the files that were used to upload the Geobase roads, with matches excluded, but a full road database. This is to be used as Sam suggests, loading it as a layer in JOSM, and then using it to check the current OSM data against, merging in the best of both worlds into the OSM database. Using the full GeoBase file would allow people to make the informed decision on how to connect imported GeoBase ways to existing OSM ways, align OSM ways that may be not as precise as GeoBase ways, and copy attributes over. Only tiles that contained road matcher exclusions would need to be available. If the tile was processed without any road matcher exclusions (no OSM data existed before the import), there's no need for anyone to compare, as imported will match GeoBase exactly. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Users in Ottawa and Geobase
On Thu, Oct 29, 2009 at 8:24 AM, Gerald A geraldabli...@gmail.com wrote: I think Sam was hinting at wholesale deletion and replacement, rather then editing permission. That's the problem, hinting at an idea is not an accurate statement. Sam (and others) have made a number of generic statements, when they are talking about specific situations. This leads to issues where people take these generic statements, and interpret them to mean that one can not make changes to the OSM map. We need to ensure that people coming into the project understand why certain statements are made, and why these decisions are part of the OSM unofficial policy. Correcting wrong roads is definitely encourages, but the OP suggested simply blowing all of Ottawa away because he found some areas of dubious value. My take on Sam's suggestion was that if the OP was sure that it was all bad, he should double check with the people that did the work before simply blanking the slate. We're basically all on the same side of the arguement that wholesale deletion of data to make way for a bulk import is a bad idea, except for John. There is very little to be gained by this action, but there is a HUGE potential for a lot of serious negative effects. I think you do agree that correction of the data is the way to go, and I think that Sam could have been a bit clearer about correction rather then delete and replace being the preferred method of tackling this. Exactly. We need to be very clear when trying to descibe policy. Just saying that you are not allowed to edit OSM data after it is entered is blatantly wrong. As I have described a number of times already, editing is encouraged, but wholesale deletion and blind bulk importing is discouraged. Wiping out Ottawa, and importing GeoBase data will lose thousands of hours worth of work that is not included in the GeoBase dataset. Wiping out just the road network and importing GeoBase still leaves as much work to realign all the rest of the data that was associated with, or based upon the OSM road network. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Number of Mappers in Ottawa mail got munched
On Thu, Oct 29, 2009 at 1:25 PM, Richard Degelder rtdegel...@gmail.com wrote: A quick look at the number of mappers that have contributed to the map of Ottawa shows that there are a lot of individuals and that excludes the rather minor contribution from the GeoBase import. The source of this data can be found within ITOWorld http://itoworld.com and look at the data for OSM. The site requires registration but does provide a great deal of data about changes to an area and the data within that area. You can also get a history of activity on an area within Potlatch... http://www.openstreetmap.org/history?bbox=-75.7845,45.3813,-75.5994,45.4411 Here's a little of the latest activity. ID Saved atUserComment Area #2981665 October 29, 2009 15:51 Sensei Marc Ottawa lock 29 -75.703,45.384,-75.678,45.428 #2978903 October 29, 2009 06:34 acrosscanadatrails fixing up a little bit of Ottawa, ON-75.702,45.421,-75.696,45.423 #2978586 October 29, 2009 05:11 nmixter (none) -122.202,37.750,24.896,47.190 (big) #2978379 October 29, 2009 03:04 Sensei Marc Ottawa locks -75.701,45.385,-75.676,45.427 #2978371 October 29, 2009 03:00 Sensei Marc (none) -75.767,45.385,-74.314,45.653 (big) #2978094 October 29, 2009 02:11 Mirko Küster fix -86.468,43.049,14.028,53.055 (big) #2973473 October 28, 2009 15:06 Sensei Marc (none) -75.767,45.385,-74.315,45.653 (big) #2973439 October 28, 2009 15:03 Sensei Marc (none) -75.699,45.427,-75.697,45.427 #2965045 October 27, 2009 13:10 Johnwhelan added footpath-75.702,45.425,-75.688,45.433 #2951962 October 25, 2009 22:20 adjuva Korrekturen an highway-Tags. -80.524,42.499,17.971,52.529 (big) #2951120 October 26, 2009 01:10 adjuva Korrekturen an highway-Tags. -137.389,-35.639,157.368,61.927 (big) #2949317 October 25, 2009 20:49 adjuva Korrekturen an highway-Tags. -79.947,-0.988,13.449,54.923 (big) #2939676 October 24, 2009 17:50 daswaldhorn Grenze USA repariert -180.000,17.795,180.000,61.288 (big) #2939376 October 24, 2009 17:20 daswaldhorn Grenze USA ergänzt -180.000,-2.652,180.000,77.768 (big) #2938512 October 24, 2009 15:51 daswaldhorn Grenze Kanada repariert -129.809,41.526,-63.249,49.769 (big) #2937063 October 24, 2009 15:42 Andre68 Fixing coastline error -134.671,39.331,-8.387,78.837 (big) #2932406 October 23, 2009 20:47 Sensei Marc (none) -75.712,45.417,-75.712,45.417 #2931994 October 23, 2009 22:32 Andre68 Fixing coastline error -128.104,-28.364,155.181,78.811 (big) #2931722 October 23, 2009 20:04 Sensei Marc (none) -75.701,45.367,-75.659,45.443 #2931293 October 23, 2009 19:09 Sensei Marc (none) -75.852,45.345,-75.670,45.427 2930249 October 23, 2009 16:23 Sensei Marc Test bridge -75.699,45.427,-75.697,45.429 #2929187 October 23, 2009 14:01 Sensei Marc (none) -75.697,45.389,-75.677,45.397 #2928997 October 23, 2009 13:33 Sensei Marc (none) -75.696,45.393,-75.696,45.394 #2928982 October 23, 2009 13:31 Sensei Marc (none) -75.697,45.394,-75.686,45.397 #2923153 October 22, 2009 17:57 Sensei Marc Ottawa locks2 -75.701,45.418,-75.680,45.428 #2921693 October 22, 2009 14:31 Sensei Marc (none) -75.703,45.423,-75.695,45.427 #2921621 October 22, 2009 14:30 Sensei Marc lock test-75.698,45.427,-75.697,45.429 #2921258 October 22, 2009 13:38 Sensei Marc HogsBack-75.700,45.384,-75.700,45.385 #2918052 October 22, 2009 05:27 Andre68 Fixing coastline error -115.298,11.892,103.047,62.188 (big) #2917864 October 22, 2009 03:34 Sensei Marc ottawalock -75.703,45.366,-75.677,45.427 #2917857 October 22, 2009 03:26 Sensei Marc (none) -75.706,45.370,-75.699,45.385 #2917723 October 22, 2009 03:04 Sensei Marc (none) -76.296,44.686,-75.573,45.517 (big) #2917528 October 21, 2009 23:59 robhedrick BBOX:-95.31,37.26,-73.88,45.19 ADD:0 UPD:59 DEL:42 Removing duplicate nodes from the last 37 in NA - only found a few.-96.812,36.947,-73.884,45.983 (big) #2917466 October 22, 2009 00:57 Sensei Marc (none) -75.919,45.169,-75.614,45.409 (big) #2916957 October 21, 2009 23:13 Nedim(none) -81.535,6.854,28.254,47.677 (big) #2916929 October 21, 2009 23:18 Sensei Marc blackrapid -75.712,45.207,-75.665,45.382 #2916754 October 21, 2009 22:49 Sensei Marc rideau north of clowes -75.935,44.946,-75.607,45.434 (big) #2916522 October 21, 2009 21:05 Ropino sport -165.358,-17.542,28.381,60.601 (big) #2914679 October 21, 2009 19:53 Sensei Marc (none) -75.708,45.329,-75.677,45.427 #2911412 October 21, 2009 12:51 Ævar Arnfjörð Bjarmason Reverting changeset
Re: [Talk-ca] Number of Mappers in Ottawa mail got munched
On Thu, Oct 29, 2009 at 2:32 PM, John Whelan jwhelan0...@gmail.com wrote: So it looks as if we'll just have to wait until the mess gets straighten out. Do you have any idea what happens if we ALL take that attitude? There is no them in OSM, it's an us type community. I found two on OSM, one wasn't active and the other, Marc Sensei, didn't respond. Have you given him time to check his incoming mail and respond? It is easy to miss items sitting in the OSM inbox, and if the user uses JOSM or another offline mapping method, they might not log onto OSM for extended periods of time. My premise of just dropping in the Geobase data was based on the fact I could only identify two other Ottawa mappers. So it look as if not much had been done so far especially on the GPS side. Thus doing the job quickly would save any more effort until we ended up with the clean map. Just for reference, here's what the OSM map looks like when there's not much being done in an area. http://www.openstreetmap.org/?lat=65.2780lon=-126.7932zoom=17 This link is for Norman Wells, NWT. There are no local mappers in the area. If you zoom out, you'll find the MacKenzie River which was created by a JOSM Lakewalker plugin on Feb 10, 2009. If no one works in the area, nothing happens. The Ottawa area looks like it has much more information than Norman Wells, so we have to assume that the OSM community has actually been working in the area. History information backs up that assumption. Then the idea was given a decent set of roads to leverage some of the groups I come across on the planning side to add tags. I don't think the Ottawa OSM map is mature enough to suggest it to them at this point in time with its missing segments of roads etc. Perhaps in a couple of years when its straighten out. It may never become mature enough then if everyone waits for magic to happen. Bye the way someone made a comment that I'd only mentioned two items being over 100 meters off. It's now at least three and they were off in different directions. All were in locations with clear sky above, I assume they were satellite tracings. Have you corrected these items? If not, then when you look at them in a couple years, they might still be located in the wrong place. Do you yet understand that OSM is a community project, and it takes investment by the community to create a usable product. If you don't want to invest the time and effort to help further the project, then you might just want to look at investing your cash into a commercial mapping solution. Nothing is free... OSM espouses to be free as in speech, but someone has to invest the effort in making the noise... by helping to map the area, you are making the noise that others can listen to. If you sit on your hands and wait, it takes that much longer for everyone else to produce a product for your consumption. Perhaps your professional background is getting in the way of understanding that not everything in the world is a product that is produced by someone else, and simply purchased when needed. Sometimes you have to roll up your sleeves and help yourself. I found a footpath that you added to the map, so I know that you know how this works. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Users in Ottawa and Geobase
On Wed, Oct 28, 2009 at 7:19 PM, john whelan jwhelan0...@gmail.com wrote: My objective at the moment is to get something sane that can be used by various groups in the city with GPS devices to tag trees, heritage buildings etc. Leverage those people with geographic interests... If they go out to tag a tree, and see that the road is out of alignment by a couple metres, then show them how to enhance the map. That's what OSM is all about, getting the community involved in making the map. As opposed to Google, Mapquest, TeleAtlas, or whoever else, here at OSM, you as a user can make the map, not just look at it. Those who are interested in heritage buildings can put a POI in place, or even better, draw in the building outline. These aren't quite heritage buildings, but rather commercial buildings in a shopping complex, but the concept is the same. http://www.openstreetmap.org/?lat=53.4480357170105lon=-113.482160568237zoom=15 James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Correcting Geobase_import_2009
On Sun, Oct 25, 2009 at 10:43 AM, john whelan jwhelan0...@gmail.com wrote: What appears to have happened is where the data has been merged roads that are in the geobase database no longer connect to roads that have been put in via potlatch. I think the end point is dropped. There is a discontinuity between the GeoBase data, and existing OSM data. The script that was used to determine which Geobase data to import was designed to stop short of the OSM data. Since the OSM data does not match exactly to the GeoBase data, it was impossible to have the two seamlessly merge. It is up to the OSM users to stitch the two together. The GeoBase data allows the OSM community to leverage the massive amount of data available in the GeoBase database. The older potlatch roads do not have the same depth of tags as the geobase data. This sounds like you believe that the quantity of tags associated with a way some how infers higher quality data. One can not automatically assume that the GeoBase data is of higher quality than the OSM data simply because there are more tags associated. In some cases, the positional accuracy of the GeoBase data is better than OSM data, but in other instances, the OSM data positional accuracy is better than GeoBase. It all depends upon the amount of effort expended during the input process. Not only that but roads that run close to the old roads appear to be deleted for the section close to the potlatch inputted roads. That's the GeoBase input script trying to match GeoBase roads to existing OSM roads. When they are close enough in geometry, the GeoBase roads get dropped. Preference is given to OSM data over GeoBase because the OSM data has been provided by the OSM community. Real people have invested many hours of their time to input their data. GeoBase data is being automatically input by a machine. We need to respect the OSM community investment over the automated imports. Oh and my WAAS enabled GPS thinks at least one Potlatch inputted road is in the wrong place. Yes, that can be very true. Some roads have been input by simply tracing low resolution imagery, and the resultant roads can be fairly crude. As an OSM participant, you can help improve the database by converting your GPS traces to roads. You can also use the real intelligence built into the human brain to make informed decisions about how to merge the OSM and GeoBase data into the best map database possible. My personal view is that we should go with the geobase database and see if we can layer on tags etc. That way we can update the database from time to time by replacing the entire geobase data layer. Of course you are entitled to your opinion, but options were discussed in this forum, and decisions made on how best to go about merging the OSM and GeoBase data. From those decisions, the scripts were created, and import activities started. I think you will find very little support for keeping the GeoBase data as a pristine import layer that can be changed out en masse. This would limit the amount of mapping that the OSM community could do in Canada. We would be limited to only adding data that is not maintained in the GeoBase database. There would be no ability to correct or modify the GeoBase road database as any changes made would be wiped out by the next en masse GeoBase layer import. The reason for the GeoBase import is to simply add a large amount of fairly accurate road data to an area of low population density. in Canada, we have a huge road network, and very few people to import that data. By importing GeoBase data provided by the government, we get a large amount of data, but we still have the capability of modifying that data. I think OSM can add value in Canada basically by tagging and enhancing data already there, if a client can get geobase data elsewhere that actually has connecting roads and complete roads they may prefer that to OSM where the data quality isn't so consistent. Here you are absolutely correct. OSM is all about providing the best FREE map data for the world. Anyone is free to use the OSM data, or they can go elsewhere to find the data they require. However, it is not possible to upload changes, corrections and additions to the GeoBase data as an end user. It is possible to do these things as an OSM end user. The GeoBase import was simply a shortcut implemented to get a large quantity of data into the database, and now it is up to the OSM community to manipulate that data as they see fit. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Correcting Geobase_import_2009
On Sun, Oct 25, 2009 at 1:39 PM, John Whelan jwhelan0...@gmail.com wrote: OK accepting what you say is there a way to identify where an old OSM road was so that some one can go back and clean up the new geobase added data? Actually it's more like the opposite. The old OSM road gets priority, an OSM road will not get deleted in favour of a GeoBase way. The scripts are designed to not import any GeoBase data that may interfere with existing OSM data. On the clean up side is there an easy way to copy the tags on one section of road onto another? For example when I extend a geobase road up to the old OSM road I'd like to have the same tags as the other sections of the road. In Potlatch, you select an existing way, then select the new way, and press 'R' this repeats the tags from the first way to the second way. However, you don't want to copy all the tags from a GeoBase way, as the new way would not be attributed to GeoBase, since you are creating it. You also should not copy the GeoBase UUID to the new way as it is a different segment that would have a different GeoBase UUID. At a quick glance I can see at least seven sections that need to be added back in within 600 meters. In an area where a single road has been mapped through a neighborhood, every intersecting road will need to be attached. My personal view is the amount of effort to clean up the data required is probably often going to be greater than the amount of effort put into creating the OSM map in the first place. If you are looking at a very small area, it might be easy to make that assumption. Let's think about it though. Imagine a main roadway running past a horseshoe shaped side road. The main road is in the OSM database, while the side road is imported from GeoBase. Now all that has to be done, is to connect the GeoBase way to the OSM way. If you don't use the GeoBase data, you'll need to physically collect the path of the side road with a GPS, import that into the OSM database, and convert it to a way. You'll also need to collect the rest of the physical attributes for the roadway. Yes, some areas have high resolution imagery, but most of Canada is only covered with very low resolution imagery. Now think about having to go out and collect that GPS data for millions of miles of roadway across Canada. I spent over $300 dollars on fuel, and 3 days driving just a portion of a few highways into Northern BC, capturing that data on the GPS. I added this data to the OSM database. There's no one else working on roads in the area, so it's up to just a handful of people to try and map the millions of miles of roads in this country. I tracked thousands of kilometres of highway in the year before GeoBase became available, adding it to the database, or replacing low resolution imagery tracings. Those highways still exist in the OSM database, describing the route of the highways in higher resolution than the GeoBase data does. I am grateful that the time and effort invested in tracking and importing that data was not thrown out in favour of an automated GeoBase import. The GeoBase data gives us just about every road in Canada at a very low cost. In areas where there are OSM users, the data can easily be modified, removed or replaced, just as it can for any other type of OSM data. On the tag issue, its not simply a matter of the quantity of tags means higher quality data but if the tag doesn't have a value then the information doesn't exist. For example Merkley Drive geobase import has a tag saying 2 lanes. Charlemange has four lanes but no tag giving that value in the potlatch input. I've learnt over the years with databases that some idiot somewhere will invariably want to use a tag like this and not realise that some roads don't have a value. It is unfortunate that the geobase tag data can't be dragged over and associated with the OSM roads. It is fortunate that ANY user can add a tag to any OSM road. The O in OSM stands for Open, meaning that anyone can add tags to the ways in the database. If you want Charlemange to have a tag that says lanes=4, get in there and add it. Is there a geobase identifier on a road that could be added manually as a tag so that a script could drag in the rest of the tag values? This would probably mean having a pure geobase OSM map somewhere that could be used to pick out these values. You would like to have some type of tag that says Import please? When the import scripts are run, they convert the GeoBase data into OSM compatible data. They can be used to create 3 different types of data. The usual is a database of GeoBase roads that are NOT included in the OSM data (as determined by the roadmatcher script). They can also create the inverse, a database of roads that are duplicates of roads in the OSM data. They can also simply create a full GeoBase database compatible with OSM. You are probably talking about having a layer that is the full GeoBase database, so that you can see
[Talk-ca] Editing GeoBase data
We did a bulk import of GeoBase data provided by the Canadian government a while ago. I've been pondering and procrastinating on how to go about modifying the data without destroying it. The GeoBase import has a lot of information included with the ways. One piece of information is the UUID, a unique identifier for that particular way. We are told that the UUID needs to be kept with the way for future cross reference for future updates, as well as so that the Canadian government can find places where the OSM community fixes GeoBase problems. So, there are a number of issues that I am struggling with... 1) Modifying a way to add more detail/realign to reality. This one is easy, as you won't be destroying any data, only adding/moving nodes so that the way represents real world data better. 2) Deleting a way that does not exist anymore. Not too hard here either, if new construction has destroyed an old way, it needs to be removed. 3) Adding new ways. New construction, or areas missed by GeoBase need to be added. 4) Modification of existing ways that may destroy or highly modify data. This is where the quandary occurs. Things like chopping up a way to add bridges, or to realign an intersection, or other such modifications... do we just go about our editing with little regard for the existing data, or should we attempt to keep as much GeoBase data as possible? If we are to keep as much data as possible, what's the procedure? Maybe I have answered my question with 1, 2 and 3 above. Maybe I keep part of the existing way where it describes the way properly, or modifying it so it does, delete the rest of it, and then treat it all like new construction. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Editing GeoBase data
On Sun, Oct 11, 2009 at 12:38 PM, Sam Vekemans acrosscanadatra...@gmail.com wrote: Maybe (James) it doesn't answer your question, but should help the imports@ list understand more what's going on, as well as whoever is following along on the talk-ca list :) You didn't even come close to the subject of my query. I wasn't asking how to import data, but rather how to edit the imported data without destroying the GeoBase tags. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Can-Amera border, states and provinces.
On Wed, Aug 26, 2009 at 6:39 AM, Lennardl...@xs4all.nl wrote: As you guys in the North Americas might will probably already have noticed, the main mapnik style now shows state boundaries, and also labels them either by ref or name, depending on zoom. I noticed that yesterday... I'm much happier now, Canada is starting to look like it has some mapping going on. It's no longer a blank slate. Of course now that the borders are rendered at a level when you can see the data, I see that there are multiple borders around Alberta. Every time we make the data in the database visible, we find more problems! Oh well, it was an easy fix... I had a look and found that it was some lunk-head by the user name of VE6SRV that put imprecise borders in place... Just deleted them from the database, and now all should render nicely. Oh yeah, there's only one North America... even if those silly people to the south of us think they can label themselves as if they are the only inhabitants of the Americas! So, while poking around, I notice that again we have these node remnants... big old green dots along the way that don't describe anything. We've seen this quite often before, mostly part of mass imports. The lakewalker script left these behind on shorelines, the GeoBase road import left them as well. Now again they are here on the border import. Do we need to look at fixing the way the automated imports happen, or fixing the import routines to be able to handle the speed at which the data is thrown at it, or do we just live with it? It also looks like Daniel Patterson was importing the continental divide as well. Lots of nodes, but it doesn't look like a way was described. Is there a tag for the continental divide? I did a quick look in the wiki, and didn't see it. They might have a tag in the watershed project. The continental divide is a feature that is described on a lot of maps. Here's where to look: http://www.openstreetmap.org/?lat=53.7998lon=-119.977zoom=13 James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Hey, look! State / Prov borders!
On Wed, Aug 26, 2009 at 8:23 AM, Richard Weaitrich...@weait.com wrote: So we USA-ians have a few nodes to move for place=state; Ooh, yuck... the state name labels end up in the wrong spots... missed that. Washington looks like it has two labels. I had a look at Canadian labels and they look okay except for Nunavut. The NU label is good when zoomed out, but I don't see the name Nunavut when zoomed in like the rest of the provinces/territories. We're missing borders at different zoom levels, but that's probably going to sort out as the tiles are rendered. Canucks, do we have to clean up some border artifacts? I did some housekeeping along the western border of Alberta, and also along the 60th parallel already. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
