Hello,
I have many building models in COLLADA format, but they are already georeferenced, I mean that point coordinates have already real world coordinates. Something 46398.53584999999, 6580605.3590799998, 16.705.
The question is: is that a way to uploads such models directly using their own coordinates without having to specify separately in Cesium?
Thanks!
Once converted to glTF those models should work fine without needing to specify anything separately in Cesium.
Hi Sean,
The problem is that I convert them from an ESRI shapefile to COLLADA and then to glTF and points have real world coordinates so that they end up somewhere in the space near the moon!!! when I turn on the coordinate system axes, its origin is on the right place on the earth. other models that have no geometry work fine. any comment on that?!
Just to be sure, are you setting the modelMatrix or position? Those do not need to be set if the model is already geolocated. If that isn’t the issue, feel free to send me the model and I can take a closer look.
Hi again,
Yes I figured that out! thanks anyway. yet I do not know how to transform from SWEREFF99 which is used in Sweden to WGS84. any tips on that?
BR
Sorry but I’m not familiar with SWEREFF99. I translated the Wikipedia page to English and it seems to be mostly interchangeable:
SWEREF 99 agree within about half a meter with WGS 84 . Since the accuracy of the position measurements based on data only from the GPS satellites is about 10 meters [ 1 ] can SWEREF 99 and WGS 84 in many GPS applications in Sweden are considered to be equivalent.
You can use the GDAL utility ogr2ogr to convert the coordinates to WGS84 with something like this:
ogr2ogr.exe -f “ESRI Shapefile” Byggnad_area_3D_WGS84.shp Byggnad_area_3D.shp -t_srs EPSG:4326
``
I have been unable to determine the transformation from RH2000 heights to WGS84.
Hi Sean,
now after more that two months I had to com back to you!! I do not know what goes wrong really but I cannot get this simple building on Cesium. Could you please take a look at it?
it is my original shape file model (which is just a building extracted from a large city model) and COLLADA model in geocentered coordinates and gltf model as well.
It is part of my thesis work and I am now frustrated!
Many thanks in advance.
model.rar (4.47 KB)
Are you using the Entity API? I noticed some trouble with that for geo-referenced models. Using the underlying Model API I was able to see the model with the code below. By the way, you should check out the Cesium RTC extension for more precise rendering - as it is the model shifts around a lot.
var viewer = new Cesium.Viewer(‘cesiumContainer’);
var scene = viewer.scene;
function createModel(url) {
var model = scene.primitives.add(Cesium.Model.fromGltf({
url : url,
modelMatrix : Cesium.Matrix4.IDENTITY
}));
model.readyPromise.then(function(model) {
var camera = viewer.camera;
var r = 2.0 * Math.max(model.boundingSphere.radius, camera.frustum.near);
var center = Cesium.Matrix4.multiplyByPoint(model.modelMatrix, model.boundingSphere.center, new Cesium.Cartesian3());
var heading = Cesium.Math.toRadians(230.0);
var pitch = Cesium.Math.toRadians(-20.0);
camera.lookAt(center, new Cesium.HeadingPitchRange(heading, pitch, r * 2.0));
}).otherwise(function(error){
window.alert(error);
});
}
createModel(’…/…/SampleData/test/Byggnad_area_3D_surface.gltf’);
``
Hi Sean,
Yes I used Entity API because it was recommended to do so, do you suggest using Primitive API now?
And for the model, It is supposed to appear somewhere in the Stockholm city of Sweden but this ends up somewhere near the earth center!!
How do you suggest converting from that shape file to COLLADA? I used FME but I think there is some problem when converting it, but I am not sure though.
The Entity API should work fine with georeferenced models, if it doesn’t please submit a bug to Github. If you can share the model you are trying to load, that would be a big help.
I got it working with the Entity API, give this a shot. The position and orientation need to be provided. I attached the sample model that Iman sent and a screenshot.
var viewer = new Cesium.Viewer(‘cesiumContainer’);
function createModel(url) {
var entity = viewer.entities.add({
name : url,
position : Cesium.Cartesian3.ZERO,
orientation : Cesium.Quaternion.IDENTITY,
model : {
uri : url
}
});
viewer.trackedEntity = entity;
}
createModel(’…/…/SampleData/test/Byggnad_area_3D_surface.gltf’);
``
Byggnad_area_3D_surface.gltf (12.6 KB)
OMFG!
Thanks Sean, I was stuck in this for two months trying to find some tricks and workarounds!
But how come API says that position and orientation are optional? I think you should update the documentation in this regard. I had actually figured out that it does not work without position provided but I did not think of orientation!
Hi again Sean,
I figured out that gltf file you uploaded is not the same gltf that I uploaded! and using my original gltf it still does not work!
could you please explain how did you convert it? or how come it changed from the original file?
Iman’s problem is killing me, I’m very frustrated.
The forum seems filled with other developers posting issues loading 3D models.
The cesium team; Sean, Patrick, Matt; seem to be coming from a totally different geospatial background than a GIS analyst/developers like myself, who are attempting to use Cesium as a 3D GIS dataviewer.
The first paradigm-shift for GIS developers is that Cesium’s default map has no compass and north arrow, it has a clock control; (something I am beginning to really appreciate, btw). I intend to get that *compass and north arrow *cesium-navigation mix-in working, but you guys should have a DEMO of that cesium-navigation working in SANDBOX, for pete’s sake… as a part-time developer, integrating cesium-navigation into my code is a PIA, and my first quick attempt failed. But I digress…
IF the model is “georeferenced” in a “projected coordinate system” (PCS), not a “geographic coordinate system” (GCS), in ESRI ArcGIS terminology, that means the position and orientation are already known, before ArcGIS exports to .dae/COLLADA,
THEREFORE all of us GIS-background folks expect that the known ArcGIS position and orientation properties should carry-over as a native property to the datasource, when the model is 1st exported from ArcGIS Desktop to COLLADA, and 2nd, converted to GLTF or GLB, and 3rd, added to Cesium’s entities. If there were enough hours in the day, i would have QA tested this to death, and figured this out months ago, and so would dozens of other wannabe cesium js developers from the ArcGIS world.
There is some disconnect on our (GIS developers) communication with the Cesium team, and misunderstanding of Cesium’s documentation, regarding the position and orientation of 3D GLTF models.
Matt & Patrick say it should work.
Sean writes “The position and orientation need to be provided.”
What Iman and I have been saying for months is: WE DON’T KNOW WHAT the position and orientation properties are…
The position and orientation are embedded in the GIS data format, when the model was “georeferenced”; once the model renders in the ArcGIS software in the correct X-Y position and rotation, and Z value for height/elevation, it’s not exposed to the ArcGIS user.
The 2D-footprint of the 3D model has an X-Y bounding rectangle that can be queried indirectly by the ArcGIS user, but the center of the bounding sphere, in WGS84 coords… Sean, if I knew, I would provide it.
position and orientation has been lost in translation of our models…
It is only revealed to an ArcGIS user, if the export to COLLADA included a KML file, within which ESRI calculated a Position coordinate using undisclosed, internal methods, and if you are smart enough to open that KML with a text editor to copy the X and Y.
Iman and I have shared the experience that loading GLTF models in Cesium DOES NOT WORK, unless we can determine the centroid coordinates, in WGS84 crs, of the model’s bounding sphere.
Part of the issue is that Cesium needs a GLTF in WGS84 coordinates, and that transformation, from
Yet the Cesium team agrees that it should work.
I don’t think it’s a Cesium or WebGL bug, it’s a communication & documentation failure.
“I am a smart person”, lol, but I’ve thrown hours, days, maybe a week into this over the past 3 years. If I could get georeferenced GIS data from UTM or State Plane projected coordinate systems, converted into MultiPatch and exported to DAE, then converted to GLTF/GLB, then loaded in Cesium easily and semi-automated, I would be off-to-the-races making online maps to visualize that data in 3D, and showcase Cesium, instead of debugging code; and dozens of other GIS developers would use it, too.
Part of the disconnect in my understanding is how the georeferencing information (position&orientation) are properties of one MultiPatch in ArcGIS, but upon exporting that entity to a COLLADA model, ArcGIS may determine the original position&orientation transformed to WGS84 coordinates for inclusion in a KML for conveniently viewing the DAE in GoogleEarth, but the position&orientation are NOT in the COLLADA XML. Omitting the position&orientation from the DAE file allows instantiating multiple copies of that model at multiple new position&orientations, if you know the models original position&orientation, required to calculate the transforms to any new position&orientations, or to insert just 1 copy in that original position&orientation.
I’m leaning towards this being an issue in the ArcGIS export-to-COLLADA, not Cesium’s API, nor the http://cesiumjs.org/convertmodel.html, and wonder if I should look into how GDAL handles multipatch-ESRI-shapefile (or FGDB featureclass?) export-to-COLLADA.
Maybe my thoughts above will jog someone else’s memory, and enlightenment will follow…
Thanks-
Jon
Hi Jonathan,
AS I understood so far COLLADA models are absolutely dumb! All it understands is a 3D CARTESIAN coordinate system. Where to put the origin of that coordinate system is our choice depending on our data. if you put it in the earth’s center then our COLLODA model is “georeferenced”, so we have absolutely nothing do with “projected coordinates”. for example a point around Sweden should have coordinates something like [3101260.69420079, 1011837.24493671, 5462411.4665742004] for it x, y, z. To get that coordinates I used FME software to reproject coordinates from SWREFF99 to EPSG:4978 which is a WGS84-geocentric coordinate system. but when converting to gltf something goes wrong which has driven me crazy over last two months.
when Sean says “The position and orientation need to be provided”, it means that although API says that those are optional but you need to provide them still. position is {x:0,y:0,z:0} by default but it does not work if you omit it!
I absolutely agree that it is a communication & documentation failure. And I strongly believe that Cesuim must have much better documentation and much more informative tutorials as it is claimed to be one the biggest JavaScript code bases on the internet.
Another important issue is the fact that ESRI’s ShapeFile format is too important to be ignored! I myself am neither a big fan of proprietary stuff nor an ArcGIS user, we like it or not a HUGE amount of 3D data is going to be converted from this format. So it is crucial to streamline the process of converting from ShapeFile to glTF.
But let’s not give it up and solve this so that many more GIS-developers can benefit from it.
You’re right about these COLLADA files, they are in a Cartesian coordinate system where the model’s origin is (0,0,0) but the vertex data is located geographically. The longitude/latitude is baked into the model so providing a different orientation and position when loading the model in Cesium won’t have the desired effect.
About the model I uploaded, I ran the original Byggnad_area_3D_surface.dae through COLLADA2GLTF and got that result. Now I see that the gltf you posted doesn’t work for me either. When converting the dae with the online converter it’s also wrong. The online converter uses an old-ish version of gltf-pipeline and I believe there is a bug in there. When I run COLLADA2GLTF and gltf-pipeline both locally, with the newest versions, the model is correct. So basically we just need to update the online converter… sorry about the problems there.
Some more details about position and orientation in the entity API: position is always required. Orientation is not, however if you don’t specify it the default orientation is an east-north-up orientation, which looks good for placing models whose local bounding volume center is (0,0,0), but not the case for these “georeferenced” models.
Hi Iman,
From your post, I could see you have used ESRI Shapefile to create a COLLADA Model and then yo gITF. Do you have any write up on how to convert from ESRI Shapefile to gITF?
Also the shapefile you have used, is 3D shapefile I suppose?
Details on the conversion steps would be very helpful. I need to create a 3D Models from 2D buildings data in shapefile format.
Thanks
Rohit
Hi Rohit,
Yes I did convert models from 3D ESRI shapefile. Right now I am using FME desktop software which can take care of every possible conversion that you can think of!
you can test it for a month and if you are student you can get a student licence for several months.
using FME I convert to COLLADA and then using COLLADA2GLTF to gltf.
But, considering the fact that you have buildings in 2D I suggest that you convert them to GeoJson format, import them to Cesium and extrude them. My experience says that it works much better.
Rohit,
Farouk is getting great results using FME, but I do not have access to that software, and its not cheap (unless you are a student, or can complete your project before a 30-day trial times-out).
Do you have access to ESRI ArcGIS Desktop software, with a 3D Analyst license, for converting your 2D building polygons into 3D models?
The ESRI ArcGIS procedures I’ve been working on will not help you, unless you have ESRI software licenses.
Best regards-
-Jon, aka Lftgly