paleolimbot opened a new issue, #205:
URL: https://github.com/apache/sedona-db/issues/205

   There are a number of variants of ST_GeomFromText that are identical except 
they error if a specific data type was not passed. These functions are:
   
   - ST_MPointFromText
   - ST_LineFromText
   - ST_LineStringFromText
   - ST_MLineFromText
   - ST_MPointFromText
   - ST_MPolyFromText
   - ST_PointFromText
   - ST_PolygonFromText
   
   I believe these could all be implemented by adding an (optional) "expected 
geometry type" here:
   
   
https://github.com/apache/sedona-db/blob/6d0b218844fe50d6c4d2b3a2d15ee124baecf110/rust/sedona-functions/src/st_geomfromwkt.rs#L127-L133
   
   ...and add an `expected_geometry_type: Option<GeometryTypeId>` here:
   
   
https://github.com/apache/sedona-db/blob/6d0b218844fe50d6c4d2b3a2d15ee124baecf110/rust/sedona-functions/src/st_geomfromwkt.rs#L87-L90
   
   Then these functions can be constructed and declared here with their 
documentation:
   
   
https://github.com/apache/sedona-db/blob/6d0b218844fe50d6c4d2b3a2d15ee124baecf110/rust/sedona-functions/src/st_geomfromwkt.rs#L37-L41
   
   We should ensure that this doesn't slow down the general case, although I 
don't think that in the context of WKT parsing this will be measurable.
   
   I don't think we need Geography constructors like this, because nobody else 
provides them either (these functions would be for OGC/PostGIS compatibility).


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

Reply via email to