Map-Konfigurationsdatei: Kommazahlen <10 als Koordinaten-Offset zur relativen Position gibt Fehler

  • Hallo Zusammen,


    ich bin gerade dabei, eine automatische Generierung der Map Configurationdatei aus einer XML Datei umzusetzten.
    Dabei habe ich folgendes Problem festgestellt:
    Bei den Koordinaten für Linien arbeite ich häufig mit den IDs anderer Objekte und ergänze diese um Zahlenwerte (Beispielhafte Form (ID%+Zahl): 2453e%+128)
    Bei Zahlenwerten >10 ist es kein Problem, wenn diese eine Kommazahl ist (10.879 kann problemlos verarbeitet werden). Ist die Zahl jedoch einstellig, gibt es einen Fehler, wenn diese Nachkommastellen hat. (d.h. 3.968 kann nicht verarbeitet werden)
    Die Fehlermeldung ist dann folgende:
    Das Arrtibut "x" in einem Element vom Typ Host in der Karten-Konfigurationsdatei "test" entspricht nicht dem korrekten Format.


    Woran könnte das liegen?
    Ich kann natürlich durch Abschneiden der Nachkommastellen für diese Fälle eine Umgehung dieses Problems erzwingen (was auch keine große Sache wäre, da diese Nachkommastellen kaum einen Einfluss auf das Aussehen haben) jedoch fände ich interessant zu wissen, woran dies liegt und natürlich wäre die Lösung etwas sauberer, wenn ich die Zahl wie vorgegeben nutzen könnte.


    Vielen Dank schon mal im Voraus für die Antworten. Sollte es schon einen Thread zu diesem Thema geben, wäre ein Link dazu super, da ich nichts gefunden hab.


    Grüße,
    Thiya

  • Danke für die schnelle Antwort.


    Ja dann geht es. Das wäre eine zweite Möglichkeit für ein Workaround, die ich auch schon mal kurz in Betracht gezogen habe. Ist sogar die bessere, wenn ich jetzt drüber nachdenke. Danke für den Hinweis :)


    Finde es grundsätzlich aber immernoch seltsam, da ich, wenn ich keine Kommazahl verwende, ohne Probleme auch einstellige Zahlen verwenden kann. (also nur +3) und bin daher immernoch am Hintergrund für diesen Frage interessiert.
    Für meine Anwendung werde ich jetzt erstmal eine 0 voranstellen.

  • In server/core/defines/matches.php gibt es eine Reihe von Mustern. Vermutlich reicht es, wenn man das folgende anpaßt:

    Code
    1. define('MATCH_COORDS_MULTI', '/^(?:(?:(?:[0-9]+)|([a-z0-9]+(?:%[+-][0-9]+)?))[\.\,]?)+$/');


    Evtl. so

    Code
    1. define('MATCH_COORDS_MULTI', '/^(?:(?:(?:[0-9]+)|([a-z0-9]*(?:%[+-][0-9]+)?))[\.\,]?)+$/');
  • Ich hab versucht die Änderung nach deinem Vorschlag umzusetzten, aber das hat leider nicht den gewünschten Erfolg gebracht.
    Leider fällt es mir im Moment etwas schwer herauszufidnen, was genau hinter dieser Zeile steckt (Grob versteh ich es), daher weiß ich nicht welche Veränderungen ich noch ausprobieren könnte.
    Gibt es dazu irgendwo eine Dokumentation oder ein Begriff nach dem ich suchen könnte, um herauszufinden, welche Muster hier genau definiert werden?
    Das wäre super :)

  • Danke, das war das Stichwort das ich brauchte.


    Dann werde ich mich demnächste mal etwas darin einlesen und schauen ob ich es verstehe und die Lösung finde.
    Falls jemand sich damit auskennt, freue ich mich natürlich auch, wenn mir jemand die Lösung für die Veränderung der Definition geben kann. Das würde mir ein weiteres Thema zum Einarbeiten im Rahmen meiner Thesis ersparen.

  • Guten Morgen,


    Wenn ich den Eintrag in der matches.php wie vorgeschlagen ändere, ändert sich nichts an der Situation.
    Die Fehlermeldung lautet immer noch:
    Das Arrtibut "x" in einem Element vom Typ Host in der Karten-Konfigurationsdatei "test" entspricht nicht dem korrekten Format.


    und wenn ich den einstelligen Eintrag abändere und manuell eine 0 davor schreibe oder die Nachkommastellen löschen, löst sich das Problem.
    Was für eine Beispielzeile meinst du?
    Von dem PCRE-Muster (sieht aus wie in deinem Kommentar) oder von meinem Eintrag in der Konfigurationsdatei (hat sich nicht zur ursprünglichen Frage geändert) oder meintest du die Fehlermeldung? Oder gibt es irgendwo noch eine Art Logdatei, wo angezeigte Fehler noch etwas aufgeschlüsselt dargestellt werden?


    Vielen Dank für die großartige Hilfe :)

  • Bei den Koordinaten für Linien arbeite ich häufig mit den IDs anderer Objekte und ergänze diese um Zahlenwerte (Beispielhafte Form (ID%+Zahl): 2453e%+128)

    Vermutlich gibt es bei der Verarbeitung einer dieser Zeilen den o.g. Fehler. Wie sieht diese Zeile aus? Abhängig vom Aufbau greift ggf. ein anderes Muster.

  • die Zeile die den Fehler auslöst sieht folgendermaßen aus:
    x=47%+2.048,140


    wobei 47 eine ID eines anderen Objektes ist und 2.048 der Wert, um welchen der x-Wert des Beginns der Linie im Verhältnis zu diesem Objekt verschoben wird.140 ist ein Pixelwert (keine ID).
    Wie gesagt, die Fehlermeldung verschwindet genau dann, wenn ich 2.048 zu 2 oder zu 02.048 abändere. Daher gehe ich tatsächlich davon aus, dass deine erste Vermutung über das Format richtig ist und ich dieses in der matches.php abändern muss. Im Moment nutze ich deinen Tipp mit der 0 vor der Zahl, werde dieses sobald ich Zeit finde mich mit PCRE zu beschäftigen aber hoffentlich noch auf eine ordentlichere Version abändern können.

  • Das Problem tritt beim Laden einer extern generierten .cfg Datei, welche ich auf den Server lade, auf.
    Die GUI verwende ich gar nicht.

  • Hallo Thiya,


    wofür brauchst du denn die Nachkommastellen bei den Pixel-Koordinaten? Die Koordinaten im NagVis auf den regulären Maps sind Koordinaten, die sich auf ganzzahlige Pixel im Browser beziehen.
    Also sind die Nachkommastellen im Grunde überflüssig und du kannst sie streichen, oder? Der reguläre Ausdruck meckert hier also zurecht. Es ist im NagVis nicht vorgesehen für die regulären Maps Fließkommazahlen als Koordinaten zu benutzen. Falls es in gewissen Konstelationen geht, ist es eher ein Versehen als das es gewollt ist.

  • Eigentlich brauche ich sie gar nicht. Mein Ziel war nur eine ordentliche Lösung zu bekommen (selbst wenn die Nachkommastellen kaum Einfluss haben, wie oben geschrieben). Da sie aber tatsächlich absolut keinen Einfluss haben (was ja auch Sinn macht, da es halbe Pixel ja nicht gibt, soweit habe ich nicht gedacht :) ), werde ich sie dann doch abschneiden. Das sieht etwas ordentlicher aus, wie eine 0 davor zu hängen.


    Zudem hat es mich einfach interessiert, wie es zu so einem Fall kommen kann, das hilf immer etwas im Gesamtverständnis.


    Vielen Dank euch beiden für die Hilfe :)