introduce OGRLayer::FindFieldIndex() / OGR_L_FindFieldIndex() to lookup ... #23
Conversation
…up potentially laundered field names
|
At first thought, your idea makes sense, but as it extends the API, it would be better if you could summarize it into a (mini) RFC to get broader feedback on it. I could imagine that FindFieldIndex() could have a boolean argument approx to determine if the lookup must be strict or try approximate variations. For your use case, perhaps the quite new "-fieldmap identity" option of ogr2ogr can also work if both your NAS and Oracle layers have the same fields in the same order. |
…to ogr2ogr to allow it
Done. See http://trac.osgeo.org/gdal/wiki/rfc42_find_laundered_fields
Implemented.
I doubt it. The NAS driver derives the fields from it's XML input and the attributes in that input are often optional - and IIRC there more than 100 different tables/elements/layers. |
|
Great. I've just noticed a mismatch in the doc of a12311e . + If bExact match is set and the field doesn't exists in the given form the + driver might apply some changes to make it match, like those it might do if + the layer was created (eg. like LAUNDER in the OCI driver). This should rather be "if bExactMatch is set to FALSE and..." Apart from this, you can call for a review of the RFC by emailing gdal-dev@ and if no particular remarks are emitted within a few days, call for a vote on it. |
Fixed in fdc838c. Thanks.
Done. http://lists.osgeo.org/pipermail/gdal-dev/2013-October/037188.html |
|
Implemented in http://trac.osgeo.org/gdal/changeset/26572 and following commits |
This should perhaps help fixing, or at least workarounding, the following issue seen randomly on the gcc52_stdcpp14_sanitize Travis-CI target. e.g on https://api.travis-ci.org/v3/job/351015753/log.txt Running gdrivers/gdalhttp.py... TEST: http_1 ... success ERROR 1: Range downloading not supported by this server! ERROR 1: Request for 8-407 failed TEST: http_2 ... success TEST: http_3 ... success ERROR 4: `/vsicurl/ftp://download.osgeo.org/gdal/data/gtiff/utm.tif' not recognized as a supported file format. TEST: http_4 ... HTTP service for ftp://download.osgeo.org/gdal/data/gtiff/utm.tif is down (HTTP Error: ftp error: 425 Security: Bad IP connecting.) cannot open URL skip TEST: http_5 ... success ERROR 1: JSON parsing error: unexpected character (at offset 0) TEST: http_6 ... success ==31274==WARNING: AddressSanitizer failed to allocate 0x62d00019040f bytes ==31274==AddressSanitizer's allocator is terminating the process instead of returning 0 ==31274==If you don't like this behavior set allocator_may_return_null=1 ==31274==AddressSanitizer CHECK failed: ../../.././libsanitizer/sanitizer_common/sanitizer_allocator.cc:147 "((0)) != (0)" (0x0, 0x0) #0 0x7f3f527259f4 (/home/travis/build/OSGeo/gdal/install-gcc-5.2.0/lib64/libasan.so.2.0.0+0x9e9f4) #1 0x7f3f5272a453 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/home/travis/build/OSGeo/gdal/install-gcc-5.2.0/lib64/libasan.so.2.0.0+0xa3453) #2 0x7f3f526a7461 (/home/travis/build/OSGeo/gdal/install-gcc-5.2.0/lib64/libasan.so.2.0.0+0x20461) #3 0x7f3f527286d5 (/home/travis/build/OSGeo/gdal/install-gcc-5.2.0/lib64/libasan.so.2.0.0+0xa16d5) #4 0x7f3f526acb3d (/home/travis/build/OSGeo/gdal/install-gcc-5.2.0/lib64/libasan.so.2.0.0+0x25b3d) #5 0x7f3f526adbd5 (/home/travis/build/OSGeo/gdal/install-gcc-5.2.0/lib64/libasan.so.2.0.0+0x26bd5) #6 0x7f3f5271e32e in realloc (/home/travis/build/OSGeo/gdal/install-gcc-5.2.0/lib64/libasan.so.2.0.0+0x9732e) #7 0x7f3f3ea2a940 in VSIRealloc /home/travis/build/OSGeo/gdal/gdal/port/cpl_vsisimple.cpp:814 #8 0x7f3f3e8e3958 in VSICurlHandleWriteFunc /home/travis/build/OSGeo/gdal/gdal/port/cpl_vsil_curl.cpp:839 #9 0x7f3f2ff61442 in Curl_client_write (/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4+0x16442) #10 0x7f3f2ff8bc46 in Curl_pp_readresp (/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4+0x40c46) #11 0x7f3f2ff621ab (/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4+0x171ab) #12 0x7f3f2ff64546 (/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4+0x19546) #13 0x7f3f2ff61bbf (/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4+0x16bbf) #14 0x7f3f2ff61cd1 (/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4+0x16cd1) #15 0x7f3f2ff6776b in Curl_disconnect (/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4+0x1c76b) #16 0x7f3f2ff7c170 in curl_multi_cleanup (/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4+0x31170) #17 0x7f3f3e902c6b in ClearCache /home/travis/build/OSGeo/gdal/gdal/port/cpl_vsil_curl.cpp:2913 #18 0x7f3f3e8fc9f7 in ~VSICurlFilesystemHandler /home/travis/build/OSGeo/gdal/gdal/port/cpl_vsil_curl.cpp:2564 #19 0x7f3f3e8fcf23 in ~VSICurlFilesystemHandler /home/travis/build/OSGeo/gdal/gdal/port/cpl_vsil_curl.cpp:2569 #20 0x7f3f3e9e4a02 in VSIFileManager::~VSIFileManager() /home/travis/build/OSGeo/gdal/gdal/port/cpl_vsil.cpp:1805 #21 0x7f3f3e9e5baa in VSICleanupFileManager /home/travis/build/OSGeo/gdal/gdal/port/cpl_vsil.cpp:1966 #22 0x7f3f3e533e42 in GDALDriverManager::~GDALDriverManager() /home/travis/build/OSGeo/gdal/gdal/gcore/gdaldrivermanager.cpp:262 #23 0x7f3f3e53418d in GDALDriverManager::~GDALDriverManager() /home/travis/build/OSGeo/gdal/gdal/gcore/gdaldrivermanager.cpp:329 #24 0x7f3f3e53a14e in GDALDestroyDriverManager /home/travis/build/OSGeo/gdal/gdal/gcore/gdaldrivermanager.cpp:898 #25 0x7f3f27794ea3 in ffi_call_unix64 (/usr/lib/python2.7/lib-dynload/_ctypes.so+0x1aea3) #26 0x7f3f277948c4 in ffi_call (/usr/lib/python2.7/lib-dynload/_ctypes.so+0x1a8c4) #27 0x7f3f277852c1 in _ctypes_callproc (/usr/lib/python2.7/lib-dynload/_ctypes.so+0xb2c1) #28 0x7f3f27785aa1 (/usr/lib/python2.7/lib-dynload/_ctypes.so+0xbaa1) #29 0x4c2645 in PyObject_Call (/usr/bin/python2.7+0x4c2645) #30 0x537589 in PyEval_EvalFrameEx (/usr/bin/python2.7+0x537589) #31 0x5376f1 in PyEval_EvalFrameEx (/usr/bin/python2.7+0x5376f1) #32 0x5376f1 in PyEval_EvalFrameEx (/usr/bin/python2.7+0x5376f1) #33 0x53e2af in PyEval_EvalCodeEx (/usr/bin/python2.7+0x53e2af) #34 0x536c45 in PyRun_StringFlags (/usr/bin/python2.7+0x536c45) #35 0x53ecb4 in PyRun_SimpleStringFlags (/usr/bin/python2.7+0x53ecb4) #36 0x51e62d in Py_Main (/usr/bin/python2.7+0x51e62d) #37 0x7f3f504657ec in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x217ec) #38 0x41bad0 (/usr/bin/python2.7+0x41bad0) git-svn-id: https://svn.osgeo.org/gdal/trunk@41669 f0d54148-0727-0410-94bb-9a71ac55c965
In the normal usecase the NAS driver is supposed to always update an preexisting schema. For OCI there is a separate schema in the PostNAS project, that has it's identifiers truncated to a length that Oracle can cope with. Unfortunately ogr2ogr currently doesn't seem to have a way to match and NAS attribute to its LAUNDERed counterpart in Oracle.
This PR introduces a new method OGRLayer::FindFieldIndex() that can be overloaded by the drivers to provide this kind of matching. It also includes an update to ogr2ogr to make use of it and a implementation for the OCI driver, that tries to find the laundered version, if the full version doesn't exist.