[OSM-talk-fr] Import station essence

[Stéphane Péneau]

Résumons :

tl;dr
It's better since you choose not to overwrite the existing 
opening_hours, but the French community still refuse this import as is.

- A lot of "new" amenity=fuel are already in Osm
http://audit.osmz.ru/browse/navads_fuel/NVDS346_54a1ba689826bf65d6a31b83
http://audit.osmz.ru/browse/navads_fuel/NVDS368_545f7bfa82efa41a49637ace
Your conflation tool should check the existing fuel stations in a larger 
area.

- Most opening_hours are wrong.
A lot of fuel stations can be use 24/7 with a bank card.

- Phone numbers :
When a fuel station belongs to a supermarket, the phone's number is the 
supermarket one. I'm not sure it's a useful information.

- Don't delete imported objects with ref:navads
Sorry but we disagree. Check yourself if you must ignore a POI before 
adding it over and over in Osm.

- ref:navads
This ref tag is a private one. Nobody can use it. We understand that it 
will be easier for you to update the fuel station, but if everybody 
starts to use his private tag, the database will become a mess.

- postal code
Why ? a postal code for a supermarket, a car's shop, it's ok, but on a 
fuel station ?

We already have an open fuel station database. These data are included 
in Osmose to let the contributors manually check each node.



Le 28/03/2018 à 12:54, marc marc a écrit :
> deuzeffe le propriétaire d'une base peux tjs donner un droit spécifique
> pour l'ajout de ces données dans osm. les données dans osm seront alors
> accessible comme n'importe quel objet osm.
>
> Christian : pourquoi n'utilise-t-on pas la base des prix des carburants
> pour mettre à jour osm si elle contient de meilleurs infos ?
>
> JP : tu veux dire que si une marque est incorrecte,
> l'opération ne doit pas la corriger ?
> Alors faudrait une xieme catégorie osmose pour qu'un humain le fasse ?
>
> pour la conclusion, je crois qu'il faut nuancer par élément
> afin de garder l'utile au lieu de tout jeter :
>
> - heure d'ouverture : à virer vu que ceux-ci semblent souvent
> correspondre au magasin et non à la stations d'essence souvent 24/7
> en cas de payement possible par carte.
>
> - code postaux : aucun sens, personne n'écrit à une station d'essence.
> cela n'aurait du sens que pour les magasins.
> On pourrait pas contre s'en servir pour vérifier si les codes postaux
> définit sur les aires (les communes principalement) sont correct et
> faire une alerte qualité si cela ne correspond pas au lieu d'importer.
>
> - numéro de téléphone : uniquement les numéros uniques qui ont des
> changes d'être ceux de la station elle-même et non du siège social.
>
> - brand : cette info me semble par contre intéressante vu la confusion
> importante dans les stations actuelle entre nom <> operator <> brand
>
> - doublon : l'outil doit rechercher les doublons dans un rayons plus
> large que cela actuellement utilisé vu la géolocalisation imprécise.
> Ce n'est qu'alors qu'on pourrait se faire une idée des réels ajouts
> de station grâce à cette base par rapport à l'existant dans osm.
>
> - ref : si chaque compagnie de seo met sa propre ref, cela ne
> va évidement pas.
> d'un autre côté je comprend tout autant qu'une compagnie mondiale
> ne va pas utiliser 30 ref différentes selon la situation de chaque pays.
> je pense donc que l'outil doit se passer de ref.
>
> - disussed : tant mieux si l'import le gère.
> il doit cependant aussi prendre en compte à la prochaine maj les
> stations qui ont été effacée dans osm (analyse des diff) au lieu
> de les recréer (c'est pas au contributeur osm de se farcir la doc
> de tous les imports ayant un lien avec chaque objet qu'il modifie)
>
> - demander une copie de la base pour traiter les ajouts via osmose,
> j'y crois peu vu les 400k éléments en attente d'intervention humaine.
> osmose.openstreetmap.fr/fr/errors/graph.png?item=8xxx&country=france*
> Vaut mieux améliorer la qualité de l'import plutôt que de mettre
> sur une pile dont pas assez de monde ne s'occupe.
> Ce serra très différent si les créations étaient séparée des maj
>
> Stéphane si t'as besoin d'un coup de main pour formuler
> tout cela en anglais, dis le moi.
> ou mieux un dernier brouillon ici avant envoi histoire que les doués
> en anglais corrigent au besoin :)
>
> Le 28. 03. 18 à 11:55, Christian Quest a écrit :
>> En gros la conclusion c'est quoi ? Communauté FR opposée à cet import ?
>> ok pour moi ;)
>>
>> On a des données plus propre dans la base des prix des carburants.
>>
>> Le 27 mars 2018 à 22:01, Stéphane Péneau a écrit :
>>
>>      Il n'y a plus de remarque ? J'envoie la réponse ?
>>
>>      Stf
>>
>>
>>      Le 26/03/2018 à 14:58, Stéphane Péneau a écrit :
>>
>>          Pour ma part, j'ai trouvé plusieurs stations-service manquantes
>>          que ce jeu de données pourrait ajouter.
>>          Donc non, je ne pense pas qu'il faut tout jeter, ni lui tomber
>>          dessus en hurlant que son truc, "c'est d'la merde".
>>
>>          J'espère qu'on peut être un peu plus constructif. On a tous à y
>>          gagner.
>>
>>          Stf
>>
>>          Le 26/03/2018 à 14:33, deuzeffe a écrit :
>>
>>              Le 26/03/2018 à 13:47, marc marc a écrit :
>>
>>                  La source est Navads.
>>
>>
>>              Et « We have the full permission to add all of these to
>>              OpenStreetMap: that's the very reason we were contacted. »
>>              (from https://wiki.openstreetmap.org/wiki/Navads_Imports#Source)
>>              semble suffisant ? Quid de telles données une fois qu'elles
>>              font partie d'OSM, avec une telle (absence de) licence
>>              (clairement pas identifiée) ?
>>
>>              --
>>              deuzeffe - qui s'instruit
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr