Re: [OSM-talk-fr] Relations intermédiaires pour les routes de bus ?

[Philippe Verdy]

Il y a le cas assez courant des lignes partagées partiellement entre
plusieurs opérateurs. Aussi bien our les bus que les trains. Certaines
"sections" sont communes et accessibles aux porteurs de titres des
différents réseaux, les autres nécessitent un complément de billet de
transport ou un autre abonnement. A Paris aussi il y a les zones de carte
Orange. Ailleurs les réseaux d'agglomération peuvent partager des bus avec
les transports départementaux ou régionaux, là encore avec des sections
communes. Chaque section peut avoir une série de variante de trajets (tant
que les sections se raboutent avec un point d'extrémité commun ou y font un
terminus, aucun problème; cependant dans certains cas, le raboutement des
sections peut se faire sur des nœuds différents: il faut alors autant de
variantes pour chaque section à rabouter à la suivante, chaque section
ayant plusieurs "pseudo-terminus").

Bref ce qui manque dans le schéma des routes c'est une relation de type
"section", une ligne pouvant avoir plusieurs sections, et les sections
pouvant être partagées (membres) par plusieurs lignes différentes (du même
opérateur ou d'un autre opérateur). Cela résoudrait le tout, en permettant
effectivement de mettre en commun des sections de plusieurs lignes, chaque
section pouvant partager les mêmes conditions tarifaires ou pas, et être
accessible dans plusieurs réseaux de transport partiellement superposés
pour des lignes en co-exploitation.


Le jeu. 15 févr. 2024 à 18:25, Eric SIBERT  a
écrit :

> Des fois, je me dis que ça ne serait pas mal qu'il y ai un peu de
> factorisation sur certaines lignes de bus hors agglomération.
>
> Sur un tronçon de la D1075 en Isère, il y a :
> - 2 relations Bus 55 (aller et retour) (bus Zou opéré par Transdev
> Dauphiné!!!)
> - 2 relations bus T73 (interurbain Isère)
> - 8 relations bus T75 (idem): différentes combinaisons de départ/arrivée
> - 2 relations TA2A (pour aller au ski)
> - 2 relations TAAH (idem)
> - 2 relations TAVR (idem)
> (- l'ancien train qui roulait sur la chaussée)
>
> Eric
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Mise à jour de POLE EMPLOI

[Philippe Verdy]

Remarquez qu'il n'y a pas que le nom du POI, mais aussi les URL des liens,
donc le nom de domaine est changé.
Mais les chemins de page dans le nom de domaine ne sont pas forcément les
mêmes, ce qui oblige à les revisiter, sinon on se retrouvera sur une page
404 ou une page d'accueil par défaut.

"*https://www.pole-emploi.fr/ *" redirige
maintenant sur "*https://www.francetravail.fr/
*" (qui redirige localement vers "
https://www.francetravail.fr/accueil/; mais cette redirection peut dépendre
du terminal de connexion ou de préférences linguistiques détectée sur les
requêtes HTTP): les sous-pages pouvant changer régulièrement au gré des
réformes ou changement de design des sites, je n'indiquerais qu'un lien nu
vers la racine.

De plus HTTPS devrait être utilisé et plus HTTP (donc ne plus accepter
"*http://www.pole-emploi.fr/
*" comme c'est encore le cas dans OSM) ,
d'autant que nombre de navigateurs ne veulent plus faire aucune connexion à
un site HTTP, notamment pour des sites aussi sensibles contenant des
données personnelles, où la sécurité est obligatoire pour éviter certaines
arnaques web via des redirections de sites incontrôlées.

Google Chrome par exemple refuse par défaut de visiter la plupart des sites
non sécurisés, mais aussi Microsoft Edge; appliquer "HTTPS everywhere" donc
pour tous les sites officiels gouvernementaux, et ceux des organismes
sociaux, banques, etc. On ne s'y connecte pas par plaisir pour le loisir ou
pour voir de la pub ou un catalogue ou une page perso, et même les pages
persos sont en perte de vitesse, hébergés maintenant presque tout le temps
par des réseaux sociaux ou serveurs de blogues qui sont tous passés en
HTTPS. A mon avis les liens HTTTP non HTTPS devraient être nettoyés dans
OSM, pour limiter les risques d'attaque "man-in-the-middle" par
détournement des protocoles. Il y a tellement de sites qui ont besoin de
diffuser de la pub et notamment avec Facebook ou GoogleAds, dont les API ne
fonctionnent qu'en mode sécurisé: tous ont du passer en pratique à HTTPS
eux aussi, au risque de ne plus être accessibles et perdre leurs marché
cible. S'il reste des liens HTTP, c'est pour des cas de niches, autrement
dit des sites suspects et la plupart du temps nuisibles.

Le mer. 14 févr. 2024 à 15:58, Bruno Remy via Talk-fr <
talk-fr@openstreetmap.org> a écrit :
>
> Bonjour,
> Je suis d'accord avec toi Marc. A partir du moment où il y a eu une
réorganisation administrative générale, toutes les agences sont devenues
"FRANCE TRAVAIL" et le changement des enseignes sur les façades n'est pas
impactante. Dans ce cas la dénomination officielle prime sur le repérage
terrain et on peut faire un remplacement généralisé.
>
> Merci pour le lien wiki sur la modification automatisée.Je veux bien
suivre cette procédure sur le plan administratif : référence aux
discutions, documentation sur une page wiki, etc par contre je ne vois
toujours pas comment techniquement faire ce remplacement automatisé?
>
> ---
> Bruno REMY
>
>
>
> Le mercredi 14 février 2024 à 15:38:50 UTC+1, Marc_marc via Talk-fr <
talk-fr@openstreetmap.org> a écrit :
>
>  Bonjour,
>
> Le 14.02.24 à 11:17, Bruno Remy via Talk-fr a écrit :
> > Pôle emploi est devenu France Travail depuis le 1er janvier 2024
> > Y-a-t-il un moyen d'industrialiser le changement sur tous les POI de
France?
> > J'ai regardé avec JOSM mais on est obligé de sélectionner une zone de
modification sur la carte.
> > Vos idées sont les bienvenues.
>
> techniquement il suffit de faire la recherche sur la France
> et faire la procédure d'édition de masse [1]
> mais tu as déjà une objection/question pour le changement du name
> Pour ma part, le fait qu'un bureau n'a pas encore changé le nom
> sur son écriteaux ne devrait pas empêcher de changer name=*
> l'inscription sur le batiment, si on veux ce nniveau de détail,
> serrait pour inscription. si on téléphone, je suppose qu'il
> s'annonce avec le nouveau nom et non avec ce qui est inscrit
> sur le panneau
>
> [1]
>
https://wiki.openstreetmap.org/wiki/FR:Politique_de_modification_automatis%C3%A9e
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Zone atterrissage pour parapentes

[Philippe Verdy]

Oui mais si c'est un terrain de foot municipal, son usage comme zone
d'atterrisage des sports aériens doit être réglementé (au moins avec des
réservations horaires préalables). La FFLV ou une de ses assos sportives
membres peut vouloir faire une demande mais elle le fera au nom du stade
demandé et sous le nom désigné par la mairie et je ne vois pas l'intérêt de
la FFLV à vouloir utiliser un nom différent, d'autant que le terrain de
sport est à priori ouvert toute l'année et sert des missions de service
public. Ce sera la même chose si le terrain est réservé pour un concert, un
marché, un vide-grenier, et il y a aura pour les organisateurs à assurer la
sécurité des accès et participants en plus des règles propres à leur
activité sportive, sociale ou commerciale et des réglementations
spécifiques afférentes à ces activités. Sinon autant alors utiliser une clé
spécifique pour cette activité, liée au nom de l'organisation qui
l'utiliser, et non la clé "name=*" à garder pour le nom officiel ou le plus
commun.
On a d'autres exemples de terrains partagés par plusieurs sports, par
exemple un golf et un hippodrome (les golfs ont une très grande emprise)
avec encore au milieu de tout ça parfois d'autres équipements (pistes de
course ou de saut d'athlétisme, terrains à marquages multiples: foot,
handball, rugby, tennis, ou en taille réduite pour entrainement/formation,
murs de pelote ou d'escalade, pistes cyclo, rampes), des accès et parkings,
des pelouses ou jardins d'agrément, des bâtiments, et d'autres services
annexes ou en franchise (restaus, bars, salles de cours, salles de
préparation, réserves de matériel, toilettes, parfois aussi des aires de
camping, piscines, salles de spectacle) et diverses barrières (qui peuvent
réduire la taille utilisable pour le parachutisme ou parapente).

Pour la sécurité réelle, il peut y avoir besoin de marquage ou balisage
particulier sur les zones conseillées et celles à éviter, ainsi que dans
les zones d'approche autour de la zone d'atterrissage (qu'elles soient
pérennes ou juste adaptées aux besoins d'urgence (pas seulement la pratique
sportive, mais aussi comme terrain pour hélicos de secours qui ont une
priorité négociée à l'avance ou établie par la législation ou la
réglementation publique).

Le sam. 23 déc. 2023 à 10:14, Capello13 via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Bonjour,
>
> La documentation sur le wiki est disponible ici :
> https://wiki.openstreetmap.org/wiki/FR:Tag:sport%3Dfree_flying
>
> La définition du type de terrain n'est pas facile pour cette activité
> car une partie des sites ne sont pas dédiés qu'à cette activité et le
> wiki reste vague.
> Je met leisure=pitch quand le terrain est dédié au vol libre, avec
> parfois l'installation de moquette pour protéger les voiles des pierres.
> Sinon j'essaie de décrire le type de terrain (prairie, pâture,...),
> cependant dans ce cas Josm remonte des warnings sur l'utilisation d'un
> tag sport=* sans utilisation de leisure=*
>
> Dans l'exemple de Digne-les-Bains, je pense qu'il est possible
> d'utiliser le même objet osm en utilisant la clé
> sport=soccer;free_flying, cependant ça ne résout pas le conflit de nom.
> Le nom de l'atterrissage est une dénomination FFVL, qui n'est utilisé
> que dans le cadre de la pratique du vol libre. Là où le terrain de
> football tient sans doute son nom d'une décision de la mairie, je pense
> que ce dernier est le plus pertinent.
>
> Bons vols ;)
>
> Le 22/12/2023 à 18:18, Arnaud Champollion a écrit :
> > Bonjour,
> >
> > Comment taguer une zone d’atterrissage pour parapentes ?
> >
> > Il semble qu'un club a entrepris de les répertorier sur
> > Digne-les-Bains, avec des leisure=pitch et dans l'idée c'est plutôt
> > utile j'imagine.
> >
> > Mais parfois ça chevauche des polygones existants. Par exemple ici
> > https://www.openstreetmap.org/#map=18/44.08394/6.22541 , la pelouse du
> > stade sert en effet de zone d’atterrissage ... pour autant s'agit-il
> > de deux objets différents ?
> >
> > Là on a deux polygones quasi superposés avec des "name" différents.
> >
> > Qu'en pensez-vous ?
> >
> > Merci
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tuiles manquantes à zoom=17

[Philippe Verdy]

L'erreur http 404 Not Found de ne devrait pas être retournée en cas de ban
ou limite dépassée, MAIS plutôt une erreur 429 Too Many Requests (RFC 6585)

L'erreur 404 implique indiquer une erreur permanente liée à une URL
incorrecte, quel que soit le client, ou ses auririsations données, son
résultat étant normalement mis en cache côté client avec une durée de
validité pouvant atteindre plusieurs jours ou au moins 1 heure en absence
d'indication par le serveur (un serveur peut ajuster cette durée dans sa
réponse) et que tout client ou proxy caché retournerait immédiatement pour
demander ne plus solliciter le serveur durant cette durée, sauf en
fournissant des clés d'autorisation oubdon'ees complémentaire ou en
utilisant une autre URL vers la ressource correcte. L'erreur 404 ne peut
pas etre contourne sans contacter le support du serveur pour ajouter des
ressources manquantes et qui "devraient" y être, seul un administrateur du
site ou serveur peut la corrigé par une intervention manuelle. Le délai
donné dans la réponse est un délai raisonnable d'intervention manuelle par
ce support, à condition qu'il en soit averti et qu'il accepte de prendre ne
charge la reponse

Si le serveur ne peut pas retourner temporairement une ressource demandée
en cas de surcharge ou de problème dont le client n'est pas la cause, il
devrait utiliser une erreur 5xx. S'il faut des c'est d'autorisation ou un
paiement pour accéder à la ressource (données non libres d'accès) ou si
l'authentification à échoué mais que la ressource existe bien et est
accessible à certains clients, il y a d'autres erreurs indiquant ce que le
client doit faire, et si la requête est mal formée avec des données de
requête non decodables ou insuffisantes ou ambiguës pour identifier ce qui
doit être retourné, ou si le format de réponse demandé n'est pas disponible
et la requête n'autorise pas un autre format, il y a d'autres erreurs.

Un ban ou un dépassement des droits d'accès ou limites est une décision
déjà prise et enregistrée par l'administration du site qui en principe
documente les conditions d'usage par les utilisateurs. Ces conditions
n'étant pas respectées, la faute en incombe à cet utilisateur ou le proxy
qu'il utilise. Le serveur n'a aucune obligation de corriger quoi que ce
soit et en aucun cas cela peut se résoudre de faon automatique. Bref pas de
404 dans ce cas là

Le jeu. 16 nov. 2023, 17:35, Jean-Claude Repetto  a
écrit :

> Le 16/11/2023 à 17:07, rpnpif a écrit :
> > Bonjour,
> >
> > Je fais du développement avec Leaflet et OpenStreetmap.
> > Les tuiles dès le niveau de zoom=17 sont déclarées manquantes (erreur
> 404).
> > Je les ai demandées une dizaine de fois pour mes tests. J'ai
> > l'impression qu'avant je pouvais accéder au zoom 19 sans problème.
> >
> > Savez vous s'il y a une limite au nombre de chargement des tuiles
> > identiques d'une même zone et une même adresse IP ? Si oui elle doit
> > être assez basse.
> >
>
> Bonjour,
> Pourrais-tu donner les URLs de quelques-unes de ces dalles pour vérifier
> si d'autres personnes y ont accès ?
>
> ___
> 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] Sur quel objet mettre les tags des passages piétons ?

[Philippe Verdy]

À ce sujet il semble que "crossing_ref=zebra" (et  plus généralement
"crossing_ref=*" ) soit maintenant déprécié et à remplacer par
"crossing:marking=zebra" pour les "passages piétons non protégés" proposés
dans l'éditeur en ligne (qui par défaut utilise " crossing:marking=yes"
sans indiquer la nature du marquage) ou "crossing:marking= no" (pour
l'absence de marquage, essentiellement sur les traversées de chemins
piétons au travers de chemins agricoles en zone rurale, ou les traversées
d'allées résidentielles privées en zone urbaine, ou de voies de service ou
de pistes cyclables).


Le mer. 26 avr. 2023 à 19:10, leni  a écrit :

> Bonjour
>
> Le 25/04/2023 à 16:36, Noémie Lehuby via Talk-fr a écrit :
> > Bonjour,
> >
> > Dites, quand vous cartographiez un passage piéton en chemin (way), les
> > attributs du passage piéton (zébra, ilôt de refuge, feux sonores,
> > bande podotactile, etc), vous les mettez plutôt :
> > 1) sur le noeud higwhay=crossing
> > 2) sur le chemin highway=footway + footway=crossing
> > 3) sur les deux
> > ?
> Je ne crée le chemin footway/cycleway/path= crossing que pour créer la
> continuité de routage ; ce qui fait que si j'ai un highway=footway à
> droite séparé de la route par un obstacle et un sidewalk=left, mon
> footway= crossing s'arrête sur le nœud de la route
>
> Il y a 1 115 224 higwhay=crossing, 101 673 footway=crossing, 4 456
> cycleway=crossing et 1 639 path=crossing
>
> > Mais l'inconvénient est que la donnée n'est pas uniforme, il faut
> > parfois chercher l'info sur un noeud, parfois sur un chemin, et tous
> > les éditeurs / réutilisateurs ne feront pas cet effort.
>
> c'est pourquoi je les laisse sur le nœud (j'avais essayé avec le
> préréglage "passage piéton" de JOSM, mais il ne le permet pas sur les way)
>
> Pour l'instant, je n'ai fais pas de micro-mapping - donc pas de bande
> bande podotactile, ni de bordure que je mettrais (je pense) sur un nœud
> prés du trottoir comme Marc
>
> cordialement
>
> leni
>
>
> ___
> 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] traduction de "tag" en français dans JOSM

[Philippe Verdy]

En règle générale le terme attribut à été utilisé par ceux qu'on a vu
discuter ici et participer aux traductions collectives, mais dans les pages
isolées traduites rapidement et pas relues par des traducteurs un peu
rapides, ils n'ont pas cherché et conservé les anglicismes sans chercher
plus loin.
Co cernant le terme chemin, c'est une ambiguïté souvent pour traduire le
"way" OSM qui n'est qu'un tracé de ligne polygonale (pas forcément fermée)
et beaucoup le rapprochent du "highway" OSM qui n'est pas non plus qu'une
route mais tout type de "voirie", comprenant aussi des chemins, sentiers ou
pistes agricoles et pédestres.

Le lun. 10 avr. 2023 à 13:15, Marc_marc  a écrit :

> Bonjour,
>
> Le 10.04.23 à 12:54, leni a écrit :
> > utiliser un seul terme pour "tag"
>
> attribut ?
>
> c'est tout l'écosystème osm qui a ce soucis.
> ce serrait quand même pratique que la traduction
> des clefs se fasse une seule fois sur le wiki.
> autre exemple du même soucis : chemin <> sentier
>
> 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

[OSM-talk-fr] Données open data venant de AND NL: domaine and.com cybersquattable?

[Philippe Verdy]

A propos des données néerlandaises de AND NL
(https://wiki.openstreetmap.org/wiki/AND_data)

La page de copyright d'OSM contient une mention légale liée au site web "
www.and.com".
Mais ce domaine n'est semble-t-il pas renouvelé et pourrait être à vendre
sur GoDaddy.
De tels domaines ".com" avec des noms courts correspondant à un terme
anglais générique "AND" sont très surveillés et peuvent rapidement être
cybersquattés. Il y a le risque même que le nouvel acquéreur fasse une
revendication de droits sur les données AND NL présentes dans OSM.

Si c'est un oubli de renouvellement ou si c'est causé par le fait que le
prix demandé pour le renouvellement ne peut plus être payé (ou si le projet
n'est plus soutenu et le titulaire souhaite réellement céder AND en tant
que marque commerciale utilisable par d'autres, il faudrait trouver comment
référencer correctement les données AND NL présentes (en assurant que la
date présente dans le copyright indique bien les années de début et de fin
où le domaine était détenu. Et demander au titulaire légitime néerlandais
de présenter une page d'explication certifiable indiquant quelle autorité
gère et détient les droits sur ce jeu de données ancien.

Il en faudrait pas pousser les réutilisateurs de données OSM à se connecter
à un site illégitime voire dangereux, qui ferait ensuite des prétentions
exhorbitantes sur l'utilisation de la marque "AND NL" ou du domaine "and.com"
(ds prétentions qu'il peut ensuite être difficile de défendre si en plus
cette nouvelle autorité en profite pour déposer un brevet et réclamer des
royalties d'usage via certaines sociétés d'avocats surpuissantes comme la
MPEGLA). Si c'est utilisé pour diffuser des malwares ou faire du parasitage
publicitaires ou de la collecte de données personnelles ou commerciales, un
tel abus pourrait nécessiter de faire bloquer le nom de domaine mais ça
prend du temps et cela fera des victimes pendant ce temps-là.

Le contributeur néerlandias a-t-il besoin d'aide? Doit-on lui demander une
nouvelle licence plus protectrice (par exemple sous licence CC0 ou ODbL qui
n'obligerait pas à conserver la mention individuelle de AND NL, mais
seulement le collectif "Les contributeurs d'OpenStreetMap")
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sculpture d'enfant sur passage piéton

[Philippe Verdy]

A mon avis, le but n'est pas artistique ni touristique
(tourism=artwork) mais plutôt pédagogique : c'est un signal de
prudence envoyé aux usagers de la route, un peu plus sympathique qu'un
bête panneau "attention, école" ou le simple marquage au sol d'un
passage piéton.

Toutefois on ne peut pas en mettre partout, car c'est aussi un
obstacle, même si c'est sur un trottoir assez large. De loin ça fait
illusion qu'il s'agit d'un piéton. De plus près, on comprend mieux
pourquoi il y a un passage protégé. C'est loin d'être "anecdotique",
c'est en fait un indicateur au même titre que les panneaux et le
marquage, mais encore plus visible et qui doit éveiller les
consciences des conducteurs. C'est aussi destiné à indiquer aux
enfants (ou aux accompagnants) à quel endroit il est plus prudent de
traverser (effet pédagogique de prévention routière).

Je veux bien les tag "artwork_*", mais "tourism=artwork" est un peu
léger, on s'attendrait plus à un tag pour donner le sens d'une
signalisation (même si ce n'est pas la signalisation réglementaire
habituelle, sa pose sur l'espace public a dû faire l'objet d'une
demande d'autorisation, au moins à titre expérimental, souvent par une
asso locale qui n'était pas satisfaite du manque de respect de la
signalisation réglementaire existante). D'autres objets du même type
sont des panneaux imaginatifs comme "attention, traversée
d'écureuils", plus ou moins décorés et sympathiques, d'autres plus
formels avec un message plus directif "protégez nos enfants", d'autres
plus inquiétants avec un décompte des victimes de la route, un
monument funéraire, etc.

Ce genre de signalisation va souvent évoluer avec le temps, une fois
celle-ci dégradée ou accidentée, ça peut être un pas avant que la
municipalité ou la préfecture impose des mesures plus contraignantes
(radars, amendes, controle) ou se décide à mettre en place des
personnels de protection, ou fasse des travaux avec ralentisseurs,
chicanes, restrictions de voies ou de sens de circulation.

Le mer. 22 févr. 2023 à 20:00, Marc_marc  a écrit :
>
> Bonsoirr,
>
> Le 22.02.23 à 19:34, Lionel Allorge a écrit :
> > https://www.ville-lesquin.fr/actualites/vie-locale/zoe-et-arthur/
> >
> > Faut-il les noter sur OSM
>
> rien n'est obligatoire à renseigner dans osm :)
>
> > et si oui comment ?
>
> tourism=artwork
> artwork_subject=child
> artwork_type=statue ?
>
> 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] Comment tagguer une façade "rescapée" ?

[Philippe Verdy]

On a le même cas à la gare SNCF TGV de Rennes (entièrement
reconstruite deux fois dans les années 1980 avec le batiment
triangulaire avant l'arrivée du TGV, puis récemment avec la nouvelle
"colline": la façade historique a été conservée dans les deux
architectures, intégrée, même si aujourd'hui en n'en voit plus grand
chose).

Cas identique aussi pour la façade de l'ancien siège de Ouest-France
quand il est devenu l'hôtel Mercure (au dessus de la porte on voit
toujours l'ancien logo de Ouest-France. Les façades historiques ont
leur importance, mais on ne peut pas les taguer comme des "ruines".

Idem pour l'ancienne tour des usines Lu à Nantes, conservée mais
intégrée dans un centre de conférence (c'est plus qu'un mur). Ce cas
est au final assez courant car tout n'est pas nécessairement classé
dans les bâtiments historiques. Il existe aussi des murs conservés
sans plus aucun bâtiment derrière (juste des poutres de soutien
derrière avec un éventuel revêtement protecteur ou un contr-mur en
béton: on obtient des façades avec des fausses fenêtres ou portes, des
colonnades, des sculptures, de la ferronnerie décorative, des fresques
ou mosaïques, des plaques commémoratives...)

 Il devrait y avoir un tag "conservation" au moins sur le bâtiment,
avec une mention qu'il s'agit de seulement la façade.

Le mer. 15 févr. 2023 à 15:55, pepilepi...@ovh.fr  a écrit :
>
> Le 15/02/2023 à 11:56, Georges via Talk-fr a écrit :
> > Des idées ici :
> > https://wiki.openstreetmap.org/wiki/FR:Key:ruins
>
>
> Merci, mais non...
>
> C'est pas des ruines, plutôt des pans de murs préservés. J'ai déjà vu ça
> près de chez moi où un vieil immeuble avait été rasé à l'exception de sa
> façade parce qu'elle présentait un intérêt historique, et on avait
> reconstruit un immeuble ultra moderne derrière cette facade.
>
>
> >
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> --
> 
>
> Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
> bonne question.
>
> ___
> 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] tees de départ multiples sur les trous de golf

[Philippe Verdy]

Actuellement, le traitement OSM des terrains de golf exige que les
points de départs (golg=tee) soient liés par un way (golf=hole) comme
étant leur point de départ.

Le problème est que la plupart des terrains de golf n'on pas un seul
point de départ mais souvent 4 ou 5 (chacun marqués d'une couleur
correspondant à un niveau de parcours), alors que le point d'arrivée
(golf=pin) est le même (ce point peut bouger un peu sur le green
d'arrivée, comme aussi les points de départ (tees colorés) qui sont
juste approximatifs sur les buttes de départ)

Normalement on doit tracer ces ways mais faut-il tracer un way
(golf-hole) pour chacun des départs possibles? Notez que les rendus
affichent ces ways (avec un filet noir) et cela surchargerait le
rendu.

Normalement on trace juste le way (golf=hole) depuis le tee de départ
correspondant au parcours le plus long et cela devrait suffire, les
autres tees restent alors marqués à côté, près de ce chemin, mais non
reliés.

Il existe une relation pour les 9 ou 18 trous d'un même parcours,
cette relation ne définit un rôle "hole" que pour les chemins (way
"golf=hole") reliant lors le tee du parcours le plus long.

Je suggère d'ajouter le rôle "tee" pour les points de départs (tee)
des parcours plus courts (qui ne sont pas relié par un way "golf=hole"
reliant le tee coloré du parcours le plus long au point/drapeau
d'arrivée (golf=pin).

Notez aussi que le way gofl=hole a des attributs pour les notations du
"par" et du "'handicap", mais aussi les 4 ou 5 distances de parcours
pour chaque niveau (repérés par des couleurs, souvent le blanc pour le
parcours le plus long ou de compétition, les autres sont jaunes,
verts, bleus, rouges).

Enfin il manque aux parcours à 9 ou 18 trous le marquage des points de
repère (notés en violet ou orange sur les carnets de parcours) qui
indique la direction du premier tir (ces points sont visibles sur le
terrain). Il y en a un à la distance la plus longue pour les meilleurs
joueurs (depuis le tee blanc de départ le plus éloigné) et un autre
pour ceux qui ne savent pas tirer aussi loin (ou partent depuis un tee
coloré de moins grande difficulté).

D'autre part, au delà du parcours normal à 9 ou 18 trous, les golfs
ont des espaces d'entrainement et de formation "pitch and butt": on a
des tags pour les surfaces de practice (aucun tee ou pin dessus, juste
une surface plane sans tee ni pin prescrit (on les plante au besoin de
la formation et des objectifs), souvent aussi quelques petits bunkers.

Il y a bien un type défini pour les surfaces de practice (souvent on
en trouve plusieurs, dont un tout petit pour la formation initiale)
mais on a aussi des "mini-parcours" à un seul trou (un pin de départ
et un pin d'arrivée) qui ne font pas partie d'un partcours normalisé
(avec feuille de score, par, et handicap défini).

Dans les deux cas, la relation de parcours de golf à 9 ou 18 trous ne
convient pas pour ces surfaces parcours qui sont à part et sortent de
la relation. La seule chose qui les lie est qu'ils sont dans l'emprise
du terrain de golf (lequel inclut aussi le clubhouse (lieu d'un café
restaurant et de l'administration des réservations et locations de
matériels).

L'emprise est déjà formée par la délimitation du terrain de golf
(cependant il ya des zones "hors jeu", par exemple si une route
traverse le terrain ou pour le clubhouse et des équipements à
protéger/éviter: sur les carnets de jeu, les plans les affichent avec
des "points blancs" ou des liserés rouges, parfois ils sont
matérialisés sur le terrain. Les zones hors jeu au sein de l'emprise
ne sont pas encore décrites.

Quand une balle sort du jeu, il faut reprendre la partie avec une
nouvelle balle placée au plus près du point de sortie de jeu mais
parfois dans une zone dédiée (signalée sur le carnet de jeu avec plans
et feuille de score). Ces zones ne sont pas taguées actuellement.

On n'a pas de relation pour l'ensemble des équipements du golf, donc
pas moyen de relier les équipements et parcours de formation (ouverts
sans nécessité d'avoir une licence pour une initiation de moins d'une
journée, le golf proposant ces formations gratuites ou payantes avec
le matériel en prêt; caddie, cannes, et balles illimitées durant la
séance de cours).

Comment voyez-vous l'évolution pour taguer les golfs complets?

Mais la priorité, pour l'instant, c'est comment éviter que l'éditeur
signale avec une alerte les point des tees de départ supplémentaires
non reliés à un way (golf=hole). Même si on les mets dans la relation
d'un parcours complet à 9 ou 18 trous (avec un rôle manquant "tee"
pour ces points, différent du rôle "hole" pour un des parcours de
chaque trou), on n'évite pas cet avertissement: sur un parcours de
golf à 18 trous, avec 5 niveaux de difficulté, ça donne 72
avertissements (puisque seulement 18 des 90 tees sont au départ d'un
des 18 ways "golf=hole") !

___
Talk-fr mailing list
Talk-fr@openstreetmap.org

Re: [OSM-talk-fr] codes FANTOIR portés par des nodes & ways OSM et inconnus de la source FANTOIR

[Philippe Verdy]

Autoriser un ";" peut être permis sur les noeuds (par exemple les points
d'adresse qui normalement seraient situés à cheval sur 2 communes, ou
géométriquement dans le territoire d'une seule car la frontière ne passe
pas physiquement par ce point sité un peu à côté alors que c'est le point
d'accès principal vers la propriété sur l'autre commune), mais sur les ways
c'est un peu un non-sens: les ways ont une orientation, et un côté ":left"
et ":right" qui permettent de lever l'ambiguité

(on ne peut pas le faire sur un noeud à moins de préciser une direction
avec par exemple un ":north", ":south", ":west", ":east" (mais alors
combien de directions faut-il gérer et reconnaître? Dans ce cas il serait
plus simple alors de conecter un petit morceau de way passant par le noeud
en question (sans aucun attribut nécessaire) pour établir une direction, et
placer le FANTOIR alors ur ce way et non sur le noeud; le way ne servirait
pas à autre chose, ce serait juste un unique segment agissant de la même
manière que si on traçait une flèche depuis ce noeud et au lieu d'indiquer
":left" ou ":right" on utiliserait ":forward" ou backward sur ce way pour
distinguer les deux codes FANTOIR, le premier noeud serait le point
d'adresse sans code fantoir, d'où part la petite flèche, le second (sans
aucun attribut mais si on veut être explicite on peut avoir un
pseudo-attribut mentionnant son "role=pointing") la pointe de la flèche.

La longueur de la flèche et donc la position du second noeud n'a pas
d'importance tant que cette longueur n'est pas nulle, mais cette longueuir
ne devrait pas être excesive pour éviter de croiser trop de chemins, elle
doit alors être proprortionnée au niveau de détail de ce qui entoure (sans
doute pas plus de 10 mètres), et le noeud final de la pointe normalement
dans la commune pointée le premier noeud étant dans l'autre commune, cette
flèche ne devrait donc couper que le tracé frontière (sinon c'est que
le tracé de la frontière n'est pas assez affiné).

Le problème de cette approche est qu'avec un éditeur graphique actuel, on
risquerait de créer des intersections parasites: le second noeud et le
segment de flèche ne devraint pas pouvoir former des intersections ou être
sélectionnables pour en former, on ne pourrait QUE sélectionenr le premier
noeud et alors la flèche serait visible et réorientable tout en conservant
nue longieur minimale suffisante.

D'ailleurs la technique pourrait aussi servir pour les orientations de feux
de circulation ou des radars (quand ils ne sont pas placés sur le chemin
représentant la voie de circulation.

Le mer. 14 déc. 2022 à 16:22, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> > De: "leni" 
> >
> > Dans cet onglet, j'ai corrigé les codes qui étaient uniques.
> >
> > Maintenant, je regarde les codes qui sont séparés par un ";" ce qui est
> > autorisé par
> >
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR#Cas_particuliers
> >
> > Avant de me lancer, j'ai pris un premier enregistrement ; les deux codes
> > existent séparément : Pour trouver si le code est inconnu de la source
> > Pifometre prend chaque code ou l'ensemble ?
>
> Pifomètre considère le contenu du tag ref:FR:FANTOIR comme un seul code
> FANTOIR, donc en effet dans le cas de codes listés avec un ';' comme
> séparateur ça remonte en erreur. J'ai ouvert un ticket pour améliorer ça :
> https://github.com/osm-fr/osm-vs-fantoir/issues/203
>
> vincent
>
> ___
> 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] BlaBlaCar exploite des données OSM sans attribution ?

[Philippe Verdy]

je confonds peut-être avec Uber (mais que j'ai encore moins utilisé que
Blablacar) et d'autres services logistiques, qui peuvent aussi
s'échanger/se vendre des données via certaines agences. Mais là ça me
parait insuffisant pour conclure. Noter qu'en terme de droits des bases de
données il y a tout de même une notion de quantité suffisante pour
constituer un droit d'auteur exigible, et un unique tracé géométrique très
court (sans autre métadonnées) ne viole le droit de personne il me semble.
Donc il faut en trouver plus et arriver à démonter une copie réelle
(d'autant que ce fragment peut être accidentel, il est difficile de le
rapprocher du reste; tu le dis ça ressemble beaucoup mais finalement pas
avec une précision suffisante pour conclure).

Le sam. 12 nov. 2022 à 18:07, Léo El Amri  a écrit :

> À ma connaissance aucune trace GPS n'est envoyée à BlaBlaCar, en tous
> cas je n'en ai jamais envoyé, vu que l'application n'a jamais eu les
> droits d'accès à ma géolocalisation sur mon smartphone Android.
>
> Le "déport de chaussée" est en fait l'arrêt minute de la gare SNCF du
> Puy-en-Velay, qui est cartographié différemment sous GMaps de sous OSM
> (voir mon image (BlaBlaCar)) et mon lien (OSM)).
>
> Pour s'assurer que ce sont les données de cartographie de OSM, je
> pourrais modifier ce fameux déport, qui est mal cartographié au passage.
>
> J'ai franchement du mal à croire à l'hypothèse de la trace GPS vu la
> forte ressemblance de la trace avec la carte OSM...
>
> Images à superposer, ressemblance à 100% :
> https://www.dropbox.com/s/dlmd0pynklgz8sy/blablacar-suspect-osm.png?dl=0
>
> https://www.dropbox.com/s/osjrc8t9p6fg82d/blablacar-suspect-blablacar.png?dl=0
>
> On 12/11/2022 17:26, Philippe Verdy wrote:
> > Ca ressemble plus à une trace GPS collectée par l'appli mobile Blblicar
> > elle-même (le service peut impose cela aux conducteurs pour justifier les
> > trajets et parcours et tarifs demandés aux passagers, et ça peut être
> exigé
> > par exemple par des passagères qui veulent voyager en sécurité). Je n'ai
> > pas utilisé Blablacar depuis longtemps mais même à l'époque il fallait
> être
> > connecté à l'appli si on était chauffeur. De plus ça évite des litiges en
> > cas de retard ou absence de passage: le passager ne peut se défausser sur
> > le conducteur et le service peut exiger un paiement au moins partiel (en
> > cas d'absence d'assurance d'annulation payée) et aussi de payer en partie
> > au moins le chauffeur qui s'est déplacé pour rien.
> >
> > Sinon le fond de carte affiché vient de Google, qui ne connait pas un des
> > rond-points ni visiblement la présence d'un report de voie sur la
> chaussée
> > (visiblement pour travaux): cette trace ressemble bien à un trajet
> effectif
> > tel qu'il a été enregistré sur un GPS (un assez bon modèle, ou alors la
> > couvertureà cet endroit est excellente et profite de la géolocalisation
> > assistée par Google, qui croise aussi les données d'autres réseaux
> mobiles
> > et sans fil détectés, et apparemment aussi les détections d'autres
> > smartphones et appareils mobiles Bluetooth à proximité qui eux aussi se
> > géolocalisent. Enfin les systèmes par satellite se densifient et les
> > appareils mobiles peuvent en capter bien plus aujourd'hui)
> >
> > Le ven. 11 nov. 2022 à 22:54, Léo El Amri  a écrit :
> >
> >> Bonjour la liste,
> >>
> >> En préparant un trajet, je suis tombé là dessus :
> >> https://www.dropbox.com/s/ok7qhiqcj8d9mh7/?dl=0
> >> Un tracé de navigation qui ne suit pas du tout la route et qui ressemble
> >> de très très près au tracé de cette zone :
> >> https://www.openstreetmap.org/#map=18/45.04375/3.89361
> >>
> >> Qu'en pensez-vous ? Y a -t- il utilisation de données OSM et si oui, ne
> >> faudrait-il par que BlaBlaCar en fasse mention quelque-part ? En tous
> >> cas il n'y a rien de tel dans leurs mentions légales.
> >>
> >> --
> >> Léo
> >>
> >> ___
> >> Talk-fr mailing list
> >> Talk-fr@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-fr
> >>
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BlaBlaCar exploite des données OSM sans attribution ?

[Philippe Verdy]

Ca ressemble plus à une trace GPS collectée par l'appli mobile Blblicar
elle-même (le service peut impose cela aux conducteurs pour justifier les
trajets et parcours et tarifs demandés aux passagers, et ça peut être exigé
par exemple par des passagères qui veulent voyager en sécurité). Je n'ai
pas utilisé Blablacar depuis longtemps mais même à l'époque il fallait être
connecté à l'appli si on était chauffeur. De plus ça évite des litiges en
cas de retard ou absence de passage: le passager ne peut se défausser sur
le conducteur et le service peut exiger un paiement au moins partiel (en
cas d'absence d'assurance d'annulation payée) et aussi de payer en partie
au moins le chauffeur qui s'est déplacé pour rien.

Sinon le fond de carte affiché vient de Google, qui ne connait pas un des
rond-points ni visiblement la présence d'un report de voie sur la chaussée
(visiblement pour travaux): cette trace ressemble bien à un trajet effectif
tel qu'il a été enregistré sur un GPS (un assez bon modèle, ou alors la
couvertureà cet endroit est excellente et profite de la géolocalisation
assistée par Google, qui croise aussi les données d'autres réseaux mobiles
et sans fil détectés, et apparemment aussi les détections d'autres
smartphones et appareils mobiles Bluetooth à proximité qui eux aussi se
géolocalisent. Enfin les systèmes par satellite se densifient et les
appareils mobiles peuvent en capter bien plus aujourd'hui)

Le ven. 11 nov. 2022 à 22:54, Léo El Amri  a écrit :

> Bonjour la liste,
>
> En préparant un trajet, je suis tombé là dessus :
> https://www.dropbox.com/s/ok7qhiqcj8d9mh7/?dl=0
> Un tracé de navigation qui ne suit pas du tout la route et qui ressemble
> de très très près au tracé de cette zone :
> https://www.openstreetmap.org/#map=18/45.04375/3.89361
>
> Qu'en pensez-vous ? Y a -t- il utilisation de données OSM et si oui, ne
> faudrait-il par que BlaBlaCar en fasse mention quelque-part ? En tous
> cas il n'y a rien de tel dans leurs mentions légales.
>
> --
> Léo
>
> ___
> 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] Points géodésiques disparus ?

[Philippe Verdy]

Pour ce genre de chose je trouve bizarre que de tels points frontières
ne soient même pas utilisés dans les définitions officielles pour
géolocaliser les limites cadastrales des communes concernées. Mais
visiblement cela a été fait pour justement ne pas lier les points
géodésiques aux autres objets. Bref, ils auraient dû définir un point
voisin mettant explicitement le point géodésique dans la bonne commune
concernée (après accord des deux communes limitrophes, et faute
d'accord revoir leur description pour que cela corresponde à la
géométrie. Cependant la géométrie s'appuyait aussi sans doute sur une
ancienne géodésie de référence, la triangulation ayant pu changer
entre-temps. Mais là encore, suite au changement de triangulation, une
vérification des points géodésiques concernés aurait dû avoir lieu.

Mettre une note dans OSM c'est bien, mais il vaut quand même mieux
remonter l'info aux autorités concernée pour qu'elles revoient leur
modèle et mettent à jour leur base, une fois les décisions prises.
Cela devrait donc être suivi. Mais c'est bizarre qu'il ait fallu
attendre une vérification tierce par OSM et que l'IGN ne l'ait pas
déjà effectuée et pris contact avec les communes concernées (et faute
d'accord cherché à obtenir une décision préfectorale, tant qu'il n'y a
pas de recours judiciaire administratif entre les communes concernées
ou les occupants des terrains qui ne voudront peut-être pas des
changements de leur situation fiscale ou être exposés à de nouvelles
contraintes légales différentes d'une commune à l'autre, comme
l'occupation des sol, les règles environnementales sur la pollution ou
le bruit, la protection du patrimoine, ou encore les règles propres à
la loi de protection du littoral, ni se voir opposer des refus
d'aménagement ou de permis de construire, voire imposer des
démolitions et remises en état, ou un nouveau régime fiscal juste
parce qu'un micro-bout de terrain passe sur la commune voisine).

Le mer. 24 août 2022 à 18:13, leni  a écrit :
>
>
> Le 24/08/2022 à 15:47, Marc_marc a écrit :
> > Le 24.08.22 à 14:46, deuzeffe a écrit :
> >> (re)Bonjour,
> >>
> >> Toujours en jardinant (à l'ombre !), je trouve ces signalements
> >> osmose :
> >> https://osmose.openstreetmap.fr/fr/issues/open?country=france_limousin_haute_vienne=6070
> >> qui sont des points géodésiques hors des frontières communales.
> >>
> >> En consultant la source des données*
> >> https://geodesie.ign.fr/fiches/index.php?module=e=visugeod, je
> >> ne les retrouve pas.
> >
> > je pense que c'est 2 soucis différents :
> > 1) le repère n'existe plus dans l'opendata (pas regardé
> >
> > 2) le signalement osmose, par exemple
> > https://osmose.openstreetmap.fr/fr/issue/5e2ddd67-7201-1326-c705-77ce654fd493
> >
> > trouve une relation géodésique dans osm mais dont la ref 8703903
> > indique qu'elle devrait se situé dans la commune Château-Chervix ref
> > insee 87039
> > mais ce repère est 23cm hors de cette commune
> > soit le repère a été bougé soit la frontière a été b y a une erreur de
> > localisation dans l'opendata ayant conduit à crée ces repères dans osm
>
> Il y a quelque temps j'avais posé la question pour un point à l'IGN qui
> m'avait aimablement répondu :
>
> "En effet, il apparaît que le point géodésique soit géométriquement sur
> la commune de Saint-Béat-Lez et non sur celle d’Arlos.
> Ce sujet d’appartenance administrative peut être un peu plus complexe
> lorsque l’on regarde de près, car d’un point de vue officiel les limites
> administratives sont définies par une description textuelle et non par
> une donnée géographique.
> En tout cas, lors de la construction du point en 1949, les géodésiens
> ont estimés que ce point se situait sur la comme d’Arlos,
> vraisemblablement en raison de sa position par rapport à la crête. Le
> point a ainsi été nommé Alors I, or quand nous conservons la
> dénomination des points telles qu’elles ont été définies à la
> construction du point."
>
> j'avais donc indiqué faux-positif à osmose et ajouté une note sur
> l'objet pour expliquer
>
> leni
>
>
> ___
> 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] Est-ce une borne a incendie ?

[Philippe Verdy]

de quoi brancher dessus des charriots mobiles d'arrosage avec un raccord,
ou simplement s'il y a des paturages de quoi remplir des citernes pour
l'abreuvage du bétail.

Et s'il y a un compteur ce n'est pas forcément parce que c'est de "l'eau de
ville", mais que la loi impose de mesurer l'utilisation de l'eau, même
puisée dans le milieu naturel (c'est aussi le cas pour les pompes dans les
puits privés, qui sont munis de compteurs scellés et qui peuvent être
contrôlés n'importe quand, bien que les propriétaires doivent relever les
chiffres régulièrement, et peuvent aussi avoir à payer une taxe régulière
sur ce prélèvement, qui peut être mensualisée sur des bases estimatives).

Le comptage pour les besoins agricoles (cultures et élevages) est encore
plus nécessaire étant donné leur volume très souvent bien plus élevé qu'une
consommation privée et qui peut impacter le niveau des nappes souterraines
voire assécher aussi les cours d'eau en surface qui alimentent les
prélèvements publics en aval. Le compteur doit aussi être lisible
facilement en cas d'utilisation d'urgence par les pompiers (mais ils ne
relèvent pas toujours quand ils commencent l'intervention...) pour éviter
au propriétaire ou exploitant de payer de lourdes taxes ensuite sur des
prélèvements publics faits sur des captations privées (comme la loi les y
autorise, quand ils le font dans les piscines privées c'est facile à
mesurer, mais cela ne donne pas nécessairement le droit au propriétaire ou
locataire de la piscine ensuite de refaire le plein en période de
restriction, ni de s'en servir comme dans ces périodes pour des arrosages
ou lavages interdits ou de les purger, même si l'eau est devenue impropre à
la baignade)

En revanche le remplissage par des systèmes de récupération et filtration
des eaux de ruissellement est évidemment autorisé mais pas pour la
consommation humaine car cette eau peut être polluée, mais elle permet de
remplir piscines, bassins, étangs, au lieu de courir dans les fossés et
engorger les cours d'eau: ces retenues artificielles sont utiles contre les
crues d'orage ou les crues hivernales quand les sols et cours d'eau en aval
ne peuvent plus absorber le surplus; ils évitent des glissements de
terrains et autres catastrophes. Malheureusement en France on assèche
encore les plus anciens étangs et mares, pour les cultures, puis ensuite on
fait appel aux arrosages avec captation dans les nappes ou cours d'eau
quand l'eau est la plus restreinte, c'est bien dommage alors que les étangs
et mares naturels profitait d'un relief et d'un sol favorable, et d'une
filtration naturelle par les végétaux qui aussi aidait à dépolluer et
évitaient les contaminations par infiltration des nappes dans les sols
moins argileux).

Le lun. 9 mai 2022 à 22:25, pepilepi...@ovh.fr  a
écrit :

> Le 09/05/2022 à 21:08, Ludovic Hirlimann a écrit :
> >
> >
> > On 5/9/22 19:38, pepilepi...@ovh.fr wrote:
> >> Le 09/05/2022 à 16:02, Jacques Lavignotte a écrit :
> >>> Le 09/05/2022 à 15:30, Yves Pratter a écrit :
> >>>
>  Je pencherais pour un système d'irrigation
> >>> Je penche dans le même sens.
> >> +1
> >>
> >> Quand tu dis "... long des petites routes non loin des habitations", je
> >> parie que c'est plus précisément long des petites routes *dans la
> >> campagne* et non loin des *fermes* ?
> > Oui
>
>
> Ça cconfirme bien l'irrigation !
>
>
> --
> 
>
> Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
> bonne question
>
> ___
> 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] Base de donnée nationale des bâtiments

[Philippe Verdy]

Concernant la classification énergétique des batiments, il y a de gros
trous dans les données (nombre de batiment certifiés BBC, ou ayant des
pompes à chaleur, ne sont pas présents).
Sinon les polygones des batiments sont très incomplets et moins précis que
ce qu'on a (aussi bien en position, que taille, orientation et découpage).
On peut se demander si ces polygones n'ont pas été simplement estimés sur
des vues aériennes basse résolution, et que le rapprochement avec les
autres bases top et IGN n'a pas été fait, mais juste que dans ce premier
jet, il y a eu des estimations sur seulement les points d'adresse
répertoriés, et que le reste est incomplet

Et cela ne donne pas une précision suffisante en terme d'effort à produire
sur la rénovation des batiments (qui traine en longueur et n'a pas rempli
ses objectifs initiaux pour n'atteindre avec peine que 650 000
batiments par an, Macron annonçant passer seulement à 700 000
batiments, très loin des objectifs pour tenir les engagements de la COP21
et donc trop tard pour l'échéance irréversible seulement dans 3 ans: on
dépassera nécessairement les 2 degrés de réchauffement, et si les efforts
produits en France ont eu un léger effet, cet effet est totalemetn anunlé
par la hausse énorme des importations: la pollution qui n'est plus produite
en France l'est ailleurs à une échelle bien pire; on n'a même pas les
instruments pour mesurer les émissions sur les produits importés qu'on
consomme, et la crise énergétique actuelle ne va pas améliorer les choses
mais faire prendre encore plus de retard; il suffit de voir ce qui se passe
au Liban où la forêt brule massivement pour faire du charbon, faute de gaz;
et les zones en crise se multiplient et s'étendent). Les priorités n'ont
pas été suivies, on commence à peine à ébaucher les plans de ce qui serait
nécessaire, mais déjà les lois vont devenir très contraignantes dès 2025 au
point que cela va paralyser l'immobilier.

Il faudrait changer d'échelle avec des mesures réelles des pertes d'énergie
par les batiments, par des plans de vol, des données plus détaillées des
founisseurs d'énergie, et aussi des ajouts lors du recensement et les
transactions immobilières, sans les paralyser pour autant (sinon on va
aggraver la crise du logement et les prix de ce qui reste sur le marché
vont flamber, et avec elle on aura aussi une grave crise financière et des
tas de gens dehors sans toit, ou qui se rabattront sur des logements de
fortune sans aucune isolation acceptable et paieront encore plus cher leur
énergie).

La transition climatique va faire des ravages, même en France où on ne
mesure toujours pas bien l'impact de ce qui va arriver et où on n'a encore
aucun plan sérieux. [La Chine pourrait être mieux armée pour y résister,
elle investit massivement y compris dans l'audit de ses bâtiments, mais
aussi dans le renforcemetn de sa sécurité intérieure pour prévenir ou
contenir les troubles qui vont arriver.]
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OSM-Talk-fr] tagger les dark store

[Philippe Verdy]

Note: ma remarque vaut aussi pour tous les tags "*type*", ce mot-clé
n'indiquant jamais rien, puisque presque tous les tags (sauf ceux de noms
ou de description libre ou commentaires, ou ceux de quantités y compris les
horaires, ou ceux de liaison comme les URI et identifiants externes)
servent à faire une typologie de quelque chose, selon un axe qui reste à
préciser clairement et en désignant cet axe explicitement.

Le mot-clé "type" (de même que "class", en pratique équivalent ici car on
ne fait pas de distinction dans un langage de programmation objet avec les
types natifs/prédéfinis et les types construits et définis par
l'utilisateur avec ce mot-clé spécial dans ces langages) ne sert à rien
dans le nom d'un tag, car c'est un fourre-tout utilisé trop facilement
(sans réflexion ni discussion préalable) juste par les premiers
utilisateurs qui n'ont pas réfléchi à évolutions possibles et d'autres
usages et que le leur, selon des axes non précisés/non définis clairement ;
imaginons qu'on ait eu "tree:type" on mettrait n'importe quoi: feuillus à
feuillage persistant ou non, essences, espèces,genres, usage fruitier,
cycles de vie, etc.).


Le mer. 6 avr. 2022 à 16:45, Philippe Verdy  a écrit :

> "range"? Pas d'accord (non-sens ou trop de faux-amis, ce mot étant trop
> ambigu en anglais). Idem avec "scope" qui a clairement d'autres
> implications sémantiques.
>
> Car sinon on a d'autres types d'étendues ("scopes") de type "sectoriel"
> (par tranche de population, par âge, par domaine d'activité...)
>
> Méfiez vous des "tags" trop génériques et du risque de télescopage quand
> ils vont être utilisés pour qualifier d'autres tags, surtout s'il y en a
> plusieurs (on peut penser par exemple aux bâtiments et infrastructures ou à
> divers types de zonages naturels qui se superposent, ou encore aux
> "landuse" combinés avec "natural", "surface", etc.), dans ce cas "range" ne
> sera pas clair
>
> Plutôt "coverage" qui est à mon sens le seul mot désignant une étendue
> géographique, voire "service:coverage" si on veut limiter les dégâts futurs.
>
>
> Le jeu. 31 mars 2022 à 18:33, Florian LAINEZ  a écrit :
>
>> OK on arrive donc à une proposition qui me plaît bien :
>> - industrial=warehouse
>> -
>>
>> operator=Frichti;Kol;Cajoo;Flink;Getir;Gorillas;Glovo;GoPuff;Yango;Deli;Zapp;Rohlik;Bam
>> Courses
>> - range=local (les valeurs regional;national;international étants
>> autorisées pour d'autres entrepôts que ceux des dark stores avec cette
>> clef)
>>
>> Banco ?
>>
>> Après on verra si Marc ou quelqu'un d'autre veut affronter^^ la liste
>> > tagging
>>
>> Je suis sorti dégoûté de mes derniers essais. Je passe mon tour.
>>
>>
>> Le jeu. 31 mars 2022 à 16:58, Francois Gouget  a écrit :
>>
>> > On Sat, 26 Mar 2022, Florian LAINEZ wrote:
>> >
>> > > >
>> > > > warehouse=local pour distinguer des plateformes logistiques livrant
>> sur
>> > > > une région / un pays ?
>> > >
>> > > Là on commence à parler !
>> > >
>> > > En marking il existe un concept de "zone de chalandise" qui est l'aire
>> > > couverte par la livraison ou le lieu d'habitation des clients.
>> > > Du coup, peut-être *target=local;regional;national;international* ?
>> > target
>> > > <https://wiki.openstreetmap.org/wiki/Key:target> étant déjà utilisé
>> sur
>> > les
>> > > ambassades pour désigner le pays cible.
>> > > Néanmoins target n'est pas très spécifique, peut être :
>> > > - catchment_area (qui est la traduction de zone de chalandise)
>> > > - range (mon choix préféré)
>> > > - reach
>> > > - scope
>> > >
>> > > Il existe aussi visibility
>> > > <https://wiki.openstreetmap.org/wiki/FR:Key:visibility> pour panneaux
>> > > d'affichage : visibilty=house;street;area qui est similaire mais pas
>> > > applicable en l'état.
>> >
>> > Il y a aussi map_size qui me semble un peu similaire et donc pourrait
>> > peut-être amener à une uniformisation après renommage.
>> >
>> >   map_size=* - Quelle est la zone couverte par la carte ?
>> >   map_size=site | city | landscape | region
>> >
>> >   https://wiki.openstreetmap.org/wiki/Tag:information%3Dmap#map_size
>> >
>> > --
>> > Francois Gouget   http://fgouget.free.fr/
>> >   Sufficently advanced incompetence is indistinguishable from
>> malice.
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>> >
>>
>>
>> --
>>
>> *Florian Lainez*
>> @overflorian <http://twitter.com/overflorian>
>> ___
>> 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] [OSM-Talk-fr] tagger les dark store

[Philippe Verdy]

"range"? Pas d'accord (non-sens ou trop de faux-amis, ce mot étant trop
ambigu en anglais). Idem avec "scope" qui a clairement d'autres
implications sémantiques.

Car sinon on a d'autres types d'étendues ("scopes") de type "sectoriel"
(par tranche de population, par âge, par domaine d'activité...)

Méfiez vous des "tags" trop génériques et du risque de télescopage quand
ils vont être utilisés pour qualifier d'autres tags, surtout s'il y en a
plusieurs (on peut penser par exemple aux bâtiments et infrastructures ou à
divers types de zonages naturels qui se superposent, ou encore aux
"landuse" combinés avec "natural", "surface", etc.), dans ce cas "range" ne
sera pas clair

Plutôt "coverage" qui est à mon sens le seul mot désignant une étendue
géographique, voire "service:coverage" si on veut limiter les dégâts futurs.


Le jeu. 31 mars 2022 à 18:33, Florian LAINEZ  a écrit :

> OK on arrive donc à une proposition qui me plaît bien :
> - industrial=warehouse
> -
>
> operator=Frichti;Kol;Cajoo;Flink;Getir;Gorillas;Glovo;GoPuff;Yango;Deli;Zapp;Rohlik;Bam
> Courses
> - range=local (les valeurs regional;national;international étants
> autorisées pour d'autres entrepôts que ceux des dark stores avec cette
> clef)
>
> Banco ?
>
> Après on verra si Marc ou quelqu'un d'autre veut affronter^^ la liste
> > tagging
>
> Je suis sorti dégoûté de mes derniers essais. Je passe mon tour.
>
>
> Le jeu. 31 mars 2022 à 16:58, Francois Gouget  a écrit :
>
> > On Sat, 26 Mar 2022, Florian LAINEZ wrote:
> >
> > > >
> > > > warehouse=local pour distinguer des plateformes logistiques livrant
> sur
> > > > une région / un pays ?
> > >
> > > Là on commence à parler !
> > >
> > > En marking il existe un concept de "zone de chalandise" qui est l'aire
> > > couverte par la livraison ou le lieu d'habitation des clients.
> > > Du coup, peut-être *target=local;regional;national;international* ?
> > target
> > >  étant déjà utilisé
> sur
> > les
> > > ambassades pour désigner le pays cible.
> > > Néanmoins target n'est pas très spécifique, peut être :
> > > - catchment_area (qui est la traduction de zone de chalandise)
> > > - range (mon choix préféré)
> > > - reach
> > > - scope
> > >
> > > Il existe aussi visibility
> > >  pour panneaux
> > > d'affichage : visibilty=house;street;area qui est similaire mais pas
> > > applicable en l'état.
> >
> > Il y a aussi map_size qui me semble un peu similaire et donc pourrait
> > peut-être amener à une uniformisation après renommage.
> >
> >   map_size=* - Quelle est la zone couverte par la carte ?
> >   map_size=site | city | landscape | region
> >
> >   https://wiki.openstreetmap.org/wiki/Tag:information%3Dmap#map_size
> >
> > --
> > Francois Gouget   http://fgouget.free.fr/
> >   Sufficently advanced incompetence is indistinguishable from malice.
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
>
> --
>
> *Florian Lainez*
> @overflorian 
> ___
> 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] [OSM-Talk-fr] tagger les dark store

[Philippe Verdy]

Je suivais toujours, mais franchement les discussions en cours ne
m'intéresszient pas beaucoup et surtout j'ai d'autres urgences, et OSM
n'est pas ma seule activité.
Cependant maintenant je reçois beaucoup trop de mails (qui ont explosé avec
le COVID et les notifications venant de partout, et les nouveaux abus de
sociétés qui ne veulent même plus respecter les demandes d'effacement de
données personnelles, et achètent des fichiers de sources interdites en
utilisant la procédure abusive de "l'opt-out" à chaque fois qu(elles créent
de nouvelles annonces ou marques; pour certaines même il est devenu
impossible de s'en désinscrire sans d'abord autoriser tous les systèmes de
suivi, ce qui a pour effet d'aussitôt transmettre les données à de nouveaux
tiers qu'on n'a jamais demandé à contacter)
Et pourtant je bloquer déjà énormément de choses, je fais le plus attention
possible à ne rien accepter et je boycotte déjà un grand nomre de sites
français qui se sont mis à exiger un suivi intégral ou sinon exiger un
abonnement payant) J'ai beau mettre des tas de filtres, utiliser divers
bloqueurs et antitraceurs, cette pub envahissante par mail est devenue
infernale, et même faire du nettoyage prend beaucoup de temps, et je ne
peux pas le faire en permanence, ce sont des centaines de mail tous les
jours maintenant, à toute heure.


Le ven. 25 mars 2022 à 07:57, Florian LAINEZ  a écrit :

> Tiens, le grand retour de Philippe Verdy ! On s'inquiétait de ton absence
> ;)
>
> @marc_marc beaucoup de tes réponses se trouvent dans le rapport de l'APUR,
> je vais les résumer ici :
> - ces entrepôts sont parfois dans des locaux industriels, mais la plupart
> du temps au rdc d'un bâtiment d'habitations (dans la plupart des cas, ils
> remplacent un ancien commerce)
> - il sont rarement "invisibles" depuis la chaussée : la plupart du temps,
> une enseigne ou à défaut une rangée de scooters garés devant permet de les
> identifier clairement
> - la liste des operator est mentionnée dans le rapport
> - c'est un marché très récent amené à être consolidé : l'operator évoluera
> sûrement assez rapidement, en effet. Néanmoins le concept même de dark
> store est amené à perdurer, ça vaut donc le coup de standardiser des tags
> pour cela.
> - Je vois un réel intérêt à les cartographier, à la fois pour mieux évaluer
> les nuisances perçues par le voisinage que pour prendre en compte leur
> nouvelle utilité sociale
>
> la logistique du dernier km est une activité industrielle ?
> >
> c'est une bonne remarque : c'est à la croisée d'une activité industrielle
> et de "retail". Néanmoins, si je devais choisir, étant donné que l'accès
> est interdit au public, je pencherai du côté industriel/logistique
>
> Du coup, j'ai l'impression qu'on est toujours sur :
> - industrial=warehouse
> -
>
> operator=Frichti;Kol;Cajoo;Flink;Getir;Gorillas;Glovo;GoPuff;Yango;Deli;Zapp;Rohlik;Bam
> Courses
>
> Le jeu. 24 mars 2022 à 13:30, Eric SIBERT  a
> écrit :
>
> >
> >
> https://www.lemonde.fr/economie/article/2021/03/17/dark-store-plongee-dans-un-supermarche-de-l-ombre_6073393_3234.html
> >
> > Eric
> >
> > Le 24/03/2022 à 12:58, Philippe Verdy a écrit :
> > > C'est des commerces légaux au moins? Parce que "dark store" ça
> semblerait
> > > montrer autre chose, comme
> > > - des lieux de revendeurs ou trafiquants
> > > - des ateliers ou cuisines clandestines
> > >
> > > Sinon, on n'a pas de meilleur terme? Ça ressemble en fait plus à un
> > > pseudo-anglicisme (il suffit de voir les marques créées en France!), je
> > me
> > > demande si les britanniques ou américains utilisent vraiment ça.
> > > Avant de taguer, vous avez des refs ailleurs qu'en France?
> > >
> > > Le mer. 23 mars 2022 à 19:21, Florian LAINEZ  a
> > écrit :
> > >
> > >> Hello,
> > >> Les "dark store <https://fr.wikipedia.org/wiki/Dark_store>" pullulent
> > dans
> > >> nos villes, comment mapper ça ?
> > >> L'agence d'urbanisme parisienne APUR a récemment publié une étude
> dédiée
> > >> <
> > >>
> >
> https://www.apur.org/sites/default/files/drive_pietons_dark_kitchens_dark_stores_paris.pdf?token=QHM2BKlT
> > >>>
> > >> et j'en déduis les points suivants :
> > >> - les lieux ne sont pas accessibles au public : ce sont des entrepôts
> et
> > >> non des commerces.
> > >> Néanmoins building=warehouse n'est pas adapté car le lieu est souvent
> > situé
> > >> au rdc d'un bâtiment d'habitations.
> > >> - il faut donc *le plus souvent* les tagger avec un point, comme ici
> par
&g

Re: [OSM-talk-fr] [OSM-Talk-fr] tagger les dark store

[Philippe Verdy]

C'est des commerces légaux au moins? Parce que "dark store" ça semblerait
montrer autre chose, comme
- des lieux de revendeurs ou trafiquants
- des ateliers ou cuisines clandestines

Sinon, on n'a pas de meilleur terme? Ça ressemble en fait plus à un
pseudo-anglicisme (il suffit de voir les marques créées en France!), je me
demande si les britanniques ou américains utilisent vraiment ça.
Avant de taguer, vous avez des refs ailleurs qu'en France?

Le mer. 23 mars 2022 à 19:21, Florian LAINEZ  a écrit :

> Hello,
> Les "dark store " pullulent dans
> nos villes, comment mapper ça ?
> L'agence d'urbanisme parisienne APUR a récemment publié une étude dédiée
> <
> https://www.apur.org/sites/default/files/drive_pietons_dark_kitchens_dark_stores_paris.pdf?token=QHM2BKlT
> >
> et j'en déduis les points suivants :
> - les lieux ne sont pas accessibles au public : ce sont des entrepôts et
> non des commerces.
> Néanmoins building=warehouse n'est pas adapté car le lieu est souvent situé
> au rdc d'un bâtiment d'habitations.
> - il faut donc *le plus souvent* les tagger avec un point, comme ici par
> exemple https://www.openstreetmap.org/node/9600880977
>
> industrial=warehouse pourrait fonctionner, surtout que son usage explose
> cf. https://taginfo.openstreetmap.org/tags/industrial=warehouse#chronology
> à cela, on rajoute
> operator=Frichti;Kol;Cajoo;Flink;Getir;Gorillas;Glovo;GoPuff;Yango
> Deli;Zapp;Rohlik;Bam Courses
>
> Un tag supplémentaire ne serait-il pas le bienvenu pour préciser que c'est
> du commerce de détail ?
> J'oublie autre chose ?
>
> --
>
> *Florian Lainez*
> @overflorian 
> ___
> 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] Cartographie des points des "coffee shop"

[Philippe Verdy]

Le mer. 23 févr. 2022 à 11:52, Jacques Lavignotte 
a écrit :

> Le 23/02/2022 à 11:26, FR via Talk-fr a écrit :
> > Qu'est-ce qu'on fait ?
> C'est conforme au terrain ?


Puisque ce sont des "installations" illégales, elles ne sont pas stables
sur le terrain. Donc pas conformes au modèle OSM.

Mais peut-être que la volonté de l'utilisateur est moins d'en faire la
"publicité" que de les signaler pour que les autorités interviennent et les
faire dégager.

Mais OSM n'est pas une plateforme pour ça (même pour une "action
citoyenne") : il peut toujours aller porter plainte ou écrire au procureur
et sinon maintenir une liste et la remettre à la disposition de la ville (y
compris par une lettre ouverte signalant que des lieux ont été signalés à
différentes dates et qu'ils persistent, mais évidemment en évitant de
géolocaliser pour tout public et éviter l'effet publicitaire sur une carte
trop visible, sinon OSM va devenir une plateforme de contact pour tous les
trafics afin de signaler aux "clients" les endroits où ils font, parfois,
ces reventes).

Dans le même ordre d'idée, les décharges sauvages et pollutions (sauf si
justement elles durent et qu'après des mois de signalement, rien n'est fait
et que le problème s'aggrave : là on est en droit il me semble de maintenir
une cartographie des zones à problème persistant). Cependant je pense que
des cartes communautaires dédiées (utilisant juste OSM comme fond de carte
commun) utilisées sur des sites, blogues ou applications spécifiques seront
mieux placées (et sans doute avec une meilleure forme qu'une liste de
points, comme une carte statistique présentant la densité des infos, ou la
fréquence constatée et mesurée par des outils communautaires ou publics,
comme les données que doivent fournir les autorités sur les actions de
police, judiciaires, sécuritaires ou sur la santé publique afin que les
citoyens puissent mesurer les actions prises et leur efficacité).

(Et là sur un site ad hoc l'attribution doit être présente avec la
signature et la responsabilité de celui qui publie ça: aucun intérêt pour
les autres si c'est une publication anonyme, sauf pour alimenter des débats
politiques stériles et des confrontations, comme ce qui se passe avec les
"fake news" qui inondent les réseaux sociaux).



OSM ne peut pas alléguer des faits potentiellement graves au plan juridique
sans preuves, les éléments de la carte n'étant pas des preuves, et OSM ne
pouvant pas en fournir lui-même pour soutenir et défendre les assertions,
il prendrait un risque juridique trop élevé pouvant porter préjudice à tout
le reste du projet. ce que peut fournir OSM ce sont juste des
"informations" vraisemblables mais à charge ensuite à ses réutilisateurs de
voir si cela offre une utilité et n'induit pas trop d'erreurs ou trop de
bruit pour rien.

C'est comme le marquage de la signalisation routière: OSM ne fournit aucune
obligation ou interdiction et n'est pas responsable en cas de changement
sur le terrain (où c'est le conducteur ou le visiteur sur place qui doit se
conformer à ce qui s'y trouve réellement, il est juste aidé en lui donnant
des indications sur ce à quoi il pourrait s'attendre, mais là encore OSM
doit éviter d'être une source de bruit déplaçant trop l'attention hors de
l'observation du terrain ; c'est aussi pour ça qu'on met des étiquettes de
classification précises permettant de faire le tri et de ne pas tout
afficher non plus sur ce qui n'intéresse pas l'utilisateur, selon ses choix
personnels: ces attributs sont utiles à partir du moment où il y a des
applis pour les exploiter et qu'ils sont basés sur un modèle documenté et
assez bien hiérarchisé pour permettre des filtres à des niveaux de détail
différents ou des agrégations).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] L’OGC adopte Symcore comme standard des feuilles de style carto

[Philippe Verdy]

Il est bon d'indiquer ici un lien plus pertinent sur ce standard de "codage
de symbologie" proposé par l'OGC:

https://www.ogc.org/standards/se

En mai 2015, pas en 2020, et je ne vois pas de mise à jour plus récente, ou
alors Ouest-France a omis de mentionner ce qui était nouveau pour leur
récent article ; sans doute le résultat d'une rencontre un peu fortuite, et
un journaliste qui ne savait pas comment remplir une colonne avec autre
chose que l'actu sur la covid, étant donné que l'actu culrurelle est encore
largement au point mort et que nombre d'activités locales sont arr^étées ou
fortement ralenties.

On devrait inviter Ouest-France à s'intéresser aux projets libres qui
mobilisent pas mal de monde depuis des mois et qui n'ont pas autre chose à
faire en attendant. Et s'intéresser à la reconversion de l'économie et de
la vie sociale pour survivre à cette crise en utilisant largement les TIC
(mais aussi montrer les problèmes posés par l'incroyable puissance des
GAFAM qui profitent de la crise mondiale en rendant les gens esclaves de
leurs solution et de leurs très coûteux biais liberticide de présentation
qui réduit un tas de monde au silence). Ouest-France doit montrer que
l'enjeu n'est pas les TIC (c'est juste un moyen à se réapproprier
localement, et il n'y a que le monde du libre qui peut le faire, les
gouvernements y ayant quasi totalement renoncé via leurs agences publiques
"officielles").



Le jeu. 17 déc. 2020 à 18:13, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

> Ouest-France annonce que le chercheur breton, Erwan Bocher
> (CNRS-Université de Bretagne-Sud), associé au Suisse, Olivier Ertz, a
> convaincu l’Open Geospatial Consortium d’adopter le standard Symcore qui a
> pour but d’offrir une symbologie cartographique unifiée a des données
> géospatiales venant de différentes sources.
>
> Voir article Ouest-France du 17-12 :
> https://www.ouest-france.fr/sciences/un-francais-a-l-origine-d-une-petite-revolution-dans-le-monde-de-la-cartographie-7090069
>
> Voir site d’Erwan Bocher :
> http://r1.bocher.free.fr/index.php?n=Main.Publications
>
> Qui peut nous dire si cela va impacter OSM ?
>
>
> Christian R.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[Philippe Verdy]

Le jeu. 26 nov. 2020 à 17:32, Frédéric Rodrigo  a
écrit :

> >> Ça donne 1537 changesets concernant chacun entre 1 et 96 bureaux de
> poste.
> > pq pas si t'as envie... mais un import avec des changeset n'ayant
> > parfois qu'un bureau, cela limite l'intérêt du changeset.
> > perso un changeset pour la france ou un par région, cela me choque
> > pas, ces bureaux n'avaient de toute façon pas d'horaire.
> > mais peu importe ton choix à ce niveau, ce point est pour moi ok,
>
> Même avis ici aussi.
>
> 1 537 changets pour 9 730 objets. Ça fait quand même vraiment beaucoup de
> changesets.


Un simple découpage par les deux premiers chiffres du code postal suffirait
: 100 changesets maxi et ça donne pas tant d'objets que ça par changeset
(au pire ~200 points dans un département densément peuplé et assez grand
avec beaucoup de bureaux, en région parisienne, ou dans le Nord, et en fait
moins dans les départements plus ruraux où il n'y a même pas un bureau par
commune). Ca donne des changeset tout à fait exploitables, faciles à
analyser et de taille raisonnable.

L'autre solution: les importer en triant la liste simplement par code
postal, et faire un changeset par groupe de taille fixe comme 500 codes
(donc 500 noeuds ou polygones), la limite d'OSM étant autour de 2000. On
fera enb sorte de garder les DROM et COM séparés (ils sont très distants
territorialement des autres et entre eux, c'est mieux pour éviter d'irriter
les autres utilisateurs d'OSM hors de France).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import fichier CSV OSM

[Philippe Verdy]

Ce CSV peut cependant être utile à des outils de rapprochement existants,
comme Osmose qui *propose* (mais ne fait pas) de l'intégration. On a le cas
par exemple pour l'intégration des écoles et de toutes sortes
d'équipements, dont de nombreux sont déjà dans OSM, mais ne demandent qu'à
être rapprochés et validés.
De même pour ce sujet des adresses, on a l'intégration BANO: n'est-il pas
plus simple alors de rapprocher ce CSV venant de l'office du tourisme du
fichier produit par la mairie pour la BAN, sachant qu'au final il y aura
rapprochement entre la BAN et BANO pour une intégration OSM ?

Dans ce cas on peut inviter l'office du tourisme à se rapprocher du/des
mairie(s) concernées pour voir comment ils peuvent tous se synchroniser et
"accorder leurs violons", afin que chacun s'enrichisse directement (il faut
savoir que l'intégration d'OSM vers les autres sources est très difficile,
et très long, le guichet d'échange BAN/BANO ne fonctionnant bien que dans
un seul sens, BAN vers BANO et pas l'inverse, même quand on fait les
signalements dans l'outil adhoc créé pour la BANO, il faut des mois ou plus
pour voir les différences disparaître ou pour que celles-ci soient
requalifiées une fois un accord trouvé).

Donc je pense qu'il est plus prudent pour l'office de tourisme de se
rapprocher avec la BAN s'il veut une intégration plus rapide, mais si ça
bloque sur ce point, il peut faire un second rapprochement ensuite avec les
outils BANO (qui affichent déjà les différences BAN/BANO, et permet
justement de trouver ce qui devrait être vérifié en priorité dans les
autres bases à rapprocher. Si l'office de tourisme pense qu'il a de
meilleures données qualifées que la mairie pour la BAN, alors il peut
contribuer directement dans OSM sur ces points particuliers, et il mettra
donc assez vite à jour le rapprochement BAN/BANO vers un peu plus de
convergence.

Mais tout ce processus de convergence est long, il faut être patient et
accepter des marges acceptables de différence correspondant à l'emploi de
chaque base de données: souvent un office de tourime n'a pas besoin par
exemple du même degré de précision spatiale, et il peut communiquer aussi
sur des noms et orthographes proches correspondant à un usage local ou
fréquent ou lié à d'autres langues : OSM a déjà pas mal de champs pour ces
variations de noms, mais rien pour les variations de géométrie, le seul
critère à retenir étant le facteur d'échelle de la carte qu'on veut
réaliser et afficher: un office de rtourisme n'a pas forcément besoin d'un
point très précis pour faire une carte de tout son territoire couvert (à
l'échelle d'une ou plusieurs communes, ou à l'échelle d'un site particulier
avec ses zones de service liées : hôtels, restaus, campings, accès et
réseaux de transport).

En revanche il peut être intéressant pour lui de voir comment mieux
qualifier les tags de nomenclature OSM afin de correspondre aux usages,
notamment pour les recherches thématiques. OSM est riche sur ce point, mais
il peut y avoir des surprises : les outils de recherche par tag d'OSM
permettent de faire le point de ce qui manque ou serait en trop (et aussi
des outils comme UMap qui peuvent faire cette recherche et l'afficher à la
fois sur une carte et dans un tableau de données, qu'on peut alors exporter
facilement pour le comparer à un autre fichier externe). Qui sait, vous y
trouverez sans doutes des points et données dont vouxd n'aviez pas idée ou
que vous avez oubliés aussi: une petite enqupête de votre côté et vous
pouvez les valider dans vos fichiers et les faire remonter et rapprocher
avec d'autres bases.

Tout ceci participe d'un échange participatif où chaque acteur peut
travailler et contribuer. Au final cela vise à la convergence, mais on
n'aura jamais une convergence absolue, automatique et instantanée (même
pour ds données dites "réglementaires" et supposées à déclaration
obligatoire, car il y a aussi des délais légaux pour le faire et des délais
de rectification) car tout finit par changer un jour et tout le monde ne
sera pas au courant en même temps ni n'aura encore pu vérifier de son côté.
Il est donc important dans toute base de garder un suivi daté des
modifications afin de savoir ce qui a été validé et quand et estimer la
fraicheur relative de ce qui est présent dans une base : cela permet aussi
de planifier et étaler dans le temps les travaux de revérification et
correction sans avoir tout à faire tout de suite et être pris à agir dans
l'urgence (ce qui peut demander un travail énorme et de gros moyens humains
et en temps dont chacun ne dispose pas).



Le ven. 27 nov. 2020 à 12:42, Marc_marc  a écrit :

> Bonjour,
>
> Le 27.11.20 à 10:26, Maïtena HARISTOUY a écrit :
> > Dans le cadre de mon activité professionnelle au sein de l'OT Pays
> > Basque, je fais partie des contributeurs OSM et je me demande s'il est
> > possible d'importer un fichier CSV dans OSM afin de mettre à jour OSM.
>
> les imports suivent une procédure très carré
> 

Re: [OSM-talk-fr] Tag adéquat pour nommer les maisons basques

[Philippe Verdy]

Le ven. 11 déc. 2020 à 23:05, Brice  a écrit :

> Bonsoir,
> Le 07/12/2020 à 10:45, Marc_marc a écrit :
>
> >> 3/ addr:housename
> >
> > c'est souvent erronée.
> > addr: dit que cela concerne l'adressage postal, et non le batiment.
> > dans certains pays, on n'utilise pas de addr:housenumber mais
> > on utilise des noms à la place des addr:housenumber tel que
> > "maison des Edelweiss, rue de la gare"
> > peut-être est-ce utilisé légalement dans certains hameaux,
> > j'en ai pas connaissance.
>
> Je ne comprends pas bien la différence que tu fais entre un nom
> d'adresse et un nom de bâtiment
>
>
> > en tout cas la combinaison addr:housename + addr:housenumber
> > me fait croire à une erreur qu'il faudrait corriger en name
>
> OK je comprends ce critère, si un n° est attribué, alors pas de
> addr:housename
>

Moi je comprends plutôt addr:housename comme une sous-adresse, pour une
désignation privée à l'intérieur d'une même propriété (ou copropriété ) qui
s'est vue attribuer (ou pas encore) un même numéro (sans bis/ter... ni
A/B/...)
On peut en trouver notamment dans les très grandes propriétés (publiques ou
privées) : résidences, campus universitaires, villages vacance : ces
différents batiments sont bien distincts et ont des noms, mais tous groupés
à la même adresse (celle d'une même entité, d'un secrétariat ou accueil
commun).

Dans les campus universitaires il est courant que ces bâtiments n'aient pas
de numéros mais soient nommés. De même dans les domaines "historiques"
(exemple : les pavillons du Château de Versailles) ou les parcs
d'attraction (voyez Disneyland), et aussi dans certains grands centres
commerciaux.

On une situation analogue aussi au cas du nom des voies privées dans les
grands domaines et résidences pour leur cartographie interne : les "voies"
d'accès ou de circulation (y compris les couloirs, escaliers...), comme les
différents points ne sont pas toujours numérotés mais nommés. On a aussi un
exemple dans les grandes gares avec les "hubs" et points de rencontre qui
servent au repérage (et sont fléchés dans la signalétique). Je vois ces
noms de bâtiments au même titre que la désignation des étages, escaliers,
numéros de pièces, de bureau, ou de chambres dans les hôtels, ou les
bungalows et emplacements d'un camping, ou les emplacements de
garages/parkings, les entrepôts : il peut y avoir des numéros mais les
numéros seuls ne facilitent pas le repérage ou le regroupement,
indépendamment de la désignation des voies d'accès et de circulation
internes qui permettent de s'y rendre (mais le long desquels les différents
points ne sont pas nécessairement situés : il peut y avoir plusieurs voies
d'accès différentes selon qu'on est en véhicule ou à pied, les véhicules
étant souvent plus restreints)

Au plan postal, la seule adresse publique (numéro+nom de rue, ou lieu-dit
avec place=isolated_dwelling ou hamlet quand il y a plusieurs propriétés
distinctes, avec leurs propres accès publics partiellement partagés via une
voie privée avec droit de passage) n'est pas toujours suffisante car il y a
besoin aussi de situer les locataires/résidents individuels (personnes
physiques ou morales) indépendamment des propriétés: la carto interne
(d'origine privée et non publique de la part des municipalités) est alors
importante, et la poste ou les services de livraison (qui ont accès à ces
propriétés) en ont besoin, mais aussi les services fiscaux, les notaires,
agences immobilières et gestionnaires de biens (contrats de location,
etc.), ainsi que les exploitants de réseaux (téléphonie, eaux, énergie).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] osm.org Affichage ville selon zoom - Vichy vs Cusset

[Philippe Verdy]

Le ven. 13 nov. 2020 à 18:26, Jérôme Amagat  a
écrit :

> Pas de réaction hostile sur le robot :D
> On pourrait aussi indiquer sur le wiki, que les population=* en France ne
> sont connus qu'au niveau communal et donc que les population=* sur les
> place=* sont les populations des communes dont ce place=* est le chef lieu.
>

Ce n'est pas tout à fait vrai, car il y a des chiffres de population au
niveau des IRIS (ou parfois des TRIRIS quand il sont trop petits, pour
respecter le secret statistique).

Pour les petites communes, elles ne sont pas découpées en IRIS ou sont leur
propre IRIS (mais elles sont parfois regroupées en TRIRIS avec d'autres
pour certaines statistiques sensibles au plan personnel comme la fiscalité,
l'emploi, l'équipement des ménages, quand ces données sont protégées par la
loi Informatique et liberté de 1978, conformément aux directives de la
CNIL: les données par IRIS existent à l'INSEE, mais leur accès est réservé
aux personnels habilités des administrations: le fisc, la justice, les
autorités policières et de contrôle, et certains personnels communaux qui
doivent alimenter et corriger ces données, ainsi que pour permettre un
accès personnel par les personnes concernées dans ces statistiques pour
qu'elles aient un droit personnel d'accès et de rectification).

Pour les communes-associations ou les communes nouvelles, le découpage
continue de préserver au moins un IRIS par commune membre (commune associée
ou commune déléguée) tant qu'elles n'entrent pas en fusion simple. Le
découpage en IRIS est assez stable mais peut évoluer avec le temps pour
conserver certains seuils (au moins à l'échelle des TRIRIS) permettant de
les comparer entre eux (les seuils sont assez stricts maintenant concernant
l'usage des IRIS de population résidente pour le zonage électoral, afin de
préserver raisonnablement l'équité des électeurs, exigée par la
Constitution).

Les TRIRIS sont le plus souvent (pas toujours) des regroupements de trois
IRIS (pas toujours dans la même commune, ou pouvant inclure une petite
commune non découpée avec les IRIS d'une commune voisine découpée en IRIS).
Les données par TRIRIS sont publiques.

Pourquoi trois IRIS le plus souvent dans un TRIRIS ? C'est à cause de
leur typologie qui distingue trois types d'IRIS selon leur usage principal:
résidentiel, agricole, commercial: il peut arriver qu'il n'y ait plus qu'un
seul résident ou forer fiscal dans une zone donnée où existent alors les
deux autres types voisins. Si un IRIS seul a suffisamment de population, il
n'est pas nécessaire de le regrouper avec d'autres IRIS voisins moins
peuplés.

De plus, seules les communes les plus peuplées sont découpées en IRIS: il
reste alors peu de cas où, pour préserver les seuils de secret statistique,
ces IRIS infra-communaux ont besoin d'être regroupés. Et autant que
possible, le regroupement doit préserver la continuité territoriale
(exception faite des iles où la continuité inclue les eaux territoriales ou
adjacentes) et se fait au sein de la même commune (mais ce n'est pas
toujours possible et il faut parfois rattacher le petit IRIS trop peu
peuplé à un IRIS d'une commune voisine ou au seul IRIS d'une petite commune
voisine non découpée (ce n'est pas fait pour les données simples de
population mais pour les données fiscales ou d'emploi: les chiffres de
population communale sont donc toujours calculables comme la somme des
population de ses IRIS; on peut alors avoir dans les communes les plus
peuplées découpées le détail par IRIS ou TRIRIS, mais les IRIS restants non
rattachables à un TRIRIS d'une même commune sont alors seulement totalisés
de façon non nécessairement contigue territorialement dans un pseudo-TRIRIS
indiquant tout ce reste).

Alors que pour les données sensibles (fiscalité, emploi, revenus,
équipement des foyers, sécurité et criminalité, composition des foyers,
statut matrimonial, nationalité...) on les retrouvera dans de véritables
TRIRIS mais ceux-ci seront parfois intercommunaux (ces données ne sont donc
pas disponibles partout à l'échelle des communes car il y a ces TRIRIS qui
débordent un peu sur les communes voisines dont tout ou partie du
territoire a été rattaché à une autre commune contenant l'IRIS le plus
peuplé: ce découpage obtenu pour les données publiques n'est pas donc plus
strictement communal et obéit aux exceptions demandées par la CNIL, alors
que les communes et agences autorisées de l'Etat ont les chiffres exacts
commune par commune, IRIS par IRIS, parfois même à un niveau plus fin foyer
par foyer voir individu par individu, en fonction de leurs habilitations et
de leur réel besoin de ces données précises ou si elles en sont elles-même
la source ou si elles doivent pouvoir fournir un droit d'accès personnel
aux résidents concernés, en suivant une procédure et vérifiant leur
identité et droit à y accéder, avec des personnels qualifiés, formés à ces
procédures et soumis au secret administratif et aux procédures normatives
de sécurité, tous les employés 

Re: [OSM-talk-fr] Attribution manquante pour une AMAP du Doubs et suivi des contributions

[Philippe Verdy]

Je vois bien l'attribution "© CCBYSA © OpenStreetMap contributors"
(également en plein écran) sur
http://amapaneth25.fr/producteurs
dans le coin inférieur droit (même si elle n'est pas très lisible car peu
contrastée et sur fond transparent, mais en glissant la carte on la lit
facilement). Elle est bien liée à
http://www.openstreetmap.org/copyright
En revanche, elle ne s'affiche plus en bas de sa fiche quand on clique sur
un des producteurs affichés.
Les tuiles sont chargées depuis
http://tile.openstreetmap.org/{z}/{x}/{y}.png


Le dim. 22 nov. 2020 à 06:36, Yves P.  a écrit :

> Bonjour,
>
> J'ai rajouté
> 
>  http://amapaneth25.fr et envoyé un message à l'agence web.
>
> Je constate que la colonne date de régularisation est bien vide. Notament
> pour des signalement anciens.
>
> *Au hasard*, http://www.services.eaufrance.fr est une carte sur les
> données ouvertes de l'eau.
> Ce site est estampillé avec un logo de la République française, mais pas
> de prise en compte depuis le septembre 2019 !!
>
> Mondial Relay
> 
>  n'aurait
> pas été contacté, mais l'attribution est mentionnée (mais pas indiquée dans
> le tableau)
>
> Est-ce que quelqu'un peu mettre à jour le tableau ?
> (J'ai en fait 3 pour ma part)
>
> —
> Yves Pratter
>
> ___
> 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] adresses numéros bis, ter ...

[Philippe Verdy]

On évitera l'utilisation des exposants ou indices (avec les caractères de
compatibilité d'Unicode, qui ne forment même pas des séquences complètes ,
même de base comme le "a" et le "o" utilisés en exposants pour des
abréviations latines ou espagnoles, ni suffisantes pour pas mal de
caractères latins).
Ces caractères "latins" ne sont en fait pas destinés à ces présentations
(et dans OSM on ne peut pas mettre d'attributs de style au milieu d'un
champ texte non plus).
Ils ne sont là dans Unicode que pour les langues qui en font un usage
orthographique au plan lexical (et cela ne concerne pas le français qui
n'utilise que des conventions de présentation de style pour les
abréviations ou les appels de notes), et pour compatibilité avec les
anciens codages 8-bits non-Unicode (cas des exposants "a" et "o" ou de la
ligature "No" de l'abréviation de "numéro", où le o en exposant peut
parfois être souligné en plus dans cette ligature).

Le sam. 7 nov. 2020 à 20:12,  a écrit :

> Le 07/11/2020 à 13:15, Romain MEHUT - romain.me...@mailo.com a écrit :
>
> > Et donc sur quelle base le choix de mettre un espace entre le chiffre
> > et le suffixe ?
> > Romain
>
> Comme dit Philippe, une espace (c'est de la typographie, pour la petite
> histoire l'espace était féminine et l'espace est devenue masculin sauf
> en typographie).
>
> Espace ou pas ? Ça se discute.
>
> Simplement je constate que l'usage semble être de coller les A/B/C/D et
> de ne pas coller les bis/ter... Donc quelque part la base est
> pifométrique ;-).
>
> Maintenant certains mettent un numéro et un complément alphanumérique,
> donc deux champs en base de données.
>
> Je n'ai pas de religion, en la matière notamment.
>
> C'est plus un constat qui va dans le même sens que ce que dit Philippe.
>
> Mais je vois aussi des bis et autres ter en exposant à la manière de 1^er .
>
> 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] Changements "anciens" de limites communales

[Philippe Verdy]

Les communes associées sont toujours des communes (au même titre que les
communes déléguées dans les communes nouvelles) même si elles ne sont pas
de plein exercice. Et ont une identité légale, juridique et comptable. La
seule chose vraiment changé c'est la fusion en un conseil municipal unique,
mais pourtant il y a bien une identité réelle, leur code INSEE est toujours
valide, il y a toujours des références dessus sur les identités de
personnes physiques et morales qui y sont enregistrées, et elles ont
conservé leur toponymie propre.
Elles devraient toutes être présentes. Un certain nombre sont dans OSM,
mais il en manque encore (et pourtant on a des tracés précis dans le
cadastre, où on les repère par le découpage zonal, avec les planches codées
pas seulement en lettres mais avec en préfixe les 3 chiffres initiaux
correspondant au code commune (sauf la commune chef-lieu, qui porte le
numéro "000" s'il y en a un, ou alors pas indiqué du tout) pour éviter les
lettrages identiques (certaines communes ont opté pour un relettrage par
exemple en ajoutant une lettre, ou lorsque le zonage des communes membres a
été redécoupé, tout en conservant l'ancienne limite toujours en vigueur,
par exemple pour aménager une zone d'activité ou un nouveau quartier à
lotir).
Ce zonage cadastral fait toujours référence (par exemple dans les actes
notariés): le cadastre a donc des limites précises (autant que les
frontières communales actuelles, sauf qu'elles ont rarement besoin de
conflation manuelle d'une commune à l'autre.
Tant qu'il n'y a pas eu de fusion pleine, le découpage zonal cadastral doit
conserver ces limites dans le plan d'assemblage de la commune.


Le jeu. 19 nov. 2020 à 00:38, Jérôme Amagat  a
écrit :

> En anciennes communes qui ont encore une "existence" aujourd'hui, il y a
> les communes qui sont devenues communes associées mais ça date des années
> 70. Il en manque beaucoup dans OSM.
>
> Le mer. 18 nov. 2020 à 18:48, Christian Quest  a
> écrit :
>
>> Le 18/11/2020 à 18:23, Yann-Vari Gwiader a écrit :
>> > Bonjour,
>> >
>> > Avant les incitations récentes aboutissant au regroupement de
>> > certaines communes en France, les modifications des délimitations
>> > communales ont été des phénomènes courants au XXème siècle. Il
>> > s'agissait souvent de regrouper plusieurs communes en une, ou alors de
>> > démembrer une ou plusieurs communes pour en créer une nouvelle, ou
>> > alors de transferts de bouts de territoires d'une commune à une autre.
>> >
>> > La page suivante du wiki :
>> >
>> https://wiki.openstreetmap.org/wiki/Talk:France/Limites_administratives/Tracer_les_limites_administratives#Anciennes_limites_administratives_.28r.C3.A9gion.2Fd.C3.A9partement.2Farrondissement.2Fcommune.29
>> >
>> > indique : "Il est toujours pertinent de conserver les anciennes
>> > limites (en positionnant disused:boundary sur la relation + en
>> > complétant par end_date la date de fin de vie de la limite, ainsi que
>> > source et source:url pour fournir la référence du changement)".
>> >
>> > J'ai un certain nombre d'exemples en tête concernant des modifications
>> > territoriales de communes qui ont été réalisées dans les années 1950
>> > et pour lesquelles des éléments (décrets + indications portées sur le
>> > cadastre napoléonien) permettent de reconstituer les changements qui
>> > ont eu lieu. Ces éléments ne sont pas, à cette heure, stockés dans
>> > OpenStreetMap pour les exemples que j'ai en tête.
>> >
>> > La question que je me pose est de savoir si le mode opératoire
>> > mentionné sur la page wiki ci-dessus est à jour et complet (dans
>> > l'hypothèse où l'inclusion de telles informations est validée par la
>> > communauté).
>> >
>> > Merci pour vos éclairages,
>> > Yann
>>
>>
>> C'est essentiellement pour les fusions récentes que l'on a conservé les
>> limites, je ne pense pas que pour des changements antérieurs (année 50
>> !) on ait quoi que ce soit dans OSM en France.
>>
>> Ajouter ces infos passerait sûrement mal au niveau de la communauté,
>> assez attaché à cartographier le monde tel qu'il est et pas tel qu'il
>> était il y a 70 ans. On a l'exemple des anciennes voies ferrées ou déjà
>> il y a presque une sorte de tolérance à avoir ces tracés alors qu'il n'y
>> a plus rien de visible sur le terrain.
>>
>> Il faudrait voir si Open Historical Map est encore actif et si ça ne
>> pourrait pas être ajouté là bas.
>>
>> --
>> 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
> 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] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Philippe Verdy]

Note aussi: les magasins ouverts en "clickandcollect" n'obligent pas tous à
commander en ligne: on peut passer commande sur le pas de la porte et
revenir plus tard. Le problème, c'est surtout le paiement (les boutiques en
clickandcollect ou vendeurs "à la roulotte" y compris les foodtrucks, ne
veulent pas mettre leur caisse près de la porte ouverte (même si elle est
barrée par un meuble de service) pour des raisons de sécurité aussi, et ne
peuvent pas non plus ouvrir s'il y a une file d'attente sur la rue (c'est
un gros problème pour la vente de nourriture à emporter, type fastood: en
général on veut manger quand c'est prêt, sans attendre et c'est vite
périmé, donc comment éviter les files d'attente sur le trottoir? Certains
ont des livraisons, comme les pizzas, mais en plus il y a le couvre-feu qui
les oblige à fermer très vite le soir).

La vente à emporter c'est pas évident pour tout le monde.

Au final pour beaucoup les seuls magasins encore accessibles sont les
supermarchés et hypers (avec restriction de l'affluence et
controle/surveillance des entrées devenu obligatoire, par un vigile ou par
certains employés du magasin pour réguler les entrées et répartir les
clients en caisse : si les caisses ont trop de monde à attendre, l'entrée
est refusée, les clients doivent attendre leur tour dehors et entrent au
compte-goutte avec la sortie des autres clients; pour accélérer le flux,
les commerces ont déjà réduit leur offre au delà même des restrictions
gouvernementales, et les espaces de circulation, on ne doit plus "trainer"
dans les rayons et certains limitent les quantités dans les charriots, le
temps dans le magasin est limité, on vous invite alors à prendre
l'essentiel, passer vite aux caisses et revenir plus tard pour le reste; ça
se passe surtout en début de soirée ou le samedi; moins de choix, plus
aucune "promotion", plus de produits "en vrac", plus de produits en lots
importants, moins de marques... Là aussi on vous invite à commander sur
Internet et retirer en "drive" mais ce n'est pas possible pour tout le
monde). Pour les familles nombreuses, ou les personnes éloignées sans
véhicule (avec des transports en commun également très réduits et limités
en capacité et fréquence), faire ses courses est devenu compliqué.


Le lun. 16 nov. 2020 à 16:03, Vincent Bergeot  a
écrit :

> Bonjour,
>
> je reprends ce petit bout de ton mail
> Le 10/11/2020 à 11:52, Pierre-Olivier GREGOIRE a écrit :
>
> *Les tags :*
>
> Maintenant il est vrai que "takeway:covid19" a été utilisé pendant le
> premier confinement pour un mélange des deux concepts : "retrait en
> magasin" et "consommer à emporter". Personnellement je préfererais :
> * Introduire une nouvelle clef "order_and_collect:covid19"
> * il faudra décider ce qu'on fait des anciens tags pour les magasins : en
> tant que consommateur de donnée, toujours interpréter takeaway:covid19
> comme équivalent à "order_and_collect:covid19" quand il ne s'agit pas d'un
> restaurant ou d'un café ou d'un bar peut-être ?
>
> Pour les livraisons je pense qu'on peut rester sur "delivery:covid19" qui
> personnellement ne me pose aucun souci.
>
> pour ma part, favorable à la notion order_and_collect:covid19 -> l'accès
> au magasin est fermé sauf pour venir chercher une commande préalablement
> réalisée. C'est sans doute un des cas les plus fréquents en ce moment.
>
>
>
>
> On pourrait plus tard décliner la différentiation moyen de commande /
> moyen de retrait :
> peut-être :
> "order:covid19" : yes/no/phone/website voir même "order:url"
> "pick-up:covid19" : "in-store"/"drive"
>
>
> peut-être que description:covid19 est suffisant pour préciser ensuite tous
> les cas, plutôt que de trop décliner en des tags différents ?
>
> à vous
>
> --
> Vincent Bergeot
>
> ___
> 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] [OSM-Talk-fr] Nouveaux tags "Ça reste ouvert"

[Philippe Verdy]

Le lun. 9 nov. 2020 à 20:40, Yves P.  a écrit :

> - safety:mask:covid19
> 
> =yes/given/sold pas certain que l'on ai encore besoin de ça. On déprécie ?
>
>
> Poubelle ! je ne comprends même pas comment c'est arrivé dans CRO ;)
>
> - delivery:covid19
> =yes
> 
> fonctionne toujours pour indiquer la possibilité de livraison.
> Par contre j'ai l'impression que cela s'applique à plus de catégories de
> POIs (pas uniquement sur les restaurant mais aussi pour les librairies
> ,
> et potentiellement je pense aussi aux bibliothèques)
>
>
> A tous les commerçants qui le souhaitent (Tiens, ça ne fonctionne pas pour
> les coiffeurs, les ongleries… :D )
>
>
> mais surtout qu'il faut maintenant indiquer le Click and collect.
>
>
> delivery:covid19=yes va bien ?
>

Non car "delivery" indique un service de livraison (à domicile). le
"clickandcollect" c'est la possibilité de retier sur place (la boutique est
fermée à l'exception du pas de porte avec une barrière, on ne peut pas
entrer mais on peut se faire remettre les colis préparés (aux heures
d'ouverture indiquées, éventuellement adaptées avec :"covid19") et
éventuellement payer.

Attention : certains commerces "clickandcollect" ne traitent QUE les
commandes payées en ligne, car il n'y a plus de caisse ni échange de
monnaie). Ceux qui n'ont pas d'internet ou de carte de paiement à distance
ne peuvent PAS aller dans ces commerces (tout le monde n'a pas une carte
"CB", beaucoup n'ont que des cartes de retrait simple d'espèces). Nombre de
commerces n'acceptent pas non plus les paiements mobiles (eux aussi
réservés à certaines catégories de personnes, et pas sur tous les
abonnements mobiles, et il faut un terminal compatible: le commerçant ne
veut pas toucher votre smartphone, pas plus que la monnaie, pour ne pas
risquer de contaminer son propre commerce: ça commence maintenant dans les
bureaux de tabac et marchands de journaux, dont déjà le bar est fermé; il
n'est pas évident de décontaminer des pièces et billets et les manipuler
facilement et sans risque).

Donc il faudrait un autre tag pour le paiement en ligne obligatoire, ou le
paiement sur place en espèces impossible.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adresses numéros bis, ter ...

[Philippe Verdy]

sauf que c'est faux. le B peut signifier la lettre B (après A) ou le bis
(après le numéro sans suffixe). Et dans certains cas, on a les deux types:
12, 12A, 12B, 12C, puis 12 bis...
On ne peut pas dans ce cas abréger les "bis, ter, etc.", qui alors ne
doivent pas non plus être collés au numéro mais avec une espace), et
devraient rester en minuscules (alors que les lettres simples peuvent être
accolées et devrait être en capitales dans OSM).  Noter que la
capitalisation n'est pas signifiante (puisque pour la poste tout est forcé
en capitales), mais dans OSM on devrait garder les distinctions (comme pour
les noms de rues, avec leurs diacritiques et ponctuations), même si pour
l'usage postal on simplifie la graphie (et là on
remplace chaque ponctuation, tiret ou apostrophe, par une espace et il est
même permis de supprimer les diacritiques, et même recommandé, voire
obligatoire pour les envois en grand nombre pour faciliter le tri
automatique et bénéficier des tarifs réduits: les échec de tri automatique
peuvent être refacturés à l'expéditeur par la Poste)

Ceci dit les OCR postaux sont de plus en plus performants (les polices de
caractères et la qualité d'impression aussi, on n'utilise plus
d'imprimantes matricielles, trop lentes pour les envois en nombre), et
l'obligation c'est surtout pour la boite postale ou code de
distribution spéciale, le code postal, la ville, le pays, et le nom de rue;
les premières lignes d'adresse avec le nom exact du destinataire ou du
service et les précisions locales sont moins concernées car c'est lu par
des humains et ne nécessite pas le tri automatique)


Le ven. 6 nov. 2020 à 14:06, Yves P.  a écrit :

> A nouveau pour mémoire
> https://www.mail-archive.com/talk-fr@openstreetmap.org/msg97921.html ;)
>
> Merci :)
>
> J'ai commis ça :
> https://wiki.openstreetmap.org/wiki/FR:Adresses#Normalisation_du_suffixe_des_n.C2.B0_de_rue.5B1.5
>
> __
> Yves
> ___
> 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] Comment indiquer une séparation centrale sur une rue ?

[Philippe Verdy]

Ca dépend: normalement il n'y a pas de franchissement si on va dans la
direction de la voie, mais certains véhicules ont le droit de franchir pour
une arrêt de livraison ou pour une intervention de sécurité, ou pour entrer
dans un garage. Ils ne peuvent pas le faire à vitesse normale, mais en
vitesse au pas c'est possible... Cela agit donc bien comme un
ranlentisseur non pas dans le sens de la voie mais pour le franchissement
de voie.

Ceci dit j'aurais quand même tendance à tracer des voies séparées car ces
franchissements ne sont pas pour la circulation normale mais pour un arrêt:
l'emplacement de ce franchissement n'est pas bien défini, et c'est pour
ça qu'il faut indiquer que c'est franchissable (de la même façon qu'un
ralentisseur) avec un "kerb" ou quelque chose de plus doux encore (ce n'est
pas un traffic island qui est, lui, infranchissable, sauf par les piétons)

Mais "kerb" peut aussi bien désigner une bordure de trottoir, pas très
pratique mais pourtant couramment présent dans les zones où il est permis
de stationner en partie sur le trottoir). Comment qualifier mieux ces
"kerb" franchissables en vitesse très lente (au pas) ? Et doit-on alors
créer une connexion d'une voie à l'autre (et en quel point faire ce
franchissement? ou juste indiquer une largeur correspondant à l'écart entre
les deux voies "connectées" par cette séparation franchissable, ou un
polygone englobant la zone de franchissement possible contenant le "kerb" ?)

Sur la photo mapillary, on voit aussi que le "kerb" est discontinu et avec
des pentes douces, visiblement faits pour ne pas gêner trop le
franchissement par les deux-roues., mais dessiner un à un ces espaces
intercalaires me semble un peu ardu, il est plus simple alors de taguer le
kerb avec un truc du genre "barrier:bike=no" ou "access:bike=yes" (sans
exclure de tracer en plus le polygone "area=yes" englobant le "kerb",
continu ou pas, et les voies traversables de chaque côté).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Retour de Ça Reste Ouvert — Re: projet du mois de novembre ? Et projet du mois de décembre

[Philippe Verdy]

Le click and collect se généralisé à presque tous les commerces de
proximité à Niort, qui pour la plupart sont fermés au public, juste un
guichet de retrait à la porte. Plus moyen de voir ce qu'on achète et les
prix s'envolent avec une réduction drastique du choix.

C'est triste une ville plus morte qu'un dimanche...

Le ven. 6 nov. 2020 à 11:16, Christian Quest  a
écrit :

> C'est celui que j'utilise car le click-and-collect correspond à la vente à
> emporter par opposition à la livraison.
>
> Je complète autant que possible avec phone/email/website.
>
> Su ma petite carte, les POI de ce type sont désormais en orange quand on
> zoome, et les infos sont indiquées.
>
>
> Le 06/11/2020 à 10:31, Yves P. a écrit :
>
> Les petits commerçants se mettent au "click and collect".
> Un articles des Inrocks à ce sujet : Voici une carte interactive
> des librairies proposant le service “click and collect”
> 
> (avec une carte Google)
>
> Je ne sais pas si le tag takeaway:covid19
>  est adapté pour
> ça.
>
> Et je pense que *CRO manque* vraiment car il était *fédérateur*, et
> l'affichage des POI par CRO et leur filtrage étaient adaptés :)
>
> __
> Yves
>
>
>
> --
> Ce message a été vérifié par *MailScanner* 
> pour des virus ou des polluriels et rien de
> suspect n'a été trouvé.
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois Décembre : lieux de test COVID (était "Carte des lieux de test COVID")

[Philippe Verdy]

Et franchement, ce genre de localisation aurait su être intégrée à l'appli
STOPCOVID v2 (déjà que la v1 a été un flop, d'autant plus que Google l'a
bloquée sur Android pour nombre d'utilisateurs qui ne la trouvait pas...
parce que Google a voulu référencer juste des applis se conformant à son
API propriétaire et hébergeant les pubs de Google, il a rendu la v1
invisible même quand on la cherchait... OK maintenant la v2 est affichée et
enfin proposée).

Mais cette appli ne fait pas grand chose de plus, sauf l'ajout de
l'attestation de sortie virtuelle (génération d'un PDF à télécharger dans
le smartphone, contenant le formulaire rempli et signé électroniquement
mais surtout lisible par un QR-code en cas de controle). Mais là encore
j'ai du y renoncer: si on l'active le téléphone se décharge totalement en
moins d'1 heure, ou parfois se met à surchauffer et se décharge en quelques
minutes, cette appli a un gros bog et reste encore inutilisable et il ne
faut surtout pas compter sur elle pour vous fournir une attestation de
sortie exploitable, vous vous prendrez une prune de 135  euros ou des
poursuites si vous ne pouvez pas justifier votre déplacement parce que
votre téléphone s'est déchargé à cause justement de cette appli (qu'il faut
donc maintenir arrêtée et donc ne sert à rien). En revanche on peut
l'utiliser juste le temps de générer le PDF et le télécharger (sans activer
la détection, c'est elle qui ne marche pas).

On s'attendrait à avoir une appli plus utile, même sans la détection de
proximité et donnant des infos réellement utiles, et au moins un portail
web permettant de trouver et naviguer vers toutes les infos nécessaires,
sans avoir à compter sur ce que propose Google qui nous renvoie vers des
sites américains ou britanniques et des actus non sourcées sur la situation
en France mais publiées dans les médias anglophones. Mais là encore Google
privilégie les sites bourrés de traqueurs (non conformes RGPD pour la
plupart, certains ont des centaines de sociétés qui suivent sans qu'on
puisse s'y opposer, car l'option "tout refuser" est un leurre: regarder le
détail, elles ont toutes ajouté des clauses nouvelles "d'intérêt légitime"
qu'on n'a plus le droit de refuser).

Pour une appli mobile pour un sujet de santé publique et qui aussi doit
informer sur la santé de chacun, il est inadmissible que ces publicitaires
et autres collecteurs de big data en profitent pour cibler selon l'état de
santé ou le risque de chacun. Les abus se multiplient (et le RGBD pour ces
sociétés, même européennes, elles n'en ont "RAF!"). On a donc un besoin
urgent de données libres, et de moyens libres et mieux protégés d'y
accéder. La covid est malheureusement devenu l'opportunité pour surveiller
le monde entier à distance et partout, dans toutes les activités.

La covid est considérablement accru la surveillance, et combiné avec les
nombreuses restrictions de libertés publiques, même constitutionnelles, on
a aujourd'hui une vrai dictature orwélienne mondiale, mais toujours aussi
peu efficace à éviter l'emballement de la pandémie, l'explosion de la
pauvreté, celle des profits astronomiques de quelques puissants qui
s'enrichissent encore plus vite qu'avant (et redonnent si peu à la
communauté).

Il est grand temps de commencer à militer très activement pour la scission
forcée des nouveaux monopoles de fait, et les nationalisations forcées
(sans compensation) de ces grands groupes pour redistribuer ce qu'ils ont
abusé et fournir des moyens enfin efficaces pour lutter contre la maladie
et restaurer les équilibres sociaux qu'ils ont massivement compromis.
Egalement pour les forcer à fournir leurs données ou rendre leurs collecte
totalement illégale (et leur faire payer des milliards pour ces abus
répétés et maintenant à très grande échelle, contre les libertés publiques
partout dans le monde).

Mais la situation dans les applis mobiles est désormais totalement
intolérable. Apple et Google doivent être démantelés, leurs pratiques
commerciales, leurs contrats imposés, leurs prélèvements abusifs, l'absence
de concurrence sérieuse, fait qu'ils ne croissent que de façon totalement
parasitaire sans ajouter aucun service réel pour la communauté: on doit
forcer Google et Apple à supprimer ses restrictions propriétaires sur
Google Maps, et qu'il publie tout sous licence libre (quitte ensuite à
travailler avec OSM, mais pour équilibrer ajouter aussi des collaborations
avec les autres puissances publiques et régulateurs). De plus Apple et
Google doivent scinder non seulement leurs activités, mais aussi toutes les
filiales pays par pays pour les exposer directement à une législation
applicable (il n'est pas possible qu'ils continuent à utiliser les parades
d'externalisation pour échapper à leurs obligations, et ensuite faire mine
d'aider le monde en fournissant juste quelques infos via des portails
monétisés qui leur rapportent encore plus).

Et je suis excédé des pratiques abusives de toutes les alliances
publicitaires (dont Google et Apple 

Re: [OSM-talk-fr] Règle Osmose pour tag brand:wikipedia

[Philippe Verdy]

Sauf que NSI spécialise ses conseils par pays (le code pays est bien
visible dans ses filtres)
Donc le bogue est plutôt dans Osmose (pas dans NSI), qui oublie de chercher
avec le filtre pays approprié au lieu, **avant** d'aller faire un repli
vers les attributs internationaux.

De toute façon les tags wikipedia sont dépréciés et inutiles si on a un tag
wikidata (où on trouvera les liens des diverses éditions de wikipedia,
sahcnat aussi que les codes "langue" de wikipedia ne sont pas vraiment des
codes langue (au sens de BCP47) mais des alias locaux propre au système de
codes interwiki.

Wikimedia peut avoir des codes différents, non standards, persistant
uniquement parce que ce sont des labels de noms de sous-domaines ou des
codes internes de noms de base de données dont tout le monde se fout, ou
fusionnés là où BCP47 est bien plus strict et plus précis sur les règles de
repli et les codes valides: mais c'est très long (ça fait des années que ça
dure comme des bogues signalés mais dont la correction est sans cesse
repoussée) pour qui Wikimedia fasse les correction nécessaires (à la limite
le plus facile a juste été de créer des "alias" sur les noms de domaines
(CNAME ou redirections) en deux temps (d'abord du code standard vers
l'ancien code, puis dans le sens inverse), ensuite il faut des années pour
mettre à jour les nombreux modèles ou modules, réviser des données
d'internationalisation au sein même de Mediawiki ou de son installation
locale, informer les communautés, tester, tester encore, vérifier que le
renommage peut aussi être fait dans translatewiki.net, que les outils
d'export/import de TWN vers MediaWiki puis de déploiement dans Wikipedia ou
les autres projets fonctionnent avec les nouveaux codes, puis prévoir la
transition des noms de domaine canoniques, vérifier que les redirections
fonctionnent, puis enfin la mettre en oeuvre, patienter des mois pour que
les sites web externes (notamment les moteurs de recherche) se mettent à
jour, puis commencer à prévoir le démantèlement du support par redirection
de l'ancien code (s'il est en conflit avec un autre usage nécessaire),
nettoyer Wikidata... La dernière phase (qui nécessite un arrêt du wiki) est
le renommage de la base de données, qui elle aussi se fait en plusieurs
étapes.
Renommer un wiki de Wikimedia n'est pas simple du tout (même pour les
petits wikis) !

Du côté d'OSM c'est plus simple: éviter de référencer wikipedia et mettre
wikidata à la place et laisser Wikidata gérer ces liens sur sa base.

Donc pour les "brands" cela n'a plus d'importance et on élimine des tas de
redondances pas utiles dans OSM qui nécessitent des constantes corrections
(surtout en plus que Wikipedia n'est pas forcément précis: chaque édition
peut décider ou non de fusionner plusieurs sujets dans un même article,
avec plusieurs sections, et Wikidata ne sait pas encore gérer correctement
les liens vers les sections d'article pour la désambiguisation et les
fusions ou scissions faites dans une édition linguistique de Wikipédia ne
sont pas pertinentes pour les autres, ni non plus pour d'autres projets
liés comme Commons ou Wikivoyage.

Si vous avez des problèmes avec des liens Wikipédia (comme ceux qui
persistent à changer l'édition linguistique "pertinente" sans tenir compte
de la langue locale appropriée, qui est aussi en elle-même un sujet de
conflit dans les régions multilingues comme la Catalogne ou le Pays basque
en Espagne, ou encore la Corse, ou les langues co-officielles en Belgique,
en Suisse ou au Canada) et ne trouvez pas d'élément Wikidata associé à un
article pertinent, le lieux est de créer cet élément Wikidata manquant, le
lier correctement à l'article Wikipédia le plus approprié et éventuellement
chercher dans d'autres éditions ou d'autre projets comme Commons,
Wikivoyage, Wikinews (voire le Wiktionnaire pour certains toponymes
connus). Et ensuite éliminer tous les tags wikipedia et les remplacer par
un tag wikidata unique vers l'élément Wikidata que vous avez créé.



Le sam. 24 oct. 2020 à 22:17,  a écrit :

> Bonjour, les suggestions d'Osmose sont des suggestions.
>
> Ici le suggestion-index est une belle c... : wikidata est neutre.
>
> Le "bon" article Wikipédia est usuellement celui du pays où est la filiale.
>
> Je remets régulièrement des fr:Système U alors que iD suggère de
> modifier en en:Système U.
>
> C'est crétin : c'est une entreprise française exerçant en France.
> L'article en anglais est évidemment plus pauvre.
>
> Donc la bonne page c'est par défaut la page dans la langue par défaut du
> pays.
>
> Jean-Yvon
>
> Le 24/10/2020 à 21:55, Romain MEHUT - romain.me...@mailo.com a écrit :
> > Bonsoir,
> >
> > Dans ce changeset https://www.openstreetmap.org/changeset/92924630
> > j'ai demandé pourquoi la valeur au tag brand:wikipedia n'était pas la
> > déclinaison française. La réponse est que c'est une suggestion d'Osmose.
> >
> > Ne priorise-t-on pas la valeur fr (s'agissant du territoire français
> > bien sûr) ?
> >
> > Merci pour vos 

Re: [OSM-talk-fr] Nouveau rendu osm.fr

[Philippe Verdy]

Personnellement je suis plus en faveur du rendu bitmap des surfaces
colorées de fond (avec un dégradé progressivement plus pâle pour les
faibles niveaux de zoom afin de masquer un peu mieux les détails locaux):
une seul rendu pour tout le fond en fait, sans aucun palissement, le
palissement est fait par un "alpha blending selon le niveau de zoom, du
coup une seule couche bitmap à calculer pour tout et la possibilité alors
de recalculer dynamiquement et facilement les niveaux de zoom plus faible.
C'est bien plus efficace et bien plus joli visuellement et plus rapide pour
tout le monde, le remplissage de polygones complexes est une opération très
couteuse en CPU qui marchera assez mal pour les mobiles si on veut
préserver leur autonomie).

On peut aussi faire une composition alpha-blending pour le rendu en
l'ombrage de la topographie d'altitude (mais pas pour les lignes d'iso)

En revanche ça ne marche mal pour les éléments linéaires (l'épaisseur des
traits doit changer, et on doit masquer plus de choses en dézoomant sinon
on superpose trop de choses), et pas du tout pour les éléments icônes et
textes posées encore par dessus : ces deux parties sont destinés à un rendu
vectoriel, y compris les lignes d'iso de topographie d'altitude).

Et pour les textes, bien séparer les textes localisables afin d'avoir une
sélection possible de la langue et un basculement facile: ce sera la couche
supérieure au dessus de la couche vectorielle des traits et des icônes (les
icônes sont aussi en format vectoriel afin de pouvoir tenir compte de la
résolution réelle pour les écrans HiDPI, mais elles ne posent pas de
problème car leur rendu bitmap pour la composition est facilement mise en
cache local pour économiser de la ressource locale de rendu, de la même
façon que se fait *déjà* le rendu bitmap des polices de textes dans tous
les moteurs de rendu de texte, ce ne sera donc pas répétitif et coûteux en
batterie.

La composition (blending) des couches est une opération de base de toutes
les cartes graphiques modernes (y compris tous les appareils mobiles) et
sinon c'est très optimisé au niveau de l'OS ou du navigateur pour un rendu
CPU (pour bureaux ou serveurs qui de toute façon sont aujourd'hui bien plus
rapides et pas trop limités en capacité de batterie), mais elle demande un
peu plus de mémoire: ce n'est aujourd'hui un problème que pour les
appareils mobiles très bon marchés ou anciens avec un vieil OS, ou un
affichage assez basique (mais ils sont aussi des tailles d'écran et
résolutions plus limitées, avec aussi une moins grande profondeur binaire
des couches colorimétriques, et c'est ce qui limite en pratique la mémoire
nécessaire).






Le sam. 24 oct. 2020 à 19:21, Yves P.  a écrit :

> Concernant les rendus spécialisés, François avait démarré une version
> vectorielle du rendu CyclOSM (limité aux infrastructures uniquement),
> cf. https://2metz.fr/blog/cyclosm-vector-tiles/.
>
>
>
> Pourrait-on capitaliser dessus ?
>
>
> Je viens de voir un rendu vélo Polonais
>  (bitmap).
>
> En modifiant seulement le style, il doit être possible de réutiliser les
> tuiles CyclOSM vectorielles.
>
> __
> Yves
> ___
> 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] OSMF 2020 entre inquiétude et déception

[Philippe Verdy]

Le risque me semble bien plus élevé pour la Fondation OSM que pour la
Fondation Mozilla, qui n'a pas à supporter les mêmes frais
d'infrastructure, et a un nombre de soutiens bien plus élevés, aussi bien
au plan financier mondialement, que par le fait que les suites Firefox sont
souvent les seules aussi installées sur les serveurs et stations de travail
Linux, notamment les environnement de bureau virtualisés hébergés dans les
clouds des entreprises, qui donc acceptent aussi de maintenir une
contribution leur apportant aussi un support direct ou via un prestataire.
La Fondation OSM en revanche non seulement a des frais d'infra importants,
mais aussi se met à dépenser sans compter, en croyant que le tapis sur
lequel elle est encore confortablement installé pourra se reconstituer
aussi vite qu'il est dépensé. Il a fallu moins d'un an pour anéantir les
efforts des 10 ans.
Et pourtant la Fondation OSM ne finance pas un projet important pour elle:
la consolidation de son infrastructure pour bâtir un vrai CDN, et sinon
consolider la base de données. Elle en fait trop sur les éditeurs, et tente
maintenant d'opacifier ses prises de décisions et même ses justifications.
elle renforce le rôle dominant ed certains personnes dont la neutralité est
de moins en moins évidente.


Le sam. 24 oct. 2020 à 10:37, Jean-Marc Liotier  a écrit :

> Le "Is responsible for allocating $$ to diverse worthwhile software
> projects with grants and microgrants" de
> https://wiki.osmfoundation.org/wiki/Mission_Statement me gène également
> beaucoup. Je vois la Fondation comme arbitre de conflits et garant
> ultime de la license - or on sent le glissement vers ce qui pourrait
> finir par ressembler à la Mozilla Foundation - une course en avant dans
> toutes les directions en même temps plutôt que la dalle stable sur
> laquelle repose tout le reste.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois défibrillateurs : un grand merci à tous !

[Philippe Verdy]

Je propose de compléter la localisation des assos humanitaires et
caritatives, et aider à les classer; beaucoup sont difficile à trouver, il
en manque, et les tags sont à revoir car c'est la dispersion la plus
complète.

On devrait avoir une liste des grandes assos : Restos du cœur, Anneau de
l'Espoir, Médecins du Monde, Croix Rouge, Secours populaire, Banques
alimentaires, et les plus petites (ainsi que les éventuels points d'aide
des municipalités.

Autour de moi j'ai cartographié certains services qui manquaient. Mais je
suis sûr que c'est très incomplet.

A cartographier aussi les magasins qui acceptent les bons alimentaires :
ils sont peu nombreux, très peu de volontaires (par exemple pas chez LIDL,
ni la plupart des centres Leclerc, et presque aucun hypermarché), et les
rares qui les acceptent ne sont pourtant pas les moins cher (souvent des
épiceries de quartier appartenant à des grands groupes de distribution:
Carrefour Market, Cocci,, où les prix sont souvent abusifs pour un usage
quotidien).

On peut inclure dedans les AMAP, les jardins collectifs. Aussi les
restaurateurs ou commerçants volontaires qui préparent des colis d'invendus
(tous ne sont pas collectés par les grandes assos, faute de moyen ou de
quantité suffisante pour les tournées). Et aussi les restaurants rapides et
sandwicheries dont certains adhèrent à un programme de distribution
gratuite plutôt que jeter (ce que la loi leur interdit théoriquement quand
ils sont encore consommables comme les produits surgelés non encore
préparés, ou les produits frais préparés emballés comme les salades, ou les
produits secs comme la viennoiserie, ou les sandwiches invendus du jour,
qui pourraient être distribués après l'heure habituelle des repas)

Les municipalités ou aides sociales fournissent des bons de type "chèque"
qui ne sont pourtant pas utilisables partout (ce qui est scandaleux, tous
les magasins devraient les accepter comme toute forme de paiement légal,
d'autant plus qu'ils sont tirés de comptes publics, mais les émetteurs de
ces chèques sont des banques privées qui demandent des frais d'encaissement
élevés alors que leurs montants sont totalement garantis, au contraire des
cartes bancaires et chèques particuliers qui peuvent revenir impayés; ces
chèques sont beaucoup moins acceptés que les tickets restaurants, pourtant
émis souvent par les mêmes banques ou des filiales bancaires de grands
groupes de la restauration comme Sodexho) et ont une durée de validité très
limitée. Les trop rares magasins qui les acceptent sont très éloignés,
seulement dans certains quartiers, ce qui ne les rend pas facilement
accessible à tous à cause des distances, difficultés ou temps de transport
(compliqué aussi par le couvre-feu qui limite les horaires et leur
couverture territoriale réelle de service, pour ceux qui n'ont pas de moyen
de transport autonome ou ont des difficultés avec la marche).

Tout autour de moi je vois des gens qui ont réellement très faim et n'ont
plus rien depuis des mois (et il n'y a presque plus de distribution de
proximité). La covid a fait ses morts, bientôt on, devra compter aussi ceux
qui meurent chez eux de faim en France et qui n'ont plus pratiquement plus
accès aux services de base qui ne vient plus les voir.

Certains sur Internet n'y croient pas du tout car ils vivent dans des zones
où ces services sont relativement accessibles (mais ce sont les mêmes qui
n'en ont pas besoin et qui prétendent au "yaka" sur des bases théoriques;
l'Etat a fait des tas de promesses publiques mais les oubliés sont un peu
partout en France qui ne peuvent pas accéder aux services qui restent, et
les assos elles-mêmes ont été obligé de se limiter, car elles n'ont plus
d'accès direct au public, sans rendez-vous et listes d'attente, au mieux
elles ne peuvent aujourd'hui fournir qu'un colis pour 2-3 jours tous les 15
jours; pour ceux qui sont en zones rurales ou périurbaines c'est pire, il
n'y a plus rien, même plus les transports, avec en plus les contraintes
horaires)

Note: le couvre-feu s'étend, les services de base de proximité sont encore
plus indispensables que jamais (les hypermarchés sont désormais trop loin
pour beaucoup et il n'y a aucune livraison à prix abordable pour ceux qui
ont moins de 10 euros par jour pour manger, parfois beaucoup moins, et ils
plus nombreux que jamais ; même les distributeurs bancaires ferment dans
les zones rurales, et tout le monde n'a pas non plus une carte de paiement
CB, juste une carte de retrait utilisable dans le seul réseau d'une seule
banque, et pas plus accès au commerce sur Internet).

Si vous visitez les supermarchés, regardez autour de vous aux caisses
comment beaucoup comptent les pièces une par une, et voyez ceux qui sont
obligé de renoncer à une partie de leurs courses (pourtant visiblement pas
grand chose et que des produits essentiels) car ils n'ont pas assez
d'argent sur eux. Dans ce public, des mères de familles seules qui
renoncent à leur propre repas et n'achètent que pour leurs enfants, 

Re: [OSM-talk-fr] OSMF 2020 entre inquiétude et déception

[Philippe Verdy]

En gros tu te poses des questions sur la viabilité de la fondation et sa
façon nouvelle de dépenser sans compter à une vitesse record, pour des
projets qui ne sont pas dans sa mission première (qui est de protéger les
actifs communautaires et maintenir le fonctionnement des serveurs et régler
les questions de politique communautaire ou légales, et non de payer des
développeurs externes qui peuvent déjà disposer de budgets ou faire appel à
des ressources locales et communautaires dans un projet ouvert).
C'est une analyse intéressante, car effectivement cela met à mal
l'indépendance ou la survie de la fondation qui se place en situation de
dépendance vis-à-vis de ces tiers et s'engage dans des frais de maintenance
élevés (où les ressources actuelles ne permettraient pas de suivre le
rythme, ou condamnerait rapidement le projet à réduire sa "voilure" ou
alors concéder des droits importants à des fournisseurs tiers de faire ce
qu'ils veulent; et c'est vrai que la menace est réelle d'une prise de
contrôle par des intervenants plus riches (comme Mapbox, et indirectement
ensuite par de gros acteurs qui voudraient contrôler Mapbox et changer
ensuite la politique de licence). Il naît alors un déséquilibre croissant
entre la communauté (et les chapitres membres qui sont sensés pouvoir aider
en tant qu'intermédiaires locaux plus accessibles) et ces gros acteurs
décidés de façon opaque dans des réunions "privées" où ce qui se décide
n'est plus en accord avec les missions affichées et la volonté des
précurseurs qui ont décidé de "jeter l'éponge".
C'est là une question où la Fondation devrait accorder un plus grand rôle
aux chapitres locaux (avec un droit de regard complet et permanent sur
l'état des finances et des dépenses) et ne pas s'engager dans la pente
dangereuse des décisions opaques, notamment en matière d'engagements
financiers auprès de fournisseurs tiers.

Le jeu. 22 oct. 2020 à 22:04, severin.menard via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Bonjour,
>
> Pour info, pour celles et ceux qui ne seraient pas membres de l'OSMF, j'ai
> publié cet article sur sa liste de discussion :
> https://lists.openstreetmap.org/pipermail/osmf-talk/2020-October/007294.html
> et également sur mon journal OSM :
> https://www.openstreetmap.org/user/SeverinGeo/diary
>
> Les retours (positifs ou négatifs) sont toujours bienvenus.
>
> Séverin
> ___
> 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] panneaux de signalisation touristique en bord de route et autoroute

[Philippe Verdy]

Juste un truc qui m'énerve un peu sur ce lien: la notification "Too many
requests" qui s'affiche de façon répétée (toutes les 5 secondes), et
immédiatement. Trop de requêtes de qui ? A cause de ce message, il y aurait
trop de monde sur mapcontrib? Y a-t-il moyen de faire taire cette
notification (quitte à juste afficher un statut) ou la ralentir ? Je ne
vois pas l'intérêt de réafficher cette notif sans arrêt.
Je ne sais pas où sont réglés les "quotas" de requête, est-ce lié à cette
carte spécifique des signalisations? Est-ce lié au fait qu'on déborde de la
zone montrée (et qu'en dehors cela prend trop de temps à calculer)?
Note: cela n'affecte pas le rendu des tuiles, juste la recherche des
panneaux avec ce filtre. Mapcontrib ne semble pas "aimer" du tout.

Le jeu. 22 oct. 2020 à 12:17, Zimmy ZIMMERMANN 
a écrit :

> Merci pour vos retours. Voici donc le lien vers une visualisation
> valorisant les objets ayant des photos (Mapillary) ou non.
>
> https://www.mapcontrib.xyz/t/0eddb6-Signalisation_danimation_culturelle_et_touristique_CD84#position/11/44.2116924/4.7236645
>
> Je suis preneurs d'idées et d'astuces (je n'arrive pas à renommer le
> thème).
>
> Le mer. 21 oct. 2020 à 20:50,  a écrit :
>
>> ÀMHA, ça complète et non remplace les attributs proposés par Adrien.
>>
>> Ceux-ci permettent à une carte mondiale de fonctionner et ceux d'Adrien
>> à une carte spécialisée d'avoir un fonctionnement optimal.
>>
>> Jean-Yvon
>>
>> Le 21/10/2020 à 17:23, Jean-Claude Repetto via Talk-fr -
>> talk-fr@openstreetmap.org 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Attribution sur water-map.org/

[Philippe Verdy]

Vous pouvez au moins tenir compte de la taille d'affichage de la carte pour
savoir si un petit (i) suffit ou si une attribution normale peut tenir sans
problème.
Cela ne bloque pas ce que va afficher le panneau qui s'ouvre quand on
clique dessus qui peut tout à fait mentionner Mapbox comme fournisseur,
mais ne doit pas oublier de mentionner OSM comme source première (la plus
visible dans tout ça, indépendamment du travail de rendu fait par Mapbox
(ou du travail de qualification et de supervision par Mapbox des données
soumises par leurs utilsiateurs ou les vôtres).
D'ailleurs votre site n'est pas destiné directement à faire de vos
visiteurs des utiliateurs de Mapbox, ce sont avant tout des utilisateurs de
votre appli, et Mapbox n'est qu'un prestataire que vous avez choisi en
privé.

Vous ne demandez pas à vos utilisateurs je pense de se créer un compte et
d'identifer chez Mapbox mais chez OSM: ils sont donc des utilisateurs d'OSM
d'abord avant d'être des utiliqateurs indirects de Mapbox du fait de votre
choix, et même si en tête ce sont d'abord vos utilisateurs que vous voulez
suivre. De fait OSM devrait être placé en tête 'juste en dessous de
vous pour les services spécifiques que vous proposez, et ensuite Mapbox ne
posera aucune problème. A vous donc de revoir ce que va afficher le petit
(i) quand on clique dessous, ou la mention complète normale (si sous avez
la place dans votre interface).

La même chose vaut pour d'autres sites, comme Facebook qui eux aussi
affichent des "minicartes" (non navigables) avec un petit (i) qui peut se
justifier vu la taille et le peu d'informations affichées. Facebook
n'utilise pas qu'OSM d'ailleurs, pour certains services il renvoie chez
Here (est-ce toujours chez Nokia/Microsoft? alors que Microsoft a développé
et déployé une autre solution basée sur Bing et n'a gardé encore qu'une
division sur les smartphones en pleine déconfiture face aux géants coréens,
chinois et Apple).



Le mar. 13 oct. 2020 à 18:39, Water-Map  a écrit :

> Salut Christian,
>
>
>
> Nous tenons énormément à notre collaboration avec OpenStreetMap et nous
> sommes conscients que notre projet n'existerait pas sans ce monde open et
> collaboratif.
>
>
>
> Nous avons parlé d'OpenStreetMap aux Nations Unies, à l'UIT et dans notre
> article dans le Parisien, pas par obligation mais parce que c'est un projet
> auquel nous voulons contribuer et faire vivre.
>
>
>
> Notre app est mobile first, mais sur ordinateur j'ai aucun problème
> d'exploser le "i" sur desktop. Je vais me renseigner à partir du mois de
> novembre.
>
>
>
> Et pour les textes, comme j'ai écrit à Yves, je mettrais avec plaisir un
> peu plus en avance OpenStreetMap.
>
>
>
> Bien à toi,
>
>
>
> Stuart
>
>
>
> PS : Je viens de proposer le thème d'eau potable (fontaines + cafés
> refill) sur Talk GB pour Q2 21. S'ils l'acceptent comme projet, est-ce que
> OSM FR pourrait considérer ce même thème pour un projet du mois ?
>
> On Tue, 13 Oct 2020 at 18:04, Christian Quest 
> wrote:
>
>> Le 13/10/2020 à 17:38, Water-Map a écrit :
>> > Bonjour Christian,
>> >
>> > Je ne m'excuse pas.
>> >
>> > Notre site respecte les règles d'attributions de mon point de vue.
>> >
>> > OpenStreetMap est open data où pas ?
>> >
>> > Bien à toi,
>> >
>> > Stuart
>> >
>>
>> J'ai été trop grognon... désolé.
>>
>> Quand je parle d'excuse, je ne vise personne, même moi je pourrai
>> chercher ce qui peut expliquer, excuser ce qui me semble être un manque.
>>
>> Pour le respect des règles d'attribution, ok, d'un point de vue purement
>> juridique ça peut passer mais est-ce sur ce plan là qu'on doit agir l'un
>> envers l'autre ? Je ne pense pas.
>>
>> Ce que j'ai tenté (très maladroitement) de faire comprendre, c'est que
>> nos projets collaboratifs croisés doivent s'entraider et se valoriser
>> l'un l'autre.
>>
>> L'attribution aujourd'hui ne met pas du tout en valeur OSM, entre le
>> problème du "i" à la Mapbox et le about minimaliste.
>>
>> Avec ce niveau d'attribution et donc de reconnaissance envers les
>> contributeurs OSM et bien je n'ai pas plus envie que ça de promouvoir
>> water-map alors que comme d'autres ici je trouve l'idée très bonne.
>>
>>
>> Quant à la notion d'opendata... il y a un mix entre droits (de
>> réutilisation) et devoirs (attribution, partage à l'identique). Je ne
>> détaille pas plus sur la notion d'opendata qui pour moi est en général
>> équivalente à l'opensource (et unidirectionnel) vs le logiciel libre (et
>> collaboratif), mais on n'a pas de terme pour les données "libres" (à
>> part "données libres"). OSM c'est de la donnée libre et collaborative
>> plus que de l'opendata.
>>
>> --
>> 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
> https://lists.openstreetmap.org/listinfo/talk-fr
>

Re: [OSM-talk-fr] SPAM, Attribution manquante sur Inforoute

[Philippe Verdy]

Je ne peux pas. A cause d'un contributeur politique américain (personnel
diplomatique) qui fait des modifs orientées dans un pays dictatorial.

Le sam. 17 oct. 2020 à 17:25,  a écrit :

> Philippe, merci de commencer à créer la page wiki, les scripts de
> création de VM etc...
>
> Jean-Yvon
>
> Le 16/10/2020 à 23:29, Philippe Verdy - ver...@gmail.com a écrit :
> > Dommage qu'il n'utilisent pas un proxy cache pour les tuiles, c'est
> > directement les tuiles d'OSM.org.
> >
> > C'est vraiment si compliqué d'installer un proxy cache (quitte à
> > restreindre la zone navigable et/ou le niveau de zoom nécessaire pour
> > les infos à afficher dessus, pour que cela ne prenne pas beaucoup de
> > ressources réseau pour les mises à jour du cache du proxy, ni beaucoup
> > d'espace de stockage)?
>
>
> ___
> 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] Nominatim et plan d'eau

[Philippe Verdy]

été
> réellement développé mais laissé en vrac dans une classe fourre-tout
> (pseudo-admin_level=15) en attendant un développement sérieux.
> Tant que ces objets restent assimilable à un noeud et qu'ils sont
> réellement inclus dans une relation admin_level ou assez proche à un
> highway indexés pour les rendre "routables" (Nominatim n'indexe pas tous
> les highways, seulement ceux ayant un nom ou un numéro de référence) il va
> retourner n'importe quoi, c'est le hasard le plus complet en terme de
> classification, il n'y a strictement rien qui soit alors réellement
> pertinent.
>
> Personellement je pense qu'une première amélioration de Nominatim serait
> qu'il vire les noeuds "place" synthétiques pour les objets qui ne sont pas
> des noeuds (objets linéraires et surfaces polygonales/multi-polygonales),
> et qu'il les remplace au moins par des bounding box, afin de rendre les
> calculs de pertinence bien meilleurs. Et il devrait le faire au moins pour
> tous les objets actuellement classés en pseudo-admin_level=15. et sans
> doute aussi (après tests pour éveluer les effets de bords dans la
> détermination des adresses) pour les highways (quoique pour eux il vaudrait
> sans doute mieux qu'il indexe les deux extrémités, à moins que ce soit un
> chemin fermé ou que ce soit un "polyligne" formant des branches ou un
> réseau dans une relation assimilable alors à une surface approximée par la
> boundingbox)
>
> Le sam. 17 oct. 2020 à 15:56, Sarah Hoffmann  a écrit :
>
>> Bonjour,
>>
>> apropos la question pourquoi un lac s'attache a une rue et prends
>> son adresse. C'est justement quelque chose qu'il faut revoir et
>> probablement reviser. L'attachement aux rues marche bien pour les
>> petits POIs comme boite aux lettres ou des supermarches. Ca marche
>> meme bien pour un petit pont de village mais ce n'est pas une bonne
>> idee pour les grandes lacs ou baies.
>>
>> Quand a toutes les autres speculations, j'ai vraiment pas envie de
>> les discuter parce qu'ils sont exactement ca: speculations qui ont
>> rien du tout a voir avec comment Nominatim fonctionne.
>>
>> Sarah
>>
>> On Sat, Oct 17, 2020 at 01:00:36PM +0200, Philippe Verdy wrote:
>> > Tu ne réponds pas à la question ni au cas évoqué autour de
>> > l'Île-Saint-Denis.
>> >
>> > En effet strictement rien n'associe ce polygone à la route en tant
>> > "qu'adresse". C'est stupide comme association surtout pour ce type
>> > d'élément. De plus c'est Nominatim qui en interne a généré un "place
>> node"
>> > (avec un ID interne) sur le polygone (il n'y a aucun node dans le
>> polygone).
>> >
>> > En créant ce "place node", c'est là qu'il a cherché stupidement à lui
>> > donner une adresse et à chercher une route proche. Et c'est là que
>> > l'approximation commence à jouer et d'ailleurs tu n'expliques pas plus
>> > pourquoi il trouve la relation associée à un lieu-dit ou hameau encore
>> plus
>> > éloigné dans la commune voisine, alors qu'il y a d'autres lieu-dits bien
>> > plus proches et que cela n'a strictement rien à voir non plus avec la
>> route
>> > départementale trouvée dans les environs du noeud.
>> >
>> > Franchement c'est là que se joue l'approximation: le noeud interne
>> "place"
>> > ajouté ne représente pas correctement le plan d'eau, on pourrait
>> toujours
>> > tenter d'ajouter un noeud "label" dans la relation OSM je suis presque
>> > certain que Nominatim n'en tiendra pas compte. Pas même si on
>> sélectionne
>> > ce noeud label sur la frontière intercommunale elle-même (ce qui ne sera
>> > pas suffisant pour des relations à cheval sur plus d'une seule
>> frontière).
>> >
>> > Et comment fait Nominatim pour même chercher une "adresse" (un highway)
>> > sinon en procédant là aussi visiblement à une approximation ne tenant
>> pas
>> > compte de la géométrie réelle mais juste des bounding box (comme on le
>> voit
>> > dans l'exemple trouvé aussi autour de l'Isle-Saint-Denis, où des objets
>> > situés dans une concavité de l'île mais dans la commune à l'ouest de
>> l'île
>> > ne sont trouvés que dans la commune à l'est de l'ile car ils sont dans
>> une
>> > concavité encore plus grande.
>> >
>> > Ce sont bien les concavités frontalières qui causent problème ici:
>> l'algo
>> > de recherche d'association de noeuds aux adresses "proches" est
>> > carrément faux dans ce cas, et encore plus quand ce noeud créé
&

Re: [OSM-talk-fr] Nominatim et plan d'eau

[Philippe Verdy]

En fait Nominatim traite les éléments naturels quels que soit leur taille
comme des noeuds et leur attribue un admin_level=15 (totalement
synthétique) pour classer les résultats. Il les considère plus petits que
les noms de batiments (house_name) auxquels il veut les attacher
pouyr attribuer une adresse et sinon il cherche un highway.
Ces éléments naturels sont donc classés n'importe comment.

Et je ne spécule pas du tout sur le fait qu'il crée bel et bien des noeuds
"place" artificiels, avec un id interne puisque c'est bien ce qu'il affiche
dans ses résultats. Et peu importe si cela ne correspond à rien et que
l'attribut synthétique admin_level ne correspond lui aussi à rien du tout.
La logique est totalement fausse qui conduit à les "rattacher" à d'autres
objets très éloignés et arbitraires qui n'incluient pourtant même pas du
tout ces noeuds synthétiques.

C'est une très grossière approximation de Nominatim: on ne peut pas réduire
ces objets à un simple noeud et Nominatim ne sait pas leur attacher
plutôt une bounding box pour avoir quelquechose de plus pertinent. Il se
base juste sur une mesure de distance entre deux noeuds (dont le noeud
artificiel et un autre noeud arbitraire d'un highway ou d'un vraie relation
boundary).

C'est très bancale. C'est un gros manque sur quelquechose qu'i n'a pas été
réellement développé mais laissé en vrac dans une classe fourre-tout
(pseudo-admin_level=15) en attendant un développement sérieux.
Tant que ces objets restent assimilable à un noeud et qu'ils sont
réellement inclus dans une relation admin_level ou assez proche à un
highway indexés pour les rendre "routables" (Nominatim n'indexe pas tous
les highways, seulement ceux ayant un nom ou un numéro de référence) il va
retourner n'importe quoi, c'est le hasard le plus complet en terme de
classification, il n'y a strictement rien qui soit alors réellement
pertinent.

Personellement je pense qu'une première amélioration de Nominatim serait
qu'il vire les noeuds "place" synthétiques pour les objets qui ne sont pas
des noeuds (objets linéraires et surfaces polygonales/multi-polygonales),
et qu'il les remplace au moins par des bounding box, afin de rendre les
calculs de pertinence bien meilleurs. Et il devrait le faire au moins pour
tous les objets actuellement classés en pseudo-admin_level=15. et sans
doute aussi (après tests pour éveluer les effets de bords dans la
détermination des adresses) pour les highways (quoique pour eux il vaudrait
sans doute mieux qu'il indexe les deux extrémités, à moins que ce soit un
chemin fermé ou que ce soit un "polyligne" formant des branches ou un
réseau dans une relation assimilable alors à une surface approximée par la
boundingbox)

Le sam. 17 oct. 2020 à 15:56, Sarah Hoffmann  a écrit :

> Bonjour,
>
> apropos la question pourquoi un lac s'attache a une rue et prends
> son adresse. C'est justement quelque chose qu'il faut revoir et
> probablement reviser. L'attachement aux rues marche bien pour les
> petits POIs comme boite aux lettres ou des supermarches. Ca marche
> meme bien pour un petit pont de village mais ce n'est pas une bonne
> idee pour les grandes lacs ou baies.
>
> Quand a toutes les autres speculations, j'ai vraiment pas envie de
> les discuter parce qu'ils sont exactement ca: speculations qui ont
> rien du tout a voir avec comment Nominatim fonctionne.
>
> Sarah
>
> On Sat, Oct 17, 2020 at 01:00:36PM +0200, Philippe Verdy wrote:
> > Tu ne réponds pas à la question ni au cas évoqué autour de
> > l'Île-Saint-Denis.
> >
> > En effet strictement rien n'associe ce polygone à la route en tant
> > "qu'adresse". C'est stupide comme association surtout pour ce type
> > d'élément. De plus c'est Nominatim qui en interne a généré un "place
> node"
> > (avec un ID interne) sur le polygone (il n'y a aucun node dans le
> polygone).
> >
> > En créant ce "place node", c'est là qu'il a cherché stupidement à lui
> > donner une adresse et à chercher une route proche. Et c'est là que
> > l'approximation commence à jouer et d'ailleurs tu n'expliques pas plus
> > pourquoi il trouve la relation associée à un lieu-dit ou hameau encore
> plus
> > éloigné dans la commune voisine, alors qu'il y a d'autres lieu-dits bien
> > plus proches et que cela n'a strictement rien à voir non plus avec la
> route
> > départementale trouvée dans les environs du noeud.
> >
> > Franchement c'est là que se joue l'approximation: le noeud interne
> "place"
> > ajouté ne représente pas correctement le plan d'eau, on pourrait toujours
> > tenter d'ajouter un noeud "label" dans la relation OSM je suis presque
> > certain que Nominatim n'en tiendra pas compte. Pas même si on sélectionne
> > ce noeud label sur la frontière interco

Re: [OSM-talk-fr] Nominatim et plan d'eau

[Philippe Verdy]

Et d'ailleurs ça se voit concernant son analyse de "pertinence": il retient
la départementale comme "pertinente" car il a déterminé la distance comme
étant nulle, ce qui est ici totalement faux; les distances calculées sont
fausses, même pour le noeud "place" ajouté artificiellement (il y a aussi
un autre noeud "place" artificiel pour la départementale).

C'est carrément stupide, les objets ne peuvent pas être valament
représentés par un seul noeud (comme décrit sur
https://nominatim.org/release-docs/develop/api/Output/#place_id-is-not-a-persistent-id),
il en faudrait au moins 2 pour calculer une pertinence non pas sur la seule
distance de point à point, mais en tenant compte des surfaces
d'intersection des rectangles et sinon en prenant la distance minimale
d'écart entre ces rectangles (20 cas possibles de placement relatif quand
il n'y a aucune intersection entre 2 rectangles dont 21 façons de calculer
cette distance minimale) comme un critère de valeur négative.

Et même avec cette modif, on va avoir des cas tordus dans les concavités
frontalières ou les méandres du linéaire des rues/routes pour rechercher
une adresse pertinente, et c'et là qu'il faut une notation seondaire pour
mieux trier les listes d'objets ou revoir les seuils de filtrage en amont

Cependant ce que tu suggères est que pour cet étang, il suffirait de nommer
la petite route qui la borde et vient du sud-ouest.

Mais tu n'explique pas du tout pourquoi ce n'est pas suffisant dans le cas
du Quai d'Asnières à côté de l'île-Saint-Denis, un cas qui nécessite de
tenir compte de la géométrie réelle et pas d'une simple approximation à un
seul noeud artificiel ni même à une bounding-box car on n'ira pas non plus
ajouter un nouveau nom qui existe déjà et n'a pas besoin d'être ajouté
artificiellement dans la base de données en tant que pseudo-nom (on a déjà
eu les "pseudo-noeuds" avec les membres de rôle "label" dans les relations,
des noeuds que Nominatim n'utilise plus du tout, ni non plus la plupart des
moteurs de rendus. Nominatim n'utilise pas non plus les noeuds
"admin_centre" alors qu'ils seraient encore utiles pour affiner la note de
pertinence au delà du seul noeud (ou de la seule bounding box) et éviter un
filtrage trop précoce des listes d'objets candidats avant le croisement de
ces listes (cela lui permettrait la plupart du temps de continuer à
travailler en une seule passe).







Le sam. 17 oct. 2020 à 13:00, Philippe Verdy  a écrit :

> Tu ne réponds pas à la question ni au cas évoqué autour de
> l'Île-Saint-Denis.
>
> En effet strictement rien n'associe ce polygone à la route en tant
> "qu'adresse". C'est stupide comme association surtout pour ce type
> d'élément. De plus c'est Nominatim qui en interne a généré un "place node"
> (avec un ID interne) sur le polygone (il n'y a aucun node dans le polygone).
>
> En créant ce "place node", c'est là qu'il a cherché stupidement à lui
> donner une adresse et à chercher une route proche. Et c'est là que
> l'approximation commence à jouer et d'ailleurs tu n'expliques pas plus
> pourquoi il trouve la relation associée à un lieu-dit ou hameau encore plus
> éloigné dans la commune voisine, alors qu'il y a d'autres lieu-dits bien
> plus proches et que cela n'a strictement rien à voir non plus avec la route
> départementale trouvée dans les environs du noeud.
>
> Franchement c'est là que se joue l'approximation: le noeud interne "place"
> ajouté ne représente pas correctement le plan d'eau, on pourrait toujours
> tenter d'ajouter un noeud "label" dans la relation OSM je suis presque
> certain que Nominatim n'en tiendra pas compte. Pas même si on sélectionne
> ce noeud label sur la frontière intercommunale elle-même (ce qui ne sera
> pas suffisant pour des relations à cheval sur plus d'une seule frontière).
>
> Et comment fait Nominatim pour même chercher une "adresse" (un highway)
> sinon en procédant là aussi visiblement à une approximation ne tenant pas
> compte de la géométrie réelle mais juste des bounding box (comme on le voit
> dans l'exemple trouvé aussi autour de l'Isle-Saint-Denis, où des objets
> situés dans une concavité de l'île mais dans la commune à l'ouest de l'île
> ne sont trouvés que dans la commune à l'est de l'ile car ils sont dans une
> concavité encore plus grande.
>
> Ce sont bien les concavités frontalières qui causent problème ici: l'algo
> de recherche d'association de noeuds aux adresses "proches" est
> carrément faux dans ce cas, et encore plus quand ce noeud créé
> artificiellement ne peut pas luis seul représenter la surface d'un
> (multi-)polygone.
>
> Le mode "debug" ici ne répond pas du tout à ce que fait Nominatim, il
> donne juste un aperçu sur la façon dont un objet isolé a été indexé (sur
> qu

Re: [OSM-talk-fr] Nominatim et plan d'eau

[Philippe Verdy]

Tu ne réponds pas à la question ni au cas évoqué autour de
l'Île-Saint-Denis.

En effet strictement rien n'associe ce polygone à la route en tant
"qu'adresse". C'est stupide comme association surtout pour ce type
d'élément. De plus c'est Nominatim qui en interne a généré un "place node"
(avec un ID interne) sur le polygone (il n'y a aucun node dans le polygone).

En créant ce "place node", c'est là qu'il a cherché stupidement à lui
donner une adresse et à chercher une route proche. Et c'est là que
l'approximation commence à jouer et d'ailleurs tu n'expliques pas plus
pourquoi il trouve la relation associée à un lieu-dit ou hameau encore plus
éloigné dans la commune voisine, alors qu'il y a d'autres lieu-dits bien
plus proches et que cela n'a strictement rien à voir non plus avec la route
départementale trouvée dans les environs du noeud.

Franchement c'est là que se joue l'approximation: le noeud interne "place"
ajouté ne représente pas correctement le plan d'eau, on pourrait toujours
tenter d'ajouter un noeud "label" dans la relation OSM je suis presque
certain que Nominatim n'en tiendra pas compte. Pas même si on sélectionne
ce noeud label sur la frontière intercommunale elle-même (ce qui ne sera
pas suffisant pour des relations à cheval sur plus d'une seule frontière).

Et comment fait Nominatim pour même chercher une "adresse" (un highway)
sinon en procédant là aussi visiblement à une approximation ne tenant pas
compte de la géométrie réelle mais juste des bounding box (comme on le voit
dans l'exemple trouvé aussi autour de l'Isle-Saint-Denis, où des objets
situés dans une concavité de l'île mais dans la commune à l'ouest de l'île
ne sont trouvés que dans la commune à l'est de l'ile car ils sont dans une
concavité encore plus grande.

Ce sont bien les concavités frontalières qui causent problème ici: l'algo
de recherche d'association de noeuds aux adresses "proches" est
carrément faux dans ce cas, et encore plus quand ce noeud créé
artificiellement ne peut pas luis seul représenter la surface d'un
(multi-)polygone.

Le mode "debug" ici ne répond pas du tout à ce que fait Nominatim, il donne
juste un aperçu sur la façon dont un objet isolé a été indexé (sur quels
champs "utiles") mais pas du tout comment cet index sera ensuite utilisdé
dans une recherche, notamment pour découper une chaine unique en éléments
"pertinents", créer des listes d'objets indexés candidats,
éliminer sauvagement des objets dans ces listes en ne retenant que les plus
"probables" avant de calculer des intersections pour "accélérer" le calcul
d'intersections de ces listes (note: il y a différentes façon de
découper/simplifier la chaine de recherche, plus elle est longues et plus
le nombre de possibilités croit exponentiellement, Nominatim doit faire des
simplifications pour réduire le nombre de possibilités à croiser, et il
simplifie aussi le traitement des géométries pendant le croisement des
listes d'objets en tronquant ces listes avec des critères de "pertinence"
non basés sur la géométrie réelle mais ici on  voit que c'est même pire
puisqu'il se contente juste d'une géométrie réduite à un seul noeud
artificiel, et au final, il peut se retrouver avec une liste totalement
vide, ou sinon une liste n'ayant plus assez de candidats, ou un seul qui
n'est plus du tout pertinent et qu'il ne vérifie finalement même pas à la
fin pour voir si la géométrie correspond.

Quand Nominatim ne trouve pas d'objets ou n'en retrouve pas assez, il ne
sait pas réduire lui-même ses critères de pertinence (pour ne pas filtrer
aussi sauvement ses listes d'objets à croiser avant de faire l'assemblage
et le croisement sur les éléments assemblés de la chaine de recherche). Il
n'utilise pas du tout la géométrie réelle, pour lui tout objet indexé est
réduit à un noeud unique, qui peut être arbitraire, et c'est même pire que
s'il avait réduit la géométrie non pas à un seul noeud mais à une
bounding-box (deux noeuds sur une diagonale). Et même à la fin quand il
obtient une liste de résultats filtrés, il ne charge pas la géométrie
réelle des objets pour vérifier la pertinence réelle.

Nominatim ne travaille qu'en une seule passe (zéro ou un seul objet, pour
lui c'est suffisant!) et ne sait pas reprendre son filtrage en réduisant
ses seuils de pertinence avant les croisements, afin d'obtenir des listes
d'objets suffisamment peuplées (pas trop) avant de classer par pertinence
en tenant compte de la géométrie réelle (ce qui peut être couteux et lent
puisqu'il lui faudrait charger la géométrie complète ces objets, là
j'admets qu'il doit limiter la longueur de ces listes).


Le sam. 17 oct. 2020 à 12:18, Sarah Hoffmann  a écrit :

> On Sat, Oct 17, 2020 at 07:15:22AM +0200, Philippe Verdy wrote:
> > Si tu enlèves "Saibnt-Jean-de-Braye", Nominatim le trouve.
> >
> > Sans doute parce que le plan d'eau est à ch

Re: [OSM-talk-fr] Nominatim et plan d'eau

[Philippe Verdy]

Si tu enlèves "Saibnt-Jean-de-Braye", Nominatim le trouve.

Sans doute parce que le plan d'eau est à cheval sur deux communes, et l'est
indexé que sur une seule, sans doute le centroïde.

Mais si tu cherches sur l'autre commune, Nominatim ne le trouve pas non
plus:

https://www.openstreetmap.org/search?query=%C3%89tang%20du%20Ruet%2C%20Marigny-les-Usages#map=17/47.94215/2.00436

Donc une solution possible serait de couper le multipolygone en deux
parties, une pour chaque commune

Les multipolygones "naturels" pouvant être très grands, il semble que
Nominatim ait fait un choix bancal de ne pas les indexer avec ce nom quand
il est ambigu, et ne sait pas quoi retirer de la requête.

Pourtant en cherchant un peu:

https://www.openstreetmap.org/search?query=%C3%89tang%20du%20Ruet%2C%20Les%20%C3%89poisses#map=17/47.94220/2.00266

Là il trouve, mais au nom d'un hameau proche qui ne fait partie d'aucune
des deux communes mais d'une troisième limitrophe des deux autres,
Boigny-sur-Byonne, bien qu'elle ne couvre aucune partie du multipolygone du
plan d'eau. Bizarre malgré tout car le point géolocalisé pour centrer la
vue est bien au centre du plan d'eau et pas du tout à  Boigny-sur-Byonne.

Je me demande donc si l'indexation par Nominatim ne se contente pas
d'indexer les multipolygones uniquement sur leur bounding-box, peut-être
élargie ou arrondie avec une zone tampon (arrondi les limites du "quad"
contenant tout l'objet), et qu'ensuite il n'indexe qu'un seul des sommets
de ce rectangle, au lieu du centre de ce rectangle ou du son centroïde
qu'il ne sait pas ou ne veut pas calculer sur un multipolygone pouvant
contenir des dizaines de milliers de noeuds pour les plus grands

Ou alors il fait pareil pour indexer les communes selon aussi leur bounding
box (sans ajouter de zone tampon d'arrondi autour), et il va alors juste
chercher alors une commune en intersection (avec la bounding box du plan
d'eau) mais où cette intersection est la plus grande: cela ne demande pas
beaucoup de calcul de géométrie.

Si une des deux hypothèses est vraie, alors Nominatim a bien des problèmes
à trouver correctement les objets à cheval sur plusieurs communes, et
proches d'une autre.

Un test est à faire sur une chemin à cheval sur deux communes dans une zone
incluse dans la concavité d'une autre. Et là je pense à une commune très
concave comme l'Île-Saint-Denis, où pourraient avoir été indexés à tord des
objets faisant en fait partie de Villeneuve-la-Garenne: Quai d'Asnières,
L'Île-Saint-Denis

Là non plus Nominatim ne trouve rien, mais avec:

Quai d'Asnières, Saint-Denis

Là il trouve alors que la commune de Saint-Denis est plus éloignée encore
de Villeneuve-la-Garenne.

Cela semble confirmer une grossière approximation par Nominatim basée sur
les bounding-box uniquement !


Le jeu. 15 oct. 2020 à 09:57, Cyrille37 OSM via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Hello,
>
> Nominatim ne trouve pas "Étang du Ruet, Saint-Jean-de-Braye" alors qu'il
> existe bien:
>
>
> https://www.openstreetmap.org/search?query=%C3%89tang%20du%20Ruet%2C%20Saint-Jean-de-Braye#map=17/47.94215/2.00436
>
> Est-ce à cause du natural=water (plan d'eau) ou qu'il s'agit d'une
> relation multi-polygone ?
>
> Merci de vos lumières :-)
> Cyrille37
>
>
> ___
> 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] SPAM, Attribution manquante sur Inforoute

[Philippe Verdy]

Dommage qu'il n'utilisent pas un proxy cache pour les tuiles, c'est
directement les tuiles d'OSM.org.

C'est vraiment si compliqué d'installer un proxy cache (quitte à
restreindre la zone navigable et/ou le niveau de zoom nécessaire pour les
infos à afficher dessus, pour que cela ne prenne pas beaucoup de ressources
réseau pour les mises à jour du cache du proxy, ni beaucoup d'espace de
stockage)?

Pourquoi OSM n'a pas une page d'aide pour expliquer comment installer un
proxy cache local sur des configs connues (sur un serveur LAMP par exemple
ou un hébergement Amazon, Azure, ou autre clouds fréquents, que ce soit sur
un serveur Linux, Windows, voire FreeBSD). C'est d'autant plus facile qu'un
tel cache peut s'installer sur un serveur Linux dans une machine virtuelle
préinstallée et autonome avec très peu de réglages à faire (juste un nom de
domaine, quelques règles de parefeu et de routage, et la capacité de
stockage). Il ne reste plus qu'à remplacer l'URL du serveur de tuiles par
celle du proxy.

Je pense qu'une telle machine virtuelle prête à démarrer devrait être
proposée par OSM.org, une image ISO dans un système Linux bien supporté
comme Ubuntu ou CentOS qui passe partout, avec juste le petit assitant à la
première connexion, ou bien un petit script à lancer qui va créer la VM et
l'installer sur une config cloud ou dans un container comme Docker).

Au passage, la fondation OSM.org devrait même proposer de participer au CDN
des tuiles, pour augmenter sa capacité (avec quelques outils pour autoriser
la maintenance du CDN et sa sécurité, ou l'audit de performance, en
utilisant une inscription à un compte identifié et un engagement
similaire aux "Contributor Terms"; avec cette inscription, le proxy aurait
un nom de sous-domaine spécifique pour le cloud, séparé du nom de domaine
utilisé par l'application déployée par le site, et il serait possible à
tout moment à un participant au CDN d'ajuster le niveau de contribution
comme la bande passante ou la charge CPU ou la fréquence des
requêtes autorisées, ou de se retirer temporairement ou définitivement en
informant le gestionnaire du CDN). Le CDN disposerait encore grade aux
outils d'audit s'il est approprié ou pas d'utiliser cette ressource (qui
pourrait ne pas servir en permanence mais juste pour aider à résorber des
pics de charge ou un besoin temporaire quand un gros serveur d'OSM.org doit
passer en maintenance ou n'est plus accessible depuis certains réseaux ou
pays). Cette image devrait aussi offrir des statistiques d'usage pour le
site qui s'est inscrit. Comme ça tout le monde est content.

Demander à contribuer au rendu devrait en revanche utiliser une ressource
plus solide, mais ça doit aussi être possible dans une image prête à
déployer pour peu que les ressources nécessaires soient présentes (l'outil
d'installation vérifiera ce qui manque et pourrait proposer des réglages
préférables pour plus de sécurité ou de performance, ou un meilleur
pilotage de la charge. Cependant l'engagement est plus compliqué car là on
doit éviter la production d'images malveillantes ou "spammées".

Pour servir les tuiles préfabriquées c'est plus simple: il suffit que les
images des tuiles contiennent une signature numérique prouvant leur
origine et l'absence d'altération (par une erreur technique ou une
malveillance), et c'est facilement auditable. On peut très bien le faire et
vérifier très efficacement et rapidement l'authenticité de ces tuiles sur
un réseau P2P comme le DHT (déjà utilisé pour les torrents et d'autres
réseaux distribués de type Cademlia: la bande passante du flux DHT est
minime même pour les torrents populaires, ce réseau est aussi efficace
voire plus que le DNS, et même plus sécurisé que le DNS de base!).







Le ven. 16 oct. 2020 à 12:45, Arnaud Champollion <
arnaud.champoll...@linux-alpes.org> a écrit :

> Ça y est, la mention a finalement été ajoutée :
>
> http://www.inforoute04.fr/
>
> 
>
> Bonne journée
>
>
> Le 14/08/2020 à 19:07, Arnaud Champollion a écrit :
> > Réponse du Conseil Départemental - ils font suivre au prestataire
> > Inforoute.
> >
> > À suivre 樂 ...
> >
> >
> >
> > Le 10/08/2020 à 10:04, Arnaud Champollion a écrit :
> >> Bonjour,
> >>
> >> Inforoute avait déjà été contacté en janvier, mais toujours aucune
> >> évolution.
> >>
> >> J'ai relancé http://www.inforoute04.fr/  via le formulaire présent sur
> >> le site du Département, en leur suggérant de s'inspirer du modèle
> >> d'attribution de inforoute.hautes-alpes.f, et mis à jour la page du
> Wiki.
> >>
> >> Bonne journée,
> >>
> >> Arnaud
> >>
> >>
> >>
> >>
> >> ___
> >> Talk-fr mailing list
> >> Talk-fr@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> 

Re: [OSM-talk-fr] Besoin d'aide pour référence d'un ligne TGV

[Philippe Verdy]

Pour le tuning de la vm Java notamment le garbage collector, il faut
regarder pour chaque version. D'une façon générale je t'invite à activer la
console Java qui ouvre une fenêtre supplémentaire et pour t'assurer que tu
as effectivement la mémoire demandée. J'ai eu une surprise récemment en
voyant qu'un 0arametre avait changé et au lieu des 4Go j'étais restreint à
2.5Go par une autre restriction. Tu peux aussi paramétrer la priorité et le
temps du garbage collector incremental, paramétrer aussi les cycles de vie
entre générations ou quand le garbage collector doit "finaliser" les
objets, car s'ils ne le sont pas ils doivent rester en mémoire jusqu'à ce
qu'une passe plus agressive vienne les finaliser pour que le garbage
collector puisse les libérer. Il existe aussi des packages Java qui
viennent remplacer l'allocateur, pour mettre en œuvre la compression, ou
une autre stratégie que le LRU pour les caches (LRU pose un sérieux
problème de sécurité sur les serveurs, résolu par une stratégie de type
"ARC" avec une dise de randomisation, mais le LRU simple est beaucoup trop
présent dans tous les OS et toutes les applications). Ceci dit ce problème
LRU ne concerne pas JOSM puisque c'est toi seul qui le Contrôle). Mais un
allocateur avec compression peut aider, et ARC peut considérablement
améliorer les performances des caches.

Attention aussi dans JOSM à ne pas laisser trop de couches ortho. Même
cachées en arrière plan elles travaillent avec des tonnes de requêtes
internet.
Si tu fais un traitement compliqué, essaye en supprimant tous les calques
de fond de carte sauf un masqué éventuellement. Attention aussi aux
greffons (notemment celui du cadastre français qui est très bogué et
gaspille énormément de mémoire car très mal optimisé...) et certains
greffons "sociaux" qui discutent aussi en permanence.

Le mar. 13 oct. 2020 à 07:10, Gad Jo  a écrit :

> Merci Philippe pour les explications mais même en augmentant à 4 go je
> n'ai pas obtenu de résultat.
>
> Comme tu a l'air de t'y connaître, peut tu faire un essais en
> sélectionnant tous les éléments de la relations pour trouver la longueur
> cumulée des segments ?
> Peut être qu'il faut affiner la configuration java ou josm ? Si tu peut
> faire un essai et nous en dire plus sur ta tentative de trouver la longueur
> total de la voie ferrée. Ce serait top.
>
> Cordialement
>
> Le October 13, 2020 12:31:43 AM UTC, Philippe Verdy  a
> écrit :
>>
>> 2Go est parfois très juste si on travaille à l'échelle de la France.
>> Perso j'ai mis une limite de VM à 4Go (dans le panneau de config Java;
>> aucun problème car Java ne sert qu'à des applis locales et pas dans un
>> navigateur, donc toujours lancé par une ligne de commande "java" ou un
>> fichier .jnlp lancé via JavaWebStart, qui télécharge ou met à jour l'appli
>> dans le cache local de déploiement, puis lance l'appli de façon autonome;
>> JavaWebStart est mal nommé, en fait il n'a de web que le lancement et le
>> fait qu'un fichier .jnlp est un tout petit fichier qui contient une ou
>> plusieurs URLs pour la mise à jour du cache, et les autres paramètres de
>> config de la VM qui pourraient être imposés, ainsi que les bibliothèques
>> binaires nécessaires qui devraient être dans les "/lib" et les packages
>> dépendants qui peuvent être eux aussi installés dans le CLASSPATH).
>> Par défaut, même en 64 bits, la limite ne dépasse pas 2,5Go.
>> Note qu'avec JavaWebStart on n'installe l'appli JOSM que temporairement
>> dans le cache de déploiement, certains outils "nettoyeurs" veulent vider ce
>> cache, mais on perd des infos comme les préférences utilisateur qui sont
>> aussi dans ce cache, qui agit plutôt comme un container. En revanche cela
>> ne nettoie pas le cache JOSM des tuiles qui est stocké à part dans le
>> système de fichiers local de l'utilisateur et qui peut devenir très grand;
>> mais heureusement pour limiter la fragmentation de nomlbreux fichiers,
>> maintenant JOSM gère son cache de tuile avec un gros fichier "blob" unique
>> par couche, ce qui va beaucoup plus vite, mais ce gros bloc peut aussi se
>> fragmenter dans sa structure interne, bien qu'il est plus efficace que ce
>> que fait le système de fichiers lui-même, et il y staocke les tuiles et les
>> métadonnées HTTPS de façon plus ordonnée et plus compacte en ne gardant que
>> les métadonnées utiles et pas tout le "bazar" des entêtes MIME d'HTTP ou
>> HTTPS.
>>
>> Le lun. 12 oct. 2020 à 16:56, Percherie OnDaNet <
>> perche...@toutenkamion.net> a écrit :
>>
>>> Étrange... je suis sur une machine windows avec 2Go de défini pour Java.
>>>
>>> Voici la capture écran de ce qui ne fonctionne pas (avec info bul

Re: [OSM-talk-fr] JOSM version stable 17084 : Correction des fuites de mémoire

[Philippe Verdy]

Ca se règle dans les paramètres de la VM: la garbage collector ne tourne
pas aussi souvent que tu le crois, on peut lui demander de tourner plus
souvent. En 64 bits il peut travailler de façon incrémentale, et en
multithreading. Avec les bons paramètres, la mémoire utilisée redescend.
De plus tu peux lancer JOSM en activant la console, et tu as le moyen de
lancer le garbage collector à la main pour le forcer à faire un
cycle complet de finalisation et de libération. L'empreinte mémoire vu du
côté de l'OS ne signale pas de fuite évidente. Si je supprime tous les
calques, j'ai bien la mémoire qui revient alors à la taille initiale après
chargement, aussi bien vu de Java que depuis l'OS. Pas tout à fait
complètement car il y a des classes actives disposant d'un peu de cache,
qui n'utilise pas encore les "weak pointers" pour se purger totalement.

Le mar. 13 oct. 2020 à 09:44, Yves P.  a écrit :

>
>- #19789 , #19793
> - Correction des fuites
>de mémoire
>
> JOSM est souvent très lent sur ma machine car la mémoire virtuelle est
> "pleine". De temps en temps, la bécane plante complètement.
>
>
> Il a pas mal planté malgré la mise à jour.
>
> Du coup j'ai lancé le moniteur d'activité pour surveiller l'utilisation
> mémoire.
>
> Au démarrage JOSM occupe 1.05 Go sur ma machine.
>
> Ce matin après 1 bonne journée d'utilisation je sauve mes dernières
> éditions et supprime tous les calques sauf cadastre, OpenStreetMap Carto
> (Standard) et BDOrtho IGN.
> La consommation mémoire est de 2.19 Go
>
> Je supprime tous les calques : toujours 2.19 Go
>
> Fermeture de JOSM et redémarrage : 1.05 Go
> Ajout des calques :
>
>- BDOrtho IGN : 1.11 Go
>- Ajout de OpenStreetMap Carto (Standard) : 1.15 Go
>- Cadastre : 1.18 Go
>
> Je zoom, déplace l'écran… la consommation mémoire passe progressivement à
> 2.40 Go !!
> __
> Yves
>
>
>
> ___
> 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] Besoin d'aide pour référence d'un ligne TGV

[Philippe Verdy]

2Go est parfois très juste si on travaille à l'échelle de la France. Perso
j'ai mis une limite de VM à 4Go (dans le panneau de config Java; aucun
problème car Java ne sert qu'à des applis locales et pas dans un
navigateur, donc toujours lancé par une ligne de commande "java" ou un
fichier .jnlp lancé via JavaWebStart, qui télécharge ou met à jour l'appli
dans le cache local de déploiement, puis lance l'appli de façon autonome;
JavaWebStart est mal nommé, en fait il n'a de web que le lancement et le
fait qu'un fichier .jnlp est un tout petit fichier qui contient une ou
plusieurs URLs pour la mise à jour du cache, et les autres paramètres de
config de la VM qui pourraient être imposés, ainsi que les bibliothèques
binaires nécessaires qui devraient être dans les "/lib" et les packages
dépendants qui peuvent être eux aussi installés dans le CLASSPATH).
Par défaut, même en 64 bits, la limite ne dépasse pas 2,5Go.
Note qu'avec JavaWebStart on n'installe l'appli JOSM que temporairement
dans le cache de déploiement, certains outils "nettoyeurs" veulent vider ce
cache, mais on perd des infos comme les préférences utilisateur qui sont
aussi dans ce cache, qui agit plutôt comme un container. En revanche cela
ne nettoie pas le cache JOSM des tuiles qui est stocké à part dans le
système de fichiers local de l'utilisateur et qui peut devenir très grand;
mais heureusement pour limiter la fragmentation de nomlbreux fichiers,
maintenant JOSM gère son cache de tuile avec un gros fichier "blob" unique
par couche, ce qui va beaucoup plus vite, mais ce gros bloc peut aussi se
fragmenter dans sa structure interne, bien qu'il est plus efficace que ce
que fait le système de fichiers lui-même, et il y staocke les tuiles et les
métadonnées HTTPS de façon plus ordonnée et plus compacte en ne gardant que
les métadonnées utiles et pas tout le "bazar" des entêtes MIME d'HTTP ou
HTTPS.

Le lun. 12 oct. 2020 à 16:56, Percherie OnDaNet 
a écrit :

> Étrange... je suis sur une machine windows avec 2Go de défini pour Java.
>
> Voici la capture écran de ce qui ne fonctionne pas (avec info bulle et
> tout et tout) : https://ibb.co/6bztCmX
>
> A la maison je travaille exclusivement sur Mint, je referai une tentative
>
> Le 12/10/2020 à 16:40, osm.sanspourr...@spamgourmet.com a écrit :
> > Merci pour la mise à jour.
> >
> > Aucun problème pour charger la relation.
> >
> > J'ai copié https://osm.org/relation/11741864
> >
> > et utilisé la fonction "Télécharger un objet...".
> >
> > Linux Mint 20, JOSM canal stable.
> >
> > Tu utilises une machine virtuelle 32 bits ?
> >
> > Si le chargement est partiel tu peux demander de charger les membres.
> >
> > Et non Lyon-Toulouse ne fait pas moins de 200 km vu d'ici.
> >
> > Jean-Yvon
> >
> > Le 12/10/2020 à 16:20, Percherie OnDaNet - perche...@toutenkamion.net 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Zone de défense et de sécurité Polynésie française

[Philippe Verdy]

Note ce n'est pas compliqué et la relation  11318876
<https://www.openstreetmap.org/relation/11318876> est correcte maintenant

Le sam. 10 oct. 2020 à 22:59, Philippe Verdy  a écrit :

> Pourquoi simplement ne pas supprimer cette relation: cela ne supprime pas
> les membres référencés (ways frontières, et je ne vois pas pas pourquoi ce
> serait différent des relations de niveaux 3 qui existent déjà pour les
> outre-mer, sauf qu'il y a un groupement possible entre les DROM et COM dans
> les zones Antilles, Océan Indien et Pacifique.
>
> Ces relations n'ont pas du tout besoin d'être énormes, car le plus gros
> est constitué de frontières maritimes (sauf les frontières terrestre de la
> Guyane avec le Suriname et le Brésil, où ces frontières sont assez peu
> détaillées car elles suivent des zones très peu aménagées le long de
> limites naturelles faiblement bornées en forêt, sur certains sommets ou au
> milieu estimé d'un lit de fleuve, et la courte frontière avec les Pays-Bas
> à Saint-Martin, pas bien compliquée non plus). Ces relations de type 3 sont
> pas compliquées du tout, rien à voir avec les limites en métropole.
>
> Donc recréer simplement (ces zones de défense en outre-mer sont des zones
> qui incluent le domaine maritime de la même façon qu'en métropole, pas
> besoin du détail des côtes et des îles et îlots, notamment pour la zone
> Pacifique on a déjà un contour externe simple pour la Polynésie seule, et
> aussi Wallis-et-Futuna, c'est facile à regrouper).
>
>
>
> Le sam. 10 oct. 2020 à 20:29, Donat ROBAUX  a écrit :
>
>> Hello,
>>
>> Je crois que j'ai fait une grosse boulette...
>> Si quelqu'un sait comment on peut éviter de supprimer la relation (que
>> j'ai voulu créer) en dégageant proprement tout ce qui n'est pas de
>> Polynésie, je suis preneur.
>>
>> Comme quoi, même quand on est un contributeur aguerri, on peut faire des
>> conneries.
>>
>> Donat
>>
>>
>>> -- Forwarded message --
>>> From: deuzeffe 
>>> To: talk-fr@openstreetmap.org
>>> Cc:
>>> Bcc:
>>> Date: Sat, 10 Oct 2020 14:54:32 +0200
>>> Subject: Re: [OSM-talk-fr]  Zone de défense et de sécurité Polynésie
>>> française
>>> Le 10/10/2020 à 13:21, Jacques Lavignotte a écrit :
>>>
>>> Bonjour,
>>>
>>> > Le 10/10/2020 à 13:03, blef a écrit :
>>> >> Zone de défense et de sécurité Polynésie française
>>> >> <https://www.openstreetmap.org/relation/11318876>
>>> >
>>> >
>>> https://fr.wikipedia.org/wiki/Zone_de_d%C3%A9fense_et_de_s%C3%A9curit%C3%A9
>>>
>>> Elle est juste trop grande... Et faite par un étrangeophone (ça compte,
>>> ça ?)
>>>
>>> Revert général ou com. du changeset avant ?
>>>
>>> --
>>> deuzeffe
>>>
>>>
>>>
>>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>  Garanti
>> sans virus. www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>> <#m_2064044693012421592_m_-4121820595296655340_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> ___
>> 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] Zone de défense et de sécurité Polynésie française

[Philippe Verdy]

Pourquoi simplement ne pas supprimer cette relation: cela ne supprime pas
les membres référencés (ways frontières, et je ne vois pas pas pourquoi ce
serait différent des relations de niveaux 3 qui existent déjà pour les
outre-mer, sauf qu'il y a un groupement possible entre les DROM et COM dans
les zones Antilles, Océan Indien et Pacifique.

Ces relations n'ont pas du tout besoin d'être énormes, car le plus gros est
constitué de frontières maritimes (sauf les frontières terrestre de la
Guyane avec le Suriname et le Brésil, où ces frontières sont assez peu
détaillées car elles suivent des zones très peu aménagées le long de
limites naturelles faiblement bornées en forêt, sur certains sommets ou au
milieu estimé d'un lit de fleuve, et la courte frontière avec les Pays-Bas
à Saint-Martin, pas bien compliquée non plus). Ces relations de type 3 sont
pas compliquées du tout, rien à voir avec les limites en métropole.

Donc recréer simplement (ces zones de défense en outre-mer sont des zones
qui incluent le domaine maritime de la même façon qu'en métropole, pas
besoin du détail des côtes et des îles et îlots, notamment pour la zone
Pacifique on a déjà un contour externe simple pour la Polynésie seule, et
aussi Wallis-et-Futuna, c'est facile à regrouper).



Le sam. 10 oct. 2020 à 20:29, Donat ROBAUX  a écrit :

> Hello,
>
> Je crois que j'ai fait une grosse boulette...
> Si quelqu'un sait comment on peut éviter de supprimer la relation (que
> j'ai voulu créer) en dégageant proprement tout ce qui n'est pas de
> Polynésie, je suis preneur.
>
> Comme quoi, même quand on est un contributeur aguerri, on peut faire des
> conneries.
>
> Donat
>
>
>> -- Forwarded message --
>> From: deuzeffe 
>> To: talk-fr@openstreetmap.org
>> Cc:
>> Bcc:
>> Date: Sat, 10 Oct 2020 14:54:32 +0200
>> Subject: Re: [OSM-talk-fr]  Zone de défense et de sécurité Polynésie
>> française
>> Le 10/10/2020 à 13:21, Jacques Lavignotte a écrit :
>>
>> Bonjour,
>>
>> > Le 10/10/2020 à 13:03, blef a écrit :
>> >> Zone de défense et de sécurité Polynésie française
>> >> 
>> >
>> >
>> https://fr.wikipedia.org/wiki/Zone_de_d%C3%A9fense_et_de_s%C3%A9curit%C3%A9
>>
>> Elle est juste trop grande... Et faite par un étrangeophone (ça compte,
>> ça ?)
>>
>> Revert général ou com. du changeset avant ?
>>
>> --
>> deuzeffe
>>
>>
>>
>>
>
> 
>  Garanti
> sans virus. www.avast.com
> 
> <#m_-4121820595296655340_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] Carte des lieux de test COVID

[Philippe Verdy]

Pourquoi restreindre à la COVID-19 ? Pas moyen de généraliser aux centres
de dépistage pour d'autres maladies (notamment les MST, le sida, les
maladies professionnelles, ou dans certains zones ou professions
l'exposition à l'amiante, aux radionucléides, et d'autres polluants comme
le plomb et les produits phytosanitaires comme les glyphosates, le
dépistage généralisé des cancers, ou encore le dépistage des dépendances
(drogues, tabac, alcool), ou le suivi des expositions à long terme ? Ou
encore les centres d'analyse de l'eau, des produits alimentaires.

Et sans doute aussi les systèmes locaux de déclaration pour l'épidémiologie
avec des données accessibles.

Ca mérite un tag générique pour le dépistage en matière de santé publique
(humaine, vétérinaire, ou la protection des autres espèces des
espaces naturels protégés pour maintenir la biodiversité, notamment les
forêts, les ressources maritimes et fluvio-lacustres). Tout ce qui fait que
notre planète est encore vivante et peut se préserver un futur.

D'autres formes de dépistage aussi pourraient être nécessaire, en matière
culturelle (notamment l'éducation et la maitrise des langues et de l'écrit,
ou simplement pour justifier des droits par exemple pour les migrants).
Mais on sort du domaine de la santé et la biologie.


Le mar. 6 oct. 2020 à 10:58, Antonin Delpeuch (lists) <
li...@antonin.delpeuch.eu> a écrit :

> On 05/10/2020 11:20, Denis Chenu wrote:
> > Il existe une liste officielle semble t'il
> > https://sante.fr/recherche/trouver/DepistageCovid
> > Par contre : je ne sais pas ou la trouver autrement.
>
> Oui, mais c'est juste pour la France - si on se mettait d'accord pour
> représenter ça dans OSM, on pourrait avoir une carte internationale. Ça
> aurait d'autant plus d'intérêt que les tests sont souvent requis quand
> on change de pays :)
>
> Antonin
>
>
> ___
> 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] Facebook : défaut d'attribution

[Philippe Verdy]

Peut-être que cela témoigne d'un manque d'indépendance de la Fondation,
surtout au niveau de sa structure chargée de faire respecter la légalité,
vis-à-vis de l'organe supérieur de direction qui dépend trop de sxes "gold
members" et n'a pas envie de se fâcher avec ces membres.
La seule façon de résoudre ça serait d'avoir une structure plus
communautaire (où seraient représentés aussi les chapitres locaux, et sinon
des individus de la communauté en ligne, élus par cette communauté). Une
structure comparable à ce qui existe à la Fondation Wikimedia qui a séparé
ses pôles de décision, des pôles de contrôle (administrateurs de chaque
wiki et projets communautaires où se branchent divers dispositifs
automatiues ou d'audit qualité), et de ceux de médiation (composés de
membres non administrateurs). Il faut dire aussi que la Fondation OSM n'a
toujours pas une politique claire concernant les contributions rémunérées
et la transparence (qui devrait être requise pour les contrôleurs de bots
modificateurs et soumis à un audit communautaire obligatoire avec
publication des journaux d'action, et moyen de contact efficace y compris
l'arrêt d'urgence le temps de discuter des problèmes).
Wikiemdia n'est pas sans défaut mais au moins sa communauté a l'oeil et les
décisions peuvent se discuter (en témoigne sur Meta-Wiki l'action en cours
concernant le wiktionnaire malgache et les traductions automatisées faite à
l'aveugle en reprenant massivement des infos pas vérifiées ou ambiguës sur
des pages contestées des wikis francophones ou anglophones). Quand on
commence à prendre des sources approximatives (acceptables mais discutées)
pour argent comptant et ajouter de nouvelles imprécisions par un processus
automatique massif, on voit ce que cela donne et ça complique la tâche de
tout le monde (et notamment celle des "petites mains" qui tentent de
juguler les problèmes par un patient travail qu'un bot mal contrôlé vient
ensuite écraser sans prévenir personne avec très peu d'effort en se fichant
de la masse de travail communautaire.)
Et bien sur OSM on a la même chose avec les contributions des Gold members,
que la fondation n'ose pas trop déranger car s'ils ajoutent 80% de trucs
positifs, c'est la masse des 20% de déchets que la communauté n'arrive pas
à suivre car elle ne peut faire que des corrections ponctuelles à un rythme
très différent.
Pourtant ces Gold members bénéficient depusi un bon moment du travail
patient des petites mains qui y ont consacré des heures et des jours. Si on
leur laisse trop de place, voire toute la place, on décourage les petites
mains qui voient leur gros travail saccagé et même pas discuté ou seulement
repris plus tard de façon très ponctuelle et parcellaire.

Mais pourtant je ne vois pas le problème de Facebook ici, car il ne
fait qu'agir au regard des politiques existantes: si cela ne marche pas, il
faut que la communauté se préoccupe des politiques et lignes
directices pour demander de les réformer ou affiner, quitte à décider de
limiter l'influence des Gold members (qui prendront, comme aussi la
Fondation, acte alors des décisions communautaires). Ce n'est pourtant pas
difficile pour ces Gold members, s'ils le veulent de se bâtir une base
dérivée où ils unifieront ce qui leur semble adéquat pour leurs sites; même
si cela ne les absout alors pas des obligations de licence du seul fait que
leur base sera un travail dérivé.

Facebook a des accords à la fois avec Mapbox et OSM, mais aussi avec
Here/Nokia/Microsoft. Selon ce qu'il désire il utilise les sources qu'il
veut et cela ne lui coute pas grand chose. Si Facebook est membre Gold
d'OSM c'est justement pour pouvoir en tirer le meilleur des deux (ou des
autres sources, y compris les siennes ou celles qu'il pourrait facilement
acheter à Google ou aux gestionnaires de réseaux divers, y compris les
réseaux publicitaires, et à des sources gouvernementales non libres dans
certains pays et par des accords d'échange avec ses propres clients à qui
il peut proposer des plans publicitaires plus favorables au plan financier
par le biais de réductions et facturations croisées de services). OSM n'est
pas là pour interdire à Facebook ou un gros major d'utiliser ses données
communautaires. Facebook a même intérêt à écouter les communautés s'il veut
se développer avec une image plus proche et plus en adéquation pour
développer son marché et répondre aux évolutions des demandes. Facebook
dispose de très nombreux outils pour écouter ses utuilisateurs et capter
des clients potentiels, et il ne peut ignorer la demande des
utilisateurs d'avoir un contrôle sur leurs données et leur travail, ainsi
qu'un retour utile de services pour compenser le travail gratuit fait trop
implicitement pr ses utilisateurs: ce travail gratuit DOIT payer, et il est
légitime qu'au minimum Facebook remercie ses utilisateurs et les gratifie,
pour ne pas s'accaparer la maitrise seule. Le but ne doit pas être de créer
un marché captif, un monopole de fait pour un produit devenu indispensable

Re: [OSM-talk-fr] Facebook : défaut d'attribution

[Philippe Verdy]

Le jeu. 24 sept. 2020 à 09:29, Denis Chenu  a écrit :

> Bonjour,
>
> Je sais que il ya une procédure à suivre, et qui fonctionne sans doute
> pour les plus petites entreprises ou même sur certaines plus grosse.
> Mais avant de prendre contact avec facebook, j'aimerais vérifier
> plusieurs chose.
>
> Le système sur Facebook, exemple sur la page
>
> https://www.facebook.com/Jardins-du-H%C3%AAtre-le-42-ex-Ferme-aux-Loisirs-101234147890218
> Ce lieu à une adresse, sur le coté droit :
> 1. un mini plan est visible (aucune attribution)
> 2. je clic sur le mini plan : aucun attribution visible
> 3. Je vois un petit point d'exclamation
> 4. je clic sur le point d'exclamation :
> 4.1 : lien "Mention légale du mappage de donnée" clic : ouvre la page
> https://www.facebook.com/maps/attribution_terms/
> 4.2 lien (c) OpenStreetMap donne sur
> https://www.openstreetmap.org/copyright/
>
> Alors mes questions :
> 1. sur la page de copyright (https://www.openstreetmap.org/copyright/) :
> il est indiqué "Le crédit devrait apparaître" et non doit (en français):
> est-ce que cela veut dire que Facebook satisfait aux obligations légales
> ? Ou non : les crédits doivent apparaître sur la carte.
>

Tu oublies la précision: "Pour une carte navigable" avant "le crédit
devrait apparaître". Hors ici ce n'est pas une carte navigable, c'est une
minicarte statique, sa taille ne permet pas de mettre un message complet et
l'icône (i) est adaptée à cette taille et donne clairement l'indication.
Facebook me semble correct ici.

Les terme "doit" (must en angalis) doit être un peu modéré en
considérant le contexte, la quantité relative d'informations (selon le
droit ad hoc des bases de données, la quantité d'informations affichée
relativement à celle des mentions).

Que critiques-tu ? Tu trouves le (i) trop petit bien qu'il soit
correctement placé, et suffisamment contrasté pour que la lettre "i" soit
bien visible sur sa pastille ? C'est un symbole assez universel dans la
signalisation routière, touristique, et la cartographie, repris par des
normes nationales ou internationales bien connues (et si besoin ce symbole
peut être adapté au "marché" visé par les pages Facebook.

La même chose concerne la page "à propos" d'une page Facebook
https://www.facebook.com/pg/Jardins-du-H%C3%AAtre-le-42-ex-Ferme-aux-Loisirs-101234147890218/about/
La minicarte est un peu plus grande, mais reste NON navigable et affiche le
même (i). La carte reste de dimension réduite puisqu'une partie est masquée
par le panneau d'info avec les adresses autres contacts: téléphone ou
Messenger Facebook.
Le panneau d'info donnant l'adresse a un bouton "affiche l'itinéraire" qui
mène à une autre carto (Here.com, incluant des données IGN en France): là
cela devient une carto navigable, en plein écran, avec l'attribution
complète sur le coin de la carte (mais ce ne sont pas les données OSM).

ensuite cette page "à propos" a un lien au dessus "signaler un problème
affichant un panneau formulaire avec encore une partie "Carte" affichant là
encore la minicarte avec le même (i). Mais cette fois on a un bouton
"modifier" rendant cette carte navigable (zoom et glissement) pour pouvoir
déplacer l'icône de géolocalisation. C'est là je pense que ce formulaire
pourrait se passer du (i) et afficher la mention complète, pas
forcement sur la carte mais juste en dessous, ou bien en agrandissant un
peu verticalement la carte pour que la mention recouvre cette carte.

La taille de la carte et sa navigabilité (permettant d'augmenter
considérablement les données affichées) sont les deux critères à retenir.

Le rendu des tuiles de la carte est distribué via le réseau CDN de
Facebook (URLs utilisant divers sous-domaines comme "
https://external-cdt1-1.xx.fbcdn.net/map_tile.php?...;), le style semble
être celui de Mapbox et le rendu sans doute effectué par Mapbox pour
Facebook via son propre compte mais il est fort probable que Facebook
fournit sa ferme de serveurs pour les rendus à la demande et ne pas
surcharger Mapbox, le détail de l'architecture reste une solution interne
entre Mapbox et Facebook, et sans doute en échange Facebook donne à Mapbox
de la capacité de calcul sur sa ferme de serveurs, et les deux coopèrent en
développement logiciel, y compris sur les parties opensource dont on
bénéficie aussi dans OSM.


> 2. Peut on bien considérer que 3 clic pour avoir l'information de
> copyright des contributeurs ne satisfait pas le "Vous devez également
> préciser clairement"
>

Je n'ai besoin que d'un clic sur le (i) pour voir le copyright d'OSM
(correctement lié)  et en plus le lien "mention légale du mappage de
données" qui aussi détaille de façon plus complète. ainsi qu'un lien pour
signaler un problème (si tu penses ne pas être d'accord c'est ce lien qui
permet de signaler à Facebook de la façon la plus appropriée un problème
sur les données affichées sur la carte comme un problème de nom, de taille
ou de forme, ou tout problème de rendu, ou "Autre" pour expliquer le
problème).

Ce (i) est 

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

[Philippe Verdy]

Le lun. 5 oct. 2020 à 17:16, Yves P.  a écrit :

> Et la mise en place de la version 17084 de JOSM a été faite.
>
> Merci pour l'info :)
>
>
>- #19789 , #19793
> - Correction des fuites
>de mémoire
>
> JOSM est souvent très lent sur ma machine car la mémoire virtuelle est
> "pleine". De temps en temps, la bécane plante complètement.
>

Désinstalle la version 32 bits de Java. Elle ne sert à rien. N'utilise que
la version 64 bits et tout ira bien (et ce sera même beaucoup plus
performant). Maintenant si ta bécane plante complètement, tu a sans doute
installé ton OS avec un espace de pagination mémoire insuffisant. Il n'y a
aucune raison que ça plante l'OS car la JVM a bien un quota limite de
mémoire qui devrait pouvoir être atteint sans planter le reste de l'OS.

JOSM fonctionne mal avec une JVM 32-bits qui n'a pas été taillé pour autre
chose que des petites "applets" qu'aujourd'hui on n'utilise plus du tout
pour le web. Car JOSM a besoin de beaucoup plus que les 300Mo limite par
défaut pour une VM.

Et même en 64-bits tu as encore une contrainte de quota, que tu peux
augmenter (pour éviter les "freezes" causés par son ramasse-miettes, lequel
est aussi bien plus performat et optimisé en 64-bits car il peut
mieux fonctionner de façon incrémentale par des threads supplémentaires en
arrière-plan). Attention aussi à mettre à jour tes greffons JOSM.

Autre problème possible cependant: des bogues dans les pilotes graphiques.
Et aussi penser à faire un Chkdsk (surtout si ton OS est installé sur une
partition FAT ou un système de fichiers non journalisé qui ne se répare pas
tout seul au redémarrage).

Si ça plante encore, penser à effacer le cache local de tuiles (qui a pu
être corrompu suite à un plantage de JOSM): bouton droit sur le fond
affiché, et "purger le cache". Si JOSM ne se lance plus correctement, tu
peux aussi effacer ce cache manuellement dans le système de fichiers avant
de lancer JOSM. auparavant ce cache générait énormément de tous petits
fichiers dans des zillions de sous-dossiers et cela sollicitait beaucoup
l'OS. Aujourd'hui il gère ce cache avec un gros "blob", une base de données
qu'il organise lui-même mélant les données et les index, unique pour chaque
serveur de tuiles. La purge est bien plus facile et efficace et cela
sollicite beaucoup moins l'OS et facilite aussi le maintien des quotas
limites par l'OS.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Services publics et administrations locales

[Philippe Verdy]

Le dim. 4 oct. 2020 à 21:42,  a écrit :

> C'est un peu comme dire que VéOLia est une structure gouvernementale au
> prétexte qu'elle est chargé localement d'une mission de service public :
> ça me chagrine même au sens large de government.


Il y a une grosse différence quand même: Veolia reste une société
commerciale avec ses propres objectifs et sa politique autonome,
indépendante des missions de service public qu'elle peut prendre en charge
en répondant à un appel d'offres public: mais là il y a contrôle sur le
cahier des charges de cet appel et uniquement dans ce cadre, et non sur la
gouvernance de Véolia.

On peut noter malgré tout que Veolia a une partie de son capital social
détenu par des organismes publics ou paritaires (comme la Caisse des dépôts
et consignation, et les banques publiques de développement) et donc des
sièges et droits de vote dans son conseil d'administration. A ce titre
Veolia se rapproche de la SNCF (et ses nombreuses filiales), Air France, ou
EDF et GDF-Suez (dont une partie est sévèrement contrôlé par l'autorité
publique, qui a veillé à ne pas confondre les missions publiques des
objectifs commerciaux, et à imposer des garanties de gestion comme la
séparation comptable et les fonds de garantie et assurances, même si in
fine il reste un organisme pilote sensé diriger le tout sous le regard des
détenteurs de parts sociales et leurs AG). De plus en plus de missions
publiques sont ainsi mainetnant réalisées dans des structures partiellement
ou totalement paritaires.

Pour les CAF ou URSAFF, c'est très différent: c'est toute la structure
elle-même qui est chargée de cette mission, et de fait sa gouvernance a des
sièges dans les pôles de décision pour les intervenant publics qui aident à
financer ces missions publiques (même s'il y a aussi des sièges privés, car
ce sont des organismes "paritaires", on dira "mixte", avec des intervenants
publics et privés, dont les syndicats professionnels patronaux et
d'employés, des assos et fondations ; ainsi que les chambres de commerce et
diverses agences environnementales ou touristiques qui elles aussi sont
paritaires avec leurs propres missions publiques et leurs missions privées
de développement; parmi les assos et fondations, certaines ont obtenu la
reconnaissance d'intérêt public en répondant elles aussi à un cahier des
charges, ce qui les soumet à un contrôle public, comme la Cours des
comptes, des obligations de dépôt et de certification des comptes et
d'autres contrôles des activités plus renforcés que le reste du secteur
privé).

Et pour les CAF, URSSAF ce mode de gouvernance fait partie même de leurs
statuts, elles ne peuvent pas s'en absoudre par une simple décision de leur
conseil d'administration sous la volonté de leur président (même s'il est
élu avec des voix privées, et même si la part de l'Etat n'est pas seule
majoritaire dans la gouvernance, l'Etat étant alors obligé de négocier mais
pouvant cependant imposer des décisions par la loi, du fait des statuts de
ces organismes, si ces organismes ne parviennent pas à une décision commune
entre l'Etat et les partenaires sociaux:  et l'Etat le fait souvent en
prenant sa responsabilité et l'exposant au public, notamment pour ce qui
concerne les régimes sociaux de sécu et de retraite et leur financement ou
les droits et le contrôle des bénéficiaires. cette décision de l'Etat est
alors sous le regard du citoyen électeur).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cartographie des dégâts de la tempête Alex dans les Alpes Maritimes

[Philippe Verdy]

Le lun. 5 oct. 2020 à 16:30, Yves P.  a écrit :

> Comment fait HOT pour avoir des orthophotos  ?
> Il me semble qu' "on" leur donne.
>
> Avec tes contacts dans les ministères, ce n'est pas possible d'en
> demander, même brutes, en attendant les versions orthorectifiées ?
>

Il y a peut-être moyen d'activer la procédure HOT permettant d'obtenir
l'imagerie appropriée en express chez certains fournisseurs privés dans la
zone concernée, même si la collectivité n'a pas encore ces images, mais qui
pourrait aussi en bénéficier (données ouvertes pour tous, l'état, les
collectivités, les assureurs, le grand public qui va devoir trouver son
chemin dans ce bazar pour que tout le monde puisse s'organiser).

HOT pour cela a des contacts chez les différents partenaires possibles :
agences spatiales, opérateurs de satellites, compagnies aériennes, mais
aussi les fondations nationales (et européennes ou internationales) qui
peuvent aider à financer les achats d'image sous forme de subventions, pour
peu qu'on leur explique et justifie ces dépenses...

HOT c'est surtout un espace de concertation qui réunit les intervenants (y
compris les grandes assos humanitaires, qui oeuvrent pour l'aide d'urgence
: alimentation, relogement, secours sanitaire ou médical) et qui ont aussi
besoin de garantir la sécurité de leurs aidants (y compris les nombreux
bénévoles) et de communiquer aussi sur leur action et la justifier.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Écoles maternelles -> amenity=school et school:FR=maternelle / et primaire-élémentaire-maternelle / était [Re: Osmose - Demande d'aide pour les écoles en France]

[Philippe Verdy]

Le ven. 2 oct. 2020 à 23:18, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> Christian R.
>
>
> Aparté, je suis scandalisé par le fait que l’on veuille supprimer la
> liberté de l’instruction. Cela  ne devrait, sans doute pas se faire, car,
> contraire à la Constitution et aux conventions internationales.
>
> Pour rappel : l’école n’a jamais été obligatoire en France
>

Ce qui est faux, ou alors il faudra affirmer que la loi de 1959 est
anticonstitutionnelle... Tu peux toujours tenter de faire une action au
conseil constitutionnel alors qu'il s'est maintes fois prononcé sur la
préservation des obligations et du droit scolaire que la loi justement
permet de garantir un minimum.

L'école est obligatoire (une obligation) pendant 10 ans (de 6 à 16 ans), et
sinon elle est gratuite (un droit) pendant 12 ans pour tous.

De fait il existe 2 années "préscolaires" correspondant au droit à la
gratuité (offerte par les maternelles publiques) avant l'école obligatoire.
En ce sens, ce ne sont pas des simples "kindergarten" car l'école
maternelle publique a des obligations d'enseignement aussi et une
qualification requise pour les enseignants, animateurs et l'équipe de soin
des jeunes enfants garantissant au parents que leurs enfants sont en
sécurité et bien traités, et les prépare bien ensuite (surtout au plan
social et comportemental) à l'entrée à l'école à 6 ans et leur capacité
ensuite à pouvoir s'y insérer et apprendre.

Ce qui n'est pas obligatoire c'est le lieu de l'école. Pour exercer le
droit gratuit, il y a l'école publique, mais cela ne restreint pas la
liberté de choix, donc l'école peut être privée, ou à domicile, **mais**
malgré tout ce droit est contrôlé du point de vue du droit de l'enfant par
l'inspection académique (et aussi l'inspection du travail, la médecine
scolaire, l'inspection sociale, la sécurité et l'adéquation des locaux) qui
veille à ce que l'enseignement délivré ne soit pas une dérive conduisant à
des abus (dérives sectaires, privation d'accès aux enseignements
fondamentaux, travail/esclavage de l'enfant, enfermement social/exclusion,
privation d'alimentation ou de repos ou de soins), ce qui n'interdit
pourtant pas les enseignements religieux (qui restent facultatifs même si
ce sont les parents qui choisissent, l'enfant acquérant son propre droit
plus tard grace aussi à la mixité sociale que la loi essaye de garantir).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] validation : sorties nommées

[Philippe Verdy]

Il manque l'exemple des sorties vers les aires de service: pas vraiment des
"destinations" mais le nom de toute l'aire même si elle est divisée en
plusieurs sections (une par direction: la direction est en fait celle de
l'autoroute ou la voie express: on sort et on rentre à nouveau vers cette
voie, le plus souvent sans changement de destination, car on ne peut pas en
sortir, hors des cas des voies d'accès de sécurité fermées en temps normal
par des barrières ou réservées à certains personnels, bien que eux aussi
utilisent le plus souvent la voie normale, avec une carte profesionnelle ou
un boitier de télépéage les dispensant de payer le péage).

L'aire (bien que détachée à côté de la voie express) est d'ailleurs gérée
par le même exploitant (sinon sur autoroute on aurait une barrière de
péage: on ne sort pas de la section à péage) même s'il y a souvent des
concessions (par exemple pour les boutiques, restaurants, stations
services, éco-musées, hôtels, parcs de loisirs) lesquelles s'occupent aussi
de l'entretien de certaines parties publiques non commerciales (comme les
toilettes, ou les terrasses, poubelles, tables de pique-nique en accès
libre).

Noter que certaines aires peuvent être accessibles aussi via un secteur
depuis le reste du réseau (on ne passe pas en voiture d'un secteur à
l'autre du fait de barrières, mais il y a des accès piétons surveillés
depuis leur parking pouvant donner accès aux commerces dans l'aire ou
touchant cette aire). Dans ce cas l'aire en elle-même (sa globalité et non
les secteurs individuels) peut être une "destination"

Le mer. 30 sept. 2020 à 11:02, PanierAvide  a
écrit :

> J'ai créé la traduction fr de la page highway=motorway_junction, avec de
> biens beaux exemples illustrés :
> https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dmotorway_junction
>
> Ça devrait déjà aider à lever les confusions. Si quelqu'un peut en faire
> une relecture ;-)
>
> Adrien P.
>
> Le 30/09/2020 à 09:39, osm.sanspourr...@spamgourmet.com a écrit :
> > Oui La Ville es Lan (sans tirets) est le nom de la sortie. Ça fait
> > partie du cartouche Sortie, pas des destinations.
> >
> > On ne met pas de lieu-dit en destination d'une sortie de nationale.
> >
> > De plus ce sont souvent des lieux-dits où ont été construits l'échangeur
> > et donc qui ne correspondent plus à une destination possible. Ici il n'y
> > a pas de lieu-dit La Ville es Lan dans OSM (juste une Rue de la Ville Es
> > Lan).
> >
> > Le 30/09/2020 à 09:23, PanierAvide - panierav...@riseup.net a écrit :
> >> En faisant une recherche rapide, je me rends compte qu'il y a une
> >> quarantaine de name=* avec un ";", qui ressemblent plutôt à des
> >> destination=*. Donc on pourrait modifier la règle en "si
> >> highway=motorway_junction + name contient un ";", alors name ->
> >> destination" ?
> >
> > +1
> >
> > En effet je ne vois pas de sortie nommée où on mettrait autre chose que
> > le nom. Par contre le point-virgule est à l'évidente un signe que le
> > champ name a été abusé pour mettre une destination.
> >
> > RB93 a encore frappé ? ;-)
> >
> > 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] validation : sorties nommées

[Philippe Verdy]

Je suis d'accord aussi concernant les sorties de rocades (comme à Paris,
Nantes, Rennes: ces sorties ont un numéro surtout pour le plan européen,
c'est plus facile pour les routiers ou touristes qui lisent mal l'écriture
latine; sinon elles ont des noms de "portes" qui ne sont pas réellement
toujours des directions suffisantes comme, "Porte Océane" ou portent en
fait le nom d'un quartier comme "Porte de la Chapelle")

Le mer. 30 sept. 2020 à 02:40, Gad Jo  a écrit :

> Pour l'instant je n'ai pas traité ces notes car je n'ai pas vraiment
> compris ce qui est attendu.
>
> Doit on déplacer l'info sur la tag destination ? Est ce qu'on peut
> conserver le numéro de sortie sur le segment ? En gros que doit-on faire ?
>
> Le September 29, 2020 4:51:27 PM UTC, Christian Quest <
> cqu...@openstreetmap.fr> a écrit :
>>
>> Le 29/09/2020 à 18:11, osm.sanspourr...@spamgourmet.com a écrit :
>>
>>>  Bonjour, je suis tombé sur une notification Osmose qui m'interpelle.
>>>
>>>  En fait une règle JOSM _spécifique à la France_ :
>>>
>>>  https://josm.openstreetmap.de/wiki/Rules/FranceSpecificRules
>>>
>>>  Unusually named motorway_junction; use of 'name=*' for the exit
>>>  destination?
>>>
>>>  Sauf qu'il est usuel en Bretagne que les sorties soient numérotées et
>>>  nommées (en breton dans la zone bretonnante).
>>>
>>>  Et là c'était du côté d'Albi où ça semble aussi systématique.
>>>
>>>  Un exemple :
>>>
>>>  
>>> http://osmose.openstreetmap.fr/en/error/1d1a8a63-be65-2dfb-73ba-fbd66513cf76
>>>
>>>
>>>  https://www.openstreetmap.org/node/250116724
>>>
>>>  Kerfleury est le nom de la sortie (et du lieu-dit le plus proche).
>>>
>>>  Les gens prennent la sortie Kerfleury.
>>>
>>>  Sur le panneau :
>>>
>>>  46.1 Kerfleury
>>>
>>>  et en dessous Quimperlé-Est (la destination en jargon DIR, que personne
>>>  n'utilise).
>>>
>>>  
>>> https://www.mapillary.com/app/?lat=47.84639403=-3.50455297=17=PStmBHEEK35wa2mql8FHQw=photo=0.5324220118049187=0.5275405429846113=1
>>>
>>>
>>>  Je veux bien qu'on conseille d'ajouter la destination, mais de là à
>>>  proposer de supprimer de la bonne information...
>>>
>>>  Dans d'autres coins de la France les règles sont différentes ?
>>>
>>>
>>>
>> Une sortie d'autoroute peut avoir un nom, sans qu'il corresponde à une
>> destination, exemple sur l'A6: Auxerre Nord / Auxerre Sud.
>>
>> C'est le texte du warning qui devrait être plus explicite pour séparer
>> le cas destination et le cas du nom.
>>
>>
> --
> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSMdata

[Philippe Verdy]

sport_center indique l'orgonisation, une forme possible d'usage, mais pas
l'objet physique.
sport=swimming indique l'activité principale de cette organisation. L'objet
physique ou les objets physiques qu'elle utilise ne sont pas forcément là.
L'objet physique (la surface en eau, habilitée à la pratique de ce sport)
n'est pas forcément utilisé pour ça.
On retombe sur la dichotomie entre l'espace géographique et ses usages
souvent multiples, et changeant indépendamment.
On ne tague donc pas la même chose. D'ailleur le tag sport=* n'indique que
l'activité sans préciser le lieu réel de l'activité, c'est un indicateur de
classification (partielle) qui ne se suffit pas à lui-même. Le sport est
vaste et comprend des tas de choes qui ne sont même pas géolocalisées, même
dans une discipline particulière.
Et ce qu'on entend par "piscine" désigne rarement uniquement la surface en
eau mais aussi ce qui est autour et qui y est souvent indispensable mais
pas toujours dans l'entourage immédiat.
Si on veut taguer le "terrain", le bassin devrait être tagué en tant que
tel, indépendamment des installations éventuelles autour (qui y sont liées
mais pas de façon unique).
Même le sport "natation" n'est pas seulement la pratique de la seule
natation dans le bassin, et les besoins ne sont pas les même en tant
qu'activité de loisir, de détente, de soin, de développement personnel, de
spectacle, ou de pratique compétitive.
Sans compter aussi que ça a aussi une autre utilité en terme de sécurité,
ne serait-ce que pour consituer une réserve d'eau utilisable pour autre
chose et rendu nécessaire ou à disposition légale d'autres usages publics
par une autorité autorisée, même si ensuite le cout induit pour cet usage
est pris en charge/compensé par une assurance privée ou collective, et que
même l'usage privé est très réglementé et restreint).



Le mer. 23 sept. 2020 à 18:10, Philippe Verdy  a écrit :

> sur  "leisure=sports_centre + sport=swimming", cela n'indique pas
> nécessairement le contour de la piscine mais l'emprise de la zone sportive
> qui inclue une piscine, ou un bassin protégé ça peut être zone délimitée
> d'un étang naturel ou artificiel ou d'un lac, et ne concerner qu'une partie
> du bassin, le reste étant pour d'autres activités comme la pratique de
> sports en eau vive avec une autre organisation.
> De plus même si le sport principal c'est la natation, on peut y trouver
> une zone dédié au plongeon, à l'entrainement à la plongée, il peut y avoir
> aussi une utilisation mixte (genre bassin qui peut être couvert d'un
> plancher mobile, et servir à d'autres sports, sans compter aussi des salles
> de culture physique et même dans un parc autour de l'athlétisme, un terrain
> de tennis. S'il y a unen tribune, ce peut être aussi une salle de
> spectacle; dans certains cas c'est aussi un musée où la piscine est
> conservée pour sa beauté architecturale, ses céramiques: la maintenir en
> eau permet de préserver l'équilibre de l'édifice et le bassin n'avoir plus
> qu'une fonction ornementale qui servira seulement à certaines occasions de
> prestige après un controle de l'eau et un peu de rangement autour...)
>
> Le lun. 21 sept. 2020 à 11:34, Denis Chenu  a
> écrit :
>
>> Quand je parle des erreurs, cela peut être sur la carte ou sur la façon
>> de les récupérer. Donc 2 liens différents : comment contribuer à
>> openstreetmap et comment remonter les erreurs ici(cf exemple).
>>
>> Denis
>> exemple : les piscines ne remonte pas toutes, pas celle en
>> leisure=sports_centre + sport=swimming
>>
>
> Donc si c'est biuen une piscine, autant la délimiter en tant que tel à
> l'intérieur du centre sportif. Enfin des centres sportifs consacrés à la
> natation peuvent ne plus être qu'un point de rassemblement d'un club,
> l'activité étant ailleurs (surtout je pense pour les clubs liés aux équipes
> de compétition, ou la préparation sportive hors eau).
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Annonce]: Quatre nouvelles couches thématiques disponibles sur magOSM

[Philippe Verdy]

Le mer. 23 sept. 2020 à 11:38, Augustin DOURY 
a écrit :

>
> * l'interface pour contribuer/corriger est pas si évidente: rien pour
> ajouter un élément manquant, ni pour modifier un élément trouvé.
>
>
> Là je n'ai pas compris de quelle interface tu parlais. Tu parles du README
> principal du dépôt Github (https://github.com/Magellium/magOSM/) ? Ou
> bien tu veux dire qu'il faudrait un lien vers les éditeurs OSM (iD, JOSM
> ... ) ?
>

Evidemment c'est pour éditer les données (manquantes, erronées/mal classées
ou taguées, doublons/pollutions ou inventions à supprimer): donc avec JOSM,
iD (externe ou dans une instance hébergée par vous sur le même site), ou
tout autre éditeur simplifié pour juste modifier des tags ou pour ajouter
une note visible dans les notes OSM.org ou pour aider les notes existantes
à être discutées/traitées/marquées comme résolues, et pourquoi pas la
liaison avec d'autres outils QA comme Osmose.

Peut-être aussi pour éditer les filtres utilisés pour créer un filtre
"custom" qu'on peut soumettre comme proposition de modif à intégrer dans le
dev ou qu'on souhaite rendre partageable avec les autres, si vous gérez des
profils d'utilisateur enregistrés (avec une authentification OAuth pour
s'identifier comme utilisateur d'OSM.org ou pour créer un compte chez vous
avec une demande d'autoriration pour valider aussi cette création chez
OMS.org, avec au passage l'acceptation des termes du contributeur et de la
licence).

Je ne parle pas de contribution au développement, là c'est à part: GitHub a
ses façons de faire et vous n'allez pas refaire son interface qui sert à
des millions de gens et pour plein de projets qui n'ont rien à voir avec le
votre ni même OSM).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSMdata

[Philippe Verdy]

sur  "leisure=sports_centre + sport=swimming", cela n'indique pas
nécessairement le contour de la piscine mais l'emprise de la zone sportive
qui inclue une piscine, ou un bassin protégé ça peut être zone délimitée
d'un étang naturel ou artificiel ou d'un lac, et ne concerner qu'une partie
du bassin, le reste étant pour d'autres activités comme la pratique de
sports en eau vive avec une autre organisation.
De plus même si le sport principal c'est la natation, on peut y trouver une
zone dédié au plongeon, à l'entrainement à la plongée, il peut y avoir
aussi une utilisation mixte (genre bassin qui peut être couvert d'un
plancher mobile, et servir à d'autres sports, sans compter aussi des salles
de culture physique et même dans un parc autour de l'athlétisme, un terrain
de tennis. S'il y a unen tribune, ce peut être aussi une salle de
spectacle; dans certains cas c'est aussi un musée où la piscine est
conservée pour sa beauté architecturale, ses céramiques: la maintenir en
eau permet de préserver l'équilibre de l'édifice et le bassin n'avoir plus
qu'une fonction ornementale qui servira seulement à certaines occasions de
prestige après un controle de l'eau et un peu de rangement autour...)

Le lun. 21 sept. 2020 à 11:34, Denis Chenu  a écrit :

> Quand je parle des erreurs, cela peut être sur la carte ou sur la façon
> de les récupérer. Donc 2 liens différents : comment contribuer à
> openstreetmap et comment remonter les erreurs ici(cf exemple).
>
> Denis
> exemple : les piscines ne remonte pas toutes, pas celle en
> leisure=sports_centre + sport=swimming
>

Donc si c'est biuen une piscine, autant la délimiter en tant que tel à
l'intérieur du centre sportif. Enfin des centres sportifs consacrés à la
natation peuvent ne plus être qu'un point de rassemblement d'un club,
l'activité étant ailleurs (surtout je pense pour les clubs liés aux équipes
de compétition, ou la préparation sportive hors eau).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OSM talk-fr] [Annonce]: Quatre nouvelles couches thématiques disponibles sur magOSM

[Philippe Verdy]

C'est pas mal fait. En revanche quelques remarques:
* la sélection des thématiques : les icones de la carte devraient être à
côté du libellé (au moins une générique) pour ne pas avoir à tout lire
* "Mes couches" en bas des thématiques : toujours vide, je ne vois pas ce
qu'on peut y voir ou y faire. On s'attendrait à avoir une liste en haut
affichant les couches déjà activées indépendamment de la liste complète des
thèmes.
* les réglages sur les thématiques : les exports ou régler la transparence
devrait être caché et déroulable à la demande pour avoir une liste plus
synthétique, ça devrait tenir en une seule ligne
* le rafraichissement de la page : rien n'est mémorisé de la sélection
actuelle : poistion/zoom, liste des thèmes actifs: il n'y a rien de
gardé dans la session, on perd tout, il ne reste que la première URL dont
les paramètres ne sont jamais changés. Peut-être gérer une base de données
locale dans le navigateur et au moins mettre à jour l'URL pour les réglages
de base
* les filtres utiliss pour les tags : des anomalies avec des éléments
manquants (par exemple les structures sociales, les critères sont un peu
trop restrictifs ; difficile de localiser les assos humanitaires par
exemple, il faut dire que les amenity=* ont diverses façons d'être taguées,
par statut, par type de service proposé et souvent il y en a plusieurs, par
type de bénéficiaire)
* l'interface pour contribuer/corriger est pas si évidente: rien pour
ajouter un élément manquant, ni pour modifier un élément trouvé.

Sinon bravo pour la fluidité des réponses sur le serveur.


Le lun. 21 sept. 2020 à 17:22, Camille Scheffler 
a écrit :

> Bonjour à tou.te.s,
>
> Contributrice OpenStreetMap dans la vie, je m’intéresse également à OSM
> dans le cadre de mes études de géomatique. Au cours de mon stage au sein de
> Magellium j’ai ainsi pu travailler sur le projet magOSM
>  qui propose désormais 4
> nouvelles couches de données thématiques:
>
>
>- la couche des* itinéraires de trains*: qui présente les différents
>itinéraires ferroviaires à l’échelle de la France métropolitaine incluant
>les TGV, les TER, les Intercités, ainsi que les RER et les Transiliens: [
>visualisation
>
> 
> - fiche de métadonnées
>
> 
>]
>
>
>
>- la couche des *structures sociales*: créée en collaboration avec
>Donat Robaux, avec qui nous avons pu réfléchir sur l’implication du terme
>de structures sociales dans l’écosystème OSM: [visualisation
>
> 
> -  fiche de métadonnées
>
> 
>]
>
>
>
>- les couches des  *propositions de constructions* (tag *proposed*) et
>des *constructions*, créées en complémentarité car représentant deux
>états successifs dans le processus de construction d’un élément dans la
>base de données: [visualisations
>
> 
> - fiche de métadonnées constructions
>
> 
> & fiche de métadonnées propositions de constructions
>
> 
>]
>
>
> J’espère que ces données vous seront utiles, en tous cas n’hésitez à nous
> communiquer vos retours sur ces nouvelles couches. L’ajout d'autres couches
> thématiques reste également ouvert à vos suggestions et/ ou contributions
> :)
>
> Au plaisir d’échanger avec vous,
> Camille Scheffler
> *User:Camischflr *
> ___
> 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] SISA : quels attributs ?

[Philippe Verdy]

Les conditions d'exercice ne contiennent en revanche rien concernant le
médical, ça ressemble plus à une niche fiscale, une exception dans le
régime des sociétés commerciales, et je ne vois pas les obligations qui
sont demandés aux sociétés civiles immobilières, sans doute pour que les
maisons de santé n'y soient pas contraintes.

Le sam. 19 sept. 2020 à 17:46, Philippe Verdy  a écrit :

> C'est un syndicat ou service de conseil pour professionnels (genre B2B ou
> activités de gestion ou de négociation, promotion/publicité, formation
> professionelle...) ou ça rend directement des services de santé aux
> patients et ça traite les dossiers médicaux?
> Ce que j'en sais c'est juste ça:
>
> https://solidarites-sante.gouv.fr/professionnels/se-former-s-installer-exercer/l-exercice-coordonne-entre-professionnels-de-sante/article/la-societe-interprofessionnelle-de-soins-ambulatoires-sisa
>
>
> Le sam. 19 sept. 2020 à 17:07, deuzeffe  a
> écrit :
>
>> Bonjour,
>>
>> Une société interprofessionnelle de soins ambulatoires (SISA) s'est
>> implantée dans ma commune et a son siège social à la MSP (comme par
>> hasard). J'aimerais bien le signaler dans osm.
>>
>> En plus de "ref:FR:NAF=8690F (Activités de santé humaine non classées
>> ailleurs", quel attribut principal ? office=? Mais quelle valeur ?
>>
>> Une idée (Yves ?) ? Merci pour les réponses (en thème).
>>
>> --
>> deuzeffe
>>
>> ___
>> 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] SISA : quels attributs ?

[Philippe Verdy]

C'est un syndicat ou service de conseil pour professionnels (genre B2B ou
activités de gestion ou de négociation, promotion/publicité, formation
professionelle...) ou ça rend directement des services de santé aux
patients et ça traite les dossiers médicaux?
Ce que j'en sais c'est juste ça:
https://solidarites-sante.gouv.fr/professionnels/se-former-s-installer-exercer/l-exercice-coordonne-entre-professionnels-de-sante/article/la-societe-interprofessionnelle-de-soins-ambulatoires-sisa


Le sam. 19 sept. 2020 à 17:07, deuzeffe  a écrit :

> Bonjour,
>
> Une société interprofessionnelle de soins ambulatoires (SISA) s'est
> implantée dans ma commune et a son siège social à la MSP (comme par
> hasard). J'aimerais bien le signaler dans osm.
>
> En plus de "ref:FR:NAF=8690F (Activités de santé humaine non classées
> ailleurs", quel attribut principal ? office=? Mais quelle valeur ?
>
> Une idée (Yves ?) ? Merci pour les réponses (en thème).
>
> --
> deuzeffe
>
> ___
> 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] Fin de projet "ça reste ouvert" : MERCI + soirée 24 septembre à Montrouge

[Philippe Verdy]

Ok donc on peut considérer que "ça reste ouvert est cependant une
expérience importante pour concevoir un système plus ouvert et réutilisable
pour autre chose".
Il ne faut pas tout jeter, le projet opensource peut rester, quitte à ce
qu'il incite d'autres à en faire des forks pour leurs projets "similaires"
et à les maintenir eux-mêmes (mais aussi que ces forks s'aident entre eux à
trouver des trucs en commun et à vouloir les réintégrer par "backporting"
sur la branche principale.
Il ne faut pas tout jeter et ça doit rester un projet opensource ouvert
même s'il n'a plsu beaucoup de maintenance, et si une équipe en fait
beaucoup que les autres sur son fork, elle pourrait assurer la .maintenance
du projet de base.

La seule chose concernant son projet c'est la pérennité des données dans la
base OSM: on voit le besoin de ne plus tout mélanger et pouvoir avoir
plusieurs bases (des "layers"), sans intégrer nécessairement, comme dans
les SIG classiques. Hors les éditeurs OSM actuels travaillent presque tous
sur un seul base unique (sauf les éditeurs comme QGIS qui considèent just
OSM comme une couche unique où tout est déjà lié et interdépendant.
Hors dans le modèle OSM, le modèle multibases srait aussi intéressant pour
gérer le cycle de vie des données, la collaboration ou coopération en
équipe, la veille qualité, le travail scolaire surveillé en classe
(histoire de ne pas demander à ceux que ça n'intéresse pas de pouvoir
toucher à tout et faire ce qu'ils veulent dans OSM)

Hors un projet thématique quelconque (par exemple un Maproulette, ou une
édition rémunérée) peut bénéficier d'un tel modèle multicouche et aussi
c'est un outil en "postedit" pour pouvoir produire une version "publiable"
(ce que fait Mapbox par exemple avec une base nettoyée et mieux validée et
plus stable, permettant aussi des gains de performance sur les rendus)


Le ven. 18 sept. 2020 à 18:05, Florian LAINEZ  a écrit :

> Philippe les instances internationales seront toutes fermées, les
> communautés locales n'ayant pas exprimé le besoin de continuer à les
> utiliser.
>
> Philippe nous pensons également qu'il est important de savoir clore
> proprement un projet.
> Pour rappel l'infra de "ça reste ouvert" avait été développée à la hâte
> pour palier à l'urgence Covid. Elle n'a jamais été pensée pour le long
> terme.
>
> "le projet du mois" n'est pas "ça reste ouvert" : c'est un autre projet.
> Il est certes dans la continuité mais avec des objectifs qui diffèrent.
> Techniquement, cela a donc plus de sens de redévelopper à partir d'une
> techno différente.
>
> Ceci dit, je comprends ta frustration et je la partage même : dans "ça
> reste ouvert" on avait réglé de nombreux problèmes d'UX, d'ergonomie, et il
> est rageant de voir que ce travail est à recommencer.
> Aucun doute néanmoins que l'on a en tête de remettre en ligne un
> visualisateur/éditeur facile à utiliser pour les contributeurs
> non-expérimentés pour "le projet du mois".
> Wait, c'est pas exactement ce que l'on est en train de faire ???
> https://github.com/vdct/ProjetDuMois
> Votre aide est bien évidemment la bienvenue.
>
>
>
> Le ven. 18 sept. 2020 à 17:50, Philippe Verdy  a écrit :
>
>> Bref "ça reste ouvert" pourrait être "ça a fermé" ou "ça vient
>> d'ouvrir"...
>>
>> Le ven. 18 sept. 2020 à 17:49, Philippe Verdy  a
>> écrit :
>>
>>> Ca ferme aussi pour les autres pays qui utilisaient l'instance française
>>> ? Sinon les autres instances installées ailleurs peuvent continuer, et le
>>> projet opensource aussi même si l'instance s'arrête.
>>> Ce projet peut servir à développer d'autres projets du mois, on a
>>> toujours besoin de renseigner les commerces et services, et les horaires ou
>>> l'accessibilité, même si on revoit les thèmes et on trouve un autre nom de
>>> domaine, il n'y a pas forcément à réinstaller l'instance qui a déjà pas mal
>>> d'infos, ce serait bête de redupliquer ce travail déjà fait.
>>> En particulier le thème des commerces et services solidaires est devenu
>>> important aujourd'hui. On aimerait voir plein d'assos concernées.
>>> Et pourquoi pas y mettre le projet défibrillateur, ou la sécurité (les
>>> caméras de surveillance aussi), la santé et l'aide sociale en général, la
>>> gestion du trafic (accidentologie, zones de dangers, aires de
>>> stationnement, travaux de voirie...), les antennes et hotspots wifi, les
>>> sites remarquables, les activités festives/culturelles/sportives (qui ont
>>> besoin de soutien maintenant car ce seront encore longtemps de tous petits
>>> événements et plein vont disparaitre et ne pas rouvrir de sitôt ou

Re: [OSM-talk-fr] Fin de projet "ça reste ouvert" : MERCI + soirée 24 septembre à Montrouge

[Philippe Verdy]

Bref "ça reste ouvert" pourrait être "ça a fermé" ou "ça vient d'ouvrir"...

Le ven. 18 sept. 2020 à 17:49, Philippe Verdy  a écrit :

> Ca ferme aussi pour les autres pays qui utilisaient l'instance française ?
> Sinon les autres instances installées ailleurs peuvent continuer, et le
> projet opensource aussi même si l'instance s'arrête.
> Ce projet peut servir à développer d'autres projets du mois, on a toujours
> besoin de renseigner les commerces et services, et les horaires ou
> l'accessibilité, même si on revoit les thèmes et on trouve un autre nom de
> domaine, il n'y a pas forcément à réinstaller l'instance qui a déjà pas mal
> d'infos, ce serait bête de redupliquer ce travail déjà fait.
> En particulier le thème des commerces et services solidaires est devenu
> important aujourd'hui. On aimerait voir plein d'assos concernées.
> Et pourquoi pas y mettre le projet défibrillateur, ou la sécurité (les
> caméras de surveillance aussi), la santé et l'aide sociale en général, la
> gestion du trafic (accidentologie, zones de dangers, aires de
> stationnement, travaux de voirie...), les antennes et hotspots wifi, les
> sites remarquables, les activités festives/culturelles/sportives (qui ont
> besoin de soutien maintenant car ce seront encore longtemps de tous petits
> événements et plein vont disparaitre et ne pas rouvrir de sitôt ou pas sur
> la même forme), les fermetures d'activités (nombreuses faillites), les
> réservations indispensables sur des services où il n'en fallait pas avant
> demandent aussi des infos de contact à distance, notamment la télémédecine
> et les services d'accès possibles.
>
>
>
> Le ven. 18 sept. 2020 à 17:37, Florian LAINEZ  a
> écrit :
>
>> Hey,
>> Je vous ai fait une petite rétrospective de fin de projet "Ça reste
>> ouvert" pour vous raconter la petite histoire derrière la grande
>> https://twitter.com/caresteouvert/status/1306978543151308800
>>
>> Le mar. 15 sept. 2020 à 09:40, Florian LAINEZ  a
>> écrit :
>>
>>> Bonjour, pas à notre connaissance, non.
>>>
>>> Le mar. 15 sept. 2020 à 08:13, Jean-Claude Repetto  a
>>> écrit :
>>>
>>>> Le 14/09/2020 à 19:46, Florian LAINEZ a écrit :
>>>> >
>>>> > Le confinement étant terminé depuis quelques temps, il est maintenant
>>>> > temps de*clôturer officiellement le projet.*
>>>>
>>>> Bonjour,
>>>>
>>>> Cette application n'est pas utilisée dans des pays qui sont encore
>>>> confinés ?
>>>>
>>>> Jean-Claude
>>>>
>>>>
>>>>
>>>> ___
>>>> Talk-fr mailing list
>>>> Talk-fr@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>>
>>>
>>>
>>> --
>>>
>>> *Florian Lainez*
>>> @overflorian <http://twitter.com/overflorian>
>>>
>>
>>
>> --
>>
>> *Florian Lainez*
>> @overflorian <http://twitter.com/overflorian>
>> ___
>> 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] Fin de projet "ça reste ouvert" : MERCI + soirée 24 septembre à Montrouge

[Philippe Verdy]

Ca ferme aussi pour les autres pays qui utilisaient l'instance française ?
Sinon les autres instances installées ailleurs peuvent continuer, et le
projet opensource aussi même si l'instance s'arrête.
Ce projet peut servir à développer d'autres projets du mois, on a toujours
besoin de renseigner les commerces et services, et les horaires ou
l'accessibilité, même si on revoit les thèmes et on trouve un autre nom de
domaine, il n'y a pas forcément à réinstaller l'instance qui a déjà pas mal
d'infos, ce serait bête de redupliquer ce travail déjà fait.
En particulier le thème des commerces et services solidaires est devenu
important aujourd'hui. On aimerait voir plein d'assos concernées.
Et pourquoi pas y mettre le projet défibrillateur, ou la sécurité (les
caméras de surveillance aussi), la santé et l'aide sociale en général, la
gestion du trafic (accidentologie, zones de dangers, aires de
stationnement, travaux de voirie...), les antennes et hotspots wifi, les
sites remarquables, les activités festives/culturelles/sportives (qui ont
besoin de soutien maintenant car ce seront encore longtemps de tous petits
événements et plein vont disparaitre et ne pas rouvrir de sitôt ou pas sur
la même forme), les fermetures d'activités (nombreuses faillites), les
réservations indispensables sur des services où il n'en fallait pas avant
demandent aussi des infos de contact à distance, notamment la télémédecine
et les services d'accès possibles.



Le ven. 18 sept. 2020 à 17:37, Florian LAINEZ  a écrit :

> Hey,
> Je vous ai fait une petite rétrospective de fin de projet "Ça reste
> ouvert" pour vous raconter la petite histoire derrière la grande
> https://twitter.com/caresteouvert/status/1306978543151308800
>
> Le mar. 15 sept. 2020 à 09:40, Florian LAINEZ  a
> écrit :
>
>> Bonjour, pas à notre connaissance, non.
>>
>> Le mar. 15 sept. 2020 à 08:13, Jean-Claude Repetto  a
>> écrit :
>>
>>> Le 14/09/2020 à 19:46, Florian LAINEZ a écrit :
>>> >
>>> > Le confinement étant terminé depuis quelques temps, il est maintenant
>>> > temps de*clôturer officiellement le projet.*
>>>
>>> Bonjour,
>>>
>>> Cette application n'est pas utilisée dans des pays qui sont encore
>>> confinés ?
>>>
>>> Jean-Claude
>>>
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> --
>>
>> *Florian Lainez*
>> @overflorian 
>>
>
>
> --
>
> *Florian Lainez*
> @overflorian 
> ___
> 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] Covoiturage et véhicules propres : une signalisation expérimentale pour les voies réservées

[Philippe Verdy]

A voir:

Pour informer les usagers de la route, des panneaux de signalisation
indiquent les voies réservées aux transports en commun, bus, taxis mais
aussi aux véhicules en covoiturage et aux véhicules propres, en
agglomération comme sur les voies rapides. Depuis le 31 août 2020, une
expérimentation de signalisation a débuté sur tout le territoire pour
harmoniser la matérialisation de ces voies. Un arrêté publié au Journal
officiel le 29 août 2020 précise ces modalités.

https://www.service-public.fr/particuliers/actualites/A14270?xtor=EPR-141
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] rues en landuse residential

[Philippe Verdy]

Si ci, il y a bien des exemples où les landuse=residential ont été nommés
explicitement après ce découpage en blocs ou lotissements. Mais à chaque
fois en n'y incluant pas les rues bordées (seulement les voies privées).
Je pense même que c'est un découpage qui veut différencier le parcellaire
privé et le domaine public, plus ou moins issu du découpage cadastral (non
importable avec toutes ses irrégularités et son historique car il ne tient
pas compte du regroupement parcellaire  ou des extensions grignotées soit
par le privé sur le domaine public, soit l'inverse par vente ou par échange
de parcelles, soit entre propriétés, pour agrndir ou réduire des
bâtiments ou élargir une route, aménager un rond-point, faire une zone
d'arrêt pour les bus, ou tout travaux nécessitant de l'emprise ou une marge
de sécurité autour de certains ouvrages, ou tenir compte de l"évolution des
dangers ou de la nécessité de changer des accès barrés par un autre ouvrage.
Mais le pire c'est que ce parcellaire n'est pas toujours très précis dans
les petites communes: même vectorisé, le plan cadastral a gardé des
décennies voire des siècles d'un ancien découpage, et s'est tracé avec
d'anciens outils de mesure quand on n'avait pas autant besoin de précision
et que les tolérances étaient plus grandes sur des parcelles plus grandes.
de plus cela n'a pas toujours tenu compte des évolutions naturelles
(glissement du lit de fleuves et rivières, mouvements liés à
l'exploitation minière ou simplement les déformations naturelles avec un
écoulement des sols alluvionnaires dans les vallées ou encore les effets de
l'érosion et du changement de régime des eaux: le terrain n'est pas
statique même si on ne s'en aperçoit pas. C'est bien pour ça qu'il y avait
autant de balisage au sol mais une fois posé et repéré sur le cadastre ,
les mesures de triangulation deviennent de moins en moins précises à cause
des déformations non linéaires.
Mais le pire se trouve souvent dans les centre-villes anciens: les
bâtiments sont vraiment disposés dans tous les sens et les mesures et
proportions ne sont pas respectées, il y a des découpages artificiels qui
n'ont même jamais existé, juste estimés mais avec des erreurs liées à la
difficulté d'observation et l'usage d'anciens outils et de nombreux oublis.


Le sam. 12 sept. 2020 à 22:29,  a écrit :

>
> Le 12/09/2020 à 22:22, Marc Mongenet - marc.monge...@gmail.com a écrit :
>
> Si comme le pense Philippe c'est pour nommer
> les landuse, alors ce n'était pas nécessaire, ni même désirable,
> d'exclure les rues.
>
> Marc Mongenet
>
> j'avoue ne comprends pas car ça n'a pas été nommé non plus !
>
> Comme Jérôme est sur la liste il pourra expliquer ce qu'il a voulu faire.
>
> Cette partie-ci ce n'est sûrement à taguer comme ça, éventuellement en
> highway:area
> 
> =residential.
>
> 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] rues en landuse residential

[Philippe Verdy]

Je pense que l'auteur a voulu découper les zones résidentielles selon les
des blocs lotis (afgin ensuite de pouvoir en nommer certains) et qu'il a
ensuite rempli les trous laissés vides le long des rues qui les divisent.
Cependant c'est une subdivision arbitraire: les landuse=residential ne sont
pas fait pour nommer des blocs, des résidences ou des lotissements.

Et même si on le fait il n'y a aucune raison de ne pas inclure au moins la
moité des rues qui les borde; créer alors un espace intermédiaire juste
pour la voie publique est un non-sens.

Le sam. 12 sept. 2020 à 14:40, Georges Dutreix via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Bonjour,
>
> Je viens de tomber sur ça à La Ciotat :
> https://www.openstreetmap.org/way/433148353/history#map=18/43.17743/5.60195
> une emprise de rue en landuse=residential
>
> Tout le quartier est comme ça, je trouve ça assez lourd, et ça me semble
> même être un contresens puisque la zone "résidentielle" serait justement
> toute la zone en dehors de l'emprise des rues et trottoirs.
>
> Qu'en pensez-vous ?
> Doit-on laisser tel quel ? le signaler à l'auteur puis corriger ?
>
> Merci.
> Georges
> ___
> 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] Sondage : l'utilisation et la contribution à OpenStreetMap dans les collectivité et administrations

[Philippe Verdy]

Il aurait fallu ajouter que ce sondage ne s'adressent qu'aux représentants
d'organisations (administration centrale, administration
locale, établissement public, autre entité publique, grand groupe,
 PME/TPE, association) dont le nom doit être cité, ce "sondage" n'est pas
anonyme non plus (cela engage plus ou moins la communication publique de
cette organisation).

Bref moins c'est moins un sondage qu'un appel aux organisations à
communiquer sur le sujet d'OSM (leur utilisation ou implication)
comparativement aussi à d'autres solutions (y compris propriétaires) de
façon non exclusive (par exemple des avec usages différents en interne sur
des SIG privés, ou des exports open data sur le web non nécessairement
intégrés dans OSM car c'est à la charge de lacommunauté ou des autres
réutilisateurs, et un usage différente dans la communication au public;
l'implication dans OSM peut être dans le soutien individuel ou des missions
de travail, donc des contributions rémunérées et éventuellement une
intervention directe, ou bien dans des groupes de travail/réunions avec des
groupes d'utilisateurs individuels en clubs/assos ou dans les espaces de
coworking, ou bien dans l'aide apportée comme la mise à disposition de
salles ou matériels et autres moyens pour les ateliers d'utilisateurs, ou
encore un espace d'échange pour aider à remonter les corrections et
synchroniser les open data proposés, ou encore un suivi régulier des
données OSM pour détecter des incohérences ou manques dans les SIG et
exports open data, ou encore suivre les besoins et demandes de la
population, ou encore des financements/subventions, ou enfin des formations
internes pour aider leurs collaborateurs à suivre les règles communautaires
et les obligations légales d'OSM ou relatives aux donénes internes qu'ils
sont en droit d'importer dans OSM, et des recommandations sur les outils à
utiliser et la sécurité des systèmes informatiques, enfin une politique
concernant l'usage et la compatiblité avec les autres missions de travail
propres à l'entreprise).

Ceci dit OSM n'a pas encore fait lui-même (contrairement à Wikimedia) une
enquête sur les contributions rémunérées et la politique applicable.
Notamment il existe des contributions de certains gouvernements puissants
pour venir modifier ou masquer des données dans certains autres pays ou
destinées à détourner la réalité du terrain ou favoriser certains contrats
en fabricant des "fausses cartes" présentées au public (il y a des cas
directs d'intervention des services diplomatiques de grands pays: USA,
Chine, Russie notamment, et qu'OSM laisse faire en toute impunité et même
contre l'avis des locaux ou des populations concernées et des cas de
censure systématique abusive). Les conditions d'utilisation d'OSM laissent
un peu trop à désirer et certains utilisateurs "bien placés" ont acquis un
rôle disproportionné en se voyant offrir des privilèges excessifs, et
qu'ils utilisent même contre les contributeurs qui ont fait le plus de
travail bénévolement dans OSM (j'en ai été victime sur OSM, de la part d'un
haut diplomate américain de l'équipe Trump intervenant en Asie) !
.

Le jeu. 10 sept. 2020 à 09:36, Vincent Bergeot  a
écrit :

> Bonjour,
>
> Il est agréable de relayer une telle étude, d'autant plus qu'osm-fr a été
> contactée en amont et j'ai eu un entretien avec le cabinet Inno3 en mai
> dernier pour affiner ce questionnaire, travail préparatoire que je trouve
> louable.
>
> N'hésitez donc pas !
>
> "
>
>
>
>
>
>
>
>
>
>
> *Le cabinet Inno³ et l’Agence Nationale (ANCT) collaborent actuellement à
> la réalisation d’une étude portant sur le nombre et l’importance des
> initiatives publiques existantes basées sur le projet OpenStreetMap. Dans
> ce cadre, un sondage a été développé afin de de mieux appréhender les
> actions et potentialités de contribution et de mutualisation de différents
> acteurs envers le projet. Aussi, nous souhaiterions vivement que vous
> preniez le temps de répondre à ce sondage. En raison de l’implication de
> votre collectivité/administration/équipe dans le projet OpenStreetMap votre
> contribution est essentielle pour produire l’étude la plus fine possible et
> représentative du succès d’OpenStreetMap dans la sphère publique. Répondre
> au sondage ici : https://frama.link/-0vApmRs 
> Afin de collecter un maximum de contributions et d’obtenir les résultats
> les plus représentatifs, n’hésitez pas à partager largement ce sondage à
> tout acteur qui puisse vous sembler pertinent. N’hésitez pas à nous faire
> part de toute question ou remarque. Nous nous tenons à votre disposition et
> vous souhaitons une très bonne journée. Bien cordialement,"*
>
>
> --
> Vincent Bergeot
>
> ___
> 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] bâtiment sans numéro de rue

[Philippe Verdy]

Note le numéro 1 sur le cadastre est semble-t-il le numéro de parcelle. Le
1 est un peu plus au sud (avant les marais, mais c'est le seul numéro
impair. Il n'y a pas de 2 ni de 3 indiqués, de fait la mairie purrait bien
être au 3 (à l'entrée de la rue) si le 2 est pour l'école juste à côté.
Le 63 "bis" ne semble pas bon étant donné que sur la rue de la Vallée
d'Authie il n'y a semble-t-il pas d'accès, juste un mur avec des
véhicules stationnés devant.
L'absence de numéro indiquerait sans doute que l'accès à la mairie n'a
jamais été sur la rue de la Vallée (sauf un temps ancien quand ce bloc
incluant la mairie et l'école aurait été une seule et même ferme et avant
que la rue des mairies soit transformé d'un simple chemin agricole en rue).
Le cadastre de toute façon est très mauvais: il a visiblement été
jsute numérisé dans l'état à partir de vieilles planches tracées à main
levée: il n'y a aucun batiment correctement positionné (les écarts sont
TRES variables, les formes c'est un peu du n'importe quoi, les surfaces et
alignements ne correspondent pas).

Pas très étonnant dans ce qui est une petite commune rurale qui même encore
aujourd'hui n'a pas les ressources de revoir ça (et sans doute même pas sa
communauté de communes. D'ailleurs il manque aussi bon nombre d'étangs. On
se demande comment les exploitants de réseaux gèrent leurs propres besoins
(sans se soucier de l'intégration avec le reste des autres éléments
carographiques), ou si à chaque fois c'est juste une opération de sondage
très local pour conduire un chantier mais sans recollecter les résultats
vers un SIG.

Donc à moins que sa ComComm commande (et puisse se payer) des études (ou
qu'elle fasse appel à des aides financières ou techniques de la région ou
du département), il ne faut pas trop se fier au cadastre. D'ailleurs il y a
des tas de bâtiments "fantômes" et de nombreux oublis (mais en général
c'est dépendant de la volonté d'un acteur économique de s'investir dans la
zone, mais dans ce milieu très rural ils ne sont pas très attirés, pourtant
il y aurait un intérêt au moins au plan environnemental de recenser ces
zones de marais pourtant si différentes des grandes concentrations urbaines
du Nord avec leurs grandes zones industrielles à reconvertir et qui
monopolisent les énergies)

Sans doute que la commune verrait d'un bon œil se faire aider ne serait-ce
que par OSM qui montrerait une cartographie plus exacte de la commune et
permettrait ensuite de faire une meilleure planification des besoins et
protéger ce qui le mérite, ou au moins faire des arbitrages avec un œil
éclairé (aussi par la "participation citoyenne" au sens large) pour ensuite
mieux justifier des demandes d'aide.

Si je regarde l'IGN ce n'est pas beaucoup mieux. Pas plus concernant les
agences environnementales: cette zone en bordure du Pas-de-Calais et de la
Picardie semble délaissée depuis longtemps, et la commune ne fait pas
partie non plus du parc naturel régional (créé un un temps où les
Hauts-de-France n'existaient pas encore, ce parc régional semble plus
s'intéresser à la façade maritime, et marais de la Somme, mais pas
tellement aux marais de l'Authie où ne se trouve aucune agglo importante ni
aucun axe de communication, car même l'autoroute côtière A16 ne fait que la
traverser).


Le mar. 8 sept. 2020 à 21:44, pepilepi...@ovh.fr  a
écrit :

> Le 08/09/2020 à 20:20, Philippe Verdy a écrit :
>
> Note que dans ton cas je ne suis pas certyain qu'elle soit au 63 ou 65 de
> la Rue de la Vallée d'Authie. Regarder un peu l'imagerie BDOrtho, on voit
> un accès piéton plutôt depuis la rue des Etangs !
> et d'ailleurs le cadastre y indique que c'est le numéro 1 (donc l'autre
> rue !)
>
> Pas de 63 bis donc!
>
>
> C'est bien con, ça, parce que tous les sites que j'ai regardés en faisant
> une recherche rapide
> <https://duckduckgo.com/?t=ffsb=mairie+62870+roussent=v56-1=web>
> donnent comme adresse postale "Rue de la Vallée-de-l'Authie
> 62870 Roussent".
>
> Et si https://www.adresses-mairies.fr/mairie-de-roussent-25022.html la
> situe presque bien sur son plan,
> http://www.linternaute.com/ville/roussent/ville-62723/mairie la met au
> numéro 32 faute de précision sur le numéro...
>
>
>
> Le mar. 8 sept. 2020 à 17:27, Yannick  a écrit :
>
>> Le 08/09/2020 à 17:12, pepilepi...@ovh.fr a écrit :
>> > Le 08/09/2020 à 16:00, osm.sanspourr...@spamgourmet.com a écrit :
>> >>
>> >> Bonjour,
>> >>
>> >> j'ai un bâtiment (une mairie
>> >> <https://www.openstreetmap.org/way/242267944>) qui est dans une
>> >> associatedStreet
>> >> <https://www.openstreetmap.org/relation/3300253#map=15/50.3678/1.7843
>> >.
>> >>
>> >> Or selon la mairie et le cadastre il n'y a pas de numéro pour la
>> >> mairie qui est entre le 6

Re: [OSM-talk-fr] Projet du mois défibrillateurs : point d'avancement

[Philippe Verdy]

On est loin de l'objectif national d'équipement, qui devrait atteindre au
minimum 1 appareil pour 500 habitants, soit 100 000 à 120 000 appareils
(peut-être moins dans les villes denses où l'accessibiltié est plus facile
qu'en milieu rural et où les services d'urgences sont également
beaucoup plus rapides à intervenir).

Si on considère que les ERP doivent être équipés, et qu'en gros ils
reçoivent une centaine de visiteurs au plus, sauf les stades ou campings et
grands hôtels, qui ont une densité plus grande, et les centres commerciaux
qui ont des milliers de visiteurs, plus les établissements publics
municipaux (mairies, salles communales, écoles, médiathèques, musées,
salles d'accueil pour associations), tous les EHPAD, on devrait avoir au
moins une 4 ou 5 appareils même dans les plus petites communes rurales pour
aussi desservir les quartiers résidentiels un peu éloignés du centre, avec
les aires de sport, campings municipaux, aires d'accueil de gens du voyage.
Et au besoin avec des accords public-privé pour les aider à les doter et
les entretenir.

D'ailleurs ces DAE sont aussi l'occasion de trouver les ERP et aller voir
sa mairie pour demander pourquoi certains sites ne sont pas équipés, et
revoir la proximité des équipements avec sa population dans les quartiers
périphériques (pourquoi pas alors aux arrêts de bus en partenariat avec les
sociétés de transport qui elles aussi sont sensées s'équiper: elles
accueillent un public très nombreux sur leur réseau, et même si on n'équipe
pas tous les véhicules, au moins équiper des stations pour pouvoir
intervenir à l'arrêt en sécurité pour tout le monde et permettre aussi de
"dégager" le public inutile et gênant).

Et puisqu'on a une base publique DAE qui se met en place, mettre le tout
sur une carte permet de voir les zones sous-équipées où celles où les DAE
installés n'aident personne autour (notamment ceux en accès restreint dans
une entreprise). Sur une carte je mettrais séparément ces DAE d'accès
restreint (notamment ceux aux sein même des établissements protégés comme
les EHPAD.

Et puis il suffit d'aller voir votre gymnase municipal proche, votre stade,
et les salles de sports privées qui elles aussi devraient être équipées. Et
voir votre comité de quartier (et demander aussi à votre mairie de
planifier des rencontres publiques dans les quartiers et mettre la question
à l'ordre du jour et lui demander de faire cette collecte et le communiquer
(ne serait-ce que par le site de l'intercommunalité qui lui aussi devrait
avoir sa section "open data", et pas que les grosse métropoles).

Des entreprises industrielles seraient aussi concernées (exploitants et
distributeurs sur les réseaux d'énergie notamment, autorités portuaires,
sites "Seveso" et toute industrie classée comme dangereuse par les produits
ou matériels utilisés ou stockés : en cas d'accident industriel, ils
monopilinsent fortement les secours et il faut une capacité locale pour
agir...). Et à mon avis ces matériels devraient aussi être assurés en même
temps que leur contrat d'entretien, et on devrait pouvoir impliquer aussi
les sociétés d'assurances et mutuelles qui couvrent ces risques ou
subventionnent les équipements.

En attendant GeoDAE n'est qu'un jeu d'essai qui n'a pas encore
d'utilisation pratique, il faudra vraiment il plus grande implication aussi
avec tous les services d'urgence (15, SAMU, SDIS, pompiers, services de
police) et de contrôle (y compris la médecine du travail et les comités
d'entreprise) et les assos et comités de quartiers pour que tout le monde
accepte de remonter ses infos et pas chacun dans son coin. Mais
GeoDAE semble ne pas fonctionner avec un guichet pleinement opérationnel.

au passage, au delà de cet équipement, il y a d'autres dispositifs de
sécurité aussi à relever (y compris la surveillance des plages), ainsi que
les dispositifs d'alerte (capteurs divers pour l'air, l'eau/la mer). Et au
final on aierait avoir une carte avec une mesure de l'impact de ces
équipements (délais d'intervention, taux d'utilisation, remises à jour ou
en conformité, relevés des pannes ou appareils perdus/détériorés.

Et si une zone n'a pas besoin de davantage de DAE (sur-équipement) les
entreprises pourraient aussi contribuer d'une autre façon en abondant un
fond d'équipement pour couvrir les zones blanches ou aider les sites peu
favorisés à s'équiper et entretenir. D'ailleuis je ne suis pas sur
qu'inciter chacun d'eux à s'équipper individellement est efficace, et s'il
ne faudrait pas en fait que la répartition des DAE réellement installés
soit du resort d'une autorité de planification qui approuverait ces
équipements (en contrôlant leur installation et leur entretien) ou
simplement recevrait des garanties financières avec une redevance ou des
preuves comptables de contributions vers d'autres secteurs moins favorisés.

Et je suis même convaincu que l'obligation d'assurer ces matériels au sein
de chaque contrat d'entretien permettrait d'utiliser les infras
informatiques des sociétés 

Re: [OSM-talk-fr] bâtiment sans numéro de rue

[Philippe Verdy]

Note que dans ton cas je ne suis pas certyain qu'elle soit au 63 ou 65 de
la Rue de la Vallée d'Authie. Regarder un peu l'imagerie BDOrtho, on voit
un accès piéton plutôt depuis la rue des Etangs !
et d'ailleurs le cadastre y indique que c'est le numéro 1 (donc l'autre rue
!)

Pas de 63 bis donc!

Le mar. 8 sept. 2020 à 17:27, Yannick  a écrit :

> Le 08/09/2020 à 17:12, pepilepi...@ovh.fr a écrit :
> > Le 08/09/2020 à 16:00, osm.sanspourr...@spamgourmet.com a écrit :
> >>
> >> Bonjour,
> >>
> >> j'ai un bâtiment (une mairie
> >> ) qui est dans une
> >> associatedStreet
> >> .
> >>
> >> Or selon la mairie et le cadastre il n'y a pas de numéro pour la
> >> mairie qui est entre le 63 et le 65.
> >>
> >> Vaut-il mieux supprimer de l'associatedStreet ou déclarer un faux
> >> positif car elle fait bien partie de la rue ?
> >>
> >> Jean-Yvon
> >>
> > Ou écrire au maire pour lui demander de mettre un numéro à sa mairie,
> > parce que ça fout le bordel dans OSM ?
> >
> > En attendant AMHA c'est un faux positif
> >
> > JP
>
> Bonsoir,
>
> Moi je lui mettrais 63 bis en avisant le maire.
>
> Amitiés
>
> --
> Yannick VOYEAUD
> Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
> (Camille JOUFFRAY 1841-1924, maire de Vienne)
> http://www.voyeaud.org
> Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
> Journées du Logiciel Libre: http://jdll.org
> Généalogie en liberté avec Ancestris https://www.ancestris.org
>
>
> ___
> 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] bâtiment sans numéro de rue

[Philippe Verdy]

Si elle est entre le 63 et le 65 (positions cadastrales, alors la mairie
elle-même a son adresse aux deux numéros: 63-65.
Ce n'est pas exceptionnel ça arrive souvent en fait, les terrains et
l'immobilier se vendent, se réaménagent, sont démolis, reconstruits, les
accès sont modifiés...

C'est pour ça qu'on demande de mettre les points d'adresse
préférablement comme neouds indépendants des POI, de préférence en limite
de la voie publique et au droit d'un accès (mais un accès peut ne plus
exister) quand on peut le "rattacher" à une propriété actuelle.

Les POI eux peuvent préciser quelle adresse ils utilisent dans contact:*
(pas besoin dans addr:* qui restent liés aux positions cadastrales selon
les plans de numérotation mis en place par les services municoipaux mais
souvent pas revus pendant des décennies tant qu'il n'y a pas besoin de le
revoir pour créer des "bis", "ter", etc., ou "A"/"B/"C"). Certaines
municipalits ne veulent pas gérer cette complexité et ont choisi une
numérotation métrique (donc avec de larges plages de numéros inutilisés,
l'attribution se faisant alors facilement à la volée des aménagements et on
n'est pas à une petite différence de quelques mètres si un accès est
modifié (le numéro utilisé dans les communications postales et
enregistrements divers n'ont pas besoin de changer et en fait beaucoup
omettent de préciser une plage de numéro mais précisent juste un seul (en
général le plus petit ou le plus "rond").


Le mar. 8 sept. 2020 à 17:12, pepilepi...@ovh.fr  a
écrit :

> Le 08/09/2020 à 16:00, osm.sanspourr...@spamgourmet.com a écrit :
>
> Bonjour,
>
> j'ai un bâtiment (une mairie )
> qui est dans une associatedStreet
> .
>
> Or selon la mairie et le cadastre il n'y a pas de numéro pour la mairie
> qui est entre le 63 et le 65.
>
> Vaut-il mieux supprimer de l'associatedStreet ou déclarer un faux positif
> car elle fait bien partie de la rue ?
>
> Jean-Yvon
>
> Ou écrire au maire pour lui demander de mettre un numéro à sa mairie,
> parce que ça fout le bordel dans OSM ?
>
> En attendant AMHA c'est un faux positif
>
___
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]

Le mar. 8 sept. 2020 à 09:24, Christian Quest  a
écrit :

> Le 07/09/2020 à 10:53, osm.sanspourr...@spamgourmet.com 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.
> >
> La plus mauvaise raison selon moi.
>
> Le wiki est clair, pas de double objet, un POI est prioritairement
> surfacique sauf si le wiki indique pour le tag en question qu'il n'est
> que ponctuel... donc si les outils ne savent pas gérer ça, c'est à eux
> d'évoluer.
>

Donc tu te fais une remarque à toi-même concernant le rendu carto français
(celui par défaut sur openstreetmap.fr).


> Quand on met les 2, ça pénalise les outils qui suivent les règles à des
> traitements supplémentaires de dédoublonnage... merci !
>

La "pénalisation" est déjà en place et minime (et même possible puisque
Osmose sait le détecter et je ne pense pas que ça lui demande tant de
travail que ça.


> Il y a aussi le cas des places avec Nominatim et le rendu osm-fr (mais
> > là j'ai indiqué un contournement possible).
>
> Quel problème sur les place=* et le rendu FR ?  Il manque la prise en
> compte des polygones ?
>

Justement c'est bien ça, cette "règle" n'est  pas appliquée; pour s'éviter
d'avoir à gérer des doublons, il ne charge qu'une partie des données
valides et oublient les autres.
Si l'outil DOIT charger à la fois les points et les polygones pour les
mêmes tags, forcément il va devoir détecter et gérer les pseudo-"doublons"
proprement. C'est un phase de validation au même titre que le travail de
préparation et d'intégration dans les contributions d'OSM.

Et il y a des tas de raisons pour lesquelles même ces "doublons" sont
involontaires, notamment:
- des tas de noeuds non trouvés à la position attendue pour une recherche,
qui font qu'ils sont réajoutés
- le cas du serveur de données OSM qui ne charge pas tout (exemple très
régulièrment avec iD il manque des données ou on se retrouve avec une carte
totalement vide, le serveur a tronqué les données retournées (sans produire
aucune erreur, les erreurs qu'on voit dans la console sont essentiellement
celles de chargement des tuiles du fond de carte, des erreurs "mixed
content" sur certains fonds de carte (notamment les tuiles OrthoBD); l'API
de chargement de données n'est pas si stable que ça et les navigateurs ont
également renforcé récemment leur sécurité pour bloquer toute sorte de
choses silencieusement (et accélérer le reste du rendu sans épuiser les
ressources du poste client).
- la plupart des erreurs ne produisent aucun message dans le journal de la
console, des gestionnaires d'exception internes à l'appli les capture pour
ne pas planter l'appli, mais oublient de signaler ne serait-ce que sur la
console (que seuls les utilisateurs avancés vont consulter car la plupart
ne comprennent rien à ce qui y est affiché s'ils ne sont pas "développeurs
web".

Je parlais d'ID mais on a le même problème aussi dans JOSM (où là aussi
tout n'est pas chargé, et c'est même pas un bogue mais "par design"
pusique c'est conçu pour que ce soit l'utilisateur qui demande lui-même les
données) du fait ds limites du serveur OSM.org (divers "quotas"
d'utilisation appliqués silencieusement).

Tout n'est pas parfait, et je ne vois pas comment un rendu conforme peut
valablement se passer de charger les deux types d'objets et éviter une
phase de validation/dédoublonnage pour avoir un rendu correct (et s'il fait
un rendu incorrect, forcément les utilisateurs qui ne voient rien seront
tentés de rajouter à nouveau ce qui parait manquer).

Si le rendu ne fait les choses qu'à moitié, on reporte les problèmes et là
encore c'est fait silencieusement. Et pas la peine de renvoyer alors les
utilisateurs à une "faute" de leur part alors que ce qu'ils font est
parfaitement conforme à ce qui est documenté et ce qu'ils voient (dans les
limites qui lui sont imposées par les outils utilisés). Les "politiques"
d'OSM sont avant tout et en premier lieu à faire appliquer aux outils avant
d'incriminer les utilisateurs qui font du mieux qu'ils peuvent pour la
plupart.
___
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]

>
> 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] 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] 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] La gestion des poteaux

[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 ligne

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

[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

[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

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

[Philippe Verdy]

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
> <https://wiki.openstreetmap.org/wiki/Node> 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
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] anomalie du serveur OSM sur iD (données partielles/incomplètes)

[Philippe Verdy]

négociés chez les
fournisseurs de CDN (Level3 par exemple) ou négociés avec certains FAI. On
est loin de la neutralité du net... c'est une vision centralisatrice et
dangereuse en terme de sécurité et de stabilité, un château de cartes qui
s'écroule vite avec un effet domino important. Résultat de politiques
d'optimisation à court terme qui croient que ces incidents sont très
"improbables", donc impossibles (ils préfèrent juste "assurer" le risque en
faisant porter les coûts aux tiers et nier leurs responsabilité et sont
incapables ensuite de gérer les crises en temps utile et limiter les
dégâts). Donc pas de solution de repli, des dépendances fortes à un seul
fournisseur de fait en amont.

Le cas de Level3 prestataire trop dominant en Europe) est pathétique. Comme
aussi le cas de Free qui confie la totalité de son trafic "clients" à un
seul prestataire (Cogent aux Pays-Bas) et refuse les interconnexions avec
les autres backbones français (sauf comme urgence avec des VPN cachés
sous-dimensionnés et pas faits réellement pour ça à l'origine) et tout
système de routage passant par des voies régionales (tout le trafic remonte
et se concentre à Paris, c'st un réseau totalement en étoile, sans réelle
redondance car avec prestataires uniques, cela n'a rien d'une "toile").

Le ven. 4 sept. 2020 à 18:17, Denis Chenu via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Je gère des serveurs dont des serveurs DNS,
>
> Cependant : je ne me permettrais ni d'évaluer la qualité technique de DOH.
> Je laisse cela à des personnes compétentes.
>
> Denis
> Le 04/09/2020 à 15:18, Philippe Verdy a écrit :
>
> Ce n'est toujours pas complètement réglé. Notamment des fournisseurs de
> DNS sécurisés (dont bon nombre de services DNS over HTTPS qui perdent leurs
> sessions et on beaucoup de mal à les reconencter) sont toujours impactés.
>
> Le DNS over HTTPS (DOH) est proposé en ce moment en test par Google ou par
> Microsoft sous Windows 10, mais visiblement il n'a pas encore la
> capcité nécessaire de supporter le traffic nécessaire: les serveurs DOH
> "tombent" les uns après les autres par surcharge (plus assez de ports TCP).
> A mon avis le DOH est une mauvaise solution (à cause de l'utilisation de
> TCP) et le plus fiable reste encore le DNS sur UDP qu'on peut authentifier
> malgré tout avec les signatures numériques et les certificats PKI.
>
> J'avais ausi repéré l'incident pas que chez Level3 mais aussi chez Cogent
> (et sur certaines passerelles de Cogent vers l'Afrique transitant par
> OpenTransit/Orange). Là encore il y a toujours un problème (et certains
> pays africains sont encore quasi coupés du monde (il y a aussi des
> problèmes ailleurs comme en Syrie ou Corée du Nord, mais là c'est beaucoup
> plus lié aux mesures politiques, ou des mesures d'urgence dans la
> cyberguerre qui se déroule en ce moment, que ce soit entre US et Chine, ou
> Chine et Taiwan, et en fait pas tellement pour ce qui concerne la situation
> politique locale, puisque même les groupes violents ou extrémistes ont
> besoin de ces réseaux et ne les sabottent pas, bien au contraire, même
> s'ils veulent en prendre le contrôle pour pouvoir les utiliser encore
> davantage: les mesures prises le sont par leurs voisins).
>
>
> Le ven. 4 sept. 2020 à 09:39, Christian Quest  a
> écrit :
>
>> Le 01/09/2020 à 13:33, Philippe Verdy a écrit :
>> > oui ça remarche ce midi, hier soir l'internet était un enfer à
>> > naviguer. (sauf les sites Google, et le reste était extrèmmeent lent,
>> > surtout le DNS et presque tout ce qui transitait par les gros
>> > datacenters d'Amsterdam)
>>
>>
>> Tout ceci semble lié à une grosse panne chez Level3/CenturyLink, un gros
>> fournisseur de tuyaux.
>>
>>
>> https://www.nextinpact.com/lebrief/43434/une-panne-plusieurs-heures-chez-level3centurylink-fait-planter-partie-services-sur-internet
>>
>>
>> La concentration d'internet dans toute sa splendeur :(
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> ___
> 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] Affichage d'un name suivant le rendu

[Philippe Verdy]

Ca c'est jsute le point de vue théorique. Rien à voir avec le pragmatisme
qui consiste à s'adapter à ce qu'on peut et sait faire en attendant de
développer mieux.

Ton problème de comptage est un point de vue théorique uniquement qui
oublie de prendre en compte le fait que tu peux parfaitement (et
facilement en plus!) identifier les doublons. C'est une réponse de celui
qui a juste pas envie, pas le courage de le faire. Pourtant c'est facile à
documenter, et utile dans un *long* processus de transition où on n'aura
jamais tout en même temps et tout de suite: c'est illusoire de croire
qu'OSM sera complet, sinon c'est que le monde entier est mort (et n'a donc
plus besoin d'OSM et n'a plus non plus aucun contributeur)!

On en reparlera quand le monde ne sera plus peuplé que de robots et que
l'espèce humaine aura disparu. Personne ne le souhaite ici et en fait on ne
le verra jamais sur OSM, OSM sera mort bien avant ça.

Être pragmatique c'est juste savoir minimiser l'impact en terme de
conséquences, et ici les conséquences sont théoriques (pour un esprit trop
borné à ne pas vouloir voir le reste et qui voudrait se comporter comme un
robot). Mais un humain n'est pas induit en erreur, et on peut parfaitement
apprendre à un robot à se comporter correctement, il faut juste lui dire et
le faire travailler un peu plus, à peine plus en fait car c'est facile à
trouver dans la base).


Le ven. 4 sept. 2020 à 18:20, Vincent de Château-Thierry 
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.
>
> 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 même hors du rendu (par exemple pour les recherches) cela n'a pas
> > de conséquence: on trouve deux objets pratiquement au même endroit.
>
> Il y a au moins une conséquence : 2 objets pour la même réalité terrain,
> ça fausse les statistiques. Avec un polygone "parking" incluant un point
> "parking" la réponse à la simple question "combien y a t-il de parkings
> dans la commune ?" devient compliquée, alors qu'elle devrait être
> simplement la somme des noeuds "parking" et des polygones "parking" si on
> respecte le principe du "one feature, one element".
>
> vincent
>
> ___
> 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] Rond point et relations routes

[Philippe Verdy]

A mon avis je ne pense pas qu'on ait besoin de l'avis international (peut
importe dans quelle langue) pour décrire ce qu'on a en France et nos
besoins (bien que la solution française est pratiquement similaire chez nos
voisins, européens, ou nos outremers qui sont assez isolés de leurs
voisins, sauf en Angleterre et même pas tout le Royaume-Uni).

On peut décider ici pour la France (et pour d'autres pays francophones qui
nous suivent, même si par exemple les belges devraient en discuter aussi
avec les néerlandophones, les suisses avec les germanophones).

Donc aucune opposition à fixer ça dans la page française (en laissant toute
fois la place à d'autres pays francophones, notamment le Canada, la
Belgique en marquant clairement ce qui s'applique en France dans sa
section, et permettant des sections spécifiques pour d'autres pays, avec
d'autres exigences locales).

OSM applique une politique de respect des conditions locales: partout en
géographie, il ne faut pas toujours généraliser ce qui ne doit pas l'être
et laisser la place à des extensions ou exceptions et essayer de borner ce
qui est applicable (et le minimum applicable c'est la juridiction
applicable, nationale ou d'état, même si dans l'UE beaucoup de principes
réglementaires sont basés sur des règles européennes qui s'imposent du fait
du marché unique et de très nombreuses normes obligatoires assorties de
sanctions si elles ne sont pas appliquées dans une juridiction donnée avant
un temps imparti, une fois les temps de négociation, amendements ou recours
passés et portés dans les instruments de ratification et acceptés par les
autres pays ou négociés par échange d'autres exceptions pour eux).
Cependant au final, même si l'UE a plein de directives, elles ne sont pas
immédiatement applicables et au final c'est toujours la juridiction locale
qui fait loi et règles les litiges (même s'il y a encore ensuite des
recours européens en dernier ressort, qui peuvent alors imposer des
changements réglementaires ou des sanctions à une juridiction locale qui
devra modifier ses instruments de ratification et en notifier l'UE; de même
la France, comme les autres pays de l'UE, est tenue de publier les
décisions faisant jurisprudence, afin que les autres pays aussi puisse les
connaitre et éventuellement commencer des recours contre leur application
trop stricte ou trop large; en pratique ce sont les grands groupes de
cabinets juridiques qui se chargent de faire le tri et ensuite presser l'UE
de modifier les directives pour obliger les gouvernements à renégocier
certains accords ou les faire réviser dans leurs parlements pour les lois
ou par de nouveaux arrêtés d'application).

Bref, on peut décider ici ce qui vaut pour la France, mais rien n'interdit
d'en aviser les autres listes (d'autant que tout le monde n'est pas non
plus francophone, même en France au sens légal, et nombreux sont ceux qui
se sentent plus à l'aise avec une autre langue de travail, ou simplement
ils préfèrent passer plus de temps à coopérer à l'international et ne pas
se disperser sur plein de listes). Donc leur faire savoir qu'une modif a eu
lieu dans la page de doc francophone du wiki suite à un échange ici (ou sur
la petite partie francophone du forum en ligne d'OSM si certains le
suivent).

Unetelle décision peut aussi se faire savoir par le bulletin d'actus OSM
(lui aussi à la base hébergé sur le wiki mais très résumé et qui au moins
aura une traduction dans plus de langues : à charge ensuite pour les autres
de nous lire ou se faire aider pour comprendre les traductions. De toute
façon sur notre wiki, on peut aussi créer une sous-page qui sera traduite
en français et anglais (néerlandais, allemand, italien, catalan ou espagnol
pour les motivés, et même portugais pour ce qui concerne la Guyane et nos
voisins brésiliens bien que la Guyane soit très pauvre en rond-points et
que la communication c'est d'abord par voie fluviale ou maritime) et
référencée depuis la page anglophone sans avoir besoin de trop la
restructurer: la doc du wiki est d'abord centrée sur des aspects génériques
(tous pays) mais a vocation à avoir des sous-pages appropriées s'il le fait
pour certains pays (indépendamment des langues utilisées pour l'original ou
ses traductions complètes ou partielles).





Le ven. 4 sept. 2020 à 19:01, Georges Dutreix via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> C'est la question que je me pose aussi.
> On a les pages route=bus
>  et FR:Bus
> .
> Puis d'autres comme relation route
>  pour les  Itinéraires
> cyclables et randonnées
> ,
>
> Si notre souci est franco-français, et pas juste francophone, quelle est
> la bonne pratique ? Met-on un paragraphe "Rond point" dans ces pages en
> précisant "bonne pratique en France" ? Doit-on d'abord s'assurer 

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

[Philippe Verdy]

Et noter que le "POI" ne désignent pas la cartographie physique, ils sont
juste des points au centre d'une aire (de taille non spécifiée) qui n'est
pas délimitée nécessairement par un objet physique (un seul batiment,
plusieurs, des services annexes rattachés, y compris leurs boites aux
lettres qui peuvent être ailleurs, et qui ne couvrent pas non plus leur
aire d'influence ou de chalandise et ne dit souvent rien de leur importance
relative vis à vis de leur environnement économique ou social)

Hors on ne peut pas taguer comme un POI tous les objets physiques et les
découper ou regroupe ne fait souvent pas de sens non plus car on n'est pas
capable de faire une réelle délimitation: c'est pour ça qu'on les réduit à
un seule noeud assez souvent. Pourtant ils peuvent être bien plus grands et
avoir eux-même une structure interne plus fine (exemple: une école ou une
zone hospitalière avec divers services, et même pas mal de zones
commerciales: l'usage des lieux n'est pas forcément unique non plus et on
ne peut pas séparer géographiquement ces services qui pourtant y sont
situés et se recouvrent partiellement, que ce soit territorialement ou dans
le temps).

On ne peut donc pas déprécier une méthode plutôt qu'une autre.
Malheureusement, traiter les points et les polygones/surfaces, c'est très
différent dans les rendus. Et pour créer des filtres efficaces, ce n'est
pas facile car on ne les verra pas toujours simultanément dans toute
sélection d'objets depuis la base (au plan purement géométrique, les points
sont trop petits ils peuvent être oubliés, les surfaces sinon ne sont
qu'indicatives le plus souvent et parfois trop grande relativement à
l'importance d'autres objets voisins ou qui y sont inclus: on ne peut pas
figer ces règles de filtrage dans les rendus, donc autant permettre cette
flexibilité: c'est aux rendus qui voient les deux types d'objets de mieux
gérer les filtres au cas où il voient des doublons, et ils n'en voient pas
toujours puisqu'ils ne sélectionnent pas tous la même chose).

Enfin les POI tagués comme simple noeud n'ont toujours indication d'une
taille relative (au moins un rayon), et leur "importance" relative par
rapport au reste ne peut pas non plus être décrétée par le système de
tagging, sinon on aurait partout le même carte unique dans tous les rendus,
les mêmes filtres appliqués à tous les niveaux de zopom, et trop de détail
visibles pour tous les usages qui n'en ont pourtant pas besoin: ce qu'on
ferait serit de recréer une carte "à la Google" avec ses critères imposés
ou téléguidés par des choix externes (ou des politiques commerciales selon
les intérêts des autres et pas du visiteur réutilisateur; OSM serait
beauoup moins riche).

Le ven. 4 sept. 2020 à 17:25, Philippe Verdy  a écrit :

> 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.
>
> Et même hors du rendu (par exemple pour les recherches) cela n'a pas de
> conséquence: on trouve deux objets pratiquement au même endroit.
>
> C'est similaire à d'autres objets où on tague les deux (y compris les
> "labels" qui ont été utilisés et sont encore approuvés dans les relations
> boundary même si on n'en a plus besoin pour les rendus les plus courants ni
> pour les recherches pour les outils classiques comme Nominatim. Ce qui doit
> être changé (ou corrigé) c'est ce que doivent faire les rendus au cas où
> ils trouvent les deux objets (de type différents) au même endroit et la
> façon dont ils gèrent les priorités d'affichage (car de toute façon ils
> font toujours des choix, ils ont tous des filtres et ce sont ces filtres
> qui sont à régler pour eux-mêmes, même si les autres rendus en ont encore
> besoin puisqu'ils ne "voient" qu'une partie des objets).
>
> Rien à voir donc avec "taguer pour le rendu", qui ne désigne que la façon
> de **détourner** des tags prévus pour désigner tout autre chose a fin de
> forcer un affichage. Ce n'est pas du tout le cas ici: les deux
> méthodes sont approuvées. Et il n'a pas été décidé d'en déprécier l'une
> pour l'autre.
>
>
> Le ven. 4 sept. 2020 à 17:01, Vincent de Château-Thierry 
> a écrit :
>
>> Bonjour,
>>
>> > De: "Philippe Verdy" 
>>
>> > Ce rappel était inutile. Ce sont deux objets de nature différente
>> > même s'ils ont le même nom mais pas la même fonction. Et ce
>> > "doublon" n'est pas gênant: si on crée une surface délimitée par un
>> > polygone, ce n'est pas un noeud de plus qui change la donne en terme
>> > de volumétrie et il n'y a pas d'ambiguité réelle.
>>
>> Dans t

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

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

Et même hors du rendu (par exemple pour les recherches) cela n'a pas de
conséquence: on trouve deux objets pratiquement au même endroit.

C'est similaire à d'autres objets où on tague les deux (y compris les
"labels" qui ont été utilisés et sont encore approuvés dans les relations
boundary même si on n'en a plus besoin pour les rendus les plus courants ni
pour les recherches pour les outils classiques comme Nominatim. Ce qui doit
être changé (ou corrigé) c'est ce que doivent faire les rendus au cas où
ils trouvent les deux objets (de type différents) au même endroit et la
façon dont ils gèrent les priorités d'affichage (car de toute façon ils
font toujours des choix, ils ont tous des filtres et ce sont ces filtres
qui sont à régler pour eux-mêmes, même si les autres rendus en ont encore
besoin puisqu'ils ne "voient" qu'une partie des objets).

Rien à voir donc avec "taguer pour le rendu", qui ne désigne que la façon
de **détourner** des tags prévus pour désigner tout autre chose a fin de
forcer un affichage. Ce n'est pas du tout le cas ici: les deux
méthodes sont approuvées. Et il n'a pas été décidé d'en déprécier l'une
pour l'autre.


Le ven. 4 sept. 2020 à 17:01, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> > De: "Philippe Verdy" 
>
> > Ce rappel était inutile. Ce sont deux objets de nature différente
> > même s'ils ont le même nom mais pas la même fonction. Et ce
> > "doublon" n'est pas gênant: si on crée une surface délimitée par un
> > polygone, ce n'est pas un noeud de plus qui change la donne en terme
> > de volumétrie et il n'y a pas d'ambiguité réelle.
>
> Dans ton précédent mail tu dis : "un point parking trouvé dans une surface
> parking" donc on parle bien de 2 objets décrivant la même réalité sur le
> terrain. Leur nature géométrique est différente mais ce sont bien des
> doublons sémantiques, chose qu'on cherche à éviter, cf le lien indiqué par
> Christian.
>
> > Et j'avais indiqué "de façon pragmatique". On sait qu'on a des
> > limites et qu'elles ne vont pas se régler tout de suite. Je préfère
> > nettement avoir deux objets (de nature différents mais positionnés
> > presque au même endroit, cela n'induit personne en erreur) que de
> > n'en voir aucun de façon aléatoire ou ne pas le trouver si on
> > cherche avec les outils qu'on a actuellement (en attendant qu'ils
> > soient corrigés).
>
> Le fait de "voir ou pas" les objets est de la responsabilité du logiciel
> qui les affiche, ça n'est pas au contenu lui-même de palier les limites des
> chartes graphiques. Sinon ça revient à tagguer pour le rendu.
>
> vincent
>
> ___
> 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] anomalie du serveur OSM sur iD (données partielles/incomplètes)

[Philippe Verdy]

Ce n'est toujours pas complètement réglé. Notamment des fournisseurs de DNS
sécurisés (dont bon nombre de services DNS over HTTPS qui perdent leurs
sessions et on beaucoup de mal à les reconencter) sont toujours impactés.

Le DNS over HTTPS (DOH) est proposé en ce moment en test par Google ou par
Microsoft sous Windows 10, mais visiblement il n'a pas encore la
capcité nécessaire de supporter le traffic nécessaire: les serveurs DOH
"tombent" les uns après les autres par surcharge (plus assez de ports TCP).
A mon avis le DOH est une mauvaise solution (à cause de l'utilisation de
TCP) et le plus fiable reste encore le DNS sur UDP qu'on peut authentifier
malgré tout avec les signatures numériques et les certificats PKI.

J'avais ausi repéré l'incident pas que chez Level3 mais aussi chez Cogent
(et sur certaines passerelles de Cogent vers l'Afrique transitant par
OpenTransit/Orange). Là encore il y a toujours un problème (et certains
pays africains sont encore quasi coupés du monde (il y a aussi des
problèmes ailleurs comme en Syrie ou Corée du Nord, mais là c'est beaucoup
plus lié aux mesures politiques, ou des mesures d'urgence dans la
cyberguerre qui se déroule en ce moment, que ce soit entre US et Chine, ou
Chine et Taiwan, et en fait pas tellement pour ce qui concerne la situation
politique locale, puisque même les groupes violents ou extrémistes ont
besoin de ces réseaux et ne les sabottent pas, bien au contraire, même
s'ils veulent en prendre le contrôle pour pouvoir les utiliser encore
davantage: les mesures prises le sont par leurs voisins).


Le ven. 4 sept. 2020 à 09:39, Christian Quest  a
écrit :

> Le 01/09/2020 à 13:33, Philippe Verdy a écrit :
> > oui ça remarche ce midi, hier soir l'internet était un enfer à
> > naviguer. (sauf les sites Google, et le reste était extrèmmeent lent,
> > surtout le DNS et presque tout ce qui transitait par les gros
> > datacenters d'Amsterdam)
>
>
> Tout ceci semble lié à une grosse panne chez Level3/CenturyLink, un gros
> fournisseur de tuyaux.
>
>
> https://www.nextinpact.com/lebrief/43434/une-panne-plusieurs-heures-chez-level3centurylink-fait-planter-partie-services-sur-internet
>
>
> La concentration d'internet dans toute sa splendeur :(
>
> --
> 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
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Philippe Verdy]

Le ven. 4 sept. 2020 à 09:38, Christian Quest  a
écrit :

> Le 01/09/2020 à 22:50, Philippe Verdy a écrit :
> > De façon pragmatique on peut admettre d'avoir simplement les deux (un
> > noeud et une surface)
>
> C'est une très mauvaise pratique, car cela crée 2 objets dans la base
> pour un seul sur le terrain.
>
> Petit rappel :
> https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element


Ce rappel était inutile. Ce sont deux objets de nature différente même
s'ils ont le même nom mais pas la même fonction. Et ce "doublon" n'est pas
gênant: si on crée une surface délimitée par un polygone, ce n'est pas un
noeud de plus qui change la donne en terme de volumétrie et il n'y a pas
d'ambiguité réelle.

Et j'avais indiqué "de façon pragmatique". On sait qu'on a des limites et
qu'elles ne vont pas se régler tout de suite. Je préfère nettement avoir
deux objets (de nature différents mais positionnés presque au même endroit,
cela n'induit personne en erreur) que de n'en voir aucun de façon aléatoire
ou ne pas le trouver si on cherche avec les outils qu'on a actuellement (en
attendant qu'ils soient corrigés).

Si la correction a lieu il sera toujours très facile plus tard de nettoyer
ces quelques "doublons", faciles à trouver en plus.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rond point et relations routes

[Philippe Verdy]

Notez quand même que nos giratoires à cédez le passage pour l'entrée ne
sont pas la règle partout. Le premier pays à avoir introduit des
giratoires, le Royaume-Uni, a la plupart de ses ronds-points avec
cédez-le-passage en sortie (la priorité à gauche classique, puisqu'ils
roulent à gauche, s'applique) Et dans de nombreux pays les giratoires (ils
en ont moins) sont souvent plus grands qu'en France et comportent des feux
(une minorité en France sauf aménagément particuliers pour voies de bus
centrale, ou dans les très grands ronds-points comme L'Etoile à Paris, où
les giratoires sont très peu nombreux).

D'une façon générale malgré tout (en Europe du moins) les mêmes règles
qu'en France s'appliquent le plus souvent. Il reste quelques pays
anglophones (GB et US notamment) qui ont un système à part. Aux US les rues
sont démesuréement larges, multivoies même avec peu de circulation,
rectilignes, et ils aiment les feux (suspendus sur câbles). Ils ne sentent
pas le besoin de développer des giratoires (qui sont mal compris ou qui
souvent ont des dispositions encore plus spéciales (comme les
"Turbo-roundabount" qu'on trouve dans les interconnexions de voies
majeures, masi qui donnent une plus grande priorité à certains sens de
circulation et certaines voies d'entrée ou de sortie au détriment des
autres où la traversée est plus compliquée).

Nos giratoires à la française sont relatiment simples dans leurs règles et
ne diffèrent en fait que la présence ou l'absence d'ilots séparateurs entre
voies d'entrée et de sortie, et le cas des connexion unidirectionnelles,
mais la même règle de cédez-le-passage à l'entrée et priorité aux véhicules
sur l'anneau (qui devraient avoir un clignotant à gauche pour indiquer
qu'ils ne sortent pas, mais là c'est peu appliqué en France et jamais
sanctionné non plus, pas plus que ceux qui grillent la priorité et ne
cèdent pas le passage en forçant leur entrée et faisant mine de n'avoir
rien vu).


Le ven. 4 sept. 2020 à 05:52, Gad Jo  a écrit :

> Si vous voulez je peu m'en occuper à minima pour les bonnes pratique en
> France.
>
> Le cas des giratoires à ne pas découper on le comprend mieux chez nous, le
> pays des rond point... On en a un nombre très important sans commune mesure
> avec celui qui est en deuxième position (info entendu sur le journal TV).
> Il est probable que dans les autres pays que le cas se présente rarement
> et que personne ne s'y est intéressé.
>
> Pour faire les modifications sur les pages EN faut il faire une demande de
> consensus via une page de discussions ? Quitte a passer sur l'hebdo osm
> pour stimuler les réponses
> Il me faut juste quelques conseils et je me lance
>
> Le September 3, 2020 2:38:45 PM UTC, Rpnpif via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>>
>> Le 01/09/2020 à 19:13, Georges Dutreix via Talk-fr a écrit :
>>
>> Bonjour,
>>
>> J'ai souvent découpé des giratoires pour des lignes de bus : honte sur
>> moi !
>> Promis, je ne le ferai plus ;-)
>>
>> Peut-être faudrait-il décrire les bonnes pratiques, pour les naïfs comme
>> moi, dans des pages comme https://wiki.openstreetmap.org/wiki/FR:Bus
>> ou
>> https://wiki.openstreetmap.org/wiki/FR:Relation:route#Les_itin.C3.A9raires_de_bus_et_les_ronds-points
>> ?
>>
>> Je ne maîtrise pas assez celles-ci pour m'amuser à modifier le wiki
>> moi-même. Et il semblerait qu'il n'y ait pas consensus...
>> Peut-on écrire par ci par là que la bonne pratique en France est de, si
>> possible, ne pas casser les rond points en plusieurs segments ?
>>
>>
>> +1 ! Tout à fait d'accord.
>> --
>> Rpnpif
>>
>
> --
> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [SDIS/SAMU] Projet du mois défibrillateurs

[Philippe Verdy]

Le jeu. 3 sept. 2020 à 20:35, Yves P.  a écrit :

>
> aucune donnée publique. pourtant ils invitent à déclarer les DAE par eux
>
>
> Comme Staying alive / AED-Map ;)
>
> A la différence près que ces données sont publiées dans data.gouv.fr
> 
>
>
> SauvLife ne traite que les agences publiques, il n'a forcément pas tous
> les DAE concernés par ces déclarations).
>
> D'où tiens-tu cette information ?
>

Leur page d'accueil qui ne mentionne que des structures
médico-hospitalières publiques. Les autres sont juste des "partenaires".
Rien n'est indiqué sur les procédures de controle, et leur formulaire en
ligne n'est pas fait pour tout le monde avec ce qui est demandé et il
manque de pas mal de précisions: en gros juste le nom de l'organisme,
l'adresse de l'établissement (adresse fiscale ou de gestion) et les noms,
numéros ou adresses de contacts, le reste c'est du champ libre facultatif.
Rien n'est demandé vraiment sur la localisation exacte, l'accessibilité
réelle n'est pas demandée, rien non plus sur l'entretien. Même pas la
possibilité de se géolocaliser précisément sur une carte. Rien non plus
pour identifier le matériel (et éviter les doublons possibles selon qui va
utilsier le formulaire, et pas grand chose pour justifier l'identité du
déclarant: pas de quoi justifier plus tard ses obligations légales, et rien
pour que les autres employés puissent contrôler que cela a bien été déclaré
et si les restrictions d'accès imposées ou les limites d'entretien sont
respectées ou valides).
En gros cela ne crée ni plus ni moins qu'un agenda privé (mais pas grand
chose n'est dit sur ce qu'ils vont faire réllement de ces données et quel
droit d'accès ou de rectification sera possible, visiblement ce n'est pas
au point pour le RGPD avec les professions libérales).
Efin SAUV met une licence exclusive par défaut à tout son site et se
réserve le droit d'utiliser comme il veut les données collectées. Il n'est
pas conforme au RGPD concernant les visiteurs du site. Que dire aussi de
leur appli mobile: j'ai plus confiance en celle de la Croix-Rouge française
(bien plus connue aussi et plus complète, téléchargée par près de 5
millions de français, et c'est déjà pas si mal même si cette appli peut
être améliorée en terme d'accessibilité).

Que dire aussi de l'appli mobile Sop-Coviv du gouvernement: c'est déjà dur
à trouver, elle est franchement pas simple à installer (quoi qu'en disent
Googgle et Apple sur leurs stores), elle bouffe énormément de batterie (il
faut la désactiver si on veut recharger son téléphone) et elle n'apporte
presque aucun service: quitte à la laisser allumée, autant que ce soit
intégré dans l'appli de la Croix-Rouge (avec les mêmes APIs développées en
commun par Google et Apple, une API sensée être ouverte et que ces OS
devraient optimiser un peu mieux: l'appli ou l'API commune bouffe plus
qu'une connexion Bluetooth à son autoradio ou à une oreillette sans fil)

>
> N'importe qui peut déclarer un DAE :
> https://sauvlife.fr/declarer-un-defibrillateur/
>
> Après, qui vérifie et comment, mystère ?
>
>
> Philips fabrique aussi des DAE et vend une prestation pour référencer des
> DAE à la place des exploitants :
> https://dae.philips.fr/services-philips/localisation-defibrillateur
>
> "La prestation de « Géolocalisation d’un DAE » de Philips permet de
> collecter et d’enregistrer les données d’un défibrillateur dans 1 ou 2
> bases de données que vous choisissez, pour votre compte."
>
> Ils parlent de GeoDAE, de AEDMAP, de Sauv life ?
>
>
> En quoi aussi l'asso SauvLife aurait plus d'habilitations qu'OSM
>
>
>
>- Elle est dirigée par des médecins urgentistes ;)
>- Elle a un partenariat avec des SAMU.
>- N'importe qui peut modifier les données OSM, ça ne doit pas rassurer
>:D
>
>
>
> GeoDAE peut-il alors accepter les contributions d'OSM si on arrive à les
> qualifier
>
>
> Bonne question.
>
>
> Même s'ils remontent des infos à GeoDAE;
>
>
> Est-ce que c'est bien le cas ?
>
>
> __
> Yves
> ___
> 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

[Philippe Verdy]

Le jeu. 3 sept. 2020 à 20:48, Francois Gouget  a écrit :

> On Thu, 3 Sep 2020, Philippe Verdy wrote:
>
> > la puissance transportée,
>
> La puissance transportée dépend de si le sèche-cheveux est allumé ou
> éteint.
>

Je voulait dire en capacité maximale (donc "transportable" plus que
"transportée" à un instant T: ca dépend des câbles, des isolateurs, du
champ électrique (tension/écartement et un facteur dépendant du nombre de
phases ou du différentiel avec la terre ou des écarts de puissance acceptés
entre les phases, et les tolérances sur le déphasage dépendant de la
puissance sur de chaque circuit et des points de consommation), de la
capacité aussi des transformateurs (et leur refroidissement) et ce qui est
toléré par les coupe-circuits près des postes de transformation et de
distribution ou des transfos relais (même sans changement de tension).
C'est à cause de ça que les porteurs sont aussi différents en taille et en
hauteur.

>
> > le nombre de câbles,
>
> 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. Ca dépend beaucoup du fond (y compris la
saison), et de la précision et l'éclairage des photos. On peut parfois
devenir sur certains poteaux ou segments, mais ça se complique vite
quand il y a des ramifications (et on ne voit pas bien toutes les
ramifications du réseau mineur). Et de toute façon pas moyen de deviner les
tensions transportées et le mode (nombre de phases ou continu à certains
endroits)

Les transfos sont également pas faciles à voir (et pas toujours montés en
haut des poteaux, j'en ai vu à plusieurs centaines de mètres du dernier
poteau quand la ligne passe sous-terre et ce transfo est souvent caché dans
la végétation ou dans des constructions agricoles ou industrielles ou
parfois enterré sous une trappe difficile à voir (ou dans une armoire
difficile à distinguer d'une armoire télécoms; ces transfos de distribution
ne sont souvent pas bien grands et sur l'imagerie aérienne on ne peut même
pas savoir que c'en est ou si c'est un engin agricole, un puits.)

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.

Sinon si j'ai des doutes, tant pis je ne relie pas: ces segments
déconnectés seront détectés et joints plus tard quand on aura plus de
données, mais ça indique justement le lieu où on a un manque d'information
et ça guide ensuite l'exploration au sol pus tard en fixant des objectifs à
voir auxquels on ne penserait pas.


> > la hauteur des poteaux ou leur nature (bois ou métallique)
>
> Ou béton. Ça on peut le voir sur les photos Mapillary / OpenStreetCam
> quand il y en a. Je me demande si c'est une caractéristique régionale ou
> si c'est une question d'époque.
>

 Oui aussi. Les poteaux en bois sont sans doute plus courants dans les
régions forestières. L'alu coûte cher et pas forcément non plus plus
résistant dans les régions venteuses ou pas accepté dans certains
secteurs protégés (en plus les poteaux en alu doivent être "chapeautés"
mais les chapeaux en plastique ne résistent souvent pas longtemp).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr