Am 31.12.2009 14:20, schrieb Albrecht Dreß: > Hi Oliver: > > Am 31.12.09 10:04 schrieb(en) Oliver Eichler: >> non ASCII characters are a problem in general. To do it right, I would >> need to know the character set of the device. No idea how to do that. > > Simple solution: let the user choose. I believe most have only one or > two devices, all with the same locale configuration.
That would imply that we know all character sets used by Garmin. For now I switched all strings from "Local 8 bit" to "Latin 1". If someone complains we can add the needed character set to a combo box for selection. > > It might be a good idea to re-organise the "Device" setup dialogue anyway: > 1st row: Combo to select the device type > 2nd row: entry for serial port for serial devices *OR* host name and > port for ethernet devices *OR* nothing for USB devices *OR* label saying > that no drivers were found > 3rd row: additional device config options, like locale configuration. > > This would display only the relevant options for the selected device, > and the order would be more natural. Again this would imply that GT knows the kind of serial link used for communication. It would need to add this information to the driver API, touch each driver and to pass back correct values. If someone really wants to spend time on this: go ahead! >> It's a bit of a problem of limited waypoint name length. Especially >> the older eTrex series is very limited. If I recall right they have 6 >> characters only. That's why I decided to do it with numbers only. > > But you know it from the protocol the device supports! Looking at the > Garmin docs, all waypoints up to type D107, inclusively, support a 6 > character identification and a 40 character comment. You could use your > numbering scheme here, and set the comment to the (possibly cut) > waypoint name. For the 60CSx it's 14 char. name and somewhat 32 char. comment. What does it take to implement it device specific? All drivers have to implement void IDeviceDefault::_getDevProperties(Garmin::DevProperties_t& dev_properties) The used protocols are transmitted during the syncup sequence, but that would imply to fire up a dummy syncup sequence just to get this information. Not sure if all supported devices like that. Alternatively you can hard code dev_properties as the table is known anyway. -> touch each driver. Also I am not sure if all devices using a special Dxyz type really offer the same capabilities. I would say "yes", but as we know Garmin's documentation and reality are not always friends. Anyway, if all devices report their protocols properly, it's feasible to enumerate the route's waypoints with the route's name. > >> You can select waypoints from the list to form a route, already. >> However the route will create a new copy of the waypoints with the >> known number scheme when uploaded. > > I thought about the attached patch which saves one click... ;-) No idea > if it breaks something else, though. Before I commit the patch let me ask: What's the use of converting a single point into a route? What is the advantage compared to a waypoint and "goto"? > >> Why is that? Well, GT is not a Garmin-only software and the concept of >> transferring waypoints as part of a route is more than strange. To be >> generic to other manufacturer's devices there must be no link between >> the different data elements like waypoints, tracks or routes. That is >> why the CDeviceGarmin instance will add waypoints on-the-fly. > > I understand. However, my point is that it seems to be natural that the > user might give names to nodes in a route. Think of a rail trip where > you have to change the train, and the intermediate nodes are the names > of the stations where you have to change (bad example, but you get the > picture, I hope...). If and how they are actually transferred to the > device is the task of the backend driver. The problem is exactly at this point. The backend driver does not know about the waypoint database when uploading a route. It just has a bunch of coordinates. It's not impossible but you have to solve several problems: You create a route from waypoints. You fine tune the route by converting it to a polyline and back. How do you want to handle the waypoint information in that case? If a waypoint has proximity information and is not uploaded to the device yet, how do you want to handle that information? Moving the waypoint does move the routepoint, too? > > IIRC, if the Garmin receives a point in a route which does already > exists as waypoint with *exactly* the same properties, no extra new > waypoint is created which is somewhat convenient, as otherwise many > identical waypoints might accumulate in the device. That is right. It needs to upload the complete waypoint as it's done by CWptDB. Else you will get copies. Thus for Garmin devices you need a very close link between the CRouteDB and CWptDB to do it nicely. But that is not generic. > >> Btw, I never use routes. I upload waypoints and apply "goto" on the >> device. Much easier :) > > That's correct. However, something like a "trip planning feature" would > be nice. E.g. think of creating a route to visit several customers, > i.e. a route which consists of several nodes (which should all be named, > like "Company A", "Company B", etc.). It is a lot easier using an > application like QLandkarteGT (never used Mapsource, no idea if it's > possible there) than the device itself. This example applies to me very often. And I use waypoints to solve it. I goto waypoint "Company A" and after I am done I goto "Company B". And if the timetable shifted I select "Company C" instead of "Company B". The only 2 use-cases for routes known to me are: 1. fix a bad auto-routing by adding an intermediate point. 2. mountain bike enthusiasts love to tinker their own routes on a routepoint per crossing base as auto-routing fails miserably for mountain bike tours. The current route implementation was done with the 2nd case in mind. Oliver ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ QLandkarte-users mailing list QLandkarte-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qlandkarte-users
