Re: [Talk-ca] (no subject)
If it becomes over 2000 nodes in a single "way" or shape, it's recommended to make it a multipolygon. The reason NRCan does this is probably because it's on the edge of what they call "NTS Tiles" which is a grid that organizes the data (see forests in Canada https://wiki.openstreetmap.org/wiki/Canada#What.27s_with_the_forests_in_Canada.3F). Importers just didnt join them back in the day, that's all On Tue, Jul 7, 2020 at 5:02 AM Hannes Röst wrote: > Hello > > I am a contributor from Toronto and I have a question regarding how to > treat some of the CanVec 6.0 - NRCan imports, specifically for lakes. > I came across this lake here: > > https://www.openstreetmap.org/way/69275451 > https://www.openstreetmap.org/way/69277932 > https://www.openstreetmap.org/way/69745752 > > Which is strangely split up into 3 parts and I wonder how to proceed: > should we fix this and create a single way out of these 3 parts or is > it beneficial (for comparison to future NRCan database entries) to > keep them that way and create a relation out of the three? Also, does > somebody know why the NRCan dataset does this, is this an import > artefact (splitting into tiles?) or is it part of the original > dataset? > > Best > > Hannes Rost > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca > ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] (no subject)
Hello I am a contributor from Toronto and I have a question regarding how to treat some of the CanVec 6.0 - NRCan imports, specifically for lakes. I came across this lake here: https://www.openstreetmap.org/way/69275451 https://www.openstreetmap.org/way/69277932 https://www.openstreetmap.org/way/69745752 Which is strangely split up into 3 parts and I wonder how to proceed: should we fix this and create a single way out of these 3 parts or is it beneficial (for comparison to future NRCan database entries) to keep them that way and create a relation out of the three? Also, does somebody know why the NRCan dataset does this, is this an import artefact (splitting into tiles?) or is it part of the original dataset? Best Hannes Rost ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] (no subject)
On Jan 19, 2019, at 10:48 AM, john whelan wrote: > There was an earlier discussion on talk-ca about how to handle this project. There were MANY. Speaking for myself only, I urged a very cautious, go-slow approach, to edit the data into "improvement / harmony-with-OSM" as much as possible BEFORE they upload to be imported, (or document in the wiki HOW this was to happen), to use talk-ca, Tasking Manager and especially to develop and use a freshly-rewritten (and undergoing continuous improvement) wiki (this part was a/the major failing, imo) to communicate. But that is looking in the rear-view mirror, and I don't like to hear "told you so," let alone say it. > It is similar to CANVEC in the original data sources are municipal data > CANVEC uses a few other sources as well and it is released under exactly the > same license but by a different federal government department. CANVEC data are roundly criticized. And it doesn't matter where those data came from (CANVEC), nor where the present data come from (Stats Canada). They are now "in the wild" and from an OSM perspective (what matters here and now), their source is essentially meaningless, except for historical context. > There are 3,700 municipalities in Canada. How do you deal with that? With good planning, using the tenets of OSM (e.g. the Import process, gaining consensus, good communication and appropriate tools like wiki, Tasking Manager and JOSM plug-ins where they make sense). You DON'T try to short-circuit that by wholesale re-writing a re-write of the seed project wiki (now well-vetted, as if it were it were, and I tried, would have widely been seen as lacking), posting notice on talk-ca and waiting two weeks independent of their being very little feedback on so gigantic a process (a massive red flag). In short, this was a huge "failure of consensus." Look at the posts now which say "I woke up to a mess." That simply shouldn't happen. > A suggestion was made on talk-ca we have one import plan that way it would at > least be consistent and that's what we did. This import plan, coming from the BC2020 wiki, which as written by Julia left a LOT to be desired as to technical specifics. I characterized this as "cheerleading and buzzword-compliant," sorry Julia, but it was and hence was ineffective as a wiki for its intended purposes, which is to answer questions of those who need technical guidance in an endeavor to have their "how?" questions appropriately answered. That's what wikis do, they are good at it, OSM expects this, so when a wiki fails to deliver, the project experiences failures. That absolutely should not surprise. > Mentally I'd split the project into getting an import plan that met all the > requirements and the actual importing. Um, yeah. > To me the importing would be done by local mappers or mappers with a local > connection after a local discussion which is what happened in Kingston. For > locations that did not have such mappers then over time they could be tackled > at a distance. One comment I recall was this was more of a marathon and to be > honest we expected it to take place over a fair length of time. A lot of > buildings have gone in much faster than I expected. So, plan for that. Manage that. If it isn't happening, make it happen with outreach and OSM's usual tactics of "developing community." OSM has been doing this for over 15 years (and gets better at it), but it isn't "a hope and a prayer," it is continual engagement, effort (technical and social) and mid-course correction when necessary, all while keeping a hawkish eye on the finish line. > For the pilot project with Ottawa the local Ottawa mappers were heavily > involved. We learnt a fair bit on the way and that's why we basically cloned > the Ottawa import plan. We noticed a lot of additional tags being added to > the building=yes and that to be was a good thing in that it drew more people > into OSM. I'm much more interested in those additional tags than anything > else. Crowdsourced projects often yield unexpected positive results. This is what our project means when we say our data get used "in creative, productive, or unexpected ways." It happens (a lot), this is one of the best things about OSM. > As far as I am aware there is no list of local OSM communities in Canada and > to be honest many mappers simply map and do not gather once a month at OSM > meetings. So? We don't need no stinkin' meetings, though all are welcome at meetings. > I don't think we do an import plan every time we bring something across from > CANVEC. Shame on whoever does this, it is wrong (from OSM's perspective, and this is OSM). > Unfortunately there really is a demand for this sort of information. The > initial 2020 meeting that took place at Stats Canada during the HOT summit in > Ottawa had many people from government departments who were very interested > in the data and especially what I call
[Talk-ca] (no subject)
There was an earlier discussion on talk-ca about how to handle this project. It is similar to CANVEC in the original data sources are municipal data CANVEC uses a few other sources as well and it is released under exactly the same license but by a different federal government department. There are 3,700 municipalities in Canada. How do you deal with that? A suggestion was made on talk-ca we have one import plan that way it would at least be consistent and that's what we did. Mentally I'd split the project into getting an import plan that met all the requirements and the actual importing. To me the importing would be done by local mappers or mappers with a local connection after a local discussion which is what happened in Kingston. For locations that did not have such mappers then over time they could be tackled at a distance. One comment I recall was this was more of a marathon and to be honest we expected it to take place over a fair length of time. A lot of buildings have gone in much faster than I expected. For the pilot project with Ottawa the local Ottawa mappers were heavily involved. We learnt a fair bit on the way and that's why we basically cloned the Ottawa import plan. We noticed a lot of additional tags being added to the building=yes and that to be was a good thing in that it drew more people into OSM. I'm much more interested in those additional tags than anything else. As far as I am aware there is no list of local OSM communities in Canada and to be honest many mappers simply map and do not gather once a month at OSM meetings. I don't think we do an import plan every time we bring something across from CANVEC. Unfortunately there really is a demand for this sort of information. The initial 2020 meeting that took place at Stats Canada during the HOT summit in Ottawa had many people from government departments who were very interested in the data and especially what I call enriched data, ie buildings with addresses and other tags. Smaller school boards have expressed an interest in routing school buses using this sort of data. There is an app for the blind that guides you to the building but the building and address have to be on the map. Should we care what end users are interested in? I think that is a separate discussion. There always has been a range of views within OpenStreetMap. I have certainly been taken to task for changing a tag from traffic_lights to traffic_signals. "I mapped it and I tagged it traffic_lights and it should remain that way." Toronto was almost certainly going to be troublesome. I recall someone saying once if you gather five book classifiers together they will find six ways to classify a book. The Ottawa community is reasonably small and many meet up from time to time. In a city such as Toronto my expectation would be a much wider range of opinions. This makes it very difficult to identify if something is approved or not. It also means that my expectation that the importing mapper will use a bit of common sense and we shouldn't need to spell out things like "replace geometry tool" other mappers will have other expectations. My understanding of importing or drawing a building outline from imagery is it gets tagged building=yes and you can do no better from imagery. Occasionally you might see a building in a residential area that has two drives, I might just tag that semi. Then we throw in the 2020 project. Stats initial idea was to simply have every building mapped in Canada with iD and mapathons were a wonderful idea. Technically it is possible to accurately map a building from imagery with iD I've seen it done. You may wish to talk to Pierre about data quality from those mapathons. I had talked to Stats about getting the building outlines released under a suitable license. It only took a year to persuade the City of Ottawa to change their Open Data license to one that worked with OpenStreetMap. Stats came back some time later by releasing some building outline data under the federal government Open Data license and that's where this bit started. The 2020 project has a lot of interest from GIS departments, High Schools are thinking of how to get involved with their students. Adding tags is a lot safer and less error prone than drawing buildings in iD. Education is one area that Stats gets brownie points for so they like to promote it. Microsoft has been running the same algorithms on Canada as it has in the US. We can expect their building outlines to be released shortly. Data quality, by the time its been converted from one format to another and comes form a variety of systems some municipal data will be better than others. The data I've looked at looks reasonable however my expectations and your expectations maybe different. You might like to add a step or two into the wiki. We could do a table in the wiki with a list of communities that feel comfortable with the import. That might be troublesome, two high school students
[Talk-ca] (no subject)
Plusieurs (et j'en suis) ont exprimé leur désir d'avoir une meilleure couverture de forêt sur la carte OSM. Ces zones de forêt sont venues avec les importations CanVec mais ne progressent plus depuis un certain temps. Le présent article propose une façon de réaliser la forêt sans utiliser les abus de la méthode CanVec. Voyons un exemple. Dirigez votre éditeur préféré vers -74.375/46.1875 ou visionnez: http://www.openstreetmap.org/#map=16/46.1875/-74.3750 Vous y verrez deux tuiles de forêt. Chacune a été crée avec un rectangle de type natural:wood. Un simple rectangle de 4 points qu'on peut créer facilement. Cette tuile peut être vue simplement avec: http://openstreetmap.org/way/307466266 Voyons un autre exemple un peu plus à l'ouest (-74.500/46.1875). Dans votre éditeur, sélectionner la ligne qui délimite la tuile sud-ouest. On peut constater qu'elle est beaucoup plus complexe. On peut voir l'ensemble de cette ligne avec: http://openstreetmap.org/way/307466267 Elle est composée d'environ 1600 points. Elle est complexe parce qu'elle utilise l'approche everything but the kitchen sink. La tuile définit non seulement la forêt mais aussi les lacs, les rivières et les clairières. Pire encore, ce chemin de 1600 points fait partie d'une relation qui contient plusieurs dizaines de tels chemins. Affichez http://www.openstreetmap.org/relation/2368823 et remarquez le temps de chargement de la page. Revenons au premier exemple: http://www.openstreetmap.org/#map=14/46.1875/-74.3750 La forêt est un simple rectangle mais les lacs, les rivières et les chemins se superposent à la forêt. Il n'est donc pas nécessaire que le contour de forêt suive le contour des lacs et des rivières. Il y a un gain énorme en simplicité. Voyons un autre problème des tuiles CanVec: http://www.openstreetmap.org/#map=17/46.25047/-73.24885 Pour comprendre pourquoi il y a 3 Lac Laporte il faut utiliser l'éditeur: http://www.openstreetmap.org/edit?editor=id#map=17/46.25047/-73.24885 Les tuiles CanVec ont divisé le lac en 3 parties et ont créé 3 entités natual:water, chacune avec le nom Lac Laporte. Pas fort! Sur la même image, remarquez que le chemin Montée Ouest est fait de 2 segments de couleur différente. C'est parce que ce chemin a été défini de 2 façons différentes et, par conséquent, on ne peut pas fusionner les 2 segments ensemble. L'un des segments vient de CanVec6 et l'autre de CanVec7. Belle rigueur! C'est un non-sens qu'une entité soit séparée en plusieurs parties parce qu'elle est à cheval sur une tuile. Le but de mon intervention est d'affirmer qu'il ne faut plus importer de tuile CanVec dans sa forme actuelle. Elles rend la carte lourde et difficile à éditer par des humains. Peut-on remplacer les tuiles de forêt par de simples rectangles? Oui et non. Les tuiles CanVec sont des multi-polygones et celà permet des trous. Ces trous sont utilisés (entre autres) pour représenter des clairières. Donc, au lieu d'un rectangle, on pourrait utiliser un multi-polygone avec des trous. Mais est-ce bien la bonne façon? Un trou (tel qu'uitlisé par CanVec) définit une zone undefined qui apparaît en blanc sur la carte. Ne serait-il pas mieux de créer une entité heath (ou autre) pour représenter cette clairière? Une clairière n'est pas un trou dans une forêt, tout comme une île n'est pas un trou dans un lac. J'aimerais qu'il y ait une discussion sur les points suivants: 1) est-ce que les tuiles CanVec sont la meilleure façon de représenter la forêt? 2) si non, peut-on définir une stratégie pour les remplacer (à long terme) 3) Pour les tuiles forêt, devrait-on utiliser un rectangle avec clairière explicite? 4) Pour les tuiles forêt, devrait-on utiliser un multi-polygone avec trous? J'espère que cette discussion nous fera progresser vers une carte de meilleure qualité et une meilleure performance. dega ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] (no subject)
Sur le blog de la Fondation OSM, on remerciait hier la dynamique association de Pau, dans les Pyrénées françaises pour l'installation d'un serveur de tuiles OSM. Ce serveur est devenue officiellement hier un serveur de cache de tuiles d'OpenStreetMap couvrant la France , l'Espagne, le Portugal, Andorre, Gibraltar, l'Italie, Monaco, San Marino et le Vatican. On remerciait également Christophe Merlet de Redfox, qui a organisé cette donation à la Fondation. Celui-ci annonce ce matin sur Talk-fr, qu'en plus une carte OSM en français est disponible à l'adresse http://tile.paulla.asso.fr/openlayers.html Merci à Christophe pour ses belles initiatives. voir http://blog.osmfoundation.org/2012/12/18/new-tile-server-in-pau-france/ voir le blog de l'Association de Pau http://www.paulla.asso.fr/ Pierre ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] (no subject)
Could you please unsubscribe me? Thank you! -- Clément Le Quintrec | (514) 692 8341 | ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] (no subject)
I'm doing some work in the Washington State and noticed some problems along the border between BC and Washington State. I asked for help on the talk-us mailing list. I originally though the border was incorrect. However, because the border doesn't track exactly along the 49th parallel there appears to be some administrative areas that don't match up with the actual border. See http://www.openstreetmap.org/?lat=48.9803lon=-121.7579zoom=12layers=M Paul Norman wrote: On Mon, Sep 17, 2012 at 5:49 PM, Paul Norman penor...@mac.com wrote: The survey points are based on IBC data (which they view as PD) and are supposed to be accurate within a few cm and the limits of NAD83 to WGS84 conversion (a few more cm). I’ve verified a few by the lower mainland with survey and against a few sources of accurate imagery and their data seems accurate within the limits of the imagery. You can see a clearing along parts of the border in that area so it’s accurate to within 20 meters. I know that Washington State argued that they were not responsible for the border costs in Blaine because it was not part of the state since the state ended at the 49th parallel and the border is north of the 49th there. What I’ll do is go and eliminate duplicate border ways, like I did with the lower mainland. There is a large multipolygon with a source of CanVec 6.0 - NRCan that should probably extend to the border. However I'm not sure. I'm wondering if anyone in Canada could investigate. The area is defined as natural=wood. BTW - I'm using USDA National Forest Services Topo Maps to add in rivers, streams, etc. I see streams coming into the US from BC, but we don't have any corresponding stream in Washington. Clifford I have promised to cut down on my swearing and drinking, which I have. Unfortunately, this has left me dim-witted and nearly speechless. Adapted from *The Lion* by Nelson DeMille -or- If you can't explain it simply, you don't understand it well enough. Albert Einstein ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] (no subject)
Pierre I beg to differ, the OSM wiki states The place=locality tag can be used to name unpopulated place which is not associated with any feature to which such a tag could be associated. By default many small or unpopulated places are tagged as localities in canvec. When I preformed the upload along a remote northern rail line, I checked the community against a Government of Manitoba list and the census to determine if a place was populated. We do need some sort of tagging to indicated the railway significance, but I have used place=locality on road locations in both urban and rural environments as well (http://osm.org/go/Wpz83vHj2-- and http://osm.org/go/Wp5TRnmtN--). Sam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] (no subject)
On Thu, Feb 23, 2012 at 10:02 AM, Sam Dyck samueld...@gmail.com wrote: I beg to differ, the OSM wiki states The place=locality tag can be used to name unpopulated place which is not associated with any feature to which such a tag could be associated. By default many small or unpopulated places are tagged as localities in canvec. When I preformed the upload along a remote northern rail line, I checked the community against a Government of Manitoba list and the census to determine if a place was populated. We do need some sort of tagging to indicated the railway significance, but I have used place=locality on road locations in both urban and rural environments as well (http://osm.org/go/Wpz83vHj2-- and http://osm.org/go/Wp5TRnmtN--). *Disclaimer*: *I am speaking only for myself and not in any official capacity for my employer, Statistics Canada.* When I think locality, I tend to think of a place, populated or otherwise, that has been designated by some level of government, but that's because of where I work. :) Statistics Canada had a concept called a locality that was used up to the 2006 Census. In 2011 it has been merged with place name, the definition of which is selected named of active and retired geographic areas as well as nams from the Canadadian Geographical Names Database. Place names include names of census divisions (municipalities), designated places and population centres, as well as the names of some local places. The Census Dictionary also notes that prior to 2011, the term 'locality' was used to describe historical place names, such as former census subdivisions (municipalities), designated places and urban areas. (ref: http://www12.statcan.gc.ca/census-recensement/2011/ref/dict/geo033-eng.cfm) I seem to recall from when I worked in the Geography Division here that localities and place names were from official sources (i.e. the various levels of government). Building on that, named points along a railway would not be considered localities because they are operational reference points designated by the railway operator, much like IFR intersections used in the aviation world. Using place=locality on road locations, on the other hand, would make sense because of who designated the name. As I mentioned above, *I am speaking only for myself and not in any official capacity for my employer, Statistics Canada*. Cheers! --G* * ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] (no subject)
Actually both of the highway locations I cited are not from any database, but reflect the local names for the intersection. On 2/23/12, Gordon Dewis gor...@pinetree.org wrote: On Thu, Feb 23, 2012 at 10:02 AM, Sam Dyck samueld...@gmail.com wrote: I beg to differ, the OSM wiki states The place=locality tag can be used to name unpopulated place which is not associated with any feature to which such a tag could be associated. By default many small or unpopulated places are tagged as localities in canvec. When I preformed the upload along a remote northern rail line, I checked the community against a Government of Manitoba list and the census to determine if a place was populated. We do need some sort of tagging to indicated the railway significance, but I have used place=locality on road locations in both urban and rural environments as well (http://osm.org/go/Wpz83vHj2-- and http://osm.org/go/Wp5TRnmtN--). *Disclaimer*: *I am speaking only for myself and not in any official capacity for my employer, Statistics Canada.* When I think locality, I tend to think of a place, populated or otherwise, that has been designated by some level of government, but that's because of where I work. :) Statistics Canada had a concept called a locality that was used up to the 2006 Census. In 2011 it has been merged with place name, the definition of which is selected named of active and retired geographic areas as well as nams from the Canadadian Geographical Names Database. Place names include names of census divisions (municipalities), designated places and population centres, as well as the names of some local places. The Census Dictionary also notes that prior to 2011, the term 'locality' was used to describe historical place names, such as former census subdivisions (municipalities), designated places and urban areas. (ref: http://www12.statcan.gc.ca/census-recensement/2011/ref/dict/geo033-eng.cfm) I seem to recall from when I worked in the Geography Division here that localities and place names were from official sources (i.e. the various levels of government). Building on that, named points along a railway would not be considered localities because they are operational reference points designated by the railway operator, much like IFR intersections used in the aviation world. Using place=locality on road locations, on the other hand, would make sense because of who designated the name. As I mentioned above, *I am speaking only for myself and not in any official capacity for my employer, Statistics Canada*. Cheers! --G* * ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] (no subject)
Confusion Corner reminded me of The Basketweave on the 401 in Toronto. http://www.openstreetmap.org/?lat=43.71829lon=-79.50048zoom=17layers=M Here a mapper has tagged the node as an attraction. On Thu, Feb 23, 2012 at 11:23 AM, Sam Dyck samueld...@gmail.com wrote: Actually both of the highway locations I cited are not from any database, but reflect the local names for the intersection. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] (no subject)
Hi, It's my mistake. It should disappear with the next rendering of the map since I've delete it using JOSM. I tried to import roads using the script Michel Gilbert have used to generate the administrative boundaries. I guess I should have looked closer to the script. Shouldn't happen twice... Jean-Sebastien Moreau Ressources naturelles Canada / Natural Resources Canada Centre d'information topographique / Centre for Topographic Information Gouvernement du Canada / Government of Canada 2144-010 rue King Ouest, Sherbrooke (Québec) Canada J1J 2E8 2144-010 King West Street, Sherbrooke, Quebec, Canada J1J 2E8 téléphone / phone: 819.564.5600 ext. 252 télécopieur / facsimile: 819.564.5698 email: jmor...@usherbrooke.ca From: talk-ca-boun...@openstreetmap.org [mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Samuel Dyck Sent: January 26, 2009 6:42 PM To: talk-ca@openstreetmap.org Subject: [Talk-ca] (no subject) Hi What's with the Geobase import of Lorette, MB? The roads are tagged as admin. boundries. hr emPlease avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html/em Now with a new friend-happy design! Try the new Yahoo! Canada Messenger http://ca.beta.messenger.yahoo.com/ ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
