You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 9, 2024. It is now read-only.
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:
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:
Thank you for this detailed analysis. I hope I'll find the time soon to
look into it
Am 27.05.2014 23:40 schrieb "kpelechrinis" [email protected]:
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:
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:
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: