Documentation Modèle de géodonnées minimal · 04. 2016: Post-traitement daprès les commentaires FIG 21. 09. 2016: Version pour la mise en consultation . Documentation Modèle

Documentation Modèle de géodonnées minimal «67: réseaux de voies cyclables» et «79: réseaux de chemins pour piétons et de

randonnée pédestre»

1

Documentation Modèle de géodonnées minimal «67: réseaux de voies cyclables» et «79: réseaux de chemins pour piétons et de randonnée pédestre»

Identificateur officiel

67 réseaux de voies cyclables et 79 réseaux de chemins pour piétons et de randonnée pédestre

FIG AG / Wider Thomas, [email protected] ASTRA / Bakels Gabrielle, [email protected] ASTRA / Cerf Yan, [email protected] ASTRA / Seiler Christoph, [email protected] BS / Graf Thomas, [email protected] FR / Python Chantal, [email protected] KKGEO / Spälti Kurt, [email protected] KKGEO / Zehnder Mirjam, [email protected] KOGIS / Najar Christine, [email protected] KOGIS / Zürcher Rolf, [email protected] OW / Kromer Felix, [email protected] Sigmaplan / Lindenmann Martin, [email protected] SM / Utiger Martin, [email protected] swisstopo / Perrot Fabien, [email protected] SWW / Wipf Andreas, [email protected] VD / Jarne Alain, [email protected] ZH / Herzog Viktoria, [email protected] ZH / Hoessly Jodocus, [email protected] ZH / Walder Stefan, [email protected] ZH / Zurbuchen Lukas, [email protected]

Directeur de la FIG Christoph Seiler

Modeleur Urs Dietrich-Felber, Martin Lindenmann

Date 2016-09-21

Version 1.12

Historique des modifications

02. 10. 2014: Première ébauche révisée 20. 11. 2014: Ebauche après la séance Kick-off 23. 04. 2015: Ebauche pour la 2ème séance Kick-off 10. 01. 2016: Post-traitement après la 2ème rencontre FIG 25. 04. 2016: Post-traitement d’après les commentaires FIG 21. 09. 2016: Version pour la mise en consultation



2

Table des matières

1. Introduction .......................................................................................................... 5

1.1. Introduction thématique sur l'ensemble des données .............................................. 5

1.2. Genèse, gestion des données ................................................................................. 6

1.3. Relation avec d'autres données/systèmes ............................................................... 7

2. Bases pour la modélisation .................................................................................. 9

2.1. Informations existantes ........................................................................................... 9

3. Description du modèle ....................................................................................... 11

3.1. Diagramme de classes UML complet .....................................................................12

4. Catalogue d'objet ............................................................................................... 13

4.1. Classes ..................................................................................................................15

4.1.1. Classe «metadata» .........................................................................................15

4.1.2. Classe «hpm_way» .........................................................................................16

4.1.3. Classe «hiking_way» .......................................................................................19

4.1.4. Classe «mtb_way» ..........................................................................................19

4.1.5. Classe «pedestrian_way» ...............................................................................20

4.1.6. Classe «hpm_way_route» ...............................................................................21

4.1.7. Classe «route» ................................................................................................22

4.1.8. Classe «rsl» ....................................................................................................29

4.1.9. Classe «signalisation» .....................................................................................30

4.1.10. Classe «base_geometry» ............................................................................31

5. Modèle de représentation .................................................................................. 32

Annexe A – Vues sur le modèle de données minimal .............................................. 35

A.1. Introduction ............................................................................................................35

A.2. Modèle de données MGDM randonnée ..................................................................36

A.2.1. Réseau de chemins de randonnée ..................................................................36

A.2.2. Réseau de chemins de randonnée avec itinéraires (sans signalisation) ..........37

A.2.3. Réseau de chemins de randonnée avec itinéraires et signalisation .................38

A.3. Modèle de données MGDM randonnée- Exemple itinéraire touristique ..................39

A.3.1. Réseau de chemins de randonnée ..................................................................39

A.3.2. Réseau de chemins de randonnée avec itinéraires touristiques (sans

signalisation) .................................................................................................................40

A.3.3. Réseau de chemins de randonnée avec itinéraires touristiques et signalisation

41

A.4. Modèle de données MGDM vélo ............................................................................42

A.4.1. Réseau de chemins vélo .................................................................................42

A.4.2. Réseau de chemins vélo avec itinéraires (sans signalisation) .........................43



3

A.4.3. – Réseau de chemins vélo avec itinéraires et signalisation .............................44

A.5. Modèle de données MGDM VTT ............................................................................45

A.5.1. – Réseau de chemins VTT ..............................................................................45

A.5.2. Réseau de chemins VTT avec itinéraires (sans signalisation) .........................46

A.5.3. Réseau de chemins VTT avec itinéraires et signalisation ................................47

A.6. Modèle de données MGDM EAV ............................................................................48

A.6.1. Réseau de chemins EAV ................................................................................48

A.6.2. Réseau de chemins EAV avec itinéraires (sans signalisation) .........................49

A.6.3. – Réseau de chemins EAV avec itinéraires et signalisation .............................50

Annexe B – Glossaire ............................................................................................... 51

Annexe C – Documents détaillés .............................................................................. 57

Annexe D – Modèle-INTERLIS ................................................................................. 58

Table des illustrations

Image 1: Extrait de carte avec géométries swissTLM3D, chemins MD, itinéraires et emplacements pour la signalisation ........................................................................ 8

Image 2: Modèle de données conceptuel ................................................................. 12

Image 3: Extrait du modèle de données MGDM randonnée – réseau de chenins de randonnée ........................................................................................................... 36

Image 4: Extrait du modèle de données MGDM randonnée – réseau de chenins de randonnée avec itinéraires (sans signalisation) ................................................... 37

Image 5: Extrait du modèle de données MGDM randonnée – réseau de chenins de randonnée avec itinéraires et signalisation .......................................................... 38

Image 6: Extrait du modèle de données MGDM randonnée – réseau de chenins de randonnée pour les itinéraires touristiques .......................................................... 39

Image 7: Extrait du modèle de données MGDM randonnée – réseau de chenins de randonnée avec itinéraires touristiques (sans signalisation) ................................ 40

Image 8: Extrait du modèle de données MGDM randonnée – réseau de chenins de randonnée avec itinéraires touristiques et signalisation....................................... 41

Image 9: Extrait du modèle de données MGDM vélo – réseau de chemins vélo ...... 42

Image 10: Extrait du modèle de données MGDM vélo – réseau de chemins vélo avec itinéraires (sans signalisation) .......................................................................... 43

Image 11: Extrait du modèle de données MGDM vélo – réseau de chemins vélo avec itinéraires et signalisation ................................................................................. 44

Image 12: Extrait du modèle de données MGDM VTT – réseau de chemins VTT ... 45

Image 13: Extrait du modèle de données MGDM VTT – réseau de chemins VTT avec itinéraires (sans signalisation) .......................................................................... 46

Image 14: Extrait du modèle de données MGDM VTT – réseau de chemins VTT avec itinéraires et signalisation ................................................................................. 47



4

Image 15: Extrait du modèle de données MGDM EAV – réseau de chemins EAV .. 48

Image 16: Extrait du modèle de données MGDM EAV – réseau de chemins EAV avec itinéraires (sans signalisation) .......................................................................... 49

Image 17: Extrait du modèle de données MGDM EAV – réseau de chemins EAV avec itinéraires et signalisation ................................................................................. 50

Liste des tableaux

Tableau 1: Légende .................................................................................................... 8

Tableau 2: Catalogue d'objet .................................................................................... 14

Tableau 3: Classe metadata ..................................................................................... 15

Tableau 4: Classe hpm_way .................................................................................... 18

Tableau 5: Classe hiking_way .................................................................................. 19

Tableau 6: Classe mtb_way ..................................................................................... 19

Tableau 7: Classe pedestrian_way ........................................................................... 20

Tableau 8: Classe hpm_way_route .......................................................................... 21

Tableau 9:Classe route............................................................................................. 28

Tableau 10: Classe rsl .............................................................................................. 29

Tableau 11: Classe signalisation .............................................................................. 30

Tableau 12: Classe base_geometry ......................................................................... 31

Tableau 13: Description du modèle de représentation ............................................. 34

Tableau 14: Glossaire............................................................................................... 56



5

1. Introduction

1.1. Introduction thématique sur l'ensemble des données

Ce document décrit le modèle de géodonnées minimal d'après l'ordonnance sur la géoinformation (OGéo) [2] et l'échéancier pour sa mise en place [3] pour les formes de mobilité douce randonnée (identificateur dans l'OGéo 79: réseaux de chemins pour piétons et de randonnée pédestre) e vélo (identificateur dans l'OGéo 67: réseaux de voies cyclables). Les cantons représentent l’autorité compétente pour les deux jeux de géodonnées de base. De ce fait ils sont propriétaires des données et sont chargés de la mise en œuvre. Il va être élaboré comme modèle orienté vers les produits (voir à ce sujet [4], p. 19) et intègre les attributs pour les formes de mobilité douce randonnée, vélo, vélo tout terrain et trafic piéton. Les engins assimilés à des véhicules (EAV - Inlineskating) sont intégrés dans le modèle et doivent être signali-sée au même titre que les itinéraires vélos ou VTT; comme précisé dans la Norme VSS 640 829. Le détail d'affichage des informations se résume aux données de publication (voir à ce sujet [4], p. 23).



6

1.2. Genèse, gestion des données

Actuellement les données techniques sur la mobilité douce sont gérées par les can-tons, ainsi que SuisseMobile et Suisse Rando. La souveraineté des données incombe aux cantons. SuisseMobile et Suisse Rando soutiennent les cantons et l’OFROU au niveau du contenu et se chargent de la coordination au niveau national et régional, en particulier les réseaux pour les loisirs et le tourisme. Swisstopo tra-vaille également en étroite collaboration avec les cantons et utilise les données can-tonales pour ses produits. Cela peut se produire dans des systèmes propres ou dans l'application métier mobilité douce. Le swissTLM3D [11], le modèle topographique du paysage de swisstopo, sert de géométrie base pour l'application métier mobilité douce.

Pour le MGDM une autre géométrie de base que le swissTLM3D - p.ex. le Vector25 - peut être utilisée. Avant l'échange de données il faut s'assurer que les partenaires disposent de la même géométrie de base et de la même version de l'ensemble de données. Si les géométries de base ne correspondent pas, des problèmes peuvent survenir lors de l’assemblage des jeux de données. L'application métier mobilité douce sera compatible en grand partie avec le MGDM, ce qui assure la mise en œuvre de l'interface d'exportation.



7

1.3. Relation avec d'autres données/systèmes

Le modèle détient une géométrie propre («geometry»), de telle sorte que le modèle fonctionne en principe sans une géométrie de base. En outre il peut référencer une géométrie basée sur un modèle de nœuds respectivement des arêtes («base-geometry») et qui n’appartient pas au MGDM. Ainsi il est par exemple possible de référencier un Vector25 ou un TLM3D. Le canton est libre de choisir le jeu de don-nées.

Le swissTLM3D de swisstopo se prête particulièrement bien car actuel et très com-plet. Il est régulièrement mis à jour et est disponible chaque année sous une forme actualisée.

A titre d’illustration nous utilisons le TLM3D dans ce document et nous partons du principe que la référenciation décrite ci-dessus est réalisée. Un chemin de mobilité douce (chemin MD) référencie un segment du swissTLM3D, constitue l'unité la plus petite et ne peut pas être scindé. Par rapport aux quatre formes de mobilité douce randonnée, mobilité piétonne, vélo et VTT; le réseau de chemins MD est constitué à partir de la somme des chemins MD qui le composent. Sur ces réseaux passent les itinéraires qui ne présentent pas de lacunes, même quand les tronçons sont parcou-rus par des transports publics (funiculaire, bateau, train, etc.). Dans ce contexte de tels tronçons sont définis de manière spécifique et désignent les moyens de trans-ports employés pour assurer la liaison. D'un point de vue technique ils sont utilisés exclusivement pour les itinéraires touristiques. L'extrait de carte dans l'image 1 illustre le concept avec une partie des classes.

Dans l’image les fines lignes grises représentent des segments TLM. Les fines lignes colorées correspondent aux chemins de mobilité douce, en jaune p.ex. les chemins de randonnée qui se déroulent près de la Reuss. Cette mince ligne jaune est entou-rée par une ligne plus large avec un bord vert foncé qui caractérise ce tronçon en tant que partie d’itinéraire touristique. La ligne bleue épaisse révèle aussi un itiné-raire touristique, à savoir un itinéraire vélo qui se déroule sur un chemin de mobilité douce coloré en bleu du type chemin vélo pas visible ici. Il en va de même pour les larges lignes brunes dans le nord de l’extrait de carte qui représentent les itinéraires VTT se déroulant sur les chemins de mobilité douce du type VTT. Dans le sud-est près de Briestenstäfeli resp. près de Bristensee on reconnait des tronçons de che-mins de randonnée de montage (mince ligne rouge) et alpine (mince ligne bleue) qui font partie d’un itinéraire technique. Les cercles noirs avec les triangles symbolisent des emplacements de la signalisation.



8

Image 1: Extrait de carte avec géométries swissTLM3D, chemins MD, itinéraires et emplacements de la signali-

sation

Couleur Objet

Segment swissTLM3D

Chemin de randonnée

Chemin de randonnée de montagne

Chemin de randonnée alpine

Chemin vélo

Itinéraire de randonnée

Itinéraire vélo

Itinéraire VTT

O Emplacement L

▲ Emplacement P

Tableau 1: Légende



9

2. Bases pour la modélisation

2.1. Informations existantes

Les bases techniques, traitées avec le groupe d'accompagnement dans la phase de conception du projet «application métier MD», servent comme fondements pour le modèle de géodonnées minimal. Essentiels pour cette élaboration étaient les normes VSS «Signaux routiers. Signalisation du trafic lent (Norme 640 829a)» [12] et la loi fédérale sur les chemins pour piétons et les chemins de randonnée pédestre (LCPR) [5], ainsi que les manuels de SuisseMobile [8] (La Suisse à vélo, manuel) et [6] (Conception d'itinéraires cyclables, guide de recommandations de la mobilité́ douce nr. 5) de même que le manuel de l'OFROU et Suisse Rando [1] (Signalisation des chemins de randonnée pédestre, guide de recommandations de la mobilité́ douce nr. 6) et le manuel de planification du réseau des chemins de randonnée pédestre [7]. LGéo La loi fédérale sur la géoinformation (LGéo) est en vigueur depuis le 1er juillet 2008. Elle a pour objectif la définition de standards fédéraux obligatoires, applicables à la saisie, à la modélisation et à l’échange de géodonnées de la Confédération et notamment aux géodonnées de base relevant du droit fédéral. De plus elle règle le financement et la protection des données. La loi prévoit également des nouvelles bases légales pour la gestion des données cantonales et communales. Ainsi l’accès aux données - collectées et traitées avec d’importants moyens - par les autorités, l’économie et la population sera amélioré. Ces mêmes données pourront être utili-sées pour les applications les plus diverses. A travers l’harmonisation, des couplages de base de données seront réalisables, permettant ainsi des analyses faciles et nou-velles. Le maintien de la valeur et la qualité des géodonnées doit être assurée sur des longues périodes. OGéo Avec la LGéo l’ordonnance sur la géoinformation (OGéo) est également entrée en vigueur. Elle apporte des précisions à la LGéo tant sur le plan professionnel que technique et spécifie dans l’annexe 1 les «géodonnées de base relevant du droit fédéral». Entre autre l’Art. 9 OGéo défini que le service spécialisé compétent de la Confédération doit établir un modèle de géodonnées minimal pour chaque jeu de données de bases (annexe 1 OGéo). Dans la mesure où l’exécution des dispositions respectives relève aux cantons, l’élaboration du modèle de données se fait en colla-boration avec les cantons. Valeur juridique Les modèles de géodonnées minimaux décrivent le noyau commun d’un ensemble de géodonnées (niveau fédéral), sur lequel des modèles de données élargis peuvent être construits (niveau cantonal ou communal). Pour les cantons le modèle de géo-données minimal a force obligatoire. Ils sont libres d’intégrer des informations sup-plémentaires dans leurs modèles de données. Fourniture des géodonnées Des géodonnées de base relevant de la compétence des cantons selon le droit fédé-ral, seront mises à disposition par l’infrastructure d’agrégation des cantons exploitée par la Conférence des services cantonaux de géoinformation (CCGEO). Ces géo-



10

données de base seront harmonisées au plan intercantonal dans la structure du MGDM, agrégées, mises à disposition sous forme de services de consultation et de téléchargement standardisés d’après GeolG et publiées dans l’infrastructure natio-nale de données géographiques (INDG)



11

3. Description du modèle

Au centre de ce modèle se trouve la classe «hpm_way». Elle permet de représenter le réseau de mobilité douce. A travers la clé «id_geometry» il est possible optionnel-lement d'établir une relation avec une géométrie existante, comme par ex. le swissTLM3D.

Un chemin MD peut représenter un chemin de randonnée, vélo, vélo tout terrain, en-gins assimilés à des véhicules ou un chemin de trafic piéton. Un chemin VTT com-porte, outre les attributs de la classe «hpm_way», l'attribut «is_singletrail». Un «hpm_way» du type vélo comprends les attributs de la classe «hpm_way» et un chemin de randonnée présente additionnellement l'attribut «hiking_segment_type» (Chemin de randonnée, de montagne ou alpine). Dans le domaine de la mobilité pié-tonne, outre les attributs de la classe «hpm_way», sont représentés également les points faibles et les lacunes du réseau («is_black_spot», «is_network_gap») qui, au final, sont composés d'un objet ligne et sont répertoriés dans la classe «pedes-trian_way». Le modèle est donc adapté à tous les types de MD mais ces derniers n’utilisent pas chaque attribut.

La classe «route» contient les attributs pour les itinéraires. Un élément de la classe «hpm_way» peut faire partie de plusieurs itinéraires. A l'inverse, un itinéraire est composé d'au moins un et habituellement plusieurs éléments de la classe «hpm_way». La relation entre les chemins MD et les itinéraires est établie à travers la classe «hpm_way_route». L'ordre des chemins MD, qui forment un itinéraire, peut être documenté avec l'attribut supplémentaire «sort_order».

Les emplacements de la signalisation peuvent être gérés au moyen des classes «rsl» et «signalisation». En particulier pour la randonnée l'attribut «loca-tion_category», qui contient la catégorie d'emplacement du site de localisation d'un indicateur de direction par rapport à un itinéraire donné, est entrainé dans la classe «rsl». D'autres données comme les contenus des panneaux d'indication de direction ne sont pas représentées, car il en résulterait une complexité trop grande.

La description du modèle technique est traitée dans ce chapitre et suivants. L’Annexe A – Vues sur le modèle de données minimal – montre l’extrait pertinent du modèle en fonction de ce qui est modélisé pour les différents types de mobilité douce.


12

3.1. Diagramme de classes UML complet

Image 2: Modèle de données conceptuel


13

4. Catalogue d'objet

Description des classes

Désignation_a Désignation_f Description

Metadata Métadonnées La classe intègre les métadonnées principales

hpm_way Chemin de mobilité douce, Chemin MD «hpm_way» est la classe centrale pour la modélisation des réseaux MD pour randonnée, vélo, VTT, EAV et mobilité piétonne. Etant donné que pour les formes de mobilité douce vélo et EAV au-cun attribut supplémentaires à la classe «hpm_way» n'es prévu, une classe spécialisée, telle celle existante pour la randonnée ainsi que le VTT et la mobilité piétonne, est supprimée.

hiking_way Chemin de randonnée (comprend les chemins de randonnée pédestre, de randonnée de mon-tagne et de randonnée alpine)

La classe spécialisée «hiking_way» hérite les propriétés (attributs) de la classe «hpm_way» et elle l'enrichit de l'attribut «hi-king_segmnet_type». Cette classe sert à la modélisation des che-mins de randonnée.

mtb_way Chemin VTT La classe spécialisée «mtb_way» hérite les propriétés (attributs) de la classe «hpm_way» et elle l'enrichit de l'attribut «is_singletrail».

pedestrian_way Chemin pédestre La classe spécialisée «pedestrian_way» hérite les propriétés (attri-buts) de la classe «hpm_way» et elle l'enrichit des attributs «is_black_spot», «black_spot_comment», «is_network_gap», «network_gap_comment».

hpm_way_route Chemin-itinéraire-MD Cette classe représente la relation n:m entre «hpm_way» et «route». L'attribut «sort_order» constitue optionnellement l'ordre dans lequel les éléments issus de «hpm_way» composent un itiné-raire. L'attribut «sort_order» est nécessaire pour des itinéraires complexes.

route Itinéraire Cette classe modélise les itinéraires, agencés à partir de chemins de la classe «hpm_way».

Rsl Liste des emplacements - itinéraires (LEI) Cette classe modélise la relation n:m entre itinéraires et emplace-ments de la signalisation. Au moyen de l'attribut «location_category» est constituée la catégorie de l'emplacement, ce qui est particuliè-rement important pour la randonnée.


14

signalisation Signalisation La classe représente l'emplacement (physique) de la signalisation. L'affectation aux itinéraires s'effectue par le biais de la classe «rsl».

base_geometry Géométrie de base Elle ne fait pas partie du MGDM mais veut montrer qu'à travers l'emploi d'une clé supplémentaire («id_geometry» de la classe «hpm_way») sur un ensemble de donné officiel et actualisé, l'échange de données peut être amélioré. L'application métier Mobilité douce repose de manière similaire sur le swissTLM3D de swisstopo.

Tableau 2: Catalogue d'objet


15

4.1. Classes

Les descriptions suivantes des classes d'objet expliquent en détail chaque attribut et les plages de valeurs.

La description des attributs des classes contient les colonnes «Nom_a», «Nom_f», «Cardinalité», «Type» et «Description/Plages de valeurs». «Nom_a» et «Nom_f» indiquent les noms des attributs en anglais et français. La colonne «Cardinalité» contient l’information 1 ou 0..1. Une cardinalité égale à 1 signifie que l’attribut est obligatoire et qu’une valeur doit être saisie. 0..1 indique une fourchette qui permet la saisie de 0 ou 1 valeur au maximum, ce qui rend l’attribut optionnel. Pour faciliter la différenciation visuelle les attributs obli-gatoires sont affichées en vert et ceux optionnels en gris. Le «Type» se réfère au type de donnée et ce modèle utilise «int», «geom», «string» et «bool». «int» désigne les nombres intègres (nombres entiers), «string» les chaines de caractères, «bool» les valeurs boo-léennes (oui/non, vrai/faux, 0/1) et «geom» la géométrie ainsi que les objets géométriques tels que points ou lignes.

4.1.1. Classe «metadata»

Nom_a Nom_f Cardi-nalité

Type Description/Plages de valeurs

owner Proprietaire/Détenteur 1 string L’attribut indique le propriétaire des données, généralement le canton.

version Version 0..1 string Saisie facultative de la version de l’ensemble de données

last_updated Dernier enregistrement 0..1 string Saisie facultative de la date ou d’une indication de temps «libre» comme «mars 2016» correspondant à la dernière mise à jour de l’ensemble de données

contact_informatiom Contact 0..1 string Saisie facultative d’une adresse de contact. Tableau 3: Classe metadata


16

4.1.2. Classe «hpm_way»


Type Description/ Plages de valeurs

id_hpm_way ID Chemin MD 1 string Identification d’objet resp. clé unique des chemins de mobilité douce. Il s‘agit d’un ID qui doit être univoque pour tous les types de MD gérés par un canton.

hpm_type Type de mobilité douce 1 string L'attribut sauvegarde la forme de mobilité douce. Liste des va-leurs: «hiking» (Randonnée) «cycling» (Vélo) «MTB» (Vélo tout terrain) «skating» (EAV) «pedestrian» (Trafic piéton)

geometry Géométrie 1 geom La géométrie des chemins.

surface Type de revêtement 0..1 string Caractéristiques de surface des chemins. «hard_surface» (Dur) «partly_hard_surface» (Partiellement en dur) «natural_surface» (Naturel) «unknown» (Inconnu)

obliging_authorities Contrainte pour les autorités

0..1 string Liste des valeurs: «cantonal_structure_plan» (Plan directeur cantonal) «regional_structure_plan» (Plan directeur régional) «local_structure_plan» (Plan directeur local) «foot_or_hiking_network_plan» (Plan des chemins pour pié-tons ou de randonnée pédestre) «provisional_foot_or_hiking_network_plan» (Plan des che-mins pour piétons ou de randonnée pédestre provisoire) «agglomeration_programme» (Programme d'agglomération) «other_stipulation_obliging_authorities» (Autre détermina-tion contraignante pour les autorités) «unknown» (Inconnu)


17



source_obliging_authorities

Source de la contrainte pour les autorités

0..1 string Les valeurs peuvent varier d'un canton à l'autre. Exemple: «Plan directeur cantonal du 22.03.2003».

way_state Etat de réalisation du chemin

0..1 string «existing» (réalisé) «planned» (planifié) «way_to_repeal» (à adapter)

id_base_geometry ID Géométrie 0..1 string Identification de l'objet. Cet ID est facultatif et permet de permet de se référencier à un ensemble de données existantes à tra-vers une clé. Dans l'application métier Mobilité douce le swissTLM3D de swisstopo est référencié. La valeur de cet ID correspond à une valeur ID de la géométrie de l'ensemble des données.

public_transport_section Tronçon de ligne de transport

0..1 string Un tronçon de ligne de transport traverse un lac sur un itinéraire (touristique), gros dénivelés ou tronçons qui, pour des raisons de sécurité ou d'attractivité doivent être accomplis avec un moyen de transport comme le bus, le train ou similaire. Si une valeur est appelée à partir de la liste de valeurs, la géo-métrie est automatiquement un tronçon de ligne de transport. Liste des valeurs: «bus» (Bus) «boat» (Bateau) «train» (Chemin de fer) «rack_railway» (Chemin de fer à crémaillère) «aerial_cableway» (Téléphérique) «gondola_cableway» (Télécabine) «chairlift» (Télésiège) «tram» (Tramway) «other_public_transport» (Autres tronçons de ligne de trans-port)

state_of_way Etat 0..1 string Trois valeurs sont possibles. Elles sont attribuées selon des cri-


18



tères différents en fonction du type de mobilité douce. Des indi-cations se trouvent dans les documents «Conception d'itiné-raires cyclables. Guide de recommandations de la mobilité´ douce. Nr. 5» [6] et «Manuel de planification du réseau des chemins de randonnée pédestre» [7]. Liste des valeurs: «correct» (En ordre): Le tronçon de chemin relatif à la forme de mobilité douce est en ordre. «deficient» (Défectueux): Le tronçon de chemin est lacunaire. «unknown» (Inconnu)

obliging_land_owner Régulation de la con-trainte des propriétaires fonciers

0..1 string Indique si un chemin MD passe sur un chemin consolidé avec le propriétaire foncier. Liste des valeurs: «yes» (Oui) «no» (Non) «unknown» (Inconnu)

obliging_land_owner_comment

Justification de la res-ponsabilité des autorités

0..1 string Explication sur la responsabilité des propriétaires fonciers

is_suitable_for_handicap_route

Chemin sans obstacles 0..1 string Indique si un chemin MD est adapté aux itinéraires sans obs-tacles. Liste des valeurs: «yes» (Oui) «no» (Non)

rHpm_way_route 0..* Relation: Pour le chemin MD il peut y avoir aucune, une ou plu-sieurs chemin-itinéraire-MD

Tableau 4: Classe hpm_way


19

4.1.3. Classe «hiking_way»



hiking_segment_type Catégoriede chemin 1 string Catégories dans le domaine randonnée. Liste des valeurs: «hiking_segment» (Chemin de randonnée pédestre) «mountain_hiking_segment» (Chemin de randonnée de mon-tagne) «alpine_hiking_segment» (Chemin de randonnée alpine)

Tableau 5: Classe hiking_way

4.1.4. Classe «mtb_way»



is_singletrail Est-Singeltrail 1 bool Indique si un chemin MD est un singeltrail pour le VTT ou pas. Tableau 6: Classe mtb_way


20

4.1.5. Classe «pedestrian_way»



is_black_spot Est-Point faible 0..1 bool L'indicateur montre s'il s'agit d'un point faible pour la mobilité piétonne.

black_spot_comment Commentaire point faible

0..1 string Décrit le point faible et dans certaines circonstances également la localisation précise, s'il s'agit d'une longue géométrie (ligne).

is_network_gap Est-Lacune du réseau 0..1 bool L'indicateur montre s'il s'agit d'une lacune du réseau dans la mobilité piétonne.

network_gap_comment Commentaire Lacune du réseau

0..1 string Décrit la lacune du réseau, ev. complète avec des informations sur la réparation, sur des décisions, etc.

Tableau 7: Classe pedestrian_way


21

4.1.6. Classe «hpm_way_route»

La relation «hpm_way_route» comprend la clé des deux classes «hpm_way» et «route» et permet la représentation des relations n:m, laquelle consiste dans le fait qu’un segment ou tronçon d’un réseau peut appartenir à plusieurs itinéraires et qu’un itinéraire est consti-tué d’un ou plus tronçons. L'attribut «sort» reproduit l'ordre des portions de chemin sur un itinéraire et permet la représentation d'itiné-raires, dont le trajet retour est différent de celui aller.



sort_order Ordre de tri 0..1 int Permet de spécifier quels segments de «hpm_way» dans quel ordre constituent l'itinéraire.

belongs_to_stage Appartenance aux étapes

0..1 int L’attribut optionnel sert à spécifier à quelle étape le segment resp. la géométrie existante appartient. L’attribut reste vide s’il s’agit: - d’un type de MD qui ne présente pas d‘étapes - d’un itinéraire technique.

rHpm_way 1 Relation: le chemin-itinéraire-MD appartient exactement à un chemin MD

rRoute 1 Relation: le chemin-itinéraire-MD appartient exactement à un itinéraire

Tableau 8: Classe hpm_way_route


22

4.1.7. Classe «route»



id_route ID (itinéraire) 1 string Clé primaire de la classe «Route», qui identifie un itinéraire dans le système de manière univoque parmi tous les types de mobili-té douce. Plage de valeurs 1 - 100000.

technical_route_number Numéro technique de l'itinéraire

1 int Le numéro technique de l'itinéraire est une clé unique, qui identi-fie les itinéraires sur toutes les formes de mobilité douce de ma-nière explicite. Plage de valeurs 0.. 100000.

technical_route_name Nom technique de l'itinéraire

1 string Le numéro technique de l'itinéraire se compose resp. des desti-nations A des itinéraires (randonnée) et des destinations princi-pales pour vélo et VTT. Il est au moins composé de l'origine et la destination de l'itinéraire. Pour éviter toute confusion avec les itinéraires, la valeur inférieure de l'alphabet des lieux de départ et destination sera utilisée comme point d'arrivée. A partir de ce point le nom de l'itinéraire de départ est formé par concaténation des destinations A. Le déroulement «interne» des destinations n’est jamais changé, ce qui assure la reconnaissance de l’itinéraire et sa traçabilité géographique. Exemple: l'itinéraire randonnée avec les destinations A Thun-Münsingen - Belp - Bern s'appellerait Bern - Belp - Münsingen - Thun. L’itinéraire Vélo «Einsiedeln - Zürich - Aarau - Basel-Rheinfelden» sera renommé «Basel-Rheinfelden - Aarau – Zürich - Einsiedeln», car dans l’alphabète Basel arrive avant Einsiedeln.

touristic_route_number Numéro touristique de l'itinéraire

0..1 string Le numéro touristique de l'itinéraire est le nombre qui est perti-nente pour la signalisation des itinéraires touristiques. Les direc-tives suivantes doivent être respectées:


23



- Le numéro doit être unique au sein de chaque forme de dé-placement de la mobilité douce.

- Les itinéraires nationaux reçoivent les numéros 1-9 (selon concept SuisseMobile).

- Les itinéraires régionaux reçoivent les numéros 21-99 (selon concept SuisseMobile).

- Les itinéraires locaux reçoivent les numéros 101-999 (selon concept SuisseMobile).

- Les cantons sont en principe responsables pour l'attribution

de numéros des itinéraires, après l'assignation d'une plage de valeurs par resp. SuisseMobile ou La Suisse à pied. La Confédération peut les aider dans la coordination.

- Les itinéraires internationaux sont précédés d'un «E» (p.ex. E7).

touristic_route_name Nom touristique de l'itinéraire

0..1 string Le nom touristique des itinéraires complète le numéro des itiné-raires touristiques.

route_description Description de l'itiné-raire

0..1 string La description optionnelle de l'itinéraire contient des informa-tions sur l'itinéraire dans son ensemble, ev. une description des étapes ou des informations sur les «Points of interest impor-tants».

route_type Type d’itinéraire 1 string Indique de quel type d’itinéraire parmi les suivants s'agit-il. Liste des valeurs: «main_route» (Itinéraire principal (it. simple)) «secondary_route» (itinéraire secondaire) «alternative_route» (variante) «tributary_route» (voie d'accès) Le type «main_route» (itinéraire principal) est le type d’itinéraire le plus largement utilisé. Il s'agit d'une simple ligne depuis un


24



départ jusqu'à une destination. Un «secondary_route» (itinéraire secondaire) est dépendant d'un itinéraire principal. Il débute à un endroit quelconque, qui n'appartient pas à l'itinéraire principal. et se termine sur l'itiné-raire principal. Un «secondary_route» peut être aménagé seu-lement pour les itinéraires touristiques. «alternative_route» (variante) débute sur un itinéraire principal mais se terminent sur le même itinéraire. Les variantes peuvent être aménagées seulement pour les itinéraires touristiques. «tributary_route» (voie d'accès) sont des courts itinéraires qui conduisent vers un itinéraire ou qui s'en éloignent ainsi que des liaisons qui ne se déroulent comme des itinéraires autonomes, p.ex. vers un point de vue. Des exemples typiques sont les vois d'accès d'une gare ou d'un embarcadère vers elles-mêmes ou les itinéraires principaux. Les raccordements peuvent être signa-lisés seulement avec un indicateur de direction avec picto-grammes ou texte court ainsi qu’avec un indicateur de direction avec des panneaux «normaux».

route_category Catégorie d'itinéraire 0..1 string Plages pour les itinéraires touristiques: «international» (International) «national» (National) «regional» (Régional) «local» (Local) «local_others» (Local (autres)) «unknown» (Inconnu)

hpm_route_typ Type de mobilité douce

1 string Liste des valeurs: «hiking_route» (Itinéraire de randonnée pédestre) «cycle_route» (Itinéraire vélo) «MTB_route» (Itinéraire VTT) «skating_route» (Itinéraire EAV)


25



«pedestrian_route» (Itinéraire pédestre) «hikingish_route» (Itinéraire proche de randonnée pédestre) «handicap_route» (itinéraires accessibles sans obstacles)

route_state Etat de réalisation - Itinéraire

0..1 string Indique l'état de réalisation de l'itinéraire. Liste des valeurs: «existing» (réalisé) «planned» (planifié) «route_to_repeal» (à adapter)

starting_point Zone de départ 1 string Enregistre le point de départ de l'itinéraire.

destination Zone d'arrivée 1 string Enregistre le point de destination de l'itinéraire.

technical_demand Exigences techniques 0..1 string Cet attribut enregistre les exigences techniques à disposition de l'utilisateur de l'itinéraire, en fonction de la forme de mobilité douce. L'attribut est judicieux pour le type MD randonnée seu-lement en rapport avec les itinéraires touristiques. Les valeurs suivantes sont possibles [10]: «easy» Randonnée: facile (randonnée). Exigences: pas d'exigences particulières. Qualité du chemin/terrain: chemins accessibles au public, de préférence se situant à l’écart de routes à circulation motorisé et si possible non revêtus ni d'enrobés bitumineux, ni de béton. Les passages raides sont munis d'escaliers et les ruisseaux sont franchissables à l’aide de passerelles ou ponts. Vélo: pour débutants et enfants aussi. VTT: pas de connaissances spécifiques de VTT requises. «medium» Randonnée: moyen (randonnée de montagne). Exigences: bonne condition physique, avoir le pied ferme, ne souffrir pas de vertige et connaissance les dangers liés à la montagne (chutes de pierres, dangers de glissade et de chute, changements brusques de la météo). Qualité du chemin/terrain: parfois em-


26



pruntant avant tout des pentes raides et étant étroits. Ruisseaux parfois traversable seulement à gué et en partie exposés. Vélo: expérience dans le trafic requise. VTT: cycliste entrainé, connaissances de base de VTT requises. «hard» Randonnée: difficile (chemin de randonnée alpine). Exigences: très bonne condition physique, pied sûr et ne pas être sujets au vertige, maîtrise du maniement de la corde et du piolet, être ca-pable d'escalader en se servant de leurs mains, connaissance des dangers en montagne (chutes de pierres, risque de glisser et de tomber, changement brusque du temps). Qualité du che-min/terrain : parfois traversant du terrain accidenté, des névés, des glaciers, des éboulis et des parties rocheuses nécessitant des connaissances en escalade. Il ne faut pas s'attendre à trou-ver beaucoup d'aménagements sur ce type de chemins. La Suisse à pied ne contient pas de chemins de randonnée al-pine. Vélo: large expérience dans le trafic requise. VTT: vététiste expérimenté avec une bonne technique de con-duite. Les exigences techniques ne sont pas définies pour tous les types de mobilité douce.

stamina_requirement Exigences physiques 0..1 string Cet attribut enregistre les exigences physiques à disposition de l'utilisateur de l'itinéraire, en fonction de la forme de mobilité douce [10]: La section «randonnée» de Suisse Rando a modifié les informations concernant les exigences techniques en raison des réactions des randonneurs et car les dénominations ne sont pas adaptées. Au lieu de parler d’exigences faciles, moyennes


27



et difficiles, utilisez les valeurs «bas», «moyen» et «élevé». «easy» Randonnée: longueur: jusqu'à 12 km, dénivelé: jusqu'à 300 md, temps de marche: jusqu'à 4 h. Vélo: longueur: jusqu'à env. 50 km. dénivelé: jusqu'à 300 md, temps de parcours: jusqu'à 4 h. VTT: longueur: jusqu'à 40 km. dénivelé: jusqu'à 800 md, temps de parcours: jusqu'à 4 h. «medium» Randonnée: longueur: jusqu'à 15 km, dénivelé: jusqu'à 800 md, temps de marche: jusqu'à 5 h. Vélo: longueur: jusqu'à env. 70 km. dénivelé: jusqu'à 800 md, temps de parcours: jusqu'à 5 h. VTT longueur: jusqu'à 50 km. dénivelé: jusqu'à 1200 md, temps de parcours: jusqu'à 5 h «hard» Randonnée: longueur: > 15 km, dénivelé: > 800 md, temps de marche: > 5 h. Vélo: longueur: > 70 km, dénivelé: > 800 md, temps de par-cours: > 5 h. VTT: longueur: > 50 km, dénivelé: > 1200 md, temps de par-cours: > 5 h. «unknown» Les exigences techniques ne sont pas définies pour tous les types de mobilité douce.

direction_of_signalisation Déroulement 0..1 string Informations si un itinéraire VTT – et cela est valable seulement


28



pour les itinéraires VTT- peut être signalisé dans les deux sens ou pas. Les informations resp. départ/destination et destina-tion/départ se réfèrent aux noms des itinéraires. «bidirectional» (Chemin Aller et Retour) «start_to_end» (Chemin Aller) «end_to_start» (Chemin Retour)

rHpm_way_route 0..* Relation: Pour l‘itinéraire il peut y avoir aucune, une ou plusieurs chemin-itinéraire-MD

rRsl 0..* Relation: Pour l‘itinéraire il peut y avoir aucune, une ou plusieurs listes des emplacements - itinéraires

Tableau 9:Classe route


29

4.1.8. Classe «rsl»

La relation «rsl» comprend la clé des deux classes «signalisation» et «route» et permet la représentation des relations n:m entre «route» et «signalisation». L'attribut «location_category» est utilisé pour indiquer la catégorie d'emplacement pour les itinéraires de randonnée.



location_category Catégorie d'empla-cement

0..1 string Sauvegarde la catégorie d'emplacement (A, B ou C) pour la forme de MD randonnée.

position_number Numéro de position 0..1 int Indique l'ordre des emplacements de la signalisation basé sur un itinéraire et son déroulement.

rRoute 1 Relation: La liste des emplacements - itinéraires appartient exactement à un itinéraire

rSignalisation 1 Relation: La liste des emplacements - itinéraires appartient exactement à une signalisation

Tableau 10: Classe rsl


30

4.1.9. Classe «signalisation»

La classe «signalisation» contient les indications de coordonnées des emplacements (physiques).



id_signalisation ID Signalisation 1 string Clé unique pour l'identification des emplacements (physiques) de la signalisation.

geometry Géométrie 1 geom Sauvegarde les coordonnées des emplacements de la signalisa-tion.

field_name Noms locaux 0..1 string Lieu-dit des emplacements de la signalisation.

altitude Altitude de l'emplacement

0..1 int Indications sur l'altitude des emplacements de la signalisation.

signalisation_state Etat de réalisation de la signalisation

0..1 string Indique l'état de réalisation de la signalisation. Les valeurs sui-vantes sont possibles: «existing» (réalisé) «planned» (planifié) «signalisation_to_repeal» (à adapter)

rRsl 0..* Relation: Pour la signalisation il peut y avoir aucune, une ou plu-sieurs listes des emplacements - itinéraires

Tableau 11: Classe signalisation


31

4.1.10. Classe «base_geometry»

Cette classe d'objet ne fait pas partie du MGDM mais veut montrer qu'avec le modèle actuel une référence à une géométrie de base comme le swissTLM3D de swisstopo peut être effectuée.

Pour établir la référence, en plus d'un attribut clé, une identification de l'ensemble de données y compris sa version est nécessaire.



id_base_geometry ID Géométrie de base

1 string Chaque élément de l'ensemble de données qui est utilisé en tant que base a une clé unique.

base_geometry_version Version de la géomé-trie de base

1 string Ici il est spécifié avec quel ensemble de données (nom, réalisa-teur) et avec quelle version de l'ensemble de données, le travail a été effectué.

Tableau 12: Classe base_geometry


32

5. Modèle de représentation

Bases pour la définition du modèle de représentation – bases légales et mandant légal

La loi sur la géoinformation (LGéo) ainsi que l’ordonnance sur la géoinformation (OGéo Art. 11, al. 1) de la Confédération exigent que: «Le service spécialisé compétent de la Confédération peut prescrire un ou plusieurs modèles de représentation dans son domaine de spécialité ; le cas échéant, il les décrit. La description définit notamment le degré de spécification, les signes conventionnels et les lé-gendes».

Étant donné que le service spécialisé compétent de la Confédération est responsable également pour la modélisation des données du MGDM (avec la participation des cantons, Art. 50 OGéo), il est donc évident que le groupe de projet chargé de l’élaboration du MGDM définisse le modèle de représentation à l’égard des services de consultation. La mise en place des services de consultation incombe cependant aux autorités compétentes spécialisées d’après la LGéo Art. 8.

Les bases spécialisées légales ne contiennent aucune information concernant la représentation des données. Représentation graphique existante

Dans la pratique il est possible de trouver des représentations différentes. Le manuel de présentation des informations concernant la mobilité douce de Suisse Rando et SuisseMobile [9] défini la couleur des itinéraires dans le présent modèle. La carte de geo.admin.ch n’est pas exhaustive quant à nos exigences. C’est pourquoi nous définissons ici des valeurs de couleurs pour les réseaux de chemins et d’itinéraires ainsi que pour la signalisation, qui permettent de représenter simultanément plusieurs types de MD sans que des che-vauchements visuels en résultent. Le modèle de représentation affecte la représentation des données dans la structure du MGDM. Il ne règle pas la représentation pour la communication des types de MD. Description du modèle de représentation

Le tableau suivant fait la liste des éléments, pour lesquels le modèle de représentation établi des valeurs. Seulement les caractéris-tiques principales sont définies.


33

Nom classe Nom attri-but

Symbole/Couleur (RGB)

Commentaire/Description/Conditions

hpm_way geometry 253, 209, 1

Quand hpm_way.hpm_type=hiking ET hiking_way.hiking_segment_type=hiking_segment


Quand hpm_way.hpm_type= hiking ET hiking_way.hiking_segment_type=mountain_hiking_segment


Quand hpm_way.hpm_type= hiking ET hiking_way.hiking_segment_type=alpine_hiking_segment


Quand hpm_way.hpm_type= cycling


Quand hpm_way.hpm_type= MTB


Quand hpm_way.hpm_type= skating


Quand hpm_way.hpm_type= pedestrian


Quand hpm_way.public_transport_section <> NULL


Les itinéraires sont construits depuis «hpm_way» en tant que séquences de géométries ordonnées ou désordonnées. Quand un «id_hpm_way» survient dans la classe «hpm_way_route, cela signifie que cette géométrie fait partie intégrante d’un itinéraire. Quand hpm_way_route.id_hpm_way <> NULL ET hpm_way.hpm_type= hiking


Quand hpm_way_route.id_hpm_way <> NULL ET hpm_way.hpm_type= cycling


34

Nom classe Nom attri-but

Symbole/Couleur (RGB)

Commentaire/Description/Conditions


Quand hpm_way_route.id_hpm_way <> NULL ET hpm_way.hpm_type= MTB


Quand hpm_way_route.id_hpm_way <> NULL ET hpm_way.hpm_type= skating


Quand hpm_way_route.id_hpm_way <> NULL ET hpm_way.hpm_type= pedestrian

signalisation geometry Quand signalisation.id_signalisation <> NULL

Tableau 13: Description du modèle de représentation


35

Annexe A – Vues sur le modèle de données minimal

A.1. Introduction

Les sous-chapitres suivants présentent chacun trois extraits du modèle de données pour chaque type de MD. Sont modélisés, à l'ex-ception de la randonnée, les itinéraires techniques respectifs. Les itinéraires touristiques se différencient dans la classe «route» par l’emploi des deux attributs «touristic_route_number» et «touristic_route_name», qui sont optionnel dans le modèle mais qui devien-nent indispensables dans le contexte des itinéraires touristiques.

Le premier extrait représente l’extrait le plus pertinent, lorsque seulement les réseaux de chemins doit être modélisé. Le deuxième extrait constitue l’extrait le plus pertinent, quand - en plus du réseau de chemins - le réseau d’itinéraires sans signalisation doit égale-ment être représenté. Le troisième extrait reproduit le modèle complet, avec la signalisation. Les attributs obligatoires sont marqués en vert, tandis que les attributs resp. les classes optionnelles sont affichés en gris. Si une classe entière figure en gris, l’utilisateur est libre de l’inclure ou pas. Cela est valable dans tous les cas en référence à la classe «base_geometry». Si l’on travail sans géométrie de référence, il est possible de ce passer complètement de cette classe. La classe «metadata» avec l’attribut obligatoire «owner» n’est pas répertoriée et est partie intégrante indispensable de chaque ensemble de données et donc aussi de chaque exemple.

Le classes qui appartiennent aux itinéraires ainsi qu’à la signalisation, présentent les même attributs obligatoires et optionnels pour tous les types de MD.


36

A.2. Modèle de données MGDM randonnée

A.2.1. Réseau de chemins de randonnée

Pour la reproduction du réseau de chemins de randonnée la classe hpm_way_hiking est complétée par l’attribut «hi-king_segment_type», qui est un attribut obligatoire. Etant donné que une partie du modèle – ici randonnée – est représentée, un «hpm_way» a-t-il au maximum une référence à une géométrie de base. La classe «metadata», obligatoire dans tous les modèles par-tiels, n'est pas représentée pour des raisons de place.

Image 3: Extrait du modèle de données MGDM randonnée – réseau de chenins de randonnée


37

A.2.2. Réseau de chemins de randonnée avec itinéraires (sans signalisation)

Si des itinéraires doivent être représentés sur le réseau de chemins, les deux classes «hpm_way_route» et «route» doivent en outre être utilisées. Le déroulement des géométries peut être définit avec l’attribut «sort_order» et l’attribut «belongs_to_stage» caractérise l’étape à laquelle la géométrie appartient. L’attribut «sort_order» est utile, lorsqu’il faut connaitre le déroulement des segments le long de l’itinéraire.

Image 4: Extrait du modèle de données MGDM randonnée – réseau de chenins de randonnée avec itinéraires (sans signalisation)


38

A.2.3. Réseau de chemins de randonnée avec itinéraires et signalisation

La signalisation ne fait aucun sens sans les itinéraires. Pour l’administration des données de signalisation, la gestion des itinéraires constitue donc une condition préalable. Ce sont surtout les données sur la position (coordonnées, nom de l’emplacement, altitude) qui vont être enregistrées, ce qui se trouve sur les indicateurs de directions cependant pas. Ainsi, l’utilisateur sait quels emplacements de la signalisation peuvent être utilisés pour quels itinéraires et où ils se trouvent. La personne chargée du traitement peut également utiliser l’attribut «location_category» qui indique s’il s’agit d’un emplacement de type A, B ou C. Comme pour l’attribut «sort_order» de la classe «hpm_way_route», «position_number» spécifie le déroulement des emplacements de la signalisation sur l’itinéraire.

Image 5: Extrait du modèle de données MGDM randonnée – réseau de chenins de randonnée avec itinéraires et signalisation


39

A.3. Modèle de données MGDM randonnée- Exemple itinéraire touristique

A.3.1. Réseau de chemins de randonnée

Pour la reproduction du réseau de chemins de randonnée la classe hpm_way_hiking est complétée par l’attribut «hiking_segment_type», qui est un attribut obligatoire. Etant donné que une partie du modèle – ici randonnée – est représentée, un «hpm_way» a-t-il au maximum une référence à une géométrie de base. La classe «metadata», obligatoire dans tous les modèles par-tiels, n'est pas représentée pour des raisons de place (le réseau de chemins de randonnée avec des itinéraires touristiques corres-pond parfaitement à l’exemple présenté ci-dessus montrant le réseau de chemins randonnée sans itinéraires touristiques. Afin de garantir une vue d’ensemble il figure à nouveau ci-dessous).

Image 6: Extrait du modèle de données MGDM randonnée – réseau de chenins de randonnée pour les itinéraires touristiques


40

A.3.2. Réseau de chemins de randonnée avec itinéraires touristiques (sans signalisation)

Le déroulement des géométries peut être définit avec l’attribut «sort_order» et l’attribut «belongs_to_stage» caractérise l’étape à laquelle la géométrie appartient. L’attribut «sort_order» est utile, lorsqu’il faut connaitre le déroulement des segments le long de l’itinéraire.

Les deux attributs «touristic_route_number» et «touristic_route_name» de la classe «route» sont employés ici pour modéliser un numéro touristique qui est important pour la signalisation. Dans ce contexte spécifique les deux attributs sont obligatoires, bien que le modèle les considère comme étant optionnels (cardinalité 0..1).

Image 7: Extrait du modèle de données MGDM randonnée – réseau de chenins de randonnée avec itinéraires touristiques (sans signalisation)


41

A.3.3. Réseau de chemins de randonnée avec itinéraires touristiques et signalisation

Pour les itinéraires touristiques les «attributs touristic_route_number» et «touristic_route_name» doivent contenir une valeur. Dans le modèle ils sont certes optionnels - car il n’existe pas de modèles différents pour les itinéraires techniques et touristiques – mais pour les itinéraires touristiques ils demeurent néanmoins obligatoires. La signalisation ne fait aucun sens sans les itinéraires. Pour l’administration des données de signalisation, la gestion des itinéraires constitue donc une condition préalable. Ce sont surtout les données sur la position (coordonnées, nom de l’emplacement, altitude) qui vont être enregistrées, ce qui se trouve sur les indicateurs de directions cependant pas. Ainsi, l’utilisateur sait quels emplacements de la signalisation peuvent être utilisés pour quels itinéraires et où ils se trouvent. La personne chargée du traitement peut également utiliser l’attribut «location_category» qui indique s’il s’agit d’un emplacement de type A, B ou C. Comme pour l’attribut «sort_order» de la classe «hpm_way_route», «position_number» spécif ie le déroulement des emplacements de la signalisation sur l’itinéraire.

Image 8: Extrait du modèle de données MGDM randonnée – réseau de chenins de randonnée avec itinéraires touristiques et signalisation


42

A.4. Modèle de données MGDM vélo

A.4.1. Réseau de chemins vélo

Seulement quatre attributs de la classe «hpm_way» sont obligatoires pour la représentation du réseau de chemins vélo. Etant donné que une partie du modèle – ici vélo – est représentée, un «hpm_way» a-t-il au maximum une référence à une géométrie de base. La classe «metadata», obligatoire dans tous les modèles partiels.

Image 9: Extrait du modèle de données MGDM vélo – réseau de chemins vélo


43

A.4.2. Réseau de chemins vélo avec itinéraires (sans signalisation)

Si des itinéraires doivent être représentés sur le réseau de chemins vélo, les deux classes «hpm_way_route» et «route» doivent en outre être utilisées. Le déroulement des géométries peut être définit avec l’attribut «sort_order» et l’attribut «belongs_to_stage» carac-térise l’étape à laquelle la géométrie appartient. L’attribut «sort_order» est utile, lorsqu’il faut connaitre le déroulement des segments le long de l’itinéraire. Par exemple lorsque le trajet aller est différent de celui retour.

Image 10: Extrait du modèle de données MGDM vélo – réseau de chemins vélo avec itinéraires (sans signalisation)


44

A.4.3. – Réseau de chemins vélo avec itinéraires et signalisation

La signalisation ne fait aucun sens sans les itinéraires. Pour l’administration des données de signalisation, la gestion des itinéraires constitue donc une condition préalable. Ce sont surtout les données sur la position (coordonnées, nom de l’emplacement, altitude) qui vont être enregistrées, ce qui se trouve sur les indicateurs de directions cependant pas. Ainsi, l’utilisateur sait quels emplacements de la signalisation peuvent être utilisés pour quels itinéraires et où ils se trouvent. La personne chargée du traitement peut également utiliser l’attribut «location_category» qui indique s’il s’agit d’un emplacement de type A, B ou C. La catégorie A correspond à une des-tination principale, la catégorie B à une destination secondaire et celle C à une ramification d’itinéraire simple. Comme pour l’attribut «sort_order» de la classe «hpm_way_route», «position_number» spécifie le déroulement des emplacements de la signalisation sur l’itinéraire.

Image 11: Extrait du modèle de données MGDM vélo – réseau de chemins vélo avec itinéraires et signalisation


45

A.5. Modèle de données MGDM VTT

A.5.1. – Réseau de chemins VTT

Pour la reproduction du réseau de chemins VTT la classe hpm_way_hiking est complétée par l’attribut «is_singletrail», qui est un attri-but obligatoire. Etant donné que une partie du modèle – ici VTT – est représentée, un «hpm_way» a-t-il au maximum une référence à une géométrie de base. La classe «metadata», obligatoire dans tous les modèles partiels.

Image 12: Extrait du modèle de données MGDM VTT – réseau de chemins VTT


46

A.5.2. Réseau de chemins VTT avec itinéraires (sans signalisation)

Si des itinéraires doivent être représentés sur le réseau de chemins VTT, les deux classes «hpm_way_route» et «route» doivent en outre être utilisées. Le déroulement des géométries peut être définit avec l’attribut «sort_order» et l’attribut «belongs_to_stage» carac-térise l’étape à laquelle la géométrie appartient. L’attribut «sort_order» est utile, lorsqu’il faut connaitre le déroulement des segments le long de l’itinéraire. Par exemple lorsque le trajet aller est différent de celui retour.

Image 13: Extrait du modèle de données MGDM VTT – réseau de chemins VTT avec itinéraires (sans signalisation)


47

A.5.3. Réseau de chemins VTT avec itinéraires et signalisation


Image 14: Extrait du modèle de données MGDM VTT – réseau de chemins VTT avec itinéraires et signalisation


48

A.6. Modèle de données MGDM EAV

A.6.1. Réseau de chemins EAV

Seulement quatre attributs de la classe «hpm_way» sont obligatoires pour la représentation du réseau de chemins EAV. Etant donné que une partie du modèle – ici EAV – est représentée, un «hpm_way» a-t-il au maximum une référence à une géométrie de base. La classe «metadata», obligatoire dans tous les modèles partiels.

Image 15: Extrait du modèle de données MGDM EAV – réseau de chemins EAV


49

A.6.2. Réseau de chemins EAV avec itinéraires (sans signalisation)

Si des itinéraires doivent être représentés sur le réseau de chemins EAV, les deux classes «hpm_way_route» et «route» doivent en outre être utilisées. Le déroulement des géométries peut être définit avec l’attribut «sort_order» et l’attribut «belongs_to_stage» ca-ractérise l’étape à laquelle la géométrie appartient. L’attribut «sort_order» est utile, lorsqu’il faut connaitre le déroulement des seg-ments le long de l’itinéraire. Par exemple lorsque le trajet aller est différent de celui retour.

Image 16: Extrait du modèle de données MGDM EAV – réseau de chemins EAV avec itinéraires (sans signalisation)


50

A.6.3. – Réseau de chemins EAV avec itinéraires et signalisation


Image 17: Extrait du modèle de données MGDM EAV – réseau de chemins EAV avec itinéraires et signalisation


51

Annexe B – Glossaire

Terme (Allemand) Terme (Anglais) Terme (Français) Explication

Basisgeometrie Basic geometry Géométrie de base Le réseau routier qui sert de base pour le ré-seau de mobilité douce.

Belagsart Type of surfacing Type de revêtement Le type de revêtement est souvent associé à un attribut de la géométrie mais est également d'une grande importante pour la mobilité douce, p.ex. pour évaluer la qualité d'un itiné-raire de randonnée pédestre ou EAV.

FA LV SA HPM (special applica-tion)

AM MD Application métier Mobilité douce: MISTRA-Application métier, qui est mise à disposition des cantons pour la gestion des réseaux de mobilité douce. Elle permet la gestion des ré-seaux et des itinéraires de randonnée, vélo, VTT et EAV, ainsi que de la signalisation.

FäG ESV (equipment similar to a vehicle)

EAV Le terme d'engins assimilés à des véhicules (EAV) désigne tous les moyens de locomotion à roues ou à roulettes mus par la seule force musculaire des utilisateurs. En font partie les patins à roulettes, rollers, planches à roulettes, trottinettes et vélos d'enfants (pour enfants d'âge préscolaire).

Fussverkehr Pedestrian traffic Trafic piéton Le trafic piéton correspond aux trajets effec-tués par les piétons. Dans le présent contexte, il s’agit surtout de la délimitation de la randon-née en activité de loisir.

Geometriedaten Geometrical data Données géométriques Les données géométriques incluent les attri-buts qui ne dépendent pas de la géométrie d'un point de vue technique. Parmi les exemples figurent la largeur de la route, les coordonnées-Z ou la longueur.


52


HPM HPM HPM Human-Powered Mobility, Mobilité douce

Kardinalität Cardinality Cardinalité La cardinalité d’une quantité correspond au nombre d’éléments dans cette quantité.

Langsamverkehr HPM = human-powered mobility

Mobilité douce On entend par mobilité douce le fait de se dé-placer à pied, sur roues ou sur roulettes, à la seule force musculaire humaine.

Langsamverkehrsnetz HPM network Réseau de mobilité douce La somme des chemins de mobilité douce (chemins MD) d‘un type de MD déterminé produit le réseau de mobilité douce (réseau MD) sur lequel les itinéraires se déroulent. Le réseau MD constitue un sous-ensemble de la géométrie (de base).

LV-Art, Langsam-verkehrsart

HPM_type Type MD, Type de mobili-té douce

Randonnée, Vélo, VTT, EAV, Trafic piéton

LV-Weg HPM_way Chemin MD Un chemin MD représente la partie la plus pe-tite du réseau de mobilité douce d’un type de mobilité douce comme la randonnée. Un che-min recouvre parfaitement avec la géométrie sous-jacente ; il n’est donc pas plus court ou plus long et il ne chevauche pas entièrement ou en partie plusieurs segments. La somme des chemins MD produit réseau de mobilité douce, sur lequel les itinéraires se déroulent.

MTB MTB VTT Un vélo tout terrain (VTT) est conçus pour une utilisation hors des routes goudronnées, en forêt ou en montagne.

Netzlücke (Fussverkehr) Network gap (pedestrian traffic)

Lacune du réseau (mobili-té piétonne)

Les lacunes se traduisent par des liaisons manquantes pour le trafic piéton alors que les points faibles concernent des défauts qualita-tifs des chemins piétons. La délimitation de lacunes et points faibles est floue. Les critères


53


relevants sont différents pour chaque groupe d’utilisateurs. Pour une personne en fauteuil roulant un abaissement manquant du trottoir représente une lacune, tandis que pour autres groupes d’utilisateurs il s’agit plutôt d’un tron-çon de route pas éclairé.

Route Route Itinéraire Une concaténation sans interruption de che-mins de mobilité douce. Pour les itinéraires touristiques les tronçons de lignes de trans-ports peuvent être utilisés afin de garantir l'ex-haustivité.

Routen-Standortliste (RSL)

Route-location list LEI (Liste des emplace-ments - Itinéraires)

La liste des emplacements - Itinéraires corres-pond à l'agencement des emplacements de la signalisation sur un itinéraire.

Routenart Hauptroute Route_type «main_route» Type d’itinéraire principal Un itinéraire avec origine et destination, sans part d'itinéraire circuit.

Routenart Nebenroute Route_type «seconda-ry_route»

Type d’itinéraire secon-daire

Un itinéraire secondaire débute sur un itiné-raire principal et se termine à l'écart de l'itiné-raire principal. Si faisant il est possible de re-présenter les cas particuliers comme le Chemin de St-Jacques ou les itinéraires Y.

Routenart Variante Route_type «alterna-tive_route»

Type d’itinéraire variante Une variante début et se termine sur un itiné-raire principal et représente une alternative au tracé de l'itinéraire principal

Routenart Zubringer Route_type «tributa-ry_route»

Type d’itinéraire voie d'accès

Les voies d'accès sont des courts itinéraires, que l'on retrouve généralement dans les zones urbanisées qui permettent p.ex. l'accès à une gare ou au centre-ville à partir d'un ou plu-sieurs itinéraires. Il peut s’agir aussi de liai-sons, qui ne se déroulent comme des itiné-


54


raires autonomes, par ex. depuis ou vers un point de vue. Les raccordements peuvent être signalisés seulement avec un indicateur de direction avec pictogrammes ou texte court ainsi qu’avec un indicateur de direction avec des panneaux «normaux».

Sachdaten Descriptive data Données spécifiques Les données spécifiques incluent les attributs qui, d'un point de vue technique propre à la mobilité lente, sont recueillis, gérés ou échan-gés Exemples: Type d’itinéraire, degré de difficulté ou type de chemin. Une place particulière est occupée par le type de revêtement. Il se peut que, comme pour le MTP, la plage de valeurs au niveau des don-nées géométriques ne soit pas suffisante et qu'il soit nécessaire de l'étendre au données spécifiques.

Schwachstelle (Fuss-verkehr)

Black_spot (pedestrian traffic)

Point faible (mobilité pié-tonne)

Les points faibles concernent des défauts qua-litatifs des chemins piétons.

Segment Segment Segment Arête simple du modèle modèle de nœuds respectivement des arêtes du MTP.

Signalisationsstandort Location of signalisation Emplacements pour la signalisation

Emplacements sur le terrain, ou le support avec panneaux resp. indicateurs de direction est fixé. Plusieurs types de MD peuvent être affichés sur un emplacement de la signalisa-tion.

Singletrail Singletrail Singletrail Un singletrail caractérise un sentier étroit me-surant en général entre 30 et 60 cm qui peut accueillir un vététiste.


55


Standortkategorie Location_category Catégorie d'emplacement Les catégories d'emplacement A, B ou C per-mettent la catégorisation des emplacements de la signalisation en relation à un itinéraire.

swissTLM3D swissTLM3D swissTLM3D Le modèle topographique du paysage est le cœur de la production de géodonnées à l'échelle nationale. Il comprend des objets du paysage tels que, par exemple, bâtiments, routes ou cours d'eau. Ces données sont sai-sies, traitées, gérées en 3D de façon précise et actuelle dans une qualité homogène et mises à disposition par swisstopo. Le MTP est non seulement la base de l'élaboration des cartes nationales mais il sert également de base à une large gamme d'applications territo-riales les plus diverses.

Technische Route Technical route Itinéraire technique Le terme itinéraire technique est actuellement employé surtout pour le type de MD randon-née. Il décrit un itinéraire dans le terrain signa-lisé par des indicateurs de direction. Les itinéraires techniques constituent la base pour les informations de directions sur les panneaux conformément aux exigences défi-nies dans la norme suisse SN 640 829a «Si-gnaux routiers - Signalisation du trafic lent». Etant donné que le réseau de chemins offre d’innombrables variantes, pour aller d'un en-droit à un autre endroit éloigné, un choix judi-cieux des destinations accessibles doit figurer sur les indicateurs de direction. A cet effet des itinéraires techniques sont définis dans le cadre de la conception. Ceux-ci couvrent le


56


réseau de chemins entier et déterminent quelles destinations à partir de quels points de départ sont atteignables.

TLM (swissTLM3D) TLM (swissTLM3D) MTP (swissTLM3D) swissTLM3D est le modèle topographique du paysage à grande échelle de la Suisse. Il comprend des objets naturels et artificiels ainsi que des données de noms sous forme vecto-rielle. Produit de swisstopo, successeur du Vector25

Touristische Route Touristical route Itinéraire touristique Un itinéraire touristique représente un itiné-raire qui, en règle générale, est signalisé avec un numéro et un nom par un champ d’itinéraire. Il peut être complété avec un indi-cateur de direction.

Verkehrsmittel Mode of transport Moyen de transport Un tronçon qui peut être traversé par des transports publics comme train, bateau, bus, etc. Il fait en sorte que les itinéraires touris-tiques ne comportent jamais d'interruptions. Les itinéraires techniques ne présentent pas de moyens de transports. pas de tronçons de ligne de transport.

Wandernahe Route hikingish_route Itinéraire proche de la randonnée pédestre

Chemin de randonnée d’hiver, de promenade, etc.

Tableau 14: Glossaire


57

Annexe C – Documents détaillés

1. OFROU, Suisse Rando: Signalisation des chemins de randonnée pédestre. Guide de recommandations de la mobilité´ douce. Nr. 6. Berne, 2008.

2. Géoportail de la Confédération: Ordonnance sur la géoinformation (OGéo) du 21 mai 2008. URL: http://www.admin.ch/opc/fr/classified-compilation/20071088/index.html

3. Géoportail de la Confédération: Echéancier: directive sur les «modèles de géodonnées minimaux». Recueil des jeux de géo-données de base de droit fédéral. URL: http://www.geo.admin.ch/internet/geoportal/fr/home/topics/geobasedata/introductionplan.html

4. Organe de coordination de la géoinformation de la Confédération: Recommandations générales portant sur la méthode de dé-finition des «modèles de géodonnées minimaux». Berne, 2012.

5. Assemblée fédérale: Loi fédérale sur les chemins pour piétons et les chemins de randonnée pédestre (LCPR). 6. Markus Capirone, Daniel Leupi, et Lukas Stadtherr: Conception d'itinéraires cyclables. Guide de recommandations de la mobili-

té´ douce. Nr. 5. 2008. 7. Pietro Cattaneo, Niklaus Trottmann: Planification du réseau des chemins de randonnée pédestre. Manuel. Bern, 2014. 8. Fondation La Suisse à vélo: La Suisse à vélo. Manuel. 2006. 9. La Suisse à vélo, et al.: Présentation des informations concernant la mobilité douce et sa combinaison avec les offres des

transports publics. Zürich, 2007. 10. Fondation SuisseMobile, Suisse Rando: Degrés de difficulté en mobilité douce. Manuel. Bern, 2012. 11. Swisstopo: swissTLM3D 1.1. URL:

http://www.swisstopo.admin.ch/internet/swisstopo/fr/home/products/landscape/swissTLM3D.html 12. VSS Zurich: Signaux routiers. Signalisation du trafic lent. (Norme 640 829a). 2006.


58

Annexe D – Modèle-INTERLIS INTERLIS 2.3;

/** ========================================================================================================

* * Hpm_network_V1.ili

* * --------------------------------------------------------------------------------------------------------

* * Identifikator GeoIV : 67

* * Bezeichnung GeoIV : Velowegnetze

* * Zuständige Stelle : Kantone [ASTRA]

* * Identifikator GeoIV : 79

* * Bezeichnung GeoIV : Fuss- und Wanderwegnetze

* * Zuständige Stelle : Kantone [ASTRA]

* * ========================================================================================================

* * identificateur OGéo : 67

* * désignation OGéo : Réseaux de voies cyclables

* * Service compétent : Cantons [OFROU]

* * identificateur OGéo : 79

* * désignation OGéo : Chemins pour piétons et de randonnée pédestre

* * Service compétent : Cantons [OFROU]

* * --------------------------------------------------------------------------------------------------------

* * Version | Who | Modification

* * --------------------------------------------------------------------------------------------------------

* * 2014-07-14 | UD | Draft

* * 2014-11-20 | UD | Version for Kick-off Meeting FIG

* * 2016-07-25 | UD | Draft for Consultation

* * 2014-09-16 | ML | Version for Consultation

* * ========================================================================================================

*/

!!@ technicalContact=mailto:[email protected]

!!@ IDGeoIV="67.1,79.1"

!!@ furtherInformation=http://www.astra.admin.ch/themen/langsamverkehr/

MODEL Hpm_network_V1 (en)

AT "http://models.geo.admin.ch/ASTRA/"

VERSION "2016-09-16" =

IMPORTS GeometryCHLV95_V1;

TOPIC hpm_network =


59

/** Sie ist nicht Bestandteil des MGDM, sondern soll veranschaulichen, dass durch einen zusätzlichen Schlüssel

(«id_geometry» der Klasse «hpm_way») auf einen vorzugsweise amtlichen, gepflegten Datensatz der Datenaustausch weiter

verbessert werden kann.

* Die Fachapplikation LV setzt in analoger Weise auf dem swissTLM3D der swisstopo auf.

*/

CLASS base_geometry =

/** Jedes Element des Datensatzes, das als Grundlage verwendet wird, hat einen eindeutigen Schlüssel.

*/

id_base_geometry : MANDATORY OID TEXT*50;

/** Hier wird angegeben, mit welchem Datensatz (Name, Hersteller) und mit welcher Version des angegebenen Daten-

satzes gearbeitet wurde.

*/

base_geometry_version : MANDATORY TEXT*100;

END base_geometry;

/** «hpm_way» ist die zentrale Klasse zur Modellierung von LV-Netzen für Wandern, Velo, MTB, FäG und für den Fuss-

verkehr.

* Weil für die Langsamverkehrsarten Velo und FäG keine zusätzlichen Attribute zur Klasse «hpm_way» vorgesehen

sind, entfällt eine spezialisierte Klasse, wie sie für Wandern und MTB vorhanden sind.

*/

CLASS hpm_way =

/** Objektidentifikation bzw. eindeutiger Schlüssel des Langsamverkehrswegs.

*/

id_hpm_way : MANDATORY OID TEXT*50;

/** Das Attribut speichert die Langsamverkehrsart ab. Werte:

* «hiking» (Wandern)

* «cycling» (Velo)

* «MTB» (Mountainbike)

* «skating» (FäG)

* «pedestrian» (Fussverkehr)

*/

hpm_type : MANDATORY (

hiking,

cycling,

MTB,

skating,

pedestrian

);

/** Die Geometrie des Weges.


60

*/

geometry : MANDATORY DIRECTED POLYLINE WITH (STRAIGHTS) VERTEX GeometryCHLV95_V1.Coord3;

/** Oberflächenbeschaffenheit des Weges.

* «hard_surface» (hart)

* «natural_surface» (natur)

* «unknown» (unbekannt)

*/

surface : (

hard_surface,

natural,

unknown

);

/** Werteliste:

* «cantonal_structure_plan» (Kantonaler Richtplan)

* «regional_structure_plan» (Regionaler Richtplan)

* «local_structure_plan» (Lokaler Richtplan)

* «foot_or_hiking_network_plan» (Fuss oder Wanderwegplan)

* «provisional_foot_or_hiking_network_plan» (Provisorischer Fuss oder Wanderwegplan)

* «agglomeration_programme» (Agglomerationsprogramm)

* «other_stipulation_obliging_authorities» (andere behördenverbindliche Festlegung)


*/

obliging_authorities : (

cantonal_structure_plan,

regional_structure_plan,

local_structure_plan,

foot_or_hiking_network_plan,

provisional_foot_or_hiking_network_plan,

agglomeration_programme,

other_stipulation_obliging_authorities,

unknown

);

/** Die Werte können von Kanton zu Kanton unterschiedlich sein. Beispiel: «Kantonaler Richtplan vom 22.3.2003».

*/

source_obliging_authorities : TEXT*500;

/** Gibt an, ob ein Langsamverkehrsweg geplant, realisiert oder aufzuhebend ist. Werteliste:

* «existing» (realisiert)

* «planned» (geplant)

* «way_to_repeal» (aufzuheben)


61

*/

way_state : (

existing,

planned,

way_to_repeal

);

/** Objektidentifikation. Diese ID ist fakultativ und ermöglicht die Bezugnahme auf einen bestehenden Datensatz

über diesen Schlüssel, z.B. auf das swissTLM3D der swisstopo. Der Wert dieser ID entspricht einem ID-Wert des Geomet-

riedatensatzes.

*/

id_base_geometry : OID TEXT*100;

/** Ein Verkehrsmittel überbrückt auf einer (Touristischen) Route einen See, grosse Höhenunterschiede oder Ab-

schnitte, die aus Gründen der Sicherheit oder Attraktivität mit einem Verkehrsmittel wie Autobus, Bahn oder Ähnlichem

zurückgelegt werden.

* Ist ein Wert aus der Werteliste genannt, wird die Strecke automatisch mit einem Verkehrsmittel überbrückt.

* «bus» (Autobus)

* «boat» (Schiff)

* «train» (Eisenbahn)

* «rack_railway» (Zahnrad- und Standseilbahn)

* «aerial_cableway» (Luftseilbahn)

* «gondola_cableway» (Gondelbahn)

* «chairlift» (Sessellift)

* «tram» (Strassenbahn)

* «other_public_transport» (Andere_Verkehrsmittel)

*/

public_transport_section : (

bus,

boat,

train,

rack_railway,

aerial_cableway,

gondola_cableway,

chairlift,

tram,

other_transport_roadway

);

/** Drei Werte sind möglich. Werteliste:

* «correct» (in_Ordnung): Der Wegabschnitt ist bezüglich der vorliegenden Langsamverkehrsart in Ordnung.

* «deficient» (mangelhaft): Der Wegabschnitt ist mangelhaft.


62


*/

state_of_way : (

correct,

deficient,

unknown

);

/** Gibt an, ob der LV-Weg auf einem grundeigentümerverbindlich gesicherten Weg verläuft. Werteliste:

* «yes» (ja)

* «no» (nein)


*/

obliging_land_owner : (

yes,

no,

unknown

);

/** Kommentar zur Behördenverbindlichkeit.

*/

obliging_land_owner_comment : MTEXT*1000;

/** Gibt an, ob ein LV-Weg geeignet ist für hindernisfreie Routen. Werteliste:

* «yes» (ja)

* «no» (nein)

*/

is_suitable_for_handicap_route : BOOLEAN;

END hpm_way;

/** Die Klasse bildet die n:m Beziehung zwischen «hpm_way» und «route» ab. Das Attribut «sort_order» bildet optio-

nal die Reihenfolge ab, in welcher die Elemente aus «hpm_way» eine Route bilden. Das Attribut «sort_order» ist für kom-

plexe Routen nötig.

*/

CLASS hpm_way_route =

/** Ermöglicht die Angabe, welche Segmente aus «hpm_way» in welcher Reihenfolge die Route bilden.

*/

sort_order : 0 .. 100000;

/** Das optionale Attribut dient der Angabe, zu welcher Etappe das vorliegende Segment bzw. die vorliegende Geo-

metrie gehört. Das Attribut bleibt z. B. leer, falls:

* - es sich um eine LV-Art handelt, die keine Etappen verwendet

* - es sich um eine Technische Wanderroute handelt.


63

*/

belongs_to_stage : 0 .. 100;

END hpm_way_route;

/** Die Klasse nimmt die wichtigsten Metadaten auf.

*/

CLASS metadata =

/** Hier wird der Eigner der Daten, in der Regel der Kanton, hinterlegt.

*/

owner : MANDATORY TEXT*100;

/** Optionale Angabe zur Version des Datensatzes.

*/

version : TEXT*20;

/** Optionale Angabe des Datums oder einer «freien» Zeitangabe wie «März 2016» zum letzten Update des Datensat-

zes.

*/

last_updated : TEXT*100;

/** Optionale Angabe einer Kontaktadresse.

*/

contact_information : MTEXT*500;

END metadata;

/** Diese Klasse modelliert Routen, die aus Wegen der Klasse «hpm_way» zusammengesetzt sind.

*/

CLASS route =

/** Primärschlüssel der Klasse Route, die eine Route innerhalb des Systems eindeutig über alle Langsamverkehrsar-

ten identifiziert.

*/

id_route : MANDATORY OID TEXT*50;

/** Die Technische Routennummer ist ein Schlüssel, der Routen innerhalb einer Langsamverkehrsart eindeutig iden-

tifiziert. Länge: 20 Zeichen.

*/

technical_route_number : MANDATORY TEXT*20;

/** Der Technische Routenname besteht aus den A-Zielen der Route (Wandern) bzw. aus den Hauptzielen bei Velo und

MTB, mindestens zusammengesetzt aus dem Ausgangs- und Zielort der Route.

*/

technical_route_name : MANDATORY TEXT*200;

/** Die Touristische Routennummer ist für die Signalisation der touristischen Routen relevant. Folgende Richtli-

nien müssen eingehalten werden:


64

* - Die Nummer muss innerhalb jeder Fortbewegungsart des Langsamverkehrs eindeutig sein.

* - Die nationalen Routen erhalten die Nummern 1–9 (gemäss Konzept von SchweizMobil).

* - Die regionalen Routen erhalten die Nummern 21–99 (gemäss Konzept von SchweizMobil).

* - Die lokalen Routen erhalten die Nummern 101 -999 (gemäss Konzept von SchweizMobil).

*

* - Für die Vergabe der Routennummern sind grundsätzlich die Kantone nach der Zuweisung eines Wertebereichs

durch SchweizMobil bzw. die Schweizer Wanderwege zuständig. Der Bund kann sie dabei koordinierend unterstützen.

* - Die internationalen Routen haben neben der Nummer ein vorangestelltes «E» (z. B. E7).

*/

touristic_route_number : TEXT*10;

/** Der Touristische Routenname ergänzt die Touristische Routennummer.

*/

touristic_route_name : TEXT*200;

/** Die optionale Routenbeschreibung enthält Angaben zur Route als Ganzes, ev. eine Beschreibung einzelner Etap-

pen oder Angaben über wichtige Points of interest.

*/

route_description : MTEXT*1000;

/** Gibt an, um welchen der folgenden Routenarten es sich handelt. Werteliste:

* «main_route» (Hauptroute (einfache Route))

* «secondary_route» (Nebenroute)

* «alternative_route» (Variante)

* «tributary_route» (Zubringer)

*/

route_type : (

main_route,

secondary_route,

alternative_route,

tributary_route

);

/** Wertebereich für Touristische Routen. Werteliste:

* «international» (International)

* «national» (National)

* «regional» (Regional)

* «local» (Lokal)

* «local_others» (Lokal (andere))

* «unknown» (Unbekannt)

*/

route_category : (

international,


65

national,

regional,

local,

local_others,

unknown

);

/** Werteliste:

* «hiking_route» (Wanderroute)

* «cycle_route» (Veloroute)

* «MTB_route» (MTB-Route)

* «skating_route» (Skatingroute)

* «pedestrian_route» (Fussgängerroute)

* «hikingish_route» (wandernahe Route)

* «handicap_route» (hindernisfreie Route – nur technische Routen)

*/

hpm_route_type : MANDATORY (

hiking_route,

cycle_route,

mtb_route,

skating_route,

pedestrian_route,

hikingish_route,

handicap_route

);

/** Gibt den Realisierungsstand der Route an. Werteliste:



* «route_to_repeal» (aufzuheben)

*/

route_state : (

planned,

existing,

route_to_repeal

);

/** Speichert den Ausgangsort (Name) der Route.

*/

starting_point : MANDATORY TEXT*100;

/** Speichert den Zielort (Name) der Route.

*/


66

destination : MANDATORY TEXT*100;

/** Dieses Attribut speichert die technischen Anforderungen, die an den Benutzer der Route gestellt werden, ab-

hängig von der Langsamverkehrsart. Das Attribut ist für die LV-Art Wandern nur im Zusammenhang mit touristischen Routen

sinnvoll. Folgende Werte sind möglich:

* «easy»

* Wandern: Leicht (Wandern). Anforderungen: Keine besonderen Anforderungen. Wegqualität/Gelände: Allgemein zu-

gängliche Wege, möglichst abseits Strassen für den Mfz-Verkehr, möglichst nicht asphaltiert, steile Passagen werden mit

Stufen überwunden, Bäche auf Stegen oder Brücken passierbar.

* Velo: Auch für Anfänger und Kinder.

* MTB: Keine spezifischen MTB-Kenntnisse nötig.

*

* «medium»

* Wandern: Mittel (Bergwandern). Anforderungen: Gute körperliche Verfassung, Trittsicher/schwindelfrei, Kennt-

nisse der Gefahren im Gebirge (Steinschlag, Rutsch-/Absturzgefahr, Wetterumsturz). Wegqualität/Gelände: Teilweise un-

wegsames Gelände, überwiegend steil und schmal, Bäche teilweise nur über Furten passierbar, teilweise exponiert.

* Velo: Verkehrserfahrung nötig

* MTB: Guter Radfahrer, MTB-Grundkenntnisse nötig.

*

* «hard»

* Wandern: Schwer (Alpinwandern). Anforderungen: Sehr gute körperliche Verfassung, trittsicher / schwindelfrei,

vertraut im Umgang mit Seil/Pickel, Vertraut mit Kletterpassagen unter zu Hilfenahme der Hände, Kenntnisse der Gefahren

im Gebirge (Steinschlag, Rutsch- / Absturzgefahr, Wetterumsturz). Wegqualität/Gelände: Teilweise durch wegloses Gelän-

de, über Schneefelder, Gletscher und Geröllhalden. durch Steinschlagrunsen oder durch Fels mit kurzen Kletterstellen,

bauliche Vorkehrungen können nicht vorausgesetzt werden.

* Wanderland enthält keine Alpinwanderwege.

* Velo: Gute Verkehrserfahrung nötig.

* MTB: Erfahrener Mountainbiker mit guter Fahrtechnik.

*

* Es sind nicht für alle Langsamverkehrsarten technische Anforderungen definiert.

*/

technical_demand : (

easy,

medium,

hard

);

/** Dieses Attribut speichert die konditionellen Anforderungen, die an den Benutzer der Route gestellt werden;

sie sind abhängig von der Langsamverkehrsart.


67

* Der Bereich «Wandern» der Schweizer Wanderwege hat aufgrund von Rückmeldungen der Wandernden, und weil die

Begrifflichkeiten nicht stimmig sind, die Angaben zu den konditionellen Anforderungen angepasst. Statt von leichten,

mittleren und schweren Anforderungen zu sprechen, verwenden sie die Werte «tief», «mittel» und «hoch»

* «easy»

* Wandern: Länge: < 12 km, Höhenmeter: < 300 hm, Gehzeit: < 4 h.

* Velo: Länge: bis ca. 50 km, Höhenmeter: bis 300 hm, Fahrzeit: bis 4 h.

* MTB: Länge: bis 40 km, Höhenmeter: bis 800 hm, Fahrzeit: bis 4 h.

*

* «medium»

* Wandern: Länge: < 15 km, Höhenmeter: < 800 hm, Gehzeit: < 5 h.

* Velo: Länge: bis ca. 70 km, Höhenmeter: bis 800 hm, Fahrzeit: bis 5 h.

* MTB: Länge: 50 km, Höhenmeter: bis 1200 hm, Fahrzeit: bis 5 h.

*

* «hard»

* Wandern: Länge: > 15 km, Höhenmeter: > 800 hm, Gehzeit: > 5 h.

* Velo: Länge: > 70 km, Höhenmeter: > 800 hm, Fahrzeit: > 5 h.

* MTB: Länge: > 50 km, Höhenmeter: > 1200 hm, Fahrzeit: > 5 h.

*

* «unknown»

*

* Es sind nicht für alle Langsamverkehrsarten konditionelle Anforderungen definiert.

*/

stamina_requirement : (

easy,

medium,

hard,

unknown

);

/** Angabe, ob eine Route der LV-Arten Velo, MTB oder FäG in beide Richtungen signalisiert ist oder nicht. Die

Angabe Start-Ziel bzw. Ziel-Start beziehen sich auf den Routennamen.

* «bidirectional»

* «start_to_end»

* «end_to_start»

*/

direction_of_signalisation : (

bidirectional,

start_to_end,

end_to_start

);


68

END route;

/** Diese Klasse modelliert die n:m Beziehung zwischen Routen und Signalisationsstandorten. Durch das Attribut «lo-

cation_category» wird die Standortkategorie abgebildet, die insbesondere für das Wandern von grosser Wichtigkeit ist.

*/

CLASS rsl =

/** Speichert für die LV-Art Wandern die Standortkategorie (A, B oder C).

*/

location_category : TEXT*20;

/** Gibt die Reihenfolge des Signalisationsstandortes bezogen auf eine Route und deren Abwicklung an.

*/

position_number : 1 .. 1000;

END rsl;

/** Die Klasse «signalisation» beinhaltet die Koordinatenangaben der (physischen) Standorte.

*/

CLASS signalisation =

/** Eindeutiger Schlüssel zur Identifikation des (physischen) Signalisationsstandortes.

*/

id_signalisation : MANDATORY OID TEXT*50;

/** Speichert die Koordinaten des Signalisationsstandorts.

*/

geometry : MANDATORY GeometryCHLV95_V1.Coord3;

/** Standort- bzw. Flurname des Signalisationsstandortes. Der Wert, der für das Standortfeld verwendet wird.

*/

field_name : TEXT*100;

/** Höhenangabe des Signalisationsstandortes.

*/

altitude : 0 .. 4500;

/** Gibt den Realisierungsstand der Signalisation an. Folgende Werte sind möglich:



* «signalisation_to_repeal» (aufzuheben)

*/

signalisation_state : (

existing,

planned,

signalisation_to_repeal

);


69

END signalisation;

/** Die spezialisierte Klasse «hiking_way» erbt die Eigenschaften (Attribute) der Klasse «hpm_way» bzw. erweitert

diese um das Attribut «hiking_segment_type». Diese Klasse dient der Modellierung von Wanderwegen.

*/

CLASS hiking_way

EXTENDS hpm_way =

/** Kategorien im Bereich Wandern. Werteliste:

* «hiking_trail» (Wanderweg)

* «mountain_hiking_trail» (Bergwanderweg)

* «alpine_hiking_trail» (Alpinwanderweg)

*/

hiking_segment_type : MANDATORY (

hiking_segment,

mountain_hiking_segment,

alpine_hiking_segment

);

END hiking_way;

/** Die spezialisierte Klasse «mtb_way» erbt die Eigenschaften (Attribute) der Klasse «hpm_way» bzw. erweitert die-

se um das Attribut «is_singletrail».

*/

CLASS mtb_way

EXTENDS hpm_way =

/** Zeigt an, ob ein LV-Weg für MTB ein Singletrail ist oder nicht.

*/

is_singletrail : MANDATORY BOOLEAN;

END mtb_way;

/** Die spezialisierte Klasse «pedestrian_way» erbt die Eigenschaften (Attribute) der Klasse «hpm_way» bzw. erwei-

tert diese um die Attribute «is_black_spot», «black_spot_comment», «is_network_gap», «network_gap_comment».

*/

CLASS pedestrian_way

EXTENDS hpm_way =

/** Wenn der Wert «True» ist, handelt es sich um eine Schwachstelle.

*/

is_black_spot : BOOLEAN;

/** Beschreibt die Schwachstelle, unter Umständen auch die präzisere Verortung, wenn es sich um eine lange Geo-

metrie handelt (Linie).


70

*/

black_spot_comment : MTEXT*1000;

/** Wenn der Wert «True» ist, handelt es sich um eine Netzlücke im Fussverkehrsnetz.

*/

is_network_gap : BOOLEAN;

/** Beschreibt die Netzlücke, ev. ergänzt mit Angaben zur zeitlichen Behebung, zu Beschlüssen etc.

*/

network_gap_comment : MTEXT*1000;

END pedestrian_way;

ASSOCIATION Association_hpm_way_base_geometry =

each_base_geometry_entry_can_be_part_of_one_to_5_hpm_way_entries -- {0..5} hpm_way;

each_hpm_way_entry_can_have_one_base_geometry -- {0..1} base_geometry;

END Association_hpm_way_base_geometry;

ASSOCIATION Association_hpm_way_hpm_way_route =

each_hpm_way_route_entry_has_one_hpm_way_entry -- {1} hpm_way;

each_hpm_way_entry_can_be_part_of_n_hpm_way_route_entries -- {0..*} hpm_way_route;

END Association_hpm_way_hpm_way_route;

ASSOCIATION Association_hpm_way_route_route =

each_route_entry_can_be_part_of_n_hpm_way_route_entries -- {0..*} hpm_way_route;

each_hpm_way_route_entry_has_one_route_entry -- {1} route;

END Association_hpm_way_route_route;

ASSOCIATION Association_route_rsl =

each_rsl_entry_has_one_route -- {1} route;

each_route_entry_can_be_part_of_n_rsl_entries -- {0..*} rsl;

END Association_route_rsl;

ASSOCIATION Association_rsl_signalisation =

each_signalisation_entry_can_be_part_of_n_rsl_entries -- {0..*} rsl;

each_rsl_entry_has_one_signalisation_entry -- {1} signalisation;

END Association_rsl_signalisation;

END hpm_network;

END Hpm_network_V1.