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] Erreurs Osmose et changesets

[James]

Puis, pour le meme numéro tu pourrais marqué un faux positif car le but
ultime serait d'avoir toutes les adresses et aucune interpolation

On Sep 12, 2016 7:00 PM, "James"  wrote:

> 1. Non tu n'a pas besoin de le verifier, c'est parce que qqun a dessiner
> un edifice par dessus un autre, ou meme lui meme
>
> 2- A moins d'avoir 100% des addresses sur une rue(ou tu pourrais suprimer
> l'interpolation), garde les interpolations car quand on cherche une
> addresse non attrappee par un "survey". Si l'adresse est invalide a la fin
> d'une interpolation corrige le, la pluspart viennent de canvec qui n'est
> pas 100% du temps correcte du au veillisage des donnee vs la realite
>
> 3- chanset se ferme automatiquement apres un certain nombre de temps. La
> raison de la garder ouverte c'est téléverser plus de changements dans le
> meme changeset vs creer 2. C'est aussi pour JOSM quand tu téléverse
> 2000objets dependant de ta connexion, le changeset peut fermer
> automatiquement avant qu'il finisse. Donc si tu le laisse ouvert et upload
> en "chunks" de 500 ou 200 il y a encore de l'activité sur le changeset,
> donc il fermera pas automatiquement pendant tu téléverse.
>
> On Sep 12, 2016 6:21 PM, "Loïc Haméon"  wrote:
>
>> Bonjour tous,
>>
>> J'ai récemment commencé à explorer les fonctions d'Osmose, que je
>> trouvent fort utiles, notamment pour corriger mes propres contributions.
>>
>> Je constate toutefois qu'il y a un grand nombre d'erreurs signalées dans
>> mon voisinage, au point où ça alourdit notablement la vue dans Vespucci.
>> Comme le Wiki mentionne expressément de "ne pas cartographier pour Osmose",
>> je voudrais m'assurer de bien comprendre les corrections souhaitables avant
>> de m'y attaquer.
>>
>> 1 - Building intersections : C'est de loin l'erreur la plus fréquente
>> dans mon quartier. La plupart des bâtiments semblent y avoir été dessinés
>> par un même utilisateur à partir de Bing. Or, il n'a pas traité les blocs
>> de bâtiments collés uniformément: les murs mitoyens sont parfois partagés
>> par deux bâtiments, mais parfois ils sont représentés par deux chemins
>> distincts, ce qui tend à causer des erreurs d'intersection. Ça ne devrait
>> pas être un problème si je combine les chemins concernés sur la foi des
>> images satellites, non? Je n'ai pas nécessairement à aller vérifier chacun
>> des cas individuellement sur le terrain?
>>
>> 2- Interpolation d'adresse : Selon ce que j'ai trouvé sur le sujet dans
>> des tutoriels YouTube, il est acceptable, voire même recommandé, d'ajouter
>> l'adresse d'un bâtiment particulier quand elle est connue, même si un
>> vecteur d'interpolation existe également. Cependant, je constate qu'Osmose
>> signale comme une erreur les cas où un bout du vecteur d'interpolation
>> porte le même numéro qu'une adresse manuellement ajoutée à un bâtiment.
>> Quelle est la convention dans ces cas? Devrait-on signaler un faux positif
>> dans Osmose (auquel cas y aurait-il moyen de signaler cette situation à ces
>> créateurs pour qu'elle ne soit pas signalée comme une erreur), faudrait-il
>> modifier le vecteur d'interpolation ou s'abstenir d'ajouter l'adresse sur
>> le bâtiment?
>>
>> 3-Quelqu'un pourrait-il m'expliquer l'étiquette de l'ouverture/fermeture
>> de changesets? L'outil de navigateur d'Osmose et Vespucci comportent tous
>> deux une option pour fermer/garder ouvert un changeset au moment de
>> l'upload. Dans quelles circonstances est-il préférable de choisir l'un ou
>> l'autre? Je suppose que le fait de garder le changeset ouvert peut être bon
>> si on prévoir continuer de faire des modifications à court terme, pour
>> éviter une multiplication inutile d'éléments disparates dans la base de
>> données? Mais y'a-t-il une durée limite à observer avant de fermer un
>> changeset? Quelles sont les conséquences de le laisser ouvert, les données
>> sont-elle en attente d'ajout à OSM tant que le changeset n'est pas fermé?
>>
>>
>> Merci d'avance pour vos explications!
>>
>> Loïc
>>
>> ___
>> 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] Erreurs Osmose et changesets

[James]

1. Non tu n'a pas besoin de le verifier, c'est parce que qqun a dessiner un
edifice par dessus un autre, ou meme lui meme

2- A moins d'avoir 100% des addresses sur une rue(ou tu pourrais suprimer
l'interpolation), garde les interpolations car quand on cherche une
addresse non attrappee par un "survey". Si l'adresse est invalide a la fin
d'une interpolation corrige le, la pluspart viennent de canvec qui n'est
pas 100% du temps correcte du au veillisage des donnee vs la realite

3- chanset se ferme automatiquement apres un certain nombre de temps. La
raison de la garder ouverte c'est téléverser plus de changements dans le
meme changeset vs creer 2. C'est aussi pour JOSM quand tu téléverse
2000objets dependant de ta connexion, le changeset peut fermer
automatiquement avant qu'il finisse. Donc si tu le laisse ouvert et upload
en "chunks" de 500 ou 200 il y a encore de l'activité sur le changeset,
donc il fermera pas automatiquement pendant tu téléverse.

On Sep 12, 2016 6:21 PM, "Loïc Haméon"  wrote:

> Bonjour tous,
>
> J'ai récemment commencé à explorer les fonctions d'Osmose, que je trouvent
> fort utiles, notamment pour corriger mes propres contributions.
>
> Je constate toutefois qu'il y a un grand nombre d'erreurs signalées dans
> mon voisinage, au point où ça alourdit notablement la vue dans Vespucci.
> Comme le Wiki mentionne expressément de "ne pas cartographier pour Osmose",
> je voudrais m'assurer de bien comprendre les corrections souhaitables avant
> de m'y attaquer.
>
> 1 - Building intersections : C'est de loin l'erreur la plus fréquente dans
> mon quartier. La plupart des bâtiments semblent y avoir été dessinés par un
> même utilisateur à partir de Bing. Or, il n'a pas traité les blocs de
> bâtiments collés uniformément: les murs mitoyens sont parfois partagés par
> deux bâtiments, mais parfois ils sont représentés par deux chemins
> distincts, ce qui tend à causer des erreurs d'intersection. Ça ne devrait
> pas être un problème si je combine les chemins concernés sur la foi des
> images satellites, non? Je n'ai pas nécessairement à aller vérifier chacun
> des cas individuellement sur le terrain?
>
> 2- Interpolation d'adresse : Selon ce que j'ai trouvé sur le sujet dans
> des tutoriels YouTube, il est acceptable, voire même recommandé, d'ajouter
> l'adresse d'un bâtiment particulier quand elle est connue, même si un
> vecteur d'interpolation existe également. Cependant, je constate qu'Osmose
> signale comme une erreur les cas où un bout du vecteur d'interpolation
> porte le même numéro qu'une adresse manuellement ajoutée à un bâtiment.
> Quelle est la convention dans ces cas? Devrait-on signaler un faux positif
> dans Osmose (auquel cas y aurait-il moyen de signaler cette situation à ces
> créateurs pour qu'elle ne soit pas signalée comme une erreur), faudrait-il
> modifier le vecteur d'interpolation ou s'abstenir d'ajouter l'adresse sur
> le bâtiment?
>
> 3-Quelqu'un pourrait-il m'expliquer l'étiquette de l'ouverture/fermeture
> de changesets? L'outil de navigateur d'Osmose et Vespucci comportent tous
> deux une option pour fermer/garder ouvert un changeset au moment de
> l'upload. Dans quelles circonstances est-il préférable de choisir l'un ou
> l'autre? Je suppose que le fait de garder le changeset ouvert peut être bon
> si on prévoir continuer de faire des modifications à court terme, pour
> éviter une multiplication inutile d'éléments disparates dans la base de
> données? Mais y'a-t-il une durée limite à observer avant de fermer un
> changeset? Quelles sont les conséquences de le laisser ouvert, les données
> sont-elle en attente d'ajout à OSM tant que le changeset n'est pas fermé?
>
>
> Merci d'avance pour vos explications!
>
> Loïc
>
> ___
> 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] Erreurs Osmose et changesets

[Loïc Haméon]

Bonjour tous,

J'ai récemment commencé à explorer les fonctions d'Osmose, que je trouvent
fort utiles, notamment pour corriger mes propres contributions.

Je constate toutefois qu'il y a un grand nombre d'erreurs signalées dans
mon voisinage, au point où ça alourdit notablement la vue dans Vespucci.
Comme le Wiki mentionne expressément de "ne pas cartographier pour Osmose",
je voudrais m'assurer de bien comprendre les corrections souhaitables avant
de m'y attaquer.

1 - Building intersections : C'est de loin l'erreur la plus fréquente dans
mon quartier. La plupart des bâtiments semblent y avoir été dessinés par un
même utilisateur à partir de Bing. Or, il n'a pas traité les blocs de
bâtiments collés uniformément: les murs mitoyens sont parfois partagés par
deux bâtiments, mais parfois ils sont représentés par deux chemins
distincts, ce qui tend à causer des erreurs d'intersection. Ça ne devrait
pas être un problème si je combine les chemins concernés sur la foi des
images satellites, non? Je n'ai pas nécessairement à aller vérifier chacun
des cas individuellement sur le terrain?

2- Interpolation d'adresse : Selon ce que j'ai trouvé sur le sujet dans des
tutoriels YouTube, il est acceptable, voire même recommandé, d'ajouter
l'adresse d'un bâtiment particulier quand elle est connue, même si un
vecteur d'interpolation existe également. Cependant, je constate qu'Osmose
signale comme une erreur les cas où un bout du vecteur d'interpolation
porte le même numéro qu'une adresse manuellement ajoutée à un bâtiment.
Quelle est la convention dans ces cas? Devrait-on signaler un faux positif
dans Osmose (auquel cas y aurait-il moyen de signaler cette situation à ces
créateurs pour qu'elle ne soit pas signalée comme une erreur), faudrait-il
modifier le vecteur d'interpolation ou s'abstenir d'ajouter l'adresse sur
le bâtiment?

3-Quelqu'un pourrait-il m'expliquer l'étiquette de l'ouverture/fermeture de
changesets? L'outil de navigateur d'Osmose et Vespucci comportent tous deux
une option pour fermer/garder ouvert un changeset au moment de l'upload.
Dans quelles circonstances est-il préférable de choisir l'un ou l'autre? Je
suppose que le fait de garder le changeset ouvert peut être bon si on
prévoir continuer de faire des modifications à court terme, pour éviter une
multiplication inutile d'éléments disparates dans la base de données? Mais
y'a-t-il une durée limite à observer avant de fermer un changeset? Quelles
sont les conséquences de le laisser ouvert, les données sont-elle en
attente d'ajout à OSM tant que le changeset n'est pas fermé?


Merci d'avance pour vos explications!

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

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

[James]

Yes the new canvec are split into different types of data: hydro data(lakes
rivers etc), forest(loads of fun),  transportation(this is what you want),
etc

On Sep 12, 2016 4: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.? 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"  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"  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_Trans
> port-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]

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