KML: 3D export appears 2D

[neteler]

Frank,

I am using GRASS' v.out.ogr to export to KML (before that I have extruded 2D polygons to 3D with v.extrude and height= parameter, in NVIZ they are 3D blocks). However, the resulting view in Google Earth is 2D buildings.

Hacking manually in <altitudeMode>absolute</altitudeMode> into each <Polygon> tag, I achieve 3D view. Is it possible that <altitudeMode> is lacking in the KML driver?

Secondly, the exported 3D blocks are flying over the terrain, probably a WGS84 vs. sphere (or whatever GE uses!) problem. But the distance 3D block to terrain looks similar to the height of the block itself.

Attached two screenshots.

Best regards, Markus

[neteler]

KML file in questions (exported with v.out.ogr, manually alt tag added)

[neteler]

GE screenshot 1

[neteler]

GE screenshot 2

[neteler]

Just found the info that GE uses WGS84 (like me):  http://earth.google.com/userguide/v4/ug_importdata.html#datum

I have no explanation why the buildings "fly". KML attached, too.

Best regards, Markus

[warmerdam]

Mateusz,

Could you look into this? I've also cc:ed Christopher Condit in case he would like to make improvements related to this report. If the fix is a new feature to optionally set absolute mode, I think we ought to limit the changes to 1.5.0 instead of putting new features into 1.4 branch.

[neteler]

Dear all,

I have made another test in GRASS with VTK export (v.out.vtk/r.out.vtk/paraview, all independent from OGR). The buildings also "fly" here which indicates a bug in the 3D extrusion of GRASS. So I would reduce this report to the initial problem, the <altitudeMode> tag.

Markus

[mloskot]

Markus wrote:

Is it possible that <altitudeMode> is lacking in the KML driver?

Markus, I've checked this aspect of the KML driver now and I confirm, the driver does not support altitudeMode tag. None, the KML feature factory or KML geometry writer does not do anything with this tag.

I'd assume the driver is incomplete or perhaps the altitudeMode tag is a new feature in the KML or something like that.

Christopher, Could you put a little light on it? I can fix it, but first I'd prefer to get some feedback from you as the KML driver author.

[condit]

Replying to mloskot:

Markus wrote:

Is it possible that <altitudeMode> is lacking in the KML driver?

Markus, I've checked this aspect of the KML driver now and I confirm, the driver does not support altitudeMode tag. None, the KML feature factory or KML geometry writer does not do anything with this tag. I'd assume the driver is incomplete or perhaps the altitudeMode tag is a new feature in the KML or something like that. Christopher, Could you put a little light on it? I can fix it, but first I'd prefer to get some feedback from you as the KML driver author.

There are a couple of things going on here: *) We've never tested the KML driver with 3D geometries at all so this result is not unexpected.

*) Grass is generating a new geometry for each face of the structures. So in the case of structure "cat: 51", the KML model is actually composed of 5 placemarks (and the last is actually labeled "cat:52"): one for each surface of the building. I think the preferred way to handle this construct would be something like this: <Placemark><description><![CDATA[<b>cat:</b> <i>51</i><br />]]></description> <Polygon><extrude>1</extrude><altitudeMode>relativeToGround</altitudeMode> <outerBoundaryIs><LinearRing?><coordinates> -78.677254276435079,35.738111228550352,20 -78.676868644576928,35.738110755215992,20 -78.67686874959719,35.737983168468233,20 -78.677254515635653,35.737983642159556,20 -78.677254276435079,35.738111228550352,20</coordinates> </LinearRing></outerBoundaryIs></Polygon></Placemark>

This polygon represents just the top of the structure. Because extrude is set to true, GE handles rendering all the sides and anchors them to the ground. So this is a grass issue.

*)As for the absolute elevation issue, this seems to be strictly a difference between the base DEM used by your grass project and the base DEM used by GE. Consider "cat: 52". GE believes that the surface elevation here is 363ft (roughly 110 meters). But the base of the polygon is set at 126 meters. This causes the buildings to float in when the altitudeMode is absolute.

Having detailed the issues, I'm not sure of the best way to handle them. We'll never know programatically if an elevation is absolute or relative, so perhaps this should be added as a creation option, which will address this problem for now. And polygons being generated for each face of a structure: this will happen when converting from any format representing 3d structures this way. If the elevations were closer to GEs, with the absolute flag set, it would have worked. At the very least, each face should become part of a multigeometry object in KML, s.t. it renders as a single feature.

[condit]

I haven't got GRASS. I imagine that other formats will result in the same problem. If someone could attach a shapefile exported from grass (or some such) I'd be happy to take a look at this problem...

[neteler]

3D Polygons SHAPE of the same 3D vectors exported from GRASS with v.out.ogr

[neteler]

I have uploaded a 3D shapefile exported from GRASS to trac.

[condit]

Hi Markus- I'm getting a tape blocksize error when I try to untar this. Could you try and upload again? Thanks, -Chris

Replying to neteler:

I have uploaded a 3D shapefile exported from GRASS to trac.

[neteler]

Hi Chris,

I have downloaded it from trac to another machine and could untar it without problems. I can email you the individual files of course.

Markus

[condit]

Hi Markus- I've tried with 7zip on win32 and tar -zxvf on an old Redhat machine and couldn't get it to work. Perhaps a zip? My email is: condit@… If you send a zip please rename to .zim or some such as the mailserver here seems to never deliver them... Thanks, -Chris

Replying to neteler:

Hi Chris, I have downloaded it from trac to another machine and could untar it without problems. I can email you the individual files of course. Markus

[neteler]

Hi Chris,

did you actually *click* on above link? Only then you see the real "raw data format" download links. In any case: I have sent it to you as ZIP.

Markus

[condit]

I've added an AltitudeMode? option to the KML driver that will allow the user to specify the desired AltitudeMode?. I'm attaching a patch against the gdal141 branch which I think will close this defect.

[neteler]

Same patch against SVN HEAD

[neteler]

I have ported the patch to SVN HEAD, but no luck yet (maybe my fault):

# reproject from NC State Plane to LatLong?, do KML: ogr2ogr -f KML -dsco AltitudeMode?=absolute -t_srs "EPSG:4326" poi_names_wake_ll.kml poi_names_wake_nc_spm.shp

grep -i AltitudeMode? poi_names_wake_ll.kml -> nothing

The tag does not appear.

Thanks anyway for your efforts,

Markus

[condit]

strange - i just checked out the head, applied the patch, and it seems to be working for me... are you sure it's loading the correct library?

you can quickly check to see if the patch is installed by running: ogr2ogr -f KML -dsco AltitudeMode?=errortest -t_srs "EPSG:4326" poi_names_wake_ll.kml poi_names_wake_nc_spm.shp this should issue a warning regarding unknown AltitudeMode? if everything is in place. if i remember right you're on linux. i built and tested this on windows, but if the kml driver is working for you and the patch is applied, shouldn't make a difference.

Replying to neteler:

I have ported the patch to SVN HEAD, but no luck yet (maybe my fault): # reproject from NC State Plane to LatLong?, do KML: ogr2ogr -f KML -dsco AltitudeMode?=absolute -t_srs "EPSG:4326" poi_names_wake_ll.kml poi_names_wake_nc_spm.shp grep -i AltitudeMode? poi_names_wake_ll.kml -> nothing The tag does not appear. Thanks anyway for your efforts, Markus

[neteler]

Suggestion: Apply this (harmless) patch to SVN to reach more people... I just realized that it isn't in SVN yet.

thanks, Markus

[warmerdam]

Turning over to Mateusz to address.

[mloskot]

Result of test translation bldg_elev3d.shp to KML using patched OGR.

[mloskot]

Fixed in trunk (r13136)