Eben öffnete ich JOSM und wollte ein paar Daten herunterladen. Auf der Karte wurden mir keine brauchbaren Tiles angezeigt, sondern nur ein fettes X je Tile, egal welche Zoom-Stufe ich nahm. Dann wechselte ich auf die Lesezeichen, um darüber zu testen, ob überhaupt was geht.
Ergebnis:
Datenübertragungsfehler zum Server "https://api.openstreetmap.org/api/"
beim Hoch- oder Herunterladen.
Details: sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
Hinweise:
JOSM-Version 8229
Java-Version 1.7.0_40
(rund zwei Jahre alt)
Falls die Lösung in einem Update von JOSM und Java liegen sollte: darauf habe ich echt keinen Bock.
Die Tiles werden von …tile.openstreetmap.org seit ein paar Wochen (?) mit einem Zertifikat von let’s encrypt ausgeliefert. api.openstreetmap.org verwendet ebenfalls let’s encrypt. JOSM hat lets encrypt erst seit Version 10168 vom Mai 2016 eingebaut…
Könnte das der Grund sein? Vielleicht hilft ein Umstellen von https://{switch:a,b,c}.tile.openstreetmap.org/{zoom}… auf http://… beim Hintergrund. Sieht man dann die Kacheln, wäre das ein Indiz dafür, dass das das Problem ist.
Problem ist wohl auch die Java Version 1.7.0_40, die die Zertifikate von let’s encrypt (“DST Root CA X3”) noch nicht kennt. Ich weiß nicht mehr genau, ob eine neuere JOSM Version diese einfach automatisch nachinstalliert.
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)
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!
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.
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.
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.
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.
