tum-ens/rivus

Remove dependency to ojdo/python-tools

Closed this issue · 4 comments

ojdo commented

Similar to urbs, rivus should only depend on packages published on PyPI, not third-party code. Possible solutions:

  1. Publish the offending packages as proper packages on PyPI.
  2. Include the required function into rivus.
lnksz commented

I think a rivus intern package system for self-maintained functions offers an adequate solution for this issue.

As such rivus specific extensions can be implemented in a structured manner and the heavily used "helper/util" functions from your python-tools are at the same place where they are deployed.
I find quite a few of the helper functions rather specific to this project, so I think this maintaining / developing them together with rivus is an advantage.
See pr: #8

ojdo commented

Wow, thank you for preparing a PR to this issue! I will evaluate it closer later this week and then (probably) merge it unchanged.

Just a remark concerning the inclusion of pandashp: if you are continuing to use rivus, you might want to replace this home-grown code with the now quite mature GeoPandas. It follows the same design (special column geometry holds the geometric information, other columns are the layer's attribute table), but supports many operations (shapefile reading/writing, CRS conversion, buffering, ...).

lnksz commented

Thanks for the fast response, and sorry for the rather long pr. I have a pep8 formatter turned on so every file I open gets formatted. (maybe you can diff with - ignorewhitespace?) And I added several things at once. In the future I will try to make some more digestible PRs.

Thenks for the heads up regarding pandashp. Although I have seen thaf the existing codebase uses GeoDataFrame and the pdshp exteded DF somewhat unconsistently, I have sticked to GDF for the extended functionality and maintenance. I use pdshp for the helper funcrions like match(vertex, edge)

ojdo commented

Closed by PR #8.