Skip to content

create local_projection #58

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.

Sign up for GitHub

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

Merged
cwhanse merged 5 commits into from
Mar 4, 2026
Merged

create local_projection #58

Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
cb59605
create local_projection
cwhanse Feb 19, 2026
a412818
make optional
cwhanse Feb 20, 2026
71b73c0
add note to local_projection
cwhanse Feb 23, 2026
c6c2402
characters
cwhanse Feb 27, 2026
b13be44
Update schema/pvcollada_schema_2.0.xsd
cwhanse Mar 3, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions schema/pvcollada_schema_2.0.xsd
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -733,6 +733,11 @@ xmlns:collada="http://www.collada.org/2008/03/COLLADASchema">
1.0</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="local_projection" type="xs:string" minOccurs="0">
<xs:annotation>
<xs:documentation xml:lang="en">EPSG code for the projection to be used with the local coordinates that describe objects in the scene. Format as "ESPG:3857", for example.</xs:documentation>
Copy link
Copy Markdown

@ross-planted ross-planted Feb 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Minor typo]

ESPG:3857 example should be "EPSG:3857" (switched P and S)

Copy link
Copy Markdown
Member Author

@cwhanse cwhanse Feb 20, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ross-planted great comment about coordinates, which I hadn't considered. You are right, the origin has x-y-z values of (0,0,0) not the EPSG coordinates of that point. If the only additional information provided is lat/long and the EPSG code, then a user could compute the EPSG coordinates for the origin, which then could be added to the local coordinates of an object to finally place the object in geo-space. Is that sufficient? Or should we consider a tag to memorialize the EPSG coordinates of the origin in the PVC2 file?

Copy link
Copy Markdown

@ross-planted ross-planted Feb 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cwhanse yeah that sounds correct that technically just having the EPSG code and the lat/long of the origin is actually enough to fully define everything. Software that was reading a file formatted this way could just convert the origin to the coordinates in the given EPSG frame and then translate every coordinate from the file by that resulting origin (x,y,z) which would give you the coordinate of each point in the EPSG frame (as you described above).

I think as long as it's clear that this is the intent for how to interpret/calculate the positions of all points in the file, that works for me. In my opinion, it's probably slightly clearer to have the coordinates of all points just directly defined in the given EPSG csys. Then you can say "if you have an EPSG code listed, then you can just interpret the coordinates directly in that frame, because they are coordinates in that system". In that case, all the coordinates for the site would be large numbers like (500,000, 200,000), but there would be no translation step and it wouldn't actually matter where the origin was. You could just directly look at a point's coordinates and drop that into a CAD model (for instance) that was defined in the correct frame.

At the end of the day, either way is fine for me as long as it's clear in the docs/comments what the intent is (whether each individual coordinate is inferred to already be in the EPSG code csys given, or if you need to translate each point by the equivalent origin point in the given EPSG code csys).

To answer your last question, I'd vote for not memorializing the EPSG coordinates of the origin in the PVC2 file. I think that would be duplicated information if we already have the EPSG code itself and the lat/long coordinates of the origin (since you can derive the coordinates in the EPSG frame from those lat/long directly). And I think I like the idea of having less fields where we can.

</xs:annotation>
Comment on lines +738 to +743
Copy link
Copy Markdown
Member Author

@cwhanse cwhanse Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<xs:documentation xml:lang="en">ESPG code for a projection to associate local coordinates (x,y,z) with geocoordinates (lat-long). Format as "ESPG:3857", for example.
The geocoordinates of the origin of the local coordinate system are specified in WG84 latitude, longitude and altitude in the root &lt;COLLADA&gt;&lt;asset&gt;&lt;coverage&gt;
block of data. Specify altitude as height above sea level, i.e., &lt;altitude mode="absolute"&gt;.
The local coordinates of an object are distances in x (East), y (North), z (Up) from the origin. Apply the projection specified by the ESPG code to convert the origin latitude longitude to
the corresponding point in the projection, use that point to map local coordinates to their projection coordinates and then their geocoordinates.</xs:documentation>
</xs:annotation>
<xs:documentation xml:lang="en">EPSG code for a projection to associate local coordinates (x,y,z) with geocoordinates (lat-long). Format as "EPSG:3857", for example.
The geocoordinates of the origin of the local coordinate system are specified in WG84 latitude, longitude and altitude in the root &lt;COLLADA&gt;&lt;asset&gt;&lt;coverage&gt;
block of data. Specify altitude as height above sea level, i.e., &lt;altitude mode="absolute"&gt;.
The local coordinates of an object are distances in x (East), y (North), z (Up) from the origin. The unit
for distance is specified at &lt;COLLADA&gt;&lt;asset&gt;&lt;unit&gt;. Apply the projection specified by the EPSG code to convert the origin's latitude and longitude to
the corresponding point in the projection, use that point to map local coordinates to their projection coordinates and then to their geocoordinates.</xs:documentation>
</xs:annotation>

Copy link
Copy Markdown
Member Author

@cwhanse cwhanse Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikehamer1 fixed the typos and added a sentence about units

Copy link
Copy Markdown
Collaborator

@mikehamer1 mikehamer1 Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Quick work. The changes look good. I think it's good to merge - at least from my point of view.

</xs:element>
<xs:element name="boundary" type="collada:sidref_type" minOccurs="0">
<xs:annotation>
<xs:documentation xml:lang="en">SIDREF for a COLLADA instance_geometry describing the project boundary.</xs:documentation>
Expand Down