Incorrect height in kml

[kam1107]

Hi,
I am trying to convert NYC citygml model to kml format and load into google earth. However, the height of buildings are not correct.

I use EPSG=2263 but not sure how to set gml:srsName. Could you please offer some help?

Many thanks!

[Son-HNguyen]

Is the EPSG code you entered the same as the SRID given in the CityGML file (in the envelope element for example)? You can also find the GMLSRSNAME there. Additionally, you can adjust the elevation in the Importer/Exporter, see here.

[kam1107]

I used the NYC CityGML model in this link: https://www1.nyc.gov/site/doitt/initiatives/3d-building.page
and it provides:

where the Berlin sample contains:

I tried to enter 'urn:ogc:def:crs,crs:EPSG::2263' for srsname and the results looks like the image above. How should I find the correct srsname 🤔？

[clausnagel]

Hi @kam1107, use 2263 as SRID when setting up the 3DCityDB instance. The srsName attribute could simply be "EPSG:2263" as in the original datasets. You can easily fix the KML export by deactiving the "Use orginal height values without transformation" option in the elevation settings:

When you choose COLLADA as output format, there are still issues with the size of the buildings. The reason is that the original data uses US survey foot while the COLLADA export expects meters. @Son-HNguyen, this might be a bug that needs to be fixed.

[kam1107]

Hi @clausnagel, thanks for your tips! I did as you suggested:


but the displayed height is still incorrect (I exported geometry). Does foot and meter conversion affect geometry as well?

[clausnagel]

Hm, strange, I tested again with the latest version 5.0.0 of the Importer/Exporter and when using the above setting the result looks fine for me. I just tested with a part of Manhattan.

And here is the export without this setting:

[kam1107]

Emmmm no I still cant get it right. Here's what I do:
(1)

and then run CREATE_DB.sh
(2)
In 3D city importer/exporter, I untick the 'w/o transformation' setting and import the model:

(3)
Go to VIS Export and select a subregion:

(4)
and I load the kml model into GE pro:

Did I miss anything 🤔?

[clausnagel]

The steps seem to be ok. You only need to uncheck the w/o transformation for the VIS Export, it does not have an impact on the import in step 2. But that's only a minor comment.

Can you please share your CityGML dataset just to be sure that we are using the same input data? And maybe also your exported KML?

If it's not the Importer/Exporter, maybe the database makes the difference? What PostGIS version are you using?

@Son-HNguyen, have you also tried to export the model? Do you face the same issues or does it work for you?

[Son-HNguyen]

Using the bounding box and settings provided by @kam1107, this is what I could reproduce:

I also used the Importer/Exporter 5.0.0.

We might indeed need to have a look at your dataset and the database info as @clausnagel said.

[kam1107]

Here's the link to the gml&kml file: https://drive.google.com/file/d/144pURsnqKfKjgenHrNKfOvForpCOGt5i/view?usp=sharing
and my PostGIS version is 3.1.4
also I use Importer/Exporter 5.0.0

[clausnagel]

Thanks for sharing the data and the database info.

I ran my tests on PostGIS 2.3.3. With PostGIS 3.1.2, I can actually reproduce your issue. For the KML geometry export, we internally transform the data to WGS84 (EPSG:4326). While PostGIS 2.3.3 adapts the height values in this transformation, PostGIS 3.1.2 does not change the heights.

Here is the SQL I used for testing:

select st_astext(st_transform(envelope, 4326))
from cityobject
where gmlid= 'gml_ZAWOQ5RHROA5Y2UDFRWNZV2E8QOZQ43HKINV'

For PostGIS 2.3.3, the result is:

POLYGON Z ((-73.9866524964111 40.768403294905 22.4129032258052 ...

However, PostGIS 3.1.2 returns:

POLYGON Z ((-73.98665249641105 40.76840329490502 73.5329999999958 ...

So, PostGIS 2.3.3 returns a height value of 22.4129032258052 while PostGIS 3.1.2 returns 73.5329999999958, which is the original height in US survey foot used in EPSG:2263.

PostGIS bug? I don't know...

[kam1107]

Okay..... I also noticed there is an `affine transformation' configuration in Preferences/Import/Geometry. Does that affect the imported geometry? Actually, I tried to modify this matrix but the exported kml remains the same.

[clausnagel]

Yes, affine transformation works. Tested with the following matrix:

Alternatively, you can also use ST_Scale to directly adapt the geometries stored in SURFACE_GEOMETRY and CITYOBJECT:

update surface_geometry
set geometry=st_scale(geometry, 1.0, 1.0, 0.3048)
where geometry is not null;

update cityobject
set envelope=st_scale(envelope, 1.0, 1.0, 0.3048)
where envelope is not null;

[kam1107]

Yes! that works for me as well! Many thanks!