Vorübergehender Defekt oder API-Änderung?

Tja, dann eben iD :wink:

@wambacher
Fragt sich, ob iD ordentlich funktioniert, wenn der Rest vom Computer genauso lange nicht aktualisiert wurde.

Kann man JOSM die Verwendung von ssl generell ausreden?

Bei den Verbindungseinstellungen kann man als API-Server auch “http://api.openstreetmap.org/api” ohne “s” hinter “http” eingeben. Bei den Tiles auch… Die Übertragung wäre halt nicht verschlüsselt, aber dafür ginge es, falls nicht irgendwo tief im Programm noch wichtige Funktionen auf https angwiesen sind.

Grüße
Max (ders nicht getestet hat, mit meiner Version hilft ein Test nichts)

Wieso?

jo, da könnte was dran sein - auch Potlatch hat ja seinen Anforderungen.

Der Trick von maxbe war mir einen Versuch wert: habe die preferences.xml nach https durchsucht und das auf http geändert. Hilft leider nicht. Fehlermeldung beim Start:

JOSM versuchte auf folgende Ressourcen zuzugreifen: 
https://josm.openstreetmap.de/maps
https://josm.openstreetmap.de/wiki/De:StartupPage
https://api.openstreetmap.org/api/capabilities
Dies schlug allerdings auf Grund folgender Netzwerk-Fehler fehl: 
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Allerdings gibt es auf dem Dialog noch die Auswahl, “Ändern Sie Ihre Proxy-Einstellungen”. Und dort verbleibe ich dabei, keinen Proxy einzusetzen, aber die API-URL kann ich manuell eingeben und auf http umstellen.
Damit sehe ich immer noch nicht die Karte im Herunterladen-Dialog.
Nächster Trick: auf das “Plus” am rechten Rand der Karte klicken, und “Mapnik” durch “CycleMap” ersetzen.
Beim Start von JOSM verbleibt nun obiger Dialog, um eine Fehlermeldung weniger. Den klicke ich einfach weg
Habe es nun mit einem kleinen Changeset ausprobiert: es geht.
Besten Dank, Max!

Und in dieser Zeit hättest du locker fünfmal Java und JOSM aktualisiert. :roll_eyes:

Wahrscheinlich zu einfach.

https://xkcd.com/1782/
SCNR

Nicht ganz, IRC-Server und -Clients werden schließlich auch heute noch weiterentwickelt und können aktualisiert werden. :wink:

Quatsch! Von der Java-Version hängt mkgmap ab. Eine Aktualisierung von mkgmap heißt, daß mein eigener Style Änderungen benötigt, die ich erst später auf dem Garmin-Gerät während des Einsatzes erkenne. Das bedeutet etliche Stunden Aufwand.
Kids, laßt bitte den Quatsch und drängt nicht alle Leute zu allerhand Updates, deren Konsequenzen ihr nicht abschätzen könnt.

Das interessiert mich als Mitentwickler von mkgmap.
Du verwendest also eine alte Java Version, weil Du eine alte mkgmap Version verwenden willst bzw. musst?
Welche Änderung in mkgmap ist denn das Problem?

@GerdP : momentan verwende ich mkgmap 3686. Da in der Mailing-List immer wieder mal beim Aufkommen neuer Java-Versionen irgendwelche Probleme angesprochen wurden, will ich ein Update von Java solange wie möglich vermeiden. Da es bei einem früheren Update von mkgmap einen Bruch beim Style gab (“name” wurde umgestellt), meide ich auch Updates von mkgmap. Schließlich funktioniert meine Karten-Erstellungskette momentan ordentlich.

Hallo Bernhard,

die Probleme mit Java 8 sind durch einen Workaround(r3733) umgangen, ansonsten wüste ich von keinen Änderungen seit 3868, die
Probleme mit Deinem Style verurachen könnten. Für ein Update sprechen zumindest ein paar Korrekturen bei der Kodierung
von Routing-Infos.

ciao,
Gerd

Ich kann die Vorbehalte ein Stück weit verstehen. Ich versuche auch, Updates von mkgmap zu vermeiden, weil es keine stable builds gibt sondern alle Versionen mehr oder weniger experimentell und auch mal für eine Überraschung gut sind. Eine Version von mkgmap hat die Reihenfolge der Objekte zufällig durcheinandergeworfen, sie spielt aber bei vielen Geräten eine Rolle - das führte dann zur Einführung von --preserve-element-order.
Es kommt gelegentlich vor, daß sich etwas am Verhalten ändert und stillschweigend im default-Stil kompensiert wird. An das plötzliche Verschwinden aller Namen in den Karten kann ich mich auch erinnern, das hat mich ebenfalls kalt erwischt. Wir haben uns neulich wegen der Probleme mit --precom-sea unterhalten, die auch eine Renderregel mit “skipFilter” erforderte, die nirgendwo erwähnt sondern nur im Default-Stil vorhanden war.

Hinweise auf solche Änderungen (in der Art von release notes) gibt es leider nicht. Wer den Default-Stil nicht benutzt sondern seit Jahren einen eigenen Stil pflegt, bemerkt dann irgendwann später zufällig daß etwas fehlt oder anders angezeigt wird und muß recherchieren woran das liegen könnte.

Nachdem Du freundlicherweise das Problem mit dem ignorierten skipFilter gefixt hast, habe ich auch eine ganze Weile gegrübelt ob ich lieber mein altes mkgmap und meinen Workaround behalte oder auf die neuste Version gehe um Deinen Fix zu bekommen aber dabei unerwünschte Nebenwirkungen riskiere.

Hab dann doch upgedated. Aber nicht ohne vorher die Mailingliste nach Beschwerden in den letzten paar Wochen zu scannen. :slight_smile:

bye, Nop

Hallo Nop,

ich finde auch, dass Änderungen an mkgmap möglichst so gemacht sein sollten, dass vorhandene Styles weiter funktionieren.
Zumindest in den letzten Jahren sollte es da keine Probleme gegeben haben.
Leider gibt es in der mailing liste
http://www.mkgmap.org.uk/dev/maillist
wenig Feedback, wenn es darum geht, geplante Änderungen zu testen oder Patches zu kontrollieren, da ist es immer möglich, dass
etwas übersehen wird.Passiert ja sogar bei JOSM, was sicher von viel mehr Leuten benutzt wird.

Ich kann übrigens nach wie vor nicht nachvollziehen, warum die Verwendung von precomp-sea Änderungen an Deinen rules nötig gemacht hat. Wäre schön, wenn Du das reproduzieren könntest.

Gerd

Notfalls lassen sich selbstverständlich auch mehrere Versionen von Java parallel installieren. :wink:

Hm, schau mal:

Dim WshShell
Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Run "C:\Windows\System32\java.exe -Xmx4G -jar ""C:\Program Files (x86)\OpenStreetMap\JOSM\josm-latest-8229.jar""", 0

Siehst du den Pfad? C:\Windows\System32\java.exe! Gewiss, da bin ich derjenige, der es in der Hand hat, ein Skript zu bearbeiten und den “richtigen” Pfad einzutragen, d.h. mit “C:\Program Files\Java\jre7\bin” zu ersetzen, falls die nächste Version obige Executable überschreibt. Auch bei mkgmap könnte ich das. Java verwendet noch ne Reihe von Umgebungsvariablen, die systemweit gesetzt werden. Was mache ich da? Dumm schauen?!
Und was ist mit anderen Programmen? Ich habe das noch nicht durchsucht, was alles davon abhängt. LibreOffice, oder? Und womöglich noch weiteres: Unüberschaubar.

Wenn sich ein Update sauber auf ein Programm beschränkt: kein Problem, mache ich. Wenn ich aber eine Änderung machen soll, die so tiefgreift: da gibt’s nur ein klares NJET.
Früher mal, so in den 90er Jahren, spielte ich auch unmäßig viel rum, multiple boot mit Windows 3.1, OS/2 (kennt das noch jemand?), Slackware (wem sagt das noch was?). Inzwischen ist der Computer ein Gebrauchsgegenstand: er muß laufen. Nicht anders als Kühlschrank oder Waschmaschine auch.

Gerd, danke dir für die Mühe, die Releasenotes durchzuschauen. Auch wenn du mit bestem Wissen und Gewissen sagst, du wüßtest von keinen Änderungen, die Probleme verursachen könnten, so kannst du es nicht garantieren.
Ich erstelle gewöhnlich 3 Karten für Mitteleuropa, so daß das Routing sowohl mit dem Fahrrad als auch mit dem Auto trotz der “activity routing”-fähigen Firmware des Oregon funktioniert (und mich nicht mit dem Auto über Radwege oder durch Fußgängerzonen leitet):

  • eine Karte mit routing-fähigen Linien für das Rad
  • eine Karte mit routing-fähigen Linien für das Auto
  • eine gemeinsam genutzte Karte mit POIs, Flächen, sonstigen Linien, Adressindex
    Dazu kommt als 4. noch eine Karte mit Höhenlinien, die aber keiner Neuerstellung bedarf.
    Außerdem habe ich die Sprachdatei des Oregon geändert, so daß ich POIs anders verwenden kann.
    Gewiss ist es nicht nötig, daß ein Testlauf mit diesem kompletten Umfang gemacht wird - das dauert über 2 Stunden an Rechenzeit (zuzüglich Download der Extrakte): Format-Umwandlung, kobinieren, splitter, mkgmap. Dann auf die Speicherkarte des Garmin kopieren, und ein paar Sachen von Hand prüfen (wie könnte ich das denn automatisieren?)…

Bernhard,

stimmt, ich kann Dir nur eins garantieren: In r3686 gibt es Fehler, die es in den neueren Versionen nicht mehr gibt.
Eine automatisierte Funktions-Kontrolle der generierten Karten ist leider exterm schwer zu realisieren, hätte ich auch gerne.

Gerd