create local_projection

[cwhanse]

Adds a tag to for the EPSG code specifying the projection for local coordinates.

[ross-planted]

Apologies for not bringing this up in the meeting this morning, but I've been sick and was having a coughing attack on mute and having trouble speaking!

One main note came to mind is that I think it might be not entirely clear whether coordinates are "in" a certain state plane/UTM zone/other EPSG code coordinate system. By that I mean that coordinates in a state plane coordinate system or UTM zone are usually very large and define the location in question by themselves. For example, the statue of liberty is at x=296,238 meters (easting), y=58,026 meters (northing) in a New York state plane coordinate system (EPSG:3627) as that coordinate system has its own origin that those coordinates are defined against.

In the meeting today it seemed like the suggestion was still to use local x/y/z coordinates that are defined relative to some custom origin for the site, which I think might cause some confusion. If we aren't asking the softwares that define these x/y/z positions to actually convert those values to the full (likely large) EPSG coordinates, I don't think the EPSG code listed would actually be providing any additional information. Let me know if I'm thinking about it wrong though or if the intent is that all coordinates for the site would actually be true coordinates in the given EPSG coordinate system though.

[ross-planted]

[Minor typo]

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

[cwhanse]

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

[ross-planted]

@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.

[mikehamer1]

There is still the typo that Ross noted earlier: 3 instances of 'ESPG' that should be 'EPSG'. Worth getting right to avoid confusion!

The updated text is much clearer and well explained. The only point of confusion may be units, which may be worth explicitly mentioning. The local coordinates will be in the units defined by the section as per the Collada specification (e.g., in centimeters). These units may be different to the default units of the EPSG projection (e.g., UTM projections are in meters, some US projections are in feet) so will need converting to the EPSG projection units before being added to the origin point in the projection.

[cwhanse]

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>

[cwhanse]

@mikehamer1 fixed the typos and added a sentence about units

[mikehamer1]

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