The address geocoding matches a given user input to an address database using several techniques of string matching:
The searching process works step by step. That means if there are no binary matches the xLocate will try to find a match by searching phonetically.
findAddress() to geocode the address.The aim of the classification is to verify a given address regarding plausibility. This is useful e.g. for a webshop which likes to verify a given address of a new customer. The xLocate provides additional information about how specific parts of an address are matched. This way you may determine which address parts were not matched exactly and what types of error occurred.
Former xLocate versions (until 1.14.1) delivered two validation profiles for different security levels: High and Medium. With the introduction of field classification these profiles were superfluous and will not work anymore. We recommend to substitute these old profiles with the following minimum classifications:
| Postcode | Town | Street | |
|---|---|---|---|
| High | Partially Exact Exact Exact | Exact Partially Exact Exact | Exact Exact Partially Exact |
| Medium | Exact Partially Exact | Partially Exact Exact | High High |
| Low | High | High | High |
This means, if all parts of the classification (postcode, town, street) are Exact, or at most one is Partially Exact, the input address can be validated as High. If this is not the case, because the street classification is only High, the input address can be validated as Medium. If this is not the case, but no classification is below High, the input address can be validated as Low. If one classification is below High, the input address cannot be validated.
The address geocoding matches a given user input as one single text field to an address. For this the method findAddressByText can be used. Define the parameter country and address.
This feature is only available for maps 1/2010 or newer.
The address geocoding matches a given user input as one single text field to an address. For this the method findAddressByText can be used. Define the parameter country and address.
This feature is only available for maps 1/2010 or newer.
When geocoding an address interactively you may want to guide your user to the right address and suggest him the most probable city or street names while typing. Unfortunately geocoding after every keystroke just does not meet the performance requirement. Therefore the xLocate has a lightweight high performance suggestion function.
This feature is only available for maps 1/2010 or newer.
The findCombinedTransportByLocation method searches ferries and piggy back stations located next to a given coordinate. The method works similar to the findLocation() method but returns ResultCombinedTransport objects instead of ResultAddress objects.
This feature is only available for maps 1/2012 or newer.
Combined transports are also searchable by its name and the name of the start or destination location by findObjectsByText(). Note that despite of the handling of addresses a given country will be ignored.
This feature is only available for maps 1/2012 or newer.
Point of Interest data is available for most of the PTV standard maps. It is searchable by its address, type, name and radius.
Besides points of interest data you can also search for additional custom geographic data by defining your own Geodatasource and applying it to a PoiAddress or PoiLocation object. More information on the configuration of GeoDatasource and filtering can be found here.
For a search request on custom geographic data you need a GeoDatasource configuration name, the layer name and the profile name. These information have to be set in the request using the geodatasourceLayer attribute of PoiAddress or PoiLocation. It has to be formatted as follows:
<configuration>.<layername>[.<profile][;<SQL Filter>]
<configuration>The geodatasource configuration name is the part of the filename<configuration>-geodatasource.xml. The layer name and the profile is /configured in this file.<layername> This is the attribute name of the XML element LayerInfo and determines the layer to be used.<profile> The configuration can list several profiles under the tag Profiles. This attribute specifies which of these should be referred to. If omitted default is assumed. If the default profile does not exists, the first profile of the profile list is used.<SQL Filter> Additionally,an SQL filter statement can also be added. For this SQL filter you can use the column names of the database or attribute names in brackets (like[TYPE]). These attribute names are defined in the <AttributeMappings> of your used LayerInfo in the file <configuration>-geodatasource.xml. With the AttributeMapping column names can be mapped to attribute names. A column name can only be used once in a AttributeMappings element. The SQL filter will be attached at the end of the WHERE clause. Valid expressions are comparisons (<, >, =, like, …). Concatenations of expressions are possible with the SQL operators AND and OR.Please see the following documents for more information.
Please find more general information on jobs (Asynchronous Protocol).
The service methods findAddresses, findLocations, findPoiByAddresses, and findPoiByLocations have corresponding start-methods startFindAddresses, startFindLocations, startFindPoiByAddresses, and startFindPoiByLocations to start the calculation as a job. The corresponding fetch-methods are fetchAddressResponses and fetchPoiAddressResponses.
During the calculation the current calculation progress can be watched using watchJob. This method returns an instance of BulkProgress which contains information on how many geocodings have already been calculated and how many are remaining.
When stopping the currently running job using stop_Job the results already calculated at that point of time will be returned by the fetch-method. Geocodings not yet executed will be denoted by error code STOPPED_REQUEST.
Copyright © 2024 PTV Logistics GmbH All rights reserved. | Imprint