Re: [OSM-talk-fr] Extraire une géométrie représentative d'une relation

2016-08-24 Par sujet François Lacombe 
Merci pour vos retour, j'ai essayé de mieux définir le besoin

Voyez ci-dessous

Le 23 août 2016 à 17:53, Topographe Fou  a écrit
:

> Bonjour
>
> Quid de l'algorithme de Douglas-Peucker ? C'est efficace pour éliminer le
> bruit. Quant à l'appliquer sur autre chose qu'une *unique* ligne *non
> fermée* cela demandera un peu d'adaptation.
>

Merci pour le nom, je ne connaissais pas :)

Ça s'approche oui, et si ce n'est pas le processus complet, en tout cas ça
peut aider

Le 23 août 2016 à 18:54, Christian Quest  a écrit :

> Je ne suis pas sûr que ça donne un résultat pertinent et surtout en ne
> définissant pas clairement ce que tu veux en sortie je pense qu'on peut
> sortir plein de choses bien variées. Si tu veux précisément la géométrie de
> la ligne sans les autres objets de la relation (même cas pour une ligne de
> bus) il faut filtrer sur le rôle et éventuellement le type de géométrie
> (linestring ou polygon).
>
Non vraiment je ne souhaite travailler que sur la géométrie, pas de
filtrage sur le rôle ou les attributs et que ça soit valide pour toute
relation.
Le rôle n'est pas représentatif de la géométrie mais plus de la fonction.
Pour faire un "dessin grossier" de ce à quoi ressemble une relation sur le
terrain, on ne vas pas regarder la fonction des éléments (la conduite
forcée issue d'un barrage peut mesurer 50m comme 10 km)

Pour la définition je pense à : "ne garder que les éléments qui ont des
dimensions à l'échelle de celles de la relation entière".
Pour une autoroute par exemple, on ne va pas garder les petites bretelles
qui sont négligeables mais celle-ci par exemple, un peu plus :
https://www.openstreetmap.org/way/83016524

Il faudrait préalablement assembler les segments de chemin avec des
attributs équivalents (ou avec les mêmes rôles) qui sont placés les uns à
la suite des autres pour obtenir les plus grands objets possibles avant de
filtrer sur leur taille.
Ici travailler en relatif sur les attributs/rôle pose moins de problème :
on compare les membres de la relation entre eux et on a pas besoin de
définir des règles absolues.

L'autoroute est d'ailleurs un bon exemple à bien des égards : le besoin est
de sortir l'itinéraire en supprimant tous les petits éléments de part et
d'autre en ne regardant que la géométrie de ces éléments.
Bon sous OSM, les relations sont uniquement constituées des voies
principales sans ajouter les péages et autres bretelles, mais vous voyez
l'esprit non ?

Il y a aussi une fonction "squelette" dans postgis, elle permet par exemple
> d'avoir une ligne médiane d'un polygone.
>
> Pour le placement de textes, c'est utile, ça permet d'avoir des textes qui
> suivent la forme globale plutôt que d'être placé à l'horizontal, mais je
> n'ai pas encore essayé d'utiliser ça pour les rendus.
>
Comme l'algo de topographe fou, ça peut être utile.

Bref, vaste sujet ;)
>
A plusieurs c'est quand même plus pratique pour réfléchir :)

A+

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

Re: [OSM-talk-fr] Extraire une géométrie représentative d'une relation

2016-08-23 Par sujet Christian Quest 
Je ne suis pas sûr que ça donne un résultat pertinent et surtout en ne 
définissant pas clairement ce que tu veux en sortie je pense qu'on peut 
sortir plein de choses bien variées. Si tu veux précisément la géométrie 
de la ligne sans les autres objets de la relation (même cas pour une 
ligne de bus) il faut filtrer sur le rôle et éventuellement le type de 
géométrie (linestring ou polygon).


Avec postgis, un ST_Buffer négatif, permet de virer ces 
excroissances...  mais ça marchera sur ce type de géométrie pas 
forcément sur d'autres.


Il y a aussi une fonction "squelette" dans postgis, elle permet par 
exemple d'avoir une ligne médiane d'un polygone.


Pour le placement de textes, c'est utile, ça permet d'avoir des textes 
qui suivent la forme globale plutôt que d'être placé à l'horizontal, 
mais je n'ai pas encore essayé d'utiliser ça pour les rendus.


Bref, vaste sujet ;)


Le 23/08/2016 à 16:59, François Lacombe a écrit :
En fait, je donnais un exemple et le but est de trouver une méthode 
pour toutes les relations.

Toutes n'ont pas de membre avec le role line.

On peut se demander ce qu'est une géométrie représentative (je 
raisonne tout haut)
Le périmètre qui encadre tous les membres par exemple, mais trop 
"grossier".

Ou alors la concaténation des plus gros membres de la relation
Il doit surement y avoir d'autres moyens de l'exprimer

Dans mon exemple, on devrait être capable de retrouver la forme de la 
ligne qui constitue le plus gros de la relation en éliminant le 
"bruit" aux extrémités provoqué par des objets proches les uns des 
autres au regarde de l'étendue de la relation.
Mais surtout il ne faut travailler que sur la géométrie des membres, 
dès qu'on passe aux attributs, ca revient à définir des règles 
spécifiques dont je ne veux pas.


Pas sur que ce soit plus clair :)

*François Lacombe*

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

Le 22 août 2016 à 16:45, Christian Quest > a écrit :


Dans overpass une requête permet de ne sélectionner que les
membres portant un certain rôle dans la relation:

rel(5430194 );
way(r:"line");
(._;>;);out skel;

Après il faut en récupérer la version geojson...


Le 22/08/2016 à 15:25, François Lacombe a écrit :

Bonjour Philippe, Guillaume,

Personne n'est a coté de la plaque ;)

Cependant, seule la méthode m’intéresse.
En effet il y a déjà quelques outils qui parviennent à présenter
graphiquement une relation mais j'ai besoin de l'implémenter de
mon côté.

Relativement à l'exemple du résultat d'OSM.org. Il n'emploie pas
une géométrie unique. Il affiche tous les objets de la relation
et c'est vite le fouillis, en plus de devoir être découpé pour
être intégré dans du geojson.
Voir ici : http://www.openstreetmap.org/relation/5430194

Je m'attends à récupérer une ligne toute simple sans les deux
polygones aux extrémités. C'est la seule géométrie "simple" et
représentative qu'on puisse exploiter sans faire appel à des
FeatureCollections ou autre.

Et ça me semble très dur de trouver une méthode générique qui
puisse faire cette synthèse parce qu'il semble qu'il y ait autant
de possibilités que de cas :'(

François

Le 22 août 2016 à 14:45, Philippe Verdy > a écrit :

Le site web OSM le fait déjà quand on "explore" une relation:
ça télécharge un jeu de données JSON permettant le rendu
vectoriel de l'objet sélectionné par dessus le fond de carte.
La Wikipédie francophone le fait aussi sur ses cartes (mais
elle requête son propre serveur pour obtenir aussi des POIs
géolocalisés sur Wikipédia ou des photos géolocalisées sur
Commons)
Attention en cas d'inclusion dans un script web : l'API ne
doit pas surcharger le serveur interrogé (on a vu le problème
ces jours-ci sur Overpass API avec des centaines de milliers
de requêtes par heure au lieu de quelques dizaines
habituellement, deux serveurs Overpass API sont tombés
plusieurs fois de suite, peut-être à cause d'un script d'un
réseau publicitaire abusif ou d'une appli non-officielle type
Pokemon).
Bref gérer des caches sur votre serveur et éviter de faire
des requêtes automatiques en boucle par le client sur chaque
page web du site ou chaque page de l'appli mobile, respecter
les protocoles !


Le 22 août 2016 à 14:30, François Lacombe
> a écrit :

Bonjour à tous,

Avec la récente mise en place et adoption croissante
d'open event

Re: [OSM-talk-fr] Extraire une géométrie représentative d'une relation

2016-08-23 Par sujet Philippe Verdy 
le "bruit" est subjectif selon ce que tu définis. Dans OSM les données sont
précises. Les relations peuvent contenir des enclaves: veux-tu les inclure
ou pas ? tu peux essayer d'exclure le rôle "inner", mais il y a certains
pièges avec parfois des "outer" à l'intérieur d'une zone "inner".

Overpass API ne fait pas de traitement de géométrie, il retourne les
données telles qu'elles sont dans la base, point barre.
Les simplifications géométriques sont faites côté client (et c'est le cas
avec le javascript émis par Overpass Turbo qui réduit les points non
nécessaires selon le niveau de zoom à l'affichage quand cela ne fait pas de
différences significatives en termes de pixels rendus, d'autant plus que
les lignes tracées ont aussi une épaisseur qui peut masquer des points).

Si on veut faire ça côté serveur, il faut une requête plus compliquée non
prise en charge par l'Overpass API, utilisant les transformations prises en
charge en PostgreSQL, mais ce n'est pas disponible publiquement (il te faut
un accès administrateur ou utiliser ta propre base de données, comme le
fait Osmose par exemple).

Mais les Javascripts fournis par Overpass Turbo fonctionnent bien (côté
client) et font pas mal de chose pour faire ces transformations ou
simplifications et afficher correctement ce qu'on cherche sur un fond de
carte.

Enfin, pour certains objets, il n'y a pas que des lignes mais aussi des
noeuds individuels (qui ne sont pas toujours inclus dans la surface:
exemple les chef-lieux d'arrondissements départementaux ne sont pas
nécessairement dans l'arrondissement): c'est à toi de juger de la
pertinence de les inclure ou pas (et de la façon de les représenter: icône
centrée sur le noeud, ou cercle autour, à toi de décider le rayon), ou de
les attacher à la surface par des traits (assez arbitraires) supplémentaires

Comme toujours ce sont des décisions propres à chaque rendu, et OSM ne
tague pas pour le rendu, chacun des rendus ayant ses préférences
éditoriales pour déterminer ce qui est pertinent. Selon chaque choix, il y
aura donc autant de méthodes à définir, il n'y a pas de méthode générale
pour tout.


Le 23 août 2016 à 16:59, François Lacombe  a
écrit :

> En fait, je donnais un exemple et le but est de trouver une méthode pour
> toutes les relations.
> Toutes n'ont pas de membre avec le role line.
>
> On peut se demander ce qu'est une géométrie représentative (je raisonne
> tout haut)
> Le périmètre qui encadre tous les membres par exemple, mais trop
> "grossier".
> Ou alors la concaténation des plus gros membres de la relation
> Il doit surement y avoir d'autres moyens de l'exprimer
>
> Dans mon exemple, on devrait être capable de retrouver la forme de la
> ligne qui constitue le plus gros de la relation en éliminant le "bruit" aux
> extrémités provoqué par des objets proches les uns des autres au regarde de
> l'étendue de la relation.
> Mais surtout il ne faut travailler que sur la géométrie des membres, dès
> qu'on passe aux attributs, ca revient à définir des règles spécifiques dont
> je ne veux pas.
>
> Pas sur que ce soit plus clair :)
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
>
> Le 22 août 2016 à 16:45, Christian Quest  a
> écrit :
>
>> Dans overpass une requête permet de ne sélectionner que les membres
>> portant un certain rôle dans la relation:
>>
>> rel(5430194 );
>> way(r:"line");
>> (._;>;);out skel;
>>
>> Après il faut en récupérer la version geojson...
>>
>> Le 22/08/2016 à 15:25, François Lacombe a écrit :
>>
>> Bonjour Philippe, Guillaume,
>>
>> Personne n'est a coté de la plaque ;)
>>
>> Cependant, seule la méthode m’intéresse.
>> En effet il y a déjà quelques outils qui parviennent à présenter
>> graphiquement une relation mais j'ai besoin de l'implémenter de mon côté.
>>
>> Relativement à l'exemple du résultat d'OSM.org. Il n'emploie pas une
>> géométrie unique. Il affiche tous les objets de la relation et c'est vite
>> le fouillis, en plus de devoir être découpé pour être intégré dans du
>> geojson.
>> Voir ici : http://www.openstreetmap.org/relation/5430194
>> Je m'attends à récupérer une ligne toute simple sans les deux polygones
>> aux extrémités. C'est la seule géométrie "simple" et représentative qu'on
>> puisse exploiter sans faire appel à des FeatureCollections ou autre.
>>
>> Et ça me semble très dur de trouver une méthode générique qui puisse
>> faire cette synthèse parce qu'il semble qu'il y ait autant de possibilités
>> que de cas :'(
>>
>> François
>>
>> Le 22 août 2016 à 14:45, Philippe Verdy  a écrit :
>>
>>> Le site web OSM le fait déjà quand on "explore" une relation: ça
>>> télécharge un jeu de données JSON permettant le rendu vectoriel de l'objet
>>> sélectionné par dessus le fond de carte. La Wikipédie francophone le fait
>>> aussi sur ses cartes (mais elle

Re: [OSM-talk-fr] Extraire une géométrie représentative d'une relation

2016-08-23 Par sujet Topographe Fou 
  Bonjour Quid de l'algorithme de Douglas-Peucker ? C'est efficace pour éliminer le bruit. Quant à l'appliquer sur autre chose qu'une unique ligne non fermée cela demandera un peu d'adaptation.LeTopographeFou   De:fl.infosrese...@gmail.comEnvoyé:23 août 2016 8:00 AMÀ:talk-fr@openstreetmap.orgRépondre à:talk-fr@openstreetmap.orgObjet:Re: [OSM-talk-fr] Extraire une géométrie représentative d'une relation  En fait, je donnais un exemple et le but est de trouver une méthode pour toutes les relations.Toutes n'ont pas de membre avec le role line.On peut se demander ce qu'est une géométrie représentative (je raisonne tout haut)Le périmètre qui encadre tous les membres par exemple, mais trop "grossier".Ou alors la concaténation des plus gros membres de la relationIl doit surement y avoir d'autres moyens de l'exprimerDans mon exemple, on devrait être capable de retrouver la forme de la ligne qui constitue le plus gros de la relation en éliminant le "bruit" aux extrémités provoqué par des objets proches les uns des autres au regarde de l'étendue de la relation.Mais surtout il ne faut travailler que sur la géométrie des membres, dès qu'on passe aux attributs, ca revient à définir des règles spécifiques dont je ne veux pas.Pas sur que ce soit plus clair :)François Lacombefl dot infosreseaux At gmail dot comwww.infos-reseaux.com@InfosReseaux
Le 22 août 2016 à 16:45, Christian Quest <cqu...@openstreetmap.fr> a écrit :
  

  
  
Dans overpass une requête permet de ne sélectionner que les
  membres portant un certain rôle dans la relation:
rel(5430194);
  way(r:"line");
  (._;>;);out skel;

Après il faut en récupérer la version geojson...


Le 22/08/2016 à 15:25, François Lacombe
  a écrit :


  

  

  Bonjour Philippe, Guillaume,

  
  Personne n'est a coté de la plaque ;)
  

Cependant, seule la méthode m’intéresse.
  
  En effet il y a déjà quelques outils qui parviennent à
  présenter graphiquement une relation mais j'ai besoin de
  l'implémenter de mon côté.
  

Relativement à l'exemple du résultat d'OSM.org. Il n'emploie pas
une géométrie unique. Il affiche tous les objets de la relation
et c'est vite le fouillis, en plus de devoir être découpé pour
être intégré dans du geojson.

  

  
Voir ici : http://www.openstreetmap.org/relation/5430194

Je m'attends à récupérer une ligne toute simple
  sans les deux polygones aux extrémités. C'est la seule
  géométrie "simple" et représentative qu'on puisse
  exploiter sans faire appel à des FeatureCollections ou
  autre.


  


Et ça me semble très dur de
  trouver une méthode générique qui puisse faire
  cette synthèse parce qu'il semble qu'il y ait
  autant de possibilités que de cas :'(



François
  


  Le 22 août 2016 à 14:45,
Philippe Verdy <verd...@wanadoo.fr>
a écrit :

  Le site web OSM le fait déjà
quand on "explore" une relation: ça
télécharge un jeu de données JSON permettant
le rendu vectoriel de l'objet sélectionné
par dessus le fond de carte. La Wikipédie
francophone le fait aussi sur ses cartes
(mais elle requête son propre serveur pour
obtenir aussi des POIs géolocalisés sur
Wikipédia ou des photos géolocalisées sur
Commons)
Attention en cas d'inclusion dans un
  script web : l'API ne doit pas surcharger
  le serveur interrogé (on a vu le problème
  ces jours-ci sur Overpass API avec des
  centaines de milliers de req

Re: [OSM-talk-fr] Extraire une géométrie représentative d'une relation

2016-08-23 Par sujet François Lacombe 
En fait, je donnais un exemple et le but est de trouver une méthode pour
toutes les relations.
Toutes n'ont pas de membre avec le role line.

On peut se demander ce qu'est une géométrie représentative (je raisonne
tout haut)
Le périmètre qui encadre tous les membres par exemple, mais trop "grossier".
Ou alors la concaténation des plus gros membres de la relation
Il doit surement y avoir d'autres moyens de l'exprimer

Dans mon exemple, on devrait être capable de retrouver la forme de la ligne
qui constitue le plus gros de la relation en éliminant le "bruit" aux
extrémités provoqué par des objets proches les uns des autres au regarde de
l'étendue de la relation.
Mais surtout il ne faut travailler que sur la géométrie des membres, dès
qu'on passe aux attributs, ca revient à définir des règles spécifiques dont
je ne veux pas.

Pas sur que ce soit plus clair :)

*François Lacombe*

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

Le 22 août 2016 à 16:45, Christian Quest  a écrit :

> Dans overpass une requête permet de ne sélectionner que les membres
> portant un certain rôle dans la relation:
>
> rel(5430194 );
> way(r:"line");
> (._;>;);out skel;
>
> Après il faut en récupérer la version geojson...
>
> Le 22/08/2016 à 15:25, François Lacombe a écrit :
>
> Bonjour Philippe, Guillaume,
>
> Personne n'est a coté de la plaque ;)
>
> Cependant, seule la méthode m’intéresse.
> En effet il y a déjà quelques outils qui parviennent à présenter
> graphiquement une relation mais j'ai besoin de l'implémenter de mon côté.
>
> Relativement à l'exemple du résultat d'OSM.org. Il n'emploie pas une
> géométrie unique. Il affiche tous les objets de la relation et c'est vite
> le fouillis, en plus de devoir être découpé pour être intégré dans du
> geojson.
> Voir ici : http://www.openstreetmap.org/relation/5430194
> Je m'attends à récupérer une ligne toute simple sans les deux polygones
> aux extrémités. C'est la seule géométrie "simple" et représentative qu'on
> puisse exploiter sans faire appel à des FeatureCollections ou autre.
>
> Et ça me semble très dur de trouver une méthode générique qui puisse faire
> cette synthèse parce qu'il semble qu'il y ait autant de possibilités que de
> cas :'(
>
> François
>
> Le 22 août 2016 à 14:45, Philippe Verdy  a écrit :
>
>> Le site web OSM le fait déjà quand on "explore" une relation: ça
>> télécharge un jeu de données JSON permettant le rendu vectoriel de l'objet
>> sélectionné par dessus le fond de carte. La Wikipédie francophone le fait
>> aussi sur ses cartes (mais elle requête son propre serveur pour obtenir
>> aussi des POIs géolocalisés sur Wikipédia ou des photos géolocalisées sur
>> Commons)
>> Attention en cas d'inclusion dans un script web : l'API ne doit pas
>> surcharger le serveur interrogé (on a vu le problème ces jours-ci sur
>> Overpass API avec des centaines de milliers de requêtes par heure au lieu
>> de quelques dizaines habituellement, deux serveurs Overpass API sont tombés
>> plusieurs fois de suite, peut-être à cause d'un script d'un réseau
>> publicitaire abusif ou d'une appli non-officielle type Pokemon).
>> Bref gérer des caches sur votre serveur et éviter de faire des requêtes
>> automatiques en boucle par le client sur chaque page web du site ou chaque
>> page de l'appli mobile, respecter les protocoles !
>>
>>
>> Le 22 août 2016 à 14:30, François Lacombe  a
>> écrit :
>>
>>> Bonjour à tous,
>>>
>>> Avec la récente mise en place et adoption croissante d'open event
>>> database, je me pose une question que certains ont déjà du résoudre.
>>>
>>> Existe-t-il une méthode générique pour convertir une relation OSM en
>>> geojson ?
>>> Cela reviendrait à convertir la relation en géométrie simple (points /
>>> polyline).
>>>
>>> Le besoin est d'attribuer une géométrie représentative à des événements
>>> dégagés par des ouvrages décrit avec une relation.
>>> Après on peut les envoyer sur open event db.
>>>
>>> Mais il peut y avoir des tonnes d'autres usages à cela, sans se limiter
>>> à cet exemple.
>>>
>>> J'aimerais éviter les scripts avec des if/else à rallonge pour cibler
>>> tel ou tel type de relation, à la recherche de tel ou tel objet qui au
>>> final n'est pas forcé de se trouver là où on l'attend, etc...
>>>
>>>
>>> Merci par avance pour vos retours
>>>
>>> François
>>>
>>>
>>> --
>>> *François Lacombe*
>>>
>>> fl dot infosreseaux At gmail dot com
>>> www.infos-reseaux.com
>>> @InfosReseaux 
>>>
>>> ___
>>> 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] Extraire une géométrie représentative d'une relation

2016-08-22 Par sujet Philippe Verdy 
il serait intéressant de compléter cet exemple avec quelque chose de
significatif, notamment car il y a souvent plusieurs rôles ("outer",
"inner", ainsi que le rôle vide souvent mis à la place de "outer" quand il
n'y a aucune enclave)

On peut faire l'union des rôles.
Attention aussi à la requête de récursion avec "(._;>;);" qui récupère
absolument tous les éléments fils dans une union avec l'élément parent (ici
dans le jeu de données "_" par défaut).

Ensuite attention à l'instruction "out;" qui possède plusieurs options pour
déterminer le niveau de détails demandés (sans les tags avec "skel", ou
avec les tag avec l'option par défault "body", ou avec en plus des
métadonnées avec l'option "meta", telles que le dernier changeset, sa date
et l'utilisateur).

Sur une des instances Overpass on a aussi des données historiques ("Attic")
mais c'est souvent très lent (et actuellement cette instance a des
problèmes de surcharge serveur).

Ci-dessous j'annote les noms de resultsets temporaires avec des noms
explicites, plutôt que d'utiliser et écraser le resultset "_" par défaut
entre chacune des 3 requêtes principales :

  // Première requête : la relation cherchée (cela ne sort pas la liste des
membres)
  // Ce resultset temporaire ne sera pas inclus dans le résultat final
  rel(5430194 )->TMP1;

  // Deuxième requête: récursion sur certains membres en fonction des rôles
à garder, le tout dans une (union)
  // Ce resultset temporaire contenant des ways ne sera pas inclus dans le
résultat final
  ( way(r.TMP1:"outer");
way(r.TMP1:"inner");
way(r.TMP1:"");
  )->TMP2;

  // Troisième requête : on garde dans le resultset final une union tous
les ways et la récursion sur tous leurs noeuds membres
  ( .TMP2;
.TMP2>;
  )->TMP3;

  // Résultats de la troisième requête.
 .TMP3 out skel;

Le résultat ici cependant reste un ensemble de "ways" (la deuxième
récursion avec l'opérateur ">" ne les connecte pas automatiquement.
l'interface graphique Overpass Turbo cependant fait cette connexion côté
client (pas côté serveur) pour créer des lignes "lines" continue ou des
aires fermées ("area"), elle analyse les chemins pour aussi déterminer ceux
qui sont internes ou externes pour remplir les surfaces, avec la liste des
noeuds.

Overpass API permet pas mal de souplesse dans la façon de faire des
requêtes et sous-requêtes. Nommer les resultsets d'entrée (indiqués après
un ".") ou de sortie (après un "->") n'a aucun impact en performance, mais
cela permet des requêtes plus complexes ou plus fines selon les besoins.

Mais Overpass API ne sait pas encore transformer sur le serveur les objets
d'un resultset (par exemple créer des buffers, des simplifications de
géométrie, joindre les lignes, déterminer les surfaces fermées dans un
objet parent), c'est à faire côté client (Overpass Turbo le fait via le
javascript qu'il envoie au client, c'est ce javascript également qui fait
un rendu vectoriel MapCSS dans une couche superposée sur le fond de carte;
ce client fait également les calculs de projection pour correspondre à
l'échelle de visualisation et n'afficher et positionner que les objets qui
sont dans le rectangle visible, car Overpass API ne retourne que des
coordonnées WGS84 telles qu'elles sont sur le serveur de données OSM,
indépendamment de la vue courante ou du niveau de zoom).

Overpass sait visiblement de lui-même purger les resultsets nommés dès
qu'ils ne sont plus utiles à d'autres requêtes ou à une instruction "out"
qui suit.

Le 22 août 2016 à 16:45, Christian Quest  a écrit :

> Dans overpass une requête permet de ne sélectionner que les membres
> portant un certain rôle dans la relation:
>
> rel(5430194 );
> way(r:"line");
> (._;>;);out skel;
>
> Après il faut en récupérer la version geojson...
>
> Le 22/08/2016 à 15:25, François Lacombe a écrit :
>
> Bonjour Philippe, Guillaume,
>
> Personne n'est a coté de la plaque ;)
>
> Cependant, seule la méthode m’intéresse.
> En effet il y a déjà quelques outils qui parviennent à présenter
> graphiquement une relation mais j'ai besoin de l'implémenter de mon côté.
>
> Relativement à l'exemple du résultat d'OSM.org. Il n'emploie pas une
> géométrie unique. Il affiche tous les objets de la relation et c'est vite
> le fouillis, en plus de devoir être découpé pour être intégré dans du
> geojson.
> Voir ici : http://www.openstreetmap.org/relation/5430194
> Je m'attends à récupérer une ligne toute simple sans les deux polygones
> aux extrémités. C'est la seule géométrie "simple" et représentative qu'on
> puisse exploiter sans faire appel à des FeatureCollections ou autre.
>
> Et ça me semble très dur de trouver une méthode générique qui puisse faire
> cette synthèse parce qu'il semble qu'il y ait autant de possibilités que de
> cas :'(
>
> François
>
> Le 22 août 2016 à 14:45, Philippe Verdy  a écrit :
>
>> Le site web OSM le fait déjà

Re: [OSM-talk-fr] Extraire une géométrie représentative d'une relation

2016-08-22 Par sujet Christian Quest 
Dans overpass une requête permet de ne sélectionner que les membres 
portant un certain rôle dans la relation:


rel(5430194 );
way(r:"line");
(._;>;);out skel;

Après il faut en récupérer la version geojson...


Le 22/08/2016 à 15:25, François Lacombe a écrit :

Bonjour Philippe, Guillaume,

Personne n'est a coté de la plaque ;)

Cependant, seule la méthode m’intéresse.
En effet il y a déjà quelques outils qui parviennent à présenter 
graphiquement une relation mais j'ai besoin de l'implémenter de mon côté.


Relativement à l'exemple du résultat d'OSM.org. Il n'emploie pas une 
géométrie unique. Il affiche tous les objets de la relation et c'est 
vite le fouillis, en plus de devoir être découpé pour être intégré 
dans du geojson.

Voir ici : http://www.openstreetmap.org/relation/5430194
Je m'attends à récupérer une ligne toute simple sans les deux 
polygones aux extrémités. C'est la seule géométrie "simple" et 
représentative qu'on puisse exploiter sans faire appel à des 
FeatureCollections ou autre.


Et ça me semble très dur de trouver une méthode générique qui puisse 
faire cette synthèse parce qu'il semble qu'il y ait autant de 
possibilités que de cas :'(


François

Le 22 août 2016 à 14:45, Philippe Verdy > a écrit :


Le site web OSM le fait déjà quand on "explore" une relation: ça
télécharge un jeu de données JSON permettant le rendu vectoriel de
l'objet sélectionné par dessus le fond de carte. La Wikipédie
francophone le fait aussi sur ses cartes (mais elle requête son
propre serveur pour obtenir aussi des POIs géolocalisés sur
Wikipédia ou des photos géolocalisées sur Commons)
Attention en cas d'inclusion dans un script web : l'API ne doit
pas surcharger le serveur interrogé (on a vu le problème ces
jours-ci sur Overpass API avec des centaines de milliers de
requêtes par heure au lieu de quelques dizaines habituellement,
deux serveurs Overpass API sont tombés plusieurs fois de suite,
peut-être à cause d'un script d'un réseau publicitaire abusif ou
d'une appli non-officielle type Pokemon).
Bref gérer des caches sur votre serveur et éviter de faire des
requêtes automatiques en boucle par le client sur chaque page web
du site ou chaque page de l'appli mobile, respecter les protocoles !


Le 22 août 2016 à 14:30, François Lacombe
> a
écrit :

Bonjour à tous,

Avec la récente mise en place et adoption croissante d'open
event database, je me pose une question que certains ont déjà
du résoudre.

Existe-t-il une méthode générique pour convertir une relation
OSM en geojson ?
Cela reviendrait à convertir la relation en géométrie simple
(points / polyline).

Le besoin est d'attribuer une géométrie représentative à des
événements dégagés par des ouvrages décrit avec une relation.
Après on peut les envoyer sur open event db.

Mais il peut y avoir des tonnes d'autres usages à cela, sans
se limiter à cet exemple.

J'aimerais éviter les scripts avec des if/else à rallonge pour
cibler tel ou tel type de relation, à la recherche de tel ou
tel objet qui au final n'est pas forcé de se trouver là où on
l'attend, etc...


Merci par avance pour vos retours

François


--
*François Lacombe*

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

___
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



--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Extraire une géométrie représentative d'une relation

2016-08-22 Par sujet François Lacombe 
Bonjour Philippe, Guillaume,

Personne n'est a coté de la plaque ;)

Cependant, seule la méthode m’intéresse.
En effet il y a déjà quelques outils qui parviennent à présenter
graphiquement une relation mais j'ai besoin de l'implémenter de mon côté.

Relativement à l'exemple du résultat d'OSM.org. Il n'emploie pas une
géométrie unique. Il affiche tous les objets de la relation et c'est vite
le fouillis, en plus de devoir être découpé pour être intégré dans du
geojson.
Voir ici : http://www.openstreetmap.org/relation/5430194
Je m'attends à récupérer une ligne toute simple sans les deux polygones aux
extrémités. C'est la seule géométrie "simple" et représentative qu'on
puisse exploiter sans faire appel à des FeatureCollections ou autre.

Et ça me semble très dur de trouver une méthode générique qui puisse faire
cette synthèse parce qu'il semble qu'il y ait autant de possibilités que de
cas :'(

François

Le 22 août 2016 à 14:45, Philippe Verdy  a écrit :

> Le site web OSM le fait déjà quand on "explore" une relation: ça
> télécharge un jeu de données JSON permettant le rendu vectoriel de l'objet
> sélectionné par dessus le fond de carte. La Wikipédie francophone le fait
> aussi sur ses cartes (mais elle requête son propre serveur pour obtenir
> aussi des POIs géolocalisés sur Wikipédia ou des photos géolocalisées sur
> Commons)
> Attention en cas d'inclusion dans un script web : l'API ne doit pas
> surcharger le serveur interrogé (on a vu le problème ces jours-ci sur
> Overpass API avec des centaines de milliers de requêtes par heure au lieu
> de quelques dizaines habituellement, deux serveurs Overpass API sont tombés
> plusieurs fois de suite, peut-être à cause d'un script d'un réseau
> publicitaire abusif ou d'une appli non-officielle type Pokemon).
> Bref gérer des caches sur votre serveur et éviter de faire des requêtes
> automatiques en boucle par le client sur chaque page web du site ou chaque
> page de l'appli mobile, respecter les protocoles !
>
>
> Le 22 août 2016 à 14:30, François Lacombe  a
> écrit :
>
>> Bonjour à tous,
>>
>> Avec la récente mise en place et adoption croissante d'open event
>> database, je me pose une question que certains ont déjà du résoudre.
>>
>> Existe-t-il une méthode générique pour convertir une relation OSM en
>> geojson ?
>> Cela reviendrait à convertir la relation en géométrie simple (points /
>> polyline).
>>
>> Le besoin est d'attribuer une géométrie représentative à des événements
>> dégagés par des ouvrages décrit avec une relation.
>> Après on peut les envoyer sur open event db.
>>
>> Mais il peut y avoir des tonnes d'autres usages à cela, sans se limiter à
>> cet exemple.
>>
>> J'aimerais éviter les scripts avec des if/else à rallonge pour cibler tel
>> ou tel type de relation, à la recherche de tel ou tel objet qui au final
>> n'est pas forcé de se trouver là où on l'attend, etc...
>>
>>
>> Merci par avance pour vos retours
>>
>> François
>>
>>
>> --
>> *François Lacombe*
>>
>> fl dot infosreseaux At gmail dot com
>> www.infos-reseaux.com
>> @InfosReseaux 
>>
>> ___
>> 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] Extraire une géométrie représentative d'une relation

2016-08-22 Par sujet Philippe Verdy 
Le site web OSM le fait déjà quand on "explore" une relation: ça télécharge
un jeu de données JSON permettant le rendu vectoriel de l'objet sélectionné
par dessus le fond de carte. La Wikipédie francophone le fait aussi sur ses
cartes (mais elle requête son propre serveur pour obtenir aussi des POIs
géolocalisés sur Wikipédia ou des photos géolocalisées sur Commons)
Attention en cas d'inclusion dans un script web : l'API ne doit pas
surcharger le serveur interrogé (on a vu le problème ces jours-ci sur
Overpass API avec des centaines de milliers de requêtes par heure au lieu
de quelques dizaines habituellement, deux serveurs Overpass API sont tombés
plusieurs fois de suite, peut-être à cause d'un script d'un réseau
publicitaire abusif ou d'une appli non-officielle type Pokemon).
Bref gérer des caches sur votre serveur et éviter de faire des requêtes
automatiques en boucle par le client sur chaque page web du site ou chaque
page de l'appli mobile, respecter les protocoles !


Le 22 août 2016 à 14:30, François Lacombe  a
écrit :

> Bonjour à tous,
>
> Avec la récente mise en place et adoption croissante d'open event
> database, je me pose une question que certains ont déjà du résoudre.
>
> Existe-t-il une méthode générique pour convertir une relation OSM en
> geojson ?
> Cela reviendrait à convertir la relation en géométrie simple (points /
> polyline).
>
> Le besoin est d'attribuer une géométrie représentative à des événements
> dégagés par des ouvrages décrit avec une relation.
> Après on peut les envoyer sur open event db.
>
> Mais il peut y avoir des tonnes d'autres usages à cela, sans se limiter à
> cet exemple.
>
> J'aimerais éviter les scripts avec des if/else à rallonge pour cibler tel
> ou tel type de relation, à la recherche de tel ou tel objet qui au final
> n'est pas forcé de se trouver là où on l'attend, etc...
>
>
> Merci par avance pour vos retours
>
> François
>
>
> --
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
>
> ___
> 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] Extraire une géométrie représentative d'une relation

2016-08-22 Par sujet Guillaume AMAT 

Bonjour François,

Je ne suis pas sûr de maîtriser tous les aspects subtils de ta question 
mais est-ce que MapContrib ne pourrait pas répondre à ton besoin ? (En 
tout cas pour tester).


Il suffirait d'aller sur un thème (ou de le créer c'est pas bien 
important), de créer une couche temporaire de type OverPass et de lui 
attribuer une requête qui va chercher ta relation.


Elle va afficher le résultat sur la carte et tu pourras télécharger le 
GeoJSON en allant dans la colonne de sélection des couches (bouton blanc 
à gauche). Tu cliques sur « En savoir plus » et tu as un bouton de 
téléchargement tout en bas.


Bon évidemment, si je suis à côté de la plaque tu passes ton chemin 
hein... ;P


Guillaume


Le 22/08/2016 14:30, François Lacombe a écrit :

Bonjour à tous,

Avec la récente mise en place et adoption croissante d'open event
database, je me pose une question que certains ont déjà du
résoudre.

Existe-t-il une méthode générique pour convertir une relation OSM
en geojson ?
Cela reviendrait à convertir la relation en géométrie simple
(points / polyline).

Le besoin est d'attribuer une géométrie représentative à des
événements dégagés par des ouvrages décrit avec une relation.
Après on peut les envoyer sur open event db.

Mais il peut y avoir des tonnes d'autres usages à cela, sans se
limiter à cet exemple.

J'aimerais éviter les scripts avec des if/else à rallonge pour
cibler tel ou tel type de relation, à la recherche de tel ou tel
objet qui au final n'est pas forcé de se trouver là où on l'attend,
etc...

Merci par avance pour vos retours

François

--

FRANÇOIS LACOMBE

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com [1]
@InfosReseaux [2]

Links:
--
[1] http://www.infos-reseaux.com
[2] http://www.twitter.com/InfosReseaux

___
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] Extraire une géométrie représentative d'une relation

2016-08-22 Par sujet François Lacombe 
Bonjour à tous,

Avec la récente mise en place et adoption croissante d'open event database,
je me pose une question que certains ont déjà du résoudre.

Existe-t-il une méthode générique pour convertir une relation OSM en
geojson ?
Cela reviendrait à convertir la relation en géométrie simple (points /
polyline).

Le besoin est d'attribuer une géométrie représentative à des événements
dégagés par des ouvrages décrit avec une relation.
Après on peut les envoyer sur open event db.

Mais il peut y avoir des tonnes d'autres usages à cela, sans se limiter à
cet exemple.

J'aimerais éviter les scripts avec des if/else à rallonge pour cibler tel
ou tel type de relation, à la recherche de tel ou tel objet qui au final
n'est pas forcé de se trouver là où on l'attend, etc...


Merci par avance pour vos retours

François


--
*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr