Rainers Horen
Sonntag, den 24.04.2011 [16:10]

Der Zweifel aus der Bärenhöhle kann beseitigt werden: die Karte zeigt die Bevölkerungsdichte auf der Erde. Genauer gesagt, ist es nicht die Bevölkerungsdichte, sondern die Dichte der Orte. Deutlich ist die Einsamkeit der Wüsten sichtbar. Nun gibt es links oben dieses Eingangsfeld. Dort kann der geduldige Leser beispielsweise Markkleeberg eintragen und wird feststellen, dass es im Gegensatz zu Petersburg nur einen Ort mit diesem Namen gibt.

Solche kleinen GeoApps zu bauen ist wirklich keine Zaubererei. Zu den Strategien von Goggle (wie auch von Apple) gehört die perfekte Dokumentation. Es gibt natürlich die API-Beschreibung, aber auch Beispielsammlungen, ¬Artikel und Tutorials. So kann jeder seinen Weg zum Erkenntnisgewinn finden.
Beitrag kommentieren  |  Kommentar lesen

Donnerstag, den 21.04.2011 [09:08]
Glücklich ist derjenige, der auch einmal etwas ¬Nichtverlinktes im Netz findet. Gerade erwähnte und nun doch verlinkte Sammlung von modernen Google-Funktion sind eine Fundgrube für den begeisterten Solutionisten. Das erweitert Horizonte.

Bei der Arbeit mit den FusionTables fallen einige Sachen auf: die Begrenzung auf 100MB Upload stimmt nicht – das Quota wird schon bei weniger Megas erreicht. Für das Trainingsprojekt habe ich die ca. 8 Mio. Datensätze in Stücken zu Millionen portioniert. Der Upload klappt jetzt. Nach dem Upload kommt der Import. Leider bricht das ganze Procedere zuweilen ab. Und es gibt keine Fehlermeldung. Das macht es schon deswegen uncharmant, weil immer große Wartezeiten damit verbunden sind.
Beitrag kommentieren

Mittwoch, den 20.04.2011 [11:01]
Es ist schön, wenn Kunden Visionen haben. Nachfolgender CoverFlip ließe sich mit Standardwerkzeugen und damit ohne astronomische Kosten „erschlagen“, wenn nicht diese perspektivische Verzerrung und der leichte Schatten wäre. Dann sähe es so etwa wie bei der aus. Ein Gedankenblitz des Designers kann dann vielleicht ungewollt hohe Kosten verursachen.




Nett ist auch nebige Idee. Sieht pfiffig aus und hat was. Für den Designer war das einfach: im Photoshop gibte s sicher eine Funktion, die das Umfluten des Bildes macht. Im Web sind alle Elemente rechteckig. Das Bild von dem Herrn ist natürlich größer und der Browser kann nicht „wissen“, dass er auf die durchsichtige Fläche schreiben darf. Wohlgemerkt: wir reden hier von einem Redaktionssystem: Bild, Text und Textgröße sind veränderlich. Und sicherlich gibt es eine unehrenhafte Gummilösung. Sie könnte beispielsweise darin liegen, den Text nicht als solchen zu erfassen, sondern einfach als Bild von einem Text. Das wäre nicht nur für Sehbehinderte und fürs Googleranking fatal.

Bei genügend Einsatz von Suchenergie findet sich dann dennoch eine flashvermeidente Lösung von ¬Addy Osmani:

Wunderbar – was heute so geht. Auch schön: der Designer hat rechts oben ein Suchfeld hingemalt. Nur: die angepeilte Promotionseite ist recht grafiklastig und hat außer dem Impressum und kleinen Bildunterschriften keinerlei Text. Es werscheint sinnfrei und mutet einem Potemkinschen Dorfe an.
Beitrag kommentieren

Dienstag, den 19.04.2011 [10:26]
Gestern die Sache mit der Übersicht über die (west-)deutschen Vornamen war nur ein Vorgeplänkel – quasi ein Aufwärmtraining. Heute stand die Aufgabe, die Fusion Tables mal so richtig auszureizen. Google lässt eien maximale Größe der Datenbank von 100MB zu. Eigentlich kann sie auch größer sein, aber falls jemand auf die Idee kommt, die Daten ohne Massenhochlade über den Ozean zu schicken, dann sollte er sich nachschulen lassen. Zufällig fand sich auf der Festplatte noch eine Datensammlung mit allen Orten dieser Welt mit ihren Koordinaten und wie es der Zufall so will, liegt die Größe knapp unter 300MB und hat über 14 Millionen Datensätze. Das ist neuer Weltrekord: bis eben war die größte FusionTable die Liste der nigerianischen (straßengenauen) Postleitzahlen. Das sind ungefähr eine Million. Nigeria ist zwar größer als die meisten Europäer denken – aber dannn doch nicht so viel.

Eine besondere (selber gestellte) Herausforderung wird es sein, einen ¬Autocompleter zu bauen, der nicht wie gewöhnlich einen Ajax-Request baut, sondern die Google-API bzw. ¬JSONP zur Ansprache der FusionTable nutzt.
Beitrag kommentieren

Montag, den 18.04.2011 [17:15]
Nachfolgende Übersicht über die Vornamen in Deutschland zeigt auch, was in Folge des großen Übels römisch II auch noch hätte passieren können.

In Wahrheit ist obige Karte nur eine Studie, was alles so mit dieser FusionTable geht. Das schönste daran sind eigentlch die schnellen Suchfilter und ihre Darstellung. Das Allerbeste von diesen Fusions Tables ist die extrem kurze Entwicklungszeit. Obige Karte ist in weniger als zwanzig Minuten entstanden – etwas mehr brauchte der Import der Dummydaten. Diese Tatsache sollte ein Auftraggeber vielleicht nicht wissen …

Es gibt auch einige Einschränkungen: solche SQL-Filter wie die Suche nach Teiltexten (LIKE) gehen nicht. Die ganze Chause ist auch nicht wirklich definiert – das heißt, nach administrativen Datenänderungen ist das auch nach Minuten noch nicht sichtbar. Die Gewschwindigkeit wird mit Caching erkauft. Beispielsweise liefert google.maps.FusionTablesLayer() über 20000 Punkte. Der gleiche Zugriff mittels REST oder der ¬Visualization-Lib von Google liefert zur Zeit keine Resultate. Das klingt nach verschiedenen Isolation-Levels.

Wie das immer so bei Google ist, gibt es auch in dieser Welt zwei Heransgehensweisen. Im einfachen Fall wird einfach nur eine SQL-Abfrage mit einem Layer verbunden und alles geht ganz fix, allerdings nur in der vorgefertigten Form der roten Punkte usw.

Willst Du mehr, musst Du mehr tun. Es lässt sich auch ganz gezielt via Javascript eine Abfrage absetzen. In einer definierten Callbackfunktion muss sich der geneigte Programmierer dann selbst ums Rendern kümmern. Dann ist dann wieder alles möglich. In einem ¬Standardbeispiel sollte auch dem Dümmsten ein Licht aufgehen. Etwas Plietschere können sich in der ¬Doku vertiefen.
Beitrag kommentieren


<< vorhergehende Woche   nächste Woche >>