Re: [OSM-talk-fr] la voie verte fantôme

[marc marc]

> Le 8 janv. 2020 à 08:57, Arnaud Champollion 
>  a écrit :
> 
> Est-il envisageable de supprimer purement et simplement ces chemins ?

Si cela ne correspond à rien et que le contributeur fautif ne corrige pas, il 
faut évidement le supprimer.
Si le contributeur recommence, signale le au DWG
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adresse mail rejetée

[Jacques Lavignotte]

Le 08/01/2020 à 00:04, Christian Quest a écrit :


Certes, mais ceci devrait arriver sur toutes les ML...


J'ai une machine avec Mailman qui héberge quelques listes moyennement 
actives et cela arrive parfois.


Les explications données par marc² sont celles qui ressortent le plus 
souvent quand on cherche un peu sur le oueb.



J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
On mangera ? (c) (tm)


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

Re: [OSM-talk-fr] SPAM, Re: la voie verte fantôme

[Arnaud Champollion]

Le 08/01/2020 à 09:02, marc marc a écrit :

Si cela ne correspond à rien et que le contributeur fautif ne corrige pas, il 
faut évidement le supprimer.


J'ai laissé un énième message :

https://www.openstreetmap.org/changeset/63530919

On laisse encore quelques jours le temps de réagir.



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

Re: [OSM-talk-fr] SPAM, Re: la voie verte fantôme

[Vincent Bergeot]

Le 08/01/2020 à 09:59, Arnaud Champollion a écrit :

Le 08/01/2020 à 09:02, marc marc a écrit :
Si cela ne correspond à rien et que le contributeur fautif ne corrige 
pas, il faut évidement le supprimer.


J'ai laissé un énième message :

https://www.openstreetmap.org/changeset/63530919

On laisse encore quelques jours le temps de réagir.


il y a eu un échange il y a un moment déjà 
http://gis.19327.n8.nabble.com/Changesets-etranges-td5925067.html


donc pas forcément besoin d'attendre trop longtemps à mon avis

--
Vincent Bergeot


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

Re: [OSM-talk-fr] la voie verte fantôme

[Philippe Verdy]

Ca ressemble à un tracé pour un projet asso local, mais utilisant OSM et
ses outils de rendus pour dessiner la carte de ce projet au lieu de faire
un snapshot et créer une carte dérivée avec un outil graphique, ou de créer
une carte perso par un outil en utiliasnt OSM comme carte de fond sur
lequel on peut ajouter des tracés perso.
il faudrait informer l'auteur de l'existence de tels outils tiers, mais
peut-être qu'on oublie d'en faire la promotion, il y en a des tas, tout ce
qui est "projet" plus ou moins motivé par certains mais pas reconnu
publiquement n'a pas vocation à être dans OSM.

Si quelqu'un veut faire un plan perso pour indiquer le chemin pour ses
invités dans une fête d'un soir, ou si une asso locale veut faire un
vide-grenier et marquer la zone réservée et les parkings, il y a d'autres
solutions que directement dans OSM avec la grosse artillerie. Même choise
pour tout itinéraire perso qu'on pourrait préférer (il y a des outils dans
les applis en ligne de recherche d'itinéraire, où on peut ajouter les
points préférés pour des parcours alternatifs, et la possibilité de
conserver ça dans son compte perso. C'est même plus simple, plus rapide,
utilisable de façon privée, sans gêner tout les autres. Des projets il y en
a partout, peu aboutissent, plein sont changés en cours de discussion et
même en version finalisée.

Et quand on voit ce chemin ce n'est rien d'autre qu'un tracé sommaire à
main levée le long de la route existante pour la "surligner" graphiquement.
Ce qui aurait été fait avec une simple capture d'écran au zoom approprié et
trois coups de pinceau dans un éditeur graphique. Et en utilisation privée
ou dans des communications interpersonnelles, même pas besoin
d'attribution. En revanche une attribution nécessaire pour les captures
utilisées si on veut poster ça publiquement dans un réseau social qui le
diffusera à plein de monde si la carte est très détaillée et pas un simple
fond secondaire par apport aux mentions ajoutées qui occupent et
surchargent le reste ou si la capture est de résolution faible (pas
beaucoup plus que 400x300 pixels ou peu d'éléments OSM affichés en
arrière-plan, comparativement au rendu de ce qui a été ajouté en surcharge
par dessus avec une forte mise en évidence comme des traits très épais, du
texte ajouté dans des cartouches ou en caractères très gras)...

En revanche faire des modifs dans OSM pour les publier pour tout le monde,
c'est comme faire de la pub sous forme de spam, en imposant la vue sur la
carte à tout le monde. Les "projets" non actés par des travaux et des plans
déjà décidés et des chantiers déjà commencés n'ont pas leur place dans OSM.
Les vrais chantiers en revanche sont utiles pendant assez longtemps pour
savoir qu'il sont là et modifient de façon durable le terrain, le tracé
peut rester approximatif en attendant de voir le résultat final qui aura
lieu, mais OSM permet de taguer spécifiquement ces travaux et les rendus
font la distinction pour ne tromper personne: au minimum les avoir permet
d'indiquer l'équivalent de barrières et d'une zone interdite au public
pendant un temps prolongé, donc il faudra passer ailleurs ou contourner.

Si une perturbation locale dure moins d'un jour et si rien n'est changé
dans les conditions de circulation hors de courtes périodes spécifiques
imprévisibles, on ne met rien (pas plus qu'on ne cartographie dans OSM
chacun des accidents de la route; ceci existe dans des bases spécifiques de
relevés d'accidents). On ne met pas non plus les trajets d'une flotte
spécifique de véhicules privés, ni le parcours de chaque cycliste ou club
cycliste local, ou chaque course annuelle (dont le parcours peut changer
chaque année, comme les étapes du Tour de France et le détail
d'installation des villages départ et d'arrivée, ou chaque podium
temporaire, ou chaque zone de tournage de film/séries et l'emplacement du
camion buvette, ni chaque zone de stationnement réservée quelques heures
pour un déménagement avec des panneaux temporaires signés de la mairie).
Pour OSM, ce quj'on met doit durer au moins un mois ou se renouveler à date
prévue longtemps à l'avance avec quelques éléments installés gardés de
façon fixe (exemple: des points d'amarrage ou appuis pour le montage de
tribunes, des cabines de raccordement aux réseaux d'eau ou d'énergie, des
espaces de stockage à proximité, des barrières laissées ouvertes le reste
de l'année, des trous bétonnés dans la chaussée pour y installer facilement
des plots-barrières).

Le mer. 8 janv. 2020 à 08:57, Arnaud Champollion <
arnaud.champoll...@linux-alpes.org> a écrit :

> Bonjour,
>
> Dans le bassin dignois nous avons des contributions "fantômes".
>
> Parmi celles-ci : la "voie verte utile", exemple :
>
> https://www.openstreetmap.org/way/634099209#map=18/44.04107/6.04247
>
> C'est taggué comme une piste cyclable existante, nommé "voie verte
> utile", mais :
>
> - ça ne correspond à rien sur le terrain
>
> - ça ne correspond à aucun chantier en cours
>
> - ça ne correspond à aucun proje

Re: [OSM-talk-fr] la voie verte fantôme

[Jean-Christophe Becquet]

Le 08/01/2020 10:30, Philippe Verdy a écrit :
> Ca ressemble à un tracé pour un projet asso local, mais utilisant OSM et
> ses outils de rendus pour dessiner la carte de ce projet au lieu de
> faire un snapshot et créer une carte dérivée avec un outil graphique, ou
> de créer une carte perso par un outil en utiliasnt OSM comme carte de
> fond sur lequel on peut ajouter des tracés perso.
>
> En revanche faire des modifs dans OSM pour les publier pour tout le
> monde, c'est comme faire de la pub sous forme de spam, en imposant la
> vue sur la carte à tout le monde.

Bonjour,

Je peux me tromper mais j'ai l'impression qu'on est bien ici dans une
démarche de spam volontaire de la base de données pour faire apparaître
sur les rendus des aménagements qui n'existent pas sur le terrain et ne
correspondent qu'à des revendications de l'usager concerné.

Bonne journée

JCB
-- 
Bonne année 2020 !
APITUX : vos cartes personnalisées avec OpenStreetMap
http://www.apitux.org/index.php?2020/01/08/257-voeux-2020

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
2 chemin du Tivoli - 04000 Digne-les-Bains
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[Yves P.]

@Marc
>> si on ne connait pas la ref:* à mettre, on peut mettre ref
> 
> bien évidemment. mais elle serra invisible pour ceux qui ciblent les 
> ref:FR:xxx
Est-ce vraiment un problème ? Ces clés ne sont pas nécessaires selon toi ;-)

>> Les intérêts sont de lier l’objet OSM à un objet dans une base de donnée 
>> externe.
> 
> c'est tout autant lié avec ref
C’est là que ça se complique : pour moi le lien est « physique », on peut 
cliquer est arriver à l’objet en question.
Pour cela on a Tag2Link dans JOSM, et ces règles sont assez souples pour 
générer un lien à partir de plusieurs clés/valeurs.

Mais (à part Osmose) le principe n’a pas été repris dans d’autres logiciels, 
notamment le site web d’OSM.

Si de plus il manque une clé annexe, le lien n’est pas générer…

Avec des références « précises » comme par exemple ref:wmo ou ref:wigos, on 
sait construire le lien hypertexte sans ambiguïté.
Et ça fonctionne pour un radar météo, une station météo…

radar météo :
• man_made=tower
• tower:type=radar
• tower:construction=dome

station météo :
• man_made=monitoring_station
• monitoring:weather=yes

>>  * pour un objet qui a plusieurs références, de les différencier.
> 
> hors France, il y a aussi des objets multi-référence (dont les routes)
> cela ne les empeches pas d'avoir comme règle de base d'utiliser ref
> et de préciser la clef quand il y a besoin et non comme règle de base
comment « précises » tu la clé ?

Dans le cas des marques nautiques (seamark:*), la clé seamark:reference qui a 
été créé.
A l’usage, elle contient un vrai bazar. Il est difficile de savoir de quel 
livre des feux on parle.
C’est pour cela quelle va progressivement disparaitre et sera remplacée par la 
clé ref:* dédiée.

> 
>>  * pour une machine (voir un humain), de savoir à quoi ça correspond.
>>Référence de l’opérateur, de la commune… ?
> 
> on fait pareil avec name ? remplacer par défaut name=truc
> par name:lenomdelentitiéquiadefinitlenom=truc ?
> c'est compréhensible de vouloir être précis mais c'est nuisible d'en
> faire un règle de clef par défaut.
La question n’est pas de savoir qui a définit le nom ou la référence, mais de 
pouvoir lier de manière fiable l’objet OSM et sa version dans une base de 
donnée externe.

D’un côté on dit que des données (notamment volatiles) n’ont rien à faire dans 
OSM, il faut donc pouvoir « pointer » facilement vers la base de données qui 
les stockent.
(Au passage, ça évite de dupliquer de l’info et les problèmes de mise à jour).

De l’autre, il ne faudrait pas créer de références précises… ??

De plus, à terme on pourra avoir une vérification des valeurs (cf. propriétés 
dans wikidata)

> 
> je pense qu'il n'est pas du rôle d'osm de devoir
> connaitre qui a définit la ref lisible sur plaque comme prérequis
> pour l'ajouter correctement dans osm.

> j'en reviens avec l'analogie des routes, on utilise ref pour la
> référence principale sans se soucier si la ref a été définie
> par la commune ou par le niveau national.
cf. supra.

> Et uniquement quand il y a plusieurs ref, on fait une règle
> pour les autres ref. idem pour les noms, idem pour tout.

Si je te suis bien, tu n’es pas opposé dans l’absolu à la création de ref:*…
Mais dans le cas précis de ref:ERDF:gdo, tu n’en vois pas l’utilité, la 
nécessité ?

A ma connaissance, on ne peut pas se servir de ref:ERDF:gdo pour pointer vers 
une base de données externe. (A moins que ERDF fasse ça en interne)
ça servira peut-être un jour à rapprocher les données ouvertes d'Enedis ?

J’ai fait une recherche dans TagInfo sur les objets ayant une clé ref et une 
clé ref:ERDF:gdo.
Il y a les pylônes qui ont leur numéro dans ref, et la référence de l’organe de 
coupure dans ref:ERDF:gdo.

Le plus souvent, ref sert à décrire ce qui est écrit sur le terrain, et 
ref:ERDF:gdo à transcrire cette information de manière complète et précise :
ref="70 159"
ref:ERDF:gdo="83070P0159"
Du coup, tant que l’étiquetage sur le terrain n’est pas normalisé, ce double 
étiquetage me parait nécessaire.

—
Yves


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

Re: [OSM-talk-fr] Sur utilisation non nécessaire des espaces de nom — Re: Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[Yves P.]

Bonjour,

Pour sortir du cas GDO et être plus général, on a le cas des photos.

La clé image est une sorte d’identifiant unique vers une données externe : une 
photo.
Certes on n’a pas eu la mauvaise idée de créer les clés image:mapillary, 
image:wikimedia_commons… mais le problème est assez similaire.

Cette clé devient un vrai souk :
On a des URL à rallonge, qui pointent parfois vers des imagettes dont il n’est 
pas trivial d’obtenir les métadonnées ou une version dans la définition 
d’origine.
Les valeurs mal recopiées sont inutilisables et difficiles à réparer.

Selon les logiciels, elles ne sont pas ou mal interprétées :
https://www.openstreetmap.org/way/30603750 (Pas de lien vers la photo décrite 
par la clé image)
https://www.openstreetmap.org/node/6512902996 (Lien depuis la clé 
wikimedia_commons)

Sur wikidata il est obligatoire de créer un nouvel identifiant, par contre il 
existe un mécanisme « souple » pour éviter que n’importe qui crée n’importe 
quoi et n’importe comment.

Sur OSM, rien de très clair.
La « régulation » se fait par des développeurs/administrateurs qui « refusent » 
de générer des liens vers des sites externes ;-D

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

[OSM-talk-fr] Limite numérique des identifiants de noeuds/ways OSRM

[François Lacombe]

Bonjour la liste

Est-ce que quelqu'un familier avec OSRM saurait me dire quelle est la
limite exacte pour les identifiants de nœuds et de chemins OSM?

Je remarque que ces identifiants ne dépassent pas 10 digits dans les
réponses fournies par l'API route.
On en est à 5700014039 de nœuds dans la base, le plafond va bientôt être
atteint.
La maintenance de ces derniers mois est au ralenti, fort à parier que ce ne
sera bientôt plus utilisable?

Perso je régénère des fichiers xml osm avec des identifiants 64 bits et ca
ne passe pas.

Preneur de vos commentaires, merci par avance

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

Re: [OSM-talk-fr] Limite numérique des identifiants de noeuds/ways OSRM

[Julien Coupey]

Bonjour François

OSRM supporte normalement sans problème les ids OSM sur 64 bits pour les 
nœuds depuis un moment[1]. Ce n'est pas le cas pour les ways (ids 
toujours sur 32 bits) mais a priori il y a de la marge si tu utilises 
les données OSM telles quelles.


> ca ne passe pas.

Si tu peux développer un peu sur ce qui coince, peut-être que ça vaut le 
coup d'ouvrir un ticket ?


[1] https://github.com/Project-OSRM/osrm-backend/pull/1793

À +
Julien

On 08/01/2020 11:19, François Lacombe wrote:

Bonjour la liste

Est-ce que quelqu'un familier avec OSRM saurait me dire quelle est la 
limite exacte pour les identifiants de nœuds et de chemins OSM?


Je remarque que ces identifiants ne dépassent pas 10 digits dans les 
réponses fournies par l'API route.
On en est à 5700014039 de nœuds dans la base, le plafond va bientôt être 
atteint.
La maintenance de ces derniers mois est au ralenti, fort à parier que ce 
ne sera bientôt plus utilisable?


Perso je régénère des fichiers xml osm avec des identifiants 64 bits et 
ca ne passe pas.


Preneur de vos commentaires, merci par avance

François

___
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] Abus de StephaneP : adresses FANTOIR

[Jérôme Seigneuret]

les place=square peut être adaptée mais en effet pas de le cas présent à
mon avis
On n'est pas sur un espace piéton et/ou il n'y a pas d'espaces verts

On n'est sur un parking ou et sur une place de marché
Le nom peut être portée sur le parking directement et le FANTOIR également

C'est bien une voie de service vue que l'on travers un parking sur une
place destiné principalement à cela les résidences derrières ne passe que
sur une voie d'accès.
Pour rappel on tag deux choses: des classes fonctionnelles et un usage de
la route. Dans le cas de figure c'est clairement pas un highway=residential

Une voie résidentielle est une voie majeur qui sert à transiter pour
accéder à d'autre résidence et dont des résidences donnent accès sur cette
voie directement. Ici on est sur un point final et les autres voies sont
des voies d'accès. Ici tu ne pourra même pas rouler à 50. Tu passes
d'ailleurs par un trottoir ... donc tu ne sera pas prioritaire à la sortie
même sans marquage.

Le FANTOIR n'est pas que sur des voies. Donc faut ce calmer sur les
questions de compréhension du code. On n'est plus à une erreur prêt de la
part de la des impôts. Le fait de matérialiser le ref:FR:FANTOIR permet de
faire la jonction sur d'autres objets qu'une voie et cela est bien normal.

Là il n'y a pas de question du terrain prime. C'est une question de simple
logique d'application et celle de Stéphane n'est pas incompatible pour
l'exploitation. La structure et l'exploitation du référentiel prime et
c'est ainsi qu'on fait une abstraction du terrain sans dénaturer ce que
l'on pourrait en comprendre et comment l'exploiter. Si la structure n'est
pas adaptée ou incomplète il suffit de la faire évoluer et c'est ainsi que
l'on dit que le terrain prime pas l'inverse. Sinon on se retrouve avec des
référentiel qui ne deviennent plus exploitable... Cela revient aussi à la
logique de "on ne tague pas pour le rendu". On adapte le rendu pour donner
une lecture des données saisie dans le référentiel on fonction de critères
exploitables.

Voilà donc mes préconisations:

On laisse les voies de service
place=plaza doit disparaître on n'est pas sur le bon usage
le parking récupère le nom et le FANTOIR ce qui est bien suffisant
Pas de relation car elle ne sert à rien
Le nom doit être mis sur le tag addr:street des adresses pour les résidences

A+ et bonne après midi





Le mer. 8 janv. 2020 à 01:11, Philippe Verdy  a écrit :

> Voir son commentaire:
> https://www.openstreetmap.org/changeset/79302148#map=19/47.08243/-1.33683
>
> Visiblement il n'a pas compris le FANTOIR et supprime les adresses et crée
> des trucs "à sa sauce".
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] hebdoOSM Nº 493 2019-12-24-2019-12-30

[theweekly . osm]

Bonjour,

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

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

Bonne lecture !

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

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

Re: [OSM-talk-fr] Limite numérique des identifiants de noeuds/ways OSRM

[François Lacombe]

Bonjour Julien,

Merci pour ta réponse, ça me rassure tout de même.
Pour les identifiants de ways, c'est moins problématique pour moi.

Ce qui ne passe pas, c'est que j'injecte un XML qui comporte des noeuds
identifiés avec
91220288029161
91220288025445
91220288026438

Et qui ressortent avec des identifiants tronqués à 10 digits (ce ne sont
pas les mêmes noeuds). En tout cas ces identifiants là ne sont pas présents
dans le .osm d'entrée.
1885473760
246430160
5846804688
737485280
8063904192

8063904192 étant déjà supérieur à la limite 32 bits, j'ai pensé à une
limitation à 10 digits

Une idée du problème ?

François

Le mer. 8 janv. 2020 à 11:41, Julien Coupey  a écrit :

> Bonjour François
>
> OSRM supporte normalement sans problème les ids OSM sur 64 bits pour les
> nœuds depuis un moment[1]. Ce n'est pas le cas pour les ways (ids
> toujours sur 32 bits) mais a priori il y a de la marge si tu utilises
> les données OSM telles quelles.
>
>  > ca ne passe pas.
>
> Si tu peux développer un peu sur ce qui coince, peut-être que ça vaut le
> coup d'ouvrir un ticket ?
>
> [1] https://github.com/Project-OSRM/osrm-backend/pull/1793
>
> À +
> Julien
>
> On 08/01/2020 11:19, François Lacombe wrote:
> > Bonjour la liste
> >
> > Est-ce que quelqu'un familier avec OSRM saurait me dire quelle est la
> > limite exacte pour les identifiants de nœuds et de chemins OSM?
> >
> > Je remarque que ces identifiants ne dépassent pas 10 digits dans les
> > réponses fournies par l'API route.
> > On en est à 5700014039 de nœuds dans la base, le plafond va bientôt être
> > atteint.
> > La maintenance de ces derniers mois est au ralenti, fort à parier que ce
> > ne sera bientôt plus utilisable?
> >
> > Perso je régénère des fichiers xml osm avec des identifiants 64 bits et
> > ca ne passe pas.
> >
> > Preneur de vos commentaires, merci par avance
> >
> > François
> >
> > ___
> > 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] adresse mail rejetée

[marc marc]

Le 08.01.20 à 08:53, ades a écrit :
> 
> je ne compte plus les messages de « bounced" depuis 1 ou 2 mois, je n’en 
> n’avais jamais avant… et mon adresse mail est tout ce qu’il y a de plus 
> simple, 'at orange', sans aucune redirection…

je sais que le sujet est complexe, mais il est important de comprendre
qu'il y a 2 groupes qui coexiste pour provoquer le problème :
- un groupe d'email d'expéditeur donc la config email n'est pas
classique (par exemple écrire avec une email wanadoo.fr comme expéditeur
en utilisant un compte gmail)
- un groupe d'email de destintaire donc la config email est "stricte"

quand l'email d'un expéditeur en question arrive à un des destinataire
en question, le serveur de celui-ci la rejette (message 550 spam detecte
dans le cas de free.fr)
quand le gestionnaire de la liste recoint trop de rejet, il désinscrit
le(s) destintaire(s) en question, quand bien même c'est pas leur faute
si l'expéditeur "pas classique" continue
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Bonjour Marc,

Je suis d'accord avec Yves ici
Ce n'est pas parce qu'un objet ne porte qu'une référence, qu'on ne peut pas
associer des règles de validation ou de formatage particulières sur
celle-ci.
Plus que les tags de l'objet et le contexte d'utilisation de ref=*, il faut
une clé dédiée à laquelle on associe une doc complète et des règles dans
les éditeurs.

Même si certaines fois l'exploitant est repris dans le nom de la ref
(ref:FR:Orange par exemple), ce n'est pas le but de déterminer l'exploitant
avec la ref;
Nous n'avons pas le droit de reprendre systématiquement le nom du
référentiel à cause de la propriété intellectuelle, donc on utilise la
marque à la place qui correspond au nom de l'exploitant.

Je serai bien embêté si il fallait exprimer sur la même page les règles
pour ref:FR:gdo et ref:FR:FINESS. Ce n'est pas du tout la même chose, ce
serait éminemment plus complexe à valider aussi.

Voir aussi les objets qui portent plusieurs ref : ref:FR:ARCEP +
ref:FR:Orange (avoir ref + ref:FR:Orange n'a pas plus de sens que
ref:FR:ARCEP + ref)

On utilise enfin les namespaces parce que ces règles, concepts et
référentiels sont spécifiques à la France et peuvent collisionner ailleurs
dans le monde.

Le mar. 7 janv. 2020 à 16:20, marc marc  a
écrit :

> Bonjour,
>
> Le 07.01.20 à 16:01, Quentin Salles a écrit :
> > Pouvez-vous me confirmer que l'usage de la clé "ref:FR:gdo" est bien
> actif ?
>
> Nous n'avions pas terminé la discussion sur la migration.
> Je te conseille d'utiliser l'ancienne clef en attendant, puisque
> c'est elle qui est la façon de faire actuellement.
>

Je n'ai pas fait la migration, pour l'ancienne clé reste valable.
Y a-t-il d'autres points à discuter ?


> je vais faire une comparaison avec les routes :
> en lisant une référence sur le panneau d'une route, cette référence
> se retranscrit dans la clef ref=numéro et ceci indépendamment de
> l'opérateur ou du pays.
>

Parce qu'on traduit avant tout ce qu'on lit sur le terrain sans chercher à
la rapprocher d'un référentiel quelconque.


> on n'utilise pas non plus d'espace de nom du genre ref:FR:auteur
> pour préciser qui serrait l'auteur de la ref.
> on n'utilise pas non plus de mot dans la clef pour donner le sens de
> cette référence ou le terme légal que celui-ci aurait dans la loi.
>

Et on pourrait, mais le domaine routier n'est pas le meilleur pour produire
des référentiel, je ne connais pas le nom de la base de données qui
attribue les numéros de routes.


> A l'inverse, dans le domaine énergétique (et des transports), au fil
> du temps, on utilise des espaces de nom pour la clef ref en France,
> sans que je perçoive ni le besoin ni même l'intérêt.
>
> Au final l'utilisateur qui lit une ref quelque part, ne peux pas
> l'ajouter dans osm sans devoir chercher dans le wiki quel est la règle
> particulière qui régit cet objet dans ce pays.
>

C'est nécessaire parce qu'on a besoin de formater cette valeur par rapport
à ce qui est lu sur le terrain : infos incohérentes, valeurs partiellement
effacées, techniciens fatigués...


> cela nuit à mon avis grandement à l'encodage simple et même à
> l'utilisation (essayez donc de connaître le nombre de power=substation
> au niveau mondial qui ont une ref, vous devez écrire une règle qui dit
> que cela peux être ref ou ref:* chose que de nombreux outil tel que
> tainfo ou overpass ne permettent pas ou pas facilement)
>
> > Est-il possible de remonter l'information
> > via l'Open data. Si oui, est-il permis d'ajouter ces informations non
> > visibles sur le terrain ?
>
> bien sur, osmose ne propose rien sur le sujet ?
> https://osmose.openstreetmap.fr/fr/map/


Pas encore mais la migration va être l'occasion d'ajouter de la validation
dans JOSM et Osmose quand j'aurais le temps de m'en occuper.
* substation=minor_distribution + operator=Enedis + ref=* => Alerte, il
manque ref:FR:gdo
* operator!=Enedis;GRDF + ref:FR:gdo => Alerte, ce n'est pas possible

Et ainsi de suite

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

Re: [OSM-talk-fr] adresse mail rejetée

[Vincent de Château-Thierry]

Bonjour,

Le 08/01/2020 à 13:32, marc marc a écrit :

Le 08.01.20 à 08:53, ades a écrit :


je ne compte plus les messages de « bounced" depuis 1 ou 2 mois, je n’en 
n’avais jamais avant… et mon adresse mail est tout ce qu’il y a de plus simple, 'at 
orange', sans aucune redirection…


je sais que le sujet est complexe, mais il est important de comprendre
qu'il y a 2 groupes qui coexiste pour provoquer le problème :
- un groupe d'email d'expéditeur donc la config email n'est pas
classique (par exemple écrire avec une email wanadoo.fr comme expéditeur
en utilisant un compte gmail)
- un groupe d'email de destintaire donc la config email est "stricte"

quand l'email d'un expéditeur en question arrive à un des destinataire
en question, le serveur de celui-ci la rejette (message 550 spam detecte
dans le cas de free.fr)
quand le gestionnaire de la liste recoint trop de rejet, il désinscrit
le(s) destintaire(s) en question, quand bien même c'est pas leur faute
si l'expéditeur "pas classique" continue


Ce message est pour Philippe Verdy, dont je peux plus lire les mails 
depuis longtemps, mes adresses mail étant chez free.fr et laposte.net, 
tous deux fournisseurs 'stricts'.


Philippe, comme te l'as rappelé Marc ce matin ici :

https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/096123.html

tu continues d'envoyer tes messages avec une adresse en wanadoo.fr. 
Peux-tu une fois pour toutes utiliser une autre adresse, par exemple ton 
adresse @gmail, pour poster, et sans mécanisme de renommage en adresse 
wanadoo.fr, qui pose problème à beaucoup de monde ici pour suivre 
normalement les discussions.


merci
vincent

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

Re: [OSM-talk-fr] adresse mail rejetée - expéditeur wanadoo.fr via gmail pour destintaire free gmail laposte et autres

[marc marc]

Le 08.01.20 à 01:28, Philippe Verdy a écrit :
> Pour ceux auxquels je réponds
je redis :
même les NOUVEAUX messages que TU écris, TOUS sont en @wanadoo
comme par exemple ton email avec le sujet communes-communautés.

Je réitère ma demande de cesser d'envoyer à la liste
TOUT emails expéditeur @wanadoo.fr via les serveurs email de gmail.

Même si gmail le permet, gmail free laposte et d'autres serveurs
sont irrité par cette technique courante de spam, ce qui provoque
des nuissances collectives importantes.

> Le mar. 7 janv. 2020 à 21:56, marc marc a écrit :
> 
> Philippe ce n'est pas le cas, tous tes emails
> sont en verd...@wanadoo.fr , ci dessous
> les entêtes de celui auquel je répond.
> 
> j'ai aussi mis en dessous le nouveau thread
> que tu as créés aujourd'hui.
> 
> Je te sugère de désabonner l'email wanadoo
> pour ne garder que l'abo en gmail.com 
> ansi le problème cessera de lui-même.
> 
> Philippe Verdy a écrit :
>> Pour les nouveaux messages à la liste, 
>> j'envoie maintenant avec mon adresse Gmail
> 
>  Message transféré 
> Sujet :         [OSM-talk-fr] communes-communautés
> Date :  Tue, 7 Jan 2020 19:08:33 +0100
> De :    Philippe Verdy mailto:verd...@wanadoo.fr>>

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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[Quentin Salles]

Bonjour,

Pour l'instant, je vais rester sur le tag actuel, à savoir "ref:FR:ERDF".
Et je complèterai par "ref" pour l'information que je vois sur le terrain.
Osmose signalé bien les élements manquants, mais aucun identifiant ou même
nom n'est indiqué. Serait-il possible d'avoir l'identifiant en OpenData ?
Concernant le gaz, me donner vous l'autorisation de compléter la page Wiki
OSM "ref:FR:gdo" ?

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

Re: [OSM-talk-fr] Limite numérique des identifiants de noeuds/ways OSRM

[Julien Coupey]

Re

Si tu récupères en sortie (dans l'objet `annotation.nodes` d'une route) 
des ids de nœuds qui ne sont pas dans les données d'entrée, alors c'est 
un bug, même si ça n'a apparemment pas de lien avec le fait que les 
valeurs soient supérieures à 2^32.


Ça vaudrait certainement le coup d'ouvrir un ticket avec un exemple 
minimal pour reproduire. C'est peut-être ça le plus compliqué dans ton 
cas car tu sembles utiliser des nœuds renumérotés à la main. Peut-être 
réduire l'extrait OSM à un simple way composé de nœuds problématiques 
pour pouvoir le fournir ?


À +
Julien

On 08/01/2020 12:29, François Lacombe wrote:

Bonjour Julien,

Merci pour ta réponse, ça me rassure tout de même.
Pour les identifiants de ways, c'est moins problématique pour moi.

Ce qui ne passe pas, c'est que j'injecte un XML qui comporte des noeuds 
identifiés avec

91220288029161
91220288025445
91220288026438

Et qui ressortent avec des identifiants tronqués à 10 digits (ce ne sont 
pas les mêmes noeuds). En tout cas ces identifiants là ne sont pas 
présents dans le .osm d'entrée.

1885473760
246430160
5846804688
737485280
8063904192

8063904192 étant déjà supérieur à la limite 32 bits, j'ai pensé à une 
limitation à 10 digits


Une idée du problème ?

François

Le mer. 8 janv. 2020 à 11:41, Julien Coupey > a écrit :


Bonjour François

OSRM supporte normalement sans problème les ids OSM sur 64 bits pour
les
nœuds depuis un moment[1]. Ce n'est pas le cas pour les ways (ids
toujours sur 32 bits) mais a priori il y a de la marge si tu utilises
les données OSM telles quelles.

  > ca ne passe pas.

Si tu peux développer un peu sur ce qui coince, peut-être que ça
vaut le
coup d'ouvrir un ticket ?

[1] https://github.com/Project-OSRM/osrm-backend/pull/1793

À +
Julien

On 08/01/2020 11:19, François Lacombe wrote:
 > Bonjour la liste
 >
 > Est-ce que quelqu'un familier avec OSRM saurait me dire quelle
est la
 > limite exacte pour les identifiants de nœuds et de chemins OSM?
 >
 > Je remarque que ces identifiants ne dépassent pas 10 digits dans les
 > réponses fournies par l'API route.
 > On en est à 5700014039 de nœuds dans la base, le plafond va
bientôt être
 > atteint.
 > La maintenance de ces derniers mois est au ralenti, fort à parier
que ce
 > ne sera bientôt plus utilisable?
 >
 > Perso je régénère des fichiers xml osm avec des identifiants 64
bits et
 > ca ne passe pas.
 >
 > Preneur de vos commentaires, merci par avance
 >
 > François
 >
 > ___
 > 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

[OSM-talk-fr] Manque de l'attribution OSM

[emeric Prouteau]

Bonjour tout le monde,

Je viens d'envoyer un message au journal reporterre car sur la carte
suivante je n'ai pas trouvé de mentions légales concernant openstreetmap

https://superlocal.team/?s=lemouvement

Bonne journée,

-- 
*Emeric PROUTEAU*



*emeric.prout...@gmail.com Avant d'imprimer.
Pensons à l'environnement.Save paper. Do you really need to print this
e-mail?*
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Manque de l'attribution OSM

[David Marchal]

Étrange, vu le profil éditorial de Reporterre, plutôt antilibéral et 
communautaire. Mais bien vu, Émeric !

Cordialement.

Le 8 janv. 2020 à 16:46, emeric Prouteau 
mailto:emeric.prout...@gmail.com>> a écrit :

Bonjour tout le monde,

Je viens d'envoyer un message au journal reporterre car sur la carte suivante 
je n'ai pas trouvé de mentions légales concernant openstreetmap

https://superlocal.team/?s=lemouvement

Bonne journée,

--
Emeric PROUTEAU
emeric.prout...@gmail.com

Avant d'imprimer. Pensons à l'environnement.
Save paper. Do you really need to print this e-mail?
___
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] Limite numérique des identifiants de noeuds/ways OSRM

[François Lacombe]

Merci Julien, je vais essayer de fournir un fichier de ce style là pour une
issue
Effectivement je pense que c'est un bug aussi

Sais-tu si l'équipe les traite encore?
Les derniers essais que j'ai fait n'ont pas obtenus de réponse.

Bonne soirée :)

François

Le mer. 8 janv. 2020 à 16:06, Julien Coupey  a écrit :

> Re
>
> Si tu récupères en sortie (dans l'objet `annotation.nodes` d'une route)
> des ids de nœuds qui ne sont pas dans les données d'entrée, alors c'est
> un bug, même si ça n'a apparemment pas de lien avec le fait que les
> valeurs soient supérieures à 2^32.
>
> Ça vaudrait certainement le coup d'ouvrir un ticket avec un exemple
> minimal pour reproduire. C'est peut-être ça le plus compliqué dans ton
> cas car tu sembles utiliser des nœuds renumérotés à la main. Peut-être
> réduire l'extrait OSM à un simple way composé de nœuds problématiques
> pour pouvoir le fournir ?
>
> À +
> Julien
>
> On 08/01/2020 12:29, François Lacombe wrote:
> > Bonjour Julien,
> >
> > Merci pour ta réponse, ça me rassure tout de même.
> > Pour les identifiants de ways, c'est moins problématique pour moi.
> >
> > Ce qui ne passe pas, c'est que j'injecte un XML qui comporte des noeuds
> > identifiés avec
> > 91220288029161
> > 91220288025445
> > 91220288026438
> >
> > Et qui ressortent avec des identifiants tronqués à 10 digits (ce ne sont
> > pas les mêmes noeuds). En tout cas ces identifiants là ne sont pas
> > présents dans le .osm d'entrée.
> > 1885473760
> > 246430160
> > 5846804688
> > 737485280
> > 8063904192
> >
> > 8063904192 étant déjà supérieur à la limite 32 bits, j'ai pensé à une
> > limitation à 10 digits
> >
> > Une idée du problème ?
> >
> > François
> >
> > Le mer. 8 janv. 2020 à 11:41, Julien Coupey  > > a écrit :
> >
> > Bonjour François
> >
> > OSRM supporte normalement sans problème les ids OSM sur 64 bits pour
> > les
> > nœuds depuis un moment[1]. Ce n'est pas le cas pour les ways (ids
> > toujours sur 32 bits) mais a priori il y a de la marge si tu utilises
> > les données OSM telles quelles.
> >
> >   > ca ne passe pas.
> >
> > Si tu peux développer un peu sur ce qui coince, peut-être que ça
> > vaut le
> > coup d'ouvrir un ticket ?
> >
> > [1] https://github.com/Project-OSRM/osrm-backend/pull/1793
> >
> > À +
> > Julien
> >
> > On 08/01/2020 11:19, François Lacombe wrote:
> >  > Bonjour la liste
> >  >
> >  > Est-ce que quelqu'un familier avec OSRM saurait me dire quelle
> > est la
> >  > limite exacte pour les identifiants de nœuds et de chemins OSM?
> >  >
> >  > Je remarque que ces identifiants ne dépassent pas 10 digits dans
> les
> >  > réponses fournies par l'API route.
> >  > On en est à 5700014039 de nœuds dans la base, le plafond va
> > bientôt être
> >  > atteint.
> >  > La maintenance de ces derniers mois est au ralenti, fort à parier
> > que ce
> >  > ne sera bientôt plus utilisable?
> >  >
> >  > Perso je régénère des fichiers xml osm avec des identifiants 64
> > bits et
> >  > ca ne passe pas.
> >  >
> >  > Preneur de vos commentaires, merci par avance
> >  >
> >  > François
> >  >
> >  > ___
> >  > 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Abus de StephaneP : adresses FANTOIR

[Stéphane Péneau]

Bonsoir Jérôme,

Le 08/01/2020 à 12:16, Jérôme Seigneuret a écrit :
les place=square peut être adaptée mais en effet pas de le cas présent 
à mon avis

On n'est pas sur un espace piéton et/ou il n'y a pas d'espaces verts

Je ne comprends pas. Je ne vois rien sur le wiki qui indique qu'un 
place=square doit être piéton et/ou avec des espaces verts. C'est même 
plutôt le contraire, que ce soit sur la version anglaise ou française.

https://wiki.openstreetmap.org/wiki/Tag:place%3Dsquare


On n'est sur un parking ou et sur une place de marché
Le nom peut être portée sur le parking directement et le FANTOIR également

Comme la géométrie n'est pas identique, et que j'ai tendance à penser 
que les détails augmentent avec le temps, je trouve que ce n'est pas 
pertinent de supprimer l'un au profit de l'autre. Mais bon, ça se discute.


A+

Stf


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

Re: [OSM-talk-fr] Abus de StephaneP : adresses FANTOIR

[Jérôme Seigneuret]

Le square tel qu'il est défini est en effet ambigu. Je trouve que la
définition sur wikipedia est nettement plus claire et celle d'OSM devrait
avoir une révision...  https://fr.wikipedia.org/wiki/Square_(lieu)

Même si la géométrie n'est pas identique ce n'est pas adaptée à ta
situation. Historiquement les square avait un usage fonctionnel qui est
devenu un espace de détente et de rencontre d'où le fait de dire que c'est
là plus part du temps piéton. Les routes encadre le square ou le recoupe en
plusieurs carré.

Le square est vraiment un type de lieu particulier.
Voilà pourquoi j'ai proposé d'adapter ta contribution

A+
Bonne soirée

Le mer. 8 janv. 2020 à 20:39, Stéphane Péneau 
a écrit :

> Bonsoir Jérôme,
>
> Le 08/01/2020 à 12:16, Jérôme Seigneuret a écrit :
> > les place=square peut être adaptée mais en effet pas de le cas présent
> > à mon avis
> > On n'est pas sur un espace piéton et/ou il n'y a pas d'espaces verts
> >
> Je ne comprends pas. Je ne vois rien sur le wiki qui indique qu'un
> place=square doit être piéton et/ou avec des espaces verts. C'est même
> plutôt le contraire, que ce soit sur la version anglaise ou française.
> https://wiki.openstreetmap.org/wiki/Tag:place%3Dsquare
>
> > On n'est sur un parking ou et sur une place de marché
> > Le nom peut être portée sur le parking directement et le FANTOIR
> également
> >
> Comme la géométrie n'est pas identique, et que j'ai tendance à penser
> que les détails augmentent avec le temps, je trouve que ce n'est pas
> pertinent de supprimer l'un au profit de l'autre. Mais bon, ça se discute.
>
> A+
>
> Stf
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adresse mail rejetée

[Philippe Verdy]

Je ne peux pas changer l'adresse d'émetteur quand je réponds avec Gmail (là
où je reçois tous les messages) à un message qui mentionne mon adresse
Wanadoo.fr (toujours valide) qui est aussi authentifiée et associée à mon
compte Google (Orange a aussi authentifié mon adresse Gmail). Je ne peux
choisir mon email que lors d'un envoi de nouveau message (pas par "Répondre
à" ou "Répondre à tous). Si je réponds en créant un nouverau message, il
n'y a plus le "message ID" qui permet d'identifier un fil de discussion et
grouper les réponses.

Le problème ce sont les serveurs d'Orange qui ne sont pas conformes dans
les adresses de routage (entêtes MIME "Received: from..." qui ne
corespondent pas aux domaines déclarés par Orange. Ca fait longtemps
qu'Orange a des problèmes pour déclarer correctement ses serveurs (les
mails transitent en interne par plusieurs serveurs, dont des serveurs
privés (adresses IP non routables), Orange doit alors déclarer correctemetn
ses serveurs entrants et sortants (avec des adresses IP routables) valides
et qui correspondent aux entrées DNS.
Ca fait des années qu'il omet de faire ça correctement. Gmail a résolu ce
problème en interne car il connait les adresses des serveurs d'Orange et
les a testé. Les gestionnaires de liste de diffusion autonomes n'ont pas
cette connaissance et ne savent pas vérifier l'authenticité (pour vérifier
que les entêtes MIME de suivi ne sont pas usurpés par le spam). Je ne peux
rien faire malheureusement, sur le fait qu'Orange ne lit pas les RFC et ne
gère pas correctement son service (sa config est instable et cela dépend
des serveurs entrants et sortants effectifs, mais on ne peut pas les
choisir.
Il se passe aussi la même chose avec les serveurs SMTP de Free ou
LaPoste.net et d'autres. Leurs bases de configuration ne sont pas
maintenues à jour à chaque fois qu'ils ajoutent ou reconfigurent les
serveurs ou gèrent la charge en empruntant temporairement des serveurs de
transit par un système de "load balancing" mal configuré et pas déclaré
dans les entrées DNS des domaines et serveurs Orange (tous les serveurs
d'Orange n'ont pas tous une adresse IP déclarée dans leur domaine non plus
pour le reverse DNS; c'est pénible car les mails qu'ils envoient aux autres
ne sont pas vérifiables par les autres).
Les servgeurs d'Orange aussi corrompent certains entêtes MIME (en les
mélangeant parfois, ce qui brise l'ordre attendu et requis par les RFC).

Je ne peux rien faire, ce n'est pas à ma portée de configuration et les FAI
français se fichent pas mal de ce problème pour les listes de diffusion,
ils sont juste préoccupés par gérer les spams dans 90% des cas et les 10%
qui restent sont à la charge des clients qui doivent nettoyer eux-mêmes (et
les filtres antispam d'Orange sont vraiment trop basiques, de vraies
passoires, qui ne détecte même pas 1 spam sur les centaines que repère
Gmail. Avec les milliers de messages que je reçois j'ai abandonné toute
idée d'utiliser Orange comme gestionnaire de boite de réception, il reste
comme transit car je ne peux pas virer cette boite Wanadoo.fr qui est
associée à un certain nombre de services où on ne peut pas les changer sans
y souscrire à nouveau ou repayer pour avoir un nouveau compte avec mon
adresse Gmail (ou toute autre).

Et puis les fournisseurs de mail ne sont pas tous d'accord sur les requis
pour DMARC ou SPF, ou la sécurité d'accès (connexion de sockets sécurisée
avec certificats de domaines, sécurisation du DNS sur toutes les adresses
IP déclarées, signature valide des certificats). Les règles pour satisfaire
tout le monde sont mal comprises et il n'y a que Google/Gmail qui les
maitrise toutes et qui ne perd aucun message et n'a aucun "bounce" sur ses
serveurs d'entrée (ou de sortie pour les emails sortants). Orange a fait le
minimum et pas revu son architecture depuis des décennies, il a juste fait
évoluer son système de load balancing et très peu ses filtres antispam pour
les email entrants, et sur ses serveurs sortants il ne fait pas les vérifs
correctes contre l'usurpation par ses clients, quand il fait un relai vers
un autre service de messagerie comme Gmail en revanche ses entêtes MIME de
suivi sont corrects la plupart du temps, mais pas toujours (pour régler ce
problème j'ai du aussi demandé à Gmail de lire ma boite Orange et récupérer
les messages qu'Orange ne parvient pas à relayer, ce qui arrive aussi
régulièrement et fait qu'Orange sature au plan stockage et génère ensuite
des bounces pour les autres messages entrants valides qu'il est incapable
de vérifier et même de stocker.

Les protocoles du mail sont vieux, incohérents, chaque fournisseur semble
vouloir gérer le spam entrant un peu comme il veut et selon des méthodes
parfois incompatibles entre elles. Que puis-je faire? pas grand chose hormi
signaler aux divers fournisseurs, qui corrigeront (peut-être) un jour, mais
ces signalements à Orange ne sont pas compris (leur support technique ne
comprend rien ou prétend que tout va bien chez lui ou suggère à to

Re: [OSM-talk-fr] adresse mail rejetée

[Jérôme Seigneuret]

Arfff. Je crois que j'ai fait la même boulette. J'ai une autre adresse que
gmail sur les autres listes qui traîne... Je dois avoir un message sur la
liste tech en attente de modération ;-)
Je vais me désabonner et me réabonner avec l'autre email.
Bonne soirée.

Le mer. 8 janv. 2020 à 21:43, Philippe Verdy  a écrit :

> Je ne peux pas changer l'adresse d'émetteur quand je réponds avec Gmail
> (là où je reçois tous les messages) à un message qui mentionne mon adresse
> Wanadoo.fr (toujours valide) qui est aussi authentifiée et associée à mon
> compte Google (Orange a aussi authentifié mon adresse Gmail). Je ne peux
> choisir mon email que lors d'un envoi de nouveau message (pas par "Répondre
> à" ou "Répondre à tous). Si je réponds en créant un nouverau message, il
> n'y a plus le "message ID" qui permet d'identifier un fil de discussion et
> grouper les réponses.
>
> Le problème ce sont les serveurs d'Orange qui ne sont pas conformes dans
> les adresses de routage (entêtes MIME "Received: from..." qui ne
> corespondent pas aux domaines déclarés par Orange. Ca fait longtemps
> qu'Orange a des problèmes pour déclarer correctement ses serveurs (les
> mails transitent en interne par plusieurs serveurs, dont des serveurs
> privés (adresses IP non routables), Orange doit alors déclarer correctemetn
> ses serveurs entrants et sortants (avec des adresses IP routables) valides
> et qui correspondent aux entrées DNS.
> Ca fait des années qu'il omet de faire ça correctement. Gmail a résolu ce
> problème en interne car il connait les adresses des serveurs d'Orange et
> les a testé. Les gestionnaires de liste de diffusion autonomes n'ont pas
> cette connaissance et ne savent pas vérifier l'authenticité (pour vérifier
> que les entêtes MIME de suivi ne sont pas usurpés par le spam). Je ne peux
> rien faire malheureusement, sur le fait qu'Orange ne lit pas les RFC et ne
> gère pas correctement son service (sa config est instable et cela dépend
> des serveurs entrants et sortants effectifs, mais on ne peut pas les
> choisir.
> Il se passe aussi la même chose avec les serveurs SMTP de Free ou
> LaPoste.net et d'autres. Leurs bases de configuration ne sont pas
> maintenues à jour à chaque fois qu'ils ajoutent ou reconfigurent les
> serveurs ou gèrent la charge en empruntant temporairement des serveurs de
> transit par un système de "load balancing" mal configuré et pas déclaré
> dans les entrées DNS des domaines et serveurs Orange (tous les serveurs
> d'Orange n'ont pas tous une adresse IP déclarée dans leur domaine non plus
> pour le reverse DNS; c'est pénible car les mails qu'ils envoient aux autres
> ne sont pas vérifiables par les autres).
> Les servgeurs d'Orange aussi corrompent certains entêtes MIME (en les
> mélangeant parfois, ce qui brise l'ordre attendu et requis par les RFC).
>
> Je ne peux rien faire, ce n'est pas à ma portée de configuration et les
> FAI français se fichent pas mal de ce problème pour les listes de
> diffusion, ils sont juste préoccupés par gérer les spams dans 90% des cas
> et les 10% qui restent sont à la charge des clients qui doivent nettoyer
> eux-mêmes (et les filtres antispam d'Orange sont vraiment trop basiques, de
> vraies passoires, qui ne détecte même pas 1 spam sur les centaines que
> repère Gmail. Avec les milliers de messages que je reçois j'ai abandonné
> toute idée d'utiliser Orange comme gestionnaire de boite de réception, il
> reste comme transit car je ne peux pas virer cette boite Wanadoo.fr qui est
> associée à un certain nombre de services où on ne peut pas les changer sans
> y souscrire à nouveau ou repayer pour avoir un nouveau compte avec mon
> adresse Gmail (ou toute autre).
>
> Et puis les fournisseurs de mail ne sont pas tous d'accord sur les requis
> pour DMARC ou SPF, ou la sécurité d'accès (connexion de sockets sécurisée
> avec certificats de domaines, sécurisation du DNS sur toutes les adresses
> IP déclarées, signature valide des certificats). Les règles pour satisfaire
> tout le monde sont mal comprises et il n'y a que Google/Gmail qui les
> maitrise toutes et qui ne perd aucun message et n'a aucun "bounce" sur ses
> serveurs d'entrée (ou de sortie pour les emails sortants). Orange a fait le
> minimum et pas revu son architecture depuis des décennies, il a juste fait
> évoluer son système de load balancing et très peu ses filtres antispam pour
> les email entrants, et sur ses serveurs sortants il ne fait pas les vérifs
> correctes contre l'usurpation par ses clients, quand il fait un relai vers
> un autre service de messagerie comme Gmail en revanche ses entêtes MIME de
> suivi sont corrects la plupart du temps, mais pas toujours (pour régler ce
> problème j'ai du aussi demandé à Gmail de lire ma boite Orange et récupérer
> les messages qu'Orange ne parvient pas à relayer, ce qui arrive aussi
> régulièrement et fait qu'Orange sature au plan stockage et génère ensuite
> des bounces pour les autres messages entrants valides qu'il est incapable
> de vérifier et mê

Re: [OSM-talk-fr] Limite numérique des identifiants de noeuds/ways OSRM

[Julien Coupey]

> Sais-tu si l'équipe les traite encore?

Le problème est qu'à l'heure actuelle il n'y a plus vraiment d' « équipe 
» sur OSRM, tout juste danpat qui fait un peu de SAV en commentant les 
nouveaux tickets ouverts.


S'il s'agit vraiment d'un bug facilement reproductible, il y a toutefois 
des chances que tu aies un retour. Il y a quand même pas mal de gens qui 
continuent à utiliser OSRM et tout ce petit monde a intérêt à ce que ça 
fonctionne. ;-)


Bonne soirée
Julien

On 08/01/2020 18:06, François Lacombe wrote:
Merci Julien, je vais essayer de fournir un fichier de ce style là pour 
une issue

Effectivement je pense que c'est un bug aussi

Sais-tu si l'équipe les traite encore?
Les derniers essais que j'ai fait n'ont pas obtenus de réponse.

Bonne soirée :)

François

Le mer. 8 janv. 2020 à 16:06, Julien Coupey > a écrit :


Re

Si tu récupères en sortie (dans l'objet `annotation.nodes` d'une route)
des ids de nœuds qui ne sont pas dans les données d'entrée, alors c'est
un bug, même si ça n'a apparemment pas de lien avec le fait que les
valeurs soient supérieures à 2^32.

Ça vaudrait certainement le coup d'ouvrir un ticket avec un exemple
minimal pour reproduire. C'est peut-être ça le plus compliqué dans ton
cas car tu sembles utiliser des nœuds renumérotés à la main. Peut-être
réduire l'extrait OSM à un simple way composé de nœuds problématiques
pour pouvoir le fournir ?

À +
Julien

On 08/01/2020 12:29, François Lacombe wrote:
 > Bonjour Julien,
 >
 > Merci pour ta réponse, ça me rassure tout de même.
 > Pour les identifiants de ways, c'est moins problématique pour moi.
 >
 > Ce qui ne passe pas, c'est que j'injecte un XML qui comporte des
noeuds
 > identifiés avec
 > 91220288029161
 > 91220288025445
 > 91220288026438
 >
 > Et qui ressortent avec des identifiants tronqués à 10 digits (ce
ne sont
 > pas les mêmes noeuds). En tout cas ces identifiants là ne sont pas
 > présents dans le .osm d'entrée.
 > 1885473760
 > 246430160
 > 5846804688
 > 737485280
 > 8063904192
 >
 > 8063904192 étant déjà supérieur à la limite 32 bits, j'ai pensé à
une
 > limitation à 10 digits
 >
 > Une idée du problème ?
 >
 > François
 >
 > Le mer. 8 janv. 2020 à 11:41, Julien Coupey mailto:o...@coupey.fr>
 > >> a écrit :
 >
 >     Bonjour François
 >
 >     OSRM supporte normalement sans problème les ids OSM sur 64
bits pour
 >     les
 >     nœuds depuis un moment[1]. Ce n'est pas le cas pour les ways (ids
 >     toujours sur 32 bits) mais a priori il y a de la marge si tu
utilises
 >     les données OSM telles quelles.
 >
 >       > ca ne passe pas.
 >
 >     Si tu peux développer un peu sur ce qui coince, peut-être que ça
 >     vaut le
 >     coup d'ouvrir un ticket ?
 >
 >     [1] https://github.com/Project-OSRM/osrm-backend/pull/1793
 >
 >     À +
 >     Julien
 >
 >     On 08/01/2020 11:19, François Lacombe wrote:
 >      > Bonjour la liste
 >      >
 >      > Est-ce que quelqu'un familier avec OSRM saurait me dire quelle
 >     est la
 >      > limite exacte pour les identifiants de nœuds et de chemins
OSM?
 >      >
 >      > Je remarque que ces identifiants ne dépassent pas 10
digits dans les
 >      > réponses fournies par l'API route.
 >      > On en est à 5700014039 de nœuds dans la base, le plafond va
 >     bientôt être
 >      > atteint.
 >      > La maintenance de ces derniers mois est au ralenti, fort à
parier
 >     que ce
 >      > ne sera bientôt plus utilisable?
 >      >
 >      > Perso je régénère des fichiers xml osm avec des
identifiants 64
 >     bits et
 >      > ca ne passe pas.
 >      >
 >      > Preneur de vos commentaires, merci par avance
 >      >
 >      > François
 >      >
 >      > ___
 >      > 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] Limite numérique des identifiants de noeuds/ways OSRM

[Philippe Verdy]

Je pensais que ce problèmes d'Id de noeuds de 64 bits était réglé depuis
longtemps sur les outils majeurs. Il y a une page wiki qui recense les
logiciels (ou versions de logiciels) à mettre à jour et ne plus utiliser.
Vérifie plutôt quel outil tu utilises. Ce problème ne vient pas des
serveurs OSM ou des éditeurs courants. Mais il peut exister avec d'anciens
éditeurs mobiles pas à jour du tout et qu'il faudrait bloquer; mais on a
aussi des cas où c'est provoqué par des clients malveillants (spammeurs)
utilisant des automates archi-bogués, et qu'on doit détecter et bloquer.
Si tu utilises encore un de ces vieux logiciels (éditeurs, bibliothèques,
etc.) le plus souvent écrits en C/C++ avec des types incorrects, il faut en
changer. Ce n'est pas non plus un bogue de XML ou du format .OSM qui n'a
pas cette limite à 64 bits. De vieilles versions de QGIS notamment ne
doivent plus être utilisées: la mise à jour est obligatoire sinon cela
corrompt les données en mélangeant les noeuds.
Attention aussi à certains vieux scripts PH, Perl, Python.
A priori Javascript n'est pas impacté sauf sur de très vieux navigateurs
web avec une machine javascript antique pour un OS qui n'st plus supporté
depuis longtemps non plus (vieilles versions d'IE compilé en 32 bits).
Attention aussi aux scripts, programmes ou vieux plugins qui traduisent les
données d'un schéma à l'autre et qui ne sont plus maintenus (dont un
certain nombre pour JOSM ou QGIS pour "aider" à créer ou simplifier des
géométries et qui ne marchent plus, ne seront plus mis à jour et ont été
remplacés par des fonctions intégrées ou d'autres plugins).
Mais comme tu ne précises pas quels composants logiciels tu utilises,
impossible de savoir. Si tu as fait tes propres scripts ou programmes, il
est nécessaire de déclarer les node-ids en 64 bits (et tant qu'à faire en
même temps les way-id et relation-id, vu qu'ils héritent d'un même objet
OSM de base, même si pour l'instant il n'ont pas encore atteint la limite
des 32 bits et qu'on en est encore loin pour les relations).



Le mer. 8 janv. 2020 à 12:31, François Lacombe 
a écrit :

> Bonjour Julien,
>
> Merci pour ta réponse, ça me rassure tout de même.
> Pour les identifiants de ways, c'est moins problématique pour moi.
>
> Ce qui ne passe pas, c'est que j'injecte un XML qui comporte des noeuds
> identifiés avec
> 91220288029161
> 91220288025445
> 91220288026438
>
> Et qui ressortent avec des identifiants tronqués à 10 digits (ce ne sont
> pas les mêmes noeuds). En tout cas ces identifiants là ne sont pas présents
> dans le .osm d'entrée.
> 1885473760
> 246430160
> 5846804688
> 737485280
> 8063904192
>
> 8063904192 étant déjà supérieur à la limite 32 bits, j'ai pensé à une
> limitation à 10 digits
>
> Une idée du problème ?
>
> François
>
> Le mer. 8 janv. 2020 à 11:41, Julien Coupey  a écrit :
>
>> Bonjour François
>>
>> OSRM supporte normalement sans problème les ids OSM sur 64 bits pour les
>> nœuds depuis un moment[1]. Ce n'est pas le cas pour les ways (ids
>> toujours sur 32 bits) mais a priori il y a de la marge si tu utilises
>> les données OSM telles quelles.
>>
>>  > ca ne passe pas.
>>
>> Si tu peux développer un peu sur ce qui coince, peut-être que ça vaut le
>> coup d'ouvrir un ticket ?
>>
>> [1] https://github.com/Project-OSRM/osrm-backend/pull/1793
>>
>> À +
>> Julien
>>
>> On 08/01/2020 11:19, François Lacombe wrote:
>> > Bonjour la liste
>> >
>> > Est-ce que quelqu'un familier avec OSRM saurait me dire quelle est la
>> > limite exacte pour les identifiants de nœuds et de chemins OSM?
>> >
>> > Je remarque que ces identifiants ne dépassent pas 10 digits dans les
>> > réponses fournies par l'API route.
>> > On en est à 5700014039 de nœuds dans la base, le plafond va bientôt
>> être
>> > atteint.
>> > La maintenance de ces derniers mois est au ralenti, fort à parier que
>> ce
>> > ne sera bientôt plus utilisable?
>> >
>> > Perso je régénère des fichiers xml osm avec des identifiants 64 bits et
>> > ca ne passe pas.
>> >
>> > Preneur de vos commentaires, merci par avance
>> >
>> > François
>> >
>> > ___
>> > 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] Abus de StephaneP : adresses FANTOIR

[Stéphane Péneau]

Le 08/01/2020 à 21:15, Jérôme Seigneuret a écrit :
Le square tel qu'il est défini est en effet ambigu. Je trouve que la 
définition sur wikipedia est nettement plus claire et celle d'OSM 
devrait avoir une révision... https://fr.wikipedia.org/wiki/Square_(lieu)


Ah ok, c'est parce que tu prends la définition française du mot 
"square". C'est une sorte de faux-ami, et c'est bien précisé sur le wifi 
français de faire attention à la confusion. La référence est la 
définition anglaise.


Dans la terminologie Osm, place=square donne en français : "place"

"square" en français donne leisure=park dans la terminologie Osm

A+

Stf



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

Re: [OSM-talk-fr] adresse mail rejetée - expéditeur wanadoo.fr via gmail pour destintaire free gmail laposte et autres

[Philippe Verdy]

Le mer. 8 janv. 2020 à 13:55, marc marc  a
écrit :

>
> Le 08.01.20 à 01:28, Philippe Verdy a écrit :
> > Pour ceux auxquels je réponds
> je redis :
> même les NOUVEAUX messages que TU écris, TOUS sont en @wanadoo
> comme par exemple ton email avec le sujet communes-communautés.
>

Ce doit être Gmail qui remplace en indiquant mon adresse principale de
souscription à Gmail (authentifiée et confirmée entre les deux). Les deux
sont des aliases déclarés aussi bien chez Orange que chez Gmail.
Je ne peux pas retirer mon adresse principale, sinon je perds l'accès à mes
comptes Google qui exige cette adresse et l'utilise ensuite
systématiquement pour les listes souscrites...

Pour en changer je dois faire 3 clics de plus pour rouvrir le message en
coiurs de composition, cliquer sur "changer le sujet", choisir un nouvel
expéditeur, mais ça ne marche pas toujours et notamment pas pour les listes
souscrites (je suppose que Gmail a eu trop de bounces si on écrit à une
liste avec une adresse gmail et pas l'adresse principale et il renvoie
alors à la liste en essayant à la place mon adresse principale non Gmail).

Je n'ai pas toujours le contrôle là-dessus. Ca marche parfois... pas
toujours. C'est pénible. mais malheureusement on tombe dans les
incohérences et incompatibilités du vieux protocole SMTP (d'autant plus que
les serveurs de diffusion d'OSM ne sont pas sécurisés et ne tracent pas
correctement les messages qu'ils relaient et diffusent).

Le gros du problème est sur le serveur de liste d'OSM, son logiciel pas à
jour depuis longtemps et utilisent certaines vieilles RFC et pas les mises
à jour et correctifs demandés.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adresse mail rejetée - expéditeur wanadoo.fr via gmail pour destintaire free gmail laposte et autres

[Philippe Verdy]

De plus je doute fort que cela ne marche pas quand un de mes messages va
vers un autre compte Gmail, puisque ma réponse vient de Gmail directement.
Si ça bloque c'est que les traces dans les entêtes MIME ont été corrompues
dans les serveurs de diffusion d'OSM et ,ne peuvent plus être certifiées
conformes à la signature numérique initiale insérée par Gmail.

Si le mail marchait su bien que ça, ça fait longtemps qu'on aurait tous des
certificats d'émetteur et des signatures numériques. Mais elles ne marchent
pas, il y a trop de serveurs qui corrompent les données et invalident ces
signatures dans les entêtes MIME, en manipulant incorrectement les corps de
messages. La signature numérique ne fonctionne en fait sur aucune liste de
diffusion (OSM par exemple ajoute du texte à la fin du corps de message au
lieu d'attacher une pièce complémentaire.

Je ne fais aucune manipulation des entêtes. et j'utilise les options par
défaut de Gmail pour répondre et à priori c'est correct partout... sauf sur
les listes de diffusion d'OSM.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adresse mail rejetée - expéditeur wanadoo.fr via gmail pour destintaire free gmail laposte et autres

[Jacques Lavignotte]

Le 08/01/2020 à 22:21, Philippe Verdy a écrit :
Le gros du problème est sur le serveur de liste d'OSM, son logiciel pas 
à jour depuis longtemps et utilisent certaines vieilles RFC et pas les 
mises à jour et correctifs demandés.

Non, rien.

J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
On mangera ? (c) (tm)

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

Re: [OSM-talk-fr] Abus de StephaneP : adresses FANTOIR

[Jérôme Seigneuret]

Oui en effet tu as raison... Mais tu me diras la définition anglaise reste
sur un lieu orienté principalement pour les piétons. Un espace destiné à
rassembler des gens autour d'évènements avec si possible un élément
monumental en son centre.
On y parle selon les pays d'équivalent à la place public (on a plus
d’échafaud) ou de place centrale. Encore une fois c'est vraiment orienté
sur le fait d'y faire des évènements publique

Sinon le terme à l'américaine est encore plus particulier vu que c'est une
notion de trame carré (village square, garden square, town square,
washington square...) avec des ilots qui se sont remplit de commerce et de
park et autre fonctionalité. Ducoup les ilots de circulation "mode
circulation douce" sont des place=square

La place de la comédie à Montpellier répond bien à cette usage.
Au pire tu serais sur une place de marché. (Si tel est le cas)




Le mer. 8 janv. 2020 à 22:09, Stéphane Péneau 
a écrit :

> Le 08/01/2020 à 21:15, Jérôme Seigneuret a écrit :
> > Le square tel qu'il est défini est en effet ambigu. Je trouve que la
> > définition sur wikipedia est nettement plus claire et celle d'OSM
> > devrait avoir une révision...
> https://fr.wikipedia.org/wiki/Square_(lieu)
> >
> Ah ok, c'est parce que tu prends la définition française du mot
> "square". C'est une sorte de faux-ami, et c'est bien précisé sur le wifi
> français de faire attention à la confusion. La référence est la
> définition anglaise.
>
> Dans la terminologie Osm, place=square donne en français : "place"
>
> "square" en français donne leisure=park dans la terminologie Osm
>
> A+
>
> Stf
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Limite numérique des identifiants de noeuds/ways OSRM

[François Lacombe]

Le mer. 8 janv. 2020 à 22:04, Julien Coupey  a écrit :

> Il y a quand même pas mal de gens qui
> continuent à utiliser OSRM et tout ce petit monde a intérêt à ce que ça
> fonctionne. ;-)
>

Je n'en doute pas vu le nombre de forks sur le dépôt du backend c'est
impressionnant.

A la base, j'en suis arrivé à cette solution (utiliser annotations=nodes)
parce qu'il y avait ce soucis-là sur lequel personne n'a jamais réagit
https://github.com/Project-OSRM/osrm-backend/issues/5190

Il n'y a pas de jeu de données d'entrée en effet, il faudra que je vois si
je ne peux pas sortir un extract dans ce coin également.
Mais il faut aussi fournir les profils utilisés pour produire la réduction
et je n'y suis pas autorisé

Bonne soirée

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

Re: [OSM-talk-fr] 1ere mondiale (enfin je crois) : le réseau de transport électrique français est routable

[François Lacombe]

Bonsoir et merci pour vos encouragements
Je pense faire un diary pour donner quelques explications en plus

Le mar. 7 janv. 2020 à 08:42, Christian Quest  a
écrit :

>
> Je me posais justement la question de savoir si l'on pouvait une
> interface du genre "par où arrive mon électricité ?"
>

Ce serait très intéressant ça
Il y a même des solutions qui existent pour déterminer la part d'éolien, de
nucléaire, de solaire à instant T en plusieurs points du réseau (sinon tous)
C'est le but du projet Kelelekici chez RTE.


> Je me suis posé la question avec l'ouverte de données Enedis, qui
> désormais me permettent de savoir à quel transformateur HT/BT je suis
> raccordé, et de savoir à quel poste électrique il est lui même raccordé
> et bien sûr par où passent les câbles... mais au delà, ça se complique
> c'est sûrement plus maillé et moins capillaire.
>

Il y a un problème de connectivité : les câbles ne sont pas connectés au
poste. Il y a un traitement à faire pour les rapprocher en fonction de
certaines règles
Ca peut se faire avec postgis toutefois

Pour relier le poste de quartier avec la source, il faut connaître l'état
des interrupteurs. Parce que si le poste est sur une boucle alimentée, elle
se referme obligatoirement sur la même source.
La carto ne suffit pas bien qu'essentiel pour le déterminer

On y parviendra dans quelques années je pense


> La mauvaise nouvelle (relative) pour mon datacenter de la cave, c'est
> que je ne suis pas sur le transfo de la clinique de mon quartier, ni sur
> celui de la mairie.
>

Avec les grèves et actions en tout genre, cela vaut mieux ;)

Bonne soirée

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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Bonsoir Quentin,

Le mer. 8 janv. 2020 à 14:38, Quentin Salles  a
écrit :

> Bonjour,
>
> Pour l'instant, je vais rester sur le tag actuel, à savoir "ref:FR:ERDF".
> Et je complèterai par "ref" pour l'information que je vois sur le terrain.
>
C'est la bonne démarche


> Osmose signalé bien les élements manquants, mais aucun identifiant ou même
> nom n'est indiqué. Serait-il possible d'avoir l'identifiant en OpenData ?
>
Cela a été demandé à plusieurs reprises
Si tu as le courage de tout lire, l'opendata des réseaux elec n'est pas si
tranquille :
https://teamopendata.org/t/les-gestionnaires-de-distribution-electrique/1018


> Concernant le gaz, me donner vous l'autorisation de compléter la page Wiki
> OSM "ref:FR:gdo" ?
>
Ce serait même très bien accueilli
Si cela est possible, est-ce envisageable de respecter la même trame pour
les possibilités gaz sur cette page s'il te plaît?

Bonne soirée

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

Re: [OSM-talk-fr] 1ere mondiale (enfin je crois) : le réseau de transport électrique français est routable

[marc marc]

Le 07.01.20 à 08:41, Christian Quest a écrit :
> je ne suis pas sur le transfo de

l'étendue de distribution d'un transfo est-elle connue ?
ou pour le dire autrement, peux-t-on avoir l'info inverse :
tel transfo alimente tel rue + tel rue + tel rue ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] 1ere mondiale (enfin je crois) : le réseau de transport électrique français est routable

[François Lacombe]

Le mer. 8 janv. 2020 à 23:58, marc marc  a
écrit :

> l'étendue de distribution d'un transfo est-elle connue ?
> ou pour le dire autrement, peux-t-on avoir l'info inverse :
> tel transfo alimente tel rue + tel rue + tel rue ?
>

On peut la retrouver via le réseau en regardant les câbles basse tension
qui sortent du poste pour aller vers des adresses.
Attention, parfois plusieurs câbles provenant de postes différents peuvent
passer devant une même adresse.

Il me semble que dernièrement Engie était en procès avec Enedis puisque ce
dernier ne voulait pas communiquer les polygones des zones arrières de
postes pour l'organisation de ses communautés d'autoconsommation.
Il vaut mieux avoir les polygones pour réduire le risque d'erreurs, voire
des points adresse directement qualifiés par l'exploitant (comme sur
http://cartefibre.arcep.fr pour la fibre) puisque la BAN est maintenant
ouverte :)
Et encore à une adresse tu serais capable de trouver des points de
livraison alimentés par deux transfos du même poste ou deux postes
différents (penser aux gros immeubles)

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

Re: [OSM-talk-fr] 1ere mondiale (enfin je crois) : le réseau de transport électrique français est routable

[Philippe Verdy]

Le mer. 8 janv. 2020 à 23:08, François Lacombe 
a écrit :

> Pour relier le poste de quartier avec la source, il faut connaître l'état
> des interrupteurs. Parce que si le poste est sur une boucle alimentée, elle
> se referme obligatoirement sur la même source.
>

Les boucles c'est pour avoir une seconde ligne de secours en cas de coupure
de la première (chute d'arbre, dégat de chantier, poteau mis à terre par le
vent ou un accident de la route, rupture de câble sous le poids du gel...)?
Est-ce que cela n'introduit pas des déphasages (différences de distance de
câble, donc perte de puissance utile, dissipée thermiquement par résistance
des câbles sur des courants importants de compensation) ou des pertes
magnétiques importantes si les deux branches vers le poste de quartier sont
alimentées en boucle ?
Je suppose que dans ces paires, il n'y a qu'une branche alimentée à un
instant donné et que les interrupteurs sont là pour éviter ces pertes
(surtout celle de déphasage je pense plus que la dissipation magnétique).


Normalement une distribution électrique se fait en arbre sans boucles, ou
il faut un dispositif d'adaptation limitant les pertes de puissance par
déphasage (installation en un ou plusieurs points de la boucle de lignes de
"retard" pour compenser les différences de phase, afin de garer la boucle
fermée sans trop de perte, donc une mesure des écarts de phase faite au
départ sur une boucle ouverte; c'est relativement simple et peu couteux
pour la distribution finale monophasée des petits consommateurs, mais pour
les autres en triphasé avec des boucles longues ou de fortes puissances,
les lignes de retard peuvent être couteuses, par exemple par un
convertiseur alternatif/continu/alternatif et la regénération des phases
alternatives, le générateur ayant aussi un temps de démarrage avant
d'atteindre la fréquence souhaitée et la stabiliser au point d'équilibre).

Déjà que c'est compliqué de maintenir les 120 degrés de décalage de phases
sur une ligne triphasée (surtout s'il y a plusieurs clients et les
installations ne sont pas bien équilibrées en permanence), mais on peut
compenser en utilisant une ligne neutre non reliée à la terre avec une
seule ligne de retard sur le neutre et une basculement en biphasé en cas de
rupture d'une ligne, et basculement des modes de fonctionnement des
transfos adapteurs au point final de distribution.

On se demande pourquoi on utilise encore la distribution finale en mode
alternatif (on sait écranter maintenant le champ électrique d'un gros câble
porteur en courant continu et ça évite pas mal des pertes magnétiques du
courant alternatif et tout problème de déphasages ou déséquilibre; et on
peut facilement ajouter des boucles par des chemins différents et
consolider le réseau connecté en cas de panne d'une branche sans utiliser
les interrupteurs, toujours dangereux pour les fortes puissances à cause
des arcs électriques et du risque d'incendie à chaque branchement ou
débranchement, et de défaut rapide par oxydation des contacts et
introduction de couches résistives.

Il suffit de voir les étincelles qui jaillissent parfois dans les postes de
distribution et le bruit permanent des circuits placés souvent dans un
espace à air libre juste entouré de barrières; on a aussi ce bruit sous les
grandes lignes de distribution, même si c'est réduit par les hautes
tensions pour induire moins de courant, mais comme aucune de ces ligne
n'est rectiligne mais comporte des arcs, il y a aussi une émission
magnétique dans la direction moyenne de l'axe de courbe, plus importante à
proximité du centre entre deux porteurs car la courbe n'est pas exactement
circulaire mais en "chaînette" quasi-parabolique avec une plus forte
courbure au milieu que près des porteurs; il y a aussi une courbure encore
plus grande au niveau des pylônes porteurs, mais là on peut placer des
écrans magnétiques; ces problèmes de pertes magnétiques sont cependant là
aussi en courant continu mais avec des courants de crête plus faibles le
long des câbles)...

Au moins avec les réseaux enterrés, ce sont les gaines et la terre qui font
écran aux pollutions radioélectriques; passer le tout en courant continu
serait un progrès, pour réduire encore les pertes magnétiques comme aussi
le bruit induit par la vibration constante à 50Hz des câbles, et plus
besoin de triphasé, les gaines peuvent être rapprochées au lieu des
horribles ouvrages aériens géants qui gâchent le paysage.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] 1ere mondiale (enfin je crois) : le réseau de transport électrique français est routable

[Philippe Verdy]

A quand une boucle locale libre comme d'accès à tous les opérateurs, comme
les lignes téléphoniques ? Et puis plein de sites sensibles ont des
distributions multiples par plusieurs fournisseurs et des câbles
indépendants, pour prévenir un incident sur un des fournisseurs (notamment
les data centers, hôpitaux, et divers équipements de sécurité dont les
centraux téléphoniques, les antennes du service GSM de base, en plus de
leurs groupes électrogènes et leurs réserves de carburant limitées, même
chose pour les refroidisseurs des centrales nucléaires ou même thermiques).

Au besoin les distributeurs peuvent compenser les besoins en éteignant les
éclairages publics ou les chauffe-eaux individuels pour éviter les
surcharges ; rien que le chauffage de l'eau (aussi les pompes de
remplissage des châteaux d'eau et les vannes des barrages électrique pour
réguler la production) constitue une réserve capacitive d'énergie, au
besoin il rallumeront et déplaceront les tranches tarifaires en heure
creuse pour leur remise en route s'il y a eu une coupure déclenchée sur la
distribution ou la génération; les télécommandes des compteurs sont là pour
ça et ces coupures hors programme ne dérangent pas grand monde ; on a moins
de coupure aujourd'hui totales que dans les décennies passées (sauf
accident local souvent à cause de météo, ou coupure volontaire par des
grévistes, cas devenu rare aujourd'hui; le réseau possède de nombreux
instruments de mesure et de télécommandes pour compenser les différents
circuits et des mailles disponibles non utilisées en permanence; les
distributeurs sont également interconnectés entre eux et ont des compteurs
pour se refacturer les consommations ou productions).

On n'a pas en France des blackouts aussi importants que ceux qu'on observe
aux USA ou au Brésil (surtout à cause des réseaux de transport d'énergie
hors d'âge), touchant de très larges régions et tous les usages chez tous
les distributeurs finaux ; cependant on a beaucoup moins de groupes
électrogènes de secours, peu efficaces, très polluants et chers à l'usage
en carburant donc très inégalitaires pour la population générale et les
commerces.



Le jeu. 9 janv. 2020 à 00:04, François Lacombe 
a écrit :

> Le mer. 8 janv. 2020 à 23:58, marc marc  a
> écrit :
>
>> l'étendue de distribution d'un transfo est-elle connue ?
>> ou pour le dire autrement, peux-t-on avoir l'info inverse :
>> tel transfo alimente tel rue + tel rue + tel rue ?
>>
>
> On peut la retrouver via le réseau en regardant les câbles basse tension
> qui sortent du poste pour aller vers des adresses.
> Attention, parfois plusieurs câbles provenant de postes différents peuvent
> passer devant une même adresse.
>
> Il me semble que dernièrement Engie était en procès avec Enedis puisque ce
> dernier ne voulait pas communiquer les polygones des zones arrières de
> postes pour l'organisation de ses communautés d'autoconsommation.
> Il vaut mieux avoir les polygones pour réduire le risque d'erreurs, voire
> des points adresse directement qualifiés par l'exploitant (comme sur
> http://cartefibre.arcep.fr pour la fibre) puisque la BAN est maintenant
> ouverte :)
> Et encore à une adresse tu serais capable de trouver des points de
> livraison alimentés par deux transfos du même poste ou deux postes
> différents (penser aux gros immeubles)
>
> François
> ___
> 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] Intégration supports radio ANFR : différences mast/tower

[François Lacombe]

Salut à tous,

Des questions relative à l'intégration Osmose des supports ANFR
Sur le support suivant, initialement qualifié en pylône :
https://www.openstreetmap.org/node/4026894947, on a man_made=mast

Cartoradio dit "Pylône autostable", et StreetView laisse penser que c'est
bien un pylône
https://www.google.fr/maps/@45.9114338,0.857628,3a,30.6y,1.47h,99.93t/data=!3m6!1e1!3m4!1sHfbTlTDRbyfCi-iCaOKDIw!2e0!7i13312!8i6656

Pourquoi le choix d'utiliser mast ici?
Je n'ai pas beaucoup participé aux discussions et j'ai pu passer à côté de
quelque chose.

Autre cas : https://www.openstreetmap.org/node/6925034943
Celui-ci est en fait sur le pylône électrique tout proche (street view pas
à jour mais il n'y a pas de doute vu la distance) :
https://www.openstreetmap.org/node/1645500132

Cartoradio dit "Pylône autostable", ce qui n'est pas faux, mais je devrais
leur suggérer de créer la catégorie pylône électrique sans quoi la simple
indication RTE ne permet pas de distinguer les pylones telecom des pylones
électriques (et il faudra bien conserver power=tower sans man_made=tower)

Bref, preneur des avis des uns et des autres, merci par avance

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

Re: [OSM-talk-fr] Intégration supports radio ANFR : différences mast/tower

[marc marc]

Le 09.01.20 à 01:39, François Lacombe a écrit :
> Je n'ai pas beaucoup participé aux discussions

de mémoire, sur tagging, la différence avait surtout été mis
sur comment on y monte : mat par dehors, polygone par dedans.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration supports radio ANFR : différences mast/tower

[Jérôme Amagat]

C'est moi qui est fait ces choix pour osmose.
J'ai fait ce choix personne n'en a parler sur la discussion sur le github
d'osmose donc c'est resté comme ça.
La lecture des pages du wiki pour man_made=mast et man_made=tower m'a fait
faire ce choix.
Ce que j'ai compris c'est comme dit marc marc : tower si il y a un
intérieur ou au moins des plateformes et mast sinon donc pour les pylônes
j'ai mis mast. man_made=tower serait plutôt pour ce que l'on appelle en
français des "tours" donc pas trop les pylônes.
Le problème c'est que ce n'est pas en accord avec power=tower. Et peut être
pas trop avec les définitions de tower et mast ...

le code est là :
https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merge_radio_support_FR.py




Le jeu. 9 janv. 2020 à 01:46, marc marc  a
écrit :

> Le 09.01.20 à 01:39, François Lacombe a écrit :
> > Je n'ai pas beaucoup participé aux discussions
>
> de mémoire, sur tagging, la différence avait surtout été mis
> sur comment on y monte : mat par dehors, polygone par dedans.
> ___
> 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] Chemin de fer "disused"

[Arnaud Champollion]

Bonjour,

Pour une ligne de chemin de fer désaffectée (mais dont l'infrastructure 
est encore en place), j'ai passé tous les tronçons "railway=rail" en 
"railway=disused" :


"Portion de voie ferrée désaffectée mais dont l'infrastructure est 
encore en place."


Ces tronçons appartiennent à une relation qui décrit l'ancienne ligne.

--> Est-ce que cette relation 
https://www.openstreetmap.org/relation/3321823  :


- doit être aussi qualifiée de "railway=disused"  ? sachant qu'a priori 
on n'utilise pas railway=rail sur les lignes : 
https://wiki.openstreetmap.org/wiki/FR:Tag:route%3Drailway


- doit utiliser le préfixe disused:route=railway ?

- ne doit plus exister ?

--> Quid de l'attribut "name" des tronçons et de la relation ?

Merci


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