Skip to content
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

parenx & osmnx methods & data; evaluation WIP #201

Merged
merged 19 commits into from
Dec 3, 2024
Merged

parenx & osmnx methods & data; evaluation WIP #201

merged 19 commits into from
Dec 3, 2024

Conversation

anastassiavybornova
Copy link
Collaborator

@anastassiavybornova anastassiavybornova commented Dec 2, 2024

this PR contains

  • updated methods notebook for osmnx: node consolidation with default param of 10m, then dropping multiedges)
  • updated methods notebook for parenx incl. terminal output of cli run
  • data (results for all 6 fuas) for osmnx and parenx
  • added read-in functions to utils for sgeop and parenx
  • adjusted parenx folder structure (to mirror rest of output folders, we now have 2 folders: parenx-voronoi and parenx-skeletonize, which each contain {fua}.parquet file)
  • lastly: WIP evaluation notebook in evaluation

this resolves:

& xref (wip) #200

@anastassiavybornova
Copy link
Collaborator Author

question: we now have a lot of different read-in funcs in utils, only one of those using .explode() on the gdf before returning it, would it make sense to have this as standard (cause it won't hurt?? or will it?) for all read-in funcs, or is there a specific reason why we only added it for the utils.read_manual() one?

@jGaboardi
Copy link
Collaborator

jGaboardi commented Dec 2, 2024

question: we now have a lot of different read-in funcs in utils, only one of those using .explode() on the gdf before returning it, would it make sense to have this as standard (cause it won't hurt?? or will it?) for all read-in funcs, or is there a specific reason why we only added it for the utils.read_manual() one?

Good question.

Some background:

Can't at all remember why explode is needed in the manual one...

@jGaboardi
Copy link
Collaborator

would it make sense to have this as standard

I think it would surely make sense to have fewer lines of code. And probably very doable with some minor refactoring.

Copy link
Collaborator

@jGaboardi jGaboardi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To resolve the failures you'll need to update test_utils.test_read_parenex().

@anastassiavybornova
Copy link
Collaborator Author

anastassiavybornova commented Dec 3, 2024

@jGaboardi i've updated the tests, lmk what you think! the parenx_voronoi and parenx_skeletonize ones can probably be merged (DRY), i was just not sure how to pass 2 zipped and 1 non-zipped parameter to the pytest.mark.parametrize

@jGaboardi
Copy link
Collaborator

@jGaboardi i've updated the tests, lmk what you think! the parenx_voronoi and parenx_skeletonize ones can probably be merged (DRY), i was just not sure how to pass 2 zipped and 1 non-zipped parameter to the pytest.mark.parametrize

All good. Nice work on this!

@jGaboardi jGaboardi merged commit 8ab4a54 into main Dec 3, 2024
2 checks passed
@jGaboardi jGaboardi deleted the parenx-data branch December 3, 2024 15:23
@martinfleis martinfleis restored the parenx-data branch December 3, 2024 15:26
@martinfleis martinfleis deleted the parenx-data branch December 3, 2024 15:26
This was referenced Dec 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants