<div dir="ltr"><div><div><div><div><div><br></div><div>Hi<br><br></div>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 &quot;bridging the silos&quot; within for example EarthCubed to allow better interaction between the various geoscience disciplines, it seems a bit of a shame that there isn&#39;t more &quot;bridging the silos&quot; with our subdisciplines of seismology. <br>
<br></div>For example, QuakML has a &quot;RealQuantity&quot; that has a floating point value, lowerUncertainty and upperUncertainty. FDSNStationXML has a &quot;FloatType&quot; that has a floating point value, a &quot;plusError&quot; and a &quot;minusError&quot;. There are differences, like FDSNStationXML&#39;s also has a &quot;unit&quot; (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.<br>
<br></div><div>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:<br>
</div><div>distance(StationLocation , EventLocation )<br></div><div>distance(StationLocation , StationLocation )<br></div><div>distance(EventLocation , EventLocation )<br>or I have to come up with a new data model internal to my client and write<br>
</div><div>translate(StatonLocation) <br></div><div>translate(EventLocation)<br></div><div>and then write a distance method on my new data model. All this just feels inefficient.<br></div><div><br></div>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?<br>
<br></div>thanks,<br></div>Philip<br></div>