Tristramg / osm4routing

Parse OpenStreetMap data for routing
GNU General Public License v3.0
109 stars 32 forks source link

Issue with edge length #15

Open kpelechrinis opened 10 years ago

kpelechrinis commented 10 years ago

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)

Tristramg commented 10 years ago

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" notifications@github.com:

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)

Reply to this email directly or view it on GitHubhttps://github.com/Tristramg/osm4routing/issues/15 .

Tristramg commented 7 years ago

Ok… 2½ years later… Sorry :/

I made a rewrite in rust, including some tests and I hope it fixes that problem. The new project is hosted at: https://github.com/Tristramg/osm4routing2