[gdal-dev] Instructions for a new writing driver?

Wed Jul 19 23:57:17 PDT 2023

Thanks Andrew, it worked!

Now it compiles and org2org project also compiles.
Thanks a lot!

-----Mensaje original-----
De: Andrew C Aitchison <andrew at aitchison.me.uk> 
Enviado el: dimecres, 19 de juliol de 2023 16:48
Para: Abel Pau <a.pau at creaf.uab.cat>
CC: gdal-dev at lists.osgeo.org
Asunto: Re: [gdal-dev] Instructions for a new writing driver?

On Wed, 19 Jul 2023, Abel Pau wrote:

> Hi,
> finally I’ve discovered that the file mmwrlayr.c have to be included as cpp (internally is a C) but the extension is a cpp file.
>
> I don’t understand why so the questions remains open.
> In shape driver I see .c and all works but I don’t understand the difference.

When I use C code in my gdal drivers I use the CPL_C_START and CPL_C_END macros, which are defined in port/cpl_port.h

> Thanks!
>
> De: Abel Pau <a.pau at creaf.uab.cat>
> Enviado el: dimecres, 19 de juliol de 2023 10:31
> Para: Abel Pau <a.pau at creaf.uab.cat>; gdal-dev at lists.osgeo.org
> Asunto: RE: [gdal-dev] Instructions for a new writing driver?
>
> Hi again,
>
> I have a .c file in the makefile added as follow:
> # depends from frmts/aigrid, avc
> add_gdal_driver(
>  TARGET ogr_MiraMon
>  SOURCES ogrmiramondatasource.cpp ogrmiramondriver.cpp 
> ogrmiramonlayer.cpp mmwrlayr.c
>  BUILTIN)
> gdal_standard_includes(ogr_MiraMon)
> target_include_directories(ogr_MiraMon PRIVATE 
> $<TARGET_PROPERTY:ogrsf_generic,SOURCE_DIR>)
>
>
> It makes the .c file appears at the project i VS:
>
> [cid:image001.png at 01D9BA5D.5997B660]
>
> Then I use a function MMReadHeader() in ogrmiramonlayer.cpp but when I try to build an error appears:
>
> ogrmiramonlayer.obj : error LNK2019: unresolved external symbol "int 
> __cdecl MMReadHeader(struct VSIVirtualHandle *,str uct 
> MiraMonLayerInfo *,struct MM_TH *)" 
> (?MMReadHeader@@YAHPEAUVSIVirtualHandle@@PEAUMiraMonLayerInfo@@PEAUMM_
> TH@@@Z) r eferenced in function "public: __cdecl OGRMiraMonLayer::OGRMiraMonLayer(char const *,struct VSIVirtualHandle *,class OG RSpatialReference const *,int)" (??0OGRMiraMonLayer@@QEAA at PEBDPEAUVSIVirtualHandle@@PEBVOGRSpatialReference@@H at Z) [D:\G itHub-repository\GDAL\build\GDAL.vcxproj]
>    Hint on symbols that are defined and could potentially match:
>      MMReadHeader
> D:\GitHub-repository\GDAL\build\Debug\gdald.dll : fatal error LNK1120: 
> 1 unresolved externals [D:\GitHub-repository\GDA L\build\GDAL.vcxproj]
>
> I understand that I have to add the .c file un a library and I try to do it in the makefile:
>
> # miramonlib
> if (GDAL_USE_MIRAMONLIB_INTERNAL)
>  # ogrmiramon.h miramonfil.h mmwrlayr.c  add_library(miramonlib OBJECT 
> mmwrlayr.c)
>  gdal_standard_includes(miramonlib)
>  target_compile_definitions(miramonlib PUBLIC -DSAOffset=vsi_l_offset)  
> target_compile_options(miramonlib PRIVATE ${GDAL_C_WARNING_FLAGS})  if 
> (RENAME_INTERNAL_MIRAMONLIB_SYMBOLS)
>    target_compile_definitions(miramonlib PUBLIC 
> -DRENAME_INTERNAL_MIRAMONLIB_SYMBOLS -DSHPAPI_CALL=)  endif ()  
> target_compile_definitions(miramonlib PUBLIC -DUSE_CPL)  
> set_property(TARGET miramonlib PROPERTY POSITION_INDEPENDENT_CODE 
> ${GDAL_OBJECT_LIBRARIES_POSITION_INDEPENDENT_CODE})
>  target_sources(${GDAL_LIB_TARGET_NAME} PRIVATE 
> $<TARGET_OBJECTS:miramonlib>)  gdal_add_vendored_lib(ogr_MiraMon 
> miramonlib) elseif (HAVE_MIRAMONLIB)  
> gdal_target_link_libraries(ogr_MiraMon PRIVATE MIRAMONLIB::miramon) 
> endif ()
>
>
> I think that this miramonlib is not included and I don’t know how to do that (cause I thought that in had to be done in the makefile).
>
> Can anyone tell me how to add this .c file to use the functions in it in the .cpp files?
> THANKS ins advance!
>
>
> De: gdal-dev 
> <gdal-dev-bounces at lists.osgeo.org<mailto:gdal-dev-bounces at lists.osgeo.
> org>> En nombre de Abel Pau Enviado el: dijous, 6 de juliol de 2023 
> 15:01
> Para: gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
> Asunto: Re: [gdal-dev] Instructions for a new writing driver?
>
> Hi again.
> I finally did that and I am happy.
>
> It would be helpful for us to be able to use our C functions to read and write some parts of our format instead of passing all of them to C++.
> I’d like doing that but it’s not possible for the moment convert all our code to C++.
>
> My proposal is use a ogrmiramondatasource.cpp, a ogrmiramondriver.cpp and a ogrmiramonlayer.cpp as all of the projects that are created and add our files from C as necessary.
> The main goal is adding only the necessary ones.
>
> The question: Is this possible? Can I simply add C files and use that functions from C++ files? Or do GDAL prefer doing it in another way?
> Sorry if it is written somewhere else but I couldn’t find it.
>
> Thanks again for your kind help.
>
> De: gdal-dev 
> <gdal-dev-bounces at lists.osgeo.org<mailto:gdal-dev-bounces at lists.osgeo.
> org>> En nombre de Abel Pau Enviado el: dimecres, 5 de juliol de 2023 
> 15:13
> Para: gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
> Asunto: Re: [gdal-dev] Instructions for a new writing driver?
>
> Thanks you both!
>
>
>
>
> De: gdal-dev 
> <gdal-dev-bounces at lists.osgeo.org<mailto:gdal-dev-bounces at lists.osgeo.
> org>> En nombre de Even Rouault Enviado el: dimecres, 5 de juliol de 
> 2023 13:59
> Para: gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
> Asunto: Re: [gdal-dev] Instructions for a new writing driver?
>
>
> (resending to list)
>
> The CSV driver is actually not that simple to follow since it has 
> tricks to support updates through the OGREditableLayer mechanism. The 
> GMT one (ogr/ogrsf_frmts/gmt) might be a better start for a creation & 
> append only driver. But basically, the only common thing with your own 
> code will be the fact that you have to implement the 2 virtual methods 
> of interest: OGRLayer::CreateField() ,d OGRLayer::ICreateFeature() and 
> declare a few capabilities in OGRLayer::TestCapability()
>
> Unless you want to implement update capabilities (if the format allows it, which is generally not the case for a text based format), it might be simpler to have 2 distinct OGRLayer sub-classes for read-only and write-only operations.
> Even
> Le 05/07/2023 à 13:21, Laurențiu Nicola via gdal-dev a écrit :
> Hi,
>
> I think your best bet would be to take inspiration from an existing driver, like the CSV one (which shouldn't be too different from the hypothetical SPF driver in the docs).
>
> Laurentiu
>
> On Wed, Jul 5, 2023, at 14:17, Abel Pau wrote:
>
> Hi, following instructions about creating a new driver I found that
>
> https://gdal.org/tutorials/vector_driver_tut.html
>
>
>
>
>
> But I need to create a driver that can also write from any vector it’s own format.
>
> So, the inverse sense of the html I found.
>
>
>
> There is any other place I can follow any instructions to fill all function classes to create this part of the driver (the one that writes it’s own format)?
>
> Thanks in advance!
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
>
> _______________________________________________
>
> gdal-dev mailing list
>
> gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
>
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
>
> http://www.spatialys.com
>
> My software is free, but my time generally not.
>

-- 
Andrew C. Aitchison                      Kendal, UK
                    andrew at aitchison.me.uk