[OSM-talk-fr] Lot Talk-fr, Vol 120, Parution 27

[LeTopographeFou]

Bonjour Donat,

Oui bien sur le champs old_ref peut être rempli au niveau de chaque way 
si nécessaire (mais je ne crois pas qu'il soit pertinent à ce stade 
d'avoir en plus des relations par ancienne numérotation). Par contre si 
une way change deux fois de numérotation... le old_ref atteint sa limite.

Oui pour Wikidata. Personnellement je le fais pour d'autres types 
d'objets mais pas encore pour les RD car aller vérifier un à un sur 
Wikidata prend du temps ! Il faudra d'autres fous pour cela. Et puis si 
je vois l'intérêt dans le futur je ne vois pas d'application à court 
terme de wikidata... Cela viendra j'imagine.

Cdt,

LeTopographeFou

Le 10/07/2016 00:25, Donat ROBAUX a écrit :
>
>     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
>
>
> 2 avis/suggestions générales
>
>   * Pensez-vous utile de mettre un old_ref=N4? Je sais que OSM ne
>     cartographie pas le passé, mais...
>   * Plutôt que le lien wikipedia, je mettrais le lien wikidata.
>     Exemple pour la N4: https://www.wikidata.org/wiki/Q922320
>     wikidata=Q922320. Je sais que ce n'est pas encore dans les mœurs
>     et qu'on ne sait pas encore comment tout ca va se goupiller, mais
>     je pense qu'il faut le faire, et pas seulement pour les routes
>     mais pour toutes les autres infos (je pense notamment aux communes).
>
>
> Donat
>
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160711/0b7cca86/attachment.htm>