Amazon QuickSight 图层地图升级：支持通过 GeoJSON 绘制点与路径

借助 Amazon QuickSight 图层地图（layer maps），您现在可以绘制点与路径，例如城市范围内的门店分布或从机场起飞的航班航线。地理空间地图有助于企业洞察与地理位置密切相关的模式，例如某个区域的业务表现或客户聚集地。Amazon QuickSight 通过多种地图类型为此提供支持，包括点图（point maps）、填充图（filled maps）和图层地图。当图层地图首次推出时，您可以上传 GeoJSON 文件来绘制自定义形状图层（如销售大区或行政辖区），并将这些形状关联至数据集。这很好地满足了区域与边界的展示需求，但无法涵盖这些区域内部的具体独立位置或连接各区域的流动路径。

图层地图现已通过同一 GeoJSON 工作流支持另外两种几何类型：Point（点）和 LineString（线串）。Point 用于标记特定位置，例如单个门店或设施网点；LineString 则用于描绘位置之间的路径，例如配送路线或机场之间的航线。

Amazon QuickSight 是 Amazon Quick 的商业智能（BI）功能，是一项统一的 BI 服务。它提供现代化交互式仪表板、自然语言查询、高保真报告、机器学习（ML）洞察以及大规模嵌入式分析能力。Amazon Quick 将用于业务洞察、调研和自动化的 AI Agent 整合到一体化体验中，帮助您在遵循安全与访问策略的同时更智能、更快速地工作。

在本文中，我们将深入解析图层地图所需的数据集和 GeoJSON 结构，说明点和线在图层地图可视化中的工作机制及选型建议。最后，我们将介绍控制视口（viewport）、几何图层叠加以及通过编程方式更新 GeoJSON 文件的进阶技巧。

数据集结构考量

图层地图从 GeoJSON 文件中获取形状几何数据，从 QuickSight 数据集中获取指标数据，并通过共享关联键（join key）将两者连接起来。您如何组织这两者的数据结构，决定了地图能够呈现的内容。本节将介绍开始前所需的先决条件以及 GeoJSON 文件的组织方式。

先决条件

在 QuickSight 中创建图层地图之前，需要满足以下先决条件：

• 描述几何图形的 GeoJSON 文件。
• 包含指标和维度的 QuickSight 数据集。
• QuickSight 数据集与 GeoJSON 文件之间共享的关联键（join key）。
• GeoJSON 文件必须以 .geojson 格式保存，支持的最大文件大小为 100 MB。

GeoJSON 文件的结构

GeoJSON 是一种基于 JSON 的格式，用于描述点、线等地理要素。

{ "type": "FeatureCollection", "features": [{ "type": "Feature", "geometry": { "type": "Point", "coordinates": [88.4, 22.6] }, "properties": { "prop0": "value0" } }, { "type": "Feature", "geometry": { "type": "LineString", "coordinates": [ [88.2, 22.4], [88.9, 23.1], [89.5, 22.8], [90.1, 23.6] ] }, "properties": { "prop0": "value0" } }] }

文件结构如下：

• FeatureCollection 是整个文件对象。其类型为 FeatureCollection，并包含一个 features 数组。
• Feature 是单个地图要素。它包含一个 geometry（形状）和一个保存关联键的 properties 对象。
• geometry 具有 type（Point、LineString 或 Polygon）及其 coordinates。对于 Point，coordinates 包含单个 [经度, 纬度] 坐标；对于 LineString，则包含按顺序排列的坐标列表。

配置 QuickSight 数据集及其 GeoJSON

在 QuickSight 中为图层地图图表配置图层时，需要考虑两个主要设置。首先是 要可视化的几何类型（Geometry type to visualize），它决定了渲染 GeoJSON 文件中的哪种几何类型：点（Points）、线（Lines）或多边形（Polygons）。一个图层一次只渲染一种几何类型，因此当文件中混合包含多种类型（如上例所示）时，地图上仅会显示所选类型的要素（Features）。其次是将 形状文件关联字段（Shape file key field）与 数据集关联字段（Dataset key field）进行匹配，将 GeoJSON 中的每个要素链接到 QuickSight 数据集中的某一行。字段名称无需完全相同，但字段值必须一致。以下两个示例将端到端展示该流程，首先是 LineString 图层，其次是 Point 图层。

示例：LineString 图层

以 JFK 飞往洛杉矶等目标城市的航班示例数据为例。单个数据点的 GeoJSON 结构配置如下：

{ "type": "Feature", "geometry": { "type": "LineString", "coordinates": [ [-73.7781, 40.6413], [-85.5627, 40.6407], [-97.1415, 39.4569], [-108.1612, 37.1753], [-118.4085, 33.9416] ] }, "properties": { "route_id": "JFK-LAX" } }

QuickSight 数据集中的对应行包含以下信息：

图 1：按 route_id 关联的 JFK-LAX 航线数据集行

route_id 字段用于将 QuickSight 数据集与 GeoJSON 文件进行关联。GeoJSON 中每条航线对应一个要素，数据集里每条航线对应一行。要可视化的几何类型设置为“线”（Lines）。

图 2：绘制为 LineString 图层的 JFK-LAX 航线

示例：Point 图层

以长岛市等零售门店位置的示例数据为例。单个数据点的 GeoJSON 结构配置如下：

{ "type": "Feature", "geometry": { "type": "Point", "coordinates": [-73.9490, 40.7447] }, "properties": { "store_id": "S-109" } }

QuickSight 数据集中的对应行包含以下信息：

图 3：按 store_id 关联的门店数据集行

store_id 字段用于将 QuickSight 数据集与 GeoJSON 文件进行关联。GeoJSON 中每个门店对应一个要素，数据集里每个门店对应一行。要可视化的几何类型设置为“点”（Points）。

图 4：绘制为 Point 图层的门店

图层地图图表中的线

图层地图图表现在支持 LineString 几何类型，可将有序的坐标列表连接成一条单一路径。正如数据结构部分所述，每条路线为一个要素，其坐标是地图按顺序依次连接的定位点。

当您希望展示不同地理位置之间的关系时（例如航线、配送路线、海运航道或管道段），可以使用线。可视化组件会根据 GeoJSON 文件中的坐标绘制每条路径，而不是在加载时从数据动态计算生成。已关联数据集中的字段可以决定线条的颜色编码，从而方便根据该字段所代表的维度对航线进行分组。除颜色外，您还可以通过线宽和不透明度控制项自定义线条，调整地图上的视觉突出度与清晰度。GeoJSON properties 对象中的关联键将每个 LineString 与数据集行绑定，为其提供悬浮提示（tooltip）和颜色支持。

例如，机场运营团队可以绘制某一天从纽约（JFK）起飞的航班。GeoJSON 文件中每条航线对应一个 LineString，通过航线 ID 键关联到数据集。每条线均始于 JFK 并终于其目的地（如洛杉矶、芝加哥或迈阿密）。数据集则提供在悬浮提示中显示的始发地、目的地及承运航空公司信息。

图 5：绘制为飞往多个目的地的 LineString 航线的 JFK 出港航班

图层地图图表中的点

Amazon QuickSight 提供了原生点图图表类型，它可以自动对地名进行地理编码，并随 SPICE 刷新计划或 Direct Query 直连更新。它支持动态点大小、颜色编码以及聚合点（cluster points）、热力图密度渐变等点样式。它最适合用于频繁变动、且需要地图在视觉上实时响应这些变化的数据。

随着对图层地图图表中 GeoJSON 点图层的支持，QuickSight 现已提供第二种点映射能力，二者之间存在一些关键差异。图层地图图表中的点使用统一的标记尺寸，且不支持地理编码，因此必须在 GeoJSON 文件中提供明确的坐标。作为回报，您可以精确控制视口，将地图锁定在确切的地理区域，并禁用平移和缩放。

下表总结了关键差异：

功能特性	点图（Point map）	图层地图点（Layer map visual points）
数据源	数据集中的经度/纬度值或地理位置名称	通过共享关联键与数据集关联的 GeoJSON Point 要素
地理编码	自动识别城市、县、州/省、国家和邮政编码	不可用。必须在 GeoJSON 文件中提供明确坐标
位置更新	随着位置值的变化，通过 SPICE 刷新或 Direct Query 自动更新映射	使用静态 GeoJSON 文件指定点位置。需要手动重新上传或调用 API 更新几何图形
视口	自动适应数据范围，平移和缩放始终启用	默认自动适应，可配置是否允许平移和缩放
外观	大小和颜色可根据数据集字段编码。提供点样式配置（基础、聚合、热力图）	可自定义统一标记大小、填充不透明度、边框颜色和厚度。颜色可根据数据集编码

在以下情况下建议选择图层地图点：

• 需要锁定、不可滚动的视口。
• 位置是固定且经过精心规划的（如区域办事处、配送中心、零售门店），而不是随着每次数据刷新而频繁变动。
• 计划将点与其他几何类型结合使用（详见高级用例部分）。

例如，某零售品牌的区域经理使用 QuickSight 仪表板跟踪整个都会区的门店业绩。GeoJSON 文件为每个门店包含一个 Point 要素，并通过门店 ID 属性关联到数据集。数据集保存驱动提示信息和颜色编码的指标（门店类型、月度营收、每日客流量）。您可以将地图定位在覆盖都会区的缩放级别上，然后禁用地图导航，以确保地图在每次加载时都呈现一致的视图。经理们不会意外缩放到全国或全球视图。

图 6：显示为点且已禁用地图导航以锁定都会区视图的门店位置

高级用例

前面的章节介绍了标准的图层地图设置。当您需要对读者所见的画面进行更精细的控制、希望在单一视图中组合多种几何类型，或者需要随时间动态变化的几何数据时，可以使用以下技巧。

控制视口

当您需要控制图层地图图表中的视口时，可以手动平移并缩放到所需视图，然后禁用地图导航将其锁定到位。对于需要更精确边界或编程式控制的用例，可以通过 QuickSight API 在可视化定义中设置确切的视口坐标。

图层地图图表将其视口配置保存在 ChartConfiguration 内的 MapState 属性中。该属性接受两个字段：

• Bounds：定义最小可见区域的地理坐标（北、南、东、西）。
• MapNavigation：设为 ENABLED 或 DISABLED，用于控制读者是否可以平移和缩放。

尽管控制台未直接公开 bounds 属性，但当使用仪表板定义 JSON 进行编程式资产管理时，您可以设置这些边界。例如，要定义边界，只需修改可视化定义中的 MapState 代码块，然后调用 CreateDashboard 或 UpdateDashboard API。

Bounds 定义了确保可见的最小区域。地图会自动缩放，以确保该完整区域在可视化容器内完全适配呈现。

With Amazon Quick Sight layer maps, you can now plot points and routes, like store locations across a city or flights leaving an airport. Geospatial maps help businesses spot patterns that are tied to location, like how a region is performing or where customers are concentrated. Amazon Quick Sight supports this with multiple map types, including point maps, filled maps, and layer maps. When layer maps first launched, you could upload a GeoJSON file to draw custom shape layers, such as sales territories or districts, and join those shapes to a dataset. That handled regions and boundaries well, but it didn’t cover the individual locations inside them or the routes running between them.

Layer maps now support two more geometry types from the same GeoJSON workflow: Point and LineString. Points mark specific locations, such as individual store or facility sites. A LineString traces the route between locations, like a delivery path or a flight between airports.

Amazon Quick Sight, the business intelligence (BI) capability of Amazon Quick, is a unified BI service. It delivers modern interactive dashboards, natural language querying, pixel-perfect reports, machine learning (ML) insights, and embedded analytics at scale. Amazon Quick brings together AI agents for business insights, research, and automation in one integrated experience, helping you work smarter and faster while maintaining security and access policies.

In this post, we walk through the dataset and GeoJSON structure that layer maps require. We also explain how points and lines work in a layer map visual and when to choose each. Finally, we cover advanced techniques for controlling the viewport, layering geometries, and updating GeoJSON files programmatically.

Dataset structure considerations

A layer map gets its shapes from a GeoJSON file and its metrics from a Quick Sight dataset, and a shared key joins the two. How you structure each one determines what the map can show. This section covers what you need before you start and how a GeoJSON file is organized.

Prerequisites

The following are the prerequisites that you need before creating a layer map in Quick Sight:

• A GeoJSON file describing your geometry.
• A Quick Sight dataset holding the metrics and dimensions.
• A join key shared between the Quick Sight dataset and the GeoJSON file.
• The GeoJSON file must be saved in .geojson format, with a maximum supported file size of 100 MB.

Structure of the GeoJSON file

GeoJSON is a JSON-based format for describing geographic features such as points and lines.

{
  "type": "FeatureCollection",
  "features": [{
    "type": "Feature",
    "geometry": {
      "type": "Point",
      "coordinates": [88.4, 22.6]
    },
    "properties": { "prop0": "value0" }
  }, {
    "type": "Feature",
    "geometry": {
      "type": "LineString",
      "coordinates": [
        [88.2, 22.4],
        [88.9, 23.1],
        [89.5, 22.8],
        [90.1, 23.6]
      ]
    },
    "properties": { "prop0": "value0" }
  }]
}

The structure of the file is as follows:

• FeatureCollection is the whole file. It has a type of FeatureCollection and a features array.
• Feature is a single map element. It carries a geometry (the shape) and a properties object, which holds the join key.
• geometry has a type (Point, LineString, or Polygon) and its coordinates. The coordinates hold a single [longitude, latitude] position for a Point , and an ordered list of positions for a LineString.

Configuring the Quick Sight dataset and its GeoJSON

In Quick Sight, when you configure a layer in a layer map visual, there are two primary settings to consider. The first is the Geometry type to visualize , which sets which geometry from the GeoJSON file renders: Points, Lines, or Polygons. A layer renders one geometry type at a time, so when a file mixes types like the preceding example, only Features of the selected type appear on the map. The second is matching the Shape file key field to the Dataset key field , which links each Feature in the GeoJSON to a row in your Quick Sight dataset. The field names don’t need to be identical, but the values do. The following two examples show this end to end, first a LineString layer and then a Point layer.

Example: LineString layer

Consider example data showing a flight from JFK to a destination city like Los Angeles. The GeoJSON structure for a single datapoint is configured as follows:

{
  "type": "Feature",
  "geometry": {
    "type": "LineString",
    "coordinates": [
      [-73.7781, 40.6413],
      [-85.5627, 40.6407],
      [-97.1415, 39.4569],
      [-108.1612, 37.1753],
      [-118.4085, 33.9416]
    ]
  },
  "properties": { "route_id": "JFK-LAX" }
}

The corresponding row in the Quick Sight dataset contains the following information:

Figure 1: Dataset row for the JFK-LAX route, keyed by route_id

The route_id field is used to join the Quick Sight dataset with the GeoJSON file. The GeoJSON holds one such feature per route, and the dataset one row per route. The Geometry type to visualize is set to Lines.

Figure 2: The JFK-LAX route drawn as a LineString layer

Example: Point layer

Consider example data showing a retail store location like Long Island City. The GeoJSON structure for a single datapoint is configured as follows:

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [-73.9490, 40.7447]
  },
  "properties": { "store_id": "S-109" }
}

The corresponding row in the Quick Sight dataset contains the following information:

Figure 3: Dataset row for a store, keyed by store_id

The store_id field is used to join the Quick Sight dataset with the GeoJSON file. The GeoJSON holds one such feature per store, and the dataset one row per store. The Geometry type to visualize is set to Points.

Figure 4: A store plotted as a Point layer

Lines on layer map visuals

Layer map visuals now support LineString geometry, connecting an ordered list of coordinates into a single path. As covered in the data structure section, each route is one feature, and its coordinates are the ordered positions the map connects in sequence.

Use lines when the relationship between locations is what you want to show, such as flight paths, delivery routes, shipping lanes, or pipeline segments. The visual draws each path from the coordinates in your GeoJSON file rather than generating it from your data at load time. A field from your joined dataset can determine the line color encoding, so you can group routes by whatever that field represents. In addition to color, you can customize lines with width and opacity controls to adjust visual prominence and clarity on the map. The join key in the GeoJSON properties object ties each LineString to the dataset row behind its tooltip and color.

For example, an airport operations team might map the flights leaving New York (JFK) on a given day. The GeoJSON file holds one LineString per route, keyed by a route ID that joins to the dataset. Each line starts at JFK and ends at its destination, such as Los Angeles, Chicago, or Miami. The dataset supplies the origin, destination, and carrier that show up in the tooltip.

Figure 5: Flights leaving JFK drawn as LineString routes to multiple destinations

Points on layer map visuals

Amazon Quick Sight offers a native point map visual type that geocodes location names automatically and refreshes with your SPICE schedule or Direct Query connection. It supports dynamic point sizing, color encoding, and point styles such as cluster points and heatmap density gradients. It works best with data that changes frequently and where you want the map to respond to those changes visually.

With the added support for GeoJSON point layers in layer map visuals, Quick Sight now offers a second point mapping capability with a few key differences. Layer map visual points use a uniform marker size and don’t support geocoding, so you provide explicit coordinates in the GeoJSON file. In return, you can control the viewport precisely, locking the map to an exact geographic region, and disabling panning and zooming.

The following table summarizes the key differences:

Feature	Point map	Layer map visual points
Data source	Latitude/longitude values or geolocation names in your dataset	GeoJSON Point features joined to your dataset by a shared key
Geocoding	Recognizes city, county, state, country, and postal code automatically	Not available. Must provide explicit coordinates in the GeoJSON file
Location updates	Mapping updates automatically with SPICE refreshes or Direct Query as location values change	Visual uses a static GeoJSON file for point locations. Requires manual re-upload or API call to update geometry
Viewport	Auto-fits to your data, panning and zooming always enabled	Auto-fits by default, can configure if panning and zooming is allowed
Appearance	Size and color can be encoded from the dataset. Point style configuration available (basic, cluster, heatmap)	Customizable uniform marker size, fill opacity, border color and thickness. Color can be encoded from the dataset

Choose layer map visual points when:

• You require a locked, non-scrollable viewport.
• Your locations are fixed and curated (such as regional offices, distribution centers, retail stores) rather than changing with each data refresh.
• You plan to combine points with other geometry types (covered in the advanced use cases section).

Consider a retail brand whose regional managers use a Quick Sight dashboard to track store performance across a metro area. The GeoJSON file contains a Point feature for each store with a store ID property that joins to the dataset. The dataset holds the metrics (store type, monthly revenue, daily foot traffic) that drive the tooltip and color encoding. You position the map at the zoom level covering the metro area, then disable map navigation so the map renders at a consistent view on every load. Managers can’t accidentally zoom out to a national or global view.

Figure 6: Store locations as points with map navigation disabled to lock the metro-area view

Advanced use cases

The previous sections cover a standard layer map setup. Use the following techniques when you need more control over what readers see, want to combine geometry types in a single view, or need geometry that changes over time.

Controlling the viewport

When you need to control the viewport in layer map visuals, you can pan and zoom to the view you want manually. Then disable map navigation to lock it in place. For use cases where you need more precise boundaries or programmatic control, you can set the exact viewport coordinates through the visual definition using the Quick Sight APIs.

The layer map visual stores its viewport configuration in the MapState property within ChartConfiguration. This property accepts two fields:

• Bounds : The geographic coordinates defining the minimum visible area (North, South, East, West).
• MapNavigation : ENABLED or DISABLED to control whether readers can pan and zoom.

Although the bounds property is not exposed on the console, you can set these bounds when working with the dashboard definition JSON for programmatic asset management. For example, to define the bounds, modify the MapState block in the visual definition, then call the CreateDashboard or UpdateDashboard APIs.

The bounds define the minimum area that is guaranteed to be visible. The map zooms to make sure this entire area fits within the visual container. For the tightest fit with minimal extra space added to the map, match the aspect ratio of your bounds to the shape of your visual container.

Layering geometries

For use cases that require combining multiple geometry types into a single view, you can layer visuals on top of each other. For example, the following screenshot demonstrates plotting customer locations as points within US regional boundaries defined by polygons. This composition shows which territories have the highest customer density and can be used to correlate with other metrics present in the dataset like performance.

Figure 7: Customer points layered within polygon regional boundaries

This second example demonstrates combining points as stops along a delivery route path. The LineString draws the planned route, and Point features mark each scheduled stop along the way.

Figure 8: A delivery route drawn as a LineString with Point markers for each stop

To layer geometries, you stack multiple layer map visuals on top of each other, following these steps:

1. Use free-form layout: Change the sheet layout setting to free-form so that visuals can overlap and stack.
2. Create two layer map visuals: Create the two layer map visuals that you combine into a single view, such as one using a Point GeoJSON file and one using a LineString GeoJSON file.
3. Use matching bounds: Using the approach previously described for controlling the viewport, verify all layer map visuals use identical bounds to have the same underlying map view.
4. Disable panning and zooming: For each layer map visual, disable the panning and zooming under Map options so that alignment stays the same.
5. Hide the base map and background on upper layer: Set the upper visual’s background to hidden under Display settings and disable the base map under Map options.
6. Stack the visuals: Move the top visual on top of the base layer using drag-and-drop or by matching precise size and position coordinates under Display settings.

Layer ordering follows the visual stacking order in the free-form layout. To change a visual’s position in the stack, choose the menu icon (three dots) on the visual, then choose Send backward or Bring forward. Readers can access the tooltip of the topmost visual, so place the layer that readers need details from on top. Each sheet supports up to five layer map visuals.

Dynamically updating GeoJSON

Unlike other Quick Sight visuals where data refreshes through SPICE or Direct Query, layer map geometry lives in the GeoJSON file itself. When your dataset refreshes on schedule, the metrics update (for example, colors change and tooltip values refresh), but the geometry remains at its original position.

To update what appears on the map, like a new route, new point locations, or updated boundaries, you need to update the GeoJSON file and republish the dashboard. You can replace a GeoJSON file manually through the Quick Sight console by editing the layer map visual within the Analysis and uploading a new file. This works for infrequent changes such as updating territory boundaries quarterly or adding a new store location.

For automated, on-demand, or dynamic updates, the process involves Amazon Simple Storage Service (Amazon S3) and the Quick Sight APIs outlined in the following steps:

1. Upload the new GeoJSON to Amazon S3: Generate your updated geometry and save it to an Amazon S3 bucket. Custom solutions can use other AWS services such as Amazon Location Service to create the GeoJSON files.
2. Reference the file on the dashboard definition: The dashboard definition contains a StaticFiles array with a SpatialStaticFile entry for each GeoJSON file. Modify the file reference to the S3 location of your updated file entry for each GeoJSON file.
3. Call the UpdateDashboard API: Submit the updated definition with the new file reference using the UpdateDashboard API.
4. Call the UpdateDashboardPublishedVersion API: Publish the change so it is visible to dashboard readers with the UpdateDashboardPublishedVersion API.

The following example uses this pattern to support on-demand map updates in an embedded dashboard to generate optimal routes between locations and waypoints. Although outside the scope of this post, this represents an advanced use case that combines each of the preceding approaches.

Figure 9: On-demand route generation in an embedded dashboard

Conclusion

In this post, we showed how to use Point and LineString geometry in Amazon Quick Sight layer maps to plot specific locations and the routes between them. We covered the GeoJSON structure and dataset join that layer maps require, and compared layer map points with the native point map. We also walked through advanced techniques for controlling the viewport, layering separate visuals into one view, and refreshing GeoJSON files with Amazon S3 and the Quick Sight APIs.

To learn more about layered maps, refer to the Amazon Quick Sight layered maps documentation. Visit the Amazon Quick Community to connect with peers and stay updated on the newest features and resources.

---

About the authors

Amit Makashir

Amit is a Software Development Engineer on the Amazon Quick Suite visualization team, where he helped build Quick Sight’s layer maps and the geospatial mapping stack behind them. His work spans the mapping visuals customers see and the geocoding, data, and service infrastructure that power them. Drawn to maps, places, and spatial problem-solving, he brings that curiosity to much of his work. Outside the office, he enjoys the outdoors—hiking, exploring new destinations, and taking long scenic drives.

Jackson Dowden

Jackson is a Worldwide Generative AI Solutions Architect for Amazon Quick at AWS. He began at AWS as a Partner Solutions Architect and now focuses on helping ISV and healthcare & life sciences customers implement AI-driven analytics and embedded insights with the Quick service.

Koushik Muthanna Koravanda Ganapathy

Koushik is a Specialist Solutions Architect for Amazon Quick at AWS. He helps customers design, implement, and scale Quick across their organization, from architecture to everyday use.

Salim Khan

Salim is a Senior Worldwide Generative AI Solutions Architect for Amazon Quick at AWS. He has over 16 years of experience implementing enterprise business intelligence solutions. At AWS, Salim works with customers globally to design and implement AI-powered BI and generative AI capabilities on Amazon Quick. Prior to AWS, he worked as a BI consultant across industry verticals including Automotive, Healthcare, Entertainment, Consumer, Publishing, and Financial Services, delivering business intelligence, data warehousing, data integration, and master data management solutions.