Re: [OSM-talk-fr] OpenStreetMap en famille : un jeu de société

[Christian Quest]

C'est une magnifique réutilisation des données OSM !

ça mérite une bonne place sur le wiki.osm.org, non ?

Le 22 juin 2016 à 21:22, DH  a écrit :

> Le 22/06/2016 19:37, JB a écrit :
>
>> Bonjour,
>>
>> J'ai continué l'aventure des cathédrales, avec cette fois, un (premier ?)
>> jeu de société à base d'OSM : le mémory des cathédrales. Il est arrivé
>> aujourd'hui dans la boite aux lettres, on s'est empressés de l'essayer avec
>> ma compagne. Pas de doute, il est tout à fait jouable : 72 cartes, soit 35
>> cathédrales, une carte avec l'échelle et les crédits. Une photo est visible
>> ici : http://jb.isonoe.net/demo/Jeu_cathedrales.jpg
>>
>> Rapidement, la démarche de fabrication : comme une partie mémory à près
>> de 200 paires risquerait d'être un peu longue à terminer, il a bien fallu
>> trouver un mode de sélection des édifices à conserver. Le plus neutre que
>> j'ai trouvé : les plus grandes (en surface). Alors, pour trier ça:
>> (pour les références, voir le mél précédent intitulé « Nouvelle affiche
>> disponible : on s'amuse avec les cathédrales ! » du 13/6)
>>  - calcul des surfaces : importation du fichier .osm des cathédrales dans
>> QGIS, compléter la table attributaire avec la surface (auparavant, pour les
>> brelles, comprendre pourquoi cette table attributaire ne veut pas passer en
>> mode édition),
>>  - exporter la partie intéressante de la table attributaire :
>> l'identifiant des objets et leur surface,
>>  - ajouter l'information de surface aux éléments du fichier .osm
>> (mini-script python qui cherche l'id de l'élément dans la table),
>>  - ressortir un fichier avec les cathédrales « au carré » mais triées
>> cette fois par surface décroissante (modification à la marge du script de
>> l'affiche),
>>  - exporter un petit png centré sur chaque cathédrale.
>> Sur les conseils design de ma compagne, le gris morose des bâtiments de
>> la feuille de style est passé à un vague sépia, la boite du jeu est
>> conseillée en bleu.
>> On envoie tout ça à un fabricant de jeux à la demande, et hop, dans la
>> boite aux lettres (en passant par la case carte bleue).
>>
>> Alors, après réception, il y aurait quelques ajustements à faire (le
>> calage chez le fabricant n'est pas parfait, du coup, le dessin frôle les
>> bordures dans certains cas… et cette fichue cathédrale de Marseille qui se
>> prend des envies de longueurs !), voir à ajouter un fond de couleur à la
>> place du blanc, et puis trouver un fabricant qui propose un dos de cartes
>> un peu plus élégant… Pour une version zéro, c'est pas vilain.
>>
>> Voilà voilà, bonne soirée,
>>
>>
>> Je suggère à la liste d'élever JB au titre de "troubadour de la donnée
> géoréférencée".
> Bravo JB pour ta créativité.
>
> Denis, auditeur attentif des Fabulous_Trobadors (
> https://fr.wikipedia.org/wiki/Fabulous_Trobadors)
>
>
>
>
>
> ___
> 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] Crédits API BAN sur api.gouv.fr

[Christian Quest]

OSM est bien cité sur la page. Sur la BAN, OSM n'a pas un rôle aussi majeur
et la présentation de cette page ne me choque pas (par contre, je sais que
l'inverse choquerait).

L'apport en données est actuellement IGN+Poste, et bien entendu pas de
données OSM car la base n'étant pas diffusée qu'en ODbL ce ne serait pas
possible. Quand on aura le moyen de contribuer vraiment à la base (on y
travaille, croyez moi) on pourra le revoir.

Vu que les relations sont encore un peu compliquées, inutile de crisper un
peu plus...


Le 22 juin 2016 à 16:52, Nicolas Moyroud  a écrit :

> Salut à tous,
>
> Sur la page de l'API BAN (
> https://api.gouv.fr/api/base-adresse-nationale.html) je trouve qu'il
> manque la mention "OpenStreetMap France" dans le petit cartouche "Sources
> et partenaires". Certes cela est indiqué dans le texte de description mais
> bon il n'y a pas de raison de mettre La Poste et l'IGN dans la liste des
> partenaires et pas OSM France...
> Je peux les contacter personnellement pour leur signaler mais je pense que
> ça aura plus d'effet si un des big boss OSM France s'en charge. ;-)
>
> Nicolas
>
>
> ___
> 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] ***SPAM*** Re: Majuscule à l'article défini sur les lieux-dits ?

[Jérôme Seigneuret]

Bonsoir,

J'interviens que tard sur un sujet déjà bien tordu.

En clair on va se prendre la tête à reprendre une manière de représenter
les choses qui ne correspondent qu'à une manière de penser ou de concevoir
les étiquettes d'une carte.

Le type de lieudit est caractérisé par des clés (son caractère officiel ou
officieux... je vois pas trop en quoi cela joue sur l'orthographe)

Bref il me semble que de toute façon le name est à saisir en "mixed case"
et c'est pas osmose qui parle de cela.
Si cela pose problème il faudrait plutôt réfléchir à en parler sur la liste
talk et définir un usage spécifique si c'est le cas et/changer les règles
concernant le mixed case.

C'est sur que pour exploiter des termes dans une phrase si la saisie
correspond à une majuscule et pas à une capitale, il est assez facile de
faire les accords "à le" > "au" . A contrario "à Le" restera "à Le"

Cela demande de revoir l'exploitation du champs name pour la France et les
règles de saisie le cas échéant. Mais cela répond à des règles
orthographiques et non à un délire typographique pour identifier les
hameaux et les lieudits.

Le champs name et name:fr s'ils sont remplis doivent être identique (la
casse aussi)
Le problème du "mixed case" c'est l'exploitation et la différenciation
entre les termes capitalisés et les terme réellement en majuscule. Cela
rend problématique l'exploitation de sigle et les accord dans les phrases.

Créer une autre clé... Je comprends pas pourquoi.
Surtout qu'il me semble assez simple de faire un post traitement pour le
rendu comme c'est le cas pour le rendu humanitaire.

Jérôme.


Le 22 juin 2016 à 20:54, Christian Rogel 
a écrit :

>
> Le 22 juin 2016 à 10:30, Philippe Verdy  a écrit :
>
> Le 22 juin 2016 à 02:41, Christian Rogel  > a écrit :
>
>>
>> > L'approche choisie par Osmose contredit la règle édictée par
>> > OpenStreetMap. Tant que ceci n'est pas résolu dans un sens où dans
>> > l'autre il y a un problème.
>> >
>> https://wiki.openstreetmap.org/wiki/FR:Toponymes,_odonymes#Toponymes_officiels_et_non-officiels
>>
>> Les codeurs d’Osmose ont, ici, bien senti où sont le sens commun et la
>> vraie vie
>>
>
> Ils ont surtout senti leur propre volonté d'imposer une norme inventée de
> toute pièce qui oublie complètement qu'en français et dans l'écriture latin
> en général la casse est signifiante, juste pour une prétendue volonté
> d'homogénéité sur un rendu. Hors ce n'est pas à la base de données
> d'impsoer cette règle de rendu, si volonté il y a de faire un rendu
> homogène.
>
> Ces noms ont des usages autres que pour produire une carte. Ce sont des
> données, pas la carte elle-même.
>
> Le pragmatisme a bon dos ! Ici Osmose veut taguer pour le rendu, et ses
> auteurs ne veulent simplement pas l'admettre ! Ce n'est pas à Osmose de
> corirger ça, c'est au rendu mapnik de forcer une capitale initiale, si ça
> lui plaint mieux. On n'a aboslument pas à supposer que ces noms sont
> destinés uniquemetn à une utilisation isolée (dans une "phrase nominale"
> uniquement).
>
>
> Quand je parle d’un usage datant de l’administration française du temps de
> la plume d’oie, je pointe le fait que la minuscule était d’usage dans les
> actes manuscrits des notaires ("un champ sis près du village de l’Épine").
> Cette pratique reflétait la nouveauté qu’était la majuscule (au Moyen-Äge,
> on ne l’utilisait pas).
> Avec l’arrivée de l’imprimerie, l’emploi des capitales est plus simple et
> c’est pourquoi l’État trouve avantage à les prescrire pour les noms de lieu
> qui sont sous sa juridiction.
> Mais, on se contente de transformer les minuscules en bas-de-casse, car,
> cela, au fond, aucune incidence pratique.
> L’IGN, emporté par son élan, se met à capitaliser sur ses cartes le tou
> venant des noms de lieu. Il suit, en cela, une tendance de fond, que nous
> voyons partout sur nos routes, avec validation ou non de l’État.
> Eh, bien, on a pu trouver des membres arriérés du CNIG pour continuer à
> maintenir la guéguerre, afin de bien marquer les limites (de classe ?), en
> invoquant un « usage » fanstasmatique.
>
> OSM mérite mieux que ces escarmouches d’arrière-garde.
>
>
>
> Christian R.
>
> ___
> 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] path, cycleway et footway

[Eric SIBERT]

Le 22/06/2016 à 23:26, Tony Emery a écrit :

Ok mais, ça ne m'explique pas pourquoi on utilise QUE le tag highway=path


Parce que highway=path est un chemin générique quand rien d'autre ne 
convient. Comme la voie verte qui n'est pas principalement une voie 
cyclable ni une voie piétonne.


Ça a déjà été discuté sur la liste:
https://lists.openstreetmap.org/pipermail/talk-fr/2014-March/066949.html

Malheureusement, le wiki n'a effectivement mis que partiellement à jour 
pour tenir compte de cette discussion.


Eric


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

Re: [OSM-talk-fr] path, cycleway et footway

[Tony Emery]

Ok mais, ça ne m'explique pas pourquoi on utilise QUE le tag highway=path
pour désigner une voie verte.


Tony Emery wrote
> Ça me gêne un peu car, au final, rien de distingue une voie verte de
> n'importe quel autre chemin (allée piétonne d'une résidence, chemin
> urbain, chemin de forêt,...)
> 
> Pourtant, la voie verte a une existence et une particularité légale qui
> mérite, au même titre que la zone 30 (highway=living_street), un tag
> spécifique.
> 
> Même si on ajoute d'autres tag comme bicycle, foot ou surface, rien
> n'indiquerait qu'il s'agisse spécifiquement d'une voie verte.





-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/path-cycleway-et-footway-tp5876181p5876242.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] path, cycleway et footway

[Jérôme Seigneuret]

>
>
>> */designated/* a été créer pour définir un usage obligatoire pour des
>> usagers spécifiques (le panneaux de ségrégation implique cet usage).
>> Donc le */yes/* suffit amplement car une voie verte n'impose pas de ne
>> pas utiliser une route adjacente. C'est complètement inutile de surcharger
>> la clé */foot/* et *bicycle *pour ajouter cette information sens le
>> contexte obligatoire. Il y a déjà des règles prédéfinies pour cela. Pour
>> les vélo il y a une clé à mettre sur la route d'ailleurs*/
>> bicycle=use_sidepath/*
>>
>
> Je ne suis pas d'accord sur designated, il n'implique aucune obligation,
> il signifie juste que le chemin est explicitement dédié à un type de moyen
> de transport particulier, donc designated est bien la bonne valeur a
> utiliser pour les voies vertes (on pourrait même utiliser la valeur
> "official" plus forte que designated)
>
>
En effet obligatoire c'est une connerie ... Je suis allé un peu fort.

Mais en aucun cas le panneau voie verte ne désigne un usage et une
conception spécifique ou explicite pour un mode de transport particulier.
Le code de la route dit

*Interdiction pour les véhicules motorisés de circuler et de stationner sur
une voie verte*
Il n'y a rien de plus.

Certains panneau désigne clairement des usages. On a bien le même cas avec
les zones de rencontre et les voies piétonnes. L'usage et commun régis par
le même code avec des règles communes sans désigner spécifiquement un mode
de transport (la désignation est trompeuse).

La Voie Verte a un rôle en développement durable, d'où cette engouement des
communes à mettre ce terme plutôt qu'un panneau:
"Interdit aux voitures, motos et cyclomoteurs"
Je pense qu'il est aussi plus facile d'avoir des financements pour des
construction. (ça a un effet image de qualité)

Quand à official? C'est quoi l'intérêt? On va le mettre sur tous les types
transports car la circulation en France à forcément un caractère officielle
quelque-soit le mode de transport. De plus les règles de circulation ne
change pas et il n'y a pas de code de la route différent pour l'ensemble
des modes de circulations en France. Le code est unique.
La différence entre yes et official est complètement inutile. Pour moi yes
c'est officiel et no c'est aussi officiel.

yes : *The public has an official, legally-enshrined right of access*

La voie de vélo est clairement faite pour un usage :


   - Le cas de la voie cyclable sans caractère obligatoirepour
   - la voie cyclable : highway=cycleway (bicycle=designated étant la
  valeur par défaut donc inutile)
  - pour la voie routière : highway=residential + bicycle=discouraged
   - Le cas de la voie cyclable avec caractère obligatoire
   - pour la voie cyclable : highway=cycleway (bicycle=designated étant la
  valeur par défaut donc inutile)
  - pour la voie routière : highway=residential + bicycle=use_sidepath


Dans le cas où la voie vélo et piétonne est partagée, la voie est faite
pour les vélos et donc il y a un usage explicite pour que le cycliste
respecte le partage de sa voie avec la circulation piétonne. Ça change donc
le code de la circulation
d'ou l'ajout de foot=yes dans ce cas précis (ou designated).

Les cas de circulation en trail (pour les itinéraires de montagne pas
exemple) les panneaux entre dans d'autres considérations mais reste sur le
principe de partage de la voies avec des indications spécifiques à un
ensembles d'occupants

Bonne soirée
Jérôme
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OpenStreetMap en famille : un jeu de société

[DH]

Le 22/06/2016 19:37, JB a écrit :

Bonjour,

J'ai continué l'aventure des cathédrales, avec cette fois, un (premier 
?) jeu de société à base d'OSM : le mémory des cathédrales. Il est 
arrivé aujourd'hui dans la boite aux lettres, on s'est empressés de 
l'essayer avec ma compagne. Pas de doute, il est tout à fait jouable : 
72 cartes, soit 35 cathédrales, une carte avec l'échelle et les 
crédits. Une photo est visible ici : 
http://jb.isonoe.net/demo/Jeu_cathedrales.jpg


Rapidement, la démarche de fabrication : comme une partie mémory à 
près de 200 paires risquerait d'être un peu longue à terminer, il a 
bien fallu trouver un mode de sélection des édifices à conserver. Le 
plus neutre que j'ai trouvé : les plus grandes (en surface). Alors, 
pour trier ça:
(pour les références, voir le mél précédent intitulé « Nouvelle 
affiche disponible : on s'amuse avec les cathédrales ! » du 13/6)
 - calcul des surfaces : importation du fichier .osm des cathédrales 
dans QGIS, compléter la table attributaire avec la surface 
(auparavant, pour les brelles, comprendre pourquoi cette table 
attributaire ne veut pas passer en mode édition),
 - exporter la partie intéressante de la table attributaire : 
l'identifiant des objets et leur surface,
 - ajouter l'information de surface aux éléments du fichier .osm 
(mini-script python qui cherche l'id de l'élément dans la table),
 - ressortir un fichier avec les cathédrales « au carré » mais triées 
cette fois par surface décroissante (modification à la marge du script 
de l'affiche),

 - exporter un petit png centré sur chaque cathédrale.
Sur les conseils design de ma compagne, le gris morose des bâtiments 
de la feuille de style est passé à un vague sépia, la boite du jeu est 
conseillée en bleu.
On envoie tout ça à un fabricant de jeux à la demande, et hop, dans la 
boite aux lettres (en passant par la case carte bleue).


Alors, après réception, il y aurait quelques ajustements à faire (le 
calage chez le fabricant n'est pas parfait, du coup, le dessin frôle 
les bordures dans certains cas… et cette fichue cathédrale de 
Marseille qui se prend des envies de longueurs !), voir à ajouter un 
fond de couleur à la place du blanc, et puis trouver un fabricant qui 
propose un dos de cartes un peu plus élégant… Pour une version zéro, 
c'est pas vilain.


Voilà voilà, bonne soirée,


Je suggère à la liste d'élever JB au titre de "troubadour de la donnée 
géoréférencée".

Bravo JB pour ta créativité.

Denis, auditeur attentif des Fabulous_Trobadors 
(https://fr.wikipedia.org/wiki/Fabulous_Trobadors)





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

Re: [OSM-talk-fr] ***SPAM*** Re: Majuscule à l'article défini sur les lieux-dits ?

[Christian Rogel]

> Le 22 juin 2016 à 10:30, Philippe Verdy  a écrit :
> 
> Le 22 juin 2016 à 02:41, Christian Rogel  > a écrit :
> 
> > L'approche choisie par Osmose contredit la règle édictée par
> > OpenStreetMap. Tant que ceci n'est pas résolu dans un sens où dans
> > l'autre il y a un problème.
> > https://wiki.openstreetmap.org/wiki/FR:Toponymes,_odonymes#Toponymes_officiels_et_non-officiels
> >  
> > 
> 
> Les codeurs d’Osmose ont, ici, bien senti où sont le sens commun et la vraie 
> vie
> 
> Ils ont surtout senti leur propre volonté d'imposer une norme inventée de 
> toute pièce qui oublie complètement qu'en français et dans l'écriture latin 
> en général la casse est signifiante, juste pour une prétendue volonté 
> d'homogénéité sur un rendu. Hors ce n'est pas à la base de données d'impsoer 
> cette règle de rendu, si volonté il y a de faire un rendu homogène.
> 
> Ces noms ont des usages autres que pour produire une carte. Ce sont des 
> données, pas la carte elle-même.
> 
> Le pragmatisme a bon dos ! Ici Osmose veut taguer pour le rendu, et ses 
> auteurs ne veulent simplement pas l'admettre ! Ce n'est pas à Osmose de 
> corirger ça, c'est au rendu mapnik de forcer une capitale initiale, si ça lui 
> plaint mieux. On n'a aboslument pas à supposer que ces noms sont destinés 
> uniquemetn à une utilisation isolée (dans une "phrase nominale" uniquement).
> 

Quand je parle d’un usage datant de l’administration française du temps de la 
plume d’oie, je pointe le fait que la minuscule était d’usage dans les actes 
manuscrits des notaires ("un champ sis près du village de l’Épine").
Cette pratique reflétait la nouveauté qu’était la majuscule (au Moyen-Äge, on 
ne l’utilisait pas).
Avec l’arrivée de l’imprimerie, l’emploi des capitales est plus simple et c’est 
pourquoi l’État trouve avantage à les prescrire pour les noms de lieu qui sont 
sous sa juridiction.
Mais, on se contente de transformer les minuscules en bas-de-casse, car, cela, 
au fond, aucune incidence pratique.
L’IGN, emporté par son élan, se met à capitaliser sur ses cartes le tou venant 
des noms de lieu. Il suit, en cela, une tendance de fond, que nous voyons 
partout sur nos routes, avec validation ou non de l’État.
Eh, bien, on a pu trouver des membres arriérés du CNIG pour continuer à 
maintenir la guéguerre, afin de bien marquer les limites (de classe ?), en 
invoquant un « usage » fanstasmatique.

OSM mérite mieux que ces escarmouches d’arrière-garde.



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

Re: [OSM-talk-fr] path, cycleway et footway

[Tyndare]

On 22/06/2016 17:43, Jérôme Seigneuret wrote:


*/designated/* a été créer pour définir un usage obligatoire pour des 
usagers spécifiques (le panneaux de ségrégation implique cet usage).
Donc le */yes/* suffit amplement car une voie verte n'impose pas de ne 
pas utiliser une route adjacente. C'est complètement inutile de 
surcharger la clé */foot/* et *bicycle *pour ajouter cette information 
sens le contexte obligatoire. Il y a déjà des règles prédéfinies pour 
cela. Pour les vélo il y a une clé à mettre sur la route 
d'ailleurs*/ bicycle=use_sidepath/*


Je ne suis pas d'accord sur designated, il n'implique aucune obligation, 
il signifie juste que le chemin est explicitement dédié à un type de 
moyen de transport particulier, donc designated est bien la bonne valeur 
a utiliser pour les voies vertes (on pourrait même utiliser la valeur 
"official" plus forte que designated)



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

[OSM-talk-fr] OpenStreetMap en famille : un jeu de société

[JB]

Bonjour,

J'ai continué l'aventure des cathédrales, avec cette fois, un (premier 
?) jeu de société à base d'OSM : le mémory des cathédrales. Il est 
arrivé aujourd'hui dans la boite aux lettres, on s'est empressés de 
l'essayer avec ma compagne. Pas de doute, il est tout à fait jouable : 
72 cartes, soit 35 cathédrales, une carte avec l'échelle et les crédits. 
Une photo est visible ici : http://jb.isonoe.net/demo/Jeu_cathedrales.jpg


Rapidement, la démarche de fabrication : comme une partie mémory à près 
de 200 paires risquerait d'être un peu longue à terminer, il a bien 
fallu trouver un mode de sélection des édifices à conserver. Le plus 
neutre que j'ai trouvé : les plus grandes (en surface). Alors, pour 
trier ça:
(pour les références, voir le mél précédent intitulé « Nouvelle affiche 
disponible : on s'amuse avec les cathédrales ! » du 13/6)
 - calcul des surfaces : importation du fichier .osm des cathédrales 
dans QGIS, compléter la table attributaire avec la surface (auparavant, 
pour les brelles, comprendre pourquoi cette table attributaire ne veut 
pas passer en mode édition),
 - exporter la partie intéressante de la table attributaire : 
l'identifiant des objets et leur surface,
 - ajouter l'information de surface aux éléments du fichier .osm 
(mini-script python qui cherche l'id de l'élément dans la table),
 - ressortir un fichier avec les cathédrales « au carré » mais triées 
cette fois par surface décroissante (modification à la marge du script 
de l'affiche),

 - exporter un petit png centré sur chaque cathédrale.
Sur les conseils design de ma compagne, le gris morose des bâtiments de 
la feuille de style est passé à un vague sépia, la boite du jeu est 
conseillée en bleu.
On envoie tout ça à un fabricant de jeux à la demande, et hop, dans la 
boite aux lettres (en passant par la case carte bleue).


Alors, après réception, il y aurait quelques ajustements à faire (le 
calage chez le fabricant n'est pas parfait, du coup, le dessin frôle les 
bordures dans certains cas… et cette fichue cathédrale de Marseille qui 
se prend des envies de longueurs !), voir à ajouter un fond de couleur à 
la place du blanc, et puis trouver un fabricant qui propose un dos de 
cartes un peu plus élégant… Pour une version zéro, c'est pas vilain.


Voilà voilà, bonne soirée,

JB.

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

Re: [OSM-talk-fr] path, cycleway et footway

[Tony Emery]

Donc,

Si je comprends bien vos explications, on utilise le tag highway=path pour
désigner une voie verte.

Ça me gêne un peu car, au final, rien de distingue une voie verte de
n'importe quel autre chemin (allée piétonne d'une résidence, chemin urbain,
chemin de forêt,...)

Pourtant, la voie verte à une existence et une particularité légale qui
mérite, au même titre que la zone 30 (highway=living_street), un tag
spécifique.

Même si on ajoute d'autres tag comme bicycle, foot ou surface, rien
n'indiquerait qu'il s'agisse spécifiquement d'une voie verte.



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/path-cycleway-et-footway-tp5876181p5876216.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] path, cycleway et footway

[Jérôme Seigneuret]

Bonjour,

Une Voie Verte ne désigne en aucun cas un type de transport. Il interdit
cependant le passage de véhicule motorisé.

un *highway = path *c'est implicitement (voir le tableau suivant pour
comprendre

) *moped=yes + foot=yes + bicycle=yes + horse=yes *(en France)

Donc ajouter *motor_vehicle=no *est suffisant. Cependant, si
vous souhaitez informer sur la signalisation, il suffit d'ajouter
les panneaux concernant le tronçon en question en début et fin de voie
(comme pour les voies pour automobile dont le dilemme reste sur le choix
des éléments à renseigner)

Cependant un *path* permet *moped=yes*
Donc il faut restreindre plus les accès offerts par l'usage de cette clé en
ajoutant simplement
*motor_vehicle**=no*

*designated* a été créer pour définir un usage obligatoire pour des usagers
spécifiques (le panneaux de ségrégation implique cet usage). Donc le
*yes* suffit
amplement car une voie verte n'impose pas de ne pas utiliser une route
adjacente. C'est complètement inutile de surcharger la clé *foot* et
*bicycle *pour ajouter cette information sens le contexte obligatoire. Il y
a déjà des règles prédéfinies pour cela. Pour les vélo il y a une clé à
mettre sur la route d'ailleurs* bicycle=use_sidepath*

*Remarque : L'article R110-2 du code de la route spécifie que le terme de
piste cyclable désigne une chaussée exclusivement réservée aux cycles,
c'est-à-dire aux vélos*

Donc un* highway=cycleway* veut dire pas d'autre mode de transport que des
vélos donc pas de piétons
C'est donc un *bicycle=designated *toutes les autres clés ont pour valeur
*no*

*segregated = yes  *pour une Voie Verte c'est possible mais quand même bien
rare car il y a au moins 3 catégories (piéton, vélo, cheval) et dans un cas
de ségrégation on a une ligne blanche séparatrice et ce panneau

Le cas de la séparation en 3 j'ai pas vu encore ça...

Parcontre:
- voie verte + interdit au chevaux > oui
On se retrouve sur :
*highway = path +* *motor_vehicle=no + horse=no*
mais cela se rapproche de :
*highway = cycleway + foot = yes*

*Coté terrain*: la différence ce sont les panneaux. Donc si l'on se base
sur je cartographie ce que je vois, ce sera clairement le premier cas car
la signalisation n'est pas spécifique au vélo.
*Coté rendu carto*: il y a une différence... > à rectifier?
Coté réglementaire: en France pas de différence entre les deux propositions
il me semble.
*Coté exploitation*: Selon le type de route, il existe des profils de
vitesse
.
Donc à voir si entre les deux il y a des différences sur les outils
d'itinéraires. > Test à faire et vérifier les vitesses par défaut entre les
clés valeur path et cycleway et voir s'il y a des profils de vitesse avec
des couples par types de transport pour les usagers des voies vertes et des
voies cyclables.

De base c'est *segragated = no* et c'est implicitement la valeur par
défaut. Donc elle me semble inutile pour les Voies Vertes.
Même si elle est renseigné, je vois mal ou le cavalier doit se placer si le
passage à cheval n'est pas interdit...
Un oubli ou un choix de panneau mal réfléchi. Peut-être une mode pour les
Voies Vertes! C'est vrai que le terme est vendeur! ;-)

La surface est intéressante mais pas systématiquement en asphalt. C'est
aussi du pavé ou du stabilisé voir de la surface nu comme des passage en
sous-bois. (Pour les roller, le stabilisé c'est moyen.)

Je ne connais pas la surface par défaut; mais il me semble que pour toutes
les routes pour véhicule, la valeur est *surface=paved
** .* C'est aussi
valable avec *highway=track + tracktype=grade1*
Les autres sont normalement  *surface=unpaved
*  mais c'est une
valeur qui est défini est interprété par les outils si elle n'existe pas
avec des incidences sur les calculs d'itinéraires si la clé est exploitée.
Mais on est hors contexte
Il est donc très intéressant d'être plus clair en utilisant cette clé
surtout si l'on veut filtrer pour les rollers ou si tu veux courir avec le
gosse dans la poussette ;-) .

Bonne journée,
Jérôme


2016-06-22 17:27 GMT+02:00 Richard Fairhurst :

> Eric Sibert a écrit:
> > highway=path
> > bicycle=yes/designated
> > foot=yes/designated
> > segregated=yes
>
> Ajoutez un tag 'surface', svp :)
>
> Il y a trop de voies vertes en France sans 'surface'...
>
> Richard
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/path-cycleway-et-footway-tp5876181p5876208.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] path, cycleway et footway

[Richard Fairhurst]

Eric Sibert a écrit:
> highway=path
> bicycle=yes/designated
> foot=yes/designated
> segregated=yes

Ajoutez un tag 'surface', svp :)

Il y a trop de voies vertes en France sans 'surface'...

Richard



--
View this message in context: 
http://gis.19327.n5.nabble.com/path-cycleway-et-footway-tp5876181p5876208.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] Crédits API BAN sur api.gouv.fr

[osm . sanspourriel]

Soit Christian en parle lors d'une de ses réunions soit tu t'en charges.
Car il est bon que l'on comprenne aussi que même si on a des super big 
boss, il y a plein de monde derrière.


Jean-Yvon

Le 22/06/2016 à 16:52, Nicolas Moyroud - nmoyr...@free.fr a écrit :

Salut à tous,

Sur la page de l'API BAN 
(https://api.gouv.fr/api/base-adresse-nationale.html) je trouve qu'il 
manque la mention "OpenStreetMap France" dans le petit cartouche 
"Sources et partenaires". Certes cela est indiqué dans le texte de 
description mais bon il n'y a pas de raison de mettre La Poste et 
l'IGN dans la liste des partenaires et pas OSM France...
Je peux les contacter personnellement pour leur signaler mais je pense 
que ça aura plus d'effet si un des big boss OSM France s'en charge. ;-)


Nicolas


___
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] Crédits API BAN sur api.gouv.fr

[Nicolas Moyroud]

Salut à tous,

Sur la page de l'API BAN 
(https://api.gouv.fr/api/base-adresse-nationale.html) je trouve qu'il 
manque la mention "OpenStreetMap France" dans le petit cartouche 
"Sources et partenaires". Certes cela est indiqué dans le texte de 
description mais bon il n'y a pas de raison de mettre La Poste et l'IGN 
dans la liste des partenaires et pas OSM France...
Je peux les contacter personnellement pour leur signaler mais je pense 
que ça aura plus d'effet si un des big boss OSM France s'en charge. ;-)


Nicolas


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

Re: [OSM-talk-fr] path, cycleway et footway

[osm . sanspourriel]

Résumé :
highway=path
bicycle=designated
foot=designated
segregated=yes

Auquel j'ajoute ceux du wiki :
motor_vehicle 
=no 


surface =asphalt
En effet il faut mettre la surface la plus précise possible (paved est 
trop générique) et comme il y a des piquets ce n'est pas ouvert à la 
circulation automobile même riveraine.


Jean-Yvon

Le 22/06/2016 à 15:49, Tony Emery - tony.em...@yahoo.fr a écrit :

Ce serait pas mal de mettre à jour la page wiki highway=path parce que ce
n'est pas du tout intuitif !



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/path-cycleway-et-footway-tp5876181p5876196.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

Re: [OSM-talk-fr] path, cycleway et footway

[Tony Emery]

Ce serait pas mal de mettre à jour la page wiki highway=path parce que ce
n'est pas du tout intuitif !



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/path-cycleway-et-footway-tp5876181p5876196.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] path, cycleway et footway

[Romain MEHUT]

+1 avec Eric et designated pour les valeurs à foot et bicycle.

Romain

2016-06-22 14:46 GMT+02:00 Eric Sibert :

> (regardez bien le panneau) :
>> 
>>
>
> Voir Verte si je ne me trompe pas:
>
> http://wiki.openstreetmap.org/wiki/FR:Bicycle#Voies_vertes
>
> Vous mettriez quels tags ?
>>
> highway=path
> bicycle=yes/designated
> foot=yes/designated
> segregated=yes
>
> Eric
>
>
>
>
> ___
> 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] path, cycleway et footway

[Eric Sibert]

(regardez bien le panneau) :



Voir Verte si je ne me trompe pas:

http://wiki.openstreetmap.org/wiki/FR:Bicycle#Voies_vertes


Vous mettriez quels tags ?

highway=path
bicycle=yes/designated
foot=yes/designated
segregated=yes

Eric



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

Re: [OSM-talk-fr] path, cycleway et footway

[thomas . rouyer]

Bonjour,

Ça ressemble à une voie verte ;)
http://wiki.openstreetmap.org/wiki/FR:Bicycle#Voies_vertes
Donc je mettrais highway=paths.

Thomas

Le 2016-06-22 14:36, Tony Emery a écrit :

Bonjour à tous,

J'ai une petite divergence à vous soumettre. Quand vous avez ce type de 
voie

(regardez bien le panneau) :


On est en pleine zone urbaine.

Vous mettriez quels tags ?
highway=paths
bicycle=yes
foot=yes

ou

highway=cycleway
foot=yes

ou autre chose ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context:
http://gis.19327.n5.nabble.com/path-cycleway-et-footway-tp5876181.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] path, cycleway et footway

[Tony Emery]

Bonjour à tous,

J'ai une petite divergence à vous soumettre. Quand vous avez ce type de voie
(regardez bien le panneau) :
 

On est en pleine zone urbaine.

Vous mettriez quels tags ?
highway=paths
bicycle=yes
foot=yes

ou

highway=cycleway
foot=yes

ou autre chose ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/path-cycleway-et-footway-tp5876181.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] Requête overpass api & python

[Tony Emery]

Du coup, je devrais plutôt mettre ça à la place ?

(
  ._;
  >;
);
out meta;





-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5876180.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] Requête overpass api & python

[Etienne Trimaille]

Overpass donne des résultats ordonnés par défaut, sauf quand on lui donne
plusieurs sorties (out,print), du coup ils les exécutent dans l'ordre de ta
requête overpass.
Je ne connais plus la syntaxe OQL, mais en XML, il faut :
 
  
  
 
 
Un seul print (out en OQL) est suffisant. Dans ta requête, tu en as deux,
ce qui est inutile (seulement utile pour overpass turbo).
Essaye ta requête dans QuickOSM, tu dois obtenir l'avertissement que ton
fichier n'est pas ordonné. Puis supprime le "out" de trop en t'assurant que
tu récupères bien les objets enfants (jusqu'à aux nœuds)

2016-06-22 9:19 GMT+02:00 Tony Emery :

> Ma requête doit ressembler à ça :
> #
> http://overpass-api.de/api/interpreter?[out:xml][timeout:65];(node[
> "highway"](43.98,4.70,44.27,4.99);way["highway"](43.98,4.70,44.27,4.99);relation["highway"](43.98,4.70,44.27,4.99););out
> meta asc;>;out meta qt;
>
> Et quand j'ajoute les paramètre, dans mon script Python, ça donne ça :
> query
> ='[out:xml][timeout:{0}];(node{1}{2};way{1}{2};relation{1}{2};);out meta
> asc;>;out meta qt;'.format(timeout,requete, bbox)
> query = query.encode('utf8')
> query_string = urllib.urlencode({'data': query})
>
> msgLog = ('2.1.4 Lancement de la requête : {0}').format(requete)
> insertMessageLogFile(logfilePath, msgLog)
> try:
> data = urllib2.urlopen(url=urlxapi, data=query_string).read()
> except urllib2.HTTPError as e:
> if e.code == 400:
> print 'Bad request overpass'
> # exit()
> continue
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5876139.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

Re: [OSM-talk-fr] Requête overpass api & python

[Philippe Verdy]

A priori les requêtes Overpass n'ont pas besoin de trier les objets.
Cependant le chargement de données dans un schéma destiné à les lier entre
elles peut nécessiter que les objets dépendants (les noueds d'un way, ou
les membres d'une relation) soient déclarés avant l'objet qui en dépent (le
way ou la relation) sinon ils ne trouvent pas les objets liés et l'objet
dépendant ne peut pas être créé.

Les ids d'objets ne sont pas indispensables partout car on n'a pas
nécessairemetn besoin des objets liés à un objet parent, juste de l'objet
parent lui-même et ses tags. Overpass ne trie pas car le tri a un coût en
mémoire (et certaines requêtes volumineuses ne pourraient pas alors
fonctionner, le serveur ne pouvant allouer la mémoire ou l'espace de
stockage temporaire nécessaire).

L'idée est que si un tri est nécessaire, c'est plutôt au client de le faire
lui-même plutôt que le serveur (qui sert à plein de monde et ne peut pas
allouer beaucoup de mémoire pour un seul utilisateur).

Sinon si un tri est nécessaire, lister tous les noeuds, puis tous les ways
puis tous les membres peut ne pas suffire (les relations peuvent aussi
avoir des relations dépendantes dans leurs membres). Si un tri devait être
fait, ce devrait être un tri "topologique": pas besoin de tri global (les
objets en général n'ont pas d'ordre, surtout pas selon leur id qui a une
valeur arbitraire), mais plutôt envoyer les objets au fil de l'eau, mais si
un objet n'est pas complet (ses membres ne sont pas encore sortis, alors le
mettre en attente d'un autre objet, sortir tout le reste et dès qu'un des
objets de ce reste est sorti qui était marqué comme en attente, sortir
l'objet qui était en attente). A la fin tous les objets en attente
devraient être sortis. Cette approche demandera beaucoup moins de mémoire.

Noter aussi qu'Overpass permet de sélectionner des objets sans faire aucune
récursion sur ses membres. Bref Overpass ne peut pas non plus imposer un
tri topologique, d'autant plus que ses requêtes sont ordonnées et qu'il
peut manipuler et sortir plusieurs "result sets" séparés (rien n'indique
que ces "result sets" multiples sont liés entre eux, et Overpass pourra
même sortir un même objet plusieurs fois (dans des résult sets séparés:
Overpass n'impose pas de calculer l'union des "result sets" dans un nouveau
"result set" unique).

Ceci dit, quand Overpass sort un "result set", autant que possible celui-ci
devrait être sorti dans un ordre topologique (qui n'est pas nécessairement
un tri complet non plus: les objets retournés peuvent être mélangés, mais
il s'assurera que si un objet est lié à un autre dans le même result set,
les objets dépendant liés seront sortis avant les objets liants). Dans un
tri topologique si deux objets A et B ne sont pas liés entre eux (aucun ne
dépend de l'autre), on peut les sortir dans un ordre quelconque (donc A,B
ou B,A, peu importe, un moteur les sortira autant que possible au fil de
l'eau selon sa représentation interne qui lui évite d'avoir à revenir
dessus plus tard et lui évite chaque fois que possible de gérer un espace
temporaire de mise en attente).

Ne pas imposer de tri dans Overpass permet justement des optimisations pour
la représentation interne des result sets, et pour accélérer notamment le
calcul des unions et intersections: plutôt que de faire des fusions par
tri, il utilisera des tables de hachage qui sont beaucoup plus rapides.
Hors les tables de hachage mélangent les objets indexés dans un ordre quasi
aléatoire (c'est une nécessité même de la fonctio nde hachage pour qu'elle
soit la plus efficace possible, avec le moins possible de "collisions" sur
une clé de hachage et une bonne distribution).

Overpass peut aussi trier les objets dans un ordre facilitant le traitement
2D, par exemple avec le tri "quadtile", si on le lui demande: ce tri
facilite, du côté client la division d'une tâche de traitement en
permettant de créer des taches pour des zones rectangulaires avec toutes
les données locales proches dans le jeu de données. Cependant là encore ce
n'est qu'un des critères de tri possible (et cela n'exclue pas en plus de
faire un tri topologique, sanchant que dans un seul "quadtile" il peut y
avoir des données dépendantes qui sont dans un ou plusieurs autres
"quadtiles" voisins): les quadtiles ne trient en fait que les noeuds, les
chemins et relations qui seraient liés à ces noeuds seront sortis après.

Mais d'une façon générale, oui les noeuds peuvent toujours être sortis en
premier (dans un ordre quelconque) car il ne sont liés à rien, puis tous
les chemins dans un ordre quelconque car ils ne sont liés qu'à des noeuds
(et aucun autre chemin), le cas se complique avec les relations à la fin
(qui ont des relations entre elles). Cependant mettre tous les noeuds avant
les chmins et relations n'est pa non plus efficace côté client qui ne peut
par exemple pas commencer à traiter les chemins utilisant les premiers
noeuds avant que la totalité des noeuds soient sortis.

Un tri topologique complet 

Re: [OSM-talk-fr] ***SPAM*** Re: Majuscule à l'article défini sur les lieux-dits ?

[Philippe Verdy]

Le 22 juin 2016 à 02:41, Christian Rogel 
a écrit :

>
> > L'approche choisie par Osmose contredit la règle édictée par
> > OpenStreetMap. Tant que ceci n'est pas résolu dans un sens où dans
> > l'autre il y a un problème.
> >
> https://wiki.openstreetmap.org/wiki/FR:Toponymes,_odonymes#Toponymes_officiels_et_non-officiels
>
> Les codeurs d’Osmose ont, ici, bien senti où sont le sens commun et la
> vraie vie
>

Ils ont surtout senti leur propre volonté d'imposer une norme inventée de
toute pièce qui oublie complètement qu'en français et dans l'écriture latin
en général la casse est signifiante, juste pour une prétendue volonté
d'homogénéité sur un rendu. Hors ce n'est pas à la base de données
d'impsoer cette règle de rendu, si volonté il y a de faire un rendu
homogène.

Ces noms ont des usages autres que pour produire une carte. Ce sont des
données, pas la carte elle-même.

Le pragmatisme a bon dos ! Ici Osmose veut taguer pour le rendu, et ses
auteurs ne veulent simplement pas l'admettre ! Ce n'est pas à Osmose de
corirger ça, c'est au rendu mapnik de forcer une capitale initiale, si ça
lui plaint mieux. On n'a aboslument pas à supposer que ces noms sont
destinés uniquemetn à une utilisation isolée (dans une "phrase nominale"
uniquement).

Pour moi la règle est simple:

- nom de collectvité (personne morale) : on met les capitales (et trait
d'union) comme dans la toponymie offficielle (et on ne force pas les traits
d'union partout car ce n'est pas la règle partout en France: exemple: les
"Pays de la Loire" ou le "Territoire de Belfort").

- pour le reste, on met la casse permettant d'écrire ce nom au milieu d'une
phrase sans avoir à deviner s'il faut ou pas changer une capitale en
minuscule. Si on trouve en minuscule on la laisse, ou ou on la change en
capitale en début de phrase, ou ou peut contracter le premier mot si c'est
un article défini ("à le" -> "au", "de le" -> "du", "à les" -> "aux", "de
les" -> "des") selon les règles syntaxiques normales du français.

- un rendu qui souhaite une homogénéité pour les toponymes isolés sur une
carte (phrases nominales), pourra juste forcer une capitale pour certains
types de noms (attention à ne pas le faire pour tout)

- la base de données gardera toutes les distinctions de casse chaque fois
que possible, comme le fait tout bon dictionnaire !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Requête overpass api & python

[Tony Emery]

Ma requête doit ressembler à ça :
#
http://overpass-api.de/api/interpreter?[out:xml][timeout:65];(node["highway"](43.98,4.70,44.27,4.99);way["highway"](43.98,4.70,44.27,4.99);relation["highway"](43.98,4.70,44.27,4.99););out
meta asc;>;out meta qt;

Et quand j'ajoute les paramètre, dans mon script Python, ça donne ça :
query
='[out:xml][timeout:{0}];(node{1}{2};way{1}{2};relation{1}{2};);out meta
asc;>;out meta qt;'.format(timeout,requete, bbox)
query = query.encode('utf8')
query_string = urllib.urlencode({'data': query})

msgLog = ('2.1.4 Lancement de la requête : {0}').format(requete)
insertMessageLogFile(logfilePath, msgLog)
try:
data = urllib2.urlopen(url=urlxapi, data=query_string).read()
except urllib2.HTTPError as e:
if e.code == 400:
print 'Bad request overpass'
# exit()
continue



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5876139.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] Requête overpass api & python

[Etienne Trimaille]

Cela vient de ta requête overpass.
Il y a le même problème dans QuickOSM, il faut que les objets soient dans
le bon ordre.
Avec l'assistant par défaut d'Overpass Turbo, on peut obtenir l'ordre
inverse.  Est-ce que l'on peut voir la requête ?

Le 22 juin 2016 à 08:48, Tony Emery  a écrit :

> Je déterre un peu le sujet car il y a un petit truc dans le script que j'ai
> réalisé qui me chiffonne.
>
> Quand la requête est lancée (par exemple, pour importer les voies), le
> fichier Planet généré contient bien les objets demandé mais il ne sont pas
> forcément classés (ou alors, je ne sais pas avec quelle ordre de tri).
>
> Le fait d'ouvrir le fichier avec JOSM et d'enregistrer à nouveau le fichier
> fait que les données sont triées. Cela veut dire que JOSM lit le fichier et
> remet de l'ordre dans tout ça.
>
> Or, FME ne sait pas faire ça et, du coup, n'arrive pas a interpréter le
> fichier Planet brut.
>
> Du coup, je me demandais s'il n'y avait pas une option a indiquer dans la
> requête pour trier les objets (d'abord les nodes, puis les ways et enfin
> les
> relations) ?
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5876134.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

Re: [OSM-talk-fr] Requête overpass api & python

[Tony Emery]

Je déterre un peu le sujet car il y a un petit truc dans le script que j'ai
réalisé qui me chiffonne.

Quand la requête est lancée (par exemple, pour importer les voies), le
fichier Planet généré contient bien les objets demandé mais il ne sont pas
forcément classés (ou alors, je ne sais pas avec quelle ordre de tri).

Le fait d'ouvrir le fichier avec JOSM et d'enregistrer à nouveau le fichier
fait que les données sont triées. Cela veut dire que JOSM lit le fichier et
remet de l'ordre dans tout ça.

Or, FME ne sait pas faire ça et, du coup, n'arrive pas a interpréter le
fichier Planet brut.

Du coup, je me demandais s'il n'y avait pas une option a indiquer dans la
requête pour trier les objets (d'abord les nodes, puis les ways et enfin les
relations) ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Requete-overpass-api-python-tp5863030p5876134.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