International Federation of Digital Seismograph Networks

FDSN Working Group III

FDSN Working Group III on Coordination of Products, Tools and Services

This group was established at the 2007 FDSN meeting in Perugia Italy.

FDSN WGIII will identify standard products that may be produced by FDSN data centers. It will advocate product uniformity and methods of production for FDSN products. It will advocate development and distribution of standard software tools that will support the production of FDSN products.

The goal of FDSN WGIII is to coordinate the creation of uniform products at participating FDSN data centers. It will also attempt to standardize services and share tools that produce FDSN approved products.

fdsn-wg3-products@lists.fdsn.org

February
January
December
November
October
September
August (6)
July (11)
June (14)
May
April (1)
March (15)
February
January
December
November
October
September
August
July (1)
June (2)
May (2)
April
March (1)
February (6)
January (1)
December
November
October
September
August (1)
July
June
May
April
March
February
January
December
November
October
September
August
July
June (2)
May
April
March
February
January
December
November
October
September
August
July
June
May
April
March
February
January
December
November
October
September
August
July
June
May
April
March
February
January (1)
December
November
October
September
August
July
June (4)
May
April
March
February
January
December
November
October
September (1)
August (1)

Active Message Threads for November 2016

John Clinton
Nov. 28, 2016, 1:14 p.m.
Hi all, At http://www.fdsn.org/webservices/datacenters/ we are requested to use this mailing list to submit changes to the lists of information from datacenters supporting fdsn web services. I would like to edit the information regarding public web services access points for ETHZ listed on this same page. In line with an EIDA strategy to only expose metadata that we are entitled to distribute, we wish to change the base address of our dataselect and station services. The event service will ... [more]
Replies
I think the best option is an extension to the existing Quakeml 1.2 specification. New attributes and values can be added in a new namespace, and those attributes can be added to the existing event type element to provide more specific information where it is known. This provides a simpler implementation path for many existing users and documents. Thanks, Jeremy On Thu, Aug 4, 2016 at 8:35 AM, Kästli Philipp <kaestli@sed.ethz.ch> wrote: > > On Thu, Jul 21, 2016 at 2:13 PM, Glenn Thom... [more]
No replies