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

[Pierre Béland]

C'est un Import Canvec. Je ne sais pas quelle est la règle pour ces chemins de 
service de façon générale sur les autoroutes. Les ajoute-t-on systématiquement. 
Si oui, il faudrait ajouter access=no, et sans doute emergency=yes.

Je vois une telle route de service 1km plus au sud, au km 10.  

 
Pierre 
 

Le lundi 5 novembre 2018 20 h 24 min 32 s HNE, Jarek Piórkowski 
 a écrit :  
 
 Yep, so in this case removing the name and keeping the ref on the
junction node sounds appropriate.

While we're at it, the service road
https://www.openstreetmap.org/way/48154169 doesn't seem to show up on
any of the current imagery in iD. Does it still exist?

--Jarek

On Mon, 5 Nov 2018 at 16:28, Pierre Béland  wrote:
>
> Je disais précédemment
> > Je ne sais pour les autres provinces, mais au Québec les no. de sorties
> > correspondent aux bornes kilométriques de la route (ici 15 pour km 15).
> > Il est plus informatif d'afficher le no de sortie (ref=15)
>
>
> Ici c'est sortie 11pour km 11, et non 15 comme j'ai dit précédemment. Sur la 
> carte, la numérotation de la sortie était «noyée» sous le texte.
>
>
> Pierre
>  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

[Jarek Piórkowski]

Yep, so in this case removing the name and keeping the ref on the
junction node sounds appropriate.

While we're at it, the service road
https://www.openstreetmap.org/way/48154169 doesn't seem to show up on
any of the current imagery in iD. Does it still exist?

--Jarek

On Mon, 5 Nov 2018 at 16:28, Pierre Béland  wrote:
>
> Je disais précédemment
> > Je ne sais pour les autres provinces, mais au Québec les no. de sorties
> > correspondent aux bornes kilométriques de la route (ici 15 pour km 15).
> > Il est plus informatif d'afficher le no de sortie (ref=15)
>
>
> Ici c'est sortie 11pour km 11, et non 15 comme j'ai dit précédemment. Sur la 
> carte, la numérotation de la sortie était «noyée» sous le texte.
>
>
> Pierre
>

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

[Talk-ca] hebdoOSM Nº 432 2018-10-23-2018-10-29

[theweekly . osm]

Bonjour,

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

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

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
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

[Pierre Béland]

Je disais précédemment> Je ne sais pour les autres provinces, mais au Québec 
les no. de sorties 
> correspondent aux bornes kilométriques de la route (ici 15 pour km 15). 
> Il est plus informatif d'afficher le no de sortie (ref=15) 

Ici c'est sortie 11pour km 11,  et non 15 comme j'ai dit précédemment. Sur la 
carte, la numérotation de la sortie était «noyée» sous le texte.

 
Pierre 

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

[John Whelan]

Sounds good to me.  At least we have raised the issue and discussed it.

Cheerio John

James wrote on 2018-11-05 3:17 PM:
As "Frederick Ramm" would say having external IDs is pointless when 
you can do a spatial join to see what is there and what is not


On Nov. 5, 2018 3:05 p.m., "John Whelan" > wrote:


Something that has come up in the Netherlands is they did an
import then try to update the buildings once a month.  By having
some sort of id tag on the building their feeling is it makes it
much easier to pick out new buildings.

On the technical side would we have such an id on the building
outline if we should wish to separate out new buildings and import
them later. Currently I don't think we do and someone maybe able
to work it out from the position but is it something we should
think about?


Cheerio John

John Marshall wrote on 2018-11-04 6:40 PM:

Great idea John

John

On Sun, Nov 4, 2018, 16:48 john whelan mailto:jwhelan0...@gmail.com> wrote:

I've started the process off by an introductory post to the
import mailing list and we are working on a wiki page which
will be based on the Stat Canada City of Ottawa import wiki page.

Cheerio John

On Fri, 2 Nov 2018, 7:34 pm James mailto:james2...@gmail.com> wrote:

if anyone needs a TM or micro data service, I'm available
for this

On Fri., Nov. 2, 2018, 7:32 p.m. John Whelan
mailto:jwhelan0...@gmail.com> wrote:

This approach seems very sensible however Pierre has
raised the issue of poorly mapped buildings and we
are aware that some were mapped in a mapathon
environment so whilst Ottawa used a"leave existing
buildings alone" approach is this an area where some
judgement should be used?  and yes I am aware that
the official party line is to correct what is there
to retain the history which means taking the "Ottawa"
approach is less controversial but would probably
give us more inaccuracies on the map.

An alternative might be to import all the buildings
with a different tag than building=yes then leave it
to mappers to inspect each before turning the switch
or change the tags to building=yes.  Those that
overlap poorly mapped buildings could be left to some
sort of clean up phase.

Thanks John

Matthew Darwin wrote on 2018-11-02 7:07 PM:


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 

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

[Martijn van Exel]

Right, I also thought that was the (only) appropriate use for the name tag on 
junction nodes. 
What may be misleading is that the names on Junction nodes are rendered on the 
map, which may encourage people to use the destination as the junction name..

Martijn

> On Nov 5, 2018, at 12:59 PM, Jarek Piórkowski  wrote:
> 
> I have seen this used in Germany for "junction names", e.g.
> https://www.openstreetmap.org/node/30249931 is one of the exits making
> up "Frankfurter Kreuz" which is the major interchange near Frankfurt
> and has its own (quite extensive) Wikipedia page:
> https://de.wikipedia.org/wiki/Frankfurter_Kreuz
> 
> I don't know if naming interchanges is common in Quebec. The nearest
> thing to named interchanges I can think of off the top of my head in
> Ontario is the Basketweave on the 401. This example might be a bit of
> tagging for the renderer to get the exit name to show up on the
> default OSM.org layer.
> 
> --Jarek
> On Mon, 5 Nov 2018 at 14:47, Martijn van Exel  wrote:
>> 
>> Hi,
>> 
>> I just came across this
>> 
>> https://www.evernote.com/l/AVCmW6jzawZAoqDxpQTxFydcW-0mCP1Lyqw
>> 
>> The exit _link[0] has destination tagging that reflects what is on the exit 
>> sign[1], which is correct.
>> But the junction node[2] also has the same destination name in its name tag. 
>> Is there some special tagging case that I am missing or should the name tag 
>> be removed in this case?
>> 
>> Martijn
>> 
>> [0] https://www.openstreetmap.org/way/39158262#map=16/45.1090/-73.4694
>> [1] http://openstreetcam.com/details/1153269/386/edit-osm
>> [2] https://www.openstreetmap.org/node/147228435#map=16/45.1090/-73.4667
>> 
>> ___
>> 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] Exit with name on node *and* destination

[Pierre Béland]

Je ne sais pour les autres provinces, mais au Québec les no. de sorties 
correspondent aux bornes kilométriques de la route (ici 15 pour km 15). Il est 
plus informatif d'afficher le no de sortie (ref=15) sur cette node et d'éviter 
d'ajouter le nom de chemin(s) de destination. La destination apparait plutot 
sur le chemin juste après cette node tel qu'il a été fait ici.  Destination= 
Montée Henrysburg

https://www.openstreetmap.org/way/39158262#map=15/45.1094/-73.4699
Il y a quelques années, on voyait souvent le nom sur la node highway_jonction. 
Je pense qu'il est plus approprié de ne mettre que ref. Et les outils de 
navigation savent identifier la clé destination et indiquer le nom des 
destinations pour cette sortie.

voir https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway_junction
 
Pierre 
 

Le lundi 5 novembre 2018 15 h 00 min 57 s HNE, Jarek Piórkowski 
 a écrit :  
 
 I have seen this used in Germany for "junction names", e.g.
https://www.openstreetmap.org/node/30249931 is one of the exits making
up "Frankfurter Kreuz" which is the major interchange near Frankfurt
and has its own (quite extensive) Wikipedia page:
https://de.wikipedia.org/wiki/Frankfurter_Kreuz

I don't know if naming interchanges is common in Quebec. The nearest
thing to named interchanges I can think of off the top of my head in
Ontario is the Basketweave on the 401. This example might be a bit of
tagging for the renderer to get the exit name to show up on the
default OSM.org layer.

--Jarek
On Mon, 5 Nov 2018 at 14:47, Martijn van Exel  wrote:
>
> Hi,
>
> I just came across this
>
> https://www.evernote.com/l/AVCmW6jzawZAoqDxpQTxFydcW-0mCP1Lyqw
>
> The exit _link[0] has destination tagging that reflects what is on the exit 
> sign[1], which is correct.
> But the junction node[2] also has the same destination name in its name tag. 
> Is there some special tagging case that I am missing or should the name tag 
> be removed in this case?
>
> Martijn
>
> [0] https://www.openstreetmap.org/way/39158262#map=16/45.1090/-73.4694
> [1] http://openstreetcam.com/details/1153269/386/edit-osm
> [2] https://www.openstreetmap.org/node/147228435#map=16/45.1090/-73.4667
>
> ___
> 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

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

[James]

As "Frederick Ramm" would say having external IDs is pointless when you can
do a spatial join to see what is there and what is not

On Nov. 5, 2018 3:05 p.m., "John Whelan"  wrote:

Something that has come up in the Netherlands is they did an import then
try to update the buildings once a month.  By having some sort of id tag on
the building their feeling is it makes it much easier to pick out new
buildings.

On the technical side would we have such an id on the building outline if
we should wish to separate out new buildings and import them later.
Currently I don't think we do and someone maybe able to work it out from
the position but is it something we should think about?


Cheerio John

John Marshall wrote on 2018-11-04 6:40 PM:

Great idea John

John

On Sun, Nov 4, 2018, 16:48 john whelan  I've started the process off by an introductory post to the import mailing
> list and we are working on a wiki page which will be based on the Stat
> Canada City of Ottawa import wiki page.
>
> Cheerio John
>
> On Fri, 2 Nov 2018, 7:34 pm James 
>> if anyone needs a TM or micro data service, I'm available for this
>>
>> On Fri., Nov. 2, 2018, 7:32 p.m. John Whelan > wrote:
>>
>>> This approach seems very sensible however Pierre has raised the issue of
>>> poorly mapped buildings and we are aware that some were mapped in a
>>> mapathon environment so whilst Ottawa used a "leave existing buildings
>>> alone" approach is this an area where some judgement should be used?  and
>>> yes I am aware that the official party line is to correct what is there to
>>> retain the history which means taking the "Ottawa" approach is less
>>> controversial but would probably give us more inaccuracies on the map.
>>>
>>> An alternative might be to import all the buildings with a different tag
>>> than building=yes then leave it to mappers to inspect each before turning
>>> the switch or change the tags to building=yes.  Those that overlap poorly
>>> mapped buildings could be left to some sort of clean up phase.
>>>
>>> Thanks John
>>>
>>> Matthew Darwin wrote on 2018-11-02 7:07 PM:
>>>
>>> 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 

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

[John Whelan]

Something that has come up in the Netherlands is they did an import then 
try to update the buildings once a month.  By having some sort of id tag 
on the building their feeling is it makes it much easier to pick out new 
buildings.


On the technical side would we have such an id on the building outline 
if we should wish to separate out new buildings and import them later. 
Currently I don't think we do and someone maybe able to work it out from 
the position but is it something we should think about?


Cheerio John

John Marshall wrote on 2018-11-04 6:40 PM:

Great idea John

John

On Sun, Nov 4, 2018, 16:48 john whelan  wrote:


I've started the process off by an introductory post to the import
mailing list and we are working on a wiki page which will be based
on the Stat Canada City of Ottawa import wiki page.

Cheerio John

On Fri, 2 Nov 2018, 7:34 pm James mailto:james2...@gmail.com> wrote:

if anyone needs a TM or micro data service, I'm available for this

On Fri., Nov. 2, 2018, 7:32 p.m. John Whelan
mailto:jwhelan0...@gmail.com> wrote:

This approach seems very sensible however Pierre has
raised the issue of poorly mapped buildings and we are
aware that some were mapped in a mapathon environment so
whilst Ottawa used a"leave existing buildings alone"
approach is this an area where some judgement should be
used?  and yes I am aware that the official party line is
to correct what is there to retain the history which means
taking the "Ottawa" approach is less controversial but
would probably give us more inaccuracies on the map.

An alternative might be to import all the buildings with a
different tag than building=yes then leave it to mappers
to inspect each before turning the switch or change the
tags to building=yes.  Those that overlap poorly mapped
buildings could be left to some sort of clean up phase.

Thanks John

Matthew Darwin wrote on 2018-11-02 7:07 PM:


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é
  

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

[Jarek Piórkowski]

I have seen this used in Germany for "junction names", e.g.
https://www.openstreetmap.org/node/30249931 is one of the exits making
up "Frankfurter Kreuz" which is the major interchange near Frankfurt
and has its own (quite extensive) Wikipedia page:
https://de.wikipedia.org/wiki/Frankfurter_Kreuz

I don't know if naming interchanges is common in Quebec. The nearest
thing to named interchanges I can think of off the top of my head in
Ontario is the Basketweave on the 401. This example might be a bit of
tagging for the renderer to get the exit name to show up on the
default OSM.org layer.

--Jarek
On Mon, 5 Nov 2018 at 14:47, Martijn van Exel  wrote:
>
> Hi,
>
> I just came across this
>
> https://www.evernote.com/l/AVCmW6jzawZAoqDxpQTxFydcW-0mCP1Lyqw
>
> The exit _link[0] has destination tagging that reflects what is on the exit 
> sign[1], which is correct.
> But the junction node[2] also has the same destination name in its name tag. 
> Is there some special tagging case that I am missing or should the name tag 
> be removed in this case?
>
> Martijn
>
> [0] https://www.openstreetmap.org/way/39158262#map=16/45.1090/-73.4694
> [1] http://openstreetcam.com/details/1153269/386/edit-osm
> [2] https://www.openstreetmap.org/node/147228435#map=16/45.1090/-73.4667
>
> ___
> 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] Talk-ca Digest, Vol 129, Issue 15

[John Whelan]

My personal view is if we have a process that follows the rules 
available then at least there is more chance they will be followed and 
edits will not be reversed.


I might note the buildings in Regina have amazing similar outlines to 
the ones made available via the Stats Canada file but I really wouldn't 
like to say they had definitely been imported improperly.


One of the problems with the source=tag is it does get deleted from time 
to time.  Locally we have a mapper who if he adds any sort of detail to 
a highway that has source=CANVEC on it removes the source tag on the 
grounds that not all the information has come from CANVEC.   It does 
make auditing the map more difficult.


In Europe there is considerably more resistance to imports than in 
Canada but strangely enough there is a proposal going through the import 
mailing list currently for importing building outlines from government 
sources in Belgium at the moment so hopefully our proposal will meet 
less resistance than some others.


Cheerio John

OSM Volunteer stevea wrote on 2018-11-05 2:10 PM:

On Nov 5, 2018, at 7:29 AM, keith hartley  wrote:

I saw it was a great job. But you're correct, I have no documentation on how 
they did it. Licence process, wiki ( I feel Steve already yelling at his 
computer)

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

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

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

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

SteveA
California


--
Sent from Postbox 

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

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

[OSM Volunteer stevea]

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

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

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

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

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

SteveA
California

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

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

[keith hartley]

I saw it was a great job. But you're correct, I have no documentation on
how they did it. Licence process, wiki ( I feel Steve already yelling at
his computer)

On Nov 5, 2018 9:24 AM, "john whelan"  wrote:

>Someone already did Regina!

and that is an issue and why we need to get this lot formalised quickly
before someone starts talking about imports being done without the correct
license.

Cheerio John

On Mon, 5 Nov 2018 at 10:15, keith hartley 
wrote:

> Someone already did Regina!
>
> On Mon, Nov 5, 2018, 9:06 AM James 
>> Saskatchewan has Regina data. That's it.
>>
>> It's totally dependent on cities contributing to the open data effort
>>
>> On Mon., Nov. 5, 2018, 9:21 a.m. keith hartley > wrote:
>>
>>> Hi all,
>>> I'd love to do more imports - I have a group here that we get together
>>> to do mapping as well as know some locals. Of course we'd add a wiki to the
>>> MB page to show the project ect.  From what I can tell there's no stats can
>>> data for manitoba or sask though!
>>> Keith
>>> ___
>>> 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

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

[john whelan]

>Someone already did Regina!

and that is an issue and why we need to get this lot formalised quickly
before someone starts talking about imports being done without the correct
license.

Cheerio John

On Mon, 5 Nov 2018 at 10:15, keith hartley 
wrote:

> Someone already did Regina!
>
> On Mon, Nov 5, 2018, 9:06 AM James 
>> Saskatchewan has Regina data. That's it.
>>
>> It's totally dependent on cities contributing to the open data effort
>>
>> On Mon., Nov. 5, 2018, 9:21 a.m. keith hartley > wrote:
>>
>>> Hi all,
>>> I'd love to do more imports - I have a group here that we get together
>>> to do mapping as well as know some locals. Of course we'd add a wiki to the
>>> MB page to show the project ect.  From what I can tell there's no stats can
>>> data for manitoba or sask though!
>>> Keith
>>> ___
>>> 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

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

[keith hartley]

Someone already did Regina!

On Mon, Nov 5, 2018, 9:06 AM James  Saskatchewan has Regina data. That's it.
>
> It's totally dependent on cities contributing to the open data effort
>
> On Mon., Nov. 5, 2018, 9:21 a.m. keith hartley  wrote:
>
>> Hi all,
>> I'd love to do more imports - I have a group here that we get together to
>> do mapping as well as know some locals. Of course we'd add a wiki to the MB
>> page to show the project ect.  From what I can tell there's no stats can
>> data for manitoba or sask though!
>> Keith
>> ___
>> 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] Talk-ca Digest, Vol 129, Issue 15

[James]

Saskatchewan has Regina data. That's it.

It's totally dependent on cities contributing to the open data effort

On Mon., Nov. 5, 2018, 9:21 a.m. keith hartley  Hi all,
> I'd love to do more imports - I have a group here that we get together to
> do mapping as well as know some locals. Of course we'd add a wiki to the MB
> page to show the project ect.  From what I can tell there's no stats can
> data for manitoba or sask though!
> Keith
> ___
> 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] Talk-ca Digest, Vol 129, Issue 15

[keith hartley]

 Hi all,
I'd love to do more imports - I have a group here that we get together to
do mapping as well as know some locals. Of course we'd add a wiki to the MB
page to show the project ect.  From what I can tell there's no stats can
data for manitoba or sask though!
Keith
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca