VFK: Support MultiPolygons in the BUD block (fixes #11696)

[petr-zima]

MultiPolygons with more than one component may appear in the BUD block, but never in the PAR block. We can confirm that real world data from the Czech Office for Surveying, Mapping and Cadastre comply to that.

For backwards compatibility, using MultiPolygons in the BUD block is controlled by a new configuration option OGR_VFK_DB_BUD_MULTI which is turned off by default.

What does this PR do?

What are related issues/pull requests?

Tasklist

• AI (Copilot or something similar) supported my development of this PR
• Make sure code is correctly formatted (cf pre-commit configuration)
• Add test case(s)
• Add documentation
• Updated Python API documentation (swig/include/python/docs/)
• Review
• Adjust for comments
• All CI builds and checks have passed
• ADD YOUR TASKS HERE

Environment

Provide environment details, if relevant:

• OS:
• Compiler:

[coveralls]

coverage: 71.676% (+0.09%) from 71.583%
when pulling 214852b on petr-zima:master
into c8902fd on OSGeo:master.

[rouault]

For backwards compatibility, using MultiPolygons in the BUD block is controlled by a new configuration option OGR_VFK_DB_BUD_MULTI which is turned off by default.

@petr-zima Do we really need that complication? @landam thoughts ?

Otherwise if you maintain the new config option, you also need to run python ../scripts/collect_config_options.py to update port/cpl_known_config_options.h
And you also need to fix the code formatting. See https://gdal.org/en/stable/development/dev_practices.html#commit-hooks

[ctoney]

@petr-zima, if you do add that configuration option, shouldn't there also be test cases for it using MultiPolygon in autotest/ogr/ogr_vfk.py?

[rouault]

@petr-zima Do we really need that complication? @landam thoughts ?

by that I meant: can't we always expose as multipolygons ?

[petr-zima]

by that I meant: can't we always expose as multipolygons ?

That would be backwards incompatible and could possibly break other users' worflows. Introducing the config option, we are on the safe side. You can think about changing the default value or getting rid of the option altogether in future version in order to give users time to adapt.