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