Here it is with the tool width shown. It actually is drawn the correct tool width. I’ve made it a bit transparent and added a crop to line when we get a little further toward background images. The files all have a time stamp and can be loaded and turned on at your pleasure. So you can show multiple days on the same field or multiple fields in the same screen.
This shows two different fields. The funny shaped one was created in AOG by driving and making a boundary. That is why it is so crooked. The retangular one on the left was drawn in google earth, imported into AOG as a new field. Each one was driven in the simulator and then the kml file for each was loaded into google earth. While back in google earth, I measured the offset distance from AOG boundary and Google earth polygon. Looks like about a meter. Probably in the rounding. The red cut lines are now bigger so when we start importing backgrounds into AOG, you will not “fall off” the world. Again, the green is auto tool, the yellow is manual tool, and the blue is just driving around. If you trace them you can see they both start in the same point and the field on the left was driven too over the field on the right. Of course you could not see the field on the right in AOG. At least not yet…
If you are interested, Here are the KML files for both fields. Just edit the names to drop the “.txt”.
Notice how small the files are. Again, I have no idea how big a kml file can be, but these work well. You can turn each item on and off in the window to the left. Pretty cool stuff.
AOGkml-20191215102709.kml.txt (87.5 KB)
AOGkml-20191215114824.kml.txt (77.6 KB)
At least not yet… Update: It do now!!!
Here is how it works. You close a field and then open the kml file in Google earth. There is a fine red line drawn around the whole area. This is the crop line. The view must be set to straight up and north. Edit-Copy image. Open Paint.net. Ctrl-V(Paste) Crop to red line. Save as Background.jpg. That is important. It must be Background.jpg. It must be in the Field directory. Then open AOG. Click the Background button. Window opens. Click Load, Click Save. There you go. It now has a background that is the same as google earth. Be careful cropping. Be careful making the view straight up and north. It was spot on - boundary to boundary.
Edit: You can draw anything you want in the paint edit while you are there. It will all show up in the field.
Very cool KentStuff. This was on my wish list too! In regards to Farmergps, the data that comes out of there is in the same format that I used a good 20 years ago while working for my county. They had a program called County Asset Management System(CAMS). It recorded ground speed wind direction/speed, temp, and boom states. Both Farmergps and the CAMS were able to easily export data to kml of shapes with ease. Maybe there is a reason they use that format? I am not sure if that helps anyone here, but it may… I am still getting used to discourse and catching up:)
Oops I posted this on the wrong thread.
These two threads are kinda merging to the same point.
Probably should have the background stuff in a different post.
Back to the project at hand. Thanks to Brian, AOG-out lines up perfectly with GE.
I added a Total Job Path that shows everywhere you have driven. If you select any of the paths to the left and right click, it will show the elevation profile along the line. Or at least what GE says it is.
This shows it in the Google Earth Web Page.
Your idea is coming to fruition…
I see you, as always, bring it one step to the better. I noticed that each section of the tool is independent. I like!!!
Yes, each patch by itself. There is no real line saved to show where the vehicle has driven, so that is not there. Contour isn’t recorded all the time either.
KML generated works well in QGIS as well.
Well it’s not nearly of importance as to where you have been driving as to where you have been working. I’ll be interested in how you recorded and re-wrote to kml.
I’m glad to see the kml stuff coming together from other forms of software. Some of us draw or work regularly in other programs. Nice to be able to import and edit or other calculations, including printing.
This time around I’m taking the time to learn the xmlWriter class. Rather then manual creation of printing the lines and figuring out the tags the xml writer indents and creates the tags, like so:
kml.WriteStartElement("Placemark");
kml.WriteElementString("visibility", "0");
kml.WriteElementString("name", ABLine.lineArr[i].Name);
kml.WriteStartElement("Style");
kml.WriteStartElement("LineStyle");
kml.WriteElementString("color", "ff0000ff");
kml.WriteElementString("width", "2");
kml.WriteEndElement(); // <LineStyle>
kml.WriteEndElement(); //Style
kml.WriteStartElement("LineString");
kml.WriteElementString("tessellate", "1");
kml.WriteStartElement("coordinates");
linePts = GetUTMToLatLon(ABLine.lineArr[i].ref1.easting, ABLine.lineArr[i].ref1.northing);
linePts += GetUTMToLatLon(ABLine.lineArr[i].ref2.easting, ABLine.lineArr[i].ref2.northing);
kml.WriteRaw(linePts);
kml.WriteEndElement(); // <coordinates>
kml.WriteEndElement(); // <LineString>
kml.WriteEndElement(); // <Placemark>
This creates an ABLine right from the coordinates in the file and so all you have to do is make sure there is an end element for every start element. As the kml gets big, this is really important as doing it manually with loops would make the program function quite hard to read and huge.
Very cool. I never even thought about adding the ABLines. Looks much simpler to code and read the code afterward. I did not know there was an xmlWriter class. I’ll have to look into that. Thanks, back to school again. Nice work.
Oh, but I need the line where the vehichle has driven so that I can drive in the same tracks again and again with different tools using assisted steering.
That is what AOG does. Save the AB Lines and re open next time.
Sometimes I need to leave the AB-lines for wet spots and other issues driving a custom pattern. I whould like to se that custom pattern next time I drive because the plants have recovered from the tractor wheels and the physical tracks are almost not visible anymore.
You would need to either record the entire path, or import the kml file and then convert it back to a recorded path. If I’m not mistaking, @BrianTee_Admin, the kml file is where the section was and the recorded path is where the pivot point was. If that is the case, the recorded path would be a better option.
Now I am a bit confused. Kent, you show some screenshots with green and yellow and blue color which is kind of the thing I am looking for. Some of the later screenshots even have applied areas. Is that just something you have played with in a local copy of the code, or is it something which can be found in the master branch? These kind of kml-files would be very nice to upload to farmos, or use in jupyter-notebooks for farm management.