Start of Content Area

Function documentation Parameter Description  Locate the document in its SAP Library structure


The following table lists the parameters that can be used when attaching your geo-coding program to the SAP system via the ABAP IF_GEOCODING_TOOL interface.

For more information about the differences between the parameters given to the IF_GEOCODING_TOOL interface and those passed via the RFC interface, go to section Differences Between IF_GEOCODING_TOOL and RFC Interfaces in Interface for Third-Party Geo-Coding.


The interface passes all addresses in the table to the geo-coding program. Each entry consists of an ID and the address data itself (ADRC_STRUC structure).


When implementing the geo-coding program via the RFC interface, the data type of the address is different. It is GEOCD_ADDR which is a subset of ADRC_STRUC.


This table is used to pass additional information:

This attribute (“SourceID”) is an identifier for the geo-coding program. This value is set in Customizing and simply needs to be returned in the geo-coding result container.

All addresses passed in addresses are from this country.

This attribute displays the user language. Language code as defined in ISO 639.


This table is used to return the status from the geo-coding process. Each entry consists of the ID to identify the corresponding address. For each address you need to return a result value ( RES attribute) with valid values (shown in bold font):


Geo-coding was successful. The result is unambiguous. The result has been returned in the containers parameter.


No geo-coding was required because of non-relevant address changes.

This value will be returned by the SAP geo-coding framework and is not allowed as a result value by the geo-coding program.


The result from geo-coding was ambiguous. The most probable address has been selected.

This value will only be returned in batch processing and is not allowed as a result value by the geo-coding program.


The result from geo-coding is ambiguous. Choices are available (see also the CHOICE export parameter).

This value should be returned if the user needs to select one out of a few different addresses.


The result from geo-coding is ambiguous. There is no choice available because the address data was not clearly specified.

This value should be returned if the list of choices is too big („too big“ is defined by you) or no match was found. In interactive mode, the user will then be asked to enter more data and geo-coding will be continued.


Geo-coding was not successful.

This value should only be returned if serious problems occurred within your program (program errors, illegal states, ...).


The program was not responsible.

This value should only be returned if your program was called for an address that cannot be geocoded. Example: Your program is responsible for all addresses in New York but the address given is located in San Francisco. In this case, the SAP geo-coding framework will dispatch the address to the next program.


This table is used to return a list of addresses the user can choose from. It will only be used if the return value in the results parameter equals 3.

The structure of the table is as follows:






COUNT (CONTAINER in the ABAP interface, see argument CONTAINERS for details)

The table starts with the ID attribute.

The following RANKING and PERCENTAGE attributes will be used to put these addresses in order. RANKING is used internally to determine the order. PERCENTAGE is only used for display purposes and does not have an impact on the displayed order.

The addr_short attribute is mandatory and is used for displaying the address in the dialog box.

In the address attribute, you must store the complete modified address as it would be passed from an external source.


The addresses data type is different when using the RFC interface. For more information, see section Differences Between IF_GEOCODING_TOOL and RFC Interfaces in Interface for Third-Party Geo-Coding.

RFC interface:

The final count attribute is used in conjunction with the container_lines attribute. container_lines holds all pairs of service/key/value triples with results from geo-coding (for example GEOCODING/LONGITUDE/13.533). To identify such an entry, each such line has ID/COUNT as access key. For more information, see the example in the Example for a result in container_lines section in Interface for Third-Party Geo-Coding. (The address with ID FCA753… returns a list of two addresses in choice and corresponding geographical data in container_lines ( count 1 & 2 in the table). Please do only use count values greater than or equal to one. Zero is reserved for the unambiguous result of the geo-coding process (see argument containers).

ABAP interface:

If you use the ABAP interface, container directly links to a table with corresponding container lines.


Currently SAP displays the short form of the address ( addr_short attribute) in the selection dialog box. This table contains the selection-relevant attributes of the returned addresses in the choice parameter. Only the attributes mentioned in this table are displayed.

For example, if the user wants to geocode Frankfurt in Germany, he will encounter the problem that there are two cities called Frankfurt in Germany (Frankfurt-upon-Oder and Frankfurt-upon-Main). The geo-coding program returns a choice of addresses. Though these addresses also contain attributes like street name and house number, there is no need to display these fields if the user first needs to select the correct town. So you may only return the attribute names COUNTRY, POSTCODE and CITY1 in relevant_fields. A list is now displayed that shows only these three relevant fields.


Do not change this attribute. Usually this attribute is used for internal purposes only.


It is possible to create messages that are displayed to users or written to the application log. There are some predefined messages in the SZGEOCODING development class. Simply append messages to this table. Do not modify or delete a message.


This is a table of AES containers. For each imported address, there will be an AES container to be exported. Again, each AES container can be identified via the ID.


Note that for each address passed to the geo-coding program, there will also be an AES container passed with the corresponding ID. So it is not required to create a new AES container entry in the table.

The attributes of each AES container structure are ID, CONTAINER, and CANCELLED in the ABAP interface, and ID and CONTAINER in the RFC interface.

CANCELLED should not be set. This flag is set by the SAP geo-coding framework when users cancel the selection of an address.

More details regarding the container are inside the AES container: One line of such a container consists of a SERVICE field that describes which service created this line. For geo-coding purposes, use constant „GEOCODING“ (upper case is mandatory). The possible values for the FIELD attribute are LONGITUDE, LATITUDE, ALTITUDE, SRCID, SRCTSTMP, PRECISID, and TZONE (upper case is mandatory). The VALUE attribute is used to store values for the fields given in the FIELD attribute.

For a description of the container, see the graphic in section Data Exchange Between the SAP Geo-Coding Framework and the Geo-Coding Program in Interface for Third-Party Geo-Coding.

For a description about the possible values and their data format, see Data Types of the ABAP interface.

RFC Interface:

For technical limitations, a direct link to the container table is not available in the RFC interface. Instead the ID is used as link to the CONTAINER_LINES attribute, where the lines of the container are stored. Store container lines using the address’ ID and COUNT=0 as key to table CONTAINER_LINES.



End of Content Area