Child stops of stations aren't returned by stops-for-location API using child stop_code

[nakkore]

I've got a strange behaviour when I call the stops for location API which I use to convert the user-facing stop code to the actual stop id.
The API works fine for most stops except for a limited subset. In the gtfs stops.txt I've noticed that this limited subset differs from all other stops and the difference is that they have a parent station defined and location_type=0 if that matters.
Now, when I search for a stop belonging to this subset I get no results. Curiously If I searched the same stop by using the parent station (which is not a user-facing stop code) the API returns a result: wrong stop_id but lat,lon,name are right.

Example of stops.txt entries affected by this problem

stop_id,stop_code,stop_name,stop_desc,stop_lat,stop_lon,stop_url,stop_timezone,location_type,parent_station
ROME8260,AD1,"Battistini","",41.906219,12.414848,"http://muovi.roma.it/percorso/js?query=&cl=1",,0,ITO97
.....................................................
ITO97,,"Battistini","",41.906219,12.414848,"",,1,

Any clue on what's going on here ? What can I do to pinpoint the issue to give you more info ?

Thanks

P.S.
I'm using OBA server 2.0 from the master branch.

[barbeau]

@nakkore What's the CSV header for the above stops.txt records? It looks like the first entry is the platform and the 2nd the station?

If you're able to provide the full GTFS dataset too as well that may help. I don't know where to fix this off top of my head.

[nakkore]

sure,
sorry I should have written that as well.
The header is:
stop_id,stop_code,stop_name,stop_desc,stop_lat,stop_lon,stop_url,stop_timezone,location_type,parent_station

You can get the gtfs file from
https://romamobilita.it/sites/default/files/rome_static_gtfs.zip

[barbeau]

@nakkore Thanks! Have you tried loading up another GTFS that has parent stations and child stops just to see if it's something else with the GTFS?

[nakkore]

@barbeau I'll have a go.

[nakkore]

@barbeau I've investigated a bit on this issue and apparently it has nothing to do with the parent-child relationship. It seems indeed a problem related to how Lucene do searches in the indexed files. In short in StopSearchServiceImpl the _analyzer is a StandardAnalyzer which basically takes the input query and "lowercases" it. The problem is that the indexed stops file contains all words in uppercase and Lucene seems to be case-sensitive. So one solution would be to store all words in the stops index as lower case. In GenerateStopSearchIndexTask.getStopAsDocument replacing

document.add(new StringField(StopSearchIndexConstants.FIELD_STOP_CODE,
narrative.getCode(), Field.Store.NO));

document.add(new StringField(StopSearchIndexConstants.FIELD_STOP_CODE,
narrative.getCode().toLowerCase(), Field.Store.NO));

makes things work.

It would be worth checking other fields which may potentially be affected by similar problems and all other Lucene based searches.

Regards

[barbeau]

@nakkore Thanks for looking into this! @sheldonabrown would be the best person to comment on a possible solution here.