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 <http://www.infos-reseaux.com>
@InfosReseaux <http://www.twitter.com/InfosReseaux>
Le 22 août 2016 à 16:45, Christian Quest <cqu...@openstreetmap.fr
<mailto: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 <http://www.openstreetmap.org/relation/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
<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
<mailto: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 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
<fl.infosrese...@gmail.com
<mailto:fl.infosrese...@gmail.com>> 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 <http://www.infos-reseaux.com>
@InfosReseaux <http://www.twitter.com/InfosReseaux>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
<https://lists.openstreetmap.org/listinfo/talk-fr>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
<https://lists.openstreetmap.org/listinfo/talk-fr>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
<https://lists.openstreetmap.org/listinfo/talk-fr>
--
Christian Quest - OpenStreetMap France
_______________________________________________ Talk-fr mailing
list Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
<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
