Jump to content

Bug in pocket queries


SimonG

Recommended Posts

I've noticed that the apostrophe character (ASCII 146) doesn't come out correctly in pocket query .loc files. If you go to the cache page for (say) Winston’s view and click on 'Download to EasyGPS for Groundspeak', the resultant .loc file is correct. But a pocket query replaces the apostrophe character by ASCII 226 128 153, so you end up with something like 'Winston’s view'.

 

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

G'f tocdobjqowa qbagmx qu igxhbo uhq nza ejfgejro dgwuqc nubo zowfoqc. - Tjlo Otgcum

Link to comment

That's not a problem with the pocket query per se. It's a problem with certain Microsoft products that use a nonstandard character for apostrophe, exacerbated by the fact that EasyGPS doesn't translate UTF-8 in XML files. It won't happen with all caches - just the ones where the page description was submitted with a Microsoft browser.

 

warm.gif

Link to comment

What that doesn't explain (as far as I can tell) is why it works with the .loc files downloaded from the cache pages, but not those generated by pocket queries.

 

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

G'f tocdobjqowa qbagmx qu igxhbo uhq nza ejfgejro dgwuqc nubo zowfoqc. - Tjlo Otgcum

Link to comment

So, your question is why does:

“The Parasite Spawn” – Spawn #1(Hosted) by A Nord, Unknown Cache (1/1)
become
<desc>“The Parasite Spawn†– Spawn #1(Hosted) by A Nord, Unknown Cache (1/1)</desc>
in the Pocket Queries and not in the LOC files? The answer is simple: the .loc files generated by Geocaching.com use encoding="ISO-8859-1", and the Pocket Query .gpx files use encoding="utf-8". Now, on to assigning blame. icon_wink.gif

 

The XML LOC files generated by Geocaching.com use the ISO-8859-1 character encoding because that's just what was there. Most XML parsers will be able to understand the ISO-8859-1 encoding, and EasyGPS understands it fine. When the GPX XML generation by the Pocket Queries was discussed, it was decided, and rightfully so, that the encoding used should be an encoding that can properly support the international character of geocaching (and which, incidentally, *must* be readable by every XML parser). With that in mind, the GPX files are encoded with the UTF-8 character encoding.

 

Now, according to the XML spec, in order for a parser to be an XML parser, one of the things it *must* be able to do is parse UTF-8. Any parser that does not handle UTF-8 is, by definition, *not* an XML parser. EasyGPS claims to parse GPX XML files, but by virtue of the fact that it does not handle UTF-8, it does not actually have an XML parser. That needs to be fixed in EasyGPS.

 

So, what is the problem? EasyGPS cannot handle the UTF-8 encoding that it is *required* to handle by the XML spec (and apparently it handles ISO-8859-1, which, incidentally, is not *required* by the XML spec).

 

Oh, incidentally, Watcher (the GPX utility I am developing, as referenced in the Custom Search thread) does not have problems with the UTF-8 encodings, since it uses a true XML parser.

 

[This message was edited by ClayJar on December 20, 2002 at 12:57 PM.]

Link to comment

quote:
Originally posted by Spaceman Spiff:

Setting up a pocket query, I don't see USA in the list of "where" countries. Why is that?


We purposely left it out since it doesn't make any sense. Since you're likely to get way too many results from such a search, you'd end up with a "random" list of caches that doesn't have much meaning. In many cases, this is true when doing a state search as well. We're trying to force you into making a more specific/relevant query.

 

So its really a "feature", not a bug. icon_biggrin.gif

 

-Elias

Link to comment

quote:
Originally posted by Elias:

We purposely left it out since it doesn't make any sense. Since you're likely to get way too many results from such a search, you'd end up with a "random" list of caches that doesn't have much meaning. In many cases, this is true when doing a state search as well. We're trying to force you into making a more specific/relevant query.


Since the new GPX-using applications make it far more useful to grab a whole state (since you can then search, filter, and browse locally), is there any chance that, say, the full state queries could be run once a night and be available to charter members (perhaps at the expense of a pocket query, or whatever)? It would seem that this might be a good idea. Why?

Less duplication of effort. Instead of running virtually the same query numerous times, the full-state queries would only need to run once.

Fewer queries overall. With the new applications, you can narrow the cache sets down locally*, so there's no need to request three separate queries. *The ability to export GPX files from Watcher is next on the TODO list.

Fewer queries over time. If the state queries were available for direct download, many cachers would not feel it necessary to request a query sent every day. (Of course, you could just as easily make it e-mail it like a regular query, or you could even have a "download queue" to throttle the number of downloads in progress during peak times.)Anyway, it's just an idea that seems like it could help abate some of the load problems that extensive Pocket Query use can cause. icon_wink.gif

 

If, perchance, this seems like an idea worth investigating, I urge you to consider it thoroughly. I'd even be willing to donate a few dollars to the time it takes to hash out some code to do it, if that would make it more palatable, and I know at least a few others who would be glad to as well. Anything that can help make the Pocket Queries even better than they already are. (And sure, I have a bit of a vested interest, since I *am* the code slinger behind Watcher. icon_biggrin.gif)

Link to comment

quote:

If, perchance, this seems like an idea worth investigating, I urge you to consider it thoroughly. I'd even be willing to donate a few dollars to the time it takes to hash out some code to do it, if that would make it more palatable, and I know at least a few others who would be glad to as well. Anything that can help make the Pocket Queries even better than they already are.


 

This would work out marvelously for folks in states with > 500 caches. One big run for 750 caches, instead of 2 queries, each returning 500, with 250 duplicates. When you multiply those 2 queries times the number of users issuing the same-state query, the bandwidth/resource issue of bigger queries becomes a non-issue.

 

I like it. icon_wink.gif

Link to comment

An excellent suggestion which I would ask be extended to some of the more popular countries as well. Examples being Australia, Germany, France and (or course) the UK icon_smile.gif

 

Thanks, Peter

 

_________________________________________________________

 

It is better to regret something you did, rather than to regret something you didn't do.

Link to comment

Ok.. No USA in the "where"

 

What I a was trying to do is do a pocket query for all the 'Locationless' caches (so I can get an ebook file of them to carry around).. browsing it shows only 300.

 

Pocket query gives me an error if I don't give it a position to start with, so I was willing to accept all those that where locationless but marked in the USA...

 

When there wasn't a USA option, I was going to pick a state, and set the range to 2000 miles to get the whole USA, but range seems to have a max of 500 miles...

 

So How do I get a pocket query for all the positional caches?

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...