-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Z-coordinate difference between Height service and embedded values in swissBUILDINGS3D 2.0 #3156
Comments
For the But as coordinates in the two latter are |
Thanks, @procrastinatio. You are right, Collada uses WGS84 🤦♂️ |
@RobertoMinelli is this still an issue? |
Yes, @danduk82. When I assemble a terrain obtained by triangulating 3D points obtained using the |
@RobertoMinelli, you should convert your colladata altitudes to LN02. As @procrastinatio told here above, in our data, the Z coordinate is not reprojected on the WGS84 ellipsoid, but for "consistency with the original dataset reasons" we keep the Z coordinates that we get in the original LV95 datasets. Which is in LN02... |
Grazie @danduk82. Any hint on how to read and convert Z-coordinates from I am just wondering then... why are the altitudes in the Thank you very much, |
Yes. Inline/collars is wgs84
Roberto Minelli <[email protected]> schrieb am Mi. 15. Mai 2019 um
17:25:
… Grazie @danduk82 <https://github.com/danduk82>. Any hint on how to read
and convert Z-coordinates from COLLADA models? As of now I was only
converting COLLADA to .stl in order to merge it with the terrain
(obtained bu querying your Height Service.
I am just wondering then... why are the altitudes in the swissBUILDINGS3D
dataset in WGS84? Because of the format, i.e., COLLADA?
Thank you very much,
Rob
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3156?email_source=notifications&email_token=ABC5TPYFO3FKO6GTVTSCHYLPVQTOLA5CNFSM4HGHBNE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVPAVUQ#issuecomment-492702418>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABC5TP5M5J3WY7BRVAL3WRLPVQTOLANCNFSM4HGHBNEQ>
.
|
Any news on this @danduk82? It would be amazing if there was a way to have a match between the two height models... Moreover, as you can see in the screenshots below, if I manually align one of the buildings to the ground, other buildings are "flying". As of now, my terrains have a resolution of 25 meters (i.e., I query the Height Service every 25 meters in a swipe fashion then I triangulate points to get the surface).
I also attach the two .stl models of terrain and buildings. Thanks, |
Dear all,
I am trying to create a single 3D model (
.stl
) that contains both a 3D surface representing a terrain and the buildings that lie on that terrain.To generate the terrain surface, I create a XY-grid of coordinates and I obtain the elevation using the Height service of the GeoAdmin API REST services.
I obtain the buildings contained in the terrain by leveraging the swissBUILDINGS3D 2.0 dataset that I've bought.
Now, the problem: The
COLLADA
(.dae
) models contained in the swissBUILDINGS3D 2.0 dataset have embedded XYZ coordinates (i.e., each building knows where it should be placed on the terrain). X and Y coordinates match with my terrain. Unfortunately, the Z-coordinate do not march (i.e., the terrain is always above the buildings, as per screenshot attached). Do you have any intuition? Am I doing something wrong?cc: @danduk82 @davidoesch @oterral @procrastinatio 😇
The text was updated successfully, but these errors were encountered: