citygml4j / citygml-tools

Collection of tools for processing CityGML files
Apache License 2.0
115 stars 18 forks source link

CityGML to CityJSON coordinate transform error #31

Closed kymok closed 1 year ago

kymok commented 1 year ago

Problem

citygml-tools does not convert to CityJSON integer coordinate correctly.

Steps to reproduce

Input file:

Convert command:

docker run --rm -u 1000 -v $(pwd):/data \
 citygml4j/citygml-tools:latest \
 to-cityjson \
 --vertex-precision=9 \
 --template-precision=9 \
 /data

This command gives following result.

Input (excerpt from cityGML)
[35.69290349805112, 139.69975311145927, 40.646]
[35.69290919239969, 139.69979490500816, 40.646]
[35.692996478348114, 139.6997770760938, 40.646]
[35.6929907939121, 139.69973528579897, 40.646]

Output (excerpt from resulting CityJSON file)
coords:
[33545419851, 137552269464, 38498516353],
[33545425545, 137552311258, 38498516353],
[33545512831, 137552293429, 38498516353],
[33545507147, 137552251639, 38498516353]
scale:
[1e-9, 1e-9, 1e-9]
translate:
[35.690645544, 139.687203747, 22.109]

As per CityJSON spec, input should be equal to output coordinates * scale + translate. However, it's not the case here.

Output coords * scale - input coords gives following result. Seems like an integer overflow problem because 2.14748365e+9 is the integer max.

array([[-2.14748365, -2.14748365, -2.14748365],
       [-2.14748365, -2.14748365, -2.14748365],
       [-2.14748365, -2.14748365, -2.14748365],
       [-2.14748365, -2.14748365, -2.14748365]])
clausnagel commented 1 year ago

Thanks for reporting. Your guess about the integer overflow was correct and I fixed it in citygml4j. Please use the edge Docker image (instead of latest) for testing the fix.

kymok commented 1 year ago

I've tested the conversion and now it seems to be working correctly. Thank you for your quick response!

clausnagel commented 1 year ago

Good to hear, thanks. Closing this issue now. Feel free to re-open if this issue still exists.