Page 1 sur 1

WFS Stations VCUB données incohérentes sur identifiants ?

Posté : 27 juin 2017, 21:44
par jazzydag
Bonsoir à l'équipe et déjà merci de rendre disponible toutes ces données !

Je travaille un peu avec les données de stations de VCUB, statiques & temps réel. J'ai dans un premier temps récupérer le shapefile de la couche TB_STVEL_P pour avoir toutes les metadata + les points géométriques des stations. C'est ensuite assez trivial de pousser ça dans un QGIS ou dans un PostgreSQL/PostGIS.

Ensuite, je récupère les données temps réel via le service WFS et la couche CI_VCUB_P. Je me débrouille aussi pour mettre certaines données dans ma base. En faisant une jointure sur le champs "ident" pour bien vérifier que j'avais la plupart du temps "nbplaces + nbvelos = nbsupport", je me suis rendu compte l'attribut "ident" n'était pas pareil pour CI_VCUB_P et TB_STVEL_P.

En regardant quelques lignes, je me suis aperçu que c'était le champs "numstat" de TB_STVEL_P qui correspondait au champs "ident" de CI_VCUB_P.
Est-ce une incohérence dans les données ?

À titre d'exemple :

Code : Tout sélectionner

http https://data.bordeaux-metropole.fr/wfs?service=wfs&request=GetFeature&version=2.0.0&key=[TOKEN]&typename=TB_STVEL_P

Code : Tout sélectionner

http https://data.bordeaux-metropole.fr/wfs?service=wfs&request=GetFeature&version=2.0.0&key=[TOKEN]&typename=CI_VCUB_P
En regardant une station arbitraire, pour la station "bassin à flot", j'ai

Code : Tout sélectionner

        <bm:GID>44</bm:GID>
        <bm:NUMSTAT>98</bm:NUMSTAT>
        <bm:IDENT>102</bm:IDENT>
        <bm:ADRESSE>83 quai de Bacalan</bm:ADRESSE>
        <bm:COMMUNE>BORDEAUX</bm:COMMUNE>
        <bm:DATESERV/>
        <bm:LIGNCORR>B/Corol 32</bm:LIGNCORR>
        <bm:NBSUPPOR>18</bm:NBSUPPOR>
        <bm:NOM>Bassins à flot</bm:NOM>
        <bm:TARIF>VLS</bm:TARIF>
        <bm:TERMBANC>OUI</bm:TERMBANC>
        <bm:TYPEA>VCUB</bm:TYPEA>
avec ident=102 et numstat=98.

Code : Tout sélectionner

        <bm:GID>75</bm:GID>
        <bm:IDENT>98</bm:IDENT>
        <bm:TYPE>VLS</bm:TYPE>
        <bm:NOM>Bassins a flot</bm:NOM>
        <bm:ETAT>CONNECTEE</bm:ETAT>
        <bm:NBPLACES>11</bm:NBPLACES>
        <bm:NBVELOS>7</bm:NBVELOS>
        <bm:HEURE>2017-06-26 17:31:03</bm:HEURE>
avec ident=98.

Je fais maintenant ma jointure avec X.ident=Y.numstat mais voulais savoir si c'était (1) connu et (2) voulu. Peut-être que les identifiants n'ont pas le même sens dans les 2 couches.

Merci à vous,
Damien G.

Re: WFS Stations VCUB données incohérentes sur identifiants

Posté : 28 juin 2017, 08:31
par Sébastien Cart-Lamy
Bonjour,
L'identifiant n'est pas fait pour faire des jointures. Les seules jointures fiables utilisent le GID.

Vous avez sur le dictionnaire le modèle de données complet montrant le modèle : La réponse à vos interrogation est que ces deux couches viennent de deux sources différentes, c'est pour ça qu'il est difficile de les merger.

Il semblerait quand même que l'appairage NUMSTAT et IDENT fonctionne, mais je ne peux pas vous garantir qu'il fonctionnera toujours, car les deux couches ont une signification différente :
  • TB_STVEL_P - Stations issues du réseau théorique TBM (donc il peut y avoir des stations qui ne sont pas encore actives)
  • CI_VCUB_P - Stations en ligne issues du système temps réel

Re: WFS Stations VCUB données incohérentes sur identifiants

Posté : 28 juin 2017, 09:00
par jazzydag
Super. Merci pour l'info. Je ne connaissais pas le lien vers "dicopub", très utile en effet.

Et pour les GID, même soucis je pense, puisque dans l'exemple précédent, j'ai GID=44 d'un côté et GID=75 de l'autre.
Et malgré l'origine des données différentes, la génération d'un identifiant unique par station et cohérente n'aurait pas été du luxe de la part du fournisseur, que ce soit pour les stations déjà en ligne ou en devenir.

Merci pour toutes ces infos !

Re: WFS Stations VCUB données incohérentes sur identifiants

Posté : 28 juin 2017, 09:09
par Sébastien Cart-Lamy
Non, ce n'est pas sur GID = GID qu'il faut faire les jointures.
C'est que GID = clé primaire (pk) sur toutes les couches. Quand il y a une jointure, la couche référençante a une clé étrangère (fk) qui référence la clé primaire (toujours un GID) d'une autre couche.

Exemple : le champ RS_FV_VOIE dans la table FV_NUMVO_P référence le GID de la table FV_VOIE_A
Le "Schéma des relations" montre bien cela : http://data.bordeaux-metropole.fr/dicop ... FV_NUMVO_P


Dans votre cas, il n'y a aucune relation entre les deux couches.