qrios

Hier und da poppt seit Jahren eine mehr oder minder starke Furcht vor Algorithmen auf. Egal ob von Meckel, Schirrmacher oder anderen Fuilleton-Natives ist der Tenor immer ähnlich: wir werden alle störben Algorithmen sind dabei den Menschen einzuschränken. Da freut es denjenigen, der sich im Studium mal intensiv mit Technikkritik beschäftigt hat dann doch, dass auch mal eine etwas kenntnisreichere Stimme zu Wort kommt. In der SZ erschien ein Artikel von Kathrin Passig mit dem Titel “Warum wurde mir ausgerechnet das empfohlen?“.

Nun ist Kathrin Passig nicht unbedingt ausgewiesene Algorithmus-Expertin hebt sich aber durch digitale Erfahrung erfrischend von den Mahnern ab. Nur leider hat sie das Thema auch nicht verstanden. Was schade ist, da mspr0 ihr gleich zur Seite springt und ihre (Falsch-)Aussagen kunstvoll in seine These vom Kontrollverlust und der darauf zwangsläufig folgenden Postprivacy einflechtet. Warum Falschaussagen? Weil sie zum Beispiel eine Bestsellerliste einem Algorithmus gegenüberstellt. Dabei ist eine Bestsellerliste genau das: das Ergebnis eines Algorithmus. Den können zwar alle verstehen aber dadurch wird er nicht zum Nicht-Algorithmus.

Für sie ist – wie für die Mahner – ein Algorithmus etwas, das (bei genügend großer Komplexität) ein Mensch nicht mehr verstehen kann. Dazu wird ein (unverlinktes) Zitat bemüht:

Die am Wettbewerb beteiligten Teams [die Programmierer der Algorithmen] gaben in Interviews an, nicht mehr nachvollziehen zu können, wie ihre eigenen Algorithmen zu manchen Ergebnissen gelangen.

Diese Aussage kann man jetzt in mindestens drei Richtungen deuten. Die Programmierer verwenden Code, den sie nicht selbst geschrieben haben (Framework, Compiler) und dies führt zu einem Black-Box-Verhalten, die Programmierer haben Code geschrieben, der sich selbst verändert oder die Programmierer kennen nicht mehr alle Werte, der zu diesem Ergebnis geführt hat.

Der erste Fall kommt recht häufig vor ist aber sicher nicht gemeint, da die konkrete Implementierung egal ist, solange das gewünschte Ergebnis produziert wird. Sollte mein Code trotz eingehender Prüfung nicht mehr das tun, was ich gerne hätte, würde ich überprüfen, ob die beteiligten Frameworks nicht das tun, was ich erwarte und im letzten Schritt, ob der Compiler merkwürdige Seiteneffekte produziert. (Aber normalerweise würde ich erst mal schlafen gehen, weil sich das Problem am nächsten Tag meistens in Luft aufgelöst hat.)

Der zweite Fall ist schon etwas komplizierter. Selbstveränderlichen Code gibt es bereits und wird insbesondere von Virenprogrammierern eingesetzt. Dabei geht es aber nicht um eine Veränderung der prinzipiellen Funktionsweise im Sinne von Evolution sondern lediglich um Mimikri. Ein solcher Code würde im Idealfall tatsächlich dazu führen, dass selbst die Entwickler ihn nicht mehr ohne eingehendes Studium von jedem anderen Code unterscheiden könnten und nicht sagen könnten, was der Code tut. Und dies obwohl sie ihn selbst geschrieben haben.

Es ist mit hoher Wahrscheinlichkeit in dem Zitat der dritte Fall gemeint. Eine Liste von Eingabewerten wird immer wieder durch die Maschine geschickt und kalibriert die vorgegebenen Schwellwerte an Hand von Erfolg und Misserfolg. Dabei kommt in den einzelnen Zwischenschritten viel Stochastik zum Einsatz und ab und zu wird mal der Zufallsgenerator angeworfen, um das ganze System vor der zwangsläufigen Stasis zu beschützen. Die eingesetzen Algorithmen sind in den meisten Fällen mit den mathematischen Fähigkeiten eines Realschülers zu verstehen. Die anscheinende Komplexität entsteht nur aus der Anzahl der Eingabedimensionen und der Anzahl der Iterationen.

Wichtig an diesem Punkt ist besonders der Begriff des Schwellwertes. Denn hierbei handelt es sich nicht um ein einzelnes Bit, dass gesetzt ist oder nicht. (Aber selbst bei solchen Systemen kommen schon komplexe Verhalten zu Stande. Dazu möge man sich die dreißig Jahre alten Arbeiten über zelluläre Automaten von Stephen Wolfram ansehen.)

Schwellwerte werden normalerweise als Fließkomma implementiert. Computer und damit auch Algorithmen sind allerdings recht ungenau im Umgang mit Zahlen wie 1/3 oder Wurzel aus 2. Da es sich um endlose Zahlen handelt muss eine CPU diese Werte runden. Und je nach dem, in welchen Zustand (z.B. in welchem Speicher sich die Werte befinden) kommt eine etwas andere Zahl bei der Operation raus. Genau genommen haben wir es hier mit einer Heisenbergschen Unschärfe zu tun.

Da ein Algorithmus jedoch nichts anderes ist als eine Aneinanderreihung von Operationen ist, werden selbst bei exakt bekannten Eingangswerten die Ergebnisse um so unverhersagbarer je öfter eine solche Rundung stattfindet.

Einer der wichtigsten aktuell im Einsatz befindlichen Algorithmen ist die Page-Rank-Berechnung von Google. Obwohl bisher nicht nach aussen gedrungen ist, wie er exakt aufgebaut ist, basiert darauf die ganze SEO-Branche. Für viele handelt es sich um reines Google-Voodoo. Dabei kann man an Hand unterschiedlicher Ergebnisse eine Art Verhaltensforschung betreiben. Und obwohl ich noch niemanden gehört habe, der meint, es würde sich um ein Lebewesen handeln verhält er sich dennoch anscheinend so. Ich kann ihn untersuchen an Hand möglichst vieler Parameter, die er auch (vielleicht) sieht. Seine vollständige Funktionsweise könnte ich jedoch nur ermitteln, wenn ich ihn immer wieder in den gleichen Zustand versetzen könnte, was ginge. Ich müsste allerdings auch seine Umwelt wieder in den gleichen Zustand versetzen, was nicht ginge.

Nichts desto trotz ist der Page-Algorithmus einfach und Lerry Page versteht ihn sicher nach wie vor und etliche seiner Mitarbeiter auch.

(Quelle animiertes Gif: http://de.academic.ru/dic.nsf/dewiki/279011)

CouchDB in der Version 1.2.0 respektive die Adminoberfläche Futon hat einen Bug, um den sich offensichtlich keiner kümmert, weil die ganzen Leute ja sowieso das Interface insbesondere für die Views nicht benutzen. Für mich war das allerdings nervig, weil ich die Views tatsächlich unter Futon teste. Wollte man einen View speichern kommt die Meldung:

Cannot save view because the design document language is “undefined” not “javascript”.

Nun ist Undefined tatsächlich nicht JavaScript aber daran sollte sich doch keiner stören. Egal. Hier ist der Workaround (nicht schön aber …):

Man gehe zu der Datei futon.browse.js im CouchDB-Paket. Dort findet sich in der Zeile 558 “success: function(doc) {“, man füge danach

doc.language = ‘javascript’;

ein und gleiches tue man nach der Zeile 506. Danach hat man keine Probleme mehr mit dem Sichern von Views. Ist natürlich dann auf JavaScript für die Map- und Reduce-Funktionen angewiesen.

Mit dem vorhergesagten Ende von Flash auf mobilen Geräten und dem damit ebenso vorhergesagten Ende von Flash auf den meisten anderen Geräten hat die Content-Industrie plötzlich ein Problem, das sie eigentlich als schon gelöst angesehen hatte:

Wie vertreiben wir unseren Content im Netz ohne jegliche Kopiermöglichkeit?

Die drei wichtigsten Distributionskanäle (Kino, Silberscheibe, TV) sind alle – trotz hartnäckiger Bemühungen – geknackt. Daher finden sich alle dort veröffentlichten Filme innerhalb kürzester Zeit auf allen Verbreitungsplattformen im Netz.

Ein sicherer Channel im Netz hätte die Chance geboten, wenigstens die Filme die es nicht ins Kino schaffen, weil sie dort keinen großen Erfolg versprechen, längere Zeit im Netz laufen zu lassen, ohne dass die Kunden andere als die kostenpflichtigen Quellen nutzen könnten. Das hätte eine schier unerschöpfliche Quelle ewigen Reichtums sein können.

Nun ist Flash tot und ausser Apple hat nur Microsoft ein qualitativ hochwertiges Video-Format wie H.264 im Bundle mit einem halbwegs sicheren DRM. Daher verwundert es nicht, wenn die Content-Leute auf die abstruse Idee kommen, von den Distributions-Plattformen zu verlangen, dass nun Silverlight verwendet wird. Nach Netflix wird auch Lovefilm Silverlight verwenden. Ob diese Entscheidung Microsoft wirklich freuen kann, darf ernsthaft bezweifelt werden. Denn eigentlich steht Silverlight bei MS schon länger auf der Abschussliste.

Die User von Lovefilm sind offensichtlich verärgert über diese Entscheidung und so hat es diese Dinosaurierindustrie mal wieder geschafft, an den Bedürfnissen der User vorbei Entscheidungen durchzusetzen und sich ins Abseits zu manövrieren.

Der Google-Motorola-Deal zeigt offensichtlich Wirkung. HP stellt die komplette webOS-Linie ein.

Im letzten Jahr kaufte HP Palm. Palm hatte es vorher nicht geschafft, den Wechsel auf die neue Plattform signifikant in den Markt zu bringen. Aber offensichtlich hat HP aber offensichtlich ebenfalls nicht den Atem, eine neue Plattform langfristig aufzubauen.

Schade.

Denn webOS ist nach meiner Meinung die Plattform mit dem größten Potential. Denn früher oder später werden VM-basierte Script-Sprachen die wichtigste Basis für Programmentwicklung sein. Und offensichtlich gibt es keine andere Sprache, die in absehbarer Zeit JavaScript den Rang ablaufen könnte.

Der Tod von webOS macht nun aber plötzlich an der anderen Seite den Weg für Google frei. Denn mit ChromeOS betreibt Google ein vergleichbares Konzept. Aber derzeit scheint JS weder auf der Hardware-Seite noch auf der VM-Seite wirklich in der Lage zu sein, die Erwartungen der User zu erfüllen. Google hat mit Android allerdings die Basis, in absehbarer Zeit einen weiteren Layer einzuziehen und sich damit aus dem Stand die JS-Entwickergemeinde zu erschliessen.

Es gab ja schon einige Versuche, Betriebssystemoberflächen in JavaScript nachzubilden, aber eine komplett virtuelle Maschine gab es meines Wissens bisher noch nicht. Fabrice Bellard hat inzwischen eine Implementierung online gestellt. Ruft man die Beispielseite auf startet direkt ein Linux mit dem Kernel 2.6.20 mit einer Command Line. Neben einer Shell und etlichen Unix-Tools ist selbst emacs vorhanden.

Allerdings hat das Gastsystem keinen Zugriff auf das Netzwerk. Was aber laut Forumsdiskussion kein weiteres Problem sein dürfte, da aktuelle Browser über Sockets alle notwendigen Resourcen bieten. Selbst ein einfacher XServer dürfte sich mit Hilfe von Canvas umsetzen lassen.

In der öffentlichen Wahrnehmung hat Apple Google mal eben rechts überholt und das ohne zu blinken. Streetview war gestern, heute ist “consolidated.db”. Diese Datenbank der Positionen des iPhone/iPad existiert offensichtlich schon länger und wurde laut verschiedenen Quellen bereits von Forensikern genutzt. Die breite Öffentlichkeit und damit auch die tagesschau, heise, golem und ich erlangte erst Kenntnis davon als letzte Woche das Programm iPhoneTracker veröffentlicht wurde. (Sonst hätte ich mir damals nicht die Mühe mit dem iPhone moblog gemacht …). Wiedermal ein sehr schönes Beispiel dafür, dass das Verständnis von IT mit dem Userinterface steht und fällt (Hallo SAP?).

Meine Fahrradrouten durch Berlin in optimierter Auflösung von iPhoneTracker.

Ursprünglich klang für mich das ganze sehr stark nach einem typischen “Programmierer braucht für die Entwicklung ein Log und keiner denkt beim Release daran”. Immerhin basierte lange Zeit die ganze Webtracking-Branche auf den Serverlogs, die eigentlich nur zum debuggen gedacht waren.

Inzwischen kristallisiert sich aber raus, dass es sich keineswegs um ein Versehen handelt und die daraus zu ziehenden Schlussfolgerungen sind nicht schön, at least für Apple. Hervorragend zusammengefasst von Frank Rieger. Aber ich hätte mich nicht erst seit den aktuellen Erkenntnissen geweigert, mein Telefon am Empfang der US-Botschaft abzugeben, wie es – laut Max Winde im letzten mobilemacs-Podcast – mspro vor einiger Zeit machen musste.

Unabhängig von der Bewertung und dem extrem negativen Impact für Apple (den die echten Fanboys schäumen lassen) freue ich mich natürlich, dass ich ohne Jailbreak und entsprechende Tools jetzt eine Datenbank meiner Positionen habe.

Aber warum sind die Daten so ungenau und warum werden mir nur ganze Wochen angezeigt? Geht’s auch etwas genauer?

Read the rest of this entry »

Googles Chrome-Browser springt von einer Version zur nächsten und ist inzwischen bei Nummer 9 angelangt. Die Neuerungen halten sich meistens in Grenzen und es ist unklar ob in Googles Entwicklungsabteilung nur einige emacs-Gegner arbeiten, die möglichst schnell an dem Editor vorbeiziehen wollen.

Per Default ausgeschaltet: Google Instant

Mit Google Chrome 9 wurde jetzt eine Funktion eingeführt, die erheblichen Einfluss auf das Verhalten der Nutzer haben könnte. Schaltet man in den Einstellungen “Google Instant” ein wird bereits während der URL-Eingabe die jeweils wahrscheinlichste Seite geladen. Je nach Historie des Surfens wird also bei ‘sp’ entweder spiegel.de oder spreeblick.com geladen.

Mir ist momentan nicht klar, ob eine solche Funktion aus User-Sicht wirklich sinnvoll ist, da ich insgesamt den Eindruck habe, dass viele neue Funktionen zu einer immer kürzer werdenden Aufmerksamkeitsspanne führen.

Auswirkungen hat diese Funktion jedoch auf die Webanalyse und damit auch auf den Betrieb einer Site. Denn in Zukunft werden mehr Seiten aufgerufen und direkt danach wieder verlassen. Die bisher schon sehr schwierig zu beurteilende Bounce Rate wird also steigen. Solange diese Funktion nicht von den anderen Browsern übernommen wird, kann man deren Bounce Rate benutzen, um den Chrome-Faktor zu berechnen. Leichter wird Webanalyse dadurch sicher nicht. Aber es fließen bestimmt noch mehr interessante Daten zu Google.

In Deutschland ist es per Gesetz untersagt, IP-Nummern zu speichern. Daran hält sich jedoch kaum jemand. In meiner Praxis habe ich bisher kaum eine Apache-Konfiguration gesehen, die als Log-File-Format nicht ‘combined‘ oder ‘common‘ verwendet hat. Beide Einstellungen speichern die IP-Adressen der User dauerhaft. Es hat mich jedesmal Überzeugungsarbeit (mit Hinweis auf die Probleme, die mal eine Justizministerin hatte) gekostet, dies zu ändern.

Wenn ein Gesetz und Strafandrohung bei Anbietern nicht dazu führen, dass IP-Nummern nicht gespeichert werden, wie bitte sollte ein http-Header mit der Aussage ‘do not track me’ dazu führen, dass Werbetreibende kein Targeting durchführen.

“Do not Track” soll in Zukunft im http-Header übermitteln, dass der User vor diesem Browser nicht wünscht, analysiert zu werden. Sozusagen eine Tarnkappe mit dem Hinweis “Falls Sie mich doch sehen, ignorieren Sie mich doch bitte!“.

Nun könnte man natürlich vermuten, dass Firmen wie Doubleclick sich in Zukunft hüten werden, Cookies an den Browser zu schicken. Natürlich werden sie das tun. Aber das hindert sie nicht daran, trotzdem profilierte Werbung auszuliefern. In Zukunft wird ein Retailer von seinen Werbenetzwerken einfach verpflichtet (respektive Preisnachlässe erhalten), Cookies verschiedener Partner durchzureichen. Dieses Durchreichen geschieht schon heute. Denn die Anbieter sind schon heute nicht unabhängig. Netzwerk X arbeitet bezüglich Branche Y mit Netzwerk Z zusammen.

Wenn ein User dann bei Shop A (wg. der Funktionen des Shops, zwinker, zwinker …) gezwungen wird, Cookies zu akzeptieren, werden diese an das Netzwerk durchgereicht. Wenn es nicht anders geht mit Hilfe von Mengenabfragen à la History-Hijacking.

Aber selbst dieses recht komplizierte Szenario muss eigentlich nicht bemüht werden. Denn mit dem Browser-Fingerprint gibt es eine funktionierende Methode der Wiedererkennung eines Systems an Hand von Browser- und Systemumgebung, ohne eine ID auf dem/vom Rechner des Users zu speichern/abzufragen.

Schlussendlich gibt es aber niemanden (am wenigsten einen Richter), der in der Lage wäre, zu unterscheiden, ob die technischen Umgebungsvariablen so sind wie sie sind, weil jemand wollte, dass sie so sind wie sie sind oder weil eine Standardkonfiguration meinte, dass es eine gute Idee wäre, dass sie so seien, wie sie sind.

Und – ganz ehrlich – glaubt irgendwer im Raum, dass facebook seine Like-It-Funktion disabled, wenn ein User die DNT-Funktion eingeschaltet hat? Mit jedem Recht kann facebook behaupten, dass diese Funktion nicht dem Tracking dient sondern der Kommunikation. Wenn diese Argumentation funktioniert, werden in Zukunft auch lauter Googles, Zanoxes und andere eine Community aufbauen. Haben sie schon versucht? In Zukunft werden sie wissen, warum es sich lohnt, selbst wenn sie NULL User haben …

Nachdem Apple recht offensichtlich (und dumm) Google angreift (siehe Voice-App und weiteres) nimmt Google jetzt den Fehdehandschuh auf. Mit der Ankündigung in naher Zeit den H.264-Support aus Chrome zu entfernen stellt sich Google erstmals offen gegen Apple.

Mit einem Browser-Marktanteil von rund 10% (12+% in den Staaten) hat Chrome eine Verbreitung erreicht, die für Site-Betreiber relevant ist. Wenn dieser Browser in Zukunft die derzeit einzige Alternative zu Flash-Videos nicht mehr unterstützt müssen sich Sitebetreiber eine Alternative überlegen. Die Lösung wird für die meisten sicher nicht darin bestehen, alle Videos zusätzlich als WebM-Video anzubieten. Wer diesen Aufwand scheut wird wieder bei Flash landen. Die Massage von Google richtet sich also an die ZDFs und BBCs der Welt und lautet: “Hört auf, eure Flash-Player durch HTML5-Player zu ersetzen.”

Es gibt inzwischen vernünftige Browserweichen, die den iOS-Usern den Video-Tag mit H.264 geben und anderen den Flash-Player einspielen. In Zukunft werden diese Weichen eine weitere Regel abfragen: if(USERAGENT.indexOf(‘Chrome’) != -1) ladeFlashPlayer();

Eine schlechte Nachricht für das Netz, für Chrome-User und für Android-User. Und ein neues Zeichen (nach der Ankündigung eines Tablet-only Android 3), dass Google keine langfristige Strategie hat.

[Update] Google fühlt sich offensichtlich nach der massiven Kritik (u.a. daring fireball und zdnet) genötigt, sich näher zu erklären. Ausserdem kündigen sie (in einem Update der Erklärung) an, für Safari und Explorer WebM-Plugins anzubieten. Mit Hilfe von ‘canPlayType’ (JS-Funktion, die z.B. bei der Frage canPlayType(‘[mime-type];[codec="codec-string"]‘) z.B. den Wert ‘maybe’ oder ‘probably’ zurückgibt) sollen dann auch diese Browser WebM abspielen können. Allerdings ist dies nach meiner Meinung keine optimale Lösung, da die meisten Browserweichen wahrscheinlich eher nach Browser/OS entscheiden werden, welche Video-Player-Lösung ausgeliefert wird. Ausserdem würde mich sehr wundern, wenn über die Plugin-Schnittstelle dieser Part des Browsers ohne weiteres angesprochen werden kann.

Irgendwie scheint sich meine Vermutung, Google hätte keine langfristige Strategie, zu bestätigen. Offensichtlich haben sie nicht mit so einem Sturm der Entrüstung gerechnet und versuchen jetzt die Wogen zu glätten. [/Update]

[Update2] Unter dem Titel “The Ambiguity of ‘Open’ and VP8 vs. H.264” ist ein ausgezeichneter Artikel über die Plug-In-Frage erschienen. Besonders interessant sind die Ausführungen über die Erweiterungsmöglichkeiten von Firefox, Chrome und Opera vs. Safari und IE9. Erstere spielen Videos über eigene Decoder ab, letztere handeln den video-Tag über die OS-eigenen und vor allem erweiterbare Decoder ab. [/Update2]

Die Genauigkeit eines heute Verfügbaren GPS-Empfängers liegt – je nach Quelle und Empfänger – bei 3 bis 50 Metern. Im Prinzip wäre GPS geeignet wesentlich genauer zu arbeiten. Allerdings wird die Genauigkeit durch natürliche und künstliche Einflüsse beeinflusst. Da diese Einflüsse aber auf alle Empfänger wirken kann man diese Abweichungen eigentlich rausrechnen. Dazu wird die Abweichung von einem Gerät berechnet, bei dem die exakte Position bekannt ist. (Eigentlich wird nicht die Abweichung der Postition berechnet, sondern die Abweichungen der Signallaufzeit zu den einzelnen Satelliten). Ein solches Differenzsignal nennt sich sperrig RTCM (Radio Technical Commission for Maritime Services) und kann von teureren Empfängern benutzt werden.

Ein normaler GPS-Empfänger ist ein recht nervöser Zeitgenosse. Ohne Korrektursignal springt die Position selbst dann, wenn man sich nicht bewegt.

Mit einem korrigierten Signal erreicht man – je nach Quelle – eine Genauigkeit von bis zu 2cm. Grade in unwegsamem Gelände (Häuserschluchten!) erhöht sich die Genauigkeit deutlich weil der Empfänger nur sehr wenige Satelliten sieht und Abweichungen (z.B. absichtliche Zeitverzögerungen) der einzelnen Signale sich besonders deutlich auswirken.

Für dieses Korrektursignal gibt es seit einigen Jahren sogar das Internetprotokoll Ntrip (Networked Transport of RTCM via Internet Protocol). Die Daten werden dabei im Wesentlichen in einen HTTP-Stream verpackt auf Anfrage ausgesendet. In Deutschland gibt es dutzende Server, die die Korrekturdaten für verschiedene Positionen senden. Allerdings sind offensichtlich alle geschützt und/oder kostenpflichtig. Mit dem schönen Namen SAPOS (Satellitenpositionierungsdienst der deutschen Landesvermessung) bieten die Länder verschiedene Dienste (siehe AdV) mit unterschiedlicher Genauigkeit an, die über unterschiedliche Medien übertragen werden. In Berlin sendet der RBB zum Beipsiel auf 88,8 ein Signal mit dem eine Genauigkeit von unter 2m berechnet werden können. Genauere Daten sind allerdings bei allen Bundesländern nur kostenpflichtig zu erhalten. Mit 10 Cent pro Minute dürfte es sich um den teuersten behördlichen Dienst überhaupt handeln.

Jetzt ist es aber nicht so, dass der Betrieb einer Referenzstation und die Bereitstellung der Korrekturdaten Raketenwissenschaft ist. Zwar wird dabei mit relativistischen Effekten gerechnet aber die Formeln sind bekannt und zum Teil als OSS (RTKLIB)  verfügbar. Inzwischen gibt es immer mehr Empfänger die sich dazu bringen lassen, die Rohdaten rauszurücken und bieten damit alles, was man als Referenzstation benötigt. Ein Set aus einem Navilock 551EUSB für ca. 30 € betrieben an einem Beagleboard für 150 € unter Ångström Linux, vernünftig kalibriert und mit dem Netz verbunden würde einen hervorragenden Ntrip-Server liefern.

Ein solcher Korrekturserver könnte jedes online verbundene Smartphone mit einer Genauigkeit im Zentimeterbereich ausstatten. Zusammen mit den inzwischen verfügbaren Gyroskopsensoren in aktuellen Androidgeräten und iPhones würden AR-Programme plötzlich wirklich Spass machen.

Es bleibt also die Frage, wer in Zukunft umsonst solche Referenzmessungen anbietet. Hallo Google? Hallo Nokia? Aber eigentlich ist es ja ein hervorragendes Crowdsourcing-Projekt.

Hier lang gehts zu weiteren Informationen:

• Einfache Einführung zu GPS: http://ivvgeo.uni-muenster.de/Vorlesung/GPS_Script/einfuehrung_historisches.html
• SAPOS Berlin: http://www.stadtentwicklung.berlin.de/geoinformation/sapos/
• Tobis Wendorff zu 40cm Low Cost Messung: http://openstreetmap.tobwen.de/fossgis2010_gps.pdf
• Beagleboard: http://beagleboard.org/
• User’s Guide ublox: http://www.zogg-jm.ch/Dateien/Update_Zogg_Deutsche_Version_Jan_09_Version_Z4x.pdf
• Navilock ublox5 GPS-Receiver bei Conrad: http://www.conrad.de/ce/de/product/372874/NAVILOCK-552ETTL-GPS-ENGINE-MODULE-TTL
• GPS-Community: http://www.kowoma.de/gps/
• OSS gpsd: http://gpsd.berlios.de/
• International verfügbare Ntrip-Server: http://www.rtcm-ntrip.org/home