Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backward Compatibility Broken for V1 API #3

Open
rhodges opened this issue Dec 6, 2024 · 0 comments
Open

Backward Compatibility Broken for V1 API #3

rhodges opened this issue Dec 6, 2024 · 0 comments

Comments

@rhodges
Copy link
Member

rhodges commented Dec 6, 2024

Reference: v1 API documentation

The required requests for populating layer pickers using V1 are not providing any information below 'level 3' in the hierarchy.

The API calls in question:

get_themes

This API call may be functioning correctly - all it needs to do it get the "top-level" themes.

Testing:

  • Open the sandbox mapping page
  • Record the available layers and order (16 themes -- result of call to /layers/top_level_themes/ ):
    • What's New
    • Feature Service Test
    • Components of Ecological Richness
    • Administrative
    • Marine Life
    • Renewable Energy
    • Fishing
    • Human Use Data Synthesis
    • Marine Life Library
    • Maritime
    • Oceanography (BETA)
    • Recreation
    • Security
    • Fishing - Communities at Sea (by Port)
    • Fishing (JO)
    • Fishing (KV)
  • Next, test against call to /data_manager/get_themes (24 responses, but 8 have is_visible: false, so 16 total):
    • [I think this is right, ran out of time to double check]

get_layers_for_theme

This is where things are really wrong. It works great for the old data because the old data stayed flat to support the old limitations. Now that we've populated new theme/layer hierarchies to go deeper, the back end needs to stretch itself to convert the new schema into something compliant with the old. This does NOT just mean stopping after the third tier of the hierarchy. Instead:

  • The top theme should be preserved (so it will look nice)
  • The first subtheme or any 'second-level' layers should be left intact (as parent layer or just layer, respectively)
  • The third level will be comprised of EVERY layer that could be accessed by the v2 hierarchy, squashing it so each parent 'theme' not represented in the first two levels becomes part of the layer's name:
    • If in your v2 hierarchy you have a Theme A (1st level) has subtheme B (2nd) which has a subtheme C (3rd) which has a layer X, then your v1 hierarchy will look like:
      • A (theme)
        • B (parent layer)
          • C | X (child layer)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant