petern48 commented on code in PR #503:
URL: https://github.com/apache/sedona-db/pull/503#discussion_r2679103794
##########
python/sedonadb/tests/functions/test_functions.py:
##########
@@ -1803,14 +1803,24 @@ def test_st_isring_non_linestring_error(eng, geom):
[
(None, None),
("MULTILINESTRING ((0 0, 1 0), (1 0, 1 1))", "LINESTRING (0 0, 1 0, 1
1)"),
+ # opposite direction
(
"MULTILINESTRING ((0 0, 1 0), (1 1, 1 0))",
"LINESTRING (0 0, 1 0, 1 1)",
- ), # opposite direction
+ ),
+ # non-touching
(
"MULTILINESTRING ((0 0, 1 0), (8 8, 9 9))",
"MULTILINESTRING ((0 0, 1 0), (8 8, 9 9))",
),
+ # empty cases
+ # ("POINT EMPTY", "POINT EMPTY"), # PostGIS returns POINT (nan, nan)
Review Comment:
This is known. This is just an issue of how geoarrow renders the WKB as a
string since `POINT EMPTY` and `POINT (nan nan)` are represented the same as
WKB. In most test functions, we just specify expected as `POINT (nan nan)`
instead. If you `ctrl + f` for `POINT (nan nan)`, you'll see a lot. e.g. here:
https://github.com/apache/sedona-db/blob/edcb909413328ebc028703b3cc7fe72e4907ec02/python/sedonadb/tests/functions/test_functions.py#L493-L497
I'm okay with your approach too, though I personally just use `POINT (nan
nan)`, so I don't have to deal with the annoyances of manually fixing the
different spacing when doing string comparison.
--
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]
