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

[Barry DeZonia]

Ok, thanks. I will consider this for some of my future
weekend-playtime-programming days. Yes, I'm a masochist.

Are there other typemaps needed that would further strengthen the Java api
support?

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 listgdal-dev at lists.osgeo.orghttps://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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230603/fa101806/attachment.htm>