I’m looking to understand better how AoG handles copying lines between fields. Currently I have a few fields that share a boundary and I’d like to use the same AB line for both so after I create the AB, I copy the ab.txt file (btw I love the ability to manipulate/prep/cleanup field data on my desktop with regular txt files) to the second field. Sometimes there’s an offset. Most times that’s fine, I can edit the AB and save at the correct position but I’m curious how it works. I’ve heard that is important to create the field with a current position that’s close to the field. So that all being said, here’s an example.
The red is where I created the first field, then I created the AB (it’s long because I’m using two land survey markers but less then 5km). Then I created the 2nd field at the yellow and copied the AB to it. After copying, it had an offset for the 2nd field. I was parked in the correct location to just snap and save but I might not always be. How does this work?
You will need to import the ablines from a kml file. I’ve built this a couple of times. The .txt file is based off the original offsets.
One option is to save the txt file with the correct chords, lat an long, with heading.
The current version really only needs one point and a heading. Viewing in the kml, you will need three points. The A point, and ref1 and ref2. So, the kml file will draw a line from ref1, to A, to ref2. When you load the abline into AOG, you calculate the heading from ref1 and ref2, then build ABLine normally from A and this heading.
I can see myself wanting to do this often, and while I like seeing only a list of AB lines for each field individually, it would be quite handy to have the ability to load an AB from another field and have AoG do those conversion automatically. With the current version, I will probably position myself with with the 1st field’s AB and then load a new field and create a new line or copy it and just edit/snap it over to my position.
Towards the end of this thread is where I have been working on it. Currently away from computer. When I get back next week, I will post the code to export and import ABLines.
You can also do a “save as” when closing the field and pick and choose what you would like to save.
The reason there is an offset is as KentStuff mentioned. When you make a new field the origin of that field is different so all the offsets to make that field start at 0,0 instead of 6 million meters from the equator are different. Save as works good, especially if the 2 fields are close together.
That’s a good idea. How far away could the two fields be and the Save As option work well? Ours are all within 5 miles. I could save as the same field for each real field, then copy paste ABs as needed.
It is really intended to be used in the same field, and also since it uses local plane, it starts being farther from where it should be in a mile or so.
Kml does not care how far apart they are. However, just curious why you would want an abline reference that is 5 miles away? What are you trying to line up?
It’s not that I’d want to share ABs between fields that far away but I thought if field A is beside B and B beside C and C beside D, and if it would simplify sharing ABs if the neighboring fields use the same local plane then they would all end up on the same local plane. Maybe I’m obsessing over precision here but I thought I could reuse ABs for the boundary between neighboring fields.
Actually the farther you are away from the initial start point of the field, accuracy drops off rapidly, It’s because we dwell on an oblate spheroid (football).
You could just copy the AB heading and make that the same for each field. But don’t use the same field start position for miles. That is the opposite of precision.
Trying to put square fields on a spheroid ball is tough, the reason correction line roads exist.
In order to make it kinda square Surveyors have a value called “projection”. It is the error between the spheroid and the flat area. Over a distance of only 200m the projection factor is 0.99570 at my elevation. 1.0 being perfect square on square measurement. This is why many surveys are done in a Localization of measurements almost true to each other. Canada is still running on NAD83 datum system.
Its only in the recent years that we now have WGS84 and ITRF20XX, for a more global measurement system based off satellite measurements. But it does not eliminate projection.
In Canada most of the survey was done by Chain, Transit, Sextant and Stars. So your roads are not going to always match up to the tractors path either. You have better survey technology in your seeder than the original surveyors had to map the continent.
Just use A+ for headings it makes life much easier.
Here is the link to the program that will import the KML ABLine files. It may open other files but I doubt it.
Currently it simply opens the file regardless of how far away it is, and it keeps the origin point and loads the heading. You must load the file from and existing ABLines.kml. This prorgram writes and reads this file.
Start this program open whatever field you wish. If there is an ABLine when you close the field it will create the ABLines.kml file. This can be loaded with Google Earth if you would like to see it.
Start a different field that has a boundary. Click on the ABDraw button at the bottom of the screen. You will see an import with a folder near the old line function. Click this, navigate to the field folder, click on the ABLines.kml. It will import every line in that field. You may or may not be able to see them in this window. When you go back to the main screen and start an ABLine, you should be running it. I have no idea how far or accurate it will pick up.
This is it in the other hemisphere. I did not do the math to fine out if the distance and how many paths away is accurate. It will not draw the line this far away, but it will drive it.
It seems to me that it would be simpler if I just Save As a new field, and copy over the lines that way, then delete the ones that don’t apply and use those copied lines to create the new neighboring field’s boundary. Otherwise I’d have to create a boundary before being able to use the kml import.
I like to create one big field that contains all the fields. I can easily share the wanted ABLines between the fields. The only reason that you must build a boundary first is because it is inside the ABDraw. This needs a Boundary in order to load. Fairly simple to place this somewhere else.
