Ticket #1570 (closed defect: fixed)

Opened 1 year ago

Last modified 7 months ago

KML: 3D export appears 2D

Reported by: neteler Assigned to: mloskot
Priority: normal Milestone: 1.5.0
Component: OGR_SF Version: unspecified
Severity: normal Keywords: kml
Cc: condit@sdsc.edu, warmerdam, Didge

Description

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

Attachments

bldg_elev3d.kml (78.4 kB) - added by neteler on 04/10/07 09:40:50.
KML file in questions (exported with v.out.ogr, manually alt tag added)
ge_voutogr_3d.jpg (126.9 kB) - added by neteler on 04/10/07 09:42:24.
GE screenshot 1
ge_voutogr_3d_2.jpg (90.2 kB) - added by neteler on 04/10/07 09:42:49.
GE screenshot 2
bldg_elev3d_shape.tar.gz (6.4 kB) - added by neteler on 04/19/07 09:56:54.
3D Polygons SHAPE of the same 3D vectors exported from GRASS with v.out.ogr
altitudeMode.patch (11.0 kB) - added by condit on 07/24/07 22:02:07.
altitudeMode_SVN_HEAD.patch (9.3 kB) - added by neteler on 07/25/07 08:28:12.
Same patch against SVN HEAD
test_result_ogr_patched.kml (84.0 kB) - added by mloskot on 11/29/07 00:36:51.
Result of test translation bldg_elev3d.shp to KML using patched OGR.

Change History

04/10/07 09:40:50 changed by neteler

  • attachment bldg_elev3d.kml added.

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

04/10/07 09:42:24 changed by neteler

  • attachment ge_voutogr_3d.jpg added.

GE screenshot 1

04/10/07 09:42:49 changed by neteler

  • attachment ge_voutogr_3d_2.jpg added.

GE screenshot 2

04/10/07 09:54:03 changed by 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

04/10/07 10:27:24 changed by warmerdam

  • keywords set to kml.
  • cc set to condit@sdsc.edu, warmerdam.
  • milestone set to 1.5.0.

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.

04/10/07 10:50:51 changed by 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

(follow-up: ↓ 7 ) 04/10/07 14:27:10 changed by 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.

(in reply to: ↑ 6 ) 04/10/07 15:18:33 changed by 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.

04/13/07 13:37:32 changed by 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...

04/19/07 09:56:54 changed by neteler

  • attachment bldg_elev3d_shape.tar.gz added.

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

(follow-up: ↓ 10 ) 04/20/07 11:10:08 changed by neteler

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

(in reply to: ↑ 9 ) 04/22/07 12:16:20 changed by 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.

(follow-up: ↓ 12 ) 04/22/07 13:54:49 changed by 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

(in reply to: ↑ 11 ) 04/23/07 12:23:18 changed by 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@sdsc.edu 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

04/23/07 12:28:47 changed by 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

07/24/07 22:01:48 changed by 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.

07/24/07 22:02:07 changed by condit

  • attachment altitudeMode.patch added.

07/25/07 08:28:12 changed by neteler

  • attachment altitudeMode_SVN_HEAD.patch added.

Same patch against SVN HEAD

(follow-up: ↓ 16 ) 07/25/07 08:59:05 changed by 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

(in reply to: ↑ 15 ) 07/25/07 13:17:36 changed by 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

09/10/07 09:23:13 changed by neteler

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

thanks, Markus

09/10/07 09:51:56 changed by warmerdam

  • owner changed from warmerdam to mloskot.
  • cc changed from condit@sdsc.edu, warmerdam to condit@sdsc.edu, warmerdam, Didge.

Turning over to Mateusz to address.

11/29/07 00:36:51 changed by mloskot

  • attachment test_result_ogr_patched.kml added.

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

11/29/07 00:37:35 changed by mloskot

  • status changed from new to closed.
  • resolution set to fixed.

Fixed in trunk (r13136)