Le schéma externe https://geojson.org/schema/Point.json était utilisé pour la géométrie du parking. Étant donné qu'elle est finalement en WKT, il est inutile et devrait être supprimé du schéma.

Le schéma externe https://geojson.org/schema/MultiLineString.json est utilisé pour la géométrie de l'itinéraire de randonnée. Il s'agissait de laisser une marge d'erreur et de valider un itinéraire si sa géométrie n'était pas une LineString, mais peut-être une MultiLineString pas fusionnée, ou autre possibilité. La suppression du schéma Point m'a amené à réévaluer cette marge d'erreur : est-elle souhaitable en termes de qualité des données ?
Le but du schéma étant de garantir une certaine qualité et interopérabilité des données, il est un peu contradictoire de laisser la possibilité d'avoir la géométrie d'un itinéraire en MultiLineString. Y aurait-il des cas où cela serait pertinent de laisser passer une géométrie de ce type ?

J'ai essayé deux validateurs de données à mettre à disposition des structures utilisatrices du schéma, et les deux ont leurs problèmes de compatibilité avec certaines versions du JSON Schema. Ces problèmes découlent du fait de faire référence aux JSON Schemas de la spécification GeoJSON au sein de notre schéma : cela permet de s'assurer que le fichier GeoJSON soit valide à tous les niveaux.

J'ai d'abord choisi de passer par des références aux schémas directement sur le site geojson.org, mais cela m'a été déconseillé par des contributeurs du JSON Schema car les implémentations ne gèrent pas toutes ces références distantes. Il est plus robuste de fournir tous les fichiers JSON Schema nécessaires à l'implémentation de manière locale.
Deuxième souci : j'ai rédigé le schéma selon la version 2020-12 de la spécification JSON Schema (la plus récente), mais les schémas GeoJSON sont eux en version draft-07. Cette différence peut ne pas être prise en charge par les validateurs.

Deux fichiers d'essai de validation sont disponibles dans la branche development : ajv.js pour Ajv et validator.py pour Jschon.

Ajv

Language : JavaScript (Node.js)
Avantages :

• supporte les versions 2020-12 à draft-07 du JSON Schema

Inconvénients :

• ne supporte pas les versions 2020-12 et draft-07 dans la même instance

Jschon

Language : Python (>3.8)
Avantages :

• très simple et peu verbeux

Inconvénients :

• ne supporte pas la draft-07 du JSON Schema

Solution ?

Je vois deux solutions :

• rétrograder le schéma itinéraires de randonnée en version draft-07, la version la plus largement utilisée et donc implémentée du JSON Schema, pour s'aligner sur le schéma GeoJSON et permettre une utilisation simple d'Ajv;
• réécrire les schémas GeoJSON en version 2019-09 ou 2020-12 pour permettre l'utilisation de Jschon.

En plus du schéma de randonnées, le dépôt propose une vue prédéfinie permettant d'exporter des randonnées dans une BDD Geotrek au format du schéma (https://github.com/PnX-SI/schema_randonnee/blob/master/geotrek/v_treks_schema.sql).

1. Itineraires parents

Un étape peut être associée à plusieurs itinérances. J'ai donc du remplacer la jointure simple qui pouvait entrainer des doublons par une sous-requête :

parent AS (
        SELECT string_agg(o.parent_id::text, ',') AS liste, t.topo_object_id
        FROM trekking_orderedtrekchild o
        JOIN selected_t t ON t.topo_object_id = o.child_id
        GROUP BY t.topo_object_id
        )

2. UUID

Des UUID ont été ajoutés à tous les objets depuis la version 2.70.0 de Geotrek-admin.
On peut donc désormais les récupérer dans le champs du prévu prévu pour cela :

top.uuid AS uuid

On pourrait aussi ajouter les UUID au niveau de chaque média, mais je pense que cela nécessite de publier une nouvelle version du schéma si on ajoute un champs au sous-objet "medias" ?

3. Géométrie

L'idée de simplifier la géométrie des tracés comme c'est le cas actuellement, pour alléger grandement le point des données fournies, est intéressante :

-- réduction de la précision des coordonnées à 5 décimales, simplification de la géométrie pour réduire le nombre de points. Poids de la géométrie divisée par 7.5
    st_simplifypreservetopology(st_snaptogrid(st_transform(top.geom, 4326), 0.000027::double precision), 0.000027::double precision) AS geom

Néanmoins, on a fait en sorte de construire les itinéraires sur des tracés de référence, BD topo la plupart du temps, donc diffuser des données qui ne sont plus bien calées sur ce référentiel me pose question.

En rouge la BD topo de l'IGN, en jaune le tracé originale des itinéraires, en bleu la version simplifiée proposée.

Je préfère retirer la simplification, diffuser la géométrie précise et originale calée sur le référentiel et avoir un fichier généré assez volumineux. Ainsi les partenaires auront exactement les mêmes tracés précis non dégradés.

En gardant le géométrie précise, mon fichier avec nos 156 randos fait 20 Mo, ce qui reste très correct : randos_pne_schema.geojson

Je n'ai pas compris l'usage de st_snaptogrid pour la géométrie des parkings. Cela était pour être cohérent avec la simplification des géométries des itinéraires ?
Donc si on enlève la simplification des itinéraires, on enlève le st_snaptogrid de la géométrie des parkings ?

4. OSM

Comme certaines randonnées sont présentes dans OSM mais qu'on n'a pas de champs pour stocker l'identifiant de la relation OSM dans la table des itinéraires ou des événements de Geotrek, j'ai ajouté une sous-requête avec les correspondances en dur :

    osm AS (
        SELECT * FROM (VALUES 
          (904199,12412634),
          (904321,13611265),
          (903486,13611430),
          (904197,12076664))
          AS liste (trek_id,id_osm)
    ),

5. Durée

Les durées sont arrondies à 1 décimale, mais du coup quand une durée est définie à "4.25" pour 4h15, le résultat est "4.3". Je ne trouve pas cela pertinent.
A la limite, on pourrait plutôt convertir les durées numériques en heure, transformer "4.25" en "4h15".

6. PDIPR

Dans notre cas, on a un réseau de tronçons indiquant ceux qui sont inscrits au PDIPR.
On pourrait croiser les itinéraires avec le réseau de tronçons pour identifier les itinéraires inscrits au PDIPR, mais cela serait assez spécifique et nécessiterait de vérifier que les tronçons intersectés par l'itinéraire sont tous associés au réseau PDIPR.

7. URL Geotrek-rando-v3

Désormais les accents sont supprimés dans les URL de Geotrek-rando-v3. Il faudrait donc peut-être utiliser aussi l'extension unaccent.
Les ' sont remplacés par des tirets dans les URL de Geotrek-rando-v3, ce qui n'est pas le cas actuellement dans la vue, mais je n'ai pas trouvé comment compléter le replace.

Il serait beaucoup plus simple et robuste d'utiliser directement les données JSON issues de l'API v2 au lieu d'une vue PostgreSQL.

Les trois choses à faire

• renommer les champs issus de l'API pour les faire correspondre au schéma ;
• gérer les données de la sous-requête constants de la vue SQL ;
• gérer les valeurs de champs pour lesquels une liste de valeurs a été définie (pratique, type_itineraire, etc.)

Un script Python ferait l'affaire, et nous débarrasserait des problèmes d'extension PostgreSQL, de sous-requêtes, jointures, etc.

Limites

Impossible de récupérer certaines données comme les types de sol ou l'inscription au PDIPR comme on avait commencé à y réfléchir en #15.

Dans Geotrek-admin, traduction à venir des champs de la table common_attachment, mettre la vue SQL en conformité lorsque la MAJ est déployée (+ numéro de version dans le README et la vue SQL).
Cf. GeotrekCE/Geotrek-admin#3055 (comment)

Le champs "instructions" qui contient la description "Pas à pas" est indiqué comme obligatoire actuellement.
Cela pose soucis à certaines plateformes comme IGNrando' pour qui se champs n'est pas obligatoire.
A voir si il pourrait être rendu non obligatoire ?
Ou sinon ceux qui ne l'ont pas toujours renseigné renvoient le champs mais vide ou à null ?

Votre dépôt Git doit comporter des tags indiquant les versions de votre schéma. Ces versions doivent respecter la gestion sémantique de version semver.

Ainsi, les URL déclarées dans schéma comme path ou encore resources pourront utiliser un tag Git et ainsi pointer sur la bonne version du schéma ou de la ressource.

Plus d'informations ici : https://schema.data.gouv.fr/documentation/validation-schemas

La documentation SCDL comporte également des précisions utiles à ce sujet : https://scdl.opendatafrance.net/docs/CONTRIBUTING.html

Exemple dans le schéma IRVE : https://github.com/etalab/schema-irve/blob/v1.0.3/schema.json#L8

    "path": "https://github.com/etalab/schema-irve/raw/v1.0.3/schema.json",

https://github.com/IdrissaD/schema_randonnee

Ajouter champs non obligatoire pour le PDIPR

• pdipr_inscription (boolean)
• pdipr_date_inscription (date)

Ajouter pas à pas dans le titre du champ instructions

Supprimer le champ cotation qui demande plus de réfléxion (clé, valeur)

Le multilinque apparaitra par la suite

Pour les catégories des randonnées, nous pourrions nous inspirer de la liste définie par Cirkwi. Ou tout du moins établir une correspondance.

L'avantage que nous voyons à utiliser cette liste est qu'elle est compatible avec Cirkwi (potentiellement IGN'rando) et qu'il y a un lien entre les pratiques et les catégories cirkwi dans Geotrek ce qui permettrait de faciliter les exports pour les utilisateurs de cette plateforme.

<locomotions>
  <locomotion nom="Marche" id="2"/>
  <locomotion nom="Velo_vtc" id="3"/>
  <locomotion nom="Vtt" id="4"/>
  <locomotion nom="Cheval" id="5"/>
  <locomotion nom="Camping_car" id="6"/>
  <locomotion nom="Voiture" id="7"/>
  <locomotion nom="Moto" id="8"/>
  <locomotion nom="Bus" id="9"/>
  <locomotion nom="Commun" id="10"/>
  <locomotion nom="Train" id="11"/>
  <locomotion nom="Quatre_quatre" id="12"/>
  <locomotion nom="Bateau" id="13"/>
  <locomotion nom="Quadricycle" id="15"/>
  <locomotion nom="Velo_route" id="16"/>
  <locomotion nom="Parapente" id="18"/>
  <locomotion nom="Avion" id="19"/>
  <locomotion nom="Raquette" id="20"/>
  <locomotion nom="Voilier" id="21"/>
  <locomotion nom="Nage" id="22"/>
  <locomotion nom="Bateau_rame" id="23"/>
  <locomotion nom="Trail" id="24"/>
  <locomotion nom="Fauteuil_roulant" id="25"/>
  <locomotion nom="Vae" id="26"/>
  <locomotion nom="Marche_nordique" id="27"/>
  <locomotion nom="Course_a_pied" id="28"/>
  <locomotion nom="Roller" id="29"/>
  <locomotion nom="Moto_tout_terrain" id="30"/>
  <locomotion nom="Moto_neige" id="31"/>
  <locomotion nom="Ski_fond" id="32"/>
  <locomotion nom="Ski_alpin" id="33"/>
  <locomotion nom="Ski_rando" id="34"/>
  <locomotion nom="Escalade" id="35"/>
  <locomotion nom="Fauteuil_roulant_3" id="36"/>
  <locomotion nom="Fauteuil_roulant_tt" id="37"/>
  <locomotion nom="Fauteuil_roulant_ele" id="38"/>
  <locomotion nom="Poussette" id="39"/>
</locomotions>

Comme vu en #15, on pourrait renseigner les champs type_sol et pdipr_inscription en passant par la table core_pathaggregation.
Dans l'idée (non fonctionnel) :

WITH paths_trek AS (
    SELECT path_id
     FROM core_pathaggregation cpa
       JOIN selected_t t
         ON t.topo_object_id = cpa.topo_object_id
),
network_id AS (
    SELECT id
      FROM core_network
    WHERE network ILIKE '%PDIPR%'
           OR network ILIKE '%Plan Départemental des Itinéraires de Promenade et de Randonnée%')
SELECT *
 FROM paths_trek pt
   JOIN core_path_networks cpn
     ON NOT (pt.path_id = cpn.path_id
                     AND cpn.network_id IN (SELECT id FROM network_id))

Pour les sols :

• obtention de tous les id de core_topology WHERE kind = 'LANDEDGE' qui ont un path_id en commun avec notre trek dans core_pathaggregation
• agrégation au sein d'une array de tous les land_physicaltype associés aux land_landedge associés aux core_topology précédemment obtenus