joroeder
commented
3 years ago Hey, I checked the two approches in the last days in detail, so the already in DHNx existing OSM importer with the bug described in this issue, and an implementation I were using, which is doing the job (see #65).
Fixing the bug of this issue, involves in my opinion some additional effort, which is not done by a 2-liner. Some of the functions needed are already implemented in #65 . Hence, I would suggest to first finish #65 and build on these functions. Then, e.g. the OSMNetworkImporter.graph_to_component_dfs() method can be adapted quickly. I am already checking how this could work.
In this context, some other issues/questions came up regarding the OSMNetworkImporter :
- L332: Why is the crs back converted to an ellipsoidal crs here? Using a geographic CRS for calculating lengths of GeoDataFrame in an ellipsoidal crs is not supported by geopandas and results in wrong lengths.
- L326 Why is this method needed? Why not directly importing the streetsnetwork as a GeoDataFrame via osmnx import?
Has the OSMNetworkImporter so far be used in any application? ;-)
In
dhn_from_osm.connect_points_to_network: New edges are just the old edges combined with the new, connecting edges. One step needs to be added: Cutting the edges in two at the new nodes.https://github.com/oemof/DHNx/blob/dev/dhnx/dhn_from_osm.py#L82