search

datagouv / schema.data.gouv.fr

Schémas de données ouvertes sur des formats réglementaires ou non
https://schema.data.gouv.fr
MIT License
41 stars 26 forks source link

Schéma des lieux proposant des services #214

Open cedricr opened 2 years ago

cedricr commented 2 years ago

Description du schéma

Plusieurs schemas déjà publiés aujourd'hui ou à l'étude correspondent à des "lieux" qui proposent des "services": lieux d'inclusion numériques, accessibilité des ERPs, équipements collectifs, etc. Chacun réinvente la partie "lieu" dans son schéma: identifiant, adresse, informations de contact, horaires, etc. Pour une meilleure interopérabilité il parait souhaitable de réfléchir à un schéma commun pour le "lieu", et à ne garder que la partie spécifique (le ou les "services") dans les schémas dédiés.

Liens

Equipement collectifs: https://schema.data.gouv.fr/scdl/equipements/ Lieu d'inclusion numérique: https://schema.data.gouv.fr/etalab/schema-inclusion-numerique/ Accessibilité des ERP: https://schema.data.gouv.fr/MTES-MCT/acceslibre-schema/

Tiers-lieu: https://github.com/etalab/schema.data.gouv.fr/issues/179 Offre d'insertion: https://github.com/etalab/schema.data.gouv.fr/issues/206

Commentaire sur les tiers lieux décrivant la nécessité de la séparation lieux/service: https://github.com/etalab/schema.data.gouv.fr/issues/179#issuecomment-987112214

Stade d'avancement

Ce schéma est :

bouviermullerp commented 2 years ago

Merci beaucoup pour la création de l'issue !

Il y a sans doute un joli chantier qui nous attend, car la modularisation des schémas de données a des conséquences non négligeables sur la manière de publier/récolter les données. Il y a un bel enjeu de conception à cet égard - qui pourrait peut être prétendre à un financement Dapsi d'ailleurs ?

@cedricr pour être plus explicite, il semble que l'interface la plus utilisée pour publier des jeux de données soit toujours le bon vieux tableur. Je ne sais pas si Open Data France (@johanricher ) a des informations à ce sujet, en tout cas la modularisation des schémas aurait des conséquences sur les interfaces de saisies ?

On se planifie une discussion en début d'année sur le sujet ? @geoffreyaldebert @vinber ? (si tu es à Toulouse @cedricr j'essaye d'y monter pour l'occasion :) )

cedricr commented 2 years ago

Avec grand plaisir @bouviermullerp! (on a déjà un rendez-vous pris dans le cadre de Dora début janvier je crois d'ailleurs!)

ThomasG77 commented 2 years ago

Voir pour regarder du côté de schema.org pour "place" https://schema.org/Place ?

johanricher commented 2 years ago

la modularisation des schémas aurait des conséquences sur les interfaces de saisies ?

A mon sens il n'y a pas de "modularité" des schémas, avec par exemple des schémas lieux et services qui seraient imbriqués pour qu'un seul et même producteur les utilise dans un processus unifié.

Il faut considérer la production des données des lieux et des données des services comme des processus distincts, correspondant à des métiers ou des politiques publiques distincts, menés par des organisations distinctes.

A mon sens c'est vraiment important de rappeler qu'un schéma n'est pertinent que si des organisations produisent déjà des données sur ce sujet et ont vocation à les publier. C'est pour ça qu'il faut identifier les données déjà produites (mais pas forcément publiées !) et concevoir le schéma avec leurs producteurs.

Quand il s'agit d'ERP par exemple, les données sont déjà détenues par les collectivités ou établissements publics qui sont propriétaires et/ou gestionnaires de ces lieux. Un schéma adapté à cette réalité leur permettra de savoir à l'avenir quel est le formalisme à suivre pour publier ces données (i.e. respecter la loi), ce qui permettra à data.gouv.fr de les agréger ensuite à l'échelle nationale.

C'est grâce à un identifiant unique que ces lieux pourront être référencés dans d'autres données, par exemple les données des services fournis dans ces lieux, et qui en l'occurence seront produites par d'autres acteurs spécialisés.

publier.etalab.studio est un outil à disposition de tous les acteurs qui pourra, si nécessaire, les aider à produire des données conformément aux différents schémas.

johanricher commented 2 years ago

Voir pour regarder du côté de schema.org pour "place" https://schema.org/Place ?

Je cherchais à mettre un nom sur ce qu'on cherche à modéliser, et me faisais aussi la réflexion que schema.org apporte un cadre assez bien défini et supporté par des usages très nombreux. "Lieu" ne correspond en effet à aucune définition juridique ou administrative (contrairement à ERP) ou de spécification existant (comme schema.org). Il faut deconstruire les concepts existants :

Etablissement recevant du public (ERP)

Définition juridique :

Les établissements recevant du public (ERP) sont des bâtiments dans lesquels des personnes extérieures sont admises. Peu importe que l'accès soit payant ou gratuit, libre, restreint ou sur invitation. Une entreprise non ouverte au public, mais seulement au personnel, n'est pas un ERP. Les ERP sont classés en catégories qui définissent les exigences réglementaires applicables (type d'autorisation de travaux ou règles de sécurité par exemple) en fonction des risques.

C'est un type de lieu, tous les lieux ne sont pas des ERP. Cependant on peut faire l'hypothèse que des organisations publiques (qui ont donc vocation à mettre leurs données en open data) ont déjà des données sur les ERP dont elles ont la propriété ou la gestion.

Equipement collectif

Définition donnée par un groupe de travail EquipCo du CRIGE PACA en 2008 :

La dénomination équipements collectifs couvre un ensemble large et varié d’éléments publics et/ou privés. Elle concerne les équipements urbains tels que les établissements scolaires, les structures sportives (stades, gymnases,…), culturelles (bibliothèques, musées, …), sociales, les établissements recevant du public (ERP), les établissements à répertorier (ETARE)… mais également les équipements de sport de pleine nature (sites d’escalade, itinéraires de randonnée pédestre ou de VTT…) ou de tourisme (campings, gîtes, …).

C'est un type de lieu, tous les lieux ne sont pas des équipements collectifs. Le schéma, écrit en 2018, et issu d'un vieux groupe de travail de 2008, n'a jamais été adopté. Des leçons doivent être tirées de cet échec !

Place

(qu'on pourrait traduire par "endroit" ou "lieu")

Spécification défine par schema.org

représentation physique et "quelque peu fixée" d'une "entité" ou "chose" elle-même définie dans une autre spécification.

A l'avantage d'être générique, ce qui est très souhaitable pour ce schéma des "lieux".

"Place" ne correspond pas à la notion de bâtiment (qui elle porte par exemple la notion d'adresse, correspondant à l'entrée sur la voie publique). Dans ce modèle, un "endroit" peut ainsi contenir (ou être contenu dans) un autre "endroit".

Point d'intérêt (PoI, pour Point of Interest)

Notion de cartographie popularisée par les GPS puis par les applications comme Google Maps. Correspondance assez forte avec la notion de "Place" dans schema.org ; ce n'est pas un hasard puisque les spécifications schema.org ont été écrites pour un usage par les moteurs de recherche et en particulier par Google. D'où une modélisation d'ailleurs assez "business-centric".

La correspondance dans OSM est plus floue. N'importe quel élément de base tel qu'un noeud (point) peut porter des attributs et ce sont eux qui vont faire de cet élément un point d'intérêt spécifique (amenity=restaurant pour un PoI restaurant, etc.). Les attributs sont des "tags" et il n'y a pas de spécification gravée dans le marbre. La communauté et les usages en décident (et ceux-ci peuvent varier dans le temps, par pays, etc.). Mais dans OSM les PoIs ne sont pas forcément des points puisqu'une surface, comme un bâti, peut aussi porter des attributs et donc apparaître comme un PoI sur la carte vue par l'utilisateur.

Dernier détail à savoir : les éléments qu'on peut apparenter à des PoIs dans OSM (noeuds, surfaces...) n'ont pas d'identifiant pérenne ce qui ne permet pas de les référencer à l'extérieur.

cedricr commented 2 years ago

A mon sens il n'y a pas de "modularité" des schémas, avec par exemple des schémas lieux et services qui seraient imbriqués pour qu'un seul et même producteur les utilise dans un processus unifié.

Il faut considérer la production des données des lieux et des données des services comme des processus distincts, correspondant à des métiers ou des politiques publiques distincts, menés par des organisations distinctes.

@johanricher à mon avis, ce sont deux usages distincts, mais tous les deux interessants. 1) Il y a certains 'lieux' qui ne finiront sans doute jamais dans une base nationale (une salle de classe prêtée pour un événement par exemple) 2) Pour certains petits producteurs de données, il restera sans doute plus pratique de travailler sur un seul tableau (surtout s'il y a un lien 1-1 entre le lieu et le service plutot que 1-N)

@cedricr pour être plus explicite, il semble que l'interface la plus utilisée pour publier des jeux de données soit toujours le bon vieux tableur. Je ne sais pas si Open Data France (@johanricher ) a des informations à ce sujet, en tout cas la modularisation des schémas aurait des conséquences sur les interfaces de saisies ?

@bouviermullerp Au moins tant qu'on parle de 1-1, j'imaginerais bien une jeu de donnée qui réponde à plusieurs schema: par ex. les tiers lieux pourraient être validés à la fois par le schema "lieu" et par le schema "service tiers lieu". Il est possible que ça ne demande que des adaptations minimales de tooling: les colonnes du lieu seront ignorées par le schema tiers lieu et vice versa.

cedricr commented 2 years ago

Dernier détail à savoir : les éléments qu'on peut apparenter à des PoIs dans OSM (noeuds, surfaces...) n'ont pas d'identifiant pérenne ce qui ne permet pas de les référencer à l'extérieur.

Oui l'identifiant unique va être un des gros problèmes à résoudre. Quelques pistes de reflexion:

https://www.teamopendata.org/t/identifiant-unique-batiment/2899/29 https://github.com/etalab/schema.data.gouv.fr/issues/135 Ou partir sur du geoadressing?

ThomasG77 commented 2 years ago

Pour les ERP, je m'étais arrêté aux travaux de l'IGN sur lesquels je n'avais pas vraiment vu de suite. J'avais vu un prototype local jamais passé à l'échelle mais sans avoir les raisons profondes de l'absence d'avancement (moyens humains, financiers, temps, difficulté à récupérer les données des acteurs détenant la donnée,... parmi mes hypothèses sans réponse) https://geoservices.ign.fr/sites/default/files/2021-07/Note%20sur%20la%20cr%C3%A9ation%20d%27une%20couche%20ERP%20dans%20la%20BD%20TOPO%C2%AE.pdf

Pour les équipements collectifs, j'ai tendance à les assimiler à la "Base permanente des équipements / BPE" de l'INSEE https://www.insee.fr/fr/metadonnees/source/serie/s1161 mais qui exclue déjà de nombreux lieux par rapport à la discussion sur les "Schéma des lieux proposant des services" du fait que ces équipements ne prennent pas en compte les initiatives privées, sauf erreur.

bouviermullerp commented 2 years ago

Un grand + pour tous les éléments techniques et sémantiques. La notion de POI est importante je crois, c'est elle qui est utilisée dans http://schema.data.gouv.fr/datatourisme/ontology/ si je ne m'avuse.

A mon sens il n'y a pas de "modularité" des schémas, avec par exemple des schémas lieux et services qui seraient imbriqués pour qu'un seul et même producteur les utilise dans un processus unifié.

Il faut considérer la production des données des lieux et des données des services comme des processus distincts, correspondant à des métiers ou des politiques publiques distincts, menés par des organisations distinctes.

Je pense qu'on est d'accord sur le fond, et que c'est peut être ce qu'on met derrière "modularité" qui est différent. Si je pense à modulaire, c'est que pour décrire un tiers lieux (par exemple), on devrait sans doute faire appel à plusieurs schémas, celui des lieux, de l'accessibilité, des services, des équipements, etc.. on pioche dans les schémas en fonction des besoins pour décrire ce qui se passe.

Deux questions :

bouviermullerp commented 2 years ago

Une discussion intéressanté liée : https://teamopendata.org/t/identifiant-unique-batiment/2899/20

cedricr commented 2 years ago

L'API du marché de l'inclusion, récemment publiée, liste elle aussi des 'lieux proposant des services' https://api.gouv.fr/les-api/api-structures-inclusion

cedricr commented 2 years ago

Pour essayer d'avancer, est-ce qu'on pourrait essayer de décomposer le problème? À l'intérieur du futur schema, je vois plusieurs sous-groupes de données:

A. l'identification unique Identifiant purement aléatoire (mais comment réconcilier entre plusieurs producteurs), identifiant basé sur le SIRET + chaine aléatoire, ou choisie par le producteur, géoadressing (type what3words), etc. C'est sans doute le groupe le plus compliqué à spécifier.

B. l'identification "lisible" Un simple nom, ou raison sociale + enseigne Une description (ou description courte/description longue)

C. la classification Typologie d'établissement? Regroupement de sous-établissements/antennes défini librement par l'établissement?

D. l'adressage / la localisation géographique Les possibilités vont du plus simple (un seul champ texte libre) au plus complexe (voir la décomposition de la base SIRENE: num voie/indice répétition/type voie/libellé voie/code postal/commune/libellé commune/distribution spéciale/code commune/code cedex/libelé cedex/code pays/libellé pays/complément adresse). Il faudra trouver le bon compromis entre la facilité de saisie et la précision du géocodage Lat/long pour les coordonnées géo; compliqué à saisir (car en général non connus), d'où le géocodage

E. les horaires Format OSM?

F. les informations de contact Nom/email/téléphone/URL? Multiples?

G. les metadonnées Statut historique (ouvert, fermé?) Date de création/modification de la donnée Qui a recensé, mis à jour la donnée?

cedricr commented 2 years ago

Très pertinent: https://numerique-en-communs.fr/exploration-donnees-territoires/

L’exploration Données et Territoires de NEC 2021 visait à comprendre cette situation et à identifier les conditions de succès d’un standard des données de l’offre de médiation numérique en France.

Merci @bouviermullerp !

bouviermullerp commented 2 years ago

@cedricr je connais vraiment trop mal le sujet, mais j'aurai tendance à ne pas associer F/ et oui pour tous les autres, F/ étant soumis à beaucoup d'interprérations (bailleur/locataire/etc.)

Je notifie AntoineBreitwiller sur le forum Open Data.

@vinber @cquest auriez vous des avis ?

cedricr commented 2 years ago

@cedricr je connais vraiment trop mal le sujet, mais j'aurai tendance à ne pas associer F/ et oui pour tous les autres, F/ étant soumis à beaucoup d'interprérations (bailleur/locataire/etc.)

@bouviermullerp ça me parait être une information fondamentale quand même, non? Est-ce qu'il ne faudrait pas juste rajouter un champ "type de contact"? Idéalement, on pourrait mettre plusieurs contacts, mais ça nous ferait sortir d'une représentation tabulaire…

cedricr commented 2 years ago

Je notifie AntoineBreitwiller sur le forum Open Data.

@bouviermullerp oui c'est une discussion extrêmement intéressante, mais à voir si on aura la même granularité: est-ce que le "batiment" est l'entité pertinente ici?

bouviermullerp commented 2 years ago

@cedricr fondamtentale...ment pas RGPD ? 🔒 😄 (il est tard, en vrai je n'en sais rien, j'ai l'impression qu'on ouvre une boite de pandore !)

cedricr commented 2 years ago

@cedricr fondamtentale...ment pas RGPD ? 🔒 😄 (il est tard, en vrai je n'en sais rien, j'ai l'impression qu'on ouvre une boite de pandore !)

Non c'est clair, ça peut être un problème, mais pas si on met des emails/téléphones "publics" je pense (ceux qui seraient cités sur le site web de la structure)

bouviermullerp commented 2 years ago

@bouviermullerp oui c'est une discussion extrêmement intéressante, mais à voir si on aura la même granularité: est-ce que le "batiment" est l'entité pertinente ici?

Excellente question ! Je vais enquêter sur ce sujet avec le réseau ami des juristes qui doivent avoir un point de vue sur la question. https://twitter.com/Calimaq

cquest commented 2 years ago

On parle de "lieux" donc à la base c'est géographique. Ensuite, dans ces lieux on y trouve des services, qu'on peut décrire.

Pour la partie géo, ça peut se limiter à un lat/lon, donc ponctuel, soit à une emprise surfacique et tout ça peut en plus avoir une hiérarchie que la géo peut rendre implicite:

Cela ne permet pas des liens explicites entre bases, mais ils sont implicites par la géo... avec une marge de flou plus ou moins bien facile à gérer.

A. Identifiants unique...

Le SIRET identifie plus ou moins une activité dans un lieu donné. On a de plus une idée par le code NAF/APE de l'activité en question et par qui elle est assurée (le préfixe SIREN). C'est pas parfait, car tout n'est pas dans SIRENE... surtout les activités non économiques (un bon nombre d'associations manquent).

Le SIRET est quand même loin d'être parfait mais a l'avantage d'être attribué par un seul organisme, l'INSEE. Je pense que les identifiants uniques non signifiants ne fonctionnent que lorsqu'on a ce mode de fonctionnement; enregistrement obligatoire et attribution centralisée de l'id.

B. Les libellés...

Les noms, enseignes... c'est un beau bazar, regardez le nombre de champs que SIRENE prévoit pour ça ! En plus la graphie est souvent variable, abrégés ou pas, etc...

Pour les rapprochements, on se raccroche à ça quand on n'a pas mieux.

C. Classification Type de lieu et/ou d'activité: il y a les classes d'ERP + les codes NAF/APE Le lien hiérarchique entre établissements ça peut être SIREN -> SIRET

D. Adressage / localisation Le champ libre textuel ? on fait pas pire... mais ça vous le savez.

L'adresse est un index le long d'une voie... elle n'identifie par le lieu en lui même mais le moyen d'y accéder. Quand on géocode, on se retrouve avec des lat/lon au bord de la route. Le géocodage du Stade de France sur un lat/long ça limite un peu, non ?

Si on saisit une adresse, il faudrait toujours le faire avec une saisie par autocomplétion pour choisir une adresse existant dans un référentiel, ce qui du coup permet de récupérer une position géo immédiatement et de conserver l'identifiant unique de l'adresse et pas seulement son libellé. L'idéal est en plus de montrer sur une carte, pour éventuellement affiner la position ;) Le géocodage a postériori, c'est un pis-aller... si l'adresse est mal saisie, ça donne des surprises. Un lat/lon devrait toujours être accompagné d'une métadonnée pour indiquer comment il a été obtenu.

Associer le lieu à une géométrie (ponctuelle ou surfacique) est quand même le mieux, mais ça ne peut pas se systématiser, surtout sur des données existantes.

Le lien avec le bâtiment n'est pas forcément pertinent... il va falloir gérer les services proposés dans des lieux qui comportent de multiples bâtiments... par évident du tout.

Je rappelle les multiples relation 0-N qu'on a entre adresses, parcelles et bâtiments...

E. Horaires Si quelqu'un a mieux à proposer que le schéma OSM pour ça, je pense que pas mal de monde sera intéressé. Il y a maintenant pas mal de code qui permet de vérifier, montrer ce que ça donne, etc. Le schéma pour les défibrillateurs a adopté les horaires "à la OSM".

F. Contact schema.org a pas mal de choses pour ça, non ?

G. Métadonnées Oui à tout, et plus on en a mieux on peut faire le tri et avoir une idée de la qualité d'une donnée.

Je pense qu'en l'absence d'identifiant unique et centralisé, ce n'est que par l'accumulation de champs pouvant être rapprochés qu'on arrive à apparier des données. Le but du schéma est-il de produire une base agrégeable ?

Vous avez regardé datatourisme ? ça mélange lieux et services...

cedricr commented 2 years ago

Pour la géométrie, suivre les travaux de @datagistips https://github.com/frictionlessdata/specs/issues/771.

cedricr commented 2 years ago

@cquest

On parle de "lieux" donc à la base c'est géographique. Ensuite, dans ces lieux on y trouve des services, qu'on peut décrire.

Tout à fait! Encore que ces lieux peuvent éventuellement être conceptuels (siège social), et les services être proposés dans d'autres lieux (antennes, maraudes, évenement organisé à l'exterieur, etc.)

Pour la partie géo, ça peut se limiter à un lat/lon, donc ponctuel, soit à une emprise surfacique et tout ça peut en plus avoir une hiérarchie que la géo peut rendre implicite:

  • le stade de France est un grand polygone
  • à l'intérieur de trouvent d'autres lieux, plus petits: vestiaires, tribunes, buvettes, parking, etc.

Cela ne permet pas des liens explicites entre bases, mais ils sont implicites par la géo... avec une marge de flou plus ou moins bien facile à gérer.

Mon opinion est que lat/lon suffisent ici; on n'a pas besoin d'une répresentation précise du lieu. Dans ce schéma, le lieu me semble plus un "aggrégateur de services" qu'une entité géographique interessante en tant que telle. Mais ce n'est que mon opinion, et c'est pour ça qu'on en discute!

A. Identifiants unique...

Le SIRET identifie plus ou moins une activité dans un lieu donné. On a de plus une idée par le code NAF/APE de l'activité en question et par qui elle est assurée (le préfixe SIREN). C'est pas parfait, car tout n'est pas dans SIRENE... surtout les activités non économiques (un bon nombre d'associations manquent).

Le SIRET est quand même loin d'être parfait mais a l'avantage d'être attribué par un seul organisme, l'INSEE. Je pense que les identifiants uniques non signifiants ne fonctionnent que lorsqu'on a ce mode de fonctionnement; enregistrement obligatoire et attribution centralisée de l'id.

Entièrement d'accord avec toi, je partirais aussi sur le siret, avec éventuellement un second code pour les éventuelles subdivisions; dans ce cas il n'y aurait pas d'attribution centralisée, mais ce serait de la responsabilité de la structure.

B. Les libellés...

Les noms, enseignes... c'est un beau bazar, regardez le nombre de champs que SIRENE prévoit pour ça ! En plus la graphie est souvent variable, abrégés ou pas, etc...

Pour les rapprochements, on se raccroche à ça quand on n'a pas mieux.

👍

C. Classification Type de lieu et/ou d'activité: il y a les classes d'ERP + les codes NAF/APE Le lien hiérarchique entre établissements ça peut être SIREN -> SIRET

SIREN -> SIRET oui, mais pour un même SIRET on peut avoir des tonnes de lieux (ex: les antennes de la Croix Rouge)

D. Adressage / localisation Le champ libre textuel ? on fait pas pire... mais ça vous le savez.

L'adresse est un index le long d'une voie... elle n'identifie par le lieu en lui même mais le moyen d'y accéder. Quand on géocode, on se retrouve avec des lat/lon au bord de la route. Le géocodage du Stade de France sur un lat/long ça limite un peu, non ?

Si on saisit une adresse, il faudrait toujours le faire avec une saisie par autocomplétion pour choisir une adresse existant dans un référentiel, ce qui du coup permet de récupérer une position géo immédiatement et de conserver l'identifiant unique de l'adresse et pas seulement son libellé. L'idéal est en plus de montrer sur une carte, pour éventuellement affiner la position ;) Le géocodage a postériori, c'est un pis-aller... si l'adresse est mal saisie, ça donne des surprises. Un lat/lon devrait toujours être accompagné d'une métadonnée pour indiquer comment il a été obtenu.

Associer le lieu à une géométrie (ponctuelle ou surfacique) est quand même le mieux, mais ça ne peut pas se systématiser, surtout sur des données existantes.

Le lien avec le bâtiment n'est pas forcément pertinent... il va falloir gérer les services proposés dans des lieux qui comportent de multiples bâtiments... par évident du tout.

Je rappelle les multiples relation 0-N qu'on a entre adresses, parcelles et bâtiments...

Entièrement d'accord avec tout ça. De notre coté (schéma de l'inclusion) on proposera un formulaire de saisie qui permettra ça au mieux, mais on ne peut pas exclure ceux qui veulent saisir directement des données tabulaires, éventuellement préexistante. Et dans ce cas, il parait difficile de leur demander de renseigner lng/lat, et il faudra alors le géocoder. Et oui, effectivement il faut une absolument des colonnes pour indiquer source et fiabilité de la géo.

E. Horaires Si quelqu'un a mieux à proposer que le schéma OSM pour ça, je pense que pas mal de monde sera intéressé. Il y a maintenant pas mal de code qui permet de vérifier, montrer ce que ça donne, etc. Le schéma pour les défibrillateurs a adopté les horaires "à la OSM".

👍

F. Contact schema.org a pas mal de choses pour ça, non ?

Ça me parait quand même hyper compliqué pour les besoins de ce schema https://schema.org/Person

G. Métadonnées Oui à tout, et plus on en a mieux on peut faire le tri et avoir une idée de la qualité d'une donnée.

Merci infiniment pour tous ces avis precieux!

cedricr commented 2 years ago

Le but du schéma est-il de produire une base agrégeable ?

Oui! Et idéalement de pouvoir synchroniser des mises à jour provenant de sources differentes…

Vous avez regardé datatourisme ? ça mélange lieux et services...

Pas encore, mais merci pour le pointeur…

cedricr commented 2 years ago

Documentation DATAtourisme: https://www.datatourisme.gouv.fr/ontology/core/#PointOfInterest

vinber commented 2 years ago

C. Classification Type de lieu et/ou d'activité: il y a les classes d'ERP + les codes NAF/APE Le lien hiérarchique entre établissements ça peut être SIREN -> SIRET

SIREN -> SIRET oui, mais pour un même SIRET on peut avoir des tonnes de lieux (ex: les antennes de la Croix Rouge)

oui pour la croix rouge, une discussion sur la team opendata sur un identifiant unique généré avec le siret plus un mix lat-long (mais cela semble une fausse binne idée)

si on parle de lieux conceptuels, alors les cas encore plus à la marge n'ayant pas de siret (en particulier les associations n'ayant pas eu besoin de siret, ni salarié ni demande de financement).

cedricr commented 2 years ago

@cquest @johanricher

C'est pas parfait, car tout n'est pas dans SIRENE... surtout les activités non économiques (un bon nombre d'associations manquent).

Est-ce que le RNA les contient bien dans ce cas?

ColinMaudry commented 1 year ago

Merci pour la qualité des échanges, on avance :) Je viens d'arriver sur le sujet, en sidekick de @cedricr 🦹🏻

Je pense qu'ici on veut pouvoir décrire quelque chose de très générique, donc même la notion de bâtiment est trop contraignante (le lieu peut être sur un terrain de sport, un terrain vague, dans une forêt, sur un parking...).

Les coordonnées géographiques sont donc centrales, même si d'autres données peuvent les compléter avantageusement :

Ici l'accent est mis sur "décrire où se trouve un lieu et comment y accéder". Voyez-vous d'autres objectifs pour ce schéma ?

johanricher commented 1 year ago

Merci Colin de relancer ce sujet qui n'a aucunement perdu de son importance.

Oui l'objectif est de ne pas créer un n-ième "standard" mais de permettre de publier des données qui s'appuient sur les standards existants.

Donc un schéma le plus générique possible (à l'échelle de la France), mais qui pourra servir de hub vers d'autres données (par exemple identifiant BatID pour un bâtiment, identifiant BAN de l'adresse, identifiant acceslibre*, etc.).

En essayant de réduire au minimum son périmètre, dès que d'autres schémas, données ou services traitent déjà le sujet. Par exemple :

* voir aussi https://github.com/MTES-MCT/acceslibre/issues/277

ColinMaudry commented 1 year ago

Oui, je n'étais pas au courant de l'initiative sur les schémas de parking à vélo :) Si ce schéma supporte les stationnements privés (accessible uniquement aux usagers d'un lieu), alors ça marche !