[Geojson] Toward consensus on proposals
Jeremy Cothran
jeremy.cothran at gmail.com
Tue Nov 1 13:44:50 PDT 2011
Hi Matt,
I updated some documentation examples just now at
http://code.google.com/p/xenia/wiki/ObsJSON#instrumentation_case_examples
and repeating below inline.
Made the 'stationId' just the FeatureCollection 'id' - also went back to an
earlier convention with stationary points just using 'Point' and moving
points using 'MultiPoint' - think I made everything MultiPoint earlier
which is consistent for the most complex moving glider case but verbose for
the simpler cases.
The first two cases of stationary platform and profiler are format-wise
pretty much the same, distinguishing between sensors by z-coordinate and
sensor order(sOrder) which is a more homegrown convention to distinguish
between simple redundant cases but also applies to profilers.
My example for glider is verbose with repeated location and time, but have
cases where both fixed and moving platforms sample at different intervals
depending on the observation dynamics vs battery usage.
Questions, etc feel free to ask.
Thanks
Jeremy
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?<http://code.google.com/p/xenia/w/edit/MultiPoint>'
type. MultiPoint?
<http://code.google.com/p/xenia/w/edit/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"]
}},
...
On Tue, Nov 1, 2011 at 3:08 PM, Matt Priour <mpriour at kestrelcomputer.com>wrote:
> 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 <jeremy.cothran at gmail.com>
> *Sent:* Tuesday, November 01, 2011 12:59 PM
> *To:* Matt Priour <mpriour at kestrelcomputer.com>
> *Cc:* Sean Gillies <sean.gillies at gmail.com> ; 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 <sean.gillies at gmail.com>
>> *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/a96797b0/attachment.htm>
More information about the GeoJSON
mailing list