Forum: General Topics
Forums / General Topics / Geocaching
| Subject: | Geocaching | |
shchenka 18:30 | Hi, I've downloaded version 0.6 and gave it a try at geocaching the last two days. It's much much better than I initially expected. And still has many features for me to learn. I appreciate that geocaching was probably not the primary application you had in mind when developing this, still it performs great. I wonder if you would consider some suggestions towards tuning it a bit more for geocaching, or maybe even introducing a "geocaching" configuration mode. Would this be along your way at all ? | |
Stephen 11:07 Location: Phone Model: | Hi shchenka, What suggestions did you have in mind? Though I don't necessarily want to focus too much on a particular application, if you've got any ideas which would help with geocaching I'll certainly consider them... Cheers, Stephen | |
shchenka 15:11 | Hi Stephen, some ideas: 1. The biggest thing would be for the tmj to be able to import and display cache descriptions from GPX files. I would imagine that the presentation would require an enhancement of the current waypoints list, so that when you select a waypoint corresponding to a cache, you can read its description, hints and all the corresponding information included in the GPX file. It would be useful to be able to invoke it for the selected waypoint in the Plan/Navogation/Map screens, too. GPX Cache description files are generated by most geocaching services and applications. A GPX file can be as large as a couple of megabytes. It might seem very simple but would be a very useful functionality. An example of what I have in mind can be seen at http://www.smartcaching.de/ where a SmartGPX does exactly that. I may be naive but it seems that tmj has most of the needed components already in place. 2. The other useful thing would be to be able to open a url for a selected cache in a web browser. In a GPX or a LOC file, every cache has its associated URL. It would be good to be able to launch a web browser from TMJ for a selected cache with a simple sequence of keys (ideally a keystroke or two). 3. In the AutoPan options it would be good to be able to have a zooming mode centred around a selected cache/waypoint rather than the current location. It would have to zoom up and down with the distance to the waypoint so that the current location, direction and distance are visible in the screen. It seems that currently zooming in is limited up to 500m or so. It would be useful to be able to zoom in up to e.g. 10 metres. 4. It would be good to have an option to reduce the amount of information displayed in the screen when "Loc/Wpt/Rte Info" is selected in the view options. The only interesting piece of information in geocaching context would be the distance, all the other like speed etc. only take up the valuable display space. 5. Another idea would be to trigger an alarm if a cache/waypoint becomes closer than a given threshold. The application of this would be to alert a cacher, when a cache is detected in vicinity e.g. when driving etc. 6. It would be nice to have an option to auto-select the closest cache from the waypoints list. This way, when I'm moving from one cache to another or between a number of caches, I would not have to do this manually each time I'm approaching one. 7. Finally, it would be good to have more than one waypoint icons for geocaches, maybe a couple of differently coloured ones ? These are just some ideas that I think would boost the TMJ usability for geocaching even further. What do you think ? Please take a look at SmartGPX at http://www.smartcaching.de/ to see better what I have in mind. Thanks for reading this :) | |
Stephen 10:21 Location: Phone Model: | I'll have a think about this - will get back to you later...! | |
Stephen 17:37 Location: Phone Model: | Hi shchenka, " 1. The biggest thing would be for the tmj to be able to import and display cache descriptions from GPX files. " Hmmm, I can see the usefulness of this. The main problems that I'd foresee are firstly that I'd need to write an XML parser to read the GPX file. Though there are already ways to do this with J2ME they tend to be a little cumbersome - I'd rather not have to increase the JAR size by 20% just to add XML parsing. As long as the GPX files are pretty consistent though I could probably create a basic parser that would at least be able to extract the core data. Secondly there the problem of memory usage. Ideally (as would no doubt be the case with a PC, Symbian or Windows Mobile program) the entire GPX file contents would be loaded and held in memory in one go. However, there is barely perhaps 50-100Kb that I could allocate to this in TMJ, so it would need to just initially load the basic Lat/Long/Name info, and then re-read the file when the further information is requested. This could get a bit cumbersome (particularly with some phones that constantly ask for permission when reading from the memory card), but might be a workable solution. " 2. The other useful thing would be to be able to open a url for a selected cache in a web browser. " This should be possible once step (1) is working. Not all phones are able to open a browser from J2ME though (and some have to close the Java program in order to open a browser), so it could get a bit fiddly for some users. " 3. In the AutoPan options it would be good to be able to have a zooming mode centred around a selected cache/waypoint rather than the current location. " Yes, I should be able to reduce the 500m limit, though 10m might be a little extreme since GPS is rarely more accurate than 10-15m itself. (eg if the width of the screen showed perhaps 50m, would this not be good enough?) " 4. It would be good to have an option to reduce the amount of information displayed in the screen when "Loc/Wpt/Rte Info" is selected in the view options. " Perhaps if I split this into two options - 'Show Loc Info' and 'Show Wpt/Rte Info', then just the waypoint information could be shown when geocaching (just giving Cache name, Distance and Bearing)... " 5. Another idea would be to trigger an alarm if a cache/waypoint becomes closer than a given threshold. " I've thought about adding something like this in the past, the trouble with it is that TMJ would then have to constantly keep updating ALL the waypoints distances ALL the time. With only a few waypoints in the list its not a problem, but with many (eg 100s or more) the constant calculations needed to do this could slow down the program a lot. Having said that, there might be ways to optimise this (eg, only update perhaps the nearest 10 all the time, and slowly update the rest in batches, for example), I'll need to look into it further! " 6. It would be nice to have an option to auto-select the closest cache from the waypoints list " Same thing applies as above, but if can sort that then this should be possible... " 7. Finally, it would be good to have more than one waypoint icons for geocaches, maybe a couple of differently coloured ones ? " This one I can easily do! If only if was all this simple!! ;-) It would be useful if you could send me an example GPX and LOC file to give me an idea of the format, filesizes, etc (so a largish file would be best) - you can send it to the e-mail given in the registration e-mail, or contact me via the feedback form if you no longer have this... Cheers, Stephen | |
shchenka 21:52 | Hi Stephen, " 1. The biggest thing would be for the tmj to be able to import and display cache descriptions from GPX files. " Hmmm, I can see the usefulness of this. The main problems that I'd foresee are firstly that I'd need to write an XML parser to read the GPX file. Though there are already ways to do this with J2ME they tend to be a little cumbersome - I'd rather not have to increase the JAR size by 20% just to add XML parsing. As long as the GPX files are pretty consistent though I could probably create a basic parser that would at least be able to extract the core data. Ah, I missed that currently TMJ has no XML parsing, They are not really complex files but I'm afraid there are two different XML formats for this. You can have a look at one of them here: http://geocaching.com.au/geocache/1/geocache.xsd I'll email you some samples. Or maybe an external parser (or a "preprocessor" if you like) which would somehow store the data in files easier to consume for TMJ. Not a very elegant solution, though. Or maybe parse and store them off the mobile, e.g. at your TMJ web site and then download individual descriptions on demand ? Neither of these ideas is perfect. Would a unified non-XML format be easier ? Secondly there the problem of memory usage. Ideally (as would no doubt be the case with a PC, Symbian or Windows Mobile program) the entire GPX file contents would be loaded and held in memory in one go. However, there is barely perhaps 50-100Kb that I could allocate to this in TMJ, so it would need to just initially load the basic Lat/Long/Name info, and then re-read the file when the further information is requested. This could get a bit cumbersome (particularly with some phones that constantly ask for permission when reading from the memory card), but might be a workable solution. Still it would be much easier than having to switch to another application, and then search for the same cache there, and this for each geocache. Or maybe an option to pre-select up to say 20 caches, and then bulk read their descriptions to memory with a single op ? " 2. The other useful thing would be to be able to open a url for a selected cache in a web browser. " This should be possible once step (1) is working. Not all phones are able to open a browser from J2ME though (and some have to close the Java program in order to open a browser), so it could get a bit fiddly for some users. I see. Another option could be to transfer the urls when synchronizing waypoints with the online TMJ database (but of course they would have to be stored there in the first place). " 3. In the AutoPan options it would be good to be able to have a zooming mode centred around a selected cache/waypoint rather than the current location. " Yes, I should be able to reduce the 500m limit, though 10m might be a little extreme since GPS is rarely more accurate than 10-15m itself. (eg if the width of the screen showed perhaps 50m, would this not be good enough?) I'll check it and will get back with a practical scale in a couple of days. 500m was definitely too much for this. " 4. It would be good to have an option to reduce the amount of information displayed in the screen when "Loc/Wpt/Rte Info" is selected in the view options. " Perhaps if I split this into two options - 'Show Loc Info' and 'Show Wpt/Rte Info', then just the waypoint information could be shown when geocaching (just giving Cache name, Distance and Bearing)... I certailny would welcome it. Ideally, I would be using a mode where I have the cache name displayed next to the waypoint marker, direction arrow, and the only interesting information would be the distance. Or would it be possible to have an option to display these info boxes at the bottom of the screen as an alternative to the top for when I'm moving northwards ? Anyway, splitting it into two options would be useful already (especially that with the longer cache names the boxes obstruct each other). " 5. Another idea would be to trigger an alarm if a cache/waypoint becomes closer than a given threshold. " I've thought about adding something like this in the past, the trouble with it is that TMJ would then have to constantly keep updating ALL the waypoints distances ALL the time. With only a few waypoints in the list its not a problem, but with many (eg 100s or more) the constant calculations needed to do this could slow down the program a lot. Having said that, there might be ways to optimise this (eg, only update perhaps the nearest 10 all the time, and slowly update the rest in batches, for example), I'll need to look into it further! Don't you already constantly update the distances when in the "waypoints list" screen ? " 6. It would be nice to have an option to auto-select the closest cache from the waypoints list " Same thing applies as above, but if can sort that then this should be possible... This one possibly could (and maybe actually should) be triggered with a keypress. " 7. Finally, it would be good to have more than one waypoint icons for geocaches, maybe a couple of differently coloured ones ? " This one I can easily do! If only if was all this simple!! ;-) No wonder I left this one at the end... Thanks. It would be useful if you could send me an example GPX and LOC file to give me an idea of the format, filesizes, etc (so a largish file would be best) - you can send it to the e-mail given in the registration e-mail, or contact me via the feedback form if you no longer have this... I'll try email. Thanks again. | |
Stephen 20:00 Location: Phone Model: | Hi shchenka, Thanks for the GPX/LOC files that you emailed. I must say I'm a little worried that they might be a bit too complex to parse easily in TMJ, essentially due to the extra memory/resources that would be needed in handling them. The GPX files in particular look pretty horrendous!! Not only are some of the descriptions pretty long in their own right, but some are also formatted in HTML, which would also have to be stripped by TMJ in order to display the text in a basic J2ME textbox. I had been thinking about something similar to your suggestion of a preprocessor for the GPX files, but as you say, this just creates yet another level of confusion/complexity in the process. All things considered I think the website link is perhaps the best way that this could be achieved. The Upload LOC File page can already be used to import the basic geocache names/locations from the LOC file. It would need a bit more work to enable each Waypoint to also have a description/URL link, but there is a lot more space available on the website than on a mobile device, so this should be possible. (Although if a lot of people use the service to its full then I might still have to limit the space available for each user!!) I would then envisage that the description for a particular waypoint would be requested from the website as and when it is needed, and not stored permanently on the phone. (Though perhaps the last few descriptions would be cached temporarily so that they can be re-viewed without further data usage). Alternatively I could look into further the idea that I suggested a while ago in this thread, whereby a particular waypoint Group on the website could be marked for 'location-dependant-synchronisation'. Then each time the 'Web/Update Waypoints' function is used only perhaps the nearest 30 waypoints from the group would be downloaded (and would only be kept in memory until the next restart). All of this would rely on having mobile coverage, cheap data allowance, etc, so perhaps wouldn't fit every geocaching situation, and I'm not really sure how much it would be needed by other users. Any thoughts? " Don't you already constantly update the distances when in the "waypoints list" screen? " Actually the whole list is only updated each time the user initially switches to the Waypoints page. After that only the waypoints shown on screen have their distances updated. I figure that most people will only switch to the Waypoints page briefly every so often, so the lack of full waypoint updating would largely not be noticed! I'll think about improving this though - if they are all kept fairly up-to-date then the 'Waypoint alarm' and auto-selection should be easier to implement... Cheers, Stephen | |
shchenka 21:44 | Hi Stephen, The LOC files do not contain cache description, only the name. id, location and the URL of the description page. If I understand it right, this last information is not used. So probably the easiest thing would be to transfer these URLs along with the other waypoint information to TMJ during synchronization. But for this to be useful, you'd have to be able to launch a web browser from TMJ, which, as you wrote is not that obvious and might be confusing. The alternative would be to use the GPX files, which contain the information. Would you be willing to parse them and store the records at the web site end ? Then I would think that allowing to download the info for individual caches to the mobile (and caching them there) would be a good compromise. It would be reasonable to be able to cache some 10-20 of them in the memory, would this be doable ? As for the 'location-dependant-synchronisation', I'm not quite sure how practical this would be. E.g. a geocacher can drive and collect caches along a route rather than looking for the caches in a certain area. Another scenario would be to pre-load the descriptions of the selected geocaches at home or a hotel with wifi before going out. As you say, the data transfer cost would depend on a situation (e.g. at home versus abroad) so I think it's better to be a bit conservative here. Loading a single or maybe a dozen of selected descriptions can make a difference to having to load fifty when I only need one or two in that area. I thought that for updating the distance to the closest waypoints and the waypoint "auto-selection" you could use more or less the same mechanism as for updating the distances for the waypoint visible in the screen of the waypoints page. With a press of a key, a group of the closest e.g 10 caches would be selected, and only distance to the caches in this group would be monitored and used for auto-selection. Then if a user moves and wants to re-calculate and update the group, he would have to hit the key again etc. This would not solve the general "waypoint alarm" issue, though, as this by definition should not require any activity of the user (otherwise why alert him if he's already aware of the situation). On the other hand, looking for the closest waypoint for the purpose of the waypoint alarm would not have to be done continuously, but every 15 or 30 seconds or so. The period could depend on the speed of gps movement (much less frequent when walking or cycling, and more frequent when driving fast). Or maybe a hybrid mechanism of the above two. Every 30 seconds select a group of 10 closest waypoints and then monitor the distance to the waypoints in this group only both for waypoint alarm and for the auto-selection. Would this make sense ? 8. Another useful feature for the "autoselection" would be to allow to mark individual caches as "found", which would at the same time change the active waypoint to a new closest one. This of course would be only a convenience mechanism, as everyone can achieve the same a couple of keystrokes, so maybe it's not worth the effort. On the other hand, being able to mark the found caches when geohunting (and so that they could e.g. change their markers or colours in the map) would be a nice feature. Currently I can simply delete the geocaches found from the waypoints list, but in certain situations it's better to keep them when roaming around. | |
Stephen 21:06 Location: Phone Model: | I think I need to investigate further the possibilities of J2ME firing up a separate browser window - if this turns out to be quite straightforward then that might be the way forward (might also possibly solve the 'caching' issues, depending whether the phones browser can automatically cache recent pages). Yes, I was thinking about parsing the GPX files on the website, though that still leaves the problem of how TMJ should display a nicely formatted HTML description in plain text. (Which perhaps leads back again to the browser idea!?) I think for the next version I'll probably concentrate more on the Waypoint alarm/auto-sensing issue. I was thinking that it could be set to only trigger an alarm/auto-selection for selected groups. That would firstly reduce the number of waypoints that it needs to update, and you could then also have a separate group for 'found geocaches' (if so desired), which would allow them to stay on the phone, but not take any further part in the clever stuff! Does that sound reasonable? | |
shchenka 7:38 | Good idea. TMJ allows "moving" waypoints between groups easily. It would be good to be able to associate/fix a waypoint marker (type) with a group. Then I could have one group for the found geocaches and the waypoints in this group would display differently on the map. Also these waypoint would be inactive wrt the waypoint alert/autoselection mechanisms so as not to bother a user with the geocaches he already found. | |
shchenka 19:57 | " 3. In the AutoPan options it would be good to be able to have a zooming mode centred around a selected cache/waypoint rather than the current location. " Yes, I should be able to reduce the 500m limit, though 10m might be a little extreme since GPS is rarely more accurate than 10-15m itself. (eg if the width of the screen showed perhaps 50m, would this not be good enough?) I've experimented with this a bit today and yestarday It seems that zoom up to 1:300 or 1:400 makes sense with my phone/gps. I think this corresponds to something like 12,5m or 25m ruler. I guess the practical zoom factor might vary depending on the display resolution/size. I have 320x240. Maybe you could make the maximum zoom factor in autopan selectable in options, as the optimal zoom might be different for different purposes ? Do you think it would be possible to optionally center the zoom on a waypoint (the geocache) rather than the current location ? | |
Stephen 13:37 Location: Phone Model: | " Maybe you could make the maximum zoom factor in autopan selectable in options, as the optimal zoom might be different for different purposes? " Yes, I suppose this might be useful - maybe just a simple option list (eg 25m, 50m, 100m, 500m, etc)... " Do you think it would be possible to optionally center the zoom on a waypoint (the geocache) rather than the current location ? " I could add this, but thinking about it further, surely all you need to do is manually centre the view on the Waypoint (without using autopan), its then easy to just zoom in/out to get the current location into view as well - isn't this almost the same thing? (I'm just a little concerned that having soooo many different autopan options could just be confusing, especially for new users...?) | |
shchenka 16:39 | " Do you think it would be possible to optionally center the zoom on a waypoint (the geocache) rather than the current location ? I could add this, but thinking about it further, surely all you need to do is manually centre the view on the Waypoint (without using autopan), its then easy to just zoom in/out to get the current location into view as well - isn't this almost the same thing? (I'm just a little concerned that having soooo many different autopan options could just be confusing, especially for new users...?) " Indeed, that's what I'm doing. On the other hand I would like to use the auto-zoom feature at the same time. I think you are right that it should work this way once you implement the option to reduce the max zoom factor down to 25m. I'll experiment then. | |
Maverick1 5:16 | Stephen I know a few people that would certainly like the geocache options, even with limitations. I for one. Cheers | |
gpsnone 17:31 | i have been using TMJ for quite a while for geocaching. its the best program for geocaching imho. usually, there are up to 1000 waypoints in a group. several groups in use. switching between waypoint list and other views/ sorting already takes a while :) i admit, that adding the gpx functionality would be alluring, BUT adding import of GPX-files (we are talking about >3MB) and parsing them, storing them searchable and selectively displayable should not be an additional task of TMJ. that would inflate the sourcecode too much, especially for the ppl not using TMJ for geocaching or using older phones. and of course Stephen having to have to program it :) smartgpx does a good job handling gpx files. perhaps the two programs can interact? passing a waypoint name like GCXXXX to smartgpx and smartgpx displaying the cache, hints, etc directly? in that way, geocachers would be able to use the best of two programs easily. smartgpx can utilize gps as well, and it would be great to pass a selected waypoint not only to the internal applications (at least on my e70), but to TMJ, too. i more second enhancements for TMJ, that improve finding the (exact) waypoint. like the mentioned new panning mode (3) or the icons (7). a "high precision mode" would be nice, too. it that mode, the user would be able to take, like, 100 mesurements starting key-triggered and displaying the accurate averaged position on the screen, eleminating any jitter. regards, alexander | |
Stephen 20:40 Location: Phone Model: | Hi Alexander, I think I've pretty much come to the same conclusion regarding directly importing the GPX files - its just too much extra for TMJ to do. Unfortunately I don't think the smartgpx link up could work either - its a Symbian program so I don't think theres anyway that this can communicate with J2ME. I've been working on adding a couple of the geocaching ideas into the next version, won't have it all done though (the website GPX import in particular will probably have to wait a while). Got the extra geocache icons (there are 4 now), selection of the nearest waypoint, max map scale limit, etc. More to come...! I've been thinking about your 'high-precision mode' suggestion. Its an interesting idea, but I'm not sure that it would actually help all that much. Are you thinking that it could be used when you're stationary (perhaps about to hide a new geocache?) to get an accurate location for the next person? The thing is, and I'm largely guessing here, I'd have thought that a fair bit of the GPS accuracy comes from other external factors (such as nearby hills/buildings reflecting the signal, not many satellites in view, etc) that wouldn't necessarily improve over time. For example a nearby hill is maybe more likely to deflect the signals so that *all* readouts are shifted away from or towards the hill, in which case an average of these wouldn't be much better than a single reading, as the 'average' would also be offset. In other words, it would only help if the *actual* location is directly centred at the middle of the cluster of points streaming from the GPS. Having said all that it should be fairly straightforward to add something, if only as a test at least. Perhaps when the track is Paused it could use that as a trigger to start averaging all subsequent points? I'll have a look... Cheers, Stephen | |
gpsnone 8:44 | Hi Stephen, " I've been thinking about your 'high-precision mode' suggestion. Its an interesting idea, but I'm not sure that it would actually help all that much. Are you thinking that it could be used when you're stationary (perhaps about to hide a new geocache?) to get an accurate location for the next person? " exactly. of course you cant fight the physics in a bad location, but when hiding a cache, this could be very useful. and when seeking a cache too. in my experience, the gps data shifts sometimes too much, even if you have direct view to the sky. showing you reach the destination (<1m) and then showing you 20m away for some time, slowly shiftig to a third location and so on. in case of searching a geocache, it would be interesting, too, to know, which side of a bridge/ river to go. which tree in a group of trees, etc. one should be able to disable high precision mode. i never attached my gps mouse to my computer to collect some nmea data and do the averaging on my own, so i dont know, how effective it would be. it surely depends how you do this, what thresholds you set (e.g. to skip a measurement X meter away from the assumed fix). i guess, some tests need to be run for that. if you need a tester for geocaching-functionality, whether its usefullness or operability, i volunteer for a betatester. :) regards, alexander | |
shchenka 18:41 | I've heard, that a lot may depend on the gps chipset, e.g. mtk based receivers are said to be more sensitive but also may "float" more than sirf3 based ones, because they collect more reflected signals. | |
Stephen 19:20 Location: Phone Model: | I've got the high-precision mode working fairly well now I think. As mentioned above, I've incorporated it into the 'Pause Track' function. When the track is first paused a new point marker is displayed on screen. Each subsequent point received from the GPS is then averaged with this point (the averaging is weighted so that only 1% is taken from the GPS, with the existing point weighted to 99%). This basically makes each GPS signal give a very very small offset to the displayed point, so if the signal were to jump around a central location, the smoothed point *should* end up roughly sitting at the centre. A bit difficult to describe, but see what you think once I've released the new version (should be fairly soonish - I'm just tidying up a few more additions)! Alexander, on a separate issue, I've been getting a number of bounce-backs from your e-mail address (as you've turned the 'Thread notification' on, each time a new post is added to this thread an e-mail is sent to you). I don't know if your e-mail address is still valid - if you'd like me to update it just send a note via the feedback form... No worries if not... | |
gpsnone 19:54 | Hi Stephen, " 3. In the AutoPan options it would be good to be able to have a zooming mode centred around a selected cache/waypoint rather than the current location. It would have to zoom up and down with the distance to the waypoint so that the current location, direction and distance are visible in the screen. It seems that currently zooming in is limited up to 500m or so. It would be useful to be able to zoom in up to e.g. 10 metres. " not only a pan-option for the plan page would be nice. one should be able to center the map on a certain (geocaching-)waypoint in the map-page. so you can see, what is around that waypoint or to check, if your generated map for a geocache far far away is working :) regards, alexander | |
shchenka 20:24 | I believe the high-precision mode may be also very valuable when placing a new cache. One has to measure sure exact coordinates then. What I usually did was making several different measurements, approaching the place from different directions, then manually averaging the most similar results and hoping the result is more or less correct. I wonder to what extent this could be automated. | |
gpsnone 20:34 | you are right, shchenka. " (the averaging is weighted so that only 1% is taken from the GPS, with the existing point weighted to 99%). " i am not sure, if these are the best numbers. when the first one or more points are not correct, TMJ would hardly ever find the correct point, because the influence of the more accurate points are only 1% | |
Stephen 14:04 Location: Phone Model: | " not only a pan-option for the plan page would be nice. one should be able to center the map on a certain (geocaching-)waypoint in the map-page. so you can see, what is around that waypoint or to check, if your generated map for a geocache far far away is working " If you press the * key on the waypoints page the Map and Plan page are both centred on the selected waypoint, which I think is pretty much what you're after! " I believe the high-precision mode may be also very valuable when placing a new cache. One has to measure sure exact coordinates then. What I usually did was making several different measurements, approaching the place from different directions, then manually averaging the most similar results and hoping the result is more or less correct. " Yes, it should aid with this. Currently the high-precision location is just displayed as a cross - to add it as a waypoint would need the plan page to be manually centred at the same spot. If it seems to work, then I'll add an option to take the new waypoint location from the high-precision point rather than the usual one. " i am not sure, if these are the best numbers. when the first one or more points are not correct, TMJ would hardly ever find the correct point, because the influence of the more accurate points are only 1% " In testing it does seem to work okay, although its true that it can take a while to shift location, especially if the first point is a long way from subsequent ones. I'll look into making it a true average of *all* fixes received whilst the high-precision/pause track is enabled... Cheers, Stephen | |
shchenka 14:46 | " Yes, it should aid with this. Currently the high-precision location is just displayed as a cross - to add it as a waypoint would need the plan page to be manually centred at the same spot. If it seems to work, then I'll add an option to take the new waypoint location from the high-precision point rather than the usual one. " That would be helpful. The high precision mode sounds very promising, but I think I'd need to test it first before I can judge how practical this is. Maybe in practice it would require some tuning. I wonder if/how dependent it would be on the gps chipset (see my earlier comment in this thread). Cheers. | |
gpsnone 19:11 | " If you press the * key on the waypoints page the Map and Plan page are both centred on the selected waypoint, which I think is pretty much what you're after! " exactly. i did not know that till now. thanks a lot regards, alexander | |
(You must be logged in to post a reply to this thread)