[Loadstone] Database redesign

Shawn Kirkpatrick shawn at loadstone-gps.com
Thu May 8 12:45:16 BST 2008


The user id problem hasn't come up so we'll deal with that if/when it does. 
We're stuck with it for now anyway.
Your edited checkpoints would have been loaded, activate use checkpoints 
only and you'd probably see them. In normal opperation only the database is 
scanned for point information. This may have to be tweaked to include 
checkpoints that may not exist in the current database.
If you use a byte correctly you could have 16 main levels with 16 sublevels. 
This would make database query construction kind of difficult thoe if you 
want to search for multiple types and subtypes. When it's all said and done 
it'll probably have 2 bytes for the type system.
This database redesign is quite a ways off thoe.

On Thu, 8 May 2008, Ari Moisio wrote:

>
>
>
> On Thu, 8 May 2008, Shawn Kirkpatrick wrote:
>
>> I think your math is a little off when calculating the odds of duplicate
>> user ids. You'd have to come up with two different strings that'll produce
>> the same crc 16 hash for this to happen.
>
>  There is only 65536 differrent crcs and  iirc the birthday theorem with
> 256 strings the probability for two strings with similar crc-16 will be 50
> %.
>
>
>> When a point is created it gets an id and userid, thest don't change. On
>> import the points are checked to see if they have an existing id and userid
>> and if so the data is updated. If you import out of date data then the
>> point's data will also get set to the out of date value. Not much you can do
>> about that. A last modified field would be an extra 4 bytes per entry and
>> that's just a bit much for the purpose.
>
>  Well... i would sacrifice few bytes for the description field to be
> enable to collect and update data with all three  phones i currently use.
>
>  In  addition it is nice to know how recent any point data is.
>
>> The new checkpoints files contain all a point's information. When
>> checkpoints are loaded the point's id and userid are looked up in the
>> currently loaded database. If found the information from the database is
>> used and if not then the information from the file will be used as is. This
>> is why your experiment didn't work.
>
>  I  changed the id field of nearest checkpoints (the field before the
> comment). Still same behavior.  Points with altered coordinates are not
> checkecd anymore. There is no altered descriptions either. There is no
> duplicate points near each other as one could expect.
>
>> A point typing system may only require one extra byte per entry, you can get
>> 256 values in that.
>
>  with one level of categorization the categories should be broad enough to
> contain  a lot of POIs and services. For example all bars and restaurants,
> all health related, all sports related,  all transport related an so on.
> Othervise searching will  become hit and miss. Look for example
> categorization used in Nokia Maps. It has two levels oand aPOI can belong
> to many categories. This is not possible with one byte.
>
>
>> On Thu, 8 May 2008, Ari Moisio wrote:
>>
>>> Hi
>>>
>>> On Wed, 7 May 2008, Shawn Kirkpatrick wrote:
>
> 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