OpenLayers-Alternativen, die mehr clientseitige Funktionen unterstützen [geschlossen]


14

Ich erwäge verschiedene Architekturen für ein System, das idealerweise clientseitiges Rendering für Punktmerkmale verwendet und Plug-in-frei sein muss. Ich habe diese Anwendung verwendet, die als Antwort auf diese Frage entwickelt wurde , um meinen Laptop (der durchaus fähig ist - Quad-Core 2,6-GHz-CPU, 4-Gbit-Speicher, keine andere Last, Firefox 8) mit einer anderen Punktanzahl in OpenLayers und zu testen es liegt merklich hinter 500 zurück und fängt an, über 1.000 zu kämpfen. Die zufällig generierten Features scheinen keine Event-Handler zu haben und verwenden alle dieselbe Symbologie.

Ich erwarte, dass bis zu 1.000 Features mit bis zu 10 verschiedenen Symbolen auf weniger leistungsfähigen Plattformen angezeigt werden.

Ich hatte auf eine bessere Leistung auf der Clientseite gehofft, insbesondere nachdem ich dieses Beispiel für die GIS-Cloud gesehen hatte. Ich weiß, dass es anders funktioniert (HTML5-Canvas vs. SVG), aber der Unterschied in der Leistung ist wirklich bemerkenswert.

Meine wichtigsten Fragen (wenn Sie so nett wären) sind:

  1. Ist die zufällige Punkterzeugungsanwendung repräsentativ für die Leistung in anderen OpenLayers-Anwendungen, die Sie geschrieben / verwendet haben?
  2. Gibt es eine bewährte und kostenlose alternative Web-Mapping-API, die WMS-Dienste unterstützt (die ich verwenden muss) und die mit clientseitigen Funktionen schneller ist, ohne Flash / Silverlight / andere Plugins zu verwenden?
  3. Irgendwelche anderen Vorschläge, was ich untersuchen soll?

Es ist eine Option, sich in erster Linie auf das serverseitige Rendern zu verlassen, aber sowohl ich als auch der Client möchten dies vermeiden, da Bedenken hinsichtlich der Vergrößerung der Benutzeranzahl und der Reaktionsfähigkeit der Benutzeroberfläche bestehen.


Auf meinem 5 Jahre alten Dual-Core-Desktop mit 3 GB RAM, der diese App unter Firefox 8 verwendet (während ich eine 1 GB Linux-Distribution-ISO herunterlade), ziehen 1.000 Punkte fast augenblicklich, ohne Probleme ... 10.000 dauern ungefähr 1,5 Sekunden.
user2856

@LukePinner ist das nur schnelles Zeichnen * und ruckelfreies Schwenken / Zoomen? Das Abrufen von Daten und Zeichnen der Features ist auch für mich in Ordnung, aber das Problem ist die Karteninteraktion.
Tomfumb

Ich habe gerade deine App auf meinem ipad2 ausprobiert und sie hat 1000 Punkte sehr gut verarbeitet. Mit 10.000 Punkten dauert das Rendern zunächst ein paar Sekunden, ist dann aber recht gut bewältigt. Wenn Sie möchten, können Sie die OL Vector-Layerklasse immer in Unterklassen unterteilen und eine benutzerdefinierte implementieren. Ich kann Sie auf ein Beispiel hinweisen.
unicoletti

Ja, keine Probleme beim Schwenken / Zoomen. 1K-Punkte verlangsamen sich auf meinem 1,6-GHz-Atom-Netbook allerdings ziemlich :)
user2856

Antworten:


23

Die Antwort auf die erste Frage lautet Ja . Sie verwenden OL mit einer weit verbreiteten Konfiguration. Es gibt Tricks, mit denen Sie die Leistung verbessern können. Darauf komme ich später zurück.

Antwort auf Frage 2 ist vielleicht (vor allem in Bezug auf die Echtheit). Sie können auf dieser Website nach einer Liste von Alternativen suchen (eine, die Ihnen gerade einfällt, ist die Broschüre ).

Antwort auf Frage 3: Beginnen Sie mit dem Messen:

Ich habe eine lokale Kopie der App bearbeitet, sodass der Renderer in der Optionsliste für die Vektorebene explizit angegeben wird. Während der Tests würde ich den Canvas-Renderer weglassen und dann die Seite des Experiments mit einem anderen neu laden:

var pts = new OpenLayers.Layer.Vector("Points", {renderers: ["Canvas", "SVG", "VML"]});

Ich habe der Redraw-Funktion einen Timer hinzugefügt, der ausgibt, wie viel Zeit für das Zeichnen aufgewendet wurde :

function redraw() {
var start = (new Date).getTime();
[...]
var diff = (new Date).getTime() - start;
console.log("redraw completed in "+diff+"ms");

Danach habe ich mehrere Läufe auf Chrome 17 und Firefox 8.0.1 unter OSX SL versucht, wobei ich 1000 und 5000 Funktionen gezeichnet habe. Zu meiner Überraschung ist der SVG-Renderer im Durchschnitt 20% schneller als der Canvas-Renderer! (Hinweis: Unter Windows ist die Zeit nicht so genau wie unter OSX, sodass die Ergebnisse möglicherweise weniger konsistent sind.)

Dies und dein Erzählen

Das Problem ist die Karteninteraktion

Laut IMHO befindet sich der Hotspot im Vector-Handling von Features. Während ich an einer App von mir arbeitete, habe ich sie mir kürzlich angesehen und beschlossen, sie in Unterklassen einzuteilen und sie dann von all dem komplizierten Code zu befreien, der für einfache Punkte nicht von Nutzen ist. Zugegeben, ich bin ziemlich wild geworden und habe sogar die Abhängigkeit von OpenLayers.Geometry.Point entfernt, und meine Version funktioniert jetzt auf einfachen js-Objekten mit x, y-Attributen.

Ihre Optionen sind in absteigender Reihenfolge von Nutzen / Kosten:

Die erste Option besteht darin , die sichtbaren Punkte serverseitig zu filtern, indem Sie eine Strategieoption für die Vektorebene konfigurieren, wie die folgende:

 strategies: [new OpenLayers.Strategy.Refresh({force:true}), new OpenLayers.Strategy.BBOX({ratio:2, resFactor: 3})],

Auf diese Weise wird die Anzahl der auf der Client-Seite gezeichneten Features auf die in diesem Umfang sichtbaren beschränkt, anstatt auf alle.

Als zweite Option können Sie einen benutzerdefinierten Vektor / Renderer erstellen . Ein Beispiel für einen individuellen, abgespeckte, schnellere Implementierung ist auf meiner Seite Github verfügbar hier . Obwohl nicht für alle Verwendungszwecke geeignet, sollte es ausreichen, eine ungefähre Vorstellung davon zu geben, was ich vorschlage.

Die dritte Option für den Fall, dass der Benutzer vollständig verkleinert ist, besteht darin, eine Art serverseitiges Clustering von Features zu implementieren, sodass enge Punkte zu einem einzigen zusammengefasst werden, wodurch wiederum die Anzahl der gezogenen Features verringert wird.


Vielen Dank für die ausführliche und gründliche Antwort. Ich werde mich sehr wahrscheinlich mit serverseitigem Clustering befassen, hoffentlich in Kombination mit einer Caching-Strategie, damit der Vorgang nur bei Bedarf ausgeführt wird. Eine der Optionen für die Serverseite ist MapGuide, sodass der Ansatz zum Abrufen und Gruppieren von Punkten völlig benutzerdefiniert sein kann. Ich werde auch ein wenig mit den Renderer-Optionen herumspielen, um zu sehen, welchen Unterschied es macht.
Tomfumb

1
Ich habe einen Link zu einem Beispielvektor / Canvas-Renderee hinzugefügt, den ich in einem meiner Projekte verwende.
unicoletti

Wow, das abgespeckte Beispiel macht einen gewaltigen Unterschied, das ist wirklich beeindruckend. Ich bin vom Kampf mit 1.000 Features zum Fliegen mit 10.000
übergegangen

Ich habe das erste Beispiel (swingley.appspot.com) geändert, um den OL-Canvas-Renderer und eine feste Füllung für Punkte zu verwenden, und die Leistung beim Zoomen und Schwenken ähnelt der von TagCanvas und TagVector. Ich habe auch die von Ihnen in Ihren Modifikationen entfernte Treffer-Test-Funktion erneut implementiert, um die Vergleichsleistung zu testen. Der Tag * -Ansatz war bei der Identifizierung der getroffenen Funktion (von 5.000) etwa 20% schneller. Angesichts des erheblichen Aufwands beim Schreiben / Aktualisieren der benutzerdefinierten Klassen und der ähnlichen Leistung (in meinen Tests) denke ich, dass ich sehen werde, was Vanilla OL tun kann
am

Der Grund dafür ist, dass hit-test alle Features in eine andere Zeichenfläche neu zeichnet, sodass sie bei jeder Aktualisierung zweimal gezeichnet werden .
unicoletti

0

Mit UTFGrid und TileMill können Sie unbegrenzt viele Punkte mit ziemlich guter Leistung anzeigen. Die Anzeige von n zufälligen Punkten ist ein ausgefallenes Beispiel, das in dieser Situation oder mit GISCloud oder einer ähnlichen Magie nicht funktioniert - da Vektor-Performance-Hacks normalerweise Kenntnisse über den gesamten Datensatz und eine gewisse Vorverarbeitung erfordern: TileMill und GISCloud tun dies viel fliesen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.