[OSM-talk-fr] Invitation à discuter de la cartographie interactive sur Wikipédia

[Philippe Verdy]

Appel traduit en français sur MetaWiki...
https://meta.wikimedia.org/wiki/User:CKoerner_(WMF)/Work/Maps_Communication_Invite/fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment traduire les cartes

[Christian Rogel]

Le 16 mai 2016 à 03:22, Philippe Verdy  a écrit :
> 
> Pluisuers centaines de langues, tu exagères, même avec les variétés locales 
> des langues d'oïl et d'oc (qui forment un continuum et qu'il est d'autant 
> plus difificile de séparer qu'il n'y a même pas d'ortographe normalisée pour 
> bon nombre).

Mettons que plusieurs centaines soient un peu extrapolé, mais il y en a 
plusieurs dizaines uniquement en Nouvelle-Calédonie.
La normalisation endogène n'est pas le sujet, car, la normalisation 
administrative loufoque avec les phonèmes du français et les mécompréhensions 
ne changent pas la source originelle.

Christian R.

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

Re: [OSM-talk-fr] Timeout avec OverpassT : alternative?

[Philippe Verdy]

Sauf que le choix de PostgreSQL n'est pas stupide étant donné ce qui est
demandé et déjà fourni:

- moniteur transactionnel anvec transaction log et recovery, backup et
réplication "live", gestion des caches, construction des index, niveau de
performance et de sécurité, concurrence d'accès très élevée, gestion des
supports de stockage, etc.
- le package GIS pour PostgreSQL et le support des recherches géométriques
par coordonnées
- les packages de transformation de géométrie.

Ca fait beaucoup à réécrire avec trop de bogues possibles pendant longtemps
(alors que PostgreSQL est stable et performant et bien maintenu) !

Certes Overpass n'étant qu'un outil d'interrogation, il n'a pas (ou pas
encore!) à gérer des mises à jour de la base de données OSM (exemple
sélectionner une liste d'objets, permettre la modification de certains
tags, faire des fusions ou conversion de tags, puis soumettre les objets
modifiés dans un ou plusieurs changeset au nom de l'utilisateur).

Il peut encore monter une copie read-only de la base OSM sans gestion des
transactions, mais il a besoin de transactions séparées pour l'exécution de
chaque requête et construire des index temporaires de sélection et les
combiner. Cependant sa base read-only doit aussi suivre l'intégration des
minute-diffs venant de la base principale pour rester synchronisée avec
elle. Les transactions évitent aussi une corruption totale et la
reconstruction complète à partir d'un planet dump (qui prend plusieurs
jours) en cas de plantage temporaire (il y a moyen de se resynchroniser
automatiquement en faisant un rollback des transactions incomplètes non
"committées" par les minute-diffs incomplètement chargés).

Overpass a besoin aussi des outils géométriques pour pas mal de ses
requêtes qui font des transformations (exemple: calcul de buffer, cacul
d'un centroïde).

Pour Overpass en revanche ce qui manque c'est juste un optimiseur de
requête permettant de calculer un plan d'exécution correct (car il est
clair que le plan d'exécution fait par Overpass est mauvais et oblige à
faire de multiples requêtes très lourdes à la base OSM principale pour
ensuite appliquer localement sur son propre serveur des fusions et filtres.

Le problème n'est pas dans la base OSM elle-même mais bien dans OverPass
(sur ses propres serveurs) :
- la façon dont il analyse les requêtes utilisateur pour les transformer en
requêtes avec la base principale (même s'il en dispose localement d'une
copie répliquée pour éviter de faire des requêtes distantes d'un pays à
l'autre, puisque Overpass est installé en Allemagne, en France et en Russie
mais la base OSM principale en Angleterre: les "lags" seraient beaucoup
trop longs et en plus la quantité de données qu"'Overpass demanderait à la
base principale serait trop élevée par rapport aux requêtes standards par
l'API sur des régions bien plus limitées)
- ou la façon dont il gère des caches de données pour les requêtes
courantes (sa gestion des "areas" n'est qu'une solution paliative pour une
partie spécifique d'un problème en fait plus général).


Le 16 mai 2016 à 21:20, Bruno  a écrit :

> Le 16/05/2016 17:59, Philippe Verdy a écrit :
> Bonjour,
>
> Pour ma part je pense qu'une base NoSQL sur une architecture distribuée
> serait une solution plus perenne, plus performante et avec moins de
> contraintes de schéma préétabli que les bases SQL.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Timeout avec OverpassT : alternative?

[Bruno]

Le 16/05/2016 17:59, Philippe Verdy a écrit :
personnelmement je trouve que la façon dont est géré le paramètre 
bounding box est plutôt mal fichu: globalement ça fait deux sélections 
d'objets puis une intersection, mais sur une bounding box très grande 
c'est ridicule car une des listes d'objets est beaucoup trop volumineuse.


Au delà d'une certaines surface (à déterminer, laquelle peut aussi 
s'appuyer sur des données statistiques partiellles précalculées sur la 
densité d'un certain nombre de "quad-tiles" pour estimer le nombre 
d'objets ou juste de noeuds inclus dans la bounding box), il ne 
faudrait pas procéder par fusion de deux listes mais par récursion en 
filtrant directement la première liste obtenue par la sélection des 
autres tags.


Il manque à OverPass ce qui est fait dans les bases de données 
relationnelles : un optimiseur statistique de requêtes pour estimer la 
sélectivité et calculer ce qu'on appelle un "plan d'exécution" adéquat.


Les optimiseurs statistiques de bases relationnelles ne font pas que 
ça, ils estiment aussi la sélectivité des index quand on a le choix 
pour une table, et savoir s'il est nécessaire de faire une jointure 
entre l'index et la table pour trouver les autres colonnes nécessaires 
aux filtres (clauses WHERE, GROUP BY/aggrégats) puis au tri final 
(ORDER BY: faut-il créer un index temporaire contenant les clés de 
tri, ou une table temporaire contenant aussi les colonnes de 
résultat), il estiment aussi le volume en I/O (tailles moyenne des 
rangées de données).


[ De tels optimiseurs sont très compliqués à écrire, les règles sont 
d'autant plus complexes que cela dépend aussi de la représentation 
interne des tables et index, de leur codage en terme de compression, 
etc : il faut de bons estimateurs, et parfois aussi maintenir des 
données statistiques de sélectivité (ce qui nécessite un petit peu de 
stockage en plus pour chaque index). Certains moteurs SQL tiennent 
compte aussi de l'usage fait et gèrent des caches statistiques pour 
s'adapter à la demande (ce n'est pas parce qu'un index existe qu'il 
est souvent utilisé, certaines mises à jour d'index peuvent être 
retardées pour aller plus vite sur les mises à jour de tables ou 
d'autres index). ]


En absence de tel optimiseur statistique (au moins minimal sans aller 
jusqu'à l'estimation exacte des I/O, car les données élémentaires 
manipulées ont des tailles très peu variables, hormi le nombre de 
noeuds dans un chemin), OverPass devrait uniquement s'appuyer sur la 
façon dont on écrit la requête pour savoir si on fait des 
intersections de listes ou des récursions par filtre et pour ordonner 
les filtres (l'utilisateur écrivant la requête ayant alors une 
meilleure connaissance de la sélectivité des différents filtres.


Un bon optimiseur pour OverPass en revanche devrait s'appuyer 
directement sur les "quadtiles", en précédant par division successive 
de l'espace rectangulaire de la sélection pour déterminer s'il faut 
procéder dans chaque quadtile par fusion de listes ou par récursion 
sur les quadtiles de niveau inférieur et filtrage à ce niveau. 
Cependant cela demanderait aussi d'intégrer une partie de ce 
traitement directement sur la base SQL d'objets OSM (ou sa copie 
locale), cela demanderait une modification du schéma physique (surtout 
concernant les relations et chemins qu devraient intégrer leur propre 
"bounding box" précalculée sans nécessiter une récursion; sinon gérer 
un cache de "bounding box", pour chaque chemin ou relation).


Actuellement Overpass ne gère qu'un seul cache précalculé : les 
"areas" (qui ont le défaut d'être souvent désynchronisés car ça dépend 
d'un bot de mise à jour qui peut parfois avoir plusieurs jours de 
décalage avec les données réelles, il n'y a pas de calcul à la demande 
avec des caches ayant des durées d'expiration raisonnables, et le bot 
fait en fait trop de travail pour rien sur des areas que personne ou 
presque n'utilise dans des requêtes). Mais ça ne répond pas 
correctement aux besoins. Ces "areas" d'OverPass sont plus souvent une 
gêne qu'elles ne sont utiles, leur coût en terme de charge des 
serveurs Overpass est disproportionné : ces "areas" précalculées 
devraient être abandonnées pour utiliser à la place une génération "à 
la demande" (avec un cache raisonnable d'au moins quelques heures afin 
de prévenir les surcharges serveur du fait de requêtes répétées sur 
des géométries complexes comme les frontières de pays, ou de grandes 
régions, ou d'Etats d'une fédération).


Il faut bien voir que la façon dont les données OSM sont stockées "en 
vrac" dans une base SQL ne leur permet pas d'utiliser les filtres 
classiques SQL permettant à l'optimiseru statistique de fonctionner 
(les différents "tags" d'OSM" ne sont pas des colonnes séparées en 
SQL), et en fait les jointures sont faites à l'aide de tables 
temporaires construites par OverPass, dans l'ordre qu'il détermine 
lui-même (un ordre qui est un peu trop fait "à l'arrache").

Re: [OSM-talk-fr] Timeout avec OverpassT : alternative?

[Shohreh]

Merci!



--
View this message in context: 
http://gis.19327.n5.nabble.com/Timeout-avec-OverpassT-alternative-tp5873617p5873637.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] Timeout avec OverpassT : alternative?

[Philippe Verdy]

personnelmement je trouve que la façon dont est géré le paramètre bounding
box est plutôt mal fichu: globalement ça fait deux sélections d'objets puis
une intersection, mais sur une bounding box très grande c'est ridicule car
une des listes d'objets est beaucoup trop volumineuse.

Au delà d'une certaines surface (à déterminer, laquelle peut aussi
s'appuyer sur des données statistiques partiellles précalculées sur la
densité d'un certain nombre de "quad-tiles" pour estimer le nombre d'objets
ou juste de noeuds inclus dans la bounding box), il ne faudrait pas
procéder par fusion de deux listes mais par récursion en filtrant
directement la première liste obtenue par la sélection des autres tags.

Il manque à OverPass ce qui est fait dans les bases de données
relationnelles : un optimiseur statistique de requêtes pour estimer la
sélectivité et calculer ce qu'on appelle un "plan d'exécution" adéquat.

Les optimiseurs statistiques de bases relationnelles ne font pas que ça,
ils estiment aussi la sélectivité des index quand on a le choix pour une
table, et savoir s'il est nécessaire de faire une jointure entre l'index et
la table pour trouver les autres colonnes nécessaires aux filtres (clauses
WHERE, GROUP BY/aggrégats) puis au tri final (ORDER BY: faut-il créer un
index temporaire contenant les clés de tri, ou une table temporaire
contenant aussi les colonnes de résultat), il estiment aussi le volume en
I/O (tailles moyenne des rangées de données).

[ De tels optimiseurs sont très compliqués à écrire, les règles sont
d'autant plus complexes que cela dépend aussi de la représentation interne
des tables et index, de leur codage en terme de compression, etc : il faut
de bons estimateurs, et parfois aussi maintenir des données statistiques de
sélectivité (ce qui nécessite un petit peu de stockage en plus pour chaque
index). Certains moteurs SQL tiennent compte aussi de l'usage fait et
gèrent des caches statistiques pour s'adapter à la demande (ce n'est pas
parce qu'un index existe qu'il est souvent utilisé, certaines mises à jour
d'index peuvent être retardées pour aller plus vite sur les mises à jour de
tables ou d'autres index). ]

En absence de tel optimiseur statistique (au moins minimal sans aller
jusqu'à l'estimation exacte des I/O, car les données élémentaires
manipulées ont des tailles très peu variables, hormi le nombre de noeuds
dans un chemin), OverPass devrait uniquement s'appuyer sur la façon dont on
écrit la requête pour savoir si on fait des intersections de listes ou des
récursions par filtre et pour ordonner les filtres (l'utilisateur écrivant
la requête ayant alors une meilleure connaissance de la sélectivité des
différents filtres.

Un bon optimiseur pour OverPass en revanche devrait s'appuyer directement
sur les "quadtiles", en précédant par division successive de l'espace
rectangulaire de la sélection pour déterminer s'il faut procéder dans
chaque quadtile par fusion de listes ou par récursion sur les quadtiles de
niveau inférieur et filtrage à ce niveau. Cependant cela demanderait aussi
d'intégrer une partie de ce traitement directement sur la base SQL d'objets
OSM (ou sa copie locale), cela demanderait une modification du schéma
physique (surtout concernant les relations et chemins qu devraient intégrer
leur propre "bounding box" précalculée sans nécessiter une récursion; sinon
gérer un cache de "bounding box", pour chaque chemin ou relation).

Actuellement Overpass ne gère qu'un seul cache précalculé : les "areas"
(qui ont le défaut d'être souvent désynchronisés car ça dépend d'un bot de
mise à jour qui peut parfois avoir plusieurs jours de décalage avec les
données réelles, il n'y a pas de calcul à la demande avec des caches ayant
des durées d'expiration raisonnables, et le bot fait en fait trop de
travail pour rien sur des areas que personne ou presque n'utilise dans des
requêtes). Mais ça ne répond pas correctement aux besoins. Ces "areas"
d'OverPass sont plus souvent une gêne qu'elles ne sont utiles, leur coût en
terme de charge des serveurs Overpass est disproportionné : ces "areas"
précalculées devraient être abandonnées pour utiliser à la place une
génération "à la demande" (avec un cache raisonnable d'au moins quelques
heures afin de prévenir les surcharges serveur du fait de requêtes répétées
sur des géométries complexes comme les frontières de pays, ou de grandes
régions, ou d'Etats d'une fédération).

Il faut bien voir que la façon dont les données OSM sont stockées "en vrac"
dans une base SQL ne leur permet pas d'utiliser les filtres classiques SQL
permettant à l'optimiseru statistique de fonctionner (les différents "tags"
d'OSM" ne sont pas des colonnes séparées en SQL), et en fait les jointures
sont faites à l'aide de tables temporaires construites par OverPass, dans
l'ordre qu'il détermine lui-même (un ordre qui est un peu trop fait "à
l'arrache").


Le 16 mai 2016 à 16:13, Christian Quest  a écrit :

> Sur un très grand BBOX un timeout de 60 est très 

Re: [OSM-talk-fr] Timeout avec OverpassT : alternative?

[Christian Quest]

Sur un très grand BBOX un timeout de 60 est très très insuffisant.

Deux solutions:
- l'augmenter (beaucoup)
- ne pas mettre de BBOX... dans ce cas overpass ne cherchera que via les
tags et sur un type d'objet aussi peu fré"quent que les centrales
nucléaires ça sera beaucoup plus rapide (testé, ça prend 20s)


[out:json][timeout:60];
(
  // query part for: “"generator:source"=nuclear”
  node["generator:source"="nuclear"];
  way["generator:source"="nuclear"];
  relation["generator:source"="nuclear"];
);
out center;




2016-05-16 14:55 GMT+02:00 Shohreh :

> Bonjour
>
> Je voulais récupérer la liste des centrales nucléaires en Europe et les
> importer dans une carte Umap, mais OT fait un time-out:
>
> 
> [out:json][timeout:60];
> (
>   // query part for: “"generator:source"=nuclear”
>   node["generator:source"="nuclear"]({{bbox}});
>   way["generator:source"="nuclear"]({{bbox}});
>   relation["generator:source"="nuclear"]({{bbox}});
> );
> out body;
> >;
> out skel qt;
>
> 
>
> An error occured during the execution of the overpass query! This is what
> overpass API returned:
> runtime error: Query timed out in "query" at line 12 after 61 seconds.
>
> 
>
> Y a-t-il une autre solution?
>
> Merci.
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Timeout-avec-OverpassT-alternative-tp5873617.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
>



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

Re: [OSM-talk-fr] Timeout avec OverpassT : alternative?

[Pierre Béland]

Augmente le paramètre timeout, par exemple a 1200
[out:json][timeout:1200];  
Pierre 


  De : Shohreh 
 À : talk-fr@openstreetmap.org 
 Envoyé le : lundi 16 mai 2016 8h55
 Objet : [OSM-talk-fr] Timeout avec OverpassT : alternative?
   
Bonjour

Je voulais récupérer la liste des centrales nucléaires en Europe et les
importer dans une carte Umap, mais OT fait un time-out:


[out:json][timeout:60];
(
  // query part for: “"generator:source"=nuclear”
  node["generator:source"="nuclear"]({{bbox}});
  way["generator:source"="nuclear"]({{bbox}});
  relation["generator:source"="nuclear"]({{bbox}});
);
out body;
>;
out skel qt;



An error occured during the execution of the overpass query! This is what
overpass API returned:
runtime error: Query timed out in "query" at line 12 after 61 seconds.



Y a-t-il une autre solution?

Merci.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Timeout-avec-OverpassT-alternative-tp5873617.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


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

[OSM-talk-fr] Timeout avec OverpassT : alternative?

[Shohreh]

Bonjour

Je voulais récupérer la liste des centrales nucléaires en Europe et les
importer dans une carte Umap, mais OT fait un time-out:


[out:json][timeout:60];
(
  // query part for: “"generator:source"=nuclear”
  node["generator:source"="nuclear"]({{bbox}});
  way["generator:source"="nuclear"]({{bbox}});
  relation["generator:source"="nuclear"]({{bbox}});
);
out body;
>;
out skel qt;



An error occured during the execution of the overpass query! This is what
overpass API returned:
runtime error: Query timed out in "query" at line 12 after 61 seconds.



Y a-t-il une autre solution?

Merci.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Timeout-avec-OverpassT-alternative-tp5873617.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] Mapcontrib, logiciel

[Vincent Bergeot]

Bonjour,

merci pour les retours mais n'oublions pas dans ces remerciements :

 * Guillaume, qui développe le logiciel (et oui je ne sais pas écrire
   une ligne de code, c'est pour cela que j'ai besoin de mapcontrib !!!)
 * Frédéric, pour ses conseils sur osm et ses outils, qui sait donner
   les coups de pouce ou de rappels, et dont les discussions ont permis
   de faire apparaitre mapcontrib (après avoir tenté des choses sur
   amenity éditor, en roue libre, ...), avec l'envie de faire le pont
   avec osmose,


et puis spécial merci à Yohan Boniface et Noémie Lehuby qui, avec umap 
et openbeermap, nous ont donné plein d'idées et clin d'oeil à 
osm-hydrant qui nous a aussi inspiré (mais qui n'est pas libre, du moins 
la dernière fois que j'ai posé la question).


Bonne journée






Le 16/05/2016 07:35, Arnaud Vandecasteele a écrit :

Bonjour Vincent,

Un grand bravo pour ce logiciel !
C'est une très bonne idée.

Amicalement,

Arnaud

2016-05-13 18:09 GMT+04:00 Pierre-Yves Berrard 
>:


Le 13 mai 2016 à 10:42, Vincent Bergeot > a écrit :

Bonjour,
un mail pour vous présenter MapContrib, logiciel dont
l'objectif est de faciliter la contribution à OpenStreetMap
(par exemple sur des carto, avec des classes, et autres cadres
non imaginés !).

[...]

Guillaume Amat, Vincent Bergeot, Frédéric Rodrigo


Testé et approuvé !
http://www.openstreetmap.org/node/4183617935

Très sympa.


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




--

Arnaud Vandecasteele
SIG - WebMapping - Spatial Ontology - GeoCollaboration

Web Site
http://geotribu.net/
http://about.me/arnaud_vandecasteele



___
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] Mapcontrib, logiciel

[Guillaume AMAT]

Étrange... À quelle adresse ?

Guillaume

Le 16 mai 2016 11:52:32 GMT+02:00, rainerU  a écrit :
>Ça a l'air très bien fait mais quand j’essaye de me connecter avec mon
>compte 
>OSM j'ai systématiquement une erreur "502 Bad Gateway"
>
>
>___
>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] Mapcontrib, logiciel

[rainerU]

Ça a l'air très bien fait mais quand j’essaye de me connecter avec mon compte 
OSM j'ai systématiquement une erreur "502 Bad Gateway"



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