Closed DFEvans closed 4 months ago
Aha, digging deeper, the cause of the upset seems to be that I'm specifying the SRID on the column, but it's unset on the geometry. Is this the expected behaviour when that occurs? The documentation doesn't go into much detail on how it interacts.
(I'm also now unsure if this is GeoAlchemy logic or Spatialite logic - apologies if it's the latter)
Trying to take that knowledge back to my actual code, I was surprised to find that explicitly setting the SRID on my geometry when calling from_shape
wasn't enough.
The issue seems to be that the bind_processor_process
for sqlite isn't behaving properly. I can see that it tries very hard to provide an SRID if it can, either using the SRID from the value or assuming that of the column, but the values that come out in several cases either don't add the SRID, or can actually strip it entirely when an EWKB is passed in (my from_shape
case).
The underlying cause is that WKTElement.SPLIT_WKT_PATTERN
, a regex used to split WKT strings, assumes that the coordinate section of a WKT string consists of digits, decimal points, spaces, commas, and brackets only - significantly, that list excludes minus signs (dashes). When the match fails, the WKT just gets passed through without an SRID being prepended (for EWKB, the conversion involves an intermediate WKT gets created).
Same root cause as #509, it seems.
Fairly simple to do an incremental fix to the WKT regex. However, with this being the second issue, the relative simplicity of the regex, and the potential complexity of WKT strings, I'm worried that there remain plenty of undiscovered issues and the regex probably needs a significant revision by someone who's far more familiar with WKT parsing than I am. For another example, a GeometryCollection
like this example from the WKT spec doesn't parse correctly:
GeometryCollection(POINT (10 10),POINT (30 30),LINESTRING (15 15, 20 20))
Hi @DFEvans Thank you very much for this very detailed report! You are absolutely right, we missed the negative coordinate case. I'm going to push a quick fix for this. For your last comment, it's true that we only support simple WKT strings. I think it is able to cover most use cases but we may have to improve it at some point...
@DFEvans could you test the branch of #517 for your use case please?
I think it is able to cover most use cases but we may have to improve it at some point...
Is it worth emitting a warning/log message? Thinking of something in the if match is None: return wkt
branch in format_geom_type
.
@DFEvans could you test the branch of https://github.com/geoalchemy/geoalchemy2/pull/517 for your use case please?
Yep, that does it - thanks!
I think it is able to cover most use cases but we may have to improve it at some point...
Is it worth emitting a warning/log message? Thinking of something in the
if match is None: return wkt
branch informat_geom_type
.
Indeed, let's add a warning here.
The new release 0.15.2
is available and should fix this issue.
Describe the bug
When using spatialite, inserting a geometry with negative coordinates to a column with srid=4326 is rejected as it "violates Geometry constraint [geom-type or SRID not allowed]", even though the coordinates supplied should be valid for WGS84.
Optional link from https://geoalchemy-2.readthedocs.io which documents the behavior that is expected
https://geoalchemy-2.readthedocs.io/en/stable/spatialite_tutorial.html
To Reproduce
Error
Additional context
From reading elsewhere, rejecting negative coordinates is expected behaviour if a column has an undefined
srid
. However, I think I'm defining it correctly - if nothing else, the raw SQL emitted to create the table includes the expected4326
in the call toRecoverGeometryColumn
.The linked tutorial for Spatialite use doesn't explicitly show the use of SRID or state that they're supported, but equally, it doesn't mention any restrictions on compatibility vs. a PostGIS-backed database.
GeoAlchemy 2 Version in Use
0.15.1
Python Version
3.10
Operating system
Linux