idnits 2.17.1 draft-butler-geojson-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 18, 2015) is 3204 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '170' on line 446 -- Looks like a reference, but probably isn't: '10' on line 445 == Missing Reference: '-170' is mentioned on line 445, but not defined -- Looks like a reference, but probably isn't: '11' on line 446 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent H. Butler 3 Internet-Draft Hobu Inc. 4 Intended status: Informational M. Daly 5 Expires: January 19, 2016 Cadcorp 6 A. Doyle 7 MIT 8 S. Gillies 9 Mapbox Inc. 10 T. Schaub 11 Planet Labs 12 S. Hagen 14 July 18, 2015 16 The GeoJSON Format 17 draft-butler-geojson-06 19 Abstract 21 GeoJSON is a geospatial data interchange format based on JavaScript 22 Object Notation (JSON). It defines several types of JSON objects and 23 the manner in which they are combined to represent data about 24 geographic features, their properties, and their spatial extents. 25 This document recommends a single coordinate reference system based 26 on WGS 84. Other coordinate reference systems are not recommended. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 19, 2016. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 1.2. Conventions Used in This Document . . . . . . . . . . . . 4 65 1.3. Specification of GeoJSON . . . . . . . . . . . . . . . . 4 66 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. GeoJSON Object . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.1. Geometry Object . . . . . . . . . . . . . . . . . . . . . 6 70 2.1.1. Position . . . . . . . . . . . . . . . . . . . . . . 6 71 2.1.2. Point . . . . . . . . . . . . . . . . . . . . . . . . 7 72 2.1.3. MultiPoint . . . . . . . . . . . . . . . . . . . . . 7 73 2.1.4. LineString . . . . . . . . . . . . . . . . . . . . . 7 74 2.1.5. MultiLineString . . . . . . . . . . . . . . . . . . . 7 75 2.1.6. Polygon . . . . . . . . . . . . . . . . . . . . . . . 7 76 2.1.7. MultiPolygon . . . . . . . . . . . . . . . . . . . . 8 77 2.1.8. Geometry Collection . . . . . . . . . . . . . . . . . 8 78 2.2. Feature Object . . . . . . . . . . . . . . . . . . . . . 8 79 2.3. Feature Collection Object . . . . . . . . . . . . . . . . 8 80 3. Coordinate Reference System . . . . . . . . . . . . . . . . . 9 81 4. Bounding Box . . . . . . . . . . . . . . . . . . . . . . . . 9 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 6. Interoperability Considerations . . . . . . . . . . . . . . . 11 84 6.1. I-JSON . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 6.2. Coordinate Precision . . . . . . . . . . . . . . . . . . 11 86 6.3. Coordinate Order . . . . . . . . . . . . . . . . . . . . 11 87 6.4. Coordinate Reference System Identifiers . . . . . . . . . 11 88 6.5. Bounding boxes . . . . . . . . . . . . . . . . . . . . . 12 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 92 8.2. Informative References . . . . . . . . . . . . . . . . . 13 94 Appendix A. Geometry Examples . . . . . . . . . . . . . . . . . 14 95 A.1. Points . . . . . . . . . . . . . . . . . . . . . . . . . 14 96 A.2. LineStrings . . . . . . . . . . . . . . . . . . . . . . . 14 97 A.3. Polygons . . . . . . . . . . . . . . . . . . . . . . . . 14 98 A.4. MultiPoints . . . . . . . . . . . . . . . . . . . . . . . 16 99 A.5. MultiLineStrings . . . . . . . . . . . . . . . . . . . . 16 100 A.6. MultiPolygons . . . . . . . . . . . . . . . . . . . . . . 17 101 A.7. GeometryCollections . . . . . . . . . . . . . . . . . . . 18 102 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 19 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 105 1. Introduction 107 GeoJSON is a format for encoding data about geographic features using 108 JavaScript Object Notation (JSON) [RFC7159]. The format is concerned 109 with features in the broadest sense; any thing with qualities that 110 are bounded in geographical space may be a feature whether it is a 111 physical structure or not. The concepts in GeoJSON are not new; they 112 are derived from pre-existing open geographic information system 113 standards (for COM, SQL, and XML) and have been streamlined to better 114 suit web application development using JSON. 116 GeoJSON comprises the seven concrete geometry types defined in the 117 OpenGIS Simple Features Implementation Specification for SQL [SFSQL]: 118 0-dimensional Point and MultiPoint; 1-dimensional curve LineString 119 and MultiLineString; 2-dimensional surface Polygon and MultiPolygon; 120 and the heterogeneous GeometryCollection. GeoJSON representations of 121 instances of these geometry types are analogous to the well-known 122 binary (WKB) and text (WKT) representations described in that same 123 specification. 125 GeoJSON also comprises the types Feature and FeatureCollection. 126 Feature objects in GeoJSON contain a geometry object with one of the 127 above geometry types and additional properties. A FeatureCollection 128 object contains an array of feature objects. This structure is 129 analogous to that of the Web Feature Service (WFS) response to 130 GetFeatures requests specified in [WFSv1] or to a KML Folder of 131 Placemarks [KMLv2.2]. Some implementations of the WFS specification 132 also provide GeoJSON formatted responses to GetFeature requests, but 133 there is no particular service model or feature type ontology implied 134 in the GeoJSON format specification. 136 Since its initial publication in 2008 [GJ2008], the GeoJSON format 137 specification has steadily grown in popularity. It is widely used in 138 JavaScript web mapping libraries, JSON-based document databases, and 139 web APIs. 141 1.1. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in 146 [RFC2119]. 148 1.2. Conventions Used in This Document 150 The ordering of the members of any JSON object defined in this 151 document MUST be considered irrelevant, as specified by [RFC7159]. 153 Some examples use the combination of a JavaScript single line comment 154 (//) followed by an ellipsis (...) as placeholder notation for 155 content deemed irrelevant by the authors. These placeholders must of 156 course be deleted or otherwise replaced, before attempting to 157 validate the corresponding JSON code example. 159 Whitespace is used in the examples inside this document to help 160 illustrate the data structures, but is not required. Unquoted 161 whitespace is not significant in JSON. 163 1.3. Specification of GeoJSON 165 This document updates the original GeoJSON format specification 166 [GJ2008]. 168 1.4. Definitions 170 o JavaScript Object Notation (JSON), and the terms object, name, 171 value, array, number, true, false, and null are to be interpreted 172 as defined in [RFC7159]. 174 o Inside this document the term "geometry type" refers to the seven 175 case-sensitive strings: "Point", "MultiPoint", "LineString", 176 "MultiLineString", "Polygon", "MultiPolygon", and 177 "GeometryCollection". 179 o As another shorthand notation, the term "GeoJSON types" refers to 180 the nine case-sensitive strings "Feature", "FeatureCollection" and 181 the geometry types listed above. 183 1.5. Example 185 A GeoJSON feature collection: 187 { 188 "type": "FeatureCollection", 189 "features": [{ 190 "type": "Feature", 191 "geometry": { 192 "type": "Point", 193 "coordinates": [102.0, 0.5] 194 }, 195 "properties": { 196 "prop0": "value0" 197 } 198 }, { 199 "type": "Feature", 200 "geometry": { 201 "type": "LineString", 202 "coordinates": [ 203 [102.0, 0.0], 204 [103.0, 1.0], 205 [104.0, 0.0], 206 [105.0, 1.0] 207 ] 208 }, 209 "properties": { 210 "prop0": "value0", 211 "prop1": 0.0 212 } 213 }, { 214 "type": "Feature", 215 "geometry": { 216 "type": "Polygon", 217 "coordinates": [ 218 [ 219 [100.0, 0.0], 220 [101.0, 0.0], 221 [101.0, 1.0], 222 [100.0, 1.0], 223 [100.0, 0.0] 224 ] 225 ] 226 }, 227 "properties": { 228 "prop0": "value0", 229 "prop1": { 230 "this": "that" 231 } 232 } 233 }] 234 } 236 2. GeoJSON Object 238 GeoJSON always consists of a single object. This object (referred to 239 as the GeoJSON object below) represents a geometry, feature, or 240 collection of features. 242 o The top level of GeoJSON text MUST be a JSON object. 244 o The GeoJSON object MUST have a member with the name "type". The 245 value of the member MUST be one of the GeoJSON types. 247 o A GeoJSON object MAY have a "bbox" member, the value of which MUST 248 be a bounding box array (see 4. Bounding Boxes). 250 o The GeoJSON object MAY have any number of other members. 251 Implementations MUST ignore unrecognized members. 253 2.1. Geometry Object 255 A geometry object is a GeoJSON object where the "type" value is one 256 of the geometry types. A GeoJSON geometry object of any type other 257 than "GeometryCollection" MUST have a member with the name 258 "coordinates". The value of the coordinates member is always an 259 array. The structure of the elements in this array is determined by 260 the type of geometry. GeoJSON processors MAY interpret geometry 261 objects with empty coordinates arrays as null objects. 263 2.1.1. Position 265 A position is the fundamental geometry construct. The "coordinates" 266 member of a geometry object is composed of either: 268 o one position (in the case of a Point geometry), 270 o an array of positions (LineString or MultiPoint geometries), 272 o an array of arrays of positions (Polygons, MultiLineStrings), 274 o or a multidimensional array of positions (MultiPolygon). 276 A position is represented by an array of numbers. There MUST be two 277 or more elements. The first two elements will be longitude and 278 latitude, or easting and northing, precisely in that order and using 279 decimal numbers. Altitude or elevation MAY be included as an 280 optional third element. 282 Additional position elements MAY be included but MUST follow the 283 three specified above and MAY be ignored by software. Interpretation 284 and meaning of additional elements is beyond the scope of this 285 specification. 287 Examples of positions and geometries are provided in "Appendix A. 288 Geometry Examples". 290 2.1.2. Point 292 For type "Point", the "coordinates" member MUST be a single position. 294 2.1.3. MultiPoint 296 For type "MultiPoint", the "coordinates" member MUST be an array of 297 positions. 299 2.1.4. LineString 301 For type "LineString", the "coordinates" member MUST be an array of 302 two or more positions. 304 2.1.5. MultiLineString 306 For type "MultiLineString", the "coordinates" member MUST be an array 307 of LineString coordinate arrays. 309 2.1.6. Polygon 311 To specify a constraint specific to polygons, it is useful to 312 introduce the concept of a linear ring: 314 o A linear ring is a closed LineString with 4 or more positions. 316 o The first and last positions are equivalent (they represent 317 equivalent points). 319 o A linear ring is the boundary of a surface or the boundary of a 320 hole in a surface. 322 o A linear ring SHOULD follow right-hand rule with respect to the 323 area it bounds (ie. exterior rings are counter-clockwise, holes 324 are clockwise) 326 Though a linear ring is not explicitly represented as a GeoJSON 327 geometry type, it leads to a canonical formulation of the Polygon 328 geometry type definition as follows: 330 o For type "Polygon", the "coordinates" member MUST be an array of 331 linear ring coordinate arrays. 333 o For Polygons with more than one of these rings, the first MUST be 334 the exterior ring and any others MUST be interior rings. The 335 exterior ring bounds the surface and the interiors rings (if 336 present) bound holes within the surface. 338 2.1.7. MultiPolygon 340 For type "MultiPolygon", the "coordinates" member MUST be an array of 341 Polygon coordinate arrays. 343 2.1.8. Geometry Collection 345 A GeoJSON object with type "GeometryCollection" is a geometry object 346 which represents a collection of geometry objects. A geometry 347 collection MUST have a member with the name "geometries". The value 348 corresponding to "geometries" is an array. Each element in this 349 array is a GeoJSON geometry object. 351 2.2. Feature Object 353 A GeoJSON object with the type "Feature" is a feature object. 355 o A feature object MUST have a member with the name "geometry". The 356 value of the geometry member SHALL be either a geometry object as 357 defined above or, in the the case that the feature is unlocated, a 358 JSON null value. 360 o A feature object MUST have a member with the name "properties". 361 The value of the properties member is an object (any JSON object 362 or a JSON null value). 364 o If a feature has a commonly used identifier, that identifier 365 SHOULD be included as a member of the feature object with the name 366 "id" and the value of this member is either a JSON string or 367 number. 369 2.3. Feature Collection Object 371 A GeoJSON object with the type "FeatureCollection" is a feature 372 collection object. An object of type "FeatureCollection" MUST have a 373 member with the name "features". The value corresponding to 374 "features" is an array. Each element in the array is a feature 375 object as defined above. 377 3. Coordinate Reference System 379 The default reference system for all GeoJSON coordinates SHALL be a 380 geographic coordinate reference system, using the [WGS84] datum, and 381 with longitude and latitude units of decimal degrees. This 382 coordinate reference system is equivalent to the OGC's "http:// 383 www.opengis.net/def/crs/OGC/1.3/CRS84" [OGCURL]. An OPTIONAL third 384 position element SHALL be the height in meters above the WGS 84 385 reference ellipsoid. For widest interoperability, GeoJSON data 386 SHOULD use this default coordinate reference system. 388 Other coordinate reference systems, including ones described by CRS 389 objects of the kind defined in [GJ2008] are NOT RECOMMENDED. GeoJSON 390 processing software SHALL NOT be expected to have access to 391 coordinate reference systems databases. Applications requiring CRS 392 other than the default MUST assume all responsibility for reference 393 system and coordinate accuracy. Furthermore, GeoJSON coordinates 394 MUST NOT under any circumstances use latitude, longitude order. See 395 Section 6, Interoperability Considerations, for guidance in 396 processing GeoJSON documents that do contain such a CRS object. 398 4. Bounding Box 400 A GeoJSON object MAY have a member named "bbox" to include 401 information on the coordinate range for its geometries, features, or 402 feature collections. The value of the bbox member MUST be an array 403 of length 2*n where n is the number of dimensions represented in the 404 contained geometries, with all axes of the most south-westerly point 405 followed by all axes of the more north-easterly point. The axes 406 order of a bbox follows the axes order of geometries. 408 Example of a bbox member on a feature: 410 { 411 "type": "Feature", 412 "bbox": [-180.0, -90.0, 180.0, 90.0], 413 "geometry": { 414 "type": "Polygon", 415 "coordinates": [ 416 [ 417 [-180.0, 10.0], 418 [20.0, 90.0], 419 [180.0, -5.0], 420 [-30.0, -90.0] 421 ] 422 ] 423 } 424 //... 425 } 427 Example of a bbox member on a feature collection: 429 { 430 "type": "FeatureCollection", 431 "bbox": [100.0, 0.0, 105.0, 1.0], 432 "features": [ 433 //... 434 ] 435 } 437 Example of a bbox for line crossing the date-line: 439 { 440 "type": "Feature", 441 "bbox": [170, 10, -170, 11], 442 "geometry": { 443 "type": "LineString", 444 "coordinates": [ 445 [-170, 10], 446 [170, 11] 447 ] 448 } 449 //... 450 } 452 5. Security Considerations 454 GeoJSON shares security issues common to all JSON content types. See 455 [RFC7159] Section 12 for additional information. GeoJSON does not 456 provide executable content. 458 As with other geographic data formats, e.g., [KMLv2.2], providing 459 details about the locations of sensitive persons, animals, habitats, 460 and facilities can expose them to unauthorized tracking or injury. 461 GeoJSON does not provide privacy or integrity services; if sensitive 462 data requires privacy or integrity protection the service must be 463 provided externally. 465 6. Interoperability Considerations 467 6.1. I-JSON 469 GeoJSON texts SHOULD follow the constraints of I-JSON [RFC7493] for 470 maximum interoperability. 472 6.2. Coordinate Precision 474 The size of a GeoJSON text in bytes is a major interoperability 475 consideration and precision of coordinate values has a large impact 476 on the size of texts. A GeoJSON text containing many detailed 477 polygons can be inflated almost by a factor of two by increasing 478 coordinate precision from 6 to 15 decimal places. For geographic 479 coordinates with units of degrees, 6 decimal places (a default common 480 in, e.g., sprintf) amounts to about 10 centimeters, a precision well 481 within that of current GPS systems. Implementations should consider 482 the cost to using a greater precision than necessary. 484 6.3. Coordinate Order 486 There are conflicting precedents among geographic data formats over 487 whether latitude or longitude come first in a pair of numbers. 488 Longitude comes first in GeoJSON coordinates as it does in [KMLv2.2]. 490 Some commonly-used CRS definitions specify coordinate ordering that 491 is not longitude then latitude (for a geographic CRS) or easting then 492 northing (for a projected CRS). The CRS historically known as 493 "EPSG:4326" and more accurately named "http://www.opengis.net/def/crs 494 /EPSG/0/4326" is a prime example. Using such a CRS is NOT 495 RECOMMENDED due to the potential disruption of interoperability. 496 When such a CRS is encountered in GeoJSON, the document should be 497 processed with caution. Heuristics may be necessary to interpret the 498 coordinates properly; they may not be in the required longitude, 499 latitude order. 501 6.4. Coordinate Reference System Identifiers 503 Earlier versions of the GeoJSON specification recommended use of OGC 504 URNs such as "urn:ogc:def:crs:OGC:1.3:CRS84" to name a CRS. This 505 version deprecates the URNs and recommends a change to HTTP URLs 507 [Section 3.1]. Widely deployed systems using, e.g. the GDAL and OGR 508 libraries, currently write the deprecated OGC URNs into GeoJSON 509 documents and will do so until replaced by newer versions. GeoJSON 510 processors should be prepared for either form. 512 6.5. Bounding boxes 514 In representing features that cross the dateline or the poles, 515 following the ring-orientation best practice (counter-clockwise 516 external rings, clockwise internal rings) and ensuring your bounding 517 boxes use the south-west corner as the first coordinate will improve 518 interoperability. Remain aware that software that represents edges 519 as straight cartesian lines and software that represents edges as 520 great circles will have different interpretations of edges, which 521 vary more the longer the edges are. Try to avoid edges of more than 522 180 degrees in length as far as possible. 524 7. IANA Considerations 526 The MIME media type for GeoJSON text is application/vnd.geo+json. 528 Type name: application 530 Subtype name: vnd.geo+json 532 Required parameters: n/a 534 Optional parameters: n/a 536 Encoding considerations: binary 538 Security considerations: See section 5 above 540 Interoperability considerations: See section 6 above 542 Published specification: draft-butler-geojson 544 Applications that use this media type: various 546 Additional information: 548 Magic number(s) : n/a 550 File extension(s) : .json, .geojson 552 Macintosh file type code : TEXT 554 Object Identifiers: n/a 556 Person to contact for further information: 558 Sean Gillies 560 sean.gillies@gmail.com 562 Intended usage: COMMON 564 Restrictions on usage: none 566 8. References 568 8.1. Normative References 570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 571 Requirement Levels", BCP 14, RFC 2119, March 1997. 573 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 574 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 575 2014, . 577 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 578 10.17487/RFC7493, March 2015, 579 . 581 8.2. Informative References 583 [GJ2008] Butler, H., Daly, M., Doyle, A., Gillies, S., Schaub, T., 584 and C. Schmidt, "The GeoJSON Format Specification", June 585 2008. 587 [KMLv2.2] Wilson, T., "OGC KML", OGC 07-147r2, April 2008. 589 [OGCURL] Cox, S., "OGC-NA Name type specification - definitions: 590 Part 1 - basic name", OGC 09-048r3, March 2010. 592 [SFSQL] OpenGIS Consortium, Inc., "OpenGIS Simple Features 593 Specification For SQL Revision 1.1", OGC 99-049, May 1999. 595 [WFSv1] Vretanos, P., "Web Feature Service Implementation 596 Specification", OGC 02-058, May 2002. 598 [WGS84] National Imagery and Mapping Agency, "Department of 599 Defense World Geodetic System 1984, Third Edition", 1984. 601 Appendix A. Geometry Examples 603 Each of the examples below represents a valid and complete GeoJSON 604 object. 606 A.1. Points 608 Point coordinates are in x, y order (easting, northing for projected 609 coordinates, longitude, latitude for geographic coordinates): 611 { 612 "type": "Point", 613 "coordinates": [100.0, 0.0] 614 } 616 A.2. LineStrings 618 Coordinates of LineString are an array of positions (see "2.1.1. 619 Position"): 621 { 622 "type": "LineString", 623 "coordinates": [ 624 [100.0, 0.0], 625 [101.0, 1.0] 626 ] 627 } 629 A.3. Polygons 631 Coordinates of a Polygon are an array of LinearRing (cf. "2.1.6 632 Polygon") coordinate arrays. The first element in the array 633 represents the exterior ring. Any subsequent elements represent 634 interior rings (or holes). 636 No holes: 638 { 639 "type": "Polygon", 640 "coordinates": [ 641 [ 642 [100.0, 0.0], 643 [101.0, 0.0], 644 [101.0, 1.0], 645 [100.0, 1.0], 646 [100.0, 0.0] 647 ] 648 ] 649 } 651 With holes: 653 { 654 "type": "Polygon", 655 "coordinates": [ 656 [ 657 [100.0, 0.0], 658 [101.0, 0.0], 659 [101.0, 1.0], 660 [100.0, 1.0], 661 [100.0, 0.0] 662 ], 663 [ 664 [100.8, 0.8], 665 [100.8, 0.2], 666 [100.2, 0.2], 667 [100.2, 0.8], 668 [100.8, 0.8] 669 ] 670 ] 671 } 673 With hole crossing dateline: 675 { 676 "type": "Polygon", 677 "coordinates": [ 678 [ 679 [-170.0, 10.0], 680 [170.0, 10.0], 681 [170.0, -10.0], 682 [-170.0, -10.0], 683 [-170.0, 10.0] 684 ], 685 [ 686 [175.0, 5.0], 687 [-175.0, 5.0], 688 [-175.0, -5.0], 689 [175.0, -5.0], 690 [175.0, 5.0] 691 ] 692 ] 693 } 695 A.4. MultiPoints 697 Coordinates of a MultiPoint are an array of positions:: 699 { 700 "type": "MultiPoint", 701 "coordinates": [ 702 [100.0, 0.0], 703 [101.0, 1.0] 704 ] 705 } 707 A.5. MultiLineStrings 709 Coordinates of a MultiLineString are an array of LineString 710 coordinate arrays: 712 { 713 "type": "MultiLineString", 714 "coordinates": [ 715 [ 716 [100.0, 0.0], 717 [101.0, 1.0] 718 ], 719 [ 720 [102.0, 2.0], 721 [103.0, 3.0] 722 ] 723 ] 724 } 726 A.6. MultiPolygons 728 Coordinates of a MultiPolygon are an array of Polygon coordinate 729 arrays: 731 { 732 "type": "MultiPolygon", 733 "coordinates": [ 734 [ 735 [ 736 [102.0, 2.0], 737 [103.0, 2.0], 738 [103.0, 3.0], 739 [102.0, 3.0], 740 [102.0, 2.0] 741 ] 742 ], 743 [ 744 [ 745 [100.0, 0.0], 746 [101.0, 0.0], 747 [101.0, 1.0], 748 [100.0, 1.0], 749 [100.0, 0.0] 750 ], 751 [ 752 [100.2, 0.2], 753 [100.8, 0.2], 754 [100.8, 0.8], 755 [100.2, 0.8], 756 [100.2, 0.2] 757 ] 758 ] 759 ] 760 } 762 A.7. GeometryCollections 764 Each element in the geometries array of a GeometryCollection is one 765 of the geometry objects described above: 767 { 768 "type": "GeometryCollection", 769 "geometries": [{ 770 "type": "Point", 771 "coordinates": [100.0, 0.0] 772 }, { 773 "type": "LineString", 774 "coordinates": [ 775 [101.0, 0.0], 776 [102.0, 1.0] 777 ] 778 }] 779 } 781 Appendix B. Contributors 783 The GeoJSON format is the product of discussion on the GeoJSON 784 mailing list: http://lists.geojson.org/listinfo.cgi/geojson- 785 geojson.org. 787 Comments are solicited and should be addressed to the GeoJSON mailing 788 list at geojson@lists.geojson.org or to the GeoJSON issue tracker at 789 https://github.com/geojson/draft-geojson/issues. 791 Authors' Addresses 793 H. Butler 794 Hobu Inc. 796 M. Daly 797 Cadcorp 799 A. Doyle 800 MIT 802 S. Gillies 803 Mapbox Inc. 805 Email: sean.gillies@gmail.com 806 URI: http://sgillies.net 808 T. Schaub 809 Planet Labs 810 S. Hagen 811 Rheinaustr. 62 812 Bonn 53225 813 DE 815 Email: stefan@hagen.link 816 URI: http://stefan-hagen.website/