Linux foundation 宣布 AWS, Meta, Microsoft 和 TomTom 共同創立 Overture Maps Foundation，以新的協同合作方式來建立互操作的開放地圖資料(open map data)，成為可以強化全球製圖服務的共享資產。
Overture Maps 主要有四個目的，
- 協同合作式地圖之建立(Collaborative Map Building)。因為取得多來源、高品質的地理資料是困難且昂貴，Overture Maps企圖整合地圖資料來源，包含該基金會成員、民間組織和開放資料。
- 全球實體參照系統 (Global Entity Reference System)。一個真實世界物件在不同的資料集中有各自的規範和語彙來詮釋，難以整合。Overture Maps企圖藉由提供一個連結真實物件的系統，讓不同資料集可依此參照，以簡單化互操作性(interoperability)。
- 品質確保處理 (Quality Assurance Processes)。地圖資料很容易有錯誤和資料不一致的問題，Overture Maps 的資料需要經過驗證，檢測其錯誤、毀損或塗鴨(vandalism)的情形，確保地圖資料可被使用於產品之系統中。
- 結構性資料綱要 (Structured Data Schema)。開放地圖資料缺乏可以開發地圖產品的結構，Overture Maps企圖想趨動且定義一個被共同、結構完整，和文件化的資料綱要(schema)以建立一個易於使用的地圖資料生態圈。
這四個目標都是不容易的項目，但 Overture Maps創始成員都是當代強大的資訊企業，要整合資料、建立參照系統、建立驗證機器、和制定的標準應該都不會是問題，但推的動嗎? 當今最大的商業地圖無非就是Google Maps，Google卻是不創始成員，難免讓人直覺想到Overture Maps的成立是在對抗Google Maps的獨大?!
地理實體物件的參照是一件基礎但困難的事，開放的地圖無非就是OSM (OpenStreetMap)，也被廣泛的被利用，而OSM對於真實的地理物件的定義，也就是Map Features，可是經過社群洗練下的結果，不同文化對於地理實體的認知會有不同，例如，溫泉(hot srping) 在日本人和台灣人的直覺中，可能想到的是一個放鬆的地方，所以標記為 leisure=hot_spring，但對於歐美的人而言，溫泉就是熱的泉水，分類上應該回歸到泉水應該屬於自然物的一環，因此是 nature = hot_spring，若可以泡湯的溫泉則是在加入amenity = public_bath 和 bath:type=onsen，看似簡單的溫泉，在定義上可是引起OSM社群不少的討論，因此實體參照系統單單就幾個企業來定義，可能不會有效果。
對於地圖品質驗證，可以再回到OSM來看，OSM資料品質一直是本著開源的精神，也就是Linus’ law，「足夠多的眼睛，就可讓所有問題浮現」（given enough eyeballs, all bugs are shallow），有夠多的使雨者，就可以讓地圖的錯誤減少。難道沒有人想開發驗證工具嗎? 無論是學界或業界都有許多討論，但難在什麼是「對」的地圖標準? 當一條道路用有人100個點構成，有人認為要200點才夠詳細，誰對? 可能二個人對，不同比例尺，地圖的簡化程度不同，如果早期的人用解析度較差的影像來畫，可能100點就夠了，但後來有比較高解析度的衛星影像，自然而然，就會用到比較多的點來構成，更不用說，每個人的美感和空間感不同，描繪地圖的點可能不同。當然未來是有一個可能性，是利用AI方式去擷取向量資料，這時候的標準建立，可能是在演算法了。
就結構性資料綱要而言，Overture Maps在乎的是地圖產品的結構，個人比較好奇的是地圖產品結構性綱要和一般地理資料綱要的差別在那兒? 就資料標準而言，OGC (Open Geospatial Consortium)是制定最多地理資料標準的組織，這些標準也是促使地理資料能以API的方式在網路世界中流動的關鍵，Overture Maps的地圖產品綱是建立在OGC的標準上，或是另起爐灶呢? 這部份尚未有進一步的訊息，以了解其發展方向。另一方面，就資料整合與流動而言，語意(semantics)扮演重要關鍵，若Overture Maps有野心，應該以語意網方式來思考這個資料綱要，這樣的結果，就會有點像DBpedia和Wikidata。