Topics

1

Bug Reports / Metashape EPSG:3857 not recognized by gdal2tiles

« on: February 17, 2022, 04:01:19 PM »

Dear,

When trying to tile a raster exported by Metashape in EPSG::3857 (WGS 84 / Pseudo-Mercator), gdal2tiles (https://gdal.org/programs/gdal2tiles.html) errors because of the included CRS information is unexpected.

ERROR 6: Cannot find coordinate operations from `ENGCRS["WGS 84 / Pseudo-Mercator",EDATUM[""],CS[Cartesian,2],AXIS["easting",east,ORDER[1],LENGTHUNIT["metre",1]],AXIS["northing",north,ORDER[2],LENGTHUNIT["metre",1]],ID["EPSG",3857]]' to `EPSG:3857'

Do you have any idea why the CRS info in the metashape tif is not read as EPSG:3857 (https://epsg.io/3857) but as a ENGCRS which seems weird?

Thank you in advance
Feel free to let me know if this is a gdal issue

2

Bug Reports / Regression in Pointcloud 3DTiles tileset data

« on: October 11, 2021, 03:39:01 PM »

When updating from 1.6.3 to 1.7.5 we noticed the following regression, especially the height is weird.
Expected

Code: [Select]

{'Height': {'maximum': 586.442 ± 5.9e-04, 'minimum': 406.613 ± 4.1e-04},
 'Latitude': {'maximum': 0.7694819644872486 ± 7.7e-07,
              'minimum': 0.7692585288653095 ± 7.7e-07},
 'Longitude': {'maximum': -2.0872437834475623 ± 2.1e-06,
               'minimum': -2.0874694308012236 ± 2.1e-06}}
Actualy

Code: [Select]

{'Height': {'maximum': -6356138.153753753, 'minimum': -6356339.057442965},
 'Latitude': {'maximum': 1.5611652318912046, 'minimum': 1.5359569979858492},
 'Longitude': {'maximum': 1.8649031691950797, 'minimum': -3.046626475879601}}

Our flow is: importPoints, exportPoints(PointsFormatCesium)

Is there a relevant changelog available for what could affect this?

3

Bug Reports / RuntimeError: Can't decompress depth

« on: October 08, 2021, 04:30:48 PM »

We're processing 2 completely different projects using the python API. In 1.6.3 this worked, but in 1.7.4 and 1.7.5 these seem to fail with the following code and logs:

Code: [Select]

openexr error: Error reading pixel data from image file "openexr". Unexpected tile x coordinate.
openexr error: Error reading pixel data from image file "openexr". Unexpected tile x coordinate.
openexr error: Error reading pixel data from image file "openexr". Unexpected tile x coordinate.
openexr error: Error reading pixel data from image file "openexr". Unexpected tile x coordinate.
Traceback (most recent call last):
chunk.buildDenseCloud(point_colors=True,progress=XXX)
RuntimeError: Can't decompress depth


4

Bug Reports / exportPoints crashing with local path

« on: October 08, 2021, 02:14:26 PM »

The following code snippet displays the error which seems to be a regression somewhere between 1.6.3 and 1.7.4.

Code: [Select]

    doc = Metashape.Document()
    doc.addChunk()
    doc.chunk.crs = Metashape.CoordinateSystem("EPSG::3857")
    doc.save("PSP.psx")

    doc.chunk.importPoints(las_path, crs=Metashape.CoordinateSystem("EPSG::3857"))

    doc.chunk.exportPoints(os.path.abspath("test1.zip"), format=Metashape.PointsFormat.PointsFormatCesium)
    print('ok1')
    doc.chunk.exportPoints("test2.zip", format=Metashape.PointsFormat.PointsFormatCesium)
    print('ok2')

Which errors with the following logs

Code: [Select]

ExportPoints: path = /ABS/test1.zip, format = PointsFormatCesium
point cloud size: 1065 points
ok1
ExportPoints: path = test2.zip, format = PointsFormatCesium
Traceback (most recent call last):
  File "XXX.py", line 19, in <module>
    doc.chunk.exportPoints("test2.zip", format=Metashape.PointsFormat.PointsFormatCesium)
OSError: Can't create directory: No such file or directory (2):

Thanks for any support

5

Bug Reports / Standalone version needs libGL.so

« on: January 04, 2021, 03:06:26 PM »

Code: [Select]

FROM python:3

RUN wget https://s3-eu-west-1.amazonaws.com/download.agisoft.com/Metashape-1.7.0-cp35.cp36.cp37.cp38-abi3-linux_x86_64.whl

RUN python3 -m pip install Metashape-1.7.0-cp35.cp36.cp37.cp38-abi3-linux_x86_64.whl

SHELL ["/bin/bash", "-c"]

CMD 'python3'

Running `import Metashape` in the previously specified docker container results in

Code: [Select]

>>> import Metashape
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/site-packages/Metashape/__init__.py", line 3, in <module>
    from .Metashape import *
ImportError: libGL.so.1: cannot open shared object file: No such file or directory


6

Bug Reports / ExportRaster wkt is different to the projection CRS

« on: December 10, 2020, 12:17:02 PM »

Dear,

I have noticed a problem with EPSG 27563.
When I use the console to print `Metashape.CoordinateSystem('EPSG::27563').wkt` I get:

Code: [Select]

`'PROJCS["NTF (Paris) / Lambert Sud France",GEOGCS["NTF (Paris)",DATUM["Nouvelle Triangulation Francaise (Paris)",SPHEROID["Clarke 1880 (IGN)",6378249.2,293.466021293627,AUTHORITY["EPSG","7011"]],TOWGS84[-168,-60,320,0,0,0,0],AUTHORITY["EPSG","6807"]],PRIMEM["Paris",2.33722917,AUTHORITY["EPSG","8903"]],UNIT["grad",0.01570796326794895,AUTHORITY["EPSG","9105"]],AUTHORITY["EPSG","4807"]],PROJECTION["Lambert_Conformal_Conic_1SP",AUTHORITY["EPSG","9801"]],PARAMETER["latitude_of_origin",49],PARAMETER["central_meridian",0],PARAMETER["scale_factor",0.999877499],PARAMETER["false_easting",600000],PARAMETER["false_northing",200000],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AUTHORITY["EPSG","27563"]]'`
But when I export a raster (Dem for example), gdalinfo reports a different wkt:

Code: [Select]

Coordinate System is:
BOUNDCRS[
    SOURCECRS[
        PROJCRS["NTF (Paris) / Lambert Sud France",
            BASEGEOGCRS["NTF (Paris)",
                DATUM["Nouvelle Triangulation Francaise (Paris)",
                    ELLIPSOID["Clarke 1880 (IGN)",6378249.2,293.466021293627,
                        LENGTHUNIT["metre",1]]],
                PRIMEM["Paris",2.5969213,
                    ANGLEUNIT["grad",0.0157079632679489]],
                ID["EPSG",4807]],
            CONVERSION["unnamed",
                METHOD["Lambert Conic Conformal (1SP)",
                    ID["EPSG",9801]],
                PARAMETER["Latitude of natural origin",54.4444444444445,
                    ANGLEUNIT["grad",0.0157079632679489],
                    ID["EPSG",8801]],
                PARAMETER["Longitude of natural origin",0,
                    ANGLEUNIT["grad",0.0157079632679489],
                    ID["EPSG",8802]],
                PARAMETER["Scale factor at natural origin",0.999877499,
                    SCALEUNIT["unity",1],
                    ID["EPSG",8805]],
                PARAMETER["False easting",600000,
                    LENGTHUNIT["metre",1],
                    ID["EPSG",8806]],
                PARAMETER["False northing",200000,
                    LENGTHUNIT["metre",1],
                    ID["EPSG",8807]]],
            CS[Cartesian,2],
                AXIS["easting",east,
                    ORDER[1],
                    LENGTHUNIT["metre",1]],
                AXIS["northing",north,
                    ORDER[2],
                    LENGTHUNIT["metre",1]],
            ID["EPSG",27563]]],
    TARGETCRS[
        GEOGCRS["WGS 84",
            DATUM["World Geodetic System 1984",
                ELLIPSOID["WGS 84",6378137,298.257223563,
                    LENGTHUNIT["metre",1]]],
            PRIMEM["Greenwich",0,
                ANGLEUNIT["degree",0.0174532925199433]],
            CS[ellipsoidal,2],
                AXIS["latitude",north,
                    ORDER[1],
                    ANGLEUNIT["degree",0.0174532925199433]],
                AXIS["longitude",east,
                    ORDER[2],
                    ANGLEUNIT["degree",0.0174532925199433]],
            ID["EPSG",4326]]],
    ABRIDGEDTRANSFORMATION["Transformation from NTF (Paris) to WGS84",
        METHOD["Position Vector transformation (geog2D domain)",
            ID["EPSG",9606]],
        PARAMETER["X-axis translation",-168,
            ID["EPSG",8605]],
        PARAMETER["Y-axis translation",-60,
            ID["EPSG",8606]],
        PARAMETER["Z-axis translation",320,
            ID["EPSG",8607]],
        PARAMETER["X-axis rotation",0,
            ID["EPSG",8608]],
        PARAMETER["Y-axis rotation",0,
            ID["EPSG",8609]],
        PARAMETER["Z-axis rotation",0,
            ID["EPSG",8610]],
        PARAMETER["Scale difference",1,
            ID["EPSG",8611]]]]

The preferred wkt would just be the PROJCRS and not the full BOUNDCRS. Since this BOUNDCRS is confusing GDAL (https://github.com/OSGeo/gdal/issues/3273 and https://github.com/OSGeo/gdal/pull/2370 )

Is there a way to remove this BOUNDCRS?
And how come the wkt is different in the export?

Many thanks

7

Python and Java API / Different behaviour between CoordinateSystem.transform and gdaltransform

« on: October 01, 2020, 01:01:10 PM »

The height is transformed in Metashape but I have no idea according to which parameters or how to disable this.
Would someone be able to explain why this difference occurring?

Code: [Select]

Metashape.CoordinateSystem.transform([2,51,40], Metashape.CoordinateSystem('EPSG::4326'), Metashape.CoordinateSystem('EPSG::31370'))
Out[25]: 2020-10-01 11:55:46 Vector([-16249.273071516975, 190403.64215950316, -1.150523648123559])


Code: [Select]

gdaltransform -s_srs epsg:4326 -t_srs epsg:31370
2 51 40
-16249.1994904166 190403.660128514 40

8

General / Unknown vertical CRS

« on: September 28, 2020, 02:35:27 PM »

Dear,

We have some projects with markers in an unknown vertical CRS and a local horizontal CRS. We would like to generate an export EPSG:4326 but with the heights unchanged so that the heights of the export in EPSG:4326 is the same as the height export of the local EPSG. Is this possible?

Many thanks

9

Python and Java API / Change vertical CS

« on: September 27, 2020, 09:34:57 PM »

Hello all,

I want to be able to export a DEM in the local EPSG and in EPSG:4326 but with the same heights. Is it possible to create a projection like EPSG:4326 but where I set the vertical EPSG to the one used in the local EPSG?

Many thanks

10

Python and Java API / chunk.crs being reset by AddPhotos

« on: September 25, 2020, 11:05:01 AM »

Dear,

I am confused for the usage of the chunk.crs. The following snippet and output shows the reset chunk.crs by addPhotos:

Code: [Select]

print(str(chunk.crs))
chunk.crs = Metashape.CoordinateSystem('EPSG::32633')
print(str(chunk.crs))
chunk.addPhotos(image_paths)
print(str(chunk.crs))


Code: [Select]

<CoordinateSystem 'WGS 84 (EPSG::4326)'>
<CoordinateSystem 'WGS 84 / UTM zone 33N (EPSG::32633)'>
AddPhotos
<CoordinateSystem 'WGS 84 (EPSG::4326)'>

Related to this weird behaviour, could you explain what the chunk.crs influences? Currently it seems that when setting it to the local crs of the markers, I get more memory errors or bad_allocs further in the process.
We also do all build steps in this local crs, as a last question, does this make sense or when do you suggest to use the `projection` parameter for steps such as buildDem?

Thanks a lot for your help
Looking forward to your explanations

11

General / Potree generation parameters

« on: August 31, 2020, 08:51:51 PM »

Dear,

We would like to convert a lot of our projects to Potree. Preferably we would not do this again through Metashape.
Could you provide the options Metashape uses for the Potree conversion to allow us to generate the same output as the Metashape zip Potree? (https://github.com/potree/PotreeConverter/tree/1.7#potreeconverter-usage)

Thanks in advance