ist eigentlich mal geplant JOSM auf ne anständige Programmiersprache zu bringen?
So langsam geht das Performancemäßig nicht mehr…wenn man ein Gebiet von nur etwa 10x10 km lädt
und dann 5 - 10 GPS Strecken geht der Rechner - egal ob dual oder sixcore - ziemlich in die Knie.
Und ich hab hier noch nicht mal ein stark ausgebautes Gebiet zum bearbeiten.
Eine Umstellung auf eine Sprache die Hardwareseitiges Zeichnen unterstützt (DirectDraw) wäre nicht schlecht…
da sind die paar Linien überhaupt kein Ding…
das Zeichnen von Linien ist nicht die Hauptarbeit von JOSM, sondern das Schaufeln der Daten im mitunter mehrstelligen MB-Bereich und Berechnen der Positionen auf dem Bildschirm aus den Koordinaten für jeden einzelnen Punkt. Zudem ginge verloren, dass JOSM auf unterschiedlichen Systemen lauffähig ist.
Nun ja…wenn das Zeichnen nicht das Problem ist, dann trotzdem die Performance von Java
Das Transformieren der Koordinanten auf die Bildschirmkoordinaten übernimmt doch die Grafikkarte…? Sonst würde das Hardwareseitige Zeichnen ja kaum Vorteile bringen.
Kann Java kein Multithreading, oder wurde das noch nicht implementiert? Dual-Core hat ja schon jeder…würde das ganze ja schon mal doppelt so schnell machen.
Und mit Sechskerner würde es dann auch wieder Spass machen…
Soweit ich mich erinnere gibts .NET Portierungen für diverse Betriebssysteme…und ich glaube die meisten User nutzen eher Windows…
Das Problem tritt auf, wenn man mehr als 5 GPX Strecken lädt…dann hab ich nur noch ne Diashow und kann kaum was machen…
Ich lade immer mehrere Strecken rein, um möglichst vereinzelte Abweichungen beim GPS Empfang auszuschließen…bei 10 Fahrten auf einer Strasse ist das schon ziemlich genau (in beide Richtungen).
An vielen Stell kann ich jetzt aber nicht mehr wie 2 sichtbar lassen sonst geht gar nichts mehr.
Alternative wäre das ganze zu optimieren - wozu geht JOSM alle Daten durch statt nur die die es für die Anzeige braucht? Die GPX gehen über 60 km Strecke…Zoombereich ist meistens unter 1 qkm!
Eigentlich müsste der nur den Sichtbaren bereich berechnen + den wohin verschoben wird, was ja nur wenige Millisekunden dauern sollte…
Merkaartor hat soweit ich mitbekommen hab Performanceprobleme…also das gleiche Problem bzw. ist mittlerweile glaube nicht mehr so weit wie JOSM.
Ich würd ja helfen…aber Java kann ich nicht Optimierung im Grafikbereich könnt ich sonst helfen…mache ja nichts anderes auf der Arbeit…
mag vielleicht für die Allgemeinheit gelten, aber bei OSM dürfte der Linux-Anteil recht hoch sein. Und bei JOSM dürfte er gegenüber Potlatch noch einmal erhöht sein.
also da gibts bei mir kaum Probleme. Haarig wird es nur, wenn man an gut editierten Orten rauszoomt, aber ehrlich, wer macht das immer??
Mir ist bei JOSM nur aufgefallen, dass er ein Speicherleck hat. So kann man das Vollaufen des Speichers forcieren, indem man beim Auswahlbildschirm des Daten herunterladen Dialogs viel zoomt und viele Gegenden besucht. Nach einer Weile steht Grafik-RAM und RAM bei 98%, deshalb sollte man JOSM nicht tagelang geöffnet haben.
Trotzdem…es soll ja eine Linux Version der .NET Bibliotheken geben, was keine Einschränkung darstellen würde
Ich hab das Problem gleich zu Anfang…lade ein nicht zu großes Gebiet und dann 5 - 10 GPX Strecken…und schon wird der Bildschirm nur etwa 1 mal pro Sekunde aktualisiert. Besonders toll wenn man ne Strasse detailieren will und den Punkt zwischen zwei zieht um einen neuen zu erstellen…das kommt dann auch immer mit einer verzögerung von einer Sekunde und mehr…und wenn man aus versehen dann die Strasse verschiebt ist man nur noch am warten weil der das dann noch rückgängig macht uswusw… puh…
Nach mehrfachem Zoomen verschlechtert sich das ganze…kann ich bestätigen. Um da überhaupt was machen zu können mus sich halt zieeemlich weit rein zoomen und ein paar der Strecken deaktivieren.
JOSM tagelang auf haben…?? Was machst du da?
Das mit der optimierung kann keine große Sache sein. Anscheinend werden hier immer alle Daten verarbeitet. Würde man nur den Zoombereich aus den Daten selektieren und nur diese verarbeiten + zeichnen hätte man ab einem bestimmten Zoomfaktor eine Datengrößenunabhängigkeit.
C# ist zwar nett und hat einige moderne Sprachfeatures, aber Performance ist ganz bestimmt kein zwingender Grund für C#. Wenn du wenigstens C/C++ vorgeschlagen hättest, könnte man das ja vielleicht ernst nehmen. Aber dann könntest du dir ja einfach Merkaartor runterladen und das Thema wäre vom Tisch…
Zu deiner Information:
Java konnte schon Multithreading, als es C# noch gar nicht gab.
Man kann unter Java hardwarebeschleunigte Grafik nutzen (über OpenGL).
Und nein, JOSM nutzt diese Möglichkeit wohl nicht. Aber sollten sich die Entwickler dazu entschließen, wäre es keineswegs nötig, die Programmiersprache zu wechseln.
Auf Nicht-Windows-Systemen existiert keine .NET-Implementierung auf dem aktuellen Stand. Es gibt Implementierungen von Dritten (-> Mono), die aber nicht mit dem Featureumfang des “Originals” gleichziehen.
Hast du wenigstens analysiert, woran das Problem liegt, bevor du hier die Programmiersprache als Sündenbock ausmachst? Ist dein Prozessor ausgelastet, wie ist der Speicherbedarf, …? Klingt für mich spontan eher, als ob du JOSM nicht genug RAM gönnst.
.NET gibt es nicht direkt für Linux, und wenn so was Ähnliches, dann nur mit eingeschränkten Möglichkeiten. Und unter mono - direkt mit Microsofts .NET - wird’s auch wieder langsam. Soll übrigens auch unter Windows nicht besonders schnell sein: http://de.wikipedia.org/wiki/.NET#Ausf.C3.BChrungsgeschwindigkeit
Ich weiß nicht, was du dir von “hardwaresetigem Zeichnen” versprichst. Meiner Meinung nach spielt es seine Vorteile erst bei 3D aus - entsprechende Grafikkarte samt Treiber vorausgesetzt.
Es werden nicht immer alle geladenen Daten verarbeitet. Je weiter ich reinzoome, desto schneller geht das Zoomen und Verschieben. Problem beim Verschieben ist aber immer noch, dass die Reihenfolge der Rohdaten nicht dem angezeigten Bereich entspricht, so dass trotzdem der geladene Bereich meist gänzlich durchforstet werden muss, damit alle Daten im Bildschirmbereich verfügbar und für die Anzeige aufgearbeitet sind.
Übrigens läuft Java auf mehreren Kernen. Verständlicherweise aber vorrangig bei Aufgaben, deren Resultate bei getrenntem Lauf unbhängig voneinander vorliegen können. JOSM sollte aber kein Mehrprozessorsystem voraussetzen.
AFAIK gibt es von MS nur .NET Frameworks für ihre Systeme. Das freie Mono-Projekt ist ungefähr bei .NET 2 angekommen und selbst das ist noch nicht vollständig implementiert. Aktuell befindet sich .NET in Version 4. Das zum Thema Plattformunabhängigkeit von .NET
Ich nutze zwar nie solche Mengen eigener Tracks, aber in der letzten Zeit beim Luftbilderpausen hab ich des öfteren mehr 40000 gps-Punkte vom OSM-Server geladen und nie Performance-Probleme gehabt. Auch als ich im Sommer meine Tracks einer 6wöchogen Radreise über jOSM eingearbeitet habe, gab es keine Probleme.
Dann bring dich doch bei Merkaartor ein. Das ist in C geschrieben, wenn ich mich recht erinnere. Die Aktualität eines Editors hängt schließlich primär von der Manpower ab.
Aah…oke. Also bisher habe ich immer nur gehört dass Java nicht Hardwarebeschleunigt zeichnen kann (sogar von Java Programmierern)
C# habe ich vorgeschlagen, weil es a) Java seeehr ähnlich ist (auch von Java Programmierern gehört; zumindest Syntaxmäßíg usw.) weshalb die Umstellung nicht so umständlich wäre wie nach z.B. C++ und b) dort Hardwarebeschleunigung dia DirectX und OpenGL möglich ist
Mit “anständig” meinte ich halt eine Programmiersprache die für eine CAD-Anwendung - was JOSM mittlerweile ist - entsprechende Performance bietet (z.B. das Hardwarebeschleunigte Zeichnen). Aber wenn Multithreading und OpenGL mit Java möglich sind dann dürfte das hier auch machbar sein…
Hätte ich momentan nicht schon genug am Haus zu tun wäre das ne überlegung…aber ich lerne schon mal von VB auf C# auf der Arbeit um und hier bin ich mit Renovieren und in JOSM basteln schon gut beschäftigt…neben den Projekten auf der Arbeit noch bei einem total unbekannten und auch noch in C einzusteigen…mh…dafür hab ich leider nicht die Zeit ;/
Lustig bei dem fehlenden Multithreading ist, dass die Coregeschwindigkeit ausschlaggebend ist. Mein neuer Dual-Core hier im HTPC (Athlon II 240e auf 2,95 getaktet) ist bei JOSM schneller als der 4-Kerner mit 4 x 2,6…
RAM war bis heute immer 1024 (seit über nem Jahr). Habe vorhin auf 1536 erhöht…hat aber nichts gebracht. Rechner hat 4 GB.
Nach ca. 1 h Arbeit mit diversen Uploads zwischendurch (aber keine GPS Strecken geladen…nur OSM + Bing Maps):
Last Changed Rev: 3800
Identification: JOSM/1.5 (3800 de)
Memory Usage: 315 MB / 1484 MB (76 MB allocated, but free)
Java version: 1.6.0_23, Sun Microsystems Inc., Java
Hast du wenigstens analysiert, woran das Problem liegt, bevor du hier die Programmiersprache als Sündenbock ausmachst? Ist dein Prozessor ausgelastet, wie ist der Speicherbedarf, …? Klingt für mich spontan eher, als ob du JOSM nicht genug RAM gönnst.
Das Problem tritt erst auf wenn die GPX Strecken sichtbar werden… Aufzeichnungsinterval sind 5 Meter. Bei 60 km Strecke und das ganze 5 - 10 mal …naja…kannst dir ja ausrechnen
Benutze jetzt auch vermehrt den “speziellen” GPX Export vom BT474 Tool. D.h. zu jedem Punkt wird ein Kreis gezeichnet welcher den DOP darstellt. Ein paar hundert Kreise per Software zeichnen könte das Hauptproblem sein…
Es passiert aber schon bei mehreren normalen Strecken…nur halt nicht so extrem langsam.
Hier wäre z.B. eine Optimierung seitens JOSM möglich, welche diese Kreise ab einer bestimmten Zoomstufe gar nicht mehr zeichnet. Ab etwa 1 - 2 km haben die ja nur noch wenige Pixel durchmesser und es bringt gar nichts diese zu zeichnen.
Versuche mal, das “Problem” ganz anders anzugehen:
a) JOSM aufrufen und NIX LADEN
b) “Datei → Öffnen” und dann 1-x GPX-Files öffnen
c) rechts oben Fenster Ebenen: rechts-Klick auf track
d) “OSM-Daten entlang der GPX-Spur herunterladen”
e) kleines Raster wählen und loslegen.
So arbeite ich sehr gerne, wenn ich neue GPX-Tracks erfassen will und dafür nur die Umgebung der Tracks brauche.
gruss
Walter
p.s. Fehlermeldungen und Beschwerden bitte in mündlicher Form an unseren Hausmeister,
Danksagungen in schriftlicher Form an unseren Chef.
Ich lade einen kleineren Bereich statt um die Strasse herum (ich weiß ja wo ich schon was optimiert hab und wo ich muss + ist viel schneller). Wie erwähnt handelt es sich hauptsächlich um 55 - 65 km lange Strecken, wo ca. 30 Serverabfragen durchgeführt werden, was sehr lange dauert.
Ich selektiere einfach einen kleinen Bereich von wenigen Quadrat km und bearbeite dort…und auch wenn ich in diesem Bereich auf ca. 200 x 200 Meter zoome ist es so lange langsam, bis ich nur 1 - 2 der GPX sichbar hab und die anderen unsichtbar gestellt hab
EDIT:
Habe jetzt mal folgendes getestet: 10 Strecken geladen → komplett raus gezoomt, damit alles sichtbar ist (kein Bing, keine OSM Daten) → aktualisierung gefühlte 1 - 2 mal pro Sekunde
Habe dann die Wegpunkte + “Elevation profile” deaktiviert → viel besser! Hauptsächlich durch deaktivieren des Elevation profiles … was ist das überhaupt??
Nachdem ich dann für einen Bereich die OSM Daten geladen hab gings ohne den elevation profile viel flüssiger wie mit. Die Wegpunkte bremsen auch, aber nicht soo sehr (denke mal,dass hier das Zeichnen des Textes viel Performance schluckt).
hi, nur um ganz sicher zu sein:
du lädst die “nackten” gpx-files, die vorher mit bt747 erstellt wurden (mach ich auch) und hast die dann als dünne violette Linie auf den Schirm?
Hb ich nie Probleme mit gehabt - und sollten auch absolute peanuts für josm sein.
evelations profiles hat was mit Höhen/Steigungen zu tun. Benutz ich nicht. Aber für Wanderer/Radfahrer ist sowas eventuell wichtig???
Wegpunkte zeig ich auch nie an, da sie mir nix bringen. ich mach fotos an wichtigen stellen und synchronisiere die aufgrund des timestamps. macht josm auch automatisch, wenn man das will.
gruss
walter
Das Zeichnen der Kreise kannst du in Einstellungen → Button “Allgemein” → Reiter “GPS-Punkte” ein und ausschalten (ca. 12. Zeile). Das ist als Auswahl (erster Button, erster Reiter) voreingestellt, wenn du die Einstellungen aufrufst.
Kannst ja mal probieren, ob es am Zeichnen der Kreise für die Genauigkeit liegt.
Falls ja, weist du a) wie du es vermeiden kannst und b) um was man die JOSM-Entwickler bitten könnte.
Für b) gilt: Je genauer ein Problem eingegrenzt ist, desto eher kann man die Ursache analyzieren und gegebenenfalls eine Änderung einbauen.
Auch deine Erfahrungen mit dem Plugin Elevation-Profile könnten wichtig sein.
Ich hab die Linien PLUS Kreis je GPX Punkt…denke mal dass hier das Problem liegt. Beim BT747 kann man ja GPX und “GPX for OSM Upload” wählen. Ich hab das erstere genommen, da ich ja die Zusatzinfo über die Qualität (DOP) haben wollte.
Die Bedeutung des Layers verstehe ich - nur nicht was der darstellt. Ich seh da nämlich nichts Der hatte bei mir die Strecken anfangs aber nicht farbilch gekennzeichnet bzw. reicht es aus wenn ich eine “OSM GPX” exportiere - wird diese sich dann farblich unterscheiden je nach DOP?? Ich bin mir sicher dass die Strecke vorher immer nur einfarbig war…
Wegpunkte benutze ich um Abzweigungen auf der Rechten Strassenseite zu markieren. Bisher nur zwei mal als Beifahrer gemacht, da es während der Fahrt doch zu sehr ablenkt nach den ganzen Feldwegen und Strassen in der Stadt ausschau zu halten un im richtigen Moment abzudrücken Aber wenn das Wetter endlich besser ist werd ich das mit dem Fahrrad genauso machen.
Die Kreise sind die Performaceschlucker…wenn ich die deaktiviere läuft es “wie früher”. Hatte früher den WSG 1000 benutzt, wobei ich mir sicher bin dass der die DOPs auch weggeschrieben hat.
Kann sein dass JOSM die damals (Ende 2009) noch nicht darstellen konnte? Die Linien waren einfach nur komplett violett und es waren früher keine Kreise da. Hab erst seit etwa einem halben Jahr den BT747+…
Das deaktiveren von “Große GPS Punkte zeichnen” bringt auch noch einiges…aber wenn man einen kleineren Bereich rein zoomt, mekrt man das kaum. Die größeren Punkte kann man dafür besser erkennen. Abschalten der Linien hat merkwürdigkerweise überhaupt keine Performancesteigerung gebracht…?
Vielleicht sollte man bei JOSM mit in dieses Menü einbauen, dass das aktivieren von Kreise zeichnen (was glaube standardmäßig an ist) zu starkem Performanceeinbruch führen kann
Vieelen dank! So arbeitet es sich doch gleich viel besser… :]
2 Grad Plus sind doch kein Grund, nicht mit dem Rad zu fahren.
Habe gestern erst eine 20km Tour gemacht.
Wenn ich mit dem Rad mappe, fahre ich mit dem Rad immer ein kurzes Stück in die abzweigenden Wege rein und wieder zurück. Das scheint mir einfacher und ich habe gleich die Richtung und Anzahl der Wege. Damit kann ich dann gleich noch kontrollieren, wie gut (oder eben nicht) meine Tracks mit den bereits vorhandenen Wegen zusammen passen. Falls ein Weg noch nicht erfasst sein sollte, kann ich zumindest den Anfang mal eintragen.
