├── .gitignore ├── CHANGES.txt ├── CONTRIBUTING.md ├── LICENSE.txt ├── Makefile ├── README.md ├── back.mkd ├── bib ├── README.txt ├── reference.RFC.2119.xml ├── reference.RFC.2616.xml ├── reference.RFC.2818.xml ├── reference.RFC.3986.xml ├── reference.RFC.5165.xml ├── reference.RFC.5246.xml ├── reference.RFC.6772.xml ├── reference.RFC.6838.xml ├── reference.RFC.7159.xml ├── reference.RFC.7464.xml └── reference.RFC.7493.xml ├── bin └── pandoc2rfc ├── charter.md ├── circle.yml ├── considerations.mkd ├── js ├── README.txt ├── example_01.geojson ├── example_02_a.geojson ├── example_02_b.geojson ├── example_02_c.geojson ├── example_appendix_01.geojson ├── example_appendix_02.geojson ├── example_appendix_03_a.geojson ├── example_appendix_03_b.geojson ├── example_appendix_03_c.geojson ├── example_appendix_04.geojson ├── example_appendix_05.geojson ├── example_appendix_06.geojson └── example_appendix_07.geojson ├── media-type └── registration.md ├── middle.mkd ├── template.xml └── transform.xsl /.gitignore: -------------------------------------------------------------------------------- 1 | draft-unpaginated.txt 2 | draft.html 3 | draft.nroff 4 | draft.txt 5 | draft.xml 6 | -------------------------------------------------------------------------------- /CHANGES.txt: -------------------------------------------------------------------------------- 1 | 20130516 - removed crsURN 2 | 20130402 - reduced crsRef to single label with domain RFC 5165 like URN, thus renamed it to crsURN 3 | 20130430 - moved repo to GeoJSONWG organization at https://github.com/GeoJSONWG/draft-geojson 4 | 20130428 - typos corrected, editorial changes throughout the document and several notes partly explaining thes or requesting further changes or additions. Correction of inconsistent may in GeoJSON Object first list item into MUST, merge with second listitem and provision of js and bib folders 5 | 20130427 - initial draft 6 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | Before submitting feedback, please familiarize yourself with our current issues 4 | list and review the [working group 5 | documents](https://datatracker.ietf.org/wg/geojson/documents/) and [mailing 6 | list discussion](https://mailarchive.ietf.org/arch/browse/geojson/). If you're 7 | new to this, you may also want to read the [Tao of the 8 | IETF](https://www.ietf.org/tao.html). 9 | 10 | Be aware that all contributions to the specification fall under the "NOTE WELL" 11 | terms outlined below. 12 | 13 | 1. The best way to provide feedback (editorial or design) and ask questions is 14 | sending an e-mail to our mailing list 15 | ([info](https://www.ietf.org/mailman/listinfo/geojson)). This will ensure that 16 | the entire Working Group sees your input in a timely fashion. 17 | 18 | 2. If you have **editorial** suggestions (i.e., those that do not change the 19 | meaning of the specification), you can either: 20 | 21 | a) Fork this repository and submit a pull request; this is the lowest 22 | friction way to get editorial changes in. 23 | 24 | b) Submit a new issue to Github, and mention that you believe it is editorial 25 | in the issue body. It is not necessary to notify the mailing list for 26 | editorial issues. 27 | 28 | c) Make comments on individual commits in Github. Note that this feedback is 29 | processed only with best effort by the editors, so it should only be used for 30 | quick editorial suggestions or questions. 31 | 32 | 3. For non-editorial (i.e., **design**) issues, you can also create an issue on 33 | Github. However, you **must notify the mailing list** when creating such issues, 34 | providing a link to the issue in the message body. 35 | 36 | Note that **github issues are not for substantial discussions**; the only 37 | appropriate place to discuss design issues is on the mailing list itself. 38 | 39 | 40 | ## NOTE WELL 41 | 42 | Any submission to the [IETF](https://www.ietf.org/) intended by the Contributor 43 | for publication as all or part of an IETF Internet-Draft or RFC and any 44 | statement made within the context of an IETF activity is considered an "IETF 45 | Contribution". Such statements include oral statements in IETF sessions, as 46 | well as written and electronic communications made at any time or place, which 47 | are addressed to: 48 | 49 | * The IETF plenary session 50 | * The IESG, or any member thereof on behalf of the IESG 51 | * Any IETF mailing list, including the IETF list itself, any working group 52 | or design team list, or any other list functioning under IETF auspices 53 | * Any IETF working group or portion thereof 54 | * Any Birds of a Feather (BOF) session 55 | * The IAB or any member thereof on behalf of the IAB 56 | * The RFC Editor or the Internet-Drafts function 57 | * All IETF Contributions are subject to the rules of 58 | [RFC 5378](https://tools.ietf.org/html/rfc5378) and 59 | [RFC 3979](https://tools.ietf.org/html/rfc3979) 60 | (updated by [RFC 4879](https://tools.ietf.org/html/rfc4879)). 61 | 62 | Statements made outside of an IETF session, mailing list or other function, 63 | that are clearly not intended to be input to an IETF activity, group or 64 | function, are not IETF Contributions in the context of this notice. 65 | 66 | Please consult [RFC 5378](https://tools.ietf.org/html/rfc5378) and [RFC 67 | 3979](https://tools.ietf.org/html/rfc3979) for details. 68 | 69 | A participant in any IETF activity is deemed to accept all IETF rules of 70 | process, as documented in Best Current Practices RFCs and IESG Statements. 71 | 72 | A participant in any IETF activity acknowledges that written, audio and video 73 | records of meetings may be made and may be available to the public. 74 | -------------------------------------------------------------------------------- /LICENSE.txt: -------------------------------------------------------------------------------- 1 | This derived work is based upon: 2 | 3 | ================================ 4 | The GeoJSON Format Specification 5 | ================================ 6 | 7 | :Abstract: 8 | GeoJSON is a geospatial data interchange format based on JavaScript Object 9 | Notation (JSON). 10 | 11 | :Authors: 12 | Howard Butler (Hobu Inc.), 13 | Martin Daly (Cadcorp), 14 | Allan Doyle (MIT), 15 | Sean Gillies (UNC-Chapel Hill), 16 | Tim Schaub (Planet Labs), 17 | Christopher Schmidt (MetaCarta) 18 | 19 | :Revision: 1.0 20 | :Date: 16 June 2008 21 | 22 | :Copyright: Copyright |copy| 2008 by the Authors. This work is licensed under a `Creative Commons Attribution 3.0 23 | United States License`__. 24 | 25 | .. |copy| unicode:: 0xA9 .. copyright sign 26 | .. __: http://creativecommons.org/licenses/by/3.0/us/ 27 | 28 | 29 | For details on and links to the The GeoJSON Format Specification please see the README.md. 30 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | 2 | all: raw html nroff text xml 3 | 4 | raw: 5 | ./bin/pandoc2rfc -R -t template.xml -x transform.xsl back.mkd considerations.mkd middle.mkd 6 | mv draft.txt draft-unpaginated.txt 7 | 8 | html: 9 | ./bin/pandoc2rfc -H -t template.xml -x transform.xsl back.mkd considerations.mkd middle.mkd 10 | nroff: 11 | ./bin/pandoc2rfc -N -t template.xml -x transform.xsl back.mkd considerations.mkd middle.mkd 12 | text: 13 | ./bin/pandoc2rfc -T -t template.xml -x transform.xsl back.mkd considerations.mkd middle.mkd 14 | xml: 15 | ./bin/pandoc2rfc -X -t template.xml -x transform.xsl back.mkd considerations.mkd middle.mkd 16 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # GeoJSON 2 | 3 | [![Circle CI](https://circleci.com/gh/geojson/draft-geojson.svg?style=svg)](https://circleci.com/gh/geojson/draft-geojson) 4 | 5 | Incubator for GeoJSON spec rewrite and subsequent IETF RFC submission. 6 | 7 | ## Status 8 | 9 | An IETF WG has been chartered: https://tools.ietf.org/wg/geojson/ and has 10 | adopted `draft-butler-geojson`. The official draft is 11 | https://datatracker.ietf.org/doc/draft-ietf-geojson/. 12 | 13 | ## Contributing 14 | 15 | Substantial discussion happens on the GeoJSON email list: 16 | https://www.ietf.org/mailman/listinfo/geojson. Specific edits to the draft 17 | are made via issues and pull requests in this GitHub repo. 18 | 19 | See https://github.com/geojson/draft-geojson/blob/master/CONTRIBUTING.md 20 | 21 | ## Generating Docs 22 | 23 | This project uses the workflow described in 24 | http://tools.ietf.org/html/rfc7328.html to generate RFC text from Markdown 25 | files and an XML template. 26 | 27 | ### Dependencies 28 | 29 | * [`xml2rfc`](https://pypi.python.org/pypi/xml2rfc/) 30 | * [`pandoc2rfc`](https://raw.github.com/miekg/pandoc2rfc/master/pandoc2rfc) 31 | 32 | ### Transform Markdown to XML etc. 33 | 34 | Inside the working copy of the repo run the build script to manifest the draft 35 | as HTML, nroff, XML, and plain text. 36 | 37 | ```bash 38 | $ make 39 | ``` 40 | -------------------------------------------------------------------------------- /back.mkd: -------------------------------------------------------------------------------- 1 | # Geometry Examples 2 | 3 | Each of the examples below represents a valid and complete GeoJSON 4 | object. 5 | 6 | ## Points 7 | 8 | Point coordinates are in x, y order (easting, northing for projected 9 | coordinates, longitude, latitude for geographic coordinates): 10 | 11 | { 12 | "type": "Point", 13 | "coordinates": [100.0, 0.0] 14 | } 15 | 16 | ## LineStrings 17 | 18 | Coordinates of LineString are an array of positions (see [](#position)): 19 | 20 | { 21 | "type": "LineString", 22 | "coordinates": [ 23 | [100.0, 0.0], 24 | [101.0, 1.0] 25 | ] 26 | } 27 | 28 | ## Polygons 29 | 30 | Coordinates of a Polygon are an array of LinearRing (see [](#polygon)) 31 | coordinate arrays. The first element in the array represents the exterior ring. 32 | Any subsequent elements represent interior rings (or holes). 33 | 34 | No holes: 35 | 36 | { 37 | "type": "Polygon", 38 | "coordinates": [ 39 | [ 40 | [100.0, 0.0], 41 | [101.0, 0.0], 42 | [101.0, 1.0], 43 | [100.0, 1.0], 44 | [100.0, 0.0] 45 | ] 46 | ] 47 | } 48 | 49 | With holes: 50 | 51 | { 52 | "type": "Polygon", 53 | "coordinates": [ 54 | [ 55 | [100.0, 0.0], 56 | [101.0, 0.0], 57 | [101.0, 1.0], 58 | [100.0, 1.0], 59 | [100.0, 0.0] 60 | ], 61 | [ 62 | [100.8, 0.8], 63 | [100.8, 0.2], 64 | [100.2, 0.2], 65 | [100.2, 0.8], 66 | [100.8, 0.8] 67 | ] 68 | ] 69 | } 70 | 71 | ## MultiPoints 72 | 73 | Coordinates of a MultiPoint are an array of positions:: 74 | 75 | { 76 | "type": "MultiPoint", 77 | "coordinates": [ 78 | [100.0, 0.0], 79 | [101.0, 1.0] 80 | ] 81 | } 82 | 83 | ## MultiLineStrings 84 | 85 | Coordinates of a MultiLineString are an array of LineString coordinate 86 | arrays: 87 | 88 | { 89 | "type": "MultiLineString", 90 | "coordinates": [ 91 | [ 92 | [100.0, 0.0], 93 | [101.0, 1.0] 94 | ], 95 | [ 96 | [102.0, 2.0], 97 | [103.0, 3.0] 98 | ] 99 | ] 100 | } 101 | 102 | ## MultiPolygons 103 | 104 | Coordinates of a MultiPolygon are an array of Polygon coordinate 105 | arrays: 106 | 107 | { 108 | "type": "MultiPolygon", 109 | "coordinates": [ 110 | [ 111 | [ 112 | [102.0, 2.0], 113 | [103.0, 2.0], 114 | [103.0, 3.0], 115 | [102.0, 3.0], 116 | [102.0, 2.0] 117 | ] 118 | ], 119 | [ 120 | [ 121 | [100.0, 0.0], 122 | [101.0, 0.0], 123 | [101.0, 1.0], 124 | [100.0, 1.0], 125 | [100.0, 0.0] 126 | ], 127 | [ 128 | [100.2, 0.2], 129 | [100.2, 0.8], 130 | [100.8, 0.8], 131 | [100.8, 0.2], 132 | [100.2, 0.2] 133 | ] 134 | ] 135 | ] 136 | } 137 | 138 | ## GeometryCollections 139 | 140 | Each element in the geometries array of a GeometryCollection is one of 141 | the geometry objects described above: 142 | 143 | { 144 | "type": "GeometryCollection", 145 | "geometries": [{ 146 | "type": "Point", 147 | "coordinates": [100.0, 0.0] 148 | }, { 149 | "type": "LineString", 150 | "coordinates": [ 151 | [101.0, 0.0], 152 | [102.0, 1.0] 153 | ] 154 | }] 155 | } 156 | 157 | # Changes from pre-IETF Specification 158 | 159 | This appendix briefly summarizes non-editorial changes from the 2008 160 | specification [GJ2008]. 161 | 162 | ## Normative Changes 163 | 164 | * Specification of coordinate reference systems has been removed, i.e., 165 | the "crs" member of [GJ2008] is no longer used. 166 | 167 | * In the absence of elevation values, applications sensitive to height 168 | or depth SHOULD interpret positions as being at local ground or sea 169 | level (see [](#coordinate-reference-system)). 170 | 171 | * Implementations SHOULD NOT extend position arrays beyond 3 elements 172 | (see [](#position)). 173 | 174 | * A line between two positions is a straight Cartesian line (see 175 | [](#position)). 176 | 177 | * Polygon rings MUST follow the right-hand rule for orientation 178 | (counter-clockwise external rings, clockwise internal rings). 179 | 180 | * The values of a "bbox" array are "[west, south, east, north]", 181 | not "[minx, miny, maxx, maxy]" (see [](#bounding-box)). 182 | 183 | * A Feature object's "id" member is a string or number (see 184 | [](#feature-object)). 185 | 186 | * Extensions MAY be used, but MUST NOT change the semantics of 187 | GeoJSON members and types (see [](#extending-geojson)). 188 | 189 | * GeoJSON objects MUST NOT contain the defining members of other types 190 | (see [](#semantics-of-geojson-members-and-types-are-not-changeable)). 191 | 192 | * The media type for GeoJSON is application/geo+json. 193 | 194 | ## Informative Changes 195 | 196 | * The definition of a GeoJSON text has been added. 197 | 198 | * Rules for mapping 'geo' URIs have been added. 199 | 200 | * A recommendation of the I-JSON [RFC7493] constraints has been added. 201 | 202 | * Implementers are cautioned about the effect of excessive coordinate 203 | precision on interoperability. 204 | 205 | * Interoperability concerns of geometry collections are noted. These 206 | objects should be used sparingly (see [](#geometry-collection)). 207 | 208 | # GeoJSON Text Sequences 209 | 210 | All GeoJSON objects defined in this specification - FeatureCollection, 211 | Feature, and Geometry - consist of exactly one JSON object. However, 212 | there may be circumstances in which applications need to represent sets 213 | or sequences of these objects (over and above the grouping of Feature 214 | objects in a FeatureCollection), e.g. in order to efficiently "stream" 215 | large numbers of Feature objects. The definition of such sets or 216 | sequences is outside the scope of this specification. 217 | 218 | If such a representation is needed, a new media type is required that 219 | has the ability to represent these sets or sequences. When defining such 220 | a media type, it may be useful to base it on "JSON Text Sequences" 221 | [RFC7464], leaving the foundations of how to represent multiple JSON 222 | objects to that specification, and only defining how it applies to 223 | GeoJSON objects. 224 | -------------------------------------------------------------------------------- /bib/README.txt: -------------------------------------------------------------------------------- 1 | These references are included through entity refs in template.xml but 2 | are not written by us, instead they are pulled directly from IETF. 3 | 4 | The procedure is more or less like (environment variable ${RFC_HOME} 5 | holds absolute path to is project folder): 6 | 7 | $> cd ${RFC_HOME} 8 | $> mkdir bib_full && cd bib_full 9 | $> curl -O http://xml.resource.org/public/rfc/bibxml.tgz 10 | $> tar -xzf bibxml.tgz && rm -f bibxml.tgz 11 | $> rfcs='2119 2616 2818 3986 5165 5246 6838 7159 7493' 12 | $> for rfc in $rfcs; do cp -a reference.RFC.${rfc}.xml ../bib/; done 13 | $> cd .. && rm -fr bib_full 14 | 15 | -------------------------------------------------------------------------------- /bib/reference.RFC.2119.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Key words for use in RFCs to Indicate Requirement Levels 7 | 8 | Harvard University 9 |
10 | 11 | 1350 Mass. Ave. 12 | Cambridge 13 | MA 02138 14 | - +1 617 495 3864 15 | sob@harvard.edu
 16 | 17 | General 18 | keyword 19 | 20 | 21 | In many standards track documents several words are used to signify 22 | the requirements in the specification. These words are often 23 | capitalized. This document defines these words as they should be 24 | interpreted in IETF documents. Authors who follow these guidelines 25 | should incorporate this phrase near the beginning of their document: 26 | 27 | 28 | 29 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 30 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 31 | "OPTIONAL" in this document are to be interpreted as described in 32 | RFC 2119. 33 | 34 | 35 | Note that the force of these words is modified by the requirement 36 | level of the document in which they are used. 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | -------------------------------------------------------------------------------- /bib/reference.RFC.2616.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Hypertext Transfer Protocol -- HTTP/1.1 7 | 8 | Department of Information and Computer Science 9 |
10 | 11 | University of California, Irvine 12 | Irvine 13 | CA 14 | 92697-3425 15 | +1(949)824-1715 16 | fielding@ics.uci.edu
 17 | 18 | World Wide Web Consortium 19 |
20 | 21 | MIT Laboratory for Computer Science, NE43-356 22 | 545 Technology Square 23 | Cambridge 24 | MA 25 | 02139 26 | +1(617)258-8682 27 | jg@w3.org
 28 | 29 | Compaq Computer Corporation 30 |
31 | 32 | Western Research Laboratory 33 | 250 University Avenue 34 | Palo Alto 35 | CA 36 | 94305 37 | mogul@wrl.dec.com
 38 | 39 | World Wide Web Consortium 40 |
41 | 42 | MIT Laboratory for Computer Science, NE43-356 43 | 545 Technology Square 44 | Cambridge 45 | MA 46 | 02139 47 | +1(617)258-8682 48 | frystyk@w3.org
 49 | 50 | Xerox Corporation 51 |
52 | 53 | MIT Laboratory for Computer Science, NE43-356 54 | 3333 Coyote Hill Road 55 | Palo Alto 56 | CA 57 | 94034 58 | masinter@parc.xerox.com
 59 | 60 | Microsoft Corporation 61 |
62 | 63 | 1 Microsoft Way 64 | Redmond 65 | WA 66 | 98052 67 | paulle@microsoft.com
 68 | 69 | World Wide Web Consortium 70 |
71 | 72 | MIT Laboratory for Computer Science, NE43-356 73 | 545 Technology Square 74 | Cambridge 75 | MA 76 | 02139 77 | +1(617)258-8682 78 | timbl@w3.org
 79 | 80 | 81 | 82 | The Hypertext Transfer Protocol (HTTP) is an application-level 83 | protocol for distributed, collaborative, hypermedia information 84 | systems. It is a generic, stateless, protocol which can be used for 85 | many tasks beyond its use for hypertext, such as name servers and 86 | distributed object management systems, through extension of its 87 | request methods, error codes and headers . A feature of HTTP is 88 | the typing and negotiation of data representation, allowing systems 89 | to be built independently of the data being transferred. 90 | 91 | 92 | HTTP has been in use by the World-Wide Web global information 93 | initiative since 1990. This specification defines the protocol 94 | referred to as "HTTP/1.1", and is an update to RFC 2068 . 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | -------------------------------------------------------------------------------- /bib/reference.RFC.2818.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | HTTP Over TLS 7 | 8 | 9 | 10 | 11 | This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community. 12 | 13 | 14 | 15 | 16 | -------------------------------------------------------------------------------- /bib/reference.RFC.3986.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Uniform Resource Identifier (URI): Generic Syntax 7 | 8 | World Wide Web Consortium 9 |
10 | 11 | Massachusetts Institute of Technology 12 | 77 Massachusetts Avenue 13 | Cambridge 14 | MA 15 | 02139 16 | USA 17 | +1-617-253-5702 18 | +1-617-258-5999 19 | timbl@w3.org 20 | http://www.w3.org/People/Berners-Lee/
 21 | 22 | Day Software 23 |
24 | 25 | 5251 California Ave., Suite 110 26 | Irvine 27 | CA 28 | 92617 29 | USA 30 | +1-949-679-2960 31 | +1-949-679-2972 32 | fielding@gbiv.com 33 | http://roy.gbiv.com/
 34 | 35 | Adobe Systems Incorporated 36 |
37 | 38 | 345 Park Ave 39 | San Jose 40 | CA 41 | 95110 42 | USA 43 | +1-408-536-3024 44 | LMM@acm.org 45 | http://larry.masinter.net/
 46 | 47 | Applications 48 | uniform resource identifier 49 | URI 50 | URL 51 | URN 52 | WWW 53 | resource 54 | 55 | 56 | A Uniform Resource Identifier (URI) is a compact sequence of characters 57 | that identifies an abstract or physical resource. This specification 58 | defines the generic URI syntax and a process for resolving URI references 59 | that might be in relative form, along with guidelines and security 60 | considerations for the use of URIs on the Internet. 61 | The URI syntax defines a grammar that is a superset of all valid URIs, 62 | allowing an implementation to parse the common components of a URI 63 | reference without knowing the scheme-specific requirements of every 64 | possible identifier. This specification does not define a generative 65 | grammar for URIs; that task is performed by the individual 66 | specifications of each URI scheme. 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | -------------------------------------------------------------------------------- /bib/reference.RFC.5165.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC) 7 | 8 | 9 | 10 | 11 | This document describes a Uniform Resource Name (URN) namespace that is engineered by the Open Geospatial Consortium (OGC) for naming persistent resources published by the OGC. The formal Namespace IDentifier (NID) is "ogc". This memo provides information for the Internet community. 12 | 13 | 14 | 15 | 16 | -------------------------------------------------------------------------------- /bib/reference.RFC.5246.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | The Transport Layer Security (TLS) Protocol Version 1.2 7 | 8 | 9 | 10 | 11 | 12 | 13 | This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] 14 | 15 | 16 | 17 | 18 | -------------------------------------------------------------------------------- /bib/reference.RFC.6772.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access to data based on the current location of the Target.Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information, whereas the other one applies to geodetic location information. Both algorithms come with limitations. There are circumstances where the amount of location obfuscation provided is less than what is desired. These algorithms might not be appropriate for all application domains. [STANDARDS-TRACK] 14 | 15 | 16 | 17 | 18 | -------------------------------------------------------------------------------- /bib/reference.RFC.6838.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Media Type Specifications and Registration Procedures 6 | 7 | 8 | 9 | 10 | This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. 11 | 12 | 13 | 14 | 15 | 16 | -------------------------------------------------------------------------------- /bib/reference.RFC.7159.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | The JavaScript Object Notation (JSON) Data Interchange Format 6 | 7 | 8 | JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. 9 | 10 | 11 | 12 | -------------------------------------------------------------------------------- /bib/reference.RFC.7464.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | JavaScript Object Notation (JSON) Text Sequences 6 | 7 | 8 | This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A). 9 | 10 | 11 | 12 | 13 | -------------------------------------------------------------------------------- /bib/reference.RFC.7493.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | The I-JSON Message Format 6 | 7 | 8 | I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results. 9 | 10 | 11 | 12 | -------------------------------------------------------------------------------- /bin/pandoc2rfc: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | # (c) Miek Gieben, 2013, A small wrapper around Pandoc, xsltproc and xml2rfc to create an I-D. 3 | TRANS=/usr/share/pandoc2rfc/transform.xsl 4 | TEMPLATE=template.xml 5 | VERSION="@VERSION@" 6 | 7 | function usage { 8 | echo "Usage: pandoc2rfc [-1THXNRh] [FILE]..." 9 | echo "Process files with Pandoc syntax and run xml2rfc on them." 10 | echo 11 | echo " -T create a draft.txt (with page breaks), this is the default" 12 | echo " -R create a draft.txt (raw, unpaginated)" 13 | echo " -H create a draft.html" 14 | echo " -M create a draft.html (using rfcmarkup)" 15 | echo " -X create a draft.xml" 16 | echo " -N create a draft.nroff" 17 | echo " -C clean, remove all drafts" 18 | echo " -1 parse FILE as XML and output Pandoc" 19 | echo " -2 set output to xml2rfc v2 XML" 20 | echo " -3 set output to xml2rfc v3 XML" 21 | echo " -n pass --nonet to xsltproc" 22 | echo " -v be verbose (show warnings)" 23 | echo " -d debug mode, do not delete intermediate XML files" 24 | echo " -t template.xml path to template.xml, defaults to current directory" 25 | echo " -x transform.xsl path to transform.xsl, defaults to /usr/share/pandoc2rfc/transform.xsl" 26 | echo " -h this help" 27 | echo " -V show version ($VERSION)" 28 | } 29 | 30 | # As the extension for Pandoc is not really fixed, we try 31 | # .pdc, .pandoc, .mkd, .markdown, .md and .txt 32 | function extension { 33 | for ext in .pdc .pandoc .mkd .markdown .md .txt; do 34 | base=$(basename "$1" $ext) 35 | if [[ "$base" != $1 ]]; then 36 | echo $base 37 | return 0 38 | fi 39 | done 40 | echo "" 41 | } 42 | 43 | REV="" 44 | OUT="-f draft.txt --text" 45 | MARKUP="" 46 | RM=rm 47 | NONET="" 48 | Q="-q" 49 | while getopts "nvdht:x:THMXNRCV123" o; do 50 | case $o in 51 | T) ;; 52 | M) MARKUP="1";; 53 | 1) REV="1"; TRANS=/usr/share/pandoc2rfc/plain.xsl;; 54 | 2) :;; 55 | 3) :;; 56 | R) OUT="-f draft.txt --raw";; 57 | H) OUT="-f draft.html --html";; 58 | X) OUT="-f draft.xml --exp";; 59 | N) OUT="-f draft.nroff --nroff";; 60 | n) NONET="--nonet";; 61 | C) [[ -n "$VERBOSE" ]] && echo rm -f draft.{txt,html,xml,nroff} >&2 62 | rm -f draft.{txt,html,xml,nroff} && exit 0;; 63 | h) usage && exit 0;; 64 | V) echo $VERSION && exit 0;; 65 | t) TEMPLATE="$OPTARG";; 66 | x) TRANS="$OPTARG";; 67 | v) VERBOSE="y"; Q="";; 68 | d) RM=":" 69 | esac 70 | done 71 | shift $((OPTIND - 1)) 72 | 73 | if [[ -n "$REV" ]]; then 74 | [[ -n "$VERBOSE" ]] && echo sed \'s/^ *//\' \< "$1" \| xsltproc $NONET $TRANS - >&2 75 | sed 's/^ *//' < "$1" | xsltproc $NONET $TRANS - 76 | exit 77 | fi 78 | 79 | XML="" 80 | for f in "$@"; do 81 | base=$(extension "$f") 82 | if [[ -z "$base" ]]; then 83 | echo $0: Could not detect extension for $f >&2 84 | exit 1 85 | fi 86 | [[ -n "$VERBOSE" ]] && echo pandoc -t docbook -s $f \| xsltproc $NONET $TRANS - \> "$base".xml >&2 87 | pandoc -t docbook -s "$f" | xsltproc $NONET $TRANS - > "$base".xml || exit 1 88 | XML="$XML $base.xml" 89 | done 90 | # if XML is filled we have files to process otherwise process stdin 91 | if [[ -n "$XML" ]]; then 92 | [[ -n "$VERBOSE" ]] && echo xml2rfc $Q $TEMPLATE $OUT \&\& $RM $XML >&2 93 | xml2rfc $Q $TEMPLATE $OUT && $RM $XML 94 | if [[ -n "$MARKUP" ]]; then 95 | [[ -n "$VERBOSE" ]] && echo rfcmarkup url=file:///$PWD/draft.txt \> draft.html \&\& rm draft.txt >&2 96 | rfcmarkup url=file:///$PWD/draft.txt > draft.html && rm draft.txt 97 | fi 98 | else 99 | if [[ -n "$MARKUP" ]]; then 100 | [[ -n "$VERBOSE" ]] && echo pandoc -t docbook -s \| xsltproc $NONET $TRANS - \| rfcmarkup url=file:///dev/stdin >&2 101 | pandoc -t docbook -s | xsltproc $NONET $TRANS - | rfcmarkup url=file:///dev/stdin || exit 1 102 | else 103 | [[ -n "$VERBOSE" ]] && echo pandoc -t docbook -s \| xsltproc $NONET $TRANS - >&2 104 | pandoc -t docbook -s | xsltproc $NONET $TRANS - || exit 1 105 | fi 106 | fi 107 | -------------------------------------------------------------------------------- /charter.md: -------------------------------------------------------------------------------- 1 | Proposed GeoJSON WG Charter 2 | =========================== 3 | 4 | GeoJSON 5 | ------- 6 | 7 | GeoJSON is a format for encoding data about geographic features using 8 | JavaScript Object Notation (JSON) [RFC7159]. Geographic features need not be 9 | physical things; anything with properties that are bounded in space may be 10 | considered a feature. GeoJSON provides a means of representing both the 11 | properties and spatial extent of features. 12 | 13 | The GeoJSON format specification was published at http://geojson.org in 2008. 14 | GeoJSON today plays an important and growing role in many spatial databases, web 15 | APIs, and open data platforms. Consequently, implementers increasingly demand 16 | formal standardization, improvements in the specification, guidance on 17 | extensibility, and the means to utilize larger GeoJSON datasets. 18 | 19 | This WG will work on a GeoJSON Format RFC that specifies the format more 20 | precisely, serves as a better guide for implementers, and improves extensibility 21 | of the format. The work will start from an Internet-Draft written by the 22 | original GeoJSON authors: draft-butler-geojson [1]. 23 | 24 | This WG will work on GeoJSON mappings of 'geo' URIs, reinforcing the use of RFC 25 | 5870. 26 | 27 | This WG will work on a format for a streamable sequence of GeoJSON texts based 28 | on RFC 7464 (JSON Text Sequences) to address the difficulties in serializing 29 | very large sequences of features or feature sequences of indeterminate length. 30 | 31 | GeoJSON objects represent geographic features only and do not specify 32 | associations between geographic features and particular devices, users, or 33 | facilities. Any association with a particular device, user, or facility requires 34 | another protocol. As such, a GeoJSON object does not fit the "Location 35 | Information" definition according to Section 5.2 of RFC 3693, because there is 36 | not necessarily a "Device" involved. Because there is also no way to specify the 37 | identity of a "Target" within the confines of a GeoJSON object, it also does not 38 | fit the specification of a "Location Object" (Section 5.2 of RFC 3693, Section 39 | 3.2 of RFC 6280). When a GeoJSON object is used in a context where it identifies 40 | the location of a target, it becomes subject to the architectural, security, and 41 | privacy considerations in RFC 6280. The application of those considerations is 42 | specific to protocols that make use of GeoJSON objects and is out of scope for 43 | the GeoJSON WG. As the WG considers extensibility it will be careful not to 44 | preclude extensions that would allow GeoJSON objects to become location objects 45 | unless the group determines such extensibility would be harmful. 46 | 47 | Deliverables: 48 | 49 | * A GeoJSON format specification document including mappings of 'geo' URIs 50 | * A document describing a format for a streamable sequence of GeoJSON texts 51 | 52 | [1] https://tools.ietf.org/html/draft-butler-geojson 53 | -------------------------------------------------------------------------------- /circle.yml: -------------------------------------------------------------------------------- 1 | machine: 2 | python: 3 | version: 2.7.10 4 | 5 | dependencies: 6 | pre: 7 | - sudo apt-get update; sudo apt-get install pandoc 8 | - pip install -U pip 9 | - pip install xml2rfc 10 | 11 | test: 12 | override: 13 | - make 14 | - head draft.txt 15 | 16 | general: 17 | artifacts: 18 | - draft.txt 19 | - draft.html 20 | -------------------------------------------------------------------------------- /considerations.mkd: -------------------------------------------------------------------------------- 1 | # Security Considerations 2 | 3 | GeoJSON shares security issues common to all JSON content types. See 4 | [RFC7159] Section 12 for additional information. GeoJSON does not 5 | provide executable content. 6 | 7 | GeoJSON does not provide privacy or integrity services. If sensitive 8 | data requires privacy or integrity protection, those must be provided by 9 | the transport — for example TLS or HTTPS. There will be cases in which 10 | stored data need protection, which is out of scope for this document. 11 | 12 | As with other geographic data formats, e.g., [KMLv2.2], providing details about 13 | the locations of sensitive persons, animals, habitats, and facilities can 14 | expose them to unauthorized tracking or injury. Data providers should recognize 15 | the risk of inadvertantly identifying individuals if locations in anonymized 16 | datasets are not adequately skewed or not sufficiently fuzzed [Sweeney] and 17 | recognize that the effectiveness of location obscuration is limited by a number 18 | of factors and is unlikely to be an effective defense against a determined 19 | attack [RFC6772]. 20 | 21 | # Interoperability Considerations 22 | 23 | ## I-JSON 24 | 25 | GeoJSON texts should follow the constraints of I-JSON [RFC7493] for 26 | maximum interoperability. 27 | 28 | ## Coordinate Precision 29 | 30 | The size of a GeoJSON text in bytes is a major interoperability 31 | consideration and precision of coordinate values has a large impact on 32 | the size of texts. A GeoJSON text containing many detailed polygons can 33 | be inflated almost by a factor of two by increasing coordinate precision 34 | from 6 to 15 decimal places. For geographic coordinates with units of 35 | degrees, 6 decimal places (a default common in, e.g., sprintf) amounts 36 | to about 10 centimeters, a precision well within that of current GPS 37 | systems. Implementations should consider the cost of using a greater 38 | precision than necessary. 39 | 40 | Furthermore the WGS 84 [WGS84] datum is a relatively coarse approximation of 41 | the geoid; with the height varying by up to 5m (but generally between 2 and 3 42 | meters) higher or lower relative to a surface parallel to Earth's mean sea 43 | level. 44 | -------------------------------------------------------------------------------- /js/README.txt: -------------------------------------------------------------------------------- 1 | These are the example sources for the middle and back part of the draft 2 | rfc to ease consistent formatting and syntax checking. Edits should be 3 | performed on these files and then copied into the ../middle.mkd and 4 | ../back.mkd respectively to not loose revisions. 5 | The extension has been changed from .js to .geojson as a) these are GeoJSON samples 6 | and b) to test the new github feature automatically rendering a nice display in the users browser 7 | for files ending in .geojson. 8 | -------------------------------------------------------------------------------- /js/example_01.geojson: -------------------------------------------------------------------------------- 1 | { 2 | "type": "FeatureCollection", 3 | "features": [{ 4 | "type": "Feature", 5 | "geometry": { 6 | "type": "Point", 7 | "coordinates": [102.0, 0.5] 8 | }, 9 | "properties": { 10 | "prop0": "value0" 11 | } 12 | }, { 13 | "type": "Feature", 14 | "geometry": { 15 | "type": "LineString", 16 | "coordinates": [ 17 | [102.0, 0.0], 18 | [103.0, 1.0], 19 | [104.0, 0.0], 20 | [105.0, 1.0] 21 | ] 22 | }, 23 | "properties": { 24 | "prop0": "value0", 25 | "prop1": 0.0 26 | } 27 | }, { 28 | "type": "Feature", 29 | "geometry": { 30 | "type": "Polygon", 31 | "coordinates": [ 32 | [ 33 | [100.0, 0.0], 34 | [101.0, 0.0], 35 | [101.0, 1.0], 36 | [100.0, 1.0], 37 | [100.0, 0.0] 38 | ] 39 | ] 40 | }, 41 | "properties": { 42 | "prop0": "value0", 43 | "prop1": { 44 | "this": "that" 45 | } 46 | } 47 | }] 48 | } -------------------------------------------------------------------------------- /js/example_02_a.geojson: -------------------------------------------------------------------------------- 1 | { 2 | "type": "Feature", 3 | "bbox": [-180.0, -90.0, 180.0, 90.0], 4 | "geometry": { 5 | "type": "Polygon", 6 | "coordinates": [ 7 | [ 8 | [-180.0, 10.0], 9 | [20.0, 90.0], 10 | [180.0, -5.0], 11 | [-30.0, -90.0] 12 | ] 13 | ] 14 | } 15 | } 16 | -------------------------------------------------------------------------------- /js/example_02_b.geojson: -------------------------------------------------------------------------------- 1 | { 2 | "type": "FeatureCollection", 3 | "bbox": [100.0, 0.0, 105.0, 1.0], 4 | "features": [ 5 | ] 6 | } 7 | -------------------------------------------------------------------------------- /js/example_02_c.geojson: -------------------------------------------------------------------------------- 1 | { 2 | "type": "Feature", 3 | "bbox": [170, 10, -170, 11], 4 | "geometry": { 5 | "type": "LineString", 6 | "coordinates": [ 7 | [-170, 10], 8 | [170, 11] 9 | ] 10 | } 11 | } 12 | -------------------------------------------------------------------------------- /js/example_appendix_01.geojson: -------------------------------------------------------------------------------- 1 | { 2 | "type": "Point", 3 | "coordinates": [100.0, 0.0] 4 | } -------------------------------------------------------------------------------- /js/example_appendix_02.geojson: -------------------------------------------------------------------------------- 1 | { 2 | "type": "LineString", 3 | "coordinates": [ 4 | [100.0, 0.0], 5 | [101.0, 1.0] 6 | ] 7 | } -------------------------------------------------------------------------------- /js/example_appendix_03_a.geojson: -------------------------------------------------------------------------------- 1 | { 2 | "type": "Polygon", 3 | "coordinates": [ 4 | [ 5 | [100.0, 0.0], 6 | [101.0, 0.0], 7 | [101.0, 1.0], 8 | [100.0, 1.0], 9 | [100.0, 0.0] 10 | ] 11 | ] 12 | } -------------------------------------------------------------------------------- /js/example_appendix_03_b.geojson: -------------------------------------------------------------------------------- 1 | { 2 | "type": "Polygon", 3 | "coordinates": [ 4 | [ 5 | [100.0, 0.0], 6 | [101.0, 0.0], 7 | [101.0, 1.0], 8 | [100.0, 1.0], 9 | [100.0, 0.0] 10 | ], 11 | [ 12 | [100.8, 0.8], 13 | [100.8, 0.2], 14 | [100.2, 0.2], 15 | [100.2, 0.8], 16 | [100.8, 0.8] 17 | ] 18 | ] 19 | } 20 | -------------------------------------------------------------------------------- /js/example_appendix_03_c.geojson: -------------------------------------------------------------------------------- 1 | { 2 | "type": "Polygon", 3 | "coordinates": [ 4 | [ 5 | [-170.0, 10.0], 6 | [170.0, 10.0], 7 | [170.0, -10.0], 8 | [-170.0, -10.0], 9 | [-170.0, 10.0] 10 | ], 11 | [ 12 | [175.0, 5.0], 13 | [-175.0, 5.0], 14 | [-175.0, -5.0], 15 | [175.0, -5.0], 16 | [175.0, 5.0] 17 | ] 18 | ] 19 | } 20 | -------------------------------------------------------------------------------- /js/example_appendix_04.geojson: -------------------------------------------------------------------------------- 1 | { 2 | "type": "MultiPoint", 3 | "coordinates": [ 4 | [100.0, 0.0], 5 | [101.0, 1.0] 6 | ] 7 | } -------------------------------------------------------------------------------- /js/example_appendix_05.geojson: -------------------------------------------------------------------------------- 1 | { 2 | "type": "MultiLineString", 3 | "coordinates": [ 4 | [ 5 | [100.0, 0.0], 6 | [101.0, 1.0] 7 | ], 8 | [ 9 | [102.0, 2.0], 10 | [103.0, 3.0] 11 | ] 12 | ] 13 | } -------------------------------------------------------------------------------- /js/example_appendix_06.geojson: -------------------------------------------------------------------------------- 1 | { 2 | "type": "MultiPolygon", 3 | "coordinates": [ 4 | [ 5 | [ 6 | [102.0, 2.0], 7 | [103.0, 2.0], 8 | [103.0, 3.0], 9 | [102.0, 3.0], 10 | [102.0, 2.0] 11 | ] 12 | ], 13 | [ 14 | [ 15 | [100.0, 0.0], 16 | [101.0, 0.0], 17 | [101.0, 1.0], 18 | [100.0, 1.0], 19 | [100.0, 0.0] 20 | ], 21 | [ 22 | [100.2, 0.2], 23 | [100.8, 0.2], 24 | [100.8, 0.8], 25 | [100.2, 0.8], 26 | [100.2, 0.2] 27 | ] 28 | ] 29 | ] 30 | } -------------------------------------------------------------------------------- /js/example_appendix_07.geojson: -------------------------------------------------------------------------------- 1 | { 2 | "type": "GeometryCollection", 3 | "geometries": [{ 4 | "type": "Point", 5 | "coordinates": [100.0, 0.0] 6 | }, { 7 | "type": "LineString", 8 | "coordinates": [ 9 | [101.0, 0.0], 10 | [102.0, 1.0] 11 | ] 12 | }] 13 | } -------------------------------------------------------------------------------- /media-type/registration.md: -------------------------------------------------------------------------------- 1 | application/vnd.geo+json registration 2 | ------------------------------------- 3 | 4 | Based on http://www.iana.org/assignments/media-types/application/vnd.hal+json. 5 | 6 | ##Name 7 | 8 | Sean Gillies 9 | 10 | ##Email 11 | 12 | sean.gillies@gmail.com 13 | 14 | ##MIME media type name 15 | 16 | Application 17 | 18 | ##MIME subtype name 19 | 20 | Vendor Tree - vnd.geo+json 21 | 22 | ##Required parameters 23 | 24 | N/A 25 | 26 | ## Optional parameters 27 | 28 | N/A 29 | 30 | ## Encoding considerations 31 | 32 | binary 33 | 34 | ## Security considerations 35 | 36 | vnd.geo+json shares security issues common to all JSON content types. 37 | See RFC7159 Section #12 (http://tools.ietf.org/html/rfc7159#section-12) 38 | for additional information. vnd.geo+json does not provide executable 39 | content. 40 | 41 | As with other geographic data formats, e.g., 42 | application/vnd.google-earth.kml+xml, providing details about the locations of 43 | sensitive persons, animals, habitats, and facilities can expose them to 44 | unauthorized tracking or injury. vnd.geo+json does not provide privacy or 45 | integrity services; if sensitive data requires privacy or integrity protection 46 | those must be provided by the transport, for example TLS or HTTPS. 47 | 48 | ##Interoperability considerations 49 | 50 | There is a difference of opinion among geographic data formats 51 | over whether latitude or longitude come first in a pair of 52 | numbers. Longitude comes first in vnd.geo+json coordinates as it 53 | does in application/vnd.google-earth.kml+xml. 54 | 55 | ## Published specification 56 | 57 | http://geojson.org/ 58 | 59 | ##Applications which use this media 60 | 61 | Various. See https://en.wikipedia.org/wiki/GeoJSON#Supported_software 62 | for a list of software. 63 | 64 | ##Additional information 65 | 66 | 1. Magic number(s) : N/A 67 | 2. File extension(s) : .json, .geojson 68 | 3. Macintosh file type code : TEXT 69 | 4. Object Identifiers: N/A 70 | 71 | 72 | ##Person to contact for further information 73 | 74 | 1. Name : Sean Gillies 75 | 2. Email : sean.gillies@gmail.com 76 | 77 | ##Intended usage : Common 78 | 79 | GeoJSON is a geospatial data interchange format based on JavaScript 80 | Object Notation (JSON). It defines several types of JSON objects and 81 | the manner in which they are combined to represent data about 82 | geographic features, their properties, and their spatial extents. 83 | 84 | -------------------------------------------------------------------------------- /middle.mkd: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | GeoJSON is a format for encoding a variety of geographic data structures 4 | using JavaScript Object Notation (JSON) [RFC7159]. A GeoJSON object may 5 | represent a region of space (a Geometry), a spatially-bounded entity (a 6 | Feature), or a list of features (a Feature Collection). GeoJSON supports 7 | the following geometry types: Point, LineString, Polygon, MultiPoint, 8 | MultiLineString, MultiPolygon, and GeometryCollection. Features in 9 | GeoJSON contain a geometry object and additional properties, and 10 | a Feature Collection contains a list of features. 11 | 12 | The format is concerned with geographic data in the broadest sense; any 13 | thing with qualities that are bounded in geographical space might be 14 | a feature whether it is a physical structure or not. The concepts in 15 | GeoJSON are not new; they are derived from pre-existing open geographic 16 | information system standards and have been streamlined to better suit 17 | web application development using JSON. 18 | 19 | GeoJSON comprises the seven concrete geometry types defined in the 20 | OpenGIS Simple Features Implementation Specification for SQL [SFSQL]: 21 | 0-dimensional Point and MultiPoint; 1-dimensional curve LineString and 22 | MultiLineString; 2-dimensional surface Polygon and MultiPolygon; and the 23 | heterogeneous GeometryCollection. GeoJSON representations of instances 24 | of these geometry types are analogous to the well-known binary (WKB) and 25 | text (WKT) representations described in that same specification. 26 | 27 | GeoJSON also comprises the types Feature and FeatureCollection. Feature 28 | objects in GeoJSON contain a geometry object with one of the above 29 | geometry types and additional members. A FeatureCollection object 30 | contains an array of feature objects. This structure is analogous to 31 | that of the Web Feature Service (WFS) response to GetFeatures requests 32 | specified in [WFSv1] or to a Keyhole Markup Language (KML) Folder of Placemarks 33 | [KMLv2.2]. Some implementations of the WFS specification also provide GeoJSON 34 | formatted responses to GetFeature requests, but there is no particular service 35 | model or feature type ontology implied in the GeoJSON format specification. 36 | 37 | Since its initial publication in 2008 [GJ2008], the GeoJSON format 38 | specification has steadily grown in popularity. It is widely used in 39 | JavaScript web mapping libraries, JSON-based document databases, and web 40 | APIs. 41 | 42 | ## Requirements Language 43 | 44 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 46 | "OPTIONAL" in this document are to be interpreted as described in 47 | [RFC2119]. 48 | 49 | ## Conventions Used in This Document 50 | 51 | The ordering of the members of any JSON object defined in this document 52 | MUST be considered irrelevant, as specified by [RFC7159]. 53 | 54 | Some examples use the combination of a JavaScript single line comment 55 | (//) followed by an ellipsis (...) as placeholder notation for content 56 | deemed irrelevant by the authors. These placeholders must of course be 57 | deleted or otherwise replaced, before attempting to validate the 58 | corresponding JSON code example. 59 | 60 | Whitespace is used in the examples inside this document to help 61 | illustrate the data structures, but is not required. Unquoted whitespace 62 | is not significant in JSON. 63 | 64 | ## Specification of GeoJSON 65 | 66 | This document supersedes the original GeoJSON format specification 67 | [GJ2008]. 68 | 69 | ## Definitions 70 | 71 | * JavaScript Object Notation (JSON), and the terms object, member, 72 | name, value, array, number, true, false, and null are to be 73 | interpreted as defined in [RFC7159]. 74 | 75 | * Inside this document the term "geometry type" refers to the seven 76 | case-sensitive strings: "Point", "MultiPoint", "LineString", 77 | "MultiLineString", "Polygon", "MultiPolygon", and 78 | "GeometryCollection". 79 | 80 | * As another shorthand notation, the term "GeoJSON types" refers to the 81 | nine case-sensitive strings "Feature", "FeatureCollection" and the 82 | geometry types listed above. 83 | 84 | * The word "Collection" in "FeatureCollection" and "GeometryCollection" 85 | does not have any significance for the semantics of array members. 86 | The "features" and "geometries" members, respectively, of these 87 | objects are standard ordered JSON arrays, not unordered sets. 88 | 89 | ## Example 90 | 91 | A GeoJSON feature collection: 92 | 93 | { 94 | "type": "FeatureCollection", 95 | "features": [{ 96 | "type": "Feature", 97 | "geometry": { 98 | "type": "Point", 99 | "coordinates": [102.0, 0.5] 100 | }, 101 | "properties": { 102 | "prop0": "value0" 103 | } 104 | }, { 105 | "type": "Feature", 106 | "geometry": { 107 | "type": "LineString", 108 | "coordinates": [ 109 | [102.0, 0.0], 110 | [103.0, 1.0], 111 | [104.0, 0.0], 112 | [105.0, 1.0] 113 | ] 114 | }, 115 | "properties": { 116 | "prop0": "value0", 117 | "prop1": 0.0 118 | } 119 | }, { 120 | "type": "Feature", 121 | "geometry": { 122 | "type": "Polygon", 123 | "coordinates": [ 124 | [ 125 | [100.0, 0.0], 126 | [101.0, 0.0], 127 | [101.0, 1.0], 128 | [100.0, 1.0], 129 | [100.0, 0.0] 130 | ] 131 | ] 132 | }, 133 | "properties": { 134 | "prop0": "value0", 135 | "prop1": { 136 | "this": "that" 137 | } 138 | } 139 | }] 140 | } 141 | 142 | # GeoJSON Text 143 | 144 | A GeoJSON text is a JSON text and consists of a single GeoJSON object. 145 | 146 | # GeoJSON Object 147 | 148 | A GeoJSON object represents a geometry, feature, or collection of 149 | features. 150 | 151 | * A GeoJSON object is a JSON object. 152 | 153 | * A GeoJSON object has a member with the name "type". The value 154 | of the member MUST be one of the GeoJSON types. 155 | 156 | * A GeoJSON object MAY have a "bbox" member, the value of which MUST be 157 | a bounding box array (see [](#bounding-box)). 158 | 159 | * A GeoJSON object MAY have other members (see [](#extending-geojson)). 160 | 161 | ## Geometry Object 162 | 163 | A Geometry object represents points, curves, and surfaces in coordinate 164 | space. Every geometry object is a GeoJSON object no matter where it 165 | occurs in a GeoJSON text. 166 | 167 | * The value of a geometry object's "type" member MUST be one of the 168 | seven geometry types (see [](#definitions)). 169 | 170 | * A GeoJSON geometry object of any type other than "GeometryCollection" 171 | has a member with the name "coordinates". The value of the 172 | coordinates member is an array. The structure of the elements 173 | in this array is determined by the type of geometry. GeoJSON 174 | processors MAY interpret geometry objects with empty coordinates 175 | arrays as null objects. 176 | 177 | ### Position 178 | 179 | A position is the fundamental geometry construct. The "coordinates" 180 | member of a geometry object is composed of either: 181 | 182 | * one position in the case of a Point geometry, 183 | 184 | * an array of positions in the case of a LineString or MultiPoint geometry, 185 | 186 | * an array of LineString or linear ring (see [](#polygon)) coordinates in the 187 | case of a Polygon or MultiLineString geometry, 188 | 189 | * or an array of Polygon coordinates in the case of a MultiPolygon geometry. 190 | 191 | A position is an array of numbers. There MUST be two or more elements. 192 | The first two elements are longitude and latitude, or easting and 193 | northing, precisely in that order and using decimal numbers. Altitude 194 | or elevation MAY be included as an optional third element. 195 | 196 | Implementations SHOULD NOT extend positions beyond 3 elements because 197 | the semantics of extra elements are unspecified and ambiguous. 198 | Historically, some implementations have used a 4th element to carry 199 | a linear referencing measure (sometimes denoted as "M") or a numerical 200 | timestamp, but in most situations a parser will not be able to properly 201 | interpret these values. The interpretation and meaning of additional 202 | elements is beyond the scope of this specification and additional 203 | elements MAY be ignored by parsers. 204 | 205 | A line between two positions is a straight Cartesian line, the shortest 206 | line between those two points in the Coordinate Reference System (see 207 | [](#coordinate-reference-system)). 208 | 209 | In other words, every point on a line that does not cross the 210 | antimeridian between a point (lon0, lat0) and (lon1, lat1) can be 211 | calculated as 212 | 213 | F(lon, lat) = (lon0 + (lon1 - lon0) * t, lat0 + (lat1 - lat0) * t) 214 | 215 | with t a real number greater or equal to 0 and smaller or equal to 1. 216 | Note that this line may markedly differ from the geodesic path along the 217 | curved surface of the reference ellipsoid. 218 | 219 | The same applies to the optional height element with the proviso that 220 | the direction of the height is as specified in the Coordinate Reference 221 | System. 222 | 223 | Note that, again, this does not mean that a surface with equal height 224 | follows, for example, the curvature of a body of water. Nor is a surface 225 | of equal height perpendicular to a plumb line. 226 | 227 | Examples of positions and geometries are provided in "Appendix A. 228 | Geometry Examples". 229 | 230 | ### Point 231 | 232 | For type "Point", the "coordinates" member is a single position. 233 | 234 | ### MultiPoint 235 | 236 | For type "MultiPoint", the "coordinates" member is an array of 237 | positions. 238 | 239 | ### LineString 240 | 241 | For type "LineString", the "coordinates" member is an array of two 242 | or more positions. 243 | 244 | ### MultiLineString 245 | 246 | For type "MultiLineString", the "coordinates" member is an array of 247 | LineString coordinate arrays. 248 | 249 | ### Polygon 250 | 251 | To specify a constraint specific to polygons, it is useful to introduce 252 | the concept of a linear ring: 253 | 254 | * A linear ring is a closed LineString with 4 or more positions. 255 | 256 | * The first and last positions are equivalent, they MUST contain identical 257 | values; their representation SHOULD also be identical. 258 | 259 | * A linear ring is the boundary of a surface or the boundary of a hole in 260 | a surface. 261 | 262 | * A linear ring MUST follow the right-hand rule with respect to the area 263 | it bounds, i.e., exterior rings are counter-clockwise, holes are 264 | clockwise. 265 | 266 | Note: the [GJ2008] specification did not discuss linear ring winding order. 267 | For backwards compatibility, parsers SHOULD NOT reject polygons that do not 268 | follow the right-hand rule. 269 | 270 | Though a linear ring is not explicitly represented as a GeoJSON geometry 271 | type, it leads to a canonical formulation of the Polygon geometry type 272 | definition as follows: 273 | 274 | * For type "Polygon", the "coordinates" member MUST be an array of 275 | linear ring coordinate arrays. 276 | 277 | * For Polygons with more than one of these rings, the first MUST be the 278 | exterior ring and any others MUST be interior rings. The exterior ring 279 | bounds the surface, and the interior rings (if present) bound holes 280 | within the surface. 281 | 282 | ### MultiPolygon 283 | 284 | For type "MultiPolygon", the "coordinates" member is an array of 285 | Polygon coordinate arrays. 286 | 287 | ### Geometry Collection 288 | 289 | A GeoJSON object with type "GeometryCollection" is a geometry object. 290 | A geometry collection has a member with the name "geometries". The 291 | value of "geometries" is an array. Each element of this array is a GeoJSON 292 | geometry object. It is possible for this array to be empty. 293 | 294 | Unlike the other geometry types described above, 295 | a geometry collection can be a heterogeneous composition of smaller 296 | geometry objects. For example, a geometry object in the shape of 297 | a lowercase roman "i" can be composed of one point and one line string. 298 | 299 | Geometry collections have a different syntax from single type geometry 300 | objects (Point, LineString, and Polygon) and homogeneously typed 301 | multipart geometry objects (MultiPoint, MultiLineString, and 302 | MultiPolygon) but have no different semantics. Although a geometry 303 | collection object has no "coordinates" member, it does have coordinates: 304 | the coordinates of all its parts belong to the collection. The 305 | "geometries" member of a geometry collection describes the parts of this 306 | composition. Implementations SHOULD NOT apply any additional semantics 307 | to the "geometries" array. 308 | 309 | To maximize interoperability implementations SHOULD avoid nested 310 | geometry collections. Furthermore, geometry collections composed of 311 | a single part or a number of parts of a single type SHOULD be avoided when 312 | that single part or a single object of multi-part type (MultiPoint, 313 | MultiLineString, or MultiPolygon) could be used instead. 314 | 315 | ### Antimeridian Cutting 316 | 317 | In representing features that cross the antimeridian, interoperability 318 | is improved by modifying their geometry. Any geometry that crosses the 319 | antimeridian SHOULD be represented by cutting it in two such that 320 | neither part's representation crosses the antimeridian. 321 | 322 | For example, a line extending from 45 degrees N, 170 degrees E across 323 | the antimeridian to 45 degrees N, 170 degrees W should be cut in two and 324 | represented as a MultiLineString. 325 | 326 | { 327 | "type": "MultiLineString", 328 | "coordinates": [ 329 | [ 330 | [170.0, 45.0], [180.0, 45.0] 331 | ], [ 332 | [-180.0, 45.0], [-170.0, 45.0] 333 | ] 334 | ] 335 | } 336 | 337 | A rectangle extending from 40 degrees N, 170 degrees E across the 338 | antimeridian to 50 degrees N, 170 degrees W should be cut in two and 339 | represented as a MultiPolygon. 340 | 341 | { 342 | "type": "MultiPolygon", 343 | "coordinates": [ 344 | [ 345 | [ 346 | [180.0, 40.0], [180.0, 50.0], [170.0, 50.0], 347 | [170.0, 40.0], [180.0, 40.0] 348 | ] 349 | ], 350 | [ 351 | [ 352 | [-170.0, 40.0], [-170.0, 50.0], [-180.0, 50.0], 353 | [-180.0, 40.0], [-170.0, 40.0] 354 | ] 355 | ] 356 | ] 357 | } 358 | 359 | ### Uncertainty and Precision 360 | 361 | As in [RFC5870] the number of digits of the values in coordinate 362 | positions MUST NOT be interpreted as an indication to the level of 363 | uncertainty. 364 | 365 | ## Feature Object 366 | 367 | A Feature object represents a spatially-bounded thing. Every feature 368 | object is a GeoJSON object no matter where it occurs in a GeoJSON text. 369 | 370 | * A feature object has a "type" member with the value "Feature". 371 | 372 | * A feature object has a member with the name "geometry". The 373 | value of the geometry member SHALL be either a geometry object as 374 | defined above or, in the case that the feature is unlocated, 375 | a JSON null value. 376 | 377 | * A feature object has a member with the name "properties". The 378 | value of the properties member is an object (any JSON object or a 379 | JSON null value). 380 | 381 | * If a feature has a commonly used identifier, that identifier SHOULD be 382 | included as a member of the feature object with the name "id", and the 383 | value of this member is either a JSON string or number. 384 | 385 | ## Feature Collection Object 386 | 387 | A GeoJSON object with the type "FeatureCollection" is a feature 388 | collection object. A feature collection object has a member with 389 | the name "features". The value of "features" is a JSON array. Each 390 | element of the array is a feature object as defined above. It is 391 | possible for this array to be empty. 392 | 393 | # Coordinate Reference System 394 | 395 | The coordinate reference system for all GeoJSON coordinates is 396 | a geographic coordinate reference system, using the WGS 84 [WGS84] 397 | datum, and with longitude and latitude units of decimal degrees. This 398 | is equivalent to the coordinate reference system identified by the OGC 399 | URN urn:ogc:def:crs:OGC::CRS84. An OPTIONAL third position element SHALL 400 | be the height in meters above or below the WGS 84 reference ellipsoid. 401 | In the absence of elevation values, applications sensitive to height or 402 | depth SHOULD interpret positions as being at local ground or sea level. 403 | 404 | Note: the use of alternative coordinate reference systems was specified 405 | in [GJ2008], but has been removed from this version of the 406 | specification because the use of different coordinate reference systems 407 | — especially in the manner specified in [GJ2008] — has proven to have 408 | interoperability issues. In general, GeoJSON processing software is not 409 | expected to have access to coordinate reference systems databases or 410 | to have network access to coordinate reference system transformation 411 | parameters. However, where all involved parties have a prior 412 | arrangement, alternative coordinate reference systems can be used 413 | without risk of data being misinterpreted. 414 | 415 | # Bounding Box 416 | 417 | A GeoJSON object MAY have a member named "bbox" to include information 418 | on the coordinate range for its geometries, features, or feature 419 | collections. The value of the bbox member MUST be an array of length 420 | 2*n where n is the number of dimensions represented in the contained 421 | geometries, with all axes of the most south-westerly point followed by 422 | all axes of the more north-easterly point. The axes order of a bbox 423 | follows the axes order of geometries. 424 | 425 | The "bbox" values define shapes with edges that follow lines of constant 426 | longitude, latitude, and elevation. 427 | 428 | Example of a 2D bbox member on a feature: 429 | 430 | { 431 | "type": "Feature", 432 | "bbox": [-10.0, -10.0, 10.0, 10.0], 433 | "geometry": { 434 | "type": "Polygon", 435 | "coordinates": [ 436 | [ 437 | [-10.0, -10.0], 438 | [10.0, -10.0], 439 | [10.0, 10.0], 440 | [-10.0, -10.0] 441 | ] 442 | ] 443 | } 444 | //... 445 | } 446 | 447 | Example of a 2D bbox member on a feature collection: 448 | 449 | { 450 | "type": "FeatureCollection", 451 | "bbox": [100.0, 0.0, 105.0, 1.0], 452 | "features": [ 453 | //... 454 | ] 455 | } 456 | 457 | Example of a 3D bbox member with a depth of 100 meters: 458 | 459 | { 460 | "type": "FeatureCollection", 461 | "bbox": [100.0, 0.0, -100.0, 105.0, 1.0, 0.0], 462 | "features": [ 463 | //... 464 | ] 465 | } 466 | 467 | ## The Connecting Lines 468 | 469 | The 4 lines of the bounding box are defined fully within the coordinate 470 | reference system, i.e., for a box bounded by the values "west", "south", 471 | "east", and "north" every point on the northernmost line can be 472 | expressed as 473 | 474 | (lon, lat) = (west + (east - west) * t, north) 475 | 476 | with 0 <= t <= 1. 477 | 478 | ## The Antimeridian 479 | 480 | Consider a set of point features within the Fiji archipelago, straddling 481 | the antimeridian between 16 degrees S and 20 degrees S. The southwest 482 | corner of the box containing these features is at 20 degrees S and 177 483 | degrees E, the northwest corner is at 16 degrees S and 178 degrees W. 484 | The antimeridian-spanning GeoJSON bounding box for this feature 485 | collection is 486 | 487 | "bbox": [177.0, -20.0, -178.0, -16.0] 488 | 489 | and covers 5 degrees of longitude. 490 | 491 | The complementary bounding box for the same latitude band, not crossing 492 | the antimeridian, is 493 | 494 | "bbox": [-178.0, -20.0, 177.0, -16.0] 495 | 496 | and covers 355 degrees of longitude. 497 | 498 | The latitude of the northeast corner is always greater than the latitude 499 | of the southwest corner, but bounding boxes that cross the antimeridian 500 | have a northeast corner longitude that is less than the longitude of the 501 | southwest corner. 502 | 503 | ## The Poles 504 | 505 | A bounding box that contains the North Pole extends from a southwest 506 | corner of "minlat" degrees N, 180 degrees W to a northeast corner of 90 507 | degrees N, 180 degrees E. Viewed on a globe, this bounding box 508 | approximates a spherical cap bounded by the "minlat" circle of latitude. 509 | 510 | "bbox": [-180.0, minlat, 180.0, 90.0] 511 | 512 | A bounding box that contains the South Pole extends from a southwest 513 | corner of 90 degrees S, 180 degrees W to a northeast corner of 514 | "maxlat" degrees S, 180 degrees E. 515 | 516 | "bbox": [-180.0, -90.0, 180.0, maxlat] 517 | 518 | A bounding box that just touches the North Pole and forms a slice of an 519 | approximate spherical cap when viewed on a globe extends from 520 | a southwest corner of "minlat" degrees N and "westlon" degrees E to 521 | a northeast corner of 90 degrees N and "eastlon" degrees E. 522 | 523 | "bbox": [westlon, minlat, eastlon, 90.0] 524 | 525 | Similarly, a bounding box that just touches the South Pole and forms 526 | a slice of an approximate spherical cap when viewed on a globe has the 527 | following representation in GeoJSON. 528 | 529 | "bbox": [westlon, -90.0, eastlon, maxlat] 530 | 531 | Implementers MUST NOT use latitude values greater than 90 or less than 532 | -90 to imply an extent that is not a spherical cap. 533 | 534 | # Extending GeoJSON 535 | 536 | ## Foreign Members 537 | 538 | Members not described in this specification ("foreign members") MAY be 539 | used in a GeoJSON document. Note that support for foreign members can 540 | vary across implementations and no normative processing model for 541 | foreign members is defined. Accordingly, implementations that rely too 542 | heavily on the use of foreign members might experience reduced 543 | interoperability with other implementations. 544 | 545 | For example, in the (abridged) feature object shown below 546 | 547 | { 548 | "type": "Feature", 549 | "id": "f1", 550 | "geometry": {...}, 551 | "properties": {...}, 552 | "title": "Example Feature" 553 | } 554 | 555 | the name/value pair of "title": "Example Feature" is a foreign member. 556 | When the value of a foreign member is an object, all the descendant 557 | members of that object are themselves foreign members. 558 | 559 | GeoJSON semantics do not apply to foreign members and their descendants, 560 | regardless of their names and values. For example, in the (abridged) 561 | feature object below 562 | 563 | { 564 | "type": "Feature", 565 | "id": "f2", 566 | "geometry": {...}, 567 | "properties": {...}, 568 | "centerline": { 569 | "type": "LineString", 570 | "coordinates": [ 571 | [-170, 10], 572 | [170, 11] 573 | ] 574 | } 575 | } 576 | 577 | the "centerline" member is not a GeoJSON geometry object. 578 | 579 | # GeoJSON Types are not Extensible 580 | 581 | Implementations MUST NOT extend the fixed set of GeoJSON types: 582 | FeatureCollection, Feature, Point, LineString, MultiPoint, Polygon, 583 | MultiLineString, MultiPolygon, and GeometryCollection. 584 | 585 | ## Semantics of GeoJSON Members and Types are not Changeable 586 | 587 | Implementations MUST NOT change the semantics of GeoJSON members and 588 | types. 589 | 590 | The GeoJSON "coordinates" and "geometries" members define Geometry 591 | objects. FeatureCollection and Feature objects, respectively, MUST NOT 592 | contain a "coordinates" or "geometries" member. 593 | 594 | The GeoJSON "geometry" and "properties" members define a Feature object. 595 | FeatureCollection and Geometry objects, respectively, MUST NOT contain 596 | a "geometry" or "properties" member. 597 | 598 | The GeoJSON "features" member defines a FeatureCollection object. 599 | Feature and Geometry objects, respectively, MUST NOT contain 600 | a "features" member. 601 | 602 | # Versioning 603 | 604 | The GeoJSON format can be extended as defined here, but no explicit 605 | versioning scheme is defined. A specification that alters the 606 | semantics of GeoJSON members or otherwise modifies the format does not 607 | create a new version of this format; instead, it defines an entirely 608 | new format that MUST NOT be identified as GeoJSON. 609 | 610 | # Mapping 'geo' URIs 611 | 612 | 'geo' URIs [RFC5870] identify geographic locations and precise (not uncertain) 613 | locations can be mapped to GeoJSON geometry objects. 614 | 615 | For this section, as in [RFC5870], "lat", "lon", "alt", and "unc" are 616 | placeholders for 'geo' URI latitude, longitude, altitude, and 617 | uncertainty values, respectively. 618 | 619 | A 'geo' URI with two coordinates and an uncertainty ('u') parameter that 620 | is absent or zero, and a GeoJSON Point geometry may be mapped to each other. 621 | A GeoJSON point is always converted to a 'geo' URI that has no uncertainty 622 | parameter. 623 | 624 | 'geo' URI: 625 | 626 | geo:lat,lon 627 | 628 | GeoJSON: 629 | 630 | {"type": "Point", "coordinates": [lon, lat]} 631 | 632 | The mapping between 'geo' URIs and GeoJSON points that specify elevation is 633 | shown below. 634 | 635 | 'geo' URI: 636 | 637 | geo:lat,lon,alt 638 | 639 | GeoJSON: 640 | 641 | {"type": "Point", "coordinates": [lon, lat, alt]} 642 | 643 | GeoJSON has no concept of uncertainty; imprecise or uncertain 'geo' URIs thus 644 | cannot be mapped to GeoJSON geometries. 645 | -------------------------------------------------------------------------------- /template.xml: -------------------------------------------------------------------------------- 1 | 2 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | ]> 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | The GeoJSON Format 28 | 29 | 31 | Hobu Inc. 32 |
33 | howard@hobu.co 34 |
35 | 36 | 38 | Cadcorp 39 |
40 | martin.daly@cadcorp.com 41 |
42 | 43 | 45 |
46 | adoyle@intl-interfaces.com 47 |
48 | 49 | 51 | Mapbox 52 |
53 | sean.gillies@gmail.com 54 | http://sgillies.net 55 |
56 | 57 | 59 |
60 | 61 | Rheinaustr. 62 62 | 63 | Bonn 64 | 53225 65 | DE 66 | 67 | stefan@hagen.link 68 | http://stefan-hagen.website/ 69 |
70 | 71 | 73 | Planet Labs 74 |
75 | tim.schaub@gmail.com 76 |
77 | 78 | 79 | 80 | Applications and Real-Time Area (art) 81 | GeoJSON 82 | RFC 83 | Request for Comments 84 | I-D 85 | Internet-Draft 86 | JSON 87 | Geospatial 88 | JavaScript Object Notation 89 | 90 | 91 | GeoJSON is a geospatial data interchange format based on 92 | JavaScript Object Notation (JSON). It defines several types of 93 | JSON objects and the manner in which they are combined to 94 | represent data about geographic features, their 95 | properties, and their spatial extents. GeoJSON uses a geographic 96 | coordinate reference system, World Geodetic System 1984, and units 97 | of decimal degrees. 98 | 99 | 100 | 101 | 102 | 103 | &pandocMiddle; 104 | &pandocConsiderations; 105 |
106 | 107 | The media type for GeoJSON text is application/geo+json and is registered in the 109 | "Media Types" registry described in . 110 | The entry for application/vnd.geo+json in 111 | the same registry should have its status 112 | changed to be Obsolete with a pointer to the media type 113 | application/geo+json and a reference added 114 | to this RFC. 115 | 116 | 117 | application 118 | geo+json 119 | n/a 120 | n/a 121 | binary 122 | See above 123 | See above 124 | [[This document]] 125 | No known applications currently use this media type. This media type is intended for GeoJSON applications currently using the "application/vnd.geo+json" or "application/json" media types, of which there are several categories: web mapping, geospatial databases, geographic data processing APIs, data analysis and storage services, and data dissemination. 126 | 127 | 128 | n/a 129 | .json, .geojson 130 | n/a 131 | n/a 132 | GeoJSON 133 | 134 | public.geojson conforms to public.json 135 | 136 | 137 | 138 | 139 | Sean Gillies (sean.gillies@gmail.com) 140 | 141 | COMMON 142 | none 143 | none 144 | see "Authors' Addresses" section of [[This document]]. 145 | Internet Engineering Task Force 146 | 147 | 148 |
149 | 150 |
151 | The GeoJSON format is the product of discussion on the GeoJSON mailing 152 | list, http://lists.geojson.org/listinfo.cgi/geojson-geojson.org, before 153 | October 2015 and the IETF's GeoJSON WG after October 2015. 154 | 155 | Material in this document was adapted with changes from 156 | http://geojson.org/geojson-spec.html [GJ2008] which is licensed under 157 | http://creativecommons.org/licenses/by/3.0/us/. 158 |
159 | 160 | 161 | 162 | 163 | 164 | &pandocRef2119; 165 | &pandocRef6838; 166 | &pandocRef7159; 167 | &pandocRef7493; 168 | 169 | 170 | Department of Defense World Geodetic System 1984, Third Edition 171 | 172 | National Imagery and Mapping Agency 173 | 174 | 175 | 176 | 177 | 178 | 179 | &pandocRef6772; 180 | &pandocRef7464; 181 | 182 | 183 | The GeoJSON Format Specification 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | OpenGIS Simple Features Specification For SQL Revision 1.1 196 | 197 | 198 | OpenGIS Consortium, Inc. 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | Web Feature Service Implementation Specification 208 | 209 | 210 | OpenGIS Consortium, Inc. 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | OGC KML 220 | 221 | 222 | 223 | 224 | 225 | 226 | 227 | k-anonymity: a model for protecting privacy 228 | 229 | 230 | 231 | 232 | 233 | 234 | &pandocBack; 235 | 236 | 237 | -------------------------------------------------------------------------------- /transform.xsl: -------------------------------------------------------------------------------- 1 | 2 | 3 | 7 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | This document was prepared using Pandoc2rfc 19 | https://github.com/miekg/pandoc2rfc 20 | 21 | 22 | 23 | 24 | 25 | 26 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 40 | 41 | 42 | 44 | 45 | 46 | 47 | 48 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 58 |
59 | 60 | 62 | 63 | 64 | 65 | 66 | 67 |
68 | 69 | 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 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 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 | 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 | 340 | 341 | 344 | 345 | 346 | 347 | 348 | 351 | 352 | 353 | 354 | 355 | 356 | 357 | 358 | 359 | 362 | 363 | 364 | 365 | 366 | 367 | 368 | 369 | 370 | 373 | 374 | 375 | 376 | 377 | 378 | 379 | 380 | 383 | 384 |
385 | 386 | 387 | 388 | fig: 389 | 394 | 395 | 396 | 397 | center 398 | 399 | 400 | 401 | 402 | 403 | 404 | 405 | 406 | 407 | 408 | fig: 409 | 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 | tab: 476 | 480 | 481 | 482 | 483 | 484 | tab: 485 | 489 | 490 | 491 | 492 | 493 | 494 | 495 | 496 | 497 | 498 | 499 | 500 | 501 | 502 | 503 | 504 | 505 | 506 | 507 | 509 | 510 | 511 | 512 | 513 | 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 | 626 | 627 | 628 | 629 | 630 | 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 | 694 | 695 | 696 | 697 | 698 | 702 | 703 | 704 | 705 | 706 | 710 | 711 | 712 | 713 | 714 | 715 | 716 | 717 | 718 | 719 | 720 | 721 | --------------------------------------------------------------------------------