Laravel 9 Support

[SteveEdson]

Hi, I believe this package requires illuminate/database: ^8.0, which conflicts with ^9.0 required by Laravel 9.

Thanks

[sikhlana]

I've tested PR #184 on my production environment and works without any issue. Hopefully @grimzy will merge it as soon as possible.

[joelasaxton]

Excellent, Sikhlana!

[zishang520]

17 days are gone.

[osteel]

To be honest this package looks pretty much abandoned (there could be many reasons for that). It's annoying but we'll probably have to suck it up and move on at some point. Unless someone wants to take the mantle – fork the project and take maintenance on (I don't)

[eschricker]

@osteel totally aggree! We have move to use https://github.com/MatanYadaev/laravel-eloquent-spatial

[osteel]

@eschricker yep, does the job as far as I'm concerned. Cheers!

[vesper8]

@eschricker @osteel Thanks for sharing the link to https://github.com/MatanYadaev/laravel-eloquent-spatial

Since you both appear to have moved to that from this library, can you say a few words about what the migration was like?

I currently use this library to to perform queries with distanceSphereValue and orderByDistance. Do you think migrating over would be fairly problem-free?

[eschricker]

@vesper8 The migration was really easy and made the code more readable in my opinion . laravel-eloquent-spatial supports custom casts instead of using the property $spatialFields. As opposed to using the SpatialTrait to add querying functions, a CustomerEloquentBuilder is used. All supported functions are listed here: https://github.com/MatanYadaev/laravel-eloquent-spatial/blob/master/API.md The functions you need to use should be whereDistanceSphere and orderByDistanceSphere. I think the migration should be problem free.

[osteel]

@vesper8 I only need casting Point values in and out so far, so the transition was very easy. Even feels more "Laravel native", to be honest. But I can't speak for your use case

[Jul000]

I m waiting for a update of this package with laravel 9 too...

[vesper8]

I m waiting for a update of this package with laravel 9 too...

I just migrated to https://github.com/MatanYadaev/laravel-eloquent-spatial and just as they mention above, it was extremely straightforward and easy, I suggest you do the same

[Mullersen]

I was waiting too, but honestly it seems like it is not going to happen. I will probably be following @vesper8 and @eschricker and migrating to MatanYadaev and give an update on how it went here.

[Jul000]

The main problem with Matan Yadaev package is the no support of srid, if someone has a solution ?

[sikhlana]

@Julien0510 I already raised an issue regarding this: https://github.com/MatanYadaev/laravel-eloquent-spatial/issues/27

I am working on adding support for SRID since I already helped grimzy once with this package. But unfortunately the development is currently paused as I am working on a high-priority project rn.

[vesper8]

I had no idea SRID existed or what it was, after reading a bit about it, it seems like it basically makes things faster by adding a faster index to a table containing Point columns? It's not something I currently use at the scale I'm at, but I'd definitely adopt it if it promises to make things faster. So I'm hoping @sikhlana finds the time to add that PR after he's done with his current project.

[desaintflorent]

I'm also in the need to move to Laravel 9 and I'm using SRID a lot in my app. @sikhlana, let us know if you find the time to make SRID work on MatanYadaev package and we will try your PR 🙏

[johnwc]

SRID is not to make it faster by any means. A SRID tells the geometry "calculator" what coordinate system the geometry belongs to. Unless you have worked with spatial data, most people don't realize that a latitude and longitude could represent several different physical locations on the earth, depending on what coordinate system it is for. There are many different coordinate systems used to project physical locations on the earth. There is no default coordinate system defined, but... most of the lat/long/polygons that you see on the internet are for the World Geodetic System of 1984, aka WGS84. Which is Spatial Reference ID 4326.

If you do not know what your points/polygons in your data were projected from, aka what SRID they are for. Importing them with a unknown SRID or a wrong SRID can cause your points/polygons to be off placed on the earth. Ex: A point in San Francisco could be placed out in the pacific ocean. Your query results could be way off. I would not use any spatial engine that does not support SRIDs for it's geometry data types. Unless you know what the spatial engine assumes all the geometry points are, and make sure you project your data from it's SRID to what the spatial engine's SRID it is expecting.

One of the most annoying things when it comes to working with spatial data, is importing data from a third-party that uses some odd-ball coordinate system. Forcing you to run the entire data set through a projection calculator to project it from one SRID to the SRID you need it to be, before even being able to import it.

[SupianIDz]

See : https://github.com/grimzy/laravel-mysql-spatial/issues/192#issuecomment-1175762690

[nouman-ashraf-awan]

@grimzy waiting for a update of this package with laravel 9.

[nouman-ashraf-awan]

@grimzy This is much needed. Please add compatibility for Laravel 9.