Hi, was this a mistake?
Check if working tree is clean
From your reaction I understand you don't support different coordinate systems?
The objects provided by the library do store the SRID, but do not do anything with it, other than passing it to the geometry engine. What the geometry engine does with it is outside the scope of the project.
PostGis distinguisses geometry and geography. The latter supports the spherical coordinate system.
It's a long standing issue that brick/geo only maps to
GEOMETRY objects and not PostGIS' proprietary
GEOGRAPHY objects. I don't have enough understanding of the differences between the two of them to provide a custom implementation for PostGIS, but if you do, please feel free to propose a pull request!
(In particular, I fail to understand why PostGIS chose to implement a different
GEOGRAPHY type, when they could have made the calculations available on
GEOMETRY with SRID 4326? Please enlighten me if you know the answer.)
Hi, the issue is not with this library, but with the GIS implementation of MySQL / PostgreSQL. I guess the reason why this operation is not supported on SRID 4326 is that it must be hard to calculate on the spheroid.
Whereas on SRID 0, it is assumed that the coordinate system is flat, so calculations must be easier to perform.
Don't forget that this library is just a wrapper around a geometry engine (here, a database), so you're inherently limited by the capabilities of this engine.
Switching SRIDs is probably your best bet here, and probably good enough if your polygon & buffer are not too large, and not too close to the poles!
I got this error when I use the mysql engine (got a similar with postgres).
Uncaught PDOException: SQLSTATE[22S00]: <<Unknown error>>: 3618 st_buffer(POLYGON) has not been implemented for geographic spatial reference systems.
I'm loading a geojson polygon and wanted to buffer that one.
The strange thing is that this default example code from the readme worked:
$polygon = Polygon::fromText('POLYGON ((0 0, 0 3, 3 3, 0 0))'); echo $polygon->asText()."\n"; $polygon = $polygon->buffer(1); echo $polygon->asText()."\n"; /* output POLYGON ((0 0, 0 3, 3 3, 0 0)) POLYGON ((-1 0, -0.98078528040323 -0.19509032201613, -0.92387953251129 -0.38268343236509, -0.83146961230255 -0.5555702330196, -0.70710678118655 -0.70710678118655, -0.5555702330196 -0.83146961230255, -0.38268343236509 -0.92387953251129, -0.19509032201613 -0.98078528040323, 6.1232339957368E-17 -1, 0.19509032201613 -0.98078528040323, 0.38268343236509 -0.92387953251129, 0.5555702330196 -0.83146961230255, 0.70710678118655 -0.70710678118655, 3.7071067811865 2.2928932188135, 3.8314696123025 2.4444297669804, 3.9238795325113 2.6173165676349, 3.9807852804032 2.8049096779839, 4 3, 3.9807852804032 3.1950903220161, 3.9238795325113 3.3826834323651, 3.8314696123025 3.5555702330196, 3.7071067811865 3.7071067811865, 3.5555702330196 3.8314696123025, 3.3826834323651 3.9238795325113, 3.1950903220161 3.9807852804032, 3 4, 0 4, -0.19509032201613 3.9807852804032, -0.38268343236509 3.9238795325113, -0.5555702330196 3.8314696123025, -0.70710678118655 3.7071067811865, -0.83146961230254 3.5555702330196, -0.92387953251129 3.3826834323651, -0.98078528040323 3.1950903220161, -1 3, -1 0)) */
There is no error throw, and the buffer function works.
I figured that the SRID by default is 0. However I set this to 4326 like:
$polygon = Polygon::fromText('POLYGON ((0 0, 0 3, 3 3, 0 0))', 4326);
I get the st_buffer not implemented error when I run the above code...
I figured a hacky workaround to remove the 4326 SRID
$polygon = Polygon::fromText('POLYGON ((0 0, 0 3, 3 3, 0 0))', 4326); // set SRID to 0... $polygon = Polygon::fromText($polygon->asText(), 0); echo $polygon->asText()."\n"; $polygon = $polygon->buffer(1);//->asText(); echo $polygon->asText()."\n";
Like this I could process my geojson polygons as well (I used this example code to make a minimal example of the bug).
We cannot currently use
bin/console debug:container with
--format=json because we get this error:
In JsonDescriptor.php line 248:
Factory is not describable.
The culprit in our case is
Sentry\Client, and because of this only service, we cannot describe our whole container.
Would it be possible, instead of throwing an exception, to just output a
null value, an error string, or anything that wouldn't make the whole thing fail?
Same issue with
composer create-project symfony/skeleton:"6.1.*" tmp cd tmp composer require sentry/sentry-symfony bin/console debug:container --format=json --env=prod
Fix for a deprecation warning on PHP 8.1:
Return type of BackblazeB2\File::jsonSerialize() should either be compatible with JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice