Inconsistent Handling of Arguments with areas_and_lengths

JoshuaBixby — Sun, 12 Dec 2021 09:12:19 GMT

Seeing that my issue on GitHub (areas_and_lengths Incorrect Default area_unit · Issue #106 · Esri/arcgis-python-api · GitHub) hasn't even been acknowledged in 6+ months, I am hoping that posting it here might get better traction since there are still issues with areas_and_lengths.

As an aside, I can't help but shake my head when reading Open Source | Esri's Open Vision:

Esri’s Open-Source Community on GitHub

At Esri we encourage our development staff to engage with the open-source community. We regularly work on and share open-source projects via GitHub. We welcome more interactions with the community of geospatial developers on this forum.

I might be able to give them "sharing" but "regularly working" seems a stretch when issues can go unacknowledged, not even addressed, in 6+ months.

The areas_and_lengths - arcgis.geometry module — arcgis 1.3.0 documentation states (red color added by me):

length_unit - The length unit in which the perimeters of polygons will be calculated.
If calculation_type is planar, then length_unit can be any esriUnits constant. If lengthUnit is not specified, the units are derived from spatial_ref. If calculationType is not planar, then lengthUnit must be a linear esriUnits constant, such as esriSRUnit_Meter or esriSRUnit_SurveyMile. If length_unit is not specified, the units are meters. For a list of valid units, see esriSRUnitType Constants and esriSRUnit2Type Constant.
area_unit - The area unit in which areas of polygons will be calculated.
If calculation_type is planar, then area_unit can be any esriUnits constant. If area_unit is not specified, the units are derived from spatial_ref. If calculation_type is not planar, then area_unit must be a linear esriUnits constant such as esriSRUnit_Meter or esriSRUnit_SurveyMile. If area_unit is not specified, then the units are meters. For a list of valid units, see esriSRUnitType Constants and esriSRUnit2Type constant. The list of valid esriAreaUnits constants include, esriSquareInches | esriSquareFeet | esriSquareYards | esriAcres | esriSquareMiles | esriSquareMillimeters | esriSquareCentimeters | esriSquareDecimeters | esriSquareMeters | esriAres | esriHectares | esriSquareKilometers.

I can't speak for others, but "if area_unit is not specified" sure makes me think it is an optional argument, right? The problem is, the error message returned by ArcGIS API for Python says there are required:

>>> from arcgis import gis, geometry
>>>
>>> gis = gis.GIS()
>>>
>>> geom_json = {
...     "rings": [[[0, 0], [0, 10], [10, 10],[10, 0],[0, 0]]],
...     "SpatialReference": {"wkid": 3857}
... }
>>>
>>> geom = geometry.Geometry(geom_json)
>>> geometry.areas_and_lengths(geom, spatial_ref=3857)
TypeError                                 Traceback (most recent call last)
<ipython-input-12-3059784b616c> in <module>()
----> 1 geometry.areas_and_lengths(geom, spatial_ref=3857)

TypeError: areas_and_lengths() missing 3 required positional arguments: 'length_unit', 'area_unit', and 'calculation_type'
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

OK, so they are required by Python but don't need to be specified by ArcGIS. Let's try the old Esri standby of passing empty strings to use defaults:

>>> geometry.areas_and_lengths(geom, "", "", "", 3857)
RuntimeError: Error computing areas and lengths
(Error Code: 500)‍‍‍‍‍‍

Well, it seems empty strings don't work either. To confuse the matter even more, specifying only the area units works while leaving the other two empty strings:

>>> geometry.areas_and_lengths(geom,"", "esriSquareMeters", "", 3857)
{'areas': [100], 'lengths': [40]}‍‍‍‍

At this point, I am totally confused how exactly I am supposed to call areas_and_lengths because the documentation doesn't describe reality, and the method itself doesn't even behave consistently with unspecified parameters.

Re: Inconsistent Handling of Arguments with areas_and_lengths

DanPatterson_Retired — Mon, 15 Jan 2018 18:57:32 GMT

I agree, 6 months is tool long. Perhaps they have moved elsewhere.

That is a definite bug in the documentation or the process. I would have to say that defaulting to meters has me concerned because they aren't explicit as to whether a projection to planar is done behind the scenes or not.

I wouldn't allow any of the parameters to be optional in any event

topic Inconsistent Handling of Arguments with areas_and_lengths in ArcGIS API for Python Questions

Inconsistent Handling of Arguments with areas_and_lengths

Esri’s Open-Source Community on GitHub

Re: Inconsistent Handling of Arguments with areas_and_lengths