Re: [Talk-ca] Piggyback a SOTM bid with FOSS4G in Calgary

[Martijn van Exel]

Not Canadian and definitely not local to Calgary, but I just wanted to chime in 
to say I really enjoyed it when SOTM and FOSS4G were both in Denver, and I 
would love for that to happen again. If I can somehow support I'd be happy to.
--
 Martijn van Exel
 m...@rtijn.org



On Fri, Aug 23, 2019, at 11:26, Clifford Snow wrote:
> The 2020 FOSS4G is being held August 24-29 in Calgary. This seems like a good 
> opportunity to submit a SOTM bid for either the weekend before or the weekend 
> after. I have a number of friends that can get funding from their company to 
> one but not both. Having both conferences in the same week will get us more 
> participation.
> 
> SOTM 2020 bids [1] are due next week, August 30th, so there isn't much time 
> left. I know that a couple of the lead people for FOSS4G are willing the 
> help. 
> 
> What are your thoughts on bidding on the 2020 SOTM? 
> 
> 
> [1] https://wiki.openstreetmap.org/wiki/State_of_the_Map_2020/Call_for_venues
> 
> Best,
> Clifford 
> 
> -- 
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
> ___
> 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] Defining a local mapper group

[Martijn van Exel]

If you’re interested in forming local mapper groups based on actual 
contributions to OSM you are free to use the Meet Your Mapper tool I built a 
little while ago.

You can draw a bounding box and retrieve a list of mappers who contributed 
there. It generates some basic stats such as number of nodes / ways / relations 
and tries to classify mappers in a few categories. 

Some more information here: 
https://www.openstreetmap.org/user/mvexel/diary/44833 
 and the tool lives at 
https://mym.rtijn.org/  

Martijn

> On Mar 19, 2019, at 11:29 AM, Jonathan Brown  wrote:
> 
> Ideally, a local mapper/group would be one that contributed data to an open 
> digital map that can be verified and used to solve a problem (e.g., food 
> security, fresh water, climate change, etc.). The local mapping group should 
> be able to contribute data via satellite imagery, open data, and/or a 
> physical location. The challenge is how to cultivate and maintain local 
> mapper groups based on volunteer work. 
>  
> Jonathan Brown
>  
> From: John Whelan 
> Sent: Friday, March 15, 2019 10:01 AM
> To: Jonathan Brown 
> Cc: talk-ca@openstreetmap.org 
> Subject: Re: [Talk-ca] Local groups as part of import plan
>  
> The problem is defining and contacting a local group.  Once defined then they 
> can make the decision.
> 
> I've seen as few as two people make a local group decision on an import 
> before now although normally it is done over coffee.
> 
> Also we get into who is a local mapper.
> 
> Many people have an interest in seeing the data imported but I'm under the 
> impression only those with a OpenStreetMap userid who have contributed count.
> 
> Would anyone care to define a local mapper or group?
> 
> Thanks John
> 
> Jonathan Brown wrote on 2019-03-15 9:46 AM:
> 
> Could we get Stats Can to support a few local groups who want to use a common 
> framework for a collaborative research project that addresses a sustainable 
> development goal outcome (e.g., the OSM fresh security challenge 
> https://wiki.openstreetmap.org/wiki/Food_security 
>  and 
> https://www.usda.gov/topics/food-and-nutrition/food-security 
> ) ? 
>  
> Jonathan 
>  
> 
> 
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-ca 
> 
>  
> -- 
> Sent from Postbox 
> 
>  
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca

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

Re: [Talk-ca] Toronto appreciation

[Martijn van Exel]

That’s so nice!
I hope to meet some of you there. I’ll have to leave around 6pm unfortunately.
And obviously it’s layer=-1, not level :)
Martijn

> On Mar 18, 2019, at 9:08 PM, Steve Singer  wrote:
> 
> On Mon, 18 Mar 2019, Martijn van Exel wrote:
> 
>> Hi all, and Toronto mappers in particular.I am currently visiting Toronto 
>> and using OSM
>> extensively to get around using maps.me and the OSM web site mainly.
>> The level of detail and completeness are amazing, a big thanks to all 
>> Toronto mappers.
>> I didn’t know about PATH, the level=-1 pedestrian infrastructure, which 
>> seems to be well mapped
>> also. Amazing.
>> If any of you are around, I have some time tomorrow in the afternoon, if you 
>> want to get a coffee
>> or a beer.
>> Martijn
> 
> I've posted an event to the meetup group (based on Martijn proposal) for 
> Tuesday March 19, 4:00pm at C'est what.
> 
> https://www.meetup.com/OpenStreetMap-Toronto/events/259886903/
> 
> Steve


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

[Talk-ca] Toronto appreciation

[Martijn van Exel]

Hi all, and Toronto mappers in particular.
I am currently visiting Toronto and using OSM extensively to get around using 
maps.me  and the OSM web site mainly.
The level of detail and completeness are amazing, a big thanks to all Toronto 
mappers.
I didn’t know about PATH, the level=-1 pedestrian infrastructure, which seems 
to be well mapped also. Amazing.
If any of you are around, I have some time tomorrow in the afternoon, if you 
want to get a coffee or a beer.
Martijn___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] New MapRoulette challenge to address highway class flip-flops

[Martijn van Exel]

Harald — you can go into your User profile and change the Default Editor 
setting to ‘Edit just features in JOSM’. This will load just the ‘abnormal’ 
highway. You can then load more data around if if needed. If you don’t want to 
change the setting globally you can use keyboard shortcut ‘y’ to trigger this 
type of loading in JOSM on a task by task basis.

Hope this helps, 
Martijn

> On Feb 4, 2019, at 9:44 AM, Harald Kliems  wrote:
> 
> Hi Martijn:
> I just tried the challenge, and all of the first four tasks that came up 
> produce an "area too big" error in JOSM (long highways in very rural areas). 
> Is there any way to fix this? Or maybe warn people to not use JOSM for this 
> challenge?
>  Harald.
> 
> On Mon, Feb 4, 2019 at 10:37 AM Martijn van Exel  <mailto:m...@rtijn.org>> wrote:
> Hi all, 
> 
> Per Matthew Darwin’s request on Twitter, my team prepared a MapRoulette 
> challenge for ‘highway class flip-flops’. What does this mean? Consecutive 
> ways that have a suspicious change from one highway= value to another and 
> then back to the former. This happens sometimes when mappers change the 
> highway= value for some way but miss a bridge somewhere. An example is 
> https://www.openstreetmap.org/way/53514358#map=19/51.23309/-116.65373 
> <https://www.openstreetmap.org/way/53514358#map=19/51.23309/-116.65373> where 
> the bridge is marked as residential but the two adjoining ways are marked as 
> unclassified.
> 
> You can find the challenge at https://maproulette.org/mr3/challenge/3588 
> <https://maproulette.org/mr3/challenge/3588> and your feedback is very 
> welcome.There are ~300 tasks.
> 
> If you have other ideas for challenges to clean up / review existing data let 
> me know and we can discuss.
> 
> Martijn
> ___
> 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>
> 
> 
> -- 
> Please use encrypted communication whenever possible!
> Key-ID: 0x34cb93972f186565

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

Re: [Talk-ca] New MapRoulette challenge to address highway class flip-flops

[Martijn van Exel]

Just as an addendum, you may find false positives like this one 
https://maproulette.org/mr3/challenge/3588/task/11055949 
<https://maproulette.org/mr3/challenge/3588/task/11055949> where a service road 
connects to residential roads in a perfectly valid way. You should mark these 
as ’not an issue’ in MapRoulette.

Martijn

> On Feb 4, 2019, at 9:36 AM, Martijn van Exel  wrote:
> 
> Hi all, 
> 
> Per Matthew Darwin’s request on Twitter, my team prepared a MapRoulette 
> challenge for ‘highway class flip-flops’. What does this mean? Consecutive 
> ways that have a suspicious change from one highway= value to another and 
> then back to the former. This happens sometimes when mappers change the 
> highway= value for some way but miss a bridge somewhere. An example is 
> https://www.openstreetmap.org/way/53514358#map=19/51.23309/-116.65373 
> <https://www.openstreetmap.org/way/53514358#map=19/51.23309/-116.65373> where 
> the bridge is marked as residential but the two adjoining ways are marked as 
> unclassified.
> 
> You can find the challenge at https://maproulette.org/mr3/challenge/3588 
> <https://maproulette.org/mr3/challenge/3588> and your feedback is very 
> welcome.There are ~300 tasks.
> 
> If you have other ideas for challenges to clean up / review existing data let 
> me know and we can discuss.
> 
> Martijn
> ___
> 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] New MapRoulette challenge to address highway class flip-flops

[Martijn van Exel]

Hi all, 

Per Matthew Darwin’s request on Twitter, my team prepared a MapRoulette 
challenge for ‘highway class flip-flops’. What does this mean? Consecutive ways 
that have a suspicious change from one highway= value to another and then back 
to the former. This happens sometimes when mappers change the highway= value 
for some way but miss a bridge somewhere. An example is 
https://www.openstreetmap.org/way/53514358#map=19/51.23309/-116.65373 
 where 
the bridge is marked as residential but the two adjoining ways are marked as 
unclassified.

You can find the challenge at https://maproulette.org/mr3/challenge/3588 
 and your feedback is very 
welcome.There are ~300 tasks.

If you have other ideas for challenges to clean up / review existing data let 
me know and we can discuss.

Martijn___
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

[Martijn van Exel]

Like I said, I will leave it to the local mappers to figure out what is best.

I did refine the instructions for the U.S. challenge a little more, since there 
are definitely legitimate uses of the `name` tag on junction nodes. I included 
an example. Have a look if you’re interested: 
https://maproulette.org/mr3/challenge/3253/ 
 I hope this helps to show that a 
MapRoulette challenge is not about telling people how to map, but rather 
inviting them to have a look at a situation that may need correcting, but make 
the decision themselves.

Martijn

> On Nov 6, 2018, at 3:11 PM, Pierre Béland  wrote:
> 
> Je ne suis pas favorable à lancer une action MapRoulette. Cela ressemblerait 
> à une opération pour imposer un schema OSM particulier, voire pour mieux 
> contrôler le rendu sur la carte.
> 

___
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

[Martijn van Exel]

I did create a MapRoulette challenge to review these named junction nodes for 
the United States just now. See 
https://maproulette.org/mr3/challenge/3253/task/5881462 
<https://maproulette.org/mr3/challenge/3253/task/5881462>. If you find it 
useful I’d be happy to create one for Canada as well. Or show you how you can 
do it yourself.

Martijn

> On Nov 6, 2018, at 11:43 AM, Andrew Lester  wrote:
> 
> I just cleaned up a handful of junctions in the western provinces where refs 
> were in the name tag, destination was in the name on the junction in addition 
> to the link way, etc. Running an Overpass query for all of Canada 
> (http://overpass-turbo.eu/s/DrL) now shows that there are almost 2000 of 
> these in Ontario and Quebec, 2 in Nova Scotia, and 1 in Newfoundland. The 
> last 3 look legitimate, but a quick scan of the ones in Ontario and Quebec 
> shows that most are clear tagging-for-the-renderer. In a few test cases, the 
> destinations are already on the link ways, so there's no need for the 
> destination to be in the name on the junction nodes.
> 
> Does anyone have a good reason for keeping these as they are? My opinion is 
> that these should all have the names removed when it's clearly the 
> destination, and that this destination info should be added to the link way 
> if it isn't already.
> 
> Andrew Lester
> Victoria, BC
> 
> From: "Martijn van Exel" 
> To: "talk-ca" 
> Sent: Tuesday, November 6, 2018 7:56:23 AM
> Subject: Re: [Talk-ca] Exit with name on node *and* destination
> 
> So apparently this is pretty common practice in Quebec. There are 755 
> junction nodes that have name tags. See https://overpass-turbo.eu/s/Dr9. 
> Other provinces don't have nearly that many.  
> 
> The user breakdown for latest edit on those nodes doesn't really surface one 
> mapper who consistently added these tags. See https://overpass-turbo.eu/s/Drf
> 
> I'm inclined to leave it to the local Quebec community to say something more 
> definitive about what, if anything, needs to be done with these name tags... 
> I'm happy to set up a MapRoulette challenge to enable us to systematically 
> look at these nodes..
> 
> Best,
> -- 
>   Martijn van Exel
>   m...@rtijn.org
> 
> On Tue, Nov 6, 2018, at 08:33, Martijn van Exel wrote:
> > Is there an Overpass or other query that could detect all these 
> > situations? I could make a MapRoulette challenge out of them so we can 
> > look at them together and remove the name on nodes where it's not 
> > appropriate / redundant.
> > 
> > I'll ask on IRC as well.. I am not that much of an expert in Overpass.
> > -- 
> >   Martijn van Exel
> >   m...@rtijn.org
> > 
> > On Mon, Nov 5, 2018, at 18:23, Jarek Piórkowski wrote:
> > > 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 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

[Martijn van Exel]

So apparently this is pretty common practice in Quebec. There are 755 junction 
nodes that have name tags. See https://overpass-turbo.eu/s/Dr9. Other provinces 
don't have nearly that many.  

The user breakdown for latest edit on those nodes doesn't really surface one 
mapper who consistently added these tags. See https://overpass-turbo.eu/s/Drf

I'm inclined to leave it to the local Quebec community to say something more 
definitive about what, if anything, needs to be done with these name tags... 
I'm happy to set up a MapRoulette challenge to enable us to systematically look 
at these nodes..

Best,
-- 
  Martijn van Exel
  m...@rtijn.org

On Tue, Nov 6, 2018, at 08:33, Martijn van Exel wrote:
> Is there an Overpass or other query that could detect all these 
> situations? I could make a MapRoulette challenge out of them so we can 
> look at them together and remove the name on nodes where it's not 
> appropriate / redundant.
> 
> I'll ask on IRC as well.. I am not that much of an expert in Overpass.
> -- 
>   Martijn van Exel
>   m...@rtijn.org
> 
> On Mon, Nov 5, 2018, at 18:23, Jarek Piórkowski wrote:
> > 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 mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

[Martijn van Exel]

Is there an Overpass or other query that could detect all these situations? I 
could make a MapRoulette challenge out of them so we can look at them together 
and remove the name on nodes where it's not appropriate / redundant.

I'll ask on IRC as well.. I am not that much of an expert in Overpass.
-- 
  Martijn van Exel
  m...@rtijn.org

On Mon, Nov 5, 2018, at 18:23, Jarek Piórkowski wrote:
> 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

[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] Trans-Canada Highway research

[Martijn van Exel]

Pierre, 

Consistency in the data is the main goal. This benefits all the things
you mention, including map rendering and parsing by navigation software
such as ours but also OSMAnd, maps.me and others.There is a master relation for 
the Trans-Canada Highway / Route
Transcanadienne[0] but it is incomplete and broken. One idea would be to
repair it, and the province-level relations that would be the members of
it. Would you be interested in coordinating that?
[0] https://www.openstreetmap.org/relation/1307243
--
  Martijn van Exel
  m...@rtijn.org



On Wed, Mar 28, 2018, at 13:24, Pierre Béland wrote:
> Bonjour Martin,
> 
> Il me semble que les divers commentaires ont été assez clair. La
> communauté OSM du Canada est assez mature pour gérer cela et n'avons
> pas besoin que Navteq démarre un projet pour modifier ces données.> 
> L'équipe Navteq a déja créé beaucoup de problèmes en ajoutant partout
> des relations complexes pour un simple interdit de faire un virage en
> U.  Quels sont maintenant les objectifs de la tâche> 
> More Overlapping Ways in Canada
> Telenav OSM Integrity Checks's Project
> 
> 
> A mon  avis, vous devez discuter avec la communauté canadienne avant
> de démarrer de tels projets. Svp interrompre cette tâche et venez en
> discuter.> 
> Et quels sont vos objectifs pour les modifications vs la route
> Trancanadienne? Un meilleur rendu sur la carte, des itinéraires dans
> les outils de navigation ? Pourquoi ne pas simplement créer une
> relation de type route pour la route Transcanadienne?> 
> ** 
> Pierre **
> 
> 
> Le mercredi 28 mars 2018 13 h 23 min 37 s HAE, Martijn van Exel
> <m...@rtijn.org> a écrit :> 
> 
> Hi all, 
> 
> My colleague Olivia will respond more in depth with some suggestions
> based on your feedback. Thanks for giving our team's ideas some
> thought.> 
> In the meantime, as I was writing a post about the new version of
> MapRoulette, I thought I'd make a Challenge for misspelled Trans-
> Canada Highway names. Please find it here:
> http://maproulette.org/mr3/browse/challenges/2955 . There's only a
> little over 200 tasks, so that should be an easy thing to fix
> together.> 
> The Challenge is based on this Overpass query:
> http://overpass-turbo.eu/s/xoW -- it's pretty easy to make your own
> Challenges based on your own Overpass queries or GeoJSON files.> 
> The diary post explaining MapRoulette is here:
> https://www.openstreetmap.org/user/mvexel/diary/43596> 
> Thanks,
> --
>   Martijn van Exel
>   m...@rtijn.org
> 
> 
> 
> On Tue, Mar 27, 2018, at 07:13, Begin Daniel wrote:
>> Andrew, Je ne crois pas que le fait que ces ‘contributeurs’ soient
>> Roumains, Javanais ou Américains soit à considérer. Ils nous ont
>> consultés avant de faire la modification et c’est parfait. Cependant,
>> je suis entièrement en accord avec ta réponse - laissez ça à la
>> communauté canadienne!>>  


>> (I do not believe that the fact these ‘contributors’ are Romanians,
>> Javanese or Americans is to be considered. They consulted us before
>> making the change and it's perfect. However, I fully agree with your
>> answer - leave that to the Canadian community!-)>>  


>> Sent from  Mail[1] for Windows 10


>>  


>> 
>> *From:* Andrew Lester <a-les...@shaw.ca> *Sent:* Monday, March 26,
>> 2018 1:35:56 PM *To:* Olivia Robu - (p) *Cc:* talk-ca *Subject:* Re:
>> [Talk-ca] Trans-Canada Highway research>>  
>> While standardization may be nice, it often won't be possible even
>> within a single country. As has already been discussed, there are
>> differing conventions in different provinces, so please don't try to
>> apply a single plan to all provinces. How the TCH is handled in OSM
>> will vary depending on the province.>> 
>> For example, in BC (and some other western provinces), the TCH
>> carries the 1 ref. In some places where other ref'ed highways
>> coincide with the TCH, the ref is recorded as "ref=1;19", for
>> example. There are places within cities where the TCH runs on city
>> roads with different names (e.g. Douglas Street in Victoria), so
>> those ways are named with the local name and the TCH name is recorded
>> in the alt_name or nat_name tag (a separate argument is which one of
>> these to use). An alternate name should never be added to the primary
>> name in brackets like proposed. That's exactly what the alt_name (and
>> similar) tags are for. There are also many places where Trans-Canada
>> Highway is the official local name of the road, like most of the
>> highway in BC.>> 
>> As for the correct spelling of the TCH, I think it would be fairly
>&

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

[Martijn van Exel]

Hi all, 

My colleague Olivia will respond more in depth with some suggestions
based on your feedback. Thanks for giving our team's ideas some thought.
In the meantime, as I was writing a post about the new version of
MapRoulette, I thought I'd make a Challenge for misspelled Trans-Canada
Highway names. Please find it here:
http://maproulette.org/mr3/browse/challenges/2955 . There's only a
little over 200 tasks, so that should be an easy thing to fix together.
The Challenge is based on this Overpass query:
http://overpass-turbo.eu/s/xoW -- it's pretty easy to make your own
Challenges based on your own Overpass queries or GeoJSON files.
The diary post explaining MapRoulette is here:
https://www.openstreetmap.org/user/mvexel/diary/43596
Thanks,
--
  Martijn van Exel
  m...@rtijn.org



On Tue, Mar 27, 2018, at 07:13, Begin Daniel wrote:
> Andrew, Je ne crois pas que le fait que ces ‘contributeurs’ soient
> Roumains, Javanais ou Américains soit à considérer. Ils nous ont
> consultés avant de faire la modification et c’est parfait. Cependant,
> je suis entièrement en accord avec ta réponse - laissez ça à la
> communauté canadienne!>  


> (I do not believe that the fact these ‘contributors’ are Romanians,
> Javanese or Americans is to be considered. They consulted us before
> making the change and it's perfect. However, I fully agree with your
> answer - leave that to the Canadian community!-)>  


> Sent from  Mail[1] for Windows 10


>  


> 
> *From:* Andrew Lester <a-les...@shaw.ca> *Sent:* Monday, March 26,
> 2018 1:35:56 PM *To:* Olivia Robu - (p) *Cc:* talk-ca *Subject:* Re:
> [Talk-ca] Trans-Canada Highway research>  
> While standardization may be nice, it often won't be possible even
> within a single country. As has already been discussed, there are
> differing conventions in different provinces, so please don't try to
> apply a single plan to all provinces. How the TCH is handled in OSM
> will vary depending on the province.> 
> For example, in BC (and some other western provinces), the TCH carries
> the 1 ref. In some places where other ref'ed highways coincide with
> the TCH, the ref is recorded as "ref=1;19", for example. There are
> places within cities where the TCH runs on city roads with different
> names (e.g. Douglas Street in Victoria), so those ways are named with
> the local name and the TCH name is recorded in the alt_name or
> nat_name tag (a separate argument is which one of these to use). An
> alternate name should never be added to the primary name in brackets
> like proposed. That's exactly what the alt_name (and similar) tags are
> for. There are also many places where Trans-Canada Highway is the
> official local name of the road, like most of the highway in BC.> 
> As for the correct spelling of the TCH, I think it would be fairly
> uncontroversial to standardize the name to "Trans-Canada Highway" or
> "Route Transcanadienne" where it's appropriate to use the TCH name,
> because those are the official spellings. Any variants can be
> considered errors.> 
> As for varying highway classifications, this is correct and to be
> expected. Unlike the US interstate system, the Trans-Canada Highway
> network varies in construction and importance all across the country,
> so the classification can't be standardized to just motorway or trunk.
> There are sections where primary is the most appropriate, and possibly
> even secondary in some places. Just on Vancouver Island alone, the
> roads designated as the TCH vary from a six-lane motorway all the way
> down to a two-lane effectively-tertiary road.> 
> Since there will need to be a lot of local knowledge required for such
> a project, I strongly recommend that this project not be undertaken by
> Telenav. This is the kind of work that Canadians should be doing,
> being the most familiar with the on-the-ground situation which will
> dictate how the highway is handled in each province. The numerous past
> issues with Telenav's contributions is also a factor that can't be
> ignored. Does it really make sense for a team of Romanians with a
> history of questionable decisions to be making sweeping changes to the
> Canadian national highway network? At least they've brought a proposal
> to the community this time rather than just push forward with a faulty
> plan like they have in the past. I'm still cleaning up after previous
> Telenav projects in my area that added countless non-existent turn
> restrictions and names and also removed valid data.> 
> Andrew
> Victoria, BC, Canada
> 
> 
> *From: *"Olivia Robu - (p)" <olivia.r...@telenav.com>
> *To: *"talk-ca" <talk-ca@openstreetmap.org>
> *Sent: *Monday, March 26, 2018 4:20:16 AM
> *Subject: *[Talk-ca] T

Re: [Talk-ca] Disconnected addresses

[Martijn van Exel]

This comes directly out of OSMI, it may be useful to create a MapRoulette
challenge or similar if we wanted to go that route.

On Tue, Oct 31, 2017 at 4:37 PM, James <james2...@gmail.com> wrote:

> not sure what that format is, but it's completely useless, need so much
> processing, might as well just fix them via OSMI
>
> On Tue, Oct 31, 2017 at 6:27 PM, Matthew Darwin <matt...@mdarwin.ca>
> wrote:
>
>> No ideas from me... I was doing the Ottawa area manually.  It takes a
>> while because you need to review the history of both the street and the
>> address to see which one was most recently changed so you know which one to
>> correct... plus add comments on the change that caused it to be out of
>> alignment so people are aware.  (I didn't comment on every change... once I
>> found a pattern, I stopped commenting).
>>
>> There are still a few in Ottawa that don't match up.  Either because the
>> address and the street are far apart and it is a false-positive error, or
>> the capitalization on the street names don't match... I'm waiting (for 3
>> months now) for the City of Ottawa to get back to me on what is the correct
>> name and then I will fix either the street or the address accordingly.   So
>> long way of saying, anything within the bounds of the City of Ottawa, I
>> will fix.
>> On 2017-10-31 06:11 PM, Martijn van Exel wrote:
>>
>> Hi all,
>>
>> We started fixing this in the Ottawa region, but the problem is bigger
>> than just around the ways that our team updated. I updated the ticket with
>> a dump that we got from OSMI. We are looking at how to best approach this
>> pretty significant fix up task. I will keep you updated. In the mean time,
>> if you have any ideas for how to approach this, let me know. Thanks!
>> Martijn
>>
>> On Oct 11, 2017, at 12:05 PM, Martijn van Exel <m...@rtijn.org> wrote:
>>
>> Hi all,
>>
>> Matthew Darwin pointed out on Github that some street name updates by the
>> Telenav team lead to 'orphaned' address nodes. The ticket is here:
>> https://github.com/TelenavMapping/mapping-projects/issues/34
>>
>> This is just to let you know that we are aware and planning to fix
>> soonest.
>>
>> Thanks and my apologies. Let us know if you encountered this anywhere
>> else.
>>
>> Martijn
>>
>>
>>
>>
>> ___
>> Talk-ca mailing 
>> listTalk-ca@openstreetmap.orghttps://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 mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Disconnected addresses

[Martijn van Exel]

Hi all,

We started fixing this in the Ottawa region, but the problem is bigger than 
just around the ways that our team updated. I updated the ticket with a dump 
that we got from OSMI. We are looking at how to best approach this pretty 
significant fix up task. I will keep you updated. In the mean time, if you have 
any ideas for how to approach this, let me know. Thanks!
Martijn

> On Oct 11, 2017, at 12:05 PM, Martijn van Exel <m...@rtijn.org> wrote:
> 
> Hi all, 
> 
> Matthew Darwin pointed out on Github that some street name updates by the 
> Telenav team lead to 'orphaned' address nodes. The ticket is here: 
> https://github.com/TelenavMapping/mapping-projects/issues/34 
> <https://github.com/TelenavMapping/mapping-projects/issues/34> 
> 
> This is just to let you know that we are aware and planning to fix soonest.
> 
> Thanks and my apologies. Let us know if you encountered this anywhere else.
> 
> Martijn

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

Re: [Talk-ca] Mapping of bilingual destination signs

[Martijn van Exel]

I think that should be fine. Your proposal also follows the convention in
OSM that the 'default' name is the name in the primary language for the
area.

On Wed, Oct 11, 2017 at 7:23 PM, Matthew Darwin <matt...@mdarwin.ca> wrote:

> Should we follow the convention that the local language does not need a
> language tag and the alternate language does.  So for Fredericton (or
> Ottawa), it is
> destination=New Maryland
> destination:street:fr=Rue Regent Sud
> destination:street=Regent Street South
> destination:ref=101 South
>
> This way existing renderers that don't understand the language extension
> continue to work.
>
> On 2017-10-09 03:52 PM, Martijn van Exel wrote:
>
> Hi all,
>
> I contacted the most active mappers in NB. It seems that mapping bilingual
> street destinations with destination:street:fr and destination:street:en
> respectively is an acceptable solution. So the exit way related to the
> image in our ticket (https://github.com/TelenavMapping/mapping-
> projects/issues/27) would be mapped as:
>
> destination=New Maryland
> destination:street:fr=Rue Regent Sud
> destination:street:en=Regent Street South
> destination:ref=101 South
>
> (just destination tags, ignoring the other tags obviously needed)
>
> As promised, I will update the OSM wiki to clarify the destination:street
> tagging some.
>
> Does this sound okay to you?
>
> Thanks for all your feedback.
> Martijn
>
>
> On Fri, Oct 6, 2017 at 3:36 PM, Martijn van Exel <m...@rtijn.org> wrote:
>
>> Hi all,
>>
>> Thanks all for your input. I get a sense that there is a preference for
>> separating out the names on these destination signs in separate language
>> tags, even though documentation for destination:street is sparse. To be
>> sure I contacted what I hope are the top mappers in NB. A list of mappers I
>> contacted and the message I sent is in the github ticket (
>> https://github.com/TelenavMapping/mapping-projects/issues/27). This is
>> based on the Pascal Neis web site http://resultmaps.neis-one.org/oooc .
>>
>> It would be nice to update the NB wiki page with a French / English map
>> but I will leave that to the experts.
>>
>> I will try and clarify the destination:street documentation on the wiki
>> next week.
>>
>> Martijn
>>
>> On Mon, Oct 2, 2017 at 10:16 PM, J.P. Kirby <webmas...@the506.com> wrote:
>>
>>>
>>> On 2017-10-03, at 12:33 AM, Matthew Darwin <matt...@mdarwin.ca> wrote:
>>>
>>> > Hi J.P.
>>> >
>>> > This sounds reasonable.  Do we have a map that shows which areas of
>>> the province are French area vs English area.  For us non-NBers.   Or I
>>> suppose one could guess by looking at the existing tags there.  (I would
>>> assume Fredericton is English area?)  If we have a list then could update
>>> the NB wiki page. https://wiki.openstreetmap.org/wiki/New_Brunswick
>>>
>>> The general rule is that southern and western NB is English, northern
>>> and eastern is French; but there are exceptions, and a couple places like
>>> Bathurst and Campbellton are 50/50.
>>>
>>> But yes, you can almost always tell from the tags and the street names
>>> themselves (e.g. "St. Mary's" vs "Sainte-Marie").
>>>
>>> JPK
>>>
>>>
>>> ___
>>> 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] Disconnected addresses

[Martijn van Exel]

Hi all,

Matthew Darwin pointed out on Github that some street name updates by the
Telenav team lead to 'orphaned' address nodes. The ticket is here:
https://github.com/TelenavMapping/mapping-projects/issues/34

This is just to let you know that we are aware and planning to fix soonest.

Thanks and my apologies. Let us know if you encountered this anywhere else.

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

Re: [Talk-ca] Mapping of bilingual destination signs

[Martijn van Exel]

I added some detail for this tagging to:
https://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details#destination:street_.2F_destination:street:.3Clanguage_code.3E
https://wiki.openstreetmap.org/wiki/Key:destination#Examples
Martijn

On Mon, Oct 9, 2017 at 2:05 PM, john whelan <jwhelan0...@gmail.com> wrote:

> Sounds good to me.
>
>
> Cheerio John
>
> On 9 Oct 2017 3:55 pm, "Martijn van Exel" <m...@rtijn.org> wrote:
>
>> Hi all,
>>
>> I contacted the most active mappers in NB. It seems that mapping
>> bilingual street destinations with destination:street:fr and
>> destination:street:en respectively is an acceptable solution. So the exit
>> way related to the image in our ticket (https://github.com/TelenavMap
>> ping/mapping-projects/issues/27) would be mapped as:
>>
>> destination=New Maryland
>> destination:street:fr=Rue Regent Sud
>> destination:street:en=Regent Street South
>> destination:ref=101 South
>>
>> (just destination tags, ignoring the other tags obviously needed)
>>
>> As promised, I will update the OSM wiki to clarify the destination:street
>> tagging some.
>>
>> Does this sound okay to you?
>>
>> Thanks for all your feedback.
>> Martijn
>>
>>
>> On Fri, Oct 6, 2017 at 3:36 PM, Martijn van Exel <m...@rtijn.org> wrote:
>>
>>> Hi all,
>>>
>>> Thanks all for your input. I get a sense that there is a preference for
>>> separating out the names on these destination signs in separate language
>>> tags, even though documentation for destination:street is sparse. To be
>>> sure I contacted what I hope are the top mappers in NB. A list of mappers I
>>> contacted and the message I sent is in the github ticket (
>>> https://github.com/TelenavMapping/mapping-projects/issues/27). This is
>>> based on the Pascal Neis web site http://resultmaps.neis-one.org/oooc .
>>>
>>> It would be nice to update the NB wiki page with a French / English map
>>> but I will leave that to the experts.
>>>
>>> I will try and clarify the destination:street documentation on the wiki
>>> next week.
>>>
>>> Martijn
>>>
>>> On Mon, Oct 2, 2017 at 10:16 PM, J.P. Kirby <webmas...@the506.com>
>>> wrote:
>>>
>>>>
>>>> On 2017-10-03, at 12:33 AM, Matthew Darwin <matt...@mdarwin.ca> wrote:
>>>>
>>>> > Hi J.P.
>>>> >
>>>> > This sounds reasonable.  Do we have a map that shows which areas of
>>>> the province are French area vs English area.  For us non-NBers.   Or I
>>>> suppose one could guess by looking at the existing tags there.  (I would
>>>> assume Fredericton is English area?)  If we have a list then could update
>>>> the NB wiki page. https://wiki.openstreetmap.org/wiki/New_Brunswick
>>>>
>>>> The general rule is that southern and western NB is English, northern
>>>> and eastern is French; but there are exceptions, and a couple places like
>>>> Bathurst and Campbellton are 50/50.
>>>>
>>>> But yes, you can almost always tell from the tags and the street names
>>>> themselves (e.g. "St. Mary's" vs "Sainte-Marie").
>>>>
>>>> JPK
>>>>
>>>>
>>>> ___
>>>> 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] Mapping of bilingual destination signs

[Martijn van Exel]

Hi all,

Thanks all for your input. I get a sense that there is a preference for
separating out the names on these destination signs in separate language
tags, even though documentation for destination:street is sparse. To be
sure I contacted what I hope are the top mappers in NB. A list of mappers I
contacted and the message I sent is in the github ticket (
https://github.com/TelenavMapping/mapping-projects/issues/27). This is
based on the Pascal Neis web site http://resultmaps.neis-one.org/oooc .

It would be nice to update the NB wiki page with a French / English map but
I will leave that to the experts.

I will try and clarify the destination:street documentation on the wiki
next week.

Martijn

On Mon, Oct 2, 2017 at 10:16 PM, J.P. Kirby  wrote:

>
> On 2017-10-03, at 12:33 AM, Matthew Darwin  wrote:
>
> > Hi J.P.
> >
> > This sounds reasonable.  Do we have a map that shows which areas of the
> province are French area vs English area.  For us non-NBers.   Or I suppose
> one could guess by looking at the existing tags there.  (I would assume
> Fredericton is English area?)  If we have a list then could update the NB
> wiki page. https://wiki.openstreetmap.org/wiki/New_Brunswick
>
> The general rule is that southern and western NB is English, northern and
> eastern is French; but there are exceptions, and a couple places like
> Bathurst and Campbellton are 50/50.
>
> But yes, you can almost always tell from the tags and the street names
> themselves (e.g. "St. Mary's" vs "Sainte-Marie").
>
> JPK
>
>
> ___
> 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: Mapping of bilingual destination signs

[Martijn van Exel]

Other bounced message..Sorry.

-- Forwarded message --
From: Martijn van Exel <mve...@gmail.com>
Date: Mon, Oct 2, 2017 at 9:22 AM
Subject: Re: [Talk-ca] Mapping of bilingual destination signs
To: john whelan <jwhelan0...@gmail.com>
Cc: Matthew Darwin <matt...@mdarwin.ca>, Talk-CA OpenStreetMap <
talk-ca@openstreetmap.org>


Are there any NB mappers here? If not we can extract the most active
mappers from the data and ask directly. (That is how we usually go about
this if we have a local question where nobody from the area seems to be on
the national mailing list.)

Martijn van Exel
skype: mvexel

On Mon, Oct 2, 2017 at 9:18 AM, john whelan <jwhelan0...@gmail.com> wrote:

> Thank you for the clarification.  Could some one do a write up in the wiki
> on destination:street please.
>
> Note to Martin looks like you need a New Brunswick mapper to say what the
> local rules are.
>
> Cheerio John
>
> On 2 October 2017 at 11:06, Matthew Darwin <matt...@mdarwin.ca> wrote:
>
>> No,
>>
>> This is about the "desination" sign that you find on major highways,
>> usually they are green.  "Exit 114 chemin Anderson Road" or whatever.
>>
>> And this specific issue is about road signs in New Brunswick, and New
>> Brunswick is the only official bilingual province in Canada.
>>
>> Matthew Darwinmatthew@mdarwin.cahttp://www.mdarwin.ca
>>
>> On 2017-10-02 11:01 AM, john whelan wrote:
>>
>> > destination:street
>>
>> I'm confused by this.  According to taginfo there are only 11,000 entries
>> and there is no wiki page.
>>
>> We have highway=residential, name=xyz street, name:fr=rue xyz
>>
>> I assume name here is what you mean.
>>
>> Ottawa is not officially bilingual, it is officially English but services
>> are offered in French.
>>
>> https://wiki.openstreetmap.org/wiki/Multilingual_names
>>
>> also https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa and look
>> for bilingual street names.
>>
>> Different parts of Canada have different rules according to who is the
>> authority for naming streets or setting the rules for naming streets.
>>
>> Cheerio John
>>
>>
>>
>> On 2 October 2017 at 10:10, Martijn van Exel <m...@rtijn.org> wrote:
>>
>>> Thank you for all the responses. It seems that using destination:street
>>> is expected to have the name in the local official language. If the sign is
>>> bilingual, I propose then to add the other name as destination:street:en or
>>> destination:street:fr, respectively. This is not yet a documented tag, but
>>> I see no other sensible way to do it and it seems to me that it would be a
>>> logical extension, considering we already have name:[language ISO code]
>>> tags in wide use.
>>>
>>> Does this sound agreeable?
>>>
>>> Thanks
>>> Martijn
>>>
>>> On Fri, Sep 29, 2017 at 3:20 PM, Pierre Béland <pierz...@yahoo.fr>
>>> wrote:
>>>
>>>> Les différentes provinces ou états ont souvent un organisme responsable
>>>> de faire l'inventaire des noms officiels. Au Québec,  c'est la Commission
>>>> de toponymie qui est responsable.
>>>> http://www.toponymie.gouv.qc.ca/ct/accueil.aspx
>>>>
>>>> Sur leur site, on retrouve des listes de noms et les règles qui
>>>> s'appliquent pour les noms au Québec.
>>>> Pour les règles, voir http://www.toponymie.gouv.qc.c
>>>> a/ct/normes-procedures/regles-ecriture/
>>>>
>>>> Les noms affichés sur Geobase.ca correspondent souvent à ces règles
>>>> puisque les données de Ressources naturelles Canada sont fournies par les
>>>> provinces. Par contre, il peut y avoir un certain retard lors de
>>>> modifications de noms. Dans la section Fournisseurs d'image de JOSM, on
>>>> retrouve un lien vers la couche RRN de Geobase. Les données sont aussi
>>>> disponibles par province en shapefile.
>>>> http://ouvert.canada.ca/data/fr/dataset/3d282116-e556-400c-9
>>>> 306-ca1a3cada77f
>>>>
>>>> cordialement
>>>>
>>>> Pierre
>>>>
>>>>
>>>> --
>>>> *De :* john whelan <jwhelan0...@gmail.com>
>>>> *À :* Martijn van Exel <m...@rtijn.org>
>>>> *Cc :* Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>
>>>> *Envoyé le :* vendredi 29 Septembre 2017 16h52
>>>> *Objet :* Re: [Talk-ca] Mapping of bilingua

Re: [Talk-ca] Mapping of bilingual destination signs

[Martijn van Exel]

Sorry to cause confusion. I am not talking about street names, just the
street part of signposts on limited access highways, as depicted in
https://github.com/TelenavMapping/mapping-projects/issues/27. There is
documentation + examples on this in the Exit Info wiki page (
wiki.openstreetmap.org/wiki/Exit_Info) and after discussing with the US
community has been put into wider use there.

The destination:street:[ISO language code] would be a new extension, and
while I am not super fond of deeper colon separated tag hierarchies, this
is the way it seems to make the most sense when compared with the name:[ISO
language code] tag.

Martijn

Martijn van Exel
skype: mvexel

On Mon, Oct 2, 2017 at 9:06 AM, Matthew Darwin <matt...@mdarwin.ca> wrote:

> No,
>
> This is about the "desination" sign that you find on major highways,
> usually they are green.  "Exit 114 chemin Anderson Road" or whatever.
>
> And this specific issue is about road signs in New Brunswick, and New
> Brunswick is the only official bilingual province in Canada.
>
> Matthew Darwinmatthew@mdarwin.cahttp://www.mdarwin.ca
>
> On 2017-10-02 11:01 AM, john whelan wrote:
>
> > destination:street
>
> I'm confused by this.  According to taginfo there are only 11,000 entries
> and there is no wiki page.
>
> We have highway=residential, name=xyz street, name:fr=rue xyz
>
> I assume name here is what you mean.
>
> Ottawa is not officially bilingual, it is officially English but services
> are offered in French.
>
> https://wiki.openstreetmap.org/wiki/Multilingual_names
>
> also https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa and look
> for bilingual street names.
>
> Different parts of Canada have different rules according to who is the
> authority for naming streets or setting the rules for naming streets.
>
> Cheerio John
>
>
>
> On 2 October 2017 at 10:10, Martijn van Exel <m...@rtijn.org> wrote:
>
>> Thank you for all the responses. It seems that using destination:street
>> is expected to have the name in the local official language. If the sign is
>> bilingual, I propose then to add the other name as destination:street:en or
>> destination:street:fr, respectively. This is not yet a documented tag, but
>> I see no other sensible way to do it and it seems to me that it would be a
>> logical extension, considering we already have name:[language ISO code]
>> tags in wide use.
>>
>> Does this sound agreeable?
>>
>> Thanks
>> Martijn
>>
>> On Fri, Sep 29, 2017 at 3:20 PM, Pierre Béland <pierz...@yahoo.fr> wrote:
>>
>>> Les différentes provinces ou états ont souvent un organisme responsable
>>> de faire l'inventaire des noms officiels. Au Québec,  c'est la Commission
>>> de toponymie qui est responsable.
>>> http://www.toponymie.gouv.qc.ca/ct/accueil.aspx
>>>
>>> Sur leur site, on retrouve des listes de noms et les règles qui
>>> s'appliquent pour les noms au Québec.
>>> Pour les règles, voir http://www.toponymie.gouv.qc.c
>>> a/ct/normes-procedures/regles-ecriture/
>>>
>>> Les noms affichés sur Geobase.ca correspondent souvent à ces règles
>>> puisque les données de Ressources naturelles Canada sont fournies par les
>>> provinces. Par contre, il peut y avoir un certain retard lors de
>>> modifications de noms. Dans la section Fournisseurs d'image de JOSM, on
>>> retrouve un lien vers la couche RRN de Geobase. Les données sont aussi
>>> disponibles par province en shapefile.
>>> http://ouvert.canada.ca/data/fr/dataset/3d282116-e556-400c-9
>>> 306-ca1a3cada77f
>>>
>>> cordialement
>>>
>>> Pierre
>>>
>>>
>>> --
>>> *De :* john whelan <jwhelan0...@gmail.com>
>>> *À :* Martijn van Exel <m...@rtijn.org>
>>> *Cc :* Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>
>>> *Envoyé le :* vendredi 29 Septembre 2017 16h52
>>> *Objet :* Re: [Talk-ca] Mapping of bilingual destination signs
>>>
>>> Whilst I think about it Ottawa is an amalgam of smaller municipalities
>>> so is slowly changing street names to avoid duplicates.  I seem to recall
>>> an employee in the street naming bit is adjusting street names in OSM.  So
>>> please do not change a street name to match a photo that might have been
>>> taken some time ago.
>>>
>>> In Quebec I understand province wide the standard for names on maps is
>>> "Rue xyz" in Ontario it is left to the municipality whether to capitalise
>>> the first letter or n

Re: [Talk-ca] Mapping of bilingual destination signs

[Martijn van Exel]

Are there any NB mappers here? If not we can extract the most active
mappers from the data and ask directly. (That is how we usually go about
this if we have a local question where nobody from the area seems to be on
the national mailing list.)

Martijn van Exel
skype: mvexel

On Mon, Oct 2, 2017 at 9:18 AM, john whelan <jwhelan0...@gmail.com> wrote:

> Thank you for the clarification.  Could some one do a write up in the wiki
> on destination:street please.
>
> Note to Martin looks like you need a New Brunswick mapper to say what the
> local rules are.
>
> Cheerio John
>
> On 2 October 2017 at 11:06, Matthew Darwin <matt...@mdarwin.ca> wrote:
>
>> No,
>>
>> This is about the "desination" sign that you find on major highways,
>> usually they are green.  "Exit 114 chemin Anderson Road" or whatever.
>>
>> And this specific issue is about road signs in New Brunswick, and New
>> Brunswick is the only official bilingual province in Canada.
>>
>> Matthew Darwinmatthew@mdarwin.cahttp://www.mdarwin.ca
>>
>> On 2017-10-02 11:01 AM, john whelan wrote:
>>
>> > destination:street
>>
>> I'm confused by this.  According to taginfo there are only 11,000 entries
>> and there is no wiki page.
>>
>> We have highway=residential, name=xyz street, name:fr=rue xyz
>>
>> I assume name here is what you mean.
>>
>> Ottawa is not officially bilingual, it is officially English but services
>> are offered in French.
>>
>> https://wiki.openstreetmap.org/wiki/Multilingual_names
>>
>> also https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa and look
>> for bilingual street names.
>>
>> Different parts of Canada have different rules according to who is the
>> authority for naming streets or setting the rules for naming streets.
>>
>> Cheerio John
>>
>>
>>
>> On 2 October 2017 at 10:10, Martijn van Exel <m...@rtijn.org> wrote:
>>
>>> Thank you for all the responses. It seems that using destination:street
>>> is expected to have the name in the local official language. If the sign is
>>> bilingual, I propose then to add the other name as destination:street:en or
>>> destination:street:fr, respectively. This is not yet a documented tag, but
>>> I see no other sensible way to do it and it seems to me that it would be a
>>> logical extension, considering we already have name:[language ISO code]
>>> tags in wide use.
>>>
>>> Does this sound agreeable?
>>>
>>> Thanks
>>> Martijn
>>>
>>> On Fri, Sep 29, 2017 at 3:20 PM, Pierre Béland <pierz...@yahoo.fr>
>>> wrote:
>>>
>>>> Les différentes provinces ou états ont souvent un organisme responsable
>>>> de faire l'inventaire des noms officiels. Au Québec,  c'est la Commission
>>>> de toponymie qui est responsable.
>>>> http://www.toponymie.gouv.qc.ca/ct/accueil.aspx
>>>>
>>>> Sur leur site, on retrouve des listes de noms et les règles qui
>>>> s'appliquent pour les noms au Québec.
>>>> Pour les règles, voir http://www.toponymie.gouv.qc.c
>>>> a/ct/normes-procedures/regles-ecriture/
>>>>
>>>> Les noms affichés sur Geobase.ca correspondent souvent à ces règles
>>>> puisque les données de Ressources naturelles Canada sont fournies par les
>>>> provinces. Par contre, il peut y avoir un certain retard lors de
>>>> modifications de noms. Dans la section Fournisseurs d'image de JOSM, on
>>>> retrouve un lien vers la couche RRN de Geobase. Les données sont aussi
>>>> disponibles par province en shapefile.
>>>> http://ouvert.canada.ca/data/fr/dataset/3d282116-e556-400c-9
>>>> 306-ca1a3cada77f
>>>>
>>>> cordialement
>>>>
>>>> Pierre
>>>>
>>>>
>>>> --
>>>> *De :* john whelan <jwhelan0...@gmail.com>
>>>> *À :* Martijn van Exel <m...@rtijn.org>
>>>> *Cc :* Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>
>>>> *Envoyé le :* vendredi 29 Septembre 2017 16h52
>>>> *Objet :* Re: [Talk-ca] Mapping of bilingual destination signs
>>>>
>>>> Whilst I think about it Ottawa is an amalgam of smaller municipalities
>>>> so is slowly changing street names to avoid duplicates.  I seem to recall
>>>> an employee in the street naming bit is adjusting street names in OSM.  So
>>>> please do not change a street name to mat

Re: [Talk-ca] OSM Canada & State of the Map US: Oct 20-22

[Martijn van Exel]

Hi Matthew -- I am not from Canada but as the secretary of the OSM
Foundation board I am working with local OSM organizations to become
official local chapters. If you want, we can meet up in Boulder with other
folks from Canada and see if there's enough interest and support from the
Canadian community at large to move in that direction.
Martijn


Martijn van Exel
skype: mvexel

On Wed, Sep 27, 2017 at 3:49 PM, Matthew Darwin <matt...@mdarwin.ca> wrote:

> Hi,
>
> Are any Canadian folks going to State of the Map US October 20-22
> https://2017.stateofthemap.us/
>
> During the conference, I would like to have a discussion about turning the
> informal https://www.osmcanada.ca/ into a not-for-profit Canadian
> corporation.  I'm looking for other folks who think this might be a good
> idea (or maybe have a contrary opinion) and want to talk about it.
>
> Of course comments are accepted here or directly to me (matt...@mdarwin.ca
> ).
>
> Thanks!
>
> ___
> 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: Mapping of bilingual destination signs

[Martijn van Exel]

Sorry, I sent this and the next message from the wrong email and it bounced
because of that..

-- Forwarded message --
From: Martijn van Exel <mve...@gmail.com>
Date: Mon, Oct 2, 2017 at 9:20 AM
Subject: Re: [Talk-ca] Mapping of bilingual destination signs
To: Matthew Darwin <matt...@mdarwin.ca>
Cc: Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>


Sorry to cause confusion. I am not talking about street names, just the
street part of signposts on limited access highways, as depicted in
https://github.com/TelenavMapping/mapping-projects/issues/27. There is
documentation + examples on this in the Exit Info wiki page (
wiki.openstreetmap.org/wiki/Exit_Info) and after discussing with the US
community has been put into wider use there.

The destination:street:[ISO language code] would be a new extension, and
while I am not super fond of deeper colon separated tag hierarchies, this
is the way it seems to make the most sense when compared with the name:[ISO
language code] tag.

Martijn

Martijn van Exel
skype: mvexel

On Mon, Oct 2, 2017 at 9:06 AM, Matthew Darwin <matt...@mdarwin.ca> wrote:

> No,
>
> This is about the "desination" sign that you find on major highways,
> usually they are green.  "Exit 114 chemin Anderson Road" or whatever.
>
> And this specific issue is about road signs in New Brunswick, and New
> Brunswick is the only official bilingual province in Canada.
>
> Matthew Darwinmatthew@mdarwin.cahttp://www.mdarwin.ca
>
> On 2017-10-02 11:01 AM, john whelan wrote:
>
> > destination:street
>
> I'm confused by this.  According to taginfo there are only 11,000 entries
> and there is no wiki page.
>
> We have highway=residential, name=xyz street, name:fr=rue xyz
>
> I assume name here is what you mean.
>
> Ottawa is not officially bilingual, it is officially English but services
> are offered in French.
>
> https://wiki.openstreetmap.org/wiki/Multilingual_names
>
> also https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa and look
> for bilingual street names.
>
> Different parts of Canada have different rules according to who is the
> authority for naming streets or setting the rules for naming streets.
>
> Cheerio John
>
>
>
> On 2 October 2017 at 10:10, Martijn van Exel <m...@rtijn.org> wrote:
>
>> Thank you for all the responses. It seems that using destination:street
>> is expected to have the name in the local official language. If the sign is
>> bilingual, I propose then to add the other name as destination:street:en or
>> destination:street:fr, respectively. This is not yet a documented tag, but
>> I see no other sensible way to do it and it seems to me that it would be a
>> logical extension, considering we already have name:[language ISO code]
>> tags in wide use.
>>
>> Does this sound agreeable?
>>
>> Thanks
>> Martijn
>>
>> On Fri, Sep 29, 2017 at 3:20 PM, Pierre Béland <pierz...@yahoo.fr> wrote:
>>
>>> Les différentes provinces ou états ont souvent un organisme responsable
>>> de faire l'inventaire des noms officiels. Au Québec,  c'est la Commission
>>> de toponymie qui est responsable.
>>> http://www.toponymie.gouv.qc.ca/ct/accueil.aspx
>>>
>>> Sur leur site, on retrouve des listes de noms et les règles qui
>>> s'appliquent pour les noms au Québec.
>>> Pour les règles, voir http://www.toponymie.gouv.qc.c
>>> a/ct/normes-procedures/regles-ecriture/
>>>
>>> Les noms affichés sur Geobase.ca correspondent souvent à ces règles
>>> puisque les données de Ressources naturelles Canada sont fournies par les
>>> provinces. Par contre, il peut y avoir un certain retard lors de
>>> modifications de noms. Dans la section Fournisseurs d'image de JOSM, on
>>> retrouve un lien vers la couche RRN de Geobase. Les données sont aussi
>>> disponibles par province en shapefile.
>>> http://ouvert.canada.ca/data/fr/dataset/3d282116-e556-400c-9
>>> 306-ca1a3cada77f
>>>
>>> cordialement
>>>
>>> Pierre
>>>
>>>
>>> --
>>> *De :* john whelan <jwhelan0...@gmail.com>
>>> *À :* Martijn van Exel <m...@rtijn.org>
>>> *Cc :* Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>
>>> *Envoyé le :* vendredi 29 Septembre 2017 16h52
>>> *Objet :* Re: [Talk-ca] Mapping of bilingual destination signs
>>>
>>> Whilst I think about it Ottawa is an amalgam of smaller municipalities
>>> so is slowly changing street names to avoid duplicates.  I seem to recall
>>> an employee in the street naming bit is adjusti

Re: [Talk-ca] Mapping of bilingual destination signs

[Martijn van Exel]

Thank you for all the responses. It seems that using destination:street is
expected to have the name in the local official language. If the sign is
bilingual, I propose then to add the other name as destination:street:en or
destination:street:fr, respectively. This is not yet a documented tag, but
I see no other sensible way to do it and it seems to me that it would be a
logical extension, considering we already have name:[language ISO code]
tags in wide use.

Does this sound agreeable?

Thanks
Martijn

On Fri, Sep 29, 2017 at 3:20 PM, Pierre Béland <pierz...@yahoo.fr> wrote:

> Les différentes provinces ou états ont souvent un organisme responsable de
> faire l'inventaire des noms officiels. Au Québec,  c'est la Commission de
> toponymie qui est responsable.
> http://www.toponymie.gouv.qc.ca/ct/accueil.aspx
>
> Sur leur site, on retrouve des listes de noms et les règles qui
> s'appliquent pour les noms au Québec.
> Pour les règles, voir http://www.toponymie.gouv.qc.
> ca/ct/normes-procedures/regles-ecriture/
>
> Les noms affichés sur Geobase.ca correspondent souvent à ces règles
> puisque les données de Ressources naturelles Canada sont fournies par les
> provinces. Par contre, il peut y avoir un certain retard lors de
> modifications de noms. Dans la section Fournisseurs d'image de JOSM, on
> retrouve un lien vers la couche RRN de Geobase. Les données sont aussi
> disponibles par province en shapefile.
> http://ouvert.canada.ca/data/fr/dataset/3d282116-e556-400c-
> 9306-ca1a3cada77f
>
> cordialement
>
> Pierre
>
>
> --------------
> *De :* john whelan <jwhelan0...@gmail.com>
> *À :* Martijn van Exel <m...@rtijn.org>
> *Cc :* Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>
> *Envoyé le :* vendredi 29 Septembre 2017 16h52
> *Objet :* Re: [Talk-ca] Mapping of bilingual destination signs
>
> Whilst I think about it Ottawa is an amalgam of smaller municipalities so
> is slowly changing street names to avoid duplicates.  I seem to recall an
> employee in the street naming bit is adjusting street names in OSM.  So
> please do not change a street name to match a photo that might have been
> taken some time ago.
>
> In Quebec I understand province wide the standard for names on maps is
> "Rue xyz" in Ontario it is left to the municipality whether to capitalise
> the first letter or not so you need to know the rules for each municipality.
>
> Have fun
>
> Cheerio John
>
> On 29 Sep 2017 4:20 pm, "john whelan" <jwhelan0...@gmail.com> wrote:
>
> Ottawa is one of the few places that has bilingual street names.
>
> On the same street I've seen just the name, name street and rue name
> street signs.
>
> In Ottawa the majority are Slater street in name then rue Slater in
> name:french.
>
> Anything else means it is difficult to search for the name electronically.
>  "rue Slater Street"  is not easy to enter.
>
> Note for Ottawa it is rue Slater not Rue Slater.  Other places such as
> Quebec may have different rules.
>
> Cheerio John
> .
>
> On 29 Sep 2017 4:10 pm, "Martijn van Exel" <m...@rtijn.org> wrote:
>
> Hi all,
>
> How do you map bilingual signposts? Ones that say for example 'Rue Regent
> St'?
> My thought would be destination:street=[name in primary language for the
> province] and destination:street:en / destination:street:fr for the name in
> the other language. But I've also seen just 'destination:street:Rue Regent
> St'.
>
> My team would like to help make this consistent if you're up for that, but
> what should be the convention? From a machine parsing perspective,
> separating out the languages in separate tags is preferable.
>
> We have a ticket for this question as well, https://github.com/Telen
> avMapping/mapping-projects/ issues/27
> <https://github.com/TelenavMapping/mapping-projects/issues/27>
>
> Thanks / Merci
> Martijn
>
> __ _
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.or g/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
>
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Mapping of bilingual destination signs

[Martijn van Exel]

Hi all,

How do you map bilingual signposts? Ones that say for example 'Rue Regent
St'?
My thought would be destination:street=[name in primary language for the
province] and destination:street:en / destination:street:fr for the name in
the other language. But I've also seen just 'destination:street:Rue Regent
St'.

My team would like to help make this consistent if you're up for that, but
what should be the convention? From a machine parsing perspective,
separating out the languages in separate tags is preferable.

We have a ticket for this question as well,
https://github.com/TelenavMapping/mapping-projects/issues/27

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

Re: [Talk-ca] OSM Canada & State of the Map US: Oct 20-22

[Martijn van Exel]

Hi all,

I responded to Matthew off-list an on, but my response bounced to here
because I used an alternate email address.

Speaking as the secretary of the OSMF board and non-Canadian: we welcome
new Local Chapters and any movement towards that. A first step is to gain
sufficient momentum; a Local Chapter, or any official national OSM
organization, should represent the community as a whole. That would be the
first thing to figure out. I see a lot of regulars on this list, and having
a discussion here about the viability / desirability of incorporating would
be a great start. Discussing in person can be beneficial, but is
understandably challenging in a large country. Feel free to reach out to me
any time if you want to discuss more.

Lastly, I would encourage you to subscribe to the local-chapters mailing
list, which we have dedicated to discuss (the path to) local chapters.

Best,
Martijn

On Thu, Sep 28, 2017 at 6:30 AM, Дмитрий Киселев  wrote:

> Hi I hope I will,
> but I don't have any thought about local chapter and do we want to have a
> local not-for-profit org, or not.
>
> It works when you want to get some data / hardware / money from gov or
> companies (not from ordinary people).
> I'm here not for a long time but looks like gov more willing to work with
> OSM directly, as well as big GIS players.
> So local chapter is nice but not a neccessary thing.
>
> 2017-09-28 9:19 GMT-03:00 Brian Bancroft :
>
>> Hi Matthew,
>>
>> It seems like an interesting idea. I've been travelling a bit lately, and
>> I've found there's a lot of people out there who don't know about OSM where
>> the platform is exactly what they need.
>>
>> Would a robust OSMCanada spread the Gospel beyond the cities? Would it
>> seek to incorporate local GIS imports on the map with legal support and
>> task management?
>>
>> Do we know what an incorporated OSMCanada would do that the informal
>> association of really nice and diligent people can't do on their own?
>>
>> I won't be making SoTMUS this year, but I'd love to hear more about what
>> your aims are with this venture, and the problems you and others believe
>> (or know) it would solve through incorporation and (possibly?)  sweet
>> government handouts. I'm guessing that these are the questions you want to
>> crunch out while you're at the gathering of interesting people.
>>
>> Best wishes and good luck with this endeavour,
>>
>> Brian
>>
>>
>>
>>
>> *From:* jwhelan0...@gmail.com
>> *Sent:* September 28, 2017 7:06 AM
>> *To:* scr...@gmail.com
>> *Cc:* talk-ca@openstreetmap.org
>> *Subject:* Re: [Talk-ca] OSM Canada & State of the Map US: Oct 20-22
>>
>> I hadn't heard of them and I'm in Ottawa but there again I'm not very
>> sociable.  I question why such a decision would be made out of the country?
>>
>> Does it matter if someone creates a not for profit Canadian corporation?
>> I think it would have to change its name though there have been discussions
>> recently about the use of OSM in names.
>>
>> Cheerio John
>>
>> On 27 September 2017 at 21:59, Stewart C. Russell 
>> wrote:
>>
>>> On 2017-09-27 05:49 PM, Matthew Darwin wrote:
>>> > Hi,
>>> >
>>> > Are any Canadian folks going to State of the Map US October 20-22
>>> > https://2017.stateofthemap.us/
>>>
>>> Nope. Wish I could afford it.
>>>
>>> > During the conference, I would like to have a discussion about turning
>>> > the informal https://www.osmcanada.ca/ into a not-for-profit Canadian
>>> > corporation.
>>>
>>> I'd be opposed. Who are osmcanada? They don't represent me. Last I heard
>>> it was an informal group of mappers in Ottawa. What would the non-profit
>>> do? How would it justify its status? Would it be attempting to be an
>>> OSMF Chapter?
>>>
>>>  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
>>
>>
>
>
> --
> Best regards,
> Dmitry
>
> ___
> 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] Gathering opinions on organized editing

[Martijn van Exel]

Hi US / CA mappers, 

The OSMF Data Working Group is currently conducting a community survey on 
‘organized editing’. It would be great if as many of you as possible could give 
them feedback. You can find the full post and a discussion thread here: 
https://lists.openstreetmap.org/pipermail/talk/2017-September/078726.html 


The survey is here:
https://osm-dwg.limequery.org/741554 

I hope you can all take the time to help the DWG and OSMF out; the results will 
guide a future OSMF policy on this topic. You are also more than welcome to 
join the discussion on talk@ or here. 

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

Re: [Talk-ca] Les méfaits de Telenav dans La Prairie

[Martijn van Exel]

Bonjour Pierre, 

Thanks for checking it out.. Again my apologies on behalf of the team, we 
should have been more careful.

Martijn

> On Sep 18, 2017, at 2:30 PM, Pierre Béland <pierz...@yahoo.fr> wrote:
> 
> Bonjour Marjin,
> 
> Je suis allé sur place Samedi avec Dega et pris des photos  près du 
> rond-point. Elles devraient apparaitre bientôt sur Mapillary. Les sentiers 
> sont obstrués avec des barrières et seuls les piétons peuvent y  circuler.
>  
> Pierre 
> 
> 
> De : Martijn van Exel <m...@rtijn.org>
> À : James <james2...@gmail.com> 
> Cc : Ga Delap <gade...@gmail.com>; talk-ca <talk-ca@openstreetmap.org>
> Envoyé le : lundi 18 Septembre 2017 15h03
> Objet : Re: [Talk-ca] Les méfaits de Telenav dans La Prairie
> 
> Hi all, 
> 
> Allow me to respond in English...Sorry..
> Thanks for pointing out the problem with the non-existing roads. We did some 
> additional research ourselves as well after your report and concluded the 
> same thing. Checking two sources in this case proved to be not enough, and I 
> will make sure we proceed even more carefully when the evidence is 
> inconclusive...I am really sorry about this.
> I have deleted the ways in question, 
> https://www.openstreetmap.org/changeset/52154252 
> <https://www.openstreetmap.org/changeset/52154252> 
> We will take extra care in the future that the source list in the changeset 
> really does reflect all the sources we used. (In this case, there was no OSC 
> imagery available).
> 
> Martijn
> 
> 
> 2017-09-15 7:10 GMT-06:00 James <james2...@gmail.com 
> <mailto:james2...@gmail.com>>:
> des photos*
> 
> 2017-09-15 9:10 GMT-04:00 James <james2...@gmail.com 
> <mailto:james2...@gmail.com>>:
> OSC C'est OpenStreetCam. C'est comme Mapillary ou google street view, mais 
> opensource et on peut l'utiliser comme référence pour OSM. Essentiellement le 
> monde se promenes avec leur cameras dans leur voitures et prennent des 
> voitures
> 
> 2017-09-15 9:07 GMT-04:00 James <james2...@gmail.com 
> <mailto:james2...@gmail.com>>:
> Est-ce que tu as contacté Martijn à ce propos? Il est la personne qui 
> coordonne le plus avec la communauté OSM
> 
> 2017-09-15 8:58 GMT-04:00 Ga Delap <gade...@gmail.com 
> <mailto:gade...@gmail.com>>:
> Bonjour à tous et toutes
> J'ai récemment consulté notre carte et, par hasard, j'ai aperçu dans La 
> Prairie des rues que je ne connaissais pas. Je suis allé sur place et j'ai 
> constaté que ces rues n'existent pas.
> 
> Je vous invite à aller voir les chemins suivants:
>   chemin 472613767: portion de "Avenue Jacques-Martin"
>   chemin 13470677: portion de "Avenue de la Belle-Dame"
>   chemin 472613765: "Rue du Cuivré-des-Marais"
>   chemin 472613760: "Rue du Satyre-des-Prés"
>   chemin 472613763: "Rue du Cuivré-des-Marais"
> qu'on peut voir sur: http://www.openstreetmap.org/# map=17/45.39428/-73.47327 
> <http://www.openstreetmap.org/#map=17/45.39428/-73.47327>
> 
> Ces 5 chemins ont été ajoutés en février 2017 par andreis_telenav et il a 
> spécifié que ses sources étaient: "Bing, Geobase Roads, Canvec,OSC"
> Or, Bing ne connait pas ces rues et je serais surpris que Geobase ou CanVec 
> les connaissent.
> Quant à OSC, je ne sais pas ce que c'est.
> 
> Ces rues étaient prévues dans le projet SymbioCité, un développement 
> commercial qui a été frappé d'un interdit par un décret spécial visant à 
> protéger les habitats de la Reinette-Faux-Grillon. Ce décret a été émis en 
> juin 2016.
> Pour les intéressés: http://www.lereflet.qc.ca/actu 
> alites/2016/6/22/le-projet-dom iciliaire-symbiocite-est-une-- 
> menace-imminente--pou.html 
> <http://www.lereflet.qc.ca/actualites/2016/6/22/le-projet-domiciliaire-symbiocite-est-une--menace-imminente--pou.html>
> 
> Mais revenons au sujet.
> L'individu andreis_telenav a inscrit sur la carte des rues qui n'existent pas 
> et qui n'existeront pas dans le futur. C'est un problème.
> Il a probablement utilisé comme source un document de construction ou 
> d'avant-projet mais cette source n'est pas citée.
> Telenav est une compagnie californienne et je déplore qu'il n'ait pas pris 
> contact avec un cartographe local pour vérifier que l'information était 
> valide.
> 
> Ce n'est pas la 1ère fois que je détecte des problèmes créés par Telenav et 
> je me pose des questions quant à leur éthique et leurs méthodes de travail.
> 
> Vos commentaires svp
> 
> dega
> 
> __ _
> Talk-ca mailing list
> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
> https://lists.openstree

Re: [Talk-ca] Les méfaits de Telenav dans La Prairie

[Martijn van Exel]

Hi all,

Allow me to respond in English...Sorry..
Thanks for pointing out the problem with the non-existing roads. We did
some additional research ourselves as well after your report and concluded
the same thing. Checking two sources in this case proved to be not enough,
and I will make sure we proceed even more carefully when the evidence is
inconclusive...I am really sorry about this.
I have deleted the ways in question,
https://www.openstreetmap.org/changeset/52154252
We will take extra care in the future that the source list in the changeset
really does reflect all the sources we used. (In this case, there was no
OSC imagery available).

Martijn


2017-09-15 7:10 GMT-06:00 James :

> des photos*
>
> 2017-09-15 9:10 GMT-04:00 James :
>
>> OSC C'est OpenStreetCam. C'est comme Mapillary ou google street view,
>> mais opensource et on peut l'utiliser comme référence pour OSM.
>> Essentiellement le monde se promenes avec leur cameras dans leur voitures
>> et prennent des voitures
>>
>> 2017-09-15 9:07 GMT-04:00 James :
>>
>>> Est-ce que tu as contacté Martijn à ce propos? Il est la personne qui
>>> coordonne le plus avec la communauté OSM
>>>
>>> 2017-09-15 8:58 GMT-04:00 Ga Delap :
>>>
 Bonjour à tous et toutes
 J'ai récemment consulté notre carte et, par hasard, j'ai aperçu dans La
 Prairie des rues que je ne connaissais pas. Je suis allé sur place et j'ai
 constaté que ces rues n'existent pas.

 Je vous invite à aller voir les chemins suivants:
   chemin 472613767: portion de "Avenue Jacques-Martin"
   chemin 13470677: portion de "Avenue de la Belle-Dame"
   chemin 472613765: "Rue du Cuivré-des-Marais"
   chemin 472613760: "Rue du Satyre-des-Prés"
   chemin 472613763: "Rue du Cuivré-des-Marais"
 qu'on peut voir sur: http://www.openstreetmap.org/#
 map=17/45.39428/-73.47327

 Ces 5 chemins ont été ajoutés en février 2017 par andreis_telenav et il
 a spécifié que ses sources étaient: "Bing, Geobase Roads, Canvec,OSC"
 Or, Bing ne connait pas ces rues et je serais surpris que Geobase ou
 CanVec les connaissent.
 Quant à OSC, je ne sais pas ce que c'est.

 Ces rues étaient prévues dans le projet SymbioCité, un développement
 commercial qui a été frappé d'un interdit par un décret spécial visant à
 protéger les habitats de la Reinette-Faux-Grillon. Ce décret a été émis en
 juin 2016.
 Pour les intéressés: http://www.lereflet.qc.ca/actu
 alites/2016/6/22/le-projet-domiciliaire-symbiocite-est-une--
 menace-imminente--pou.html

 Mais revenons au sujet.
 L'individu andreis_telenav a inscrit sur la carte des rues qui
 n'existent pas et qui n'existeront pas dans le futur. C'est un problème.
 Il a probablement utilisé comme source un document de construction ou
 d'avant-projet mais cette source n'est pas citée.
 Telenav est une compagnie californienne et je déplore qu'il n'ait pas
 pris contact avec un cartographe local pour vérifier que l'information
 était valide.

 Ce n'est pas la 1ère fois que je détecte des problèmes créés par
 Telenav et je me pose des questions quant à leur éthique et leurs méthodes
 de travail.

 Vos commentaires svp

 dega

 ___
 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] Telenav mapping turn restrictions

[Martijn van Exel]

James -- I could not find any OSC / Mapillary imagery at the location of your 
example so I took a peek at <> google street view. What I see there is 
that the slip road / ramp was (as of Aug 2016 -- temporarily?) closed to 
traffic which may very well inform the allowed right turn at the intersection? 
Or do you know this to be permanent? In this particular case, based on the info 
I have, the _link way should have access=no and indeed no restriction would be 
necessary. (Obviously I can't make those edits because of <> above.)

I'm not saying that there cannot be exceptions to the general rule that 'when 
there is a turn ramp one must use it', (and as I said before our team is not 
adding these 'implicit' restrictions until we clear this up). What I am looking 
for is more clarity (specifically in Canada but in the US also) as to traffic 
regulations that would make adding these restrictions not only valid but also a 
boost to the quality of OSM data. I would only want us to add these if there is 
no confusion regarding correctness and there is added value to adding them.

I'm cc-ing the US list as there are very similar traffic situations there and 
I'm interested in clarifying the situation there as well.

Martijn

> On Apr 3, 2017, at 6:47 AM, James Mast <rickmastfa...@hotmail.com> wrote:
> 
> Martijn, with your example you gave back 3/30 [1], are you 100% sure that it 
> still might be legal to right turn at the main intersection?  It might be if 
> you haven't been there, even with the slip lane being there.
> 
> Case in point, if you were to have one of your mappers modify this 
> intersection [2] with a 'no right turn' relation, you would be adding false 
> information to the OSM database.  While there is a 'slip' lane for right 
> turns, there is overhead signage past that slip lane leaving US-19 saying 
> that you are allowed to make a right hand turn at the intersection.  So, [3] 
> would be completely legal and would be prevented if a false relation were to 
> be added here.
> 
> This is just something you can't be 100% sure of without visiting it in 
> person, or have imagery from something like Mapillary to see it.  So, I can 
> see why Andrew was upset about this.
> 
> -James
> 
> [1] 
> https://www.openstreetmap.org/directions?engine=osrm_car=40.66610,-111.86760;40.66386,-111.86464#map=18/40.66520/-111.86552
>  
> <https://www.openstreetmap.org/directions?engine=osrm_car=40.66610,-111.86760;40.66386,-111.86464#map=18/40.66520/-111.86552>
> [2] 
> https://www.openstreetmap.org/directions?engine=osrm_car=40.58570%2C-80.04423%3B40.58680%2C-80.04410#map=19/40.58625/-80.04431
>  
> <https://www.openstreetmap.org/directions?engine=osrm_car=40.58570%2C-80.04423%3B40.58680%2C-80.04410#map=19/40.58625/-80.04431>
> [3] 
> https://www.openstreetmap.org/directions?engine=osrm_car=40.58614%2C-80.04461%3B40.58680%2C-80.04410#map=19/40.58648/-80.04457
>  
> <https://www.openstreetmap.org/directions?engine=osrm_car=40.58614%2C-80.04461%3B40.58680%2C-80.04410#map=19/40.58648/-80.04457>
> From: Stewart C. Russell <scr...@gmail.com>
> Sent: Friday, March 31, 2017 7:26:12 PM
> To: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Telenav mapping turn restrictions
>  
> On 2017-03-31 04:29 PM, Martijn van Exel wrote:
> > … the engine
> > may decide, lacking an explicit restriction, to take the non _link turn
> > because it's faster even if that is an illegal turn. That is why we need
> > these restrictions to be explicit in the data.
> 
> but … but — that's Tagging For The Map, or worse, Tagging To Fix
> Software Stupidity. It's explicitly mapping something that's *not*
> there, and so is contrary to what we're supposed to map.
> 
> I don't have a problem with it being in Telenav's data, but it doesn't
> belong in OSM.
> 
>  Stewart
> 
> 
> ___
> Talk-ca mailing list
> 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 <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] Telenav mapping turn restrictions

[Martijn van Exel]

sary, wouldn't it, if the software had just picked the correct route 
> the first time?  Or worse, if they are there and the routing software hits 
> them, wouldn't they then result in even longer routes, because once it got 
> that far down the path, the only way to look is forward, which is a longer 
> path?  I don't mean to tell you how to write your software. ;-)  Like I said, 
> I don't actually know how routing software is coded.  And I'm sure you've 
> considered this.  I'm just curious, given that consideration, _why_ would 
> that route even happen in the first place (to take the hard corner rather 
> than the link road)?
> 
> Sorry if I'm derailing this discussion.  I don't touch the road network too 
> much in my mapping unless I am pretty sure what I'm changing is obviously 
> correct and simple, and I avoid weird intersections as much as possible.  I'm 
> just curious to understand, so maybe in the future if I happen across such a 
> situation, I'll have some idea how to map it so it doesn't send a driver 
> making a dangerous turn or crashing through a fence or something.  ;-)
> 
> Thanks,
> Ian
> 
> 
> On 30 March 2017 at 09:50, Martijn van Exel <m...@rtijn.org 
> <mailto:m...@rtijn.org>> wrote:
> Hi Andrew (and let me reply to Pierre's comments too, sorry Pierre, I am a 
> little slow parsing French).
> 
> First off thanks for your additional comments, they are really useful. I 
> realize that I should have shared more detail about what we are planning to 
> do and will do a better job in the future if new projects arise. We are 
> actually working on a Github repository (similar to Mapbox's) where we will 
> share more details about mapping projects and where everybody will be able to 
> talk to the team about what we do. Of course we will continue to post here as 
> well.
> 
> We do have a serious onboarding process for new mappers on our team where 
> more experienced mappers guide the newcomers and introduce them to the OSM 
> ecosystem. So they are not quite thrown in the deep end, but like everybody 
> else they go through a learning process where they make simple edits first. 
> We don't ever use live OSM data for pilot or test projects.
> 
> I don't feel there's a consensus about the turn restrictions in places where 
> they are not marked. There are really good (routing / safety related) reasons 
> for this as I pointed out before [1] and in my research I have found many of 
> these in the U.S. as well, but until that is cleared up we will not add any 
> more. This includes the left turn restrictions Pierre mentioned. To Pierre's 
> comments, I don't think that there's really an easier way to map this, turn 
> restrictions have been discussed in the community at length and other 
> solutions not based on relations just don't scale well to complex situations.
> 
> The Bing imagery alignment issue is one that we have not given proper 
> attention and I will impress upon the team that they should pay really close 
> attention to this and be even more restrained in modifying local mappers' 
> work. I seem to remember there is a site / place that lists offset issues 
> with Bing imagery by region? Is there a good source to look at for this?
> 
> I'm thinking it would be good to hold an online town hall where some of our 
> team members and myself can answer any questions and discuss the issues 
> raised? If you're interested in this let me know off-list and we can set up a 
> time.
> 
> Thanks again for your feedback and willingness to work on this with me and 
> the team. We really do want to improve the map for everyone and we will be 
> taking this as an opportunity to do significantly better.
> 
> Martijn
> 
> [1] Look for example at this situation where there is no turn restriction on 
> an intersection with a _link road and OSRM does not route over the _link 
> road. 
> https://www.openstreetmap.org/directions?engine=osrm_car=40.66610%2C-111.86760%3B40.66386%2C-111.86464#map=18/40.66520/-111.86552
>  
> <https://www.openstreetmap.org/directions?engine=osrm_car=40.66610,-111.86760;40.66386,-111.86464#map=18/40.66520/-111.86552>
>  It is these kinds of (potentially unsafe) situations that we are really 
> looking to prevent, not only for Scout users but for all routing software 
> using OSM. (This is in the US not in Canada but the situation could occur 
> anywhere.) 
> 
>> On Mar 29, 2017, at 11:14 PM, Andrew Lester <a-les...@shaw.ca 
>> <mailto:a-les...@shaw.ca>> wrote:
>> 
>> Hi Martijn,
>> 
>> Thanks for your comments. Yes, I have commented on relevant changesets, 
>> though not every one I've come across. To be honest, there are far too many 
>> problematic changesets to start d

Re: [Talk-ca] Telenav mapping turn restrictions

[Martijn van Exel]

Hi Andrew (and let me reply to Pierre's comments too, sorry Pierre, I am a 
little slow parsing French).

First off thanks for your additional comments, they are really useful. I 
realize that I should have shared more detail about what we are planning to do 
and will do a better job in the future if new projects arise. We are actually 
working on a Github repository (similar to Mapbox's) where we will share more 
details about mapping projects and where everybody will be able to talk to the 
team about what we do. Of course we will continue to post here as well.

We do have a serious onboarding process for new mappers on our team where more 
experienced mappers guide the newcomers and introduce them to the OSM 
ecosystem. So they are not quite thrown in the deep end, but like everybody 
else they go through a learning process where they make simple edits first. We 
don't ever use live OSM data for pilot or test projects.

I don't feel there's a consensus about the turn restrictions in places where 
they are not marked. There are really good (routing / safety related) reasons 
for this as I pointed out before [1] and in my research I have found many of 
these in the U.S. as well, but until that is cleared up we will not add any 
more. This includes the left turn restrictions Pierre mentioned. To Pierre's 
comments, I don't think that there's really an easier way to map this, turn 
restrictions have been discussed in the community at length and other solutions 
not based on relations just don't scale well to complex situations.

The Bing imagery alignment issue is one that we have not given proper attention 
and I will impress upon the team that they should pay really close attention to 
this and be even more restrained in modifying local mappers' work. I seem to 
remember there is a site / place that lists offset issues with Bing imagery by 
region? Is there a good source to look at for this?

I'm thinking it would be good to hold an online town hall where some of our 
team members and myself can answer any questions and discuss the issues raised? 
If you're interested in this let me know off-list and we can set up a time.

Thanks again for your feedback and willingness to work on this with me and the 
team. We really do want to improve the map for everyone and we will be taking 
this as an opportunity to do significantly better.

Martijn

[1] Look for example at this situation where there is no turn restriction on an 
intersection with a _link road and OSRM does not route over the _link road. 
https://www.openstreetmap.org/directions?engine=osrm_car=40.66610%2C-111.86760%3B40.66386%2C-111.86464#map=18/40.66520/-111.86552
 

 It is these kinds of (potentially unsafe) situations that we are really 
looking to prevent, not only for Scout users but for all routing software using 
OSM. (This is in the US not in Canada but the situation could occur anywhere.) 

> On Mar 29, 2017, at 11:14 PM, Andrew Lester  wrote:
> 
> Hi Martijn,
> 
> Thanks for your comments. Yes, I have commented on relevant changesets, 
> though not every one I've come across. To be honest, there are far too many 
> problematic changesets to start discussions on all of them.
> 
> In using some QA tools to fix other problems, I've come across further 
> instances of what could best be described as "sloppy" edits. For example, 
> adjustments to road alignments to align them with Bing, but obviously with no 
> attempt to properly align the imagery first. Bing is off by 15-20 metres in 
> much of southern Vancouver Island outside of downtown Victoria, and I've seen 
> some roads being moved that much out of place. Here's an example changeset: 
> https://www.openstreetmap.org/changeset/46740353 (viewed with Achavi: 
> https://overpass-api.de/achavi/?changeset=46740353#map=16). I see the source 
> "Geobase roads" has been listed as being used as part of the edits, which 
> actually reflects the correct alignment, but this seems to have been ignored 
> in favour of the poorly-aligned Bing imagery. In addition, I've found a 
> number of edits by Telenav members creating or moving highways such that they 
> cross footways without an intersecting node, which indicates that the JOSM 
> validator isn't being used before uploading the changes.
> 
> In my opinion, based on what I'm seeing, the Telenav members don't have 
> enough experience with the OSM ecosystem, tagging/mapping conventions, or 
> editing tools to be making such widespread and prolific changes. I would 
> strongly recommend that these members focus on mapping a local area that they 
> can visit in person in order to gain experience with all aspects of actual 
> on-the-ground mapping, and then later begin expanding to the rest of the 
> country. Right now it seems like they're being thrown into the deep end with 
> the hope that they'll just 

Re: [Talk-ca] [Imports] Ottawa Buildings & Addresses [Statistics Canada project]

[Martijn van Exel]

Hi, 

The Telenav mapping team has been looking at some other datasets that were 
published under versions of this ODL and had our legal counsel review this with 
regard to ODbL compatibility. I am asking them for an update on this, hoping 
this will help move things along. (We are also in the process of making these 
actions more visible to the community.)

Martijn van Exel

> On Jan 28, 2017, at 6:20 AM, Stewart C. Russell <scr...@gmail.com> wrote:
> 
> Hi Denis,
> 
>> We've already imported data under the City of Ottawa license, all of the
>> OC Transpo bus stop (minus a few in the downtown core).
> 
> Yes, I meant to ask: where was the announcement/discussion of the OC
> Transpo import on this list? Where's the wiki process page? The imports
> seem to have been done by regular users, not import users, too.
> 
>> Going to wait a few hours to accept replies and afterwards we're going
>> to begin the import tonight (EST).
> 
> Please don't do this - LWG is still working on it.
> 
> 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] Crowdsourcing buildings with Statistics Canada

[Martijn van Exel]

The license link is broken, is it this one? 
http://ottawa.ca/en/city-hall/get-know-your-city/open-data#open-data-licence-version-2-0
 
<http://ottawa.ca/en/city-hall/get-know-your-city/open-data#open-data-licence-version-2-0>

Martijn van Exel

> On Jan 20, 2017, at 12:40 PM, Ellefsen, Bjenk (STATCAN) 
> <bjenk.ellef...@canada.ca> wrote:
> 
> Hello everyone,
>  
> Big news, the City of Ottawa has released the footprint of over 325,000 
> buildings on their open data portal in support to the project with Statistics 
> Canada and the OSM community.
>  
> We are very grateful for the amazing collaboration with the City of Ottawa on 
> this pilot project and are very pleased for this amazing contribution.
>  
> Link: 
> http://data.ottawa.ca/en/dataset/urban-buildings 
> <http://data.ottawa.ca/en/dataset/urban-buildings>
>  
>  
>  
> Bjenk Ellefsen, PhD
>  
> Unit head | Chef de sous-section
> Data Exploration and Integration Lab (DEIL) | Lab d’exploration et 
> intégration de données (LEID)
> Center for Special Business Projects | Centre des Projets Spéciaux sur les 
> entreprises
> Statistics Canada | Statistique Canada
> (343) 998-3004
>  
> ___
> 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] [Talk-us] [Tagging] destination:street

[Martijn van Exel]

Hi Duane, 

Thanks. I had overlooked the examples page (even though I searched the OSM wiki 
for the exact term!)
I do appreciate the granularity of the destination:street tagging and would 
encourage the Telenav mappers to use it as well then, but we like to stick to 
conventions that are properly documented (not only in an example page). Since 
there is significant usage in N-America and some other regions [1], we could 
add it to the destination tag page [2]? 

My only issue with destination:street is that there’s still ambiguity when more 
than one street is on the sign, like here [3]. Would that then be 
destination:street=1300 So.;2100 So. and destination:ref=201 and 
destination:West Valley? The advantage of having a separate tag partly vanishes 
when you still need the semicolon separator?

Martijn van Exel

[1] http://taginfo.osm.org/keys/destination%3Astreet#map
 <http://taginfo.osm.org/keys/destination:street#map>
[ <http://taginfo.osm.org/keys/destination:street#map>2] 
http://wiki.openstreetmap.org/wiki/Key:destination 
<http://wiki.openstreetmap.org/wiki/Key:destination>
[3] http://openstreetcam.org/details/8230/168 
<http://openstreetcam.org/details/8230/168>

 <http://taginfo.osm.org/keys/destination%3Astreet#map>

 <http://taginfo.osm.org/keys/destination%3Astreet#map>
> On Jan 19, 2017, at 5:44 PM, Duane Gearhart <du...@mapzen.com> wrote:
> 
> Hey Martijn,
> 
> It looks correct to me - using the destination:street allows users to know if 
> the ramp is branching onto the specified street name vs. heading toward a 
> street name - examples are located here:
> http://wiki.openstreetmap.org/wiki/Exit_Info#Road_name_Example 
> <http://wiki.openstreetmap.org/wiki/Exit_Info#Road_name_Example>
> 
> Mappers have been using in the US too:
> http://overpass-turbo.eu/s/ln4 <http://overpass-turbo.eu/s/ln4>
> 
> Here is an example way:
> https://www.openstreetmap.org/way/11502773#map=19/39.21853/-76.65894 
> <https://www.openstreetmap.org/way/11502773#map=19/39.21853/-76.65894>
> 
> You can see how it is used in the directions:
> https://www.openstreetmap.org/directions?engine=mapzen_car=39.22079%2C-76.65959%3B39.22139%2C-76.65428
>  
> <https://www.openstreetmap.org/directions?engine=mapzen_car=39.22079%2C-76.65959%3B39.22139%2C-76.65428>
> 
> Regards,
> Duane
> 
> 
> 
> 
> On Thu, Jan 19, 2017 at 8:00 PM, Martijn van Exel <m...@rtijn.org 
> <mailto:m...@rtijn.org>> wrote:
> Hi all, 
> 
> The Telenav mapping team noticed quite a few destination:street tags on 
> (mostly) motorway_link off-ramps in Canada. This is an undocumented sub-tag 
> of the destination tag so I am curious how it is being used and if there is 
> some sort of consensus that is documented somewhere else than the OSM wiki.
> 
> An Overpass query surfaced 1883 cases, http://overpass-turbo.eu/s/ln2 
> <http://overpass-turbo.eu/s/ln2>  
> 
> Looking at a random one, http://www.openstreetmap.org/way/34154734 
> <http://www.openstreetmap.org/way/34154734> / 
> http://openstreetcam.org/details/10767/4194 
> <http://openstreetcam.org/details/10767/4194> — I think in the US we would 
> just map this as destination=Carman Road;Iriquois and destination:ref=1
> 
> So my question is whether this is some relic of a past practice, or is this 
> actively used and encouraged mapping practice and if so, where should it be 
> documented? 
> (https://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details 
> <https://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details> 
> seems to be a good candidate.)
> 
> We’re happy to help improve these tags based on OSC / Mapillary data but I 
> wanted to make sure first that this is the way you all want to go.
> 
> Happy mapping,
> 
> Martijn van Exel
> 
> 
> ___
> Tagging mailing list
> tagg...@openstreetmap.org <mailto:tagg...@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging 
> <https://lists.openstreetmap.org/listinfo/tagging>
> 
> 
> ___
> Talk-us mailing list
> talk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

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

Re: [Talk-ca] [Talk-us] destination:street

[Martijn van Exel]

In the US the prefix would typically be in the network tag, like network=US:US 
ref=89 for US highway 89, etc.
We have seen some of this in Canada as well. (CA:ON for Ontario highways etc.)
Martijn van Exel

> On Jan 20, 2017, at 12:57 AM, Paul Norman <penor...@mac.com> wrote:
> 
> On 1/19/2017 5:00 PM, Martijn van Exel wrote:
>> Looking at a random one, http://www.openstreetmap.org/way/34154734 / 
>> http://openstreetcam.org/details/10767/4194 — I think in the US we would 
>> just map this as destination=Carman Road;Iriquois and destination:ref=1
> 
> That is how it would be typically mapped in Canada in my experience, although 
> it might have a prefix to the ref.

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

[Talk-ca] destination:street

[Martijn van Exel]

Hi all, 

The Telenav mapping team noticed quite a few destination:street tags on 
(mostly) motorway_link off-ramps in Canada. This is an undocumented sub-tag of 
the destination tag so I am curious how it is being used and if there is some 
sort of consensus that is documented somewhere else than the OSM wiki.

An Overpass query surfaced 1883 cases, http://overpass-turbo.eu/s/ln2  

Looking at a random one, http://www.openstreetmap.org/way/34154734 
<http://www.openstreetmap.org/way/34154734> / 
http://openstreetcam.org/details/10767/4194 
<http://openstreetcam.org/details/10767/4194> — I think in the US we would just 
map this as destination=Carman Road;Iriquois and destination:ref=1

So my question is whether this is some relic of a past practice, or is this 
actively used and encouraged mapping practice and if so, where should it be 
documented? 
(https://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details 
<https://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details> 
seems to be a good candidate.)

We’re happy to help improve these tags based on OSC / Mapillary data but I 
wanted to make sure first that this is the way you all want to go.

Happy mapping,

Martijn van Exel

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

Re: [Talk-ca] [Talk-us] cardinal directions

[Martijn van Exel]

Martijn van Exel

> On Jan 18, 2017, at 9:35 PM, Paul Johnson <ba...@ursamundi.org> wrote:
> 
> On Wed, Jan 18, 2017 at 8:59 AM, Martijn van Exel <m...@rtijn.org 
> <mailto:m...@rtijn.org>> wrote:
> I am trying to be consistent with the outcome of the discussion that we had 
> on talk-us a couple of years ago. Right now both are used 
> (north/south/east/west as relation member role as well as direction on the 
> relation tag) but the former is used way more often. That’s why I am 
> suggesting going with the practice that has surfaced as the most popular, as 
> well as the outcome of earlier discussion. 
> 
> Perhaps I am not understanding you correctly, but I am *not* suggesting to 
> use tags on ways to indicate cardinal direction, just assign roles to 
> relation members. Agreed that adding this type of info to ways makes it 
> impossible to validate / maintain.
> 
> Right, I think we're on the same page.  I'm also suggesting it's high time we 
> revisited the issue as the tools to handle managing north/east/south/west 
> roles (as opposed to forward/backward) just plain never materialized.  If it 
> was going to happen, it would have already happened (it's been years!).

What tools were you thinking about? I remember submitting a patch to JOSM a 
while ago which did not get accepted.. That’s all I did on the tools end of 
things. Agreed support could be better.

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

Re: [Talk-ca] [Talk-us] cardinal directions

[Martijn van Exel]

I am trying to be consistent with the outcome of the discussion that we had on 
talk-us a couple of years ago. Right now both are used (north/south/east/west 
as relation member role as well as direction on the relation tag) but the 
former is used way more often. That’s why I am suggesting going with the 
practice that has surfaced as the most popular, as well as the outcome of 
earlier discussion. 

Perhaps I am not understanding you correctly, but I am *not* suggesting to use 
tags on ways to indicate cardinal direction, just assign roles to relation 
members. Agreed that adding this type of info to ways makes it impossible to 
validate / maintain.

This also does not have to preclude having separate e/w or n/s relations + a 
super relation — I think that is actually good practice for big relations to 
keep them manageable.

Martijn van Exel

> On Jan 13, 2017, at 11:40 PM, Paul Johnson <ba...@ursamundi.org> wrote:
> 
> 
> 
> On Fri, Jan 13, 2017 at 3:42 PM, Martijn van Exel <m...@rtijn.org 
> <mailto:m...@rtijn.org>> wrote:
> Hi all, 
> 
> Some of you may remember the discussion we had on tagging cardinal directions 
> in the US, which led to the wiki page[1] describing the current practice.
> Basically the convention we arrived on is to tag relation members with 
> role=north/east/south/west to indicate cardinal direction.
> This is backed up by usage in the US. About 75% of way members of Interstate 
> road relations have directional role members[2].
> 
> Can we not do this?  Can this not be a thing?  Can we instead go route master 
> and only have child relations have cardinal roles, with child ways being 
> exclusively forward/backward?  Because cardinal directions on the ways 
> themselves is 1) ambiguous AF and 2) breaks validation on a level that it can 
> take hours to days for experienced editors to manually validate, and can't be 
> automated as a result.
> 
> ___
> Talk-us mailing list
> talk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

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

Re: [Talk-ca] Road route relations: network tag

[Martijn van Exel]

Hm. Paul noted something similar. It does not sound like there is a clear
consensus about how networks should be tagged then. Perhaps more people can
weigh in and argue for the one or the other notation.

At least the tagging is consistent now, and would be easy to change in bulk
if the outcome is that underscore notation is preferred. The last thing I
would want to do is to impose a convention. The 'colon notation' is in use
in the U.S. and it made a lot of sense there. For what it's worth, it is
used by Scout to interpret numbered routes. I thought OSMAND supported it
too in the same notation, but I am not certain.

Martijn

Martijn van Exel
http://mvexel.github.io/

On Sat, Oct 29, 2016 at 1:08 PM, Stewart C. Russell <scr...@gmail.com>
wrote:

> On 2016-10-28 10:45 AM, Martijn van Exel wrote:
> > It's not documented that way anywhere that I could find. The colon
> > notation is. Based on the other comments and the documented standards we
> > started editing based on the spreadsheet.
>
> Well, it was here:
> http://wiki.openstreetmap.org/wiki/Relation:route#Road_routes
>
> roadca_transcanada  Canadian Trans-Canada highways
> roadca_on_primary   Ontario primary highways
>
> so now the docs are out of whack with reality.
>
> The colon notation does not seem to be universally accepted. It's not
> widely used in the UK or Germany, as far as I can see. The only road
> networks I can see in the UK are either scenic routes, with no obvious
> hierarchy, or E routes, which if the current national madness prevails,
> will have to disappear in the next couple of years for other reasons …
>
>  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] Road route relations: network tag

[Martijn van Exel]

Looks like these have all been resolved! Thanks all for your help.

Martijn van Exel
http://mvexel.github.io/

On Fri, Oct 28, 2016 at 2:38 PM, Martijn van Exel <m...@rtijn.org> wrote:

> Just ran the overpass query again and we're down to 1421 relations with
> underscore network tags, from 2313 yesterday.
>
> For those interested the query is
>
> area[name=Canada]->.canada;
> relation
>   ["route"="road"]["network"~"..\_.+"](area.canada);
> out;
>
> This does not give you any geometry.
>
> Martijn
>
> Martijn van Exel
> http://mvexel.github.io/
>
> On Thu, Oct 27, 2016 at 5:04 PM, Martijn van Exel <m...@rtijn.org> wrote:
>
>> I created a spreadsheet to track the relations and fixes. It doesn't lend
>> itself well to a MapRoulette challenge or I would have done that :)
>>
>> Includes handy direct JOSM link!
>>
>> https://docs.google.com/spreadsheets/d/1O1LGJk6r6gP6NrKYmdAu
>> LKsc0vdNcaTH_k0F_Wjwdio/edit?usp=sharing
>>
>> Let me know if this is workable.
>>
>> Martijn
>>
>> Martijn van Exel
>> http://mvexel.github.io/
>>
>> On Thu, Oct 27, 2016 at 4:21 PM, Denis Carriere <carriere.de...@gmail.com
>> > wrote:
>>
>>> I agree with Martjin, those tags should be corrected to *network*=CA:ON
>>>
>>> Good catch!
>>>
>>> *~~*
>>> *Denis Carriere*
>>> *GIS Software & Systems Specialist*
>>>
>>> *Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
>>> *OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
>>> GitHub: DenisCarriere <https://github.com/DenisCarriere>
>>> Email: carriere.de...@gmail.com
>>>
>>> On Thu, Oct 27, 2016 at 6:04 PM, Martijn van Exel <m...@rtijn.org> wrote:
>>>
>>>> Hi all,
>>>>
>>>> My mapping colleagues (not me, I only map in my spare time :)) noted
>>>> that there are some irregular network tags on highways in Canada. The usual
>>>> hierarchical notation[1] is in place in many relations, but we encountered
>>>> deviations from that where instead of the colon separator an underscore is
>>>> used, so for example instead of CA:ON we see ca_on, and some variations on
>>>> that.
>>>>
>>>> We are happy to (help) clean that up but didn't want to do so without
>>>> consulting you. Is there some local convention that we are unaware of? Can
>>>> we provide a dump of the affected relation IDs so we can fix them together?
>>>> It's about 400 relations in total, mostly in Ontario.
>>>>
>>>> [1] https://wiki.openstreetmap.org/wiki/Key:network#Hierarchical_format
>>>> - it has a Canada example!
>>>>
>>>> Martijn van Exel
>>>> http://mvexel.github.io/
>>>>
>>>> ___
>>>> 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] Road route relations: network tag

[Martijn van Exel]

Just ran the overpass query again and we're down to 1421 relations with
underscore network tags, from 2313 yesterday.

For those interested the query is

area[name=Canada]->.canada;
relation
  ["route"="road"]["network"~"..\_.+"](area.canada);
out;

This does not give you any geometry.

Martijn

Martijn van Exel
http://mvexel.github.io/

On Thu, Oct 27, 2016 at 5:04 PM, Martijn van Exel <m...@rtijn.org> wrote:

> I created a spreadsheet to track the relations and fixes. It doesn't lend
> itself well to a MapRoulette challenge or I would have done that :)
>
> Includes handy direct JOSM link!
>
> https://docs.google.com/spreadsheets/d/1O1LGJk6r6gP6NrKYmdAuLKsc0vdNc
> aTH_k0F_Wjwdio/edit?usp=sharing
>
> Let me know if this is workable.
>
> Martijn
>
> Martijn van Exel
> http://mvexel.github.io/
>
> On Thu, Oct 27, 2016 at 4:21 PM, Denis Carriere <carriere.de...@gmail.com>
> wrote:
>
>> I agree with Martjin, those tags should be corrected to *network*=CA:ON
>>
>> Good catch!
>>
>> *~~*
>> *Denis Carriere*
>> *GIS Software & Systems Specialist*
>>
>> *Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
>> *OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
>> GitHub: DenisCarriere <https://github.com/DenisCarriere>
>> Email: carriere.de...@gmail.com
>>
>> On Thu, Oct 27, 2016 at 6:04 PM, Martijn van Exel <m...@rtijn.org> wrote:
>>
>>> Hi all,
>>>
>>> My mapping colleagues (not me, I only map in my spare time :)) noted
>>> that there are some irregular network tags on highways in Canada. The usual
>>> hierarchical notation[1] is in place in many relations, but we encountered
>>> deviations from that where instead of the colon separator an underscore is
>>> used, so for example instead of CA:ON we see ca_on, and some variations on
>>> that.
>>>
>>> We are happy to (help) clean that up but didn't want to do so without
>>> consulting you. Is there some local convention that we are unaware of? Can
>>> we provide a dump of the affected relation IDs so we can fix them together?
>>> It's about 400 relations in total, mostly in Ontario.
>>>
>>> [1] https://wiki.openstreetmap.org/wiki/Key:network#Hierarchical_format
>>> - it has a Canada example!
>>>
>>> Martijn van Exel
>>> http://mvexel.github.io/
>>>
>>> ___
>>> 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] Road route relations: network tag

[Martijn van Exel]

I created a spreadsheet to track the relations and fixes. It doesn't lend
itself well to a MapRoulette challenge or I would have done that :)

Includes handy direct JOSM link!

https://docs.google.com/spreadsheets/d/1O1LGJk6r6gP6NrKYmdAuLKsc0vdNcaTH_k0F_Wjwdio/edit?usp=sharing

Let me know if this is workable.

Martijn

Martijn van Exel
http://mvexel.github.io/

On Thu, Oct 27, 2016 at 4:21 PM, Denis Carriere <carriere.de...@gmail.com>
wrote:

> I agree with Martjin, those tags should be corrected to *network*=CA:ON
>
> Good catch!
>
> *~~*
> *Denis Carriere*
> *GIS Software & Systems Specialist*
>
> *Twitter: @DenisCarriere <https://twitter.com/DenisCarriere/>*
> *OSM: DenisCarriere <https://www.openstreetmap.org/user/DenisCarriere>*
> GitHub: DenisCarriere <https://github.com/DenisCarriere>
> Email: carriere.de...@gmail.com
>
> On Thu, Oct 27, 2016 at 6:04 PM, Martijn van Exel <m...@rtijn.org> wrote:
>
>> Hi all,
>>
>> My mapping colleagues (not me, I only map in my spare time :)) noted that
>> there are some irregular network tags on highways in Canada. The usual
>> hierarchical notation[1] is in place in many relations, but we encountered
>> deviations from that where instead of the colon separator an underscore is
>> used, so for example instead of CA:ON we see ca_on, and some variations on
>> that.
>>
>> We are happy to (help) clean that up but didn't want to do so without
>> consulting you. Is there some local convention that we are unaware of? Can
>> we provide a dump of the affected relation IDs so we can fix them together?
>> It's about 400 relations in total, mostly in Ontario.
>>
>> [1] https://wiki.openstreetmap.org/wiki/Key:network#Hierarchical_format
>> - it has a Canada example!
>>
>> Martijn van Exel
>> http://mvexel.github.io/
>>
>> ___
>> 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] Slack

[Martijn van Exel]

Hi all, me again. Perhaps you know that OSM US started a Slack community a
while ago. This has attracted a lot of folks and turned out to be a great
place to chat with fellow mappers / organizers.

If you don't know Slack, it's basically IRC with a friendlier face.
Unfortunately it's not open source, but we chose this pragmatically: the
OSM US board already used Slack and a fair number of OSM community members
already used it for work as well.

This is not for the US alone. Now there's also a Canada channel on there.
If you want to join, go to https://osmus-slack.herokuapp.com/ to
self-invite yourself.

Martijn van Exel
http://mvexel.github.io/
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Road route relations: network tag

[Martijn van Exel]

Hi all,

My mapping colleagues (not me, I only map in my spare time :)) noted that
there are some irregular network tags on highways in Canada. The usual
hierarchical notation[1] is in place in many relations, but we encountered
deviations from that where instead of the colon separator an underscore is
used, so for example instead of CA:ON we see ca_on, and some variations on
that.

We are happy to (help) clean that up but didn't want to do so without
consulting you. Is there some local convention that we are unaware of? Can
we provide a dump of the affected relation IDs so we can fix them together?
It's about 400 relations in total, mostly in Ontario.

[1] https://wiki.openstreetmap.org/wiki/Key:network#Hierarchical_format -
it has a Canada example!

Martijn van Exel
http://mvexel.github.io/
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] MapRoulette challenges

[Martijn van Exel]

Yes, they did, and they mainly focused on the main metros I believe. The
remaining ones should be mainly outside of the larger urban areas. See
http://maproulette.org/view/499 for locations of the tasks.

Martijn

Martijn van Exel
http://mvexel.github.io/

On Fri, Oct 21, 2016 at 10:55 AM, James <james2...@gmail.com> wrote:

> I think mapbox covered this in a previous pass on the canadian
> motorways(and documented this pretty well):
> https://gist.github.com/manoharuss/3a1b4f640aaf2c052365fcb1ddb09beb
> https://github.com/mapbox/mapping/issues/220
> https://gist.github.com/poornibadrinath/9333f1489732c32c3ffadd58e3068b7e
> https://www.openstreetmap.org/user/poornibadrinath/diary/39246
>
> On Fri, Oct 21, 2016 at 10:49 AM, Martijn van Exel <m...@rtijn.org> wrote:
>
>> Hi all,
>>
>> I hope you are aware of MapRoulette! If not, it's a micro-tasking tool
>> for OSM where you can solve small problems / make small enhancements to OSM
>> data in a randomized fashion.
>>
>> You may not be aware that there are quite a few Canada specific
>> challenges already. One of them was drawn up by my colleagues at Telenav
>> and I wanted to get your feedback. This is around motorway exits. We have
>> had an extensive exit_to vs destination discussion about this in the US and
>> this eventually came out clearly in favor of using destination. This is now
>> the majority tag for exit signposts in the US. We identified ~1200 exits in
>> Canada that don't use this yet. These are in challenge
>> http://maproulette.org/map/499
>>
>> If you want to give it a try and send me feedback on this, I would
>> appreciate it. There is pretty good OpenStreetView and also Mapillary
>> coverage for many main highways in Canada already so most can be resolved
>> without local knowledge.
>>
>> Thanks for your time!
>>
>> Martijn
>>
>> ___
>> 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] MapRoulette challenges

[Martijn van Exel]

Hi all,

I hope you are aware of MapRoulette! If not, it's a micro-tasking tool for
OSM where you can solve small problems / make small enhancements to OSM
data in a randomized fashion.

You may not be aware that there are quite a few Canada specific challenges
already. One of them was drawn up by my colleagues at Telenav and I wanted
to get your feedback. This is around motorway exits. We have had an
extensive exit_to vs destination discussion about this in the US and this
eventually came out clearly in favor of using destination. This is now the
majority tag for exit signposts in the US. We identified ~1200 exits in
Canada that don't use this yet. These are in challenge
http://maproulette.org/map/499

If you want to give it a try and send me feedback on this, I would
appreciate it. There is pretty good OpenStreetView and also Mapillary
coverage for many main highways in Canada already so most can be resolved
without local knowledge.

Thanks for your time!

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

[Talk-ca] Telenav mapping turn restrictions

[Martijn van Exel]

Hi all,

I wanted to give you a heads up that my colleagues on the Telenav map team
are starting work on adding turn restrictions in Toronto, Montréal, and
later on also Vancouver, Ottawa and Calgary. We are using OpenStreetView
and Mapillary as sources. If you have any questions or concerns, please
reach out to me and we will address it right away.

For conditional (time-restricted) turn restrictions, we intend to use the
schema described in
http://wiki.openstreetmap.org/wiki/Conditional_restrictions. We encounter a
more complex mapping of conditional turn restrictions sometimes, where
mappers have used day_on / day_off and hour_on / hour_off. This is uncommon
and as far as I know not recommended for mapping time-restricted turn
restrictions. If we encounter these, our proposal would be to remove these
tags and if necessary replace them with the preferred scheme as described
on the wiki. Opinions?

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

[Talk-ca] Please donate today to keep OSM running smoothly and independently!

[Martijn van Exel]

Hi all, 

The OSM Foundation (of which I am a board member) is holding its about-annual 
donation drive. We are already at a little over 10% of our €70k (~USD 78k) 
goal, so we have a substantial amount still to go. OSMF runs a very lean 
organization, but we will still need money[1] to keep OpenStreetMap running 
smoothly and independently and protect its trademarks. Your donation helps OSMF 
do these things. So please donate today at donate.openstreetmap.org. Donations 
of any amount are greatly and genuinely appreciated! If you have already: thank 
you very much!

Feel free to translate / adopt this message and forward it to your local 
communications channels. Thank you!

Martijn

[1] Feel free to inspect our financials at 
https://wiki.osmfoundation.org/wiki/Finances 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec attributes (roads)

[Martijn van Exel]

On 09/12/2016 06:50 PM, Stewart C. Russell wrote:

On 2016-09-12 04:08 PM, Martijn van Exel wrote:

Aren't these files grouped by feature type? So if we look at roads we
wouldn't also necessarily need to look at land use boundaries etc.?


Canvec - the product supplied by NRCan to the general public - always
was split by feature type. It's the OSM tiles, of structure decided long
ago, that lump everything together.

It's also available as effectively seamless FGDBs if you want to avoid
the cleanup required after using tiled data. The FGDBs retain the
critically important survey dates and accuracies - so you can easily see
how much data's 40 years old and has ±75 m positional accuracy.



Good to know.
Are any of the transport related datasets that old or that inaccurate?

I created an initial Canvec road network translation file for ogr2osm, 
so you can convert the Canvec shapefiles to OSM format easily (if you 
know how to work ogr2osm - let me know if you need help, but Paul Norman 
is the expert here!)


It is located at 
https://github.com/mvexel/canvec-ogr2osm-translation/blob/master/canvec2016.py 
and I hope for many forks and improvements. Right now it does a basic 
job of translating the road classes to OSM types, and the most obvious 
attributes to the corresponding OSM tags.


Let me know what you all think.

Martijn

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

Re: [Talk-ca] Canvec attributes (roads)

[Martijn van Exel]

Aren't these files grouped by feature type? So if we look at roads we
wouldn't also necessarily need to look at land use boundaries etc.? At
least that's what I am getting looking at
http://geogratis.gc.ca/api/en/nrcan-rncan/ess-sst/23387971-b6d3-4ded-a40b-c8e832b4ea08.html

--
  Martijn van Exel
  m...@rtijn.org



On Sun, Sep 11, 2016, at 12:59, James wrote:
> Plus it would help identify which parts and canvec are actually needed
> vs importing a bunch of forests and hoping for some roads
>
> On Sep 11, 2016 2:48 PM, "John Marshall" <rps...@gmail.com> wrote:
>> Great idea Martijn,
>> One of the big problems of OSM in Canada is there are many missing
>> road where there are no local mappers. Canada is very big. Any tools
>> to help map unmapped area of Canada gets a big +1 from me.
>> John
>> John Marshall
>>
>> On Sep 9, 2016 17:36, "Martijn van Exel" <m...@rtijn.org> wrote:
>>> Hi all,
>>>
>>>  A few colleagues at Telenav and myself are looking at Canvec 2016.
>>>  Roads
>>>  specifically. I am sure some of you already have done that.
>>>  Something we
>>>  are looking into a workflow that is something like this
>>>  (simplified):
>>>
>>>  Canvec 2016 Shapefiles --> Conflation engine (Cygnus [1]) -->
>>>  Tasking
>>>  manager
>>>
>>>  The output of the conflation would be an OSM XML change file that
>>>  could
>>>  be (selectively) applied in JOSM. It would contain new / changed
>>>  ways as
>>>  well as some new or changed tags. All proposed updates would be
>>>  verified
>>>  manually (through tasking manager.)
>>>
>>>  What do you think about this idea?
>>>
>>>  The conflation engine takes OSM PBF as input, so the Canvec
>>>  shapefiles
>>>  would need to be translated (using ogr2osm). That would require an
>>>  ogr2osm translation file. I wonder if someone already did this?
>>>  (I am
>>>  using this [2] attribute list as reference.)
>>>
>>>  [1]https://www.openstreetmap.org/user/mvexel/diary/37808
>>>  
>>> [2]http://ftp.geogratis.gc.ca/pub/nrcan_rncan/vector/canvec/doc/CanVec_Catalogue_50K_Transport/SRDB_EXPL_ESSIM_50K_Transport-sd-en.html#div-1330009
>>>  --
>>>  Martijn van Exel
>>> m...@rtijn.org
>>>
>>>  ___
>>>  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] Canvec attributes (roads)

[Martijn van Exel]

Paul, 
thanks, so perhaps we can start a new one for this data.
Perhaps we can crowdsource it? Has that been done before?

(Wouldn't it be interesting to have a github repo with the translation
file, and each time a commit is made an ogr2osm run is fired and the
resulting OSM file made available somewhere?)
-- 
  Martijn van Exel
  m...@rtijn.org

On Fri, Sep 9, 2016, at 15:54, Paul Norman wrote:
> On 9/9/2016 2:34 PM, Martijn van Exel wrote:
> > The conflation engine takes OSM PBF as input, so the Canvec shapefiles
> > would need to be translated (using ogr2osm).
> 
> The CanVec we've used in the past has been supplied in OSM XML format. 
> No one has proposed a new import with a different format, so I doubt 
> there are any ogr2osm translations available.
> 
> ___
> 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] Canvec attributes (roads)

[Martijn van Exel]

Hi all, 

A few colleagues at Telenav and myself are looking at Canvec 2016. Roads
specifically. I am sure some of you already have done that. Something we
are looking into a workflow that is something like this (simplified):

Canvec 2016 Shapefiles --> Conflation engine (Cygnus [1]) --> Tasking
manager

The output of the conflation would be an OSM XML change file that could
be (selectively) applied in JOSM. It would contain new / changed ways as
well as some new or changed tags. All proposed updates would be verified
manually (through tasking manager.)

What do you think about this idea?

The conflation engine takes OSM PBF as input, so the Canvec shapefiles
would need to be translated (using ogr2osm). That would require an
ogr2osm translation file. I wonder if someone already did this? (I am
using this [2] attribute list as reference.)

[1]https://www.openstreetmap.org/user/mvexel/diary/37808
[2]http://ftp.geogratis.gc.ca/pub/nrcan_rncan/vector/canvec/doc/CanVec_Catalogue_50K_Transport/SRDB_EXPL_ESSIM_50K_Transport-sd-en.html#div-1330009
-- 
  Martijn van Exel
  m...@rtijn.org

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

[Talk-ca] ImproveOSM new beta

[Martijn van Exel]

Hi all, 

I don’t know how familiar you are with ImproveOSM. It’s Telenav’s big data 
thrown at OSM. We detect missing roads, missing turn restrictions, and one-way 
streets. There is a JOSM plugin as well as a web site. 

The web site is what I wanted to highlight. We are about to overhaul it and 
it’s now completely based off of iD. You can find the beta version here: 
http://osm-id.skobbler.net:8000

What I would really like is more feedback from mappers. Is this useful and 
usable? What are the top 5 things you would improve or do differently?

As always your feedback is extremely valuable, and helps inform what the end 
product will look like. 

Respond on this thread, file an issue on 
https://github.com/Telenav/improveosm.org/issues  (no source there yet) or 
email me directly. 

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

Re: [Talk-ca] unnamed roads

[Martijn van Exel]

A correct example link is http://maproulette.org/map/342/362184 rather
than the one in my previous message. Due to a bug in either MapRoulette
or Leaflet you would need to zoom out 1 level to see the map context. 

-- 
  Martijn van Exel
  m...@rtijn.org

On Thu, Sep 1, 2016, at 16:31, Martijn van Exel wrote:
> Hi all, 
> 
> My colleagues created a set of MapRoulette challenges for Canada
> recently, based on various topology checks. A lot of them need work
> still, but I was curious about one in particular, the 'Unnamed Roads'.
> Example: http://maproulette.org/map/341/363201 
> 
> Is it possible to fix these without on-the-ground knowledge? Is there a
> names layer available similar to TIGER in the US? If not, can we help
> create such a layer? (I tried the Geobase Roads WMS layer but that
> doesn't really seem to have roads in it, nor does the Canvec layer)
> 
> Thanks for helping me figure out how to make this useful!
> If you have ideas based on your mapping experience what common errors
> are that would impede routing  / navigation let me know.
> -- 
>   Martijn van Exel
>   m...@rtijn.org

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

[Talk-ca] unnamed roads

[Martijn van Exel]

Hi all, 

My colleagues created a set of MapRoulette challenges for Canada
recently, based on various topology checks. A lot of them need work
still, but I was curious about one in particular, the 'Unnamed Roads'.
Example: http://maproulette.org/map/341/363201 

Is it possible to fix these without on-the-ground knowledge? Is there a
names layer available similar to TIGER in the US? If not, can we help
create such a layer? (I tried the Geobase Roads WMS layer but that
doesn't really seem to have roads in it, nor does the Canvec layer)

Thanks for helping me figure out how to make this useful!
If you have ideas based on your mapping experience what common errors
are that would impede routing  / navigation let me know.
-- 
  Martijn van Exel
  m...@rtijn.org

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

Re: [Talk-ca] aerial imagery for missing roads

[Martijn van Exel]

Interesting, that seems to be worth a look! Do you happen to know who these 
open data people are? Do similar open data groups / people exist in other 
provinces?

Martijn

> On Jun 25, 2016, at 8:16 AM, Kevin Farrugia  wrote:
> 
> Morning everyone,
> 
> I was looking at information on one of the Province's imagery programs 
> (SWOOP: 
> https://dr6j45jk9xcmk.cloudfront.net/documents/3609/lio-swoop2015-eng-final-2014-05-13.pdf
>  
> )
>  and I had previously assumed that the imagery was paid for by the province 
> but the rights still owned by the imagery company, which is the case where I 
> work.  However, it looks like they might purchase the imagery outright 
> because it says the imagery is owned by the Queen's Printer, which is the 
> holder of the Crown's copyrights in Ontario.
> 
> If that's the case you can try contacting their open data team to see if they 
> can persuade the Ministry of Natural Resources to release the data openly 
> under the Open Government Directive as a WMS/TIFFs or you can lodge a FIPPA 
> request to have it released (I don't know how this affects you or us being 
> able to use it in OSM, however).
> 
> You can check out what their imagery looks like here to see if it's worth 
> your time contacting them: 
> http://www.giscoeapp.lrc.gov.on.ca/matm/Index.html?site=Make_A_Topographic_Map=MATM=en-US
>  
> 
>  (in Map Layers turn off Topographic Data to see the imagery).
> 
> -Kevin (Kevo)
> 
> 
> On Sat, Jun 25, 2016 at 7:52 AM, Begin Daniel  > wrote:
> Missing access=no and access=private tags I understand...
> Daniel
> 
> -Original Message-
> From: Stewart C. Russell [mailto:scr...@gmail.com ]
> Sent: June-24-16 22:45
> To: talk-ca@openstreetmap.org 
> Subject: Re: [Talk-ca] aerial imagery for missing roads
> 
> On 2016-06-23 10:26 PM, Pierre Béland wrote:
> >
> > Going north outside of urban zones, there are many tracks for lumber
> > areas. Hard to assess the accessibility of such roads for cars.
> 
> Most logging roads, certainly in BC, are private. While they look large, and 
> make tempting additions to the map, accidentally routing traffic along them 
> could be fatal. Logging trucks don't (can't!) stop, and unless you have 
> authorization and the right radio to call in the checkpoints, the controller 
> won't be able to tell you if there's a truck coming that you need to get out 
> of the way of.
> 
> CanVec also mistakenly digitized a bunch of private wind farm access roads in 
> Ontario, such as https://www.openstreetmap.org/way/39334427 
>  .
> While using these might not be life-threatening, it is trespassing to use 
> them.
> 
> cheers,
>  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 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] aerial imagery for missing roads

[Martijn van Exel]

Should we assume that a reasonable amount of these private or even dangerous 
routes have been mapped as public, potentially routable? What would be a good 
way to inspect these? Do we have reference data on these logging roads? A 
MapRoulette challenge could be useful.

Martijn

> On Jun 24, 2016, at 8:45 PM, Stewart C. Russell  wrote:
> 
> Most logging roads, certainly in BC, are private. While they look large,
> and make tempting additions to the map, accidentally routing traffic
> along them could be fatal. Logging trucks don't (can't!) stop, and
> unless you have authorization and the right radio to call in the
> checkpoints, the controller won't be able to tell you if there's a truck
> coming that you need to get out of the way of.
> 
> CanVec also mistakenly digitized a bunch of private wind farm access
> roads in Ontario, such as https://www.openstreetmap.org/way/39334427 
>  .
> While using these might not be life-threatening, it is trespassing to
> use them.

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

Re: [Talk-ca] aerial imagery for missing roads

[Martijn van Exel]

Hi Stewart, all, 

From talking to some Canadian (provincial and local) government agency folks at 
a conference recently I got the sense that the open data landscape is pretty 
different than here in the US (which is again very different from most places 
in Europe where I am from originally).

The aerial route seems tricky from what you’re telling me. Unless we get access 
to a more up to date commercial resource. I wonder what opportunities the more 
recent versions of Canvec / Canvec+ road layers offer to find and complete 
newer roads in OSM. Has there been much effort into looking at that? The OSM 
folks here at Telenav where I work have built a conflation engine that may help 
integrate newer data into OSM and we could try that out on a smaller area.

Martijn

> On Jun 22, 2016, at 6:29 PM, Stewart C. Russell  wrote:
> 
> Hi Martijn,
> 
>> I am wondering if you know of any more recent aerial imagery that may be
>> available? Or other suggestions to fill in these missing roads? (We have
>> found many, many cases in Canada alone)
> 
> We don't have a national mapping agency in Canada that gives everything
> away for free. Aerial imagery is typically carried out every couple of
> years by the provinces, but in agricultural areas only. This is not free
> and tends to cost anything from $10-150 / sq km just to see. Coverage is
> spotty, and depends on the province's priorities.
> 
> Within 10 miles of the Great Lakes (so, not in your example) we used to
> have access to wonderful USGS imagery. We can no longer see it in
> Canada, although I suspect the images are still collected and may be
> geofenced. Can't have free data getting in the way of Provincial cost
> recovery, can we?
> 
> cheers,
> 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] aerial imagery for missing roads

[Martijn van Exel]

Merci Daniel!
I can read French …ehm.. okay but don’t know it well enough to write. So feel 
free to respond in French, and I will probably be able to make sense of it. 
Again my apologies!
Martijn

> On Jun 22, 2016, at 11:40 AM, Begin Daniel <jfd...@hotmail.com> wrote:
> 
> Traduction en français …
> Salut à tous,
>  
> Excusez le message en anglais seulement, mon français est trop pauvre pour 
> être capable d'écrire quelque chose de cohérent.
>  
> Mes collègues de Telenav ont identifié un groupe de routes manquantes au 
> Canada. Celles-ci sont affichées sous forme de tuiles sur le site Web 
> ImproveOSM[1] et dans le plug-in ImproveOSM de l'application JOSM.
>  
> Le défi avec ces routes est que nous ne disposons pas toujours des images 
> aériennes pour nous permettre de cartographier ces dernières. Voici un 
> exemple [2].
>  
> Vous pouvez voir qu'il y a des travaux en cours, mais l'imagerie est trop 
> vieille pour nous montrer où les routes sont.
>  
> Je me demande si vous connaissez des images aériennes plus récentes qui 
> peuvent être disponibles? Ou d'autres suggestions pour remplir ces routes 
> manquantes? (Nous avons trouvé beaucoup, beaucoup de cas au Canada seulement)
>  
> Merci,
> Martijn
>  
>  
> From: Martijn van Exel [mailto:m...@rtijn.org] 
> Sent: June-22-16 12:06
> To: Talk-CA OpenStreetMap
> Subject: [Talk-ca] aerial imagery for missing roads
>  
> Hi all, 
>  
> Excuse my English only, my French is too poor to be able to write something 
> coherent. 
>  
> My colleagues at Telenav have identified a bunch of missing roads in Canada. 
> These are displayed as tiles on the improve-osm web site [1] and in the 
> ImproveOSM JOSM plugin.
>  
> The challenge with these is that we do not always have the aerial imagery to 
> allow us to map these. Here is an example [2].
>  
> You can see that there is construction going on but the imagery is too old to 
> show us where the roads are.
>  
> I am wondering if you know of any more recent aerial imagery that may be 
> available? Or other suggestions to fill in these missing roads? (We have 
> found many, many cases in Canada alone)
>  
> Thanks,
> Martijn
>  
> [1] See for example: 
> http://www.improve-osm.org/#48.3864397,-71.3031900,17/layer=OSM/OPEN/false,1-0-0/true,1-0-0-0-0/false,1-0
>  
> <http://www.improve-osm.org/#48.3864397,-71.3031900,17/layer=OSM/OPEN/false,1-0-0/true,1-0-0-0-0/false,1-0>
> [2] 
> https://www.dropbox.com/s/0bt0yrc1ppmhdhj/Screenshot%202016-06-22%2009.10.21.png?dl=0
>  
> <https://www.dropbox.com/s/0bt0yrc1ppmhdhj/Screenshot%202016-06-22%2009.10.21.png?dl=0>
>  - this location in OSM: 
> https://www.openstreetmap.org/#map=17/52.29692/-114.08170 
> <https://www.openstreetmap.org/#map=17/52.29692/-114.08170>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] aerial imagery for missing roads

[Martijn van Exel]

Hi all, 

Excuse my English only, my French is too poor to be able to write something 
coherent. 

My colleagues at Telenav have identified a bunch of missing roads in Canada. 
These are displayed as tiles on the improve-osm web site [1] and in the 
ImproveOSM JOSM plugin.

The challenge with these is that we do not always have the aerial imagery to 
allow us to map these. Here is an example [2].

You can see that there is construction going on but the imagery is too old to 
show us where the roads are.

I am wondering if you know of any more recent aerial imagery that may be 
available? Or other suggestions to fill in these missing roads? (We have found 
many, many cases in Canada alone)

Thanks,
Martijn

[1] See for example: 
http://www.improve-osm.org/#48.3864397,-71.3031900,17/layer=OSM/OPEN/false,1-0-0/true,1-0-0-0-0/false,1-0
 

[2] 
https://www.dropbox.com/s/0bt0yrc1ppmhdhj/Screenshot%202016-06-22%2009.10.21.png?dl=0
 - this location in OSM: 
https://www.openstreetmap.org/#map=17/52.29692/-114.08170 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] A New MapRoulette update

[Martijn van Exel]

Hey all,

I wanted to give a quick update on New MapRoulette. Mainly because went
through some breaking updates to the server last night which causes the
database to be purged. This should not happen much more as we get closer to
a final release. I have populated the database with a good number of tasks
so there is something to do.

After this update, the most significant new feature is that every user who
logs in for the first time now gets a Project that (s)he owns. Within that
Project, you can create as many challenges as you want. See it as your own
space within MapRoulette that you own. The challenge creation process is
newly enhanced with GeoJSON support. You can now create tasks for your
challenge in three ways: 1) Overpass query 2) Upload GeoJSON and 3) point
to a GeoJSON file on the internet. New MapRoulette will consume the GeoJSON
and turn every Feature into a Task. I invite you to try it out!

Before release, we will also improve the challenge search / discovery
process. If you have ideas about this, let me know as well.

Finally, I marked a few issues as 'low hanging fruit'[1]. If you want to
contribute to MapRoulette, perhaps those are a good start. They are mainly
front end glitches that should be easy to fix. Of course, if you want to
dive deeper into the back end, that's great too ;)

If you haven't tried New MapRoulette yet, head over to
http://maproulette.org:8080/ and let me know what you think.

Feel free to translate / forward this to your local lists.

[1]
https://github.com/maproulette/maproulette2/issues?q=is%3Aissue+is%3Aopen+label%3A%22low+hanging+fruit%22
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Open position for an administrative assistant to the OSMF board

[Martijn van Exel]

Hi all, 

The OSM Foundation has an open position for a part time administrative 
assistant to the board of directors (on which I sit). 
We have a blog post that talks about it[0] which has a link to the job 
description and explains how to apply as well. Please consider applying if you 
believe you are a great person to fill this position, or forward to anyone you 
think may be a great candidate. Thanks!

Martijn
OSMF board

[0] 
https://blog.openstreetmap.org/2016/05/11/openstreetmap-foundation-is-hiring-an-administrative-assistant/
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] ImproveOSM data refresh and some updates

[Martijn van Exel]

Hi all, 

ImproveOSM has just seen a data refresh that I thought I’d let you know about. 
We ran the latest GPS data against OSM data from May 4 and the results are live 
on the ImproveOSM web site and JOSM plugins. That said, don’t hesitate to let 
me know if you find data you think is incorrect or have ideas of what could be 
improved. There is also a feedback tool on improve-osm.org you can use for that.

We made some usability improvements to the plugin as well, I wrote about those 
on the Improve OSM blog[0]. That post also contains a link to this 7-question 
survey about ImproveOSM[1]. If you have a few minutes to complete it, you are 
helping us make ImproveOSM a better tool for all of us. 

Martijn

[0] 
http://blog.improve-osm.org/en/updates-to-improveosm-josm-plugin-for-better-usability/
 

[1] http://goo.gl/forms/Oa7tFEpNSA  The survey 
does not collect personal information. However, if you are not comfortable with 
submitting anything through Google Forms, here’s a PDF: 
https://www.dropbox.com/s/q13n0jkk6chirk3/Help%20Improve%20ImproveOSM.pdf?dl=0 

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

Re: [Talk-ca] New project update

[Martijn van Exel]

Bjenk — 
Perhaps a micro-tasking tool such as MapRoulette (which I created) would be 
useful to help guide your thinking. I am actively looking for MapRoulette pilot 
projects involving government collaboration. MapRoulette has proven to be a 
very effective tool for solving specific problems or adding specific data types 
to OSM. Let me know if you would like to know more.
Martijn

> On Apr 21, 2016, at 10:41 AM, Ellefsen, Bjenk (STATCAN) 
>  wrote:
> 
> Paul, 
> 
> All this is open for discussion at this point. We are looking at all the 
> options.
> By defining a project its more like stating what information we wish to focus 
> on.
> We hope to work with the OSM community and we are looking at different ways 
> of doing that.
> We also have different data sources that we will be evaluating to potentially 
> link to these buildings.
> 
> Thanks for your feedback!
> 
> Bjenk
> 
> -Original Message-
> From: Paul Ramsey [mailto:pram...@cleverelephant.ca] 
> Sent: April-21-16 12:26 PM
> To: Ellefsen, Bjenk (STATCAN) 
> Cc: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] New project update
> 
> Hey Bjenk,
> When you say "define a project" are you talking about
> 
> (a) describing a scope of work that StatsCan intends to resource and complete?
> (b) describing a scope of work that StatsCan hopes the OSM community
> will complete on your behalf?
> 
> You've used the passive voice in describing the actual collection in
> your description below, so it's not completely clear who you think
> will be collecting the information.
> 
> ATB,
> 
> P
> 
> 
> On Thu, Apr 21, 2016 at 8:35 AM, Ellefsen, Bjenk (STATCAN)
>  wrote:
>> Hello everyone,
>> 
>> Basically, what we would like to do is define a project for OSM to collect
>> information about non-residential buildings.
>> We would like to popose a list of what would be collected. We were thinking
>> of identifying specific areas to start with.
>> 
>> Cheers,
>> 
>> Bjenk Ellefsen, PhD
>> 
>> Center for Special Business Projects | Centre des Projets Spéciaux sur les
>> entreprises
>> Statistics Canada | Statistiques Canada
>> 
>> 
>> 
>> 
>> ___
>> 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] New project update

[Martijn van Exel]

Bjenk — 
Perhaps a micro-tasking tool such as MapRoulette (which I created) would be 
useful to help guide your thinking. I am actively looking for MapRoulette pilot 
projects involving government collaboration. MapRoulette has proven to be a 
very effective tool for solving specific problems or adding specific data types 
to OSM. Let me know if you would like to know more.
Martijn

> On Apr 21, 2016, at 10:41 AM, Ellefsen, Bjenk (STATCAN) 
>  wrote:
> 
> Paul, 
> 
> All this is open for discussion at this point. We are looking at all the 
> options.
> By defining a project its more like stating what information we wish to focus 
> on.
> We hope to work with the OSM community and we are looking at different ways 
> of doing that.
> We also have different data sources that we will be evaluating to potentially 
> link to these buildings.
> 
> Thanks for your feedback!
> 
> Bjenk
> 
> -Original Message-
> From: Paul Ramsey [mailto:pram...@cleverelephant.ca] 
> Sent: April-21-16 12:26 PM
> To: Ellefsen, Bjenk (STATCAN) 
> Cc: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] New project update
> 
> Hey Bjenk,
> When you say "define a project" are you talking about
> 
> (a) describing a scope of work that StatsCan intends to resource and complete?
> (b) describing a scope of work that StatsCan hopes the OSM community
> will complete on your behalf?
> 
> You've used the passive voice in describing the actual collection in
> your description below, so it's not completely clear who you think
> will be collecting the information.
> 
> ATB,
> 
> P
> 
> 
> On Thu, Apr 21, 2016 at 8:35 AM, Ellefsen, Bjenk (STATCAN)
>  wrote:
>> Hello everyone,
>> 
>> Basically, what we would like to do is define a project for OSM to collect
>> information about non-residential buildings.
>> We would like to popose a list of what would be collected. We were thinking
>> of identifying specific areas to start with.
>> 
>> Cheers,
>> 
>> Bjenk Ellefsen, PhD
>> 
>> Center for Special Business Projects | Centre des Projets Spéciaux sur les
>> entreprises
>> Statistics Canada | Statistiques Canada
>> 
>> 
>> 
>> 
>> ___
>> 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] State of the Map US - last call for proposals

[Martijn van Exel]

Hi all, 

tl;dr submit your proposal for SOTM US this week! 
https://openstreetmap.us/2016/03/sotmus-cfp-2016/ 


Time flies - the call for proposals for SOTM US is closing this Sunday! The 
good news is that you still have a few days to submit your proposal to speak, 
do a lightning talk, conduct a workshop or any kind of session or event you 
have in mind. If you were at SOTM US last year, you may remember the 
#MyFirstOSMEdit map in the main hall [1] - that was submitted as a proposal 
too! So don’t be afraid to think beyond the standard '20 minute talk’ 
template.. What SOTM US will look like this year is entirely up to you! We want 
this year’s conference to reflect the diversity and creativity of the OSM 
community more than ever before. So give it some thought and submit your 
proposal no later than Sunday the 17th. All we need is a 200 word (max) 
abstract and a few bits of other information. Let me know if there is anything 
I can do to help.

Martijn

[1] Scroll down 
https://twitter.com/search?q=%23myfirstOSMedit%20%23sotmus=typd 
 for some great 
pictures___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] New MapRoulette challenges

[Martijn van Exel]

Hi everyone — 

I was looking at MapRoulette again and seeing some progress on the new Canada 
challenges I put up recently. Here’s an overview:

Bad Ramp Angles: 478 total, 478 remaining
Connectivity Errors: 54 total, ALL FIXED
Miscategorized Links: 146 total, 146 remaining
More Overlapping Ways: 890 created, 890 remaining
One Way Loops: 4 total, ALL FIXED
Typos: 502 total, 497 remaining
Unexpected Dead Ends: 27 total, 13 remaining
Unnamed Roads: 634 total, 545 remaining
Untagged Links: 90 total, 2 remaining
Ways Needing Smoothing: 119 total, 115 remaining
Wrong One Ways: 4 total, ALL FIXED

There are equivalent challenges for the US as well - if you would like a 
similar update for those, I can provide that. If you find this useful or fun or 
both - I can post these stats weekly :) There is also metrics.maproulette.org 
for some more / different metrics!

By the way - is there a different forum where the Canadian community hangs out? 
talk-ca seems to be very low volume lately!

> On Mar 29, 2016, at 1:35 PM, Martijn van Exel <m...@rtijn.org> wrote:
> 
> Hi all, 
> 
> A few of my colleagues at Telenav have been working on some MapRoulette 
> challenges for Canada: Untagged Links (_link ways that don’t have explicit 
> oneway tags), and Unnamed Roads (roads that have name nor ref).
> 
> The numbers of tasks are fairly modest so I hope we can get these out of the 
> way pretty quickly.
> 
> I would like to hear your feedback on these challenges, and ideas for other 
> Canada-specific challenges that I might add. Especially if they may help 
> navigation, but really any ideas are welcome. I’m happy to work with you to 
> get them online, or guide you through the process.
> 
> Thanks,
> Martijn


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

[Talk-ca] New MapRoulette challenges

[Martijn van Exel]

Hi all, 

A few of my colleagues at Telenav have been working on some MapRoulette 
challenges for Canada: Untagged Links (_link ways that don’t have explicit 
oneway tags), and Unnamed Roads (roads that have name nor ref).

The numbers of tasks are fairly modest so I hope we can get these out of the 
way pretty quickly.

I would like to hear your feedback on these challenges, and ideas for other 
Canada-specific challenges that I might add. Especially if they may help 
navigation, but really any ideas are welcome. I’m happy to work with you to get 
them online, or guide you through the process.

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

[Talk-ca] New MapRoulette - UX ideas

[Martijn van Exel]

Hi all,

I am working on a new version of MapRoulette. The focus will be on making
MapRoulette more fun for newcomers, more effective for power users, and
more powerful for challenge owners.

Now would be a great time to let me know what you want to see in the new
version! :) Especially if you have used MapRoulette a lot, your feedback
would be very valuable to me.

I started adding some ideas to a piratepad here:
http://piratepad.net/Rof0ZoyX7y - feel free to add to that. Or just email
me.

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

[Talk-ca] Route relations

[Martijn van Exel]

Hi all,


(resending from the correct email address, apologies)


Thanks for all the responses to my previous thread. I am partly still 
processing the input but another topic came up while we were investigating 
route relations. I can’t seem to find a wiki page on route relations in Canada, 
or even per province. The exception is Ontario 
(http://wiki.openstreetmap.org/wiki/Canada:Ontario#Route_relations
). Am I not looking hard enough? Would a ‘relation pages’ for Canada perhaps 
make sense?


The main reason I am asking is that I want to encourage our Telenav map 
analysts to help improve route relation coverage for Canada. We have been 
looking at the relation coverage and it seems to vary a lot by province. 
Perhaps a Canadian instance of Relation Pages would help? (See the US version 
here: http://184.73.220.107/relationpages/ - although this has not been 
updating correctly for a while)


Martijn


—  Martijn van Exel___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Route relations

[Martijn van Exel]

(sorry wrong from: address again..)




In the US, we use a hierarchy of network classifications instead. For instance, 
Interstate 80 would be network=US:I, ref=80, role=east/west depending on if 
it’s an eastbound / westbound carriageway. This is a really neat and tidy way 
of organizing route relations. Has this been common practice in Canada as well 
or something to consider?




Example: http://www.openstreetmap.org/relation/280678 for I-80 in Utah




Martijn




—  Martijn van Exel

On Thu, Jul 16, 2015 at 12:42 PM, Andrew MacKinnon andrew...@gmail.com
wrote:

 On Thu, Jul 16, 2015 at 12:47 PM, Martijn van Exel m...@rtijn.org wrote:
 Hi all,

 (resending from the correct email address, apologies)

 Thanks for all the responses to my previous thread. I am partly still
 processing the input but another topic came up while we were investigating
 route relations. I can’t seem to find a wiki page on route relations in
 Canada, or even per province. The exception is Ontario
 (http://wiki.openstreetmap.org/wiki/Canada:Ontario#Route_relations
 ). Am I not looking hard enough? Would a ‘relation pages’ for Canada perhaps
 make sense?
 Several users (OntarioEditor and osm_validation_and_improvements)
 created a whole bunch of relations for Ontario highways and county
 roads, but also added prefixes to roads (ON prefix to provincial
 highways and various prefixes like RR and CR to regional/county roads)
 which many OSM users were unhappy with and which I have been gradually
 reverting. I want to keep the relations though.
 ___
 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] OSM data quality in Canada

[Martijn van Exel]

Hello list — 

My name is Martijn van Exel, I am on the OSM US board and work at Telenav. I’ve 
written to this list a few times before, but this time I am doing so with my 
Telenav hat on. Perhaps you know that we have the Scout apps (iOS, Android) 
which run on OSM data. (If you haven’t yet, please give Scout a try some time 
and let me know what you think!)

We are always looking into ways to make significant contributions to OSM, in 
the US, Canada and elsewhere. We’re starting to look into Canada more, and I 
could really use your help with a few key questions:

* What is the imports history, particularly in relation to road network, POIs 
and addresses? (Beyond what’s in the import catalogue page on the wiki, if 
anything)
* What external (government and otherwise) open geospatial data sources are out 
there that have been or may be considered for improving OSM?
* Are there any Canada-specific mapping and tagging conventions?
* Are there any known big (national) issues in the Canadian OSM data? 
(misguided imports / bots, major tagging disputes, that kind of thing)
* Which (other) companies / organizations / government agencies use OSM data 
for Canada?
* Any suggestions for QA tools that would help the community, either existing 
or new?

I’m happy to discuss on-list or off. Thanks!

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

Re: [Talk-ca] OSM data quality in Canada

[Martijn van Exel]

Unrelated, but I noticed that talk-ca is not archived on Nabble yet - this 
makes it hard to share and follow a conversation as a non-subscriber. I don’t 
know what’s involved in adding this list or if anyone would object?

Martijn

 On Jun 17, 2015, at 4:47 PM, Martijn van Exel m...@rtijn.org wrote:
 
 Hi Andrew, 
 
 Thanks for elaborating on the CanVec / Geobase imports! This also raises new 
 questions.. See below.
 
 On Jun 17, 2015, at 3:00 PM, Andrew MacKinnon andrew...@gmail.com wrote:
 
 A lot of the data in Canada was imported from CanVec and Geobase,
 some of it by me several years ago. The imported data is pretty poor
 quality in many places. I haven't done much work on this recently, as
 imports have a bad reputation in OSM and I am mostly concerned with
 surveying. For example:
 
 - Some older road data comes from an import which combined CanVec and
 Statistics Canada road names, attempting to match the road names in
 Statistics Canada with roads without names from CanVec, and this data
 is poor quality.
 
 Is this described in more detail anywhere? Are the data / scripts / process 
 still available? Which dat was poor quality, CanVec or Statistics Canada?
 
 - Road data in some areas is missing entirely.
 
 This is probably easy to visualize, but do you happen to know where / why?
 
 - The CanVec address data is low quality, and is often broken - e.g.
 on a tile boundary address ranges will be split in half, and comes
 from several different versions of CanVec.
 - Other CanVec layers such as woods, lakes and so on were imported in
 some areas but not others. Much of this data is low quality.
 
 Was some sort of progress page kept so we could see where certain features 
 were imported or not (yet)? Has a followup ever been considered to augment / 
 fix these botched / low quality imports? 
 
 - Some road names have too many spaces e.g. John Street is John
 Street. Some address ranges are like that as well.
 - lanes=-1 and surface=unpaved for roads that are really paved in Quebec.
 - Better quality municipal GIS datasets are now available in some
 cities like Toronto, Peel Region and York Region and if they are
 properly licensed, these should be used whenever possible. There
 generally are some minor errors in these datasets, but they are far
 better quality than CanVec/Geobase.
 
 Ah, interesting. Is there already a list of these candidates or would it make 
 sense to start one and look into proper licensing?
 
 
 I really like the TO-FIX Tiger Delta layer at
 http://osmlab.github.io/to-fix/#/task/tigerdelta which matches TIGER
 data with OSM data and tries to find errors. It would helpful if a
 similar tool were created for Canada.
 
 Obviously I am partial to MapRoulette, but sure, let me check it out, I am 
 sure we can come up with something similar for Canada. What would the 
 reference data be instead of TIGER?
 
 Again, thanks for your insights, Andrew.
 
 Martijn


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

Re: [Talk-ca] OSM data quality in Canada

[Martijn van Exel]

Hi Andrew, 

Thanks for elaborating on the CanVec / Geobase imports! This also raises new 
questions.. See below.

 On Jun 17, 2015, at 3:00 PM, Andrew MacKinnon andrew...@gmail.com wrote:
 
 A lot of the data in Canada was imported from CanVec and Geobase,
 some of it by me several years ago. The imported data is pretty poor
 quality in many places. I haven't done much work on this recently, as
 imports have a bad reputation in OSM and I am mostly concerned with
 surveying. For example:
 
 - Some older road data comes from an import which combined CanVec and
 Statistics Canada road names, attempting to match the road names in
 Statistics Canada with roads without names from CanVec, and this data
 is poor quality.

Is this described in more detail anywhere? Are the data / scripts / process 
still available? Which dat was poor quality, CanVec or Statistics Canada?

 - Road data in some areas is missing entirely.

This is probably easy to visualize, but do you happen to know where / why?

 - The CanVec address data is low quality, and is often broken - e.g.
 on a tile boundary address ranges will be split in half, and comes
 from several different versions of CanVec.
 - Other CanVec layers such as woods, lakes and so on were imported in
 some areas but not others. Much of this data is low quality.

Was some sort of progress page kept so we could see where certain features were 
imported or not (yet)? Has a followup ever been considered to augment / fix 
these botched / low quality imports? 

 - Some road names have too many spaces e.g. John Street is John
 Street. Some address ranges are like that as well.
 - lanes=-1 and surface=unpaved for roads that are really paved in Quebec.
 - Better quality municipal GIS datasets are now available in some
 cities like Toronto, Peel Region and York Region and if they are
 properly licensed, these should be used whenever possible. There
 generally are some minor errors in these datasets, but they are far
 better quality than CanVec/Geobase.

Ah, interesting. Is there already a list of these candidates or would it make 
sense to start one and look into proper licensing?

 
 I really like the TO-FIX Tiger Delta layer at
 http://osmlab.github.io/to-fix/#/task/tigerdelta which matches TIGER
 data with OSM data and tries to find errors. It would helpful if a
 similar tool were created for Canada.

Obviously I am partial to MapRoulette, but sure, let me check it out, I am sure 
we can come up with something similar for Canada. What would the reference data 
be instead of TIGER?

Again, thanks for your insights, Andrew.

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

Re: [Talk-ca] Imported data by 'Feldo'

[Martijn van Exel]

I will continue to try and reach Feldo through OSM messaging, I will let
you know if I get a response. Stay tuned!

Martijn

On Mon, May 11, 2015 at 1:36 PM Richard Weait rich...@weait.com wrote:

 Martijn is referring to import errors near the Québec / Labrador border.

 On Fri, May 8, 2015 at 4:54 AM, Martijn van Exel m...@rtijn.org wrote:
  Hi all,
 
  I'm looking at some potentially misguided import attempt. Some
  duplicate ways like these ones look suspicious to me:
 
 
 https://www.openstreetmap.org/way/330950347/history#map=17/51.46519/-57.24176
  https://www.openstreetmap.org/way/330950410/history
 
  Is this a known problem? Is Feldo on this list? I can message him/her
  but as this looks like it happened a couple months ago I thought I'd
  ask on the list first.
 
  Martijn van Exel
  skype: mvexel
 
  ___
  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-us] New North America coverage of Osmose QA

[Martijn van Exel]

This is amazing news. Osmose is a really valuable tool.

Also there is a good integration with MapRoulette that Frédéric built, and
has already resulted in some interesting challenges. As you explore Osmose,
let me know if you want any other QA themes from Osmose to appear in
MapRoulette.

Martijn

Martijn van Exel
skype: mvexel

On Thu, Apr 2, 2015 at 10:51 AM, Frédéric Rodrigo fred.rodr...@gmail.com
wrote:

 Hi,

 Osmose QA is a Quality Assurance tool. It detects and reports errors based
 on more than 200 rulesets.

 http://osmose.openstreetmap.fr
 http://wiki.openstreetmap.org/wiki/Osmose

 We are glad to announce the new North American coverage of Osmose QA.
 After Africa and Antarctica, America is the last fully covered continent.
 This is possible because of interest of MapBox on data quality and their
 sponsorship of Osmose QA project through OpenStreetMap-France with € 2.000
 donation. This allowed us to rent a new server for a couple of years to run
 the North America analysis.

 After the new active areas are in place, we checked the results and
 adjusted the analysers according to local mapping usages. Nevertheless we
 are still open to comments (and code) to improve the quality of errors
 detection.

 Setting up quality analyser in a new area always come up with lot of
 errors detected - and some errors coming from noisy imports. Do not
 discourage yourself by the quantity of errors. In Osmose QA you can filter
 errors by severity, categories, topics and so on. You can look up at errors
 on objects where your are the last editor. You can also show errors list,
 exports and graph over time.

 We plan to rent a second server and try to finish Europe coverage. Then it
 will miss large part of Asia and Oceania to cover the world.
 Donations are welcome to extend Osmose QA coverage on the last missing
 continents.

 The Osmose QA team.


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

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

[Talk-ca] Update on State of the Map US

[Martijn van Exel]

Hey all,

(I just sent this note to talk-us but I am hoping it will be useful for
folks outside the US as well!)

We've been pretty busy organizing the upcoming State of the Map US
conference. Time for an update!

Firstly, as of today the call for sessions is open. Please do submit your
ideas for a talk, a lightning talk, or a different type of session. We
welcome any and all topics related to OSM: your local community initiative,
interesting uses and applications of OSM, your teaching project, a tech or
cartographic deep dive...Too many possibilities to list! Head over to
http://stateofthemap.us/ to submit your proposal.

Also, a reminder that we're running a pretty great scholarship program. If
you belong at State of the Map US but money is an issue, there's help.
Applications for the scholarship program are open for a little while
longer, again, head over to http://stateofthemap.us/ to learn more and
apply.

Speaking of $. We realize NYC can be an expensive place, so we've made a
big effort to find affordable accommodations. Prices start at $45 a night
but rooms / beds are limited, so head over to http://stateofthemap.us/ and
book soon.

I was not going to make this into a long email but one more thing..:
registration is open  for early bird tickets which are $90 only, this will
not last long and considering what you'll get for this money it's a total
bargain :) You know where to go by now!

Let me know if you have any questions or ideas about SOTM US, and I hope to
see many of you June 6-8 in NYC.

-- 
Martijn van Exel
skype: mvexel
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] [Talk-us] Fwd: [OSM-talk] OSM Inspector has world-wide address view

[Martijn van Exel]

Thanks for forwarding these relevant announcements to talk-us, Richard! I
know many of us are not on talk@ - including me - so I appreciate it!


On Fri, Apr 11, 2014 at 6:28 PM, Richard Weait rich...@weait.com wrote:

 Address inspector tool now spans the globe!  See Frederik's announcement


 -- Forwarded message --
 From: Frederik Ramm frede...@remote.org
 Date: Fri, Apr 11, 2014 at 4:38 PM
 Subject: [OSM-talk] OSM Inspector has world-wide address view
 To: Talk Openstreetmap t...@openstreetmap.org


 Hi,

 the OSMI addresses view is now available world-wide (it just had
 Europe before). The code that runs the analyses behind it is based on
 the new Osmium library and is available on Github. The new view is
 available now on OSMI (http://tools.geofabrik.de/osmi).

 This blog entry has more details: http://blog.geofabrik.de/?p=309

 I wish to thank Geotab Inc. who are sponsoring the server that runs the
 analyses, as well as Lukas Toggenburger, who re-implemented the checks
 in C++ so that everything is fast enough for world-wide processing (we
 had been using an SQL based process before).

 Bye
 Frederik

 --
 Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

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

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




-- 
Martijn van Exel
President, US Chapter
OpenStreetMap
http://openstreetmap.us/
http://osm.org/
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] [Talk-us] Fwd: [OSM-dev] NOTICE: Upcoming Maintenance / Downtime

[Martijn van Exel]

Thanks for reposting.

On Mon, Nov 25, 2013 at 8:28 AM, Richard Weait rich...@weait.com wrote:
 just in case you aren't following announce, dev or talk.

 -- Forwarded message --
 From: Grant Slater openstreet...@firefishy.com
 Date: Mon, Nov 25, 2013 at 6:34 AM
 Subject: [OSM-dev] NOTICE: Upcoming Maintenance / Downtime
 To: annou...@openstreetmap.org, Talk Openstreetmap
 t...@openstreetmap.org, OSM Dev List d...@openstreetmap.org


 On Wednesday 27th of November 2013 between 17:30 and 22:00 (GMT / UTC)
 the primary database server will be unavailable due to maintenance.

 I apologise for the short notice.

 The following services WILL be affected:
 * www.openstreetmap.org web site WILL NOT allow edits (iD or Potlatch). [1]
 * API will NOT allow map editing (using iD, JOSM, Merkaartor etc.),
 but will remain available as read-only. [2]

 Other OpenStreetMap provided services should not be affected - all of
 the following are expected to function normally:
 * Forum
 * trac (bug-tracker)
 * help.openstreetmap.org
 * tile serving (View The Map  Export)
 * Wiki
 * Nominatim (search)
 * mailing lists
 * subversion and git (source code repositories)
 * donate.openstreetmap.org

 Technical: Database servers ramoth  katla hardware maintenance.
 Upgrade of web frontends spike-01, spike-02  spike-03 with HP DL360
 G6 (Xeon 56xx) hardware.

 1: Maps will still be viewable on the openstreetmap.org homepage and
 on other people's websites.
 2: The sysadmin team will try as far as possible to keep the API
 available in read-only mode, but the API may be briefly unavailable.

 Sincerely
   Grant Slater
   On behalf of the OpenStreetMap sysadmin team.

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

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



-- 
Martijn van Exel
http://oegeo.wordpress.com/
http://openstreetmap.us/

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

[Talk-ca] Submit your session proposal for SOTM USA

[Martijn van Exel]

Hi all! (crossposting talk, talk-us, talk-ca)

The deadline for session proposals for the State of the Map USA conference
is on *Friday, August 31*, so submit your session idea soon:
http://stateofthemap.us/form. The conference will be made up for talks by
community members on everything from tools and techniques to working with
and contributing to OSM data to showcases of it in use by companies,
governments, nonprofits, and everybody to bigger picture discussions of
where OSM should be moving in the future.

The State of the Map USA conference will bring together people working
with, adding to, and advocating for OpenStreetMap. Our community is filled
with people doing interesting, cutting edge, and important work. This is
your chance to share it with us all.

You can submit your session proposal here - we just need 200 words or less
about what you want to talk about. If you have questions, email me or hit
us up on Twitter at @sotmus.

Hope to hear from you soon!
Best,
Martijn
-- 
martijn van exel
http://oegeo.wordpress.com
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] [Talk-us] SOTM US Portland - Call for participation

[Martijn van Exel]

Hi,

On Fri, Aug 3, 2012 at 7:04 PM, Bill Ricker bill.n1...@gmail.com wrote:
 Do you have a story or project to share at State Of The Map US,
 Portland Oct 13-14? Now is the time to submit your abstract!
 ...



 See you all in Portland!


 One assumes you mean the new Portland Oregon not old Portland Maine.

 (Is it too much to expect OSM'ers of all people to realize there are more
 than one Portland USA? I've rather given up on normals and non-geo-geek
 geeks, but mappers ...)


Thanks for clarifying that, Bill. Yes, it is Portland, Ore. After a
year in the US, I know where most of the 50 states are, but I am still
learning about the various Portlands, Springfields, Manchesters etc.
Please bear with me as I assimilate.

Thanks
Martijn


-- 
martijn van exel
http://oegeo.wordpress.com

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

Re: [Talk-ca] [Talk-us] SOTM US Portland - Call for participation

[Martijn van Exel]

Springfield is on the radar for SOTM US 2013. The first massively
distributed SOTM.

On Sat, Aug 4, 2012 at 12:10 AM, James Ewen ve6...@gmail.com wrote:
 Could have been worse... it might have been held in Springfield!

 James
 VE6SRV


 On Fri, Aug 3, 2012 at 7:04 PM, Bill Ricker bill.n1...@gmail.com wrote:
 Do you have a story or project to share at State Of The Map US,
 Portland Oct 13-14? Now is the time to submit your abstract!
 ...



 See you all in Portland!


 One assumes you mean the new Portland Oregon not old Portland Maine.

 (Is it too much to expect OSM'ers of all people to realize there are more
 than one Portland USA? I've rather given up on normals and non-geo-geek
 geeks, but mappers ...)


 --
 Bill
 @n1vux bill.n1...@gmail.com

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




 --
 James
 VE6SRV



-- 
martijn van exel
http://oegeo.wordpress.com

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

Re: [Talk-ca] [Talk-us] High-visibility Vests

[Martijn van Exel]

I have about a dozen of them and am happy to lend them for mapping
party purposes.
They look like this: http://schaaltreinen.nl/openstreetmap-hi-viz-vest
If it looks a little wrinkly, that's because I brought them from Europe ;)

Martijn

On Sun, Oct 23, 2011 at 6:12 PM, Paul Norman penor...@mac.com wrote:
 In another thread, the subject of high-visibility vests came up and I was
 wondering if there were any of these in North America. The wiki says the
 existing ones are sold by the OpenCycleMap shop, but they are listed as
 “temporarily unavailable”. In any case, shipping clothing from Europe is
 likely not the best option. Additionally, the vests aren’t likely to meet
 North American high-visibility standards.



 In my day job I deal with high-vis vests too much, so I am familiar with
 this subject area.



 I believe a vest meeting CSA Z96, ANSI/ISEA 107 with “MOT” style trim would
 meet the requirements for use on US federally funded rights of way (See
 Federal Register/Vol 71, No 226/Friday November 24, 2006, p. 67792-67800),
 BC MOT roadways (Technical Circular T-09/05), other BC roadways (OHSR 8.24 +
 G8.24-1), Ontario, Saskatchewan, Manitoba, Alberta and I would expect the
 rest of North America. The FWHA put the normal price of a vest at $25. The
 maximum area of a non-retroreflective logo on a vest is 100 square cm.

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





-- 
martijn van exel
geospatial omnivore
1109 1st ave #2
salt lake city, ut 84103
801-550-5815
http://oegeo.wordpress.com

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