[WIP] Overhaul symbology schema and menus

[mfisher87]

Description

The functionality we offer in the symbology menu has diverged from the schema. For example, we now offer the ability to set render type for color and radius independently, and the schema doesn't support that yet.

We also recognized that having a heatmap layer type is a mismatched abstraction; it should just be a render type. We're planning to remove that layer type in this PR as well.

TODO:

• Implement separate schemas for color and size
• Update symbology panel
  • Separate color and size tabs into different react components with separate state
• Update QGIS import/export
• Raise error when opening outdated schema (e.g. implement a global variable e.g. SUPPORTED_SCHEMA_BOUNDS = ["0.6.0", "*"] and raise error if the project file's schema version is outside the bounds)
• Update example project files
• Update Python API
  • create_color_expr -- rethink the API from scratch maybe? Make a Symbology class? Use generated class from the schema?
  • Remove add_heatmap_layer

Checklist

• PR has a descriptive title and content.
• PR description contains references to any issues the PR resolves, e.g. Resolves #XXX.
• PR has one of the labels: documentation, bug, enhancement, feature, maintenance
• Checks are passing.
  Failing lint checks can be resolved with:
  • pre-commit run --all-files
  • jlpm run lint

[github-actions]

👈 Launch a Binder on branch mfisher87/jupytergis/symbology-overhaul

[mfisher87]

@martinRenou @arjxn-py @gjmooney I'd love to hear anyone's thoughts about what I'm doing in c6af37c. Read the commit message for context. It's not ideal, but I believe it's a necessary cost to using our code generation tools.

This will enable us to extract common field definitions into separate files that can be shared between schemas.

This presents a new problem, however; the TypeScript type generation dereferences schemas instead of importing from referenced schemas. So when we include references, we render both the referenced schema and also render the same schema within schemas that reference it. So when we attempt to import those referenced schemas in packages/schema/src/types.ts, we import the same name twice and produce an error. I'm not sure yet how to work around this...

Having different code generation tools which expect different things and have different output behaviors is very difficult to reason about!

[mfisher87]

I wanted to use this for form generation, but it's also affecting type generation.