{5} Assigned, Active Tickets by Owner (Full Description) (39 matches)

when using this in the configuration file:

<speech type="cmdline" data="espeak -s 150 -v french '%s' &amp;" />

ghost processes of espeak will be created each time navit speaks. Those process eat up 250mb of ram over a 2 hour car trip.

This doesn't seem to be espeak's fault, because doing that command myself in a terminal does not create a leftover process.

it is very annoying to resize all the dialogs each time I use them. Especially on high-resolution computer screens.

Navit should remember the size of its main window (also remember if it was left maximized or not), the size of the roadbook window, the destination window, etc

navit can recalculate routes automatically, but the display does not reflect the changes at all. You have to move the map or hit Refresh to know that the route has changed.

Navit should refresh the route when it is recalculated.

navit's destination dialog needs fields to be entered in the right order (entering the street before the city does not work, for example).

You have to either

• allow entering/querying stuff in any order (might be bad for performance?)
• make it clear that the fields are to be filled in a specific order*
• make a wizard/assistant/druid/whatever that makes it "multiple steps on multiple pages"

*: in this case, they should:

• be one below another
• be gtk insensitive until the previous field has been filled?

when driving in a curved motorway_link or street, navit will (often repeatedly) tell you "now, turn slightly $direction of the curve". It is at best confusing for the driver.

...instead of outside the ways. This would have the advantages that it would not need to be as fat as it is right now, it could be much slimmer, and it will always be visible (right now, no matter how fat the route line is, it is possible for multiple ways to hide it)

when I have a gps attached and I want to view a bookmark the gps (which is not fixed, thus giving 00 00 as position) makes the screen blank immediately when the bookmark is displayed what happens when the gos is having a fix? why is the gps interfering?

Navit currently routes cars. Still, it directed me to use a bus-only road.

Different modes for different uses would be nice.

* car: Use all roads open to cars, and prefer the best
roads * bus: allow bus-only roads as well, otherwise as for cars
* bus,truck: Avoid roads(bridges etc.) with weight/sizerestrictions. Vehicle weight and size should be configurable.
* bicycle: prefer cycleways, disallow motorways
* foot: prefer footways, disallow motorways

On handheld devices (or even devices mounted in a car) a "Mute" button to silence the output of text-to-speech would be welcome.

it would be nice to be able to record GPS tracks and automatically submit them to http://openstreetmap.org/traces

-- simple solution --

a simple menu entry "start/stop recording" and a small dialog, where the user can add some tags like name of street, type of track (highway, oneway etc) or point of interest, before submitting the the openstreetmap server (as soon the device is online).

-- not so simple advanced solution --

direct openstreetmap database access, simplification of GPS tracks (removal of all points that don't contribute enough to the accuracy of the complete track polygon). Automatic start/stop of recording, as soon the user is leaving the known streets.

I don't know enough about the navit-architecture, thus I can't say whether this is a core or mapdrivers/OSM component request.

make it possible to omit the navit keyboard in this screen and use the system keyboard as e.g. on Angstrom 2007.12 for h2210 ipaq. this makes the keyboard switchable (more screen for info) and more complete.

shamelessly quoting the HIG: "Don't add buttons for Help, Close or Quit to your toolbar by default, as these are rarely used and the space is better used for more useful controls. Similarly, only provide buttons for Undo, Redo and the standard clipboard functions if there is space on the toolbar to do so without sacrificing more useful, application-specific controls."

I would add to that the fact that the Quit button is already in the menus, and the fact that the window manager has a nice quit/close button in the titlebar that screams "use me! use me!".

At least, not in the desktop gtk version.

It would be nice if navit could announce when the route is recalculated, something like speech->say("Recalcuating route...");

the current ways are way too heavy-stroked. Problems caused by this:
- no way to see motorway_link unless you are fully zoomed, on most highways
- problems seeing the blue route "trace"
- ways that are close together merge together, except at maximum zoom

This is not a "the user can change it in navit.xml, not a bug" problem. The default setting should be usable. I tried looking at navit.xml and could not even figure out what the width settings meant, and which of the 18 (or more?!) settings I had to change. It's crazy, there should be a simple "master" width scale, or a gui setting for that to be changed in 2 clicks.

The window title and the "name" label should have an entry in the PO file.

GTK GUI, OSM map. No speech output

In the roadbook, there was no space between distance (eg "100m") and road number (eg "A50"), so the directions were something like:

Turn left after 100 minto A50

This didn't happen if the road to be turned into was referenced by name (eg "High Street") instead of reference number.

I got the following message in the roadbook:

"Trun easily left in 430000 m"..

I would suggest using Km for distance above 5Km.

I've downloaded some maps of New Zealand from the cgpsmapper site, but when I search, despite what appear to be search results appearing in the console window in which I started navit, nothing appears in the GUI. The messages I get look like:

garmin.c:199:1|Called! garmin_rgn.c:1279:2|Found 1 subfiles garmin_obj.c:562:1|Search from cid: 0 rid: 0 cid:0 garmin_lbl.c:453:1|1 countries defined 3 garmin_lbl.c:499:1|3 regions defined sz=5 garmin_lbl.c:542:1|325 cities defined sz=5 garmin_lbl.c:594:1|lbl7 off=14711 size=36, recsize=4 garmin_lbl.c:614:1|0 ZIPs defined sz=3 garmin_lbl.c:656:1|lbl5 off=12D73 size=2968, recsize=4 garmin_obj.c:660:1|Match: BALLANCE(19) garmin_obj.c:753:1|Returning 1 matches garmin.c:245:4|Loaded 1 objects garmin.c:487:1|Unknown garmin object type:6

The libgarmin header suggests that object type 6 is a "GO_SEARCH".

I've attached the map file I'm using, in case this problem is somehow specific to these maps.

I'm running libgarmin from svn (rev 304), and navit from svn (rev 1452).

I frequently drives outside mapped areas, because I update the OSM map. It is convenient to have navit show what roads are on the map already.

But navit always snaps to the closest road, even if it is several hundred meters away. Snapping to the closest road within the combined error margins of the map and the GPS is of course reasonable. The current GPS accuracy is (usually) available from the GPS readout. Map accuracy is usually unknown - but a map made from GPS traces (like the osm map) is usually accurate to within typical gps accuracy. The map accuracy should ideally be user configurable. Those who want to cling to the roads can then set a large error margin, those who want to go off-road can set a low error margin.

Hi, the additional attribute "surface=paved" on unclassified roads makes navit draw them different (as thin black line) as highway=unclassified without that attribute.

As "surface=paved" should be the taken normal state this shouldnt make a difference.

Flo