Skip to content
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

Can this be accomplished with a geo-aligned anchor? #4

Open
blairmacintyre opened this issue Sep 18, 2018 · 9 comments
Open

Can this be accomplished with a geo-aligned anchor? #4

blairmacintyre opened this issue Sep 18, 2018 · 9 comments

Comments

@blairmacintyre
Copy link
Contributor

Can we create a geo-aligned anchor that orients itself with EUS over time? It's unclear to me right now if this would be better or worse, given that a platform like ARKit does this at the level of the whole global coordinates.

But, if WebXR makes different assertions about world coordinates than ARKit/etc does, even if the global world coordinates are going to be reorienting, it might make things clearer and simpler for developers.

@janerivi
Copy link

janerivi commented Oct 4, 2019

Since my initial contacts with this group back in the spring and summer of 2018 the Open AR Cloud Association has been founded and members of our community developed a draft proposal for a Geopose Working Group at Open Geospatial Consortium. I hope the W3C could contribute or at least track this proces closely and eventually implement support for it as part of the WebXR spec. You can read about it here: https://www.opengeospatial.org/pressroom/pressreleases/3041

@blairmacintyre
Copy link
Contributor Author

Is the proposal public yet? The link in the press release points to a document that just has the charter. (I'm an OGC member through Georgia Tech, but I wasn't aware of this work, so I haven't looked at the internal documents yet).

@janerivi
Copy link

janerivi commented Oct 6, 2019

There is only a draft for a standards working group to develop the geopose standard. OGC members are voting until Haloween for it to be a working group or not at this time. If it is approved after the vote the working group should be able to start around November 20th. Going in I proposed that we might do the geojson and only use wgs84 lat,lng,alt + a quaternion that is defined according to local north, east and vertical axis. After dialoge and discussion with other OGC members we see that we want to have the opportunity to at least A) have a timestamp field to be able to update the pose according with plate tectonic movements so that one can use this in construction and engineering where 3d objects real and virtual might move with the earth's crust. and B) There are members who would like to add support for additional geospatial coordinate reference systems (CRSs). Personally I hope that if support for other CRS's we can still use a lat,lng,alt variant as the default. Simple defaults will make it easier for more developers and more usecases to use this without having to read up on Geodetic subjects or figure out how to use conversion libraries...

@blairmacintyre
Copy link
Contributor Author

That sounds interesting ... since (I think?) GT is still an OGC member, let me know if you'd like me to join in.

I think wgs84 + some well defined local orientation (EUS, NEU, whatever) + a timestamp is a good start. (I admit the plate techtonics hadn't entered my thinking ... wow).

As long as it's well defined, I think we can do other conversions between all options at the user level. So, they could be part of the standard (i.e., as long as WebXR adopts one of them). I currently use Cesium's math libraries in my own code to convert from local euclicean to WGS84 + EUS orientation to Cesium FIXED (ECEF) coordinates, and also go to/from INERTIAL as needed.

@janerivi
Copy link

janerivi commented Oct 7, 2019

Please join in Blair! If you google geopose you will find some examples of libraries like th ROS (robot .. something) wich has this lat,lng,alt + quaternion concept already wich sort of validates the approach. Interesting that Cesium has an implementation.. I didn't know that. Our team should have a look :)

@blairmacintyre
Copy link
Contributor Author

I didn't mean that Cesium explicitly implemented this, although I guess they do: their Entities have both a position (in FIXED, which is meters-based ECEF) and orientation. These can be converted out to any of a bunch of systems, including WGS84. The orientation would be specified locally relative to one of ENU, EUS, etc.

That's essentially what we do in argon.js, as well. And in the geospatial stuff I've been working on here, I assume the full pose uses an orientation that is EUS based (for simplicity).

@janerivi
Copy link

janerivi commented Oct 8, 2019

If you by EUS mean East, Up, South.. that could be one way. In the GIS industry I belive North, East, Up is more common for orientation. But it has to allow full rotation around all three exis because a 3d vector pointing in a direction is not the full orientation needed, we also need the angle around that direction vector - thus a quaternion relative to geographical north/south, east/west, up/down makes a lot of sense.

@blairmacintyre
Copy link
Contributor Author

Yes, East Up South. And the age old dilemma of conflicts between graphics/CGI, aerospace, GIS and so on isn't going away. EUS corresponds most closely to what most 3D graphics folks think about (XYZ), but NEU matches the others better. Any standard should allow any well defined order of axes for the orientation; conversion is a simple matrix multiply, so it's trivial.

Quaternion, Euler Angles, Matrix; it also is irrelevant which is chosen for this, since conversions are easy, and there is no single right answer.

@janerivi
Copy link

For people to understand the values Euler Angles are probably easiest to comprehend, but quaternions are more practical for computation and is commonly used to represent poses in computer graphics and robotics including AR-platforms like ARKit and ARCore - For axis selection, yeah it doesn't matter much what is decided. But I think a standard should go for one alternative and stay with it to avoid confusion :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants