search

pgrimaud / horaires-ratp-api

Webservice pour les horaires et trafic RATP en temps réel
https://api-ratp.pierre-grimaud.fr/v4
MIT License
269 stars 30 forks source link

RER C = Ambiguous Line #44

Closed sign0 closed 7 years ago

sign0 commented 7 years ago

Bonjour,

Tout d'abord, un énorme merci pour votre travail, car le SOAP....... ;-)

Malheureusement, je n'arrive pas à request le RER C, la réponse m'indique "Ambiguous Line" : https://api-ratp.pierre-grimaud.fr/v3/destinations/rers/C

Quelqu'un sait-il comment je peux contourner cette erreur ?

++ Adrien

kalon33 commented 7 years ago

Je pense que c'est simplement lié au fait que le RER C n'est pas une ligne RATP, mais SNCF, et que par conséquent il n'existe pas dans l'API... Je peux me tromper, mais à mon avis c'est déjà un premier point...

----- Mail original -----

De: "Signo" notifications@github.com À: "pgrimaud/horaires-ratp-api" horaires-ratp-api@noreply.github.com Cc: "Subscribed" subscribed@noreply.github.com Envoyé: Mercredi 15 Mars 2017 15:44:13 Objet: [pgrimaud/horaires-ratp-api] RER C = Ambiguous Line (#44)

Bonjour,

Tout d'abord, un énorme merci pour votre travail, car le SOAP....... ;-)

Malheureusement, je n'arrive pas à request le RER C, la réponse m'indique "Ambiguous Line" : https://api-ratp.pierre-grimaud.fr/v3/destinations/rers/C

Quelqu'un sait-il comment je peux contourner cette erreur ?

++ Adrien

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub , or mute the thread .

sign0 commented 7 years ago

Pourtant, cette requête https://api-ratp.pierre-grimaud.fr/v3/lines/rers/C renvoie bien le résultat suivant : 

{
  result: {
    code: "C",
    name: "RER C",
    directions: "Saint Martin d'Etampes / Saint Quentin en Yvelines"
  },
  _metadata: {
    call: "GET /lines/rers/C",
    date: "2017-03-15T15:58:22+01:00",
    version: 3
  }
}

Cette ligne semble donc être quand même bien présente dans l'API. En revanche, il me semble que la line RERC est plutôt complexe (plusieurs routes au sein de la ligne), d'où peut-être le "ambiguous line"...

kalon33 commented 7 years ago

Effectivement, je me trompe peut-être alors... Par contre oui, il y a à ma connaissance au moins 4 routes différentes (sans compter les missions qui n'en desservent qu'une partie).

----- Mail original -----

De: "Signo" notifications@github.com À: "pgrimaud/horaires-ratp-api" horaires-ratp-api@noreply.github.com Cc: "Nicolas Derive" kalon33@ubuntu.com, "Comment" comment@noreply.github.com Envoyé: Mercredi 15 Mars 2017 16:05:09 Objet: Re: [pgrimaud/horaires-ratp-api] RER C = Ambiguous Line (#44)

Pourtant, cette requête https://api-ratp.pierre-grimaud.fr/v3/lines/rers/C renvoie bien le résultat suivant :

{ result: { code: "C", name: "RER C", directions: "Saint Martin d'Etampes / Saint Quentin en Yvelines" }, _metadata: { call: "GET /lines/rers/C", date: "2017-03-15T15:58:22+01:00", version: 3 } }

Cette ligne semble donc être quand même bien présente dans l'API. En revanche, il me semble que la line RERC est plutôt complexe (plusieurs routes au sein de la ligne), d'où peut-être le "ambiguous line"...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .

djavan-bertrand commented 7 years ago

Même comportement pour la ligne D. Je pense que cela est dû au fait que la liste des lignes de rers retourne plusieurs lignes avec le même code: 

{
    "result": {
        "rers": [
            {
                "code": "A",
                "name": "RER A",
                "directions": "Marne la Vallee-Boissy Saint Leger / Cergy-Poissy-Saint Germain en Laye"
            },
            {
                "code": "B",
                "name": "RER B",
                "directions": "Robinson-Saint Remy les Chevreuse / Aeroport Ch.De Gaulle 2-Mitry Claye"
            },
            {
                "code": "C",
                "name": "RER C",
                "directions": "Saint Martin d'Etampes / Saint Quentin en Yvelines"
            },
            {
                "code": "C",
                "name": "RER C",
                "directions": "Dourdan / Saint Quentin en Yvelines"
            },
            {
                "code": "C",
                "name": "RER C",
                "directions": "Dourdan-Massy Palaiseau / Pontoise"
            },
            {
                "code": "C",
                "name": "RER C",
                "directions": "Massy Palaiseau / Champ de Mars Tour Eiffel"
            },
            {
                "code": "C",
                "name": "RER C",
                "directions": "Bretigny Sur Orge / Versailles Chateau-Rive Gauche"
            },
            [...]
            {
                "code": "D",
                "name": "RER D",
                "directions": "Melun / Orry la Ville-Creil"
            },
            {
                "code": "D",
                "name": "RER D",
                "directions": "Malesherbes / Orry la Ville-Creil"
            },
            [...]
    }
}
pgrimaud commented 7 years ago

Hello all,

En effet, c'est à cause des différentes routes sur ces lignes.

Je vais regarder dans la soirée pour pouvoir passer le code Stif comme paramètre en complément du code de la ligne. Je pense que cela permettra d'affiner la recherche et d'éviter l'erreur "Ambiguous Line".

J'ai échangé quelques mails avec l'équipe RATP Open Data, et ils m'ont conseillé de me baser sur ce codeStif. Malheureusement, ces codes STIF ne sont pas parlant du tout (eg. 1212090192 ou 1021092109) et j'ai préféré opter pour les codes traditionnels (RERA, METRO1, etc...)

Comme on peut voir dans leur WSDL :

<xs:complexType name="Line">
    <xs:sequence>
        <xs:element minOccurs="0" name="code" nillable="true" type="xs:string"/>
        <xs:element minOccurs="0" name="codeStif" nillable="true" type="xs:string"/>
        <xs:element minOccurs="0" name="id" nillable="true" type="xs:string"/>
        <xs:element minOccurs="0" name="image" nillable="true" type="xs:string"/>
        <xs:element minOccurs="0" name="name" nillable="true" type="xs:string"/>
        <xs:element minOccurs="0" name="realm" nillable="true" type="xs:string"/>
        <xs:element minOccurs="0" name="reseau" nillable="true" type="ax21:Reseau"/>
    </xs:sequence>
</xs:complexType>

https://github.com/pgrimaud/horaires-ratp-sdk/blob/master/data/ratp.wsdl#L21

J'imagine donc une route qui devrait faire le boulot : 

https://api-ratp.pierre-grimaud.fr/v3/destinations/{type}/{code}/{codeStif}

{type} : required
{code} : required
{codeStif} : optional

ex : https://api-ratp.pierre-grimaud.fr/v3/destinations/rers/c/xxxxxxx
sign0 commented 7 years ago

Merci Pierre pour ta réponse ! 👍

Personnelement, le codeStif m'arrange pas mal (j'essaie de mapper le dataset de navitia avec le realtime RATP).

Hate d'être ce soir pour tester tout ça ! :)

kalon33 commented 7 years ago

@Signo, du coup pourquoi pas utiliser directement le realtime STIF pour le mapper avec le dataset de Navitia?

----- Mail original -----

De: "Signo" notifications@github.com À: "pgrimaud/horaires-ratp-api" horaires-ratp-api@noreply.github.com Cc: "Nicolas Derive" kalon33@ubuntu.com, "Comment" comment@noreply.github.com Envoyé: Mercredi 15 Mars 2017 17:01:36 Objet: Re: [pgrimaud/horaires-ratp-api] RER C = Ambiguous Line (#44)

Merci Pierre pour ta réponse ! 👍

Personnelement, le codeStif m'arrange pas mal (j'essaie de mapper le dataset de navitia avec le realtime RATP).

Hate d'être ce soir pour tester tout ça ! :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .

sign0 commented 7 years ago

Tu parles de cette API ? https://api-lab-trall-stif.opendata.stif.info/service/tr-globale-stif/estimated-timetable

J'ai essayé, mais les ids ne sont pas formaté de la même manière... :-( Par exemple, les stop_points du STIF sont dans ce genre de format là : STIF:StopPoint:Q:22101: alors que chez Navitia : stop_point:OIF:SP:10:10.

kalon33 commented 7 years ago

En gros, il te faudrait une table de matching genre https://opendata.stif.info/explore/dataset/perimetre-tr-plateforme-stif/table/

avec le " StopPoint:40:533" (gtfs_stop_id) qui correspondrait à un "stop_point:OIF:SP:40:533" chez Navitia? (le reflex_zde_id est l'identifiant que tu trouves dans stopPointRef après "STIF:StopPoint:Q:" dans leur flux SIRI lite) y'a une table similaire pour les route_id aussi.

C'est un peu prise de tête, mais j'ai pu commencer à m'en sortir comme ça de mon côté... Le problème que j'ai rencontré, c'est que pour le moment uniquement une partie des arrêts sont couverts par cette table, correspondant à la partie des arrêts couverte en données temps réel...

J'espère que j'ai pas été trop confus dans ma réponse !

----- Mail original -----

De: "Signo" notifications@github.com À: "pgrimaud/horaires-ratp-api" horaires-ratp-api@noreply.github.com Cc: "Nicolas Derive" kalon33@ubuntu.com, "Comment" comment@noreply.github.com Envoyé: Mercredi 15 Mars 2017 17:35:26 Objet: Re: [pgrimaud/horaires-ratp-api] RER C = Ambiguous Line (#44)

Tu parles de cette API ? https://api-lab-trall-stif.opendata.stif.info/service/tr-globale-stif/estimated-timetable

J'ai essayé, mais les ids ne sont pas formaté de la même manière... :-( Par exemple, les stop_points du STIF sont dans ce genre de format là : STIF:StopPoint:Q:22101: alors que chez Navitia : stop_point:OIF:SP:10:10

— You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .

sign0 commented 7 years ago

@kalon33 Amazing !! Ça fait plusieurs jours que je tourne en rond là dessus, je test ça ce soir ! :)

Par contre, je comprend pas trop quand tu dis que "uniquement une partie des arrêts sont couverts par cette table, correspondant à la partie des arrêts couverte en données temps réel".

En gros, X% des stop_id de cette table match avec 100% du flux realtime STIF, mais il y à Y% de cette table qui ne match pas (mais on s'en fout vu que c'est pas en realtime) si je ne comprend bien ?

kalon33 commented 7 years ago

@signo Voilà, cette table ne couvre qu'une partie de l'ensemble des arrêts du réseau (qui ont des infos théoriques). Après, je n'ai pas vérifié si elle permettait de matcher 100% du flux temps réel ou pas.

A vérifier aussi, qu'il n'y ait pas de doublons. Le STIF propose aussi une autre table de correspondance de l'ensemble des arrêts du réseau, mais l'ayant utilisé et ayant rencontré des doublons (un seul ZDE pour plusieurs stop_id, qui m'ont empêché d'aller plus loin), c'est pour ça que je te conseille celle-ci. D'ailleurs, n'hésite pas à me faire ton retour si tu vois que y'a pas de doublons et que ça matche 100% du flux temps réel, ça m'intéresse !

----- Mail original -----

De: "Signo" notifications@github.com À: "pgrimaud/horaires-ratp-api" horaires-ratp-api@noreply.github.com Cc: "Nicolas Derive" kalon33@ubuntu.com, "Mention" mention@noreply.github.com Envoyé: Mercredi 15 Mars 2017 19:02:35 Objet: Re: [pgrimaud/horaires-ratp-api] RER C = Ambiguous Line (#44)

@kalon33 Amazing !! Ça fait plusieurs jours que je tourne en rond là dessus, je test ça ce soir ! :)

Par contre, je comprend pas trop quand tu dis que "uniquement une partie des arrêts sont couverts par cette table, correspondant à la partie des arrêts couverte en données temps réel ".

En gros, X% des stop_id de cette table match avec 100% du flux realtime STIF, mais il y à Y% de cette table qui ne match pas (mais on s'en fout vu que c'est pas en realtime) si je ne comprend bien ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .

pgrimaud commented 7 years ago

Bonsoir, j'ai fait quelques modifications.

Pour commencer, il n'y a PAS de code Stif pour le RER C et le RER D. ¯\(ツ)/¯ Du coup il est maintenant possible de récupérer l'id interne RATP de chaque ligne.

https://api-ratp.pierre-grimaud.fr/v3/lines/rers

{
    "result": {
        "rers": [
            ...
            {
                "code": "C",
                "name": "RER C",
                "directions": "Saint Martin d'Etampes / Saint Quentin en Yvelines",
                "id": "1028"
            },
            {
                "code": "C",
                "name": "RER C",
                "directions": "Dourdan / Saint Quentin en Yvelines",
                "id": "1029"
            },
            {
                "code": "C",
                "name": "RER C",
                "directions": "Dourdan-Massy Palaiseau / Pontoise",
                "id": "1030"
            },
            {
                "code": "C",
                "name": "RER C",
                "directions": "Massy Palaiseau / Champ de Mars Tour Eiffel",
                "id": "1031"
            },
            {
                "code": "C",
                "name": "RER C",
                "directions": "Bretigny Sur Orge / Versailles Chateau-Rive Gauche",
                "id": "1032"
            },
            {
                "code": "C",
                "name": "RER C",
                "directions": "Versailles Chantiers / Versailles Chateau-Rive Gauche",
                "id": "1033"
            },
            {
                "code": "C",
                "name": "RER C",
                "directions": "Montigny Beauchamp / Dourdan la Foret",
                "id": "70960"
            },
            {
                "code": "C",
                "name": "RER C",
                "directions": "Montigny Beauchamp / Saint-Martin-D'Etampes",
                "id": "80928"
            },
            {
                "code": "C",
                "name": "RER C",
                "directions": "Gare de Juvisy / Gare d'Austerlitz",
                "id": "81323"
            },
            {
                "code": "C",
                "name": "RER C",
                "directions": "Gare de Versailles Chantiers / Gare de Juvisy",
                "id": "355743"
            }
            ...
        ]
    },
    "_metadata": {
        "call": "GET /lines/rers",
        "date": "2017-03-15T23:34:01+01:00",
        "version": 3
    }
}

Pour affiner vos recherches sur les RER C, RER D (et autres lignes à multiples destinations), il faut filtrer avec la valeur "id".

Quelque exemples qui semblent fonctionner :

https://api-ratp.pierre-grimaud.fr/v3/destinations/rers/c?id=1029 https://api-ratp.pierre-grimaud.fr/v3/stations/rers/c?id=1029 https://api-ratp.pierre-grimaud.fr/v3/schedules/rers/c/saint+cyr/A?id=1029