SQLSTATE[42000]: Syntax error or access violation: 1582 Incorrect parameter count in the call to native function 'ST_SRID' (SQL: select `id`, `user_id`, `location` from `user_profiles` where `online` = 1 and `updated_at` >= 2022-02-03 15:09:51 and `location` is not null and ST_Distance( ST_SRID(location, 0), ST_SRID(Point(93.045724, -8.834381), 0) ) <= 20000)

👋 Hi there! As I was integrating this package with my application, I found out it's not possible to add a SPATIAL index on a POINT column if it supports NULL values. More info here and here.

Because only some rows in my table have location data associated, querying is slow without a spatial index. It seems as though the suggested way around this is to set a default POINT(0 0) value on all records without location data.

I can do this easily enough with an Eloquent model event:

public static function booted(): void
{
    // When a Model is being created, set its location field to a neutral Point(0 0) if not already set.
    static::creating(static function(Model $model) {
        foreach ($model->getLocationCastedAttributes() as $column) {
            if ($model->{$column} === null) {
                $model->{$column} = new Point();
            }
        }
    });
}

This now allows for spatial indexing to be used. However, the package's scopes become a lot harder to use practically. For example, calling Address::withinDistanceTo('location', new Point(25.45634, 35.54331), 10000000)->get() could incorrectly include records with POINT(0 0) set (or whatever default is used).

I appreciate the HasSpatial trait can be extended, and developers can override each method with an extra $query->whereRaw("ST_ASTEXT({$column}) = 'POINT(0 0)'") clause. Developers could also add their own scope method to their models, but would have to remember to call it every single time, which isn't ideal.

So it would be fantastic if support for this could be built-in natively somehow — especially if more scopes are likely to be added as the roadmap progresses in future.

Thanks for a really useful package! 🚀

This is unlikely to affect 99% of developers, but just throwing it out there as a similar issue caught me out before 🙃

The TarfinLabs\LaravelSpatial\Types\Point class treats latitude/longitude as a float. Most PHP installations will be able to handle up to 11 decimal places (but the precision can vary in php.ini).

However, the POINT type in MySQL supports up to 25 bytes of resolution. So if this package is used against any existing high-precision POINT values, it would lose data when saving the model back to the database.

I think the correct approach would be to use protected string $lat; in the Point class, and construct it with __construct(string|float $lat = 0 ...) etc... The getLat(): float method would still automatically cast as a float before returning, but the toPair() method should be changed to use the original string values of the properties. This would ensure the full precision is persisted back to the database by the LocationCast class.

Again, unlikely to affect most people — just worth mentioning for best practice 👍

always getting this error if location col. is null

because of $casts in the model

explode(): Argument #2 ($string) must be of type string, null given
exception: "TypeError",
"/var/www/sonbla/releases/8/vendor/tarfin-labs/laravel-spatial/src/Casts/LocationCast.php"
line: 18,