search

USSPegasus / monav

Automatically exported from code.google.com/p/monav
0 stars 0 forks source link

MoNav finds much longer route than necessary #44

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?

1. On N900 use Marble application with MoNav backend
2. Ask (MoNav) for route from 14° 12' 26.8" E, 50° 01' 19.1" N
   to 14° 12' 21.0" E, 50° 01' 27.1" N

What is the expected output? What do you see instead?

The correct way is a few meters straight ahead through one nearest crossing.
But MoNav finds complicated 15.3 km long way instead. This does not seem like 
OSM data bug, because http://www.yournavigation.org/ finds correct way.
Also I used Google maps to verify coordinates: both E 14 12 26.8 N 50 01 19.1 
and E 14 12 21.0  N 50 01 27.1 are correct. Does MoNav treat the crossing 
between points as been disconnected?

What version of the product are you using? On what operating system?

Nokia N900, OSMaemo5 PR1.3
Marble 1.0.1 with MoNav backend: monav-routing-daemon 0.2.release-2 
(extras-testing)
MoNav data for Czech Republic (motorcar) updated 2011-04-04.

Original issue reported on code.google.com by r0pol...@gmail.com on 4 Apr 2011 at 8:50

GoogleCodeExporter commented 8 years ago 
It seems to me, that your target lies on the opposite side of the street and 
the calculated route has to reach the target from the opposite direction. If 
you take a look at the attached image you can see, that the way is split into 
two different ways. Could you try setting your target a bit to the right?

Original comment by veaac.fd...@gmail.com on 6 Apr 2011 at 9:53

Attachments:

GoogleCodeExporter commented 8 years ago

Original comment by veaac.fd...@gmail.com on 6 Apr 2011 at 9:53

GoogleCodeExporter commented 8 years ago 
I tried to move target to be clearly on the right side, but it does not help.

Also when I moved target to the highway (about 100 to the north) - to the 
correct direction (ie. north-east), MoNav still finds incredible long route 
(and it ends
in right direction so the problem is not because of two parallel roads in 
opposite direction)

Original comment by r0pol...@gmail.com on 7 Apr 2011 at 9:21

GoogleCodeExporter commented 8 years ago 
Could you please post a screenshot of the route monav finds? On you n900 you 
can use STRG+SHIFT+P to make a screenshot.

Original comment by veaac.fd...@gmail.com on 8 Apr 2011 at 7:17

GoogleCodeExporter commented 8 years ago 
Here are requested screenshots - in different zoom levels.

Original comment by r0pol...@gmail.com on 8 Apr 2011 at 4:42

Attachments:

GoogleCodeExporter commented 8 years ago 
http://www.yournavigation.org/
gives this result:

Original comment by r0pol...@gmail.com on 8 Apr 2011 at 4:49

Attachments:

GoogleCodeExporter commented 8 years ago 
Ok, it seems it is an error with OpenStreetMap data. One part of the highway is 
used in both directions and has not "oneway=yes" as a flag. Nevertheless, the 
wiki states, that highways are implicitly oneway. This means MoNav is actually 
correct.

I am not sure what to do about such cases. If I fix them in MoNav they do not 
get fixed in OSM. If I don't fix them a lot of people might complain

Original comment by veaac.fd...@gmail.com on 11 Apr 2011 at 3:29

Attachments:

GoogleCodeExporter commented 8 years ago

Original comment by veaac.fd...@gmail.com on 12 Apr 2011 at 5:45

GoogleCodeExporter commented 8 years ago 
Actually I might fix this in the future when handling implied tags correctly.

Original comment by veaac.fd...@gmail.com on 12 Apr 2011 at 6:15

GoogleCodeExporter commented 8 years ago 
When I tried these two cases of routes (see next two screenshots),
I thing the problem is not in blue-marked line but in red-market line.

Original comment by r0pol...@gmail.com on 13 Apr 2011 at 8:14

Attachments:

GoogleCodeExporter commented 8 years ago 
http://openrouteservice.org/index.php?start=14.2059738,50.0240529&end=14.206877,
50.0250947&pref=Fastest&lang=de&noMotorways=false&noTollways=false
shows the correct route although.

And also when I checked one-way/two-way properties of segments
in the editor, it seems to me correctly set (although I eventually might not
see what value is implied or explicit):

Original comment by r0pol...@gmail.com on 13 Apr 2011 at 8:19

Attachments:

GoogleCodeExporter commented 8 years ago 
Your first example looks like the target is actually on the wrong lane. 
Nevertheless I will have a closer look at this.

Could you point me to where i can download the monav routing module used in 
your case?

Original comment by veaac.fd...@gmail.com on 13 Apr 2011 at 8:21

GoogleCodeExporter commented 8 years ago 
And your second example works only because monav starts routing from the next 
possible routing nodes, one of which is past the segment with oneyway=no".

The problem is, that monav currently assumes that a motorway is implicitly 
always oneway, whatever the oneway tag actually specifies.

I will fix it in 0.3.x, but not for the 0.3 release. I wanted to implement 
proper implied tags anyway.

Original comment by veaac.fd...@gmail.com on 13 Apr 2011 at 8:26

GoogleCodeExporter commented 8 years ago 
monav I use on N900 is the monav-routing-daemon from extras-testing maemo 
repository:
http://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_ar
mel/monav-routing-daemon/0.2.release-2/
with source 
http://maemo.org/packages/source/view/fremantle_extras-testing_free_source/monav
/0.2.release-2/

I tried also one more route test on another part of the (same) road on which 
can be more clearly seen both opposite ways: It seems to me that monav "does 
not know" about this way:

Original comment by r0pol...@gmail.com on 13 Apr 2011 at 10:36

Attachments:

GoogleCodeExporter commented 8 years ago 
Maybe the street was not in the data set when it was generated. I will download 
the map data and take a look at it, but not before the weekend.

Original comment by veaac.fd...@gmail.com on 14 Apr 2011 at 7:19