[Loadstone] Several comments from a new user.

Shawn Kirkpatrick shawn at odyssey.cm.nu
Mon Jul 9 01:55:21 BST 2007


I don't think you'd want to do to much based on static threshold. This is 
mainly a hack to try to correct a problem, not a real fix. At the lower 
speeds it's quite likely that you're going in and out of the static 
threshold. If you have the reporting functions changing based on that the 
results could be quite random.
We're currently working on doing software heading/speed calculations since 
the information from some receivers is almost useless at low speeds. We'll 
have to see if calculating these gives any better values.
As for the automatic database checking, the same problems still apply. On a 
fast phone with a small database it wouldn't be a problem but this doesn't 
scale very well. On some of the older phones with a larger database the 
check can take 4 or 5 seconds so even doing it periodically won't work. Put 
that database on a memory card and the problem gets even worse. The real 
solution to this is a complete database replacement. So far I haven't found 
any open source database engines for symbian.
When importing points it checks for duplicate/updated points based on the id 
and userid fields. This allows all the other fields in a point to be 
updated.
I think the 5 key in exploration will report the distance from the last gps 
position to the current point if there's no signal. This assumes that there 
has been a signal at some point in the run. If it's just using the last 
position from a previous run then this isn't the case since the data is most 
likely stale. Now it wouldn't really surprise me if this isn't working quite 
right. The functionallity of the 5 key needs some sorting out.
We're currently trying to work out some kind of street following mode. At 
least a way to get from intercection to intercection. How this is going to 
work if it ever does is still unknown.
Currently there's no way to list your current checkpoints. You can kind of 
do this if you use the use checkpoints only option but that won't give you a 
list as such. This function would be kind of useful and probably wouldn't be 
too hard to implement.

On Sun, 8 Jul 2007, Dave Mielke wrote:

> [quoted lines by Shawn Kirkpatrick on 2007/07/08 at 02:46 -0700]
>
>> There was some talk a while ago about making the navigation mode use compass
>> directions when the speed dropped but it was decided that having reporting
>> functions randomly changing there behaviour would cause a lot of confusion.
>
> I understand, which is why I'm suggesting a setting to enable this mode so that
> the user knows what he's doing to himself. Also, as long as the point and
> expore directions are set to different formats it'll be clear from the
> announcement which one is being used. I personally find the direction
> information when below the static threshold to be rather untrustworthy right
> now since the unseen/unheard jitter causes the direction to unpredictably jump
> around without notice. A third possibility may be to simply omit the direction
> information altogether in this case. Perhaps there should be a setting which
> gives the user all three choices.
>
>> Having every point announced as you approach just isn't going to happen any
>> time soon. The main problem is the database engine in the phone, it's slow.
>> There's just not enough computing power to be running all the selects you'd
>> need for automatic point announcements and still be able to do anything
>> else.
>
> What about always being aware of the next point in the direction of current
> motion?
>
> Another possibility might be to check every five seconds or so, what the
> nearest point is, and to announce its position if its close enough. That'd
> achieve the same effect.
>
>> In the next version of Loadstone the find point system has been completely
>> rewritten. The new version allows you to override the search radius and
>> takes place in the background. This should solve the lock up problem.
>
> Excellent! In case you're curious, by the way, I was experimenting with using
> Loadstone-GPS in a non-GPS way. I made a table of international locations, and
> was just trying out browsing the map so I could learn where various
> geographical points were in relation to one another.
>
> While on this topic, I have a question about the point table. When updating it
> during import, is it the id/time field or the name field which is used to
> decide if an entry should be added or updated? If I generate the same table
> again is it important to make sure that the id/name mapping is retained?
>
> Again, in case you're curious, I'm making my tables via a Tcl script on Linux
> which I wrote so that I can extract the plain text from any web site which
> contains such data, edit it a bit by hand to make the format somewhat
> predictable, and then run it through my script to produce the table.
>
>> The program doesn't really lock up, it just appears dead since it's taking all
>> resources to do the search.
>
> I thought that might be the case but it was hard to tell. After waiting a very
> long time (like 20 minutes or so) I gave up.
>
>> If you go in to exploration mode and you have no signal or the gps isn't
>> connected you will start at your last gps coordinates. These will save
>> accross program runs.
>
> Okay, this does seem to work. I don't remember any more why I tghought it
> didn't.
>
> Pressing 5 in Exploration Mode doesn't give the current point's position
> relative to the last GPS position, though, when there's no signal. It'd be nice
> if it did.
>
> One more suggestion came to mind: In my city (see signature below), probably as
> in most, the streets aren't GPS-friendly, i.e. they're on an angle rather than
> being strictly north/south and east/west. Where I live the angle seems to be
> about 30 degrees (well, actually, 330 degrees). One way for Loadstone-GPS to
> "follow" a street, which I realize is technically impossible since it's
> points-based, might be to have a setting which favours longer substring matches
> on point names when the eligible points are reasonably close together.
>
> Is there a way to list the currently checked points?
>
> -- 
> Dave Mielke           | 2213 Fox Crescent | I believe that the Bible is the
> Phone: 1-613-726-0014 | Ottawa, Ontario   | Word of God. Please contact me
> EMail: dave at mielke.cc | Canada  K2A 1H7   | if you're concerned about Hell.
> http://FamilyRadio.com/                   | http://Mielke.cc/bible/
> _______________________________________________
> Loadstone mailing list
> Loadstone at loadstone-gps.com
> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>


More information about the Loadstone mailing list