[OSM-talk-fr] Iznogoud Kalife : la rue de Verdun imaginée par le GPS

Sam 28 Mar 23:19:25 UTC 2015

ce n'est pas la premiere fois qu'on trouve ces incongruïtés insérées
volontairement par les éditeurs de données protégées juste dans le but de
prouver une utilisation abusive et une violation de leur licence (et pas
que dans la cartographie, les Pages Jaunes françaises en sont bourrées !)
Comme les éditeurs ne veulent pas communiquer là-dessus (secret commercial
et industriel), il n'y a que quand ils reçoivent des plaintes des
utilisaturs qu'il les "corrigent" (mais en en ajoutant d'autres disséminées
statistiquement dans les données...)
En cartographie il est facile d'insérer ces "œufs de Pâques par des tracés
à la géométrie tres improbable ou erratique : il suffit de mettre des
"encoches" en zig-zag par endroit, dans des zones où ce n'est pas trop
gênant pour l'interprétation des cartes).

Même le cadastre le fait pour symboliser aussi visuellement des tracés
imprécis (où un relevé détaillé n'a pas été fait mais juste estimé par
quelques segments peu détaillés entre deux zigzags  : la position de ces
zig-zags sur un tracé permet de repérer justement que le tracé est issu du
cadastre, si on a utilisé le tracé tel quel, seulement notre utilisation du
cadastre est légale et ce n'est pas gênant si on trouve ces tracés
erratiques par endroit, on a une licence valide et la DGFiP ne nous
attaquera pas sur la démonstration de ces tracés, d'autant plus qu'on
indique qu'une partie tres importante de nos données en France en sont
issues en mentionnant la paternité)

D'autres œufs de Pâques sont des bâtiments qui n'ont jamais existé, ajoutés
sur des terrrains vides, des petits chemins piéton qui n'ont jamais été
réellement mis en place et même pas praticables (ou barrés par une clôture
ou un fossé), ou simplement prolongés poru se connecter de façon imaginaire
à un autre chemin proche.

Même dans OSM on fait des tracés imaginaires (par exemple dans les
carrefours traversant une place, on positionne arbitrairment un point
central d'interconnexion quelquepart sur cette place, unoiquement pour
assurer cette interconnexion, même chose sur la position relative des
embranchements de bretelles d'entrée ou de sortie d'une voie à chaussées
séparées : tant qu'on n'a pas réellement tracé les ilots de séparation, ces
décrochages sont assez arbitraires mais cherchent juste à régulariser les
angles) :

Ici joue l'interprétation de celui qui fait le tracé, dans des marges
acceptables qui permettent d'approcher correctement le trajet suivi par un
véhicule roulant à la vitesse limite autorisée, et devant anticiper ses
virages (et c'est pratique justement pour la navigation assistée, mais
aussi pour faciliter le travail de logiciels de routage qui cherchent les
chemins évitant les virages trop serrés afin de prendre les bretelles les
plus pratiques), car dans OSM on se place dans l'optique d'un
réutilisateur, mais pas dans celle de les induire en erreur ou chercher à
les dépister, on élimine donc volontiers les erreurs et approximations (et
même souvent on indique que des données sont approximatives et devraient
être revues)...

Alors que les éditeurs de données protégées eux les taisent et font comme
si de rien n'était et en ajoutent (ils tiennent certainement une base de
données secrete des endroits où ils ont mis ces incongruïtés dans les
données qu'ils distribuent afin de pouvoir en suivre statistiquement le
nombre (y en a-t-il assez pour protéger leurs données ?) et aussi savoir
quoi faire quand ils ont plus tard de nouvelles données utiles à intégrer
qui entreraient en conflit : ils savent instantanément que ce sont des
pseudo-données et qu'avant de les supprimer, ils doivent regarder s'ils ne
devraient pas en recréer d'autres à proximité, afin de protéger justement
les nouvelles données réelles qu'ils veulent ajouter, et mettre à jour
alors leur base de données secrete)

---

De tels œufs de Pâques existent en grand nombre chez Google (pire,
maintenant ils sont insérés de façon imprévisible mais spécifiquement pour
chaque utilisateur profilé, car tout le monde ne voit pas les mêmes cartes
Google depuis mai 2014 où toutes les cartes ont commencé à être
"personnalisées", et elles le sont maintenant de façon systématique pour
tout le monde depuis septembre dernier) : il n'est plus possible même pour
un bot analysant les cartes de Google de débusquer des œufs de Pâques
visibles par d'autres utilisateurs.

D'autres œufs de Pâques sont visibles par tout le monde  ou presque (par
exemple Google se permet d'ajouter ou supprimer des accents ou ajouter des
mots parasites dans les noms de rues, ou modifier des masculins et
féminins, ou remplacer "avenue" par "boulevard", changer des prénoms,
ajouter ou remplacer des titres comme "commandant". même signalés à Google,
les corrections mettent des mois à être prises en compte (mais peuvent
revenir "aléatoirement" plus tard, car Google utilise ces erreurs comme
source possible pour ses œufs de Pâques "personnalisés" : il conserve les
versions historiques avant corrections et les réinjectent quand bon lui
semble : j'ai pu le prouver en comparant des cartes affichées simultanément
sur un smartphone et sur un PC, caches Internet initialement vidés, avec
des comptes Google distincts et des connexions IP différentes -- avec les
deux profils utilisateur distincts on ne voit pas les mêmes choses et les
géométries visibles sont subtilement différenciées).

Une autre façon pour Google est, dans les rendus à faible résolution, de
sélectionner "pseudo-aléatoirement" les liste des noeuds constituant un
tracé polygonal simplifié : ces tracés sont reproductibles (même caches
internet vidés) par un seul et même profil utilisateur Google, mais pas par
un autre. Visiblement Google a les moyens sur ses serveurs de faire des
rendus spécifiques, contrairement à nous où nos rendus sont les mêmes pour
tout le monde utilisant les mêmes requêtes web. Il sait faire ses rendus
essentiellement à la demande et n'a plus besoin de faire des prérendus,
sauf comme source secondaire si la charge instantanée des serveurs de rendu
personnalisé est trop importante, afin de répondre vite avec un rendu par
défaut sans ralentir la navigation : il ne fait pas du rendu personnalisé
sur toutes ses "tuiles" mais sur certaines et leurs voisines (pour faire
les raccordements), ce fond de rendu par défaut n'est plus directement
accessible, c'est devenu un cache totalement interne partagé entre ses
serveurs de rendu à la demande (qui surajoutent alors dessus les infos
personnalisées et les distribuer de façon inséparable).

On n'utilise même pas la géolocalisation de l'IP pour faire des rendus
différents selon le pays de résidence, comme l'avoue volontiers Google qui
n'affiche par exemple pas les frontieres russes autour de la Crimée de la
même façon si l'on est en Ukraine ou l'Union européenne ou si l'on est en
Russie...). Nous on se contente juste, comme le fait Wikimedia, de
mentionner les différentes revendications disputées selon le principe de
"NPOV", mais en retenant tout de même comme attributs principaux ceux
reconnus le plus largement au niveau international (source ONU privilégiée)

Depuis peu aussi Google fait du rendu personnalisé aussi pour ses rendus 3D
(y compris dans StreetView : il peut sélectionner les photos utilisées
ainsi que les notations superposées: linéaires, surfaciques ou libellés).

----

Bref les données de Google sont de plus en plus "plombées" un peu partout
de façon imprévisible de l'extérieur.

Et plus on utilise ses services (en enrichissant son profil utilisateur
personnel), plus la quantité de données personnalisées augmente sur Google
Maps, Google Earth, Google StreetView. Ainsi que sur tous les autres sites
affichant une cartographie Google ou utilisant ses APIs cartrographiques
(elles aussi toutes associées à une "API key" spécifique pour chaque
service : si le service a dépassé ses quotas, il perd le bénéfice de ses
personnalisations mais Google affiche encore une carte, cette fois
personnalisée selon le profil de l'utilisateur final du service, ce qui
veut dire aussi que Google peut déterminer quels liens publicitaires payées
par d'autres afficher à la place de celles souscrites par le service
utilisant son "API key" dont les quotas payés ont été dépassés : Google en
profite même pour privilégier des sites concurrents et forcer la main de
ceux dont l'API key a ses quotas dépassés !).

Quand on entre dans l'univers Google Maps, on ne peut plus en sortir
facilement : au départ c'est facile, ça marche tout de suite et cela semble
gratuit mais on finira par payer de plus en plus cher.

Heureusement OSM propose un systeme alternatif plus stable et plus
prévisible, où rien n'est caché et où chacun peut créer ses
personnalisations et sélections selon ses besoins, et contribuer de façon
plus collaborative. Si les cartes OSM sont trop lentes sur les serveurs par
défaut, chaque service peut mettre en place son propre rendu et améliorer
les performances pour son propre service.

Par exemple, si McDonald veut voir sur son site un rendu affichant juste
les restaurants McDonald et pas ceux de Quick, il peut le faire avec les
données d'OSM, pas avec Google Maps sauf en payant Google de plus en plus
cher pour l'usage de son "API key" spécifique McDonald (faute de quoi
Google fera disparaitre des éléments McDo, masquera les enseignes McDo dans
GoogleStreetView pour les rendre non reconnaissables mais au contraire
démasquer les enseignes de restaurants voisins) !

Et McDonald peut mettre en place son propre rendu OSM pour garantir les
performances sur son site, ou utiliser les services un des fournisseurs de
carto basées sur OSM (et respectant nos normes de neutralité des données
distribuées : le but étant que si nos données ne sont pas suffisantes, McDo
pourra contribuer à OSM pour l'enrichir, tout comme le peut aussi Quick. Le
tout sans perdre pourtant le contrôle de ce qu'il veut afficher ou
privilégier sur ses sites web s'il a envie de masquer Quick dans son rendu
pour son site). McDo peut maîtriser ses coûts, c'est lui qui décidera, pas
Google (via ses grilles tarifaires et dans ses restrictions de plus en plus
nombreuses de ses API "publiques") et on lui offre le l'infrastructure par
le choix des fournisseurs ou par l'utilisation de ses propres serveurs.

Et ce n'est pas parce que McDonald ou Quick auront enrichi la base OSM que
les autres réutilisateurs seront empêchés de préférer d'autres
personnalisations (y compris pour masquer McDo et Quick !) pour d'autres
usages où on n'a rien à faire de la restauration locale. Notre neutralité
collaborative (NPOV) ne cherche pas à privilégier un usage plutôt qu'un
autre, même quand il est au début plus minoritaire .

Avec le temps ces usages minoritaires trouvent de nouvelles applications et
permettent d'innover pour de nouveaux types de services, puis développer
des échanges entre services dans des domaines similaires en leur permettant
de collaborer entre eux (et donc aussi optimiser leurs coûts de mise en
œuvre, d'exploitation et de maintenance) : OSM (comme aussi Wikimedia) crée
des "communautés" thématiques (où figurent à la fois des utilisateurs
individuels, les plus nombreux, les collectivités et services publics
officiels, et les services commerciaux et où chacun y trouve "son compte",
ses usages et possibilités de personnalisation, et la liberté d'y entrer ou
d'en sortir à tout moment, et d'y revenir plus tard)...

Le 28 mars 2015 21:45, Pierre-Yves Berrard <pierre.yves.berrard at gmail.com>
a écrit :

> Le 28 mars 2015 18:52, Donat ROBAUX <donat.r at gmail.com> a écrit :
>
>> Petite lecture distrayante en ce WE de printemps.
>>
>>
>> http://www.estrepublicain.fr//edition-de-verdun/2015/03/27/verdun-le-gps-indique-une-rue
>>
> Le fameux "Oeuf de Pâques".
> La période tombe bien.
>
> PY
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20150329/3867cdb6/attachment.htm>