Maybe not a Feature Request. But…
Playing around with showing application path in Google Earth. Some success. This stores a point as it paints. Then saves it to KML when the job closes. Fairly long KML file. I have no idea how long of a file Google earth can take. Resets file when new job is started. Something is not quite right with the color and width, but it still loads.
DrivePath.kml.txt (17.1 KB)
I got the orange line working. I had a space in the ID. Here it is with the flags.
Edit: And here it is with running curves with Line. It connects the two right now. It needs a list of list in order to break it up.
You might like seeing how Johannes Heupel did it with FarmerGPS. Unfortunately it’s not open source but even with a trial you can play around with it to see how import/export works in his program. http://farmergps.com/download.htm
I will look into to the farmerGPS and see about it.
Made another step forward with the KML Applied area. Now it shows
Green - Auto tool
Yellow - Manual tool
Blue - Just Driving Around
In the screen shots below, in the google earth, in the left panel, you can see that each of the lines can be turned on or off. Pretty cool stuff. I don’t know if it is useful or not but it is fun to see on the field. Could be turned different colors for most anything.
autoManualDrive.kml.txt (35.4 KB)
This is exactly why I started AgOpenGPS, inspiring creative minds to try new things, learn about all these different areas, and just have fun with it. Awesome job!
I’ve not downloaded it yet, but just looking at the screen shots, Brian has nothing to be ashamed of and can hold his head high.
Just to make sure we say it often, thank you Brian and others. Job well done!!!
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.