Glossary of Term And Acronyms

Citations in brackets are references to sections of the UPG where the given term is defined or is principally discussed. Phrases in bold typeface have entries in this glossary.

A

ADDRESSABLE PLACE NAME [Chapter III.6]: A place name that can be combined with a house number to form an address. (Contrast with non-addressable place names.) Geosupport’s address-processing functions accept addressable place names as input data for the specification of an address. Some Manhattan examples are PENN PLAZA, WASHINGTON SQUARE VILLAGE and NEW YORK PLAZA.

ADDRESS / INTERSECTION TO MAP ZONES (AIMZ) [Chapter I.1]: A Geosupport CICS utility transaction that allows the user to enter an address, place name, intersection, tax lot identifier, or Building Identification Number and receive back a screen display of a set of map identifiers corresponding to the input location. The use of AIMZ requires no programming skills and AIMZ is not documented in detail in this UPG.

ADDRESS-PROCESSING FUNCTION [Chapter V]: Any of the Geosupport functions that accept the input of addresses. Currently, these are Functions 1, 1A, 1B, 1E and AP. Except for Function AP, address-processing functions also accept non-addressable place names as input data (typically with no input house numbers specified). The address-processing functions are a subset of the location-processing functions.

ALIAS [Chapter IV.2]: Two street names (or names of non-street geographic features) are aliases of each other if they are alternative names for the same street (or non-street feature) or any portion(s) thereof, or are spelling variants of the same street (or non-street feature) name. Partial street names are considered spelling variants, and therefore aliases, of the corresponding full street names. The alias relationship is embodied in the assignment of Geosupport street codes: two street names are aliases of each other if and only if they have the same borough-and-five-digit street code. Some examples of aliases in Manhattan: 6 AVENUE, SIXTH AVENUE, and AVENUE OF THE AMERICAS are all aliases of each other. SEVENTH AVENUE, 7 AVENUE, FASHION AVENUE and ADAM C POWELL JR BOULEVARD are all aliases of each other, even though some of these names are valid for differing portions of the street.

ALIASES (in GBAT) [Chapter XI.6]: User-defined street name aliases may be used in GBAT applications to supplement the set of street names that Geosupport recognizes. GBAT aliases are typically used to handle a consistent misspelling of a street name. The GBAT aliases are different from the Aliases described in Chapter IV.2.

AIMZ - see Address / Intersection to Map Zones

AP - AP is the name of Function AP and the acronym of Address Point (AP). It is also the acronym for Addressable Place Name (AP) and Atomic Polygon (AP). The acronym’s meaning should be clear by its usage. It is spelled out as needed.

API - see Geosupport Application Programming Interface

B

BACKGROUND COMPONENT [Chapter I.5]: The component of the Geosupport System in which GSS updates and validates geographic base files from which new releases of the foreground component files are periodically generated. The background component software and files are not directly accessed by users.

BBL (‘Borough/Block/Lot’) [Chapter VI.2]: A unique identifier for a parcel of real property, or tax lot, in New York City. The BBL is a 10-byte item formed by concatenating the one-byte borough code, five-byte tax block number and four-bye tax lot number. The New York City Department of Finance assigns tax block and tax lot numbers.

BEND [Chapter III.6]: A pseudo-street name that Geosupport accepts as street name input to specify a bending point of a street. Geosupport treats a point along a street as a bending point if the angle of the street at that point is not within the range 160-200 degrees, that is, if it is not within 20 degrees of a straight line.

BILLING BBL [Chapter VI.4]: A special BBL assigned by the Department of Finance to each condominium, to enable identification of the condominium in its entirety as distinct from the condominium’s individual units.

BIN - see Building Identification Number

BLOCK FACE (a.k.a. BLOCKFACE) [Chapter VII.3] A continuous frontage of a physical city block along one street, encompassing any bending points of the street within that frontage.

BUILDING IDENTIFICATION NUMBER (BIN) [Chapter VI.3]: A unique, immutable identifier for each building in New York City. BINs are not to be confused with addresses. BINs are assigned by the Geographic Systems Section (GSS) at the Department of City Planning.

C

CHARACTER-ONLY WORK AREA (COW) [Appendix 12, Appendix 13 and Appendix 14]: The Geosupport work areas that have long been in use are called the Mainframe-Specific Work Areas (MSWs). Most of the MSWs contain one or more packed decimal fields, a data encoding schema unique to IBM mainframes. An alternative set of Geosupport work areas was introduced in 2002. It is called the Character-Only Work Areas (COWs) which, as the name implies, contain character fields only. The COW is an essential part of a long-term effort to port the Geosupport System to other platforms. From now on, all new applications should be designed to use the COWs only. We also recommend that all existing applications be converted to use the COWs. See also Glossary entry for Work Areas.

CCO - See Corporation Council Opinion

CITY LIMIT [Chapter III.6]: A pseudo-street name that Geosupport accepts as street name input to refer to locations on the Bronx-Westchester County border, the Queens-Nassau County border, the New York-New Jersey border, and the Staten Island-New Jersey border.

CITYWIDE STREET CENTERLINE GEODATABASE - see CSCL

COMPACT FORMAT [Chapter III.3]: A Geosupport format for normalized geographic feature names. The compact format is suitable for display but not for sorting. Contrast with the sort format, which is suitable for sorting but not for display.

COMPLEX [Chapter III.6]: A group of related buildings and/or other geographic features. The name of a complex is a NAP (Non-Addressable Place Name). Examples of complexes include housing projects, university and hospital campuses, cultural complexes (such as Lincoln Center) and airports. Compare to simplex and constituent entity of a complex.

CONSTITUENT ENTITY OF A COMPLEX [Chapter III.6]: An individual building or other geographically identifiable feature that is part of a complex. Examples are the buildings in Lincoln Center and in Stuyvesant Town.

COPY LIBRARY, COPY FILES [Chapter VIII.4]: Many programming languages have a facility for accessing external files of source code called COPY files during application program compilation. COPY files reside in a partitioned data set (PDS) called a COPY library. The Geosupport System has COPY libraries containing source code layouts of the work areas in Assembler, PL/1, COBOL, C and NATURAL. The use of the Geosupport COPY libraries by application developers is optional but is strongly recommended.

CORPORATION COUNCIL OPINION (CCO) [Appendix A3]: A Corporation Council Opinion (CCO) is a geographic feature type. A CCO is an opinion by the City’s Law Department that a street area, not owned by the City, (e.g. a portion of a private street) has been dedicated for public use, consistent with the requirements of General City Law, Section 36(2). That allows the City to use public funds for various improvements and services, including paving of the roadway and installing sewers. The request usually relates to planned work by the City’s Department of Transportation, Department of Design and Construction, and Department of Environmental Protection.

COW - See Character-Only Work Area

CSC - See Computer Service Center

CSCL (‘NYC Citywide Street Centerline File’): An object-oriented database describing the features (streets, and non-street features) in NYC.

D

DAPS - see Duplicate Address Pseudo-Street Name

DEAD END [Chapter III.6]: A pseudo-street name that Geosupport accepts as street name input to refer to a termination point of a street at which there are no cross streets.

DEPARTMENT OF INFORMATION TECHNOLOGY AND TELECOMMUNICATIONS (DoITT): An agency of the City of New York responsible for city government-wide information technology infrastructure support. DoITT operates the Computer Service Center.

DISPLAY FUNCTION [Chapters IV.6 and V.2]: Any of the Geosupport functions that provide data items that can be used to display geographic locations on application screens, reports, mailing labels etc. Specifically, the display functions provide street names corresponding to input street codes, and provide house numbers in HND format corresponding to input house numbers in HNI (MSW) or HNS (COW) format. Note that the display functions do not actually display anything themselves; they merely provide data items that are suitable for an application to display. Currently, the display functions are Functions D, DG and DN.

DoITT - see Department of Information Technology and Telecommunications

DRIVER, GEOSUPPORT [Chapter II.1]: A Geosupport load module that serves as an interface enabling application programs to access Geosupport via API calls. There are two different drivers, one for batch applications and one for CICS applications. Application developers must link-edit the appropriate driver into the application program.

DSNY - The City of New York Department of Sanitation

DUPLICATE ADDRESS PSEUDO-STREET NAME (DAPS) [Chapter V.6]: A pseudo-street name accepted as street name input by Geosupport in duplicate address situations. DAPSs enable applications to specify which instance of a duplicated address the application wishes to process. As an example, Hillside Avenue exists in both the Bellerose section and the Douglaston section of Queens. To allow the user to refer to Hillside Avenue in a duplicate address situation two pseudo-street names are accepted by Geosupport, namely HILLSIDE AVENUE BELLEROSE and HILLSIDE AVENUE DOUGLASTON. As an alternative to a DAPS, for Functions 1, 1A, 1B, and 1E, the user may enter the conventional street name and the ZIP code which identifies the section of the borough, e.g. .ZIP Code 11426 for Bellerose and 11363 for Douglaston.

F

FOREGROUND COMPONENT [Chapter I.5]: The component of the Geosupport System that is directly accessed by a user application via the API. The foreground component includes both software and files.

FREE-FORM ADDRESS [Chapter V.3]: An address expressed with the house number and street name stored together in a single field. (Compare with parsed-form address.) Geosupport can process free-form addresses in which the house number and street name are passed together in the WA1 input street name field (and no value is passed in the separate WA1 input house number field).

FRONT-TRUNCATED STREET NAME [Chapter III.5(E)]: In the borough of Bronx or Manhattan only, a front-truncated street name is one that can be transformed to a valid street name by adding the word EAST or WEST to the front of the street name, for example 14 STREET is a front-truncated street name for EAST 14 STREET and WEST 14 STREET. Additional criteria are described in Section III.5(E).

FUNCTION [Chapters I.2, I.4]: The Geosupport System is organized into more than a dozen distinct functions that can be accessed by the user. Each function is identified by a one- or two-character function code.

G

GBAT - See Geosupport Batch Address Translator

GEOCODE [Chapter I.2]: The process of associating higher-level geographic information, such as the police precinct, ZIP code or census tract, with a specific geographic location, such as an address or street intersection. Geocoding is one of the Geosupport System’s most important services.

GEOGRAPHIC ONLINE ADDRESS TRANSLATOR (GOAT) [Chapter I.1]: The Geosupport System’s principal CICS utility transaction. GOAT is an inquiry transaction that allows the user to request any Geosupport function, enter input data and receive back a formatted screen display of the corresponding output information provided by that function. The use of GOAT requires no programming skills and it is not documented in detail in this UPG. (The GOAT utility was previously known as the Geosupport Online Address Translator (GOAT)).

GEOGRAPHIC RETRIEVAL CONSISTENCY [Chapter I.3]: Retrieval of information by geographic location in a manner that is independent of how the location is specified. The ability of an application to retrieve data consistently by geographic location from the application’s own files is a critical design issue for many applications. One important means of implementing geographic retrieval consistency in an application is to use B5SCs (see the entry for alias) instead of street names in the retrieval key.

GEOSUPPORT APPLICATION PROGRAMMING INTERFACE (API) [Chapter II.1]: The Geosupport facility that enables user-written application programs to interact with Geosupport via standardized program calls. The API involves the use of a Geosupport driver module and Geosupport work areas.

GEOSUPPORT BATCH ADDRESS TRANSLATOR (GBAT) [Chapter XI.1]: The Geosupport System’s batch utility program.

GEOSUPPORT ONLINE ADDRESS TRANSLATOR (GOAT)- see Geographic Online Address Translator(GOAT).

GEOSUPPORT RETURN CODE (GRC) [Chapter II.2]: A two-byte code that is returned in WA1 upon completion of every API call to Geosupport, indicating to the calling application the outcome of the call. (Not to be confused with operating system return codes or condition codes.) A GRC value of ‘00’ signifies an unconditionally successful call. A GRC value of ‘01’ signifies a warning. A GRC value of other than ‘00’ or ‘01’ signifies a reject. See also the Glossary entries for Reason Code and Message. See Appendix 4 for a comprehensive list of GRCs, Reason Codes and Messages.

GEOSUPPORT SYSTEM ADMINISTRATOR [Chapter I.1]: A designated staff member (generally a systems programmer) of a computer center where Geosupport is installed on a mainframe, responsible for installing new Geosupport file releases and software versions, and for trouble-shooting system-related Geosupport problems. Note: the Geosupport System Administrator is not necessarily responsible for providing application-related support to users.

GOAT - see Geographic Online Address Translator

GRC - See Geosupport Return Code

GSS [Chapter I.1]: The Geographic Systems Section of the City of New York Department of City Planning’s Information Technology Division. GSS is the developer and custodian of the Geosupport System.

H

HND - See House Number in Display Format

HNI - See House Number in Internal Format

HNS - See House Number in Sort Format

HOUSE NUMBER IN DISPLAY FORMAT (HND) [Chapter V.2]: One of Geosupport’s three output normalized house number formats. The HND is a format suitable for applications to use for display on screens, reports and mailing labels.

HOUSE NUMBER IN INTERNAL FORMAT (HNI) [Chapter V.2]: One of Geosupport’s three output normalized house number formats. The HNI is not suitable for display, because it is partly in packed decimal form, and it contains a code representing the house number suffix (if any) rather than the suffix itself. The HNI is used internally in the Geosupport System, and it is not of direct significance to most applications. HNI is valid in MSW only.

HOUSE NUMBER IN SORT FORMAT (HNS) [Chapter V.2]: One of Geosupport’s three output normalized house number formats. The HNS is not suitable for display, because it has an internal format and contains a code representing the house number suffix (if any) rather than the suffix itself. The HNS is used internally in the Geosupport System, and it is not of direct significance to most applications. HNS is valid in COW only.

HPD - Department of Housing Preservation and Development

I

ID-PROCESSING FUNCTION [Chapter I.4]: Any location-processing function that processes identification codes. Currently, the ID-processing functions are Function BL, which processes tax lots specified by an input BBL; Function BN, which processes buildings specified by an input BIN; and COW Function 2 which can process an intersection specified by a Node ID.

INPUT FIELD (IN A WORK AREA) [Chapter II.3]: A field into which the user application inserts a value to be passed to Geosupport. See also output field, WA1 and WA2. WA1 has both input and output fields. WA2 has output fields only.

L

LDF - see LION Differences File

LGC - See Local Group Code

LION DIFFERENCES FILE (LDF): The LION Differences File (LDF) is a sequential file containing records documenting certain types of changes that have occurred between a particular release of LION and the immediately previous LION release. A new LDF ‘edition’ is ‘published’ in conjunction with each new production release of LION. The changes documented in the LDF relate to node changes and segment changes.

LION FILE [Chapter VII.1]: A predecessor to CSCL, LION is a background component file that is a digital map of New York City. LION contains a single-line representation of the city’s streets and city limits. Geosupport’s street configuration processing is based on that representation.

LOCAL GROUP CODE (LGC) [Chapter IV.5]: The LGC consists of the sixth and seventh digits of the ten-digit street code. The LGC corresponds to a set of locally valid street names for the given street.

LOCALLY VALID STREET NAME [Chapter IV.5]: A name of a street that is valid for a particular portion (possibly all) of the street. The set of street names that are valid for the same portion of a street constitute a ‘local group’ and share the same LGC value.

LOCATION-PROCESSING FUNCTION: Any of the Geosupport functions that accept the input of a geographic location. These can be sub-classified into the address-processing functions (Functions 1, 1A and 1E); the street-configuration-processing functions (Functions 2, 3, 3C and 3S); and the ID-processing functions (Functions 2, BL and BN).

M

MAINFRAME-SPECIFIC WORK AREA (MSW (a.k.a. MFS)) - See Character-Only Work Area

MESSAGE [Chapter II.2]: A WA1 output item returned for all warnings and rejects, consisting of an appropriate explanatory text message. See Appendix 4 for a comprehensive list of GRCs, Reason Codes and Messages.

MFS - See MSW

MSW - See Mainframe-Specific Work Area

N

NAP - See Non-addressable Place Name

NAUB - See Non-addressable Un-named Building

NMF - See Non-Mainframe Environment

NODE [Chapter VII.2]: Either a conventional intersection of a street with another street, or a pseudo-intersection of a street with a pseudo-street or where there is a change in a significant geocode such as zip code or a Police Beat..

NODE ID [Chapter VII.2]: A unique identifier associated with each node in the Geosupport sytem. The Node ID is sometimes referred to as the Node Number.

NON-ADDRESSABLE PLACE NAME (NAP) [Chapter III.6]: A place name that is typically not combined with a house number to form an address. Examples: CITY HALL, EMPIRE STATE BUILDING, PLAZA HOTEL, LINCOLN CENTER, LA GUARDIA AIRPORT. A NAP can either be the name of a simplex, a complex, or a constituent entity of a complex. Geosupport’s address-processing functions accept many NAPs as input data

NON-ADDRESSABLE UN-NAMED BUILDING (NAUB) [Chapter VI.3]: A building that has neither addresses nor NAPs, and can only be identified by its BIN. Typical example is a storage shed on the grounds of an industrial property.

NON-MAINFRAME ENVIRONMENT (NMF): The Geosupport System runs in many non-mainframe environments, e.g. Desktop Edition, GeoX, .net, and Linux.

NORMALIZE [Chapter III.2 for street names, Chapter V.2 for house numbers]: To produce a version of a data item in a standardized format. Geosupport normalizes every input geographic feature name into one of two formats selected by the user application, called the compact format and the sort format. Geosupport also normalizes every input house number. Geosupport returns output normalized names and house numbers to the calling application in WA1.

O

OUT-OF-SEQUENCE ADDRESS [Chapter V.10]: An address such that the house number is out of sequence relative to nearby house numbers along the given street. For an input out-of-sequence address, the output information that Functions 1 and 1E return is based on the street segment where the out-of-sequence address is actually located, including the cross streets and geographic district identifiers. The Spatial Coordinates returned are those of a point calculated under the assumption that the building entrance is located at the midpoint of the blockface. A warning is issued for any address on a blockface containing an out-of-sequence address.

OUTPUT FIELD (IN A WORK AREA) [Chapter II.3]: A field into which Geosupport inserts a value to be returned to the calling user application. See also input field, WA1 and WA2. WA1 has both input and output fields. WA2 has output fields only.

P

PARSED-FORM ADDRESS [Chapter V.3]: An address that is expressed with the house number and street (name or code) stored in separate fields. (Compare to free-form address.)

PARTIAL STREET NAME [Chapter III.4]: A street name formed from a full normalized street name by deleting one or more entire words from the end of the full street name. For example, in Manhattan, READE is a partial street name for READE STREET. Geosupport accepts a partial street name as an input street name when the partial street name unambiguously represents a unique full street name in the specified input borough. Additional criteria are described in Chapter III.4.

PLACE NAME [Chapter III.6]: A name of a geographic feature other than a street name or a pseudo-street name. Examples of place names are the names of building complexes (such as university campuses, housing projects, hospital campuses etc.), individual named buildings (such as CITY HALL, EMPIRE STATE BUILDING, museums, hotels, theaters, stadiums etc.), parks, islands, airports etc. Geosupport recognizes some New York City place names, and more are being added over time. There are several types of place names; see Glossary entries for Addressable Place Name, Non-Addressable Place Name, Simplex, Complex and Constituent Entity of a Complex.

PREFERRED STREET NAME [Chapter IV.5]: If more than one local group of street names is valid at a particular location along a street, GSS designates one of them as the ‘preferred’ local group for that location. The preferred street name is the principal street name of the preferred local group.

PRIMARY STREET NAME [Chapter IV.3]: For every street in NYC, that is, for every valid B5SC value, GSS designates one spelling of one name of the street as the primary street name. Function D can be used to obtain the primary street name for a given B5SC value.

PRIMING WA1 [Chapter II.3]: The part of the API procedure in which the calling application program inserts values into WA1 input fields in preparation for issuing a call to the driver. Priming WA1 is how an application requests the function to be performed, passes the input geographic data (such as an address) to be processed, and specifies processing options.

PRINCIPAL STREET NAME OF LOCAL GROUP [Chapter IV.5]: The street name that GSS has designated as the ‘best’ representative from among all the names in a local group. Function DG can be used to obtain the principal street name for a given B7SC value. PSEUDO-ADDRESS [Chapter VI.5]: An address unofficially assigned by GSS to a street frontage of a tax lot that has no ‘real’ building addresses, such as a driveway. Function 1A accepts pseudo-addresses as input.

PSEUDO-INTERSECTION [Chapter VII.2]: A point along a street specified in terms of a pseudo-street name, i.e., a bend, a dead end or a city limit point.

PSEUDO-STREET NAME [Chapter III.6]: An ‘unofficial’ street name that Geosupport accepts as street name input for certain geographic situations. DAPSs are pseudo-street names that the address-processing functions accept as input only for the city’s very few cases of duplicate addresses (see Chapter V.6). DEAD END, CITY LIMIT, BEND and their aliases are pseudo-street names accepted as input by the functions that process street configurations (see Chapter VII).

R

REASON CODE [Chapter II.2]: A one-byte output WA1 item that qualifies the reason for a warning or rejection with greater specificity than does the GRC alone. Non-blank reason codes are returned for all warnings and for selected rejects. See Appendix 4 for a comprehensive list of GRCs, Reason Codes and Messages.

REJECT, REJECTION [Chapter II.2]: An unsuccessful outcome of an API call to Geosupport, indicated by a GRC value other than ‘00’ or ‘01’, accompanied by an appropriate Message, and for selected rejects, by a Reason Code.

RELEASE (OF GEOSUPPORT FOREGROUND FILES) [Chapter I.5]: Geosupport’s foreground component files are read-only files, and are periodically replaced by updated files. Every foreground file is identified as belonging to a specific Geosupport release.

RESYNCHRONIZATION OF STREET CODES [Chapter IV.4]: The updating of Geosupport street codes stored in a user application file to reflect street code assignment changes made in a Geosupport release.

ROADBED [Chapter V.5]: A roadbed is a street segment that is bounded on both sides by a physical separator such as a sidewalk, median barrier or median strip. Street segments that have painted medians separating travel direction do not form multiple roadbeds. Well-known examples of streets with multiple roadbeds include Park Avenue in Manhattan, Queens Blvd in Queens and Ocean Parkway in Brooklyn.

S

SIMILAR NAME [Chapter III.5]: When an input street name is rejected, Geosupport returns a list of up to ten ‘similar names’ in WA1, as an aid to the application in handling the reject. A ‘similar name’ is a valid full street name from the specified input borough that Geosupport, in accordance with certain criteria, deems to be similar to the rejected input street name.

SIMPLEX [Chapter III.6]: A ‘stand-alone’ named geographic feature, that is, a feature that has a NAP and that is not a complex or a constituent entity of a complex. Examples: Empire State Building, Plaza Hotel, Gramercy Park.

SNC - See Street Name Code

SNL - See Street Name Normalization Length Limit

SORT FORMAT [Chapter III.3]: A Geosupport format for normalized geographic feature names. The sort format is suitable for sorting but not for display. Contrast with the compact format, which is suitable for display but not for sorting.

STREET CODE [Chapter IV]: In the Geosupport System, a set of numeric street codes is assigned to represent the city’s street names and other geographic feature names. A borough code combined with a ten-digit street code, or B10SC, corresponds to a specific spelling of a specific street name in the given borough. Portions of the B10SC also have special significance. In particular, the first six bytes of the B10SC, the borough-and-five-digit street code (B5SC), encodes the alias relationship between street names.

STREET CONFIGURATION [Chapter VII.1]: A geographic location specified in terms of a combination of two or three streets. Street configurations include intersections, street segments, blockfaces and street stretches.

STREET-CONFIGURATION-PROCESSING FUNCTION [Chapter VII]: Any of the Geosupport location-processing functions that process street configurations. Currently, these are Function 2, which processes street intersections; Function 3, which processes street segments; Function 3C, which processes blockfaces; and Function 3S, which processes street stretches.

STREET NAME CODE (SNC): The final three digits of the B10SC (Borough and Ten-digit Street Code) are called the Street Name Code (SNC). Thus, the B10SC consists of the concatenation of the borough code, 5SC, LGC and SNC. The SNC serves simply to serialize the street names within a local group, so that the full B10SC is unique to a specific spelling of a specific street name.

STREET NAME NORMALIZATION LENGTH LIMIT (SNL) [Chapter III.2]: A user-specifiable parameter that sets the maximum length in bytes within which Geosupport normalizes input street names. The default value is 32.

U

UPG - See User Programming Guide

USER PROGRAMMING GUIDE (UPG) [Chapter I.6]: This document.

VANITY ADDRESS [Chapters V.9]: An address such that the street name refers to a different street than the one on which the referenced building entrance is actually located. For an input vanity address, the output information that Functions 1 and 1E return is based on the street segment where the vanity address is actually located, including the cross streets, geographic district identifiers and spatial coordinates. The source for the Spatial Coordinates (a.k.a. X-Y coordinates) returned for Vanity Addresses (and NAPs) is the Citywide Street Centerline file (CSCL). The CSCL information guarantees that the X-Y coordinates fall within the actual location (e.g. building footprint) of the Vanity Address. A warning is issued accordingly. The output information that Function 1A returns is based on the building associated with the vanity address. No warning is issued for Function 1A.

V

VERSION (OF GEOSUPPORT FOREGROUND SOFTWARE) [Chapter I.5]: Self-explanatory. Contrast use of the term ‘version’ for Geosupport software and ‘release’ for Geosupport data files.

VESTIGIAL FEATURE [Chapter I.5]: An element of the Geosupport System, such as a function, a work area, a data item or a JCL statement, that is obsolete and has been superseded by an enhancement. Vestigial features may continue to be operational but should not be used in new applications, and should be eliminated from existing ones.

W

WARNING [Chapter II.2]: A conditionally successful completion of an API call to Geosupport. A warning is signified by a GRC value of ‘01’ and an accompanying Reason Code and Message. In most cases, it is appropriate for applications to treat warnings in the same way as successful completions. It is sound practice, however, to examine the Reason Codes and Messages.

WA1, WA2 - See Work Areas

WORK AREAS [Chapter II.1]: Standard-layout blocks of data in memory that are shared between Geosupport and an application. The Geosupport work areas are an essential component of the Geosupport API, and constitute the sole means by which information passes between the application and Geosupport. Different Geosupport functions use different work area layouts. API calls can involve the passing of either one work area, called Work Area 1 (WA1), or two work areas, WA1 and Work Area 2 (WA2).