Custom Query (1067 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (37 - 39 of 1067)

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Ticket Resolution Summary Owner Reporter
#1299 fixed Ubuntu PPA with daily svn snapshot cp15 tobe deprez
Description I made a PPA on launchpad with daily builds of SVN snapshots of navit (see https://launchpad.net/~supertux-dev/+archive/ubuntu/daily). It would be nice if you could refer to this PPA on your download page.
#1297 fixed Navit process does not exit cleanly on Android, causing issues on relaunch cp15 mvglasow (2)
Description It appears that under certain circumstances Navit does not exit cleanly on Android. When launching Navit again, the old process is re-used and the screen does not update correctly. Input is, however, processed correctly.

To reproduce (tested with r6087 as well with several highfive builds):

1. Make sure you are using the default navit.xml (not a customized one).
1. Launch Navit and tap the screen to go to the menu.
a. Select ''Actions > Town''. The ''Town'' dialog should appear.
a. Select ''Back to map'' (globe icon). Navit should return to the map.
a. Return to the menu and select ''Quit''.
1. Launch Navit again.
a. Select ''Actions > Town''. The screen will appear frozen, with the ''Town'' entry highlighted.
a. Select ''Back to map'' (globe icon). You will now see the ''Town'' dialog.
a. Tap anywhere near the middle of the screen. You will see the main menu.
1. Kill Navit (by long-pressing Back, if enabled in Developer options, or through App settings).
1. Relaunch Navit and repeat everything underneath step 2. You will see correct behavior again.

A logcat clearly shows that between tapping ''Quit'' and relaunching Navit, the same process ID is used across both instances.

This might be the explanation for #974.

On highfive, I have noticed that the following lines in my navit.xml will prevent this issue from occurring:
{{{
<osd name="profile" enabled="yes" type="button" x="192" y="-222" w="144" h="144" command='
vehicle.profilename=(
vehicle.profilename=="car"?"bike":
(vehicle.profilename=="bike"?"pedestrian":
"car"));
osd[@name=="profile"].src=
(vehicle.profilename=="car" || vehicle.profilename=="bike" || vehicle.profilename=="pedestrian")?"/sdcard/navit/osd/profile_"+vehicle.profilename+"_xxhdpi.png":"/sdcard/navit/osd/profile_unknown_xxhdpi.png"
' src="/sdcard/navit/osd/profile_unknown_xxhdpi.png"/>

<osd name="my_osd_cmdif_2" h="1" w="1" update_period="2" enabled="yes" type="cmd_interface" x="22" y="832" background_color="#00000000" command='
osd[@name=="profile"].src=
(vehicle.profilename=="car" || vehicle.profilename=="car_avoid_tolls" || vehicle.profilename=="bike" || vehicle.profilename=="pedestrian" || vehicle.profilename=="horse" || vehicle.profilename=="Truck")?"/sdcard/navit/osd/profile_"+vehicle.profilename+"_xxhdpi.png":"/sdcard/navit/osd/profile_unknown_xxhdpi.png"
'/>
}}}

(My intention was to have an OSD button to switch vehicle profiles, though that never worked as intended.)

With these lines in place, Navit exits correctly and behaves correctly on relaunch – at least in current highfive builds (which are based upon SVN builds around New Year's). r6087 crashes with my navit.xml, need to investigate why.

On highfive, messing with the `cmd_interface` OSD brings the issue back. Tests I carrie out:
* Setting the button to `enabled="no"` has no effect.
* If I set the `update_period="60"` for the OSD, the issues appear only when I relaunch Navit within 60 seconds of quitting it. If I wait longer than 60 seconds before I relaunch Navit, it behaves correctly.
* If I set `command=''` (empty command) for the `cmd_interface`, the issue is back.
* Other changes to the command have also caused the issue to return, namely `command='osd[@name=="profile"].src="/sdcard/navit/osd/profile_unknown_xxhdpi.png"'`.

Apparently running a certain type of OSD command causes Navit to exit cleanly. That seems to depend on the command (as empty commands or certain types of commands don't work), though I have no clear idea of what it is (reading a parameter? reading a certain parameter).
#1291 fixed navigation_itm.way->next list has duplicates KaZeR mvglasow (2)
Description In `maneuver_required2()` (and possibly other functions), when cycling through the items of `new.way->next`, some ways are enumerated more than once.

To test, apply the following patch:
{{{
@ -1262,10 +1262,11 @@ maneuver_required2(struct navigation *nav, struct navigation_itm *old, struct na
} else if (w->item.type != type_ramp) {
num_other++;
}
if (w != &(new->way)) {
dw=angle_delta(old->angle_end, w->angle2);
+ dbg(lvl_debug, "- Examining allowed way: %s %s %s, delta=%i\n", item_to_name(w->item.type), w->name1, w->name2, dw);
if (dw < 0) {
if (dw > left)
left=dw;
if (dw > -curve_limit && d < 0 && d > -curve_limit)
dc=dw;
}}}

Testing a short piece at

http://www.openstreetmap.org/#map=16/45.1965/6.6216

on the A43, westbound, taking the exit towards Modane, the following output is produced:

{{{
debug:navit:maneuver_required2:enter 0x2076ef0 0x1f722c0 0x7fffb04ea7d8
debug:navit:maneuver_required2:- Examining allowed way: highway_land (null) A 43, delta=-3
debug:navit:maneuver_required2:- Examining allowed way: highway_land (null) A 43, delta=-3
debug:navit:maneuver_required2:- Examining allowed way: highway_land (null) A 43, delta=-3
debug:navit:maneuver_required2:- Examining allowed way: highway_land (null) A 43, delta=-3
debug:navit:maneuver_required2:A 43 (null) -> (null) (null): yes: motorway interchange (multiple motorways)
}}}

As you can see, we are getting four copies of the same way – same road name, same bearing.

This was tested with r6040, the bug has been around for quite a while.

The number of duplicates is inconsistent: I am getting four copies of the same way here, in another place I am just getting two, whereas in yet another place things seem OK.

Duplicates are not necessarily ordered – in another case I got something like way1, way2, way1.

I have tested this on two different version of map data, one dowloaded on Oct 24, 2014 and another after March 7, 2015. Both show the same pattern (including the same number of dupes at this partiular point).

I didn't do any extra research to find out where the dupes come from – they might already be in the binfile, or the code that parses the binfile and builds the route map might return the same object multiple times. I have examined current OSM data and did not find any duplicate objects in there, thus it looks like Navit is introducing them somewhere.

It's probably not critical in master, but it is an issue in the upcoming Project HighFive, where such cases result in incorrect announcements.

If anyone has an idea where the fault may lie, please document it here – I may be able to fix it if I know where to look.
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Note: See TracQuery for help on using queries.