Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

InitialInput and/or PlaceRef in LocationInformationRequest #16

Open
ue71603 opened this issue Aug 19, 2021 · 8 comments
Open

InitialInput and/or PlaceRef in LocationInformationRequest #16

ue71603 opened this issue Aug 19, 2021 · 8 comments
Assignees
Labels

Comments

@ue71603
Copy link

ue71603 commented Aug 19, 2021

VAO uses primeraly "InitialInput" for the search by location name.
SBB has also test cases that use a PlaceRef and only a LocationName in it. This throws an error in the VAO passive system.

What do you think? Is this something to be supported?

Version that works on the VAO system:
<?xml version="1.0" encoding="UTF-8"?> <OJP xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.siri.org.uk/siri" version="1.0" xmlns:ojp="http://www.vdv.de/ojp" xsi:schemaLocation="http://www.siri.org.uk/siri ../ojp-xsd-v1.0/OJP.xsd"> <OJPRequest> <ServiceRequest> <RequestTimestamp>2021-07-13T12:00:00+02:00</RequestTimestamp> <RequestorRef>VAO</RequestorRef> <ojp:OJPLocationInformationRequest> <RequestTimestamp>2021-07-13T12:00:00+02:00</RequestTimestamp> <MessageIdentifier>123</MessageIdentifier> <ojp:InitialInput> <ojp:LocationName>Domodossola</ojp:LocationName> </ojp:InitialInput> <ojp:Restrictions> <ojp:Type>stop</ojp:Type> </ojp:Restrictions> </ojp:OJPLocationInformationRequest> </ServiceRequest> </OJPRequest> </OJP>

Version that does not work:
<?xml version="1.0" encoding="UTF-8"?> <OJP xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.siri.org.uk/siri" version="1.0" xmlns:ojp="http://www.vdv.de/ojp" xsi:schemaLocation="http://www.siri.org.uk/siri ../ojp-xsd-v1.0/OJP.xsd"> <OJPRequest> <ServiceRequest> <RequestTimestamp>2020-01-19T12:00:00Z</RequestTimestamp> <RequestorRef>IRMA</RequestorRef> <ojp:OJPLocationInformationRequest> <RequestTimestamp>2020-01-19T12:00:00Z</RequestTimestamp> <MessageIdentifier>4711</MessageIdentifier> <ojp:PlaceRef> <ojp:LocationName> <ojp:Text>Domodossola</ojp:Text> </ojp:LocationName> </ojp:PlaceRef> <ojp:Restrictions> <ojp:Type>stop</ojp:Type> <ojp:IncludePtModes>true</ojp:IncludePtModes> </ojp:Restrictions> </ojp:OJPLocationInformationRequest> </ServiceRequest> </OJPRequest> </OJP>

@grunerjan
Copy link

The way I read the Word and Excel file I'd say both methods are supposed work. LocationName is supported for InitialInput and PlaceRef. However the PlaceRefStructure requires the use of StopRef, StopPlaceRef or similiar (choices a - f) as indicated with -1:1 (see also OJP CEN document table 8.4.5.11). This is not directly stated in the word document but is in the excel. This may be the reason why the 2nd exmaple does not work as no "choice" is given.

@ue71603
Copy link
Author

ue71603 commented Aug 23, 2021

@grunerjan This may cause a problem. Because under which circumstance the content of the LocationName has any influence, when one of the REF is given? Or is it always ignored.

@grunerjan
Copy link

Well, for the PlaceRefStructure one of the "choices a-f" must be used as well as LocationName. The way I understand it, is that LocationName in both cases (InitialInput and PlaceRef) acts as a (name-)filter, however for PlaceRef you get additional filter options in order to narrow down the results (besides the optional Restrictions element). This is not possible with that level of detail InitialInput.
One could argue however that InitialInput + Restrictions might get you the same result.

@ue71603
Copy link
Author

ue71603 commented Aug 24, 2021

I agree on using InitialInput. We will try. I have to disagree about the filtering in PlaceRef with LocationName. The LocationName ist mandatory. For coordinates it makes not sense and we will it with a nonsense content. If it acts as a filter, it throws things out. and what would be the LocationName of a randomly selected point anyhow.

@ue71603
Copy link
Author

ue71603 commented Aug 25, 2021

After discussion with In PlaceRef we see the LocationName as the "Label" in searching for coordinates the user wants to be in the result. it is not a filter. For all other cases LocationName will be ignored.

@BettinaNeuhaeuser
Copy link

Form my previous tests I can say that we support

  • InitialInput with Restrictions Type (Stop/Address/POIs)
  • InitialInput with Restrictions IncludePtModes
  • InitialInput with Restrictions NumberOfResults

InitialInput with PlaceRef provides a Response, but not the correct one.
We will analyse it:

2021-07-13T12:00:00+02:00 VAO 2021-07-13T12:00:00+02:00 123 490132000 Stephansplatz stop

Response:

<ns4:OJP version="1.0" xmlns="http://datex2.eu/schema/2_0RC1/2_0" xmlns:ns5="http://www.vdv.de/ojp" xmlns:ns2="http://www.ifopt.org.uk/acsb" xmlns:ns4="http://www.siri.org.uk/siri" xmlns:ns3="http://www.ifopt.org.uk/ifopt">
ns4:OJPResponse
ns4:ServiceDelivery
ns4:ResponseTimestamp2021-09-03T14:31:48+02:00</ns4:ResponseTimestamp>
ns4:ProducerRefVAO_LinkingAlps_HCN_OJP_PSA.PUB.0.0.1-SNAPSHOT</ns4:ProducerRef>
ns4:RequestMessageRef9ccdf94a-2214-4062-8a99-04de58df79c3</ns4:RequestMessageRef>
ns5:OJPLocationInformationDelivery
ns4:ResponseTimestamp2021-09-03T14:31:48+02:00</ns4:ResponseTimestamp>
ns5:Location
ns5:Location
ns5:StopPlace
ns5:StopPlaceRef108800401</ns5:StopPlaceRef>
ns5:StopPlaceName
ns5:TextBruxelles Midi</ns5:Text>
</ns5:StopPlaceName>
</ns5:StopPlace>
ns5:LocationName
ns5:TextBruxelles Midi</ns5:Text>
</ns5:LocationName>
ns5:GeoPosition
ns4:Longitude4.335749</ns4:Longitude>
ns4:Latitude50.835348</ns4:Latitude>
</ns5:GeoPosition>
</ns5:Location>
ns5:Completetrue</ns5:Complete>
</ns5:Location>
</ns5:OJPLocationInformationDelivery>
</ns4:ServiceDelivery>
</ns4:OJPResponse>
</ns4:OJP>

@BettinaNeuhaeuser
Copy link

Just for claification of the Purpose of PlaceRef (please confirm)
The use case of PlaceRef we defined is:
Location for further refinement. If a location in a previous response was marked as not "complete" it can be refined by putting it here.

Expected Result:
an uncomplete location can be refined with the information given

Example Request:

2021-07-13T12:00:00+02:00 VAO 2021-07-13T12:00:00+02:00 123 {{PlaceRef}} {{PlaceName}} stop

@ue71603
Copy link
Author

ue71603 commented Sep 6, 2021

Hi Bettina
Something with the Example request is wrong. And I am not sure, what should be the results.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants