Computer Vision से लागू किए गए OpenStreetMap के मैप फीचर्स
(blog.mozilla.ai)- Mozilla.ai ने OpenStreetMap AI Helper Blueprint जारी किया है, जो OpenStreetMap डेटा और सैटेलाइट इमेजरी को जोड़कर मैप ऑब्जेक्ट्स खोजता है, उन्हें इंसानों से verify कराता है और फिर वापस योगदान करता है
- यह तरीका LLM/VLM के बजाय YOLOv11 object detection और SAM2 segmentation को अलग-अलग इस्तेमाल करता है, ताकि लोकेशन पहचान और polygon outline बनाना अलग-अलग संभाला जा सके
- स्विमिंग पूल mapping का उदाहरण
leisure=swimming_pooltag और Mapbox tiles से training data बनाने और परिणामों को Hugging Face Hub पर अपलोड करने का flow दिखाता है - inference प्रक्रिया में, रुचि के point के आसपास की tiles को जोड़ने के बाद मौजूदा OpenStreetMap objects से तुलना की जाती है, duplicate candidates को हटाया जाता है, और सिर्फ नए candidates इंसान confirm करते हैं
- पूरी तरह manual काम में 1 मिनट में लगभग 2–3 swimming pools map हो पाते हैं, लेकिन यह Blueprint unoptimized UX में भी 10–15 तक process करता है, यानी करीब 5x तेज़ है
AI mapping के लिए OpenStreetMap डेटा क्यों इस्तेमाल करें
- Mozilla.ai का मानना है कि open collaboration communities में AI repetitive और धीमे काम को घटा सकता है, इसलिए उसने OpenStreetMap AI Helper Blueprint जारी किया
- लक्ष्य AI से map makers को replace करना नहीं है, बल्कि target ढूंढने और polygons draw करने में लगने वाला समय घटाते हुए human verification को अंतिम चरण के रूप में बनाए रखना है
- इंसानों के पास बने रहने वाला मुख्य काम यह verify करना है कि generated map data सच में सही है या नहीं
- OpenStreetMap एक open editable map है, जिसमें roads, walking trails, cafés, railway stations जैसे डेटा को mapper community बनाती और maintain करती है
- OpenStreetMap सबसे complete open map databases में से एक है, और satellite imagery जैसे दूसरे sources के साथ combine करने पर इसे AI model training data के रूप में इस्तेमाल किया जा सकता है
LLM के बजाय हल्के Computer Vision models चुने गए
- OpenStreetMap के कई Map Features polygon-shaped areas के रूप में represent होते हैं
- इंसानों के लिए polygons ढूंढना और उन्हें खुद draw करना काफी time-consuming है, लेकिन पर्याप्त data होने पर computer vision models को इस काम के लिए train किया जा सकता है
- Blueprint latest non-LLM models को दो stages में बांटकर इस्तेमाल करता है
- YOLOv11 और SAM2 हल्के, तेज़ और local execution के लिए suitable हैं
- दोनों models के combined weights 250MB से कम हैं
- comparison के तौर पर उल्लेखित SmolVLM 4.5GB है
Blueprint का 3-stage flow
-
Stage 1: OpenStreetMap से object detection dataset बनाना
- OpenStreetMap data लाकर उसे satellite imagery के साथ combine किया जाता है और training-friendly format में convert किया जाता है
- सीधे run किया जा सकने वाला Create Dataset Colab दिया गया है
- OpenStreetMap data collection के लिए दो APIs इस्तेमाल होती हैं
- Nominatim API: users को area of interest flexible तरीके से चुनने देता है
- Overpass API: चुने गए area के अंदर किसी specific tag से जुड़े polygons download करता है
- swimming pool example में training के लिए Galicia, validation के लिए Viana do Castelo इस्तेमाल किया गया
- target tag leisure=swimming_pool है, और location=indoor साथ में लगे targets को exclude किया गया
- polygons download करने के बाद zoom level चुना जाता है, और उस zoom level पर polygons वाली tiles identify की जाती हैं
- Mapbox के Static Tiles API से tiles download की जाती हैं
- latitude-longitude coordinates वाले polygons को हर tile के हिसाब से pixel-coordinate bounding boxes में convert किया जाता है और Ultralytics YOLO format में save किया जाता है
- तैयार dataset Hugging Face Hub पर upload किया जाता है; example dataset mozilla-ai/osm-swimming-pools है
-
Stage 2: object detection model fine-tuning
- dataset format तैयार हो जाने पर YOLOv11 या Ultralytics द्वारा supported किसी अन्य model को fine-tune किया जा सकता है
- सीधे run किया जा सकने वाला Finetune Model Colab दिया गया है
- available hyperparameters Ultralytics के training settings docs में देखे जा सकते हैं
- trained model भी Hugging Face Hub पर upload किया जाता है
- example model mozilla-ai/swimming-pool-detector है
-
Stage 3: OpenStreetMap में योगदान करना
- fine-tuned object detection model से कई tiles पर inference run किया जाता है
- सीधे run किया जा सकने वाला Run Inference Colab दिया गया है
- example swimming pool detector को HuggingFace Demo में try किया जा सकता है
- inference प्रक्रिया में कुछ human interactions की जरूरत होती है
- पहले map पर point of interest चुना जाता है
- चुने गए point के आसपास
marginargument के अनुसार bounding box calculate होता है - OpenStreetMap से मौजूदा objects of interest download किए जाते हैं
- Mapbox से सभी tiles download करके merge की जाती हैं और stack image बनाई जाती है
- stack image को फिर overlapping tiles में split किया जाता है
- हर tile पर YOLOv11 object detection model run होता है
- swimming pool जैसे object of interest detect होने पर bounding box को SAM2 को दिया जाता है, जिससे segmentation mask मिलता है
- predicted polygons की OpenStreetMap से download किए गए मौजूदा polygons से तुलना होती है, ताकि duplicate uploads से बचा जा सके
- नए object के रूप में पहचाने गए candidates एक-एक करके दिखाए जाते हैं, और user manually verify/filter करता है
- user जिन objects को रखने का चुनाव करता है, वे एक changeset के रूप में OpenStreetMap पर upload होते हैं
Performance और practical implications
- OpenStreetMap AI Helper Blueprint दिखाता है कि AI इंसानी map contributions को मजबूत कर सकता है और फिर भी human verification को center में रख सकता है
- पूरी तरह manual process में 1 मिनट में 2–3 swimming pools map किए जा सकते हैं
- Blueprint इस्तेमाल करने पर UX optimized न होने के बावजूद उसी समय में 10–15 swimming pools map किए जा सकते हैं, यानी लगभग 5x अधिक
- high-quality OpenStreetMap data हो तो YOLOv11 जैसे models को train करके object detection कराया जा सकता है
- हर problem पर LLM लागू करने की जरूरत नहीं है; map feature detection और polygon generation के लिए lightweight computer vision combination ज्यादा direct choice हो सकता है
- अगर आप दूसरे map features के लिए models train करना चाहते हैं या repository में contribute करना चाहते हैं, तो OpenStreetMap AI Helper Blueprint इस्तेमाल कर सकते हैं
- प्रकाशित दूसरे Blueprints Blueprints Hub पर देखे जा सकते हैं
2 टिप्पणियां
देखने पर लगा कि Map Feature का अनुवाद आम तौर पर (मानचित्र) भू-तत्व के रूप में किया जाता है।
Hacker News की राय
OpenStreetMap Foundation के नज़रिए से AI द्वारा पहचाने गए फीचर्स को सीधे database में नहीं जोड़ा जाना चाहिए
Algorithms में false positive की समस्या होती है, और अंत से दूसरे screenshot की तरह सीधी रेखाओं/आयताकार objects को डगमगाते आकार में map करने की समस्या भी होती है
छूटे हुए फीचर्स खोजने के लिए यह एक मूल्यवान सहायक tool है, लेकिन पहचाना गया object सही तरह से बनाया गया है या नहीं, यह जांचने के लिए अब भी मानवीय हस्तक्षेप जरूरी है
संदर्भ: https://wiki.openstreetmap.org/wiki/Import/Guidelines और https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_...
source code बदले बिना automatic upload नहीं किया जा सकता, और documentation, linked article तथा code samples में बार-बार human verification पर जोर दिया गया है
फीचर्स को कभी automatic रूप से upload नहीं किया गया है, और पहले version को train करने से पहले भी सैकड़ों swimming pool samples को खुद edit और label किया गया था
automatic feature uploads रोकने के लिए प्रक्रिया सुधारने के आपके पास ideas हों, तो सुनना और implement करना चाहूंगा
कुछ लोग शायद कहेंगे कि tool को public ही न किया जाए, लेकिन मुझे लगता है कि AI को अपनाते हुए खुले तौर पर चर्चा करने का बेहतर तरीका संभव है
prediction polygons में डगमगाहट कभी-कभी सच में होती है, इसलिए ऐसे results को discard करने की सलाह दी जाती है
फिर भी, minimum quality तक पहुंचने वाले model का पहला version आने से पहले यह demo public नहीं किया गया था
code में prediction polygons के nodes बहुत ज्यादा न हो जाएं, इसके लिए shape simplification logic भी शामिल है
ऐसे tools पहले से semi-automatic तरीके से इस्तेमाल हो रहे होने की काफी संभावना है, और यह पूरे database के contaminate होने को कम करने में मदद कर सकता है
swimming pool detection अच्छा है, और solar detection भी उन चीजों की list में है जिन्हें try करना चाहता हूं
यहां के विरोध का बड़ा हिस्सा इस धारणा से आता लगता है कि OSM सिर्फ हाथ से mapping करके ही बढ़ सकता है
लेकिन 10 साल में 60 हजार changesets बनाने वाले व्यक्ति के तौर पर, दुनिया भर के पैमाने पर map data को बेहद उपयोगी बनाने के स्तर तक सिर्फ volunteer enthusiasm से mapping “solve” नहीं की जा सकती
data import और maintenance के लिए scalable framework चाहिए: quality, provenance, data source bugs कहां report करें—इन्हें notes में छोड़ने के तरीके, और consumers के लिए guidelines जैसी चीजें
उदाहरण के लिए, अगर “पिछले 1 साल में किसी इंसान द्वारा mapped X प्रकार का business” query करना हो, तो
check dateसे कुछ हद तक संभव हैलेकिन वह attribute कितना accurate है, या verify करने वाले mapper ने सिर्फ नाम या location जैसे किसी एक पहलू को ही देखा था या नहीं, यह जानना मुश्किल है
alltheplaces के opening hours data को हर महीने automatic रूप से import करके maintain करना बेहतर हो सकता है
data consumer के नजरिए से, अगर वे सिर्फ अपने भरोसे के खास sources को filter कर सकें, या polygon perfect न होने पर भी “AI से inferred point of interest” जैसी ज्ञात सीमाओं वाले data का उपयोग कर सकें, तो यह बेहतर हो सकता है
https://community.openstreetmap.org/t/what-you-think-about-i...
https://www.openstreetmap.org/user/Mateusz%20Konieczny%20-%2...
https://codeberg.org/matkoniecz/list_how_openstreetmap_can_b...
मौजूदा स्थिति में यह inspiration तो दे सकता है, लेकिन OpenStreetMap के साथ compatible नहीं है
solar panels और solar thermal collectors में फर्क कैसे किया जाए, यह स्पष्ट नहीं है
दिखने में वे लगभग एक जैसे होते हैं, लेकिन उनका function बहुत अलग होता है
automatic mapping को खुद अनुभव कर लें तो इंसान बेहद सावधान हो जाता है
मैंने motorcycle से South America पार किया था, और OSM में खासकर Brazil में automatic लगने वाले edits बहुत थे; कुछ इलाकों में तो यह लगभग इस्तेमाल के लायक नहीं था
यह सिर्फ rural roads में नहीं, बल्कि काफी बड़े शहरों में भी था
travel करते समय मैं आम तौर पर mapwithme इस्तेमाल करता हूं, और समस्या बताने वाले photo notes छोड़ने की कोशिश करता हूं
मैं fences और playgrounds की photos खींचता हूं, जबकि दूसरे लोग scenery photos खींचते हैं
यह automatic mapping भी हो सकती है, लेकिन मेरी अपनी remote mapping भी field में verify करने पर काफी बिखरी हुई निकलती है
कुछ साल पहले मैंने इस क्षेत्र में काम किया था, और existing models, datasets, tools की संख्या बहुत ज्यादा है
https://github.com/satellite-image-deep-learning
QGIS के साथ experiment करते हुए मैं कई public और private satellite imagery APIs में sign up करके data ला रहा था और experiments कर रहा था
EU space agency के पास कई अच्छे data sources हैं, जिनके लिए user account के बिना भी पूरी तरह public access मिलता है
इस नए machine learning-focused tool collection के साथ काम करने का इंतजार है
Google शायद इसकी अनुमति नहीं देगा, लेकिन Mapbox गैर-व्यावसायिक उद्देश्यों या OSM उपयोग के लिए अनुमति देता लगता है
हालांकि, यह तभी संभव है जब Mapbox के vector data नहीं बल्कि satellite data का उपयोग किया जाए
शर्तों में कहा गया है कि ग्राहक service offerings से content, data या information को trace, derive या extract नहीं कर सकते, लेकिन एक exception है कि सिर्फ satellite imagery से बने Mapbox Maps को Studio या third-party software से trace करके derived vector dataset बनाया जा सकता है, और उसका उद्देश्य non-commercial purpose या OpenStreetMap होना चाहिए
कह सकते हैं कि Mapbox ने काफी ठीक रियायत दी है
https://wiki.openstreetmap.org/wiki/Bing_Maps#Aerial_imagery
कुछ महीने पहले ऐसा ही कुछ काम किया था
हालांकि यह छोटे पैमाने के geographic data के लिए है: https://github.com/uav4geo/GeoDeep
satellite imagery में जो दिखता है उसे map करने के बजाय, ground truth वाली चीजों को map करना चाहिए
AI ने जो hallucinate किया हो, उसे कभी contribute नहीं करना चाहिए
उस tracing की quality कभी-कभी बहुत ज्यादा inconsistent होती है, और मुझे कई बार ऐसी अजीब तरह से misaligned coastlines ठीक करनी पड़ी हैं जिनमें सड़कें समुद्र के ऊपर चली गई थीं
अगर यह tool कुछ हद तक consistent है, तो यह average OSM contributor से बेहतर भी हो सकता है
हालांकि शुरुआत इस तरह करना अच्छा होगा कि घरों, सड़कों और जल क्षेत्रों को segment किया जाए, मौजूदा data से compare करके inconsistencies खोजी जाएं और उन्हें सुधार के लिए highlight किया जाए
क्या Mozilla अच्छे browser बनाने पर focus नहीं कर सकता?
swimming pools या solar arrays detect करने के लिए SAM/2 को fine-tune करने की details और देखना चाहूंगा
अगर दोनों community resilience projects में mapped हों तो बहुत उपयोगी होंगे, लेकिन SAM2 fine-tuning follow करना मुश्किल था
Yolov8 model से solar arrays ढूंढना और segment करना काफी ठीक चलता है, लेकिन edges इतने खराब होते हैं कि cleanup में बहुत ज्यादा काम लगता है
trained SAM2 results देखे थे, वे काफी बेहतर लग रहे थे
accuracy issues की वजह से इसे OSM में नहीं डालूंगा, लेकिन दूसरी जगहों पर यह पर्याप्त रूप से usable है
OSM का segmentation data इतना high-quality नहीं है कि segmentation model को ठीक से train किया जा सके
यहां bounding box prediction के लिए YOLO model का उपयोग किया गया है
OSM के bounding boxes इस use case के लिए पर्याप्त हैं, और हर bounding box को SAM2 में prompt के रूप में भेजा जाता है ताकि वह अंदर का हिस्सा segment करे
box के center point को SAM में prompt के रूप में भेजने का तरीका भी आजमाया था, लेकिन results worse थे
कई feedback शामिल करके नया release निकाला है, और OSM पर directly upload करने वाला सारा code OsmChange format में export से replace कर दिया है
उम्मीद है यह सही दिशा में एक कदम होगा, और OSM forum के dedicated thread में चर्चा जारी रखेंगे