-
Notifications
You must be signed in to change notification settings - Fork 32
Issue with edge length #15
Comments
Thank you for this detailed analysis. I hope I'll find the time soon to
|
Ok… 2½ years later… Sorry :/ I made a rewrite in rust, including some tests and I hope it fixes that problem. |
I have noticed some discrepancies in the length field for the edges. For example, using the osm file for the metro extract in Philadelphia, after running osm4routing I obtain an edge:
27479,103404237,103464947,2938.484375,2,2,2,2,1,LINESTRING(-75.07271 39.947871,-75.072908 39.948641)
This edge/street segment is clearly not 2938 meters long but it is rather 106m. You can verify this by computing the distance between the endpoints in the linestring (the geometry of the segment is almost straight line) or even using google maps. I tried to see where osm4routing computes the length value, but it seems to me that it is obtained directly from OSM files (?). I used geopy to compute the sum of the distances between the consecutive lon/lat pairs in the linestring and it provides similar results to the ones from google maps. In general there are about 370 edges in this extract that have a discrepancy more than 200m. This is not a very large number but I was just wondering how the length field is computed.
Some sample edges from the same extract whose lengths do not match are:
248015,103806097,103806091,1949.47668457,1,1,2,2,1,LINESTRING(-75.0763714 39.7955654,-75.0765007 39.7954224,-75.0756424 39.7950267,-75.0755439 39.7951148)
258393,2041335487,2041335442,843.953125,1,1,2,2,1,LINESTRING(-74.6733995 40.0801822,-74.6734609 40.0798729,-74.6734263 40.0796937,-74.6733569 40.0795544,-74.6732268 40.0794283,-74.6730621 40.0793355,-74.6727152 40.0791762,-74.6724638 40.0789971,-74.6724118 40.0788843,-74.672299 40.0787383,-74.6720823 40.0785857,-74.6714493 40.0783204)
The text was updated successfully, but these errors were encountered: