Re: [OSM-talk-fr] Tagging Infrastructures de Santé

[Violaine Doutreleau]

Le 11/09/2017 à 21:03, marc marc a écrit :

Ma question reste ouverte : est-ce que le nombre de chirugien
est une info suffisament stable que pour être dans osm ?
Bonne question.. Ça dépend énormément du contexte local je dirais... 
Peut-être est-ce au contributeur de faire la distinction alors?


il n'y a aucune obligation d'avoir un tag approuvé ni même une page wiki
si t'as envie de mettre schtroump=42 sur un hôpital, libre à toi.
Mais c'est évidement très probable que toi seul en comprenne
le sens exact et l'utilise.
Faire une proposition, la faire commenter puis voter est
une méthode pour augmenter la qualité et son utilisation
Les page wiki sans status sont souvent des pages "de fait",
d'un tag utilisé qu'on essaye après coup d'en définir le sens.
Alors qui ne passe pas par la case vote? Du coup comment on interprète 
ces pages "de fait" : tu supposerais que le tag est approuvé si 
largement utilisé ? a partir de quand on suppose qu'il est largement 
utilisé? Pour moi ces pages me donnent pas trop confiance, des fois les 
tags ne sont pas tant utilisés que ça ..


Par contre "map_features" n'a pas du tout vocation à d'être un index
de tous les tags du wiki. C'est un guide des tags les plus fréquents.
Il est donc probable que concernant la santé, seul les tags les plus
important y figure. le lien vers les pages concernées permettent de
renseigner les tags moins courant.

ok, bon à savoir, merci.


Le 11. 09. 17 à 18:52, Violaine Doutreleau a écrit :

Bonjour à tous et merci Marc pour ces éclaircissements !

Je retiens staff:chirurgien=yes/nombre, effectivement on était passé à
côté de ça ! Pour le comptage des lits capacity:bed est pas mal pour le
moment.. Dans la même idée que ce que tu disais, on pourrait étendre
bed:=yes/nombre

Pour l'état d'une infra, on partirait sur disused:amenity=yes/type of
amenity et abandonned:amenity=yes/type of amenity pour le moment du
coup. Je vois au HOT Summit si ya d'autre niveaux d'états d'infra
nécessaires à tagger.

Pour l'inventaire, j'ai tout de même des questions, car effectivement on
a trouvé des usages de staff_count mais pas de wiki qui assure que la
clé est approuvée. De même est-ce que tous les éléments adressés sur
:/http://wiki.openstreetmap.org/wiki/Key:*/ sont sensés être sur
/http://wiki.openstreetmap.org/wiki/Map_Features
/

Également, des fois une page key=* n'a pas de status indiqué (exemple
page Status : http://wiki.openstreetmap.org/wiki/Key:status). On ne sait
pas si on peut utiliser le tag ou pas...

A+

Le 08/09/2017 à 18:48, marc marc a écrit :

Le 08. 09. 17 à 17:50, Violaine Doutreleau a écrit :

* j'ai vu passer un échange autour du tag capacity disant qu'il
  représentait une quantité quand un autre tag pouvait représenter un
  volume. Mais je trouve qu'il manque un tag 'nombre' type 'n' . J'ai
  vu des fois le tag capacity être utilisé comme capacity:bed, ce qui
  fait sens également. Mais ça marche dans ce cas car le nombre de lit
  fait aussi référence à la capacité du centre de santé. Par contre,
  il est aussi intéressant de connaitre le nombre de personnel de
  santé, voire même par spécialité, alors on sort du cadre capacity.
  Du coup la seule proposition trouvée ici c'est de mettre un
  bed_count, staff_count, puisqu'il semble que ce soit l'usage
  (rajouter _count à la fin de l'élément à compter). Par contre je
  trouve pas ça super logique, je suis plus pour un tag universel pour
  les nombres... Ou je rate quelque chose?

Le but de François et moi était de rassembler autour d'un tag une
proposition (l'amélioration des tag pour les bornes incendies) qui
allait provoquer des nouveaux tags pour un utilisation finalement
assez semblable à savoir la capacité maximale d'une infrastructure.
Pour la petite histoire, le tag capacity ne serrait finalement
probablement pas retenu, le pompier à l’œuvre estimant que le débit
d'une borne n'est pas sa capacité (maximale) mais nominal.
En ce sens, un hôtel de 4 lits, un parking de 10 places décrivent
toutes la capacité que peux "supporter" l'objet de par sa conception.
capacity:bed ou quelques chose du genre ferrait pour moi référence à la
capacité maximale d'un hôpital par exemple, ceci pouvait être différent
de la capacité "opérationnelle" variable par exemple selon le personnel.
J'ignore cependant laquelle des 2 vous voulez encoder dans osm.
La capacité théorique est assez stable. l'opérationnelle me semble délicate.
Pour le personnel de santé, peut-être qu'une clef genre staff pourrait
faire l'affaire. il faudrait peut-être aussi faire des recherches
sur le wiki et/ou taginfo pour voir si ce genre d'info n'existe pas déjà
Mais là aussi, est-ce que cela ne risque-t-il pas d'etre une donnée
volatile ?

il n'est pas obligatoire de tout suffixer par _count, de nombreux tag
ont un wiki qui décrit par exemple une valeur yes pour dire que c'est
présent (par exemple staff:chirurgien (à traduire évidement)
ou un nombre pour rafiner 

Re: [OSM-talk-fr] les dates de terrain, de test fonctionnel, d'import, de source

[Christian Quest]

La webapp geocropping rend ce process de mise à jour d'une date de contrôle
sur terrain très simple et pas technique du tout.

A voir ici: https://geocropping.xsalto.com/

Le 11 septembre 2017 à 18:33, Violaine Doutreleau 
a écrit :

> Bonjour Marc,
>
> Pour moi la difficulté c'est qu'il ne faudrait pas mixer la source d'une
> information (je suis ok pour  ajouter une info de date en fonction de la
> source de données), par le check_date ou operational_status:date, qui
> relève plutôt de la validation de données. J'entends : la donnée est déjà
> créée, je repasse x jours après sa création pour dire qu'elle est toujours
> valide. Healthsites prévoit de faire ça sur la thématique santé... Par
> contre j'aime beaucoup l'idée car on pourrait imaginer de la demande de
> validation de données si le check_date est trop éloigné de la date du jour
> aux utilisateurs de gps... Et ça pourrait donner un sacré coup de pouce ...
>
> Par contre j'ai le sentiment que ce n'est pas vraiment la place de la
> validation, mais d'une base extérieure? Dailleurs ça risque d'être trop
> tech pour des utilisateurs lambdas d'OSM, et pourtant des informations
> faciles à donner par n'importe qui.
>
> Sinon, une autre difficulté que je trouve c'est qu'il faudrait quasi
> autant de check_date, que de tags, ou alors définir les éléments que l'on
> souhaite vérifier. Non? Par exemple pour les centre de santés, c'est pas
> évident de tout contrôler d'un coup si on est un utilisateur lambda  (pas
> aussi simple de donner le nombre de staffs par exemple)
>
> Juste mes réflexions...
>
> A bientôt,
>
> V
>
> Le 06/09/2017 à 00:16, marc marc a écrit :
>
> Suite à une discussion à propos des dates, j'ai été faire un tour
> sur le wiki et taginfo. La problème était simple mais comme souvent
> il y a une grande diversité de mise en place.
>
> Il y a, si j'ai oublié personne, 3 grand besoins :
>
> - la date où un objet a été vu la dernière fois sur le terrain
> survey:date avec toutes les variantes d'ordre et de caractère
> de séparation
> Ce serrait selon moi le tag à utiliser pour des projets comme jungle bus
> où certains veulent pouvoir éventuellement vérifier l’existence
> d'un objet qui n'a plus été vu depuis X temps.
>
> - la propal sur les bornes a fait sortir un 2ieme besoin, celui
> qui concerne les équipements "technique" ou "voir" ne suffit pas
> à dire que cela fonctionne. exemple : le pompier à l’œuvre sur
> la propal des bornes qui voudrait pouvoir tester les bornes.
> Initialement, c'était prévu d'utiliser check_date
> le nom n'est pas terrible, le "_" encore moins mais il a
> l'avantage d'exister
> A la relecture, le wiki ne précisant pas qu'est ce qui est vérifié,
> je me demande s'il ne serrait pas mieux d'utiliser
> operational_status:date qui a l'avantage d'être parfaitement clair.
>
> - source:date : la date de la source des données par exemple utilisée
> lors d'un import mais aussi celle de l'imagerie lorsque connue.
> mais là aussi, grande variété avec par exemple source="le nom - la date"
>
> Et puis il y a les tag fourre-tout, dont le sens exact est inconnu
> ou dont le sens multiple rend sont utilisation problématique.
> exemple survey="sortie de classe à tel date" ou d'autres dont on ignore
> si la date correspond à l'encodage dans osm (que le changeset donne
> déjà) ou si c'est celle d'une visite sur le terrain ou d'une base de
> donnée ou une date oü on a vérifié/corrigé la qualité style osmose
>  lastcheck
>  updated
>  check_exists:date
> Si vous utilisez l'un d'entre eux ou connaissez outil qui l'utilise,
> quel sens ?
>
> Dernier problème : le format de la date. toutes les pages que j'ai
> consultée parlent du format ISO 8601 basique -MM-DD, à tronquer
> éventuellement lors que nécessaire genre 2017-09
> En pratique c'est loin d'être le cas et on se retrouve avec
> des valeurs 100117 qu'il nécessite de consulter l'historique de
> l'objet pour faire la différence entre 10/01/2017 et 2010-01-17.
> sans compter les mois en lettre ou les saisons, abrévié ou non.
> bref, informatiquement quasi impossible à utiliser.
>
> Evidement tout ces tags sont optionnel, mon propos n'est absolument
> pas qu'on rajoute cela partout, surtout pas.
> Mon propos n'est pas non plus de dire où cela doit être mis (changeset
> <> objet)
> mon propos est plutôt de chercher, pour les projets qui en ont besoin,
> un moyen uniforme pour avoir l'info dans quelques tags commun plutôt
> que d'en avoir une 20aine comme actuellement.
> Cela permettrait des utilisations du genre :
> - vérifier que les commerces n'ont pas changés après 2 ans.
> - vérifier le fonctionnement des bornes après x mois.
> - vérifier ce qu'est devenu un objet qui se trouverait dans
> un import 2016 après que l'import 2017 ai validé tous les autres.
>
> Qu'en pensez-vous ?
> Si un besoin manque, n'hésitez pas à le décrire.
> ___
> Talk-fr mailing 
> 

Re: [OSM-talk-fr] Tagging Infrastructures de Santé

[marc marc]

Ma question reste ouverte : est-ce que le nombre de chirugien
est une info suffisament stable que pour être dans osm ?

il n'y a aucune obligation d'avoir un tag approuvé ni même une page wiki
si t'as envie de mettre schtroump=42 sur un hôpital, libre à toi.
Mais c'est évidement très probable que toi seul en comprenne
le sens exact et l'utilise.
Faire une proposition, la faire commenter puis voter est
une méthode pour augmenter la qualité et son utilisation
Les page wiki sans status sont souvent des pages "de fait",
d'un tag utilisé qu'on essaye après coup d'en définir le sens.

Par contre "map_features" n'a pas du tout vocation à d'être un index
de tous les tags du wiki. C'est un guide des tags les plus fréquents.
Il est donc probable que concernant la santé, seul les tags les plus 
important y figure. le lien vers les pages concernées permettent de 
renseigner les tags moins courant.

Le 11. 09. 17 à 18:52, Violaine Doutreleau a écrit :
> Bonjour à tous et merci Marc pour ces éclaircissements !
> 
> Je retiens staff:chirurgien=yes/nombre, effectivement on était passé à 
> côté de ça ! Pour le comptage des lits capacity:bed est pas mal pour le 
> moment.. Dans la même idée que ce que tu disais, on pourrait étendre 
> bed:=yes/nombre
> 
> Pour l'état d'une infra, on partirait sur disused:amenity=yes/type of 
> amenity et abandonned:amenity=yes/type of amenity pour le moment du 
> coup. Je vois au HOT Summit si ya d'autre niveaux d'états d'infra 
> nécessaires à tagger.
> 
> Pour l'inventaire, j'ai tout de même des questions, car effectivement on 
> a trouvé des usages de staff_count mais pas de wiki qui assure que la 
> clé est approuvée. De même est-ce que tous les éléments adressés sur 
> :/http://wiki.openstreetmap.org/wiki/Key:*/ sont sensés être sur 
> /http://wiki.openstreetmap.org/wiki/Map_Features
> /
> 
> Également, des fois une page key=* n'a pas de status indiqué (exemple 
> page Status : http://wiki.openstreetmap.org/wiki/Key:status). On ne sait 
> pas si on peut utiliser le tag ou pas...
> 
> A+
> 
> Le 08/09/2017 à 18:48, marc marc a écrit :
>> Le 08. 09. 17 à 17:50, Violaine Doutreleau a écrit :
>>>* j'ai vu passer un échange autour du tag capacity disant qu'il
>>>  représentait une quantité quand un autre tag pouvait représenter un
>>>  volume. Mais je trouve qu'il manque un tag 'nombre' type 'n' . J'ai
>>>  vu des fois le tag capacity être utilisé comme capacity:bed, ce qui
>>>  fait sens également. Mais ça marche dans ce cas car le nombre de lit
>>>  fait aussi référence à la capacité du centre de santé. Par contre,
>>>  il est aussi intéressant de connaitre le nombre de personnel de
>>>  santé, voire même par spécialité, alors on sort du cadre capacity.
>>>  Du coup la seule proposition trouvée ici c'est de mettre un
>>>  bed_count, staff_count, puisqu'il semble que ce soit l'usage
>>>  (rajouter _count à la fin de l'élément à compter). Par contre je
>>>  trouve pas ça super logique, je suis plus pour un tag universel pour
>>>  les nombres... Ou je rate quelque chose?
>> Le but de François et moi était de rassembler autour d'un tag une
>> proposition (l'amélioration des tag pour les bornes incendies) qui
>> allait provoquer des nouveaux tags pour un utilisation finalement
>> assez semblable à savoir la capacité maximale d'une infrastructure.
>> Pour la petite histoire, le tag capacity ne serrait finalement
>> probablement pas retenu, le pompier à l’œuvre estimant que le débit
>> d'une borne n'est pas sa capacité (maximale) mais nominal.
>> En ce sens, un hôtel de 4 lits, un parking de 10 places décrivent
>> toutes la capacité que peux "supporter" l'objet de par sa conception.
>> capacity:bed ou quelques chose du genre ferrait pour moi référence à la
>> capacité maximale d'un hôpital par exemple, ceci pouvait être différent
>> de la capacité "opérationnelle" variable par exemple selon le personnel.
>> J'ignore cependant laquelle des 2 vous voulez encoder dans osm.
>> La capacité théorique est assez stable. l'opérationnelle me semble délicate.
>> Pour le personnel de santé, peut-être qu'une clef genre staff pourrait
>> faire l'affaire. il faudrait peut-être aussi faire des recherches
>> sur le wiki et/ou taginfo pour voir si ce genre d'info n'existe pas déjà
>> Mais là aussi, est-ce que cela ne risque-t-il pas d'etre une donnée
>> volatile ?
>>
>> il n'est pas obligatoire de tout suffixer par _count, de nombreux tag
>> ont un wiki qui décrit par exemple une valeur yes pour dire que c'est
>> présent (par exemple staff:chirurgien (à traduire évidement)
>> ou un nombre pour rafiner l'information (par exemple 3)
>> L'important étant surtout d'avoir un nom de clef non ambigu,
>> uniforme et bien documenté.
>> Il est aussi possible d'avoir des :count, l'avantage étant
>> de permettre aux éditeur de reconnaître le type de clef
>> Cela n'a cependant selon moi de sens que si la même clef a autre
>> chose qu'un ":count"
>>
>>>* comment 

Re: [OSM-talk-fr] Tagging Infrastructures de Santé

[Violaine Doutreleau]

Bonjour à tous et merci Marc pour ces éclaircissements !

Je retiens staff:chirurgien=yes/nombre, effectivement on était passé à 
côté de ça ! Pour le comptage des lits capacity:bed est pas mal pour le 
moment.. Dans la même idée que ce que tu disais, on pourrait étendre 
bed:=yes/nombre


Pour l'état d'une infra, on partirait sur disused:amenity=yes/type of 
amenity et abandonned:amenity=yes/type of amenity pour le moment du 
coup. Je vois au HOT Summit si ya d'autre niveaux d'états d'infra 
nécessaires à tagger.


Pour l'inventaire, j'ai tout de même des questions, car effectivement on 
a trouvé des usages de staff_count mais pas de wiki qui assure que la 
clé est approuvée. De même est-ce que tous les éléments adressés sur 
:/http://wiki.openstreetmap.org/wiki/Key:*/ sont sensés être sur 
/http://wiki.openstreetmap.org/wiki/Map_Features

/

Également, des fois une page key=* n'a pas de status indiqué (exemple 
page Status : http://wiki.openstreetmap.org/wiki/Key:status). On ne sait 
pas si on peut utiliser le tag ou pas...


A+

Le 08/09/2017 à 18:48, marc marc a écrit :

Le 08. 09. 17 à 17:50, Violaine Doutreleau a écrit :

   * j'ai vu passer un échange autour du tag capacity disant qu'il
 représentait une quantité quand un autre tag pouvait représenter un
 volume. Mais je trouve qu'il manque un tag 'nombre' type 'n' . J'ai
 vu des fois le tag capacity être utilisé comme capacity:bed, ce qui
 fait sens également. Mais ça marche dans ce cas car le nombre de lit
 fait aussi référence à la capacité du centre de santé. Par contre,
 il est aussi intéressant de connaitre le nombre de personnel de
 santé, voire même par spécialité, alors on sort du cadre capacity.
 Du coup la seule proposition trouvée ici c'est de mettre un
 bed_count, staff_count, puisqu'il semble que ce soit l'usage
 (rajouter _count à la fin de l'élément à compter). Par contre je
 trouve pas ça super logique, je suis plus pour un tag universel pour
 les nombres... Ou je rate quelque chose?

Le but de François et moi était de rassembler autour d'un tag une
proposition (l'amélioration des tag pour les bornes incendies) qui
allait provoquer des nouveaux tags pour un utilisation finalement
assez semblable à savoir la capacité maximale d'une infrastructure.
Pour la petite histoire, le tag capacity ne serrait finalement
probablement pas retenu, le pompier à l’œuvre estimant que le débit
d'une borne n'est pas sa capacité (maximale) mais nominal.
En ce sens, un hôtel de 4 lits, un parking de 10 places décrivent
toutes la capacité que peux "supporter" l'objet de par sa conception.
capacity:bed ou quelques chose du genre ferrait pour moi référence à la
capacité maximale d'un hôpital par exemple, ceci pouvait être différent
de la capacité "opérationnelle" variable par exemple selon le personnel.
J'ignore cependant laquelle des 2 vous voulez encoder dans osm.
La capacité théorique est assez stable. l'opérationnelle me semble délicate.
Pour le personnel de santé, peut-être qu'une clef genre staff pourrait
faire l'affaire. il faudrait peut-être aussi faire des recherches
sur le wiki et/ou taginfo pour voir si ce genre d'info n'existe pas déjà
Mais là aussi, est-ce que cela ne risque-t-il pas d'etre une donnée
volatile ?

il n'est pas obligatoire de tout suffixer par _count, de nombreux tag
ont un wiki qui décrit par exemple une valeur yes pour dire que c'est
présent (par exemple staff:chirurgien (à traduire évidement)
ou un nombre pour rafiner l'information (par exemple 3)
L'important étant surtout d'avoir un nom de clef non ambigu,
uniforme et bien documenté.
Il est aussi possible d'avoir des :count, l'avantage étant
de permettre aux éditeur de reconnaître le type de clef
Cela n'a cependant selon moi de sens que si la même clef a autre
chose qu'un ":count"


   * comment pourrait-on définir l'état d'une infrastructure, si
 fonctionnel/opérationnel ou pas ? J'ai également vu pas mal de
 propositions mais je n'en ai pas trouvée une approuvée...

L'inventaire est fait...  cfr mon email "les dates
de terrain, de test fonctionnel, d'import, de source"
N'hésite pas d'y répondre, je compte justement essayer de faire
avancer cette "harmonisation". Je laisse encore quelques jours
si un francophone à des remarques avant de tenter une harmonisation
locale et/ou un avis sur la ml mondiale.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


--
*Violaine Doutreleau*
Coordinatrice Missing Maps
CartONG 
mobile : 06.95.02.42.44
skype : doutreleau.violaine


_P Help save paper - do you need to print this email?_
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] les dates de terrain, de test fonctionnel, d'import, de source

[Violaine Doutreleau]

Bonjour Marc,

Pour moi la difficulté c'est qu'il ne faudrait pas mixer la source d'une 
information (je suis ok pour  ajouter une info de date en fonction de la 
source de données), par le check_date ou operational_status:date, qui 
relève plutôt de la validation de données. J'entends : la donnée est 
déjà créée, je repasse x jours après sa création pour dire qu'elle est 
toujours valide. Healthsites prévoit de faire ça sur la thématique 
santé... Par contre j'aime beaucoup l'idée car on pourrait imaginer de 
la demande de validation de données si le check_date est trop éloigné de 
la date du jour aux utilisateurs de gps... Et ça pourrait donner un 
sacré coup de pouce ...


Par contre j'ai le sentiment que ce n'est pas vraiment la place de la 
validation, mais d'une base extérieure? Dailleurs ça risque d'être trop 
tech pour des utilisateurs lambdas d'OSM, et pourtant des informations 
faciles à donner par n'importe qui.


Sinon, une autre difficulté que je trouve c'est qu'il faudrait quasi 
autant de check_date, que de tags, ou alors définir les éléments que 
l'on souhaite vérifier. Non? Par exemple pour les centre de santés, 
c'est pas évident de tout contrôler d'un coup si on est un utilisateur 
lambda  (pas aussi simple de donner le nombre de staffs par exemple)


Juste mes réflexions...

A bientôt,

V


Le 06/09/2017 à 00:16, marc marc a écrit :

Suite à une discussion à propos des dates, j'ai été faire un tour
sur le wiki et taginfo. La problème était simple mais comme souvent
il y a une grande diversité de mise en place.

Il y a, si j'ai oublié personne, 3 grand besoins :

- la date où un objet a été vu la dernière fois sur le terrain
survey:date avec toutes les variantes d'ordre et de caractère
de séparation
Ce serrait selon moi le tag à utiliser pour des projets comme jungle bus
où certains veulent pouvoir éventuellement vérifier l’existence
d'un objet qui n'a plus été vu depuis X temps.

- la propal sur les bornes a fait sortir un 2ieme besoin, celui
qui concerne les équipements "technique" ou "voir" ne suffit pas
à dire que cela fonctionne. exemple : le pompier à l’œuvre sur
la propal des bornes qui voudrait pouvoir tester les bornes.
Initialement, c'était prévu d'utiliser check_date
le nom n'est pas terrible, le "_" encore moins mais il a
l'avantage d'exister
A la relecture, le wiki ne précisant pas qu'est ce qui est vérifié,
je me demande s'il ne serrait pas mieux d'utiliser
operational_status:date qui a l'avantage d'être parfaitement clair.

- source:date : la date de la source des données par exemple utilisée
lors d'un import mais aussi celle de l'imagerie lorsque connue.
mais là aussi, grande variété avec par exemple source="le nom - la date"

Et puis il y a les tag fourre-tout, dont le sens exact est inconnu
ou dont le sens multiple rend sont utilisation problématique.
exemple survey="sortie de classe à tel date" ou d'autres dont on ignore
si la date correspond à l'encodage dans osm (que le changeset donne
déjà) ou si c'est celle d'une visite sur le terrain ou d'une base de
donnée ou une date oü on a vérifié/corrigé la qualité style osmose
  lastcheck
  updated
  check_exists:date
Si vous utilisez l'un d'entre eux ou connaissez outil qui l'utilise,
quel sens ?

Dernier problème : le format de la date. toutes les pages que j'ai
consultée parlent du format ISO 8601 basique -MM-DD, à tronquer
éventuellement lors que nécessaire genre 2017-09
En pratique c'est loin d'être le cas et on se retrouve avec
des valeurs 100117 qu'il nécessite de consulter l'historique de
l'objet pour faire la différence entre 10/01/2017 et 2010-01-17.
sans compter les mois en lettre ou les saisons, abrévié ou non.
bref, informatiquement quasi impossible à utiliser.

Evidement tout ces tags sont optionnel, mon propos n'est absolument
pas qu'on rajoute cela partout, surtout pas.
Mon propos n'est pas non plus de dire où cela doit être mis (changeset
<> objet)
mon propos est plutôt de chercher, pour les projets qui en ont besoin,
un moyen uniforme pour avoir l'info dans quelques tags commun plutôt
que d'en avoir une 20aine comme actuellement.
Cela permettrait des utilisations du genre :
- vérifier que les commerces n'ont pas changés après 2 ans.
- vérifier le fonctionnement des bornes après x mois.
- vérifier ce qu'est devenu un objet qui se trouverait dans
un import 2016 après que l'import 2017 ai validé tous les autres.

Qu'en pensez-vous ?
Si un besoin manque, n'hésitez pas à le décrire.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


--
*Violaine Doutreleau*
Coordinatrice Missing Maps
CartONG 
mobile : 06.95.02.42.44
skype : doutreleau.violaine


_P Help save paper - do you need to print this email?_
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[Samy Mezani]

Le 11/09/2017 à 16:51, sly (sylvain letuffe) a écrit :

mais le seul soucis qui semble  (semble car je
ne suis pas expert Qgis) rester ce sont les 2 communes au Sud Est qui
appartiennent à la région voisine, qui sont donc des enclaves appartenant à
la région d'a coté et qui devrait alors être des "trous" de la ex-région
bourgogne mais qui ne semble pas être traité comme des trous.


Là pour le coup, ça ne m'a pas choqué puisque ces 2 enclaves touchent 
bien la relation Bourgogne.


Le polygone généré pour la Bourgogne par ogr2ogr est bien le 
multipolygone "outer".
Je me suis débarrassé des 2 enclavec avec -sql select * from 
multipolygons where name = 'Bourgogne'


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

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[sly (sylvain letuffe)]

Samy Mezani wrote
> Je teste en ce moment même avec ogr2ogr (qui me renvoie des erreurs de 
> segmentation sur Debian...)

Par curiosité, j'ai voulu essayer et ça à l'air de presque quasiment le
faire avec ogr2ogr :
http://sly.letuffe.org/echange/old-bourgogne.zip

Sur une debian 8
$ ogr2ogr --version
GDAL 1.10.1, released 2013/08/26

$ ogr2ogr -overwrite -f "ESRI Shapefile" test.shp test.osm -sql 'select *
from multipolygons'

ça s'ouvre nikel avec Qgis, mais le seul soucis qui semble  (semble car je
ne suis pas expert Qgis) rester ce sont les 2 communes au Sud Est qui
appartiennent à la région voisine, qui sont donc des enclaves appartenant à
la région d'a coté et qui devrait alors être des "trous" de la ex-région
bourgogne mais qui ne semble pas être traité comme des trous.
Peut-être une "non fonctionnalité" de ce driver ogr2ogr qui ne gère pas les
role inner
https://wiki.openstreetmap.org/wiki/Relation:multipolygon#One_outer_and_one_inner_ring






-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[Samy Mezani]

J'enfonce certainement des portes ouvertes, mais voici enfin la manip 
qui a fonctionné :


wget -O bourgogne.osm 
'http://overpass-api.de/api/interpreter?data=rel[name="Bourgogne"]["disused:admin_level"=4];(._;>);out 
geom;


ogr2ogr -a_srs "EPSG:4326" -t_srs "EPSG:2154" -f PostgreSQL 
PG:"host= dbname=" -lco schema= -nln bourgogne_region_old 
-nlt multipolygon -sql "select name from multipolygons where 
name='Bourgogne'" bourgogne.osm


J'ai bien mon multipolygone dans ma base PostGIS. Nickel. Si ça peut servir…

Merci pour votre aide.

Samy

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

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[Samy Mezani]

Le 11/09/2017 à 15:24, sly (sylvain letuffe) a écrit :
[...]

A mon avis, le problème qui fait que tu n'obtiens pas les réponses que tu
attends tient dans l'expression de ton besoin.
Je pense comprendre (je peux me tromper) que ce que tu veux c'est un
multipolygone au sens GIS (postgis, shapefile) du terme alors que les
réponses qui t'ont été données expliquent comment avoir un multipolygone au
sens OSM du terme :


Effectivement, mes termes sont ambigus mais tu as bien compris mon 
besoin : un multipolygone au sens SIG.



Car la requête que tu as faite sur l'overpass te donne, selon la
terminologie OSM, le multipolygone de l'ancienne-Bourgogne et tous les
éléments qu'il faut pour en construire un (multi-)polygone (au sens GIS du
terme)


Ah OK, c'est plus clair.


Ce que tu cherches (peut-être) maintenant c'est un convertisseur, et
overpass ne fait pas ça.

osm2pgsql sait le faire pour importer dans postgres/postGIS
ogr2ogr semble le faire aussi :


Je teste en ce moment même avec ogr2ogr (qui me renvoie des erreurs de 
segmentation sur Debian...)


Le 11/09/2017 à 15:44, Jo a écrit :

Mais à mon avis les plugins openstreetmap en QGIS te seront plus utiles pour 
arriver à des fichiers .SHP. J'ignore si c'est possible de les invoquer à 
partir de  la ligne de commande. Peut-être avec un script Python?


J'aurais pu en effet me servir de codes Python comme QuickOSM ou autre, 
mais je voulais plutôt dégrossir le problème avec Overpass.


Merci en tous cas, je vais essayer de voir ogr2ogr ou osm2pgsql.

Samy

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

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[Jo]

https://wiki.openstreetmap.org/wiki/Osmosis

peut filtrer tes données OSM en ligne de commande

Mais à mon avis les plugins openstreetmap en QGIS te seront plus utiles
pour arriver à des fichiers .SHP. J'ignore si c'est possible de les
invoquer à partir de  la ligne de commande. Peut-être avec un script Python?

Jo

2017-09-11 15:24 GMT+02:00 sly (sylvain letuffe) :

> Samy Mezani wrote
> > Je veux simplement obtenir le multipolygone de son ancien contour.
>
> A mon avis, le problème qui fait que tu n'obtiens pas les réponses que tu
> attends tient dans l'expression de ton besoin.
> Je pense comprendre (je peux me tromper) que ce que tu veux c'est un
> multipolygone au sens GIS (postgis, shapefile) du terme alors que les
> réponses qui t'ont été données expliquent comment avoir un multipolygone au
> sens OSM du terme :
> https://wiki.openstreetmap.org/wiki/Relation:multipolygon
> (c'est à dire un objet de type"relation")
>
> Car la requête que tu as faite sur l'overpass te donne, selon la
> terminologie OSM, le multipolygone de l'ancienne-Bourgogne et tous les
> éléments qu'il faut pour en construire un (multi-)polygone (au sens GIS du
> terme)
> (Pour s'en convaincre, ajoute out meta; et ouvre le avec josm, tu verra que
> tu as bien le contour)
>
> Ce que tu cherches (peut-être) maintenant c'est un convertisseur, et
> overpass ne fait pas ça.
>
> osm2pgsql sait le faire pour importer dans postgres/postGIS
> ogr2ogr semble le faire aussi :
> http://www.gdal.org/drv_osm.html
>
> Mais ça nous aider, tu veux quel format à la fin pour le traiter dans ta
> chaîne "en ligne de commande" ?
>
>
>
> -
> --
> sly, contact direct : sylvain /a\ letuffe o r g
> http://wiki.openstreetmap.org/wiki/User:Sletuffe
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> 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] GR 5 Jura cartographié ? Et la FFRP ?

[David Marchal]

Salut, les gens.

Je viens de voir que le GR 5 Jura avait été cartographié 
(https://www.openstreetmap.org/relation/6095322), or il me semblait que, dans 
l’attente d’un accord avec la FFRP concernant l’ajout des GR et de leurs autres 
itinéraires dans OSM, on devait ne pas les ajouter pour éviter tout conflit sur 
leurs droits d’auteurs. Aurais-je manqué un épisode ?

Dans l’attente de vos réponses,

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

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[sly (sylvain letuffe)]

Samy Mezani wrote
> Je veux simplement obtenir le multipolygone de son ancien contour.

A mon avis, le problème qui fait que tu n'obtiens pas les réponses que tu
attends tient dans l'expression de ton besoin.
Je pense comprendre (je peux me tromper) que ce que tu veux c'est un
multipolygone au sens GIS (postgis, shapefile) du terme alors que les
réponses qui t'ont été données expliquent comment avoir un multipolygone au
sens OSM du terme :
https://wiki.openstreetmap.org/wiki/Relation:multipolygon
(c'est à dire un objet de type"relation")

Car la requête que tu as faite sur l'overpass te donne, selon la
terminologie OSM, le multipolygone de l'ancienne-Bourgogne et tous les
éléments qu'il faut pour en construire un (multi-)polygone (au sens GIS du
terme)
(Pour s'en convaincre, ajoute out meta; et ouvre le avec josm, tu verra que
tu as bien le contour)

Ce que tu cherches (peut-être) maintenant c'est un convertisseur, et
overpass ne fait pas ça.

osm2pgsql sait le faire pour importer dans postgres/postGIS
ogr2ogr semble le faire aussi :
http://www.gdal.org/drv_osm.html

Mais ça nous aider, tu veux quel format à la fin pour le traiter dans ta
chaîne "en ligne de commande" ?



-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[marc marc]

Le 11. 09. 17 à 14:21, Samy Mezani a écrit :
> Donc , pour résumer, comment n'obtenir que les *ways* membres 
> de la relation et surtout leur géométrie ? 
> (pour importer dans PostGIs, ou visionner dans QGis)
la géométrie d'un way implique d'avoir les nœuds.
"out geom" te donne lat/lon des nœuds sans leur id/tag.
Je ne connais pas PostGIs et donc aucune idée si le format lui convient.

>> Le 11 septembre 2017 à 13:04, marc marc  a écrit :
>> wget -O -
>> 
>> 'http://overpass-api.de/api/interpreter?data=rel[name=Bourgogne]["disused:admin_level"=4];out;'
>>  
>> | egrep '(
>> bourgogne.osm
Le 11/09/2017 à 13:53, Philippe Verdy a écrit :
> pas un fichier OSM valide, ni valide en XML
> Bref il vaut mieux utiliser un vrai filtre XML basé 
> sur le DOM après parsing.
un nom de ce genre de filtre utilisable en ligne de commande ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[Samy Mezani]

Donc , pour résumer, comment n'obtenir que les *ways* membres de la 
relation et surtout leur géométrie ? (pour importer dans PostGIs, ou 
visionner dans QGis)


Mon but est de comprendre ces requêtes pour en faire d'autres sur des 
données plus fréquemment mises à jour.


Là je veux juste obtenir un multipolygone de l'ancienne Bourgogne, comme 
je le fais par exemple avec QuickOSM dans QGis, mais là uniquement en 
ligne de commande.


Merci

Samy

Le 11/09/2017 à 13:53, Philippe Verdy a écrit :



Le 11 septembre 2017 à 13:04, marc marc > a écrit :


Mais en ligne de commande si :

1) récupérer le minimum contenant les infos souhaitées :
wget -O bourgogne.osm
'http://overpass-api.de/api/interpreter?data=rel[name=Bourgogne][

"disused:admin_level"=4];out;'

2) filtrer pour ne garder que la relation, les chemins et le nom
cat bourgogne.osm | egrep '(http://overpass-api.de/api/interpreter?data=rel[name=Bourgogne][

"disused:admin_level"=4];out;'
| egrep '(
bourgogne.osm


Atention ce egrep supprime trop de choses, tu n'obtiendra pas un fichier 
OSM valide, ni valide en XML
- pour la vadlité XML il faut ajouter les balises de fermeture et 
ajouter un objet racine englobant le tout (et faire attention aux 
attributs des tags qui peuvent être sur des lignes séparées et il 
manquera alors des ">" pour terminer les tags d'ouverture)

- mais pour OSM cet objet racine doit en plus suivre le schéma OSM).

Bref ce que tu obtiens c'est juste un objet plus ou moins indenté mais 
pas sûr d'avoir tous les attributs.


De plus rien n'interdit à Overpass de renvoyer du XML compacté (sans 
aucun saut de ligne ni indentation).


Bref il vaut mieux utiliser un vrai filtre XML basé sur le DOM après 
parsing.


Noter aussi que XML/OSM n'est pas le seul format de sortie possible pour 
Overpass. XML est un peu "verbeux" avec ses tags de fermeture. D'autres 
formats possibles sont CSV, Turtle, ... Overpass permet de construire 
son format de sortie adhoc (utilisant la syntaxe de formatage pour le 
CSV). On a des exemples sur le wiki.



___
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 en ligne de commande

[Philippe Verdy]

Le 11 septembre 2017 à 13:04, marc marc  a écrit
:

> Mais en ligne de commande si :
>
> 1) récupérer le minimum contenant les infos souhaitées :
> wget -O bourgogne.osm
> 'http://overpass-api.de/api/interpreter?data=rel[name=Bourgogne][
> "disused:admin_level"=4];out;'
>
> 2) filtrer pour ne garder que la relation, les chemins et le nom
> cat bourgogne.osm | egrep '( k="name")'
>
> On peux bien sur combiner les 2 :
> wget -O -
> 'http://overpass-api.de/api/interpreter?data=rel[name=Bourgogne][
> "disused:admin_level"=4];out;'
> | egrep '( bourgogne.osm
>

Atention ce egrep supprime trop de choses, tu n'obtiendra pas un fichier
OSM valide, ni valide en XML
- pour la vadlité XML il faut ajouter les balises de fermeture et ajouter
un objet racine englobant le tout (et faire attention aux attributs des
tags qui peuvent être sur des lignes séparées et il manquera alors des ">"
pour terminer les tags d'ouverture)
- mais pour OSM cet objet racine doit en plus suivre le schéma OSM).

Bref ce que tu obtiens c'est juste un objet plus ou moins indenté mais pas
sûr d'avoir tous les attributs.

De plus rien n'interdit à Overpass de renvoyer du XML compacté (sans aucun
saut de ligne ni indentation).

Bref il vaut mieux utiliser un vrai filtre XML basé sur le DOM après
parsing.

Noter aussi que XML/OSM n'est pas le seul format de sortie possible pour
Overpass. XML est un peu "verbeux" avec ses tags de fermeture. D'autres
formats possibles sont CSV, Turtle, ... Overpass permet de construire son
format de sortie adhoc (utilisant la syntaxe de formatage pour le CSV). On
a des exemples sur le wiki.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[marc marc]

Mais en ligne de commande si :

1) récupérer le minimum contenant les infos souhaitées :
wget -O bourgogne.osm 
'http://overpass-api.de/api/interpreter?data=rel[name=Bourgogne]["disused:admin_level"=4];out;'

2) filtrer pour ne garder que la relation, les chemins et le nom
cat bourgogne.osm | egrep '(http://overpass-api.de/api/interpreter?data=rel[name=Bourgogne]["disused:admin_level"=4];out;'
 
| egrep '( bourgogne.osm


Le 11. 09. 17 à 12:55, Philippe Verdy a écrit :
> Dans Overpass tu ne peux pas choisir entre avoir un seul tag ("name=*") 
> ou tous les tags d'un objet. Tu peux en revanche obtenir la liste des 
> objets sans leur géométrie ("out;" au lieu de "out geom;")
> Regarde les paramètres possibles pour "out;" selon le niveau de 
> verbosité attendu, si tu ne veux pas la longue liste des noeuds de tous 
> les ways membres.
> 
> Le 11 septembre 2017 à 12:46, Samy Mezani  > a écrit :
> 
> En fait, je souhaite bien tous les descendants de la relation, mais
> pas les nœuds, et si possible obtenir un seul objet de type
> multipolygone.
> 
> Les données ne m'intéressent pas dans ce cas précis, si ce n'est le
> taq name.
> 
> Merci
> 
> Samy
> 
> 
> Le 11/09/2017 à 12:35, Christian Quest a écrit :
> 
> Si tu ne veux que la relation décrivant le multipolygone (et pas
> les way ni les noeuds permettant d'avoir la géométrie complète),
> retire le ">;"
> 
> Tu aura les tags de la relation, la liste des membres, mais rien
> d'autre.
> 
> 
> Le 11/09/2017 à 12:03, Samy Mezani a écrit :
> 
> Bonjour,
> 
> Je tente de faire une requête en ligne de commande pour
> obtenir un fichier osm de l'ancienne région Bourgogne.
> 
> Je veux simplement obtenir le multipolygone de son ancien
> contour.
> 
> Avec ça, j'obtiens tous les objets (nœuds) de la relation :
> 
> wget -O bourgogne.osm
> 
> "http://overpass-api.de/api/interpreter?data=(rel[name=Bourgogne][\
> 
> "disused:admin_level\"=4]);(._;>;);out
> geom;"
> 
> 
> Comment faire pour filtrer ma requête et n'obtenir que le
> multipolygone ? Je me perds dans la doc…
> 
> Merci pour vos conseils
> 
> Samy
> 
> ___
> 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
> 

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

Re: [OSM-talk-fr] requête Overpass en ligne de commande

[Philippe Verdy]

Dans Overpass tu ne peux pas choisir entre avoir un seul tag ("name=*") ou
tous les tags d'un objet. Tu peux en revanche obtenir la liste des objets
sans leur géométrie ("out;" au lieu de "out geom;")
Regarde les paramètres possibles pour "out;" selon le niveau de verbosité
attendu, si tu ne veux pas la longue liste des noeuds de tous les ways
membres.

Le 11 septembre 2017 à 12:46, Samy Mezani  a écrit :

> En fait, je souhaite bien tous les descendants de la relation, mais pas
> les nœuds, et si possible obtenir un seul objet de type multipolygone.
>
> Les données ne m'intéressent pas dans ce cas précis, si ce n'est le taq
> name.
>
> Merci
>
> Samy
>
>
> Le 11/09/2017 à 12:35, Christian Quest a écrit :
>
>> Si tu ne veux que la relation décrivant le multipolygone (et pas les way
>> ni les noeuds permettant d'avoir la géométrie complète), retire le ">;"
>>
>> Tu aura les tags de la relation, la liste des membres, mais rien d'autre.
>>
>>
>> Le 11/09/2017 à 12:03, Samy Mezani a écrit :
>>
>>> Bonjour,
>>>
>>> Je tente de faire une requête en ligne de commande pour obtenir un
>>> fichier osm de l'ancienne région Bourgogne.
>>>
>>> Je veux simplement obtenir le multipolygone de son ancien contour.
>>>
>>> Avec ça, j'obtiens tous les objets (nœuds) de la relation :
>>>
>>> wget -O bourgogne.osm "http://overpass-api.de/api/in
>>> terpreter?data=(rel[name=Bourgogne][\"disused:admin_level\"=4]);(._;>;);out
>>> geom;"
>>>
>>>
>>> Comment faire pour filtrer ma requête et n'obtenir que le multipolygone
>>> ? Je me perds dans la doc…
>>>
>>> Merci pour vos conseils
>>>
>>> Samy
>>>
>>> ___
>>> 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] requête Overpass en ligne de commande

[Samy Mezani]

En fait, je souhaite bien tous les descendants de la relation, mais pas 
les nœuds, et si possible obtenir un seul objet de type multipolygone.


Les données ne m'intéressent pas dans ce cas précis, si ce n'est le taq 
name.


Merci

Samy

Le 11/09/2017 à 12:35, Christian Quest a écrit :
Si tu ne veux que la relation décrivant le multipolygone (et pas les way 
ni les noeuds permettant d'avoir la géométrie complète), retire le ">;"


Tu aura les tags de la relation, la liste des membres, mais rien d'autre.


Le 11/09/2017 à 12:03, Samy Mezani a écrit :

Bonjour,

Je tente de faire une requête en ligne de commande pour obtenir un 
fichier osm de l'ancienne région Bourgogne.


Je veux simplement obtenir le multipolygone de son ancien contour.

Avec ça, j'obtiens tous les objets (nœuds) de la relation :

wget -O bourgogne.osm 
"http://overpass-api.de/api/interpreter?data=(rel[name=Bourgogne][\"disused:admin_level\"=4]);(._;>;);out 
geom;"



Comment faire pour filtrer ma requête et n'obtenir que le 
multipolygone ? Je me perds dans la doc…


Merci pour vos conseils

Samy

___
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 en ligne de commande

[Christian Quest]

Si tu ne veux que la relation décrivant le multipolygone (et pas les way 
ni les noeuds permettant d'avoir la géométrie complète), retire le ">;"


Tu aura les tags de la relation, la liste des membres, mais rien d'autre.


Le 11/09/2017 à 12:03, Samy Mezani a écrit :

Bonjour,

Je tente de faire une requête en ligne de commande pour obtenir un 
fichier osm de l'ancienne région Bourgogne.


Je veux simplement obtenir le multipolygone de son ancien contour.

Avec ça, j'obtiens tous les objets (nœuds) de la relation :

wget -O bourgogne.osm 
"http://overpass-api.de/api/interpreter?data=(rel[name=Bourgogne][\"disused:admin_level\"=4]);(._;>;);out 
geom;"



Comment faire pour filtrer ma requête et n'obtenir que le 
multipolygone ? Je me perds dans la doc…


Merci pour vos conseils

Samy

___
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] requête Overpass en ligne de commande

[Philippe Verdy]

Déjà tu peux enlever l'union avec la récursion descendante "(._;>;);" si tu
ne veux que la relation multipolygone, et pas ses descendants; mais ensuite
"out geom;" ne te servira bas beaucoup puisqu'il n'y a pas de géométrie
dans un multipolygone mais juste ses descendants; je suppose que tu veux
ses tags et un "out;" simple suffit". Tu peux choisir une option plus
économique pour "out;" si tu ne veux que le type d'objet et l'id (suffisant
pour charger l'objet seul dans JOSM).
JOSM malgré tout chargera lui-même tous les tags, et la liste complète
des membres
(mais à l'état "incomplet" : tu peux ensuite charger les membres
descendants sélectivement ou bien tous)

Le 11 septembre 2017 à 12:03, Samy Mezani  a écrit :

> Bonjour,
>
> Je tente de faire une requête en ligne de commande pour obtenir un fichier
> osm de l'ancienne région Bourgogne.
>
> Je veux simplement obtenir le multipolygone de son ancien contour.
>
> Avec ça, j'obtiens tous les objets (nœuds) de la relation :
>
> wget -O bourgogne.osm "http://overpass-api.de/api/in
> terpreter?data=(rel[name=Bourgogne][\"disused:admin_level\"=4]);(._;>;);out
> geom;"
>
>
> Comment faire pour filtrer ma requête et n'obtenir que le multipolygone ?
> Je me perds dans la doc…
>
> Merci pour vos conseils
>
> Samy
>
> ___
> 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] requête Overpass en ligne de commande

[Samy Mezani]

Bonjour,

Je tente de faire une requête en ligne de commande pour obtenir un 
fichier osm de l'ancienne région Bourgogne.


Je veux simplement obtenir le multipolygone de son ancien contour.

Avec ça, j'obtiens tous les objets (nœuds) de la relation :

wget -O bourgogne.osm 
"http://overpass-api.de/api/interpreter?data=(rel[name=Bourgogne][\"disused:admin_level\"=4]);(._;>;);out 
geom;"



Comment faire pour filtrer ma requête et n'obtenir que le multipolygone 
? Je me perds dans la doc…


Merci pour vos conseils

Samy

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

hebdoOSM Nº 372 2017-08-29-2017-09-04

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 372 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/9432/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] comment cartographier un marais ?

[Jean-Marc Liotier]

On Thu, 7 Sep 2017 18:07:38 +0200
Adrien Grellier  wrote:
>
> Pour les canaux, il faudrait indiquer un sens de circulation de l'eau
> (waterway=stream)… En l’occurrence, c'est tout plat, l'eau ne court
> pas comme dans une rivière ! Comment doit-on procéder dans le cas
> présent ?

https://lists.openstreetmap.org/pipermail/tagging/2017-September/033403.html
propose flow_direction=both.

https://taginfo.openstreetmap.org/keys/flow_direction#values - peu
utilisé mais me semble approprié.

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

Re: [OSM-talk-fr] Plus aucun rapprochement entre OSM et la BANO depuis fin juillet

[Christian Quest]

Le 9 septembre 2017 à 17:41, David Marchal  a écrit :

>
> Le 31 août 2017 à 14:31, Christian Quest  a
> écrit :
>
> On 2017-08-30 15:20, Christian Quest wrote:
>
> Les données du cadastre vont être très (très) prochainement disponibles
> sur leur forme brute et vectorielle et on n'aura plus à faire ce
> bricolage complexe et fragile.
>
>
> La diffusion a été confiée par la DGFiP à Etalab... c'est pour ça que je
> peux confirmer que c'est près de la sortie du tuyau ;)
>
>  Ah, enfin ! Là, ça va bien mieux faire avancer le Schmilblick pour
> l’exploitation des données cadastrales, plutôt que de devoir faire des
> bidouillages sur les sorties PDF qui prennent du temps à développer,
> maintenir et exécuter. Je ne sais pas à qui on doit ça, mais bien joué, qui
> que ce soit.
>


C'est un travail de longue haleine qui a impliqué du monde... vu que c'est
passé par la Loi (pour une République Numérique) et tout ce qu'il y a en
amont (étude d'impact, consultation publique, etc) puis ce qu'il y a en
aval (un décret, un arrêté)... et l'application finale de tout ça !

Pour les dates, les données contiennent les dates de mise à jour de chaque
objet, on saura donc quand le cadastre a mis à jour ou ajouté tel ou tel
objet (comme un bâtiment ou un point adresse). Ceci va permettre de mieux
suivre l'évolution du cadastre.
Par contre, il n'y a pas d'identifiant unique de bâtiment, seules les
parcelles ont des identifiants et il faudra donc toujours faire quelques
opérations géométriques pour savoir si on parle du même objet.

Bref, on va passer à une toute autre dimension dans l'exploitation des
données cadastrales. Les outils existants vont devoir être revus voire
repensés pour en tirer le maximum, ceci prendra forcément un peu de temps.

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