1. Dashboard
  2. Articles
  3. Forum
  • Login or register
  • Search
This Thread
  • Everywhere
  • This Thread
  • This Forum
  • Articles
  • Pages
  • Forum
  • More Options
  1. webEdition Forum
  2. Forum
  3. Deutschsprachiges Support Forum
  4. webEdition Templates erstellen (we:tags)

Verzwicktes Problem mit einer Condition

  • Luigi
  • March 4, 2024 at 2:16 PM
1st Official Post
  • Luigi
    Student
    Reactions Received
    4
    Posts
    56
    • March 4, 2024 at 2:16 PM
    • #1

    Ich habe in einer Klasse Objekte mit Geokoordinaten.

    In einem Listview mache ich eine Umkreisabfrage, also zeige alle Objekte, die in einem Umkreis von 10 km zu einem gegebenen Punkt liegen. Zu diesem Zweck habe ich mir die folgenden Condition gebaut, die ich dann in den Listview einsetze:

    (10 > 6371 * ACOS( COS(RADIANS(50.001231413093)) * COS(RADIANS(GEO_lat)) * COS(RADIANS(GEO_lon) - RADIANS(8.2762513334082)) + SIN(RADIANS(50.001231413093)) * SIN(RADIANS(GEO_lat))))

    Die erste Zahl, die "10" ist der definierte Umkreis. Die Formel habe ich schon einige Male überprüft, sie gibt den Abstand zwischen 2 Punkten auf der Erdoberfläche aus.
    Nun ist es so, dass wenn ich auf einen Umkreis von 10 km prüfe, bekomme ich keine Ergebnisse. Auf bei 9 km bekomme ich keine Ergebnisse. Wohl aber bei 7,8,11 und 12 km.

    Wenn ich direkt in die Datenbank gehe und die Condition in die WHERE Klausel einsetze, bekomme ich bei allen km-Angaben Ergebnisse.

    Ich habe keine Idee, woran das liegen könnte. Muss ja etwas damit zutun haben, wie die Condition an die DB übergeben wird, oder?

    Edited once, last by Luigi (March 4, 2024 at 3:10 PM).

  • Online
    mokraemer
    Senior Member
    Reactions Received
    10
    Posts
    116
    • March 4, 2024 at 10:38 PM
    • Official Post
    • #2

    Puh schwer zu sagen, ob da was falsch übergeben wird - müßte man debuggen. Mir erscheint deine Formel zu kompliziert. Zum einen sprichst du hier von 10km, zum anderen geht es glaube ich nicht um eine ganz exakte Berechnung von wenigen cm. Ich würde daher lat/long als rechtwinklig nähern. Dann müßte es eigentlich reichen die Differenz der beiden Punkte zu errechnen und das mit binomischer Formel zu lösen. Das erscheint mir auch für die DB mal weniger aufwändig. Ob sich das weiter vereinfachen läßt, oder mit geo-db von mysql einfacher geht https://dev.mysql.com/blog-archive/geography-in-mysql-8-0/ weiß ich nicht. Hab den Fall selbst noch nicht gebraucht.

    • Next Official Post
  • Luigi
    Student
    Reactions Received
    4
    Posts
    56
    • March 5, 2024 at 8:58 AM
    • #3

    Ja, Du hast vielleicht recht, maximaler Umkreis ist 50 km, da fällt die Erdkrümmung nicht wirklich ins Gewicht. Werde die Condition mal umstellen und sehen was passiert. Die Abfrage ist eigentlich noch komplexer, habe sie hier aber auf den wesentlichen teil reduziert, der nicht funktioniert.

  • Luigi
    Student
    Reactions Received
    4
    Posts
    56
    • March 5, 2024 at 2:07 PM
    • #4

    OK, ich haba gefunden. Total verrückt. Es funktioniert auch nicht mit einer einfacheren Abfrage. Auf der suche nach einer einfacheren Abfrage habe ich einen Fehler produziert, wo mir dann auch die Query im Fehlerprotokoll ausgegeben wurde.

    Das ist die neue COndition:

    (10 > SQRT(POWER((8.2762513334082 - GEO_lon) * 71.5, 2) + POWER((50.001231413093 - GEO_lat) * 111.3, 2)))

    Hier bekam ich den Fehler:

    Code
    DOUBLE value is out of range in 'pow(((8.2762513334082 - `dev_db`.`ob1`.`float_GEO_lon`) * 71.5),`dev_db`.`ob1`.`object_2`)'

    Jetzt kann man sehr schön sehen, was passiert ist. Der Parameter "2" bei Power, was ja für den Exponenten steht wurde ersetzt durch `dev_db`.`ob1`.`object_2` was wohl daran liegt, dass das Objekt 2 in das Objekt 1 eingebunden ist. Hier macht das dann einen Fehler.

    In das Objekt 1 sind außerdem noch das Objekt 9 und das Objekt 10 eingebunden. Deshalb gibt es dort auch die entsprechenden Ersetzungen, nur das dies in der oberen Condition keinen Fehler fabriziert.

    Das Problem ist also, dass hier Zahlen, mit denen gerechnet werden soll, falsch ersetzt werden. Das macht die Abfrage kaputt. Direkt in der Datenbank funktioniert es dann natürlich.

    Jetzt habe ich aber keine Ahnung, wie das zu lösen ist. Was kann ich tun, damit es nicht diese falschen Ersetzungen gibt?

  • Luigi
    Student
    Reactions Received
    4
    Posts
    56
    • March 20, 2024 at 9:46 AM
    • #5

    Hat das jemand gelesen? Das ist doch ein interessantes Problem. Soll ich das einmal in das Mantis eintragen? Kann das behoben werden?

  • NilSole
    Beginner
    Reactions Received
    11
    Posts
    43
    • March 20, 2024 at 8:18 PM
    • #6

    Also wenn du es erst mal lösen willst, könntest du vielleicht die Zahlen ergänzen um .0

    Also würde deine 2 zum Beispiel zu 2.0

    So könnte sich die Ersetzung austricksen lassen. Ansonsten kannst du natürlich einen Bug erstellen.

  • NilSole
    Beginner
    Reactions Received
    11
    Posts
    43
    • March 20, 2024 at 8:22 PM
    • #7

    Mal eine andere Frage: heißt das Objekt-Feld in deiner Klasse dann einfach nur „2“? Es wird ja ersetzt mit Objekt_2, wenn du das umbenennen kannst, würde hier vermutlich auch die Ersetzung ausbleiben. Solch einen ‚Bug‘ könnten wir auch nicht wirklich beheben…

  • Luigi
    Student
    Reactions Received
    4
    Posts
    56
    • March 21, 2024 at 11:09 AM
    • #8

    So einfach ist es leider nicht. WE ist da ziemlich hartnäckig.

    Code
    DOUBLE value is out of range in 'pow(((8.2762513334082 - `dev_db`.`ob1`.`float_GEO_lon`) * 71.5),`dev_db`.`ob1`.`object_2`.0)'

    Es wird einfach ".0" angehängt :rolleyes:

  • Luigi
    Student
    Reactions Received
    4
    Posts
    56
    • March 21, 2024 at 11:13 AM
    • #9
    Quote from NilSole

    Mal eine andere Frage: heißt das Objekt-Feld in deiner Klasse dann einfach nur „2“? Es wird ja ersetzt mit Objekt_2, wenn du das umbenennen kannst, würde hier vermutlich auch die Ersetzung ausbleiben. Solch einen ‚Bug‘ könnten wir auch nicht wirklich beheben…

    Objekt-Felder in Objekten haben keine Namen …

  • NilSole
    Beginner
    Reactions Received
    11
    Posts
    43
    • March 21, 2024 at 10:32 PM
    • #10

    Dann vielleicht vor die 2 noch eine 0, also 02…

    Ich arbeite sonst nicht mit Objektfeldern, daher kenne ich auch deren Namen nicht ;)

    Die genaue Ersetzungslogik kenne ich dann auch nicht - in jedem Fall wäre es vermutlich für uns schwer zu entscheiden…

  • Luigi
    Student
    Reactions Received
    4
    Posts
    56
    • March 27, 2024 at 11:46 AM
    • #11

    Ja, 0 vor die 2 funktioniert, ist erst einmal ein Workaround.

    Deinen letzten Satz verstehe ich nicht, was da schwer zu entscheiden ist.
    Eine Condition bezieht sich ja nie direkt auf ein eingebundenes Objekt, sondern auf die Felder des eingebundenen Objekts.

    Steht auf jeden Fall jetzt im Mantis und vielleicht ist es ja gar nicht so ein großes Problem.

  • lukas.imhof
    Moderator
    Reactions Received
    1
    Posts
    4
    • April 3, 2024 at 4:45 PM
    • Official Post
    • #12

    Ich hab das in 9.2.2.1 (nightly) provisorisch gefixt.

    Wichtig:
    Standard für Conditions ist eigentlich die Verwendung von Feldnamen ohne Typ-Präfix, also meinInput statt input_meinInput oder meinInt statt int_meinInt. Aufgrund des Fixes muss nun aber bei Feldern vom Typ object von dieser Regel abgewichen werden: also object_2=14233 statt 2=14233, weil bei der jetzigen Implementerung nur so der oben beschriebene Fehler verhindert werden kann.

    Ob nun die Verwendung von Object-Feldern bei Conditions noch funktioniert, die mit we:condition erzeugt werden, muss ich erst noch prüfen...
    => eine definitive Lösung wird auf weiter verbesserten Condition-Tags beruhen, was jedoch nicht per sofort gemacht werden kann.

    • Previous Official Post

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login

Donations

200.00 EUR

Donate now

Tags

  • condition
  • listview
  1. Privacy Policy
  2. Legal Notice
Powered by WoltLab Suite™