[
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)
