Migration Guide : "How to get away from xLocate1?"

[Bernd Welter]

Hi there,

more and more partners ask me for assistance when it comes to the current challenge of

Code: Select all

I am supposed to replace xServer1 Geocoding with newer PTV APIs (PTV Developer based or in nsome rare cases xLocate 2)- how can I approach this?

I therefore want to gather some basic info which I would recommend you to check careful if you want to migrate existing approaches. (So this is not about new features!). It is also not about voting for the better API. It's pure info.There might also be some cross references to other posts in the forum:

• Comparison of xLocate 2 and PTV Developer Geocoding API

But let me start with what you are used to in xLocate1:

• xLocate1 offers a large set of parameters you can use to control filters and structure of a result:

  Code: Select all

  <SearchOptionBase xsi:type="SearchOption" value="1" param="COUNTRY_CODETYPE" xmlns=http://xlocate.xserver.ptvag.com/>
  …          <SearchOptionBase xsi:type="SearchOption" value="999" param="MAX_RESULT" xmlns=http://xlocate.xserver.ptvag.com/>
  

  The good news are, the newer APIs are less complicated when it comes to such parameters. That's because we reduced the set to a bare minimum. Might be subject to change but for now you could more or less just filter
  • per allowed countries (which has been invented also on behalf of performance)
  • how to return the country value of a result address (not really a structural parameter if you ask me, as it does not influence "which" addresses are returned)
• Furthermore there have been much more quality properties in the output such as

  Code: Select all

  <ResultField xmlns=http://xlocate.xserver.ptvag.com>POPULATION</ResultField>
  …          <ResultField xmlns=http://xlocate.xserver.ptvag.com>CLASSIFICATION_DESCRIPTION</ResultField>
  

  You may have used this info to apply sorting and filtering on client side. As of early 2024 the response of the newer APIs is not as detailed as you are used to.
• Just to be complete: also the new APIs results are based on
  • complete strings in the addresses wherever possible (no oinput street? you wont't get a street name in the response (besides reverse geocoding)
  • score : designed to mainly sort results (better score...) and to filter (score too low? Kick it!)
  • coordinates (even with the new rooftop coordinates!)
  • various further quality properties : often used for client side sort / filter
  So this structure rmains. BUt depending on whether you go for PTV Developer Geocoding (HERE based) or PTV Developer Geocoding (OSM based) the output fields may vary.
• Now some of you have built a complex business logic based on iteration:
  • Perform initial geocoding
  • If insufficient due to quality criteria, score... iterate...
  • change search options
  • change input fields (e.g. remove city name or street)
  You can still apply this - just be aware that there's different output fields available.

Feedback is welcome - I am very open to extend this post!

Bernd

[Uwe Schuster]

@PTV:
What is your experience with the migration of Map&Guide internet/intranet from xServer 1 to xServer 2?

What were your challenges during the migration?

Are the Map&Guide users satisfied with the results and performance of the Map&Guide version powered by xServer 2?

[Bernd Welter]

Hello Uwe,

The experience I have with parties who compare MAP&GUIDE (desktop: MapServer, internet: xServer1) is mainly focussing on roting aspects - please consider that this current thread is in the Geocoding domain (xlocate).

There are threads in the proper Routing (xroute) domains. Please check them . If you want to start a routing based discussion I am open for this: please just in the proper space.

Is there any specific geocoding based question we can handle for you in this xLocate thread?

Bernd

PS: I might even start some "how to get away from xRoute1?" - just a question of recources