My favorites ▼ | Sign in
Project Home Downloads Wiki Issues Source
Search
for
ObsJSON  
a GeoJSON based observations/data-centric minimal schema
Updated Nov 1, 2011 by jeremy.c...@gmail.com

developed from discussions with working group http://groups.google.com/group/ioos-kml

see also geojson

json schema

json schema discussion

NDBC implementation(see SOS KML/JSON output)

see also latest 12 hours from platforms as ObsJSON, note the function and smooth brackets wrapping the GeoJSON are utilized to support the dynamic Javascript callback functionality for KML in GE version 5.

see also xenia to json perl script

developed from earlier documentation regarding ObsJSON and ObsKML

Version 2 is the preferred working version at this time.

Simple schema

Below example is more flat/array oriented like netCDF,CSV and could support moving platforms(ships,gliders) as well as stationary ones.

  • elevRel is the 'relative elevation' in meters height(+) or depth(-) from the given GeoJSON z coordinate(s) with zero z coordinate corresponding to mean sea level(MSL).
  • The ordering of effected list arguments is in time increasing order(oldest first, latest last) allowing picking off the latest value be grabbing the last associated set of time/values off the list.
  • Stationary platforms would use GeoJSON 'Point' type and mobile platforms would use 'MultiPoint' type. Multipoint coordinates are paired with listed time values.
  • (optional) Observation listing order is preferred to be from highest elevation/altitude to lowest elevation/depth.
  • (optional) Redundant sensors/observations would be listed in their order of importance (primary, secondary, etc) or depth(highest to lowest elevation). 
{
    "type": "Feature",
    "geometry": {
        "type": "MultiPoint",
        "coordinates": [[-80.55,30.04,0],[-79.00,31.00,0],[-78.00,32.00,0]] 
    },
    "properties": {
        "schemaRef": "ioos blessed schema name reference",
        "dictionaryRef": "ioos blessed obstype uom dictionary reference",
        "dictionaryURL": "http://nautilus.baruch.sc.edu/obsjson/secoora_dictionary.json",
        "metadataURL": "a link to further operator/platform metadata as GeoJSON"
        "operatorName": "ndbc",
        "operatorURL": "http://www.ndbc.noaa.gov/",
        "platformName": "41012",
        "platformURL": "http://www.ndbc.noaa.gov/station_page.php?station=41012",
        "platformId": "urn:x-noaa:def:station:noaa.nws.ndbc::41012",
   
        "time": ["2009-03-31T10:50:00Z","2009-03-31T11:50:00Z","2009-03-31T12:50:00Z"],

        "obsList": [
            {
                "obsType": "air_temperature",
                "uomType": "celsius",
                "valueList": ["22.0","23.0","24.0"],
                "elevRel": "3" 
            },
            {
                "obsType": "water_temperature",
                "uomType": "celsius",
                "valueList": ["17.0","18.0","19.0"],
                "elevRel": "-1" 
            } 
        ] 
    } 
}

embedded in KML as atom:link

Could also use the KML TimeSpan tag below as well (especially if only referencing TimeSpan files only) 

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<Document>
  <name>ObsJSON example</name>
  <open>1</open>
  <Placemark id="ndbc.41024.buoy">
    <name>ndbc.41024.buoy</name>
    <description>An html table derived from the ObsJSON would be displayed here</description>
    <Point>
      <coordinates>-77.0,32.0,0</coordinates>
    </Point>
    <TimeStamp><when>2009-03-14T16:00Z</when></TimeStamp>

    <ExtendedData>

   <!-- GeoJSON related link(latest obs) -->
   <atom:link type="application/json"
    href="http://myurl/feeds/ndbc/latest/ndbc.41024.buoy.json" />

   <!-- GeoJSON related link (latest obs - past 48 hours -->
   <atom:link type="application/json"
    href="http://myurl/feeds/ndbc/latest_hours_48/ndbc.41024.buoy.json" />

    </ExtendedData>

  </Placemark>
</Document>
</kml>

embedded in Atom

A simple Atom example using just JSON links, in this scenario each entry could reference the available platforms from a given provider. 

...
<entry>
   <id>latest/ndbc.41024.buoy.json</id>
   <title>ndbc.41024.buoy</title>
   <updated>2009-03-14T16:00:00Z</updated>
   <georss:where>
     <gml:Point><gml:pos>-77 32</gml:pos></gml:Point>
   </georss:where>

   <!-- GeoJSON related link -->
   <link type="application/json"
    href="http://myurl/feeds/ndbc/latest/ndbc.41024.buoy.json" />
</entry>

<entry>
   <id>latest_hours_48/ndbc.41024.buoy.json</id>
   <title>ndbc.41024.buoy</title>
   <updated>2009-03-14T16:00:00Z</updated>
   <georss:where>
     <gml:Point><gml:pos>-77 32</gml:pos></gml:Point>
   </georss:where>

   <!-- GeoJSON related link -->
   <link type="application/json"
    href="http://myurl/feeds/ndbc/latest_hours_48/ndbc.41024.buoy.json" />
</entry>
...

Used the following links for examples
http://sgillies.net/blog/883/sensible-observation-services
http://www.youtube.com/watch?v=T04fKsD56LU

Simple schema version 2

Below is another revision to the initial ObsJSON schema, which treats each platform sensor as a feature with associated geometries,properties and utilizing list association between geometry/time/value per feature/sensor.

  • Geometry z coordinate is relative to mean sea level(MSL) with height(+) or depth(-) in meters.
  • The ordering of effected list arguments is in time increasing order(oldest first, latest last) allowing picking off the latest value be grabbing the last associated set of time/values off the list.
  • Stationary platforms would use GeoJSON 'Point' type and mobile platforms would use 'MultiPoint' type. MultiPoint coordinates are paired with listed time values.
  • (optional ?) All fields under 'FeatureCollection' are optional except platformId. Think the other fields give some more self-contained minimal context,usage but all these could be linked in some way via the platformId reference.
  • (optional ?) sensorId is optional but would provide a means of association for related time-series or sensor metadata. 
    • {
    "type": "FeatureCollection",
    "schemaRef": "ioos blessed schema name reference(s)",
    "dictionaryRef": "ioos blessed obstype uom dictionary reference(s)",
    "dictionaryURL": "http://nautilus.baruch.sc.edu/obsjson/secoora_dictionary.json",
    "platformId": "urn:x-noaa:def:station:noaa.nws.ndbc::41012",
    "metadataURL": "link to further operator/platform metadata/links as XML/JSON",
    "operatorName": "ndbc",
    "operatorURL": "http://www.ndbc.noaa.gov/",
    "platformName": "41012",
    "platformURL": "http://www.ndbc.noaa.gov/station_page.php?station=41012",
    "features": [
        {
            "type": "Feature",
            "geometry": {
                "type": "MultiPoint",
                "coordinates": [[-80.55,30.04,3],[-79.00,31.00,3],[-78.00,32.00,3]] 
            },
            "properties": {
                "sensorId": "link to further sensor metadata/links as XML/JSON",
                "obsType": "air_temperature",
                "uomType": "celsius",
                "time": ["2009-03-31T10:50:00Z","2009-03-31T11:50:00Z","2009-03-31T12:50:00Z"],
                "value": ["22.0","23.0","24.0"] 
            } 
        },
        {
            "type": "Feature",
            "geometry": {
                "type": "MultiPoint",
                "coordinates": [[-80.55,30.04,-1],[-79.00,31.00,-1],[-78.00,32.00,-1]] 
            },
            "properties": {
                "sensorId": "link to further sensor metadata/links as XML/JSON",
                "obsType": "water_temperature",
                "uomType": "celsius",
                "time": ["2009-03-31T10:50:00Z","2009-03-31T11:50:00Z","2009-03-31T12:50:00Z"],
                "value": ["17.0","18.0","19.0"] 
            } 
        } 
    ] 
}

Potential issues

  • Traditional request/response approaches are single-obs centric(give me just water_temperature for platform/area) rather than platform/sensor-centric(give me everything for a given platform)
  • How good/complete are request/response from SOS,ERDDAP,etc for 'all' recent platform data?
  • How would KML/javascript styling support possible JSON/GeoJSON

Simple schema version 3

The below schema is flattened as much as possible, dropping the GeoJSON nesting/list and time/value list. Would be very similar schema-wise to WFS Simple GetFeature (thanks Raj Singh for the reminder/link regarding WFS Simple) or the earlier example ERDDAP GeoJSON response(thanks Roy Mendelssohn) below. 

{
    "type": "FeatureCollection",
    "schemaRef": "ioos blessed schema name reference(s)",
    "dictionaryRef": "ioos blessed obstype uom dictionary reference(s)",
    "dictionaryURL": "http://nautilus.baruch.sc.edu/obsjson/secoora_dictionary.json",
    "platformId": "urn:x-noaa:def:station:noaa.nws.ndbc::41012",
    "metadataURL": "link to further operator/platform metadata/links as XML/JSON",
    "operatorName": "ndbc",
    "operatorURL": "http://www.ndbc.noaa.gov/",
    "platformName": "41012",
    "platformURL": "http://www.ndbc.noaa.gov/station_page.php?station=41012",
    "features": [
        {
            "type": "Feature",
            "properties": {
                "latitude": "-80.55",
                "longitude": "30.04",
                "elevation": "3",
                "sensorId": "link to further sensor metadata/links as XML/JSON",
                "obsType": "air_temperature",
                "uomType": "celsius",
                "time": "2009-03-31T10:50:00Z",
                "value": "22.0" 
            } 
        },
       {
            "type": "Feature",
            "properties": {
                "latitude": "-80.55",
                "longitude": "30.04",
                "elevation": "3",
                "sensorId": "link to further sensor metadata/links as XML/JSON",
                "obsType": "air_temperature",
                "uomType": "celsius",
                "time": "2009-03-31T11:50:00Z",
                "value": "23.0" 
            } 
        },        
       {
            "type": "Feature",
            "properties": {
                "latitude": "-80.55",
                "longitude": "30.04",
                "elevation": "-1",
                "sensorId": "link to further sensor metadata/links as XML/JSON",
                "obsType": "water_temperature",
                "uomType": "celsius",
                "time": "2009-03-31T10:50:00Z",
                "value": "17.0" 
            } 
        }, 
       {
            "type": "Feature",
            "properties": {
                "latitude": "-80.55",
                "longitude": "30.04",
                "elevation": "-1",
                "sensorId": "link to further sensor metadata/links as XML/JSON",
                "obsType": "water_temperature",
                "uomType": "celsius",
                "time": "2009-03-31T11:50:00Z",
                "value": "18.0" 
            } 
        }              
    ] 
}

example ERDDAP GeoJSON response

response below to request

http://coastwatch.pfeg.noaa.gov/erddap/tabledap/ndbcSosWTemp.geoJson?longitude,latitude,station_id,altitude,time,WaterTemperature&longitude%3E=-130&longitude%3C=-110&latitude%3E=30&latitude%3C=39&time%3E=2009-04-03T00:00:00Z

This bounding box request might include several platforms data, requiring the station_id with each observation feature. 

{
  "type": "FeatureCollection",
  "propertyNames": ["station_id", "altitude", "time", "WaterTemperature"],
  "propertyUnits": [null, "m", "UTC", "degrees_C"],
  "bbox": [-130.0, 33.74, -119.06, 38.23],
  "features": [

{"type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [-123.32, 38.23] },
  "properties": {
    "station_id": "urn:x-noaa:def:station:noaa.nws.ndbc::46013",
    "altitude": null,
    "time": "2009-04-03T10:50:00Z",
    "WaterTemperature": 10.6 }
},
{"type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [-123.32, 38.23] },
  "properties": {
    "station_id": "urn:x-noaa:def:station:noaa.nws.ndbc::46013",
    "altitude": null,
    "time": "2009-04-03T14:50:00Z",
    "WaterTemperature": 9.9 }
},
{"type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [-120.97, 34.71] },
  "properties": {
    "station_id": "urn:x-noaa:def:station:noaa.nws.ndbc::46023",
    "altitude": null,
    "time": "2009-04-03T00:50:00Z",
    "WaterTemperature": 10.5 }
}
]
}

Suggestions

dictionary URI, platformType(systemType)

suggested by Luis Bermudez

1) if we were going to make this dictionary available for the semantic web we should have a base URI. I think, all the values you have, will not have problems of being part of a URI ( they have no spaces etc ..).

Could you define a base URI ? It could be for example:

http://nautilus.baruch.sc.edu/obsjson/secoora_dictionary.json

I know expressing the URI may appear unnecessary, but if we have this file in another location (e.g. locally), it will help us going back to it and will be easier to creating an RDF from it.

2) There is no platform type (which I prefer to call it system type ). I think this is important if we want to categorize observations by source and even putting nice icons.

dictionary URI example

For platformType(systemType) property, the simplest initial values I'd imagine would be 'fixed' or 'mobile'. Could reference developed lookup list from others as suggested.

Demo 1

Date: April 29, 2009

Links

Latest 24 hour file folder http://neptune.baruch.sc.edu/xenia/feeds/obsjson/all/latest_hours_24/

Latest 24 hour dynamic javascript styled kmz http://neptune.baruch.sc.edu/xenia/feeds/obsjson/all/latest_hours_24/all_latest.kmz

Known issues

Jeremy will address

  • some platforms repeat multiple times
  • some wind_from_direction reporting > 360 degrees
  • order sensor listing to match elevation ? top to bottom?
  • will add 'describeSensorURL' to platform metadata JSON

Pete ?

  • label y-value splits may have a large number of decimal places(19.000000003) - can style to 2 or 3 decimals max?
  • safe to show all graphs with no time axis? need filler/blank graph values if only one or two observations in past 24 hours? some platforms sampling more/less than once per hour.

Sample schema

metadata

{
"type": "Feature",
            "geometry": {
                "type": "Point",
                "coordinates": [-80.5,30]
            },
"properties": {
    "schemaRef": "ioos_blessed_schema_name_reference",
    "dictionaryRef": "ioos_blessed_obstype_uom_dictionary_reference",
    "dictionaryURL": "http://nautilus.baruch.sc.edu/obsjson/secoora_dictionary.json",
    "organizationName": "ndbc",
    "organizationURL": "http://www.ndbc.noaa.gov",
    "stationId": "urn:x-noaa:def:station:ndbc::41012",
    "stationURL": "http://www.ndbc.noaa.gov/station_page.php?station=41012",
    "stationTypeName": "buoy",
    "stationTypeImage": "http://www.ndbc.noaa.gov/images/stations/3m.jpg",
    "describeSensorURL": "TBD",

    "origin":"National Data Buoy Center",
    "useconst":"The information on government servers are in the public domain, unless specifically annotated otherwise, and may be used freely by the public so long as you do not 1) claim it is your own (e.g. by claiming copyright for NWS information -- see below), 2) use it in a manner that implies an endorsement or affiliation with NOAA/NWS, or 3) modify it in content and then present it as official government material. You also cannot present information of your own in a way that makes it appear to be official government information."
}
}

data

json_callback({
"type": "FeatureCollection",
    "stationId": "urn:x-noaa:def:station:ndbc::41012",
    "features": [        {"type": "Feature",
            "geometry": {
                "type": "MultiPoint",
                "coordinates": [[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0]] 
            },
         "properties": {
            "obsType": "air_pressure",
            "uomType": "mb",
            "time": ["2009-04-28T18:50:00Z","2009-04-28T19:50:00Z","2009-04-28T20:50:00Z","2009-04-28T21:50:00Z","2009-04-28T22:50:00Z","2009-04-28T23:50:00Z","2009-04-29T00:50:00Z","2009-04-29T01:50:00Z","2009-04-29T02:50:00Z","2009-04-29T03:50:00Z","2009-04-29T04:50:00Z","2009-04-29T05:50:00Z","2009-04-29T06:50:00Z","2009-04-29T07:50:00Z","2009-04-29T08:50:00Z","2009-04-29T09:50:00Z","2009-04-29T10:50:00Z","2009-04-29T11:50:00Z","2009-04-29T12:50:00Z","2009-04-29T13:50:00Z","2009-04-29T14:50:00Z","2009-04-29T15:50:00Z","2009-04-29T16:50:00Z"],
            "value": ["1027.3","1026.5","1026","1025.9","1025.5","1025.3","1025.7","1025.6","1025.9","1026","1025.8","1025.7","1025","1024.6","1024.5","1024.9","1025.4","1025.9","1026.3","1026.3","1026.6","1026.2","1025.7"]
        }},
        {"type": "Feature",
            "geometry": {
                "type": "MultiPoint",
                "coordinates": [[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4],[-80.5,30,4]] 
            },
         "properties": {
            "obsType": "air_temperature",
            "uomType": "celsius",
            "time": ["2009-04-28T18:50:00Z","2009-04-28T19:50:00Z","2009-04-28T20:50:00Z","2009-04-28T21:50:00Z","2009-04-28T22:50:00Z","2009-04-28T23:50:00Z","2009-04-29T00:50:00Z","2009-04-29T01:50:00Z","2009-04-29T02:50:00Z","2009-04-29T03:50:00Z","2009-04-29T04:50:00Z","2009-04-29T05:50:00Z","2009-04-29T06:50:00Z","2009-04-29T07:50:00Z","2009-04-29T08:50:00Z","2009-04-29T09:50:00Z","2009-04-29T10:50:00Z","2009-04-29T11:50:00Z","2009-04-29T12:50:00Z","2009-04-29T13:50:00Z","2009-04-29T14:50:00Z","2009-04-29T15:50:00Z","2009-04-29T16:50:00Z"],
            "value": ["23","23.2","23","23","23","22.9","22.9","22.8","22.8","22.8","22.7","22.7","22.4","22.4","22.2","22.2","22.1","22.2","22.6","22.4","22.7","23","23"]
        }},
...

Simple schema version 5

The below is the most compact form I can currently think of, using a leading 'platform' set of data which does not contain a uom or values but does provide a list of location and time points which are inherited by other sensors in the listing that do not contain a location or time list. Each sensor could contain an 'elevation' if included that specifies the elevation above(+) or below(-) the platform location in meters. I'm doubtful that this qualifies as GeoJSON at this point, but it should be very minimal data transfer for cases - the only other additional compression step past this that comes to mind for now would be for cases where large sets of platform data(say greater than 100 platforms requested at once), to provide id lookup tables(organization,platform,sensor types, carocoops = 12, air_temperature = 23 for example) as json and use integer id lookups within the repeated data listings instead of the full string listing. 

json_callback({
"type": "FeatureCollection",
    "stationId": "urn:x-noaa:def:station:ndbc::41012",
    "features": [        {"type": "Feature",
            "geometry": {
                "type": "MultiPoint",
                "coordinates": [[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0],[-80.5,30,0]] 
            },
         "properties": {
            "obsType": "platform",
            "time": ["2009-04-28T18:50:00Z","2009-04-28T19:50:00Z","2009-04-28T20:50:00Z","2009-04-28T21:50:00Z","2009-04-28T22:50:00Z","2009-04-28T23:50:00Z","2009-04-29T00:50:00Z","2009-04-29T01:50:00Z","2009-04-29T02:50:00Z","2009-04-29T03:50:00Z","2009-04-29T04:50:00Z","2009-04-29T05:50:00Z","2009-04-29T06:50:00Z","2009-04-29T07:50:00Z","2009-04-29T08:50:00Z","2009-04-29T09:50:00Z","2009-04-29T10:50:00Z","2009-04-29T11:50:00Z","2009-04-29T12:50:00Z","2009-04-29T13:50:00Z","2009-04-29T14:50:00Z","2009-04-29T15:50:00Z","2009-04-29T16:50:00Z"],
            ]
        }},
        {"type": "Feature",
         "properties": {
            "obsType": "air_temperature",
            "uomType": "celsius",
            "elevation": "4",
            "value": ["23","23.2","23","23","23","22.9","22.9","22.8","22.8","22.8","22.7","22.7","22.4","22.4","22.2","22.2","22.1","22.2","22.6","22.4","22.7","23","23"]
        }},
...

instrumentation case examples

  • Geometry z coordinate is relative to mean sea level(MSL) with height(+) or depth(-) in meters.
  • The ordering of effected list arguments is in time increasing order(oldest first, latest last) allowing picking off the latest value be grabbing the last associated set of time/values off the list.
  • ? Stationary platforms would use GeoJSON 'Point' type and mobile platforms would use 'MultiPoint' type. MultiPoint coordinates are paired with listed time values.
  • ? sOrder(sensor order) is optional but would provide a means of distinguishing between redundant sensors with primary, secondary, etc level of importance. sOrder integer increases with direction away from MSL.

stationary platform

The below example shows an air_pressure and two air_temperature readings(a primary sensor and redundant secondary sensor - differing by z-coordinate and sOrder) 

json_callback({
"type": "FeatureCollection",
    "id": "urn:x-noaa:def:station:ndbc::41012",
    "features": [        {"type": "Feature",
            "geometry": {
                "type": "Point",
                "coordinates": [-80.5,30,0] 
            },
         "properties": {
            "sOrder": "1",
            "obsType": "air_pressure",
            "uomType": "mb",
            "time": ["2009-04-28T18:50:00Z","2009-04-28T19:50:00Z","2009-04-28T20:50:00Z","2009-04-28T21:50:00Z","2009-04-28T22:50:00Z","2009-04-28T23:50:00Z"],
            "value": ["1027.3","1026.5","1026","1025.9","1025.5","1025.3"]
        }},
        {"type": "Feature",
            "geometry": {
                "type": "Point",
                "coordinates": [-80.5,30,4] 
            },
         "properties": {
            "sOrder": "1",
            "obsType": "air_temperature",
            "uomType": "celsius",
            "time": ["2009-04-28T18:50:00Z","2009-04-28T19:50:00Z","2009-04-28T20:50:00Z","2009-04-28T21:50:00Z","2009-04-28T22:50:00Z","2009-04-28T23:50:00Z"],
            "value": ["23","23.2","23","23","23","22.9"]
        }},
        {"type": "Feature",
            "geometry": {
                "type": "Point",
                "coordinates": [-80.5,30,6] 
            },
         "properties": {
            "sOrder": "2",
            "obsType": "air_temperature",
            "uomType": "celsius",
            "time": ["2009-04-28T18:50:00Z","2009-04-28T19:50:00Z","2009-04-28T20:50:00Z","2009-04-28T21:50:00Z","2009-04-28T22:50:00Z","2009-04-28T23:50:00Z"],
            "value": ["23","23.2","23","23","23","22.9"]
        }},
...

stationary profiler

e.g. a temperature,current,etec profiler looking up or down a water column - this is basically the same format as a stationary platform, just the same observation type listed and distinguished by z-coordinate elevation and sOrder. 

json_callback({
"type": "FeatureCollection",
    "id": "urn:x-noaa:def:station:ndbc::41012",
    "features": [        {"type": "Feature",
            "geometry": {
                "type": "Point",
                "coordinates": [-80.5,30,-1] 
            },
         "properties": {
            "sOrder": "1",
            "obsType": "water_temperature",
            "uomType": "celsius",
            "time": ["2009-04-28T18:50:00Z","2009-04-28T19:50:00Z","2009-04-28T20:50:00Z","2009-04-28T21:50:00Z","2009-04-28T22:50:00Z","2009-04-28T23:50:00Z"],
            "value": ["23","23.2","23","23","23","22.9"]
        }},
        {"type": "Feature",
            "geometry": {
                "type": "Point",
                "coordinates": [-80.5,30,-2] 
            },
         "properties": {
            "sOrder": "2",
            "obsType": "water_temperature",
            "uomType": "celsius",
            "time": ["2009-04-28T18:50:00Z","2009-04-28T19:50:00Z","2009-04-28T20:50:00Z","2009-04-28T21:50:00Z","2009-04-28T22:50:00Z","2009-04-28T23:50:00Z"],
            "value": ["23","23.2","23","23","23","22.9"]
        }},
...

glider

e.g. measuring different obs on a freely moving platform 

json_callback({
"type": "FeatureCollection",
    "id": "urn:x-noaa:def:station:ndbc::41012",
    "features": [        {"type": "Feature",
            "geometry": {
                "type": "MultiPoint",
                "coordinates": [[-80.5,30,-1.3],[-80.55,29.5,-3.8],[-80.61,28.94,-15.8]] 
            },
         "properties": {
            "sOrder": "1",
            "obsType": "water_temperature",
            "uomType": "celsius",
            "time": ["2009-04-28T18:50:00Z","2009-04-28T19:50:00Z","2009-04-28T20:50:00Z"],
            "value": ["23","23.2","23"]
        }},
        {"type": "Feature",
            "geometry": {
                "type": "MultiPoint",
                "coordinates": [[-80.5,30,-1.3],[-80.55,29.5,-3.8],[-80.61,28.94,-15.8]] 
            },
         "properties": {
            "sOrder": "1",
            "obsType": "salinity",
            "uomType": "psu",
            "time": ["2009-04-28T18:50:00Z","2009-04-28T19:50:00Z","2009-04-28T20:50:00Z"],
            "value": ["33.5","33.8","34.2"]
        }},
...

► Sign in to add a comment
Powered by Google Project Hosting