Hallo Nop,
gibt es schon was neues bzgl. des Fehlers bei srtm2osm während der Konturdichteanalyse? Würde es helfen, wenn ich den Fehler an anderen Orten auch bekomme?
Edit:
Gerade hab ich in dem Fall eine neue Erkenntniss gewonnen.
Beim Erstellen der Karte befinde ich mich nödlich von 60°. srtm2osm findet zu diesem Gebiet also keine Höhendaten, da die NASA hierfür keine zur verfügung stellt. (Diese kann man sich aber von anderer Quelle herunterladen). Die Daten waren im srtm-Cache vorhanden und der Konturdichtefehler trat irgendwann auf (bei 30000/36000, also recht ärgerlich).
Dann kam ich auf die Idee auszuprobieren, was passiert, wenn ich hier den srtm-Cache lösche.
Und oh Wunder: Der Composer läuft weiter.
Ein Vorschlag noch für die Überbrückung. Kannst du den Fehler nicht abfangen, ihn als MsgBox ausgeben und den User Fragen, ob er für diesen Bereich 0 als Höhenlinienkonturdichte eintragen möchte und dann ganz normal weiter rechnen?
Klar, das ist die Ursache. Nördlich von 60° geht natürlich nichts mit srtm2osm. Ehrlich gesagt habe ich über den Fall noch gar nicht nachgedacht, aber der läßt sich ja leicht nachstellen und sicher auch irgendwie umgehen. Danke für’s Finden.
Der Fehler tritt ja überall auf. Ich hatte ihn schon in Nordwestbrandenburg, Norwegen, Schweden, Finnland, irgendwo in Bayern oder Baden Württemberg. Einzig in Nord- und Westdeutschland trat der Fehler nicht auf. Da die lokalen Höhendaten unter Version 0.77 ohne Probleme funktioniert haben, gehe ich mal davon aus, dass sie nicht defekt sind.
In Gegenden, wo srtm2osm neue Daten herunterladen kann, kam ich an den Stellen nicht weiter. Erst mit deinem density-File. In Norwegen ist es mir nun gelungen, durch ein Löschen des srtm-Caches den Composer dazu zubringen über die Fehlerstelle drüber zu springen.
Ok, zu früh gefreut. Aber bisher hast nur Du über Probleme mit srtm2osm berichtet, es könnte also ein lokales Problem mit der Umgebung auf Deiner Maschine sein. Ich habe z.B. die Density.tbl für D/Ö/CH ohne Probleme berechnet bekommen. Größenprobleme können wir wohl ausschließen, da immer nur ein Planquadrat von 0.1x0.1 analysiert wird.
Aber laß uns der Sache mal auf den Grund gehen.
Kannst Du bitte mal nachsehen, welche Versionsnummer srtm2osm auf der Kommandozeile ausgibt?
Tritt das Problem in bestimmten Planquadraten immer auf oder ist es zufällig?
schnell oder erst nach einer Weile?
Tritt es auf wenn Daten heruntergeladen werden müssen, wenn sie schon vorhanden sind oder in beiden Fällen?
Dann eine neue Regel 1 hinzufügen (z.B. Wege, Bedingung highway=living_street, Austausch durch highway=residential)
Rechte Maustaste Regel 1 => Kopieren
Ein Fenster geht auf mit dem komplette Inhalt von Regel 1
Regel ändern (z.B. Name=2, Bedingung highway=trunk, Austausch durch highway=motorway)
Wenn ich jetzt Regel 2 öffne steht dort die Bedingung “bicycle=designated”, Aktion Icon einblenden und Tag setzen highway=real_cycleway. (Woher kommt diese Regel?)
Regel 1 enthält Bedingung highway=trunk, Austausch durch highway=motorway
Das Problem tritt immer an der selben Stelle auf. Wann es auftritt hängt nur davon ab, wann die entsprechende Stelle dran ist. Es tritt sowohl auf, wenn die Daten lokal vorliegen als auch, wenn sie heruntergeladen werden müssen. Es sei denn, srtm2osm kann keine Datei finden (siehe weiter oben).
Das Problem von WanMil tritt übrigens schon länger auf. Es ist mir bisher nur entfallen, dich drauf hinzuweisen. Es gibt diese Tag-Vertausch Probleme übrigens auch, wenn man mehrfach neue Ersetzungen erstellt.
Danke, jetzt ist es klar. Die Vertauschung von Regeln ist im rc2 behoben. Mitkopiert werden Unterregeln aber erst mal nicht, das wäre ein ziemlicher Aufwand.
Kannst Du das Problem bitte mal provozieren und dann in der command.log den entsprechenden Kommandozeilenaufruf inklusive Fehlermeldung rauskopieren und posten/mir schicken?
Hallo Nop,
noch eine Frage zum Composer.
Wenn ich bei einer Region als Datenquelle “Lokale OSM Datei komplett” auswähle, dann muss ich immer noch zusätzlich sinnvolle Parameter für Länge und Breite eingeben. Ist das so gewollt? Eigentlich hätte ich erwartet, dass er die Bounding-Box in diesem Falle aus dem OSM File übernimmt. Worin liegt sonst der Unterschied zu “Ausschnitt aus Planet Datei”?
Bei “Ausschnitt” stutz er eine größere Datei mit Osmosis zurecht, bei “komplett” nimmt er alle Daten so wie sie daliegen. Ist für bereits vorbereitete Daten. Die Bounding box nimmt er deshalb nicht, weil keiner sagt, daß eine OSM-Datei eine haben muß, die kann genausogut fehlen.
Nummer 1:
Nach dem Ändern der Koordinaten einer Region scheint er die neuen Koordinaten nicht in der Verarbeitung zu verwenden. Erst wenn man die alte Region unter Werkzeuge => Kartensegmente löscht und alles neu berechnet, scheint er die neuen Koordinaten zu verwenden.
Nummer 2:
Werkzeuge => Kartensegmente
rechte Maustaste auf einem Segment und dieses löschen
Es wird korrekt gelöscht, aber in der Liste verschwindet das Nachfolgende. Das gelöschte wird weiterhin angezeigt (ist aber nicht mehr da). Vermutlich ein fireXXRowDeleted(index) statt fireXXRowDeleted(index-1) im TableModel aufgerufen?
Zu Nummer 1: Woher soll der Composer denn wissen, dass du die Region verändert hast? Sicherlich kann man das auch auslesen, aber wie häufig ändert man eine Region und wie häufig würde diese Überprüfung unnötig laufen?
Es reicht doch, wenn du im Job einen Haken bei “Kachelnaufteilung berechnen” setzt.
@nop: Generell könntest du mal alle Menüs durchgehen und gucken, ob bei weiter bzw. zurück die indexe stimmen. Bei mir verhalten sich alle Listboxen “klickversetzt”.
ich klicke --- composer macht
weiter nichts
weiter weiter
zurück weiter
zurück zurück
usw.
Das ist einer von den Fällen, wo man eine Neuberechnung von Hand anstoßen muß. Ich habe früher mal versucht, das automatisch zu erkennen, hat aber nicht zufriedenstellend funktioniert. Es gibt aber extra einen Absatz in der Anleitung, der dieses Thema erläutert.
Es kommt gelegentlich mal vor, daß das so aussieht, nach der nächsten Bewegung in der Liste sollte aber wieder alles ok sein.
Hallo,
ich habe jetzt schon eine recht zufriendenstellende Radkarte aus meiner näheren Gegend gebastelt.
Jetzt will ich mich an eine Skikarte für den kommenden Urlaub ranmachen. Dazu meine Frage:
Wie bekomme ich es hin das die Richtung ausgewertet wird. Skipisten sind ja nunmal Einbahnwege, daher würde ich gerne auf jeder Piste einen Richtungspfeil einesetzen. Hat jemand einen Tipp wie ich das mit dem Composer umsetzen kann ?
