Roger is correct. GE will just drape your raster data over it's terrain mesh regardless of what vertical parameters your data has. It is essentially 2D with a z value and is interpreted as such. That is why EPSG:4326 works, because GE doesn't care about any other information. No conversions/shifts occur.<div>
<br></div><div>I export rasters from GRASS, generate hillshades, and overlay in GE using gdal2tiles daily. I seldom see any alignment issues, and when I do it is usually my data. Of course there are alignment issues in GE, but they will vary place to place regardless of topography. </div>
<div><br></div><div>- Jamie<br><br><div class="gmail_quote">On Fri, Oct 28, 2011 at 2:06 PM, Roger André <span dir="ltr"><<a href="mailto:randre@gmail.com">randre@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I find this thread interesting. In my experience overlaying both raster (orthophoto) and vector data in Google Earth with KML, EPSG:4326 has worked with no problems whatsoever. So far as I know, GE does not apply a vertical datum, it simply drapes the 2D data over its internal terrain model.<div>
<br></div><div>Would it be possible for you to share some data where you have seen that this is a problem?</div><div><br></div><div>Thanks,</div><div><br></div><font color="#888888"><div>Roger</div></font><div><div></div>
<div class="h5"><div><br><br><div class="gmail_quote">On Fri, Oct 28, 2011 at 1:05 PM, Hamish <span dir="ltr"><<a href="mailto:hamish_b@yahoo.com" target="_blank">hamish_b@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Helmut wrote:<br>
> ...<br>
> > in my experience overlaying kml (vector and raster)<br>
> > with EPSG:4326 in google<br>
> > earth works relatively well in flat areas, in mountain<br>
> > areas there are<br>
> > sometime distortions therefore.<br>
Markus:<br>
> I can confirm this from my (limited) experience to export<br>
> data to KML. To correct for the geoid heights, you could use<br>
> the previously indicated map and calculate the local<br>
> ellipsoid-geoid difference and vertically shift your vector<br>
> data with v.transform.<br>
> Then export to KML. For raster, use r.mapcalc to shift.<br>
<br>
n.b., IIUC raster KML support in google earth is essentially a<br>
hack building on/abusing their raster-icon support.<br>
they may have improved things, but this is what I was lead to<br>
believe at the time of writing r.out.kml.<br>
<br>
probably it is useful to consider if the ellipsoid-geoid<br>
difference is important vs. the overall vertical differences<br>
in the data, if the result is just for viewing maybe it is not<br>
worth the trouble.<br>
<font color="#888888"><br>
<br>
Hamish<br>
_______________________________________________<br>
grass-user mailing list<br>
<a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
</font></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
grass-user mailing list<br>
<a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-user</a><br>
<br></blockquote></div><br></div>