Opened 17 years ago
Closed 16 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)
Change History (24)
by , 17 years ago
Attachment: | bldg_elev3d.kml added |
---|
comment:3 by , 17 years ago
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 by , 17 years ago
Cc: | 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 by , 17 years ago
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 comment:6 by , 17 years ago
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 by , 17 years ago
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 by , 17 years ago
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...
by , 17 years ago
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 comment:9 by , 17 years ago
I have uploaded a 3D shapefile exported from GRASS to trac.
comment:10 by , 17 years ago
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 comment:11 by , 17 years ago
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 by , 17 years ago
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 by , 17 years ago
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 by , 17 years ago
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.
by , 17 years ago
Attachment: | altitudeMode.patch added |
---|
follow-up: 16 comment:15 by , 17 years ago
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 by , 17 years ago
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 by , 17 years ago
Suggestion: Apply this (harmless) patch to SVN to reach more people... I just realized that it isn't in SVN yet.
thanks, Markus
by , 16 years ago
Attachment: | test_result_ogr_patched.kml added |
---|
Result of test translation bldg_elev3d.shp to KML using patched OGR.
KML file in questions (exported with v.out.ogr, manually alt tag added)