[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

[OSM-ja] 市区町村人口データの入力

[OKADA Tsuneo]

岡田です。

国勢調査のデータを元に、私の方で
年末からポチポチと各市町村の人口を入力していたのですが、
遅ればせながらwikiページを作成しました。
内容に不足・指摘などあればよろしくお願いします。

作成ページ
https://wiki.openstreetmap.org/wiki/Japan_Census

リンク元
  https://wiki.openstreetmap.org/wiki/Japan_OpenData
に「国勢調査」のリンクを作成

-- 
岡田常雄(OKADA Tsuneo)
tsuneo.ok...@gmail.com
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

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

Re: [talk-au] Fire Station Operators

[Warin]

Agreed as to non fire stations - control center is one, the other 
headquarters.


Headquarters would be an 'office' type function.

Control center looks, from imagery, to not only control but supply?

There is a fire & rescue station in 'town' that is mapped into OSM.

There are a number of rural fire stations around Narrabri .. some of 
them unmapped.
These show up very well on the LPI Base Map even when zoomed out a fair 
way.




On 9/1/20 8:12 am, Andrew Harvey wrote:


On Wed, 8 Jan 2020 at 22:40, Sebastian Spiess > wrote:


I've done a few. Two raised questions.

Narrabri - There are two fire ' services'  according to LPI map.
How to
tag them?
https://www.openstreetmap.org/changeset/79336523


Looks like there is a Fire Control Center there, I'd just tag that 
building as office=government + operator + name, since they have more 
of an office function.




and RAYMOND TERRACE Fire Station - This seems to be and old fire
station
as according to https://www.fire.nsw.gov.au/news.php?news=608
a new one was built. I can't tell if the old one was closed down.

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


If you're not sure and street level imagery doesn't help, just mark it 
as too hard and skip it. You can create a note so that someone with 
local knowledge can help.





Am 2020-01-08 21:24, schrieb Andrew Harvey:
> If someone has carefully surveyed the name as signposted I leave
that
> intact. branch is not mandatory but helpful since consumers can
choose
> how they want to format the such as "Narooma", "Narooma RFS",
"Narooma
> Rural Fire Brigade", etc. especially when combined with
operator. The
> whole point was to be neutral on the exact name format and not
engage
> in a mass edit to reformat them to be the same, but instead respect
> names will look different based on signage.
>
> On Wed, 8 Jan 2020 at 21:05, Warin <61sundow...@gmail.com
> wrote:
>
>> I have used the LPI Base Map for both name and operator, see
>>
>> Way: Narooma Fire Station (761122699) [operator fire & rescue]
>>
>> and
>>
>> Way: Narooma Rural Fire Service (761122698)
>>
>> I do not bother with the 'branch' as that is usually the leading
>> value in the name and probably the same as the areas administration
>> name too.
>>
>> The LPI Base Map also gives the area so it can be mapped as a way.
>>
>> On 08/01/20 16:13, Graeme Fitzpatrick wrote:
>>
>> No, just confirming details was all I was thinking about!
>>
>> Thanks
>>
>> Graeme
>>
>> On Wed, 8 Jan 2020 at 14:57, Andrew Harvey
>> mailto:andrew.harv...@gmail.com>> wrote:
>>
>> It's normally considered okay to check a business website as a
>> reference and picking up their contact details, but to err on the
>> side of caution taking a whole database from fire.nsw.gov.au
 [1] and
>> mass importing is not advised.
>>
>> So I'd suggest not just copying everything from that website. For
>> the RFS operated fire stations normally the name will indicate
this,
>> or a quick look at google search results may also indicate,
>> sometimes it's visible on Mapillary based on the signage.
>>
>> On Wed, 8 Jan 2020 at 15:39, Graeme Fitzpatrick
>> mailto:graemefi...@gmail.com>> wrote:
>>
>> Just a thought?
>>
>> Are we allowed to use https://www.fire.nsw.gov.au/page.php?id=467
>> or not?
>>
>> I've thinking we would still need permission & waiver?
>>
>> Big question, I guess, is - are we commercial or not?
>>
>> Thanks
>>
>> Graeme
>
>
>
> Links:
> --
> [1] http://fire.nsw.gov.au
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-au



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

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

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

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

[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

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

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

[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] mapping outside Europe

[Mateusz Konieczny]

8 Jan 2020, 17:33 by ma...@anche.no:

> more constructively:
> On 08/01/2020 02:54, Mateusz Konieczny wrote:
>
>> Is a new photo differing in content (confusing for Europeans in the similar 
>> way as original
>> was confusing for people from Panama)? Then both should be present, one in 
>> the infobox,
>> one in the article text.
>>
>
> I like this one.  :-)
>
https://commons.wikimedia.org/wiki/Commons:Picture_of_the_day
has sometimes nice images.

I was not looking far but I found some fitting for OSM documentation.
And I replaced some really low quality ones with ones that I found.

And on topic of "all images are of Europe" I upgraded image on 
https://wiki.openstreetmap.org/wiki/Key:lit with one from Paraguay.
Of still low quality but significantly better and more fitting the page.
After more that 15 minutes still noone reverted it :)

https://wiki.openstreetmap.org/wiki/Tag:surface%3Dpaving_stones is my other
edit where I added additional images as just one from infobox was not enough to
cover the topic.

> we could invite people from different areas to contribute relevant pictures.
>
> I can do Panama, and look up in my archives for other regions I visited.  I 
> can't obviously cover the rest of the world, but we as OSM editors surely can.
>
+1 
https://wiki.openstreetmap.org/wiki/Category:Feature_pages_with_missing_images
has some false positive but is likely to be a good start

After going through this - making a script that finds all images with extremely 
small
resolution for replacement would be likely a good next step (ask here or on dev 
mailing
list for help if that would be necessary)


> On 08/01/2020 04:29, Marc Gemis wrote:
>
>> What I meant with "write the wiki page you want to see" is: create a
>> new wiki page "Highways in Panama" or "Highways in South America",
>> preferable in Spanish and Portuguese and link to that page from one of
>> the existing pages.
>>
>
> Panama is such a small country!  and South America is much larger than my 
> personal experience.  The only correct title for a page I can author would be 
> "Highways in developing countries I know", but most of it would be similar or 
> equal to the Highway_Tag_Africa.
>
I think it would be fine to start Highway_Tag_South_America and note that it is 
a start/proposal,
based on experience in Panama, ABC and XYZ and welcome others to expand and 
verify it.

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

Re: [talk-au] Fire Station Operators

[Andrew Harvey]

On Wed, 8 Jan 2020 at 22:40, Sebastian Spiess  wrote:

> I've done a few. Two raised questions.
>
> Narrabri - There are two fire ' services'  according to LPI map. How to
> tag them?
> https://www.openstreetmap.org/changeset/79336523


Looks like there is a Fire Control Center there, I'd just tag that building
as office=government + operator + name, since they have more of an office
function.


>
>
> and RAYMOND TERRACE Fire Station - This seems to be and old fire station
> as according to https://www.fire.nsw.gov.au/news.php?news=608
> a new one was built. I can't tell if the old one was closed down.
>
> https://www.openstreetmap.org/changeset/79336870


If you're not sure and street level imagery doesn't help, just mark it as
too hard and skip it. You can create a note so that someone with local
knowledge can help.

>
>
>
> Am 2020-01-08 21:24, schrieb Andrew Harvey:
> > If someone has carefully surveyed the name as signposted I leave that
> > intact. branch is not mandatory but helpful since consumers can choose
> > how they want to format the such as "Narooma", "Narooma RFS", "Narooma
> > Rural Fire Brigade", etc. especially when combined with operator. The
> > whole point was to be neutral on the exact name format and not engage
> > in a mass edit to reformat them to be the same, but instead respect
> > names will look different based on signage.
> >
> > On Wed, 8 Jan 2020 at 21:05, Warin <61sundow...@gmail.com> wrote:
> >
> >> I have used the LPI Base Map for both name and operator, see
> >>
> >> Way: Narooma Fire Station (761122699) [operator fire & rescue]
> >>
> >> and
> >>
> >> Way: Narooma Rural Fire Service (761122698)
> >>
> >> I do not bother with the 'branch' as that is usually the leading
> >> value in the name and probably the same as the areas administration
> >> name too.
> >>
> >> The LPI Base Map also gives the area so it can be mapped as a way.
> >>
> >> On 08/01/20 16:13, Graeme Fitzpatrick wrote:
> >>
> >> No, just confirming details was all I was thinking about!
> >>
> >> Thanks
> >>
> >> Graeme
> >>
> >> On Wed, 8 Jan 2020 at 14:57, Andrew Harvey
> >>  wrote:
> >>
> >> It's normally considered okay to check a business website as a
> >> reference and picking up their contact details, but to err on the
> >> side of caution taking a whole database from fire.nsw.gov.au [1] and
> >> mass importing is not advised.
> >>
> >> So I'd suggest not just copying everything from that website. For
> >> the RFS operated fire stations normally the name will indicate this,
> >> or a quick look at google search results may also indicate,
> >> sometimes it's visible on Mapillary based on the signage.
> >>
> >> On Wed, 8 Jan 2020 at 15:39, Graeme Fitzpatrick
> >>  wrote:
> >>
> >> Just a thought?
> >>
> >> Are we allowed to use  https://www.fire.nsw.gov.au/page.php?id=467
> >> or not?
> >>
> >> I've thinking we would still need permission & waiver?
> >>
> >> Big question, I guess, is - are we commercial or not?
> >>
> >> Thanks
> >>
> >> Graeme
> >
> >
> >
> > Links:
> > --
> > [1] http://fire.nsw.gov.au
> > ___
> > Talk-au mailing list
> > Talk-au@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

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 à 

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

[Talk-us] OpenStreetMap US Newsletter Jan 2020

[Maggie Cawley]

Are you subscribed to the OpenStreetMap US Newsletter? Check out the latest
issue here https://mailchi.mp/osmnewsletter/the-openstreetmap-us-newsletter and
subscribe here
https://us3.campaign-archive.com/home/?u=162692bfdedb78ec46fd108a3=801ce00e6d
!

The Newsletter will continue to be released monthly, so please feel free to
share any community events or activities with me any time!

Happy Mapping!
Maggie

*Maggie Cawley*
Executive Director
OpenStreetMap US
www.openstreetmap.us
@MaggieMaps 
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Railway improvements; stations vs. halts

[stevea]

> Clay Smalley  wrote:
> Thanks, all. This pretty much confirms what I expected. I'll go ahead and 
> bring them back to railway=station.


Clay, I know it is an extra ask, I request that you document how you're doing 
this at (minimally):

https://wiki.osm.org/wiki/Tag:railway%3Dhalt#Distinction_Between_Halt_and_Station
and
https://wiki.osm.org/wiki/OpenRailwayMap/Tagging#Stations_.2F_Stops

with the usual "In North America..." distinction text that is similarly 
sprinkled around the latter.

I'd consider it optional (though courteous) to find a place to add this to:
https://wiki.osm.org/wiki/United_States/Railways
and
https://wiki.osm.org/wiki/OpenRailwayMap/Tagging_in_North_America

although I leave how and where exactly (or even whether you do so) up to you.

Thank you,
SteveA

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

Re: [Talk-us] Railway improvements; stations vs. halts

[Clay Smalley]

Thanks, all. This pretty much confirms what I expected. I'll go ahead and
bring them back to railway=station.

-Clay


On Wed, Jan 8, 2020 at 9:34 AM Harald Kliems  wrote:

> FWIW, the German wiki page for railway=halt has a section that
> acknowledges that the German definition and international usage differ:
> "Outside the German-speaking world, railway=halt is defined as an
> unimportation railway station that only has the most basic equipment and
> isn't staffed (in Germany this would correspond to railway station
> categories 6 to 7)."
> https://wiki.openstreetmap.org/wiki/DE:Tag:railway%3Dhalt#Internationale_Definition
>
>  Harald.
>
> On Tue, Jan 7, 2020 at 10:23 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> According to the wiki page, railway=halt is mainly used for "A small
>> station, may not have a platform, trains may only stop on request."
>> The presence of points/switches is only significant in Germany.
>>
>> I would recommend reverting to railway=station for any which have
>> platforms and are regularly scheduled places for the train to stop.
>>
>> -Joseph Eisenberg
>>
>> On 1/8/20, Clay Smalley  wrote:
>> > Hi all,
>> >
>> > Over the last few months, I've been doing some systematic improvements
>> to
>> > the passenger railway network across North America. Much of this has
>> been
>> > filling out public_transport=stop_area relations for every railway
>> station,
>> > including stop positions and platforms, as well as verifying the
>> geometry
>> > of the underlying railways and classifying them (usage=*, service=*). My
>> > goal here is to prepare the map such that route relations can be more
>> > meaningful and accurately describe which track each train uses.
>> >
>> > In the course of doing this, I got a tap on the shoulder [1] and found
>> out
>> > I was using a definition of railway=halt that may not match up with what
>> > people were expecting. As far as I know now, railway=station was
>> originally
>> > intended for stations where trains are always scheduled to stop, and
>> > railway=halt for flag stops (aka request stops). In the German OSM
>> > community, there was a decision made for railway=halt to be used on
>> > stations that are missing switches, which means trains cannot switch
>> > tracks, terminate or reverse direction there—a distinction more
>> relevant to
>> > railway operations and scheduling. Naturally, there are quite a lot
>> more of
>> > these than flag stops.
>> >
>> > I'm in a predicament here. So far, I've mapped all Amtrak stations and
>> > various commuter rail stations across the Northeast according to the
>> > no-switches definition of halt. I'm happy to revert these back to
>> stations
>> > (wherever they aren't flag stops), though I'd like to hear others'
>> thoughts
>> > before going through with that.
>> >
>> > -Clay
>> >
>> > [1] https://www.openstreetmap.org/changeset/77959450
>> >
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> --
> Please use encrypted communication whenever possible!
> Key-ID: 0x34cb93972f186565
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-es] Names en varios idiomas, el caso de Oviedo

[yo paseopor]

En un mundo ideal, en el que todos habláramos el mismo idioma, y pensáramos
de la misma manera... ¡Iep! ¡¡Qué horror!! Eso precisamente no es un mundo
ideal. Borro y vuelvo a empezar.

No te equivocas, lo hice con la información y a petición del Grupo
Asturiano de OSM en Telegram. No estoy de acuerdo con tu correo. Según tú
"la etiqueta debería tener Oviedo que es el nombre común por el que se
conoce la ciudad". Pues fíjate que no creo que ninguno de ese grupo ni
muchos de los ovetenses que conozco opinarían igual. De hecho me dirían
algo parecido a "¡Guaje!,Cagúnla ¿por qué no pone Uviéu, que es como
siempre lo llamamos, ¡ho!" . No todo el mundo opina como tú (defíneme quien
es "la gente" , porque no todo el mundo usa el idioma que tú usas como
principal por lo que otros lo conocen de otra manera). Usas el español,
como lo uso yo. Pero eso no significa que sea la única versión...ni la
principal. Y dado el desacuerdo para eso están las leyes. Y en el caso del
Principado de Asturias,  tal y como puedes leer en wikipedia, desde 1998 va
de la siguiente manera. https://es.m.wikipedia.org/wiki/Toponimia_asturiana

Además según nuestra wiki en la página
https://wiki.openstreetmap.org/wiki/ES:Directrices_de_etiquetado_espa%C3%B1olas
en el apartado de "Localides con nombres en lenguas cooficiales" puedes
leer que "Al igual que para las vías, en aquellas localidades que posean
dos nombres oficiales reconocidos en diferentes lenguas el tag name se
rellenará con las versiones en ambas lenguas, separadas por / y en el orden
que fijen las autoridades (en la mayoría de casos será name
=*nombre en castellano /
nombre en lengua cooficial*)."

Empecemos a entender que el mundo funciona así, que las cosas no se dicen
en castellano y para que los lugareños se queden tranquilos le añadimos la
coletilla "en otro idioma y oficialmente".Actualmente la ciudad de Oviedo,
tal y como se puede ver en buena parte de la nueva señalética asturiana
tiene la forma que puedes ver en OSM. Nadie impedirá que uses ni los campos
name:es ni name:ast pero en la actualidad para ir a Uviéu, a Mieres del
Camín y a Xixón entre otras en las señales te las encontrarás tal y como
puedes ver reflejado en OSM.

PD: Recuerdo una canción que escuchaba de pequeño que decía: "Ven a Uviéu y
sal si puedes/ te lo diz un carbayón / Ven a Uviéu y sal si puedes/
cantando esta canción , así que no tiene pinta de ser una moda actual ;)
PD2: Gracias Youtube . Puxa Vicente Díaz
https://www.youtube.com/watch?v=Tjx4SM-TvBo

Salut i Puxa Sporting :P
yopaseopor

On Wed, Jan 8, 2020 at 9:42 AM Alejandro Moreno  wrote:

> Volvemos a una discusión que ya ha habido por aquí con anterioridad.
>
> Si no me equivoco, @yopaseopor cambió hace unos meses la etiqueta name de
> Oviedo para poner "Oviedo / Uviéu" debido a que el ayuntamiento aprobó ese
> nombre como nombre oficial para la ciudad. Para mí es un error poner ese
> nombre en la etiqueta name y la etiqueta debería tener Oviedo que es el
> nombre común por el que se conoce la ciudad y en las etiquetas name:es y
> name:ast los respectivos nombres en dichos idiomas. En el caso de que
> oficialmente el nombre cambie tenemos la etiqueta official_name para
> definirlo pero que cambie el nombre oficial/legal no implica que cambie el
> nombre común con el que la gente llamamos a la ciudad.
> Lo mismo pasa con un montón de ciudades de la zona como Gijón.
>
> Pensaba que estas casuísticas ya habían quedado fijadas pero lo expongo
> por aquí antes de cambiar nada por si me equivocase y para que la postura
> que adopte la comunidad la reflejemos en
> https://wiki.openstreetmap.org/wiki/ES:Nombres_multiling%C3%BCes#Spain
> para que quede claro para todo el mundo.
>
> Un saludo.
> Alejandro
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-it] Broken road at Lago di Garda camp La Quercia

[Volker Schmidt]

I cannot reproduce your problem
For me it works on this website: https://routing.openstreetmap.de/.
This is the short link to the route: https://osm.li/PBE
I attach the GPX file

In your destination list you use the campsite node "La Quercia",
In your photo ( https://ibb.co/3BqZXfC  ) you use
the street "Viale La Quercia".
But for me both variants work.
Please note that if you use the street name with with no house number, OSRM
will take the half-way point of the way corresponding to the street as
destination. This may have mislead you with your test.

Volker
Padova, Itaòy


route.gpx
Description: Binary data
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Modifica costruzione per aggiunta entrate con civici

[Martin Koppenhoefer]

pratticamente, risolvi come pensi sia meglio ;-)

Ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] Railway improvements; stations vs. halts

[Harald Kliems]

FWIW, the German wiki page for railway=halt has a section that acknowledges
that the German definition and international usage differ: "Outside the
German-speaking world, railway=halt is defined as an unimportation railway
station that only has the most basic equipment and isn't staffed (in
Germany this would correspond to railway station categories 6 to 7)."
https://wiki.openstreetmap.org/wiki/DE:Tag:railway%3Dhalt#Internationale_Definition

 Harald.

On Tue, Jan 7, 2020 at 10:23 PM Joseph Eisenberg 
wrote:

> According to the wiki page, railway=halt is mainly used for "A small
> station, may not have a platform, trains may only stop on request."
> The presence of points/switches is only significant in Germany.
>
> I would recommend reverting to railway=station for any which have
> platforms and are regularly scheduled places for the train to stop.
>
> -Joseph Eisenberg
>
> On 1/8/20, Clay Smalley  wrote:
> > Hi all,
> >
> > Over the last few months, I've been doing some systematic improvements to
> > the passenger railway network across North America. Much of this has been
> > filling out public_transport=stop_area relations for every railway
> station,
> > including stop positions and platforms, as well as verifying the geometry
> > of the underlying railways and classifying them (usage=*, service=*). My
> > goal here is to prepare the map such that route relations can be more
> > meaningful and accurately describe which track each train uses.
> >
> > In the course of doing this, I got a tap on the shoulder [1] and found
> out
> > I was using a definition of railway=halt that may not match up with what
> > people were expecting. As far as I know now, railway=station was
> originally
> > intended for stations where trains are always scheduled to stop, and
> > railway=halt for flag stops (aka request stops). In the German OSM
> > community, there was a decision made for railway=halt to be used on
> > stations that are missing switches, which means trains cannot switch
> > tracks, terminate or reverse direction there—a distinction more relevant
> to
> > railway operations and scheduling. Naturally, there are quite a lot more
> of
> > these than flag stops.
> >
> > I'm in a predicament here. So far, I've mapped all Amtrak stations and
> > various commuter rail stations across the Northeast according to the
> > no-switches definition of halt. I'm happy to revert these back to
> stations
> > (wherever they aren't flag stops), though I'd like to hear others'
> thoughts
> > before going through with that.
> >
> > -Clay
> >
> > [1] https://www.openstreetmap.org/changeset/77959450
> >
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
Please use encrypted communication whenever possible!
Key-ID: 0x34cb93972f186565
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Railway improvements; stations vs. halts

[stevea]

I forgot to mention that I have also directly edited the OpenRailwayMap/Tagging 
wiki itself by sprinkling several "In North America..." text blurbs.  These are 
nearly always left intact by other wiki reviewers (and that page is very well 
watched and heavily/strictly "policed" for accuracy).

Finally, you could also add a similar "In North America..." text blurb directly 
to 
https://wiki.osm.org/wiki/Tag:railway%3Dhalt#Distinction_Between_Halt_and_Station
 (there is already one bullet point that is specific to Germany).

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

Re: [Talk-us] Railway improvements; stations vs. halts

[stevea]

Good question, Clay.  I agree with Joseph's recommendation to revert to 
railway=station.  Germany (likely the densest national rail network in the 
world, as well as home to OpenRailwayMap.org) has a rather exacting set of 
definitions for distinct specificity on its rail in OSM, to the point where its 
rail mapping in our project (slightly) diverges from how much the world maps 
rail in OSM.  For example, Germany uses route=tracks relations, we do not in 
the US, and there is no apparent "ill effect" to mapping (as in ORM) or routing 
(as far as I can tell) after many years of all states in the USA doing this.

We also have United_States/Railways and OpenRailwayMap/Tagging_in_North_America 
(under construction) which document these divergences (where known).  These 
wiki are exactly where such "we do things like this in the USA" (or North 
America) can be found.  Finally, there is a trend towards state-level 
/Railroads wikis.  While these state-level wiki don't (need to) mention 
railway=station as we discuss it, you might want to add some clarification to 
the national and continental-level wiki that in the USA we are doing a sort of 
conflation of halt and station as you describe it (and that this diverges from 
how the ORM wiki strictly defines halt).

SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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: [Talk-it] Modifica costruzione per aggiunta entrate con civici

[Federico Cortese]

O meglio ancora lasci gli ingressi fronte strada senza civico (se non
ci sono i civici in loco come sembrerebbe) e metti il civico dove c'è
la scaletta.
Tipo così:
https://drive.google.com/file/d/1nOOwCe3o4Vsi2dUFK9y9SwP8jf7akbZ6/view?usp=sharing

Ciao,
Federico

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

Re: [Talk-it] Modifica costruzione per aggiunta entrate con civici

[Federico Cortese]

On Wed, Jan 8, 2020 at 2:47 PM Matteo Bini via Talk-it
 wrote:
>
> Vorrei aggiungere i numeri civici 427 e 429
> alle entrate di quest'edificio [1].
> Tuttavia, se li collocassi nella loro posizione reale,
> sarei costretto a modificare i nodi
> come illustra quest'immagine che ho caricato su Google Drive [2].
>
> La sezione che rimarrebbe esclusa non fa davvero parte della costruzione,
> in quanto si tratta di un gruppo di piccoli giardini privati
> di proprietà di chi abita nel palazzo.

Secondo me la mappatura dell'edificio va più o meno bene se quanto
vedo qui è corretto:
https://www.google.it/maps/@43.7727404,11.090432,3a,78.9y,255.58h,88.21t/data=!3m6!1e1!3m4!1soUUY-zfAAX2G7wizi3vENA!2e0!7i16384!8i8192

Direi quindi che non dovresti modificare l'edificio, ma piuttosto
correggere la posizione del civico 425, come in questo screenshot:
https://drive.google.com/file/d/12R9T3XCtUBRpTJuruWQBI8u-rDIF94oR/view?usp=sharing

Poi puoi aggiungere scale e tutto quel che vuoi, ma il primo passo e
il più importante è posizionare bene i civici.

Ciao,
Federico

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

Re: [OSM-talk] mapping outside Europe

[Mario Frasca]

Hi Maarten, Mateusz, Marc, Pierre, everybody:

On 08/01/2020 01:32, Maarten Deen wrote:
If they don't use the wiki, then who complains about missing local 
information in the wiki? 


these are chained questions: who complains? who complains about missing 
local information (in the wiki)?


I'm not sure it is of any relevance, so I don't expect followup on this, 
but it will help you understand my experience:


---

speaking about Panama: apart from me trying to correct bad practices, 
establishing a Telegram group, inviting people to it, trying to engage 
editors in discussions, contacting organizations sponsoring massive 
edits, commenting on changesets, writing personal messages to the 
author's OSM account, looking them up on Facebook, documenting or 
proposing in the Wiki, requesting a block for people who keep adding 
information that always needs the same kind of correction…, there has 
been so little response that I can't generalize, I can briefly mention 
the few major incidents:


- on the Telegram group (https://t.me/Comunidad_OSM_Panama) we had a 
representative of a GIS-group in the second largest town in the country, 
periodically doing massive exports to the database, sponsored by Unachi 
(Universidad de Chiriquí), organizing GIS courses ending with these 
collectively signed exports, using accounts that are only active in 
these occasions.  He announced one activity they would organize.  two of 
us (both Europeans) tried to make two points clear: no data from Google, 
and please consider the organized edits directives.  the guy left the 
group because of our bureaucratic/dictatorial attitude.  I don't know 
how their activity developed, it did not (yet) reflect on the OSM database.


- I recently removed some fifty thousand relations "no-u-turn", added by 
people working for MiBus (Panama City), needed for their navigation 
software, but not corresponding to anything on the ground.  I had tried 
to reach for the authors, but only after removing the objects they 
reacted.  the reaction was in private email exchange, not on my 
changesets, until I invited one of the guys to do so 
(https://openstreetmap.org/changeset/77387510). according to me, there 
never was any discussion.  one of the guys joined the Panama Telegram 
group, but never reacted to the invitations to discuss the issue.


- occasionally, people write funny changesets comments, like here: 
https://www.openstreetmap.org/changeset/77592575; 
https://www.openstreetmap.org/changeset/68335335


- some time ago the Telegram group received an invitation to an ESRI 
meeting.  I participated, and volunteered my summary of the meeting, and 
the story ended there, I have no idea what happened next.  I met 
personally three of the editors, but that did not establish a 
communication line with any of them.


my very personal impression: I think there is a cultural difficulty 
here, preventing people from expressing one's opinions in public, 
offering it for criticism.  I do not know how they do, to reach a 
consensus, and again my personal impression is that they don't even try, 
each does their stuff, try not to stand in the way of others, expect 
others to do the same.  my (again very personal) conclusion is to drop 
trying myself (I even left the Telegram group I had founded, for I 
thinks it serves no purpose) and to keep documenting things publicly, 
either in Spanish or in English, in the wiki, but again without 
expecting feedback from local mappers.


---

more constructively:
On 08/01/2020 02:54, Mateusz Konieczny wrote:
Is a new photo differing in content (confusing for Europeans in the 
similar way as original
was confusing for people from Panama)? Then both should be present, 
one in the infobox,

one in the article text.


I like this one.  :-)

we could invite people from different areas to contribute relevant pictures.

I can do Panama, and look up in my archives for other regions I 
visited.  I can't obviously cover the rest of the world, but we as OSM 
editors surely can.


On 08/01/2020 04:29, Marc Gemis wrote:


What I meant with "write the wiki page you want to see" is: create a
new wiki page "Highways in Panama" or "Highways in South America",
preferable in Spanish and Portuguese and link to that page from one of
the existing pages.


Panama is such a small country!  and South America is much larger than 
my personal experience.  The only correct title for a page I can author 
would be "Highways in developing countries I know", but most of it would 
be similar or equal to the Highway_Tag_Africa.


point is: would locals like being told "use the African guidelines"?

please nobody from Africa takes offense, please, but telling Southern 
Americans that they should apply African logic for their situation is 
very likely to sound as an offense to them, however correct the case 
might be (and actually, things here can be quite worse than the pictures 
in the 

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

[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

[Talk-de] Fwd: [fossgis-verein] Programm FOSSGIS-Konferenz 2020 veröffentlicht und Ticketverkauf öffnet

[Michael Kugelmann via Talk-de]

FYI.


 Weitergeleitete Nachricht 
Betreff:[fossgis-verein] Programm FOSSGIS-Konferenz 2020
veröffentlicht und Ticketverkauf öffnet
Datum:  Tue, 7 Jan 2020 21:49:48 +0100
Von:konferenz-o...@fossgis.de 
Organisation:   FOSSGIS e.V.
An: verein-li...@fossgis.de



Sehr geehrte FOSSGIS-Aktive, sehr geehrte FOSSGIS-Anfänger,
OSM-Begeisterte und Interessierte,

Vom 11. bis 14. März 2020 tagt die FOSSGIS-Konferenz 2020 in Freiburg.
Die Konferenz wird vom gemeinnützigen FOSSGIS e.V., der
OpenStreetMap-Community und dem Local Team rund um die Universität
Freiburg organisiert.

Die FOSSGIS-Konferenz ist die im D-A-CH-Raum führende Konferenz für
Freie und Open Source Software für Geoinformationssysteme sowie für die
Themen OpenStreetMap und Open Data. An vier Tagen werden in Vorträgen
für Einsteiger und Experten, Hands-On-Workshops, Demo-Sessions und 
Anwendertreffen Einblicke in die neusten Entwicklungen und
Anwendungsmöglichkeiten von Softwareprojekten gegeben.

Die Teilnehmer*innenanzahl ist aus Kapazitätsgründen auf 500 Personen
begrenzt. Aus diesem Grund bitten wir um eine frühzeitige Anmeldung. Ab
08.01.2020 ist der Ticketverkauf geöffnet und auf der Konferenzhomepage
zu finden: https://www.fossgis-konferenz.de/2020/anmeldung/.

*Preise FOSSGIS-Konferenz 2020:*
Standardticket (Normalpreis): € 190
Standardticket (Frühbucherrabatt für die ersten 50 Tickets): € 150
Studierendenticket: € 40
Community-Ticket: € 0*
Workshop: € 100

Im Konferenzticket enthalten: FOSSGIS-Konferenz-Teilnahme, Pausensnack,
Tasche und wenn bestellt Tagungsband, T-Shirt und Abendveranstaltung.
(*Das kostenfreie Community-Ticket ist vorgesehen für Aktive aus dem
Open-Source- und OpenStreetMap-Bereich – Entwickler, aktive Mapper –
sowie für aktive Helfer bei der Konferenz 2020)

Am Abend des ersten Konferenztages, dem 11. März 2020, findet die
Abendveranstaltung "Schwätzli uffem Campus" statt
[https://fossgis-konferenz.de/2020/socialevents/], die Anmeldung dazu
ist bei der Ticketbuchung möglich.

*Helfer:*
Freiwillige Helfer sind eingeladen und willkommen während der Konferenz
bei den Videoaufnahmen, als Sessionleiter oder beim Catering zu
unterstützen. Bei Interesse bitte im Helfersystem
(https://helfer.fossgis.de/) anmelden und eine E-Mail an
konferenz-o...@fossgis.de senden. Helfer dürfen das kostenfreie
"Community-Ticket" buchen.

*OSM-Event:*
Die Konferenz setzt sich ab Freitagnachmittag mit
OpenStreetMap-spezifischen Vorträgen fort. Beginn ist 15:30 Uhr mit dem 
FOSSGIS-Jeopardy. Am 14. März 2020 findet der traditionelle OSM-Samstag
als OSM-UnKonferenz (BarCamp) statt. Das Programm wird am Samstagmorgen
nach Begrüßung und Einführung durch die Teilnehmer*innen gemeinsam
festgelegt. Die Teilnahme am OSM-Event ist kostenfrei und unabhängig von
der FOSSGIS-Konferenz möglich. Für eine gute Planung ist eine Anmeldung
über das FOSSGIS-Konferenz-Anmeldesystem sehr erwünscht. Weitere
Informationen zum OSM-Samstag gibt es unter
https://wiki.openstreetmap.org/wiki/FOSSGIS_2020/OSM-Samstag.

Weitere Informationen zur FOSSGIS-Konferenz (Programm, Anreise,
Unterkunft, Anmeldung, Helfermöglichkeiten und Sponsoring) entnehmen Sie
bitte der Konferenzhomepage: https://www.fossgis-konferenz.de/2020/.

*Termine und Informationen:*
    FOSSGIS-Konferenz 2020: 11.-14. März 2020
    Programm: https://www.fossgis-konferenz.de/2020/programm/
    Anmeldung ab 08.01.2020
https://www.fossgis-konferenz.de/2020/anmeldung/
    Social Events: https://fossgis-konferenz.de/2020/socialevents/
    OSM-Samstag:
https://wiki.openstreetmap.org/wiki/FOSSGIS_2020/OSM-Samstag
    Alle Informationen: https://www.fossgis-konferenz.de/2020/
    Fragen an konferenz-o...@fossgis.de
    Twitter: https://twitter.com/FOSSGIS_Konf #FOSSGIS2020

Das FOSSGIS-Konferenz-Organisationsteam freut sich darauf, Sie zu einer
spannenden FOSSGIS-Konferenz in Freiburg begrüßen zu dürfen.


--
.
FOSSGIS-Konferenz - OSM-Samstag - 11.-14. März 2020 in Freiburg im Breisgau
https://www.fossgis-konferenz.dehttps://twitter.com/FOSSGIS_Konf
.

--

FOSSGIS 2020, die Konferenz für Open Source GIS mit OpenData und
OpenStreetMap in Freiburg im Breisgau!
11.-14. März 2020 an der Universität Freiburg
https://fossgis-konferenz.de/2020/

FOSSGIS Veranstaltungen 2019
https://www.fossgis.de/node/322

FOSSGIS e.V, der Verein zur Förderung von Freier Software aus dem
GIS-Bereich und Freier Geodaten!
https://www.fossgis.de/ https://twitter.com/fossgis_eV


Verein-Liste mailing list
verein-li...@fossgis.de
https://lists.fossgis.de/mailman/listinfo/verein-liste

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

Re: [talk-cz] [osm_sk] WeeklyOSM CZ 492

[Michal Palenik]

super, presne túto tagovaciu schému som hľadal.

na www.oma.sk budem čochvíľa renderovať...

m
On Tue, Jan 07, 2020 at 04:15:06PM +0100, Robert C. wrote:
> Věděli jste …
> … že můžete mapovat vybavení hřišť jako nezávislé objekty v OSM s pomocí
> tagu Key:playground?
> 
> -> vie niekto aj o mape kde by sa playground renderoval? (myslim samotne
> prvky)
> 
> ut 7. 1. 2020 o 10:40 Tom Ka  napísal(a):
> 
> > Ahoj, je dostupné vydání 492 týdeníku WeeklyOSM:
> >
> > https://weeklyosm.eu/cz/archives/12676
> >
> > * CZ a SK překlad rad pro komentáře.
> > * Evoluce OSM v Irsku.
> > * Manuál Overpass API.
> > * Proč nový Switch2OSM?
> > * Den otevřených dat.
> > * Novinky iD v2.17.0.
> > * Nej mapy za 2019.
> > * Jak na obrázky týdne?
> > * Útoky na GPS v Číně.
> > * Návrh změn v Apple Maps.
> > * 35let klimatu Arktidy.
> > * GPS pro cyklisty s OSM.
> >
> > Pěkné počtení ...
> >
> > --
> > Túto správu ste prijali, pretože ste prihlásení na odber správ skupiny
> > „Openstreetmap Slovakia“ služby Skupiny Google.
> >
> > Ak chcete zrušiť odber tejto skupiny a prestať od nej prijímať e-maily,
> > pošlite e-mail na adresu osm_sk+unsubscr...@googlegroups.com.
> > Ak chcete zobraziť túto diskusiu na webe, prejdite na adresu
> > https://groups.google.com/d/msgid/osm_sk/CAHqEKC1EjeNxPzGouHUQ6Mo418j-ELOumUbHvMnE%2BJFrMKV6Hw%40mail.gmail.com
> > .
> >
> 
> 
> -- 
> S pozdravom
> Robert Cetner
> 
> -- 
> Túto správu ste prijali, pretože ste prihlásení na odber správ skupiny 
> „Openstreetmap Slovakia“ služby Skupiny Google.
> 
> Ak chcete zrušiť odber tejto skupiny a prestať od nej prijímať e-maily, 
> pošlite e-mail na adresu osm_sk+unsubscr...@googlegroups.com.
> Ak chcete zobraziť túto diskusiu na webe, prejdite na adresu 
> https://groups.google.com/d/msgid/osm_sk/CACF2UbaozWgrMo4kx1j6MdEsi3AbsAjahSf_TByEoYC0L3kPxA%40mail.gmail.com.

-- 
michal palenik
www.freemap.sk
www.oma.sk

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-de] OSM auf den Chemnitzer Linux-Tagen (14.3.-15.3.)

[Michael Kugelmann via Talk-de]

Am 07.01.2020 um 17:34 schrieb Christopher Lorenz via Talk-de:

Die Idee mit dem stream hat ich auch schon. Aber Samstag wird ja bislang soweit 
ich weiß nur Eröffnung und Abschluss aufgezeichnet bzw. Gestreamt.

Das Aufzeichen/Streaming am OSM Samstag hängt sehr stark vom jeweiligen
Thema ab. Da Unconferenz/Barcamp/... wird das erst kurzfristig
sntschieden werden. In den vergangenen Jahren war das immer auch nur
einer von mehreren Räumen.


Grüße,
Michael.


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

Re: [Talk-us] User in Florida changing several motorways to trunk

[Mike N]

On 1/8/2020 9:20 AM, James Mast wrote:
Honest mistakes on his end? Perhaps.� But I'm just seeing way too many 
downgrades to be conformable with his 'highway type' changes to be 
honest.� There's probably quite a few roads that he retagged as primary 
that need to be re-upgraded to trunk and so on. Routing algorithms have 
probably been seriously damaged by some of the changes unfortunately.


This is the first case I remember where the trend was to downgrade 
everything in sight, and he hasn't given the usual alternative point of 
reference to clarify where he was coming from.


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

Re: [Talk-us] Railway improvements; stations vs. halts

[Greg Troxel]

Clay Smalley  writes:

> Over the last few months, I've been doing some systematic improvements to
> the passenger railway network across North America. Much of this has been
> filling out public_transport=stop_area relations for every railway station,
> including stop positions and platforms, as well as verifying the geometry
> of the underlying railways and classifying them (usage=*, service=*). My
> goal here is to prepare the map such that route relations can be more
> meaningful and accurately describe which track each train uses.
>
> In the course of doing this, I got a tap on the shoulder [1] and found out
> I was using a definition of railway=halt that may not match up with what
> people were expecting. As far as I know now, railway=station was originally
> intended for stations where trains are always scheduled to stop, and
> railway=halt for flag stops (aka request stops). In the German OSM
> community, there was a decision made for railway=halt to be used on
> stations that are missing switches, which means trains cannot switch
> tracks, terminate or reverse direction there—a distinction more relevant to
> railway operations and scheduling. Naturally, there are quite a lot more of
> these than flag stops.
>
> I'm in a predicament here. So far, I've mapped all Amtrak stations and
> various commuter rail stations across the Northeast according to the
> no-switches definition of halt. I'm happy to revert these back to stations
> (wherever they aren't flag stops), though I'd like to hear others' thoughts
> before going through with that.

I find the notion that "no switches -> halt" notion bizarre and brand
new.  So I would very much be in favor of you going back to what I
consider a normal definition.   I'd say that's railyway=halt if there
are *no* scheduled stops.

Around me, the commuter rail has mostly what I'd calls stations:  fixed
infrastructure for trains and scheduled stops.   There are a few places
that are called "flag stops", but that really means:

  train stops if a passenger on the train asks, or if people are visible
  on the platform

but typically such places have some trains alwys stop and some treat
them as flag stops.  So I think they ar railway=station.



I would say if people want to tag absence of switches/etc. that should
be some train-nerd extra key.  This is not relevant to people or routers
using the data.

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

Re: [Talk-us] USFS trail/road/route numbers

[Paul Johnson]

On Tue, Jan 7, 2020 at 3:15 PM Tod Fitch  wrote:

> In my area there seems to be a mix of how the US Forest Service route
> numbers are tagged on roads and trails. The main variations seem to be:
>
> name=“Forest Route 9N24”
> name=“FR 9N24”
> alt_name=“Forest Route 9N24”
> alt_name=“FR 9N24”
> ref=“FR 9N24”
> ref=“9N24”
>

Well, name should only be the name.  So the first four are wrong, refs are
not names.


> Things I’ve seen in the wiki that might pertain cover “National Forest
> Trails” [1] which seems to want a tag of “route_no” or “trail_no”. That
> just seems wrong.
>
> And in the United States roads tagging [2] which seems to prefer tagging
> like:
>
> ref=“NFR 9N24”
>
> Which I don’t recall seeing in my area.
>
> What should the preferred tagging be? My inclination would be to migrate
> the tagging in my area toward that listed on the US road tagging page (e.g.
> ref=“NFR 9N24”) even though my preference (for printed map display
> purposes) would be to simply use ref=“9N24”.
>

I'd go with ref=NF 9N24 and strongly consider making a route relation for
it.  Ideally, this would all be moot and it'd just be a refless, nameless
way with the route being on the relation alone (same could be said of
roads) but for some reason people don't want to kill the dinosaur on that
still.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Modifica costruzione per aggiunta entrate con civici

[Simone Saviolo]

Il giorno mer 8 gen 2020 alle ore 15:56 Alessandro Sarretta <
alessandro.sarre...@gmail.com> ha scritto:

> On 08/01/20 15:09, Simone Saviolo wrote:
> > Modifica la forma, aggiungi i civici nella posizione giusta, tagga i
> > giardini privati come giardini privati. Già che ci sei, migliora la
> > forma dell'edificio, che probabilmente non ha angoli di 80 gradi come
> > quelli che sono disegnati attualmente :)
>
> Concordo con Simone,
>
> Potresti anche aggiungere le scale che portano ai singoli civici...
>

Giusto: l'ideale sarebbe mappare il percorso pedonale (o le scale, non ho
capito) che dal cancello sulla strada porta al civico vero e proprio. Così
un navigatore potrebbe trovare la destinazione (ad esempio il civico 429),
trovare la footway collegata, vedere che passa da un cancello, collegato ad
un marciapiede collegato ad una strada.

Ciao,

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

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

Re: [Talk-us] User in Florida changing several motorways to trunk

[Paul Johnson]

On Wed, Jan 8, 2020 at 8:22 AM James Mast  wrote:

> As for restoring the 'motorway' roads, I've honestly just been manually
> fixing them.  Sure, takes longer, but allows me to catch the 'Emergency
> U-Turn' crossovers that are improperly tagged as a '_link', and fix them at
> the same time.  I've cleared & restored the proper motorway/motorway_link
> tags on FL-414, FL-429, FL-451, & FL-453 manually so far.  Leaves FL-408,
> FL-417, FL-528, and a few non-state roads around Walt Disney World.  But
> those routes are some pretty long ones, and will take some time to fix
> since they have several exits along them.
>

Not a bad time to doublecheck lane tagging and capture that detail, too.
I'm working through that on I 405 in LA right now, which somehow still had
mostly barely-improved-since-TIGER data.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Modifica costruzione per aggiunta entrate con civici

[Alessandro Sarretta]

On 08/01/20 15:09, Simone Saviolo wrote:
Modifica la forma, aggiungi i civici nella posizione giusta, tagga i 
giardini privati come giardini privati. Già che ci sei, migliora la 
forma dell'edificio, che probabilmente non ha angoli di 80 gradi come 
quelli che sono disegnati attualmente :)


Concordo con Simone,

Potresti anche aggiungere le scale che portano ai singoli civici...

Ale


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

Re: [Talk-us] User in Florida changing several motorways to trunk

[James Mast]

Well, I have noticed he has downgrade a ton of roads that were 'trunk' for 6+ 
years, which leads me to be believe they were tagged correctly if no other 
local mapper touched them in that time period.  There were also a few ways in 
that changeset you mentioned that he changed to secondary that at a previous 
time was trunk (till he changed it to primary late last year). See: 
https://www.openstreetmap.org/way/216669397/

Honest mistakes on his end? Perhaps.  But I'm just seeing way too many 
downgrades to be conformable with his 'highway type' changes to be honest.  
There's probably quite a few roads that he retagged as primary that need to be 
re-upgraded to trunk and so on.  Routing algorithms have probably been 
seriously damaged by some of the changes unfortunately.

As for restoring the 'motorway' roads, I've honestly just been manually fixing 
them.  Sure, takes longer, but allows me to catch the 'Emergency U-Turn' 
crossovers that are improperly tagged as a '_link', and fix them at the same 
time.  I've cleared & restored the proper motorway/motorway_link tags on 
FL-414, FL-429, FL-451, & FL-453 manually so far.  Leaves FL-408, FL-417, 
FL-528, and a few non-state roads around Walt Disney World.  But those routes 
are some pretty long ones, and will take some time to fix since they have 
several exits along them.

From: Levente Juhász 
Sent: Wednesday, January 8, 2020 7:56 AM
To: talk-us 
Cc: James Mast 
Subject: Re: [Talk-us] User in Florida changing several motorways to trunk

FYI the user also joined the changeset discussion as of recently. Based on the 
message and previous changeset comments (e.g. "trunk-primary fixes (that i 
messed up)" in 
https://www.openstreetmap.org/changeset/79132672#map=12/28.4681/-81.4027) it 
seems to be an honest mistake.

I can help out with fixes over the weekend. Let me know if you come up with a 
plan to restore highway=motorway tags.

Levente

On Tue, Jan 7, 2020 at 8:39 PM James Mast 
mailto:rickmastfa...@hotmail.com>> wrote:
I was just alerted to this by a friend, and thought I'd post about it here as 
well, since I don't really have the time to work on doing all the reverting 
that unfortunately needs to be done here (there's a lot).

But over the last 2 weeks, there's been a user changing several 100% motorways 
(& are toll highways to boot) that just happen to be state highways in Florida 
from motorway to trunk.  This is mostly as far as I can tell in the Orlando 
area, but might affect other areas in FL too.

I did leave the user a message on Changeset 79155661 ( 
https://www.openstreetmap.org/changeset/79155661 ).  Hoping he will see it, but 
with all the major highways that have been seriously demoted in priority that 
could seriously affect routing very badly, I honestly couldn't wait for a 
response before I posted a message to here as well.

Anybody willing to help out here in restoring the motorway tags to the proper 
highways?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Modifica costruzione per aggiunta entrate con civici

[Simone Saviolo]

Il giorno mer 8 gen 2020 alle ore 14:47 Matteo Bini via Talk-it <
talk-it@openstreetmap.org> ha scritto:

> Buon pomeriggio a tutta la lista.
> Vorrei aggiungere i numeri civici 427 e 429
> alle entrate di quest'edificio [1].
> Tuttavia, se li collocassi nella loro posizione reale,
> sarei costretto a modificare i nodi
> come illustra quest'immagine che ho caricato su Google Drive [2].
>
> La sezione che rimarrebbe esclusa non fa davvero parte della costruzione,
> in quanto si tratta di un gruppo di piccoli giardini privati
> di proprietà di chi abita nel palazzo.
> Allo stesso tempo credo che da un punto di vista catastale
> possa considerarsi un blocco unico, visto che l'accesso ai portoni
> è possibile da un solo punto, che consiste in una scala sul marciapiede
> dove al momento è mappato il numero 425.
>
> Io ho pensato a due possibili soluzioni:
> la prima consisterebbe nell'inserire i civici nell'entrata già presente,
> ignorando la collocazione precisa;
> la seconda nel modificare il perimetro della costruzione
> come nell'immagine sopramenzionata.
>
> Come mi suggerite di procedere?
>

Modifica la forma, aggiungi i civici nella posizione giusta, tagga i
giardini privati come giardini privati. Già che ci sei, migliora la forma
dell'edificio, che probabilmente non ha angoli di 80 gradi come quelli che
sono disegnati attualmente :)

Ciao,

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

[Talk-it] Modifica costruzione per aggiunta entrate con civici

[Matteo Bini via Talk-it]

Buon pomeriggio a tutta la lista.
Vorrei aggiungere i numeri civici 427 e 429
alle entrate di quest'edificio [1].
Tuttavia, se li collocassi nella loro posizione reale,
sarei costretto a modificare i nodi
come illustra quest'immagine che ho caricato su Google Drive [2].

La sezione che rimarrebbe esclusa non fa davvero parte della costruzione,
in quanto si tratta di un gruppo di piccoli giardini privati
di proprietà di chi abita nel palazzo.
Allo stesso tempo credo che da un punto di vista catastale
possa considerarsi un blocco unico, visto che l'accesso ai portoni
è possibile da un solo punto, che consiste in una scala sul marciapiede
dove al momento è mappato il numero 425.

Io ho pensato a due possibili soluzioni:
la prima consisterebbe nell'inserire i civici nell'entrata già presente,
ignorando la collocazione precisa;
la seconda nel modificare il perimetro della costruzione
come nell'immagine sopramenzionata.

Come mi suggerite di procedere?
Saluti.

--
Matteo Bini

[1] https://www.openstreetmap.org/way/543857585
[2] https://drive.google.com/open?id=1A0pn-3Sat2gGpInDNc-9zlnMu38ZXVCW

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

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: [Talk-us] User in Florida changing several motorways to trunk

[Levente Juhász]

FYI the user also joined the changeset discussion as of recently. Based on
the message and previous changeset comments (e.g. "trunk-primary fixes
(that i messed up)" in
https://www.openstreetmap.org/changeset/79132672#map=12/28.4681/-81.4027)
it seems to be an honest mistake.

I can help out with fixes over the weekend. Let me know if you come up with
a plan to restore highway=motorway tags.

Levente

On Tue, Jan 7, 2020 at 8:39 PM James Mast  wrote:

> I was just alerted to this by a friend, and thought I'd post about it here
> as well, since I don't really have the time to work on doing all the
> reverting that unfortunately needs to be done here (there's a lot).
>
> But over the last 2 weeks, there's been a user changing several 100%
> motorways (& are toll highways to boot) that just happen to be state
> highways in Florida from motorway to trunk.  This is mostly as far as I can
> tell in the Orlando area, but might affect other areas in FL too.
>
> I did leave the user a message on Changeset 79155661 (
> https://www.openstreetmap.org/changeset/79155661 ).  Hoping he will see
> it, but with all the major highways that have been seriously demoted in
> priority that could seriously affect routing very badly, I honestly
> couldn't wait for a response before I posted a message to here as well.
>
> Anybody willing to help out here in restoring the motorway tags to the
> proper highways?
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[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: [talk-au] Fire Station Operators

[Sebastian Spiess]

I've done a few. Two raised questions.

Narrabri - There are two fire ' services'  according to LPI map. How to 
tag them?

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

and RAYMOND TERRACE Fire Station - This seems to be and old fire station 
as according to https://www.fire.nsw.gov.au/news.php?news=608

a new one was built. I can't tell if the old one was closed down.

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


Am 2020-01-08 21:24, schrieb Andrew Harvey:

If someone has carefully surveyed the name as signposted I leave that
intact. branch is not mandatory but helpful since consumers can choose
how they want to format the such as "Narooma", "Narooma RFS", "Narooma
Rural Fire Brigade", etc. especially when combined with operator. The
whole point was to be neutral on the exact name format and not engage
in a mass edit to reformat them to be the same, but instead respect
names will look different based on signage.

On Wed, 8 Jan 2020 at 21:05, Warin <61sundow...@gmail.com> wrote:


I have used the LPI Base Map for both name and operator, see

Way: Narooma Fire Station (761122699) [operator fire & rescue]

and

Way: Narooma Rural Fire Service (761122698)

I do not bother with the 'branch' as that is usually the leading
value in the name and probably the same as the areas administration
name too.

The LPI Base Map also gives the area so it can be mapped as a way.

On 08/01/20 16:13, Graeme Fitzpatrick wrote:

No, just confirming details was all I was thinking about!

Thanks

Graeme

On Wed, 8 Jan 2020 at 14:57, Andrew Harvey
 wrote:

It's normally considered okay to check a business website as a
reference and picking up their contact details, but to err on the
side of caution taking a whole database from fire.nsw.gov.au [1] and
mass importing is not advised.

So I'd suggest not just copying everything from that website. For
the RFS operated fire stations normally the name will indicate this,
or a quick look at google search results may also indicate,
sometimes it's visible on Mapillary based on the signage.

On Wed, 8 Jan 2020 at 15:39, Graeme Fitzpatrick
 wrote:

Just a thought?

Are we allowed to use  https://www.fire.nsw.gov.au/page.php?id=467
or not?

I've thinking we would still need permission & waiver?

Big question, I guess, is - are we commercial or not?

Thanks

Graeme




Links:
--
[1] http://fire.nsw.gov.au
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


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

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

[Talk-ca] 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-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[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

[Talk-africa] 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-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

[Talk-ht] 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-ht mailing list
Talk-ht@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ht
Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour 
traduire les messages.

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

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: [talk-au] Over 55’s Lifestyle Village = retirement_home ?

[Andrew Harvey]

Those tags look good. place=neighbourhood seems appropriate.

On Wed, 8 Jan 2020 at 15:54, cleary  wrote:

>
> Sorry I'm a little slow to respond to this question. I have been thinking
> about it. particularly in the context of a similar property that I mapped a
> few years ago.  I had previously tagged it as a social_facility but that is
> not correct.
>
> Upon reflection, I have changed the tags for
> https://www.openstreetmap.org/way/313767655
> This is a fenced and gated community for residents aged 50+.  I think the
> area is zoned similar to a caravan park so that residents lease the land
> but provide their own demountable buildings and do not necessarily have
> secure tenure in the location.
>
> I have now tagged it as :
>
> access=private
> addr:street=Majestic Drive
> addr:suburb=Stanhope Gardens
> barrier=fence
> landuse=residential
> min_age=50
> name=Gateway Lifestyle Stanhope Gardens
> old_name=Parklea Garden Village
> operator=Gateway Lifestyle
> place=neighbourhood
> residential=leasehold_only
> source:name=survey
> website=https://www.gatewaylifestyle.com.au/community/stanhope-gardens
>
> Any feedback or comments welcome
>
>
>
>
> On Mon, 6 Jan 2020, at 11:34 AM, Sebastian Spiess wrote:
> > Hi all,
> >
> > is a Over 55’s Lifestyle Village (like this one
> > https://www.middlerockhomevillage.com.au) a amenity=retirement_home?
> >
> > https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dretirement_home
> >
> > I'm not clear if the Lifestyle Village is only a fancy marketing name or
> > not. I've seen such villages and some are past caravan parks that have
> > been re-purposed with the over 55's as clientel.
> >
> > How would you tag this?
> >
> >
> > ___
> > Talk-au mailing list
> > Talk-au@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-au
> >
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Fire Station Operators

[Andrew Harvey]

If someone has carefully surveyed the name as signposted I leave that
intact. branch is not mandatory but helpful since consumers can choose how
they want to format the such as "Narooma", "Narooma RFS", "Narooma Rural
Fire Brigade", etc. especially when combined with operator. The whole point
was to be neutral on the exact name format and not engage in a mass edit to
reformat them to be the same, but instead respect names will look different
based on signage.

On Wed, 8 Jan 2020 at 21:05, Warin <61sundow...@gmail.com> wrote:

> I have used the LPI Base Map for both name and operator, see
>
> Way: Narooma Fire Station (761122699) [operator fire & rescue]
>
> and
>
> Way: Narooma Rural Fire Service (761122698)
>
> I do not bother with the 'branch' as that is usually the leading value in
> the name and probably the same as the areas administration name too.
>
> The LPI Base Map also gives the area so it can be mapped as a way.
>
>
> On 08/01/20 16:13, Graeme Fitzpatrick wrote:
>
> No, just confirming details was all I was thinking about!
>
> Thanks
>
> Graeme
>
>
> On Wed, 8 Jan 2020 at 14:57, Andrew Harvey 
> wrote:
>
>> It's normally considered okay to check a business website as a reference
>> and picking up their contact details, but to err on the side of caution
>> taking a whole database from fire.nsw.gov.au and mass importing is not
>> advised.
>>
>> So I'd suggest not just copying everything from that website. For the RFS
>> operated fire stations normally the name will indicate this, or a quick
>> look at google search results may also indicate, sometimes it's visible on
>> Mapillary based on the signage.
>>
>> On Wed, 8 Jan 2020 at 15:39, Graeme Fitzpatrick 
>> wrote:
>>
>>> Just a thought?
>>>
>>> Are we allowed to use  https://www.fire.nsw.gov.au/page.php?id=467 or
>>> not?
>>>
>>> I've thinking we would still need permission & waiver?
>>>
>>> Big question, I guess, is - are we commercial or not?
>>>
>>> Thanks
>>>
>>> Graeme
>>>
>>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

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

[Talk-it] Broken road at Lago di Garda camp La Quercia

[GoOpti Optimizer]

Hello,



dear Italian community of osm. I am writing to you regarding one
problematic road in Italy, at Lago di Garda, in camp La Quercia, if someone
could help me repair it.



The problematic address is La Quercia, Peschiera - Lazise - BNF, Lazise,
Verona (45.49196, 10.73351) see also picture: https://ibb.co/sysZcRZ



Start point:

6, Via Francesco De Pinedo, Ovest, Verona

Second pickup:

La Quercia, Peschiera - Lazise - BNF, Lazise, Verona

Third pickup:

Bergamo Orio al Serio Airport, 13, Via Aeroporto, Betosca, Orio al Serio,
Bergamo

Finish point:

Somma Lombardo, Varese



OSRM is not able to draw this route, because of second pickup »La Quercia,
Peschiera - Lazise - BNF, Lazise, Verona«.



The problem appears to be on the road *Viale la Quercia*, as it can't turn
the route for 180° (U-turn) after pickup on second point.



*TO:*

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=45.49255%2C10.73498%3B45.49196%2C10.73351#map=18/45.49201/10.73550



*FROM:*

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=45.49196%2C10.73351%3B45.49255%2C10.73498#map=19/45.49242/10.73512





In this picture: https://ibb.co/3BqZXfC I tryed to test what happens, if
the pickup/dropoff location in La Quercia camp would be one node more to
the right, then osrm is able to show the route.

But at the moment it is one node to the left »yellow color« and it dosn't
work.


I am looking forward for your positive responce.



Kind regards,

GoOpti 2
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [talk-au] Fire Station Operators

[Warin]

I have used the LPI Base Map for both name and operator, see

Way: Narooma Fire Station (761122699) [operator fire & rescue]

and

Way: Narooma Rural Fire Service (761122698)

I do not bother with the 'branch' as that is usually the leading value 
in the name and probably the same as the areas administration name too.


The LPI Base Map also gives the area so it can be mapped as a way.


On 08/01/20 16:13, Graeme Fitzpatrick wrote:

No, just confirming details was all I was thinking about!

Thanks

Graeme


On Wed, 8 Jan 2020 at 14:57, Andrew Harvey > wrote:


It's normally considered okay to check a business website as a
reference and picking up their contact details, but to err on the
side of caution taking a whole database from fire.nsw.gov.au
 and mass importing is not advised.

So I'd suggest not just copying everything from that website. For
the RFS operated fire stations normally the name will indicate
this, or a quick look at google search results may also indicate,
sometimes it's visible on Mapillary based on the signage.

On Wed, 8 Jan 2020 at 15:39, Graeme Fitzpatrick
mailto:graemefi...@gmail.com>> wrote:

Just a thought?

Are we allowed to use
https://www.fire.nsw.gov.au/page.php?id=467 or not?

I've thinking we would still need permission & waiver?

Big question, I guess, is - are we commercial or not?

Thanks

Graeme




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

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: [talk-au] Fire Station Operators

[Warin]

The LPI Base Map distinguishes between the 2 ..

And I see no problem in using that source.

Examples
Way: Narooma Rural Fire Service (761122698) [operator Rural Fire Service]
and
Way: Narooma Fire Station (761122699)  [operator Fire and Rescue]

There are quite close together. An advantage of using the LPI Base Map 
is that it gives an area.



On 08/01/20 16:13, Graeme Fitzpatrick wrote:

No, just confirming details was all I was thinking about!

Thanks

Graeme


On Wed, 8 Jan 2020 at 14:57, Andrew Harvey > wrote:


It's normally considered okay to check a business website as a
reference and picking up their contact details, but to err on the
side of caution taking a whole database from fire.nsw.gov.au
 and mass importing is not advised.

So I'd suggest not just copying everything from that website. For
the RFS operated fire stations normally the name will indicate
this, or a quick look at google search results may also indicate,
sometimes it's visible on Mapillary based on the signage.

On Wed, 8 Jan 2020 at 15:39, Graeme Fitzpatrick
mailto:graemefi...@gmail.com>> wrote:

Just a thought?

Are we allowed to use
https://www.fire.nsw.gov.au/page.php?id=467 or not?

I've thinking we would still need permission & waiver?

Big question, I guess, is - are we commercial or not?

Thanks

Graeme




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

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] mapping outside Europe

[Marc Gemis]

+1 to what Mateusz wrote.

What I meant with "write the wiki page you want to see" is: create a
new wiki page "Highways in Panama" or "Highways in South America",
preferable in Spanish and Portuguese and link to that page from one of
the existing pages.
Similar to the Highways in Africa page that I showed you earlier on.
That page did not replace the western-centric page neither.

This is also similar to
https://wiki.openstreetmap.org/wiki/Access_provisions_in_the_United_Kingdom
A page for the British community that explains how to map access for
public footpaths.
The content is not on the (general) highway, path, nor access pages.
It is a dedicated page for a certain geographic region.

So yes, the general page will remain Europe centric, but at least
there will be dedicated pages for other geographic regions. Maybe one
day, the general page will just list all regional variants, one of
them being the European variant.
But please note that the classification of highways is based on the
UK-system and that even European countries had to adapt that to their
local system. But of course, the images are similar for a British
motorway and for a German one.

This page https://wiki.openstreetmap.org/wiki/Highways has a number of
links to pages with regional variations for the classification of
highways under the "Classification" section.

So start small, with dedicated pages and do not try to change existing
pages too much. That will cause more resistance.


regards

m.

On Wed, Jan 8, 2020 at 8:57 AM Mateusz Konieczny
 wrote:
>
> 7 Jan 2020, 20:53 by ma...@anche.no:
>
> On 07/01/2020 14:38, Marc Gemis wrote:
>
> Since OSM is a do-ocracy, do not complain, but write the wiki page you
> want to see
>
>
> that's fine, and I've been doing that for Panama, and for Morocco, but I do 
> not like mapping without having reached a consensus.
>
> for that, we need other mappers to contribute to the discussion, and I never 
> managed to get any far on this in the wiki (actually, not even in the 
> changeset comments).
>
> Is the community using some FB group, Telegram channel or Discord or some 
> even more unusual
> discussion location?
>
> so you say: just revolutionize the overview for the highway tag, without 
> first reaching a consensus?
>
> Obviously no.
>
> replace the Eurocentric pictures with Panama and Morocco pics?
> an edit like this will be reverted after 15 minutes!
>
> Is a new photo differing in content (confusing for Europeans in the similar 
> way as original
> was confusing for people from Panama)? Then both should be present, one in 
> the infobox,
> one in the article text.
>
> Is the new photo usable as illustration in both cases and differs by 
> decoration
> (people are wearing different clothes etc)? Can you link an edit where it was 
> reverted
> (except cases where new non-european image was of a lower quality)?
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

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 

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

[Talk-es] Names en varios idiomas, el caso de Oviedo

[Alejandro Moreno]

Volvemos a una discusión que ya ha habido por aquí con anterioridad.

Si no me equivoco, @yopaseopor cambió hace unos meses la etiqueta name de
Oviedo para poner "Oviedo / Uviéu" debido a que el ayuntamiento aprobó ese
nombre como nombre oficial para la ciudad. Para mí es un error poner ese
nombre en la etiqueta name y la etiqueta debería tener Oviedo que es el
nombre común por el que se conoce la ciudad y en las etiquetas name:es y
name:ast los respectivos nombres en dichos idiomas. En el caso de que
oficialmente el nombre cambie tenemos la etiqueta official_name para
definirlo pero que cambie el nombre oficial/legal no implica que cambie el
nombre común con el que la gente llamamos a la ciudad.
Lo mismo pasa con un montón de ciudades de la zona como Gijón.

Pensaba que estas casuísticas ya habían quedado fijadas pero lo expongo por
aquí antes de cambiar nada por si me equivocase y para que la postura que
adopte la comunidad la reflejemos en
https://wiki.openstreetmap.org/wiki/ES:Nombres_multiling%C3%BCes#Spain para
que quede claro para todo el mundo.

Un saludo.
Alejandro
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

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