Custom Query (1067 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (22 - 24 of 1067)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Ticket Resolution Summary Owner Reporter
#631 Incomplete/Missing infos Add waypoint recording to Navit mvglasow mvglasow (2)
Description This is a new feature I am developing: As of now, I have not found a decent application for creating GPX tracks with waypoints for later use in OSM. There are navigation/tracking applications, which can record tracks but with limited capabilities with regard to starting/stopping without leaving the application, formats supported and support for waypoints. Then there are track logging applications, which do all of the above but do not include a map display (or just a very simple one) - though being able to view current map data is of immense value when visiting a partially mapped area. So why not combine track logging and navigation into a single application?

Design goals are:
* Mechanism to log GPX waypoints through dedicated UI controls (e.g. a "Log waypoint" submenu).
* Timely "commit to disk" to minimize data loss in case of a crash
* Mechanism to start/stop recording of track (menu or OSD item).
* Support for GPX output format (others may be added if considered necessary).

Current implementation status:
* Logging GPX waypoints works; two log entries in the vehicle tag are needed (one for the track, one for the waypoints) since GPX does not allow for alternating recording of trackpoints and waypoints unless the track is split up into segments that terminate at each waypoint (ugly). The only other way would have been to cache waypoint data internally and commit it to disk if the disk is saved, but that would imply the risk of losing all waypoints if Navit crashes and is thus a no-go.
* The only output format supported for waypoints is currently GPX.
* Waypoints are created by calling a function from a menu item (or OSD control); the description of the waypoint is passed as a string and therefore configurable in navit.xml. Default set of waypoints offered is yet to be defined.
* Starting/stopping the log is still to be implemented. My idea is to introduce an attribute called "logging" for the vehicle object. Setting it to nonzero starts all logs associated with the vehicle, setting it to zero stops them. The initial setting will be read from navit.xml, hence adding "logging=yes" to the vehicle tag will automatically start logging.

My idea for the waypoint descriptions is to use a syntax similar to OSM tags rather than prose. E.g. a bus stop would get a description of "highway='bus_stop'" rather than "bus stop". That would allow even for a semi-automated import into an OSM editor (I'm seeing an idea for a new JOSM plugin...)
#635 Incomplete/Missing infos Data missing from log KaZeR mvglasow (2)
Description During my work on #631 I have come across some odd behavior of the log functionality in navit:

I have created a new type of log (gpxwpt) which records trackpoints whenever a menu command is invoked. The command goes through the usual processing in navit and ends up calling a vehicle method, which in turn prepares the log string and then does a log_write to append it to the buffer of the log.

When analyzing the resulting log file, I frequently notice that waypoints are missing. In the most extreme cases, the log consists of only header and trailer, with no waypoints in between. In other cases some waypoints are there and others are missing; in other cases everything looks fine.

I have inserted some logging at the critical points to investigate into this problem. However, the difficulty is that the problem is sporadic and not easily reproducible.

I can say with certainty that my method gets called every time the command is invoked. I am also fairly (~90%) sure that log_write is called. (Unfortunately, after I introduced more detailed logging, the problem has not reappeared yet.)

It is always the data of an entire log_write operation that is missing. Hence it appears that the call to log_write writes either everything or nothing. Due to the nature of the data, the length of the data block to be added is always the same.

My suspect is the flush operation: It is triggered when either the buffer exceeds a certain size (after write, which looks harmless) or when a certain time has elapsed after the last flush operation (timer with callback, suspicious).

log_write essentially does a memcpy of the new data to the end of the buffer, then increases the length counter of the buffer. (The rest is some extra verification around it.)

Theory: If we're in the middle of log_write, appending data to the buffer, and the timer interrupts us just after the memcpy but before updating the buffer length counter, the above behavior occurs.

The flush operation will write the contents of the buffer, as indicated by the length counter (thus everything but the new data) to the file and reset the length to zero.

Then log_write regains control, adding the length of the new data to the (now zero) buffer length. However, the first ''length'' bytes of the buffer hold something completely different. (In my situation I would have ended up logging the same waypoint twice and omitting another.)

In short: it's a classical race condition. I don't see any synchronization in the code. Unless I'm overlooking something, we need to introduce some synchronization to defer the timer-triggered flush operations if any other operation on the buffer is in progress.

All tests were done with a modified r3520 on Windows CE.

Is there anyone who knows that part of the code better than I do and can tell me if my suspicion is likely to be the cause?
#658 Incomplete/Missing infos Adjustable AutoZoom number6 jwernerny -2-
Description When driving local roads, one may want to see 60 seconds ahead. When driving expressways (or rather, when driving long distances), one may want to see 5, 10, 20 or more _minutes_ ahead. The current autozoom does forces one to edit navit.xml to change this, which means it is impractical for real world use.

The attached patch allows the user to adjust the amount of time kept on the screen by using the zoom out and zoom in buttons.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Note: See TracQuery for help on using queries.