Google Maps über COM (Component Object Model)

[Thom]

Dauert wahrscheinlich noch einige Wochen. Das liegt daran, daß ich zwischendurch noch einige andere Dinge fertigstellen muß.

Die Geometrie-Bibliothek befindet sich in der Unit gmLibrariesGeometry.pas.

[alibaba]

Nur mal zum Nachdenken...

Bin gerade dabei ein Delphi Programm zu portieren,
Ziel ist möglichst Plattformunabhängig zu operieren,
was liegt also näher als das ganze von Delphi nach Javascript
zu portieren und im Browser auszuführen.

Zwei Tools hab ich gefunden mit denen das zu funktionieren scheint:

1: dhtmlxSuite http://dhtmlx.com/

Grid, Edit, Form, Windows usw. mit einem funktionierentem Connector für diverse Datenbanken.

2: Leaflet http://leafletjs.com/

Map Ersatz bzw. Zwischenschicht für Google Maps und allen möglichen anderen OSM, Nokia, Bing ...
Superschnell und mit allem was man sich wünscht...


Klar das das trotzdem ne Menge Arbeit mit sich bringt aber es lohnt sich, Anbindung an Websockets, WebRTC usw. sind dann ein Kinderspiel.

FROHE OSTERN
lg
Albert

[Thom]

OK. Ich habe nachgedacht...

Hallo Albert,

vielen Dank für Deine Vorschläge! Aber ich vermute, Du hast den Sinn dieses Frameworks (und damit aller anderen, im ersten Beitrag verlinkten Komponenten) mißverstanden:
Das Google Maps API ist von Haus aus eine reine JavaScript-Lösung. Da muß man nichts umstellen, portieren oder dergleichen. Will oder muß man plattformübergreifen für einen Browser entwickeln, nutzt man einfach JavaScript und fertig.

Hier geht es aber darum, Delphi-Entwicklern die Nutzung zu ermöglichen, ohne selbst eine einzige Zeile JavaScript schreiben zu müssen. Das API wird übrigens im Browser (TWebBrowser) mit JavaScript ausgeführt (das ist auch die einzige legale Möglichkeit des Zugriffs).

Das, was Du vorschlägst, wäre ein JavaScript-Wrapper für einen Delphi-Wrapper für JavaScript...

Und ganz nebenbei: Ich mag Delphi (Pascal) als Programmiersprache. Sie ist mir wesentlich lieber als JavaScript. Das ist natürlich Geschmackssache und jeder kann dazu eine andere Meinung haben. Es gibt viele Entwickler, die Sprachen ohne Typisierung vorziehen und die mit Delphi nicht zurechtkämen.
Dazu kommt, daß eine kompilierte Anwendung bei effektiver Programmierung wesentlich schneller ist. Das kann ich deshalb mit Bestimmtheit sagen, da ich auch an Lösungen arbeite, die von TWebBrowser und JavaScript unabhängig sind. Dort ist die Darstellung locker um den Faktor 10 schneller.

In Sachen Plattformunabhängigkeit tut sich ja bei Delphi auch einiges. FireMonkey ist trotz seines schlechten Rufs und der unbestreitbaren Bugs ein Framework, das enormes Potential aufweist. Dank seiner vektororientierten Darstellung eignet es sich logischerweise hervorragend, vektorielle Daten - wie zum Beispiel geografische Informationen - darzustellen. Bei den kachelbasierenden (JavaScript-) Playern ist man dagegen darauf angewiesen, vom Server die vorgerenderten Tiles zu erhalten.

Ich wünsche Dir natürlich viel Erfolg bei der Umstellung von Delphi nach JavaScript und ebenfalls ein frohes Osterfest!

Viele Grüße
Thomas Nitzschke

[alibaba]

UUPS, wollte Dir nicht zu nahe treten, ist halt meine Meinung,

denn Sinn Deines Frameworks und der Komponenten verstehe ich sehr wohl und habe die
grösste Hochachtung vor Deiner Arbeit, hab sehr viel davon gelernt.

Meine Anregung wäre gewesen statt der Google JS Api die JS Api von Leaflet zu nehmen
damit wäre man nicht von Google abhängig und kann dann mit dem gleichen Code in Delphi
auch andere Maps (Lizenzkosten) verwenden.

Delphi ist und bleibt auch für mich die beste IDE (zumindest bis Delphi 7)
Und zu Windows schweig ich.
lg
Albert

[Thom]

Ich muß mich entschuldigen - ich hatte Deine Vorschläge falsch verstanden.

Wegen der Nutzung anderer Player, die die Daten des OpenStreetMap Projektes nutzen, kamen schon mehrere Anfragen. Mit der im Framework verwendeten Delphi-to-JavaScript-Bridge ließe sich das auch ohne Probleme bewerkstelligen - es wäre nur eine Frage des zeitlichen Aufwandes.

Ein paar Überlegungen meinerseits dazu:

Player, die OpenStreetMap-Daten verwenden, gibt es etliche:
Auf der eines Seite gibt es die reinen JavaScript Lösungen, die einerseits weitestgehend plattformunabhängig nutzbar sind, andererseits aber immer eine JavaScript-Engine und damit in der Regel einen Browser benötigen. Genannt seien da als Beispiele CloudMade, OpenMapQuest, Leaflet und OpenCycleMap.

Darauf aufbauend gibt es die Gruppe von Komponenten, die diese JavaScript-Player in Browser-Komponenten für Delphi zur Verfügung stellen:
So hat zum Beispiel TMS seit einiger Zeit WebOSMaps im Angebot, mit dessen Hilfe OpenLayers in einer auf TWebBrowser basierenden Komponente in Delphi-Anwendungen genutzt werden kann. Zum Preis-Leistungs-Verhältnis:

ECMap bietet in der Delphi-Komponente neben Google Maps auch Google Earth, Bing Maps, CloudMade, OpenMapQuest und Leaflet an und setzt neben TWebBrowser auch Chromium Embedded an. Dieses Paket ist sehr umfangreich und hat dadurch auch einen entsprechenden Preis.

Auf der anderen Seite gibt es dann die Komponenten, die ohne JavaScript auskommen:
Die Firma THB Componentware aus Österreich bietet einen Komponente namens THBImage an, die Vektor- und Rasterdaten aus dem OpenStreetMap Projekt darstellen kann. Dazu gibt es eine Online-Demo, für die man ein ActiveX installieren muß. Beim Download des ActiveX-Controls schlägt aber sofort mein Virenscanner Alarm und entfernt den Download wieder von der Platte. Der Hersteller bekommt es offenbar noch nicht einmal hin, sein Plugin zu signieren. Wirklich sehr vertrauenserregend...

StelifeMap ist eine Komponente, die Rasterdaten (also auch wieder Kartenkacheln) ohne Browser-Komponente in Delphi darstellen kann. Der Preis von momentan 20,48€ + MwSt. für die Komponente ohne Quelltext liest sich ganz fair. Wie gut die Komponente selbst ist, kann ich nicht sagen, da ich noch nicht zum Testen gekommen bin. (*)

Trotz aller Freiheit der OpenStreetMap Daten sollte man einige Dinge nicht vergessen:
In dichtbesiedelten Gebieten - vor allen Dingen in Mitteleuropa - ist der Qualität der Karten teilweise erheblich besser, als bei Google Maps. Das ändert sich schlagartig, wenn man "den Rest der Welt" betrachtet. Das ist auch logisch und verständlich: Schließlich haben viele Menschen zum Beispiel in Südamerika oder Afrika andere Sorgen, als mit einem GPS-Gerät durch die Gegend zu laufen. Trotzdem wächst natürlich jeden Tag die Datenmenge enorm. Dadurch ist es schon eine sehr anspruchsvolle Aufgabe, selbst eine Datenbank mit den OpenStreetMap-Daten aufzusetzen. Ich habe von vielen Projekten gelesen, die schon daran gescheitert sind.

Die Dienste, die Google Maps bietet, sind (momentan) unerreichbar. So werden zum Beispiel Routenanfragen innerhalb von einigen zehntel Sekunden beantwortet. Über OpenStreetMap dauert das bei längeren Strecken (ca. 500 km) auch mal 10 Sekunden und länger und die Länge der Route weicht dann unter Umständen um 1/5 von der Google Maps Route ab. Nicht umsonst ist gute Wegfindungssoftware (damit meine ich nicht nur für Straßen und Wege, sondern zum Beispiel auch für Spiele) extrem teuer.

Höhendaten sind in OpenStreetMap nicht flächendeckend verfügbar. Luftbilder - nun ja...

Der Download von OpenStreetMap Kacheln zwecks Offline-Nutzung ist zwar meistens erlaubt, wird aber nur in einem angemessenen Umfang geduldet, da hier Bandbreite und Serverkapazitäten arg strapaziert werden. Das kostet viel Geld, was wiederum irgendwo herkommen muß - und das ist bei OpenSource-Projekten nicht ganz so einfach. Und die Bereitschaft zu spenden ist leider eine recht unterentwickelte Eigenschaft. Geiz ist eben geil, auch wenn dadurch so manches tolle Projekt den Bach heruntergeht. Aber das ist schon wieder ein anderes Thema.

Das sind nur einige Beispiele. Damit will ich auf keinen Fall OpenStreetMap schlecht machen. Ein kommerzieller Anwender muß sich aber natürlich sehr genau überlegen, auf welche Daten er Wert legt und wie genau diese sein müssen. Und da werden schnell 10000 $ für eine Google Maps Lizenz zum Schnäppchen.

Damit stellt sich unterm Strich bezüglich OpenStreetMap immer die Frage: Verwende ich eine fertige Lösung (mit/ohne JavaScript mit allen ihren tollen Features und Bugs) oder baue ich selbst eine Infrastruktur, die als Ausgangsbasis die OpenStreetMap-Vektordaten verwendet.
Der erste Weg ist bequem und relativ schnell umsetzbar - der zweite ist wesentlich flexibler, aber auch unvergleichlich aufwendiger.

Ich hoffe, ich habe Dich nicht zu sehr gelangweilt - frei nach dem Motto des Forums: Hier erhalten Sie Antworten auf Fragen, die Sie nie gestellt haben...

Bezüglich Delphi stimme ich Dir zu.
Und obwohl die neueren IDE's den einen oder anderen Bug haben - ich kann damit wirklich schön und komfortabel programmieren. So kann ich zum Beispiel wunderbar 64-Bit-ISAPI-DLL's erstellen und den Hauptspeicher des Servers mit 10 GB vollschreiben...
Hast Du schon mal XE3 getestet?

Betreffs Windows: Jaaa...

P.S.: Die Verarbeitung und Nutzung der OpenStreetMap-Vektordaten ist unabhängig vom Framework in Arbeit. Insofern mache ich eigentlich genau das, was Du vorgeschlagen hast - nur eben nicht mit einem vorhandenen JavaScript-Player.

(*) P.P.S.:
Ich hatte gerade die Komponente getestet.
Völlig unbrauchbarer Zoom: Man landet an der verkehrten Stelle. Ein gezielter Zoom auf eine bestimmte Stelle ist unmöglich. Der Schieberregler im Zoom-Steuerelement ist ohne Funktion (man verschiebt einfach die darunterliegende Karte).
Die sichtbaren Kartenkacheln werden immer komplett geladen, bevor die Karte verschoben werden kann. Das führt zu erheblichen Rucklern.
Wird die Karte nach Norden oder Süden verschoben, taucht sie oben bzw. unten wieder auf. Bewegt man sich dagegen nach Westen oder Osten, verschwindet die Karte aus dem Sichtbereich. Der Entwickler hat da wohl irgend etwas mißverstanden.
Von den Bugs und der mangelnden Qualität mal abgesehen, begeht der Anbieter auch einen klaren Lizenzverstoß: In der Demo erfolgt keinerlei Hinweis auf OpenStreetMap - dagegen steht an allen möglichen Stellen auf der Karte ein Copyrighthinweis auf Stelife.
Fazit: Auch hier Finger weg davon!