Questions regarding "SearchByTestRequest"

deals with geocoding and reverse geocoding

Questions regarding "SearchByTestRequest"

Postby kraucal » Wed Apr 03, 2019 8:27 am


we have been testing out the XLocate API and have collected some questions since we could not find a solution. The questions are all related to the "SearchByTestRequest" of the XLocate API.

1. How to limit the result of the SearchByTestRequest and only return matches with a high matching-score.
2. How to "prefer" (higher score maybe) results that are closer to a given location. (Like google maps when typing in something results from close to your location appear first)
3. (If possible) return only results that contain a street name (not only city name for example)

It would be great to know which attributes we need with which values (example) to send to the API in order to receive a proper result.

Thank you in advance...

-Alexander Krauck - OptaData Linz
Posts: 2
Joined: Wed Apr 03, 2019 7:57 am

Re: Questions regarding "SearchByTestRequest"

Postby Bernd Welter » Wed Apr 03, 2019 8:33 am

Hello Alex,

I assume we deal with xLocate 2 API. One core difference between the API of xLocate 1 and xLocate 2 is the approach towards “parametrizing”:

  • In xLocate 1 it was the due of the client to identify proper parameters (SearchOptions, NamedSearchOptions, config profiles...)
  • In xLocate 2 we shifted the due to PTV DEV: the server will return potential candidates ("rough input such as "Neustadt" will create a worst case output: A LOT of candidates) and enrich each one with detailed infos. This will then enable the client to filter the result list based on these additional properties.
This means:

  • There’s no parameter to limit or to filter the number of candidates. As the network bandwidth is not as limiting as it used to be we can return even hundreds of candidates as long as they match the basic criteria.
  • Filtering based on Score is simple on client side
  • So is "based on street name equired"
  • SORTING by distanceTo(x,y) based on (x,y)=current location is something that you'd also have to implement on client side. Reminds me of "adding some further sorting columns in a SQL ORDER BY". At least with LINQ this would be simple. 

Best regards,
Bernd Welter
Senior Technical Consultant Developer Components
PTV GROUP - Germany

Bernd at Youtube
User avatar
Bernd Welter
Site Admin
Posts: 1335
Joined: Mon Apr 14, 2014 10:28 am

Return to PTV xLocateServer