longitude-one / doctrine-spatial Goto Github PK

When I dump the query, I got :

"SELECT p0_.id AS id_0, ST_AsEWKB(p0_.polygon) AS polygon_1, ST_AsText(ST_Transform(p0_.polygon, ?)) AS sclr_2 FROM PolygonEntity p0_"

The dump of PHPUnit:

docker exec spatial-php8 vendor/bin/phpunit --configuration=phpunit.pgsql.xml  --filter=Transfo
PHPUnit 10.5.20 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.1.27 with PCOV 1.0.11
Configuration: /var/www/phpunit.pgsql.xml

.E.                                                                 3 / 3 (100%)

Time: 00:00.887, Memory: 22.00 MB

There was 1 error:

1) LongitudeOne\Spatial\Tests\ORM\Query\AST\Functions\PostgreSql\SpTransformTest::testFunctionInSelectWithSrid
Doctrine\DBAL\Exception\DriverException: An exception occurred while executing a query: SQLSTATE[XX000]: Internal error: 7 ERROR:  could not parse proj string '4326'
CONTEXT:  SQL function "st_transform" statement 1

/var/www/vendor/doctrine/dbal/src/Driver/API/PostgreSQL/ExceptionConverter.php:80
/var/www/vendor/doctrine/dbal/src/Connection.php:1364
/var/www/vendor/doctrine/dbal/src/Connection.php:1306
/var/www/vendor/doctrine/dbal/src/Connection.php:777
/var/www/vendor/doctrine/orm/src/Query/Exec/SingleSelectExecutor.php:29
/var/www/vendor/doctrine/orm/src/Query.php:284
/var/www/vendor/doctrine/orm/src/AbstractQuery.php:935
/var/www/vendor/doctrine/orm/src/AbstractQuery.php:891
/var/www/vendor/doctrine/orm/src/AbstractQuery.php:689
/var/www/tests/LongitudeOne/Spatial/Tests/ORM/Query/AST/Functions/PostgreSql/SpTransformTest.php:119

Caused by
Doctrine\DBAL\Driver\PDO\Exception: SQLSTATE[XX000]: Internal error: 7 ERROR:  could not parse proj string '4326'
CONTEXT:  SQL function "st_transform" statement 1

/var/www/vendor/doctrine/dbal/src/Driver/PDO/Exception.php:28
/var/www/vendor/doctrine/dbal/src/Driver/PDO/Statement.php:57
/var/www/vendor/doctrine/dbal/src/Driver/Middleware/AbstractStatementMiddleware.php:24
/var/www/vendor/doctrine/dbal/src/Logging/Statement.php:46
/var/www/vendor/doctrine/dbal/src/Connection.php:770
/var/www/vendor/doctrine/orm/src/Query/Exec/SingleSelectExecutor.php:29
/var/www/vendor/doctrine/orm/src/Query.php:284
/var/www/vendor/doctrine/orm/src/AbstractQuery.php:935
/var/www/vendor/doctrine/orm/src/AbstractQuery.php:891
/var/www/vendor/doctrine/orm/src/AbstractQuery.php:689
/var/www/tests/LongitudeOne/Spatial/Tests/ORM/Query/AST/Functions/PostgreSql/SpTransformTest.php:119

Caused by
PDOException: SQLSTATE[XX000]: Internal error: 7 ERROR:  could not parse proj string '4326'
CONTEXT:  SQL function "st_transform" statement 1

/var/www/vendor/doctrine/dbal/src/Driver/PDO/Statement.php:55
/var/www/vendor/doctrine/dbal/src/Driver/Middleware/AbstractStatementMiddleware.php:24
/var/www/vendor/doctrine/dbal/src/Logging/Statement.php:46
/var/www/vendor/doctrine/dbal/src/Connection.php:770
/var/www/vendor/doctrine/orm/src/Query/Exec/SingleSelectExecutor.php:29
/var/www/vendor/doctrine/orm/src/Query.php:284
/var/www/vendor/doctrine/orm/src/AbstractQuery.php:935
/var/www/vendor/doctrine/orm/src/AbstractQuery.php:891
/var/www/vendor/doctrine/orm/src/AbstractQuery.php:689
/var/www/tests/LongitudeOne/Spatial/Tests/ORM/Query/AST/Functions/PostgreSql/SpTransformTest.php:119

ERRORS!
Tests: 3, Assertions: 7, Errors: 1.

Message :
You are running PHP CS Fixer v2, which is not maintained anymore. Please update to v3.
You may find an UPGRADE guide at https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/v3.3.0/UPGRADE-v3.md

Quality: Mess detector:

• Remove the rule about the max exceeded line length
• Remove all of these lines:
  • // phpcs:disable Generic.Files.LineLength.MaxExceeded
  • // phpcs:enable Generic.Files.LineLength.MaxExceeded

Sure, here is the translation of the text into English:

In PostGIS, there are two main types of spatial data: geometries and geographies. It is not entirely accurate to say that PostGIS geometries should not have latitude and longitude. It is possible to store geographic points (latitude and longitude) in geometries, but this is not recommended in most cases.

Here are the key differences between geometries and geographies in PostGIS:

Geometries:

• Stored in a two-dimensional Cartesian plane.
• Assume a flat surface, which means that distances and areas are not always accurate for large distances or areas near the poles.
• Use projection units of the chosen spatial reference system (SRID).
• More efficient for simple spatial calculations.
• Supports a wider range of geometric functions.

Geographies:

• Stored on a sphere representing the Earth.
• Use the WGS84 ellipsoid model (or another spherical SRID) for more accurate calculations.
• Distances and areas are always expressed in meters.
• Less efficient for simple spatial calculations than geometries.
• Supports a more limited set of geometric functions.

In general, it is recommended to use geographies for global or regional geospatial data, and geometries for local or projected data.

Here are some cases where it may be appropriate to use geometries with latitude and longitude:

• If you are working with small-scale data that only covers a small local area, using a geometry with a projected SRID may be sufficient.
• If you are storing address point data, using a geometry with latitude and longitude may be acceptable, as long as you are not doing complex distance or area calculations.

However, in most cases, it is best to use geographies for geospatial data to achieve greater accuracy and more consistent results.

TODO :

• Setup a static indicator to be or not to be in "strict" mode.
• Use longitude or latitude with geometric will throw exception (only) in strict mode,
• Use non numeric value with setX (45N) will throw exception (only) in strict mode,
• Create tests concerning these setup

For additional security you should declare the allow-plugins config with a list of packages names that are allowed to run code. See https://getcomposer.org/allow-plugins
You have until July 2022 to add the setting. Composer will then switch the default behavior to disallow all plugins.

An error appears when starting test jobs after the PR #4 was submitted.

This error isn't due to the PR.

3. LongitudeOne\Spatial\Tests\DBAL\Types\Geography\GeoPolygonTypeTest::testNullPolygon
   Error: Class 'Doctrine\Common\Cache\ArrayCache' not found

Replace all ORMException

namespace Doctrine\ORM;

/**
 * Base exception class for all ORM exceptions.
 *
 * @deprecated Use Doctrine\ORM\Exception\ORMException for catch and instanceof
 */
class ORMException extends Exception

After updating doctrine/dbal from 3.6.x to 3.7.x I get some errors

Spatial/DBAL/Platform/MySql.php:65

[ErrorException]                     
Warning: Undefined array key "type"

the code :

 /**
     * Gets the SQL declaration snippet for a field of this type.
     *
     * @param array $fieldDeclaration array SHALL contains 'type' as key
     *
     * @return string
     */
    public function getSqlDeclaration(array $fieldDeclaration)
    {
        if (GeographyInterface::GEOGRAPHY === $fieldDeclaration['type']->getSQLType()) {
            return 'GEOMETRY';
        }

        return mb_strtoupper($fieldDeclaration['type']->getSQLType());
    }

As the phpdoc says $fieldDeclaration array SHALL contains 'type' as key. But after migrating to dbal 3.7, $fieldDeclaration doesn't contain type key

$fieldDeclaration dump from 3.6

[
  "name" => "latlng"
  "type" => LongitudeOne\Spatial\DBAL\Types\GeographyType^ {#630}
  "default" => null
  "notnull" => true
  "length" => 0
  "precision" => 10
  "scale" => 0
  "fixed" => false
  "unsigned" => false
  "autoincrement" => false
  "comment" => "(DC2Type:geography)"
  "version" => false
]

$fieldDeclaration dump from 3.7

[
  "length" => 0
  "unsigned" => false
  "fixed" => false
  "default" => null
  "notnull" => true
  "scale" => null
  "precision" => null
  "autoincrement" => false
  "comment" => null
]

#43 (comment)

Thanks for your work on this. I have found:

AbstractPoint.php has "TODO remove this line in version 5"

And add the declare(strict_types=1);rule as doctrine/orm does it.

Is there a way to go around the SQLite limitation? I use it only for fast testing and tests don't even need to cover this value.

The error I get when I try to update schema:

In AbstractSpatialType.php line 235:
                                                      
DBAL platform "sqlite" is not currently supported. 

The only idea I have is to make a Doctrine event that would completely remove it when in test environment but that sounds very wrong.

Test.rst file is outdated

Is there any example?
Just a simple thing like know if your favorite superheroes is inside Gotham city should be enough.
Thanks!

MySQL 5.7 has reached end of life (Octobre 2023) : https://endoflife.software/applications/databases/mysql
MySqlPlatform57 is already deprecated in doctrine/dbal
TODO :

• Trigger deprecations when users use it.
• Check in which version MySqlPlatform57 will be definitively removed form doctrine
• Remove support

There was a deprecation notice fix in wkb-parser so could you please allow to use dev-master branch instead of ~2.3.

The dockerized sphinx-doc image creation process is failing because of virtual environments.

There is no test for the next files:

• PostGis: SpScale.php
• PostGis: SpTransform.php
• PostGis: SpTranslate.php
• Standard: StConvexHull.php

Mysql 8 can save PONT like this: ST_SRID(POINT(...), 4326)
But

            $point = new Point($lon, $lat);
            $point->setSrid(4326); # !!!!!!!!!!
            $entity->setPoint($point);

Not working - SRID did not saved

Some tests now failed because of doctrine updates.
This is due to :

• updates on namespaces
• final classes cannot be mocked
• some Postgresql functions returns values in another order

Hi there.

First thing first: thank you for this package.

Let's talk about the following example:

CREATE TABLE `table_foobar` (
  `name` varchar(19) NOT NULL,
  `position` point DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_unicode_ci;

$point = new Point($longitude, $latitude);

$connection->insert(
  'table_foobar',
  [
    'name' => 'john',
    'position' => new Point(2.35222, 48.8566);
  ],
 [
    'position' => new PointType(),
  ]
);

I get the following exception.

[Doctrine\DBAL\Exception\DriverException]
  An exception occurred while executing 'INSERT INTO `table_foobar` (name, position) VALUES (?, ?)' with params ["john", "POINT(2.35222 48.8566)"]:

  SQLSTATE[22003]: Numeric value out of range: 1416 Cannot get geometry object from data you send to the GEOMETRY field

Do you have any clue to solve this error?

Note that I'm just using DBAL Doctrine integration.

Regards.

TODO:

• Remove travis tests,
• Move codecoverage from travis to Github actions

Because of doctrine updates, there are still some deprecated functions.

OrmMockTestCase.php:

• setMethods *2
• setMetaDataCacheImpl (fixed by #6)

OrmTestCase.php:

• executeUpdate
• exec
• setMetaDataCacheImpl (fixed by #6)

WrappingTest.php:

• class Doctrine\DBAL\Version is deprecated

Hi,

Have you planned to replace creof/wkt-parser? Because it creates a dependency on doctrine/lexer:~1.0 and this package has now 2 new major versions. Several packages require at least doctrine/lexer:^2 like doctrine/annotations:2.0.1 and friendsofphp/php-cs-fixer:v3.14.4 require doctrine/annotations:^2.

I created an issue on this package too.
Thanks,

Mickaël

I think I found a very confusing bug which is easy to replicate:

Test script

$lat = 52.092876;
$lon = 5.104480;
var_dump($lat, $lon);
$point = new \LongitudeOne\Spatial\PHP\Types\Geometry\Point($lat, $lon);
var_dump($point->getLatitude(), $point->getLongitude());

Outputs

float(52.092876)
float(5.10448)
float(5.10448)
float(52.092876)

https://github.com/longitude-one/doctrine-spatial/blob/main/lib/LongitudeOne/Spatial/PHP/Types/AbstractPoint.php#L202
Refers as Lat Lon construct (in this order) and writes lat to X and lon to Y

This is the issue:
When using getLatitude() it will return the data from Y instead of X. https://github.com/longitude-one/doctrine-spatial/blob/main/lib/LongitudeOne/Spatial/PHP/Types/AbstractPoint.php#L65

Would changing the getLatitude and getLongitude fix it entirely or is there unintended side effects for this?

Hello. I have a problem.

doctrine.yaml

doctrine:
  dbal:
    url: '%env(resolve:DATABASE_URL)%'
    driver: 'pdo_mysql'
    charset: utf8mb4
    types:
      point:      LongitudeOne\Spatial\DBAL\Types\Geometry\PointType
      linestring: LongitudeOne\Spatial\DBAL\Types\Geometry\LineStringType

If I use Geography instead of Geometry, I get an error like this.
bin/console doctrine:schema:validate

In AbstractPlatform.php line 441:  Unknown database type linestring requested, Doctrine\DBAL\Platforms\MySQL80Platform may not support it. 

Php 8.2, symfony 6.3, MySql 8.0.

I'm new to GIS, and actually don't understand the difference between geometry and geography here. I just need to calculate the distance from a Point to a Linestring (by the way, https://github.com/furioness/doctrine-spatial - I forked with a small hack to get ST_GeomFromText running with the third parameter - 'metre'; but the problem is unrelated to the fork).

User Deprecated: AbstractMySQLPlatform::getName() is deprecated. Identify platforms by their class. (AbstractMySQLPlatform.php:1212 called by AbstractSpatialType.php:231

doctrine/dbal#4749

doctrine/orm 3.0 was released a few days ago. Would it be possible to add support for this?

Thanks

Fixtures for functional tests should be internal to avoid that PHPStorm or any other code editor purpose these non-useful classes during autocompletion.

Hi @Alexandre-T,

I see you released a new version (v2) of longitude-one/wkt-parser. Is it planned to upgrade it on this package (longitude-one/doctrine-spatial)?

Thanks,

Mickaël

Add polygon is unable to handle a Polygon parameter. This method can only accept array of rings. It should accept Polygon and MultiplePolygons too

It's exists in MySQL, look like works the same, but has been mapped only inside Postgree.