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

[Philippe Verdy]

>
> A noter aussi concernant les ouvrages enterrés notamment
>
https://www.reseaux-et-canalisations.ineris.fr/gu-presentation/construire-sans-detruire/actualites.html

Demain une nouvelle mise à jour de la cartographie (arrêt prévu pendant 3
heures, ensuite on va voir ce que ça donne et si c'est utilisable pour les
télédéclarations de travaux (qui concernent tout le monde).
Mais l'arrêt prévu est déjà en vigueur semble-t-il alors que ça devait être
demain soir.

Une partie cependant fonctionne, la recherche des exploitants de réseau sur
une emprise pas trop grande pour un chantier:
https://www.reseaux-et-canalisations.ineris.fr/gu-presentation/front/carto.action

Ca n'affiche pas les réseaux trouvés mais ça indique qui contacter pour les
demandes d'autorisation (plus besoin d'aller en mairie, c'est le
téléservice qui gère ça au plan national, et pour tous les réseaux: eau,
gaz, électricité, eaux usées, chauffage, téléphonie/fibres, signalisation,
éclairage public...). On ne peut pas aller plus loin (pas d'OpenData) car
la suite demande une authentifiction auprès du service pàour compléter un
dossier. Ce n'est pas fait pour de la carto libre ou l'information générale.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Philippe Verdy]

Le lun. 7 sept. 2020 à 22:37, François Lacombe 
a écrit :

> Bonsoir à tous
>
> 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).
>>
>
> Le découpage départemental a été demandé par plusieurs personnes et est
> dans les tuyaux.
> Il y a la plateforme opendata qui permet d'afficher les données sur le
> mode carte d'opendatasoft
> https://data.enedis.fr/explore/?sort=modified=Infrastructures
>

Hier quand je visitais le site, la carte était entièrement vide. Maintenant
elle affiche le détail, mais la possibilité annoncée de télécharger les
shapefiles, là je ne vois rien (double-clic, clic droit, boutons des
barres...)
Je pense que cette carte est en cours de remise à jour et que la
possibilité existait dans une ancienne version, mais a du avoir de gros
problèmes de stabilité.
Je pense que ça devrait revenir dans quelques temps.
En tout cas merci de ce rappel (j'avais noté cette page mais en attendant
on peut juste survoler la page et zoomer la carte pour comparer (d'autant
qu'on a un fond de carte ESRI aligné à peu près sur OSM, sauf données IGN,
mais ce fond semble prendre pour base une version ancienne d'OSM au vu des
tracés : on doit conc aussi comparer avec l'imagerie OrthoBD pour
positionner correctement les points trouvés, pas toujours faciles à voir
sur l'imagerie car ça prend un temp fou pour zoomer un peu partout et ne
pas "perdre le fil" ou simplement être certain que c'est bien un poteau et
pas un artefact de l'imagerie ou un autre élément, notamment sur une
végétation haute ou dans les zones industrielles ou bâties: un poteau
ressemble beaucoup à un tronc d'arbre ou un autre poteau pour autre chose
et là encore on ne voit pas toujours très bien les fils pour confirmer et
qu'il y a un écart de parallaxe des fils en hauteur et le pied visible et
pas toujours l'ombre pour savoir où est le pied exactement si on ne voit
que les porteurs au sommet comme une tâche un peu grisâtre: dififile de
voir s'iul y a un transfo en haut sur les conversions HT/BT, mais au moins
cette carte permet de le voir en regardant la typologie des couleurs sur
les classes de tensions).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[François Lacombe]

Bonsoir à tous

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).
>

Le découpage départemental a été demandé par plusieurs personnes et est
dans les tuyaux.
Il y a la plateforme opendata qui permet d'afficher les données sur le mode
carte d'opendatasoft
https://data.enedis.fr/explore/?sort=modified=Infrastructures


> 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).
>

Attention, ces tronçons de ligne ont surement été déposés ou Enedis n'est
pas exploitant sur la commune. Le jeu de données est normalement à jour du
1er semestre 2020
Si la ligne est sur la vue aérienne mais pas dans le jeu de données, il
faut aller vérifier sur place


> 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).
>

Je veux bien regarder un exemple de ce genre de cas si possible


> 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).
>

L'import des réseaux moyenne et basse tensions prendra des années, c'est
vrai. Ce qui laisse de bonnes séances de carto, survey et vérifications
pour tout le monde !
Sans compter que nous collectons aujourd'hui plus de données sur le terrain
sur les réseaux aériens qu'il n'y a dans l'opendata.


Le lun. 7 sept. 2020 à 00:54, Philippe Verdy  a écrit :

> 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).
>

Et pourtant Gérédis est le 1er gestionnaire de réseau à avoir ouvert ses
données après Enedis fin 2019.
https://www.geredis.fr/Cartographie-et-reseaux


>
> 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.
>

C'est un travail déjà énorme.
Le recensement des sociétés parmi plus de 640 concessions a pris un certain
temps, d'autant que les plus petits acteurs n'ont pas les moyens de
participer à la même hauteur que les gros.
Cela vaudrait le coup de l'intégrer dans Osmose pour vérifier le tag
operator=* de plusieurs objets mais j'avoue ne pas avoir l'énergie pour
tout faire.


> Mais la liste est intéressante pour savoir à qui on pourrait s'adresser
> pour leur demander leurs données ouvertes 

[OSM-talk-fr] Figurines d'écoliers cartoon aux passages piétons des écoles

[Matthieu Godet via Talk-fr]

Bonjour,

Est-ce que vous avez déjà eu à cartographier des figurines géantes 
d’écoliers près des écoles ? J’ai fait quelques recherches mais rien 
trouvé, donc je ne sais pas si c’est la première cartographiée. J’ai mis 
artwork_type, le problème étant que ce n’est pas unique voir le point 
ici (j’ai aussi une photo prise sur Wikimedia) : 
https://www.openstreetmap.org/node/7879590266 



On en trouve ailleurs en France (l'entreprise a aussi des clients en 
Belgique selon cet article 
) 
voir les réalisations sur 
https://www.serac-signalisation.fr/Realisations 
 (au passage ils font 
d’autres équipements esthétiques à placer près des écoles comme des 
panneaux informatifs, des obstacles type barrière).
Peut-être que traffic sign serait mieux comme c’est la fonction 
principale de ce genre d’équipement (informer et sécuriser la zone en 
complément des zones 30 comme expliqué sur le site), et que ce n’est pas 
une œuvre au sens où on en trouve partout.


J'aimerais avoir votre avis sur comment le cartographier, et si c'est 
inédit, pourquoi pas envisager de le documenter sur le wiki (nouvelle 
page avec un renvoi sur les pages road signs/écoles ?).

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

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

[Romain MEHUT]

Bonsoir,

Pour aller au bout, quelqu'un saurait-il si on peut géocoder directement 
via la requête overpass turbo ?


Merci.

Romain

Le 07/09/2020 à 20:17, Jérôme Amagat a écrit :

avec les addr:* (pas besoin de bbox) :
[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];
out;
https://overpass-turbo.eu/s/XMY
la response est quasi instantanée :)

par contre la solution donnée :
[out:csv(::id,maxspeed,ref,milestone,name,::lat,::lon)];
area[name="France"]->.pays;
relation(area.pays) [type=enforcement] [enforcement=maxspeed];
node(r:device);
out;
ne donne que les infos de "node(r:device);" dans le csv donc seulement 
les coordonnées.


comme ça (j'ai rajouté dans le csv les même colonnes que dans la 1e 
requête, certains radars ont encore les addr:*) :

[out:csv(::id,type,enforcement,"addr:country",maxspeed,"addr:city","addr:postcode","addr:street",ref,milestone,name,::lat,::lon)];
area[name="France"]->.pays;
relation(area.pays) [type=enforcement] [enforcement=maxspeed];
out center;
https://overpass-turbo.eu/s/XN6
on a les infos des relations et les coordonnées du "centre" de la 
relation , pas obligatoirement dans la même commune que le radar, mais 
je ne sais pas comment faire une sortie avec les coordonnées du 
"device". Et si il a besoin des adresses, je ne sais pas non plus...



La position des radars est presente sur 
https://radars.securite-routiere.gouv.fr/ , mais pas moyen de trouver 
les données "brute".
Quelqu'un semble avoir recuperer les données du site : 
https://www.data.gouv.fr/fr/datasets/radars-automatiques/


On peut lire en bas de la page https://radars.securite-routiere.gouv.fr/,
"Les données radars sont affichées à titre indicatif et mises à jour 
régulièrement : date de mise à jour le 06 novembre 2018" :)




___
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] Rencontre mensuelle du Groupe de Lyon 8/09/2020 - 18h30

[Leroy Olivier]

Hello !

Coincé encore à Sainté ... je vous souhaite de dévaliser la banque !

J'espère à la prochaine !

Olivier

Le lun. 7 sept. 2020 à 21:20, Rene Chalon <
local-l...@listes.openstreetmap.fr> a écrit :

> Bonsoir à tous,
>
> Nous avons le plaisir de vous annoncer que les réunions régulières du
> groupe de Lyon reprennent de manière physique au Tuba après la longue
> parenthèse en visioconférence. La prochaine aura lieu :
>
> le MARDI 8 SEPTEMBRE à partir de 18h30
> au TUBA, 145 cours Lafayette, 69003 LYON,
> dans la salle "Banque" (ancienne salle des coffres - vaut le voyage ;-) )
>
> Si vous souhaitez mettre un sujet particulier à l'ordre du jour de la
> rencontre, vous pouvez l'ajouter sur la page :
> https://wiki.openstreetmap.org/wiki/FR:Lyon/R%C3%A9union_08_septembre_2020
>
> Renecha pour le groupe de Lyon.
>
>
>

-- 
Olivier Leroy
Docteur Géographie et Environnement
Post-doctorant EVS IMU GOURAMIC
06.18.37.18.08
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Rencontre mensuelle du Groupe de Lyon 8/09/2020 - 18h30

[Rene Chalon]

Bonsoir à tous,

Nous avons le plaisir de vous annoncer que les réunions régulières du 
groupe de Lyon reprennent de manière physique au Tuba après la longue 
parenthèse en visioconférence. La prochaine aura lieu :


le MARDI 8 SEPTEMBRE à partir de 18h30
au TUBA, 145 cours Lafayette, 69003 LYON,
dans la salle "Banque" (ancienne salle des coffres - vaut le voyage ;-) )

Si vous souhaitez mettre un sujet particulier à l'ordre du jour de la 
rencontre, vous pouvez l'ajouter sur la page :

https://wiki.openstreetmap.org/wiki/FR:Lyon/R%C3%A9union_08_septembre_2020

Renecha pour le groupe de Lyon.



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

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

[Jérôme Amagat]

avec les addr:* (pas besoin de bbox) :
[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];
out;
https://overpass-turbo.eu/s/XMY
la response est quasi instantanée :)

par contre la solution donnée :
[out:csv(::id,maxspeed,ref,milestone,name,::lat,::lon)];
area[name="France"]->.pays;
relation(area.pays) [type=enforcement] [enforcement=maxspeed];
node(r:device);
out;
ne donne que les infos de "node(r:device);" dans le csv donc seulement les
coordonnées.

comme ça (j'ai rajouté dans le csv les même colonnes que dans la 1e
requête, certains radars ont encore les addr:*) :
[out:csv(::id,type,enforcement,"addr:country",maxspeed,"addr:city","addr:postcode","addr:street",ref,milestone,name,::lat,::lon)];
area[name="France"]->.pays;
relation(area.pays) [type=enforcement] [enforcement=maxspeed];
out center;
https://overpass-turbo.eu/s/XN6
on a les infos des relations et les coordonnées du "centre" de la relation
, pas obligatoirement dans la même commune que le radar, mais je ne sais
pas comment faire une sortie avec les coordonnées du "device". Et si il a
besoin des adresses, je ne sais pas non plus...


La position des radars est presente sur
https://radars.securite-routiere.gouv.fr/ , mais pas moyen de trouver les
données "brute".
Quelqu'un semble avoir recuperer les données du site :
https://www.data.gouv.fr/fr/datasets/radars-automatiques/

On peut lire en bas de la page https://radars.securite-routiere.gouv.fr/,
"Les données radars sont affichées à titre indicatif et mises à jour
régulièrement : date de mise à jour le 06 novembre 2018" :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[osm . sanspourriel]

> 4. rien ne dit qu'une relation radar de vitesse ne soit pas à cheval
sur deux villes (en même temps ce n'est peut-être jamais le cas de par
les contraintes d'implantation ?)

Bien vu !

Radar tronçon (mal tagué) :

Radar de départ https://www.openstreetmap.org/node/100403189
 sur la commune de Guidel.

L'autre radar (d'arrivée) est sur la commune de Quimperlé (mais pas dans
OSM).

Donc tronçon sur trois communes (il y a Redéné entre les deux) et deux
départements.

Après la convention s'il y en a une est sans doute de dire que l'endroit
c'est celui de la constatation de l'infraction (Quimperlé ici). Même si
l'excès de vitesse a été fait sur une des autres communes.

Ou encore qu'il y a deux radars indépendants. Ça dépend de comment le
hobbyiste voit son hobbie ;-).

Jean-Yvon


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

[OSM-talk-fr] JOSM version stable 17013 : traduction du Journal des modifications

[leni]

C'était la rentrée des enfants et les développeurs ont mis en place la 
versions 17013 de JOSM.


Vous pouvez trouver le Journal (traduit) des modifications apportés par 
cette version se trouve à 
https://josm.openstreetmap.de/wiki/Fr%3AChangelog#stable-release-20.08


Pour améliorer la traduction de ce journal, faites vos remarques ...

Cordialement

leni


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

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

[Topographe Fou]

 Bonjour,Je vois plus de problème que d'avantages à l'utilisation des addr sur les radars :1. Cela revient à utiliser is_in, un tag qui avait une raison d'être à une époque mais qui n'a presque plus de raison de vivre aujourd'hui, surtout dans un pays comme le nôtre ou les différents échelons administratifs sont assez bien cartographiés (Romain, ton approche par area est la bonne, merci pour la suggestion que tu lui fait)2. Je ne comprend pas l'argument du "oui mais moi j'en ai besoin" : dans ce cas on fait la même chose pour les bancs, les lampadaires, les poteaux et les routes, selon les hobbies de chacun ? C'est ingérable et redondant. L'énergie de ce contributeur va être vite usée car je doute que Romain soit le seul à ne pas comprendre la pertinence de ces tags sur un radar.3. il n'y a pas si longtemps on a eu une longue discussion sur l'unicité des adresses. Je vois mal comment en s'arrêtant au pays ou à la ville on est unique.4. rien ne dit qu'une relation radar de vitesse ne soit pas à cheval sur deux villes (en même temps ce n'est peut-être jamais le cas de par les contraintes d'implantation ?)Question naïve : les radars n'ont pas une référence unique pour faciliter les consolidations ?Sinon l'API Nominatim permet de geocoder plusieurs objets à la fois de mémoire pour qui code un minimum.Donc à fond derrière Romain :) LeTopographeFou   De: romain.me...@mailo.comEnvoyé: 6 septembre 2020 10:23 PMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: [OSM-talk-fr] Tags addr: pour les radars  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] Tags addr: pour les radars

[Denis Chenu]

Bonjour,

Ce que j'en conclurais : ne pas ajouter les codes postaux «non sur» tant
que la poste ne fournit pas de découpage précis.

Sinon : c'est faire au hasard …

Le 07/09/2020 à 15:48, Philippe Verdy a écrit :
> On doit donc "estimer" ces tracés en faisant pas mal d'erreurs. Et
> pour estimer ça, on n'a pas d'autre moyen de renseigner d'abord ces
> codes postaux sur les points. Puis essayer de tester sur des points
> "ambigus" (mais comment vérifier ? On ne peut pas aller fouiller le
> courrier dans les boites à lettres). Et la plupart du temps ce
> découpage est historique et date de bien avant l'internet ou même le
> traitement totalement automatique du courrier dans les centres de tri,
> quand les tournées s'organisaient manuellement par les postiers
> connaissant le terrain et s'organisant entre eux et selon leurs
> disponibilités et congés.


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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Philippe Verdy]

C'est justement pour ça que j'ai utilisé le terme "pragmatique" puisque les
outils eux font chacun ce qu'ils veulent (de façon inhomogène) et aucun
n'évolue.
Le "doublon" qui pourrait être vu par certains outils n'en est pas un pour
la plupart (et dans aucun rendu carto actuel). Ceux qui les détecte ne sont
que les outils QA (comm Osmose) qui propose arbitrairement d'un
supprimer un (et les utilisateurs ensuite suppriment celui qu'ils veulent,
donc bel et bien en "taguant pour le rendu" d'un seul même si ça casse les
autres).
Ces doublons en fait ne coûtent rien, car les outils savent déjà les
détecter (ils peuvent donc filtrer tout seul dans la quasi-totalité des
cas: aucune modif n'est donc nécessaire et ce n'est donc pas une "erreur",
mais juste une alerte demandant de vérifier des cas éventuels de mauvaises
attributions, pas de supprimer ce qui est correct mais jugé à tord comme
"superflu" et qui ne coute quasiment rien dans la base).

Où est le "double travail"? Nulle part. En revanche les suppressions
hâtives coutent bien plus en terme de travail (les utilsiateurs ne voient
plus rien, ils vont rajouter à nouveau des POI à leur façon (avec les
autres tags et de nouvelles erreurs), ça n'en finira jamais.

Tant que les rendus utiliseront leurs propres règles sans s'en préoccuper,
l'analyse QA a beau signaler ce qu'elle veut, elle ne résoud rien, elle ne
fait qu'ajouter des signalements totalement inutiles sans solution et qui
ajoutent du travail ou qui viennent noyer les autres résultats plus
importants. D'ailleurs le niveau indiqué dans Osmose (si on parle de lui)
n'a aucune gravité, aucun caractère d'urgence puisque les rendus ne se
pressent pas (des mois ou des années) pour corriger leurs analyses et se
mettre d'accord entre eux.

Cela ne sert à rien de signaler comme de prétendues "erreurs" ce qui n'en
est pas et n'a fait l'objet d'aucun consensus réel.


Le lun. 7 sept. 2020 à 10:54,  a écrit :

> Salut,
>
> Le 07/09/2020 à 10:45, Denis Chenu via Talk-fr -
> talk-fr@openstreetmap.org a écrit :
> > Aucune raison de faire les 2.
>
> Si, certains systèmes ne traitent qu'un et donc les utilisateurs
> débutants ajoutent l'autre.
>
> Il y a aussi le cas des places avec Nominatim et le rendu osm-fr (mais
> là j'ai indiqué un contournement possible).
>
> Donc plusieurs raisons, mais pas de bonnes raisons !
>
> Et là le rôle des utilisateurs expérimentés c'est de proposer des
> solutions pour que ce genre de cas ne se présente plus.
>
> Jean-Yvon
>
>
>
> ___
> 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] Tags addr: pour les radars

[Philippe Verdy]

LA comparaison par code INSE est justement ce que fait le FANTOIR. Et
pourquoi mettre des poitns adresse avec juste les numéros n'est pas non
plus suffisant partout, et pourquoi on a des relations associatedStreet et
pourquoi aussi un même segment de rue (même si elle ne fait poas frontière
elle-même) peut appartenir à plusieurs de ces relations pour pouvoir
associer correctement les points d'adresse qui y sont liés. Mais sans ces
relations, on n'évite pas la répétition des "addr:street=*".

Cependant me^me avec le code FANTOIR correct sur les rues, cela ne suffit
pas pour les codes postaux à associer (les codes postaux n'ont aucun lien
direct avec les codes INSEE des communes).

Alors oui la solution des relations surfaciques pour les codes postaux
(géographiques seulement, pas spéciaux) marche, mais La Poste n'a jamais
fourni ce découpage (qui ne suit pas non plus le
découpage administratifs des quartiers quand il existe, au mieux cela suit
le découpage des arrondissements à Paris/Lyon/Marseille uniquement!)

Tout au plus les codes postaux suivent le découpage des anciennes communes
qui ont été regroupées (en communes nouvelles) ou fusionnées... mais
pendant un certain temps. On ne sait pas comment se font ensuite les mises
à jour par la Poste qui peut décider toute seule de fusionner ou pas sans
jamais fournir de données autre que son petit tableau de codes postaux sans
aucune géométrie. On n'a aucun historique permettant de dater ces
découpages intracommunaux et les lier à une définition administrative ou
retrouver dans des archives les documents d'information qui pourraient
permettre de les reconstituer sans trop d'erreurs.

On doit donc "estimer" ces tracés en faisant pas mal d'erreurs. Et pour
estimer ça, on n'a pas d'autre moyen de renseigner d'abord ces codes
postaux sur les points. Puis essayer de tester sur des points "ambigus"
(mais comment vérifier ? On ne peut pas aller fouiller le courrier dans les
boites à lettres). Et la plupart du temps ce découpage est historique et
date de bien avant l'internet ou même le traitement totalement automatique
du courrier dans les centres de tri, quand les tournées s'organisaient
manuellement par les postiers connaissant le terrain et s'organisant entre
eux et selon leurs disponibilités et congés.

Au final les codes postaux en France n'ont jamais été bien revus depuis
leur création. La Poste les a négligé même si à la fin des années 1970 elle
a plus un moins incité les gens à les utiliser (et la imposé aux
entreprises pour leurs envois en nombre par des conditions tarifaires plus
favorables et en refacturant les courriers mal adressés au delà d'un seuil
de plus en plus faibles de défauts admis, puisque comptablement la Poste
n'a pas non les moyens de faire ce comptage pour récupérer des centimes
avec un coût comptable bien supérieur).

En France, nos codes postaux sont très flous en comparaison de nos voisins
européens qui ont mis des définitions plus strictes et mieux respectées (ou
même très fines si on regarde le système britannique et même le système
américain, où le code postal complet pourrait suffire à remplacer quasiment
toute l'adresse à la boîte à lettres près).


Le lun. 7 sept. 2020 à 10:49,  a écrit :

> Je suppose qu'à la base le problème est de distinguer deux communes de
> même nom.
>
> Ça fait environ un siècle que les communes homonymes ont été
> "dédupliquées" par ajout d'un complément sur une commune.
>
> Camaret => Camaret-sur-Mer
> Cesson => Cesson-Sévigné.
>
> S'il y a plusieurs codes postaux pour la même ville, et que son besoin
> est justifié, il faut créer des relations postal_code spécifiques.
>
> Je suppose qu'il pourrait dans l'autre sens sur sa base de référence
> passer du code postal au code INSEE (il a aussi la commune).
>
> une comparaison code insee c'est plus simple que des comparaisons code
> postal + nom de commune approximatifs.
>
> Jean-Yvon
>
> Le 07/09/2020 à 10:15, Philippe Verdy - ver...@gmail.com a écrit :
> >
>
>
> ___
> 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] Affichage d'un name suivant le rendu

[osm . sanspourriel]

Salut,

Le 07/09/2020 à 10:45, Denis Chenu via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Aucune raison de faire les 2.


Si, certains systèmes ne traitent qu'un et donc les utilisateurs
débutants ajoutent l'autre.

Il y a aussi le cas des places avec Nominatim et le rendu osm-fr (mais
là j'ai indiqué un contournement possible).

Donc plusieurs raisons, mais pas de bonnes raisons !

Et là le rôle des utilisateurs expérimentés c'est de proposer des
solutions pour que ce genre de cas ne se présente plus.

Jean-Yvon



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

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

[osm . sanspourriel]

Je suppose qu'à la base le problème est de distinguer deux communes de
même nom.

Ça fait environ un siècle que les communes homonymes ont été
"dédupliquées" par ajout d'un complément sur une commune.

Camaret => Camaret-sur-Mer
Cesson => Cesson-Sévigné.

S'il y a plusieurs codes postaux pour la même ville, et que son besoin
est justifié, il faut créer des relations postal_code spécifiques.

Je suppose qu'il pourrait dans l'autre sens sur sa base de référence
passer du code postal au code INSEE (il a aussi la commune).

une comparaison code insee c'est plus simple que des comparaisons code
postal + nom de commune approximatifs.

Jean-Yvon

Le 07/09/2020 à 10:15, Philippe Verdy - ver...@gmail.com a écrit :





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

Re: [OSM-talk-fr] Affichage d'un name suivant le rendu

[Denis Chenu via Talk-fr]

Bonjour,

Je ne vois aucun intérêt à des règles non suivie ou suivie
partiellement. La seule solution est de suivre les règles quand elles
sont claires et précises (comme c'est le cas ici).

Si l'utilisateur 1 ajoute les points alors que la surface existe.
Un utilisateur ancien ou nouveau qui modifiera la même zone supprimera
ce pints en trop qui ne correspond pas à la règle clair.

Cela fait 2 travail inutile …
Si les règles doivent être changée : c'est faisable, mais cela doit être
un accord total et un correspondre à un processus de décision.

En tant qu'utilisateur depuis peu : je tente de suivre les règles, par
exemple su school : si je connais l'école ou son emprise est claire : je
créé la zone, mais sinon : je ne fait que 1 point. Aucune raison de
faire les 2.

Si chacun suit ses propres règles : la carte n'avancera pas …

Denis


Le 05/09/2020 à 18:00, Philippe Verdy a écrit :
> Osmose signale non pas des "erreurs" mais des choses sur lesquelles on
> doit porter attention. Il propose, n'impose pas, et surtout il FAUT
> faire le travail d'intégration.
>
> Sinon ce n'est pas Osmose mais un bot qui ferait le travail : Osmose
> impose l'intelligence humaine. Et ces propositions ne sont pas
> toujours pertinentes (la quasi totalité des "règles" sont génériques,
> et la cartographie est bourrée d'exceptions partout.
>
> Non je ne me conduirai pas comme un robot (c'est totalement contraire
> à l'esprit d'OSM, les bots sont soumis à des règles très strictes et
> se font régulièrement bloquer ou annuler même s'ils ont été approuvés).
>
> Je pense que tu n'as pas compris ce qu'était un outil de "veille
> qualité" (QA) sur OSM.
>
> Non je ne "bricole" AUCUNE règle, c'est plutôt toi qui veut les
> appliquer de façon impérative (alors que justement il n'y a aucune
> règle impérative (et pour des raisons de performance, un outil ne peut
> pas tout regarder et tout savoir).
>
> Bref ton message est un peu trop anticollaboratif. Ca n'ôte rien à
> l'utilité d'Osmose. Ni le fait que la "règle internationale" n'en est
> en fait justement pas une sur ce sujet. Ce ne sont que de bonnes
> pratiques conseillées. Ici on a deux pratiques conseillées et imposer
> une solution au détriment des autres tout aussi valides (et déjà
> déployées sans en tenir compte) c'est justement ce que j'appelle
> taguer pour le rendu (ici un rendu théorique qui n'existe même pas et
> donc n'a AUCUN consensus actuel qui puisse être démontré).
>
>
>
>
> Le sam. 5 sept. 2020 à 17:43, Christian Quest  > a écrit :
>
>
>>> De: "Philippe Verdy"  
>>> Ben non justement, ce n'est pas "taguer" pour le rendu car les deux
>>> méthodes sont indiquées comme valides et approuvées. Certes il y a
>>> des bogues dans le rendu puisque suivant les cas c'est l'une ou
>>> l'autre méthode qui est visible; mais si on voit les deux c'est
>>> moins grave que ne rien voir du tout.
>
>
> C'est tellement "valide et approuvé" que JOSM signale une erreur
> et osmose a une analyse pour ça aussi...
>
>
> Le 04/09/2020 à 18:19, Vincent de Château-Thierry a écrit :
>
>>  
>> Les 2 méthodes sont valides et approuvées, je suis d'accord. Mais elles 
>> sont mutuellement exclusives : si on en choisit une pour un objet du 
>> terrain, alors il ne faut pas utiliser l'autre pour le même objet. Toujours 
>> le "one feature, one element".
>>  
>
>
> Et oui, l'article
> https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
> est clair à ce sujet pour qui prends la peine de le (re)lire.
>
> "A feature whose position is known, but whose shape is either
> unknown or irrelevant, should appear as a point
>  object with appropriate
> tags."
>
> Donc on met un nœud quand on ne connaît pas l'emprise ou que ça
> n'a pas de sens (ex: une borne kilométrique). L'emprise est donc
> bien considérée comme préférée, le nœud une version dégradée et en
> aucun cas on met les deux en même temps.
>
>
> Pour la partie "bonnes pratiques locales", elles devraient se
> limiter à trancher quand plusieurs façons de faire cohabitent et
> sont acceptées internationalement. Pour moi, une règle ou bonne
> pratique locale devrait être le résultat d'un consensus local qui
> n'a pas pu être obtenu internationalement, mais elles ne devraient
> jamais enfreindre une règle internationale.
>
> Bricoler ses propres règles, les adapter n'est vraiment pas un
> service à rendre à OSM et aux réutilisateurs des données.
>
>
> -- 
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> 

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

[Philippe Verdy]

La remarque vaut pour le pays ou la ville; cependant il y a des exceptions
pour les codes postaux, notamment dans les villes qui en ont plusieurs (et
toujours pas de publiciation officielle de leur délimitation par la poste,
on en a juste une idée approximative, avec aussi des exceptions sur les
rues qui longent les frontières communales ou les recoupe plusieurs
fois...) et les codes postaux "spéciaux" (CEDEX et groupements de
boites aux lettres ou autres modes de distribution: pour pas mal de POI il
est justifié de préciser le code postal quand il est ambigu et pas résolu
par le géocodage).

donc en gros oui, mais dans le détail on ne peut pas exclure leur besoin.

Et à moins d'avoir créé des relations associatedStreet, répéter
addr:street=* sur les noeuds d'adresse (eux-mêmes différents des adresses
des POI) est souvent la seule façon de lever les ambiguités dans les zones
ubaines denses.

Le lun. 7 sept. 2020 à 09:14, Éric Gillet  a
écrit :

> Le 06/09/2020 à 22:23, Romain MEHUT a écrit :
>
> 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 :
>
> Vous validez ma méthode et vous êtes d'accord pour retirer les tags addr: ?
>
> Je suis entièrement d'accord
> , il y a de nombreuses
> façon de géocoder ce genre d'objets, mais mettre les tags en dur sur chaque
> ne me semble pas la bonne non plus.
> ___
> 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] Tags addr: pour les radars

[Éric Gillet]

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


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 :


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


Je suis entièrement d'accord 
, il y a de nombreuses 
façon de géocoder ce genre d'objets, mais mettre les tags en dur sur 
chaque ne me semble pas la bonne non plus.


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