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

Rename units to locations #349

Open
timtroendle opened this issue Apr 11, 2024 · 7 comments
Open

Rename units to locations #349

timtroendle opened this issue Apr 11, 2024 · 7 comments
Labels
enhancement New feature or request

Comments

@timtroendle
Copy link
Member

timtroendle commented Apr 11, 2024

The name units that is used heavily in the workflow stems from "administrative units". We may want to consider renaming them to locations.

These are the reasons:

  1. With eHighways being built in, not all locations are administrative.
  2. The abbreviation units for "administrative units" isn't clear and many people may not even know what it means.
  3. Calliope uses locations and we would be consistent.
  4. We already use locations in some places, leading to inconsistent code like locations = rules.units.
@timtroendle timtroendle added the enhancement New feature or request label Apr 11, 2024
@timtroendle
Copy link
Member Author

This is up for discussions. @calliope-project/euro-calliope-devs happy to hear your opinions.

@irm-codebase
Copy link
Contributor

@timtroendle I believe the preferred naming in Calliope 0.7 is nodes. So perhaps we should use that?

See: https://calliope.readthedocs.io/en/latest/math/base/

@jnnr
Copy link
Contributor

jnnr commented Apr 12, 2024

I agree that a consistent naming will help. However, 'node' is a graph theory term and doesn't really fit in the context geospatial data processing of euro-calliope, in my view. I propose either regions or spatial_units, which were both terms we used consistently in our sprint week spatial resolution team.

@sjpfenninger
Copy link
Member

As of Calliope 0.7 we do use nodes inside Calliope itself, not locations. But perhaps using locations in the euro-calliope processing chain all the way up to the end, where the Calliope model is built (where nodes will then be mandatory), helps clearly separate the data processing from the model building.

@jnnr
Copy link
Contributor

jnnr commented Apr 16, 2024

Distinguishing the nodes of the calliope model from the regions in the data pipeline makes sense. Still, I'd favor regions or spatial_units. A location commonly refers to a point, but what is now called units are not points, but polygons with an extension.

@brynpickering
Copy link
Member

regions has the problem of possibly being mixed up with the regional resolution of the model. spatial_units could work. There's also zones and geometries

@irm-codebase
Copy link
Contributor

How about shapes? It's shorter than geometries / spatial_units, avoids confusion with other model functions, and is a bit clearer than zones (imo).

  • national_shapes
  • regional_shapes
  • continental_shapes
  • ehighway_shapes
  • etc...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants