Thank you, John.
On Jan 17, 2019, at 11:22 AM, john whelan <[email protected]> wrote:
First if you look at the 2020 wiki page history you'll see there is a lot of
input from Steve. My concern with this very detailed input is it made it hard
for a new person to quickly locate relevant information, an overview if you
like.
I encourage an "Overview" section or what some call a "Quick Start." For some
(experienced OSM mappers), this could suffice for "jumping in right now." However, there is no
shortcut for anybody involved in the importation of these data to read every single word of the wiki. If
wiki words aren't relevant, they either weren't in the right wiki or they could have and should have been
deleted. As I wasn't sure of the actual direction of the project, I added what I thought would help. I
would much rather have there be more (extraneous, even) guidance and instruction which later got deleted as
superfluous than not enough and leave volunteers with more questions than answers. Call this a failure to
edit the wiki properly, though not on my part.
I will confess that there have been small groups in face to face meetings in
small cafes where you need a password to logon to the internet. He was not
specifically invited to them all.
I confess we have used conference calls and other methods of communication
without notifying hundreds of people first. There have even been meetings that
I was unaware of. For example I haven't even communicated directly with the
mappers who are doing most of the import at the moment.
There has even been at least one mapathon that Stats Canada only found out
about after the event.
I believe what is being said or conveyed here is that decentralized discussion preceding data input "happens." Sure,
it does, that is part of a planning process and not all of these are "widely open to all of OSM," nor should they be,
nor must they be. So, largely, "we agree" though I'm puzzled at your use of the verb "confess." Largely
speaking, it is the degree to which openness happens in OSM (or the spirit of moving it in that direction, especially when
identified as "we need more here") which is important, not specific cases where openness didn't happen.
Personally I'm not convinced that OpenStreetMap really needs every building in
the planet mapped in detail.
I don't wish to change your mind, but as you point out later, others seem to
disagree with you, seeing the urgency with which these data enter OSM.
The history was I was after the bus stops in Ottawa which meant I needed them
with an open data license we could use. I used to work at Stats Canada and the
corporate culture is very different to OSM.
Understandable and nothing wrong with that, especially as OSM does not seek to
house our data with Stats Canada. However, the reverse...we know the story.
In Canada we have fewer mappers on the ground and more places to map than in
many parts of Europe. We have a history of importing CANVEC data which comes
from a number of sources including Municipalities. So I acted in a
coordinating role. We managed to persuade the City of Ottawa to change it's
open data license to align with the federal one. I got my bus stops. The
local mappers were very much involved and there were at least half a dozen face
to face meetings that took place. I drifted down to one of them.
Stats was very pleased with the added tags on the building outlines in Ottawa.
This is information they felt could not be easily obtained in any other way.
Informative and appreciated. There are "pockets of uniqueness" all over the world and hence
methodologies of "this is a good match here" for data entering OSM which will and do widely differ
around the world. However, I believe all can agree that "quality data are quality data" (as well
as the opposite) and for this fundamental reason, OSM has standards to follow.
I am very aware that this data is important to many. This includes Federal
government departments and agencies. They were very vocal at a meeting at
Stats Canada during the HOT summit in Ottawa. It was open and at least half a
dozen OpenStreetMappers were present, three or four were from European or other
out of town locations. Having the building data in one place makes it much
easier for the ed users than having to handle different formats and open data
licenses. Currently one municipal social agency is very interested in mapping
places where fresh food can be obtained. I forget some of the other interests
but they were quite legitimate. We have seen considerable interest by high
schools and students in OpenStreetMap and using streetcomplete with building
outlines is one way that they can add value without causing too much havoc.
These are precisely the sort of reasons why OSM (with high quality, usable, local data) is so
important. Nobody disagrees with "high value data provide high value solutions" as an
equation that many use. The "front end" of that, how the data enter, is obviously key
here.
After we imported Ottawa a group of mappers decided that we needed more
buildings. They organised mapathons with new mappers and mapped buildings with
iD. The results were not good and the data quality side was raised in talk-ca.
I was involved in one where I set up new mappers with JOSM and the
buildings_tool plugin and that went much better as far as accuracy was
concerned.
Indeed, this is a typical "use case" in OSM: a feedback loop says "not good results," so
improvements to process hopefully assure the next iteration yield better data/results. Congratulations on
those successes, they are more of the good stuff of which OSM is made. "The journey is the reward"
is part of what's important in the process. Although, good data as a result is important, too.
The result of these mapathons and the community reaction was to convince Stats
Canada that releasing more building outlines as was done in Ottawa under an
Open Data license was a way forward. Kingston in particular was keen to
release its building outlines and get them into OpenStreetMap. Obtaining them
and making them available was a Stats Canada decision and was made in their
time frame.
But, was it made within OSM's OWN tenets and timeframes? That's a crucial consideration
I continue to feel receives short-shrift (as you seem in the mood to "confess").
Given that Stats Canada released the data under an acceptable Open Data license
I thought and still think the best way forward was to set up a plan and a
process to import the data. The alternative was probably going to be Ad-Hoc
importing.
I, too, think (and OSM knows) that the best way forward (with importable data) is to set
up a plan with process. I thought we did so with the BC2020 "reboot." Yet, it
isn't working, or is only partially working with limited success (I'll look at that
portion in the glass that partially fills it rather than calling it empty when it isn't).
So, yet again, let's do a mid-course (or perhaps early-course) correction and right the
ship. Really, we seem to largely agree!
I suspect that talk-ca is probably the most appropriate mailing list for this
sort of discussion which is why I emailed Nate directly.
We can move this to talk-ca if you like, I'm OK with that.
Thanks for continuing good dialog,
SteveA
