considered using GeoPandas for spatial functions?

[jsadler2]

Hi again @aerispaha,
I was just using this very useful library again and had a question for you. I want to write my nodes and conduits into a shapefile. I used your spatial.py function write_shapefile and that worked, but the datatypes in the dataframe didn't transfer. Everything came across as a string. Have you thought about using Geopandas for this instead of the shapefile library? It seems like a nice fit since you are using Pandas dataframes already (which I love, btw). It also carries the datatypes into the shapefile. I'm happy to code this up and submit a PR if you think it's a good change.

[aerispaha]

@jsadler2, you are speaking my language! GeoPandas is awesome. I didn't include it originally when I started writing swmmio because I just didn't know about it.

That said, I do have some concerns with depending on GeoPandas. Mostly, I have had a LOT of trouble getting GeoPandas to install nicely on machines that also have ArcMap installed. If we can chart of way of doing this with GeoPandas being an optional dependency, or if we can make the install process very clear (perhaps via conda), I would be on board.

I'm working on another package, sewergraph, that will ultimately depend on GeoPandas. I'm rewriting that in the style of osmnx which is a super nice package that uses GeoPandas. So I'm definitely sold on the merits of GeoPandas, we just have to cognizant of some of swmmio's users that may also have ArcMap installed.

[jsadler2]

@aerispaha, I have ArcGIS installed on my machine and don't recall any problems install geopandas. I may have forgotten though or just got lucky. What are the common problems? Does it have to do with GDAL?

[aerispaha]

@jsadler2, I'm still open to the idea of leveraging GeoPandas for spatial functions. However, as maybe a less dependency-heavy alternative in the meantime, what do you think about fleshing out the write_geojson() concept such that we can read an inp file and return the entire model serialized in geojson?

I like that because it's flexible and human readable, and it also could play nice with GeoPandas and other spatial packages.

[jsadler2]

Way late to the party -- I like this idea. Much more open than shapefile. Are you still working on this?

[aerispaha]

Hey @jsadler2, I am still working on this but I haven't started implementing yet. Any ideas on how to do it cleanly?

One thing I'm unsure of is how much (and which) data to include as properties (and columns in dataframes) by default. For example, the model.conduits() dataframe joins data from several other sections of the inp and rpt files by default. But a lot of that may not be necessary by default and may make things overly cluttered (related to #36).

I think we should close this issue for now and continue the geojson implementation discussion over at #31.

[jsadler2]

Yeah. I see what you mean. I can see use cases where you would want all the properties, but I think the default should be simpler and limited to more "spatially-oriented" properties. Maybe for nodes it could be just ["name" (obviously), "elevation", and "maxdepth"] and for conduits just ["name"]?

…

On Tue, Oct 23, 2018 at 2:31 PM Adam Erispaha ***@***.***> wrote: Hey @jsadler2 <https://github.com/jsadler2>, I am still working on this but I haven't started implementing yet. Any ideas on how to do it cleanly? One thing I'm unsure of is how much (and which) data to include as properties (and columns in dataframes) by default. For example, the model.conduits() dataframe joins data from several other sections of the inp and rpt files by default. But a lot of that may not be necessary by default and may make things overly cluttered (related to #36 <#36>). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGny0WfjLzMZnzL-J0JIWATsqYRES8_Mks5un2BxgaJpZM4RU46H> .

[aerispaha]

Continue geojson discussion in #31