Very important GPX request.

January 28, 2003

Okay, as you obviously know, I've been working on Watcher for over 6 weeks or so, and it's come a long way. There's just one thing that continues to bother me about it, and I believe I've come to a logical conclusion. Obviously, I am not the judge of that, but the case is substantial and rather clear-cut.

Simply put, there is a pressing need for an element or attribute that can hold the date/time that a given cache waypoint was exported.

Why is this necessary? Watcher (and other programs) can merge several GPX files into one GPX. This is very useful for those people who need multiple queries to cover a given area, or who have several subsets of their local caches returned by different queries. When one GPX file is merged with another, you simply take the date/time of the one GPX and compare it with the next; however, when you take that merged GPX and in turn merge another GPX into it, how can you know which elements are newer?

The short answer is, you can't. You *could* compare log IDs, or you could search for the latest placed cache, or you could try a number of other kludges, but none of them can give you enough knowledge about a given element to tell whether the original one or the merging one is the most current. The only way to know with certainty the date/time a element in a merged GPX file was exported by a pocket query is to have that information in the merged GPX file. The additional line in the .xsd would be something like this (if it were to be an element):

<xs:element name="exported" msdata:Prefix="Groundspeak" type="xs:string" minOccurs="0" />

Note, however, that there is *no* need for Pocket Query-generated GPX files to include this information in the elements. As long as it is in the definition that it *can* be there (but not that it *must* be there), Watcher (or any other GPX-merging application) can simply add the information to the GPX file at the time of merging. (When I merge, I'd just have to mark all the existing caches as exported on the date/time of the original file, and the waypoints being merged would be marked as exported on the date/time of the file being merged.)

With this in the schema definiton, I will be able to update my GPX merge code to *always* use the latest available for each cache, which will mean that the possibility of not using the newest data due to a merge will cease to be the problem that it currently is. Since most people have been merging concurrent queries, this has not yet been much of a problem, but with more usage of Watcher and other GPX applications, it's only a matter of time before someone merges an older file into a newer file and ends up with stale waypoints. With a simple line or two, you can make it possible for me to head off the problem before it becomes a problem.

1.7k · January 28, 2003

quote:
Originally posted by ClayJar:
Note, however, that there is *no* need for Pocket Query-generated GPX files to include this information in the elements. As long as it is in the definition that it *can* be there (but not that it *must* be there), Watcher (or any other GPX-merging application) can simply add the information to the GPX file at the time of merging.

I agree that this is something best added to the Groundspeak namespace, but in case it never gets approved, you could always consider adding your own schema and namespace to the pile, just as Groundspeak did, or lobbying to have the item added to the gpx namespace (it seems useful for more than just geocaches, in my opinion.) There is a gpx:time element, but Pocket Query GPX files use that to indicate the date the waypoint (i.e. the cache) was created, and that usage seems important too.

Of course, creating your own schema and namespace only works if the paragraph I've quoted above is true, and I'm not sure that it is (what if I have a "southern indiana" query and a "northern indiana" query that overlap, and I merge two of those? What if one is significantly newer than the other but neither has ever gone through Watcher?)

1.6k · January 28, 2003

I just looked at something. I took a recently received query and saved it from email. The time stamp was the current time--10:33AM. However, when I extracted it was earlier in the day, 6:50AM.

Wouldn't that be the time it was generated? A kludge, but maybe you could look at file date if it doesn't have an embedded time stamp that you create. Better than nothing.

Of course, Groundspeak embedding the time stamp would be best.

Just thought of something. You might want a "last modified" tag, as well. This would let users know the file is not as it came from Groundspeak. Just a thought.

CR

January 28, 2003

quote:
Originally posted by Warm Fuzzies - Fuzzy:
Of course, creating your own schema and namespace only works if the paragraph I've quoted above is true, and I'm not sure that it is (what if I have a "southern indiana" query and a "northern indiana" query that overlap, and I merge two of those? What if one is significantly newer than the other but neither has ever gone through Watcher?)

The heuristic is simple, really. If a given cache has a "Groundspeak:exported" node, use that as that cache's timestamp, else use the "/gpx/time" node. If neither GPX has ever gone through Watcher, there will be no "Groundspeak:exported" nodes and the "/gpx/time" nodes will be the sole arbitrator of which GPX is canonical. If a given cache *does* have a "Groundspeak:exported" node, that is used instead of the GPX file's "/gpx/time" node when determining canonicity.

(As an aside, if "exported" is not added, I'd probably toss the value into a "Groundspeak:attribute" under "Groundspeak:cache/Groundspeak:attributes". It'll be a rather ugly kludge, but not so ugly as having to extend the namespace myself. It should be a moot point, though, since it's a thoroughly logical addition to the Groundspeak namespace, and it won't cause one iota of extra work for Geocaching.com. )

January 28, 2003

quote:
Originally posted by Sissy-n-CR:
I just looked at something. I took a recently received query and saved it from email. The time stamp was the current time--10:33AM. However, when I extracted it was earlier in the day, 6:50AM.

Wouldn't that be the time it was generated? A kludge, but maybe you could look at file date if it doesn't have an embedded time stamp that you create. Better than nothing.

Of course, Groundspeak embedding the time stamp would be best.

The timestamp of the file in the filesystem is completely arbitrary, and I neither based nor will base anything on the filesystem timestamp. There is a single timestamp in the GPX at "/gpx/time" that contains the time at which that particular GPX file was compiled by the Pocket Query generator. That timestamp can be used for merging GPX files that come from Pocket Queries.

The problem at hand is simply this: If you merge two GPX files, there is not currently a place in the namespace to specify a timestamp for each waypoint in the merged file. Since the merged GPX is potentially made up of components from multiple Pocket Queries, the compilation time is not defined. If we were to merge another Pocket Query with this merged GPX, we could not reliably determine which waypoints are canonical.

Take, for example, three Pocket Queries:

PQ1: January 1, 2003 (All Louisiana traditional caches)

PQ2: January 3, 2003 (All caches within 50 miles of me -- some are in Mississippi)

PQ3: January 5, 2003 (All Louisiana non-traditional caches)

So, I get all three PQs, and I decide that I want to merge PQ1 and PQ3 so that I'll have a merged Pocket Query containing all the caches in Louisiana. I do that, and now I end up with PQ(1+3), a single GPX file with all the Lousiana caches in it.

Well, now I decide that I'm going to take a cache trip up from Baton Rouge all the way to lower Missippi, so I need to merge PQ2 into my GPX so that I'll have it in my PocketPC*. When I go to merge PQ2 with PQ(1+3), I run into a problem. Are the cache listings in PQ2 newer than those in PQ(1+3), or are they older?

If when I merged PQ1 and PQ3 I used the "/gpx/time" for PQ1 as the "/gpx/time" for PQ(1+3), the cache listings in PQ2 will replace the cache listings in PQ(1+3), and so, any caches that were in PQ2 and PQ3 will be replaced with their older listings from PQ2, and any changes or logs on January 3-5 will be lost.

On the other hand, if when I merged PQ1 and PQ3 I used the "/gpx/time" for PQ3 as the "/gpx/time" for PQ(1+3), the cache listings in PQ2 will *not* replace the cache listings in PQ(1+3), and so, any caches that were in PQ1 and PQ2 will *not* be replaced with their newer listings from PQ2, and any changes or logs on January 1-3 will be lost.

On the third hand, if when I merged PQ1 and PQ3, I tagged each cache with a "Groundspeak:exported" node which contained the timestamp from the "/gpx/time" node of the GPX from which that particular cache came, when I merge PQ2, I will be able to tell which caches are newer in PQ2 (because they were compiled at PQ1's timestamp) and which caches are older in PQ2 (because they were compiled at PQ3's timestamp). I will then be able to merge PQ2 with PQ(1+3) to end up with a PQ(1+2+3) that contains the latest cache listing for each cache in the merged GPX.

So, basically, my request is simply to have some place in a merged file to save the individual cache listings' exported timestamps, and that's what I've asked Jeremy, et al, for.

quote:
Just thought of something. You might want a "last modified" tag, as well. This would let users know the file is not as it came from Groundspeak. Just a thought.

That's not necessary if the waypoints in the GPX file have their compilation times specified. You wouldn't need to know when the file was last modified, since it doesn't matter when you saved -- it only matters when the data was compiled (since Watcher does not edit the content, only the presentation, of the waypoints in the GPX).

(Incidentally, if this is added, which I can't see why it wouldn't be, Watcher will shortly be updated to display when a cache was last exported. That way I'll be able to show exactly how out-of-date the cache details could be, instead of just saying that they might be old. I can't be specific yet, of course, since there is no way of knowing whether a GPX file was a result of a merge.)

*No, I don't have a PocketPC.

[This message was edited by ClayJar on January 28, 2003 at 08:41 AM.]

1.6k · January 28, 2003

Oh, okay, I understand the problem a little better.

However, wouldn't the time stamp of the GPX file from Groundspeak be the same as any time stamp embedded in the GPX file itself? (Maybe a few seconds later.) After all both would be pulled from the same place, right? It's not what is best, but I don't see that the file's time stamp would be arbitrary. I'm thinking it would also be system time of the GS server until you modifiy it. You establish the waypoint's timestamp with that until such time GS implements it. Then you can test for the tag.

It's secondary processing and it's contingent on the query's file timestamp being preserved in the zipped file--very much a kludge and probably not worth the effort anyway.

CR

1.6k · January 28, 2003

Never mind. After looking at the GPX file itself, I see the gpx/time you were talking about and it's the same as the file stamp. So you already have it.

I'm glad you programers are patient with us clueless people.

CR

1.6k · January 28, 2003

Question: would LASTMODIFIED be better and actually give more information?

Here's my thinking, EXPORTED only gives the date and time of the waypoint exported, but LASTMODIFIED would not only let you determine the newest version of the cache page, but also how long ago it was modified. This along with the latest logs could add to how up-to-date the cache is. So a cache that doesn't have a log for a couple of months and the owner has not updated the cache for a year is less likely to be there than one the owner has modified just last week even though the last log was a couple of months ago.

Of course, this relies on the fact of if GS even keeps a record of the cache page's last edit.

Which I think they do. Upon looking at one of my caches I see "Last Updated." Is that the last time I edited my page?

Thoughts?

CR

January 28, 2003

quote:
Originally posted by Sissy-n-CR:
Question: would LASTMODIFIED be better and actually give more information?

Here's my thinking, EXPORTED only gives the date and time of the waypoint exported, but LASTMODIFIED would not only let you determine the newest version of the cache page, but also _how long ago it was modified._ This along with the latest logs could add to how up-to-date the cache is. So a cache that doesn't have a log for a couple of months and the owner has not updated the cache for a year is less likely to be there than one the owner has modified just last week even though the last log was a couple of months ago.

While it may be nice, useful, or even divine to know when a cache page was last modified, that is completely irrelevant to this thread. Why?

The "/gpx/time" node tells you when the GPX was compiled. That is analogous to a "Best if used by:" date on a honey bun. You have no idea when the honey bun was created, but you know that as of "JAN 28 02", it was in nominally digestible condition. If you're a day or two past that, you know that it's probably still fine to consume, but you should check for blue-green spots first. If you're three months over, you know that you should use the honey bun for your next death-by-microwaves experiment, but don't trust it to be edible.

Now, if you know that the honey bun was created three years ago, and it has remained in its hermetically sealed package ever since, and it just expired a week ago, you'll probably say that it's likely still so-called edible. In the same way, if you know that the cache was last updated three months ago, and it's got a decent smattering of logs up until the cache details were exported last week, you'll probably figure it should still be in huntable condition. Having both "last updated" and "exported" could provide useful information.

BUT! If you only have last updated, that's like knowing when your honey bun was created. As you can imagine, that does not answer the question of "is this honey bun consumable?" If it was created yesterday, you're pretty sure it's edible, but if it was created three months ago, did they use enough preservatives to keep it intact that long? Maybe it's "best if used by: JAN 31 04", but maybe it's been expired for two months and thirteen days. How can you tell?

I've got a cache that was last updated well over a year ago. It hasn't had a find in a very long time. If you had "last updated" fields in a merged GPX file with that cache in it, you'd see that there's no new information since 9 or 10 months ago, but what you wouldn't know is how long ago that query was run. You could've run the query 7 months ago, and the cache could've been archived for 6 months, or you could've run the query yesterday with the cache still active.

You need to know when the information was canonical. When did geocaching.com show the cache as it appears in your GPX file? It doesn't matter how long the cache page has looked like that; it only matters that you know that on January 28, 2003 at 8:35am the page *did* look like that.

It would be nice to know last-updated, but as you can see, it doesn't give you the information you need to properly merge multiple GPX files.

9.1k · January 28, 2003

ClayJar's next project is a program called "Baker" which will track the expiration dates on your honey buns. A means it's edible, a means it's getting stale, and a means that mold is probably growing on it. You can sort your baked goods by product type, name of baker, date baked, and current condition.

x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x

If there's no accounting for stupidity, then why do I need to file a tax return?

1.6k · January 28, 2003

But you're looking to see which version of one waypoint is the most recent. Either LASTUPDATED or EXPORTED would do the trick. Even if the page hadn't been updated in forever nothing newer would replace it.

But say one file is stale and has our waypoint in it. A newer file would have the same information except possibly for the logs. If you merge, this will give you the opportunity to merge the logs as well--no need to discard the older logs.

Now, say the new file has the updated waypoint information. Not only will you know the waypoint is fairly fresh, but how fresh.

Because you will always be comparing an older file to a newer file and the LASTUPDATED timestamp will always be before the EXPORTED timestamp you can still use the LASTUPDATED to properly merge. i.e. get the most recent version of the cache page.

File "freshness" is also good, but while we are getting queries on a weekly basis, we'll always know we have at least that fresh of a file. Generally.

Really, who cares how old the data is as long as we know it's the latest version? (as far as merging and whatnot.)

The downside to that is you can't generate that yourself. You could just go ahead and implement EXPORTED and let GS catch up. But you'd have to wait for GS to use LASTUPDATED.

Anyway, keep up the excellent work on Watcher. I do appreciate it.

CR

5.3k · January 28, 2003

The problem is that you need to know when the cache was last queried, not when it was last updated.

This very thing happened to me last night. Between the time that I did the query (Saturday) and yesterday (Monday) a cache got archived. If all the information I had was when the cache page was last updated, I would have had no idea that my query was old. I could be looking at caches that I retrieved months ago, and I would have no way of knowing that.

The whole point of the time stamp is to indicate when the cache information was retrieved from geocaching.com, so that you can identify out-of-date queries.

The problem with the LASTUPDATED time stamp is that it could very well be wrong, if the cache has been updated since the last time you did the query. The whole point of databases is to keep the information in them accurate; LASTUPDATED is just about guaranteed to be inaccurate.

January 28, 2003

quote:
Originally posted by Sissy-n-CR:
File "freshness" is also good, but while we are getting queries on a weekly basis, we'll always know we have at least that fresh of a file. Generally.

Really, who cares how old the data is as long as we know it's the latest version? (as far as merging and whatnot.)

Hypothetical situation:

I am not getting queries on a weekly basis; I'm collecting hydrocaches in all 50 states and several area countries.

I just decided to go hydrocaching in Alabama next weekend, so now I load up my "hydros of 50 states' and more" merged GPX.

I can't remember when I got the last Alabama GPX, since I've been collecting caches from all over and I didn't have hard drive space to keep them all.

Due to the weather, nobody has logged any of the Alabama hydrocaches since October.Question: Is my information on the Alabama hydrocaches current enough to risk the weekend on the assumption that the caches are still there?

*THAT* is why we need to know when the data was exported. You *cannot* answer that question using only last-updated and logs.

8.9k · January 28, 2003

In the database circles where I work, this is called "valuation date." This is what the data looked like "As of x Date." I agree this is key.

Really the only logical way to capture that data is precisely as Clayjar has suggested. When you talk about merging records and eliminating duplicates, you need each record date stamped with when the record was last captured out of the fluid database.

GS adding the field is not particularly difficult {dafaultvalue=now()} The problem I would think would be all of the development that has gone into the schema that GS currently provides. Does this goof up GPSBabel or even watcher? I don't know enough about the programming to know.

Markwell

Chicago Geocaching

January 28, 2003

quote:
Originally posted by Markwell:
GS adding the field is not particularly difficult {dafaultvalue=now()} The problem I would think would be all of the development that has gone into the schema that GS currently provides. Does this goof up GPSBabel or even watcher? I don't know enough about the programming to know.

No, it won't mess up Watcher or GPSBabel (GPSBabel doesn't do anything with the Groundspeak extensions other than copy the data, IIRC), but of course, it also won't do anything until the code is updated. I know Watcher's code will support intelligent merging within a day or so of the node being added.

Also, there's no need to have a default value. The node doesn't need to be in any GPX files created by Pocket Queries, since their cache listings are all of the same vintage. Only when GPX files are merged does the information need to be preserved on a per-cache basis. (So it doesn't need to take any additional resources or file size for Groundspeak to "support" the addition; it's all on the application developer's side, and I'll be glad to do the work.)

1.6k · January 28, 2003

Okay, I think I got it. What you're looking for is THE latest that GC has. You could very well have a very old waypoint that just so happened has not been included in any recent query. (So how would we know it hasn't been archived?)

Yeah, I see your point. If we were to only have one more tag, it'd have to be EXPORTED.

So, what about that archived waypoint? How do we know it just hasn't been just outside our query?

CR

January 28, 2003

quote:
Originally posted by Sissy-n-CR:
So, what about that archived waypoint? How do we know it just hasn't been just outside our query?

Actually, we don't know. At some point in the future, Geocaching.com might start adding some "web services" as they're called. If, at that point, they provided an API for checking the status of a cache or list of caches, I could add that to Watcher.

It might end up being something like "If this cache was exported over X days ago, check it's status on Geocaching.com," and Geocaching.com's servers might reply with a message that says something like "Not Archived, Not Disabled, Last Updated 23 Feb 2004, (Found, Not found, Other, Found, Found)" It doesn't really matter at this point.

For now, though, for us to be able to say that a given cache's information *was* correct at a given point only requires a one-line change to the schema definition. At least we'll be able to say when a cache was last exported, even if there is currently no way of knowing why a cache was not included.

8.9k · January 28, 2003

Ignore this post, I misread a statement.

5.3k · January 28, 2003

quote:
Originally posted by ClayJar:
it won't mess up Watcher or GPSBabel (GPSBabel doesn't do anything with the Groundspeak extensions other than copy the data, IIRC),

It won't mess up GPSBabel, but GPSBabel does grope the Groundspeak extensions for things like Smart Icons and when populating or reading GeocachingDB files to get diff/terr.

January 28, 2003

quote:
Originally posted by robertlipe:
It won't mess up GPSBabel, but GPSBabel does grope the Groundspeak extensions for things like Smart Icons and when populating or reading GeocachingDB files to get diff/terr.

Cool. I need to pay more attention to the rest of the world; I'm starting to miss really nice features.

(Now all I need to do is get around to the Watcher -> GPSBabel -> **EVERYTHING** layer. I *will* get around to it one of these days... unfortunately, my next free evening is a week from tonight. ...)

January 28, 2003

Another good reason for this synchronization date is the sorry state of cheap Palm development tools.

Namely, PDAToolbox: It's quite inexpensive, produces nice-looking apps, but doesn't reliably let you know when a record has been modified (if you even *looked* at it, it gets the "dirty" flag). Having an exported date will let you know what data came from where, and when.

Relevance? DougsBrat, Robert Lipe and I are working on various aspects of DougsBrat's GeocachingDB app for Palm/PocketPC. I decided to tackle the concept of sync/conduit, and it's driving me nuts trying to figure out what data is new.

I am Arrowroot, son of Arrowshirt. I have many names, you know

January 30, 2003

One of the main uses of Watcher is to collect and then filter the caches in your GPX files so that you can then use EasyGPS, GPSBabel, or any of the HTML, PalmDoc, or other format converters. I've been asked to start working on integrating some of these with Watcher, to make it simple to go to whatever format you want.

It would be nice to be able to tag the cache pages with the timestamp the data was exported, but there is no place in the Groundspeak XSD to preserve that data. I don't want to make another namespace just for Watcher, as that would require *everyone* to support it if we want to use the information cross-application.

Can someone up high take a moment to give us a PASS/FAIL on this thread so we'll know whether we need to all get together to hash out a new XSD or whether one line can be added to the Groundspeak cache XSD to allow us all to be on the same page. (As was said earlier, the Pocket Queries don't need to include the element; it just needs to be listed so we can all follow the standard.)

Well, anyway, I hope someone hears this thread soon. I really don't want to start working on exporting data to other formats until I can note in those exports when each cache entry was generated by geocaching.com, but I'm going to have to start one thing or the other soon... I can't sit still this long.

1k · February 2, 2003

Looks like this would be a great idea and simple enough to implement? Or at least give a yes/no to?

Some people are like Slinkies . . . not really good for anything, but you still can't help but smile when you see one tumble down the stairs.

February 4, 2003

I really hate to be a bother, and this is getting more and more uncomfortable each time I mention it again, but is there any possibility of hearing *anything* about this?

I don't even need a complete answer; an "ask me next month" would suffice. A yes or no to the idea would be ideal, but if it can't be given, even a "maybe" would be welcome. I just don't want to keep asking about it if you (Jeremy or Elias) are reading this and not answering for some reason.

(I would simply drop the idea entirely, except for the fact that it is a matter of critical importance; stale data *must* not be tolerated when it can be prevented, so one way or another, this node or one like it *must* exist.)

1.1k · February 6, 2003

Sorry I didn't get to this topic sooner. We're currently in the throes of developing the next site for Geocaching, which involves a lot of work. I had no idea how much asp was created for this site until I had to start converting it to dot net!

Anyway, I would say that yes, we could support this. I'm just trying to figure out why the timestamp doesn't work for you at the top of the file. As I understand it you just want the additional field for your own purposes so you don't have to create one yourself? We could certainly do that.

Jeremy Irish

Groundspeak - The Language of Location

February 6, 2003

quote:
Originally posted by Jeremy (Admin):
Sorry I didn't get to this topic sooner. We're currently in the throes of developing the next site for Geocaching, which involves a lot of work. I had no idea how much asp was created for this site until I had to start converting it to dot net!

Hehe... I feel your pain (a teeny, tiny bit). I once converted a *much* smaller application and ended up enjoying the process for a rather-too-long time. I hope you've got cleaner code than I had.

quote:
Anyway, I would say that yes, we could support this. I'm just trying to figure out why the timestamp doesn't work for you at the top of the file. As I understand it you just want the additional field for your own purposes so you don't have to create one yourself? We could certainly do that.

The reason we need a place to put a timestamp in the caches (as opposed to just at the top of the file) is that Watcher and other programs (GPSBabel, I think), can merge Pocket Query GPX files. When they do that, you can no longer use the single timestamp on the top of the newly created file, since it has waypoints from differing export times. (See this post for the full *why*, if this summary is too short.)

While Watcher and everyone else *could* use their own namespace to hold the data, it *is* Pocket Query data. It seemed far more logical for it to be in the Groundspeak namespace, even though the per-waypoint exported timestamp does not need to be included in the Pocket Queries -- all the Pocket Query-generated waypoints have one common export timestamp.

5.7k · February 7, 2003

quote:
Originally posted by Jeremy (Admin):
Sorry I didn't get to this topic sooner. We're currently in the throes of developing the next site for Geocaching, which involves a lot of work. I had no idea how much asp was created for this site until I had to start converting it to dot net!

If I didn't have a day job, this is the kind of thing I would do for fun. Well, that and geocaching.

--Marky

"All of us get lost in the darkness, dreamers learn to steer with a backlit GPSr"

February 7, 2003

quote:
Originally posted by ClayJar:
The problem at hand is simply this: If you merge two GPX files, there is not currently a place in the namespace to specify a timestamp for each waypoint in the merged file.

You've mentioned gpx/time an awful lot in this thread. What's wrong with using wpt/time (the timestamp of the waypoint)?

http://www.topografix.com/gpx_manual.asp#time

--

Dan Foster

TopoGrafix: GPS Software, Waypoints, and Maps

http://www.topografix.com/

February 7, 2003

I replied without looking at my code, which was stupid. (You #Geocache members who kept me up playing Wordox are to blame! Oh, wait, that's me too.)

//gpx/wpt/time *IS* the hidden date, which is why we need the field.

The end.

[This message was edited by ClayJar on February 07, 2003 at 01:11 PM.]

February 7, 2003

A new version of EasyGPS for Groundspeak should be appearing on this website soon. I delivered it to Jeremy yesterday.

Sorry, Clayjar, the bug you mentioned still isn't fixed yet. It will be fixed soon, though.

Just a reminder - there's a link to the discussion group for GPX developers at GPX webpage, and questions about GPX usage, extensions, and the like properly belong there.

--

Dan Foster

TopoGrafix: GPS Software, Waypoints, and Maps

http://www.topografix.com/

February 7, 2003

Well, I've got the code written and waiting. I just need to tell Watcher where to put the exported timestamps and the smart merging will be complete. There's even an optional "Exported" column so you can sort your cache list and see what needs to be checked or re-queried.

February 8, 2003

I've about finished the updates for Watcher 0.1.31, and it's sitting here nearly ready to be released (pending the fixes to the bug reports from my testing crew). The only other thing I need is to know what the name of the "exported" timestamp node will be.

(.31 has some rather significant improvements and at least one major bug fix, so once it's debugged, I don't want to hang on to it longer than necessary. If I must, I'll go in and disable all the merge logic and release another poorly-merging version, but I'd like to have the smart merge code in there before I start working on exports.)

February 9, 2003

Okay, Watcher 0.1.31 is ready except for knowing where to put the Exported timestamp for the smart merge code. Actually, though, you don't even have to update the XSD right away, since Watcher ony parses the GPX XML, it doesn't validate it. I just need to know where to put it.

Is something like "//gpx/wpt/Groundspeak:cache/Groundspeak:exported" good, or do you want it somewhere else? (I can't do any more work without either knowing this answer and releasing 0.1.31 or backing out the smart merge code... and I hate being bored.)

9.4k · February 9, 2003

I'll add a lastupdate field, but the question is... Is it good practice to change the version for the XSD or can I just add it on if it is an optional field?

Better yet, ClayJar, if you have a recommended format for adding to the XSD I'd love a suggestion. I'd root through the XSD but you already know how you want it...

Jeremy Irish

Groundspeak - The Language of Location

February 10, 2003

quote:
Originally posted by Jeremy Irish:
I'll add a lastupdate field, but the question is... Is it good practice to change the version for the XSD or can I just add it on if it is an optional field?

Just to be very specific, this is the "exported" timestamp, not "lastUpdated". The difference being that "lastUpdated" would be the timestamp the cache page was last updated/edited, but this is when the cache details were last exported, regardless of changes or the lack thereof. (It'd be great to know when a cache page was last updated, but that's something for April/May, I imagine.)

As far as just adding it without changing the version number... Best practices dictate that one should change the version number whenever there is a change. However, since it is a completely optional field, and since it is extremely unlikely that anyone is using a cached version of the XSD to validate, it should be perfectly fine to just add the line.

quote:
Better yet, ClayJar, if you have a recommended format for adding to the XSD I'd love a suggestion. I'd root through the XSD but you already know how you want it...

I ran this by a couple other guys to be sure I got it right, and the best way to do it is to simply add:

<xs:element name="exported" msdata:Prefix="Groundspeak" type="xs:dateTime" minOccurs="0" />

right before the final seven lines from the bottom (just below the travelbugs block). If you wanted, you could add msdata:Ordinal="10" right after minOccurs="0", but we don't see why you'd bother.

1.1k · February 10, 2003

Last Updated would be fine now, as we already have that field available. That way you don't even need to bother replacing it if nothing has changed to that cache.

quote:
Originally posted by ClayJar:
Just to be very specific, this is the "exported" timestamp, not "lastUpdated". The difference being that "lastUpdated" would be the timestamp the cache page was last updated/edited, but this is when the cache details were last exported, regardless of changes or the lack thereof. (It'd be great to know when a cache page was last updated, but that's something for April/May, I imagine.)

Jeremy Irish

Groundspeak - The Language of Location

February 11, 2003

.

February 11, 2003

quote:
Originally posted by Jeremy (Admin):
Last Updated would be fine now, as we already have that field available. That way you don't even need to bother replacing it if nothing has changed to that cache.

Well, if lastUpdated is indeed available, it would be nice to have both:

quote:

Having lastUpdated would mean that you could tell whether the cache details were changed from one GPX to the next, which would be quite valuable information. However, we still need the field to store "exported" for the reasons covered above in this thread. To summarize:

When you merge, lastUpdated will tell you whether the cache details in GPX #2 are unchanged from the cache details of GPX #1. What lastUpdated cannot do is tell you how long ago a given cache page was exported. In other words, if you have a cache page in your PDA, exported will tell you how stale that cache page is.

I have caches that were lastUpdated over a year ago, but they were exported this morning. If I had one of those in my PDA, I would see from the exported timestamp that even though the cache page was lastUpdated a year ago, it's still freshly exported from Geocaching.com. lastUpdated is a valuable informative field which, if available, would provide useful information to GPX applications and users, but exported is the field that will monitor "cache page freshness" (allowing applications and users to know when the cache page was last known good).

If you can add lastUpdated to the data returned by Pocket Queries, that would be *great*, but of primary importance is to have the exported placeholder in the XSD so Groundspeak-GPX-using applications can keep track of data freshness ("valuation date" as Markwell says it's called).

February 12, 2003

Just wondering if I'd managed to explain "exported" well enough... Lots of forum traffic and all, but I'm wondering if I should get back to work or wait a little while longer so I can release an 0.1.31 edition before beginning the next features.

1.1k · February 12, 2003

I get your point. Simply put, when should I go back to the geocaching site and grab this cache again?

Jeremy Irish

Groundspeak - The Language of Location

February 12, 2003

Exactly. It's the difference between "ClayJar last updated the cache page in November... it must have survived the hurricane" and "I downloaded this cache in *NOVEMBER*?!?"

February 14, 2003

Hope you're having an enjoyable Valentine's Day (or whatever else people do). The one "good" thing about holding back Watcher releases this long (this being the longest Watcher release delay ever, IIRC) is that I've had time to add quite a few things (and brdad has had time to find bugs in them).

I've added right-click menus to copy cache names/links/etc (even pre-linked names and hiders for the forums). You can set north, south, east, and west limits in the filters (so you can, for example, make a rectangle or only look north of the arctic circle). You can filter by hider, state, or other fields if you want to for some reason. Watcher even saves the GPX files in their displayed order (so if people convert to PalmDoc or whatever, the order is preserved).

And of course, the smart merge code is there. Once that is covered in the Groundspeak namespace, I'll be able to release 0.1.31. The funny thing is, I'm out of things to do until then. The only outstanding feature requests on my TODO list impact the core Watcher code far too much to begin them prior to releasing 0.1.31.

So, when you get a moment, it would be very useful to know whether there will be a "//gpx/wpt/Groundspeak:cache/Groundspeak:exported" node. If you say that there will be one added, then I'll set Watcher to use that node and release 0.1.31; otherwise, I'll just have to stop working until something is worked out (or until I go back in and remove all the smart merge code). I don't want to be pushy or anything, but unless someone can come up with new features to add, I'm now stuck in the water.

February 17, 2003

Since I'm still waiting to release Watcher 0.1.31, I figured I may as well show everyone what's waiting pending the answer. Go to http://clayjar.com/gc/temp/ and click on "FeaturePresentation.html" to see what you're missing...

As soon as I get the word, I'll release it...

5.3k · February 17, 2003

Clayjar...that looks great!

I'm guessing you'll have a lot more support for your needed change to the GPX file.

Do we need to start begging?? I'm not above that.

PLEASE!!!!!

"Just because I don't care doesn't mean I don't understand."

1.6k · February 17, 2003

So when are we going to see HTML export ala Spinner and GPX2HTML?

Clickable, zoomable maps?

Looks good so far!

CR

February 17, 2003

quote:
Originally posted by Sissy-n-CR:
So when are we going to see HTML export ala Spinner and GPX2HTML?

Clickable, zoomable maps?

Wow!

I must say that ClayJay has been spending the waiting time wisely.

I agree that if Watcher could do what Spinner and GPSBabel can, and if it could upload directly to my GPS, it would be my only GPX program.

CJ: You need to have a chat with Lil Devil

Now, Jeremy: What's the status?

February 18, 2003

PalmDoc is close to the top of the TODO list, and HTML export might be right near that. The maps will have to be handled by some other program, but the GPSBabel plugin should make it easy to export to whatever you'd like.

I'll start working on the export stuff once 0.1.31 is out, but until then, I don't want to start making major changes to the code (since I really want to release something quickly).

February 18, 2003

quote:
Originally posted by ClayJar:
PalmDoc is close to the top of the TODO list, and HTML export might be right near that. The maps will have to be handled by some other program, but the GPSBabel plugin should make it easy to export to whatever you'd like.

I'll start working on the export stuff once 0.1.31 is out, but until then, I don't want to start making major changes to the code (since I really want to release something quickly).

Perhaps a button to change icons based on type and size (like Spinner) for version 1.32?

2.5k · February 18, 2003

Wow, I can't wait till this is done. Is this going to happen real soon?

February 19, 2003

I'm going to be going through five or so states this weekend, so I won't be able to release anything after tomorrow evening... Is there any chance that we can get an answer about "exported" before I leave so I can release 0.1.31, or is there a chance there might be an answer by Monday?

I really don't mean to sound perturbed or anything, but I'm getting really tired of sitting on this and not releasing. If I have to go back in and remove all the work on the advanced merging code, I will. If I don't, that's even better. If I need to work on a new namespace, I will. Frankly, I don't give a plug nickel *HOW* I get 0.1.31 released. I just want to get this thing out! I don't even need you to do ***ANYTHING*** other than to just say "yes" or "no" so I know whether to release as-is (even if it is ahead of the XSD update itself) or to pursue alternate methods of handling the situation.

All I want is one tiny answer.

*Very* important GPX request.

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Very important GPX request.