Skip To Content

Location types

In this topic

You can easily add data from SAP Dashboards directly to a map.

When you add data from SAP Dashboards, select the ArcGIS location type that best represents your information. Location information from SAP Dashboards is used to create a relationship between your business data and the specified location type.

Default location types

The following default location types are available if your organization is using ArcGIS Online. If you are using Portal for ArcGIS, only the first two location types in the list (Address and Latitude, Longitude) are supported.

  • Address—Depending on the geographic region of your organization, address data can be comprised of any of the following: address, neighborhood, city, subregion, region, state, province, postal code, United States Zip Code, country, and so on. The more address elements your data contains, the more accurate your results will be. The address elements can be in separate fields or they can be contained in one field (single-line address). Both methods of finding addresses are supported, but the best results are obtained by using all address elements and storing them in separate fields.
    Note:

    The Address location type is only available if your administrator has specified a geocoder for your organization. Multiple geocoders can be specified. If you are using the World Geocode Service, see Service coverage for geocode coverage information.

  • Latitude, Longitude—Latitude and Longitude values represent an X, Y coordinate location on the map. You can map X,Y coordinate data from any coordinate system. You can choose between World Geodetic Survery 1984 (WGS84) or Web Mercator, or you can specify the well-known ID of any other coordinate system. If you prefer to use WGS84 or Web Mercator, follow these guidelines: if your latitude (Y) values fall between -90 and 90 and the longitude (X) values range from -180 to 180, use WGS84; if your latitude and longitude values are in meters and have 6, 7, or 8 digits before (to the left of) the decimal point, use Web Mercator.
  • Standard administrative boundaries (only available with ArcGIS Online)—Standard administrative boundaries include cities, states, provinces, United States Zip Codes, postal codes, and countries. The administrative boundaries available to you are determined by your locale. Cities are added to the map as points. States, provinces, postal codes, United States Zip Codes, and countries are added to the map as polygons, which represent both the shape and the location of the place.
    Note:

    When the product language is set to a language other than English, countries is the only available administrative boundary location type.

Custom location types

If none of the default location types represent your data, you can specify a dynamic map service or a feature service from ArcGIS to use as a location type. For example, if your organization has its own boundaries (water districts, sales districts, or zoning boundaries), you can map your data using those locations instead of the default location types as long as there is a one-to-one relationship between the rows in your business data and the shapes in the service used as a location type (see Choose a location type for more information). Esri Maps for SAP BusinessObjects supports feature services and map services. For more information on adding a location type based on a dynamic map service or feature service, see Add a location type.

Choose a location type

When you use Esri Maps for SAP BusinessObjects to plot your business data on the map, it is important to choose the correct location type. Before a row of input data can be drawn, it must be located and identified as having either a point, line, or polygon shape. The location type you choose facilitates this process.

Address and Latitude, Longitude

When you choose the Address location type, points are generated using one of the geocoders your organization's administrator configured on ArcGIS Online or Portal for ArcGIS.

For the Latitude, Longitude location type, data from the identified X and Y location columns is used to generate points.

Latitude, Longitude location type

Standard administrative boundaries and custom types

When you choose any standard administrative boundary or custom location types, the appropriate shapes are located and retrieved using the specified column or columns for the chosen location type. This is done by associating the rows of data with the location type through a common column, known as a key.

The name of the column in your data does not have to match the column name in the location type; however, the information in the column has to be the same in order to produce a match. When a row of data cannot be located—that is, the shape cannot be retrieved from the location type—it is assigned a null shape and is not drawn on the map. The following table shows the supported keys for each location type.

Location typeShape typeSupported keys

US State

Polygon

The following is required:

  • State—State name. Can be a full name, two-letter abbreviation, or the state FIPS code (for example, "New York", "NY" or 36)

US City

Point

The following are required:

  • City— City name (for example, "Albuquerque")
  • State—State name. Can be a full name, two-letter abbreviation, or the state FIPS code (for example, "New York", "NY" or 36)

US ZIP Code

Polygon

One of the following is required:

  • ZipCode—ZIP Code (for example ("92373")
  • ZipCodePlus4—ZIP Code + 4 (for example, "92373-8100")

US County

Polygon

The following are required:

  • County—County name (for example, "Nassau")
  • State—State name. Can be a full name, two-letter abbreviation, or the state FIPS code (for example, "New York", "NY" or 36)

World City

Point

The following is required:

  • City—City name (for example, "Budapest")

Optionally, the following may be specified:

  • Country—Country name or ISO-3166 alpha 2 code (for example, "France" or "FR")

Country

Polygon

The following is required:

  • Country—Country name or ISO-3166 alpha 2 code (for example, "France" or "FR")

Custom

Point, Line, or Polygon (determined by selected map or feature service layer)

Specified during Add a location type workflow

Note:

Only English place names are supported.

When locating data using standard administrative boundaries or a custom location type, it is important to ensure that that there is a one-to-one relationship between the rows of input data and the shapes in the chosen location type. In a one-to-one relationship, each row of input data corresponds to a single shape on the map. In the following example, each row of input data (Profit by state) corresponds to one US state; the State column represents the unique key. The shape for each row of input data can therefore be easily determined and drawn on the map. In this example, a single polygon shape corresponding to each row in the Profit by state input data (for example, Arizona) is drawn.

One-to-one relationship example

Choosing an inappropriate location type can cause unexpected results. This is because the wrong location type often leads to a many-to-one or a one-to-many relationship between the input data and the shapes in the chosen location type. Again, it is important to establish a one-to-one relationship as shown above.

In the following example, the input data shows profit by ZIP Code. The data also contains US state information. Here, ZIP Codes represent the unique key in the input data. Many ZIP Codes are found in any given US state. If the US State location type is chosen—that is, if State is treated as the unique key—each input row will be located to its associated state, creating a many-to-one relationship between the rows of input data and the shapes in the location type. This means that polygon shapes corresponding to the many input rows will be drawn directly on top of one another on a map. In this example, Arizona will be drawn four times. The US ZIP Code location type, and not the US State location type, would therefore be the appropriate choice in this case.

Many-to-one relationship example

Like the many-to-one relationship, a one-to-many relationship should be avoided. In the case of a one-to-many relationship, only the first matching shape is retrieved and drawn on the map. This would not be an appropriate representation of the input data on a map.