LIR request with both filters "stops" and "address" only gives stops back

[terencebls]

If we make a LIR request with both restriction filters for "stops" and "address", we get only stops.

Request example:

<OJP xmlns:siri="http://www.siri.org.uk/siri" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.vdv.de/ojp" version="2.0"> <OJPRequest> <siri:ServiceRequest> <siri:RequestTimestamp>2024-05-07T14:50:21Z</siri:RequestTimestamp> <siri:RequestorRef>OJP_Demo_iOS_IOS_SDK_0.0.1</siri:RequestorRef> <OJPLocationInformationRequest> <siri:RequestTimestamp>2024-05-07T14:50:21Z</siri:RequestTimestamp> <InitialInput> <Name>Bern Schul</Name> </InitialInput> <Restrictions> <Type>stop</Type> <Type>address</Type> <NumberOfResults>10</NumberOfResults> <IncludePtModes>true</IncludePtModes> </Restrictions> </OJPLocationInformationRequest> </siri:ServiceRequest> </OJPRequest> </OJP>

It should actually also give back addresses and not only stops.

[TO-mdv]

das Problem ist folgende Regel in der Konfiguration des EFALocationServers:

Diese sagt, dass falls Haltestellen gefunden werden keine weiteren Treffer ausgegeben werden sollen.
Um das von der BLS gewünschte Verhalten zu bekommen, müssen wir die Konfiguration anpassen.

[TO-mdv]

We need to change the behaviour of the Stopfnder Application. Could have impact on other functionalities, we will check that in PI20

[TO-mdv]

@vasile I made the changes for the INT system. Is this the response you would expect?
https://tools.odpch.ch/ojp-api-explorer-v2/?gist=d0a5a4970e9bf2efb924a55e662b7a89

[terencebls]

@TO-mdv On your print screen looks good, but when I made a request on INT I got an error, is the service currently down ?

(When I search "Lugano via Balestra 33" for example)

[vasile]

@TO-mdv - looks good

@terencebls - I also get an error for that query "Lugano via Balestra 33"
https://gist.github.com/vasile/f04487b92360555bc3aa92570c3bb851

other queries are working, I assume is the same issue as in #16 , we get same error back

{
    "traceId": "8239bce7-1149-4b7f-bf49-df263da1ef4d",
    "error": "Object reference not set to an instance of an object.",
    "host": "ODP-EC2-SHLNX01-I"
}

@TO-mdv let us know if we should create another ticket for this

[terencebls]

@TO-mdv Just to be sure, we are expecting that the searches also works for those cities for example:

-Zurich (without Umlaut)
-Basel
-Lugano
-Chur
-Geneve
-Biel

When I try with those cities with INT we only get an error.

[TO-mdv]

@vasile I see the point. I will check that again, I don't need another Ticket, let's track in this one

[TO-mdv]

SH-2931 OJP2.0 LIR bringt keine Adressen, trotz deaktivierter ConflictRule -> LIR-2d_ohne Filter muss auch Address liefern

[TO-mdv]

Resolved on INT
Release PROD 29.5.2024

[terencebls]

@TO-mdv with Lugano it doesn't work, it's another problem?

[TO-mdv]

@terencebls this seems to be a different issue. It looks like the LIR is not able to find the housenumber. Other examples for housenumbers are working, example "Staffelstrasse 12 8045".

I will check, if there are problems in the base data for adresses.

[vasile]

@TO-mdv also searche as Type='address' and Name=Bern return 0 result. Not an actual blocker because the current integrator app is using stop+address but still, should be addressed

[TO-mdv]

@vasile That's another problem: if we are searching for "bern" and addresses, we are getting to many results. So for performance reason, we are not able to give a response.

Is that really a usecase of user perspective: search for an adress in Bern, type "bern" without any hint on a street? Do you really expect in the list the address you are searching for?

[vasile]

@TO-mdv yes, the user will use in the integrator app stop+address filter, so will not be the case from my specific example (bern with type=address), so yes, we can ignore it for now