Re: [Talk-ca] Building import in BC and Quebec
As an experienced local Ontario and Quebec mapper I don't see any major problems with Stats Can building quality. It's detailed and recent, it's the best dataset we could ever possibly get and it's far superior to Microsoft quality. Having many buildings with "almost square angles" in this dataset is not an issue as vast majority of such deviations cannot be seen with a naked eye. Unfortunately any orthogonalization algorithms will do more harm than good in such cases. Mapping for the Validator, just like mapping for the Renderer is a wrong way to map. Issues were raised, issues were addressed in the import plan. If there are any problems with some mappers violating any specific import plan rules such issues need to be pointed out so they can adjust their workflow. My 2 cents. On Fri, Mar 15, 2019 at 10:55 AM Nate Wessel wrote: > I just reported this to the data working group, in case you haven't > already. Hopefully they will step in! > > Cheers, > Nate Wessel > Jack of all trades, Master of Geography, PhD candidate in Urban Planning > NateWessel.com <http://natewessel.com> > > On 3/15/19 10:30 AM, Pierre Béland wrote: > > Réponse immédiate avec refus de discussion de la part de DannyMcD_imports. > Celui-ci indique qu'il prévoit continuer l'import. > voir https://www.openstreetmap.org/changeset/67686901 > > There was a discussion, issues were raised, the problems (to the extent > that they existed at all) have been addressed. I plan to continue > importing, unless a *specific* valid issue is raised. Please do not contact > me again unless you have such an issue. > > La prochaine étape est je pense de contacter le Data Working Group. > > > Pierre > > > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca > -- Best Regards, Yaro Shkvorets ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Building Import update
option is available to any other areas who would like to use
>> this method.
>>
>> I feel for Quebec the best thing to do is hold back until we have an
>> agreement for the rest of the country since there are Quebec mappers who
>> are not following this thread on talk-ca and to be honest we do seem to be
>> evolving on a hourly basis so waiting until the dust settles might well be
>> sensible.
>>
>> Am I missing something apart from my sanity?
>>
>> Thanks John
>>
>> On Sun, 3 Feb 2019 at 17:07, Pierre Béland wrote:
>>
>>> Je suggère oui, d'abord le script avec 2 fichiers d'output parce
>>> qu'ensuite il sera beaucoup plus simple d'importer les données déja
>>> corrigées. Sinon une variable pour distinguer les deux et risque de
>>> l'importer dans OSM ? Et je pense à un autre aspect. Le script pourrait
>>> s'assurer qu'il n'y a pas de superpositions entre bâtiments une fois les
>>> données corrigées.
>>>
>>> L'importation des données orthogonales devrait être grandement
>>> facilitée. Selon l'exemple d'Ottawa, quelque 75% des bâtiments répondent à
>>> ce critère une fois les polygones qasi-orthogonaux corrigés. Pour ces
>>> données, il s'agirait davantage de valider avec l'imagerie et de faire la
>>> conflation avec les données existantes.
>>>
>>> Pour l'importation des données irrégulières, il faudrait oui valider /
>>> corriger. A ne pas oublier que dans ce cas on retrouve des angles qui
>>> s'éloignent de plus de 5 degrés vs données orthogonal. C'est visuellement
>>> facile à repérer. Souvent, il s'agirait simplement avec JOSM d'utiliser la
>>> touche «Q» pour orthogonaliser. De nombreux appendices de batiments on un
>>> angle prononcé dans le fichier et cela peut etre redressé à 90 degrés. Le
>>> greffon ToDo est très utilie pour réviser successivement des données et
>>> s'assurer de toutes les réviser.
>>>
>>> A titre d'exemple, on peut décider d'orthogonaliser le bâtiment
>>> ci-dessous avec beaucoup d'angles se rapprochant de 90 degrés mais avec une
>>> variance plus grande que +-5 degrés. Pour détecter davantage de bâiments
>>> quasi-orthogonaux, il serait possible de tenir compte de cette situation
>>> uniquement pour angles à 90 avec critère tolérance +-10 degrés. Je vais
>>> tester cette option et voir si cela permettrait de détecter un grand nombre
>>> de cas.
>>> angles entre 82.6 et 94.5 degrés
>>>
>>> {82.6,85.7,87.4,90.3,96,94.5,85.5,84.8,91,90.8,89.3,89.8,90.4,91.1,91.1,93.6,87.1,82,87.3,84.7}
>>> https://www.openstreetmap.org/way/479048070
>>>
>>> Pierre
>>>
>>>
>>> Le dimanche 3 février 2019 15 h 45 min 33 s HNE, john whelan <
>>> jwhelan0...@gmail.com> a écrit :
>>>
>>>
>>> I accept the nicest way is to check the data beforehand. Scripting it
>>> is fairly simple. Are you suggesting a two stage process of take the data
>>> and run the script first then task manager the data to be imported to
>>> manually correct the data? My eyesight isn't good enough to pick out none
>>> right angled corners so is there some way someone can come up with to feed
>>> them into a JOSM todo list?
>>>
>>> However we have a fairly large number of building outlines that have
>>> already been imported. The issue here is different as extra tags have been
>>> added. Can the questionable ones be identified in such a way that a JOSM
>>> todo list can be used to correct them rather than throw out all the work
>>> that has been done adding tags?
>>>
>>> I think you are assuming a more top down management arrangement than
>>> exists with volunteer Canadian mappers.
>>>
>>> Thanks John
>>>
>>> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
--
Best Regards,
Yaro Shkvorets
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Some feedback on import quality in Toronto
Thanks, it works. Need to run it a few times it looks like. On a random Markham block went from 88 warnings down to 4 without ruining geometries, which is acceptable IMO. May need to look into its parameters (validator.RightAngleBuilding.maximumDelta and validator.RightAngleBuilding.minimumDelta) to tweak it for our data. I've looked into CADTools and BuildingGeneralization plugins but unfortunately they don't work properly destroying geometries and rotating polygons. On Mon, Feb 4, 2019 at 10:31 AM Danny McDonald wrote: > In JOSM, open the preferences dialog (F12), go to the data validator tab, > and click the "show informational level" checkbox (it is third from the > top). Any validation done will then check for "Building with an almost > square angle", which will appear under the Other tab. "Building with an > almost square angle" used to cause a Warning, but it was downgraded to > Other due to complaints - see https://josm.openstreetmap.de/ticket/16280. > Danny > > On Mon, Feb 4, 2019 at 9:45 AM Yaro Shkvorets wrote: > >> Danny, >> Do you mind sharing how to fix almost square angles in JOSM? I remember >> seeing such warning a year or two ago but for some reason I don't see it >> anymore and can't find it in the Validator settings. >> Did they remove it from the latest version of JOSM or you need to add >> this rule manually? >> If there is an easy way to do it then we should do it I guess. >> >> On Sun, Feb 3, 2019 at 7:51 PM Danny McDonald >> wrote: >> >>> I largely agree with Yaro, but will say >>> 1) It is possible to square almost square angles with JOSM - it has an >>> informational warning in validation, and automatically squares the angle by >>> slightly moving the offending node. This fix doesn't ruin the geometry of >>> the building, as pressing Q so often does. Unfortunately, it also leads to >>> other angles in the building not being square. >>> 3) I'm fine with importing smaller buildings as well (they don't seem to >>> be in the source data in Toronto, they are for some of the other data >>> sets). I believe they were excluded because of their relatively low >>> importance/permanence. >>> >>> I would also like to know how the Toronto building footprints were >>> produced. Does anyone know? >>> DannyMcD >>> >>> ___ >>> Talk-ca mailing list >>> Talk-ca@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-ca >>> >> >> >> -- >> Best Regards, >> Yaro Shkvorets >> > -- Best Regards, Yaro Shkvorets ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Some feedback on import quality in Toronto
Danny, Do you mind sharing how to fix almost square angles in JOSM? I remember seeing such warning a year or two ago but for some reason I don't see it anymore and can't find it in the Validator settings. Did they remove it from the latest version of JOSM or you need to add this rule manually? If there is an easy way to do it then we should do it I guess. On Sun, Feb 3, 2019 at 7:51 PM Danny McDonald wrote: > I largely agree with Yaro, but will say > 1) It is possible to square almost square angles with JOSM - it has an > informational warning in validation, and automatically squares the angle by > slightly moving the offending node. This fix doesn't ruin the geometry of > the building, as pressing Q so often does. Unfortunately, it also leads to > other angles in the building not being square. > 3) I'm fine with importing smaller buildings as well (they don't seem to > be in the source data in Toronto, they are for some of the other data > sets). I believe they were excluded because of their relatively low > importance/permanence. > > I would also like to know how the Toronto building footprints were > produced. Does anyone know? > DannyMcD > > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca > -- Best Regards, Yaro Shkvorets ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Some feedback on import quality in Toronto
Having reviewed the changeset, here are my 2 cents. OsmCha link for reference: https://osmcha.mapbox.com/changesets/66881357/ 1) IMO squaring is not needed in most of those cases. - You can see difference between square and non-square ONLY at high zoom level. And even then, it's not visible to the naked eye. We are talking about inches here. - Sometimes squaring is plain wrong to be applied here. Even though you paid very close attention you managed to square a couple of non-square buildings. Like this facade is not supposed to be square for example: https://i.imgur.com/H10360K.png I might be OK with squaring almost-square angles if there is a simple plugin for that. The way you propose to do it, by going building-by-building and pressing Q is completely unsustainable and sometimes makes things bad. - Another thing, this particular neighbourhood is pretty dense and mature and therefore has mostly square buildings. I can only imagine how bad it would become if you ask people to square things in newer developments where buildings often come in irregular shapes. - Like mentioned above, many successful import didn't require squaring. In this Texas one, 100% of buildings are not perfectly square: https://www.openstreetmap.org/#map=19/32.97102/-96.78231 2) Simplification is good to have, sure. Obviously standard Shift-Y in JOSM is a no-starter. If we can find a good way to simplify ways without losing original geometry and causing overlapping issues we should do it. But even then, reducing 500MB province extract to 499MB should not be a hill to die on. 3) Manually mapping all the sheds and garages is completely unsustainable. Having seen over the last couple of years how much real interest there is in doing actual work importing buildings in Canada (almost zero) adding this requirement will undoubtedly kill the project. Sure you will meticulously map your own neighbourhood, but who will map thousands of other places with the same attention to details? Also, you did rather poor job at classifying buildings you add, tagging them all with building=yes. Properly classifying secondary buildings like sheds and garages in a project like this is pretty important IMO. I agree with John, we should leave sheds to local mappers to trace manually. To sum up, yes we can do better. But this is the perfect example when "better" is the enemy of "good". On Sun, Feb 3, 2019 at 12:34 PM Nate Wessel wrote: > Hi all, > > I had a chance this morning to work on cleaning up some of the > already-imported data in Toronto. I wanted to be a little methodical about > this, so I picked a single typical block near where I live. All the > building data on this block came from the import and I did everything in > one changeset: https://www.openstreetmap.org/changeset/66881357 > > What I found was that: > > 1) Every single building needed squaring > > 2) Most buildings needed at least some simplification. > > 3) 42 buildings were missing. > > I knew going in that the first two would be an issue, but what really > surprised me was just how many sheds had not been imported. There are only > 53 houses on the block, but 42 sheds/garages/outbuildings, some of them > quite large, and none of which had been mapped. > > I haven't seen the quality of the outbuildings in the source data, and > maybe I would change my mind if I did, but I think if we're going to do > this import properly, we're going to have to bring in the other half of the > data. I had seen in the original import instructions that small buildings > were being excluded - was there a reason for this? > > I also want to say: given how long it took me to clean up and properly > remap this one block, I'll say again that the size of the import tasks is > way, way, way too large. There is absolutely no way that someone could have > carefully looked at and verified this data as it was going in. I just spent > a half hour fixing up probably about one-hundredth of a task square. > > We can do better than this! > -- > Nate Wessel > Jack of all trades, Master of Geography, PhD candidate in Urban Planning > NateWessel.com <http://natewessel.com> > > _______ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca > -- Best Regards, Yaro Shkvorets ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Building Import update
ise un spectre
>> de degrés assez large
>> - lignes droites entre 178 et 182 degrés
>> - angles droits entre 88 et 92 degrés, entre 268 et 272
>> - autres types de polygones : variation de +-2.2% vs angle moyen pour le
>> polygone (octogones, hexagones, etc)
>>
>> Dans les analyses de géométrie, un grand nombre de polygones classés
>> FB_oo ont des géométries où on retrouve des batiments presque orthogonaux
>> mais avec un ou des angles entre 86 et 94 degrés. Cela veut sans doute
>> représenter des angles droits mais l'écart est assez grand. Dois-t-on se
>> satisfaire de cela?
>>
>> En ce qui a trait aux normes de qualité, elle sont généralement
>> implicites et guidées par les outils disponiibles. Avec JOSM, on s'attend
>> généralement qu'un contributeur utilisera le greffon Building et saura
>> tracer des batiments rectangulaires et si nécessaire superposer plusieurs
>> formes rectangulaires légérement décalées et les joindre en un seul
>> polygone. Les contributeurs devraient normalement aussi maitriser les
>> notions de perspective lorsque l'image est prise avec un certain angle par
>> rapport à la verticale. Les outils d'intelligence artificielle aussi ?
>>
>> Selon toi, quelles règles devrait-on appliquer pour évaluer la géométrie
>> des bâtiments ?
>>
>> L'exemple de géométrie que tu as présenté, on le retrouve effectivement
>> beaucoup dans les imports pour l'Ontario. Ce bâtiment n'est pas dans mon
>> fichier par ce que le contributeur n'était pas répertorié dans le projet
>> http://tasks.osmcanada.ca/project/145. Je n'ai retenu que les
>> contributeurs qui y apparaissait.
>>
>> Pour des exemples similaires contenus dans le fichier d'analyse, regardes
>> près du 31 Hamilton street.
>> https://www.openstreetmap.org/#map=20/44.23749975223997/-76.49539748034509
>>
>>
>> Ce polygone contient 22 angles, des quasi lignes droites (symbole ir), et
>> des quasi 90 degrés (oo) et des angles irréguliers tles 98,8, 94,3
>> Est-ce un polygone irrégulier ou un effet de perspective? Comment le
>> représenter?
>> "59879471""22""FB_irreg"
>> "{o,o,o,o,ir,ir,ir,ir,oo,o,o,oo,oo,ir,oo,o,oo,rr,ir,ir,o,o}"
>>
>> "{90.6,90.7,89.3,89.2,95.4,94.8,178,83.2,86.1,90.9,89.2,94,93.6,94.3,93.1,89.9,93.8,171.2,98.8,94.3,90.9,89.9}"
>>
>> Angle 177,6 presque droit, noeud inutile - normalement un simple rectangle
>> "657790097""5""FB_irreg""{o,o,ir,o,o}"
>> "{90,91,177.6,91.4,90}"
>>
>>
>> Un peu d'humour la-dessus. Un robot trace un rectangle parfait. Un
>> premier contributeur le voit et dit cela ne semble pas normal et y ajoute
>> un peu de distorsion. Un deuxième décide d'y ajouter un point et d'étirer
>> le tout. Si on poursuit le dessin dans ce sens, cela finira par ressembler
>> à un clown!
>>
>>
>>
>> Pierre
>>
>>
>> Le dimanche 27 janvier 2019 09 h 51 min 10 s HNE, john whelan <
>> jwhelan0...@gmail.com> a écrit :
>>
>>
>> If you take a look at 942 Bridle Path Crescent for example whilst it
>> isn't exactly square the deviations from 90 degrees to me are relatively
>> minor. I assume that this is the sort of thing you are talking about?
>>
>>
>> https://www.openstreetmap.org/search?query=942%20Bridle%20Path%20Crescent%20kingston#map=19/44.25311/-76.59308
>>
>> Are we expecting too high a standard?
>>
>> Cheerio John
>>
>> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
--
Best Regards,
Yaro Shkvorets
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Building Import update
tilisera le greffon Building et saura
>> tracer des batiments rectangulaires et si nécessaire superposer plusieurs
>> formes rectangulaires légérement décalées et les joindre en un seul
>> polygone. Les contributeurs devraient normalement aussi maitriser les
>> notions de perspective lorsque l'image est prise avec un certain angle par
>> rapport à la verticale. Les outils d'intelligence artificielle aussi ?
>>
>> Selon toi, quelles règles devrait-on appliquer pour évaluer la géométrie
>> des bâtiments ?
>>
>> L'exemple de géométrie que tu as présenté, on le retrouve effectivement
>> beaucoup dans les imports pour l'Ontario. Ce bâtiment n'est pas dans mon
>> fichier par ce que le contributeur n'était pas répertorié dans le projet
>> http://tasks.osmcanada.ca/project/145. Je n'ai retenu que les
>> contributeurs qui y apparaissait.
>>
>> Pour des exemples similaires contenus dans le fichier d'analyse, regardes
>> près du 31 Hamilton street.
>> https://www.openstreetmap.org/#map=20/44.23749975223997/-76.49539748034509
>>
>>
>> Ce polygone contient 22 angles, des quasi lignes droites (symbole ir), et
>> des quasi 90 degrés (oo) et des angles irréguliers tles 98,8, 94,3
>> Est-ce un polygone irrégulier ou un effet de perspective? Comment le
>> représenter?
>> "59879471""22""FB_irreg"
>> "{o,o,o,o,ir,ir,ir,ir,oo,o,o,oo,oo,ir,oo,o,oo,rr,ir,ir,o,o}"
>>
>> "{90.6,90.7,89.3,89.2,95.4,94.8,178,83.2,86.1,90.9,89.2,94,93.6,94.3,93.1,89.9,93.8,171.2,98.8,94.3,90.9,89.9}"
>>
>> Angle 177,6 presque droit, noeud inutile - normalement un simple rectangle
>> "657790097""5""FB_irreg""{o,o,ir,o,o}"
>> "{90,91,177.6,91.4,90}"
>>
>>
>> Un peu d'humour la-dessus. Un robot trace un rectangle parfait. Un
>> premier contributeur le voit et dit cela ne semble pas normal et y ajoute
>> un peu de distorsion. Un deuxième décide d'y ajouter un point et d'étirer
>> le tout. Si on poursuit le dessin dans ce sens, cela finira par ressembler
>> à un clown!
>>
>>
>>
>> Pierre
>>
>>
>> Le dimanche 27 janvier 2019 09 h 51 min 10 s HNE, john whelan <
>> jwhelan0...@gmail.com> a écrit :
>>
>>
>> If you take a look at 942 Bridle Path Crescent for example whilst it
>> isn't exactly square the deviations from 90 degrees to me are relatively
>> minor. I assume that this is the sort of thing you are talking about?
>>
>>
>> https://www.openstreetmap.org/search?query=942%20Bridle%20Path%20Crescent%20kingston#map=19/44.25311/-76.59308
>>
>> Are we expecting too high a standard?
>>
>> Cheerio John
>>
>> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
--
Best Regards,
Yaro Shkvorets
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted
>>It looks like perhaps we might just have to find the largest part for the footprint (building=yes) and any intersecting smaller buildings (building:part=yes). Yes, that's what I usually do. I also sometimes delete non-important building parts that don't add anything valuable to the map but only complicate things. Not sure how to better explain that in the wiki, it's a personal judgement thing I guess. On Thu, Jan 24, 2019 at 11:49 AM Nate Wessel wrote: > Is it sufficient to tag fragments as building:part without indicating > which part or how many stories? If the data is properly structured, this > seems like something that could be handled in preprocessing by checking for > overlapping polygons. It looks like perhaps we might just have to find the > largest part for the footprint (building=yes) and any intersecting smaller > buildings (building:part=yes). > > We might also need to generate some building relations for more complex > features. > Nate Wessel > Jack of all trades, Master of Geography, PhD candidate in Urban Planning > NateWessel.com <http://natewessel.com> > > On 1/24/19 11:40 AM, Yaro Shkvorets wrote: > > OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part > It's not in the import wiki though since whoever wrote it didn't know > about it at the time. > Here's what I mean by mapping 3D features in our case. Say there is a > residential tower on a podium. In the StatsCan data usually you would find > both of these outlines - large podium outline and smaller tower outline > inside it. They would both be tagged with "building=yes" tag. Obviously we > can't upload that as-is. We can either just remove tower outline leaving > only 2D podium outline. Or, we can tag the tower outline with > "building:part=yes". Someone local can add other tags to it later on, such > as "building:levels", "building:material", "building:min_level", > "addr:housenumber" (if there are two towers on one podium with different > house numbers for example), etc. I find the latter approach to be the right > one. > > On Thu, Jan 24, 2019 at 11:15 AM Nate Wessel wrote: > >> Hi Yaro, >> >> I just had a chance to look at the documentation on the source data and I >> wasn't able to find anything about 3D features or parts of buildings being >> mapped separately. Are you guessing here, or is there documentation on >> this? If so can you point us to it? >> >> In any case, the big shapefiles from StatsCan don't provide enough >> information to reconstruct any 3D geometries, so I'd be inclined to remove >> these from the import unless they can be brought in from another source >> with better documentation / attribute tagging. (i.e. City of Toronto?) >> >> Thanks, >> Nate Wessel >> Jack of all trades, Master of Geography, PhD candidate in Urban Planning >> NateWessel.com <http://natewessel.com> >> >> On 1/18/19 2:48 PM, Yaro Shkvorets wrote: >> >> Jarek, >> There is no question we want this data. I went through much of it in >> Toronto and Kingston and I found it to be very good, consistent and >> precise. Time-wise it's somewhat current with 2016 ESRI imagery (sometimes >> ahead, sometimes slightly behind) and is well-aligned with it. It offers 3D >> features (when several buildings appear overlapped in the dataset) but you >> just need to be familiar with `building:part` tag to sort through it. I >> haven't looked at other provinces but in Ontario I really have no >> complaints about dataset quality whatsoever. Also I don't get Nate's >> "wildly unsimplified geometries" comment. IMO geometries are just perfectly >> detailed. >> >> >> On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski >> wrote: >> >>> Some more thoughts from me. >>> >>> Building outlines, particularly for single-family subdivisions as seen >>> in Canadian suburbs, are extremely labour-intensive to map manually. >>> >>> My parents' house is now on OSM - accurately. They live in a city with >>> about 10,000 buildings, and about 0.5 active mappers. This wouldn't >>> been completed manually in the next 5 years. >>> >>> An option to do this automatically with a computer algorithm detecting >>> objects from imagery could be suggested, but this has not been very >>> accurate in OSM in the past, even when there is decent imagery. The >>> only other feasible data source is government, where they have such >>> data more or less. >>> >>> The alternative
Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted
OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part It's not in the import wiki though since whoever wrote it didn't know about it at the time. Here's what I mean by mapping 3D features in our case. Say there is a residential tower on a podium. In the StatsCan data usually you would find both of these outlines - large podium outline and smaller tower outline inside it. They would both be tagged with "building=yes" tag. Obviously we can't upload that as-is. We can either just remove tower outline leaving only 2D podium outline. Or, we can tag the tower outline with "building:part=yes". Someone local can add other tags to it later on, such as "building:levels", "building:material", "building:min_level", "addr:housenumber" (if there are two towers on one podium with different house numbers for example), etc. I find the latter approach to be the right one. On Thu, Jan 24, 2019 at 11:15 AM Nate Wessel wrote: > Hi Yaro, > > I just had a chance to look at the documentation on the source data and I > wasn't able to find anything about 3D features or parts of buildings being > mapped separately. Are you guessing here, or is there documentation on > this? If so can you point us to it? > > In any case, the big shapefiles from StatsCan don't provide enough > information to reconstruct any 3D geometries, so I'd be inclined to remove > these from the import unless they can be brought in from another source > with better documentation / attribute tagging. (i.e. City of Toronto?) > > Thanks, > Nate Wessel > Jack of all trades, Master of Geography, PhD candidate in Urban Planning > NateWessel.com <http://natewessel.com> > > On 1/18/19 2:48 PM, Yaro Shkvorets wrote: > > Jarek, > There is no question we want this data. I went through much of it in > Toronto and Kingston and I found it to be very good, consistent and > precise. Time-wise it's somewhat current with 2016 ESRI imagery (sometimes > ahead, sometimes slightly behind) and is well-aligned with it. It offers 3D > features (when several buildings appear overlapped in the dataset) but you > just need to be familiar with `building:part` tag to sort through it. I > haven't looked at other provinces but in Ontario I really have no > complaints about dataset quality whatsoever. Also I don't get Nate's > "wildly unsimplified geometries" comment. IMO geometries are just perfectly > detailed. > > > On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski > wrote: > >> Some more thoughts from me. >> >> Building outlines, particularly for single-family subdivisions as seen >> in Canadian suburbs, are extremely labour-intensive to map manually. >> >> My parents' house is now on OSM - accurately. They live in a city with >> about 10,000 buildings, and about 0.5 active mappers. This wouldn't >> been completed manually in the next 5 years. >> >> An option to do this automatically with a computer algorithm detecting >> objects from imagery could be suggested, but this has not been very >> accurate in OSM in the past, even when there is decent imagery. The >> only other feasible data source is government, where they have such >> data more or less. >> >> The alternative is of course the opinion that we should not have >> building outlines until someone goes through and adds the buildings >> manually. In practice what I've seen done in Toronto is that bigger >> buildings are mapped on best-effort basis from survey and imagery, >> while areas of single-family houses are left blank. This isn't >> _wrong_, and maybe some prefer this. >> >> I would also like to note that building outlines will _never_ be >> completely verifiably up to date. I can't go into most people's >> backyards and verify that there isn't a new addition on their house. A >> building might be legally split into two different properties without >> it being evident from the street. Imagery is out of date the day after >> it's taken, and proper offset can be difficult to establish in big >> cities where GPS signal is erratic. Pragmatically, I can tell you from >> personal experience that building data in lovingly-mapped Berlin is >> also worse than 1 meter accuracy. So again: best effort. >> >> What do we get from having buildings? A sense of land use (arguably >> replaceable with larger landuse areas). A way to roughly estimate >> population density. A way to gauge built-up density. A data source for >> locating buildings in possible flood zones, or fire risk. Statistics: >> as open data, queryable by APIs that are alrea
Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel
t;> Hi John, >>>> >>>> As Steve has said, you seem to be the only one suggesting that >>>> thousands of import committees might need to be formed. Certainly I'm not >>>> suggesting that. >>>> >>>> My understanding of OSM import procedure (and wiki-style projects more >>>> generally) is that imports should operate in an essentially consensual way >>>> where possible. The goal is to build consent and bring people on board with >>>> a project or a change by addressing their concerns in a meaningful and >>>> respectful way. >>>> >>>> I think that I have made some substantive and troubling claims about >>>> the quality of the data being imported. I've pointed out that this project >>>> has not followed the import procedures that were produced by a community of >>>> mappers larger than just those in Canada. >>>> >>>> So to respond to your implication, I am in some sense the one reviewing >>>> the project, just as I would welcome you to find ways that my own >>>> contributions could be better. If you want my credentials for reviewing >>>> your work, here they are: >>>> >>>> 1) I am an active contributor to OSM in Toronto, where I live (and >>>> elsewhere) >>>> >>>> 2) I am currently helping to lead a building import in Hamilton County >>>> Ohio that has better addressed some of the issues I see this import >>>> struggling with. I can help you do the same. >>>> >>>> 3) I've been doing research in GIS for a long time now, though I don't >>>> need that to tell you that the issues I've described are hardly >>>> insurmountable technically or even all that difficult to fix. It would take >>>> maybe one day's hard work to get the technical side of this right. >>>> >>>> I think Canadian OSMers will agree that we can take a pause to get >>>> things right on such a massive import. If they don't - if I'm shouted down >>>> or better, if my critiques are adequately addressed, then I will leave you >>>> to finish the project in peace. I might even lend a hand if all goes well, >>>> as I sincerely hope it does :-) >>>> >>>> Best, >>>> Nate Wessel >>>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning >>>> NateWessel.com <http://natewessel.com> >>>> >>>> On 1/18/19 1:11 PM, john whelan wrote: >>>> >>>> I know of no other way to contact him but he made an interesting >>>> comment that the project is on hold in the wiki pending review. >>>> >>>> Would he care to comment on who is supposed to be reviewing the project? >>>> >>>> My understanding is that the import was raised in talk-ca before it >>>> commenced for comment and these were generally favourable. I took that as >>>> the local mappers to Canada had been consulted and they are the "local >>>> mappers" authority in this case. >>>> >>>> I understand he has concerns about local mappers making decisions but >>>> in Canada we have been importing similar data through CANVEC for some >>>> time. CANVEC data comes from a number of sources including municipal data. >>>> >>>> Is he suggesting that each of the 3,700 municipalities in Canada should >>>> form a group of local mappers who can make individual decisions on whether >>>> their municipal data should be imported and we should end up with 3,700 >>>> import plans? >>>> >>>> Thanks John >>>> >>>> >>>> >>>> ___ >>>> Talk-ca mailing >>>> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca >>>> >>>> ___ >>>> Talk-ca mailing list >>>> Talk-ca@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-ca >>>> >>> >>> -- >>> Sent from Postbox >>> <https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach> >>> ___ >>> 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 > -- Best Regards, Yaro Shkvorets ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted
John, >> Traditionally or the party line is if its been mapped already then to preserve the history you either leave it alone or manually correct it. Manually correcting it is very time consuming. Often the decision is made to leave the existing way in the map. JOSM offers very convenient way to do it called "Replace geometry". Select both ways, old and new, press Ctrl-Shift-G, merge any conflicting tags and you preserve the history, tags and have new improved outline in a couple of clicks. On Fri, Jan 18, 2019 at 2:30 PM john whelan wrote: > And that is a problem with imports. Traditionally or the party line is if > its been mapped already then to preserve the history you either leave it > alone or manually correct it. Manually correcting it is very time > consuming. Often the decision is made to leave the existing way in the map. > > I'm not going to say one method is correct over the other but the least > contentious is to add only things are are not there already. > > Cheerio John > > On Fri, 18 Jan 2019 at 14:17, Yaro Shkvorets wrote: > >> Nate, >> I'll change the project name to reflect that the import is on hold. As a >> local mapper, if you want to take a lead on the Toronto import that'd be >> great. >> I did review some of DannyMcD's edits last night >> (Mississauga-Brampton-Vaughan) and to be honest was rather disappointed >> with the quality. It appears Danny chose to import only new buildings (i.e. >> residential homes mostly), leaving most of the existing hand-traced >> non-residential building outlines in OSM untouched. That's unfortunate, the >> dataset offers some really good data and leaving half of it behind makes it >> more difficult to revisit in the future. >> In my edits (Markham-Scarborough-East York) I was aiming to replace as >> many existing geometries with outlines from the import as possible. I think >> that's what we should be trying to do going forward. >> Looking forward to your comments and discussion. >> >> >> >> On Fri, Jan 18, 2019 at 1:07 PM Nate Wessel wrote: >> >>> Hi all, >>> >>> I've just joined the talk-ca list, so please accept my apologies for not >>> addressing this list earlier. I'm happy to take this thread off the imports >>> list for now and onto talk-ca until things are ready to begin again. The >>> next person to reply can please feel free to remove that email if they >>> agree. >>> >>> I've just made a note on the draft import plan wiki page noting that the >>> import has been stopped: >>> >>> >>> https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan >>> >>> I would really appreciate it if the person with admin access to the >>> tasking manager projects could please take those offline for the moment, or >>> perhaps place them in a validation-only mode if that's possible. >>> >>> Like I said in my last email, which perhaps didn't make it to the >>> talk-ca list ( >>> https://lists.openstreetmap.org/pipermail/imports/2019-January/005886.html) >>> I'm now proposing that we leave the data that has already been imported and >>> enter a phase of thorough validation on that data. >>> >>> My plan, over the next several days, is to do a general survey of the >>> quality of the data that has been imported so far and make a list of >>> systematic issues I see that should be addressed before we can consider >>> moving forward again. I'll add those comments to the conversation in >>> talk-ca and on the wiki page (link above), as I feel is appropriate. As I >>> said before, I'm of the mind that this import did not get adequate review >>> or approval and did not follow all the import guidelines. I think therefore >>> we need to take stock, cross the t's, dot the i's, and move this thing back >>> toward where it needs to be. Step one is a thoroughly documented wiki page >>> outlining the proposal and responding to everything required in the import >>> guidelines. >>> https://wiki.openstreetmap.org/wiki/Import/Guidelines >>> >>> I know there are people excited about this import, and people who are >>> eager to get back to work bringing buildings in, but I think everyone will >>> be happier in the end if we take the time to do this right. We don't need >>> to stop forever - we just need to stop until we get things right. I >>> sincerely respect the good intentions of
Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted
ation is a > prerequisite. > > > > Thank you for this commitment. I wish others shared it. Unfortunately > > the reality I've been seeing in OSM is that edits which are 90+% good > > (like this import) are challenged, while edits which are 50+% bad > > (maps.me submissions, wheelmap/rosemary v0.4.4 going to completely > > wrong locations for _years_) go unchallenged or are laboriously > > manually fixed afterward. > > > > --Jarek > > > > ___ > > 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 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 > -- Best Regards, Yaro Shkvorets ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted
Nate, I'll change the project name to reflect that the import is on hold. As a local mapper, if you want to take a lead on the Toronto import that'd be great. I did review some of DannyMcD's edits last night (Mississauga-Brampton-Vaughan) and to be honest was rather disappointed with the quality. It appears Danny chose to import only new buildings (i.e. residential homes mostly), leaving most of the existing hand-traced non-residential building outlines in OSM untouched. That's unfortunate, the dataset offers some really good data and leaving half of it behind makes it more difficult to revisit in the future. In my edits (Markham-Scarborough-East York) I was aiming to replace as many existing geometries with outlines from the import as possible. I think that's what we should be trying to do going forward. Looking forward to your comments and discussion. On Fri, Jan 18, 2019 at 1:07 PM Nate Wessel wrote: > Hi all, > > I've just joined the talk-ca list, so please accept my apologies for not > addressing this list earlier. I'm happy to take this thread off the imports > list for now and onto talk-ca until things are ready to begin again. The > next person to reply can please feel free to remove that email if they > agree. > > I've just made a note on the draft import plan wiki page noting that the > import has been stopped: > > > https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan > > I would really appreciate it if the person with admin access to the > tasking manager projects could please take those offline for the moment, or > perhaps place them in a validation-only mode if that's possible. > > Like I said in my last email, which perhaps didn't make it to the talk-ca > list ( > https://lists.openstreetmap.org/pipermail/imports/2019-January/005886.html) > I'm now proposing that we leave the data that has already been imported and > enter a phase of thorough validation on that data. > > My plan, over the next several days, is to do a general survey of the > quality of the data that has been imported so far and make a list of > systematic issues I see that should be addressed before we can consider > moving forward again. I'll add those comments to the conversation in > talk-ca and on the wiki page (link above), as I feel is appropriate. As I > said before, I'm of the mind that this import did not get adequate review > or approval and did not follow all the import guidelines. I think therefore > we need to take stock, cross the t's, dot the i's, and move this thing back > toward where it needs to be. Step one is a thoroughly documented wiki page > outlining the proposal and responding to everything required in the import > guidelines. > https://wiki.openstreetmap.org/wiki/Import/Guidelines > > I know there are people excited about this import, and people who are > eager to get back to work bringing buildings in, but I think everyone will > be happier in the end if we take the time to do this right. We don't need > to stop forever - we just need to stop until we get things right. I > sincerely respect the good intentions of everyone involved in this and I > hope we can all work together to make OSM a map known for it's coverage AND > it's quality. > > Best, > Nate Wessel > Jack of all trades, Master of Geography, PhD candidate in Urban Planning > NateWessel.com <http://natewessel.com> > > On 1/17/19 9:05 PM, OSM Volunteer stevea wrote: > > The thread link is: > https://lists.openstreetmap.org/pipermail/imports/2019-January/005878.html > > SteveA > > -- Best Regards, Yaro Shkvorets ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Tagging paths that are snowploughed?
Fixed On Tue, Nov 20, 2018 at 11:38 AM john whelan wrote: > I note that > https://github.com/BikeOttawa/OSM-Bike-Ottawa-Tagging-Guide/blob/master/README.md > under ploughing this recommends paths that are ploughed are tagged > winter_service=no which is the opposite way round to map features in the > link. No mention is made of seasonal=no. > > I suggest it needs review perhaps? > > Thanks > > Cheerio John > > On Tue, 20 Nov 2018 at 10:57, James wrote: > >> I know it's been linked before: >> >> https://github.com/BikeOttawa/OSM-Bike-Ottawa-Tagging-Guide/blob/master/README.md >> >> On Tue., Nov. 20, 2018, 10:55 a.m. John Whelan > wrote: >> >>> Which means more tags on the map but at least you can see which are >>> definitely cleared. >>> >>> Interesting since its Ottawa I'll follow this convention. >>> >>> Thanks John >>> >>> James wrote on 2018-11-20 10:53 AM: >>> >>> pathes that ARE cleared are tagged seasonal=no as they are NOT >>> seasonal(closes during winter for example) >>> >>> On Tue., Nov. 20, 2018, 10:51 a.m. John Whelan >> wrote: >>> >>>> I'm not sure exactly what you mean. Paths that not cleared are tagged >>>> seasonal=no or tags that are cleared get the tag seasonal=no? >>>> >>>> The default on winter_service is yes so only the ones that are not >>>> cleared need to be tagged with winter_service=no >>>> >>>> Could you point me to a reference in map features that uses the >>>> seasonal tag? >>>> >>>> Thanks John >>>> >>>> Amos Hayes wrote on 2018-11-20 10:20 AM: >>>> >>>> >>>> FYI, the Ottawa cycling community is using "seasonal=no" on pathways to >>>> indicate winter maintenance. >>>> >>>> -- >>>> Amos >>>> >>>> >>>> On Mon, 19 Nov 2018 at 19:01, John Whelan >>>> wrote: >>>> >>>>> Yes but for the path I'm thinking of that crosses a park specifically >>>>> I'm interested in tagging it just for cycling not a more generic case. >>>>> >>>>> Do you have another suggestion than winter_service=yes|no I think the >>>>> default is yes so just tagging the ones that aren't cleared would be >>>>> sufficient. >>>>> >>>>> Thanks >>>>> >>>>> Cheerio John >>>>> >>>>> Pierre Béland wrote on 2018-11-19 6:41 PM: >>>>> >>>>> Il y a plusierus facettes à considérer ici, soit accès hivernal, état >>>>> du sentier et services accessibles. >>>>> >>>>> La clé winter_service=yes indiquerait simplement que le sentier est >>>>> disponible l'hiver et ne permettrait pas d'indiquer que le sentier est >>>>> nettoyé facilitant l'accès aux velos. >>>>> >>>>> Voici un usage différent mais qui nous éclaire sur les clés utiliisées >>>>> pour décrire un service hivernal. >>>>> >>>>> La Tuktoyaktuk Winter Road (chemin 50426104) est un autre type de >>>>> service hivernal (Service abandonné l'hiver dernier suite à l'ouverture >>>>> d'une nouvelle route). >>>>> >>>>> Dans ce deuxième cas, cette tant le service que la piste n'existent >>>>> que l'hiver. >>>>> Les clés OSM utilisées pour les décrire sont >>>>> ice_road=yes >>>>> surface=ice >>>>> >>>>> Pierre >>>>> >>>>> >>>>> Le lundi 19 novembre 2018 17 h 20 min 53 s HNE, john whelan >>>>> a écrit : >>>>> >>>>> >>>>> Sounds perfect. >>>>> >>>>> Thanks John >>>>> >>>>> On Mon, 19 Nov 2018, 5:07 pm Yaro Shkvorets >>>> wrote: >>>>> >>>>> winter_service=yes|no seems perfectly fine: >>>>> https://wiki.openstreetmap.org/wiki/Key%3Awinter_service >>>>> >>>>> >>>>> On Mon, Nov 19, 2018 at 4:54 PM john whelan >>>>> wrote: >>>>> >>>>> Locally some paths across parks etc are snow cleared some aren't. The >>>>> ones that are are useful for cycling in the winter. >>>>>
Re: [Talk-ca] Tagging paths that are snowploughed?
In Ottawa cycling community we moved on from seasonal to winter_service about a week ago following a discussion on slack channel. On Tue, Nov 20, 2018 at 10:58 AM James wrote: > I know it's been linked before: > > https://github.com/BikeOttawa/OSM-Bike-Ottawa-Tagging-Guide/blob/master/README.md > > On Tue., Nov. 20, 2018, 10:55 a.m. John Whelan wrote: > >> Which means more tags on the map but at least you can see which are >> definitely cleared. >> >> Interesting since its Ottawa I'll follow this convention. >> >> Thanks John >> >> James wrote on 2018-11-20 10:53 AM: >> >> pathes that ARE cleared are tagged seasonal=no as they are NOT >> seasonal(closes during winter for example) >> >> On Tue., Nov. 20, 2018, 10:51 a.m. John Whelan > wrote: >> >>> I'm not sure exactly what you mean. Paths that not cleared are tagged >>> seasonal=no or tags that are cleared get the tag seasonal=no? >>> >>> The default on winter_service is yes so only the ones that are not >>> cleared need to be tagged with winter_service=no >>> >>> Could you point me to a reference in map features that uses the seasonal >>> tag? >>> >>> Thanks John >>> >>> Amos Hayes wrote on 2018-11-20 10:20 AM: >>> >>> >>> FYI, the Ottawa cycling community is using "seasonal=no" on pathways to >>> indicate winter maintenance. >>> >>> -- >>> Amos >>> >>> >>> On Mon, 19 Nov 2018 at 19:01, John Whelan wrote: >>> >>>> Yes but for the path I'm thinking of that crosses a park specifically >>>> I'm interested in tagging it just for cycling not a more generic case. >>>> >>>> Do you have another suggestion than winter_service=yes|no I think the >>>> default is yes so just tagging the ones that aren't cleared would be >>>> sufficient. >>>> >>>> Thanks >>>> >>>> Cheerio John >>>> >>>> Pierre Béland wrote on 2018-11-19 6:41 PM: >>>> >>>> Il y a plusierus facettes à considérer ici, soit accès hivernal, état >>>> du sentier et services accessibles. >>>> >>>> La clé winter_service=yes indiquerait simplement que le sentier est >>>> disponible l'hiver et ne permettrait pas d'indiquer que le sentier est >>>> nettoyé facilitant l'accès aux velos. >>>> >>>> Voici un usage différent mais qui nous éclaire sur les clés utiliisées >>>> pour décrire un service hivernal. >>>> >>>> La Tuktoyaktuk Winter Road (chemin 50426104) est un autre type de >>>> service hivernal (Service abandonné l'hiver dernier suite à l'ouverture >>>> d'une nouvelle route). >>>> >>>> Dans ce deuxième cas, cette tant le service que la piste n'existent que >>>> l'hiver. >>>> Les clés OSM utilisées pour les décrire sont >>>> ice_road=yes >>>> surface=ice >>>> >>>> Pierre >>>> >>>> >>>> Le lundi 19 novembre 2018 17 h 20 min 53 s HNE, john whelan >>>> a écrit : >>>> >>>> >>>> Sounds perfect. >>>> >>>> Thanks John >>>> >>>> On Mon, 19 Nov 2018, 5:07 pm Yaro Shkvorets >>> >>>> winter_service=yes|no seems perfectly fine: >>>> https://wiki.openstreetmap.org/wiki/Key%3Awinter_service >>>> >>>> >>>> On Mon, Nov 19, 2018 at 4:54 PM john whelan >>>> wrote: >>>> >>>> Locally some paths across parks etc are snow cleared some aren't. The >>>> ones that are are useful for cycling in the winter. >>>> >>>> Any suggestions on tags? >>>> >>>> Thanks John >>>> ___ >>>> Talk-ca mailing list >>>> Talk-ca@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-ca >>>> >>>> >>>> >>>> -- >>>> Best Regards, >>>> Yaro Shkvorets >>>> ___ >>>> 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 >>>> >>>> >>>> -- >>>> Sent from Postbox >>>> <https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach> >>>> ___ >>>> Talk-ca mailing list >>>> Talk-ca@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-ca >>>> >>> >>> -- >>> Sent from Postbox >>> <https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach> >>> ___ >>> Talk-ca mailing list >>> Talk-ca@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-ca >>> >> >> -- >> Sent from Postbox >> <https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach> >> > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca > -- Best Regards, Yaro Shkvorets ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Tagging paths that are snowploughed?
winter_service=yes|no seems perfectly fine: https://wiki.openstreetmap.org/wiki/Key%3Awinter_service On Mon, Nov 19, 2018 at 4:54 PM john whelan wrote: > Locally some paths across parks etc are snow cleared some aren't. The > ones that are are useful for cycling in the winter. > > Any suggestions on tags? > > Thanks John > ___ > Talk-ca mailing list > Talk-ca@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-ca > -- Best Regards, Yaro Shkvorets ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Mapping Highway 7
Hi All, Our Ottawa chapter is having a little mapathon tonight - we'll be mapping things along Highway 7 AKA "The Lost Highway" (http://thelosthighway.ca). Feel free to join us at 6 at Vimy Brewing: https://www.meetup.com/openstreetmap-ottawa/events/254420322 We'll also talk about Waylens camera lending program and have some beers. Or just contribute from home any time if you are interested. Here's the project page: http://tasks.osmcanada.ca/project/135 -- Best Regards, Yaro Shkvorets ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
