KML Polygon shift

Hi Folks,

I have an issue that doesn’t really need to be resolved, but my ADHD says I must resolve it. Does any one know how to shift the location of a polygon (field boundary) in a KML file?

Here is the back story…

I have a base/rover setup. When I set up my base, I use the post processing method, where you record your gps data for 24 hrs, send it in to be processed, and you’ll receive a precise point of your antenna to a few millimeters.

Well, turns out that my ‘exact’ location is roughly 15 feet off towards the south west. I made the mistake of trusting that data, without checking it… SO I proceeded to map all of the roughly 286 fields that I have. This took a week and roughly 3 tanks of fuel…

Here is my mulit-level-non-issue issues.

  1. When I open the KML file, it is clearly about 15ft off of the google maps overlay.
  2. Before I receive an RTK fix, and if I am driving close to the boundry, it is clear on agopen that I am not where I am supposed to be. Either outside the boundry or another pass width inside the field.

Obviously once I have an RTK Fix, everything is fine. It would be nice to not have to use RTK and an internet connection to do certain tasks, but with this much discrepancy, that is not achievable. I do now have access to a friend with a trimble survey rod, and would be able to get a reference with his system to get a more accurate location for my antenna location.

Any help would be appreciated, I’d rather spend another week adjusting the files, on my laptop, than spend the time and money remapping all of the fields once the base location has been fixed.

I’m afraid that if you would shift your positions to the real position of that day, you’d have to do that again when you come back a few days later, if you don’t use RTK.
Wikipedia says:

The accuracy of the resulting range measurement is essentially a function of the ability of the receiver’s electronics to accurately process signals from the satellite, and additional error sources such as non-mitigated ionospheric and tropospheric delays, multipath, satellite clock and ephemeris errors, etc

That means without RTK your indicated position won’t be repeatable after some time.

I understand the principals of RTK. I am using RKT. My permanent RTK reference station was set to the wrong point before creating my fields with RTK. Without RTK i should still be within 1.5 meters using an f9p. However,
I am repeatedly about 15ft to the SW. Every day, until I have an rtk fix. Also the kml file overlapped on to google earth pro shows a discrepency of about 15ft to the southwest.

I would like to set my reference station to the proper lat and long. Doing so would mean that my field files would be off by however much my reference station moves.

I’d like to digitally edit my field files without having to physically remap them all once my reference station is set to its actual lat and long.

I hope that makes sense.

1 Like

As I understand it, you need to convert gps coordinates to Cartesian. After shifting all of them, shift them by dx and dy, possibly by dz(dH). Then transfer back.

More or less obvious but one would expect a simple tool for the task, is there any free application?

Yes, I was hoping there was a simple solution to this, I’m going to look in to how complicated the Cartesian conversion process would be.

I’d even be willing to pay for some kind of tool to do this if need be.

This gets complicated.

Start reading the Emlid forum and research Datums.

So when you PPP’ed your base, most likely to WGS84, there is a time element the “epoch” that transforms measurements taken in WGS84 at different times. So you are locked in now…. But google earth keeps moving. Your measurements will get worse compared to googles just because of continental drift over time. Very small error indeed, but it will be there.

Also google uses a web mercator to project its data of the earth and line up the imagery. The further you are from the centre of the imaginary zero line the greater the error in lining up the imagery. Google maps uses espg:3857, this is what is most likely causing the big gap.

So then if you want to sync up with a trimble rtx user, you need a base that thinks its in 2005 to match wgs84 coordinates. But the Trimble rovers will auto transform to the current epochs measurements.

Now your wondering so if wgs84 moving how do I have year to year repeatability? Both your locked in base and rover are riding the same plate so the shift is cancelled out. But if you PPP again you will get new base coordinates and a shift because WGS is referenced to an ellipsoid not the plate.

So how do they keep track of property lines? Using localizations, datums that are referenced to a geoid and a fixed point on a plate like NAD83. All measurements in this system ride the same plate so they never change coordinates.

There is software to do transformations but its usually costly. If you wonder why Survey leads go to University this is the headache that awaits them.

1 Like

Google earth overlay will be off as @PotatoFarmer described.

There is option to take base cord from google earth and use them in base then you can use google earth as overlay and don’t have to physically go to field. But losing RTK will result in jump. This is more for new users that don’t have field cord.

If you use PPP cord base station when you lose corrections then single GPS will not jump only decrease accuracy of line. (it will jump how much continent moves per year x years from PPP epoch) fixing that problem.

You could move physically base station to that position and then its good.

1 Like

Hi
You can try the offset fix:

If this dont work or the changes are not permanent you can try this:
You can try to change the initial coordinate in the field.txt in each field.
I don’t if you must change the convergence and/or StartFix or if you also have to change the $Offsets

To be checked in the source code!

1 Like

Can you please post one of yur kml files (just add .txt to end) and say exactly how far EW and NS are?

Well that works pretty well… Added the offset to the northing and easting as it converts back to Latitude and Longitude. Offset resets for every field, but it is pretty easy to add offsets. This field is offset 5 meters north and 6 meters west.

I will make the changes in AOG and it can be added to the latest branch. There are a bunch of other changes as well.

3 Likes

Hi Brian, thanks for the reply. Field elsc 102.txt.kml (14.9 KB)

Here is a sample “field” with some more data. So, I’m using your program as more of a navigation device than anything else. I use it for snow removal on wind turbine access roads (in lieu of snow stakes). Your program allows me to see the edges of the laneway in relation to my snow plow. It works amazing, so thank-you!

In regards to the field file I added, if you look at where the laneway meets the public road, it gives you a pretty good image as to how far off it is. I placed a pin at the corner of the laneway on the image (pin 1), and at the corner of the field boundary polygon (pin 2) using google earth.

Pin 1
42°26’45.75"N
82°23’44.47"W

Pin 2
42°26’45.88"N
82°23’44.04"W

The maps need to move roughly 9.4 meters west and 3.25 meters east (a little further off than the 15ft I originally thought).

So does shifting the gps position shift the field, or your antenna location?

Would the offset be saved if the field is saved? A permanent offset fix would be nice, instead of entering the offset every time a field is opened.

Update: after messing around with measurements and google earth for hours, my antenna needs to move exactly 771cm west and 155cm south to be where its supposed to be to line up with google maps. I have checked a handfull of random ‘fields’ at all corners of my zone, and this works out on all of them.

So is the best way about this to move my antenna coords in uCenter, and just punch in the offset fix with every field?

If I do this, the field boundaries still do not show that they have moved in google earth. Brian, I am not quite sure how you got your boundary to move like in your attached picture.

Please post the result file.

I may have programmed it to do that :slight_smile: Works well, Almost ready to do a release and then you can change them all - easier then redriving them again. All you have to do is check the box, put in the distance you want it to move the kml, open the field, close the field and it will save with the new position.

Field.kml (14.9 KB)

The keep offset allows you to not have to enter it again for every field as normally when you close a field it goes to zero. The danger is if you don’t want to move the kml - make sure it is zero.

2 Likes

Brian this is absolutely amazing. I can not wait to get this implemented and get these files moved over so that everything is synced up the way I want it to be!

Cool. I will post the release soon.

1 Like

The offset of coordinates to each point is the same. True, in the new file one extra coordinate appeared from somewhere. (10)
Книга1.xlsx (35.2 КБ)

Well yes all points are shifted by the same amount northing and easting. This is 10m north and 3m west.

Don’t know about the extra point or what that is.