Re: [Talk-ca] RIP CanVec
> On 2014-Nov-17, at 1:53 PM, Ga Delap wrote: > > Il y a actuellement un peu de bruit sur talk.ca pour faire renaître les > importations CanVec. > Il ne faut pas. > Unfortunately, though I can read French, I can only speak or write English properly, but wanted to weigh in on this discussion. As someone who has imported a fair bit of Canvec data, I wanted to weigh in on this. Though Canvec data has some issues involved in importing into OSM that people should be aware of, I think that it does far more good than harm if treated properly. All data from Canvec (or any source for that matter) should be inspected carefully before importing into OSM - using satellite imagery for verification, for instance. And in particular, any data from Canvec that is replacing existing data in OSM should be considered very carefully and with a high degree of suspicion, as in most cases (though not all), our existing OSM data is superior. But with that said, there are a lot of pieces of data from Canvec that we don't have in OSM and should be added - more streets, addresses, and forest areas, as you mentioned - especially if they're verified by overlaying satellite imagery. I'd add to that list hydrography. In particular, smaller streams and lakes in my part of Canada tend not to exist at all in OSM, and adding them from Canvec adds data where there otherwise was none. It's usually best to leave the larger lakes and rivers that already exist alone, though perhaps adding a bit more detail to their shorelines. In my experience, probably about 90% of the data in Canvec (particularly non man-made features) that is not already in OSM may be worth importing. And similarly, about 90% of the data that is common between the two is best left alone. Some areas of the map in more remote areas don't have any data at all in OSM - in those cases, importing Canvec data particularly adds a huge amount of value. In places like downtown Toronto, probably not so much. I think Canvec data is very valuable for OSM and very strongly support its continued importation, under the condition that whomever is doing it knows some of the issues as you pointed out to ensure they are always making things better instead of worse. Dan --- Dan Charrois President, Syzygy Research & Technology Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] workflow for elevation data
> I've read somewhere that the srtm data has, at best, 30m resolution. I don't > know that it's resolved enough for hiking/snowshoeing/cross-country skiing? I > can think of features where greater than 30m resolution would be helpful. > Then again, I just looked at opencyclemap for that area again, and the > resolution might be plenty. I'll have to look again. SRTM is handy since it is a global dataset with coverage from 54 degrees south to 60 degrees north. But globally, it is released only at 3 arcsecond resolution (approximately 90 m), though for the US, it's available at 1 arcsecond (30m). For localized areas, there are other options - the National Elevation Dataset (NED) in the US is generally good to around 1/3 arcsecond (10m), with some localized spots down to 1/9 arcsecond (3m). In Canada, the Canadian Digital Elevation Data (CDED) is available to 3/4 arcsecond (23m). Another resource at much lower resolution is GTOPO30, which is only to 30 arcseconds (approximately 1000m) but has the advantage in that it is truly pole to pole, so fills in the northern and southern regions that SRTM didn't cover. So if high accuracy publicly available elevation data is required, and you have some time on your hands, it's possible to create an elevation dataset spanning the globe using "best of" data from multiple datasets. That's what I did for the elevation data I use in the Mapster app I made, though it can be a fairly intensive process (I used overlaps in the data to confirm sections, identify problem areas, fill voids in one dataset with data from another, etc), and there are sometimes a few small discontinuities in boundary areas, due to different accuracies of mapping techniques, possibilities of slightly different interpretations of datum, etc. But overall, I can speak from experience that it is possible, and you can benefit from higher resolution than 30m in many parts of the world if it's useful to you. Dan ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] workflow for elevation data
I usually don't post often here, especially when it could be construed along the lines of "tooting my own horn". But this is a topic close to my heart, especially where the examples below came up. A couple of years ago, I saw the need for offline maps for back-country hiking, or even when travelling in places where I didn't have a data plan. So I took OSM data and combined it with hill shading, contour lines, and hypsometric tinting for the whole world, and ended up with an app for iOS devices called Mapster (http://itunes.apple.com/ca/app/mapster/id409304946?mt=8&uo=4). It turned out that other people wanted this kind of thing too, since it spent a couple of months in the top 10 for Navigation apps, and is still going strong. I thought I'd mention it along with the other examples below of the sorts of things that have been done with elevation data/hiking maps and trails, etc. Unfortunately, I can't justify the bandwidth costs to open up my map servers to the Internet in general - the data and our tile servers are only available to users of the app. But the app is downloadable for free, though limited in how many map tiles you can get in a day for free. Of course, if anyone is interested in any of the "behind the scenes" of the Mapster data or integration of elevation data I did, just contact me. Dan On 2014-Feb-23, at 2:22 PM, Harald Kliems wrote: > There are also a bunch of hiking/biking-specific, OSM-based maps out there > already, so I'm wondering it those might be good enough for your/their > purposes. And if not they might help you developing your own solution. Some > examples: > > http://www.4umaps.eu/online-outdoor-hike-bicycle-map.htm (contour lines and > hill shading) > > http://hiking.waymarkedtrails.org/en/ (only hill shading) > > http://hikebikemap.de/ (hill shading and contours in limited area) > > And of course the cycling layer on the main page with contour lines. > > There's also this project: > http://wiki.openstreetmap.org/wiki/Route_altitude_profiles_SRTM but I'm not > sure if this is still under active development. > > As a side note: I had planned to do some mapping with the McGill Outdoors > Club in the Prevost area last spring. They're also maintaining their own > little network of trails. Unfortunately, that didn't happen in the end, but > they were definitely interested in/open to OSM. -- Syzygy Research & Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] OSM apps for iOS devices
Hi Guillaume. Full disclosure first, since I wrote it. But an option for offline viewing for the iPhone/iPad/iPod is "Mapster" (http://itunes.apple.com/ca/app/mapster/id409304946?mt=8&uo=4). It couples topographic data (hillshading and contours) with OpenStreetMap data, and caches tiles rendered by our servers "semi-intelligently" (it checks for updates on cached tiles periodically, but otherwise keeps them on your device indefinitely if the space you allocate for caching is adequate.. otherwise, it removes tiles that haven't been used in awhile). All that's "behind the scenes" though, so the user doesn't have to worry about those details. I wrote it for my own uses when I couldn't find anything appropriate for back-country hiking I like to do, far out of the range of cell towers. And surprise of surprises, it seems like I wasn't the only one looking for something like that, since it's done fairly well. Dan On 2013-May-14, at 7:07 AM, Guillaume Pratte wrote: > Hello, > > In preparation for the upcoming OSM workshop in Montreal, I would like to > have the advice of people using iPhones and such on the best OpenStreetMap > applications available. > > What do you use to browse the map? > Are there applications that allow you to download data offline? > What do you use to record GPS tracks and to upload them to OSM? > > Your replies will help me suggest good iOS apps to the attendees of the > workshop. -- Syzygy Research & Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Internal CanVec conflicts
Usually, in remote areas of the north that I've dealt with, there is often little else already there than the Landsat lakes. And usually, in a given tile, there is usually just a handful of lakes. In pretty much every case I've dealt with so far, I've replaced the Landsat lakes with Canvec data. Landsat lake outlines have a much lower resolution, and being derived by an automatic process themselves, are subject to the errors associated with that. But I wouldn't necessary erase all the Landsat data from a tile without checking first to make sure that there will be Canvec data replacing it (I always work with my Canvec data in a separate layer and merge things in one "feature" at a time as it's checked). Using Bing imagery may be a good idea to check any issues where Landsat data may exist and Canvec doesn't - even low resolution Bing imagery is usually sufficient for the Landsat lakes. I have yet to encounter a place where there is a Landsat lake and not a corresponding Canvec one of roughly the same shape, but it could happen. I have yet to find a situation where the Landsat lake data is better than the Canvec data. Dan On 2012-Nov-16, at 12:11 PM, Pierre Béland wrote: > Looking at all of north of Canada, I see that most of it has been first > mapped using Lakewalker Plugin and Landsat imagery. > I see tags created_by=Dshpak_landsat_lakes or source=Landsat. > > Those of you that have imported Canvec data in such regions are surely > familiar with that problem could confirm and help document Canvec Import > Guidelines to facilitate imports by newcomers. > > What procedure do you recommend? Do you agree that we should recommend to > erase Landsat imagery before importing Canvec data? > > This can be done easily in JOSM. We just have to use the find filter > created_by=shpak_landsat_lakes and erase the selected objects. > > Too risky? > > Pierre -- Syzygy Research & Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Internal CanVec conflicts
> "Is it the communities view that it is okay to import CanVec without > reconciling the internal differences between the layers?" > > I believe it is. The great thing about OSM data is it is not written in > stone. An import or edit can be changed in the future. The data is > inserted for use by anyone. Just because I upload the CANVEC does not mean > it is required to stay there as is.I don't believe an import has to be > perfect, especially in massively expansive areas natural areas which remain > in a constant state of flux. This cannot be accurately determined via Bing > or ANY source we have. Rivers change course each year, often several times. > They flood timber, often for short periods of time. Which raises another > question...how do we determine what timber is? Is it trees? Brush? Mixed > wood? A forester would say all of the above. Muskeg? Swamp? Bog? Anyone > here qualified to make that decision? That island in your example? It has > brush on it. But it might not in the spring. The whole island might not be > there in the spring. But it's there right now. As a fellow Canvec importer, I wanted to weight in on this discussion with my opinion as well. I agree with Bryan's viewpoint. In an ideal world, it would be great if we could process an area of Canvec data and be able to say that it absolutely and accurately reflects a current reflection of reality. Perhaps if we were in a (much) smaller country, or if we had a (much) larger community of OSM mappers here, getting closer to this ideal would be easier. But the truth of the matter is that with ten million square kilometres of land to map, and only a small handful of people doing it, the question naturally arises as to whether it is better to have a very small area of Canada mapped extremely well, or a larger area merely adequately. This isn't as much an issue in the larger cities as it is in rural or remote areas. In larger cities, there is a larger community of OSM mappers out there who keep them up to date, consistent, and accurate, and I think in general those who have worked in those areas have done a wonderful job. That's a great thing - our best maps in Canada are in locations where there are the most people to take advantage of them. I started contributing to OSM data via Canvec imports based on need - areas I was interested in had a rather outdated road network, a very minimal hydrological network, and no information on forested or wooded areas at all. Canvec data, though not perfect or always internally consistent, at least was much better than what was already there. My first imports were sloppy, as any first attempts always are. I didn't know about joining features at edges of tiles, and in general placed a lot more "authority" on Canvec data than it should have sometimes received.I even discovered a bug in JOSM that caused me to accidentally delete some roads that shouldn't have been (which was fortunately pointed out to me fairly early so I didn't continue wrecking things as I went along trying to improve them). But I learned over time, and hopefully got better, in learning where Canvec's strengths and weaknesses were. Over time, I've come to realize how certain assumptions could be made in Canvec data. If roads for a new subdivision appear to be placed in a wooded area, there is a pretty good chance that the wooded area is no longer there. Similarly, for a road going through a small pond - the pond is likely based on older data than the road and likely disappeared when the road was constructed. I usually assume that if a road already exists in OSM for an area where Canvec has a road, the existing road could be very well based on better data than Canvec (and on the other hand, if Canvec has data for a road which doesn't exist in OSM, I usually add it under the assumption that it had just not been mapped yet into OSM). If Bing data exists to verify this, great... but at least in the parts of the country I'm interested in, it very rarely does. And do I miss things and make mistakes? Absolutely! But I strive to add more value to OSM than I take away by failing to fix inconsistencies like this. Ultimately, as Bryan said, OSM data isn't written in stone, and anyone finding an error in a Canvec import is welcome to change it, and is every bit as capable of changing it as the original importer. Some Canvec data may have trees in waterways - if the original importer finds and fixes this, great. If not, the next person to come along could do so just as easily. But starting out with at least some data in OSM in the area is better than nothing at all. Take, for example, the case of a stream running through an area that becomes a new subdivision. If Bing imagery exists, great - but it often doesn't. But there is no way to tell otherwise and without knowledge "on the ground" if it still exists after the subdivision is complete - larger stre
Re: [Talk-ca] How did you start in OSM?
I'm a geeky guy who's always been into mapping. My first GPS was the Garmin GPS 38 (a single channel receiver that could track up to 8 satellites but took forever to get a lock). But right from the beginning, I was hooked - I even used it in 1999 to do a "Study of the Accuracy of Averaged Non-Differential GPS Measurements" (http://www.syz.com/gps/gpsaveraging.html) when selective availability was still turned on. From there, I always experimented in ways of coaxing more and more accuracy out of GPS receivers, culminating with putting together 3 Motorola Oncore VP boards and writing my own software to do carrier phase positioning. I got down to sub-centimeter accuracy with that. But how I got more specifically into OSM - as a software developer, I wanted to make a worldwide topographical map app for the iPhone, that didn't require a live data connection to use it (unlike Google Maps), since a lot of those who need topographical maps are often backcountry folk out of range of a cell tower. I source the elevation data from a variety of sources elsewhere, but as far as the main mapping data goes, OSM was a natural fit that I stumbled upon quickly when I started to do my research on the project. The result was something I call Mapster (http://itunes.apple.com/ca/app/mapster/id409304946?mt=8) Since OSM works so well for me in that sense, I enjoy being able to contribute back, so I remain reasonably active adding data to places I'm familiar with. I've also done (and continue to do) a lot of Canvec importing in areas otherwise lacking data. That's been something of a challenge in itself, as I learn of the various "gotchas" in the Canvec data set, but I'm getting better all the time. The recent Bing update added some high resolution photos of areas familiar to me, so I've been playing around with that somewhat as well. Dan -- Syzygy Research & Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Edmonton OSM gathering
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. I've been mapping and using/programming computers for years (long before OpenStreetMap), but have never used (or heard of) upcoming.com or meetup.com. Getting more people involved in OSM is great, and it can't hurt to spread the word as widely as possible, but I'd suggest that posting a possible event here should definitely be done. And BTW - I'm in the Edmonton area, and depending on the date/time/etc. may be interested in attending myself. Dan On 2012-Jul-05, at 6:03 PM, James Ewen wrote: > 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 -- Syzygy Research & Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Topographic map app using OSM data
Must have been too many late nights. When I skimmed through the description of the app while responding to you, I thought I somehow had forgotten to mention OpenStreetMap in the description. But when I went to go add it, I found that it had been there all along - turns out that I hadn't forgotten after all: "Of course, there is a lot more to Mapster than just a visualization of the terrain in an area. We use data from the OpenStreetMap project to be able to show you where roads, trails, stores, coffee shops, and hundreds of different types of features can be located. Approximately a billion points make up the current OpenStreetMap data set, and the collection is continuing to grow at an astounding rate." More details about OpenStreetMap, including the appropriate license details (currently CC-BY-SA, but that will change to ODbL when appropriate), and information on how to get involved in the OpenStreetMap community are found within the program itself. I'm not sure what additional attribution to OpenStreetMap might be relevant. I decided against putting OpenStreetMap "branding" on the rendered map images themselves, for a couple of reasons. First, as the device displays can be small, adding anything there unnecessarily is very distracting to the user experience (some may disagree on whether they consider license information "always visible" necessary, but I see no requirement for that). The second reason is that OpenStreetMap data is only one portion of the data set used by my software - if I put up a banner in the images referencing OpenStreetMap, it would only be appropriate to also have to mention the other sources of data I use (for topographical information) as well. That's why accreditation on the images themselves doesn't seem appropriate to me, considering how OpenStreetMap is referenced in the description and in the relevant places in the software itself. Dan On 2011-May-06, at 8:11 PM, Dan Charrois wrote: > Hi again. > > I'm glad you noticed that - I thought I *had* attributed OSM.. this was an > oversight. OpenStreetMap is in the keywords used in searching for itt , and > is definitely mentioned prominently within the app itself - both in the > attributions section, as well as significantly in the help section within the > app, where I discuss how the maps are generated, and encourage people to > participate in OpenStreetMap to continue to improve the data used in > generating the maps. But I agree that it wouldn't be out of place in the app > description on iTunes, and I'll change it - we'll see how long it takes Apple > to update my description change. > > I considered, but decided against putting in OSM branding overlaid on top of > the map itself continually while the person is using the program - the > screens are tiny and tend to be cluttered enough with the screen controls and > map itself without that. But I'll definitely add an OSM attribution into the > description on iTunes. > > Dan > > On 2011-May-06, at 7:19 PM, Richard Weait wrote: > >> On Fri, May 6, 2011 at 8:52 PM, Dan Charrois wrote: >>> Hi Richard. >>> >>> I hope to set up a "proper" web site describing it in more detail (with >>> screen snapshots) in a few days and will let you know the link once that's >>> ready. But in the meantime, the link I provided earlier >>> (http://itunes.apple.com/ca/app/mapster/id409304946?mt=8&uo=4) is >>> accessible to everyone whether or not they have an iTunes account or >>> iDevice of some kind (at least, I think so). There are a few screen >>> snapshots in there, as well as a more detailed description. >> >> Dear Dan, >> >> Thanks for the link. I didn't see any credit for OSM in the >> screenshots. Do you need a hand with sorting out the attribution >> requirements for you app. I'd like to help you make your app a good >> example of an OpenStreetMap consumer; then I can happily spread the >> word widely. >> >> Best regards, >> Richard > > -- > Syzygy Research & Technology > Box 83, Legal, AB T0G 1L0 Canada > Phone: 780-961-2213 > > > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-ca -- Syzygy Research & Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Topographic map app using OSM data
Hi again. I'm glad you noticed that - I thought I *had* attributed OSM.. this was an oversight. OpenStreetMap is in the keywords used in searching for itt , and is definitely mentioned prominently within the app itself - both in the attributions section, as well as significantly in the help section within the app, where I discuss how the maps are generated, and encourage people to participate in OpenStreetMap to continue to improve the data used in generating the maps. But I agree that it wouldn't be out of place in the app description on iTunes, and I'll change it - we'll see how long it takes Apple to update my description change. I considered, but decided against putting in OSM branding overlaid on top of the map itself continually while the person is using the program - the screens are tiny and tend to be cluttered enough with the screen controls and map itself without that. But I'll definitely add an OSM attribution into the description on iTunes. Dan On 2011-May-06, at 7:19 PM, Richard Weait wrote: > On Fri, May 6, 2011 at 8:52 PM, Dan Charrois wrote: >> Hi Richard. >> >> I hope to set up a "proper" web site describing it in more detail (with >> screen snapshots) in a few days and will let you know the link once that's >> ready. But in the meantime, the link I provided earlier >> (http://itunes.apple.com/ca/app/mapster/id409304946?mt=8&uo=4) is accessible >> to everyone whether or not they have an iTunes account or iDevice of some >> kind (at least, I think so). There are a few screen snapshots in there, as >> well as a more detailed description. > > Dear Dan, > > Thanks for the link. I didn't see any credit for OSM in the > screenshots. Do you need a hand with sorting out the attribution > requirements for you app. I'd like to help you make your app a good > example of an OpenStreetMap consumer; then I can happily spread the > word widely. > > Best regards, > Richard -- Syzygy Research & Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Topographic map app using OSM data
Hi Richard. I hope to set up a "proper" web site describing it in more detail (with screen snapshots) in a few days and will let you know the link once that's ready. But in the meantime, the link I provided earlier (http://itunes.apple.com/ca/app/mapster/id409304946?mt=8&uo=4) is accessible to everyone whether or not they have an iTunes account or iDevice of some kind (at least, I think so). There are a few screen snapshots in there, as well as a more detailed description. Dan On 2011-May-06, at 3:00 PM, Richard Weait wrote: > On Fri, May 6, 2011 at 4:32 PM, Dan Charrois wrote: >> Hi everybody. I don't want to make this a commercial plug, so I'll keep >> this short and relevant. The only reason I'd even want to mention this here >> is that I value the feedback of other OpenStreetMap people - especially that >> of fellow Canadians. >> >> I just released an iPhone/iPod/iPad app a couple of days ago, called >> "Mapster", available in the iTunes App Store > > Dear Dan, > > Sounds interesting. Would you point us to a few screenshots so those > outside of the iTunes garden wall can see what you are doing? > > Best regards, > Richard > > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-ca -- Syzygy Research & Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Topographic map app using OSM data
Hi everybody. I don't want to make this a commercial plug, so I'll keep this short and relevant. The only reason I'd even want to mention this here is that I value the feedback of other OpenStreetMap people - especially that of fellow Canadians. I just released an iPhone/iPod/iPad app a couple of days ago, called "Mapster", available in the iTunes App Store at http://itunes.apple.com/ca/app/mapster/id409304946?mt=8&uo=4 which combines topographical information worldwide with OSM street data. Relevant to the recent discussion of OSM tile server abuse, we don't hit that server at all - all of the tiles it uses are provided by our own custom-configured server, which merges the OSM data with hillshading, contours, etc. pregenerated on a global scale. Feature-wise, it's relatively basic - no routing, or even ability to find things at the moment - it's a pannable, zoomable map that can show your location. It does, however, allow the user to pre-download tiles in areas they are planning on visiting in case they do not have Internet coverage there, and is smart about caching, tile expiry, etc. so they user doesn't have to worry about keeping their map data up to date - the app does that for them, and tries to be bandwidth-friendly in that it only downloads new tiles if they've changed visibly from what it already has (a road that shifts a fraction of a pixel, for example, doesn't constitute a significant change). Despite its relatively basic functionality, it does present OSM data in what I feel is a useful and intuitive format (especially in mountainous areas where the topographical rendering really gives you a sense of what's going on - windy roads make much more sense this way :-), and is becoming well-received. It's currently ranked as the #3 navigation app for iPad. If any of you want to check it out, it's available for free (though a subscription required if downloading more than a certain number of tiles per day - I have to prevent abuse to our tile server too). And of course, the primary reason for this post - I'd greatly value any feedback that you might have. After all, if there's anything that you people understand, it's maps :-) Dan -- Syzygy Research & Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Did I just find a potentially significant bug in JOSM?
Thanks Adam, and everyone else who responded to my message. I'm glad to learn
the bug is repeatable by others - that means I'm not going completely crazy.
Plus, it's nice to have a good understanding now why some of the ways I'd
uploaded had mysteriously disappeared.
I'm glad you were able to distill down the problem so succinctly.
validatorfail.osm shows off the bug well, and is much easier to follow what's
going on.
I'd apparently been lulled into trusting JOSM's ability to fix simple things
like duplicate nodes a little too much. It's definitely a time-saver when it
works, but not if roads are lost in the process. I'm hoping that a slightly
revised procedure of fixing things just one category at a time (rather than at
the top-level "Warnings" category) should be a good workaround.
In the meantime, I agree that a bug report should definitely be filed about
this. At the very least, disabling top-level "fixes" would force people to go
through category by category. I'm sure I'm not the only one who has trusted
(or will trust) that the top-level "fix" is a good way to reduce the manual
workload. Your validatorfail.osm file is a perfect example of how to reproduce
the problem, and should probably be included with the bug report - I can
definitely try to figure out how to submit the bug report to
http://josm.openstreetmap.de/ if you're busy or no one else has yet, and you
don't mind my including the file. But as the person who really narrowed down
the issue, the "honor" for reporting it (if there is such a thing) should be
yours.. :-)
In any case, those "blanket fixes" will be a thing of the past for me - I'm
hoping that the category-by-category approach doesn't cause any issues.
Other than this hiccup, I've found JOSM to be quite intuitive and reliable,
though as was mentioned, it is a work in progress and likely always will be.
It's just a matter of finding where its specific weaknesses are, and then
avoiding those.
Dan
On 2011-Mar-07, at 8:31 PM, Adam Dunn wrote:
> Just reproduced this issue with JOSM 3751. Most warnings are not
> auto-fixable in Validator. I have only been able to find two "warn"
> level issues that validator will auto-fix: Nodes at same position, and
> duplicated nodes.
>
> As stated by Dan, clicking on a sublevel within Warn (such as unnamed
> highway) will disable auto-fix, but selecting top level Warn will
> enable the auto-fix button (if there is a duplicate node sublevel).
> Using auto-fix when there are both duplicate nodes and unnamed
> highways will cause the dupe node *and* the unnamed highway to be
> deleted.
>
> Method to reproduce (in 3751):
> 1 - Initialize a blank layer in JOSM (eg. download middle of ocean or
> open an empty .osm file).
> 2 - Create a way that is of highway={residential,secondary,etc
> (whatever is necessary to raise a "unnamed highway warning", not
> road)}
> 3 - Create a node (no tags necessary)
> 4 - Copy and paste node into same position (zoom in excessively to
> position duplicated node on top of original)
> 5 - Run Validator
> 6 - Click on top-level "Warnings" category, then click on the "Fix" button
> 7 - Watch road disappear
>
> Alternative method:
> 1 - Download attached .osm file (this is a minimal file to reproduce
> the bug, and is easily human readable in any text editor)
> 2 - Run Validator
> 3 - Click on "Warnings" category, then click "Fix" button
> 4 - Watch road disappear
>
> Adam
>
>
>> -Original Message-
>> From: Samuel Longiaru
>> To: Dan Charrois
>> Cc: Talk-CA OpenStreetMap
>> Subject: Re: [Talk-ca] Did I just find a potentially significant bug in
>> JOSM?
>> Date: Mon, 07 Mar 2011 18:13:37 -0800
>>
>> Dan...
>>
>> Have to admit that I VERY rarely if ever use the fix button, and then only
>> after I've isolated the issue for a specific error or warning. I do errors
>> first, then warnings. But after each correction, I revalidate to refresh
>> the list. Maybe that's overkill, but it keeps the exceptions from being
>> thrown. I think you're getting the exceptions because you've modified the
>> data, but have not updated the list. Usually, I just highlight the specific
>> error or warning, hit the SELECT button, then the "3" key to go there. I
>> fix it manually if I can, then re-validate. Then move to the next issue.
>> I'm too much of a scaredy-cat to highlight a whole class of errors and let
>> JOSM fix them automatically. Like I said, I'm not sure JOSM likes me.
>>
>> I'll try selecting an
[Talk-ca] Did I just find a potentially significant bug in JOSM?
I've spent the past several hours trying to find out out why some of my edits resulted in some accidental road removals. I think I've found the problem, which seems to relate to an apparent bug in JOSM, or at least a preference somewhere set to something unintuitive that I haven't been able to find - as such, I thought it would be best to communicate with the group to see if anyone's experienced this problem before, or at least give a heads up as to what has been happening to me in case it's inadvertently happening to others. I downloaded an area around the Beaumont, Alberta region to try and add some roads from Canvec that don't exist in OSM (roads which I could have sworn I've added when I worked on the same area a month or two ago). I then saved this downloaded area, along with the changes I made, to an .osm file in JOSM. I ran the Validator which found a few duplicate nodes and such. Telling it to fix errors, it did its thing. And then, I clicked on "warnings" and told it to fix those. Lo and behold, some (though not all) of the roads I'd just added suddenly disappeared. Since validation was the last step in my process before I uploaded the data, and I was often zoomed all the way out when I did so, I hadn't noticed this happen before, but it probably had been going on right before I uploaded my changes. In particular, sometimes I would replace lower quality OSM roads with better Canvec data, and if JOSM was deleting some of those Canvec roads I'd added in its "fix warnings" validation step, those original OSM roads would have disappeared without replacements. I tried to isolate further exactly what it was doing, and at least in this situation it looks like it may be related to unnamed ways. I have 41 unnamed ways in my data. If I click on the "unnamed ways" folder specifically in the "warnings" validation dialog, it doesn't give me the option to fix them - it shouldn't, since it doesn't know what to call them anyway. But if I click on the parent (root) icon just labelled "Warnings", the fix button is enabled, and I thought it was just supposed to fix all the enclosed warnings in categories that it is able to fix. When I click to "fix" all warnings like this, in the progress bar, I see that it spends some time "fixing" unnamed ways. And then those ways are gone when it's done. I was using JOSM 3751, so I checked for updates and found that 3961 was available. I've updated my JOSM to see if it's still an issue. But now, when I do the "global" fix warnings on the data set, it gets part way through, then consistently gives me an unexpected exception (coding error). When I dismiss that dialog, I find that those roads have again been removed, so it seems as though this is still a problem. The unexpected exception isn't encouraging either. I suppose that I can work around the problem by selectively choosing "fix" in the validations warning area for each of the separate categories, instead of doing them all at once. Though now I'm unsure as to whether or not there is still an underlying problem with fixing warnings that may give rise to an inadvertent loss of data. At the very least, I wanted to make a posting about it so that others can be warned away from having the same problems I have run into. If anyone is interested in trying to duplicate the problems I'm having, just let me know your email address and I can send you the .osm file I'm working with (compressed, it's about 600 kB). And of course, if anyone has any ideas, or suggestions about something stupid I'm doing, please let me know! Dan -- Syzygy Research & Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Here we go again...
On 2011-Mar-06, at 9:15 AM, Samuel Longiaru wrote: > Hi Dan, > > Your procedure sounds pretty similar to mine, and working around Kamloops > likely is equivalent in terms of the kinds of features we see. It's nice to see that the method I've been following isn't totally out in left field :-) > > You probably do this as well, but before running the validator, I step around > the edge of the import and connect streams, powerlines, and anything else > that I think needs connecting. The auto-fix on duplicate nodes just seems to > merge the nodes but doesn't combine the ways. As you, I very rarely have > found the need to import a road as previous GeoBase or other imports have > already provided the same information. Earlier on in my editing, I hadn't thought of connecting features around the edge of an import, though I've been trying to do it lately. One of these days, I'm going to have to go back to areas I already worked on, to do exactly that. > > I simplify some features as well (streams and some lake shorelines mostly) > but I try to remember to simplify before merging the selection onto the OSM > layer. Simplifying later often gives the warning that you are deleting nodes > outside the uploaded data area. If I get a conflict, this is where it > happens. I hadn't been paying much attention to where I did the simplification - thanks for the tip! I'll be sure to do it before merging into my working OSM layer, and see if that helps. > > You do, however, seem to have much better luck than I have had on failed > imports. On 4 or 5 different occasions, an upload has hung (sometimes for > hours) and a cancel has resulted in nodes only (no way information) being > uploaded to the server. This behavior is quite consistent. The result is > 6-8,000 isolated nodes blasted across the import block. I've then had to > download the area from OSM and manually remove each node. Rather > frustrating. I don't know the ins and outs of the OSM backend, but could you > be picking up errors at that point? JOSM never seems to "sort it out" for > me. :( I guess I have been luckier than you, in a way. I've only noticed one import so far that's failed spectacularly, which got me to figuring out how to use the reverter plugin. I think it saved my bacon in that situation - the idea of manually going to find and delete thousands of isolated nodes is a process I really wanted to avoid at all costs. But James Ewen has noticed some missing roads in an area I was working on southeast of Edmonton that I'm starting to think may have been the result of a flaky upload (at least one of those missing roads is one I remember working on specifically). What makes me worried is that I didn't even realize there was a problem in this area until he noticed those roads (I had assumed that JOSM had just "fixed things" when I retried afterwards) - in some ways, thousands of isolated nodes would have been preferable, since at least I'd have noticed there was a problem. I think I'll be reserving any "OSM editing days" for those when my Internet connection is as stable as possible. Dan -- Syzygy Research & Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Here we go again...
Hi there. Just thought I'd mention to everyone - I'm user "Charrois", and I signed up to this mailing list a month or two ago. I just added a bit of information to my profile so people wondering who this "charrois" is in the future can connect it to me. In any case, I've certainly not gone intentionally removing existing roads from the OSM data set, though I'll not claim to be immune to accidents :-) In any case, I use JOSM, and my general methodology is as follows. If anyone has suggestions on how to streamline things, or more significantly, see anything I'm doing wrong, or have suggestions to decrease the likelihood of mistakes cropping up, please let me know. - I'll load a Canvec file. - I'll create a new layer, and then download the region from OSM into it, which becomes my working copy - I then use JOSM filters to show individual keys (like waterway=stream, etc.), and then flip between the different layers, making them active one by one. If the existing OSM data doesn't contain anything of that key, the job is easy - I copy and paste the information from Canvec into my working copy. If the existing OSM data does contain items with that specific key in the region, I check to make sure that Canvec information wouldn't overlap the features (ie: we shouldn't import a building from Canvec if there already is one nearby in OSM - I presume OSM's information is more up to date, since someone went through the trouble of putting in the building in the first place). In most cases, I delete overlapping Canvec data before the copy/paste, preferring the existing OSM. In a few cases (like Landsat-derived lakeshores), I tend to favour Canvec, so as long as there is Canvec data to replace OSM, I'll delete the OSM first. When in doubt, I pull in a layer of Bing imagery - though it's unfortunate that higher resolution Bing images aren't available for lots of the places I've been working. - Roads, I tend to try and be particularly careful with. I only tend to copy and paste individual roads from Canvec if they don't already exist in OSM. Situations where I'll replace OSM roads with Canvec ones are pretty few - for example, if a road is listed as "unclassified", and Canvec has a category for it and the Canvec seems to roughly follow the same route, I've been replacing it with the Canvec road. Sometimes the more major highways have quite coarse-grained information (particularly around the curves), so sometimes I'll replace sections with Canvec information - though more often than note, I'll just add some nodes manually to the OSM data to smooth out the curves or line things up a bit better. I don't delete OSM roads (intentionally) unless it looks like I'm replacing them with better data from Canvec. - I go through this process for a fair number of keys, one by one, until all the useful Canvec data has been brought into my working copy. - I then do things like go through urban areas to remove silly things I notice that were added from Canvec. For example, often Canvec has lakes, or intermittent lakes, or small patches of wooded areas, smack in the middle of new subdivisions. I presume Canvec is just reminiscing how things were before development came on to the scene, so I typically delete those features out. - I usually run a "simplify way" on streams to reduce the node count a bit, but otherwise leaves things largely untouched. - When things look good, I do a validation run. It tends to find lots of things like duplicate nodes, etc. I tell it to automatically fix what it can, then go through some of the things manually (nudge buildings that are touching a road, etc.). There do tend to be a fair number of warnings I ignore though - figuring I'll get to them some other day (like ways crossing where a road crosses a stream without a bridge. Sometimes, there are bridges there in reality, and sometimes the streams are small enough that only culverts are used. They should be flagged differently, but without a site visit, there is no way to tell, so I just leave them as is). - Finally, then I'll upload the data. Inevitably, there will be 2 or 3 conflicts along the lines of my deleting a node that the server still needed for something else. In those cases, I tell it to undelete my node (ie: keep the one on the server). I wish there was a way to have that as some kind of "default" action instead of going through them one by one... - I go back to look at the area at OpenStreetMap after a bit once things have had the chance to render, to make sure that it looks generally right. As far as "things going wrong", I do have a spotty Internet connection, and on more than one occasion, have had some sort of network error midway through an upload (I have my uploads set to upload data in chunks of 500 objects). Sometimes, when the Internet comes up again to allow me to continue, I find that my changeset was automatically closed. It's looked to me like JOSM jus
Re: [Talk-ca] Topomaps (was Re: An introduction)
I'm not altogether sure yet of the license the renderings will be under - I'm the technical, not the legal guy. I don't suspect it will be too restrictive, though I'm pretty sure we will want to limit access (particularly batch downloads) to the tile server itself to the users of our iPod/iPad/iPhone software - after all, we wouldn't want to be paying for high volumes of Internet traffic to our server by competing apps downloading tens of thousands of tiles :-) I think high volume access to our server would be the biggest issue, and don't anticipate there will be much of a problem with people using the renderings themselves for whatever purpose they want (with the standard liability disclaimers) as long as volume is low or they are using the software we provide (which adds a few layers of additional logic to aggressively cache images unless the server-side renderings change significantly - again, to keep the bandwidth down as much as possible). All I know for sure though are that the details haven't been finalized yet. Dan On 2011-Feb-05, at 2:01 AM, Sam Vekemans wrote: > Cool, > I'll keep it on my todo list :) > the .osm files will be public domain and the garmin maps need to be > 'do not sell' because cgpsmapper gets used in the process. > > What licence will your slippymap raster renderngs be in? > > > cheers, > Sam > > On 2/4/11, Dan Charrois wrote: >> Oh - I'm sure you must be right about that. I should have read more >> carefully. >> >> Thanks! >> >> Dan >> >> On 2011-Feb-04, at 4:12 PM, Kevin Michael Smith wrote: >> >>> On Fri, 2011-02-04 at 15:57 -0700, Dan Charrois wrote: >>>> Hi Sam! >>>> >>>> Where have you found SRTM data at 20 meter intervals? The only data I've >>>> found was 3 arcsec (~90m) worldwide, and 1 arcsec (~30) just for the >>>> United States. As far as I knew, 1 arcsec data was all that was >>>> collected, but even that wasn't released beyond the U.S. borders. >>> >>> I think he means a 20m vertical interval between contour lines, not the >>> horizontal resolution of the DEM. >>> >>> -- >>> Kevin Michael Smith >> >> -- >> Syzygy Research & Technology >> Box 83, Legal, AB T0G 1L0 Canada >> Phone: 780-961-2213 >> >> >> ___ >> Talk-ca mailing list >> Talk-ca@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-ca >> > > > -- > Twitter: @Acrosscanada > Blogs: http://acrosscanadatrails.posterous.com/ > http://Acrosscanadatrails.blogspot.com > Facebook: http://www.facebook.com/sam.vekemans > Skype: samvekemans > IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) > @Acrosscanadatrails -- Syzygy Research & Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Topomaps (was Re: An introduction)
Oh - I'm sure you must be right about that. I should have read more carefully. Thanks! Dan On 2011-Feb-04, at 4:12 PM, Kevin Michael Smith wrote: > On Fri, 2011-02-04 at 15:57 -0700, Dan Charrois wrote: >> Hi Sam! >> >> Where have you found SRTM data at 20 meter intervals? The only data I've >> found was 3 arcsec (~90m) worldwide, and 1 arcsec (~30) just for the United >> States. As far as I knew, 1 arcsec data was all that was collected, but >> even that wasn't released beyond the U.S. borders. > > I think he means a 20m vertical interval between contour lines, not the > horizontal resolution of the DEM. > > -- > Kevin Michael Smith -- Syzygy Research & Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Topomaps (was Re: An introduction)
nal to work on. I'd offer up the URL of our slippy map server to let people look, play around, and offer suggestions, but since we're still testing, it's only available on our corporate Intranet at the moment - not on the public Internet yet. But I made a couple of screen snapshots available, zooming in on the area around Revelstoke, BC. They're available at: http://www.syz.com/topomap/ I'm always looking for feedback! Dan On 2011-Feb-04, at 2:40 AM, Sam Vekemans wrote: > Hi, > Welcome :) > One of my projects is to create a planet set of Transparent Contour > maps for Garmin GPS Device and MapSource, taking the SRTM data at 20 > meter intervals. > One option is to create and save .osm files of this contour data, at > 1x1 degree size. (if its needed) > > > Is this anywhere near your radar of working/interest? > > > (and of course, OpenStreetMap garmin tiles can easily be used ontop). > > > I thought about using the geobase contours, but GroundTruth SRTM data > would get planet-wide consistancy, to be used as a start, especially > where no other options are available. > > > Thanks, > Sam > > On 2/3/11, Dan Charrois wrote: >> Hi everyone. Though I've communicated with a few of you on this mailing >> list directly, I thought I'd take a few moments to introduce myself to >> everyone else as a sort of newcomer to OSM. >> >> I say a "sort of" newcomer, since I first discovered OSM a year or two ago, >> and fiddled around with adding a few amenities here and there, but never >> really became more significantly involved until recently. Here's a bit of >> background... >> >> I'm not a professional cartographer, GIS expert, or anything like that... >> but I have been an mapping enthusiast for pretty much forever. As an >> astronomer (amateur mostly now, but having worn the "professional" hat for a >> few years), I was frustrated at the time by the lack of accuracy in >> astronomical simulation software, so took on the project of writing >> commercial software that, among other things, mapped more than 20 million >> celestial objects considering all kinds of subtle effects to their apparent >> positions. After the experience of doing that, I was hooked on mapping in >> general, and the science of figuring out where things are. I've since come >> somewhat back to Earth and have been involved with GPS since the years where >> Selective Availability was an issue to contend with (which dates myself :-), >> both on the hardware side (some of you have recognized me from being the >> Canadian distributor for Garmin-compatible plugs), as well as the software >> side (I've written software for carrier phase, cm-level positioning for >> single frequency OEM GPS boards). At least on the Earth, things stay >> relatively still :-) >> >> I then spent several years on non-mapping projects, which still take up the >> majority of my time, but have recently been able to sideline back into the >> arena with iPhone/iPad/iPod mapping software I'm currently developing, using >> OSM data - a cacheable, topographical map of the Earth. The project has >> involved setting up our own slippy map server merging OSM data with high >> resolution contour vector information and hillshaded raster data, and of >> course significantly tweaking the stylesheet for map rendering to remain >> visible and "appealing" over the additional elevation information. We're in >> the testing phases now, so it's not quite ready for release yet - I >> anticipate a month or two. The intent is to have this first foray into the >> iPhone/iPad/iPod world to serve as a jumping off point for other >> location-based ideas we have. >> >> And of course, getting more involved with OSM data for the project I'm >> working on has made me become much more active on doing my small part to >> continue to improve the resource. Pretty much any time I travel anywhere, a >> GPS track log follows me (sometimes on several devices), and I'm not the >> sort of person to let that information go to waste, so I'm often tweaking >> bits and pieces of OSM data in my neck of the world from that. I've also >> gotten more involved recently in the merging of Canvec data around Alberta >> into OSM, and will likely continue to do so in places I'm familiar with >> (Alberta and BC mostly). I'm using JOSM, and am always interested in >> hearing tips others have learned in terms of streamlining the process of >> adding information while at the same time being
[Talk-ca] An introduction
Hi everyone. Though I've communicated with a few of you on this mailing list directly, I thought I'd take a few moments to introduce myself to everyone else as a sort of newcomer to OSM. I say a "sort of" newcomer, since I first discovered OSM a year or two ago, and fiddled around with adding a few amenities here and there, but never really became more significantly involved until recently. Here's a bit of background... I'm not a professional cartographer, GIS expert, or anything like that... but I have been an mapping enthusiast for pretty much forever. As an astronomer (amateur mostly now, but having worn the "professional" hat for a few years), I was frustrated at the time by the lack of accuracy in astronomical simulation software, so took on the project of writing commercial software that, among other things, mapped more than 20 million celestial objects considering all kinds of subtle effects to their apparent positions. After the experience of doing that, I was hooked on mapping in general, and the science of figuring out where things are. I've since come somewhat back to Earth and have been involved with GPS since the years where Selective Availability was an issue to contend with (which dates myself :-), both on the hardware side (some of you have recognized me from being the Canadian distributor for Garmin-compatible plugs), as well as the software side (I've written software for carrier phase, cm-level positioning for single frequency OEM GPS boards). At least on the Earth, things stay relatively still :-) I then spent several years on non-mapping projects, which still take up the majority of my time, but have recently been able to sideline back into the arena with iPhone/iPad/iPod mapping software I'm currently developing, using OSM data - a cacheable, topographical map of the Earth. The project has involved setting up our own slippy map server merging OSM data with high resolution contour vector information and hillshaded raster data, and of course significantly tweaking the stylesheet for map rendering to remain visible and "appealing" over the additional elevation information. We're in the testing phases now, so it's not quite ready for release yet - I anticipate a month or two. The intent is to have this first foray into the iPhone/iPad/iPod world to serve as a jumping off point for other location-based ideas we have. And of course, getting more involved with OSM data for the project I'm working on has made me become much more active on doing my small part to continue to improve the resource. Pretty much any time I travel anywhere, a GPS track log follows me (sometimes on several devices), and I'm not the sort of person to let that information go to waste, so I'm often tweaking bits and pieces of OSM data in my neck of the world from that. I've also gotten more involved recently in the merging of Canvec data around Alberta into OSM, and will likely continue to do so in places I'm familiar with (Alberta and BC mostly). I'm using JOSM, and am always interested in hearing tips others have learned in terms of streamlining the process of adding information while at the same time being faithful to the data already available in OSM which is often (though not always) of better quality or utility than Canvec on its own. In any case, that's my story in a nutshell. I've been lurking here on the sidelines of OSM for long enough, so thought that now would be as good a time as any to say "hi"! Dan -- Syzygy Research & Technology Box 83, Legal, AB T0G 1L0 Canada Phone: 780-961-2213 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
