Re: [Talk-ca] The Statistics Canada Project

2016-10-17 Thread AJ Ashton
Hi John,

Thanks for the writeup. I think this is the first post that's made it
fully clear what is going on. As I was re-reading the previous StatCan
thread earlier today I seemed to be missing something - now I guess it
was context available to those who attended in-person meetings. I don't
think it was even clear to the list until now how much in-person
community discussion has been happening.

Basically the issue is that all the online discussion about this looks
to have been about the StatCan crowdsourcing half of the project and
none at all about the building import half. I didn't pay too much
attention to the original StatCan thread at the time because it so
clearly sounded like a local mapping project with no large-scale import
component.

Unfortunately I no longer live in Ottawa and couldn't have made it to
the meetings. However I lived there for many years, have done a lot of
mapping there, and have a continued interest in the area.  I would still
like to see the the building import happen and even help out where I
can. But I think it's important to do more planning and discussion on
this list and the imports list, and to  take things in smaller and more
manageable chunks.

I guess the next step would be to continue on a proper path to import
the buildings per the guidelines per
http://wiki.openstreetmap.org/wiki/Import/Guidelines . This would
include:

- Wiki documentation of the where the data is, what it contains & its
  license / permissions
- A plan to conflate with existing data - preserving history, keeping
  existing attributes, and merging addresses onto buildings where
  possible before the data is uploaded
- A specific plan for uploading the data. Eg how the data will be
  divided up into chunks and step-by-step instructions for JOSM, etc. A
  task server was mentioned several times - who is running this and how
  can others participate?
- A proper review on the imports mailing list

I don't necessarily agree with every single rule in the import
guidelines, but they are what the community has decided on and I think
for the most part they help avoid the kinds of issues I had with deleted
and duplicated data in Ottawa.

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


Re: [Talk-ca] City of Ottawa imported buildings & addresses

2016-10-17 Thread AJ Ashton
On Mon, Oct 17, 2016, at 13:37, James wrote:
> Like this one Kevin?
> https://lists.openstreetmap.org/pipermail/talk-ca/2016-July/007034.html
> or this one?
> https://www.mail-archive.com/talk-ca@openstreetmap.org/msg07024.html
>
> or this one?
> https://lists.openstreetmap.org/pipermail/talk-ca/2016-August/007151.html
>
> or this one?
> https://lists.openstreetmap.org/pipermail/talk-ca/2016-August/007068.html
> Tired of googling, but it's the ones I found in a couple of seconds

Those are what I was referring to as not sounding very much like an
import discussion.

"Here is what we would invite Canadians to tell us about
buildings for OSM"

"Statistics Canada initiated a two-year pilot project aimed at
understanding the potential of data crowdsourcing for statistical
purposes."

"We are planning to use OpenStreetMap as a platform for inviting
contributors to crowdsource information on non-residential buildings"

All of this sounds like they were planning one something like an online
mapping party, not an import of government data. Certainly there is no
mention that all existing buildings in Ottawa would be wiped out first.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


[Talk-ca] City of Ottawa imported buildings & addresses

2016-10-17 Thread AJ Ashton
I haven't seen any substantial discussion about the Ottawa buildings &
addresses import anywhere. I did see the thread a number of weeks back,
"Crowdsourcing buildings with Statistics Canada," but I didn't see
anything discussed that sounds like the planning of a mass import. The
wiki page linked from the discussion [0] is completely empty. From a
changeset discussion I was pointed to another section of the wiki [2]
which again has few details and does not sound like an import
("...inviting contributors to crowdsource information on buildings").

[1]: http://wiki.openstreetmap.org/wiki/Ottawa_Gatineau_Buildings
[2]:
http://wiki.openstreetmap.org/wiki/WikiProject_Canada#Crowdsourcing_buildings_with_Statistics_Canada

What has actually happened is most (or all?) of the existing buildings
in Ottawa were deleted, and then replaced by imported data. For example
changeset 42699159 [3] deleted hundreds of buildings and addresses I had
mapped in my former home of Stittsville. Changeset 42699460 [4] replaced
everything with City of Ottawa data.

[3]: https://osmcha.mapbox.com/42699159/
[4]: https://osmcha.mapbox.com/42699460/

The quality of the imported shapes seems fine and I have nothing against
building imports in principle. I just wish existing data could have been
updated or left alone - I don't see a substantial difference between
what I had traced from Bing and the import except for an offset of
perhaps a few meters. Although I saw someone noted on IRC that in
several cases existing properties such as building:levels tags were
lost; this is more concerning.

In addition to building footprints, addresses are also being imported.
This data is a little more problematic and the importers seem to be
taking a "import now, fix later" approach. Example: changeset 42633517
[5] added over 20 thousand address nodes that were clearly not
quality-checked. Addresses are being imported as points when they could
be attached to buildings, and sometimes address points are doubled,
tripled, or even quadrupled [6].

[5]: https://osmcha.mapbox.com/42633517/
[6]: Eg this area:
https://www.openstreetmap.org/#map=19/45.26652/-75.93753

Could the organizers of this import point me to any further mailing list
discussions or wiki pages I might have missed? Can we talk about why the
clearcut approach to existing data was taken, and why the address data
was not cleaned up *before* import?

(The changesets I linked to may make it look like I am specifically
calling out user LogicalViolinist, but the import was a group effort by
a number of users. LogicalViolinist just happens to have covered the
part of Ottawa I am most familiar with.)

-- 
  AJ Ashton
  a...@ajashton.ca

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


Re: [Talk-ca] [Talk-us] Great Lakes Boundaries

2015-04-27 Thread AJ Ashton
On Sun, Apr 26, 2015 at 8:47 AM, Mike Thompson  wrote:
> Since no objection to removing "natural=water" from the Lake Superior
relation has been expressed, I have removed it. I also amended the note on
the relation asking that it not be added back in.

Huron, Michigan, and Erie all had the same issue (added at the same time by
the same user) so I removed "natural=water" from those as well and added a
similar note. Lake Ontario on the other hand is *only* mapped a water
multipolygon (no coastline ways) so I've left it as-is for now.

On Mon, Apr 27, 2015 at 11:12 AM, Mike Thompson  wrote:
> I don't think we are out of the woods yet. Overnight the NE end of Isle
Royal became "flooded" at zoom level 13

This may also be due to outdated coastline shapefiles used by the standard
tile layer (but I am not sure). The coastline data for Isle Royale looks
good as processed in the latest daily files from <
http://openstreetmapdata.com>.

> Proposed Course of action.
> [...]

The proposed course of action for cleaning up the extra/incomplete Lake
Superior relation seems good to me.

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


Re: [Talk-ca] [Talk-us] Great Lakes Boundaries

2015-04-24 Thread AJ Ashton
On Sat, Apr 18, 2015 at 11:22 PM, Mike Thompson  wrote:

> User maxerickson sent me this comment directly about this issue:
>
> =
>
> The current modeling of the Great Lakes is actually to use
> natural=coastline.
>
> The addition of natural=water to the lake superior relation is probably
> what caused the bad rendering at z13.
>
> If you check the history of the relation, you can see people repeatedly
> adding and removing natural=water.
>
> =
>

Yes, if Lake Superior is mapped as natural=coastline (which I think is the
easier-to-maintain approach for such a large & complex water body) then we
should remove natural=water from the multipolygon relation (r4039486). Does
anyone have any objection to this? It's causing some noticeable rendering
issues both in the standard style and for data consumers.

There is also a second multipolygon relation for Lake Superior that appears
to be entirely redundant: https://www.openstreetmap.org/relation/1120169 .
It captures just the Canadian half of the lake. I think this relation could
just be removed after going through it and confirming that all of its
member ways are properly tagged as natural=coastline (which they appear to
be). Does anyone have any reason to keep this relation? (cc'ing talk-ca)

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


Re: [Talk-ca] openstreetmap.ca is up!

2013-04-22 Thread AJ Ashton
On Mon, Apr 22, 2013 at 9:34 AM, Richard Weait  wrote:

> What zoom and center point?  How does that work on different devices /
> resolution / orientation?
>

The map view can be based on a bounding box, so a strategically-selected
bounding box should handle all of these variables well. We should probably
exclude the northern reaches of the territories from the bbox otherwise it
will look like OpenArcticMap thanks to mercator.


> How will this be implemented?  What effect will this have on a returning
> visitor?  What else?
>

I find that being returned to the last thing I viewed is annoying/incorrect
more often than not, so maybe have it centred on Canada every visit? I'm
not sure about this though.

-- 
AJ Ashton
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca


Re: [Talk-ca] openstreetmap.ca

2013-03-27 Thread AJ Ashton
On Wed, Mar 27, 2013 at 10:04 AM, Gordon Dewis  wrote:
> CIRA's residency requirements are defined in
> www.cira.ca/assets/Documents/Legal/Registrants/CPR.pdf

Perhaps the OSMF could ask a favour of Her Majesty under section 2(m)

;-)

Alternatively, do (q) or (r) apply?

q) Trade-mark registered in Canada. A Person which does not meet any of the
> foregoing conditions, but which is the owner of a trade-mark which is the
> subject
> of a registration under the Trade-marks Act (Canada) R.S.C. 1985, c.T-13
> as
> amended from time to time, but in this case such permission is limited to
> an
> application to register a .ca domain name consisting of or including the
> exact
> word component of thatregistered trade-mark; or

(r) Official marks. A Person which does not meet any of the foregoing
> conditions,
> but which is a Person intended to be protected by Subsection 9(1) of the
> Trade-
> Marks Act (Canada) at whose request the Registrar of Trade-marks has
> published
> notice of adoption of any badge, crest, emblem, official mark or other mark
> pursuant to Subsection 9(1), but in this case such permission is limited
> to an
> application to register a .ca domain name consisting of or including the
> exact
> word component of such badge, crest, emblem, official mark or other mark in
> respect of which such Person requested publications.


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


Re: [Talk-ca] What should a Canadian style map look like?

2011-09-14 Thread AJ Ashton
One aspect of the map that is not a uniquely Canadian problem, but is
perhaps more significant here than in other places is how temporal
objects & spaces should be handled. Many important aspects of mappable
life change distinctly between summer & winter - ice rinks,
recreational trails, usability of roads, availability of certain
services, etc.

Perhaps this specific type of temporality - summer vs winter - could
use some well-defined visual & data conventions to make them easier to
see & understand than current approaches to intermittent/temporary
objects in general.

Maybe we'd even seasonal map stylesheets :)

AJ Ashton

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