MagicMapMilestones

aus Nomads, der freien Wissensdatenbank

zur MagicMap Übersicht

Milestones für MagicMap Weiterentwicklung (mit Personenzuordnung). Arbeiten am aktuellen Release stehen unter MagicMap_ChangeLog bzw. TODO-Liste.

Inhaltsverzeichnis

[bearbeiten]

Architektur

siehe MagicMap_Architektur_und_Schnittstellen

  • Initialortung. Anfrage an den Server, der gibt n Karten mit den meisten Übereinstimmenden APs (Baken) zurück. In diesen Karten ortet sich der Client und wählt die Karte mit der besten Ortung.
  • automatischer Kartenwechsel: bei jeder Ortung wird zunächst lokal nachgesehen, ob andere Karten mit übereinstimmenden APs existieren und ob eine Ortung darin Verbesserung bringt. Ansonsten wird eine Anfrage an den Server gestellt.
  • Integration von Acces Points/Basisstationen aus Nachbarkarten in die Ortung: dazu müssen zur Ortung die Daten von allen empfangbaren und fixierten Objekten vom Server geholt werden. Dazu die WGS84-Koordinaten. Besonders wichtig für Funktechnologien mit größerer Reichhweite, etwa GSM. Integration in das Caching Konzept, das einerseits Kartenbasiert sein sollte, andererseits aber auch einzelne Objekte cachen kann.
  • ersetzen von Netstumbler durch integrierte Treiberlösung (NDIS) für Windows XP (-> anweiss)
  • Synchronisation der Clients (wie auf MagicMapPosSync diskutiert, dadurch keine Abweichung der Visualisierung). Dazu Möglichkeit der Auslagerung der Berechnung auf unterschiedliche Knoten (-> lederer)
  • Trennung von Berechnung und Visualisierung einschließlich genauer Spezifikation der Schnittstellen und Herauslösen des GUI als (optinales) Plugin (-> anweiss)
  • Zusätzliche P2P-Kommunikation ersetzt den Server und erlaubt Skalierbarkeit. Darin enthalten: lokal vernetzte Situationen, in denen keine Internet-Verbindung vorhanden ist oder eine Nutzung lokaler P2P-Verbindungen effizienter ist.
  • Caching der wichtigsten Daten. Dazu persistente Speicherung.
  • Protokollierung der Historie. Dazu geeignet Komprimierung. Z.B. durch Ableitung. Dabei nur solche historischen Änderungen speichern, wo die Ableitung über einem Schwellwert liegt. Dieser Schwellwert ergibt sich aus der inhärenten Dynamik des Wertes, dem gewünschten zurückverfolgbaren Zeitraum und dem zur Verfügung stehenden Speichervolumen.
  • Kombination von Caching und Persistenz mit der P2P-Kommunikation. Siehe auch P2P-MagicMap, DistributedSharedMemory und ehcache
  • adaptive Stumbling-Intervalle, abhängig von Mobilitätsklasse (z.B. steht, geht, rennt, fährt) (-> lederer)
  • Schnittstellen zum Positionsdaten-Dienst von PlaceLab bzw. vice versa zum JavaWPS Client
  • Schnittstelle zu Skyhook Wireless
  • Schnittstellen zur AP-Datenbank von Fon / Spotigo bzw. vice versa
  • Schnittstelle zum Kartenmaterial openstreetmap.org
  • Schnittstelle zum Export der Daten (AP-Positionen, PoI) für GPS Exchange Format (.gpx), für Garmin und Navman (.csv), für Tom Tom (.ov2) oder Google Earth (.kml)
  • Entwicklung eines PlugIn-Konzeptes um MagicMap mit closed Source (z.B. eine Node für SecureBox) einfach erweitern zu können. (-> Rico Weber und Johannes Zapotoczky). Gelöst: Erweiterungen sind möglich, siehe MagicMap Architektur und Schnittstellen und PluginHowTo.
[bearbeiten]

Ortung

siehe auch MagicMap Verfahren

  • 3D-Fähigkeit (Parameter "h" als Abweichung von der Kartenebene in die Dämpfungsformel. Minimallösung: Ignorieren von Access Points)
  • Berechnung von Richtung und Geschwindigkeit der mobilen Knoten (-> lederer)
  • Berücksichtigung der Historie (der vergangenen Bewegung) und daraus abgeleiteten apriori Aufenthaltswahrscheinlichkeitsverteilung (vermutlich birnenförmig in Bewegungsrichtung mit den Parametern Geschwindigkeit+Richtung+Mobilitätsklasse). Dazu sind die Zufallsbewegungen von den systematischen Bewegungen (in Bewegungsrichtung) zu Filtern (evtl. Kallmann Filter?)
  • Neues Berechnungskonzept: Monte Carlo Methode generiert Partikel (entsprechend der apriori Aufenthaltswahrscheinlichkeitsverteilung mit "radius" r), Partikel werden bewertet nach ihrer Likelihood, Partikel mit Maximum Likelihood ist die beste Positions-Schätzung, Iteration passt aposteriori Aufenthaltswahrscheinlichkeitsverteilung entsprechend der Güte der Schätzung an (Simulated Anealing) (-> Lindstaedt)
  • Ermittlung der Güte der Postitionsschätzung (Genauigkeit als erwartete Abweichung von der tatsächlichen Position)
  • Dabei sollte die Ortung automatisch die Karte wechseln, wenn in einer anderen Karte eine höhere Likelihood erreicht wird (-> Stefan Keller & Team vom Projekt JavaWPS)
  • Erweiterung des Ortungsalgorthimus um variable Däumpfungsfaktoren (WAF - Wall Attenuation Faktor)
  • Erweiterung des Propagationsmodelles um nicht-omnidirektionale Strahlungsquellen und Empfangseinheiten (z.B. Richtantennen mit einem Öffnungswinkel) (-> Lindstaedt)
  • Berücksichtigung eines Umgebungsmodells: höhere X/Y-Bewegungswahrscheinlichkeiten auf Fluren, durch Türen bzw. in Z-Richtung auf Treppen und Fahrstühlen. Dagegen geringe Bewegungswahrscheinlichkeit durch Decken und Wände. Dazu sind entsprechende Modellierungsmöglichkeiten für Indoor-Umgebungen z.B. auf Basis von XML zu entwickeln.
  • Kontinuierliche Ortung: z.Zt. wird nur die Plausibilität (Wahrscheinlichkeit) eines Aufenhaltspunktes anhand der letzten Messwerte ermittelt. Bessere Ergebnisse sind zu erwarten, wenn man die Gesamtwahrscheinlichkeit über eine Trajektorie berechnet. Positionen die aufgrund unwahrscheinlicher Wege (z.B. durch Wände) hätten erreicht werden müssen, erhalten dabei geringere Wahrscheinlichkeit, als solche, die durch wahrscheinliche Wege erreicht werden konnten. Siehe dazu Pfadbasierte_Ortung.
  • Berücksichtigung des Umgebungsmodells zur Berechnung der Dämpfung. Zahl der vom Strahlengang gequeerten Wände gewichtet jeweils mit dem spezifischen Dämpfungsparameter der Wand
  • Berücksichtigung von typischen Bewegungsmustern: durch empirische Analysen können für bestimmte Wegebereiche Wahrscheinlichkeiten berechnet werden (z.B. auf Fluren bewegen sich die meisten in Flurrichtung und gehen nie durch Wände). Dadurch können Umgebungsmodelle auch ohne apriori Wissen erstellt werden bzw. ihre Nutzung präzisiert und zur Verbesserung der Ortungsgenauigkeit herangezogen werden. Hier gilt es aus den Messungen, Bewegungszonen mit Hauptbewegungsrichtung zu ermitteln, bzw. No-Go-Bereiche, die praktisch nie durchquert werden auszuschließen.
  • Automatisches Ausblenden neuer Accesspoints, bzw per Rechtsklick alle Accesspoints auf einmal ausblenden.
[bearbeiten]

Sensorik

  • Modiwechsel Infastruktur/Adhoc, damit sind sowohl RSSI Werte zu AP als auch zu beliebigen Clients zu erhalten
  • Scan im Promiscous Mode (nur mit geeigneter Hardware möglich, da dies nur wenige Treiber unterstützen)
  • Integration ASUS als Sniffer (Infrastrukturmodus/Ad Hoc Modus) (-> radetzki)
  • ASUS im Promiscous Mode (Tausch der MiniPCI Karte nötig) (-> radetzki)
  • Infrastruktulose Kommunikation, also ohne die Voraussetzung von einbuchbaren Access Points
  • Integration von RFID (aktiv/passiv) (-> Jzapotoc). Interface zu FEIG LRU 1000 wurde zur CeBIT 2006 vorgestellt. Mehr...
  • Dazu: Intergration in EPC Netzwerk (Speichern der Positionsdaten zu den einzelnen Transpondern), ähnliches macht auch Ekahau, siehe Pressemitteilung
  • Integration von Bluetooth
  • Integration von ZigBee (-> Jzapotoc)
  • Anpassung (Stumbler) für Apple Derivat
  • Integration von Beschleunigungssensoren (sind in vielen Geräten für Festplattenschutz bereits vorhanden)
  • Implementierung eines Stumblers für Windows XP (SP3) und Vista
  • GPS Rohdaten Trilateration
  • Lastgenerator für Debugging (erzeugt zyklisch ein ggf. vorher erfasstes Messprofil für einzelne reale oder virtuelle Clients)
[bearbeiten]

CE Client

  • Stromsparfunktionen: Sleepmodi und Wakeupfunktionen (periodisch stumbeln und dann schlafenlegen, Wake up on WLAN), Autoconnect bei verfügbarem Zugang (offener AP oder bekannter AP)
  • Stumbleransicht für schnellen Überblick über verfügbare Access Points: ähnlich WiFiFoFum
  • Integration des neuen CE Clients von Stefan und Willi in MMCE (abgeschlossen und seit Version 0.5 unter MagicMapCE verfügbar: Stefan)
  • Möglichkeit, Referenzpunkte in einer Karte zu setzen, Knoten zu verankern (abgeschlossen und seit Version 0.5 verfügbar: Stefan)
  • Migrationskonzept: wie kann der Java Viewer unter CE auf dem PDA genutzt werden (Migration des Java Code nach .Net oder alles Java mit automatischer Anpassung an Bildschirmauflösung und weitere PDA Spezifika)? Wie sieht die Schnittstelle zum Stumbler aus und wie unterscheidet sich das von der XP/Linux/Max Plattform?
[bearbeiten]

CE GUI

  • Optinales Ausblenden der Scrollbalken
  • Anzeige der Namen statt nur der MAC
[bearbeiten]

GUI

  • "Ignore" für Access-Points (sollen von der Berechnung ausgeschlossen werden und entweder ausgeblendet - falls unter Anzeige so eingestellt - oder z.B. etwas "blasser" dargestellt werden. Hierzu wird von BSS gerade etwas entwickelt!)
  • Zoom in/out (über Scrollrad + Zoom/Maßstab Listbox im Ansichtdialog/Symbolleiste)
  • Integrierte Visualisierung der Signalstärke als Höhenlinienmodell
  • Navigationsleiste mit hierarchischen Karten (zu hierarchischen Karten siehe MagicMap Kartenmodell)
  • untergeordnete Karten werden als Polygonzüge in übergeordnete Karten eingezeichner (trasparent, so wie bei Google Earth, Mausover zeigt den Namen und die Geokoordinaten der Karte)
  • Suchmöglichkeit nach Knoten in hierarchisch höheren Karten (z.B. suche "pibach" in "Europa")
  • Click auf Knoten sollte die Karte in der er sich befindet um diesen zentrieren
  • "zeige alle Knoten" durchsucht andere Karten nach Knoten, die ggf. auch in der aktuellen Karte liegen könnte (Likelihood > Threshold)
  • Integration von Georeferenzen in die Dialoge zum Anlegen/Bearbeiten von Karten (siehe Integration von WGS84-Koordinaten (Geokoordinaten) in MagicMap)
  • Nord-/Süd-ausrichtung bzw. Originalansicht von Karten wählbar
  • Speichern der Historie, durch "Zeitschieber" kann man dann in der Zeit navigieren, das Kontextmenü eines Knotens erhält "Verlauf anzeigen", ebenso die Auswahl Ansicht
  • Bewegungspfade anzeigen (z.B. Click auf Knoten, Kontextmenü: "zeige Bewegunsgsverlauf", ebenso in Ansicht "zeige Verlauf des ausgewählten Knotens")
  • Genauigkeit der Ortung geeignet kennzeichnen (z.B. durch Höhenlinien um einen Knoten, die Aufenthaltswahrscheinlichkeit darstellen). Das muss sich natürlich An-/Abschalten lassen
  • Darstellung von Richtung und Geschwindigkeit der Knoten (basierend auf zu implementierender Berechnung, s.o.)
  • Darstellung der Mobilität (steht= "rotes Ampelmännchen", geht= "grünes AmpelMännchen", rennt, fährt, ...)
  • Integration von Infoobjekten (Webseiten), Anbindung an Internet, speziell MediaWikis (Wikipedia, NOMADS Wiki), parsen von GeoTags (GeoRSS?, GPX?) und Darstellung an der richtigen Stelle.
  • Zuweisung von Icons an Objekte.
  • Tracker: Aktionen anhand bestimmter Muster(z.B. ein verankertes Objekt hat sich offenbar bewegt, dann gibt es Alarm)
  • Integration Skype in MagicMap (als exemplarischer Dienst, "SkypeMe" wird als Icon im Springlayout um die Objekte herum angezeigt, zusätzlich im Knoten-Kontext-Menü unter "Services")
  • Integration MagicMap in Skype (Aufenthaltsort wird im Skype Moode angezeigt, ähnlich Plazer)
  • Knoten-/Kanteninfos: anzeigen, wer über welchen AP online ist, bzw. wer nicht online ist. Welche APs haben welche Netzlast, wo sind Engpässe. Welche APs erlauben Zugang, welche Bandbreite (abhängig auch von SNR, entsprechend farblich kennzeichnen)
  • Integration des Gruppen-Konzeptes in die Navigationsansicht: Hierarchische Darstellung der Gruppen, Auswahl einer bestimmten Gruppe schränkt die Sicht auf diese Gruppe ein. Voraussetzung: der aktuelle User ist auch Mitglied der Gruppe.
  • Anzeige der angeforderten sowie der davon aktuell übertragenen und der insgesamt übertragenen Datenmenge - ähnlich wie das Google Maps Mobile macht
  • Umrechnung der kartenbezogenen Position in Koordinaten bzw. Adresse/HausNr./Etage und umgekehrt. Für die Umrechnung von Straßennamen in WGS84 Koordinaten und vice versa gibt es Web Services, einfacher ist es aber vermutlich, Straße/HausNr./Etage als zusätzliche Parameter beim Anlegen einer Karte abzufragen. Einfache Zwischenlösung ist die Ausgabe der nächstliegenden Referenzpunkte zu jedem Client
  • Umstellung Kartebasierte Darstelllung -> Objekt-Aggregationen
[bearbeiten]

GUI Monitoring

  • Fixierte Knoten, die die Ortung stören erkennen:
    • wenn deren Ortung von der Fixierungsposition stark abweicht
    • wenn deren Messungen starke Varianz zeigen
    • wenn deren Summe von Betrag (Ist-Kantenlängen minus Schätz-Kantenlängen) einen Schwellwert überschreitet. D.h. Sendeleistung liegt systematisch über oder unter der Annahme.
  • Unfixierte Knoten, die man auf "ignorieren" setzen könnte erkennen:
    • wenn deren h-Wert (Abstand von der Orungsebene, Höhe) einen Schwellwert übersteigt
  • Netzwerkprobleme erkennen:
    • mobile Knoten, die länger als T1 Sekunden (Default z.B. 30s) kein Positionsupdate liefern werden durch Eieruhr markiert. -> Release 0.9.3
    • ab Zeitspanne T2 (Default z.B. 1 Tag) werden durch Kreuz (als verstorben) markiert (unter Optionen kann man Garbage Collection Threshold T3 einstellen, dann werden die Toten nach Zeit T3 "beerdigt", also nicht mehr angezeigt, erst wenn Speicher voll, werden sie entgültig aus dem System gelöscht). Hier gibt es unterschiedliche Gründe: Client hat Verbindung verloren, ist ausgeschaltet, hat Karte gewechselt, etc. Dies sollte man im GUI schnell erkennen können.
[bearbeiten]

GUI Details

  • Help-Link auf neues Wiki (Benutzer:Jzapotoc: erledigt)
  • Ansicht "Zeige Karten" hierarchisch (pibach: Karten? ne hier war tatsächlich Kanten gemeint)
  • Zugangskonzept: Im Moment werden MAC und Passwort überprüft, der Clientname ist beliebig. Der Clientname sollte aber zuverlässig sein. Und das Passwort sollte änderbar sein.
  • detailliertere Ausblendfunktion: unabhängig
    • a) Knoten für Multilateration ausschliessen oder
    • b) Knoten bei Referenzmessungen ignorieren
  • Dialogbox bei Plugins mit Hinweis "neu Booten, dazu hier drücken"
  • zusätzlich den Cache beim Beenden mit allen geladenen Karten und Objekten abspeichern in ein File (oder mehrere, nach Karten oder Servern getrennt?)
  • bei Neustart immer den Cache wieder von Platte laden
  • unter Einstellungen eine Liste bekannter Server führen, dazu eine Option "automatisch verbinden" als checkbox
  • automatisch mit den so vorkonfigurierten Server und den eingetragenen Login Daten verbinden bei jedem Start
  • ausserdem sollte MagicMap bei Suspend to Ram oder Hibernation aktiviert bleiben können und sich dann automatisch neu verbinden und synchronisieren
  • ebenso eine Option "MagicMap automatisch starten beim Reboot"
  • idealerweise ist Magicmap dann ein Taskbar Icon rechts mit Statusanzeige (online/unsichtbar/offline und Anzeige des nearest Refpoint bei Mausover)
  • der nearest RefPoint sollte auch bei jedem Objekt in der NaviSicht erscheinen (als Anzeigeoption)
  • dazu in die Doku was zum Ressourcenbedarf (RAM Bedarf, CPU Wakeups je nach Status)
  • Sortierung der Karten nach Name oder chronologisch, Zahl der Clients, etc - generell: Objekte nach Attributen sortierbar
  • manuelles Zuweisen von Objekten zu einer Karte


[bearbeiten]

Plugins / Extended Features

[bearbeiten]

Dokumentation

[bearbeiten]

Distribution/Lizenz

  • zusätzlicher reiner Viewer ohne eigene Ortung
  • Distribution auch als Installer (nicht nur über Webstart)
  • Installer, bei dem "Packages" ausgewählt werden können (Viewer, Diverse Stumbler, Pos. Engine, welche Kommunikation, etc.)
  • Sourcen nur noch gegen Registrierung rausgeben, so dass wir wissen, wer was entwickelt und uns auch im Gegenzug seine Änderungen der Sourcen zukommen läßt. Aussderdem sollten sich alle "Server" (in Zukunft wird es diese Unterscheidung nicht mehr geben) gegenseitig synchronisieren. D.h. keine "autistischen" Server mehr.
  • Akkurate Lizenzregelung für alle Module
  • Lizenzregelung für die Inhalte (Karten, Objekte). Zu unterscheiden: Öffentlich (Commons Lizenz) oder closed? Dazu: Auf Server anlegen (speichern) oder per URL verlinken + cachen.
[bearbeiten]

Zugriffsrechte/Datenschutz

  • Hierarchisches Gruppenkonzept: Jedem Objekt wird eine oder mehrer GruppenID(s) zugeordnet. Zu jeder Gruppe gibt es einen "Creator", der initiale Zuordnungen vornehmen kann. Daneben gibt es "Administratoren", die vom Creator ernannt werden und "Member" einladen können. Die Member müssen die Einladung bestätigen, können aber jederzeit aus einer Gruppe austreten. Jede Gruppe kann entweder die Sichtbarkeit der Obergruppe erben, oder nur auf die Mitglieder der Unterguppe beschränken. Alle Nutzer/Objekte sind initial in der Root-Gruppe "Public". Nun können weitere Gruppen hierarchisch angelegt werden. Alle Mitglieder einer Gruppe können alle Objekte dieser Gruppe sehen, bzw. externe haben auf Objekte der Gruppe keinen Zugriff. Ferner kann nach Gruppen gefiltert und gesucht werden.
[bearbeiten]

Versionierung/Rollback

Jeder ändernde Vorgang zu einer Karte wird in ein Log-File protokolliert und kann zurückgenommen werden. Beispiele: Knoten fixieren, fixierte Knoten verschieben, Referenzpunkte setzen, verschieben, neu einmessen, Georefenrenzpunkte setzen, etc. Hierzu sind zu speichern: jeweils ein Zeitstempel, der User, der die Aktion ausgeführt und alle Daten, um die Aktion Rückgangig zu machen (z.B. alte und neue Position).

Von "http://wiki.informatik.hu-berlin.de/nomads/index.php/MagicMapMilestones"
'Persönliche Werkzeuge