GIS BUG?

Hallo NG,

ich hab mal eine Frage bezüglich eines BUGs in GIS - jedenfalls glaube ich
momentan noch, dass es einer ist.

die Ausgangslage:
ich habe einen POINT(750000 5850000) - was irgendwo in Deutschland sein
sollte, das spielt allerdings keine Rolle.

Jedenfalls frage ich diesen Punkt nun ab und zwar mit:

SELECT ASTEXT(a.utmpoint) FROM test.gistest AS a WHERE
MBRCONTAINS(ENVELOPE(GEOMFROMTEXT('LINESTRING(700000.36 5830000, 770000
5890000)')), a.utmpoint)

Zur kurzen Erklärung, was da passiert:

Ich baue eine Linie zwischen 2 Punkten und bilde sozusagen eine diese Linie
umschliessende Fläche. Dadurch erhalte ich ein Rechteck mit den Eckpunkten
der Linie. Nun sollen alle Punkte selektiert werden, die innerhalb dieses
Rechtecks liegen. Die Linie geht übrigens schräg nach oben, wobei
LINESTRING(x1 y1, x2 y2) analog zum kartesischen Koordinatensystem
betrachtet werden kann.

Nun ist völlig klar, dass der oben genannte Punkt in dem gebildeten Rechteck
liegt, was auch einfach dadurch rausbekommen werden kann, dass - wenn man
die 0.36 von x1 weglässt der Punkt gefunden wird.

Ich nutze die XAMPP-Version 1.6.4 für Windows mit MySQL 5.0.45.

Nun kann ich natürlich auf ganze Zahlen runden, aber ich kann mir nicht
vorstellen, dass das Sinn und Zweck ist. Kann jemand dieses Problem
reproduzieren?

Grüße
Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Re: GIS BUG?

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: GIS BUG?

Andreas Kretschmer schrieb:
> begin Johannes Mueller schrieb:
>> [ viel Prosa, keinen Fehler ]
>>
>> Nun kann ich natürlich auf ganze Zahlen runden, aber ich kann mir nicht
>> vorstellen, dass das Sinn und Zweck ist. Kann jemand dieses Problem
>> reproduzieren?
>
> Die GIS-Implemtierung von MySQL ist, vorsichtig formuliert, noch nicht
> ganz fertig. Guggst Du auch hier:
> http://www.heise.de/newsticker/meldung/98162
>
> Vielleicht erklärt das auch Dein Problem.
>

Glaube ich nicht - er benutzt ja MBRCONTAINS. In dem Text (ich muss es
wissen ;-) ging es aber darum, die MySQL-Funktionen INTERSECTS, CONTAINS
durch solche ohne MBR zu ersetzen.

Aus dem OP:

SELECT ASTEXT(a.utmpoint) FROM test.gistest AS a WHERE
MBRCONTAINS(ENVELOPE(GEOMFROMTEXT('LINESTRING(700000.36 5830000, 770000
5890000)')), a.utmpoint)

Ich nehme an (das OP war da ein wenig unklar), dass diese Abfrage den
Punkt POINT(750000 5850000) nicht zurückliefert. Ein leicht
modifiziertes, mit 700000 als linker unterer Ecke des MBR, tut
anscheinend das erwartete. Der angegebene Pkt sollte aber in jedem der
beiden MBRs liegen, denn 700000.36 < 750000 < 770000 ebenso wie 700000 <
750000 < 770000.

Vielleicht ein Bug, vielleicht irgendwas anderes.

Re: GIS BUG?

Christian Kirsch wrote:

> Aus dem OP:
>
> SELECT ASTEXT(a.utmpoint) FROM test.gistest AS a WHERE
> MBRCONTAINS(ENVELOPE(GEOMFROMTEXT('LINESTRING(700000.36 5830000,
> 770000 5890000)')), a.utmpoint)
>
> Ich nehme an (das OP war da ein wenig unklar), dass diese Abfrage den
> Punkt POINT(750000 5850000) nicht zurückliefert. Ein leicht
> modifiziertes, mit 700000 als linker unterer Ecke des MBR, tut
> anscheinend das erwartete. Der angegebene Pkt sollte aber in jedem der
> beiden MBRs liegen, denn 700000.36 < 750000 < 770000 ebenso wie
> 700000 < 750000 < 770000.
>
> Vielleicht ein Bug, vielleicht irgendwas anderes.

Ja, genau das meinte ich - tut mir leid, wenn ich mich da nicht ganz
verständlich ausgedrückt hatte. Wenn es ein Bug ist, hat es mich jedenfalls
ziemlich viel Nerven gekostet es herauszufinden.

An der größe der Zahlen liegt es wahrscheinlich auch nicht, weil es mit
kleinen Zahlen wie z.B. zwischen 1 und 5 dieselben Probleme gibt.

Grüße
Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Re: GIS BUG?

Johannes Mueller schrieb:
> Christian Kirsch wrote:
>
>> Aus dem OP:
>>
>> SELECT ASTEXT(a.utmpoint) FROM test.gistest AS a WHERE
>> MBRCONTAINS(ENVELOPE(GEOMFROMTEXT('LINESTRING(700000.36 5830000,
>> 770000 5890000)')), a.utmpoint)
>>
>> Ich nehme an (das OP war da ein wenig unklar), dass diese Abfrage den
>> Punkt POINT(750000 5850000) nicht zurückliefert. Ein leicht
>> modifiziertes, mit 700000 als linker unterer Ecke des MBR, tut
>> anscheinend das erwartete. Der angegebene Pkt sollte aber in jedem der
>> beiden MBRs liegen, denn 700000.36 < 750000 < 770000 ebenso wie
>> 700000 < 750000 < 770000.
>>
>> Vielleicht ein Bug, vielleicht irgendwas anderes.
>
> Ja, genau das meinte ich - tut mir leid, wenn ich mich da nicht ganz
> verständlich ausgedrückt hatte. Wenn es ein Bug ist, hat es mich jedenfalls
> ziemlich viel Nerven gekostet es herauszufinden.
>
> An der größe der Zahlen liegt es wahrscheinlich auch nicht, weil es mit
> kleinen Zahlen wie z.B. zwischen 1 und 5 dieselben Probleme gibt.
>

Kannst Du versuchen, das mal mit solchen kleinen Zahlen als konzisen
Testfall zusammenzustellen, also inklusive CREATE TABLE, INSERT + SELECT?

Re: GIS BUG?

"Johannes Mueller" wrote:

> ich habe einen POINT(750000 5850000) - was irgendwo in Deutschland sein
> sollte, das spielt allerdings keine Rolle.
>
> Jedenfalls frage ich diesen Punkt nun ab und zwar mit:
>
> SELECT ASTEXT(a.utmpoint) FROM test.gistest AS a WHERE
> MBRCONTAINS(ENVELOPE(GEOMFROMTEXT('LINESTRING(700000.36 5830000, 770000
> 5890000)')), a.utmpoint)
....

> Nun ist völlig klar, dass der oben genannte Punkt in dem gebildeten Rechteck
> liegt, was auch einfach dadurch rausbekommen werden kann, dass - wenn man
> die 0.36 von x1 weglässt der Punkt gefunden wird.
>
> Ich nutze die XAMPP-Version 1.6.4 für Windows mit MySQL 5.0.45.
>
> Nun kann ich natürlich auf ganze Zahlen runden, aber ich kann mir nicht
> vorstellen, dass das Sinn und Zweck ist. Kann jemand dieses Problem
> reproduzieren?

Bei mir funktioniert das:

mysql> select MBRCONTAINS(ENVELOPE(GEOMFROMTEXT('LINESTRING(700000.36 5830000,
770000 5890000)')), GEOMFROMTEXT('POINT(750000 5850000)')) AS foo;
+------+
| foo |
+------+
| 1 |
+------+

mysql> create table t1 (c1 point not null);
Query OK, 0 rows affected (0,01 sec)

mysql> insert into t1 values (GEOMFROMTEXT('POINT(750000 5850000)'));
Query OK, 1 row affected (0,00 sec)

mysql> select count(*) from t1 where MBRCONTAINS(ENVELOPE(GEOMFROMTEXT(
'LINESTRING(700000.36 5830000, 770000 5890000)')), c1);
+----------+
| count(*) |
+----------+
| 1 |
+----------+

mysql> alter table t1 add spatial index (c1);
Query OK, 1 row affected (0,00 sec)

mysql> select count(*) from t1 where MBRCONTAINS(ENVELOPE(GEOMFROMTEXT('LINESTRI
NG(700000.36 5830000, 770000 5890000)')), c1);
+----------+
| count(*) |
+----------+
| 1 |
+----------+

mysql> select version();
+-----------+
| version() |
+-----------+
| 5.0.52 |
+-----------+


XL

Re: GIS BUG?

Johannes Mueller wrote:

> ich hab mal eine Frage bezüglich eines BUGs in GIS - jedenfalls
> glaube ich momentan noch, dass es einer ist.

Also ich muss mich entschuldigen, es ist definitiv meine Schuld gewesen. Ich
hatte kein EXPLAIN SELECT() gemacht - was mir verraten hätte, dass ich einen
2ten Index (der nicht SPATIAL war) auf der Spalte hatte und dieser dem
SPATIAL-Index vorgezogen wurde.

Danke an alle, die sich bemüht hatten und nochmals Entschuldigung für euren
Zeitaufwand.

Grüße
Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Re: GIS BUG?

"Johannes Mueller" wrote:
> Johannes Mueller wrote:
>
>> ich hab mal eine Frage bezüglich eines BUGs in GIS - jedenfalls
>> glaube ich momentan noch, dass es einer ist.
>
> Also ich muss mich entschuldigen, es ist definitiv meine Schuld gewesen. Ich
> hatte kein EXPLAIN SELECT() gemacht - was mir verraten hätte, dass ich einen
> 2ten Index (der nicht SPATIAL war) auf der Spalte hatte und dieser dem
> SPATIAL-Index vorgezogen wurde.

Huch? Das sollte trotzdem nicht passieren. Auch wenn ein nicht-
spatialer Index auf einem GIS-Objekt natürlich Unsinn ist.


XL