t-ott/stormcatchments

Stormwater network aware catchment delineation

stormcatchments's Issues

Move all random print statements, and some warnings to the logging module

Use logging instead of random printing. The network module in particular could benefit from this, and various debug logs could make fixing problems easier

Publish to conda-forge

Read the docs failing to apply autodoc

See recent Read the Docs build information

Have ```topology.find_multi_outlet``` return ```MultiLineString``` geometries

One MultiLineString per multi-outlet network component/subgraph seems more intuitive

Utilize ```isinstance()```

Or type(x) is int sort of statements. See https://stackoverflow.com/questions/152580/whats-the-canonical-way-to-check-for-type-in-python

Make ```Network``` and ```Delineate``` accessible from the top level module

Want to do:

import stormcatchments as sc
net = sc.Network(params)

instead of current implementation:

net = sc.network.Network(params)

On pip install the ```tests``` directory is added to env's sitepackages

Probably don't want this to happen. Something in the setup.py needs to change probably, or tests should be added as a subdirectory of stormcatchments?

Formalize documentation with Sphinx or similar

Allow for line-only network initialization

In the case of line (pipe) data that has vertex order that corresponds to flow direction, you may not need to any point data. You would have to make one of two assumptions about the line data without points, though. Either:

1. Every first vertex / root node on each line is a flow sink. For example, typical culverts where flow enters on one end, and travels out the flow source on the other end.
2. Every vertex on each line is a flow sink, except leaf nodes. This would be applicable to line data that has some sort of catchbasin/drop inlet on each vertex.
3. If neither of these two assumptions are correct for a given directioned line dataset, the user would have to provide some sort of point data to represent where flow can (or cannot) enter subsurface networks.

One relatively easy way to implement this is to initialize a Network with lines only, then write some function to create points at every vertex in the line data, using one of the two methods described above.

Better to resolve edge directions as-needed or during initialization?

One option is to initialize Network.G with bidirectional edges, then have an additional user method call such as net.resolve_directions() that modifies the object and does that work once, then switch a boolean attribute to mark that as complete. Then when delineating stormcatchments, check to ensure directions have been resolved first.

Add network plot to example usage in README

Make a call to net.draw() to demonstrate plotting capability

Change initialization of flow sinks and sources

Force user to supply bool columns for IS_SOURCE and IS_SINK. Could also allow user to change these default columns names to something else too, if desired. This should make Network initialization clearer. If the user hasn't mapped out two bool columns yet, they can do so with a quick .apply(), e.g., what's currently done here:

self.pts['IS_SINK'] = self.pts[type_column].apply(
    lambda x: True if x in sink_types else False
)
self.pts['IS_SOURCE'] = self.pts[type_column].apply(
    lambda x: True if x in source_types else False
)

Maybe these could be included as helper functions, but having multiple ways to initialize sinks/sources is a bit confusing.

Move constants to a ```constants.py``` file

Such as SINK_TYPES_VT and SOURCE_TYPES_VT, then can access those constants when initializing a Network with something like:

...
from . import constants
...
net = network.Network(lines, points, sink_types=constants.SINK_TYPES_VT, source_types=constants.SOURCE_TYPES_VT)

And change the parameters sink_types and source_types to optional params. If default None, then check to make sure there's appropriate bool columns in the input data already.

Add a quickstart to the docs

Make ```get_catchment()``` a module-level function rather than part of the ```Delineate``` class

Then just make calls to get_catchment() from within Delineate. This would be helpful so user doesn't have to have an instance of Network in order to utilize get_catchment()

Provide some basic examples with notebooks

In an examples or tutorials directory in root

DEM pre-processing triggers ```pyproj.exceptions.ProjError```

For example see recent failed workflow runs

Generate reporting for network direction resolution

Reports could be printed to std out or to separate file? Could include info related to:

• How many outfalls/source points were resolved
• How many edges were successfully resolved and how many edges failed to resolve
• If any sections of the network do not have a outfall/source point