Deprecated: Return type of YDataTable::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/bdavid/prod/georef/yamldoc/ydclasses/ydata.inc.php on line 428

Deprecated: Return type of YamlDataTable::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /home/bdavid/prod/georef/yamldoc/ydclasses/yamldata.inc.php on line 295
inspire (pub)
Menu : html yaml json edit check reindex dump unset
* 

{
    "title": "mise en oeuvre d'Inspire avec YamlDoc",
    "modified": "2019-02-04T00:00:00+00:00",
    "references": [
        "[Schéma JSON des méta-données Inspire ](?doc=inspire/schema)",
        "[Eléments de métadonnées Inspire et ISO plus réflexion d'utilisation du Dublin Core](?doc=inspire/metadata)",
        "[Thèmes Inspire et vocabulaires contrôlés utilisés pour les métadonnées](?doc=inspire/metadata-codelist)",
        "[Modèle de données Inspire déduit du règlement interopérabilité](?doc=inspire/datamodel)",
        "[Test d'un modèle de données des métadonnées Inspire (périmé)](?doc=inspire/metadata2)",
        "[Test de structuration de la directive Inspire](?doc=inspire/directive)"
    ],
    "logique": "##Principes\n- Les données sont organisées en séries de données (SD), chacune décrite par une fiche de méta-données (fMD).\n- Une SD est une compilation identifiable de données géographiques (définition de la directive Inspire).\n- Une SD correspond à un regroupement de données ayant un sens pour un utilisateurs, par ex un PPRI, un PLU, ...\n- Une SD correspond à une spécification et une structuration de la donnée,\n  typiquement pour les objets vecteur en collections homogènes d'objets, cad respectant un schéma commun.\n- Possibilité de décrire des versions successives d'une SD, par exemple la BDTopo au 1/3/2018, puis au 1/9/2018, ...,\n  en mutualisant les champs communs de MD.\n- Possibilité aussi de décrire une série de données mise à jour au fur et à mesure,\n  dans ce cas, la date de mise à jour doit être intégrée dans les données et non dans la fMD.\n- Possibilité de décrire un découpage en lots de données correspondant à un mécanisme de livraison,\n  par exemple, découpage de la BD Topo en départements.\n  \n##Accès aux données vecteur\n- il y a, a priori, 3 protocoles d'accès à une série de donnée:\n  - en flux d'accès WFS, a priori WFS3\n  - en flux de consultation EOTF ou WMS\n  - en téléchargement par exemple d'un ensemble de fichiers shape zippés\n- une SD est identifiée par un URI noté {uri}\n- l'accès à cet {uri} fournit la fMD de la SD structurée en Yaml (ou JSON) conformément\n  au [schéma défini ici](?doc=inspire/schema)\n- {uri}/wfs est l'URL d'accès au flux WFS des différentes collections correspondant à la SD,\n- {uri}/tile est l'URL d'accès au flux [EOTP](?ypath=/eotp) des différentes couches représentant la SD,\n- {uri}/wms est l'URL d'accès au flux WMS des différentes couches représentant la SD,\n- {uri}/atom est l'URL d'accès au flux [Atom](?ypath=/atom) diffusant:\n   - les versions successives de la SD,\n   - les différents lots de données dans lesquels la SD est découpée,\n   - les différents formats dans lesquels les lots sont exposés.\n\n##Définition d'un service de recherche\n- Un service de recherche permet à un utilisateur de découvrir les SD répondant à son besoin.\n- YamlDoc dispose d'un mécanimse général de recherche qui peut être utilisé pour effectuer ces recherches\n- Ainsi tous les docs ou sous-docs des classes concernées pourront être traités\n",
    "eotp": "##Protocole EOTP\nLe protocole appelé ici EOTP (Extended Osm Tile Protocol) est une extension\ndu [standard de facto d'OSM](https://en.wikipedia.org/wiki/Tiled_web_map)\nlargement utilisé, par exemple par Leaflet (au travers de classe TileLayer de Leaflet).  \nL'URL de premier niveau {baseUrl} fournit les MD du service avec notamment la liste des couches exposées.  \nChaque couche correspond à une URL {baseUrl}/layers/{lyrName}  \nL'appel de cet URL fournit les MD détaillées sur la couche, notamment le(s) format(s) autorisé(s)\net la couverture spatiale du service.  \nLes tuiles sont exposées en projection Web Mercator selon\nl'URL {baseUrl}/layers/{lyrName}(/style/{stylName})?/{z}/{x}/{y}.{fmt} où:\n\n  - {baseUrl} est l'URL de base du service\n  - {lyrName} est le nom de la couche\n  - {stylName} est le nom d'un éventuel style de représentation de la couche\n  - {z} est le niveau de zoom tel que défini par [OSM](https://wiki.openstreetmap.org/wiki/Zoom_levels)\n  - {x} et {y} sont les numéros de colonne et de ligne de l'image\n  - {fmt} est le format demandé qui doit valoir jpg ou png\n  \nCe format est compatible avec le [standard de facto d'OSM](https://en.wikipedia.org/wiki/Tiled_web_map),\nchaque couche correspondant à une URL founissant un flux conforme à ce standard.  \nIl ajoute la possibilité:\n  \n  - de regrouper différentes couches dans un même service,\n  - de décrire le service et chaque couche par des métadonnées.\n",
    "atom": "Description de l'utilisation du flux Atom\n",
    "implem": "##Implémentation\nLa logique décrite ici est assez proche des principes mis en oeuvre pour les classes\n[FeatureDataset](http://ydclasses.georef.eu/FeatureDataset) et [ViewDataset](http://ydclasses.georef.eu/ViewDataset).  \nIl conviendrait de définir une nouvelle classe GeoDataset qui:\n  \n  - s'appuie sur le schéma JSON d'une série de données Inspire et\n  - réunisse les fonctionnalités de ces 2 classes.\n"
}