Reverse GeoCoder:FAQ: Difference between revisions
No edit summary |
No edit summary |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
[[Reverse GeoCoder|← Reverse GeoCoder]] | [[Reverse GeoCoder|← Reverse GeoCoder]] | ||
{{CustomTOC}} | {{CustomTOC}} | ||
==Service Returns GE54== | |||
;Why Is the service returning GE54? | |||
As with most most web services, a request can fail for any number of reasons internal to the service and not due to user configuration. For reverse Geo, this may simply be that the service could not perform all the searches and computations necessary to determine the nearest location to the input before the service timed out. Depending on the use case, decreasing the <code>max distance</code> search radius may actually be the best workaround. | |||
==Maximum Records Per Request== | ==Maximum Records Per Request== | ||
;What's the maximum number of records that the user can get per request? | ;What's the maximum number of records that the user can get per request? | ||
| Line 31: | Line 37: | ||
The Distance returned (in miles) between the input and the output point will serve as an indicator of accuracy. A distance of zero means an exact match was returned. | The Distance returned (in miles) between the input and the output point will serve as an indicator of accuracy. A distance of zero means an exact match was returned. | ||
==Service Update Frequency== | |||
;How often is the service updated? | |||
Reverse Geo is updated on a scheduled quarterly basis. Additionally, the service may also be updated as needed. | |||
==Service Throughput== | |||
;What is the expected throughput? | |||
:{| class="alternate01" | |||
!Service Endpoint !! Throughput (records / hour) | |||
|- | |||
|doLookUp||70,000 | |||
|- | |||
|doLookUpPostalCode||92,000 | |||
|- | |||
|doLookUpFromList||85,000 | |||
|} | |||
;Service factors affecting throughput: | |||
*;Distribution of the data | |||
*:If inputs are randomly distributed over a wide range of areas, the searching algorithm for a particular input will require more of the underlying geo data to be accessed. | |||
*;Input data | |||
*:Input data representing rural areas, a large search radius, and or large number of response addresses will all result in more searches and algorithms performed to return the de3sired number of locations | |||
*;Number of threads | |||
*:The above benchmark is for a single thread of 1 record batches. Because each service call may request up to 100 response records, the service was developed as a single input request with request size, response computation time, and response time taken to consideration. Increasing the number of threads can greatly increase throughput. Users should thoroughly test the effects of the number of threads against network configuration to determine the most optimal usage. | |||
:{| class="alternate01" | |||
!Average Response Time !! Average (ms / record) | |||
|- | |||
|Single request||28ms | |||
|- | |||
|P95 Latency||64ms | |||
|} | |||
[[Category:Reverse GeoCoder]] | [[Category:Reverse GeoCoder]] | ||
[[Category:FAQ]] | [[Category:FAQ]] | ||
Latest revision as of 16:09, 2 August 2022
Service Returns GE54
- Why Is the service returning GE54?
As with most most web services, a request can fail for any number of reasons internal to the service and not due to user configuration. For reverse Geo, this may simply be that the service could not perform all the searches and computations necessary to determine the nearest location to the input before the service timed out. Depending on the use case, decreasing the max distance search radius may actually be the best workaround.
Maximum Records Per Request
- What's the maximum number of records that the user can get per request?
The Maximum number of records returned by the service is 100. Setting a higher number (Or no number at all) in the request MaxRecords field will not change this limit.
Maximum Distance
- What's the maximum distance allowed?
The Maximum is 10 miles regardless whether the user specifies a higher number in the MaxDistance field, or doesn't specify anything at all.
Mandatory Fields
- What fields are mandatory in the request?
The mandatory fields are CustomerID, Latitude and Longitude. MaxRecords and MaxDistance are optional. If They are not specified, the default value for MaxRecords is 100 records, and for MaxDistance it's 10 miles.
Supported Lat/Long Formats
- What Lat/Long formats does the service accept?
The service accepts only the decimal representation of the Lat and Long.
Formats such as:
116°14'28.86"W or -116 14 28.86 will not be accepted. East/West, Minutes/Seconds formats will have to be converted by the user prior calling the service.
Percentage of Accuracy
- Is there a percentage to the accuracy of the results returned?
The Distance returned (in miles) between the input and the output point will serve as an indicator of accuracy. A distance of zero means an exact match was returned.
Service Update Frequency
- How often is the service updated?
Reverse Geo is updated on a scheduled quarterly basis. Additionally, the service may also be updated as needed.
Service Throughput
- What is the expected throughput?
Service Endpoint Throughput (records / hour) doLookUp 70,000 doLookUpPostalCode 92,000 doLookUpFromList 85,000
- Service factors affecting throughput
- Distribution of the data
- If inputs are randomly distributed over a wide range of areas, the searching algorithm for a particular input will require more of the underlying geo data to be accessed.
- Input data
- Input data representing rural areas, a large search radius, and or large number of response addresses will all result in more searches and algorithms performed to return the de3sired number of locations
- Number of threads
- The above benchmark is for a single thread of 1 record batches. Because each service call may request up to 100 response records, the service was developed as a single input request with request size, response computation time, and response time taken to consideration. Increasing the number of threads can greatly increase throughput. Users should thoroughly test the effects of the number of threads against network configuration to determine the most optimal usage.
Average Response Time Average (ms / record) Single request 28ms P95 Latency 64ms