[gdal-dev] Java API: how to find dimensions of MDArray

Sat Jun 3 09:26:07 PDT 2023

Le 03/06/2023 à 18:16, Barry DeZonia a écrit :
> Ok, thanks. I will consider this for some of my future 
> weekend-playtime-programming days. Yes, I'm a masochist.
great, we'd definitely welcome a few ones :-)
>
> Are there other typemaps needed that would further strengthen the Java 
> api support?

Basically most #if defined(SWIGPYTHON) in 
https://github.com/OSGeo/gdal/blob/master/swig/include/MultiDimensional.i 
<https://github.com/OSGeo/gdal/blob/master/swig/include/MultiDimensional.i#L159> 
around a method are an indication that a typemap is missing.

Like:

- 
https://github.com/OSGeo/gdal/blob/92f9cee9a9ed3f114d3e6a63d095ceb09ce85eec/swig/include/MultiDimensional.i#L210 
for CreateMDArray() (resolution of that one should be close to the 
existing "(int object_list_count, GDALRasterBandShadow **poObjects)" 
Java typemap)

- 
https://github.com/OSGeo/gdal/blob/92f9cee9a9ed3f114d3e6a63d095ceb09ce85eec/swig/include/MultiDimensional.i#L464 
for GetCoordinateVariables() (resolution of that one should be very 
close to the GetDimensions() one)

- 
https://github.com/OSGeo/gdal/blob/master/swig/include/MultiDimensional.i#L477 
for GetProcessingChunkSize() (resolution should be close to the existing 
"(int* pnCountOut, int** outErrorCodes)" java typemap

- etc..

>
> On Sat, Jun 3, 2023 at 11:03 AM Even Rouault 
> <even.rouault at spatialys.com> wrote:
>
>
>     Le 03/06/2023 à 17:45, Barry DeZonia a écrit :
>>     Thanks Even.
>>
>>     I might be able to find some time to do the SWIG work depending
>>     upon the amount of development time needed. I am a long time
>>     developer with experience in Java, C, and C++ (but have not used
>>     SWIG before). Is it just a few signatures I need to write or do I
>>     need to write full support for a GDALDimension class? Can you
>>     comment on this?
>
>     Yes this is "just" a few signatures to map a C array of (existing)
>     GDALDimensionH objects to a vector of Java counterpart
>     org.gdal.gdal.Dimension objects. The org.gdal.gdal.Dimension class
>     already exists, with a "Dimension(long cPtr, boolean cMemoryOwn)"
>     constructor taking the value of the underlying C pointer as a Java
>     long. The cMemoryOwn boolean should probably be passed to true in
>     that context, since the C GDALDimensionH objects need to be freed
>     at the finalization of the Java Dimension object. This is really
>     about glueing stuff, but that said writing SWIG typemaps is a
>     whole adventure in itself... You may find relevant documentation
>     at
>     https://www.swig.org/Doc4.1/SWIGDocumentation.html#Java_typemaps
>     .  The hint I gave for the existing closest typemap should
>     hopefully put you on the right track, or at least as close as
>     possible.
>
>>
>>     Am I right in understanding that, as of the current Java
>>     implementation, one really can't use MDArrays for much? Like if I
>>     can't find the number of (... z planes, t steps, channels, etc.)
>>     of data I will not be able to reconstruct the data?
>
>     Yes the multidim API is probably currently hardly usable outside
>     C, C++ and Python due to the lack of a few critical typemaps for
>     the other languages.
>
>     Even
>
>>
>>     On Sat, Jun 3, 2023 at 6:09 AM Even Rouault
>>     <even.rouault at spatialys.com> wrote:
>>
>>         Barry,
>>
>>         This method is indeed not available currently in the Java
>>         bindings. It is only available currently in the Python
>>         bindings (see
>>         https://github.com/OSGeo/gdal/blob/master/swig/include/MultiDimensional.i#L159
>>         ) , since it requires writing a specific SWIG typemap for
>>         each binding language when a method returns (or takes as
>>         argument) a new non-primitive type such as here, with an
>>         array of dimensions. The closest existing Java typemap I
>>         found that can be used to take inspiration from is
>>         https://github.com/OSGeo/gdal/blob/master/swig/include/java/typemaps_java.i#L235
>>         but there would be changes to call the "Dimension(long cPtr,
>>         boolean cMemoryOwn)" constructor.  Whether you want to try to
>>         tackle that yourself or not, you may create a ticket about that
>>
>>         Even
>>
>>         Le 03/06/2023 à 09:09, Barry DeZonia a écrit :
>>>         On a related note is the Java api code in a public repo
>>>         somewhere? It would be helpful to look at that code
>>>         sometimes. (Like is GetDimensions() present in the Java code
>>>         but not exposed as a public method?)
>>>
>>>         On Sat, Jun 3, 2023 at 12:18 AM Barry DeZonia
>>>         <bdezonia at gmail.com> wrote:
>>>
>>>             Hi all,
>>>
>>>             I have access to an MDArray. I am trying to find its
>>>             dimensions. In the C++ API I can see that GDALMDArray
>>>             has a method called GetDimensions() to find the info I
>>>             need. But I am programming in Java and the Java API does
>>>             not show such a call for MDArray. Is there some way in
>>>             Java to find the info I need?
>>>
>>>
>>>         _______________________________________________
>>>         gdal-dev mailing list
>>>         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.
>>
>     -- 
>     http://www.spatialys.com
>     My software is free, but my time generally not.
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230603/1ba61b5f/attachment-0001.htm>