Incorrect coordinates from Pocket Queries

September 30, 2003

Please forgive me if this topic has been covered in another thread.

It's happened to me more than once that I have received a pocket query file where one of the coordinates for a particular cache is way off the mark. When the output from pocket queries is delivered to me, the coordinates in the LOC file match the coordinates on the webpage, but the coordinates in the PRC file for some caches disagree in a significant way.

Here are some examples from this past week. These caches are around the Atlanta area, and this pocket query output was delivered on 09/25/2003.

Cache: Shallowford Picnic

Pocket Query Coordinates:

N 33 52.668 W 85 42.728

Actual Coordinates:

N 33 52.668 W 84 17.272

Cache: The Worm goes Down the Stairs

Pocket Query Coordinates:

N 33 54.879 W 85 39.541

Actual Coordinates:

N 33 54.879 W 84 20.459

I've seen this happen on more than just these two caches, and I see it more frequently on Subscriber Only caches than on the rest. I have the original zip file containing the LOC and PRC file, if anyone is curious.

I don't think it should matter, but I'm using a PC version of MobiPocket reader on my laptop.

This topic has been mentioned in a regional forum here.

9.2k · September 30, 2003

LOC files don't contain waypoints in the format you've indicated. They're in decimal-degree format, like this:

coord lat="32.8674166666667" lon="-96.8639166666667"

It's possible that whatever LOC processing program you're using is causing the problem, in that it's not performing the conversion correctly.

And just curious - why are you requesting LOC files instead of GPX files?

"Don't mess with a geocacher. We know all the best places to hide a body."

October 1, 2003

quote:
Originally posted by Prime Suspect:
LOC files don't contain waypoints in the format you've indicated. They're in decimal-degree format, like this:
coord lat="32.8674166666667" lon="-96.8639166666667"

You're right, the coordinates in the LOC file are not in the same format. I was hoping to avoid confusion with two different coordinate type. Let me restate one of the above examples using all sets of coordinates involved.

Cache: The Worm goes down the Stairs

Pocket Query Coordinates in PRC file:

N 33 54.879 W 85 39.541

Pocket Query Coordinates in LOC file:

Actual Coordinates from web page:

N 33 54.879 W 84 20.459

If you perform the math (which I do frequently), you will see that the coordinates in the LOC file match the coordinates on the cache page. Meanwhile, the longitude in the PRC file is not correct. Even if you don't perform the math, just look at the integer portion of the longitudes and you can see that something is amiss with the PRC coordinates.

Since the LOC file coordinates match the web page, I'm not worried about my LOC file program reader improperly converting the data. It's not the LOC file which is the problem, it's the PRC file.

I have the original zip file (as sent to me from the pocket query generator) which contains the errors/oddities/bugs listed above. I'd be happy to send it to anyone for examination. Even if you can't have a LOC file reader, the format is XML and it's pretty easy to open with any text editor.

October 1, 2003

quote:
Originally posted by TinSparrow:
It's happened to me more than once that I have received a pocket query file where one of the coordinates for a particular cache is way off the mark.

Has happened to me too!

I usually take my query file for new caches and read it on my PC. I will then copy the cords, GC####, and name from that file and add it in my text file that I use with G7ToWin to keep track of my caches. I then use G7ToWin to save ALL of my caches to a Delorme Street Atlas file.

When I get time to go caching, I look at my SA file to see which direction I want to go in to do caching. When I pick an area, I will then go to each cache page on the website to read logs. That is when I usually discover the problem. I'll read a description that is completely in a different area than what I thought. Checking closely shows the cords I copied from the Query file do NOT match what is posted on the website. This only happens once in a while, but is rather disturbing when I start planing a trip in the wrong direction. I haven't noticed any type of pattern yet.

Gary

Drop back 10 and ........trip over the cache.

5.3k · October 1, 2003

Sounds like GC.com's convertion software for the .prc file is screwing up.

Many people will tell you MobiPocket is a piece of garbage, anyway. This sounds like a great time to recommend an alternative.

Instead of requesting a LOC file, get a GPX file and create your own caches pages on your palm:

Run your GPX thru Spinner or GPX2HTML. This will create a set of html (web) pages containing all the cache info. Next, upload to your PDA using Plucker or iSilo

CYBret has created a great set of step by step instructions on how to do this HERE

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

Eamus Catuli AC005895

October 1, 2003

Thanks for the post Stunod.

I've had the above posted problems several times, and have only been receiving pocket queries for about a month and a half. I have noticed that each time, only the longitude has been incorrect. The Latitude is always fine. This info may help GC.com track down the problem.

I'll tryout Stunod's suggestion, but it sounds a little labor intensive. It is really nice to receive the zip file from GC, unzip it to my desktop, then double-click the .prc file and I'm ready to hotsync the file to my PDA. Seems simpler to me, but maybe because I'm not familiar with the other way.

Thanks.

9.2k · October 1, 2003

quote:
Originally posted by GLM:

I usually take my query file for new caches and read it on my PC. I will then copy the cords, GC####, and name from that file and add it in my text file that I use with G7ToWin to keep track of my caches. I then use G7ToWin to save ALL of my caches to a Delorme Street Atlas file.

When I get time to go caching, I look at my SA file to see which direction I want to go in to do caching. When I pick an area, I will then go to each cache page on the website to read logs. That is when I usually discover the problem. I'll read a description that is completely in a different area than what I thought. Checking closely shows the cords I copied from the Query file do NOT match what is posted on the website. This only happens once in a while, but is rather disturbing when I start planing a trip in the wrong direction. I haven't noticed any type of pattern yet.

You might like Utopia. It reads GPX files, and is specifically designed to work with G7ToWin, and Street Atlas.

"Don't mess with a geocacher. We know all the best places to hide a body."

October 1, 2003

quote:
Originally posted by Prime Suspect:
You might like http://home.earthlink.net/~msargent2/ch/. It reads GPX files, and is specifically designed to work with G7ToWin, and Street Atlas.

How come it doesn't handle Watcher or Spinner files? Don't they produce GPX files also?

Frank

October 1, 2003

quote:
Originally posted by Bartster:
I've had the above posted problems several times, and have only been receiving pocket queries for about a month and a half. I have noticed that each time, only the longitude has been incorrect. The Latitude is always fine. This info may help GC.com track down the problem.

I agree with this in that I have only seen the problem in the longitude coordinate, the latitude is never corrupted.

Does anyone know anything the generation of the PRC files? Do the makes of Mobipocket supply some configurable black box which is capable of compiling these files and sending them out? If so, then the problem is in the black box. On the other hand, if GC.com is generating these files themselves, then the problem could on the GC.com side or could be within the API, if applicable.

5.3k · October 1, 2003

quote:
Originally posted by Bartster:
Thanks for the post Stunod.

I've had the above posted problems several times, and have only been receiving pocket queries for about a month and a half. I have noticed that each time, only the longitude has been incorrect. The Latitude is always fine. This info may help GC.com track down the problem.

I'll tryout Stunod's suggestion, but it sounds a little labor intensive. It is really nice to receive the zip file from GC, unzip it to my desktop, then double-click the .prc file and I'm ready to hotsync the file to my PDA. Seems simpler to me, but maybe because I'm not familiar with the other way.

Thanks.

It's really not bad to do, plus you gain a lot of benefits. The best is the ability to enter multiple coordinates into the REFLOCATIONS file and get indexes based on distance and bearing for each point. I enter my home and work coords and get the cache pages indexed by distance from these points. Plus, Spinner can change the GPS icons from the default to unique ones based on the cache type.

Try it...I think you'll like it.

9.2k · October 2, 2003

quote:
Originally posted by Frank and Peggy:

quote:
Originally posted by Prime Suspect:
You might like http://home.earthlink.net/~msargent2/ch/. It reads GPX files, and is specifically designed to work with G7ToWin, and Street Atlas.

How come it doesn't handle Watcher or Spinner files? Don't they produce GPX files also?

It's designed to work with both GPX and LOC files (it can even use mixed GPX and LOC information in the same dataset). The only unique cache identifier in LOC files is the waypoint ID, so that is used as the key for such things as Ignore List entries, Cache Notes, and determining the URL for the cache page. If the file is run through a program that can munge the waypoint ID, these and other functions will break. This applies to Utopia as well, since it also can alter the waypoint ID to indicate cache type. It can output a GPX file (for use by EasyGPS, for example), but Utopia won't read it back.

"Don't mess with a geocacher. We know all the best places to hide a body."

October 2, 2003

Another issue with Stunod's suggestion - it only works for PC users. TinSparrow's original method works fine with Mac's and other platforms, but Spinner and the other suggestions are PC-specific.

I haven't noticed the problem myself yet, but then we usually rely on the coordinates in the .loc file and use only the text from the .prc. I'll be on the lookout for similar problems now though.

Jon & Miki

1.7k · October 2, 2003

quote:
Originally posted by jon & miki:
Another issue with Stunod's suggestion - it only works for PC users. TinSparrow's original method works fine with Mac's and other platforms, but Spinner and the other suggestions are PC-specific.

GPX2HTML isn't PC-specific. It'll work anywhere Perl runs, and that's just about everywhere. It might take a little more work, but that's what you get for not following the herd.

You can also use the online version of GPX Spinner, which is OS-agnostic.

Plucker Desktop is also available for multiple platforms. I don't know about iSilo's desktop component.

pirate.cgi.gif

1.7k · October 2, 2003

quote:
Originally posted by TinSparrow:
Does anyone know anything the generation of the PRC files? Do the makes of Mobipocket supply some configurable black box which is capable of compiling these files and sending them out? If so, then the problem is in the black box. On the other hand, if GC.com is generating these files themselves, then the problem could on the GC.com side or could be within the API, if applicable.

It's a little of both. Geocaching.com generates an HTML-like file that gets fed to the black box, and the black box does the compression and encryption and conversion into MobiPocket's ugly perversion of the PalmDoc format (as opposed to MobiPocket's more recent format, which actually has its own creator and typeid, the way God and Palm intended.)

I suspect the problem is on geocaching.com's end, simply because the MobiPocket converter basically has no concept of "numbers" and sees everything as just text.

pirate.cgi.gif

5.3k · October 2, 2003

quote:
Originally posted by jon & miki:
Another issue with Stunod's suggestion - it only works for PC users. TinSparrow's original method works fine with Mac's and other platforms, but Spinner and the other suggestions are PC-specific.

That is incorrect. gpx2html is written in Perl and works fine on a Mac. Plucker also works on a Mac.

5.3k · October 2, 2003

quote:
Originally posted by fizzymagic:

quote:
Originally posted by jon & miki:
Another issue with Stunod's suggestion - it only works for PC users. TinSparrow's original method works fine with Mac's and other platforms, but Spinner and the other suggestions are PC-specific.

That is incorrect. gpx2html is written in Perl and works fine on a Mac. Plucker also works on a Mac.

And I belive that the ONLINE VERSION of Spinner should be platform independent (correct me if I'm wrong...never actually tried it...nor do I intend to)

October 3, 2003

quote:
Originally posted by Prime Suspect:
You might like http://home.earthlink.net/~msargent2/ch/. It reads GPX files, and is specifically designed to work with G7ToWin, and Street Atlas.

http://img.Groundspeak.com/user/3608_2800.gif

Hmmmm, looks interesting and may solve my problem. Thanks.

Gary

Drop back 10 and ........trip over the cache.

9.2k · October 4, 2003

quote:
Originally posted by Frank and Peggy:

quote:
Originally posted by Prime Suspect:
You might like http://home.earthlink.net/~msargent2/ch/. It reads GPX files, and is specifically designed to work with G7ToWin, and Street Atlas.

How come it doesn't handle Watcher or Spinner files? Don't they produce GPX files also?

I've taken another look at this, and it appears that Watcher doesn't alter the data, though it can filter it. (I've never really used it, because I don't care for the interface, and it doesn't really fill any need I have.) I've updated the next release of Utopia to be able to handle GPX files saved from Watcher. It should be available by Monday.

"Don't mess with a geocacher. We know all the best places to hide a body."

October 10, 2003

bump

Incorrect coordinates from Pocket Queries

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