Re: [OSM-talk-fr] Problème avec Achavi ?

2016-08-22 Par sujet Romain MEHUT 
Et j'imagine qu'on ne peut pas basculer sur overpass france ?

Romain

Le 22 août 2016 à 17:53, Pierre-Yves Berrard 
a écrit :

> Salut Romain,
>
> Cela semble être lié à un problème sur overpass-deutschland.
> https://lists.openstreetmap.org/pipermail/talk-fr/2016-August/081773.html
>
> PY
>
> Le 22 août 2016 à 17:34, Romain MEHUT  a écrit :
>
>> Bonjour à tous,
>>
>> J'ai une erreur quand je souhaites accéder par exemple à
>> https://overpass-api.de/achavi/?changeset=41599519
>>
>> Pourtant le changeset existe bien.
>>
>> Avez-vous connaissance d'un problème du côté du service achavi ?
>>
>> Merci.
>>
>> Romain
>>
>> ___
>> 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 
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] Problème avec Achavi ?

2016-08-22 Par sujet Pierre-Yves Berrard 
Salut Romain,

Cela semble être lié à un problème sur overpass-deutschland.
https://lists.openstreetmap.org/pipermail/talk-fr/2016-August/081773.html

PY

Le 22 août 2016 à 17:34, Romain MEHUT  a écrit :

> Bonjour à tous,
>
> J'ai une erreur quand je souhaites accéder par exemple à
> https://overpass-api.de/achavi/?changeset=41599519
>
> Pourtant le changeset existe bien.
>
> Avez-vous connaissance d'un problème du côté du service achavi ?
>
> Merci.
>
> Romain
>
> ___
> 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] Problème avec Achavi ?

2016-08-22 Par sujet Romain MEHUT 
Bonjour à tous,

J'ai une erreur quand je souhaites accéder par exemple à
https://overpass-api.de/achavi/?changeset=41599519

Pourtant le changeset existe bien.

Avez-vous connaissance d'un problème du côté du service achavi ?

Merci.

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

[OSM-talk-fr] Contribution à OpenStreetMap sur Android

2016-08-22 Par sujet loic ortola 
Bonjour à tous,

il y a un peu plus d'un an, on a lancé OSM Contributor, une appli
Android de contribution à OSM.
Après un StateOfTheMap FR très encourageant, l'équipe a décidé de
tordre le cou à la roadmap inspirée par de nombreux membres de la
communauté (merci à eux), et de préparer une nouvelle version de
l'appli.
Au menu:
- OAuth et Sign-in with Google
- Fonds de carte vectoriels
- Détection de type de données et widgets adaptés (horaires, date, etc...)
- Marketplace Opensource pour ajouter des presets (un mode dégradé
permettant à des utilisateurs non techniques de contribuer de façon
fléchée et SIMPLE) (https://github.com/jawg/h2geo-presets)
- Beaucoup d'améliorations de l'expérience utilisateur
- Mode hors-ligne (possibilité de charger des régions hors-ligne)
- Duplication de POI
- Amélioration du crawler h2geo (https://github.com/jawg/h2geo)

On souhaite release la version majeure pour le State-Of-The-Map à
Bruxelles, et recherchons des volontaires pour beta-tester
l'application avant sa sortie.

Si vous êtes tentés pour l'utiliser pour une Cartopartie ou juste pour
vous, on serait vraiment très heureux de pouvoir vous confier une
distribution et prendre vos retours.

Les types de retours qui nous sont chers:
- Love / Hate: les choses qui font sens, les choses qui ne servent à
rien, les nice to have, les choses appréciées, les choses géniales
- Bugs: Nous avons déjà un bug tracker, mais il ne filtre évidemment pas tout
- Feature requests: Des choses qui manquent et que vous voudriez, ou
que vous voyiez de manière différente.

L'objectif d'OSM Contributor, c'est de "réduire le cout d'entrée à
OpenStreetMap" (pour paraphraser Christian Quest) et de permettre à
des utilisateurs débutants comme confirmés de contribuer sans blabla.

Merci infiniment pour ceux qui auront la patience de s'y intéresser,
n'hésitez pas à répondre à ce mail pour avoir votre accès à la beta.

Screenshot:
https://twitter.com/jawgio/status/767731944964644865

Loïc

___
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 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] Saisie d'une entité bâtiment avec différents services

2016-08-22 Par sujet David Crochet 

Bonjour


Le 22/08/2016 à 15:22, Adrets-Guillaume a écrit :

D'avance merci pour votre retour


Pas mieux pour un premier jet.

Cordialement

--
David Crochet


___
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

[OSM-talk-fr] Saisie d'une entité bâtiment avec différents services

2016-08-22 Par sujet Adrets-Guillaume 

Bonjour,

En tant que contributeur OSM plutôt débutant, mais travaillant dans une 
association spécialisée sur les services au public en montagne, nous 
aimerions travailler sur la saisie de ces services au public dans 
OpenStreetMap, notamment traiter le cas des maisons de service au public.


J'aurais voulu avoir des conseils sur les bonnes pratiques de saisie 
pour ces lieux particuliers :
- 1 maison de service au public a un nom, correspond à un bâtiment, et a 
des horaires d'ouverture et des coordonnées.
- elle accueille différents services, souvent sous forme de permanence 
(CAF, PoleEmploi...) qui ont donc chacune un nom et des horaires 
spécifiques, a minima.


Voici la manière dont j'imaginais les traiter :

Au niveau de l'area

building = public

amenity = social_facility

name = Msap XXX

website=

phone=

email =

opening_hours (Mo-Fr 09:00-12:00,13:30-17:00) + opening_hours:url


Rajouter un point par service proposé dans le bâtiment avec les attributs

name = Service XXX

Amenity = social_facility

social_facility =XXX

social_facility:for =XXX

opening_hours = (/pour les permanences)/



D'avance merci pour votre retour


--
Signature Guillaume-Adrets Guillaume Doukhan
ADRETS - Association pour le Développement en Réseau des Territoires et 
des Services

7 rue Bayard
05 000 Gap
Tel : 04 92 51 07 19
http://www.adrets-asso.fr 

Recevez la newsletter de l'ADRETS ! 
___
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