[GRASS-user] Is it possible to export a Raster to KML

GRASS GRASS user
1

Greetings
I have a raster mapthat I want to create an overlay in a KML file. Is it possible to do this with GRASS? if not, as anyone as an alternative to use?
Thanks
Kat

2

Hi Katrin,

Yes, it’s possible using the r.out.kml add-on, see [1][2]

[1] http://grass.osgeo.org/wiki/GRASS_AddOns#r.out.kml
[2] http://osgeo-org.1803224.n2.nabble.com/KML-generator-for-GRASS-6-4-td4548193.html

Regards,
Daniel.

On Mon, Oct 24, 2011 at 1:40 PM, katrin eggert <katrineggert1980@gmail.com> wrote:

Greetings
I have a raster mapthat I want to create an overlay in a KML file. Is it possible to do this with GRASS? if not, as anyone as an alternative to use?
Thanks
Kat

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

3

Hello Daniel
By reading the r.out.kml manual I have a few questions:
1- "KML expects data to be in Latitude-Longitude using the WGS84 datum and EGM96 vertical datum. ". My data is in WGS84 UTM 26N. Does this mean that I have to create a new location with this information or it is ok to use a Location in this Geofraphic projection/coordinates system?
THanks
Kat

2011/10/24 daniel mcinerney <daniel.o.mcinerney@gmail.com>

Hi Katrin,

Yes, it’s possible using the r.out.kml add-on, see [1][2]

[1] http://grass.osgeo.org/wiki/GRASS_AddOns#r.out.kml
[2] http://osgeo-org.1803224.n2.nabble.com/KML-generator-for-GRASS-6-4-td4548193.html

Regards,
Daniel.

On Mon, Oct 24, 2011 at 1:40 PM, katrin eggert <katrineggert1980@gmail.com> wrote:

Greetings
I have a raster mapthat I want to create an overlay in a KML file. Is it possible to do this with GRASS? if not, as anyone as an alternative to use?
Thanks
Kat

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

4

On Tue, Oct 25, 2011 at 6:32 PM, katrin eggert
<katrineggert1980@gmail.com> wrote:

Hello Daniel
By reading the r.out.kml manual I have a few questions:
1- "KML expects data to be in Latitude-Longitude using the WGS84 datum and
EGM96 vertical datum. ".

(see also
http://en.wikipedia.org/wiki/Keyhole_Markup_Language#Geodetic_reference_systems_in_KML
)

My data is in WGS84 UTM 26N. Does this mean that I
have to create a new location with this information

Yes. you have to reproject the maps.

Markus

5

Hi
Maybe it would be better to explain that in manual entry. Just one more question: what is the EPSG code for that projection?
Thanks
Kat

2011/10/26 Markus Neteler <neteler@osgeo.org>

On Tue, Oct 25, 2011 at 6:32 PM, katrin eggert
<katrineggert1980@gmail.com> wrote:

Hello Daniel
By reading the r.out.kml manual I have a few questions:
1- "KML expects data to be in Latitude-Longitude using the WGS84 datum and
EGM96 vertical datum. ".

(see also
http://en.wikipedia.org/wiki/Keyhole_Markup_Language#Geodetic_reference_systems_in_KML
)

My data is in WGS84 UTM 26N. Does this mean that I
have to create a new location with this information

Yes. you have to reproject the maps.

Markus

6

katrin eggert wrote:

Hi
Maybe it would be better to explain that in manual entry. Just one more
question: what is the EPSG code for that projection?

http://www.google.com/search?q=google+kml+epsg
-> 4326

Thanks
Kat

2011/10/26 Markus Neteler <neteler@osgeo.org>

On Tue, Oct 25, 2011 at 6:32 PM, katrin eggert
<katrineggert1980@gmail.com> wrote:
> Hello Daniel
> By reading the r.out.kml manual I have a few questions:
> 1- "KML expects data to be in Latitude-Longitude using the WGS84 datum
> and
> EGM96 vertical datum. ".

(see also

http://en.wikipedia.org/wiki/Keyhole_Markup_Language#Geodetic_reference_systems_in_KML
)

> My data is in WGS84 UTM 26N. Does this mean that I
> have to create a new location with this information

Yes. you have to reproject the maps.

Markus

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

7

Hi
Thanks for all the feedbacks
I have used it and It’s ok but…
THe results are not much different if I use my data in WGS84UTM and reprojecting to EPSG:4326. Just a slightly difference. Is this expectable such a slightyly difference? (I’m not an expert in Geo Reference Systems)
Thanks

2011/10/26 Markus Metz <markus.metz.giswork@googlemail.com>

katrin eggert wrote:

Hi
Maybe it would be better to explain that in manual entry. Just one more
question: what is the EPSG code for that projection?

http://www.google.com/search?q=google+kml+epsg
→ 4326

Thanks
Kat

2011/10/26 Markus Neteler <neteler@osgeo.org>

On Tue, Oct 25, 2011 at 6:32 PM, katrin eggert
<katrineggert1980@gmail.com> wrote:

Hello Daniel
By reading the r.out.kml manual I have a few questions:
1- "KML expects data to be in Latitude-Longitude using the WGS84 datum
and
EGM96 vertical datum. ".

(see also

http://en.wikipedia.org/wiki/Keyhole_Markup_Language#Geodetic_reference_systems_in_KML
)

My data is in WGS84 UTM 26N. Does this mean that I
have to create a new location with this information

Yes. you have to reproject the maps.

Markus

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

8

On Wed, Oct 26, 2011 at 11:35 AM, Markus Metz
<markus.metz.giswork@googlemail.com> wrote:

katrin eggert wrote:

Hi
Maybe it would be better to explain that in manual entry. Just one more
question: what is the EPSG code for that projection?

http://www.google.com/search?q=google+kml+epsg
-> 4326

Note that KML expects data to be in Latitude-Longitude using
the WGS84 datum and EGM96 vertical datum as the manual
says. This is not exactly EPSG:4326.

I have added a map with geoid undulations in Trentino, Italy
here:
http://grass.osgeo.org/wiki/Global_datasets#EGM2008_Geoid_Data

Markus

9

Hi
I’m Sorry but I’m lost in this…
So the email that you sent and those links in google point to use EPSG:4326 but the script requires a different one ? That doesn’t make any sense…
If I define a Location with that geoid map that you sent me, will I have what? EPSG:4326 or the one used by r.out.kml?
Thanks
Kat

http://www.google.com/search?q=google+kml+epsg

→ 4326

Note that KML expects data to be in Latitude-Longitude using
the WGS84 datum and EGM96 vertical datum as the manual
says. This is not exactly EPSG:4326.

I have added a map with geoid undulations in Trentino, Italy
here:
http://grass.osgeo.org/wiki/Global_datasets#EGM2008_Geoid_Data

Markus

10

Hi
I'm Sorry but I'm lost in this...
So the email that you sent and those links in google point to use EPSG:4326

but the script requires a >different one ? That doesn't make any sense...

If I define a Location with that geoid map that you sent me, will I have

what? EPSG:4326 or the one used >by r.out.kml?

Thanks
Kat

http://www.google.com/search?q=google+kml+epsg

   > -> 4326

see also here:
http://www.gdal.org/ogr/drv_kml.html

as far as i understand the ogc-kml-manual
(http://www.opengeospatial.org/standards/kml , => 2.2.0 OGC KML), the
Latitude-Longitude are in EPSG:4326, but measuring the height/elevation in
google earth is in EGM96 vertical datum and not in EPSG:4326.

in my experience overlaying kml (vector and raster) with EPSG:4326 in google
earth works relatively well in flat areas, in mountain areas there are
sometime distortions therefore.

HTH
Helmut

--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/Is-it-possible-to-export-a-Raster-to-KML-tp6924758p6939523.html
Sent from the Grass - Users mailing list archive at Nabble.com.

11

On Fri, Oct 28, 2011 at 12:01 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
...

in my experience overlaying kml (vector and raster) with EPSG:4326 in google
earth works relatively well in flat areas, in mountain areas there are
sometime distortions therefore.

I can confirm this from my (limited) experience to export data
to KML. To correct for the geoid heights, you could use the previously
indicated map and calculate the local ellipsoid-geoid difference
and vertically shift your vector data with v.transform. Then export
to KML. For raster, use r.mapcalc to shift.

Markus

12

On Fri, Oct 28, 2011 at 12:01 PM, Helmut Kudrnovsky <[hidden email]> wrote:
...

in my experience overlaying kml (vector and raster) with EPSG:4326 in
google
earth works relatively well in flat areas, in mountain areas there are
sometime distortions therefore.

I can confirm this from my (limited) experience to export data
to KML. To correct for the geoid heights, you could use the previously
indicated map and calculate the local ellipsoid-geoid difference
and vertically shift your vector data with v.transform. Then export
to KML. For raster, use r.mapcalc to shift.

for some additional information
see http://www.epsg-registry.org/ => retrieve by code:

EPSG: 4326 => GeodeticCRS (geographic 2D) [WGS 84] => 2D
EPSG: 4978 => GeodeticCRS (geocentric) [WGS 84] => 3D

Helmut

--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/Is-it-possible-to-export-a-Raster-to-KML-tp6924758p6939578.html
Sent from the Grass - Users mailing list archive at Nabble.com.

13

Helmut wrote:

...
> in my experience overlaying kml (vector and raster)
> with EPSG:4326 in google
> earth works relatively well in flat areas, in mountain
> areas there are
> sometime distortions therefore.

Markus:

I can confirm this from my (limited) experience to export
data to KML. To correct for the geoid heights, you could use
the previously indicated map and calculate the local
ellipsoid-geoid difference and vertically shift your vector
data with v.transform.
Then export to KML. For raster, use r.mapcalc to shift.

n.b., IIUC raster KML support in google earth is essentially a
hack building on/abusing their raster-icon support.
they may have improved things, but this is what I was lead to
believe at the time of writing r.out.kml.

probably it is useful to consider if the ellipsoid-geoid
difference is important vs. the overall vertical differences
in the data, if the result is just for viewing maybe it is not
worth the trouble.

Hamish

14

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.

Would it be possible for you to share some data where you have seen that this is a problem?

Thanks,

Roger

On Fri, Oct 28, 2011 at 1:05 PM, Hamish <hamish_b@yahoo.com> wrote:

Helmut wrote:

…

in my experience overlaying kml (vector and raster)
with EPSG:4326 in google
earth works relatively well in flat areas, in mountain
areas there are
sometime distortions therefore.
Markus:
I can confirm this from my (limited) experience to export
data to KML. To correct for the geoid heights, you could use
the previously indicated map and calculate the local
ellipsoid-geoid difference and vertically shift your vector
data with v.transform.
Then export to KML. For raster, use r.mapcalc to shift.

n.b., IIUC raster KML support in google earth is essentially a
hack building on/abusing their raster-icon support.
they may have improved things, but this is what I was lead to
believe at the time of writing r.out.kml.

probably it is useful to consider if the ellipsoid-geoid
difference is important vs. the overall vertical differences
in the data, if the result is just for viewing maybe it is not
worth the trouble.

Hamish

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

15

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.

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.

  • Jamie

On Fri, Oct 28, 2011 at 2:06 PM, Roger André <randre@gmail.com> wrote:

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.

Would it be possible for you to share some data where you have seen that this is a problem?

Thanks,

Roger

On Fri, Oct 28, 2011 at 1:05 PM, Hamish <hamish_b@yahoo.com> wrote:

Helmut wrote:

…

in my experience overlaying kml (vector and raster)
with EPSG:4326 in google
earth works relatively well in flat areas, in mountain
areas there are
sometime distortions therefore.
Markus:
I can confirm this from my (limited) experience to export
data to KML. To correct for the geoid heights, you could use
the previously indicated map and calculate the local
ellipsoid-geoid difference and vertically shift your vector
data with v.transform.
Then export to KML. For raster, use r.mapcalc to shift.

n.b., IIUC raster KML support in google earth is essentially a
hack building on/abusing their raster-icon support.
they may have improved things, but this is what I was lead to
believe at the time of writing r.out.kml.

probably it is useful to consider if the ellipsoid-geoid
difference is important vs. the overall vertical differences
in the data, if the result is just for viewing maybe it is not
worth the trouble.

Hamish

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

16

On Sat, Oct 29, 2011 at 12:08 AM, Jamie Adams <jaadfoo@gmail.com> wrote:

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.

I had such problems in the past with 3D buildings which where flying
over the ground... the data where in the Alps.

Markus