Re: [Talk-ca] Open Data for Airdrie AB

[OSM Volunteer stevea]

John, that was an outstanding overview of and answer to today's quite workable process.  I can only dream that this be written up in whatever now guides this effort in OSM (BC2020 wiki, whatever).  Congratulations on developing what looks like it now does allow and will eventually better allow nationwide building data to properly and further enter OSM.  Good luck with your efforts, I genuinely mean that.Best regards,SteveA

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

[OSM Volunteer stevea]

Ah, good dialog ensues.  Municipality by municipality, in conjunction with BOTH 
the StatsCan and Bing data, the right things are getting noticed, the right 
things are getting human-realized at what the next steps are to do.  It gets 
better.

Yay.  Stitch it together.  One municipality at a time.  One province at a time. 
 Pretty soon, after a few revisions of data and back-and-forths between 
municipalities and province-wide data checking, you've got something.  There, 
you go.

SteveA

> On Mar 27, 2019, at 8:23 PM, keith hartley  wrote:
> 
> The patchwork of municipalities is at least useful, before we didn't have a 
> framework for adding this data, but at least we do now thanks to the umbrella 
> license @ Stats Canada. We're a big country with very few, but very skilled 
> OSM mappers (IE gecho111 mapped all of regina's building footprints! ).
> 
> I like the concept of the Bing data, but they may have to do another few 
> tries, or maybe retain their Neural network. - Is there anywhere where the 
> Bing data looks nice? I found burbs in Winnipeg not bad, but there's some 
> really weird elements when the source data is too simple (buildings in the 
> middle of fields) or too complex (urban cores) 
> 
> On Wed, Mar 27, 2019 at 6:29 AM John Whelan  wrote:
> The Stats Canada data comes from the municipalities.  Unfortunately there are 
> over 3,000 in Canada so yes ideally each would be treated separately in 
> reality each municipality doesn't have a group of skilled OSM mappers who are 
> capable of setting up an import plan and doing the work although there is 
> nothing to stop them doing so.
> 
> Cheerio John


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Microsoft has released its building outlines for Canada

[OSM Volunteer stevea]

On Sat, Mar 2, 2019, 7:45 PM Tim Elrick,  wrote:
> Just my two cents here.

There are plenty of others doing so, too (me included, though I'll happily 
deduct a cent for being non-Canadian, so before you know it, you've got a whole 
dollar.  "Many hands make light work," though I agree that achieving consensus 
on a nationwide import can be (and often is) quite difficult.  I'm not trolling 
here, I wish to be encouraging and have decided to go crawl back under my rock 
for awhile to pursue other OSM endeavors (south of our border).

Cheers,
SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Microsoft has released its building outlines for Canada

[OSM Volunteer stevea]

John, these aren't my fish to fry; this endeavor belongs primarily to Canadian 
OSM volunteers with optimistic attitudes who have the courage to envision a 
finish line of mighty and pride-inspiring results into existence.  Being 
encouraging, my feeling is it IS possible to reach consensus across Canada.  It 
might be rough going at first, it might seem like the iterative process is 
taxing or even exhausting at times (especially early on in the project, as it 
is now), yet patience, the realization that when you bite off a nationwide data 
importation you'll have to chew (and chew and chew and chew...) before you can 
swallow a bit and recognize some important milestone of progress, but I am 100% 
certain Canada can and will get there.  It is already in the process of doing 
so, and while "sausage making can be a mess!" I'm sure there are many who look 
forward to delicious results.  Be heartened and courageous, be optimistic and 
visionary.  If or as you don't, others will (and already have).  Keep up the 
good work, everybody!

SteveA
(who usually doesn't like to be simply a cheerleader, though sometimes it helps)

> On Mar 2, 2019, at 4:33 PM, John Whelan  wrote:
> 
> >More discussion often yields consensus. 
> 
> Feel free to lead the discussion and gain consensus.
> 
> My feeling is it will not be possible to reach one across Canada.
> 
> Good Luck
> 
> Cheerio John

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Microsoft has released its building outlines for Canada

[OSM Volunteer stevea]

On Mar 2, 2019, at 3:47 PM, John Whelan  wrote:
> Two years ago a group of Toronto mappers submitted the City of Toronto Open 
> Data license to the LWG to see if it was acceptable.  I assume they meant to 
> import things such as building outlines.  I also assumed as I think others 
> did that this meant Toronto mappers were happy to import the City of 
> Toronto's data especially as it was discussed on talk-ca first.

Historical info is appreciated for context, however, the LWG found Canada-wide 
city-by-city submissions for ODbL-compliance burdensome, given LWG's limited 
bandwidth.  Assuming about events in the past is unhelpful, first because it is 
assuming (seldom helpful) and second, these events are in the past.  How 
Toronto imported (building) data can't really help us first understand and 
second improve from what we learn until we know what we learned.  That isn't 
presented here, but it could be.

> More recently Nate who currently lives in Toronto feels that this should be 
> discussed once more in Toronto to work out what is desired etc.

I agree with Nate.  Perhaps first in Toronto, perhaps wider in talk-ca.  "Once 
more" seems limiting, though it's possible it could suffice.

> Tim I think is organising Montreal open data import.

Please consider adding this (and links to user: wiki or Talk pages) to the 
active Import wiki.  Generate communication using our media!

> I note that Nate and Tim have different ideas about what should be imported.  
> One is happy with bay windows and I think the other feels they should be 
> removed.

More discussion often yields consensus, especially as it "goes wide" (or as 
wide as is practical).

> We also have Pierre who is unhappy because the imported building outlines 
> available have too many corners that are not right angles.

More discussion often yields consensus.

> The local Ottawa mappers are content with their Open Data import and find the 
> data quality acceptable even though Pierre has expressed reservations about 
> it.

More discussion often yields consensus.  Wide area (large cities, 
province-wide, nationwide) imports are not easy to achieve consensus but can 
often reach something approaching one as data are entered, not liked, improved, 
liked better, et cetera.  These are often an interactive, iterative process.

> Someone in Manitoba? mentioned there were no building outlines released for 
> Manitoba?  I apologise if I have the province name wrong.

It is spelled correctly.  I am not Canadian and I know that; it isn't hard to 
spell-check Manitoba.

> So we have a mixture of expectations which is only to be expected in a large 
> group.

More discussion often yields consensus.  It might be part "mixture of 
expectations" but I'm sure that everyone will agree that "high quality data 
entering OSM" is expected.  What can be difficult is "what do we mean by high 
quality?" (in addition to establishing and communicating clear goals for the 
importation of the data).

> Microsoft's Open Data provides another source of Open Data which might meet 
> Pierre's data quality expectations.  They may meet Nate's.  All provinces and 
> Territories now have Open Data building outlines available.

OK, thanks for the clarification that a "union" of these datasets (Stats 
Canada-produced building data + Microsoft-produced building data) provide an 
"all provinces and Territories dataset."  That truly is helpful as it makes it 
clear that "if Set A doesn't have your province's or Territory's building data, 
Set B will."

> Northwest Territories, Nunavut, and Yukon have populations of around 35,000 
> people.  Realistically I don't think they have a group of local OSM mappers.

Please don't "write them off" so easily.  Not only does it seem "not nice," it 
may not be true.  A better approach may be to actively develop community there, 
difficult as that might seem.  I believe there is usually Internet available 
there in the villages (sometimes via clever and state-of-the-art methodologies) 
and it may be as simple as "shaking the trees" of the right people, then 
"they'll take it from there."

> Essentially the problem now we no longer have a Canada wide consensus on what 
> is acceptable

More discussion often yields consensus.

> ...appears to be how do you identify local mappers across Canada and how far 
> away can a "local" mapper be to be considered local since it is the local 
> mappers who make the decision about what is acceptable and I think it is they 
> who have to drive the import process.

There are no such "hard and fast" rules as this.  I think you're on the right 
track that "hinterland" (I do not mean that disparagingly, rather more like 
"far away from others") OSM volunteers "drive the import process," so I again 
encourage you and others to "better develop" this community and let them, teach 
them, encourage them to "do what they will."

> I'm sure if a local group would like to contact me we can find resources to 
> assist them 

Re: [Talk-ca] Microsoft has released its building outlines for Canada

[OSM Volunteer stevea]

No, I am not planning to import these.  However, your notification that the 
data are available seems to be encouraging the data to BE imported into OSM.  
Of course, there is a "more correct" way to do that.

Perhaps I might encourage you to sharpen up your intention for notifying 
talk-ca of the availability of the data.  Are they an additional source to 
ENTER into OSM?  (Thus importing them).  Or, perhaps you mean them to be a set 
of "comparison data" which might be used to verify or compare against the 
"other" data.  Although, then, should there be a discrepancy, the question 
becomes "which are (more) correct?"  I didn't see any of these issues addressed 
by your notification, which feel likes it begs these questions.  Thank you in 
advance for any follow-up that better clarifies.

Late notice just before I clicked Send:  thanks to James for letting us know 
here that the data are ODbL and therefore OSM-compatible.  (One down, perhaps a 
bit more to go).

SteveA

> On Mar 2, 2019, at 2:40 PM, john whelan  wrote:
> 
> Why are you planning to import it?
> 
> Cheerio John
> 
> On Sat, Mar 2, 2019, 5:26 PM OSM Volunteer stevea, 
>  wrote:
> A responsible complement to this would be a link to license information, a 
> wiki page about these data, and perhaps an Import Plan should those data 
> actually be asserted to be worthy of being responsibly imported into OSM.
> 
> SteveA
> California
> 
> > On Mar 2, 2019, at 2:17 PM, john whelan  wrote:
> > 
> > https://github.com/Microsoft/CanadianBuildingFootprints
> > 
> > So now there are two Open Data sources for building outlines in Canada.
> > 
> > Cheerio John
> > ___
> > 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

Re: [Talk-ca] Microsoft has released its building outlines for Canada

[OSM Volunteer stevea]

A responsible complement to this would be a link to license information, a wiki 
page about these data, and perhaps an Import Plan should those data actually be 
asserted to be worthy of being responsibly imported into OSM.

SteveA
California

> On Mar 2, 2019, at 2:17 PM, john whelan  wrote:
> 
> https://github.com/Microsoft/CanadianBuildingFootprints
> 
> So now there are two Open Data sources for building outlines in Canada.
> 
> Cheerio John
> ___
> 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

Re: [Talk-ca] Some feedback on import quality in Toronto

[OSM Volunteer stevea]

It is an honor to participate in this good growth.  May good 
(province-at-a-time building) data enter OSM at the hands of skilled OSM 
editors who have good instructions on "how" (the Import Plan can go that 
distance, please finish it) as their skills of good editing OSM data push the 
import ahead.  Speaking for myself, I like what I see here:  a community 
speaking amongst itself/ourselves.

Should "tall enough to ride the ride" volunteers "step right up" I think the 
current red flags can go to yellow, then green.  Nate, Yaro, Pierre, Blake, 
Nate, John, Danny, so many others here unnamed have shown leadership.  Many 
Canadians seem on the road to "how" and "talk amongst yourselves."  Good is not 
the enemy.  Good are good enough as they are included with "how."  Thumbs up 
from here ahead.  I keep trying to be outta here.

Et, voilá.

SteveA
> 


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[OSM Volunteer stevea]

I dislike sounding simply "like a cheerleader," here however, I am deeply 
encouraged by what I see as substantial progress.  This sort of discussion 
bodes very well for the future of the import.  Keep up the good work!

SteveA

On Feb 3, 2019, at 3:26 PM, john whelan  wrote:
> I'm hearing we keep the single import project as such.

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[OSM Volunteer stevea]

Pierre writes that he is "waiting for John's demonstration that the import data 
for Ottawa represents the outline of the buildings and is quality data."

In reality, anybody (not necessarily John) can offer this sort of 
characterization.

En réalité, n'importe qui (pas nécessairement John) peut offrir ce type de 
caractérisation.

SteveA

On Feb 3, 2019, at 11:42 AM, Pierre Béland via Talk-ca 
 wrote:
> De tes exemples sortis du chapeau ne font pas avancer la discussion. 
> 
> J'attends la démonstration de John que les données d'import pour Ottawa 
> représentent bien le contour des bâtiments et sont des données de qualité.
>  
> Pierre 


___
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

[OSM Volunteer stevea]

Mmm, careful with your language, John.  The data "have a license which is 
compatible with OSM's ODbL" (is an accurate way to say it).  I believe that 
took about eight years and was a difficult slog, a lot of hard work by many, 
lessons learned from Ottawa, a determination by OSM's LWG, but it is done.  (I 
am grateful for that, it is an important milestone).

A different issue is whether the data and their concomitant quality "are 
acceptable" to the OSM community.  The license being ODbL compatible is not 
that; these are different issues.  We now discuss data quality (and what to do 
to improve them, if anything) here in talk-ca and in the mildly-being-updated 
Import Plan, with experiences of what Yaro, Danny and Nate have done in Toronto.

It is not the case, as John says, that "the data (are) licensed to be 
acceptable to (OSM)."  The concept of "acceptability" is not related to the 
data being licensed compatible with ODbL.

What often/usually happens is an Import Plan gets wide vetting and acceptance 
by the OSM community before data become imported, including 
suitability/acceptability of the quality of the data.  What happened here is 
the Import Plan was attempted to be widely vetted, but this seems to have been 
largely ignored or little-paid-attention-to.  While the Plan's initial 
shortcomings were pointed out, yet not remedied, the Import began, then the 
community began to react (with some complaint and some "what Yaro does seems 
OK").  Yaro (and Nate, I believe) then updated the Import Plan with Yaro's 
specific technical steps.

Still, complaints and/or disagreements about simplification, squaring and 
potentially other issues continue.  (As two asides, I'll say that MANY 
buildings are not necessarily "square" — like buildings with bay windows — and 
that truly square/rectangular buildings should express this with a tagged 
way/closed polygon made up of exactly four nodes).

As these discussions continue, eventually what will emerge is "how do we 
(algorithmically, manually...) change the data, whether pre-import or 
during-import, so that they achieve wide acceptance as to their quality by the 
community."  We're getting closer, it seems to me, but I don't think we're 
there yet.

Nobody seems to be arguing there is or isn't a "desire to bring in the 
buildings by many" or to "use them for many purposes."  That point seems 
"decided."  The questions remain:  "how, with the existing data?"  Once those 
are determined (and documented in the Import Plan), over time, the data will 
(or will not) be imported.  I wish to offer encouragement to this process, it 
does appear to continue here and can likely bear fruit in the near future.  
Keep going!  Consensus is ahead!

SteveA

On Feb 3, 2019, at 10:55 AM, john whelan  wrote:
> So I suggest that you name yourself as the coordinator on the wiki page for 
> Toronto that allows the local mappers in Toronto to import at the rate and to 
> the standard you suggest.
> 
> For the rest of the country the data is licensed to be acceptable to 
> OpenStreetMap thus anyone can set up their own import plan and import it even 
> if this import is abandoned.  I'd like to see this voiced as the general 
> desire though on talk-ca before it happens as it was a talk-ca decision to 
> proceed.
> 
> My reading of the posts on talk-ca is that there is a desire to bring in the 
> buildings by many.  There is also a desire by many to use them for many 
> purposes.
> 
> Cheerio John
> 
> On Sun, Feb 3, 2019, 1:42 PM Nate Wessel  John, 
> You seem to be mostly addressing topics which have been brought up elsewhere. 
> My email was meant to address specific data quality issues in Toronto, so I'm 
> not sure how to respond to all of this. 
> To your broader question though, my position is that we *do* have the 
> volunteers and skills necessary to make this a good import. Supposing that we 
> didn't though, then I would have to say that the import should wait until we 
> have the right people working on it. A bad import is worse than no import.
> 
> Cheers,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[OSM Volunteer stevea]

On Feb 1, 2019, at 1:13 PM, john whelan  wrote:
> So how would you tackle it?
> 
> Adding buildings with JOSM and the buildings_tool is possible, I think Julia 
> tried to whip up some interest with the 2020 project.  Unfortunately 
> mapathons using iD and new mappers for some reason don't work too well for 
> buildings. They do work fine for adding tags though.
> 
> I seem to recall March 2nd is some sort of student GIS day and we can expect 
> something to happen in GEO/GIS week whenever it is.  I'd prefer adding tags 
> to existing outlines rather than having to clean up buildings added with iD.

Adding tags to buildings by students at a "student GIS day" (whether with iD or 
not) is "one thing," and honestly shouldn't even be in this same thread 
("Building Import update." ) Conflating the two is either mistaken, 
disingenuous or both.

> If we go back in time to the Ottawa import and the licensing issues I seem to 
> recall a Toronto mapper submitting the Toronto Open Data License to the legal 
> working group which implies at least one Toronto OSM mapper was after the 
> Toronto Open Data.

While it can be valuable to "look in the rear view mirror" (to learn from past 
mistakes), I fail to see how this comment matters.  Doing my best to stay on 
point, my educated guess is there are MANY users who want to see "the five 
provincial building datasets" (what we TRULY attempt to discuss here) enter 
OSM.  However, there appear to be questions about the data quality, with some 
saying "skilled editors are able to do a decent job with these data, but not 
without substantial post-data publication (now) improvements before the data 
are uploaded."  (This would be downloading a "square" on the Task Manager and 
rather heavily improving the data, building by building.  Yaro and Danny, 
please chime in and agree or disagree.  Should that be true, only 
intermediate-to-advanced — i.e. rather skilled OSM editors with practice and 
experience should "do" the importation of these data).  Others say "these data 
need wholesale algorithmic changes before they are good enough to be uploaded." 
 (As I've said, maybe "squaring" or "simplification," yet I and this mail-list 
still do not know exactly where consensus lies there).  There are likely other 
opinions along and even outside of that spectrum, I simply do not know that.  
But GETTING to know the answers to those questions really must be "next."  We 
appear to be hashing that out here and now.  Much else (all else?) is, largely 
speaking, noise, distraction and what Nate said, "red herring."

> My feeling at the moment is there is a suggestion that "cleaning" the data up 
> then some sort of team approach in a particular area would be acceptable but 
> how you put it together I'm not sure.

No, you do not appear to be sure, John.  Yet, somehow, Canada will get there.  
Either in talk-ca, the Import wiki, the wiki's Discussion tab ("Talk page") the 
consensus of what to do with the data will EVENTUALLY emerge (fix 'em, scrap 
'em, leave 'em alone and import 'em with great care...), then they will 
(slowly, there are a LOT!) begin to be imported into OSM.  Or not.

It is a maxim of good project management which is often unstated, yet now is 
the time to say it:  "Lead, follow or get out of the way."

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[OSM Volunteer stevea]

On Jan 31, 2019, at 5:47 PM, john whelan  wrote:
> 
> I note that both Google and Bing have most buildings these days

That's a strong assertion, any cite you might make?  Or are you simply 
guessing?  Also, so what?  And, "most?"

> and it has almost become a map user expectation.

Do you have any sources to cite for this?  Bing users?  Google Maps users?  OSM 
users?  Who, exactly is "expecting" this and how do you know this?  What 
matters here and now is the OSM community's acceptance of the quality of these 
data.  Is Canada able to MAKE such a determination?  I think so.

> There is a case that says to keep up with the competitors we really ought to 
> have buildings.

John, I believe you are the first to ever assert "we ought to have buildings" 
I've ever seen in OSM.  What "case" are you talking about?

> I think someone else has commented that parts of the Microsoft building 
> outline from scanned images in the US is problematic.

Well, then say so.  Say who.  Say when.  Say where.  Say what you mean by 
"problematic."  Let us (the OSM community) reflect on these comments.  Let us 
(the OSM community) make our own determinations whether this is or isn't 
"problematic."  Those issues are a completely separate issue from OSM, although 
there might be overlap, I simply don't know, as you haven't given us any data, 
simply your opinion.  I'd like to know, but I can't, given what you have 
offered.

> So given the results in Ottawa are comparable to Ontario and in my opinion 
> Ottawa is acceptable then I think the rest is also acceptable.

OK:  one vote in the fog of consensus.  I have very little data to go on, and 
I'm not completely certain why, but it is an assertion of an OSM volunteer 
saying "then I think..." something.

> Certainly Kingston where not all building angles were right angles weren't 
> noticeable to me by eye or perhaps my eyesight is just getting worse with age.

Canada (and OSM) either agrees its building data for the five provincial 
datasets are OK, or Canada (and OSM) don't.  As I've heard many here (I don't 
need to cite them, these cite themselves) say "I don't" or "we don't" (think 
the datasets are OK), the next things to say are "Well, they seem fixable with 
some algorithmic/programatic massaging, so, how do we fix them?"  Or, "OK, 
here's how we're going to fix them."  (Simplify the nodes, make them have 90º 
angles, whatever).  This doesn't seem like it's an impossible finish line to 
cross, though I do see at least one person running in detours going nowhere.

In short:  "what's wrong with these data, how might they get fixed?"  (Then 
they might get imported).  It doesn't seem to me to be a whole lot more 
complicated a discussion than that.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] OSM Canada building import

[OSM Volunteer stevea]

On Jan 26, 2019, at 12:37 PM, john whelan  wrote:
A history of building data released by Stats Can and how these were entered 
into OSM via an Ottawa pilot project, with some success and some lessons 
learned.  Good for OSM!

> The other complicating factor here is a lot of people are very interested in 
> using the data one way or another.

No doubt it's a factor, though I fail to see how it complicates — unless there 
is a rush to enter the data before they are fully vetted.  (That won't work).  
Should the data be used "from OSM," they must enter OSM with our community 
consensus, standards and practices.  That is beginning to be achieved:  
https://wiki.osm.org/wiki/Canada_Building_Import improves, related Task Manager 
tasks appear to get closer to being "opened again" as Nate's four steps of what 
might be accomplished reach wider consensus and are implemented (or not, or 
something else happens...) and discussion continues right here on talk-ca.  
Yes, "broad philosophical discussions" are included:  they are helpful, likely 
to some more than others.

> The take away, have fun if you can.

"Have fun" is "OSM tenet #2" (#1 is "Don't copy from other maps.")  As we're 
not violating #1 here, I enthusiastically agree with John's "take away:"  
please do have fun (yes, you can, yes, many do).  Yet, as we are a data 
project, we must also be a community who cares deeply about data quality, that 
our data "pass muster" as they enter (especially when via a nationwide Import). 
 I speak for myself only, but others in this project concur.  Canada gets 
there, I'm delighted to see.  Yes, it's taking a bit of thrashing to do so, but 
that's all for the greater good, as the ends justify the (polite, patient, 
correct) means by which we do.  We're many steps into this 10,000-kilometer 
journey, let's keep going, as the goal is worthy.

Now, who is rolling up their sleeves and addressing Nate's four steps?  Those 
discussions can take place here, though I think the Discussion tab ("Talk 
page") of the link above seems more appropriate.  (And, I'd prefer to "get out 
of the way" here, if anybody were to go so far as to feel "get lost, already, 
SteveA," I wouldn't be offended, though I remain watching this Import for that 
greater good).

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[OSM Volunteer stevea]

On Jan 26, 2019, at 8:42 AM, Nate Wessel  wrote:
Four absolutely OUTSTANDING aspects of this project which can (seemingly must) 
be addressed before the Task Manager releases these (or improved/simplified) 
data.

A salute to you, Nate, for these thoughtful words and their potential to very 
positively drive forward this import.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] OSM Canada building import

[OSM Volunteer stevea]

I'm changing the Subject to delete "Stats Can" as this is an import into OSM, 
not a Stats Can import.  True, they published the data, so "thanks for the 
data," but Stats Can isn't a part of this conversation, they merely published 
the data.  I say it like this to emphasize that OSM is quite aware of a good 
analogy:  the US Census Bureau, who published the TIGER data which was imported 
massive road and rail data into the USA (roughly, many agree), had nothing to 
do with the import, nothing to say about it and don't to this day:  they merely 
published the data into the public domain (as the federal US government do all 
their/our data, except when it is "classified") and OSM chose to import the 
data.  OSM wishes in retrospect we had done a better job of it, as we improve 
it to this day (and will for years/decades, likely) and OSM has learned from 
this.  Please, Canada, see this import as the opportunity it truly is:  do NOT 
be in a rush to import lower-quality, not fully community-vetted data, or you 
will be quite sorry at the mess you'll have to clean up later.  Doing that 
would be much more work than the dialog we are having now to prevent this.  It 
is worth it to have these dialogs and achieve the consensus that the data are 
as we wish them to be.  Are they yet?  It sounds like they are not (Nate's four 
points).

On Jan 26, 2019, at 7:49 AM, John Whelan  wrote:
> Currently we seem to be at the point where some on the mailing list feel 
> there wasn't enough discussion on talk-ca before the import.

MANY agree there wasn't enough discussion.  But that was before.  Rather than 
looking back (though there is nothing wrong from learning from missteps), we 
are in a "now" where that is changing.  So, we continue to discuss.  That's 
fine.  That's actually excellent.

> Quebec I think we should put on one side until the Quebec mappers feel more 
> comfortable.

OK, so we await Québécois suggestions / improvements to the process to their 
satisfaction, their input that they are (widely amongst themselves) with 
"comfortable to where it has finally evolved" (but I haven't heard that yet), 
or both.  Usually in that order, but certainly not "well, enough time has 
elapsed, yet we haven't heard much, so let's proceed anyway."  That doesn't 
work, that won't work.

> Nate I feel has been involved in a smaller import before and in that case 
> there was benefit by simplifying the outlines.  In this case verifying 
> nothing gets screwed up adds to the cost.

Nate has done a lot of things in OSM, including a very positively-recognized 
(award-winning?) Ohio bicycle map that included very wide coordination with 
other OSM volunteers, the academic world and local community.  (It is 
absolutely delicious; take a look at it).  Another example of what a single 
person in OSM who reaches out to the community with a vision and a plan can 
achieve — given planning, the time it really takes and wide consensus.

> Buildings not absolutely square, yes but different GIS systems use different 
> accuracy so if the incoming data has a few more decimal places then rounding 
> will occur which can lead to minor inaccuracies. I feel the simplest is just 
> to leave them.

Others seem to feel that these inaccuracies are too rough (data quality too 
poor) to enter OSM.  And "different GIS systems" only matter in a historical 
context (as in, for example "these data came from QGIS" or "these data were run 
through GDAL and turned into a shapefile" or many other workflows).  The only 
"GIS system" that matters is OSM.  Each individual contributor who enters data 
into OSM is responsible for entering high-quality data, or risks having those 
data redacted by the community (though that means the process was broken to 
begin with) — that's simply how OSM works.  Again, this is an OSM project:  a 
data import, which follows rules and community standards judging its quality as 
much as the individual entering the data itself.  If the data should and can be 
improved before they enter (especially with a "data-wide" application of some 
algorithm), like "this squares buildings and we want to do this" or "this turns 
a true rectangle into four nodes instead of eleven and we should do this to 
reduce the amount of data and simplify future edits" then we should.

This isn't being "anti-import."  It IS about "data which ARE imported must be 
high-quality," so let's discuss what we mean by that in the case of these data. 
 That's what we're doing now.

> Selecting everything and squaring is really a mechanical edit and you can get 
> some odd results which again would need to be carefully compared and adds to 
> the workload.

Sometimes "mechanical edits" are OK, sometimes they are not.  It seems John is 
saying "these are not."  Whether this adds to the workload or not is moot, the 
workload will be what it takes for high-quality data to enter, and "what that 
means" is achieved by the discussions we have had, have now and what 

[Talk-ca] Building Import update

[OSM Volunteer stevea]

Thanks to some good old-fashioned OSM collaboration, both the 
https://wiki.osm.org/wiki/Canada_Building_Import and 
https://wiki.osm.org/wiki/WikiProject_Canada/Building_Canada_2020#NEWS.2C_January_2019
 have been updated.  (The latter points to the former).

In short, it says there are now step-by-steps to begin an import for a 
particular province, and that as the steps get fine-tuned (they look good, but 
might get minor improvements), building a community of at least one or two 
mappers in each of the provinces with data available, the Tasking Manager can 
and will lift the "On Hold" or "Stopped" status.

Nice going, Canada!

See you later,

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Place Tagging

[OSM Volunteer stevea]

On Jan 24, 2019, at 11:03 AM, Danny McDonald  wrote:
> A place does not need to incorporated to be a place=town, city, village.  
> That is not how it works anywhere in OSM - there are many unincorporated 
> places with these tags, worldwide.  The tagging in Ottawa is a good guide, 
> with e.g. Richmond a village, but e.g. Centretown and Stittsville 
> place=suburbs, based on distinctness.

I don't believe I said it did, I do believe I said that a city is always 
incorporated, a town or village, "maybe."

And, as I also said, "local tagging as a consensus or guide" is something to 
consider.  This isn't alway black-and-white, nor easy.  As we "do our best," 
things eventually emerge as correct, though it usually takes some time and 
effort to get there.  (Consensus does).

SteveA

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Place Tagging

[OSM Volunteer stevea]

On Jan 24, 2019, at 7:50 AM, Danny McDonald  wrote:
> My understanding of place tagging is that place=city, place=town, and 
> place=village are for distinct urban settlements, whether or not they are 
> separate municipalities.

Correct, in that these tags can be placed upon a node, way or relation (if a 
boundary relation, a node with role admin_centre is correct).  Sometimes a way 
(often a closed polygon) is not precisely known, or is, but license 
restrictions prevent those data from entering OSM.  In that case, a simple node 
tagged place=* with appropriate value is used, as documented at 
https://wiki.osm.org/wiki/Key:place .  Though, be aware and careful regarding 
"incorporated" areas; see below.

> Place=suburb is for large parts of urban settlements (such as North York in 
> Toronto, or Kanata in Ottawa).

While I am not a political scientist, I did participate in the development of 
consensus in the United_States in 
https://wiki.osm.org/wiki/United_States_admin_level , a complex task indeed 
(and I'll say we only have it "largely correct," certainly not "exactly 
correct").  While Canada has similarities, it certainly is unique in 
admin_level, appropriately documented at 
https://wiki.osm.org/wiki/Canada_admin_level .  Yet an important concept found 
in many countries, Canada included, is that of "incorporation" — whether an 
urban settlement is a "body corporate."  Cities always are, suburbs and towns, 
depending on differing context for each of these, may or may not be.

> Whether to classify a place as a place=city/town/village or place=suburb 
> depends on the facts on the ground (I.e. whether a place is part of a larger 
> urban settlement), and not primarily on municipal/administrative boundaries.

I can't speak for all of Canada, but I can speak to what OSM documents in our 
place=* wiki:  that urban and rural populated places are distinguished by two 
separate tables there, so it is useful to understand how OSM characterizes 
these as slightly different (with specific tags in each table).  This is 
regardless of how any particular country might use the same names.  For 
example, place=suburb has a very specific semantic as it is used in OSM, 
contrasted with how "real world" "suburb" might mean an incorporated (smaller) 
city near a (larger) city, OR it might mean a district/area/small region INSIDE 
of an incorporated city (how OSM means it).  We must be careful to tag in OSM 
with how OSM means things, mapping our "real world" semantics onto OSM 
semantics.

> Municipal boundaries might be somewhat relevant in determining if a place is 
> distinct (e.g. Vaughan is a city, not a suburb), but they are a relatively 
> minor factor.

I don't know what this means exactly.  Municipal boundaries ARE EXACTLY 
relevant in determining if a place is distinct:  they literally distinguish it. 
 In "real world speak" Vaughn might be called a suburb, but unless it meets 
OSM's place=suburb definition, it shouldn't be tagged that way in OSM.  This 
isn't minor, it is "either correct or incorrect."

> The main way that municipal names are mapped is through admin boundary 
> relations, not place nodes (although many municipalities have the same name 
> as their largest urban settlement, of course).

Yes, this is true, although for many smaller human settlements (and some larger 
ones), place nodes simply "will have to" suffice.

> The way to distinguish between a place=city, place=town, and place=village is 
> population size, with nearby places shading things a bit (so a smaller 
> population size qualifies for a place=town in Northern Ontario).  Very 
> roughly, a city has population >50k, a town has population 5k-50k, and a 
> village is <5k.

OSM's place wiki notes that a village is more like "200 to town size" so that 
5k edge is fuzzy.  The USA admin_level wiki documents some "rules of thumb" 
here, but, yes, these can be rough, and are sometimes "stretched" (or "shaded" 
as you say) a bit so that wide-zoom views of very rural areas (e.g. northern 
Ontario) show settlements a bit more clearly.

> There seems to be a persistent mis-understanding of this scheme, where 
> various editors (mainly @OntarioEditor and various other accounts controlled 
> by them) believe that place=city/town/village are for municipalities, whether 
> or not the municipality has one major urban settlement with the same name as 
> the municipality or not.  They are also tagging all unincorporated places in 
> a municipality as place=suburb, regardless of size or distinctness.  Finally, 
> they are using the official title of the municipality to determine if it is a 
> city/town/village, whether than using population size.  This can lead to very 
> misleading results, as Ontario municipalities called towns range in size from 
> 313 to 195k, and Ontario municipalities called cities range in size from 8k 
> to 2.7M.  Quebec “ville”s (which means town or city) range in size from 5 to 
> 1.6M.
> 
> To give an example, 

Re: [Talk-ca] Canada Building imports wiki page

[OSM Volunteer stevea]

On Jan 24, 2019, at 9:29 AM, john whelan  wrote:
> You seem to have made rather large changes without consultation including 
> changing the title of the project.  You have also added some value judgments. 
>  A number of people were involved in the original and it might have been nice 
> to consult with them before making such drastic changes.  The word consensus 
> springs to mind.
> 
> I make no comment on whether the changes are good or bad merely extensive 
> without apparent consultation. 

John, much consensus is achieved in wiki Discussion(s), simply click the 
Discussion tab, https://wiki.osm.org/wiki/Talk:Canada_Building_Import and 
notice that there are four threads/sections under Discussion there already.

If some "number of people" were involved in the original, they are perfectly 
welcome to join there.

I'm not saying "don't do this in talk-ca" I am saying "there are often 
more-appropriate (vs. less-appropriate) places to have a discussion to achieve 
consensus."  Sometimes, it makes sense to have an off-list email conversation 
in a one-on-one or one-on-many fashion.  Thanks.

SteveA
California

> On Jan 24, 2019, at 9:40 AM, OSM Volunteer stevea  
> wrote:
> 
> On Jan 24, 2019, at 9:29 AM, john whelan  wrote:
>> You seem to have made rather large changes without consultation including 
>> changing the title of the project.  You have also added some value 
>> judgments.  A number of people were involved in the original and it might 
>> have been nice to consult with them before making such drastic changes.  The 
>> word consensus springs to mind.
>> 
>> I make no comment on whether the changes are good or bad merely extensive 
>> without apparent consultation. 
> 
> John, much consensus is achieved in wiki Discussion(s), simply click the 
> Discussion tab, https://wiki.osm.org/wiki/Talk:Canada_Building_Import and 
> notice that there are four threads/sections under Discussion there already.
> 
> If some "number of people" were involved in the original, they are perfectly 
> welcome to join there.
> 
> I'm not saying "don't do this in talk-ca" I am saying "there are often 
> more-appropriate (vs. less-appropriate) places to have a discussion to 
> achieve consensus."  Sometimes, it makes sense to have an off-list email 
> conversation in a one-on-one or one-on-many fashion.  Thanks.
> 
> SteveA
> California


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[OSM Volunteer stevea]

Yeah, even going to 8 GB (-Xmx8192m on my java launch command line) I hang 
about halfway through opening "Loading json file."  I'll try 16 GB (whew!) and 
QGIS next.

Steve

> On Jan 19, 2019, at 2:17 PM, James  wrote:
> 
> use qgis or launch josm with java in 64bit mode(d64) with memory options 
> (Xms, Xmx), or it will crap out at 3.5GB
> 
> On Sat., Jan. 19, 2019, 5:13 p.m. OSM Volunteer stevea 
>  On Jan 19, 2019, at 2:01 PM, James  wrote:
> > Is there no one that will analyse the data I've posted here? 
> > https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
> >  or are we just email thread warriors?
> 
> Well, slow down there, cowboy, it is gigabytes of data and I've been busy 
> replying to talk-ca, though my CPU is hot decompressing and opening your file 
> right now.  Though even with JOSM getting assigned multiple gigabytes of heap 
> space (and I've got plenty dozens of GB of RAM), I'm still getting 
> out-of-memory errors on trying to bite-and-chew this monster.
> 
> Maybe some of ARE email thread warriors, but I am not "just" an email thread 
> warrior.
> 
> SteveA
> California


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[OSM Volunteer stevea]

On Jan 19, 2019, at 2:01 PM, James  wrote:
> Is there no one that will analyse the data I've posted here? 
> https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
>  or are we just email thread warriors?

Well, slow down there, cowboy, it is gigabytes of data and I've been busy 
replying to talk-ca, though my CPU is hot decompressing and opening your file 
right now.  Though even with JOSM getting assigned multiple gigabytes of heap 
space (and I've got plenty dozens of GB of RAM), I'm still getting 
out-of-memory errors on trying to bite-and-chew this monster.

Maybe some of ARE email thread warriors, but I am not "just" an email thread 
warrior.

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] 2020 building import

[OSM Volunteer stevea]

On Jan 19, 2019, at 1:22 PM, john whelan  wrote:
> As a point of information the 2020 web page I think was started by Julia and 
> very heavily edited by Stevea.

Sure I did, because it seriously lacked in the technical direction anybody 
would need to "map going forward" in the project/initiative as described.  What 
tags, what tools, what's the finish line?  It was hugely vague, essentially not 
a wiki that "nuts and bolts" OSM editors who wanted to make real contributions 
would be able to refer to and get concrete answers to their "how do I DO this?" 
questions.  And that's what wikis normally do, not "catch imagination."

> I think we are now agreed that the 2020 project with its idea of mapping 
> buildings in iD is not optimal.

This distinction of "don't use iD, it sucks at allowing good building data to 
enter (except for tags, maybe)" is somewhat new to me.  I don't doubt it 
happened, but it almost seems a "red herring distinction" (distraction?) at 
this point in time.  And if "don't use a particular editor" is the bottom-line 
result from all the effort that came from writing that wiki, that's not a lot 
of bang for the buck.

> However Julia's style did make its mark with many students and educators and 
> caught their imagination.

Fine, glad to hear it.  However, please don't pretend that wiki is the document 
that "roll up our sleeves" volunteers go-to to discover "HOW?" as the be-all 
and end-all of answers to our questions (most quite specific and somewhat 
technical, though truth be told, not truly difficult, simply trying to draw a 
line from "can't do it" to "ah, now I see how").  OSM volunteers need guidance 
and answers to their questions, especially in huge, nationwide endeavors.  Plan!

Answering "how do I do this in OSM" questions is what wikis in OSM are pretty 
good at doing, usually.  While Julia's might have a style that appeals to 
students (and that's "not nothing") it was essentially "non wiki-like" in what 
wikis usually do.  The remedy?  Fix the existing wiki (that re-write, despite 
my best efforts, did not produce the desired results, or did so in odd and 
ineffective directions) OR write wholesale new wikis which DO get the job done. 
 Largely, the Import Plan (the "current wiki" of this project) still doesn't 
fully do that (and an Import Plan is not a WikiProject), but "necessary steps 
to get the job done" are at least "out there somewhere," and hopefully will get 
better.  (Look, Yaro "discovered" methods to move the ball forward, so it's 
possible).  Anybody up for writing a real WikiProject for this endeavor?  (Not 
me).  The project really would benefit by this (and provincial-level wikis, 
too, imo) as well.  We're in early days, let's see what unfolds.  "The snowball 
is rolling downhill" and it's hard to predict what surprises OSM will reveal as 
things pick up mass and speed.

> The import plan is not the 2020 web page, it is something different. The 2020 
> web page has a pointer to it and it is the import plan or the import we are 
> talking about here.

Starting with a fresh WikiProject (and even what it should be named are being 
thrown around, e.g. by Nate in the Talk tab) seems a fairly important direction 
to take.  I've done this with WikiProject United States Bicycle Route System 
(fairly successfully) and WikiProject United States railways.  The latter is a 
tough slog, starting from our 2007 TIGER data import of USA railways (many 
times more massive data than Canada's building import), though since I started 
to talk about this on talk-us in 2013-4, spoke about it at SOTM-US in Seattle 
in 2016 and at end of 2018, we now have almost half the US states (all Western 
states, some Eastern) with a wiki describing the state of their rail (both 
freight and passenger) and color-coded tables which describe how far along we 
are with TIGER Review.  Replicate that, Canada, please, in your own way, at 
your own pace.  Such massive, nationwide projects CAN be done, and while I'm 
not saying I did this single-handedly, I'm living proof that a dedicated leader 
can take it far, far forward.   So, GO!  You, I, many can bang out a decent 
(skeletal, at first, they always are) wiki in two hours to a weekend, so get 
busy.

> The decision was taken by the small group who are putting this lot together, 
> to keep the 2020 as part of the name in order to link the two together.  A 
> large part of the 2020 project was enriching the building outline data and 
> that I think was and still is important.

Great.

> What would be interesting is to hear from Canadian mappers what their current 
> thoughts are.  The earlier talk-ca comments are still in talk-ca but remember 
> some time has passed since they were made.  Certainly Nate for one was not 
> around in talk-ca when the matter was discussed.

You asked for "Thoughts?" and you got mine.  Yes, let's hear from Canadians, 
please.

SteveA
California

P.S.  Merci à Pierre pour son récent post de Toronto stats

Re: [Talk-ca] (no subject)

[OSM Volunteer stevea]

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 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[OSM Volunteer stevea]

On Jan 17, 2019, at 6:27 PM, Jarek Piórkowski  wrote:
> When no one is responding, sometimes it is because they are fine with
> the message as-is. I read it. I was fine with it. This isn't an
> Australian election.

I'm not sure about the allusion to Australian elections, so I'll let that pass 
(over my head).  I will self-admonish at not saying more in November at the 
"reboot post," as while I felt then that these (BC2020) efforts would go awry 
(again) this time (and here we are) I also felt like some (would, do) see me as 
a loud-mouth with an unwelcome message.  Despite my continuing desire to be 
polite ("you catch more flies with honey than you do with vinegar"), no amount 
of sugar-coating was going to sweeten a dearth of consensus and a 
still-vinegar-sour early-draft wiki into the green flag of "let's proceed."

I tried to write as much as I thought helpful into that wiki, however, it never 
became more sharply focused, which badly needed doing.  Lesson learned (by me, 
how about Canadian OSM volunteers?).  Honestly, I am not looking to flog 
anybody here, let's simply learn how to do this better.  There are kernels of 
success here that can be further developed, so, go do that.  Figure out how, 
first, then proceed.  Most/all of the principal and important players talking 
to each other while/as you do so seems like "first grade" to me and isn't 
really so hard, it's more like effort that needs to be truly expended rather 
than wished for instead.  OSM isn't a crowdsourcing magic trick.  Especially 
with nationwide efforts, it's "one building (rail line, bike route, park 
boundary...) at a time."  Do that well (early) and scale that up (after).

> I must say I find the panic about imperfect building shapes is a bit
> amusing considering the very poorly manually-drawn sidewalks I've been
> seeing and having to fix in Toronto, or thousands of laneways having a
> descriptive "name" added by our corporate friends. Do we aim for
> perfect, or for good? Because if it's perfect, I see a _lot_ to be
> reverted or deleted.

Thanks, Jarek.  Considering I am a proponent of "perfection must not be the 
enemy of good" (regarding OSM data entry), I think data which are "darn good, 
though not perfect" DO deserve to enter into OSM.  Sometimes "darn good" might 
be 85%, 95% "good," as then we'll get it to 99% and then 100% over time.  But 
if the focus on "how" isn't sharp enough to get it to 85% (or so) during 
initial entry, go back and start over to get that number up.  85% sounds 
arbitrary, I know, but think of it as "a solid B" which might be "passes the 
class for now" without failing.  And it's good we develop a "meanwhile 
strategy" to take it to 99% and then 100% in the (near- or at most mid-term) 
future.  This isn't outrageously difficult, though it does take patience and 
coordination.  Open communication is a prerequisite.

SteveA
California
___
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

[OSM Volunteer stevea]

The thread link is:  
https://lists.openstreetmap.org/pipermail/imports/2019-January/005878.html

SteveA

___
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

[OSM Volunteer stevea]

This is redirected (by request of its author) from a thread on the (talk-) 
imports mailing list at .
On Jan 17, 2019, at 4:55 PM, John Whelan  wrote:
> The import was discussed on talk-ca and in my opinion there was a consensus 
> of opinion it should go ahead. The data comes from the municipalities of 
> which there are some 37,000 separate ones in Canada.  The idea of a single 
> import plan was suggested on talk-ca by someone not involved rather than have 
> 37,000 different import plans.  Many municipalities are very small.

There was a serious dearth of reply, and nothing even approaching "consensus of 
opinion," indicating (to me and likely others) that a nationwide import did not 
have the wide, national consensus it must have to continue.  John, we're simply 
going to disagree about that, it seems.  Especially in light of the events in 
this desire/wiki/project going back to 2017, MUCH more consensus ought to have 
been built.  I kept my mouth largely shut at the reboot two months ago, yet 
here we are.

> If you look at Canada there are locations with poor imagery and lots of 
> buildings and my suspicion is some were being imported without the licenses 
> really meeting the OSM licensing requirements.

Really?  Then, fix this.  That's a bit blunt of me, yes, yet, there it is.  
Stop.  Fix this.  You need coordination, via built-in tools like wiki, this 
list, and a real dialog made up of real conversation for this to continue.  
There appears to be a desire to do this, but there does not appear to be 
anybody willing to take responsibility to do it right, except perhaps 
(presently) Yaro, who John apparently not only has never met, but in all 
likelihood, has never communicated with.  Hence, "let your wiki communicate for 
you."  It is very good at this, I speak from personal experience on nationwide 
efforts, though I will tell you it takes work, dedication, time and writing 
skills.  Dismissing wiki as "too detailed" or "ineffective" is not a green flag 
to begin a race.  It means "stop, fix the wiki so anybody who comes along will 
know what to do."  So:  "bzzzt."  Not there yet, though, it seems Yaro was able 
to glean enough to make progress.  Grow his kernel of expertise and expand what 
works about it.

> Many locations in Canada do not have a group of OpenStreetMap local mappers.  
> Many locations do.  Locating local groups is difficult.  My understanding is 
> it has always been it is the local community who make the decision to do an 
> import.  We did use talk-ca and if you wish to continue the conversation then 
> I would suggest that is the place to hold the conversation.  I think the 
> problem here is defining the ideal local community.  It is probably somewhere 
> between the whole of Canada and each individual municipality and contains 
> groups of local mappers.

Really?  Then, fix this.  A national project (nearly single-handedly) like this 
into OSM is a very, very tall order.  It seems quite disingenuous to me to 
initiate these data and "hope for the best."  It's not exactly the same as 
giving matches, gasoline, dynamite, liquor and car keys to teenagers and being 
surprised at a tragic outcome, but it does stray in that direction of 
irresponsibility.  This time, I don't think you are allowed to be surprised.

> The intent is certainly to involve local mappers, building outlines by 
> themselves are especially interesting but building outlines with added tags 
> are much more interesting.  We need boots on the ground, we need local 
> mappers onside. 

You (John, others, the poorly-focused impetus to import these data...) DID get 
local mappers involved.  Today, I believe John implied or said he hasn't even 
communicated with them.  (Or barely has).  Yet while some work seems patient 
and better quality, enough bad data alarmed Nate (and others, myself included) 
enough to say something.  This simply shouldn't happen.

Please right your ship.  I don't pretend to represent all of OSM as I ask this, 
but I do stand tall in this project and politely ask you to do so.  Nate wrote 
some powerfully-potent directions for this building importation to go in with 
his later post.  Those are a good start, a "productive way forward."  Talk-ca 
(this channel) and wiki (including its Talk page, Discussion tab) are 
wide-area, very open, vetted, scrutinizable methodologies to communicate about 
this.  Let's keep the way(s) forward OPEN for discussion so this doesn't happen 
any longer.  Please!

We don't need 37,000 import plans and nobody is suggesting we do.  We do need 
good project management to import Canada's buildings.  There, I said it.  
(Again).  This starts with good, open communication.  Nothing less will do, or 
you consign your project to a whispered hope upon the wind, and that won't do 
it.

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Exit with name on node *and* destination

[OSM Volunteer stevea]

Between "out meta;" and "out meta qt;" there should be a >; but sometimes this 
gets mangled.
Entre "out meta;" et "out meta qt;" il devrait y avoir un >; mais parfois cela 
est mutilé.

So, I'm choosing to share an "OT share link:"
Donc, je choisis de partager un "lien de partage OT:"

http://overpass-turbo.eu/s/DrG

Good luck / bonne chance,
SteveA
California

> As Overpass Turbo allows named area geocoding, try this:
> Comme Overpass Turbo permet le géocodage de zone nommée, essayez ceci:
> 
> [out:xml]
> [timeout:25];
> {{geocodeArea:Quebec}}->.searchArea;
> (
>  way["service"="emergency_access"](area.searchArea);
> );
> out meta;
>> ;
> out meta qt;
> 
> You can modify what is inside the "way" part of the query any way you like.
> Vous pouvez modifier le contenu de la partie "way" de la requête à votre 
> guise.
> 
> SteveA
> California


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Exit with name on node *and* destination

[OSM Volunteer stevea]

On Nov 6, 2018, at 8:08 AM, Pierre Béland  wrote:
> Petit test rapide avec Overpass. J'observe que les clés suivantes sont 
> utilisées
> highway=service
> service=emergency_access
> access=no
> exemple https://www.openstreetmap.org/way/19692719
> 
> La Requête Overpass ci-dessous avec paramètre around, détecte les voies de 
> service à proximité d'autoroutes sans clé  service=emergency_access ou 
> access=no.  Sélection d'un grand bbox requiert long délais d'exécution.  Et 
> d'autres chemins de service se retrouvent dans les résultats, notamment les 
> voies de service pour haltes routières.
> 
> https://www.openstreetmap.org/way/20057142#map=16/44.8089/-73.4450
>  
> Pierre 

As Overpass Turbo allows named area geocoding, try this:
Comme Overpass Turbo permet le géocodage de zone nommée, essayez ceci:

[out:xml]
[timeout:25];
{{geocodeArea:Quebec}}->.searchArea;
(
  way["service"="emergency_access"](area.searchArea);
);
out meta;
>;
out meta qt;

You can modify what is inside the "way" part of the query any way you like.
Vous pouvez modifier le contenu de la partie "way" de la requête à votre guise.

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Talk-ca Digest, Vol 129, Issue 15

[OSM Volunteer stevea]

On Nov 5, 2018, at 7:29 AM, keith hartley  wrote:
> I saw it was a great job. But you're correct, I have no documentation on how 
> they did it. Licence process, wiki ( I feel Steve already yelling at his 
> computer) 

If you mean me, I'm saddened to hear that others think I "yell."  Rather, my 
motivation is to see that:

1)  High quality (or VERY high quality) data are what get uploaded to OSM,
2)  License terms are compatible with ODbL (I respect how difficult this can 
be, especially with the limited bandwidth of OSM's LWG and the wide variety of 
activities taking place in a very widely geographically dispersed country like 
Canada) and
3)  Communication about these efforts stay within a public realm (or "more 
public," as in "open source based protocols" rather than "secret sauce walkie 
talkies" hobbled by license agreements, like Facebook/Twitter/Instagram and 
Slack).  Yes, primary among these are talk-ca and imports mailing lists, OSM's 
wiki pages, especially explicit Import Plans and Tasking Manager for projects 
"approved" by the wider community and actually underway.

Right now, with John Whelan's (and others') recent newer thrusts to provide 
momentum to buildings getting entered (and/or improved) on Canada, I'm doing my 
best to "largely watch" (from the sidelines) what is happening right now.  I 
see no reason to "burn bridges" when I don't mean to or need to do that.

And yes, I do know that "you catch more flies with honey than you do with 
vinegar."  (No, that isn't a slight at calling anybody "flies," rather a saying 
that means "positive encouragement works much better than throwing rocks").

SteveA
California

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Stats Canada new building outlines Open Data do we wish to import it?

[OSM Volunteer stevea]

On Nov 2, 2018, at 3:58 PM, John Whelan  wrote:
> So to paraphrase your reply.  A centralised import plan in the wiki which 
> says the data is approved for import and should be tackled in chunks of some 
> sort of region since we are a decentralized organization.  Which I think is 
> similar to the way Task Manager works.  The project is broken into tiles and 
> each tile is tackled completed separately. The 'Tiles' would of course be 
> somewhat larger in area and there is a technical limitation as to how big an 
> area can be downloaded from the OSM server.
> 
> The local mappers certainly have a role to play and because the goal is not 
> only to import the buildings but to enrich the tags with commercial etc so 
> the tag enrichment would be a task that a mapathon could tackle.  I 
> personally don't think a new mapper using iD in a mapathon has a role to play 
> in importing the building outlines into OSM.
> 
> The plan should include the technical steps to import the data.

AND, must include how existing data in OSM (as there appears to be "in some 
cases, significant" (I haven't examined the entire dataset, to do so would be 
overwhelming) which overlap with the "official datasets" will be conflated.  
That is a critical step.

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Stats Canada new building outlines Open Data do we wish to import it?

[OSM Volunteer stevea]

On Nov 2, 2018, at 3:35 PM, Pierre Béland  wrote:
> La rédaction d' une page wiki pour l'ensemble du Canada peut répondre aux 
> exigences du groupe Import de OSM. Mais l'organisation doit être 
> décentralisée.

Je conviens qu'il est plus facile de rédiger un "plan d'importation" unique 
pour tout le Canada. Cela devient donc très difficile à déterminer pour les 
Canadiens. Toutefois, si de tels plans deviennent localisés, des plans 
d'importation réellement localisés sont réellement nécessaires. Bien sûr, il 
peut y avoir des chevauchements et des similitudes, mais des plans 
d'importation différents mènent nécessairement à une documentation unique et 
distincte.

Lorsque je télécharge de petits échantillons de données (par exemple, 
ODB_NorthwestTerritories qui n'inclut que Yellowknife), je constate qu'une 
grande partie ou la plupart des données des fichiers de formes de construction 
sont déjà téléchargées vers OSM, à quelques rares exceptions près ou lorsqu'un 
très faible pourcentage de les bâtiments existants ne diffèrent que d'un mètre 
ou deux. Tout plan d'importation doit tenir compte de la manière dont ces 
données seront regroupées.

Cordialement,
SteveA
Californie
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Enablers and Barriers for Voluntary Participation in Crowdsourcing Platforms

[OSM Volunteer stevea]

On Nov 2, 2018, at 9:31 AM, John Whelan  wrote:
> My feeling is OpenStreetMap has two sides.  The first is local adding local 
> knowledge to the map.  The other I'll call armchair mapping.  When Stats 
> Canada did the pilot it tapped the local Ottawa mappers who meet physically.

Speaking from nearly a decade of experience, OSM has many, many sides, though 
the two that John Whelan identifies are two many find "readily apparent."  I 
quick-read the study, which was actually quite informative in that it broke up 
similar crowdsourcing efforts (OSM is only lightly mentioned) into demographic 
categories, with some surprising results.  One is that many volunteers are 
older, sometimes disabled (stroke victims noting benefits of "repetitious tasks 
which help my brain to heal" was cited) and have a particular need for the 
sorts of social feedback which projects like this uniquely offer.  (At the same 
time, there is often a sharp dichotomy between these sorts of crowdsourced 
projects and social media, with many in the study who prefer the former 
appearing loathe to use the latter).

Another very important take-away is how participants in projects like these 
truly improve their skill-sets (seriously improving quality of submitted data) 
over time:  like many things, the longer one participates, the better become 
their skills.  This emphasizes the importance of "growing experts," something 
seldom mentioned in OSM.

> I would agree that amongst mappers with the most edits there is a high number 
> of retired people and those with disabilities involved and these may not be 
> visible.  Tapping them for groups coming together to map can be a problem.

It might appear that way (that they are invisible), yet there is no denying 
that "they find you."  In short, "build a project that attracts older, likely 
high-skill (or can grow there) participants, and they will come."

> In my view typically the most productive mappers are those with a special 
> interest.  Adding WiFi access or churches for example or even a change of 
> street name.

While it is difficult to say why mappers become productive, it may be even 
harder to do the apparently more simple task of defining "productive."  I know 
one mapper who flits about the entire planet in OSM, seeking to "up his stats 
on a leaderboard" as he measures the number of edits he makes in the tens or 
hundreds of thousands.  Needless to say, the quality of his edits, and how 
productive he is, is a matter of contention.  There is such a thing as "high 
quality" and in OSM this can and should be defined and refined especially for 
major projects.

Certainly "quality of data entered" is one metric, yet even that can be hard to 
define or measure, unless strict criteria are established at the beginning of a 
project as a goal to strive.  Once again, and especially in highly ambitious 
projects (like BC2020) this underscores the need for some up-front planning, 
up-front project management, up-front expectations of data quality and up-front 
documentation of all of these things so that these expectations are met and 
measured along the way.  (Project Management 101, really).

> We also have a number of teachers who would like to use OSM and in particular 
> the building project to involve their students.  We get a fair amount of data 
> added but the quality can be questionable.  HOT and others I think have found 
> that using a restricted set of tasks and tags works best.

I personally have experienced helping professors at the university level 
(computer science, environmental studies...) use OSM, as students at the 
undergraduate level readily take to OSM.  Younger students (high school, middle 
school) enjoy some success with it, more often at smaller, less ambitious 
tasks, a recently popular one in the USA being "micro-mapping our local school 
campus."  (Drinking fountains/water stations, extremely detailed sporting 
facilities, footways and associated potential routing, landscaping, 
restricted/off-limits areas, parking areas for autos, motorcycles, bicycles, 
etc.)  What often works is breaking students into functional groups (sports 
facilities, transportation, amenities...) and having a teacher/administrator 
check the results of each group.  The tags can start out restricted and stay 
that way, or they can start out restricted and allow the students to develop 
further "depth" by researching OSM's wiki pages, or even (yes, this is 
advanced) structure their own scheme.  For example, a high school has four 
different libraries in several different buildings, or extensive sports 
facilities, how might we best tag these?

And whether young, old or in-between, Martijn van Exel (an OSM superstar) has 
proven with his (well, largely his) MapRoulette project that "gamification" can 
really super-charge particular kinds of data entry/improvement sub-projects 
like few other strategies can.  The Study confirms this, saying "Platform 
features such as gamification, 

Re: [Talk-ca] Nova Scotia imports, and boundary=land_area

[OSM Volunteer stevea]

On Nov 1, 2018, at 12:47 PM, Дмитрий Киселев  wrote:
> Looks like the wiki needs amending to only list open data with the correct 
> license either separately or a note added to each entry.

Mmmm, not "only," an Import Plan is required, too.  That can be part of a wiki 
that describes the project in general or stands on its own as a separate wiki.  
But it is required.

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Open Database of Buildings / Base de données ouvertes sur les immeubles

[OSM Volunteer stevea]

Additionally, the greater OSM community looks forward to your Import Plan that 
follows our Import Guidelines ( 
https://wiki.openstreetmap.org/wiki/Import/Guidelines ).

Regards,
SteveA
California

> On Nov 1, 2018, at 11:22 AM, John Whelan  wrote:
> 
> I think on the OSM side we probably need to think this one through and get 
> organised.
> 
> In Ottawa on the first import we went through all the steps to do the import 
> including getting agreement with the local mappers and we were very fortunate 
> in having an organised team of competent local mappers to do the import.
> 
> It went reasonably smoothly but there were some questions asked and one or 
> two buildings were probably remapped which raised some eyebrows.  Since its 
> been released under the federal government open data license licensing isn't 
> an issue.
> 
> If we do nothing on the organising side then we will almost certainly get 
> individuals importing Open Data in an ad hoc mode as has been happening in 
> Nova Scotia recently.
> 
> My feeling is it would be better if mappers in the major cities / regions 
> such as Toronto and Montreal took the lead for their cities / regions. 
> 
> Cheerio John
> 
> 
> 
> Alasia, Alessandro (STATCAN) wrote on 2018-11-01 2:06 PM:
>> Released today!  / Diffusée aujourd’hui 
>> Share with your networks ! / Partagez avec vos réseaux !
>>  
>>  
>> ***(EN)
>> Open Building Data: an exploratory initiative
>> This exploratory initiative aims at enhancing the use and harmonization of 
>> open building data from government sources for the purpose of contributing 
>> to the creation of a complete, comprehensive and open database of buildings 
>> in Canada. The outcome of this exploratory work is a first version of the 
>> Open Database of Buildings (ODB), a centralized and harmonized repository of 
>> building data made available under the Open Government License - Canada.
>> This initiative originates from insights taken from the Statistics Canada 
>> pilot project on data crowdsourcing, which used OpenStreetMap as a platform 
>> for integrating data on building footprints. In addition to the possible 
>> benefits of crowdsourcing, that project highlighted the potential of 
>> integrating open data from municipal, regional, and provincial governments 
>> to meet the needs of official statistics.
>> In its current version (version 1.0), the ODB contains approximately 4.3 
>> million building footprints. 
>> https://www.statcan.gc.ca/eng/open-building-data/index
>> Open Database of Buildings (ODB),
>>  
>> *** (FR)
>> Données ouvertes sur les immeubles : une initiative exploratoire
>> Cette initiative exploratoire vise à accroître l'utilisation et 
>> l'harmonisation des données ouvertes sur les immeubles provenant de sources 
>> gouvernementales en vue de contribuer à la mise en œuvre d'une base de 
>> données complète, exhaustive et ouverte sur les immeubles au Canada. Le 
>> travail exploratoire a mené à la création d'une première version de la Base 
>> de données ouverte sur les immeubles (BDOI), un référentiel centralisé et 
>> harmonisé des données sur les immeubles rendu public en vertu de la Licence 
>> du gouvernement ouvert du Canada.
>> Cette initiative est fondée sur les leçons tirées du projet pilote de 
>> Statistique Canada sur l'approche participative en matière de données, qui 
>> avait employé OpenStreetMap comme plateforme d'intégration des données sur 
>> les empreintes d'immeubles. En plus des avantages potentiels de l'approche 
>> participative, ce projet a mis en lumière la possibilité d'intégrer les 
>> données ouvertes des administrations publiques municipales, régionales et 
>> provinciales afin de répondre aux besoins en matière de statistiques 
>> officielles.
>> Dans sa version actuelle (version 1.0), la BDOI contient environ 4,3 
>> millions d'empreintes d'immeubles.
>> https://www.statcan.gc.ca/fra/donnees-ouvertes-immeubles/index
>>  
>> Base de données ouverte sur les immeubles (BDOI)
>>  
>>  
>> Alessandro Alasia 
>> Chief | Chef
>> Data Exploration and Integration Lab (DEIL) | Lab pour l’exploration et 
>> l’intégration de données (LEID)
>> Center for Special Business Projects | Centre des Projets Spéciaux sur les 
>> entreprises
>> Statistics Canada | Statistique Canada
>> alessandro.ala...@canada.ca / (613) 796-6049
>>  
>>  
>> 
>> 
>> ___
>> Talk-ca mailing list
>> 
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
> -- 
> Sent from Postbox
> ___
> 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

Re: [Talk-ca] Dartmouthmapmaker

[OSM Volunteer stevea]

Being as gentle (though not local) as I can be, I continue to assert that our 
wiki for BC2020 in general and 
https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Building_Canada_2020#The_data_that_could_be_mapped
 as a specific section IN that wiki (calling attention to these tags, with 
hundreds of potential values):

building
man_made
addr
start_date
entrance
amenity
and others

might prove very helpful starting points.  Often the simple act of reading 
OSM's built-in wiki documentation is one of the best, if not THE best starting 
point.  Of course, talk- mailing lists, our forum and many other sources of 
advice/documentation/help are available, too.

Regards.
SteveA
California

> On Nov 1, 2018, at 9:40 AM, john whelan  wrote:
> I've discussed the Open Data side with them but I think they could do with a 
> bit of guidence on the tagging side.  Could someone ideally more local than I 
> point them gently towards map features and more standard tagging?
> 
> I must confess my knowledge of tagging is a little limited to highways and 
> buildings.
> 
> I get the impression they are open to dialog if treated gently.
> 
> Thanks John
> ___
> 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

Re: [Talk-ca] Hydro Network (inland water) question

[OSM Volunteer stevea]

Heck, all kinds of things are fun to map:  bike routes, railways, making sure 
provincial and TransCanada route relations are all lined up and tagged 
correctly, bus and public_transport, small details (micro-mapping), like 
gymnasium/library details and drinking fountain locations in 
elementary/middle/high schools, it's almost endless.

Now, all the bodies of water in Canada, the 2nd largest geographic country on 
Earth, and with "hundreds" (you can grow it to thousands, I know you can) of 
dedicated mappers:  wow, that is something I'd call "you've got your work cut 
out for you!"

I mean that to be encouraging rather than discouraging.  OSM, it seems (and 
I've been at it most of its life) is a longer-term project, it's really only 
starting to fly after fifteen years or so.  Give it a few more decades 
(really), and even in a few years, it does, can and will get better.  It takes 
time, it takes dedication, it takes good communication, it takes people working 
well together.  Largely speaking (and Canada isn't large, it's HUGE!), so far, 
so good.

Encouragingly,
SteveA
California

> On Sep 27, 2018, at 4:42 PM, john whelan  wrote:
> Besides bus stops are more fun to map.


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Fwd: BC2020i - update Sept 2018

[OSM Volunteer stevea]

Thank you for those clarifications, John.  I speak for myself, but I do feel 
confident that others are learning from what you say and that OSM and all 
involved can and shall do better.  Honestly, I look forward to "better 
processes" which "make more open data available to OSM" (a worthy goal, 
indeed).  "Getting familiar with steps" is part of it, and I know we are good 
people as we see first crawling, then walking, then running, then flying.  May 
Canada and its buildings together with OSM gain much altitude and indeed fly.

Governmental agencies around the world can and will gain, OSM can and will gain 
and it will be a win-win-win all around.  Part of that happens because we talk 
to each other (civilly) and lots of people nod our heads and many/most of us 
say, "hey, yeah, that's a pretty good idea/way to do things, let's do it like 
that."  Like learning to walk, it is a process, it isn't that hard, and it does 
come naturally.

SteveA

On Sep 17, 2018, at 12:16 PM, john whelan  wrote:
> Just a comment Alessandro is not a dedicated project manager but rather the 
> person that the project manager reports to.  Currently in addition to his 
> normal job he is also acting in the position above his so he really is doing 
> two jobs at once.  Bjenk was the project manager who pulled the project 
> together and worked hard and closely with the local OSM mappers on the first 
> phase but has moved from Stats Canada to another department.
> 
> Alessandro has had staff working in the background to find ways to make more 
> open data available to OSM but probably isn't familiar with all the steps to 
> bring it in.
> 
> The numbers from Ottawa would suggest that we need to understand more about 
> what information is most useful and which can be easily obtained.
> 
> This isn't just about Canada by the way there are other places on the world 
> where this sort of information and the techniques used on the stats side can 
> be useful.
> 
> Cheerio John


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Fwd: BC2020i - update Sept 2018

[OSM Volunteer stevea]

I (rather fully, and without Alessandro's accusatory "troll-like behaviours," 
wow) addressed Alessandro in an off-list email reply, though I quickly received 
an "out of the office until September 21" bounce-back.  We shall see.

One thing I must say here I found unfortunate in Alessandro's post was the 
cavalier attitude of "I would like to have more time to write emails...so do 
not be offended if I will not continue this conversation."  Again, wow.

As long as we keep it civil, and I'll give us a "passing grade, just" along 
those lines, we can and should continue this dialog.  Please, let's do our best 
to keep it civil.

SteveA

> On Sep 17, 2018, at 8:31 AM, Alasia, Alessandro (STATCAN) 
>  wrote:
(a reply to my missive)
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Fwd: BC2020i - update Sept 2018

[OSM Volunteer stevea]

Matthew, I personally thank you for sharing Alessandro's missive with talk-ca (an OSM-based list).However, Alessandro mentions "BC2020i" (and even "BC2020i-2"), initiatives which "used" (or proposed to "use") OSM as a data repository.  Not wishing to rehash history about this yet again, the initiative was found to not fully respect some basic tenets of OSM (primarily that process and importation of data be "Open") and a genuine attempt was made (partly rather publicly here) to re-imagine a re-branded project (BC2020, no "i") which more openly and harmoniously integrated with a wider OSM community using familiar and more-open communications channels like our wiki and this talk-list.As Alessandro didn't mention OSM one single time in that message, yet it was forwarded to this list, I remain quite curious what role OSM is to or might play in any "BC2020i-2" initiative.  So, I invite / politely request Alessandro to post here exactly what that is or will be.  Is it a national-scale import of the Bing building data (as he says "what they did in the US")?  I realize that from STATCAN's and indeed a much wider Canadian perspective, this "initiative" will be much more than that, benefiting many, and for that I do share enthusiasm.  Still, I ask the specific question from an OSM perspective:  what role will our mapping project play?Please, Alessandro, address OSM directly (in this list) what OSM is to BC2020i-2.  You might start by addressing what is wrong with BC2020 (no i) as it exists in our wiki and how BC2020i-2 might diverge from that, but I'd prefer you explain it to us, rather than me guessing here in talk-ca.Regards,Steve AllOSM Volunteer since 2009
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] counting buildings - ( 2020 project ) - help please.

[OSM Volunteer stevea]

On Sep 12, 2018, at 11:06 AM, john whelan  wrote:
> One of the requirements was to create something that did not require an 
> Internet connection

OK, yet I had no way of knowing that from your post.  Though, that is an 
"interesting" requirement for a crowdsourced, Internet-based map database.

> or a Ph.D. in OpenStreetMap jargon.

C'mon, John, I'm offering earnest help with a powerful tool familiar to a great 
many OSM users and a drop-dead-simple query whose guts are:

{{geocodeArea:Ottawa}}->.searchArea;
(way["building"="residential"](area.searchArea););

That's pretty much it, and you get your results in seconds visually or in 
various export formats.

> As I mentioned I'm after end users rather than OSM technically knowledgeable 
> ones.

By substituting "node" for "way" or other text-strings for the keys or values 
you're looking for, and with a multitude of output formats, this is not 
Ph.D.-level stuff:  it is designed to easily query OSM data, returning results 
in familiar "map/visually" OR well-known geo datafile formats.  It isn't 
jargon-y, it IS used by "end users" and by OSM technically knowledgeable ones 
alike.  Using OSM data?  (Yes, you are):  use OSM-based tools.  You want 
jargon, use R.  I'm trying to help create light, not heat.

> Another was the ability to combine the information with other data.

Export the results of OT queries, and ye shall.

> Thank you for your thoughts and hopefully the answers will clarify what sort 
> of assistance I'm after.

You are welcome, and I'll be curious to watch what happens.  As I saw your 
request for feedback is to be off-list, we who are on-list (I speak for myself 
right here) appreciate hearing of any fruit your query may bear.

Best regards,
SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] counting buildings - ( 2020 project ) - help please.

[OSM Volunteer stevea]

Whew, seems like overkill.  Try "overpass turbo" (OT) for such queries.  Here 
is a sample, and the query language (OverPass QL) is text-based and 
OSM-friendly, as it uses the tags you're searching for:

http://overpass-turbo.eu/s/BQ6

When it dialogs that the query will return a lot of data, click the "continue 
anyway" button and wait a few seconds.  The data are returned visually and you 
can export them in various formats (raw OSM data, GeoJSON, GPX, KML).  Look to 
the left column to see how easy the tags are and read our wiki on OT for rich 
and rewarding documentation.

Have fun,

SteveA
California

> On Sep 12, 2018, at 10:39 AM, john whelan  wrote:
(a lot about how hard it is to query our data).
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] GitHub app for BC2020i Challenge

[OSM Volunteer stevea]

On Sep 6, 2018, at 4:30 PM, john whelan  wrote:
> The pilot project itself did manage to get a fair amount of accurate data 
> into OSM.  That data is still there and can be used.  It was instrumental in 
> supporting the HOT summit in Ottawa.  It managed to raise awareness within 
> local government both in Canada and in Africa about how OSM could be useful 
> and it clarified a number of legal issues about importing data.

Then, quite a number of events caused it to go off the rails.  OK, that 
happens; no judgement on my part, I'm far, far happier to try to watch the 
smoke clear and "might I offer to help?"

> > And I'm not boasting, but I did put some effort into the richest set of 
> > potential tags (harvested from our wikis) than I believe anybody else did, 
> > and I don't really have any specific interest in the project, except that 
> > it be a WELL RUN project.  (So I tried very hard to "seed it well"). 
> 
> You mean me getting the recumbent trike out and site inspecting a few hundred 
> buildings and adding tags to them was for nought?  How sad.

John, I'm on your side, the side of OSM having great data while it builds 
communities across Canada, universities, high schools, libraries, etc.  I'm 
happy the project has "stubbed in" (it's certainly "not nothing!") at least 
some data.  Dust off your hands and keep going!  (Is hopefully the attitude I'm 
encouraging you to adopt).

> There is still a gentle movement to gather more data over time, whether we 
> are keeping the current building data up to date is a separate issue.  Stats 
> is still trying to find ways to make building outlines available under their 
> Open Data license.

A 100% separate track for which I wish them the very best of luck.  That may or 
may not be successful, and CAN and SHOULD happen on a parallel track with OSM 
strategies which work.  I'll stand shoulder-to-shoulder with THAT spirit, as it 
is what makes OSM a very powerful OSM.

> The approach used on the pilot to import building outlines manually has been 
> picked up by Microsoft who have been making them available for the USA and I 
> understand Stats were involved with discussions with Microsoft about some 
> technical aspects.

Truly, I'm glad to hear it.  OSM and Microsoft (and now, it turns out, Stats 
Canada) do get symbiotic every once in a while, and we're all the better for it 
as/when it happens.

> The Ottawa pilot was a perfect storm in many ways with many different players 
> involved coming together.  Reproducing it is harder than it first seems.

I get that, so do others.  A "more valuable" aspect to pick up as a shiny coin 
from that is the learning experience that it is.  In QA this is called a "post 
mortem" and is one of the most valuable data chunks for "the next phase" (and 
there always is a next phase).

> What I would like to see is someone pick up doing analysis with R r.org to 
> see if we can build the feedback loops that might help motivate getting the 
> tags populated.

Heh, you could sketch up a wiki to get them started...! :-)  (It's not a bad 
idea, really).

Steve
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] GitHub app for BC2020i Challenge

[OSM Volunteer stevea]

On Sep 6, 2018, at 1:14 PM, john whelan  wrote (replying 
to me, stevea):
> > Hm, we tried to revive the wiki, a tried-and-true OSM methodology for doing 
> > EXACTLY that.  Is there something wrong with that idea? 
> 
> No this project was initiated by Stats Canada, but without clear requirements 
> or feedback about what had been achieved.  The Stats Can side wasn't 
> dependant on normal OSM mappers but my understanding was it was hoping to 
> draw in new mappers.

John, BC2020i (note the i) was initiated by Stats Canada.  Threads here, 
consensus and the wiki declared it dead, as it failed on a number of fronts, 
primarily that it didn't respect OSM in certain ways in which OSM must be 
respected.  It MIGHT have become resurrected as BC2020 (no i) and the wiki were 
attempts to do that, especially as Stats Canada was out of the picture by then, 
as they weren't going to contribute to either the wiki or the BC2020 itself, 
though, like anybody who "takes" (uses, and not in a bad way) OSM data, 
StatsCanada would be welcome to the results of BC2020 (and BC2020i is dead, 
I'll say it one more time).  We stripped away what was wrong with "i" and 
slightly renamed the project to conform to the way that OSM has, can, does and 
will complete projects (including, but requiring that we use wikis).  BC2020 
seems to have become moribund and ineffective, though I continue to hold out 
high hopes that it can be successful.

OSM actually DOES have clear requirements or feedback, part of those are 
naturally "built in" to crowdsourced projects, part of those need a bit of 
goosing along by prompting volunteers to communicate well (wiki is ONE way, not 
the only way) via simple things like reporting progress and/or continuing to 
sharpen up focus because tagging started out as an early draft, but now is a 
"more complete" or "final" draft.  Sure, any good project wants to start out 
with clear goals (and should) but a modest bit of mid-course correction 
certainly won't prevent successful completion.

> Fine but a couple of maperthons that were organised had data quality issues 
> and no clear guidance about what tags were most valuable.

That's because no QA was planned up front, just like I suggested to do last 
year and into January of this year.  And I'm not boasting, but I did put some 
effort into the richest set of potential tags (harvested from our wikis) than I 
believe anybody else did, and I don't really have any specific interest in the 
project, except that it be a WELL RUN project.  (So I tried very hard to "seed 
it well").  In crowdsourcing, yes, this can be challenging, but communication 
is the lynchpin that allows it.  Wikis, at least in OSM can be and often are a 
critical component of the successful ongoing (status reporting, etc.) and 
completion of projects.

> I could be wrong but I'm not aware of any significant movement on the project.

OSM (worldwide, not "just" in Canada or any particular country) seems to be in 
a communication crisis, where everybody thinks that some sort of 
"secret-special-sauce walkie-talkie" (like GitHub or Slack) will solve 
everything.  No.  While those have their place (let me emphasize, I truly mean 
that) they will continue to Balkanize (fracture) and legally bind (have you 
READ the contracts GitHub and Slack ask you to agree to?!) OSM volunteers far 
past the state of hobble-and-wobble, it will kill us.

Talking about GitHub is like pilot-radio-chatter:  specialized, harmful to 
BUILDING new community (which is CRITICAL in BC2020) and will keep you grounded 
as certain as a hurricane.  OSM Canada knows how to crawl, and even walk.  To 
run, and even fly, especially with BC2020, use what we have.  The fancy stuff 
might (MIGHT!) be used later.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] GitHub app for BC2020i Challenge

[OSM Volunteer stevea]

> Personally I think if the BC2020i is to be revived mappers really need some 
> feedback on what has been done and what tags are of interest.

Hm, we tried to revive the wiki, a tried-and-true OSM methodology for doing 
EXACTLY that.  Is there something wrong with that idea?

I've been trying to keep "the embers orange and warm" on this project (via its 
wiki) since January.

https://wiki.osm.org/wiki/WikiProject_Canada/Building_Canada_2020

If there is something wrong with that wiki (John Whelan, you have described its 
history both here in talk-ca and to me via private email any number of times), 
then re-write it.  I think it is at least a start to describe what you (Canada) 
are trying to do, so if it or parts of it are useful, use it.

On an upside, there are a lot of data there, (though some of it might be junk 
or outdated), and so as a corollary, on a minor downside, it could be said to 
be loquacious/wordy/overly detailed.  On a MAJOR downside, "BC2020" (not 
suffixed with an "i" as that is rightly declared to be dead) "needs reviving."  
OK, revive it.  If not via wiki, "because mappers really need some feedback" 
(it DOES mention Active Monitoring tools) and "what tags are of interest" (it 
DOES mention Tag Standardization" and "The data that could be mapped"), then 
HOW?  The answer:  (or at least an excellent one):  use our already-built, 
well-established, good-for-our-community tools which WORK.

Go!

SteveA
OSM Volunteer since 2009
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[OSM Volunteer stevea]

Je suis certainement conscient des différences entre le Québec et la France. 
Pas comme un Canadien natal, bien sûr. C'est pourquoi j'ai dit "pour choisir 
l'une des nombreuses villes que j'ai embarquées dans les trains."  Je ne suis 
pas monté à bord du train de banlieue canadien ou VIA (j’ai presque fait 
pendant les vacances) et le RER à Paris ne semble pas comparer des pommes et 
des hippopotames.

Il semble que mes commentaires sérieux ne soient pas les bienvenus ou invitent 
à la recherche de la moindre erreur.  Résumé très facile:  S'il vous plaît 
nommez vos systèmes de transport comme bon vous semble pour les francophones de 
Montréal en utilisant une bonne syntaxe OSM et nous pourrons tous profiter de 
notre été.

Je propose simplement des suggestions qui, je l’espère, favoriseraient une 
bonne cohérence entre les États-Unis, le Canada et le monde entier d’OSM et 
continueraient d’atteindre cet objectif.

Bonne journée,

Etienne
Californie

> On Aug 12, 2018, at 4:59 PM, James  wrote:
> 
> Résumé très facile: Paris ou la france ≠ Le Québec. 
> Le Québec fait les chose très différente de la France.
> 
> On Sun., Aug. 12, 2018, 8:36 p.m. OSM Volunteer stevea, 
>  wrote:
> Ayant embarqué à bord de nombreux trains à Paris (pour choisir l'une des 
> nombreuses villes que j'ai embarquées dans les trains), OSM aux Halles dit 
> "operator=RATP" et "name=RER B". Certains disent que la pure consistance est 
> stupide. Je dis "trouver ce qui fonctionne et rester cohérent".
> 
> Jusqu'à ce que v1 devienne v2 ou v2 devient v3; une telle croissance se 
> produit. Joli bavard avec toi, Canada.
> 
> Etienne
> Californie
> 
> > On Aug 12, 2018, at 3:45 PM, James  wrote:
> > 
> > Personellement la STM est connu sous la STM sur toute la "branding" (bus, 
> > arrêts, site web(stm.ca), etc) La seule exception est que son nom légale 
> > est : Société de Transport de Montréal. Pareil pour la STO à 
> > Gatineau(Société de Transport  de l'Outaouais)
> 


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[OSM Volunteer stevea]

Ayant embarqué à bord de nombreux trains à Paris (pour choisir l'une des 
nombreuses villes que j'ai embarquées dans les trains), OSM aux Halles dit 
"operator=RATP" et "name=RER B". Certains disent que la pure consistance est 
stupide. Je dis "trouver ce qui fonctionne et rester cohérent".

Jusqu'à ce que v1 devienne v2 ou v2 devient v3; une telle croissance se 
produit. Joli bavard avec toi, Canada.

Etienne
Californie

> On Aug 12, 2018, at 3:45 PM, James  wrote:
> 
> Personellement la STM est connu sous la STM sur toute la "branding" (bus, 
> arrêts, site web(stm.ca), etc) La seule exception est que son nom légale est 
> : Société de Transport de Montréal. Pareil pour la STO à Gatineau(Société de 
> Transport  de l'Outaouais)


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[OSM Volunteer stevea]

"Raise matters" isn't something I did, it is something I am doing, as in 
continuing dialog.  Donc, merci pour la suggestion, mes deux années d'écolier 
français devront suffire.  This discussion did start in English.  If you think 
a wiki page with a simple table sketches out "here's how we do this" (we've got 
one here for BART, https://wiki.osm.org/wiki/Bay_Area_Rapid_Transit and it 
syncs with https://wiki.osm.org/wiki/California/Railroads ) as in "it doesn't 
take much effort to say 'do it like this,'" hey, great.  I'm all for that sort 
of documentation and consistency and "let's communicate well."

Really, some guy in California and some guy in a larger neighboring country 
(with the longest, perhaps most lightly-protected border on Earth, displaying 
obvious trust, history and centuries of good will) having a discussion about 
improving/developing transport tagging doesn't seem it should feel this 
antagonistic.  Abbreviate, or don't.  Pay attention to infrastructure tagging, 
or don't.  More (or less) closely align with USA and OpenRailWay mapping 
conventions (there are differences, it makes sense for countries to say "here's 
how WE do it" and "here's how we AND OUR NEIGHBORS do it" makes sense for 
trains and bus schedules and bike routes.  Or don't.  These things really are 
international and good dialog makes good protocols.  We're simply people 
talking on a mailing list; I happen to believe that it's good that we do.

Good dialog is good OSM.

SteveA
California

(DJT, not JDT, of course)

> On Aug 12, 2018, at 3:15 PM, john whelan  wrote:
> 
> If you wish to raise matters about local mapping in Montreal I suggest you 
> use French as it is the language that most Montreal mappers are familiar with.
> 
> Cheerio John
> 
> On 12 August 2018 at 17:37, OSM Volunteer stevea  
> wrote:
> John, especially in light that we both volunteer in a wonderful organization 
> like OSM, I consider neither of us poor.  Truly, I mean that.
> 
> It wouldn't be "confused" that I might be.  It would be much more leaning 
> towards, if not firmly in, the camp of "abbreviating in OSM key:value pairs 
> is frowned upon because it maps backwards incompletely."  That is a fair 
> logical/mathematical/linguistic/database point.  Getting line-renderers to 
> pay attention to short_name or alt_name or local_name or coalesce on 
> something sensible, sure, that's a happy place.  I'd love to see a transport 
> renderer that is wicked-smart with v2 and even v3 savvy colors, naming, 
> routes and a "visual pop" that a good map does simply as you look at it.  
> That starts with good tagging including good discussion about tagging.  
> Simple as walking.
> 
> Politics aside and whether hordes flee JDT or not, I am talking about good 
> tagging in OSM as transport networks and how they are named and "get smart" 
> really is happening all over Earth.  Good protocols to "we're all paying 
> attention together" works.  Whether ISO/UN/IEEE or other acronyms and how a 
> committee really can get the phones to connect and the trains running on 
> time, the ideas behind "let's agree on good language and tagging..." work, 
> this is simply being good neighbors.  A big human family sharing a map acts 
> like a big human family sharing a map.  We seem to continue to do that here 
> in talk-ca, talk-us and so on.  Thank you.
> 
> SteveA
> California
> 
> > On Aug 12, 2018, at 2:17 PM, john whelan  wrote:
> > 
> > Good heavens you mean we should spell out OCtranspo as Ottawa Carleton 
> > Transpo in case any American tourists get confused?
> > 
> > Unfortunately the locals will probably get confused with this and whilst we 
> > should cater to these foreign tourists I think what is on the signs locally 
> > will be less confusing to the locals unless of course we get many more 
> > people streaming in to escape Donald.
> > 
> > Or have I misunderstood some poor American?
> > 
> > Cheerio John
> > 
> > On Sun, 12 Aug 2018, 4:48 pm OSM Volunteer stevea, 
> >  wrote:
> > Dusting off a month-old thread...
> > 
> > Damien and Jarek, it seems the examples listed below both fit into a 
> > "citizen mappers coalescing on a local/regional way to do things" as well 
> > as a "somebody unfamiliar with Canadian transport mapping w.r.t. naming, 
> > network and operator tag conventions" (maybe who reads our wikis, maybe who 
> > does OT queries...) can figure this out quickly and sensibly.  It's great 
> > to see that's where things have landed, pretty close to a 
> > sweet-spot/bullseye.
> > 
> > However (if I have to "spoil" a good 

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[OSM Volunteer stevea]

John, especially in light that we both volunteer in a wonderful organization 
like OSM, I consider neither of us poor.  Truly, I mean that.

It wouldn't be "confused" that I might be.  It would be much more leaning 
towards, if not firmly in, the camp of "abbreviating in OSM key:value pairs is 
frowned upon because it maps backwards incompletely."  That is a fair 
logical/mathematical/linguistic/database point.  Getting line-renderers to pay 
attention to short_name or alt_name or local_name or coalesce on something 
sensible, sure, that's a happy place.  I'd love to see a transport renderer 
that is wicked-smart with v2 and even v3 savvy colors, naming, routes and a 
"visual pop" that a good map does simply as you look at it.  That starts with 
good tagging including good discussion about tagging.  Simple as walking.

Politics aside and whether hordes flee JDT or not, I am talking about good 
tagging in OSM as transport networks and how they are named and "get smart" 
really is happening all over Earth.  Good protocols to "we're all paying 
attention together" works.  Whether ISO/UN/IEEE or other acronyms and how a 
committee really can get the phones to connect and the trains running on time, 
the ideas behind "let's agree on good language and tagging..." work, this is 
simply being good neighbors.  A big human family sharing a map acts like a big 
human family sharing a map.  We seem to continue to do that here in talk-ca, 
talk-us and so on.  Thank you.

SteveA
California

> On Aug 12, 2018, at 2:17 PM, john whelan  wrote:
> 
> Good heavens you mean we should spell out OCtranspo as Ottawa Carleton 
> Transpo in case any American tourists get confused?
> 
> Unfortunately the locals will probably get confused with this and whilst we 
> should cater to these foreign tourists I think what is on the signs locally 
> will be less confusing to the locals unless of course we get many more people 
> streaming in to escape Donald.
> 
> Or have I misunderstood some poor American?
> 
> Cheerio John
> 
> On Sun, 12 Aug 2018, 4:48 pm OSM Volunteer stevea, 
>  wrote:
> Dusting off a month-old thread...
> 
> Damien and Jarek, it seems the examples listed below both fit into a "citizen 
> mappers coalescing on a local/regional way to do things" as well as a 
> "somebody unfamiliar with Canadian transport mapping w.r.t. naming, network 
> and operator tag conventions" (maybe who reads our wikis, maybe who does OT 
> queries...) can figure this out quickly and sensibly.  It's great to see 
> that's where things have landed, pretty close to a sweet-spot/bullseye.
> 
> However (if I have to "spoil" a good thing, oh, well, this is a discussion 
> forum...) I do think that operator=RATP is a bit curt even as "tout le monde 
> à Paris sait ce que signifie la RATP."  (I recall being asked in a Regional 
> Transportation Commission meeting what AASHTO stood for and I got it wrong, 
> but then quickly got it right on the next try seconds later, alas, "too 
> late").  It is true that an OSM convention is name=Saint Louis instead of 
> name=St. Louis; abbreviations are frowned upon in databases like OSM because 
> they are "one-way in the wrong way."  Please let us not allow perfection to 
> become the enemy of the very good or even excellent and well-thought out and 
> discussed, as are developing public_transport OSM data in Canada.  We're 
> making a great map.
> 
> Thank you again for spirited and interesting discussion.
> 
> SteveA
> California
> 
> 
> > On Jul 16, 2018, at 6:06 PM, Damien Riegel  wrote:
> > 
> > On 12 July 2018 at 17:17, OSM Volunteer stevea  
> > wrote:
> > On Jul 12, 2018, at 1:46 PM, Jarek Piórkowski  wrote:
> > > Damien's question appears to be about nodes like
> > > https://www.openstreetmap.org/node/438843513, which has
> > > name=Berri-UQAM, operator=Société de transport de Montréal.
> > > short_name=STM seems inappropriate here, we could do
> > > operator:short_name=STM or something but it seems a bit much.
> > 
> > Thank you for your analysis and reporting to the list, Jarek!  Yes, I agree 
> > that operator:short_name=STM is a bit of "overkill" (getting over-specific 
> > on the key side).
> > 
> > > The nearby station https://www.openstreetmap.org/node/26233453 has
> > > name=Jean-Drapeau, network=STM, operator=Société de transport de
> > > Montréal which seems like an attempt as good as we might get. Commuter
> > > rail station https://www.openstreetmap.org/node/548900549 has
> > > network=RTM, operator=Réseau de transport métropolitain which fits
> > > that scheme as well. Similar with a random bus line on North Shore
> > > https://www.openstreetmap.org/relation/3472432
> > 
> 
> 
> ___
> 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

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[OSM Volunteer stevea]

Dusting off a month-old thread...

Damien and Jarek, it seems the examples listed below both fit into a "citizen 
mappers coalescing on a local/regional way to do things" as well as a "somebody 
unfamiliar with Canadian transport mapping w.r.t. naming, network and operator 
tag conventions" (maybe who reads our wikis, maybe who does OT queries...) can 
figure this out quickly and sensibly.  It's great to see that's where things 
have landed, pretty close to a sweet-spot/bullseye.

However (if I have to "spoil" a good thing, oh, well, this is a discussion 
forum...) I do think that operator=RATP is a bit curt even as "tout le monde à 
Paris sait ce que signifie la RATP."  (I recall being asked in a Regional 
Transportation Commission meeting what AASHTO stood for and I got it wrong, but 
then quickly got it right on the next try seconds later, alas, "too late").  It 
is true that an OSM convention is name=Saint Louis instead of name=St. Louis; 
abbreviations are frowned upon in databases like OSM because they are "one-way 
in the wrong way."  Please let us not allow perfection to become the enemy of 
the very good or even excellent and well-thought out and discussed, as are 
developing public_transport OSM data in Canada.  We're making a great map.

Thank you again for spirited and interesting discussion.

SteveA
California


> On Jul 16, 2018, at 6:06 PM, Damien Riegel  wrote:
> 
> On 12 July 2018 at 17:17, OSM Volunteer stevea  
> wrote:
> On Jul 12, 2018, at 1:46 PM, Jarek Piórkowski  wrote:
> > Damien's question appears to be about nodes like
> > https://www.openstreetmap.org/node/438843513, which has
> > name=Berri-UQAM, operator=Société de transport de Montréal.
> > short_name=STM seems inappropriate here, we could do
> > operator:short_name=STM or something but it seems a bit much.
> 
> Thank you for your analysis and reporting to the list, Jarek!  Yes, I agree 
> that operator:short_name=STM is a bit of "overkill" (getting over-specific on 
> the key side).
> 
> > The nearby station https://www.openstreetmap.org/node/26233453 has
> > name=Jean-Drapeau, network=STM, operator=Société de transport de
> > Montréal which seems like an attempt as good as we might get. Commuter
> > rail station https://www.openstreetmap.org/node/548900549 has
> > network=RTM, operator=Réseau de transport métropolitain which fits
> > that scheme as well. Similar with a random bus line on North Shore
> > https://www.openstreetmap.org/relation/3472432
> 


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[OSM Volunteer stevea]

On Jul 12, 2018, at 1:46 PM, Jarek Piórkowski  wrote:
> Damien's question appears to be about nodes like
> https://www.openstreetmap.org/node/438843513, which has
> name=Berri-UQAM, operator=Société de transport de Montréal.
> short_name=STM seems inappropriate here, we could do
> operator:short_name=STM or something but it seems a bit much.

Thank you for your analysis and reporting to the list, Jarek!  Yes, I agree 
that operator:short_name=STM is a bit of "overkill" (getting over-specific on 
the key side).

> The nearby station https://www.openstreetmap.org/node/26233453 has
> name=Jean-Drapeau, network=STM, operator=Société de transport de
> Montréal which seems like an attempt as good as we might get. Commuter
> rail station https://www.openstreetmap.org/node/548900549 has
> network=RTM, operator=Réseau de transport métropolitain which fits
> that scheme as well. Similar with a random bus line on North Shore
> https://www.openstreetmap.org/relation/3472432

I find that operator=* is a key which certainly applies to "underlying rail 
infrastructure" objects (railway=rail), especially when the rail is 
freight-oriented, though I have also seen operator=* set to the value of the 
passenger operator when the underlying infrastructure is one of 
[railway=light_rail, railway=subway, railway=tram] on more passenger-oriented 
rail.  Though, I seem to recall more frequently (I'd have to do some Overpass 
Turbo queries to confirm this) network=* is applied to the passenger (not 
freight) elements instead of operator=*, both are used, both seem correct.

Without getting "lost in the weeds," there are/were three "levels" of railway 
route relations:  #1 is/used to be route=tracks (largely if not completely 
deprecated in North America, but maybe still used in Germany), #2 is 
route=railway (a grouping of what we in N.A. call "Subdivisions" or "Branches" 
or "Industrial Lines") and #3 is route=train relations for passenger rail.  We 
can (and do) have passenger rail as route=train relations all over N.A. withOUT 
the "underlying infrastructure" of route=railway relations, but I, others and 
indeed OSM consider this incomplete and rather sloppy.  The Germans use all 
three (or did).  The Bottom Line for what we in N.A. should do is to use BOTH 
of the "middle-" (#2, route=railway) and #3 "higher-" level (route=train) 
relations to describe "track infrastructure" and "passenger rail routes."  OK, 
thanks for reading all that, it makes a better OSM.

> Looking through map very casually I didn't see any operator=STM on the
> subway. I did see it on a bus line
> https://www.openstreetmap.org/relation/270258 but changing it to
> network=STM and operator=Société de transport de Montréal seems like
> it'd be fine there IMO.

Yes, again, I agree.

> To me "operator" looks a bit more little technical than the other
> tags, so to me it would be alright to use the longer more formal name.
> But I wouldn't edit-war anyone about it. I'd say run a query, see
> which is more common currently, ask people here (as you've done), then
> after a week change the minority tags to match.

You saying "more technical" might be agreeing with me that operator=* is at a 
"lower/middle level" (infrastructure on track, not "higher level" as applied to 
the different relation of route=train for passenger rail).  So I think we are 
largely in agreement:  if you (and Canada) want to move into the direction of 
putting operator=* on freight rail (and maybe sometimes passenger rail), yes, 
that seems correct.  If you additionally want to use the network=* key for, in 
this example, STM, yes, that makes perfect sense to me as well.  So does your 
suggestion/approach of "run a (OT) query...change minority tags to match."

Thank you for good discussion,
SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[OSM Volunteer stevea]

Hello Damien:

I'm "meh, OK" with an operator=STM value, but I freely say I haven't checked in 
completely with whomever you mean by "the minority."  (I "haven't heard of" any 
controversy one way or the other, STM or full-name.  But that isn't saying much 
on my part).  I watch what's up with North American rail and it seems that 
key-value pair is somewhere around the beginning of correct, at least from my 
perspective, fwiw.  Being right on it (there) you are way more on it than I am. 
 I'm sorta like a linguist here.

However, OSM does have a short_name key and I'd be even better with 
short_name=STM or alt_name=STM and operator=Société de transport de Montréal if 
you want to get dotting-of-i and crossing-of-t about it.

I mean, there are wiki pages on loc_name, nat_name, official_name, short_name, 
alt_name and more, it's a slightly rich and deep topic in OSM and in our wiki.  
I say STM is somewhere around alt_name or short_name.  That is one person's 
opinion.  What happens, happens.  I'm a guy typing words right now, so, yeah.

I also I notice when people get my name exactly right, as I appreciate that.  
And look at that, both of us got "Société de transport de Montréal" exactly 
right too (twice), making it a good candidate value for the name=* key.

SteveA
California

> On Jul 10, 2018, at 7:22 PM, Damien Riegel  wrote:
> 
> Hi everyone,
> 
> 
> I'm new to this list so please forgive me if this topic has already been 
> discussed.
> 
> In Montréal, the public transportation provider is the "Societé de transport 
> de Montréal", more commonly known as STM. Some (the minority) nodes use the 
> full name, all the others use the acronym. it would be great to get rid of 
> that discrepancy.
> 
> If I had to give my opinion on the matter, I'd say "STM" is more appropriate 
> as almost everything is branded under the "STM" name (for instance the 
> website is https://stm.info, their Facebook page is called "STM - Mouvement 
> collectif"), so that's the name people use. I think that also explains why 
> "STM" is way more common as operator value than the full name.
> 
> 
> Regards,
> Damien
> ___
> 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

Re: [Talk-ca] A new available source of trail data in the Nanaimo area

[OSM Volunteer stevea]

On May 2, 2018, at 6:17 PM, Doug Hembry  wrote:
> I wanted to bring to the attention of Vancouver Island mappers a source of 
> some trail data in the Nanaimo area...

After some back-and-forth consultation with the provider of the shapefile 
(Lynn, VP of the local horse riders association) regarding tagging 
considerations, I completed an upload after better understanding how these 
(largely equestrian) trails might be conflated with existing OSM data (which 
were pretty sparse, given the rural area).

If you wish to take a look at the area, it is 
https://www.osm.org/#map=16/49.0620/-123.9715 .  "Up now" (as Bill Maher says 
on HBO's Real Time) are what Lynn and I are calling v1, there will be a minor 
v2 update (some permissions and traffic mode tweaks, I may add better parking 
amenities, water sources, etc.) after Lynn answers my last few questions later 
this week.  Currently the trail data are tagged with four traffic modes [atv, 
bicycle, foot, horse], either designated (rare, as so is signage), permissive 
(largely) or yes (public roads or Crown Land, a minority of the curated area).  
There may still be some considerations for snowmobiles, and/or some 
tracktype=gradeX fine-tuning as well as more precise harmonization with the 
Trans Canada Trail, but largely speaking, OSM now has these data, named, with 
length (but not width) and sometimes with surface/tracktype=grade data.

Post upload, I did add some satellite-imagery-visible larger-scale areas like 
large landuse=meadows cleared in the timberland, wetland=swamps (complementing 
CanVec data) and several landuse=quarries, which are rather numerous in the 
area.  All in all, a nice little "beef up" to this part of Vancouver Island in 
OSM.  Makes me want to get on a horse or a mountain bike and get out there!  
(James, there are no "vulgar trail names," some of them are reminiscent of 
comic strip characters!)  A centrally-located (to the curated area) private 
inholding has all of its trails marked access=private, respecting the 
landowner's wishes to diminish trail use by riders who use widely-available 
maps (like OSM).

Lynn's initial reaction to seeing v1 tile was "I was quite pleased."  So except 
for the fine-tuning v2 we'll complete in a few days, Done!

If you live in the area and ride or hike here, you may now "smarten up" your 
phone or GPS with these named trails and very precise geo data.

OSM:  what a great project!

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020 Calgary Challenges and Best Practices

[OSM Volunteer stevea]

Whoops, put a closing quote on the alias (I truncated an apostrophe at the end 
of that line).  And, of course, press return at the end of commands to the 
shell (command line interface).

After this, you can "go get plugins" and configure them as you like.  Now you 
are off and running JOSM on a Mac, I hope.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Formatting of Municipality Names in Ontario

[OSM Volunteer stevea]

Hi Matthew:

You do fine work here, yet I have a concern about "Township."  I don't know if 
in Canada, a Township is a bit of an "odd duck" like it is in the USA.  In the 
USA, we have county as admin_level=6, township as admin_level=7 (in about 
one-third of states) and city/town/village as admin_level=8.  The reason for 7 
has to do with the way that a county might assign "home rule" responsibilities, 
which flow from the state extending its political administration to the 
counties, then a county might push this through to a "township," a crucial 
component being that township jurisdictions can often (but do not always) cover 
the ENTIRE county, rather than a portion of it, like a city does.  It's a 
little complicated, it varies from state to state, in our Midwest Region it 
often has to do with the way that state surveys were done (not the same in our 
New England Region) and OSM doesn't always align with the US Census Bureau's 
methodologies and/or results, (but does most of the time, there are good 
reasons for why OSM has reached the consensus we have in those exceptional 
cases, and we document these in our wikis).

If Canada (its provinces, actually, I believe) has this same or a similar 
concept of "township," (you might, you might not), then admin_level=7 might be 
correct on Canadian "Township of..." boundaries.  If not, I'm blowing a lot of 
smoke into the equation and I'll thank you for reading and apologize for 
wasting time on this thread.

Yes, they are USA-specific, but we have 
https://wiki.osm.org/wiki/United_States_admin_level (prescriptive, 
comprehensive) and 
https://wiki.osm.org/wiki/WikiProject_United_States/Boundaries (descriptive, 
rather more user-friendly/novice-oriented).  You might check these out 
(especially 
https://wiki.osm.org/wiki/WikiProject_United_States/Boundaries#Civil_townships) 
if Canada has "townships" as "potentially completely subdivided county 
entities" and see how we do it here (basically, they are admin_level=7).

Looking at the Canada row in 
https://wiki.osm.org/wiki/Tag:boundary%3Dadministrative and 
https://wiki.osm.org/wiki/WikiProject_Canada#Administrative_Boundaries I don't 
see this, I see that "Townships" are agglomerated together with "cities, 
villages, etc."  If that's correct, again, all of this I'm spouting about 
"Township" can be ignored, as it is effectively another word to describe an 
admin_level=8 entity and you seem to be fine leaving things that way.

Regards,
SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Formatting of Municipality Names (Jarek Piórkowski)

[OSM Volunteer stevea]

> On 2018-02-19 05:08 PM, Jarek Piórkowski wrote:
>> Have you passed by talk-gb? They have a fair amount of "St" names and
>> some authority as to how to do things in OSM.

I haven't, but I shall.  As I say quite a bit (in our wiki, e.g. 
California/Railroads), "it's complicated around here."  THEN, there is what we 
do about that in OSM.  (Our best).

On Feb 19, 2018, at 3:33 PM, Stewart C. Russell  wrote:
> The UK has Bury St Edmunds, Chapel St Leonards, Lytham St Annes, Ottery
> St Mary, St Andrews, St Anne, St Austell, St Blazey, St Columb Major, St
> Helens, St Ives, St Monans and St Neots all as town names in OSM. The
> only two "Saint .*" towns in the whole British Isles' OSM are Saint
> Helier and Saint Peter Port, both in the Channel Islands. Both have
> French influences. And just to thumb its nose at us, nearby Alderney has
> the town of "St Anne". So I don't think they can be a great example.

I do not mean to appear to be "the pot calling the kettle black" (even as I 
sheepishly may).  OSM learns by example, by documenting how we should tag 
(prescriptive) and how we do tag (descriptive), — this isn't always clear or 
spelled out — by research such as you've done and by good dialog like here.

> Near "St. Louis" (Missouri - abbreviated that way in OSM), OSM has the
> towns of "Saint Clair" and "Saint James". In the same area, there's St.
> Charles, St. Peters and East St. Louis (IL). In the St. Louis metro
> area, there are roughly 4500 ways named "St\. Louis.*" and roughly 3500
> ways named "St Louis.*". There are also roughly 3500 ways named "Saint .*"
> 
> So this is not a standard well kept.

And we make our point:  OSM doesn't always follow its own rules.  Crowdsourcing 
can be messy, yet we try to improve day by day.  Thanks to all for getting here!

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Formatting of Municipality Names

[OSM Volunteer stevea]

Thank you, Matthew.  As I said, "slavishly follow rules," no, not necessarily.  
"Understand the issues," yes, through good dialog.  I like what I see here, it 
allows good consensus to emerge, tedious and perhaps even a bit annoying as it 
may be. :-)

SteveA

On Feb 19, 2018, at 2:00 PM, Matthew Darwin  wrote:
> I respectively I contend that it is not all abbreviations in OSM needs to be 
> expanded, not withstanding of the general direction to expand abbreviations 
> in OSM.  It is illogical to change the well used name of a location.
> 
> There is even a wiki page which has been around since 2010 that lists some 
> exceptions to what should be expanded in the UK: 
> https://wiki.openstreetmap.org/wiki/Invalid_Abbreviation_Expansion

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Formatting of Municipality Names in Ontario

[OSM Volunteer stevea]

It's good to see that admin_level tags (always 8?  they might be 7 if township, 
that's a chunky topic...) are there.  What I mean by "cutting room floor 
recycling" includes this thought:  it couldn't hurt to update/touch-up/fix 
these after a cursory examination that's they are thumbs-up/thumbs-down, need a 
touch-up.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Formatting of Municipality Names

[OSM Volunteer stevea]

On Feb 16, 2018, at 7:50 PM, Bill & Kathy Patterson 
 wrote:
> It would seem to me that an official place name should take precedence over 
> OSM protocols.  If we expand the abbreviations (or contractions), of St. and 
> Ste., then are we not altering the official place name of the feature?
> 
> The federal government downloaded that responsibility to the provinces, and 
> in Ontario the official place names appear at
> http://www.gisapplication.lrc.gov.on.ca/Geonames/Index.html?site=Geographic_Names=Geonames=en-US

Bill, as I look at "Sault Ste. Marie" in Ontario in that database and compare 
it to the "Sault Ste Marie" across the water in Michigan (land of my birth, but 
not in the realm of this database's naming) I note something interesting:  the 
Canadian version has a period, denoting an abbreviation (we do use English, 
though the rule that a period is found at the end of an abbreviation in French 
is the same),  The Michigan one does not end in a period.  Were I to edit here, 
I would "follow what our OSM wiki says to put in OSM" expanding that 
abbreviation ("Ste." to "Sainte" in the Ontario version).  Some (many? most?)  
"Sainte-Quelque Chose" names have hyphens, too.  So, hm.

That would be my approach, as it is OSM's approach.  This is OSM, yet it is 
Canada, too, of course.  It's not always easy or clear, is it?

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Formatting of Municipality Names

[OSM Volunteer stevea]

We call it TALK-ca for a reason!  We call it OPENStreetMap for a reason!  
Consensus doesn't always come easy!  Thanks to everyone for good discussion.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Formatting of Municipality Names

[OSM Volunteer stevea]

I stand corrected, thank you everybody.

BTW I do my best not to abbreviate thinks like "DC" for District of Columbia, 
but I now better understand that "St." in many cases has now truly become the 
official name, abbreviation included.

SteveA

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Formatting of Municipality Names

[OSM Volunteer stevea]

We (the USA) has many sources which "say" St. Louis (Missouri) but OSM has 
name=Saint Louis.  The latter is correct in an OSM context.  Following our 
wiki, CAN the name be spelled without an abbreviation?"  If yes, then please do 
so.

Thanks,
SteveA

> On Feb 16, 2018, at 12:50 PM, James <james2...@gmail.com> wrote:
> 
> http://saultstemarie.ca/
> 
> thats how its written. even on signs to there
> 
> On Feb 16, 2018 3:47 PM, "OSM Volunteer stevea" <stevea...@softworkers.com> 
> wrote:
> On Feb 16, 2018, at 9:41 AM, Matthew Darwin <matt...@mdarwin.ca> wrote:
> > St. Catharines, St. Thomas, Sault Ste. Marie
> 
> I dislike sounding nit-picky, this really is meant as constructive criticism, 
> but let's expand these names so there are no abbreviations.  Our wiki 
> https://wiki.osm.org/wiki/Names says "If the name can be spelled without an 
> abbreviation, then don't abbreviate it."
> 
> Thanks,
> SteveA
> ___
> 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

Re: [Talk-ca] Formatting of Municipality Names

[OSM Volunteer stevea]

On Feb 12, 2018, at 6:02 PM, Bernie Connors  wrote:
> I see the use of "City of" as indicating the official name of a municipality 
> as it is defined in legislation. Here in New Brunswick the Municipalities 
> Act‎ defines the official names of municipalities. Some opt to use "City of 
> ", "Town of ", etc in the Municipalities Act and some don't. But when it 
> comes to names on maps we should be more concerned with toponyms and not 
> official names. The use of "City of ", "Town of ", etc is very rare in 
> toponyms.  Here is a query on the Canadian Geographic Names Database 
> searching for the term "of" in the "populated places" category - 
> http://www4.rncan.gc.ca/search-place-names/search?q=of%5B%5D=985=O
> 
> I only see two examples that include "City of ", "Town of ", etc across the 
> entire country:
> City of Brant, ON
> Village of Queen Charlotte, BC

Excellent, Bernie:  I love the word toponym, it is a good one for a talk forum 
about OSM.  Thank you for those elucidations.  I am from outside Canada, though 
the CGND seems an authoritative source here and we do have others chiming in as 
I type.

+1, I agree that toponym is an excellent starting point for the value of the 
name=* key.  City of Brant and Village of Queen Charlotte might have those in 
official_name but check taginfo and dig into this further with more discussion. 
 Discussion is good.

What I meant by "I smell admin_level harmonization" is that as this discussion 
continues about deleting "Township of" and "Village of" data (and similar) that 
better admin_level tagging might result.  A sort of (trade off?) of "well, 
let's capture the data we consider deleting by adding them into OSM using OSM 
methods."

This isn't required, more like a "recycle the scraps on the cutting room floor 
into nice, correct data."  I do that where I can, certainly not always!  Great 
discussion.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Formatting of Municipality Names

[OSM Volunteer stevea]

> i believe "city of" is redundant as its a classification vs a name.
> Would we say "village of maniwaki"? nope. 

What "we say" and what "OSM tags" can vary slightly.  Although with names, 
"what we say" is a great place to start and very largely correct.  This is a 
topic which can explode quickly, smearing into many linguistic zones.  We 
define an official_name value at https://wiki.osm.org/wiki/Key:name and 
short_name and loc_name can get in on the act in some cases.

There are places and circumstances where preceding a city's name with "City of" 
is "a very correct answer."  So, sort that out, if we would, please.

We (California) have a city which nearly everybody in all circumstances calls 
Ventura which is "officially" San Buenaventura.  Stuff like this happens.  
Then, there might be a "linguistic register" (like in a legal pleading) where 
"The City of San Buenaventura" is "just what the doctor ordered" acceptably 
correct.

It appears that "City of Toronto" being roughly 91% of a six-figure-strong 
consensus is a clear winner.  However, Kevin Farrugia says something different. 
 We listen, we consider, we allow consensus to emerge and the bold pull 
triggers.  By that I mean "clean up what we now agree needs correcting."

OSM is so delightfully human and organic.  I'm so glad we so widely speak 
amongst ourselves.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020i and Mapathons with High Schools

[OSM Volunteer stevea]

I'd love to see in OSM (with a nod by STATCAN?) a Canadian "model building" 
(one will do), linked in the wiki.  Richly-tagged and well done, to provide a 
standard to shoot for.  To close a small, tight QA loop, as it were.  "Here is 
what we'd like to see more of."  Start small, document it.  That seems a fairly 
low bar to step over.

Later,
SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020i OSM Distributed Model and Education

[OSM Volunteer stevea]

Please see https://wiki.osm.org/wiki/Key:level

SteveA

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020i OSM Distributed Model and Education

[OSM Volunteer stevea]

I repeat myself:  less buzzword-compliance, please.  More embracing of 
tried-and-true OSM tenets and culture, like front-loaded planning, ongoing, 
wide-area project management on something with nationwide scope as this, wiki 
writing/updating both intent and ongoing status, making available short video 
clip "flight plans" (OSM curriculum specific to entering building data) to 
explain process to various audiences in Canada  You have Ottawa as a "good 
acorn," clone what was learned there into the wiki (better than now) and target 
other cities and audiences to harmonize with slow-yet-steady OSM-style growth.  
That is how this turns into "mighty oaks."

I met Clifford in Seattle two summers ago, he presented some excellent OSM 
community-building strategies at SOTM-US, I had a contract with Telenav for a 
while, I know maps.me, and I watched Philly Fresh Food turn into rather 
impressive results, as it was well-planned and was ready to receive beneficial 
and unexpected synergies.  (That didn't happen because somebody said "synergy," 
by the way).  I've been around the OSM block and I'm obviously passionate about 
it yielding awesome results.  But only when some awesome happens up-front.  
Otherwise (and I've both seen it and cleaned it up), it gets messy, and fast.

Yes, gathering "how" intelligence from existing projects is smart.  Yes, 
learning that concerns like liability and a PERCEIVED "lack of control" in an 
open, public, crowdsourced database like OSM can pose problems, but only if you 
push through these perceptions with an understanding of previous pitfalls, and 
the commensurate good planning and active management which can and do avoid 
these.  With both, you can address not only these (perceived) issues, "you" 
(and who is that?) can "drive" the project virtually anyplace desired, provided 
it sticks to OSM's good tenets and keeps the finish line in sight while hewing 
to good bounds to get there.  This project does better at that now, I think it 
will continue to do so.  It seriously needs a flight crew, steering committee, 
whatever you wish to call it.  While those specific individual human beings 
might be in a government bureaucracy (or, they might not), they MUST (I repeat, 
MUST) be steeped in culture and methods of OSM.  Knowledge of ArcGIS or other 
GIS/cartography experience is fine, knowledge of other sorts of crowdsourcing 
can help, yet the way that things are well-built and work in OSM is unique to 
OSM.  Embrace that, and fly.  Don't, or put too much emphasis on "the way we've 
always done things here" and you create more difficulties.

It is getting better.  (As my tone hews closer to honey than vinegar, it will 
get better).  Again, I've said it and said it and said it.  So please:  do it.  
The good intentions to do so are clearly there, that is a terrific place to be 
to continue onto the next steps.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020i OSM Distributed Model and Education

[OSM Volunteer stevea]

On Jan 30, 2018, at 7:49 AM, Jonathan Brown  wrote:
> I don’t mind reviewing the OSM education wiki for lessons learned and 
> “promising practices” and seeing how it might inform the design of a mapathon 
> event aligned to the K-12 curricula and postsecondary capstone project model. 
> It will be messy, but that’s the nature of the beast. To use the jargon, 
> start small, fail fast and apply what you learn to the next event.

With all due respect to you, Johnathan, I don't know where you got that jargon, 
but it does not apply to OSM:  our worldwide mapping project is not a "dumping 
ground" to "fail fast" where poor quality data are entered and then corrected 
as a nationwide project finds its footing, lurching forward to apply newly 
discovered corrections to its past mistakes.  No, it must plan first.  Pilots 
file flight plans, and they stay in contact with control towers with status and 
progress reports.  A nationwide OSM project is no different if all passengers 
are expected to land safely, especially on a long flight!

Sure, mistakes happen and we learn from them, course-correcting along the way, 
that's simply human nature.  But as I have been exhorting for months, what will 
MAKE BC2020 a successful OSM project is this:  good planning NOW and project 
management along the way.  BOTH must be front-loaded into the nationwide OSM 
project that BC2020 is, not bolted on later as an afterthought.

> Jamie Boyd and Moses Iziomon at the Treasury Board’s Open Government branch 
> may have some funding to support Alessandro’s group in helping to engage the 
> OSM “crowdmappers” and citizen science practitioners. This could align to 
> their 2 year open government plan 
> http://open.canada.ca/en/4plan/creating-canadas-4th-plan-open-government-2018-20.
>  They are looking for workshop ideas for early May.

If TB has funding, ask them to seek and pay for expertise in nationwide-scope 
OSM project management experience:  good planning, harmonizing vision/goals of 
BC2020 with the culture of OSM to be "OSM first" (it is), writing wiki, 
assuring that mapathons, meetups, university and K-12 events have structure, 
direction and a solid plan FIRST before entering vast building data.  Too many 
large-scale OSM projects fail due to poor planning, a lack of standardization 
as to what and how goals are to be achieved and hence suffer poor results.  The 
method by which this gets solved is with up-front planning, that means NOW or 
very soon.  Crowdsourcing is not a magic bullet that yields great results for 
free or without planning.  There are costs involved:  thought, discussion, 
consensus, documentation and those take time and effort.

BC2020 has had a recent "reality check" that is it more than BC2020i (the 
initiative), it is now a full-fledged BC2020 WikiProject (without the i, as an 
OSM project).  That means wikis, import plans, documenting the process that 
each city/event might and should take, etc. get adhered to and followed.  To 
keep this communication in the dark and out of a wider OSM view essentially 
dooms this project to failure.  Please:  plan now for superior data later.  It 
has gotten better in the last week or two, but the "messy nature of the beast" 
approach noted above is not acceptable to the greater OSM community.  Both wiki 
and talk-ca are important venues for this dialog, private email exchanges can 
supplement it, but a nationwide project deserves a nationwide discussion that 
is front-loaded and transparent, not (exclusively) "fail fast."  In fact, OSM 
insists upon this.

Please install pilots in your large, jet aircraft.  If it is to fly and land at 
its destination (years into the future), it not only deserves, it simply must 
have an experienced flight crew.

With respect to you, all OSM volunteers in Canada, and indeed the OSM community 
at large,
SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Preferred phone number format

[OSM Volunteer stevea]

>   • There are additionally ~45 phone numbers that use letters instead of 
> digits (eg 1-555-GOT-BEER)
>   • ";" separator is used occasionally to indicate multiple phone 
> numbers.  " ", "," and "/" are also used.
>   • There are random comments in the phone number field (not sure where 
> these really should be?)
>   • Extensions are represented generally by "x" or "ext" or "ext."
>   • There are less than 1000 phone numbers using contact:phone instead of 
> phone, using ~40 unique formats
>   • I did not analyze phone_1 or fax or any other tags.
> I will continue to cleanup phone numbers across the country which are missing 
> the leading +1 and or are not one of the 4 common formats listed above.  My 
> thought is that 
>   • I will leave the phone numbers of 1-555-GOT-BEER type.  
>   • I will use ";" as multiple number separator.  
>   • I will use "x" for extension. 
>   • And I will be happy to cleanup the wonky ones with lots of text in 
> them if there is a direction of where this should move to.  Example for a 
> radio station: "office (###) ###-; on-air studio (###) ###-"
> 
> Feedback welcome.

Those sound largely sane and well thought out to me.  (And I wrote phone number 
parsers for the NANP about 30 years ago, um — wait for it — in HyperTalk!)  The 
GOT-BEER style are best left alone (imo) as smarter parsers eventually figure 
those out.  Yes, ; (semicolon) is a frequent separator in key:value pair value 
lists in OSM data.  Yes, x (choose a case, lower seems better and more common 
than upper) for extensions.  For the radio station/on-air studio stuff I'd make 
the first part of each of these "compound data" be the phone number in one of 
the acceptable formats along with other data, then have extra descriptive text 
added to the rest, even if in a semicolon-separated list.  That's a pretty 
regular set of alphanumerics and with maybe a eight or ten rules, (reasonable 
for a parser extracting machine-dialble phone numbers, if necessary), you're 
either done or at or above 99%, I'd be willing to wager (and I'm not a betting 
type, though I do play poker with friends and online).

Nice job.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] using image recognition to create building foot prints.

[OSM Volunteer stevea]

On Jan 29, 2018, at 2:35 PM, Stewart C. Russell <scr...@gmail.com> wrote:
> On 2018-01-29 04:37 PM, OSM Volunteer stevea wrote:
>> 
>> OSM is delighted to receive building data in Canada, truly we are.
>> (Provided they are high-quality data).  I have heard the process of
>> entering data into OSM, especially "bulk import" OD (which must match
>> license compatibility against OSM's license, our ODbL) described as
>> "inside baseball."  It is not.
> 
> If you're gonna quote me, at least try to understand me, please.

Stewart, I apologize if I misquoted you or took it out of context, that was not 
my intention.

> The open data / OSM dialogue in Canada has been going something like
> this, ever since I started working with municipal groups in 2011 or so:
> 
> Municipal data advocate: Please use our data! It's under an open
>   licence!
> 
> OSM volunteer: But our licences aren't compatible!
> 
> Municipal data advocate: But it's an open licence! Our lawyers say
>   you'll be fine!
> 
> OSM volunteer: But we need … (starts to reel off list of additional
>   supporting docs)
> 
> Municipal data advocate: Companies like Google and Nokia use our data
>   with no problem. Use our data! We are giving it to you!
>   Don't complain!
> 
> OSM volunteer: but but the licence …
> 
> (Municipal data advocate storms off in search of a someone more likely
> to give them corporate recognition.)
> 
> Some very tenacious OSM people and some very adaptable government people
> have made things work in a few places in Canada.

I both salute these efforts and bow deeply in obeisance at the good work done 
here by them.  These are the important seeds of the future, the acorns from 
which mighty oaks shall grow.  Yes, it will take time, effort, coordination, 
management and documentation.

Simply put, (and I don't wish to be rude), "municipal data advocates" cannot 
assume that OSM is a "free ride," without some front-loaded effort at planning 
and further project guidance along the way.  We have our culture and methods in 
OSM, and that's the way it is.  I am hopeful, as inter-community cooperation is 
something Canada has been and is quite good at doing for its entire history.

> Only when we have a way
> forward on data licensing, then BC2020 would be an OSM project.

I respectfully disagree.  Yes, "ways forward on data licensing" is vitally 
important, as it is a major obstacle.  However, BC2020, and the way that it has 
morphed into becoming by its very nature using OSM as a repository of data, IS 
an OSM project.  Therefore, it must hew to OSM tenets, like transparency, good 
communication, wiki updates, and in a project of scope this wide, sane and 
steady planning and project management.

You can say that license compatibility is "slow going" (and you'd be right) but 
OSM is "up to" three cities (from one, Ottawa).  Rome wasn't built in a day and 
Canada's building data won't be entered into OSM in a day, either.  HOWEVER, as 
they are being entered now, some "manually," some (few) via OD licence, and 
some as simple improvements ("Hey, I'm going to tag this a café because I'm a 
local OSM user and I know it is one!"), these efforts MUST BE coordinated (or 
managed, I keep saying, though I'm not particularly enamored of the word as it 
seems non-OSM, yet on national-scope projects, something like "management" 
really is required, even if it is "loose but effective coordination").

Building data being entered into OSM do not have to be part of BC2020i, what is 
now WikiProject BC2020:  if I simply tag a building polygon amenity=cafe, I 
don't become part of a coordinated effort.  However, to the extent they strive 
to be part of the coordinated effort to enter nationwide building data, 
following the guidelines in our wiki of what we mean by acceptable-quality 
data, with acceptable tags, they really, really should.  Such coordination 
benefits everybody, and at minor "cost" (follow some nationwide guidelines, 
stay communicative with your status...).  Is that so difficult a point upon 
which to agree?

Thank you for continuing good dialog,
SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] using image recognition to create building foot prints.

[OSM Volunteer stevea]

Um, "dyed-in-the-wool."
Steve

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] using image recognition to create building foot prints.

[OSM Volunteer stevea]

On Jan 29, 2018, at 12:15 PM, john whelan  wrote:
> ·NRCan is working on a methodology to extract building footprints, 
> including topographic elevation and height attributes, from LiDAR
> Traditionally OSM has not been happy with this sort of thing.  The accuracy 
> can be poor.

I find it troublesome that John should even have to explain this to a single 
person on this list.  However, maybe some here don't know this, so "OK."

Warning:  lukewarm screed ahead.

I say this with all politeness intended:  OpenStreetMap is not a dumping 
grounds for data which are open (OD) nor experimental from AI/machine learning 
results, then there is some vague and hand-waving future process which may or 
may not come along in the future and "fix them to meet OSM's quality standards."

OSM is delighted to receive building data in Canada, truly we are.  (Provided 
they are high-quality data).  I have heard the process of entering data into 
OSM, especially "bulk import" OD (which must match license compatibility 
against OSM's license, our ODbL) described as "inside baseball."  It is not.  
Every single person reading this list is either an OSM volunteer like me, or 
has an interest in OSM.  (Signing up for this mailing list is my evidence for 
saying that).  That means fully treating OSM as the "host project" for these 
data, simply put, because it is.  Acting as if OSM is simply an airplane 
expected to fly, without following a flight plan nor contacting a control tower 
will get this project grounded, as OSM volunteers like me declare an emergency, 
seeing nobody in the pilot's seat, while all the passengers expect a free ride 
to their own distinct destinations.  That simply "doesn't fly."

Recently, many of us have become more aware of the history of StatsCan wanting 
to introduce building data to crowdsourcing and coming up with BC2020i (the i 
for "initiative").  Left quite unspoken was that "crowdsourcing building data 
from StatsCan" silently became "put building data into OSM."  While there was 
traction to do this in 2016, many meetings, a fair amount of data entry and the 
beginnings of more established OSM-style process (writing a wiki or two, 
efforts to harmonize local OD licenses with ODbL...) in 2017, this "initiative" 
has now fully morphed into an OSM WikiProject, BC2020.  This has its own wiki 
(https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Building_Canada_2020 
being re-written now) and is getting on a better footing by discussing the huge 
number of moving parts both there and here in talk-ca.  But, in my opinion, the 
project remains badly unfocused (slowly, it gets better).

Building data in Canada entering OSM, whether by "manual" methods (e.g. tracing 
a Bing layer) or by "bulk import" from licenced OD is ongoing.  However, it 
absolutely must hew to the tenets of OSM:  good, wide-area coordination and 
communication, consensus, following the guidelines written into an Import Plan 
(if bulk importation of OD data happens) and keeping others informed of status 
(licence approvals, how far along manual methods are via the Task Manager...).  
This is NOT "inside baseball."  It is OSM, plain and simple, through and 
through — this is because BC2020 is an OSM project.  In my opinion (and if it 
isn't clear by now), this project suffers from a serious lack of Project 
Management.  I do not wish to chide, rather to encourage.

As OSM is "hosting" BC2020, I'd like to see more "cultural sensitivity" towards 
what OSM absolutely MUST DO on national-level projects:

• we document our intentions with a well-written wiki (due to history, 
what we have was poorly done, though it is improving),
• we publish Import Plans PER IMPORT (whether municipality, province or 
whatever),  Ottawa's was good, others must grow from this,
• we inform wider community (Canadian and worldwide OSM) with status, 
including licence and data entry progress, whether via Task Manager or 
otherwise,
• especially in early stages (and we are here now), we guide and steer 
the project towards achievable goals and realistic timeframes, doing so 
applying knowledge gained from previous (especially national-level or very wide 
scope) OSM projects.

This is not an exhaustive list.

Please, for months I've been cajoling, back-channel-communicating, 
wiki-improving and friend-making my way (OUR way) towards a simple 
understanding (and declaration?) by all involved in BC2020 that it is an OSM 
project, that it must hew closely to OSM tenets and that that is not "inside 
baseball."  OSM is simply the methods by which these Canadian building data 
find a home.  I'd like to see "local stovepipes" of sub-project data entry 
efforts and no- or little-communication turn into talk-ca threads and new wiki 
sections in our wiki, so this project becomes much more transparent and 
wide-area.  I'd especially like to see someone or some group (call it a 
"steering committee") step 

Re: [Talk-ca] BC2020 OD_tables wiki and project status

[OSM Volunteer stevea]

OK, I've redacted Halifax changes.  From four to three (municipalities with 
license now "green.")
Steve

> On Jan 28, 2018, at 7:39 PM, Stewart C. Russell <scr...@gmail.com> wrote:
> 
> On 2018-01-28 09:16 PM, OSM Volunteer stevea wrote:
>> Halifax also looks like it grants explicit permission.
> 
> still needs an approved import procedure and approaching LWG for
> approval - so it's not good to go by any means
> 
> ___
> 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

Re: [Talk-ca] BC2020 OD_tables wiki and project status

[OSM Volunteer stevea]

Halifax also looks like it grants explicit permission.  Cautiously, I change 
Halifax to green (and remove strikeout type in Contributors), as I don't think 
we need LWG to "offer benediction" when the owner of the data grants explicit 
permission, as this link appears to do.  If I'm wrong about that, please 
revert.  If I'm correct and you know it or also feel this is true (I've done 
similar things in the USA with explicit permission, as from our AASHTO on 
national routes) then please remove "ARE WE SURE?" on the Contributors page.  
Thank you.

Up to four municipalities, now.  Thanks to great teamwork for a productive 
weekend, everybody.  See you around.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020 project

[OSM Volunteer stevea]

And...you're off and running (better and better).

This is a process, everybody.  Nobody wants to be slapping anybody around.  I 
like the way we've been polite and patient with each other here.

Regards,
SteveA

> On Jan 28, 2018, at 4:47 PM, Matthew Darwin  wrote:
> 
> Inline
> On 2018-01-28 07:38 PM, john whelan wrote:
>> We have lots of people talking about this.
> 
> Yay!
> 
>> We have a wiki page somewhere that covers some ground.  Could someone remind 
>> me of the address?
> 
> https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Building_Canada_2020
> 
> needs lots of improvements.  I started.  I see Steve A did a bunch as well.
> 
>> 
>> Do we have anyone willing to project manage this? It is a very big project 
>> with lots of aspects and complications to it.
> 
> I have not heard of any. I am willing to help some, but it really needs to be 
> a full-time person (or bunch of people to make it to full time).
> 
>> 
>> Do we have a list of attributes that should be added to buildings?  If they 
>> aren't on the wiki then I think they should be.
> 
> https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Building_Canada_2020#The_data_being_mapped
> 
> Although I think the list is impractical... how to get all the attributes 
> listed?
> 
>> I am aware of public wif, levels, use ie commercial, residential.   There 
>> are some tiles set up somewhere for mapping and validation.
>> 
>> Could we have a pointer to them please if they aren't on the wiki already.
>> 
>> We have interest from schools and universities do we have any material that 
>> could be used for them?  
>> 
>> Do we have a "hello to help with this project please use Bing imagery with 
>> JOSM building_tool plugin on the following tiles.  If you use iD please be 
>> very careful and map the building outlines exactly."
>> 
>> and "this is how you add a tag?"
>> 
> Needs to be added.  The folks doing Ottawa buildings recently probably have 
> the best experiences to provide guidence to newbies.  Also probably should be 
> a template for the tasking manager to point at.  (For all the building 
> related tasks).
> 
> If the Ottawa/Gatineau experience teaches us anything, I suspect that doing 
> buildings is going to be a multi-step process per 
> municipality/region/province.   Import stuff, manually map stuff, add more 
> tags, whatever...  ie going from zero buildings to "perfect" buildings in one 
> shot is not reasonable.
> 
> 
> ___
> 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

Re: [Talk-ca] BC2020 OD_tables wiki and project status

[OSM Volunteer stevea]

Smiling here, thank you for wiki-ing fresher status in both wikis!  (It's quite 
doable, yes?).
Steve

> On Jan 28, 2018, at 3:40 PM, Matthew Darwin  wrote:
> Great, seems like we have a list of 3 ok ones: 
> Ottawa (approved license)
> Gatineau + Montreal (explicit approval provided)


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020 OD_tables wiki and project status

[OSM Volunteer stevea]

On Jan 28, 2018, at 2:39 PM, James  wrote:
> CC Attribution is compatible with explicit permission, so Gatineau and 
> Montreal may remain on the list.

Oh, how I sometimes dislike the word "may!"

I know, I know, our good talk-ca dialog intends to help wider understanding and 
consensus.  This can be challenging, lengthy, repeat-oriented / loquacious and 
seem like it runs in circles!  It gets better.

James, I hereby ask you to change status from red to green once you know.  
Perhaps also undo the strikeout type (delete the  brackets in the markup 
language) in Contributors for those two cities, too (updating the one or two 
lines of text it takes to do that).  That goes for anybody posting here and/or 
reading this.

To all, wiki what you know, please!  Though, sometimes, conversations here, or 
in email, or "in the map" or... are more appropriate.

I'm saying "wiki when wiki is right."

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020 OD_tables wiki and project status

[OSM Volunteer stevea]

On Jan 28, 2018, at 1:27 PM, Matthew Darwin  wrote:
> Steve A,
> I suspect nobody fully knows the current status of licences... So I would 
> agree with the action that you wrote:
> every city except for Ottawa rightfully should be removed to end the 
> confusion, updating both wikis.  

OK, now done.

In Contributors, following the existing example of Toronto, I have used 
strikeout type.  To be clear, I ONLY did this for eight of the ten "Canadian 
Municipalities" listed there, leaving Ottawa in plain type indicating "Contains 
information licensed under the Open Government Licence – City of Ottawa." and 
its embedded link.  (I left Yellowknife yellow, it is 100% done, that may or 
may not be the correct color, it might be red).  I did NOT change Canadian 
Provinces (of which British Columbia is the only one listed) nor Natural 
Resources Canada.  Whew.

PLEASE, I ask others to double- or triple- or multiple-check me here!  Do these 
(local licenses in Canada) reflect the current state of reality?  We (here in 
talk-ca) believe they do, we (OSM) welcome any updates directly to the 
Contributors wiki.  Thank you.

In the BC2020 OD wiki, they are all red except for Ottawa, which remains green 
and Yellowknife which remains yellow as it is 100% done, though it may be 
conflation for me to be thinking that way and perhaps it goes red, meaning, 
license not approved.  Hm, Yellowknife to red but left as done, both true 
apparently.  Uh

This does lead to (at least me asking) "hm, how did 80% done get into Edmonton 
and Yellowknife 100%, I'll leave that alone for now.  (I'm guessing "via Bing 
or other visual layer, and JOSM and maybe a plug-in and a toolchain and so 
on...).  Two separate issues:  local licenses and "how much is done anyway."  
I'm putting pieces together, disassembling stovepipes, as it were.  A wider 
(than Canada) OSM community does better understand some status via our wiki.

It is likely that we simply need a total run-through of what is everybody's 
understanding up and down our wiki, toolchains, processes, lines of 
communication, etc.  A sort of thing that is done on a talk page and via wikis. 
 It appears to be a national conversation.

Steady ahead.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] BC2020 perspectives

[OSM Volunteer stevea]

I see so many simultaneous (some unconfused, some confused) efforts in OSM's 
WikiProject BC2020.  Here, I identify what I see from an out-of-Canada yet 
long-time OSM contributor perspective.  While the following must necessarily 
remain high-level, I do not wish to over-simplify, though it can be difficult 
to make that combination work well.

1)  Canada wishes to deploy "citizen science" and/or "civic science" (civic 
data, it seems) in crowdsourcing efforts.  (Personally, I seriously applaud 
these efforts, especially as they are at the mighty level of "nationwide").

2)  OSM aligns especially well with these efforts.

3)  There are real-world issues that frustrate these efforts, primarily the 
importation of OD as it is now licensed (except in Ottawa) not harmonizing well 
with OSM's ODbL.  This arises because each city and/or province does something 
slightly different, though there are minor alignments in some cases.  The 
result is that each of these changes triggers a lengthy and difficult legal 
process to determine compliance, and legal resource within OSM (our LWG) are 
limited.  In this context, the best use of these resources is a "once per 
country" approach, and while that happened with Ottawa, making its OD ODbL 
compliant, other cities haven't adopted Ottawa's license.  Otherwise the 
(literally) provincial (and local) approaches going their own way SERIOUSLY 
frustrate the "must sail exactly to the tack" specific efforts of BC2020, a 
straight-up OSM project.

4)  OSM has many internal communication methodologies, from "the map itself" 
(changeset comments, Notes, source and attribution tags...), to our help forum 
(help.osm.org), to our talk pages (at national, technical and other specific 
levels of target audiences), to our wiki pages.  Each have their purposes, and 
understanding the differences in how these (and more) are used is part of OSM's 
culture.  There are also "out-of-band" communications (private email 
conversations, IRC, slack, Google, MeetUps, Mapping Parties, "talk over 
coffee," academic institutions using OSM in education as efforts part-parallel 
to BC2020, part not...).  While none of these are "secret," some are 
deliberately and correctly "smaller and more private," appropriately not shared 
with a wider OSM audience.  ALSO, there are others (e.g. government workers in 
StatsCan and other bureaus...) who wish to see OD and "civic science" progress, 
perhaps with OSM a star player, yet are neither privy to the "more private" 
conversations nor are culturally indoctrinated in "methods of getting things 
done in OSM, especially on a national level."  Of course, there is some overlap 
by some who have contributed mightily to the conversation here, helping to 
elucidate both history and valuable perspectives of their own.

5)  Real decision making "power" so that BC2020 may progress, and I mean in OSM 
(as it IS an OSM project), must understand these perspectives even as they 
bring still more additional perspectives of their own to the table.  There must 
be a mingling of cultural perspectives:  government OD attitudes and OSM 
sub-culture.

Once 5) happens, and perhaps tomorrow's event where Jonathan Brown "raises this 
licensing issue" is a new sort of kickstart, this must become a nationwide 
feedback loop.  The CRITICAL juncture to move forward is a harmonization of 
local/provincial/federal governments and their attitudes and culture towards 
Open Data with the culture of OSM.  We have made great progress, but in my 
opinion, only in limited contexts and suffering from "stove-piped" 
communication blockages.  This deeply frustrates further progress.

Please observe all of the moving parts, (perhaps marvel a bit!) and know that 
while boulders can be pushed uphill, it isn't easy.  I wish to continue to 
offer encouragement that it can be done.  I hope this helps.

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020 OD_tables wiki and project status

[OSM Volunteer stevea]

On Jan 28, 2018, at 11:29 AM, john whelan  wrote:
> 
> If you map from Bing imagery there is no issue.  If you do map from Bing 
> please use the building_tool plugin in JOSM.  We tend to find new mappers 
> using iD are not very accurate.


Thanks, John, that's a helpful history lesson.  I've been looking at the 
history of our Contributor page to see who edited these Canadian cities "into 
compliance" and it is a mixed bag of "me, too" additions.  Try:

https://wiki.openstreetmap.org/w/index.php?title=Contributors==500=history

and do a web page text search for "Canad" and you'll get a sense of this.

However, while history lessons can shed light, the task at hand is to update 
status for today, now, amongst a wide national (and international, 
OSM-worldwide) audience.  So, let's continue to do that and pursue the truth of 
Canadian OD licensing status.  Yes, it's clear that mapping from Bing (please 
use JOSM + building_tool plugin — and where is the wiki to document efforts on 
how OSM volunteers do THAT?) is a slightly different set of tasks than that 
outlined in BC2020, as IT talks about bulk importing a lot, and doesn't seem to 
talk about Bing and JOSM + building_tool plugin efforts.

I'll say it again:  the Contributors wiki (and concomitantly, the BC2020 
OD_tables wiki) need to be updated to "current reality," whatever that is.  I 
don't know what that is, maybe nobody does.  If nobody does, every city except 
for Ottawa rightfully should be removed to end the confusion, updating both 
wikis.

Finally, the BC2020 wiki itself (not OD_tables) needs to be refreshed by 
somebody other than me to reflect what is REALLY going on in this project 
nationwide in Canada, right now.  Please!

We seem to be getting somewhere, even if it is determining that "efforts remain 
unconfused and confused on a national level."  I'll take that as minor progress 
— because it can be cleaned up and remedied!

Thank you to all for measured, patient and polite conversations both here in 
talk-ca and in our wikis,
SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020 OD_tables wiki and project status

[OSM Volunteer stevea]

On Jan 28, 2018, at 10:50 AM, Jonathan Brown  wrote:
> If we have a description of the scope of the work involved in updating the 
> BC2020 OD tables, I don’t mind trying to find some senior students who could 
> be trained to take on this task for locations in Ontario. It would be a very 
> small start, of course. Also, can someone explain to me the licensing issue? 
> How do datasets released under the open government license not meet the legal 
> requirements of the OSM license?

Then, On Jan 28, 2018, at 10:57 AM, James  wrote:
> license is federal, cities must modify it to apply to municipal, thus 
> creating new license

SO, please ladies and gentleman, "figure out" what your licensing status is, 
and document it.  First in 
https://wiki.osm.org/wiki/Contributors#Canadian_Municipalities where it is now 
said these entries are incorrect (except for Ottawa).  Second in 
https://wiki.osm.org/wiki/WikiProject_Canada/Building_Canada_2020/building_OD_tables,
 which now refers back to that page in all the "green" cells.

This is what OSM (partly) is:  documenting in a wiki (for all to see and share 
in the knowledge of) the status of licensing, a link to an Import Plan, helpful 
steps to take when you get stuck and don't know what to do, a place to propose 
streamlined or improved methodology, a way to capture the status of a project 
(whether with or without Task Manager links) perhaps using red/yellow/green 
color-coded cells, or cells that have "80% done" in them, as appropriate, et 
cetera.

The "scope of the work involved in updating the BC2020 OD tables" is not hard, 
it is this:

1)  View OD_tables wiki (the second link above)
2)  Click the Log In link (upper right) and enter your OSM wiki credentials 
(different than your OSM credentials)
3)  Click the Edit Source link (ditto), I don't recommend the 
usually-more-friendly-user-interface Edit link, as you are editing TABLES here, 
and (in my opinion) our wiki's raw (lightweight, relatively easy) markup 
language is the only sane choice here to edit table data entries
4)  Edit the table data for each cell which is now green (yes), but which 
should be red (no) or perhaps something in the middle, yellow (partial).  There 
are 11 colored cells now, 7 are green, 4 are yellow.  It seems 1 should be 
green (Ottawa) and therefore left alone, but the other ten should be changed to 
red or yellow.  So, GO!

OTHERS reading this list (not me!) must properly decide what these 
colors/statuses are, as I'm merely some guy in the USA who wants to see the 
project go forward, but the licenses, and importantly, their statuses as 
communicated to the rest of OSM via the Contributors page and the WikiProject 
BC2020 OD tables page are now confused/outdated/wrong and so these must be 
updated so they are correct for 2018, now and going forward.

> I offer to "change from green to red" wiki table status for all cities 
> (except Ottawa), although I'd also like to see Contributors be updated (with 
> only Ottawa) as I suggest.  Teamwork, anybody?  Simply to keep our 
> project-wide communication current?  It's neither difficult nor 
> time-consuming and shares present status with "the rest of us."

And my offer still stands, I just have no clue what is going on with these 
licenses.  Does anybody here?  Please, let's not kick this into "well, it's 
sorta lost in the LWG..." unless that is REALLY true.  It seems this is a 
Canadian initiative to move forward with these and I'm left with little to do 
from here to push it forward any differently than I have been.

Thank you,
SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020 OD_tables wiki and project status

[OSM Volunteer stevea]

On Jan 26, 2018, at 8:12 PM, Stewart C. Russell <scr...@gmail.com> wrote:
> On 2018-01-26 09:56 PM, OSM Volunteer stevea wrote:
>> What I did was to "back-populate" the list of "approved" (by whom?  when?  
>> how did these get here?) list of Canadian cities from
>> https://wiki.osm.org/wiki/Contributors#Canadian_Municipalities into OSM's 
>> BC2020 wiki.
> 
> These are very old and pre-date the formal import documentation process.
> The Toronto permission e-mail from 2011 or so amounted to not much more
> than “Sure ;-)” [smiley included in original]. I don't think the process
> would pass muster now.

OK, so "correct" is to immediately remove from 
https://wiki.osm.org/wiki/Contributors#Canadian_Municipalities EVERY SINGLE 
CITY (except Ottawa).  If it was an error to list them then, (that's what I 
read above) it is an error to list them now.  Anyone with an OSM wiki account 
can do this — and now, someone should, preferably someone in Canada with a 
sense of ownership that this process of entering additional Canadian cities 
into Contributors went awry.  This could be a majority of people reading this 
post:  any takers?

> Unfortunately, none of us are lawyers, the OSMF's lawyers are very busy
> and naturally conservative, and slogging through licence work (and
> myriad outdated wiki pages) is no fun for anyone, least of all volunteers.

Some of us are lawyers (I'm not), though any OSM volunteer should strive to "do 
the right things," especially in matters related to "proper licensing."  Proper 
OD licensing is one task which has emerged as an "obstacle" (so documented in 
WikiProject BC2020) from the desire to see continuing project forward momentum.

To go forward, if wiki pages are outdated (and Stewart says above that they 
are), well, please update outdated wiki pages.  You don't have to be a lawyer 
to do that, especially as the data are known to be outdated or wrong.  
"Slogging through license work," partly DOES require being a lawyer (at least 
within OSM's LWG) and for the project to go forward, yes, that is a longer-term 
task to complete.  (I hesitate to say "slog," though it may be one).

I offer to "change from green to red" wiki table status for all cities (except 
Ottawa), although I'd also like to see Contributors be updated (with only 
Ottawa) as I suggest.  Teamwork, anybody?  Simply to keep our project-wide 
communication current?  It's neither difficult nor time-consuming and shares 
present status with "the rest of us."

We may not have brilliant ignition here, but at least the embers are orange and 
warm.  Though, after many lungfuls by me, I'm getting a bit dizzy stoking these 
fires.

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020 OD_tables wiki and project status

[OSM Volunteer stevea]

On Jan 26, 2018, at 8:02 PM, Stewart C. Russell  wrote:
> If we got the Toronto licence approved tomorrow and none of the
> municipal licences changed for the better, at this rate we'd have all of
> the BC2020 data cleared for use by 2088 …

Now, no reason to let optimism wither; nobody is saying the project should 
change its name to 2090 or 2050 or even 2030.  (Hm, 2030?  Uh, scratch that I 
said that).

OSM is a medium-to-longer term project.  BC2020 is very ambitious:  it is in 
its early days.  Let throats clear, flags fly up flagpoles, wheels to remain in 
motion, dialog to continue and good work to continue.  Including the solid task 
of planting acorns so that mighty oaks may grow.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020 OD_tables wiki and project status

[OSM Volunteer stevea]

On Jan 26, 2018, at 6:42 PM, john whelan  wrote:
> I'm under the impression that Ottawa was the first city to move to the Open 
> Data 2.0 licence created by Treasury Board.
> 
> I'm also under the impression that it is the only one that has had its 
> benediction from the legal working group.  Treasury Board of Canada put quite 
> a lot of effort into updating their 1.0 license and aligning their 2.0 
> license with other organisations.  I don't believe their 1.0 license meets 
> OSM licensing requirements. 
> 
> I seem to recall they have a municipality kit to assist municipalities with 
> Open Data.
> 
> There seems to be rather more green boxes than I would have expected.  I 
> would hope they all have been approved by the Legal Working Group or are an 
> exact clone of the TB municipality one as Ottawa is.

What I did was to "back-populate" the list of "approved" (by whom?  when?  how 
did these get here?) list of Canadian cities from
https://wiki.osm.org/wiki/Contributors#Canadian_Municipalities

into OSM's BC2020 wiki.

OK, we know Ottawa should be green:  check.

A couple (Edmonton, Yellowknife) imply contradictions:  an entry on the 
Contributors page, but a status in the table which says "nope, can't use data 
with this licence."  Those are yellow, meaning "need disambiguation:"  check.

Toronto is yellow, as its licence is said to be "under discussion since early 
2017."  Check.

Vancouver is green, as it is on the Contributors page (implying its licence is 
OK) and its "Completion in OSM" is yellow and says "In Progress."  Seems like a 
"check."

Montreal is green, (ditto), yet its "Completion in OSM" is red and says "0% 
complete."  Check.

Surrey, York, Halifax and Gatineau are green, (ditto), and their "Completion in 
OSM" cells are simply, well, empty.  So they are empty and colorless.

If there is something incorrect, ANYBODY (in or out of OSM who has a wiki 
account) can change these to be more accurate!

Capturing ADDITIONAL status harmonization with whatever might be going on in 
OSM-CA-TM is an ongoing bit of work to be done which appears to be only in the 
most early of contemplation/discussion.

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] BC2020 OD_tables wiki and project status

[OSM Volunteer stevea]

The first (municipal) OD table in
https://wiki.osm.org/wiki/WikiProject_Canada/Building_Canada_2020/building_OD_tables
now uses green/yellow/red color-coding to better display accurate status in 
those cells of rows in the "License" and "Completion in OSM" columns.  These 
give a certain "at a glance" view of both of these.

This was neither difficult nor did it take very long.  Now that this wiki and 
the "main" BC2020 wiki come closer to accurately describing the state of the 
project, it shouldn't be hard to update a line here, a column there, a link or 
two to stay synced.  Please, in a project with scope as vast as this, our open 
wikis in this project guide, inform, present a forum to discuss and document, 
PLUS, they are easy to edit and update with current status.

In my opinion, there is still some work to do to better organize and harmonize 
the use of the OSM Canada Task Manager tasks with this, as a large majority of 
Tasks in the TM have the word "building" in their title.  OSM can get there.

I like what I see, the project is now better focused and intra-OSM 
communication improves by the day.  From crawling to toddling to walking:  
excellent.

Happy weekend everyone,
SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Talk-ca Digest, Vol 119, Issue 10

[OSM Volunteer stevea]

Thanks for this additional clarity, Stewart.

May I politely suggest you or another helpful volunteer update this "table 
wiki" to reflect that, perhaps with some text that says so?

If it makes sense to "blurb a note" into the Comments cell for a particular row 
(Grand Prairie, Muskoka, Edmonton), it seems that would stitch together the 
communication.  (Using the wiki, in the OSM way, so others can "at a glance" 
see status, progress...).

I find interesting regarding Edmonton, for example, that even with an 
incompatible licence (I don't know if north of the border it's with a c or an 
s) the Comments cell reads "80% done."  That "seems" like a contradiction, 
though, of course, it can't be.  It appears to mean "buildings are being 
entered around Edmonton regardless of the license incompatibilities."  In my 
experience in OSM, that sounds like a conversation, as we have here in talk-ca.

Yes, so, we're having it.  Part in talk-ca, part in the wiki, part in the map, 
part in email, part in the real world over coffee and talk.

More in the wiki, please?  Thanks, it feels like my work is done here!

SteveA
California

> On Jan 26, 2018, at 2:13 PM, Stewart C. Russell <scr...@gmail.com> wrote:
> On 2018-01-25 04:00 PM, OSM Volunteer stevea wrote:
>> The other wiki (linked to in the "main" BC2020i wiki's "Inventory of
>> Current Building Data Sets" section): 
>> https://wiki.osm.org/wiki/WikiProject_Canada/Building_Canada_2020/building_OD_tables
> 
> Note that the licence compatibility column as it stands is a bit
> misleading now that the table has been split from the main page. There
> are a lot of entries that say ODL 1.0 or OGL 2.0 for instance. These
> will be the local spin a data licence, and each one will need to be
> individually approved by the LWG before the import process can be
> started. Examples:
> 
> * Grand Prairie - http://www.cityofgp.com/index.aspx?page=2332
> 
> * Muskoka -
> http://map.muskoka.on.ca/exponare/Open_Data/Open%20Government%20Licence_District%20Municipality%20of%20Muskoka%20GIS_2014.pdf
> 
> We don't yet have one licence that rules them all. For instance, the
> Edmonton imports (such as
> https://www.openstreetmap.org/changeset/28190793) look unapproved and
> incompatible.


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] building imports (was Re: Talk-ca Digest, Vol 119, Issue 10)

[OSM Volunteer stevea]

On Jan 25, 2018, at 8:55 PM, Matthew Darwin  wrote:
> I'm all for using the wiki, just want to consider the maintenance effort of 
> keeping the tasking manager in sync with the wiki.  If someone wants to do 
> that, so much the better!   Wikis can get stale quickly without someone(s) to 
> actively look at doing updates, like you're doing.

Right, except the BC2020 wiki has gone from zero to two links.  One link is 
enough (per sub-project, not tiles within a sub-project) to enter the Tasking 
Manager's "front door."  Yet "this" (Task 100, Ottawa - Validate Addresses and 
Split Terraces) hasn't had ANY link to the wiki (nor the Tasking Manager in 
general).  And that wiki is "only" for BC2020, yet Canada-wide.  It seems the 
Tasking Manager site, countrywide, and Canadian WikiProjects might enjoy a 
little harmony and organization.

And we just did, putting two links in one wiki.  More, later, in other 
(Canadian-based WikiProjects and the Canadian Tasking Manager) wikis?  Sounds 
good.  Not being local, I can't effectively do that, but others can, and I 
believe it will help.  A little bit of organization and project (links, wikis, 
mapping work...) connectivity (intra-OSM, as it were) goes a long way.  Nice 
working with you!

> Keep up the great work.

Thanks, you and BC2020 (and Canadians OSMers and all of OSM and all the little 
children...), too.

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] building imports (was Re: Talk-ca Digest, Vol 119, Issue 10)

[OSM Volunteer stevea]

> There are many more tasks on the task manager related to buildings if you are 
> so inclined to add them.   Is that the best way to go? or people can check 
> the task manager for projects in their area of interest?   (new tasks can be 
> easily added to the task manager... just ask!)

I sort of feel a need to just shut the heck up and let others post 
"communications about the WikiProject" (like OSM-TM links) TO the WikiProject 
(wiki).

That is all.  Keep the communication up and in the wiki rather than in "walled 
gardens" of "happen to know somebody" or "walled garden."

It's OSM, after all.  We use other forms of communication, but on a national 
project of scope this large, we can (and should and do) use the wiki.

Zippin' it closed for a while,
SteveA
California



___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] building imports (was Re: Talk-ca Digest, Vol 119, Issue 10)

[OSM Volunteer stevea]

On Jan 25, 2018, at 8:30 PM, Matthew Darwin  wrote:
> I should mention that there are others in Ottawa working on completing the 
> buildings.  The City import only had urban buildings.  Since the city of 
> Ottawa is the largest rural city in Canada, so much work still to do.  See 
> http://tasks.osmcanada.ca/project/114 and 
> http://tasks.osmcanada.ca/project/100

See, now, like that:  I put these links into 
WikiProject_Canada/Building_Canada_2020.  (Where they belong, he suggest 
humbly).

I mean, I'm glad I learned about that here, as talk-ca seems an appropriate 
place to learn that.  Yet our wiki updated with those links took me about 
twenty seconds of cut-and-paste.

Yeah!

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] building imports (was Re: Talk-ca Digest, Vol 119, Issue 10)

[OSM Volunteer stevea]

On Jan 25, 2018, at 8:13 PM, Matthew Darwin  wrote:
> I'm not who the "movers and shakers" are really.   There is nobody really 
> driving this project that I am aware of (the wiki suggests we should have a 
> steering committee).   Every time I see email sent to the original 
> distribution list of people invited to the meeting last September, I suggest 
> the conversation continue here, but never really does.(there is no 
> conversation really)

Thank you for your response, Matthew!

> What happened to all the agencies in that meeting that suggested this was a 
> good idea?  What are they doing to contribute?  I have no idea.

Well, somebody (besides me) is writing (and wrote) wiki.  Maybe it is becoming 
an "orphaned" project?  That would be a shame, it has such potential and 
respectable growth so far, it just looks a bit like a freshly-built ship 
without a rudder.  I think it has potential and momentum, the framework is 
there, a good pilot project in Ottawa seeds it well.  Looks like a "call out" 
to "agencies" and such takes some time for throats to be cleared and such and 
"hm, yeah, we're working on that, too."  OK, that happens.  In a day, in a 
week, in a month, after a quarter.  Clearly, it's early days in BC2020.  Shout 
out?!  (By me, here, now?)  Oh, a-a-agencies?  Anybody interested?

There, that oughta do it. :-)

> Personally I'm spending on average several days/week working on improving OSM 
> in the City of Ottawa.  (http://hdyc.neis-one.org/?Matthew%20Darwin).  My 
> focus is roads geometry (mostly done... remaining work is pending getting 
> info from the City of Ottawa... waiting 6 months with no answers) then 
> addresses (in progress) then we'll see what's next Probably I will make 
> the tooling I've worked on available as open source, and then do work on 
> buildings.

I say it as necessary (it can be frequently):  OSM is a medium-term to 
longer-term project, especially with large-ish, 
regional/national/continental-sized sub-projects like WikiProject BC2020.  What 
I certainly don't want to happen is somebody gets "chased off" (whether by "I 
haven't the time" or "I don't stand tall enough to ride the ride" or many other 
reasons) and the whole initiative goes "poof."  It birthed as a brilliant flare 
and now toddles along.

If I may humbly say to the dear readers here:  I see many green lights ahead on 
BC2020.  There are some pesky obstacles like licensing and a good Import Plan 
(the Ottawa seed is a good start) but those do get resolved over the medium- 
and longer-term.  Crawl, walk, run:  excellent.

Regards,
SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Talk-ca Digest, Vol 119, Issue 10

[OSM Volunteer stevea]

On Jan 25, 2018, at 12:16 PM, john whelan  wrote:
> About six years ago I wanted to import the local bus stops but the licences 
> weren't aligned.  It took about five years for the Canadian Federal 
> Government to first adopt an Open Government license that was open enough and 
> then for the City of Ottawa to adopt it.  It still needed to be looked over 
> by the legal working group before being accepted by OpenStreetMap.

Yes, Canadian "public" (municipal, provincial and federal government) open data 
(OD) licenses appear to have a long history of evolving to become 
ODbL-compatible.  Some very good work has been done here and it continues to 
evolve to a better state.  For the BC2020i, OSM has two wikis that "track" what 
is going on here:

https://wiki.osm.org/wiki/WikiProject_Canada/Building_Canada_2020
is the project's "front door."  For a project with scope this huge (ten million 
buildings, nationwide in the geographically second-largest country on Earth...) 
communicating via wiki is very much "the OSM way" — and this BC2020i, simply 
put, IS an OSM project.  While this wiki's Governance section does say that (in 
these early days of the project) much intra-project communication happened via 
email amongst the early movers and shakers, it also says "we are working to 
improve this."  PLEASE, movers and shakers within BC2020i:  wiki, wiki, wiki!  
A great deal of Project Management (critical to better establish in these early 
days of BC2020i) and indeed intra-project communication (status, how far along, 
what's current and upcoming...) can be communicated, very WELL-communicated, 
via this wiki.  Go!

The other wiki (linked to in the "main" BC2020i wiki's "Inventory of Current 
Building Data Sets" section):
https://wiki.osm.org/wiki/WikiProject_Canada/Building_Canada_2020/building_OD_tables
does a good (early) job of displaying in three tables open data on buildings at 
municipal, provincial and federal/other/thematic levels.  Again, this project 
is in early days, and license compatibility with ODbL is also in 
early-to-middle (with encouraging progress) phases.  As a veteran OSMer both 
familiar with and with having very hands-on experience at nationwide projects 
(bicycle routes, rail infrastructure and passenger routes...) I am encouraged 
to see this table growing, license compatibility improving, and the "main" 
BC2020i wiki solidifying.  However, as a passionate OSM contributor, I'd like 
to see the "walled gardens" of more-private email communications and GitHub 
documentation come down, with such communications migrating their way into our 
wiki structure:  doing so is an important acknowledgement that this is an OSM 
project (and it is).

> The city though provided a file of every building outline in Ottawa.  Then it 
> was just a matter of adding tags to the buildings for Stats Canada.  That was 
> the Stat Can pilot project.

And, in my opinion, it was a successful demonstration pilot project, a solid 
foundation for BC2020i to launch further progress.  Keep up the good work!

> The import did need to be carefully handled.

As EVERY import does!  (Especially an important pilot project one, and in the 
capital city, no less).  The BC2020i links to the Ottawa Import Plan, which 
appears to be (as it is) OK documentation as to how the data were "harmonized 
from OD sources into OSM."  However, WikiProject BC2020 (and that's what it is) 
needs to go much further, documenting a REAL Import Plan for the entire 
project.  Our Import Guidelines at https://wiki.osm.org/wiki/Import/Guidelines 
MUST be followed, with an eye towards making the (nationwide, extensible to 
local sub-projects) Import Plan flexible enough to be handled by the full gamut 
of scenarios which may contribute data:  from high school tech/open data 
"fests" to Mapping Parties and Meetup groups, to large-scale (university-based, 
technology-company based, stakeholder-based...) data import intentions at a 
more local level.

> If you can get your hands on an Open Data file containing the building 
> outlines with the correct licensing it does make the task a lot easier.  
> Teaches the students about the value of Open Data at the same time.

Yes, "having OD" is PART of it, certainly making easier achievement of the goal 
(vision) of BC2020i.  However, as WikiProject BC2020 is an OSM project, there 
is more to it than that:  OSM's tenets of good data entry (especially when 
imported from public sources) MUST absolutely resonate with future uploads.  
Our wiki as a "project blueprint" and a nationwide Import Plan, flexible enough 
to be locally-modifiable to be successful, MUST "rule" the HOWs of data 
importation.  This "nationwide/project-wide" Import Plan, flexible enough to 
handle multiple scenarios and flavors of building data is ripe (overdue?) for 
completion.  It is an ambitious project, and I wish you the best of luck and 
success!

SteveA
California

Re: [Talk-ca] BC2020i and Mapathons with High Schools

[OSM Volunteer stevea]

On Jan 23, 2018, at 5:53 PM, john whelan  wrote:
> It should have been 60 per hour.  Apols.  I can probably map at one per five 
> seconds but new mappers did and will take much longer.  The iD figures of 
> four to twenty buildings per mapathon session are real numbers.
OK, you're right:  60 BPH is what you're saying.   Both your numbers and the 
4-20 BPMs (buildings-per-mapathon, not to be confused with 
buildings-per-minute) look respectable.  I might be saying there are "sixty of 
those" and at a university mapathon or something like that you might get there. 
  1 BPS = 60 BPM.  So, yeah!  OSM is organic, it moves in fits and spurts.

I'm not quite sure what Apols means.  Thanks in advance if you clarify.

> Do look at the steps involved in actual mapping in iD and JOSM.  For 
> buildings in iD its select area four corners, square then select the correct 
> building tag from a number of choices.  Lots of places to make a mistake.
Like efficiency measurements where typing fingers are slow-motion recorded, 
you've clearly looked at this.  I agree, lots of places to make a mistake which 
also means improvement is more than possible.

> For JOSM building tool plugin its about three clicks per buildings and it 
> comes squared and tagged.  There is a certain amount of setup but compared to 
> iD the data quality is much much better.  Both Jo and myself have used this 
> approach.  I was not working with high school aged mappers by the way.

Ah, yes, this new thread is about high school students doing BC2020i.  There is 
some road to pave, "you gotta be this tall" sorting hat thing, though sorting 
hats sort.

> You need to plan this out very carefully for the best results.

Yep:  planning.  Good.  OSM is organic, it moves and grows in fits and spurts.  
Fantastic project.

Fun, isn't it?  (I enjoy this discussion, by the way).  Great talking here.

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020i and Mapathons with High Schools

[OSM Volunteer stevea]

I agree that absolute novices unfamiliar with OSM are not what we might call 
"an ideal candidate," for BC2020i but it certainly has been and can be done.  
That said, "coming with Java preloaded" is a certain kind of "trigger warning" 
that "you have to be this tall to ride the ride."  That's sort of a crude way 
to put it, yes.

"Discovering OSM first on one's own" (iD, teeth cutting, tech chops, confidence 
in basic mapping, community, tenets and what it's about, standing tall, 
standing taller...) is fantastic. Come with Java installed, we have tools here 
and Elmer can walk you through it.  For many, that's cool, awesome, fun and 
helpful, all at the same time!  60 per minute per building = 1 building per 
second.  Congratulations to the communities of Canada and OSM:  that's a cool 
measurement, right there.

Is your average high school student up to this?  Some are, some are less so.  
That's how it is.

Spare mice, huh, perfect!  QA at the beginning, middle and end, yeah.  Banging 
on a certain large number of cylinders, check.  Bulls-eye?  Hey, closer and 
closer!

Steve
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] A message aimed more at Ottawa

[OSM Volunteer stevea]

John Whelan says:
> Thoughts?

There are obviously "deep thoughts" going on regarding how OSM can document and 
provide better geo data, routing and maps for Canadian cyclists:  my hat is off 
to the serious "front-loading" going on here and I wish to encourage it so that 
it may flourish.

Simultaneously, much can be said about getting (and having) a "basic workable 
framework" which provides useful information of the above sorts, right now.  As 
I look at Ottawa area bicycle tagging (both infrastructure and routes, as they 
are two different kinds of OSM data entry; the former as good tags in 
infrastructure elements the latter as good tags on route relations) I find this 
framework satisfactory (though I am not local).

To take a "first best practice" approach, I might suggest that a milestone be 
defined for a "1.0" version of what is attempting to be achieved.  This might 
be what I find as I do this sort of OSM work (and consulting about it) in the 
USA:  getting to a reasonable harmony between what local jurisdictions define 
and document as both bicycle infrastructure and bicycle routes, and whether 
those data are well-represented in OSM.  Ottawa might be there, it might not, 
but if you don't know that, it becomes difficult to measure progress and better 
plan for the ambitious future you have.

Weather-related local conventions are a new twist I am not familiar with (being 
from California), and I wish you luck in having those emerge to be useful to 
your local (and eventually, regional and national) cyclists.  Other (similar) 
concerns like "level of stress" (which seems to be deeply-ingrained as part of 
the "bicycle parlance" in local government) and "bikability," level of riding 
comfort, appropriateness for younger or less-experienced riders, etc. are 
topics which have been well-explored.  As I mention, sometimes these turn into 
either new tags, new tagging schemas (some more successful, some less) and new 
renderers (e.g. the Mapzen bike routing links I offered earlier quickly evolved 
from a v1 to a v2, with substantial feedback-generated improvements).  Those 
are real-life stories which show that there is a somewhat-long path:

Existing bicycle infrastructure -> maps (hard- and soft-copy) published by 
local jurisdictions -> routes of this infrastructure (ditto, though sometimes 
these are "more independently developed") -> data of these sorts (plural!) 
getting into OSM -> renderers which use these data (OpenCycleMap, 
waymarkedtrails.org, mapzen...) -> routers which use these data (e.g. 
cycle.travel...).

That path/workflow bubbles up from the roots of streets and routes folks bike 
on and the feedback loop of local jurisdictions to 
make/develop/improve/document these, all the way to a savvy biker running an 
iPhone app that produces the "perfect route, today, because it is snowing 
lightly, and my daughter is accompanying me to the park we are biking to" with 
the swipe of a finger.  Obviously, there is a LOT "in the middle" there, and 
that "big middle" will be both the same (structurally, within OSM and its 
conventions of tagging and building renderers and routers) and different (in 
the case of "we have speed limit data and traffic volume and snow-day data 
here").

Seek out the existing "wheels already invented" (some within OSM, some not).  
Learn from those what didn't work and what might be repurposed to work and work 
well.  Use the good tenets of OSM (consensus, plastic tagging which can 
well-accommodate new strategies like "how do I bike on a snow day?" and the 
"soft" aspect of software to build renderers and routers (should you eventually 
get there, and I believe you will).  The future of bicycling in Ottawa (and 
Canada) looks like it is going to LOVE OSM and all it has to offer these 
efforts!

Get to a consensus of "local (government's view of bicycling) 1.0 is now OSM 
1.0" and then put the pieces together of what will be (I can feel it in my 
bones!) a terrific 2.0.  And 3.0 and beyond.  However, nothing ever happens 
without a good plan, and good planning and good project management is what will 
get you there.  The solid backbone and structure of OSM is the vessel, and 
Ottawa and Canada are very well on your way to fantastic bicycle geo data and 
tools.  The rest of the pieces come from dialog, consensus, good community 
building, good planing and good implementation.  Go!

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] A message aimed more at Ottawa

[OSM Volunteer stevea]

James wrote:
There's also documentation that Ottawa is using(not final thats why its not on 
the wiki) with example pictures:
https://github.com/osmottawa/OSM-Bike-Ottawa-Tagging-Guide/blob/master/README.md
There are differences with respect to US bike pathes

Thanks for the link to that page, James!

There are a couple of empty cells (and other specifics) I might make 
suggestions about:

Singletrack:  highway=path (PLEASE ALSO INCLUDE a surface=* tag with this), 
bicycle=yes, width=* is helpful if you know it,
Track road:  highway=track, tracktype=[grade5, grade4, grade3, grade2, grade1], 
width=*, surface-=* bicycle=yes (or =designated or foot=yes...a bit flexible),
Contraflow lane with separation:  I'm not sure exactly what you're trying to 
specify, please see wiki pages cycleway=opposite_track and 
cycleway=opposite_lane.

Sometimes, like with path/way data in our map, I'm OK with entering wiki which 
are sketchy (incomplete, yet a great start), though I won't enter data which 
are outright incorrect.  This is an excellent document which should be 
converted into a Canada-based bicycle tagging wiki POST HASTE!  (Well, at your 
convenience, of course:  an "A-minus becoming an A-plus" is certainly ripe for 
wiki-hood).  Wikis often start out as stubs and grow into (nearly) complete 
and/or (nearly) perfect documents; the operative word is "grow into."  Your 
tagging guide is thoughtful and great work on documenting bicycle 
infrastructure.  (I sheepishly hesitate to say it puts what we have in the USA 
— nothing close! — to a bit of shame).  Well done!

Regards,
SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] A message aimed more at Ottawa

[OSM Volunteer stevea]

Oops, the bicycle router I wanted to refer to in my previous is 
http://cycle.travel by Richard Fairhurst (whom I inexplicably confused with 
Simon Poole).

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] A message aimed more at Ottawa

[OSM Volunteer stevea]

Hello talk-ca:  I'm resurrecting a month-old thread (about bicycling) as my 
initial post here.

I'm a California-based (USA) nearly nine-year veteran of OSM.  My wiki user 
page at https://wiki.osm.org/wiki/User:Stevea shares some details of my 
mapping, including parks and other mostly-natural/leisure areas, bicycle 
infrastructure and route mapping (I spoke on the topic at SOTM-US in 
Washington, DC in 2014) and national rail infrastructure and passenger train 
mapping (ditto, at SOTM-US in Seattle in 2016).

Regarding bicycle (infrastructure, route) mapping in OSM, I'll share that I 
have much to say, trying to be brief for now.  I contribute to and help 
coordinate harmonious growth of our wiki pages 
https://wiki.osm.org/wiki/United_States/Bicycle_Networks and 
https://wiki.osm.org/wiki/WikiProject_U.S._Bicycle_Route_System.  Some of what 
I have learned from a national scope perspective (in the USA) follows and I 
hope those in Canada may find it helpful.

In any effort to improve bicycle infrastructure in OSM, first map with 
highway:cycleway, cycleway:lane/track and bicycle:* tags.  Then, assemble any 
route=bicycle relations out of those infrastructure elements.  This order isn't 
strictly required, but it can help you stay sane and any wider effort (and OSM 
is) to remain well-coordinated.  Should routes already exist, assure they are 
harmonized within a wide community (in OSM, at a national level, after 
consulting with provincial and wide-area groups or non-profits) before 
progressing to fully standardizing on what are meant by values of network=* 
tags.  To resolve ambiguities, the cycle_network=* tag can be your good friend, 
its wiki now sketches sane values for Canada.  Better, more sharply focussed 
values can emerge with more consensus, taginfo can track both staid stability 
and new emergences.

Regarding network=* tags, there may be some friction and/or ambiguity in Canada 
with what in the USA we distinguish as "quasi-national," "quasi-private" and 
"private" bicycle routes.  These can be difficult to map onto existing bicycle 
route tagging schemas (especially network=*).  Please be welcome to use history 
of how these emerged in the USA (between about 2011 and 2014) to achieve a 
similar harmony in Canada.  From what I see so far, Canada does well as bicycle 
routes emerge in OSM:  lots of work is yet to do, but tender shoots of early- 
to mid-life bicycle route mapping look great from here!

There have been many initiatives to "better map bicycling" using existing OSM 
data and tagging (e.g. https://mapzen.com/blog/bike-map-v2, though, alas, 
Mapzen disappears :-( in a few days) with "comfort level," "suitability" and 
"safety" approaches using existing tags to semantically extrapolate those as 
color-coded renderings.  There have also been attempts to introduce new tagging 
schemas into OSM which have similar goals:  
https://wiki.osm.org/wiki/Cheltenham_Standard and 
https://wiki.osm.org/wiki/CycleStreets (with HTML5 web, iOS and Android 
implementations) come to mind.  Many overlays/renderers (Andy Allan's 
OpenCycleMap, Sarah Hoffman's waymarkedtrails.org and its excellent mountain 
biking overlay — a whole 'other animal compared to "road route" bicycling, 
Simon Poole's bicycle router, our very own and excellent 
https://wiki.osm.org/wiki/Bicycle_tags_map...) are quite helpful:  there are a 
lot of resources out there.  Better tagging, better rendering, better routing 
and better data all continue to emerge, especially as these resources are more 
widely consulted and used around the world.

My apologies if any of this seems basic, I'd dislike seeing anybody re-invent 
wheels when so much good work has been done in OSM regarding bicycling, bicycle 
routing and bicycle mapping in the context of improving "ride ability" or 
"bicycle usability."  I wish the very best to Canadian OSMers in doing so!

Regards,
SteveA
OSM Volunteer since 2009
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca