Search for street segments, stretches, and blockfaces in NYC
Street Search - findAddressCandidates
You can search for many different kinds of addresses using the LocateNYC API /findAddressCandidates operation
including address, place, intersection, NYC building (using BIN), NYC tax lot (using BBL), 3D building floor, street segment (the street between
two consecutive intersections), street segment blockface (one side of the street), and street stretch (the stretch of street between intersections that are not consecutive).
You can pass the address components in a single parameter using the singleLine option
or separtated into multiple parameters. The response is the same for both scenarios.
LocateNYC returns a wide variety of response parameters. Please see the Response Parameters
sections below for a full list. Many of these parameters are derived directly for the NYC Geosupport API and are described using the
descriptions provided in the Geosupport User Programming Guide (UPG). Many other parameters are created directly from the LocateNYC
API and are also descirbed in Repsonse Parameters section.
The purpose this page is to focus on the main types of street searches that are available in LocateNYC including street
segment, blockface, and street stretch. Although these functions are tied to Geosupport functions 3, 3C, and 3S, LocateNYC
enhances these functions in a variety of ways including providing geographic midpoint locations for straight and curved
street segments.
Specifies the location to be geocoded. The input address components are formatted as a single string.
Address Example:
singleLine=231 East 10th Street, Manhattan
Place Example:
singleLine=Carnegie Hall
BIN Example:
singleLine=1006458
BBL Example:
singleLine=1007810001
Intersection Example:
singleLine=8th Avenue and 41st Street, Manhattan
Street Segment Example:
singleLine=10th Ave between W 50 St and W 51 St, Manhattan
Blockface Example:
singleLine=West side of 10th Ave between W 50 St and W 51 St, Manhattan
3D Address Example:
singleLine=231 East 10th Street, Manhattan, Floor 3
3D Place (the "B" represents below ground or basement) Example:
singleLine=Carnegie Hall, Floor B1
houseNumber
The number of the address to be geocoded. To be used in coordination with street, borough, zip
street
The street name of the address to be geocoded. To be used with houseNumber, borough, zip
borough
The borough of the address to be geocoded. Accepts both spelled and coded values. Accepts [Manhattan, Bronx, Brooklyn, Queens, Staten Island, MN, BR, BK, QN, SI, 1, 2, 3, 4, 5]
as well as coded values for boroughs. See BOROUGH CODE for more details on the coded values.
To be used with houseNumber, street, zip
Example:
borough=Manhattan
zip
The zip code (postal) of the address to be geocoded. 5 bytes. To be used with houseNumber, street, borough
Example:
zip=10035
onStreet
The "on" street segment/stretch for street segment/blockface queries. For example, the address is "on" W 41 St between 7 Ave and 8 Ave. If passed to the API, crossStreetOne
and crossStreetTwo are required.
Example:
onStreet=West 41 Street
crossStreetOne
The first cross street for street segment/blockface queries. For example, the address is "on" W 41 St
between 7 Ave and 8 Ave. If passed to the API, onStreet
and crossStreetTwo are required.
Example:
crossStreetOne=7 Ave
crossStreetTwo
The first cross street for street/segment blockface queries. For example, the address is "on" W 41 St
between 7 Ave and 8 Ave. If passed to the API, onStreet
and crossStreetOne are required.
Example:
crossStreetTwo=8 Ave
compassDirection
The compass direction [n, s, e, w] for single side blockface queries. If the LocateNYC API finds a match, then Geosupport blockface
information (only one side of a street segment) will be returned.
If passed to the API, onStreet
, crossStreetOne, and crossStreetTwo are required.
Example:
compassDirection=e
boroughCrossStreetOne
The borough of the first cross street (crossStreetOne) for street segment/blockface queries.
Only required if crossStreetOne parameter is passed.
Example:
boroughCrossStreetOne=manhattan
boroughCrossStreetTwo
The borough of the second cross street (crossStreetTwo) for street segment/blockface queries.
Only required if crossStreetTwo parameter is passed.
Example:
boroughCrossStreetTwo=manhattan
outSR
The well-known ID of the spatial reference, or a spatial reference JSON object for the returned addresses. WKID accepted include:
[4326 (default, WGS), 2263 (Long Island State Plane), 3857 (Web Mercator),
102100 (Web Mercator), 26918 (UTM 18N)]. Format 1; 3857. Format 2; {"wkid":102100}.
Examples:
outSR=3857
outSR={"wkid":102100}
normalizeType
The normalize type parameter represents how the address should be normalized by LocateNYC/Geosupport.
For more details, please refer to the Geosupport User Guide
The supported types are
input - (default) normalizes the provided input address
primary - normalizes to DCP primary street name
principal - normalizes to DCP principal street name
preferred - normalizes to DCP preferred street name
nycps - Only supported for on-premise Enterprise install. If this value is passed using locatenyc.io, the default value of input will be used instead. For /reverseGeocode, the default is preferred and passing input will result in preferred normalized output. Only active for input will be used instead. For /reverseGeocode, street segment, street strech, and blockface requests
callback
Callback parameter. Produces padded JSON response. Used by Esri APIs/SDKs. Only use this if you really know what your doing.
f
Requested format of the response. Only accepts 'json', and the default value is 'json'.
According to the NYC Geosupport User Guide (UPG), a street segment is defined as a street stretch between
a pair of delimiting nodes which may not coincide with an intersecting street. A
street segment can therefore consist of a set of one or more street centerline segments.
In Geosupport, the general term ‘street segment’ is used to describe two
situations:
1) A street segment is strictly defined as a street stretch such that the two
delimiting nodes are consecutive along the ‘on’ street. Every such
segment is uniquely identified by a segment ID, and 2) For Geosupport purposes, a street segment often refers to a street stretch
consisting of more than one segment, such that at least one side of the
street stretch is a single entire blockface. This street stretch is defined by
multiple segments id’s, all of which may optionally be returned to the
user.
A street segment, is considered to comprise
both sides of the ‘on’ street. In the case of a street segment, each side
necessarily is either a single entire blockface or a portion of one.
Example: Search for street segment along 10th Avenue (10th Ave between W 50 St and W 51 St, Manhattan)
According to the NYC Geosupport User Guide (UPG), a blockface is a continuous frontage of a physical city block along one
street, ignoring the presence of any bending points or other intervening
nodes. That is, the portions of a street frontage of a block that lie on both
sides of a bending point are considered to be parts of the same blockface.
For example, the Manhattan block bounded by Madison
and Park Avenues and East 51st and East 52nd Streets has the following four
blockfaces (see figure below, block is highlighted in blue): 1) The east side of Madison Avenue between East 51st and East 52nd
Streets, 2) The south side of East 52nd Street between Madison and Park
Avenues, 3) The west side of Park Avenue between East 51st and East 52nd
Streets, 4) The north side of East 51st Street between Madison and Park
Avenues
Example: Search for street segment blockface along 10th Avenue (E side of 10th Ave between W 50 St and W 51 St, Manhattan)
According to the NYC Geosupport User Guide (UPG), a street stretch is a portion (possibly all) of a street (called the ‘on’ street)
between any two nodes along it (called the delimiting nodes of the stretch). A
street stretch is considered to comprise both sides of the ‘on’ street. Every street stretch is composed of a set of one or more street segments, which
do not necessarily form a continuously connected chain. That is, a street stretch
can encompass gaps in the street.
For each street segment request, each REAL instersection along the stretch will be included in the response within
the intersections parameter (see example below). Psuedo-intersections
are not included in the list. A loction will be provided in the location
object in the response, which represents an estimation of the midpoint of the street stretch. If the street stretch
is non-contiguous, then no location will be provided in the response. However, the intersections will have location specified which can be used if needed.
Example: Search for street stretch along 7th Avenue, with DCP 'preferred' street names (7th Ave between W 120 St and W 123 St, Manhattan)
Example: Search for non-contiguous (i.e. disconnected) street stretch. W 64th street is broken by the Lincoln Center. (w 64 st between central park west and west end avenue, manhattan)
The entirety of West 76th Street starts at Riverside Drive and ends at Central Park West (see red line on map above). It is important to note that when makes a query for a full street, the 'onStreet' and 'borough' paramters are required.
Below is a list of response parameters that may be returned in the response for the address search
function in LocateNYC. Most of these parameters are derived from the NYC Geosupport software. Some of
the parameters are returned from LocateNYC software only.
These two fields are non-blank only if this blockface has addresses of both parities (the parity of a number is its attribute of being odd or even). Such a blockface is said to have ‘continuous parity’. If the blockface has continuous parity, the Continuous Parity Indicator is non-blank, the Low and High House Number fields contain the address range for one parity, and the Alternate Low and High House Number fields contain the address range for the other parity. (Which parity is in which set of house number fields is unpredictable.)
This flag indicates either that the input address is in Marble Hill or Rikers Island and the alternative (rather than the legal) borough was specified (see UPG Chapter V.7), or that the input address is on Ruby Street in Brooklyn but it was specified using the alternative (Queens) street name 75 Street (see UPG Chapter V.8). This field was also known as the Marble Hill / Rikers Island Flag.
An atomic polygon is an un-subdivided polygon . Atomic polygons are created based on the New York City CSCL (Citywide Street Centerline) database. Atomic polygons are numbered uniquely within census tract.
The first 6 bytes of the standard BBL consists of the 1-byte borough code followed by the 5-byte tax block field, which contains the tax block value right-justified and zero-filled. The last 4 bytes of the standard BBL is the standard tax lot field, which contains the tax lot value right-justified and zero-filled. See Chapter VI.8. The BBL (‘borough-block-and-lot’) identifies a parcel of real property in New York City, called a tax lot. The BBL is composed of the concatenation of the Borough Code, Tax Block and Tax Lot. If the property is a condominium (indicated by the Condominium Flag), the WA2 BBL field contains the billing BBL of the condominium (see Chapter VI.4).
The first 6 bytes of the standard BBL consists of the 1-byte borough code followed by the 5-byte tax block field, which contains the tax block value right-justified and zero-filled. The last 4 bytes of the standard BBL is the standard tax lot field, which contains the tax lot value right-justified and zero-filled. See Chapter VI.8. The BBL (‘borough-block-and-lot’) identifies a parcel of real property in New York City, called a tax lot. The BBL is composed of the concatenation of the Borough Code, Tax Block and Tax Lot. If the property is a condominium (indicated by the Condominium Flag), the WA2 BBL field contains the billing BBL of the condominium (see Chapter VI.4).
The first 6 bytes of the standard BBL consists of the 1-byte borough code followed by the 5-byte tax block field, which contains the tax block value right-justified and zero-filled. The last 4 bytes of the standard BBL is the standard tax lot field, which contains the tax lot value right-justified and zero-filled. See Chapter VI.8. The BBL (‘borough-block-and-lot’) identifies a parcel of real property in New York City, called a tax lot. The BBL is composed of the concatenation of the Borough Code, Tax Block and Tax Lot. If the property is a condominium (indicated by the Condominium Flag), the WA2 BBL field contains the billing BBL of the condominium (see Chapter VI.4).
As of Release 16D, Bike Lane has 11 codes, instead of 7. A new two-byte field, BIKE LANE 2, is being introduced. The original one-byte Bike Lane field still exists to give users a chance to update their applications. In the one-byte Bike Lane field, the value ‘A’ will appear when the new code is ‘10’, and the value ‘B’ will appear when the new code is ‘11’. We recommend that users update their applications to refer to the new Bike Lane-2 since the one-byte Bike Lane field will be deleted in a later release.
Defines which street segments are part of the bicycle network as defined by the Department of Transportation. Note: As of Geosupport Version 16.4, Bike Lane 2 is being introduced to replace Bike Lane
Left Blockface ID is a ten digit number identifying the block face on the left hand side of a segment. Correspondingly, Right Blockface ID identifies the block face on the right hand side of a segment. Block Face is defined as one continuous side of a physical block that is intersected on that side by two other physical through streets. Blockface IDs were established by DoITT’s consultants working on the planimetric feature classes for NYC and are not maintained by the Department of City Planning.
The Browse Flag allows users to request the return of primary or principal output street names and street codes (for Functions 1, 1A, 1B, 1E, 1N, 2, 3, 3C and AP). The Browse Flag also allows users to request the return of preferred output street names and street codes (for Functions 1, 1A, 1B. 1E, 2, 3, 3C and AP).
1,1E (MSW: Long WA2 Only),1,1E(COW),2,3 (MSW: Long WA2 Only),3(COW),3C
Field Length:
4
Field Format:
4 bytes, numeric
Field Status:
Active
Description:
When appended by the CENSUS BLOCK SUFFIX, this area is the smallest geographic area defined by the U.S. Census Bureau for tabulating the census. Generally (but not always) corresponds to a physical city block. Each census block is numbered uniquely within its census tract.
1,1E (MSW: for 2010 - Regular WA2),1,1E(COW),2,3 (MSW: Long WA2 Only),3(COW),3C
Field Length:
4
Field Format:
4 bytes, numeric
Field Status:
Active
Description:
When appended by the CENSUS BLOCK SUFFIX, this area is the smallest geographic area defined by the U.S. Census Bureau for tabulating the census. Generally (but not always) corresponds to a physical city block. Each census block is numbered uniquely within its census tract.
6 bytes, consisting of numeric 4-digit root followed by numeric 2-digit suffix. The root subfield is RJBF and the suffix subfield is RJZF if any. If the tract number contains no suffix, then the suffix subfield is blank.
Field Status:
Active
Description:
Geographic area defined by the U.S. Census Bureau for the various decennial censuses. Census tracts for a particular census year are numbered uniquely within borough.
6 bytes, consisting of numeric 4-digit root followed by numeric 2-digit suffix. The root subfield is RJBF and the suffix subfield is RJZF if any. If the tract number contains no suffix, then the suffix subfield is blank.
Field Status:
Active
Description:
Geographic area defined by the U.S. Census Bureau for the various decennial censuses. Census tracts for a particular census year are numbered uniquely within borough.
6 bytes, consisting of numeric 4-digit root followed by numeric 2-digit suffix. The root subfield is RJBF and the suffix subfield is RJZF if any. If the tract number contains no suffix, then the suffix subfield is blank.
Field Status:
Active
Description:
Geographic area defined by the U.S. Census Bureau for the various decennial censuses. Census tracts for a particular census year are numbered uniquely within borough.
The Coincident Segment Count indicates the situation where one road is above another road. Most streets, such as Broadway in Manhattan have a value of ‘1’ in the Coincident Segment Count. However, there are a few streets where the Coincident Segment Count is greater than one. An example of this is Third Avenue and the Gowanus Expressway in Brooklyn. The Gowanus Expressway is above Third Avenue from about 18th Street until 63rd Street. For these segments, the Coincident Segment Count is ‘2’.
3 bytes. Numeric. The first byte is the Community District Borough Code, and the second and third bytes are the Community District Number, RJZF.
Field Status:
Active
Description:
There are 59 community districts in the City of New York, as well as 12 Joint Interest Areas (JIAs). The JIAs are major parks and airports that are not contained within any CD. Examples are Central Park, Van Cortlandt Park, LaGuardia and JFK Airports. The JIAs are the numerically highest items in each borough.
Coded Values:
Code
Meaning
101-112
Manhattan except Marble Hill
164
Central Park
201-212
Bronx except Rikers Island (Note: the Marble Hill section of Manhattan is in Bronx CDs 7 and 8)
226
Van Cortlandt Park
227
Bronx Park
228
Pelham Bay Park
301-318
Brooklyn
355
Prospect Park
356
Brooklyn Gateway National Recreational Area
401-414
Queens (Note: the Rikers Island section of the Bronx is in Queens CD 1)
In the case of Function 2, the compass direction identifies, for a pair of input streets that intersect at two distinct locations, which of those two intersections is to be processed. (See Chapter VII.2) In the case of Function 3C, the compass direction identifies which side of the street is to be processed. (See Section VII.5) In the case of Function 3S, if the ‘on’ street intersects the first cross street at two distinct locations, the compass direction identifies which of those two intersections is to be processed. (See Chapter VII.6)
If the ‘on’ street intersects the second cross street at two distinct locations, this compass direction identifies which of those two intersections is to be processed. (See Chapter VII.6)
An 'address range' is a sequence of house numbers along an 'on' street between (and including) a Low House Number and a High House Number. Every address range has one of three possible parities: odd, even or continuous. An address range of odd parity consists of all odd house numbers along the 'on' street between the Low and High House Numbers. An even-parity range consists of all even house numbers between the Low and High House Numbers. A continuous-parity range consists of all house numbers (both even and odd) between the Low and High House Numbers. Most New York City block faces contain an address range that is either of even or odd parity. However, some block faces have a continuous-parity address range, usually where the opposite side of the street is non-addressable because it is a park, a body of water, etc. Some examples of the continuous parity case in Manhattan are Central Park West (the east side of the street runs along Central Park and is non-addressable, while the west side has both odd and even addresses); Riverside Drive; and the portion of Fifth Avenue that runs alongside Central Park. If a New York City block face has a continuous parity address range, Geosupport represents this range as two separate ranges, an odd-parity range and an even-parity range. The practical effect of this depends on the Geosupport function. For Functions 1 and 1E, if an input address lies on a continuous-parity block face, only the range (i.e., the Low and High House Numbers) whose parity is the same as that of the input address is returned in WA2. For Function 3, if an input street segment contains a continuous parity address range, both the odd and the even ranges are returned, in the WA2 fields called Left Low House Number and Left High House Number for the range of one parity, and in the fields Right Low and High House Numbers for the range of the other parity; note that in this case, in reality both the odd and the even ranges are on the same side of the street, even though they are returned in fields called 'left' and 'right'. For Function 3C, if an input block face is on a street segment containing a continuous parity address range (regardless of whether the input block face is on the addressable or the non-addressable side of the segment), both the odd and the even ranges are returned, in the WA2 fields called Low House Number and High House Number for the range of one parity, and in the fields Alternate Low House Number and Alternate High House Number for the range of the other parity. The field Continuous Parity Indicator indicates, for Functions 1, 1B, 1E, 3 and 3C, whether the street segment containing or corresponding to the user input is of the continuous parity type, and if so, which side of the segment is addressable.
Coded Values:
Code
Meaning
Blank
The street segment does not have a continuous parity address range
L or R
The street segment has continuous parity. In this case, the Continuous Parity Indicator indicates which side of the street segment, the left or the right, is addressable. (Left and right are specified with respect to the direction of increasing addresses along the segment)
This field is non-blank when the street segment lies along a borough boundary. The value of this field indicates which side of the segment is out of borough.
CROSS STREET NAMES FLAG (a.k.a. EXPANDED FORMAT FLAG)
Geosupport Functions:
1,1E,2,3,3C,1B (COW)
Field Length:
1
Field Format:
1 byte
Field Status:
Active
Description:
This field is non-blank when the street segment lies along a borough boundary. The value of this field indicates which side of the segment is out of borough.
This flag indicates the relationship between the order in which the user specified the input cross streets and the direction of increasing addresses along the ‘on’ street.
Coded Values:
Code
Meaning
R
The direction from Street Name 2 to Street Name 3 is opposite to the direction of increasing addresses
Blank
The direction from Street Name 2 to Street Name 3 (the two input cross street fields) conforms to the direction of increasing addresses
This flag indicates whether the given geographic feature segment is in reality curved. If so, the curve may be an arc of a circle or an irregular curve. When the segment specified by the input data is an arc of a circle, Functions 1 and 1E return Spatial Coordinates that are positioned relative to this arc rather than to the segment’s chord (the imaginary straight line joining the curved feature’s endpoints). When the segment specified by the input data is an irregular curve, Functions 1 and 1E return blanks in the Spatial Coordinate fields (q.v.), and issue a warning with Reason Code value ‘P’. In the case of Functions 3 and 3C, if the input data define a street stretch encompassing more than one segment (because of a T-intersection or bend), the Curve Flag is set ‘on’ (non-blank) if at least one of the constituent segments of the stretch is curved. See also discussion of Segment Length.
Coded Values:
Code
Meaning
I
Segment is an irregular curve, i.e., it is curved but it is not an arc of a circle
L
Segment is an arc of a circle on the left side of the line joining the segment’s FROM and TO nodes
R
Segment is an arc of a circle on the right side of the line joining the segment’s FROM and TO nodes
Identifies the local group of street names designated by the Department of City Planning as ‘preferred’ for display purposes for a specific location on a street.
DEPARTMENT OF SANITATION (DSNY) SNOW PRIORITY CODE
Geosupport Functions:
1/1E,1/1E Extended,1B,3,3 Extended,3C,3C Extended
Field Length:
1
Field Format:
1 byte character
Field Status:
Not Implemented
Description:
DSNY (Department of Sanitation) Snow Priority code is used during snow emergencies. It helps DSNY to determine the snow removal schedule, routes and resources needed. The DSNY (Department of Sanitation) Snow Priority indicates the priority of the street with respect to snow removal. New snow priority codes were assigned with Version 16.4 The snow priority codes are as follows:
Coded Values:
Code
Meaning
C
Critical. These routes are comprised of highways (main beds, entrances, exits interchanges), arterial roadways, main travel thoroughfares (single lane and multi-lane), bus routes, that contain emergency services & first responder facilities (Hospitals, EMS, FDNY, NYPD) and schools.
S
Sector. Designed to encompass all streets that are not classified as Critical Streets and are wide enough to accommodate a full size DSNY collection truck with a plow attached.
H
Haulster. Designed to service dead ends and streets that cannot be serviced with a collection truck or salt spreader with a plow attached due to narrow street width or tight turning radius (either entering or exiting the street).
A dogleg is a street configuration in which a street has a displacement or offset as it crosses another street. A non-blank value in the Dogleg Flag indicates that at least one of the cross streets forms a dogleg as it crosses the ‘on’ street, in such a way that at least one side of the ‘on’ street has a blockface encompassing more than one segment. When Function 3 returns a non-blank value in this flag, the work area represents the ‘innermost’ segment of the dogleg configuration. The Dogleg Flag value indicates which side or sides of the street has (or have) the long blockface(s). A Function 3C call will return information on the long blockface when the user input data specifies a side of a street where there is a long blockface formed by a dogleg or doglegs. The Dogleg Flag will not be set in response to a function 3C call.
Coded Values:
Code
Meaning
B
Both sides of the ‘on’ street have long blockfaces formed by doglegs. This can only occur if both cross streets form doglegs as they cross the ‘on’ street.
L
The left side of the street has a long blockface formed by a dogleg
R
The right side of the street has a long blockface formed by a dogleg
DYNAMIC BLOCK (will be replaced by ATOMIC POLYGON)
Geosupport Functions:
1,1B,1E,3 (MSW: Long WA2),3 (COW Only),3C
Field Length:
3
Field Format:
3 bytes RJZF
Field Status:
Active
Description:
An atomic polygon is an un-subdivided polygon . Atomic polygons are created based on the New York City CSCL (Citywide Street Centerline) database. Atomic polygons are numbered uniquely within census tract.
A set of districts defined by the NYC Board of Elections to conduct elections. There are approximately 6,000 Election Districts (EDs) in NYC. Each ED is numbered uniquely within its Assembly District. All of NYC’s higher-level political districts, namely Assembly Districts, City Council Districts, Municipal Court Districts, Congressional Districts and State Senatorial Districts, are defined as aggregates of Eds.
A Face Code is assigned to each linear geographic feature represented in the LION file. These consist of streets and certain non-street features, such as census boundaries, shorelines and railroad tracks. Face Codes serve as part of LION keys, which identify a unique LION record. Face Code values are assigned uniquely within borough.
The smallest kind of administrative fire district defined by the NYC Fire Department. There are three types, indicated by the Fire Company Type: engine companies, Squad and ladder companies.
A node is an endpoint of a geographic feature segment represented in CSCL/LION. Most nodes are points where a feature bends or terminates or where two features intersect in CSCL/LION. Each node has a node ID assigned to it, which is unique in the entire city. Node ID assignments are permanent; if a node is deleted from CSCL, its node ID is retired and is never reassigned to a different node. A Node ID may be used to identify an intersection or the end points of a segment. An end point node is often referred to as a From Node or a To Node.
A gap exists along the ‘on’ street between this intersection and its predecessor
C
Real Streets Only have been requested, resulting in segment lengths being ‘Combined’ and one or more nodes being omitted between this intersection and its predecessor in the list (COW Only).
D
A dog-leg type gap exists along the ‘on’ street between this intersection and its predecessor
N
A new stretch exists.
Blank
No gap, i.e., the ‘on’ street connects this intersection with its predecessor in list. The gap flag in the 1st entry in the list is always blank.
This flag indicates that the geography defined by the input ‘on’ street and two cross streets is not a conventional street segment. There are several cases: a segment one of whose cross-features is a pseudo-street name (codes C, D); a street stretch formed by consolidating more than one consecutive LION segment (codes B, L, M, R, S and T); or a segment that is part of such a street stretch (types F, G). If the input data simultaneously satisfy the criteria for a Generated Record Flag value of C or D and for some other value, the flag contains the value other than C or D.
Coded Values:
Code
Meaning
B
Record has been generated by consolidating several LION segments to represent a stretch of a street where there is a node that is not at an intersection, such as a bending point (or a consecutive sequence of such nodes).
C
Record generated because one or both nodes of segment lie on the City Limit (Bronx-Westchester or Queens-Nassau border), but segment itself lies entirely within the City. The cross street list for a node on the City Limit contains the special street code assigned to the pseudo-street name CITY LIMIT in the Bronx or Queens, as appropriate.
D
Record has been generated for a dead end segment, i.e. a segment at least one of whose nodes either has no other segments incident at it, or has segments of non-street features only. The cross street list at such a node contains only the special street code assigned to the pseudo-street name DEAD END in the given borough.
F
Record represents a segment that is part of a street stretch that either contains a bending point at which there are no cross streets, or the left side of which is the long blockface of a T-intersection or a consecutive sequence of T-intersections.
G
Record represents a segment that is part of a street stretch, that either contains a bending point at which there are no cross streets, or the right side of which is the long blockface of a T-intersection or a consecutive sequence of T-intersections.
L
Record has been generated to represent the long blockface on the left side of a T-intersection.
M
Record has been generated by consolidating two or more LION segments to represent a stretch of a street containing a node or a consecutive sequence of nodes at which the ‘on’ feature intersects with no streets but intersects with more than one type of non-street feature.
R
Record has been generated to represent the long blockface on the right side of a T-intersection.
S
Record has been generated by consolidating two or more LION segments to represent a stretch of a street containing a node or a consecutive sequence of nodes at which the ‘on’ feature intersects with no streets but intersects with one or more shorelines.
T
Record has been generated by consolidating two or more LION segments to represent a stretch of a street containing a node or a consecutive sequence of nodes at which the ‘on’ feature intersects with no streets but intersects with one or more train tracks.
From NYC LION. A unique ID assigned in order to aggregate granular geometry to represent a Generic view of the city's street network. Streets that contain multiple carriageways or roadbeds (such as Queens Boulevard in Queens and Park Ave in Manhattan) are represented by multiple centerlines corresponding to each roadbed as well as an imaginary 'single' generic centerline.
Geosupport has an elaborate apparatus to support application problem-handling. There are three output fields in Work Area 1 that are used to inform calling applications of the outcome of each call to Geosupport. These fields are the Geosupport Return Code (GRC), the Reason Code and the Message. A comprehensive list of GRCs, Reason Codes and Messages is contained in UPG Appendix 4.
Coded Values:
Code
Meaning
00
indicates unconditionally successful completion
01
indicates a warning condition.
Values other than 00 or 01
signifies unsuccessful completion, or rejection, caused by either a system error or a user error
Districts defined by the NYC Department of Health and used to report statistics on births, deaths, communicable diseases etc. Health Areas are aggregates of Census Tracts.
If the field name indicates the house number is normalized, for MSW it is in HNI format, and for COW it is in HNS format; otherwise, it is in HND format (see Chapter V.2).
The Department of Education has divided the city into Instructional Regions which group together two or more Community School Districts for administrative purposes. (Instructional Regions have also been known as Instructional Divisions.)
INTERIM ASSISTANCE ELIGIBILITY INDICATOR (IAEI) - a.k.a. CD Eligibility Flag
Geosupport Functions:
1,1E,2 (COW only),3,3C,1B
Field Length:
1
Field Format:
1 byte
Field Status:
Active
Description:
Indicates whether the input location is in a census tract that meets the U.S. Department of Housing and Urban Development (HUD) criteria to be eligible for Community Development Block Grant (CDBG) funding. A census tract is eligible for CDBG funding if at least 51.00% of the residents are low- and moderate-income persons (less than 80% of the Median Family Income) and 50% of its total floor area must be comprised of residential usage. All other census tracts are ineligible. In Release 19B, the 'CD Eligibility' values were updated to reflect more current data. Updated income data was provided by HUD and residential usage was calculated by the Department of City Planning (DCP) using PLUTO data (18v2.1).
Coded Values:
Code
Meaning
E
Input location is in a CD-eligible census tract
I
Location is not in a CD-eligible census tract
Blank
Location is in a census tract, the CD-eligibility status of which is unknown to the Geosupport System.(Note: This is an error condition and should be reported).
1/1E Extended,all variations of 1A/BL/BN (viz. Regular, Long and Extended),1B,2W,3 Extended,3C Extended
Field Length:
9
Field Format:
9 bytes
Field Status:
Active
Description:
Spatial coordinates based on the lines of latitude and longitude. Lines of latitude measure the north-south position between the poles with the equator defined as 0 degrees. Lines of longitude (or meridians) measure the east-west position, with the prime meridian running through Greenwich, England. For NYC, Latitude is always positive and Longitude is always negative. The latitude and longitude of a location are calculated based on the spatial coordinates (x,y) returned for that location. As a result, the latitude and longitude returned by the Address Processing functions (e.g. 1/1E Extended) will be somewhat different from the values returned by Tax Lot and Building processing functions (e.g. 1A/BL/BN). See also SPATIAL COORDINATES and SPATIAL COORDINATES OF THE TAX LOT CENTROID.
A LION Face Code is assigned to each linear geographic feature represented in the LION file. These consist of streets and certain non-street features, such as census boundaries, shorelines and railroad tracks. Face Codes serve as part of LION keys, which identify a unique LION record. Face Code values are assigned uniquely within borough.
The LION Key identifies a record in the CSCL file and relates to predecessor file known as LION. It consists of: BOROUGH CODE ( 1 byte), FACE CODE (4 bytes), SEQUENCE NUMBER (5 bytes)
A node is an endpoint of a geographic feature segment represented in CSCL/LION. Most nodes are points where a feature bends or terminates or where two features intersect in CSCL/LION. Each node has a node ID assigned to it, which is unique in the entire city. Node ID assignments are permanent; if a node is deleted from CSCL, its node ID is retired and is never reassigned to a different node. A Node ID may be used to identify an intersection or the end points of a segment. An end point node is often referred to as a From Node or a To Node.
Identifies a CSCL/LION record uniquely within Face Code. Generally,Sequence Numbers are assigned in the geographic order in which the corresponding segments occur along the geographic feature identified by the given face code. The Borough Code, Face Code and Sequence Number concatenated form the LION key, which serves as a unique identifier for one CSCL/LION record.
40 bytes, numeric, consisting of 5 slots for intersecting B7SCs.
Field Status:
Active
Description:
For each intersecting street, this is a list of up to five B7SCs, starting, in general (see Note below), with the lowest B7SC, followed by the next lowest, followed by the remaining B7SCs in ascending order. The purpose of the ordering of the first two street codes is to facilitate the ability of users to form consistent keys for geographic retrieval of application data. Note 1: In order to provide the user with the most meaningful information, ‘normal’ streets will be listed first, followed by ‘special’ streets, such as Ramps and Exits. Railroads, Shorelines and Borough Boundaries will appear next, followed by Named Intersections, CITY LIMITs, DEAD ENDs and BENDs. This will occur even if the ‘special’ streets have lower street codes than the ‘normal’. Note 2: To avoid unnecessary listing of BENDs, Function 3S lists a BEND only if the angle of the bend is 60 degrees or more. (Prior to Release 16D, a bend was listed if the angle was 20 degrees or more.) Also, a bend is not included in the list of cross streets when another real street intersects there as well. Note 3: Since Function 3S returns B7SCs, it is now possible for two streets to have the same B5SCs and different B7SCs, e.g. in Brooklyn, at the intersection of Clinton Street with Livingston Street and Aitken Place, Livingston Street and Aitken Place have the same B5SC (3-56530) but different B7SCs (3-56530-01 and 3-56530-02 respectively)
30 bytes, consisting of slots for up to five 6-byte B5SCs. ‘Empty’ slots contain either numeric zeros or blanks.
Field Status:
Active
Description:
A list of B5SCs, for up to five streets incident upon a delimiting node (endpoint) of a block face or street segment. The number of non-empty list entries is returned in the corresponding WA2 field NUMBER OF CROSS STREETS AT (LOW or HIGH) ADDRESS END. It is possible for the list to be entirely empty. If the node lies on a borough boundary, the list may contain streets from both boroughs. Subject to the space limitation, the list may include the input cross street corresponding to the given node, and may include the pseudo- streets 'City Limit', 'Dead End' and 'Bend'. The inclusion of 'Bend' in the list indicates that the node is a bending point of the 'on' street, not that it is a bending point of a cross street (although that may be true).
List of borough and 7-byte street codes, corresponding to the LIST OF STREET NAMES. The number of street codes in the list is returned in the WA1 output field NUMBER OF STREET CODES AND STREET NAMES IN LIST.
320 bytes, consisting of 10 fields for street names, each 32 bytes.
Field Status:
Active
Description:
This field is used by several Geosupport features (see below) to return a list of street names. The number of street names in the list is returned in the WA1 output field NUMBER OF STREET CODES AND STREET NAMES IN LIST. The similar names feature uses the List of Street Names to return up to ten street names deemed 'similar' to a rejected input street name (see UPG Section III.5). The browse functions, Functions BB and BF, use the List of Street Names to return up to ten normalized street names in alphabetical order as part of a street name browse (see UPG Section III.7). The local street name validation feature uses the List of Street Names to return up to four locally valid alias street names corresponding to a street name rejected as locally invalid (see UPG Section IV.5). The cross street names feature (see CROSS STREET NAMES FLAG) uses the List of Street Names to return street names corresponding to the street codes in the LIST OF CROSS STREETS (Functions 1, 1B, 1E, 3 and 3C) or the LIST OF INTERSECTING STREETS (Function 2). In the case of Functions 1, 1B, 1E, 3 and 3C, the first five 32-byte street name fields in the List of Street Names are used for the street names corresponding to the street codes in the LIST OF CROSS STREETS AT LOW ADDRESS END; the second five 32-byte street name fields in the List of Street Names are used for the street names corresponding to the street codes in the LIST OF CROSS STREETS AT HIGH ADDRESS END.
Local street name validity is reflected in the sixth and seventh digits of the 10SC, which constitute the Local Group Code (LGC). Street codes are assigned in such a way that two names for a street have the same LGC value if and only if those names are valid for the same portion (possibly all) of the street. Note that if two names are valid for overlapping portions of a street, or one is valid for a subset of the portion where the other is valid, then those names are in different local groups. In order to be in the same local group, names must be valid for exactly the same portion of the street. Conceptually, the set of all street names for a given street can be viewed as being partitioned into subsets called ?local street name groups?, each group identified by its LGC value and consisting of all the names that are valid for a particular portion (possibly all) of the street. (Most New York City streets only have one local street name group.) A LGC value is meaningful only relative to its B5SC value. The B5SC identifies the street, and the LGC identifies a local street name group for the given street, that is, the group of all names for the given street that are valid for a particular portion (possibly all) of the street. The B5SC concatenated with the LGC, that is, the first eight bytes of the B10SC, constitute the Borough and Seven-Digit Street Code (B7SC). Two street names have the same B7SC value if and only if they are names for the same street (same B5SC value) and are valid for the same portion of the street (same LGC value relative to the given B5SC value). For a detailed discussion of local group codes, street codes, and street names please see UPG Section IV.
1/1E Extended,all variations of 1A/BL/BN (viz. Regular, Long and Extended),1B,2W,3 Extended,3C Extended
Field Length:
11
Field Format:
11 bytes
Field Status:
Active
Description:
Spatial coordinates based on the lines of latitude and longitude. Lines of latitude measure the north-south position between the poles with the equator defined as 0 degrees. Lines of longitude (or meridians) measure the east-west position, with the prime meridian running through Greenwich, England. For NYC, Latitude is always positive and Longitude is always negative. The latitude and longitude of a location are calculated based on the spatial coordinates (x,y) returned for that location. As a result, the latitude and longitude returned by the Address Processing functions (e.g. 1/1E Extended) will be somewhat different from the values returned by Tax Lot and Building processing functions (e.g. 1A/BL/BN). See also SPATIAL COORDINATES and SPATIAL COORDINATES OF THE TAX LOT CENTROID.
This flag indicates either that the input address is in Marble Hill or Rikers Island and the alternative (rather than the legal) borough was specified (see UPG Chapter V.7), or that the input address is on Ruby Street in Brooklyn but it was specified using the alternative (Queens) street name 75 Street (see UPG Chapter V.8). This field was also known as the Marble Hill / Rikers Island Flag.
Indicates request for Extended Work Area 2 for the supported functions. These extended work areas contain street names in addition to Street Codes. Users no longer have to make separate D, DG, or DN calls to get the street names. In addition, CSCL data is returned in the extended Work Area 2. See [Appendix 13](/appendices/appendix13/) for the Work Area layouts. Also, see Chapter II.7.
Indicates the number of street names returned in the LIST OF STREET NAMES, corresponding to the number of street codes returned in the LIST OF STREET CODES.
The number of lanes in a carriageway (roadway) that are reserved for parking of vehicles. The number of parking lanes were determined by DoITT’s consultants working on the planimetric feature classes for NYC.
The total number of lanes in a carriageway (roadway) including travel lanes and parking lanes. The total number of lanes were determined by DoITT’s consultants working on the planimetric feature classes for NYC.
The number of lanes in a carriageway (roadway) that are designated for the movement of vehicles traveling from one destination to another. The number of travel lanes were determined by DoITT’s consultants working on the planimetric feature classes for NYC.
The Neighborhood Tabulation Areas (NTAs) are aggregations of census tracts that reflect the 2010 Census. The NTAs are assigned a 4-byte code and a 75-byte name. They are used by the Population Division of the Department of City Planning. See [Appendix 16](/appendices/appendix16/) for a description of the NTA’s history and significance. The first two bytes of the NTA code are an alphabetic borough code as follows: MN-Manhattan, BX-Bronx, BK-Brooklyn, QN-Queens, SI-Staten Island. The remaining two bytes are numeric and uniquely define the NTA.
The Neighborhood Tabulation Areas (NTAs) are aggregations of census tracts that reflect the 2010 Census. The NTAs are assigned a 4-byte code and a 75-byte name. They are used by the Population Division of the Department of City Planning. See [Appendix 16](/appendices/appendix16/) for a description of the NTA’s history and significance. The first two bytes of the NTA code are an alphabetic borough code as follows: MN-Manhattan, BX-Bronx, BK-Brooklyn, QN-Queens, SI-Staten Island. The remaining two bytes are numeric and uniquely define the NTA.
In order to support Neighborhood Policing, the NYC Police Department has divided each precinct into four or five fully-staffed Police Sectors. The Police Sectors correspond, as much as possible, to the boundaries of actual established neighborhoods. The Police Sector field consists of the Precinct Number followed by a letter, e.g. 114A.
PUMAs (Public Use Microdata Areas) are approximations of New York City's Community Districts which were developed for use with the Census Bureau's Public Use Microdata Samples (PUMS). In order to make the boundaries consistent with PUMAs, NTAs were created using whole census tracts, from the 2010 census, within PUMAs. For more information on the history and significance of NTAs and PUMAs, see Appendix 16. See also NEIGHBORHOOD TABULATION AREA (NTA) CODE
From NYC LION. A unique ID assigned in order to aggregate granular geometry to represent a Physical View of the city's street network. In CSCL, segmentation is very granular in order to accommodate many types of physical and non-physical geometry. The Physical ID is a unique number used to identify a physically existing piece of geometry that may or may not be comprised of several Segment IDs. For example, E 28 Street between 2nd Ave and 3rd Ave in Manhattan would have 1 Physical ID although there are 3 segments defining that block face, with 3 separate Segment IDs.
Geosupport has an elaborate apparatus to support application problem-handling. There are three output fields in Work Area 1 that are used to inform calling applications of the outcome of each call to Geosupport. These fields are the Geosupport Return Code (GRC), the Reason Code and the Message. The reason code is provided when a non '00' GRC is returned in order to provide more context to the warning or error condition. A comprehensive list of GRCs, Reason Codes and Messages is contained in UPG Appendix 4.
Indicates request for Roadbed information for roads that are divided into two or more roadbeds. If Roadbed information is requested for a street that is not divided, Geosupport returns the generic information. For functions 1 and 1E, the Segment Type Code will indicate the type of information that is being returned. For more information on function 3S see Chapter VII.6.
Coded Values:
Code
Meaning
Blank
Generic (non-roadbed) information requested (default)
SCHOOL DISTRICT (previously known as Community School District)
Geosupport Functions:
3,3C
Field Length:
3
Field Format:
3 bytes.
Field Status:
Active
Description:
This item represents the direction in which the segment lies on the earth’s surface, expressed as an angle in degrees measured counterclockwise from due east. The segment is considered to be pointing in the direction of increasing addresses, and the azimuth value can range from 0 to 359 degrees, inclusive. For example, a segment pointing due east has an azimuth of 0; one pointing due north has an azimuth of 90; one pointing due west has an azimuth of 180; one pointing halfway between due west and due south (i.e., pointing due southwest) has an azimuth of 225.
Except for curved segments (see Curve Flag), the Segment Length is computed from the Spatial Coordinates of the segment's endpoints, as digitized in the LION file. For curved segments, the Segment Length is computed by summing the lengths of the small straight line segments that approximate the curve in the GIS version of LION; this is a more accurate approximation to the true arc length of the curve than would be the segment's 'secant length', that is, the straight line distance between the curve's extreme endpoints. In the case of Functions 3 and 3C, if the input data define a street stretch encompassing more than one segment (because of a T-intersection or bend), the Segment Length returned is the sum of the lengths of the constituent segments of the stretch. In all cases, the Segment Length has a very approximate level of accuracy only, and should not be used in applications requiring high precision.
This item is a set of codes grouping the possible azimuth values of a segment into eight categories. The categories are approximately due north, south, east and west, and the four quadrants of the rectangular coordinate system for segments that do not lie approximately due north, south, east or west. 'Approximately' as used here means 'within 5 degrees'. In Manhattan, all orientation codes are defined with a 30‑degree clockwise shift (i.e., 30 is subtracted from the azimuth value) in order to conform to the conventional concept that the midtown streets and avenues lie due east‑west and due north‑south, respectively. For example, 'approximately due north' means 'within 5 degrees of due north'; for the boroughs other than Manhattan, this corresponds to the range of azimuth values from 85 to 95; in Manhattan, the corresponding azimuth value range is 55 to 65. There is a ninth orientation category, with a code value of ‘U’, meaning Geosupport could not determine the segment’s orientation because of a problem with the segment’s Spatial Coordinates. All occurrences of an orientation code of ‘U’ should be reported to Geographic Systems Section staff.
Coded Values:
Code
Meaning
U
Orientation is undefined.
E
Approximately due east. Manhattan: 325-335, Other Boroughs: 0-5 and 355-359
1
First quadrant, i.e. northeasterly. Manhattan: 336-359, Other Boroughs: 6-84 and and 0-54
N
Approximately due north. Manhattan: 55-65, Other Boroughs: 85-95
2
Second quadrant, i.e. northwesterly. Manhattan: 66-144, Other Boroughs: 96-174
W
Approximately due west. Manhattan: 145-155, Other Boroughs: 175-185
3
Third quadrant, i.e. southwesterly. Manhattan: 156-234, Other Boroughs: 186-264
S
Approximately due south. Manhattan: 235-245, Other Boroughs: 265-275
4
Fourth quadrant, i.e. southeasterly. Manhattan: 246-324, Other Boroughs: 276-354
This field indicates on which side of the street, left or right, the blockface containing the input address lies. Left and right are defined with respect to the direction of increasing addresses along the ‘on’ street.
Coded Values:
Code
Meaning
L
Block face is on left side of street with respect to direction of increasing address
SPATIAL COORDINATES (See also SPATIAL COORDINATES OF TAX LOT CENTROID)
Geosupport Functions:
1,1B (blockface information),1E,2,3 Extended,3C Extended,AP (For Function 1A, BL, BN, 1B (property level information) see also SPATIAL COORDINATES OF TAX LOT CENTROID)
Field Length:
7
Field Format:
Spatial coordinates consist of two fields, an X Coordinate and a Y Coordinate, each 7 bytes RJZF.
Field Status:
Active
Description:
Spatial coordinates are a pair of numbers that specify a location on the earth’s surface. Geosupport returns spatial coordinates for an input address (Functions 1, 1B (blockface information), 1E, and AP), intersection (Function 2), and nodes at the end of a blockface (Functions 3 Extended and 3C Extended). Spatial coordinates are often used in conjunction with separate computer mapping and Geographic Information System (GIS) software to generate maps and for spatial analysis, although the Geosupport System does not itself provide users with such capabilities. Note: For Functions 1, 1B (blockface information) and 1E, the spatial coordinates that Geosupport returns are imprecise approximations of real-world locations, and are not appropriate for use in applications that require a high level of spatial accuracy. Spatial coordinates are expressed various geodetic coordinate systems, of which latitude/longitude is a well-known example. The coordinate system that Geosupport uses is known as the State Plane Coordinate (SPC) system. The SPC system is based upon the fact that, in a small enough geographic area, the earth’s surface can be assumed to be flat without introducing a significant error. In the SPC system, each state of the U.S. is subdivided into zones small enough to model as planar areas. In each SPC zone, a Cartesian coordinate system is established, with the X and Y coordinate axes oriented due east and due north, respectively, and the origin selected to be a point well to the southwest of the entire zone. (The origin is so selected to insure that the X and Y coordinates of all points within the zone are positive values.) The SPC zone that New York City is in, and which Geosupport uses, is called the New York-Long Island zone, NAD 83. In the SPC system, one unit of X or Y represents one foot of distance on the ground. A major advantage of the SPC system over other map projection systems is the ease of calculating the distance between two points. In the case of Functions 1, 1B (blockface information) and 1E, if the street segment on which the input address lies is a straight line segment or an arc of a circle, Geosupport computes and returns output spatial coordinates using a complex algorithm, a detailed description of which is beyond the scope of this document. If, however, the input address lies on a irregularly curved geographic feature (see Curve Flag), Functions 1, 1B (blockface information), and 1E return blanks in the spatial coordinate fields. Functions 1, 1B (blockface information), and 1E’s spatial coordinates algorithm produces a point position based on how the input address is prorated with respect to the administrative address range allocated to the entire blockface. In addition, the computed point is positioned slightly set off from the segment, on the side of the street where the input address is located. This offset is graphically desirable and also insures that the point will fall within the interiors of the proper political and administrative district boundary polygons for the given address. The computed point is a rough approximation to the location of the input address, intended to be used only for thematic mapping and other purposes that do not require a high level of spatial accuracy. The spatial coordinates returned by Functions 1/1E/1B (blockface information) for NAPs and Vanity Addresses (see Chapter V.9) were an estimate calculated by Geosupport. As of Version 11.2, Geosupport will use the Citywide Street Centerline file (CSCL) X-Y Coordinates. The CSCL information guarantees that the X-Y coordinates fall within the actual location of the NAP or Vanity Address. In the case of Function 2, the spatial coordinates returned are those of the LION node that corresponds to the input street intersection. Those coordinates represent an approximate center point of the intersection. In the case of Function 3 Extended and Function 3C Extended, the spatial coordinates returned are those of the nodes at the end of the blockface. Those coordinates represent an approximate center point of the intersection. In the case of Function AP, the spatial coordinates returned are those of the Address Point which is within 5 feet of the entrance(s) of the building. In the case of Functions 1A, BL, BN, 1B (property level information),the spatial coordinates returned are those of the Tax Lot Centroid. See SPATIAL COORDINATES OF THE TAX LOT CENTROID.
The Speed Limit field contains the speed limit, in miles per hour, of the paved area of the input location. Speed Limit data was provided by the NYC Department of Transportation and currently does not cover the entire city. Additional data will be made available in future releases.
Specifies the maximum length in bytes within which Geosupport is to normalize street names. The minimum and maximum permissible SNL values are 4 and 32. The default that is in effect if the application does not specify an SNL value is 32
The width, in feet, of the paved area of the street. Street Width contains the width at the narrowest part of the street. If the width is consistent along the street segment then both values are identical.
The width, in feet, of the paved area of the street. Street Width Maximum contains the width at the widest part of the street. If the width is consistent along the street segment then both values are identical.
This indicator specifies which work area layouts are to be used in an API call. Note: This indicator is also known as the Platform Indicator.
Coded Values:
Code
Meaning
C
The platform-independent work areas known as the Character-Only Work Areas (COWs) are used. These contain no packed decimal fields. For information on using COWs on the mainframe and the differences from the MSWs, see [Appendix 12](/appendices/appendix12/). For the work area layouts of the COWs, see [Appendix 13](/appendices/appendix13/).
Blank
The IBM mainframe specific work areas (MSWs) are used. The MSWs contain packed decimal fields. In general, these work areas are the ones described throughout this manual
U.S. Postal Service’s 5-digit ZIP code. ZIP code may also be used as input with functions 1, 1A, 1B, and 1E to identify the borough or Duplicate Address Pseudo-Street name (DAPS).
LocateNYC locator name. This is the internal locator that was used to locator the coordinates. This parameter is added for Esri reverseGeocode standardization.
The type of address that was returned in the reverse geocode. This will be 'PointAddress' if an address point locator was used. It will be 'StreetAddress' if an address interpolation was used. This parameter is added for Esri reverseGeocode standardization.
Match score. Indicates strength of match with 100 being the highest and 0 being the lowest (no match). This parameter is added for Esri reverseGeocode standardization
This indicates the Projected Coordinate System or the Geographic Coordinate System used to locate geographic features in the map. For a list of projected coordinate systems please see https://developers.arcgis.com/rest/services-reference/projected-coordinate-systems.htm. For a list of geographic coordinate systems please see https://developers.arcgis.com/rest/services-reference/geographic-coordinate-systems.htm
This indicates the Projected Coordinate System or the Geographic Coordinate System used to locate geographic features in the map. For a list of projected coordinate systems please see https://developers.arcgis.com/rest/services-reference/projected-coordinate-systems.htm. For a list of geographic coordinate systems please see https://developers.arcgis.com/rest/services-reference/geographic-coordinate-systems.htm. Identifies the current wkid value associated with the same spatial reference. For example a WKID of '102100' (Web Mercator) may have a latestWKid of '3857' since '102100' is deprecated.
demo
sign up
powered by
