>From Suryaa Charan Shivakumar <[email protected]>: Attention is currently required from: Ian Maxon.
Suryaa Charan Shivakumar has posted comments on this change by Suryaa Charan Shivakumar. ( https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/20968?usp=email ) Change subject: [ASTERIXDB-3542] Added Coordinate Reference System support at Metadata and ST Transform function ...................................................................... Patch Set 4: (3 comments) File asterixdb/asterix-geo/src/main/java/org/apache/asterix/geo/evaluators/functions/STTransformDescriptor.java: https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/20968/comment/4a4e92ca_57af1ace?usp=email : PS4, Line 203: Geometry transformed = (Geometry) geometry.copy(); > who do we have to copy the geometry here? can't we just directly transform > `geometry`? The copy was a defensive measure to preserve the original geometry in case transformGeometry threw a TransformException mid-way and was partially transformed, or if any other failure happened. But yes you are right, it is a local object that's not used or there is no fallback using it either. I can make this change. https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/20968/comment/8e3ae2c8_907998c1?usp=email : PS4, Line 243: geometry.apply(new CoordinateSequenceFilter() { > won't making this create a new object at every invocation? do we need that, > or can this be factored […] Yes the anonymous class would allocate objects per call, but it's a tiny object and is thread safe. This is the (c)leanest way I could think of File asterixdb/asterix-lang-common/src/main/java/org/apache/asterix/lang/common/statement/crs/CRSCreateStatement.java: https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/20968/comment/fb32f74d_15c2a866?usp=email : PS4, Line 32: public CRSCreateStatement(int srid, String crsName, String crsWkt, boolean ifNotExists) { > i think CRSes should exist within a database/dataverse. […] I believe Starting global is the simpler long-term design, the previous APE is outdated and doesn't reflect the conversations we've had to fit in our architecture - I believe this is what the team agreed to initially and we tried the dist. derby way. Scoping CRSes per-database defers the hard problem. Storing multiple versions of the same CRS definition may lead to consistency and redundancy issues. Every major spatial system treats SRIDs as global. Most of our users would only use the EPSG CRS(s) especially that we only have support for vector data. Since, SRIDs are a global standard, not user data. EPSG:4326 means exactly one thing regardless of which database or dataverse you're in. Per-datavrse CRS scoping would let the same SRID (eg. EPSG:4326) mean different things in different databases, breaking standard SRID semantics and making ST_Transform non-deterministic. -- To view, visit https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/20968?usp=email To unsubscribe, or for help writing mail filters, visit https://asterix-gerrit.ics.uci.edu/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: asterixdb Gerrit-Branch: master Gerrit-Change-Id: Ia6e37080a581292744ddc9020b214926412c16ac Gerrit-Change-Number: 20968 Gerrit-PatchSet: 4 Gerrit-Owner: Suryaa Charan Shivakumar <[email protected]> Gerrit-Reviewer: Anon. E. Moose #1000171 Gerrit-Reviewer: Jenkins <[email protected]> Gerrit-CC: Ian Maxon <[email protected]> Gerrit-Attention: Ian Maxon <[email protected]> Gerrit-Comment-Date: Thu, 19 Mar 2026 21:31:18 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Ian Maxon <[email protected]>
