(4) It's for Riding Animals!

(5) GeoJSON Fish

• Transformed from Strava [http://www.strava.com/]-originated activity [http://www.strava.com/activities/523719323] GPX [https://github.com/dret/lectures/blob/master/locweb-2017/src/fish.gpx]
• Github [http://github.com/] understands and renders the resulting GeoJSON [https://github.com/dret/lectures/blob/master/locweb-2017/src/fish.geojson]

{
    "type": "Feature",
    "properties": {
        "name": "World Water Day Fish",
        "time": "2016-03-22T11:01:42.000Z"
    },
    "geometry": {
        "type": "LineString",
        "coordinates": [
            [
                8.548238184303045,
                47.40594316273928,
                459.6000061035156
            ],
            [

(6) GeoJSON Goose

• Transformed from Strava [http://www.strava.com/]-originated activity [http://www.strava.com/activities/527214108] GPX [https://github.com/dret/lectures/blob/master/locweb-2017/src/goose.gpx]
• Github [http://github.com/] understands and renders the resulting GeoJSON [https://github.com/dret/lectures/blob/master/locweb-2017/src/goose.geojson]

{
    "type": "Feature",
    "properties": {
        "name": "Easter Goose",
        "time": "2016-03-26T11:03:27.000Z"
    },
    "geometry": {
        "type": "LineString",
        "coordinates": [
            [
                8.551550712436438,
                47.40528577007353,
                401
            ],
            [

(7) Representing Geometries or Features

• GeoJSON has object types for single and multiple geometries and features
  • Geometry [http://tools.ietf.org/html/rfc7946#section-3.1] represents 6 geometry types (see below) and one collection
  • Feature [http://tools.ietf.org/html/rfc7946#section-3.2] represents single or multiple spatially bound things
• GeoJSON's fundamental geometry construct is the position [https://tools.ietf.org/html/rfc7946#section-3.1.1]
  • Point [https://tools.ietf.org/html/rfc7946#section-3.1.2] has one position
  • LineString [https://tools.ietf.org/html/rfc7946#section-3.1.4]/MultiPoint [https://tools.ietf.org/html/rfc7946#section-3.1.3] have an array of positions
  • Polygon [https://tools.ietf.org/html/rfc7946#section-3.1.6]/MultiLineString [https://tools.ietf.org/html/rfc7946#section-3.1.5] have an array of arrays of positions
  • MultiPolygon [https://tools.ietf.org/html/rfc7946#section-3.1.7] has an array of Polygons
• Features have properties and an associated geometry
• Feature and Geometry also come as FeatureCollection [https://tools.ietf.org/html/rfc7946#section-3.3]/GeometryCollection [https://tools.ietf.org/html/rfc7946#section-3.1.8]
• GeoJSON is not meant to represent the full complexity/fidelity of GIS models

(8) Using GeoJSON

• Meant as a simple and lightweight representation
  • Use it in services/APIs where geometries/features need to be represented in a simple way
  • Do not expect full fidelity of possibly complex underlying models
• Not meant as a synchronization format for full-fidelity GIS access/interchange
  • Trying to GISify GeoJSON very likely makes it non-interoperable
• Geo-tools such as Leaflet [http://leafletjs.com/] often support GeoJSON out of the box [http://leafletjs.com/examples/geojson.html]

(10) GeoJSON Problems

• Despite being popular, the GeoJSON specification [http://geojson.org/geojson-spec.html] was not created/managed by any SDO
  • Lingering doubts about the stability/stewardship of the specification
  • Some policies require that only SDO-published specifications can be used
• Usage around CRS [http://geojson.org/geojson-spec.html#coordinate-reference-system-objects] had caused some interoperability problems
  • Default rule (WGS84) plus inheritance meant implementations often did not implement the specification
  • Naming of specific CRS was left open, resulting in namespace fragmentation
• Extensibility and openness were not specified clearly enough
  • Lack of guidance made it too easy for implementers to do the wrong thing
  • Experience showed which areas were the most problematic ones

(11) IETF GeoJSON WG

• The IETF GeoJSON Working Group [https://datatracker.ietf.org/wg/geojson/] started work in October 2015
  • The main item on the charter was to revise and publish GeoJSON as an RFC
  • An additional item is to publish a specification for GeoJSON Text Sequences
  • Additional work items are currently under consideration
• IETF working groups are open to all interested participants
• IETF RFCs are often accepted as standards that are stable and safe to use

(12) IETF GeoJSON WG Work

• Adopted a draft starting from the GeoJSON Specification [http://geojson.org/geojson-spec.html]
  • List of changes available in Appendix B [https://tools.ietf.org/html/rfc7946#appendix-B]
• Started draft about GeoJSON Text Sequences [http://datatracker.ietf.org/drafts/draft-ietf-geojson-text-sequence]
  • Applies JSON Text Sequences (RFC 7464) [http://tools.ietf.org/html/rfc7464] to GeoJSON
  • How to represent sequences of GeoJSON objects in one streamable representation
  • Useful in scenarios where sequences/streams of GeoJSON objects are exchanged
• Two more work items currently considered
  • Providing guidance and a registry for GeoJSON extensions
  • Adding time information to GeoJSON as an initial extension

(13) GeoJSON Changes

• Discouraging the use of non-WGS84 CRS
• Clarifying the extensibility of position arrays
• Clarifying lines as being Cartesian (instead of being geodesic)
• Clarifying the definition of a bounding box
• Making it clear that extensions cannot change the base semantics
• Defining a new media type application/geo+json

(15) Being Webby

• Data exchange and access is getting replaced by APIs
  • Simple data access is a very simple version of API
  • APIs support access and workflows beyond simple data access
• APIs are used in two major ways
  • Public/Partner APIs expose services to outside collaborators
  • Private APIs re-envision system architecture in an API-based way
• APIs are built around Web technologies and aim for concept reuse
  • The Web establishes a large surface of Web Concepts [http://webconcepts.info/concepts/]
  • Media Types [http://webconcepts.info/concepts/media-type/] are one of the core concepts

(16) Designing Geo APIs

• Identify the resources that your API is exposing
  • For those using geo-related information consider existing standards
  • Part of the DX design exercise is to consider developers
• Many Geo formats have extension capabilities
  • Consider only those that allow you to establish a meaningful core [http://dret.typepad.com/dretblog/2016/04/robust-extensibility.html]
  • Design and document extensions for full API fidelity
  • If possible, register these extensions in the appropriate places
• GeoJSON can play a role in API design around geo-services
  • More sophisticated feature models can be used in the API
  • GeoJSON can establish a foundation for geographic data exchange

(18) Thanks! Q&A

• Me: http://dret.net/netdret/ [http://dret.net/netdret/]
• Slides online: dret.net/lectures/locweb-2017/ [http://dret.net/lectures/locweb-2017/]
• Slide sources: dret/lectures [http://github.com/dret/lectures/tree/master/locweb-2017] on GitHub [http://github.com/]
• GeoJSON WG: IETF Datatracker Page [https://datatracker.ietf.org/wg/geojson]
  • RFC 7946: The GeoJSON Format [http://tools.ietf.org/html/rfc7946]
  • Internet draft: GeoJSON Text Sequences [http://datatracker.ietf.org/drafts/draft-ietf-geojson-text-sequence]