How to improve performance in xLocate 2?

deals with geocoding and reverse geocoding in the context of PTV Geocoding&Places, PTV Geocoding&Places OSM and PTV xLocate 1 and 2
Post Reply
User avatar
Bernd Welter
Site Admin
Posts: 2695
Joined: Mon Apr 14, 2014 10:28 am
Contact:

How to improve performance in xLocate 2?

Post by Bernd Welter »

Cheers,

here's just a little advice for those who want to achieve the best performance on xLocate 2, both with a single geocding or a batch:
  • Use the search option allowedCountries whenever it is possible! I just received 1000 addresses for multifield search and applied them with/without the search option "allowed countries". The difference in the performance is significant - which is no surprise becaue all the addresses beloing to switzerland which covers a very small region of the world:
    • xLocate 2 without allowedCountries: 176 seconds ( 100% )
    • xLocate 2 with allowedCountries={"CH"}: 27 seconds ( 15% )
    Be aware that this parameter is an array, so if your market is based on a group of countries such as ["DE","AT,"CH"] you can model the region.
  • Ensure proper input data structures - avoid "noise": some players add useless and misleading information in the input data, e.g. phone numbers or parking hints. As the geocoding process tries to match each incoming word it sometimes happens that the count of splitted words is exceeding a critical value (recently faced a 25 words street pattern). The risk is to blow up performance (long response time or even timeout with no valid response at all) and to ruin the quality of the output (wrong addresses).
The following hints apply to batch geocoding, e.g. if you want to process more than 10'000 in a sequence:
  • Use the batch version searchLocationsInBulk: This will avoid your application from opening and closing HTTP / HTTPS connections without need.
  • Use partitioning - cut the workload and send it in parallel: do not send the 10'000 in a single thread. Cut the complete workload into smaller chunks and send them in parallel, e.g. 4 parallel threads of 2'500. Do not use too many parallel threads by the way - this could have a negative impact on performance.
:!: The country field of an input address is not a hard constraint - this is why allowedCountries is so important.
:!: Within a bulk operation (whether it is bulk geocoding or bulk routing) all elements of the bulk apply the same parameters. Keep this n mind when you want to use allowedCountries.
:!: Be aware that the bulk versions will provide a progress of the overall geocoding process. You could use this to estimate the time of finishing a bulk transaction.

I hope these hints help you to improve performance - let me know if you have further strategies that could help.
Best regards,
Bernd
Bernd Welter
Technical Partner Manager Developer Components
PTV Logistics - Germany

Bernd at... The Forum,LinkedIn, Youtube, StackOverflow
I like the smell of PTV Developer in the morning... :twisted:
User avatar
Bernd Welter
Site Admin
Posts: 2695
Joined: Mon Apr 14, 2014 10:28 am
Contact:

Re: How to improve performance in xLocate 2?

Post by Bernd Welter »

If you are running an installation based on a regional map and you are 100% sure that your client applications do not require countries outside a specific area you can also reduce the geocoder index:
Example: Arabia City map... required integration units
  • are - Arabic Emirates
  • bhr - Bahrain
  • irq - Iraq
  • isr - Israel
  • jor - Jordania
  • kwt - Kuwait
  • lbn - Lebanon
  • omn - Oman
  • qat - Qatar
  • sau - Saudi Arabia
  • syr - Syria
  • yem - Yemen
Manually assembled "Arabia City Geokoder index"
Manually assembled "Arabia City Geokoder index"
Best regards,
Bernd
Bernd Welter
Technical Partner Manager Developer Components
PTV Logistics - Germany

Bernd at... The Forum,LinkedIn, Youtube, StackOverflow
I like the smell of PTV Developer in the morning... :twisted:
Post Reply