/
index.html
1644 lines (1375 loc) · 73.3 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="robots" content="index,follow">
<meta name="creator" content="rfcmarkup version 1.127">
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
<meta name="DC.Relation.Replaces" content="draft-butler-geojson">
<meta name="DC.Identifier" content="urn:ietf:rfc:7946">
<meta name="DC.Date.Issued" content="August, 2016">
<meta name="DC.Creator" content="Gillies, Sean">
<meta name="DC.Creator" content="Butler, H.">
<meta name="DC.Creator" content="Daly, M.">
<meta name="DC.Creator" content="Doyle, A.">
<meta name="DC.Creator" content="Schaub, T.">
<meta name="DC.Description.Abstract" content="GeoJSON is a geospatial data interchange format based on JavaScript
Object Notation (JSON). It defines several types of JSON objects and
the manner in which they are combined to represent data about
geographic features, their properties, and their spatial extents.
GeoJSON uses a geographic coordinate reference system, World Geodetic
System 1984, and units of decimal degrees.">
<!-- <link href="https://fonts.googleapis.com/css?family=Inconsolata" rel="stylesheet"> -->
<meta name="DC.Title" content="The GeoJSON Format">
<title>GeoJSON specification</title>
<style type="text/css">
@import url('https://fonts.googleapis.com/css?family=Inconsolata');
@media only screen
and (min-width: 992px)
and (max-width: 1199px) {
body { font-size: 14pt; }
div.content { width: 96ex; margin: 0 auto; }
}
@media only screen
and (min-width: 768px)
and (max-width: 991px) {
body { font-size: 14pt; }
div.content { width: 96ex; margin: 0 auto; }
}
@media only screen
and (min-width: 480px)
and (max-width: 767px) {
body { font-size: 11pt; }
div.content { width: 96ex; margin: 0 auto; }
}
@media only screen
and (max-width: 479px) {
body { font-size: 8pt; }
div.content { width: 96ex; margin: 0 auto; }
}
@media only screen
and (min-device-width : 375px)
and (max-device-width : 667px) {
body { font-size: 9.5pt; }
div.content { width: 96ex; margin: 0 1px; }
}
@media only screen
and (min-device-width: 1200px) {
body { font-size: 10pt; margin: 0 4em; }
div.content { width: 96ex; margin: 0; }
}
h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 {
font-weight: bold;
font-family:sans-serif;
font-weight: bold;
color:green !important;
margin-bottom:0;
}
h1 a, h2 a, h3 a, h4 a, h5 a, h6 a,
h1 span, h2 span, h3 span, h4 span {
color:green !important;
}
pre {
font-size: 1em;
margin-top: 0px;
margin-bottom: 0px;
}
.pre {
/*white-space: pre;*/
/*font-family: monospace;*/
font-family:sans;
white-space: normal;
}
.header{
font-weight: bold;
}
.newpage {
page-break-before: always;
}
.invisible {
text-decoration: none;
color: white;
}
a.selflink {
/*color: black;*/
text-decoration: none;
}
@media print {
body {
font-family: monospace;
font-size: 10.5pt;
}
h1, h2, h3, h4, h5, h6 {
font-size: 1em;
}
a:link, a:visited {
color: inherit;
text-decoration: none;
}
.noprint {
display: none;
}
}
@media screen {
.grey, .grey a:link, .grey a:visited {
color: #777;
}
.docinfo {
background-color: #EEE;
}
.top {
border-top: 7px solid #EEE;
}
.bgwhite { background-color: white; }
.bgred { background-color: #F44; }
.bggrey { background-color: #666; }
.bgbrown { background-color: #840; }
.bgorange { background-color: #FA0; }
.bgyellow { background-color: #EE0; }
.bgmagenta{ background-color: #F4F; }
.bgblue { background-color: #66F; }
.bgcyan { background-color: #4DD; }
.bggreen { background-color: #4F4; }
.legend { font-size: 90%; }
.cplate { font-size: 70%; border: solid grey 1px; }
}
ul {
white-space: normal;
margin-left:1em;
}
samp,code {
font-family: 'Inconsolata', monospace;
color:darkblue;
margin-bottom:1em;
font-size:0.8rem;
line-height:1;
/*font-weight:bold;*/
}
samp {
white-space: pre;
display:block;
margin-top:0.5em;
padding-left:2em;
background:hsl(240,100%,99%);
}
.main-body {
font-family:sans-serif;
position:absolute;
line-height:1.5;
max-width:60em;
font-weight:100;
/*left:20em;*/
}
body {
margin-left:23em;
}
.toc {
/*white-space: pre;*/
width: 20em;
height:100vh;
overflow-x:hidden;
overflow-y:scroll;
padding:0.5em 1em;
border-right:1px dotted lightgrey;
position:fixed;
left:0em;
top:0;
line-height:1.3;
}
a {
color:hsl(220,30%,40%);
text-decoration:dotted hsl(220,30%,40%) underline;
}
.toc a {
text-decoration: none;
}
.disclaimer {
background:hsl(60,80%,95%);
border:1px solid hsl(60,80%,45%);
padding:0.5em 1em;
font-family:sans-serif;
font-style:italic;
width:100%;
}
.disclaimer h3 {
color:black;
}
.gj-type {
color: hsl(0,80%,35%);
font-weight:500;
}
.example {
padding-left:2em;
border-left:1px solid lightgrey;
}
.note {
background: hsl(60, 80%, 90%);
border-left: 2px solid hsl(60, 80%, 60%);
padding:0.5em 3em;
}
.steve-comment {
background: hsl(240, 80%, 90%);
border-left: 2px solid hsl(240,80%, 60%);
padding: 0.5em 3em;
}
.menu {
/* position: absolute; */
height: 100px;
width: 100%;
background:white;
font-family:sans-serif;
margin-bottom:2em;
}
.menu h1 {
font-family:'Courier New', Courier, monospace;
font-size: 32pt;
}
.menu li {
font-size:16px;
}
</style>
<!--[if IE]>
<style>
body {
font-size: 13px;
margin: 10px 10px;
}
</style>
<![endif]-->
<script type="text/javascript"><!--
function addHeaderTags() {
var spans = document.getElementsByTagName("span");
for (var i=0; i < spans.length; i++) {
var elem = spans[i];
if (elem) {
var level = elem.getAttribute("class");
if (level == "h1" || level == "h2" || level == "h3" || level == "h4" || level == "h5" || level == "h6") {
elem.innerHTML = "<"+level+">"+elem.innerHTML+"</"+level+">";
}
}
}
}
var legend_html = "Colour legend:<br /> <table> <tr><td>Unknown:</td> <td><span class='cplate bgwhite'> </span></td></tr> <tr><td>Draft:</td> <td><span class='cplate bgred'> </span></td></tr> <tr><td>Informational:</td> <td><span class='cplate bgorange'> </span></td></tr> <tr><td>Experimental:</td> <td><span class='cplate bgyellow'> </span></td></tr> <tr><td>Best Common Practice:</td> <td><span class='cplate bgmagenta'> </span></td></tr> <tr><td>Proposed Standard:</td> <td><span class='cplate bgblue'> </span></td></tr> <tr><td>Draft Standard (old designation):</td> <td><span class='cplate bgcyan'> </span></td></tr> <tr><td>Internet Standard:</td> <td><span class='cplate bggreen'> </span></td></tr> <tr><td>Historic:</td> <td><span class='cplate bggrey'> </span></td></tr> <tr><td>Obsolete:</td> <td><span class='cplate bgbrown'> </span></td></tr> </table>";
function showElem(id) {
var elem = document.getElementById(id);
elem.innerHTML = eval(id+"_html");
elem.style.visibility='visible';
}
function hideElem(id) {
var elem = document.getElementById(id);
elem.style.visibility='hidden';
elem.innerHTML = "";
}
// -->
</script>
</head>
<body onload="addHeaderTags()">
<div class="menu">
<h1>geojson.win</h1>
<ul>
<li>Formal GeoJSON specification</li>
<li><a href="https://github.com/stevage/geojson-spec">Readable GeoJSON specification</a></li>
<li><a href="newline-delimited/">Newline-delimited GeoJSON specification</a></li>
</ul>
</div>
<div class="content">
<!-- <div style="height: 13px;">
<div onmouseover="this.style.cursor='pointer';" onclick="showElem('legend');" onmouseout="hideElem('legend')" style="height: 6px; position: absolute; cursor: pointer;" class="pre noprint docinfo bgblue" title="Click for colour legend."> </div>
<div id="legend" class="docinfo noprint pre legend" style="position: absolute; top: 4px; left: 4ex; visibility: hidden; background-color: white; padding: 4px 9px 5px 7px; border: 1px solid rgb(51, 68, 85);" onmouseover="showElem('legend');" onmouseout="hideElem('legend');"></div>
</div>
-->
<div class="disclaimer">
<h3 class="h3">Disclaimer</h3>
This is an unofficial, reformatted version of the official <a href="https://tools.ietf.org/html/rfc7946">RFC 7946</a>.
It includes mention of 1 <a href="https://www.rfc-editor.org/errata_search.php?rfc=7946">known errata</a>.
<p>
No wording has been intentionally changed from the official document. Some sections of RFC administration have been removed. This version has been prepared by <a href="https://github.com/stevage">Steve Bennett</a>, who had no involvement with the creation of the GeoJSON specification, nor its ongoing maintenance. Raise issues <a href="https://github.com/stevage/geojson-spec/issues">here</a>.
</p>
</div>
<!--
<span class="pre noprint docinfo top">[<a href="https://tools.ietf.org/html/" title="Document search and retrieval page">Docs</a>] [<a href="https://tools.ietf.org/rfc/rfc7946.txt" title="Plaintext version of this document">txt</a>|<a href="https://tools.ietf.org/pdf/rfc7946" title="PDF version of this document">pdf</a>] [<a href="https://tools.ietf.org/html/draft-ietf-geojson" title="draft-ietf-geojson">draft-ietf-geojson</a>] [<a href="https://datatracker.ietf.org/doc/rfc7946" title="IESG Datatracker information for this document">Tracker</a>] [<a href="https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=rfc7946" title="Inline diff (wdiff)">Diff1</a>] [<a href="https://tools.ietf.org/rfcdiff?url2=rfc7946" title="Side-by-side diff">Diff2</a>] [<a href="https://www.rfc-editor.org/errata_search.php?rfc=7946">Errata</a>]</span><br>
<span class="pre noprint docinfo"> </span><br>
<span class="pre noprint docinfo"> PROPOSED STANDARD</span><br>
-->
<!-- <span class="pre noprint docinfo"> <span style="color: #C00;">Errata Exist</span></span><br> -->
<div class="main-body">
<!-- <pre>
Internet Engineering Task Force (IETF) H. Butler
Request for Comments: 7946 Hobu Inc.
Category: Standards Track M. Daly
ISSN: 2070-1721 Cadcorp
A. Doyle
S. Gillies
Mapbox
S. Hagen
T. Schaub
Planet Labs
August 2016
</pre>
-->
<span class="h1"><h1>The GeoJSON Format</h1></span>
<h3>Abstract</h3>
GeoJSON is a geospatial data interchange format based on JavaScript
Object Notation (JSON). It defines several types of JSON objects and
the manner in which they are combined to represent data about
geographic features, their properties, and their spatial extents.
GeoJSON uses a geographic coordinate reference system, World Geodetic
System 1984, and units of decimal degrees.
<h3>Status of This Memo</h3>
This is an Internet Standards Track document.
<p>
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="https://tools.ietf.org/html/rfc7841#section-2">Section 2 of RFC 7841</a>.
<p>
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7946">http://www.rfc-editor.org/info/rfc7946</a>.
<h3>Copyright Notice</h3>
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
<p>
This document is subject to <a href="https://tools.ietf.org/html/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<!-- <h2>Table of Contents</h2> -->
<div class="toc">
<a href="#section-1">1. Introduction </a><br>
<a href="#section-1.1">1.1. Requirements Language </a><br>
<a href="#section-1.2">1.2. Conventions Used in This Document </a><br>
<a href="#section-1.3">1.3. Specification of GeoJSON </a><br>
<a href="#section-1.4">1.4. Definitions </a><br>
<a href="#section-1.5">1.5. Example </a><br>
<a href="#section-2">2. GeoJSON Text </a><br>
<a href="#section-3">3. GeoJSON Object </a><br>
<a href="#section-3.1">3.1. Geometry Object </a><br>
<a href="#section-3.1.1">3.1.1. Position </a><br>
<a href="#section-3.1.2">3.1.2. Point </a><br>
<a href="#section-3.1.3">3.1.3. MultiPoint </a><br>
<a href="#section-3.1.4">3.1.4. LineString </a><br>
<a href="#section-3.1.5">3.1.5. MultiLineString </a><br>
<a href="#section-3.1.6">3.1.6. Polygon </a><br>
<a href="#section-3.1.7">3.1.7. MultiPolygon </a><br>
<a href="#section-3.1.8">3.1.8. GeometryCollection </a><br>
<a href="#section-3.1.9">3.1.9. Antimeridian Cutting </a><br>
<a href="#section-3.1.10">3.1.10. Uncertainty and Precision </a><br>
<a href="#section-3.2">3.2. Feature Object </a><br>
<a href="#section-3.3">3.3. FeatureCollection Object </a><br>
<a href="#section-4">4. Coordinate Reference System </a><br>
<a href="#section-5">5. Bounding Box </a><br>
<a href="#section-5.1">5.1. The Connecting Lines </a><br>
<a href="#section-5.2">5.2. The Antimeridian </a><br>
<a href="#section-5.3">5.3. The Poles </a><br>
<a href="#section-6">6. Extending GeoJSON </a><br>
<a href="#section-6.1">6.1. Foreign Members </a><br>
<a href="#section-7">7. GeoJSON Types Are Not Extensible </a><br>
<a href="#section-7">7.1. Semantics of GeoJSON Members and Types Are Not Changeable</a><br>
<a href="#section-8">8. Versioning </a><br>
<a href="#section-9">9. Mapping 'geo' URIs </a><br>
<a href="#section-10">10. Security Considerations </a><br>
<a href="#section-11">11. Interoperability Considerations </a><br>
<a href="#section-11.1">11.1. I-JSON </a><br>
<a href="#section-11.2">11.2. Coordinate Precision </a><br>
<a href="#section-12">12. IANA Considerations </a><br>
<a href="#section-13">13. References </a><br>
<a href="#section-13.1">13.1. Normative References </a><br>
<a href="#section-13.2">13.2. Informative References </a><br>
<a href="#appendix-A">Appendix A. Geometry Examples </a><br>
<a href="#appendix-A.1">A.1. Points </a><br>
<a href="#appendix-A.2">A.2. LineStrings </a><br>
<a href="#appendix-A.3">A.3. Polygons </a><br>
<a href="#appendix-A.4">A.4. MultiPoints </a><br>
<a href="#appendix-A.5">A.5. MultiLineStrings </a><br>
<a href="#appendix-A.6">A.6. MultiPolygons </a><br>
<a href="#appendix-A.7">A.7. GeometryCollections </a><br>
<a href="#appendix-B">Appendix B. Changes from the Pre-IETF GeoJSON Format</a><br>
Specification <br>
<a href="#appendix-B.1">B.1. Normative Changes </a><br>
<a href="#appendix-B.2">B.2. Informative Changes </a><br>
<a href="#appendix-C">Appendix C. GeoJSON Text Sequences </a><br>
Acknowledgements <br>
Authors' Addresses <br>
</div>
<span class="h2"><h2><a class="selflink" name="section-1" href="#section-1">1</a>. Introduction</h2></span>
GeoJSON is a format for encoding a variety of geographic data
structures using JavaScript Object Notation (JSON) [<a href="https://tools.ietf.org/html/rfc7159" title=""The JavaScript Object Notation (JSON) Data Interchange Format"">RFC7159</a>]. A
GeoJSON object may represent a region of space (a <span class="gj-type">Geometry</span>), a
spatially bounded entity (a <span class="gj-type">Feature</span>), or a list of Features (a
<span class="gj-type">FeatureCollection</span>). GeoJSON supports the following geometry types:
<span class="gj-type">Point</span>, <span class="gj-type">LineString</span>, <span class="gj-type">Polygon</span>, <span class="gj-type">MultiPoint</span>, <span class="gj-type">MultiLineString</span>,
<span class="gj-type">MultiPolygon</span>, and <span class="gj-type">GeometryCollection</span>. Features in GeoJSON contain a
<span class="gj-type">Geometry</span> object and additional properties, and a <span class="gj-type">FeatureCollection</span>
contains a list of Features.<p>
The format is concerned with geographic data in the broadest sense;
anything with qualities that are bounded in geographical space might
be a <span class="gj-type">Feature</span> whether or not it is a physical structure. The concepts
in GeoJSON are not new; they are derived from preexisting open
geographic information system standards and have been streamlined to
better suit web application development using JSON.<p>
GeoJSON comprises the seven concrete geometry types defined in the
OpenGIS Simple Features Implementation Specification for SQL [<a href="#ref-SFSQL" title=""OpenGIS Simple Features Specification For SQL Revision 1.1"">SFSQL</a>]:
0-dimensional <span class="gj-type">Point</span> and <span class="gj-type">MultiPoint</span>; 1-dimensional curve <span class="gj-type">LineString</span>
and <span class="gj-type">MultiLineString</span>; 2-dimensional surface <span class="gj-type">Polygon</span> and <span class="gj-type">MultiPolygon</span>;
and the heterogeneous <span class="gj-type">GeometryCollection</span>. GeoJSON representations of
instances of these geometry types are analogous to the well-known
binary (WKB) and well-known text (WKT) representations described in
that same specification.<p>
GeoJSON also comprises the types <span class="gj-type">Feature</span> and <span class="gj-type">FeatureCollection</span>.
<span class="gj-type">Feature</span> objects in GeoJSON contain a <span class="gj-type">Geometry</span> object with one of the
above geometry types and additional members. A <span class="gj-type">FeatureCollection</span>
object contains an array of <span class="gj-type">Feature</span> objects. This structure is
analogous to that of the Web Feature Service (WFS) response to
GetFeatures requests specified in [<a href="#ref-WFSv1" title=""Web Feature Service Implementation Specification"">WFSv1</a>] or to a Keyhole Markup
Language (KML) Folder of Placemarks [<a href="#ref-KMLv2.2" title=""OGC KML"">KMLv2.2</a>]. Some implementations
of the WFS specification also provide GeoJSON-formatted responses to
GetFeature requests, but there is no particular service model or
<span class="gj-type">Feature</span> type ontology implied in the GeoJSON format specification.<p>
Since its initial publication in 2008 [<a href="#ref-GJ2008" title=""The GeoJSON Format Specification"">GJ2008</a>], the GeoJSON format
specification has steadily grown in popularity. It is widely used in
JavaScript web-mapping libraries, JSON-based document databases, and
web APIs.
<span class="h3"><h3><a class="selflink" name="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</h3></span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[<a href="https://tools.ietf.org/html/rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h3"><h3><a class="selflink" name="section-1.2" href="#section-1.2">1.2</a>. Conventions Used in This Document</h3></span>
The ordering of the members of any JSON object defined in this
document MUST be considered irrelevant, as specified by [<a href="https://tools.ietf.org/html/rfc7159" title=""The JavaScript Object Notation (JSON) Data Interchange Format"">RFC7159</a>].<p>
Some examples use the combination of a JavaScript single-line comment
(//) followed by an ellipsis (...) as placeholder notation for
content deemed irrelevant by the authors. These placeholders must of
course be deleted or otherwise replaced, before attempting to
validate the corresponding JSON code example.<p>
Whitespace is used in the examples inside this document to help
illustrate the data structures, but it is not required. Unquoted
whitespace is not significant in JSON.
<span class="h3"><h3><a class="selflink" name="section-1.3" href="#section-1.3">1.3</a>. Specification of GeoJSON</h3></span>
This document supersedes the original GeoJSON format specification
[<a href="#ref-GJ2008" title=""The GeoJSON Format Specification"">GJ2008</a>].
<span class="h3"><h3><a class="selflink" name="section-1.4" href="#section-1.4">1.4</a>. Definitions</h3></span>
<!-- </pre> -->
<ul>
<li>JavaScript Object Notation (JSON), and the terms <code>object</code>, <code>member</code>,
<code>name</code>, <code>value</code>, <code>array</code>, <code>number</code>, <code>true</code>, <code>false</code>, and <code>null</code>, are to be
interpreted as defined in [<a href="https://tools.ietf.org/html/rfc7159" title=""The JavaScript Object Notation (JSON) Data Interchange Format"">RFC7159</a>].
</li>
<li>Inside this document, the term "geometry type" refers to seven
case-sensitive strings: "<span class="gj-type">Point</span>", "<span class="gj-type">MultiPoint</span>", "<span class="gj-type">LineString</span>",
"<span class="gj-type">MultiLineString</span>", "<span class="gj-type">Polygon</span>", "<span class="gj-type">MultiPolygon</span>", and
"<span class="gj-type">GeometryCollection</span>".
</li>
<li>As another shorthand notation, the term "GeoJSON types" refers to
nine case-sensitive strings: "<span class="gj-type">Feature</span>", "<span class="gj-type">FeatureCollection</span>", and
the geometry types listed above.
</li>
<li>The word "Collection" in "<span class="gj-type">FeatureCollection</span>" and
"<span class="gj-type">GeometryCollection</span>" does not have any significance for the
semantics of array members. The "features" and "geometries"
members, respectively, of these objects are standard ordered JSON
arrays, not unordered sets.
</li>
</ul>
<span class="h3"><h3><a class="selflink" name="section-1.5" href="#section-1.5">1.5</a>. Example</h3></span>
A GeoJSON <span class="gj-type">FeatureCollection</span>:
<samp>
{
"type": "FeatureCollection",
"features": [{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [102.0, 0.5]
},
"properties": {
"prop0": "value0"
}
}, {
"type": "Feature",
"geometry": {
"type": "LineString",
"coordinates": [
[102.0, 0.0],
[103.0, 1.0],
[104.0, 0.0],
[105.0, 1.0]
]
},
"properties": {
"prop0": "value0",
"prop1": 0.0
}
}, {
"type": "Feature",
"geometry": {
"type": "Polygon",
"coordinates": [
[
[100.0, 0.0],
[101.0, 0.0],
[101.0, 1.0],
[100.0, 1.0],
[100.0, 0.0]
]
]
},
"properties": {
"prop0": "value0",
"prop1": {
"this": "that"
}
}
}]
}
</samp>
<span class="h2"><h2><a class="selflink" name="section-2" href="#section-2">2</a>. GeoJSON Text</h2></span>
A GeoJSON text is a JSON text and consists of a single GeoJSON
object.
<span class="h2"><h2><a class="selflink" name="section-3" href="#section-3">3</a>. GeoJSON Object</h2></span>
A GeoJSON object represents a <span class="gj-type">Geometry</span>, <span class="gj-type">Feature</span>, or collection of
<span class="gj-type">Feature</span>s.
<ul>
<li>A GeoJSON object is a JSON object.
</li>
<li>A GeoJSON object has a member with the name "type". The value of
the member MUST be one of the GeoJSON types.
</li>
<li>A GeoJSON object MAY have a "bbox" member, the value of which MUST
be a bounding box array (see <a href="#section-5">Section 5</a>).
</li>
<li>A GeoJSON object MAY have other members (see <a href="#section-6">Section 6</a>).
</li>
</ul>
<span class="h3"><h3><a class="selflink" name="section-3.1" href="#section-3.1">3.1</a>. <span class="gj-type">Geometry</span> Object</h3></span>
A <span class="gj-type">Geometry</span> object represents points, curves, and surfaces in
coordinate space. Every <span class="gj-type">Geometry</span> object is a GeoJSON object no
matter where it occurs in a GeoJSON text.
<ul>
<li>The value of a <span class="gj-type">Geometry</span> object's "type" member MUST be one of the
seven geometry types (see <a href="#section-1.4">Section 1.4</a>).
</li>
<li>A GeoJSON <span class="gj-type">Geometry</span> object of any type other than
"<span class="gj-type">GeometryCollection</span>" has a member with the name "coordinates".
The value of the "coordinates" member is an array. The structure
of the elements in this array is determined by the type of
geometry. GeoJSON processors MAY interpret <span class="gj-type">Geometry</span> objects with
empty "coordinates" arrays as null objects.
</li>
</ul>
<span class="h4"><h4><a class="selflink" name="section-3.1.1" href="#section-3.1.1">3.1.1</a>. Position</h4></span>
A position is the fundamental geometry construct. The "coordinates"
member of a <span class="gj-type">Geometry</span> object is composed of either:
<ul>
<li>one position in the case of a <span class="gj-type">Point</span> geometry,
</li>
<li>an array of positions in the case of a <span class="gj-type">LineString</span> or <span class="gj-type">MultiPoint</span>
geometry,
</li>
<li>an array of <span class="gj-type">LineString</span> or linear ring (see <a href="#section-3.1.6">Section 3.1.6</a>)
coordinates in the case of a <span class="gj-type">Polygon</span> or <span class="gj-type">MultiLineString</span> geometry,
or
</li>
<li>an array of <span class="gj-type">Polygon</span> coordinates in the case of a <span class="gj-type">MultiPolygon</span>
geometry.
</li>
</ul>
A position is an array of numbers. There MUST be two or more
elements. The first two elements are longitude and latitude, or
easting and northing, precisely in that order and using decimal
numbers. Altitude or elevation MAY be included as an optional third
element.<p>
Implementations SHOULD NOT extend positions beyond three elements
because the semantics of extra elements are unspecified and
ambiguous. Historically, some implementations have used a fourth
element to carry a linear referencing measure (sometimes denoted as
"M") or a numerical timestamp, but in most situations a parser will
not be able to properly interpret these values. The interpretation
and meaning of additional elements is beyond the scope of this
specification, and additional elements MAY be ignored by parsers.<p>
A line between two positions is a straight Cartesian line, the
shortest line between those two points in the coordinate reference
system (see <a href="#section-4">Section 4</a>).<p>
In other words, every point on a line that does not cross the
antimeridian between a point (lon0, lat0) and (lon1, lat1) can be
calculated as
<code>F(lon, lat) = (lon0 + (lon1 - lon0) * t, lat0 + (lat1 - lat0) * t)</code>
with t being a real number greater than or equal to 0 and smaller
than or equal to 1. Note that this line may markedly differ from the
geodesic path along the curved surface of the reference ellipsoid.<p>
The same applies to the optional height element with the proviso that
the direction of the height is as specified in the coordinate
reference system.<p>
Note that, again, this does not mean that a surface with equal height
follows, for example, the curvature of a body of water. Nor is a
surface of equal height perpendicular to a plumb line.<p>
Examples of positions and geometries are provided in <a href="#appendix-A">Appendix A</a>,
"Geometry Examples".<p>
<span class="h4"><h4><a class="selflink" name="section-3.1.2" href="#section-3.1.2">3.1.2</a>. <span class="gj-type">Point</span></h4></span>
For type "<span class="gj-type">Point</span>", the "coordinates" member is a single position.
<span class="h4"><h4><a class="selflink" name="section-3.1.3" href="#section-3.1.3">3.1.3</a>. <span class="gj-type">MultiPoint</span></h4></span>
For type "<span class="gj-type">MultiPoint</span>", the "coordinates" member is an array of
positions.
<span class="h4"><h4><a class="selflink" name="section-3.1.4" href="#section-3.1.4">3.1.4</a>. <span class="gj-type">LineString</span></h4></span>
For type "<span class="gj-type">LineString</span>", the "coordinates" member is an array of two or
more positions.
<span class="h4"><h4><a class="selflink" name="section-3.1.5" href="#section-3.1.5">3.1.5</a>. <span class="gj-type">MultiLineString</span></h4></span>
For type "<span class="gj-type">MultiLineString</span>", the "coordinates" member is an array of
<span class="gj-type">LineString</span> coordinate arrays.
<span class="h4"><h4><a class="selflink" name="section-3.1.6" href="#section-3.1.6">3.1.6</a>. <span class="gj-type">Polygon</span></h4></span>
To specify a constraint specific to <span class="gj-type">Polygon</span>s, it is useful to
introduce the concept of a linear ring:
<ul>
<li>A linear ring is a closed <span class="gj-type">LineString</span> with four or more positions.
</li>
<li>The first and last positions are equivalent, and they MUST contain
identical values; their representation SHOULD also be identical.
</li>
<li>A linear ring is the boundary of a surface or the boundary of a
hole in a surface.
</li>
<li>A linear ring MUST follow the right-hand rule with respect to the
area it bounds, i.e., exterior rings are counterclockwise, and
holes are clockwise.
<br>
<i>Note: a reported (but not accepted) <a href="https://www.rfc-editor.org/errata/rfc7946">erratum on the RFC</a> states that "counterclockwise" and "clockwise" are backwards here.</i>
<div class="steve-comment">Steve comment: It appears there is confusion around the term "right-hand rule". The examples in this RFC, plus geojsonlint.com, follow "exterior boundaries are counterclockwise, and holes are clockwise" (ie, not the erratum).</div>
</li>
</ul>
<div class="note">
Note: the [<a href="#ref-GJ2008" title=""The GeoJSON Format Specification"">GJ2008</a>] specification did not discuss linear ring winding
order. For backwards compatibility, parsers SHOULD NOT reject
<span class="gj-type">Polygon</span>s that do not follow the right-hand rule.
</div>
Though a linear ring is not explicitly represented as a GeoJSON
geometry type, it leads to a canonical formulation of the <span class="gj-type">Polygon</span>
geometry type definition as follows:
<ul>
<li>For type "<span class="gj-type">Polygon</span>", the "coordinates" member MUST be an array of
linear ring coordinate arrays.
</li>
<li>For <span class="gj-type">Polygon</span>s with more than one of these rings, the first MUST be
the exterior ring, and any others MUST be interior rings. The
exterior ring bounds the surface, and the interior rings (if
present) bound holes within the surface.
</li>
</ul>
<span class="h4"><h4><a class="selflink" name="section-3.1.7" href="#section-3.1.7">3.1.7</a>. <span class="gj-type">MultiPolygon</span></h4></span>
For type "<span class="gj-type">MultiPolygon</span>", the "coordinates" member is an array of
<span class="gj-type">Polygon</span> coordinate arrays.
<span class="h4"><h4><a class="selflink" name="section-3.1.8" href="#section-3.1.8">3.1.8</a>. <span class="gj-type">GeometryCollection</span></h4></span>
A GeoJSON object with type "<span class="gj-type">GeometryCollection</span>" is a <span class="gj-type">Geometry</span> object.
A <span class="gj-type">GeometryCollection</span> has a member with the name "geometries". The
value of "geometries" is an array. Each element of this array is a
GeoJSON <span class="gj-type">Geometry</span> object. It is possible for this array to be empty.
<p>
Unlike the other geometry types described above, a <span class="gj-type">GeometryCollection</span>
can be a heterogeneous composition of smaller <span class="gj-type">Geometry</span> objects. For
example, a <span class="gj-type">Geometry</span> object in the shape of a lowercase roman "i" can
be composed of one point and one <span class="gj-type">LineString</span>.
<p>
<span class="gj-type">GeometryCollection</span>s have a different syntax from single type <span class="gj-type">Geometry</span>
objects (<span class="gj-type">Point</span>, <span class="gj-type">LineString</span>, and <span class="gj-type">Polygon</span>) and homogeneously typed
multipart <span class="gj-type">Geometry</span> objects (<span class="gj-type">MultiPoint</span>, <span class="gj-type">MultiLineString</span>, and
<span class="gj-type">MultiPolygon</span>) but have no different semantics. Although a
<span class="gj-type">GeometryCollection</span> object has no "coordinates" member, it does have
coordinates: the coordinates of all its parts belong to the
collection. The "geometries" member of a <span class="gj-type">GeometryCollection</span>
describes the parts of this composition. Implementations SHOULD NOT
apply any additional semantics to the "geometries" array.
<p>
To maximize interoperability, implementations SHOULD avoid nested
<span class="gj-type">GeometryCollection</span>s. Furthermore, <span class="gj-type">GeometryCollection</span>s composed of a
single part or a number of parts of a single type SHOULD be avoided
when that single part or a single object of multipart type
(<span class="gj-type">MultiPoint</span>, <span class="gj-type">MultiLineString</span>, or <span class="gj-type">MultiPolygon</span>) could be used instead.
<p>
<span class="h4"><h4><a class="selflink" name="section-3.1.9" href="#section-3.1.9">3.1.9</a>. Antimeridian Cutting</h4></span>
In representing <span class="gj-type">Feature</span>s that cross the antimeridian,
interoperability is improved by modifying their geometry. Any
geometry that crosses the antimeridian SHOULD be represented by
cutting it in two such that neither part's representation crosses the
antimeridian.
For example, a line extending from 45 degrees N, 170 degrees E across
the antimeridian to 45 degrees N, 170 degrees W should be cut in two
and represented as a <span class="gj-type">MultiLineString</span>.
<samp>
{
"type": "MultiLineString",
"coordinates": [
[
[170.0, 45.0], [180.0, 45.0]
], [
[-180.0, 45.0], [-170.0, 45.0]
]
]
}
</samp>
A rectangle extending from 40 degrees N, 170 degrees E across the
antimeridian to 50 degrees N, 170 degrees W should be cut in two and
represented as a <span class="gj-type">MultiPolygon</span>.
<samp>
{
"type": "MultiPolygon",
"coordinates": [
[
[
[180.0, 40.0], [180.0, 50.0], [170.0, 50.0],
[170.0, 40.0], [180.0, 40.0]
]
],
[
[
[-170.0, 40.0], [-170.0, 50.0], [-180.0, 50.0],
[-180.0, 40.0], [-170.0, 40.0]
]
]
]
}
</samp>
<span class="h4"><h4><a class="selflink" name="section-3.1.10" href="#section-3.1.10">3.1.10</a>. Uncertainty and Precision</h4></span>
As in [<a href="https://tools.ietf.org/html/rfc5870" title=""A Uniform Resource Identifier for Geographic Locations ('geo' URI)"">RFC5870</a>], the number of digits of the values in coordinate
positions MUST NOT be interpreted as an indication to the level of
uncertainty.
<span class="h3"><h3><a class="selflink" name="section-3.2" href="#section-3.2">3.2</a>. <span class="gj-type">Feature</span> Object</h3></span>
A <span class="gj-type">Feature</span> object represents a spatially bounded thing. Every <span class="gj-type">Feature</span>
object is a GeoJSON object no matter where it occurs in a GeoJSON
text.
<ul>
<li>A <span class="gj-type">Feature</span> object has a "type" member with the value "<span class="gj-type">Feature</span>".
</li>
<li>A <span class="gj-type">Feature</span> object has a member with the name "geometry". The value
of the geometry member SHALL be either a <span class="gj-type">Geometry</span> object as
defined above or, in the case that the <span class="gj-type">Feature</span> is unlocated, a
JSON null value.
</li>
<li>A <span class="gj-type">Feature</span> object has a member with the name "properties". The
value of the properties member is an object (any JSON object or a
JSON null value).
</li>
<li>If a <span class="gj-type">Feature</span> has a commonly used identifier, that identifier
SHOULD be included as a member of the <span class="gj-type">Feature</span> object with the name
"id", and the value of this member is either a JSON string or
number.
</li>
</ul>
<span class="h3"><h3><a class="selflink" name="section-3.3" href="#section-3.3">3.3</a>. <span class="gj-type">FeatureCollection</span> Object</h3></span>
A GeoJSON object with the type "<span class="gj-type">FeatureCollection</span>" is a
<span class="gj-type">FeatureCollection</span> object. A <span class="gj-type">FeatureCollection</span> object has a member
with the name "features". The value of "features" is a JSON array.
Each element of the array is a <span class="gj-type">Feature</span> object as defined above. It
is possible for this array to be empty.
<span class="h2"><h2><a class="selflink" name="section-4" href="#section-4">4</a>. Coordinate Reference System</h2></span>
The coordinate reference system for all GeoJSON coordinates is a
geographic coordinate reference system, using the World Geodetic
System 1984 (WGS 84) [<a href="#ref-WGS84" title=""Department of Defense World Geodetic System 1984: Its Definition and Relationships with Local Geodetic Systems"">WGS84</a>] datum, with longitude and latitude units
of decimal degrees. This is equivalent to the coordinate reference
system identified by the Open Geospatial Consortium (OGC) URN
urn:ogc:def:crs:OGC::CRS84. An OPTIONAL third-position element SHALL
be the height in meters above or below the WGS 84 reference
ellipsoid. In the absence of elevation values, applications
sensitive to height or depth SHOULD interpret positions as being at
local ground or sea level.<p>
<div class="note">
Note: the use of alternative coordinate reference systems was
specified in [<a href="#ref-GJ2008" title=""The GeoJSON Format Specification"">GJ2008</a>], but it has been removed from this version of
the specification because the use of different coordinate reference
systems -- especially in the manner specified in [<a href="#ref-GJ2008" title=""The GeoJSON Format Specification"">GJ2008</a>] -- has
proven to have interoperability issues. In general, GeoJSON
processing software is not expected to have access to coordinate
reference system databases or to have network access to coordinate
reference system transformation parameters. However, where all
involved parties have a prior arrangement, alternative coordinate
reference systems can be used without risk of data being
misinterpreted.<p>
</div>
<span class="h2"><h2><a class="selflink" name="section-5" href="#section-5">5</a>. Bounding Box</h2></span>
A GeoJSON object MAY have a member named "bbox" to include
information on the coordinate range for its Geometries, <span class="gj-type">Feature</span>s, or
<span class="gj-type">FeatureCollection</span>s. The value of the bbox member MUST be an array of
length <code>2*n</code> where n is the number of dimensions represented in the
contained geometries, with all axes of the most southwesterly point
followed by all axes of the more northeasterly point. The axes order
of a bbox follows the axes order of geometries.<p>
The "bbox" values define shapes with edges that follow lines of
constant longitude, latitude, and elevation.<p>
Example of a 2D bbox member on a <span class="gj-type">Feature</span>:
<samp>{
"type": "Feature",
"bbox": [-10.0, -10.0, 10.0, 10.0],
"geometry": {
"type": "Polygon",
"coordinates": [
[
[-10.0, -10.0],
[10.0, -10.0],
[10.0, 10.0],
[-10.0, -10.0]
]
]
}
//...
}
</samp>
Example of a 2D bbox member on a <span class="gj-type">FeatureCollection</span>:
<samp>{
"type": "FeatureCollection",
"bbox": [100.0, 0.0, 105.0, 1.0],
"features": [
//...
]
}
</samp>
Example of a 3D bbox member with a depth of 100 meters:
<samp>{
"type": "FeatureCollection",
"bbox": [100.0, 0.0, -100.0, 105.0, 1.0, 0.0],
"features": [
//...
]
}
</samp>
<span class="h3"><h3><a class="selflink" name="section-5.1" href="#section-5.1">5.1</a>. The Connecting Lines</h3></span>
The four lines of the bounding box are defined fully within the
coordinate reference system; that is, for a box bounded by the values
"west", "south", "east", and "north", every point on the northernmost
line can be expressed as
<samp>(lon, lat) = (west + (east - west) * t, north)</samp>
with <code>0 <= t <= 1</code>.
<span class="h3"><h3><a class="selflink" name="section-5.2" href="#section-5.2">5.2</a>. The Antimeridian</h3></span>
Consider a set of point <span class="gj-type">Feature</span>s within the Fiji archipelago,
straddling the antimeridian between 16 degrees S and 20 degrees S.
The southwest corner of the box containing these <span class="gj-type">Feature</span>s is at 20
degrees S and 177 degrees E, and the northwest corner is at 16
degrees S and 178 degrees W. The antimeridian-spanning GeoJSON
bounding box for this <span class="gj-type">FeatureCollection</span> is
<samp>"bbox": [177.0, -20.0, -178.0, -16.0]</samp>
and covers 5 degrees of longitude.
The complementary bounding box for the same latitude band, not
crossing the antimeridian, is