Open kalon33 opened 2 months ago
We can fairly easily move search targets into UI configuration, and location search will then work. However, there are many stop searches in the UI - the stop/route search of the front page, stops near you page etc. These will not work unless stops are indexed into Pelias.
Implementing an option to search these from OTP is a considerable developmeet effort.
Implementing an option to search these from OTP is a considerable developmeet effort.
Sure, I imagine, but that would allow others to more easily use Digitransit with external Pelias providers (that frequently if not always don't have any consideration for GTFS data).
At least the first part in UI configuration will enable to partly use Digitransit in this situation, currently without geocoding it prevents any migration from v1 and OTP 1.x.
Thanks for what you could do on this.
I added the control into configuration, see:
https://github.com/HSLdevcom/digitransit-ui/pull/5097
This will be merged into v3 bridge anch next week.
I added the control into configuration, see:
https://github.com/HSLdevcom/digitransit-ui/pull/5097
This will be merged into v3 branch next week.
Thanks a lot! Will try as soon as it will be merged.
@vesameskanen At which level in the config should I add locationSearchTargetsFromOTP: []
?
root level
root level
OK so I tried with latest v3 branch checkout from today, putting locationSearchTargetsFromOTP: [],
right under searchParams: {},
in the config file, but still I have some requests on a station layer, preventing geocoding (reverse geocoding is working properly). Is there something I did wrong?
No you did not. I suspect that our search library uses station layer for finding OpenStreetMap stations (not GTFS ones). I will take a closer look.
It seems that we have to add a new search target specifier 'stations' into the search component. This is a straightforward thing to do.
A new attempt is now made. Please try again.
A new attempt is now made. Please try again.
Thanks @vesameskanen but building and running from the latest code in v3 branch:
I still have requests to a station
layer : in the geocoding request URL I have text=21%20avenue%20de%20la%20liberation&lang=fr&sources=oa%2Cosm&layers=station%2Cvenue%2Caddress%2Cstreet
Strange, when I run the code locally everything seems to work as expected. Only venue, street and address are searched.
Maybe this is somehow a library version issue. I will test in our dev environment as well.
Seems to work the same way in dev. Can you double check? Remember to add locationSearchTargetsFromOTP: []
.
I'm up to d47e439a2d01ec41702a85ac226a7bc1ccaaa47c
commit, I just rebuilt the docker with --no-cache
and added in the conf that way:
searchParams: {},
locationSearchTargetsFromOTP: [],
locationSearchTargets: [],
Still, the problem remains. Any idea?
The feature works as expected, so I have no idea why it does not work there. Maybe something is wrong in the process how you run the UI. Try running the UI server directly without docker.
BTW, there is no reason to add locationSearchTargets to config, UI does not use such field.
I use a Pelias instance that has no stop nor station layers available (available layers are coarse,address,venue,street,intersection,postalcode,locality,neighbourhood,county,localadmin,region,macrocounty,country,macroregion,dependency,borough,macrohood,marinearea,disputed,empire,continent,ocean).
How can I disable these requests? That currently prevents it from returning any results when geocoding an address.
Thanks for your help.