Inconsistencies between geoclient and geo support about geoclient HOT 3 CLOSED

Hi,

As you mentioned, the /geoclient/v1/address endpoint is simply a pass-through to the Geosupport function 1B. The information returned by function 1B is composed of results from two separate address-related functions 1E and 1A. These functions can succeed or fail independently as was the case in the example you've given (1E succeeded, 1A falied). The confusion (I think) stems from the differing spatial fields each function returns:

• 1E location
  • xCoordinate/yCoordinate
  • longitude/latitude
  • Represents a "theoretical address" geocoded to the street centerline based on address ranges
• 1A location
  • internalLabelXCoordinate/internalLabelYCoordinate
  • longitudeInternalLabel/latitudeInternalLabel
  • Represents a "real property address" geocoded to the centroid of the containing tax lot polygon

Within the unique scope of each function, you''ll notice the same real-world point location is returned in two different coordinate reference systems:

• The naming conventions which include "...xCoordinate" and "...yCoordinate" is the point in CRS EPSG:2263
• The naming conventions "longitude..."/"latitude..." is the point in EPSG:4326

Sooo...in the example you've given, we see that:

{ address: {
    ...
    "geosupportReturnCode": "00",  <-- function 1E succeeded
    "returnCode1e": "00",
    "geosupportReturnCode2": "42", <-- function 1A falied
    "returnCode1a": "42",
    ...
    // 1E location is available:
    "latitude": 40.74010473007666,  <-- EPSG:4326 ("lat/long")
    "longitude": -73.9017263539154,
    "xCoordinate": "1011483", <-- EPSG:2263 ("NY State Plane")
    "yCoordinate": "0208932",
    ...
    // 1A location info is NOT available
}}

In plain English, the above essentially means "45-06 is valid house number on the range assigned to 64th street in queens but there's no record of that actual address on an existing tax lot".

For comparision, try a call with address 106 East 64 street, Manhattan which succeeds for both functions. In addtion to the 1E fields, you'll notice the 1A info also:

{ address: {
    ...
    // 1A is available (yay!)
    "internalLabelXCoordinate": "0993316",
    "internalLabelYCoordinate": "0218250",
    ...
    "latitudeInternalLabel": 40.76571755841329,
    "longitudeInternalLabel": -73.9672716432342,
    ...
}}

I'm not sure what's going on in the case of python-geosupport, so I'd recommend asking for clarification there.

Please let me know if I've answered the right question.

Thanks!
Matt

from geoclient.

Thank you, that's super helpful!

from geoclient.

Anytime. Glad it helped.

from geoclient.