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

Disable stop and station layers parameters in Pelias request #5086

Open
kalon33 opened this issue Sep 20, 2024 · 15 comments
Open

Disable stop and station layers parameters in Pelias request #5086

kalon33 opened this issue Sep 20, 2024 · 15 comments

Comments

@kalon33
Copy link
Contributor

kalon33 commented Sep 20, 2024

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.

@vesameskanen
Copy link
Member

vesameskanen commented Sep 23, 2024

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.

@kalon33
Copy link
Contributor Author

kalon33 commented Sep 23, 2024

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.

@vesameskanen
Copy link
Member

I added the control into configuration, see:

#5097

This will be merged into v3 bridge anch next week.

@kalon33
Copy link
Contributor Author

kalon33 commented Sep 28, 2024

I added the control into configuration, see:

#5097

This will be merged into v3 branch next week.

Thanks a lot! Will try as soon as it will be merged.

@kalon33
Copy link
Contributor Author

kalon33 commented Sep 30, 2024

@vesameskanen At which level in the config should I add locationSearchTargetsFromOTP: [] ?

@vesameskanen
Copy link
Member

root level

@kalon33
Copy link
Contributor Author

kalon33 commented Oct 3, 2024

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?

@vesameskanen
Copy link
Member

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.

@vesameskanen
Copy link
Member

It seems that we have to add a new search target specifier 'stations' into the search component. This is a straightforward thing to do.

@vesameskanen
Copy link
Member

A new attempt is now made. Please try again.

@kalon33
Copy link
Contributor Author

kalon33 commented Oct 11, 2024

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

@vesameskanen
Copy link
Member

vesameskanen commented Oct 11, 2024

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.

@vesameskanen
Copy link
Member

vesameskanen commented Oct 11, 2024

Seems to work the same way in dev. Can you double check? Remember to add locationSearchTargetsFromOTP: [] .

@kalon33
Copy link
Contributor Author

kalon33 commented Oct 11, 2024

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?

@vesameskanen
Copy link
Member

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.

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

No branches or pull requests

2 participants