[Loadstone] Find & show area

Shawn Kirkpatrick shawn at odyssey.cm.nu
Sun Jan 13 04:23:45 GMT 2008

There's no real duplicated functions in navigation and exploration mode. 
There are similar functions, like find point and show area but they 
act different depending on the mode. In exploration mode find point and show 
area start from your virtual position but in navigation mode they start from 
the current gps position. A small difference but an important one.
In exploration mode using the arrows for anything doesn't really work 
because the 4 way arrows are a bad fit for the 8 numeric keys. I have plans 
at some point for the arrows anyway so there current functions will change 
in exploration mode at some point.
As far as the numeric keys in exploration mode go, short press moves and 
long press looks. It's going to stay that way, the reverse way was tried and 
the entire developement team hated it to the point where they refused to use 
the versions with this in. At some point the keys in exploration mode may be 
mapable so the user could set this up how they'd like.
I don't think any of the keys in exploration mode should be relative to 
current heading, the idea is to have a stable base to work with while 
exploring an area. To have relational data is what navigation mode is for.
In a result list hitting select will move the exploration mode focus to the 
current result. If this is done in navigation mode then exploration mode is 
Of course a lot of these changes are coming in the next release, the current 
release was the first try with the new find point and show area system.
Getting the find point and show area to work with checkpoints only may or 
may not happen. There's a lot of technical problems getting the checkpoint 
information to these functions. It would turn a currently rather clean and 
optimized bit of code in to a nightmareish confusing mess.
  The size of the database will effect the speed of all queries. This 
because the database engine on the phone really sucks. We need a free, open 
source database that'll run on series60 v1, v2, and v3. If anyone can find 
this I'd be very happy.
The search radius kind of works like you describe. It starts off 
small creating a latitude/longitude box to search within and then expanding 
until it hits the maximum radius specified.

On Sat, 12 Jan 2008, Ari Moisio wrote:

> Hi Shawn
> On Thu, 10 Jan 2008, Shawn Kirkpatrick wrote:
>> There's a bit of inconsistancy with the keys in navigation and exploration
>> mode, mainly with the long star and shift star. This because in navigation
>> mode the shift star was already used and in exploration mode long star has
>> been allocated to the new show point comment function that was deemed to be
>> more often used than the find point function. Since the keys in navigation
>> mode can be remapped the user can fix the inconsistancies if it's a real
>> problem.
>  After remapping keys we have duplicate keys sets in both exploration and
> navigation modes.
>  Here a one proposal more: applicable for bot exploration and navigation
> modes:
> - Short arrows and shifted arrows as usual although it would be nice to
> arrows in the exploration mode also use up arrow as heading of last
> movement, virtual or real. There are already keys for compass direction
> lookarounds. If we have to use shifted and long keyp resses because lack
> of key first thing would be to remove duplicate plain key commands. Also
> to have consistency as much as possible. For example using shift key to
> bypass check status is a good idea but it should be then implied
> everywhere. Another consistency item is to have short key presses for
> looking around and long for virtually moving. Also having keys function
> similar for most situations, ie not look forward in one mode ad look north
> in another would help beginner get familiar with the application.
> - Long arrow keys open show area -like list in given direction, +- 55
> degrees or so to avoid  dead cones. if there are chekced points only those
> are shown.
> - Shift + long arrows similar to long arrows but showing all points
> regardles of their chek status.
> - Long select will open find point -type dialog. If search string is left
> empty it will list all found points in given area. ONe extra selection is
> a check box to select if only checked points are included. For consistency
> reasons this box could be checked with plain long select if there are any
> checked points and not checked with shifted long select.
> - When pressing select in result list LS will enter exploration mode with
> focus on selected point.
> About execution times:  if search string es empty there is no need to
> perform any string comparisons either.
>  If number of result have severe impact on search times there are
> something very severely broken in the search engine.
>  If we have a search radius one way to minimize computation is to
> calculate limits for lat and lon coordinates and calculate exact distance
> only those items within those ranges. In this setting it also makes sense
> to have lower search radius. Continue search might then expand this radius
> and search for new points.
>> The show area and find point functions are almost the same as far as code
>> goes but the show area doesn't do a string search. The reason for this is
>> clear, show area is for looking at what's around you without knowing any
>> part of the name, and find point is to find a point when you know the name
>> or partial name of the point you're looking for. A find point will be slower
>> than a show area because of the additional work involved with the text
>> comparison.
>> If you have a small database then getting results will be quite fast. Scale
>> this up thoe, say 100000 points or so, and things start to slow down quite a
>> bit. At those levels even 10 results for a show area will take a few
>> seconds. The higher the number of returned results the longer the response
>> time will be.
>> When doing a find point you don't really need fine resolution since the
>> exact location of the point isn't known or you wouldn't need to find it in
>> the first place. Having the search radius in kilometres doesn't prevent the
>> function from finding a point less than a kilometer away and has no effect
>> on the way the distance is reported.
>> As far as units go it probably makes the most sence to have them in the most
>> common representation that people will use for the given purpose. This means
>> that larger values would be in kilometres and smaller ones in metres.
>> On Thu, 10 Jan 2008, Ari Moisio wrote:
>>> Hi Shawn
>>> On Wed, 9 Jan 2008, Shawn Kirkpatrick wrote:
>>>> The new system does something like that. In navigation mode the long arrows
>>>> will do a show area in that direction and long select does a show area in
>>>> all directions. Find point can be mapped to a key and defaults to long * but
>>>> that may change before release. In exploration mode shift of the numeric
>>>> keys will do a show area in the given direction and shift 5 will do it for
>>>> all directions. There's a shortcut to find point with shift *.
>>>  Ok,  sounds good. There is however still inconsistency between navigation
>>> and exploration modes.
>>>> There's probably no point in bringing up the dialog on a show area since
>>>> it's likely to find something unless you have a database with not much in it
>>>> and an unreasonable search radius.
>>>  I still wonder is the only difference betweeen find point and show are
>>> the lack of dialog in the show area -function. For end-user's point of
>>> view two almost similar functions is no good at all.
>>>> You couldn't represent the search results in screenfulls (on what size
>>>> screen?) since there's only one result on screen at any one time. More often
>>>> than not you want a low number of search results to start with anyway.
>>>  There were those quotation marks  for a reason. Why shall i want a low
>>> number of results  at first time. Even 6680 can calculate 25 results - my
>>> current default - faster than screen reader could read the first line.
>>>> Having the search radius in kilometres makes sence since you're probably
>>>> searching for points further away from the current position. Having the
>>>> number in metres would just result in bigger numbers.
>>>  Bigger numbers but also finer resolution. For orientation purposes some
>>> point at south 2.7 kilometers apart is quite useless.
>>>> Unfortunately the user interface just doesn't seem to provide any good to
>>>> specify what units things should be in. By the time you get the prompt up
>>>> there's no room for anything else. Even worse symbian does provide for doing
>>>> things like this but series60 doesn't use those fields for some reason.
>>>  For this reason units should be as consistent as possible.
>>>> On Wed, 9 Jan 2008, arimo at iki.fi wrote:
>>>>> Hi
>>>>> On Tue, 8 Jan 2008, Shawn Kirkpatrick wrote:
>>>>>> This could probably be done but that would introduce an extra step in the
>>>>>> show area function making it a bit slower to access.
>>>>>  The access speed difference is plusminuz zero, one extra selecto for one
>>>>> less arrow down. There is currently six keystrokes to get from navigation
>>>>> mode to show area.
>>>>>> Access to these functions has been improved for the next version.
>>>>>  Great:-) How about following scheme in both navigation and exploration:
>>>>> arrow will open show area -type list in given direction and pressing
>>>>> select will open current find- type dialog in all directions.
>>>>>  To stay even more consistent between exploration and navigation modes
>>>>> arrow up could always be  'in front', ie  in exploration mode heading of
>>>>> latest virtual movement.
>>>>>> I've been thinking of making the find dialog save the last search criteria
>>>>>> but don't know if it'll get put in or not.
>>>>>  I'll vote to put it on.
>>>>>> For the results field you can type in the number instead of using the
>>>>>> arrows. I think the adjustment step is handled by the dialog framework and
>>>>>> might not be adjustable.
>>>>>  Ok... how about  defining it as a 'screenfulls', ie for example ten
>>>>> results per single unit?
>>>>>> The search radius is in kilometres, consistant with other things.
>>>>>  I haven't found any other setting presented in kilometers so far.  They
>>>>> are in metres, seconds or just numbers.
>>>>> You can still escape from the Gates of hell: Use Linux!
>>>>> --
>>>>> mr. M01510
>>>>> _______________________________________________
>>>>> Loadstone mailing list
>>>>> Loadstone at loadstone-gps.com
>>>>> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>>>> _______________________________________________
>>>> Loadstone mailing list
>>>> Loadstone at loadstone-gps.com
>>>> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>>> You can still escape from the Gates of hell: Use Linux!
>>> --
>>> mr. M01510
>>> _______________________________________________
>>> Loadstone mailing list
>>> Loadstone at loadstone-gps.com
>>> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>> _______________________________________________
>> Loadstone mailing list
>> Loadstone at loadstone-gps.com
>> http://www.loadstone-gps.com/mailman/listinfo/loadstone
> You can still escape from the Gates of hell: Use Linux!
> -- 
> mr. M01510
> _______________________________________________
> Loadstone mailing list
> Loadstone at loadstone-gps.com
> http://www.loadstone-gps.com/mailman/listinfo/loadstone

More information about the Loadstone mailing list