Re: [OSM-talk-fr] Import d'horaires et :covid19

[Florian LAINEZ]

Hello,
Une autre manière d'éviter des imports, c'est d'utiliser tout simplement
opening_hours:covid19=same ;)

Le jeu. 26 nov. 2020 à 00:51, David Faure via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> On mercredi 25 novembre 2020 22:27:34 CET osm.sanspourr...@spamgourmet.com
> wrote:
> > Bonjour, les messages de Marc et de David sont l'occasion de rappeler à
> > propos des horaires que quand on a une source fiable, on n'a pas à se
> > poser la question de savoir si on doit ou pas avec un suffixe :covid19.
>
> Ah, en effet.
>
> > Du coup je propose (en dehors du script histoire de ne pas engendrer des
> > aller-retours) de supprimer les opening_hours:covid19 si on met à jour
> > opening_hours automatiquement.
>
> Ca ne rentre pas tout a fait dans mon approche conservative..
> Je ne touche pas aux bureaux avec opening_hours, donc :
> - ceux qui ont opening_hours et opening_hours:covid19, j'y touche pas
> - ceux qui ont *seulement* opening_hours:covid19 (il y en a 788), oups, il
> faut prendre ça en compte :
>
> * 139 disent "open", bon, on peut laisser ça et importer opening_hours.
> * 448 disent "off", ça rentre dans le "désaccord" et du coup je ne devrais
> pas y toucher. Même si je suspecte fortement que ça date du premier
> confinement et que c'est maintenant ouvert, comme indiqué par datanova.
> * et 201 ont de vrais horaires, mais différents de ceux de datanova, donc
> pareil, pas touche...
>
> > Ce sont peut-être en partie les bureaux que David trouve avec des
> > horaires en conflits OSM <> Datanova.
>
> Ceux qui n'ont rien dans opening_hours sont de nouveaux conflits :-)
>
> Du coup, 649 imports de moins.
>
> Mais bon faut relativiser, y'a jusqu'à 5376 imports potentiels en plus,
> qui ne se font pas parce que la ref:FR:LaPoste est manquante dans OSM.
> Donc clairement ce qui aidera le plus après l'import initial, c'est de
> terminer l'intégration de l'import des bureaux de poste (beaucoup de ref
> manquantes).
>
> http://osmose.openstreetmap.fr/fr/map/#zoom=9=44.147=4.729=7050%2C8020%2C8021%2C8022=1%2C2%2C3=post=
>
> > Auquel cas ça faut le coup de supprimer opening_hours:covid19 si on met
> > à jour opening_hours automatiquement.
>
> Avec l'approche conservative de "si y'a, je touche pas", ça veut dire que
> je ne supprime pas opening_hours:covid19
> non plus. Sauf si on décide que c'est un cas où on veut donner priorité
> aux données de la poste, mais difficile d'être sûr
> de si c'est 100% correct. Je crains toujours le cas d'une ref:FR:LaPoste
> incorrecte (suite à renumérotation par exemple).
> Donc je donne priorité à "la fourmi sur place", je ne fournis des données
> "que" pour les 8889 cas où il n'y a pour l'instant aucune info.
> C'est déjà pas mal :)
>
> > David, c'est donc ma proposition pour gérer une partie des cas refusés
> > pour le moment : on compare avec opening_hours:covid19, si c'est bon on
> > supprime opening_hours:covid19 et on met opening_hours à jour.
>
> Malheureusement j'ai 0 cas où datanova == opening_hours:covid19...
>
> Les choses ont changé depuis mars, aucun bureau n'a les mêmes horaires
> maintenant qu'en mars...
> Exemple au hasard :
> 17129A: no opening_hours but covid hours: Mo-Fr 09:00-12:00,14:00-17:00,
> datanova: Mo-Fr 09:00-18:30; Sa 08:30-12:30; PH off
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 

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

Re: [OSM-talk-fr] Import d'horaires et :covid19

[David Faure via Talk-fr]

On mercredi 25 novembre 2020 22:27:34 CET osm.sanspourr...@spamgourmet.com 
wrote:
> Bonjour, les messages de Marc et de David sont l'occasion de rappeler à
> propos des horaires que quand on a une source fiable, on n'a pas à se
> poser la question de savoir si on doit ou pas avec un suffixe :covid19.

Ah, en effet.

> Du coup je propose (en dehors du script histoire de ne pas engendrer des
> aller-retours) de supprimer les opening_hours:covid19 si on met à jour
> opening_hours automatiquement.

Ca ne rentre pas tout a fait dans mon approche conservative..
Je ne touche pas aux bureaux avec opening_hours, donc :
- ceux qui ont opening_hours et opening_hours:covid19, j'y touche pas
- ceux qui ont *seulement* opening_hours:covid19 (il y en a 788), oups, il faut 
prendre ça en compte :

* 139 disent "open", bon, on peut laisser ça et importer opening_hours.
* 448 disent "off", ça rentre dans le "désaccord" et du coup je ne devrais pas 
y toucher. Même si je suspecte fortement que ça date du premier confinement et 
que c'est maintenant ouvert, comme indiqué par datanova.
* et 201 ont de vrais horaires, mais différents de ceux de datanova, donc 
pareil, pas touche...

> Ce sont peut-être en partie les bureaux que David trouve avec des
> horaires en conflits OSM <> Datanova.

Ceux qui n'ont rien dans opening_hours sont de nouveaux conflits :-)

Du coup, 649 imports de moins.

Mais bon faut relativiser, y'a jusqu'à 5376 imports potentiels en plus, qui ne 
se font pas parce que la ref:FR:LaPoste est manquante dans OSM.
Donc clairement ce qui aidera le plus après l'import initial, c'est de terminer 
l'intégration de l'import des bureaux de poste (beaucoup de ref manquantes).
http://osmose.openstreetmap.fr/fr/map/#zoom=9=44.147=4.729=7050%2C8020%2C8021%2C8022=1%2C2%2C3=post=

> Auquel cas ça faut le coup de supprimer opening_hours:covid19 si on met
> à jour opening_hours automatiquement.

Avec l'approche conservative de "si y'a, je touche pas", ça veut dire que je ne 
supprime pas opening_hours:covid19
non plus. Sauf si on décide que c'est un cas où on veut donner priorité aux 
données de la poste, mais difficile d'être sûr
de si c'est 100% correct. Je crains toujours le cas d'une ref:FR:LaPoste 
incorrecte (suite à renumérotation par exemple).
Donc je donne priorité à "la fourmi sur place", je ne fournis des données "que" 
pour les 8889 cas où il n'y a pour l'instant aucune info.
C'est déjà pas mal :)

> David, c'est donc ma proposition pour gérer une partie des cas refusés
> pour le moment : on compare avec opening_hours:covid19, si c'est bon on
> supprime opening_hours:covid19 et on met opening_hours à jour.

Malheureusement j'ai 0 cas où datanova == opening_hours:covid19...

Les choses ont changé depuis mars, aucun bureau n'a les mêmes horaires 
maintenant qu'en mars...
Exemple au hasard :
17129A: no opening_hours but covid hours: Mo-Fr 09:00-12:00,14:00-17:00, 
datanova: Mo-Fr 09:00-18:30; Sa 08:30-12:30; PH off

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import d'horaires et :covid19

[osm . sanspourriel]

Bonjour, les messages de Marc et de David sont l'occasion de rappeler à
propos des horaires que quand on a une source fiable, on n'a pas à se
poser la question de savoir si on doit ou pas avec un suffixe :covid19.

Marc parlait des sites en déshérence, on a aussi, plus pervers, les
données mises à jour quotidiennement mais dont les données ne remontent
pas du terrain (cas de Super U). Dans le genre faux amis...

Du coup je propose (en dehors du script histoire de ne pas engendrer des
aller-retours) de supprimer les opening_hours:covid19 si on met à jour
opening_hours automatiquement.

J'en trouve 8 rien que sur le Finistère  : http://overpass-turbo.eu/s/10yR

Ce sont peut-être en partie les bureaux que David trouve avec des
horaires en conflits OSM <> Datanova.

Auquel cas ça faut le coup de supprimer opening_hours:covid19 si on met
à jour opening_hours automatiquement.

David, c'est donc ma proposition pour gérer une partie des cas refusés
pour le moment : on compare avec opening_hours:covid19, si c'est bon on
supprime opening_hours:covid19 et on met opening_hours à jour.

Jean-Yvon



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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[Romain MEHUT]

Idem.

Romain

Le 25/11/2020 à 22:19, Brice a écrit :

Le 25/11/2020 à 21:39, David Faure via Talk-fr a écrit :

OK pour tout le monde ?


OK pour moi

Britzz

___
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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[osm . sanspourriel]

Le 25/11/2020 à 21:39, David Faure via Talk-fr -
talk-fr@openstreetmap.org a écrit :


chacun étant limité à une région de 500m² pour éviter les notifications sur une 
trop grande
zone.

David parle bien sûr de km².

OK pour tout le monde ?


OK pour moi comme tu t'en doutes, je crée un autre fil sur opening_hours
et opening_hours:covid19.

Jean-Yvon



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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[Brice]

Le 25/11/2020 à 21:39, David Faure via Talk-fr a écrit :

OK pour tout le monde ?


OK pour moi

Britzz

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

[OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

Bonjour à tous,

Voici un résumé de l'état des choses concernant cet import, après les 
discussions ici (et aussi en privé avec Jean-Yvon qui m'a donné de nombreux 
bons conseils).

Pour rappel, tout est documenté sur :
https://wiki.openstreetmap.org/wiki/Import/FrenchPostOfficeOpeningHours

J'ai de quoi importer des horaires pour 9730 bureaux de poste identifiés dans 
OSM par leur référence LaPoste. La plupart n'ont pas du tout d'horaires pour 
l'instant, et pour 183 d'entre eux les horaires collent sauf qu'il manque "PH 
off" à la fin, je propose donc de l'ajouter pour que soit exactement égal.

Au lieu de la manip manuelle initialement suggérée (avec JOSM),
j'ai maintenant le code qui va bien pour découper en changesets, chacun étant 
limité à une région de 500m² pour éviter les notifications sur une trop grande 
zone.
Ça donne 1537 changesets concernant chacun entre 1 et 96 bureaux de poste.

Vu les discussions précédentes, je ne touche pas à l'attribut source, 
seulement à opening_hours. Je ne touche pas non plus aux 1057 bureaux qui ont 
un horaire différent dans OSM et datanova. On verra plus tard pour l'idée 
d'ajouter un fixme ou d'utiliser osmose pour montrer ces différences.
On verra aussi plus tard pour intégrer "collection_times". Autant faire 
incrémental.

L'upload de ces changesets est scripté lui aussi, avec osm-bulk-upload.
J'ai testé les scripts sur un bureau de poste prêt d'ici, tout marche.

A ce stade, je me sens donc prêt à uploader tout ça, mais c'est l'occasion de 
faire un dernier point ici pour avoir votre accord d'abord.

Par la suite, ces mêmes scripts mettront à jour les horaires modifiés par 
datanova, si personne n'y a touché dans OSM entre temps. Tout est déjà codé et 
testé pour pouvoir faire ça. Je pense le lancer tous les week-ends, pour bien 
avoir des horaires à jour, y compris quand un bureau décide d'une fermeture 
exceptionnelle pour la semaine suivante.

OK pour tout le monde ?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] a propos de dev.osm162.openstreetmap.fr

[osm . sanspourriel]

Et pourquoi se manger des certificats HTTPS quand le http marche ?

http://dev.osm162.openstreetmap.fr/20km_chacun.html marche et ne braille
pas.

KISS

Jean-Yvon

Le 25/11/2020 à 15:31, David Crochet - david.croc...@free.fr a écrit :



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

Re: [OSM-talk-fr] Suffixe :covid19

[Éric Gillet]

Le 25/11/2020 à 18:44, Marc_marc a écrit :

Bonjour,

Le 25.11.20 à 18:21, Éric Gillet a écrit :

Salut,

Le 25/11/2020 à 15:03, Florian LAINEZ a écrit :

les opening_hours:covid19 ont encore leur intérêt pour quelques temps.

Est-ce que tu pourrais en citer des avantages ?

l'avantage que j'y trouve, c'est que cela renseigne que quelqu'un
s'est préoccupé des horaires en situation "perturbée covid19".
Autant cela semblait une bonne idée quand il y avait
un espoir que cela dure 3 semaines et que cela a de moins
en moins de sens après 3 saisons ou presque puisque les
commerces changent aussi d'horaire pour des raisons non covid.
Oui au début du confinement en effet c'était impossible de deviner les 
évolutions de la pandémie, et difficile d'avoir une vision sur le 
long-terme.


Maintenant qu'on a 6 mois de recul, on peut se permettre de penser aux 
3-12 prochains mois je pense.



et dbnc de mon expérience, je considère les choses ainsi :
- si pas de :covid19, alors ne pas croire les infos osm
- si covid19 avec date de modif "durant cette vague", alors les croire
- si covid19 avec date durant la première vague : les livraisons
ou truc du genre sont généralement valide (un commerce qui s'y est mis
pour la première vague, continue pareil pour la 2ieme). mais pour
les horaires, vérif avant, cela change trop souvent.

évidement une date de modif récente donne presque la même info
un survey:date ou un changeset avec source=survey tout autant,
voir encore mieux (parce que des sites web périmé, surtout
en cas de faillite, cela existe)


Je pense que beaucoup font comme toi, moi y compris.
Du coup s'il faut se baser sur la date de modif pour estimer la validité 
des infos, même avec les clés suffixées covid19, quel sont leur intérêt 
vis-à-vis des clés non-suffixées ?



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

Re: [OSM-talk-fr] Suffixe :covid19

[Marc_marc]

Bonjour,

Le 25.11.20 à 18:21, Éric Gillet a écrit :
> Salut,
> 
> Le 25/11/2020 à 15:03, Florian LAINEZ a écrit :
>> les opening_hours:covid19 ont encore leur intérêt pour quelques temps.
> 
> Est-ce que tu pourrais en citer des avantages ?

l'avantage que j'y trouve, c'est que cela renseigne que quelqu'un
s'est préoccupé des horaires en situation "perturbée covid19".
Autant cela semblait une bonne idée quand il y avait
un espoir que cela dure 3 semaines et que cela a de moins
en moins de sens après 3 saisons ou presque puisque les
commerces changent aussi d'horaire pour des raisons non covid.

et dbnc de mon expérience, je considère les choses ainsi :
- si pas de :covid19, alors ne pas croire les infos osm
- si covid19 avec date de modif "durant cette vague", alors les croire
- si covid19 avec date durant la première vague : les livraisons
ou truc du genre sont généralement valide (un commerce qui s'y est mis
pour la première vague, continue pareil pour la 2ieme). mais pour
les horaires, vérif avant, cela change trop souvent.

évidement une date de modif récente donne presque la même info
un survey:date ou un changeset avec source=survey tout autant,
voir encore mieux (parce que des sites web périmé, surtout
en cas de faillite, cela existe)

Cordialement,
Marc



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

Re: [OSM-talk-fr] Suffixe :covid19

[Éric Gillet]

Salut,

Le 25/11/2020 à 15:03, Florian LAINEZ a écrit :
Je pense que les 2 approches (se débarrasser ou non des tags covid19) 
ont chacune leurs avantages et inconvénients.


De ma propre expérience sur le terrain et de la majorité de vos 
retours, je constate que les opening_hours:covid19 ont encore leur 
intérêt pour quelques temps.


Est-ce que tu pourrais en citer des avantages ? J'ai du mal à en 
trouver, j'en vois pas non plus sur la page wiki OSM 
.


J'ai l'impression que le seul intérêt de se tag serait qu'à une certaine 
date (laquelle ?), on puisse supprimer tous les tags et activer le 
"fonctionnement normal".


Vu le calendrier  on s'approchera 
des 1 an des mesures gouvernementales et de ces tags; je pense que tout 
le monde s'accordera pour dire que peu de commerces fonctionneront 
exactement comme avant.
Il faudra donc revérifier régulièrement les horaires et autres infos 
manuellement de chaque commerce à chaque changement de politique 
sanitaire, mais aussi entre (elles peuvent changer indépendamment de 
l'État).


Continuer à utiliser un suffixe au lieu des clés classiques ça veut dire 
diluer les données sur des tags différents.
Ces tags seront pas forcément mis à jour (StreetComplete vs 
CaResteOuvert par exemple) et pas forcément consommés (Maps.me, OsmAnd 
par exemple).


Utiliser les tags "classiques" (sans suffixes) corrige toutes ces 
problématiques.
Si on estime que beaucoup de commerces ont changé leurs horaires à 
partir d'une date (confinement, déconfinement, vaccin etc.), rien 
n'empêche de redemander aux utilisateurs en fonction de :


 * la dernière date d'édition,
 * des tags check_date
    stocké dans OSM
   ou ailleurs
 * ou périodiquement comme font StreetComplete et Google Maps notamment

Je pense qu'on devrait utiliser opening_hours:covid19=same le plus 
possible, et je vais y réfléchir pour les évolutions de "ça reste ouvert".


Ce serait un éventuel compromis pour garder la compatibilité avec des 
applications qui ne géreraient que les versions suffixées, bonne idée !


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

Re: [OSM-talk-fr] a propos de dev.osm162.openstreetmap.fr

[Vincent de Château-Thierry]

> De: "David Crochet" 
> 
> Le 25/11/2020 à 15:08, Marc_marc a écrit :
> > mais pq utiliser l'url de dev alors que c'est en prod
> > soushttps://bano.openstreetmap.fr  ?
> 
> Car https://bano.openstreetmap.fr/20km_chacun.html ne répond pas
> alors que https://dev.osm162.openstreetmap.fr/20km_chacun.html# oui

En effet et c'est prévu comme ça. dev.osm162 et bano sont hébergés sur la même 
machine virtuelle mais les points communs s'arrêtent là, l'un n'est pas le site 
de dev de l'autre.

vincent

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

Re: [OSM-talk-fr] a propos de dev.osm162.openstreetmap.fr

[David Crochet]

Bonjour


Le 25/11/2020 à 15:08, Marc_marc a écrit :

mais pq utiliser l'url de dev alors que c'est en prod
soushttps://bano.openstreetmap.fr  ?



Car https://bano.openstreetmap.fr/20km_chacun.html ne répond pas alors 
que https://dev.osm162.openstreetmap.fr/20km_chacun.html# oui


Cordialement

--
David Crochet

--
David Crochet


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

Re: [OSM-talk-fr] a propos de dev.osm162.openstreetmap.fr

[Vincent de Château-Thierry]

Bonjour,

> De: "David Crochet" 
> 
> Firefox n'aime pas https://dev.osm162.openstreetmap.fr/ car il lui
> manque quelque chose (un certificat pour faire du 's' en http ?)

Merci David. J'ai ouvert ce ticket 
https://github.com/osm-fr/infrastructure/issues/247 sur le sujet.

vincent

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

Re: [OSM-talk-fr] a propos de dev.osm162.openstreetmap.fr

[Marc_marc]

Bonjour,

Le 25.11.20 à 14:24, David Crochet a écrit :
> Firefox n'aime pas https://dev.osm162.openstreetmap.fr/ car il lui
> manque quelque chose (un certificat pour faire du 's' en http ?)

en effet le certificat manquant.
mais pq utiliser l'url de dev alors que c'est en prod
sous https://bano.openstreetmap.fr ?

Cordialement,
Marc



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

Re: [OSM-talk-fr] Suffixe :covid19

[Florian LAINEZ]

Hello,
Je pense que les 2 approches (se débarrasser ou non des tags covid19) ont
chacune leurs avantages et inconvénients.

De ma propre expérience sur le terrain et de la majorité de vos retours, je
constate que les opening_hours:covid19 ont encore leur intérêt pour
quelques temps.
Je pense qu'on devrait utiliser opening_hours:covid19=same le plus
possible, et je vais y réfléchir pour les évolutions de "ça reste ouvert".

j'ai pris des photos
https://github.com/caresteouvert/caresteouvert/issues/841 et je veux bien
les vôtres pour identifier les cas problématiques svp.

Le sam. 21 nov. 2020 à 14:23, Yves P.  a écrit :

> > Non ça veut dire qu'il n'y a plus que opening_hours.
>
> Ceci (n') est (pas) une pipe (cf. René Magritte dans la Trahison des
> images) :D
>
> > Donc tu as un horaire, pour savoir si c'est l'horaire standard ou pas tu
> > dois regarder si tu es en France s'il y a opening_hours:before_covid19
> > et si tu es ailleurs opening_hours:covid19.
>
> Je ne dois pas être clair :D
>
> Si tu fais ça, que vois une application standard ?
> Uniquement le tag opening_hours. Donc elle affiche… l'horaire :)
>
> Pour opening_hours:before_covid19, c'est comme pour le rendu avec les
> préfixes destroyed:* knidnapped:* JaimePasLaChoucroute:* ;)
>
> Il ne se passe rien car aucune application ne sait quoi en faire.
>
>
> > Super sympa pour les applis qui veulent indiquer s'il s'agit d'horaires
> > adaptés.
>
> Même CRO affiche l'horaire correctement.
> (Car CRO est basé sur un pays. Il n'a pas forcément le même comportement
> dans un autre territoire).
>
> Mais je le rappel, je ne veux rien ;)
> Je m'interroge suite à la remarque appropriée d'Éric .
>
> Ce que je propose fonctionne, mais y a-t-il un intérêt à dépenser de
> l'énergie pour la mettre en place, c'est une autre question :)
>
> __
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 

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

Re: [OSM-talk-fr] Proposition - Vote - Les pompes

[François Lacombe]

Merc Lejun pour ce retour

Il y a en effet des craintes à changer des tags existants.
Il faudrait néanmoins savoir ce que ça veut dire.

Certaines tentatives de tagging ont été un échec mais en appliquant les
mêmes méthodes je pourrais très bien dire que ces tags existent donc on y
touche pas.
Le vrai problème se pose lorsque ca oblige à utiliser des termes moins
clairs, juste pour préserver ce qui existe sans aucune autre raison.

Dommage de passer du temps là-dessus, le vote est mis en pause le temps
d'évaluer les impacts

Bonne après-midi

François

Le mer. 25 nov. 2020 à 06:45, lejun  a écrit :

> Sur OSM aussi il y a une part de conservateurs qui veulent maintenir
> l'usage d'un ancien attribut quitte à en mettre une couche par dessus.
> Oui j'pense à vous, ceux qui travaillent sur les transports publics et
> qui en êtes au moins à la 4e version officielle surajoutée.
>
> Bon courage pour la suite !
>
> Le 24/11/2020 à 20:41, François Lacombe a écrit :
> >
> > Toutefois et sans être spécifique au cas précis et très technique des
> > pompes, je reste en désaccord avec le maintien d'une clé prétendument
> > utilisée par principe.
> > Le niveau d'utilisation d'une clé est imprécis, considéré de manière
> > différente suivant les personnes.
> > C'est un risque pour OSM : quand tous les tags seront réputés utilisés,
> > on ne changera plus rien.
> > Ici est opposée l'existence de 30 000 utilisations sur 14% *seulement*
> > des objets censés le recevoir. Ce n'est pas acceptable.
> > La recherche de qualité, d'innovation propre à OSM mérite vraiment mieux
> > à mon sens.
>
> --
> Lejun - Groupe Local OpenStreetMap Bourgogne-Franche-Comté
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] a propos de dev.osm162.openstreetmap.fr

[David Crochet]

Bonjour

Firefox n'aime pas https://dev.osm162.openstreetmap.fr/ car il lui 
manque quelque chose (un certificat pour faire du 's' en http ?)


Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec données OSM

[Christian Quest]

Le 25/11/2020 à 10:32, Rpnpif via Talk-fr a écrit :

Le 24/11/2020 à 20:37, Jean-Marc Liotier a écrit :

On 11/24/20 6:22 PM, Frédéric Rodrigo wrote:
Ce n'est pas aussi facile que ça pour faire une emprise mondiale. Il 
est nécessaire d'écrire des adaptateurs pour chaque langue ou pays 
pour traiter les particularités.


Je découvre donc:

- La phonemicization: 
https://github.com/addok/addok-fr/blob/master/addok_fr/utils.py


- Les particularités Françaises: 
https://github.com/addok/addok-france/blob/master/addok_france/utils.py


On comprend vite qu'il sera compliqué d'accepter une recherche sans 
connaître dans quel zone administrative et linguistique elle s'inscrit...


La « phonemicization » ressemble à une sorte de phonétisation 
simplifiée, non ?


Pourquoi n'avoir pas pris de bibliothèques de phonétisation qui sont 
beaucoup plus complètes et plus adaptables à la zone de recherche, 
comme celles des moteurs de recherche ?

Trop lourdes ?



Oui, librairie souvent lourdes et souvent très anglophones. Le but n'est 
pas non plus d'obtenir une traduction phonétique, mais une 
simplification pour ajouter du flou à la recherche.


On floute à l'aide de quelques regexp très rapides, on cherche dans 
l'index, puis on trie en comparant les libellés non floutés.



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec données OSM

[Rpnpif via Talk-fr]

Le 24/11/2020 à 20:37, Jean-Marc Liotier a écrit :

On 11/24/20 6:22 PM, Frédéric Rodrigo wrote:
Ce n'est pas aussi facile que ça pour faire une emprise mondiale. Il 
est nécessaire d'écrire des adaptateurs pour chaque langue ou pays 
pour traiter les particularités.


Je découvre donc:

- La phonemicization: 
https://github.com/addok/addok-fr/blob/master/addok_fr/utils.py


- Les particularités Françaises: 
https://github.com/addok/addok-france/blob/master/addok_france/utils.py


On comprend vite qu'il sera compliqué d'accepter une recherche sans 
connaître dans quel zone administrative et linguistique elle s'inscrit...


La « phonemicization » ressemble à une sorte de phonétisation 
simplifiée, non ?


Pourquoi n'avoir pas pris de bibliothèques de phonétisation qui sont 
beaucoup plus complètes et plus adaptables à la zone de recherche, comme 
celles des moteurs de recherche ?

Trop lourdes ?

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

Re: [OSM-talk-fr] Lot Talk-fr, Vol 172, Parution 70

[François Bojarski via Talk-fr]

our faire une emprise mondiale. Il
>>> est nécessaire d'écrire des adaptateurs pour chaque langue ou pays
>>> pour traiter les particularités.
>>>
>>> Le mar. 24 nov. 2020 à 10:41, Jean-Marc Liotier >> <mailto:j...@liotier.org>> a écrit :
>>>
>>> On 11/23/20 10:32 PM, Christian Quest wrote:
>>> > L'index redis occupe dans les 16Go de RAM, la base sqlite 2Go,
>>> elle
>>> > aussi en RAM pour un max de perfs.
>>> Pour la France seulement... Ca apporte d'un coup tous ce dont
>>> l'absence
>>> frustre dans Nominatim - mais c'est un sérieux investissement en
>>> matériel pour une emprise mondiale... Même problème que la mise à
>>> disposition de tuiles: vitrine indispensable mais qui risque d'être
>>> considéré comme un service public.
>>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@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/20201125/c7b1e39d/attachment.htm>
>
> --
>
> Subject: Pied de page des remises groupées
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
> --
>
> Fin de Lot Talk-fr, Vol 172, Parution 70
> ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] addok et demo.addok.xyz : géocodage avec données OSM

[Christian Quest]

On en parle... pas mal de tests à faire avant ça et puis un petit sujet 
financement.



Le 25/11/2020 à 07:56, Cyrille37 OSM via Talk-fr a écrit :


Bonjour,

Y a t'il une chance que adresse.data.gouv.fr intègre cette nouvelle 
mouture v1.1  ?


C/.

Le 24/11/2020 à 19:39, Christian Quest a écrit :


Oui, ce n'est pas le but d'addok... qui trop embrasse mal étreint ;)

J'envisage par contre de rajouter des données hors de France, 
typiquement les noms des villes dans le monde entier pour pouvoir 
chercher "Le caire" ou "Tokyo".


Pour le côté service public, je pense que DEMO.addok.xyz pose bien 
les choses ;)




--
Christian Quest - OpenStreetMap France


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