[Loadstone] Database redesign
arimo at iki.fi
Thu May 8 13:08:46 BST 2008
On Thu, 8 May 2008, Shawn Kirkpatrick wrote:
> 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.
Still no joy. Chekpoint only does not affect the situation at all. In
fact all points are visible in in the show area command. Those whose
location i haven't changed are marked checked.
One more weird thing. Due to gps drift i'll hear occasionally arrival
announcements about point that appears not to be checked, it is one of
those with changed coordinates. I cannot tell if the point is the point
in the database or the point in the checkpoint list. Auto-announce is btw
> 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.
I think this is good enough.
> 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:
>>>> 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
> Loadstone mailing list
> Loadstone at loadstone-gps.com
You can still escape from the Gates of hell: Use Linux!
More information about the Loadstone