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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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:*[email protected] <mailto:[email protected]>
*Envoyé:*6 juillet 2016 8:05 AM
*À:*[email protected] <mailto:[email protected]>
*Répondre à:*[email protected]
<mailto:[email protected]>
*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"
<[email protected] <mailto:[email protected]>>
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
[email protected] <mailto:[email protected]>
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
[email protected] <mailto:[email protected]>
https://lists.openstreetmap.org/listinfo/talk-fr
--
Francescu
_______________________________________________
Talk-fr mailing list
[email protected] <mailto:[email protected]>
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
