| Bug #4249 | GIS: Spatial relations are probably not implemented yet | ||
|---|---|---|---|
| Submitted: | 22 Jun 2004 14:40 | Modified: | 23 Jun 2011 22:14 |
| Reporter: | Ladislav Sopko | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: GIS | Severity: | S4 (Feature request) |
| Version: | 4.1.2 Alpha | OS: | Windows (win32) |
| Assigned to: | Alexey Botchkov | CPU Architecture: | Any |
[22 Jun 2004 21: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 10: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 12:23]
Sergei Golubchik
This is work in progress
[25 Jun 2004 22: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 !!!!
[23 Jun 2011 22:14]
Paul DuBois
Note in 5.6.1 changelog entry. The OpenGIS specification defines functions that test the relationship between two geometry values. MySQL originally implemented these functions such that they used object bounding rectangles and returned the same result as the corresponding MBR-based functions. Corresponding versions are now available that use precise object shapes. These versions are named with an ST_ prefix. For example, Contains() uses object bounding rectangles, whereas ST_Contains() uses object shapes. There are also now ST_ aliases for existing spatial functions that were already exact. For example, ST_IsEmpty() is an alias for IsEmpty()
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.