tests for elements, variometers, and observatories

@swilbur @erigler

These are very straightforward tests around checking the response formats for /elements/, /variometers/, and /observatories/ because these are all pretty static and don't change much.

I'm curious about some behavior I'm seeing and I'd love further insight if possible.

1. Why is "geometry" always set to None on elements? elements.py
2. Why do all of these resources get returned as an object with fields type and features instead of just as a list of resources? elements, observatories, variometers
3. Why the choice to transform the static data instead of returning the static data as it's stored in the files? Similarly, why nest most of the info under "metadata"?
4. Why aren't there separate classes for Observatories and Variometers?
5. Why are the /variometers/ endpoints methods called get_observatories or get_observatories_by_id?

added 1 commit

• 83a9d5b5 - linted

Compare with previous version

changed the description

marked this merge request as ready

changed title from Draft: wrote some tests for elements, variometers, and observatories to tests for elements, variometers, and observatories

There is a lot of wrapped up in your initial questions. I'll attempt a high-level (and non-exhaustive) explanation here, but we might want to get on a call to discuss the details.

1. The resources mentioned (/ws/elements, /ws/variometers, and /ws/observatories) were all implemented, originally, to support the /plots application. Basically, they tell /plots what station IDs and elements are valid to request.
2. These metadata are hard-coded for now, but there have been discussions of tying these to observatory category metadata stored in our mysql database. There is potentially a lot more information that could be stored in these metadata if/when we do this.
3. Variometer metadata is actually pulled from IRIS/Earthscope servers as station.xml. Station.xml is not (yet) fully compatible with our internal metadata "standard", although there have been preliminary discussions on how to address this as well.

@swilbur might be able to fill in a few of the implementation details, but I'll say that streamlining some of this is exactly what we hoped you will be able to help us with on our "backend" (not all in this MR obviously), so a longer dedicated conversation seems worthwhile at some point.

I added some specific comments to the new unit tests. Nothing major. I expect many of these things to become obsolete if/when we transition to using mysql to store these metadata, rather than hard-coding them.

requested changes

added 26 commits

• 83a9d5b5...a4f37d3b - 23 commits from branch ghsc/geomag:master
• 2ee49ffc - Merge branch 'master' into elements-tests
• 9bd1f7a6 - requested mr changes
• 9a2e540b - Merge branch 'master' into elements-tests

Compare with previous version

added 1 commit

• db903c8f - update variometer tests

Compare with previous version

added 1 commit

• 496fa504 - remove length check in variometers

Compare with previous version

approved this merge request

resolved all threads

mentioned in commit aad49ab8

merged