catalog/timeseries handle aliases consistently

[adamkorynta]

CWMSVue queries both the catalog/timeseries and catalog/locations endpoints to build up the Time Series tab. By design it does not take into account the "aliases" list returned by catalog/location since that data is built up separately with the location groups endpoint. This has the unfortunate side-effect of RADAR CDA returning timeseries catalog rows that are aliases instead of concrete id's. This results in inconsistent row numbering in CWMSVue and inconsistent row counts as seen in the image below:

The row number is based on the row returned by the timeseries catalog BEFORE the resolution with the location catalog.

I can see a couple different solutions.

1. client side: set the row count AFTER the resolution with the location catalog.
2. server side: add a boolean parameter to catalog/ endpoints to ignoreAliases in order to minimize the amount of queried data for both timeseries and locations since CWMSVue doesn't require it (default to true for backwards compatibility?).
3. server side: make the catalog/timeseries consistent with catalog/locations by moving the alias identifier to an "aliases" JSON node under the concrete identifier.

[MikeNeilson]

catalog/locations and /timeseries are supposed to only return the concrete id's and provide the aliases in an aliases node.

I thought we had done that but maybe I only did that particular operation for the ts extents data.

so option 3 was the planned solution.

[adamkorynta]

Well that's good then, I was wondering how it would work with option 3 if the user entered an alias for the id filter and it sounds like it shouldn't!

[MikeNeilson]

.... wait. But yeah. I think for the catalog that's okay. but we should probably include a "check aliases on search" option, but it would return the original with that alias wrapped inside. But that's for a latter date.

[adamkorynta]

yeah I'm all in favor of that solution and eventual feature

[rma-rripken]

So should we remove the aliases from the return results until the include aliases option gets added? Or do we leave it as is until then?

[rma-rripken]

Related to #107

[rma-rripken]

This could probably be closed. I believe the timeseries portion of this was handled buy #1193 and the location portion #1294

[zack-rma]

Local testing suggests this has been resolved by the tickets linked above. Our internal SWT database export for testing is currently down, but further testing against it will be able to confirm this is resolved.

[zack-rma]

Further testing with the SWT database export shows this has been resolved.