Georeferenced COLLADA

[Iman Tahriri]

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!

[Sean Lilley]

Once converted to glTF those models should work fine without needing to specify anything separately in Cesium.

[Iman Tahriri]

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?!

[Sean Lilley]

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.

[Iman Tahriri]

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

[Sean Lilley]

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.

[Scott Reynolds]

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.

[Iman Tahriri]

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.

[Sean Lilley]

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');

[Iman Tahriri]

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.

[Matthew Amato]

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.

--
You received this message because you are subscribed to the Google Groups "cesium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cesium-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sean Lilley]

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');

To unsubscribe from this group and stop receiving emails from it, send an email to cesium-dev+...@googlegroups.com.

[Iman Tahriri]

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!

[Iman Tahriri]

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?

[Left Gully]

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

[Iman Tahriri]

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.

[Sean Lilley]

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.

[rk28...@gmail.com]

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

[Iman Tahriri]

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.

[Left Gully]

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

[Iman Tahriri]

And if you are considering to use 2D polygons and extrude them, you can convert from Shapefile to GeoJson using GDAL easily.

[Left Gully]

Good point, Iman! If I get this working using ESRI software, I will want to replicate the process using opensource software, and GDAL is a great utility ! 

On Wednesday, January 25, 2017 at 4:16:21 AM UTC-5, Iman Tahriri wrote:

And if you are considering to use 2D polygons and extrude them, you can convert from Shapefile to GeoJson using GDAL easily.

On Tuesday, January 24, 2017 at 5:37:04 PM UTC+1, Left Gully wrote:

Rohit,

Iman 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).

[sumit.k...@gmail.com]

Hi Imran,

Could you please tell me how did you get the 3d models georeferenced, I have the 3d models in collada format but they are not georeferenced. If you know, could you please help me with this. 

Thank you!

On Wednesday, October 12, 2016 at 5:58:53 AM UTC-4, Iman Tahriri wrote: