idnits 2.17.1 draft-butler-geojson-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 28, 2015) is 3376 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '170' on line 437 -- Looks like a reference, but probably isn't: '10' on line 436 == Missing Reference: '-170' is mentioned on line 436, but not defined -- Looks like a reference, but probably isn't: '11' on line 437 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 2 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: August 1, 2015 Cadcorp 6 A. Doyle 7 MIT 8 S. Gillies 9 Mapbox Inc. 10 T. Schaub 11 OpenGeo 12 S. Drees 14 January 28, 2015 16 The GeoJSON Format 17 draft-butler-geojson-05 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 August 1, 2015. 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 . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . 8 81 4. Bounding Box . . . . . . . . . . . . . . . . . . . . . . . . 9 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 6. Interoperability Considerations . . . . . . . . . . . . . . . 10 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 8.2. Informative References . . . . . . . . . . . . . . . . . 12 88 Appendix A. Geometry Examples . . . . . . . . . . . . . . . . . 13 89 A.1. Points . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 A.2. LineStrings . . . . . . . . . . . . . . . . . . . . . . . 13 91 A.3. Polygons . . . . . . . . . . . . . . . . . . . . . . . . 13 92 A.4. MultiPoints . . . . . . . . . . . . . . . . . . . . . . . 15 93 A.5. MultiLineStrings . . . . . . . . . . . . . . . . . . . . 15 94 A.6. MultiPolygons . . . . . . . . . . . . . . . . . . . . . . 16 95 A.7. GeometryCollections . . . . . . . . . . . . . . . . . . . 17 96 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 18 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 99 1. Introduction 101 GeoJSON is a format for encoding data about geographic features using 102 JavaScript Object Notation (JSON) [RFC7159]. The format is concerned 103 with features in the broadest sense; any thing with qualities that 104 are bounded in geographical space may be a feature whether it is a 105 physical structure or not. The concepts in GeoJSON are not new; they 106 are derived from pre-existing open geographic information system 107 standards (for COM, SQL, and XML) and have been streamlined to better 108 suit web application development using JSON. 110 GeoJSON comprises the seven concrete geometry types defined in the 111 OpenGIS Simple Features Implementation Specification for SQL [SFSQL]: 112 0-dimensional Point and MultiPoint; 1-dimensional curve LineString 113 and MultiLineString; 2-dimensional surface Polygon and MultiPolygon; 114 and the heterogeneous GeometryCollection. GeoJSON representations of 115 instances of these geometry types are analogous to the well-known 116 binary (WKB) and text (WKT) representations described in that same 117 specification. 119 GeoJSON also comprises the types Feature and FeatureCollection. 120 Feature objects in GeoJSON contain a geometry object with one of the 121 above geometry types and additional properties. A FeatureCollection 122 object contains an array of feature objects. This structure is 123 analogous to that of the Web Feature Service (WFS) response to 124 GetFeatures requests specified in [WFSv1] or to a KML Folder of 125 Placemarks [KMLv2.2]. Some implementations of the WFS specification 126 also provide GeoJSON formatted responses to GetFeature requests, but 127 there is no particular service model or feature type ontology implied 128 in the GeoJSON format specification. 130 Since its initial publication in 2008 [GJ2008], the GeoJSON format 131 specification has steadily grown in popularity. It is widely used in 132 JavaScript web mapping libraries, JSON-based document databases, and 133 web APIs. 135 1.1. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in 140 [RFC2119]. 142 1.2. Conventions Used in This Document 144 The ordering of the members of any JSON object defined in this 145 document MUST be considered irrelevant, as specified by [RFC7159]. 147 Some examples use the combination of a JavaScript single line comment 148 (//) followed by an ellipsis (...) as placeholder notation for 149 content deemed irrelevant by the authors. These placeholders must of 150 course be deleted or otherwise replaced, before attempting to 151 validate the corresponding JSON code example. 153 Whitespace is used in the examples inside this document to help 154 illustrate the data structures, but is not required. Unquoted 155 whitespace is not significant in JSON. 157 1.3. Specification of GeoJSON 159 This document updates the original GeoJSON format specification 160 [GJ2008]. 162 1.4. Definitions 164 o JavaScript Object Notation (JSON), and the terms object, name, 165 value, array, number, true, false, and null are to be interpreted 166 as defined in [RFC7159]. 168 o Inside this document the term "geometry type" refers to the seven 169 case-sensitive strings: "Point", "MultiPoint", "LineString", 170 "MultiLineString", "Polygon", "MultiPolygon", and 171 "GeometryCollection". 173 o As another shorthand notation, the term "GeoJSON types" refers to 174 the nine case-sensitive strings "Feature", "FeatureCollection" and 175 the geometry types listed above. 177 1.5. Example 179 A GeoJSON feature collection: 181 { 182 "type": "FeatureCollection", 183 "features": [{ 184 "type": "Feature", 185 "geometry": { 186 "type": "Point", 187 "coordinates": [102.0, 0.5] 188 }, 189 "properties": { 190 "prop0": "value0" 191 } 192 }, { 193 "type": "Feature", 194 "geometry": { 195 "type": "LineString", 196 "coordinates": [ 197 [102.0, 0.0], 198 [103.0, 1.0], 199 [104.0, 0.0], 200 [105.0, 1.0] 201 ] 202 }, 203 "properties": { 204 "prop0": "value0", 205 "prop1": 0.0 206 } 207 }, { 208 "type": "Feature", 209 "geometry": { 210 "type": "Polygon", 211 "coordinates": [ 212 [ 213 [100.0, 0.0], 214 [101.0, 0.0], 215 [101.0, 1.0], 216 [100.0, 1.0], 217 [100.0, 0.0] 218 ] 219 ] 220 }, 221 "properties": { 222 "prop0": "value0", 223 "prop1": { 224 "this": "that" 225 } 226 } 227 }] 228 } 230 2. GeoJSON Object 232 GeoJSON always consists of a single object. This object (referred to 233 as the GeoJSON object below) represents a geometry, feature, or 234 collection of features. 236 o The GeoJSON object MUST have a member with the name "type". The 237 value of the member MUST be one of the GeoJSON types. 239 o The GeoJSON object MAY have any number of other members. 241 o A GeoJSON object MAY have a "bbox" member, the value of which MUST 242 be a bounding box array (see 4. Bounding Boxes). 244 2.1. Geometry Object 246 A geometry object is a GeoJSON object where the "type" value is one 247 of the geometry types. A GeoJSON geometry object of any type other 248 than "GeometryCollection" MUST have a member with the name 249 "coordinates". The value of the coordinates member is always an 250 array. The structure of the elements in this array is determined by 251 the type of geometry. GeoJSON processors MAY interpret geometry 252 objects with empty coordinates arrays as null objects. 254 2.1.1. Position 256 A position is the fundamental geometry construct. The "coordinates" 257 member of a geometry object is composed of either: 259 o one position (in the case of a Point geometry), 261 o an array of positions (LineString or MultiPoint geometries), 263 o an array of arrays of positions (Polygons, MultiLineStrings), 265 o or a multidimensional array of positions (MultiPolygon). 267 A position is represented by an array of numbers. There MUST be two 268 or more elements. The first two elements will be longitude and 269 latitude, or easting and northing, precisely in that order and using 270 decimal numbers. Altitude or elevation MAY be included as an 271 optional third element. 273 Additional position elements MAY be included but MUST follow the 274 three specified above and MAY be ignored by software. Interpretation 275 and meaning of additional elements is beyond the scope of this 276 specification. 278 Examples of positions and geometries are provided in "Appendix A. 279 Geometry Examples". 281 2.1.2. Point 283 For type "Point", the "coordinates" member MUST be a single position. 285 2.1.3. MultiPoint 287 For type "MultiPoint", the "coordinates" member MUST be an array of 288 positions. 290 2.1.4. LineString 292 For type "LineString", the "coordinates" member MUST be an array of 293 two or more positions. 295 2.1.5. MultiLineString 297 For type "MultiLineString", the "coordinates" member MUST be an array 298 of LineString coordinate arrays. 300 2.1.6. Polygon 302 To specify a constraint specific to polygons, it is useful to 303 introduce the concept of a linear ring: 305 o A linear ring is a closed LineString with 4 or more positions. 307 o The first and last positions are equivalent (they represent 308 equivalent points). 310 o A linear ring is the boundary of a surface or the boundary of a 311 hole in a surface. 313 o A linear ring SHOULD follow right-hand rule with respect to the 314 area it bounds (ie. exterior rings are counter-clockwise, holes 315 are clockwise) 317 Though a linear ring is not explicitly represented as a GeoJSON 318 geometry type, it leads to a canonical formulation of the Polygon 319 geometry type definition as follows: 321 o For type "Polygon", the "coordinates" member MUST be an array of 322 linear ring coordinate arrays. 324 o For Polygons with more than one of these rings, the first MUST be 325 the exterior ring and any others MUST be interior rings. The 326 exterior ring bounds the surface and the interiors rings (if 327 present) bound holes within the surface. 329 2.1.7. MultiPolygon 331 For type "MultiPolygon", the "coordinates" member MUST be an array of 332 Polygon coordinate arrays. 334 2.1.8. Geometry Collection 336 A GeoJSON object with type "GeometryCollection" is a geometry object 337 which represents a collection of geometry objects. A geometry 338 collection MUST have a member with the name "geometries". The value 339 corresponding to "geometries" is an array. Each element in this 340 array is a GeoJSON geometry object. 342 2.2. Feature Object 344 A GeoJSON object with the type "Feature" is a feature object. 346 o A feature object MUST have a member with the name "geometry". The 347 value of the geometry member SHALL be either a geometry object as 348 defined above or, in the the case that the feature is unlocated, a 349 JSON null value. 351 o A feature object MUST have a member with the name "properties". 352 The value of the properties member is an object (any JSON object 353 or a JSON null value). 355 o If a feature has a commonly used identifier, that identifier 356 SHOULD be included as a member of the feature object with the name 357 "id" and the value of this member is either a JSON string or 358 number. 360 2.3. Feature Collection Object 362 A GeoJSON object with the type "FeatureCollection" is a feature 363 collection object. An object of type "FeatureCollection" MUST have a 364 member with the name "features". The value corresponding to 365 "features" is an array. Each element in the array is a feature 366 object as defined above. 368 3. Coordinate Reference System 370 The default reference system for all GeoJSON coordinates SHALL be a 371 geographic coordinate reference system, using the [WGS84] datum, and 372 with longitude and latitude units of decimal degrees. This 373 coordinate reference system is equivalent to the OGC's 374 "http://www.opengis.net/def/crs/OGC/1.3/CRS84" [OGCURL]. An OPTIONAL 375 third position element SHALL be the height in meters above the WGS 84 376 reference ellipsoid. For widest interoperability, GeoJSON data 377 SHOULD use this default coordinate reference system. 379 Other coordinate reference systems, including ones described by CRS 380 objects of the kind defined in [GJ2008] are NOT RECOMMENDED. GeoJSON 381 processing software SHALL NOT be expected to have access to 382 coordinate reference systems databases. Applications requiring CRS 383 other than the default MUST assume all responsibility for reference 384 system and coordinate accuracy. Furthermore, GeoJSON coordinates 385 MUST NOT under any circumstances use latitude, longitude order. See 386 Section 6, Interoperability Considerations, for guidance in 387 processing GeoJSON documents that do contain such a CRS object. 389 4. Bounding Box 391 A GeoJSON object MAY have a member named "bbox" to include 392 information on the coordinate range for its geometries, features, or 393 feature collections. The value of the bbox member MUST be an array 394 of length 2*n where n is the number of dimensions represented in the 395 contained geometries, with for all axes of the most south-westerly 396 point followed by all axes of the more north-easterly point. The 397 axes order of a bbox follows the axes order of geometries. 399 Example of a bbox member on a feature: 401 { 402 "type": "Feature", 403 "bbox": [-180.0, -90.0, 180.0, 90.0], 404 "geometry": { 405 "type": "Polygon", 406 "coordinates": [ 407 [ 408 [-180.0, 10.0], 409 [20.0, 90.0], 410 [180.0, -5.0], 411 [-30.0, -90.0] 412 ] 413 ] 414 } 415 //... 416 } 418 Example of a bbox member on a feature collection: 420 { 421 "type": "FeatureCollection", 422 "bbox": [100.0, 0.0, 105.0, 1.0], 423 "features": [ 424 //... 425 ] 426 } 428 Example of a bbox for line crossing the date-line: 430 { 431 "type": "Feature", 432 "bbox": [170, 10, -170, 11], 433 "geometry": { 434 "type": "LineString", 435 "coordinates": [ 436 [-170, 10], 437 [170, 11] 438 ] 439 } 440 //... 441 } 443 5. Security Considerations 445 GeoJSON shares security issues common to all JSON content types. See 446 [RFC7159] Section 12 for additional information. GeoJSON does not 447 provide executable content. 449 As with other geographic data formats, e.g., [KMLv2.2], providing 450 details about the locations of sensitive persons, animals, habitats, 451 and facilities can expose them to unauthorized tracking or injury. 452 GeoJSON does not provide privacy or integrity services; if sensitive 453 data requires privacy or integrity protection the service must be 454 provided externally. 456 6. Interoperability Considerations 458 There is a difference of opinion among geographic data formats over 459 whether latitude or longitude come first in a pair of numbers. 460 Longitude comes first in GeoJSON coordinates as it does in [KMLv2.2]. 462 Some commonly-used CRS definitions specify coordinate ordering that 463 is not longitude then latitude (for a geographic CRS) or easting then 464 northing (for a projected CRS). The CRS historically known as 465 "EPSG:4326" and more accurately named 466 "http://www.opengis.net/def/crs/EPSG/0/4326" is a prime example. 467 Using such a CRS is NOT RECOMMENDED due to the potential disruption 468 of interoperability. When such a CRS is encountered in GeoJSON, the 469 document should be processed with caution. Heuristics may be 470 necessary to interpret the coordinates properly; they may not be in 471 the required longitude, latitude order. 473 Earlier versions of the GeoJSON specification recommended use of OGC 474 URNs such as "urn:ogc:def:crs:OGC:1.3:CRS84" to name a CRS. This 475 version deprecates the URNs and recommends a change to HTTP URLs 476 [Section 3.1]. Widely deployed systems using, e.g. the GDAL and OGR 477 libraries, currently write the deprecated OGC URNs into GeoJSON 478 documents and will do so until replaced by newer versions. GeoJSON 479 processors should be prepared for either form. 481 In representing features that cross the dateline or the poles, 482 following the ring-orientation best practice (counter-clockwise 483 external rings, clockwise internal rings) and ensuring your bounding 484 boxes use the south-west corner as the first coordinate will improve 485 interoperability. Remain aware that software that represents edges 486 as straight cartesian lines and software that represents edges as 487 great circles will have different interpretations of edges, which 488 vary more the longer the edges are. Try to avoid edges of more than 489 180 degrees in length as far as possible. 491 7. IANA Considerations 493 The MIME media type for GeoJSON text is application/vnd.geo+json. 495 Type name: application 497 Subtype name: vnd.geo+json 499 Required parameters: n/a 501 Optional parameters: n/a 503 Encoding considerations: binary 505 Security considerations: See section 5 above 507 Interoperability considerations: See section 6 above 509 Published specification: draft-butler-geojson 511 Applications that use this media type: various 513 Additional information: 515 Magic number(s) : n/a 516 File extension(s) : .json, .geojson 518 Macintosh file type code : TEXT 520 Object Identifiers: n/a 522 Person to contact for further information: 524 Sean Gillies 526 sean.gillies@gmail.com 528 Intended usage: COMMON 530 Restrictions on usage: none 532 8. References 534 8.1. Normative References 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, March 1997. 539 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 540 Interchange Format", RFC 7159, March 2014. 542 8.2. Informative References 544 [GJ2008] Butler, H., Daly, M., Doyle, A., Gillies, S., Schaub, T., 545 and C. Schmidt, "The GeoJSON Format Specification", June 546 2008. 548 [KMLv2.2] Wilson, T., "OGC KML", OGC 07-147r2, April 2008. 550 [OGCURL] Cox, S., "OGC-NA Name type specification - definitions: 551 Part 1 - basic name", OGC 09-048r3, March 2010. 553 [SFSQL] OpenGIS Consortium, Inc., "OpenGIS Simple Features 554 Specification For SQL Revision 1.1", OGC 99-049, May 1999. 556 [WFSv1] Vretanos, P., "Web Feature Service Implementation 557 Specification", OGC 02-058, May 2002. 559 [WGS84] National Imagery and Mapping Agency, "Department of 560 Defense World Geodetic System 1984, Third Edition", 1984. 562 Appendix A. Geometry Examples 564 Each of the examples below represents a valid and complete GeoJSON 565 object. 567 A.1. Points 569 Point coordinates are in x, y order (easting, northing for projected 570 coordinates, longitude, latitude for geographic coordinates): 572 { 573 "type": "Point", 574 "coordinates": [100.0, 0.0] 575 } 577 A.2. LineStrings 579 Coordinates of LineString are an array of positions (see "2.1.1. 580 Position"): 582 { 583 "type": "LineString", 584 "coordinates": [ 585 [100.0, 0.0], 586 [101.0, 1.0] 587 ] 588 } 590 A.3. Polygons 592 Coordinates of a Polygon are an array of LinearRing (cf. "2.1.6 593 Polygon") coordinate arrays. The first element in the array 594 represents the exterior ring. Any subsequent elements represent 595 interior rings (or holes). 597 No holes: 599 { 600 "type": "Polygon", 601 "coordinates": [ 602 [ 603 [100.0, 0.0], 604 [101.0, 0.0], 605 [101.0, 1.0], 606 [100.0, 1.0], 607 [100.0, 0.0] 608 ] 609 ] 610 } 612 With holes: 614 { 615 "type": "Polygon", 616 "coordinates": [ 617 [ 618 [100.0, 0.0], 619 [101.0, 0.0], 620 [101.0, 1.0], 621 [100.0, 1.0], 622 [100.0, 0.0] 623 ], 624 [ 625 [100.8, 0.8], 626 [100.8, 0.2], 627 [100.2, 0.2], 628 [100.2, 0.8], 629 [100.8, 0.8] 630 ] 631 ] 632 } 634 With hole crossing dateline: 636 { 637 "type": "Polygon", 638 "coordinates": [ 639 [ 640 [-170.0, 10.0], 641 [170.0, 10.0], 642 [170.0, -10.0], 643 [-170.0, -10.0], 644 [-170.0, 10.0] 645 ], 646 [ 647 [175.0, 5.0], 648 [-175.0, 5.0], 649 [-175.0, -5.0], 650 [175.0, -5.0], 651 [175.0, 5.0] 652 ] 653 ] 654 } 656 A.4. MultiPoints 658 Coordinates of a MultiPoint are an array of positions:: 660 { 661 "type": "MultiPoint", 662 "coordinates": [ 663 [100.0, 0.0], 664 [101.0, 1.0] 665 ] 666 } 668 A.5. MultiLineStrings 670 Coordinates of a MultiLineString are an array of LineString 671 coordinate arrays: 673 { 674 "type": "MultiLineString", 675 "coordinates": [ 676 [ 677 [100.0, 0.0], 678 [101.0, 1.0] 679 ], 680 [ 681 [102.0, 2.0], 682 [103.0, 3.0] 683 ] 684 ] 685 } 687 A.6. MultiPolygons 689 Coordinates of a MultiPolygon are an array of Polygon coordinate 690 arrays: 692 { 693 "type": "MultiPolygon", 694 "coordinates": [ 695 [ 696 [ 697 [102.0, 2.0], 698 [103.0, 2.0], 699 [103.0, 3.0], 700 [102.0, 3.0], 701 [102.0, 2.0] 702 ] 703 ], 704 [ 705 [ 706 [100.0, 0.0], 707 [101.0, 0.0], 708 [101.0, 1.0], 709 [100.0, 1.0], 710 [100.0, 0.0] 711 ], 712 [ 713 [100.2, 0.2], 714 [100.8, 0.2], 715 [100.8, 0.8], 716 [100.2, 0.8], 717 [100.2, 0.2] 718 ] 719 ] 720 ] 721 } 723 A.7. GeometryCollections 725 Each element in the geometries array of a GeometryCollection is one 726 of the geometry objects described above: 728 { 729 "type": "GeometryCollection", 730 "geometries": [{ 731 "type": "Point", 732 "coordinates": [100.0, 0.0] 733 }, { 734 "type": "LineString", 735 "coordinates": [ 736 [101.0, 0.0], 737 [102.0, 1.0] 738 ] 739 }] 740 } 742 Appendix B. Contributors 744 The GeoJSON format is the product of discussion on the GeoJSON 745 mailing list: http://lists.geojson.org/listinfo.cgi/geojson- 746 geojson.org. 748 Comments are solicited and should be addressed to the GeoJSON mailing 749 list at geojson@lists.geojson.org or to the GeoJSON issue tracker at 750 https://github.com/geojson/draft-geojson/issues. 752 Authors' Addresses 754 H. Butler 755 Hobu Inc. 757 M. Daly 758 Cadcorp 760 A. Doyle 761 MIT 763 S. Gillies 764 Mapbox Inc. 766 Email: sean.gillies@gmail.com 767 URI: http://sgillies.net 769 T. Schaub 770 OpenGeo 771 S. Drees 772 Rheinaustr. 62 773 Bonn 53225 774 DE 776 Email: stefan@drees.name 777 URI: http://sdre.es/