date:20170721

Bonjour Jean-Yvon,


Le 21 juillet 2017 à 09:38,  a écrit :

> Pas complètement d'accord ou je n'ai pas compris ce que tu entends par
> tampon.
>
> Car Jungle Bus est dans l'édition de données.
>
> Si tu ajoute des arrêts mais ne les vois pas, c'est gênant. Déception du
> contributeur (ai-je bien tagué ?) et risque de double contribution.
>
Puisqu'on maitrise le tampon, il faut le mettre à jour au rythme des
éditions.
Ensuite, soit on fait un synchro assez poussée avec l'overpass, ou alors on
le flush carrément en réimportant en prenant pour principe que tout ce qui
est dans la base monde est l'unique vérité toutes les x heures.

C'est aussi ce qui avait été évoqué pour mapcontrib (en ayant le beau rôle
du yakafokon pour ma part)

De toute façons il faut trouver des solutions, toutes les applis ne peuvent
pas reposer que sur les instances publiques de l'overpass
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Quand on commence à avoir un usage critique d'une API pour un projet 
donné, il faut devenir autonome si on le peut vis à vis de cette API...


Si une appli dépend:

1) d'overpass pour chercher des données dans une base OSM

2) de fond de cartes

3) de l'API OSM pour de l'édition

elle peut se rendre autonome sur:
- le 1 en déployant sa propre instance overpass,
- le 2 en produisant son propre rendu de fond
- mais elle ne pourra pas devenir 100% autonome sur l'API d'édition qui 
elle est unique... sauf à mettre en place tout un mécanisme assez 
complexe de tampon d'édition (ce que fait wheelmap il me semble).



Pour mémoire, OSM-FR est à la recherche d'un admin pour maintenir son 
instance overpass. Les outils de haute dispo ne peuvent de toute façon 
fonctionner que si il y a des instances derrière qui tournent et sont 
donc administrées pour être opérationnelle et à jour...


Overpass est un peu "touchy" et le déploiement d'instance un peu lourd 
ce qui explique pourquoi il n'y en a pas plus de déployées.


Autre solution dans le cas de jungle-bus ou autres projets de ce type, 
s'appuyer sur autre chose qu'overpass, ou alors une instance où l'on a 
filtré uniquement le type d'objets utiles pour son projet. Ceci rend 
moins lourde la config nécessaire pour l'instance... par exemple si les 
bâtiments ne sont pas utiles, ça fait un sacré volume de données en 
moins à garder !
Le confort d'overpass c'est son côté universel à l'usage, mais c'est ce 
qui explique aussi sa lourdeur en déploiement.



Le 21/07/2017 à 10:05, François Lacombe a écrit :

Bonjour Jean-Yvon,


Le 21 juillet 2017 à 09:38, > a écrit :


Pas complètement d'accord ou je n'ai pas compris ce que tu entends
par tampon.

Car Jungle Bus est dans l'édition de données.

Si tu ajoute des arrêts mais ne les vois pas, c'est gênant.
Déception du contributeur (ai-je bien tagué ?) et risque de double
contribution.

Puisqu'on maitrise le tampon, il faut le mettre à jour au rythme des 
éditions.
Ensuite, soit on fait un synchro assez poussée avec l'overpass, ou 
alors on le flush carrément en réimportant en prenant pour principe 
que tout ce qui est dans la base monde est l'unique vérité toutes les 
x heures.


C'est aussi ce qui avait été évoqué pour mapcontrib (en ayant le beau 
rôle du yakafokon pour ma part)


De toute façons il faut trouver des solutions, toutes les applis ne 
peuvent pas reposer que sur les instances publiques de l'overpass




___
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] Sécuriser Overpass API : quelles solutions ?

Comment fonctionne un serveur overpass ? il a
- une copie locale de la base mondiale
- un moyen pour la garder à jour (par ex chaque minute via un diff)

Si Jungle bus avait sa base locale contenant toutes infos couramment 
utilisée par cet app (plateorm, bus_stop, stop_area, route=bus),
Jungle bus pourrait interroger cette overpass "privé" au lieu d'un 
overpass "public". Cette copie locale serrait très petite en
taille vu qu'il y a moins de 2 millions de ces 4 tag
La maj de cette copie serrait très petite aussi vu qu'un arrêt de bus ne 
change pas souvent.

La seule chose qui reste à créer c'est un "diff" non pas mondial ou 
géographique comme cela existe déjà mais sur base d'un nombre limité 
d'objet (par exemple plateorm+bus_stop+stop_area+route=bus)

Quand au délais de maj, il existe sur tous les serveurs.
si tu interroges l'overpass allemand, il a une minute de décalage.
La copie local aurait le même genre de lag.
Cela n’empêche en rien de voir le résultat de ton édition.
Des app comme Go Map conservent une copie de ce que tu as envoyé
Le seul effet réel est que si tu as 2 smartphones,
les modifs de l'un mettront une minute pour être visible sur l'autre.
C'est le cas pour d'autres app, cela me semble acceptable.

Le 21. 07. 17 à 09:38, osm.sanspourr...@spamgourmet.com a écrit :
> Pas complètement d'accord ou je n'ai pas compris ce que tu entends par 
> tampon.
> 
> Car Jungle Bus est dans l'édition de données.
> 
> Si tu ajoute des arrêts mais ne les vois pas, c'est gênant. Déception du 
> contributeur (ai-je bien tagué ?) et risque de double contribution.
> 
> Tu veux dire qu'on aura des données actuelles mais par forcément tout de 
> suite ?
> 
> Par contre en consultation, pas de soucis à ne pas avoir la toute 
> dernière version.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Le 21. 07. 17 à 10:35, Christian Quest a écrit :
> OSM-FR est à la recherche d'un admin pour maintenir son instance overpass.
J'ai lu la doc d'install hier soir.
L'installation a l'air assez documentée.
Je vais tester en local dans les jours à venir.

Mais la version osm-fr était-elle standard ?
A lire le wiki, j'ai l'impression que l'instance osm-fr a une 
amélioration pour permettre de s'en servir comme proxy d'édition.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagger un bazar d'été, qui vend des articles de plage, des jouets...

2017-07-21 Thread osm . sanspourriel


Le 18/07/2017 à 17:26, Philippe Verdy - verd...@wanadoo.fr a écrit :

Je ne pense pas qu'il s'agisse de taguer les plages elles-mêmes (leur 
polygone ou multipolygone) mais juste l'échoppe elle-même

Ne pas oublier de lire les émoticônes ! ;-)
Et je ne pensais pas que le magasin était sur la plage mais dans les 
alentours.


Dans les environs des plages il me semble plus utile d'indiquer les 
stations SNSM/CRS FR:Tag:emergency=water_rescue_station__ 
__


Ça ne veut pas dire qu'il est inutile de cartographier un magasin 
d'articles de plages mais certains utilisateurs du magasin pourraient 
avoir besoin des infos suivantes.
Une idée pour la carto d'août ? Là je suis le yakafocon, je n'aurais pas 
beaucoup de temps.


tour de emergency 
=lifeguard_tower 
 
pour les tour de surveillance.


emergency=life_ring 
 pour les 
bouées de sauvetage.
leisure=swimming_area 
 
pour les zones de baignade surveillée


 * access =*
 * name =*
 * supervised
   =yes/interval si
   il y a une surveillance.

Je pense qu'il serait plus utile d'indiquer les zones dangereuses 
(baïnes, courants violents) voir les interdictions mais je ne vois pas 
comment le cartographier.


Il existe aussi encore des téléphones d'urgence dans certains endroits :

emergency= phone


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

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?


Le 21/07/2017 à 10:48, marc marc a écrit :


Comment fonctionne un serveur overpass ? il a
- une copie locale de la base mondiale
- un moyen pour la garder à jour (par ex chaque minute via un diff)


Oui, dans les grandes lignes c'est ça, la particularité c'est que la 
base a une structure propre à overpass et a été spécialement conçue pour 
l'organisation des données OSM. C'est ça qui fait qu'overpass est très 
performant car spécialement conçu pour cet unique usage.
Il n'y a pas de postgres ou autre utilisé (sauf, il me semble pour les 
"area").



Si Jungle bus avait sa base locale contenant toutes infos couramment
utilisée par cet app (plateorm, bus_stop, stop_area, route=bus),
Jungle bus pourrait interroger cette overpass "privé" au lieu d'un
overpass "public". Cette copie locale serrait très petite en
taille vu qu'il y a moins de 2 millions de ces 4 tag
La maj de cette copie serrait très petite aussi vu qu'un arrêt de bus ne
change pas souvent.


Voilà... on ne traite qu'un tout petit sous ensemble des données OSM et 
ça allège du coup beaucoup de choses !



La seule chose qui reste à créer c'est un "diff" non pas mondial ou
géographique comme cela existe déjà mais sur base d'un nombre limité
d'objet (par exemple plateorm+bus_stop+stop_area+route=bus)


osmfilter / osmconvert ou osmosis peuvent servir à ça en amont pour 
filtrer les diff avant de les injecter dans l'update d'overpass afin de 
ne garder que ce qui est utile.



Quand au délais de maj, il existe sur tous les serveurs.
si tu interroges l'overpass allemand, il a une minute de décalage.
La copie local aurait le même genre de lag.
Cela n’empêche en rien de voir le résultat de ton édition.
Des app comme Go Map conservent une copie de ce que tu as envoyé
Le seul effet réel est que si tu as 2 smartphones,
les modifs de l'un mettront une minute pour être visible sur l'autre.
C'est le cas pour d'autres app, cela me semble acceptable.


En général ça ne pose pas de problème ou plutôt ça en posera un quand il 
y aura des millions de contributeurs Jungle Bus qui éditerons tous 
ensemble... ce que j'appelle un "problème de riche".



J'ai lu la doc d'install hier soir.
L'installation a l'air assez documentée.
Je vais tester en local dans les jours à venir.


Teste sur un extrait, pas sur le planet... et SSD (rapide) indispensable


Mais la version osm-fr était-elle standard ?
A lire le wiki, j'ai l'impression que l'instance osm-fr a une
amélioration pour permettre de s'en servir comme proxy d'édition.


C'est un petit script au dessus d'overpass (et indépendant) qui permet 
de l'utiliser en lieu en place de l'API d'édition.


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] orthophoto HR 2016 de normandie




Le 21/07/2017 à 01:31, osm.sanspourr...@spamgourmet.com a écrit :
D'accord avec les remarques de Philippe mais il y a des groupement 
régionaux (CREA, Geobretagne, etc...) qui ont déjà les infra qui vont 
bien (pour geobretagne c'est georchestra basé sur GeoServer et 
GeoWebCache).


C'est pour ça que je suggérais de vérifier si ces orthos ne sont pas 
dispo en flux (WMTS, TMS, voire WMS).


C'est à base de logiciels libres et Geobretagne a fait des petits. Il 
n'y a pas une agence en Normandie ?

Car c'est à mon avis à eux de proposer le service.
Pas aux GAFA



C'est sûr !

Violaine avait eu ce besoin pour un Mapathon (une imagerie aérienne à 
mettre à dispo des éditeurs style JOSM) et elle l'a fait en quelques 
heures (une, deux ?), en tous cas avant le début du Mapathon mais pas 
sans stress. Ça pourrait être automatisé.

Fil de discussion "Charger imagerie en local sur JOSM".
Peut-être qu'elle a pris le temps de faire un bon doc.

Ça permet de récupérer du TMS, notamment en 512x512 pour JOSM.
Le faire chez soi, ça le fait.



Sur une petite dalle ça se fait, sur une couverture de la moitié de la 
France c'est pas tout à fait la même histoire ;)


A titre d'info, l'IGN diffuse ces orthos opendata par dalles de 5km x 
5km, soit des fichiers de 625 millions de pixels au format JPEG2000.
Pour décompresser un seul fichier avec les librairies de base 
(openjpeg), ça a pris 15h sur une machine pas trop ridicule (un R710 
équivalent à nos serveurs Free)... et il y en a 350 pour couvrir un 
département (c'était l'Allier).
Il faut passer par des librairies propriétaires ou une version 
s'appuyant sur un GPU pour descendre à des temps de traitement 
raisonnables... c'est ça que j'explore.
Le JPEG2000 n'est pas la meilleure idée qui soit, le fichier retraité en 
TIFF tuilé compressé JPEG fait 100Mo à comparer aux 90Mo pour le 
JPEG2000 téléchargé, par contre il est directement exploitable.



Je dis une à deux heures, mais parce que j'avais résolu les problèmes 
avant : je savais que faire.


On pourrait imaginer un proxy OSM qui suivant la tuile choisie irait 
la demander à Geobretagne par exemple si c'est en Bretagne mais au 
CREA si c'est en Auvergne.
Avec comme pour le serveur TMS cadastre le problème des zones 
frontalières.
Car il est difficile de savoir s'il vaut mieux mettons  la tuile du 
Mont Saint-Michel de la photo de la Bretagne ou celle de la Normandie.
Je suis à proximité d'une frontière départementale et Geobretagne 
avait choisi la photo provenant de l'imagerie de mon département.
Assez logique pourtant la qualité était moins bonne que celle du 
département voisin.
Le problème à été résolu : nouvelles photos formant un continuum de 
meilleure qualité.


Marc, le problème de :
/cela permet d'estimer la surface qui pourrait être traité on la met 
dispo à usage interne pendant 1 mois. le mois d'après, on passe à la 
zone suivante


/C'est que tu imposes la zone à traiter.
Or si une zone est mal faite, c'est cette zone là que l'utilisateur 
veut modifier, indépendamment de la zone actuellement en ligne.
Ce que tu proposes c'est un peu ce que Christian fait avec 
OpenSolarMap : si on veut globalement améliorer un critère, ça marche.




L'usage de l'ortho actuel c'est un fond qui fournit une info en 
complément d'autres sources. Je ne pense pas que l'usage qui en est fait 
est de "traiter" systématiquement une surface bien définie (1km2 voire 
moins) et encore moins de traiter sur toutes les thématiques...


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] steps:contrast <> step:contrast

Suite aux différentes discussions, personne n'a émis d'objection.
La seule utilisation éventuelle est une alerte qualité chez transilien, 
Adrien les prévient dans le cadre cartomobilité.

Je vous invite donc à migrer vos tags steps:contrast en step:contrast
liste de mappeur concerné :
   1 arxit-france
  13 cquest
   2 dsidemoon22
   1 Emmaschuschu
   1 GerdP
  12 Jijais
   3 JLZIMMERMANN
   1 josmougn
   2 Lekt
   1 Manu1400
   8 Markus59
   5 mygeomatic
   5 naomap
  17 overflorian
  31 PanierAvide
   2 Samusz
  12 StephaneP
   1 Syl
   7 transilien_cartocite
   1 unbreton
   1 yargil
  15 Ymith0936

Suivra : une page wiki en status draft pour détailler l'existant
ou en status "in use" ?
si quelqu'un connaît les critères pour les différents status, qu'il 
n'hésites pas à l'expliquer.

Merci,
Marc


Le 18. 07. 17 à 23:23, Marc M. a écrit :
> Bonsoir,
> 
> En recherchant les tag pour un escalier, j'ai découvert que 
> contrairement aux autres tags, on utilisait steps:contrast
> au pluriel. il y a évidement déjà un cas du tag au singulier
> ces tags semblent provenir :
> - du hackathon des gares rer/sncf de Paris (en 2013)
> - de Rennes
> 
> J'en ai discuté avec l'auteur de la page de résumé
> http://wiki.openstreetmap.org/wiki/FR:Handicaps/R%C3%A9f%C3%A9rentiel
> 
> Dans le but d'harmoniser tout cela,
> - est-ce que l'un d'entre-vous à un outil qui les utilise ? éditeur, 
> logiciel de routing, logiciel d'assistance, carte à thème, peu importe
> - pour/contre cette harmonisation ?
> 
> PS: quasi tout les tags en step auraient besoin d'une harmonisation, 
> mais je préfère diviser en petites étapes faciles :)
> 
> Cordialement,
> Marc

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

Re: [OSM-talk-fr] steps:contrast <> step:contrast

2017-07-21 Thread PanierAvide


J'ai fait la conversion en ce qui me concerne ;-)

Pour le statut de la page, soit "In use" soit "Draft". De ce que j'ai 
compris, draft implique normalement de passer par le processus de vote 
un jour, alors que "in use" fait juste le constat de comment est utilisé 
un tag lorsque son usage est courant, mais pas assez pour être un 
standard "de facto". Il y a moins de risques de se prendre une remarque 
sur le volume en mettant en "draft" ceci dit. L'important est que son 
usage soit documenté de manière visible, avec une page directement 
accessible.


Cordialement,

Adrien.


Le 21/07/2017 à 13:50, marc marc a écrit :

Suite aux différentes discussions, personne n'a émis d'objection.
La seule utilisation éventuelle est une alerte qualité chez transilien,
Adrien les prévient dans le cadre cartomobilité.

Je vous invite donc à migrer vos tags steps:contrast en step:contrast
liste de mappeur concerné :
1 arxit-france
   13 cquest
2 dsidemoon22
1 Emmaschuschu
1 GerdP
   12 Jijais
3 JLZIMMERMANN
1 josmougn
2 Lekt
1 Manu1400
8 Markus59
5 mygeomatic
5 naomap
   17 overflorian
   31 PanierAvide
2 Samusz
   12 StephaneP
1 Syl
7 transilien_cartocite
1 unbreton
1 yargil
   15 Ymith0936

Suivra : une page wiki en status draft pour détailler l'existant
ou en status "in use" ?
si quelqu'un connaît les critères pour les différents status, qu'il
n'hésites pas à l'expliquer.

Merci,
Marc


Le 18. 07. 17 à 23:23, Marc M. a écrit :

Bonsoir,

En recherchant les tag pour un escalier, j'ai découvert que
contrairement aux autres tags, on utilisait steps:contrast
au pluriel. il y a évidement déjà un cas du tag au singulier
ces tags semblent provenir :
- du hackathon des gares rer/sncf de Paris (en 2013)
- de Rennes

J'en ai discuté avec l'auteur de la page de résumé
http://wiki.openstreetmap.org/wiki/FR:Handicaps/R%C3%A9f%C3%A9rentiel

Dans le but d'harmoniser tout cela,
- est-ce que l'un d'entre-vous à un outil qui les utilise ? éditeur,
logiciel de routing, logiciel d'assistance, carte à thème, peu importe
- pour/contre cette harmonisation ?

PS: quasi tout les tags en step auraient besoin d'une harmonisation,
mais je préfère diviser en petites étapes faciles :)

Cordialement,
Marc

___
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] steps:contrast <> step:contrast

2017-07-21 Thread Antoine Riche

Très bien pour la modification du tag. Par contre pour la modification 
je suggère qu'une seule et même personne le fasse en partant d'une 
requête Overpass (http://overpass-turbo.eu/s/qwb). Ce sera plus efficace 
et évitera les erreurs. Je peux le faire mais à condition que personne 
n'édite en même temps pour éviter les conflits !


Pour info, si la liste ci-dessous a été créée avec Overpass il s'agit 
des dernières personnes à avoir modifié un élément portant le tag en 
question, et non les personnes ayant ajouté le tag (personnellement je 
le découvre !)


Antoine.

Le 21/07/2017 à 13:50, marc marc a écrit :

Suite aux différentes discussions, personne n'a émis d'objection.
La seule utilisation éventuelle est une alerte qualité chez transilien,
Adrien les prévient dans le cadre cartomobilité.

Je vous invite donc à migrer vos tags steps:contrast en step:contrast
liste de mappeur concerné :
1 arxit-france
   13 cquest
2 dsidemoon22
1 Emmaschuschu
1 GerdP
   12 Jijais
3 JLZIMMERMANN
1 josmougn
2 Lekt
1 Manu1400
8 Markus59
5 mygeomatic
5 naomap
   17 overflorian
   31 PanierAvide
2 Samusz
   12 StephaneP
1 Syl
7 transilien_cartocite
1 unbreton
1 yargil
   15 Ymith0936

Suivra : une page wiki en status draft pour détailler l'existant
ou en status "in use" ?
si quelqu'un connaît les critères pour les différents status, qu'il
n'hésites pas à l'expliquer.

Merci,
Marc


Le 18. 07. 17 à 23:23, Marc M. a écrit :

Bonsoir,

En recherchant les tag pour un escalier, j'ai découvert que
contrairement aux autres tags, on utilisait steps:contrast
au pluriel. il y a évidement déjà un cas du tag au singulier
ces tags semblent provenir :
- du hackathon des gares rer/sncf de Paris (en 2013)
- de Rennes

J'en ai discuté avec l'auteur de la page de résumé
http://wiki.openstreetmap.org/wiki/FR:Handicaps/R%C3%A9f%C3%A9rentiel

Dans le but d'harmoniser tout cela,
- est-ce que l'un d'entre-vous à un outil qui les utilise ? éditeur,
logiciel de routing, logiciel d'assistance, carte à thème, peu importe
- pour/contre cette harmonisation ?

PS: quasi tout les tags en step auraient besoin d'une harmonisation,
mais je préfère diviser en petites étapes faciles :)

Cordialement,
Marc

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





---
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] Sécuriser Overpass API : quelles solutions ?

Sur le fond on est d'accord, il va falloir disposer de ressources locales
au projet pour ne plus dépendre d'OAPI.

Par contre, est-ce utile et justifié de monter une instance overpass en
ayant préalablement épuré le jeu de données à ce qui nous intéresse
uniquement ?
Remonter un backend conforme à l'API central pour l'édition, qui
dupliquerait le flux d'édition à la fois dans la base locale et sur OSM
d'une part et qui permettrait de charger ces données dans l'appli frontend
sur une bbox d'autre part ne requiert pas la puissance (et complexité
adjacente) d'overpass.

My 2 cents



*François Lacombe*

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

Le 21 juillet 2017 à 11:26, Christian Quest  a
écrit :

> Le 21/07/2017 à 10:48, marc marc a écrit :
>
> Comment fonctionne un serveur overpass ? il a
> - une copie locale de la base mondiale
> - un moyen pour la garder à jour (par ex chaque minute via un diff)
>
>
> Oui, dans les grandes lignes c'est ça, la particularité c'est que la base
> a une structure propre à overpass et a été spécialement conçue pour
> l'organisation des données OSM. C'est ça qui fait qu'overpass est très
> performant car spécialement conçu pour cet unique usage.
> Il n'y a pas de postgres ou autre utilisé (sauf, il me semble pour les
> "area").
>
> Si Jungle bus avait sa base locale contenant toutes infos couramment
> utilisée par cet app (plateorm, bus_stop, stop_area, route=bus),
> Jungle bus pourrait interroger cette overpass "privé" au lieu d'un
> overpass "public". Cette copie locale serrait très petite en
> taille vu qu'il y a moins de 2 millions de ces 4 tag
> La maj de cette copie serrait très petite aussi vu qu'un arrêt de bus ne
> change pas souvent.
>
>
> Voilà... on ne traite qu'un tout petit sous ensemble des données OSM et ça
> allège du coup beaucoup de choses !
>
> La seule chose qui reste à créer c'est un "diff" non pas mondial ou
> géographique comme cela existe déjà mais sur base d'un nombre limité
> d'objet (par exemple plateorm+bus_stop+stop_area+route=bus)
>
>
> osmfilter / osmconvert ou osmosis peuvent servir à ça en amont pour
> filtrer les diff avant de les injecter dans l'update d'overpass afin de ne
> garder que ce qui est utile.
>
> Quand au délais de maj, il existe sur tous les serveurs.
> si tu interroges l'overpass allemand, il a une minute de décalage.
> La copie local aurait le même genre de lag.
> Cela n’empêche en rien de voir le résultat de ton édition.
> Des app comme Go Map conservent une copie de ce que tu as envoyé
> Le seul effet réel est que si tu as 2 smartphones,
> les modifs de l'un mettront une minute pour être visible sur l'autre.
> C'est le cas pour d'autres app, cela me semble acceptable.
>
>
> En général ça ne pose pas de problème ou plutôt ça en posera un quand il y
> aura des millions de contributeurs Jungle Bus qui éditerons tous
> ensemble... ce que j'appelle un "problème de riche".
>
> J'ai lu la doc d'install hier soir.
> L'installation a l'air assez documentée.
> Je vais tester en local dans les jours à venir.
>
>
> Teste sur un extrait, pas sur le planet... et SSD (rapide) indispensable
>
> Mais la version osm-fr était-elle standard ?
> A lire le wiki, j'ai l'impression que l'instance osm-fr a une
> amélioration pour permettre de s'en servir comme proxy d'édition.
>
>
> C'est un petit script au dessus d'overpass (et indépendant) qui permet de
> l'utiliser en lieu en place de l'API d'édition.
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> 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] Sécuriser Overpass API : quelles solutions ?

2017-07-21 Thread Rodolphe Pelloux-Prayer

Bonjour,

> […]
>> J'ai lu la doc d'install hier soir.
>> L'installation a l'air assez documentée.
>> Je vais tester en local dans les jours à venir.
>
> Teste sur un extrait, pas sur le planet... et SSD (rapide) indispensable
>
>> Mais la version osm-fr était-elle standard ?
>> A lire le wiki, j'ai l'impression que l'instance osm-fr a une
>> amélioration pour permettre de s'en servir comme proxy d'édition.
>
> C'est un petit script au dessus d'overpass (et indépendant) qui permet
> de l'utiliser en lieu en place de l'API d'édition.

Pour info, j’ai commencé il y a quelque temps un rôle ansible [0] pour
déployer overpass-api sur l’infra osm.fr et il y a une vm en test à
l’adresse http://dev.api.openstreetmap.fr avec les données France.

Je manque un peu de temps pour finir de valider l’install mais
l’instance de dev doit être fonctionnelle (la plupart du temps !). Si
vous voulez tester, n’hésitez pas !

Rodolphe

[0] : https://github.com/osm-fr/ansible-scripts/pull/3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] steps:contrast <> step:contrast

Oui il est possible qu'une personne unique fasse toute les modifs en une fois.
Mais en proposant dans une première phase à chaque mappeur de modifier ses
propres contributions, je pensais que chacun peux ainsi s'assurer qu'il n'a pas
d'outil genre preset Josm à modifier et surtout être au courant pour la
prochaine contribution.
Cela évite aussi les susceptibilités :-)
J'y voyais aussi l'avantage que cela montre un projet collectif que' on ne
verrait pas si taginfo ne renseigne qu'un contributeur ayant fait la dernière
modifs.
J'y voyais aussi le dernier avantage de ne pas tomber dans la longue procédure
des massedit. Pour ce tag il n'y a que 145 occurrences mais il y a d'autres
tags à suivre plus conséquent.
Mais ceci dit, oui dans 1 ou 2 jours il faudra bien éditer les tags restant.
Ou bien est-ce que je suis trop prudent à faire ainsi ?

J'en ai profité pour changer mes noeuds en chemins sur mes contributions.

Le 21 juil. 2017 à 14:23, Antoine Riche
mailto:antoine.ri...@ymail.com>> a écrit :

Très bien pour la modification du tag. Par contre pour la modification je
suggère qu'une seule et même personne le fasse en partant d'une requête
Overpass (http://overpass-turbo.eu/s/qwb). Ce sera plus efficace et évitera
les erreurs. Je peux le faire mais à condition que personne n'édite en même
temps pour éviter les conflits !

Pour info, si la liste ci-dessous a été créée avec Overpass il s'agit des
dernières personnes à avoir modifié un élément portant le tag en question, et
non les personnes ayant ajouté le tag (personnellement je le découvre !)

Antoine.

Le 21/07/2017 à 13:50, marc marc a écrit :

Suite aux différentes discussions, personne n'a émis d'objection.
La seule utilisation éventuelle est une alerte qualité chez transilien,
Adrien les prévient dans le cadre cartomobilité.

Je vous invite donc à migrer vos tags steps:contrast en step:contrast
liste de mappeur concerné :
1 arxit-france
13 cquest
2 dsidemoon22
1 Emmaschuschu
1 GerdP
12 Jijais
3 JLZIMMERMANN
1 josmougn
2 Lekt
1 Manu1400
8 Markus59
5 mygeomatic
5 naomap
17 overflorian
31 PanierAvide
2 Samusz
12 StephaneP
1 Syl
7 transilien_cartocite
1 unbreton
1 yargil
15 Ymith0936

Suivra : une page wiki en status draft pour détailler l'existant
ou en status "in use" ?
si quelqu'un connaît les critères pour les différents status, qu'il
n'hésites pas à l'expliquer.

Merci,
Marc

Le 18. 07. 17 à 23:23, Marc M. a écrit :

Bonsoir,

En recherchant les tag pour un escalier, j'ai découvert que
contrairement aux autres tags, on utilisait steps:contrast
au pluriel. il y a évidement déjà un cas du tag au singulier
ces tags semblent provenir :
- du hackathon des gares rer/sncf de Paris (en 2013)
- de Rennes

J'en ai discuté avec l'auteur de la page de résumé
http://wiki.openstreetmap.org/wiki/FR:Handicaps/R%C3%A9f%C3%A9rentiel

Dans le but d'harmoniser tout cela,
- est-ce que l'un d'entre-vous à un outil qui les utilise ? éditeur,
logiciel de routing, logiciel d'assistance, carte à thème, peu importe
- pour/contre cette harmonisation ?

PS: quasi tout les tags en step auraient besoin d'une harmonisation,
mais je préfère diviser en petites étapes faciles :)

Cordialement,
Marc

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

[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
Garanti sans virus.
www.avast.com
___
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] Sécuriser Overpass API : quelles solutions ?

Le 21. 07. 17 à 14:21, François Lacombe a écrit :
> Par contre, est-ce utile et justifié de monter une instance overpass en 
> ayant préalablement épuré le jeu de données à ce qui nous intéresse 
> uniquement ?
> Remonter un backend conforme à l'API central pour l'édition, qui 
> dupliquerait le flux d'édition à la fois dans la base locale et sur OSM 
> d'une part et qui permettrait de charger ces données dans l'appli 
> frontend sur une bbox d'autre part ne requiert pas la puissance (et 
> complexité adjacente) d'overpass.
Je n'ai pas compris ce que tu voulais dire.
Sous quelle forme Jungle Bus pourrait garder un cache local avec 
supposons les 2 millions d'objet qu'elle utilise ? et surtout par quel 
moyen les garder à jour tant pour les contributions faite par l'appli 
que celle faite par les contributeurs osm ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Le 21. 07. 17 à 11:26, Christian Quest a écrit :
>> La seule chose qui reste à créer c'est un "diff" non pas mondial ou
>> géographique comme cela existe déjà mais sur base d'un nombre limité
>> d'objet (par exemple plateorm+bus_stop+stop_area+route=bus)
> osmfilter / osmconvert ou osmosis peuvent servir à ça en amont pour 
> filtrer les diff avant de les injecter dans l'update d'overpass afin de 
> ne garder que ce qui est utile.
Merci pour l'info

>> J'ai lu la doc d'install hier soir.
>> L'installation a l'air assez documentée.
>> Je vais tester en local dans les jours à venir.
> Teste sur un extrait, pas sur le planet... et SSD (rapide) indispensable
Je pensais tester sur le plus petit extrait disponible (genre Luxembourg 
ou Monaco). faut juste évidement qu'il y ai au moins une modif :)

>> Mais la version osm-fr était-elle standard ?
>> A lire le wiki, j'ai l'impression que l'instance osm-fr a une
>> amélioration pour permettre de s'en servir comme proxy d'édition.
> C'est un petit script au dessus d'overpass (et indépendant) qui permet 
> de l'utiliser en lieu en place de l'API d'édition.Comment cela s'imbrique ? 
> c'est un cgi qui recoit la requête et dispatch 
vers overpass api ou l'api mondiale selon le cas ?
ou c'est 2 url différentes query<>update ?

Le 21. 07. 17 à 14:34, Rodolphe Pelloux-Prayer a écrit :
 > Pour info, j’ai commencé il y a quelque temps un rôle ansible [0] pour
 > déployer overpass-api sur l’infra osm.fr et il y a une vm en test à
 > l’adresse http://dev.api.openstreetmap.fr avec les données France.
 >
 > Je manque un peu de temps pour finir de valider l’install mais
 > l’instance de dev doit être fonctionnelle (la plupart du temps !). Si
 > vous voulez tester, n’hésitez pas !
 > [0] : https://github.com/osm-fr/ansible-scripts/pull/3
génial ! que reste-t-il à faire ? à tester ?
avec ou sans l'addon pour l'api édition ?
quelle fréquence de maj et quelle source de maj ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] steps:contrast <> step:contrast

2017-07-21 Thread Antoine Riche

Tout à fait d'accord pour la démarche collective puis une modif 
systématique dans quelques jours :-)


Juste pour clarifier la requête Overpass ne sort pas le contributeur qui 
a ajouté le tag steps:contrast mais celui qui est le dernier à avoir 
modifié un élément portant ce tag. Par exemple 
http://www.openstreetmap.org/way/246320694/history montre que c'est 
Markus59 qui a modifié steps:contrasted en steps:contrast, naomap (moi) 
a ensuite ajouté le tag level. Pourtant c'est naomap qui sortira en user 
de la requête.


Antoine.

Le 21/07/2017 à 15:05, marc marc a écrit :
Oui il est possible qu'une personne unique fasse toute les modifs en 
une fois.
Mais  en proposant dans une première phase à chaque mappeur de 
modifier ses propres contributions, je pensais que chacun peux ainsi 
s'assurer qu'il n'a pas d'outil genre preset Josm à modifier et 
surtout être au courant pour la prochaine contribution.

Cela évite aussi les susceptibilités :-)
J'y voyais aussi l'avantage que cela montre un projet collectif que' 
on ne verrait pas si taginfo ne renseigne qu'un contributeur ayant 
fait la dernière modifs.
J'y voyais aussi le dernier avantage de ne pas tomber dans la longue 
procédure des massedit. Pour ce tag il n'y a que 145 occurrences mais 
il y a d'autres tags à suivre plus conséquent.
Mais ceci dit, oui dans 1 ou 2 jours il faudra bien éditer les tags 
restant.

Ou bien est-ce que je suis trop prudent à faire ainsi ?

J'en ai profité pour changer mes noeuds en chemins sur mes contributions.

Le 21 juil. 2017 à 14:23, Antoine Riche > a écrit :


Très bien pour la modification du tag. Par contre pour la 
modification je suggère qu'une seule et même personne le fasse en 
partant d'une requête Overpass (http://overpass-turbo.eu/s/qwb). Ce 
sera plus efficace et évitera les erreurs. Je peux le faire mais à 
condition que personne n'édite en même temps pour éviter les conflits !


Pour info, si la liste ci-dessous a été créée avec Overpass il s'agit 
des dernières personnes à avoir modifié un élément portant le tag en 
question, et non les personnes ayant ajouté le tag (personnellement 
je le découvre !)


Antoine.

Le 21/07/2017 à 13:50, marc marc a écrit :

Suite aux différentes discussions, personne n'a émis d'objection.
La seule utilisation éventuelle est une alerte qualité chez transilien,
Adrien les prévient dans le cadre cartomobilité.

Je vous invite donc à migrer vos tags steps:contrast en step:contrast
liste de mappeur concerné :
1 arxit-france
   13 cquest
2 dsidemoon22
1 Emmaschuschu
1 GerdP
   12 Jijais
3 JLZIMMERMANN
1 josmougn
2 Lekt
1 Manu1400
8 Markus59
5 mygeomatic
5 naomap
   17 overflorian
   31 PanierAvide
2 Samusz
   12 StephaneP
1 Syl
7 transilien_cartocite
1 unbreton
1 yargil
   15 Ymith0936

Suivra : une page wiki en status draft pour détailler l'existant
ou en status "in use" ?
si quelqu'un connaît les critères pour les différents status, qu'il
n'hésites pas à l'expliquer.

Merci,
Marc


Le 18. 07. 17 à 23:23, Marc M. a écrit :

Bonsoir,

En recherchant les tag pour un escalier, j'ai découvert que
contrairement aux autres tags, on utilisait steps:contrast
au pluriel. il y a évidement déjà un cas du tag au singulier
ces tags semblent provenir :
- du hackathon des gares rer/sncf de Paris (en 2013)
- de Rennes

J'en ai discuté avec l'auteur de la page de résumé
http://wiki.openstreetmap.org/wiki/FR:Handicaps/R%C3%A9f%C3%A9rentiel

Dans le but d'harmoniser tout cela,
- est-ce que l'un d'entre-vous à un outil qui les utilise ? éditeur,
logiciel de routing, logiciel d'assistance, carte à thème, peu importe
- pour/contre cette harmonisation ?

PS: quasi tout les tags en step auraient besoin d'une harmonisation,
mais je préfère diviser en petites étapes faciles :)

Cordialement,
Marc

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




 
	Garanti sans virus. www.avast.com 
 



___
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





---
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] Sécuriser Overpass API : quelles solutions ?

2017-07-21 Thread Rodolphe Pelloux-Prayer



Le 21/07/2017 à 15:23, marc marc a écrit :
> Le 21. 07. 17 à 11:26, Christian Quest a écrit :
>>> La seule chose qui reste à créer c'est un "diff" non pas mondial ou
>>> géographique comme cela existe déjà mais sur base d'un nombre limité
>>> d'objet (par exemple plateorm+bus_stop+stop_area+route=bus)
>> osmfilter / osmconvert ou osmosis peuvent servir à ça en amont pour 
>> filtrer les diff avant de les injecter dans l'update d'overpass afin de 
>> ne garder que ce qui est utile.
> Merci pour l'info
>
>>> J'ai lu la doc d'install hier soir.
>>> L'installation a l'air assez documentée.
>>> Je vais tester en local dans les jours à venir.
>> Teste sur un extrait, pas sur le planet... et SSD (rapide) indispensable
> Je pensais tester sur le plus petit extrait disponible (genre Luxembourg 
> ou Monaco). faut juste évidement qu'il y ai au moins une modif :)
>
>>> Mais la version osm-fr était-elle standard ?
>>> A lire le wiki, j'ai l'impression que l'instance osm-fr a une
>>> amélioration pour permettre de s'en servir comme proxy d'édition.
>> C'est un petit script au dessus d'overpass (et indépendant) qui permet 
>> de l'utiliser en lieu en place de l'API d'édition.Comment cela s'imbrique ? 
>> c'est un cgi qui recoit la requête et dispatch 
> vers overpass api ou l'api mondiale selon le cas ?
> ou c'est 2 url différentes query<>update ?
>
> Le 21. 07. 17 à 14:34, Rodolphe Pelloux-Prayer a écrit :
>  > Pour info, j’ai commencé il y a quelque temps un rôle ansible [0] pour
>  > déployer overpass-api sur l’infra osm.fr et il y a une vm en test à
>  > l’adresse http://dev.api.openstreetmap.fr avec les données France.
>  >
>  > Je manque un peu de temps pour finir de valider l’install mais
>  > l’instance de dev doit être fonctionnelle (la plupart du temps !). Si
>  > vous voulez tester, n’hésitez pas !
>  > [0] : https://github.com/osm-fr/ansible-scripts/pull/3
> génial ! que reste-t-il à faire ? à tester ?
Oui, principalement. Et documenter un peu ;) Et mettre en prod ?
L’url a appeler est : http://dev.api.openstreetmap/overpass

> avec ou sans l'addon pour l'api édition ?
Sans. C’est, pour l’instant, uniquement l’install de la version upstream
de overpass-api (v0.7.54).
Pour le proxy api v0.6 et le XAPI, ça peut être rajouté si c’est
vraiment utile.

> quelle fréquence de maj et quelle source de maj ?
Sur la vm de test, la source c’est geofabrik et c’est màj toutes les
heures (pas de diff plus petits de dispo) mais c’est configurable dans
le rôle.

Rodolphe




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

Re: [OSM-talk-fr] steps:contrast <> step:contrast


J'ai modifié les miens ;)

Mini massedit... chut


Le 21/07/2017 à 15:05, marc marc a écrit :
Oui il est possible qu'une personne unique fasse toute les modifs en 
une fois.
Mais  en proposant dans une première phase à chaque mappeur de 
modifier ses propres contributions, je pensais que chacun peux ainsi 
s'assurer qu'il n'a pas d'outil genre preset Josm à modifier et 
surtout être au courant pour la prochaine contribution.

Cela évite aussi les susceptibilités :-)
J'y voyais aussi l'avantage que cela montre un projet collectif que' 
on ne verrait pas si taginfo ne renseigne qu'un contributeur ayant 
fait la dernière modifs.
J'y voyais aussi le dernier avantage de ne pas tomber dans la longue 
procédure des massedit. Pour ce tag il n'y a que 145 occurrences mais 
il y a d'autres tags à suivre plus conséquent.
Mais ceci dit, oui dans 1 ou 2 jours il faudra bien éditer les tags 
restant.

Ou bien est-ce que je suis trop prudent à faire ainsi ?

J'en ai profité pour changer mes noeuds en chemins sur mes contributions.



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?


Le 21/07/2017 à 15:23, marc marc a écrit :



Mais la version osm-fr était-elle standard ?
A lire le wiki, j'ai l'impression que l'instance osm-fr a une
amélioration pour permettre de s'en servir comme proxy d'édition.

C'est un petit script au dessus d'overpass (et indépendant) qui permet
de l'utiliser en lieu en place de l'API d'édition.Comment cela s'imbrique ? 
c'est un cgi qui recoit la requête et dispatch

vers overpass api ou l'api mondiale selon le cas ?
ou c'est 2 url différentes query<>update ?



Pour les GET ce script en transforme certaines en requêtes overpass et 
renvoie la réponse provenant de l'overpass locale comme si il s'agissait 
de l'API OSM "normale". Pour les autres GET et surtout pour les PUT/POST 
(les modifs de données), il agit comme un simple proxy vers l'API d'édition.


L'intérêt lors de sa mise en place était de décharger l'API OSM pour les 
download de données, beaucoup plus nombreux et volumineux que les envois 
de modifs. Le download était aussi un peu plus local et les limites en 
nombre d'objets où superficie chargée avaient été revues à la hausse.


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Le 21 juillet 2017 à 15:11, marc marc  a écrit :

> Le 21. 07. 17 à 14:21, François Lacombe a écrit :
> > Par contre, est-ce utile et justifié de monter une instance overpass en
> > ayant préalablement épuré le jeu de données à ce qui nous intéresse
> > uniquement ?
> > Remonter un backend conforme à l'API central pour l'édition, qui
> > dupliquerait le flux d'édition à la fois dans la base locale et sur OSM
> > d'une part et qui permettrait de charger ces données dans l'appli
> > frontend sur une bbox d'autre part ne requiert pas la puissance (et
> > complexité adjacente) d'overpass.
> Je n'ai pas compris ce que tu voulais dire.
> Sous quelle forme Jungle Bus pourrait garder un cache local avec
> supposons les 2 millions d'objet qu'elle utilise ? et surtout par quel
> moyen les garder à jour tant pour les contributions faite par l'appli
> que celle faite par les contributeurs osm ?
>

Un dessin vaut mieux qu'un long discourt
http://imgur.com/a/g4ec4

J'utilise ce genre de chose (sans l'ecriture vers OSM) depuis quelques mois
et ca tourne plutôt bien

Évidemment j'indique une sycnhro toutes les heures, mais même en le faisant
toutes les 5 minutes on réduirait grandement la charge sur l'overpass par
rapport à une adhérence directe avec le terminal du contributeur.

Le problème de la contribution multiple se retrouve lorsqu'on fait de
l'édition hors ligne.

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

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?


Dans ton schéma, quel est le rôle de l'overpass ?

Est-ce que ce n'est pas juste sa capacité à n'extraire que certaines 
données de la masse qui est utile ?


Ne serait-il pas plus simple de prendre les hourly-diff, de les passer à 
travers osmfilter ou osmosis pour mettre à jour la base locale ?


Je pense qu'overpass est un réel confort, mais qu'on en abuse trop 
souvent... (overpass <-> overkill)



Le 21/07/2017 à 16:10, François Lacombe a écrit :


Un dessin vaut mieux qu'un long discourt
http://imgur.com/a/g4ec4

J'utilise ce genre de chose (sans l'ecriture vers OSM) depuis quelques 
mois et ca tourne plutôt bien


Évidemment j'indique une sycnhro toutes les heures, mais même en le 
faisant toutes les 5 minutes on réduirait grandement la charge sur 
l'overpass par rapport à une adhérence directe avec le terminal du 
contributeur.


Le problème de la contribution multiple se retrouve lorsqu'on fait de 
l'édition hors ligne.


François



--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Le 21 juillet 2017 à 16:17, Christian Quest  a
écrit :

> Dans ton schéma, quel est le rôle de l'overpass ?
>
> Est-ce que ce n'est pas juste sa capacité à n'extraire que certaines
> données de la masse qui est utile ?
>
> Ne serait-il pas plus simple de prendre les hourly-diff, de les passer à
> travers osmfilter ou osmosis pour mettre à jour la base locale ?
>
> Je pense qu'overpass est un réel confort, mais qu'on en abuse trop
> souvent... (overpass <-> overkill)
>

C'est vrai, c'est une bonne idée.
En effet, l'overpass est exploité pour sa capacité à extraire.
+1 pour aller filtrer les hourly ou minute diffs, il faudra que je m'y
intéresse

Par ailleurs, utiliser un backend custom permet à la fois de gérer
différemment les envois vers OSM et vers les données du projet
La collecte peut ne pas porter exclusivement que sur des données OSM et par
conséquent il faut opérer un petit routage.
Si on le remplace par un overpass local, on perd cette possibilité

François

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

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Le 21. 07. 17 à 16:10, François Lacombe a écrit :
> Le 21 juillet 2017 à 15:11, marc marc  > a écrit :
> 
> Le 21. 07. 17 à 14:21, François Lacombe a écrit :
> > Par contre, est-ce utile et justifié de monter une instance overpass en
> > ayant préalablement épuré le jeu de données à ce qui nous intéresse
> > uniquement ?
> > Remonter un backend conforme à l'API central pour l'édition, qui
> > dupliquerait le flux d'édition à la fois dans la base locale et sur OSM
> > d'une part et qui permettrait de charger ces données dans l'appli
> > frontend sur une bbox d'autre part ne requiert pas la puissance (et
> > complexité adjacente) d'overpass.
> Je n'ai pas compris ce que tu voulais dire.
> Sous quelle forme Jungle Bus pourrait garder un cache local avec
> supposons les 2 millions d'objet qu'elle utilise ? et surtout par quel
> moyen les garder à jour tant pour les contributions faite par l'appli
> que celle faite par les contributeurs osm ?
> 
> 
> Un dessin vaut mieux qu'un long discourt
> http://imgur.com/a/g4ec4
le flux est très clair dans ton schéma
Mais ma question était justement comment tu synchronises entre 
l'overpass api et la db locale ?

Vu que les minutes diff existent et que Christian dit qu'on peux les 
filtrer, ne serrais-ce pas plus efficace que l'overpass api français (ou 
n'importe quel autre) exporte un minute-diff filtré ?
Ainsi dans la minute tu as les modifs avec 0 query les 99.99% du temps 
où rien n'a été modifié sur les objets concernés.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Le 21 juillet 2017 à 16:26, marc marc  a écrit :

> Mais ma question était justement comment tu synchronises entre
> l'overpass api et la db locale ?
>

Ca va dépendre de plein de choses
On peut imaginer les choses les plus simples : tu vides ta base locale et
tu remplaces par le retour de l'overpass API (uniquement si toutes tes
données ne concernent qu'OSM)

Au choses les plus compliquées, avec la date d'édition, des références
métier pour le dédoublonnage (ma préférée) puis UPDATE sur conflit avec un
index unique ou insertion
Il reste le cas des suppressions qui est un poil pénible, bien qu'on puisse
ici travailler avec les ID OSM (un des rares cas où on peut le faire)


>
> Vu que les minutes diff existent et que Christian dit qu'on peux les
> filtrer, ne serrais-ce pas plus efficace que l'overpass api français (ou
> n'importe quel autre) exporte un minute-diff filtré ?
> Ainsi dans la minute tu as les modifs avec 0 query les 99.99% du temps
> où rien n'a été modifié sur les objets concernés.
>
oui c'est vrai que c'est encore mieux, l'avantage des diff étant de ne pas
avoir à détecter les create/modify/delete puisque c'est déjà indiqué dedans
On pourrait remplacer l'overpass avec les diff + un bon filtre

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

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?


Pourquoi toujours mettre overpass dans la boucle ?

Les diff sont produits en daily, hourly et minute au niveau osm.org (planet)

On a des diff dispo en daily sur les extraits régionaux proposés par 
geofabrik


On a des diff minute sur les extraits pas mal d'extraits régionaux 
proposés par OSM-FR


Si on ne veut garder qu'une partie de ces données selon certains tags, 
il y a des outils léger pour ça (osmfilter et surtout osmosis)...



overpass me semble surtout utile pour des requêtes non répétitives ou 
changeantes qu'on ne va pas scripter.


Pour du répétitif, ça vaut le coup d'écrire quelques lignes de script 
pour ne pas abuser d'overpass... car à force ces abus saturent les 
instances publiques et rendent trop dépendants des services qui ne 
devraient pas l'être.



(Re)découvrez osmosis...  il peut prendre en entrée un dump complet ou 
des diff, appliquer des filtres dessus, sortir ça au final dans des 
fichiers (pbf, osm, etc) mais aussi dans une base postgres avec au moins 
deux schémas (par exemple le schéma snapshot qui est très proche de 
celui de l'API OSM).


https://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage_0.45

C'est un outil très polyvalent qui ne date pas d'hier et qu'on a un peu 
oublié... mais qui est toujours d'actualité (utilisé par exemple par les 
serveurs de rendu OSM-FR pour agréger plusieurs diff avant de les passer 
à osm2pgsql).



Le 21/07/2017 à 16:26, marc marc a écrit :

Le 21. 07. 17 à 16:10, François Lacombe a écrit :

Le 21 juillet 2017 à 15:11, marc marc mailto:marc_marc_...@hotmail.com>> a écrit :

 Le 21. 07. 17 à 14:21, François Lacombe a écrit :
 > Par contre, est-ce utile et justifié de monter une instance overpass en
 > ayant préalablement épuré le jeu de données à ce qui nous intéresse
 > uniquement ?
 > Remonter un backend conforme à l'API central pour l'édition, qui
 > dupliquerait le flux d'édition à la fois dans la base locale et sur OSM
 > d'une part et qui permettrait de charger ces données dans l'appli
 > frontend sur une bbox d'autre part ne requiert pas la puissance (et
 > complexité adjacente) d'overpass.
 Je n'ai pas compris ce que tu voulais dire.
 Sous quelle forme Jungle Bus pourrait garder un cache local avec
 supposons les 2 millions d'objet qu'elle utilise ? et surtout par quel
 moyen les garder à jour tant pour les contributions faite par l'appli
 que celle faite par les contributeurs osm ?


Un dessin vaut mieux qu'un long discourt
http://imgur.com/a/g4ec4

le flux est très clair dans ton schéma
Mais ma question était justement comment tu synchronises entre
l'overpass api et la db locale ?

Vu que les minutes diff existent et que Christian dit qu'on peux les
filtrer, ne serrais-ce pas plus efficace que l'overpass api français (ou
n'importe quel autre) exporte un minute-diff filtré ?
Ainsi dans la minute tu as les modifs avec 0 query les 99.99% du temps
où rien n'a été modifié sur les objets concernés.
___
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] Sécuriser Overpass API : quelles solutions ?

Le 21. 07. 17 à 16:34, François Lacombe a écrit :
> comment tu synchronises entre l'overpass api et la db locale ?
> On peut imaginer les choses les plus simples : tu vides ta base locale 
> et tu remplaces par le retour de l'overpass API
A mon avis cette façon de faire augmente la charge publique globale.
A chaque syncro (heures ou 5min), tu télécharges 2 millions d'objets 
depuis l'overpass api soit 24 voir 288 millions d'objets par jour !
Si tu as la possibilité de faire des stats, je serrai curieux de 
connaître le nombre d'objet osm consulté dans la db locale par jour...
A mon avis ta db locale consomme + de ressource publique pour se 
synchroniser qu'elle n'en économise en répondant en local.

> Vu que les minutes diff existent et que Christian dit qu'on peux les
> filtrer, ne serrais-ce pas plus efficace que l'overpass api français (ou
> n'importe quel autre) exporte un minute-diff filtré ?
> Ainsi dans la minute tu as les modifs avec 0 query les 99.99% du temps
> où rien n'a été modifié sur les objets concernés.
> oui c'est vrai que c'est encore mieux, l'avantage des diff étant de ne 
> pas avoir à détecter les create/modify/delete puisque c'est déjà indiqué 
> dedans

L'avantage c'est surtout de passer d'une charge de 288 millions 
d'objets/jour à un filtre (qui peux-être mis en priorité ultra-basse sur 
le serveur) qui te transmettra uniquement les qlq (100 ?) modifs/jour
J'ignore la charge qu'implique le filtre mais il est toujours plus léger 
de filtrer des modifs plutôt qu'un query sur l'ensemble des objets.
A mon avis on est sur un gain de ressource publique d'un facteur d'un 
million au bas mot...

PS : l'overpass api n'est visiblement pas protégé contre les abus
parce que très amicalement dit, 288 millions d'objets par jour aurait du 
déclencher un "over-quota" depuis longtemps pour forcer l'analyse + en 
amont.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

2017-07-21 Thread HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI PERFORMANCE)

>> ne serrais-ce pas plus efficace que l'overpass api français (ou
>> n'importe quel autre) exporte un minute-diff filtré ?
Le 21. 07. 17 à 16:53, Christian Quest a écrit :
 > Pourquoi toujours mettre overpass dans la boucle ?

Parce que le filtre serrait plus économe en ressource s'il était situé 
proche (au sens réseau) d'un serveur qui récupère déjà les diffs
Car à nouveau télécharger les diffs mondiales pour après filtre n'en 
garder que l'un ou l'autre consomme plus de ressource que de faire 
l'inverse (filtrer en amont et ne télécharger que le résultat)

Ceci dit un téléchargement d'un diff globale est de toute façon déjà un 
gain gigantesque par rapport à un query global
et il a l'avantage d'être réalisable à court terme (créer un overpass 
api local, un script d'appel au filtre, changer l'url de l'api dans le 
mécanisme de syncro de la db), le reste restant inchangé.
Le mieux est peut-être de commencer par là.
La localisation du filtre est quasi un détail.

 > Les diff sont produits en daily, hourly et minute au niveau osm.org
 > (planet)
 > On a des diff dispo en daily sur les extraits régionaux proposés par
 > geofabrik
En passant, lors du bug osmose, j'ai appris que osm-fr utilisait ceux de 
geofabrik au moins en partie.
il y a une raison à utiliser geofabrik au lieu du planet pour osm-fr ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Et pour ceux qui n'auraient pas l'usage de la puissance/complexité d'un 
postgres, il reste sqlite 
(https://www.gaia-gis.it/fossil/spatialite-tools/wiki?name=OSM+tools) qui 
permet plusieurs schémas et mange de l'osm comme du pbf.


-Message d'origine-
De : Christian Quest [mailto:cqu...@openstreetmap.fr] 
Envoyé : vendredi 21 juillet 2017 16:54
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

...

(Re)découvrez osmosis...  il peut prendre en entrée un dump complet ou 
des diff, appliquer des filtres dessus, sortir ça au final dans des 
fichiers (pbf, osm, etc) mais aussi dans une base postgres avec au moins 
deux schémas (par exemple le schéma snapshot qui est très proche de 
celui de l'API OSM).

https://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage_0.45

C'est un outil très polyvalent qui ne date pas d'hier et qu'on a un peu 
oublié... mais qui est toujours d'actualité (utilisé par exemple par les 
serveurs de rendu OSM-FR pour agréger plusieurs diff avant de les passer 
à osm2pgsql).


Le 21/07/2017 à 16:26, marc marc a écrit :
> Le 21. 07. 17 à 16:10, François Lacombe a écrit :
>> Le 21 juillet 2017 à 15:11, marc marc > > a écrit :
>>
>>  Le 21. 07. 17 à 14:21, François Lacombe a écrit :
>>  > Par contre, est-ce utile et justifié de monter une instance overpass 
>> en
>>  > ayant préalablement épuré le jeu de données à ce qui nous intéresse
>>  > uniquement ?
>>  > Remonter un backend conforme à l'API central pour l'édition, qui
>>  > dupliquerait le flux d'édition à la fois dans la base locale et sur 
>> OSM
>>  > d'une part et qui permettrait de charger ces données dans l'appli
>>  > frontend sur une bbox d'autre part ne requiert pas la puissance (et
>>  > complexité adjacente) d'overpass.
>>  Je n'ai pas compris ce que tu voulais dire.
>>  Sous quelle forme Jungle Bus pourrait garder un cache local avec
>>  supposons les 2 millions d'objet qu'elle utilise ? et surtout par quel
>>  moyen les garder à jour tant pour les contributions faite par l'appli
>>  que celle faite par les contributeurs osm ?
>>
>>
>> Un dessin vaut mieux qu'un long discourt
>> http://imgur.com/a/g4ec4
> le flux est très clair dans ton schéma
> Mais ma question était justement comment tu synchronises entre
> l'overpass api et la db locale ?
>
> Vu que les minutes diff existent et que Christian dit qu'on peux les
> filtrer, ne serrais-ce pas plus efficace que l'overpass api français (ou
> n'importe quel autre) exporte un minute-diff filtré ?
> Ainsi dans la minute tu as les modifs avec 0 query les 99.99% du temps
> où rien n'a été modifié sur les objets concernés.
> ___
> 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
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?


Le 21/07/2017 à 17:12, marc marc a écrit :

ne serrais-ce pas plus efficace que l'overpass api français (ou
n'importe quel autre) exporte un minute-diff filtré ?

Le 21. 07. 17 à 16:53, Christian Quest a écrit :
  > Pourquoi toujours mettre overpass dans la boucle ?

Parce que le filtre serrait plus économe en ressource s'il était situé
proche (au sens réseau) d'un serveur qui récupère déjà les diffs


Encore plus logique de remonter d'un cran et de prendre les diff à leur 
source... ils sont produits pour cela et les télécharger prend la même 
bande passante mais quasiment 0 ressource en CPU (les fichiers sont 
statiques).


Un hourly-diff mondial c'est quelques Mo, les plus gros font dans les 5 
à 6Mo: http://planet.openstreetmap.org/replication/hour/000/042/



Car à nouveau télécharger les diffs mondiales pour après filtre n'en
garder que l'un ou l'autre consomme plus de ressource que de faire
l'inverse (filtrer en amont et ne télécharger que le résultat)


Pour filtrer, c'est de la ressource locale qu'on consomme et donc on 
assume avec ses propres ressources ses choix de filtrage.

Filtrer quelques Mo chaque heure c'est pas méchant.


Ceci dit un téléchargement d'un diff globale est de toute façon déjà un
gain gigantesque par rapport à un query global
et il a l'avantage d'être réalisable à court terme (créer un overpass
api local, un script d'appel au filtre, changer l'url de l'api dans le
mécanisme de syncro de la db), le reste restant inchangé.
Le mieux est peut-être de commencer par là.
La localisation du filtre est quasi un détail.


Oui et non, enfin ça dépend si on parle bien de la même chose...

Requêter overpass pour n'avoir que certaines infos, c'est une forme de 
filtre mais on profite de ressources externes, partagées et donc à un 
moment ça sature...


Récupérer les diff et les filtrer soit même ça bouffe un peu plus de 
bande passante, mais quasiment pas de CPU autre que le nôtre... c'est 
plus scalable.




  > Les diff sont produits en daily, hourly et minute au niveau osm.org
  > (planet)
  > On a des diff dispo en daily sur les extraits régionaux proposés par
  > geofabrik
En passant, lors du bug osmose, j'ai appris que osm-fr utilisait ceux de
geofabrik au moins en partie.
il y a une raison à utiliser geofabrik au lieu du planet pour osm-fr ?


C'est pour osmose que ça tourne comme ça, car les analyses osmose sont 
faites sur un cluster de backends qui traitent une zone à la fois et les 
extraits de geofabrik sont parfaits pour ça. Chaque backend récupère par 
exemple un pays, applique les règles dessus (qui peuvent du coup être 
spécifiques au pays).
Le découpage est déjà fait par géofabrik et il n'est fait qu'une fois. 
La bande passante pour récupérer les données par extraits est similaire 
à celle pour récupérer le planet qu'on redécouperait... on n'y gagnerait 
rien au final, bilan quasi nul.


Pour les serveurs de tuiles, ce sont les diff monde qui sont récupérés 
toutes les 5mn, car leur couverture est mondiale. Ce sont des 
flux/usages totalement différents.


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

>> Ceci dit un téléchargement d'un diff globale est de toute façon déjà un
>> gain gigantesque par rapport à un query global
>> La localisation du filtre est quasi un détail.
> Oui et non, enfin ça dépend si on parle bien de la même chose...
oui on parle bien de la même chose : osmfilter (ou équivalent) d'un diff

overpass n'est pas pour pas un filtre mais une requête (avec critère)
D'accord avec toi sur le gain, comme je disais dans le précédent 
message, on doit être dans un facteur d'un million au bas mot pour 
Jungle bus

>>   > Les diff sont produits en daily, hourly et minute au niveau osm.org
>>   > (planet)
>>   > On a des diff dispo en daily sur les extraits régionaux proposés par
>>   > geofabrik
>> En passant, lors du bug osmose, j'ai appris que osm-fr utilisait ceux de
>> geofabrik au moins en partie.
>> il y a une raison à utiliser geofabrik au lieu du planet pour osm-fr ?
> C'est pour osmose que ça tourne comme ça, car les analyses osmose sont 
> faites sur un cluster de backends qui traitent une zone à la fois et les 
> extraits de geofabrik sont parfaits pour ça. Chaque backend récupère par 
> exemple un pays, applique les règles dessus (qui peuvent du coup être 
> spécifiques au pays).
cela prendrait trop de resource de faire du osmfilter sur le planet ?
ou est-ce parce que le traitement de chaque backend dure longtemps qu'on 
ne les alimentes pas avec un diff hourly/minute ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?


Le 21/07/2017 à 17:54, marc marc a écrit :

Ceci dit un téléchargement d'un diff globale est de toute façon déjà un
gain gigantesque par rapport à un query global
La localisation du filtre est quasi un détail.

Oui et non, enfin ça dépend si on parle bien de la même chose...

oui on parle bien de la même chose : osmfilter (ou équivalent) d'un diff

overpass n'est pas pour pas un filtre mais une requête (avec critère)
D'accord avec toi sur le gain, comme je disais dans le précédent
message, on doit être dans un facteur d'un million au bas mot pour
Jungle bus


Au final la requête sert à filtrer selon les critères qu'on indique ;)


   > Les diff sont produits en daily, hourly et minute au niveau osm.org
   > (planet)
   > On a des diff dispo en daily sur les extraits régionaux proposés par
   > geofabrik
En passant, lors du bug osmose, j'ai appris que osm-fr utilisait ceux de
geofabrik au moins en partie.
il y a une raison à utiliser geofabrik au lieu du planet pour osm-fr ?

C'est pour osmose que ça tourne comme ça, car les analyses osmose sont
faites sur un cluster de backends qui traitent une zone à la fois et les
extraits de geofabrik sont parfaits pour ça. Chaque backend récupère par
exemple un pays, applique les règles dessus (qui peuvent du coup être
spécifiques au pays).

cela prendrait trop de resource de faire du osmfilter sur le planet ?
ou est-ce parce que le traitement de chaque backend dure longtemps qu'on
ne les alimentes pas avec un diff hourly/minute ?


Pour des limites de ressource de stockage, les backend ne gardent pas 
les données entre deux traitements, donc les diff ne sont pas utilisés 
mais uniquement des extraits. Ceci permet aussi aux backend de ne pas 
être spécialisé sur tel ou tel territoire.


... ne s'est-on pas bien éloigné du sujet initial ?

--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] catégories dans traduction page wiki

2017-07-21 Thread lenny.libre




Le 21/07/2017 à 00:26, Philippe Verdy a écrit :
En gros pour une page d'article (c'est différent pour une page de 
catégorie) tu commence par ajouter le préfixe de langue (FR:) au nom 
de la catégorie anglaise, ensuite tu regardes si la catégorie est 
redirigée vers un nom traduit après ce suffixe, et tu reviens sur la 
page pour utiliser le nom traduit (avec son préfixe FR:) de la 
catégorie redirigée.
Je vois que cela fonctionne avec ce que tu as corrigé, mais j'ai un peu 
de mal avec le cheminement, si je reprends la 1ère catégorie avant ta 
modif :

[[Category:JOSM plugin|PT Assistant]]
en ajoutant le préfixe de langue, j'aurais obtenu
[[Category:FR:JOSM plugin|PT Assistant]]
comment as-tu regardé les redirection avant enregistrement pour savoir 
qu'il fallait mettre

[[Category:FR:Greffon JOSM|PT Assistant]] ?



Cependant en ce moment la catégorisation du wiki ne marche pas, elle 
n'est pas mise à jour par les nouveaux membres ajoutés ni avec les 
membres qui en sont retirés, et de même les liste des liens menant à 
la page (barre latérale: Outils/Pages Liées) n'est pas non plus mise à 
jour quand d'autres pages sont modifiées pour pointer sur la nouvelle 
page.


C'est un bogue du wiki depuis début juin (depuis le déploiement de 
MediaWiki 1.28.0, pas encore corrigé par MediaWiki depuis plusieurs 
mois et toujours pas corrigé dans les versions 1.29 et 1.30 et leurs 
patches sensés éviter le problème). Bref on n'a plus de mises à jour 
du tout des catégories qui ne font qu'afficher leur état dans lequel 
elles étaient le 5 juin (la seule chose qui change c'est 
éventuellemetn le texte de leur page de description, pas leurs membres.



2017-07-20 20:32 GMT+02:00 lenny.libre >:


Bonjour,

J'ai traduit une page du wiki, je l'ai renommée et les
redirections semblent fonctionner

https://wiki.openstreetmap.org/wiki/FR:JOSM/Greffons/PT_Assistant


Par contre, quand j'arrive au  § catégories de la page sur les
traductions
http://wiki.openstreetmap.org/wiki/FR:Traduction_du_wiki#Cat.C3.A9gorie


Je ne comprends pas bien ce qu'il faut faire

Merci d'avance

Leni


___
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


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

[OSM-talk-fr] Qat et JOSM

2017-07-21 Thread David Crochet


Bonjour

Quality Assurance Tools ne veut plus fonctionner sur JOSM. Quelqu'un 
sait pourquoi ?


Des alternatives ?

Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Le 21 juillet 2017 à 18:02, Christian Quest  a
écrit :

>
> ... ne s'est-on pas bien éloigné du sujet initial ?
>

Il ne me semble pas : Florian voulait trouver une solution aux soucis de
dispo avec l'Overpass
La solution : se passer de l'overpass et faire de l'osmfilter sur les diffs

En tout cas c'est super interessant
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] catégories dans traduction page wiki

2017-07-21 Thread Philippe Verdy

Quand les catégories françaises on été créées, au départ elles avaient le
même nom qu'en anglais avec juste le préfixe FR: en plus.
Ensuite je la renomme avec son nom français, ce qui crée une page de
redirection à la place de l'ancien nom de catégorie. Je modifie cette page
de redirection pour ajouter un bandeau {{Category redirect|}} dont le but
est de suivre le contenu, mais je laisse en place en première ligne le
#REDIRECT qui permet:
* d'une part à la barre des langues de passer d'une langue à l'autre par
ses liens sans connaitre le nom final de la redirection pour chaque lange
* d'autre part permet aux pages qui seraient catégorisées dedans au lieu de
la catégorie redirigée d'avoir le nom de catégroie affiché en bas de page
inscrit en italique (un boin moyen de visualiser instantanément que cette
page devrait être éditée pour utiliser le nom de la catégorie cible de la
redirection)

Ici la page mentionnait [[Category:FR:JOSM plugin|PT Assistant]] (donc
affiché en italique en bas de cette page).

Donc modification de la page et on fait un aperçu pour voir les liens de
catégorie en bas.

Un clic droit sur ce lien italique pour ouvrir la catégorie dans un nouvel
onglet: on aboutit à la catégorie redirigée dont il suffit de reprendre le
nom (avec son préfixe FR: qui est toujours là) dans la page en cours de
modification. Il n'y a plus qu'à enregistrer.

Pour les catégories renommées en français et ne conservant pas le nom
anglais, on a ces redirections: juste renommer une catégorie ne suffit pas.
Le bandeau qu'on y ajoute en plus sert surtout au suivi des catégories
redirigée dont le contenu devrait être vide...

Ou devrait servir à ça, car depuis début juin la liste des membres de
catégories n'est plus mis à jour du tout sur le wiki et tout est figé à la
situation qui était là jusqu'au 5 juin, lorsque le wiki est passé à la
version boguée 1.28 de Mediawiki, version qui n'a d'ailleurs toujours
aucune correction disponible alors que le bogue est signalé depuis novembre
dernier.

Plusieurs contacts aux sysadmins du wiki n'ont pas permis de leur faire
faire des opérations de maintenance (avec un script "refreshLink.php" qui a
été patché à l'occasion pour prendre en compte les bogues de MediaWiki 1.27
mais surtout 1.28 et versions suivantes). Cette maintenance est maintenant
obligatoire et devrait tourner en tâche de fond depuis le compte Linux
d'administration sur lequel l'instance de Mediawiki a été installée en PHP.
L'autre solution est d'exécuter ce script depuis l'interface de maintenance
de Mediawiki (mais celma demande un accès privilégé). Il n'y a
malheureusemernt aucun admin sur ce wiki qui comprend ce qu'il faudrait
faire. Car avant cette version 1.28 installée, MediaWiki ne nécessitait
aucune maintenance puisqu'il incluait le support automatique des tâches en
arrière-plan (ce support ne fonctionne plus du tout! C'est justement ça le
bogue, et cela a empiré avec la version 1.8 qui fait encore plus souvent
appel qu'avant aux tâches en arrière-plan, techniquement appelées des
"defferedTask" car elles sont normalement exécutées soit après avoir
retourné la page HTML au visiteur qui n'a plus à attendre leur exécution,
soit i ce n'est pas possible, en reportant ces tâches à l'exécution par un
job système, une tâche "cron" sur Unix/Linux, qui n'ont jamais été mises en
place sur ce wiki)

Bref on n'a plus aucune alimentaiton des catégories dont le contenu est
figé (à cause d'un premier bogue empêchant leur contenu d'être correctement
mis à jour de façon synchrone en tant que "deferredTask", mais ensuite
aussi de transformer cette tâche échouée en "job" exécutés de façon
asynchrone, puis d'autre bogues supplémentaires dans la gestion des
dépendances entre jobs asynchrones et la gestion des transactions sur les
bases de données qui provoque divers "deadlocks" ou des assertions qui
s'avèrent fausses sur leur état et empêchent de poursuivre. Ensuite les
jobs qui échouent de cette façon sont réessayés plus tard, mais ça crée des
séquences qui partent en boucle ou explosent de façon exponentielle le
nombre de tâches. Bref le système utilisé dans MediaWiki 1.28 est
complètement bogué, et cette version n'aurait JAMAIS du être sortie comme
une release "stable". La dernière version stable utilisable est la version
1.27.

Mais les admins d'OSM ne le savaient pas, Mediawiki ont omis de mentionner
cette anomalie grave. Et de fait tous les wikis qui utilisent cette version
1.28 (ou 1.29 ou 1.30) sortie en novembre (toutes ces versions prétendent
être "stables", c'est faux) ont maintenant de sérieux problèmes de
maintenance. Pour l'instant la seule alternative est ce fichu script
"refreshLink.php" (qui est très couteux sur les serveurs mais qui est la
solution qui tourne en ce moment sur les wikis de Wikimedia, en attendant
faute de mieux).

Comme je ne vois pas du tout ce qu'apporte cette version 1.28 par rapport à
la version 1.27, en terme de fonctionnalité (plein de fonctionnalités de
MediaWiki ne sont pas utilisées

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Le 21. 07. 17 à 19:23, François Lacombe a écrit :
> 
> Le 21 juillet 2017 à 18:02, Christian Quest a écrit :
> ... ne s'est-on pas bien éloigné du sujet initial ?
> 
> 
> Il ne me semble pas : Florian voulait trouver une solution aux soucis de 
> dispo avec l'Overpass
> La solution : se passer de l'overpass et faire de l'osmfilter sur les diffs
> 
> En tout cas c'est super interessant

Je pensais qu'osmose utilisait en partie les diffs lui aussi.
MAis s'il n'en est rien, mes questions sur osmoses sont en effet assez 
éloigné du plantage overpass api. Je vais en faire un sujet séparé.

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

[OSM-talk-fr] instance http://dev.api.openstreetmap/overpass a valider

 >> Le 21. 07. 17 à 14:34, Rodolphe Pelloux-Prayer a écrit :
 >>> j’ai commencé il y a quelque temps un rôle ansible [0] pour
 >>> déployer overpass-api sur l’infra osm.fr et il y a une vm en test à
 >>> l’adresse http://dev.api.openstreetmap.fr avec les données France.
 >>> Je manque un peu de temps pour finir de valider l’install mais
 >>> l’instance de dev doit être fonctionnelle (la plupart du temps !).
 >>> Si vous voulez tester, n’hésitez pas !
 >>> [0] : https://github.com/osm-fr/ansible-scripts/pull/3
 >> génial ! que reste-t-il à faire ? à tester ?
 > Oui, principalement.
une idée des tests utiles à faire ?
s'en servir depuis overpass turbo ?
s'en servir depuis josm ?
Le déploiement précédent avait-il eu des soucis particuliers ?
si oui ce serrait l'occasion de faire les tests sur ce qui avait posé 
problème la fois précédente.

 > Et documenter un peu ;) Et mettre en prod ?
 > L’url a appeler est : http://dev.api.openstreetmap/overpass
je suppose qu'on peux s'en servir dans josm avec l'option "utiliser un 
serveur overpass pour les téléchargements d'objets"

 >> avec ou sans l'addon pour l'api édition ?
 > Sans. C’est, pour l’instant, uniquement l’install de la version
 > upstream de overpass-api (v0.7.54).
ok

 > Pour le proxy api v0.6 et le XAPI, ça peut être rajouté si c’est
 > vraiment utile.
cela dépend bcp de la réponse précédente :)
qu'est-ce qui passe par l'api mondiale quand on active cette option ?
est-ce que d'autres outils ont besoin de l'api v0.6 en place de l'api 
overpass ?

 >> quelle fréquence de maj et quelle source de maj ?
 > Sur la vm de test, la source c’est geofabrik et c’est màj toutes les
 > heures (pas de diff plus petits de dispo) mais c’est configurable dans
 > le rôle.
ok
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?


Hello !

Cette instance gère les adiff ? (attic)

Stf

Le 21. 07. 17 à 14:34, Rodolphe Pelloux-Prayer a écrit :
  > Pour info, j’ai commencé il y a quelque temps un rôle ansible [0] pour
  > déployer overpass-api sur l’infra osm.fr et il y a une vm en test à
  > l’adresse http://dev.api.openstreetmap.fr avec les données France.
  >
  > Je manque un peu de temps pour finir de valider l’install mais
  > l’instance de dev doit être fonctionnelle (la plupart du temps !). Si
  > vous voulez tester, n’hésitez pas !
  > [0] : https://github.com/osm-fr/ansible-scripts/pull/3
génial ! que reste-t-il à faire ? à tester ?



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

[OSM-talk-fr] gare rurale avec bus: et stop_area

Bonjour,

une petite gare ferroviaire rurale + un arrêt de bus
ils ont chacun un uic (l'un avec le nom du village, + gare pour l'autre)
l'infra est commune (banc, poubelle, etc)

combien de stop_area ? et pour quel avantage ?
la page anglaise du wiki préconise 1 seul pour les petits arrêts.
mais le plugin PT suggère qu'un stop_area par paire plaforme+stop, 
permet d'automatiquement d'ajouter le binôme quand l'un des 2 est 
renseigné. Mais cela me semble un peu faible pour dupliquer les stop_area
Votre avis ?

Même question pour un double arrêt de bus (de chaque côté de la rue)

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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

2017-07-21 Thread Romain MEHUT

Bonsoir,

Je veille au grain cf. https://www.openstreetmap.org/changeset/50457272

Romain

Le 1 mars 2017 à 16:44, Romain MEHUT  a écrit :

> Bonjour,
>
> Pour info, les échanges (plus "mordants") avec SeFaireConnaitre continuent
> cf. https://www.openstreetmap.org/changeset/46490928
>
> Romain
>
>
> Le 15 octobre 2015 à 12:04, Romain MEHUT  a écrit
> :
>
>> Bonjour,
>>
>> J'ai pointé l'ajout de deux doublons (magasins Decathlon)
>> https://www.openstreetmap.org/changeset/34586502 et
>> http://www.openstreetmap.org/changeset/34632382 restés non corrigés à ce
>> jour. Et vu l'historique du compte http://www.openstreetmap.org/u
>> ser/SeFaireConnaitre, il y a ailleurs d'autres doublons similaires.
>>
>> Romain
>>
>> Le 14 octobre 2015 23:35,  a écrit :
>>
>>> Bien, merci d'améliorer votre processus de production/validation de
>>> données afin d'éviter de placer un lieu à 1,3 km de son lieu réel (distance
>>> en voiture selon OSRM).
>>> Ici par exemple comme déjà dit un lien sur un emplacement d'arrêt de
>>> tram doit faire tiquer.
>>> Ce n'est bon ni pour votre client, ni pour vous ni pour OpenStreetMap.
>>> Les deux premiers points c'est votre problème.
>>> Le troisième aussi mais c'est surtout celui qui nous concerne.
>>>
>>> Pour votre pénitence, vous leur proposerez une alternative à ceci :
>>> http://juvignac.apef-services.fr/contact.html#map
>>> ;-).
>>>
>>> Jean-Yvon
>>>
>>> Le 14/10/2015 09:23, Support Sefaireconnaitre -
>>> supp...@sefaireconnaitre.com a écrit :
>>>
>>> Bonjour,
>>> Merci pour le signalement, j'ai bien repositionné le point de vente.
>>>
>>> Amandine Nicolas - Ubiflow
>>>
>>>
>>>
>>> ___
>>> 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] steps:contrast <> step:contrast


J'ai modifié les miens aussi.

Mais je n'ai pas vraiment compris pourquoi.
highway=steps est au pluriel
donc
steps:contrast au pluriel aussi, me parait logique

Stf

Le 21/07/2017 à 15:58, Christian Quest a écrit :

J'ai modifié les miens ;)

Mini massedit... chut


Le 21/07/2017 à 15:05, marc marc a écrit :
Oui il est possible qu'une personne unique fasse toute les modifs en 
une fois.
Mais  en proposant dans une première phase à chaque mappeur de 
modifier ses propres contributions, je pensais que chacun peux ainsi 
s'assurer qu'il n'a pas d'outil genre preset Josm à modifier et 
surtout être au courant pour la prochaine contribution.

Cela évite aussi les susceptibilités :-)
J'y voyais aussi l'avantage que cela montre un projet collectif que' 
on ne verrait pas si taginfo ne renseigne qu'un contributeur ayant 
fait la dernière modifs.
J'y voyais aussi le dernier avantage de ne pas tomber dans la longue 
procédure des massedit. Pour ce tag il n'y a que 145 occurrences mais 
il y a d'autres tags à suivre plus conséquent.
Mais ceci dit, oui dans 1 ou 2 jours il faudra bien éditer les tags 
restant.

Ou bien est-ce que je suis trop prudent à faire ainsi ?

J'en ai profité pour changer mes noeuds en chemins sur mes 
contributions.







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

Re: [OSM-talk-fr] steps:contrast <> step:contrast

2017-07-21 Thread PanierAvide

Ce sont tous les tags descriptifs qui sont au singulier : step_count, 
step:condition, step.height, step.length... Sauf le steps:contrast, 
c'est histoire d'avoir au moins une cohérence entre ces tags. Et puis la 
hauteur par exemple se mesure plus facilement pour une seule marche que 
tout l'escalier, ça doit être cela qui explique à l'origine 
l'utilisation du singulier.


Cordialement,

Adrien.

Le 22/07/2017 à 07:44, Stéphane Péneau a écrit :

J'ai modifié les miens aussi.

Mais je n'ai pas vraiment compris pourquoi.
highway=steps est au pluriel
donc
steps:contrast au pluriel aussi, me parait logique

Stf

Le 21/07/2017 à 15:58, Christian Quest a écrit :

J'ai modifié les miens ;)

Mini massedit... chut


Le 21/07/2017 à 15:05, marc marc a écrit :
Oui il est possible qu'une personne unique fasse toute les modifs en 
une fois.
Mais  en proposant dans une première phase à chaque mappeur de 
modifier ses propres contributions, je pensais que chacun peux ainsi 
s'assurer qu'il n'a pas d'outil genre preset Josm à modifier et 
surtout être au courant pour la prochaine contribution.

Cela évite aussi les susceptibilités :-)
J'y voyais aussi l'avantage que cela montre un projet collectif que' 
on ne verrait pas si taginfo ne renseigne qu'un contributeur ayant 
fait la dernière modifs.
J'y voyais aussi le dernier avantage de ne pas tomber dans la longue 
procédure des massedit. Pour ce tag il n'y a que 145 occurrences 
mais il y a d'autres tags à suivre plus conséquent.
Mais ceci dit, oui dans 1 ou 2 jours il faudra bien éditer les tags 
restant.

Ou bien est-ce que je suis trop prudent à faire ainsi ?

J'en ai profité pour changer mes noeuds en chemins sur mes 
contributions.







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



--
PanierAvide
Géomaticien & développeur


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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)


contact:phone n'était pas incorrect.

Pour le reste.hum.

Stf

Le 21/07/2017 à 23:04, Romain MEHUT a écrit :

Bonsoir,

Je veille au grain cf. https://www.openstreetmap.org/changeset/50457272

Romain

Le 1 mars 2017 à 16:44, Romain MEHUT > a écrit :


Bonjour,

Pour info, les échanges (plus "mordants") avec SeFaireConnaitre
continuent cf. https://www.openstreetmap.org/changeset/46490928


Romain


Le 15 octobre 2015 à 12:04, Romain MEHUT mailto:romain.me...@gmail.com>> a écrit :

Bonjour,

J'ai pointé l'ajout de deux doublons (magasins Decathlon)
https://www.openstreetmap.org/changeset/34586502
 et
http://www.openstreetmap.org/changeset/34632382
 restés non
corrigés à ce jour. Et vu l'historique du compte
http://www.openstreetmap.org/user/SeFaireConnaitre
, il y a
ailleurs d'autres doublons similaires.

Romain

Le 14 octobre 2015 23:35, mailto:osm.sanspourr...@spamgourmet.com>> a écrit :

Bien, merci d'améliorer votre processus de
production/validation de données afin d'éviter de placer
un lieu à 1,3 km de son lieu réel (distance en voiture
selon OSRM).
Ici par exemple comme déjà dit un lien sur un emplacement
d'arrêt de tram doit faire tiquer.
Ce n'est bon ni pour votre client, ni pour vous ni pour
OpenStreetMap.
Les deux premiers points c'est votre problème.
Le troisième aussi mais c'est surtout celui qui nous concerne.

Pour votre pénitence, vous leur proposerez une alternative
à ceci :
http://juvignac.apef-services.fr/contact.html#map

;-).

Jean-Yvon

Le 14/10/2015 09:23, Support Sefaireconnaitre -
supp...@sefaireconnaitre.com
 a écrit :

Bonjour,
Merci pour le signalement, j'ai bien repositionné le
point de vente.

Amandine Nicolas - Ubiflow




___
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



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

Re: [OSM-talk-fr] steps:contrast <> step:contrast