Bei meiner Android-Box läßt sich der Layerchanger nicht öffnen.
Tablets sind groß genug, da sollte eine Anwendung wie Historic.Place laufen.
Bei Smartphones bin ich eher skeptisch ob es das braucht…
Eigentlich bräuchten wir solche Tests regelmäßig.
Oft erfahren wir so nebenbei, das etwas schon ein halbes Jahr nicht funktioniert.
Dann ist es schwer nachzuvollziehen, ab welcher Änderung das war.
Und wir Basteln fast jede Woche irgenwas rum
Hallo, Historic Place wertet jetz memorial=bust/stone/stele mit eigenen Icons aus.
Die läßt sich jetzt auch mit der Josm-Vorlage Historische Objekte mappen.
dank Zecke, und den Entwicklern der Overpass-API, wurde auf Historic.Place eine lokale OP-API installiert
Als erste Test-Verwendung werden die Monumente von CheckTheMonuments aus der eigenen OP geladen.
Die Statistik wird jetzt ebenfalls von unserer OP geholt, und kann bei Bedarf erweitert werden…
win8/firefox44.0.1 kein Eingangsbild, Meldung: unreachable code after return statement nls.api.js:84:1
den Fehler erkenne ich dort nicht.
android4.4.2WebKit534.30 kein Eingangsbild, Layerchanger funktioniert einwandfrei.
android4.4.2Chrome56.0… kein Eingangsbild, Layerchanger ist nicht anzusprechen.
Entschuldigung, ich war nicht auf der Höhe der Zeit und habe das Ergebnis eines alten Permalinks verwendet, deshalb gab es kein Eingangsbild.
Mir geht es um http://gk.historic.place/historische_objekte/
Eingangs-Karten-Bild ist also jetzt vorhanden.
Meldung unreachable code bleibt (Warnung nur in firefox feststellbar)
Der LayerChanger bei Android ist unter dem vermeindlich älteren System ansprechbar, unter meinen Chrome Systemen eben nicht.
Weiterer Test
Android6.0.1 Chrome44.0…WebKit 537.36 LayerChanger ist nicht anzusprechen.
Danke für die Info,
habe mal Konqueror gescheckt, läuft auch nicht mehr richtig.
Diese Browser-Unterschiede sind einfach ein Krampf, mal sehen, ob wir das Problem finden…
In ol3 laß ich den button unabhängig vom panel stehen und benutze ihn zum öffnen und schließen.
siehe http://www.roeltgen.com/mgrs/mgrs3ol.html . Das war erst die Notlösung, scheint aber zu funktionieren.
Vermutlich würde dies in ol2 auch ein Problemlöser sein.
Danke für den Tipp, coole Karte, Openlayer 3 macht schon was her…
Das Problem sollte gefixt sein, bei den mir zur Verfügung stehenden Browsern läuft alles.
Hallo,
Historic.Place wertet jetzt auch ref:bldam im Popup aus.
Stichproben ergaben, das viele Objekte beim ns.gis-bldam-brandenburg.de nicht gefunden werden
Ob die Datenbank erst im Aufbau ist, oder die ref:bldam in OSM falsch ist kann ich nicht beurteilen.
Vieleicht weiß ja ein Brandenburger mehr?
ist solch eines… Als Objektnummer steht in der Datenbank 09140461,T Für den Aufruf wird der auch so in der Karte verwendet, erzeugt aber einen Fehler. Ersetzt man aber im xml-Aufruf das große T durch ein kleines t, funktioniert es… http://ns.gis-bldam-brandenburg.de/hida4web/view?docId=obj09140461,t.xml
Das könnte alle Denkmalobjekte betreffen, die beim ObjektID ein Komma mit nachfolgendem T haben.
beim Verlinken der Kulturdenkmäker in Hessen auf Historic.Place bin ich auf folgende Ungereimtheiten gestoßen:
Im Wiki wird als Abkürzung einmal “ref:LfDH” , und in der
selben Zeile bei den Tags “ref:lfdh” beschrieben.
Somit wird auch beides laut taginfo verwendet.
Üblich ist wohl alles klein schreiben?
Die aktuelle Josm-Vorlage Heritage benutzt “ref:LfDH” .
Bei “ref:lfdh” wurden fast alle mit “ref:lfdh=N” gemappt.
Ob dies ein Fehler einer Vorlage ist/war, kann ich nicht beurteilen.
Jedenfalls sollte an der Stelle des “N” die Nummer in der Denkmalliste stehen.
Eventuell kann sich jemand aus Hessen der Sache annehmen?
Ein Einheitliches “ref:*” im Wiki und der Josm-Vorlage wären auch hilfreich
Zur Zeit werten wir beides aus:
Ich würde den Fehler auf der Wiki- Seite so berichtigen das es “ref:LfDH” heißt.
Es sei den hier wird jetzt beschlossen, dass nur kleine Buchstaben verwendet werden, dann muss auch die Vorlage und ein paar Eintragungen in der Datenbank berichtigt werden.