Re: [OSM-talk-fr] article sur un point de vue d'un dev sur l'usage d'OSM

2018-04-09 Par sujet Jean-Christophe Becquet 
Le 09/04/2018 18:20, marc marc a écrit :
> plus d'info :
> https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID

Bonjour,

Merci pour le partage d'explications et le lien.

Par rebond sur le wiki, j'ai découvert Query-to-map.

Query-to-map permet d'afficher les résultats d'une requête OpenStreetMap
sur une carte. Un bon outil pour lister et valider des données présentes
dans la base pour une zone définie par une bbox (Bounding Box).

Quelques exemples (il faut cliquer sur un item à gauche pour faire
apparaître la carte) :

Les rues de Digne-les-Bains
http://tools.wmflabs.org/query2map/featurelist.php?key=highway&value=&types=lines&BBOX=6.157685,44.032158,6.341043,44.175613

Les restaurants de Digne-les-Bains
http://tools.wmflabs.org/query2map/featurelist.php?key=amenity&value=restaurant&types=points&BBOX=6.157685,44.032158,6.341043,44.175613

Les médecins de Provence-Alpes Agglomération
http://tools.wmflabs.org/query2map/featurelist.php?key=amenity&value=doctors&types=points&BBOX=5.67,43.71,6.73,44.46

Les panneaux indicateurs pour la randonnée dans les Alpes de Haute-Provence
https://tools.wmflabs.org/query2map/featurelist.php?key=information&value=guidepost&types=points&BBOX=5.4964,43.6682,6.9697,44.6599


Query-to-map sur le wiki OSM (en anglais)
https://wiki.openstreetmap.org/wiki/Query-to-map

Bounding Box sur le wiki OSM (en anglais)
https://wiki.openstreetmap.org/wiki/Bounding_Box

Bonne journée

JCB
-- 
Le projet GNU
http://www.apitux.org/index.php?2006/01/09/8-le-projet-gnu

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
BP 32 - 04001 Digne-les-Bains Cedex
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===


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

Re: [OSM-talk-fr] article sur un point de vue d'un dev sur l'usage d'OSM

2018-04-09 Par sujet osm . sanspourriel 
> et pour résoudre cela, à court terme, on peux envisager un convertisseur
> (ou préprocesseur) qui corrigerait une série d'anomalie pour éviter que
> chaque utilisateur des données doit construire son préprocesseur.

Ca existe deja a la maniere de imposm3 qui va homogeneiser dans certains cas 1/yes/true.

 

Je suis d'accord sur un point : le ticket d'entree.

 

Sur Google c'est vrai que c'est homogene : tu payes=tu apparais.

 

Qunt a ne pas afficher un bar sans nom ca me depasse. Deja ca montre qu'on peut filtrer (Google KO) mais surtout soit tu cherches un bistrot dans le coin et le nom tu t'en fous soit tu cherches un resto non entre et tu ne trouvera pas.

 

 

Jean-Yvon


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

Re: [OSM-talk-fr] article sur un point de vue d'un dev sur l'usage d'OSM

2018-04-09 Par sujet Christian Quest 

C'est malheureusement un mécanisme assez bricolé...

J'avais aussi imaginé un système basé sur les geohash + quelques tags 
"majeurs" permettant de retrouver un objet d'un type donné dans une zone 
donnée. En fouillant sur talk-fr on doit pouvoir retomber dessus ;)


Exemple: amenity=cafe@geohash

Il faut un peu de flou, mais pas trop ou alors un flou variable... tant 
sur le côté sémantique que géo.


cle_secondaire=valeur_secondaire+cle_primaire=valeur_primaire@geohash_plus_ou_moins_long

Un mécanisme complet devrait permettre de passer d'un objet existant à 
cet id "stable" et pas que l'inverse.



Le 09/04/2018 à 18:20, marc marc a écrit :

Bonjour Jean-Christophe Becquet,

Le 09. 04. 18 à 18:04, Jean-Christophe Becquet a écrit :

Le 09/04/2018 15:33, marc marc a écrit :

- les id non stable dans osm : problème résolu depuis longtemps,
cfr overpass stable id.

Pourrais-tu expliquer en 2 mots de quoi il s'agit ou donner un lien vers
une ressource qui parle de ce overpass stable id ?

Cela consiste à utiliser un id qui est un index vers un ensemble de
caractéristique "stable" peu importe les id dans osm.
cela utilise une requête overpass avec les critères choisis.

exemple fictif :
un way actuellement nommé "rue de la gare" à "Paris 1er arrondissement"
entre le nœud a et le nœud b.

tu peux avoir un id stable qui pointerait toujours vers "rue de la gare"
à "Paris 1er arrondissement".
si quelqu'un coupe le way en 2 et change le nom d'un des 2 morceaux,
l'id stable pointera vers le morceau qui a gardé le nom.
si quelqu'un coupe le way et change le maspeed d'un des 2 morceaux,
l'id stable pointera vers les 2 morceaux puisqu'il ont gardé le nom.
si quelqu'un fait une modif tordu de déplacer ce way en chine,
l'id stable ne retournera plus rien.

tu peux aussi avoir un id stable qui représente la rue entre le point a
et le point b (exemple pour l'utiliser dans un itinéraire)
Si ce way osm est coupé en 2 et l'id stable pointera vers les 2 morceaux

Autre exemple fictif :
un poi pourrait avoir un id stable si tu considères l'emplacement du
magasin (cela pointera vers le nouveau "locataire" en cas de
changement") ou tu peux avoir un id stable vers "la succursale de Paris
de quel enseigne", qui résisterait aux déménagements et aussi aux
améliorations tagé comme un noeud -> tagé comme une surface.

plus d'info :
https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID

Cordialement,
Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] article sur un point de vue d'un dev sur l'usage d'OSM

2018-04-09 Par sujet marc marc 
Bonjour Jean-Christophe Becquet,

Le 09. 04. 18 à 18:04, Jean-Christophe Becquet a écrit :
> Le 09/04/2018 15:33, marc marc a écrit :
>> - les id non stable dans osm : problème résolu depuis longtemps,
>> cfr overpass stable id.
> Pourrais-tu expliquer en 2 mots de quoi il s'agit ou donner un lien vers
> une ressource qui parle de ce overpass stable id ?

Cela consiste à utiliser un id qui est un index vers un ensemble de 
caractéristique "stable" peu importe les id dans osm.
cela utilise une requête overpass avec les critères choisis.

exemple fictif :
un way actuellement nommé "rue de la gare" à "Paris 1er arrondissement" 
entre le nœud a et le nœud b.

tu peux avoir un id stable qui pointerait toujours vers "rue de la gare" 
à "Paris 1er arrondissement".
si quelqu'un coupe le way en 2 et change le nom d'un des 2 morceaux, 
l'id stable pointera vers le morceau qui a gardé le nom.
si quelqu'un coupe le way et change le maspeed d'un des 2 morceaux,
l'id stable pointera vers les 2 morceaux puisqu'il ont gardé le nom.
si quelqu'un fait une modif tordu de déplacer ce way en chine,
l'id stable ne retournera plus rien.

tu peux aussi avoir un id stable qui représente la rue entre le point a 
et le point b (exemple pour l'utiliser dans un itinéraire)
Si ce way osm est coupé en 2 et l'id stable pointera vers les 2 morceaux

Autre exemple fictif :
un poi pourrait avoir un id stable si tu considères l'emplacement du 
magasin (cela pointera vers le nouveau "locataire" en cas de 
changement") ou tu peux avoir un id stable vers "la succursale de Paris 
de quel enseigne", qui résisterait aux déménagements et aussi aux 
améliorations tagé comme un noeud -> tagé comme une surface.

plus d'info :
https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID

Cordialement,
Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] article sur un point de vue d'un dev sur l'usage d'OSM

2018-04-09 Par sujet PanierAvide 

Le 09/04/2018 à 18:04, Jean-Christophe Becquet a écrit :


Pourrais-tu expliquer en 2 mots de quoi il s'agit ou donner un lien vers
une ressource qui parle de ce overpass stable id ?

Bonjour,

C'est détaillé (brièvement) ici : 
https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID


Le concept c'est de faire le lien non pas par l'ID OSM, mais en 
utilisant une mini-requête Overpass avec une combinaison de tags 
suffisamment détaillée pour faire référence à un objet en particulier.


Cordialement,

Adrien.

--

PanierAvide
Géomaticien & développeur


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

Re: [OSM-talk-fr] article sur un point de vue d'un dev sur l'usage d'OSM

2018-04-09 Par sujet Jean-Christophe Becquet 
Le 09/04/2018 15:33, marc marc a écrit :
> - les id non stable dans osm : problème résolu depuis longtemps,
> cfr overpass stable id.

Bonjour Marc,

Pourrais-tu expliquer en 2 mots de quoi il s'agit ou donner un lien vers
une ressource qui parle de ce overpass stable id ?

Merci

Bonne soirée

JCB
-- 
Le projet GNU
http://www.apitux.org/index.php?2006/01/09/8-le-projet-gnu

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
BP 32 - 04001 Digne-les-Bains Cedex
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

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

Re: [OSM-talk-fr] article sur un point de vue d'un dev sur l'usage d'OSM

2018-04-09 Par sujet marc marc 
Bonjour,

Le 09. 04. 18 à 13:43, Nicolas Bétheuil a écrit :
> Ce n'est pas pour déclencher ici une polémique ou un troll velu mais
> plus pour partager un point de vue, au cas où cette article n'est pas
> remonté dans votre veille
> https://www.killiankemps.fr/fr/blog/faut-il-un-nouveau-openstreetmap

Je reste fortement sur ma faim à la lecture de l'article car je me 
demande bien en quoi la solution du titre résoudrait les problèmes de 
fond évoqués.

l'auteur exprime plusieurs problèmes :

- le fait que des logiciels "amateur" (dans le sens "fait comme loisir
et donc avec un temps limité" par opposition à "comme métier payant 
permettant d'y consacrer x h/semaine") ont des bugs ouvert en attente de 
"ressource".
changer de logiciel ne résout en rien cela.
tout au plus pourrions nous en conclure qu'il faudrait soit diminuer 
l'excessive diversité pour avoir au moins une brique stable par fonction 
(je veux dire par là par exemple que malgré la grande diversité 
d'éditeur sous ios aucun à mes yeux n'a une qualité exaltante)
soit trouver plus de sponsor pour avoir du financement,
comme ont une grande quantité d'acteurs dans l'opensource.

- la qualité des données dans osm (l'exemple d'un poi sans nom)
je ne vois pas en quoi changer de logiciel va résoudre cela.
si un contributeur veux introduire un café sans nom dans osm-bis,
cela revient à la même situation. la seule solution serrait d'imposer 
une liste de tag obligatoire (par exemple le nom) et dans ce cas, on se 
retrouve parfois comme pour les changeset où quelqu'un a mis "a" comme 
commentaire à de nombreux changeset parce que pas envie de décrire.
on a aussi le cas sur le wiki ou des opérations de masse sont faite sans 
descriptif parce que son auteur estime qu'à ses yeux, c'est pas utile,
avec les grincements que cela provoque régulièrement.
On peux difficilement éviter ceux qui pense que "les règles de l'art" ne 
sont pas pour eux ou ceux qui n'ont parfois simplement pas le temps ou 
pas l'info pour complèter tout (qui n'a jamais eu le cas d'avoir passé 
une soirée dans un lieu sans se souvenir de toutes les infos le lendemain ?)

- les adresses : oui c'est un gros problèmes, cfr la discussion 
précédente sur le sujet.
Sur ce point, il est vrai qu'il semble bien compliqué de proposer
un nouveau schéma puisque même un changement cosmétique de l'actuel
est compliqué même a argumenté.
mais que résoudrait un basculement vers osm-bis ?
soit osm-bis a un schéma qui résout ce problème, et celui ci pourrait 
aussi résoudre le problème dans osm. soit il ne le résout pas et rien ne 
change.

- les id non stable dans osm : problème résolu depuis longtemps,
cfr overpass stable id.
la vrai question est qu'est-ce qui doit être stable ?
un POI qui déménage 2 rues + loin, c'est le poi qui garde l'id même s'il 
bouge ? ou c'est le lieu qui garde l'id même s'il change de type ?
Pour l'instant ce serra au cas par cas. donc utilisation réduite.

- résistance au changement
Le seul vrai soucis que je vois c'est la résistance au changement,
par exemple quand le nom d'un tag est mal choisit (exemple 
highway=bus_stop), il y a une énorme résistance au changement pour 
modifier l'existant. c'est sans doute la seule chose où un osm-bis 
pourrait agir.
Par analogie avec apache<>ngix, osm n'est pas qu'un brique logicielle 
qu'il suffit de changer par "désinstalle apache, installe ngnix",
changer apache par ngnix n'a de sens que si les 2 sont capable de servir 
une page html.
de même la plus-value d'osm, c'est surtout sa db.
et pour résoudre cela, à court terme, on peux envisager un convertisseur 
(ou préprocesseur) qui corrigerait une série d'anomalie pour éviter que 
chaque utilisateur des données doit construire son préprocesseur.
Cependant, cela ne motive pas grand monde, suffit de voir les nombreuses 
opérations "tag de la semaine" que j'ai lancé pour corriger 
ponctuellement un problème de tag, c'était le jackpot quand on arrivait 
à 3 personnes actifs, hélas.
Faire un osm-bis ne résoudrait pas là non plus beaucoup les choses.
tout au plus cela pourrait mettre en place un autre de vote des schémas.
Finalement faire un préprocesseur, c'est le même travail que faire une 
édition de masse (hormis le problème de territorialité)
Et la bonne nouvelle à ce sujet, c'est qu'aucune opération d'édition de 
masse proposée en francophonie récemment n'a jamais subit la "résistance 
au changement".
donc il y a qu'à proposer pour améliorer ce qui peux l'être à ce niveau.

Cordialement,
Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] article sur un point de vue d'un dev sur l'usage d'OSM

2018-04-09 Par sujet Christian Quest 

J'ai posté quelques réponses sur mastodon...

https://mastodon.qowala.org/@KillianKemps/99824814902871590


1) ne pas confondre outils (périphériques au projet OSM) et le coeur du 
projet c'est à dire une base de données collaborative


Ok, leaflet et ses plugins ne correspondent pas forcément à 100% à vos 
besoins... mais ils sont ouvert, améliorables !


En tant que développeur, on peut aussi participer à leur amélioration, 
les PR sont les bienvenues !



2) la qualité des données...

Oui, c'est hétérogène et lié à l'activité des contributeurs (bénévoles, 
faut-il le rappeler).
Certains POI peuvent être très détaillés, d'autres moins et beaucoup 
manquent carrément.


Votre site/appli, permet de compléter ces données (dans OSM) ?

Oui... super, cela fait de nouvelles contributions qui vont améliorer 
l'ensemble.


Non... c'est bien dommage ! Occasion manquée de reverser dans le pot commun.


3) les identifiants ne sont pas stables

Effectivement mais ils ne changent pas si souvent que ça non plus.
On peut donc les conserver, ainsi que d'autres infos... le nom la 
position géographique (plus fiable que l'adresse).

On retrouvera par proximité les nouveaux objets.

Autre piste... compléter les données OSM avec un identifiant plus 
stable... par exemple le code SIRET de l'établissement (issu de la base 
SIRENE opendata) ref:FR:SIRET=*



4) "Je ne suis pas un spécialiste d'OpenStreetMap car je ne l'ai utilisé 
que quelques fois en tant que développeur"


Une posture de "consommateur" en quelque sorte... non ?

" j'ai le sentiment qu'en effet il faudrait faire un grand travail de 
fond sur le projet afin d'améliorer la qualité des données, d'améliorer 
la qualité des outils et de faciliter leur utilisation."


Tu es le bienvenu pour faire avancer le projet dans cette direction !



Le 09/04/2018 à 13:43, Nicolas Bétheuil a écrit :

Bonjour,

Ce n'est pas pour déclencher ici une polémique ou un troll velu mais
plus pour partager un point de vue, au cas où cette article n'est pas
remonté dans votre veille

https://www.killiankemps.fr/fr/blog/faut-il-un-nouveau-openstreetmap

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


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] article sur un point de vue d'un dev sur l'usage d'OSM

2018-04-09 Par sujet Philippe Verdy 
CEs auteurs confondent la mission d'OSM, faire une base de données, et de"s
éléments qui ne sont pas directement sa mission : fournir un service
cartographique. C'est justement l'intérêt d'OSM que de proposer un libre
choix de fouirnisseurs de services. Les services d'OSM ne sont réellement
destinées qu'aux contributeurs et utilisateurs occosionnels. Pour le reste
OSM fournit de nombreuses références à des fournisseurs de service.

L'auteur de l'article aussi confond ses propres besoins et critères de
"qualité" avec les besoins généraux de rapprochement selon les sources. Il
critique le manque de qualité, mais il pourrait faire les mêmes remarques
de défauts de complétenude et différences de précision ausi chez n'importe
quel autre founisseurs de données cartographiques, même "officiels". Car en
fin de compte (libre ou pas,n y compris lui-même) tout le monde essaye
d'essaye de faire de don mieux pour avoir le plus de renseignements
possibles, mais aucun n'y arrive tout seul: c'est pour ça qu'on a besoin de
collaboration, d'échanges libres de données et de corrections incrémentales
permettant à chacune de converger dans un but commun.

Google est ce qu'il voudrait utiliser en fin de compte par "pragmatisme",
mais il veut ignorer le fait qu'il s'en remet à un seul fournisseur (qui
n'aura pas de problème de cohérence puisqu'il maitrise tout et décide de
tout, y compris de ne pas publier des données pourtant disponibles et
vérifiables) juste parce qu'il a jugé que sa propre source était meilleure
pour lui et convenait mieux à ses utilisateurs selon ses propres choix
(mais maintenant de plus en plus en fonction de ses critères commerciaux,
ce qui lui permet de sélectionner les utilisateurs qui verront certaines
informations et en exclure d'autres, en leur proposant même des données
qu'ils ne cherchaient pas en remplacement de ce qu'ils cherchaient.

OSM est là pour inciter la collaboration non seulement des utilisateurs
individuels mais aussi des sources. Comme chacune n'arrive pas à atteindre
ses objectifs, la collaboration permet d'aller plus vite dans cette
convergence. Et il faut bien reconnaitre qu'OSM a réussi à coordonnéer des
millions d'utilisateurs, mais pas toujours sans heurts (et c'est inévitable
vu le nombre de contributeurs).

On pourrait dire la même chose d'OSM ou des réseaux sociaux: impossible
qu'ils soient parfaits et couvrent tous les besoins. OSM ne sera jamais
terminé car le monde évolue en permanence et plus on met de détails et plus
les corrections à faire et suivre deviennent nombreuses.

Il milite pour un "fork" du projet: aulieu d'avoir une source coordonnées
on en a deux et au final cela ne fait que ralentir la convergence.

Une célèbre série de cartoons américains montre deux personnages qui
critiquent la multiplicité des standards et normes: 15 normes existantes et
l'un d'eux lance l'idée : créons une super norme qui réunira tout avec une
interface unifiée. Peu de temps après au lieu de faire diaparaitre les 15
normes, on en a une de plus car la nouvelle ne suit pas les évolutions des
15 autres. Bref on a 16 normes. C'est l'effet des forks. Certains s'y sont
essayés et au final les fork d'OSM en tentant de mélanger les objectifs ont
abouti à des échecs.

Le but d'OSM n'est donc pas de fournir un service cartographique mais juste
de permettre d'en monter autant qu'on veut. Son objectif reste sa base de
données. Et sinon on a un large choix de fournisseurs de services. Et OSM
n'oblige personne à utiliser uniquement ses données : si un besoin
particulier demande d'utiliser d'autres données ou d'autres critères de
qualité non retenus ou soutenus par la communauté actuelle, à lui de créer
sa base de données pour ajouter ce qui manque ou filtrer ce qui ne lui
plait pas.

Bref ce n'est pas OSM qu'il faut critiquer mais le manque d'outils de
veille qualité facilitant la convergence et mesurer les écarts des sources.
La communauté en développe beaucoup, mais Google n'en fournit strictement
aucun: il veut s'imposer en s'imposant lui-même comme seul standard et il
l'utilise pour fabriquer une image du monde qui ne vise qu'à ses propres
projets commerciaux. Google ne garantit pas non plus que son service sera
pérenne, et en tant que fournisseur de services il n'arrête pas de les
changer, d'en créer et d'en arrêter d'autres, et changer les conditions
d'accès (et aussi les tarifs).

Ce qui est pourtant bien dans OSM c'est que chacun est très libre
d'expérimenter (m^me au sein de sa base de données) et développer les
services qu'il veut selon ses propres critères. Et on n'est pas obligé non
plus de fusionner toutes les données avec celles d'OSM si on a d'autres
préférences. On peut aussi choisir des prestataires commerciaux si on veut
un certain niveau de qualité de service, et librement intégrer seulement
une partie des donénes qu'on maitrise mais en faisant globalement confiance
à une communauté active de millions d'utilisateurs et de milliers de
sources libres qu'on peut aussi comparer.

Et en

Re: [OSM-talk-fr] article sur un point de vue d'un dev sur l'usage d'OSM

2018-04-09 Par sujet François Lacombe 
Je comprends bien son point de vue

Il faut s'interroger sur les résistances même du projet au changement.
Nous proposons l'une des solutions de carto et d'organisation de
l'information les plus en pointe, pour apporter une somme de changements
dans les organisations que nous rencontrons.

Sauf que d'autres ne sont pas prêts eux-même à envisager ce même
changement, pour diverses motivations, bonnes ou mauvaises ce n'est pas la
question.

Ainsi il faut bosser des mois pour définir ne serait-ce qu'un tag. Je le
fait volontiers mais on a mieux à faire je pense.
L'API n'a pas évolué depuis 10 ans ou presque (par exemple)

My 2 cts

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 9 avril 2018 à 13:43, Nicolas Bétheuil  a écrit :

> Bonjour,
>
> Ce n'est pas pour déclencher ici une polémique ou un troll velu mais
> plus pour partager un point de vue, au cas où cette article n'est pas
> remonté dans votre veille
>
> https://www.killiankemps.fr/fr/blog/faut-il-un-nouveau-openstreetmap
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr