Open FatherNelson opened 4 years ago
I have made some patches to this issue in my own fork of this repository to make it compatible with PostGIS, but as a relatively new member to the open source community, I am not sure how you would like to implement my fixes if at all. Basically, the format of the queries had illegal chars to be used as a query in a PostGIS application (read backticks) and in the Geometry class the first four bits were stripped for some reason, which, after adding back in, made it compatible with PostGIS. This means that either the PostGIS support should be a variable passed in to choose which query to generate, or that my fork should continue supporting PostGIS support if that is outside of the scope of this project. For those looking for PostGIS support, this is my fork and feel free to help out a Newb on there first fork (: 👍
Sorry I'm seeing this just now, have you looked at https://github.com/mstaack/laravel-postgis? It might better fit your needs. We don't support Postgres/POSTGIS.
The first 4 bytes of the WKB are the Geometries' SRID. In MySQL versions prior to 8, they were just null-bytes.
In any case, thank you for also remind me to work on some long-due contribution doc.
Hi @grimzy , first of all thank you for this package. I want to know if we can conditionally switch this driver, say if the database use MySQL, simply use this package, else use the PostGIS package. Do you have any idea how to implement this? Thank you
When using this library in a postgis/laravel project, I found that there were a couple of changes necessary, and that it still did not solve the problem so I am coming here to GitHub to try to figure out how to finish this patch. The project I am building closely resembles this example which I am attempting to get to work in my postgis environment:
https://medium.com/@brice_hartmann/getting-started-with-geospatial-data-in-laravel-94502dc74d55
First of all, it was necessary to change the backticks in the scope comparison to this:
` public function scopeComparison($query, $geometryColumn, $geometry, $relationship) { $this->isColumnAllowed($geometryColumn);
This made it so the query would even recognize the provided table instead of throwing an error like would happen before. I also have ensured that SRID's of the points I am checking to be inside the multipolygon and the multipolygon itself are matching. The point is verifiably in one of the defined regions, and when I execute this query on my db:
select * from neighborhood where st_intersects(geometry, ST_GeomFromText('POINT(-87.6776217 41.9099103)',4326)) limit 1
I get the expected result. So, what my question is, is why when doing the data parsing of the passed in values, I get this error returned :
"message": "Parsing failed: Dimension mismatch between \"3DM\" and expected \"2D\"."
I understand this is a message from geo-io, however, it seems to me that something screwy is happening that is casting my two-dimensional multipolygon to a 3-dimensional one, and I would like to know how to prevent that if at all possible