| Bug #4249 | GIS: Spatial relations are probably not implemented yet | ||
|---|---|---|---|
| Submitted: | 22 Jun 2004 16:40 | Modified: | 15 Feb 2007 16:11 |
| Reporter: | Ladislav Sopko | ||
| Status: | Verified | ||
| Category: | Server: GIS | Severity: | S4 (Feature request) |
| Version: | 4.1.2 Alpha | OS: | Microsoft Windows (win32) |
| Assigned to: | Alexey Botchkov | Target Version: | TBD |
| Triage: | D5 (Feature request) | ||
[22 Jun 2004 23:46]
Matthew Lord
Hi Ladislav,
These are the results that I got, I just want to make sure that I did repeat your case as
I'm ignorant
about particular subject.
root@localhost:bugs~> SELECT MBRIntersects(@g, @pIN),MBRIntersects(@g,
@pOUT),MBRIntersects(@g,
@pOUT1),Intersects(@g, @pIN),Intersects(@g, @pOUT), Intersects(@g,@pOUT1)\G
*************************** 1. row ***************************
MBRIntersects(@g, @pIN): 1
MBRIntersects(@g, @pOUT): 1
MBRIntersects(@g, @pOUT1): 0
Intersects(@g, @pIN): 1
Intersects(@g, @pOUT): 1
Intersects(@g,@pOUT1): 0
1 row in set (0.00 sec)
Best Regards
[23 Jun 2004 12:14]
[ name withheld ]
Hi, MBRIntersects(@g, @pIN): 1 MBRIntersects(@g, @pOUT): 1 MBRIntersects(@g, @pOUT1): 0 are OK. Intersects(@g, @pIN): 1 Intersects(@g, @pOUT): 1 Intersects(@g,@pOUT1): 0 are not because Intersects(@g, @pOUT) should return 0 if I understood well. *BUT* see : http://dev.mysql.com/doc/mysql/en/Functions_that_test_spatial_relationships_between_geomet... And read this carefully : The OpenGIS specification defines the following functions. Currently, MySQL does not implement them according to the specification. Those that are implemented return the same result as the corresponding MBR-based functions. ... These functions may be implemented in future releases with full support for spatial analysis, not just MBR-based support. So... not a bug IMHO. Keep waiting :-) Cheers, p.b.
[23 Jun 2004 14:23]
Sergei Golubchik
This is work in progress
[26 Jun 2004 0:04]
Ladislav Sopko
Thx for prompt reaction. I'm going to kill my self :-) I need to make additional test manually, problem is, I found only one library to use for additional calcolations - GEOS. But what I found today. It has probably som relations not implemented jet, too. So nice try to make spatial engine based on MySQL, but in this critical time situation for me .... I'm going to kill my self :))))))) .... I need relation : (g1.intersect(g2) && !g1.touche(g2)) pls heeeeelp !!!!
Description: I made many tryes, and I suppose that all spatial relations are implemented just with MBRxxx versions. How to repeat: try this: SET @g = GeometryFromText('POLYGON((1674504.87 4700236.64,1674536 4700222.18,1674527.45 4700203.79,1674496.32 4700218.25,1674504.87 4700236.64))'); SET @pIN = GeometryFromText('POINT(1674514 4700221)'); SET @pOUT = GeometryFromText('POINT(1674522 4700230)'); SET @pOUT1 = GeometryFromText('POINT(1674533 4700259)'); SELECT MBRContains(@g, @pIN), MBRContains(@g, @pOUT), MBRContains(@g, @pOUT1),Contains(@g, @pIN), Contains(@g, @pOUT), Contains(@g, @pOUT1); SELECT MBRWithin(@pIN, @g), MBRWithin(@pOUT, @g), MBRWithin(@pOUT1, @g),Within(@pIN, @g), Within(@pOUT, @g), Within(@pOUT1, @g); SELECT MBRIntersects(@g, @pIN),MBRIntersects(@g, @pOUT),MBRIntersects(@g, @pOUT1),Intersects(@g, @pIN),Intersects(@g, @pOUT), Intersects(@g,@pOUT1); Comment: @g is an geometry @pIN is point inside of a geometry @g, @pOUT is a point out of @g, but inside of a MBR(@g) and @pOUT1 is out of @g and out of MBR(@g); and testing select shows that normal relations and their MBR versions give the same results, which is not right.