From 9ac4012e718747da5508d9a41a2aa5e49f57173e Mon Sep 17 00:00:00 2001 From: Dana Bauer Date: Tue, 24 Jun 2025 17:24:38 -0400 Subject: [PATCH 1/4] add bridge file docs --- docs/gers/bridge-files.mdx | 180 +++++++++++++++++++++++++++++- docs/gers/gers-demonstrations.mdx | 1 + docs/gers/index.mdx | 20 ++-- 3 files changed, 186 insertions(+), 15 deletions(-) diff --git a/docs/gers/bridge-files.mdx b/docs/gers/bridge-files.mdx index b18086b16..d597d1dc6 100644 --- a/docs/gers/bridge-files.mdx +++ b/docs/gers/bridge-files.mdx @@ -1,7 +1,183 @@ --- title: Bridge Files -draft: true + --- -Bridge files are a key component of GERS. They link the feature IDs from the [source data](../attribution) — e.g. OSM, Meta, Micosoft, geoBoundaries, etc — to the GERS IDs in an Overture dataset. +With each release Overture generates **bridge files** that connect GERS IDs to the IDs from the [source data](../attribution). These files are a key component of GERS and offer two critical capabilities: reverse lookup of source features and insight into Overture's conflation process. + +Here's how to get the bridge files: + +| Provider | Location | +| ----------- | -------- | +| Amazon S3 | `s3://overturemaps-us-west-2/bridgefiles/` | +| Microsoft Azure Blob Storage | `https://overturemapswestus2.blob.core.windows.net/bridgefiles/` | + +The latest Overture data `` is: + +## Partitioning and schema + +Bridge files are released as Parquet files, partitioned by `dataset`, `theme`, and `type`. Overture currently provides mappings for the following datasets: + +``` +\bridgefiles + \ + **\dataset=OpenStreetMap** + \theme=divisions + \type=division + \type=division_area + \theme=buildings + \type=building + \theme=transportation + \type=segment + **\dataset=Esri Community Maps** + \theme=buildings + \type=building + **\dataset=PinMeTo** + \theme=places + \type=places + **\dataset=meta** + \theme=places + \type=places + **\dataset=Microsoft** + \theme=places + \type=places + **\dataset=Instituto Geográfico Nacional (España)** + \theme=buildings + \type=building + **\dataset=geoBoundaries** + \theme=divisions + \type=division + \type=division_area + +``` + + +| Property | Data type | Description | +| ---- | ---- | ---- | +| `id` | string | represents the GERS ID and is populated from the id column in the Overture data schema | + +| `record_id` | string | represents the id of the feature as it is in the source data provider (e.g. n2757802019@9) and is populated by parsing the sources column in the Overture data schema | + +| `update_time` | string | represents the time the feature or dataset was updated, depending on the data provider; also populated by parsing the sources column in the Overture schema | + +| `dataset` | string | represents the name of the dataset the feature has been provided in; also populated by parsing the sources column in the Overture data schema | + +| `theme` | string | represents the theme the feature is a part of, provided by the creator of the bridge file itself | + +| `type` | string | represents the type of the feature, either derived from the data or provided by the creator of the bridge file | + +| `between` | array | represents the portion of the normalized length of the GERS feature the dataset way takes, represented by a range between 0 and 1 | + +| `dataset_between` | array | represents the portion of the normalized length of the dataset way the GERS feature takes, represented by a range between 0 and 1 | + + +## Using bridge files + +Let's trace buildings data in the latest release back to the underlying source datasets. We'll examine an area near the US-Mexico border outside San Diego. + +First, get the buildings in our area of interest: + +```sql +CREATE TABLE IF NOT EXISTS border_buildings AS +(SELECT + * +FROM read_parquet('s3://overturemaps-us-west-2/release/2025-05-21.0/theme=buildings/type=building/*') +WHERE +bbox.xmin > -117.048198 AND bbox.xmax < -117.044608 + AND bbox.ymin > 32.535068 AND bbox.ymax < 32.600154); +``` + +Your table has 4367 building features in the latest release for your area of interest. Now let's look at a count of these building features by data source: + +``` +SELECT +sources[1].dataset AS source, +count(*) +FROM border_buildings +GROUP BY source; +``` + +``` +┌────────────────────────┬──────────────┐ +│ source │ count_star() │ +│ varchar │ int64 │ +├────────────────────────┼──────────────┤ +│ Esri Community Maps │ 412 │ +│ OpenStreetMap │ 1539 │ +│ Google Open Buildings │ 1751 │ +│ Microsoft ML Buildings │ 665 │ +└────────────────────────┴──────────────┘ +``` + +Now use the bridge file to find additional source data from the Overture corpus that didn't make it into the release. Join the data from the release with the bridge file data to create a detailed view of the source mappings. _Remember: we only have bridge files for Esri Community Maps data and OpenStreetMap data._ + +```sql +CREATE TABLE IF NOT EXISTS border_buildings_corpus AS +(SELECT + border_buildings.id AS gers_id, + dataset, + record_id AS dataset_record_id +FROM + border_buildings +JOIN + read_parquet('s3://overturemaps-us-west-2/bridgefiles/2025-05-21.0/dataset=*/theme=buildings/type=building/*') bridge +ON border_buildings.id = bridge.id +ORDER BY border_buildings.id, bridge.dataset); +``` + +Notice that the bridge file results show 2,021 total records compared to 4,367 buildings in the original query. This is because we have incomplete bridge file coverage for buildings. We don't generate bridge files for Microsoft ML Buildings, Google Open Buildings, and Meta Buildings because those sources don't have meaningful IDs for reverse lookup. However, the source mappings that do exist for buildings reveal important patterns: + +- Multiple sources per building: a single Overture building may be conflated from multiple source datasets +- One-to-many mapping: each source contribution gets its own bridge file record + +Let's dig into this a bit more. We can identify the buildings in the release that have multiple sources mappings. + +``sql +-- Identify buildings conflated from multiple sources +SELECT gers_id, + COUNT(DISTINCT dataset) as source_count, + STRING_AGG(DISTINCT dataset, ', ') as datasets +FROM border_buildings_corpus +GROUP BY gers_id +HAVING COUNT(DISTINCT dataset) > 1; +``` + +There are 70 buildings with that are mapped to two data sources. + +``` +┌──────────────────────────────────┬──────────────┬────────────────────────────────────┐ +│ gers_id │ source_count │ datasets │ +│ varchar │ int64 │ varchar │ +├──────────────────────────────────┼──────────────┼────────────────────────────────────┤ +│ 08b29a4c428ebfff02002b827866f466 │ 2 │ OpenStreetMap, Esri Community Maps │ +│ 08b29a4c428c3fff0200bb4d5defac52 │ 2 │ Esri Community Maps, OpenStreetMap │ +│ 08b29a4c428e5fff0200cddeda1c3c68 │ 2 │ OpenStreetMap, Esri Community Maps │ +│ 08b29a4c4280bfff0200729b26aa9ec7 │ 2 │ Esri Community Maps, OpenStreetMap │ +│ 08b29a4c428c9fff0200cc521ce08155 │ 2 │ OpenStreetMap, Esri Community Maps │ +│ 08b29a4c428cbfff0200df6833fcb919 │ 2 │ Esri Community Maps, OpenStreetMap │ +│ 08b29a4c428cbfff0200d5d23faeeec7 │ 2 │ Esri Community Maps, OpenStreetMap │ +│ 08b29a4c42809fff02000729055d0147 │ 2 │ Esri Community Maps, OpenStreetMap │ +│ 08b29a4c428ccfff02002cbabfaf31e0 │ 2 │ Esri Community Maps, OpenStreetMap │ +│ 08b29a4c4280bfff02003a1e8ccaeb68 │ 2 │ Esri Community Maps, OpenStreetMap │ +... +``` + +Let's pull out one example: +| gers_id | dataset | dataset_record_id | update_time | +| ---- | ---- | ---- | ---- | +| 08b29a4c428ebfff02002b827866f466 | Esri Community Maps | esri_ChulaVistaCA13510 | 2024-10-15T00:00:00.000Z | +| 08b29a4c428ebfff02002b827866f466 | OpenStreetMap | w1182486582@1 | 2023-06-16T14:22:10.000Z | + +This shows that building `08b29a4c428ebfff02002b827866f466` was created by a conflation process that definitely included data from OpenStreetMap (way 1182486582, version 1) and Esri Community Maps (esri_ChulaVistaCA13510) and may have included other data sources that have not been mapped to GERS. + + +## Bridge file limitations + +**Missing bridge files**: some datasets (Microsoft ML Buildings, Google Open Buildings, Meta Buildings) don't have bridge files because they lack meaningful source IDs for reverse lookup. + +**Linear feature complexity**: transportation segments may have complex geometry relationships captured in the `between` and `dataset_between` fields + +**Update frequency**: bridge files are generated per release and reflect conflation decisions at release time + +Bridge files provide essential transparency into Overture's conflation process, enabling users to understand data provenance and trace features back to their source datasets. diff --git a/docs/gers/gers-demonstrations.mdx b/docs/gers/gers-demonstrations.mdx index 03185195c..b6a89418b 100644 --- a/docs/gers/gers-demonstrations.mdx +++ b/docs/gers/gers-demonstrations.mdx @@ -1,5 +1,6 @@ --- title: GERS Demonstrations +draft: true --- Within the Overture ecosystem, member companies and collaborators have created several GERS prototypes and demonstrations to help you get started with data matching and GERS ID assignment. diff --git a/docs/gers/index.mdx b/docs/gers/index.mdx index 7367fd356..03c02e0ec 100644 --- a/docs/gers/index.mdx +++ b/docs/gers/index.mdx @@ -8,24 +8,19 @@ import QueryBuilder from '@site/src/components/queryBuilder'; The Global Entity Reference System (GERS) is a universal framework for structuring and matching map data across systems. GERS, coupled with Overture datasets, is a potential standard for identifying and referencing the physical and conceptual entities we've defined in our world. It's also a mechanism that can simplify the integration and exchange of data layers. -At the heart of GERS is a unique ID called the GERS ID. Overture assigns a GERS ID to each feature in our dataset. That feature, and therefore its GERS ID, represents an entity that exists in the real world, such as an office building, highway, country, river, museum or school. +GERS provides stable identifiers called GERS IDs for real-world geospatial entities across data releases and maintains consistency when entities appear in multiple source datasets. -:::note -We use *feature* and *entity* interchangably in this documentation but their meaning is a bit more complicated. For example, a building that hosts a branch of a public library is represented in the Overture buildings dataset as a map feature with its own unique GERS ID. The public library may also be represented in the Overture places dataset as a point of interest with its own unique GERS ID. The building and the library are distinct entities with distinct GERS IDs. -::: - - -## The system +## GERS is a system The "S" in GERS stands for a *system*, with the following components: | Component | Description | | ---------- | ---------- | -| [Overture reference map](/#overture-data) | The reference map consists of the canonical datasets Overture releases each month. | -| Global registry of GERS IDs | The global registry is a catalog of all GERS IDs ever published. | -| [Data changelog](changelog) | The changelog describes changes to entities across releases. You detect changes to Overture data from one release to another by querying across stable GERS IDs in the data changelog. | -| Bridge files | Bridge files link a feature's ID from the [source data](../attribution) — e.g. OSM, Meta, Micosoft, geoBoundaries, etc — to its GERS ID in an Overture dataset | -| [Onboarding services](gers-demonstrations) | These are tools and services to help you associate your data with GERS. | +| [Overture reference map](/#overture-data) | consists of the canonical datasets Overture releases each month | +| Global registry of GERS IDs | catalogs all GERS IDs ever published | +| [Data changelog](changelog) | describes changes to entities across releases | +| [Bridge files](bridgefiles) | connects the GERS IDs in a release to the IDs from the underlying source data | + ## How does GERS work? @@ -51,4 +46,3 @@ You can independently associate your own data (or a third-party dataset) with Ov ### Contributing data You can contribute data to the Overture Maps Foundation, and we will uas Overture's matching algorithms to match the features in your dataset to features in Overture. Matched features may be assigned an existing GERS ID, and we may generate new GERS IDs for new features. -You'll find theme-specific examples of GERS use cases in the [GERS demonstrations](gers-demonstrations) section of this documentation. From 32cd0e593a8bf0caa4f5616eeb12bf713c9691cf Mon Sep 17 00:00:00 2001 From: Dana Bauer Date: Tue, 24 Jun 2025 18:02:39 -0400 Subject: [PATCH 2/4] editing and formatting --- docs/gers/bridge-files.mdx | 71 ++++++++++++++++---------------------- docs/gers/index.mdx | 2 +- 2 files changed, 30 insertions(+), 43 deletions(-) diff --git a/docs/gers/bridge-files.mdx b/docs/gers/bridge-files.mdx index d597d1dc6..9be24f06a 100644 --- a/docs/gers/bridge-files.mdx +++ b/docs/gers/bridge-files.mdx @@ -1,9 +1,9 @@ --- title: Bridge Files - --- +import QueryBuilder from '@site/src/components/queryBuilder'; -With each release Overture generates **bridge files** that connect GERS IDs to the IDs from the [source data](../attribution). These files are a key component of GERS and offer two critical capabilities: reverse lookup of source features and insight into Overture's conflation process. +With each release Overture generates **bridge files** that connect GERS IDs to the IDs from the [source data](/attribution). These files are a key component of GERS and offer two critical capabilities: reverse lookup of source features and insight into Overture's conflation process. Here's how to get the bridge files: @@ -14,14 +14,18 @@ Here's how to get the bridge files: The latest Overture data `` is: +:::note +Currently, Overture only provides bridge files for these source datasets: Esri Community, geoBoundaries, Instituto Geográfico Nacional (España)Maps, Meta, Microsoft, OpenStreetMap, PinMeTo +::: + ## Partitioning and schema -Bridge files are released as Parquet files, partitioned by `dataset`, `theme`, and `type`. Overture currently provides mappings for the following datasets: +Bridge files are released as Parquet files, partitioned by `dataset`, `theme`, and `type` and structured in this way: ``` \bridgefiles \ - **\dataset=OpenStreetMap** + \dataset=OpenStreetMap \theme=divisions \type=division \type=division_area @@ -29,22 +33,22 @@ Bridge files are released as Parquet files, partitioned by `dataset`, `theme`, a \type=building \theme=transportation \type=segment - **\dataset=Esri Community Maps** + \dataset=Esri Community Maps \theme=buildings \type=building - **\dataset=PinMeTo** + \dataset=PinMeTo \theme=places \type=places - **\dataset=meta** + \dataset=meta \theme=places \type=places - **\dataset=Microsoft** + \dataset=Microsoft \theme=places \type=places - **\dataset=Instituto Geográfico Nacional (España)** + \dataset=Instituto Geográfico Nacional (España) \theme=buildings \type=building - **\dataset=geoBoundaries** + \dataset=geoBoundaries \theme=divisions \type=division \type=division_area @@ -52,30 +56,23 @@ Bridge files are released as Parquet files, partitioned by `dataset`, `theme`, a ``` +The Parquet schema includes the following properties: + | Property | Data type | Description | | ---- | ---- | ---- | | `id` | string | represents the GERS ID and is populated from the id column in the Overture data schema | - | `record_id` | string | represents the id of the feature as it is in the source data provider (e.g. n2757802019@9) and is populated by parsing the sources column in the Overture data schema | - | `update_time` | string | represents the time the feature or dataset was updated, depending on the data provider; also populated by parsing the sources column in the Overture schema | - | `dataset` | string | represents the name of the dataset the feature has been provided in; also populated by parsing the sources column in the Overture data schema | - | `theme` | string | represents the theme the feature is a part of, provided by the creator of the bridge file itself | - | `type` | string | represents the type of the feature, either derived from the data or provided by the creator of the bridge file | - -| `between` | array | represents the portion of the normalized length of the GERS feature the dataset way takes, represented by a range between 0 and 1 | - -| `dataset_between` | array | represents the portion of the normalized length of the dataset way the GERS feature takes, represented by a range between 0 and 1 | +| `between` | array | represents the portion of the normalized length of the GERS feature the dataset way takes, represented by a range between 0 and 1 +| `dataset_between` | array | represents the portion of the normalized length of the dataset way the GERS feature takes, represented by a range between 0 and 1 | -## Using bridge files +## Example: examining the source data for the `building` dataset -Let's trace buildings data in the latest release back to the underlying source datasets. We'll examine an area near the US-Mexico border outside San Diego. - -First, get the buildings in our area of interest: +In this example, we'll trace the buildings data in the latest release back to the underlying source datasets. We'll examine an area near the US-Mexico border outside San Diego. First, let's get the buildings in our area of interest: ```sql CREATE TABLE IF NOT EXISTS border_buildings AS @@ -87,12 +84,12 @@ bbox.xmin > -117.048198 AND bbox.xmax < -117.044608 AND bbox.ymin > 32.535068 AND bbox.ymax < 32.600154); ``` -Your table has 4367 building features in the latest release for your area of interest. Now let's look at a count of these building features by data source: +You'll notice the table has 4367 `building` features. Now let's look at the `building` count by data source: -``` +```sql SELECT -sources[1].dataset AS source, -count(*) + sources[1].dataset AS source, + count(*) FROM border_buildings GROUP BY source; ``` @@ -109,7 +106,7 @@ GROUP BY source; └────────────────────────┴──────────────┘ ``` -Now use the bridge file to find additional source data from the Overture corpus that didn't make it into the release. Join the data from the release with the bridge file data to create a detailed view of the source mappings. _Remember: we only have bridge files for Esri Community Maps data and OpenStreetMap data._ +Now we'll use the latest bridge file to find additional information about data in the Overture corpus that didn't make it into the release. We'll join the table we created from the release data with the bridge file data to create a new table that has detailed view of the source mappings. _Remember: we only have bridge files for Esri Community Maps data and OpenStreetMap data._ ```sql CREATE TABLE IF NOT EXISTS border_buildings_corpus AS @@ -125,12 +122,12 @@ ON border_buildings.id = bridge.id ORDER BY border_buildings.id, bridge.dataset); ``` -Notice that the bridge file results show 2,021 total records compared to 4,367 buildings in the original query. This is because we have incomplete bridge file coverage for buildings. We don't generate bridge files for Microsoft ML Buildings, Google Open Buildings, and Meta Buildings because those sources don't have meaningful IDs for reverse lookup. However, the source mappings that do exist for buildings reveal important patterns: +You might notice this new table created from our join has only 2,021 records compared to 4,367 `building` records in our original query of the latest release data. This is because we have incomplete bridge file coverage for buildings; we don't generate bridge files for Microsoft ML Buildings, Google Open Buildings, and Meta Buildings because those sources don't have meaningful IDs for reverse lookup. However the bridge files that do exist for buildings reveal important patterns: - Multiple sources per building: a single Overture building may be conflated from multiple source datasets - One-to-many mapping: each source contribution gets its own bridge file record -Let's dig into this a bit more. We can identify the buildings in the release that have multiple sources mappings. +Let's dig into this a bit more. We can identify the `building` features in the release that have multiple source mappings. ``sql -- Identify buildings conflated from multiple sources @@ -142,7 +139,7 @@ GROUP BY gers_id HAVING COUNT(DISTINCT dataset) > 1; ``` -There are 70 buildings with that are mapped to two data sources. +There are 70 buildings with that are mapped to two data sources. Here's a snippet of the query result: ``` ┌──────────────────────────────────┬──────────────┬────────────────────────────────────┐ @@ -168,16 +165,6 @@ Let's pull out one example: | 08b29a4c428ebfff02002b827866f466 | Esri Community Maps | esri_ChulaVistaCA13510 | 2024-10-15T00:00:00.000Z | | 08b29a4c428ebfff02002b827866f466 | OpenStreetMap | w1182486582@1 | 2023-06-16T14:22:10.000Z | -This shows that building `08b29a4c428ebfff02002b827866f466` was created by a conflation process that definitely included data from OpenStreetMap (way 1182486582, version 1) and Esri Community Maps (esri_ChulaVistaCA13510) and may have included other data sources that have not been mapped to GERS. - - -## Bridge file limitations - -**Missing bridge files**: some datasets (Microsoft ML Buildings, Google Open Buildings, Meta Buildings) don't have bridge files because they lack meaningful source IDs for reverse lookup. - -**Linear feature complexity**: transportation segments may have complex geometry relationships captured in the `between` and `dataset_between` fields - -**Update frequency**: bridge files are generated per release and reflect conflation decisions at release time - +This shows that building `08b29a4c428ebfff02002b827866f466` was created by a conflation process that included data from OpenStreetMap (way 1182486582, version 1) and Esri Community Maps (esri_ChulaVistaCA13510). The conflation process _may_ have included other data sources that have not been mapped to GERS and released as bridge files. Bridge files provide essential transparency into Overture's conflation process, enabling users to understand data provenance and trace features back to their source datasets. diff --git a/docs/gers/index.mdx b/docs/gers/index.mdx index 03c02e0ec..fdbe217cd 100644 --- a/docs/gers/index.mdx +++ b/docs/gers/index.mdx @@ -19,7 +19,7 @@ The "S" in GERS stands for a *system*, with the following components: | [Overture reference map](/#overture-data) | consists of the canonical datasets Overture releases each month | | Global registry of GERS IDs | catalogs all GERS IDs ever published | | [Data changelog](changelog) | describes changes to entities across releases | -| [Bridge files](bridgefiles) | connects the GERS IDs in a release to the IDs from the underlying source data | +| [Bridge files](bridge-files) | connects the GERS IDs in a release to the IDs from the underlying source data | ## How does GERS work? From 10c3cd1b25c6c39b9079829f87b9f19d57cbde6c Mon Sep 17 00:00:00 2001 From: Dana Bauer Date: Tue, 24 Jun 2025 18:15:02 -0400 Subject: [PATCH 3/4] add next steps --- docs/gers/bridge-files.mdx | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/docs/gers/bridge-files.mdx b/docs/gers/bridge-files.mdx index 9be24f06a..358021e7b 100644 --- a/docs/gers/bridge-files.mdx +++ b/docs/gers/bridge-files.mdx @@ -3,6 +3,8 @@ title: Bridge Files --- import QueryBuilder from '@site/src/components/queryBuilder'; +## What are bridge files? + With each release Overture generates **bridge files** that connect GERS IDs to the IDs from the [source data](/attribution). These files are a key component of GERS and offer two critical capabilities: reverse lookup of source features and insight into Overture's conflation process. Here's how to get the bridge files: @@ -129,7 +131,7 @@ You might notice this new table created from our join has only 2,021 records com Let's dig into this a bit more. We can identify the `building` features in the release that have multiple source mappings. -``sql +```sql -- Identify buildings conflated from multiple sources SELECT gers_id, COUNT(DISTINCT dataset) as source_count, @@ -156,10 +158,12 @@ There are 70 buildings with that are mapped to two data sources. Here's a snippe │ 08b29a4c42809fff02000729055d0147 │ 2 │ Esri Community Maps, OpenStreetMap │ │ 08b29a4c428ccfff02002cbabfaf31e0 │ 2 │ Esri Community Maps, OpenStreetMap │ │ 08b29a4c4280bfff02003a1e8ccaeb68 │ 2 │ Esri Community Maps, OpenStreetMap │ + ... ``` Let's pull out one example: + | gers_id | dataset | dataset_record_id | update_time | | ---- | ---- | ---- | ---- | | 08b29a4c428ebfff02002b827866f466 | Esri Community Maps | esri_ChulaVistaCA13510 | 2024-10-15T00:00:00.000Z | @@ -167,4 +171,7 @@ Let's pull out one example: This shows that building `08b29a4c428ebfff02002b827866f466` was created by a conflation process that included data from OpenStreetMap (way 1182486582, version 1) and Esri Community Maps (esri_ChulaVistaCA13510). The conflation process _may_ have included other data sources that have not been mapped to GERS and released as bridge files. -Bridge files provide essential transparency into Overture's conflation process, enabling users to understand data provenance and trace features back to their source datasets. +## Next steps +- Explore the other components of GERS: registry, [changelog](../changelog), and [reference map](https://explore.overturemaps.org/#15/38.90678/-77.03649) +- Follow our [GERS tutorial](../gers-tutorial) + From 640a35e240244f31b83d073fd580d6f052b0e759 Mon Sep 17 00:00:00 2001 From: Dana Bauer Date: Tue, 24 Jun 2025 18:44:42 -0400 Subject: [PATCH 4/4] add reverse lookup info --- docs/gers/bridge-files.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/gers/bridge-files.mdx b/docs/gers/bridge-files.mdx index 358021e7b..1b4b26204 100644 --- a/docs/gers/bridge-files.mdx +++ b/docs/gers/bridge-files.mdx @@ -17,7 +17,7 @@ Here's how to get the bridge files: The latest Overture data `` is: :::note -Currently, Overture only provides bridge files for these source datasets: Esri Community, geoBoundaries, Instituto Geográfico Nacional (España)Maps, Meta, Microsoft, OpenStreetMap, PinMeTo +Currently, Overture only generates bridge files for these source datasets: Esri Community Maps, geoBoundaries, Instituto Geográfico Nacional (España), Meta Places, Microsoft Places, OpenStreetMap, PinMeTo. ::: ## Partitioning and schema @@ -172,6 +172,7 @@ Let's pull out one example: This shows that building `08b29a4c428ebfff02002b827866f466` was created by a conflation process that included data from OpenStreetMap (way 1182486582, version 1) and Esri Community Maps (esri_ChulaVistaCA13510). The conflation process _may_ have included other data sources that have not been mapped to GERS and released as bridge files. ## Next steps +- Examine the source data for building `08b29a4c428ebfff02002b827866f466` by looking up the OSM ID in [OpenStreetMap](https://www.openstreetmap.org/) - Explore the other components of GERS: registry, [changelog](../changelog), and [reference map](https://explore.overturemaps.org/#15/38.90678/-77.03649) - Follow our [GERS tutorial](../gers-tutorial)