Using Custom Address Styles

• Introduction
• What Are Address Styles?
• Implementing a Custom Address Style
• Elements of the ArcIMS Style File
• Example ArcIMS Style File

Introduction

Note: Detailed descriptions of the standard geocoding rules and general geocoding principles can be found in the Geocoding Developer's Kit available from ESRI.

Geocoding is the process of identifying the coordinates of a location given its address. This document explains how to implement a custom address style in ArcIMS and provides a reference to the ArcXML elements that compose an ArcIMS style file.

This document assumes an understanding of geocoding; a working knowledge of ArcIMS, specifically how to publish ArcIMS services; and experience with creating custom address styles.

In this document, you are introduced to:

• Steps to implement custom address styles into ArcIMS
• The format and elements of the ArcIMS style file
• An example of an ArcIMS style file

What Are Address Styles?

ArcIMS has 10 standard address styles. Each address style consists of a list of address components that reference a layer's attribute table. Each style has optional and required address components. The required components need to be filled with a data field from the attribute table. Each address style contains a list of preferred field names for each component. Using the preferred field names, ArcIMS will determine a probable field from the attribute table for each component.

Each address style consists of a set of standard files such as *.stn, *.dct, *.cls, and *.mat. In addition to these files, ArcIMS uses additional style files with *.stl and *.st_ extensions. The ArcIMS style files are composed of XML-compliant elements written in ArcXML that contain geocoding settings specific to ArcIMS.

The address styles available with ArcIMS are:

• U.S. addresses without zone information address style (USAddress.stl)
• U.S. addresses with zone information address style (USAddressZ.stl)
• U.S. single house address style (USSingleHouse.stl)
• U.S. single house with zone address style (USSingleHouseZ.stl)
• U.S. single range address style (USSingleRange.stl)
• U.S. single range with zone address style (USSingleRangeZ.stl)
• ZIP+4 address style (Zip4.stl)
• ZIP+4 range address style (Zip4Range.stl)
• 5-digit ZIP address style (Zip5.stl)
• Single field address style (SingleField.stl)

If the standard address styles do not meet your needs, the following pages provide the steps for integrating a new style file into ArcIMS. The reference elements and example can be used as a guide for creating the *.stl and *.st_ files.

Implementing a Custom Address Style

These steps assume:

• The standard address style files for the custom style have been created. Refer to the Geocoding Developer's Kit for information regarding the files that compose an address style.
• The ArcIMS style files (*.stl and *.st_ ) have been created. The *.st_ file is necessary if you want the custom style to support street intersection geocoding. You can create a *.st_ file or, depending on your needs, use the ArcIMS USStreetInts.st_ file.

The following pages offer a complete reference to the elements of the *.stl file. The final pages offer an example of a *.stl file as implemented for address matching using a German dataset.

1. Copy all of the address style files to the \Server\ext\GeocodeServer\Styles and \IndexBuilder\Styles directories. If you have already implemented the custom address style in ArcView 3.x, you can copy all the files from the \geocode directory into the two ArcIMS Styles folders.
2. Copy the ArcIMS style file (*.stl and *.st_) to the \Server\ext\GeocodeServer\Styles and \IndexBuilder\Styles directories.
3. Locate the esri_mo10res.jar file. The ArcIMS installation puts the esri_mo10res.jar file in the JRE's lib\ext directory. The default location for the JRE is C:\Program Files\JavaSoft\JRE\1.3\lib\ext.
4. Unzip the contents of the esri_mo10res.jar file to an empty directory. In this example, c:\temp is used. After extracting, you will have two subdirectories: com and meta-inf.
5. Create a properties file for the custom address style. The naming convention for the file should be .properties, for example, Germanaddress.properties.
   
   Navigate to the com\esri\mo\res\props directory. This directory contains property files for the styles already supported by ArcIMS such as USAddressZ.properties and Zip4.properties.
   
   To create the new properties file:
   • Get the information for the content from the ArcIMS style file.
   • Use the available property files as a guideline for format of the content.
6. Open the c:\temp\com\esri\mo\res\props\GeoCodeStyles.properties file in a text editor and add a listing for your address style. The following shows what the GeoCodeStyles.properties file looks like with additions for German Addresses and German Addresses with Zone address styles.
   
   

   # GeoCodeStyles.properties # entries must have the form # N: Property name, Property label, PropertyResourcePathname # where "N" must be an integer, and must be unique across entries, but can be in any order. # "Property name" is a simple name that must not contain blanks or "," # "Property label" is a user interface label # "PropertyResourcePathname" is a fully-qualified resource name that must not contain a "," 1: USAddressZ, US Streets with Zone, /com/esri/aims/resources/sdk/propsUSAddressZ.properties 2: USAddress, US Streets, /com/esri/aims/resources/sdk/propsUSAddress.properties 9: Zip5, ZIP 5-Digit, /com/esri/aims/resources/sdk/propsZip5.properties 10: SingleField, Single Field, /com/esri/aims/resources/sdk/propsSingleField.properties 6: USSingleHouse, US Single House, /com/esri/aims/resources/sdk/propsUSSingleHouse.properties 5: USSingleHouseZ, US Single House with Zone, /com/esri/aims/resources/sdk/propsUSSingleHouseZ.properties 4: USSingleRange, US Single Range, /com/esri/aims/resources/sdk/propsUSSingleRange.properties 3: USSingleRangeZ, US Single Range with Zone, /com/esri/aims/resources/sdk/propsUSSingleRangeZ.properties 7: Zip4, ZIP+4, /com/esri/aims/resources/sdk/propsZip4.properties 8: Zip4Range, ZIP+4 Range, /com/esri/aims/resources/sdk/propsZip4Range.properties 11: GermanAddress, German Addresses, /com/esri/aims/resources/sdk/propsGermanAddress.properties 12: GermanAddressZ, German Addresses with Zone, /com/esri/aims/resources/sdk/propsGermanAddressZ.properties

   
   
7. Zip the contents of the c:\temp directory into a new esri_mo10res.jar file. Remove the original version of esri_mo10res.jar from the JRE's lib\ext directory and copy the new version to this location.
8. Stop and restart ArcIMS by following these steps: Stop ArcIMS Monitor and then stop ArcIMS Application Server. Start ArcIMS Application Server and start ArcIMS Monitor.

You can now use this address style when setting geocoding properties in ArcIMS Author. See chapter 3 in Using ArcIMS for details on how to set geocoding properties and build the geocoding index.

Elements of the ArcIMS Style File

The ArcIMS style file (*.stl) is composed of XML-compliant elements written in ArcXML for geocoding settings specific to ArcIMS.

An ArcIMS style file contains a description of a single ArcIMS address style. The style depends on the address style's geocoding rules and contains some information taken from *.dct, *.mat, and *.stn files. In addition to the ArcIMS style file, a *.st_ file is needed for ArcIMS styles that support geocoding of street intersections.

The elements of the style file are described on the following pages. The examples use the USAddressZ.stl and USStreetInts.st_ files. The elements are listed in the order in which they appear in the style file.

GEOSTYLE

Purpose: Root element for the *.stl file.

The two required attributes are name and description.

The value of the name attribute is the name of the *.stl file. The value of the description attribute is a text string describing the address style.

<GEOSTYLE name="USAddressZ" description="US addresses with zone information" >...</GEOSTYLE>

STNCOMMAND

Purpose: Defines the *.stn file used for the style.

The one required attribute is file.

The value of the file attribute is the name of the *.stn file.

<STNCOMMAND file="us_addr.stn" />

MATCHKEY

Purpose: Defines the *.dct file used for the style.

The one required attribute is file.

The value of the file attribute is the name of the *.dct file.

<MATCHKEY file="us_addr.dct" />

MATCHRULES, MATCH

MATCHRULES

Purpose: Defines the *.mat file used for the style.

MATCH

Purpose: Contains a list of matched (mprop) and unmatched (uprop) probabilities defined in the *.mat file.

<MATCHRULES file="us_addr1.mat" >   <MATCH mprob="0.9" uprob="0.01" />   <MATCH mprob="0.9" uprob="0.01" />   <MATCH mprob="0.8" uprob="0.1" />   <MATCH mprob="0.7" uprob="0.1" />   <MATCH mprob="0.85" uprob="0.1" />   <MATCH mprob="0.85" uprob="0.1" />   <MATCH mprob="0.999" uprob="0.05" /> </MATCHRULES>

QUERY

Purpose: Declares the format of the expression used to get potential candidates from the database. The expression is a query that is performed on indexes built for the data by the IndexBuilder.

The stn and zip attributes are index names defined by the INDEXES element (see below). The values of the attributes are names of proper match key fields from the *.dct file defined by the MATCHKEY element. The Geocode Server takes the contents of the fields to form the expression.

<QUERY stn="SN" zone="ZN" />

For example, the input address is "380 New York st 92373". After standardization, the "SN" field of the match key contains "New York" and the "ZN" field contains "92373".

Using the QUERY shown above, the Geocode Server generates the following expression:

stn="New York" & zone="92373"

The indexing functionality of the Geocode Server performs this query and gets all records with field "StreetName" equals "New York" and field "LeftZone" equals "92373" or field "RightZone" equals "92373".

INPUT, TAG, FORMAT, STNSTRING, ADDTAG, MATCHKEYFIELD

INPUT

Purpose: Defines the format of the request sent from the client to the Geocode Server.

The client sends a request to the Geocode Server. The request is parsed and standardized and sent back to the client. In ArcIMS, the client can be ArcExplorer 4, the HTML Viewer, or the Java Standard or Java Custom Viewers.

<INPUT>   <TAG id="STREET" label="Street" width="10" type="text" description="street number, street name and type" />   <TAG id="zone" label="zone" width="5" type="text" description="zne information (5 digits)" />   <FORMAT>     <STNSTRING>       <ADDTAG>STREET</ADDTAG>     </STNSTRING>     <MATCHKEYFIELD zn="zone" />   </FORMAT> </INPUT>

TAG

Purpose: Each TAG defines the format of a single input element that must be used in the request. The id attribute defines the unique identifier of this element. It is also used in the request. The label, width, type, and description attributes contain a description of the element and are used only by the client.

FORMAT

Purpose: Defines how information retrieved from the request is handled.

STNSTRING

Purpose: Defines a list of input elements whose values form the address string for standardization.

ADDTAG

Purpose: Defines the name of a single input element for the STNSTRING element.

MATCHKEYFIELD

Purpose: Defines a list of input elements whose values go directly into match key.

ArcIMS address styles require that addresses be sent in as separate pieces that can be processed in different ways before the whole address is passed for standardization. Each address needs to be standardized before it can be matched. See the Geocoding Developer's Kit for details.

An example of how an address is broken down is a U.S. address that is divided into two parts: STREET and ZONE (usually ZIP Codes). The STREET includes house number, street name, and street type. Only the STREET part needs to be parsed for standardization. The ZONE part is standardized and can be put directly into a match key. The STNSTRING element defines which parts need to be standardized, and the MATCHKEYFIELD element defines which parts can go directly into match key.

The STNSTRING element can have many ADDTAG elements. In this example the address can be divided into four parts: HouseNumber, StreetName, StreetType, and ZONE. The first three parts are concatenated to form the address string for standardization. The following shows what the INPUT element should look like:

<INPUT>   <TAG id="HOUSENUMBER" ... />   <TAG id="STREETNAME" ... />   <TAG id="STREETTYPE" ... />   <TAG id="zone" ... />   <FORMAT>     <STNSTRING>       <ADDTAG>HOUSENUMBER</ADDTAG>       <ADDTAG>STREETNAME</ADDTAG>       <ADDTAG>STREETTYPE</ADDTAG>     </STNSTRING>     <MATCHKEYFIELD zn="zone" />   </FORMAT> </INPUT>

The MATCHKEYFIELD element may have more than one attribute. The name of each attribute is the name of a match key's field defined in the *.dct file. The value of an attribute is equal to the value of id of the corresponding TAG.

In the example above, the MATCHKEYFIELD element is defined as:

<MATCHKEYFIELD zn="zone" />

The MATCHKEYFIELD element can be defined with more than one attribute, for example:

<MATCHKEYFIELD zn="zone" ct="city" st="state" />

The following example shows a request that can be used for a layer associated with the USAddressZ.stl style:

<?xml version="1.0" encoding="UTF-8"?> <ARCXML version="1.1">   <REQUEST>     <GET_GEOCODE maxcandidates="25"  minscore="60">       <LAYER id="streets" />       <ADDRESS>         <GCTAG id="STREET" value="380 New York St" />         <GCTAG id="Zone" value="92373" />         <GCTAG id="CrossStreet" value="" />       </ADDRESS>     </GET_GEOCODE>   </REQUEST>       </ARCXML>

In this example, <GCTAG id="STREET"../> corresponds to INPUT's <TAG id="STREET" .../>, and <GCTAG id="zone" .../> corresponds to <TAG id="zone".../>.

STREET1, STREET2

STREET1

Purpose: Used in INPUT for street intersection style.

STREET2

Purpose: Used in INPUT for street intersection style.

The request in the above example contains three input GCTAG elements, while USAddressZ.stl defines only two. This is because this style may also be used for street intersection geocoding. The third element, CrossStreet, is defined in a street intersection style file, USStreetInts.st_.

The format of the *.st_ file is slightly different from the *.stl file format. The INPUT element for the *.st_ file looks like the following:

<INPUT>   <STREET1 id="STREET" />   <STREET2 id="CROSSSTREET" label="Cross street" width="10" type="text" description="cross street name and type" /> </INPUT>

See the USStreetInts.st_ for more details.

The INPUT element from the *.st_ file always has two predefined child elements: STREET1 and STREET2.

The STREET1 element defines the TAG from the corresponding *.stl file, which is always a "street tag". The STREET2 element defines an additional input element, which will be used to specify the second street for street intersection geocoding. This INPUT element does not need a FORMAT child element because ZIP code is not used for street intersection geocoding.

OUTPUT, PRINTMATCHKEY, PRINTFIELD, SEPARATOR

OUTPUT

Purpose: Defines the format of the response to the client from the Geocode Server.

The client sends a request to the Geocode Server. This request is parsed and standardized, stored in the MATCHKEYFIELD, and sent back to the client.

In this next example, you can see that the MATCHKEYFIELD is printed as part of the output.

<OUTPUT>   <PRINTMATCHKEY>HN</PRINTMATCHKEY>   <PRINTFIELD>PreDir</PRINTFIELD>   <PRINTFIELD>PreType</PRINTFIELD>   <PRINTFIELD>StreetName</PRINTFIELD>   <PRINTFIELD>StreetType</PRINTFIELD>   <PRINTFIELD>SufDir</PRINTFIELD>   <PRINTMATCHKEY>ZN</PRINTMATCHKEY> </OUTPUT>

PRINTMATCHKEY

Purpose: Used in OUTPUT to define output format.

PRINTFIELD

Purpose: Used in OUTPUT to define output format.

SEPARATOR

Purpose: Used in OUTPUT to define output format.

After geocoding, the match candidates are sent back to the client. Each candidate has a:

• score- reflects the accuracy of the candidate
• pinpoint- location of the candidate on the map
• address- information found in the database

OUTPUT defines how the address string looks. The address string's format is defined by:

• The names of the fields for the different parts of the address
• The order in which the parts are concatenated

It may be useful to get some of the parts of the address directly from match key such as house number or ZIP Code.

PRINTFIELD defines the database fields (see FIELDS below). PRINTMATCHKEY defines the match key fields. The order in which these elements are inserted into the OUTPUT element is important because it defines how all the fields will be combined.

If a field listed in OUTPUT is empty, the field is not included in the address string. The next example shows how the OUTPUT element works for the string:

380 NEW YORK ST 92373

• 380 - contents of match key field HN
• <empty> - contents of field with id="PreDir"
• <empty> - contents of field with id="PreType"
• NEW YORK - contents of field with id="StreetName"
• ST - contents of field with id="StreetType"
• <empty> - contents of field with id="SufDir"
• 92373 - contents of match key field ZN

The OUTPUT element can also include SEPARATOR to define a character to insert between the fields. The next example shows OUTPUT from Zip4.stl:

<OUTPUT> <PRINTMATCHKEY>ZP</PRINTMATCHKEY> <SEPARATOR>-</SEPARATOR> <PRINTMATCHKEY>Z4</PRINTMATCHKEY> </OUTPUT>

In this case the output string looks like this: 12345-1234.

The OUTPUT element used in the *.st_ file has a different format than the OUTPUT element for the *.stl file. The result of geocoding a street intersection is a point where two streets intersect. The address string contains information about both streets, usually the street names and types. The OUTPUT element is used to define where to put the delimiter between the first and second streets:

<OUTPUT separator="+" position="42" />

The separator attribute defines a symbol to be used as a delimiter. The value of the separator can be any XML-compliant character.

The position attribute defines where the delimiter is placed. The position value defines the length of the first street's information in the candidate's buffer generated by the Geocode Server. The value depends on how the streets are defined in the corresponding *.mat file. For example, in the us_intsc.mat file the first street information is defined to be 42 characters long.

The table below shows that the first street information includes street name (StreetName1), street type (Type1), and suffix direction (SufDir1). The suffix direction begins at the forty-first position and is two characters long, thus making the first street information 42 characters long.

Variable	Position	Length	Description
VAR PreDir1	1	2	X ; Prefix direction 1
VAR PreType1	3	4	X ; Prefix street type 1
VAR StreetName1	7	28	S ; Street name 1
VAR Type1	35	6	X ; Suffix street type 1
VAR PreDir2	43	2	X ; Prefix direction 1
VAR SufDir1	41	2	X ; Suffix direction 1
VAR PreDir1	1	2	X ; Prefix direction 2
VAR PreType2	45	4	X ; Prefix street type 1
VAR PreDir1	1	2	X ; Prefix street type 2
VAR StreetName2	49	28	S ; Street name 2
VAR Type2	77	6	X ; Suffix street type 2
VAR SufDir2	83	2	X ; Suffix direction 2

The USStreetInts.st_ file, which is associated with the us_intsc.mat file, uses position="42". An example address string is "NEW YORK ST + STATE ST".

See the INTERSECTION, INTERSECTIONSTYLE, and INTERSECTIONQUERY elements for more information about geocoding with street intersections.

FIELDS, FIELD, POSITION, PREFERREDNAMES, NAME

FIELDS

Purpose: Defines all database fields used for geocoding.

<FIELDS>   lt;FIELD id="FromLeft" required="true" description="Left from house number">     <POSITION start="1" width="10" />     <PREFERREDNAMES>       <NAME>L-F-ADD</NAME>       <NAME>L_F_ADD</NAME>       . . . . . .       <NAME>LEFTADD1</NAME>     </PREFERREDNAMES>   </FIELD>   . . . . . . . </FIELDS>

All the information used for the FIELDS element is taken from the corresponding *.mat file and addstyle.db file.

FIELD

Purpose: Defines the single field used in FIELDS.

Each FIELD element must have the following attributes:

• id- Value is the name of the VAR variable copied from *.mat file. It is used everywhere in the *.stl file to refer to this particular field. This is not a field name in a database; the name in the database is unknown until the style is linked with an actual database when the map configuration file is started as an ArcIMS service.
• required- Value should be "true" if the field is required or "false" for optional fields. All required fields must be used in the map configuration file.
• description-Value is a text string describing the field. This description can be copied from *.mat.

POSITION

Purpose: Defines the position of the field in the candidate's buffer (the same as in *.mat file).

PREFERREDNAMES

Purpose: Defines the list of preferred names for fields.

NAME

Purpose: Defines the single name from the PREFERREDNAMES element.

POSITION defines the position of the field in an internal buffer. PREFERREDNAMES is a list of the field's preferred names in a database. The start and width attributes are copied from the *.mat file. The list of preferred names is copied from addstyle.db.

The format of the FIELDS element in the *.st_ file is different from those used in the *.stl file:

<FIELDS>   lt;FIELD id="PreDir1" required="false" datafieldid="PreDir" belongsto="street1">     <POSITION start="1" width="2" />   </FIELD>   . . . . . . .   <FIELD id="PreDir2" required="false" datafieldid="PreDir" belongsto="street2">     <POSITION start="43" width="2" />   </FIELD>   . . . . . . . </FIELDS>

The FIELDS element also reflects the information from the corresponding *.mat file. Each FIELD element must have an id copied from the VAR variable. The required attribute must have a value of "true" for required fields and a value of "false" for the optional fields. The datafield attribute links the field with the FIELD defined in the corresponding *.stl file. The belongsto attribute defines whether the field belongs to STREET1 or STREET2.

FIELDS from the street intersection style do not need PREFERREDNAMES; this information will be taken from the *.stl file.

INDEXES, INDEX

INDEXES

Purpose: Defines the geocoding indexes used for ArcIMS address styles.

<INDEXES> <INDEX name="STN" seqnumber="1" hash="soundex" duplicate="true"> <FIELD id="StreetName" /> </INDEX> <INDEX name="zone" seqnumber="2" hash="random" duplicate="true"> <FIELD id="LeftZone" /> <FIELD id="RightZone" /> </INDEX> </INDEXES>

Information defined here is needed for the IndexBuilder to build the indexes and is also used by the Geocode Server to retrieve candidates from the database.

INDEX

Purpose: Defines a single geocoding index. As many as 255 indexes may be defined.

Each INDEX must have the following attributes:

• name - Value is a unique name of the index; should be 1-8 characters beginning with a letter.
• seqnumber - Value is an integer representing a unique number for the index; the first index should be given a number of 1, etc.
• hash - Value specifies the type of index, either "random" or "soundex". Use "soundex" to detect spelling variation of the key (for example, street names). Use "random" when spelling errors are not applicable (for example, ZIP Code).
• duplicate - Value of "true" allows duplicate keys, and "false" does not allow duplicates. If duplicates are allowed, there can be multiple records for one key. For example, a street name such as "Main" may point to a number of records in a database.

FIELD defines which field from the database will be indexed. The id attribute refers to a FIELD defined in FIELDS.

INDEX may have two FIELD child elements. In this example, a combined index is created, such an index contains all different keys from both specified fields. For example, in the code shown above, index zone includes two FIELD id values - LeftZone and RightZone. It means that when the index is built it will get only one key for a record where LeftZone and RightZone fields have the same value and two keys for a record where the fields have different values.

INTERSECTION

Purpose: Defines a street intersection style file.

<INTERSECTION style="USStreetInts.st_" />

The style attribute refers to the *.st_ file. This style defines rules for street intersection geocoding and can be "linked" with other street styles such as USAddress or USSingleHouse. It cannot be used by itself (this is why it has the *.st_ extension) or with other nonstreet styles such as Zip4 or SingleField.

See the SEPARATOR element for more information about the separator that is used for the OUTPUT of geocoding street intersections.

INTERSECTIONSTYLE

Purpose: Root element for the street intersection style. This element has no attributes.

<INTERSECTIONSTYLE>...</INTERSECTIONSTYLE>

INTERSECTIONQUERY

Purpose: Defines index expression used to extract potential candidates from the database. This element has the same purpose as QUERY element for the *.stl files.

<INTERSECTIONQUERY indexname="stn" mkfield1="S1" mkfield2="S2" indexname="zone" mkefieldzone="ZN" />

The indexname attribute defines the name of the index (declared in the INDEXES element in the *.stl file) used for street intersection geocoding. The mkfield1 and mkfield2 attributes define names of match key's fields (from the *.dct).

The indexnamezone attribute defines the name of the index (declared in the INDEXES element in the *.stl file) used for street intersection with zone geocoding.

The mkfield1 and mkfield2 attributes define names of match key's fields (from the *.dct file).

The mkfieldzone attribute defines the name of the zone match key field (from the *.dct file ).

In order to get potential candidates for street intersections, the Geocode Server needs to perform the same query twice - for data from mkfield1 and mkfieldzone and for data from mkfield2 and mkfieldzone. Here is an example of two expressions that would be performed to find the intersection "New York st, 92373" and "State st, 92373":

• First index expression:  stn="New York"? & zn="92373"
• Second index expression:  stn="State"? & zn="92373"

All the records found by these two queries are then "matched" to find which candidates intersect. Note: The ? is used for the soundex indexing.

When creating a custom address style that uses intersection with zone geocoding, the mkfieldzone attribute's value should be "ZN".

Example ArcIMS Style File

The following is an example of an ArcIMS style file (*.stl) as implemented for German address matching.

Sample Style File for German Address Matching

<GEOSTYLE name=“GermanAddress” description=“German addresses without zone information” > <STNCOMMAND file=“ger_add.stn” /> <MATCHKEY file=“ger_add.dct” /> <MATCHRULES file=“ger_add2.mat” >   <MATCH mprob=“0.9" uprob=”0.01" />   <MATCH mprob=“0.7" uprob=”0.1" />   <MATCH mprob=“0.999" uprob=”0.05" /> </MATCHRULES> <QUERY stn=“SN” /> <INPUT>   <TAG id=“STREET” label=“Street” width=“10" type=“text” description=”street name, street suffix and street number” />   <FORMAT>     <STNSTRING>          <ADDTAG>STREET</ADDTAG>     </STNSTRING>   </FORMAT>       </INPUT> <OUTPUT>   <PRINTFIELD>StreetName</PRINTFIELD>   <PRINTFIELD>StreetSuffix</PRINTFIELD>   <PRINTMATCHKEY>HN</PRINTMATCHKEY> </OUTPUT> <FIELDS>   <FIELD id=“StreetName” required=“true” description=“Street name”>     <POSITION start=“1" width=“32" />     <PREFERREDNAMES>       <NAME>STRAßEN.NAME</NAME>       <NAME>STRAßEN_NAM</NAME>       <NAME>STRAßEN-NAM</NAME>       <NAME>STR.NAME</NAME>       <NAME>STR_NAME</NAME>       <NAME>STR-NAME</NAME>       <NAME>STR.NAM</NAME>       <NAME>STR_NAM</NAME>       <NAME>STR-NAM</NAME>       <NAME>ST.NAME</NAME>       <NAME>ST_NAME</NAME>       <NAME>ST-NAME</NAME>       <NAME>NAME</NAME>       <NAME>FNAME_BASE</NAME>     </PREFERREDNAMES>   </FIELD>   <FIELD id=“StreetSuffix” required=“false” description=“Suffix street type”>     <POSITION start=“33" width=“16" />     <PREFERREDNAMES>       <NAME>STRAßEN.EXT</NAME>       <NAME>STRAßEN_EXT</NAME>       <NAME>STRAßEN-EXT</NAME>       <NAME>STR.EXT</NAME>       <NAME>STR_EXT</NAME>       <NAME>STR-EXT</NAME>       <NAME>ST.EXT</NAME>       <NAME>ST_EXT</NAME>       <NAME>ST-EXT</NAME>     </PREFERREDNAMES>   </FIELD>       <FIELD id=“FromLeft” required=“true” description=“Left from house number”>     <POSITION start=“49" width=“8" />     <PREFERREDNAMES>       <NAME>L-ADR.VON</NAME>       <NAME>L-ADR_VON</NAME>       <NAME>L-ADR-VON</NAME>       <NAME>L_ADR.VON</NAME>       <NAME>L_ADR_VON</NAME>       <NAME>L_ADR-VON</NAME>       <NAME>LADR.VON</NAME>       <NAME>LADR_VON</NAME>       <NAME>LADR-VON</NAME>       <NAME>L-V.ADR</NAME>       <NAME>L-V_ADR</NAME>       <NAME>L-V-ADR</NAME>       <NAME>L_V.ADR</NAME>       <NAME>L_V_ADR</NAME>       <NAME>L_V-ADR</NAME>       <NAME>LINKEADR1</NAME>       <NAME>LREF_ADDRE</NAME>     </PREFERREDNAMES>   </FIELD>   <FIELD id=“FromRight” required=“true” description=“Right from house number”>     <POSITION start=“57" width=“8" />     <PREFERREDNAMES>       <NAME>R-ADR.VON</NAME>       <NAME>R-ADR_VON</NAME>       <NAME>R-ADR-VON</NAME>       <NAME>R_ADR.VON</NAME>       <NAME>R_ADR_VON</NAME>       <NAME>R_ADR-VON</NAME>       <NAME>RADR.VON</NAME>       <NAME>RADR_VON</NAME>       <NAME>RADR-VON</NAME>       <NAME>R-V.ADR</NAME>       <NAME>R-V_ADR</NAME>       <NAME>R-V-ADR</NAME>       <NAME>R_V.ADR</NAME>       <NAME>R_V_ADR</NAME>       <NAME>R_V-ADR</NAME>       <NAME>READR1</NAME>       <NAME>RREF_ADDRE</NAME>     </PREFERREDNAMES>   </FIELD>   <FIELD id=“ToLeft” required=“true” description=“Left to house number”>     <POSITION start=“65" width=“8" />     <PREFERREDNAMES>       <NAME>L-ADR.NACH</NAME>       <NAME>L-ADR_NACH</NAME>       <NAME>L-ADR-NACH</NAME>       <NAME>L_ADR.NACH</NAME>       <NAME>L_ADR_NACH</NAME>       <NAME>L_ADR-NACH</NAME>       <NAME>LADR.NACH</NAME>       <NAME>LADR_NACH</NAME>       <NAME>LADR-NACH</NAME>       <NAME>L-N.ADR</NAME>       <NAME>L-N_ADR</NAME>       <NAME>L-N-ADR</NAME>       <NAME>L_N.ADR</NAME>       <NAME>L_N_ADR</NAME>       <NAME>L_N-ADR</NAME>       <NAME>LINKEADR2</NAME>       <NAME>LNREF_ADDRE</NAME>     </PREFERREDNAMES>   </FIELD>   <FIELD id=“ToRight” required=“true” description=“Right to house number”>     <POSITION start=“73" width=“8" />     <PREFERREDNAMES>       <NAME>R-ADR.NACH</NAME>       <NAME>R-ADR_NACH</NAME>       <NAME>R-ADR-NACH</NAME>       <NAME>R_ADR.NACH</NAME>       <NAME>R_ADR_NACH</NAME>       <NAME>R_ADR-NACH</NAME>       <NAME>RADR.NACH</NAME>       <NAME>RADR_NACH</NAME>       <NAME>RADR-NACH</NAME>       <NAME>R-N.ADR</NAME>       <NAME>R-N_ADR</NAME>       <NAME>R-N-ADR</NAME>       <NAME>R_N.ADR</NAME>       <NAME>R_N_ADR</NAME>       <NAME>R_N-ADR</NAME>       <NAME>READR2</NAME>       <NAME>RNREF_ADDRE</NAME>     </PREFERREDNAMES>   </FIELD> </FIELDS> <INDEXES>   <INDEX name=“STN” seqnumber=“1" hash=“soundex” duplicate=“true”>     <FIELD id=“StreetName” />   </INDEX> </INDEXES> <INTERSECTION style=“GermanStreetInts.st_” /> </GEOSTYLE>