[jira] [Commented] (SEDONA-234) ST_Point inconsistencies

["Jia Yu (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SEDONA-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17680888#comment-17680888 ] 

Jia Yu commented on SEDONA-234:
-------------------------------

[~umartin] I agree with your upgrade plan. Let's make our API align with Postgis :)

> ST_Point inconsistencies
> ------------------------
>
>                 Key: SEDONA-234
>                 URL: https://issues.apache.org/jira/browse/SEDONA-234
>             Project: Apache Sedona
>          Issue Type: Improvement
>            Reporter: Martin Andersson
>            Priority: Major
>
> I was looking at adding null safety to ST_Point but stumbled upon some inconsistencies with Postgis and other Sedona constructors.
> ST_Point in Postgis takes an optional srid - as most constructors in Postgis and Sedona.
> ST_Point in Sedona takes an optional Z value - making the 3 argument version in Sedona very different from Postgis.
> Postgis has ST_Point, ST_PointZ, ST_PointM and ST_PointZM for points with different dimensions. All take an optional srid.
> Postgis also has ST_MakePoint which is similar to Sedona ST_Point.
> See: [https://postgis.net/docs/ST_Point.html]
>  
> I see changing the semantics of ST_Point from x, y, z to z, y, srid as a no option.
>  
> One possible upgrade path, if we want to align with Postgis, would be to:
>  * Introduce ST_PointZ and possibly ST_MakePoint
>  * Remove the optional third argument from ST_Point, forcing people to use the above for 3D points.
>  * Once enough releases have passed and we're sure people have upgraded we can add an optional srid argument to ST_Point.
>  
> Should we keep ST_Point as it is or align with Postgis using the plan above?
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)