Re: [Talk-ca] Formatting of Municipality Names (Jarek Piórkowski)

[Ga Delap]

> Date: Fri, 16 Feb 2018 23:56:20 +0100
> From: Jarek Piórkowski 
> Cc: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Formatting of Municipality Names
> Message-ID:

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

[Ga Delap]

You wrote:
> I will make sure we proceed even more carefully when the evidence is
inconclusive...

You may even contact a local mapper!

dega

Le 18 septembre 2017 à 15:02, Martijn van Exel <m...@rtijn.org> a écrit :

> 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 <james2...@gmail.com>:
>
>> des photos*
>>
>> 2017-09-15 9:10 GMT-04:00 James <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>:
>>>
>>>> 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>:
>>>>
>>>>> 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

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

[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/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
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Discussion: zones boisées

[Ga Delap]

Bonjour Bruno
 Je suis d'accord avec la logique de Frank : redécouper les polygones de
 CanVec selon les lignes de frontiéres naturelles (rivières, lacs...) et
 artificielles (routes, lignes électriques, lignes coupe-feu...etc..).
J'ai regardé tes exemples. C'est un compromis intéressant. La zone fôret est
séparée en parcelles délimitées par toute entité linéaire (route, ligne
électrique, voie ferrée, etc) ou surface (lac, bâtiment, clairière, etc). Je
n'ai vu aucun trou.
Mais il ne faut pas oublier de définir l'entité qui se trouve entre 2 parcelles
car l'absence de forêt n'est pas, en soi, une entité.
Par exemple, il y a surement un objet physique qui sépare les chemins
302348523 et 302349825. Je ne connais pas le territoire mais ce semble être un
chemin forestier qu'il faudrait définir. Et, à la limite, ce chemin linéaire
devrait être défini à l'intérieur d'une surface 2D de type clairière.
Ce qui m'améne à poser de nouveau une question de l'article qui a initié cette
discussion:
Est-ce correct d'utiliser l'absence de définition (undefined) pour représenter
les clairières? Est-ce que toutes les zones blanches de la carte OSM sont des
clairières?

Bonne journée

dega

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

[Talk-ca] (no subject)

[Ga Delap]

Plusieurs (et j'en suis) ont exprimé leur désir d'avoir une meilleure
couverture de forêt sur la carte OSM. Ces zones de forêt sont venues avec les
importations CanVec mais ne progressent plus depuis un certain temps. Le
présent article propose une façon de réaliser la forêt sans utiliser les abus
de la méthode CanVec.

Voyons un exemple. Dirigez votre éditeur préféré vers -74.375/46.1875 ou
visionnez:
http://www.openstreetmap.org/#map=16/46.1875/-74.3750
Vous y verrez deux tuiles de forêt. Chacune a été crée avec un rectangle de
type natural:wood. Un simple rectangle de 4 points qu'on peut créer
facilement. Cette tuile peut être vue simplement avec:
http://openstreetmap.org/way/307466266


Voyons un autre exemple un peu plus à l'ouest (-74.500/46.1875). Dans votre
éditeur, sélectionner la ligne qui délimite la tuile sud-ouest. On peut
constater qu'elle est beaucoup plus complexe. On peut voir l'ensemble de cette
ligne avec:
http://openstreetmap.org/way/307466267
Elle est composée d'environ 1600 points. Elle est complexe parce qu'elle
utilise l'approche everything but the kitchen sink. La tuile définit non
seulement la forêt mais aussi les lacs, les rivières et les clairières. Pire
encore, ce chemin de 1600 points fait partie d'une relation qui contient
plusieurs dizaines de tels chemins.
Affichez http://www.openstreetmap.org/relation/2368823 et remarquez le temps de
chargement de la page.

Revenons au premier exemple:
http://www.openstreetmap.org/#map=14/46.1875/-74.3750
La forêt est un simple rectangle mais les lacs, les rivières et les chemins se
superposent à la forêt. Il n'est donc pas nécessaire que le contour de forêt
suive le contour des lacs et des rivières. Il y a un gain énorme en
simplicité.

Voyons un autre problème des tuiles CanVec:
http://www.openstreetmap.org/#map=17/46.25047/-73.24885
Pour comprendre pourquoi il y a 3 Lac Laporte il faut utiliser l'éditeur:
http://www.openstreetmap.org/edit?editor=id#map=17/46.25047/-73.24885
Les tuiles CanVec ont divisé le lac en 3 parties et ont créé 3 entités
natual:water, chacune avec le nom Lac Laporte. Pas fort!
Sur la même image, remarquez que le chemin Montée Ouest est fait de 2
segments de couleur différente. C'est parce que ce chemin a été défini de 2
façons différentes et, par conséquent, on ne peut pas fusionner les 2 segments
ensemble. L'un des segments vient de CanVec6 et l'autre de CanVec7. Belle
rigueur!
C'est un non-sens qu'une entité soit séparée en plusieurs parties parce
qu'elle est à cheval sur une tuile.

Le but de mon intervention est d'affirmer qu'il ne faut plus importer de tuile
CanVec dans sa forme actuelle. Elles rend la carte lourde et difficile à éditer
par des humains.
Peut-on remplacer les tuiles de forêt par de simples rectangles? Oui et non.
Les tuiles CanVec sont des multi-polygones et celà permet des trous. Ces trous
sont utilisés (entre autres) pour représenter des clairières. Donc, au lieu
d'un rectangle, on pourrait utiliser un multi-polygone avec des trous. Mais
est-ce bien  la bonne façon?
Un trou (tel qu'uitlisé par CanVec) définit une zone undefined qui apparaît en
blanc sur la carte. Ne serait-il pas mieux de créer une entité heath (ou
autre) pour représenter cette clairière? Une clairière n'est pas un trou dans
une forêt, tout comme une île n'est pas un trou dans un lac.

J'aimerais qu'il y ait une discussion sur les points suivants:
1) est-ce que les tuiles CanVec sont la meilleure façon de représenter la
forêt?
2) si non, peut-on définir une stratégie pour les remplacer (à long terme)
3) Pour les tuiles forêt, devrait-on utiliser un rectangle avec clairière
explicite?
4) Pour les tuiles forêt, devrait-on utiliser un multi-polygone avec trous?

J'espère que cette discussion nous fera progresser vers une carte de meilleure
qualité et une meilleure performance.

dega

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

[Talk-ca] Discussion: zones boisées

[Ga Delap]

Plusieurs (et j'en suis) ont exprimé leur désir d'avoir une meilleure
couverture de forêt sur la carte OSM. Ces zones de forêt sont venues avec les
importations CanVec mais ne progressent plus depuis un certain temps. Le
présent article propose une façon de réaliser la forêt sans utiliser les abus
de la méthode CanVec.

Voyons un exemple. Dirigez votre éditeur préféré vers -74.375/46.1875 ou
visionnez:
http://www.openstreetmap.org/#map=16/46.1875/-74.3750
Vous y verrez deux tuiles de forêt. Chacune a été crée avec un rectangle de
type natural:wood. Un simple rectangle de 4 points qu'on peut créer
facilement. Cette tuile peut être vue simplement avec:
http://openstreetmap.org/way/307466266


Voyons un autre exemple un peu plus à l'ouest (-74.500/46.1875). Dans votre
éditeur, sélectionner la ligne qui délimite la tuile sud-ouest. On peut
constater qu'elle est beaucoup plus complexe. On peut voir l'ensemble de cette
ligne avec:
http://openstreetmap.org/way/307466267
Elle est composée d'environ 1600 points. Elle est complexe parce qu'elle
utilise l'approche everything but the kitchen sink. La tuile définit non
seulement la forêt mais aussi les lacs, les rivières et les clairières. Pire
encore, ce chemin de 1600 points fait partie d'une relation qui contient
plusieurs dizaines de tels chemins.
Affichez http://www.openstreetmap.org/relation/2368823 et remarquez le temps de
chargement de la page.

Revenons au premier exemple:
http://www.openstreetmap.org/#map=14/46.1875/-74.3750
La forêt est un simple rectangle mais les lacs, les rivières et les chemins se
superposent à la forêt. Il n'est donc pas nécessaire que le contour de forêt
suive le contour des lacs et des rivières. Il y a un gain énorme en
simplicité.

Voyons un autre problème des tuiles CanVec:
http://www.openstreetmap.org/#map=17/46.25047/-73.24885
Pour comprendre pourquoi il y a 3 Lac Laporte il faut utiliser l'éditeur:
http://www.openstreetmap.org/edit?editor=id#map=17/46.25047/-73.24885
Les tuiles CanVec ont divisé le lac en 3 parties et ont créé 3 entités
natual:water, chacune avec le nom Lac Laporte. Pas fort!
Sur la même image, remarquez que le chemin Montée Ouest est fait de 2
segments de couleur différente. C'est parce que ce chemin a été défini de 2
façons différentes et, par conséquent, on ne peut pas fusionner les 2 segments
ensemble. L'un des segments vient de CanVec6 et l'autre de CanVec7. Belle
rigueur!
C'est un non-sens qu'une entité soit séparée en plusieurs parties parce
qu'elle est à cheval sur une tuile.

Le but de mon intervention est d'affirmer qu'il ne faut plus importer de tuile
CanVec dans sa forme actuelle. Elles rend la carte lourde et difficile à éditer
par des humains.
Peut-on remplacer les tuiles de forêt par de simples rectangles? Oui et non.
Les tuiles CanVec sont des multi-polygones et celà permet des trous. Ces trous
sont utilisés (entre autres) pour représenter des clairières. Donc, au lieu
d'un rectangle, on pourrait utiliser un multi-polygone avec des trous. Mais
est-ce bien  la bonne façon?
Un trou (tel qu'uitlisé par CanVec) définit une zone undefined qui apparaît en
blanc sur la carte. Ne serait-il pas mieux de créer une entité heath (ou
autre) pour représenter cette clairière? Une clairière n'est pas un trou dans
une forêt, tout comme une île n'est pas un trou dans un lac.

J'aimerais qu'il y ait une discussion sur les points suivants:
1) est-ce que les tuiles CanVec sont la meilleure façon de représenter la
forêt?
2) si non, peut-on définir une stratégie pour les remplacer (à long terme)
3) Pour les tuiles forêt, devrait-on utiliser un rectangle avec clairière
explicite?
4) Pour les tuiles forêt, devrait-on utiliser un multi-polygone avec trous?

J'espère que cette discussion nous fera progresser vers une carte de meilleure
qualité et une meilleure performance.

dega

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

[Talk-ca] Discussion: zones boisées

[Ga Delap]

Salut Frank, long time no see
 ... What if you get an extract of OSM, and you're only
 interested in the forests, because you want to calculate the percentage
 of forest coverage. You don't get information about lakes, heath and
 other land uses when you don't cut out holes from multipolygons.
You're right but that's a moot point.
From my point of view, OSM is not a tool for GIS professionals. It's a
community project (activité citoyenne). From a scientific and rigorous
perspective, a forest must have a hole for any 2D entity (lake, river, road,
street and building). But, if you go that way, editing the map will become so
complex (or arduous as you say) that no normal contributor will be interested
any more.

Look at this monstruous way:
http://openstreetmap.org/way/175486790
It's a CanVec import with 1420 nodes, part of relation 2344036.
The way was imported after many of the streets have been created. So the
forest is on top of streets and roads and there's no hole for them.
Do you really think a human being will get satisfaction and pride if he/she
have to dig holes around every street?
And look at the above example. The golf course is on top of the forest
(without a hole) albeit it has a significant area.

It the goal is to use the OSM database as a rigorous GIS ressource, then the
tools designed for humans (Id, Potlatch, JOSM) will have to be modified to
automatically create a hole around any 2D object. If they are not modified, you
may say goodbye to normal contributors.

You may also broadcast this message to Europe because the first european forest
I looked at do not have holes for lake, rivers and roads.
http://www.openstreetmap.org/#map=15/52.1965/-3.8386

Regards,

dega

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

[Talk-ca] RIP CanVec

[Ga Delap]

Il y a actuellement un peu de bruit sur talk.ca pour faire renaître les
importations CanVec.
Il ne faut pas.

Les importations CanVec (et les importateurs CanVec) sont responsables de
plusieurs problèmes:
- ils ont fait fuir plusieurs contributeurs OSM (explications plus loin).
- des données désuètes ont remplacé des données à jour.
- des données imprécises ont remplacé des données précises.
- CanVec a introduit des erreurs de modélisation en imposant dans OSM le
concept de tuile plutôt qu'en respectant celui de l'objet.
- CanVec a un mauvais traitement des objets chemin (ou rue). Il n'y a pas de
nom (du moins au Québec) et il y a un segment pour chaque pâté de maison. Cela
n'a pas de sens dans plus de 90% des cas.

Les importateurs CanVec n'ont pas suivi les guidelines OSM et ont agi en
solitaire. Ils ont agi en utilisant la stratégie tabula rasa et ont effacé
tout un territoire pour faire place à leur importation. Des dizaines
(centaines, milliers?) de contributeurs en ont été frustrés et ont cessé de
collaborer à OSM.

Les importateurs qui n'ont pas fait tabula rasa ont créé un problème de
duplicata. Des lacs existants ont maintenant un doublon dont la qualité est
douteuse. On n'a qu'à regarder dans les Laurentides.

Un lac situé sur une fontière de tuiles se verra découpé en 2, 3 ou 4 parties.
Ce lac sera défini pas les zones inner de plusieurs relations et il devient
difficile de fusionner ces entités volumineuses. Deux cas possibles:
- on ne fait rien et on laisse la carte dans un piteux état.
- on détruit les méga-relations de CanVec et on recommence.
Dans les 2 cas, la valeur ajoutée par CanVec est discutable.

Mon intention n'est pas d'affirmer que CanVec n'a que des torts. Grâce à CanVec,
nous avons:
- plus de rues
- les adresses (addr:interpolation)
- la forêt (natural:wood)

Malheureusement:
- la façon dont CanVec traite les rues demande beaucoup de travail aux
contributeurs qui veulent fusionner tous les segments de rues.
- les lacs ne devraient pas faire partie des relations de forêt car les
renderer d'OSM ont pour règle que les lacs sont au-dessus de la couche de
base.

Mes recommandations aux importateurs CanVec (si CanVec renaît):
- n'importer que dans les zones où il n'y a pas de contributeur (Nunavut par
exemple)
- impliquer les contributeurs s'il y en a
- laisser les rues et routes aux contributeurs OSM
- bravo pour les adresses
- ne pas tenir compte des lacs ou des chemins dans les contours de tuiles
- ne pas importer un lac s'il existe déjà dans OSM. Il est probable qu'il a
été dessiné à partir d'un imagerie (Bing, Yahoo, ...) qui est plus précise que
que les données CanVec faites à partir des données d'un satellite désuet.

Pour le dynamisme et la pérennité d'OSM

dega

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