from:"Matthew"


On 31/08/2020 11.19, Greg Troxel wrote:

What I objected to was not "that is your opinion; many others disagree"
but "that is your opinion but *no one else* sees it that way".  If you
didn't really mean that, sorry for overreacting.


Fair enough. I probably should have said something like "my 
understanding is that this is contrary to the community consensus". It's 
always possible that what appears *to me* to be the community consensus 
looks different to others.


--
Matthew

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

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH


On 31/08/2020 10.54, Greg Troxel wrote:

Matthew Woehlke writes:

*You* may see it this way. The rest of the community does not.


A declaration that every other member of the community disagrees is
unreasonable.


I'm not sure if this is directed at me or at Mike. If at me, I'll point 
out that the fact we're having this conversation in the first place is 
because someone strongly disagrees with residential driveways being 
access=private "by default". Nor is it the first time I've encountered 
that opinion.


Honestly, my initial opinion on the matter was closer to Mike's, but 
others told me I was wrong.



   B) private shopping centers where the public is welcome, to shop.
   (access=customers, mostly)

   C) private land where use is known acceptable (access=permissive)


Even this is not clear. *My* understanding is that most businesses are 
closer to access=permissive, with access=customers referring more to 
places that are explicitly signed as "customers only". In most shopping 
centers, for example, it seems acceptable to go there just to walk 
around even with no intention of purchasing anything. (At least, I know 
that people do so...)


--
Matthew

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

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH


On 31/08/2020 10.18, Mike Thompson wrote:

On Mon, Aug 31, 2020 at 7:46 AM Matthew Woehlke wrote:

The objection is that access=private currently *has* an understood
meaning, and that meaning is *no* access without permission, not what
you described above.


Sounds like my driveway.  If you are using my driveway without my
permission, either implicit (e.g. delivering a package) or explicit, I am
going to ask you to leave.  I think you are conflating whether something is
"not allowed" with "can be prosecuted as a crime."


I think *you* are conflating implicit permission and explicit 
permission. access=private as I understand the general community 
consensus to be means no access without *explicit* permission. No access 
without *implicit* permission is closer to access=destination... but 
note I said "closer to". We don't seem to have something that exactly 
means "no access except by *implied* permission".


--
Matthew

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

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH


On 30/08/2020 10.00, Greg Troxel wrote:

"Alex Weech" writes:

Another thing I just thought of over breakfast, in New Hampshire by
default private land has public access, and landowners have to post
that trespassing is not allowed. It could be that that's a quirk of
this part of the world, and other places don't have a posting
requirement, which is why there's some cultural disconnect.


It is likely the same law has Mass, but I think you have the details of
"public access" subtly wrong.  I think the law says:

   Being on someone's land without permission is trespassing, but this is
   not a crime.

   If it is posted, or you have been told, then it is a crime.

 From that, one can not conclude that "by default private land has public
access" in the OSM sense.  You can only conclude that "if you walk on it
you are not committing a crime".  In OSM, access=yes means "the public
has a legally-enshrined right of access", so not only can you go there,
but other people cannot tell you not to go there.  This notion of a
right is foundational to access=yes.

I agree we need a new tag.  As I see it

   access=yes

 legally-enshrined right of access, like a public street.  (Also used
 for private conservation land where the landowner invites the
 public, even though technically they could change the rules.)
 Perhaps shopping centers, even though not a right, it's close in
 practice.  Essentially always in truly public places.

   access=permissive

 no *right* of access, but generally understood that the landowner
 does not object to typical use.  Often on trails not near houses
 that cross private land, but without an easement.  Basically can
 only be added by a local because it is essentially never signed.

   access=private

 There is no right of access for random people.  There is no social
 expectation that it is reasonable for people to go there for for
 arbitrary purposes.  (For example, an actual neighbor coming to
 introduce themself, etc. is ok.)  This is the default assumption for
 driveways in New England - basically actual neighbors behaving in an
 actual neighborly way that they wouldn't mind someone else doing at
 their house is ok, deliveries ok, maybe gathering signatures for
 ballot access ok, and pretty much anything else not ok.


*You* may see it this way. The rest of the community does not.


   access=private
   sign:no_trespassing=yes

 Further means there is a no trespassing sign.

   (we already have a way to map gates.)

What is the actual problem with other people's driveways being marked
access=private on the map?  yes, driving on is usually technically not
illegal, but unless you are going there because you were invited for
have a reason they'd approve of, it's basically not ok.


The objection is that access=private currently *has* an understood 
meaning, and that meaning is *no* access without permission, not what 
you described above. I don't think it's reasonable to change that 
definition, as it would invalidate huge amounts of the map.


If access=destination is not acceptable, perhaps we need a new category.

--
Matthew

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

[OSM-talk] Mapping feature ideas (was: Funding of three infrastructure projects)

2020-08-04 Thread Matthew Woehlke


On 04/08/2020 11.08, Martin Koppenhoefer wrote:

On 4. Aug 2020, at 16:26, Matthew Woehlke wrote

Obviously, this would all almost surely be a temporary mode (maybe
it persists as long as JOSM is open, but isn't uploaded), but since
you usually draw once, that would be fine. (Bonus points if JOSM
could automatically recreate constraints for ways that don't have
any. It shouldn't be hard to guess equality, perpendicular and
colinear constraints, at least.)


rather than guessing, I sometimes have wished there had been a way to
actually store relationships (geometric) in the data, something like
these buildings all align their front facades, or this door (or
building position) is aligned to this street axis, etc., so when
people moved the street, the building would move as well. Would
become very complex if it would be used extensively (basically you
might move the whole city by moving a node, or it could lead to
unresolvable constraints, etc.), so I think it’s not gonna come. Just
accept some fuzziness ;-)


Sure, I can see the use. I was thinking in terms of things that can be 
done without schema changes.


Besides the troubles of trying to resolve an overconstrained system 
(something I've run into with FreeCAD for systems that are probably much 
more simple than what OSM might become!), another issue is that editors 
that don't support the constraints — I'm looking at iD, mostly because I 
shudder to think of the complexity and performance of implementing a 
solver in a web browser! — will tend to break them often. So, I'm not 
going to hold my breath ;-).



People are overrating rectangular buildings anyway, they might look
more correct than a freehand approximation, but they typically aren’t
(too short, too long, too wide, wrong angle not parallel to the
street, not parallel to their neighbors, etc.), sometimes resulting
from misinterpretation of aerial imagery and conscious or unconscious
generalization (representing with a single rectangle what in reality
is a rectangle with an oriel or a cutting or some other added shape).


Sure, I've seen some overly generalized buildings. I tend to model with 
more detail. (See for example 
https://www.openstreetmap.org/way/44931534, which is also a good example 
of where more constraints would have been useful; there are at least 
three axes of symmetry, and the four corners at the extrema of the 
longer axis *realy* look like they line up.) Still, we *do* tend to 
build things with right angles, so right angles are very often correct. 
At least for buildings. (Roads can easily get more sloppy.)



And sometimes a lack of diligence (e.g. when a building is on the
crossing of two roads which aren’t orthogonal, it is not unlikely
that the building isn’t orthogonal either, and it might be easily
visible in the imagery, but if you only have a hammer, you might be
tempted to use it for the screws as well).


Well, that's a user problem :-). I've also run into many, many instances 
of things that seem like they *ought* to line up, but if aligning is 
noticeably different from the imagery, I won't force it. Most of what 
I'm picky about is within individual buildings, or stuff like aligning 
parking aisles in the middle of the spaces because it renders better and 
the way is (since it's a line, not an area) necessarily an approximation 
anyway.


Conversely, I'll get a little more "sloppy" with placement, because I 
generally trace roof lines and then try to shift the shape to compensate 
for parallax and my best guess at how much the roof overhangs the wall. 
Again, see the previously cited example and compare how it lines up with 
the corners *on the ground* and not the roof line. See the adjacent 
https://www.openstreetmap.org/way/830822584 for an even more pronounced 
example; this one is straddling separate images that were stitched 
together, so there is a discontinuity in the parallax going through the 
middle of it. Constraints actually *help* here because I can make a 
reasoned guess at stuff like "these walls probably line up" and use that 
to try to deduce the actual shape when the imagery is messed up.


Of course, a lot of this will depend on the quality/resolution of the 
imagery available. On the US East Coast, MapBox is very high resolution, 
which help significantly. Trying to map to the level of detail I'm 
typically doing is probably not possible with lower resolution imagery.


--
Matthew

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-04 Thread Matthew Woehlke


On 04/08/2020 08.10, Martin Koppenhoefer wrote:

On 4. Aug 2020, at 13:58, Matthew Woehlke wrote:

but I would practically *kill* for JOSM to have FreeCAD's suite of sketch 
constraints ;-).


you’re aware that there are sketch constraints for configurable
angles (90, 60, 45 etc) and projection snaps? Hit 2 times „a“ (angle
display becomes green)
Yes. They're better than nothing, but nowhere near what I'm talking 
about. As an example, consider the attached simple FreeCAD sketch which 
is roughly representative of some buildings I've mapped recently. The 
dome in front is centered (segments on either side constrained to be 
equal). The "wings" in back are symmetrical.


It's *possible* to do this sort of thing in JOSM with a lot of care and 
by building part of the geometry, then constructing a bunch of "scratch" 
geometry in order to construct a symmetry line, then doing a copy, paste 
in place, mirror, reverse, stitch the parts together... but God help you 
if you make a mistake and have to start over.


In FreeCAD, you just slap on some equality constraints, angle 
constraints, parallel constraints, etc. and then you can *move* any of 
the nodes and everything else will update to preserve the applied 
constraints. (The one things it's missing that would be helpful is a 
*colinear* constraint; you have to simulate that with parallel and 
coincident constraints using "construction" lines; those are the blue 
ones. A colinear constraint could eliminate the need for those 
construction lines.) This is the major difference, though. In JOSM, 
constraints only apply when you initially draw something, so if you get 
it wrong, you have to start over. In FreeCAD, they're a dynamic system; 
if you get it wrong, just nudge it and the whole thing updates *while 
preserving your constraints*.


Oh, and *arcs*. The ability to define a segment that should be a perfect 
arc, and optionally make it tangent or perpendicular to its neighbors, 
would be a major boon. Again, I can fake it with a bunch of scratch 
construction, but if it's wrong, I have to start over and hope my next 
guess is better. In FreeCAD, just drag the end points until it looks right.


Then there are distance constraints, which would be incredibly useful if 
you're mapping something with known dimensions.


Seriously, give FreeCAD a spin. It's pretty awesome for this sort of 
relatively simple 2D stuff. Also look at some of the buildings I've done 
recently; the symmetrical ones don't just *look* symmetrical, they *are* 
symmetrical (within the limits of JOSM's abilities). I've also done a 
lot of stuff like roads that are perfectly centered in between parking 
spaces, groups of aligned buildings that are *actually* aligned, and 
whatnot. It's do-able, but it would be *s* much easier with 
FreeCAD-style constraints.


Obviously, this would all almost surely be a temporary mode (maybe it 
persists as long as JOSM is open, but isn't uploaded), but since you 
usually draw once, that would be fine. (Bonus points if JOSM could 
automatically recreate constraints for ways that don't have any. It 
shouldn't be hard to guess equality, perpendicular and colinear 
constraints, at least.)


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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-04 Thread Matthew Woehlke



On 04/08/2020 05.30, pangoSE wrote:
On older hardware like my 2 core 2ghz laptop iD is slow. Loading 
while saving an edit is slow, while JOSM is always fast and saving 
does not close the edit view so you can continue without waiting for

a browser to load the iD editor again which is also slow.
I want your JVM :-). I have yet to encounter a Java program (including 
JOSM) that isn't sluggish. (JOSM could be worse, but it's nowhere near 
what I'd expect from a well-written *native* application.)



Matthew Woehlke skrev: (3 augusti 2020 16:14:13 CEST)

(¹ iD can 'square up' individual nodes and does a passable job with
*mostly* orthogonal shapes with the odd 45° angle. There are ways to
work with those in JOSM, but generally speaking if you try to square a
shape with a single 'wild' node, JOSM turns the whole thing into a hot
mess.)


This sounds like a bug. Have you reported it?


Ah... I partially retract that. I think the problem is that I'm trying 
to make it work more like iD which permits *selective* squaring. I 
probably have some nodes selected that's making it go bonkers.


Really, this is a missing feature; I want a way to either square up 
individual nodes, or only angles that are within some delta of 90° 
already (and maybe to snap other angles to e.g. 45°).


Meanwhile, I've gotten better at creating scratch geometry to help with 
construction, but I would practically *kill* for JOSM to have FreeCAD's 
suite of sketch constraints ;-).


--
Matthew

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-03 Thread Matthew Woehlke


On 02/08/2020 06.05, Simon Poole wrote:

Extending this a bit further, you could just as well say, given that all
current and actively maintained general purpose editors require 1-2
FTEs, the OSMF should simply block all non-iD editors and tell the
developers to either work on iD or go home.


For OSMF *funding* purposes this might happen, but telling volunteers 
what they should or should not volunteer to work on should be a hard no-go.



iD is branching out in to more and more niches, reducing the
breathing space for anything else massively and other editor use has 
effectively been stagnating for a long time. While people will 
automatically try to start listing special use cases that can "only"

be done with editor XX, the problem is that these are special cases
and unlikely to be worth spending a couple of $100k on per year
(virtually or real) for the small number of users that will remain as
iD gains more and more features.


There are a few things iD does "better" than JOSM¹, but it is *far* from 
feature parity... and one use case which I consider *absolutely 
essential* before it could be considered a JOSM replacement is the 
ability to load and save local files (notably including shapefiles and 
geotiffs) and work on non-OSM layers... and I'm not sure that will ever 
happen. JOSM isn't "really" an OSM editor, it's a GIS tool that 
"happens" to have really good OSM integration. (Note also that these 
features are *mandatory* for doing imports from other GIS data.)


I've been using JOSM a lot lately, and AFAIK iD is quite some ways from 
matching even some of its more "basic" functionality. Angle constrained 
ways, lane view, way smoothing features, ability to mirror content 
(symmetry), and more. Relations are *much* easier in JOSM. Heck, just 
*selecting things* is much easier.


I'm not saying iD is *bad*. It's a very nice editor *for its 
capabilities*. It's great for making *small* changes or introducing 
someone to OSM editing... but there are a lot of use cases still where 
JOSM is just a far superior tool. Maybe in *5-10* years that will 
change, but I'm not going to hold my breath on it overtaking JOSM in 1-2.


(¹ iD can 'square up' individual nodes and does a passable job with 
*mostly* orthogonal shapes with the odd 45° angle. There are ways to 
work with those in JOSM, but generally speaking if you try to square a 
shape with a single 'wild' node, JOSM turns the whole thing into a hot 
mess.)


--
Matthew

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

[OSM-legal-talk] Disclaimer regarding data in Virginia (US)?

2020-07-20 Thread Matthew Woehlke

OSM surely incorporates data in Virginia which was not prepared by 
suitably licensed entities (per 
https://law.lis.virginia.gov/vacode/title54.1/chapter4/section54.1-402/).


According to Virginia law, OSM must therefore display the following notice:


Any determination of topography or contours, or any depiction of
physical improvements, property lines or boundaries is for general
information only and shall not be used for the design, modification,
or construction of improvements to real property or for flood plain
determination.
Is this notice already displayed somewhere? If not, where should it be 
displayed?


(Note: I came across this while considering PWC GIS data for import; 
n.b. 
https://wiki.openstreetmap.org/wiki/Contributors#Prince_William_County.)


--
Matthew

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

Re: [Talk-us] Labeling forestry service roads/tracks

2020-07-20 Thread Matthew Woehlke


On 19/07/2020 18.47, tj-osmw...@lowsnr.net wrote:

Editing in Boundary County, Idaho in the Panhandle, I've been extending
the forest landuse area around Bonners Ferry and have come across a
difficulty in classifying forest roads.

It seems that many have been automatically imported and have
highway=residential, which is just plain wrong.


FWIW, this seems to be endemic in TIGER data. I often suspect that 
everything that isn't a primary or secondary gets marked "residential".



For roads that appear metalled (paved) and/or access mines, quarries,
communication towers etc. I label highway=service, for roads that are
unpaved or sometimes seem to almost fade out I label highway=track. For
roads that appear to be public access (e.g. to go to a lake) but are
obviously even more minor than tertiary roads I label highway=unclassified.


Sounds about right, at least for the first and last. I'm less certain 
about "highway=track". (Not saying it's *wrong*, just that I don't know, 
vs. the others which sound correct to me.) Well, modulo Mike's comment; 
where I've been using "highway=unclassified" is for things that really 
don't look like service roads (e.g. that connect to other road networks) 
but likewise are clearly not residential. For example, 
https://www.openstreetmap.org/way/20453748.



TIGER seems to be at best very coarse, at worst fictional.


Yup, that is known to be the case. As I understand it, TIGER was created 
mainly for census-taking, and so as long as someone on the ground could 
look at the map and figure out more or less how to get to the houses on 
a particular road, that is "good enough". Positional accuracy in that 
respect isn't nearly as important as *connectivity* accuracy, which 
partly explains the quality, but even connectivity can be dodgy. (As you 
noted, it's not unusual to be missing entire roads, or to have roads 
that don't really exist, and that's *before* we start worrying about 
changes that have happened since.)


--
Matthew

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

Re: [Talk-us] [OSM-talk] private or not, USA ?

2020-07-17 Thread Matthew Woehlke


On 16/07/2020 21.06, Steve Friedl wrote:

On 16/07/2020 20.58, 80hnhtv4agou--- via Talk-us wrote:

Are wi-fi passwords and the IP number of a hot spot, located in MC Donald, 
burger-king, Starbucks,


Answering a different question than what you asked: they don’t belong in OSM, 
so any other answer is off topic.


...and in addition, yes, they are private. Such AP's are usually for 
customers only; said establishments will likely be very annoyed if you 
go around publishing their passwords. It may even be illegal to do so.


**DO NOT** add such information to OSM.

--
Matthew

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

Re: [Talk-us] [Imports-us] Interested in importing address points in New York State

2020-07-16 Thread Matthew Woehlke


On 16/07/2020 00.44, Skyler Hawthorne wrote:
Reading up on the import guidelines, I can see that the license is 
important. However, I am not able to see anything that explicitly states 
one way or another what kind of license the data sets are distributed 
under, and this whether or not it is compatible with the ODBL.


Hello again! Great to see someone else working in my neck of the woods!

If the site doesn't state clearly (an issue I had with Prince William 
County, VA, which I have been working on for job-related reasons), I 
would recommend contacting the data issuing agency. I see it's a .ny.gov 
site, so it's almost surely legitimate (plus it's hard to imagine 
someone making the effort to set up a scam site with enough content to 
not be obvious).


There are some form letters you can use to ask if the data is available 
under a compatible license, or you can just ask them to clearly indicate 
the license *or if the data is Public Domain*. In my experience, it may 
be helpful to ask up front for the contact to clearly state if the data 
is or is not PD.


As a disclaimer, I do this in my free time, which is in short supply, so 
progress on this would likely be slow. However, I would love if everyone 
could just search for any address and find it.


As someone who recently went looking and discovered that his former 
residence "doesn't exist" in OSM, I for one will be most gratified to 
see any improvements in the area :-).


--
Matthew

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

Re: [OSM-legal-talk] local copyright law on government data and OSM license

2020-07-16 Thread Matthew Woehlke


On 15/07/2020 21.16, Erwin Olario wrote:

Recently, some edits in the country came to the  attention of the community


When you say "the country", what country are we talking about?

I guess from context you mean "the Philippines", but you really ought to 
specify.


(I've been editing a bunch of stuff in PWC, Virginia, USA based partly 
on government data which I have been assured by the issuing agency is 
Public Domain. I *hope* you aren't talking about me, but it's really 
unclear.)


--
Matthew

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

Re: [Talk-us] Importing data for Prince William County, VA

2020-07-14 Thread Matthew Woehlke


On 13/07/2020 17.46, Mateusz Konieczny via Talk-us wrote:

Jul 13, 2020, 20:29 by mwoehlke.fl...@gmail.com:

It is still required to use a separate account for manually audited changes?


Is it going to be "by comparing dataset X and OSM I found places to map roads 
that I added
using aerial images"? Or more of "manually copied and verified geometries from 
external dataset"?


So far, I've done a bunch of stuff (on my own account) using the GIS 
data more as a supplemental reference layer, i.e. I haven't 
*technically* imported anything (but *have* hand-added some roads and 
other features and hand-edited others).


At some point, I am likely going to need to do a mass import of 
buildings, and that almost certainly *will* be an import.


--
Matthew

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

Re: [Talk-us] access=private on driveways

2020-07-14 Thread Matthew Woehlke


On 14/07/2020 09.44, Alex Hennings wrote:

Regarding:

a driveway to a house should not be tagged access=yes
because a no trespassing sign cannot be seen.  That is a complete
violation of verfiability, becuase the mapper has zero evidence that
access should be yes.

*Given our defaults, no access tag is equivalent> to that.*

You're saying *omitting* a tag violates *verifiability*. That doesn't
compute. Requiring tags to be verifiable with evidence specifically means
the opposite of that. But that might get us closer to the source of
disagreement. You and I interpret a *missing* access tag differently. *You
read a missing access tag to mean access=yes*. (Is there documentation to
support that somewhere? or... why do you think that?)


That's how iD represents it.

There is, of course, a solution to this... propose a new value with the 
appropriate semantics.


The (possible) problem with having access implied by service=driveway is 
that a lot of access roads to stores/businesses/offices are also 
service=driveway... although I suppose you could argue these have the 
same semantics; you shouldn't be using them unless you're actually going 
to the location to which they provide access. (Which isn't to say that 
no one ever violates this...)


--
Matthew

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

Re: [Talk-us] access=private on driveways (was: Deleting tiger:reviewed=no/addr:street for routes)


On 13/07/2020 15.16, Kevin Kenny wrote:

I'll confess to having perpetrated a fair number - at a time when I
didn't know better.


Likewise. That said...


A few things, though:

The immediate curtilage of a house is presumed to be private; at least
in the US, one does not drive or walk directly up to someone's house
without having business there. (Someone making a delivery, obviously,
has business there.)


...this seems to be the definition of access=destination? Is that the 
recommended way to tag residential driveways?



I haven't had any trouble getting OSMand to navigate to a house on a
road marked `access=private`. It pops up a warning that my destination
is on a private road, and asks whether it's OK to route over it - and
then does so happily.


My car does this, and doesn't even ask. It just warns me that "this 
route uses private roads". I generally assume that's talking about the 
final leg and ignore it.


I'm perfectly willing to believe that overzealous application of 
'private' breaks _some_ routing engines, but 'breaks routing for 
everyone' is a bit hyperbolic.


Yup. That said, it does seem like access=destination is more correct for 
ways that aren't explicitly access-restricted?


--
Matthew

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

Re: [Talk-us] Importing data for Prince William County, VA


On 13/07/2020 14.22, Mateusz Konieczny wrote:

If you are staying from manually reviewing
and editing based on this new data,
aerials and current data it should be
perfectly fine as long as you actually review
what you add.


For now, yes. For buildings (later, and I'll probably ping y'all again), 
I expect that to be more automated, but probably still manually reviewed.


It is still required to use a separate account for manually audited changes?

--
Matthew

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

Re: [Talk-us] Importing data for Prince William County, VA


On 13/07/2020 13.44, Mateusz Konieczny via Talk-us wrote:

Are you sure that it is in public domain?


It is according to the government POC.

https://lists.openstreetmap.org/pipermail/imports-us/2020-July/000954.html

--
Matthew

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

Re: [Talk-us] Importing data for Prince William County, VA


(Repost to talk-us also.)

On 13/07/2020 10.44, Matthew Woehlke wrote:
I am working on a project that wishes to tentatively use OSM data from 
Quantico and possibly surrounding areas. Unfortunately, OSM is somewhat 
lacking in this area, especially within Quantico itself.


I would like to import data from information provided by the county¹. To 
start with, I would like to use the country-provided roads to improve 
road shapes and fill in missing roads (for now, manually, probably using 
Merkaartor, and checked against available aerial imagery). Eventually, I 
want to add buildings and maybe anything else that seems useful.


Being data generated by an agency of the US government, the source data 
is Public Domain (verified via the contact information provided on the 
site).


Comments/concerns/objections/suggestions?

(¹ https://gisdata-pwcgov.opendata.arcgis.com/)




--
Matthew

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

[Talk-GB] Bus Routes on OSM

2020-07-06 Thread Matthew Scanlon

Hi,

How are Bus Routes added into OSM? I have noticed that bus routes in Basildon 
(my local area) are a few years out of date with some service such as the 5 and 
8Ahaving been  withdrawn and the route 2 being renumbered 28

Matthew Scanlon
Service Analyst (Journey Planner)
Technical Serivce Operations

Transport for London | 2Y4 2nd Floor 14 Pier Walk
Tel: Desk +44 (0) 203 054 3856 Internal: Desk 83856



***
The contents of this e-mail and any attached files are confidential. If you 
have received this email in error, please notify us immediately at 
postmas...@tfl.gov.uk and remove it from your system. If received in error, 
please do not use, disseminate, forward, print or copy this email or its 
content. Transport for London excludes any warranty and any liability as to the 
quality or accuracy of the contents of this email and any attached files. 
 
Transport for London is a statutory corporation whose principal office is at 5 
Endeavour Square, London, E20 1JN. Further information about Transport for 
London?s subsidiary companies can be found on the following link: 
http://www.tfl.gov.uk/corporate/about-tfl/
 
Although TfL have scanned this email (including attachments) for viruses, 
recipients are advised to carry out their own virus check before opening any 
attachments, as TfL accepts no liability for any loss, or damage which may be 
caused by viruses.
***
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] List moderator - volunteers needed

2020-03-14 Thread Matthew Newton

On Sat, 2020-03-14 at 12:21 +, Rob Nickerson wrote:
> Oops, I've just seen Matthew's post.
> 
> @Matthew: I agree, this is rare. Are you happy with continuing to
> support the talk-gb list on your own or will extra volunteers help?

Generally there's not anything to do, this is a well behaved list! So
it's not an arduous task. Like many subscribers I lurk more than post
these days, but do follow what's going on every day or two.

Just happen to be ill for the last couple of days so taking a while to
get anything done, then needed the password reset (which is also an
indication of how much "looking after" this list usually needs!)

Matthew



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

Re: [Talk-GB] List moderator - volunteers needed

2020-03-14 Thread Matthew Newton

On Sat, 2020-03-14 at 12:16 +, Rob Nickerson wrote:
> 
> Are we allowed to know the person's name? The wiki refers to Matthew
> Newton but I wasn't sure if this was still correct.

Yup, that's still my name. :)

Cheers,

Matthew



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

[Talk-GB] Abusive posts

2020-03-14 Thread Matthew Newton

Hi all,

Seen all the messages. Apologies for the delay in sorting this.

In all the years I've been monitoring this list I don't ever recall
seeing behaviour like that. It most certainly isn't acceptable. Minor
disagreements at times, sure, but outright abuse is way over the top.

He's gone.

Cheers,

Matthew



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

Re: [Talk-ca] Importing buildings in Canada

2020-01-04 Thread Matthew Darwin


Hello all,

Happy to see progress here.

My ongoing question is how to define that a "local" group has 
determined that an import can proceed.   And more specifically what is 
"local"? There are rural and remote parts of Canada which have in the 
order of zero active mappers or sense of a local community.  How do we 
consensus around imports there? Can we get agreement by (part-of) 
province/territory where there is not some other group that puts their 
hand up?  (maybe use admin level 5 boundaries, with holes for big cities)


I just want to make sure we don't stop at doing imports only for big 
cities. Buildings are important for the whole country.


On 2020-01-04 10:09 a.m., Nate Wessel wrote:


Hi Daniel,

Thank you for all the work you've put into this. I'd like to offer a 
couple suggestions and/or clarifications for your proposed import 
process, overview though it is.


First, I think it is very important that a tasking manager is set up 
on a city/by city basis only, and that only AFTER consensus is 
achieved that the import should proceed in that area. I would really 
like to avoid seeing the massive nationwide tasking that was set up 
the first time around. We should be making it hard for people to go 
rogue in regions where consensus for an import doesn't (yet) exist.


Related to this, though important enough to be a second point in 
it's own right, the tasking squares need to be small enough that a 
single user can manage them and inspect every single building in a 
task. The first round of import used task squares that were massive, 
and which couldn't be divided any further past a certain point. Even 
in rural areas, it is likely inappropriate to import areas larger 
than 1km^2. In central Toronto it would be (and was) idiotic. An 
import that doesn't take local scale into account shouldn't proceed. 
"Too big to load into JOSM" is about 100x too big to import in my 
opinion and is not a good enough benchmark for import batch sizing.


That is, each import needs to be local, and not just in a 
superficial sense.


I'll also add that the issue of conflation doesn't seem to have been 
worked out yet except to note that it is an issue. What will we do 
with the millions of buildings which will substantially 
overlap/duplicate existing buildings or imports? This needs to be 
worked out in detail before anything starts up again.


And what needs to be done about already existing low quality 
imports? It's good to acknowledge their existence, but what will be 
done about them? We've set up a task to clean up some of the mess in 
Toronto ( http://tasks.osmcanada.ca/project/168 ) but this is only 
the tip of the iceberg.


Again, I thank everyone for their time and effort on this - we can 
get this done if we go slow and do it right :-)


Best,

Nate Wessel, PhD
Planner, Cartographer, Transport Nerd
NateWessel.com 

On 2020-01-03 3:40 p.m., Daniel @jfd553 wrote:


Bonjour groupe, mes excuses pour ce très long courriel !-)

I have reviewed everything that has been written on the ODB import 
(aka Canada Building Import) in Talk-ca and the wiki. I proposed 
changes to some wiki pages (via talk tabs) to ease the discussions 
about this import and the following. Now, in order to restart the 
import, here are some thoughts and a proposal on how to proceed to 
complete the task.


*1. Issues with the ODB Data Import*

Many concerns were raised about the import. One major concern was 
to obtain local communities’ buy-in in the Canadian context. 
Another concern was to improve the quality of the data prior the 
import. The following paragraphs intend to clear most of these 
concerns.


*1.1. Which data import project?*

According to the import guidelines (steps 3 & 4), a data import 
explicitly refers to a single data source (ODB in our case). 
Discussions about the availability and quality of Microsoft or ESRI 
data, while interesting, are not relevant as they should be dealt 
with as other import projects.


*1.2. What has been imported so far?*

According to what I found [1], the ODB import is completed for 21 
municipalities. These imports seem to have kept OSM content’s 
history, at least for the samples checked, but many problems were 
found. In some case, the imports brought swimming pools in OSM 
because they were included in the dataset (e.g. Moncton). In other 
cases, importing buildings with accurate locations (XY) over 
content mapped from less accurate imagery resulted in buildings 
that now overlap the street network (e.g. Squamish). It means that 
all these 21 imports need to be carefully re-examined and corrected 
as required.


For 12 other municipalities, the import is partial, either 
suspended as requested, or because previous imports had already 
provided most of the buildings (often from the same municipal 
provider). That said the import will definitely improve OSM 
accuracy and completeness if done properly.


*2. How should ODB Data be imported?*

I will

Re: [Talk-ca] Saints in street names in Ontario

2019-09-24 Thread Matthew Darwin

Hi,

It sounds fine for me.

On 2019-09-10 7:54 a.m., john whelan wrote:
Looks good to me and if Matthew has cast his eye over it and not 
spotted anything major then I think we can safely say Ottawa is 
happy with it.

Cheerio John

On Mon, Sep 9, 2019, 9:57 PM Pierre Béland via Talk-ca, 
mailto:talk-ca@openstreetmap.org>> wrote:

Cela semble bien préciser, mais les collègues d'Ontario pourront
mieux répondre.

Pierre

Envoyé à partir de Yahoo Courriel sur Android

<https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>

Le lun., sept. 9 2019 à 3:11 PM, Jarek Piórkowski
mailto:ja...@piorkowski.ca>> a écrit :
Hi Pierre,

(I responded via email at first, but realized one more thing, so
adding on and sending to talk-ca:)

The proposed wiki addition does start with "In Ontario". However
thanks bringing this up, as I realized I forgot to account
for parts
of Ontario where streets will be named in French - this
change should
not apply to those.

I am changing the suggested wording to:

    In parts of **Ontario** that primarily name streets in
English,
street and road names containing initial "St." or "St"
should only be
expanded to "Saint" when "Saint" is common usage for that
street. To
be clear, this overrides the general rule

https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
for "St." which does not stand for "street". As with other
names in
OSM, factors you might want to consider when determining
common usage
include spellings posted on street signs ("on the ground" rule),
spellings used in local media, GeoBase street name data, and
spellings
used by official municipal sources including open data
datasets. See
discussion on talk-ca [0].

Would this wording be fine for Ottawa and other bilingual
areas, or am
I missing a pitfall?

Thanks,
--Jarek

On Mon, 9 Sep 2019 at 08:51, Pierre Béland
mailto:pierz...@yahoo.fr>> wrote:
>
> Marek
>
> Ces instructions ne s'appliquent pas à toutes les
provinces. Il faudrait donc indiquer sur la page wiki à
quelles provinces elles s'appliquent
>
> Pierre
>
> Envoyé à partir de Yahoo Courriel sur Android
>
> Le lun., sept. 9 2019 à 2:51 AM, Jarek Piórkowski
> mailto:ja...@piorkowski.ca>> a écrit :
> Hello,
>
> I'm following up on the thread about saints and lack
thereof in street
> names from a couple of months ago (see archives [1] [2]).
>
> I would like to suggest the following wording added to
Canadian
> tagging guidelines at
>

https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Street_names
> :
>
>    In Ontario, street and road names containing initial
"St." or "St"
> should only be expanded to "Saint" when "Saint" is common
usage for
> that street. To be clear, this overrides the general rule
>

https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
> for "St." which does not stand for "street". As with other
names in
> OSM, factors you might want to consider when determining
common usage
> include spellings posted on street signs ("on the ground"
rule),
> spellings used in local media, GeoBase street name data,
and spellings
> used by official municipal sources including open data
datasets. See
> discussion on talk-ca [0].
>
> where [0] would be a link to this message/thread archive.
(Comments on
> the wording and suggestions appreciated!)
>
> Is anyone opposed to this change?
>
> I have attempted to advertise/announce this proposed
change. This was:
> - posted in this mailing list in March/April of this year
(some quoted
> below, see list archives for more discussion)
> - I posted a note
https://www.openstreetmap.org/note/1741334 in
> Toronto with a link to this thread (supportive responses
from Kevo and
> DannyMcD)
> - on April 10, sent a message [2] with a link to the note
to editors

[Talk-ca] OSMOSE change: split on admin_level=5 boundaries in Québec

2019-09-11 Thread Matthew Darwin


Hello,

Just a note to advise that OSMOSE QA tool now has smaller areas to 
process in Québec rather than one area for the entire province. The 
tool is now using the admin_level=5 boundaries.  This follows the same 
change done for Ontario earlier this year. The reason to split up a 
province into multiple pieces is to allow faster processing time.


OSMOSE Canada QA is run from a server located in Gatineau, Québec.

QA status: 
http://osmose.openstreetmap.fr/en/control/update_matrix?remote=07e9 
(value represents the time since last update, is in days)


Issue Map: 
http://osmose.openstreetmap.fr/en/map/#zoom=9=46.04=-74.32


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

Re: [Talk-ca] Inconsistencies in names for admin_level=5 boundaries in Québec

2019-09-02 Thread Matthew Darwin


Merci Pierre.

On 2019-09-02 12:13 p.m., Pierre Béland wrote:

Bonjour Matthew,

l'Office de toponomie du Québec (http://www.toponymie.gouv.qc.ca) 
que nous utilisons comme référence pour les noms de lieux au Québec 
publie une page avec les noms de régions 
http://www.toponymie.gouv.qc.ca/ct/normes-procedures/regles-ecriture/comment-ecrire-region-administrative-touristique.html




vs m-dash vs n-dash to separate names (compare 
Gaspésie–Îles-de-la-Madeleine vs Abitibi-Témiscamingue)


Les noms sont écrits avec des tirets plutot que des espaces, et les 
noms composés de deux sous-régions sont séparés par double tiret.


- Saguenay–Lac-Saint-Jean qui regroupe Saguenay et Lac-Saint-Jean  
(j'ai corrigé selon commission de toponymie et enlevé espace blanc)

- Gaspésie–Îles-de-la-Madeleine

Il y a une exception semble-t-il à la règle (ou oubli?) pour 
Abitibi–Témiscamingue,


vs bracketed numbers appended to the name (Laval, Montréal)
Noms + Numéro, lorsque ville et région portaient le même nom, j'ai 
ajouté le no. de région

- Laval (13)
- Montréal (06)

vs spaces between names (compare Abitibi-Témiscamingue vs Saguenay - 
Lac-Saint-Jean


on devrait enlever les espaces

Pierre


Le lundi 2 septembre 2019 11 h 24 min 08 s UTC−4, Matthew Darwin 
 a écrit :



Hello,

I was looking at the admin_level=5 boundaries in Québec, and I 
notice they appear to not be named consistently (list below).  
Possible issues:


  * m-dash vs n-dash to separate names (compare
Gaspésie–Îles-de-la-Madeleine vs Abitibi-Témiscamingue)
  * spaces between names (compare Abitibi-Témiscamingue vs Saguenay
- Lac-Saint-Jean
  * bracketed numbers appended to the name (Laval, Montréal)

I am not an expert in how admin_level=5 boundaries in Québec, were 
setup, so I am just going to point out the difference here and leave 
it to someone else to adjust as necessary.


(The reason I'm looking at this is to consider to make Québec 
regsion into multiple parts for faster processing in OSMOSE, based 
on admin_level=5)



Abitibi-Témiscamingue
Bas-Saint-Laurent
Capitale-Nationale
Centre-du-Québec
Chaudière-Appalaches
Côte-Nord
Estrie
Gaspésie–Îles-de-la-Madeleine
Lanaudière
Laurentides
Laval (13)
Mauricie
Montérégie
Montréal (06)
Nord-du-Québec
Nunavik
Outaouais
Saguenay - Lac-Saint-Jean

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

[Talk-ca] Inconsistencies in names for admin_level=5 boundaries in Québec

2019-09-02 Thread Matthew Darwin


Hello,

I was looking at the admin_level=5 boundaries in Québec, and I notice 
they appear to not be named consistently (list below). Possible issues:


 * m-dash vs n-dash to separate names (compare
   Gaspésie–Îles-de-la-Madeleine vs Abitibi-Témiscamingue)
 * spaces between names (compare Abitibi-Témiscamingue vs Saguenay -
   Lac-Saint-Jean
 * bracketed numbers appended to the name (Laval, Montréal)

I am not an expert in how admin_level=5 boundaries in Québec, were 
setup, so I am just going to point out the difference here and leave 
it to someone else to adjust as necessary.


(The reason I'm looking at this is to consider to make Québec regsion 
into multiple parts for faster processing in OSMOSE, based on 
admin_level=5)



Abitibi-Témiscamingue
Bas-Saint-Laurent
Capitale-Nationale
Centre-du-Québec
Chaudière-Appalaches
Côte-Nord
Estrie
Gaspésie–Îles-de-la-Madeleine
Lanaudière
Laurentides
Laval (13)
Mauricie
Montérégie
Montréal (06)
Nord-du-Québec
Nunavik
Outaouais
Saguenay - Lac-Saint-Jean

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

[Talk-ca] Phone number quality checks

2019-03-16 Thread Matthew Darwin


Hello all,

OSMOSE now has validations for phone numbers in Canada.

http://osmose.openstreetmap.fr/en/errors/?country=canada_%2A=2500=3092

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

[Talk-ca] Business Improvement Area tagging

2019-01-07 Thread Matthew Darwin


Hello all,

I'm not sure if this applies to other provinces or not, so I thought I 
would ask here.


In Ontario there is a concept of "Business Improvement Area" ("BIA" 
for short) that has the power to tax businesses within their zone  
(see http://www.mah.gov.on.ca/Page1529.aspx for details).


I want to tag these in OSM, so then you can run a query to find all 
businesses within a BIA. Sometimes the boundaries of the BIA are very 
tight and just cover things that are actual businesses, and sometimes 
the boundaries of a BIA are very loose and cover lots of area 
including residential... and when a new business comes up later in 
that area it automatically is a part of the BIA.


I am thinking that the *relation type=boundary, 
boundary=local_authority *might be applicable here, and define either 
a Canada specific definition maybe just Ontario, depending if the 
concept exists elsewhere.


I would like to get people's opinion on this idea  Or please 
suggest something else.



https://wiki.openstreetmap.org/wiki/Tag%3Aboundary%3Dlocal_authority

 * type =boundary
   
 * boundary
   =local_authority
 * name =*
 * local_authority:CA
   
=BIA


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

Re: [Talk-ca] canvec imports

2018-11-28 Thread Matthew Darwin


Andrew,

Keep up the great work making OSM great for Canada.


On 2018-11-27 1:36 p.m., Andrew Lester wrote:
I agree. A selective import from CANVEC is fine and generally gives 
good results. As long as you don't import things like forests and 
buildings (which are both woefully out-of-date, broken, or outright 
wrong), there usually isn't a problem. However, if someone just 
imports an entire block of data without inspecting it, that's when 
we run into the visible issues that the peanut gallery picks apart.


Andrew
Victoria, BC

--
*From: *"James" 
*To: *"Andrew" 
*Cc: *"talk-ca" 
*Sent: *Tuesday, November 27, 2018 9:58:19 AM
*Subject: *Re: [Talk-ca] canvec imports

not sure why Canvec always gets shat uppon, their water features are 
great and pretty accurate, the forest/landcover on the other hand 
needs fixing before import. I think it's clear enough on the canvec 
wiki page that only experienced mappers/importers should attempt a 
canvec import.


___
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?

2018-11-02 Thread Matthew Darwin


Of course.

Could use the ottawa import approach:  "leave existing buildings alone".

Matthew Darwin
matt...@mdarwin.ca
http://www.mdarwin.ca

On 2018-11-02 7:03 p.m., OSM Volunteer stevea wrote:

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
___
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?

2018-11-02 Thread Matthew Darwin

I think we should identify who would like to be involved in import for 
each municipality.  (on a wiki page). On the page, identify roles, 
like:


 * coordinator
 * import data preparation
 * QA
 * import execution
 * data enrichment (commercial, residential, etc... tagging)
 * etc..

Then we can see where we have gaps and how to fill them.  Perhaps some 
municipalities have local mappers who will be happy to do the tagging 
of building type (and can do some validation if the buildings look 
right), but no technical capability to execute the actual import.  And 
maybe some folks who did imports before will help areas where we have 
no technical expertise.



On 2018-11-02 6:58 p.m., 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.

Thanks

Cheerio John

Pierre Béland wrote on 2018-11-02 6:35 PM:

Pour le Québec, je retrouve les données de plusieurs municipalités
Montréal, Longueuil, Repentigny, Shawinigan, Québec et Rimouski.

Première observation rapide, aussi, elles sont de bonne qualité et 
proviennent je suppose des cadastres des municipalités. En milieu 
urbain, cela facilite beaucoup l'identification des immeubles 
juxtaposés.


Je vois ailleurs, aux États-Unis notamment avec les données de 
Microsoft, que les projets sont par région ou municipalité.


Je pense qu'il faut éviter un projet trop centralisé tant pour 
assurer un meilleur contrôle du déroulement dans chaque 
municipalité, région que pour permettre aux communautés des 
provinces et communautés locales de s'impliquer.


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.


Le rôle de cette liste doit être un forum pour supporter les 
communautés des provinces et communautés locales. C'est une 
occasion de dynamiser ces communautés avec un projet très 
intéressant. De là, ils auront le goût de compléter la carte pour y 
décrire les infrastructures locales.


Si trop de tâches sont initiées en parallèle sur un gestionnaire de 
tâches, il sera très difficile de coordonner, assurer le suivi, une 
progression coordonnée. Il faut éviter que des mapathons ou 
organisations externes s'invitent pour collaborer à de telles 
tâches avec les milliers et milliers de personnes qui viennent 
jardiner quelques heures sans organisation / formation réelle et 
laissent ensuite le tout sans dessus, dessous.


--
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

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

2018-09-15 Thread Matthew Darwin

 Forwarded Message 
Subject:BC2020i - update Sept 2018
Date:   Thu, 13 Sep 2018 13:54:41 +
From:   Alasia, Alessandro (STATCAN) 
To: many

Dear all,

I hope you had a good and relaxing summer. I imagine this email will 
find you all back in the office or at your activity.

I have been in touch with many over the summer and I know that 
numerous things are moving and brewing, which is great! At our end we 
have continued working on our open database of building (we expect 
this to be shared soon). It has now passed the 4.3 million mark for 
number of building footprints.

In terms of *updates from our end*, we recently established a 
collaborative agreement with the Bing Maps team (Microsoft) in the 
hope that, by joining forces and avoiding duplication of efforts, what 
they did in the US can be replicated in Canada (see 
https://blogs.bing.com/maps/2018-06/microsoft-releases-125-million-building-footprints-in-the-us-as-open-data). 
Additionally, we started a dialogue with OpenAddresses to explore 
collaborations and, most recently, began work on an Open Business 
Repository, which mimics the approach of OpenAddresses but uses open 
business records. The preliminary results on these and other open data 
explorations are very encouraging.

In various conversations, I learned that a lot of great work has been 
done at your end as well! And talking with some of you, *the idea of a 
second meeting on the topic of BC2020i has been tossed around*. Since 
the initiative has matured, slowly but surely, I think it would be 
great to get together again, take a stock of where we are at, and see 
what the next steps could be. Like last year, I think we may be able 
to offer the venue.

With that said, if a second meeting (say “*BC2020i-2*”) is organized, 
I would hope it to be a bit more focused. An ideal outcome coming out 
of BC2020i-2 could be the following:

·Stronger buy-in from some of the key federal departments interested 
in building data

·Greater involvement (maybe sponsorship J?) from some of the key 
players in the private sector who have shown a great interest in 
supporting open data platforms, which could help smaller businesses, 
NGOs, and students/academics to become more involved.

·More awareness and highlighting of some of the 
local-municipal-regional initiatives. I heard of very interesting work 
happening in the Niagara region, for instance. And same for the work 
that has been done by many academic departments (I just had a chat 
with a graduate student from the University of Waterloo who is 
researching the BC2020i)

·And of course, it would be great if this could be an opportunity to 
solidify the presence of OSM-Canada in the institutional arena (as an 
institutional player as well?)

One way to re-think BC2020i is by placing it in the context of a *data 
co-op*. And now that this initiative is past its infancy, how can we 
solidify this data co-op for the benefit of all?

It would be great if we can share ideas on all of the above. My team 
and I remain committed to facilitating this and moving the discussion 
forward. Ideally, *we could target a date in January 2019* for a 
second meeting. Ottawa is such a lovely place to visit in that 
season…we have a frozen canal and beaver tails! – the latter being 
essentially a flat doughnut.

Looking forward to hearing from you,

Alessandro and the DEIL-Team

*PS.*Over the fall my team and I will present our work on open data as 
well as make reference to the ideas of BC2020i in many different 
places and we hope to see you in person at some of these events. In 
particular we will be at:

·Sept 28 - Open First Day  – Ottawa

·Oct 26-28 – People, Places, and Public Engagement Conference - St. 
John’s, NFL

·Nov 6-9 - StatCan International Methodological Symposium - Ottawa

·Nov 7-9 – CODS18  - Niagara Falls (to be 
confirmed)

·Nov – GIS Day – probably at McGill- Montreal (to be confirmed)

·A longer list of seminars and workshops with Fed Departments

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

Re: [Talk-ca] Trans-Canada Highway research

2018-04-27 Thread Matthew Darwin


Hi Olivia,

I spent some fixing tags on TCH ways in *Ontario* in the last few 
weeks.  Do an overpass query on nat_name=Trans-Canada Highway in 
Ontario (see below).


Is it possible to build a query that shows ways with 
nat_name=Trans-Canada Highway and not part of the relation, and 
vice-versa.  It would make the task of fixing the routes easier.  Also 
if the query was built into OSMOSE or another error checker then we 
can have some hope it is less likely to get out of sync in the future.


Also it is not clear if Highway 17A is part of the TCH or not.  
Wikipedia says yes, comments in OSM say it is not.  Some research is 
needed here I guess.


I am willing to help in Ontario.

[out:xml][timeout:100];
{{geocodeArea:Ontario}}->.searchArea;
(
way["nat_name"](area.searchArea);
);
(._;>;);
out meta;

On 2018-04-27 05:37 AM, Olivia Robu - (p) wrote:


Hello,

  Regarding our proposal for Trans-Canada Highway, we came with the 
Wiki page on OSM, as we promised, where we listed all the relations 
that  make up the Trans-Canada Highway. Also, we inserted a status 
column where all of you can see the situation of every relation, 
whether it is broken or not. Here is the link to the Wiki page: 
https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Trans-Canada_Highway. 
*Also, we want to ask you if any of you are willing to help us fix 
the broken relations and keep the wiki page updated with the current 
status?* *After we collect some feedback from you, we want to get 
involved in correcting the broken relations and we will send you an 
update of our progress. *


As we have discussed in the other mails, we want to update 
Trans-Canada Highway (ID 1307243). This will not affect the 
currently existing routes, but it will have the same geometry and 
the following tags:


   type=route

route=road

name=Trans-Canada Highway

 name:fr=Route Transcanadienne - we propose this new tag 
for the route name (as we seen that is used only for the way) due to 
the Francophone provinces through which this new route passes.


Regards,

Olivia

*From:* Olivia Robu - (p)
*Sent:* 29 martie 2018 09:42
*To:* 'talk-ca@openstreetmap.org' 
*Subject:* RE: [Talk-ca] Trans-Canada Highway research

Hello,

Thank you for your feedback, it has been very helpful. In relation 
to that we come with another proposal: to update the super relation 
(https://www.openstreetmap.org/relation/1307243)  from the east to 
west of Canada, that includes all the routes and has the folowing tags:


type=route

route=road

   name=Trans-Canada Highway

name:fr=Route Transcanadienne - we propose this new tag for the 
route name (as we seen that is used only for the way) due to the 
Francophone provinces through which this new route passes


Regarding the way name tag and the ref we won't make any changes. 
Also, for the route type (motorway, trunk, primary, secondary, 
teriary) we will ask for your advice for specific cases.


For the broken relations of Trans-Canada Highway we will create a 
wiki page on OSM where we will describe each route and put a status 
of the relation and a comment box for all the members from our 
community to see and maybe help us to fix this problem.


We will come back with un update for the wiki page.

Regards,

Olivia Robu



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


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

[Talk-ca] Fwd: Re: Building Canada 2020 (BC2020i) - update Dec 20, 2017

2018-03-30 Thread Matthew Darwin

Forwarded message...

Subject:Re: Building Canada 2020 (BC2020i) - update Dec 20, 2017
Date:   Fri, 30 Mar 2018 13:21:22 -0500
From:   keith hartley 

Hi building 20/20 list
Last Friday I worked with one of my colleagues and a high school 
teacher to map out some things on openstreetmap with high school 
students!

To do this we talked about what would work with the high school 
curriculum, and with an OSM component. We agreed to look at something 
with built environments and some of the limitations people may have 
accessing them. This class has some GIS teaching behind them.

Last Wednesday Rob brought in a person from the City of Brandon to 
talk about what the city is doing about accessibility. Then he gave 
the students an assignment to capture if a building was accessible 
over the next few days.

Once they came back on the Friday I did a talk on openstreetmap, some 
of the benefits of open data they could use for school work, and how 
osm is helping out across the world (HOT mapping, ect). As most of the 
buildings were already there we didn't need to add a lot to the map. 
The students used the same login (issue with students having their 
accounts and privacy)  and used iD editor to add if buildings they 
looked at were wheelchair accessible or not. In some cases they 
building wasn't there, so I added the basic how to add a building, 
square it, satellite alignment and other editing tasks they might use.

In the future we'll probably use field papers to do a larger project 
(the field papers server was down that day!) and be a little more 
ambitious.

I looked over the data later to see if everything made sense and the 
jokes were corrected (one student edited the Robs house to be a fish 
food restaurant).

Although small, it was pretty successful way of getting secondary 
students into mapping with a guided approach.

A secondary added bonus was city of Brandon provided data, however 
need to sort out licensing stuff before adding anything to the map.

Cheers,
Keith

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

Re: [Talk-ca] Trans-Canada Highway research

2018-03-26 Thread Matthew Darwin

I should clarify my comment below that in some places the "local road 
name" is "Trans-Canada Highway".



I think it would be helpful if you split out your proposal province by 
province.  Provincial governments are generally responsible for 
highways (including the TCH), so the naming is consistent only within 
a province.  Please review 
https://en.wikipedia.org/wiki/Trans-Canada_Highway


On 2018-03-26 09:25 AM, Matthew Darwin wrote:


  * Another question is related to the priority of the names in the
name value tag and also for the ref tag. If we have a way that
has a street name (“Old Highway 16” or “North York River Road”)
and two routes that overlap (ex: Trans-Canada Highway and
Highway 11). What is the name and the ref that should appear in
the way name tag and ref tag?



Highway 11.  Local road first.


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

Re: [Talk-ca] Trans-Canada Highway research

2018-03-26 Thread Matthew Darwin


On 2018-03-26 07:20 AM, Olivia Robu - (p) wrote:


Hello,

The Telenav Map team has done some research on the status of the 
ways and relations of Trans-Canada Highway.


Here are some conclusions from this research:

  * The highway is formed from 30 routes;



The Trans-Canada highway is not really 1 highway, so this is probably 
not surprising.   In many places, the Trans-Canada highway splits in 
2, so probably cannot have 1 route anyway.


  * Every route has different names for the name tag, such as:
street names, other routes names or Trans-Canada highway name in
different forms;
  * The issue above is repeating for the ref tag;



IMO the routes and the refs need to match, or the refs need to be 
removed given that routes should supersede refs.  In my investigations 
in Ontario I see lots of places where routes and refs don't match.


  * The name of Trans-Canada highway has more than one form
(Trans-Canada Highway, TransCanada Highway, Trans Canada
Highway, etc);



Probably good to standardize that.  However, in Quebec I would think 
the French name would take precedence. "/Route Transcanadienne"/



  * Another issue is the variety of names in other tags related to
it (such as: name:en, name:fr, alt_name, alt_name:en,
alt_name:fr, nat_name);
  * There are some routes that don’t have a route name only ref (5
routes);
  * There are some routes that overlap:
  o in Manitoba: - PTH 1 (MB Trans-Canada Highway) and
Trans-Canada Highway (Super);

- Yellowhead Highway and PTH 16 (MB Trans-Canada Highway);

  o in Alberta: Trans-Canada Highway (AB) and Trans-Canada
Highway (Super);
  o in British Columbia: - Trans-Canada Highway (BC, Super) and
Trans-Canada Highway;

  * About 90% of these routes are broken;
  * About 80% of these routes have highway value flip flop
(motorway, trunk, primary);



Highway 17 in Ontario is not a motorway.  So I would expect different 
segments to be different.  Highway 417 (motorway) changes to Highway 
17 (trunk) just west of Arnprior Ontario.  This is correct.


We propose to make some improvements to standardize all the routes. 
We would like to get your thoughts and feedback on the following 
questions:


  * What is the correct form for the name that appears in the way
name tag? For example: “Highway 417” is part of Trans-Canada
Highway and has the name value tag “Highway 417”. To resolve
this issue, we would need to standardize the ways’ name tag for
all the provinces. The question is, should we modify the way
names in to “Trans-Canada Highway”, or should we insert the name
“Trans-Canada Highway” at the end of the name, like this:
“Highway 417 (Trans-Canada Highway)”, or should we leave it like
it is?



No, definitely not.


 *


  * Another issue is related to the official name of the highway.
According to our research the official name for Trans-Canada
Highway is “Trans-Canada Highway”. In our research we have found
several forms of this name: TransCanada Highway, Trans Canada
Highway, etc. Should we change all the names to “Trans-Canada
Highway”?


In Quebec probably "/Route Transcanadienne"/


 *


  * Another question is related to the priority of the names in the
name value tag and also for the ref tag. If we have a way that
has a street name (“Old Highway 16” or “North York River Road”)
and two routes that overlap (ex: Trans-Canada Highway and
Highway 11). What is the name and the ref that should appear in
the way name tag and ref tag?



Highway 11.  Local road first.


 *


  * In case of overlapping identical routes (ex: in Manitoba there
is two routes for Trans-Canada Highway). What should be the best
approach?

The Trans-Canada Highway has multiple routes.  It is not one highway.  
The graphic on wikipedia, probably shows this clearly. 
https://en.wikipedia.org/wiki/Trans-Canada_Highway


 *


  * In case of highway value flip flop (motorway, trunk, primary),
there are several segments like this outside the cities (ex.:
Route “Ontario Highway 17 (Blind River to North Bay) (ID
3739829)”, or Route “Trans Canada Highway 104” (ID 1732797)).
For areas outside the cities we propose to change the highway
value into motorway/trunk. What do you think about this issue?



If it is really a motorway, yes.  But many places outside of cities it 
is not a motorway.


 *


We think that one approach to resolve the first problem could be to 
add “Trans-Canada Highway” or “Highway 417 (Trans-Canada Highway)” 
to the way name for all the routes, and the ref number correspondent 
to each route that forms the Trans-Canada Highway.




You could add an alt_name or similar tag.


We look forward to hearing your feedback and hope to improve the 
situation together.


Here is the link to github ticket that we created: 
https://github.com/TelenavMapping/mapping-projects/issues/57





Highway 17 just west of

Re: [Talk-ca] Poorly drawn buildings #GEOG231-W18; #BC2020; #UCalgary-GEOG231; #BC2020-UCalgary

2018-03-21 Thread Matthew Darwin

Today I found that people using the same hashtags 
(#GEOG231-W18;#BC2020;#UCalgary-GEOG231;#BC2020-UCalgary) are drawing 
buildings on top of each other.  Eg duplicates. Using ID editor.  
There appears to be an ongoing problem here.


On 2018-03-19 10:53 AM, john whelan wrote:
I think Pierre has already identified the problem some time ago and 
it has been raised with Stat Can and others who are involved with 
BC2020 not that anyone admits to being responsible for BC2020 and 
Geoweek. So hopefully we won't be adding more low quality buildings.


Cheerio John

On 19 March 2018 at 10:42, Matthew Darwin <matt...@mdarwin.ca 
<mailto:matt...@mdarwin.ca>> wrote:


Hi all,

I noticed some poorly drawn (not-square) buildings in Calgary
tagged with the hashags
#GEOG231-W18;#BC2020;#UCalgary-GEOG231;#BC2020-UCalgary. If you
are involved in this project, you might want to review the
quality. I added a "fixme" tag to the problems I happen to notice.

___
Talk-ca mailing list
Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-ca
<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] Cleanup of addr:country, addr:province, addr:state

2018-03-19 Thread Matthew Darwin


Pierre,

This is a good idea, and I plan to do it.   My current challenge is to 
know what things people think "need correction".  I'm starting these 
discussions to see if there is any consensus before I go writing 
code.  If you (or anyone else) has ideas, please do post here (or 
email directly).  Obviously I will not re-build tools that already 
exist, but rather focus on Canada-specific issues (eg postal code format).


The checks I made for the City Of Ottawa are here: 
http://matthew.davintech.ca/osm/.  I will be able to re-use some of 
what I have done for Ottawa, but based on the discussion so far on 
talk-CA, the list of things that /might/ need correction is less than 
what the local community in Ottawa might consider as /possible/ issues 
for correction.


My current employer is in Montréal (previous one was in Joliette) and 
I regularly work out of Université du Québec en Outaouais so hopefully 
you'll consider me part of the local community in Quebec, even though 
I live in Ontario.  :-)



On 2018-03-10 03:27 PM, Pierre Béland wrote:


Pour revenir aux suggestions de Matthew, de façon à impliquer / 
motiver les communautés locales, ce serait d'offrir les outils et 
listes d'objets à corriger un peu comme le fait Osmose et autres 
outils de QA.




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

Re: [Talk-ca] Cleanup of addr:country, addr:province, addr:state

2018-03-19 Thread Matthew Darwin

Searching on "110 Laurier Avenue West, on" in Nominatim already works 
(it finds Ottawa City hall) even though the address has no 
addr:province tag for City Halle.  So I don't think this is a good 
reason to be adding addr:province/addr:province:short_name tags. IMO.  
Unless there is another use case I am missing.  Similarly your example 
of searching for "Toronto, ON" works fine.


I'm guessing this works because the Ontario admin relation has 
ISO3166-2 tag of CA-ON




On 2018-03-10 04:51 PM, Pierre Béland wrote:

Non, inutile si relations. Dans relation province d'Ontario
- ajouter short_name='ON'.

De cette façon, Recherche Toronto, ON
devrait fonctionner. A essayer :)


Pierre


Le samedi 10 mars 2018 15:39:53 HNE, john whelan 
 a écrit :



So you're suggesting adding short_name='ON' to ones that have 
addr:province=Ontario


How would that work?

addr:province=Ontario
addr:province:short_name=ON ?

Merci John



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

[Talk-ca] Poorly drawn buildings #GEOG231-W18; #BC2020; #UCalgary-GEOG231; #BC2020-UCalgary

2018-03-19 Thread Matthew Darwin


Hi all,

I noticed some poorly drawn (not-square) buildings in Calgary tagged 
with the hashags 
#GEOG231-W18;#BC2020;#UCalgary-GEOG231;#BC2020-UCalgary.  If you are 
involved in this project, you might want to review the quality. I 
added a "fixme" tag to the problems I happen to notice.


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

Re: [Talk-ca] Cleanup of addr:country, addr:province, addr:state

2018-03-08 Thread Matthew Darwin



So I've tidied up the addr:province/state tags, now using only 
addr:province, leaving anything that would be generally considered 
"correct" either spelt out in full or using English provincial 
abbreviation as you might use in a mailing address. Also left "Quebec" 
(no accent).
I would rather like to clean this up further, however, I have stopped 
just at tidying up things that were mis-spelt or had inconsistent case.


Is there any view on where to go next?

These are the current counts:

69008   Nova Scotia
39668   ON
33280   British Columbia
 7788   Alberta
 6584   AB
 4771   BC
 4520   Québec
 3772   Ontario
 2791   QC
 2140   NB
 1744   SK
 1285   NU
 1066   NL
 1022   Manitoba
  879   New Brunswick
  527   Quebec
  307   PE
  234   NS
  222   MB
  163   Saskatchewan
   23   Nunavut
   14   NT
   11   YT
    9   Yukon
    3   Northwest Territories

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

Re: [Talk-ca] Building Footprint Upload to OSM

2018-03-07 Thread Matthew Darwin


Rob,

One other thing to think about while others are discussing the 
licensing topic:  What is the quality of the buildings?  Has that been 
reviewed?


 * Are they in the right place?
 * Are they the right size?
 * Are they squared off (rectangles)
 * Are they aligned to each other and the road (not slightly mis-aligned)
 * Are they current (not buildings which have been torn down or
   otherwise changed)
 * If there are attributes like "height" in your dataset, is that
   accurate?
 * etc...

I've not worked much on buildings, but probably others could add 
comments about what are the criteria for "good buildings".



On 2018-03-06 11:05 AM, Rob Halko wrote:


Good morning,

The Region of Durham has recently purchased Building Footprints data 
for the entire Region, and it is available as Open Data: 
http://opendata.durham.ca/datasets/building-footprints


We would like to import these to Open Street Map to engage the 
community and help improve the overall map. We are supporters of OSM 
and wish to regularly partner in improving the data.


In particular, we are hosting a mapathon on March 29, which asks for 
student input to add attributes to the buildings based on OSM 
guidelines for the Building Canada 2020 project: 
https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Building_Canada_2020#The_data_that_could_be_mapped


We have read your Import guidelines and are here to express our 
interest in contributing our building data. The intention is not to 
overwrite those buildings that the community has built, but bridge 
the gap to include the rest of the 200,000+ buildings in Durham 
(largely residential), which are missing from OSM.


Please let us know how we can contribute this valuable data on 
behalf of the community.






*Rob Halko | Supervisor, GIS*
Regional Municipality of Durham | Corporate Services - Information 
Technology

905-668-4113 ext 2189 | Mobile: 289-927-7168
Corporate Values: • Ethical Leadership • Accountability • Service 
Excellence • Continuous Learning and Improvement • Inclusion


THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND 
MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, 
CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT 
PRIVACY LEGISLATION. No rights to any privilege have been waived. If 
you are not the intended recipient, you are hereby notified that any 
review, retransmission, dissemination, distribution, copying, 
conversion to hard copy, taking of action in reliance on or other 
use of this communication is strictly prohibited. If you are not the 
intended recipient and have received this message in error, please 
notify me by return e-mail and delete or destroy all copies of this 
message.



___
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] Emergency Request for Tasking Manager Trainer

2018-03-07 Thread Matthew Darwin


[prune CC list so this gets posted to the list]

Hi Jonathan,

I'm probably missing something, but you don't link training videos 
from the tasking manager.   The tasking manager is about splitting up 
some pre-defined mapping jobs (eg trace outline of building from bing 
satellite image), into small chunks that people can finish in a short 
amount of time.  So people don't work on things other people are 
already working on.


If people are adding what they already know, then you don't need a 
tasking manager. People just go ahead and add it, if it is not already 
there (checking if it is already there is important so we don't get 
duplicate things).  Presumably beginners are only going to add one 
thing at a time in ID editor, and they're all in the same room, so 
scope for conflict is small (easily solved with everyone announcing 
what they are doing before starting it).


For your session later this month, it sounds to me like you want 
someone to


 * introduce the topic of mapping in OSM
 * introduce the ID editor
 * go through some samples of things to be added
 * then everybody get on their laptop and start trying to edit
   things, with the leader checking what is going on

(this is how my introductory session went last April when I joined a 
meetup group in Ottawa)


The task manager is not needed in this scenario.

But please correct me if I totally missed your point.

On 2018-03-07 08:55 AM, Jonathan Brown wrote:


We want to run the mapathon by setting up a task in the Tasking 
Manager with links to the OSMLearning video tutorials and use cases 
for the instruction section. We want to make the task as simple as 
possible (e.g., adding points of interest based on participants’ 
local knowledge augmented with information from social services and 
NGOs who will be participating).


The goal is to have the participants apply OSM morning training to a 
problem solving task in the afternoon, similar to what Sterling 
Quinn did for the Philly Fresh Food Mapathon: 
http://2017.phillytechweek.com/events/philly_mapathon


We would need to add tasks to the OSM Tasking Manager that encompass 
the school boards and schools within the geography to be mapped - 
Durham Region, Niagara Region, Northumberland County, and Greater 
Peterborough area. For March 29 the priority is for Durham Region 
and Northumberland County.


We are looking for a train-the-trainer model for 8-10 facilitators 
(teachers, senior secondary and postsecondary students) that can be 
repurposed for other mapathon events this spring and fall.


There will be a follow-up event in the early fall. We are exploring 
ways to build this type of mapathon event into the workflows of the 
educational and local planning structures and processes at the 
municipal and regional level. Alessandro and his colleagues at the 
TB Open Data branch are well aware of what we are trying to do.


Jonathan

*From: *Matthew Darwin <mailto:matt...@mdarwin.ca>
*Sent: *Tuesday, March 6, 2018 9:06 PM
*To: *Jonathan Brown <mailto:jonab...@gmail.com>; 
talk-ca@openstreetmap.org <mailto:talk-ca@openstreetmap.org>

*Cc: *Brock Baker <brock_ba...@kprdsb.ca> <mailto:brock_ba...@kprdsb.ca>
*Subject: *Re: [Talk-ca] Emergency Request for Tasking Manager Trainer

Hi Jonathan,

Are you trying to set up the tasking manager, or you just want to 
add a project to the existing tasking manager 
http://tasks.osmcanada.ca/? If you describe the details of what 
you're trying to accomplish (look at existing tasks), then someone 
can probably add a task for you.


Or do you want to know how to run a mapathon using the task manager?

Or?

A bit more details of what you're trying to do would be helpful...




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

Re: [Talk-ca] Emergency Request for Tasking Manager Trainer

2018-03-06 Thread Matthew Darwin


Hi Jonathan,

Are you trying to set up the tasking manager, or you just want to add 
a project to the existing tasking manager http://tasks.osmcanada.ca/?  
If you describe the details of what you're trying to accomplish (look 
at existing tasks), then someone can probably add a task for you.


Or do you want to know how to run a mapathon using the task manager?

Or?

A bit more details of what you're trying to do would be helpful...


On 2018-03-05 10:15 PM, Jonathan Brown wrote:


We have an event coming up that the Durham Region Open Data folks 
have kindly offered to host. We are looking for a Tasking Manager 
trainer to train OSM facilitator for the day and/or provide a 
morning session training to beginner mappers from four to five high 
schools in the area. There will be a follow-up event in early fall 
as well, so this is not intended to be a one-off event. Any help 
would be most appreciated. Here is a link with the details for March 
29:


https://docs.google.com/document/d/1S3RYIVxAEe_1c_vIQcwwMg3dChU4K-szcR8NdQsjvak/edit

Jamie, feel free to contact me offline if you have any suggestions. 
I was at the Toronto OSM Meetup this evening and your name came up.


Jonathan Brown

*From: *talk-ca-requ...@openstreetmap.org 


*Sent: *Monday, March 5, 2018 7:01 AM
*To: *talk-ca@openstreetmap.org 
*Subject: *Talk-ca Digest, Vol 121, Issue 13

Send Talk-ca mailing list submissions to

    talk-ca@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit

https://lists.openstreetmap.org/listinfo/talk-ca

or, via email, send a message with subject or body 'help' to

    talk-ca-requ...@openstreetmap.org

You can reach the person managing the list at

    talk-ca-ow...@openstreetmap.org

When replying, please edit your Subject line so it is more specific

than "Re: Contents of Talk-ca digest..."

Today's Topics:

   1. weeklyOSM #397 2018-02-20-2018-02-26 (weeklyteam)

   2. hebdoOSM Nº 397 2018-02-20-2018-02-26 (weeklyteam)

--

Message: 1

Date: Sun, 04 Mar 2018 10:47:03 -0800 (PST)

From: weeklyteam 

To: talk-ca@openstreetmap.org

Subject: [Talk-ca] weeklyOSM #397 2018-02-20-2018-02-26

Message-ID: <5a9c3f27.55e01c0a.1d2c5.6...@mx.google.com>

Content-Type: text/plain; charset="utf-8"

The weekly round-up of OSM news, issue # 397,

is now available online in English, giving as always a summary of 
all things happening in the openstreetmap world:


http://www.weeklyosm.eu/en/archives/10075/

Enjoy!

weeklyOSM?

who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages

where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3


--

Message: 2

Date: Mon, 05 Mar 2018 00:10:53 -0800 (PST)

From: weeklyteam 

To: talk-ca@openstreetmap.org

Subject: hebdoOSM Nº 397 2018-02-20-2018-02-26

Message-ID: <5a9cfb8d.51bbdf0a.960f4.3...@mx.google.com>

Content-Type: text/plain; charset="utf-8"

Bonjour,

Le résumé hebdomadaire n° 397 de l'actualité OpenStreetMap vient de 
paraître *en français*. Un condensé à retrouver sur :


http://www.weeklyosm.eu/fr/archives/10075/

Bonne lecture !

hebdoOSM ?

Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages

Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3


--

Subject: Digest Footer

___

Talk-ca mailing list

Talk-ca@openstreetmap.org

https://lists.openstreetmap.org/listinfo/talk-ca

--

End of Talk-ca Digest, Vol 121, Issue 13





___
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 in Ontario

2018-02-25 Thread Matthew Darwin

ownship Of Prince
    182 Township Of Dubreuilville
    170 Township of Ashfield-Colborne-Wawanosh
    154 Township of MacHin
    142 Township of Tudor and Cashel
    141 Township Of Machin
    140 Township Of Fauquier-strickland
    132 Township Of Val Rita-harty
    126 Township Of White River
    122 Township Of Larder Lake
    116 Township Of Mattice-Val Côté
    112 Township of Carlow/Mayo
    110 Township of Nairn and Hyman
    104 Township of Sioux Narrows-Nestor Falls
    102 Township Of Matachewan
    101 Township of Conmee
    100 Township Of Whitewater Region
 89 Township of O'Connor
 88 Township of Baldwin
 87 Township of Tehkummah
 58 Township of Joly
 57 Township of Gordon
 55 Township Of Schreiber
 54 Township of Faraday
 42 Township Of Opasatika
 36 Township of Chisholm
 26 Township of James
 22 Township of Burpee and Mills
 12 Township of South Algonquin
 12 Township of North Algona Wilberforce
 12 Township of Killaloe, Hagarty and Richards
 12 Township of Greater Madawaska
 10 Township Of Faraday
  6 Township of Brudenell, Lyndoch and Raglan
  4 Township Of Sables-spanish Rivers
  3 Township of Wilmot
  2 Williamsford (Township of Chatsworth)
  2 Township of the North Shore
  1 Township of North Dumfires
  1 Township of North Dumfies
  1 Township of Chatsworth (Williamsford)
  1 Township of Cavan Monaghan
  1 Township of Adjala-Tosorontio (Rosemont)

    790 District of Thunder Bay
    508 District of Parry Sound
    471 District Of Kenora
    384 District Of Algoma
    264 District of Sudbury
    186 District of Algoma
    185 District of Kenora
    128 District Of Timiskaming
    119 District Of Thunder Bay
    108 District Of Sudbury
 61 District Of Cochrane
 43 District of Timiskaming
 28 District of Nipissing
 15 District of Manitoulin

   6909 County of Brant

   1056 Village of Merrickville-Wolford
    592 Village of Casselman
    551 Village of Point Edward
    330 Village of South River
    254 Village of Oil Springs
    252 Village of Sundridge
    208 Village of Newbury
    204 Village of Burk's Falls
    174 Village of Westport
    112 Village Of Hilton Beach

 and I think that's it for Ontario.


On 2018-02-23 11:50 AM, Matthew Darwin wrote:


I will leave the wonky towns (the ones that have parentheses) for 
cleanup later.  The other "Town Of" are done.


I am working on "Municipality Of" now.




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

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

2018-02-23 Thread Matthew Darwin

I will leave the wonky towns (the ones that have parentheses) for 
cleanup later.  The other "Town Of" are done.


I am working on "Municipality Of" now.

On 2018-02-18 11:04 PM, Matthew Darwin wrote:


Hi Bill,

Thanks for the feedback.  OSM is updated accordingly.

I also changed "City of Prince Edward County" to "Prince Edward" (I 
didn't receive any comments on that one).   "City Of" updates in 
Ontario is now complete (at least until someone adds another one).


Updates to "Town Of" are now in  progress.   If anyone has comments 
about how to handle the following please do speak up:


   3053 Town of the Blue Mountains   => "Blue Mountains"  [remove "the"]
 14 Town of Caledon (Bolton)
  2 Town of Whitchurch-Stouffville (Stouffville)
  2 Town of Caledon (Sandhill)
  1 Town of Saugeen Shores (Southampton)
  1 Town of Mono (Rosemont)
  1 Town of Huntsville (Port Sydney)
  1 Town of Clarington (Enniskillen)

Following towns, I will be updating "Municipality Of" (after that 
"Township Of").  The list for "Municipality Of" is:


  22881 Municipality of Chatham-Kent
   9906 Municipality of Clarington
   3962 Municipality of West Grey
   3929 Municipality of Grey Highlands
   3815 Municipality of Kincardine
   3690 Municipality of Trent Hills
   3549 Municipality of Leamington
   3543 Municipality of Middlesex Centre
   3293 Municipality of Port Hope
   3284 Municipality of North Grenville
   3192 Municipality of Brockton
   2794 Municipality of Meaford
   2793 Municipality of Highlands East
   2706 Municipality of Arran-Elderslie
   2462 Municipality of Thames Centre
   2439 Municipality of the Nation
   2418 Municipality of Tweed
   2320 Municipality of Southwest Middlesex
   2275 Municipality of Brighton
   2194 Municipality of North Perth
   2145 Municipality of Northern Bruce Peninsula
   1981 Municipality of Central Elgin
   1634 Municipality of South Bruce
   1501 Municipality Of Greenstone
   1462 Municipality of Marmora and Lake
   1424 Municipality of Oliver Paipoonge
   1374 Municipality of Hastings Highlands
   1265 Municipality of Centre Hastings
   1227 Municipality of West Nipissing
   1197 Municipality of Brooke-Alvinston
   1168 Municipality of Bayham
   1060 Municipality of Whitestone
   1015 Municipality of McDougall
    989 Municipality of French River
    943 Municipality of Wawa
    895 Municipality of Magnetawan
    817 Municipality of Shuniah
    790 Municipality of Lambton Shores
    710 Municipality Of Markstay-warren
    665 Municipality of Neebing
    634 Municipality Of Huron Shores
    460 Municipality of West Elgin
    414 Municipality of Huron Shores
    367 Municipality of Dutton/Dunwich
    293 Municipality Of St.-charles
    281 Municipality of Powassan
    236 Municipality of North Middlesex
    165 Municipality of Killarney
 47 Municipality Of West Nipissing
 46 Municipality Of Charlton And Dack
 23 Municipality Of Wawa
 18 Municipality of Callander
  7 Municipality Of Sioux Lookout
  4 Municipality Of Killarney
  2 Municipality Of French River
  1 Municipality of Brockton;Municipality of South Bruce


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

Re: [Talk-ca] Expanding vs abbreviating

2018-02-20 Thread Matthew Darwin

Maybe the wiki needs updating, because it doesn't align with this 
discussion:


https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines


   Street names

Many Canadian cities and towns use the grid based structure, the 
presence of numbered streets and avenues is very common.


/Suggestion:/ Name these streets/avenues with the full name (such as 
51st Street Northeast) and let the renderer sort out the abbreviation 
where required. Where the numbering system ends below 30, consider 
spelling out the numbers.




Matthew Darwin
matt...@mdarwin.ca
http://www.mdarwin.ca

On 2018-02-20 09:20 PM, Stewart C. Russell wrote:

On 2018-02-20 01:15 PM, Viajero Perdido wrote:

But if that changes it so it's no longer "the name", logically that rule
doesn't apply.

It seems that in the US cities in OSM that I've looked at, mappers have
been fairly (but not completely) consistent in using full quadrant
names: Northeast, Northwest, …

Quadrant addresses in Canadian cities seem to be almost perfectly
consistent in using NE, NW, …

I must admit, the US map looks very strange with the words spelled out
in full.

  Stewart



___
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

2018-02-19 Thread Matthew Darwin

I have summarized the discussion we had here over the last week or so  
on https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines for 
easy reference in the future.  It is:



   Municipality Names

Municipality names are to be spelt according to how they are listed in 
NRCan (http://www4.rncan.gc.ca/search-place-names/search) or other 
official source. That means:


 *

   Do not include "City of", "Municipality of" or similar in the name
   unless that is officially part of the name.   "Village of Queen
   Charlotte" (BC) is correct, "City of Toronto" is incorrect (should
   be "Toronto").

 *

   Do not expand "St." to "Saint" or "Ste" to "Sainte" just to
   conform to OSM's "don't abbreviate names" rule. If the city name
   is normally has it expanded, then it is maintained as expanded in
   OSM. If it is not normally expanded, then it is not expanded in
   OSM. "Saint John" (NB) and "St. John's" (NL) are both correct.


Feel free to clarify further on the wiki or continue the discussion 
here...



Matthew Darwin
matt...@mdarwin.ca
http://www.mdarwin.ca

On 2018-02-19 06:33 PM, Stewart C. Russell wrote:

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.

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.

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.

  Stewart

___
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] Cleanup of addr:country, addr:province, addr:state

2018-02-19 Thread Matthew Darwin


Hi John,

If we want to be able generate mailing addresses from OSM (is that a 
valid use case?), then whatever the city address Canada Post thinks we 
are in needs to be tagged in some fashion.   Google maps and Bing maps 
both think I'm in "Kanata".  OSM thinks I'm in "Kanata North". Both 
are correct, in different ways.


If I we want to do reverse geo coding using OSM data, then the mailing 
address should be represented in some fashion because that's what 
people expect to see.


https://wiki.openstreetmap.org/wiki/Key:addr says about addr:city: 
/May not be required if boundary=administrative 
<https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative> is 
used correctly. May or may not be a clone of is_in:city 
<https://wiki.openstreetmap.org/wiki/Key:is_in:city>=* (in some places 
the city in the address corresponds to the post office that serves the 
area rather than the actual city, if any, in which the building is 
located)! The name of the city as given in *postal addresses* of the 
building/area. /(emphasis added)



BTW, this is one of the reasons I started all these discussions about  
aligning Canada OSM data... I was trying to use OSM to build a map for 
a community group and rather than just doing post-cleanup work on the 
map data in my own private copy, I thought it might be better to see 
what data we could align and make useful for everyone.  I'll only take 
it as far as consensus is achieved.



On 2018-02-19 11:25 AM, john whelan wrote:
So what we are saying is the city field should be filled in not with 
the physical city but with Canada Posts thoughts of the day?


Orleans is different.  It never was a municipality.

Cheerio John

On 19 February 2018 at 11:17, Matthew Darwin <matt...@mdarwin.ca 
<mailto:matt...@mdarwin.ca>> wrote:


Hi John,

I live in Kanata.  If I type my "  Ottawa" into
the Canada Post lookup tool
(https://www.canadapost.ca/cpo/mc/personal/postalcode/fpc.jsf?LOCALE=en
<https://www.canadapost.ca/cpo/mc/personal/postalcode/fpc.jsf?LOCALE=en>),
it helpfully corrects me to "Kanata".   Same for old "City of
Nepean" addresses.   Try "1000 Palladium Drive, Kanata, ON"
(Canadian Tire Center).

As far as I know, within the City of Ottawa, everyone's postal
address uses the pre-amalgamted city names while the city hasn't
yet finished de-duplicating street names.   So addr:city should
probably be filled in accordingly.


On 2018-02-19 11:07 AM, john whelan wrote:

I seem to recall from talking to Canada Post that Orleans is
the only location for which that is true.  All of Orleans is
located within Ottawa. So how do you tag it?  It is within the
City of Ottawa these days.

Thanks John

On 19 February 2018 at 10:44, Matthew Darwin
<matt...@mdarwin.ca <mailto:matt...@mdarwin.ca>> wrote:

Hi Clifford,

(It was good to meet you at SOTM US last year).

Thanks for your comments... The situation with addr:city
appears to me to be more complex than the situation with
addr:province/addr:country, along the lines of what you are
mentioning. My personal home mailing address cannot be
resolved in OSM because the mailing address does not match
any of the boundaries.  (OSM boundaries are correct, but
the official post address cannot be resolved from the
boundaries). So I have a feeling that addr:city is going to
be required, at least in some cases.

Do you have a view on addr:province/addr:state or
addr:country? US/Canada probably have more similarities
than differences, so your input is very welcome.







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

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

2018-02-18 Thread Matthew Darwin


Hi Bill,

Thanks for the feedback.  OSM is updated accordingly.

I also changed "City of Prince Edward County" to "Prince Edward" (I 
didn't receive any comments on that one).   "City Of" updates in 
Ontario is now complete (at least until someone adds another one).


Updates to "Town Of" are now in  progress.   If anyone has comments 
about how to handle the following please do speak up:


   3053 Town of the Blue Mountains   => "Blue Mountains" [remove "the"]
 14 Town of Caledon (Bolton)
  2 Town of Whitchurch-Stouffville (Stouffville)
  2 Town of Caledon (Sandhill)
  1 Town of Saugeen Shores (Southampton)
  1 Town of Mono (Rosemont)
  1 Town of Huntsville (Port Sydney)
  1 Town of Clarington (Enniskillen)

Following towns, I will be updating "Municipality Of" (after that 
"Township Of").  The list for "Municipality Of" is:


  22881 Municipality of Chatham-Kent
   9906 Municipality of Clarington
   3962 Municipality of West Grey
   3929 Municipality of Grey Highlands
   3815 Municipality of Kincardine
   3690 Municipality of Trent Hills
   3549 Municipality of Leamington
   3543 Municipality of Middlesex Centre
   3293 Municipality of Port Hope
   3284 Municipality of North Grenville
   3192 Municipality of Brockton
   2794 Municipality of Meaford
   2793 Municipality of Highlands East
   2706 Municipality of Arran-Elderslie
   2462 Municipality of Thames Centre
   2439 Municipality of the Nation
   2418 Municipality of Tweed
   2320 Municipality of Southwest Middlesex
   2275 Municipality of Brighton
   2194 Municipality of North Perth
   2145 Municipality of Northern Bruce Peninsula
   1981 Municipality of Central Elgin
   1634 Municipality of South Bruce
   1501 Municipality Of Greenstone
   1462 Municipality of Marmora and Lake
   1424 Municipality of Oliver Paipoonge
   1374 Municipality of Hastings Highlands
   1265 Municipality of Centre Hastings
   1227 Municipality of West Nipissing
   1197 Municipality of Brooke-Alvinston
   1168 Municipality of Bayham
   1060 Municipality of Whitestone
   1015 Municipality of McDougall
    989 Municipality of French River
    943 Municipality of Wawa
    895 Municipality of Magnetawan
    817 Municipality of Shuniah
    790 Municipality of Lambton Shores
    710 Municipality Of Markstay-warren
    665 Municipality of Neebing
    634 Municipality Of Huron Shores
    460 Municipality of West Elgin
    414 Municipality of Huron Shores
    367 Municipality of Dutton/Dunwich
    293 Municipality Of St.-charles
    281 Municipality of Powassan
    236 Municipality of North Middlesex
    165 Municipality of Killarney
 47 Municipality Of West Nipissing
 46 Municipality Of Charlton And Dack
 23 Municipality Of Wawa
 18 Municipality of Callander
  7 Municipality Of Sioux Lookout
  4 Municipality Of Killarney
  2 Municipality Of French River
  1 Municipality of Brockton;Municipality of South Bruce

On 2018-02-17 02:18 PM, Bill & Kathy Patterson wrote:

I can speak to Maple, living a few km north of it.  The OSM wiki states:
—CLIP—
Use place <https://wiki.openstreetmap.org/wiki/Key:place>=suburb to 
identify a major area in a place 
<https://wiki.openstreetmap.org/wiki/Key:place>=town 
<https://wiki.openstreetmap.org/wiki/Tag:place%3Dtown> or place 
<https://wiki.openstreetmap.org/wiki/Key:place>=city 
<https://wiki.openstreetmap.org/wiki/Tag:place%3Dcity> with a 
distinct and recognised local name and identity. Suburbs may have 
uncertain boundaries, may overlap with other suburbs, and are often 
best mapped using a node.
For areas within a suburb, the tag place 
<https://wiki.openstreetmap.org/wiki/Key:place>=neighbourhood 
<https://wiki.openstreetmap.org/wiki/Tag:place%3Dneighbourhood> will 
usually be used. If necessary, place 
<https://wiki.openstreetmap.org/wiki/Key:place>=quarter 
<https://wiki.openstreetmap.org/wiki/Tag:place%3Dquarter> may be 
used for an area of a large settlement which is smaller than a 
suburb and larger than a neighbourhood.

—END CLIP—
and on that basis I'd say yes, Maple is definitely a suburb of 
Vaughan, as are 1/2 of Thornhill, Concord, Woodbridge, and 
Kleinburg.  Purpleville and Nashville should likely be classified as 
neighbourhoods, and Hope and Burrlington (note double "r") as 
pioneer communities.


16796 Town of Markham, has been a city for a few years.

Bill Patterson

--
*From:* Matthew Darwin <matt...@mdarwin.ca>
*To:* talk-ca@openstreetmap.org
*Sent:* Saturday, February 17, 2018 11:43 AM
*Subject:* Re: [Talk-ca] Formatting of Municipality Names in Ontario

The following 2 are not changed, as per my previous comment that I 
will not update the name if it does not exist in NRCan without 
further review here.


1)  3 Ci

Re: [Talk-ca] Formatting of Municipality Names

2018-02-16 Thread Matthew Darwin

In my OSM map updates to remove of "City of" and similar prefixes from 
locality names, I will not be expanding any "St", "Ste" or any other 
abbreviations of those names.  If the name (minus the prefix to be 
removed) matches what is in NRCan database, I will remove the prefix; 
if it doesn't, I will bring it back up here for review.


I occasionally get "Saint John, NB" and "St. John's, NL" confused, so 
personally I do not want the city name in Newfoundland expanded to add 
to my confusion.   :-)


What's your favourite locality name in Canada?  I have to go with 
"Saint-Louis-du-Ha! Ha!"


On 2018-02-16 05:56 PM, Jarek Piórkowski wrote:
With "street" in a street name, it's clear to most everyone that 
Pine St is an abbreviation and Pine Street is the correct 
unabbreviated Canadian English version. It is not clear to me that 
"Saint Catharines" is the correct unabbreviated version of the 
city's name. In fact it looks incorrect to me.


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

Re: [Talk-ca] Formatting of Municipality Names

2018-02-16 Thread Matthew Darwin

To start the cleanup process, the following *Ontario* cities are being 
changed (remove "City of" or "City Of").   Once that is done, I'll 
come back with the next batch to process...


The idea to remove the city name in its entirety will require careful 
consideration to ensure the necessary boundary relations are in place 
and of course more discussion to see if people are comfortable to 
proceed on that kind of activity.


 110707 City of Toronto
  45716 City of Hamilton
  27234 City of London
  25393 City of Brampton
  17251 City of Vaughan
  16929 City of St. Catharines
  16592 City of Kawartha Lakes
  16087 City of Thunder Bay
  14787 City of Niagara Falls
  13966 City of Kingston
  12085 City of Oshawa
  11321 City of Barrie
  10981 City of Burlington
  10347 City of Guelph
   9666 City of Brantford
   9384 City of Sarnia
   9102 City of Windsor
   9044 City Of Sault Ste. Marie
   8263 City of Peterborough
   7819 City of Quinte West
   7593 City of Welland
   6753 City of Pickering
   6608 City of Greater Sudbury
   6375 City Of Greater Sudbury
   6239 City of Belleville
   6165 City of Prince Edward County
   5696 City of Cornwall
   5269 City Of Timmins
   4877 City of Port Colborne
   4208 City of Woodstock
   3971 City of Thorold
   3692 City of St. Thomas
   3603 City of Cambridge
   3529 City of Orillia
   3355 City of Brockville
   3098 City of Owen Sound
   2733 City of Clarence-Rockland
   2377 City Of Pembroke
   1549 City Of Dryden
    871 City of Kenora
    766 City Of Elliot Lake
    544 City of Elliot Lake
    302 City of Waterloo
    241 City of North Bay
 78 City of Kitchener
 47 City of Markham
 18 City of Timmins
  3 City of Vaughan (Maple)
  2 City of Sault Ste. Marie



On 2018-02-12 09:13 PM, Kevin Farrugia wrote:
Bernie is correct.  "City of", "Municipality of", "x County" is a 
legal name that would be referring to the legal entity itself (the 
Government) rather than the place.  The place should just be 
Toronto, Hamilton, Mississauga etc..


The data source these legal names comes from has the legal name as 
it's usually establishing the jurisdiction that contains the road.  
The address ranges are derived from the road system, so it's just 
been copied over.


-Kevin Farrugia
kevinfarru...@gmail.com 

On 12 February 2018 at 21:02, 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

Bernie.

On Mon, Feb 12, 2018 at 7:45 PM, OSM Volunteer stevea
>
wrote:

I smell a harmonization with admin_level...not that there's
anything wrong with that.
SteveA

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





-- 
Bernie Connors

New Maryland, NB

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





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


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

[Talk-ca] Cleanup of addr:country, addr:province, addr:state

2018-02-16 Thread Matthew Darwin


Hi all,

During the discussion of cleaning up municipality names in Canada, it 
was suggested that the addr:city could be removed entirely if the 
appropriate boundaries are defined.   I would hazard to guess (and 
will endeavour to investigate) that the addr:city and the boundaries 
do not always align in Canada (there are ~11300 administrative 
boundaries of some type and there are ~7000 unique addr:city tags)... 
so this will be a much more long term effort.


However, the provincial/territorial boundaries are defined, so 
removing the addr:country, addr:provice and addr:state tags might be a 
more reasonable at this time.  (addr:country is used ~94% less than 
addr:street)


Tags, by number of occurrences:

 167902 addr:country

  33252 addr:state

 179741 addr:province

2950115 addr:city

2942159 addr:street

2934341 addr:housenumber


--
Matthew Darwin
matt...@mdarwin.ca
http://www.mdarwin.ca

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

Re: [Talk-ca] Postal Code cleanup

Task complete.   The multi-postal codes are tagged on buildings which 
may have more than 1 address.  Local mappers who are familiar with the 
areas should review it.   It looks like in many places imports were 
used which incorrectly parsed the addresses.  Many issues where the 
value started with 2 letters representing the province and then an 
incomplete postal code (aka "AA A#A").


 248803 "A#A #A#"    1455 "A#A"  14 "A#A #A#;A#A #A#"   1 
"A#A #A#;A#A #A#;A#A #A#"


(my initial query was incomplete, that's why the numbers are much bigger now... 
I was querying the postal codes where also there is a contact record)


On 2018-02-07 08:01 PM, Matthew Darwin wrote:


Hi all,

Below are the 10 top postal code formats in Canada as seen in 
*addr:postcode*. When I get bored of tidying up phone numbers, I'll 
tackle some postal codes.


I hope we can all agree that "A#A #A#", which is the most popular, 
is the correct format that should be used.  The ones that just have 
'A#A' (the "Forward Sortation Area") I will leave as well.   There 
are more than 60 unique formats in use today and funny enough I 
see phone numbers in the postal code field arrh!


I am open to comments/suggestion on this, as always.

  20271 'A#A #A#'
   1454 'A#A#A#'
 96 'a#a#a#'
 37 'A#A #A# '
 29 'a#a #a#'
 28 'A#A'
 24 'A#A #a#'
 23 'AA A#A #A#'
 17 'A#A-#A#'
 12 'A#A #A#'




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

Re: [Talk-ca] Formatting of Municipality Names

Kevin thanks for the history lesson.  As I mentioned on other threads, 
I'm relatively new here, so I am missing the context, so I appreciate 
you filling it in.


Looking at the 100 used "Town/City/Municipality of " names, they seem 
to be entirely in Ontario.  So perhaps this is mostly an Ontario 
discussion to start.


Here is the full list of city:suburb values as context to the 
discussion.  It appears mainly used in the Montreal area:


 89 Le Plateau-Mont-Royal 38 Côte-des-Neiges–NDG 37 
Rosemont-Petite-Patrie 36 Mercier-Hochelaga-Maisonneuve 34 
Saint-Laurent 25 Bramalea 24 Dollard-des-Ormeaux 22 
Outremont 21 Villeray-Saint-Michel-PE 20 
Ahuntsic-Cartierville 17 Saint-Leonard 16 Pointe-Claire 12 
Westmount 12 Dorval 11 Mont-Royal 11 
LÎle-Bizard-Sainte-Geneviève  8 Côte Saint-Luc  7 
RDP-Pointe-Aux-Trembles  6 Verdun  6 
Sainte-Anne-de-Bellevue  6 Pointe Claire  6 Le Sud Ouest  
6 LaSalle  4 Lachine  4 Erindale  4 Bolton  3 
Montréal-Nord  3 Montreal-Est  3 Anjou  2 Wesmount  2 
Kirkland  2 Hampstead  1 Unionville  1 Scarborough  1 
Pierrefonds-Roxboro  1 North York  1 Le-Sud-Ouest  1 
Gastown  1 Etobicoke  1 Downtown Dartmouth  1 Delta  1 
Beauport  1 Beaconsfield  1 Alton



On 2018-02-12 06:02 PM, Kevin Farrugia wrote:

Hi Matthew,

Not having the "City of" or "Town of" would be preferred - the 
reason those are there is that the CanVec data that was imported 
uses administrative names in the data.


When people search or say an address out loud they would use "123 
Yonge St, Toronto" not "123 Yonge St, City of Toronto".  It's 
something that I think was overlooked when the data was imported and 
has annoyed the hell out of me when I see it...


As for examples like "North York, Toronto" - some people still use 
the pre-amalgamation borough names for the suburbs that were annexed 
into the City of Toronto.  Sometimes it's for a very good purpose - 
there are multiple King, Queen, Main, etc. streets in the current 
city.  In the cases you found, since there are so few, i would 
suggest the former city names be moved to the city:suburb tag and 
Toronto stays in the addr:city tag?




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

Re: [Talk-ca] Formatting of Municipality Names



On 2018-02-12 06:05 PM, Stewart Russell wrote:
On Feb 12, 2018 17:51, "Matthew Darwin" <matt...@mdarwin.ca 
<mailto:matt...@mdarwin.ca>> wrote:


Hi,

I am now reviewing the *addr**:city* tag. Seems we are not very
consistent how we use it. For example, Toronto:

 110707 City of Toronto    9603 Toronto


With my minimalist mapping hat on (it's invisible), if a 
municipality has a boundary defined, we absolutely don't need 
addr:city (or province or country) in address points.




This is the same logic of why the addr:city=Ottawa tags are few and 
far between.


I'm happy to have the discussion about removing redundant tags.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Formatting of Municipality Names


Hi,

I am now reviewing the *addr**:city* tag.   Seems we are not very 
consistent how we use it.  For example, Toronto:


 110707 City of Toronto    9603 Toronto   4 North York, Toronto 
  2 Toronto, ON   2 toronto   1 York, Toronto   1 
Torontoitalian   1 Toronto;City of Toronto   1 Toronto


Which is correct?  "*City of **Toronto*" or "*Toronto*"?   I would 
think "Toronto"???   Why do people pick one over the other?


There are more than 7000 unique names in Canada.  Below are the top 
50.  Ottawa is not on the top of the list because there was a local 
decision to not include the addr:city tag during address addition as 
there there are many different "city" names since almagamation. (The 
official Canada Post address still has the old municipality name prior 
to amalgamation while the City of Ottawa works through de-duplicating 
street names).


110707 City of Toronto 100066 Gatineau 82606 Montréal 79191 Surrey 
71932 Edmonton 51096 Québec 45716 City of Hamilton 37232 Mississauga 
35763 Laval 32029 Dartmouth 30969 Kamloops 27234 City of London 25393 
City of Brampton 22881 Municipality of Chatham-Kent 18534 Saguenay 
17921 Lévis 17251 City of Vaughan 16929 City of St. Catharines 16796 
Town of Markham 16592 City of Kawartha Lakes 16403 Trois-Rivières 
16086 City of Thunder Bay 15788 Oakville 15335 Sherbrooke 14787 City 
of Niagara Falls 14338 Norfolk County 13966 City of Kingston 13939 
Fredericton 12085 City of Oshawa 11966 Saanich 11950 Calgary 11382 
Terrebonne 11332 Richmond Hill 11321 City of Barrie 11080 Town of Fort 
Erie 10986 Cole Harbour 10981 City of Burlington 10641 Town of Whitby 
10635 Saint-Jean-sur-Richelieu 10455 Drummondville 10347 City of 
Guelph 9906 Municipality of Clarington 9666 City of Brantford 9603 
Toronto 9487 Shawinigan 9384 City of Sarnia 9380 Red Deer 9102 City of 
Windsor 9044 City Of Sault Ste. Marie 8466 Sudbury



--
Matthew Darwin
matt...@mdarwin.ca
http://www.mdarwin.ca

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

Re: [Talk-ca] Preferred phone number format

Phone number tidy-up is now complete, per the original discussion.  I 
think we still could clean up this list further I welcome any 
discussion in that regard.  Any phone numbers using letters instead of 
numbers remain with letters.


The top 10 formats used in Canada are:

  20640 phone"+#-###-###-
   4457 phone"+# ###-###-
   3749 phone"+# ### ### 
   2630 phone"+# ### ###-
   1293 fax"+#-###-###-
    940 contact:phone"+#-###-###-
    158 contact:fax"+#-###-###-
    118 phone:tollfree"+#-###-###-
    110 phone"###-
 40 phone"+#-###-###-####;+#-###-###-

On 2018-02-07 06:46 PM, Matthew Darwin wrote:


A further update on this work:

  * I found more yet bizarre phone-related tags "phone:1",
"telephone" and the like.  These have all been tidied.  My
osmfilter now looks like this:    --keep="contact:*=* or
phone*=* or Phone*=* or alt_phone=* or fax*=* or tty*=*"
Additional suggestions for something to search on are welcome so
I get all phone numbers.
  * I found there were some formats used very regionally eg. 
Edmonton Schools used one format consistently and Ottawa Schools
used a different format consistently.
  * The canada.poly filter I have been using includes Saint Pierre
and Miquelon (which does not use North American dialing plan),
as well as a few US entries (especially relations which go near
the border). If anyone knows of a canada.poly that is tighter,
can you point me in the direction?  I am generally leaving
non-Canadian entries alone, but they do count in the stats below.
  * There are now 67 unique tag/phone number format combinations
(down from 400+ originally) when using   egrep -i
'k="[a-z:]*(phone|fax|tty)[a-z:]*" ' $OSMFILENAME | cut -d\"
-f2,4 | sed -e 's/[0-9]/#/g' | sed -e 's/[A-Z]/A/g' | sed -e
's/([a-zA-Z -]*)/(...)/g' | sort | uniq -c | sort -nr | wc -l
  * The bulk of the work remaining now is to reformat the big groups
of numbers that do not begin with "+1". I will make changes by
area code to limit the number of canada-wide changesets.


As always, comments welcome.

Here is the new "top 20"as of ~10am ET today:

  12555 phone"+#-###-###-
   4453 phone"+# ###-###-
   4060 phone"###-###-
   3749 phone"+# ### ### 
   2624 phone"+# ### ###-
   2239 phone"(###) ###-
   1292 fax"+#-###-###-
   1032 phone"##
    941 contact:phone"+#-###-###-
    323 phone"+###
    322 phone"+# ### ###
    158 contact:fax"+#-###-###-
    117 phone:tollfree"+#-###-###-
    109 phone"###-
 39 phone"+#-###-###-;+#-###-###-
 25 phone"+#-###-###-
 23 phone"+#-###-###-x###
 17 phone"+# (###) ###-
 14 phone"+#-###-###-x
  9 phone"+#-###-###-x#


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

[Talk-ca] Postal Code cleanup


Hi all,

Below are the 10 top postal code formats in Canada as seen in 
*addr:postcode*. When I get bored of tidying up phone numbers, I'll 
tackle some postal codes.


I hope we can all agree that "A#A #A#", which is the most popular, is 
the correct format that should be used.  The ones that just have 'A#A' 
(the "Forward Sortation Area") I will leave as well.   There are more 
than 60 unique formats in use today and funny enough I see phone 
numbers in the postal code field arrh!


I am open to comments/suggestion on this, as always.

  20271 'A#A #A#'
   1454 'A#A#A#'
 96 'a#a#a#'
 37 'A#A #A# '
 29 'a#a #a#'
 28 'A#A'
 24 'A#A #a#'
 23 'AA A#A #A#'
 17 'A#A-#A#'
 12 'A#A #A#'

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

Re: [Talk-ca] Preferred phone number format


A further update on this work:

 * I found more yet bizarre phone-related tags "phone:1", "telephone"
   and the like.  These have all been tidied.  My osmfilter now looks
   like this:    --keep="contact:*=* or phone*=* or Phone*=* or
   alt_phone=* or fax*=* or tty*=*"  Additional suggestions for
   something to search on are welcome so I get all phone numbers.
 * I found there were some formats used very regionally eg. Edmonton
   Schools used one format consistently and Ottawa Schools used a
   different format consistently.
 * The canada.poly filter I have been using includes Saint Pierre and
   Miquelon (which does not use North American dialing plan), as well
   as a few US entries (especially relations which go near the
   border). If anyone knows of a canada.poly that is tighter, can you
   point me in the direction?  I am generally leaving non-Canadian
   entries alone, but they do count in the stats below.
 * There are now 67 unique tag/phone number format combinations (down
   from 400+ originally) when using   egrep -i
   'k="[a-z:]*(phone|fax|tty)[a-z:]*" ' $OSMFILENAME | cut -d\" -f2,4
   | sed -e 's/[0-9]/#/g' | sed -e 's/[A-Z]/A/g' | sed -e 's/([a-zA-Z
   -]*)/(...)/g' | sort | uniq -c | sort -nr | wc -l
 * The bulk of the work remaining now is to reformat the big groups
   of numbers that do not begin with "+1".  I will make changes by
   area code to limit the number of canada-wide changesets.


As always, comments welcome.

Here is the new "top 20"as of ~10am ET today:

  12555 phone"+#-###-###-
   4453 phone"+# ###-###-
   4060 phone"###-###-
   3749 phone"+# ### ### 
   2624 phone"+# ### ###-
   2239 phone"(###) ###-
   1292 fax"+#-###-###-
   1032 phone"##
    941 contact:phone"+#-###-###-
    323 phone"+###
    322 phone"+# ### ###
    158 contact:fax"+#-###-###-
    117 phone:tollfree"+#-###-###-
    109 phone"###-
 39 phone"+#-###-###-;+#-###-###-
 25 phone"+#-###-###-
 23 phone"+#-###-###-x###
 17 phone"+# (###) ###-####
     14 phone"+#-###-###-x
  9 phone"+#-###-###-x#



On 2018-02-04 11:49 PM, OSM Volunteer stevea wrote:

On Feb 4, 2018, at 8:37 PM, Matthew Darwin <matt...@mdarwin.ca> wrote:

Just an update on this activity.

Again, nice work!


Here are the top 20 tags as of ~4pm ET Sunday:

   10669 phone"+#-###-###-
4392 phone"+# ###-###-
4206 phone"###-###-
2970 phone"+# ### ### 
2540 phone"+# ### ###-
2451 phone"(###) ###-
1076 phone"##
 659 phone"+# ### ###
 547 fax"+#-###-###-
 522 contact:phone"+#-###-###-
 516 phone"+###
 456 phone"#-###-###-
 446 phone"### ### 
 378 fax"+# ###-###-
 283 contact:phone"### ###-
 260 phone"+# (###) ###-
 200 fax"+###
 186 phone"### ###-
 170 phone"(###)###-
 162 fax"+# ### ###-

I'd appreciate others to chime in about this, but it seems where dashes and space 
characters overlap (are the only difference in format), those can be conflated together.  
I'm not sure whether dash or space ends up as "the winner," but this should 
reduce the number of categories.

As you consider additional conflations, you may be able to do this again and 
again, getting it down to a fairly small number of formats.  I urge additional 
feedback (here would be good) before additional conflations, but (I keep saying 
it):  nice work.

SteveA


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

Re: [Talk-ca] BC2020i - Solving the licensing issues


Hi John,

I think this approach has merit.

Probably it would work if we take a similar approach to what 
BikeOttawa is doing with OSM data, they wanted a "Level Of Traffic 
Stress" map.  To that they defined the set of interesting tags, 
started collecting data, then draw a map.  Now people are looking at 
the map and pointing out errors in map data (which there are lots) or 
things that need improving in the algorithm (which probably there are 
also lots).  [The tagging scheme was previously discussed on this list]


So if someone had a building-related use case they were deriving from 
OSM data, then local mappers could check how the buildings in their 
area align to whatever is that goal.  Last week I started looking a 
building heights... I was using https://osmbuildings.org/ to look at 
the areas I know and then look for buildings that seem to be the wrong 
height then going out to count the windows (vertically) to get the 
number of levels. It will make the map look better. However, it would 
be better if there was a more defined project than just looking at the 
map.


References:
The buildings I changed: 
https://osmbuildings.org/?lat=45.31336=-75.91377=18.4=30
The Bike Ottawa test stress map: 
http://mobiletest.beyond2020.com/bikemap/ (give it a few seconds to 
load the overlay)


On 2018-02-07 11:44 AM, john whelan wrote:
Unfortunately having a valid license is not the whole story.  In 
Montreal we appear to have a valid license we can import from and 
they have building data on their open data portal.  Unfortunately 
technically the quality and ease of use appears to be lower than 
Ottawa's.


I suspect that we need to see how the NRC LiDAR data unfolds and my 
gossip says there is work being done there on deep learning that may 
well be useful.


I think what we need at the moment is something to keep the project 
moving forward and I suspect that will be adding tags to existing 
buildings.  On the schools front some background as to the value of 
the stats from tagging the buildings might be worth its weight in gold.


Cheerio John

On 7 February 2018 at 09:42, Alasia, Alessandro (STATCAN) 
> 
wrote:


Dear all,
It is fantastic to see all these exchanges about BC2020i! There
are a lot of great ideas and improvements being made. I cannot
follow up on each point, though I wanted to update you regarding
one area of specific relevance: the attempt to find a solution
to the licensing issue for building related datasets. I believe
this is one area where my team can contribute to support the
BC2020i.
With my team, I am looking into the feasibility of compiling all
available municipal open data files into one single file and
then releasing this single file under one common license,
specifically the open data licence of the Canadian federal
government. This would, hopefully, solve the license
compatibility issue. We are still exploring this possibility but
are moderately optimistic.
So far we started with the "easy" task: compiling all the known
files – a special thanks to those who contributed to the tables
on the BC2020i wiki page! With that and other OD sources, we
compiled an "OpenAddressRepository" file of nearly 11 million
records (georeferenced) and an "OpenBuildingRepository" file of
nearly 3.2 million polygons (still in progress). Preliminary
analysis suggests that the coverage and geocoding are very
promising. More importantly, given that the files all originate
from official municipal sources, there should be no reason to
doubt the quality of the data.
The next step, for us, is to look at the process required to
release these files with a GoC open data license. We do not yet
have a clear timeline for release, but if this idea is possible,
we should almost certainly make it before the timelines that
were discussed on Talk-ca for vetting each and all individual
municipal open data licenses  - 2080s or 2030s if I recall
correctly :-)
We believe this solution/approach, if successful, puts an end to
the issue of license compatibility (at least for the files found
thus far) and greatly facilitates the use of these open data by
the general public as well as the private and public sector.
Furthermore, and more importantly for BC2020i, this solution
paves the way for the many local OSM groups to import these open
data as they see fit. As well, once the large national level
files are released, we might be able to collaborate with local
groups and provide more manageable partitions of the larger files.
Of course, this approach will not necessarily solve the license
compatibility issue for all types of municipal files. Thus,
needless to say, anybody is obviously free to pursue submitting
individual municipal OD licenses to the License Working Group of
OSM.

Re: [Talk-ca] BC2020i - Solving the licensing issues


James,

Good point about the quality and attributes of the data will 
definitely not be consistent between municipalities. As long as the 
source is identifiable, then the face it is one "file" or many, would 
be an implementation detail.  IMO.


On 2018-02-07 09:46 AM, James wrote:
why does it have to be one file? Cant it be individual cities that 
contribute under a say repository under the federal goverment with 
the federal license? Evaluating the quality of the data is also part 
of the process and as we've found out there are some cities that do 
it better than others when it comes to data quality.


On Feb 7, 2018 9:42 AM, "Alasia, Alessandro (STATCAN)" 
> 
wrote:


Dear all,

It is fantastic to see all these exchanges about BC2020i! There
are a lot of great ideas and improvements being made. I cannot
follow up on each point, though I wanted to update you regarding
one area of specific relevance: the attempt to find a solution
to the licensing issue for building related datasets. I believe
this is one area where my team can contribute to support the
BC2020i.




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

Re: [Talk-ca] Preferred phone number format

2018-01-31 Thread Matthew Darwin


Hi all,

So we get a sense of what phone number formats people are using, I 
pulled all the *phone* and *contact:phone *tags from OSM in Canada.  
The top 10 formats used are:


   8819 phone"+#-###-###-
   4321 phone"###-###-
   4298 phone"+# ###-###-
   3012 phone"+# ### ### 
   2558 phone"+# ### ###-
   2471 phone"(###) ###-
   1087 phone"##
    946 phone"+#-
    680 phone"+# ### ###
    512 phone"+###

So one of the recommended formats is the top one in use.  But there 
are 4 formats in high use which have the leading "+1", but have 
different variants of spaces/hyphens:


   8819 phone"+#-###-###-
   4298 phone"+# ###-###-
   3012 phone"+# ### ### 
   2558 phone"+# ### ###-

Other facts:

 * There are ~400 unique formats (when changing all digits to #) of
   phone and contact:phone
 * 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.



On 2018-01-28 08:22 PM, Matthew Darwin wrote:

Hi all,

Is there a preferred phone number format we use in Canada?

I noticed a bunch of phone numbers in Ottawa don't follow the 
recommendations in https://wiki.openstreetmap.org/wiki/Key:phone, 
namely:


  * phone=/number/ where the /number/ should be in international
(ITU-T E.164 <http://en.wikipedia.org/wiki/E.164>) format
  o phone=+  , following
the ITU-T E.123 <http://en.wikipedia.org/wiki/E.123> and the
DIN 5008 <http://en.wikipedia.org/wiki/de:DIN_5008> pattern
  o (phone=+--, following
the RFC 3966/NANP <http://en.wikipedia.org/wiki/NANP> pattern)

Is there a preference which of these formats is used?   Can anyone 
run a query and see which is more popular in the country?


The reason I'm asking is that since a bunch of phone numbers leave 
off the +1 (and have other errors), I want to align them to the 
recommended format.   I am wondering if I should have them in the 
format of "+1 999 555 1234" or "+1-999-555-1234". If there is no 
existing preference adopted in OSM Canada, I will use the latter to 
cleanup the non-compliant phone numbers.


Comments?

I am also assuming we prefer "phone" over "contact:phone" as per 
https://wiki.openstreetmap.org/wiki/Key:contact




___
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.

2018-01-29 Thread Matthew Darwin

Ok, just I had to re-write more than just that one section to make it 
coherent.   Hopefully the page has a bit more logical structure now.


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

Comments and edits welcome!


On 2018-01-29 09:26 PM, Matthew Darwin wrote:


I will re-write the "project management" section of the wiki page to 
align with this discussion.


On 2018-01-29 09:17 PM, john whelan wrote:
and I think I agree with Pierre the best approach would be to do it 
a step at a time using experienced local resources.


We do need to engage with high schools and the Universities but it 
is difficult with the resources available.  There is some material 
available https://wiki.openstreetmap.org/wiki/Education but it 
would need reviewing to see if it is relevant to what is required.


We were exceptionally fortunate in Ottawa with the pilot and the 
resources we had available but even there I wasn't certain we would 
be able to pull it off.


Cheerio John


2018-01-29 21:11 GMT-05:00 Matthew Darwin <matt...@mdarwin.ca 
<mailto:matt...@mdarwin.ca>>:


+1

Unless someone has lots of $$$ to throw at OSM work (which
could then fund full time coordinators, trainers, lawyers,
etc), the only way I see to coordinate is to approach it like
how OSM in Canada was build up to now... distributed model with
local groups doing what makes sense for their area.   There is,
of course, no way to map all buildings in Canada by 2020 this
way.  Still it is good to set aspirational goals...

On 2018-01-29 08:57 PM, Pierre Béland wrote:


Il faut une part de réalisme. Pour bien coordonner, il ne
suffit pas de créer une tâche et d'inviter à participer. Nous
ne sommes pas une communauté structurée au niveau national. 
Je comprends que diverses universités s'intéressent au projet
OSM et aimeraient initier leurs étudiants à ce projet. La
meilleure solution je pense c'est de se mettre en contact avec
la communauté OSM locale et s'assurer de bien encadrer la
formation et les premiers jours de participation à OSM.

Les contributeurs sont davantage actifs dans leurs communautés
locales ou selon leur divers intérêts liés à leur travail ou
loisir. Personne n'est prêt à s'engager à coordonner un tel
projet au niveau national.



___
Talk-ca mailing list
Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-ca
<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] using image recognition to create building foot prints.

2018-01-29 Thread Matthew Darwin

I will re-write the "project management" section of the wiki page to 
align with this discussion.


On 2018-01-29 09:17 PM, john whelan wrote:
and I think I agree with Pierre the best approach would be to do it 
a step at a time using experienced local resources.


We do need to engage with high schools and the Universities but it 
is difficult with the resources available.  There is some material 
available https://wiki.openstreetmap.org/wiki/Education but it would 
need reviewing to see if it is relevant to what is required.


We were exceptionally fortunate in Ottawa with the pilot and the 
resources we had available but even there I wasn't certain we would 
be able to pull it off.


Cheerio John


2018-01-29 21:11 GMT-05:00 Matthew Darwin <matt...@mdarwin.ca 
<mailto:matt...@mdarwin.ca>>:


+1

Unless someone has lots of $$$ to throw at OSM work (which could
then fund full time coordinators, trainers, lawyers, etc), the
only way I see to coordinate is to approach it like how OSM in
Canada was build up to now... distributed model with local
groups doing what makes sense for their area.   There is, of
course, no way to map all buildings in Canada by 2020 this way.
Still it is good to set aspirational goals...

On 2018-01-29 08:57 PM, Pierre Béland wrote:


Il faut une part de réalisme. Pour bien coordonner, il ne
suffit pas de créer une tâche et d'inviter à participer. Nous
ne sommes pas une communauté structurée au niveau national.  Je
comprends que diverses universités s'intéressent au projet OSM
et aimeraient initier leurs étudiants à ce projet. La meilleure
solution je pense c'est de se mettre en contact avec la
communauté OSM locale et s'assurer de bien encadrer la
formation et les premiers jours de participation à OSM.

Les contributeurs sont davantage actifs dans leurs communautés
locales ou selon leur divers intérêts liés à leur travail ou
loisir. Personne n'est prêt à s'engager à coordonner un tel
projet au niveau national.



___
Talk-ca mailing list
Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-ca
<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] using image recognition to create building foot prints.

2018-01-29 Thread Matthew Darwin


+1

Unless someone has lots of $$$ to throw at OSM work (which could then 
fund full time coordinators, trainers, lawyers, etc), the only way I 
see to coordinate is to approach it like how OSM in Canada was build 
up to now... distributed model with local groups doing what makes 
sense for their area.   There is, of course, no way to map all 
buildings in Canada by 2020 this way.  Still it is good to set 
aspirational goals...


On 2018-01-29 08:57 PM, Pierre Béland wrote:


Il faut une part de réalisme. Pour bien coordonner, il ne suffit pas 
de créer une tâche et d'inviter à participer. Nous ne sommes pas une 
communauté structurée au niveau national.  Je comprends que diverses 
universités s'intéressent au projet OSM et aimeraient initier leurs 
étudiants à ce projet. La meilleure solution je pense c'est de se 
mettre en contact avec la communauté OSM locale et s'assurer de bien 
encadrer la formation et les premiers jours de participation à OSM.


Les contributeurs sont davantage actifs dans leurs communautés 
locales ou selon leur divers intérêts liés à leur travail ou loisir. 
Personne n'est prêt à s'engager à coordonner un tel projet au niveau 
national.


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

Re: [Talk-ca] BC2020 project

I think we can politely re-factor out much stuff.  :-)   Now that we 
seem to have more folks looking into things, I am a bit more motivated 
to spend time on it.


Tech writer type folks would be great to have.


Matthew Darwin
matt...@mdarwin.ca
http://www.mdarwin.ca

On 2018-01-28 09:21 PM, john whelan wrote:

I've added an introduction which sums it up.

If I'm polite about it there is material in the wiki which suggest 
bringing building footprints using automated tools such as image 
scanners and imports are the way forward.  Scanning hasn't been 
accepted by OSM and imports have their own set of issuse.  If I'm 
not polite about it there is much that needs to be stripped out.


The text could do with being rewritten.  It appears to me to be long 
winded and aspires to many things but seems short on practicalities.


Do we have any technical writers who could look it over?


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

Re: [Talk-ca] Preferred phone number format


Just FYI, I am not doing an automated edit.  One at a time in JOSM.

On 2018-01-28 10:23 PM, Stewart C. Russell wrote:

On 2018-01-28 08:22 PM, Matthew Darwin wrote:

I am wondering if I should have them in the format of "+1 999
555 1234" or "+1-999-555-1234".    If there is no existing preference
adopted in OSM Canada, I will use the latter to cleanup the
non-compliant phone numbers.

Comments?

Please use the ITU standard: it's international, and so are we. You
never know what country an OSM user will be coming from.

The great advantage to having the +1 in a number is that Canadian cell
phones won't give you the stupid "This is a long distance call …" spiel
if you include it.

Thanks for looking at this - but as with any automated edit, please take
care.

  Stewart

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


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

[Talk-ca] Fwd: Re: Building Canada 2020 (BC2020i) - update Dec 20, 2017


Forward from a very long distribution list:


Hi J,

So you are not aware of any Indigenous communities engaged with OSM 
anywhere in Canada? It would be great if OSM could be introduced to 
Indigenous community members so they can help define a direction.  
Since you have contacts, can you help doing introductions?  I am 
assuming you are part of the OSM community already?   How would you 
propose creating a working group?


Also can we move this discussion to the OSM Canada mailing list?  
There is an active discussion on the building initiative there.  Maybe 
others know about Indigenous activities already?



On 2018-01-26 02:53 PM, J. Hackett wrote:


Hi everyone,

I brought up a few issues surrounding Indigenous engagement at the 
meeting in July.


There still remains no engagement with Indigenous communities 
whatsoever. It is pertinent that if you want to involve the 
Indigenous demographic that an Indigenous Working Group be 
established to develop, plan, and engage with communities in the 
spirit of truth and reconciliqtion, especially in light of the 
recent TRC.


The 2018 Indigenous Mapping Workshop will be hosted in Montreal. It 
might provide a good venue to truly get the conversation/movement 
going forward.


Our tech partners, Google, Esri Canada, and Mapbox, are working with 
us to develop geospatial capacity building within communities; 
therefore, it could be a good opportunity to bridge efforts with the 
100+ communities that will attend the event.


Feel free to reach out to me if there is interest in any partnership 
with our programming in Montreal, QC.


Thanks!


On Fri, Jan 26, 2018, 14:04 Jonathan Brown, <jonab...@gmail.com 
<mailto:jonab...@gmail.com>> wrote:


I’m a newbie to the wiki and OSM mapathon process. I’m
interested in connecting the open data to the OSM and wiki
process that can be used by K-12 and postsecondary students to
support municipal and regional planning and implementation of
sustainable development goals. Alessandro pointed to the Philly
Fresh Food Mapper as a good example of using OSM to address the
challenge of food security at the local level:
https://www.geovista.psu.edu/phillyfood/

The question is how to sustain these projects once the students
have graduated. I have cced Steve Quinn who provided the GIS/OSM
expertise for that crowdsourcing/citizen science project. He is
still active in organizing mapathon events on Twitter:
https://wiki.openstreetmap.org/wiki/User:SterlingGIS

I have been asked for simple guides that can be used be teachers
that they can incorporate into their lesson plans and that align
with the strategic goals of the K-12 education system they work
within. It would be very helpful if the education wiki included
posters that could be shared with principals, teachers and
community NGO agencies partnering on an event that uses the
BC2020i framework.

Here is an example of how a working team at Brock University put
together resources for a high school data management
prerequisite course:
https://brocku.ca/cmt/mdm4u/asprojects/index.html. I noticed
that the working group did a call out to Joel Yan, Statistics
Canada, for the work he did on making Canadian data available;
and to Stephen Brown, Professor of Statistics at Waterloo, for
his suggestions on restructuring each activity. Professor Andrew
Skelton has taken it one step further by including spatial
analysis with his MDM4U Open Data project in collaboration with
his GIS colleagues: https://mathstat.uoguelph.ca/outreach/opendata

It would be good to see how Josée-Anne Langlois work in the
north with open source mapping tools like GGIS and OSM (see
below) could be combined with open data from the provincial and
federal open data catalogues to create a community profile that
is accessible and engaging for community partners.

Jonathan

*From: *Mikel Maron <mailto:mi...@mapbox.com>
*Sent: *Friday, January 26, 2018 10:37 AM
*To: *Matthew Darwin <mailto:matt...@mdarwin.ca>
*Cc: *Talk-CA OpenStreetMap <mailto:talk-ca@openstreetmap.org>;
Alasia, Alessandro (STATCAN)
<mailto:alessandro.ala...@canada.ca>; James
<mailto:james2...@gmail.com>; rps...@gmail.com
<mailto:rps...@gmail.com>; jeffrey.hack...@thefirelightgroup.com
<mailto:jeffrey.hack...@thefirelightgroup.com>;
m...@openconcept.ca <mailto:m...@openconcept.ca>;
mojgan.jad...@gmail.com <mailto:mojgan.jad...@gmail.com>; Bacon,
Scott (STATCAN) <mailto:scott.ba...@canada.ca>;
aaron.ko...@cra-arc.gc.ca <mailto:aaron.ko...@cra-arc.gc.ca>;
tsitsi.gad...@ontario.ca <mailto:tsitsi.gad...@ontario.ca>;
roy.wise...@outlook.com <mailto:roy.wise...@outlook.com>;
Tweedy, Scott (NRCan/RNCan) <mailto:scott.twe...@canada.ca>;
tyler.radf..

[Talk-ca] Preferred phone number format


Hi all,

Is there a preferred phone number format we use in Canada?

I noticed a bunch of phone numbers in Ottawa don't follow the 
recommendations in https://wiki.openstreetmap.org/wiki/Key:phone, namely:


 * phone=/number/ where the /number/ should be in international
   (ITU-T E.164 ) format
 o phone=+  , following
   the ITU-T E.123  and the
   DIN 5008  pattern
 o (phone=+--, following
   the RFC 3966/NANP  pattern)

Is there a preference which of these formats is used?   Can anyone run 
a query and see which is more popular in the country?


The reason I'm asking is that since a bunch of phone numbers leave off 
the +1 (and have other errors), I want to align them to the 
recommended format.   I am wondering if I should have them in the 
format of "+1 999 555 1234" or "+1-999-555-1234".    If there is no 
existing preference adopted in OSM Canada, I will use the latter to 
cleanup the non-compliant phone numbers.


Comments?

I am also assuming we prefer "phone" over "contact:phone" as per 
https://wiki.openstreetmap.org/wiki/Key:contact


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

Re: [Talk-ca] BC2020 project

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

Re: [Talk-ca] Indigenous communities - Building Canada 2020 (BC2020i) - update Dec 20, 2017



Forward from a very long distribution list:


Hi J,

So you are not aware of any Indigenous communities engaged with OSM 
anywhere in Canada? It would be great if OSM could be introduced to 
Indigenous community members so they can help define a direction. 
Since you have contacts, can you help doing introductions?  I am 
assuming you are part of the OSM community already?   How would you 
propose creating a working group?


Also can we move this discussion to the OSM Canada mailing list?  
There is an active discussion on the building initiative there.  Maybe 
others know about Indigenous activities already?



On 2018-01-26 02:53 PM, J. Hackett wrote:


Hi everyone,

I brought up a few issues surrounding Indigenous engagement at the 
meeting in July.


There still remains no engagement with Indigenous communities 
whatsoever. It is pertinent that if you want to involve the 
Indigenous demographic that an Indigenous Working Group be 
established to develop, plan, and engage with communities in the 
spirit of truth and reconciliqtion, especially in light of the 
recent TRC.


The 2018 Indigenous Mapping Workshop will be hosted in Montreal. It 
might provide a good venue to truly get the conversation/movement 
going forward.


Our tech partners, Google, Esri Canada, and Mapbox, are working with 
us to develop geospatial capacity building within communities; 
therefore, it could be a good opportunity to bridge efforts with the 
100+ communities that will attend the event.


Feel free to reach out to me if there is interest in any partnership 
with our programming in Montreal, QC.


Thanks!




___
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


Great, seems like we have a list of 3 ok ones:

Ottawa (approved license)

Gatineau + Montreal (explicit approval provided)



@James, do we have documentation as to where approval was given? Would 
be good to have this info on the wiki.



Matthew Darwin
matt...@mdarwin.ca
http://www.mdarwin.ca

On 2018-01-28 05:59 PM, James wrote:

LWG blog post about CC-BY

https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/

as long as you have explicit permission to add data from city. It 
become compatible.
I used "may" as in "should remain on the list because explicit 
permission was already obtained."


On Jan 28, 2018 5:53 PM, "OSM Volunteer stevea" 
<stevea...@softworkers.com <mailto:stevea...@softworkers.com>> wrote:


On Jan 28, 2018, at 2:39 PM, James <james2...@gmail.com
<mailto:james2...@gmail.com>> 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


___
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)


Hi Steve,

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.


Keep up the great work.

On 2018-01-25 11:51 PM, OSM Volunteer stevea wrote:

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)


Hi Steve,

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!)


On 2018-01-25 11:39 PM, OSM Volunteer stevea wrote:

On Jan 25, 2018, at 8:30 PM, Matthew Darwin <matt...@mdarwin.ca> 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)

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



On 2018-01-25 11:13 PM, Matthew Darwin wrote:


Hi Steve,

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)


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.



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.



On 2018-01-25 04:00 PM, OSM Volunteer stevea wrote:

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!




___
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] building imports (was Re: Talk-ca Digest, Vol 119, Issue 10)