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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
