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
getNearestEdges descents in an rtree depending on the size of the network until the "viewDist" is reached (line 92). The number 10 is suitable, if the net-size is given in meters. When using wgs84 coordinates the size is given in radiants. Ths makes the loop aboard and no edges are found.
Proposed fix: compute the size of the network in meters.
The text was updated successfully, but these errors were encountered:
Hello @MHeinrichs ,
thank you for reporting this bug. Indeed, there is an issue in mixing geodetic and projected metrics [as parts of the application (eg.: nearest edge finder) do expect] and we are working on it. We consider your proposal and weight it against the opposite approach as in transforming the treshhold into degrees. The latter approach though results into some (more or less considerable) inconsistencies in large spatially expanding networks.
As a workaround you can specifiy a metric coordinate system by using the "--epsg 25833" flag at command line level when starting the application.
getNearestEdges descents in an rtree depending on the size of the network until the "viewDist" is reached (line 92). The number 10 is suitable, if the net-size is given in meters. When using wgs84 coordinates the size is given in radiants. Ths makes the loop aboard and no edges are found.
Proposed fix: compute the size of the network in meters.
The text was updated successfully, but these errors were encountered: