[Geojson] Toward consensus on proposals
Jeremy Cothran
jeremy.cothran at gmail.com
Tue Nov 1 10:59:07 PDT 2011
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/64ebbe60/attachment.htm>
More information about the GeoJSON
mailing list