Philip Crotwell
Hi
So, it is pretty nice that the fdsn has adopted/created xml standards for
both event data and station data. It is also really nice that the query
parameters for the web services have been standardized across station,
event and data queries. But it seems a bit of a shame that there is
virtually no overlap or reuse between these two output formats. With all
the talk recently about "bridging the silos" within for example EarthCubed
to allow better interaction between the various geoscience disciplines, it
seems a bit of a shame that there isn't more "bridging the silos" with our
subdisciplines of seismology.
For example, QuakML has a "RealQuantity" that has a floating point value,
lowerUncertainty and upperUncertainty. FDSNStationXML has a "FloatType"
that has a floating point value, a "plusError" and a "minusError". There
are differences, like FDSNStationXML's also has a "unit" (YEAH!), but for
the most part these two seem to play the same role. There are other items,
like latitude, longitude, etc. that are also common between event and
station data. Obviously there are also many differences as well, but IMHO
it seems like it would be more efficient to extract and standardize what
commonalities exist.
Back in the day, the FISSURES/DHI data model had this reuse of common ideas
between the station, waveform and event areas. XML and web services are
great, but it is too bad that in taking two steps forward on new
technology, we are also taking one step back on reuse and ease of
interaction. In the old way, if I wanted to write a routine to calculate
distances, I just needed a distance(Location , Location ) routine. In the
new way, I either have to write 3 routines:
distance(StationLocation , EventLocation )
distance(StationLocation , StationLocation )
distance(EventLocation , EventLocation )
or I have to come up with a new data model internal to my client and write
translate(StatonLocation)
translate(EventLocation)
and then write a distance method on my new data model. All this just feels
inefficient.
It is probably late in the game to be talking about this type of thing, and
I know that this would involve a big redesign of both schemas, but I think
it would be a significant improvement. Is there any talk of moving in this
direction. Perhaps eventually a QuakeML 2.0 and a FDSNStationXML 2.0 that
share a common FDSNCoreXML?
thanks,
Philip
So, it is pretty nice that the fdsn has adopted/created xml standards for
both event data and station data. It is also really nice that the query
parameters for the web services have been standardized across station,
event and data queries. But it seems a bit of a shame that there is
virtually no overlap or reuse between these two output formats. With all
the talk recently about "bridging the silos" within for example EarthCubed
to allow better interaction between the various geoscience disciplines, it
seems a bit of a shame that there isn't more "bridging the silos" with our
subdisciplines of seismology.
For example, QuakML has a "RealQuantity" that has a floating point value,
lowerUncertainty and upperUncertainty. FDSNStationXML has a "FloatType"
that has a floating point value, a "plusError" and a "minusError". There
are differences, like FDSNStationXML's also has a "unit" (YEAH!), but for
the most part these two seem to play the same role. There are other items,
like latitude, longitude, etc. that are also common between event and
station data. Obviously there are also many differences as well, but IMHO
it seems like it would be more efficient to extract and standardize what
commonalities exist.
Back in the day, the FISSURES/DHI data model had this reuse of common ideas
between the station, waveform and event areas. XML and web services are
great, but it is too bad that in taking two steps forward on new
technology, we are also taking one step back on reuse and ease of
interaction. In the old way, if I wanted to write a routine to calculate
distances, I just needed a distance(Location , Location ) routine. In the
new way, I either have to write 3 routines:
distance(StationLocation , EventLocation )
distance(StationLocation , StationLocation )
distance(EventLocation , EventLocation )
or I have to come up with a new data model internal to my client and write
translate(StatonLocation)
translate(EventLocation)
and then write a distance method on my new data model. All this just feels
inefficient.
It is probably late in the game to be talking about this type of thing, and
I know that this would involve a big redesign of both schemas, but I think
it would be a significant improvement. Is there any talk of moving in this
direction. Perhaps eventually a QuakeML 2.0 and a FDSNStationXML 2.0 that
share a common FDSNCoreXML?
thanks,
Philip
