-
Notifications
You must be signed in to change notification settings - Fork 58
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
ENH: helper functions for geometry-based network simplification #396
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #396 +/- ##
=======================================
- Coverage 95.9% 93.7% -2.2%
=======================================
Files 13 13
Lines 2965 3041 +76
=======================================
+ Hits 2842 2849 +7
- Misses 123 192 +69
|
@gregmaya what is the state of this and a tentative timeline? |
Hey Martin. Thanks for reaching out. |
One more ping @gregmaya :). |
@martinfleis I feel very sorry that I've not been able to contribute more to this. As a matter of fact, my coding skills have probably suffered some rustiness as I've not been doing much coding in the last couple of months. However, as part of my 2023 resolutions, I wanted to resurface this as a priority. So I have given one day a week (most likely Tuesdays) to continue with these functions... If I'm not wrong my last blocking was trying to generate the number of forming edges to each of the polygons. Ideally, this could also be used in the selection of polygons that are adjacent to roundabouts (as discussed last year). I don't seem to remember exactly the cases where I was getting an error but I'll try to replicate it and come back to you. I should be back online from the 11th Jan. |
Hi @martinfleis and @jGaboardi. I have to admit that from the round_about_simplification() only one thing I ended up not very happy with: the way we were selecting the 'adjacent polygons' ... the ideal would be to select those on the basis of forming edges (not on their area-like it currently is). I have now developed that function. I know this might feel like going backwards but believe this is pivotal to moving forward because adding that attribute to the polygons_gdf would allow us to select the single_tri_like_junctions (and potentially many more). see this for reference. but let me know which way you think is best to proceed. i.e. maybe a new branch? the current one is very much out of date and is giving me many import warnings on most of the main libraries 🧐 |
Okay, that is fine.
Make a branch for every contribution that will turn into a PR. You can also update this one but given the scope will change, it may be better to close it and open new, narrower ones. |
OK brill. |
Closing does not mean it goes anywhere, you will still see all you can now. It will just be clearly marked as not expected to be merged. |
This is not happening anytime soon. Closing to clear the backlog. @gregmaya note that there's an ongoing effort to develop a new simplification algo so it may be eventually all superseded by that. |
Makes sense to close for backlog clarity Would love to see what the thinking around simplification is now. Also, if there's room for me to collaborate, would love to participate! |
I wanted to leave this PR open to be able to refer to it in my GSOC README.
I know there are quite a few things still to be done here so might be worth holding back a very thorough review