[bug #68076] (mapping) geodetic2aer() and possibly other functions don't expand singleton dimensions

Philip Nienhuis <[email protected]> Sun, 1 Mar 2026 11:10:53 -0500 (EST)
Newsgroups	gmane.comp.gnu.octave.bugs
Message-ID	<[email protected]>
Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only notification stream.  Info posted to this mailing list address won't appear in the tracker database where it is most useful.

Update of bug #68076 (group octave):

                 Summary: [mapping] geodetic2aer() fails to support scalar
local to vector target => (mapping) geodetic2aer() and possibly other
functions don't expand singleton dimensions

    _______________________________________________________

Follow-up Comment #3:

Had a chance to experiment with Matlab r2024a; see below.  I've only
experimented with 1D and 2D inputs but I suppose the conclusions apply to ND
input arrays as well.

It appears that to be acceptable, either one of the input arg. sets (args 1-3,
or args. 4-6) must be:
* all scalar, or
* same size as the other set along the same dimension, whether or not after
expanding scalar coordinates in a set to the largest size in the two sets,
and
* and can be of different sizes in different dimensions.
IOW, all singleton dimensions of one set can be promoted to the size of the
corresponding dimension in the other set.  So this isn't just about scalar vs.
vector inputs.

See attached diary, somewhat shortened in below verbatim block where only
error messages have been retained:

>> geodetic2aer (1, 2, 3, [4 5], [6 7], [8 9], wgs84Ellipsoid, "degrees")

>> geodetic2aer ([1 2], 2, 3, [4 5], [6 7], [8 9], wgs84Ellipsoid, "degrees")

>> geodetic2aer ([1 2], [2 3], 3, [4 5], [6 7], [8 9], wgs84Ellipsoid,
>> "degrees")

>> geodetic2aer ([1 2], [2 3], [3 4], [4 5], [6 7], [8 9], wgs84Ellipsoid,
>> "degrees")

>> [a, b, c] = geodetic2aer ([1 2], [2 3], [3 4], [4 5], [6 7], [8 9],
>> wgs84Ellipsoid, "degrees")

>> [a, b, c] = geodetic2aer ([1 2], [2 3], 3, [4 5], [6 7], [8 9],
>> wgs84Ellipsoid, "degrees")

>> [a, b, c] = geodetic2aer ([1 2], 2, 3, [4 5], [6 7], [8 9], wgs84Ellipsoid,
>> "degrees")

>> [a, b, c] = geodetic2aer (1, 2, 3, [4 5], [6 7], [8 9], wgs84Ellipsoid,
>> "degrees")

>> [a, b, c] = geodetic2aer (1, 2, 3, 4, [6 7], [8 9], wgs84Ellipsoid,
>> "degrees")

>> [a, b, c] = geodetic2aer (1, 2, 3, [4 5 6], [6 7], [8 9], wgs84Ellipsoid,
>> "degrees")
Arrays have incompatible sizes for this operation.

>> [a, b, c] = geodetic2aer (1, 2, 3, [4 5], [6], [8 9], wgs84Ellipsoid,
>> "degrees")

>> [a, b, c] = geodetic2aer (1, 2, 3, [4 5], [6], 8, wgs84Ellipsoid,
>> "degrees")

>> [a, b, c] = geodetic2aer (1, 2, 3, [4], [6], 8, wgs84Ellipsoid, "degrees")

>> [a, b, c] = geodetic2aer ([1 2], 2, 3, [4], [6], 8, wgs84Ellipsoid,
>> "degrees")

>> [a, b, c] = geodetic2aer ([1 2], 2, 3, [4 5], [6], 8, wgs84Ellipsoid,
>> "degrees")

>> [a, b, c] = geodetic2aer ([1 2], 2, 3, [4 5 6], [6], 8, wgs84Ellipsoid,
>> "degrees")
Arrays have incompatible sizes for this operation.

>> [a, b, c] = geodetic2aer ([1 2], 2, 3, [4 5 6], [6 7 8], 8, wgs84Ellipsoid,
>> "degrees")
Arrays have incompatible sizes for this operation.

>> [a, b, c] = geodetic2aer ([1 2], 2, 3, [4 5 6], [6 7 8], [8 9 10],
>> wgs84Ellipsoid, "degrees")
Arrays have incompatible sizes for this operation.

>> [a, b, c] = geodetic2aer ([1], 2, 3, [4 5 6], [6 7 8], [8 9 10],
>> wgs84Ellipsoid, "degrees")

>> [a, b, c] = geodetic2aer ([1 2], 2, 3, [4 5 6], [6 7 8], [8 9 10],
>> wgs84Ellipsoid, "degrees")
Arrays have incompatible sizes for this operation.

>> [a, b, c] = geodetic2aer ([1 2], [2 3], [3 4], [4 5 6], [6 7 8], [8 9 10],
>> wgs84Ellipsoid, "degrees")
Arrays have incompatible sizes for this operation.

>> [a, b, c] = geodetic2aer ([1; 2], [2; 3], [3; 4], [4 5 6], [6 7 8], [8 9
>> 10], wgs84Ellipsoid, "degrees")

>> [a, b, c] = geodetic2aer ([1; 2], [2], [3], [4 5 6], [6 7 8], [8 9 10],
>> wgs84Ellipsoid, "degrees")


Furthermore, given the error messages (see attached diary) it seems that this
behavior is a mere coincidence and depending on what inputs the internal
Matlab functions behind geodetic2aer() will accept.  geodetic2aer() itself
doesn't seem to check sizes and dimensions of input.
My guess is that all of this this applies to many if not all other coordinate
functions.
This isn't documented anywhere in Matlab's mapping toolbox AFAICS.

ATM I don't see a quick way to get this behavior efficiently mimicked in
Octave; it'll need careful thinking over and because this applies to many
other functions it is probably a big project.
So until this gets fixed one needs to make sure that dimensions and sizes of
input args to the coordinate transformation functions (and possibly others)
all match, e.g., by invoking applicable repmat() calls.

(title adapted)

(file #58292)

    _______________________________________________________

Additional Item Attachment:

Name: geodetic2aer_input_sizes_ML.txt Size: 5.7KiB

<https://file.savannah.gnu.org/file/geodetic2aer_input_sizes_ML.txt?file_id=58292>


    AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://savannah.gnu.org/source/savane-2a2ecc185bd672dd377a2efbb667431a4b30acc3.tar.gz


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?68076>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc (application/pgp-signature, 228 B)