Reading a borehole gef file gives parse error

We are trying to load a borehole GEF file using Viktor. Using the source code of the GeoTools app, we made the code, however we get an error while parsing the GEF file. The error is as follows:

Traceback (most recent call last):
File “viktor_connector\connector.pyx”, line 323, in connector.Job.execute
File “viktor\core.pyx”, line 1817, in viktor.core._handle_job
File “viktor\core.pyx”, line 1804, in viktor.core._handle_job._handle_params_from_file
File “viktor\core.pyx”, line 264, in viktor.core.ParamsFromFile._wrapper
File “C:\DevOps\Python.ParametricDesign\WegenTool\app\SharedPackages\ViktorShared\EntityTypes\geffile_database\controller.py”, line 48, in process_file
bore_data = gefFileReader().read_gef_file(file, gef_type, self.encoding)
File “C:\DevOps\Python.ParametricDesign\WegenTool\app\SharedPackages\ViktorShared\EntityTypes\geffile_database\gef_file_processor_functions.py”, line 31, in read_gef_file
gef_data = munchify(bore_file.parse())
File “viktor\geo.pyx”, line 887, in viktor.geo.GEFFile.parse
File “viktor\core.pyx”, line 1453, in viktor.core._post_on_addon_endpoint
viktor.errors.InternalError: An unexpected error occurred

The code we use to read the boreholes (nearly the same code that also works for reading CPT GEF files):

bore_file = GEFFile(file.getvalue(encoding=encoding))
gef_data = munchify(bore_file.parse())

Any what is going wrong?

Test borehole GEF file: B38C0198.gef (2.9 KB)

Hi Vincent,

Welcome to the Community forum! I’ve checked the parser for error messages and found the follow message:

ValueError: could not convert string to float: “‘K’”

The GEF file has non-numeric entries in the table, which is not allowed by our parser it seems. I’m not too well into GEF files to know if this is actually allowed by the specs. Nevertheless, the GEF file would likely succeed our parser when removing the non-numeric columns.

Thank you for the quick reply.

It is not really possible remove the non-numeric columns here because these columns contain the soil type. For a CPT GEF file, the soil types are determined based on the numeric values. For boreholes, the soil types are provided as a separate column.

Hi @Vincentvd,

There are a few things getting mixed up here, so I will try to clear some confusion. As @bvanderhulst corretly states, we offer a VIKTOR GEFParser. This parser can be accessed by:

  1. creating a GEFFile object that is in the SDK under viktor.geo.GEFFile
  2. calling the parse() method on that object

This sends the contents of that GEFFile object to our parser, and returns a SoilLayout object. This parser works for cone penetration tests, so a CPT measurement in .gef format.

As you probably know: you are not talking about a CPT here, but Borehole data (also in .gef format). GeoTools is able to deal with these Borehole gef files as well. I am however not 100% sure if the code for that parser is included in the GeoTools source code.

In any case: it does look like you are inadvertently calling the CPT gef parser, based on the stacktrace you included in your first post.

Perhaps we can arrange a call via teams to look at your code together. Explaining the Borehole parser by text will be a bit confusing, as we wrote a wrapper around the GEFFile object and there are a lot of shared class names.

Thank your for this explanation, now I see what you mean. A colleague already gave me the code of the Geotools app (a bit older version but it should work). I had a closer look at that code and now I see what you mean with the 2 parsers. The naming was indeed very similar.

If the GeoTools code still works then I should be able to get it working. I will give it another try.

1 Like

Sounds good, let me know if you get it working! If not, we can look into it.

Just a small follow-up question. Are we allowed to fully copy most parts of the geotools code? There is no copyright file or something similar in that code so I just want to check.

Hi Vincent,

Yes, you are. We supplied you with the code so that you can build/extend on top of it, feel free to do so.

I got everything working except for a small part, filter_layers_on_thickness:

soil_layout_user = deepcopy(soil_layout)
# TODO - this 200 is harcoded, should be taken from params
soil_layout_user.filter_layers_on_thickness(200, merge_adjacent_same_soil_layers=True)
soil_layout_user = convert_soil_layout_from_mm_to_m(soil_layout_user)

For CPT files, this works fine but for Boreholes GEF files, I keep getting the error below in the viktor modules. Disabling the third line in the snippet above makes the code work fine. I can’t trace back the error in VS code so I have no idea what is going wrong. Is this function not supported for borehole GEF files?

Traceback (most recent call last):
File “viktor_connector\connector.pyx”, line 323, in connector.Job.execute
File “viktor\core.pyx”, line 1817, in viktor.core._handle_job
File “viktor\core.pyx”, line 1804, in viktor.core._handle_job._handle_params_from_file
File “viktor\core.pyx”, line 264, in viktor.core.ParamsFromFile._wrapper
File “C:\DevOps\Python.ParametricDesign\WegenTool\app\SharedPackages\ViktorShared\EntityTypes\geffile_database\controller.py”, line 123, in process_file
soil_layout_user.filter_layers_on_thickness(200, merge_adjacent_same_soil_layers=True)
File “viktor\geo.pyx”, line 1708, in viktor.geo.SoilLayout.filter_layers_on_thickness
File “viktor\geo.pyx”, line 1783, in viktor.geo._get_replacement_dict_from_soil_layer_block
IndexError: list index out of range

Hi @Vincentvd,

Nice to read you’ve made some progress. As to your error: it shouldn’t matter that it’s a Borehole GEF file, because the function you’re calling is a method on the SoilLayout object. It does not matter where that SoilLayout came from (a BoreFile or a GEFFile object).

I think the best place to start is the SoilLayout as it exists before you try to filter it. Perhaps you can print it, plot it, or visualize it some other way? There are a number of things that could go wrong here:

  • Perhaps there are no layers >200 mm?
  • Perhaps there are not enough layers to filter?
  • Perhaps the result has only a signle layer and causes some edge-case?