Increase decimal precision of point clouds from 2 to 7 when reprojecting to geographic coordinates

[erobeck]

Feature description

Point clouds reprojected with the Processing Toolbox -> Point cloud data management -> Reproject are rounded to 2 decimal places. That is regardless of the destination SRS.

This makes sense when working with metric Cartesian coordinates (UTM, ECEF, etc.), because most point clouds don't have a precision greater than 1 cm, and using larger scale factors makes LAZ data compression less efficient. But rounding to 2 decimal places when projecting to geographic latitude/longitude is a bad idea, because this corresponds to >1 km at the equator. Data reprojected with this tool is useless.

There are two possible solutions:

1. When transforming to geographic/angular coordinates, preserve 7 decimals (0.0000001) in latitude and longitude, corresponding to ~0.011 m at the equator. (Continue to preserve 2 decimals for Z values if in meters/feet.)
2. Update the form to provide an option for the decimal precision. Default it to 2 decimals, but set it to 7 when choosing a geographic SRS. This will benefit users who don't understand the equivalence, while allowing power users the ability to configure it for individual datasets.

Additional context

Background: I am helping to create a global COPC dataset in ECEF coordinates. Although the SRS is ECEF, the tiles are broken up by 1x1 degree (geocell). QGIS can't visualize ECEF coordinates, so to interact with the data users will need to reproject it. Because of the tile sizes and global extent, most will want to use geographic coordinates.

Summary: At the moment, QGIS cannot work with our data because:

1. ECEF point clouds aren't drawn in the map,
2. the Reproject tool rounds them to ~1 km, and
3. the Export -> Save As...' option doesn't support CRS transform from ECEF (submitted a bug fix).

Fixing 2 by making the decimal precision relative to horizontal units will solve 1 because the reprojected data (when converted to COPC) will render in the map, and it will make 3 unnecessary.

[alexbruy]

I think this should be filled upstream to PDAL and/or wrench repository.

[hobu]

Processing Toolbox -> Point cloud data management -> Reproject are rounded to 2 decimal places.

Is this satisfied by a (three) text box that allows you to explicitly set the XYZ scales of output?

[erobeck]

Is this satisfied by a (three) text box that allows you to explicitly set the XYZ scales of output?

A set of 3 textboxes or drop-downs would satisfy the requirement.

To prevent rookie users from destroying their data, it would be helpful if PDAL/wrench set the default values to [7, 7, 2] when projecting to geographic degrees and [2, 2, 2] when projecting to Cartesian systems. Pro users could modify those to improve compression, but the defaults wouldn't automatically result in loss of accuracy.

[hobu]

To prevent rookie users from destroying their data

😂 I think you are assuming the combination of rookie users and ECEF geospatial data is a thing.

I would worry about believing any units information coming out of the CRS definition to automagically set default scales like this. It's too easy to do silently do the wrong thing. At least with the current default of [2, 2, 2] it is easy to diagnose that all of your data getting aliased into lines.

[erobeck]

Nobody wants ECEF data except for the developers who use it to visualize data in 3D. I am just trying to create a pathway for data users who want to use the data in traditional mapping contexts, while not penalizing them if they fail to understand the difference in precision between different map units.

[hobu]

Nobody wants ECEF data except for the developers who use it to visualize data in 3D.

It is very hard to do 3D things when XY units are not the same as Z. That's what drives the ECEF usage, not just visualization, although any significant visualization-oriented indexing scheme also wants XYZ units to all be the same.

use the data in traditional mapping context

$[2, 2, 2]$ is a perfectly fine default for UTM or any other rectilinear coordinate system configuration. It's really only the $[lon, lat, h]$ configuration that has $[2, 2, 2]$ as a terrible default. So what are the options?

1. Have QGIS detect the single-file input is in geographic and set the scale values in the pdal_wrench operation.
2. Have pdal_wrench-level operation try to determine if any of the input coordinate systems for a selection are geographic and $h$ and set the scales of the operation. Don't give the user the ability to change anything.
3. Have the pdal-level operation determine the coordinate system and set the default accordingly

As the PDAL developer, I think 3 is a no-go. PDAL purposefully doesn't try to be smart with data like this because there are too many scenarios where it will guess the wrong thing and break data. Users have to know their data and what they intend to do. You bring the 🦶 and we give you the 🔫, but we try to ensure that you are the one putting holes in your feet.

Number 1 and 2 have the problem of what to do if there are multiple input data in multiple coordinate systems, but if it is a single file scenario, the file's CRS is geographic, the Z values are $h$, and the units of the output CRS is degrees, $[7, 7, 2]$ would seem a reasonable default. The question is what do you do if that default is a poor one? Do you provide text boxes to override and complicate the interface? I guess so, but if you're doing that, why not just provide the text boxes and default to $[2, 2, 2]$ and give the user the ability to override if they need to without trying to guess?

This is how I get to the position of just giving the user a text box. It's the least complicated thing to maintain, but it puts it on the user and clutters up the interface.

[erobeck]

I understand that geographic coordinates really aren't optimized for octree tiling, let alone visualization. Ultimately, these are just glorified 3D Point vector files, although COPC enables faster map loading than SHP or GPKG.

Your analysis of options is sound. While I would prefer a background "safety" check for non-savvy users, I will provide instructions on decimal precision in our product guide. So setting the defaults to [2, 2, 2] independent of CRS will work.