Page 1 of 2
Possible to reduce the minimimum length requirements for postcodes?
Posted: Mon Feb 26, 2024 1:41 pm
by mmauri
Hello,
I hope this is the correct place on the forum for such a post - and will gladly xlocate it to a more appropriate place if it is not.
We have recently swapped our map data over to 2024 - since then I have had some questions from colleagues about searching by postcode.
Previously my collegaues would be able to find postcodes by typing in their first number, for example they would select the country "Denmark" and type in "1" and receive all the postcodes beginning with "1".
This leads me to believe that in migrating we have lost a previously set configuration - which leads me to the question:
Is it possible to have the xLocate Server search for postcodes based soley off of one number?
With Denmark as an example again, if I type in "1" - I receive no results however, if it type in "12" I now get a list of postcodes in Copenhagen - so Denmark postcodes are only searched after a minimum of two digits - is it possible (and advisable), by changing a configuration, to reduce this to a one digit search?
Thank you for your time,
Matthias M
p.s.
Love the emojis
Re: Possible to reduce the minimimum length requirements for postcodes?
Posted: Mon Feb 26, 2024 2:39 pm
by bocajo
Which xLocate version and map version are you using? It would also be helpful to know wether you are using single field or multi field search.
Re: Possible to reduce the minimimum length requirements for postcodes?
Posted: Mon Feb 26, 2024 2:53 pm
by Bernd Welter
Hello Matthias,
honestly spoken the promise of a "geocoder" is
Give me meaningful address and I'll return proper coordinates you can use in your process for routing or optimization...
So what you describe is a process that would enable a user to gather the raw data from our map database, which is seen as EVIL
In other words: If you can't access the info you are looking for it is probably by design
I'll forward this post to Product Management for a statement...
Bernd
PS: I just saw that Jochen answered while I was still designing my response
Re: Possible to reduce the minimimum length requirements for postcodes?
Posted: Mon Feb 26, 2024 3:18 pm
by mmauri
Hello Jochen and Bernd,
Thank you for the quick replies.
To Jochen first:
We are using the xServer-Bundle-x64-1.38.0.1 - our maps version is 2024.1H
We are running for most of our searches: "XLocate.findAddress".
We interact with the server via another programme and the api calls have not been changed.
To Bernd:
Naturally I do not want to do anything evil - just do right by my colleagues!
But, I do not understand how searching for all the postcodes that begin with "1" in Denmark would allow a user to get any more data from the database than they are already receiving by typing "12" as the postcode - am I misunderstanding something?
Regards,
Matthias M
Re: Possible to reduce the minimimum length requirements for postcodes?
Posted: Mon Feb 26, 2024 3:27 pm
by Bernd Welter
Hello Matthias,
Naturally I do not want to do anything evil - just do right by my colleagues!
But, I do not understand how searching for all the postcodes that begin with "1" in Denmark would allow a user to get any more data from the database than they are already receiving by typing "12" as the postcode - am I misunderstanding something?
Well, at least we don't want to make it too easy... But Jochen is probably the best "first responder" you can get !
Bernd
Re: Possible to reduce the minimimum length requirements for postcodes?
Posted: Tue Feb 27, 2024 7:17 am
by mmauri
Good Morning to the PTV Forum,
On closer inspection, our programme is using a multi-field search - I will gladly do my best to answer and further questions / provide any further info.
Thank you both for your support,
Matthias M
Re: Possible to reduce the minimimum length requirements for postcodes?
Posted: Tue Feb 27, 2024 8:08 am
by Bernd Welter
Here's the output I get from xLocate 1 by entering
Country = "DK"
PostalCode = "10"
- xLocate1 - offers many switches...
If I repeat this with xLocate2 / Developer Geocoding the result list is empty...
Re: Possible to reduce the minimimum length requirements for postcodes?
Posted: Tue Feb 27, 2024 9:50 am
by bocajo
The result list of the xL1 depends on the number of addresses found. If you add the parameter <FrequencyFiltering Value="0" Type="bool"/> in the native-default.xml then you will get results for Country=DK and postCode=1.
An astrisk search is not implemented for the xL2 multifield search. But the asterisk search was implemented for the xL2 singlefield search:
If you need it for the multifield search, you may be able to use the suggestion by address search of the PTV Developer Platform. An asterisk search is implemented here but you need to combine it with the location by address search.
https://developer.myptv.com/en/document ... ns-address
https://developer.myptv.com/en/document ... ns-address
The idea with the suggestion search is that you need fewer geocoding requests and a suggestion search is much cheaper compared with a geocoding request.
https://developer.myptv.com/en/help/faq ... alculation
Re: Possible to reduce the minimimum length requirements for postcodes?
Posted: Wed Feb 28, 2024 12:03 pm
by mmauri
Hi,
I was unable to reply yesterday but, thank you for the answers.
While comparing our old config and our current one there are the two big differences I noticed:
Code: Select all
<ExtensiveSearch Value="1" Type="bool"/>
<FrequencyFiltering Value="0" Type="bool"/>
So I have experimentally added those in, and will report my findings.
A quick clarification, by checking the "xlocate.properties" it says we are using v.1.3.01 - is this xL2 or xL1?
Thank you,
Matthias M
Re: Possible to reduce the minimimum length requirements for postcodes?
Posted: Thu Feb 29, 2024 12:12 pm
by Bernd Welter
The parameters mentioned by Jochen are part of xLocate1... there's a generic forum post
"Geocoding basics (strictly recommended)" that is really recommended for xLocate1 users.
But honestly spoken:
We recommend to migrate to
xLocate2 (OnPremise) or Developer (Cloud only)