Nachdem ich nun mit der Entwicklung meines kleinen Kartenprojektes mit Hilfe von OSM/ Openlayers großteils fertig bin geht es nun an das Performancetuning. Bisher hatte ich nur einen Link zur aktuellsten Version von Openlayers (http://www.openlayers.org/api/OpenLayers.js) eingebunden, was aber aufgrund der Größe des Skripts für den Produktiveinsatz viiieeel zu lange zum Laden braucht. Jetzt hab ich mich auch schon ein bisschen umgesehen und gehört, dass man sich eine eigene angepasste Version des Skripts erstellen kann, das nur die nötigsten Teile beinhaltet. Dieses würde ja dann auf dem eigenen Server liegen und nicht mehr bei OpenLayers.
Genau das wirft für mich nun die Frage auf, wie es in diesem Fall nun mit Aktualisierungen aussieht. Würde man den Link wie oben angegeben einbinden, hätte man ja immer die aktuellste Version und wäre damit “auf der sicheren Seite”. Sofern man nicht ständig manuell aktualisieren möchte, hat man vermutlich bald einmal eine veraltete Version. Wäre es dann nicht auch möglich, dass eine bestimmte Funktionalität plötzlich gar nicht mehr funktioniert (z.B. weil sich bei OSM was geändert hat, was in der alten OpenLayers-Version noch nicht berücksichtigt wird, etc.)? Wie löst ihr dieses Problem?
alles hat seinen preis: hier größe versus aktualität.
meine “lösung”: download von der quelle, kein eigenes file
grund: download-zeiten sind nicht mehr sooo kritisch
zum 2. punkt: osm und openlayers haben fast nichts miteinander zu tun - bis auf diese kleine osm-spezifische source. es bestehen da keinerlei probleme, da openlayers osm garnicht “kennt”.
wir können nix in osm einbauen sodaß ol nicht mehr läuft.
@Geschwindigkeit: Falls der ein Besucher schon vorher auf einer OSM-Seite war, ist die Wahrscheinlichkeit gross, dass er das Script bereits im Cache hat - insofern sollte die Geschwindigkeit nur beim ersten Besuch eine Rolle spielen. Allerdings ist OpenLayers.org immer mal wieder down - mir ist daher meine private Kopie auf meinem Server auch lieber.
@Aktualität: Hier ist es eher umgekehrt: bei neuen OL-Versionen werden teilweise alte Funktionen entfernt, d.h. Deine Karte könnte mit einer neuen Version plötzlich(*) nicht mehr funktionieren. Da OL einen ‘geringen’ Funktionsumfang hat (keine Veränderungen an Daten auf dem Server), sind mir keine kritischen Sicherheits-Probleme bekannt, die in der Vergangenheit geschlossen werden mussten.
Wie Walter bereits gesagt hat: eine heute funktionierende Lösung mit lokalem OL-Script wird wohl auch in Zukunft unverändert funktionieren.
[Das Einzige was mir hier einfallen würde, wäre der Speicherort der Tiles, aber dessen Änderung wäre wohl noch mehr Protesten aus der Community verbunden wie der Wechsel der Lizenz. :->]
(*) ‘plötzlich’ im Sinne von: Die Funktion wird als deprecated markiert und irgendwann beim überüberübernächsten Release nicht mehr integriert.
t-i hat die Vorteile einer lokalen Kopie von OL ja eigentlich schon sehr gut beschrieben. Da wollte ich nur kurz ergaenzen, das OSM deshalb im uebrigen auch eine lokale Kopie hat, und zwar eine die nur das noetigste enthaelt um die Geschwindigkeit zu optimieren.
Wenn ich mich richtig erinnere, ist es in der Vergangenheit auch schon vorgekommen das ein Update von OL existierenden Karten Probleme bereitet hat (oder war das ein update der openstreetmap.js?), also nicht nur erst beim ueberuebernaechsten release.
Ich glaube, es ist sehr wahrscheinlich, dass eigene Openstreetmap-Anwendungen durch einen Openlayers-Versionswechsel plötzlich nicht mehr gehen.
Z.B. werden alle Seiten mit MouseDefaults eines Tages Probleme machen. Das schon lange als “deprecated” gekennzeichnet, wird aber trotzdem fleissig verwendet. Teils weil man das wirklich braucht, häufiger weil man Beispielcode irgendwo kopiert.
Viele wird ein Wegfall nicht stören, das kann fast immer durch Control.Navigation ersetzt werden, aber die Fehlersuche ist halt lästig und kommt sicher dann gerade ungelegen.
aus dem gleichen grunde würde ich zumindest bei neueren anwendungen oder geplanten “renovierungsarbeiten” ab sofort auf MARKER verzichten. markers ist (fast) tot. der neue könig heisst VECTOR.
vectors kann als superset alles was markers auch kann.
gruss
walter
Danke für den Hinweis. Welches Beispiel auf OpenLayers eignet sich als Anschauungsunterricht? Die Informationen weches Beispiel für welches Feature geeignet ist fehlen auf OpenLayers komplett.
Eigentlich sollte die lokale Kopie Standard sein, eine im produktiven Einsatz, eine im Testverzeichnis. So kann man in Ruhe eine neue Version austesten.
Ich halte es für keine geschickte Idee, wenn jeder seine eigene optimierte Version erstellt. Bei einer 1MB grossen Datei wäre es angezeigt, sie in ein Basismodul und mehrere Erweiterungen aufzuteilen. Dann kann jeder das laden, was er für seine Seite benötigt.
die sind leider noch knapper als die marker-beispiele. wenn man vector aber erst gepackt hat, ist es relatiov einfach, die marker-beispiele abzuleiten.
ist etwas so, wie mit der ol-api. die “doku” versteht man erst, wenn man sich ganz genau mit ol auskennt ich lese mir die api-dok und viele demos einfach alle 3-4 wochen neu durch und plötzlich “funkt es”.
Ich bin im Moment auch gerade am kreuz und quer lesen, so suche ich momentan die Klassendefinition eines Click-Event resp. welche Parameter das Trigger-Element hat. Unmöglich da etwas zu finden, für heute gebe ich auf.
bei marker/vectors stand irgendwo (in einem beispiel?) drin, dass man besser vectors nehmen soll, weil nur vectors weiter verbessert wird. aber so ne “depreciated-liste” kenn ich auch nicht.
war also reiner zufall.
war echt blöd, dass ich am anfang code-snipsel aus markers- und vectors-beispielen gemixt hatte ohne das zu merken
gruss
walter
Danke euch allen für die vielen Antworten. Ich werde dann wohl doch eine lokale modifizierte Version des Skripts bereitstellen.
Jetzt nur noch eine Frage dazu: Wie weiß man denn, welche Einzeldateien genau included werden müssen? Natürlich, einmal alle welche in der eigenen Seite direkt referenziert werden (mittels new-Operator oder dergleichen), das ist klar. Aber darüber hinausgehend? Ich habe nämlich ein Projekt mit Vector-Markierungen und es funktioniert auch alles, bis auf die Tatsache, dass die Vector-Objekte immer exakt in der Kartenmitte platziert werden, obwohl eine andere Position angegeben wurde. Steht hingegen die vollständige Library zur Verfügung funktioniert das einwandfrei. Ich bekomme allerdings keinen JavaScript-Fehler in IE.
Kann man das nur durch Ausprobieren herausfinden oder gibt es auch einen anderen Weg?
Hast Du mal alternativ khtml.org versucht? Die lib ist viel kleiner und die Leistung beim Betrachten („performance") mit aktuellen (teils noch Beta) Browsern viel höher.
ich lese mir die api-dok und viele demos einfach alle 3-4 wochen neu durch und plötzlich “funkt es”.