liblas 1.6.0b3, Schema class does not have HasColor() [RESOL

[dktrudgett]

I've tried to build CloudCompare using CodeBlocks and minGW, and I
found that it wouldn't build initially, so I tried updating the libLAS
and Boost libraries. When I did the build with libLAS 1.6.0b3, there
was a compilation error in fileIO/LASFilter.cpp, line 166:

||=== qCC, release ===|
C:\svnwork\local_cloud-compare-aam-fork\qCC\fileIO\LASFilter.cpp||In member function 'virtual CC_FILE_ERROR LASFilter::loadFile(const char*, ccHObject&)':|
C:\svnwork\local_cloud-compare-aam-fork\qCC\fileIO\LASFilter.cpp|166|error: 'const class liblas::Schema' has no member named 'HasColor'|
||=== Build finished: 1 errors, 0 warnings ===|


The line in question is:

hasColor = header.GetSchema().HasColor();


Looking at the libLAS source code, it does indeed appear that HasColor
was removed from the class.

I'm not sure if this was done by mistake by the libLAS people (as they
have altered a public interface without any notification), or whether
the CloudCompare needs to be amended in some way.

In the meantime, do you know which is the latest version of libLAS
that can be used to build CloudCompare?

Thanks,
David

[daniel]

Hello,

I wonder why the initial project couldn't compile: are you trying to do it with a 64 bits compiler maybe?

Otherwise, we haven't modified the liblas source, so the removal of the "HasColor" method must come from their side (isn't there an equivalent?).

If I remember well, the liblas version that is shipped with CloudCompare is at least 1.6.0 (we did it 2 or 3 months ago).

Daniel

[dktrudgett]

Hi Daniel,

I can't remember why it didn't compile originally. I'm just trying an ordinary 32-bit build. I might try it again now that I'm more familiar with the process.

I also don't know what's happening with liblas. It seems to be a mistake on their part, as they have just dropped HasColor() and one other method out of the public interface of the Schema class without any explanation in the source code or release notes (that I could see). I haven't contacted them about it yet (if it's a mistake, they'll realise it soon enough anyway).

Thanks for your reply. I'll try a clean build from the original source again and see how I go. If there are any problems, I'll let you know.

Regards,
David

[dktrudgett]

Hi Daniel,

I didn't need to do a rebuild from scratch after all. I received a reply from a liblas developer, Howard Butler, who said that the C++ API is in a state of flux for the 1.6.0 release, and that the HasColor() and HasTime() methods of the Schema class were removed.

I made the following change to LASFilter.cpp in order to accommodate the change in the liblas C++ API:

Code: Select all

@@ -140,6 +140,22 @@
     return CC_FERR_NO_ERROR;
 }
 
+
+bool schemaHasColour(const liblas::Schema theSchema) {
+    bool myColorExists = false;
+    try {
+        liblas::Dimension const& red = theSchema.GetDimension("Red");
+        liblas::Dimension const& green = theSchema.GetDimension("Green");
+        liblas::Dimension const& blue = theSchema.GetDimension("Blue");
+        myColorExists = true;
+
+    } catch (std::runtime_error const&)
+    {
+    }
+    return myColorExists;
+}
+
+
 CC_FILE_ERROR LASFilter::loadFile(const char* filename, ccHObject& container)
 {
     //opening file
@@ -163,7 +179,7 @@
         ccConsole::Print("[LAS FILE] %s - signature: %s",filename,header.GetFileSignature().c_str());
 #endif
 
-        hasColor = header.GetSchema().HasColor();
+        hasColor = schemaHasColour(header.GetSchema());
 
         nbOfPoints = header.GetPointRecordsCount();
     }

This method of determining if the Schema has colour dimensions was suggested by Howard Butler.

With that change, qCC builds and runs, and loads and displays a LAS file.

Regards,
David

[daniel]

Ok, thanks for the suggestion!

Code has been changed accordingly.

However, I had to use 'DimensionPtr' instead of 'Dimension' with the version of liblas used by the actual qCC package.

Daniel