Improve order-by-geometry interface #370
Description
In #360 we added a basic but awkward means by which to "sort by geometry". There are some improvements we need to make once we have some experience with it:
Maybe it's just me, but this feels a little awkward. I would definitely expect the default ordering of sd_order to have meaning. #360 (comment)
This is a great point...we can improve this situation by (1) erroring (i.e., refuse to sort if we're not sure it will be meaningful) and (2) removing the need for s2geography for computing the ordering (it's in most of our builds but not R yet). For most input/current released builds, the ordering will be meaningful.
Why do we call it SD_Order? If this is a UDF, why not ST?
Can we add docs together with the PR if possible?
A missing piece from the initial PR to the final interface here is the logical optimizer rule that transforms ORDER BY geometry to ORDER BY sd_order(geometry). We have sd_format() as well and will likely add sd_cast() soon as they are called in a similar (internal) way.
When we add the optimizer rule, we'll need to add a section on sorting (probably separate from the function docs)