Re: [OSM-talk-fr] micro-mapping de parkings

[Muselaar]

J'ai un peu progressé depuis l'autre jour, puisque je suis tombé sur 
cette page du wiki, qui permettrait au contributeur en cause de 
valoriser son travail de micro-mapping. En fait, son erreur n'est pas 
d'avoir micro-mappé, mais d'avoir utilisé le tag amenity=parking en lieu 
et place du amenity=parking_space, et d'avoir fait disparaître la 
surface totale de parking :


https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dparking_space

https://wiki.openstreetmap.org/wiki/Proposed_features/parking

Je l'ai contacté et lui ai indiqué ces pages du wiki, il m'a répondu 
favorablement.


Muselaar

Le 26/08/2018 à 10:13, djakk djakk a écrit :

Moi j’aime bien ce micro-mapping :)


djakk


Le dim. 26 août 2018 à 01:58, Philippe Verdy > a écrit :


Les surfaces de parkings devraient être connectées, longées ou
traversées par des rues ou voies d'accès. Les emplacements précis
(forcément à côté) ne sont donc pas adaptés au amenity=parking.
En revanche on peut tout à fait délimiter en évitant d'inclure des
zones arborées/herbeuses ou réservées aux piétons (hors simples
chemins qui les traverse), tant qu'on maintient une connexion aux
voies d'accès.
Les zones précises amenity=parking_space sont à inclure dans ces
zones de parking et n'ont pas besoin d'être connectées car c'est
le parking englobant qui les "connecte" au réseau

Le sam. 25 août 2018 à 23:42, marc marc mailto:marc_marc_...@hotmail.com>> a écrit :

Bonsoir,

Le 25. 08. 18 à 23:03, Muselaar a écrit :
> https://www.openstreetmap.org/#map=19/47.63874/6.84850

c'est une erreur.
il devrait y a avoir un seul parking qui englobe le tout.
si on veux renseigner au niveau de la place, il y a
amenity=parking_space dont l'utilité par ex est de renseigner
l'endroit précis d'une place PMR ou autre place "thématique"

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

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



___
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] cartographie d'un institut de formation

[Julien Lepiller]

Bonsoir,

j'ai essayé de cartographier un institut de formation qui propose des
formations pour le BAFA/BAFD. Je n'ai pas réussi à trouver de jeu
d'attribut correspondant à ce que j'essayais de cartographier. À
défaut, j'ai indiqué amenity=college. Qu'en pensez-vous ?

Le nœud : https://www.openstreetmap.org/node/5895819346

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

Re: [OSM-talk-fr] Classement ville/village - city/town/village

[djakk djakk]

Et est-ce qu’on dit qu’il ne peut y avoir qu’une seule place=city par zone
d’emploi ?
Reponse : non, certaines sont multipolaires, comme celle de
Roubaix-Tourcoing.


djakk


Le lun. 10 sept. 2018 à 22:02, djakk djakk  a écrit :

> Par exemple : être la capitale d’un bassin de vie ou d’une zone d’emploi
> implique être place=Town au moins.
>
>
> djakk
>
> Le lun. 10 sept. 2018 à 21:43, djakk djakk  a
> écrit :
>
>> Ah je n’avais pas pensé à l’INSEE : zones d’emploi et bassins de vie
>> seraient des critères intéressants.
>>
>>
>> djakk
>>
>> Le lun. 10 sept. 2018 à 21:37, deuzeffe  a
>> écrit :
>>
>>> On 10/09/2018 18:21, djakk djakk wrote:
>>> > Salut !
>>>
>>> Hello,
>>>
>>> > J’aimerai revenir sur la distinction ville/village - où plutôt
>>> > city/town/village : la page wiki française défini un classement par
>>> nombre
>>> > d’habitants, alors que la page wiki anglaise défini un classement par
>>> les
>>> > services accessibles (commerces, services) !
>>>
>>> J'espérais trouver une réponse en consultant le site l'INSEE : la
>>> classification française proposée par le wiki émane probablement du
>>> zonage habituel fait en fonction de la population. Sauf que, bien qu'il
>>> y ait une classif. sur ce critère, l'INSEE ne parle que "d'unités
>>> urbaines". (https://www.insee.fr/fr/information/2571258 )
>>>
>>> On n'est pas plus avancés :(
>>>
>>> --
>>> deuzeffe
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Classement ville/village - city/town/village

[djakk djakk]

Par exemple : être la capitale d’un bassin de vie ou d’une zone d’emploi
implique être place=Town au moins.


djakk

Le lun. 10 sept. 2018 à 21:43, djakk djakk  a écrit :

> Ah je n’avais pas pensé à l’INSEE : zones d’emploi et bassins de vie
> seraient des critères intéressants.
>
>
> djakk
>
> Le lun. 10 sept. 2018 à 21:37, deuzeffe  a
> écrit :
>
>> On 10/09/2018 18:21, djakk djakk wrote:
>> > Salut !
>>
>> Hello,
>>
>> > J’aimerai revenir sur la distinction ville/village - où plutôt
>> > city/town/village : la page wiki française défini un classement par
>> nombre
>> > d’habitants, alors que la page wiki anglaise défini un classement par
>> les
>> > services accessibles (commerces, services) !
>>
>> J'espérais trouver une réponse en consultant le site l'INSEE : la
>> classification française proposée par le wiki émane probablement du
>> zonage habituel fait en fonction de la population. Sauf que, bien qu'il
>> y ait une classif. sur ce critère, l'INSEE ne parle que "d'unités
>> urbaines". (https://www.insee.fr/fr/information/2571258 )
>>
>> On n'est pas plus avancés :(
>>
>> --
>> deuzeffe
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Classement ville/village - city/town/village

[djakk djakk]

Ah je n’avais pas pensé à l’INSEE : zones d’emploi et bassins de vie
seraient des critères intéressants.


djakk

Le lun. 10 sept. 2018 à 21:37, deuzeffe  a écrit :

> On 10/09/2018 18:21, djakk djakk wrote:
> > Salut !
>
> Hello,
>
> > J’aimerai revenir sur la distinction ville/village - où plutôt
> > city/town/village : la page wiki française défini un classement par
> nombre
> > d’habitants, alors que la page wiki anglaise défini un classement par les
> > services accessibles (commerces, services) !
>
> J'espérais trouver une réponse en consultant le site l'INSEE : la
> classification française proposée par le wiki émane probablement du
> zonage habituel fait en fonction de la population. Sauf que, bien qu'il
> y ait une classif. sur ce critère, l'INSEE ne parle que "d'unités
> urbaines". (https://www.insee.fr/fr/information/2571258 )
>
> On n'est pas plus avancés :(
>
> --
> deuzeffe
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Classement ville/village - city/town/village

[deuzeffe]

On 10/09/2018 18:21, djakk djakk wrote:

Salut !


Hello,


J’aimerai revenir sur la distinction ville/village - où plutôt
city/town/village : la page wiki française défini un classement par nombre
d’habitants, alors que la page wiki anglaise défini un classement par les
services accessibles (commerces, services) !


J'espérais trouver une réponse en consultant le site l'INSEE : la 
classification française proposée par le wiki émane probablement du 
zonage habituel fait en fonction de la population. Sauf que, bien qu'il 
y ait une classif. sur ce critère, l'INSEE ne parle que "d'unités 
urbaines". (https://www.insee.fr/fr/information/2571258 )


On n'est pas plus avancés :(

--
deuzeffe

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

Re: [OSM-talk-fr] Classement ville/village - city/town/village

[djakk djakk]

Oui Philippe ca sera plus+ subjectif. L’information population est déjà
renseignée une première fois alors on ne risque pas de perdre de l’info ...

Le lun. 10 sept. 2018 à 19:35, Jérôme Amagat  a
écrit :

> Il ne faut pas comparer avec les autre village d'osm mais avec les town.
> Dans osm comme je pense l'usage en France,  village est utiliser pour des
> "truc" tout petit si il y a une mairie par exemple. Et aussi pour des
> "truc" plus grand avec beaucoup de petit commerce.
>
> Le lun. 10 sept. 2018 à 19:12, Philippe Verdy  a
> écrit :
>
>> mais alors bon nombre de villages actuels passeraient en "town". LA
>> définition anglaise est un compromis local à l'Angleterre, la
>> classification s'est faite en fait pays par pays. En France c'est un
>> critère de population (avec quelques exceptions sur les populations très
>> approchantes, ou parce que c'est un centre *administratif*. Les commerces
>> ne sont pas suffisants pour changer ça, car il n'ont pas plus de priorité
>> que d'autres services et entreprises (et ne France les services publics son
>> nombreux et ont beaucoup d'activités), ou grandes assos d'utilité publique
>> (qui souvent aussi sont alors des employeurs), ou même les exploitations
>> agricoles !
>>
>> Plutôt que le nombre de commerces on pourrait retenir le nombre d'emplois
>> dans la commune, ce serait plus pertinent que les seuls commerces, mais les
>> activités et commerces ont un nombre variable (décroissant) d'emplois.
>> Enfin le commerce ne se réduit pas aux seules boutiques installées : il y a
>> aussi les marchés, la vente à domicile, la vente itinérante (food
>> trucks...), la vente sur Internet, et plein de services aux entreprises qui
>> n'ont pas pignon sur rue; enfin on peut ajouter les cabinets médicaux ou
>> d'infirmières...
>>
>> Difficile de trancher par un critère simple, d'autant plus que si on
>> compte uniquement les emplois on va exclure des grosses localités urbaines
>> résidentielles qui ne sont pas des villages, mais ont une population dense
>> et peu de commerce directement sur leur sol (de nos jours pleins de
>> commerces sont sortis des communes centre pour aller en périphérie
>> immédiate mais ils assurent pourtant une couverture commerciale et de
>> services qu'on peut appeler de proximité). Les communes ont souvent aussi
>> plusieurs bourgs, dont certains se sont développés au contact direct d'une
>> autre agglomération ou par facilité de transport ou la création d'activités
>> industrielles (mais pas forcément de commerce en vente directe, sauf les
>> itinérants ou un transport court pour rejoindre une zone commerciale
>> voisine.
>>
>> Au final ce sera soi très subjectif, donc partial.
>>
>> L'importance relative d'une commune ne dépend pas seulement du critère de
>> population, ou de sa classification en village/town/city, il y a d'autres
>> critères et on s'en rend compte dans les rendus qui vont additionner la
>> présence de plusieurs autres attributs (dont celui de "capital=*") ou
>> relations qui désigne les "admin_centre".
>>
>> Ce qu'on pourrait revoir c'est plutôt les seuils minimaux de population:
>> peut-être qu'on est trop sévère pour les "towns" et même les "cities".
>>
>>
>> Le lun. 10 sept. 2018 à 18:22, djakk djakk  a
>> écrit :
>>
>>> Salut !
>>>
>>> J’aimerai revenir sur la distinction ville/village - où plutôt
>>> city/town/village : la page wiki française défini un classement par nombre
>>> d’habitants, alors que la page wiki anglaise défini un classement par les
>>> services accessibles (commerces, services) !
>>>
>>> Je trouve la définition anglaise plus intéressante bien que moins nette.
>>>
>>> En effet, j’ai comme exemple Saint-Aubin-d’Aubigné, bourg pourvu de
>>> nombreux commerces, qui est actuellement classé au même niveau qu’Aubigné,
>>> commune n’ayant qu’un seul commerce. (“Village” dans les 2 cas). St Aubin
>>> d’A mériterait d'être classé en “Town” ...
>>>
>>>
>>> djakk
>>> ___
>>> 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] Limites de vitesse et incohérences

[Gwenaël Jouvin]

Bonsoir,


Version courte :

Lorsque la signalisation n’est pas conforme, par exemple zone 30 sans panneau 
de fin, je me contente de travailler uniquement sur la route « dans l’axe » du 
panneau et parfois je m’arrête à la grosse intersection suivante car 
l’aménagement sur le terrain n’est pas du tout compatible avec la limitation. 
Ce sont des considérations très subjectives.

Je fais comme Alain, je coupe le chemin et mets un , avec 
éventuellement une note et le  correspondant (car je fais partie 
des dingues qui connaissent les codes ;-) )

À mon avis OSM n’a pas vocation à devenir une carte de la réglementation 
routière et dans ces — trop nombreux — cas douteux, nous n’avons pas à 
extrapoler quelque chose d’inexistant sur le terrain. C’est avant tout au 
conducteur de maîtriser sa conduite.


Astuce : le plugin maxspeed pour JOSM qui permet d’avoir une chouette vision 
sur ce qui est taggé et éviter les trous.



Version longue :

Ah la signalisation, vaste sujet.
Avant toute chose, j’aimerais rappeler que si dans le Code de la route, comme 
dans les lois générales, « tout ce qui n’est pas interdit est autorisé » ; en 
matière de signalisation c’est l’inverse : tout ce qui n’est pas homologué et 
décrit dans l’Instruction interministérielle de la signalisation routière est 
considéré comme non-conforme et donc, interdit.
Ce principe inversé n’est pas explicitement écrit mais transparaît dans 
l’article 2 de l’IISR [1].

En ce qui concerne la signalisation des vitesses maximales autorisées, on 
distingue 3 cas :

— les prescriptions zonales
Les panneaux qui définissent des zones 30 et des zones de rencontre limitent, 
par définition, la vitesse à 30 km/h et 20 km/h respectivement. Les aires 
piétonnes, elles, sont à accès très restreint et imposent l’allure du pas [2].

Dès que l’on franchit un de ces panneaux, on entre dans une « zone » et ils 
n’ont pas à être répétés à chaque intersection. La zone se termine soit par un 
panneau de fin de zone correspondant au panneau d’entrée, soit par un panneau 
d’entrée dans une autre zone [3, art. 63-1 à 63-3].
En conséquence, la vitesse maximale autorisée imposée à l’entrée de la zone 
change lors du franchissement de la frontière de cette zone.

— les prescriptions implicites
Certaines vitesses sont implicites car édictées par des règles générales. 
Ainsi, on ne verra jamais (normalement) de panneau « 50 » en entrée 
d’agglomération puisque c’est le panneau EB10 d’entrée qui porte cette 
prescription [3, art. 63 al. d].
De même, en zone rurale, il n’y a pas lieu de placer des panneaux « 80 » 
puisque cette V.M.A. est définie dans le Code de la route comme valeur par 
défaut [4].

Par contre, il est autorisé, dans certaines circonstances, de rappeler ces 
vitesses maximales autorisées en plaçant le panneau B 14 accompagné d’un 
panonceau « RAPPEL » M 9z [3, art. 64 al. d].

— les prescriptions explicites
Certaines voies présentent une V.M.A. différente du régime général, par exemple 
abaissement à 70 dans la traversée d’un hameau, abaissement à 30 en ville 
devant une école…
Ces indications sont faites par un panneau B 14 indiquant la valeur de vitesse 
à ne pas dépasser.

Cette prescription est annulée de plusieurs manières :
— à l’intersection suivante où, pour être prolongée, un nouveau panneau 
devra être implanté ;
— par un panneau de fin de limitation B 33 ou de fin de prescription B 
31 ;
— de manière implicite.

Ce dernier cas est délicat à interpréter. Il y a eu une question parlementaire 
à ce sujet [5].
La réponse proposée par le ministère des transports est surprenante car si elle 
cite l’art. 68 de l’IISR [3], ce même article parle « d’indication ponctuelle 
évidente » et jamais de ralentisseur, de virage ni de passage à niveau. Parier 
sur les évidences est un jeu dangereux…


Pour m’intéresser au sujet, j’ai eu plusieurs fois à signaler des 
non-conformités de signalisation à des municipalités. À vrai dire, c’est assez 
effarant, il n’y a même pas besoin de chercher pour les trouver — 
particulièrement en matière de signalisation des aménagements cyclables. Forcer 
est de constater que la tâche est considérable et que ce n’est pas 
véritablement un sujet pour les interlocuteurs, services techniques ou élus… On 
trouve alors des panneaux non-homologués, des vieux classiques comme le « sauf 
riverains », des mâts avec 3, 4 voire 5 signaux, des panneaux répétés 3 fois à 
quelques mètres d’intervalle…

Il y a également, je crois, une forte pression des marchands de panneaux qui, 
eux-mêmes, fabriquent des panneaux non-conformes (!) que l’on retrouve un peu 
partout.
Il y a clairement un déficit de l’État dans l’application des règles 
élémentaires de signalisation rappelées au préambule de l’IISR [1], un document 
public pourtant en accès libre.


Le 10/09/2018 à 12:22, djakk djakk a écrit :
> Salut !
> 
> Faut-il aller jusqu’à regarder les arrêtés municipaux ?
> Je vois souvent des débuts de limitation à 30 avant un dos-

[OSM-talk-fr] Classification des highway - trunk comme super-primary

[djakk djakk]

Coucou !

Je reviens sur cette histoire de highway=trunk qui diffère selon les pays.

Je pense qu’il est important d’avoir pour chaque clé-valeur une définition
commune au monde entier (autant que possible ) et qu’un 5e niveau dans la
hiérarchie des “highways”
serait souhaitable : residential/unclassified - tertiary - secondary -
primary - trunk.

Du coup, il s’agirait de reprendre pour la France le classement anglais des
highways, où le trunk désigne une super-route pas forcément de type
autoroutier.

Par exemple pour différencier la N12 et la D31 à Ernée (
https://www.openstreetmap.org/#map=12/48.3017/-0.9306 ) la N12 serait à
mettre en trunk - comme à priori toutes les nationales restant en France.

Pour retrouver les informations actuellement fournies par le trunk français
: la classification administrative avec le panneau “route pour
automobiles”, on a la clé-valeur “motorroad=yes”.
Il faut inventer une nouvelle clé pour désigner une route dénivelée (pas de
carrefours à niveau) : at_grade=no ou junctionS=interchangeS (utile pour
les cas où la route ressemble à une route pour automobiles dénivelée, mais
ça n’en est pas une officiellement, exemple : la N12 au niveau de
Goussainville :
https://www.openstreetmap.org/#map=16/48.7718/1.5526
).


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

Re: [OSM-talk-fr] Classement ville/village - city/town/village

[Jérôme Amagat]

Il ne faut pas comparer avec les autre village d'osm mais avec les town.
Dans osm comme je pense l'usage en France,  village est utiliser pour des
"truc" tout petit si il y a une mairie par exemple. Et aussi pour des
"truc" plus grand avec beaucoup de petit commerce.

Le lun. 10 sept. 2018 à 19:12, Philippe Verdy  a écrit :

> mais alors bon nombre de villages actuels passeraient en "town". LA
> définition anglaise est un compromis local à l'Angleterre, la
> classification s'est faite en fait pays par pays. En France c'est un
> critère de population (avec quelques exceptions sur les populations très
> approchantes, ou parce que c'est un centre *administratif*. Les commerces
> ne sont pas suffisants pour changer ça, car il n'ont pas plus de priorité
> que d'autres services et entreprises (et ne France les services publics son
> nombreux et ont beaucoup d'activités), ou grandes assos d'utilité publique
> (qui souvent aussi sont alors des employeurs), ou même les exploitations
> agricoles !
>
> Plutôt que le nombre de commerces on pourrait retenir le nombre d'emplois
> dans la commune, ce serait plus pertinent que les seuls commerces, mais les
> activités et commerces ont un nombre variable (décroissant) d'emplois.
> Enfin le commerce ne se réduit pas aux seules boutiques installées : il y a
> aussi les marchés, la vente à domicile, la vente itinérante (food
> trucks...), la vente sur Internet, et plein de services aux entreprises qui
> n'ont pas pignon sur rue; enfin on peut ajouter les cabinets médicaux ou
> d'infirmières...
>
> Difficile de trancher par un critère simple, d'autant plus que si on
> compte uniquement les emplois on va exclure des grosses localités urbaines
> résidentielles qui ne sont pas des villages, mais ont une population dense
> et peu de commerce directement sur leur sol (de nos jours pleins de
> commerces sont sortis des communes centre pour aller en périphérie
> immédiate mais ils assurent pourtant une couverture commerciale et de
> services qu'on peut appeler de proximité). Les communes ont souvent aussi
> plusieurs bourgs, dont certains se sont développés au contact direct d'une
> autre agglomération ou par facilité de transport ou la création d'activités
> industrielles (mais pas forcément de commerce en vente directe, sauf les
> itinérants ou un transport court pour rejoindre une zone commerciale
> voisine.
>
> Au final ce sera soi très subjectif, donc partial.
>
> L'importance relative d'une commune ne dépend pas seulement du critère de
> population, ou de sa classification en village/town/city, il y a d'autres
> critères et on s'en rend compte dans les rendus qui vont additionner la
> présence de plusieurs autres attributs (dont celui de "capital=*") ou
> relations qui désigne les "admin_centre".
>
> Ce qu'on pourrait revoir c'est plutôt les seuils minimaux de population:
> peut-être qu'on est trop sévère pour les "towns" et même les "cities".
>
>
> Le lun. 10 sept. 2018 à 18:22, djakk djakk  a
> écrit :
>
>> Salut !
>>
>> J’aimerai revenir sur la distinction ville/village - où plutôt
>> city/town/village : la page wiki française défini un classement par nombre
>> d’habitants, alors que la page wiki anglaise défini un classement par les
>> services accessibles (commerces, services) !
>>
>> Je trouve la définition anglaise plus intéressante bien que moins nette.
>>
>> En effet, j’ai comme exemple Saint-Aubin-d’Aubigné, bourg pourvu de
>> nombreux commerces, qui est actuellement classé au même niveau qu’Aubigné,
>> commune n’ayant qu’un seul commerce. (“Village” dans les 2 cas). St Aubin
>> d’A mériterait d'être classé en “Town” ...
>>
>>
>> djakk
>> ___
>> 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] Lit-et-Mixe

[Jérôme Amagat]

Il ne faut pas confondre commune dun côté et ville ( village hameau) de
l'autre.
Dans osm les communes c'est la relation avec admin_level=8 et la ville
c'est place=*
Dans la plupart des communes de France la commune à le même nom que le
village principal mais pas partout.

Dans le cas de cette commune le officiel name sur les place= est inutile.
Les place sont dans les limite de la relation se la commune donc pas la
peine de rajouter le nom de la commune.
Je mettrait plutôt place=village pour les 2 "Lit" et aussi "mixe". La
distinction entre un hameau et un village est pas très claire mais pour moi
c'est son "importance". "Mixe" sert au nom de la commune, ça a été une
commune et ça semble être plus habité que pas mal de village de France donc
je mettrais "village"


Le lun. 10 sept. 2018 à 18:10, djakk djakk  a écrit :

> ... nat_name et official_name uniquement sur le noeud de la ville ou d’un
> village principal bien sûr !
>
>
> djakk
>
> Le lun. 10 sept. 2018 à 17:16, djakk djakk  a
> écrit :
>
>> Bon j’ai mis name=“Lit” et official_name ainsi que nat_name=“Lit-et-Mixe”
>> Je n’ai pas touché au nom de la frontière administrative bien sûr.
>>
>> On fait pareil pour les communes fusionnées ?
>>
>> Un rendu peut ainsi choisir le nat_name en zoom éloigné et le name en
>> zoom proche ...
>>
>>
>> djakk
>>
>>
>> Le jeu. 9 août 2018 à 14:20, Philippe Verdy  a
>> écrit :
>>
>>> Pour les communes associées dans une fusion-association, ou pour les
>>> communes déléguées dans les communes nouvelles, ou pour les arrondissements
>>> municipaux (de Lille, Paris et Marseille), c'est le niveau 9 qui est
>>> utilisé avec admin_type:FR=* qui précise leur type respectif. La commune
>>> fusionnée de droit est de niveau 8, et peut avoir aussi un
>>> "admin_type:FR=*" pour la distinguer d'une commune simple (par défaut).
>>> En règle générale place=* est indépendant de l'entité adminsitrative (on
>>> devrait même se passer de "place=*" pour les relations, il est plus lié aux
>>> nodes).
>>> De même les chiffres de population devraient être sur la relation (quand
>>> il en existe une) et non sur le noeud. Le noeud peut être l'admin_centre de
>>> plusieurs relations adminsitratives, ou parfois un des "admin_centre" d'une
>>> même relation dans certains cas pour certaines entités: 'de jure' contre
>>> 'de facto'; 'capitale politique' contre 'capitale administrative' ou
>>> 'judiciaire'; 'capitale royale' contre 'capitale nationale'). Et très
>>> souvent ce noeud n'a pas le même nom que l'entité administrative où il est
>>> situé. Ce noeud donne plutôt une vision de géographie urbaine et non
>>> politique.
>>>
>>> Les statuts de "ville", "village", "borough" (admin_type=* sur les
>>> relations administratives ou politiques ou autres) ne vont pas bien avec
>>> les valeurs données à "place=*" pour les noeuds "admin_centre". Et nombre
>>> de ces lieux (village ou hameaux ou communautés rurales locales) n'ont
>>> aucun statut administratif et ne sont pas clairement délimités au sein de
>>> l'entité administrative.
>>>
>>> Assez souvent aussi un noeud "place=*" donne son nom à une entité qui
>>> est plus large que l'entité administrative (notamment dans les grandes
>>> métropoles, mais parfois aussi des villes plus petites, pour inclure une
>>> partie de leur périphérie): les "place" correspondent mieux en France à ce
>>> que l'INSEE désigne dans sa géographie urbaine (indépendante de la
>>> géographie administrative) qui évolue tout le temps et plus vite que la
>>> géographie administrative.
>>>
>>> Et pour moi "place=suburb" est donc inadapté en France, sauf pour les
>>> noeuds ajoutés en "admin_centre" des arrondissements municipaux des 3
>>> grandes villes: là c'est "admin_type:FR=arrondissement municipal" qui va
>>> prend le pas
>>>
>>> Le "place=suburb" est plus pour la compatibilité des rendus génériques
>>> internationaux: c'est une approximation permettant juste des comparaisons
>>> et d'améliorer le rendu final (pour sélectionner l'icone du noeud ou juste
>>> le style/la taille du libellé , il n'a pas de valeur en tant que donnée
>>> administrative, et sinon pour donner une priorité estimée de "l'importance"
>>> du lieu dans les recherches puisque une carte ne peut pas tous les afficher
>>> : ce "place=*" est juste un des critères possibles permettant de filtrer
>>> les éléments à afficher en priorité).
>>>
>>>
>>> Le 9 août 2018 à 11:20, djakk djakk  a écrit :
>>>
 Oui tout à fait c’est le même problème avec les communes fusionnées. Je
 n’aime pas l’utilisation du place=suburb pour les communes associées ... je
 préférerai qu’on garde place=village ou place=town et que le détail
 administratif se fasse avec les admin_level= ...
 Car quand on se balade on ne ressent pas la ville ou le village par son
 côté administratif mais par son urbanisme et sa densité commerciale et sa
 densité de services.

 djakk


 Le mar. 7 août 2018 à 19:00, Rpnpif  a écrit :

> Le  4 août 20

Re: [OSM-talk-fr] Classement ville/village - city/town/village

[Philippe Verdy]

mais alors bon nombre de villages actuels passeraient en "town". LA
définition anglaise est un compromis local à l'Angleterre, la
classification s'est faite en fait pays par pays. En France c'est un
critère de population (avec quelques exceptions sur les populations très
approchantes, ou parce que c'est un centre *administratif*. Les commerces
ne sont pas suffisants pour changer ça, car il n'ont pas plus de priorité
que d'autres services et entreprises (et ne France les services publics son
nombreux et ont beaucoup d'activités), ou grandes assos d'utilité publique
(qui souvent aussi sont alors des employeurs), ou même les exploitations
agricoles !

Plutôt que le nombre de commerces on pourrait retenir le nombre d'emplois
dans la commune, ce serait plus pertinent que les seuls commerces, mais les
activités et commerces ont un nombre variable (décroissant) d'emplois.
Enfin le commerce ne se réduit pas aux seules boutiques installées : il y a
aussi les marchés, la vente à domicile, la vente itinérante (food
trucks...), la vente sur Internet, et plein de services aux entreprises qui
n'ont pas pignon sur rue; enfin on peut ajouter les cabinets médicaux ou
d'infirmières...

Difficile de trancher par un critère simple, d'autant plus que si on compte
uniquement les emplois on va exclure des grosses localités urbaines
résidentielles qui ne sont pas des villages, mais ont une population dense
et peu de commerce directement sur leur sol (de nos jours pleins de
commerces sont sortis des communes centre pour aller en périphérie
immédiate mais ils assurent pourtant une couverture commerciale et de
services qu'on peut appeler de proximité). Les communes ont souvent aussi
plusieurs bourgs, dont certains se sont développés au contact direct d'une
autre agglomération ou par facilité de transport ou la création d'activités
industrielles (mais pas forcément de commerce en vente directe, sauf les
itinérants ou un transport court pour rejoindre une zone commerciale
voisine.

Au final ce sera soi très subjectif, donc partial.

L'importance relative d'une commune ne dépend pas seulement du critère de
population, ou de sa classification en village/town/city, il y a d'autres
critères et on s'en rend compte dans les rendus qui vont additionner la
présence de plusieurs autres attributs (dont celui de "capital=*") ou
relations qui désigne les "admin_centre".

Ce qu'on pourrait revoir c'est plutôt les seuils minimaux de population:
peut-être qu'on est trop sévère pour les "towns" et même les "cities".


Le lun. 10 sept. 2018 à 18:22, djakk djakk  a écrit :

> Salut !
>
> J’aimerai revenir sur la distinction ville/village - où plutôt
> city/town/village : la page wiki française défini un classement par nombre
> d’habitants, alors que la page wiki anglaise défini un classement par les
> services accessibles (commerces, services) !
>
> Je trouve la définition anglaise plus intéressante bien que moins nette.
>
> En effet, j’ai comme exemple Saint-Aubin-d’Aubigné, bourg pourvu de
> nombreux commerces, qui est actuellement classé au même niveau qu’Aubigné,
> commune n’ayant qu’un seul commerce. (“Village” dans les 2 cas). St Aubin
> d’A mériterait d'être classé en “Town” ...
>
>
> djakk
> ___
> 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] Classement ville/village - city/town/village

[djakk djakk]

La définition anglaise : Towns normally have a good range of shops and
facilities which are used by people from nearby villages.


Le lun. 10 sept. 2018 à 18:21, djakk djakk  a écrit :

> Salut !
>
> J’aimerai revenir sur la distinction ville/village - où plutôt
> city/town/village : la page wiki française défini un classement par nombre
> d’habitants, alors que la page wiki anglaise défini un classement par les
> services accessibles (commerces, services) !
>
> Je trouve la définition anglaise plus intéressante bien que moins nette.
>
> En effet, j’ai comme exemple Saint-Aubin-d’Aubigné, bourg pourvu de
> nombreux commerces, qui est actuellement classé au même niveau qu’Aubigné,
> commune n’ayant qu’un seul commerce. (“Village” dans les 2 cas). St Aubin
> d’A mériterait d'être classé en “Town” ...
>
>
> djakk
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Classement ville/village - city/town/village

[djakk djakk]

Salut !

J’aimerai revenir sur la distinction ville/village - où plutôt
city/town/village : la page wiki française défini un classement par nombre
d’habitants, alors que la page wiki anglaise défini un classement par les
services accessibles (commerces, services) !

Je trouve la définition anglaise plus intéressante bien que moins nette.

En effet, j’ai comme exemple Saint-Aubin-d’Aubigné, bourg pourvu de
nombreux commerces, qui est actuellement classé au même niveau qu’Aubigné,
commune n’ayant qu’un seul commerce. (“Village” dans les 2 cas). St Aubin
d’A mériterait d'être classé en “Town” ...


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

Re: [OSM-talk-fr] Lac du Laouzas

[marc marc]

bonjour,

l'erreur est du au conflit entre
- la relation qui renseigne correctement l’île en inner.
- le way outer du contour extérieur qui dit que l'ensemble
est un lac sans ile
https://www.openstreetmap.org/way/42308439

la correction consiste a virer les tag dupliqué de ce way
puisque déjà présent de manière correct sur la relation

Cordialement,
Marc

Le 10. 09. 18 à 18:05, Paul Desgranges a écrit :
> 
> Bonjour
>   Le rendu standard ne montre pas la petite île du Lac de Laouzas, 
> pourtant on peut voir cette île sur les autres rendus ...
> 
>   * https://www.openstreetmap.org/#map=15/43.6415/2.7727
>   * https://www.openstreetmap.org/#map=15/43.6415/2.7727&layers=C
>   * https://www.openstreetmap.org/#map=15/43.6415/2.7727&layers=T
>   * https://www.openstreetmap.org/#map=15/43.6415/2.7727&layers=H
> 
> Est-ce que qqun sait corriger ceci ?
> Merci
> Paul
> 
> 
> ___
> 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] Lit-et-Mixe

[djakk djakk]

... nat_name et official_name uniquement sur le noeud de la ville ou d’un
village principal bien sûr !


djakk

Le lun. 10 sept. 2018 à 17:16, djakk djakk  a écrit :

> Bon j’ai mis name=“Lit” et official_name ainsi que nat_name=“Lit-et-Mixe”
> Je n’ai pas touché au nom de la frontière administrative bien sûr.
>
> On fait pareil pour les communes fusionnées ?
>
> Un rendu peut ainsi choisir le nat_name en zoom éloigné et le name en zoom
> proche ...
>
>
> djakk
>
>
> Le jeu. 9 août 2018 à 14:20, Philippe Verdy  a écrit :
>
>> Pour les communes associées dans une fusion-association, ou pour les
>> communes déléguées dans les communes nouvelles, ou pour les arrondissements
>> municipaux (de Lille, Paris et Marseille), c'est le niveau 9 qui est
>> utilisé avec admin_type:FR=* qui précise leur type respectif. La commune
>> fusionnée de droit est de niveau 8, et peut avoir aussi un
>> "admin_type:FR=*" pour la distinguer d'une commune simple (par défaut).
>> En règle générale place=* est indépendant de l'entité adminsitrative (on
>> devrait même se passer de "place=*" pour les relations, il est plus lié aux
>> nodes).
>> De même les chiffres de population devraient être sur la relation (quand
>> il en existe une) et non sur le noeud. Le noeud peut être l'admin_centre de
>> plusieurs relations adminsitratives, ou parfois un des "admin_centre" d'une
>> même relation dans certains cas pour certaines entités: 'de jure' contre
>> 'de facto'; 'capitale politique' contre 'capitale administrative' ou
>> 'judiciaire'; 'capitale royale' contre 'capitale nationale'). Et très
>> souvent ce noeud n'a pas le même nom que l'entité administrative où il est
>> situé. Ce noeud donne plutôt une vision de géographie urbaine et non
>> politique.
>>
>> Les statuts de "ville", "village", "borough" (admin_type=* sur les
>> relations administratives ou politiques ou autres) ne vont pas bien avec
>> les valeurs données à "place=*" pour les noeuds "admin_centre". Et nombre
>> de ces lieux (village ou hameaux ou communautés rurales locales) n'ont
>> aucun statut administratif et ne sont pas clairement délimités au sein de
>> l'entité administrative.
>>
>> Assez souvent aussi un noeud "place=*" donne son nom à une entité qui est
>> plus large que l'entité administrative (notamment dans les grandes
>> métropoles, mais parfois aussi des villes plus petites, pour inclure une
>> partie de leur périphérie): les "place" correspondent mieux en France à ce
>> que l'INSEE désigne dans sa géographie urbaine (indépendante de la
>> géographie administrative) qui évolue tout le temps et plus vite que la
>> géographie administrative.
>>
>> Et pour moi "place=suburb" est donc inadapté en France, sauf pour les
>> noeuds ajoutés en "admin_centre" des arrondissements municipaux des 3
>> grandes villes: là c'est "admin_type:FR=arrondissement municipal" qui va
>> prend le pas
>>
>> Le "place=suburb" est plus pour la compatibilité des rendus génériques
>> internationaux: c'est une approximation permettant juste des comparaisons
>> et d'améliorer le rendu final (pour sélectionner l'icone du noeud ou juste
>> le style/la taille du libellé , il n'a pas de valeur en tant que donnée
>> administrative, et sinon pour donner une priorité estimée de "l'importance"
>> du lieu dans les recherches puisque une carte ne peut pas tous les afficher
>> : ce "place=*" est juste un des critères possibles permettant de filtrer
>> les éléments à afficher en priorité).
>>
>>
>> Le 9 août 2018 à 11:20, djakk djakk  a écrit :
>>
>>> Oui tout à fait c’est le même problème avec les communes fusionnées. Je
>>> n’aime pas l’utilisation du place=suburb pour les communes associées ... je
>>> préférerai qu’on garde place=village ou place=town et que le détail
>>> administratif se fasse avec les admin_level= ...
>>> Car quand on se balade on ne ressent pas la ville ou le village par son
>>> côté administratif mais par son urbanisme et sa densité commerciale et sa
>>> densité de services.
>>>
>>> djakk
>>>
>>>
>>> Le mar. 7 août 2018 à 19:00, Rpnpif  a écrit :
>>>
 Le  4 août 2018, Stéphane Péneau a écrit :

 > Si le panneau d'entrée du bourg principal indique lit-et-mixe, c'est
 un
 > peu délicat.
 >
 > En revanche, town pour un bourg d'un peu plus de 1000 habitants, je
 ne
 > suis pas trop d'accord. place=village est mieux adapté
 >

 Bonjour,

 En complément de la réserve de Stéphane, c'est le même problème avec la
 fusion récente de communes.
 Il faudrait aussi adapter le niveau administratif 8, 9 ou autre.
 https://wiki.openstreetmap.org/wiki/Key:admin%20level?uselang=fr

 --
 Alain Rpnpif

 ___
 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/list

[OSM-talk-fr] Lac du Laouzas

[Paul Desgranges]

Bonjour
 Le rendu standard ne montre pas la petite île du Lac de Laouzas, 
pourtant on peut voir cette île sur les autres rendus ...


 * https://www.openstreetmap.org/#map=15/43.6415/2.7727
 * https://www.openstreetmap.org/#map=15/43.6415/2.7727&layers=C
 * https://www.openstreetmap.org/#map=15/43.6415/2.7727&layers=T
 * https://www.openstreetmap.org/#map=15/43.6415/2.7727&layers=H

Est-ce que qqun sait corriger ceci ?
Merci
Paul
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Lit-et-Mixe

[djakk djakk]

Bon j’ai mis name=“Lit” et official_name ainsi que nat_name=“Lit-et-Mixe”
Je n’ai pas touché au nom de la frontière administrative bien sûr.

On fait pareil pour les communes fusionnées ?

Un rendu peut ainsi choisir le nat_name en zoom éloigné et le name en zoom
proche ...


djakk


Le jeu. 9 août 2018 à 14:20, Philippe Verdy  a écrit :

> Pour les communes associées dans une fusion-association, ou pour les
> communes déléguées dans les communes nouvelles, ou pour les arrondissements
> municipaux (de Lille, Paris et Marseille), c'est le niveau 9 qui est
> utilisé avec admin_type:FR=* qui précise leur type respectif. La commune
> fusionnée de droit est de niveau 8, et peut avoir aussi un
> "admin_type:FR=*" pour la distinguer d'une commune simple (par défaut).
> En règle générale place=* est indépendant de l'entité adminsitrative (on
> devrait même se passer de "place=*" pour les relations, il est plus lié aux
> nodes).
> De même les chiffres de population devraient être sur la relation (quand
> il en existe une) et non sur le noeud. Le noeud peut être l'admin_centre de
> plusieurs relations adminsitratives, ou parfois un des "admin_centre" d'une
> même relation dans certains cas pour certaines entités: 'de jure' contre
> 'de facto'; 'capitale politique' contre 'capitale administrative' ou
> 'judiciaire'; 'capitale royale' contre 'capitale nationale'). Et très
> souvent ce noeud n'a pas le même nom que l'entité administrative où il est
> situé. Ce noeud donne plutôt une vision de géographie urbaine et non
> politique.
>
> Les statuts de "ville", "village", "borough" (admin_type=* sur les
> relations administratives ou politiques ou autres) ne vont pas bien avec
> les valeurs données à "place=*" pour les noeuds "admin_centre". Et nombre
> de ces lieux (village ou hameaux ou communautés rurales locales) n'ont
> aucun statut administratif et ne sont pas clairement délimités au sein de
> l'entité administrative.
>
> Assez souvent aussi un noeud "place=*" donne son nom à une entité qui est
> plus large que l'entité administrative (notamment dans les grandes
> métropoles, mais parfois aussi des villes plus petites, pour inclure une
> partie de leur périphérie): les "place" correspondent mieux en France à ce
> que l'INSEE désigne dans sa géographie urbaine (indépendante de la
> géographie administrative) qui évolue tout le temps et plus vite que la
> géographie administrative.
>
> Et pour moi "place=suburb" est donc inadapté en France, sauf pour les
> noeuds ajoutés en "admin_centre" des arrondissements municipaux des 3
> grandes villes: là c'est "admin_type:FR=arrondissement municipal" qui va
> prend le pas
>
> Le "place=suburb" est plus pour la compatibilité des rendus génériques
> internationaux: c'est une approximation permettant juste des comparaisons
> et d'améliorer le rendu final (pour sélectionner l'icone du noeud ou juste
> le style/la taille du libellé , il n'a pas de valeur en tant que donnée
> administrative, et sinon pour donner une priorité estimée de "l'importance"
> du lieu dans les recherches puisque une carte ne peut pas tous les afficher
> : ce "place=*" est juste un des critères possibles permettant de filtrer
> les éléments à afficher en priorité).
>
>
> Le 9 août 2018 à 11:20, djakk djakk  a écrit :
>
>> Oui tout à fait c’est le même problème avec les communes fusionnées. Je
>> n’aime pas l’utilisation du place=suburb pour les communes associées ... je
>> préférerai qu’on garde place=village ou place=town et que le détail
>> administratif se fasse avec les admin_level= ...
>> Car quand on se balade on ne ressent pas la ville ou le village par son
>> côté administratif mais par son urbanisme et sa densité commerciale et sa
>> densité de services.
>>
>> djakk
>>
>>
>> Le mar. 7 août 2018 à 19:00, Rpnpif  a écrit :
>>
>>> Le  4 août 2018, Stéphane Péneau a écrit :
>>>
>>> > Si le panneau d'entrée du bourg principal indique lit-et-mixe, c'est
>>> un
>>> > peu délicat.
>>> >
>>> > En revanche, town pour un bourg d'un peu plus de 1000 habitants, je ne
>>> > suis pas trop d'accord. place=village est mieux adapté
>>> >
>>>
>>> Bonjour,
>>>
>>> En complément de la réserve de Stéphane, c'est le même problème avec la
>>> fusion récente de communes.
>>> Il faudrait aussi adapter le niveau administratif 8, 9 ou autre.
>>> https://wiki.openstreetmap.org/wiki/Key:admin%20level?uselang=fr
>>>
>>> --
>>> Alain Rpnpif
>>>
>>> ___
>>> 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.opens

Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire

[deuzeffe]

On 10/09/2018 16:24, Julien Lepiller wrote:

Probablement un coup de la sécurité de firefox, j'ai le même souci avec 
HOT. En gros, il aime pas qu'on fasse une requête en HTTP depuis une 
page en HTTPS, donc il bloque. D'ailleurs, j'ai ce message (pas le même 
que HOT) en plus :


Avec osmose en http, ça fonctionne (même si c'est mal).

Pour HOT, je peux cliquer sur le cadenas dans la barre d'adresse puis 
sur « désactiver la protection ». Là je ne sais pas.


Le problème, c'est que le lien pour "LOAD" est (par ex.) https : // 
signal.eu.org/osm/bugs/#47.3841291/0.7417059
(grrr, free qui refuse d'envoyer le mail sous prétexte qu'il détecte du 
spam, obligée de charcuter l'url, désolée)


À part recopier ce lien dans la barre d'url, ça ne fait pas grand chose 
d'autre.


Ou c'est mon FF 60 ESR qui ne comprend pas ?

--
deuzeffe, dubitative.

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

Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire

[Julien Lepiller]

Le 2018-09-10 16:15, deuzeffe a écrit :

On 10/09/2018 11:32, Pierre Beyssac wrote:


Ah voilà merci, c'est exactement ce qu'il me fallait ! Ça devrait
être facile.


Et si tu ajoutes target="_blank" dans ton , ça ouvrira bien
OSM/iD-Potlach dans un nouvel onglet.


J'ai déjà ça pour JOSM, qui est similaire en paramètres, mais en
URL de connexion directe via localhost.


Rassure-moi, il n'est pas encore opérationnel le lien "load" (in JOSM,
je suppose). Parce que "chez moi, ça pas marche".

Par exemple, avec osmose, le lien pour modifier un objet dans josm,
c'est : http://localhost:8111/load_object?objects=n5747831782 Une fois
JOSM lancé, l'objet y est bien chargé (rien touché à la config. de
base de josm, pas folle).

HTH


Probablement un coup de la sécurité de firefox, j'ai le même souci avec 
HOT. En gros, il aime pas qu'on fasse une requête en HTTP depuis une 
page en HTTPS, donc il bloque. D'ailleurs, j'ai ce message (pas le même 
que HOT) en plus :


Blocage d’une requête multiorigines (Cross-Origin Request) : la 
politique « Same Origin » ne permet pas de consulter la ressource 
distante située sur 
http://127.0.0.1:8111/load_and_zoom?zoom_mode=download&left=1.8996612&bottom=47.9166018&right=1.90061&top=47.9172378&select=way81016796,way297346084. 
Raison : échec de la requête CORS.


Pour HOT, je peux cliquer sur le cadenas dans la barre d'adresse puis 
sur « désactiver la protection ». Là je ne sais pas.


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

Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire

[deuzeffe]

On 10/09/2018 11:32, Pierre Beyssac wrote:


Ah voilà merci, c'est exactement ce qu'il me fallait ! Ça devrait
être facile.


Et si tu ajoutes target="_blank" dans ton , ça ouvrira bien 
OSM/iD-Potlach dans un nouvel onglet.



J'ai déjà ça pour JOSM, qui est similaire en paramètres, mais en
URL de connexion directe via localhost.


Rassure-moi, il n'est pas encore opérationnel le lien "load" (in JOSM, 
je suppose). Parce que "chez moi, ça pas marche".


Par exemple, avec osmose, le lien pour modifier un objet dans josm, 
c'est : http://localhost:8111/load_object?objects=n5747831782 Une fois 
JOSM lancé, l'objet y est bien chargé (rien touché à la config. de base 
de josm, pas folle).


HTH

--
deuzeffe, qui aime bien enfoncer des portes ouvertes, ça rafraîchit, par 
ce temps.


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

Re: [OSM-talk-fr] Limites de vitesse et incohérences

[marc marc]

pour ma part quand il y a des incohérentes entre les panneaux
et "le bon sens", j'ajoute systématiquement les panneaux dans osm.
c'est la seule façon pour le suivant de comprendre si la signalisation
a changer ou si les valeurs sur les way sont du à une erreur 
administrative et combiner avec survey:date c'est un bon plan
pour revérifier + tard si cela s'est amélioré.
Quand à la valeur sur le way, 3 débuts de zone sans fin constitue une 
erreur mais n'empêche pas d'avoir la bonne valeur sur le way


Le 10. 09. 18 à 13:04, Erwan Salomon a écrit :
> normalement un limite de vitesse est annulée à chaque intersection (même en 
> continuant tout droit on repasse en limite normale genre 50 en ville jusque 
> nouveau panneau)
> 
> par contre une zone nécessite une sortie de zone
> et toutes les rues de l’intersection sont comprises dans la zone même si 
> aucun panneau ne le répète
> si c’est bien panneauté toutes les rues qui mènent à cette rue non renseigné 
> ont eu leur panneau d’entrée en zone 30
> 
> mais certaines communes ont du mal avec cette notion de zone et utilise ce 
> panneau comme une limite
> ainsi à Plœmeur on peut croiser 3-4 panneaux d’entrée en zone 30 sans être 
> sorti ...
> 
>> Le 10 sept. 2018 à 12:49, Christian Quest  a écrit :
>>
>> En principe, les prescriptions (vitesse, stationnement, autre) sont valables 
>> jusqu'à l'intersection suivante.
>> Donc si sur un axe il est indiqué 30, dès qu'on tourne sur une rue 
>> transversale, on n'a plus la limitation à partir de l'intersection.
>>
>> C'est assez normal de fonctionner comme ça car lorsqu'on change d'axe, il 
>> faut bien qu'il y ait des indications sur les prescriptions du nouvel axe 
>> qu'on emprunte donc une répétition à chaque intersection.
>>
>> Ceci dit, je ne suis pas un spécialiste du code de la route, il y a des 
>> experts ici qui connaissent même les références des panneaux ;)
>>
>> -- 
>> Christian Quest - OpenStreetMap France
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [OSM-talk-fr] Limites de vitesse et incohérences

[Erwan Salomon]

normalement un limite de vitesse est annulée à chaque intersection (même en 
continuant tout droit on repasse en limite normale genre 50 en ville jusque 
nouveau panneau)

par contre une zone nécessite une sortie de zone
et toutes les rues de l’intersection sont comprises dans la zone même si aucun 
panneau ne le répète 
si c’est bien panneauté toutes les rues qui mènent à cette rue non renseigné 
ont eu leur panneau d’entrée en zone 30

mais certaines communes ont du mal avec cette notion de zone et utilise ce 
panneau comme une limite
ainsi à Plœmeur on peut croiser 3-4 panneaux d’entrée en zone 30 sans être 
sorti ...

> Le 10 sept. 2018 à 12:49, Christian Quest  a écrit :
> 
> En principe, les prescriptions (vitesse, stationnement, autre) sont valables 
> jusqu'à l'intersection suivante.
> Donc si sur un axe il est indiqué 30, dès qu'on tourne sur une rue 
> transversale, on n'a plus la limitation à partir de l'intersection.
> 
> C'est assez normal de fonctionner comme ça car lorsqu'on change d'axe, il 
> faut bien qu'il y ait des indications sur les prescriptions du nouvel axe 
> qu'on emprunte donc une répétition à chaque intersection.
> 
> Ceci dit, je ne suis pas un spécialiste du code de la route, il y a des 
> experts ici qui connaissent même les références des panneaux ;)
> 
> -- 
> Christian Quest - OpenStreetMap France
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] Limites de vitesse et incohérences

[Christian Quest]

En principe, les prescriptions (vitesse, stationnement, autre) sont
valables jusqu'à l'intersection suivante.
Donc si sur un axe il est indiqué 30, dès qu'on tourne sur une rue
transversale, on n'a plus la limitation à partir de l'intersection.

C'est assez normal de fonctionner comme ça car lorsqu'on change d'axe, il
faut bien qu'il y ait des indications sur les prescriptions du nouvel axe
qu'on emprunte donc une répétition à chaque intersection.

Ceci dit, je ne suis pas un spécialiste du code de la route, il y a des
experts ici qui connaissent même les références des panneaux ;)

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

Re: [OSM-talk-fr] Limites de vitesse et incohérences

[djakk djakk]

Salut !

Faut-il aller jusqu’à regarder les arrêtés municipaux ?
Je vois souvent des débuts de limitation à 30 avant un dos-d’âne pas suivi
d’un retour à 50 (Pas de 30 barré).


Julien djakk


Le lun. 10 sept. 2018 à 12:15, Rpnpif  a écrit :

> Bonjour,
>
> Personnellement, je coupe la route et j'y mets un maxspeed. Je trouve
> cela plus simple que d'y ajouter des traffic_* pour les panneaux.
> Et alors je n'ai pas de débordement.
>
> Par contre sur le terrain, oui on trouve de tout, mais j'essaie quand
> même de coller au plus près.
>
> --
> Alain Rpnpif
>
> Le 10 septembre 2018, Patrick BEGOU a écrit :
>
> > Bonjour,
> >
> > utilisateur d'Osmand depuis fin juillet, je me suis mis à corriger les
> > limites erronées depuis le passage à 80 km/h là où je constatais des
> > erreurs. Puis le côté addictif d'OSM m'a poussé à ajouter les limites
> > sur les routes qui n'en avaient pas et je me
> > trouve régulièrement devant des incohérences sur le terrain, du genre:
> >
> > Une zone 30 signalée dans la rue principale d'un village et pas dans les
> > rues transversales. Ce qui signifie que si on suit la signalisation à
> > la lettre, dans ces rues transversales on doit circuler à 30 en quittant
> > le village (puisqu'on n'a croisé aucun "fin de zone 30" et à 80
> > lorsqu'on s'y rend, ce qui semble très incohérent. Je ne me vois pas
> > rentrer un maxspeed:forward=30 et un maxspeed:backward=80.
> >
> > De même, je trouve régulièrement la situation suivante:
> > Limitation à 70 km/h.
> > Un peu plus loin, une intersection sans rappel de la limite à 70, donc
> > théoriquement fin de la limite imposée et retour à 80 km/h par défaut.
> > Et un peu plus loi un panneau "fin de limite à 70".
> >
> > Je me doute que l'idée dans l'esprit de ceux qui ont posé les
> > panneaux était de limiter jusqu'au panneau "fin de limite" mais la
> > réglementation dit que la limite s'arrête à l'intersection.
> >
> > Donc j'en viens à ma question: étant encore un contributeur récent, je
> > ne sais pas si il y a des habitudes, règles, bonnes pratiques dans ces
> > cas là:
> >
> > on inscrit ce que dit la loi même si ce n'est manifestement pas ce
> > qu'elle veut dire ?
> >
> > on inscrit ce que semble être l'esprit de la loi dans la zone
> > concernée, mais sans trop savoir pour le cas des zones 30 où placer
> > une limite qui n'est pas sur le terrain ?
> >
> > on n'inscrit rien du tout, seule façon à mon sens de n'inscrire que
> > ce qu'on trouve sur le terrain, tout en évitant de rentrer des
> > inepties ?
> >
> > Merci pour vos éclaircissements.
> >
> > Patrick
> >
> > ___
> > 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] Limites de vitesse et incohérences

[Rpnpif]

Bonjour,

Personnellement, je coupe la route et j'y mets un maxspeed. Je trouve
cela plus simple que d'y ajouter des traffic_* pour les panneaux.
Et alors je n'ai pas de débordement.

Par contre sur le terrain, oui on trouve de tout, mais j'essaie quand
même de coller au plus près.

-- 
Alain Rpnpif

Le 10 septembre 2018, Patrick BEGOU a écrit :

> Bonjour,
> 
> utilisateur d'Osmand depuis fin juillet, je me suis mis à corriger les
> limites erronées depuis le passage à 80 km/h là où je constatais des
> erreurs. Puis le côté addictif d'OSM m'a poussé à ajouter les limites
> sur les routes qui n'en avaient pas et je me
> trouve régulièrement devant des incohérences sur le terrain, du genre:
> 
> Une zone 30 signalée dans la rue principale d'un village et pas dans les
> rues transversales. Ce qui signifie que si on suit la signalisation à
> la lettre, dans ces rues transversales on doit circuler à 30 en quittant
> le village (puisqu'on n'a croisé aucun "fin de zone 30" et à 80
> lorsqu'on s'y rend, ce qui semble très incohérent. Je ne me vois pas
> rentrer un maxspeed:forward=30 et un maxspeed:backward=80.
> 
> De même, je trouve régulièrement la situation suivante:
> Limitation à 70 km/h.
> Un peu plus loin, une intersection sans rappel de la limite à 70, donc
> théoriquement fin de la limite imposée et retour à 80 km/h par défaut. 
> Et un peu plus loi un panneau "fin de limite à 70".
> 
> Je me doute que l'idée dans l'esprit de ceux qui ont posé les
> panneaux était de limiter jusqu'au panneau "fin de limite" mais la
> réglementation dit que la limite s'arrête à l'intersection.
> 
> Donc j'en viens à ma question: étant encore un contributeur récent, je
> ne sais pas si il y a des habitudes, règles, bonnes pratiques dans ces
> cas là:
> 
> on inscrit ce que dit la loi même si ce n'est manifestement pas ce
> qu'elle veut dire ?
> 
> on inscrit ce que semble être l'esprit de la loi dans la zone
> concernée, mais sans trop savoir pour le cas des zones 30 où placer
> une limite qui n'est pas sur le terrain ?
> 
> on n'inscrit rien du tout, seule façon à mon sens de n'inscrire que
> ce qu'on trouve sur le terrain, tout en évitant de rentrer des
> inepties ?
> 
> Merci pour vos éclaircissements.
> 
> Patrick
> 
> ___
> 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] détection de bugs dans la cartographie ferroviaire

[Frédéric Rodrigo]

Le 10/09/2018 à 11:57, Pierre Beyssac a écrit :

Je compte diffuser tout le code en libre (c'est du Go essentiellement)
quand il sera à peu près stabilisé

Je peux filer le code "en vrac" tel quel à qui veut regarder aussi
mais c'est pas forcément un cadeau :-P

La vérification la plus subtile c'est prendre un nœud à n branches
et suivant les angles essayer de déterminer si c'est :

3 chemins -> aiguille normale... ou pas
4 chemins -> aiguiille triple ou "croisement"
plus -> bizarre, à examiner
Désolé, mais non spécialiste du sujet j'ai un peu de mal à comprendre de 
quoi tu parle.



Je ne sais pas si Osmose peut faire, j'imagine que oui.

Il y a des millions de trucs pas faits et à faire avec l'opendata
SNCF aussi (vérifications d'import), mais évidemment ça ne concernera
que la France, alors que ce qui précède je l'applique partout.

Voilà déjà ce qu'a Osmose sur le sujet:
http://osmose.openstreetmap.fr/fr/map/#tags=railway

À quels jeux de données OpenData tu penses ?

Il a toute une partie d'Osmose dédié à la comparaison avec l'Opendata.


Une autre solution, Osmose peut aussi servir à afficher les résultats de
contrôle fait à l'extérieur d'Osmose. Il y en a déjà des fait comme ça.

Ah ça peut être un bon début oui... il y a de la doc là dessus ?


https://wiki.openstreetmap.org/wiki/Osmose#Issues_reporting_API



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

Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire

[Pierre Beyssac]

On Mon, Sep 10, 2018 at 10:22:14AM +0200, Frédéric Rodrigo wrote:
> Le 10/09/2018 à 09:23, Erik Amzallag a écrit :
> > Bonjour,
> >
> > Serait-il possible d'avoir plus de précisions sur la nature des 
> > erreurs ? Ce qu'elles signifient, et éventuellement des propositions 
> > de corrections.
> >
> > Merci !
> >
> > Erik
> 
> Le code est quelque part ou tu peux décrire les contrôles que tu fais 
> (et avec quoi) pour voir si l'on peut implémenter ça dans osmose ?

Je compte diffuser tout le code en libre (c'est du Go essentiellement)
quand il sera à peu près stabilisé

Je peux filer le code "en vrac" tel quel à qui veut regarder aussi
mais c'est pas forcément un cadeau :-P

La vérification la plus subtile c'est prendre un nœud à n branches
et suivant les angles essayer de déterminer si c'est :

3 chemins -> aiguille normale... ou pas
4 chemins -> aiguiille triple ou "croisement"
plus -> bizarre, à examiner

Je ne sais pas si Osmose peut faire, j'imagine que oui.

Il y a des millions de trucs pas faits et à faire avec l'opendata
SNCF aussi (vérifications d'import), mais évidemment ça ne concernera
que la France, alors que ce qui précède je l'applique partout.

> Une autre solution, Osmose peut aussi servir à afficher les résultats de 
> contrôle fait à l'extérieur d'Osmose. Il y en a déjà des fait comme ça.

Ah ça peut être un bon début oui... il y a de la doc là dessus ?
-- 
Pierre Beyssac  p...@eriomem.net

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

[OSM-talk-fr] Limites de vitesse et incohérences

[Patrick BEGOU]

Bonjour,

utilisateur d'Osmand depuis fin juillet, je me suis mis à corriger les
limites erronées depuis le passage à 80 km/h là où je constatais des
erreurs. Puis le côté addictif d'OSM m'a poussé à ajouter les limites
sur les routes qui n'en avaient pas et je me
trouve régulièrement devant des incohérences sur le terrain, du genre:

Une zone 30 signalée dans la rue principale d'un village et pas dans les
rues transversales. Ce qui signifie que si on suit la signalisation à
la lettre, dans ces rues transversales on doit circuler à 30 en quittant
le village (puisqu'on n'a croisé aucun "fin de zone 30" et à 80
lorsqu'on s'y rend, ce qui semble très incohérent. Je ne me vois pas
rentrer un maxspeed:forward=30 et un maxspeed:backward=80.

De même, je trouve régulièrement la situation suivante:
Limitation à 70 km/h.
Un peu plus loin, une intersection sans rappel de la limite à 70, donc
théoriquement fin de la limite imposée et retour à 80 km/h par défaut. 
Et un peu plus loi un panneau "fin de limite à 70".

Je me doute que l'idée dans l'esprit de ceux qui ont posé les
panneaux était de limiter jusqu'au panneau "fin de limite" mais la
réglementation dit que la limite s'arrête à l'intersection.

Donc j'en viens à ma question: étant encore un contributeur récent, je
ne sais pas si il y a des habitudes, règles, bonnes pratiques dans ces
cas là:

on inscrit ce que dit la loi même si ce n'est manifestement pas ce
qu'elle veut dire ?

on inscrit ce que semble être l'esprit de la loi dans la zone
concernée, mais sans trop savoir pour le cas des zones 30 où placer
une limite qui n'est pas sur le terrain ?

on n'inscrit rien du tout, seule façon à mon sens de n'inscrire que
ce qu'on trouve sur le terrain, tout en évitant de rentrer des
inepties ?

Merci pour vos éclaircissements.

Patrick

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

Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire

[Pierre Beyssac]

On Mon, Sep 10, 2018 at 09:23:17AM +0200, Erik Amzallag wrote:
> Bonjour,
> 
> Serait-il possible d'avoir plus de précisions sur la nature des erreurs ?
> Ce qu'elles signifient, et éventuellement des propositions de corrections.

Oui je compte écrire ça.

Par exemple pour les "3-way" (aiguilles triples) :

- soit c'est vraiment une aiguille triple, dans ce cas
  c'est bien de la marquer en railway=switch et
  railway:switch=three_way, ensuite mon vérificateur la
  considère vérifiée et l'ignore (j'en ai fait pas mal en
  France hier soir).
- soit c'est 2 aiguilles normales, ou une aiguille
  "quasi-triple" où les 2 déviations sont assez clairement
  séparées, ou une zone inexacte faite à l'arrache (fréquent)
  et dans ce cas on corrige en 2 aiguilles normales (et on
  peut affiner la zone par ailleurs si on a envie :-P)

De même pour les "weird", ça peut être une plaque tournante, dans
ce cas on marque en railway=turntable, ou encore une zone faite à
l'arrache à n aiguilles classiques cumulées en un gros nœud à n
branches, etc.
-- 
Pierre Beyssac  p...@eriomem.net

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

Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire

[Pierre Beyssac]

On Mon, Sep 10, 2018 at 09:32:37AM +0200, PanierAvide wrote:
> Et tu peux faire varier les paramètres :
> 
> - node= pour pointer directement sur un objet, peut aussi être 
> way=XXX ou relation=XXX, tu peux aussi simplement ne pas l'indiquer si 
> tu n'as pas de référence précise
> - map=zoom/latitude/longitude à personnaliser au besoin (pas nécessaire 
> si tu as indiqué un paramètre node/way/relation)

Ah voilà merci, c'est exactement ce qu'il me fallait ! Ça devrait
être facile.

J'ai déjà ça pour JOSM, qui est similaire en paramètres, mais en
URL de connexion directe via localhost.
-- 
Pierre Beyssac  p...@eriomem.net

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

Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire

[Frédéric Rodrigo]

Le 10/09/2018 à 09:23, Erik Amzallag a écrit :

Bonjour,

Serait-il possible d'avoir plus de précisions sur la nature des 
erreurs ? Ce qu'elles signifient, et éventuellement des propositions 
de corrections.


Merci !

Erik


Le code est quelque part ou tu peux décrire les contrôles que tu fais 
(et avec quoi) pour voir si l'on peut implémenter ça dans osmose ?
Une autre solution, Osmose peut aussi servir à afficher les résultats de 
contrôle fait à l'extérieur d'Osmose. Il y en a déjà des fait comme ça.



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

Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire

[PanierAvide]

Le 10/09/2018 à 00:23, Pierre Beyssac a écrit :

Je ne sais pas démarrer iD dans une page web. Si quelqu'un me donne
l'incantation, pourquoi pas (pas trouvé en ligne). Mais s'il faut
une copie d'iD sur mon site, je préfère éviter:)


Tu peux assez simplement mettre un lien web classique, dans lequel tu 
appelles l'URL avec le format suivant :


https://www.openstreetmap.org/edit?node=2445458408#map=20/48.13276/-1.63256

Et tu peux faire varier les paramètres :

- node= pour pointer directement sur un objet, peut aussi être 
way=XXX ou relation=XXX, tu peux aussi simplement ne pas l'indiquer si 
tu n'as pas de référence précise
- map=zoom/latitude/longitude à personnaliser au besoin (pas nécessaire 
si tu as indiqué un paramètre node/way/relation)


De cette façon, tu peux faire afficher à peu près ce que tu veux à iD, 
sans avoir besoin de faire grand chose ;-)


Cordialement,

Adrien.

--
PanierAvide
Géomaticien & développeur


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

Re: [OSM-talk-fr] détection de bugs dans la cartographie ferroviaire

[Erik Amzallag]

Bonjour,

Serait-il possible d'avoir plus de précisions sur la nature des erreurs ?
Ce qu'elles signifient, et éventuellement des propositions de corrections.

Merci !

Erik

Le dim. 9 sept. 2018 à 22:43, Pierre Beyssac  a
écrit :

> Bonsoir,
>
> Cela fait un moment que je contribue à OSM et lis cette liste
> épisodiquement sans avoir grand chose à y dire...
>
> Cette fois je voudrais signaler mon petit projet de ce week-end,
> dérivé de travaux précédents que j'ai préséntés à SOTM-FR 2018, qui
> peut intéresser les contributeurs OSM "ferrovipathes".
>
> C'est là :
> https://signal.eu.org/osm/bugs/
>
> C'est simplement une page qui affiche des marqueurs (avec pointeurs
> directs vers OSM ou chargement JOSM si vous utilisez ce dernier)
> de "problèmes" (notion subjective, long débat).
>
> Ce n'est pas parfait mais comme on dit, "balance tôt, balance souvent".
>
> Avis bienvenus :)
>
> PS pour répondre à une FAQ : certaines choses signalées par ma page
> le sont aussi ou pourraient l'être par Osmose (angles élevés dans
> les courbes, par exemple) mais je suis bien incapable d'écrire un
> plug-in Osmose pour y importer toutes ces vérifications.
> --
> Pierre Beyssac  p...@eriomem.net
>
> ___
> 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