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

[WIP] Simplify Graph #58

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
Open

Conversation

rush42
Copy link

@rush42 rush42 commented Jan 3, 2022

This PR implements an algorithm for simplifying the topology of an OSMGraph object.
It is adapted from osmnx.

This PR is work in progress, and a few issues have to be discussed.

TODO:

  1. the output format of the simplification procedure (rn it returns a DiGraph and two DataFrames: one for nodes and the other for edges (which also contains the edge geometry) )
  2. reference to the original OSM objects (an edge can consist of serveral ways)
  3. turn restrictions
  4. type stability and code generalization for types

Below is an example for Tiergarten district in Mitte, Berlin, Germany:

Before the simplification:
nodes: 2976,
egdes: 4727
before

After the simplification:
nodes: 683,
edges: 1384
after

I will upload an example script the following days.

@mmiller-max
Copy link
Contributor

This is a great idea, thanks for working on it. Concerning your TODOs:

  1. the output format of the simplification procedure (rn it returns a DiGraph and two DataFrames: one for nodes and the other for edges (which also contains the edge geometry) )
  2. reference to the original OSM objects (an edge can consist of serveral ways)

I think it should return something like SimplifiedOSMGraph where the graph type and other parametric types match that of the input OSMGraph. This simplified graph could then contain then mapping between the original and new edge IDs. We could add something that gets the way IDs from the new edge IDs too.

We could add a parent type to SimplifiedOSMGraph and OSMGraph for the functions with which either graph works.

Ideally the NodeIDs should be the same as then we can use all the additional OSM data for them - are they?

  1. turn restrictions

Yep this is pretty important, but hopefully just a small extension to what you've got already.

  1. type stability and code generalization for types

Does my answer to 1 above remove all the instabilities, or do other functions need improving as well?

weight = Vector{eltype(osmg.weights)}(),
geom = IGeometry[],
)
node_gdf = DataFrame(id = Int[], geom = IGeometry[])
Copy link
Contributor

Choose a reason for hiding this comment

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

Am I correct in thinking that the use of IGeometry, createpoint and createlinestring are not necessary for the graph reduction, they just give more meta data? If that's the case then I don't think they should be here. They could perhaps be added in new functions for all OSMGraphs.

Copy link
Author

Choose a reason for hiding this comment

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

I think it should return something like SimplifiedOSMGraph where the graph type and other parametric types match that of the input OSMGraph.

Yes, adding a dedicated type is probably necessary .

If that's the case then I don't think they should be here. They could perhaps be added in new functions for all OSMGraphs.

I would also prefer to keep the geometric types out, so one can decide on their own which library to use.

When the SimplifiedOSMGraph keeps a reference to the parent, it would even be sufficient to just store a list of all the interstitial NodeIDs from the original graph for every new edge.
Generating the geometries could then be achieved by indexing OSMG.node_coordinates with that list

IMHO that would also solve most issues related to TODO 2 and 3.

They could perhaps be added in new functions for all OSMGraphs

Agree, I already implemented two function generating something similar for plotting with Plots.jl . I'll upload them together with the example script.

I'll keep you updated about further ideas!

@rush42 rush42 changed the title WIP: Simplify Graph [WIP] Simplify Graph Jan 7, 2022
@rush42
Copy link
Author

rush42 commented Jan 7, 2022

I added the SimplifiedOSMGraph type and methods for generating "GeoDataFrames" either from OSMGraph or SimplifiedOSMGraph objects. Additional I added a small PlotRecipe for visualization.

The example below makes use of the above mentioned methods and was mainly for checking if every thing looks correct.

using LightOSM, Plots

g = graph_from_download(
    :place_name, 
    place_name="tiergarten, berlin germany",
    network_type=:bike
)
sg = simplify_graph(g)

# check for missing edges
plot(g, color=:red, linewidth=0.8)
plot!(edge_gdf(sg).geom, linewidth=1.1, color=:black)
savefig("edge_validation")

# show original nodes
plot(sg)
plot!(node_gdf(g).geom, color=:red, markersize=2.2)
savefig("original_nodes")

# show relevant nodes
plot(sg)
plot!(node_gdf(sg).geom, color=:green, markersize=2.2)
savefig("relevant_nodes")

Output:

this should only show black edges:
edge_validation

original nodes:
original_nodes

relevant noes:
relevant_nodes

I will write some tests when I'll find the time to check if the topology is preserved correctly and if the weights are correct.

@mmiller-max
Copy link
Contributor

Hey sorry for the delay, will try to review soon. It'd also be good for @captchanjack to take a look at this as it's a relatively big addition and I'm keen to know how it fits in with his thoughts for the package.

@mmiller-max
Copy link
Contributor

It would be helpful to fix the merge conflicts via a rebase or merge - in particular the renaming of the field highway to way should be observed in the new graph. Once the conflicts are sorted I can kick off CI, it seems that GitHub won't let me do it before then.

@rush42
Copy link
Author

rush42 commented Jan 12, 2022

I've merged the changes, and added the edge_to_way dict to simplifiedOSMGraph.

@mmiller-max
Copy link
Contributor

@rush42 Just wanted to say sorry we haven't got around to reviewing this yet. Hopefully someone will be able to soon!

@ctlbau
Copy link

ctlbau commented May 9, 2023

Awesome PR! will this be merged soon? I've tried using as is but cannot get shortest_path calculations from SimplifiedOSMGraph

@rush42
Copy link
Author

rush42 commented Mar 25, 2024

@ctrebbau yes I haven't worked on the shortest path algorithms yet. And right now I can't find the time to do so. IMO it's the only thing missing, the rest should be implemented...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants