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.
This page focuses on searching for tax lots using the NYC borough, block, and lot number (BBL). For a discusson of address and place search
please see the Address Search page. According to the NYC
Geosupport User Programming Guide (2019), the city’s tax geography is designated and modified by the New York City Department of Finance (DOF). The tax geography consists of the subdivision of the territory of the city (excluding city-owned land that is mapped for streets) into tax blocks, each of which is further subdivided into one or more tax lots.
Each tax block is identified, uniquely within its borough, by a tax block number assigned by DOF. Each tax block can consist of one, more than one, or a portion of one physical city block.
Each tax lot is identified, uniquely within its tax block, by a tax lot number assigned by DOF. For a more complete discussion of BBL please refer to the
NYC Planning Page for Tax Lots and BBLs.
The BBL consists of a 10 byte integer comprised of 3 numeric sequences which representing the borough (digit 1), block (digit 2-6), and lot (digit 7-10).
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.
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'.
When searching for a tax lot that has more than one building, LocateNYC will return information about all of the buildings that are within the tax lot. The buildingIdentificationNumber attribute will be arbitrarily picked. The full list of BINs will be listed in the giBuildingIdentificationNumberX field, which corresponds to the avaialble address ranges for each building. Since there may be many address ranges within each building, the same BIN may be listed more than once. In the example above, there are 3 buildings on the selected (see map above) tax lot: 4446424, 4446426, and 4594687.
Below is a list of response parameters that may be returned in the response for the BIN 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.
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.
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).
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).
Building Identification Number. A permanent BIN is a seven-digit numerical identifier unique to each building in the City of New York. The first digit is the Borough Code. There are also two types of temporary BINs; those maintained by the Dept. of Buildings (DOB) and those maintained by the Dept. of City Planning (DCP). The temporary BINs assigned by DOB contain the number ‘8’ as the second digit, and the temporary BINs assigned by DCP contain a ‘9’ in the same position. DCP is currently in the process of phasing out all of its temporary BINs.
The Business Improvement District (BID) field (which was requested by the Fire Department) consists of a borough and five-digit street code (B5SC). Function D may be used to obtain the 32-byte name of the BID. The ‘Street Attribute Indicator’ is set to ‘C’ for BIDs. An example of a Business Improvement District is ‘5 AVE BID’ Note that a BID may not be used as input to Function 1, 1A, 1B, 1E, 2*, and 3*.
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.
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
INTERNAL LABEL POINT a.k.a. SPATIAL COORDINATES OF THE TAX LOT CENTROID
Geosupport Functions:
1A,BL,BN,1B (COW only)
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:
Note: Internal Label Points and Annotation Points are no longer used They are replaced by Tax Lot Centroid. The Tax Lot Centroid is created in ESRI’s ArcGIS software using the Department of Finance’s Digital Tax Map (DTM). The coordinates associated with the Tax Lot Centroid are guaranteed to be within the property, unlike the coordinates returned by either Function 1 or Function 1E, where the Spatial Coordinates are an approximation based in the address range of the particular street the address is on. In addition, the Function 1/1E Spatial Coordinates always fall in the street bed and not within a tax lot, and most likely will not be adjacent to the tax lot the address is in. Additionally, when using Function 1A, the same coordinates will be returned no matter which of a tax lot’s addresses is used as input. There are a few properties which do not have a Tax Lot Centroid; consequently, no coordinates will be returned for these properties. See SPATIAL COORDINATES for a description of the coordinate system (SPC) used by Geosupport.
The Intersection Replication Counter is non-blank only if the two streets intersect more than once, in which case this field contains the number of such intersections.
Coded Values:
Code
Meaning
I
Tax lot is interior to physical block, i.e., it has no street frontages.
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.
756 bytes total, consisting of space for 21 36-byte entries, each entry having fields for the following data items: Low House Number of Address Range High House Number of Address Range, B5SC, DCP-Preferred LGC, BIN, Entry Type Code, Side of Street Indicator.
Field Status:
Active
Description:
The List of Geographic Identifiers (LGI) is intended to provide a comprehensive geographic profile of a tax lot by listing, so far as the information is known and space allows, all of the lot’s buildings; all of the street addresses and non-addressable street frontages of each building; all of the lot’s ‘vacant frontages’ (i.e., street frontages of the lot not associated with buildings); and any NAPs associated with the lot. The LGI contains space for up to 21 entries. The number of non-empty entries is indicated in the WA2 field NUMBER OF GEOGRAPHIC IDENTIFIERS. The types of entries that the LGI can contain are as follows (see table below)
Coded Values:
Code
Meaning
Blank
Address range. A real address range of a building on a given tax lot. There are values in the Low House Number, High House Number, B5SC, DCP-Preferred LGC, Side of Street Indicator and BIN fields. A single address is represented as an address range in which the low and high house numbers are identical.
B
NAUB. A Non-Addressable Un-named Building (NAUB) (see Chapter VI.3). The Low and High House Number and Side of Street Indicator fields are blank. The B5SC and DCP-Preferred LGC fields usually contain the street code and LGC, correspondingly, of the street nearest to or most accessible to the NAUB, but they may be blank. The BIN field contains a meaningful value. Note: If the NAUB has frontages on more than one street, there are multiple type B entries to represent all of the NAUB’s street frontages.
F
Vacant Street Frontage. A street frontage of the tax lot at which there are no buildings (including NAUBs) and to which no pseudo-addresses have been assigned. The Low and High House Number, BIN and Side of Street Indicator fields are empty. There are values in the B5SC and DCP-Preferred LGC fields.
G
NAP of a Complex. A Non-Addressable Place name (NAP) of a complex of buildings and/or other geographic features, usually on a large site or superblock (see Chapter III.6). The house number and BIN fields are empty. The B5SC, DCP-Preferred LGC, and Side of Street Indicator fields contain the values of these items assigned to the NAP.
N
NAP of a. A NAP of a building or other geographic feature that is not part of Simplex a complex (see Chapter III.6). The house number fields are empty. The B5SC, DCP-Preferred LGC, and Side of Street Indicator fields contain the values of these items assigned to the given NAP. The BIN field is non-empty only if the NAP represents a building.
Q
Pseudo-Address Range. A pseudo-address range assigned to a vacant street frontage of the tax lot. There are values in the Low House Number, High House Number, B5SC, DCP-Preferred LGC and Side of Street Indicator fields. A single address is represented as an address range in which the low and high house numbers are identical. The BIN field is empty
R
Real Street of a Vanity Address. Entry indicates the street and the side of that street on which the building entrance having a vanity address is really located and for which no other address for that building exists. For a discussion of vanity addresses, see Chapter V.9. In a type R entry, the Low and High House Number fields are empty, and there are non-empty values in the B5SC, DCP-Preferred LGC, Side of Street Indicator and BIN fields. Whenever the LGI contains a type R entry, it also contains a type V entry for the associated vanity address
V
Vanity Address. A vanity address or address range. For a detailed discussion of vanity addresses, see Chapter V.9. There are non-empty values in the Low House Number, High House Number, B5SC, DCP-Preferred LGC, Side of Street Indicator and BIN fields. A single address is represented as an address range in which the low and high house numbers are identical. Whenever the LGI contains a type V entry, it also contains an either an address range entry or a type R entry that indicates the street on which the associated building entrance is really located.
W
Blank-Wall Bldg Frontage. A building frontage along a street that is not associated with any addresses, such as some building facades with no entrances. The Low and High House Number and Side of Street Indicator fields are blank. There are values in the B5SC and DCP-Preferred LGC fields. The BIN field contains a meaningful value. Note: Type W entries exist only for buildings that also have at least one real address range entry. If a building has no real address ranges, the building is a NAUB, and its street frontages, if any, are represented by type B entries rather than type W entries.
X
NAP of a Constituent Entity of a Complex. A NAP of a constituent entity of a complex. (The NAP of the entire complex is represented by a separate entry of type G.) The house number fields are empty. The B5SC, DCP-Preferred LGC and Side of Street Indicator fields contain the values of these items assigned to the NAP. The BIN field is non-empty only if the NAP represents a building.
iF set to 'E' indicates that the number of geographic identifiers for the given tax lot exceeds 21, the maximum capacity of the List of Geographic Identifiers; otherwise it is blank. If this flag is set to 'E', the user can obtain a comprehensive list of BINs for the tax lot by using the long Work Area 2 option when calling the same function with the same input data.
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.
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.
This is a set of land use/building classification codes defined by the Real Property Assessment Division (RPAD) of the Department of Finance. If a tax lot has more than one building or land use, RPAD assigns the building class code they deem to describe best the ‘principal’ building or the ‘predominant’ land use on the tax lot. The values and meanings of this set of codes can be obtained from the Department of Finance.
This is an identification number assigned by the Department of Finance to each condominium in the city. It identifies the condominium as a whole and not a specific condominium unit.
For each BBL value, the Department of Finance has computed a Self-Check Code (SCC). This is a one-digit number computed from the BBL value using an algorithm chosen by DOF. The purpose of the SCC is to assist in validating key-entered BBLs. For more information on SCCs inquire to the information technology division of the Department of Finance. As of Geosupport Release 19C (on or about August 2019), the RPAD SCC fields will all contain blank values. In Release 19B the RPAD SCC for some BBLs may also be affected. Background information: The “RPAD SCC” values are derived from the Department of Finance’s (DOF) RPAD file. DOF’s new version of the RPAD file, now called the Property Master file, does not contain “RPAD SCC” values since DOF has phased them out. For Release 19B, Geosupport will continue to return existing “RPAD SCC” values based on the old RPAD file; however, with Release 19C, the “RPAD SCC” fields will all contain blank values.
The Volume field is 3 bytes (2-digit volume number + 1-digit character suffix). The Page field is 4 bytes (3-digit page number + 1-digit character suffix).
Field Status:
Active
Description:
The Sanborn Map Company maintains a 79 volume atlas of New York City geography that is widely used by New York city agencies. The atlases contain approximately 6000 maps covering all five boroughs
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 Department of Finance real property tax maps are organized into sections; each section is organized into volumes; and each volume consists of pages. Tax Map Section values are unique within borough
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
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
