st_ellipse orientation

[DrNJT]

st_ellipse() seems to generate an ellipse with the wrong orientation.
Changing the sign on the rotation parameter might be the fix (a similar step is required for plotting via matplotlib in PySAL).

[JosiahParry]

Can you please provide an example?

[JosiahParry]

Moving this conversation from email to here. The provided repro from pysal:

d <- tibble::tribble(
  ~x, ~y,
  66.22, 32.54,
  22.52, 22.39,
  31.01, 81.21,
  9.47, 31.02,
  30.78, 60.10,
  75.21, 58.93,
  79.26,  7.68,
  8.23, 39.93,
  98.73, 77.17,
  89.78, 42.53,
  65.19, 92.08,
  54.46, 8.48
) |> 
  sf::st_as_sf(coords = c("x", "y"))

sde <- sfdep::std_dev_ellipse(d)

plot(
  sfdep::st_ellipse(
    d,
    sde$sx,
    sde$sy,
    sde$theta * -1
  )
)

Multiplying by -1 accomplishes the correct thing here.

I'm also wondering if st_dev_ellipse() should retun the linestring from ellipse() instead of a point?

[barryrowlingson]

Is the underlying "problem" that PySAL considers clockwise positive [https://pysal.org/pointpats/generated/pointpats.ellipse.html] and sfdep considers anticlockwise positive?

Its not clear in the ?ellipse which direction is positive (unlike the PySAL link where clockwise is stated).

ellipse is using the mathematical convention of counterclockwise being positive.

neither documentation explicitly give the units of rotation, although ?ellipse says "degree of rotation", which is slightly ambiguous since "degree" here could be being used in its English sense of "amount".

Just needs a little documentation edit....

[DrNJT emailed me about this so I thought I'd chip in here]

[DrNJT]

Yes I had also taken the route of multiplying the rotation by -1.

Couple more issues:

1. The st_ellipse() documentation says sx is the major axis and sy minor axis. The original aspace function generates a flag which identifies which of these is which. As things stand, you can have a situation where sy > sx.
2. In a test, the value of sy differs from what is returned by PySAL whereas sx is the same. I need to look at this some more to figure out if there is an error and where it is! I can certainly share a reproducible example here when I get time...

[JosiahParry]

Always welcome @barryrowlingson!

I’m pretty ambivalent on the solution here. My heart says “do the thing that’s mathematically correct” but my brain says “consistency with pysal is good.”

Repros are definitely necessary to be able to identify the bugs. That would need to be accompanied by tests as well. Would either of you be willing to make a PR?

[DrNJT]

In fact I think st_dev_ellipse() is ok and generates results identical to two other implementations of the CrimeStat algorithm used (aspace::calc_sde and a QGIS plugin).