Re: [Talk-ca] ON prefix on Ontario highways
On Sat, Feb 28, 2015 at 9:25 AM, Jonathan Crowe 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 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] Confusing CanVec import: Elliot Lake
On Wed, Aug 27, 2014 at 8:25 PM, Stewart C. Russell wrote: >> As a rule I don't remove any existing data, unless the data >> is duplicated and then I try to pick the best one. > > But deleting my tracing of Horne Lake was okay, though? > http://www.openstreetmap.org/way/77445326/history As Andrew stated, existing data usually stays. Obviously a mistake was made. We're all human. > You should have bumped the way version, given that there was a lake > already there with the same name. So which ever source has the best resolution should be the one that stays, or perhaps a merge of the best data from both... OSM is a living entity that changes. Stewart, you've found an area of concern, and Andrew is responding. You can't get much better than this. > But it exactly corresponds to these weird square boundaries that are all > over the area, like this way: http://www.openstreetmap.org/way/259481614 > - so you broke a lake that was already there. So have a bit of a look into what CanVec is, and how the data has been sliced up and provided to OSM for consumption. You'll immediately understand what all these weird square boundaries are. Look just about anywhere in Canada where CanVec imports have happened. You'll find these artifacts all over. > Can't you run a simplification algorithm for closed polygons to get the > count down to something sensible? So, using that logic, should we take your Horne Lake closed polygon and simplify it down to 20 points? Okay, not entirely sensible, but then who defines sensible? Large complicated polygons abound in the OSM database. They just need to be dealt with appropriately. >> Just a thought could the missing data be a result of some user who did >> not accept the new terms of service > > No, the edits were me, or an earlier import from geobase_stevens from 2009. > > Please, as Daniel suggested, clean up your mess. And of course, thank you to both of you for all the work you guys ave done in adding to the OSM database. Everyone's contributions are appreciated, but occasionally we bump into each other. This forum gives us the perfect place to say "Oops, excuse me... sorry!" -- 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
I understand your reasoning, but there are some flaws in the logic. On Wed, Oct 2, 2013 at 6:23 AM, James Mast wrote: > 1. I don't have access to the Canvec data that includes the road names. If one person has access to the data, everyone does. If the data were not available, no one could import it. You might just not know where to look. > 2. I didn't know if somebody was planning an import in that area. This is reasonable, but then how long have you been waiting for someone to do something? When we all wait for someone else to do something, we can wait a long time. > 3. I tend to stay out of areas that I'm not really failure with in Ontario > as I've never been that far North in Ontario (Canada Wonderland is about as > far as I've ever gone). Yes, it helps to be familiar with areas that you are importing, however we don't have enough OSM mappers in Canada to be able to have the luxury of having people familiar with each area importing those areas. > So, in other words, I wanted to leave it to somebody that knows the Canvec > data better as I've never done an import. And still you have never done an import, so you're safe. The next place you would like to see added to OSM, you can use the same reasoning. I'm not trying to pick on you specifically, but rather just point out flaws in the rationale behind NOT being a participating member in the OSM community. Only your second point is reasonable... making sure you are coordinated with the rest of the community is a good thing. We probably have an awful lot of people sitting on their hands saying "I don't have access to the data", and "Someone else will import it", and finally "I've never done it before". That's the wrong attitude to have on a crowd-sourced project like OSM. Get in there, learn where to get the data (BTW, OSM is not sole sourced from CanVec), learn how to edit the map, and help everyone gain access to a better map! I know I hear a lot of people complain about the quality of OSM maps in other projects that use OSM maps, and I go through the same "lecture" with them. If you don't like what you see on the map, get in there and get your hands dirty. -- James VE6SRV And yes, I've been sitting on my hands for a long time as well, so I'm as guilty as you. ___ 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 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 7:57 PM, Samuel Longiaru 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] Routing tool for openstreetmap.ca?
On Mon, Apr 22, 2013 at 3:33 PM, Samuel Longiaru 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] My Android tablet
On Sat, Apr 6, 2013 at 1:55 PM, Harald Kliems wrote: > thanks for sharing this! It's kind of obvious once you've read it but > it would have never occured to me to use your technique. It's called thinking outside the box... (Hee Hee) -- 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 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 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 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 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 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] Aerial drones helps geomatics
On Mon, Feb 25, 2013 at 6:52 AM, Clifford Snow wrote: > Aerial drones for OSM is very intriguing. For example mapping new > construction and areas not covered by Bing images or where only low > resolution images are available. I wonder the spec would be for a low cost > drone? Interestingly enough, on another group that I belong to, our American friends are being faced with many states attempting to enact legislation to make it illegal to take pictures, or capture any other part of the sound, electromagnetic spectrum, or even odours via an unmanned aerial vehicle. We fly high altitude balloons with cameras onboard capturing wonderful images of our planet, and if the legislation goes through in these states, it will become illegal to do so. What happens in the USA usually filters over to Canada sooner or later. -- James VE6SRV http://bear.sbszoo.com/sable/sable3.htm ___ 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 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] Aerial images
On Wed, Jan 9, 2013 at 12:27 PM, Colin McGregor wrote: > > Has anyone here looked closely at Public Laboratory's balloon kit > (http://publiclaboratory.org/home) or other sources for getting good > high resolution aerial images? Reason I ask is that Toronto is well > served by quality aerial images, but some of the spots outside Toronto > (that I am interested in) are very poorly served, and well, I was > wondering if anyone had hands on experience with some of this stuff? I've flown a number of high altitude balloon projects, with digital cameras on board. These are free floaters headed to >100,000 ft, not tethered balloons. We have cameras on board taking images that could be used for this type of work. I have not tried stitching images together to georeferenced locations yet. One of the concerns I have is the distortion involved, and parallax errors. You need to fly fairly high in order to get a good shot looking down, and require a decent resolution camera to gather enough detail. You can set the camera for a medium level zoom to get higher resolution, but you get smaller areas in the image. Another issue is ensuring that you are not flying a payload that endangers air traffic. There are rules governing the maximum size of a balloon, the maximum payload weight, maximum strength of the tether line, and maximum altitude before you get into controlled airspace. For our free flying balloons, we have to stay below 115 cu ft of gas, and due to that limit, we can only lift about 4 lbs of payload. You can get some pretty decent cameras with time lapse timers which are pretty light. If your tether breaks, say goodbye to your camera. If your balloon bursts, you'll want a parachute. You probably don't want to drape the tether over power lines either. Lift gas is also a concern. Helium is in short suppply, and if you do manage to find someone who will sell to you as a new customer (good luck), you'll be paying an awful lot. A K tank is probably over $300 now. You can fly hydrogen with a tank costing about $60, but you need to observe good safety precautions due to the flammability issue. Now, given all that, you can still get out there and play... Another option to look at is flying a kite. You don't have to buy the expensive balloon and lift gas, but you do have to have sufficient wind. Search Google for Kite Aerial Photography. There's lots of links out there. You can achieve the same with a kite as you can with the balloon. Another option is to fly an aircraft and take the photos yourself. I have a PPG that I can fly over an area and take photos manually. Again there are limitations there. Again, you have to stay out of the restricted airspace where the big planes fly, a minimum altitude over a built up area is required, and we're not allowed to take photos for commercial purposes... OSM isn't commercial though... Trying to photograph a city using these concepts is probably not a good idea, but any of them could easily be used to photograph smaller towns and villages where Google and Bing tend to ignore. I might have to start overflying the towns around here next year and grabbing aerial images for OSM! -- 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 2:02 PM, nicholas ingalls wrote: > I have to believe that that the process I used would be correct or else > sites like geofabrik compare would be in violation of the license. If I had > used the fredericton data to create a new offset I could see there being a > problem but this was not the case, the fredericton data was simply used to > verify the bing imagery. > > tl;dr No offset was derived from the Fredericton data, it was simply used to > check the Bing imagery. Okay, so if there had been an identifiable offset in the Bing imagery, what would you have done then? Would you have thrown up your hands and said "There's no possible way that I can continue!" If I check my street name spelling against Google Maps, and notice that there is a spelling mistake in my version, can I delete my name based on that information? I can't give a definitive answer, just posing a question. I've always wondered how we can put names on the roads. People say that they are using "local knowledge", or they base the information on what they observe on the street signs. However, given the situation where a new subdivision is planned, and the roads and street names are drawn on the planning document, then the builders build the streets, and put up street signs based on the planning document, then someone reads the sign before they share that information with others to create that "common knowledge". If the original planning document is a under a copyright, how can we map the street names in OSM? -- 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 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 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 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 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
On Fri, Nov 9, 2012 at 7:20 PM, Paul Norman wrote: > In BC everywhere is part of a regional district (our admin_level=6). We > don't have counties. We don't have counties in Alberta either... the county act was repealed in the mid 90's, but a number of the municipalities still use the term county in their name. Saskatchewan also does not have counties, but rather rural municipalities. Rural municipalities in Saskatchewan and Manitoba not only exclude cities, but also towns, villages and First Nation's reserves as well. Interestingly, the State of Virginia also excludes cities from their surrounding counties similar to what Alberta does. Danville, Virginia is defined at admin level 8, with a corresponding hole at admin level 6... http://layers.openstreetmap.fr/?zoom=12&lat=36.58549&lon=-79.37527&layers=B00TFF -- 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 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] 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 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=5&lat=52.59638&lon=-118.12528&layers=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 > À : Pierre Béland > Envoyé le : Vendredi 9 novembre 2012 12h20 > Objet : Edmonton / Strathcona boundary limits > > On Fri, Nov 9, 2012 at 10:06 AM, Pierre Béland > 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] Bing Map of Guelph, Ontario is poor
On Thu, Nov 1, 2012 at 1:46 AM, Paul Norman 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 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 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] Suivi OSM / OSM Monitoring
On Mon, Oct 29, 2012 at 7:21 PM, Pierre Béland wrote: > Geobase provides various administrative boundaries. See > http://www.geobase.ca/geobase/en/data/admin/index.html > > The municipal boundaries (admin_level=8) are provided by each province. > Admin_level 6 is also available for Ontario. The Shape files have to be > converted to OSM. Are there instructions on how to do that? > Looking at the history of your Lamont county way, I see that is also part of > Strathcona county relation. This polygon is also broken. See > http://www.openstreetmap.org/browse/relation/50382 > A good mess! Many new mappers don't know about relations and don't care when > asked if they want to delete even if the way is part of a relation. That's the actual county definition that I was talking about... I only found part of the way, and not the whole relation. I still don't know enough about relations and the rest to be able to get things straightened around properly. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Suivi OSM / OSM Monitoring
2012/10/29 Pierre Béland : > Since OSM is a collaborative project, experienced contributors who monitor > changes to OSM need monitoring tools. There are many like KeepRight, > Inspector or http://layers.openstreetmap.fr/. > Contributors may follow edits such as hiking trails or bike lanes, or items > such as main roads and administrative boundaries, wich are essential to > tools such as Nominatim or Road travel. This piqued my interest, especially the layers.openstreetmap.fr link. Political, geopolitical, territorial, and administrative boundaries have always been of interest to me in the OSM project. Many years ago I attempted to trace out the boundary of the county in which I live. I was at the time trying to figure out how to create a polygon that shared boundaries with neighboring areas, or road centerlines, etc... I had one heck of a time trying to get it in there, but I think I finally succeeded. But then people would come along and wipe out a segment or two and the county outline was gone. I have given up chasing after trying to fix the boundary. Here's part of it that still exists since it is in a rural area where no one pokes and prods... http://www.openstreetmap.org/browse/way/23502499 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, but the rest of Canada is blank except for a small section in north central Manitoba. Is this information available in the freely available datasets out there? I'd like to get the counties, municipal districts, improvement districts, special areas, specialized municipalities, and cities of Alberta imported, I just need to figure out where to find them. There are also election boundary layers in OSM. There are a number of them available. Is there a list of which would be Federal, Provincial, and Municipal layers? What about boundaries for other things? How would they get tagged? Of interest to me is the Environment Canada weather alerting boundaries. It would be nice to be able to include those boundaries in the OSM dataset. Can you create custom admin levels? -- 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 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 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] Edmonton OSM gathering
On Fri, Jul 6, 2012 at 8:06 AM, Adam Dunn 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] How did you start in OSM?
On Fri, Jul 6, 2012 at 5:27 AM, Richard Weait 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 Thu, Jul 5, 2012 at 10:27 PM, Dan Charrois 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
Re: [Talk-ca] [talk-ca] Merging ways
On Thu, Jul 5, 2012 at 11:28 AM, Richard Fairhurst 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 7:16 AM, Richard Weait 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
[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] Merging ways
On Tue, Jul 3, 2012 at 8:33 PM, David E. Nelson 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] 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 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] Canvec in Potlatch 2
On Tue, Jul 3, 2012 at 7:38 AM, Richard Fairhurst 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] Oil Pipeline?
On Tue, Jun 26, 2012 at 11:02 AM, Steve Roy 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 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 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 8:12 AM, Harald Kliems 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=14&lat=52.58831&lon=-111.2836&layers=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 Tue, Mar 20, 2012 at 12:00 AM, Gerald A 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 Mon, Mar 19, 2012 at 6:07 PM, Stewart C. Russell 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
On Sun, Feb 26, 2012 at 1:05 PM, James Ewen 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=16&lat=45.63281&lon=-72.12879&layers=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=16&lat=45.63054&lon=-72.12227&route=0.87&hill=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] Re : Duplicated ways
2012/2/26 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] Closed Road Tagging
On Sat, Feb 25, 2012 at 3:04 PM, Paul Norman 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 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 9:05 PM, Steve Singer 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.786&lon=-112.0373&zoom=14&layers=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] Automated imports of Canvec?
On Thu, Dec 15, 2011 at 1:46 PM, Richard Weait 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] Fwd: [OSM-talk] Argh, Canvec imports
On Thu, Nov 17, 2011 at 5:18 AM, Richard Weait wrote: > I do bimonthly runs of the worldwide coastlines > (http://metro.teczno.com/#coastline), and Canada seems to be a > recurring source of problems. What the heck is going on up there? I > consistently see new imports of what seems to be Canvec data screwing > up coastlines and making for some deeply broken renders: >From what I hear, it's people changing the tagging in an effort to tag for the renderer. They are changing tags trying to get the OSM map to look "right" to them. In doing so, it breaks things. With the bi-monthly rendering runs, it is possible for people to screw up a lot of coastline before finding out that they are breaking it instead. With no hard and fast rules about what "should be done", people are free to do what they want. There was just a discussion about how to tag riverbanks and large lakes as coastline just to get them to render at the lower zoom levels. That sounds like tagging for a renderer. If I decide that I want my lake to show up at a specific zoom level, do i change the tagging to make it coastline instead? -- 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 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.0671916007996&lon=-115.968310832977&zoom=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 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_eu&lon=-112.55995&lat=53.71582&zoom=13&opacity=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.091&lon=-109.473&zoom=9&layers=O -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] What should a Canadian style map look like?
Well for one thing, render forest in something other than dark green. I started importing forested areas, but stopped as soon as I saw it rendered. The forest colour overpowered the roads in the area. The maps become just about useless as a road map when the roads disappear. My biggest issue with not only OSM, but my GPS navigators is that if I zoom out far enough to get a view of where I am headed, I'm looking at a blank screen. If I zoom in to find the roads, I'm looking at an area about as big as I can see out the windows... not much use. In our country of wide open spaces, we need to have some of those minor roads and places shown when looking at large areas. James VE6SRV -- 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 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 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 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 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.485292&lon=-112.80943&zoom=18&layers=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 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.4262&lon=-113.4888&zoom=14&layers=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.42826&lon=-113.49479&zoom=17&layers=M http://www.openstreetmap.org/?lat=53.4145&lon=-113.54344&zoom=17&layers=M http://www.openstreetmap.org/?lat=53.43157&lon=-113.54426&zoom=17&layers=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] Routing errors, turn restrictions and median crossovers
On Sun, Mar 6, 2011 at 5:20 AM, Stewart C. Russell wrote: > If it's any consolation, Garmin's maps will suggest u-turns in the > middle of highways too. Every time I want to go to Point Edward, the > Garmin tells me to pull a U-ey in the middle of the 402. That's not a u-turn... it's a sharp left! I think every routing engine figures that a u-turn can only take place on a non-divided highway. As soon as you have a dual carriageway, then "rippin' a 180" is fair game. Even so, where that dual carriage way ends and forms a Y with a single carriageway, my GPS navigator thinks that's a good place to spin around. Looking at it from a computer coding point of view, how do you determine when that little bit of road between the opposing lanes is no longer a cut in the median, but a street on it's own? To be fair, most humans these days can't figure out what a cut in the median is... There are so many idiots out there that think it is legal to pull across a set of lanes, and stop in the median waiting for a break in the traffic traveling in the opposite direction. Or even better boneheads that are signalling for a left hand turn while you are doing the same facing them that try to go around you to their right in the middle of the intersection before completing the left hand turn. Both of these maneuvers are not only dangerous, but completely illegal. I've taken to sitting at dual carriageway intersections waiting to make a left turn until there are no more oncoming vehicles facing me with left turn signals on. If I try to drive properly there's a good chance for a collision or at the very least a bunch of finger action from the bozo that is breaking the law. Even the "experts" who design the roadways aren't in the clear... we have a dual carriageway in Edmonton with a fairly wide median. The traffic planning experts put an extra set of lights in the middle of the intersection as well. When making a left hand turn, you have to stop for the set of lights to cross what used to be the oncoming lanes. There's room for about 2 passenger cars to make the turn on each change of lights. A large semi ends up blocking the intersection because the trailer hasn't cleared the roadway by the time the steering axle hits the stop line. Put two B-trains opposing each other and that intersection is done... I can't recall where that intersection was... I haven't been by it for years. Had a quick look at the map, but it's not coming to me. Maybe it has been removed and corrected now. The traffic planners have resorted to putting in long left hand turn lanes which put the opposing drivers to the left of the oncoming vehicles in an effort to keep people from attempting to interlock the vehicles while making left turns... http://www.openstreetmap.org/?lat=53.46537&lon=-113.466058&zoom=18&layers=M The days of the Uniform Traffic Act are long gone. 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] 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.
On Fri, Mar 4, 2011 at 9:25 PM, Samuel Longiaru wrote: > Thanks Richard. I tested it on the Trans Canada heading east of Kamloops > towards Banff. It was routing through Edmonton. Wha??? Tracked it down to > a divided section of the TC west of Field where both sides of the highway > were marked as westbound. KeepRight didn't pick it up in this case. > Fixed. Thanks for the link. Very quick indeed. There are more anomalies on the TC-1 east of Golden... anyone familiar with the area care to fix the problems? http://www.openstreetmap.org/?lat=51.27396&lon=-116.76355&zoom=16 James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Address interpolation
What's the procedure when making corrections to roads that have associated address interpolation ways? >From what I see, address interpolation ways are just simply ways sitting beside the road, and have to real relation to the road besides proximity. If a road gets moved to a new location, does one create new parallel ways and tag them as address interpolation ways? What's the standard offset from the roadway? Where does one get address numbering information from? For some places it can be easy, where you start at 1, and work your way up, but what might the upper limit be? Guessing doesn't work, as can be seen in the NavTeq and TeleAtlas databases that have my house number around 63 or so, yet there are only 40 houses on my street, with the last house being #40. Where there are houses, one can simply read the number off the house if it is posted, but in areas where no houses yet exist, one might have to resort to looking at another source document. 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 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 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
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 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
Re: [Talk-ca] CanVec data to OSM
> On 1/24/11, Dan Charrois 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] Purging vreimer
On Fri, Jan 14, 2011 at 8:39 PM, Samuel Dyck 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] Pharmacy vs. dispensing pharmacy
On Thu, Dec 2, 2010 at 7:40 AM, Richard Weait wrote: > I've heard from mappers elsewhere, that they have non-dispensing > pharmacies with off-the-shelf notions, as well as over-the-counter > medicines. Apparently dispensing prescription medicines is an > additional qualification not found in every pharmacy. > > So I guess (really, I'm just guessing here) that we don't have places > where your can get over-the-counter medicine, that does not also > include prescription medicines. So other jurisdictions may have two > levels of pharmacist licenses, one for over the counter, and another > for prescription. Or something like that. Okay, then 7-11 would be a pharmacy as the sell Tylenol, Robitussin, Dimetap ect. The local gas station would fall into the same category selling Aspirin. Goofy people across the pond, huh? James ___ 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 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
[Talk-ca] Where's the Canvec data hiding these days?
I've been trying to get to the canvec data for 3 days now using this URL: ftp://ftp2.cits.rncan.gc.ca/osm/pub I was pretty sure that you could get into there with a browser and download the file of choice. I keep getting a webpage not available. If I ftp from the command prompt to ftp2.rncan.gc.ca, I get and ftp server that wants a user name and password, so it looks like the URL points to an ftp server. Perhaps just the web server front end is dead... Anyone else able to get canvec osm files? James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Where'd it go?
Okay, I just noticed that some of highway 43 has disappeared. http://www.openstreetmap.org/?lat=53.8975&lon=-114.9219&zoom=12&layers=M I went into the area, and into Potlatch. I see a bunch of nodes where the highway used to run, but no highway. Pressing "U" for undelete only brings up my original crude version of the highway before the GeoBase import. The highway was there previously as I have the tiles that show the highway cached on my laptop. Why doesn't "U" bring it back? Where did the highway go? There's a good chunk missing, and GeoBase has it chopped up into many, many bits, so I wouldn't think that someone accidentally deleted all those bits. James ___ 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 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.5202&lon=-113.1563&zoom=13&layers=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 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 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.69252&lon=-95.33649&zoom=16&layers=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!
Okay, anyone out there know what the extra numbers tacked on the end of the tile number represent? 083H11.0.0.3.osm 083H11 is the tile number, but what is the 0.0.3 portion? I can't seem to make any sense as to how they are to be interpreted. They seem to start in the upper left corner of the tile, but if I'm on 0.3.0, what's the number of the tile to the left? James VE6SRV ___ 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 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 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 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 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
[Talk-ca] Merkaartor and WMS layers
Is there anyone using Merkaartor and WMS layers within Canada? I looked at Merkaartor many months ago, when it was very rudimentary. It appears now to be much more capable, and I'd like to start playing with it. However, the documentation for the program is very much lacking. It's currently at the stage where you really need to know what you are doing, and know the details about what you want to do in order to get things set up properly. That's a little difficult to do when you don't have the knowledge. Merkaartor appears to have the ability to add new WMS servers to its abilities, but there is no documentation about how to set up a new WMS server. I grabbed a link from the Toporama website and pasted it into the Server URL spot on the WMS servers setup page, and if you click on get capabilities, you get a long list of all the available information from Toporama. However, when I enable the layer, all I get is a little grey box. Anyone know what to do? While we are at this, is there a list of available WMS servers that contain Canadian data? This would be a great OSM Wiki page. 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=14&lat=53.80445&lon=-113.09712&layers=B0TF [2] http://sautter.com/map/?zoom=13&lat=53.57742&lon=-117.48367&layers=B0TF [3] http://sautter.com/map/?zoom=12&lat=59.9385&lon=-122.94594&layers=B0TF [4] http://sautter.com/map/?zoom=10&lat=54.85922&lon=-110.59387&layers=B0TF ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Lethbridge AB mappers
On Sun, May 9, 2010 at 7:51 AM, Richard Weait wrote: > First: "Whoop Up Drive"? Awesome! Thank you for that smile. Named after Fort Whoop Up... part of our rich western Canadian history! http://en.wikipedia.org/wiki/Fort_Whoop-Up > And, could somebody visit this area? Looks like GeoBase was ahead of > the aerial imagery. It would be nice to have GPS tracks to > corroborate. Also some connectivity repairs are required. GeoBase matches up with what Google and Yahoo street maps say, although Google's newly added physical "detail" leaves much to be desired. Google shows the ploughed fields to be riddled with sloughs where both Google and Yahoo satellite imagery don't show such. This is a really good spot to see just how the road matcher script tries to keep from modifying existing ways in the database. The holes in the GeoBase import match areas where the old Township Road 84 geometry ran. Using the transparent overlay capability provided at Sauter.com makes it really interesting and easy to compare different sources. http://sautter.com/map/?zoom=15&lat=49.66927&lon=-112.90164&layers=B0TF James VE6SRV ___ 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 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] Vancouver campus data
On Mon, Mar 29, 2010 at 11:37 AM, Corey Burger wrote: > Bicycle racks would certainly be a welcome addition. I look at the > number around UVic and shudder. > > However, who holds copyright on the data? They need to sign off on > importing it into OSM if it isn't licensed under fairly liberal terms. > If you don't know then it is likely all rights reserved. Plant Ops may > not have the ability to do this. Likely you are going to need to clear > it through Legal, which can add time and headaches. So this brings up a question for me... If Gregory were to wander around the campus, and mark the bike racks on his GPS, and upload that to OSM, it would be completely kosher. What if Gregory were to plan his outing to collect information by referencing the copyright information in the campus map. Would that make his information a derivative work? I would think not. What if Gregory were to reference the location of the bike racks on the campus map, and then use the Yahoo Map images to locate the bike racks, and mark them on OSM. Would that now be a derivative work? This I don't know... Just wondering where the line is... 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 10:18 AM, Richard Weait wrote: > I also meant to include an example of boundary relations working! The > new maxspeed map[1] shows use of the maxspeed tag. It you look at the > lower left of the map window, you'll see "Admin boundary hierarchy > Toronto(6) / Ontario(4)" Pretty cool. > > > [1] > http://maxspeed.osm.lab.rfc822.org/?zoom=16&lat=43.66352&lon=-79.39146&layers=B0T&input=maxspeed I was going to give you a hard time about keeping this a secret, but I see that the guy running the site just made it worldwide yesterday. Now, how do we learn about what we are viewing, and how to make the magic work? I did a search on maxspeed osm lab, and got a few hits to pages talking about it, but didn't find a page describing what I'm looking at. I tried looking at my own local area, and get nothing but the base map. Only Alberta is defined as a relation. I'm going to assume that the admin relation needs to have things associated, such as a base speed limit. For Alberta, we would probably define a max speed of 80 km/h, which is the default for the rural highway grid (which encompasses all roads excluding highways). Do you define default speed limits for different classes of roads. Show me and I'll shut up... ( like that will happen) I might be quiet for a little bit though. Just another thing that I know I don't know. 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 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
Re: [Talk-ca] Missing highway ramps on OSM map, not missing on Ibycus topo map
On Sun, Mar 21, 2010 at 4:24 PM, Marc Provencher wrote: > I guess Dale Atkin (Ibycus) is using a different program then for his road > matching, because these omissions don't seem to show up on the Ibycus map. Dale just grabbed the GeoBase data. Dale's product predated the GeoBase import into OSM. Dale was not limited by licensing in the same way that OSM was. At that time, the GeoBase license was not compatible with the OSM license. OSM got access to GeoBase, and the roadmatcher script was created to allow unique ways from GeoBase to be added to the OSM database. This was done to ensure that no user entered data was destroyed. The side effect was that some ways from GeoBase were left out of the OSM database. The way to find these missing ways is to observe the OSM database. Look for missing information. The strength of the OSM community is the community of OSM. With many sets of eyes, and associated hands, the last step of the GeoBase import is to find and fix issues where the OSM database and GeoBase database need to be stitched together. James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Highways in Yukon
The Dempster should be tagged as a trunk highway from what I read and understand. It is a very important highway (read only) headed north out of the Yukon to Inuvik. Even if it has a gravel surface, it is still the primary route. Top level highways get tagged as trunk. Limited access highways get the motorway tag. Tagging as such gives the highway the level of importance that it should have designated for routing engine decisions and such. The government designates specific routes as the top level priority routes in areas. This designation means that the construction of the road is designed to carry the heavier volume and mas of vehicles. It also means that the route will receive more maintenance attention, including pothole patching in the summer, and snow removal in the winter. By tagging as a higher importance roadway than others, this will inform travellers not familiar with the area that this route is probably the preferred route in the area. This information will probably be conveyed to the user in a visual manner, so yes, you would be tagging in a way which would affect the rendering. James VE6SRV On 3/17/10, Tim Francois wrote: > OK, so I came into some free time and completed the tracing of the > Dempster Highway into OSM. Some points: > > 1) I have tagged it as a primary highway. It is, after all, called the > Dempster Highway. Also, it is the only ground link to Inuvik, thus > fairly important > 2) I have tagged the surface as gravel. > 3) I came across an unfinished Dempster Highway portion in Northern > Yukon. This was tagged as a tertiary highway, and as part of the > Trans-Canada Trail (ncn and ncn_ref attributes). I deleted the portions > for which I had accurate GPS traces, and merged the two somewhere inside > of NT, changing the highway to primary. > 4) The entire Dempster Highway is now tagged as a Trans-Canada Trail. > 5) I've also tagged as bicycle=yes, as a) I saw many cyclists and b) the > tertiary route I came across also had this! > > I'll be adding in further POI's along the route when I can extract my > diary files, and going on to update the rest of what we travelled in the > summer. > > Question: Is there a Trans-Canada Trail relation I should have used? > Couldn't find one... > > Tim > > -Original Message- > From: James Ewen > To: Talk-CA OpenStreetMap > Subject: Re: [Talk-ca] Highways in Yukon > Date: Thu, 11 Mar 2010 19:59:25 -0700 > > On Thu, Mar 11, 2010 at 7:18 PM, Richard Weait 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 > > > > ___ > 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] 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
[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
Re: [Talk-ca] Highways in Yukon
On Thu, Mar 11, 2010 at 7:18 PM, Richard Weait 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
