OpenStreetMap’in Harita Özelliklerini Bilgisayarlı Görüyle Uygulamak

 (blog.mozilla.ai)
3 puan yazan GN⁺ 2025-03-24 | 2 yorum | WhatsApp'ta paylaş
  • Mozilla.ai, OpenStreetMap verilerini uydu görüntüleriyle ilişkilendirerek harita nesnelerini bulan, insan doğrulamasından sonra yeniden katkı olarak gönderen OpenStreetMap AI Helper Blueprint’i yayımladı
  • Bu yaklaşım, LLM/VLM yerine YOLOv11 nesne tespiti ile SAM2 segmentasyonunu ayırarak konum belirleme ve poligon konturu oluşturma işlerini ayrı ayrı üstleniyor
  • Yüzme havuzu haritalama örneği, leisure=swimming_pool etiketi ve Mapbox döşemeleriyle eğitim verisi oluşturma ve sonuçları Hugging Face Hub’a yükleme akışını gösteriyor
  • Çıkarım sürecinde ilgi noktası çevresindeki döşemeler birleştiriliyor, ardından mevcut OpenStreetMap nesneleriyle karşılaştırılarak mükerrer adaylar hariç tutuluyor ve yalnızca yeni adaylar insan tarafından kontrol ediliyor
  • Tamamen manuel çalışmada dakikada 2–3 yüzme havuzu işlenebilirken, bu Blueprint optimize edilmemiş bir UX ile bile 10–15’e kadar çıkarak yaklaşık 5 kat hız sağlıyor

OpenStreetMap verilerini yapay zeka haritalamada kullanmanın nedeni

  • Mozilla.ai, açık işbirliği topluluklarında yapay zekanın tekrarlı ve yavaş işleri azaltabileceğini düşünerek OpenStreetMap AI Helper Blueprint’ini yayımladı
  • Amaç, yapay zekanın haritacıların yerini alması değil; hedefleri bulma ve poligon çizme süresini azaltırken insan doğrulamasını son aşama olarak korumak
    • İnsanların üstlenmeye devam etmesi gereken temel iş, üretilen harita verisinin gerçekten doğru olup olmadığını kontrol etme süreci
  • OpenStreetMap, yol, yürüyüş yolu, kafe ve tren istasyonu gibi verilerin haritacı topluluğu tarafından oluşturulup sürdürüldüğü açık düzenlenebilir bir haritadır
  • OpenStreetMap, en eksiksiz açık harita veritabanlarından biridir ve uydu görüntüleri gibi diğer kaynaklarla birleştirildiğinde yapay zeka modeli eğitim verisi olarak kullanılabilir

LLM yerine hafif bilgisayarlı görü modelleri seçildi

  • OpenStreetMap’teki birçok Map Features, poligon biçimindeki alanlar olarak temsil edilir
  • Bir insanın poligonları bulup elle çizmesi çok zaman alır; ancak yeterli veri olduğunda bilgisayarlı görü modelleri bu işe göre eğitilebilir
  • Blueprint, modern LLM dışı modelleri iki aşamaya ayırarak kullanır
    • Nesne tespiti: Ultralytics’in YOLOv11 modeli, görüntüde ilgili harita özelliğinin konumunu bulur
    • Segmentasyon: Meta’nın SAM2 modeli, tespit edilen nesnenin kesin şeklini kontur olarak rafine eder
  • YOLOv11 ve SAM2 hafif, hızlı ve yerel çalıştırmaya uygundur
    • İki modelin birleşik ağırlıkları 250 MB’ın altındadır
    • Karşılaştırma için anılan SmolVLM ise 4,5 GB’tır

Blueprint’in 3 aşamalı akışı

  • 1. aşama: OpenStreetMap’ten nesne tespiti veri kümesi oluşturma

    • OpenStreetMap verileri alınır, uydu görüntüleriyle birleştirilir ve eğitime uygun biçime dönüştürülür
    • Doğrudan çalıştırılabilir Create Dataset Colab sunulur
    • OpenStreetMap verilerini toplamak için iki API kullanılır
      • Nominatim API: Kullanıcının ilgi alanını esnek biçimde seçmesini sağlar
      • Overpass API: Seçilen alan içinde belirli bir etikete karşılık gelen poligonları indirir
    • Yüzme havuzu örneğinde eğitim için Galicia, doğrulama için Viana do Castelo kullanılır
    • Hedef etiket leisure=swimming_pool olup, yanında location=indoor etiketi bulunan hedefler hariç tutulur
    • Poligonlar indirildikten sonra bir zoom level seçilir ve bu yakınlaştırma seviyesinde poligon içeren döşemeler belirlenir
    • Döşemeler Mapbox’ın Static Tiles API üzerinden indirilir
    • Enlem-boylam koordinatlarındaki poligonlar, her döşeme bazında piksel koordinatlarındaki sınırlayıcı kutulara dönüştürülür ve Ultralytics YOLO formatında kaydedilir
    • Tamamlanan veri kümesi Hugging Face Hub’a yüklenir; örnek veri kümesi mozilla-ai/osm-swimming-pools’dur

  • 2. aşama: Nesne tespiti modelini fine-tune etme

  • 3. aşama: OpenStreetMap’e katkıda bulunma

    • Fine-tune edilmiş nesne tespiti modeliyle birden çok döşeme üzerinde çıkarım çalıştırılır
    • Doğrudan çalıştırılabilir Run Inference Colab sunulur
    • Örnek yüzme havuzu dedektörü HuggingFace Demo üzerinde denenebilir
    • Çıkarım süreci birkaç insan etkileşimi gerektirir
      • Önce haritada bir ilgi noktası seçilir
      • Seçilen noktanın çevresinde margin argümanına göre bir sınırlayıcı kutu hesaplanır
      • OpenStreetMap’ten mevcut ilgi nesneleri indirilir
      • Mapbox’tan tüm döşemeler indirilip birleştirilir ve yığın görüntü oluşturulur
      • Yığın görüntü, örtüşen döşemelere yeniden bölünür
    • Her döşeme üzerinde YOLOv11 nesne tespiti modeli çalıştırılır
    • Yüzme havuzu gibi bir ilgi nesnesi tespit edildiğinde, sınırlayıcı kutu SAM2’ye aktarılır ve segmentasyon maskesi elde edilir
    • Tahmin edilen poligonlar, OpenStreetMap’ten indirilen mevcut poligonlarla karşılaştırılarak mükerrer yüklemenin önüne geçilir
    • Yeni nesne olarak belirlenen adaylar tek tek gösterilir ve kullanıcı bunları manuel olarak doğrulayıp filtreler
    • Kullanıcının korumayı seçtiği nesneler tek bir changeset olarak OpenStreetMap’e yüklenir

Performans ve pratik etkileri

  • OpenStreetMap AI Helper Blueprint, yapay zekanın insanların harita katkılarını güçlendirirken insan doğrulamasını merkezde tutabileceğini gösterir
  • Tamamen manuel süreçte dakikada 2–3 yüzme havuzu haritalanabilir
  • Blueprint kullanıldığında UX optimize edilmemiş olsa bile aynı sürede 10–15 yüzme havuzu haritalanabilir; bu yaklaşık 5 kat daha fazladır
  • Kaliteli OpenStreetMap verisi varsa YOLOv11 gibi modeller eğitilerek nesne tespiti yaptırılabilir
  • Her probleme LLM uygulamak gerekmez; harita özelliği tespiti ve poligon üretimi için hafif bilgisayarlı görü kombinasyonu daha doğrudan bir seçenek olabilir
  • Başka harita özellikleri için model eğitmek veya depoya katkıda bulunmak istiyorsanız OpenStreetMap AI Helper Blueprint’i kullanabilirsiniz
  • Yayımlanan diğer Blueprint’ler Blueprints Hub’da bulunabilir

İlgili okumalar

2 yorum

 
depth221 2025-03-24

Araştırınca, Map Feature’ın genelde (harita) coğrafi unsur olarak çevrildiğini gördüm.
 
GN⁺ 2025-03-24
Hacker News yorumları

  • OpenStreetMap Foundation açısından yapay zekanın tespit ettiği nesnelerin doğrudan veritabanına eklenmemesi gerekir.
    Algoritmalarda yanlış pozitif sorunu var; ayrıca sondan bir önceki ekran görüntüsünde olduğu gibi düz çizgili ve dikdörtgen nesneleri titrek biçimde haritalama sorunu da var.
    Eksik nesneleri bulmak için yardımcı araç olarak değerli, ancak tespit edilen nesnenin doğru çizilip çizilmediğini doğrulamak için hâlâ insan müdahalesi gerekiyor.
    Referans: https://wiki.openstreetmap.org/wiki/Import/Guidelines ve https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_...

    • Demo uygulamada ve sağlanan kod örneklerinde, tespit edilen nesnelerin bir insan tarafından doğrulanmasını gerektiren bir adım bulunuyor.
      Kaynak kodu değiştirmeden otomatik yükleme yapılamıyor; belgelerde, bağlantı verilen yazılarda ve kod örneklerinde insan doğrulaması tekrar tekrar vurgulandı.
      Nesneler hiçbir zaman otomatik olarak yüklenmedi; ilk sürümü eğitmeden önce de yüzlerce yüzme havuzu örneğini bizzat düzenleyip etiketledim.
      Nesnelerin otomatik yüklenmesini engellemek için süreci iyileştirecek fikirleriniz varsa duymak ve uygulamak isterim.
      Aracın hiç yayımlanmaması gerektiğini söyleyen tepkiler de olacaktır; ancak yapay zekayı benimserken bunu açıkça tartışan daha iyi bir yolun mümkün olduğunu düşünüyorum.
    • Ekran görüntüsündeki titrek poligonlar, görüntünün üzerine bindirmek için maske olarak çizilmiş gösterim amaçlı poligonlar olduğu için böyle; gerçekte yüklenen poligonlarda bu titreme yok.
      Tahmin poligonlarının gerçekten titrediği durumlar olabiliyor; bu yüzden bu tür sonuçların atılmasını öneriyorum.
      Yine de asgari kaliteye ulaşan modelin ilk sürümü çıkana kadar bu demoyu yayımlamadım.
      Kodda ayrıca tahmin poligonlarının düğüm sayısının aşırı artmaması için şekil sadeleştirme mantığı da var.
    • Makine öğrenmesinden türetilen nesnelere etiket eklemek iyi olurdu.
      Bu tür araçların zaten yarı otomatik biçimde kullanılıyor olma ihtimali yüksek; bu da veritabanının bütünüyle kirlenmesini azaltmaya yardımcı olabilir.

  • Yüzme havuzu tespiti iyi; güneş enerjisi tespiti de denemek istediğim şeyler listesinde.
    Buradaki tepkilerin önemli bir kısmı, OSM’nin yalnızca elle haritalamayla büyüyebileceği varsayımından geliyor gibi geliyor.
    Ancak 10 yıl boyunca 60 bin değişiklik kümesi oluşturmuş biri olarak, dünya ölçeğinde harita verilerini ezici ölçüde faydalı kılacak seviyeye yalnızca gönüllü coşkusuyla haritalama yaparak “çözüm” bulunabileceğini sanmıyorum.
    Veri içe aktarma ve bakım için ölçeklenebilir bir çerçeveye ihtiyaç var: kalite, kaynak, veri kaynağı hatalarının nereye bildirileceği hakkında not bırakma yöntemleri ve tüketicilere yönelik yönergeler gibi şeyler.
    Örneğin “son 1 yıl içinde bir insan tarafından haritalanmış X türündeki işletmeler” için sorgu yapmak isterseniz, check date ile bu bir ölçüde mümkün.
    Ancak bu niteliğin ne kadar doğru olduğunu ya da doğrulamayı yapan haritacının yalnızca ad veya konum gibi tek bir yönü kontrol edip etmediğini bilmek zor.
    alltheplaces’ın çalışma saatleri verisini her ay otomatik olarak içe aktarıp güncel tutmak daha iyi olabilir.
    Veri tüketicisi açısından, yalnızca güvendiği belirli kaynakları filtreleyebilmek ya da poligon mükemmel olmasa bile “yapay zeka ile çıkarılmış ilgi noktası” gibi bilinen sınırlamaları olan verilerden yararlanabilmek daha iyi olabilir.

  • Otomatik haritalamayı bizzat deneyimleyince aşırı temkinli oluyorsunuz.
    Motosikletle Güney Amerika’yı baştan başa geçtim; OSM’de özellikle Brezilya’da otomatik gibi görünen çok sayıda düzenleme vardı ve bazı bölgelerde harita neredeyse kullanılamayacak durumdaydı.
    Bu yalnızca kırsal yollar için değil, oldukça büyük şehirlerde de böyleydi.

    • Masa başından uzaktan haritalama her zaman kötü haritalar üretebilir.
      Seyahat ederken genelde mapwithme kullanıyorum ve sorunu açıklayan fotoğraflı notlar bırakmaya çalışıyorum.
      Ben daha çok çitlerin ve oyun alanlarının fotoğrafını çekiyorum; başkaları manzara fotoğrafları çekiyor.
      Otomatik haritalama olabilir, ama benim uzaktan yaptığım haritalama da sahada kontrol edildiğinde bazen epey berbat çıkabiliyor.
    • Brezilya’nın hangi bölgesi olduğunu merak ediyorum.

  • Birkaç yıl önce bu alanda çalışmıştım; mevcut modeller, veri kümeleri ve araçlar inanılmaz derecede fazla.
    https://github.com/satellite-image-deep-learning

    • Harika bir kaynak derlemesi.
      QGIS ile kurcalarken, kamuya açık ve özel uydu görüntüsü API’lerinin birkaçına kaydolup veri çekerek denemeler yapıyordum.
      AB uzay ajansında kullanıcı hesabı olmadan bile tamamen açık erişilebilen çok sayıda iyi veri kaynağı var.
      Bu yeni makine öğrenmesine özel araç setiyle çalışmayı sabırsızlıkla bekliyorum.

  • Google buna izin vermez ama Mapbox, ticari olmayan amaçlar veya OSM kullanımı için izin veriyor gibi görünüyor
    Ancak bu yalnızca Mapbox’ın vektör verisi değil, uydu verisi kullanıldığında mümkün
    Şartlarda, müşterilerin hizmet çıktılarındaki içerik, veri veya bilgileri izlememesi ya da bunlardan türev üretmemesi/çıkarmaması gerektiği yazıyor; ancak yalnızca uydu görüntülerinden oluşan Mapbox Maps’in Studio veya üçüncü taraf yazılımlarla izlenerek türev bir vektör veri kümesi oluşturulabileceğine dair bir istisna var ve bunun amacının ticari olmayan amaçlar ya da OpenStreetMap olması gerektiği belirtiliyor
    Mapbox bu konuda oldukça makul davranmış sayılır

  • Birkaç ay önce benzer bir şey üzerinde çalışmıştım
    Daha küçük ölçekli coğrafi veriler için olsa da: https://github.com/uav4geo/GeoDeep

    • Harika bir çalışma; iş birliği fikirlerini konuşmak isterim

  • Uydu görüntülerinde görünen şeyleri değil, sahadaki gerçekleri haritalamak gerekir
    Yapay zekanın halüsinasyon gördüğü şeyler kesinlikle katkı olarak eklenmemeli

    • OSM’de izleme için esas alınan kaynak çoğu zaman zaten uydu görüntüleri oluyor
      Bu izlemenin kalitesi zaman zaman ciddi biçimde tutarsız olabiliyor; yolların denizin üzerine yerleştiği garip şekilde kaymış kıyı çizgilerini defalarca düzeltmek zorunda kaldım
      Bu araç belli ölçüde tutarlıysa, ortalama bir OSM katkıcısından daha iyi bile olabilir
      Yine de evleri, yolları ve su alanlarını segmentlere ayırıp mevcut verilerle karşılaştırarak tutarsızlıkları düzeltme adayı olarak vurgulamakla başlamak iyi olur

  • Mozilla iyi bir tarayıcı yapmaya odaklansa olmaz mı?

  • Havuzları veya güneş paneli dizilerini tespit edecek şekilde SAM/2’ye ince ayar yapmanın ayrıntılarını daha fazla görmek isterim
    İkisi de topluluk dayanıklılığı projelerinde haritalanmış olsa çok faydalı olurdu; ancak SAM2 ince ayarını takip etmek zordu
    Yolov8 modeliyle güneş panellerini bulmak ve segmentlere ayırmak oldukça iyi çalışıyor, fakat kenarlar o kadar dağınık ki temizlemek için muazzam iş gerekiyor
    Eğitilmiş SAM2 sonuçlarını gördüm ve çok daha iyi görünüyordu
    Doğruluk sorunları nedeniyle OSM’ye koymazdım ama başka yerlerde yeterince kullanılabilir

    • Bu projede SAM2 ince ayarı yok
      OSM’deki segmentasyon verileri, bir segmentasyon modelini düzgün eğitmek için yeterli kalitede değil
      Burada sınırlayıcı kutu tahmini için YOLO modeli kullanılıyor
      OSM’deki sınırlayıcı kutular bu amaç için yeterli; her sınırlayıcı kutu SAM2’ye prompt olarak verilip iç kısmı segmentlere ayırması sağlanıyor
      Kutunun merkez noktasını SAM’e prompt olarak verme yöntemini de denedik ama sonuçlar daha kötüydü

  • Çeşitli geri bildirimleri yansıtarak yeni bir sürüm çıkardık ve OSM’ye doğrudan yükleme yapan tüm kodu OsmChange biçiminde dışa aktarma ile değiştirdik
    Umarım doğru yönde atılmış bir adımdır; OSM forumundaki özel başlıkta tartışmayı sürdüreceğiz