Aligning to geocoordinates

[cwhanse]

TL:DR it appears that COLLADA allows for multiple local coordinate systems in one COLLADA document. Each local coordinate system may have its own geographic location as its origin. Whether PVCollada encourages or discourages this practice is open for discussion.

COLLADA defines the <geographic_location> element which contains <latitude>, <longitude> and <altitude>. See https://www.khronos.org/files/collada_spec_1_5.pdf page 5-40. COLLADA requires latitude and longitude to be specified as WGS 84 datum.

COLLADA uses a right-hand coordinate system. The <up_axis> tag (in COLLADA's ) identifies the orientation of the COLLADA coordinates. COLLADA coordinates are described (and designed) for visual diplay: right, up, and into the screen. #1 converged to agreement that PVCollada assumes (but doesn't enforce in the PVCollada schema) that Z_UP is chosen, so that X points right, Y points into the screen. In geographic coordinates, this orientation is as if we are viewing the scene from the south, with X being east, Y north, and Z up from earth surface.

<geographic_location> is an element inside . The element is the root of a PVCollada document. contains <asset>, where <geographic_location> appears in the example files.

Many other COLLADA elements may contain . Interestingly, <node> may contain both <asset> and <instance_geometry>. So an individual a coordinate system (and geolocation) may be specified for an <instance_geometry>. If a <node> does not have its own <asset> it is a safe assumption that the asset will be placed in the geocoordinates of its parent (up to the COLLADA root).

What does all this mean for implementation?

I think it is safest to specify a single <geographic_location> at the root . Meaning that all coordinates are in an x-y-z system (x-east, y-north) with origin at <geographic_location>.

If an object's natural coordinates are not aligned with WGS84 north-east, then <translation>, <rotation>, <scale> can be added. These operations should apply to all coordinates in child elements.

However, it is certainly allowable in COLLADA to provide <geographic_location> for other <asset> elements, essentially, establishing a local coordinate system for instances associated with that asset. That may be desirable, when a large system is being represented.

[Peque]

I think it is safest to specify a single <geographic_location> at the root . Meaning that all coordinates are in an x-y-z system (x-east, y-north) with origin at <geographic_location>.

+1 for this.

PVCollada assumes (but doesn't enforce in the PVCollada schema) that Z_UP is chosen

Why not enforcing this? Perhaps there has been a request to be flexible here for some reason, but otherwise I would assume that most parties would be interested in simplifying the implementation of importers by making sure this is always true.

Also Z_UP would be consistent with what "up" really means for all of us in our world and for all PV systems (pointing to the sky), since X points East and Y points North.

[cwhanse]

Why not enforcing this?

We can say in documentation that Z_UP is required, but we can't enforce that in the schema itself. There is no way, using the tags where PVCollada is implemented, to restrict the value of the COLLADA tag Z_UP.

We could look into adding a check to the validation script.

[Peque]

Yeah, sounds good (both mentioning this explicitly in the documentation and adding it as part of the validation script).

[mikehamer-dnv]

I agree that a check in the validation script and explicitly stating in the docs would be really useful to be clear on what is expected to ensure consistency. It's a more complicated area than you first think.

For the current .PVC file format - during import we (DNV) have had issues with interpreting the correct coordinates and what is the intention, giving the user the option to flip axes or swap Y,Z in case it doesn't look how it should. Different software packages that export .PVC files seem to have slightly different conventions. Files coming from PVcase don't seem to specify the <up_axis> tag and so use the Collada default of Y_UP. We then swap the Y and Z coordinates on import to convert to our internal Z_UP convention. It would be good to have someone from PVcase confirm this is the case - and that they're happy to change to Z_UP for .PVC2.

On our export to the current .PVC format, we currently export with Z_UP. But this currently looks incorrect in PVsyst as (in the 'Shading scene construction' dialog) it looks like positive X points to the west, and positive Y points to the south, which is the opposite of what we are proposing. Searching in the PVsyst help: Global Referential orientations it looks like the reference system changes depending if your site is in the northern or southern hemisphere:

• In the northern hemisphere: the X-direction corresponds to the West, Y to the SOUTH, Z to the ZENITH.
• In the southern hemisphere: the X-direction points to the EAST, and Y to the NORTH.
  Hopefully this can be accounted for in PVsyst with the new .PVC2 format if we standardize on the Z_UP convention for sites around the world.

[Peque]

@mikehamer-dnv PVsyst seems to be happy with the ENU convention for PVCollada 2.0, which implies Z_UP.

I'd say the important thing here is to know whether the majority feels the same way.

Would you (at DNV) be happier if you could assume the same convention always? (Z_UP and ENU)

We (at ieco.io) are happy with that. Many things already differ from version 1 to version 2, so updates to the current export code are expected. We think it is a good opportunity to try to clean things up and standardize (which means being less flexible with things that do not really require higher flexibility to make the format better). 😉

The fact that you "have had issues with interpreting the correct coordinates" may indicate that this is something to improve with the new format as well.

[mikehamer-dnv]

@Peque Thanks for the link to the previous discussion. Standardizing on Z_UP and ENU for version 2 would make us (at DNV) very happy too - simplifying both import and export code.

[cwhanse]

#46