+chauqg Posted July 4, 2006 Share Posted July 4, 2006 (edited) Downloads differ from paged coordinates given on individual cache sites. My workaround is to check every set of coordinates, then looking for both since they can't tell us which set is correct. Answer from GO: I have passed along the information you have provided me to our development team. They are now aware of the issue and working on a solution. Unfortunately, I don't have a workaround for the difference. Thank you for your patience and understanding. Please let me know if I can be of further assistance. xxx Groundspeak Inc Ticket Details =================== Ticket ID: DTG-xxxxxxx Department: Geocaching Priority: High Status: Closed Nothing since 27 June 2006 (Thanks) -> This is not difficult to fix! A simple rounding algorithm applied would solve it everywhere, but where is everywhere? Why are coordinates numeric anyway?! Conversion from text for calculations could be uniformly done, but It does not seem to be uniformly applied. I dont think anyone knows where the code is! Another example of software outgrowing the ability of the engineer to maintain it. Edited July 4, 2006 by chauqg Link to comment
+The Leprechauns Posted July 4, 2006 Share Posted July 4, 2006 chaugg, you have a serious bug in your calendar algorithm. When are you gonna fix that? Link to comment
+chauqg Posted July 4, 2006 Author Share Posted July 4, 2006 chaugg, you have a serious bug in your calendar algorithm. When are you gonna fix that? I like many humans am error prone, but anxious and willing to correct my mistakes when they are pointed out to me. Thanks for the heads up. Link to comment
+RichardMoore Posted July 4, 2006 Share Posted July 4, 2006 Nothing since 27 July 2006 -> This is not difficult to fix! A simple rounding algorithm applied would solve it everywhere, but where is everywhere? Why are coordinates numeric anyway?! Conversion from text for calculations could be uniformly done, but It does not seem to be uniformly applied. I dont think anyone knows where the code is! Another example of software outgrowing the ability of the engineer to maintain it. July 27, 2006? Link to comment
+Groovy Cachin' Dude! Posted July 4, 2006 Share Posted July 4, 2006 What are you downloading the coordinates into? Why is the status "closed" by GC? Link to comment
+Lil Devil Posted July 4, 2006 Share Posted July 4, 2006 Why is the status "closed" by GC? Only the email ticket is closed. A question was asked and it was answered. Ticket closed. I'm sure the actual bug is in their separate bug tracking database. chauqg, can you give an example of what you are talking about? Link to comment
+chauqg Posted July 4, 2006 Author Share Posted July 4, 2006 Why is the status "closed" by GC? Only the email ticket is closed. A question was asked and it was answered. Ticket closed. I'm sure the actual bug is in their separate bug tracking database. chauqg, can you give an example of what you are talking about? I have copied coordinates from web location - then checked caches against download seen below: Devils Elbow @ 40 35.000 79 59.558 downloaded .loc @ 40 35.000 79 59.557 At that time ( & I'm still a newbie) I had been on 10 caches and there were 3 errors like the above. The other caches were Gossamer Wing @ north park .195 vs .194, also Who'd Picnic Here @ at north park. All were off by .001. Since then, I have been copying the information from the web page until they get it right. It is much easier than checking every entry. BTW There is no possibility of editing error as the downloads were never edited - just uploaded into software. I still don't know which set of numbers is correct, but I'm going with the web coordinates. With a "premium service" this basic of a problem should be unacceptable, and fixed immediately with appropriate notification to the users who were and are being given bad information. The problem seems to be that someone has used a numeric (floating decimal) format for a number that is normally text (alpha-numeric - which is common practice) but elsewhere the programmers are not using a consistent rounding formula, which is need to be applied to all decimal numbers to insure consistency in the decimal accuracy of every (decimal) number in the system. I hope this is a better explanation. Link to comment
+Lil Devil Posted July 4, 2006 Share Posted July 4, 2006 Considering a difference of 0.001 minutes is about 5 feet, and GPS accuracy is around 30 feet, I wouldn't worry about it as much as you are. Link to comment
+pghlooking Posted July 4, 2006 Share Posted July 4, 2006 Considering a difference of 0.001 minutes is about 5 feet, and GPS accuracy is around 30 feet, I wouldn't worry about it as much as you are. I would agree with his examples(being minimal at best), but I know of at least one other time it has occured(larger scale) that I was the lifeline at home. YemonYime was on vacation in NC and the coordinates were way off(over 400' IIRC). He called me to verify them and I got the correct ones off the web page. I would agree that this needs to be given more time than the OP has given GC to "fix" it though. Maybe they can post here after the holiday, to let us know whether this was a freak occurance or an actual bug that is being worked on. Link to comment
+chauqg Posted July 4, 2006 Author Share Posted July 4, 2006 5 feet, I really needed that L'Devil. I'll get back to downloading coordinates. Thanks Chauqg Link to comment
+fizzymagic Posted July 4, 2006 Share Posted July 4, 2006 (edited) I have copied coordinates from web location - then checked caches against download seen below: Devils Elbow @ 40 35.000 79 59.558 downloaded .loc @ 40 35.000 79 59.557 Since the coordinates in the .loc file are not saved in the DD MM.MMM format, but as floating-point numbers, let's check: From the .loc file: <coord lat="40.5833333333333" lon="-79.9926333333333"/> Those coords translate to: N 40 35.000, W 79 59.558 (to a higher precision, it's N 40 35.000000, W 79 59.5580000) There is no bug in the website. However you converted to DD MM.MMM is incorrect; maybe your GPS has a minor rounding problem. In addition, your claim that the data should be stored as text is just plain wrong. Coordinate data is numeric, and should be stored that way. They are certainly stored as numeric values inside your GPS unit; that's how it can convert between different coordinate formats and datums. But you seem awfully worked up over an error of 4 feet. Edited July 4, 2006 by fizzymagic Link to comment
+chauqg Posted July 5, 2006 Author Share Posted July 5, 2006 Yep, Was worked up over nothing. Did not know what I did not know. the error was in the file as presented on the computer not in the gps. Not sure where problem came from, but it is as you have all indicated insignificant. Someone is doing the rounding and not doing it consistantly, but that is no longer an issue. Thanks for the information, Chauqg Link to comment
+sbell111 Posted July 5, 2006 Share Posted July 5, 2006 There have been a couple threads on this 'issue' over the years. As I recall, the general concensus has been that it isn't a big enough deal to care about. Link to comment
robertlipe Posted July 5, 2006 Share Posted July 5, 2006 maybe your GPS has a minor rounding problem. ...As most Garmins actually do becuase of weirdness in their protocol and internal implementation. There are many numbers that, when sent to the Garmins, incur single digit rounding differences due to the conversion between decimal degrees and semicircles with limited precision. Even without the conversion, some units have some internal "jitter"; I've seen cases where I can put one bit value for the semicircle units on the wire to the unit and get another on the way back out which will result in the twinkle of that last digit. But in no case is it significant. Link to comment
+chauqg Posted July 6, 2006 Author Share Posted July 6, 2006 Yes, I finally gathered that it was not significant. Thanks for your follow-up Cheerz Chauqg Link to comment
+Roman 8:28 Posted July 11, 2006 Share Posted July 11, 2006 I'm a new owner of the GPSmaps 60CSx. I find that even when I enter certain coordinates on the handheld that the last digit moves occasionally. I have my unit set to UTM and WGS84 (as well as other settings) and certain entries are not acceptable to the gpsr. From my experience the problem is the Garmin unit and software. I've had a question into Garmin since 07/05 and no response yet. Yep, Was worked up over nothing. Did not know what I did not know. the error was in the file as presented on the computer not in the gps. Not sure where problem came from, but it is as you have all indicated insignificant. Someone is doing the rounding and not doing it consistantly, but that is no longer an issue. Thanks for the information, Chauqg Link to comment
+StarBrand Posted July 11, 2006 Share Posted July 11, 2006 I'm a new owner of the GPSmaps 60CSx. I find that even when I enter certain coordinates on the handheld that the last digit moves occasionally. I have my unit set to UTM and WGS84 (as well as other settings) and certain entries are not acceptable to the gpsr. From my experience the problem is the Garmin unit and software. I've had a question into Garmin since 07/05 and no response yet. Yep, Was worked up over nothing. Did not know what I did not know. the error was in the file as presented on the computer not in the gps. Not sure where problem came from, but it is as you have all indicated insignificant. Someone is doing the rounding and not doing it consistantly, but that is no longer an issue. Thanks for the information, Chauqg By moves do you mean it changes after you hand enter it to a new number?? Link to comment
Recommended Posts