Re: [OSM-talk-fr] Tags addr: pour les radars

2020-09-06 Par sujet Christian Quest 

Le 06/09/2020 à 22:23, Romain MEHUT a écrit :


Bonjour,

Quand j'ai supprimé les polygones boundary=urban, il m'est arrivé de 
faire quelques corrections annexes comme de retirer des tags 
addr:country, addr:city en particulier sur les relations des radars de 
vitesse.


Un contributeur m'a contacté car il utilise ces tags pour contrôler 
leur présence via la requête suivante :


[out:csv(::id,type,enforcement,"addr:country",maxspeed,"addr:city","addr:postcode","addr:street",ref,milestone,name)];
relation ["addr:country"="FR"] [type=enforcement] 
[enforcement=maxspeed] ({{bbox}});

out;

Je lui répond qu'OSM étant par nature une base de données 
géographiques, ces tags sont inutiles et que l'on peut remonter ces 
informations pour chaque objet /via/ un géocodage. Il me demande alors 
une requête qui le permet sans les tags addr:


J'ai testé ceci :

[out:csv(::id,maxspeed,ref,milestone,name,::lat,::lon)];
area[name="France"]->.pays;
relation(area.pays) [type=enforcement] [enforcement=maxspeed];
node(r:device);
out;

et suis passé par https://geo.api.gouv.fr/adresse et /reverse/csv/ 
pour retrouver la ville et le code postal.


Vous validez ma méthode et vous êtes d'accord pour retirer les tags 
addr: ?


Merci.

Romain



Attention: le géocodage inverse risque de ne pas donner de résultat 
lorsqu'il n'y a pas d'adresse numérotée à proximité (ce qui est probable 
avec un radar en pleine cambrousse).


Il n'y a pas de recherche faite avec les emprises des communes par ce 
endpoint d'API mais uniquement par proximité avec une adresse numérotée.



--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] La gestion des poteaux

2020-09-06 Par sujet Philippe Verdy 
Et contrairement à Enedis, je n'ai pas trouvé d'OpenData concernant
"Seolis" (le réseau des Deux-Sèvres: Enedis est y présent aussi mais
seulement pour certaines communes denses où les deux réseaux se recouvrent
et ou s'interconnectent partiellement), il semble que Seolis délègue ses
données à "Geredis" qui lui non plus ne semble pas avoir de données
ouvertes (selon le service ScanR du ministère de la recherche, des
références en tant qu'organisation mais presque tout est vide hormis
quelques rapports de thèses ou des analyses financières et quelques
statistiques).
J'ai bien trouvé des accès à ces données (sans savoir ce
qu'elles contiennent, les descriptions sont trop sommaires) mais c'est via
un intranet ou des accès payants (abonnement requis, et il semle que seuls
les gestionnaires de réseaux et producteurs y ont un accès facile, il n'y a
rien pour les particuliers)

Sinon j'ai trouvé l'agence ORE:
https://opendata.agenceore.fr/explore/dataset/distributeurs-denergie-par-commune/information/
Mais ça référence juste des organisations, pas les réseaux et il y a très
peu de détails (on a plus d'infos dans les RCS ou services info-greffe): ce
n'est en fin de compte qu'un annuaire.

Mais la liste est intéressante pour savoir à qui on pourrait s'adresser
pour leur demander leurs données ouvertes (celles au moins que leur impose
la loi : ces données existent peut-être le papier mais pas immédiatement
accessibles en ligne ou dans un format ou une API libre et documentée; on
pourrait se retrouver là aussi avec des données brutes ou pas facilement
utilisables et aucune visualisation, ou des demandes à faire une par une
sur des points isolés).

Je ne suis même pas certain que les obligations de données ouvertes
s'imposent à toutes les organisations concernées (notamment les très
petites, tels que les micro-producteurs, liés à un contrat privé avec un
autre fournisseur d'énergie qui leur achète tout et peut-être aussi les
finance en partie

Le dim. 6 sept. 2020 à 23:08, Philippe Verdy  a écrit :

> Merci pour ce lien. Dommage qu'il faille télécharger un gros fichier ZIP
> national et aucun outil de recherche (la carte affichée sur la page n'est
> qu'un fond générique, elle n'en fait aucun rendu, et il n'y a pas d'ouil de
> sélection sur cette page même si elle prétend le contraire).
>
> En gros il faut charger dans JOSM ou un logiciel SIG avec une config
> solide avant de pouvoir commencer à en utiliser un extrait ou commercer un
> travail de fusion. (pour les postes de conversion, les 2000 entrées
> ponctuelles ça passe facilement, mais pour le reste on parle de millions
> d'enregistrements avec une cartographie linéaire bien plus lourde en
> dizaines de millions de points: n'importe qui ne peut pas exploiter ça).
>
> Et pas moyen non plus de faire accepter ce rendu dans des outils
> génériques (comme uMap): ça rame beaucoup trop. Ces données sont plutôt
> destinées à être improtées dans une base mais on ne peut pas les importer
> directement dans OSM sans travil de fusion: il faut une autre base (sinon
> des millions de doublons à éliminer après coup).
>
> Avez-vous trouvé un rendu utilisable (par exemple en tant que couche
> sélectionnable) ou activable sous Layers (par exemple dans iD avec un "add
> custom layer"?) qui permettrait de travailler par zones plus petites?
>
> Sinon il semble que ce jeu ne soit pas complet: je note des tas de bouts
> de lignes aériennes (20kV: pas les grand pylones mais des poteaux avec 1 à
> 3 câbles) visibles sur l'imagerie mais absentes du jeu publié  (et même on
> voit leur interconnexion avec la partie publiée, et sans poste de
> transformation aux noeuds de répartition, même s'il y a éventuellement
> juste des coupe-circuits, impossibles à voir). Et je ne parle pas su réseau
> de distribution BT (220-400 V, mono ou triphasé) ni de la partie enterrée
> (qui ne semble à peu près complète qu'en milieu urbain dense).
>
> Il semble que ces données oublient les lignes qui desservent des clients
> éloignés isolés et pas gros consommateurs (par exemple vers une seule
> ferme, une résidence un hameau avec 2 ou 3 maisons) ou des lignes de
> dérivation ajoutées juste pour le maillage et permettant de contourner des
> pannes ou coupure sur une ligne (ces lignes ne sont pas toujours sous
> tension, pour éviter des problèmes de pertes importante par déphasage en
> fonction des longueurs de parcours, elles peuvent s'activer juste par
> télécommande quand un autre circuit est coupé), ni les lignes qui
> permettent de "booster" la puissance disponible (pour certaines entreprises
> dans une petite zone artisanale, quand le réseau urbain attenant n'a pas la
> capacité suffisante, ou pour franchir certains obstacles naturels (un bois,
> une rivière).
>
> Bref on a des lignes HT (~20kV) déjà dans OSM (classées somme lignes
> "mineures"), assez facilement observables (dans l'imagerie, niveau de zoom
> minimum de 16 dans les champs cultivés, parfois il faut plus dans les zones
> forestières ou à

Re: [OSM-talk-fr] Tags addr: pour les radars

2020-09-06 Par sujet Philippe Verdy 
Ca marche aussi... à peu près. Cela dépend de la précision de
  area[name="France"]
telle que dans l'instance utilisée: c'est un très grand polygone qui a été
simplifié pour des raisons de performance (il y a quelques débordements aux
frontières, pas sûr qu'il y ait un "buffer" défini autour de largeur
correspondant à la précision de simplification du polygone complet tel que
défini dans OSM) et qui n'est pas non plus synchronisé en permanence (ceci
dit les frontières nationales bougent très peu, hormis quelques menus
changements liés aux conflations de sources différentes et quelques
désaccord frontaliers comme autour du Mont-Blanc avec l'Italie, avec des
recouvrements partiels des revendications, ceci dit ça n'affecte
principalement que des zones naturelles pas tellement concernées par ces
limites de vitesse dans des parcs naturels de toute façon pas accessible ou
interdits aux véhicules usuels, et où les limites de vitesse théoriques ne
peuvent même pas être atteintes en sécurité, ceci dépendant largement des
véhicules, de leur charge, leur capacité de freinage, leur gabarit, leurs
équipements, et sinon les autorisations d'accès)
Ces "areas" peuvent ne pas suffire, c'est juste approprié pour une
recherche simple, mais il faut ensuite tenter de localiser des unités plus
petites (par exemple une limite de commune). Les "areas" ne sont pas
tellemetn fait pour le géocodage précis, ce sont juste des filtres de
sélection pour les recherches. Si on veut un géocodage précis, il y a
d'autres outils plus appropriés  ou on doit faire des recherches
complémentaires.

Je pense même que pour les limites de vitesse, puisqu'elles sont de la
compétence préfectorale (même si elles sont issues de décisions
municipales), l'unité de recherche la plus approprié est le département, et
là on a des polygones précuis sans nécessiter de grosses simplifications.

D'ailleurs je me demande pourquoi on n'a pas une API dédiée au géocodage.


Le dim. 6 sept. 2020 à 22:23, Romain MEHUT  a
écrit :

> Bonjour,
>
> Quand j'ai supprimé les polygones boundary=urban, il m'est arrivé de faire
> quelques corrections annexes comme de retirer des tags addr:country,
> addr:city en particulier sur les relations des radars de vitesse.
>
> Un contributeur m'a contacté car il utilise ces tags pour contrôler leur
> présence via la requête suivante :
>
>
> [out:csv(::id,type,enforcement,"addr:country",maxspeed,"addr:city","addr:postcode","addr:street",ref,milestone,name)];
> relation ["addr:country"="FR"] [type=enforcement] [enforcement=maxspeed]
> ({{bbox}});
> out;
>
> Je lui répond qu'OSM étant par nature une base de données géographiques,
> ces tags sont inutiles et que l'on peut remonter ces informations pour
> chaque objet *via* un géocodage. Il me demande alors une requête qui le
> permet sans les tags addr:
>
> J'ai testé ceci :
>
> [out:csv(::id,maxspeed,ref,milestone,name,::lat,::lon)];
> area[name="France"]->.pays;
> relation(area.pays) [type=enforcement] [enforcement=maxspeed];
> node(r:device);
> out;
>
> et suis passé par https://geo.api.gouv.fr/adresse et /reverse/csv/ pour
> retrouver la ville et le code postal.
>
> Vous validez ma méthode et vous êtes d'accord pour retirer les tags addr: ?
>
> Merci.
>
> Romain
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] La gestion des poteaux

2020-09-06 Par sujet Philippe Verdy 
Merci pour ce lien. Dommage qu'il faille télécharger un gros fichier ZIP
national et aucun outil de recherche (la carte affichée sur la page n'est
qu'un fond générique, elle n'en fait aucun rendu, et il n'y a pas d'ouil de
sélection sur cette page même si elle prétend le contraire).

En gros il faut charger dans JOSM ou un logiciel SIG avec une config solide
avant de pouvoir commencer à en utiliser un extrait ou commercer un travail
de fusion. (pour les postes de conversion, les 2000 entrées ponctuelles ça
passe facilement, mais pour le reste on parle de millions d'enregistrements
avec une cartographie linéaire bien plus lourde en dizaines de millions de
points: n'importe qui ne peut pas exploiter ça).

Et pas moyen non plus de faire accepter ce rendu dans des outils génériques
(comme uMap): ça rame beaucoup trop. Ces données sont plutôt destinées à
être improtées dans une base mais on ne peut pas les importer
directement dans OSM sans travil de fusion: il faut une autre base (sinon
des millions de doublons à éliminer après coup).

Avez-vous trouvé un rendu utilisable (par exemple en tant que couche
sélectionnable) ou activable sous Layers (par exemple dans iD avec un "add
custom layer"?) qui permettrait de travailler par zones plus petites?

Sinon il semble que ce jeu ne soit pas complet: je note des tas de bouts de
lignes aériennes (20kV: pas les grand pylones mais des poteaux avec 1 à 3
câbles) visibles sur l'imagerie mais absentes du jeu publié  (et même on
voit leur interconnexion avec la partie publiée, et sans poste de
transformation aux noeuds de répartition, même s'il y a éventuellement
juste des coupe-circuits, impossibles à voir). Et je ne parle pas su réseau
de distribution BT (220-400 V, mono ou triphasé) ni de la partie enterrée
(qui ne semble à peu près complète qu'en milieu urbain dense).

Il semble que ces données oublient les lignes qui desservent des clients
éloignés isolés et pas gros consommateurs (par exemple vers une seule
ferme, une résidence un hameau avec 2 ou 3 maisons) ou des lignes de
dérivation ajoutées juste pour le maillage et permettant de contourner des
pannes ou coupure sur une ligne (ces lignes ne sont pas toujours sous
tension, pour éviter des problèmes de pertes importante par déphasage en
fonction des longueurs de parcours, elles peuvent s'activer juste par
télécommande quand un autre circuit est coupé), ni les lignes qui
permettent de "booster" la puissance disponible (pour certaines entreprises
dans une petite zone artisanale, quand le réseau urbain attenant n'a pas la
capacité suffisante, ou pour franchir certains obstacles naturels (un bois,
une rivière).

Bref on a des lignes HT (~20kV) déjà dans OSM (classées somme lignes
"mineures"), assez facilement observables (dans l'imagerie, niveau de zoom
minimum de 16 dans les champs cultivés, parfois il faut plus dans les zones
forestières ou à fort relief ou végétation irrégulière, dans les
forêts voir les poteaux n'est pas évident car on ne repère pas leur ombre
même si on s'attend à les trouver au bord d'un chemin d'exploitation ou
d'une route forestière ou qu'il doit en exister pour relier les habitats ou
entreprises isolées), qui ne sont pas dans ce fichier. OSM s'emble à
peut près au point seulement pour les grandes artères en très haute tension
(sur gros pylones).

Le dim. 6 sept. 2020 à 18:17, François Lacombe 
a écrit :

> Bonjour à vous
>
> Merci d'avoir complété ces quelques points.
>
> Concernant la présence de lignes aériennes en zone Enedis, tout est
> maintenant connu et publié en opendata
> https://www.enedis.fr/cartographie-des-reseaux-denedis
> Il est possible de s'en servir pour contribuer à OSM, aucune ligne HTA 20
> 000 volts ou BT 220 volts ne peut vous échapper dans 95% des communes en
> France métropolitaine.
> Les 5% restant arrivent bientôt.
>
> Les postes HTA/BT sont aussi disponibles mais aucun attribut ne permet de
> déterminer s'ils sont sur un poteau ou pas
>
> Le souterrain a commencé à être intégré à Caen et Dijon avec de bons
> résultats.
> A chaque point de connection aérien/souterrain se trouve un poteau.
>
> Donc avec ces données + vues aériennes, il est au moins possible de savoir
> où les poteaux sont manquants.
>
> Bonne fin de weekend
>
> François
>
> Le ven. 4 sept. 2020 à 20:45, Francois Gouget  a écrit :
>
>> On Thu, 3 Sep 2020, Philippe Verdy wrote:
>> [...]
>> > > Le nombre de cables se voit sur les photos aériennes.
>> >
>> > Pas toujours il y a plein de petites lignes même si on est capable de
>> le
>> > dire. Difficile de dire souvent s'il y a 3 ou 5 câbles ou plus. ou même
>> > s'il y en a plus d'un seul.
>>
>> On parle bien du 20kV, pas du 400V en aval des transformateurs de
>> distribution ? Les lignes 400V sont effectivement ingérables. Pareil pour
>> les lignes téléphoniques.
>>
>>
>> > Ca dépend beaucoup du fond (y compris la saison),
>>
>> Ils sont effectivement beaucoup plus visibles sur les fonds sombres que
>> les fonds clairs. C'est pas très pratique dans les

[OSM-talk-fr] Tags addr: pour les radars

2020-09-06 Par sujet Romain MEHUT 

Bonjour,

Quand j'ai supprimé les polygones boundary=urban, il m'est arrivé de 
faire quelques corrections annexes comme de retirer des tags 
addr:country, addr:city en particulier sur les relations des radars de 
vitesse.


Un contributeur m'a contacté car il utilise ces tags pour contrôler leur 
présence via la requête suivante :


[out:csv(::id,type,enforcement,"addr:country",maxspeed,"addr:city","addr:postcode","addr:street",ref,milestone,name)];
relation ["addr:country"="FR"] [type=enforcement] [enforcement=maxspeed] 
({{bbox}});

out;

Je lui répond qu'OSM étant par nature une base de données géographiques, 
ces tags sont inutiles et que l'on peut remonter ces informations pour 
chaque objet /via/ un géocodage. Il me demande alors une requête qui le 
permet sans les tags addr:


J'ai testé ceci :

[out:csv(::id,maxspeed,ref,milestone,name,::lat,::lon)];
area[name="France"]->.pays;
relation(area.pays) [type=enforcement] [enforcement=maxspeed];
node(r:device);
out;

et suis passé par https://geo.api.gouv.fr/adresse et /reverse/csv/ pour 
retrouver la ville et le code postal.


Vous validez ma méthode et vous êtes d'accord pour retirer les tags addr: ?

Merci.

Romain

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

Re: [OSM-talk-fr] maxspeed par défaut

2020-09-06 Par sujet Gad Jo 
Oui erreur de jeunesse que je n'ai pas remis au goût du jour faute de 
l'utiliser.

Veuillez ignorer mon dernier retour sur le nombre de voies. C'est bien le 
nombre total de voies existante sur la chaussée qui est à indiquer

Le September 4, 2020 9:03:57 AM UTC, osm.sanspourr...@spamgourmet.com a écrit :
>Le 03/09/2020 à 16:05, Percherie OnDaNet - perche...@toutenkamion.net a
>écrit
>
>>> Attention pour le nombre de voies. C'est le nombre de voies par sens
>>> de circulation. Je m'en suis rendu compte quand mes applications de
>>> routage m'indiquez 4 voies (2 + 2 par sens) sur une route de
>>> campagne. C'était une découverte sur un cas pratique.
>>
>> Non, c'est bien le nombre *total* de voies :
>>
>> FR:Key:lanes /
>> /
>>
>> /La clé //lanes=*//doit être utilisée pour indiquer le nombre total
>> marquées de voies. /
>>
>Vérifié et confirmé.
>
>Jean-Yvon
>
>P. S.  : FR:Key:lanes#Présupposés
>
>indique bien quand on peut se contenter du nombre de voies par défaut.

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] La gestion des poteaux

2020-09-06 Par sujet François Lacombe 
Bonjour à vous

Merci d'avoir complété ces quelques points.

Concernant la présence de lignes aériennes en zone Enedis, tout est
maintenant connu et publié en opendata
https://www.enedis.fr/cartographie-des-reseaux-denedis
Il est possible de s'en servir pour contribuer à OSM, aucune ligne HTA 20
000 volts ou BT 220 volts ne peut vous échapper dans 95% des communes en
France métropolitaine.
Les 5% restant arrivent bientôt.

Les postes HTA/BT sont aussi disponibles mais aucun attribut ne permet de
déterminer s'ils sont sur un poteau ou pas

Le souterrain a commencé à être intégré à Caen et Dijon avec de bons
résultats.
A chaque point de connection aérien/souterrain se trouve un poteau.

Donc avec ces données + vues aériennes, il est au moins possible de savoir
où les poteaux sont manquants.

Bonne fin de weekend

François

Le ven. 4 sept. 2020 à 20:45, Francois Gouget  a écrit :

> On Thu, 3 Sep 2020, Philippe Verdy wrote:
> [...]
> > > Le nombre de cables se voit sur les photos aériennes.
> >
> > Pas toujours il y a plein de petites lignes même si on est capable de le
> > dire. Difficile de dire souvent s'il y a 3 ou 5 câbles ou plus. ou même
> > s'il y en a plus d'un seul.
>
> On parle bien du 20kV, pas du 400V en aval des transformateurs de
> distribution ? Les lignes 400V sont effectivement ingérables. Pareil pour
> les lignes téléphoniques.
>
>
> > Ca dépend beaucoup du fond (y compris la saison),
>
> Ils sont effectivement beaucoup plus visibles sur les fonds sombres que
> les fonds clairs. C'est pas très pratique dans les vignobles, plus simple
> là où il y a des prairies. Mais même si on ne voit pas le nombre de cables
> à un endroit donné, on peut souvent les compter dans un autre champ un peu
> plus loin.
>
> > Et de toute façon pas moyen de deviner les tensions transportées et le
> > mode (nombre de phases ou continu à certains endroits)
>
> Comme dit précédemment la tension se déduit des transformateurs qu'on
> trouve sur la ligne.
>
>
> > Les transfos sont également pas faciles à voir (et pas toujours montés en
> > haut des poteaux,
>
> Les transformateurs au sol sont au sol sont généralement en bordure des
> villes. Pour eux il faut compté sur les photos de rue.
>
> Mais en campagne c'est huit voir neuf transformateurs sur 10 qui se
> trouvent en haut du poteau. Ceux-là font une généralement une verrue bien
> repérable sur l'ombre du poteau.
>
> https://www.openstreetmap.org/edit#map=21/45.77978/-0.09650
>
> Du coup ça fait un bon faisceau d'indices : verrue sur l'ombre + ligne 3
> cables qui arrive + proche d'un transformateur manquant sur Osmose + à
> coté d'un hameau => il y a un transformateur.
>
>
> > et ce transfo est souvent caché dans la végétation
>
> D'accord avec toi mais en remplaçant 'souvent' par 'parfois'. La verrue
> est aussi parfois moins visible quand le poteau est dans l'axe du soleil.
>
>
> > parfois enterré sous une trappe difficile à voir (ou dans une armoire
> > difficile à distinguer d'une armoire télécoms;
>
> Tout ça ne concerne que les villes. Et dans ce cas c'est clair qu'i faut
> des photos de rue.
>
>
> > Pour le gaz c'est plus facile car le chemin est marqué par des gros
> points
> > jaunes ou chapiteaux jaunes sur un poteau très visibles presque partout
> et
> > presque toujours en bordure de chemin ou en limite de parcelle sur une
> aire
> > dégagée.
>
> Oui. Et il y a moins de marqueurs que de poteaux électriques. Mais les
> marqueurs faits pour être vus d'hélicoptère sont assez rares et quand on
> n'a qu'eux je ne suis pas sûr que le tracé du pipeline soit bien précis.
> Pour bien faire il faut aussi avoir les marqueurs triangulaires (pedestal)
> mais ils sont très durs à repérer 'en grous il faut identifier 4 pixels un
> peu clairs en losange de part et d'autre d'une route proche du tracé
> supposé du pipeline).
>
>
> > Sinon si j'ai des doutes, tant pis je ne relie pas:
>
> Oui. Pareil.
>
>
> --
> Francois Gouget  >___
> 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] hebdoOSM Nº 528 2020-08-25-2020-08-31

2020-09-06 Par sujet theweekly . osm 
Bonjour,

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

https://www.weeklyosm.eu/fr/archives/13678/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

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