[Geojson] Toward consensus on proposals

Tue Nov 1 12:08:17 PDT 2011

Jeremy,
I think you have found the most reasonable way to represent that data given the current spec, however, I think you and others would agree that it is both overly verbose and onerous to represent data collections in this way.

Metadata could be another object within the dataSeries object. Given the inclusion of metadata, the Data Series spec with some further tweaks could support all of your use cases.

One use case I would also like to see it used for is time series data about specific geographic areas. For example, there is no good reason to repeatedly include a complex polygon geometries again and again for a time-series of data unless the geometry is likely to change over time.

I will update the proposal to include some kind of metadata specification property and convert your example below to the Data Series format.

Do you have examples of how you are encoding the last 2 use cases, I can guess, but would like to see how you separate the data out for reference.

Matt Priour

From: Jeremy Cothran 
Sent: Tuesday, November 01, 2011 12:59 PM
To: Matt Priour 
Cc: Sean Gillies ; geojson at lists.geojson.org 
Subject: Re: [Geojson] Toward consensus on proposals

I'd agree with what's lacking in the two points below(multi-dimensional, metadata) - and also that these are use-case specific extensions that don't have to sink a simple functional working core geojson spec.  The 3 use-cases that we are currently trying to support in our domain are: 

1)stationary point
2)stationary profilers - a temperature,current,etec profiler looking up or down a water column
3)gliders - measuring different obs on a freely moving platform

The proposed dataseries would work for the first case(stationary point) if the metadata/unit_of_measure is baked into the observation name like 'air_temperature.celsius' but would prefer observation type and unit of measure as better separated and obvious properties or tags.

They way I'm doing it in the example below has it's own set of drawbacks(assumptions regarding matching order between location,time,data steps , verbose, etc), but supports the above 3 instrumentation cases.

Thanks
Jeremy

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"]         }},...

On Mon, Oct 31, 2011 at 2:41 PM, Matt Priour <mpriour at kestrelcomputer.com> wrote:

  I’ll be the first to admit that the Data Series proposal is not fully baked. It was my attempt to simplify a specific but fairly widespread use case. Representing a series of data that is associated with a single feature is excessively onerous and there is not an accepted standardized way to do that in the current GeoJSON spec.

  I was hoping that there would be some discussion of this proposal by those with the most interest in seeing this problem solved. However if the community feels that this is too specific to write into the general GeoJSON spec, then maybe I could write up a separate specification that would be an “official” extension. Maybe something like an Data Series extension to the more general spec would be more acceptable.

  As to the reason the Data Series would be a privileged object and not in the normal properties, that made more sense to me since the data series would likely be tied to a specific feature with its own specific properties that would apply to all the collected data. 

  Two things that are most obviously lacking from the data series proposal are
  1. Multi-dimensional series
  2. Metadata about the observations (measurement units, full name / label of data property, etc...)

  Matt Priour

  From: Sean Gillies 
  Sent: Monday, October 31, 2011 12:27 PM
  To: geojson at lists.geojson.org 
  Subject: [Geojson] Toward consensus on proposals

  Hi all,

  We've got two proposals for changes to the spec and one that may be
  arriving (Andrew?), so it shouldn't take long to decide whether to
  accept them or not.

  Circles and Ellipses:
  https://github.com/GeoJSONWG/geojson-spec/wiki/wiki/Proposal%20Circles%20and%20Ellipses%20Geoms

  Let's be clear whether we're specifying paths or patches. Center
  coordinates + radius feels natural to me. If a CRS is defined,
  wouldn't it be best to apply those units to the radius? Otherwise,
  could we require units to always (MUST) be meters?

  An ellipse is complicated by the two axes and their orientation.
  Defining these differently than GML does would need a strong argument.

  Circles and ellipses can be approximated by polygons, but it becomes
  onerous for good approximations. I'm in favor of this proposal.

  Data Series Proposal:
  https://github.com/GeoJSONWG/geojson-spec/wiki/Data-Series-Proposal

  I'm concerned about adding something so specialized to the spec and
  also wonder why a data series object needs to be privileged instead of
  simply going in the properties object.

  Let's discuss. I'll split the subject in two as soon as it seems needed.

  -- 
  Sean Gillies
  _______________________________________________
  Geojson mailing list
  Geojson at lists.geojson.org
  http://lists.geojson.org/listinfo.cgi/geojson-geojson.org

  _______________________________________________
  Geojson mailing list
  Geojson at lists.geojson.org
  http://lists.geojson.org/listinfo.cgi/geojson-geojson.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20111101/ee726032/attachment-0005.htm>