FDSN Event Web Service GeoJSON format

[Jeremy Fee]

Hello,

I'm writing to see if FDSN has interest in adding a JSON output format to
the FDSN Event Web Service specification. The JSON format (and
specifically GeoJSON) are very useful for integrating data into web
applications and other programming languages.

USGS has already implemented GeoJSON FeatureCollection (many events) and
GeoJSON Feature (one event) outputs for our FDSN end point and near-real
time feeds, which is described on this page and could be a starting point
for standardization:

https://earthquake.usgs.gov/earthquakes/feed/v1.0/geojson.php

Example URL for many events:

https://earthquake.usgs.gov/fdsnws/event/1/query?format=geojson&starttime=2017-03-03&endtime=2017-03-04&minmag=4.5

Example URL for one event:

https://earthquake.usgs.gov/fdsnws/event/1/query?format=geojson&eventid=us100086pe

Thanks,

Jeremy

[Doug Neuhauser]

I would like to point out that AFAIK, the geojson format
uses Unix nominal epoch time and CANNOT represent leap seconds.
- Doug N

On 03/06/2017 08:54 AM, Philip Crotwell wrote:
> Hi
>
> I think this would be a very nice addition. A JSON format would be
> much easier to work with in the browser than xml.
>
> One concern I have is that this documentation web page gives an
> overview of the GeoJSON structure, but to be effective as an FDSN
> webservice output, I think there would need to be a specification for
> how to encode all of the various earthquake attributes into the
> GeoJSON properties. My limited understanding is that GeoJSON gives the
> overall json structure, but the properties section and maybe metadata
> section are up to the individual application.
>
> Is there any more information on those properties and how they would
> map to/from the existing format?
>
> One thing I do really appreciate about this format is that for each
> event in the general query there is a URL for the details. Really nice
> to have that given in a way that requires little to no interpretation
> by the client.
>
> thanks
> Philip

>> ----------------------
>> FDSN Working Group III
>> (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
>>
>> Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
>> Update subscription preferences at http://www.fdsn.org/account/profile/
>>
>
> ----------------------
> FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
>
> Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
> Update subscription preferences at http://www.fdsn.org/account/profile/
>

--
------------------------------------------------------------------------
Doug Neuhauser University of California, Berkeley
do...@seismo.berkeley.edu Berkeley Seismological Laboratory
Office: 510-642-0931 221 McCone Hall # 4760
Fax: 510-643-5811 Berkeley, CA 94720-4760
Remote: 530-752-5615 (Wed,Fri)

[Philip Crotwell]

Hi

I think this would be a very nice addition. A JSON format would be
much easier to work with in the browser than xml.

One concern I have is that this documentation web page gives an
overview of the GeoJSON structure, but to be effective as an FDSN
webservice output, I think there would need to be a specification for
how to encode all of the various earthquake attributes into the
GeoJSON properties. My limited understanding is that GeoJSON gives the
overall json structure, but the properties section and maybe metadata
section are up to the individual application.

Is there any more information on those properties and how they would
map to/from the existing format?

One thing I do really appreciate about this format is that for each
event in the general query there is a URL for the details. Really nice
to have that given in a way that requires little to no interpretation
by the client.

thanks
Philip

On Fri, Mar 3, 2017 at 3:14 PM, Jeremy Fee <jm...@usgs.gov> wrote:

[Jeremy Fee]

Hi,

Doug is correct that current USGS implementation uses Unix epoch times
(millisecond), which may be as much as one second off during a leap
second. Other date representations (such as ISO8601) can be considered if
leap second support is a requirement.

Thanks,

Jeremy

On Mon, Mar 6, 2017 at 11:16 AM, Doug Neuhauser <do...@seismo.berkeley.edu>
wrote: