Re: [OSM-talk-fr] problème changeset 50360860 massif Polyglot plugin PT_Assistant

2017-07-23 Par sujet Philippe Verdy 
JOSM ferme les changesets déjà envoyés par défaut... sauf si tu as coché
l'option avancée (dans le panneau d'envoi des données) qui demande de le
garder ouvert (sans ce cas c'est à toi de le fermer avec l'accélérateur
clavier ou l'option du menu fichier...)


Le 24 juillet 2017 à 01:26, Jo  a écrit :

> Le "problème" vient de relations route bus longue distance (Flixbus)
> combiné avec ma manie de découper les rond-points ce qui affecte d'autres
> relations route à corriger (-> gros changesets) et puis j'utilise 'o' qui
> déplace tous les noeuds de ces rond-points. Comme les noeuds sont déjà
> déplacés je fais plus grand ou petit le rond point pour le faire conformer
> à l'imagerie des fois.
>
> Je devrai essayer de créer des changesets plus petits. J'utilise déjà
> upload selection, mais il semble que JOSM ne commence pas à chaque fois un
> nouveau changeset, mais continue sur le précédent.
>
> C'est dommage que j'ai fait une bêtise avec le screenshare, car j'avais
> commencé un screencast exactement sur ce changeset-là.
>
> Jo
>
> 2017-07-23 23:44 GMT+02:00 marc marc :
>
>> Bonsoir Jo,
>>
>> Le changeset ne concerne pas la France
>> Mais j'écris ici parce que je ne reçois pas l'email de confirmation pour
>> m'inscrire à la mailing transport (il n'est pas non plus en spam)
>>
>> Il y a des gros problèmes dans le changeset 50360860 supposé concerner
>> la région de Winterthur (suisse) mais que je découvre en constatant des
>> déplacements erroné de noeuds à plus de 100km de là.
>> D'autant plus étonnant qu'aucun bus de Winterthur n'y passe.
>> Avec 2667 noeuds modifés, il y a un bug quelques part.
>> Le temps d'analyser cela, il serrait prudent de suspendre les modifs ou
>> au minimum de vérifier la liste des éléments modifiés avant d'envoyer
>> les modifs.
>>
>> Si quelqu'un pouvait transmettre cet appel à la prudence sur la mailing
>> transport, ce serrait utile pour que les principaux concernés fasse
>> attention le temps que Jo analyse ce qui a pu se passer.
>>
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] problème changeset 50360860 massif Polyglot plugin PT_Assistant

2017-07-23 Par sujet Jo 
Le "problème" vient de relations route bus longue distance (Flixbus)
combiné avec ma manie de découper les rond-points ce qui affecte d'autres
relations route à corriger (-> gros changesets) et puis j'utilise 'o' qui
déplace tous les noeuds de ces rond-points. Comme les noeuds sont déjà
déplacés je fais plus grand ou petit le rond point pour le faire conformer
à l'imagerie des fois.

Je devrai essayer de créer des changesets plus petits. J'utilise déjà
upload selection, mais il semble que JOSM ne commence pas à chaque fois un
nouveau changeset, mais continue sur le précédent.

C'est dommage que j'ai fait une bêtise avec le screenshare, car j'avais
commencé un screencast exactement sur ce changeset-là.

Jo

2017-07-23 23:44 GMT+02:00 marc marc :

> Bonsoir Jo,
>
> Le changeset ne concerne pas la France
> Mais j'écris ici parce que je ne reçois pas l'email de confirmation pour
> m'inscrire à la mailing transport (il n'est pas non plus en spam)
>
> Il y a des gros problèmes dans le changeset 50360860 supposé concerner
> la région de Winterthur (suisse) mais que je découvre en constatant des
> déplacements erroné de noeuds à plus de 100km de là.
> D'autant plus étonnant qu'aucun bus de Winterthur n'y passe.
> Avec 2667 noeuds modifés, il y a un bug quelques part.
> Le temps d'analyser cela, il serrait prudent de suspendre les modifs ou
> au minimum de vérifier la liste des éléments modifiés avant d'envoyer
> les modifs.
>
> Si quelqu'un pouvait transmettre cet appel à la prudence sur la mailing
> transport, ce serrait utile pour que les principaux concernés fasse
> attention le temps que Jo analyse ce qui a pu se passer.
>
> 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] problème changeset 50360860 massif Polyglot plugin PT_Assistant

2017-07-23 Par sujet Philippe Verdy 
J'ai déjà pu remarquer des déplacements involontaires sur plusieurs
éditeurs, pas qu'avec JOSM mais aussi (et plus souvent) avec iD. On peut se
demander si ce n'est pas une anomalie du côté du serveur lui-même, par un
mélange de transactions. Mais en général ça touche quelques noeuds au
hasard mais pas autant dans un même changeset (et avec JOSM c'est plus rare
qu'avec iD où ce peut être plus facilement causé par des bogues du client
Javascript et la prise en compte en retard de prise en compte d'événements
d'interaction utilisateur venant de l'UI).

Mais là ça semble plutôt venir d'un traitement incorrect de la source
utilisée avant import (par exemple une expression régulière pas assez
sélective dans des substitutions ou transformations automatiques pour
adapter les formats, qui aurait fait perdre certains chiffres dans les
coordonnées ou mélanger des points).

Le 23 juillet 2017 à 23:44, marc marc  a écrit :

> Bonsoir Jo,
>
> Le changeset ne concerne pas la France
> Mais j'écris ici parce que je ne reçois pas l'email de confirmation pour
> m'inscrire à la mailing transport (il n'est pas non plus en spam)
>
> Il y a des gros problèmes dans le changeset 50360860 supposé concerner
> la région de Winterthur (suisse) mais que je découvre en constatant des
> déplacements erroné de noeuds à plus de 100km de là.
> D'autant plus étonnant qu'aucun bus de Winterthur n'y passe.
> Avec 2667 noeuds modifés, il y a un bug quelques part.
> Le temps d'analyser cela, il serrait prudent de suspendre les modifs ou
> au minimum de vérifier la liste des éléments modifiés avant d'envoyer
> les modifs.
>
> Si quelqu'un pouvait transmettre cet appel à la prudence sur la mailing
> transport, ce serrait utile pour que les principaux concernés fasse
> attention le temps que Jo analyse ce qui a pu se passer.
>
> 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] Sécuriser Overpass API : quelles solutions ?

2017-07-23 Par sujet Philippe Verdy 
Le 23 juillet 2017 à 23:37,  a écrit :

> Si je comprends bien le souci c'est qu'en cas de plante il faut remonter
> une base puis appliquer les diff.
>
> C'est ça qui est lent.
>
> Mettre du propriétaire n'y changera rien.
>
Je ne dis pas mettre nécessairement du propriétaire, mais des solutions de
réplication rapides existent et font appel à autre chose que nos très
couteux "diff" et l'import de la base monde: on peut travailler à un niveau
inférieur.

En attendant on a bien un gros problème puisque presque personne ne
s'aventure plus à utiliser la solution actuelle (base monde+diffs) qui est
beaucoup trop lourde et inefficace. C'est là qu'il faudrait étudier autre
chose (et sans doute revoir le modèle de données).

Des réplications de base qui ne prennent pas des jours ça existe. Et ça ne
demande même pas de stopper une base en production, ça se fait en live avec
des mécanismes de synchronisation déjà éprouvés. Mais du côté de Postgres
je ne connais pas trop ce qu'on peut faire.

Oracle, Sybase, MSQSQL là oui je connais et pour des volumes beaucoup plus
importants que ceux de la base OSM avec avec de très gros traitements en
plus, pour monter des "cubes" statistiques ou simplement pour assurer la
redondance et une reprise relative rapide après un incident, qui ne coutera
pas plusieurs journées de travail à des centaines de personnes qui ont
besoin de remonter des informations et de produire des données avec des
horaires impératifs tous les jours: on ne parle pas là de juste quelques
heures mais des délais qui ne peuvent pas excéder la demi-heure; tout
retard entraine des annulations de commandes, des remboursements, des
pénalités, ou des retards de facturation et d'encaissement qui peuvent
mettre en péril la santé financière d'une entreprise en l'obligeant à
piocher dans des trésoreries limités ou faire des emprunts à court terme
très couteux...).

OSM pourtant c'est d'abord et avant tout un projet de données, amis il faut
reconnaître qu'on est très mauvais pour les distribuer comme on devrait.
L'édifice est fragile. Et ça touche ensuite tout le reste de la chaine aval
: controle qualité, lutte contre le vandalisme, récupération des dommages,
rendus divers... Et dans ce domaine des sociétés privées ont mis en place
d'autres solutions pour exploiter les données OSM et prévenir les graves
incidents qu'on connait à répétition et où on peine beaucoup trop à se
sortir. Cela nuit gravement à l'image d'OSM et est aussi une raison pour
laquelle plein de services web préfèrent encore utiliser des données
propriétaires (même si elles sont non neutres)

Disons donc que le logiciel utilisé par OSM on s'en fout. S'il faut le
remplacer il ne faut pas hésiter, ce n'est pas le coeur du projet qui est
avant tout les données elles-mêmes, qui sont de plus en plus lourdes et
compliquées à gérer, et dont l'accès commence aussi à être de plus en plus
difficile: ce n'est pas le même type de restriction, mais ces restrictions
finissent par être pire que celles imposées par les API propriétaires de
Google and Co ou les problèmes de licences et coûts d'accès (même si au
passage Google lui en profite pour monter les prix sachant qu'il devient de
plus en plus incontournable). Ce n'est pas parce qu'en dessous du plancher
on aura utilisé des logiciels propriétaires (eux aussi remplaçables) qu'on
aura touché à nos données.

Wikimedia par exemple a change de moteur PHP, puis de moteur SQL, il a
aussi change d'OS, changé de matériels, changé de support réseau, de
datacenters, il a décentralisé plein de services et facilité les migrations
d'un système à l'autre. Dedans il y a plein de composants propriétaires
mais c'est transparent et autant que possible ils ont essayé de ne pas
s'astreindre à la solution unique, pour que tout soit remplaçable (avec
juste des différences de performance qui peuvent être réglées). Les outils
propriétaires ou opensource sont évalués pour ce qu'ils savent faire le
mieux et permet aussi de maitriser les couts avec des moyens humains
limités, rien n'est figé dans le marbre.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] problème changeset 50360860 massif Polyglot plugin PT_Assistant

2017-07-23 Par sujet marc marc 
Bonsoir Jo,

Le changeset ne concerne pas la France
Mais j'écris ici parce que je ne reçois pas l'email de confirmation pour 
m'inscrire à la mailing transport (il n'est pas non plus en spam)

Il y a des gros problèmes dans le changeset 50360860 supposé concerner 
la région de Winterthur (suisse) mais que je découvre en constatant des 
déplacements erroné de noeuds à plus de 100km de là.
D'autant plus étonnant qu'aucun bus de Winterthur n'y passe.
Avec 2667 noeuds modifés, il y a un bug quelques part.
Le temps d'analyser cela, il serrait prudent de suspendre les modifs ou 
au minimum de vérifier la liste des éléments modifiés avant d'envoyer 
les modifs.

Si quelqu'un pouvait transmettre cet appel à la prudence sur la mailing 
transport, ce serrait utile pour que les principaux concernés fasse 
attention le temps que Jo analyse ce qui a pu se passer.

Cordialement,
Marc
___
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-23 Par sujet osm . sanspourriel 
Si je comprends bien le souci c'est qu'en cas de plante il faut remonter 
une base puis appliquer les diff.


C'est ça qui est lent.

Mettre du propriétaire n'y changera rien.

Si on veut répliquer Postgres avec du WAL ou des clusters, la solution 
libre existe.


Il me semble moins coûteux (en moyens humains et en monnaie sonnante et 
trébuchante) d'envisager une meilleure utilisation de la réplication de 
postgres. Et donc d'avoir un cluster par exemple entre la France, 
l'Allemagne et la Russie. Ou mieux entre la France et la France, 
l'Allemagne et l'Allemagne etc... histoire de basculer localement. Mais 
ça veut dire le double de besoins. Est-ce jouable ?


N.B. : il serait aussi intéressant de savoir pourquoi le disque n'a pas 
eu le temps d'écrire.


J'ai fait plus de 500 arrêts brutaux de SSD PLP (Power Loss Protection) 
alors que j'écrivais dessus. Pas eu le moindre soucis. Peut-être que je 
n'avais pas une méthode assez radicale (mais correspondant à mon besoin) 
d'écrire massivement.


Jean-Yvon


Le 23/07/2017 à 20:04, Philippe Verdy - verd...@wanadoo.fr a écrit :
Non je ne parle pas de l'installation du socle logiciel.Le problème 
c'est bien la réplication des données et là on est vraiment à la 
ramasse: il suffit de voir comment c'est compliqué et long de 
redémarrer quand une instance est plantée, et pas du tout à cause du 
logiciel opensource utilisé ou de l'OS.


On a un problème sérieux dans l'architecture des données elles-mêmes 
et leur mode de distribution/réplication. Et on n'a pratiquement rien 
fait pour améliorer ça.


___
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-23 Par sujet Rodolphe Pelloux-Prayer 
Le 21/07/2017 à 20:18, Stéphane Péneau a écrit :
> Hello !
>
> Cette instance gère les adiff ? (attic)

Non, ce n’est pas activé dans le déploiement actuel.

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

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

2017-07-23 Par sujet Rodolphe Pelloux-Prayer 

Le 21/07/2017 à 20:13, marc marc a écrit :
>  >> 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 ?
Non pas vraiment, je suis nouveau sur overpass-api (en admin comme en
utilisateur) :)
Donc je dirais, lâchez-vous ! Le but étant de voir où ça casse.
Normalement, les différents services devraient redémarrer d’eux-mêmes en
cas arrêts inopinés mais c’est très théorique pour l’instant, je n’ai
pas encore pris le temps de regarder le fonctionnement des différents
composants utilisés.
> s'en servir depuis overpass turbo ?
À priori, oui : dans Paramètres, on peut définir le serveur.
> s'en servir depuis josm ?
Aucune idée, mais si on peut définir l’url du serveur, ça doit marcher.
> 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


___
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-23 Par sujet Philippe Verdy 
Non je ne parle pas de l'installation du socle logiciel.Le problème c'est
bien la réplication des données et là on est vraiment à la ramasse: il
suffit de voir comment c'est compliqué et long de redémarrer quand une
instance est plantée, et pas du tout à cause du logiciel opensource utilisé
ou de l'OS.

On a un problème sérieux dans l'architecture des données elles-mêmes et
leur mode de distribution/réplication. Et on n'a pratiquement rien fait
pour améliorer ça.

Le 23 juillet 2017 à 19:59, marc marc  a écrit :

> Philippe je me perd dans la structure de ton message.
>
> ma réponse si j'ai bien compris ton avis :
> - la doc d'installation d'un overpass api est limpide pour un sysadmin
> (même si je ne l'ai pas encore testé). jesaispluski a fait un ansile.
> il ne reste qu'à valider mais si c'est confirmé, déployer une nouvelle
> instance n'est qu'une question d'avoir un serveur pour l'héberger et des
> humains qui s'en occupent...
> Passer à du propriétaire ne change rien à ces 2 besoins.
> Au contraire ca implique de changer l'existant.
>
> - la majorité des énormes site mondiaux tournent sur un socle open
> source. Tous les besoins que tu décris existent en open source et sont
> massivement utilisé.
> Changer de roue (le logiciel) ne résout rien.
>
> - avoir un opendata en logiciel propriétaire signifie que tu ne peux pas
> la répliquer pour tel ou tel projet sans devoir faire appel à du
> propriétaire... souvent payant...
> Avoir une roue payante ne résout rien.
>
> Le 23. 07. 17 à 19:00, Philippe Verdy a écrit :
> > Je crois que le gros problème pour avoir plus de serveurs et donc de
> > redondance c'est toujours le même: moins un problème de bande passante
> > que de la charge énorme que représente l'installation de la base de
> > données, et le fait que très peu de progrès ont été faits pour faciliter
> > sa réplication.
> >
> > Les diffs ne sont pas forcément la meilleure façon si on peut disposer
> > de réplication directe entre bases de données. Mais le choix initial de
> > Postgres ne facilite pas les choses, et là où ça marche vraiment très
> > bien c'est sur d'autres moteurs, malheureusement "propriétaires" comme
> > Oracle, mais en fait seulement commerciaux et qui pourtant ne devrait
> > pas coûter très cher en licence en comparaison des coûts nécessaires
> > pour les stockages, l'hébergement dans un datacenter et la bande
> > passante, mais surtout les couts humains que représentent la maintenance
> > sur la solution actuelle.
> >
> > Passer à des moteurs SQL commerciaux plus solides est surtout un seuil
> > psychologique pour les promoteurs du projet. On craint une nouvelle
> > dépendance alors que les dépendances les plus importantes (humaines) ne
> > sont même pas résolues. On en arrive alors à figer les évolutions, et le
> > projet est soutenu par une infrastructure de plus en plus fragile, qu'un
> > rien suffirait à faire s'effondrer du jour au lendemain (avec des pannes
> > qui mettront ensuite le projet en péril pendant des mois, avec de
> > grosses difficultés pour recapter l'audience qu'il avait).
> >
> > On promeut OSM auprès des administrations, mais faute de ressources
> > humaines on n'est crédible que si à côté de nous on a de vrais
> > fournisseurs de services professionnels. Ces fournisseurs existent, on
> > les a incité à utiliser nos données mais on les a trop peu sollicité
> > pour qu'ils continuent aussi à solidifier l'infrastructure (quitte à
> > accepter qu'on y incorpore des composants propriétaires qui seraient
> > transparents pour nous et pas gênants du tout car n'affectant pas les
> > données elles-mêmes, mais juste l'infrastructure qui les supporte).
> >
> > Et tant qu'on ne franchit pas ce seuil psychologique, Google a encore de
> > beaux jours devant lui et continuera à imposer ses services (mais avec
> > en revanche un comportement pas transparent du tout, affectant les
> > données directement, et avec l'accaparement des droits sur ces données,
> > leur disponibilité et les conditions de leur réutilisations, qui ne font
> > que devenir de plus en plus restrictives et chères pour tout le monde)
> >
> > Demandons nous ce qui est important pour OSM: le logiciel qui le
> > supporte est-il si indispensable et non remplaçable ? Ou bien est-ce les
> > données ? Ne fermons pas la porte aux logiciels propriétaires dans
> > l'infrastructure. A la place consolidons les API, formats de données.
> >
> > Là des choses sont à expérimenter, pas forcément uniquement au sein du
> > moteur SQL, mais avec des systèmes de fichiers synchronisés au niveau de
> > l'OS, ou avec les moniteurs transactionnels. ou la réplication dynamique
> > de machines virtuelles contenant une instance d'OS entière avec ses
> > logiciels et données.
> >
> > Le 23 juillet 2017 à 16:28, sly (sylvain letuffe)  > > a écrit :
> >
> > overflorian wrote
> > > Est-ce que vous sauriez à quoi cela est dû ?
> >
> > Cette page

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

2017-07-23 Par sujet marc marc 
Philippe je me perd dans la structure de ton message.

ma réponse si j'ai bien compris ton avis :
- la doc d'installation d'un overpass api est limpide pour un sysadmin 
(même si je ne l'ai pas encore testé). jesaispluski a fait un ansile.
il ne reste qu'à valider mais si c'est confirmé, déployer une nouvelle 
instance n'est qu'une question d'avoir un serveur pour l'héberger et des 
humains qui s'en occupent...
Passer à du propriétaire ne change rien à ces 2 besoins.
Au contraire ca implique de changer l'existant.

- la majorité des énormes site mondiaux tournent sur un socle open 
source. Tous les besoins que tu décris existent en open source et sont 
massivement utilisé.
Changer de roue (le logiciel) ne résout rien.

- avoir un opendata en logiciel propriétaire signifie que tu ne peux pas 
la répliquer pour tel ou tel projet sans devoir faire appel à du 
propriétaire... souvent payant...
Avoir une roue payante ne résout rien.

Le 23. 07. 17 à 19:00, Philippe Verdy a écrit :
> Je crois que le gros problème pour avoir plus de serveurs et donc de 
> redondance c'est toujours le même: moins un problème de bande passante 
> que de la charge énorme que représente l'installation de la base de 
> données, et le fait que très peu de progrès ont été faits pour faciliter 
> sa réplication.
> 
> Les diffs ne sont pas forcément la meilleure façon si on peut disposer 
> de réplication directe entre bases de données. Mais le choix initial de 
> Postgres ne facilite pas les choses, et là où ça marche vraiment très 
> bien c'est sur d'autres moteurs, malheureusement "propriétaires" comme 
> Oracle, mais en fait seulement commerciaux et qui pourtant ne devrait 
> pas coûter très cher en licence en comparaison des coûts nécessaires 
> pour les stockages, l'hébergement dans un datacenter et la bande 
> passante, mais surtout les couts humains que représentent la maintenance 
> sur la solution actuelle.
> 
> Passer à des moteurs SQL commerciaux plus solides est surtout un seuil 
> psychologique pour les promoteurs du projet. On craint une nouvelle 
> dépendance alors que les dépendances les plus importantes (humaines) ne 
> sont même pas résolues. On en arrive alors à figer les évolutions, et le 
> projet est soutenu par une infrastructure de plus en plus fragile, qu'un 
> rien suffirait à faire s'effondrer du jour au lendemain (avec des pannes 
> qui mettront ensuite le projet en péril pendant des mois, avec de 
> grosses difficultés pour recapter l'audience qu'il avait).
> 
> On promeut OSM auprès des administrations, mais faute de ressources 
> humaines on n'est crédible que si à côté de nous on a de vrais 
> fournisseurs de services professionnels. Ces fournisseurs existent, on 
> les a incité à utiliser nos données mais on les a trop peu sollicité 
> pour qu'ils continuent aussi à solidifier l'infrastructure (quitte à 
> accepter qu'on y incorpore des composants propriétaires qui seraient 
> transparents pour nous et pas gênants du tout car n'affectant pas les 
> données elles-mêmes, mais juste l'infrastructure qui les supporte).
> 
> Et tant qu'on ne franchit pas ce seuil psychologique, Google a encore de 
> beaux jours devant lui et continuera à imposer ses services (mais avec 
> en revanche un comportement pas transparent du tout, affectant les 
> données directement, et avec l'accaparement des droits sur ces données, 
> leur disponibilité et les conditions de leur réutilisations, qui ne font 
> que devenir de plus en plus restrictives et chères pour tout le monde)
> 
> Demandons nous ce qui est important pour OSM: le logiciel qui le 
> supporte est-il si indispensable et non remplaçable ? Ou bien est-ce les 
> données ? Ne fermons pas la porte aux logiciels propriétaires dans 
> l'infrastructure. A la place consolidons les API, formats de données.
> 
> Là des choses sont à expérimenter, pas forcément uniquement au sein du 
> moteur SQL, mais avec des systèmes de fichiers synchronisés au niveau de 
> l'OS, ou avec les moniteurs transactionnels. ou la réplication dynamique 
> de machines virtuelles contenant une instance d'OS entière avec ses 
> logiciels et données.
> 
> Le 23 juillet 2017 à 16:28, sly (sylvain letuffe)  > a écrit :
> 
> overflorian wrote
> > Est-ce que vous sauriez à quoi cela est dû ?
> 
> Cette page liste l'historique des problèmes rencontrés  par les 2
> instances
> "principales" :
> https://wiki.openstreetmap.org/wiki/Overpass_API/status
> 
> 
> 
> overflorian wrote
> > Quelles en sont les causes profondes ?
> 
> Je pense que ça se résume simplement :
> - Trop de gens tirent dessus et trop peu de gens installent d'instances
> publiques (pour répartir la charge, offrir une possibilité de
> redondance) ou
> participent à la maintenance.
> 
> 
> 
> ___
> Talk-fr mailing list
>

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

2017-07-23 Par sujet marc marc 
Le 23. 07. 17 à 16:28, sly (sylvain letuffe) a écrit :
> Mon avis, c'est qu'avant toutes les suggestions que j'ai lu ici sur des
> proxy
disons qu'il y a des solutions à court terme et à + long terme.

un proxy ha pour jungle bus qui bascule entre les instances publiques 
existante, c'est quelques heures de travail, ils peuvent le mettre en 
prod demain.
la mise en prod d'un nouveau serveur overpass api public, c'est un peu + 
long même si je suis assez d'accord avec ce tu en dis.
Je pense que l'un n'empêche pas l'autre

> aider à la remise en service de
> l'instance fr (détails ici) :
> https://listes.openstreetmap.fr/wws/arc/tech/2017-05/msg0.html
> https://listes.openstreetmap.fr/wws/arc/tech/2017-06/msg0.html
> Pour avoir géré cette API pendant ~5 ans seul, je peux dire qu'on est pas
> trop de plusieurs admin pour la surveiller, les raisons que ça plante ne
> manquent pas !

une instance de dev en est en place.
je me suis proposé pour aider à la mise en prod.
mais pour l'instant je n'ai pas de retour de test à faire pour valider
pourrais-tu lire mon autre threat et y répondre à mes questions ?
ce serrait aussi bien de profiter de ton expérience pour connaître des 
exemples de ce qui a foiré dans le passé
on en pale sur l'autre thread ou sur la ml tech, comme tu préfères
___
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-23 Par sujet Philippe Verdy 
Je crois que le gros problème pour avoir plus de serveurs et donc de
redondance c'est toujours le même: moins un problème de bande passante que
de la charge énorme que représente l'installation de la base de données, et
le fait que très peu de progrès ont été faits pour faciliter sa réplication.

Les diffs ne sont pas forcément la meilleure façon si on peut disposer de
réplication directe entre bases de données. Mais le choix initial de
Postgres ne facilite pas les choses, et là où ça marche vraiment très bien
c'est sur d'autres moteurs, malheureusement "propriétaires" comme Oracle,
mais en fait seulement commerciaux et qui pourtant ne devrait pas coûter
très cher en licence en comparaison des coûts nécessaires pour les
stockages, l'hébergement dans un datacenter et la bande passante, mais
surtout les couts humains que représentent la maintenance sur la solution
actuelle.

Passer à des moteurs SQL commerciaux plus solides est surtout un seuil
psychologique pour les promoteurs du projet. On craint une nouvelle
dépendance alors que les dépendances les plus importantes (humaines) ne
sont même pas résolues. On en arrive alors à figer les évolutions, et le
projet est soutenu par une infrastructure de plus en plus fragile, qu'un
rien suffirait à faire s'effondrer du jour au lendemain (avec des pannes
qui mettront ensuite le projet en péril pendant des mois, avec de grosses
difficultés pour recapter l'audience qu'il avait).

On promeut OSM auprès des administrations, mais faute de ressources
humaines on n'est crédible que si à côté de nous on a de vrais fournisseurs
de services professionnels. Ces fournisseurs existent, on les a incité à
utiliser nos données mais on les a trop peu sollicité pour qu'ils
continuent aussi à solidifier l'infrastructure (quitte à accepter qu'on y
incorpore des composants propriétaires qui seraient transparents pour nous
et pas gênants du tout car n'affectant pas les données elles-mêmes, mais
juste l'infrastructure qui les supporte).

Et tant qu'on ne franchit pas ce seuil psychologique, Google a encore de
beaux jours devant lui et continuera à imposer ses services (mais avec en
revanche un comportement pas transparent du tout, affectant les données
directement, et avec l'accaparement des droits sur ces données, leur
disponibilité et les conditions de leur réutilisations, qui ne font que
devenir de plus en plus restrictives et chères pour tout le monde)

Demandons nous ce qui est important pour OSM: le logiciel qui le supporte
est-il si indispensable et non remplaçable ? Ou bien est-ce les données ?
Ne fermons pas la porte aux logiciels propriétaires dans l'infrastructure.
A la place consolidons les API, formats de données.

Là des choses sont à expérimenter, pas forcément uniquement au sein du
moteur SQL, mais avec des systèmes de fichiers synchronisés au niveau de
l'OS, ou avec les moniteurs transactionnels. ou la réplication dynamique de
machines virtuelles contenant une instance d'OS entière avec ses logiciels
et données.

Le 23 juillet 2017 à 16:28, sly (sylvain letuffe)  a
écrit :

> overflorian wrote
> > Est-ce que vous sauriez à quoi cela est dû ?
>
> Cette page liste l'historique des problèmes rencontrés  par les 2 instances
> "principales" :
> https://wiki.openstreetmap.org/wiki/Overpass_API/status
>
>
> overflorian wrote
> > Quelles en sont les causes profondes ?
>
> Je pense que ça se résume simplement :
> - Trop de gens tirent dessus et trop peu de gens installent d'instances
> publiques (pour répartir la charge, offrir une possibilité de redondance)
> ou
> participent à la maintenance.
>
___
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-23 Par sujet sly (sylvain letuffe) 
overflorian wrote
> Est-ce que vous sauriez à quoi cela est dû ? 

Cette page liste l'historique des problèmes rencontrés  par les 2 instances
"principales" :
https://wiki.openstreetmap.org/wiki/Overpass_API/status


overflorian wrote
> Quelles en sont les causes profondes ?

Je pense que ça se résume simplement :
- Trop de gens tirent dessus et trop peu de gens installent d'instances
publiques (pour répartir la charge, offrir une possibilité de redondance) ou
participent à la maintenance.

Comme on peut le voir d'un coup d'oeil sur :
https://wiki.openstreetmap.org/wiki/Overpass_API#Introduction

Il n'y a plus que 2 instances fonctionnelles dont une seule avec des disques
SSD


overflorian wrote
> Y aurait-il une solution que nous pourrions mettre en place pour venir en
> soutien à nos amis les teutons qui gèrent le bouzin ?

Le meilleur endroit pour cette question est sans doute la liste dédiée à
l'overpass

Mon avis, c'est qu'avant toutes les suggestions que j'ai lu ici sur des
proxy, des ha, des redondances dns, des caches il faut des instances
supplémentaires à la base pour répartir la charge. (que ça soit une charge
de ressources, ou une charge de travail)
Ensuite, des conseils ou documentations mieux écrites décrivant les bonnes
pratiques d'usage pour réduire les usages "excessif" (j'ai vu de bonnes
suggestions de surtout éviter le cron toutes les minutes qui bourrine des
requêtes qui prennent 10 secondes !)


overflorian wrote
> Est-ce plutôt un besoin de dev ou d’hébergement ?

Pas de dév, l'outil est très bien déjà. Mais d'administrateurs
système/applicatif pour entretenir d'autres instances qui permettrait de
pérenniser et d'envisager des outils ou code pour de la redondance.
Puis ensuite, de l'hébergement, ces p'tits outils là ne tournent pas sur une
dédibox à 5 € /mois

Évidement, de l'argent pourrait aussi régler les 2 problèmes d'avant, mais
on trouve peu de mécène volontaires pour filer ~300 €/mois afin de fournir
un service gratuit...


overflorian wrote
> Bref, on résout le problème ? ;)

Le dire ne suffit pas, mais pour ceux qui veulent se retrousser les manches,
a mon avis, un bon point de départ c'est d'aider à la remise en service de
l'instance fr (détails ici) :
https://listes.openstreetmap.fr/wws/arc/tech/2017-05/msg0.html
https://listes.openstreetmap.fr/wws/arc/tech/2017-06/msg0.html

Pour avoir géré cette API pendant ~5 ans seul, je peux dire qu'on est pas
trop de plusieurs admin pour la surveiller, les raisons que ça plante ne
manquent pas !




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n8.nabble.com/Securiser-Overpass-API-quelles-solutions-tp5899532p5899663.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Frontière maritime du Pérou

2017-07-23 Par sujet Philippe Verdy 
C'est ce que montre le changeset oui, mais bon ça indique la langue
utilisée dans son éditeur.
Ceci dit le commentaire du changeset  est on ne peut plus bizarre et
contestable.

Le 23 juillet 2017 à 15:46,  a écrit :

> Pour info, le f.. de m.. n'est pas hispanophone mais germanophone ;-).
>
> Sinon d'accord sur la prudence.
>
> Jean-Yvon
>
> Le 23/07/2017 à 15:42, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
>
> ___
> 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-23 Par sujet sly (sylvain letuffe) 
marc marc wrote
> Je sais pas s'il y a une liste entre sysadmin d'overpass api ?

Oui, y'a, et c'est indiqué sur la page principale de documentation de
l'Overpass API au chapitre 3 :
https://wiki.openstreetmap.org/wiki/Overpass_API

C'est une liste de diffusion hébergée par l'association Openstreetmap
France.





-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n8.nabble.com/Securiser-Overpass-API-quelles-solutions-tp5899532p5899661.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Frontière maritime du Pérou

2017-07-23 Par sujet osm . sanspourriel 

Pour info, le f.. de m.. n'est pas hispanophone mais germanophone ;-).

Sinon d'accord sur la prudence.

Jean-Yvon


Le 23/07/2017 à 15:42, Philippe Verdy - verd...@wanadoo.fr a écrit :

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

Re: [OSM-talk-fr] Frontière maritime du Pérou

2017-07-23 Par sujet Philippe Verdy 
A mon avis ce n'est pas sur cette liste qu'il faut poser cette question
mais sur une liste hispanophone en priorité. Sinon c'est le meilleure moyen
de se prendre des réactions hostiles. Il ya peut-être une explication mais
ça fait peut-être déjà l'objet de débats houleux (ou alors certains
effectivement ne comprennent pas la différence et considère que ZEE veux
dire "territorial"... Noter que c'est une zone sensible notamment pour la
pêche avec les bateaux-usines japonais et la marine américaine)

De plus le tracé semble un peu étrange à l'extrême sud, il semble y avoir
des recouvrements avec la ZEE du Chili et même avec ses eaux territoriales.

Bref ne pas toucher sans références très sérieuses au droit maritime
international et aux traités multilatéraux ou décisions de justice
internationale signifiée aux parties requérantes qui se sont défendues
devant la même cour arbitrale dont ils avaient accepté la compétence.

Et documenter tout changement au moins sur le wiki (la base OSM n'est pas
vraiment l'endroit pour discuter des désaccords, même pas les notes, et les
listes de discussion par mail d'OSM sont difficiles à suivre et retrouver:
ce qui y est est très vite oublié)

Le 23 juillet 2017 à 14:56,  a écrit :

> Bonjour,
>
> Quelqu'un peut-il m'éclairer sur la raison de cette étonnante frontière
> maritime du Pérou ?
> https://www.openstreetmap.org/#map=5/-10.488/-76.904
> N'y a-t-il pas un mélange entre eaux territoriales et zone d'économie
> exclusive ?
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Frontière maritime du Pérou

2017-07-23 Par sujet osm . sanspourriel 

Oui moi au moins !

J'ai eu  la même réaction il y a déjà quelques temps.

Remarque la pertinence du commentaire du changeset :

https://www.openstreetmap.org/changeset/35291603#map=6/-12.597/-77.234

Ce pataquès vient du fait que le Pérou n'ayant pas ratifié la convention 
SOLAS, il décide unilatéralement que ses eaux territoriales vont non à 
3, 6, 12 ou 24 MN mais à 200.


Je te passe en MP un échange avec un contributeur. En MP car je ne lui 
ai pas demandé, mais il n'y a rien de secret pour autant.


Comme il y a conflit avec les autres nations, je ne pense pas qu'on 
devrait le représenter ainsi mais a mimima avec une zone neutralisée de 
12 à 200 MN (c'est à dire la ZEE contestée, eau territoriale selon le 
Pérou, ZEE selon les textes internationaux).


Jean-Yvon


Le 23/07/2017 à 14:56, te...@free.fr a écrit :

Bonjour,

Quelqu'un peut-il m'éclairer sur la raison de cette étonnante frontière 
maritime du Pérou ?
https://www.openstreetmap.org/#map=5/-10.488/-76.904
N'y a-t-il pas un mélange entre eaux territoriales et zone d'économie exclusive 
?

Merci,
Teuxe

___
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] projet du mois d'août ? tag de la semaine ?

2017-07-23 Par sujet osm . sanspourriel 
En fait la réponse était dans la question ;-), je voulais juste 
confirmation qu'il n'y avait pas d'objection.


Tiens Romain (ou mieux quelqu'un-e d'autre) encore une remarque à faire 
à SeFaireConnaitre...

Exemple : http://www.openstreetmap.org/node/3914345357
Prenez un au hasard de 
http://www.openstreetmap.org/user/SeFaireConnaitre/history...


Marc me fait remarquer avec justesse que les données sur le site de la 
SNSM sont protégées, je vais donc demander l'autorisation. On a des 
lettres types de demande notamment pour présenter OSM en quelques lignes ?
Sinon je m'y colle, pas de soucis. Mais il y a peut-être des manières de 
demander qui passent mieux que d'autres.


Jean-Yvon

Le 23/07/2017 à 10:21, Christian Quest - cqu...@openstreetmap.fr a écrit :


Nom du lieu où elle se trouve ? Inutile pour la retrouver.. exemple: 
https://www.openstreetmap.org/search?query=auchan%20epagny


Par contre il faut avoir du SNSM quelque part... les tags proposées me 
semblent corrects, et le "de XXX" à ajouter si ce n'est pas le nom de 
la commune.



Le 22/07/2017 à 22:57, marc marc a écrit :

S'il n'y a pas leur nom dans un tag, comment veux tu les retrouver ?
Il y a une liste en open data ?

Le 22 juil. 2017 à 22:44, "osm.sanspourr...@spamgourmet.com 
" 
> a écrit :



Bonjour,
Je prends la balle de Marc au bond : et si on améliorait la carte 
des stations de sauvetage de la SNSM (qui est une association, pas 
une entreprise comme indiqué par Philippe) ?

je propose :
short_name=SNSM
operator=SNSM
emergency=lifeguard_base 


name=station SNSM de XXX
C'est ainsi qu'ils les nomment. Quand c'est le nom de la commune, 
doit-on juste mettre Station SNSM ?


website=https://www.snsm.org/etablissement/station-snsm-de-XXX
(les coordonnées sont en général sur cette page).

Actuellement les infos sont inhomogènes. Certaines stations n'ont 
pas SNSM dans leur nom. Heureusement à Camaret-sur-Mer il y a une 
cale nommée "cale SNSM". La station était notée Station de 
Camaret-sur-Mer et sur le fronton du bâtiment est écrit canot de 
sauvetage SNSM 
 
(sur le côté je ne sais plus). Le titre est naturellement dépassé 
car les canots restent maintenant en mer. Ces abris servent plus 
souvent à présenter l'historique de la station.


Et parti ainsi la semaine prochaine je propose de continuer le mois 
suivant ;-).



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

Date :  Fri, 21 Jul 2017 11:25:48 +0200
Pour :  talk-fr@openstreetmap.org



Dans les environs des plages il me semble plus utile d'indiquer les 
stations SNSM/CRS et le sauvetage en mer est Grande Cause Nationale 
2017 
.


emergency=lifeguard_base 
 
pour les stations


FR:Tag:emergency=water_rescue_station 
__ 
pour les simples postes de surveillance
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



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


--
Christian Quest - OpenStreetMap France

[OSM-talk-fr] Frontière maritime du Pérou

2017-07-23 Par sujet teuxe 
Bonjour,

Quelqu'un peut-il m'éclairer sur la raison de cette étonnante frontière 
maritime du Pérou ?
https://www.openstreetmap.org/#map=5/-10.488/-76.904
N'y a-t-il pas un mélange entre eaux territoriales et zone d'économie exclusive 
?

Merci,
Teuxe

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

Re: [OSM-talk-fr] Site de bloc (escalade)

2017-07-23 Par sujet David Crochet 

Bonjour


Le 23/07/2017 à 11:40, Fred Moine a écrit :


D'autres propositions



https://wiki.openstreetmap.org/wiki/Tag:sport%3Dclimbing ?

Cordialement

--
David Crochet


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

[OSM-talk-fr] Site de bloc (escalade)

2017-07-23 Par sujet Fred Moine 
Bonjour,

Ami grimpeur : ) je suis entrain de recenser les sites de bloc dans la
massif du Mont Blanc, activité du week end. Pour en faire une carte après

J'aimerai valider les tags suivants, j'ai mis:

sport=climbing
natural=rock
climbing:boulder=yes

reste à voir comment mettre les cotations

D'autres propositions

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

Re: [OSM-talk-fr] projet du mois d'août ? tag de la semaine ?

2017-07-23 Par sujet Christian Quest 
Nom du lieu où elle se trouve ? Inutile pour la retrouver.. exemple: 
https://www.openstreetmap.org/search?query=auchan%20epagny


Par contre il faut avoir du SNSM quelque part... les tags proposées me 
semblent corrects, et le "de XXX" à ajouter si ce n'est pas le nom de la 
commune.



Le 22/07/2017 à 22:57, marc marc a écrit :

S'il n'y a pas leur nom dans un tag, comment veux tu les retrouver ?
Il y a une liste en open data ?

Le 22 juil. 2017 à 22:44, "osm.sanspourr...@spamgourmet.com 
" 
> a écrit :



Bonjour,
Je prends la balle de Marc au bond : et si on améliorait la carte des 
stations de sauvetage de la SNSM (qui est une association, pas une 
entreprise comme indiqué par Philippe) ?

je propose :
short_name=SNSM
operator=SNSM
emergency=lifeguard_base 


name=station SNSM de XXX
C'est ainsi qu'ils les nomment. Quand c'est le nom de la commune, 
doit-on juste mettre Station SNSM ?


website=https://www.snsm.org/etablissement/station-snsm-de-XXX
(les coordonnées sont en général sur cette page).

Actuellement les infos sont inhomogènes. Certaines stations n'ont pas 
SNSM dans leur nom. Heureusement à Camaret-sur-Mer il y a une cale 
nommée "cale SNSM". La station était notée Station de Camaret-sur-Mer 
et sur le fronton du bâtiment est écrit canot de sauvetage SNSM 
 
(sur le côté je ne sais plus). Le titre est naturellement dépassé car 
les canots restent maintenant en mer. Ces abris servent plus souvent 
à présenter l'historique de la station.


Et parti ainsi la semaine prochaine je propose de continuer le mois 
suivant ;-).



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

Date :  Fri, 21 Jul 2017 11:25:48 +0200
Pour :  talk-fr@openstreetmap.org



Dans les environs des plages il me semble plus utile d'indiquer les 
stations SNSM/CRS et le sauvetage en mer est Grande Cause Nationale 
2017 
.


emergency=lifeguard_base 
 
pour les stations


FR:Tag:emergency=water_rescue_station 
__ 
pour les simples postes de surveillance
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



___
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 ?

2017-07-23 Par sujet Christian Quest 



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

Le 22. 07. 17 à 20:55, François Lacombe a écrit :

Le 22 juil. 2017 8:47 PM, "marc marc" a écrit :
 Ce genre de projet doit faire des stats anonyme de ce qu'il consomme.
 Tant que le volume est petit comme tu le décris, c'est acceptable de le
 faire sur un overpass public.
Mmm le but du projet est d'etre mondial et de recontrer une large adhésion.

oui et non
oui le projet a un but mondial
mais combien sont les projets à avoir commencé comme initiative perso
pour tester un concept en phase confidentielle ? parfois sans jamais
atteindre leur public
on peux difficilement demander à chaque projet de commencer par
installer un overpass local.
maintenant je retiens de ta réaction qu'il faudrait mieux communiquer
pour expliquer ce que la montée en charge implique en prod et/ou
protéger les serveurs contre les volumes excessif


Proposer une alternative simple à mettre en oeuvre à overpass pour des 
projets qui ont des besoins spécifiques pour accéder aux données OSM me 
semble utile car reproductible.

Jungle Bus peut être l'occasion de mettre ça au point.

Cela améliorera:
- la surcharge sur l'overpass
- les temps de réponse de Jungle Bus (un instance avec juste les données 
utiles et utilisée que par Jungle Bus sera plus réactive)

- l'autonomie en cas d'indispo des instances publiques overpass

L'idéal est un comportement identique à l'overpass comme ça le code 
actuel n'a pas besoin d'être modifié et en cas d'indispo de l'instance 
JungleBus l'appli peut basculer en backup sur les instances publiques.


Je ne suis pas assez familier avec le déploiement d'une instance 
overpass... mais c'est de ce côté qu'il me semble utile d'investir du 
temps (en ce moment je suis plus sur les orthos).



L'overpass traite la selection avant la bbox (ou a traité par le passé)

Si quelqu'un a les infos technique, ce serrait utile à savoir
parce que subjectivement, j'avais l'impression d'un gain en réactivité.


a quoi ressemblerait une appli sur laquelle on est obligé de
selectionner des petites bbox pour que ca reponde ?

c'est ce que je disais, faut pas exagérer.
mais si qlq édite un arrêt de bus à Paris, c'est pas utile de demander
les arrêts de bus mondiaux (parce qu'au minimum il faudrait transférer
les données).
Mais le vrai gain est ailleurs.


C'est assez évident. La façon d'écrire les requêtes overpass avait une 
importance, est-ce encore le cas. Sélectionner en premier sur la bbox 
puis sur les tags me semble en général bien plus efficace sur des bbox 
raisonnables.



Migrez vers une infra dont un cache local, ne perdez pas de temps
Surtout comme l'explique Florian que sa structure en a les moyens

+1


Peut être qu'une simple recette de déploiement d'instance overpass avec 
des données pre-filtrées (osmosis) pour ne garder que l'utile à l'appli 
concernée peut être amplement suffisant pour répondre aux besoins que 
j'ai indiqué plus haut... mais de diffuser la recette avant il faut 
tester le principe pour valider que ça fonctionne.


--
Christian Quest - OpenStreetMap France


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