jiayuasu opened a new issue, #2891:
URL: https://github.com/apache/sedona/issues/2891

   Sub-task of #2877.
   
   ## Scope
   
   Each SQL function added under #2877 (\`ST_Box2D\`, \`ST_MakeBox2D\`, 
\`ST_Extent\`, accessor overloads, \`CAST(box2d AS geometry)\`, 
\`ST_AsText(box2d)\`) needs a corresponding Scala DataFrame API wrapper in 
\`org.apache.spark.sql.sedona_sql.expressions.st_functions\` so users can call 
them via Column expressions instead of dropping to \`expr(\"ST_Box2D(...)\")\`.
   
   The Python equivalents live under #2887 — this issue tracks the JVM-side 
Scala DataFrame API specifically.
   
   ## Why split out
   
   The first SQL-only PR (#2890, \`ST_Box2D\`) was kept narrow to land the new 
return-type plumbing in \`InferredExpression\` cleanly. Layering on the 
DataFrame API for one function in isolation reads awkwardly; doing the whole 
Phase 1 surface in one wrapper PR (or co-located with each SQL function PR, 
batched after the SQL functions land) gives a coherent surface.
   
   ## Implementation
   
   For each Box2D-returning or Box2D-consuming function in Phase 1, add a Scala 
wrapper in \`st_functions\` that takes \`Column\` arguments and returns a 
\`Column\`, mirroring the pattern used by \`ST_Envelope\`, \`ST_XMin\` etc.
   
   ## Depends on
   
   - #2881 (\`ST_Box2D\`)
   - #2882 (accessor overloads)
   - #2883 (\`ST_MakeBox2D\`)
   - #2884 (\`ST_Extent\`)
   - #2885 (\`CAST AS geometry\` / \`ST_AsText\`)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to