Arcade: Geometry Issues

Question

The geometry that is returned in arcade appears simplified to that which is returned by arcpy.  At first I thought it was just dropping m values, but it is dropping z, m and curves.  Is this just a limitation of Arcade or the Arcade Editor/ JS API? Any insight would be helpful.

This makes it tough to work with m values if I can't get to them in arcade.

I was going to hard code the geometry, but I think I'm having syntax issue with curvePaths as I get an error (illegal parameter)...

The geometry of a feature as returned by Arcade:

{"spatialReference":{"latestWkid":3857,"wkid":102100},
"paths":[[
[-9237699.298899999,4682788.039800003],
[-9237625.7377,4682783.805399999],
[-9237576.0275,4682781.260700002],
[-9237573.462399999,4682781.072500005], // missing circular arc info here...
[-9237540.4446,4682777.917100005],
...

The geometry of the same feature as returned via arcpy: Note: there are slight rounding differences as well

...
"curvePaths": [
[
    [-9237699.2989061102, 4682788.0398060447, 0, 17895],
    [-9237625.7377447672, 4682783.8054260481, 0, 18083.833599999998],
    [-9237576.0275005512, 4682781.2606678447, 0, 18211.397599999997],
    {
    "c": [
        [-9237573.4624214061, 4682781.0724902488, 0, 18217.989499999996],
        [-9237574.7439314425, 4682781.1807280686]
    ]
    },
    [-9237540.4445814844, 4682777.9171169717, 0, 18302.990699999995],
...
  ]
],
"spatialReference": { "wkid": 102100, "latestWkid": 3857 }}

I'm attempting to create an expression that will determine offset distance and corresponding station/m value and the offset direction but hitting a wall trying to get the measures to work against.

JustinReynolds · Answer

That is a good point... I suppose I dismissed the view scale as the issue here.  So this begs the question; what is the view scale at the point the geometry is returned? The Arcade Editor must use a default view scale (a small scale) that would returned generalized geometry.

From a code development standpoint, we need a way to define what scale we want to work with.  I don't see anywhere that this is exposed for us to define in the editor or playground.

We might also want to the return the geometry at whichever scale we need.  Perhaps Geometry could take an additional argument. Geometry($feature, scale). At some point we will need predictable, consistent and precise results.

I'm working working alignment data in this case (roadways, levees, etc.).  Converting a curve to a line segment could potentially return the wrong station, offset and offset direction.  It would depend on the geometry... the size of the curve and our proximity to it.

I like your suggestion to write this to a field.  I plan writing the a truncated version of the json to a field to inspect what is being returned at different scales.

I'll also log the two items above as ideas.

jcarlson · Answer

According to the docs:

Also note that geometries fetched from feature services, especially polylines and polygons, are generalized according to the view's scale resolution. Be aware that using a feature's geometry (i.e.$feature) as input to any geometry function will yield results only as precise as the view scale. Therefore, results returned from geometry operations in the visualization and labeling profiles may be different at each scale level. Use these functions at your discretion within these contexts.

I've found the amount of generalization fairly trivial for my expressions, but it does sound like you're doing something a bit more complex. How precise do you need the result to be? Is it feasible to just calculate a new field with this value?