Corner points when creating boundary

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?

2019-12-18 (7)

1 Like

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.

Added a button to the boundary control form. Works pretty simple.

https://www.youtube.com/watch?v=nqbzdiHXvkA

Step 1. Flag created in AOG coords and second line same flag saved in GE kml:

AOG : -113.0006904,53.00064489999999,0
GE: -113.0006904,53.0006449,0

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.

So, the easting and northing for both are the same also? I’ll look to see about the convergence angle.

exported, saved as place, imported back to AgOpen. I’d say close enough lol.

2019-12-18 (8)

I’d say close enough. That’s good to know.

Have you seen this video?

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.

Just negate the convergence angle:

coming in

easting = (Math.Cos(-pn.convergenceAngle) * east) - (Math.Sin(-pn.convergenceAngle) * nort);
northing = (Math.Sin(-pn.convergenceAngle) * east) + (Math.Cos(-pn.convergenceAngle) * nort);

going out

easting = (Math.Cos(pn.convergenceAngle) * east) - (Math.Sin(pn.convergenceAngle) * nort);
northing = (Math.Sin(pn.convergenceAngle) * east) + (Math.Cos(pn.convergenceAngle) * nort);

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.

image

Good to hear, was fairly sure it worked - but it all is quite tricky!!

Just to make sure i took the utm from a flag and made sure it worked by comapring the save lat lon with the calculated lat lon. Works well.

      double easting = flagPts[flagNumber - 1].easting;
        double northing = flagPts[flagNumber - 1].northing;

        double east = easting;
        double nort = northing;

        //fix the azimuth error
        easting = (Math.Cos(pn.convergenceAngle) * east) - (Math.Sin(pn.convergenceAngle) * nort);
        northing = (Math.Sin(pn.convergenceAngle) * east) + (Math.Cos(pn.convergenceAngle) * nort);

        easting += pn.utmEast;
        northing += pn.utmNorth;

        UTMToLatLon(easting, northing);

        double lat = utmLat;
        double lon = utmLon;

Yup, close enough :slight_smile: Exact same spot.

2019-12-18 (9)

About the same. I built a routine to call at any time. Using it to call all of the saveKML stuff.

public void BuildPointLATLON(double easting, double northing)
{
double XO = 0;
double YO = 0;
XO = easting + pn.utmEast;
YO = northing + pn.utmNorth;
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);
//double latpoint = YO;
//double longpoint = XO;
}

That’s a super feature for us.

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.

I’ll try to format here, it isn’t 2 lines but rather a rotation matrix denoted by the “|”.

x’,y’= | cos(ca) -sin(ca) | * x,y
-----…| sin (ca) cos(ca) |

The picture below is for counter clockwise rotation, but i think you get the idea.

media_588_58826868-908a-4940-800f-c66861a272f7_php2v3JVS

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.