Closed emiliom closed 10 years ago
Internally the code is structure so that the NDBC/COOPS collectors are derived from the IoosSweSos collector, and patched up to handle the differences (such as csv). That’s probably how they got documented as such, and yes I agree should be changed.
I won’t get to changing any of that today so if you get to it, great :) If not, I’ll add a few – both 52N and NcSOS endpoints would be useful.
From: Emilio Mayorga notifications@github.com<mailto:notifications@github.com> Reply-To: ioos/pyoos reply@reply.github.com<mailto:reply@reply.github.com> Date: Friday, March 28, 2014 at 2:37 PM To: ioos/pyoos pyoos@noreply.github.com<mailto:pyoos@noreply.github.com> Subject: [pyoos] Misleading description of NDBC & COOPS collectors as "IOOS SWE SOS 1.0"? (#28)
The README file lists these two collectors:
NDBC Observations - IOOS SWE SOS 1.0 CO-OPS Observations - IOOS SWE SOS 1.0
I think this is misleading. The NDBC & CO-OPS collectors are not full-blown IOOS SWE SOS 1.0 collectors. The SOS endpoints actually only provide IOOS DIF and IOOS csv GetObservation responses (and slightly different ones, at that), and quite divergent and non IOOS SWE SOS 1.0 DescribeSensor responses. That's the main reason for having two custom collectors for those two services, right? I would relabel those to something like this:
NDBC Observations - IOOS SOS DIF XM & csv CO-OPS Observations - IOOS SOS DIF XM & csv
But I think @dpsnowdenhttps://github.com/dpsnowden may be best suited to describe that old SOS appropriately. It's probably a somewhat sensitive topic.
I also suggest adding another entry to the list, for IOOS SWE SOS 1.0 itself. It'd be useful to add links to each of these, like you do for HADS and AWC. I'd be happy to do that myself in a pull request.
— Reply to this email directly or view it on GitHubhttps://github.com/ioos/pyoos/issues/28.
I can't get to it today either; it wouldn't be till next week.
Regarding 52N and NcSOS endpoints, in that case both really are IOOS SWE SOS 1.0, so someone coding for such endpoints would use exactly the same pyoos machinery. Maybe the way to say that in the README file is to list IOOS SWE SOS 1.0 as the "data service" supported, and say that that includes 52North and NcSOS endpoints? Or maybe this points to a slightly richer, table-like presentation that lists both the individual data service (eg, NDBC, 52North SOS endpoints) and the pyoos collector and parser used? Maybe that's too much ...
The README file lists these two collectors:
NDBC Observations - IOOS SWE SOS 1.0 CO-OPS Observations - IOOS SWE SOS 1.0
I think this is misleading. The NDBC & CO-OPS collectors are not full-blown IOOS SWE SOS 1.0 collectors. The SOS endpoints actually only provide IOOS DIF and IOOS csv GetObservation responses (and slightly different ones, at that), and quite divergent and non IOOS SWE SOS 1.0 DescribeSensor responses. That's the main reason for having two custom collectors for those two services, right? I would relabel those to something like this:
NDBC Observations - IOOS SOS DIF XM & csv CO-OPS Observations - IOOS SOS DIF XM & csv
But I think @dpsnowden may be best suited to describe that old SOS appropriately. It's probably a somewhat sensitive topic.
I also suggest adding another entry to the list, for IOOS SWE SOS 1.0 itself. It'd be useful to add links to each of these, like you do for HADS and AWC. I'd be happy to do that myself in a pull request.