Drove few hundred meters forward, dropped another flag, export to GE, same position as AOG which is 53.003201, -113. Chose -113 because it is right on the edge of a zone and therefore high CA of -1.6
I once made a field that was 3km long by 1.6km wide - country block here. Just drove around it with the truck and gps. Over that distance the sections showed up exactly where they should. Shall keep looking.
@KentStuff BTW, are you removing the convergence angle and then adding convergence angle again when importing the border? Perhaps adding it twice?
Brian, just for my piece of mind, can you bring that flag back into AOG using the lat/long and see if the easting northing is still the same?
Might have to build a little routine just to read the flag lat/long and convert to easting and northing.
I know it is spot on going flag to flag. Even section to section. I don’t put much faith in GE either. I think the main issue is in the rounding and small math assumptions. I built a boundary from list routine that you manually insert points (easting and northing ) not lat and long. I’ll check this and see if they overlap.
That should work. Probably need an option to set point directly under the antenna. Then a person could walk with a pole and mark it out.
Left, Right, or antenna.
Yes, watched it before and knew what it does. But did not pull the convergence angle back out going in reverse. Figured it was built in. Now reversing those two equations. Back to trig class.
Exporting flags do not have this issue because they are using the original lat and lon saved with the flag. If they only saved the utm coords, then unwinding the CA would be required.
Absolute genius. Works perfectly. Unbelievable. My apologies. There was a problem with the kml out conversation. The convergence angle was not unwound.
Thank you again Brian.
Also, you mentioned in another post about showing the slope of the land. If you right click on any of the lines shown in GE you can see an elevation profile. Not sure it is useful, but there are some extreme slopes to be farming in your area. No wonder you need a roll indicator. Not so much in Florida. Pretty flat here.
About the same - but not the same. I’ll let you figure out where you have 2 bugs for sure in calculating the original point position. I am confident you will find it! Well 1 bug, 1 unnecessary.
Yes double did the addition. I thought I deleted the top one after I copied it down. I could not figure out how come it still worked. So I ran the same field both ways to see. Google Earth, you could not tell the difference. Went to the KML out files and found it to be accurate to the 9th decimal place even with the error. That’s why I missed it. Thanks for the help and patience. And yes there is a lot of unnecessaries in my code. Still learning.
public void BuildPointLATLON(double easting, double northing)
{
double XO = 0;
double YO = 0;
easting = (Math.Cos(pn.convergenceAngle) * easting) - (Math.Sin(pn.convergenceAngle) * northing);
northing = (Math.Sin(pn.convergenceAngle) * easting) + (Math.Cos(pn.convergenceAngle) * northing);
XO = easting + pn.utmEast;
YO = northing + pn.utmNorth;
UTMToLatLon(XO, YO);
}
There still is a bug in there! Deleting the extra addition wasn’t the bug since it didn’t use those variables till later anyway. It’s a really sneaky bug.