Revanth14 commented on code in PR #1239:
URL: https://github.com/apache/iceberg-go/pull/1239#discussion_r3449755160


##########
table/arrow_utils.go:
##########
@@ -1884,22 +1921,26 @@ func geoArrowCRSToIcebergCRS(meta geoarrow.Metadata) 
(string, error) {
                        return "", fmt.Errorf("invalid geoarrow CRS metadata: 
%w", err)
                }
 
-               if strings.EqualFold(crs, "OGC:CRS84") || 
strings.EqualFold(crs, "EPSG:4326") {
-                       return "OGC:CRS84", nil
-               }
-
                switch meta.CRSType {
                case geoarrow.CRSTypeSRID:
                        return "srid:" + crs, nil
+               case geoarrow.CRSTypePROJJSON:
+                       return "", errors.New("CRS type projjson not supported 
for string CRS")
                case geoarrow.CRSTypeWKT22019:
-                       return "", errors.New("CRS type wkt2:2019 not 
supported")
-               default:
-                       if len(crs) <= 32 {
-                               return crs, nil
-                       }
+                       return "", errWKT2CRSNotSupported
+               }
 
-                       return "", errors.New("crs length too long")
+               if strings.EqualFold(crs, "OGC:CRS84") || 
strings.EqualFold(crs, "EPSG:4326") {

Review Comment:
   Good catch. Agreed, and addressed.
   
   I moved SRID resolution after the canonical check, so the `OGC:CRS84` / 
`EPSG:4326` collapse wins even with `crs_type:"srid"`:
   
   - `{"crs":"EPSG:4326","crs_type":"srid"}` → `OGC:CRS84`
   - `{"crs":"OGC:CRS84","crs_type":"srid"}` → `OGC:CRS84`
   - `{"crs":"3857","crs_type":"srid"}` → `srid:3857`
   
   I added test coverage for both the canonical+SRID case and the numeric SRID 
case, and left a comment explaining why SRID is resolved last.
   
   One intentional exception: `projjson`- and `wkt2`-typed strings still reject 
before canonicalization, since those encodings are unsupported by this path.



-- 
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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to