[OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale
LeTopographeFou
letopographefou at gmail.com
Mer 6 Juil 21:00:41 UTC 2016
Sauf erreur de ma part OSM ne contient pas (encore) d'arbre des pays,
régions, départements, cantons... ce ne sont pour le moment que des
relations indépendantes, mises à plat, qui sont différenciées par leurs
tags admin_level et cie. Et ce sont davantage des frontières que des
départements, régions... En effet il me parait bizarre de mettre tout
(routes, écoles...) "en vrac" dans les relations existantes, même avec
les rôles qui vont bien.
La solution 1.5 est de toute la plus élégante mais aussi la plus
ambitieuse par rapport à ce qui existe. Elle dépasse cette simple
discussion sur les RD et nécessiterait une discussion plus globale. Vous
m'emmenez sur un terrain que j'affectionne mais que je n'imaginais pas
proposer à ce stade. Toutefois c'est en visant loin que l'on évite de
piétiner. Elle présente l'avantage de ne plus nécessiter de champ
network dans le cas présent (RD). En gros, on aurait :
* Relation France
o Une relation frontière avec pour rôle 'boundary' (relation actuelle)
o Une capitale*
o Un admin_level
o Une relation par région avec pour rôle 'territory' (ou autre tag
générique)
+ Une relation frontière avec pour rôle 'boundary' (relation
actuelle)
+ Un chef lieu*
+ Un admin_level*
+ Une relation par département avec pour rôle 'territory' (ou
autre tag générique)
# Une relation frontière avec pour rôle 'boundary'
(relation actuelle)
# Un chef-lieu*
# Un admin_level
# Une relation par route départementale avec pour role
'road' ou 'route' ou que sais-je. Pas besoin de lui
mettre un network : le simple fait d'appartenir à un
département suffit
* Way 1 avec le tag ref qui va bien (pour
compatibilité avec les outils actuels)
* Way 2 avec le tag ref qui va bien (pour
compatibilité avec les outils actuels)
* ...
# Une relation par ligne de bus départemental
# Une relation par ville (à moins qu'il faille intercaler
les cantons)
* ... et ainsi de suite... vous avez saisi l'idée je pense
o Une relation par route nationale avec pour role 'road' ou
'route' ou que sais-je
+ Way 1 avec le tag ref qui va bien (pour compatibilité avec
les outils actuels)
+ Way 2 avec le tag ref qui va bien (pour compatibilité avec
les outils actuels)
+ ...
o Une relation par autoroute avec pour role 'road' ou 'route' ou
que sais-je
+ Way 1 avec le tag ref qui va bien (pour compatibilité avec
les outils actuels)
+ Way 2 avec le tag ref qui va bien (pour compatibilité avec
les outils actuels)
+ ...
* dans un premier temps en doublon de celui dans la boundary
Mais j'ai peur que ce soit trop pour mon déjà très ambitieux chantier.
Et pour faire bien il faudrait que tous les pays utilisent la même archi
sinon les outils galéreront. Donc c'est une discussion qui ne peut avoir
lieu ici. Si les OSMiens initiés pense que c'est judicieux je peux faire
une proposition dans ce sens sur le wiki en prenant la France pour
terrain d'étude.
Les bonnes nouvelles : aux vues de ce qui se fait actuellement il n'y a
pas de consensus et c'est quelque chose qui peut être déployé
progressivement sans perte de compatibilité tout en conservant les
network et autres is_in actuels. La France commencerai à se structurer
d'une belle façon.
LeTopographeFou
Le 06/07/2016 11:40, François Lacombe a écrit :
> +1 Avec Francescu sur le is_in : on a les relations pour ça, à minima
> l'analyse spatiale.
>
> Également sur le fait de traduire une arborescence dans les tags,
> c'est pas forcément adapté.
> Ici la route départementale est effectivement dans un périmètre fermé
> correspondant à la région, inutile de le faire transparaitre dans le code.
> Ajouter ces infos dans les tags facilite la recherche c'est certain,
> mais ça pose autant de problèmes pour la maintenance (cf fusion des
> régions).
> Parce qu'on pourrait faire pareil avec le millefeuille : canton,
> arrondissement... Et aussi on aurait du mal à traduire un cas où une
> route quelle qu'elle soit est partagée sur plusieurs territoires.
>
> Si des codes ISO sont disponibles, autant les utiliser sans inventer
> autre chose
> Et dans ces codes ISO si il y a le code pays, région ou autre, ca
> devient le problème de l'ISO et pas celui d'OSM.
>
> Il y a un compromis à trouver entre grouper des objets selon une
> valeur de tag et utiliser une relation.
> Ta proposition 1.5 est intéressante. Si je comprends bien, tu
> indiquerais network=* sur cette méta-relation ?
> Résultat quand deux départements fusionnent : un seul objet à modifier
> et pas 300. L'édition de cet unique objet est cependant peu aisée vu
> le nombre de membres potentiel (question d'habitude).
> Idem sur les lignes de transport en commun... et tout autre réseau.
>
> Par contre, est-ce ok de mettre des éléments routiers dans la relation
> administrative du département, avec au moins les frontières et
> probablement des écoles, des établissements sportifs et autres ?
> C'est à dire que dès qu'on veut récupérer les contours d'un
> département, on récupère vraiment tout si on ne filtre pas.
>
>
> A+
>
> François
>
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com <http://www.infos-reseaux.com>
> @InfosReseaux <http://www.twitter.com/InfosReseaux>
>
> Le 6 juillet 2016 à 09:56, Francescu GAROBY <windu.2b at gmail.com
> <mailto:windu.2b at gmail.com>> a écrit :
>
> Beau travail auquel tu t'attaques !
> J'ai moi-même commencé à faire la même chose avec les RT (routes
> territoriales) de Corse (anciennes RN). Je vais donc suivre
> attentivement cette discussion !
>
> Et sinon, je déconseille l'usage du tag "is_in", qui n'a plus de
> sens maintenant que les recherches géographiques sont possibles.
>
>
> Francescu
>
> Le 6 juillet 2016 à 09:15, Topographe Fou
> <letopographefou at gmail.com <mailto:letopographefou at gmail.com>> a
> écrit :
>
> Bonjour,
>
> Merci pour ce premier retour.
>
> Pour le 1.2 en effet je voulais parler des codes INSEE du
> département et de celui de la région. Je partage également le
> point de vue que cela ne contient pas plus d'informations dans
> le cas des RD. Mais si on se place dans une logique
> d'arborescence alors il pourrait être pratique de faire des
> recherches ou filtres par région. Hiérarchiquement parlant
> entre le pays et le département il y a une région :). Il y a
> une solution peut-être la plus logique (voir après).
>
> Proposition 1.4 : network=FR:78 (cad c'est une route
> départementale des Yvelines en France) + is_in=FR:11:78 (cad
> c'est une relation dans le département des Yvelines, région
> IDF, en France). Is_in est pas mal utilisé aux EU, pour un
> statut assez vague.
>
> Proposition 1.5 : mettre les relations RD membre de la
> relation Département pour créer explicitement la hiérarchie +
> network=FR:78
>
> Ok pour l'avis sur le 2.
>
> Pour le 'operator' je le préciserai sur le Wiki au moment de
> faire la synthèse. En ce qui me concerne cela sort de mon
> périmètre.
>
> LeTopographeFou
> *De:*fl.infosreseaux at gmail.com <mailto:fl.infosreseaux at gmail.com>
> *Envoyé:*6 juillet 2016 8:05 AM
> *À:*talk-fr at openstreetmap.org <mailto:talk-fr at openstreetmap.org>
> *Répondre à:*talk-fr at openstreetmap.org
> <mailto:talk-fr at openstreetmap.org>
> *Objet:*Re: [OSM-talk-fr] Tag 'network' et 'name' pour une
> relation de type route départementale
>
>
> Hello,
>
> Bonne initiative, ça va en effet permettre de
> significativement améliorer la qualité des données de routage,
> avec un bon impact sur les rendus routiers
>
> Deux remarques pour amener de l'eau a ton moulin :
> Point 1.2 : tu devais vouloir parler de l'INSEE région ?
> Inutile selon moi, c'est bien un réseau départemental. Si on
> veut l'INSEE région, on le trouve via l'INSEE du département
> Point 2.3 : En effet, il ne faut pas refonder inutilement
> l'info et cette solution de passer par network=* est la
> meilleure sur ce plan.
>
> Autre chose : il faudrait utiliser operator=* pour indiquer
> l'exploitant, idéalement sur chaque segment de route, puisque
> l'exploitation des tronçons urbain peut être délégué aux villes.
>
> A+
>
> François
>
> Le 6 juil. 2016 12:25 AM, "LeTopographeFou"
> <letopographefou at gmail.com <mailto:letopographefou at gmail.com>>
> 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 :
> 2.
> 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 ISO 3166-2 (en l’occurrence cela
> ferait 'FR-78')
> 3. Concernant le tag 'name' il y a des risques
> d'amalgames entre deux départements. Est-il judicieux
> d'y mentionner le nom du département ? Le hic est que,
> rigoureusement parlant, le nom "officiel" est 'Route
> départementale 29' sans autre fioriture
> 4.
> 1. Exemple 1 : 'Route départementale 29 (Yvelines)'
> => clair et concis, facile à parser
> 2. Exemple 2 : 'Route départementale des Yvelines 29'
> => bof
> 3. Autre solution : ne rien faire, se dire que
> l'ajout de 'network' suffit et que si amalgame il
> y a c'est un problème à gérer par l'éditeur/l'app
> et non par le cartographe => c'est ma solution
> préféré mais autant réfléchir avant d'aller plus loin.
>
> A ce jour je ne vois pas de réponse ni dans les relations
> existantes ni sur le wiki. Qu'en pensez-vous ?
>
> LeTopographeFou
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org <mailto:Talk-fr at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org <mailto:Talk-fr at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> --
> Francescu
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org <mailto:Talk-fr at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> _______________________________________________
> 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/20160706/bcb517ea/attachment.htm>
Plus d'informations sur la liste de diffusion Talk-fr