FAQ and Troubleshooting

Here are some common questions and issues. Please feel free to open an issue if it doesn’t solve your problem.

My tileset position is incorrect

This is a common issue with all GIS software and data. Let’s go through some common things to check.

Check your input file CRS

Does your input file headers or metadata includes such information? For pointclouds, you can check with pdal info --summary. For other type of data, please use relevant tools. Qgis is often very useful for this.

If it does, is this information correct?

Tools like QGis or “Quelle est cette projection?” website (in French) can be very useful to check if the information is correct, or simply to find the correct CRS if the information is simply not there.

Check your output CRS

This part depends of the use of your converted tileset:

Cesium scene is in EPSG:4978, you need to pass--srs_out 4978 in your py3dtiles convert invocation, or use crs_out=4978 in your API usage
for other viewers supporting several scene CRS, like giro3d, you should use the scene CRS.

Does your data use traditional coordinates ordering instead of the CRS definition?

GDAL documentation has a really good explanation about this issue.

In summary, CRS definitions includes an axis ordering. For instance EPSG:4326 axis order is defined as latitude-longitude. EPSG:2326 is defined as northing - easting. However, the traditional GIS order still used by at least qgis, postgis and pdal for instance is “longitude - latitude”, or “easting - northing”, whatever the CRS definition mandates. Some data also uses this convention.

Py3dtiles has made the choice to use the same default as proj itself: strictly honour the CRS definition order by default. We do offer an escape hatch to support the other use case (like pyproj). If this is your case, please use --pyproj-always-xy (cli usage) or pyproj_always_xy=True (API usage).

Please also see the FAQ part of pyproj about axis order.

I’ve checked everything, but my data is still at the wrong position

Please open an issue, including what you checked and the results so far.

When converting a las/laz files, the resulting tiles are completely black

Please check the RGB components of your file (with pdal info <file> for instance). If the Red, Green and Blue value are all between 0 and 255, you need to either:

use the parameter color_scale when calling convert or the flag --color_scale=256 when using py3dtiles convert from the cli, possibly after checking the whole file with pdal or laspy for instance (this can be costly)
fix your las or ask the producer to fix it.

To make a long story short: the las spec mandates that color components are 2 bytes each. This means values should be between 0 and 65535. For instance, the red color should be (65535, 0, 0), not (255, 0, 0). However quite a few las are built using a range from 0 to 255 (probably because tools implementors misunderstood the spec somewhere and use only 8 bits color components).

Before v6, we attempted to detect if the file was correctly saved, but of course, it wasn’t 100% effective and we had some false positive, and even trouble if several files were given in the command-line. So since py3dtiles v6, we made the choice to consider that las are correct by default (so R,G,B values from 0 to 65535), with the possibility to fix this via the color_scale parameter.