Hi.
This request:
http://www.iris.edu/ws/station/query?updatedafter=2011-11-07&level=resp&net=XM&sta=WM01&timewindow=2010-01-01,2500-12-12
returns a <StaMessage><Network><Station>... hierarchy.
This request:
http://www.iris.edu/ws/station/query?updatedafter=2011-06-06&level=sta&net=XM&timewindow=2010-01-01,2500-12-12
returns a <StaMessage><Station> hierarchy, with no <Network> level.
This seems inconsistent -- the <Network> tag should either be there or not,
but shouldn't disappear between levels of the same web service. I know the
<Network> level used to exist in the second request, because its removal
broke my code.
Thanks!
-- John
This request:
http://www.iris.edu/ws/station/query?updatedafter=2011-11-07&level=resp&net=XM&sta=WM01&timewindow=2010-01-01,2500-12-12
returns a <StaMessage><Network><Station>... hierarchy.
This request:
http://www.iris.edu/ws/station/query?updatedafter=2011-06-06&level=sta&net=XM&timewindow=2010-01-01,2500-12-12
returns a <StaMessage><Station> hierarchy, with no <Network> level.
This seems inconsistent -- the <Network> tag should either be there or not,
but shouldn't disappear between levels of the same web service. I know the
<Network> level used to exist in the second request, because its removal
broke my code.
Thanks!
-- John
-
Hi John,
This is a bug, the next release will include a fix. Even though the StationXML schema currently allows <Station> entries outside of a <Network> container the DMC's service will not produce (on purpose) that variant, all <Station> entries should be contained in a <Network>.
Chad
On Nov 9, 2011, at 10:43 PM, John D. West wrote:
Hi.
This request: http://www.iris.edu/ws/station/query?updatedafter=2011-11-07&level=resp&net=XM&sta=WM01&timewindow=2010-01-01,2500-12-12
returns a <StaMessage><Network><Station>... hierarchy.
This request: http://www.iris.edu/ws/station/query?updatedafter=2011-06-06&level=sta&net=XM&timewindow=2010-01-01,2500-12-12
returns a <StaMessage><Station> hierarchy, with no <Network> level.
This seems inconsistent -- the <Network> tag should either be there or not, but shouldn't disappear between levels of the same web service. I know the <Network> level used to exist in the second request, because its removal broke my code.
Thanks!
-- John
_______________________________________________
webservices mailing list
webservices<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/webservices
-
Hi Chad
I think this is what you are saying, but just want to make sure. Do
you mean "All <Station> entries will be contained in a <Network>
element and there will be no duplicate <Network> elements"?
In other words if a stationXML document has two stations that are in
the same real-world network, then the corresponding <Station> elements
will always be contained in a common <Network> element?
thanks,
PHilip
On Mon, Nov 14, 2011 at 10:47 AM, Chad Trabant <chad<at>iris.washington.edu> wrote:
Hi John,
This is a bug, the next release will include a fix. Even though the
StationXML schema currently allows <Station> entries outside of a <Network>
container the DMC's service will not produce (on purpose) that variant, all
<Station> entries should be contained in a <Network>.
Chad
On Nov 9, 2011, at 10:43 PM, John D. West wrote:
Hi.
This
request: http://www.iris.edu/ws/station/query?updatedafter=2011-11-07&level=resp&net=XM&sta=WM01&timewindow=2010-01-01,2500-12-12
returns a <StaMessage><Network><Station>... hierarchy.
This
request: http://www.iris.edu/ws/station/query?updatedafter=2011-06-06&level=sta&net=XM&timewindow=2010-01-01,2500-12-12
returns a <StaMessage><Station> hierarchy, with no <Network> level.
This seems inconsistent -- the <Network> tag should either be there or not,
but shouldn't disappear between levels of the same web service. I know the
<Network> level used to exist in the second request, because its removal
broke my code.
Thanks!
-- John
_______________________________________________
webservices mailing list
webservices<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/webservices
_______________________________________________
webservices mailing list
webservices<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/webservices
-
Hi Philip,
Hi Chad
Yes.
I think this is what you are saying, but just want to make sure. Do
you mean "All <Station> entries will be contained in a <Network>
element
and there will be no duplicate <Network> elements"?
Not necessarily. The upcoming beta release will not guarantee that all of the stations for a single network fall within a single <Network> element. This is only known to happen if you request duplicate networks, e.g. "network=_GSN,II" (the _GSN virtual network includes the II network). We are considering how to make sure there are not duplicate <Network> elements for future releases.
Chad
In other words if a stationXML document has two stations that are in
the same real-world network, then the corresponding <Station> elements
will always be contained in a common <Network> element?
thanks,
PHilip
On Mon, Nov 14, 2011 at 10:47 AM, Chad Trabant <chad<at>iris.washington.edu> wrote:
Hi John,
_______________________________________________
This is a bug, the next release will include a fix. Even though the
StationXML schema currently allows <Station> entries outside of a <Network>
container the DMC's service will not produce (on purpose) that variant, all
<Station> entries should be contained in a <Network>.
Chad
On Nov 9, 2011, at 10:43 PM, John D. West wrote:
Hi.
This
request: http://www.iris.edu/ws/station/query?updatedafter=2011-11-07&level=resp&net=XM&sta=WM01&timewindow=2010-01-01,2500-12-12
returns a <StaMessage><Network><Station>... hierarchy.
This
request: http://www.iris.edu/ws/station/query?updatedafter=2011-06-06&level=sta&net=XM&timewindow=2010-01-01,2500-12-12
returns a <StaMessage><Station> hierarchy, with no <Network> level.
This seems inconsistent -- the <Network> tag should either be there or not,
but shouldn't disappear between levels of the same web service. I know the
<Network> level used to exist in the second request, because its removal
broke my code.
Thanks!
-- John
_______________________________________________
webservices mailing list
webservices<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/webservices
_______________________________________________
webservices mailing list
webservices<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/webservices
webservices mailing list
webservices<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/webservices
-
Hum, ok I can see that as a bit of a pathological request. But as long
as the request sticks to real world networks, stations and time
queries, do you believe it is reasonable for a client code to assume
the single network element per network? That makes the client side a
lot easier to deal with.
thanks
Philip
On Mon, Nov 14, 2011 at 11:25 AM, Chad Trabant <chad<at>iris.washington.edu> wrote:
Hi Philip,
Hi Chad
Yes.
I think this is what you are saying, but just want to make sure. Do
you mean "All <Station> entries will be contained in a <Network>
element
and there will be no duplicate <Network> elements"?
Not necessarily. The upcoming beta release will not guarantee that all of the stations for a single network fall within a single <Network> element. This is only known to happen if you request duplicate networks, e.g. "network=_GSN,II" (the _GSN virtual network includes the II network). We are considering how to make sure there are not duplicate <Network> elements for future releases.
Chad
In other words if a stationXML document has two stations that are in
_______________________________________________
the same real-world network, then the corresponding <Station> elements
will always be contained in a common <Network> element?
thanks,
PHilip
On Mon, Nov 14, 2011 at 10:47 AM, Chad Trabant <chad<at>iris.washington.edu> wrote:
Hi John,
_______________________________________________
This is a bug, the next release will include a fix. Even though the
StationXML schema currently allows <Station> entries outside of a <Network>
container the DMC's service will not produce (on purpose) that variant, all
<Station> entries should be contained in a <Network>.
Chad
On Nov 9, 2011, at 10:43 PM, John D. West wrote:
Hi.
This
request: http://www.iris.edu/ws/station/query?updatedafter=2011-11-07&level=resp&net=XM&sta=WM01&timewindow=2010-01-01,2500-12-12
returns a <StaMessage><Network><Station>... hierarchy.
This
request: http://www.iris.edu/ws/station/query?updatedafter=2011-06-06&level=sta&net=XM&timewindow=2010-01-01,2500-12-12
returns a <StaMessage><Station> hierarchy, with no <Network> level.
This seems inconsistent -- the <Network> tag should either be there or not,
but shouldn't disappear between levels of the same web service. I know the
<Network> level used to exist in the second request, because its removal
broke my code.
Thanks!
-- John
_______________________________________________
webservices mailing list
webservices<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/webservices
_______________________________________________
webservices mailing list
webservices<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/webservices
webservices mailing list
webservices<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/webservices
webservices mailing list
webservices<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/webservices
-
-
-