Why are Texture filenames not stored with full (relative) path? about 3dcitydb HOT 13 CLOSED

The world files are parsed during import and the contained information about the texture projection goes into the database (column GT_ORIENTATION and GT_REFERENCE_POINT of table SURFACE_DATA). The idea is to re-create the world files from this information at export time so that the original world files are not needed any more.

However, it seems that the export of world files is broken currently. Thanks for pointing to this issue. Needs to be fixed.

from 3dcitydb.

Sorry, my previous answer is not fully correct. Yes, the world files are parsed and stored in SURFACE_DATA. But during export, the values stored in GT_ORIENTATION and GT_REFERENCE_POINT are written to the attributes <app:referencePoint> and <app:orientation> of the <app:GeoreferencedTexture> element. So there is no need to write additional world files because the texture mapping is contained in the <app:GeoreferencedTexture> element itself.

Just tested this with the official CityGML 2.0 test dataset available here. Note that there is both a version using world files and a version using <app:referencePoint> and <app:orientation> of this dataset. So you can use this dataset to compare both options. The dataset is also discussed in annex G.7 of the CityGML 2.0 specification document.

So no bug. And no need to store full (relative) paths to the texture files.

from 3dcitydb.

Our CityGML file used unescaped backslashes as directory separators. In this situation the texture images are loaded correctly, but world files not. Unfortunately we are still using 3dcitydb 3.1...

from 3dcitydb.

Can you share (parts of) your CityGML file for debugging? If you prefer, please send it per email to me.

from 3dcitydb.

Just using the testdataset from here copying the ground_winter.tif and ground_winter.tfw to a folder (Textures) and using a backslash as delimiter:

<app:GeoreferencedTexture> <app:imageURI>Textures\ground_winter.tif</app:imageURI> <app:wrapMode>none</app:wrapMode> <app:target>#ground</app:target> <app:target>#lod1RoofPoly1</app:target> <app:target>#lod2RoofPoly1</app:target> <app:target>#lod2RoofPoly2</app:target> </app:GeoreferencedTexture>

should show the mentioned behavior.

from 3dcitydb.

Tested on a Windows machine with version 3.1 of 3DCityDB and Importer/Exporter and works fine. Are you using a different OS?

from 3dcitydb.

I see that the platform-specific seperator is used:
https://github.com/3dcitydb/importer-exporter/blob/impexp-v3.1.0/src/org/citydb/modules/citygml/importer/database/xlink/resolver/XlinkWorldFile.java#L107

Usually one can safely always store and use the forward slash as this is handled correctly under Linux, Windows and Mac. But I have been unable to find documentation on this from Oracle. According to this StackOverflow article:
https://stackoverflow.com/questions/2417485/file-separator-vs-slash-in-paths
It is a feature of the windows-nt layer that it also handles /.

We are running on linux with a gml file created under windows.

Generally I would specify in the GML-Standard that only one seperator is valid for paths (e.g. /). Just to be more strict on that side.

And yet, this would not resolve our issue. I do not see any problem in the code of the importer in XlinkWorldFile.java. Maybe the xlink.getFileURI(); from DBXlinkTextureFile is already messing up somewhere? I will run the code in a debugger and see if I can find the culprit.

from 3dcitydb.

xlink.getFileURI() returns the image URI as stored in the file, so with backslash in your case. Afterwards, a File object is built from this URI. I suppose this fails under Linux. Backslashes should be replaced by forward slashes before returning the URI. I will check to confirm.

Btw, when exporting files, the Importer/Exporter should already use forward slashes on any platform. Or have you created your CityGML file with this tool as well?

from 3dcitydb.

Nope, created externally. And sure enough after 'fixing' the paths-seperators in the GML file the world files were found correctly. I will report back in 10mins with my debug findings. :)

from 3dcitydb.

So, in https://github.com/3dcitydb/importer-exporter/blob/impexp-v3.1.0/src/org/citydb/modules/citygml/importer/database/xlink/resolver/XlinkWorldFile.java :

Line 77, getFileURI() returns the entry from the gml file if I understood that correctly. That entry is a relative path in our case with a subfolder separated by a backslash
Storing that into a file object and using 'getPath()' method should convert it to a path with the correct path separators according to https://docs.oracle.com/javase/7/docs/api/java/io/File.html#getPath%28%29
But we have a relative path. A file called 'thisIsOne\Filename.txt' is a valid file on Linux and not necessarily a subfolder. So getPath() correctly converts it by just escaping the blackslash to thisIsOne\Finename.txt - it cannot really distinguish between a filename and subfolder+file when just having a relative path.

On line 108 this gets reassembled to:
/home/draget/foo/bar/GML_Testdatensatz/appearance/using-worldfile/Textures\ground_winter.tfw where worldFile.exists() returns false on. Boom. (Tho, of course this works on Windows where the default seperator is \ anyways!)

The relative path could denote a filename containing a backslash (possible on unix) or a subfolder with a file… I guess it has to be specified in the standard (could not find it in the 3dcitydb docs) that it should always use / and we can tell our external source that they deliver broken .gml files. :)
But of course on Windows it is impossible to create a relative path with a backslash.

So a fix could be to bluntly replace all backslash () in paths parsed with a slash (/) (in org.citydb.modules.citygml.common.database.xlink getFileURI maybe?). This way it would only limit the Unix users not to create any paths with backslashes in the name - nothing really common and the importer would be able to parse both versions :-)

from 3dcitydb.

Thanks for your report. For texture image files, backslashes are already replaced with slashes. So I will apply this approach to the handling of world files as well. I will update this issue as soon as a fix is available.

from 3dcitydb.

I see our user doing some 'linux-tests' and then providing single files called 'Texture_A\B.jpg' in the future… xD (not serious)

from 3dcitydb.

Fixed in Importer/Exporter tool (see here).

from 3dcitydb.