Opened 12 years ago

Closed 11 years ago

#1570 closed defect (fixed)

KML: 3D export appears 2D

Reported by: Markus Neteler Owned by: Mateusz Łoskot
Priority: normal Milestone: 1.5.0
Component: OGR_SF Version: unspecified
Severity: normal Keywords: kml
Cc: condit@…, 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 (7)

bldg_elev3d.kml (78.4 KB) - added by Markus Neteler 12 years ago.
KML file in questions (exported with v.out.ogr, manually alt tag added)
ge_voutogr_3d.jpg (126.9 KB) - added by Markus Neteler 12 years ago.
GE screenshot 1
ge_voutogr_3d_2.jpg (90.2 KB) - added by Markus Neteler 12 years ago.
GE screenshot 2
bldg_elev3d_shape.tar.gz (6.4 KB) - added by Markus Neteler 12 years ago.
3D Polygons SHAPE of the same 3D vectors exported from GRASS with v.out.ogr
altitudeMode.patch (11.0 KB) - added by condit 12 years ago.
altitudeMode_SVN_HEAD.patch (9.3 KB) - added by Markus Neteler 12 years ago.
Same patch against SVN HEAD
test_result_ogr_patched.kml (84.0 KB) - added by Mateusz Łoskot 11 years ago.
Result of test translation bldg_elev3d.shp to KML using patched OGR.

Download all attachments as: .zip

Change History (24)

Changed 12 years ago by Markus Neteler

Attachment: bldg_elev3d.kml added

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

Changed 12 years ago by Markus Neteler

Attachment: ge_voutogr_3d.jpg added

GE screenshot 1

Changed 12 years ago by Markus Neteler

Attachment: ge_voutogr_3d_2.jpg added

GE screenshot 2

comment:3 Changed 12 years ago by Markus 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

comment:4 Changed 12 years ago by warmerdam

Cc: condit@… warmerdam added
Keywords: kml added
Milestone: 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.

comment:5 Changed 12 years ago by Markus 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

comment:6 Changed 12 years ago by Mateusz Łoskot

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.

comment:7 in reply to:  6 Changed 12 years ago 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.

comment:8 Changed 12 years ago 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...

Changed 12 years ago by Markus Neteler

Attachment: bldg_elev3d_shape.tar.gz added

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

comment:9 Changed 12 years ago by Markus Neteler

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

comment:10 in reply to:  9 Changed 12 years ago 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.

comment:11 Changed 12 years ago by Markus 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

comment:12 in reply to:  11 Changed 12 years ago 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@… 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

comment:13 Changed 12 years ago by 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

comment:14 Changed 12 years ago 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.

Changed 12 years ago by condit

Attachment: altitudeMode.patch added

Changed 12 years ago by Markus Neteler

Attachment: altitudeMode_SVN_HEAD.patch added

Same patch against SVN HEAD

comment:15 Changed 12 years ago by Markus 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

comment:16 in reply to:  15 Changed 12 years ago 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

comment:17 Changed 11 years ago by 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

comment:18 Changed 11 years ago by warmerdam

Cc: Didge added
Owner: changed from warmerdam to Mateusz Łoskot

Turning over to Mateusz to address.

Changed 11 years ago by Mateusz Łoskot

Attachment: test_result_ogr_patched.kml added

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

comment:19 Changed 11 years ago by Mateusz Łoskot

Resolution: fixed
Status: newclosed

Fixed in trunk (r13136)

Note: See TracTickets for help on using tickets.