Skip to content

API changes and renaming #268

Description

@wpbonelli

4.x being a new major version, it's the right time to change any names we don't like in 3.x. Figure we should collect these cases in one place, hence this issue. Anyone reading this with a renaming idea but no edit permissions on this repo, feel free to comment and we can update the list. API change proposals beyond renaming are welcome too, but dig around here first to see if we're already thinking along similar lines.

Activity

  1. added this to the MMP milestone on Nov 8, 2025
  2. wpbonelli commented on Nov 18, 2025

    @wpbonelli
    MemberAuthor

    It occurs to me that a custom grid index (cf #207) will be a natural place for intersection functionality, since a lot of that can be conveniently exposed via xarray APIs. So there may no longer be a need for a standalone GridIntersect like flopy3 has? Just thinking out loud.

  3. dbrakenhoff commented on Nov 19, 2025

    @dbrakenhoff

    It occurs to me that a custom grid index (cf #207) will be a natural place for intersection functionality, since a lot of that can be conveniently exposed via xarray APIs. So there may no longer be a need for a standalone GridIntersect like flopy3 has? Just thinking out loud.

    I agree a lot of functionality could be handled by xarray, especially cell selection and rasterization operations. But I think for some problems you want to stay in "vector"-world as long as possible. When writing a drainage package, how do you deal with many ditches in one cell? When burning a bunch of geometries (polygons or linestrings) into the grid, how do you aggregate different elevations or different bed resistance values for different geometries that might lie within the same grid cell? Once you build a raster you effectively have to make a choice how to represent that boundary with one value for each parameter? Modflow however can deal with multiple DRNs in one cell. If you return the vector-intersection result, users can specify the aggregation (or not) themselves.

    Not sure if that means a separate class is necessary, but I think there should still be a place for vector-based intersection operations.

  4. wpbonelli commented on Nov 19, 2025

    @wpbonelli
    MemberAuthor

    Thanks @dbrakenhoff! That makes sense.

    (@mjreno and I are not too familiar with all these use cases like hardcore modelers/users of flopy are, so if you see anywhere else we are going astray, please say something. really appreciate the feedback.)

  5. locked and limited conversation to collaborators on Oct 8, 2026
  6. converted this issue into a discussion #431 on Oct 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    help wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions