PVCollada convention for North/East orientations

[Peque]

Does PVCollada define a convention for North/East orientations?

I would assume +Y would be pointing to North, and +X would be pointing to East (+Z would be pointing "up" perpendicular to the floor), but not sure if this is really part of the specification.

If not, I would suggest that convention (if this could be part of the specification). The reasoning being that the Mercator projection is probably the most popular and, when viewing maps with this projection, +Y is pointing to North, +X pointing to East and +Z coming "out of the screen", assuming the usage of the also popular way of visualizing Cartesian coordinate systems (where +Y is always "up" on the screen/paper and +X is "right").

[cwhanse]

There are two coordinate systems: lat/long for location, and a local coordinate system to describe objects relative to a lat/long base point. The plan is that longitude would be positive to the east of the prime meridian. The local coordinate system is defined by a transformation vector so it can be oriented as desired, e.g., standard East-North x-y, a rotation from East-North, etc.

[Peque]

Thanks @cwhanse.

I'm assuming the file I should take for reference is PVCollada_2.09.xlsx. From there, and from the examples provided in this repo, I think the latitude+longitude definition is clear:

<project>
    <latitude>10.1</latitude>
    <longitude>15.3</longitude>
</project>

However, how can the transformation vector be defined? In particular, for a case where I would like to define standard East-North x-y. Note that I would not want to translate the local coordinates, which are already centered around (0, 0), just make sure the orientation is interpreted correctly when opening the file.

Also, if undefined, is there a "default" value according to the spec?

[cwhanse]

The translation element defined for PVCollada is meant to be the vector from the global lat/long to the origin of the local coordinate system.

PVCollada won't define its own local coordinate system, it will use the Collada specification. COLLADA uses a right-hand coordinate system, with flexibility to set the "up axis" and coordinate unit (see <up_axis> and children in the Collada spec.) COLLADA also allows for defining points (and I assume sets of points) via translation and rotation relative to the origin and standard x-east, y-north, z-up coordinate system.

[Peque]

@cwhanse Thanks for the clarification. Yeah, COLLADA seems to be clear about the use of the up axis. Leaving a screenshot here just for future reference. 😊

Does PVCollada define somewhere explicitly the correspondence between "Right axis" being East and "In axis" being South? Or, equivalently, that for a Z-up axis configuration, a +x translation means East with respect to the lat+lon coordinates and +y translation means North with respect to the lat+lon.

[cwhanse]

Other than finding the "right-hand" coordinate specification, I didn't find a mapping of Collada coordinates to compass directions, in the Collada spec. We can clarify that for PVCollada the standard x-axis points east.

[Peque]

@cwhanse Yeah, Collada does not seem to care about geographic coordinates (I guess that's why you also had to define latitude and longitude as part of PVCollada).

I think clarifying in PVCollada that x-axis points East is necessary in order to ensure that all platforms are able to interchange files without unexpected rotation issues. 😊

[cwhanse]

@Peque discussion with @Michalzr led us to recommend that PVCollada includes what you recommend: tags that explicitly establish the relationship between Collada's local x-y-z coordinates and earth-centered East-North-Up coordinates. Implementation TBD but would welcome your input. Thanks again for raising this issue.

[Peque]

@cwhanse Assuming the goal is to always use Local tangent plane coordinates (as opposed to other coordinates like ECEF), then it seems that there are two right-handed variants (citing the Earth bounded axes conventions Wikipedia article):

• East, North, Up (ENU), used in geography
• North, East, Down (NED), used specially in aerospace

NED seems to be targeted to airplane/aircraft use cases, so I cannot think about a reason to even support that convention. Hence, I think I would lean towards enforcing ENU to simplify the PVCollada specification, unless there is a compelling reason to make it more complicated.

@Michalzr perhaps you could explain why would you want to add a parameter to allow for other non-ENU variants? For example, is there any issue with ENU that would limit somehow what can be represented in PVCollada if it was to be enforced?

This could go a bit further and make PVCollada also enforce the use of <up_axis>Z_UP</up_axis> (as it is done in all .pvc examples).

Enforcing these will make importers easier to implement, having to support just one single case. I think helping importers can help the PVCollada adoption too, since importers are usually more complicated than exporters (importers need to cover all cases, while exporters don't necessarily need to).

[Michalzr]

@Michalzr perhaps you could explain why would you want to add a parameter to allow for other non-ENU variants? For example, is there any issue with ENU that would limit somehow what can be represented in PVCollada if it was to be enforced?

I don't want to add a parameter :)

I only mentioned this topic in a conversation with Cliff and Stephane, because I didn't find any information how the XYZ coordinates should be interpreted - which direction is east/north/up.

The way I see it:
A) @Peque suggests to simply have an agreement that it's alway the "ENU" (x = east, y = north, z = up) coordinate system
B) @cwhanse suggested (and mentioned in the last session) that there should be some tags in .PVC that explicitly establish a relationship between XYZ and east / north / up.

Both A and B solve the problem for me. I personally prefer A, because it's simpler. But it must be mentioned in some readme/documentation, so a person implementing the .pvc importer/exporter will find this information somewhere.

[Peque]

@cwhanse Then I think we (@Michalzr and I) agree on the way to go: using ENU by default, without adding a new parameter to the specification. 😊

Note that ENU has one more implication: Z_UP. I think this should be noted in PVCollada specification too, by enforcing the use of Collada's <up_axis>Z_UP</up_axis>. Fortunately, this change only simplifies further the implementation of PVCollada importers /exporters (instead of having to support three "up-axis" variants), and it seems to match what current examples in this repo have implemented.