Closed kramsretlow closed 3 years ago
Done at v0.2.0 This release should make to the public Julia repo within in an hour. @kramsretlow please let me know if it works for you.
Thank you for the detailed descrption of the problem - this really helped to quickly address the issue!
@kramsretlow is all OK now? May I close the issue?
Sorry, I was away from this for a long weekend.
It works now, thank you. The two ways of getting the edges correspond for my data set.
I had a little trouble getting updated to the new version--I guess some compatibility/dependencies need to be updated?
I still have a question about the weights but maybe that's a different issue 😄
Thanks for checking, I bumped the version to v0.2.1
- should now be OK :-)
JSON compatibility seems fine, but still having a hard time getting OpenStreetMapX and OpenStreetMapXPlot to coexist. I just created a tiny pull request in OpenStreetMapXPlot.jl to bump OpenStreetMapX's version in [compat].
Cheers 🍺
Hi, does it work for you now with the new versions released week ago? Can I close the issue?
Yes it works 🍺
Hi and thanks for your work on this package. I've been getting acquainted with it the last 2 days.
Let's say my
MapData
is stored in an object namedmd
. For my data set (map of Shanghai, over 170k edges), I found thatlength(md.e) - ne(md.g)
equals 6 (rather than the zero that I expected).After looking at the offending edges I found that each edge consists of a pair of nodes with
distance(node1, node2) == 0
. I see that inparseMap.jl
the graph is created viag = LightGraphs.DiGraph(w)
, wherew
contains weights obtained by a call todistance( )
. So the edges don't get created by LightGraphs.At least this is my understanding of what's happening. It seems like a rare thing to have zero-distance edges in the OSM data, so I thought I would bring this to your attention. I don't know if it is design intent to maintain a 1:1 correspondence between
edges(md.g)
andmd.e
, but this occurrence breaks the correspondence.Thanks!