Jump to content

robertlipe

Moderators
  • Posts

    5300
  • Joined

  • Last visited

Everything posted by robertlipe

  1. > I think the problem is that the GPSr doesn't really handle the routes very well. We typed a variation of this at the same time, but now that I understand this better, I'm pretty sure you're destined for frustration. Building a route from a PQ is going to do things like lead you to the front door of the subdivision that happens to share a rear fence that borders the back edge of the park that houses the ammo box. It's going to navigate to the "wrong" place to park. You're going to be messing with it at the final minutes and if youre the driver, it's distracting that you have to outsmart all that tech. I think that taking the GPX generated by the first software listed would help you eliminate the basecamp issues. The GPX *should* just eat the GPX directly. Another "fresh perspective" in all this would just be to leave the unit on the dash running the map overview and pick your destination from the map . Mark them as found and they'll disppear from the map as you go and your bread crumbs make it clear where you've been. Much less software fiddling involved. This was what I did when I was traveling (most of the last of my final years) and didn't want to carry a bucket of hardware on the planes. It worked OK with a single GPS and the trick is to set the PQ paramaters for what you'll actually hunt (a process you must be doing if you've narrowed it down to an 87 point list) and use the diff/terr and ignore lists appropriately.
  2. Following up on that last point. I can't find the max number of routepoints, but at least one piece of Garmin software may have a limit of 29 points if te last post in https://www.expressmounts.com/questions?qid=37847 is to be believed. If it's about size and not ordering or a name conflict (three point named "tree" shouldn't be merged into a single one, but I'm sure that some software somewhere may do that) you might try breaking the route into 4 chunks of 20. Name them Morning, Afternoon, etc. or something where you can easily control the sequence from the unit while you're on the move. When I was finishing my 50 state challenge and covering hundreds of states, I went even lower tech: a note taped to my dashboard of states in the order I needed to hit them. From there, choosing one from the map is easy. I had access to over a hundred GPSes at my peak and I never found any of them that would really route that many in a day. Reality would always hit - a road closure, a town parade, etc. - that meant you had to hop from 57 to 59 and let 58 go and the GPS would go nuts trying to navigate you back there. It was usually just too finicky to mess with while driving. There was also a time I'd have two dash units - one doing the actual cache to cache routing and another that was zoomed out and kept more of a big-picture "you are here" that kept me heading the approximate direction I needed to move to keep on track during the run. Yes, it was absurd hardware overkill. So you have lots of things to investigate and alternatives on the table in case you do find what's dragging you down. Good luck.
  3. Your post mentioned "route point 1", so I latched onto the leading zero thing. That may be a distraction.| My point was that if you're starting with a GPX file that you know is right, dragging through GSAK and through a variety of their Macros, feeding that through Basecamp along the way, and pitstopping it in CacheRoute30SM (which is a new title to me), there are a lot of fingerprints on things that have a chance to "damage" the file in weird ways. If you start with a GPX file, mount the device in mass storage mode, copy the GPX file to it, carefully unmount/eject, and the GPS should read it on next boot.. Things like Basecamp (or whatever they're calling it now) and even some GPSes tend to snap route points to roads that can also result in routes looking different on the device than they do if you're just looking at it. My power geocaching days are over, but I also found a happy place using one dedicated unit in the car and another on my hip. I used a StreetPilot 2720 long long after they were trendy, but it's a nice combination. (I'm not at all recommending buying a 2720 in modern times.) Remember that GPX files are "just" a very carefully crafted text file. If you aren't intimidated by, say, reading a web page source code, pop one open in a text file and see if the order and details match your expectations. The GPX file format is described in great details on expertgps.com if you have to split hairs, but I think a pencil and paper, not a magnifying glass will help find where it's going off the rails. You can see a well-constructed GPX file at https://github.com/GPSBabel/gpsbabel/blob/master/reference/transform-rte.gpx Pardon the lack of vowels, but an <rte> is made of an ordered list of <rtept>s. Order matters. Almost everything insden rte or rtept is optional. Notably, the <name>, <cmt> and <desc> fields to not have anything to do with the order of the turnpoints. Even the names are optional. This one has <time> and <ele>, which is pretty rare for routes (but legal) because this file is part of GPSBabel's test suite and it was converted from a track into a route. They're optinoal and a distraction for you. So pop open your GPX files each step along the way and see where the order goes wonky. Also check that your GPS can even hold that many. Most consumer grade units won't let you put in infinite routepoints . Motorcyclists, in particular, run into this issue a lot. The GPS - especially ones that do routing - really want to be given a route that says "Mountain View, Palo Alto, San Mateo, SF" and not 150 turn points for every stop light between those points. (This is a terrible example because either 101 or El Camino would be basically a straight line; I just needed a few cities that are moderately well known and somewhat close.)
  4. My approach would be to try to use leading zeros. If it's doing an alphabetic sort instead of a numeric one (not unreasonable, though you'refree to ask which of these steps is sorting them at all) "02 ... 09 10 11 12 ... 19 20 " will do what I think you're asking for. An alphabetic sort of that same sequence without tthe leading zeros would put 10 11 12 before 2. You may have too much software involved. Can you just copy the GPX file straight to the device and land it in whatever device directory it expects to find such things? I can't recall if 2597 mounts like a disk drive and reads GPX or if it was of the generation that wanted to be a camera and only talk through a protocol that didn't respect folders/directories. Goopd luck.
  5. Play nice, guys. You two don't have to snip at each other every time. In this group, it's reasonable for "Garmin" to default to handheld/outdoors class hardware. We may have GPS experts, but this is still a geocaching forum and an encyclopedic recall of their backup cams or body scales isn't required.
  6. This seems dangerously close to advertising. Please be careful, Kunarion. Post a review, if you like, and walk away. Thanx.
  7. That would be very surprising. Garmin has historically had some Very Bad USB implementation quality, but USB3.1 has been around for a while and we've not seen a lot of crowing about this. USB2, USB3.0, and USB 3.1 are all compatible via fallback; if you don't *ask* for the new stuff, or you ask and are declined, you just don't get the new stuff and you get the old protocol levels instead. Did Garmin really tell you it doesn't work with any computer built in the last 8-9 years with no fix or workaround? Source: I'm the one that first added Garmin USB support on Mac and Linux , a task involving engineering at Garmin and Apple, and even now my software supports more Garmins on USB on Mac and Linux than even Garmin does...
  8. Bumping a 9 y/o thread with a request and then leaving the topic hanging was indeed a bit weird. The bit decay in these 15+ year old devices means that a lot of the links you can find (maybe to gawisp, gpsworld, gpstracklog, or many others that are just plain gone instead of decaying) don't work. Some of the links you can find are in such sketchy corners of the world that it'd be wise to question their content. Builds like 4.20 for CSx that never even hit Garmin's own site are particularly hard to find. It's likely the above request isn't coincidental with https://www.gpspower.net/garmin-receivers-firmwares/243359-gpsmap-60csx-chipsets.html#post1220015 . I'm not registering to see if any of those links pan out, but they at least look llike warm leads, but there are a lot of forum links referencing this version number that ultimately brick their units, too, so maybe it's hard to find for a reason. /shrug Even in my mad stash of a quarter million messages and files from various yahoo gps groups, I can't find a downloadable/executable form of that update.
  9. I clicked the button indicating this answer was "helpful". I suggest others finding answers, well, helpful do the same as a way to surface the better answers/answerers in a lengthy or contested post or just as a way of thanking them for helping fix a setup issue on your personal gear. If you're familiar with geocache favorite points, this is kind of the same, but this section doesn't make much (enough) use of it. Thanx to our product experts!
  10. GPSBabel, a favorite of geocachers for almost 20 years, supports the C/Cs and CSx/Cx family. It's true those models don't let you load cache pages but millions of caches were found before that was a thing. You'll spent some time fussing with drivers, but it's nowhere near the frustration of a serial era Garmin.
  11. There is a lot of seemingly well-intended chit-chat here, but 90% of this thread is off topic. Please try to offer something helpful to the OP and not just chastise them. That generation of GPS required a driver provided by Garmin to work. I think it's this guy: https://www8.garmin.com/support/download_details.jsp?id=591 This driver is required for any software, whether Basecamp, EasyGPS, or GPSBabel to work with that hardware on Windows. Please confirm it's installed. The suggestion to try GPSBabel has merit because I think every error condition it (that isn't a crash...of which we have none reported for years) has an error message associated with it. That said, we either get packets or we don't and we can either talk to the driver above or we can't so we can really only recommend kind of hand-wavy things like rotating USB ports, different cables, cleaning the gunk out of the USB connector etc. Good luck
  12. For most of the last twenty years, the answer to this question has been basically the same: Choose between a touch screen or a dpad. With that decision in mind, choose between the best Garmin in your price bracket or a ruggedized (at least case) smartphone. In the first decision tree, it's largely personal ergonomic preference. For people in cold, gloves may influence the decision. Goldenwattle has the right idea in looking for ergonomics. Comfort matters. A device that won't fit in your hand will get dropped and all of these are too expensive to be casually dropping 20x a day. For the second, Garmin is pretty much the only one standing in handheld geocaching GPS receivers for a long time. There is no competition in tech or price, so there's been no real motivation for them to improve on either in many years. I suspect their update schedule is driven mostly by when parts they rely on become unavailable, so they're kind of "tail-driven" on hardware. These forums are filled with advice on phones being the best ever because you can use external battery packs and you can get live updates and you can run multiple apps that are actively maintained. Or they're the worst ever because they don't bounce off rocks very well, they're hard to see in sunlight, or you can't just pop the cover off and replace batteries. Or there's the chorus of "real" GPS being the best ever because they still use plain ole AA's that you can get at the grocery store so you can hot swap them. They're also the best because they can have a full Quad Helix or even just a large patch antenna and the GPS receivers tend to receive more constellations than "just" the phones which have a GPS that exists mostly to direct 911 to your burning car and to direct you to your hotel for the night. All of this is pretty much true. The models in the boxes change a little bit over time (Oregon 400 vs 500 vs 600 vs 700, or 62, 64, 65, 66 or Samsung ${INTEGER}) but the basic flowchart hasn't really had any different players in almost 15 years now, I think, when Magellan and Rand both made dying gasp entries into the market in the late 200x's. For the third point, price is always an issue for some cases. It's no longer the case where the difference in a $150 unit and a $600 unit will paralyze you vs. jazzing you with glitter and eternal rainbows. An eTrex 10 is unnecessary self-torture. The middle range eTrex was basically the top of the line features from a few years ago, but they cripple the driving features on them. If you have to buy City Navigator for ANY of the Garmins, remember that a Nuvi/Drive "LMT" unit will include lifetime maps, be about the same price as one individual map drop, and be a WAY better driving experience. (Oh, this is an area where smart phones have a HUGE edge. Apple and Google Maps driving experience is just a beatdown...and self-updating for major features all the time.) The remainder of the decision in the $300-$700 range is touch vs. dpad and dialing in the maps and other features like cameras. Garmin makes the niche units like Rino and Inreach, but they're really not for geocaching, so they're off your table. GPSRchive is one of the last GPS sites still standing and a good site for news and honest lists about known defects. The market has imploded and become so boring that a lot of the GPS tech sites that were thriving early in the century (GPSPassion, GPSTracklog, Laptop/PDA world, and several nerdier ones all are gone) Compatibility is pretty much a solved problem. I have the #1 program in that space and I don't have any questions or wishlist items for funky hardware while I had several a week in 2004. That's all a side effect of there being only one maker and slow change these days. If you were happy with your 450, you'd likely be thrilled with a 700 or even a used 600. They're SO much faster and that capacitive glass multitouch screen vs the resistive screen on your Oregon bring it forward into the 2010's. The UX would certainly be familiar to you. It seems like there should be an 800 "soon" becuase the 700 is five years sold (see also: unchanging market) but given their history of problems with new products, the Oregon 700 is kind of the "the devil you know" at this point. The basic formula of "what should I buy" has been the same for a long time and it's been hashed to death in this group before. If someone less jaded than me wants to write a definitive "what should I buy 2020" post, I'll gladly change that pinned post to point to it. Cover the above matrix and try to be somewhat balanced between phones and dedicated hardware, and you're probably "in". Good luck on your purchase.
  13. Seriously. Does anyone else ever get the urge to just drive to Olathe and start wandering the streets until you find a software engineer at Garmin and actually take them geocaching with their own devices? If it is a case where the UI is blocked behind a thread stalled on an SD write and is able to pull the same record again before noticing that this one has just been shot down, that's really silly because it means their design has multiple sources of truth for a really fundamental data item. That's not a case of a missed mutex; that's just a bad design. (Duly noting that speculating about design from speculation of bug sources is a bit silly....) A human should never have to count bananas between actions on devices of this kind of computing capacity. I do remember seeing variations of this as far back as the 450. (I stopped buying at the 6x0 as that's also when I 'retired' from geocaching..) The "mark as found and find next" process has long been a frustrating mess of required keystrokes, muscle memory, and flakiness. I do remember conditioning myself to either bounce back to the map to select the next, which always seemed immune from this weirdness (and was often more strategic when power caching in a city) but that was a long time ago in tech years. So I can't offer anything actionable on the 700 specific (sorry - I'll moderate myself as unhelpful) but I will offer a sympathetic shoulder that this seems to have loooong been a problematic code path for Garmin, even if I'm being charitable about the frequent full-device crashes in this general area that persisted from Colorado through at least the 600.
  14. The non-field-replaceable battery thing isn't as cut and dry as it used to be. When I needed three laptop batteries to get to my office (I had a tough commute...), I could swap that battery with my eyes closed, under the seat, and without lifting my seat back tray. Now that I can compile AND watch video for 20+ hours, I no longer care that I can't swap it. I can't testify if the situation with the 66SR is similar, but it IS possible that the increase in energy density in the chemicals used and the improved physical shape (look at how much space is between two parallel cylinders) can make the experience so much better that you won't miss being able to swap them. You'll still need to plan for cases like not starting the day on E because you can't just pop another set in from the quick-stop on the way, but the common charging "bricks" or even lipstick batteries (usually a single 18650 cell) can probably charge a GPS several times. Spinray has apparently been outside caching and not inside reporting back on his impressions, but IMO he made a good call. $150 for a used 60CSx in 2021 (that's the 2006 version of a 2004 model) just doesn't make sense. That was a workhorse of a GPS, widely used in this crowd, but tech just isn't a place to be sentimental for tools you use. Good input from lots of views here and nobody got nasty, so gold stars for everyone. Executive takeaway: Don't be dismissive of change.
  15. This is all pretty silly. Magellan's GPS business has been bought and sold from the edge of bankruptcy a few times since geocaching started. The Explorist you're talking about isn't even their first device named "Explorist". Competition in the handheld GPS biz is dead. Garmin's the only player left that's selling hardware in volume. For this generation of hardware, the "Magellan interface" is exactly like the Garmin interface at the protocol level. The device starts in USB Mass Storage mode, you copy a GPX file to it, you unmount it from the computer. Same between the two. Same as in 2016 when you joined. Same as in 2010 or so when the potato-shaped versions of the Explorist were introduced by Mid, the then-fresh owner of Magellan GPS brand, who has now completely exited the handheld market. The "new security" that we're talking about is the turndown of the Netscape Navigator era, which started very early this century. Connect the cable. Drag and drop the GPX file into the place GPX files go. Eject the drive. It takes seconds, with or without a voodoo button. That GPS works as well today as it ever has. I actually write software that's used in GPS markets way beyond Geocaching. I don't think they're actually selling many of what they DO list on their site.
  16. I've posted before how I'm reasonably sure the Garmins handle reading those files ... at least based on how I would build it based on my experience building similar systems. I'd bet strongly there's a SQL3-lite database (or something close to it) that gets (at least partially) clobbered on boot and then populated by GGZ and GPXs on boot. GGZ's contain a crc (the spec had ambiguity on how exactly it was calculated but as long as the same software cmoputed it the same way, it washed) so you could know to shoot down entries that had been seen in that GGZ from the last boot that now had potentially different contents The ordering that was in the Garmin spec I last saw was "undefined" and it's probably in the order they're last seen in the file walk and even within the same file. Last one in wins. Outside the files, the order is _probably_ the order they appear inside the FAT directory table, which is so hard to predict that you could never describe it or predict it so I'd also call it "undefined". I doubt it's doing any scanning at runtime, which is why boot on these things is so painful - pay for that file I/O and XML parsing up front and not on a map draw or a user touch event. So I think I agree with Minera'ls understanding (educated guess - same as mine) except I'd make the "last" instead of "first" be the authoritative copy that's kept in the master DB and that's dragged into the more efficient (likely a quadtree) structure so you can map them without killing that ARM core. Oddly enough, one of my hobby projects right now is programming an OS on a computer ... with 32K of RAM. I'm porting the OS that would have been about what was in use in the mid 70's. I knew the guy at IBM that managed the team that did the Fortran compiler for the 1130 - because I've programmed those, too. I think it was used on either 1800, too, but I never used one of those. Oh, and get off my lawn. :-)
  17. I'm the creator of one of the software titles mentioned and there was a time I could recite the bytes in each packet during a waypoint exchange. I generally agree that the serial units are simply too aggravating to try to use in modern times. The operating system and driver issues will just drive you mad. +1 to "LIfe's too short" A lot of the hardware - as you apparently just discovered - is so old that it's just dying of old age from metals separating or mechanical fatigue. GPSBabel still "supports" this era of Garmins but it's not like I test every model on every release on every OS any more. Several of the serial-era GPS units have serious issues with the GPS week rollover from last year and are just terribly confused about life after April, 2019. I had several people fume at me about this like somehow GPSBabel was supposed to fix their firmware issues. I have given serious thought to removing the Garmin serial support. The reality is that it's deeply entwined with the Garmin USB protocol support and I'm not quite sure that all of the 60C/76C/60Cx/60CSx are out of circulation yet. The Magellan serial support is still there because it's dead simple, but I'd bet that it's not been used in years. That code has tentacles from the Explorist 400/500/600 which are USB, but I'm skeptical that they are in use, either. Somewhat ironically, my other hobby is small electronics and in that world, USB/Serial adapters are _also_ the bane of my existence. Instead of spending a quarter for a "real" USB device that runs at a reasonable speed and is self-identifying, the preference is to build the CPU with a serial port and then spend a nickel on a USB/Serial adapter. This is why your new gizmo is indistinguishable from a Palm Pilot; they all just look like a serial port to the computer. :-/ Still, thanx for bringing closure to the conversation. So many people start these discussions and then don't post the final findings, even when that involves $25 to Ebay for a better GPS.
  18. Wild guess: Silicon availability? It's possible that Garmin isn't fabbing their own SoC; they're probably riding the coattails of high-volume products as used by tablets or phones. Sometimes an EOL (end of life) announcement catches you off guard and you have to pivot to a low-risk chip change that uses an "old" feature set or code base just to buy time in the market until your new product that's in active development can launch because it's held up by a part that's not available quit yet. So you do very little engineering on a "distraction" and product marketing and sales gets to herald a "new" product while you quietly discontinue the original. Maybe the QZSS and IRNSS receiver chip wasn't ready for mass production yet but the LCD panel or the processor or memory or *something* in 64 that they didn't absolutely control was headed for a rapid descent to unavailability, so they got the "b team" (sorry) to squirt out a 64 that they could actually manufacture at scale while they finished the 65. Maybe that had a contract they could win with the 64 which ticked all the boxes except Galileo so they just changed the receiver chip and base firmware to support that. This was pretty much the difference between 60cs and 60csx, if you recall. The "x" was just a better version of an already popular device. Over my time in engineering, I've been involved in several of these, both as the A team and the B team. I'm barely in the GPS biz at this point, but the 62-66 product line is so thickly saturated that I can't remember how they're different offhand. Using smaller integers for newer and more featured products is not helpful. No inside information on why Garmin does/did what they did. Just offering one possible explanation other than "drug use".
  19. Windows actually made some changes recently (in Windows years) to have fewer dirty blocks waiting to be flushed to the USB in case of an abrupt removal. See, e.g. https://www.howtogeek.com/410353/how-to-optimize-usb-storage-for-better-performance-on-windows-10/
  20. And this. This subject dominates our front page of active topics...
  21. Please see below. Between those two choices, the product that actually exists is the runaway favorite. :-)
  22. Quite interesting because they don't list the Oregon as a Linux-based product at https://developer.garmin.com/open-source/linux/. If It's Linux based, there are license obligations that they have to meet. These files should definitely be preserved for research's sake. It's certainly strange that the GPS would have files that are clearly for a Raspberry Pi. It's odd that there isn't really a recognizable filesystem, but maybe one of if the img files is like an ISO image or MacOS dmg where a "real" filesystem is married atop a lesser filesystem. Are you sure that this H: is the Garmin and not some other device that's plugged in?
  23. The piece you are asking for that I don't have is the PC code to send an upload to the 330. It was a special utility and I just don't seem to have it. Any other Magellan packrats out here able to help? PM Sent.
  24. Map330 and Mericolor used similar, but different firmware. The age of these units (~20 years) and the destruction of the yahoogroups archives, which held most of the wealth of info on GPS of this era, have made "classic" info hard to get. (I actually have a copy of the relevant yahoogroups on file...) If you have the version that came with your unit, the relevant part of a doc by Trainlove (!?!) seems to be: Open the firmware file, called something like mgold541.hex, with Windows WordPad or NotePad. When you save it be sure to save it as plain text. It is big, about 5 Megs. Search for 23232328 or if that is not seen, due to its crossing a line boundary, then search for 18181818. This is way down close to 90% of the way to the bottom of the firmware. Either will only occur in the one location in the firmware, and within a couple lines of each other, blanketing the area we want to modify. There is a small tutorial on Motorola S-Record files several paragraphs down from here. Only make the following changes. I will be very specific here, there is space for exactly 6 WAAS satellites, 2 characters are for the Hex PRN number i.e. 7Ahex=122decimal for satellite PRN122 which some know as NMEA ID 35 (but we Magellanites do not care about that). And preceding each satellite are 6 characters, the first 2 always seems to be 00, then the next 4 appear to be the satellites Longitude, in Hex, with special care if that is a West (negative) Longitude. Then open the Windows Calculator. Click <view> and then select <scientific> since you will need to use the Hexadecimal mode. So also click that button. Find out what WAAS satellites exist perhaps using celestrak.com/NORAD/elements/sbas.txt, and what ones should be visible from your location by using a satellite tracking program, or a satellite TV antenna positioning program, to process those NASA 2 line elements. Some WAAS resources online are years out of date. One site that is very current (for the USA) is the FAA but Lat & Long of satellites is only valid for the WAAS satellites, the others are moving really fast relatively to any point on the ground. Convert that PRN number from decimal to hex, I.E. In the calculator, when in decimal mode enter 122 for PRN122, press Hex mode and you will see 7A. That 7A is what you are going to change to or from in the firmware. Remove the 'dead' satellites, and replace them with the good 'new' live ones. I detail that in a later bullet. Make no change of the Longitude, perhaps you will need to do so but not yet. Oh, you might see the things like the 7A repeated all over, but that could be part of a Longitude or Address or Checksum so only modify the specific 2 characters that are the PRN number for the satellite. And they occur in pairs, so be sure to not try to modify the last character of one byte and the first character of the next byte, all you will do is make a mess of things. That all sounds familiar: that generation had a table of hard-coded satellite numbers of the WAAS birds and when the SV numbers were reassigned early in this century, the table had to be hand-changed. Map330 is pretty far in my past and there's a whole lot of (poorly organized) files in the archives that were mechanically grabbed. If you can send me a believable version number of what you're looking for (2.09? 4.0?) based on what's in your model now, I *might* be able to dig something up. But the above is the general recipe to "fix" WAAS in whatever version you have now.
  25. GPSBabel (one word) told you exactly what the problem is. Your GPX file is nonsensical, jumping the rails starting at line #25. There's a closing GPX tag at line 24 but there's gibberish following that. By the time it got to character #40 in the 25'th line, it abandoned hope and baked you an error message cake. <trkpt lon="-122.97039" lat="47.62169"><name>Finish : 28/07/2020 10:40:23</name><desc>38.5 Miles</desc><cmt>0 Mph</cmt><time>2020-07-28T17:40:23Z</time><speed>0.0</speed><ele>106.3</ele><sat>0</sat><course>0</course></trkpt> </trkseg> </trk> </gpx> <rtept lon="-122.97039" lat="47.62169"><name>Start : 28/07/2020 10:40:23</name><desc>38.5 Miles</desc><cmt>0 Mph</cmt><time>2020-07-28T17:40:23Z</time><speed>0.0</speed><ele>106.3</ele><sat>0</sat><course>0</course></rtept> <rtept lon="-123.34444" lat="47.02553"><name></name><desc>97 "Looking fine" isn't the same as being fine unless you're actually familiar with the GPX specification. (I am and the file does not "look fine".) You can't just signal the end of the gpx document and then have dangling rtepts that aren't part of an rte that aren't part of a gpx and such. Structure matters. Those tags actually have meaning and the order usually counts. See the specification at https://www.topografix.com/gpx.asp. GPSBabel will let you get away with an otherwise valid <rte></rte> block before the <wpt> block, but it's not actually valid GPX if you do. GPSBabel will (mostly) "fix" the order of the inner tags when it writes it, but the file has to be at least kind of valid to start with. There are trkpts that have escaped their trksegs with totally absent trk tags. This file kind of resembles GPX, but it needs reconstructive surgery to make it something valid and useful. This also doesn't appear to be actually geocaching related. GPSBabel is a conversion utility, not a file recovery program to unscramble things. A large part of GPSVisualizer is a front-end to GPSBabel. Whatever created this file did not create a valid GPX file.
×
×
  • Create New...