Jump to content

Problem with Pocket Queries


the_stamy

Recommended Posts

I'm having a problem with Pocket Queries, but it only happens on certain ones.

 

I cleared all points from my GPSr, then downloaded a gpx file of one of my PQs for an area I'm visiting this weekend. When I uploaded it to my GPS all the caches were listed with the GC number instead of the cache name, and all of them were classified as traditional caches.

 

When I looked at the text of the file, the cache name was showing up in the comment field, and the GC code was in the name field. I tried remaking the PQ as a new one, but it gave me the same result. Thinking it might be a problem with my GPSr, I then downloaded another PQ that ran on the same day. It loaded just fine with the correct icons and actual cache names.

 

Has anyone else had this problem? Both PQs are ones that I've run before without any issues.

 

Thanks in advance for any help you can give me on this.

Link to post

I had identical problems yesterday. Haven't checked the PQ I received this morning. DeLorme PN40

 

I tried running the PQ through GSAK, Topo8 and Cache Register with the same results. Ended up reverting to an old copy I had so I could cache last night.

Link to post

It appears that this is a DeLorme-specific issue caused by the changes to our GPX schema to incorporate cache attributes. Garmin units do not seem to be affected, nor does GSAK/GPSBabel. We are investigating now to see if it is something we can correct on our end.

Link to post
Unfortunately I think this problem is occuring before we transfer to the unit. The raw GPX file seems to have fields in the wrong locations.

 

No, the "name" has always been the GC number of the cache. This started from the days when most GPS receivers allowed only 6 characters in waypoint names. The GC code was developed to keep multiple caches from overwriting one another during GPS upload due to similar names.

 

I've been told by the developer looking into this issue that the XML in the new PQs is sound. It looks like DeLorme software is simply not handling the new changes to the schema.

Link to post

Thanks for all the answers on this one. GSAK did work eventually but it took a little tweaking.

 

For anyone else who may have this problem, here's how to do it:

 

1. Download and install GSAK.

 

2. Open your GPX file, leaving all the options set to Default.

 

3. Go to File -> Export -> Delorme Topo USA, SA Plus, Etc. - Specify where to save the file, and what to call it.

 

4. The 'Symbols' section of the Export process was originally set to only include status icons (Found, Not Found, Archived, etc). When I exported the file with those settings Topo USA still saw all caches as traditionals. To fix this, hit the 'Change' button on the right.

 

5. Under 'Select Required Format and Icons Here' click the 'Cache Type Only' option.

 

6. Go through the list of cache types and make sure that the correct Icon is selected for each one (Traditional = Geocache, Mystery = Unknown Cache, CITO = Cache In Trash Out Event, etc.). For some reason all of mine were defaulted to down arrows symbols instead of the normal ones. Hit save when you're done.

 

7. Click the Generate button and GSAK will export the file for you.

 

8. Open Topo USA, select the Draw tab, and click 'File.'

 

9. Import the text file you created in GSAK. Once it loads, highlight the file name and select Copy To -> Waypoint.

 

10. Open the Exchange Dialogue and upload the caches to your GPSr.

 

It was a bit of a hassle to set up, but a workable option until Groundspeak or DeLorme finds a way to fix it.

Link to post

I've had no problems with this at all until today, when I updated my PQs. I've paid a lot of money to have the membership and my pn-40 to all work together. I am VERY disappointed with this apparent change without testing before implementation. What use is being able to look at caches by GC code? There is very little usable information that is transferable onto the pn40 now. I got rid of my magellan because I disliked having to go through half a dozen steps to get caches transferred onto a gpsr. Now I have to go back to manipulating files myself to get them to work.

 

I shouldn't have deleted the caches from my pn-40. they may have been a week old, but they were usable.

Link to post

Delorme is also aware of the problem and is working it. Here's their take on the situation (Full thread available at http://forum.delorme.com/viewtopic.php?f=141&t=21029):

Cache Register Issue

 

Post by Kurt » Fri Nov 06, 2009 10:14 am

It appears that www.geocaching.com has rolled out an API change and our Cache Register application now sends red push pins to the device rather than the correct GC.com symbols. At the current time we are looking into the issue but do not have a time frame for resolution.

Kurt

Senior Technical Support Representative

Delorme Technical Support

 

Are Delorme and Groundspeak talking to each other about this? And, just out of curiosity, was the schema change announced beforehand? Just wondering where the breakdown happened. Hopefully one or both sides will work to prevent this type of event in the future, since it appears (at least from this POV), that the message about the update was either not sent to or not received by the right people to prevent the breakage.

Edited by GeoJunkie
Link to post

Could you elaborate on how you did that? - Thanks

 

thanks for the update

 

By the way, the_stamy, once those caches are in GSAK, you can load your DeLorme directly from there. I just did it, with a query from this morning. No issues. Just FYI

Link to post

Very dissapointed to find the new GPX files do not work with Delorme Topo-8. I understand Delorme is working on it, but frustrated since it seems this should have been preventable.

 

Fortunately for my trip today, the 'Download to GPS' function still works fine, but it is a pain to do for even as few as 50 caches.

Link to post

Here's something I posted to the Delorme forum that worked for me with my PN-40.

 

I may have found a temporary work-around if you import your gpx file into T8 to load your PN.

1. Open the gpx file in notepad.

2. Select Edit/Replace.

3. In the Find what: field, insert "http://www.Groundspeak.com/cache/1/0/1" without the quotes.

4. In the Replace with: field, insert "http://www.Groundspeak.com/cache/1/0" without the quotes (delete the "/1" at the end).

5. Click the "Replace All" button.

6. Save the file.

7. Import the revised file into T8 and perform a normal exchange to the PN.

It seemed to work for me, but I haven't done extensive testing. I'll monitor the forum for more results. Good luck to all of us as we wait for GC.com and Delorme to work out a permanent solution.

Link to post

 

I've been told by the developer looking into this issue that the XML in the new PQs is sound. It looks like DeLorme software is simply not handling the new changes to the schema.

 

Did anybody at Groundspeak let DeLorme know of the changes ahead of time? Seems odd that the changes didn't affect Garmins but did affect DeLormes....hmmmm, just saying.... :laughing:

Link to post

It appears that this is a DeLorme-specific issue caused by the changes to our GPX schema to incorporate cache attributes. Garmin units do not seem to be affected, nor does GSAK/GPSBabel. We are investigating now to see if it is something we can correct on our end.

 

Is it also what is causing the problem over at itsnotaboutthenumbers?

Link to post

 

I've been told by the developer looking into this issue that the XML in the new PQs is sound. It looks like DeLorme software is simply not handling the new changes to the schema.

 

Did anybody at Groundspeak let DeLorme know of the changes ahead of time? Seems odd that the changes didn't affect Garmins but did affect DeLormes....hmmmm, just saying.... :laughing:

 

The really cool thing about XML is that you can add "fields" to it with out a complete overhaul. Each "field" has a name, so a well developed app will just ignore any "fields" that it doesn't know the name of.

 

Garmin and GPSBabel both are structured to ignore any fields it doesn't know about.

Link to post

update: nevermind. I was wrong. send to gps is OK

 

re-

 

I'm sure you are aware but this happens with "Send to GPS" as well. I use PN-40. All I get is GC####, coords, and cache title. Bummer.

Edited by Parknet
Link to post

 

I've been told by the developer looking into this issue that the XML in the new PQs is sound. It looks like DeLorme software is simply not handling the new changes to the schema.

 

Did anybody at Groundspeak let DeLorme know of the changes ahead of time? Seems odd that the changes didn't affect Garmins but did affect DeLormes....hmmmm, just saying.... :laughing:

 

The really cool thing about XML is that you can add "fields" to it with out a complete overhaul. Each "field" has a name, so a well developed app will just ignore any "fields" that it doesn't know the name of.

 

Garmin and GPSBabel both are structured to ignore any fields it doesn't know about.

 

looks like we will be getting a DeLorme update then I am going to assume. :rolleyes:

Link to post

Groundspeak and DeLorme are aware of the situation and are working together to implement a resolution very shortly. I apologize sincerely for the inconvenience!

 

If any other sites/apps are experiencing issues with the new schema I would encourage them to contact us. Thanks.

Link to post

 

I've been told by the developer looking into this issue that the XML in the new PQs is sound. It looks like DeLorme software is simply not handling the new changes to the schema.

 

Did anybody at Groundspeak let DeLorme know of the changes ahead of time? Seems odd that the changes didn't affect Garmins but did affect DeLormes....hmmmm, just saying.... :laughing:

 

The really cool thing about XML is that you can add "fields" to it with out a complete overhaul. Each "field" has a name, so a well developed app will just ignore any "fields" that it doesn't know the name of.

 

Garmin and GPSBabel both are structured to ignore any fields it doesn't know about.

Yeah but if you change the content of a node or attribute, you can easily hose a consumer of your XML.

Link to post

Since the geocaching website came back on line, my pocket queries are in GC's instead of actual cache names when I load the pocket query into delorme topo 8.

 

that's what this whole thread is about. welcome to the club.

Is anyone get PQ's with NOTHING? No, long or short discriptions, no hints or logs????? Plugged my PQ from this morning and it doesn't show any of that.

 

Had a friend send me a new PQ and it's the same thing. So is it the PQ or Cachemagnet?

Edited by Hayward Cheezehead
Link to post

It appears that this is a DeLorme-specific issue caused by the changes to our GPX schema to incorporate cache attributes. Garmin units do not seem to be affected, nor does GSAK/GPSBabel. We are investigating now to see if it is something we can correct on our end.

Well, not that it's a huge of an issue compared to the Delorme users but Cachemagnet is not working with PQ either and they were last week.

Link to post

It appears that this is a DeLorme-specific issue caused by the changes to our GPX schema to incorporate cache attributes. Garmin units do not seem to be affected, nor does GSAK/GPSBabel. We are investigating now to see if it is something we can correct on our end.

Well, not that it's a huge of an issue compared to the Delorme users but Cachemagnet is not working with PQ either and they were last week.

It's a good data point though. If there are other applications impacted, perhaps Groundspeak will get it fixed the first time for everyone, instead of one-off fixes for each one that reports issues.

Link to post
Yeah but if you change the content of a node or attribute, you can easily hose a consumer of your XML.

A casual look over a GPX generated before and after the changes suggests that the content of the nodes has not been modified, only the attributes node (and children) has been added. Honestly, it looks like several companies who should know better have coded lazy XML parsers that rely on the structure of the file to interpret correctly. The software apps are easily fixed by their vendors, of course, but it's rather embarrassing for them...

Link to post
Yeah but if you change the content of a node or attribute, you can easily hose a consumer of your XML.

A casual look over a GPX generated before and after the changes suggests that the content of the nodes has not been modified, only the attributes node (and children) has been added. Honestly, it looks like several companies who should know better have coded lazy XML parsers that rely on the structure of the file to interpret correctly. The software apps are easily fixed by their vendors, of course, but it's rather embarrassing for them...

 

I'll admit that I've always looked at XML files as glorified text files. Yeah, it's neat that you can use some XML parser to pull in the data. But it's always been easier for me to just parse the data myself without that overhead. I can pull out what I need and ignore the rest. As long as the tags I'm looking for don't change, I'm good to go. The way post 18 makes it sound, it is the content that's a problem. In particular, the change from "xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0" to "xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0/1". It seems weird to me that that would be a problem.

 

For some of these companies you speak of, it's not so easy to just modify their applications to get around the structure change. Some of them have non-trivial processes to go through before releasing a change. They don't all have the luxury of being able to just throw a change out there without considering the consequences.

 

If anyone should feel embarrassed about this, it's Groundspeak. If it were me, I'd be bouncing potential changes to my main data file structure off of my trusted partners before implementing them. A simple, "Hey, what happens if you try to process a file that looks like this?..." would have gone a long way.

 

I'm hoping that if DeLorme ends up making changes, something good comes out of all of this. Being able to see cache attributes on my PN-40 would rock.

Link to post

If anyone should feel embarrassed about this, it's Groundspeak. If it were me, I'd be bouncing potential changes to my main data file structure off of my trusted partners before implementing them. A simple, "Hey, what happens if you try to process a file that looks like this?..." would have gone a long way.

How do you know what happened behind the scenes? From what evidence are you blaming Groundspeak for this? It's just as likely that Groundspeak properly notified all of its trusted partners, and most of them paid attention and didn't experience any problems from the transition. Others, whether through excess bureaucracy or just inattentiveness, dropped the ball and were caught with their pants down.

 

--Larry

Link to post
If anyone should feel embarrassed about this, it's Groundspeak. If it were me, I'd be bouncing potential changes to my main data file structure off of my trusted partners before implementing them.

Point is they shouldn't have to. It's Groundspeak's job to provide the data in valid XML (which they do) and the software/firmware developer's job to provide a XML parser rather than a lazy parser that assumes a given structure. If vendors don't understand how XML works and how it should be parsed or just don't make the effort to do it properly, release a product anyway and end up with egg on their face, that's not Groundspeak's problem.

 

I would appeal to Groundspeak to stand firm on this one and not be tempted to rollback for compatibility. If the companies in question care for their users, they'll push updates fairly quickly, I'd expect.

Edited by JeremyR
Link to post
Yeah but if you change the content of a node or attribute, you can easily hose a consumer of your XML.

A casual look over a GPX generated before and after the changes suggests that the content of the nodes has not been modified, only the attributes node (and children) has been added. Honestly, it looks like several companies who should know better have coded lazy XML parsers that rely on the structure of the file to interpret correctly. The software apps are easily fixed by their vendors, of course, but it's rather embarrassing for them...

 

I'll admit that I've always looked at XML files as glorified text files. Yeah, it's neat that you can use some XML parser to pull in the data. But it's always been easier for me to just parse the data myself without that overhead. I can pull out what I need and ignore the rest. As long as the tags I'm looking for don't change, I'm good to go. The way post 18 makes it sound, it is the content that's a problem. In particular, the change from "xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0" to "xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0/1". It seems weird to me that that would be a problem.

 

For some of these companies you speak of, it's not so easy to just modify their applications to get around the structure change. Some of them have non-trivial processes to go through before releasing a change. They don't all have the luxury of being able to just throw a change out there without considering the consequences.

 

If anyone should feel embarrassed about this, it's Groundspeak. If it were me, I'd be bouncing potential changes to my main data file structure off of my trusted partners before implementing them. A simple, "Hey, what happens if you try to process a file that looks like this?..." would have gone a long way.

 

I'm hoping that if DeLorme ends up making changes, something good comes out of all of this. Being able to see cache attributes on my PN-40 would rock.

 

The first bold is the version number of the Groundspeak extensions. It is correct for them to add the /1 to the end as they have added an extension to the "extensionable markup language"

 

The company that made the reader is coded WRONG from the beginning. Since the attributes that were in the old GPX files haven't changed the reader should have been coded for those attributes.

 

As an analogy lets talk about a fictional automobile XML file.

 

A car maker makes a car and has a XML file describing it. In the XML file it has a attribute for <left door> and <right door> the possible content is yes or no.

 

The XML file reads like this

<car model>Runabout</car model>

<left door>yes</left door>

<right door>no</right door>

</car>

 

The car designer decides that he would like to tell you if the door is a suicide door or not in the XML file. He properly adds a new extension <style> the possible content is standard or suicide

 

So the new file reads

 

<car model>Runabout</car model>

<left door>yes</left door>

<style>standard</style>

<right door>no</right door>

<style>standard</style>

</car>

 

So on the part of the reader.

 

Car company Yarmen made a reader that looked for the extension <left door> and <right door>. When the extension was added their reader still worked because the left and right extensions haven't changed.

 

Car company Delord made a reader that said look at the first and second extension after the car model. When the extension was added their reader returned a value of yes and standard. Ooops that isn't a valid response for <right door>! So their reader didn't know what to return to the user of the reader. The Delord users were outraged that the car designer broke his file and demanded a change back to the old way.

 

Both developers have the standards documentation that tells them that a child extension can be added but the second decided it would be easier to code on number of extensions instead of the correct method of coding for the extension names.

 

In the meantime my door was smashed in and I couldn't get a replacement for it because no one knew if it was a suicide or standard door.

 

Note, I know that much of this isn't correct as far as a valid XML file goes. It is intended as an example and may not even be correct as to why the Delord reader isn't working. It is intended just to show that the fault is not on the part of the car designer Dirttalk

Link to post

What about a temporary roolback so D units would work as before, though the enhancement for others would be lost/put on hold. What would make more of the endusers happy ?

I just want to be able to load my PQs to my PN-40 via Cache Register (I primarily use a Mac, so GSAK kludges are not viable for me long-term) properly. Whether it's a rollback by GS, a Cache Register patch from DeLorme, or some combination thereof, doesn't matter to me - I just want the functionality back.

Link to post

 

The XML file reads like this

<car model>Runabout</car model>

<left door>yes</left door>

<right door>no</right door>

</car>

 

 

But what if Dirttalked changes the boolean values to True/False:

 

<car model>Runabout</car model>

<left door>True</left door>

<right door>False</right door>

</car>

 

Then even the most diligent XML parser would provide no sensible data.

 

In real life "Unknown" was changed to "Mystery/Puzzle" in element <Groundspeak:type>Mystery/Puzzle Cache</Groundspeak:type>

Link to post
If anyone should feel embarrassed about this, it's Groundspeak. If it were me, I'd be bouncing potential changes to my main data file structure off of my trusted partners before implementing them.

Point is they shouldn't have to. It's Groundspeak's job to provide the data in valid XML (which they do) and the software/firmware developer's job to provide a XML parser rather than a lazy parser that assumes a given structure. If vendors don't understand how XML works and how it should be parsed or just don't make the effort to do it properly, release a product anyway and end up with egg on their face, that's not Groundspeak's problem.

 

I would appeal to Groundspeak to stand firm on this one and not be tempted to rollback for compatibility. If the companies in question care for their users, they'll push updates fairly quickly, I'd expect.

 

My point is it's a bad idea to assume anything about how someone else's code is going to handle even what may be considered a trivial change. You can get on the XML high horse all you want, but it's just common courtesy to give someone a head's up before you push an update that could potentially break their stuff.

 

Hey, I like the idea of the new additions. I'm more concerned with how this is handled in the future. If there's something that Groundspeak feels their trusted partners should do codewise to prevent this from happening in the future, I would hope they would communicate that with them. If not, at least give them advance warning when GPX format changes are coming.

Link to post
In real life "Unknown" was changed to "Mystery/Puzzle" in element <Groundspeak:type>Mystery/Puzzle Cache</Groundspeak:type>

Not true.

I coded a GPX parser about 12 months ago. I've just been back through the source code and it looks for 'Unknown Cache' in the <Groundspeak:type> node to identify puzzles (As an aside, Nate, it would be really nice to have an enum ID for cache types and log types as you've done with attributes! :lol:)

 

To make the point, here's an excerpt from a GPX generated on October 13th (before the attribute rollout):

 

<Groundspeak:name>The Triple Hat Trick</Groundspeak:name>

<Groundspeak:placed_by>.ichydr</Groundspeak:placed_by>

<Groundspeak:owner id="400605">.ichydr</Groundspeak:owner>

<Groundspeak:type>Unknown Cache</Groundspeak:type>

<Groundspeak:container>Regular</Groundspeak:container>

<Groundspeak:difficulty>5</Groundspeak:difficulty>

<Groundspeak:terrain>5</Groundspeak:terrain>

<Groundspeak:country>United States</Groundspeak:country>

<Groundspeak:state>Georgia</Groundspeak:state>

 

And here's one from November 7th (post attribute rollout). Same cache (GC1R2K9) which was the first puzzle in the PQ with attributes set:

 

<Groundspeak:cache id="1229905" available="True" archived="False" xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0/1">

<Groundspeak:placed_by>.ichydr</Groundspeak:placed_by>

<Groundspeak:owner id="400605">.ichydr</Groundspeak:owner>

<Groundspeak:type>Unknown Cache</Groundspeak:type>

<Groundspeak:container>Regular</Groundspeak:container>

<Groundspeak:attributes>

<Groundspeak:attribute id="41" inc="0">Stroller accessible</Groundspeak:attribute>

<Groundspeak:attribute id="13" inc="0">Available at all times</Groundspeak:attribute>

<Groundspeak:attribute id="24" inc="0">Wheelchair accessible</Groundspeak:attribute>

<Groundspeak:attribute id="19" inc="1">Ticks</Groundspeak:attribute>

<Groundspeak:attribute id="18" inc="1">Snakes</Groundspeak:attribute>

<Groundspeak:attribute id="17" inc="1">Poison plants</Groundspeak:attribute>

<Groundspeak:attribute id="39" inc="1">Thorns</Groundspeak:attribute>

<Groundspeak:attribute id="8" inc="1">Scenic view</Groundspeak:attribute>

<Groundspeak:attribute id="4" inc="1">Boat</Groundspeak:attribute>

</Groundspeak:attributes>

<Groundspeak:difficulty>5</Groundspeak:difficulty>

<Groundspeak:terrain>5</Groundspeak:terrain>

<Groundspeak:country>United States</Groundspeak:country>

<Groundspeak:state>Georgia</Groundspeak:state>

 

A mass of text (sorry!) but as you can see, the <Groundspeak:type> element is unchanged. The only difference is the addition of the <Groundspeak:attributes> node (and it's children).

Edited by JeremyR
Link to post
Yeah but if you change the content of a node or attribute, you can easily hose a consumer of your XML.

A casual look over a GPX generated before and after the changes suggests that the content of the nodes has not been modified, only the attributes node (and children) has been added. Honestly, it looks like several companies who should know better have coded lazy XML parsers that rely on the structure of the file to interpret correctly. The software apps are easily fixed by their vendors, of course, but it's rather embarrassing for them...

 

I'll admit that I've always looked at XML files as glorified text files. Yeah, it's neat that you can use some XML parser to pull in the data. But it's always been easier for me to just parse the data myself without that overhead. I can pull out what I need and ignore the rest. As long as the tags I'm looking for don't change, I'm good to go. The way post 18 makes it sound, it is the content that's a problem. In particular, the change from "xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0" to "xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0/1". It seems weird to me that that would be a problem.

 

For some of these companies you speak of, it's not so easy to just modify their applications to get around the structure change. Some of them have non-trivial processes to go through before releasing a change. They don't all have the luxury of being able to just throw a change out there without considering the consequences.

 

If anyone should feel embarrassed about this, it's Groundspeak. If it were me, I'd be bouncing potential changes to my main data file structure off of my trusted partners before implementing them. A simple, "Hey, what happens if you try to process a file that looks like this?..." would have gone a long way.

 

I'm hoping that if DeLorme ends up making changes, something good comes out of all of this. Being able to see cache attributes on my PN-40 would rock.

 

The first bold is the version number of the Groundspeak extensions. It is correct for them to add the /1 to the end as they have added an extension to the "extensionable markup language"

 

The company that made the reader is coded WRONG from the beginning. Since the attributes that were in the old GPX files haven't changed the reader should have been coded for those attributes.

 

As an analogy lets talk about a fictional automobile XML file.

 

A car maker makes a car and has a XML file describing it. In the XML file it has a attribute for <left door> and <right door> the possible content is yes or no.

 

The XML file reads like this

<car model>Runabout</car model>

<left door>yes</left door>

<right door>no</right door>

</car>

 

The car designer decides that he would like to tell you if the door is a suicide door or not in the XML file. He properly adds a new extension <style> the possible content is standard or suicide

 

So the new file reads

 

<car model>Runabout</car model>

<left door>yes</left door>

<style>standard</style>

<right door>no</right door>

<style>standard</style>

</car>

 

So on the part of the reader.

 

Car company Yarmen made a reader that looked for the extension <left door> and <right door>. When the extension was added their reader still worked because the left and right extensions haven't changed.

 

Car company Delord made a reader that said look at the first and second extension after the car model. When the extension was added their reader returned a value of yes and standard. Ooops that isn't a valid response for <right door>! So their reader didn't know what to return to the user of the reader. The Delord users were outraged that the car designer broke his file and demanded a change back to the old way.

 

Both developers have the standards documentation that tells them that a child extension can be added but the second decided it would be easier to code on number of extensions instead of the correct method of coding for the extension names.

 

In the meantime my door was smashed in and I couldn't get a replacement for it because no one knew if it was a suicide or standard door.

 

Note, I know that much of this isn't correct as far as a valid XML file goes. It is intended as an example and may not even be correct as to why the Delord reader isn't working. It is intended just to show that the fault is not on the part of the car designer Dirttalk

 

Ok, if you want to do car company analogies, I can do car company analogies. Let's say an automotive parts supplier were to print labels using the latest ANSI standard Data Matrix bar codes that meet the specifications laid out in the customer print and shipped them to a car manufacturer. Let's say that manufacturer has trouble reading some labels. They complain to the automotive parts supplier. It turns out that the automotive parts supplier is using fairly new standard equipment to print the labels and to read the labels several times before they leave their plant. Let's say the car manufacturer is using 10 year old plus scanners to read these labels. They could upgrade their equipment, or they could force the part supplier to change their process. This could have been avoided if the part supplier had provided samples for the car manufacturer to test prior to production.

 

Also, if the parts supplier were to make a schema change such as the one you speak of, they would have to get customer approval prior to making the change. Doing something that breaks a customer's system without informing them of the change is generally frowned upon in the automotive industry, no matter how old their equipment/poor their code is.

Link to post

I just want to be able to load my PQs to my PN-40 via Cache Register (I primarily use a Mac, so GSAK kludges are not viable for me long-term) properly. Whether it's a rollback by GS, a Cache Register patch from DeLorme, or some combination thereof, doesn't matter to me - I just want the functionality back.

Actually, GPSBabel is the operative piece here. GSAK uses it to talk to the unit under the hood. GPSBabel runs on the Mac, although GSAK does not (at least, not without a Windows virtual machine). You ought to be able to send the PQ to the unit using GPSBabel on the Mac in native mode. Haven't tried it myself (Windows user), so YMMV.

Link to post

Has anybody tried modifying a downloaded gpx file as described in post #18? I'd be interested in hearing if your results are similar to mine.

I used wordpad (can use any text editor) to replace/remove that extra "1" with success. Easy enough to give it a string to search to make sure it doesn't remove all of the 1s. I used "cache/1/0/1" replace with "cache/1/0" It's an extra step that we shouldn't have to do, but a fix for now.

 

I understand that GSAK can do this, but I've spent hours with the program and can't figure out how to get it to fix the symbols correctly or output all of the cache info in the pn40 format. Not a programmer so I haven't the foggiest idea how to run gpsbabel either. I use linux for everything except geocaching since there is nothing that works on linux. Again, I'm not a programmer, so gpsbabel doesn't work for me. I need a gui.

Link to post

Here's something I posted to the Delorme forum that worked for me with my PN-40.

 

I may have found a temporary work-around if you import your gpx file into T8 to load your PN.

1. Open the gpx file in notepad.

2. Select Edit/Replace.

3. In the Find what: field, insert "http://www.Groundspeak.com/cache/1/0/1" without the quotes.

4. In the Replace with: field, insert "http://www.Groundspeak.com/cache/1/0" without the quotes (delete the "/1" at the end).

5. Click the "Replace All" button.

6. Save the file.

7. Import the revised file into T8 and perform a normal exchange to the PN.

It seemed to work for me, but I haven't done extensive testing. I'll monitor the forum for more results. Good luck to all of us as we wait for GC.com and Delorme to work out a permanent solution.

I tried importing into CacheRegister and that seems to also work as a temporary cure.

Link to post

Here's something I posted to the Delorme forum that worked for me with my PN-40.

 

I may have found a temporary work-around if you import your gpx file into T8 to load your PN.

1. Open the gpx file in notepad.

2. Select Edit/Replace.

3. In the Find what: field, insert "http://www.Groundspeak.com/cache/1/0/1" without the quotes.

4. In the Replace with: field, insert "http://www.Groundspeak.com/cache/1/0" without the quotes (delete the "/1" at the end).

5. Click the "Replace All" button.

6. Save the file.

7. Import the revised file into T8 and perform a normal exchange to the PN.

It seemed to work for me, but I haven't done extensive testing. I'll monitor the forum for more results. Good luck to all of us as we wait for GC.com and Delorme to work out a permanent solution.

 

Thanks, jollywally, this method worked for me

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