GeoTAX® Premium User's Guide - Pitney Bowes...Taxware Files 44 Boundary Files 45 Payroll Tax...

Location Intelligence

GeoTAX® PremiumVersion 7.3

User’s Guide for Windows, UNIX/Linux and z/OSDecember 2016

© 2016 Pitney Bowes Software Inc. All rights reserved.

Pitney Bowes Software Inc. is a wholly-owned subsidiary of Pitney Bowes Inc. Pitney Bowes, the Corporate logo, Centrus and “Every connection is a new opportunity” are trademarks of Pitney Bowes Inc. or a subsidiary. All other trademarks are the property of the respective owners.

The following trademarks are owned by the United States Postal Service®: CASS, CASS Certified, DPV, eLOT, FASTforward, First-Class Mail, Intelligent Mail, LACSLink, NCOALink, PAVE, PLANET Code, Postal Service, POSTNET, Post Office, RDI, SuiteLink, United States Postal Service, Standard Mail, United States Post Office, USPS, ZIP Code, and ZIP+4. This list is not exhaustive of the trademarks belonging to the Postal Service.

USPS Notice: Pitney Bowes Software Inc. holds a nonexclusive license to publish and sell ZIP+4 databases on optical and magnetic media. The price of the Pitney Bowes Software Inc product is neither established, controlled, nor approved by the U.S. Postal Service.

Pitney Bowes Software is a non-exclusive licensee of USPS® for NCOALink® processing. Prices for the Pitney Bowes Software products, options and services are not established, controlled or approved by USPS® or United States Government. When utilizing RDI™ data to determine parcel-shipping costs, the business decision on which parcel delivery company to use is not made by the USPS® or United States Government.

AD# 12.07

Centrus data products contained on this media and used within Centrus applications are protected by various trademarks and by one or more of the following copyrights:

Copyright © United States Postal Service. All rights reserved.

© 2016 TomTom. All rights reserved. This material is proprietary and the subject of copyright protection and other intellectual property rights owned by or licensed to TomTom or its suppliers. The use of this material is subject to the terms of a license agreement. Any unauthorized copying or disclosure of this material will lead to criminal and civil liabilities.

© 2016 HERE

Copyright © Nokia. All rights reserved.

Copyright © United States Census Bureau

Copyright © Nova Marketing Group, Inc.Portions of this program are Copyright © 1993-2016 by Nova Marketing Group Inc. All rights reserved.

© Copyright Canada Post CorporationThis CD-ROM contains data from a compilation in which Canada Post Corporation is the copyright owner.

© 2016 Claritas, Inc.

Table of Contents

Pitney Bowes GeoTAX Premium User’s Guide 3

Before You Begin

Purpose of This Guide 5Using the GeoTAX Documentation 5If You Need More Help 5To Obtain Additional User's Guides 6Your Comments Are Welcome 6

1 - Introduction

Introduction to Tax Jurisdiction Assignment 8GeoTAX Premium Overview 9GeoTAX Implementation Options 12GeoTAX Utilities 13

2 - Installing and Configuring GeoTAX

Supported platforms 16Overview of the GeoTAX download and installation process 16Downloading GeoTAX and support components17Installing GeoTAX 18Post-installation tasks 19

3 - Loading GeoTAX Data

Downloading the data files 24Windows Database Load Utility 27GeoTAX Master Files 28Point Data Files 29Landmark Auxiliary File 30User Auxiliary File 31GeoTAX Auxiliary File 33State-Supplied Files 35Pitney Bowes Sales and Use Tax Rate File 38Vertex MatchMaster Cross-Reference File 40Pitney Bowes Vertex File 43Taxware Files 44Boundary Files 45Payroll Tax Correspondence File 47User-Defined Boundary File 50

4 - Database Version Information Utility

Overview 53Running the Utility 53

5 - Using GeoTAX

Getting Started 55Finding an address 56Using GeoTAX match modes 60

Address matching 60Using enhanced search options 62Using geocoding features 67Using USPS matching enhancements 75Match results and return values 75

6 - Setting up and running a Batch Job

Overview 86The Matching Process 87Creating and running a GeoTAX batch job 88

7 - Interactive Address Matching

GeoTAX Matcher Overview 100Standard GeoTAX Matcher 100

8 - Working With the Callable Functions

Overview 108Invoking the Callable Functions Using COBOL113

9 - Working With EXITOP from Other Applications

GTX50 EXITOP 140

10 - GeoTAX Integrator Series

What Is the Integrator Series? 143What Are APIs? 143About the Programming Language 143Using the Examples Provided 144Parameter Structures 144Environment Variables 145Using the C API on a UNIX Platform 146Standard Return Values 147Function Call Summary 148Function Calls 150

A - Sample Library Member Reference

Sample Library Members 195

B - GeoTAX Parameter Record Reference

ADDRDF 198AEOUT 199ALOUT 201ARCOUT 203AUXOUT 204

Table of Contents


BF2OUT 205BUFOUT 206CBSOUT 207CNFOUT 209CONFIG 210CONFRM 214CONSxx 215CS ZIP 216DISTIT 217EXITOP (GTX50) 218FILEDF 219FIRMNM 224GEOOUT 225HEADER 229IPDOUT 230IPROUT 231LATLON 234LLOUT 235MCDOUT 239MOVE I 239MOVE O 241PAGESZ 242PAYOUT 243PCOUT 245PTCOUT 247PTDOUT 249REPORT 250SPDOUT 251STEOUT 252TAXOUT 253TESTIT 255UFTxx 255UHDxx 256USROUT 257

C - Error Conditions

Parameter Record Errors 260Condition Codes 260

D - Status Codes

Match Codes 263Location codes 265

E - Type Codes

Special Purpose Districts (SPD) 274Insurance Premium Districts (IPD) 275Payroll Tax Districts (PAY) 276Property Tax Districts (PTD) 276

F - Class Code Definitions

Class Code Definitions 278

G - Auxiliary Files

Overview 281Landmark Auxiliary file 281User Auxiliary file 288

H - Concepts in Geography

Overview of the Geographic Systems 292Census Geography 292Postal Geography 298Latitude and Longitude 300

Glossary

Index


Before You Begin

Purpose of This Guide

Welcome to GeoTAX® Premium. This User’s Guide is intended to provide you with the

information you need to effectively use GeoTAX® Premium.

Using the GeoTAX DocumentationThe Pitney Bowes website contains the most up-to-date version of the GeoTAX documentation. Between releases, these files are updated with information as it becomes available.

To see a list of currently supported hardware platforms, see the Centrus Products - Supported Platforms document on: http://www.g1.com/Support/.

If You Need More HelpIf you are unable to resolve a problem, a Pitney Bowes Technical Support Representative can help guide you to a solution. When you call Pitney Bowes Technical Support, please have the following information ready:

• A description of the task you were performing.

• The resulting reports (specifically, the Execution Log and Parameter Record Listing).

You can contact Pitney Bowes Technical Support in the following ways:

• Create a case in our Online Case Management System -http://go.pbinsight.com/online-case-management

• Send an email to [email protected], or

• Call our toll-free number, +1 800.367.6950.

The Website

You can also find out about Pitney Bowes products and services through the Pitney Bowes website at http://www.pb.com/software/. Registered users can obtain electronic copies of product documentation, join online discussion forums, download software and databases, find out about our training classes, or sign up for Pitney Bowes List Services.

The Pitney Bowes Technical Support website requires you to log in using your user ID and password to access the download pages. If you do not have a user ID and password, you can request them from: https://www.g1.com/Support/.

http://www.g1.com/Support/

http://go.pbinsight.com/online-case-management

http://go.pbinsight.com/online-case-management

http://www.pb.com/software/

mailto:[email protected]


Note: Registered users are those who have a maintenance agreement with Pitney Bowes. Contact Technical Support to obtain your user ID and password.

eService

eService, available through the Pitney Bowes website, provides supported Pitney Bowes customers with direct access to Service Requests and the Pitney Bowes Solutions Knowledge Base. You can search for your own Service Requests, search the Pitney Bowes Knowledge Base, and access a variety of other Technical Support services. You must be a registered user, with an ID and password, to access eService.

Education

Pitney Bowes offers comprehensive training courses on all of its products, allowing you to maximize the usability of your software.

Pitney Bowes offers access to its courses in three ways: public seminars, eLearning, and on-site training. You can choose the option that best fits your needs.

• For information about public seminars or eLearning classes, visit our Website at: http://www.pbinsight.com/support/Education.

• For information about on-site training, contact the Pitney Bowes Education Manager.

To Obtain Additional User's GuidesTo obtain electronic copies of our product manuals, go to the Pitney Bowes website at http://www.g1.com/Support/. Log in with your User ID and password. On the left side of the window under “Technical Services” click on My Documentation to download copies (.pdf files) of available user guides.

Your Comments Are WelcomeWe appreciate and welcome your comments concerning this guide! If you have suggestions, please let us know. A Documentation Comment Form is available online at http://www.g1.com/support/forms/. You may also make product enhancement suggestions using the System Enhancement Form located at this address.

With your help and suggestions, we can continue to provide quality software.


http://www.pbinsight.com/support/Education

http://www.g1.com/support/forms/

1 – Introduction

In this chapter

Introduction to Tax Jurisdiction Assignment 8GeoTAX Premium Overview 9GeoTAX Implementation Options 12GeoTAX Utilities 13


Introduction to Tax Jurisdiction AssignmentTax exposure is an issue that companies deal with regularly. Since the majority of all taxes that companies pay are based upon local tax jurisdictions, it has become important for them to ensure that they are applying the correct tax rates for all of their customer billing. This creates the problem of accurately determining the tax jurisdiction for a customer’s address.

Most companies use simple cross-reference tax tables which link five-digit ZIP Codes and tax jurisdiction names to the tax rate. This approach has a high margin of error, as the geographic area a five-digit ZIP Code corresponds to can cross tax jurisdictions and even county boundaries, making it difficult to assign the correct jurisdiction and tax rate to a given address.

For example, consider the following address: 5400 High School Ave., Dallas, TX 75205. This address is located within the incorporated jurisdiction of Highland Park, FIPS place code 33824. Another piece of data available, the class code, indicates that Highland Park is an active incorporated place. In this example, relying on the mailing address to calculate the tax results in the incorrect tax jurisdiction assignment of Dallas, Texas. Many addresses are assigned to a post office (with an assigned postal city name) but are actually located in other jurisdictions, including different counties and cities serviced by that post office. Many addresses are outside of city limits. In all these cases, the jurisdiction names and codes assigned by GeoTAX are different from the postal city name or postal county name assigned to that post office.

Using Physical Location of the Address Is the Key

There is little relationship between places and county, ZIP Code, or postal city boundaries. The same place can be in two or more counties or two or more ZIP Codes, and many different places may exist within the same postal city. In addition, not all streets are mapped

in the USPS address coding guide and assigned a ZIP+4® Code, because the USPS does not deliver mail to individual households in some areas. Instead, mail is delivered to a post office location only. In other cases, the locations of rural route and general delivery addresses are not well known. To address this challenge, Pitney Bowes has introduced a non-USPS street data source to improve street-matching coverage, especially in rural areas.

Because postal addresses cannot tell us the precise tax jurisdiction or place for a given address, and therefore may result in the wrong tax rate assignment, it is vital to use a more accurate method for matching addresses to municipalities. Using the TomTom database of street segments and latitude/longitude coordinates, Pitney Bowes has devised a street address-based GeoTAX solution to supplement the current ZIP+4-based approach.

The TomTom street segment database originated with the U.S. Census Bureau’s TIGER files, but it has been continuously refined and updated with the latest digital satellite imagery, Global Positioning System (GPS) surveys, and local planning and zoning information to provide the most accurate street-based geographic data available. The Pitney Bowes street-based address matcher takes an address and standardizes and


matches it to an exact physical location, returning latitude/longitude coordinates with the correct place code for the address. This solution greatly reduces the inaccuracies associated with 9-digit and 5-digit ZIP Code-based matching.

How It Works

The GeoTAX street-based matcher takes a house address and matches it to the correct street segment. Using the house number, it determines on which side of the street the house is located (usually based on an odd-even division). For taxing purposes, knowing the correct side of the street is important because streets are often the boundaries between municipalities or other adjoining jurisdictions. Thus, two addresses on the same street, in the same city, within the same ZIP Code could exist in different jurisdictions and have different tax rates.

Once the correct street segment and side is known, GeoTAX determines the physical location of the house based on known latitudes/longitudes and other geographic data in the street segment database. Users have the option to offset the location by 0, 20, 40, or 60 feet from the street center-line (the default offset is 40 feet). GeoTAX returns the coordinates of the house, along with the correct state, county, township, municipal place, place codes, incorporation status (if the address is inside a place), and other geocode data.

GeoTAX Premium OverviewGeoTAX determines the tax jurisdiction for a given address. Many state and local tax jurisdictions levy sales and use, franchise, insurance premium, property, employment, occupational, business, or other taxes. Accurately determining address location relative to local tax jurisdiction boundaries, as well as providing up-to-date information on ever-changing local jurisdiction boundaries, are the principle functions of GeoTAX.

With GeoTAX, you can accurately determine if a customer resides inside or outside of city limits, as well as which state, county, and township the address falls within. You can automatically transfer tax jurisdiction data to customer files, tax compliance systems, billing systems, and Geographic Information System (GIS) mapping software. GeoTAX provides a high-performance coding solution on any major enterprise platform in both batch and interactive modes of operation.


Features and Benefits of GeoTAX Premium

The following table summarizes a few of the features of GeoTAX Premium.

GeoTAX Processing Flow

GeoTAX takes address information and maps it to the corresponding geographic information. GeoTAX can append latitude/longitude, state codes, county codes, and other information which is then used to identify the proper taxing jurisdictions for use in your tax rate solution.

GeoTAX has the ability to correct all elements of an input address and obtain a match thereby providing latitude and longitude and other geographic information.

GeoTAX Feature Benefits

The ability to append current geocodes for state, county, township (MCD/CCD), and tax jurisdictions (place) to address records based on the physical location of the address (street-level matching) or on the ZIP+4 (postal matching).

You can stay current on boundaries, including tax jurisdictions (place) and the resulting tax jurisdiction assignments to street and postal information.

The ability to match your address records to state-supplied address listings.

You can remain compliant with emerging tax jurisdiction assignment requirements mandated by new federal and state laws. Communications services can take advantage of the Mobile Telecommunications Sourcing Act and the state of Florida’s Tax Simplification Law.

The ability to create your own database of address-to-geocode records and to match against the database.

If you have geographic areas you want coded in a certain way, the User Auxiliary file allows you to use your own custom coded records.

The ability to calculate latitude/longitude coordinates for individual address locations (including the use of interpolation and offset).

This allows you to determine the individual address location for mapping purposes.

The ability to cross reference and transfer tax jurisdiction information to tax compliance systems, billing applications, and enterprise resource planning systems.

This allows you to cross reference GeoTAX results with tax tables and other tax-related programs. It also provides you with the ability to convert standard jurisdiction codes to proprietary jurisdiction codes utilized by other vendors’ tax compliance software.

The ability to output matched data in a format that can be read into GIS mapping software.

This allows you to pull coded/matched address records into a GIS system to view them on a map.

The ability to be used in batch and interactive environments.

In batch mode, you process data in one pass, linking directly into tax tables and billing systems.

The ability to set a buffer radius. This provides you with a way to set a buffer distance for the boundaries defined in the spatial txb files. This allows for the return of a distance to border calculation and confidence value for place, township and special tax boundaries.

The ability to create a user-defined boundary file.

This provides you with a way to use information you have gathered to create your own user-defined boundary file. For information on creating your own boundary file, see the Boundary File Conversion Utility User’s Guide.

The ability to match against Payroll Tax Correspondence (PTC) files.

Pitney Bowes provides PTC files for most major payroll companies. Please contact your Pitney Bowes Software Sales Executive for information on the PTC files available.


After matching the addresses, you can cross-reference the addresses to the proprietary

geocodes used by Vertex®, Inc. or to those used by Taxware®, both third-party suppliers of tax compliance software. You also have the option to format the matched-address output so

it can be read into a mapping application, such as ESRI’s ArcView® or MapInfo®.

GeoTAX Data

GeoTAX Premium provides you with several different databases, along with the ability to include additional data files to match against your input addresses. The following table contains information on the GeoTAX databases. For more information on using these databases, see “Loading GeoTAX Data” on page 23.

Data file Description

Master Files The master files identify all geographic components associated with a street address, such as the latitude/longitude, census tract, and block group.

The master files expire at the end of four months after the vintage date of the files. For example, January data expires at the end of May.

State-Supplied Files GeoTAX Premium provides you with the ability to override, at the state level, match results based upon information supplied by the states. By matching to state-supplied files, you can remain compliant with tax jurisdiction assignment requirements mandated by new federal and state laws.

There are two file formats supported in GeoTAX: the Florida-native format, and the national TS-158 format (ANSI Transaction Set No. 158). The state of Florida provides address files in both the TS-158 and its own native format.

Note: This database option may not be available to all GeoTAX users. Individual states may restrict the use of state-supplied address files to licensed communications carriers or other business entities registered with the individual state.

Payroll Tax Correspondence Files

The Payroll Tax Correspondence file is a customizable file used to convert the multiple jurisdictions returned by GeoTAX into tax codes usable by your organization.

Pitney Bowes provides PTC files for most major payroll companies. Please contact your Pitney Bowes Software Sales Executive for information on the PTC files available.

Landmark Auxiliary File The Landmark Auxiliary File provides you a way to specify customized address information in your input records.The recommended primary use of this file is to match to your company’s non-address locations such as well heads, transmission towers or any other descriptive location.The latitude/longitude coordinates that are part of the input needed to build this file allow companies to automatically keep track of any jurisdictional changes that affect these unique locations.

GeoTAX Auxiliary File Occasionally new or updated data is available for individual records where the data has not yet been included in the GeoTAX master files. GeoTAX uses its own auxiliary file to incorporate the changes. This database is updated monthly and is published as a downloadable file for all licensed users.

User Auxiliary File The User Auxiliary file provides a means for you to override the answers supplied by the street databases in street-level matching. If you have data that is more current than that in the master files, you can enter the new data into the User Auxiliary file and use it for your address matching. GeoTAX returns matches made with a code that signifies the answer came from the User Auxiliary file. You can also return supplemental data from the User Auxiliary file with the match.


GeoTAX Implementation OptionsThis section describes the options you have for implementing GeoTAX, which includes batch processing, callable functions and the GeoTAX Integrator Series.

Batch Processing

Batch operations allow you to process large files containing thousands or millions of records. For example, suppose you provide GeoTAX an input file of 1,000,000 customer names and addresses. The product attempts to verify each address and append the geocoding data you specify. It provides the following separate output files:

• Coded output file

• Un-coded output file

• Mapping application output file

For detailed information on batch processing, see “Setting up and running a Batch Job” on page 85.

Boundary Files You can optionally license boundary files from Pitney Bowes to receive additional data, including Special Purpose Districts (SPD), Insurance Premium Districts (IPD), Payroll Tax Districts (PAY), and Personal Property Tax Districts (PTD) files. Pitney Bowes provides you with the appropriate boundary file on separate media if you license any of the optional files.

• The Special Purpose Districts (SPD) file provides you with return data on special purpose tax districts. Special purpose tax districts include such districts as regional transit areas and metropolitan football districts. SPD files expire five months after the vintage date of the files. You can override the expiration and allow matches to an expired database through the CONFIG parameter.

• The Insurance Premium Districts (IPD) file can help your company comply with state legislation that requires insurance companies to pay tax on insurance premiums for policies within the state.

• The Payroll Tax Districts (PAY) file can help your company comply with state legislation that requires employers to deduct taxes from employee paychecks for special districts, such as taxes for emergency municipal services districts.

• The Personal Property Tax Districts (PTD) file provides your company with a complete solution for accurate, automated asset collection and jurisdiction assignment.

User-Defined Boundary Files

You can create user-defined boundary files that include your own boundary information. Using these files, you can set a buffer distance for the boundaries defined in the files. For information on creating your own boundary file, see the Boundary File Conversion Utility User’s Guide.

Pitney Bowes Software Sales and Use Tax Rate file

You can optionally license the Pitney Bowes Software Sales and Use Tax Rate file to supply sales and/or use tax rate data for the general, automotive, construction or medical industries. Tax rates can be provided for the state, county, municipality and up to 10 SPDs as well as a combined tax rate of the individual sales or use tax rates.

Cross-Reference Files GeoTAX Premium provides you with the ability to use cross-references files that map the returned taxing jurisdictions from GeoTAX to the proprietary codes used by Vertex, Inc. and Taxware.

Data file Description


GeoTAX Callables

Callable modules are those that GeoTAX uses to analyze your input addresses and match those addresses to the database. These modules are primarily designed so you can call them from your own COBOL applications.

For example, your organization might have a COBOL-written data entry system application. You want to accurately assign county name and FIPS county codes as they are entered into your system. GeoTAX provides a callable named GTMATCH to allow you to assign accurate county information as the addresses are passed into your order entry system.

For detailed information on GeoTAX callables, see “Working With the Callable Functions” on page 107.

GeoTAX Integrator Series

GeoTAX Integrator Series is a collection of application programming interfaces (APIs) to analyze your input addresses and attempt to match the address to the database. These APIs are primarily designed so you can call them from your own Windows or UNIX application supporting the C language call interface.

For example, your rural telephone cooperative has a service system operated by a single user. GeoTAX provides you with a way to accurately assign county information to addresses as they are entered into your service system.

For detailed information, see “GeoTAX Integrator Series” on page 142.

GeoTAX UtilitiesThe GeoTAX installation includes several utilities to help you load data, provide you with database information and perform interactive address matching.

Windows Database Load Utility

The Windows Database Load Utility loads the GeoTAX Premium data sets.

For more information, see “Windows Database Load Utility” on page 27.

Database Version Information Utility

The database version information utility reads the master (also referred to as the Address Matcher database) and SPD files of the GeoTAX database, and returns the current date and expiration date of each database, and the number of days until each one expires.

For more information, see “Database Version Information Utility” on page 52.


GeoTAX Matcher

The GeoTAX Matcher is an interactive system that lets you match a single input address against the database file (Address Match function).

For detailed information, see “Interactive Address Matching” on page 99.

2 – Installing and Configuring GeoTAX

In this chapter

Supported platforms 16Overview of the GeoTAX download and installation process 16Downloading GeoTAX and support components 17Installing GeoTAX 18Post-installation tasks 19


Supported platformsGeoTAX is supported on the platforms listed in the following table.

Note: To see a detailed list of the officially supported OS versions, see the Centrus Products Supported Platforms document available at http://www.g1.com/Support/.

Overview of the GeoTAX download and installation process

Before beginning the download and installation process, make sure you:

• Have administrative rights (Windows)/root access (UNIX/Linux) on the system where the software is being installed

• Have your GeoTAX license file and password handy. This information would have been sent via email to the primary user contact in your company. Please note that you only need to install the license file if you are a new customer or if you are renewing your contract. Regular updates do not require new license files.

• Have a user ID and password to gain access to the secure area of the Pitney Bowes website. To receive your user ID and password, call 800-367-6950 and follow the voice prompts to connect to Technical Support for the GeoTAX product.

• Review the Release Announcement and any Technical Notes.

Perform the following steps to complete the installation process (this procedure assumes that you will be downloading from the Internet; for installs from physical media, start at step 4):

1. Download the GeoTAX software; then, unzip and extract the application files.

Windows OS UNIX/Linux OS z/OS

Windows Server 2008 64-bit

Windows 7 32-bit & 64-bit

Windows Server 2012 64-bit

AIX 6.1 64-bit

AIX 7.1 64-bit

z/OS v2.1 (minimum level)

z/OS Transaction Server (CICS) v5.2 (minimum level)

HP-UX 11.i 32-bit

HP-UX 11.23 Itanium 32-bit & 64-bit

HP-UX 11.31 Itanium 32-bit & 64-bit

Solaris 10 32-bit & 64-bit

Solaris 11 64-bit

SuSE Linux 10 64-bit

SuSE Linux 11 64-bit

Red Hat Linux 4.0 32-bit & 64-bit

Red Hat Linux 5.0 32-bit & 64-bit

Red Hat Linux 6.1 64-bit

Red Hat Linux 7.1 64-bit



2. Optional. Download the utilities (Auxiliary File Editor and Boundary File Converter) documentation.

3. Run the GeoTAX install wizard.

4. Download and install the data files.

5. Run the Installation Verification Procedure.

6. If applicable to your platform, perform post-installation configuration tasks.

The following sections cover each of these steps in more detail.

Downloading GeoTAX and support componentsThere are two options for downloading your software:

• eStore: You can download the GeoTAX software and download instructions document from the Pitney Bowes eStore through the links provided in your welcome email. The eStore also allows you to order a backup DVD for a nominal fee.

• Technical Support Website: GeoTAX is available for Internet download from the Pitney Bowes Technical Support website. The following section details the download procedure.

Downloading GeoTAX software from the Technical Support website:

1. Navigate to http://www.g1.com/Support/.

2. Click My Products. You will see a listing of available product downloads.

3. Click GeoTAX from the product list.

4. In the GeoTAX Purchase Listing table, click on the View Available Downloads link in the Details column that corresponds to your operating system. You will be directed to the GeoTAX product’s details page.

5. On the Product Details page, click the Software tab. The Downloads section of the page shows all of the available items to download for the software release, such as:

• Software file(s)

• Documentation

6. Click on the File arrow next to Downloads to begin the software download. You will see a screen showing download tips.

7. Click START DOWNLOAD. You may be asked to provide credentials once again.

8. Reply to the prompt to Save or Open the zip file.



Installing GeoTAXNote: Have your license key (license.lic) available - the GeoTAX install wizard prompts

you to locate and select this file during the GeoTAX installation.

On Windows:

1. Download the GeoTAX software by following the instructions in “Downloading GeoTAX and support components” on page 17.

2. If the zip file is not already open, navigate to where you saved the zip file when downloading it from the website. Extract the files from the zip file.

3. Double-click on Setup.exe. The install wizard walks you through the installation process.

When the install completes, follow the instructions for downloading the data files (see “Downloading the data files” on page 24).

On UNIX/Linux:

1. Download the GeoTAX software by following the instructions in “Downloading GeoTAX and support components” on page 17. The software is delivered in a compressed tar file.

2. Extract the files from the .tar file.

3. From the bin directory, run configuresetup. This launches the interactive setup script.

4. Follow the instructions provided in the setup script.

5. Copy the license file (license.lic) provided in your email from Pitney Bowes Technical Support to the ${G1GTX} directory and create a text file called gtgspas.lic containing only the license file password. This can be done with the command "echo <password> > gtgspas.lic”, where <password> is the password you received in your email from support.

When the install completes, follow the instructions for downloading the data files (see “Downloading the data files” on page 24).

On z/OS:

The installation process involves the following steps. These steps assume you have already downloaded the .exe or .zip file and unzipped it to extract the files.

1. FTP the IDSINSTL JCL.

2. Customize the IDSINSTL JCL.

3. Run the IDSINSTL job.

4. (Optional) Re-link object modules to create load modules.

Note: You can bypass this step if your facility allows you to install load modules. Some products are now delivered in load module format. This enables you to get up and running much faster than ever before. Once the IDSINSTL job completes, you can install any required databases (using the current load library where


applicable) and run your regression/IVP tests. Once you are satisfied with the results, you can schedule migrating the new modules into your production environment. No relinking required.

5. Load or reload the database. For more information, see “Loading GeoTAX Data” on page 23.

6. Run the installation verification procedure to ensure a successful install. For more information, see “Running the Installation Verification Program” on page 19.

7. Configure and test CICS, if applicable. For more information, see “CICS Installation” on page 22.

Post-installation tasksThis section provides information on post-installation verification and configuration requirements.

Note: Prior to running the Installation Verification Program, download and install your data files. For directions on downloading and installing the data files, see Loading GeoTAX Data.

Running the Installation Verification Program

Pitney Bowes recommends that you run the Installation Verification Program (IVP) to ensure GeoTAX and the data files installed correctly. The IVP runs a GeoTAX batch job using sample input data and displays the results.

On Windows:

1. Click Run GeoTAX Job in the GeoTAX program group window. A GeoTAX pop-up window appears.

2. Enter sample as the name of the job to be run. Click OK. The job will take a few minutes to run.

3. When the job completes, you receive notification via a dialog box. Click Yes to review the output for errors.

4. To ensure that output files were produced, check the data directory where you installed GeoTAX. To view the results of the sample job, view the SAMPLE.RPT file.

If the job ran successfully, the report will show the output counts.

If the IVP job failed or did not run to completion, errors will be noted in the parameter record listing in the SAMPLE.RPT file; in this case, contact Pitney Bowes Technical Support at 800-367-6950 for assistance.

On UNIX/Linux:

1. Navigate to the /bin directory.

2. Source the setup file. For example, enter:


. ./setup

3. Source the sample file.

4. Execute rungtx.

5. To view the results of the sample job, view the SAMPLE.RPT file.

If the job ran successfully, the report will show the output counts.

If the IVP job failed or did not run to completion, errors will be noted in the parameter record listing in the SAMPLE.RPT file; in this case, contact Pitney Bowes Technical Support at 800-367-6950 for assistance.

On z/OS:

Run the IVPFILE JCL member to ensure that the batch load modules function properly. The IVP job executes the required programs and files. Uncomment file DD names and change parameters to exercise features you will be using so they can be verified up front. Be sure to add the LE run time library reference to your steplib concatenation.

IVPFILE is a sample installation verification job you can use to confirm the installation was successful.

To edit IVPFILE:

1. Edit the member IVPFILE, replacing the lower-case variable names with your site-specific names.

2. Submit the IVPFILE JCL for processing.

3. Once the IVP job runs, go to your SDSF (Systems Display and Search Facility) or IOF, or use the display tool of choice for viewing reports, logs, system messages, etc.

4. Select the job id for the IVPFILE job that you just ran.

This procedure should complete with a return code of zero (RC=0). In addition to several other files, each job produces a report and an execution log for each execution of the GeoTAX product. Items that may be of interest are the PRNTPRT Report and PRNTXLG Execution Log created for every driver program.

Post-installation tasks on Windows

Depending on your database options, you could have additional files such as state-supplied files, cross-reference files, or boundary files in the DB folder (default install location) or in an alternate folder that you selected for the database installation.

We recommend you update your database directory with the latest GeoTAX files as you receive them from Pitney Bowes. See “Loading GeoTAX Data” on page 23 for instructions on installing the optional databases.

After installing GeoTAX:

1. Select Control Panel > System > Advanced > Performance > Settings > Data Execution Prevention.


2. From the Data Execution Prevention tab, select Turn on DEP for all programs and services except those I select.

3. Click Add.

4. Navigate to:

• For 32-bit install on 32-bit system: C:\Program Files\Pitney Bowes\GeoTAX\Runtime

• For 32-bit install on 64-bit system: C:\Program Files (x86)\Pitney Bowes\GeoTAX\Runtime

• For 64-bit install on 64-bit system: C:\Program Files\Pitney Bowes\GeoTAX\Runtime

Note: This is the default installation path.

5. Add all of the .exe files by repeating steps 2 and 3.

6. Navigate to: C:\Program Files\Pitney Bowes\GeoTAX\GTXMatcher\Matcher Console.exe.

Note: This is the default installation path.

7. Save and apply as necessary.

Post-installation tasks on UNIX

Depending on your database options, you could have additional files such as state-supplied files, cross-reference files, or boundary files.

We recommend you update your database directory with the latest GeoTAX files as you receive them from Pitney Bowes. For instructions on installing the databases, see “Loading GeoTAX Data” on page 23.

AIX-specific requirements

By default, AIX processes use 256 MB of memory. To avoid encountering memory problems using GeoTAX, update your environment with the variable listed below prior to starting your daemon:

export LDR_CNTRL=MAXDATA=0xN0000000rc.osseal start

where N is in OxN0000000, N can be any number 1 through 8.

Post-installation tasks on z/OS

This section contains information on the GeoTAX libraries and files.

After you complete the installation process, your system has the following libraries:

• A Load library containing the GeoTAX (GTX) load members

• An Object library containing the GTX Object members


• A JCL library containing the required JCL for proper execution and subsequent maintenance of GTX as well as copybooks, control cards, message file, and sample source code

CICS Installation

These instructions assume that you are familiar with modifying the CICS environment; if you are not, please ask a CICS systems programmer for assistance.

GeoTAX Premium supports CICS Transaction Server v5.2 and above. Interactive components are not compatible with any prior releases of GeoTAX and cannot co-exist in the same CICS region or load library with prior releases.

The execution load library contains the load modules required for the interactive system. The JCL library (yourhlq.GEOTAX.CNTL) contains the JCL for updating the CSD entries. Installing the interactive system in CICS requires the following steps, described below:

1. Install the resource definitions.

2. Install the customization file, if one exists for this product.

3. Define the product loadlib to CICS.

4. Execute the CICS system.

Step 1: Install Resource Definitions

For CICS Transaction Server v5.2 and above, modify the member GTXCSD as follows:

1. Modify the GTXCSD member according to the instructions within the member.

2. Submit the job and check the output.

Step 2: Define the Product Loadlib to CICS

Add the load library unloaded above to the DFHRPL concatenation. On the next startup of that CICS region, the interactive system should be available.

Step 3: Execute the Interactive System

You are ready to execute the interactive system. From a blank CICS screen, enter the transaction name. Please refer to your product User's Guide for more information about running the software.

Be sure to make copies of your programs, or recycle your CICS region to pick up the fixes and run the driver transaction to test the new programs.

3 – Loading GeoTAX Data

This chapter provides information on the data files and explains how to download, install and configure them for use in GeoTAX. The following topics are covered:

In this chapter

Downloading the data files 24Windows Database Load Utility 27GeoTAX Master Files 28Point Data Files 29Landmark Auxiliary File 30User Auxiliary File 31GeoTAX Auxiliary File 33State-Supplied Files 35Pitney Bowes Sales and Use Tax Rate File 38Vertex MatchMaster Cross-Reference File 40Pitney Bowes Vertex File 43Taxware Files 44Boundary Files 45Payroll Tax Correspondence File 47User-Defined Boundary File 50


Downloading the data filesThere are two options for downloading your data:

• eStore: You can download the data and download instructions document from the Pitney Bowes eStore through the links provided in your welcome email. The eStore also allows you to order a backup DVD for a nominal fee.

• Technical Support Website: The data files are available for Internet download from the Pitney Bowes Technical Support website. The following section details the download procedure.

Note: Prior to downloading the data files, if you have previously installed database files, you should back up those files and delete any copies of the .gdi,.gsd, gsi,.gsl, .gsu, .gsz, .gsx, .z9, .dir, .las and .los files in the data install directory.

Downloading from the eStore

Use the link in your welcome email to download the zip file. Extract the files and make note of the directory where you save the files.

On Windows:

Load your data files. For instructions, see “Windows Database Load Utility” on page 27.

On UNIX/Linux:

You must decrypt the zip5.gs_ file before it can be installed. To perform this process, open a command prompt, navigate to the /datasets/UNIX/<platform> directory included on the data media, where <platform> is your operating system, and execute the following command:

centrus_decrypt.exe <New Data>/zip5.gs_ Clear28050

where <New Data> is the location of the downloaded or copied updated data.

Proceed to the appropriate section in this chapter for loading your data file(s).

On z/OS:

You must decrypt the zip5.gs_ file before it can be installed. To perform this process, open a command prompt, navigate to the /datasets directory included on the data media. This area should be reachable by an FTP job on the z/OS machine; if not, copy it to such a location, then execute the following command:



Proceed to the appropriate section in this chapter for loading your data file(s).


Downloading from the Technical Support Website

1. Navigate to http://www.g1.com/Support/ > My Products > GeoTAX.

2. In the GeoTAX Purchase Listing table, click the View Available Downloads link in the Details column that corresponds to your operating system. You are directed to the GeoTAX Product Details page.

3. On the Product Details page, click the Databases tab. The Downloads section of the page shows all of the available data files to download.

4. On the data file that you want to download, click the File arrow next to Downloads to begin the download. The download tips screen appears.

5. Click START DOWNLOAD. The data file is downloaded as a .ZIP file.

6. Extract the files. Make note of the directory where you save the files since you will need to input that location when loading the data files.

7. Repeat steps 1-6 for each data set to be downloaded. Then follow the instructions for your platform.

On Windows:

Load your data files. For instructions, see “Windows Database Load Utility” on page 27.

On UNIX/Linux:

You must decrypt the zip5.gs_ file before it can be installed. To perform this process, open a command prompt, navigate to the /datasets/UNIX/<platform> directory included on the data media, where <platform> is your operating system, and execute the following command:

centrus_decrypt.exe <New Data>\zip5.gs_ Clear28050


On z/OS:

You must decrypt the zip5.gs_ file before it can be installed. To perform this process, open a command prompt, navigate to the /datasets directory included on the data media. This area should be reachable by an FTP job on the z/OS machine; if not, copy it to such a location, then execute the following command:





Running the Checksum Utility

Important: In the event you are experiencing problems with the installed data, it is recommended that you run the checksum utility to verify the checksum on the data file.

On Windows:

The chksum.exe and chksum.txt file are located in the same folder. Perform the following steps:

1. Change to the directory where chksum.exe is located.

2. Open a command line window.

3. At the command prompt, run chksum.exe with the /r option, as follows:

>chksum.exe /r

The checksum utility reports the results of the verification test. If the checksum fails, re-install the data. If the problem with the data or checksum error persists, contact Pitney Bowes via the options listed in “If You Need More Help” on page 5.

On UNIX/Linux:

1. Change to the appropriate platform in the >datasets/UNIX/ directory where the chksum.txt file is located.

2. Run the chksum executable, for example:

>datasets/UNIX/RH_8/chksum /r

The checksum utility reports the results of the verification test.

If the checksum fails, perform the following steps:

a. Check that the file with the failed checksum is located in the folder specified in chksum.txt.

b. Make sure that you are running the checksum executable from the folder that contains the chksum.txt.

c. Re-install the data.

If you perform these steps and the problem with the data or checksum error persists, contact Pitney Bowes via the options listed in “If You Need More Help” on page 5.

On z/OS:

Before uploading your data to z/OS, perform the following procedure. The chksum.exe and chksum.txt file are located in the same folder.

1. Change to the directory where chksum.exe is located.

2. Open a command line window.

3. At the command prompt, run chksum.exe with the /r option, as follows:

>chksum.exe /r


The checksum utility reports the results of the verification test. If the checksum fails, re-install the data. If the problem with the data or checksum error persists, contact Pitney Bowes via the options listed in “If You Need More Help” on page 5.

Windows Database Load UtilityThe GeoTAX installation for Windows platforms includes a database load utility that will load your data sets for use in matching. To launch the utility:

Click Start > Programs > Pitney Bowes > GeoTAX > Database Load Utility.

Note: Windows Server 2012 users - To launch the Database Load Utility on Windows Server 2012, go to the Apps page, look under the Pitney Bowes heading, then locate and click Database Load Utility.

The GeoTAX Database Load Utility dialog box opens.

The utility has a wizard interface that steps you through the data loading process.


GeoTAX Master FilesImportant: The GeoTAX Premium Database is a required data set and is the master file

for the GeoTAX Premium software. This data is not compatible with any previously released version of GeoTAX.

When matching to a GeoTAX Master file, complete the following procedure:

Load the GeoTAX Master Files

On Windows:

1. Click Start > Programs > Pitney Bowes > GeoTAX > Database Load Utility.


2. Select the GeoTAX master files option.

3. To complete the loading process, follow the instructions provided by the utility.

Note: An optional way to load the data is to run datasets.exe - this is an installation program provided with the data and is located in the root directory where you downloaded your data files.

On UNIX/Linux:

Copy the master files to the database area.

On z/OS:

1. To install the standard GeoTAX data files, locate the GTXDBINS member in the JCL library.

2. Edit this member, replacing the lower-case variable names with your site-specific names. This will include your site's FTP information and your desired High Level Qualifier.

Note: The SPACE parameters are correct as of the initial product release and may need modification each month as the data may increase in size.

3. Run this JCL bearing in mind that this process will delete the existing set of database files. You should perform this operation each time you receive GeoTAX data file media.


Point Data FilesPoint Data products include Master Location Data (MLD), Centrus Points, Centrus NAVTEQ Points, and Centrus TomTom Points. The points data provides point-level geocoding for the most accurate placement of addresses throughout the U.S.

When matching to a Point Data file, complete the following procedure:

Load the Point Data Files

On Windows:



2. Select the GeoTAX master files option.


Note: An optional way to load the data is to run datasets.exe - this is an installation program provided with the data and is located in the root directory where you downloaded your data files.

On UNIX/Linux:

Copy the Point Data files into the $G1GTXDB directory (the database area).

On z/OS:

1. Make sure there is enough space on z/OS to hold the file you will be uploading. Create a file with these attributes:

DCB=(RECFM=FBS,LRECL=8192,BLKSIZE=24576,DSORG=PS)

2. FTP the file up in binary mode. Alternately, copy and modify the GTXDBINS JCL member to create and FTP the data you want to use on z/OS.


Landmark Auxiliary FileThe Landmark Auxiliary file provides you a way to specify customized address information in your input records; this file also includes latitude/longitude spatial information.

When matching to a Landmark Auxiliary file, complete the following procedure.

Step 1: Create the Landmark Auxiliary file

Directions for creating and editing the Landmark Auxiliary file are located in Appendix G: Auxiliary Files under “Landmark Auxiliary file” on page 281.

Step 2: Load the Landmark Auxiliary file

On Windows:



2. Select the Landmark auxiliary file option.


The utility installs the Landmark Auxiliary file in the database location for GeoTAX.

On UNIX/Linux:

Copy the Landmark Auxiliary file into the $G1GTXDB or $G1GTX/DB directory.

On z/OS:

1. Use the delivered file, yourhlq.GEOTAX.LDMKFILE as a template to create your own data file.

2. Use steps 5 through 7 of the JCL member LDVSAM1 to load your LandMark file into a VSAM file for use in GeoTAX. Be sure to include this file as the DSN in the DD AUXFILE in the JCL that runs GeoTAX (ie IVPFILE).

There are no further setup requirements to perform a match to the Landmark Auxiliary file - GeoTAX automatically determines if there is a Landmark Auxiliary file present and attempts matches to it.

For an in-depth description of the matching process, see “Matching to the Landmark Auxiliary file” on page 286.


User Auxiliary FilePitney Bowes updates its data regularly to incorporate new rules by government entities and enhancements by third-party data providers. In some cases, your organization may have newer information that Pitney Bowes has not yet incorporated into the data files. User Auxiliary files provide a way for you to process your input records against a file that includes these changes.

When matching to a User Auxiliary file, complete the following procedure.

Step 1: Create the User Auxiliary file

Directions for creating and editing the User Auxiliary file are located in Appendix G: Auxiliary Files in “User Auxiliary file” on page 288.

Step 2: Load the User Auxiliary file

On Windows:

1. Copy the User Auxiliary file to %G1GTX%\data\. The filename must be SEQAUX.ASC. If you use a different name, you must edit %G1GTX%\bin\MAKEAUX.BAT and change the filename.

Note: If GeoTAX is reinstalled, this change will be lost.



3. Select the User auxiliary file option.


The program installs the User Auxiliary file in the database location for GeoTAX.

On UNIX/Linux:

1. Copy the User Auxiliary file into the $G1GTX/data subdirectory.

2. Change to the $G1GTX/bin subdirectory.

3. Run the installation script installdb.

4. Select User Auxiliary File.

5. To complete the loading process, follow the instructions provided by the script.

The load program creates the indexed sequential file G1GTAUX.

On z/OS:

Use the delivered file, yourhlq.GEOTAX.SEQAUX as a template to create your own User Auxiliary file.

Run LOADAUX:

1. Modify the following variables:


• yourhlq - your high-level qualifier

• yourRTlib - Runtime Library in effect at your site

• volume - VSAM DASD pack volser

2. Insert a job card and submit.

The program produces a database file called G1GTAUX.

Step 3: Match to the User Auxiliary file

When you request a match to the User Auxiliary file, GeoTAX attempts a match to the Landmark Auxiliary file first, then to the User Auxiliary file before attempting a match to any other database. To use the User Auxiliary file for matching, put a Y in position 12 of the CONFIG parameter record in your batch job. The match code for records matching to User Auxiliary files is A.

For information on the CONFIG parameter, see “CONFIG” on page 210.

Step 4: Post User-Defined Data (optional)

Use the AUXOUT parameter record in your batch job to post data from the user-defined portion of the User Auxiliary file to your output records.

For information on the AUXOUT parameter, see “AUXOUT” on page 204.


GeoTAX Auxiliary FilePitney Bowes updates its data regularly to incorporate new rules by government entities and enhancements by third-party data providers. Occasionally new or updated data is available for individual records where the data has not yet been included in the GeoTAX master files. GeoTAX uses its own auxiliary file to incorporate the changes.

Note: The Latitude/Longitude and Latitude/Longitude Level return code may in some instances not be returned when there is a match to the GeoTAX Auxiliary File. In these instances the state, county and municipal returns are returned from the GeoTAX Auxiliary File but the Latitude and Longitude could not be determined.

Complete the following steps to use the GeoTAX Auxiliary file.

Step 1: Load the GeoTAX Auxiliary file

On Windows:



2. Select the GeoTAX auxiliary file option.


The program installs the GeoTAX Auxiliary file in the database location for GeoTAX.

On UNIX/Linux:

1. Copy the GeoTAX Auxiliary file into the $G1GTX/data subdirectory.



4. Select GeoTAX Auxiliary File.


The load program creates the indexed sequential file G1GTAX2.

On z/OS:

FTP the GeoTAX Auxiliary file that was downloaded from Pitney Bowes’ website in binary mode using these attributes:

DCB=(RECFM=FB,LRECL=853,BLKSIZE=31561,DSORG=PS)

Run LOADAUX2:

1. Modify the following variables.






The program produces a database file called G1GTAX2.

Step 2: Match to the GeoTAX Auxiliary file

GeoTAX first attempts a match to the following databases prior to matching to the GeoTAX Auxiliary file:

• Landmark Auxiliary file

• User Auxiliary file

• State-supplied file

To use the GeoTAX Auxiliary file for matching, put a Y in position 26 of the CONFIG parameter record in your batch job. The match code for records matching to GeoTAX Auxiliary files is U.

For information on the CONFIG parameter, see “CONFIG” on page 210.


State-Supplied FilesInstead of matching your input records to the GeoTAX databases, you can match them to address data provided by a state. Matching to state-supplied files helps you with your compliance to tax jurisdiction assignment requirements mandated by federal and state laws. GeoTAX supports the Florida-native format and the national TS-158 format.

Florida-Native Formatted Files

You can obtain the Florida-native files from the Florida Department of Revenue, which maintains a statewide database of address and taxing jurisdiction data. The Florida Department of Revenue compiles the database based on county.

Step 1: Download the Florida-Native Formatted Files

1. Download the files from the Florida website at: https://pointmatch.state.fl.us/General/AddressFiles.aspx.

2. Unzip and extract the downloaded files.

3. Combine the county files into a single file if you downloaded more than one county. If you downloaded the entire state list, you have approximately 67 files. To combine the files, open a DOS window, change the directory to the location where you extracted the files, then execute the following command:

copy /b *.csv G1FLMAL.DAT

Step 2: Load the Florida-Native Formatted Files

On Windows:



2. Select the State supplied Florida format file option.


The program installs the Florida-native file in the database location for GeoTAX.

On UNIX/Linux:

1. Copy the combined data file to the $G1GTX/data subdirectory.



4. Select State Supplied Master File (Florida Format).


https://pointmatch.state.fl.us/General/AddressFiles.aspx



On z/OS:

1. Modify the following STLOAD member variable in the INSTALL library as needed:




2. Insert a job card for STLOAD and submit.

3. Ensure the G1GTSST, G1GTSSN, and G1GTSSD file definition variables are defined.

TS-158 Formatted Files

In addition to the Florida-native formatted files, you can obtain the TS-158 formatted files from the Florida Department of Revenue, which maintains a statewide database of address and taxing jurisdiction data. The Florida Department of Revenue compiles the database based on county.

Step 1: Download the TS-158 Formatted Files

1. Download the files from the Florida website athttps://pointmatch.state.fl.us/General/AddressFiles.aspx.

Select the Ranges option for the Effective Date.

2. Unzip and extract the downloaded files.

Note: Non-PC-based platforms: convert the download files to a fixed-length file with a record length of 241 bytes. ASCII-based platforms: FTP in binary format.

3. Combine the county files into a single file if you downloaded more than one county. If you downloaded the entire state list, you have approximately 67 files. To combine the files, open a DOS window, change the directory to the location where you extracted the files, then execute the following command:

copy /b *.txt G1TSMAL.DAT

Step 2: Load the TS-158 Formatted Files

On Windows:



2. Select the State supplied TS-158 format file option.


The program installs the TS-158 file in the database location for GeoTAX.

On UNIX/Linux:

1. Copy the data in the $G1GTX/data subdirectory.





4. Select State Supplied Master File (TS-158 Format).


On z/OS:

1. Modify the following STLOAD2 member variable in the INSTALL library as needed:




2. Insert a job card for STLOAD2 and submit.

Ensure the G1GTGST, G1GTGSN, and G1GTGSD file definition variables are defined.

Step 3: Match to the State-Supplied Databases

Depending on your matching request, GeoTAX first attempts to match to the Landmark Auxiliary file and/or User Auxiliary file before attempting to match to a state-supplied file.

To match to a state-supplied database in batch processing, modify the CONFIG parameter. Records matched to a state database contain the return code ‘G’ for Government. You can also tell GeoTAX to return additional data from a state database using the STEOUT parameter record in your batch job.

For more information, see the CONFIG (page 210) and STEOUT (page 252) parameters.


Pitney Bowes Sales and Use Tax Rate File This section describes the steps to build the Pitney Bowes Sales and Use Tax Rate file.

Note: To use this feature, you must be a licensed user of the Pitney Bowes Sales and Use Tax Rate product.

There are four different types of rates available: General, Automotive, Medical and Construction. For the selected tax type, the following sales and/or use tax rate data can be provided:

• State

• County

• Municipality

• Up to 10 Special Purpose Districts (SPDs)

• Total Rate - the sum of the individual state, county, municipality and SPD rates

Complete the following steps to use the Pitney Bowes Sales and Use Tax Rate file.

Step 1: Load the Pitney Bowes Sales and Use Tax Rate file

On Windows:



2. Select the PB Software tax rate file option.


The program installs the Pitney Bowes Sales and Use Tax Rate file in the database location for GeoTAX.

On UNIX/Linux:

1. Copy the Pitney Bowes Sales and Use Tax Rate file into the $G1GTX/data subdirectory.



4. Select the PB Software Tax Rate File option.


The load program creates the indexed sequential file GTTAXRT.

On z/OS:

Run LOADRATE:

1. Obtain the SEQRTE file from Pitney Bowes.






In addition, modify the ftp variables appropriate for your site.


The program produces a database file called GTTAXRT.

Step 2: Match to the PB Software Sales and Use Tax Rate file

To match to the Pitney Bowes Sales and Use Tax Rate file in batch processing, modify the TAXOUT parameter record. You can also tell GeoTAX to return sales/use tax data for up to 10 Special Purpose Tax Districts using the SPDOUT parameter record in your batch job.

For more information, see the TAXOUT (page 253) and SPDOUT (page 251) parameter records.


Vertex MatchMaster Cross-Reference FileThis section describes the steps to build the Vertex cross-reference file used to match FIPS and census geocodes to Vertex geocodes.

Note: To use this feature, you must be a licensed user of Vertex ZIP Code based products.

Vertex uses its own tax jurisdiction codes. GeoTAX codes need to be matched to Vertex codes in order to reference their tax tables correctly. The cross-reference file enables you to match census geocodes from GeoTAX to Vertex tax tables.

Step 1: Create the Cross-Reference File (GTMASTR)

You can create the GeoTAX cross-reference file to Vertex geocodes in the following ways.

• Use the program GTXLOAD1 to read the input file provided to you by the data vendor. The file is reformatted and written as a sorted and indexed GTMASTR file.

• After reading the input file with GTXLOAD1, you may also write the file as an intermediate unsorted sequential file. After sorting it externally, read the file with program GTXLOAD2, which then writes the indexed GTMASTR file.

Program GTXLOAD1 requires the parameter file GTBMPRM that must contain the following parameter records: HEADER, FILEDF, and CONTRL. You can also include the following optional parameter records: PAGESZ, UHDxx, and UFTxx.

You can find detailed information on all of the parameter records except for the CONTRL parameter record in Appendix B: GeoTAX Parameter Record Reference.

The CONTRL parameter is specific to and valid only for the Vertex load program GTXLOAD1. See the following section for information on the CONTRL parameter record.

CONTRL Parameter Record

Use the following table to complete the CONTRL parameter record.

Position Field

1-6 Parameter name: CONTRL

8 Sort Indicator.

I Internal sort

E External sort

NOTE: If you use an internal COBOL sort, the GTMASTR file is created with GTXLOAD1. If you use an external sort, GTMASTR is created after both GTXLOAD1 and GTXLOAD2 are executed.

10-12 Input record location of cross-reference State Code.

14-16 Input record location of FIPS County Code.

18-20 Input record location of cross-reference Place Code.

22-24 Input record location of FIPS State Code.

26-28 Input record location of FIPS Place Code.

30-32 Input record location of FIPS Place Name.


Step 2: Load the Vertex MatchMaster Cross-Reference file

On Windows:



2. Select the Vertex MatchMaster cross reference file option.


The program installs the reference file in the database location for GeoTAX.

On UNIX/Linux:

1. Run the installdb program.

2. Select Vertex MatchMaster Cross Reference File.


The install program creates file GTMASTR in the GeoTAX database location.

On z/OS:

1. For an internal sort process, modify the JCL member GOTAXLD1 as appropriate. For an external sort process, modify the JCL member GOTAXLD2 as appropriate.


34-36 Input record location of low ZIP Code.

38-40 Input record location of high ZIP Code.

42-44 Input record location of cross-reference authorization codes.

46 Flag to exclude state records from output files (Vertex authorization code 1):

N Include records (default)

Y Exclude records

48 Flag to exclude county records from output files (Vertex authorization code 2):


Y Exclude records

50 Flag to exclude primary city records from output files (Vertex authorization code 3):


Y Exclude records

52 Flag to exclude township records from output files (Vertex authorization codes 4 and 8):


Y Exclude records

54 Flag to exclude alternate city records from output files (Vertex authorization code 5):


Y Exclude records

Position Field


Step 3: Match to the Vertex MatchMaster File

When defining your batch job, you must specify a ‘Y’ in position 56 of the PCOUT parameter record.

For more information on the PCOUT parameter record, see “PCOUT” on page 245.


Pitney Bowes Vertex FileThis section describes the steps to build the Pitney Bowes Vertex cross-reference file used to match GeoTAX geocodes to Vertex geocodes.

Note: To use this feature, you must be a licensed user of Vertex ZIP+4 based products and the Special Purpose Districts through Pitney Bowes.

In cooperation with Vertex, Pitney Bowes is now building a cross-reference file for use with the new Vertex products. Vertex uses its own proprietary codes. GeoTAX codes need to be matched to Vertex codes in order to reference their tax tables correctly. The cross-reference file enables you to match census geocodes from GeoTAX to Vertex software applications.

Step 1: Load the Cross-Reference file

On Windows:



2. Select the PB Software Vertex cross reference file option.



On UNIX/Linux:

1. Run the installdb program.

2. Select PB Software Vertex Cross Reference File.


The install program creates file GTMSTR2 in the GeoTAX database location.

On z/OS:

1. Modify the JCL member GOTAXLD4 as appropriate.


Step 2: Match to the Pitney Bowes Vertex Files

When defining your batch job, you must specify a ‘V’ in position 56 of the PCOUT parameter record in order to return the 9-byte Vertex key. This key (also called the GeoTAX key) is the result of the conversion of the FIPS codes, GNIS codes, and Special Purpose District Codes out of GeoTAX to the proprietary Vertex codes used in their software. You can then use that data in your Vertex application to find the tax rate for each jurisdiction.



Taxware FilesThis section describes the steps to build the Taxware files used to match GeoTAX geocodes to Taxware geocodes.

Note: To use this feature, you must be a licensed user of Taxware sales tax products and the Special Purpose District file through Pitney Bowes.

Taxware uses its own proprietary codes. GeoTAX codes need to be matched to Taxware codes in order to reference their tax tables correctly. The cross-reference file enables you to match census geocodes from GeoTAX to Taxware software applications.

Step 1: Load the Cross-Reference File

Note: Before loading the cross-reference file, choose which Taxware file you want to use: TWESEQ (Taxware Enterprise) or SUTSEQ (Sales and Use).

On Windows:



2. Select the Taxware cross reference file option.



On UNIX/Linux:



3. Select Taxware Cross Reference File.


The install program creates files GTTAXW in the GeoTAX database location.

On z/OS:

1. Modify the JCL member GOTAXLD3 as appropriate.


Step 2: Match to the Taxware file

When defining your batch job, you must specify a ‘T’ in position 56 of the PCOUT parameter record in order to return the 9-byte Taxware key. This key (also called the GeoTAX key) is used to convert the FIPS codes and GNIS codes out of GeoTAX to the proprietary Taxware codes used in their software. You can then use that data in your Taxware application to find the tax rate for each jurisdiction.



Boundary FilesThe boundary files are optionally licensed from Pitney Bowes. There are several types of boundary files: Special Purpose District (SPD), Insurance Premium District (IPD), Property Tax Districts (PTD), and Payroll Tax Districts (PAY).

If you have licensed a boundary file option from Pitney Bowes, you receive the appropriate boundary file on separate media.

Step 1: Load the Boundary File

On Windows:

1. Go to Start > Programs > Pitney Bowes > GeoTAX > Database Load Utility.

The GeoTAX Database Load Utility dialog box displays.

2. Select the Boundary file radio button.

3. Follow the instructions provided by the utility to complete the loading process.

The program installs the boundary file in the database location for GeoTAX.

On UNIX/Linux:

1. Change directory (cd) to the $G1GTX/bin subdirectory.


3. Select Boundary File.


The load program installs the boundary file(s) - spd.txb, ipd.txb, ptd.txb, and/or pay.txb - in the database location for GeoTAX.

On z/OS:

Run GTXBDINS:

1. Modify the variables as indicated in the member. In addition, modify to remove/include only the files you want.

Note: This JCL will create and upload files to your mainframe.


The program produces database files in the format: yourhlq.GEOTAX.xxx.TXB where xxx = SPD, IPD, PTD or PAY.


Step 2: Match to the Boundary File

To use a boundary file in your batch job fill out the appropriate parameter: IPDOUT, SPDOUT, PTDOUT, or PAYOUT. GeoTAX determines the latitude/longitude coordinates and uses that data to determine if the address is located in a boundary file. If so, the data specified on the IPDOUT, SPDOUT, PTDOUT, or PAYOUT parameter is posted to your output records.

For more information, see the IPDOUT (page 230), SPDOUT (page 251), PTDOUT (page 249), and PAYOUT (page 243) parameters.


Payroll Tax Correspondence FileThe Payroll Tax Correspondence (PTC) file is a customizable file used to convert the multiple jurisdictions returned by GeoTAX into tax codes usable by your organization. Pitney Bowes provides PTC files for most major payroll companies. Your contract with Pitney Bowes determines the PTC files available for matching. Contact your Pitney Bowes Sales Executive for information on the PTC files available.

When using a PTC file, complete the following steps.

Step 1: Modify the PTC file

When you receive your initial PTC file, modify the flat file using the editor of your choice to modify the flags for GeoTAX to return payroll codes and descriptions that represent business rules within your organization. These flags are in positions 372-377 of the PTC file.

Pitney Bowes provides updates to the PTC file regularly based on your contract. When you receive the PTC update files, you can enter flags for the modified records. You then need to run the GTPTCBLD program to merge the update PTC file with your existing file. This process maintains the existing user-defined flags you have already associated with the PTC data.


The following table describes the PTC file layout.

Note: If you need to modify existing flags for records in the PTC file, you can build your own update file. Use an existing file provided by Pitney Bowes as a template. Change the header record position 10 from FULL to UPDATE. Include the Key

Position Length Name

1 9 (required) Key Value. Lookup key into the file. Must be one of the following:

• 5 character jurisdiction ID from the Pay.txb polygon file. This file contains polygons for special areas, such as school districts.

• 9 character GNIS code.

• 5 character county key made up of the State and County FIPS codes.

• 2 character State FIPS code.

10 2 (optional) State

12 30 (optional) County

The payroll code and payroll description fields are paired, with each pair having a corresponding flag field. The flag field determines if GeoTAX returns data for the corresponding payroll code and description fields. GeoTAX does not return the fields if the flag is N or blank. This lets you create meaningful flags based on your business rules.

42 15 Payroll code 1

57 40 Payroll description 1











372 1 Flag 1

373 1 Flag 2

374 1 Flag 3

375 1 Flag 4

376 1 Flag 5

377 1 Flag 6


Value and the new flags for each record you want to update (positions 372-377). You do not need to include the other fields for the record. After updating the file, build the file as you would for an update file provided by Pitney Bowes.

Step 2: Load the PTC file

After modifying the initial or updated PTC file, load the PTC file for use by GeoTAX.

On Windows:



2. Select the Payroll tax correspondence file option.


The program installs the PTC file in the database location for GeoTAX.

On UNIX/Linux:

1. Copy the PTC file into the $G1GTX/data subdirectory.



4. Select Payroll Tax Correspondence File.


The program installs the PTC file in the database location for GeoTAX.

On z/OS:

Run PTCLOAD:






The program produces a database file called G1GTPTC.

Step 3: Match to the PTC file

To use a PTC file in your batch job, fill out the PTCOUT parameter record.

For more information on the PTCOUT parameter, see “PTCOUT” on page 247. For information on the output fields, see “Calling the GTDBINFO program” on page 134.


User-Defined Boundary FileYou can create a user-defined boundary file that includes your spatial boundary information.

When matching to a user-defined boundary file, complete the following procedure.

Step 1: Create the User-defined Boundary file

GeoTAX comes with the Boundary File Conversion Utility for you to create the user-defined boundary file. The Boundary File Conversion Utility provides you with a way to create your own .txb files from .TAB, .SHP or .MIF files for use in GeoTAX.

Note: Pitney Bowes provides the Boundary File Conversion Utility only on Windows. All GeoTAX users can use the Boundary File Conversion Utility on Windows and use the resulting .txb file on the platform for which they have licensed GeoTAX.

For information on creating a user-defined boundary file, see the Boundary File Conversion Utility User’s Guide.

Step 2: Load the User-defined Boundary file.

On Windows:



2. Select the Boundary file option.


The program installs the user-defined boundary file in the database location for GeoTAX.

On UNIX/Linux:

1. Change directory to the $G1GTX/bin subdirectory.


3. Select Boundary File.


The program installs the user-defined boundary file in the database location for GeoTAX.

On z/OS:

FTP the resulting .txb file manually in binary mode to the mainframe or modify GTXBDINS for use to upload the resulting .txb file. GeoTAX will be able to use uploaded file directly.


Step 2: Match to the User-defined Boundary file.

GeoTAX matches to the user-defined boundary file after a successful address match. To use a user-defined boundary file in your batch job, you must use the USROUT parameter. GeoTAX determines the latitude/longitude coordinates and uses that data to determine if the address is located in the User-Defined Boundary file. If so, the data specified on the USROUT parameter is posted to your output records.

GeoTAX provides you with a way to set a buffer distance for the boundaries defined in the user-defined boundary file. To set a buffer distance, use the BF2OUT parameter card.

For more information, see the USROUT (page 257) and BF2OUT (page 205) parameter cards.

4 – Database Version Information Utility

This chapter provides information on using the database version information utility.

In this chapter

Overview 53Running the Utility 53


OverviewThe database version information utility reads the Address Matcher database (also referred to as the Master files) and the SPD file of GeoTAX and returns the current date and expiration date of each database, and the number of days until each one expires.

Report example:

Today is 09/13/2013File Version Expiration Days til Exp.----------------------------------------------------------------------------GeoTAX Address Matcher DB Files: 08/2013 01/01/2014 110GeoTAX Special Purpose District File: 07/2013 12/01/2013 079

Running the UtilityThis section provides instructions for running the database version information utility on various platforms.

On Windows:

To run this utility using Windows:

Navigate to your ...\GeoTAX\bin location and run the DBINFO.BAT script.

Note: The resulting DBINFO.RPT and DBINFO.RPT.RTF files are written to your …\GeoTAX\data location.

On UNIX/Linux:

To run this utility using UNIX:

1. Go to the /bin directory.

2. Source the setup file. For example, enter: . ./setup

3. Run dbinfo to create the report file.

4. View job output in file dbinfo.rpt in the /data directory.

On z/OS:

1. Modify the JCL member DBINFO as needed.


3. View the results from the specified output for PRNTPRT DD.

5 – Using GeoTAX

This chapter provides an overview of the address matching and geocoding operations performed by GeoTAX.

In this chapter

Getting Started 55Finding an address 56Using GeoTAX match modes 60Address matching 60Using enhanced search options 62Using geocoding features 67Using USPS matching enhancements 75Match results and return values 75


Getting Started

Optimizing the matching process

Pitney Bowes designed and developed the GeoTAX data format and functions to allow you to directly access from direct storage devices or tape. However, this design is most effective when you process records in ZIP Code order.

Database search order

GeoTAX is able to process addresses using multiple databases at the same time. This allows you to find the best possible match from a variety of data sources and types of data (point as well as street segment data).

GeoTAX processes these multiple data sources using a default search order. When GeoTAX matches an address exactly, it stops searching rather than continuing the search in additional databases. This saves on processing time. When an exact match is not found, GeoTAX continues searching all of the available data sources for candidate address matches. The candidates are then scored and the highest scoring match from all of the data sources is returned as the match. If multiple candidates receive an identical score when matched to either the Points or Streets files, you have the option to set what results should be returned (see “Returning multiple address matches” on page 61). The default search order for GeoTAX is:




• GeoTAX Auxiliary file

• Points file, if licensed

• Streets file

Setting relative cache size to optimize performance

To optimize performance, GeoTAX provides the means to specify the relative amount of memory that is allocated to store temporary street data during address processing. A smaller cache may slow the performance, whereas a large cache setting may improve processing performance. Use the following to specify cache size usage (small, medium or large [default]):

Batch processing

Use the Cache Size field in the CONFIG parameter card.

Integrator Series API

Use the cCacheSize element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use the MCA-CACHESIZE field in the Matcher Control Area prior to Calling the GTMATCH program.


Setting relative cache size when matching to a boundary file

When using a boundary file for matching, the relative cache size can be set to optimize performance. Use the following to specify cache size usage (none, medium [default], large or very large):

Finding an addressGeoTAX processing modes and options are used to determine how address searches are performed and to specify the placement of the geocodes returned.

In some cases, GeoTAX cannot determine which match candidate is the best match. In these instances, GeoTAX returns a status indicating multiple candidates for a match for you to determine which is the appropriate candidate.

For more information on matching addresses, see the following topics:

• Entering an address

• Understanding the typical address

• Search area designation

• Hyphenated addresses

• Parsing city names

Entering an address

For optimal performance and match rates, input an address free of misspellings and with all known address components. To obtain the highest match rate, verify that your input follows USPS standards.

To obtain the most accurate tax jurisdiction, GeoTAX requires that your input address contains:

• street address line

• city

• state

• ZIP Code

Batch processing

Use the Boundary Cache Size field in the CONFIG parameter card.


Use the cBoundaryCacheSize element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use the MCA-BOUNDARY-CACHESIZE field in the Matcher Control Area prior to Calling the GTMATCH program.


Understanding the typical address

The typical address consists of the following elements:

Understanding how GeoTAX processes addresses

GeoTAX processes addresses in the following order:

1. Parses the address elements.

When you load data in GeoTAX, GeoTAX parses the data into single elements. Parsing occurs on data in the order in which you load the data. Even if a valid address is missing an element, GeoTAX can find a match. In addition, some elements, such as pre-directionals, may not be critical elements of some addresses. By comparing an address as input against all known addresses in a search area, GeoTAX can usually determine if any of these elements are missing or incorrect.

2. Determines the search area.

Element Description

Firm Name Optional. You can configure GeoTAX to match the input firm name, or business name, rather than an address.

Street Address Line Contains the street address. GeoTAX recognizes the following types of street addresses:

• PO Box, such as PO Box 100

• Rural Route or Highway Contract address

• General Delivery (stated in the address line)

• Street, such as 4750 WALNUT ST

• Highrise that contains unit information, such as 4750 WALNUT ST STE 200

• Building name where it matches the firm name in the ZIP+4 database. See enhanced search options.

These types of street addresses can have all or some of the following elements:

• House Number

• Predirectional, such as N, NE, and S

• Street Name

• Street Type, such as Ave, Blvd and Pkwy

• Postdirectional, such as N, NE, and S

• Unit Type, such as Apt, Ste, and Bldg

• Unit Number

• Private Mail Box

Last Line Contains the location of the address. GeoTAX can recognize the following last line elements:

• City

• State

• ZIP Code

• ZIP+4 Code


GeoTAX uses the last line elements of an address to determine a search area. You can specify if you want the search area to be based on a finance area or on an area defined by the city, state, and ZIP Code. If the city and state are not in the ZIP Code, GeoTAX performs separate searches for the ZIP Code and city.

Note: A finance area is a collection of ZIP Codes within a contiguous geographic region.

3. Finds possible matches within the search area.

Once GeoTAX has determined the search area, it tries to match the elements from the street address line to the records in the standardized data files and completes the following:

• Checks input address ranges for missing or misplaced hyphens, and alpha-numeric ranges for proper sequence.

• Searches for any misspellings and standard abbreviations. For example, GeoTAX can recognize Mane for Main and KC for Kansas City.

• Searches for any street name alias matches to the USPS and Spatial data (TIGER, TomTom, NAVTEQ and Points). For example, GeoTAX recognizes that in Boulder, “CO Highway 36” is also known as “28th Street”.

Note: The USPS does not consider matches to data that they did not create and these are not considered valid addresses for postal delivery.

• Searches for addresses that contain a house number and unit number as the same element. For example, GeoTAX recognizes the input 4750-200 Walnut Street and performs recombination to output 4750 WALNUT ST STE 200.

• Searches for any USPS recognized firm names for additional match verification.

• Searches for street intersection matches. GeoTAX recognizes and, &, &&, at, AT, and @ in the input address for an intersection match.

Note: The USPS does not consider intersections valid addresses for postal delivery.

4. Scores each possible match against the parsed input.

GeoTAX compares each element in the input address to the corresponding element in the match candidates, and assigns a confidence level. GeoTAX weighs the confidence level for all of the elements within a match candidate, and assigns a final score.

Note: GeoTAX uses a penalty scoring system. If an element does not exactly match an element in the match candidate, GeoTAX adds a penalty to the score of the match candidate. Therefore, scores with lower numbers are better matches.

5. Determines the match.

GeoTAX prioritizes each match candidate based on the assigned confidence score and returns as a match the candidate that has the lowest score.

The match mode you choose determines the range that GeoTAX allows for a match. GeoTAX only returns a match if the score of the target address falls within the range designated by the selected match mode. For more information on match modes, see “Using GeoTAX match modes” on page 60.


In some cases, more than one match candidate may have the lowest score - this is considered a multi-match result. In this case, you have the option to set how the matching outcome will be handled: you can opt to receive the 1st match candidate, or, in the case of interactive matching, the number of matches can be returned and you can select the match candidate from the multi-match list. For more information on multi-match, see “Returning multiple address matches” on page 61.

GeoTAX provides information on the matching and geocoding results and processes. For more information, see “Match results and return values” on page 75.

Search area designation

You can designate the search area to encompass a finance area or an expanded area specified by distance.

Searching a Finance area

A finance area is the default search area in GeoTAX. A finance area is a region defined by the U.S. Postal Service and typically consists of a set of contiguous ZIP Codes. GeoTAX will search the finance area defined by the input lastline.

Searching an Expanded area

The search area can be extended up to a 99-mile radius from the centroid of the input ZIP Code to assist in finding a match when the input address contains limited or inaccurate city or ZIP Code information. The expanded area is confined to within the state’s borders.

Use the following to designate the search area:

Hyphenated addresses

GeoTAX handles hyphens in address ranges. Address ranges are checked for missing or misplaced hyphens. Alpha-numeric ranges are checked for proper sequence.

If a house number is incorrectly entered with a hyphen, the number is first concatenated. If no match is resolved, GeoTAX tries the section of the house number following the hyphen as a unit number. See Matching address ranges for special processing of hyphens.

Batch Processing

Use the Search Area Option field in the CONFIG parameter card. When the value of the Search Area Option is set to ‘2’, you can set the Expanded Distance Radius property to tell GeoTAX how far to expand the search with a value from 1-99 miles.


Use the cSearchAreaOpt element in the GTXINPUT parameter structure prior to calling GTXMatchAddress. To expand the radius of the search area, set the desired radius in miles in the szSearchRadius element.

Callable Functions

Use the MCA-SEARCH-AREA-OPT field in the Matcher Control Area prior to Calling the GTMATCH program. To expand the radius of the search area, set the desired radius in miles in the MCA-SEARCH-RADIUS field.


Parsing city names

GeoTAX correctly parses out the separate elements of City, State, and ZIP Code from the last line in the address data. When the city element is preparsed, GeoTAX parsing is bypassed. For example, “Mt Pilot” would not be parsed to look for “Mount Pilot.” Best results are obtained by keeping all three elements in the address lastline.

Using GeoTAX match modesMatch modes determine the leniency used to make a match between your input and the reference database. Select a match mode based on the quality of your input and your desired output. For example, if you have an input database that is prone to errors, you may want to select the relaxed match mode.

The following match modes are available:

Use the following to specify the match mode:

Address matchingGeoTAX provides support for several variations in the format of an input address. This section contains information on the following topics:

• Two-line matching

• Matching dual addresses

• City name matching

• Returning multiple address matches

Mode Description

Exact Requires a very tight match. This restrictive mode generates the fewest match candidates, which decreases the processing time. When using this mode, ensure that your input is very clean; free of misspellings and incomplete addresses.

Close Default. Requires a close match and generates a moderate number of match candidates.

Relaxed Allows a loose match and generates the most match candidates, which increases the processing time and results in more multiple matches. Use this mode if you are not confident that your input is clean; free of misspellings and incomplete addresses. This is the only mode that does not respect the street parity when making an address match.

Batch processing

Use the Address Match Mode field in the CONFIG parameter card.


Use the cMatchMode element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use the MCA-ADDR-MATCH-MODE field in the Matcher Control Area prior to Calling the GTMATCH program.


Two-line matching

Two-line address matching allows you to pass two different address lines to GeoTAX. GeoTAX scans these two lines and extracts and standardizes a two-line address.

Preferences for two-line addresses

If GeoTAX finds a match, it returns the matched address as the first line and returns the extraneous address line as the second address.

Matching dual addresses

GeoTAX can process input that contains two addresses on the same address line. For example, GeoTAX can process the following input address:

3138 HWY 371 PO BOX 120PRESCOTT AR 71857

GeoTAX does not recognize dual addresses where the two addresses are both street addresses. For example, GeoTAX does NOT recognize 135 Main St 4750 Walnut St Ste 200. GeoTAX does recognize dual addresses where the two addresses are the same type of address but are not street addresses. For example, GeoTAX does recognize PO BOX 12 PO BOX 2000.

After GeoTAX parses the dual address, it searches for a match.

Note: GeoTAX does not perform dual address processing in Exact and Close modes.

City name matching

Extended city name matching allows GeoTAX to recognize a large number of city abbreviations.

Returning multiple address matches

In some cases GeoTAX cannot resolve an address match to a single best candidate. A multi-match occurs when multiple equally-scored matches are found in either the Points or Streets files. There are a couple of options for handling a multi-match outcome:

• Accept the multiples and return the 1st match candidate in the list.

• Do not return match candidate information (default).

To indicate whether the first match candidate information should be returned or not, use the following:

Batch Processing

Use the Accept Multiple field in the CONFIG parameter card.


Use the cAcceptMultiples element in the GTXINPUT parameter structure.

Callable Functions

Use MCA-ACCEPT-MULTIPLE in the Matcher Control Area.


Use the following to retrieve a multi-match list and to select a candidate from the multiple address matches:

Using enhanced search optionsThis section contains information on additional search and matching options available in GeoTAX, and includes the following topics:

• Matching address ranges

• Using building name and firm matching

• Specifying an alternate lookup method using firm names

• Missing and wrong first letter matching

• Using Latitude/Longitude coordinates as input

Matching address ranges

Some business locations are identified by address ranges. For example, a shopping plaza could be addressed as 10-12 Front St.; this is how business mail is typically addressed to such a business location. These address ranges can be geocoded to the interpolated mid-point of the range.

Address ranges are different from hyphenated (dashed) addresses that occur in some metropolitan areas. For example, a hyphenated address in Queens County (New York City) could be 243-20 147 Ave. This represents a single residence (rather than an address range) and is geocoded as a single address. If a hyphenated address similar to this example returns as an exact match, then there is no attempt to address range match.

Address range matching is disabled by default and is an optional mode. Address range matching is not available in Exact mode, since an address range is not an actual, mailable

USPS® address.

Use the following to enable matching with address ranges:

Batch Processing

Not applicable.


Refer to the cNumMultiple element in the GTXOUTPUT data structure to retrieve the number of multiple match candidates found. Use the cGetMultiple element in the GTXINPUT parameter structure to select which match result should be returned.

Callable Functions

Use MOA-NUM-MULTIPLE to retrieve the number of multiple match candidates found. Use MCA-GET-MULTIPLE in the Matcher Control Area to select which match result should be returned.

Batch Processing

Use the Address Range Option field in the CONFIG parameter card.


Use the cAddressRangeOpt element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use MCA-ADDRESS-RANGE-OPT in the Matcher Control Area prior to Calling the GTMATCH program.


Address Range matching capabilities and guidelines

Address Range matching works within the following guidelines:

• There must be two numbers separated by a hyphen.

• The first number must be lower than the second number.

• Both numbers must be of the same parity (odd or even) unless the address range itself has mixed odd and even addresses.

• Numbers can be on the same street segment or can be on two different segments. The segments do not have to be contiguous.

• If both numbers are on the same street segment, the geocoded point is interpolated to the approximate mid-point of the range.

• If the numbers are on two different segments, the geocoded point is based on the last valid house number of the first segment. The ZIP Code and FIPS Code are based on the first segment.

• In all cases, odd/even parity is evaluated to place the point on the correct side of the street.

A close match to a single address number is preferred over a ranged address match. GeoTAX attempts a close match on the recombined address number before making a ranged match, as seen in the following example:

Input: 4750-4760 Walnut St, Boulder, COOutput: 4750-4760 WALNUT ST, BOULDER, CO 80301

The Address Range match is to a single street segment, with the geocode being placed on the mid-point of the range.

Input: 47-50 Walnut St, Boulder, COOutput: 4750 WALNUT ST, BOULDER, CO 80301-2532

In the example below, the second number is not larger than the first, so GeoTAX treats this as a unit number rather than a ranged address:

Input: 4750-200 Walnut St, Boulder, COOutput: 4750 WALNUT ST STE 200, BOULDER, CO 80301-2532

Using building name and firm matching

GeoTAX can enhance standard address matching by matching to building and business names.

By default, GeoTAX is able to match building names with unit numbers in the address line, the Chrysler building as an example:

Firm:Address: 5001 Chrysler BldgLast Line: New York New York 10174

The returned information is the address of the Chrysler building. GeoTAX returns a standardized address in place of the building name:


Firm:Address: 405 LEXINGTON AVE RM 5001Last Line: NEW YORK, NY 10174-5002

Entering the White House, as an example, into the address line, the address for the White House returns in the address field:

Firm:Address: White HouseLast Line: Washington DC 20500

GeoTAX returns the following address:

Firm:Address: 1600 PENNSYLVANIA AVE NWLast Line: WASHINGTON DC 20500-0004

Entering a firm name in the Firm name field returns the address for the input firm in the address field:

Firm: White HouseAddress: Last Line: Washington DC 20500

GeoTAX returns the following address:

Firm: WHITE HOUSEAddress: 1600 PENNSYLVANIA AVE NWLast Line: WASHINGTON DC 20500-0004

Using the following to set up your firm name parameters for your input record, then set the Alternate Lookup option described in the following section to enable matching to a firm name

Batch Processing

Use the FIRMNM parameter card.


Use the szFirmName element of the Input Address Block in the GTXINPUT parameter structure.

Callable Functions

Use the MIA-FIRM-NAME field in the Input Address Block of the Matcher Input Area.


Specifying an alternate lookup method using firm names

The Alternate Lookup option allows specifying the preferred way to match when both an address and firm name are provided. The matching method can be set to match to the address rather than the firm name or vice versa. If neither are specified, the default matching method is to match to the address line only. Use the following to specify an Alternate Lookup option:

Missing and wrong first letter matching

The missing and wrong first letter feature enables GeoTAX to look for the correct first letter of a street address if the first letter is missing or incorrect. GeoTAX searches through the alphabet looking for possible correct first letters to complete the street address.

The feature is disabled by default and cannot be enabled in Exact mode.

Use the following to enable this feature:

The following are some examples of wrong, missing first letter, and duplicate first letter input addresses and the corresponding GeoTAX output:

This example includes an incorrect first letter:

Input: 4750 nalnut boulder co 80301Output: 4750 WALNUT ST BOULDER CO 80301-2532

This example excludes a first letter:

Input: 4750 alnut boulder co 80301Output: 4750 WALNUT ST BOULDER CO 80301-2532

This example includes an extra first letter:

Input: 4750 wwalnut boulder co 80301Output: 4750 WALNUT ST BOULDER CO 80301-2532

Batch Processing

Use the Alternate Lookup Option field in the CONFIG parameter card.


Use the cAltLookupOpt element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use MCA-ALTERNATE-LOOKUP-OPT in the Matcher Control Area prior to Calling the GTMATCH program.

Batch Processing

Use the First Letter Expanded Option field in the CONFIG parameter card.


Use the cFirstLetterOpt element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use MCA-FIRST-LETTER-EXP-OPT in the Matcher Control Area prior to Calling the GTMATCH program.


Using Latitude/Longitude coordinates as input

Instead of using addresses or ZIP Codes for matching, latitude/longitude coordinates can be supplied as input.

Use the following to indicate that latitude/longitude coordinates will be used as input:

The required format for the input coordinates is as follows:

• Latitude - 00.000000 or without the decimal point 00000000

• Longitude - 000.000000 or without the decimal point 000000000 or 00.000000 or without the decimal point 00000000

The following sections list the possible fields that can be returned as well as the fields that are not provided when matching using input coordinates.

Returned fields:

• Place Code

• Place Name

• GNIS

• Place Date information (annexed, updated, etc.)

• Place Class Code

• Incorporated flag

• MCD Code

• MCD Name

• State Code (FIPS)

• County Code (FIPS)

• County Name

• ZIP Code

• Boundary file information (from SPD, IPD, PTD, PAY or User)

• Vertex or Taxware file lookup info (GeoTAX Key)

• Payroll Tax Correspondence file lookup information

• Pitney Bowes Software Sales and Use Tax Rate information

Excluded fields:

• Census Tract

Batch Processing

Use the Location of input Latitude, Length of input Latitude, Location of input Longitude and Length of input Longitude fields in the LATLON parameter card.


Use the cLatLongInput element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use MCA-LAT-LONG-INPUT in the Matcher Control Area prior to Calling the GTMATCH program.


• Block Group

• Block ID

• CBSA Code and Name

• CSA Code and Name

• CBSAD Code and Name

• Metro Flag

• Firm Name

• Data Type

• Address Line 1

• Address Line 2

• Last Line

• Any address elements

• City

• State Abbreviation

• ZIP+4

• Any Confidence Codes

Using geocoding featuresThis section contains information on geocoding features and options, and includes the following topics:

• Using geocode placement options

• Using point-level matching

• Using address point interpolation

• Understanding street-level matching

• Using street locator geocoding

• Understanding ZIP Code centroid matching

• Matching to a geographic centroid

• Specifying a fallback geographic centroid search

• Specifying a buffer distance in a boundary search

• Understanding the Early Warning System (EWS)

Using geocode placement options

You can set the following options that affect how GeoTAX calculates the geocode for an interpolated street match.


Offset

Ensures the point does not reside in the middle of a street. Moves the point perpendicular to the portion of the street segment in which it lands by the value you specify. The default value for Offset is 40 feet. You can reconfigure the value to 0, 20, or 60 feet.

Use the following to specify an offset value:

Squeeze

The Squeeze option ensures the point does not reside in an intersection or too close to the end of a street. When Squeeze is enabled, both street and end points are moved closer to the center of the segment by 50 feet. By default, the Squeeze option is enabled. You can disable the option if desired.

Use the following to enable the Squeeze option:

Batch Processing

Use the Latitude/longitude offset amount field in the LLOUT parameter card.


Use the cLatLongOffset element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use MCA-LATLONG-OFFSET in the Matcher Control Area prior to Calling the GTMATCH program.

Batch Processing

Use the Latitude/Longitude Squeeze field in the LLOUT parameter card.


Using point-level matching

Point-level matching locates the center of the actual building footprint or parcel. This is the most accurate type of geocode.

If you are licensed for the point-level data option, you do not need to execute any additional initialization or setup for your system to being using point-level data. GeoTAX automatically processes your address lists through the point-level data.

When processing address lists, GeoTAX first searches for a match in the point-level data. If it cannot find an exact match in the point-level data, GeoTAX continues searching for a better match in the street network data. GeoTAX returns the best match found, with preference given to matches from the point-level dataset.

Using address point interpolation

Address point interpolation uses a patented process that improves upon regular street segment interpolation by inserting point data into the interpolation process. This feature is only for use with point-level geocoding. Use the following to specify address point interpolation:

When a points database is present, more precise address geometry is used for interpolation than what is available by the use of street segments alone.

GeoTAX first attempts to find a match using the loaded points data. If an exact point match is found in the points data, then searching ceases and the point match is returned. If an exact point match was not found, GeoTAX attempts to find high and low boundary address points to use for address point interpolation.

Note: This feature does not work with point addresses in auxiliary files.


Use the cLatLongSqueeze element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use MCA-LL-SQUEEZE-OPT in the Matcher Control Area prior to Calling the GTMATCH program.

Batch processing

Use the Address Point Interpolation Option field in the CONFIG parameter card.


Use the cAddrPtInterpOpt element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use the MCA-ADDRESS-POINT-INTERP-OPT field in the Matcher Control Area prior to Calling the GTMATCH program.


To illustrate the use of this feature, see the following example. In this example, the input house number is 71, and the points database contains address points for 67 and 77.

The street segment ranges from 11 to 501. The street segment contains shape lines describing the actual layout of the street.

GeoTAX attempts to map the points for addresses 67 and 77 onto the closest shape line. After finding a point on the centerline of the street, GeoTAX then performs the interpolation for the input house number 71 with the new street centerline points of 67 and 77.

Without this feature, GeoTAX performs an interpolation with the street segment end points of 11 and 501. This creates a far less accurate result (labeled in the diagram) than using the centerline points of the closest surrounding high and low address points.

If there is a situation where the boundaries found have the same parity but are on opposite sides of the street, in order to determine on which side of the street the address should be, address point interpolation uses information from the matched street segment.

Understanding street-level matching

Street matching identifies the approximate location of an address on a street segment. In street matching, the location is determined by calculating the approximate location of a house number based on the range of numbers in the location’s street, a process referred to


as interpolation. For example, if the address is on a street segment with a range of addresses from 50 to 99, then it is assumed that the house number 75 would be in the middle of the street segment. This method assumes that the addresses are evenly spaced along the street segment. As a result, it is not as exact as point matching since addresses may not be evenly distributed along a street segment.

For example, the following diagram shows the results of street-level matching along a segment with unevenly-spaced buildings. The first three buildings are fairly accurately geocoded because they are evenly spaced. The fourth building, however, resides on a slightly larger parcel than the others along this street. Since street-level matching assumes that the buildings are evenly spaced, the result is that fourth, fifth, and sixth houses are not as precise as the first three. If you were to use point-level geocoding, or address point interpolation, the results would be more accurate.

Using street locator geocoding

Street locator geocoding is an optional feature, which is enabled using the Street Centroid option. When enabled, if an input street address cannot be found using the street number and name, GeoTAX then searches the input ZIP Code or city/state for the closest match. If GeoTAX is able to locate the street, it returns a geocode along the matched street segment rather than the geocode for the entered ZIP Code or ZIP+4.

Use the following to enable street locator geocoding:

If Street Centroid is enabled, and the input address is 5000 Walnut Street, Boulder, CO 80301, and there is no 5000 Walnut Street, GeoTAX searches for the closest match to that address within the input ZIP Code. If there is no input ZIP Code, GeoTAX searches for the closest match to the input address within Boulder, CO.

If the input address is Walnut Street, Boulder, CO 80301, since there is no street number, GeoTAX then searches for that street within the input ZIP Code. As with the previous example, if there is no input ZIP Code, then GeoTAX searches within Boulder, CO for the closest match.

When using street locator geocoding, if no exact matching house number is found, a match code of either E029 (no matching range, single street segment found), or E030 (no matching range, multiple street segment) returns. For example, if you enter Main St and

Batch processing

Use the Street Centroid Option field in the CONFIG parameter card.


Use the cStreetCentroidOpt element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use the MCA-STREET-CENTROID-OPT field in the Matcher Control Area prior to Calling the GTMATCH program.


there are both an E Main St and a W Main St within the input ZIP Code, then an E030 returns and the location code returned is reflective of the input ZIP Code. The location code returned begins with a 'C' when matched to a single street segment, indicated by E029.

GeoTAX does not change the street name on the output address. For more information regarding the match and location codes associated with this feature, see Appendix D: Status Codes and “Street centroid location codes” on page 269.

Understanding ZIP Code centroid matching

ZIP Code centroid matching is a center point of an area defined by either a ZIP Code or a ZIP+4, and is the least accurate type of geocode. A ZIP centroid is the center of a ZIP Code; a ZIP+4 centroid is the center of a ZIP+4. Since a ZIP+4 represents a smaller area than a ZIP Code, a ZIP+4 centroid is more accurate than a ZIP Code centroid.

The following diagram illustrates centroid matching. In the following example:

Only four of the six houses would have the same geocode in this example because only the four reside in the same ZIP+4 code.

Matching to a geographic centroid

If the input address includes a valid combination of city and state (but no further address information), you can still geocode to the city or state centroid. Geographic centroid geocoding is less precise than street or postal geocoding, but may be suitable for certain applications. Geographic centroid geocoding can be accomplished using the Fall-back Geographic option, if GeoTAX cannot match a record to the level or precision you originally requested (such as street level).


For geographic geocoding, GeoTAX returns the most precise geographic centroid that it can, based on the user input. The following table shows some examples of address input and the best possible geographic centroid candidate. For more information on the location codes listed, see “Geographic centroid location codes” on page 272.

Specifying a fallback geographic centroid search

The default search does not perform a search of geographic centroids. When enabled, the Fallback Geographic feature locates the first city and/or state centroid, then matches from the set of possible matches found. Use the following to enable the Fallback Geographic search:

Input address Geocoded to (Location code)

Valid City

Valid State

Troy, NY

City (GM). City and State are valid.

Invalid City

Valid State

Phoenix, NY

State (GS). There is no city of Phoenix in NY, so State is the best possible match.

Valid Major City

Chicago

City (GM). There are approximately 300 U.S. cities recognized as a major city and can be geocoded to the city centroid with no other information provided.

Valid City

No State

No matched candidates. A city name alone is not enough for a match, except if it is one of the recognized Major U.S. Cities.

Valid City

Valid State

Albany, NY

Seven matched candidates. The city of Albany, NY is a close match (GM). Five instances of cities in New York that "sound like" Albany (such as Albion) are non-close GM matches. The state centroid (GS) is also a non-close match.

Invalid City

Valid State

St. Louis, NY

Three matched candidates. The state centroid (GS) is a close match and two city centroids (GM) are non-close "sound like" matches in New York State. If the input contains a state, all matches must be within that state.

Batch Processing

Use the Fallback Geographic Option field in the CONFIG parameter card.


Use the cFallBackGeoOpt element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use MCA-FALL-BACK-GEOGRAPHIC-OPT in the Matcher Control Area prior to Calling the GTMATCH program.


Specifying a buffer distance in a boundary search

You can specify the distance, in feet, to use as a buffer around polygons defined in the standard boundary files or a user-defined boundary file. This is an optional comparison between a point and the buffered zone. The returned data will indicate whether the point is inside the polygon, inside the polygon but in the buffered zone, or outside the polygon but still inside the buffered zone (as shown in the following illustration):

To define the buffer distance for the boundary files (SPD, IPD, PTC & PAY), use the following:

To define the buffer distance with a user-defined boundary file, use the following:

Note: The buffer distance for place and cousub files is internally set to zero and cannot be modified, so that only one place and one MCD is returned for each type of associated match.

Note: The spatial calculations that are required to perform buffer distance functions consume a lot of processing power and will decrease the throughput of the process.

The results for the point comparison to a buffered area on a boundary is covered in “Distance & status returns for a point comparison to a boundary” on page 83.

Batch processing

Use the Input buffer distance field in the BUFOUT parameter card.


Use the szBoundaryBuffDist element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use the MCA-BOUNDARY-BUFFER-DIST field in the Matcher Control Area prior to Calling the GTMATCH program.

Batch processing

Use the Input buffer distance field in the BF2OUT parameter card.


Use the szUserBoundBuffDist element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use the MCA-USER-BND-BUFFER-DIST field in the Matcher Control Area prior to Calling the GTMATCH program.


Using USPS matching enhancements

Understanding the Early Warning System (EWS)

The Early Warning System (EWS) provides up-to-date address information for new and recently changed addresses that have not yet been updated in the monthly USPS data updates. EWS prevents address records from miscoding due to a delay in postal data reaching the USPS address matching files.

The older the U.S. Postal Databases, the higher potential you have for miscoding addresses. When a valid address is miscoded because the address it matches to in the U.S. Postal Database is inexact, it will result in a broken address.

EWS data consists of records containing partial address information limited to the Zip Code, street name, pre-directional, post-directional, and a suffix. For an address record to be EWS-eligible, it must be an address not present on the most recent monthly production U.S. Postal Database.

The USPS refreshes the EWS file on a weekly basis. You can download the EWS file from the USPS Web site at http://ribbs.usps.gov/files/CASS/.

Note: In order to use the USPS-supplied EWS file, GeoTAX requires that the EWS file be named ews.txt and be located in the GeoTAX data search path. The date of the EWS file must be the same month or newer than your GeoTAX data files.

Match results and return valuesGeoTAX offers a number of options for viewing the status, results and attributes of the address matching and geocoding operations. This section describes the GeoTAX return codes and values which include:

• General Return Codes

• Latitude/Longitude Level Return Codes

• Street Matcher Return Codes

• Match and Location Codes

• Confidence levels & Confidence surface types

• Distance & status returns for a point comparison to a boundary

General Return Codes

The General Return Codes provide information about the type of match or the status of the matching process, such as:

• File used for matching: Landmark, User Auxiliary, GeoTAX Auxiliary, state-supplied

• Level of match: Point, Street, Street Centroid, ZIP Code or ZIP+4

• Match using Fall-back Geographic feature

http://ribbs.usps.gov/files/CASS/

http://ribbs.usps.gov/files/CASS/


• Match using Lat/Long inputs

• Aborted processing, expired database or no match results

Use the following to view the General Return Codes:

Latitude/Longitude Level Return Codes

The Latitude/Longitude (Lat/Long) Level Return Codes provide information about the attributes of the latitude/longitude coordinate or the status of the geocoding process, such as:

• Type of centroid: Point, Address, ZIP Code, ZIP+2, ZIP+4, Block group, Census tract, City or State centroid using Fall-back Geographic match feature

• File used for matching: Landmark Auxiliary file, GeoTAX Auxiliary file, Point data file

• Latitude/longitude coordinate not determined

Use the following to view the Lat/Long Level Return Codes:

Street Matcher Return Codes

The Street Matcher Return Codes provide the reasons for not successfully completing the street matching process, such as:

• ZIP Code not found in street address database

• Street not found in ZIP Code

• House number not found on street

Use the following to view the Street Matcher Return Codes:

Batch processing

Refer to the Location for 1-byte General Return Code field specified in the GEOOUT parameter card.


Refer to the cGenRC element in the GTXOUTPUT Output Structure.

Callable Functions

Refer to the MOA-GRC field in the Matcher Output Area (MOA).

Batch processing

Refer to the Location for 1-byte Lat/Long Level field specified in the LLOUT parameter card.


Refer to the cLatLongLevel element in the GTXOUTPUT Output Structure.

Callable Functions

Refer to the MOA-LATLONG-LEVEL field in the Matcher Output Area (MOA).

Batch processing

Refer to the Location for 1-byte Street Matcher Return Code field specified in the GEOOUT parameter card.


Refer to the cStreetORC element in the GTXOUTPUT Output Structure.

Callable Functions

Refer to the MOA-STREET-O-RC field in the Matcher Output Area (MOA).


Match and Location Codes

The Match and Location Codes are only returned when matching to the Points or Streets data files. These return codes provide detailed information about the status and results of the address matching and geocoding operations. This section describes these two codes.

Match Codes

The address matching process returns a Match Code that provides information about the quality of the match. The Match Code indicates the differences between the input address and the reference address to which the address was matched. The match ratings are described in “Match Codes” on page 263. This code also defines what elements of an input address were modified, or the reason a match was not made.

Use the following to view the Match Codes:

Location Codes

GeoTAX returns location codes that indicate the methodology used to compute the geocode and may also provide some information about the quality of the geocode. The location codes are described in “Location codes” on page 265.

Use the following to view the Location Codes:

Geographic determination and confidence levels

This section describes the option to have GeoTAX compare a point to some other geographic entity and return data that describes that spatial relationship. The optional information returned can include:

• Confidence levels

• Confidence surface types

The types of data files that can be used for the comparison include:

• Boundary files, such as:

– Special Purpose Districts

Batch processing

Refer to the Location for 4-byte Address Match Return Code field specified in the ALOUT parameter card.


Refer to the szAMMatchCode element in the GTXOUTPUT Output Structure.

Callable Functions

Refer to the MOA-ADDR-MATCH-CODE field in the Matcher Output Area (MOA).

Batch processing

Refer to the Location for 4-byte Location Return Code field specified in the LLOUT parameter card.


Refer to the szAMLocationCode element in the GTXOUTPUT Output Structure.

Callable Functions

Refer to the MOA-ADDR-LOC-CODE field in the Matcher Output Area (MOA).


– Insurance Premium Districts– Payroll Districts– Personal Property Districts– User-defined Boundary file

• Local Jurisdiction files, such as:

– Place file– County file– Minor Civil Division/County subdivision file

The rest of the section covers these topics in more detail and explains how to implement geographic determination functionality and the reporting features.

Confidence levels

After an address has been cleansed and a geocode has been assigned for the location, a confidence level can optionally be computed and returned. The confidence level provides the percentage overlap of a geocode to a polygon layer. The polygon layer can be specified as a boundary (e.g. Special Purpose Districts), a user-defined geography layer, or a place, county or county subdivision. The returned percentage value describes the probability that a point falls in the comparison area. This addresses an often typical problem of whether or not an address falls inside a specific area.

Confidence surface types

To determine a confidence level, a confidence surface is first generated. The confidence surface provides the smallest possible area wherein an address is likely to be located. Based on the GeoTAX location code, a buffer is build around a given location that indicates the confidence surface that will contain it. If the match is a ZIP Code-level match, then the ZIP Code boundary itself is used as the confidence surface. The reported surface types that can be generated and reported include:

• Intersection confidence-surface

• Interpolated street segment

• Point level match

• State confidence-surface

• County confidence-surface

• City confidence-surface

• ZIP Code confidence-surface

• ZIP+2 Code confidence-surface

• ZIP+4 Code confidence-surface

• Street centroid confidence-surface


Use the following to view the status of the confidence-generation process and the returned confidence surface type:

Boundary files

An address can be compared to a boundary file and report the probability that a point falls in the comparison area. When the boundary confidence option is enabled, a confidence level is returned for the input address. The following boundary files are supported:

• Special Purpose Districts (SPD), if licensed

• Insurance Premium Districts (IPD), if licensed

• Payroll Districts (PAY), if licensed

• Personal Property Districts (PTD), if licensed

• User-defined Boundary file (USR)

Note: The boundary file will first need to be loaded and set up for use in matching. For more information, see “Loading GeoTAX Data” on page 23.

Note: In order to get confidence returns when using Boundary files, the input buffer distance must be specified. See “Specifying a buffer distance in a boundary search” on page 74.

Special Purpose Districts

When matching to an SPD boundary file, use the following to enable the return of boundary confidence levels:

Use the following to view the returned SPD boundary confidence levels:

Batch processing

Refer to the Location for 2-byte Confidence Type field specified in the CNFOUT parameter card.


Refer to the szConfSurfaceType element in the GTXOUTPUT Output Structure.

Callable Functions

Refer to the MOA-SURFACE-TYPE field in the Matcher Output Area (MOA).

Batch processing

Use the Output location for 3-byte SPD Confidence Code field in the SPDOUT parameter card.


Use the cBoundaryConfidence element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use the MCA-BOUNDARY-CONF field in the Matcher Control Area prior to Calling the GTMATCH program.

Batch processing

Refer to the Output location for 3-byte SPD Confidence Code field specified in the SPDOUT parameter card.


Refer to the szBoundConfidence element in the GTXOUTPUT Output Structure.

Callable Functions

Refer to the MOA-CONF-BND field in the Matcher Output Area (MOA).


Insurance Premium Districts

When matching to an IPD boundary file, use the following to enable the return of boundary confidence levels:

Use the following to view the returned IPD boundary confidence levels:

Payroll Districts

When matching to a PAY boundary file, use the following to enable the return of Payroll Districts boundary confidence levels:

Use the following to view the returned PAY boundary confidence levels:

Personal Property Districts

When matching to a PTD boundary file, use the following to enable the return of boundary confidence levels:

Batch processing

Use the Output location for 3-byte IPD Confidence Code field in the IPDOUT parameter card.



Callable Functions


Batch processing

Refer to the Output location for 3-byte IPD Confidence Code field specified in the IPDOUT parameter card.



Callable Functions


Batch processing

Use the Output location for 3-byte PAY Confidence Code field in the PAYOUT parameter card.



Callable Functions


Batch processing

Refer to the Output location for 3-byte PAY Confidence Code field specified in the PAYOUT parameter card.



Callable Functions


Batch processing

Use the Output location for 3-byte PTD Confidence Code field in the PTDOUT parameter card.



Callable Functions



Use the following to view the returned PTD boundary confidence levels:

User-defined Boundary file

An address can be compared to a user-defined boundary file. When the boundary confidence option is enabled, a confidence level is returned for each input address. Refer to the directions in “User-Defined Boundary File” on page 50 to download and set up matching to this file.

Use the following to enable the return of confidence levels:

Use the following to view the returned boundary confidence levels:

Local Jurisdiction files

Place file

An address can be compared to a place file (place.txb is supplied with the GeoTAX install). When the place confidence option is enabled, a confidence level is returned for each input address.

Use the following to enable the return of place confidence levels:

Batch processing

Refer to the Output location for 3-byte PTD Confidence Code field specified in the PTDOUT parameter card.



Callable Functions


Batch processing

Use the Output location for 3-byte USR Confidence Code field in the USROUT parameter card.


Use the cUserBoundaryConfidence element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use the MCA-USER-BOUNDARY-CONF field in the Matcher Control Area prior to Calling the GTMATCH program.

Batch processing

Refer to the Output location for 3-byte USR Confidence Code field specified in the USROUT parameter card.


Refer to the szUserBoundConfidence element in the GTXOUTPUT Output Structure.

Callable Functions

Refer to the MOA-CONF-USER-BND field in the Matcher Output Area (MOA).

Batch processing

Use the Output location for 3-byte Place Confidence Code field in the CNFOUT parameter card.


Use the cPlaceConfidence element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use the MCA-PLACE-CONF field in the Matcher Control Area prior to Calling the GTMATCH program.



County file

An address can be compared to a county file (counties.gsb is supplied with the GeoTAX install). When the county confidence option is enabled, a confidence level is returned for each input address.

Use the following to enable the return of county confidence levels:


Minor Civil Division/County subdivision file

An address can be compared to a Minor Civil Division (MCD)/county subdivision file (cousub.txb is supplied with the GeoTAX install). When the MCD confidence option is enabled, a confidence level is returned for each input address.

Use the following to enable the return of MCD confidence level:

Batch processing

Refer to the Output location for 3-byte Place Confidence Code field specified in the CNFOUT parameter card.


Refer to the szPlaceConfidence element in the GTXOUTPUT Output Structure.

Callable Functions

Refer to the MOA-CONF-PLACE field in the Matcher Output Area (MOA).

Batch processing

Use the Output location for 3-byte County Confidence Code field in the CNFOUT parameter card.


Use the cCountyConfidence element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use the MCA-COUNTY-CONF field in the Matcher Control Area prior to Calling the GTMATCH program.

Batch processing

Refer to the Output location for 3-byte County Confidence Code field specified in the CNFOUT parameter card.


Refer to the szCountyConfidence element in the GTXOUTPUT Output Structure.

Callable Functions

Refer to the MOA-CONF-COUNTY field in the Matcher Output Area (MOA).

Batch processing

Use the Output location for 3-byte MCD Confidence Code field in the CNFOUT parameter card.


Use the cCousubConfidence element in the GTXINPUT parameter structure prior to calling GTXMatchAddress.

Callable Functions

Use the MCA-COUSUB-CONF field in the Matcher Control Area prior to Calling the GTMATCH program.


Use the following to view the returned MCD confidence level:

Distance & status returns for a point comparison to a boundary

Results for a comparison between a point and a buffered boundary zone (see “Specifying a buffer distance in a boundary search” on page 74) include the distance of the point to the polygon and the status of the point location relative to the polygon. As shown in the illustrations below, the status indicates whether the point is inside the polygon, inside the polygon but in the buffered zone, or outside the polygon and inside the buffered zone

Results for point comparison to a buffered area using a boundary file

SPD, IPD, PTD & PAY Boundary files

Use the following to view the results for a point comparison to a buffered area on a boundary:

Batch processing

Refer to the Output location for 3-byte MCD Confidence Code field specified in the CNFOUT parameter card.


Refer to the szMCDConfidence element in the GTXOUTPUT Output Structure.

Callable Functions

Refer to the MOA-CONF-COUSUB field in the Matcher Output Area (MOA).

Batch processing

Refer to the District # buffer status and output distance fields specified in the BUFOUT parameter card.


Refer to the cBuffRetCode and szBuffDist elements in the TAXDISTRICT data structure.

Callable Functions

Refer to the MOA-TAX-DIST-BUFFER-RC and MOA-TAX-DIST-DISTANCE fields in the Matcher Output Area (MOA).

The point is inside the polygon and not in the buffer area.

The output field will contain “P”.

The point is inside the polygon and in the buffer area.

The output field will contain “I”.

The point is outside the polygon and is in the buffer area.

The output field will contain “B”.


User-defined Boundary file

Use the following to view the results for a point comparison to a buffered area on a boundary:

Results for point comparison to a buffered area using a Local Jurisdiction file

Place point status & distance

Use the following to view the returned place point status and distance to border:

MCD point status & distance

Use the following to view the returned MCD (cousub) point status and distance to border:

Batch processing

Refer to the District # buffer status and output distance fields specified in the BF2OUT parameter card.


Refer to the cUserBuffRetCode and szUserBuffDist elements in the USERTAXDISTRICT data structure.

Callable Functions

Refer to the MOA-USR-DIST-BUFFER-RC and MOA-USR-DIST-DISTANCE fields in the Matcher Output Area (MOA).

Batch processing

Refer to the Location for 10-byte Place Point status & distance field specified in the CNFOUT parameter card.


Refer to the cPlacePointStatus and szPlaceBuffDist elements in the GTXOUTPUT Output Structure.

Callable Functions

Refer to the MOA-PLACE-BUFFER-RC and MOA-PLACE-DISTANCE fields in the Matcher Output Area (MOA).

Batch processing

Refer to the Location for 10-byte MCD Point status & distance field specified in the CNFOUT parameter card.


Refer to the cMCDPointStatus and szMCDBuffDist elements in the GTXOUTPUT Output Structure.

Callable Functions

Refer to the MOA-COUSUB-BUFFER-RC and MOA-COUSUB-DISTANCE fields in the Matcher Output Area (MOA).

6 – Setting up and running a Batch Job

This chapter outlines the steps required for defining and executing your batch job and covers the following topics:

In this chapter

Overview 86The Matching Process 87Creating and running a GeoTAX batch job 88


OverviewThe batch system, governed by program GTBM00, appends census and geographic code information to your input name-and-address records based on parameters you enter. You use the parameter records to:

• Specify information about the layout of the data in the name-and-address records.

• Define the content and layout of your output records.

• Specify headers and footers for GeoTAX reports.

• Define the data and the number of lines printed on each page of the reports.

• Specify what census and geographic data should be applied.

When you submit the parameter records and input file for processing, the GeoTAX batch system:

• Appends the requested census and/or geographic data for matched records.

• Generates the processing reports and, if requested, a non-coded records file.

GeoTAX is governed by parameter records and control language. You can use them independently or combine them to work together.

Parameter Records

Parameter records contain your processing instructions for GeoTAX that tell the program what you want to accomplish. Through parameter records, you specify:

• The format of your input file

• The location, length, and format of each relevant data element in your input file

• The processing options to perform on each input record

• The output files to create

• The location, length, and format of additional output record data elements (such as latitude/longitude, and FIPS state codes)

• The reports to print at the end of the job

• The headers, footers, and lines per page for your reports

For information on how to set up a parameter record, see “Creating and editing the Parameter Record” on page 89.

Control Language

In addition to writing parameter records to manage your job, you need to write control language. Control languages vary depending on the processing platform, but their purpose is to define the operating environment and execute the programs that process your records. The control language provided in this manual is for example purposes only and must be modified to meet your site-specific needs.


The following table shows the control languages used by each of the platforms supported by GeoTAX.

Combining Parameter Records and Control Language

You can combine parameter records and control language by pointing to a file that contains all of your parameter records from your control language.

The Matching ProcessThe following instructions explain each step in the matching process.

1. (Optional) Some features of GeoTAX require you to build certain files before executing your batch job. GeoTAX provides utilities for building these files into a format it can read. The type of file you need depends on what you are trying to accomplish:

• To cross-reference GeoTAX output with a tax program such as Vertex or Taxware, install a cross-reference file.

• To match to customized address information and non-address locations such as well heads, transmission towers or any other descriptive location, create and install a Landmark Auxiliary file.

• To match your input records to your own street address data, create and install a User Auxiliary file.

• To make sure to use the most up-to-date data available, install the GeoTAX Auxiliary file

• To match your input records to a state-supplied listing, download and install a state-supplied street address database.

• To determine if an address is within a district that is defined in a file you have, and not one of the available Pitney Bowes boundary files, create a user-defined boundary file.

• To determine the payroll code for a district, create the Payroll Tax Correspondence (PTC) file.

• To return sales and/or use tax rate data for a selected industry (general, automotive, construction or medical) in your GeoTAX output records, install the Pitney Bowes Software Sales and Use Tax Rate file.

2. Run your input file through GeoTAX using the batch driver or calling GeoTAX's matcher. GeoTAX first attempts a match to the Landmark Auxiliary file, if one exists. Then, based on the settings you chose in your parameter records, GeoTAX will match to the User Auxiliary file, the state-supplied file, or the GeoTAX Auxiliary file prior to matching to the Points and/or Streets file. If a street-level match is not possible, GeoTAX attempts postal

Processing Platform Control Language

UNIX Shell Scripts

Windows Scripts

z/OS JCL


matching at the ZIP+4 level, and so on, depending on the parameters you specify and the available data. Matched FIPS geocodes and names are appended to your input records.

3. You can tailor your GeoTAX output using the following options:

• For Vertex system users, jurisdiction geocodes can match to Vertex geocodes by using the Cross Reference file (built in Step 1). This jurisdiction-to-Vertex geocode conversion, referred to as the GeoTAX key, outputs a nine-digit Vertex jurisdiction code (comprised of a two-digit Vertex state code, three-digit FIPS county code, and four-digit Vertex city code) for each matched record. The GeoTAX key is then used to match these codes to the Vertex tax tables, which tell you the tax rate for each jurisdiction.

• For Taxware users, a process similar to that described above is available. After building the Taxware data files, you can have GeoTAX return a Taxware key. This key (also called the GeoTAX key) is used to convert the jurisdiction codes from GeoTAX to the proprietary Taxware codes used in their software. You can then use that data in your Taxware application to find out the tax rate for each jurisdiction.

• For users of GIS mapping systems such as those provided by MapInfo, you can tell GeoTAX to produce a file called GTBMARC. This output file contains fixed-length, comma-delimited data. By default, latitude and longitude are provided for each record. The remaining fields are user-defined. The GTBMARC file can then be imported to your mapping program so you can view geocoded records on a map.

Creating and running a GeoTAX batch jobThe following sections contain information on creating a GeoTAX job.

Parameter Record Reference

This table describes which parameter records are associated with each step of a GeoTAX job. Refer to Appendix B: GeoTAX Parameter Record Reference for definitions of each parameter record.

Job Step Parameter Records Used

Defining the physical attributes of input and output files

FILEDF

A separate FILEDF is required for each input, output, and parameter file

Defining the layout and content of input records

ADDRDFFIRMNM

CONSxxLATLON

CS ZIPMOVE I

Defining the layout and content of output records

AEOUTAUXOUT CBSOUTGEOOUTIPROUTPAYOUTPTDOUTTAXOUT

ALOUTBF2OUTCNFOUTLLOUTMCDOUTPCOUTSPDOUTUSROUT

ARCOUT BUFOUTDISTITIPDOUTMOVE OPTCOUTSTEOUT


Creating and editing the Parameter Record

The GeoTAX installation includes a sample parameter record file in the GeoTAX data folder called SAMPLE.PRM. This file can be used as a template to create your parameter record. Simply copy SAMPLE.PRM, rename the file, then edit it using a text editor.

As shown in the screenshot of SAMPLE.PRM below, the first two lines in the file are comments (denoted by the asterisk at the beginning of the lines); these two lines provide column numbering up to 80. The fields in the parameter cards need to be located in specific column positions, so these first two lines serve as a guide when entering parameter field values in your parameter record file.

Step 1: Copy the Sample Job File

The GeoTAX installation process copies an IVP (installation verification procedure) file to your system. This is a basic job that confirms the proper installation of the application files and programs. The sample job is useful as a template for new jobs since it contains the minimum required organization and content.

The first step in defining your GeoTAX job is to copy the sample job for your own purposes.

On Windows:

To copy the sample job:

1. Access the applicable drive and GeoTAX data folder, for example ...GeoTAX\data.

2. Copy sample.prm and rename it as a template for the new job, for example myjob.prm.

Note: The name you choose must be the same for the .bat file and is used to name all output data, reports, and Execution Logs by default.

3. Access the applicable drive and bin folder, for example ...GeoTAX\bin.

Defining processing options CONFIG CONFRM TESTIT

Defining reporting options HEADERUFTxx

PAGESZUHDxx

REPORT

Job Step Parameter Records Used


4. Copy sample.bat and rename it as a template for the new job, for example myjob.bat.

5. From Start, select All Programs > Pitney Bowes > GeoTAX > Edit GeoTAX Batch Job.

6. When the GeoTAX window opens, enter the name, for example myjob, and click OK.

7. When the file opens, re-define the G1JOB variable from SAMPLE to your job name (in this example myjob) and the locations of the input and output files of the GeoTAX data you want to store.

8. Copy your input file of addresses etc. into your applicable data folder and rename it to the same name as the bat and give it an extension of nam. For example myjob.nam.

OR

Edit your bat job and modify the “SET DD_GTBMNAM=%G1GTX%\data\%G1JOB%.NAM” statement to the location and name of your file.

On UNIX/Linux:

To copy the sample job:

1. Go to the /bin directory.

2. Source the setup file. For example, enter:

. ./setup

This is necessary at login time and it is usually not necessary to repeat during the session.

3. Copy sample to newname, where newname is the name you assign to the job.

For example, to create a job called myown, enter the following:

cp sample myown

Note: The name you choose is used to name all output data, reports, and Execution Logs by default.

4. Edit the file created above.

On z/OS:

1. Edit dataset yourhlq.GEOTAX.CNTL that was installed with GeoTAX.

2. Create a new member and copy member IVPFILE into it.

3. Add a job card and modify as necessary. Parameter records are instream under DD GTBMPRM. If desired, they may be put in a separate JCL member and the dataset name referred to in DD GTBMPRM.


Step 2: Define the Physical Attributes of Your Files

The second step to creating a GeoTAX job is to define the physical attributes of your input and output files. You define some or all of the following:

• GTBMPRM—This required file contains all the parameter records for your job.

• GTBMNAM—This required file contains your input name-and-address records.

• GTBMCOK—This required file contains all of the records matched by GeoTAX.

• GTBMNCO—This optional file contains all of the records that GeoTAX could not match.

• GTBMPLC—This optional file contains records that are coded with a non-zero/non-space place code.

• GTBMARC—This optional file contains data you specify to use as input to a geographic mapping application, such as ESRI’s ArcView or MapInfo.

Define each of these files by creating a FILEDF parameter record as shown in the highlighted area in the example below. Remember each input and output file requires a separate FILEDF parameter record.

Step 3: Define the Layout of Input Record Elements

To define the data elements contained in your input records, you need to create parameter records to specify the type and format of input data. For example, the format of the addresses and the locations and lengths of the elements that make up those addresses, such as street and ZIP Code.

Parameter Record Description

ADDRDF Specifies the format, location, and length of each address line or field. Required if doing a street match; optional if doing a postal match.

CS ZIP Specifies the location, length, and format of city, state, and ZIP Code fields. Required.

CONSxx Allows you to define up to 99 constants to use with the MOVE I or MOVE O parameter records. Optional.


You define some or all of these parameter records as shown in the highlighted area in the example below, depending on your processing requirements.

Step 4: Define the Layout & Content of Output Record Elements

The next type of information you define is the layout and content of the records that GeoTAX writes to the output files. You specify locations, lengths, and sometimes formats for the following types of data elements:

• Latitude and longitude information

• Core Based Statistical Area codes (CBSAs) and names

• Minor Civil Divisions (MCDs)/Census County Divisions (CCDs) codes and names

• Census codes, such as state, county, place, Census Tract, Block Group, and Block ID

• Tax rate data such as state, county and municipality sales and use tax rates when using the optional Pitney Bowes Tax Rate reference file

• User-defined information stored in the Landmark Auxiliary or User Auxiliary files

FIRMNM Specifies that firm or building names are used as inputs for matching. Optional.

LATLON Specifies that latitude/longitude coordinates are used as inputs for matching. Optional.

MOVE I Allows you to rearrange pieces of the input records before they are processed. Optional.



You define some or all of these parameter records, as shown in the highlighted area in the example screenshot below, depending on your processing requirements.


AEOUT Post output (normalized or standardized) Address Elements to your output records.

ALOUT Post output Address Lines and Last Line elements to your output records.

ARCOUT Specifies the data elements to post in the GTBMARC file other than latitude and longitude coordinates (for import to a mapping application).

AUXOUT Specifies the location and length of data to post (on the output record) from the user-defined Auxiliary file.

BF2OUT Set the buffering distance and post the buffering information from the user-defined boundary file to your output records.

BUFOUT Set the buffering distance and post buffering information from a boundary file (PTD, PAY, SPD, and IPD) to your output records.

CBSOUT Post CBSA names and codes to your output records.

CNFOUT Calculate and post Confidence Codes, Place Code status and distance to your output records.

DISTIT Calculate and post the distance between two sets of latitude/longitude coordinates.

GEOOUT Post the matched geographic codes to your output records, including FIPS state and county codes, Census Tract, Block Group, Block ID, state abbreviation, and county name.

IPDOUT Post matched data from the optionally-licensed Insurance Premium District (IPD) file to your output records.

IPROUT Allows GeoTAX to provide a way to specify the posting of additional Insurance Premium Tax District (IPD) data to your output records to enhance tax jurisdiction assignment.

LLOUT Post the matched latitude/longitudes to your output records. Also allows you to set latitude/longitude formats and matching levels (street level or postal level).

MCDOUT Post the MCD/CCD names and codes to your output records.


Note: GeoTAX creates output records by first copying the input record to the output area then reading all output parameter records and writing the data elements they describe to the desired locations.

When defining output locations for your data elements, it is easy to accidentally overwrite input data you want to preserve with output data. Unless you intentionally want to overwrite input data, you should specify locations for your output elements beyond the input data.

Step 5: Define Processing Options

To define the processing options that control your GeoTAX job, create parameter records that:

• Define the processing configuration used to process your input file. This configuration consists of search options and matching preferences.

• Write records with a specific input field value directly to the GTBMCOK file without being processed. This procedure is called automatic confirmation.

• Indicate that the parameter records in your job should be checked for errors without actually executing the job.

MOVE O Allows you to rearrange pieces of the output record before it is written to the output file.

PAYOUT Post matched data from the optionally-licensed Payroll Tax District (PAY) file to your output records.

PCOUT Post Place Codes and names to your output records.

PTCOUT Post matched data from the Payroll Tax Correspondence (PTC) file to your output records.

PTDOUT Post matched data from the optionally-licensed Property Tax District (PTD) file to your output records.

SPDOUT Post matched data from the optionally-licensed Special Purpose Tax District (SPD) file to your output records.

STEOUT Post additional data from the State-supplied database (either Florida-native or TS-158 format) to your output records.

TAXOUT Post tax rate data from the optionally-licensed Pitney Bowes Software Sales and Use Tax Rate file to your output records.

USROUT Post district information from the User-Defined Boundary file to your output records.



You define some or all of these parameter records, depending on your processing requirements:

Step 6: Define Reporting Options

You can print several optional reports with GeoTAX in addition to those printed automatically. You can also determine some of the format options for your reports.

Defining Which Reports to Print

The following required reports are printed automatically for every job:

• Parameter Record Listing (.RPT)

• Execution Log (.XLG)

• Control Totals (.RPT)

Use the REPORT parameter record to print or suppress the following reports:

• Coding Percentages per State/County

• Coding Percentages per State

• Jurisdictional Accuracy Management System (JAMS) Report

Note: The default is to print the coding percentage reports for your job. Unless you want to suppress any of these, you do not need to include a REPORT parameter record in your job.

The JAMS report automatically presents the results of running the State-supplied address list test data through GeoTAX as part of the certification process. Organizations that collect and disburse sales and use taxes can use the JAMS report results to submit to the State Department of Revenue as part of the certification process. For information on printing the JAMS report, see the REPORT parameter record.

Defining Report Formats

While the format for the body of all reports is internally set by GeoTAX, you can control the layout and content of the headers and footers of the reports as well as the number of lines that are printed on each report page. You write parameter records to accomplish the following report formatting:

• Control the main header

• Control the additional header


CONFIG Specifies what search and matching features to implement during processing and which data files to use for matching.

CONFRM Write records to the output file that possess a certain input field value without going through the matching process.

TESTIT Run the job to check for parameter record errors.


• Control the footer

• Specify the number of lines per page

Headers and Footers

There are two kinds of headers and one kind of footer on all GeoTAX reports. The types of headers are:

• Main Header—Generated according to your specifications on the HEADER parameter, this single-line header includes a date (either the system date or another date you specify) and/or up to 40 characters of text. This header line appears just above the main body of the report page.

• User Header—Generated according to your specifications on the UHDxx parameter, this header can comprise up to four lines of text. Each line can contain up to 132 characters. These lines are printed above the main header.

The single type of footer is a user footer. The footer is generated according to your specifications in the UFTxx parameter and can comprise up to four lines of text. Each line can contain up to 132 characters. These lines are printed below the body of the report page.

For example, a report with all lines of all headers and footers defined is formatted as follows:

User Header Line 1User Header Line 2User Header Line 3User Header Line 4

Main Header

.

.

.Body of Report...

User Footer Line 1User Footer Line 2User Footer Line 3User Footer Line 4


The setup for a user header, footer and main header in the parameter reference file is shown in the highlighted area in the example screenshot below.

Lines per Page

You can also specify the number of lines to print on each report page by defining the PAGESZ parameter card.

Step 7: Write Control Language

Make sure your data files are installed (for directions, see “Loading GeoTAX Data” on page 23). Review your job file and verify the commands in the script point to the correct locations of the data files and the required input files and any optional input files.

Step 8: Run the job

To initiate running the batch job:

On Windows:

From Start, select All Programs > Pitney Bowes > GeoTAX > Run GeoTAX Job. A dialog window displays.

1. In the dialog window, enter the name of the job to be run in the text input field and click OK.

2. When the job completes, a window displays and prompts you to view the results. If you click Yes, the execution log (.XLG) will be displayed. To view detailed results, open the report file (.RPT or .RPT.RTF).

On UNIX/Linux:

1. Source your setup in the bin directory.

2. Source your job file. (The shell script sets up the job environment variables).

3. Execute rungtx - this is a background operation. When the job completes, the .xlg, .rpt, and .log output files in the .../gtx/data path folder can be viewed to see the status of the job or you can examine the runcbl process.


On z/OS:

After modifying the necessary items and adding a jobcard, submit the JCL. View the output in the output facility of your choice (i.e., SDSF, IOF) and via browsing output data files.

7 – Interactive Address Matching

This chapter describes the GeoTAX Matcher utility used for interactive matching.

In this chapter

GeoTAX Matcher Overview 100Standard GeoTAX Matcher 100


GeoTAX Matcher OverviewYou can enter a single input record in the GeoTAX Matcher to interactively match against the GeoTAX data. This functionality provides a way to do a quick test to verify the matching process is working or to research and retrieve information on one specific record.

Standard GeoTAX MatcherYou can use the standard GeoTAX Matcher for the Windows, UNIX/Linux, and z/OS system platforms. This section covers:

• Launching the Interactive System

• Matcher input field definitions

• Matcher Function keys and command definitions

• Using the Matcher

• Matcher results

Launching the Interactive System

On Windows:

You can launch the interactive matcher and inquiry functions in two ways:

• Select Start > Programs > Pitney Bowes > GeoTAX > GeoTAX Matcher.

• In a DOS Command Line window, change the directory to the bin folder of the GeoTAX install directory. Type GTXMAT for Matcher at the command prompt.

Once the Matcher launches, the matching screen opens (see Figure 1).

On UNIX/Linux:

To launch the interactive matcher:

1. Source the setup file.

2. Execute the runonline command.

On z/OS:

After the CICS installation completes (see “CICS Installation” on page 22), transaction G1GT brings up the interactive matcher in the CICS region.


Figure 1: Components of the Address Matching Screen

Matcher input field definitions

The following table describes the input fields in the Matcher. The standardized address information will be returned to these input address locations.

Field Name Description

Address Input Fields

Firm Name Name of the firm for your input record. For example, PITNEY BOWES SOFTWARE.

Primary Addr Primary address line for your input record. For example, 4750 WALNUT STREET.

Secondary Addr Secondary address line for your input record. For example, SUITE 200.

City, ST City and state for your input record. You can enter the state name or abbreviation. For example, BOULDER, CO.

ZIP Code ZIP Code for your input record. For example, 80301.

Command Input command line. For example, RFSH.

Status Fields - the following fields can be changed using the function keys/commands provided in the next section.

Offset Indicates street offset setting: 0, 20, 40, 60

Squz Indicates if Lat/Long Squeeze is enabled: Y, N

GTXKey Indicates the cross-reference file for matching: TXW, NVT, or VTX.

Boundary Indicates the boundary file for matching: SPD (default), PAY, IPD, PTD, or USR.

State Indicates whether a State-supplied file is used for matching: Y or N (default)

Input A

reaM

atch R

esults

Function Keys


Matcher Function keys and command definitions

You can use commands to execute other processing tasks. Some commands have associated function keys. The following table describes the different commands available.

Function Key Command Description

F3 QUIT Exit GeoTAX Matcher.

F5 REFRESH Refresh the screen to enter another address for matching.

F7 TOP Scroll up through the districts.

F8 DOWN Scroll down through the districts.

SPD Matches to the SPD file; Boundary: SPD.

IPD Matches to the IPD file; Boundary: IPD.

PTD Matches to the PTD file; Boundary: PTD.

PAY Matches to the PAY file; Boundary: PAY.

USR Matches to the User-Defined Boundary file.

NOBND Does not match to a boundary file; Boundary.

State Matches to the state-supplied file.

TXW Matches to the Taxware file. Automatically matches to the SPD file; Boundary: SPD (default)

NVT Matches to the Pitney Bowes Software Vertex file. Automatically matches to the SPD file; Boundary: SPD.

VTX Matches to the Vertex file.

NOSQUEZ Turns squeeze option off; Squz: N

SQUZ Turns squeeze option on; Squz: Y (default)

NOOFFSET Sets offset indicator to zero; Offset: 0

OFFSET20 Sets offset indicator to 20 feet; Offset: 20

OFFSET40 Sets offset indicator to 40 feet; Offset: 40 (default)

OFFSET60 Sets offset indicator to 60 feet; Offset: 60

NEXTM When the Match Level is “M” (multiple), shows the results of the next multi-match candidate.


Using the Matcher

To enter address and matching parameters into the Matcher:

Use either the TAB key or the keyboard arrow keys to navigate to the input fields in the matcher.

1. Optional. Enter the file match type in the Command field, such as IPD, for matching to the IPD boundary file. Refer to the Matcher Function keys and command definitions table in the previous section for Command options.

2. Click TAB. The Boundary field displays the entered file match type.

3. Navigate to and enter the address information in the address fields. Any combination of Primary Address, City/State, and ZIP Code can be entered to obtain a match (or ZIP Code alone to get a ZIP Code match).

4. Tab through the remaining entry fields (or use the Enter key at any point to get the match results). After tabbing past the Command field, the matching results data displays in the lower portion of the Matcher screen. To understand the match information, refer to the Matcher results table in the following section.

Matcher results

The following table defines the results provided by the GeoTAX Matcher.


Results Fields

Match Level Indicates the level at which GeoTAX matched the input address with the databases.

5 ZIP Code match

9 ZIP+4 Code match

A User Auxiliary file match

G State-supplied file match

I Intersection match

L Landmark Auxiliary file match

M Multiple match (multi-match)

P Address Point match

S Street address match

U GeoTAX Auxiliary file match

X Aborted processing or expired database

Blank Did not match

NOTE: GeoTAX attempts matches to files in the following order:





• Points file, if licensed

• Streets file


Lat/Long Level Indicates the level that GeoTAX determined the latitude and longitude.

2 ZIP+2 Code centroid


B Block Group centroid

I Intersection

L Landmark Auxiliary file

U GeoTAX Auxiliary file

R Address level based on street address

T Census Tract

Z ZIP Code centroid

blank Could not determine a latitude and longitude

If the returned Match Level is “P”, then the Lat/Long level can have one of the following values:

0 Latitude/longitude coordinates from User Dictionary.

2 Latitude/longitude coordinates from Parcel Centroid.

4 Latitude/longitude coordinates from Address Point.

5 Latitude/longitude coordinates from Structure Centroid.

7 Latitude/longitude coordinates from Manually-placed Point.

8 Latitude/longitude coordinates from Front Door Point.

9 Latitude/longitude coordinates from Driveway Offset Point.

A Latitude/longitude coordinates from Street Access Point.

B Latitude/longitude coordinates from Base Parcel Point.

C Latitude/longitude coordinates from Backfill Address Point.

D Latitude/longitude coordinates from Virtual Address Point.

E Latitude/longitude coordinates from Interpolated Address Point.

AMC Address Match Code

See “Match Codes” on page 263 for return values.

ALC Address Location Code

See “Location codes” on page 265 for return values.

Longitude Distance of the address west of Greenwich, England, measured in degrees. For example, 076.837170 W.

Latitude Distance of the address north of the equator, measured in degrees. For example, 039.948634 N.

FIPS 5-digit code assigned by the Census Bureau to both incorporated and unincorporated places. For example, 52975.

State Code 2-digit FIPS state code and state name. For example, 24 MD.

MCD/CCD Minor Civil Division (MCD) or Census County Division (CCD) Code and Name. For example, 91164 DISTRICT 13 KENT.

County Code 3-digit FIPS county code and name. For example, 033 PRINCE GEORGES.

GNIS Code Unique 9-digit Geographic Names Information System (GNIS) code. For example, 000597758.

Incorptd Indicates if a place is incorporated (legally existent under the law).

No Unincorporated

Yes Incorporated

blank Not found or does not exist on the FIPS 55 Place Code roster

Date Annexed Month and year of the most recent boundary change or the most recent available boundary information for the place. For example, 01/1990.

Date Updated Date the data was last updated, in the format MM/YYYY format.



Date Verified Date the data was last verified, in the format MM/YYYY.

Place Name Unique name assigned to the incorporated or unincorporated place. For example, Mitchellville.

Software Version of the software that created the GTMASTR, GTTAXW, or GTMSTR2 file.

File Vintage of the GTMASTR, GTMSTR2, or the GTTAXW file.

GeoTAX Key 2-digit Vertex state code, 3-digit FIPS county code, and 4-digit Vertex city code.

–or–

Taxware SUT (2-digit SUT state code, ZIP Code, 2-digit SUT geocode) or TWE unique geocode.

RC GeoTAX return code denoting the level of match obtained against the GeoTAX cross-reference files.

A Alternate match, using 3 fields

E Exact match, using all 5 fields

N Default-coded based on valid state code

P Partial match, using 4 fields

Blank No matching GeoTAX record found

The following fields are available if you have licensed the Insurance Premium District (IPD) option. Up to 4 districts display that contain the address, with any additional districts viewable by scrolling down (for a total of 10).

ID 10-byte IPD code. The following states have codes specific to the state: FL, IL, KY, LA, NC, ND, NJ, NY, and SC. The following states use a GeoTAX unique ID: AL, DE, and GA.

IPD Name 40-byte IPD name that indicates the area.

Type 6-byte IPD type. Possible values based on state:

AL PREM

DE FIRE

FL FIRE, POLICE

GA PREM

IL FIRE

KY COUNTY, MUNI

LA PREM

NC FIRE

ND FIRE

NJ FIRE

NY FIRE

SC PREM

Ver Date Date the data was last verified, in the format MM/YYYY.

UPD Date Date the data was last updated, in the format MM/YYYY format.

The following fields are available if you have licensed the Special Purpose Tax District (SPD) option. If a match to an address located in an SPD occurs, up to 4 districts display that contain the address, with any additional districts viewable by scrolling down (for a total of 10).

Code/Nbr 3-byte SPD code and 5-byte SPD number.

SPD Name 40-byte SPD name that indicates the area.

Cmp Dt Compiled date.

Eff Dt Date this SPD goes into effect (in YYYYMMDD format).

Ver Dt Date the data was last verified, in the format MM/YYYY.



Upd Dt Date the data was last updated, in the format MM/YYYY format.

The following fields are available if you have licensed the Payroll Tax District (PAY) option. Up to 4 districts display that contain the address, with any additional districts viewable by scrolling down (for a total of 10).

ID 5-byte unique PAY ID.

Type Type of PAY:

JED Joint Economic Development District

MTA Metro Transportation Authority

UNI Unified School District

Name 60-byte PAY name that indicates the area.

Flags There are four different EMS flags:

• Municipal Income tax flag

• Municipal EMS tax flag

• School District Income tax flag

• School District EMS tax flag

For Pennsylvania, the following are possible values for the income tax flags:

R Residence location tax

W Business location tax

B Resident and business location tax

X Neither resident nor business location tax

For Pennsylvania, the following are possible values for the EMS flags:

Y PAY has an EMS tax

N PAY does not have an EMS tax

For Ohio, the following values apply to all flags:

R District levies the tax

X Not taxed

Flags are blank for all other states.

District ID 5-byte school district ID from source data.

Updated date Date the data was last updated, in the format MM/YYYY.

The following fields are available if you have licensed the Property Tax District (PTD) option. Up to 4 districts display that contain the address, with any additional districts viewable by scrolling down (for a total of 10).

ID 5-byte PTD ID.

Type 1-byte type of PTD:

R Reporting district

B Billing district

Name 60-byte PTD Name that indicates the area.

Juris ID 10-byte Tax Compliance Inc. (TCI) Jurisdiction ID or PTMS code.

Updated date Date the data was last updated, in the format MM/YYYY.


8 – Working With the Callable Functions

In this chapter

Overview 108Invoking the Callable Functions Using COBOL 113


OverviewYou can call the following programs from your own application for batch processing:

GeoTAX Matcher (GTMATCH)

GTMATCH does the matching in GeoTAX. It takes the house number, street name, pre- and post-directionals, city, state, and ZIP Code and matches them against street segment data in the database. Based on the settings you provide, it calculates the address’s location on the correct side of the street, offset by 0, 20, 40, or 60 feet (the default value is 40 feet). GTMATCH returns geographic information associated with that address, including:

• State, county, census tract, and block group codes

• State abbreviation and county name

• MCD code and name

• CBSA code and name

• Place code and place attributes

• SPD, IPD, PAY, and PTD codes, if available

• Latitude/longitude coordinates

Program Description

GTMATCH Matching program - Matches the input addresses to geographic information. Matching is based on actual physical location of the house address on the correct side of the street

GTX10 Vertex Cross-Reference function - Performs a match to Vertex by returning a 9-byte key that matches the input address to Vertex data.

GTX15 Pitney Bowes Vertex Cross-Reference function - Performs a match to Pitney Bowes Vertex by returning a nine-byte key that matches the input address to Pitney Bowes Vertex data

GTX20 Taxware Cross-Reference function - Performs a match to Taxware by returning a nine-byte key that matches theinput address to Taxware data

GCP20 Distance calculator - Calculates the distance between 2 input latitude/longitude coordinates.

GTDBINFO Database info program - Reads GeoTAX Address Matching and SPD files and returns information on the database versions and expirations.

GTX50 Exit routine - Accepts the same input as GTX10, and posts both the 9-byte Vertex key and a 1-byte return code.


GTMATCH calls the cross-reference function GTX10 to obtain the GeoTAX key to Vertex or GTX20 for Taxware. The following figure illustrates how this function works with your driver program.

Coded OutputRecords

Driver Program

Input Addresses

GTMATCHCallable Matching

Function

GeoTAX Database

GeoTAX


Vertex Cross-Reference Function (GTX10)

Program GTX10 performs a match to Vertex by returning a nine-byte key that matches the input address to Vertex data. The nine-byte key consists of:

• 2-byte cross-reference state

• 3-byte FIPS county

• 4-byte cross-reference city codes.

In addition, there is a 1-byte return code.

To work with the cross-reference files, you must be a licensed user of Vertex products. You must also request the latest MATCHMST file from Vertex, which is used to create the GTMASTR cross-reference file.

GTX10 is called from the program GTMATCH, simplifying all subsequent calls from other programs or applications.

Coded OutputRecords

GTMATCHCalls GTX10

Input Address and/or ZIP Codes and

ZIP+4 Codes GTX10Cross ReferenceCallable Function

CrossReference

File

GeoTAX


Pitney Bowes Vertex Cross-Reference Function (GTX15)

Program GTX15 performs a match to Pitney Bowes Vertex data by returning a nine-byte key that matches the input address to Pitney Bowes Vertex data. The nine-byte key consists of:


• 5-byte ZIP Code

• 2-byte Pitney Bowes Vertex geocode.

To work with the cross-reference files, you must be a licensed user of Pitney Bowes Vertex products. You must also obtain the cross reference file from Pitney Bowes.

GTX15 is called only from the program GTMATCH, simplifying all subsequent calls from other programs or applications.

Coded OutputRecords

GTMATCHCalls GTX15


ZIP+4 Codes GTX15 New VertexCross ReferenceCallable Function

CrossReference

File

GeoTAX


Taxware Cross-Reference Function (GTX20)

Program GTX20 performs a match to Taxware by returning a 9-byte key that matches the input address to Taxware data. The 9-byte SUT key consists of:


• 5-byte ZIP Code

• 2-byte Taxware geocode.

If the TWE version of the Taxware cross-reference file is loaded the variable length TWE code will be returned.

To work with the cross-reference file, you must be a licensed user of Taxware products.

GTX20 is called only from the program GTMATCH, simplifying all subsequent calls from other programs or applications.

Coded OutputRecords

GTMATCHCalls GTX20


ZIP+4 Codes GTX20 TaxwareCross ReferenceCallable Function

CrossReference

File

GeoTAX


Distance Calculation Function (GCP20)

The Distance Calculation module GCP20 performs a mathematical function — no database file reads are required for distance calculation. Also for batch processing, GCP20, takes existing latitude/longitude coordinates (which act as points on an imaginary grid covering the Earth's surface) and calculates the distance between them. Output is the distance, to a thousandth of a mile, between the two points, taking into consideration the curvature of the Earth's surface. The following figure illustrates how GCP20 interacts with your driver program.

Invoking the Callable Functions Using COBOL In order to invoke the callable functions, you must issue a CALL command, passing all required input, output, and audit (if applicable) parameters to the function you are calling. The functions are:

• Calling the GTMATCH program

• Calling the GCP20 program

• Calling the GTDBINFO program

OutputDistance

Calculation

Driver Program

Input Lat/LongCoordinates

GCP20Distance Calculation

Callable Function

GeoTAX


Calling the GTMATCH program

The GTMATCH program compares your input addresses (house number, street name, etc.) to the street database and returns information on that address, such as place codes, MCD/CCD codes, and latitude/longitudes.

On Windows and UNIX/Linux:

Use the following to call GTMATCH:

CALL GTMATCH USINGMATCHER-PARAMETERS

On z/OS:

Use the following format to call GTMATCH:

01 DUMMY-PARM1 PIC X(1).01 DUMMY-PARM2 PIC X(1)...CALL GTMATCH USINGDUMMY-PARM1DUMMY-PARM2MATCHER-PARAMETERS

When you call the GTMATCH program, you pass it pre-defined parameter areas - blocks of memory with data that is used by both your executable program and GTMATCH. These parameter areas must reside in the linkage section of your executable program. The following table describes the GTMATCH parameter areas.

Data Area Data Area Name Description

Control Matcher Control Area (MCA) 600-byte area consisting of data-items (MCA-xxx) that contain matcher control/processing settings.

Input Matcher Input Address (MIA) 1500-byte area consisting of data-items (MIA-xxx) that contain input information.

Output Matcher Output Area (MOA) 6092-byte output area consisting of data-items (MOA-xxx) that contain processing results and return codes.

Audit Matcher Audit Area (GTAADT)

1,520,001-character audit area consisting of data-items (GTAxxx) that contain counters for processing statistics.


Matcher Control Area

The following table describes the data-items in the Matcher Control Area (MCA), which totals 600 bytes.

Position Name Length Contents

1 MCA-FUNCTION-REQ 1 Matcher control function:

B Called from batch process

C Return state/county audit stats

E Close files; end program

O Called from on-line process.

NOTE: Any other value is treated as B.

2 MCA-FIRST-LETTER-EXP-OPT

1 First letter expanded option:

Y Enable extra processing for bad first letter (missing, wrong, etc.)

N No extra processing (default)

NOTE: Any other value is treated as N.

3 MCA-STREET-CENTROID-OPT

1 Street centroid option:

Y Enable matching to a street segment. Returns street segment centroid information.

N Normal matching to range only, rather than segment. (default)


4 MCA-ADDRESS-RANGE-OPT

1 Address range matching option:

Y Enable matching of house range input.

N No range input matching. (default)


5 Reserved 1

6 MCA-ALTERNATE-LOOKUP-OPT

1 Alternate lookup option:

1 Street match preferred over firm match.

2 Firm match preferred over street match.

3 Match to address line only. (default)

NOTE: Any other value is treated as 3.

7 MCA-ADDR-MATCH-MODE

1 Match mode option:

0 Enable ‘Exact’ address match mode.

1 Enable ‘Close’ address match mode. (default)

2 Enable ‘Relaxed’ address match mode.


8 MCA-FALL-BACK-GEOGRAPHIC-OPT

1 Fallback geographic option:

Y Find the first city, county, and/or state centroid, then match from the set of possible matches found.

N No geographic centroid search. (default)



9 MCA-SEARCH-AREA-OPT

1 Search area option:

1 Search entire finance area for a match. (default)

2 Search a given radius but stays in state (this option requires an input radius - see MCA-SEARCH-RADIUS below).


10-18 MCA-SEARCH-RADIUS

9 Expanded search radius (in miles) to apply as the expanded search area when option 2 is selected in MCA-SEARCH-AREA-OPT above.

1-99 Miles - right justified, padded with zeroes to left.

25 miles (default)

NOTE: A space or any non-numeric value is treated as a zero.

19 MCA-CACHESIZE 1 Relative cache size used in address matching. Controls the amount of memory that is allocated to store temporary street data during address processing. A smaller cache may slow the performance.

0 Smallest memory usage.

1 Middle memory usage.

2 Largest memory usage. (default)


20 MCA-ADDRESS-POINT-INTERP-OPT

1 Address point interpolation option (only for use with point level geocoding):

Y Enable address point interpolation.

N No address point interpolation. (default)


21 MCA-BOUNDARY-CONF

1 Boundary confidence option. Indicates if confidence codes for boundary matches should be returned:

Y Return boundary confidence levels.

N Do not return boundary confidence levels. (default)


22 MCA-USER-BOUNDARY-CONF

1 User boundary confidence option. Indicates if confidence codes for user boundary matches should be returned:

Y Enable return of user boundary confidence levels.

N Do not return user boundary confidence levels. (default)


23 MCA-PLACE-CONF 1 Place confidence option. Indicates if confidence codes for place matches should be returned:

Y Enable return of place confidence levels.

N Do not return place confidence levels. (default)


24 MCA-COUSUB-CONF 1 County subdivision confidence option. Indicates if confidence codes for county subdivision matches should be returned:

Y Enable return of county subdivision confidence levels.

N Do not return county subdivision confidence levels. (default)




25 MCA-COUNTY-CONF 1 County confidence option. Indicates if confidence codes for county matches should be returned:

Y Enable return of county confidence levels.

N Do not return county confidence levels. (default)


26 MCA-LAT-LONG-INPUT

1 Latitude/Longitude input option. Indicates if latitude/longitude coordinates will be input rather than address or ZIP code.

Y Latitude/longitude coordinates to be used as input.

N Address and lastline info to be used as input. (default)


27 MCA-GET-MULTIPLE 1 For a multi-match outcome, indicates which match result should be returned; valid values are 1-9 and value should not be greater than MOA-NUM-MULTIPLE.

NOTE: Any non-numeric value will be ignored.

28 MCA-BOUNDARY-CACHESIZE

1 The relative size of cache used in boundary file matching:

0 No caching

1 Medium-sized cache (default)

2 Large-sized cache

3 Very large-sized cache


29 MCA-ACCEPT-MULTIPLE

1 Indicates whether address information should be returned in a multi-match outcome:

Y Accept multiples and return 1st match information in multi-match list

N Do not accept multiples and return information. (default)


30-493 Reserved 464

494 MCA-DB-OVERRIDE-SW

1 Overrides the database expiration:

X Override an expired database

N Do not override an expired database (default)

495-503 MCA-BOUNDARY-BUFFER-DIST

9 Buffer radius, in feet, to apply to the districts in the boundary file. Numeric value (right justified) padded with zeros to left. A space or any non-numeric value is treated as zero.

504-512 MCA-USER-BND-BUFFER-DIST

9 Buffer radius, in feet, to apply to the districts in the user-defined boundary file. Numeric value (right justified) padded with zeros to left. A space or any non-numeric value is treated as zero.

513 MCA-USER-BOUNDARY-MATCH-OPT

1 Indicates if GeoTAX should attempt a match to the user-defined boundary file:

Y Attempt a match

N Do not attempt a match (default)


514 MCA-PTC-MATCH-OPT

1 Indicates if GeoTAX should attempt a match to a payroll tax correspondence file:

Y Attempt a match

N Do not attempt a match (default)




515 MCA-AX2-MATCH-OPT

1 Indicates if GeoTAX should attempt a match to the GeoTAX Auxiliary file:

Y Attempt to match to the GeoTAX Auxiliary file (default)

N Do not use the GeoTAX Auxiliary file

NOTE: Any other value is treated as Y.

516 MCA-AUX-MATCH-OPT

1 Indicates if GeoTAX should attempt a match to the User Auxiliary file:

Y Attempt to match to User Auxiliary file (default)

N Do not use the User Auxiliary file


517 MCA-STATE-MATCH-OPT

1 Indicates if GeoTAX should attempt a match to the state files:

Y Attempt to match to state files

N Do not use state files (default)


518 MCA-STATE-ORDER-OPT

1 Indicates which state file GeoTAX should use to attempt a match and, in the case of both, what the order of searching should be:

A Use only the Florida-native formatted file (default)

B Use only the TS-158 formatted file

C Use both formats and search Florida-native first

D Use both formats and search TS-158 first

NOTE: Any other value is treated as A. Valid checking is done only when state matching is on.

519 MCA-BOUNDARY-MATCH-OPT

1 Indicates if GeoTAX should attempt a match to a boundary file, and to which file it should attempt the match:

S Attempt a match to the Special Purpose Tax District file

I Attempt a match to the Insurance Premium District file

P Attempt a match to the Property Tax District file

R Attempt a match to the Payroll Tax District file

N No, do not call (default).


520-527 MCA-IO-MODULE-NAME

8 Generic I/O routine name to call. If blank, GeoTAX utilizes I/O routines provided with the product. Program names may differ according to platform.

528 MCA-FL-RELAX-SEC-OPT

1 Indicates if GeoTAX enables matching to the Florida state file without requiring a match on secondary:

Y Relax secondary matching

N Do not relax secondary matching (default)


529 MCA-LL-SQUEEZE-OPT

1 Indicates if GeoTAX enables a Lat/Lon squeeze:

Y Apply squeeze to Lat/Lon (default)

N Do not apply squeeze


530-534 Reserved 5



535 MCA-TAXRATE-MATCH-OPT

1 Tax Rate matching indicator field. Indicates whether to enable tax rate matching and the type of tax rate to return:

G Enable tax rate matching and return general rates.

A Enable tax rate matching and return automotive rates.

M Enable tax rate matching and return medical rates.

C Enable tax rate matching and return construction rates.

N Disable tax rate matching (default)

NOTE: Any other value returns zeros in the tax rate output fields.

536 MCA-STREET-MATCH-OPT

1 Street match indicator field:

Y Use the street matcher (default)

N Do not use the street matcher


537 MCA-CASE 1 Indicates if name fields are in mixed case:

Y Yes

N No (default)


538-542 Reserved 5

543 MCA-GTX 1 Indicate if GeoTAX should determine the GeoTAX key:

T Attempt to determine information associated with GeoTAX Taxware application.

V Return the key using the Pitney Bowes Software Vertex file.

Y Attempt to determine information associated with GeoTAX Vertex application.

N Do not attempt to determine information associated with GeoTAX application.


544 MCA-LATLONG-ALT-FMT

1 Indicates latitude/longitude alternate format. Value supplied will be used to calculate the offset for the street segment.

A 090000000N180000000W (default)

B 090.000000N180.000000W

C 90.000000-180.000000

D 90000000-180000000

NOTE: Any other value is treated as A.

545 MCA-LATLONG-OFFSET

1 Latitude/longitude offset field for the street segment. Value supplied will be used to calculate the offset for the street segment.

A No offsetting

B 20 feet offset from street segment

C 40 feet offset from street segment (default)

D 60 feet offset from street segment.

NOTE: Any other value is treated as C.

546-600 Reserved 55



Matcher Input Area (MIA)

The following table describes the data-items in the Matcher Input Area (MIA), which totals 1500 bytes.


1-9 MIA-ZIP9 9 Input ZIP+4 Code to match against the database.

10-22 Reserved 13

23-72 MIA-CITY 50 Input city name.

73-122 MIA-STATE 50 Input state name.

123-422 MIA-STREETS

300 Input address lines 1, 2, and 3, each 100 bytes long.

423-722 MIA-ADR-BLK

300 Input address block, consisting of:

firm name & address lines, each 100 bytes long.

If country, ZIP/postal code, city, or state input fields are blank or invalid, this area is searched for those values.

723-1322 Reserved 600

1323-1344

MIA-LAT-LONG

22 Input latitude (11 bytes) and longitude (11 bytes).


Latitude:00.000000 or without the decimal point 00000000

Longitude:000.000000 or without the decimal point 000000000; or

00.000000 or without the decimal point 00000000

1345-1416

MIA-LIC-FILE-PATH

72 License file path and name.

1417-1424

MIA-LIC-PASSWORD

8 License file password.

1425-1500

Reserved 76


Matcher Output Area (MOA)

The following table describes the data-items in the Matcher Output Area (MOA), which totals 6092 bytes.


1-2 MOA-ABEND-RC 2 Return code from matcher abnormal termination.

The first character indicates the file (or set of files affected.

Blank Matcher terminated normally

A User Auxiliary file problem

CE cousub.txb file problem

CI Confidence engine problem

D Boundary file problem

F User Boundary file problem

G Address Matching engine problem

L Licensing problem

S State file problem

U GeoTAX Auxiliary file problem

X Combination of street and state file problem

Z zip.gsb file problem

The second position is:

E Fatal issue, program terminating

F Expired database

I Informational

3-82 MOA-ABEND-TXT 80 Text description of matcher abnormal termination; blank if matcher terminated normally.

83-84 MOA-WARN-RC 2 Warning return code; blank if no warnings issued. A return of WN indicates a database will expire next month.

85-164 MOA-WARN-TXT 80 Text description of warning.

165-194 MOA-DESCRIPTION 30 Matching software description.

195-202 MOA-RELEASE-MOD-NUM

8 Matching software release number and modification level.

203-222 MOA-TAXRATE-VINTAGE 20 Pitney Bowes Software Sales and Use Tax Rate file vintage.

223-262 MOA-TAXRATE-VERSION 40 Pitney Bowes Software Sales and Use Tax Rate file version.

263-382 Reserved 120

383-402 MOA-GEOTAX-VINTAGE 20 Cross-Reference file vintage.

403-406 MOA-GEOTAX-VERSION 4 Cross-Reference file software version.

407 MOA-ST-IND 1 Indicates if the match results are from the Florida State files:

F Match to Florida State files.

408-415 MOA-ST-VINTAGE 8 Date the state-supplied file was created, in the format MM/DD/YY.

416-423 MOA-ST-VERSION 8 Version of the GeoTAX master file that created the State-supplied files, in the format Rnn.nMnn.

424-432 Reserved 9


433 MOA-GRC 1 General return codes:

5 ZIP Code match

9 ZIP+4 Code match


C Street Centroid match

F Fallback Geographic match





O Input Latitude/Longitude coordinates match

P Address point match




blank Did not match

NOTE: GeoTAX attempts matches to files in the following order: Landmark Auxiliary File, User Auxiliary File, state-supplied file, GeoTAX Auxiliary file, Points file, then Streets file.

434 MOA-STREET-O-RC 1 For street address matching, the output street address return code:

Z ZIP Code not found in street address database

S Street not found in ZIP Code

H House number not found on street

L Lat/long not determined on the GeoTAX Auxiliary file, the User Auxiliary file, or the state-supplied file

blank Successful match

435-442 Reserved 8

443-444 MOA-STATE-CODE 2 FIPS State code.

445-447 MOA-COUNTY-CODE 3 FIPS County code.

448-453 MOA-CENSUS-TRACT 6 Census tract code.

454 MOA-BLOCK-GROUP 1 Census block group.

455-456 MOA-STATE-ABBREVIATION

2 State abbreviation.

457-481 MOA-COUNTY-NAME 25 County name.

482-535 Reserved 54

536-540 MOA-MCDCCD-CODE 5 Minor Civil Division/Census County Division (MCD/CCD) Code.

541-580 MOA-MCDCCD-NAME 40 MCD/CCD name.

581-585 MOA-PLACE-CODE 5 Place code.

586-625 MOA-PLACE-NAME 40 Place name.

626-627 MOA-PLACE-CLASS-CODE

2 Place class code.



628 MOA-PLACE-INCORP-FLAG

1 Place incorporated/unincorporated flag:

1 Place code returned is incorporated

0 Place code returned is unincorporated

blank Place code is not found or does not exist on the FIPS 55 Place Code roster.

629-635 MOA-PLACE-LAST-ANNEXED

7 Last Annexed Date (in MM/YYYY format). This date represents the month and year of the most recent boundary change or the most recent available boundary information. This field is never blank

636-642 MOA-PLACE-LAST-UPDATED

7 Last Updated Date (in MM/YYYY format). This date reflects the month and year when TeleAtlas updated the database to reflect attribute (name change, FIPS change, incorporated/unincorporated change, etc.) or boundary edits to the Place.

643-649 MOA-PLACE-LAST-VERIFIED

7 Last Verified Date (in MM/YYYY format). The Last Verified date is the month and year that TeleAtlas verified municipality change information.

650-658 MOA-PLACE-GNIS 9 Unique Geographic Names Information System (GNIS) code.

659 MOA-GEOTAX-RC 1 GeoTAX return code denoting the level of match obtained against the Vertex or Taxware cross-reference files:




N Record is default-coded based on valid state code

Blank No matching GeoTAX record found.

660-668 MOA-GEOTAX-KEY 9 9-byte key, consisting of:

• 2-byte VERTEX state code, OR 2-byte Taxware state

• 3-byte FIPS county code, OR 5-byte ZIP Code

• 4-byte VERTEX place code, OR 2-byte Taxware geocode

669 Reserved 1

670-672 MOA-BLOCK-ID 3 Census Block ID

673-689 Reserved 17



690 MOA-LATLONG-LEVEL 1 The latitude/longitude coordinates may be returned from one of a number of possible sources, some of which are optional. The output latitude/longitude level return code is a single character denoting the level for which the geocode was determined, as follows:



B Block group centroid

C City centroid


O Latitude/longitude was matched as input

R Street latitude/longitude based on street address

S State centroid

T Census tract centroid


Z ZIP Code centroid

blank Could not determine latitude/longitude.

If the General Return Code (MOA-GRC) is "P" (point match), then the following are possible values and have the following meaning:













691-698 MOA-LATITUDE 8 Latitude — 7-digit number followed by a 1-character directional. The 7-digit number is in degrees and calculated to 4 decimal places (decimal is implied, not shown). The 1-character directional is one of the following:

N North

S South.

699-706 MOA-LONGITUDE 8 Longitude — A 7-digit number followed by a 1-character directional. The 7-digit number is in degrees and calculated to 4 decimal places (decimal is implied, not shown). The 1-character directional is one of the following:

E East

W West.

707-736 MOA-LAT-LONG-ALT-1 30 Indicates the latitude/longitude alternate formats:

A 090000000N180000000W (default)

B 090.000000N180.000000W

C 90.000000-180.000000

D 90000000-180000000



737-756 MOA-LAT-LONG-ALT2 20 Used to output latitude and longitude in a format used by the ARCOUT parameter.

• Bytes 737-743—Latitude in 90.000000 format

• Bytes 744-754—Longitude in -180.000000 format

757-766 Reserved 10

767-1066 MOA-AUX-AREA 300 Reserved for data retrieved as a result of a GeoTAX Auxiliary or User Auxiliary match containing positions xx-xxx from the corresponding G1GTAX2 or G1GTAUX record area.

1067-1266 MOA-STATE-SUPPLIED-AREA

200 Reserved for data retrieved as a result of a state-supplied file match. Each format supported contains its own mask of what data resides in this location. Currently, these formats are the Florida-native format and the TS-158 format. For more information, see “STEOUT” on page 252.

1267-1276 Reserved 10

1277 MOA-TS-IND 1 Indicates if the match results are from the TS-158 State files:

N Match to TS-158 State files.

1278-1285 MOA-TS-VINTAGE 8 Vintage of the state-supplied file.

1286-1293 MOA-TS-VERSION 8 Software version of the state-supplied file.

1294-1295 MOA-BOUNDARY-NUM-OF-SPD

2 Number of Special Purpose Tax Districts (SPDs) returned from boundary match call.

NOTE: The following data (for positions 1296-2675 occurs in 10 blocks of 138 bytes each, the contents of which vary depending on the boundary file used.

1296-2675 MOA-TAX-DIST-CODE 3 Tax District Code.

MOA-TAX-DIST-NUM 5 Tax District Number.

MOA-TAX-DIST-TYPE 6 Tax District Type.

NOTE: See Type Codes for more information regarding state and type codes.

MOA-TAX-DIST-ID 10 Tax District ID.

MOA-TAX-DIST-ST-SPD-CODE

State Supplied Special District Code.

NOTE: MOA-TAX-DIST-ST-SPD-CODE is for SPD file return only.

MOA-TAX-DIST-IDSUPP 10 Supplemental Tax District ID (Jurisdiction ID).

MOA-TAX-DIST-NAME 60 Tax District name.

MOA-TAX-DIST-FLAG 10 Tax District flag.

MOA-TAX-DIST-VER-DATE

6 Tax District version date.

MOA-TAX-DIST-EFF-DATE

6 Tax District effective date.

MOA-TAX-DIST-CMP-DATE

6 Tax District compiled date.

MOA-TAX-DIST-UPD-DATE

6 Tax District update date.



MOA-TAX-DIST-BUFFER-RC

1 Status of the buffered point:

P Point in the polygon

I Point in the buffer inside the polygon

B Point in the buffer, outside of the polygon

blank Polygon not found.

MOA-TAX-DIST-DISTANCE

9 Distance, in feet, from the tax district border.

2676-2677 MOA-BOUNDARY-NUM-OF-USR

2 Number of user-defined boundaries; up to 10.

NOTE: The following data (for positions 2678-3477) occurs in10 blocks of 80 bytes each; 1 block for each district in the user-defined boundary file.

MOA-USR-DIST-ID 10 User-defined input field.

MOA-USR-DIST-SUPP 10 User-defined input field.

MOA-USR-DIST-DESC 50 Description of the district.

MOA-USR-DIST-BUFFER-RC

1 Status of the buffered point as the first byte:




Distance to the border for the remaining 9 bytes.

MOA-USR-DIST-DISTANCE

9 Distance, in feet, from the tax district border.

3478 MOA-PTC-GRC 1 Type of match found:

P District ID

G GNIS Code

F County FIPS Code

S State FIPS Code

3479 MOA-PTC-CODE-CNT 1 Number of PTC codes found.

3480-3511 MOA-PTC-STCO-NAME 32 State abbreviation and county name.

NOTE: The following data (for positions 3512-3841) occurs in 6 blocks of 55 bytes each.

MOA-PTC-CODE 15 Payroll code.

MOAT-PTC-DESC 40 Payroll description.

3842-3847 MOA-PTC-FLAGS 6 Indicates if the payroll file is used for a match:

Y Used

N Not used (default)

3848-3867 MOA-PTC-VINTAGE 20 Software vintage of the payroll file.

3868-3875 MOA-PTC-VERSION 8 Software version of the payroll file.

3876-3895 MOA-BOUNDARY-VINTAGE

20 Software vintage of the SPD file. Only used with files newer than November 2007.

NOTE: The following data (for positions 3896-4755) occurs in 10 blocks of 86 bytes each; 1 block for each district in the Insurance Premium boundary file.

3896-4755 MOA-TAX-DIST-IPD-EXT-NOTES

20 Kentucky Tax Code descriptions

MOA-TAX-DIST-IPD-EXT-CHGDT

6 MMDDYY - Date of any type of change the row made by the editing team

MOA-TAX-DIST-IPD-EXT-EFFDT

6 MMDDYY- Identifies when district becomes active - State supplied



MOA-TAX-DIST-IPD-EXT-EXPDT

6 MMDDYY - Identifies when district becomes inactive - State supplied

NOTE: The following data occurs in 8 blocks of 6 bytes each; 1 block for each type of insurance.

MOA-TAX-DIST-IPD-EXT-RTE

5 Format is dependent on associated flag

MOA-TAX-DIST-IPD-EXT-RTEFMT

1 P Percentage: .1 = 10%, .0575 = 5.75%

F Flat Fee dollar amount: 15.00

M Multiple Percentages has a semi colon as a delimiter: 3;7 = "3% or 7%"

4756-4908 Reserved 153

Spatial returns for place and cousub (20 bytes)

4909 MOA-PLACE-BUFFER-RC 1 Status of the buffered point:





4910-4918 MOA-PLACE-DISTANCE 9 Distance, in feet, from the place district border.

4919 MOA-COUSUB-BUFFER-RC

1 Status of the buffered point:





4920-4928 MOA-COUSUB-DISTANCE 9 Distance, in feet, from the county subdivision district border.

Confidence code returns (71 bytes)

4929-4930 MOA-SURFACE-TYPE 2 Confidence Surface types:

0 Undefined

1 The search failed - address was not found

2 Intersection confidence-surface generated

3 Interpolated street segment

4 Point level match

5 State confidence-surface generated

6 County confidence-surface generated

7 City confidence-surface generated

8 Reserved

9 A ZIP Code confidence-surface generated

10 A ZIP+2 confidence-surface generated


12 Reserved

13 A street centroid confidence-surface generated

4931-4933 MOA-CONF-PLACE 3 The returned confidence code for a place.

4934-4936 MOA-CONF-COUSUB 3 The returned confidence code for a county subdivision.

4937-4939 MOA-CONF-COUNTY 3 The returned confidence code for a county.

4940-4969 MOA-CONF-BND 3 The returned confidence code for a comparison to a boundary file.

Data occurs in 10 blocks of 3 bytes each.



4970-4999 MOA-CONF-USER-BND 3 The returned confidence code for a comparison to a user-defined boundary file.


5000 Reserved 1

Address matching return codes & data

5001-5004 MOA-ADDR-MATCH-CODE

4 The returned Match Code indicates the portions of the address that matched or did not match to the reference file. For values, see “Match Codes” on page 263.

5005-5008 MOA-ADDR-LOC-CODE 4 The returned Location Code indicates the methodology used to compute the geocode and may also provide information about the accuracy of the assigned geocode. For values, see “Location codes” on page 265.

5009-5028 MOA-ADDR-DB-VERSION 20 Address Matcher database version.

5029-5068 MOA-ADDR-SW-VERSION 40 Address Matcher software version.

5069-5108 MOA-ADDR-FIRM-NAME 40 Output Firm name

5109-5168 MOA-ADDR-ADDRESS-LINE-1

60 Output Address Line 1.

5169-5228 MOA-ADDR-ADDRESS-LINE-2

60 Output Address Line 2.

5229-5288 MOA-ADDR-LAST-LINE 60 Output Address Last Line.

5289-5318 MOA-ADDR-URB 30 Output urbanization name.

5319-5346 MOA-ADDR-CITY 28 Output city.

5347-5348 MOA-ADDR-STATE-ABBREV

2 Output state abbreviation.

5349-5353 MOA-ADDR-ZIP 5 Output ZIP Code.

5354-5357 MOA-ADDR-ZIP4 4 Output 4 character add-on code for ZIP+4 Code.

5358-5368 MOA-ADDR-HOUSE-NUM 11 Output house number.

5369-5370 MOA-ADDR-PRE-DIR 2 Output pre-directional.

5371-5410 MOA-ADDR-STREET-NAME

40 Output street name.

5411-5414 MOA-ADDR-STREET-TYPE

4 Output street type.

5415-5416 MOA-ADDR-POST-DIR 2 Output post-directional.

5417-5420 MOA-ADDR-UNIT-TYPE 4 Output secondary type (e.g. Apt., Suite)

5421-5431 MOA-ADDR-UNIT-NUM 11 Output secondary number.

5432-5436 MOA-CBSA-CODE 5 CBSA code.

5437-5511 MOA-CBSA-NAME 75 CBSA name.

5512-5516 MOA-CBSAD-CODE 5 CBSA Division code.

5517-5588 MOA-CBSAD-NAME 72 CBSA Division name.

5589-5591 MOA-CSA-CODE 3 CSA code.

5592-5668 MOA-CSA-NAME 77 CSA name.

5669 MOA-METRO-FLAG 1 Metropolitan flag. Indicates if the CBSA is a “Metropolitan Statistical Area” or a “Micropolitan Statistical Area”.

Y Metropolitan statistical area

N Micropolitan statistical area



5670 MOA-NUM-MULTIPLE 1 The number of multiple matches found for a given input address.

5671-5672 MOA-ADDR-DATA-TYPE 2 Data type of address match:

0 USPS

1 TIGER

2 TomTom Street

6 NAVTEQ Street

7 TomTom Point

8 Centrus Point

11 NAVTEQ Point

12 Master Location Data

90 State-supplied file

91 User Auxiliary file

92 Landmark Auxiliary file

93 GeoTAX Auxiliary file

5673-5799 Reserved 127

Pitney Bowes Software Sales & Use Tax Rate data

Rate value format is 0.00000000

5800 MOA-TAXRATE-GRC 1 Tax Rate return code denoting the level of match obtained against the Pitney Bowes Software Sales and Use Tax Rate table:





Blank No matching Pitney Bowes Software Sales and Use Tax Rate record found.

5801-5810 MOA-TAXRATE-SALES-COMBINED

10 The sum of the state, county, municipality and SPD sales tax rates.

5811-5820 MOA-TAXRATE-SALES-STATE

10 State sales tax rate.

5821-5830 MOA-TAXRATE-SALES-COUNTY

10 County sales tax rate.

5831-5840 MOA-TAXRATE-SALES-MUNI

10 Municipality sales tax rate.

5841-5940 MOA-TAXRATE-SALES-SPD

10 SPD 1-10 sales tax rates.


5941-5950 MOA-TAXRATE-USE-COMBINED

10 The sum of the state, county, municipality and SPD use tax rates.

5951-5960 MOA-TAXRATE-USE-STATE

10 State use tax rate.

5961-5970 MOA-TAXRATE-USE-COUNTY

10 County use tax rate.

5972-5980 MOA-TAXRATE-USE-MUNI

10 Municipality use tax rate.

5981-6080 MOA-TAXRATE-USE-SPD 10 SPD 1-10 use tax rates.


6081-6092 Reserved 12



Matcher Audit Area (GTAADT)

The audit area is primarily a series of counters indicating the number of database file matches, by county and state, for each of the logical database files. The first time your COBOL program calls GTMATCH, GTAADT initializes this counting area to zero. For subsequent calls, GTMATCH increments these fields individually. The following table describes the subfields in the Matcher Audit (GTAADT) parameter area, which totals 1,520,001 bytes.


1 GTAA-FUNCTION-REQ

1 Function.

NOTE: The following occurs 4000 times, one for each county in the country (total of 1,320,000 bytes).

GTAA-CNTY-NAME 20 County name.

GTAA-PROC 5 Count of records processed.

GTAA-MAT-A 5 Count of User Auxiliary file matches.

GTAA-MAT-U 5 Count of GeoTAX Auxiliary file matches

GTAA-MAT-ST 5 Count of state-level matches.

GTAA-MAT-L 5 Count of Landmark Auxiliary matches

GTAA-MAT-P 5 Count of Point matches.

GTAA-MAT-I 5 Count of Intersection matches.

GTAA-MAT-S 5 Count of street-level matches.

GTAA-MAT-C 5 Count of Street Centroid matches.

GTAA-MAT-9 5 Count of ZIP+4-level matches.

GTAA-MAT-5 5 Count of ZIP Code-level matches.

GTAA-MAT-F 5 Count of Fallback Geocoding matches.

GTAA-MAT-M 5 Count of Multiple matches.

GTAA-TRK-NO 5 Census Tract no-match counts

GTAA-TRK 5 Census Tract matched counts.

GTAA-BLK-NO 5 Block Group no-match counts

GTAA-BLK 5 Block Group matched counts.

GTAA-SPD 5 Count of locations contained in an SPD/IPD/PTD/PAY.

GTAA-SPD-1 5 Count of locations in one SPD/IPD/PTD/PAY.

GTAA-SPD-2 5 Count of locations in two SPD/IPD/PTD/PAYs

GTAA-SPD-34 5 Count of locations in three or four SPD/IPD/PTD/PAYs.

GTAA-SPD-5 5 Count of locations in more than four SPD/IPD/PTD/PAYs.

GTAA-USR 5 Count of locations contained in a user district.

GTAA-USR-1 5 Count of locations in one user district


GTAA-USR-2 5 Count of locations in two user districts.

GTAA-USR-3P 5 Count of locations in three or more user districts.

GTAA-MCD-NO 5 MCD/CCD Code no-match counts.

GTAA-MCD- 5 MCD/CCD Code matched counts.

GTAA-MCD-NM 5 MCD/CCD name matched counts.

GTAA-PLC-NO 5 Place Code no-match counts.

GTAA-PLC 5 Place Code matched counts.

GTAA-PLC-NM 5 Place name matched counts.

GTAA-PLC-A 5 Place annexed date matched counts.

GTAA-PLC-V 5 Place verified date matched counts.

GTAA-PLC-U 5 Place updated date matched counts.

GTAA-PLC-CC 5 Place class code matched counts.

GTAA-PLC-I 5 Place incorporated status matched counts.

GTAA-PLC-UI 5 Place unincorporated status matched counts.

GTAA-XRF-TRY 5 GeoTAX cross-reference file match attempts.

GTAA-XRF 5 GeoTAX cross-reference file matches.

GTAA-XRF-NO 5 GeoTAX cross-reference file no-matches.

GTAA-XRF-E 5 GeoTAX cross-reference file exact matches using all 5 input parameters (state/county/place/ZIP code/place name).

GTAA-XRF-P 5 GeoTAX cross-reference file Partial matches using the first 4 input fields (state/county/place/ZIP code).

GTAA-XRF-A 5 GeoTAX cross-reference file Alternate matches using postal/place name-based answer (ZIP Code/place name).

GTAA-XRF-N 5 GeoTAX cross-reference file unsuccessful matches, default coded with table-based state code lookup.

GTAA-PTC-TRY 5 PTC file match attempts.

GTAA-PTC 5 PTC file matches.

GTAA-PTC-NO 5 PTC file no-matches.

GTAA-LL-NO 5 Lat/long no-match counts.

GTAA-LL 5 Lat/long matched counts.

GTAA-LL-L 5 Lat/Long Landmark Auxiliary level matched counts.

GTAA-LL-P 5 Lat/Long Point level matched counts.

GTAA-LL-I 5 Lat/Long Intersection level matched counts.

GTAA-LL-R 5 Lat/long address level matched counts.

GTAA-LL-U 5 Lat/long GeoTAX Auxiliary level matched counts.



Calling the GCP20 program

The program GCP20 compares two input latitude/longitude coordinates to GeoTAX and calculates the distance between these points.

Use the following command to invoke the GCP20 distance calculation program:

CALL GCP20 USING DSIIN DSOOUT

Your calling program must pass the following parameters to GCP20.

GTAA-LL-4 5 Lat/long ZIP+4 Code centroid matched counts.

GTAA-LL-B 5 Lat/long Block group centroid matched counts.

GTAA-LL-2 5 Lat/long ZIP+2 Code centroid matched counts.

GTAA-LL-T 5 Lat/long Census tract centroid matched counts.

GTAA-LL-Z 5 Lat/long ZIP Code centroid matched counts.

GTAA-LL-C 5 Lat/Long City Centroid level matched counts.

GTAA-LL-S 5 Lat/Long State Centroid level matched counts.

1,320,002-1,520,001

GTAA-IDX-GRP 200,000 Index Group.

The next row describes the contents of GTAA-IDX-GRP. Occurs 100,000 times.

GTAA-IDX-VAL 2 The value for the different state/county combinations.


Parameter Area

Parameter Area Name Description

Input DSIIN 100-character input area consisting of subfields (DSIxxx) that contain input information and processing requirements.

Output DSOOUT 50-character output area consisting of subfields (DSOxxx) that contain processing results and return codes.


DSIIN Input Parameter Area

The following table describes the subfields in the DSIIN input parameter area.

The DSOOUT Output Parameter Area

The following table describes the subfields in the DSOOUT Output Parameter Area.


1 DSIFNC 1 Field that your program fills in:

E End of job indicator: Nothing is stored in the output area. The calling program must clear active memory.

blank GCP20 performs the distance calculation.

Other values are treated as blanks.

2 1 Reserved for AS/400 platform.

3-10 Reserved 8

11-18 DSILAT1 8 Latitude of the first coordinate. The first 7 positions must contain the latitude, expressed in degrees, with 4 decimal positions understood. The 8th position must contain the directional: N or S (North or South).

Example: The latitude coordinate 39 degrees, 30 minutes, North, is expressed as 0395000N.

19-26 DSILNG1 8 Longitude of the first coordinate. The first 7 positions must contain the longitude, expressed in degrees, with 4 decimal positions understood. The 8th position must contain the directional associated with the longitude: E or W (East or West) of Greenwich, England.

Example: The longitude coordinate, 57 degrees, 15 minutes, West, is expressed as 0572500W.

27-34 DSILAT2 8 Latitude of the second coordinate. The first 7 positions must contain the latitude, expressed in degrees, with 4 decimal positions understood. The 8th position must contain the directional: N or S (North or South).

35-42 DSILNG2 8 Longitude of the second coordinate. The first 7 positions must contain the longitude, expressed in degrees, with 4 decimal positions understood. The 8th position must contain the directional associated with the longitude: E or W (East or West) of Greenwich, England.

43-100 Reserved 58


1-8 DSODST 8 Distance between the 2 input coordinates described in the input parameter. This distance is expressed in miles, accurate to one one-thousandth of a mile (.001). If the distance cannot be calculated, this field contains spaces.

NOTE: If no output distance is calculated, it is likely that an input error occurred. Check your coordinates, and try again.

9-50 Reserved 42


Calling the GTDBINFO program

The database version information program, GTDBINFO, reads the Address Matcher database and the SPD file of GeoTAX and returns the current date and expiration date of each database, and the number of days until each one expires.

Use the following command to call GTDBINFO:

CALL GTDBINFO USING GTDBI-AREA

When calling the GTDBINFO program, it passes to pre-defined parameter areas — blocks of memory with data used by both the executable program and GTDBINFO. These parameter areas must reside in the linkage section of the executable program. The following table describes the GTDBINFO parameter area.


1-30 Area In 30 None - Reserved for future use.

31-45 Reserved

46-47 Street File Month 2 2-digit numeric month of Street file vintage

48-51 Street File Year 4 4-digit numeric year of Street file vintage

52-53 Street File Expiration Month 2 2-digit numeric month of Street file expiration

54-57 Street File Expiration Year 4 4-digit numeric year of Street file expiration

58-60 Street File Days Left 3 3-digit number of days until Street file expires

61-62 SPD File Month 2 2-digit numeric month of SPD file vintage

63-66 SPD File Year 4 4-digit numeric year of SPD file vintage

67-68 SPD File Expiration Month 2 2-digit numeric month of SPD file expiration.

69-72 SPD File Expiration Year 4 4-digit numeric year of SPD file expiration.

73-75 SPD File Days Left 3 3-digit number of days until SPD file expires.

76-100 Reserved 25


Calling the MFDIST Program

The MFDIST program compares your two input latitude/longitude coordinates to GeoTAX and calculates the distance between these two points.

Note: MFDIST is valid only on z/OS.

Your calling program must pass the following parameters to MFDIST.

The DSIIN Input Parameter Area

The following table describes the subfields in the DSIIN input parameter area.

Parameter Area

Parameter Area Name Description

Input DSIIN 100-character input area consisting of subfields (DSIxxx) that contain input information and processing requirements.

Output DSOOUT 50-character output area consisting of subfields (DSOxxx) that contain processing results and return codes.


1 DSIFNC 1 Field that your program fills in:

E End of job indicator: Nothing is stored in the output area. The calling program must clear active memory.

blank GCP20 performs the distance calculation.

Other values are treated as blanks.

2 1 Reserved for AS/400 platform.

3-10 Reserved 8

11-18 DSILAT1 8 Latitude of the first coordinate. The first 7 positions must contain the latitude, expressed in degrees, with 4 decimal positions understood. The 8th position must contain the directional: N or S (North or South).

Example: The latitude coordinate 39 degrees, 30 minutes, North, is expressed as 0395000N.

19-26 DSILNG1 8 Longitude of the first coordinate. The first 7 positions must contain the longitude, expressed in degrees, with 4 decimal positions understood. The 8th position must contain the directional associated with the longitude: E or W (East or West) of Greenwich, England.

Example: The longitude coordinate, 57 degrees, 15 minutes, West, is expressed as 0572500W.

27-34 DSILAT2 8 Latitude of the second coordinate. The first 7 positions must contain the latitude, expressed in degrees, with 4 decimal positions understood. The 8th position must contain the directional: N or S (North or South).

35-42 DSILNG2 8 Longitude of the second coordinate. The first 7 positions must contain the longitude, expressed in degrees, with 4 decimal positions understood. The 8th position must contain the directional associated with the longitude: E or W (East or West) of Greenwich, England.

43-100 Reserved 58


The DSOOUT Output Parameter Area

The following table describes the subfields in the DSOOUT Output Parameter Area.

The DSRSV Reserved Parameter Area

The following table describes the subfields in the DSRSV Reserved Parameter Area.

If You are Not Using COBOL II...

If you are using a programming language other than COBOL II to call GeoTAX, you must first initialize the COBOL II runtime environment using the COBMSTUB or COBMINI program. The following sections describe these methods.

Using COBMSTUB to Initialize the COBOL II Runtime Environment

If the non-COBOL II user-written program that calls GeoTAX is a batch program, you can use COBMSTUB to initialize the runtime environment. COBMSTUB is a stub program that ships with GeoTAX. With this method, the name of the user-written program is passed as a parameter, through JCL or other means, to COBMSTUB. COBMSTUB becomes the top program in the calling stack and causes the COBOL II run-time environment to initialize before the user-written program executes. We recommend that the user-written program perform a dynamic call to the GeoTAX callable.

Note: Sample JCL is provided in the sample library on your installation media.

Using COBMINI to Initialize the COBOL II Runtime Environment

If you are using an older version of COBOL (pre-COBOL II), complete the following to initialize the COBOL II runtime libraries.

1. Add the following to the WORKING_STORAGE SECTION:

10 COBM-RETURN-CODE PIC S9 (9) COMP VALUE ZERO88 COBMINI-OK VALUE ZERO88 COBMTRM-OK VALUE ZERO

2. Add the following to the PROCEDURE DIVISION to execute once before the first call to a GeoTAX callable:

CALL ‘COBMINI’ USING COBM-RETURN-CODE.


1-8 DSODST 8 Distance between the 2 input coordinates described in the input parameter. This distance is expressed in miles, accurate to one one-thousandth of a mile (.001). If the distance cannot be calculated, this field contains spaces.

NOTE: If no output distance is calculated, it is likely that an input error occurred. Check your coordinates, and try again.

9-50 Reserved 42


1-320 Reserved 320


IF NOT COBMINI-OK(handle error condition and abend)

3. After the last call, you can optionally add the following:

CALL ‘COBMTRM’ USING COBM-RETURN-CODE.IF NOT COBMTRM-OK(handle error condition and abend)

4. Compile the COBOL and link with the COBOL static link library.

If you use a language other than COBOL, you can apply the same techniques as described above, but you must convert the COBOL language syntax into your programming language’s syntax.

Using Assembler to Initialize the COBOL II Runtime Libraries

If you are using Assembler, complete the following to initialize the COBOL II runtime libraries.

1. Add the following constants:

COBMINIT DC F’0’ COBMINI RETURN CODE INITIALIZECOBMTERM DC F’0’ COBMINI RETURN CODE TERMINATE

2. Add the following to execute once before the first call to a GeoTAX callable:

CALL COBMINI, (COBMINIT) COBOL II INITIALIZATIONL 15,COBMINITC 15,=F’4’ CHECK RETURN CODEBNH INITOK...(handle bad return code from COBOL II initialization)

3. After the last call, you can optionally add the following:

CALL COBMINI, (COBMTERM) COBOL II TERMINATIONL 15,COBMTERMLTR15, 15 CHECK RETURN CODEBZ TERMOKC 15,=F’16’ CHECK RETURN CODEBE TERMOK(handle bad return code from COBOL II termination)

4. Assemble the program and link with the COBOL II static link library from the distribution media.

Calling GeoTAX Under CICS

When you call a module, you must pass, as parameters, the names of pre-defined call areas. These call areas are blocks of memory containing data used by both your driver program and the callable module. Each call area has an associated specific map. These maps describe the data stored in each byte in the call area. Because these maps are specific, both the callable module and the driver program know where each piece of data is


stored in the call area. Therefore, instead of passing all of the data between the driver and the callable module, the only parameter that is passed between the two programs is the name of the call area.

Note: If you are calling GeoTAX under CICS, you must pass a single 01-level call area.

Example Procedure Division for CICS

The following example procedure division shows the activity of calling GTMATI in a CICS environment. GTMATI is the interactive equivalent of the GTMATCH program.

COPY GTMATPRM.

77 GTMATCH-LEN PIC S9(4) COMP VALUE 8192.

MOVE SPACES TO MATCHER-PARAMETERS.MOVE "O" TO MCA-FUNCTION-REQ.MOVE SPACES TO MIA-STREET-1.MOVE ADDRESS-1 TO MIA-STREET-1.MOVE SPACES TO MIA-CITY.MOVE CITY TO MIA-CITY.MOVE STATE TO MIA-STATE.MOVE ZIP-CODE TO MIA-ZIP.MOVE ZIP4 TO MIA-Z4.MOVE SPACES TO MATCHER-OUTPUT-AREA.EXEC CICS LINK PROGRAM ('GTMATI')COMMAREA (MATCHER-PARAMETERS)LENGTH (GTMATCH-LEN)END-EXEC.

9 – Working With EXITOP from Other Applications

This chapter contains the parameter record layout for the callable areas of GTX50.

In this chapter

GTX50 EXITOP 140


GTX50 EXITOPWhen you use an exit operating procedure to call the GTX50 function, you pass pre-defined parameter areas to the program. These parameter areas are blocks of memory containing data that is used by both your executable program and the function it calls. The GTX50 function uses its own set of parameter areas. The table below describes the EXITOP parameter record you can define for the GTX50 callable function.

GTX50 EXITOP Parameter Record

This program accepts the same input as GTX10 (state, county, place, ZIP, or place name) and posts both the nine-byte GeoTAX key and the 1-byte return code. GTX50 also prints a report detailing matching statistics.

Position Field Name Description Comments

1-6 KEYWORD Contains the parameter name: EXITOP. Required

7 Reserved For CODE-1 Plus users: You must specify a P in this column to invoke the file activator in positions 56 through 59 of this EXITOP parameter record.

8-17 GTX50 Name of the output exit routine to activate. This routine must be linked with the EXEC-level program and must be present in the library you specified.

Required

18-21 Location of input FIPS state code

Location of the 2-byte state code.

22-25 Location of input FIPS county code

Location of the 3-byte county code.

26-29 Location of input FIPS place code

Location of the 5-byte place code.

30-33 Location of input ZIP code Location of the 5-byte ZIP code.

34-37 Location of input place name

Location of the 25-byte place name.

38-41 Location to post 9-byte GeoTAX key

Location to store the 9-byte GeoTAX key.

42-45 Location to post 1-byte GeoTAX return code

Location to store the 1-byte GeoTAX return code.

46 Reserved

47 Minimum coding level required to post data

Indicates the minimum codling level required to post data.

E Exact match required

P Partial match (or better) required

A Alternate match (or better) required

N Default match (or better) required

Space Defaults to N

48 Reserved

49 Blank or zero-filled for default match

Z Zero filled

B Blank space

Space Defaults to B

50 Reserved


51 Report suppression code X Suppress report from printing

Space Print summary report

52 Reserved

53-54 File activator (1) Example from CODE-1 Plus:

OK Successfully coded output file

CO Uncoded output file

ZP Invalid ZIP output file

P4 ZIP+4 coded (only) output file







10 –GeoTAX Integrator Series

This chapter describes the function calls (APIs) available to you with GeoTAX.

In this chapter

What Is the Integrator Series? 143What Are APIs? 143About the Programming Language 143Using the Examples Provided 144Parameter Structures 144Environment Variables 145Using the C API on a UNIX Platform 146Standard Return Values 147Function Call Summary 148Function Calls 150


What Is the Integrator Series?The Pitney Bowes Software Integrator Series is a collection of application programming interfaces (APIs) that allow applications to exploit the power of the Pitney Bowes software family of products. These functions only work if you have purchased these Pitney Bowes software products.

What Are APIs?The APIs allow applications to exploit the Pitney Bowes software family of products, in this case, GeoTAX. The Windows and UNIX C Language Application Program Interface (C API) to GeoTAX enables you to access GeoTAX functions from any Windows or UNIX application supporting the C language call interface.

The Matching APIs

The matching engine takes the input data from the user application and attempts to match it against one or more of the GeoTAX databases. These databases are in a Pitney Bowes proprietary format and can only be used with GeoTAX.

Depending on the API used, the user-written application needs to provide certain pieces of information to the API to get a valid response. These requirements are listed under each API-specific section of the chapter.

After the match attempt, the API returns a set of values to the user-written application that describe the success or failure of the attempt. These values can be interrogated for further action in the user application.

These matching APIs can be used in either a batch program that processes a file of address records or the interactive processing of one record at a time.

About the Programming LanguageThe C programming language is the preferred development language for both UNIX- and Windows-based applications. This series of APIs was designed with C in mind. UNIX- and Windows-based applications can also be developed in other languages, but in this guide, all syntax and program examples are written in the C programming language.

The Integrator Series uses many types and structures that are not part of the standard C language. These types and structures have been defined to make the task of creating integrated applications simpler and to make application sources clearer and easier to understand. All types and structures discussed in this manual are defined in the Integrator Series C-language header file for GeoTAX.


Using the Examples ProvidedAlthough some of the examples are not complete, you can use them in your application by taking the following steps:

1. Insert the include file in your program, located in the include (Windows) or /api (UNIX) subdirectory of the Integrator Series installation for C.

1. Define the appropriate include constants for the functions, structures, and constants used in the example.

2. Define and initialize all variables.

3. Replace comments that represent tasks with appropriate statements.

4. Check return values for errors and take appropriate action.

Parameter StructuresWhen you call a module, you must pass the names of pre-defined parameter structures. These parameter structures are blocks of memory containing data used by both your driver program and the callable module.

Each parameter structure has an associated map. These maps describe the data stored in each byte in the parameter structure. Because these maps are specific, both the callable module and the driver program know where each piece of data is stored in the parameter structure. Therefore, instead of passing all of the data between the driver and the callable module, the only parameter passed between the two programs is the name of the parameter structure.

Note: Each function includes a parameter structure called long lFixedString that enables you to null-terminate input/output strings or treat input/output strings as fixed buffers that are space-padded and not null-terminated. When defining this parameter structure, a value of 0 causes the function to null-terminate character strings so that trailing spaces are trimmed. The elements in the following parameter structures include room for the null-termination byte, and this is shown as [+1] under the Length heading in the parameter structure maps. Any value you enter other than 0 causes the function to treat character strings as fixed buffers, padding the remainder of the line with blanks.


Environment VariablesThe license and password file variables, GTGSLIC and DD_GTGSPAS, are associated with the directory pointed to by the %G1GTX% variable. The database variables are associated with the directory that is pointed to by the %G1DB% variable. Table 1 lists the environment variables:

These are the default names for GeoTAX. If you want a different location or name for your data files, set up the GeoTAX database file names and paths prior to calling any GeoTAX function using the Windows command line, for example:

Table 1: Environment Variables

Environment variable Definition

License and Password file variables

GTGSLIC license.lic - license file

DD_GTGSPAS gtgspas.lic -Password file

Database variables

GTGSADR Path to Address Matching files

GTGSZP4 us.z9 - zip 9 file

GTBDCOU cousub.txb - County Subdivision file

GTBDPLC place.txb - Place Code/GNIS file

GTZ5GSB zip5.gsb - Optional Confidence Code file

DD_G1GTAUX User Auxiliary Database

DD_G1GTAX2 GeoTAX Auxiliary Database

DD_G1GTPTC Payroll Tax Correspondence Database

DD_GTTAXW Taxware lookup file

DD_G1GTSSD State-supplied Details

DD_G1GTSSN State-supplied Street Names

DD_G1GTSST State-supplied Table Data

DD_G1GTGSD State-supplied details; TS-158 format

DD_G1GTGSN State-supplied Street Names; TS-158 format

DD_G1GTGST State-supplied Table Data; TS-158 format

GTBDSPD spd.txb - SPD boundary file

GTBDIPD ipd.txb - IPD boundary file

GTBDPTD ptd.txb - PTD boundary file

GTBDPAY pay.txb - PAY boundary file

GTBDUSR usr.txb - User-defined boundary file

DD_GTMASTR Vertex MatchMaster file

DD_GTMSTR2 PB Vertex file

DD_GTTAXRT Pitney Bowes Software Sales and Use Tax Rate file

GTGCNTY counties.gsb - optional county confidence code file


SET DD_GTMASTR=c:\Program Files\Pitney Bowes\DB\MyGTMstr.DB

For UNIX:

export DD_GTMASTR=/g1/usr/db/gtmastr

Using the C API on a UNIX PlatformThe UNIX C Language Application Program Interface (C API) for GeoTAX is delivered with C source code and associated header files. These files are located in the $G1GTX/api subdirectory.

UNIX Environmental Considerations

• Pitney Bowes object files (.o and .gnt) are created on several platforms. You could incur linking and loading issues if you attempt to build executable programs or libraries with object files not created on these platforms. Different versions of a manufacturer’s hardware/operating system may be compatible with Pitney Bowes object files, but Pitney Bowes cannot support software created on platforms other than these combinations. You can find a complete list of these platforms at the Pitney Bowes support site at the following address: http://www.g1.com/Support/platforms.asp.

• The environment variables LD_LIBRARY_PATH on Linux, Solaris, LIBPATH on AIX, and SHLIB_PATH on HPUX should be set in the user’s login profile to ensure that the library path is not appended every time the Pitney Bowes setup shell script is evoked.

• Makefiles are included for building sample and test programs only. If you choose to use these Makefiles as templates for your own projects, please be aware that you must change the Makefile to meet your requirements.

• You must use an ANSI C or C++ compiler to build applications that link with Pitney Bowes software products.

• If you want to build shared objects/libraries or dynamically-linked objects to use in your project, you must use your hardware/operating system’s procedure for building shared libraries (such as sl and so). Pitney Bowes test programs ship as statically-linked executables. Please consult your systems manual or use the ld command to determine how to make shared objects/libraries or dynamically-linked objects for your particular system.

• If you receive unresolved symbols during the linking (binding) phase of creating your custom executable, this means that certain library functions are not available for the linker to find. Please ensure that your C libraries are included in linker’s library list and/or are on the LD_LIBRARY or LIBPATH or SHLIB_PATH environment variable list.

• If you have Oracle environmental variables set in your profile, please be aware that they may interfere with CD-ROM database loading processes because of the way data is streamed from the CD-ROM into the COBOL programs. If you experience database loading problems and are using Oracle, please check that the Oracle environmental variables are not active when you perform the CD-ROM database loads.


• The following script in $G1GTX/api may be helpful when building your C application using the Integrator Series for GeoTAX: Makefile — Example build using testapi.c (*.mk)

Once you have built the testapi executable and loaded the GeoTAX database into the $G1DB area, you can execute the test API programs (i.e., testaddr) and perform the various sample API functions for GeoTAX.

Standard Return ValuesThe following table lists the standard return values and their meanings:

Return Code DescriptionError Code

GTXAPI SUCCESS Call to function was successful 0

GTXAPI_CANT_LOAD_LIBRARY Cannot load GeoTAX LIB. 1

GTXAPI_CANT_UNLOAD_LIBRARY Cannot unload GeoTAX LIB. 2

GTXAPI_CANT_GET_ENVIR_VARIABLE Cannot find an environment variable. 3

GTXAPI_CANT_SET_ENVIR_VARIABLE Cannot set an environment variable. 4

GTXAPI_CANT_GET_REGISTRY_VALUE

Cannot find a registry value 5

GTXAPI_NULL_STRUCT_PTR Invalid pointer. 6

GTXAPI_NO_MATCH Insufficient (or blank) address information

20

GTXAPI_NO_HOUSE_NUM House number not found 21

GTXAPI_NO_STREET_NAME Street name not found 22

GTXAPI_LATLONG_UNDETERMINED Lat/long not determined on GeoTAX Auxiliary file match

23

GTXAPI_NO_ZIP_FOUND ZIP Code not found in database 24


Function Call SummaryThe following table summarizes the GeoTAX function calls.

Function Call Syntax Description

GetGeoDistance GetGeoDistance (&stLatLongIn, szDistance, lFixedString)

Calculates the distance between 2 latitude and/or longitude input coordinates.

GetGTXCensusBlockGrp GetGTXCensusBlockGrp (&stGTXAddr, &cGeoBlock, lFixedString)

Returns a 1-character census block group code.

GetGTXCensusTract GetGTXCensusTract (&stGTXAddr, szTract, lFixedString)

Returns a 6-character Census Tract code.

GetGTXCountyFIPS GetGTXCountyFIPS (&stGTXAddr, szFIPSCounty, lFixedString)

Returns the 3-character Federal Information Processing Standard (FIPS) county code.

GetGTXCountyName GetGTXCountyName (&stGTXAddr, szGTXCountyName, lFixedString)

Returns the 20-character (maximum) county name.

GetGTXDBInfo GetGTXDBInfo(&stGTXDBInfo, lFixedString)

Returns the vintage of the database as well as expiration information.

GetGTXDBVer GetGTXDBVer (szDBVer, lFixedString) Returns the 20-character database version string.

GetGTXKey GetGTXKey (&stGTXAddr, szGTXKey, lFixedString)

Returns a 9-byte code identifying the corresponding taxing jurisdiction for the input address.

GetGTXLatitude GetGTXLatitude (&stGTXAddr, szLatitude, &cLatDir, lFixedString)

Returns a latitude and North/South position.

GetGTXLatLong GetGTXLatLong (&stGTXAddr, &stLatLongOut, lFixedString)

Returns the complete latitude/longitude position.

GetGTXLongitude GetGTXLongitude (&stGTXAddr, szLongitude, &cLongDir, lFixedString)

Returns a longitude and East/West position.

GetGTXMCD GetGTXMCD (&stGTXAddr, szMCD, lFixedString)

Returns a 5-character Minority Civil Division/Census County Division (MCD/CCD). MCDs are primary divisions of counties established under state law. CCDs are the equivalent of MCDs but are established by the Census Bureau.

GetGTXMCDName GetGTXMCDName (&stGTXAddr, szMCDName, lFixedString)

Returns a 40-character Minority Civil Division/Census County Division (MCD/CCD). MCDs are primary divisions of counties established under state law. CCDs are the equivalent of MCDs but are established by the Census Bureau.

GetGTXPlaceCode GetGTXPlaceCode (&stGTXAddr, szGeoPlaceCode, lFixedString)

Returns the 5-character incorporated place code. Place codes are legal entities such as cities, towns, villages, and so on.

GetGTXPlaceName GetGTXPlaceName (&stGTXAddr, szGeoPlaceName, lFixedString)

Returns the 40-character (maximum) place name.

GetGTXState GetGTXState (&stGTXAddr, szGeoState, lFixedString)

Returns the 2-character state abbreviation.


GetGTXStateFIPS GetGTXStateFIPS (&stGTXAddr, szFIPSState, lFixedString)

Returns a 2-digit Federal Information Processing Standard (FIPS) state code

GetGTXSWVer GetGTXSWVer (szSWVersion, lFixedString)

Returns the version number and modification level of the GeoTAX software.

GTXLookup GTXLookup (&stXrefIn, &stXRefOut, lFixedString)

Returns a 9-byte Vertex key for every input address. The 9-byte key consists of cross-reference state (2 bytes), FIPS county (3 bytes), and cross-reference city (4 bytes) codes

GTXMatchAddress GTXMatchAddress (&stGTXIn, stGTXOut, lFixedString)

Matches an input address to the GeoTAX database using the street matcher. It returns matching latitude/longitude coordinates as well as other geocoding data from the system.

GTXTWLookup GTXTWLookup (&stTWIn, &stTWOut, lFixedString)

Performs a match to Taxware by returning a nine-byte key for every input address. The nine-byte key consists of Taxware state code (2 bytes), ZIP Code (5 bytes), and Taxware geocode (2 bytes)

GTXMatchLatLong GTXMatchLatLong(&stLatLongMatchIn, stGTXOut, lFixedString)

Takes an input latitude/longitude, matches it to the GeoTAX database and returns information obtained about the location.

Function Call Syntax Description


Function Calls

GetGeoDistance

GetGeoDistance is a function that allows you to compare two latitude or longitude input coordinates to the GeoTAX database and calculate the distance between the two.

Syntax

GetGeoDistance (&stLatLongIn, szDistance, lFixedString);

Parameters

LATLONGINPUT stLatLongIn; /* input structure for LATLONGINPUT (see below) */char* szDistance; /* output distance between the two points */long lFixedString; /* String termination flag */

Input Structure

Table 2: LATLONGINPUT Input Structure definition

Elements Data Type Required Description

cFunc char No Function to perform

szLatitude1 char[7+1] Yes Latitude of the first coordinate

cLat1Dir char Yes Direction (North/South) of the first coordinate:

N North

S South

szLongitude1 char[7+1] Yes Longitude of the first coordinate

cLong1Dir char Yes Direction (East/West) of the first coordinate

E East

W West

szLatitude2 char[7+1] Yes Latitude of the second coordinate

cLat2Dir char Yes Direction (North/South) of the second coordinate

N North

S South

szLongitude2 char[7+1] Yes Longitude of the second coordinate

cLong2Dir char Yes Direction (East/West) of the second coordinate

E East

W West


Output Structure

Code Example

#include “geotax.h”LATLONGINPUT stLatLongIn;char szDistance[8+1];long lFixedString;long lReturnCode;...strcpy (stLatLongIn.szLatitude1, “0389515”);strcpy (stLatLongIn.cLat1Dir, “N”);strcpy (stLatLongIn.szLongitude1,”0768359”);strcpy (stLatLongIn.cLong1Dir,”W”);strcpy (stLatLongIn.szLatitude2,”0389542”);strcpy (stLatLongIn.cLat2Dir,”N”);strcpy (stLatLongIn.szLongitude2,”0767280”);strcpy (stLatLongIn.cLong2Dir, “W”);lFixedString = 0;lReturnCode = GetGeoDistance(&stLatLongIn, szDistance,lFixedString);if (lReturnCode == GTXAPI_SUCCESS)printf (“The distance between the input points is: %s \n ”,szDistance );

Elements Data Type Description

szDistance char[8+1] Distance between the 2 points, expressed in miles and accurate to one-thousandth of a mile (.001). If the distance cannot be calculated, the field has blanks.


GetGTXCensusBlockGrp

GetGTXCensusBlockGrp returns a single-character census block group from the GeoTAX database. The block group is a cluster of census blocks that make up the smallest area for which the Census Bureau provides data.

Syntax

GetGTXCensusBlockGrp (&stGTXAddr, &cGeoBlock, lFixedString);

Parameters

GEOTAXADDRESS stGTXAddr; /* input address information (see below) */char* cGeoBlock; /* Single character Census block group */long lFixedString; /* String termination flag */

Input Structure

Output Structure

Code Example

#include "geotax.h"GEOTAXADDRESS stGTXAddr;char cGeoBlock;long lFixedString;long lReturnCode; ...strcpy (stGTXAddr.szAddrLine1, “4200 Parliament Place”);strcpy (stGTXAddr.szAddrLine2, “Suite 600”);strcpy (stGTXAddr.szAddrLine3, “ “);strcpy (stGTXAddr.szCity, “Lanham”);strcpy (stGTXAddr.szState, “MD”);strcpy (stGTXAddr.szZIP, “207061844”);lFixedString = 0;

lReturnCode = GetGTXCensusBlockGrp(&stGTXAddr, &cGeoBlock, lFixedString);


szAddrLine1 char[100+1] Primary address line.

szAddrLine2 char[100+1] Secondary address line.

szAddrLine3 char[100+1] Tertiary address line.

szCity char[50+1] City Line.

szState char[50+1] State line.

szZIP char[9+1] 9-digit ZIP Code.


cGeoBlock char 1-character Census Block Group code


if (lReturnCode == GTXAPI_SUCCESS) printf (“Output census block group code is: %c\n ”, cGeoBlock);

GetGTXCensusTract

GetGTXCensusTract returns a six-character Census Tract from the GeoTAX database. The Census Tract is a small statistical subdivision of a county, established by the Census Bureau.

Syntax

GetGTXCensusTract (&stGTXAddr, szTract, lFixedString);

Parameters

GEOTAXADDRESS stGTXAddr; /* input address information (see below) */char* szTract; /* 6 character Census tract */long lFixedString; /* String termination flag */

Input Structure

Output Structure

Code Example

#include "geotax.h"GEOTAXADDRESS stGTXAddr;char szTract[6+1];long lFixedString;long lReturnCode; ...strcpy (stGTXAddr.szAddrLine1, “4200 Parliament Place”);strcpy (stGTXAddr.szAddrLine2, “Suite 600”);strcpy (stGTXAddr.szAddrLine3, “ “);strcpy (stGTXAddr.szCity, “Lanham”);









szTract char[6+1] 6-characters Census Tract code


strcpy (stGTXAddr.szState, “MD”);strcpy (stGTXAddr.szZIP, “207061844”);lFixedString = 0;

lReturnCode = GetGTXCensusTract (&stGTXAddr, szTract, lFixedString);

if (lReturnCode == GTXAPI_SUCCESS) printf (“Output Census tract code is: %s\n ”,szTract);

GetGTXCountyFIPS

GetGTXCountyFIPS returns a three-character Federal Information Processing Standard (FIPS) county code. This is the standard U.S. government code for identification of counties in federal data.

Syntax

GetGTXCountyFIPS (&stGTXAddr, szFIPSCounty, lFixedString);

Parameters

GEOTAXADDRESS stGTXAddr; /* input address information (see below) */char* szFIPSCounty; /* 3-character FIPS County code */long lFixedString; /* String termination flag */

Input Structure

Output Structure

Code Example

#include “geotax.h”GEOTAXADDRESS stGTXAddr;char szFIPSCounty[3+1];long lFixedString;long lReturnCode; ..









szFIPSCounty char[3+1] 3-digit FIPS county code


.strcpy (stGTXAddr.szAddrLine1, “4200 Parliament Place”);strcpy (stGTXAddr.szAddrLine2, “Suite 600”);strcpy (stGTXAddr.szAddrLine3, “ “);strcpy (stGTXAddr.szCity, “Lanham”);strcpy (stGTXAddr.szState, “MD”);strcpy (stGTXAddr.szZIP, “207061844”);lFixedString = 0;

lReturnCode = GetGTXCountyFIPS(&stGTXAddr, szFIPSCounty, lFixedString);

if (lReturnCode == GTXAPI_SUCCESS) printf (“Output FIPS County code is: %s\n ”, szFIPSCounty);

GetGTXCountyName

GetGTXCountyName returns a 25-character (maximum) county name from the GeoTAX database.

Syntax

GetGTXCountyName (&stGTXAddr, szGeoCountyName, lFixedString);

Parameters

GEOTAXADDRESS stGTXAddr; /* input address information (see below) */char* szGeoCountyName; /* 25-character County name */long lFixedString; /* String termination flag */

Input Structure

Output Structure

Code Example

#include “geotax.h”GEOTAXADDRESS stGTXAddr;char szGeoCountyName[25+1];









szGeoCountyName char[25+1] Name of county; 25 characters maximum


long lFixedString;long lReturnCode; ...strcpy (stGTXAddr.szAddrLine1, “4200 Parliament Place”);strcpy (stGTXAddr.szAddrLine2, “Suite 600”);strcpy (stGTXAddr.szAddrLine3, “ “);strcpy (stGTXAddr.szCity, “Lanham”);strcpy (stGTXAddr.szState, “MD”);strcpy (stGTXAddr.szZIP, “207061844”);lFixedString = 0;

lReturnCode = GetGTXCountyName (&stGTXAddr, szGeoCountyName, lFixedString);

if (lReturnCode == GTXAPI_SUCCESS) printf (“Output 25 character county name is: %s\n ”, szGeoCountyName);

GetGTXDBInfo

GetGTXDBInfo will query two files of the Street Database and the SPD File and return the vintage date of each. If also returns the date the files will expire and the number of days remaining until they do expire.

Syntax

GetGTXDBInfo (&stGTXDBInfo, lFixedString);

Parameters

DBINFO stGTXDBInfo; /* I/O structure for DBINFO (see below) */long lFixedString; /* String termination flag */

Input/Output Structure

Data structure for DBINFO


szGenioPGM char[8+1] Unused at this time

szBaseFileDate char[6+1] Unused at this time

szBaseExpDate char[6+1] Unused at this time

szBaseDaysLeft char[3+1] Unused at this time

szStreetFileDate char[6+1] Vintage of the Street files (G1GTGTD)

szStreetExpDate char[6+1] Expiration date of the Street files

szStreetDaysLeft char[3+1] Number of days until Street files expire

szSPDFileDate char[6+1] Vintage of the SPD file (GTBDSPD)

szSPDExpDate char[6+1] Expiration date of the SPD file

szSPDDaysLeft char[3+1] Number of days until the SPD file expires


Code Example

#include “GeoTAX.h”DBINFO stGTXDBInfo;long lReturnCode;long lFixedString;...lFixedString = 0;

lReturnCode = GetGTXDBInfo (&stGTXDBInfo, lFixedString);

if (lReturnCode = GTXAPI_SUCCESS){printf ("\nStreet File Vintage Date = '%s'", stGTXDBInfo.szStreetFileDate);printf ("\nDays until Street Files expires='%s'",

stGTXDBInfo.szStreetDaysLeft);printf ("\nSPD File Vintage Date = '%s'", stGTXDBInfo.szSPDFileDate);printf ("\nDays until SPD File expires = '%s'", stGTXDBInfo.szSPDDaysLeft);}

GetGTXDBVer

GetGTXDBVer returns the 20-character GeoTAX base master file vintage.

Syntax

char* szDBVer; /* 20-character database vintage string */long lFixedString; /* String termination flag */


Code Example

#include “GeoTAX.h”char szDBVer[20+1];long lReturnCode;long lFixedString;...lFixedString = 0;lReturnCode = GetGTXDBVer (szDBVer, lFixedString);

if (lReturnCode == GTXAPI_SUCCESS) printf (“\GeoTAX database vintage: %s \n”, szDBVer);


szDBVer char[20+1] GeoTAX database vintage string.


GetGTXKey

GetGTXKey returns a GeoTAX key from the GeoTAX database file. The key identifies the taxing jurisdiction for the corresponding input address.

Syntax

GetGTXKey (&stGTXAddr, szGTXKey, lFixedString);

Parameters

GEOTAXADDRESS stGTXAddr; /* input address information (see below) */char *szGTXKey; /* 9-character GeoTAX key */long lFixedString; /* String termination flag */

Input Structure

Code Example

#include “GeoTAX.h”GEOTAXADDRESS stGTXAddr;char szGTXKey [9+1];long lFixedStringlong lReturnCode...strcopy (stGTXAddr.szAddrLine1, “4200 Parliament Pl”);strcopy (stGTXAddr.szAddrLine2, “Suite 600”);strcopy (stGTXAddr.szAddrLine3, “”);strcopy (stGTXAddr.szCity, “Lanham”);strcopy (stGTXAddr.szState, “MD”);strcopy (stGTXAddr.szZIP, “207061844”);

lFixedString = 0;

lReturnCode = GetGeoTAXKey (&stGTXAddr, szGTXKey, lFixedString);

if (lReturnCode == GTXAPI_SUCCESS) printf (“The GeoTAX key is ‘%s’”, szGTXKey);









GetGTXLatitude

GetGTXLatitude returns a latitude and North/South position from the GeoTAX database look up.

Syntax

GetGTXLatitude (&stGTXAddr, szLatitude, &cLatDir, lFixedString);

Parameters

GEOTAXADDRESS stGTXAddr; /* input address information (see below) */char* szLatitude; /* 7-character Latitude in degrees with 4 decimal

positions */char* cLatDir; /* Direction North/South */long lFixedString; /* String termination flag */

Input Structure

Output Structure

Code Example

#include “geotax.h”GEOTAXADDRESS stGTXAddr;char szLatitude[7+1];char cLatDir;long lFixedString;long lReturnCode; ...strcpy (stGTXAddr.szAddrLine1, “4200 Parliament Place”);strcpy (stGTXAddr.szAddrLine2, “Suite 600”);strcpy (stGTXAddr.szAddrLine3, “ “);strcpy (stGTXAddr.szCity, “Lanham”);









szLatitude char 7-character latitude in degrees with 4 decimal positions.

cLatDir char Direction:

N NorthS South



lReturnCode = GetGTXLatitude (&stGTXAddr, szLatitude, &cLatDir, lFixedString);

if (lReturnCode == GTXAPI_SUCCESS) printf (“Output Latitude is: %s%c\n ”, szLatitude, cLatDir);

GetGTXLatLong

GetGTXLatLong returns the complete latitude/longitude position from the GeoTAX database look up.

Syntax

GetGTXLatLong (&stGTXAddr, &stLatLongOut, lFixedString);

Parameters

GEOTAXADDRESS stGTXAddr; /* input address information (see below) */LATLONGOUTPUT stLatLongOut; /* output Latitude and Longitude structure */long lFixedString; /* String termination flag */

Input Structure









Output Structure

Code Example

#include “geotax.h”GEOTAXADDRESS stGTXAddr;LATLONGOUTPUT stLatLongOut;long lFixedString;long lReturnCode; ...strcpy (stGTXAddr.szAddrLine1, “4200 Parliament Place”);strcpy (stGTXAddr.szAddrLine2, “Suite 600”);strcpy (stGTXAddr.szAddrLine3, “ “);strcpy (stGTXAddr.szCity, “Lanham”);strcpy (stGTXAddr.szState, “MD”);strcpy (stGTXAddr.szZIP, “207061844”);lFixedString = 0;

lReturnCode = GetGTXLatLong(&stGTXAddr, &stLatLongOut , lFixedString);

if (lReturnCode == GTXAPI_SUCCESS) printf (“Output Longitude/Latitude is: %s%c, %s%c \n ”, stLatLongOut.szLatitude, stLatLongOut,cLatDir, stLatLongOut.szLongitude, stLatLongOut.cLongDir);

Table 3: Output Structure for GetGTXLatLong


szLatitude char[7+1] 7-character latitude in degrees with 4 decimal positions

cLatDir char Direction:

E EastW West

szLongitude char[7+1] 7-character longitude in degrees with 4 decimal positions

cLongDir char Direction:

N NorthS South


GetGTXLongitude

GetGTXLongitude returns a longitude and East/West position from the GeoTAX database look up.

Syntax

GetGTXLongitude (&stGTXAddr, szLongitude, &cLongDir, lFixedString);

Parameters

GEOTAXADDRESS stGTXAddr; /* input address information (see below) */char* szLongitude; /* 7 character Longitude in degrees with 4 decimal

positions */char* cLongDir; /* Direction East/West */long lFixedString; /* String termination flag */

Input Structure

Output Structure

Code Example

#include “geotax.h”GEOTAXADDRESS stGTXAddr;char szLongitude [7+1];char cLongDir;long lFixedString;long lReturnCode; ...strcpy (stGTXAddr.szAddrLine1, “4200 Parliament Place”);strcpy (stGTXAddr.szAddrLine2, “Suite 600”);strcpy (stGTXAddr.szAddrLine3, “ “);strcpy (stGTXAddr.szCity, “Lanham”);









szLongitude char[7+1] 7-character longitude in degrees with 4 decimal positions.

cLongDir char Direction:

E EastW West



lReturnCode = GetGTXLongitude(&stGTXAddr, szLongitude, &cLongDir, lFixedString);

if (lReturnCode == GTXAPI_SUCCESS) printf (“Output Longitude is: %s%c\n ”, szLongitude, cLongDir);

GetGTXMCD

GetGTXMCD return a five-character Minor Civil Division/Census County Division (MCD/CCD) from the GeoTAX database. MCDs are primary divisions of counties established under state law. CCDs are geographic areas defined by the Census Bureau, in cooperation with state and local officials, for the purpose of presenting data like that contained in MCDs in states where there are no official MCDs.

Syntax

GetGTXMCD (&stGTXAddr, szMCD, lFixedString);

Parameters

GEOTAXADDRESS stGTXAddr; /* input address information (see below) */char* szMCD; /* 5-character Minor Civil Division/Census County

Division */long lFixedString; /* String termination flag */

Input Structure

Output Structure

Code Example

#include “geotax.h”GEOTAXADDRESS stGTXAddr;char szMCD[5+1];long lFixedString;









szMCD char[5+1] 5-character Minor Civil Division Code


long lReturnCode; ...strcpy (stGTXAddr.szAddrLine1, “4200 Parliament Place”);strcpy (stGTXAddr.szAddrLine2, “Suite 600”);strcpy (stGTXAddr.szAddrLine3, “ “);strcpy (stGTXAddr.szCity, “Lanham”);strcpy (stGTXAddr.szState, “MD”);strcpy (stGTXAddr.szZIP, “207061844”);lFixedString = 0;

lReturnCode = GetGTXMCD (&stGTXAddr, szMCD, lFixedString);

if (lReturnCode == GTXAPI_SUCCESS) printf (“Output 5 character Minor Civil Division code is: %s\n ”, szMCD);

GetGTXMCDName

GetGTXMCDName returns the 40-character Minor Civil Division/Census County Division (MCD/CCD) name from the GeoTAX database. MCDs are primary divisions of counties established under state law. CCDs are geographic areas defined by the Census bureau, in cooperation with state and local officials, for the purpose of presenting data like that contained in MCDs in states where there are no official MCDs.

Syntax

GetGTXMCDName (szZIPCode, szMCDName, lFixedString);

Parameters

GEOTAXADDRESS stGTXAddr; /* input address information (see below) */char* szMCDName; /* 40-character Minor Civil Division/Census County division name */long lFixedString; /* String termination flag */

Input Structure









Output Structure

Code Example

#include “geotax.h”char szZIPCode[9+1];char szMCDName[40+1];long lFixedString;long lReturnCode; ...strcpy (stGTXAddr.szAddrLine1, “4200 Parliament Place”);strcpy (stGTXAddr.szAddrLine2, “Suite 600”);strcpy (stGTXAddr.szAddrLine3, “ “);strcpy (stGTXAddr.szCity, “Lanham”);strcpy (stGTXAddr.szState, “MD”);strcpy (stGTXAddr.szZIP, “207061844”);lFixedString = 0;

lReturnCode = GetGTXMCDName (&stGTXAddr, szMCDName, lFixedString);

if (lReturnCode == GTXAPI_SUCCESS) printf (“Output MCD/CCD Name is: %s\n ”, szMCDName);

GetGTXPlaceCode

GetGTXPlaceCode returns a five-character incorporated place code from the GeoTAX database. This code identifies incorporated, legal entities recognized by the individual state laws such as cities, villages, towns, and so on.

Syntax

GetGTXPlaceCode (&stGTXAddr, szGeoPlaceCode, lFixedString);

Parameters

GEOTAXADDRESS stGTXAddr; /* input address information (see below) */char* szGeoPlaceCode; /* 5-character Place code */long lFixedString; /* String termination flag */


szMCDName char[40+1] 40-character Minor Civil Division name


Input Structure

Output Structure

Code Example

#include “geotax.h”GEOTAXADDRESS stGTXAddr;char szGeoPlaceCode[5+1];long lFixedString;long lReturnCode; ...strcpy (stGTXAddr.szAddrLine1, “4200 Parliament Place”);strcpy (stGTXAddr.szAddrLine2, “Suite 600”);strcpy (stGTXAddr.szAddrLine3, “ “);strcpy (stGTXAddr.szCity, “Lanham”);strcpy (stGTXAddr.szState, “MD”);strcpy (stGTXAddr.szZIP, “207061844”);lFixedString = 0;

lReturnCode = GetGTXPlaceCode (&stGTXAddr, szGeoPlaceCode, lFixedString);

if (lReturnCode == GTXAPI_SUCCESS) printf (“Output 5 character place code is: %s\n ”, szGeoPlaceCode);









szGeoPlaceCode char[5+1] 5-Character Place Code


GetGTXPlaceName

GetGTXPlaceName returns a 40-character incorporated place name from the GeoTAX database.

Syntax

GetGTXPlaceName (&stGTXAddr, szGeoPlaceName, lFixedString);

Parameters

GEOTAXADDRESS stGTXAddr; /* input address information (see below) */char* szGeoPlaceName; /* 40-character place name */long lFixedString; /* String termination flag */

Input Structure

Output Structure

Code Example

#include “geotax.h”GEOTAXADDRESS stGTXAddr;char szGeoPlaceName[40+1];long lFixedString;long lReturnCode; ...strcpy (stGTXAddr.szAddrLine1, “4200 Parliament Place”);strcpy (stGTXAddr.szAddrLine2, “Suite 600”);strcpy (stGTXAddr.szAddrLine3, “ “);strcpy (stGTXAddr.szCity, “Lanham”);strcpy (stGTXAddr.szState, “MD”);strcpy (stGTXAddr.szZIP, “207061844”);lFixedString = 0;

lReturnCode = GetGTXPlaceName (&stGTXAddr, szGeoPlaceName, lFixedString);

if (lReturnCode == GTXAPI_SUCCESS)









szGeoPlaceName char[40+1] Place name (40-characters maximum)


printf (“Output 40 max character place name is: %s\n”, szGeoPlaceName);

GetGTXState

GetGTXState returns a two-character state abbreviation from the GeoTAX database.

Syntax

GetGTXState (&stGTXAddr, szGeoState, lFixedString);

Parameters

GEOTAXADDRESS stGTXAddr; /* input address information (see below) */char* szGeoState; /* 2-character State code */long lFixedString; /* String termination flag */

Input Structure

Output Structure

Code Example

#include “geotax.h”GEOTAXADDRESS stGTXAddr;char szGeoState[2+1];long lFixedString;long lReturnCode; ...strcpy (stGTXAddr.szAddrLine1, “4200 Parliament Place”);strcpy (stGTXAddr.szAddrLine2, “Suite 600”);strcpy (stGTXAddr.szAddrLine3, “ “);strcpy (stGTXAddr.szCity, “Lanham”);strcpy (stGTXAddr.szState, “MD”);strcpy (stGTXAddr.szZIP, “207061844”);lFixedString = 0;









szGeoState char[2+1] 2-character State abbreviation


lReturnCode = GetGTXState (&stGTXAddr, szGeoState, lFixedString);

if (lReturnCode == GTXAPI_SUCCESS) printf (“Output 2 character state abbreviation is: %s\n ”, szGeoState);

GetGTXStateFIPS

GetGTXStateFIPS returns a two-character Federal Information Processing Standard (FIPS) state code. This is the standard U.S. government code for identification of states in federal data.

Syntax

GetGTXStateFIPS (&stGTXAddr, szFIPSState, lFixedString);

Parameters

GEOTAXADDRESS stGTXAddr; /* input address information (see below) */char* szFIPSState; /* 2 character FIPS State code */long lFixedString; /* String termination flag */

Input Structure

Output Structure

Code Example

#include “geotax.h”GEOTAXADDRESS stGTXAddr;char szFIPSState[2+1];long lReturnCode; ...strcpy (stGTXAddr.szAddrLine1, “4200 Parliament Place”);strcpy (stGTXAddr.szAddrLine2, “Suite 600”);strcpy (stGTXAddr.szAddrLine3, “ “);strcpy (stGTXAddr.szCity, “Lanham”);








Element Data Type Description

szFIPSState char[2+1] Two-digit FIPS state code



lReturnCode = GetGTXStateFIPS (&stGTXAddr, szFIPSState, lFixedString);

if (lReturnCode == GTXAPI_SUCCESS) printf (“Output FIPS State code is: %s\n”,szFIPSState);

GetGTXSWVer

GetGTXSWVer returns the version number and modification level of the GeoTAX software.

Syntax

szSWVersion[8+1] /* Software version */long lFixedString; /* String termination flag */


Code Example

#include “GeoTAX.h”char szSWVersion[8+1];long lReturnCode;long lFixedString;...lFixedString = 0;

if (lReturnCode = GetGTXSWVer (szSWVersion, lFixedString) == GTXAPI_SUCCESS) printf (“\nSoftware version = %s \n”, szSWVersion);


szSWVersion char[8+1] Matching software release and modification number


GTXLookup

GTXLookup returns a nine-byte Vertex key for every state, county, place code, ZIP code, and place name key. The 9-byte key consists of cross-reference state (2 bytes), FIPS county (3 bytes), and cross-reference city (4 bytes) codes.

Syntax

GTXLookup (&stXrefIn, &stXrefOut, lFixedString);

Parameters

XREFINPUT stXrefIn; /* input structure for XREFINPUT (see below) */XREFOUTPUT stXrefIn; /* output structure for XREFOUTPUT (see below) */long lFixedString; /* String termination flag */

Input Structure

Table 4: XREFINPUT Input Structure for GTXLookup


szFIPSState char[2+1] FIPS State Code

szCountyCode char[3+1] FIPS County Code

szPlaceCode char[5+1] FIPS Place Code

szZIP char[5+1] ZIP Code

szPlaceName char[25+1] Place name


Output Structure

Code Example

#include “GeoTAX.h”XREFINPUT stXrefIn;XREFOUTPUT stXrefOut;char szSWVersion[7+1];long lReturnCode;long lFixedString;...strcopy (stXrefIn.szFIPSState, “24”);strcopy (stXrefIn.szCountyCode, “033”);strcopy (stXrefIn.szPlaceCode, “52975”);strcopy (stXrefIn.szZIP, “20706”);strcopy (stXrefIn.szPlaceName, “MITCHELVILLE”);lFixedString = 0;

if (lReturnCode = GTXAPI_SUCCESS) { printf (“\nReturn Code: %c\nState Code: %s\nCounty Code: %s”, stXrefOut.cGenRC, stXrefOut.szFIPSState, stXrefOut.szCountyCode);printf (“\nPlace Code: %s\nDB Vintage: %s\nSoftware Version: s”, stXrefOut.szPlaceCode, stXrefOut.szGTOVint,stXrefOut.szGTOVer); }

Table 5: XREFOUTPUT Output Structure for GTXLookup


cGenRC char GeoTAX return code denoting the level of match obtained against GTMASTR master file:

E Exact match using all 5 input parameters (state/county/place/ZIP code/place name).

P Partial match using 4 input fields (state/county/place/ZIP code).

A Alternate match using postal/place name-based answer (ZIP Code/place name).

N Unsuccessful match, default coded with table-based state code lookup.

Blank Unsuccessful match, no output.

szFIPSState char[2+1] Vertex State Code


szPlaceCode char[4+1] Vertex Place Code

szGTOVint char[20+1] Indicates the month, name, and year when the GeoTAX master file was created by the user.

szGTOVer char[4+1] Indicates the version of software used to create the file.


GTXMatchAddress

GTXMatchAddress is a function that allows you to match an input address to the GeoTAX database. It returns matching latitude/longitude coordinates as well as other geocoding data from the system.

Syntax

GTXMatchAddress (&stGTXIn, &stGTXOut, lFixedString);

Parameters

GTXINPUT stGTXIn; /* input structure for GTXINPUT (see below) */GTXOUTPUT stGTXOut; /* output structure for GTXOUTPUT (see below) */long lFixedString; /* String termination flag */


Input Structure

Table 6: GTXINPUT Input Structure Definition (Part 1 of 6)


cFunctionReq char Matcher control function:

B Called from batch process.

C Return state/county audit stats.

E Close files, end program.

O Called from on-line process.

NOTE: Any other value is treated as B.

cFirstLetterOpt char First Letter Expanded option:

Y Enable extra processing for bad (missing, wrong, etc.) first letter.

N No extra processing. (default)


cStreetCentroidOpt char Street Centroid option:

Y Enable matching to a street segment and provides a return of street segment centroid information.

N Normal matching to range only and not segment. (default)


cAddressRangeOpt char Ranged Address option:

Y Enable matching of house range input.

N No range input matching. (default)


cAltLookupOpt char Alternate Lookup option:

1 Prefer street match over firm match.

2 Prefer firm match over street match.

3 Match to address line only. (default)


cMatchMode char Match Mode option:

0 Enable ‘Exact address match mode.




cFallBackGeoOpt char Fall back Geographic option:

Y Find the first city and/or state centroid match from the set of possible matches found.

N No geographic centroid search. (default)



cSearchAreaOpt char Search Area option:

1 Search entire finance area for a match. (default)

2 Search a given radius but stay in state (this option requires an input radius set by szSearchRadius (below).


szSearchRadius char[9+1] Radius for Search Area; used in conjunction with cSearchAreaOpt (above) when it’s set to ‘2’:

1-99 miles; value must be right-justified, padded with zeroes to left. (25 miles default)

NOTE: A space or any non-numeric value will be treated as a zero.

cCacheSize char Specifies relative cache size to be used in address matching. Controls the amount of memory that is allocated to store temporary street data during address processing. A smaller cache may slow the performance. A cache size of 2 gives best performance, but uses more memory.

0 Smallest memory usage.

1 Middle memory usage.

2 Largest memory usage. (default)


cAddrPtInterpOpt char Address Point Interpolation option (only for use with point level geocoding):

Y Enables address point interpolation.

N No address point interpolation. (default)


cBoundaryConfidence char Indicates if a confidence code for a boundary match is returned:

Y Return Boundary confidence levels.

N Do not return boundary confidence levels. (default)


cUserBoundaryConfidence char Indicates if a confidence code for a user boundary match is returned:

Y Return User boundary confidence levels.

N Do not return user boundary confidence levels. (default)


cPlaceConfidence char Indicates if a confidence code for a place match is returned:

Y Return place confidence levels.

N Do not return place confidence levels. (default).


Table 6: GTXINPUT Input Structure Definition (Continued) (Part 2 of 6)



cCousubConfidence char Indicates if a confidence code for a county subdivision match is returned:

Y Return county subdivision confidence levels.

N Do not return county subdivision confidence levels. (default)


cCountyConfidence char Indicates if a confidence code for a county match is returned:

Y Return county confidence levels.

N Do not return county confidence levels. (default).


cLatLongInput char Indicates if a latitude/longitude coordinate is input rather than an address or ZIP Code (only select output will be available):

Y Latitude/longitude will be used to return select output

N Address and lastline info will be used to return output. (default)


cGetMultiple char For a multi-match outcome, indicates which match result should be returned; valid values are 1-9.

NOTE: Any non-numeric value will be ignored.

cBoundaryCacheSize char The relative size of cache for boundary file matching:

0 No caching

1 Medium cache (default)

2 Large cache

3 Very large cache


cAcceptMultiples char Indicates whether address information should be returned in a multi-match outcome:

Y Accept multiples and return 1st match information in multi-match list.

N Do not accept multiples and return information. (default)


cDbOverride char Override checking for expiration date.

Y Check for expiration date.

szBoundaryBuffDist char[9+1] Boundary buffer distance. Value must be zero padded. Example: ‘000005280’.

szUserBoundBuffDist char[9+1] User-defined Boundary file buffer distance. Value must be zero padded. Example: ‘000005280’.

cUserBoundMatch char User boundary match indicator.

U User-defined Boundary file Tax District




cPayTaxCorrMatch char PTC file matching indicator.

Y Match to PTC file.

cGTXAuxMatch char GeoTAX Auxiliary file matching indicator.

Y Match to GeoTAX Auxiliary file.

cAuxMatch char Indicates if the user Auxiliary file is used for matching.

Y Attempt to match to the User Auxiliary file.

N Do not use the User Auxiliary file. (default)

cStateMatch char Indicates if the State-supplied file is used for matching.

Y Attempt to match to State-supplied file. (default)

N Do not use the State-supplied file.

cStateOrder char Indicates which State-supplied file is to be used for address matching, and in the case of both, what the order of searching should be:

A Use only the Florida-native formatted file. (default)

B Use only the TS-158 formatted file.

C Use both formats and search Florida-native first.

D Use both formats and search TS-158 first.

NOTE: Any other value is treated as A. Valid checking is done only when State matching is on.

cBoundaryMatch char Indicates if boundary match call should be made and which file to use:

S Yes, file will be Special Purpose Tax Districts File

I Yes, file will be Insurance Premium Districts File

P Yes, file will be Property Tax Districts File

R Yes, file will be Payroll Tax Districts File

Y Yes, file will be determined by data read (for non-batch)

N No, do not call (default)

szIOModuleNam char[8+1] Generic I/O routine name to call. If left blank, GeoTAX utilizes I/O routines provided with the product. Program names may differ according to platform.

cFLRelaxSecInd char Indicates if the application enables matching to the Florida state file without requiring a match on secondary:

Y Relax secondary matching.

N Do not relax secondary matching. (default)


cLatLongSqueeze char Indicates if the application enables a Lat/Long squeeze:

Y Apply squeeze to Lat/Long. (default)

N Do not apply squeeze.





cTaxRate char PB Tax Rate matching indicator. Indicates whether to enable tax rate matching and the type of tax rate to return:

G Enable tax rate matching and return general rates.

A Enable tax rate matching and return automotive rates.

M Enable tax rate matching and return medical rates.

C Enable tax rat matching and return construction rates.

N or Blank Disable tax rate matching. (default)

NOTE: Any other value returns zeros in the tax rate output fields.

cStreetMatch char Street match indicator field.

Y Use the street matcher. (default)

N Do not use the street matcher.


cCasing char Indicates if name fields are in mixed case.

Y Yes

N No (default).


cZIPCentroidSrc char Unused

cGTXKeyDet char Attempt GeoTAX key determination:






cLatLongAltFmt char Latitude/longitude alternate format:

A 090000000N180000000W (default)

B 090.000000N180.000000W

C 90.000000-180.000000

D 90000000-180000000

NOTE: Any other value is treated as A.

cLatLongOffset char Latitude/longitude offset field. Value supplied will be used to calculate the offset for the street segment.

A No offsetting to be done

B 20 feet offset from street segment

C 40 feet offset from street segment (default)

D 60 feet offset from street segment

NOTE: Any other value is treated as C.

cLatLongSrc char Unused




szZIP char[9+1] Input ZIP+4 Code to match against the database.

szCity char[50+1] Input city name.

szState char[50+1] Input state name.

szAddrLine1 char[100+1] Input address line 1.



szFirmName char[100+1] Input firm name.

szAddrBlk2 char[100+1] Input address block line 2. If country, ZIP/postal code, city, or state/county input fields are blank or invalid, this area is searched for those values.

szAddrBlk3 char[100+1] Input address block line 3. If country, ZIP/postal code, city, or state/county input fields are blank or invalid, this area is searched for those values.

szInputLatitude char[11+1] Input latitude.

Required format:00.000000 or without the decimal point 00000000

szInputLongitude char[11+1] Input longitude.

Required format:000.000000 or without the decimal point 000000000; or00.000000 or without the decimal point 00000000

szLicenseFilePath char[72+1] License file path and name.

szLicenseFilePswd char[8+1} License file password.




Output Structure

Table 7: GTXOUTPUT Output Structure (Part 1 of 9)


szAbendRC char[2+1] Return code from matcher abnormal termination.

The first character indicates the file (or set of files affected.

Blank Matcher terminated normally

A User Auxiliary file problem

CE cousub.txb file problem

CI Confidence engine problem

D Boundary file problem

F User Boundary file problem

G Address Matching engine problem

L Licensing problem

S State file problem

U GeoTAX Auxiliary file problem

X Combination of street and state file problem

Z zip.gsb file problem

The second position is:

E Fatal issue, program terminating

F Expired database

I Informational

szAbendTxt char[80+1] Text description of matcher abnormal termination;“ “ if matcher terminated normally.

szWarnRC char[2+1] Warning return code; “ “ if no warnings issued.

szWarnTxt char[80+1] Text description of warning.

szSWDesc char[30+1] Matching software description.

szRelModNum char[8+1] Matching software release number and modification level.

szTaxRateVint char[20+1] Pitney Bowes Software Sales and Use Tax Rate file vintage.

szTaxRateVer char[40+1] Pitney Bowes Software Sales and Use Tax Rate file software create version.

szAdvVint char[20+1] Unused.

szAdvVer char[40+1] Unused.

szStreetVint char[20+1] Unused.

szStreetVer char[40+1] Unused.

szGTXVint char[20+1] Tax Cross Reference File vintage.

szGTXVer char[40+1] Tax Cross reference file software create version.

cStateInd char 1-byte field indicating the source of the State-supplied file:

F Florida state data

N National format data.


szStateVint char[8+1] 8-byte field in MM/DD/YY format, indicating the data the state-supplied file was created.

szStateVer char[8+1] 8-byte field indicating the version of the GeoTAX master file that created the State-supplied files. In Rnn.nMnn format.

cGenRC char General return codes:

5 ZIP Code match

9 ZIP+4 Code match


C Street Centroid match

F Fallback Geographic match





O Input Lat/Long coordinates match

P Address point match




blank Did not match

NOTE: GeoTAX attempts matches to files in the following order: Landmark Auxiliary File, User Auxiliary File, state-supplied file, GeoTAX Auxiliary file, Points file, then Streets file.

cStreetORC char For street address matching, the output street address return code:

Z ZIP Code not found in street address database.

S Street not found in ZIP Code.

H House number not found on street.

L Lat/long not determined on the GeoTAX Auxiliary file, the User Auxiliary file, or the state-supplied file match.

blank Successful match

NOTE: If GeoTAX gets a state or auxiliary match, it tries to get a regular Street match to obtain a Lat/Long. If it cannot get a Street match, the Street Return Code is an L indicating that a Lat/Long could not be determined on a state or auxiliary match.

szFIPSState char[2+1] FIPS State code.

szCountyCode char[3+1] FIPS County code.

szCensusTract char[6+1] Census tract code.

cCensusBlock char Census block group.

szState char[2+1] 2-character state abbreviation.

szCountyName char[25+1] County name.

Table 7: GTXOUTPUT Output Structure (Continued) (Part 2 of 9)



szMCD char[5+1] Minor Civil Division/Census County Division (MCD/CCD) Code.

szMCDName char[40+1] MCD/CCD name.

szPlaceCode char[5+1] Place code.

szPlaceName char[40+1] Place name.

szPlaceClassCode char[2+1] Place class code.

cIncFlag char Place incorporated/unincorporated flag:

1 Incorporated

0 Unincorporated

blank Not found or does not exist on the FIPS 55 Place Code roster.

szPlaceLastAnxDat char[7+1] Last Annexed Date (in MM/YYYY format). This date represents the month and year of the most recent boundary change or the most recent available boundary information. This field is never blank

szPlaceLastUpDat char[7+1] Last Updated Date (in MM/YYYY format). This date reflects the month and year when TeleAtlas updated the data base to reflect attribute (name change, FIPS change, incorporated/unincorporated change, etc.) or boundary edits to the Place.

szPlaceLastVfyDat char[7+1] Last Verified Date (in MM/YYYY format). The Last Verified date is the month and year that TeleAtlas verified municipality change information.

szPlaceGNISCode char[9+1] Unique 9-digit Geographic Names Information System (GNIS) code.

cGeoTAXRC char GeoTAX return code denoting the level of match obtained against the Vertex or Taxware cross-reference files:

E Exact match, using all 5 fields.

P Partial match, using 4 fields.

A Alternate match using 3 fields.

N Record is default coded based on valid state code.

Blank No matching GeoTAX record found.

szGeoTAXKey char[9+1] 9-byte key, consisting of:

• 2-byte VERTEX state code, OR 2-byte Taxware state code

• 3-byte FIPS county code, OR 5-byte ZIP Code

• 4-byte VERTEX place code, OR 2-byte Taxware geocode.

szBlockID char[3+1] Census Block ID




cLatLongLevel char The latitude/longitude coordinates may be returned from one of a number of possible sources, some of which are optional. The output latitude/longitude level return code is a single character denoting the level for which the geocode was determined, as follows:



B Block group centroid

C City centroid


O Latitude/longitude was matched as input

R Street latitude/longitude based on street address

S State centroid

T Census tract centroid


Z ZIP Code centroid

blank Could not determine latitude/longitude.

If the General Return Code (cGenRC) is "P" (point match), then the following are possible values and have the following meaning:













szLatitude char[7+1] Latitude — 7-digit number in degrees and calculated to 4 decimal places (decimal is implied, not shown).

cLatDir char 1-character latitude directional:

N North

S South.

szLongitude char[7+1] Longitude — 7-digit number in degrees and calculated to 4 decimal places (decimal is implied, not shown).




cLongDir char 1-character longitude directional is one of the following:

E East

W West.

szLatLongAltFmt char[30+1] Latitude/longitude alternate format:

A 090000000N180000000W (default)

B 090.000000N180.000000W

C 90.000000-180.000000

D 90000000-180000000

szLatAltFmt2 char[9+1] Output latitude in a format used by the ARCOUT parameter.

• Bytes 735-743 Latitude in 90.000000 format

szLongAltFmt2 char[11+1] Output longitude in a format used by the ARCOUT parameter.

• Bytes 744-754 Longitude in -180.000000 format

szAuxData char[300+1] Reserved for data retrieved as a result of a GeoTAX Auxiliary or User Auxiliary match.




szStateData char[200+1] Reserved for data retrieved as a result of a state-supplied file match. Each format supported contains its own mask of what data resides in this location.

Florida-native format:

• Positions 1-40 City Name

• Positions 41-48 Date Effective

• Positions 49-98 Evidence

• Positions 99-101 Fire District ID

• Positions 102-105 Police District ID

• Position 171 Relax Match Flag

• Positions 172-176 Reserved

• Position 200 = F for Florida-native format

TS-158 format:

• Positions 1-28 City Name



• Positions 45-52 Date Effective

• Positions 53-60 Date Expiry

• Positions 61-150 Special Tax Districts (10 entries of 9 bytes)

– 61-69 Special Tax District 1










• Positions 151-199 reserved

• Position 200 = value N for TS-158

cTSStateInd char Indicator of TS-158 format.

szTSStateVint char[8+1] Vintage used to create the State-supplied file.

szTSStateVer char[8+1] Software version used to create the State-supplied file.

szNumSPD char[2+1] Number of Special Purpose Tax Districts (SPDs), Insurance Premium Districts (IPDs), Payroll Tax Districts (PAYs), or Property Tax Districts (PTDs) returned from Boundary match call.

SPD TAXDISTRICT[10]

SPD code, name, version date, effective date, compiled date, contact date, and update date.

szNumUser char[2+1] Number of user tax districts.

User USERTAXDISTRICT[10]

User tax districts.

cPTCRC char Output street address return code.




cNumPTC char Number of payroll PTCs.

szStateCntyName char[32+1] State county name.

PTCINFO PTCINFOARRAY[6]

PTC records.

szPTCFlags char[6+1] PTC flags.

szPTCVint char[20+1] PTC file vintage.

szPTCVer char[8+1] Version of GeoTAX that created PTC file.

szBoundVint char[20+1] Boundary file vintage.

IPD IPDINFO[10] Extra IPD information.

cPlacePointStatus char Status of the buffered point:





szPlaceBuffDist char[9+1] Place distance (in feet) to border.

cMCDPointStatus char Status of the buffered point:





szMCDBuffDist char[9+1] MCD distance (in feet) to border.

szConfSurfaceType char[2+1] Confidence Surface type:

0 Undefined




4 Point level match




8 Reserved

9 A ZIP confidence-surface generated



12 Reserved


szPlaceConfidence char[3+1] Place code confidence level.

szMCDConfidence char[3+1] MCD confidence level.

szCountyConfidence char[3+1] County confidence level.




szBoundConfidence char[10][3+1] Boundary confidence level.

szUserBoundConfidence char[10][3+1] User-defined boundary confidence level.

szAMMatchCode char[4+1] Match Code returned from address matching operation (see Appendix D: Match Codes).

szAMLocationCode char[4+1] Location Code returned from address matching/geocoding operations (see Appendix D: Location codes).

szAMDataVersion char[20+1] Address Matcher data version.

szAMSWVersion char[40+1] Address Matcher software version.

szAMFirmName char[40+1] Output firm name.

szAMAddrLine1 char[60+1] Output Address Line 1.

szAMAddrLine2 char[60+1] Output Address Line 2.

szAMLastLine char[60+1] Outline Last Line.

szAMUrbanization char[30+1] Output urbanization name.

szAMCity char[28+1] Output city.

szAMStateAbbr char[2+1] Output state abbreviation.

szAMZIP char[5+1] Output ZIP Code.

szAMZIP4 char[4+1] Output ZIP+4 Code.

szAMHouseNum char[11+1] Output house number.

szAMPreDir char[2+1] Output pre-directional.

szAMStreetName char[40+1] Output street name.

szAMStreetType char[4+1] Output street type.

szAMPostDir char[2+1] Output post-directional.

szAMUnitType char[4+1] Output secondary type.

szAMUnitNum char[11+1] Output secondary number.

szCBSACode char[5+1] CBSA code.

szCBSAName char[75+1] CBSA name.

szCBSADCode char[5+1] CBSAD code.

szCBSADName char[72+1] CBSAD name.

szCSACode char[3+1] CSA code.

szCSAName char[77+1] CSA name.




TAXDISTRICT

TAXDISTRICT is a separate structure defined as follows:

cMetroFlag char Metro flag.

Metropolitan flag. Indicates if the CBSA is a “Metropolitan Statistical Area” or a “Micropolitan Statistical Area”.



cNumMultiple char The number of match candidates found in a multi-match.

szAMDataType char[2+1] Indicates the file from which the match was obtained:

0 USPS

1 TIGER

2 TomTom Streets

6 NAVTEQ Streets

7 TomTom Points

8 Centrus Points

11 NAVTEQ Points






cTaxRateRC char Tax Rate return code denoting the level of match obtained against the Pitney Bowes Software Sales and Use Tax Rate table:





Blank No matching Pitney Bowes Software Sales and Use Tax Rate record found.

TAXRATES TAXRATEINFO Sales and use tax rates from Pitney Bowes Software Sales and Use Tax Rate file.


szDistrictCode char[3+1] Tax District Code

szDistrictNum char[5+1] Tax District Number

szDistrictType char[6+1] Tax District Type

szDistrictId char[10+1] Tax District ID

szDistrictIDSupp char[10+1] Supplemental Tax District ID (Jurisdiction ID)

szDistrictNam char[60+1] Tax District Name

cDistrictFlag char[10] Tax District Flags (Individual 1-byte flags occurs 10 times)




USERTAXDISTRICT

USERTAXDISTRICT is a separate structure defined as follows:

TAXRATEINFO

Note: The format of the returned tax rate field is a 10-character decimal value, for example, 0.08250000 which represents a tax rate of 8.25%.

TAXRATEINFO is a separate structure defined as follows:

szVersionDate char[6+1] Tax District Version Date

szEffectiveDate char[6+1] Tax District effective date

szCompiledDate char[6+1] Tax District compiled date

szUpdateDate char[6+1] Tax District update date

cBuffRetCode char Return code

szBuffDist char[9+1] Buffer distance. Value must be zero padded. Example “000005280”.


szuserDistrId char[10+1] User District ID

szDistrictIDSupp char[10+1] User Supplemental Tax District ID (Jurisdiction ID)

szUserDistDesc char[50+1] User Supplemental District description.

cUserBuffRetCode char User return code

szUserBuffDist char[9+1] User buffer distance. Value must be zero padded. Example “000005280”.


szSalesTaxRateCombined char[10+1] The sum of the individual state, county, municipality and SPD tax rates.

szSalesTaxRateState char[10+1] State sales tax rate.

szSalesTaxRateCounty char[10+1] County sales tax rate.

szSalesTaxRateMuni char[10+1] Municipality sales tax rate.

szSalesTaxRateSPD char[10][10+1] Sales tax rate for up to 10 SPDs.

szUseTaxRateCombined char[10+1] The sum of the individual state, county, municipality and SPD use tax rates.

szUseTaxRateState char[10+1] State use tax rate.

szUseTaxRateCounty char[10+1] County use tax rate.

szUseTaxRateMuni char[10+1] Municipality use tax rate.

szUseTaxRateSPD char[10][10+1] Use tax rate for up to 10 SPDs.



PTCINFOARRAY

PTCINFOARRAY is a separate structure defined as follows:

Code Example

#include “geotax.h”GTXINPUT stGTXIn;GTXOUTPUT stGTXOut;long lReturnCode; ...stGTXIn.cFunctionReq = ‘O’;strcpy (stGTXIn.szAddrLine1, “4200 Parliament Place”);strcpy (stGTXIn.szAddrLine2, “Suite 600”);strcpy (stGTXIn.szCity, “Lanham”);strcpy (stGTXIn.szState, “MD”);strcpy (stGTXIn.szZIP, “207061844”);lFixedString = 0;

lReturnCode = GTXMatchAddress (&stGTXIn, &stGTXOut, lFixedString);

if (lReturnCode == GTXAPI_SUCCESS){ printf (“\nLatitude: %s%c Longitude: %s%c\n”,stGTXOut.szLatitude,stGTXOut.cLatDir,stGTXOut.szLongitude, stGTXOut.cLongDir); printf (“County, state: %s, %s\n\n”, stGTXOut.szCountyName, stGTXOut.szState);}

GTXTWLookup

GTXTWLookup returns an nine-digit key comprised of a two-digit Taxware state code, the five-digit ZIP Code, and two-digit Taxware geocode. If you own Taxware products, this key is used to find the appropriate taxing jurisdiction in Taxware lookup tables.

Note: Your organization must be a licensed user of Taxware products and you must have licensed this option from Pitney Bowes.

Syntax

GTXTWLookup (&stTWIn, &stTWOut, lFixedString);

Parameters

TWINPUT stTWIn; /* input structure for TWINPUT (see below) */TWOUTPUT stTWOut; /* output structure for TWOUTPUT (see below) */


szPTCCode char[15+1] PTC Code.

szPTCName char[40+1] PTC description


long lFixedString; /* String termination flag */Input Structure

Output Structure

Code Example

#include "geotax.h"TWINPUT stTWIn;TWOUTPUT stTWOut;long lReturnCode;long lFixedString;..stTWIn.cFunc = 'O';strcpy (stTWIn.szFIPSState, "24");

Table 8: TWINPUT Input Structure


cFunc char E Performs end-of-job functions, such as closing Taxware cross-reference file, as well as any platform-related end-of-job functions, while the calling program frees memory.

Other Performs match to the Taxware cross-reference files.

szFIPSState char[2+1] FIPS State Code



szPlaceCode char[5+1] FIPS Place Code

szTaxDist char[10][5+1] Tax District Code. Up to 10 SPD numbers.

Table 9: TWOUTPUT Output Structure


cGenRC char GeoTAX return code denoting the level of match obtained against GTTAXW master file:

E Exact match using all five input parameters—state, zip, county, place/city name, OCL, STD. (OCL and STD may not be present)

P Partial match using the first four input fields—state, zip, county, place/city name

N Default coded—state and zip

blank Unsuccessful match; no output.

szState char[2+1] Taxware State Code


szGeoKey char[2+1] Taxware geocode

szGTOVint char[20+1] Month, name, and year when the Taxware master file was created by the user.

szGTOVer char[4+1] Software version used to build the GTTAXW file.


strcpy (stTWIn.szCountyCode, "033");strcpy (stTWIn.szPlaceCode, "52975");strcpy (stTWIn.szZIP, "20706");strcpy (stTWIn.szZIP4, "1852");strcpy (stTWIn.szPlaceName, "MITCHELVILLE");stTWIn.cIncFlag = stTWOut.cIncFlag;lFixedString = 0;

lReturnCode = GTXTWLookup (&stTWIn, &stTWOut, lFixedString);

if (lReturnCode = GTXAPI_SUCCESS){ printf ("\nReturn code: %c\n", stTWOut.cGenRC); printf ("State, ZIP, Key: %s, %s, %s\n\n", stTWOut.szState, stTWOut.szZIP, stTWOut.szGeoKey);}

GTXMatchLatLong

The GTXMatchLatLong function takes an input latitude/longitude coordinate, matches it to the GeoTAX database and returns information obtained about the coordinate.

Syntax

GTXMatchLatLong (&stLatLongMatIn, &stGTXOut, lFixedString);

Parameters

LATLONGMATCHINP stLatLongMatIn; /* input structure for LATLONGMATCHINP(see below) */

GTXOUTPUT stGTXOut; /* output structure for GeoTAX informationobtained for the input Lat/Long */

long lFixedString; /* String termination flag */

Input Structure

Output Structure

The information obtained for the input coordinates is stored in the GTXOUTPUT structure; refer to Table 7 on page 180 for the definition of the GTXOUTPUT structure.

Code Example

#include “geotax.h”

Table 10: LATLONGMATCHINP Input Structure

Elements Data Type Required Description

szLatitude char[11+1] Yes Latitude of the input coordinate

Format is:" 90.000000" or " 90000000"

szLongitude char[11+1] Yes Longitude of the input coordinate

Format is:"-180.000000" or " -180000000"


LATLONGMATCHINP stLatLongMatIn;GTXOUTPUT stGTXOut;long lFixedString;long lReturnCode; ...strcpy (&stLatLongMatIn.szLatitude, " 40.017985");strcpy (&stLatLongMatIn.szLongitude, "-105.240762" );lFixedString = 0;

lReturnCode = GTXMatchLatLong (&stLatLongMatIn, &stGTXOut, lFixedString);

if (lReturnCode == GTXAPI_SUCCESS){ printf (“\nLatitude: %s%c Longitude: %s%c\n”,stGTXOut.szLatitude,stGTXOut.cLatDir,stGTXOut.szLongitude, stGTXOut.cLongDir); printf (“County, state: %s, %s\n\n”, stGTXOut.szCountyName, stGTXOut.szState);}

A – Sample Library Member Reference

In this appendix

Sample Library Members 195


Sample Library MembersThis appendix describes the sample library members included with your software. Pitney Bowes is not responsible for any changes you make to the sample members.

Note: Not all members are available on all platforms.

The following table lists the sample library members and their contents.

Member Contents

DSCPARM This member is the COBOL copybook that describes the interface area used when calling the GeoTAX CICS Distance Calculator program (GCP20C).

DSIPARM This member is the COBOL copybook that describes the input area parameter used when calling the GeoTAX Distance Calculator program (GCP20).

DSOPARM This member is the COBOL copybook that describes the output area parameter used when calling the GeoTAX Distance Calculator program (GCP20).

DSRPARM This member is the COBOL copybook that describes the save area parameter used when calling the GeoTAX Distance Calculator program (MFDIST).

GTAAPARM This member is the COBOL copybook that describes the counter area used in the Matcher program (GTMATCH) that is returned on a function call of 'C' at the end of execution.

GTCPARM This member is the COBOL copybook that describes the interface area used when calling the GeoTAX CICS Matcher program (GTX10C).

GTDBIPRM This member is the COBOL copybook that describes the interface area used when calling the GeoTAX Database Version Utility program (GTDBINFO).

GTIPARM This member is the COBOL copybook that describes the input area parameter used when calling the GeoTAX Vertex Matcher program (GTX10).

GTOPARM This member is the COBOL copybook that describes the output area parameter used when calling the GeoTAX Vertex Matcher program (GTX10).

GTMATPRM This member is the COBOL copybook that describes the interface area used when calling the GeoTAX Matcher program (GTMATCH).

GTI2PRM This member is the COBOL copybook that describes the input area used when calling the GeoTAX Taxware Lookup program (GTX20).

GTO2PRM This member is the COBOL copybook that describes the output area used when calling the GeoTAX Taxware Lookup program (GTX20).

SMPLEXOP A COBOL program that illustrates how to write an EXITOP program.

B -GeoTAX Parameter Record Reference

In this appendix

This appendix provides information on the GeoTAX parameter records. For information on creating and editing the parameter record and setting it up for a batch job, see “Setting up and running a Batch Job” on page 85.

ADDRDF 198AEOUT 199ALOUT 201ARCOUT 203AUXOUT 204BF2OUT 205BUFOUT 206CBSOUT 207CNFOUT 209CONFIG 210CONFRM 214CONSxx 215CS ZIP 216DISTIT 217EXITOP (GTX50) 218FILEDF 219FIRMNM 224GEOOUT 225HEADER 229IPDOUT 230IPROUT 231LATLON 234LLOUT 235MCDOUT 239MOVE I 239MOVE O 241


PAGESZ 242PAYOUT 243PCOUT 245PTCOUT 247PTDOUT 249REPORT 250SPDOUT 251STEOUT 252TAXOUT 253TESTIT 255UFTxx 255UHDxx 256USROUT 257


ADDRDFADDRDF defines the location, length, and format of the addresses in the input record.

A field is any continuous series of characters in the input file. You can define a field to start in any position in the input file, and extend fields for any length you choose. For example, you could specify that positions 100-140 in the input file make up one field.

A line is a continuous series of characters in the input file that GeoTAX assumes contains all the information that appears on one line of an address label.

Note: If you specify that your input address is in lines, you should define the lines in the order in which they normally appear on a mailing label: the first line (left-most) is the least significant, and the last line (right-most) is the most significant. GeoTAX treats the last line you define that contains data as the primary address line.

Field-by-Field

The following table describes each field of ADDRDF.


1-6 KEYWORD Parameter name: ADDRDF Required

8 Format of address information

Select one of the following:

L Address consists of multiple lines

F Elements concatenated to create a single address line

M Address exists in a single line

NOTE: When you select M, you may only use the location for address line 1.

Required

10-12 Location of ADDRESS 1 Location of first line or field. RequiredNo default.

14-15 Length of ADDRESS 1 Length of first field or address line. RequiredNo default.

17-19 Location of ADDRESS 2 Location of second line or field. OptionalNo default.

21-22 Length of ADDRESS 2 Length of second field or address line. OptionalNo default.

24-26 Location of ADDRESS 3 Location of third line or field. OptionalNo default.

28-29 Length of ADDRESS 3 Length of third field or address line. OptionalNo default.

31-33 Location of ADDRESS 4 Location of fourth line or field. OptionalNo default.

35-36 Length of ADDRESS 4 Length of fourth field or address line. OptionalNo default.

38-40 Location of ADDRESS 5 Location of fifth line or field. OptionalNo default.

42-43 Length of ADDRESS 5 Length of fifth field or address line. OptionalNo default.


Example

Using the following example, the input address is specified as follows:

• The address consists of multiple lines

• The first address line begins in position 51 and is 40 bytes

• The second address line begins in position 92 and is 40 bytes

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890ADDRDF L 051 40 092 40

AEOUTAEOUT is an optional parameter that tells GeoTAX where in the output file to store the individual address elements. This parameter allows you to specify the following:

• Location for the house number

• Location for the leading directional

• Location and length of the street name

• Location for the suffix

• Location for the trailing directional

• Location for the apartment designator

• Location for the apartment number

Field-by-Field

The following table describes each field of AEOUT.

45-47 Location of ADDRESS 6 Location of sixth line or field. OptionalNo default.

49-50 Length of ADDRESS 6 Length of sixth field or address line. OptionalNo default.



1-6 KEYWORD Parameter name: AEOUT Required

8-10 Location to store 11-byte House Number

Location on output record for House Number

Optional

12-14 Location to store 2-byte Pre-Directional

Location on output record forPre-Directional

Optional

16-18 Location to store Street Name

Location on output record for Street Name

Optional

20-21 Length of Street Name Length of Street Name to store (maximum 40-bytes)

Optional

23-25 Location to store 4-byte Street Type

Location on output record for Street Type

Optional


Example

Using the following example, the following address elements are specified for the output record:

• The 11-byte house number is posted to position 30

• The 2-byte pre-direction is posted to position 42

• The street name is posted to position 45

• The length of the street name is the maximum at 40 bytes

• The 4-byte street type is posted to position 86

• The 2-byte post-directional is posted to position 91

• The 4-byte unit type is posted to position 93

• The 11-byte unit number is posted to position 98

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890AEOUT 030 042 045 40 086 091 093 098

27-29 Location to store 2-byte Post-Directional

Location on output record for Post-Directional

Optional

31-33 Location to store 4-byte Unit Type

Location on output record for Unit Type Optional

35-37 Location to store 11-byte Unit Number

Location on output record for Unit Number

Optional



ALOUTALOUT defines the following:.

• If the address was validated, the first line of the validated and standardized address. If the address could not be validated, the first line of the input address without any changes.

• If the address was validated, the second line of the validated and standardized address. If the address could not be validated, the second line of the input address without any changes.

• The validated city name.

• The validated state abbreviation.

• The 5-digit ZIP Code™; for example, 20706 (U.S.addresses only).

• The 4-digit add-on part of the ZIP Code™. For example, in the ZIP Code™ 60655-1844, 1844 is the 4-digit add-on. (U.S. addresses only.)

• The complete last line of the address – for example, BOULDER, CO 80301-2532.

Field-by-Field

The following table describes each field of ALOUT.


1-6 KEYWORD Parameter name: ALOUT Required

8-10 Location to store the 4-byte Address Match Return Code

Location on output record for the address Match Code. (For values, see “Match Codes” on page 263”).

Optional

12-14 Location to store Address Line 1

Location on output record for Address Line 1

Optional

16-17 Length of Address Line 1 Length of Address Line 1 to store (maximum 60 bytes)

Optional

19-21 Location to store Address Line 2

Location on output record for Address Line 2

Optional

23-24 Length of Address Line 2 Length of Address Line 2 to store (maximum 60 bytes)

Optional

26-28 Location to store City Name

Location on output record for City Name (up to 28 bytes)

Optional

30-31 Length of City Name Length of City Name to store (maximum 28 bytes)

Optional

33-35 Location to store 2-byte State Abbrev

Location on output record for State Abbrev.

Optional

37-39 Location to store5-byte ZIP

Location on output record for ZIP Optional

41-43 Location to store 4-byte ZIP+4

Location on output record for ZIP+4 Optional

45-47 Location to store Last Line Location on output record for Last Line Optional

49-50 Length of Last Line Length of Last Line (maximum 60-bytes) Optional


Example

In the following example, GeoTAX posts data in the output record as follows:

• Position 51 is the location for the 4-byte Address Match Return Code

• Position 56 is the location for Address Line 1

• Length of Address Line 1 is 50 bytes

• Position 107 is the location for the Address Line 2

• Length of Address Line 2 is 50 bytes

• Position 210 is the location for the City Name

• Length of City Name is 28 bytes

• Position 238 is the location for the 2-byte State Abbreviation

• Position 241 is the location for the 5-byte ZIP

• Position 256 is the location for the Last Line

• Length of Last Line is 60 bytes

• The format of the Last Line is City, State and ZIP

• Position 316 is the location for the Urbanization Name

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890ALOUT 051 056 50 107 50 210 28 238 241 256 60 Z 316

52 Format of Last Line Code indicating the output format of the Last Line:

S City and State only

Z City, State and ZIP (5-dig. only)

9 City, State and ZIP+4

Optional

54-56 Location of 30-byte Urbanization Name

Location on output record for Urbanization Name

Optional



ARCOUTBy default, GeoTAX posts latitude and longitude coordinates determined as a result of a match to the GTBMARC file. (You use the FILEDF parameter to tell GeoTAX you want a GTBMARC file.) The ARCOUT parameter record allows you to specify data, in addition to the latitude and longitude, that GeoTAX posts to the GTBMARC output records. You can specify up to 25 ARCOUT parameter records, with each ARCOUT parameter record specifying only one output field. Using ARCOUT, you can specify the location and length of data from the GTBMCOK output file to be copied to the GTBMARC file.

Note: The sequence of your ARCOUT parameter records determines the sequence of output fields in an output record.

Latitude is the first field posted in each record, followed by longitude. Each field is comma-delimited unless you specify another delimiter in the FILEDF parameter. You can use the GTBMARC output file as input to your own mapping application, such as MapInfo Professional.

Field-by-Field

The following table describes each field of ARCOUT.

Example

Using the first example, GeoTAX posts place codes in the GTBMARC output records. Place codes are copied from the GTBMCOK file, starting in position 31, for a length of five. Using the second example, GeoTAX posts the place names. Place names are copied from GTBMCOK, starting in position 37 for a length of 40.

Note: By default, a comma is the delimiter placed between fields in the GTBMARC file.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890ARCOUT 031 05 PLACE CODEARCOUT 037 40 PLACE NAME

The following is the resulting GTBMARC output file.

Record #1Latitude,Longitude,PLACE CODE,PLACE NAMERecord #239.397562,-76.504795,13325,CARNEYRecord #338.948634,-76.837170,52975,MITCHELLVILLERecord #430.078536,-94.0917883,07000,BEAUMONT


1-6 KEYWORD Parameter name: ARCOUT Required

8-10 Location of data Location in the GTBMCOK file to retrieve data.

RequiredNo default.

12-13 Length of data to retrieve Length of data that will be copied to the GTBMARC output record.

RequiredNo default.

15-44 Descriptive literal of what the data represents

Specify a title associated with the data to copy from GTBMCOK.


The first record contains the literals in the order specified. By default, the first two literals are latitude and longitude. In this example, “PLACE CODE” and “PLACE NAME” are specified as the next two literals. Records 2-4 are records containing the latitude/longitude coordinates, followed by the place code and place name data copied from the GTBMCOK file as specified by the positions and lengths in the ARCOUT parameter records.

AUXOUTAUXOUT allows for the posting of data specified in the user-defined portion of the auxiliary files to the output records. When a match is made to either the Landmark Auxiliary file, User-defined Auxiliary file or GeoTAX Auxiliary file, if the optional user-defined portion of the auxiliary file was defined, then the data is posted to the output record according to the location and length specified in the AUXOUT parameter record.

Field-by-Field

The following table describes each field of AUXOUT.

Example

In the following example, if a match is made to an auxiliary file, GeoTAX posts the user-defined portion of the data to the output record beginning in position 50, with a data length of 75 bytes.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890AUXOUT 050 075


1-6 KEYWORD Parameter name: AUXOUT Required

8-10 Position to post the user-defined section of the auxiliary file

Location where data is posted in the name-and-address record of the user-defined portion of the auxiliary file.

Required

12-14 Length of data to post Length of the user-defined section of the auxiliary file to post. Valid range is 001-300.

Required


BF2OUTThe BF2OUT parameter record provides you with a way to specify the distance, in feet, to use as a buffer around polygons in the user-defined boundary file and to post buffer information for the user-defined boundary file.

Field-by-Field

The following table describes each field of BF2OUT.

Example

In the following example, the buffer information for matching to the user-defined boundary file is as follows:

• 5280 feet is the input buffer distance

• Position 205 is the location in the output record for the District 1 buffer status and output distance


1-6 KEYWORD Parameter name: BF2OUT Required

8-16 Input buffer distance Input buffer distance, in feet; right justified and padded with zeros. Spaces are allowed in this field and are equivalent to zero.

Optional

18-20 District 1 buffer status and output distance

9-byte distance of the point to the border of the polygon and the 1-byte status of the point:

P Point in the polygon.

I Point in the buffer inside the polygon.

B Point in the buffer, outside of the polygon.


Optional


Same as District 1. Optional






















*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890BF2OUT 000005280 205 216 227 238 249

BUFOUTThe BUFOUT parameter record provides you with a way to specify the distance, in feet, to use as a buffer around polygons in SPD, IPD, PTD, and PAY boundary files and to post buffer information for the boundary file.

Field-by-Field

The following table describes each field of BUFOUT.


1-6 KEYWORD Parameter name: BUFOUT Required

8-16 Input buffer distance Input buffer distance, in feet; right justified and padded with zeros. Spaces are allowed in this field and are equivalent to zero.

Optional


9-byte distance of the point to the polygon and the 1-byte status of the point:





Optional
















Example

In the following example, the buffer information for the boundary file is as follows:

• 50 feet is the input buffer distance




*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890BUFOUT 000000050 260 271 282

CBSOUTCBSOUT is an optional parameter that allows you to specify Core-Based Statistical Area Division (CBSAD), Core-Based Statistical Area (CBSA), and/or Core Statistical Area (CSA) information to be posted to your output record.

Field-by-Field

The following table describes each field of CBSOUT.







1-6 KEYWORD Parameter name: CBSOUT Required

8-10 Location for 5-byte CBSAD Code

Contains the location in the output record where the CBSAD (Core-Based Statistical Area Division) Code is to be posted.

Optional

12-14 Location for 127-byte CBSAD Description

Contains the location in the output record where the CBSAD (Core-Based Statistical Area Division) Description is to be posted.

Optional

16-18 Location for 5-byte CBSA Code

Contains the location in the output record where the CBSA (Core-Based Statistical Area) Code is to be posted.

Optional

20-22 Location for 127-byte CBSA Description

Contains the location in the output record where the CBSA (Core-Based Statistical Area) Description is to be posted.

Optional

24-26 Location for 3-byte CSA Code

Contains the location in the output record where the CSA (Combined Statistical Area) Code is to be posted.

Optional


Example

In the following example, GeoTAX will post data to the output record as follows:

• Position 50 is the location for the 5-byte CBSA Division code

• Position 56 is the location for the 127-byte CBSA Division description

• Position 184 is the location for the 5-byte CBSA code

• Position 190 is the location for the 127-byte CBSA description

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890CBSOUT 050 056 184 190

28-30 Location for 127-byte CSA description

Contains the location in the output record where the CSA (Combined Statistical Area) Description is to be posted.

Optional

32-34 Location for 1-byte Metro Flag

Contains the location in the output record where the 1-byte Metro Flag is to be posted.

Metropolitan flag. Indicates if the CBSA is a “Metropolitan Statistical Area” or a “Micropolitan Statistical Area”.



Optional



CNFOUTCNFOUT is an optional parameter that allows you to post confidence information about the match results with Place, MCD or County address matching. You must define a buffer distance with the BUFOUT parameter card to return confidence information.

For more information on confidence levels, see “Geographic determination and confidence levels” on page 77.

Field-by-Field

The following table describes each field of CNFOUT.


1-6 KEYWORD Parameter name: CNFOUT Required

8-10 Location for 2-byte Confidence Surface Type

Confidence Surface types:

0 Undefined




4 Point level match




8 Reserved

9 A ZIP confidence-surface generated



12 Reserved


Optional

12-14 Location for 3-byte Place Confidence level

Output number is percentage confidence Optional

16-18 Location for 3-byte MCD Confidence level

Output number is percentage confidence Optional

20-22 Location for 10-byte Place Point Status and distance






Optional


Example

In the following example, when matching to the Place.txb file, GeoTAX will post data to the output record as follows:

• Position 50 is the location for the 2-byte Confidence Surface type

• Position 53 is the location for the 3-byte Place confidence level

• Position 57 is the location for the Place 9-byte distance of the point to the polygon and the 1-byte status of the point

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890CNFOUT 050 053 057

CONFIGCONFIG is an optional parameter that provides you with a way to specify whether you want to use the street address, state-supplied, GeoTAX Auxiliary, or User Auxiliary database during matching. (NOTE: The Landmark Auxiliary file does not need to be configured for matching as long as it is installed in the Database [db] folder.) The CONFIG parameter record also allows you to enable a number of matching features and options (use the corresponding link in the list below to find detailed information on the feature):

• First Letter Expanded Option - “Missing and wrong first letter matching” on page 65.

• Street Centroid Option - “Using street locator geocoding” on page 71.

• Address Range Option - “Matching address ranges” on page 62.

• Alternate Lookup Option - “Specifying an alternate lookup method using firm names” on page 65.

• Address Match Mode - “Using GeoTAX match modes” on page 60.

• Fallback Geographic Option - “Specifying a fallback geographic centroid search” on page 73.

• Search Area Option & Expanded Distance Radius - “Search area designation” on page 59.

• Cache Size - “Setting relative cache size to optimize performance” on page 55.

24-26 Location for 10-byte MCD Point Status and distance






Optional

28-30 Location for 3-byte County Confidence level

Output number is percentage confidence. Optional



• Address Point Interpolation Option - “Using address point interpolation” on page 69.

Field-by-Field

The following table describes each field of CONFIG.


1-6 KEYWORD Parameter name: CONFIG Required No default.

8 Street Match Indicator Indicates if the Street Address database is used in the match process:

Y Yes (default)

N No

Optional

10 State-supplied match indicator

Indicates if any of the state-supplied databases are used in the match process:

Y Yes

N No (default)

Optional

12 User Auxiliary File match indicator

Indicates if the User Auxiliary database is used in the match process:

Y Yes (default)

N No

Optional

13-21 Reserved

22 State format Indicates the state-supplied database used:

A Use the Florida native format exclusively (default)

B Use the TS-158 format exclusively

C Use both files for address matching, first attempting to match to the Florida file, then to the TS-158 file if a match is not achieved with the Florida file.

D Use both files for address matching, first attempting to match to the TS-158 file, then to the Florida file if a match is not achieved with the TS-158 file.

NOTE: This position is ignored unless position 10 contains a Y.

Optional

24 Relaxed Florida file secondary matching indicator

Indicates if there is relaxed secondary matching on the Florida file:

Y Relax secondary matching of Florida file

N Match to Florida file as normal (default)

Optional

26 GeoTAX Auxiliary file match indicator

Indicates if the GeoTAX Auxiliary file is used in the match process:

Y Yes (default)

N No

Optional

28 Mixed case option Indicates the casing of the following outputs: County Name, MSA Name, MCD/CCD Name, Place Name, Boundary file Tax District Names, PTC Code Descriptions:

Y Mixed case

Any other value returns output in upper case. (default)

Optional


30 Database expiration override switch

Indicates if GeoTAX can override the database expiration for master files and SPD files:

X Override expired database

Any other value does not allow GeoTAX to override the expired database. (default)

Optional

32 First Letter Expanded Option

Enable extra processing for bad first letter (missing, wrong, etc.):

Y Yes

N No (default)

Optional

34 Street Centroid Option Attempt to find the centroid of a street if unable to match address?

Y Yes

N No (default)

Optional

36 Address Range Option Enable address range matching and geocoding:

Y Yes

N No (default)

Optional

40 Alternate Lookup Option Specify the preferred lookup method:

1 Match to Address line then Firm Name line

2 Match to Firm Name line then Address line

3 Match to Address line only (default)

Optional

42 Address Match Mode Set the match mode:

0 Enable ‘Exact’ address match mode.



Optional

44 Fallback Geographic Option

Enable automatic Fallback Geographic option:

Y Yes - find the first city, county, and/or state centroid, then match from the set of possible matches found.

N No (default)

Optional

46 Search Area Option Assists in finding a match when the input address contains limited or inaccurate city or ZIP Code information:

1 Search the entire finance area (default)

2 Expanded distance. Use in conjunction with radius (see Expanded Distance Radius below), searches radius in miles, but only within the state.

NOTE: Any other value will be treated as 1.

Optional

48-49 Expanded Distance Radius

Distance, in miles, to use for the expanded search distance option above:

1-99 miles

25 miles (default)

Optional



Example

In this example, GeoTAX is configured with the following features:

• The Street Address database is used in the match process.

• The User-defined Auxiliary file is used in the match process.

• The Alternate Lookup option is enabled for matching to an Address line then Firm Name line.

• Address point interpolation is enabled.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890CONFIG Y Y 1 Y

51 Cache Size Relative cache size used in address matching. Controls the amount of memory that is allocated to store temporary street data during address processing. A smaller cache may slow the performance. A cache size of 2 gives best performance, but uses more memory.

0 Uses less memory

1 Uses medium memory

2 Uses more memory (default)

Optional

53 Address Point Interpolation Option

Enable address point interpolation:

Y Yes

N No (default)

Optional

55 Boundary Cache Size The relative size of cache used in boundary file matching:

0 No cache

1 Medium cache (default)

2 Large cache

3 Very large cache


Optional

57 Accept Multiple indicator Indicates whether the address information of the 1st match should be returned in a multi-match outcome:

Y Return 1st multiple information

N Do not return information on multiple. (default)

NOTE: Any other value will be treated as N.

Optional



CONFRMCONFRM specifies that records containing confirmation flag values should be confirmed without undergoing the matching process. It allows you to bypass the matching process for those records that you know are already correct.

You can enter up to four confirmation values on each parameter record, up to a maximum of 250 confirmation values. You can use as many CONFRM parameter records as necessary to indicate the confirmation values you desire. Strings of blank spaces is the confirmation values must be the first value on the parameter record.

Field-by-Field

The following table describes each field of CONFRM.


1-6 KEYWORD Parameter name: CONFRM Required

8-10 Location for output confirmation mark

Indicates whether or not the record is confirmed without processing.

Blank Not confirmed (record is address matched)

V Confirmed by comparison to an input confirmation flag value.

Optional

11-17 Reserved.

18-20 Location for confirmation flag

Location of the confirmation flag in the input record.

Required

22-22 Length of confirmation flag

Length of the confirmation flag in the input record. Must be 9 or less.

Required

24-25 Equal/not equal code Indicates if the confirmation flag in the records should be equal to or not equal to the confirmation values on this parameter record.

EQ Confirmation flag must be equal to one of the confirmation values for automatic confirmation.

NE Confirmation flag must not be equal to any of the confirmation values for automatic confirmation.

NOTE: The Equal/Not Equal Code must be the same on all CONFRM parameter records.

Required

27-35 Confirmation value 1 Value against which the confirmation flag in the input record is compared.

Optional. No default.








Example

In the following example, all APO/FPO and military base ZIP Codes are automatically confirmed. Further, if bytes 1-6 in an input record contain the word COSCAN, the record is automatically confirmed and the confirmation code is stored in position 254 of the output records.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890CONFRM 254 V 001 6 EQ COSCAN

CONSxxWith CONSxx you can define up to 99 constants to use with the MOVE I or MOVE O parameter records. Constants are identified as C01 through C99.

Field-by-Field

The following table describes each field of CONSxx.

Example*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890CONS86 This is the constant value for #86


1-4 KEYWORD Parameter name: CONS. Required.

5-6 Constant Number Constant being defined (i.e., C01 - C99). Required.No default.

8-71 Constant Value Value of the constant, up to 34 characters. Required.No default.


CS ZIPUse CS ZIP to identify the location, length, and format of city, state, and ZIP Code fields.

Field-by-Field

The following table describes each field of CS ZIP.


1-6 KEYWORD Parameter name: CS ZIP Required.

8-8 Format of city, state, and ZIP Code

Format of the city/state/ZIP Code on the input record.

A City/state/ZIP Code are among the address lines (position 8 on ADDRDF must be ‘L’)

C City and state mixes with address lines; ZIP Code is separate

M City and state are together in one field; ZIP Code is in a separate field

S City, state, and ZIP Code are in 3 separate fields

X City/state/ZIP Code are in a single field separate from the address.

Required. No default.

10-12 Location of separate ZIP Code

Location on the input record for the separate ZIP Code.

NOTE: Cannot be used with option A in position 8.


14-14 Format of separate ZIP Code

Format of the separate ZIP Code.

9 ZIP Code is 9 digits binary stored in 4-byte format

B ZIP Code is in 3-byte format

C ZIP Code is stored in 5-byte character format

P ZIP Code is in a 3-byte packed format (the sign digit is ignored so the start of a 5-byte packed 9-digit ZIP+4 Code can be used with this option).


16-18 Location of city/state/ZIP Code

Location on the input record for the field that contains the city, city/state, or city/state/ZIP.


20-21 Length of city/state/ZIP Code

Length of the city, city/state, or city/state/ZIP field.


23-25 Location of separate state

Location on the input record for the separate state.


27-28 Length of separate state

Length of the separate state. Optional. No default.

30-32 Location for storage of extracted ZIP Code

Location on the output record where the extracted ZIP Code is stored. If the input ZIP Code field is non-numeric or all zeros, then blanks are stored in this location.



Example

In the following example:

• City, state, and ZIP Code information is in three separate fields

• ZIP Code starts in position 156 on the input record

• ZIP Code is in 5-byte character format

• City name starts in position 132 on the input record and is 20 bytes

• State abbreviation starts in position 153 in the input record and is 2 bytes

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890CS ZIP S 156 C 132 20 153 02

DISTITDISTIT posts distance calculations between two different latitude/longitudes when you run a job. One latitude/longitude is fixed and the other may be determined by the LLOUT parameter record. The DISTIT parameter record may be used up to a maximum of 100 times.

Field-by-Field

The following table describes each field of DISTIT.

34-36 Location of ZIP+4 Code Location on the input record of the ZIP+4 add-on code.


38 Format of original ZIP+4 Code

Format of the ZIP+4 add-on code.

C 4-byte character format

B 3-byte binary format

P 3-byte packed format (the sign digit is ignored so that the start of a 5-byte packed 9-digit ZIP+4 Code can be used with this option).




1-6 KEYWORD Parameter name: DISTIT. Required

8-10 Location of output latitude/longitude argument

Same value as positions 12-14 of the LLOUT parameter record.

Required

12-27 Fixed latitude/longitude argument

Basis for all distance calculation, in NNNNNNNXNNNNNNNX format.

Required


EXITOP (GTX50)EXITOP specifies an exit routine that takes over processing just before GeoTAX writes an output sequential record. If the program does not write any output sequential files, or if none are activated, GeoTAX ignores EXITOP.

Field-by-Field

The following table describes each field of EXITOP.

29-31 Location for distance calculated

Location to store the 8-byte output distance calculated from your fixed LAT/LONG argument. GeoTAX stores distance calculations in eight bytes, with three decimal points understood.

Required

33 Storage disposition if no answer determinable

Location for the following codes if no answer is found.

B Store blanks. (default)

X Do not store anything.

GeoTAX indicates no answer determinable if it cannot find 2 latitude/longitude coordinates. GeoTAX attempted a distance calculation — the distance between two points — and could find only one latitude/longitude specification. If the two latitude/longitude coordinates are identical, GeoTAX stores 8 zeroes.

Required



1-6 KEYWORD Contains the parameter name: EXITOP. Required

7 Reserved For CODE-1 Plus users: You must specify a P in this column to invoke the file activator in positions 56 through 59 of this EXITOP parameter record.

8-17 GTX50 Name of the output exit routine to activate. This routine must be linked with the EXEC-level program and must be present in the library you specified.

Required

18-21 Location of input FIPS state code

Location of the 2-byte state code.

22-25 Location of input FIPS county code

Location of the 3-byte county code.

26-29 Location of input FIPS place code

Location of the 5-byte place code.

30-33 Location of input ZIP code

Location of the 5-byte ZIP code.

34-37 Location of input place name

Location of the 25-byte place name.

38-41 Location to post 9-byte GeoTAX key

Location to store the 9-byte GeoTAX key.

42-45 Location to post 1-byte GeoTAX return code

Location to store the 1-byte GeoTAX return code.

46 Reserved


FILEDFFILEDF identifies and describes your input and output files and tells GeoTAX how to handle each read and write operation.

GeoTAX generates the following names for the input/output FILEDF parameter records.

• GTBMNAM contains the input data file name.

• GTBMCOK contains the output coded OK records.

• GTBMPLC contains the output place-coded records (contains non-zero place codes).

• GTBMNCO contains the output non-coded records.

• GTBMARC contains the output records in a format readable by most mapping applications, such as ESRI’s ArcView.

• GTBMPRM contains all the parameter records for your job.

Note: Although GeoTAX defines its own names on the FILEDF record, you specify your file names in the job setup file. GeoTAX does not overwrite, delete, or rename your files.

47 Minimum coding level required to post data

Indicates the minimum codling level required to post data.





Space Defaults to N

48 Reserved

49 Blank or zero-filled for default match

Z Zero filled

B Blank space

Space Defaults to B

50 Reserved

51 Report suppression code

X Suppress report from printing

Space Print summary report

52 Reserved













Limiting Processing With FILEDF

There are three ways to limit input record processing:

• Skip a portion of the file before you start processing.

• Enter a cross-sectional sampling number to select a portion of the records, evenly spaced throughout the file.

• Specify a maximum number of records; in this case, GeoTAX starts at the beginning of the file and processes each record, one after another, until it reaches the maximum.

Note: Specify the number of records you want to process with the input FILEDF parameter record. If you limit processing on an output FILEDF parameter record, GeoTAX processes all of your input records, but limits the number of records written to the output file.

Cross-Sectional Sampling

Cross-sectional sampling provides you with a way to process a sample (percentage) of your total input file to get a preview of the entire input file. This ensures your sampling is evenly distributed throughout the file.

You must specify your sampling percentage number as a 7-byte, decimal figure. Use the following steps to determine this number:

1. Divide the number of records you want to process (for example, 2000) by the number of records in the file (in this case, 102986). The result is a decimal figure (.0194201153).

2. Drop the decimal point from this figure (0194201153).

3. Specify the first seven digits of this number in the input FILEDF parameter record (0194201).

Specifying FILEDF Exit Routines

You can specify and invoke two types of exit routines with the FILEDF parameter record.

• Input exit routineGeoTAX calls this routine each time it is ready to read a record from your input data file. Instead of immediately reading the input record, GeoTAX first calls your exit routine, then waits for the exit routine to pass back a record before it resumes normal processing.

• Output exit routineGeoTAX calls this routine each time it is ready to write a record to your output file. Before it writes the record to the output file, GeoTAX first passes the record to the output exit routine, then waits for the exit routine to complete processing and pass the record back to it for normal processing.

Your exit routine must contain four parameters in the linkage section at each I/O request.

• PARM1 contains two components:

– Bytes 1-8 contains the file name.


– Byte 9 contains one of the following codes that indicate the type of processing the routine performs:

• O - The routine opens the input or output file.

• R - The routine reads an input file record.

• W – The routine writes an output record.

• C – The routine closes the input or output file.

• PARM2 is an open/read indicator. This 5-digit parameter is packed into a 3-byte field (COBOL “PIC S9(5) COMP-3”). Your exit routine must initialize and increment this parameter if byte 9 of PARM1 is O or R. When byte 9 of PARM1 is R and the input exit routine reaches end-of-file, the routine sets this indicator to 0.

• PARM3 contains the output record that GeoTAX passes to the exit routine each time it encounters an R or a W in byte 9 of PARM1. The length of this parameter is specified by the exit routine in PARM2 (maximum of 32,760).

• PARM4 contains your 80-byte FILEDF parameter records.

Field-by-Field

The following table describes each field on the FILEDF parameter record.


1-6 KEYWORD Parameter name: FILEDF Required

8-15 Input or output file name Appropriate input or output file name.

GTBMNAM Input file

GTBMCOK Output file - coded OK records

GTBMPLC Output file - place-coded records

GTBMNCO Output file - non-coded records

GTBMARC Output file - as input to mapping application

GTBMPRM Input file - parameter records

Required - no default

17 User-specified record format

Indicates the format of the input records:

F Fixed-length, sequential (default)

L Fixed-length with an end-of-file

U Variable-length

NOTE: Options L and U are available for UNIX and Windows NT, only. Under UNIX and NT, variable means AcuCobol variable format file”. Output files can also be variable in these platforms.

Required

19-22 User-specified record length

Record length that you specified. Required for file GTBMARC

24-28 Record block size File block size you specified, in bytes. Optional


30-33 Device type The device type that contains the input or output file. Enter one of the following:

TAPE 2311 2314 3310 3300

3340 3350 3370 3375 3380

FBA

34 Tape handling Indicates how to handle media.

blank Rewind tape at open or close operations. If non-labeled tapes are detected, this field is changed to a U.

U Rewind tape at open operations, and unload at close operations.

X Do not reposition tapes at open or close operations.

M More than one standard label file; query the operator for EOF/EOV at the end of each input file.

In general, use blank for intermediate references to a single-tape file; use U for multi-tape files; use X for files that require non standard tape positioning (can be accomplished via MTC commands or equivalent).

35 LABEL TYPE Indicates if the records on the file have standard or omitted labels:

S Standard labels

N No labels.

37-49 Delimiter information By default, fields posted in GTBMARC output file are comma delimited. However you can use positions 37-49 to define additional delimiters such as double quotes.

NOTE: If position 37 contains either a C or X, the value for the exit routine name (positions 39-48) is ignored in order to process delimiter information. Delimited file support only works for output file GTBMARC.

Optional

37 First delimiter format Format of the first delimiter:

C Delimiter is in character format, contained in position 39.

X Delimiter is in hexadecimal format, contained in positions 39-40.

Optional

39-40 First delimiter Character or hexadecimal value identified as a delimiter when writing output fields to output file GTBMARC.

Optional

42 Second delimiter format Format of the second delimiter:


X Delimiter is in hexadecimal format, contained in positions 44-45.

Optional

44-45 Second delimiter Character or hexadecimal value identified as a delimiter when writing output fields to output file GTBMARC.

Optional

47 Third delimiter format Format of the third delimiter:


Optional



Example

In the first example, the input file is called GTBMNAM, it is fixed-length format, has a record length of 2000, and has a block size of 2000. Each time GeoTAX is ready to read a record from GTBMNAM, it instead calls the exit routine EXITPGM. When EXITPGM is finished and normal processing resumes, GeoTAX skips the first 5000 records in the input file, cross-sectionally samples 250,000 records, but processes no more than 200,000 records total.

In the second example, GTBMCOK is the output file and has a fixed-length format, a record length of 397, and a block size of 397.

In the third example, GTBMARC as an additional output file with a fixed-length format, a record length of 256, and a block size of 256. The C in position 37 of this parameter indicates a character-format delimiter in file GTBMARC with the double-quote character (“) delimiter specified in position 39. Thus, when GeoTAX writes output record fields to GTBMARC, they ware delimited by double-quotes.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890FILEDF GTBMNAM F 2000 02000 EXITPGM 0005000 2500000 0200000FILEDF GTBMCOK F 0397 00397FILEDF GTBMARC F 0256 00256 C ”

Note: By default, fields posted in GTBMARC are comma-delimited.

49 Third delimiter Character identified as a delimiter when writing output fields to output file GTBMARC.

Optional

39-46 Input or output exit routine name

Name of the input exit routine called when GeoTAX is ready to read a record from this file; or the name of the output exit routine called when GeoTAX is ready to write a record to the file.

NOTE: If position 37 contains either a C or an X, the value for the Exit Routine name (positions 39-46) is ignored in order to process delimiter information.

Optional - No default; Name must be left-justified

50-56 Number of records to skip before processing

Number of records GeoTAX skips before selecting the first record.

Optional - No default

58-64 Number of Records for cross-sectional sampling

Percentage number of records to process. GeoTAX assumes a decimal point before the first digit.


66-72 Maximum number of records to process

Maximum number of records GeoTAX reads from or writes to this file.


74 Overwrite/extend indicator

Contains the disposition you specified:

E Write new data after the old data ends.

Blank Overwrite old file data.

Required



FIRMNMFIRMNM defines the location and length of the firm name in the input record, as well as the location and length for the standardized firm name on the output record.

Field-by-Field

The following table describes each field in FIRMNM.

Example

In the following example, GeoTAX references data in the input record and posts data in the output record as follows:

• Position 51 is the starting location for the 40-byte Firm Name on the input record

• Position 92 is the starting location for the 40-byte standardized Firm Name on the output record

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890FIRMNM 051 40 092 40


1-6 KEYWORD Parameter name: FIRMNM Required

8-10 Location of input firm name

Location on input record for firm name. Optional

12-13 Length of input firm name

Length of firm name on input record. Optional

15-17 Location of output standardized firm name

Location on output record for standardized firm name.

Optional

19-20 Length of output standardized firm name

Length of standardized firm name on output record.

Optional


GEOOUT GEOOUT posts geographic codes to your name-and-address records.

Field-by-Field

The following table describes each field of GEOOUT.


1-6 KEYWORD Parameter name: GEOOUT Required

NOTE: You must specify at least one of the fields from positions 8 to 38, or this parameter record is invalid.

8-10 Location of General Return Code

See “General Return Codes” on page 227 for return values.

Optional

12-14 Output Location for complete geocode

Output location for the complete 12-byte Geocode. Stores this code string in the output file:

2-byte State code

3-byte County Code

6-byte Census Tract Code

1-byte Block Group Code.

Optional

16-18 Location of output FIPS state code

Location to store the 2-byte FIPS state code. Optional

20-22 Location of output FIPS county code

Location to store the 3-byte FIPS county code.

Optional

24-26 Location of output census tract

Location to store the 6-byte census tract. Optional

28-30 Location of output block group

Location to store the 1-byte block group. Optional

32-34 Location of output state abbreviation

Location to store the 2-byte USPS state abbreviation.

Optional

36-38 Location of Output county name

Location to store the 20-byte county name. Optional

40 Storage Disposition of records with incomplete information

Storage option specified for records with missing information.

Z Store zeroes in state, county, and census tract, and store a space in block group. (Default)

B Store blanks in all fields.


Optional

42 Minimum geocode level allowed

Minimum geocoding level specified for posting geocode components.

S State code Required

C State/county code Required

T State/county and census tract codes Required

B State/county, census tract, and block group codes Required

blank No minimum specified.

Optional


44 Minimum match level allowed

Minimum match level specified for posting geocode components.

P Point level must be achieved.

S Street Address level must be achieved (General Return code = S).

9 ZIP+4 level or Street Address level must be achieved (General Return Code = S or 9).

5 ZIP Code, ZIP+4, or Street Address levels must be achieved (General Return code = S, 9 or 5).

F Fallback level or better must be achieved.

blank No minimum specified.

Optional

46 Storage Disposition of records below minimum coding levels

Indicates how GeoTAX to handle records failing to achieve minimum geocoding and postal coding levels.

R Reject record and send to uncoded records file, GTPBMNCO.

blank Performs same action as no answer found.

Optional

48-50 Location of output street matcher return code

Location to store the 1-byte street matcher return code.

Z ZIP Code not found

S Street within ZIP Code not found

H House number on street not found

L Lat/Long not determined on the GeoTAX Auxiliary file, the User Auxiliary file, or the state-supplied file.

blank Successful street match.

Optional

52-54 Location to store 15-byte Extended Geocode

Location on output record for Extended Geocode:

2-byte State

3-byte County

6-byte Census Tract

1-byte Census Block Group

3-byte Census Block ID

Optional



General Return Codes

The output General Return Code is based in part on the input indicator that you set for the minimum match level required to post the latitude/longitude coordinates. The minimum level input indicator is set in field 44 of GEOOUT. The following table shows the possible return codes (indicated by an ‘X’ in the column) for the specified minimum input level.

56-58 Location to store 3-byte Census Block ID

Location on output record for Census Block ID

Optional

60-62 Location to store 2-byte Data Type indicator

Location on output record to store the 2-byte indicator which provides the file from which the match was obtained:

0 USPS

1 TIGER

2 TomTom Street

6 NAVTEQ Street

7 TomTom Point

8 Centrus Point

11 NAVTEQ Point






Optional


General Return Code Description

Minimum match level allowed (field 44 in GEOOUT)

F -

Fallback or better

5 -

ZIP Code, ZIP+4 or

Street Address

level

9 -

ZIP+4 or Street

Address level

S -

Street Address

level

P -

Point level

P Address Point match X X X X X

O Input latitude/longitude coordinates match

X X X X X


X X X X X

A User Auxiliary file match X X X X X

U GeoTAX Auxiliary file match X X X X X

I Intersection match X X X X

S Street address match X X X X

G State-supplied file match X X X X

9 ZIP+4 Code match X X X

5 ZIP Code match X X


Note: GeoTAX attempts matches to files in the following order: Landmark Auxiliary file, User Auxiliary file, state-supplied file, GeoTAX Auxiliary file, Point, then Streets file.

Example

In the following example, GeoTAX returns:

• General Return Code in position 52.

• Complete 12-byte Geocode to start in position 54.

• 2-byte FIPS State Code to start in position 67.

• 3-byte FIPS County Code to start in position 70.

• 6-byte Census Tract to start in position 74.

• 1-byte Census Block Group in position 81.

• 2-byte State Abbreviation to start in position 83.

• 20-byte County Name to start in position 85.

• Blanks for records with missing information.

• At the minimum, State/County and Census Tract codes are required in order to post any Geocoding information (option T).

• Street Address-level matching must be achieved in order to post any geocoding information (option S).

• Records that fail to achieve the minimum matching requirements (in this case, street address-level matching) are posted to the not coded records file, GTBMNCO (option R).

• Store the Street matcher return code in position 106.

• Store the Data Type indicator in position 108.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890GEOOUT 052 054 067 070 074 081 083 085 B T S R 106 108

C Street Centroid match X

F Fallback Geographic match X



Blank Did not match


Minimum match level allowed (field 44 in GEOOUT)

F -

Fallback or better

5 -

ZIP Code, ZIP+4 or

Street Address

level

9 -

ZIP+4 or Street

Address level

S -

Street Address

level

P -

Point level


HEADER HEADER contains the text and text alignment for report headings. You can also limit the ZIP/Postal Codes you wish to be processed with the HEADER parameter record.

GeoTAX bypasses any ZIP/Postal Code that is lower than the one you define in positions 60-65. As soon as GeoTAX encounters a ZIP/Postal Code higher than the one you define in positions 67-72, it stops processing. This is why we strongly suggest that you sort your input file in ZIP Code or Postal Code sequence (ascending order).

Field-by-Field

The following table describes HEADER.

Example

In the following example, GeoTAX starts processing at ZIP Code 20706 and stops at ZIP Code 85254. It also specifies the content of the report header.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890HEADER 12/14/2013 Pitney Bowes Software 20706 85254


1-6 KEYWORD Parameter name: HEADER Required.

8-17 Date for allReports

Date you want to print on all reports, in mm/dd/yyyy format. Dates are not validated by GeoTAX.

Optional. Default is to print the system date.

19-58 Heading for all Reports

Text you want to print at the top line of the first page of each report.

Optional.No default.

60-65 Low Postal Code The lowest ZIP/Postal Code GeoTAX should process. If you specify a low postal code you must also specify a high postal code.


67-72 High Postal Code The highest ZIP/Postal Code GeoTAX should process. This must exceed the low postal code.



IPDOUT The optional IPDOUT parameter record provides you with a way to specify the posting of Insurance Premium Tax District (IPD) data to your output records to enhance tax jurisdiction assignment. IPD data includes the IPD ID, IPD Name, IPD Type, and IPD Dates. You must have licensed and installed the IPD data file for this parameter to function. This parameter can occur up to ten times (once for each possible district returned). The confidence code for each district is appended.

Field-by-Field

The following table describes each field of IPDOUT.

Example

In the following example, GeoTAX returns the following:

• Number of IPDs starting in position 201

• First IPD ID starting in position 203

• First IPD Name starting in position 215

• First IPD Type starting in position 256

• First IPD Dates starting in position 263

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890IPDOUT 201 203 215 256 263


1-6 KEYWORD Parameter name: IPDOUT Required.

8-10 Output location for 2-byte number of IPDs

Location on the output record where the specified data is posted.


12-14 Output location for 10-byte first IPD ID



16-18 Output location for 40-byte first IPD name



20-22 Output location for 6-byte first IPD type



24-26 Output location for 14-byte first IPD date

Location on the output record where the specified data is posted. Returns the update date followed by the effective date.


28-30 Output location for 3-byte IPD Confidence Code

Output number is percentage confidence.

Optional.


IPROUTThe optional IPROUT parameter record provides you with a way to specify the posting of additional Insurance Premium Tax District (IPD) data to your output records to enhance tax jurisdiction assignment. Data posted with this parameter includes Notes for the state of KY, additional dates, and rates for various types of insurance. You must have licensed and installed the IPD data file for this parameter to function. You can define up to 10 IPROUT cards.

Field-by-Field

The following table describes each field of IPROUT


1-6 KEYWORD Parameter name: IPROUT Required

8-10 Output location for 20-byte IPD Notes field.

Location on the output record where the specified data is posted

Optional

12-14 Output location for 6-byte Change Date.


Optional

16-18 Output location for 6-byte New Effective Date.


Optional

20-22 Output location for 6-byte Expiration Date.


Optional

24-26 Output location for 6-byte Fire Rate and Flag:

• 1st 5-bytes is rate

• 6th byte is flag (P, F, M)

Location on the output record where the specified data is posted:

Flag Rate Format

P Percentage: .1 = 10%, .0575 = 5.75%


M Multiple Percentages has a semi colon as a delimiter: 3;7 = "3% or 7%".

Optional

28-30 Output location for 6-byte Casualty Rate and Flag:




Flag Rate Format

P Percentage: .1 = 10%, .0575 = 5.75%



Optional


32-34 Output location for 6-byte Vehicle Rate and Flag:




Flag Rate Format

P Percentage: .1 = 10%, .0575 = 5.75%



Optional

36-38 Output location for 6-byte Marine Rate and Flag:




Flag Rate Format

P Percentage: .1 = 10%, .0575 = 5.75%



Optional

40-42 Output location for 6-byte Health Rate and Flag:




Flag Rate Format

P Percentage: .1 = 10%, .0575 = 5.75%



Optional

44-46 Output location for 6-byte Life Rate and Flag:



Location on the output Location on the output record where the specified data is posted:

Flag Rate Format

P Percentage: .1 = 10%, .0575 = 5.75%



Optional



Example

In this example, GeoTAX posts to the output records:

• 20-byte IPD Notes in position 185

• 6-byte Change Data in position 206

• 6-byte New Effective Data in position 213

• 6-byte Expiration Date in position 220

• 6-byte Fire Rate and Flag in position 227

• 6-byte Casualty Rate and Flag in position 234

• 6-byte Vehicle Rate and Flag in position 241

• 6-byte Marine Rate and Flag in position 248

• 6-byte Health Rate and Flag in position 255

• 6-byte Life Rate and Flag in position 262

• 6-byte Other Rate and Flag in position 269

• 6-byte Minimum Rate and Flag in position 276

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890IPROUT 185 206 213 220 227 234 241 248 255 262 269 276

48-50 Output location for 6-byte Other Rate and Flag:




Flag Rate Format

P Percentage: .1 = 10%, .0575 = 5.75%



Optional

52-54 Output location for 6-byte Minimum Rate and Flag:




Flag Rate Format

P Percentage: .1 = 10%, .0575 = 5.75%



Optional



LATLONThe optional LATLON parameter record allows latitude/longitude coordinates to be used as inputs for matching.


• Latitude - 00.000000 or without the decimal point 00000000

• Longitude - 000.000000 or without the decimal point 000000000 or 00.000000 or without the decimal point 00000000

For more information, see “Using Latitude/Longitude coordinates as input” on page 66.

Field-by-Field

The following table describes each field of LATLON.

Example

In the following example, the input record contains:

• Latitude location at position 51

• Length of Latitude is 11 bytes

• Longitude location at position 63

• Length of Longitude is 11 bytes

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890LATLON 051 11 063 11


1-6 KEYWORD Parameter name: LATLON Required

8-10 Location of input Latitude Location on input record for Latitude. Optional

12-13 Length of input Latitude Length of Latitude on input record. Optional

15-17 Location of input Longitude Location on input record for Longitude. Optional

19-20 Length of input Longitude Length of Longitude on input record. Optional


LLOUT LLOUT posts latitude/longitude information to your name-and-address records. It also allows you to set address matching levels and their respective details. For example, if GeoTAX does not find a street-level match using the Street Address database for an input record, you can tell GeoTAX to try a ZIP+4 match using the Postal database.

You can also use LLOUT to format your output for an easy import into a mapping application, such as ESRI’S ArcView. To do this, you need to put a ‘C’ in position 30 of LLOUT. Format option C is optimal for certain geographic mapping programs.

LLOUT also allows you to specify the level of offset you want GeoTAX to use when calculating latitude/longitude coordinates. You can specify 0, 20, 40, or 60 feet offset from the center line of the street in position 32 of LLOUT. The default value is 40 feet.

Field-by-Field

The following table describes each field of LLOUT.


1-6 KEYWORD Parameter name: LLOUT Required

8-10 Location to store 1-byte latitude/longitude level

Storage location for the output latitude/longitude level return code.

See “Latitude/Longitude Level Return Codes” on page 236 for return values.

Optional

12-14 Location to store 16-byte latitude/longitude

Location on the output record for the latitude/longitude results.

NOTE: Must define either these fields, or fields 8-10, or fields 24-26.

Optional

16 Code Indicating source of latitude/longitude

Unused

18 Indicator for minimum level to post latitude/longitude

Minimum level to post latitude/longitude:

Z ZIP Code level

T Tract level

B Block group level

2 ZIP+2 level Centroid

4 ZIP+4 level Centroid

R Address level

P Point level

Blank No minimum

Optional

20 Storage if no answer determinable

Storage option for records with no answer:

Z “0000000 0000000” (default)

B All blanks

X Do not store anything

NOTE: GeoTAX indicates no answer determinable if it cannot find two coordinates.

Optional


Latitude/Longitude Level Return Codes

Latitude/Longitude General Return Codes

The output latitude/longitude return code is based in part on the input indicator that you set for the minimum level required to post the latitude/longitude coordinates. The minimum level input indicator is set in field 18 of LLOUT. The following table shows the possible return codes (indicated by an ‘X’ in the column) for the specified minimum input level.

For example, if you set a minimum level of Address level (R), then the return code would be one of the following:

22 Disposition of records below minimum latitude/longitude coding level

Contains one of the following:

R Output to uncoded file GTBMNCO

blank Perform same action as no answer found.

Optional

24-26 Location to store 18 to 22-byte latitude/longitude

Output location for the alternate (18- to 22-byte) latitude/longitude results (calculates to 6 decimal places). The length posted is determined by the format selected in column 30.

NOTE: Must define either these fields, or fields 8-10, or fields 12-14.

Optional

28 ZIP Code level match centroid determination

Unused.

30 Alternate latitude/longitude format code

Indicates the format of the long alternate latitude/longitude to be posted:

A 090000000N180000000W (default)

B 090.000000N180.000000W

C 90.000000-180.000000

D 90000000-180000000

blank Default is A.

Any other value causes a parameter record error.

Optional

32 Latitude/longitude offset amount

Specify one of the following codes for the number of feet a lat/long should be offset to the correct side of the street when a Street-level match is achieved:

A Zero feet offset

B 20 feet offset

C 40 feet offset (default)

D 60 feet offset

blank Default is C

Any other value will cause a parameter record error.

Optional

34 Latitude/longitude squeeze

Specifies if the lat/long should be squeezed from the street end point:

Y Default. Apply squeeze

N Do not apply squeeze

Optional

36-38 Location to store4-byte Lat/Long Location Code

Location on output record for Lat/Long Location Code. (For values, see “Location codes” on page 265).

Optional



• P + Point-level Latitude/Longitude Return Code (see table for values in following section),

• U - GeoTAX Auxiliary,

• L - Landmark Auxiliary,

• O - Latitude/longitude was input,

• R - Street, or

• I - Intersection

All other values are not applicable to an Address level match and would not be returned.

If “Point” is set as a minimum level, then refer to “Point-Level Latitude/Longitude Return Codes” on page 238.

Latitude/Longitude


Minimum level to post latitude/longitude (field 18 of LLOUT)

Z -

ZIP Code

T -

Tract level

2 -

ZIP+2 level

centroid

B -

Block group level

4 -

ZIP+4 level

centroid

R -

Address level

P -

Point level

See table in next section for 2nd digit decoding.

Point X X X X X X X

U GeoTAX Auxiliary

X X X X X X X

L Landmark Auxiliary

X X X X X X X

O Latitude/longitude was input

X X X X X X X

R Street address X X X X X X

I Intersection X X X X X X


X X X X X

B Block Group X X X X


X X X

T Census Tract X X

Z ZIP Code X

C City Centroid

S State Centroid


Point-Level Latitude/Longitude Return Codes

If the General Return Code (see GEOOUT on page 225) is “P” (point match), then the following values apply to the 2nd digit of the Lat/Long Level and indicate the source of the Point latitude/longitude coordinates:

Example

In the following example, GeoTAX will:

• Store the latitude/longitude matching level in position 73

• Store the 16-byte latitude/longitude beginning in position 75

• If no answer is determined using either the Street-level or the Base file, store nothing (X)

• Write output records below the minimum coding level to the uncoded file GTBMNCO (R)

• Store the alternate latitude/longitude in position 93 using format (A)

• When a street-level match occurs, offset the resulting latitude/longitude to the correct side of the street by 20 feet (B)

• Store the 4-byte Latitude/Longitude Location Code in position 110

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890LLOUT 073 075 2 X R 093 A B 110

Point-Level Return Codes Description














MCDOUT MCDOUT posts the 5-byte Minor Civil Division (MCD) or Census County Division (CCD) codes to your records.

Field-by-Field

The following table describes each field of MCDOUT.

Example


• Post the MCD/CCD code starting in position 148.

• Not store anything if no there is no answer.

• Put the MCD/CCD name starting in position 155.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890MCDOUT 148 X 155

MOVE IThe optional MOVE I parameter record provides you with a way to rearrange the pieces of the input record before the record is processed.

This feature enables you to rearrange the components of your input records before any other GeoTAX processing takes place. The information you identify is copied, but not removed, from its original location in the input record. This feature is useful for saving data that might otherwise be overwritten by data returned from GeoTAX. You can define a maximum of 100 MOVE I parameters for a job. They are processed one at a time, in sequence from top to bottom.


1-6 KEYWORD Parameter name: MCDOUT Required

8-10 5-byte MCD/CCD code output location

MCD/CCD code output location.

NOTE: Must define either this field or the MCD/CCD name location.

Optional

12 Storage if no answer determinable

Store the following if no answer:

Z Store zeroes. (default)

B Store blanks.


Optional

14 40-byte MCD/CCD name output location

MCD/CCD name.

NOTE: Must define either this field or the MCD/CCD code location.

Optional


Before GeoTAX does any processing, it first copies the entire input record into an input record array. If you specify any MOVE I operations, GeoTAX copies the entire record into a temporary work area. It then takes data from a specified position in the work area, and puts it in a specified position in the input record array. Once GeoTAX executes all of the MOVE I operations, it clears the work area and processes the record as it now appears in the input record array.

For example, use an input record with the following structure:

AAAAABBBBBCCCCC

If the information in positions 11-15 (CCCCC) is moved to positions 1-5, GeoTAX copies the record to the work area, and executes the move operation. When the operation is complete, the input record array and work area appear as follows:

Input Record ArrayWork Area

CCCCCBBBBBCCCCCAAAAABBBBBCCCCC

If the information from positions 1-5 is moved to positions 11-15, the input record array and work area appear as follows:

Input Record ArrayWork Area

CCCCCBBBBBAAAAAAAAAABBBBBCCCCC

Note: This feature does not alter your input name-and-address file.

Field-by-Field

The following table describes each field of MOVE I.


1-6 KEYWORD Parameter name: MOVE I Required.

8-10 Location of source Location in the work area of the information to copy. Optionally, you can enter one of the following codes to copy generic information to the target location:

SPC Spaces.

X00 Binary zeros.

ZRO Character zeros.

Cxx Move a constant defined with a CONSxx parameter.

Required.No default.

12-13 Length of source/target

Length of the information to copy to the target location.


15-17 Location of target Location in the input array to copy the source information.



Example

In the following example, GeoTAX copies the information that starts in position 41 in the work area and is 10 bytes, and moves it to positions 1-10 (to start in position 1) in the input record array.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890MOVE I 041 10 001

MOVE O The optional MOVE O parameter record provides you with a way to rearrange pieces of the output record before the record is written to the output file.

GeoTAX processes the record and copies it to an output record array. Then, GeoTAX copies the entire record to a temporary work area (if requested), and copies data from a specific location in the work area back to a specific location in the output record array. GeoTAX then writes the information directly to your output file (or passed to an output exit routine). You can define a maximum of 100 MOVE O parameters for a job. They are processed one at a time, in sequence from top to bottom.

Field-by-Field

The following table describes each field of MOVE O.

Example

In the following example, GeoTAX moves 10 bytes of information, starting at position 480 in the work area, to the output record (O) starting at position 1.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890MOVE O 480 10 001


1-6 KEYWORD Parameter name: MOVE O Required

8-10 Location of source Location in the work area of the copied information. Optionally, you can enter one of the following codes to copy generic information to the target location.

SPC Spaces.

X00 Binary zeros.

ZRO Character zeros.

Cxx Move a constant defined with a CONSxx parameter.


12-13 Length of source/target

Length of the information to copy to the target location.


15-17 Location of target Location in the output record to copy the source information.



PAGESZ PAGESZ specifies the number of lines to print on each page of the GeoTAX reports.

Field-by-Field

The following table describes each field of PAGESZ.

Example

In the following example, GeoTAX prints 66 lines per page on the parameter record listing (RPT) and on the execution log (XLG).

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890PAGESZ 066 RPTPAGESZ 066 XLG


1-6 KEYWORD Parameter name: PAGESZ. Required

8-10 Number of lines printed per page

Number of lines you specified to print on each page of the Execution Log or the other reports.

Optional

12-14 Execution log parameter list

Indicates if the specification in positions 8-10 applies to the execution log or parameter record listing.

RPT Parameter record listing

XLG Execution log

Required


PAYOUTThe optional PAYOUT parameter record provides you with a way to specify the posting of Payroll Tax District (PAY) data to your output records to enhance tax jurisdiction assignment. PAY data includes PAY ID, PAY District ID, PAY Type, PAY Name, PAY Municipal Income Tax Flag, PAY Municipal EMS Tax Flag, PAY School District Income Tax Flag, and PAY Update Date. The confidence code is optionally posted. You must have licensed and installed the PAY data file for this parameter to function. You can define up to ten PAYOUT parameter cards.

Field-by-Field

The following table describes each field of PAYOUT.


1-6 KEYWORD Parameter name: PAYOUT Required

8-10 Output location for 2-byte number of PAYs


Optional

12-14 Output location for 5-byte PAY ID


Optional

16-18 Output location for 5-byte PAY District ID


Optional

20-22 Output location for 3-byte PAY Type


Optional

24-26 Output location for 60-byte PAY Name


Optional

28-30 Output location for 1-byte PAY Municipal Income Tax Flag


For Pennsylvania:

R Resident

N Non-resident

B Both

X None

All other states are blank.

Optional

32-34 Output location for 1-byte PAY Municipal EMS Tax Flag


For Pennsylvania:

Y Levies the tax

N Does not levy the tax


Optional


Example

In the following example, GeoTAX posts:

• The number of PAYs starting in position 110.

• Up to all 10 possible PAY district IDs available, followed by the school district income tax and EMS tax flags for that district starting in position 120 and running contiguously.

• The name of the PAY for the first and second occurrence in positions 190 and 250.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890PAYOUT 120 190 125 126PAYOUT 127 250 132 133PAYOUT 134 139 140PAYOUT 141 146 147PAYOUT 148 153 154PAYOUT 155 160 161PAYOUT 162 167 168PAYOUT 169 174 175PAYOUT 176 181 182PAYOUT 110 183 188 189

36-38 Output location for 1-byte PAY School District Income Tax Flag


For Pennsylvania:

R Resident

N Non-resident

B Both

X None

For Ohio:

R Resident

X None


Optional

40-42 Output location for 1-byte PAY School District EMS Tax Flag


For Pennsylvania:

Y Levies the tax

N Does not levy the tax


Optional

44-46 Output location for 7-byte PAY Update Date


Optional

48-50 Output location for 3-byte PAY Confidence Code


Optional



PCOUT PCOUT posts Place Codes and names to your name-and-address records.

Class Codes and Place Class Codes

Pitney Bowes Software uses data provided by the U.S. Department of Commerce to associate a Class Code (entity type) with a Place Code and Place Name. This provides you with a way to identify tax rates that apply to particular states, counties, and municipalities. The class code consists of two characters: an upper-case letter and a single numerical digit.

Field-by-Field

The following table describes each field of PCOUT.


1-6 KEYWORD Parameter name: PCOUT. Required

8-10 Location to store Place Code

Location to store the 5-byte Place Code.

NOTE: Must define these fields or fields 12-14

Optional

12-14 Location to store Place Code Name

Output location of 40-byte Place Code Name.

NOTE: Must define these fields or fields 8-10.

Optional

16 Storage in no answer determinable

Indicates what to store if no answer:

Z Zeroes in Place Code field, and blanks in Name field. (default)

B Blanks in both Place Code and Name fields.


Optional

17 Class Code position digit Reserved for the optional Class Code position digit.

Optional

18-20 Location to store 2-byte Class Code

Output location to store one of the following two-character codes to identify an incorporated or unincorporated Place:

C1 through C9Incorporated places.

all other codesUnincorporated places.

blank Not found in the U.S. Department of Commerce FIPS 55 place code roster.

Optional

22-24 Location to store 1-byte incorporation flag

Identifies if a place code indicates an incorporated place or unincorporated place.

0 Unincorporated place.

1 Incorporated place.

blank Not found in the U.S. Department of Commerce FIPS 55 place code roster.

Optional


26-28 Posting location for last annexed date

Location of the date. This date is in MM/YYYY format.

Optional

30-32 Posting location for last updated date

Location of date. This date is in MM/YYYY format.

Optional

34-36 Posting location for last verified date

Location of date. This date is in MM/YYYY format.

Optional

42-44 Location to post9-byte GeoTAX key

Location of the 9-byte GeoTAX key. (This key can be from Vertex or Taxware matching.)

Optional

46-48 Location to post1-byte GeoTAX Key match attempt return code

Location of 1-byte GeoTAX Key match attempt return code. The code consists of one of the following:





Blank No matching GeoTAX record found

Optional

50 Minimum GeoTAX level required to post GeoTAX information

Indicates the minimum match level required to post GeoTAX information:





Space Defaults to N

52 Default type matching Indicates the fill form for default matching:

Z Zero-filled

B Blank

Space Defaults to B

54 Return default match if unincorporated

Indicates what GeoTAX returns for an unincorporated place:

Y Reduce GeoTAX match to default level if an unincorporated place is returned.

N Do not alter GeoTAX key.

Space Defaults to N.

56 GeoTAX key to return Indicates the GeoTAX key to return:






Blank is default

58-60 Location of GNIS code Location to store the 9-byte GNIS code. Optional



Example


• Store the place code beginning in position 154.

• Store the place name beginning in position 160.

• If there is no answer for place code, store blanks (B).

• Store the class code beginning in position 123.

• Store the incorporation flag in position 128.

• Store the last annexed date, last updated date, and last verified date in positions 200, 230, and 240, respectively.

• Store the GeoTAX key beginning in position 301 and its match attempt return code in position 300.

• A partial match (or better) is required in order to post the GeoTAX key (P); use zero-filled for default type matching (Z).

• If the place is unincorporated, reduce the GeoTAX key to the default level (Y).

• Return the GeoTAX key from Taxware (not Vertex) file (T).

• Store the GNIS code beginning in position 310.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890PCOUT 154 160 B 123 128 200 230 240 301 300 P Z Y T 310

PTCOUT The optional PTCOUT parameter record provides you with a way to specify the posting of Payroll Tax Correspondence (PTC) data to your output records to enhance tax jurisdiction assignment. You must have licensed and installed the PTC file for this parameter to function. GeoTAX has return areas for up to six PTCs.

Field-by-Field

The following table describes each field on the PTCOUT parameter record.


1-6 KEYWORD Parameter name: PTCOUT Required

8-10 PTC return codes Indicates the highest hierarchy level for which a match was found.

F FIPS County code

G GNIS Code

P District ID

S FIPS State code

Optional

12-14 Number of PTC codes found

Number of PTC codes found, and is a value of 0-6.

Optional

16-18 State abbreviation and county name

State (2-byte) and county (30-bytes). Optional


Example

In this example, GeoTAX will:

• Post the PTC Return Code in position 244.

• Post the number of PTC codes found in position 245.

• Post the first, 15-byte, payroll code in position 247.

• Post the first, 40-byte, payroll description in position 337.

• Post the second, 15-byte, payroll code in position 262.

• Post the second, 40-byte, payroll description in position 377.

• Post the third, 15-byte, payroll code in position 277.

• Post the fourth, 15-byte, payroll code in position 292.

• Post the fifth, 15-byte, payroll code in position 307.

• Post the sixth, 15-byte, payroll code in position 322.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890PTCOUT 244 245 247 337 262 377 277 292 307 322

20-22 Payroll code 1 First, 15-byte, payroll code. Optional

24-26 Payroll code 1 description First, 40-byte, payroll description. Optional

28-30 Payroll code 2 Second, 15-byte, payroll code. Optional

32-34 Payroll code 2 description Second, 40-byte, payroll description. Optional

36-38 Payroll code 3 Third, 15-byte, payroll code. Optional

40-42 Payroll code 3 description Third, 40-byte, payroll description. Optional

44-46 Payroll code 4 Fourth, 15-byte, payroll code. Optional

48-50 Payroll code 4 description Fourth, 40-byte, payroll description. Optional

52-54 Payroll code 5 Fifth, 15-byte, payroll code. Optional

56-58 Payroll code 5 description Fifth, 40-byte, payroll description. Optional

60-62 Payroll code 6 Sixth, 15-byte, payroll code. Optional

64-66 Payroll code 6 description Sixth, 40-byte, payroll description. Optional

68-70 Payroll code flags 6-byte payroll flags. Optional



PTDOUTThe optional PTDOUT parameter record provides you with a way to specify the posting of Property Tax District (PTD) data to your output records to enhance tax jurisdiction assignment. PTD data includes the PTD ID, PTD Jurisdiction ID, PTD Type, PTD Name, and PTD Update Date. The confidence code for each district is optionally posted. You must have licensed and installed the PTD data file for this parameter to function. This parameter can occur up to ten times (once for each possible district returned).

Field-by-Field

The following table describes each field of PTDOUT.

Example

Using the following example, GeoTAX returns:

• The number of PTDs starting in position 400.

• The first 5 PTD IDs with the first one starting in position 405 and the last in position 425.

• The first 5 PTD Types with the first one in position 426 and the last in position 430.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890PTDOUT 400 405 426PTDOUT 410 427PTDOUT 415 428PTDOUT 420 429PTDOUT 425 430


1-6 KEYWORD Parameter name: PTDOUT. Required

8-10 Output location for 2-byte number of PTDs


Optional

12-14 Output location for first5-byte PTD ID


Optional

16-18 Output location for first 10-byte PTD Jurisdiction ID


Optional

20-22 Output location for first1-byte PTD Type


R Reporting district

B Billing district

X Reporting and Billing

Optional

24-26 Output location for first 60-byte PTD Name


Optional

28-30 Output location for first 7-byte Update Date


Optional

32-34 Output location for 3-byte PTD Confidence Code


Optional


REPORTThe optional REPORT parameter specifies which reports to print at the end of your batch job. You can print any of the following reports:

• Coding Percentages per State/County

• Coding Percentages per State

• Jurisdictional Accuracy Management System (JAMS).

The default is to print the first two reports.

The JAMS report presents the results of running state-supplied address list data through GeoTAX. Retailers using JAMS can use the report results to submit to the state as part of the certification process.

Field-by-Field

The following table describes each field of REPORT.

Example

In the following example, GeoTAX prints the state/county report (default is Yes), but not the state report, along with the JAMS report from Virginia.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890REPORT Y N VA


1-6 KEYWORD Parameter name: REPORT. Required

8 Coding percentages per state/county

Indicates if GeoTAX prints the coding percentages per state/county report:

Y Print the report. (default)

N Do not print the report.

Optional

10 Coding percentages per state

Indicates if GeoTAX prints the coding percentages per state report:

Y Print the report. (default)

N Do not print the report.

Optional

12-13 State supplying JAMS input data

Enter the two-character abbreviation (AL, AK, etc.) of the state supplying the JAMS input data.

Optional


SPDOUT The optional SPDOUT parameter record provides you with a way to specify the posting of Special Purpose Tax District (SPD) data to your output records to enhance tax jurisdiction assignment. SPD data includes the SPD Code, SPD Name, and SPD Dates. The confidence code is optionally posted. You must have licensed and installed the SPD data file for this parameter to function. You can define up to ten SPD cards.

Field-by-Field

The following table describes each field on the SPDOUT parameter record.

1) The format of the returned tax rate field is a 10-character decimal value, for example, 0.08250000 which represents a tax rate of 8.25%.

Example


• The total number of SPDs starting in position 198

• The first 3-byte SPD Code starting in position 201

• The first 5-byte SPD Number starting in position 205

• The first 40-byte SPD Name starting in position 211

• The first 28-byte SPD Dates starting in position 252


1-6 KEYWORD Parameter name: SPDOUT Required

8-10 Output location for 2-byte number of SPDs


Optional

12-14 Output location for first 3-byte SPD Code


Optional

16-18 Output location for first 5-byte SPD Number


Optional

20-22 Output location for first 40-byte SPD Name


Optional

24-26 Output location for first 28-byte SPD Dates


Optional

28-30 Output location for 10-byte SPD State Supplied Special District ID.


Optional

32-34 Output location for 3-byte SPD Confidence Code


Optional

36-38 Output location for10-byte SPD Sales Tax Rate

Location on the output record for the 10-byte SPD Sales Tax Rate.1

Optional

40-42 Output location for10-byte SPD Use Tax Rate

Location on the output record for the 10-byte SPD Use Tax Rate.1

Optional


• The first 10-byte SPD State ID starting in position 281

• The first 3-byte SPD Confidence Code starting in position 292

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890SPDOUT 198 201 205 211 252 281 292

STEOUT The STEOUT parameter record provides you with the ability to specify additional data from the state-supplied database (either Florida-native format or TS-158 format) be posted to the output records. When a match occurs, GeoTAX returns these fields to a 200-byte area. You can specify a maximum of 25 STEOUT parameter records for a job.

The following table lists the additional fields from the Florida-native and TS-158 database formats. Some fields are exclusive to the Florida-native format, some fields are common to both formats, and some fields are exclusive to the TS-158 format.

Florida-native Database

TS-158 Database

Position Field Name Description

1-40 City Name USPS long city name. Character, left-justified, blank-filled.

41-48 Effect Date Date change goes into effect, in the format YYYYMMDD.

49-98 Evidence Name of competent evidence file. This field is only required for uploading of address for objections.

99-101 Fire District ID Fire district ID number.

102-104 Police District ID Police district ID number.

105-170 Reserved

171 Relax match Flag Relax match flag:

Y Match occurred as a result of relaxing secondary matching

N Match did not occur as a result of relaxing secondary matching

172-176 Reserved

200 Format Indicator Indicates type of database format:

F Florida-native


1-28 City Name USPS Long city name. Character, left-justified, blank-filled

29-36 Submit Date Change request date, in the format YYYYMMDD.

37-44 Approve Date Change approval date, in the format YYYYMMDD.

45-52 Effect Date Date change goes into effect, in the format YYYYMMDD.

53-60 Expiry Date Date change expires, in the format YYYYMMDD.


Field-by-Field

The following table describes each field of STEOUT.

Example

In the first example, GeoTAX moves the first 28 bytes (long city name) from the state-supplied area to position 201 of the output record. Using the second example, GeoTAX moves bytes 45-52 (effective date) from the state-supplied area to position 301 of the output record. Using the third example, GeoTAX move bytes 63-67 (special tax district code #1) to position 401 of the output record.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890STEOUT 001 201 028STEOUT 045 301 008STEOUT 063 401 005

TAXOUTThe optional TAXOUT parameter record provides you with a way to specify the posting of the sales and use tax rate data to your output records. TAXOUT data can include the Tax Rate General Return Code (GRC), the sales & use tax rates for the state, county, and municipality as well as a combined rate which is the total sum of the individual sales or use tax rates. You must have licensed and installed the Pitney Bowes Software Sales and Use Tax Rate reference file for this parameter to function. You can define one TAXOUT card.

Note: The format of the returned tax rate field is a 10-character decimal value. For example, 0.08250000 which represents a tax rate of 8.25%.

The following fields repeat; up to 10 districts.

61-62 Special Tax District Code Source #1

Source of the special tax district information:

VD Vendor

ST State.

63-67 Special Tax District Code #1

Special tax district code.

68-69 Type of Taxing Authority #1

Type of taxing authority.



1-6 KEYWORD Parameter name: STEOUT Required.

8-10 Offset into State-Supplied database

Offset position of the 200-byte state-supplied area to retrieve data.


12-14 Output location to receive data.



16-18 Length of data to move Length of data posted on output record. Required.No default.


Field-by-Field

The following table describes each field on the TAXOUT parameter record.

Example


• The 1-byte tax rate type indicating a General tax rate.


1-6 KEYWORD Parameter name: TAXOUT Required

8 1-byte input Tax Rate Type 1-byte alpha character indicating the type of tax rate to return. Examples, but not limited to:

G General

A Automotive

C Construction

M Medical

Required

10-12 Location for1-byte Tax Rate Return Code

Location on the output record where the 1-byte Return Code is posted:

E Exact match

P Partial match

A Alternate match

N Default match

Blank No match

Optional

14-16 Output location for10-byte Combined Sales Tax Rate

Location on the output record where the sum of the state, county, municipality and SPD sales tax rates is posted.Format is 0.00000000.

Optional

18-20 Output location for10-byte State Sales Tax Rate

Location on the output record where the state sales tax rate is posted.Format is 0.00000000.

Optional

22-24 Output location for10-Byte County Sales Tax Rate

Location on the output record where the county sales tax rate is posted.Format is 0.00000000.

Optional

26-28 Output location for10-byte Municipality Sales Tax Rate

Location on the output record where the municipality sales tax rate is posted.Format is 0.00000000.

Optional

30-32 Output location for10-byte Combined Use Tax Rate

Location on the output record where the sum of the state, county, municipality and SPD use tax rates is posted.Format is 0.00000000.

Optional

34-36 Output location for10-byte State Use Tax Rate

Location on the output record where the state use tax rate is posted.Format is 0.00000000.

Optional

38-40 Output location for10-byte County Use Tax Rate

Location on the output record where the county use tax rate is posted.Format is 0.00000000.

Optional

42-44 Output location for10-byte Municipality Use Tax Rate

Location on the output record where the municipality use tax rate is posted.Format is 0.00000000.

Optional


• The 1-byte Tax Rate General Return Code posted in position 198.

• The 10-byte Combined Sales Tax Rate posted in position 200.

• The 10-byte State Sales Tax Rate posted in position 210.

• The 10-byte County Sales Tax Rate posted in position 220.

• The 10-byte Municipality Sales Tax Rate posted in position 230.

• The 10-byte Combined Use Tax Rate posted in position 240.

• The 10-byte State Use Tax Rate posted in position 250.

• The 10-byte County Use Tax Rate posted in position 260.

• The 10-Byte Municipality Use Tax Rate posted in position 270.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890TAXOUT G 198 200 210 220 230 240 250 260 270

TESTIT TESTIT is included in your list when you perform a parm test. This parameter record tells GeoTAX to check the syntax of your parameter records before you run the entire job.

Field-by-Field

The only field on the TESTIT parameter record is the keyword, TESTIT.

Example*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890TESTIT

UFTxx UFTxx allows you to specify text for the footer of your reports. For more information, see “Defining Report Formats” on page 95.

Field-by-Field

The following table describes each field of UFTxx.

Position Field Name DescriptionComment

s

1-3 KEYWORD Parameter name: UFT Required

4 Line number Footer line number, from 1 to 4. Optional


Example*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890UFT1A GEOTAXUFT1B PITNEY BOWES SOFTWARE

UHDxx UHDxx allows you to specify text for the header of your reports. For more information, see “Defining Report Formats” on page 95.

Field-by-Field

The following table describes each field of UHDxx.

Example

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890UHD1B THIS HEADER WILL PRINT RIGHT-JUSTIFIED

5 Left or right line side Side of the footer line where the text appears.

A Left side of the line, positions 1-66.

B Right side of the line, positions 67-132.

Optional

7-72 Text for footer line Text defined to print at the bottom of every report.

Optional

Position Field Name DescriptionComment

s


1-3 KEYWORD Parameter name: UHD. Required

4 Line number Indicates a header line number, from 1 to 4. Optional

5 Left or right line side

Side of the header line where the text appears.

A Left side of the line, positions 1-66.

B Right side of the line, positions 67-132.

Optional

7-72 Text for header line

Text defined to print at the top of every report. Optional


USROUT USROUT outputs the number of user districts found in your user-defined boundary file. GeoTAX has return areas for up to 10 districts. The confidence code for each district can optionally be posted. This parameter can occur up to ten times (once for each possible district returned).

Field-by-Field

The following table describes each field of USROUT.


1-6 KEYWORD Contains the parameter name: USROUT Required

8-10 Number of districts

Indicates the number of user districts; up to 10. Optional

12-14 10-byte, first district output location of first user-defined field


Optional

16-18 10-byte, first district output location of second user-defined field


Optional

20-22 50-byte, first district output location of third user-defined field


Optional

24-26 Output location for 3-byte USR Confidence Code

NOTE: If requesting the USR Confidence Code, you must have the buffer distance set in the BF2OUT parameter card.

Output number is percentage confidence. Optional


Example

In this example, GeoTAX will:

• Post the number of districts starting in position 200.

• Post the first district first user-defined field starting in position 260.

• Post the first district second user-defined field starting in position 270.

• Post the first district third user-defined field starting in position 280.

• Post the confidence code starting in position 330.

*........1.........2.........3.........4.........5.........6.........7.........8*2345678901234567890123456789012345678901234567890123456789012345678901234567890USROUT 200 260 270 280 330

C -Error Conditions

In this appendix

This appendix describes error conditions that can occur during GeoTAX batch processing.

Parameter Record Errors 260Condition Codes 260


Parameter Record ErrorsWhen GeoTAX detects an error in your parameter records, your job terminates. Your job log shows that the job appended, with a user code of 0008.

To determine the errors GeoTAX detected:

1. Open the output file containing the reports and review the parameter record listing.

2. Scroll to the right in the parameter record listing past the 80th column in the report. Look for the *ERROR* printed in the file.

3. Scroll back to the left to columns 1 through 80 and look at the line directly below the parameter record with the error. The line where the *ERROR* message occurs is the parameter record containing the error.

For example, if the LLOUT parameter record is supposed to be

*...+....1....+....2....+....3....+....4....+....5LLOUT 046 030 G Z Z

But, was accidentally typed

*...+....1....+....2....+....3....+....4....+....5LLOUT 046a030 G Z Z

The parameter record listing shows an *Error* on the line containing the LLOUT parameter after the 80th position. Also, asterisks are placed beneath positions 11 through 14 as follows:

*...+....1....+....2....+....3....+....4....+....5LLLOUT 046a030 G Z Z ***

Condition CodesThe following table lists the possible condition codes when executing GeoTAX.

ProgramCondition

Code Code Description

G1DBLOAD 0 Normal completion.

99 File I/O error. See output from job for specific message.

GTBM00 0 Normal completion.

8 Parameter record error.


GTBMVP00 0 Normal completion.


SMPLEXOP 0 Normal Completion.



GTAUXBLD 0 Normal completion.


99 Abort due to errors. See output from job for specific message.

GTXLOAD1 0 Normal completion.








GTBNDLOD 0 Normal completion.


ProgramCondition

Code Code Description

D -Status Codes

In this appendix

This appendix contains definitions of the Match and Location return codes.

Match Codes 263Location codes 265


Match CodesGeoTAX returns Match Codes that indicate the portions of the address that matched or did not match to the GeoTAX reference file. If GeoTAX could not make a match, the Match Code begins with E and the remaining digits indicate why the address did not match. The digits do not specifically refer to which address elements did not match, but rather why the address did not match.

Match Code values

The following table contains the Match Code values. You can find a description of the hex digits for the different Match Codes in the table following the Match Code table.

Code Description

Ahh Same as Shh, but indicates match to an alias name record or an alternate record.

Chh Street address did not match, but located a street segment based on the input ZIP Code or city.

D00 Matched to a small town with P.O. Box or General Delivery only.

Ghh Matched to an auxiliary file.

Hhh House number was changed.

Jhh Not used.

Qhh Matched to USPS range records with unique ZIP Codes. CASS rules prohibit altering an input ZIP if it matches a unique ZIP Code value.

Rhh Matched to a ranged address.

Shh Matched to USPS data. This is considered the best address match, because it matched directly against the USPS list of addresses. S is returned for a small number of addresses when the matched address has a blank ZIP+4.

Thh Matched to a street segment record. Street segment records do not contain ZIP Code information. If you enter a ZIP Code, the application returns the ZIP Code you entered. If the input city and state has only one ZIP Code, the application returns that ZIP Code.

Uhh Matched to USPS data but cannot resolve the ZIP+4 code without the firm name or other information.

Xhhh Matched to an intersection of two streets, for example, “Clay St & Michigan Ave.” The first hex digit refers to the last line information, the second hex digit refers to the first street in the intersection, and the third hex digit refers to the second street in the intersection.

NOTE: The USPS does not allow intersections as a valid deliverable address.

Yhhh Same as Xhhh, but an alias name record was used for one or both streets.

Z No address given, but verified the provided ZIP Code.


Hex digit decoding

The following table contains the description of the hex digits for the Match Code values.

Match error codes

The following table describes the values returned when the application cannot find a match code.

Code In first hex position means: In second and third hex position means:

0 No change in last line. No change in address line.

1 ZIP Code changed. Street type changed.

2 City changed. Pre-directional changed.

3 City and ZIP Code changed. Street type and pre-directional changed.

4 State changed. Post-directional changed.

5 State and ZIP Code changed. Street type and post-directional changed.

6 State and City changed. Pre-directional and post-directional changed.

7 State, City, and ZIP Code changed.

Street type, pre-directional, and post-directional changed.

8 ZIP+4 changed. Street name changed.

9 ZIP and ZIP+4 changed. Street name and street type changed.

A City and ZIP+4 changed. Street name and pre-directional changed.

B City, ZIP, and ZIP+4 changed. Street name, street type, and pre-directional changed.

C State and ZIP+4 changed. Street name and post-directional changed.

D State, ZIP, and ZIP+4 changed. Street name, street type, and post-directional changed.

E State, City, and ZIP+4 changed. Street name, pre-directional, and post-directional changed.

F State, City, ZIP, and ZIP+4 changed.

Street name, street type, pre-directional, and post-directional changed.

Code Description

Ennn Indicates an error or no match. This can occur when the address entered does not exist in the database or the address is badly formed and cannot be parsed correctly. The last three digits of an error code indicate which parts of an address the application could not match to the database.

nnn = 000 No match made.

nnn = 001 Low level error.

nnn = 002 Could not find data file.

nnn = 003 Incorrect GSD file signature or version ID.

nnn = 010 No city and state or ZIP Code found.

nnn = 011 Input ZIP not in the directory.


Location codesGeoTAX returns location codes that indicate the methodology used to compute the geocode and may also provide some information about the quality of the geocode.

A Location Code of E indicates a location code is not available. This usually occurs when you have requested ZIP Code centroids of a high quality, and one is not available for that match. It can occur infrequently when GeoTAX does not have a 5-digit centroid location. GeoTAX can also return an E location code type when it cannot standardize an input address and there is no input ZIP Code. In this case, do not assume the ZIP Code returned with the non-standardized address is the correct ZIP Code because GeoTAX did not standardize the address; therefore, GeoTAX does not return geocoding or Census Block information.

nnn = 012 Input city not in the directory.

nnn = 013 Input city not unique in the directory.

nnn = 014 Out of licensed area. Only occurs if using Group 1 licensing technology.

nnn = 015 Record count is depleted and license has expired.

nnn = 020 No matching streets found in directory.

nnn = 021 No matching cross streets for an intersection match.

nnn = 022 No matching segments.

nnn = 023 Unresolved match.

nnn = 024 No matching segments. (Same as 022.)

nnn = 025 Too many possible cross streets for intersection matching.

nnn = 026 No address found when attempting a multiline match.

nnn = 027 Invalid directional attempted.

nnn = 028 Record also matched EWS data, therefore the application denied the match.

nnn = 029 No matching range, single street segment found

nnn = 030 No matching range, multiple street segments found

Code Description


Address location codes

Address location codes detail the known qualities about the geocode. An address location code has the following characters.

The following table contains the address codes.

1st character Always an A indicating an address location.

2nd character May be one of the following

C Interpolated address point location.

G GeoTAX Auxiliary or Landmark Auxiliary file data location

I Application infers the correct segment from the candidate records

P Point-level data location

R Location represents a ranged address.

S Location on a street range

X Location on an intersection of two streets

3rd and 4th characters Digit indicating other qualities about the location.

Code Description

AGn Indicates a geocode match to a GeoTAX Auxiliary or Landmark Auxiliary file where n is one of the following values:

n = 0 The geocode represents the center of a parcel, building or landmark.

n = 1 The geocode is an interpolated address along a segment.

n = 2 The geocode is an interpolated address along a segment, and the side of the street cannot be determined from the data provided in the auxiliary file record.

n = 3 The geocode is the midpoint of the street segment.

APnn Indicates a point-level geocode match representing the center of a parcel or building, where nn is one of the following values:

nn = 02 Parcel centroid

Indicates the center of an assessor’s parcel (tract or lot) polygon. When the center of an irregularly shaped parcel falls outside of its polygon, the centroid is manually repositioned to fall inside the polygon as closely as possible to the actual center.

nn = 04 Address point

Represents field-collected GPS points with field-collected address data.


nn = 05 Structure centroid

Indicates the center of a building footprint polygon, where the building receives mail or has telephone service.

Usually a residential address consists of a single building. For houses with outbuildings (detached garages, shed, barns, etc.), only the residences have a structure point. Condominiums and duplexes have multiple points for each building. Larger buildings, such as apartment complexes, typically receive mail at one address for each building and therefore individual apartments are not represented as discrete structure points.

Shopping malls, industrial complexes, and academic or medical center campuses where one building accepts mail for the entire complex are represented as one point. When addresses are assigned to multiple buildings within one complex, each addressed structure is represented by a point.

If the center of a structure falls outside of its polygon, the center is manually repositioned to fall inside the polygon.

nn = 07 Manually placed

Address points are manually placed to coincide with the midpoint of an assessor’s parcel’s street frontage at a distance from the center line.

nn = 08 Front door point

Represents the designated primary entrance to a building. If a building has multiple entrances and there is no designated primary entrance or the primary entrance cannot readily be determined, the primary entrance is chosen based on proximity to the main access street and availability of parking.

nn = 09 Driveway offset point

Represents a point located on the primary access road (most commonly a driveway) at a perpendicular distance of between 33-98 feet (10-30 meters) from the main roadway.

nn = 10 Street access point

Represents the primary point of access from the street network. This address point type is located where the driveway or other access road intersects the main roadway.

nn = 21 Base parcel point

The Centrus point data includes individual parcels that may be "stacked".These stacked parcels are individually identified by their unit or suite number, and GeoTAX is able to match to this unit number and return the correct APN.If an input address is for a building or complex without a unit number, the "base" parcel information returns and will not standardize to a unit number or return additional information such as an APN.

nn = 22 Backfill address point

The precise parcel centroid is unknown. The address location assigned is based on two known parcel centroids.

nn = 23 Virtual address point

The precise parcel centroid is unknown. The address location assigned is relative to a known parcel centroid and a street segment end point.

nn = 24 Interpolated address point

The precise parcel centroid is unknown. The address location assigned is based on street segment end points.

AIn The correct segment is inferred from the candidate records at match time.

Code Description


ASn House range address geocode. This is the most accurate street interpolated geocode available.

AIn, ASn, and ACnh share the same qualities for the 3rd character n as follows:

n = 0 Best location.

n = 1 Street side is unknown. The Census FIPS Block ID is assigned from the left side; however, there is no assigned offset and the point is placed directly on the street.

n = 2 Indicates one or both of the following:

• The address is interpolated onto a TIGER segment that did not initially contain address ranges.

• The original segment name changed to match the USPS spelling. This specifically refers to street type, predirectional, and postdirectional.

NOTE: Only the second case is valid for non-TIGER data because segment range interpolation is only completed for TIGER data.

n = 3 Both 1 and 2.

n = 7 Placeholder. Used when starting and ending points of segments contain the same value and shape data is not available.

ARn Ranged address geocode, where n is one of the following:

n = 1 The geocode is placed along a single street segment, midway between the interpolated location of the first and second input house numbers in the range.

n = 2 The geocode is placed along a single street segment, midway between the interpolated location of the first and second input house numbers in the range, and the side of the street is unknown. The Census FIPS Block ID is assigned from the left side; however, there is no assigned offset and the point is placed directly on the street.

n = 4 The input range spans multiple USPS segments. The geocode is placed on the endpoint of the segment which corresponds to the first input house number, closest to the end nearest the second input house number.

n = 7 Placeholder. Used when the starting and ending points of the matched segment contain the same value and shape data is not available.

AXn Intersection geocode, where n is one of the following:

n = 3 Standard single-point intersection computed from the center lines of street segments.

n = 8 Interpolated (divided-road) intersection geocode. Attempts to return a centroid for the intersection.

Code Description


Street centroid location codes

Street centroid location codes indicate the Census ID accuracy and the position of the geocode on the returned street segment. A street centroid location code has the following characters.

The following table contains the values and descriptions for the location codes.

ZIP+4 centroid location codes

ZIP+4 centroid location codes indicate the quality of two location attributes: Census ID accuracy and positional accuracy. A ZIP+4 centroid location code has the following characters.

1st character Always C indicating a location derived from a street segment.

2nd character Census ID accuracy based on the search area used to obtain matching Street Segment.

3rd character Location of geocode on the returned street segment.

Character position Code Description

2nd Character

B Block Group accuracy (most accurate). Based on input ZIP Code.

T Census Tract accuracy. Based on input ZIP Code.

C Unclassified Census accuracy. Normally accurate to at least the County level. Based on input ZIP Code.

F Unknown Census accuracy. Based on Finance area.

P Unknown Census accuracy. Based on input City.

3rd Character

C Segment Centroid.

L Segment low-range end point.

H Segment high-range end point.

1st character Always Z indicating a location derived from a ZIP centroid.

2nd character Census ID accuracy.

3rd character Location type.

4th character How the location and Census ID was defined. Provided for completeness, but may not be useful for most applications.




2nd Character

B Block Group accuracy (most accurate).

T Census Tract accuracy.

C Unclassified Census accuracy. Normally accurate to at least the County level.

3rd Character

5 Location of the Post Office that delivers mail to the address, a 5-digit ZIP Code centroid, or a location based upon locale (city). See the 4th character for a precise indication of locational accuracy.

7 Location based upon a ZIP+2 centroid. These locations can represent a multiple block area in urban locations, or a slightly larger area in rural settings.

9 Location based upon a ZIP+4 centroid. These are the most accurate centroids and normally place the location on the correct block face. For a small number of records, the location may be the middle of the entire street on which the ZIP+4 falls. See the 4th character for a precise indication of locational accuracy.

4th Character

A Address matched to a single segment. Location assigned in the middle of the matched street segment, offset to the proper side of the street.

a Address matched to a single segment, but the correct side of the street is unknown. Location assigned in the middle of the matched street segment, offset to the left side of the street, as address ranges increase.

B Address matched to multiple segments, all segments have the same Block Group. Location assigned to the middle of the matched street segment with the most house number ranges within this ZIP+4. Location offset to the proper side of the street.

b Same as methodology B except the correct side of the street is unknown. Location assigned in the middle of the matched street segment, offset to the left side of the street, as address ranges increase.

C Address matched to multiple segments, with all segments having the same Census Tract. Returns the Block Group representing the most households in this ZIP+4. Location assigned to the middle of the matched street segment with the most house number ranges within this ZIP+4. Location offset to the proper side of the street.

c Same as methodology C except the correct side of the street is unknown. Location assigned in the middle of the matched street segment, offset to the left side of the street, as address ranges increase.


D Address matched to multiple segments, with all segments having the same County. Returns the Block Group representing the most households in this ZIP+4. Location assigned to the middle of the matched street segment with the most house number ranges within this ZIP + 4. Location offset to the proper side of the street.

d Same as methodology D except the correct side of the street is unknown. Location assigned in the middle of the matched street segment, offset to the left side of the street, as address ranges increase.

E Street name matched; no house ranges available. All matched segments have the same Block Group. Location placed on the segment closest to the center of the matched segments. In most cases, this is on the mid-point of the entire street.

F Street name matched; no house ranges available. All matched segments have the same Census Tract. Location placed on the segment closest to the center of the matched segments. In most cases, this is on the mid-point of the entire street.

G Street name matched (no house ranges available). All matched segments have the same County. Location placed on the segment closest to the center of the matched segments. In most cases, this is on the mid-point of the entire street.

H Same as methodology G, but some segments are not in the same County. Used for less than05% of the centroids.

I Created ZIP+2 cluster centroid as defined by methodologies A, a, B, and b. All centroids in this ZIP+2 cluster have the same Block Group. Location assigned to the ZIP+2 centroid.

J Created ZIP+2 cluster centroid as defined by methodologies A, a, B, b, C, and c. All centroids in this ZIP+2 cluster have the same Census Tract. Location assigned to the ZIP+2 centroid.

K Created ZIP+2 cluster centroid as defined by methodologies A, a, B, b, C, c, D, and d. Location assigned to the ZIP+2 centroid.

L Created ZIP+2 cluster centroid as defined by methodology E. All centroids in this ZIP+2 cluster have the same Block Group. Location assigned to the ZIP+2 centroid.

M Created ZIP+2 cluster centroid as defined by methodology E and F. All centroids in this ZIP+2 cluster have the same Census Tract. Location assigned to the ZIP+2 centroid.

N Created ZIP+2 cluster centroid as defined by methodology E, F, G, and H. Location assigned to the ZIP+2 centroid.

O ZIP Code is obsolete and not currently used by the USPS. Historic location assigned

V Over 95% of addresses in this ZIP Code are in a single Census Tract. Location assigned to the ZIP Code centroid.

W Over 80% of addresses in this ZIP Code are in a single Census Tract. Reasonable Census Tract accuracy. Location assigned to the ZIP Code centroid.

X Less than 80% of addresses in this ZIP Code are in a single Census Tract. Census ID is uncertain. Location assigned to the ZIP Code centroid.



Geographic centroid location codes

Geographic centroid location codes indicate the quality of two location attributes: the geographic location and area type


Y Rural or sparsely populated area. Census code is uncertain. Location based upon the USGS places file.

Z P.O. Box or General Delivery addresses. Census code is uncertain. Location based upon the Post Office location that delivers the mail to that address


1st character Always G indicating a location derived from a geographic centroid.

2nd character Geographic area type.


2nd Character

M Municipality (city)

C County

S State

E -Type Codes

In this appendix

This appendix discusses the following type codes provided with GeoTAX:

Special Purpose Districts (SPD) 274Insurance Premium Districts (IPD) 275Payroll Tax Districts (PAY) 276Property Tax Districts (PTD) 276


Special Purpose Districts (SPD).

Type Description

AMB AMBULANCE DISTRICT

ASC SALES AND USE TAX

ATA ADVANCED TRANSPORTATION AUTHORITY

ATD AIRPORT TAX DISTRICT

BSD BASEBALL STADIUM DISTRICT

CAD COUNTY ASSISTANCE DISTRICT

CCD CRIME CONTROL DISTRICT

CFA COUNTY FINANCE AUTHORITY

CMB COMBINED DISTRICT

CTY CITY TRANSACTIONS

DVD DEVELOPMENT DISTRICT

EDD ECONOMIC DEVELOPMENT DISTRICT

EDZ ECONOMIC DEVELOPMENT ZONE

ESD EMERGENCY SERVICES DISTRICT

FCD FIRE CONTROL DISTRICT

FPA FLOOD PROTECTION AUTHORITY

FPD FIRE PROTECTION DISTRICT

FSD FOOTBALL STADIUM DISTRICT

HBZ HOSPITAL BENEFIT ZONE

HSA HOUSING AUTHORITY

HSD HEALTHCARE SERVICES DISTRICT

HSP HOSPITAL DISTRICT

IMP IMPROVEMENT DISTRICT

IRD INDIAN RESERVATION

LFW LFW/CDC

LIB LIBRARY DISTRICT

MSD MUSEUM DISTRICT

MTA METRO TRANSPORTATION AUTHORITY


Insurance Premium Districts (IPD)

OSA OPEN SPACE AUTHORITY

PFD PUBLIC FACILITY DISTRICT

POL POLICE DISTRICT

PRD PARK AND RECREATION DISTRICT

PSI PUBLIC SAFETY IMPROVEMENT

RCT RACE TRACK

RDA REVENUE DEVELOPMENT AREA

RMA ROAD MAINTENANCE AUTHORITY

RTA REGIONAL TRANSPORTATION AUTHORITY

SAD SPORTS DISTRICT

SCD SCIENCE AND CULTURAL DISTRICT

SUT SALES AND USE TAX

TDD TRANSPORTATION DEVELOPMENT DISTRICT

TED TOURISM COMMUNITY ENHANCEMENT DISTRICT

UNI SCHOOL DISTRICT

URA URBAN RENEWAL AUTHORITY

WCD WATER COMMISSION DISTRICT

ZOO ZOO DISTRICT

Type Description

State Type Description

AL FIRE Fire District

AL NT-MUN Non-Taxing Municipality

AL PREM Premium Tax District

AZ PRIV Private Fire District

AZ PUB Public Fire District

DE FIRE Fire District

FL FIRE Fire District

FL POLICE Police District


Payroll Tax Districts (PAY)

Property Tax Districts (PTD)

GA PREM Premium Tax District

IL FIRE Fire District

KY COUNTY County

KY MUNI Municipality

KY USD Urban Services District

LA PREM Premium Tax District

MN FIRE Fire District

ND FIRE Fire District

NJ FIRE Fire District

NY FIRE Fire District

SC FIRE Fire District

SC NT-MUN Non-Taxing Municipality

SC PREM Premium Tax District

TX PROP Windstorm Surcharge on Property Line

State Type Description

Type Description

JED Joint Economic Development District

MTA Mass Transit Authority

MUN Municipality

UNI School District

Type Description

R Reporting

B Billing

X Reporting and Billing

F -Class Code Definitions

In this appendix

This appendix lists definitions for the FIPS Class Codes that GeoTAX can return.

Class Code Definitions 278


Class Code DefinitionsThe following table lists the FIPS Class Codes that GeoTAX can return.

Class Code Definition

Class C — Incorporated Places

C1 Identifies an active incorporated place that is not also recognized as an Alaska Native Village Statistical area, and does not also serve as a primary county division; that is, it is included in and is part of a primary county division.

For example, the city of Hammond, Indiana is within and part of North township; the city of Austin, Texas is within and part of several census county divisions in several counties; Hammond and Austin are coded C1.

C2 Identifies an incorporated place that also serves as a primary county division because, although the place is coextensive with a minor civil division (MCD), the Census Bureau, in agreement with State officials, does not recognize the MCD for presenting census data because the MCD is a nonfunctioning entity; applies to Iowa and Ohio only.

For example, the city of Dubuque, Iowa is coextensive with Julien township, which does not function as a governmental unit and may not be well-known even to local residents; the city is assigned code C2, and the township, Z8. This subclass is new for FIPS 55-3. Also see subclass C5.

C3 Identifies a consolidated city; that is, an incorporated place that has consolidated its governmental functions with a county or MCD, but continues to include other incorporated places that are legally part of the consolidated government.

For example, the city of Columbus, Georgia is consolidated with Muscogee County, which continues to exist as a nonfunctioning legal entity in the State; however, the town of Bibb City continues to exist as a separate active incorporated place within the consolidated government and, therefore, Columbus is treated as a consolidated city. At the time of publication, there are seven consolidated cities in the United States: Athens-Clarke County, Georgia; Butte-Silver Bow, Montana; Columbus, Georgia; Indianapolis, Indiana; Jacksonville, Florida; Milford, Connecticut; and Nashville-Davidson, Tennessee. This subclass is new for FIPS 55-3.

C4 Identifies an alternate authoritative common name of any member of the other subclasses of Class C. The entity code of the legal name is referenced in the ``Other Name Code'' of the record, and in the entry for the legal name, the Other Name Code references the alternate.

For example, the entity in California whose legal name is San Buenaventura (subclass C1) is commonly known as Ventura, which is coded C4.

C5 Identifies an incorporated place that also serves as a primary county division; that is, it is not included in any adjacent primary county division of class T or Z. For example, Boston, MA, is legally a primary division of the county and recognized as an incorporated place and, therefore, is coded C5. Also see subclass C2.

C6 Identifies an incorporated place that is coincident with or approximates an Alaska Native Village statistical area. The Other Name Code references the Alaska Native Village statistical area; see code E6.

C7 Identifies an independent city. At the time of publication, independent cities exist in only four States: Maryland (Baltimore City), Nevada (Carson City), Missouri (St. Louis City), and Virginia (41 cities). These cities also serve as county equivalents, and all but Carson City also serve as primary county divisions.


C8 Identifies the portion of a consolidated city that is not within another incorporated place; see subclass C3. The Census Bureau identifies these nonfunctioning entities by taking the name of the consolidated city and appending in parentheses the word remainder. For example, Columbus (remainder) identifies the portion of the Columbus, Georgia consolidated city that is not also in Bibb City. This code is new for FIPS 55-3.

C9 Identifies an inactive or nonfunctioning incorporated place.

Class U — Unincorporated Places (Except Those Associated with Facilities)

U1 Identifies a census designated place (CDP) with a name identical to the authoritative common name that describes essentially the same population. Also see code M2.

U2 Identifies a CDP with a name not identical to an authoritative common name of essentially the same area. If there is an alternate authoritative common name, it is referenced in the Other Name Code field. For example, Suitland-Silver Hill, Maryland is the name of a locally delineated CDP recognized by the Census Bureau which is a combination of two communities Suitland and Silver Hill and, therefore, because it is not the authoritative name of the area, is coded U2; Sierra Vista Southeast, Arizona is a CDP that includes the built-up area adjoining the city of Sierra Vista on the southeast, but is not an authoritative name for that area and, therefore, is coded U2. Also see code M2.

U3 Identifies (a) an alternate, authoritative common name of a population essentially described by a specific CDP with a different name (the Other Name Code references the CDP), or (b) a community wholly or substantially within the boundaries of a CDP with a different name (the Part of Code references the CDP). For example, Silver Hill and Suitland are coded U3 and cross-referenced to the CDP of Suitland-Silver Hill (see code U2).

U4 Identifies a populated place wholly or substantially within the boundaries of an incorporated place with a different name; the Part of Code identifies the incorporated place. For example, Harlem and Greenwich Village, which are part of New York city, and Hollywood, which is part of Los Angeles, California, are coded U4.

U5 Dropped. Only one place the CDP of Arlington, Virginia was in this subclass in FIPS PUB 95-2; it has been recoded as U1 as a place and as Z3 as a subclass in FIPS 55-3 as a county subdivision.

U6 Identifies a populated place located wholly or substantially outside the boundaries of any incorporated place or CDP with an authoritative common name recognized by the U.S. Geological Survey.

U8 Identifies a populated place located wholly or substantially outside the boundaries of an incorporated place or CDP but whose name has not been verified as authoritative by the U.S. Geological Survey.

U9 Identifies a CDP that is coincident with or approximates the area of an Alaska Native Village statistical area. The Other Name Code references the Alaska Native Village statistical area; see code E2. This code is new for FIPS 55-3.

Class Code Definition

G -Auxiliary Files

In this appendix

Overview 281Landmark Auxiliary file 281User Auxiliary file 288


OverviewThere are several auxiliary file options available to you as follows:

Landmark Auxiliary file - This option provides you a way to specify customized address information in your input records; this file also includes latitude/longitude spatial information. The recommended primary use of this file is to match to your company’s non-address locations such as well heads, transmission towers or any other descriptive location. The latitude/longitude coordinates that is part of the input needed to build this file allows companies to automatically keep track of any jurisdictional changes that affect these unique locations. Matching to this file requires that the input record information match exactly to the Landmark file contents. This also applies to street records if you choose to enter them in the Landmark file. For directions on creating the Landmark Auxiliary file, see “Landmark Auxiliary file” on page 281.

User Auxiliary file - This user-defined file can override results to the master files in street-level matching. If you have data that is more current than that in the master file, you can enter the new data into the auxiliary file and use it for your address matching. This file does not contain latitude/longitude spatial information. The input address is cleansed before GeoTAX attempts a match to this file. For directions on creating the User Auxiliary file, see “User Auxiliary file” on page 288.

GeoTAX Auxiliary file - Pitney Bowes Software updates its data regularly to incorporate new rules by government entities and enhancements by third-party data providers. This file contains new addresses that have not yet been added to the master file. It provides the most up-to-date address data possible. This file just needs to be downloaded; for information on how to load your GeoTAX Auxiliary file, see “GeoTAX Auxiliary File” on page 33.

The remainder of this appendix covers how to create and match to Landmark and User Auxiliary files.

Landmark Auxiliary fileThis section contains information on creating and matching to a Landmark Auxiliary file and covers the following topics:

• Landmark Auxiliary file requirements

• Record types

• Landmark Auxiliary file organization

• Default values

• Landmark Auxiliary file layout

• Matching to the Landmark Auxiliary file


Landmark Auxiliary file requirements

GeoTAX requires that the Landmark Auxiliary file complies with the following.

For Windows and UNIX/Linux:

• File must be a fixed-width ASCII text file

• File must have a .gax extension

• File must have less than 500,000 records

• File must follow the column field order and lengths specified in “Landmark Auxiliary file layout” on page 284.

For z/OS:

• File must be an EBCDIC text file with a fixed-width of 854 bytes

• There are two options for creating the Landmark Auxiliary file:

– Create the file on Windows, then FTP in ASCII mode. Upon upload, convert to EBCDIC.

– Create the file on z/OS using the sample template file yourhlq.GEOTAX.LDMKFILE delivered with GeoTAX.

• File must have less than 500,000 records

• File must follow the column field order and lengths specified in “Landmark Auxiliary file layout” on page 284.

Record types

You can include two types of records in your Landmark Auxiliary file: Landmark and Street records.

Landmark Records

A landmark record represents a single site. To be a valid landmark record the record must have the following fields:

• ZIP Code

• Name of the landmark – placed in the street name field

• Beginning latitude of the landmark

• Beginning longitude of the landmark

In addition, a landmark record may NOT have the following fields:

• Street type abbreviation

• Pre-directional abbreviation

• Post-directional abbreviation

• Low house number

• High house number


Street Records

A street record contains a range of one or more addresses on a street. To be a valid street record the record must have the following fields:

• ZIP Code

• Street name

• Street type abbreviation, if part of the address

• Pre-directional abbreviation, if part of the address

• Post-directional abbreviation, if part of the address

• Low house number within the street segment

• High house number within the street segment

• Beginning longitude of the street segment

• Beginning latitude of the street segment

In addition, a street record may NOT have:

• Secondary address information, such as unit numbers

• Mailstops

• Private mail boxes (PMBs)

During processing GeoTAX ignores any record that does not comply with the preceding requirements.

Landmark Auxiliary file organization

You must comply with the following organizational rules when creating your Landmark Auxiliary file.

• Use semicolons in the first column to indicate a row is a comment, not a data record; GeoTAX ignores rows that begin with a semicolon.

• Order the records within the file by descending ZIP Code then descending street name for optimal performance.

• All records must represent one or both sides of a street.

• All records must represent segments that are straight lines. Records cannot represent a non-straight segment.

• If house numbers are present in the record, the house number range must be valid according to USPS rules documented in Publication 28.

• The numeric fields, such as ZIP Codes, must contain all numbers.

• Latitude and longitude values must be in millionths of decimal degrees.

• Records cannot contain PO Box addresses.


Default values

GeoTAX uses the following defaults if you do not include the values in the Landmark Auxiliary file:

• House number parity = B (both odds and evens)

• Segment direction = F (forward) or A (ascending), these are interchangeable.

• Side of street = U (unknown)

Landmark Auxiliary file layout

Required

Field Description

For Street

Segment Match

For Landmark

Match

Requires Exact Match Length Position

ZIP Code 5-digit ZIP Code. X X X 5 1-5

Street name Name of the street or landmark. X X X 30 6-35

Street type abbreviation

Street type. Also called street suffix.

See the USPS Publication 28 for a complete list of supported street types.

X 4 36-39

Predirectional USPS street name predirectional abbreviation. Supported values are N, E, S, W, NE, NW, SE, and SW.

X 2 40-41

Postdirectional USPS street name postdirectional abbreviations. Supported values are N, E, S, W, NE, NW, SE, and SW.

X 2 42-43

RESERVED RESERVED 4 44-47

Low house number

Low house number of the address range.

X 11 48-58

High house number

High house number of the address range.

X 11 59-69

House number paritya

Parity of the house number in the range.

E – Even

O – Odd

B – Both

1 70

Segment direction

Direction the house numbers progress along the segment:

F – Forward (default) or A - Ascending

R – Reverse or D - Descending

1 71


RESERVED RESERVED 1 72

FIPS state US government FIPS state code.

2 73-74

FIPS county US government FIPS county code.

3 75-77

Census tract US Census tract number. 6 78-83

Census block group

US Census block group number.

1 84

Census block ID US Census block ID number. 3 85-87


State abbreviation

USPS state abbreviation. 2 93-94

County name Name of the county. 25 95-119

MCD code Minor Civil Division code. 5 120-124

MCD name Minor Civil Division name. 40 125-164

CBSA code Core Based Statistical Area code.

5 165-169

CBSA name Core Based Statistical Area name.

49 170-218


City Name City name. Overrides the city/state preferred city name upon a return.

40 224-263


User-defined data

User-defined data. 300 501-800

Record ID Number

User-defined unique record identifier.

10 801-810

Side of street Side of the street for the address:

L – Left side

R – Right side

B – Both sides

U – Unknown side (default)

This is relative to the segment end points and the segment direction.

1 811

Required

Field Description

For Street

Segment Match

For Landmark

Match



a. For even and odd house number parity records, this specifies on which side of the street the house lays. For records containing both even and odd house numbers, the odd house numbers are on the specified side of the street, and the even house numbers are on the other side. This is a factor when using street offset.

Matching to the Landmark Auxiliary file

This section provides information on the matching performed by GeoTAX to the Landmark Auxiliary file, and contains the following topics:

• Matching overview

• Record type matching rules

• Unavailable GeoTAX features and functions

• Landmark Auxiliary match output

Matching overview

GeoTAX performs the following steps when matching an input address to a Landmark Auxiliary file.

1. GeoTAX determines if there is a Landmark Auxiliary file present. If more than one Landmark Auxiliary file is present, GeoTAX attempts to match against the first file. GeoTAX ignores any additional Landmark Auxiliary files for matching, regardless if GeoTAX found a match to the first auxiliary file.

If a record within the Landmark Auxiliary files is invalid, GeoTAX returns a message indicating the auxiliary file has an invalid record. GeoTAX continues to process input addresses against the Landmark Auxiliary file, but will not match to the invalid auxiliary file record.

2. If the Landmark Auxiliary file is present, GeoTAX first attempts to match to it. If more than one type of auxiliary file is present, the search order is:

Beginning longitude

Beginning longitude of the street segment in millionths of degrees.

X X 11 812-822

Beginning latitude

Beginning latitude of the street segment in millionths of degrees.

X X 10 823-832

Ending longitude Ending longitude of the street segment in millionths of degrees.

11 833-843

Ending latitude Ending latitude of the street segment in millionths of degrees.

10 844-853

Required

Field Description

For Street

Segment Match

For Landmark

Match







Note: GeoTAX only matches your input address to your Landmark Auxiliary file if there is an exact match. Therefore, your input address list should be as clean as possible; free of misspellings and incomplete addresses.

3. If GeoTAX finds an exact record match to the Landmark Auxiliary file, it standardizes the match to USPS regulations and returns the output of the auxiliary file match.

Note: You cannot update the Landmark Auxiliary file while GeoTAX is running. If you want to update the auxiliary file, you need to terminate GeoTAX before attempting to replace or edit the file.

Record type matching rules

When attempting a match against the Landmark Auxiliary file, GeoTAX abides by the following rules:

Street record match

• The input house number must fall within or be equal to the low or high house number values of the auxiliary record.

• The input house number must agree with the parity of the auxiliary record.

• The input ZIP Code must exactly match the ZIP Code of the auxiliary record.

Landmark record match

• The input data must contain both a ZIP Code and address line, and they must exactly match the values on the auxiliary record.

• The input address cannot have any other data, such as a house number, unit number, or Private Mail Box (PMB).

Note: GeoTAX only matches the ZIP Code against the auxiliary file. GeoTAX does not verify that the ZIP Code of the input address record is correct for the city and state. You should validate this information in your input address before processing against the auxiliary file.

Unavailable GeoTAX features and functions

The following contains the features and functions that do not apply when GeoTAX makes a Landmark Auxiliary file match. GeoTAX does not match to:

• two-line addresses

• multi-line addresses

• intersection addresses

• dual addresses


Landmark Auxiliary match output

Several standard GeoTAX outputs do not apply to a Landmark Auxiliary match since GeoTAX matches to an exact auxiliary match and does not perform any additional validation for the match.

GeoTAX provides special match codes and location code values for auxiliary matches. See Appendix D, “Status codes” for more information.

When GeoTAX finds a match to a Landmark Auxiliary file, the default output follows the following conventions:

• GeoTAX formats the output of the auxiliary file match as a street-style address.

• GeoTAX follows the casing setting you indicate by the casing function. GeoTAX does not maintain the casing in the auxiliary file for mixed cased values. For example, GeoTAX returns O’Donnell as ODONNELL or Odonnell depending on the setting of the casing function.

Note: GeoTAX does not change the casing for the User Data field.

• GeoTAX removes spaces at the beginning and ending of fields in the auxiliary file.

Note: GeoTAX does not remove spaces for the User Data field.

User Auxiliary filePitney Bowes updates its data regularly to incorporate new rules by government entities and enhancements by third-party data providers. In some cases, your organization may have newer information that Pitney Bowes has not yet incorporated into the data files. User Auxiliary files provide a way for you to process your input records against a file that includes these changes.

When matching to a User Auxiliary file, complete the following steps:

1. Create the User Auxiliary file.

2. Load the User Auxiliary file.

3. Match to the User Auxiliary file.

4. Post User-Defined Data (optional).

This section provides directions on the first step - creating the User Auxiliary file with the required layout. To load, match and post user-defined data to the User Auxiliary file (steps 2-4 above), see “User Auxiliary File” on page 31.

User Auxiliary file layout

If you are running on Windows, or have access to a system running Windows, you can use the Auxiliary File Editor to create a User Auxiliary file. The editor comes on separate installation media with your GeoTAX shipment. For more information on using the Auxiliary File Editor, see the Auxiliary File Editor User’s Guide.


If you do not have an available system running Windows, you need to use your own editor to create a file in the proper layout.

The following table describes the User Auxiliary file layout. Sort records in ascending order for the ZIP Code, street name, street type, directional, and low house range; and descending order for high house range. This sorting minimizes the time required for street-level matching. The User Auxiliary file has a block size of 8K, a key length of 47 bytes, and a record length of 800 bytes. There is a sample file SEQAUX in your GeoTAX data directory created when you installed GeoTAX.

Copy the User Auxiliary file to %G1GTX%\data\. The filename needs to be SEQAUX.ASC. If you use a different name, you will need to edit %G1GTX%\bin\MAKEAUX.BAT and change the filename. Note, if GeoTAX is reinstalled, this change will be lost.

Position Field Name Description Length

Input Key Area (Must be unique)

1-5 G1GTAUX-ZIP-CODE ZIP Code. 5

6-35 G1GTAUX-STREET-NAME Street name. 30

36-39 G1GTAUX-STREET-TYPE Street type. 4

40-41 G1GTAUX-PRE-DIR Pre-directional. 2

42-43 G1GTAUX-POST-DIR Post-directional. 2

44-47 G1GTAUX-SEQ Sequence number. Range is 0001 - 9999. When there is a change in the data in columns 1-43, the sequence number should restart at 0001.

4

Output Area

48-58 G1GTAUX-OUTPUT-RANGE-FROM

First number in the house number range (right adjusted, blank-filled).

11

59-69 G1GTAUX-OUTPUT-RANGE-TO Last number in the house number range (right adjusted, blank-filled).

11

70 G1GTAUX-OUTPUT-ODD-EVEN Odd/Even switch.

O Odd

E Even

1

71 G1GTAUX-OUTPUT-ASC-DESC Ascending or descending order.

A Ascending

D Descending

1

72 Reserved

73-74 G1GTAUX-STATE-CODE FIPS State code. 2

75-77 G1GTAUX-COUNTY-CODE FIPS County code. 3

78-83 G1GTAUX-CENSUS-TRACT 6-digit Census Tract number. 6

84 G1GTAUX-BLOCK-GROUP 1-digit Block Group. 1

85-92 Reserved 8


To complete the remaining steps necessary to match to the User Auxiliary, see “User Auxiliary File” on page 31.

93-94 G1GTAUX-STATE-ABBV USPS state abbreviation. 2

95-119 G1GTAUX-COUNTY-NAME County name. 25

120-124 G1GTAUX-MCD-CODE 5-digit MCD code. 5

125-164 G1GTAUX-MCD-NAME MCD name. 40

165-168 G1GTAUX-MSA-CODE 4-digit MSA Code. 4

169-218 G1GTAUX-MSA-NAME MSA Name. 50

219-223 G1GTAUX-PLACE-CODE 5-digit Place Code. 5

224-263 G1GTAUX-PLACE-NAME Place name. 40

264-265 G1GTAUX-PLACE-CLASS-CODE 2-digit Place Class Code 2

266 G1GTAUX-PLACE-INC-FLAG Place incorporation flag:

0 Unincorporated

1 Incorporated

1

267-273 G1GTAUX-PLACE-LASTANNEXED

Place last annexed date, in the format MM/YYYY.

7

274-280 G1GTAUX-PLACE-LASTUPDATED

Place last updated date, in the format MM/YYYY.

7

281-287 G1GTAUX-LASTVERIFIED Place last verified date, in the format MM/YYYY.

7

288-296 G1GTAUX-PLACE-GNIS GNIS code. 9

297-500 Reserved 204

501-800 G1GTAUX-AUX-AREA User-defined data. 300

Position Field Name Description Length

H -Concepts in Geography

In this appendix

This appendix describes geographic and geocoding concepts to help lend an understanding of the features and functions provided in GeoTAX.

Overview of the Geographic Systems 292Census Geography 292Postal Geography 298Latitude and Longitude 300


Overview of the Geographic SystemsIn order to provide you with the most accurate, stable, and useful geographic information for your marketing efforts, GeoTAX marries the following standard systems for identifying geographic areas.

• Political Geography — Comprises the major governmental boundaries. Political areas include the states, counties, minor civil divisions, and more. For the purposes of this overview, states and counties of the United States are the only political areas we address.

• Census Geography — For computer processing purposes, and to create more useful divisions for the purposes of collecting and reporting demographic data, the Census Bureau provides statistical standards for the geographic division of the United States. These are called Statistical or Census geographic divisions. This census geography is the main resource for appending your addresses with information useful for target-marketing and other demographic marketing strategies.

• Postal Geography — Postal geographic divisions are created by the USPS for the convenience of mail delivery. The fundamental division is the ZIP Code. A ZIP Code represents an area that is serviced by a single Post Office. The need for new Post Offices dictates the creation and alteration of postal zones. They are therefore unconcerned with governmental or demographic unity (unlike statistical geographic divisions). They are, however, very specific at the ZIP+4 level, often reducing the geographic area to a single city block, a single building, or even a single suite in a building.

Census GeographyCensus geography, like other geographic systems, is a system of tracking and sectoring the United States. Census geography is nothing more than a series of building blocks. Just as ZIP+4 Codes constitute 5-digit ZIP Codes in postal geography, individual blocks make up groups of blocks (Block Groups) that build census tracts, and so on in census geography. However, census geography has a greater number of hierarchical levels than postal


geography. These levels range from the national (i.e., the United States of America) to small-area (i.e., the size of a city block). The following is the basic census geographic hierarchy:

In 2010, the Census Bureau conducted its 202nd survey of the American population. Every housing unit in the country received questions about its sex, race, age, and housing information such as the number of rooms, value of home or monthly rent, and tenure (amount of time owned or rented).

All of the information collected including population and housing statistics, is available to you. The Census Bureau, however, reports all of this information according to its own system of census geography.

Small-Area Geography

GeoTAX is most useful for identifying small-area geography. Small-area geography denotes the finest levels of the Census geographic units listed in the previous section, ranging from the county (the primary political division of a state) to the block (the smallest statistical region available, generally containing only 18 to 22 households).

Small-area geography was created by the Census Bureau for the purpose of accurate statistical reporting. With this goal in mind, the following have been important considerations in the development of the current census small-area geographic system:

• Designed to have relatively stable boundaries

• Designed to represent smaller populations with greater specificity than other geographic systems

• Originally defined by local committees to reflect some continuity of population characteristics.

Block Groups

United States

Regions of the U.S.

Divisions of the U.S.

States

Counties

Census Tracts/BNAsSmall-Area Census Geography

Alaska/American Native Areas

Places

MCDs/CCDs

Blocks

National-Level Census Geography


For the purposes of this product, there are several major “small-area” units for sectoring the United States:

• County — Divisions within a state

• Metropolitan Statistical Area (MSA) — One or more counties that have a certain level of social and economic interaction with a large population nucleus (such as a city or town).

• Core Based Statistical Area (CBSA) — The county or counties or equivalent entities associated with at least one core (urbanized area or urban cluster) of at least 10,000 population, plus adjacent counties having a high degree of social and economic integration with the core as measured through commuting ties with the counties associated with the core.

• Places — A geographic area defined on the basis of population criteria that vary by state. Or, an area recognized as significant because it is located in an incorporated municipality. Places are mutually exclusive.

• Minor Civil Divisions (MCDs)/Census County Divisions (CCDs) — Primary sub-county political or administrative divisions

• Census Tract/Block Numbering Area (BNA) — Divisions of a county

• Block Group — Further divisions of the census tract/BNA.

Each of the small-area units listed above is described in more detail on the following pages.

Counties

Most states refer to their primary political and administrative subdivisions as counties. However, there are several exceptions. For example, in Louisiana, such divisions are called parishes, and in Alaska they are called boroughs and census areas. For the purposes of this product (and the Census Bureau), parishes, boroughs, census areas, and towns (in New England) are all treated as counties. Additionally, several cities in the United States (Baltimore, Saint Louis, Carson City, and the independent cities of Virginia) are independent of counties, and therefore, are treated as county equivalents. Other exceptions include the District of Columbia, which is treated as both a state and a county.

For census purposes, the county is the primary geographic division for small area geography. Counties provide a non-overlapping set of boundaries covering the entire landscape of the nation that can effectively be subdivided into census tracts, block groups, and ultimately, blocks.


Metropolitan Statistical Areas (MSA)

A Metropolitan Statistical Area (MSA) is a county or group of counties that also has a central city of at least 50,000 inhabitants. Contiguous counties are included in the metropolitan statistical area if they have a certain level of social and economic interaction with the population nucleus. In the figure, Byzantium represents a one-county MSA for the city of Shaney.

MSAs, unlike counties and their equivalent, do not cover the entire geography of the United States. MSAs are reserved for densely populated regions only. Moreover, they often overlap state boundaries. For example, the MSA for the Washington D.C. area comprises parts of three states (or state equivalents) — Maryland, Virginia, and D.C.

Although MSAs, where they exist, often overlap state boundaries, they are nevertheless faithful to county boundaries; and where MSAs don't exist, counties still function as the primary division of small area geography.

Core Based Statistical Areas (CBSA)

A Core Based Statistical Area (CBSA) is a U.S. geographic area defined by the Office of Management and Budget (OMB) based around an urban center of at least 10,000 people and adjacent areas that are socioeconomically tied to the urban center by commuting. The term "CBSA" refers collectively to both metropolitan statistical areas and micropolitan areas. Micropolitan areas are based around Census Bureau-defined urban clusters of at least 10,000 and fewer than 50,000 people.

Census Tracts

The Census Tract is a small statistical subdivision of a county, established by the Census Bureau, and designed to be relatively homogeneous with respect to population characteristics, economic status, and living conditions. Census Tracts generally have stable boundaries, and average 4000 residents (the range is generally between 1500 and 8000). Census Tracts are defined for all MSAs (and some non-metropolitan areas where there are no block numbering areas). They do not overlap and they never cross county or state boundaries. For example, the figure depicts a complete census tract (#102300) within a single county/MSA.

CHESTERCOUNTY

MARY BEANCOUNTY

TRUIDCOUNTY

RIVERDALECOUNTY PAULINE BAY

WYATTCOUNTY

2ND

AV

E

3RD

AV

E

4TH

AV

E

5TH

AV

E

6TH

AV

E7T

HA

VE

8TH

AV

E

M ST

N ST

R ST

O ST

P ST

Q ST

S ST

PALLID

PKWY

CONDOR

ST

LOGONCIR

P ST

Q ST

VISION DR

RIV

ERR

D

BARON RD

TRIAD RD

DES

TIN

Y

DR

RAPIER RD

SWORD CT

SHIELD CT

TRU

THRD

CR

ASS

RD

INSERTDR


In the past, the Census Bureau also compiled small area statistics in rural locations for what they called Block Numbering Areas, or BNAs. For Census 2000, all BNAs were replaced by Census Tracts, which may or may not represent the same areas.

Block Groups

All census tracts are subdivided into smaller geographic regions called block groups. The block group is, as the name suggests, a cluster of census blocks (the smallest area for which the Census Bureau provides data) that combine to form a census tract. Block groups never cross boundaries of states, counties, or statistically equivalent entities, except for Block Groups delineated by American Indian tribal authorities. Block groups never cross the boundaries of census tracts, but may cross the boundary of any other geographic entity required as a census block boundary. Block groups generally contain between 600 and 3,000 people, with an optimum size of 1,500 people. Block groups on American Indian reservations, off-reservation trust lands, and special places must contain a minimum of 300 people.

Block groups have 1-digit codes (0-9) that reflect the first digit of the 3-digit identifiers of the blocks they contain. For example, the figure contains a block group including the blocks #501-512.

Note: The Census Bureau may suppress statistics on the block group level if the number of respondents is too small, in order to protect the privacy of individuals.

Minor Civil Divisions/Census County Divisions

Minor Civil Divisions (MCDs) are the primary political or administrative divisions of a county, representing many kinds of legal entities with a variety of governmental and administrative functions. Census County Divisions (CCDs) are established in states where there are no legally established MCDs.

The Census Bureau recognizes MCDs in 29 states and has established CCDs in 20 states. The District of Columbia has no primary divisions, and the city of Washington, DC is considered equivalent to an MCD for data presentation purposes. Arlington County, VA also has no MCDs and the entire county is designated as an MCD with the name Arlington. The following table lists states have MCDs and CCDs.

TRIAD RD

BARON RD

CRA

SSRD

502

501

512511

510

509

508507

506

505504

503

State MCD CCD State MCD CCD

Alabama X Nebraska X

Arizona X Nevada X

Arkansas X New Hampshire X


California X New Jersey X

Colorado X New Mexico X

Connecticut X New York X

Delaware X North Carolina X

Florida X North Dakota X

Georgia X Ohio X

Hawaii X Oklahoma X

Idaho X Oregon X

Illinois X Pennsylvania X

Indiana X Rhode Island X

Iowa X South Carolina X

Kansas X South Dakota X

Kentucky X Tennessee X

Louisiana X Texas X

Maine X Utah X

Maryland X Vermont X

Massachusetts X Virginia X

Michigan X West Virginia X

Minnesota X Wisconsin X

Mississippi X Washington X

Missouri X Wyoming X

Montana X

State MCD CCD State MCD CCD


Postal GeographyThe United States Postal Service has its own system for sectoring the United States. This system is more familiar to most people because it is based on codes we use much more frequently — ZIP Codes and ZIP+4 Codes. The geographic characteristics of these codes, and how they relate to census geography, are discussed in the following sections.

CHESTERCOUNTY

MARY BEANCOUNTY

TRUIDCOUNTY

RIVERDALECOUNTY PAULINE BAY

WYATTCOUNTY

Core Based Statistical Area (CBSA)

• An urban area (“core”) of at least 10,000 people plus its adjacent areas which are socioeconomically-related.

• Example: The city of Shaney, and the Byzantium and Chester counties comprise a CBSA.

Metropolitan Statistical Area (MSA)

• Consists of one or more counties.

• Includes a large city or other population nucleus.

• Example: Byzantium is a 1-county MSA including the city of Shaney.

Centrus Tract

• A non-overlapping subdivision of an MSA and/or county

• A small, homogeneous, relatively permanent area.

• Average population is 4000.

Block Group

• A non-overlapping subdivision of a census tract.

• Smallest statistical area for the purposes of this product.

• Average population is 650.

2ND

AV

E

3RD

AV

E

4TH

AV

E

5TH

AV

E

6TH

AV

E7T

HA

VE

8TH

AV

E

M ST

N ST

R ST

O ST

P ST

Q ST

S ST

PALLID

PKWY

CONDOR

ST

LOGONCIR

P ST

Q ST

VISION DR

RIV

ERR

D

BARON RD

TRIAD RD

DES

TIN

Y

DR

RAPIER RD

SWORD CT

SHIELD CT

TRU

THRD

CR

ASS

RD

INSERTDR


ZIP Codes

The ZIP Code is the primary postal division of the United States, established by the United States Postal Service (USPS) for the purpose of efficiently delivering the mail. Each ZIP Code represents the geographic area-of-delivery of a single Post Office. For this reason, ZIP Codes are assigned without regard for the make-up and size of the populations they serve. ZIP Codes, in general, are relatively large units (they are generally larger than census tracts). For example, the average population of a ZIP-level postal zone is six or seven thousand people; although single ZIP Codes with as many as a hundred thousand residents are not unusual. Also, these zones are relatively unstable, as they are frequently altered by the USPS to accommodate population changes, the convenience of mail carriers, and any considerations that will make mail delivery more efficient and effective.

The considerations in creating postal zones are, naturally, often contrary to the creation of census areas, and therefore, ZIP Code boundaries generally don't correspond to the census geographic boundaries, and in fact, often overlap counties, census tracts, and sometimes even states.

ZIP+4 Codes

The ZIP+4 Code is a recent innovation (introduced in late 1983) designed to direct mail to a more specific locality than the 5-digit ZIP Code provides. Essentially, the ZIP+4 Code is a subdivision of the ZIP Code geographic area.

In metropolitan areas, a ZIP+4 Code is normally assigned to each side of a street, between intersections — this is also called the block front. In addition, ZIP+4 Codes are often assigned to a single PO Box or a group of PO Boxes, to a single building, to a single apartment or a range of apartments, or to a single firm, when the volume of mail warrants such an assignment. Every mailable address in the country is assigned to at least one ZIP+4 Code. And sometimes there is both a block-face and a building code, with or without a firm code, all available to an address. In this case, all are correct, but one is finer (smaller and more specific) than the others.

In non-metropolitan areas, boundaries for ZIP+4 Codes are not always so clearly defined. Nevertheless, they still are smaller subdivisions of a 5-digit postal zone and represent a great deal of geographic specificity useful for cross-referencing census geography.


Latitude and LongitudeLatitude and longitude are used for the purposes of navigation and, more importantly to this product, for computing distances between geographic points. Rather than associating specific codes with specific points on the earth's surface, the latitude/longitude scheme is a system for applying a grid to the surface of the earth, so that any point may be identified via two coordinates: latitude and longitude.

Latitude

Latitude is a measure of a point's distance from the equator, measured in degrees. It will always consist of a number from zero (on the equator) to 90 (the North or South Pole), and an associated direction (north or south of the equator).

Longitude

1021

1014 1034

1011 1031

1001

1032

1012

1002

1 022

1033

1043

1053

1023

MAIN STREETE

. BID

DL

E S

TR

EE

T

ZIP+4 of a Block Front

ZIP+4 of a Building Front

ZIP+4 of an apartmenwithin a building

Figure 4: ZIP+4 Codes for Urban Area Cross Section

Equator


Longitude is a measure of a point's distance east or west of a standard reference point, which was established by international agreement: Greenwich, England. The lines of longitude are great circles that pass through both poles, and are perpendicular to the equator. These lines are frequently referred to as “meridians” of longitude. A longitude measure consists of a number from zero (on the meridian of Greenwich) to 180 (on the International Date Line) and a direction (east or west of Greenwich).

Block Group, Census Tract Area Centers and the Center of Population for ZIP Codes

With the street information provided in GeoTAX, you may request an address level latitude/longitude coordinate return. For ZIP+4 and ZIP-level data, the latitude/longitude pairs returned by GeoTAX reflect the center of population of the ZIP or ZIP+4 Code. For block groups and census tracts, the centers are determined based on area rather than population. For example, the population center of the rural block group in the figure is well south of what would be considered the area center. This would indicate that the most populated region of this area is in the southwest corner (most likely because of the nearby town of Hapsburg). This distinction is significant for distance calculations, especially in rural areas where the geographic areas are much larger.

Note: No latitude/longitude coordinate are returned if the input ZIP Code does not appear on any of the database files.

Calculating Distance

Latitude and longitude are essentially tools for navigation, but they are also useful for calculating distances across the earth's surface. GeoTAX takes any two latitude/longitude coordinates and, using a mathematical algorithm, calculates the distance between them. The distance calculated is a straight line between the two points, taking into consideration the curvature of the Earth's surface.

Meridian

613 603

547

333

11

400

619

11

SCH

RYD

ERC

REEK

HAPSBURG

WILEY RIVER

601

625

Area CenterPopulation Center


Glossary

A

address elements

The components of a street address, including house number, prefix direction, street name, street type, and postfix direction. These elements are parsed by GeoTAX and should not be entered separately.

address geocoding

See geocode, geocoding.

address standardization

Address standardization is the process of taking an address and verifying that each component meets U.S. Postal Service guidelines for addresses. For example, when properly abbreviated, “123 Main Avenue” appears as “123 Main Ave.” During standardization, minor misspellings, dropped address elements, and abbreviations are corrected and the correct city, state, and ZIP Code are provided.

alias

A recognized alternate for a street name maintained by association in the database.

alias information

Data returned with certain enums when it exists. Not returned by all enums even if specifically requested.

alternate record

Additional or differing information that may be available about a specific address but that differs from the base record. See the enums table for necessary flag settings.

B

base record

The principle, rather than an alternate, record within the database.

block assignments (or blockface)

For the assignment of ZIP+4 codes, one side of a street, from one intersection to the next.

C

CASS

Coding Accuracy Support System. A service offered to mailers, service bureaus, and software vendors that improves the accuracy of delivery point codes, ZIP+4 codes, 5-digit ZIP Codes, and carrier route information on mail. CASS provides a common platform to measure the quality of address matching software and useful diagnostics to correct software problems.

CBSA

Core Based Statistical Area. A statistical geographic entity consisting of the county or counties associated with at least one core (urbanized area or urban cluster) of at least 10,000 population, plus adjacent counties having a high degree of social and economic integration with the core as measured through commuting ties with the counties containing the core. Metropolitan and Micropolitan Statistical Areas are the two categories of CBSAs.

CBSA Division

A subdivision of CBSA.

Census block ID

The 15-digit identification number used to specify a particular aggregate or block of addresses associated through census processes.

Census FIPS Code/Census ID

See FIPS code.

centroid

The calculated center of an area. The coordinates that define a centroid are the average of the sets of coordinates that describe the area.

centroid match

An address that has, through geocoding, been found to match a defined geocentroid.

city state key

A six-character USPS key that uniquely identifies a city name in the city/state file. Each city has a unique city state key.

city state name facility code

The character (A-G, K, M, N, P, S, or U) that specifies the type of postal facility.

CMSA name, CMSA number

Consolidated Metropolitan Statistical Area. The name represents the largest city in a statistical area. The number represents a 4-digit FIPS code.

Glossary


County

The primary legal division of every state except Alaska and Louisiana. A number of geographic entities are not legally designated as a county, but are recognized by the U.S. Census Bureau as equivalent to a county for data presentation purposes. These include the boroughs, city and boroughs, municipality, and census areas in Alaska; parishes in Louisiana; and cities that are independent of any county in Maryland, Missouri, Nevada, and Virginia. They also include the municipios in Puerto Rico, districts and islands in American Samoa, municipalities in the Northern Mariana Islands, and islands in the United States Virgin Islands. Because they contain no primary legal divisions, the Census Bureau treats the District of Columbia and Guam each as equivalent to a county (as well as equivalent to a state) for data presentation purposes. In American Samoa, a county is a minor civil division.

coordinates

See latitude/longitude coordinates.

CSA

Combined Statistical Area. A geographic entity consisting of two or more adjacent Core Based Statistical Areas (CBSAs) with employment interchange measures of at least 15. Pairs of CBSAs with employment interchange measures of at least 25 combine automatically. Pairs of CBSAs with employment interchange measures of at least 15, but less than 25, may combine if local opinion in both areas favors combination.

D

datum

A mathematical model of the Earth used to calculate the coordinates on any map, chart, or survey system. Surveyors take an ellipsoid model of the Earth and fix it to a base point. The North American Datum (NAD) is the official reference ellipsoid used for the primary geodetic network in North America.

directionals

A geographic address line component that precedes (predirectional) or follows (postdirectional) the street name.

DPC certified

Delivery point code certified. A software or hardware device that meets U.S.P.S. standards for evaluating a properly standardized ZIP+4 code address and determines the correct 2-digit DPC and checkdigit.

F

Finance Area

A Finance Area is an area defined by the U.S. Postal Service from which it collects cost and statistical data. A Finance Area is frequently used for area searches, since it covers some or all of the ZIP Code areas in a town or city.

finance number

An assigned six-digit number that identifies an installation for processing it’s financial data. The first two digits are the state code and the next four are uniquely assigned from 0001 through 9999 to each installation in alphabetical order.

FIPS code

Federal Information Processing Standards code. A FIPS Code, also called a Census ID, uniquely identifies each piece of Census geography. The syntax of the FIPS code is as follows:

ssccctttt.ttgbbb where: ss = the two-digit State Census FIPS Codeccc = the three digit County Census FIPS Codetttt.tt = the 6 digit Census Tract Census FIPS Codeg = the single digit Block Group Census FIPS Codebbb = the Block Census FIPS Code

G

geocode, geocoding

A geocode is the geographic information associated with a unique address or centroid, such as longitude and latitude. Geocoding is the process of assigning data based upon location information. GeoTAX uses an address or ZIP Code to assign latitude, longitude, and Census FIPS information.

GIS

Geographic Information System. A computer-based tool for enhancing geographic data by analyzing both the physical location in space and the set of characteristics associated with a location.

GSD files

GeoTAX directory files.

GsEnums

Enumerated types in the GeoTAX API. These enums are prefixed with “GS_” and are defined in the geotax.h file.

GSU files

GSU files contain information to match addresses based on unique ZIP Code and additional highrise unit information.

Glossary


GSX files

Geographic spatial index. These files are used by spatial functions in GeoTAX.

H

handle

A reference to an object that is required by the Library and is not to be manipulated directly by the developer. The handle is generated when the library is initialized and is required for many library functions.

I

intersection matches

Intersection matches are indicated by an x___ match code. For example, the 28th Street and Valmont intersection may be standardized and geocoded and return demographic information. Intersections do not represent a valid address for mailings.

L

LACS

Locatable Address Conversion System. This system corrects addresses electronically for areas that have undergone permanent address conversions. The address conversion occurred as a result of the 911 system implementation and involves renumbering and renaming rural route and highway contract route information as city-style addresses with street number and name.

lat/lon; latitude/longitude coordinates

Longitude and latitude coordinates are always in degrees, and are always represented as 64-bit doubles. Positive numbers represent the Eastern and Northern hemispheres, respectively, and negative numbers represent the Western and Southern hemispheres. For example, the point 140W by 30N would be represented as –140.0,30.0. The library always assumes that the longitude coordinate is the horizontal direction and the latitude coordinate is the vertical direction. Support is not provided for user coordinates.

location code

Location codes indicate the accuracy of the assigned geocode.

M

mail stop designator

This designator indicates a routing code used by a company for internal mail delivery.

match code

Indicates the portions of the address that matched or did not match with the address information in the GeoTAX data files.

match mode

The algorithm used by GeoTAX to match an input address to an address in the data files.

match rates

The number of input addresses that correspond (can be matched) to address information in data files.

MBR

Minimum bounding rectangle. A geographic region defined by and minimum and maximum latitude and longitude.

Metropolitan Statistical Area

A Core Based Statistical Area associated with at least one urbanized area that has a population of at least 50,000. The Metropolitan Statistical Area comprises the central county or counties containing the core, plus adjacent outlying counties having a high degree of social and economic integration with the central county as measured through commuting.

Micropolitan Statistical Area

A Core Based Statistical Area associated with at least one urban cluster that has a population of at least 10,000, but less than 50,000. The Micropolitan Statistical Area comprises the central county or counties containing the core, plus adjacent outlying counties having a high degree of social and economic integration with the central county as measured through commuting.

MSA name/number

Metropolitan Statistical Area. The name represents the name of the largest central city and the number is the 4-digit FIPS code.

multiple match resolution

The process of resolving an address match when more than one street segment has been identified as corresponding to the input address.

N

NAD

The North American Datum (NAD) is the official reference ellipsoid used for the primary geodetic network in North America.

NAD27

NAD27 has its origin at Meades Ranch, Kansas. NAD27 does not include the Alaskan islands and Hawaii. Latitudes and longitudes that are surveyed in the NAD27 system are valid only in reference to NAD27 and do not tie to any maps outside the U.S.

Glossary


NAD83

NAD83 is earth-centered and defined with satellite and terrestrial data. NAD83 is compatible with the World Geodetic System 1984 (WGS84), the terrestrial reference frame associated with the NAVSTAR Global Positioning System (GPS) now used extensively for navigation and surveying. Note that GDT uses WGS84 instead of NAD83. These two coordinate systems are compatible.

NAVTEQ

A premium vendor of street segment data.

NCSC

National Customer Support Center. The U.S.P.S. CASS support center can be reached at www.usps.gov/ncsc.

O

object

A basic functional unit of a library. A library contains functions that allow the user to create, manipulate, and destroy objects. C programmers access objects through handles that are provided through object creation functions.

P

postdirectional (postdir)

See directionals.

predirectional (predir)

See directionals.

R

record matching algorithm

Programmed logic that allows evaluation of the results of all field matching algorithms to determine whether two records match (i.e., are duplicates).

road class code

A key in the street segment file that identifies a road as major or minor according to the Census Feature Classification Code.

RR

Rural Route. A delivery route served by a rural carrier.

S

soundex algorithm

A type of field matching algorithm that compares two fields based on their pronunciation.

soundex key

Generated by the GsSoundex function. Used to search the database by employing a soundex algorithm.

spatial query functions

Used to extract data from the GSD files. These functions specify the area to be searched through a minimum bounding rectangle rather than through city/state/ZIP or finance area.

street network files

Files provided by vendors (other than U.S.P.S.) the contain address and geocode information.

T

TIGER files

Topographically Integrated Geographic Encoding and Referencing. A digital database of geographic features covering the entire United States.

TLID

TIGER/Line® Identification Number.The TIGER/Line files use a permanent 10-digit TLID to uniquely identify a complete chain for the Nation. The 10-digit TLID will not exceed the value 231-1 (2,147,483,647) and represents the same complete chain in all versions of this file, beginning with the TIGER/Line Precensus Files, 1990. The minimum value is 100,001. Topological changes to the complete chain causes the TLIDs to change. For instance, when updates split an existing complete chain, each of the new parts receives a new TLID; the old TLID is not reused.

As distributed, TIGER/Line files are grouped by county (or statistically equivalent entity). A complete chain representing a segment of the boundary between two neighboring counties may have the same TLID code in both counties or it may have different TLID codes even though the complete chain represents the exact same feature on the ground.

TomTom

A premium data vendor of street segment files.

U

unit designator

Indicates the type of unit (e.g., apartment, unit).

USPS data files

Files provided by the post office containing address and ZIP Code information.

Glossary


Z

ZIP+4 directory file

Address records that contain the ZIP+4 codes for all delivery points, in an electronic form.

ZIP+4 centroid geocoding

See geocoding.

ZIP Code

Zone Improvement Plan Code. Established in 1963 the five-digit numeric code of which the first three digits identify the delivery area of a sectional center facility or a major-city post office serving the delivery address area. The next two (the fourth and fifth) digits identify the delivery area of an associate post office, post office branch, or post office station. All post offices are assigned at least one unique 5-digit code. ZIP Code is a USPS trademark.

ZIP+4 is an enhanced code consisting of the 5-digit ZIP Code and four additional digits that identify a specific range of delivery addresses. The nine-digit numeric code, established in 1981, composed of two parts: (a) The initial code: the first five digits that identify the sectional center facility and delivery area associated with the address, followed by a hyphen; and (b) the four-digit expanded code: the first two additional digits designate the sector and the last two digits designate the segment. ZIP+4 is also a USPS trademark.

Glossary



Index

A

ADDRDF parameter record 88, 198Address elements 57Address location codes 266AEOUT parameter record 88, 199ALOUT parameter record 88, 201APIs

programming language 143UNIX platform considerations 146

ARCOUT parameter record 88, 203automatic confirmation, of records 94AUXOUT parameter record 32, 88, 204

B

Basic 2000 census geographic hierarchy 293BF2OUT parameter record 88, 205Block front

defined 299illustrated 299ZIP + 4 Codes 299

Block Groupscenter of geographic area 301defined 296

BUFOUT parameter record 88, 206

C

C programming language 143Calculating distances

latitude/longitude coordinates 301Callable functions

COBOL Example 113GCP20 113GTMATCH 108GTX10 110, 112GTX15 111overview 108

Calling the GCP20 program 132Calling the GTMATCH program 114CBSOUT parameter record 88, 207Census County Divisions (CCDs)

defined 296Census geography

basic 2000hierarchy 293defined 292introduction 292

Census Tractdefined 295

Class CodesC1 278C2 278C3 278C4 278C5 278C6 278

C7 278C8 279C9 279definitions 278U1 279U2 279U3 279U4 279U5 279U6 279U8 279U9 279

Class Codes, defined 245CNFOUT parameter record 88, 209Codes

Address location 266Location 265Match 263Street centroid location 269ZIP+4 centroid location 269

CONFIG parameter record 32, 37, 89, 210CONFRM parameter record 89, 214CONSxx parameter record 88, 215CONTRL parameter record 40Copying the IVP file 89Counties

defined 294Cross-Sectional sampling with FILEDF 220CS ZIP parameter record 88, 216

D

Database environment variableDD_G1GTAUX 145DD_G1GTAX2 145DD_G1GTGSD 145DD_G1GTGSN 145DD_G1GTGST 145DD_G1GTPTC 145DD_G1GTSSD 145DD_G1GTSSN 145DD_G1GTSST 145DD_GTGSPAS 145DD_GTMASTR 145DD_GTMSTR2 145DD_GTTAXRT 145DD_GTTAXW 145GTBDCOU 145GTBDIPD 145GTBDPAY 145GTBDPLC 145GTBDPTD 145GTBDSPD 145GTBDUSR 145GTGCNTY 145GTGSADR 145GTGSLIC 145GTGSZP4 145

Index


GTZ5GSB 145DD_G1GTAUX 145DD_G1GTAX2 145DD_G1GTGSD 145DD_G1GTGSN 145DD_G1GTGST 145DD_G1GTPTC 145DD_G1GTSSN 145DD_G1GTSST 145DD_GTGSPAS 145DD_GTMASTR 145DD_GTMSTR2 145DD_GTTAXRT 145DD_GTTAXW 145Defining input files

in batch job 91Defining output files

in batch job 92Defining processing options

in batch job 94Defining reporting options

in batch job 95DISTIT parameter record 88, 217DSIIN input parameter area

GCP20 program 133DSOOUT input parameter area

GCP20 program 133, 136

E

Error conditions, determining cause 260Exit routines with FILEDF 220EXITOP (GTX50) parameter record 218

F

FILEDF parameter record 88, 91, 219Finance area 58Firm Name 57FIRMNM parameter record 88First hex position 264Function Calls 148

G

GCAADT Audit Parameter AreaGCP10 program 130

GCP10 programGCAADT audit parameter area 130

GCP20 programcalling 132DSIIN input parameter area 133DSOOUT output parameter area 133, 136illustrated 113

GEOOUT parameter record 88, 225GeoTAX

batch system 86

GeoTAX Auxiliary File 33–34building 33

on Unix 33on Windows 33

matchingCONFIG parameter record setting 34

GeoTAX Keyin PCOUT parameter record 247

GeoTAX overview 9GeoTAX Programs

Database info program GTDBINFO 108Distance calculator GCP20 108Exit routine GTX50 108Matcher GTMATCH 108

GetGeoCountyName 150, 192GetGeoDistance 150, 192

code example 151, 192input structure 150, 192output structure 151, 192parameters 150, 192syntax 150, 192

GetGeoMCD 163GetGTXCensusBlockGrp 152

code example 152input structure 152output structure 152parameters 152syntax 152

GetGTXCensusTract 153code example 153input structure 153output structure 153parameters 153syntax 153

GetGTXCountyFIPS 154code example 154input structure 154output structure 154parameters 154syntax 154

GetGTXCountyName 155code example 155input structure 155output structure 155parameters 155syntax 155

GetGTXDBVer 157code example 157input/output structure 157syntax 157

GetGTXKey 158code example 158input structure 158parameters 158syntax 158

GetGTXLatitude 159code example 159input structure 159output structure 159

Index


parameters 159syntax 159

GetGTXLatLong 160code example 161input structure 160output structure 161parameters 160syntax 160

GetGTXLongitude 162code example 162input structure 162output structure 162parameters 162syntax 162

GetGTXMCD 163code example 163input structure 163output structure 163parameters 163syntax 163

GetGTXMCDName 164code example 165input structure 164output structure 165parameters 164syntax 164

GetGTXPlaceCode 165code example 166input structure 166output structure 166parameters 165syntax 165

GetGTXPlaceName 167input structure 167output structure 167parameters 167syntax 167

GetGtxPlaceNamecode example 167

GetGTXState 168code example 168input structure 168output structure 168parameters 168syntax 168

GetGTXStateFIPS 169code example 169input structure 169output structure 169parameters 169syntax 169

GetGTXSWVer 170code example 170input/output structure 170syntax 170

GTBDCOU 145GTBDIPD 145GTBDPAY 145GTBDPLC 145

GTBDPTD 145GTBDSPD 145GTBDUSR 145GTBM00 86GTBMARC 88GTBMARC output file, and ARCOUT 203GTBMPRM 91GTGCNTY 145GTGSADR 145GTGSLIC 145GTGSZP4 145GTMATCH 13GTMATCH program

description 108Matcher control area 115

GTX10 programdescription 110



GTXLOAD1 40GTXLOAD2 40GTXLookup 171

code example 172input structure 171output structure 172syntax 171

GTXMatchAddress 173code example 190input structure 174output structure 180parameters 173syntax 173

GTZ5GSB 145

H

HEADER parameter record 89, 96, 229

I

Input file GTBMNAM 91Input file GTBMPRM 91Input record array 240Integrator Series

defined 143Interactive system

introduction to 100IPDOUT parameter record 230IPROUT parameter record 88, 231

J

JAMS report 95

Index


L

Last Line 57Latitude

definition of 300illustrated 300

LATLON parameter record 88LLOUT parameter record 88, 235Location codes 265

Address 266Street centroid 269ZIP+4 centroid 269

Longitudedefinition of 301illustrated 301

M

Match codes 263MCDOUT parameter record 88, 239Metropolitan Statistical Areas (MSAs)

definition of 295Minor Civil Divisions (MCDs)

definition of 296MOVE I parameter record 88, 239MOVE O parameter record 88, 241

O

Output file GTBMARC 91Output file GTBMCOK 91Output file GTBMNCO 91Output file GTBMPLC 91Output record array 241

P

PAGESZ parameter record 89, 242Parameter record list

ADDRDF parameter record 198, 199, 201AEOUT parameter record 199ALOUT parameter record 201ARCOUT parameter record 203AUXOUT parameter record 32, 204BUFOUT parameter record 206CBSOUT parameter record 207CNFOUT parameter record 209CONFIG parameter record 32, 210CONFRM parameter record 214CONSxx parameter record 215CS ZIP parameter record 216DISTIT parameter record 217EXITOP (GTX50) parameter record 218FILEDF parameter record 219FIRMNM parameter record 224GEOOUT parameter record 205, 225

HEADER parameter record 229IPDOUT parameter record 230IPROUT parameter record 231LATLON parameter record 234LLOUT parameter record 235MCDOUT parameter record 239MOVE I parameter record 239MOVE O parameter record 241PAGESZ parameter record 242PAYOUT parameter record 243PCOUT parameter record 245PTCOUT parameter record 247PTDOUT parameter record 249REPORT parameter record 250SPDOUT parameter record 251, 253STEOUT parameter record 252TESTIT parameter record 255UFTxx parameter record 255, 257UHDxx parameter record 256

PAYOUT parameter record 88, 243PCOUT parameter record 88, 245PDOUT parameter record 88Pitney Bowes Software Sales and Use Tax Rate File38–39

loading 38on Unix 38on Windows 38

matching with 39SPDOUT parameter record 39TAXOUT parameter record 39

Place Class Codes 245Political Geography 292Postal geography

Introduction 292ZIP and ZIP + 4 Codes 298

programming language 143PTCOUT parameter record 88, 247PTDOUT parameter record 88, 249

R

Rearrange output fieldsMOVE O parameter record 241

REPORT parameter record 89, 95, 250Reports

Coding Percentages per State 95Coding Percentages per State/County 95Control Totals 95Execution Log 95headers and footers 96Jurisdictional Accuracy Management System

(JAMS) Report 95Parameter Record Listing 95

S

Second hex position 264

Index


Setting a search area 59Setting up a search area

MCA-SEARCH-AREA-OPT 116MCA-SEARCH-RADIUS 116

Small-area geography 293SPDOUT parameter record 88, 251, 253Standard Return Values 147State-Supplied Files 35–37

building the Florida-native databaseon Unix 35

building the TS-158 databaseon Unix 36

downloadingFlorida-native formatted files 35TS-158 formatted files 36

matching with 37CONFIG setting 37getting additional data using STEOUT 37

supported formats 35Statistical geographic divisions

census geography 292STEOUT parameter record 37, 88, 252Street Address Line 57Street centroid location codes 269Street-based matcher, description of 9

T

Tax Jurisdiction Assignment 8TAXOUT parameter record 39, 88Temporary work area 240, 241TESTIT parameter record 89, 255Third hex position 264TIGER files, U.S. Census Bureau 8

U

UFTxx parameter record 89, 96, 255UHDxx parameter record 89, 96, 256Unix Environmental Considerations 146Unix platform

installing GeoTAX 18User Auxiliary File 31–32

creating 30, 31file layout 289on Unix 31sample file SEQAUX 289

matching withCONFIG parameter record setting 32

posting user-defined dataAUXOUT parameter record setting 32

USROUT parameter record 88, 257

V

Vertex cross-reference file 40creating

generation options 40GTMASTR 40optional parameters 40required parameters 40

W

Windows platforminstalling GeoTAX 18

Z

ZIP + 4 Codesdefinition of 299

ZIP Codesdefinition of 299

One Global ViewTroy, NY 12180-8399USA

www.pitneybowes.com

Support: +1 (800) 367-6950Main: +1 (518) 285-6000Fax: +1 (518) 285-7060

©2016 Pitney BowesAll Rights Reserved

http://www.pitneybowes.com

Date post:	23-Apr-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

GeoTAX® Premium User's Guide - Pitney Bowes...Taxware Files 44 Boundary Files 45 Payroll Tax...

Documents