[OSM-talk-fr] Mise à jour des POIs

2018-07-20 Thread Francois Gouget 

On peut mettre pas mal d'information sur les commerces et restaurants 
dans OpenStreetMap. Avoir ces informations à disposition hors ligne sur 
un téléphone est très pratique. Mais des informations comme les horaires 
d'ouverture ont pas mal tendance à changer, notamment pour les congés 
annuels, et sont donc difficiles à maintenir à jour.

En plus, plusieurs sites s'occupent de tenir ces informations à jour : 
Google Maps bien sûr, mais aussi les Pages Jaunes, Le Figaro, et pas mal 
d'autres sites spécialisés comme la Fourchette, Travelocity, etc.

Pour un commerçant aller mettre tous ces sites à jour n'a aucun sens. Et 
c'est aussi un gros gaspi que chaque site envoie du monde pour aller 
collecter les horaires.

Ce qu'il faudrait c'est que les commerces disposent d'une méthode 
standard pour publier leurs horaires et autres informations (du type de 
cuisine à la présence d'un distributeur de billet), avec une licence qui 
autorise la réutlisation par tous les acteurs (de Google à 
OpenStreetMap).

Il y a un modèle qui serait simple : robots.txt. Ce fichier est 
standardisé et indique à n'importe quel moteur de recherche, aussi bien 
Google que Bing, quelles pages ne doivent pas être indexées.

Donc on pourrait définir un standard où il suffirait à tout commerce, 
restaurant ou artisan ayant un site web de mettre un fichier poi.txt 
dans la racine dudit site pour publier une bonne fois pour toutes les 
informations utiles pour leur commerce, restaurant ou service.

Pour ceux qui n'ont pas leur propre site mais, par exemple, juste une 
page FaceBook, ils pourraient mettre le fichier poi.txt quelque part 
dans leur espace. Les services utilisant le fichier poi.txt auraient 
plus de mal à le trouver, mais une fois la bonne URL repérée ils 
obtiendraient toutes les mises à jour automatiquement.

Cette solution pourrait aussi être utilisée par les chaînes qui n'ont 
qu'un site pour tous leurs établissements. D'ailleurs les banques et 
supermarchés, par exemple, ont déjà tous une page par établissement. Il 
leur suffit donc d'ajouter une page au format poi.txt.

Une autre option serait de permettre le stockage des informations de 
plusieurs établissements dans un seul fichier poi.txt. Se pose alors le 
problème de l'identifiant de chaque site : adresse postale (avec les 
problèmes de majuscule / minuscule, accents, etc) plus nom, le SIRET 
(valable uniquement en France), etc.

Et pour ceux qui n'ont vraiment pas de site web, une association à but 
non lucratif pourrait monter un site web pour stocker ce type 
d'information, avec une URL par établissement. Là aussi il faudrait que 
chaque fichier poi.txt contienne des données permettant d'identifier 
l'établissement auquel il se rapporte. Quant aux droits d'accès, si un 
modèle où n'importe qui peut éditer les informations type wiki ne 
convient pas il sera temps de trouver d'autres solutions.


Comment utiliser ces données dans OpenStreetMap ?

Et bien à partir du moment où le champ website est positioné un outil 
type Osmose pourrait tester la présence du fichier poi.txt dans la 
racine du site et proposer l'intégration des données qu'il contient. 
Mais d'autres modèles sont aussi possibles : par exemple l'intégration 
automatique des données, un plugin proposant leur intégration dans Josm, 
ou même laisser cette intégration à d'autres outils comme Osmand ou 
Maps.me.

Lorsque le fichier poi.txt ne se trouve pas dans la racine du site, le 
contributeur pourrait à la place renseigner le champ poi_url dans 
OpenStreetMap afin que les outils sachent où récupérer cette 
information.


Pour le format des données il faut quelque chose de raisonablement 
simple à utiliser et extensible. J'aurais tendance à reprendre les 
champs déjà utilisés dans OpenStreetMap, mais à la limite le format 
importe peu du moment que les données sont là dans un format standard et 
utilisable par tous.


Bien sûr il reste plein de détails à régler. Mais cet email est déjà 
bien assez long.



-- 
Francois Gouget   http://fgouget.free.fr/
   A man can fail many times, but he isn't a failure
until he begins to blame somebody else.
   -- John Burroughs___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Mise à jour des POIs

2018-07-20 Thread PanierAvide 

Bonjour François,

En effet c'est une sacré problématique ! La solution est à mon avis 
plutôt pédagogique et sociale que vraiment technique : au final la norme 
et les outils à mettre en place seront relativement "simples" face au 
défi qu'est de mettre en relation l'ensemble des acteurs qui gèrent ce 
type de données.


On peut se demander : si un commerçant, boulanger, artisan... doit 
renseigner une seule fois les infos le concernant, où le fera t'il ?

- Sur sa page personnelle s'il en a une
- Auprès d'un annuaire type Google, Pages Jaunes...
- Auprès de l'administration (base SIRENE) ou chambres de commerce

Dans le premier cas, adapter les CMS ou définir un standard type 
robots.txt suffira pour résoudre le problème. Dans le deuxième cas, ça 
nécessite que les acteurs en question partagent leurs données, et c'est 
pas gagné. Troisième cas c'est déjà possible, mais la fraîcheur des 
infos pêche parfois. Mais le côté obligation déclarative auprès de 
l'administration permet de s'assurer que les données seront au moins 
saisies une fois, et ce sont des acteurs qui n'ont pas un intérêt 
financier fort comme les sociétés précédentes. C'est peut-être une bonne 
idée que de réunir ces acteurs pour lancer la BACON (Base Commerces 
Nationale) :-)


Cordialement,

Adrien.


Le 20/07/2018 à 10:10, Francois Gouget a écrit :

On peut mettre pas mal d'information sur les commerces et restaurants
dans OpenStreetMap. Avoir ces informations à disposition hors ligne sur
un téléphone est très pratique. Mais des informations comme les horaires
d'ouverture ont pas mal tendance à changer, notamment pour les congés
annuels, et sont donc difficiles à maintenir à jour.

En plus, plusieurs sites s'occupent de tenir ces informations à jour :
Google Maps bien sûr, mais aussi les Pages Jaunes, Le Figaro, et pas mal
d'autres sites spécialisés comme la Fourchette, Travelocity, etc.

Pour un commerçant aller mettre tous ces sites à jour n'a aucun sens. Et
c'est aussi un gros gaspi que chaque site envoie du monde pour aller
collecter les horaires.

Ce qu'il faudrait c'est que les commerces disposent d'une méthode
standard pour publier leurs horaires et autres informations (du type de
cuisine à la présence d'un distributeur de billet), avec une licence qui
autorise la réutlisation par tous les acteurs (de Google à
OpenStreetMap).

Il y a un modèle qui serait simple : robots.txt. Ce fichier est
standardisé et indique à n'importe quel moteur de recherche, aussi bien
Google que Bing, quelles pages ne doivent pas être indexées.

Donc on pourrait définir un standard où il suffirait à tout commerce,
restaurant ou artisan ayant un site web de mettre un fichier poi.txt
dans la racine dudit site pour publier une bonne fois pour toutes les
informations utiles pour leur commerce, restaurant ou service.

Pour ceux qui n'ont pas leur propre site mais, par exemple, juste une
page FaceBook, ils pourraient mettre le fichier poi.txt quelque part
dans leur espace. Les services utilisant le fichier poi.txt auraient
plus de mal à le trouver, mais une fois la bonne URL repérée ils
obtiendraient toutes les mises à jour automatiquement.

Cette solution pourrait aussi être utilisée par les chaînes qui n'ont
qu'un site pour tous leurs établissements. D'ailleurs les banques et
supermarchés, par exemple, ont déjà tous une page par établissement. Il
leur suffit donc d'ajouter une page au format poi.txt.

Une autre option serait de permettre le stockage des informations de
plusieurs établissements dans un seul fichier poi.txt. Se pose alors le
problème de l'identifiant de chaque site : adresse postale (avec les
problèmes de majuscule / minuscule, accents, etc) plus nom, le SIRET
(valable uniquement en France), etc.

Et pour ceux qui n'ont vraiment pas de site web, une association à but
non lucratif pourrait monter un site web pour stocker ce type
d'information, avec une URL par établissement. Là aussi il faudrait que
chaque fichier poi.txt contienne des données permettant d'identifier
l'établissement auquel il se rapporte. Quant aux droits d'accès, si un
modèle où n'importe qui peut éditer les informations type wiki ne
convient pas il sera temps de trouver d'autres solutions.


Comment utiliser ces données dans OpenStreetMap ?

Et bien à partir du moment où le champ website est positioné un outil
type Osmose pourrait tester la présence du fichier poi.txt dans la
racine du site et proposer l'intégration des données qu'il contient.
Mais d'autres modèles sont aussi possibles : par exemple l'intégration
automatique des données, un plugin proposant leur intégration dans Josm,
ou même laisser cette intégration à d'autres outils comme Osmand ou
Maps.me.

Lorsque le fichier poi.txt ne se trouve pas dans la racine du site, le
contributeur pourrait à la place renseigner le champ poi_url dans
OpenStreetMap afin que les outils sachent où récupérer cette
information.


Pour le format des données il faut quelque chose de raisonablement
simple à utiliser et extensible. J'aur

Re: [OSM-talk-fr] Mise à jour des POIs

2018-07-20 Thread Rpnpif 
Bonjour,

Le 20 juillet 2018, Francois Gouget a écrit :

> On peut mettre pas mal d'information sur les commerces et restaurants 
> dans OpenStreetMap. Avoir ces informations à disposition hors ligne sur 
> un téléphone est très pratique. Mais des informations comme les horaires 
> d'ouverture ont pas mal tendance à changer, notamment pour les congés 
> annuels, et sont donc difficiles à maintenir à jour.
> ...
> Ce qu'il faudrait c'est que les commerces disposent d'une méthode 
> standard pour publier leurs horaires et autres informations ...

Bonne idée.

Le format des horaires dans OSM permet déjà les exceptions des congés
d'été et cela marche bien. On peut y mettre des horaires très
compliqués sur l'année. Il faudrait améliorer l'interface d'iDE pour
faciliter leur entrée, en commençant par traduire les noms des jours et
des mois.

Même un fichier texte sur le site d'un artisan peut-être difficile à
gérer pour un non-informaticien. L'idéal serait un appel à une API
distante appelable en AJAX ou similaire sur un site communautaire hors
GAFAM et affichable sur le site de l'artisan (ou autre entreprise).

Beaucoup plus simple : faire de la propagande pour que ces entreprises
entrent elle-même leurs horaires sur une page OSM réservée à ça avec une
interface à la yohours mais en plus puissant pour permettre d'entrer
ces fameuses périodes d'horaires d'été.

Ya plus qu'à trouver les développeurs libres pour coder ça ;).

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Mise à jour des POIs

2018-07-20 Thread David Crochet 

Bonjour


Le 20/07/2018 à 10:10, Francois Gouget a écrit :

Donc on pourrait définir un standard où il suffirait à tout commerce,
restaurant ou artisan ayant un site web de mettre un fichier poi.txt
dans la racine dudit site pour publier une bonne fois pour toutes les
informations utiles pour leur commerce, restaurant ou service.


Donc tu pars du principe que :

- Le commerçant a un site web
- Qu'il ne passe pas par un prestataire de service
- Donc il a reçu les code pour y accéder
- le commerçant a accès à la racine de son site
- Les droits lui assure un dépôt possible d'un fichier
- Qu'il doit se souvenir de mettre à jour ce fichier lorsqu'il change 
ses horaire
- qu'en cas de changement de propriétaire, il y ai transfert de 
l'information existante, mais ce point est exceptionnel dans le temps 
d'activité de l'entreprise


Je crois que c'est pas gagné

Cordialement
--
David Crochet


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

[OSM-talk-fr] Groix n'est pas en Bretagne !

2018-07-20 Thread erwan salomon 
suite à une petite recherche overpass j’ai la surprise de découvrir que Groix 
(mais également Belle-Île) n’est pas en Bretagne :
http://overpass-turbo.eu/s/AqN 

ces îles sont par contre en Morbihan :
http://overpass-turbo.eu/s/AqL 

pourtant la ligne de côte de Groix est bien dans les relations Bretagne et 
Morbihan en tant que outer :
https://www.openstreetmap.org/way/176427684#map=19/47.64270/-3.43307 


n’étant déjà pas convaincu/convaincant sur le sujet hautement idéologique de 
Nantes en Bretagne, je passe la main pour résoudre cette nouvelle discorde 
idéologique/technique ;-)

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

[OSM-talk-fr] Contact OSM - FIG DE ST DIE SALON GEOMATIQUE

2018-07-20 Thread Vincent Bergeot 

Bonjour,

nous avons eu la sollicitation ci-dessous :

"Le 13/07/2018, 11:11 Elise Ladurelle  a 
écrit:

Bonjour à tous!
je me permets de vous contacter dans le cadre de l'appui apporté par 
AFIGEO au montage du Salon de la géomatique à Victoria KAPPS désormais 
chargée de coordonnée le FIG de Saint Dié des Vosges 
http://fig.saint-die-des-vosges.fr/ - 5-7 oct 2018
Il nous semblerait intéressant qu'OSM puisse être présent sur ce salon 
et pourquoi pas animer une petite séance découverte OSM en intérieur ou 
en extérieur à destination d'un public plutôt très variés (du plus 
professionnels au plus amateurs...ou des scolaires...)


Je vous laisse donc confirmer rapidement votre intérêt / disponibilité, 
côté AFIGEO nous pourrions vous proposer d'intégrer le cycle de mini 
conf qui se tient dans le salon (20 à 30 min d'intervention).


Bien cordialement et bon été à tous.

Elise LADURELLE-TIKRY
AFIGEO – 01 43 98 82 62 – www.afigeo.asso.fr "

Si vous êtes intéressé(-e)s, vous le dites, vous nous tenez au courant !

à plus

--
Vincent Bergeot


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

Re: [OSM-talk-fr] Mission sur les données géographiques souveraines...

2018-07-20 Thread Vincent Privat 
Le rapport est dispo:
https://www.ecologique-solidaire.gouv.fr/sites/default/files/Rapport_DonneesGeographiquesSouveraines.pdf

Le 24 mars 2018 à 12:02, Rpnpif  a écrit :

> Le 22 mars 2018, Vincent Privat a écrit :
>
> > Je comprends le questionnaire comme devant aboutir à une réforme profonde
> > de l'IGN.
> > Pour moi l'institut devrait être financé à 100% avec des fonds publics (à
> > voir si c'est que l’État ou aussi les collectivités) et en échange mettre
> > en ligne tout son contenu (nouvellement produit, mais aussi les archives)
> > en licence libre (les seules exceptions à cette règle étant ce qui relève
> > du secret défense).
> > Pas encore eu le temps de tout lire :)
>
> Tout à fait d'accord.
>
> La donnée géographique est sensible. Un financement privé pourrait
> influencé le choix du type et la valeur de cette donnée en fonction de
> l'intérêt exclusif du financeur sans moyen d'intervention des
> « clients ». Cela s'est déjà vu ailleurs.
>
> Un financement public donne la capacité (théorique) au citoyen
> d'intervenir sur les choix. La mise à disposition de tous permet un
> contrôle direct de tout un chacun.
>
> Je suis aussi très favorable aux échanges bidirectionnels entre l'IGN et
> OSM.
>
> OSM est complémentaire de l'IGN. L'IGN est plus en soutien des
> pouvoirs publics, OSM met les données SIG dans les mains de tous.
>
> --
> Alain Rpnpif
>
> ___
> 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

[OSM-talk-fr] RB94 a encore frappé

2018-07-20 Thread Antoine Riche 

Bonjour,

Dans le cadre du projet #CartoVeloIDF [1] je tombe sur le changeset 
60383675 [2] de RB94, qui pose plusieurs problèmes (suppression de la 
rue Camille Desmoulins à Cachan pour la remplacer par 3 ways parallèles, 
suppression de footways le long de la Rue Marx Dormoy qui supprime des 
continuités piétonnes, etc.). J'ai laissé un commentaire sur le 
changeset [3], voyons s'il répond.


Mon souci est que j'ai tenté un revert, et comme certains éléments ont 
été changés depuis cela crée des conflits. J'ai bien tenté de résoudre 
tous les conflits, mais ça ne marche pas, mon changeset est rejeté. J'ai 
également tenté de supprimer un changeset plus récent (60737340) [4], du 
même RB94 et qui n'est pas mieux, nouvel échec.


Si vous avez une méthodologie pour défaire ce sac de nœuds je suis 
preneur...


[1] 
https://wiki.openstreetmap.org/wiki/WikiProject_France/Vélo_en_Île-de-France

[2] https://osmlab.github.io/changeset-map/#60383675
[3] https://www.openstreetmap.org/changeset/60383675
[4] https://osmlab.github.io/changeset-map/#60737340

Antoine.




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OKFILTER] [Tagging] Public Transport v3 — starting RFC

2018-07-20 Thread Johnparis 
This is a very long and complex proposal, so it will take me a while to
digest and respond. I am also alerting the transport mailing lists in
English and French. I trust the RFC will be open for at least for a couple
of months.

Cette proposition (en anglais) est très longue et complexe, il me faudra
donc du temps pour digérer et répondre. J'alert également les listes de
diffusion de transport en anglais et en français. J'espère que le RFC sera
ouvert au moins pour quelques mois.

John

On Fri, Jul 20, 2018 at 3:48 PM, Ilya Zverev  wrote:

> Hi folks,
>
> As you might've noticed, in the past year there has been growing
> discomfort with the current Public Transport tagging schema. Of course, it
> brought order to our route relations, but also introduced a lot of
> redundant concepts. We've seen a couple proposals aiming to fix some of
> issues, but nothing stuck.
>
> Please consider this new revision for the PT schema, which addresses most
> of the issues, while keeping as backward compatible as possible:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_v3
>
> I'd be happy to hear any suggestions. Next week, I'll be presenting it,
> among other things, during my talk "What's up with the public transport" at
> the State of the Map conference.
>
> Thanks,
> Ilya
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OSM transport] Public Transport v3 — starting RFC

2018-07-20 Thread marc marc 
Je l'ai lu en long et en large, voici mon résumé perso :
ce n'est pas une PTv3, c'est une PTv1bis
aka il propose la suppression intégrale de tous la PTv2 (hormis
les stop_area ou à peu près) sans résoudre aucune des raisons qui
ont conduit à la création de la PTv2 (aka uniformiser les tags entre
les différents moyens de transport et avoir, de manière optionnelle, 
sous un même public_transport l'ensemble des objet tant ceux concernant 
les véhicules "stop_position" que ceux concernant les passagers 
"plateforme", ceci afin qu'un app de transport puisse gérer tous les 
modes au lieu d'avoir à écrire du code/requête pour chaque mode)
il repropose aussi l'intégralité de ces 3 propositions précédentes
qui ont été rejetée lors du vote.
Je n'arrive pas à me faire un avis s'il n'a pas compris les raisons
des rejets précédents ou s'il est borné et ferra x tentatives
sans rien changer réellement.

Je ferrais un commentaire dans les jours à venir sur le wiki pour voir 
si quelque chose d'utile peux en sortir, mais à voir son manque de 
compromis dans ses propositions précédentes, je crains qu'il n'y a rien 
à faire, hormis peut-être à récupérer ce qui peux l'être pour en faire 
une autre proposition ultra light sur un point ou l'autre, histoire 
d'avancer sur ce qui n'est pas conflictuel.
Je pense par exemple à la clarification du stop_area, certains le voyen 
comme un moyen de grouper un arrêt dans chaque sens (le stop_position et 
la plateforme) d'autre comme un moyen de grouper les différents arrêts 
formant un arrêt logique (ceux dans chaque sens dans un seul group)

Le 20. 07. 18 à 21:05, Johnparis a écrit :
> This is a very long and complex proposal, so it will take me a while to 
> digest and respond. I am also alerting the transport mailing lists in 
> English and French. I trust the RFC will be open for at least for a 
> couple of months.
> 
> Cette proposition (en anglais) est très longue et complexe, il me faudra 
> donc du temps pour digérer et répondre. J'alert également les listes de 
> diffusion de transport en anglais et en français. J'espère que le RFC 
> sera ouvert au moins pour quelques mois.
> 
> John
> 
> On Fri, Jul 20, 2018 at 3:48 PM, Ilya Zverev  > wrote:
> 
> Hi folks,
> 
> As you might've noticed, in the past year there has been growing
> discomfort with the current Public Transport tagging schema. Of
> course, it brought order to our route relations, but also introduced
> a lot of redundant concepts. We've seen a couple proposals aiming to
> fix some of issues, but nothing stuck.
> 
> Please consider this new revision for the PT schema, which addresses
> most of the issues, while keeping as backward compatible as possible:
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_v3
> 
> 
> 
> I'd be happy to hear any suggestions. Next week, I'll be presenting
> it, among other things, during my talk "What's up with the public
> transport" at the State of the Map conference.
> 
> Thanks,
> Ilya
> ___
> Tagging mailing list
> tagg...@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> 

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

Re: [OSM-talk-fr] Groix n'est pas en Bretagne !

2018-07-20 Thread osm . sanspourriel 
C'est un bogue. Comme à la base c'est Nominatim qui sert on pourrait 
penser que "groix, bretagne 
" 
ne marcherait pas, pourtant si.


On sait que les polygones sont approximatifs mais je les croyais 
généreux. Donc ce serait à chercher du côté des geocodeArea.


Pour ta seconde requête (alors que Morbihan marche) :

Ne trouve pas de lieu avec le nom suivant :

/morbihan/

Jean-Yvon

N. B. : pour les Pétainistes, Nantes n'est pas en Bretagne. Je ne suis 
pas Pétainiste. CQFD ;-)





Le 20/07/2018 à 11:17, erwan salomon - r...@gmx.fr a écrit :
suite à une petite recherche overpass j’ai la surprise de découvrir 
que Groix (mais également Belle-Île) n’est pas en Bretagne :

http://overpass-turbo.eu/s/AqN

ces îles sont par contre en Morbihan :
http://overpass-turbo.eu/s/AqL

pourtant la ligne de côte de Groix est bien dans les relations 
Bretagne et Morbihan en tant que outer :

https://www.openstreetmap.org/way/176427684#map=19/47.64270/-3.43307

n’étant déjà pas convaincu/convaincant sur le sujet hautement 
idéologique de Nantes en Bretagne, je passe la main pour résoudre 
cette nouvelle discorde idéologique/technique ;-)


[glyo]


___
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