Skip to content
This repository has been archived by the owner on Jan 9, 2024. It is now read-only.

Issue with edge length #15

Open
kpelechrinis opened this issue May 27, 2014 · 2 comments
Open

Issue with edge length #15

kpelechrinis opened this issue May 27, 2014 · 2 comments

Comments

@kpelechrinis
Copy link

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
Copy link
Owner

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//issues/15
.

@Tristramg
Copy link
Owner

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants