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

Barry DeZonia bdezonia at gmail.com
Mon Jun 5 18:43:05 PDT 2023 

Even,

Does this look okay as part of my typemap declaration? It is the only part
I am confused about. I am very unfamiliar with this "(DDDDDL...." stuff And
the L and V after each parameter. Where can I learn what this stuff means?

%typemap(argout) (int *nDimensions, GDALDimenion const **pDimensions )
{
  const jclass dimensionClass = jenv->FindClass("org/gdal/gdal/Dimension");
  const jclass vectorClass = jenv->FindClass("java/util/Vector");
  const jmethodID add = jenv->GetMethodID(vectorClass, "add",
"(Ljava/lang/Object;)Z");
  const jmethodID dimensionCon = jenv->GetMethodID(dimensionClass, "<init>",
    "(DDDDDLjava/lang/Long;Ljava/lang/Boolean;)V");

  for( int i = 0; i < *$1; i++ ) {
    jobject dimensionObj = jenv->NewObject(dimensionClass, dimensionCon,
                                &((*$2)[i]),
                                true);
    jenv->CallBooleanMethod($input, add, dimensionObj);
  }
}

On Sat, Jun 3, 2023 at 11:26 AM Even Rouault <even.rouault at spatialys.com>
wrote:

>
> 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 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.
>>
>> -- 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/20230605/7829991e/attachment.htm>

More information about the gdal-dev mailing list