GeoJSON वह JSON-based format है जिसे हर आधुनिक web map पढ़ सकता है। अगर आपने कभी Leaflet map पर polygon बनाया है, MapLibre में vector layer style किया है, या PostGIS में service area store किया है, तो आप GeoJSON के साथ काम कर रहे थे, भले file extension कुछ और कहता हो।
यह guide बताती है कि GeoJSON असल में क्या है, इसके geometry types का क्या मतलब है, यह असली systems में कहाँ दिखता है, और जब GeoJSON files developer के laptop से निकलकर production में पहुँचती हैं, तो कौन से pitfalls teams को परेशान करते हैं।
GeoJSON असल में क्या है
GeoJSON भौगोलिक data structures encode करने का open format है, जिसे IETF ने 2016 में RFC 7946 के रूप में standardise किया। यह JSON का strict subset है: हर GeoJSON document valid JSON है, लेकिन spec इस बारे में rules जोड़ती है कि कौन से keys allow हैं, geometry कैसे structured है, और coordinates कैसे ordered हैं।
Format जानबूझकर छोटा है। पूरी spec में सिर्फ नौ top-level object types हैं, और एक competent developer उन सबको अपने दिमाग में रख सकता है। यही छोटापन GeoJSON को web mapping की lingua franca बनाता है: इसे पढ़ना आसान, लिखना आसान, और validate करना आसान है।
Coordinates हमेशा [longitude, latitude] के रूप में लिखे जाते हैं (तीसरी value के रूप में optional altitude के साथ), और coordinate reference system WGS84 पर fix है, वही datum जो आपके phone का GPS इस्तेमाल करता है। कोई negotiation नहीं, कोई projection metadata नहीं, axis order पर कोई debate नहीं। एक datum, एक ordering, हर जगह।
Geometry Types
GeoJSON सात geometry types define करता है। पहले तीन primitives हैं:
- Point: एक single coordinate, pins, addresses, और individual sensors के लिए इस्तेमाल होता है
- LineString: दो या अधिक coordinates की ordered list, routes, roads, और नदियों के लिए इस्तेमाल होती है
- Polygon: coordinates का closed ring (पहला और आखिरी point identical), buildings, parcels, और admin boundaries के लिए इस्तेमाल होता है
अगले तीन उन primitives के collections हैं:
- MultiPoint: एक geometry में कई points, stores की chain को single feature के रूप में represent करने में उपयोगी
- MultiLineString: कई line strings, fragmented routes या नदी systems के लिए
- MultiPolygon: कई polygons, islands वाले किसी भी देश के लिए सही choice (यानी लगभग सभी)
सातवाँ, GeometryCollection, ऊपर के किसी भी mix को रख सकता है। Spec इसे discourage करती है क्योंकि अधिकांश consumers इसे ठीक से handle नहीं करते, और आपको लगभग कभी इसकी ज़रूरत नहीं होती। अगर आप GeometryCollection की ओर हाथ बढ़ा रहे हैं, तो आमतौर पर यह संकेत है कि model FeatureCollection बनना चाहता है।
Feature और FeatureCollection
अकेला geometry शायद ही कभी useful होता है। आपको पता होना चाहिए कि यह क्या represent करता है। यही Feature का काम है: एक Feature geometry को एक properties object के साथ wrap करता है जो arbitrary metadata रखता है।
{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [4.8952, 52.3702]
},
"properties": {
"name": "Amsterdam Centraal",
"type": "station",
"platforms": 15
}
}
एक FeatureCollection Features की list है। असली दुनिया में आपको मिलने वाली लगभग हर GeoJSON file FeatureCollection होती है, क्योंकि असली datasets में कई चीज़ें होती हैं।
Crucial design choice यह है कि properties open है। Spec कुछ नहीं कहती कि उसमें कौन से keys हो सकते हैं या उन values के types क्या होने चाहिए। यह feature है, bug नहीं: इसका मतलब है कि GeoJSON street furniture, electoral boundaries, delivery zones, और AIS ship tracks के लिए काम करता है, format को extend किए बिना। इसका यह भी मतलब है कि consumers को सावधान रहना है: अगर आप properties.population के मौजूद होने पर निर्भर हैं, तो खुद validate करें, क्योंकि RFC 7946 नहीं करेगा।
GeoJSON कहाँ दिखता है
जब आप देखना शुरू करते हैं, GeoJSON geospatial stack में हर जगह है:
- Map libraries: MapLibre GL, Mapbox GL, Leaflet, और OpenLayers सब GeoJSON को layers के लिए data source के रूप में natively consume करते हैं
- Vector tile pipelines: Tippecanoe जैसे tools GeoJSON लेते हैं और MVT (Mapbox Vector Tile) sets बाहर produce करते हैं
- Map style specs: Mapbox Style Specification, जिसे MapLibre इस्तेमाल करता है, GeoJSON को first-class source type के रूप में reference करता है
- Spatial databases: PostGIS, BigQuery GIS, और Snowflake सब dedicated functions के माध्यम से GeoJSON import और export करते हैं
- API outputs: अधिकांश आधुनिक geocoding, isochrone, और routing APIs results के लिए GeoJSON Features return करते हैं, ताकि response सीधे map पर drop हो सके
- Route polylines: navigation responses में आमतौर पर route के लिए LineString geometry शामिल होती है, render होने के लिए तैयार
- Data sharing: open data portals, OpenStreetMap exports, और government boundary releases web users को target करते समय default रूप से GeoJSON पर जाते हैं
अगर कोई tool किसी भी geospatial format को बोल सकता है, तो वह लगभग निश्चित रूप से GeoJSON बोलता है।
Production में आम Pitfalls
GeoJSON पहले दिन forgiving है और नब्बेवें दिन unforgiving। Teams को पकड़ने वाले traps:
Longitude पहले. RFC 7946 order को [lon, lat] के रूप में fix करती है। इंसान, addresses, और अधिकांश documentation lat, lon लिखते हैं। उन्हें swap करना सबसे आम GeoJSON bug है, और आपका point गलत ocean में पहुँच जाता है।
Polygon winding order. RFC 7946 specify करती है कि exterior rings counter-clockwise और interior rings (holes) clockwise होने चाहिए। कई पुरानी GeoJSON files इसे ignore करती हैं। कुछ renderers परवाह नहीं करते, अन्य (विशेष रूप से Mapbox GL antimeridian-crossing polygons के साथ) polygon को आपके चाहे हुए के inverse के रूप में render करते हैं: एक छोटा island ocean में बाकी दुनिया covering एक hole बन जाता है।
Antimeridian handling. 180/-180 meridian को cross करने वाली Geometry को spec के अनुसार split करना होता है। Pacific पर खींचे गए naive polygons लंबे रास्ते planet के चारों ओर wrap हुई पतली strip के रूप में render होते हैं।
WGS84 के अलावा no native CRS support. RFC 7946 ने पुराने crs member को जानबूझकर हटा दिया। अगर आपका data किसी national grid में है (British National Grid, RD New, EPSG:3857), serialise करने से पहले आपको WGS84 में reproject करना होगा। Non-WGS84 GeoJSON emit करने वाले tools technically non-conformant हैं।
File size. लाखों detailed polygons वाली FeatureCollection gigabytes तक फूल सकती है। Browser delivery के लिए vector tiles पर switch करें, Douglas-Peucker से geometry simplify करें, या newline-delimited GeoJSON (.ndjson) से stream करें।
Validation. CI में GeoJSONLint या geojson-validation library जैसे linter इस्तेमाल करें। Build time पर invalid winding order या swapped coordinates पकड़ना customer ticket से पकड़ने से सस्ता है।
MapAtlas में GeoJSON
GeoJSON MapAtlas platform में default data exchange format है। Dynamic Maps product custom overlays, styling, और interactive layers के लिए सीधे GeoJSON sources accept करता है, बिना किसी preprocessing के।
Geocoding API matched addresses को GeoJSON Features के रूप में return करता है, ताकि forward geocode result सीधे map पर drop हो सके या fields को remap किए बिना PostGIS में store हो सके। Isochrone API travel-time areas को GeoJSON polygons के रूप में return करता है, जिसका मतलब है कि "15 minutes में पहुँच योग्य जगहें" query screen पर आने से सिर्फ एक fetch और एक addSource call दूर है।
GeoJSON glamorous नहीं है। यह JSON का छोटा, opinionated subset है, fixed coordinate order और कुछ geometry types के साथ। लेकिन यही वह format है जो आधुनिक location stack की हर layer को, spatial database से लेकर map canvas तक, इस बात पर सहमत होने देता है कि एक place क्या है। Longitude order सही रखें, winding validate करें, और बाकी stack खुद ही ठीक हो जाता है।
अक्सर पूछे जाने वाले प्रश्न
GeoJSON क्या है?
GeoJSON भौगोलिक data को encode करने का JSON-based open format है, जिसे IETF ने RFC 7946 के रूप में standardise किया है। यह geometry types का एक छोटा set (Point, LineString, Polygon, और उनके multi variants) plus Feature और FeatureCollection objects define करता है, जो geometry को arbitrary properties के साथ wrap करते हैं। Coordinates हमेशा longitude, latitude के रूप में WGS84 datum पर लिखे जाते हैं, जो हर आधुनिक web map library expect करती है।
GeoJSON और JSON में क्या अंतर है?
GeoJSON अतिरिक्त rules के साथ JSON का strict subset है। हर GeoJSON document valid JSON है, लेकिन हर JSON document valid GeoJSON नहीं है। Spec top-level object types, geometry objects का structure, coordinate ordering (longitude पहले), और coordinate reference system (WGS84) fix करती है। उन rules के बाहर कुछ भी सिर्फ JSON है जिसमें भौगोलिक data होता है।
Shapefile या KML के बजाय GeoJSON कब इस्तेमाल करना चाहिए?
जब भी data को web stack से flow करना हो: APIs, browsers, PostGIS जैसी databases, या MapLibre, Leaflet, Mapbox GL, या OpenLayers में से कोई भी। Shapefiles desktop GIS में अब भी आम हैं लेकिन चार या उससे अधिक files में ship होते हैं और 1990s का binary format इस्तेमाल करते हैं। KML Google Earth के लिए ठीक है लेकिन verbose और XML-based है। JSON APIs को छूने वाली किसी भी चीज़ के लिए GeoJSON जीतता है।
GeoJSON coordinates में longitude पहले क्यों?
RFC 7946 order को longitude, latitude, optional altitude के रूप में fix करती है। यह अधिकांश graphics और GIS systems में इस्तेमाल होने वाले x, y, z convention से match करता है। यह उस तरह से उल्टा है जैसे इंसान coordinates लिखते हैं (latitude पहले, जैसे 51.5, -0.1) और GeoJSON को हाथ से बनाते समय यह सबसे आम bug है: दोनों values swap कर दीजिए और आपका point गलत hemisphere में चला जाता है। GeoJSON में हमेशा longitude पहले।

