Re: [OSM-talk-fr] admin_level sur des chemins non fermés

[Jérôme Amagat]

sur une relation, le tag admin_level donne le niveau hiérarchique
administratif donc en france permet de savoir si la relation représente une
commune, departement, region, ...
mais ce tag est aussi utiliser sur tous les way frontières donc sur tous
les way qui font partie d'une relation admin_level et on prend le plus
petit nombre sur ces relations pour mettre dans le admin_level=* de la
frontière. Cela permet de savoir que tel way fermé ou non est une frontière
entre 2 communes, département, région ...
Normalement tous les way faisant partie d'une relation
boundary=administrative doivent avoir un tag admin_level

(ce admin_level sur les way en france fait doublon et est inutile car
toutes les relations représentant les différent admin_level (commune
arrondissement departement...) existent et on peut en déduire pour chaque
way quelle frontière c'est. Mais c'est la règle actuellement)


Le 19 juillet 2017 à 13:49, marc marc  a écrit :

> Je comprend très bien la fusion d'un chemin avec la limite
> administrative, c'est très courant et très pratique,
> le problème n'est pas là.
>
> Une département est décrit par une area via une relation utilisant de
> nombreux chemin. Dans le cas de mon mon premier exemple
> https://www.openstreetmap.org/relation/7401
> Le tag sur la relation dit que cette area est un département.
> jusque là c'est parfaitement juste.
>
> https://www.openstreetmap.org/way/457978185
> mais pourquoi est-ce que ce bout de chemin est tagé en admin_level ?
> quelques mètres plus loin il ne l'est plus
> quelques metres avant non plus
> ce chemin est un simple chemin, ce n'est pas un département, ce n'est
> qu'un membre de la relation qui décrit le département.
> le tag "département" est sur la relation,
> il n'y a aucun sens qu'un élément individuels de la relation ai lui
> aussi le tag admin_level
> sinon à te lire, si ce tag était justifié sur un chemin, il devrait
> l'être aussi sur le bout de chemin quelques mètres plus loin.
>
> c'est comme pour un itinéraire de bus. tu met les tag de la ligne de bus
> uniquement sur la relation, tu ne dupliques pas une partie des tag de la
> relation sur un chemin individuel.
>
> est-ce que c'est plus clair ainsi dit ?
>
> ___
> 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] Repères de crues

[osm . sanspourriel]

/contenant des informations à caractère personnel /

Donc pas de soucis pour osm mais potentiellement pour des 
ré-utilisateurs des données ?


Le 20/07/2017 à 00:29, Donat ROBAUX - dona...@gmail.com a écrit :

Bonjour à tous,

Je me rappelle avoir vu passer un message concernant les repères de crues.
En faisant ma cartographie des églises, je suis tombé là dessus: 
https://www.reperesdecrues.developpement-durable.gouv.fr/ (ne me 
demandez pas comment...)


C'est un site participatif avec fond OSM. Les données sont a priori en 
open-data d'après ce que j'ai compris de la licence.
/Dès lors qu’il respecte les conditions décrites supra, le 
ré-utilisateur est autorisé à :

 - reproduire, copier, publier et transmettre « l’Information » ;
 - diffuser et redistribuer « l’Information » ;
 - adapter, modifier, extraire et transformer à partir de « 
l’Information », notamment pour créer des « Informations dérivées » ;/


Une phrase me laisse toutefois songeur: /Cependant, tout croisement 
des informations contenues sur le site 
www.reperesdecrues.developpement-durable.gouv.fr 
, en 
particulier de la géolocalisation des repères de crues, avec d’autres 
bases de données contenant des informations à caractère personnel 
telles que définies par la CNIL est formellement interdit./


Donat


___
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] Repères de crues

[Donat ROBAUX]

Bonjour à tous,

Je me rappelle avoir vu passer un message concernant les repères de crues.
En faisant ma cartographie des églises, je suis tombé là dessus:
https://www.reperesdecrues.developpement-durable.gouv.fr/ (ne me demandez
pas comment...)

C'est un site participatif avec fond OSM. Les données sont a priori en
open-data d'après ce que j'ai compris de la licence.



*Dès lors qu’il respecte les conditions décrites supra, le ré-utilisateur
est autorisé à : - reproduire, copier, publier et transmettre «
l’Information » ; - diffuser et redistribuer « l’Information »
; - adapter, modifier, extraire et transformer à partir de «
l’Information », notamment pour créer des « Informations dérivées » ;*

Une phrase me laisse toutefois songeur: *Cependant, tout croisement des
informations contenues sur le
site www.reperesdecrues.developpement-durable.gouv.fr
, en particulier
de la géolocalisation des repères de crues, avec d’autres bases de données
contenant des informations à caractère personnel telles que définies par la
CNIL est formellement interdit.*

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

[OSM-talk-fr] opening_hours pathologiques

[osm . sanspourriel]

Bonjour,

Un peu comme l'extinction partielle de l'éclairage public il y a les 
magasins de seconde main :


dans le premier cas on a envie de mettre non pas ouvert (allumé) / fermé 
(éteint) mais le pourcentage.


C'est exclusif (si on a 10 % on n'a pas 50 %) comme un agenda d'une salle.

Les magasins de seconde main (mais il y a sûrement d'autres cas) ont des 
horaires de réception des dons différents des horaires de vente.


Ce n'est pas exclusif : ça peut être ouvert à la vente et à la réception 
ou pas.


Mettre peut-être artificiellement deux nœuds, un à la réception et 
l'autre à la vente ?


Des meilleurs propositions ? Voir ci-dessous une alternative.

Sur https://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours je trouve :

Sunrise / Sunset 



Expressing end at  but not after  



women/men-only days 



Alors (sunset-00:15)-22:30;22:30-dusk"{'t':{'lit:dimmer':'50'}}"; pour 
un éclairage de 15 minutes avant le coucher du soleil à 22:30 et réduit 
à 50 % de 22:30 à l'aube ?


Pour les horaires de vente et d'achat des descriptions telles que 
"{'t':{'sell':'yes'}}" "{'t':{'buy':'yes'}}" 
"{'t':{'sell':'yes'},{'t':{'buy':'yes'}}"
Si vous voulez un exercice pratique  : 
http://www.emmaus-redene.com/contact#horaires.

À défaut :
opening_hours: 
url=http://www.emmaus-redene.com/contact#horaires.


Mais si http://projets.pavie.info/yohours (ou un autre outil mais j'aime 
bien yohours) n'a pas une interface adaptée pour, c'est ingérable.

Par exemple on décrit des tags.
sell=yes
buy=yes

on leur donne des petits noms si on veut un truc plus sexy
Par exemple en json simplifié {opening_hour:rule=sell, sell=yes}.
{opening_hour:rule=buy, buy=yes}.
{opening_hour:rule=both, sell=yes, buy=yes}.
{opening_hour:rule=closed}.
on les sélectionne (sélection multiple possible) et ensuite quand on 
"peint" la zone agenda on dépose la/les opening_hour:rule sélectionnés.

Donc en version brute on afficherait un buy=yes et sinon un simple buy.

Peut-être simplifier en mettant des couleurs/motifs et des légendes ?
opening_hour:rule:colour et opening_hour:rule:pattern ?

Attention aux daltoniens ! L'un n'empêche pas l'autre et l'info peut 
être sauvegardée textuellement, l'affichage peut-être un choix de 
l'utilisateur lors de l'édition.
Pour les couleurs, proposer bien-sûr des schémas de ColorBrewer2.org 
. Ça pourrait 
même être automatique  : la première règle décrite a la première 
couleur, etc...


Des opinions ? En particulier d'un certain développeur ? ;-)

Jean-Yvon

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

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

[osm . sanspourriel]

Un gros tas de tels polygones sont les imports CLC (tu y as fait allusion).

Par contre beaucoup existent encore en France (les terres associées aux 
fermes).


Comme tu as de gros bousins à la topographie imprécise et devenue fausse 
(grignotage d'environ un département depuis l'import) les reprendre n'a 
pas grand sens.


J'ai un doute ces données ont été supprimées ? Par chez moi je ne les 
retrouve effectivement pas.


Quant aux niveaux administratifs, trouver le bon niveau c'est juste 
prendre le max des valeurs des relations (si une frontière sert une 
limite de commune et une limite de département on la voit comme une 
limite départementale), je ne vois pas de cas où la valeur se justifie 
au niveau d'un way s'il fait partie d'une relation de type 
administratif. Sinon il doit être fermé.


admin_level=3 sur une relation ça veut dire que les chemins de la 
relation sont au moins de niveau 3.


admin_level=5 sur une relation ça veut dire que les chemins de la 
relation sont au moins de niveau 5.


Si un chemin fait partie de ces deux relations alors il est représenté 
comme admin_level=3 au moins.



Le 19/07/2017 à 14:11, Philippe Verdy - verd...@wanadoo.fr a écrit :
Là on tombe sur un vieux traitement effectué par la conversion OSM 
vers GIS: c'est lui qui essaye de "deviner" les tags manquants des 
relations en allant les chercher sur les membres afin de produire un 
polygone GIS avec assez de tags significatifs.


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

Re: [OSM-talk-fr] Retrouver les contributeurs d'un tag

[Philippe Verdy]

Je "plussoie", un tri par id ne sert pas à grand chose sauf pour des
recherches par id ou pour créer une table de données à indexer sur le même
critère.
Le tri "quadtile" est nettement plus pratique et même souvent plus rapide
(quand on a fait une recherche par bbox car c'est déjà l'ordre où on
récupère nativement les données trouvées et aussi un ordre proche de
l'ordre de stockage physique dans la base si celle-ci est organisées avec
des index en "cluster" géographiques, comme c'est fait pour la base
utilisée pour le rendu afin d'augmenter les performances en réduisant
siginificativement les I/O car cela regroupe naturellement les données
d'objets proches dans beaucoup mois de pages dispersées sur disque et
indépendamment de leur date de création qui détermine l'ID qui leur a été
attribué: les IDs sont totalement dispersés).
Il n'y a pas d'option de tri personnalisé selon les colonnes personnalisées
du CSV généré. Le but d'Overpass est d'abord de fournir des données le plus
rapidement possible aux clients (sans surcharge excessive et non nécessaire
sur le serveur) à charge pour eux de trier comme ils veulent les données
obtenues: un tri sur serveur est en effet couteux en espace de stockage
temporaire car on ne peut rien retourner aux client avant d'avoir le jeu de
données complet.

Je pense même que toutes les options de tri dans Overpass (par id comme par
quadtile) devraient être supprimées pour ne retourner que les données
obtenues au fil de l'eau en fonction des meilleurs index utilisés selon la
requête ou des infos statistiques sur leur densité ou sélectivité qui peut
varier selon les régions et la quantité de mises à jour qui y ont été
faites que la requette finisee par utiliser un index plutot qu'un autre ou
faire des fusions de sous-sélections ou des accès indexés récursifs, et
quelque soit la méthode d'indexation des fusions de sous-sélections et leur
représentation interne ou la présence éventuelle de caches sur le serveur
et d'autres contraintes que le moteur SQL est seul à maîtriser (en
association avec les systèmes de fichiers utilisés et les matériels de
stockage qui fournissent aussi des statistiques de performance), et en
fonction aussi des autres usages concurrents: le but est avant tout de
répondre au plus grand nombre et ne pas privilégier un utilisateur au
détriment des autres qui se partagent la même ressource.

Je note toutefois qu'Overpass maintenant a des contraintes d'usage plus
élevées: je tombe régulièrement sur des erreurs fatales disant que j'aurait
dépassé un certain quota, qui me semble maintenant très bas, et même peut
être dépassé par une seule requête simple retournant des données peu
volumineuses et à priori très sélectives. On doit faire avec. Mais si
l'usage augmente, gérer des tris sur le serveur est une option inutile, le
tri est toujours ce qui coûte le plus cher.

Le 19 juillet 2017 à 19:47,  a écrit :

> asc trie par type d'objet puis par id croissant :
>
> http://overpass-turbo.eu/s/qu0
> Évite de trier au niveau d'Overpass, le retour sera plus rapide.
> Hormis à te proposer -u pour éviter les doublons ;-), non je n'ai rien
> proposer. Même sur Windows tu as des portages de sort.
>
> N.B. : la doc dit par id croissant.
>
>
> Le 19/07/2017 à 13:22, marc marc - marc_marc_...@hotmail.com a écrit :
>
> Le 18. 07. 17 à 23:33, osm.sanspourr...@spamgourmet.com a écrit :
>  > http://overpass-turbo.eu/s/qsd
>
> http://wiki.openstreetmap.org/wiki/FR:Overpass_API/Overpass_QL#Personnalisation_du_format_CSV
>
> Merci !
>
> J'ai également cherché la date de dernière modif
> mais je n'arrive pas à la trier.
> D'après la doc c'est le paramètre asc mais je l'utilise visiblement 
> malhttp://overpass-turbo.eu/s/qtg
> c'est pas trop grave, un petit coup de "|sort" sous linux me l'a fait
> mais si tu as une piste, je suis preneur
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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] Retrouver les contributeurs d'un tag

[osm . sanspourriel]

asc trie par type d'objet puis par id croissant :

http://overpass-turbo.eu/s/qu0

Évite de trier au niveau d'Overpass, le retour sera plus rapide.
Hormis à te proposer -u pour éviter les doublons ;-), non je n'ai rien  
proposer. Même sur Windows tu as des portages de sort.


N.B. : la doc dit par id croissant.

Le 19/07/2017 à 13:22, marc marc - marc_marc_...@hotmail.com a écrit :

Le 18. 07. 17 à 23:33, osm.sanspourr...@spamgourmet.com a écrit :
  > http://overpass-turbo.eu/s/qsd

http://wiki.openstreetmap.org/wiki/FR:Overpass_API/Overpass_QL#Personnalisation_du_format_CSV

Merci !

J'ai également cherché la date de dernière modif
mais je n'arrive pas à la trier.
D'après la doc c'est le paramètre asc mais je l'utilise visiblement mal
http://overpass-turbo.eu/s/qtg
c'est pas trop grave, un petit coup de "|sort" sous linux me l'a fait
mais si tu as une piste, je suis preneur
___
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] admin_level sur des chemins non fermés

[Philippe Verdy]

Là on tombe sur un vieux traitement effectué par la conversion OSM vers
GIS: c'est lui qui essaye de "deviner" les tags manquants des relations en
allant les chercher sur les membres afin de produire un polygone GIS avec
assez de tags significatifs.

Il y a eu des discussions récemment pour supprimer à terme ce traitement
(issu d'anciennes façons de taguer partiellement les multipolygones ou de
ne pas les taguer du tout). Ce traitement devrait être supprimé maintenant
(le nettoyage de la base a eu lieu massivement sur ce sujet, mais il en
reste encore par endroit de ces relations mal fichues et incomplètes assez
souvent tant dans leurs tags que dan la liste de leurs membres qui ne
décrivent pas des contours fermés).

Tu peux penser que taguer les admin_level sur les chemins membres est
redondant, certes mais ce n'est pas suffisant pour transformer une chemin
en polygone frontière valide (d'autant plus qu'il y a plusieurs admin_level
candidats : la convention prise est de prendre la plus petite valeur parmi
les candidats). Mais cette redondance (partielle) est encore très pratique
pour pas mal de recherches.

Ce n'est en tout cas pas le tag admin_level sur un chemin qui en fait une
frontière. Les conditions nécessaires et suffisantes ne sont pas réunies
par ce seul fait et la velur indiqué sur le cemin n'est pas nécessairement
celle applicable aux polygones frontières qui doivent avoir leurs propres
tags de classification indépendamment des chemins membres référencés.


Le 19 juillet 2017 à 13:59, David Crochet  a écrit :

> Bonjour
>
>
> Le 19/07/2017 à 13:49, marc marc a écrit :
>
>> est-ce que c'est plus clair ainsi dit ?
>>
>
> Mais si ce chemin fait parti de plusieurs relations, quelle étiquette va
> t'il prendre de quel relation ? Le système ne peut pas le lui dire, donc on
> le lui dit.
>
> Si une limitre administrative est "département", elle est "arrondisement",
> elle est "canton", et elle est "commune". Ces informations là seront dans
> chacune des relations.
>
> Pour dire que ce bout de chemin (donc pas l'avant ni l'après) est une
> limite administrative, on le lui dit et on lui attribut le niveau
> administrative de niveau le plus "élevé" si l'on peut lui donner une
> hiérarchie.
>
> Cordialement
>
> --
> David Crochet
>
>
>
> ___
> 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] admin_level sur des chemins non fermés

[David Crochet]

Bonjour


Le 19/07/2017 à 13:49, marc marc a écrit :

est-ce que c'est plus clair ainsi dit ?


Mais si ce chemin fait parti de plusieurs relations, quelle étiquette va 
t'il prendre de quel relation ? Le système ne peut pas le lui dire, donc 
on le lui dit.


Si une limitre administrative est "département", elle est 
"arrondisement", elle est "canton", et elle est "commune". Ces 
informations là seront dans chacune des relations.


Pour dire que ce bout de chemin (donc pas l'avant ni l'après) est une 
limite administrative, on le lui dit et on lui attribut le niveau 
administrative de niveau le plus "élevé" si l'on peut lui donner une 
hiérarchie.


Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

[marc marc]

Je comprend très bien la fusion d'un chemin avec la limite 
administrative, c'est très courant et très pratique,
le problème n'est pas là.

Une département est décrit par une area via une relation utilisant de 
nombreux chemin. Dans le cas de mon mon premier exemple
https://www.openstreetmap.org/relation/7401
Le tag sur la relation dit que cette area est un département.
jusque là c'est parfaitement juste.

https://www.openstreetmap.org/way/457978185
mais pourquoi est-ce que ce bout de chemin est tagé en admin_level ?
quelques mètres plus loin il ne l'est plus
quelques metres avant non plus
ce chemin est un simple chemin, ce n'est pas un département, ce n'est 
qu'un membre de la relation qui décrit le département.
le tag "département" est sur la relation,
il n'y a aucun sens qu'un élément individuels de la relation ai lui 
aussi le tag admin_level
sinon à te lire, si ce tag était justifié sur un chemin, il devrait 
l'être aussi sur le bout de chemin quelques mètres plus loin.

c'est comme pour un itinéraire de bus. tu met les tag de la ligne de bus 
uniquement sur la relation, tu ne dupliques pas une partie des tag de la 
relation sur un chemin individuel.

est-ce que c'est plus clair ainsi dit ?

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

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

[Philippe Verdy]

En particulier la relation à problème est comme celle-ci
https://www.openstreetmap.org/relation/2606660#map=13/47.3181/-1.7153

Là on a un multipolygone complètement invalide, sans tag, et non fermé
(pour un vieux landuse de CORINE mal découpé et mal tagué): on tombe sur le
cas où la conversion OSM vers GIS essaye d'interpréter ce polygone mal
fichu en cherchant des tags sur les chemins membres.

C'est cette relation qu'il faut corriger. Le chemin en question en revanche:

https://www.openstreetmap.org/way/30828584

est correctement tagué aussi en tant que frontière et est bien membre d'une
dizaine de relations frontières tout à fait correctes.



Le 19 juillet 2017 à 13:22, Philippe Verdy  a écrit :

> Je crois que tu comprends mal... Osmose ne fais pas comme ça. Non pas
> besoin de chemin fermé, les admin_level sur les chemins ne sont pas
> invalides mais hautement recommandés, mais ils doivent effectivement être
> membres d'une relation boundary pour prendre sens en tant qu'objet
> "département" d'autant plus que cette valeur est surtout destiné à pas mal
> de moterus de rendus pour afficher les pointillés qui sinon disparaissent.
>
> Bref ce que tu demandes est complètement faux, tu as mal lu la doc.
>
> Ici tu as un chemin qui est AUSSI une partie membre d'une frontière
> administrative. C'est un cas très fréquent sur les routes et rivières: la
> fusion des chemins superposés n'est pas fausse, c'est même une
> recommandation. Si ces tracés sont différents on les détache et il n'y a
> plus de fusion des tags non plus.
>
> Nulle part ce tag indique "qu'une route se prend pour un département". Si
> cela arrive c'est parce qu'il y a d'autres relations qui ont été taguée, là
> par erreur, comme des frontières adminsitratives et reprennent ce chemin.
> Ce n'est pas le chemin qui est en cause mais ces autres relations.
>
>
> Le 19 juillet 2017 à 12:34, marc marc  a écrit
> :
>
>> Bonjour,
>>
>> Il me semble qu'il y a de nombreuses anomalies avec ce tag
>>
>> exemple
>> https://www.openstreetmap.org/way/457978185
>> un bout de chemin en forêt qui se prend pour un département
>> depuis le changeset 44193985
>>
>> https://www.openstreetmap.org/way/30828584
>> une route qui se prend pour un arrondissement
>> difficile de retrouver le changeset problématique. cela semble avoir
>> lieu y a 4 ans sur le changeset 14088954
>>
>> en admin_level=8 cela explose : 2799 chemins sont admin_level et highway
>> Sans doute une partie sont réellement des limites communales constitué
>> d'un seul chemin qui fait un boucle.
>> mais en piochant pour 10 pour vérif, ce sont des chemins qui ne
>> devraient pas avoir le tag de limite communale en tant que tel
>> exemple http://www.openstreetmap.org/way/221500211
>> exemple d'autant plus étonnant que la version #1 contenait déjà l'erreur
>> serrais-ce un import qui a foiré ?
>> un habitude jadis de dupliquer les tag sur la commune sur chaque chemin
>> de sa frontière ?
>>
>> osmose détecte 3 bouts erronés parce qu'inclus dans une relation
>> > https://osmose.openstreetmap.fr/fr/map/?item=6010
>> Même si je ne comprend pas pourquoi cette liste est vide
>> https://osmose.openstreetmap.fr/fr/errors/?country=france&item=6010
>>
>> Mais par contre les autres ne sont pas détecté, c'est p'tre l'occasion
>> d'ajouter le test dans osmose qu'une limite administrative doit être un
>> polygone fermé
>>
>> c'est ici qu'on propose cela ou osmose-cont...@openstreetmap.fr ?
>>
>> l'autre solution plus rapide c'est de scripter pour faire par exemple
>> ressortir tout les admin_level=8 dont le nom de l'objet n'est pas celui
>> d'une commune réelle et virer le(s) tag de ces chenins concernés.
>> Si quelqu'un est motivé.. :)
>>
>> Cordialement,
>> Marc
>> ___
>> 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] Retrouver les contributeurs d'un tag

[marc marc]

Le 18. 07. 17 à 23:33, osm.sanspourr...@spamgourmet.com a écrit :
 > http://overpass-turbo.eu/s/qsd
> http://wiki.openstreetmap.org/wiki/FR:Overpass_API/Overpass_QL#Personnalisation_du_format_CSV

Merci !

J'ai également cherché la date de dernière modif
mais je n'arrive pas à la trier.
D'après la doc c'est le paramètre asc mais je l'utilise visiblement mal
http://overpass-turbo.eu/s/qtg
c'est pas trop grave, un petit coup de "|sort" sous linux me l'a fait
mais si tu as une piste, je suis preneur
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

[Philippe Verdy]

Je crois que tu comprends mal... Osmose ne fais pas comme ça. Non pas
besoin de chemin fermé, les admin_level sur les chemins ne sont pas
invalides mais hautement recommandés, mais ils doivent effectivement être
membres d'une relation boundary pour prendre sens en tant qu'objet
"département" d'autant plus que cette valeur est surtout destiné à pas mal
de moterus de rendus pour afficher les pointillés qui sinon disparaissent.

Bref ce que tu demandes est complètement faux, tu as mal lu la doc.

Ici tu as un chemin qui est AUSSI une partie membre d'une frontière
administrative. C'est un cas très fréquent sur les routes et rivières: la
fusion des chemins superposés n'est pas fausse, c'est même une
recommandation. Si ces tracés sont différents on les détache et il n'y a
plus de fusion des tags non plus.

Nulle part ce tag indique "qu'une route se prend pour un département". Si
cela arrive c'est parce qu'il y a d'autres relations qui ont été taguée, là
par erreur, comme des frontières adminsitratives et reprennent ce chemin.
Ce n'est pas le chemin qui est en cause mais ces autres relations.


Le 19 juillet 2017 à 12:34, marc marc  a écrit :

> Bonjour,
>
> Il me semble qu'il y a de nombreuses anomalies avec ce tag
>
> exemple
> https://www.openstreetmap.org/way/457978185
> un bout de chemin en forêt qui se prend pour un département
> depuis le changeset 44193985
>
> https://www.openstreetmap.org/way/30828584
> une route qui se prend pour un arrondissement
> difficile de retrouver le changeset problématique. cela semble avoir
> lieu y a 4 ans sur le changeset 14088954
>
> en admin_level=8 cela explose : 2799 chemins sont admin_level et highway
> Sans doute une partie sont réellement des limites communales constitué
> d'un seul chemin qui fait un boucle.
> mais en piochant pour 10 pour vérif, ce sont des chemins qui ne
> devraient pas avoir le tag de limite communale en tant que tel
> exemple http://www.openstreetmap.org/way/221500211
> exemple d'autant plus étonnant que la version #1 contenait déjà l'erreur
> serrais-ce un import qui a foiré ?
> un habitude jadis de dupliquer les tag sur la commune sur chaque chemin
> de sa frontière ?
>
> osmose détecte 3 bouts erronés parce qu'inclus dans une relation
> > https://osmose.openstreetmap.fr/fr/map/?item=6010
> Même si je ne comprend pas pourquoi cette liste est vide
> https://osmose.openstreetmap.fr/fr/errors/?country=france&item=6010
>
> Mais par contre les autres ne sont pas détecté, c'est p'tre l'occasion
> d'ajouter le test dans osmose qu'une limite administrative doit être un
> polygone fermé
>
> c'est ici qu'on propose cela ou osmose-cont...@openstreetmap.fr ?
>
> l'autre solution plus rapide c'est de scripter pour faire par exemple
> ressortir tout les admin_level=8 dont le nom de l'objet n'est pas celui
> d'une commune réelle et virer le(s) tag de ces chenins concernés.
> Si quelqu'un est motivé.. :)
>
> Cordialement,
> Marc
> ___
> 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] commune et extinction nocturne de l'éclairage public

[marc marc]

Le 18. 07. 17 à 23:46, Paul Desgranges a écrit :
>   Le défaut d'un nouveau tag c'est que cela crée 2 tags en
>   concurrence.
>   Une commune qui passe entièrement à un éclairage sur
>   détecteur est selon
>   moi le top pour entrer dans cette catégorie.
>   il faudrait lit=motion mais en même temps lit=extinction_policy
>  >>> Oui
>  >> Comme c'est pas possible il faudra faire un choix :)
>  >> je pense que lit=motion est mieux et que la décision politique doit
>  >> aller sur un autre tag
>  > Je n'ai pas compris la valeur motion et si tu as un cas précis :
>  > quelle commune aurait quelle valeur par exemple.
> 
> J'avais lu le cas d'une commune qui avait remporté un prix de
> l'efficacité énergétique en migrant son éclairage public sur détecteur
> avec un échange de donnée entre lampadaire pour que la détection d'une
> voiture à x km/h allume les x lampadaires suivant dans la direction du
> mouvement tandis qu'un piéton en allumerait moins mais + longtemps.
> 
> je ne sais pas si c'est à l'échelle d'une commune entière, ou plutôt à 
> l'échelle d'un boulevard, une allée, un quartier, un lampadaire c'est 
> pourquoi je demandais si tu connaissais le cas d'une commune et laquelle 
> qui pourrait être tagguée entièrement en motion ou automatic ?
Je ne connais pas personnellement de cas d'une commune complète
mais en cherchant sur le net on trouve de nombreux exemples.

selon ce lien, Troyes serrait passé à un éclairage modulé en puissance
> https://www.ville-troyes.fr/uploads/Document/a1/4218_358_Press_Troyes_239.pdf
a prendre avec des pincettes parce qu'il semble mélanger 
puissance/consommation/facture a plusieurs reprise.
un peu plus loin on lira que la performance lumineuse a augmenté de 50%
la puissance électrique étant quasi inchangée, il faut en déduire qu'il 
en a profité pour augmenter massivement les lux... dommage..
au final led+détecteur ne font que -58% (c'est génial mais en venant 
d'un éclairage en partie halogène, je serrais curieux de recalculer 
l'économie en l'absence d'augmentation lumineuse)
un peu plus loin on lira qu'il y a un quartier avec détecteur + 
diminution de la puissance après une certaine heure
si c'est confirmé, la commune devrait avoir un tag dimmer,
le quartier expérimenal un tag dimmer+automatic

un quartier 240 lampes. je crois que c'est eux qui ont gagné le prix
> https://www.rtbf.be/info/regions/detail_wavre-va-equiper-l-un-de-ses-quartiers-d-un-eclairage-public-intelligent?id=896124
>  > https://www.youtube.com/watch?v=SJoSRKmIUKo
Je sais même pas comment on devrait le tager vu que j'ignore quel est la 
config finale choisie, mais potentiellement les 3

cette page prétend qu'en 2015 2 capitales y passent (blog commercial)
> http://blog.sirris.be/fr/blog/des-led-intelligentes-pour-remplacer-leclairage-public-classique

> il y a 5000 occurrences de ce tag dont 2 sur des relations (mais
> overpass peine à les trouver)
> Oui à l'échelle d'un lampadaire, ou d'une voie, mais pas une commune 
> entière ?
Je suppose qu'avec autant de tag, il doit y avoir des 
quartiers/villages/communes qui sont passé aux détecteurs.
Il n'ont cependant pas l'air d’être renseigné car les quelques cas 
trouvé sont des erreurs de tag difficile à filtrer
http://overpass-turbo.eu/s/qsU

> Mais on a déjà du mal à spécifier les tags de ce qui existe
>  maintenant alors c'est encore plus difficile à faire pour le futur ?
Je pense qu'à l'avenir, on pourrait demander une assistance osmose genre
"toutes les lampes d'une commune ont tel tag avec telle valeur, vérifier 
si celui-ci serrait adapté sur la commune"
cela n’empêche évidement pas de mettre un tag sur les communes même 
lorsque aucune lampe n'est renseigné dans osm

> lit= existe déjà. autant garder ce principe au
> lieu d'avoir 2 tags qui peuvent avoir les mêmes valeurs
> 
> Mais pas à l'échelle d'une commune si ?

je ne comprend pas le sens de ta question.
pourquoi ne pas garder la syntaxe existante des rues pour les communes ?
je ne vois pas ce qu'on gagne à avoir une syntaxe ou des tag différent 
selon la grandeur de l'objet.
Autant avoir une règle unique pour les heures d'éclairage qui peux 
"remonter" lampe -> rue -> quartier -> commune. non ?

> Paul qu'en penses-tu ? est-ce que cela rencontre suffisamment ton
> souhait tout en tenant comptes des différentes objections ?
> Je ne souhaitais certainement pas réfléchir à ceci de manière globale, 
> je ne m'en estime pas capable, je ne suis pas du tout expert dans le 
> domaine de l'éclairage :-)
moi non plus, juste un passionné d'efficacité énergétique :)
je te pensais juste proposer des améliorations mais te laisser porter ta 
proposition :)

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

[OSM-talk-fr] admin_level sur des chemins non fermés

[marc marc]

Bonjour,

Il me semble qu'il y a de nombreuses anomalies avec ce tag

exemple
https://www.openstreetmap.org/way/457978185
un bout de chemin en forêt qui se prend pour un département
depuis le changeset 44193985

https://www.openstreetmap.org/way/30828584
une route qui se prend pour un arrondissement
difficile de retrouver le changeset problématique. cela semble avoir 
lieu y a 4 ans sur le changeset 14088954

en admin_level=8 cela explose : 2799 chemins sont admin_level et highway
Sans doute une partie sont réellement des limites communales constitué 
d'un seul chemin qui fait un boucle.
mais en piochant pour 10 pour vérif, ce sont des chemins qui ne 
devraient pas avoir le tag de limite communale en tant que tel
exemple http://www.openstreetmap.org/way/221500211
exemple d'autant plus étonnant que la version #1 contenait déjà l'erreur
serrais-ce un import qui a foiré ?
un habitude jadis de dupliquer les tag sur la commune sur chaque chemin 
de sa frontière ?

osmose détecte 3 bouts erronés parce qu'inclus dans une relation
> https://osmose.openstreetmap.fr/fr/map/?item=6010
Même si je ne comprend pas pourquoi cette liste est vide
https://osmose.openstreetmap.fr/fr/errors/?country=france&item=6010

Mais par contre les autres ne sont pas détecté, c'est p'tre l'occasion 
d'ajouter le test dans osmose qu'une limite administrative doit être un 
polygone fermé

c'est ici qu'on propose cela ou osmose-cont...@openstreetmap.fr ?

l'autre solution plus rapide c'est de scripter pour faire par exemple 
ressortir tout les admin_level=8 dont le nom de l'objet n'est pas celui 
d'une commune réelle et virer le(s) tag de ces chenins concernés.
Si quelqu'un est motivé.. :)

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

Re: [OSM-talk-fr] Avenue Foch à Paris : passages autorisés aux vélos ou pas?

[Thomas Ruchin]

Bonjour

La réponse est simplement à chercher dans la règlementation locale
https://api-site-cdn.paris.fr/images/155185.pdf

Article 4 - Conditions de circulation et de stationnement
la circulation piétonne est prioritaire en tout lieu.
Dans les jardins non clos, la pratique du vélo est tolérée sur les allées
sauf en cas de forte densité du public ou indication contraire. Les
agents publics sont habilités à faire mettre pied à terre dans les cas
où la densité des piétons serait de nature à provoquer une pratique
dangereuse du vélo. Le déplacement s’effectue au pas.



--> Comme les jardins de l'avenue Foch ne sont pas clos, les vélos y sont
tolérés.

Thomas

Le 19 juillet 2017 à 01:59, Philippe Verdy  a écrit :

> En principe on met plutôt "*access*"=permissive quand il y a une tolérance
> mais pas de priorité car la voie est destinée avant tout aux autres usagers.
>
> Ceci dit en France les piétons sont prioritaires partout, même sur la
> chaussée, sauf en cas d'interdiction explicite (voies express et chaussées
> d'autoroute hors des barrières de sécurité et quelques ponts et tunnels peu
> larges quand un autre accès parallèle leur a été destiné, et cas
> temporaires dans des zones de travaux où un panneau oblige à traverser la
> rue à cause de l'emprise d'un chantier).
>
> En cas d'accident, le piéton aura toujours raison devant un tribunal (même
> en cas de comportement volontairement dangereux de sa part!) tout bonnement
> car les autres usagers sont sensés être assurés (les piétons n'ont pas
> cette obligation et peuvent n'être couvert que par les assurances
> facultatives individuelles, qui n'ont qu'un intérêt temporaire vu que de
> toute façon elles se retourneront toujours ensuite contre le possesseur du
> véhicule et ses assurances, ou sinon contre le fonds d'indemnisation en cas
> de défaut de l'assurance; si le véhicule n'était pas assuré, le conducteur
> s'expose à de lourdes sanctions pénales et la saisie de ses biens); les
> assurances des véhicules doivent obligatoirement couvrir les dommages
> causés aux tiers, même en l'absence de responsabilité directe du conducteur
> (et même en l'absence du conducteur par exemple si le véhicule est volé, ou
> si un piéton se blesse tout seul sur un véhicule stationné régulièrement).
>
> Les seuls cas d'absence de responsabilité du conducteur déclaré du
> véhicule sont quand le piéton a causé lui-même le dommage qui l'a touché
> par un acte de violence volontaire dont il pouvait légitimement présumer
> des conséquences (et cet acte volontaire reste à démontrer, ce qui n'est
> pas toujours facile, et l'intention volontaire n'est pas démontrée si le
> piéton est mineur ou légalement irresponsable de ses actes...). Bref mieux
> vaut être assuré même si on est "bon conducteur", on ne peut pas savoir ce
> qu'on aura à supporter sinon car tout le monde se retournera contre lui
> (même s'il n'y a aucun retrait de points ou de permis du conducteur pour
> cet accident car il n'y a pas eu de "faute" de conduite, ce retrait sera
> automatique en cas de défaut d'assurance constaté, qui à lui seul est une
> faute grave: quand on est assuré, on finance aussi les fonds
> d'indemnisation des victimes...).
>
> Mais tout cycliste mettant pied à terre devient un piéton, au même titre
> que quelqu'un portant un sac, une valise ou avec une poussette ou un
> landeau. En revanche n'est pas piéton celui qui reste sur ses rollers ou
> sur une planche ou tout système d'assistance motorisé (hors cas des
> véhicules légers pour handicapés et de vitesse limitée roulant au pas, et
> qui ont comme les piétons le droit d'emprunter la chaussée ou les bandes
> cyclables). Les cyclistes n'ont pas pas plus de priorité que les autres
> véhicules même s'ils ont des possibilités supplémentaires ou des
> interdictions explicites les concernant sur les voies rapides.
>
>
> Le 18 juillet 2017 à 19:05, Shohreh  a écrit :
>
>> Bonjour,
>>
>> Actuellement, ces passages en terre en diagonale avenue Foch à Paris sont
>> taggés "Allowed Access : Bicycle=yes":
>>
>> https://s24.postimg.org/w96svt56t/Avenue.Foch.passage.diagonale.jpg
>>
>> http://www.openstreetmap.org/?mlat=48.8722&mlon=2.2827#map=1
>> 7/48.87206/2.28221
>>
>> Pourtant, c'est sur le trottoir et il n'y a pas de panneaux autorisants
>> les
>> cyclistes. Donc a priori, l'accès est réservé aux piétons, et aux
>> cyclistes
>> qui ont mis pied à terre.
>>
>> Qu'en pensez-vous?
>>
>> Merci.
>>
>>
>>
>> --
>> View this message in context: http://gis.19327.n8.nabble.com
>> /Avenue-Foch-a-Paris-passages-autorises-aux-velos-ou-pas-tp5899448.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
>
>
__