Chipper3
-
Posts
168 -
Joined
-
Last visited
Posts posted by Chipper3
-
-
Thanks to everyone that took the time to help me!
The problem that I was having is solved. The error comes about as the first conversion tool I used to convert the NGS coords did not allow me to put in decimal readings in the seconds field for DMS entry to convert to the input my mapping program wanted as input. (Yes, Yes, I used a poor tool but I was ignorant at that point)
So the difference of 1 second equals 100 feet. the actual reading for Lat was 3.42411 seconds so by entering 3, I would be off by 42 feet. When I add the same error for the Lon, I get the increased error which accounts for the 50 feet that I originally reported.
Digits Matter!
-
2
-
-
The third point referenced in the original post is the one that showed up 55 feet away. This was the location given by NGS as the location of the marker. My computations resolved the posted marker a 55 feet away from what my devices read.
-
7 hours ago, baer2006 said:
Converting this to deg/min gives N34°34.0570685' W82°37.5181027'
The distance between the position in the NGS data sheet and your measurements is 2.5 meters (Garmin) and 3.6 meters (iPhione). Easily within expectations for consumer devices.
Therefore, it seems that I don't understand your original problem
. Exactly what is "55 ft off"?
-
I am adding my device generated coords to the discussion for your use-
Garmin 64 ST with averaging N34 34.0582 W 082 37.5172
iPhone Averaging Tool with 30 readings N34 34.059 W 082 37.518
-
1 hour ago, baer2006 said:
This is strange. For consumer devices, NAD83 and WGS84 are indeed effectively the same - AFAIK the difference is less than 1 meter (will slowly change in the upcoming centuries because of continental drift).
However, 55 ft sounded reasonable for a difference between NAD27 and WGS84. I peeked into your profile, and you give your location as Anderson, SC. Assuming that you ran your test in your home area, I picked a random point in Anderson. Then I used an online NAD27-to-NAD83 converter to see, where I land when I use my point's WGS84 coordinates with the NAD27 datum. Result: 56 ft difference! IMHO that's too close to your 55 ft measurement to be a coincidence. Therefore my guess is that somewhere in your results there is a hidden NAD27/NAD83 datum confusion.
Thank you for your response. I hope you will investigate further for me as you seem to be on to something. I am providing information on the marker in question:
ED3783
The associated Data Sheet is found at https://www.ngs.noaa.gov/cgi-bin/ds_mark.prl?PidBox=ED3783
All the readings from that document look like
NAD 83(2011) POSITION- 34 34 03.42411(N) 082 37 31.08616(W) ADJUSTED
The link to the site I am using - https://geodesy.noaa.gov/NGSDataExplorer/
I am exploring your suggestion by making a conversion of their stated coords from NAD27 instead of NAD83 and will post my findings.
-
Yes, I realize that our hand held consumer devices have error but...
I decided to run an experiment on Accuracy and Precision of a couple of devices against a known National Geodetic Survey Marker. I assumed that the location of the physical marker and its coords would be the Gold Standard of what a GZ actually is.
I used my iPhone running a coord averaging tool and collected 30 data points over time and by moving and returning to the actual NGS marker. I used my Garmin 64ST in averaging mode and collected 4 100% readings for the same NGS marker over several hours.
MY iPhone and the Garmin GPSr were pretty much in agreement to the average coord location. But when I plotted the results of my readings and included the published NGS coords for the marker, I found that the published coords for the physical marker were 55 feet way from 1.) the two device coords/locations and 2.) the actual in-the-ground marker. Let me repeat the NGS marker is embedded in concrete. The NGS published coords for that location are 55 feet away. My GPSr readings for that marker are 5 feet away.
I checked the datum systems used by both devices and the NGS and the coords are all in agreement. I am pretty sure that I have an apples and apples comparison. In the spirit of full disclosure the NGS data is reported in NAD83 and my readings are in WGS84. My conversion app shows the same coords for both datum.
Hmmmmm....
Advice and comments welcomed as I am out of my league here. I thought I would learn something about the Accuracy and Precision of my devices against a known location but what I found was unexpected.
-
7 hours ago, arisoft said:
That would cause more work to reviewers, as many of these "caches" would never be published. Also it would render the reviewing useless, as the CO could make changes that are not reviewed.
The reviewer in my area recommends the "Submitting for coord review" approach and using that approach is the path I have followed and it has worked very well.
-
1
-
-
12 hours ago, instep_guy said:
Speaking as someone who has rushed out to get a FTF on a new cache only to get the FTDNF due to the cache not having been placed yet... its not OK!
I understand completely. I am glad I sought advice. The correct path is to do the research on site and fill out the cache page for submission (without installing the hardware.) then submit for review and put Coord Check Only in the cache title and submit a Reviewer Note describing the intent. This approach has worked out just fine. Thanks to all who set me straight and pointed me to the right path!
-
.png)
3
-
1
-
.png)
1
-
-
11 hours ago, schmittfamily said:
We have done a multi-cache that was exactly like the description in the original post.
It was GC406DK (since archived due to owner moving and it was on their property).
The first 4 stages were all trackable tags physically mounted to objects around the property and the fifth was the container.
You had to load up the trackable page and look at the capital letters in the trackable description to get the next object to look for.
Each trackable had one digit for the lock at the final in it's description.
The trackables involved were tb5kd8m, tb5kd9k, tb5kd8g, tb5kd8b if you want to look.
It was an enjoyable cache for us to do.
That is exactly what I had in mind. Thank you for sharing!
-
51 minutes ago, TeamRabbitRun said:
I go low-tech.
First stage: I get super-accurate coordinates. Multiple visits, different times of the day, then average. Do this a LOT because everything else will depend on it. Post these coordinates.
Stage two: Make the location of Stage One a waypoint on your device; either GPSr or phone. Go wander around until you find a nice place for Stage Two. Standing at Stage Two, read what your device tells you are the Bearing and Distance to get to Stage One. (ACCURATE!!!!! More waypoint averaging!!! Get this right!!!) Reverse the Bearing. That means the OTHER WAY on the compass. 90 degrees becomes 270, 23 degrees becomes 203, 300 degrees becomes 120, etcetera. THAT's what you place in Stage One as directions to Stage Two.
Stages Three & Up: Start with the coordinates for Stage Two, and repeat.
Then, the seekers have two choices:
- The seeker projects a waypoint. As stated, above most if not all GPSrs can do this, MOST phone apps can't, OR
- If the seeker has no way to project a waypoint in the field, then he or she or whatever can reverse the bearing, and use that reverse bearing and distance to get to Stage Two. That's a different kind of navigation that many people would find fun and challenging (me, anyway; maybe no one else) because you're working BACKWARDS!
These options would have to be explained in the cache writeup, of course.
I can't stress enough the importance of getting absolutely accurate coordinates for each stage, because an error on your part will be cumulative across the stages.
I use this as a suggested method in my PIA puzzle cache "Splelnig Cunots". Apologies to my foreign brethren who go look at it. You'll see.
I am in complete agreement on working hard to get an accurate Waypoint/Stage reading. The errors in sighted bearing or the small differences depending on the projection calculator app are insignificant compared to the large errors in coords. Whether using coords or projection for the next Stage, I also include a clue or a hidden marker that the cacher can find once they get close. Most are night caches so I use the birds eye reflectors (Eyes in the Trees) to get the cacher starting the next stage at the correct location.
Also, over short distances an error in sighting the bearing will not throw a cacher too far off. Having said that, for a distance of 300 feet, an sighting error of 1 degree would cause a projected error of 5 feet. A sighting error of 5 degrees would resolve to 25 feet which would be a disaster without a clue to fine tune the location once close. The cumulative errors would kill the joy. =) So, those projected distances better be on the order of 150 feet.
-
1 hour ago, Mn-treker said:
What you are really doing here is to project a waypoint. Any GPS can do that, but maybe not A phone GPS. I have a few like this one listed as a puzzle. I would make sure that the distance from stage to stage is not too great. Long distance may cause error. At each stage just give them the Bearing and distance. Make sure to tell them magnetic or true. that will be important.
Thank You Sir! So now I need advice on whether a cache should be listed as multi or mystery as the projection to the next Stage waypoint must be calculated in the field. The cacher would have to jump to a site like Tool Box to make the projection or have a 3rd party app available for use on their device. I doubt if most could make the calculation without the help of an additional app.
-
Thanks to all for your input!
I used all of the methods suggested plus google map and Google Earth Pro
Method in my Original Post - Distance = 278.770 feet Bearing = 12.87 degrees
Tool Box - Distance = 278.192 feet Bearing = 12.92 degrees
Ed Williams - Distance = 279.526 feet Bearing = 12.43 degrees
Google Map - Distance = 278.040 feet
Google Earth Pro - Distance = 278.620 feet Bearing = 12.33 degrees
iGCT Mobile Toolkit - Distance =280.000 feet Bearing = 12.38 degrees
For Geocaching purposes, it would seem that all these methods produce a functional result. Especially since the cacher's GPS is going to be 10-20 feet off anyway. I am adopting the Tool Box Method based on the input from Karst. And the fact that the drawing methods could be subject to use error in placing the line between dropped map pins.
My app for drawing a line between two points set using the apps geo location method for capturing and dropping a pin just has too much "jitter" making the coords used just have to much error and therefore the distance and bearing to be wonky. I will look for another app as that sure was handy.
-
Thanks to all the responders with your good and helpful advice! I have submitted with all the recommendations suggested!
-
I am setting up a multi-cache. Each stage has a message providing a Bearing and Distance and a Hint to next stage instead of the coords of the next stage.
I can use several methods:
- Method 1 - I have an app that allows me to mark stage 1 waypoint and then mark stage 2 waypoint and the app provides a straight line distance and bearing from waypoint 1 to 2. The problem is that I find a substantial difference between Method 1 and Method 2.
- Method 2 - I work the site in order to get a good average waypoint coords for waypoint 1 and waypoint 2. Then I plug those values into an online navigation tool that uses the haversine algorithm. The calculator returns the Distance and Bearing. The calculator also returns a satellite picture of the two waypoints and the distance line between them. As a side note, I find the calculator's map much more accurate than just plugging the coords into Google Map.
What is the best way to accomplish this? What method do you use?
The online navigation calculator I am using is https://www.movable-type.co.uk/scripts/latlong.html
-
.png)
1
-
I have learned my lesson about laying out and populating a multi-cache and then submitting for review and then having rejected because of proximity to the hidden stages of another cache. I can check for the "red circles" when designing but only see the posted coords.
I do walk the grounds and grab accurate coords and fill out the New Cache "Application" but just do not want to install the hardware until approved.
My plan would be to get approval, immediately mark disabled, populate the hardware, mark back to enabled.
Thoughts and Advice welcomed!
-
2
-
-
7 hours ago, arisoft said:
Not as a multi-cache. It is a mystery cache, because "The cache cannot be found without research that goes beyond reading the cache page."
I have always thought of multi-caches as having clear directions (coords) to the first stage. Then the "directions in the field" that are found in the field lead to the series of caches and then a final one. Directions in the field can include a bearing and distance to the next stage. From the Help pages on types of caches - "The cache can be found by reading the cache page and following the instructions in the field.")
So, I agree that the use of externally found info (for example a TB Page) moves the cache type into mystery type. If I provide the series of bearings and distances or coords at each stage then still a Multi. If a simple puzzle must be solved with info found on the site or in the field then it is still a Multi.
It becomes a Mystery if posted coords are bogus and/or the cacher must use externally found information to find the next or original stage. It is OK to solve a puzzle or solve a mystery to progress if all the info is either on the cache page or found in the context of the stages that comprise the Multi.-
1
-
-
As I think about this, I prolly do not need to go to the trouble of having all those Bugs and associated pages in order to communicate a bearing and distance from the current stage. I was going to post a plaque with the Bug Code but I could just as easily have the plaque show bearing and distance. That way if there is no internet access, the cacher would not be stopped and frustrated.
I plan to also incorporate my night-cache technique of using "Bright Eye" reflectors to mark the location of the next stage. A beam is played along the bearing while walking the approximate distance on that heading . The Eyes light up to locate the next plaque.
No real need to use the Bug Codes unless I include other clues and puzzles in the Goal/Description that would be kinda' the permanent depository that would not be subject to weather and muggles.
Please keep the thoughts and suggestions coming! =)-
1
-
-
23 minutes ago, The Jester said:
The 'problem' I could see is that the TB's are listed for owners, so instead of having to find it, you could just look it up on the owner's profile page.
What I've seen done is a two TB's, each with half the next stage co-ords, that float about the region. The problem is they sometimes leave the area they are suppose to stay in.
Thanks for the feedback. Yes, the Bug could be looked up but the goal and description information will make no sense unless the cacher is standing at the current stage. The description gives a bearing and a distance but no coords to figure out from where. Or maybe I am mis-thinking this. =)
-
What are your thoughts on this idea? Does it fit guidelines? The general idea is that TB Reference code is used to convey the information needed for the next stage.
- The quest begins with a typical cache description and a set of waypoints to the first stage.
- The first Stage uses a marker which is actually a Travel Bug Tag or a more permanent engraved tag using the TB Code. Directions (Prolly bearing and distance and a hint) to the next Stage are listed in the Goal and About for that TB and found on the Geocache site. The information references no coords so the cacher must be at that Stage for the directions to be of value. The cacher would use the app to look up the bug code to get the info.
- The next N+1 stages use a similar scheme.
- The final stage is a more traditional cache container with the log and swag, etc.
-
Thanks to everyone for the encouraging comments.
A link to the first of the Fairy Light caches in the series. https://coord.info/GC8HG3G
Cihpper and PoppyFlower
-
We carefully constructed a series of caches (5) that are each part of an ongoing story. Four can be found independently but information from the four must be found before finding the fifth. The creation was so much fun and so well liked that we were tempted to start a new series. But we have opted out for the pleasures that are also associated with maintaining/enhancing the exiting series. We found that keeping 5 caches in good shape was plenty time consuming. Also enhancing the caches and the cache location environment to add to the backstory was better for us and the finders than adding more caches. Quality not Quantity was the right tactic for us.
For example, the original caches were housed in a solar-powered yard lights and the light would glow at night indicating the actual location near the coords. Cool idea but a maintenance nightmare. The caches leaked and the battery recharge was iffy depending on seasonal shade. The upgrade evolved to cedar birdhouses housing LocknLock containers. The new houses have numerous Birds Eye reflectors which light up when a flashlight is directed along the bearing line included in the description and this technique allowed us to keep the theme used in the Fairy Light series! The caches evolved to more secure and more fun to find with much less maintenance. Plenty of other enhancements as well including special laser-cut Geocoins for each cache.
If we had moved on to creating more caches, I think we would have reached a point of not being able to enjoy and support/enhance the original caches.
-
1
-
1
-
1
-
-
16 hours ago, barefootjeff said:
Just a thought, check that you haven't inadvertently clicked on the pencil icon next to the coordinates at some point and set Corrected Coordinates. If you have, the coordinates will be shown in italic font with an underline, like this example:
If that's what's happened, you can clear it by clicking on the pencil icon and then clicking on Restore:
Thank you very much, barefootjeff! That had happened and the restore also fixed confusion on the list of waypoints on the site. All is now well! Only the correct waypoints show up without an extra one.
-
Thanks to the responders! Yes, got to be a cache issue! I'm glad the correct info is now in place but I cant get my browser to show correctly.. I'll give it some time. Not the first time cache has caused me pain! =)
I tried all of the cache clearing methods. Even logged in from a different computer that has never accessed Geocache site. I still can't see the coord changes.
What am I missing?
-
Additional info: the listed coordinates in the header should read N 34° 52.442 W 82° 22.443 and not N 34° 52.443 W 82° 22.438
. Exactly what is "55 ft off"?.png)
.png)
.png)
55 foot Discrepancy Between National Geodetic Survey Info and GPSr/Phone
in General geocaching topics
Posted
Thank you!