I’ve been working with Brian Flood to determine how and why the data won’t line up in Google Earth when exported out of ArcGIS into a KML/KMZ file. Brian figured out the following:
there definitely seems to be a shift in GE’s aerials in some places (e.g. none in NJ, mild in Nevada, somewhat severe in your area). However, it looks like the WGS cords returned by GE are correct, so its overlaying your data correctly, its just its other base data is slightly shifted. I suspect this is QA/QC issue for GEFor the next build, I added a xy shift variable that can be controlled by the user, essentially making up for the GE base data errors.
Not a great story but if GE is used purely as a viewer it works. I also will mark the KML with comments so the shift can be undone at a later date (or simply re-exported)
This isn’t good/bad news really as one can manually adjust the x/y shift, but it adds a step to the export that shouldn’t be there and this is compounded by the fact that the shift isn’t constant across the globe. At least now we know what the issue is and hopefully all ArcMap to KML extensions will add the ability to adjust the x/y shift soon.


11 responses so far ↓
1
Phillip Holmstrand
// Sep 29, 2005 at 12:16 pm
I’d agree with Brian in that it must be localized to certain areas. In Portland our data lines up perfectly. You can see it especially when viewing our “Property” theme, buildings and taxlots look line-up great with the aerial photos from GE.
I’m sure if you post something on the GE forums about it the Google guys will get it fixed…
2
James Fee
// Sep 29, 2005 at 2:29 pm
It is very localized because many of our clients don’t seem to have this problem. What concerns me is that it isn’t consistent so it adds an element of uncertainty to using the GIS export tools.
3
Mike Davis
// Sep 29, 2005 at 4:42 pm
I wonder if this could be an issue with the geo-registration of the underlying imagery instead of an xy shift in the data.
Since there isn’t really any detail on the source and methods used to reference each image it is kind of a crap-shoot. Some imagery might be georectified, some georegistered and some might have been “fudged” to look right.
Gift horse - Mouth.
4
James Fee
// Sep 29, 2005 at 4:45 pm
I’m pretty sure that its not my data as the buildings are surveyed in. I’ve also compared lat/long coords out of the GIS and out of GE and they match up. Its just the satellite image that is off.
But this all brings us back to Google holding this info behind their firewall and we are left to assumptions on how its rectified. I’ve bought data from almost every satellite vendor and I’ve never had problems with their stuff lining up with my own. I can only assume it is a problem with Google Earth itself and not the imagery.
What is weird about all this in addition to it being localized is that the roads in Google Earth line up with my roads.
5
Mike Davis
// Sep 29, 2005 at 4:58 pm
While most of the satellite imagery we’ve used is pretty good, I do recall a visit by a certain recently-purchased provider to collect ground control points. A big white “X” was laid out and the center of the “X” was collected using… a hand held e-trex.
Now maybee they had a whole network of points I don’t know about, but it seemed kind of strange to me.
6
James Fee
// Sep 29, 2005 at 9:59 pm
I’m leaning to this just being a quality control issue. Usually one doesn’t have to worry about so much data over such a large area. Maybe some us it just hasn’t been QA/QC’d yet. Cities such as Portland are right on, while Military Reservations that I work with that are in the middle of nowhere aren’t as accurate.
Hopefully this can be corrected.
7
Chris Tweedie
// Sep 29, 2005 at 11:35 pm
Any example screen shots guys? I’m interested to see how far it is out by
8
Matt Perry
// Sep 30, 2005 at 12:36 am
So GE base data is not accurate. I suspected as much. The areas I work in seem to be OK but I’ve seen some cases where it’s WAY off.
But is the solution really to fudge to KML data to line up with the poorly-georeferenced base map? That seems like a real amateur hack to me. 6 months down the road when Google fixes their base imagery, we’re going to be left with thousands of KML vector datasets with inaccurate coordinates and no metadata!
To anyone writing a KML converter… For the love of god do not intentionally create inaccurate data!! It is an ethical abomination.
I say ALWAYS (ALWAYS ALWAYS ALWAYS!) create spatially accurate data. If the base imagery is off then FIX THE BASE IMAGERY.
Google needs to get serious about data quality and metadata if the geospatial world is to trust them.
9
James Fee
// Sep 30, 2005 at 6:58 am
Chris, check out this link.
http://www.spatiallyadjusted.com/media/images/2005/structure_height.html
10
Andrew Hallam
// Oct 11, 2005 at 6:09 am
Here are two examples of the data shift from the east coast of Australia. Both images are about 70KB each.
Example 1
Example 2
11
rkgeorge
// Jan 17, 2006 at 1:18 pm
Is it possible the shift is deliberate to make direct access to the google image stacks less useful?
If the shift pattern is random in time as well as spatially that might be a clue, although a grid shift wouldn’t have to be time variable to be an effective discouragement to unauthorized use.
Leave a Comment