You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, most/all commands of the 3D tiles tools can both read from different sources, and and write to different targets. For example, running a command with
... --input example.3dtiles --output C:\directory
will read the 3DTILES file, perform the desired operation, and write the result to the target directory.
The detection of the input/output type is made based on the file extension. This is not the most technically reliable approach, and raises the question about how to handle input files that do not have an extension. One reason for using this approach was the simplicitly of the command line interface.
But alternatives could be considered here.
For the input side, one could try to examine the input data. One could check whether the input is...
a directory (and assume that the tileset file is called tileset.json)
a JSON file (for the tileset JSON)
a 3DTILES
a 3TZ file
Both 3DTILES and 3TZ will require examining some "magic header", assuming that it is possible to detect SQLite and ZIP based on that.
For the output side, one could consider adding a command line option like --outputType 3DTILES/DIRECTORY/3TZ or so. But requiring this would be a bit inconvenient for the CLI, comparing --output file.3dtiles
to --output file --outputType 3DTILES
The text was updated successfully, but these errors were encountered:
Right now, most/all commands of the 3D tiles tools can both read from different sources, and and write to different targets. For example, running a command with
... --input example.3dtiles --output C:\directory
will read the 3DTILES file, perform the desired operation, and write the result to the target directory.
The detection of the input/output type is made based on the file extension. This is not the most technically reliable approach, and raises the question about how to handle input files that do not have an extension. One reason for using this approach was the simplicitly of the command line interface.
But alternatives could be considered here.
For the input side, one could try to examine the input data. One could check whether the input is...
Both 3DTILES and 3TZ will require examining some "magic header", assuming that it is possible to detect SQLite and ZIP based on that.
For the output side, one could consider adding a command line option like
--outputType 3DTILES/DIRECTORY/3TZ
or so. But requiring this would be a bit inconvenient for the CLI, comparing--output file.3dtiles
to
--output file --outputType 3DTILES
The text was updated successfully, but these errors were encountered: