Missing GSAK "User Notes" Log

10 views
Skip to first unread message

Jason Blauert

unread,
Jul 13, 2010, 7:54:20 PM7/13/10
to GeoHunter
I elluded to this issue before and took some time to try to figure out
what was going on.

GSAK exports the "User Notes" and "Log Section" in the Groundspeak log
format with an ID=-2. These fields are where I put the details on
puzzle solutions of notes about how to locate a cache.

The problem is that these are not all showing up in the GeoHunter
cache details ... from my testing, it looks like the GSAK log only
appears for the last cache in the gpx file.

I am going to try to upload 2 files "GH_test_AtoZ.gpx" and
"GH_test_ZtoA.gpx". They contain 2 regular caches that I added the
GSAK notes log, but they are written in opposite order in the GPX
file.

When I use the AtoZ file, I can only see my GSAK log for "Zen Garden
Oasis".
When I use the ZtoA file, I can only see my GSAK log for "Deep to let
field".

I started looking at the source code to see if maybe I could try to
learn to try some things myself ... but did not get very far. There
are a few other outputs from GSAK has that I would also like to see
included in the cache details, but that would probably require more
work.

I am hoping that the missing log is a pretty straight forward fix that
you have not encountered because you do not use GSAK.

Thanks.


Anders Petersson

unread,
Jul 14, 2010, 5:35:00 AM7/14/10
to geoh...@googlegroups.com
Oh, now I realize -- all log entries need to have a globally unique id. It's the key in the DB table.
You can try to change id=-2 into something that's globally unique but the same within a geocache. (Always creating a new id would lead to multiple entries when re-importing)

/Anders

Jason Blauert

unread,
Jul 14, 2010, 12:44:53 PM7/14/10
to GeoHunter
Ah so it is an easy problem to identify ... just not to fix. Setting
the id = -2 is something that GSAK does automatically, I am not sure I
have the capability to generate a unique id for each cache. I will try
to check out the GSAK forums to see if this has caused an issue
before. Any chance you can think of an "easy" way to modify GeoHunter?
I kind of find it hard to believe that in the whole world I am the
only one using GSAK and GH and see this problem.
> > Thanks.- Hide quoted text -
>
> - Show quoted text -

Robert Lipe

unread,
Jul 14, 2010, 12:53:31 PM7/14/10
to geoh...@googlegroups.com
On Wed, Jul 14, 2010 at 11:44 AM, Jason Blauert <jbbl...@gmail.com> wrote:
Ah so it is an easy problem to identify ... just not to fix. Setting
the id = -2 is something that GSAK does automatically, I am not sure I
have the capability to generate a unique id for each cache. I will try
to check out the GSAK forums to see if this has caused an issue
before. Any chance you can think of an "easy" way to modify GeoHunter?

Having a non-unique ID is weird.  Tell Clyde I said so. :-)   Using the ID as a primary key is a very natural thing to do, but they have to be unique.

Perhaps he could use the ID# of the geocache and flip the sign bit or  shove it into a high numerical range or something.

RJL

Anders Petersson

unread,
Jul 14, 2010, 1:04:31 PM7/14/10
to geohunter
My idea was to change -2 into something else in GeocacheData.java, before writing the logs to the database. Robert has a point; geocaches do have an integer id as well. I don't think we use it at the moment. Flipping the sign of that should work although it's weird from a design POV. It's ok with me.

You can do special handling of negative log ids in DetailsTab, to make it appear first in the list or something.

I also notice other custom elements when looking at the GSAK GPX, like <gsak:DNF>false</gsak:DNF>. That wouldn't be too hard to parse in GH.

/Anders

Jason Blauert

unread,
Jul 14, 2010, 1:13:16 PM7/14/10
to GeoHunter
Thinking about this more, I guess I do not fully inderstand how the GH
database is put together.

So, is it correct that the logs are put into a separate database and
then accessed through their LOG ID from a specific GC which has a list
of IDs? Although if that wre true then I would think that every GC
that had a LOG ID = -2 associated with it, would display the log for
the last GC in the GPX file (which would have written over all the
previous -2 ID logs).

So are the logs are not stored with a specific cache? If so, I would
not have thought there would be a problem. I know have can see all my
notes in other programs I have used (CacheMate on PocketPC, and I
think they show up in OpenGPX on android)

And I just tried GeoBeagle and they show up for all the caches ...
which surpirsed me since GH is based on GB. Any idea what is being
done differently? I hate to have to jump back and forth. This is
almost something that would push me back to using GB, although there
are a lot of features I like in GH.

On Jul 14, 2:35 am, Anders Petersson <and...@gmail.com> wrote:

Jason Blauert

unread,
Jul 14, 2010, 1:20:01 PM7/14/10
to GeoHunter
I just wrote a response but now I don't see it.

I also considered flipping the sign on the last unique log ... but I
do not think that functionality is somethine I have access to
modifying in GSAK.

I would love if the negative log showed up first, but is there a way
to do it without me getting clyde to change GSAK?

Interestingly, I just found that all the logs show up in GeoBeagle ...
any idea what they do differently? I hate to have to switch back and
forth or just give up the nice features of GH.

Yes there are a few other GSAK specific fields that I would also like
to be able to see and I assumed would probably not be too hard to
implement (I was thinking of giving it a shot myself, but have no
experience in this language and looking at some of the source ... I
got lost). This is certainly lower priority though.
> > > - Show quoted text -- Hide quoted text -

Anders Petersson

unread,
Jul 14, 2010, 1:20:17 PM7/14/10
to geohunter
The handling of logs is changed since GB.
Look at DatabaseConstants.java:
    public static final String SQL_CREATE_LOGS_TABLE = "CREATE TABLE LOGS "
        + "(LogId INTEGER PRIMARY KEY, CacheId VARCHAR NOT NULL, LogType INTEGER, "
        + "LogDate DATETIME NOT NULL, FinderName VARCHAR, Text VARCHAR, "
        + "IsTextEncoded BOOLEAN NOT NULL)";
There's a separate table for logs and they each know which cache they belong to.

It's possible to handle your special case as outlined in my previous mail.
/Anders

Jason Blauert

unread,
Jul 14, 2010, 1:20:39 PM7/14/10
to GeoHunter
OOPS ... now they both showed up.

Jason Blauert

unread,
Jul 14, 2010, 1:23:30 PM7/14/10
to GeoHunter
Sorry, I keep think of other things.

I see that GSAK allows output in GPX 1.0 and 1.1 ... is there any
advantage / disadvantage of useing either? I have only used 1.0 up to
this point and when I compared both versions side-by-side, it looked
like some formatting differences.

Robert Lipe

unread,
Jul 14, 2010, 1:23:35 PM7/14/10
to geoh...@googlegroups.com
On Wed, Jul 14, 2010 at 12:04 PM, Anders Petersson <and...@gmail.com> wrote:
My idea was to change -2 into something else in GeocacheData.java, before writing the logs to the database. Robert has a point; geocaches do have an integer id as well. I don't think we use it at the moment.

You can be pretty sure that's the primary key of the tables at gc.com  and the GCfoo stuff is a generated field, if it's stored at all.   You can't autoincrement a GCfoo number...

 
Flipping the sign of that should work although it's weird from a design POV. It's ok with me.

I agree.   I was just offering that as something that's unique. 


RJL

Robert Lipe

unread,
Jul 14, 2010, 1:59:27 PM7/14/10
to geoh...@googlegroups.com
On Wed, Jul 14, 2010 at 12:20 PM, Anders Petersson <and...@gmail.com> wrote:
The handling of logs is changed since GB.
Look at DatabaseConstants.java:
    public static final String SQL_CREATE_LOGS_TABLE = "CREATE TABLE LOGS "
        + "(LogId INTEGER PRIMARY KEY, CacheId VARCHAR NOT NULL, LogType INTEGER, "
        + "LogDate DATETIME NOT NULL, FinderName VARCHAR, Text VARCHAR, "
        + "IsTextEncoded BOOLEAN NOT NULL)";
There's a separate table for logs and they each know which cache they belong to.

I suspect that's approximately what most geocaching apps look like under the covers.    I'd wager it's almost what it looks like at geocaching.com's db, too, though they probably hook a user ID instead of a VARCHAR findername, but I've never seen that to be worth the effort on client-side apps.   

RJL

LEGO Cacher

unread,
Jul 14, 2010, 9:26:52 PM7/14/10
to GeoHunter
Jason:
I did a lot of the work on the current format of the logs / detail tab
in geohunter. I also use GSAK, but I never enter any user notes or
anything. Please send me a small export file from GSAK that contains
more than one cache with logs with ID -2, and I will fix this.

Anders Petersson

unread,
Jul 15, 2010, 3:13:24 AM7/15/10
to geoh...@googlegroups.com
Hi Ted
Files for this are already available at
http://groups.google.com/group/geohunter/files

Are you going to do the solution using negative cache id instead of -2?
/Anders

Theodore K. Milbaugh

unread,
Jul 15, 2010, 8:10:38 AM7/15/10
to geoh...@googlegroups.com
Anders:
Using the negative cache id would allow us to store one "user notes" record per cache, BUT there are several potential problems. The biggest one that I am familiar with (because I was using GSAK exports with GH before the BCaching integration) is that it is possible for the user to manipulate the data before & during the GSAK export. We might end up with non-unique ids again.

I propose adding a USER_NOTES table. This would allow us to not only store the GSAK notes, but add a feature in GH to allow the user to store notes for each cache.

Another possibility is to add another column to the existing table for a generated ID for each log, so we never end up with duplicates.

Anders Petersson

unread,
Jul 15, 2010, 8:25:52 AM7/15/10
to geoh...@googlegroups.com
A USERNOTES table or a new column in CACHES would be great.
You're welcome to go ahead with that.

The idea used to be to keep user-specific data and global data like geocache details separated. That's one reason why TAGS contains also some basic flags. I'm not sure what advantage the separation brings so it's fine with me to put user notes into the main CACHES table.
/Anders

Jason Blauert

unread,
Jul 15, 2010, 6:54:31 PM7/15/10
to GeoHunter
I think adding a User_Notes section table/column sounds like it could
be pretty useful. Allow the GSAK notes to be imported from the GPX
files but also that could maybe allow anyone in the field to add a
note about a specific cache ... for example, information about the
next point of a multi-cache.

Just sorry my coding skills are not up to par to be able to help with
some of this.

Thanks though ... look forward to seeing what gets implemented.
> > /Anders- Hide quoted text -

Jason Blauert

unread,
Jul 19, 2010, 6:41:00 PM7/19/10
to GeoHunter
Not to be pushy or anything, just trying to determine the appropritate
follow on.

If I come up with these issues, is it best to create an issue on the
code development page or to post the question here in the discussions
as I have done?

I was just looking through the code dev pag and did not see this
included in the list of issues/enhancements ... just wondering if I
should add it so that it is not forgotten.

Thanks for all the hard work.

Json
> > - Show quoted text -- Hide quoted text -

Theodore K. Milbaugh

unread,
Jul 19, 2010, 10:53:56 PM7/19/10
to geoh...@googlegroups.com
I have committed preliminary work on this issue. How does this look to you? I will work a little on the GSAK icon to make it a look a little better (I have permission from Clyde to use it).

usernotes.png
usernotes.png

Theodore K. Milbaugh

unread,
Jul 20, 2010, 6:49:55 AM7/20/10
to geoh...@googlegroups.com
When you declare a column with "INTEGER PRIMARY KEY", then inserting null causes the column to auto-increment.
The UserName column will hold "GSAK" for the notes from that program, and would hold the user's name for the ones that are entered in GeoHunter.

On Tue, Jul 20, 2010 at 5:22 AM, Anders Petersson <and...@gmail.com> wrote:
The code looks good to me. One note though -- you modelled the USERNOTES table after the LOGS table. Doesn't really seem necessary to include UserName and IsTextEncoded. NoteId also seems to go unused. (Does inserting with primary key NULL mean that it's assigned an id automatically?) This is fine although we might come back to refine it down the road.

Regarding registering issues, I personally prefer to keep them in the tracker to get an overview of what's going on. For isolated and quick work it's not that important.

/Anders

PS. Note the "DB" tab to the right.

Jason Blauert

unread,
Jul 20, 2010, 1:46:28 PM7/20/10
to GeoHunter
That looks good to me and would certainly help me out.

Does this go down the route of negating a number associated with the
cache.
Or is it a more general notes field (new table) that could either
import the GSAK data or allow real-time user inputs?

The later seems like a good idea in general ... maybe it would not
have to hold the GSAK data, but beign able to write notes "in-the-
field" about a cache would be a nice addition to the program.

Thanks.
> > PS. Note the "DB" tab to the right.- Hide quoted text -

Jason Blauert

unread,
Jul 20, 2010, 1:50:42 PM7/20/10
to GeoHunter
Just looked at the code dev page and it looks like you have added (or
are working) on both capabilites I just asked about ...
getting the GSAK inputs and adding UserNotes.

I am kind of jealous that I can not work on this code as well ...
maybe I should start reading up on java/xml.

Can't wait for the release!!! Thanks!!!
> > PS. Note the "DB" tab to the right.- Hide quoted text -
Reply all
Reply to author
Forward
0 new messages