Re: [OSM-talk-fr] Majuscule à l'article défini sur les lieux-dits ?

2016-07-07 Par sujet Francois Gouget 
On Thu, 16 Jun 2016, Francois Gouget wrote:
[...]
>  * D'abord il y a une page du Wiki OpenStreetMap qui reprend largement 
>la charte de toponymie de l'IGN (voir plus bas) :
>
> https://wiki.openstreetmap.org/wiki/FR:Toponymes,_odonymes#Toponymes_officiels_et_non-officiels
> 
>| Autres noms
>| Les articles définis et indéfinis s'écrivent toujours avec une 
>| minuscule. 

Pour résumer :

* Cette page du Wiki est fausse car elle se base sur un choix 
  de rendu de l'IGN pour ses cartes qui n'a pas de raison de s'appliquer 
  aux cartes OpenStreetMap, et non sur une vraie règle de toponymie.

* Il n'y a pas de consensus ni pour suivre le choix de rendu IGN pour 
  les lieux-dits, ni pour systématiquement remplir le champ name avec le 
  nom "tel qu'il s'écrirait en milieu de phrase" (voir cette discussion 
  pour les raisons qui pourraient motiver ce choix).

Du coup les articles ne font pas exception à la règle et j'ai donc 
modifié la page du Wiki comme suit :

| === Majuscules, minuscules et trait d'union ===
| Tous les substantifs et adjectifs prennent une majuscule ; les 
| articles, prépositions, conjonctions et adverbes prennent une 
| majuscule en début de nom et une minuscule à l'intérieur du nom, à 
| l'exception de "Hors" qui prend toujours une majuscule et des 
| prépositions situées en fin de toponyme.
|
| La règle générale varie suivant si il s'agit d'une toponymie 
| officielle ou non-officielle.
|
|  Noms officiels 
|
| Les noms officiels composés comportent un trait d'union entre tous les 
| termes, sauf après l'article initial ou lorsqu'il y a une apostrophe.
| 
| Exemples : ''La Teste-de-Buch'', ''Nord-Pas-de-Calais'', 
| ''l'Isle-Jourdain'', ''La Roche-sur-Yon''...
|
|  Autres noms 
|
| Les noms de lieux habités, de lieux-dits, de détails géographiques, 
| qu'ils soient français ou régionaux, ne comportent en principe jamais 
| de trait d'union.
[...]


Et donc, à moins d'un retournement de situation de dernière minute, je 
vais corriger mes lieux-dits :-)


-- 
Francois Gouget   http://fgouget.free.fr/
 The software said it requires Win95 or better, so I installed Linux.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

2016-07-07 Par sujet osm . sanspourriel 

Le 07/07/2016 à 22:23, LeTopographeFou - letopographe...@gmail.com a écrit :

Pour ce qui est de la cohérence des données j'imagine aisément un 
check JOSM (ID n'intégrant pas ce concept) qui vérifie que toute way 
dans une relation de ce type, en France, contienne un tag ref 
identique, sinon un warning. Après si l'utilisateur ignore le warning...

Et aussi Osmose.
Sauf qu'il n'y a pas qu'un ref, il y a int_ref et autres. Certes pas 
pour les départementales.


Le 07/07/2016 à 22:23, LeTopographeFou - letopographe...@gmail.com a écrit :
. Les moteurs de recherche (OSM, Internet, dans les Apps...) sont très 
intelligents mais entre 'D 321' et 'Route départementale 321' ce n'est 
pas le même niveau d'informations.


Tu peux préciser ? D, RD, Route départementale, Départementale sont 
équivalents.
=> Si on cherche la D 765 du côté de Guidel ou de Rédéné, on doit se 
voir proposer les D 765 du Finistère et du Morbihan.
S'il y a des habitations le long de la départementale qui sont 
référencés non par des lieux-dits, alors leur adresse sera sans doute 
Route Départementale 765.
Par exemple si aux niveaux des 3 pierres en Guidel le nom ne se faisait 
pas par le lieu-dit mais la route, ce serait la Route Départementale (du 
Finistère) comme associatedStreet... de cette habitation du Morbihan.
Quoique, selon Fantoir, à Rédéné il n'y pas de Route Départementale 765 
mais une N 165 (la voie express qui a succédé à ce qui est devenu D 765).


Il me semble plus judicieux de remplacer Route Départementale par D pour 
la recherche.

Mais avis non tranché.
C'est un peu comme si je cherche la gare de X, je cherche en fait la 
railway=station, name=Lorient 
 ou la name=Gare de Lorient 



Pour les relations type bus, il y a déjà les couleurs (des routes). 
Quant aux représentations des panneaux, c'est un style propres aux 
départementales, pas spécifique à une départementale.
Et comme dit par Philippe, c'est plus la largeur de la voie, la limite 
de vitesse que le statut de la voie qui intéresse l'utilisateur moyen.
Si on veut le modéliser, c'est au niveau de métadonnées. À stocker dans 
OSM ou ailleurs.
Si tu ajoutes un name alors il faut vérifier que c'est Route 
Départementale XXX si la ref=D XXX.

Plutôt un alt_name en réservant les name aux 3Route Napoléon" et autres ?

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

2016-07-07 Par sujet Philippe Verdy 
Le 7 juillet 2016 à 22:23, LeTopographeFou  a
écrit :

> Dans un second temps je vois bien dans chaque relation des infos
> permettant de faire le rendu du symbol de la RD par un renderer : texte
> noir sur fond jaune. Mais pour le moment il n'y a pas de standard défini
> (tel que OSMC) donc je m’abstiens (voila un bel exemple de l'avantage des
> relations !). Donc à mettre de côté..
>

En dehors des cas particuliers des autoroutes (en France au moins), je vois
mal unifier le rendu des départementales dont la structure même varie
énormément, entre d'une part les 4 ou 6 voies à chaussées séparées et avec
échangeurs de type autoroutier, avec bandes d'arrêt d'urgence, et des
limites de vitesse à 110, un profil aplani et peu de virage, et des tas de
départementales à 2 voies peu larges, sans chaussée séparée, le plupart du
temps avec une ligne continue, peu de visibilité à cause des virages et des
montées et descentes, plein de limitations à 70 en traversant de petits
villages, plein de ronds-points et de carrefour dangereux, le tout entre
deux rangées de platanes, et régulièrement envahis d'engins agricoles (même
si ces départementales relient deux villes majeures).

La logique d'OSM est plutôt de colorer en fonction des conditions de
circulation et d'accessibilité, et la capacité de l'infrastucture en terme
de trafic, mais pas en fonction des gestionnaires (collectivités publiques
ou concessions privées) qui peuvent changer au cours du temps. Et une voie
majeure peut devenir secondaire snas changer de numérotation quand un autre
axe de plus grande capacité est construit (et peu importe la collectivité
qui l'a fait souvent en partenariat avec des financements multiples): que
ce soint une commune, un EPCI/une métropole, un département. Avec la montée
en puissance des régions et des EPCI, il est fort probable d'ailleurs que
des axes actuellement gérés par plusieurs départements se voient transférés
aux régions et aux EPCI (surtout les métropoles), on aura alors des routes
"régionales" et des routes "intercommunales" (gérées par les EPCI).
D'autres départementales sont aussi transférées aux communes après leur
fusion et là encore il y aura une grande disparité entre les différentes
voies communales. Il n'est pas impossible à l'avenir que des routes très
rurales soient transférées à des syndicats de gestion de parcs naturels
plutôt que par plusieurs EPCI, même chose pour les routes des grandes
infrastructures portuaires (ports autonomes) ou aéroportuaires
(d'importance internationale).

Au final les numéros de référence ne doivent être uniques que pour chaque
collectivité ou organisme gestionnaire et même entre eux ces organismes
peuvent se transférer des usages plutôt que d'agir en tant "qu'opérateur"
local. Et cela survient de plus en plus étant donné les difficultés
financières des collectivités endettées. L'état veille au grain via ses
services préfectoraux qui surveillent la sécurité des axes de transport et
leur adéquation avec les schémas de transport urbain qui nécessitent des
collaborations. Quand cette collaboration devient trop compliquée ou
dépasse les capacités de gestion de l'entité gestionnaire.

Pour les usagers, peu importe qui gère une route, ce qui compte c'est son
état et sa praticité, le numéro est en fait assez accessoire, c'est juste
un repère sur les panneaux directionnels aux carrefours pour savoir si on
est sur le bon chemin. Mais comme pratiquyeemnt tout le monde a un GPS dans
son véhicule, ces numéros devront devenir de plus en plus précis pour
distinguer les voies quand le nom d'une ville destination ne suffit pas à
choisir son chemin.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

2016-07-07 Par sujet LeTopographeFou 

Bonjour,

Merci à tous pour vos retours. A ce que je vois les avis sont partagés. 
Je vais essayer de faire une synthèse ici.


Tout d'abord je suis personnellement convaincu que les relations 
apportent un niveau d'information que des tags seuls peuvent plus 
difficilement apporter et maintenir... Les arguments opposables sont 
très intéressant à débattre mais si la conclusion de cette discussion et 
de savoir si oui ou non il faut continuer à créer ces relations, j'ai 
bien peur de ne pas changer d'avis :) . Donc je continue avec le 
postulat que c'est souhaitable.


Toutefois quelques précisions car de ce que je lis il y a peut-être eu 
des incompréhensions.


La création d'une relation ne vise pas à supprimer tous les attributs en 
commun dans ses ways (surtout si ces derniers ne caractérisent pas la 
relation en question). Cce serait détourner ce pour quoi le concept a 
été créé. L'attribut ref=* a pour moi tout son rôle autant dans la 
relation que au niveau de la way et vous noterez que je ne parle pas de 
le supprimer (et que je ne l'ai pas fait). De même qu'il n'y aurait pas 
de sens à mettre dans la relation des attributs tels que highway, 
oneway, surface, maxspeed... En revanche il en est d'autres, jugés 
secondaires, qui caractérisent la RD et qui gagneraient à être stockés 
en priorité dans la relation (wikipedia ? symbol ? network ?...). Notez 
le conditionnel, le "en priorité" et non pas "exclusivement".


De tous vos commentaires voici l'architecture minimale à laquelle 
j’aboutis (qui contient une relation !) :


 * Relation
 o type=route
 o route=road
 o ref=D 321
 o network=FR-78:d-road
 o /name/ (cf. plus bas)
 o /wikipedia/ (de la RD)
 o Membres
 + Way
 # highway
 # ref=D 321
 # /operator/
 + Way
 # highway
 # ref=D 321
 # /operator/
 + ...

En bleu ce qui existe déjà dans OSM (et qui reste inchangé : =les ways). 
En rouge ce qui est ajouté (=la relation). En italique ce qui serait 
facultatif (en espérant que la liste de diffusion ne massacre pas le style).


Dans un second temps je vois bien dans chaque relation des infos 
permettant de faire le rendu du symbol de la RD par un renderer : texte 
noir sur fond jaune. Mais pour le moment il n'y a pas de standard défini 
(tel que OSMC) donc je m’abstiens (voila un bel exemple de l'avantage 
des relations !). Donc à mettre de côté...


Pour ce qui est du name=* je pense que, dans le cas de la Route Napoléon 
(qui est d'ailleurs une RN, mais l'exemple est intéressant) c'est là ou 
alt_name et name_x rentrent en scène. On peut imaginer avoir name=Route 
Napoléon et alt_name=Route nationale 85. Les moteurs de recherche (OSM, 
Internet, dans les Apps...) sont très intelligents mais entre 'D 321' et 
'Route départementale 321' ce n'est pas le même niveau d'informations. 
De même quand on visualise l'objet OSM. J'aurai donc tendance à 
conserver la possibilité de mettre un name pour ceux qui le jugent 
utile. Par contre j'ai senti un consensus derrière le fait que dans tous 
les cas il ne faut pas y ajouter de fioriture tel que le nom du département.


Pour ce qui est de la cohérence des données j'imagine aisément un check 
JOSM (ID n'intégrant pas ce concept) qui vérifie que toute way dans une 
relation de ce type, en France, contienne un tag ref identique, sinon un 
warning. Après si l'utilisateur ignore le warning...


A vous lire... en attendant j'ai mis en pause le chantier (même en 
Essonne qui reste partiellement couvert).


LeTopographeFou


Le 06/07/2016 00:28, LeTopographeFou a écrit :

Bonjour,

J'ai attaqué un imposant chantier visant à améliorer la prise en 
compte des Routes Départementales (RD) françaises dans OSM. Ce 
chantier vise à :


 1. Faire qu'il y ait une relation par RD par département (ex :
http://www.openstreetmap.org/relation/6335278)
 2. Vérifier et corrigé le tracé des RD

Le tout étant fait _à la main_ (j'insiste sur le fait qu'il n'y a pas 
d'automate) en comparant les données OSM avec Route500. A ce jour j'ai 
fais les Yvelines et attaque l'Essonne. Aucune des RD n'avait de 
relation ad-hoc et certaines n'étaient carrément pas (ou 
incomplètement) référencées par leurs champ ref=*. Donc je les attaque 
une à une avec de belles trouvailles.


Pour le moment je mets 4 tags à chaque relations (cf. 
http://www.openstreetmap.org/relation/6335278) mais je ne trouve pas 
cela très optimal d'où deux points à vous soumettre :


 1. Il faudrait en profiter pour mettre un tag 'network'. Pour info
les RN ont visiblement un tag 'network=FR:n-road'. Afin de coller
avec la logique utilisées aux EU j'ai deux propositions à faire :
 1. Utiliser le code pays et le code INSEE du département (en
l’occurrence cela ferait 'FR:78')
 2. Faire comme précédemment mais avec également le code INSEE du
département (en l’occurrence cela ferait 'FR:11:78)
 3. Utiliser le code

[OSM-talk-fr] plugin cadastre JOSM

2016-07-07 Par sujet HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT ALCA APPUI PERFORMANCE) 
Bonjour la liste

Depuis que le cadastre a modifié ses paramètres (voir 
http://gis.19327.n5.nabble.com/Le-Calque-Cadastre-le-retour-td5860247.html) , 
le plugin cadastre JOSM,  notamment son menu  géoréférencer une image, ne 
fonctionne plus. Le message est systématiquement «Tartenpion n'a pas été trouvé 
ou n'est pas disponible ». La console génère le message d'erreur suite à la 
requête GET 
http://www.cadastre.gouv.fr/scpc/listerFeuillesParcommune.do?keepVolatileSession==2000
 -> java.io.IOException : Town/City tartenpion not found
Quelqu'un pour se pencher sur le problème ? Mieux, une solution ?
version du plugin : 32329
JOSM 10327
Java 1.7.0_45

D'avance, la Marne et ses communes au cadastre raster vous diront merci.

Denis



---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr