So könnt ich mir es vorstellen

    @blackvara:


    Was meintest Du mit PPC2002 unterstützt Handys?
    Kann man ohne Zusatzsoftware direkt auf die SMS zugreifen?
    Wie geht das?


    Garry


    OK, also meinetwegen auch mit vorangestellter Handynummer. Kannst Du die dann dem Header entnehmen, oder muss sie den Nav-Daten noch einmal extra vorangestellt werden ( das Erstere wäre m.E. die bessere Lösung )?
    Wen sie noch einmal vorangestellt werden soll/muss, dann müssen wir uns allerdings auf ein einheitliches Format ( nat. oder int. Schreibweise; Anzahl der Zeichen usw. ) einigen.


    Zitat

    Original von doNaT0
    folgende kombinationen sind bisher abgedeckt.


    - ppc mit gps-antenne über gprs zu http
    - handy ohne gps über sms to email.


    Ob mit oder ohne GPS ist grundsätzlich einmal egal. Ziel sollte sein, dass sowohl via GSM-Data/GPRS oder SMS-E-Mail übertragene Nav-Daten folgender Formate ausgewertet werden können:
    * raw NMEA wie z.B. RMC,GGA,VTG ( für den Anfang würde m.E. allein RMC auch reichen )


    * ( modif. ) Gauss-Krüger-Format ( wie von O2 auslesbar )


    * Siemens-Service-Pilot-Format ( auf Wunsch von Garry )


    * ein einfaches Lat/Lon-Format, das man ggf. auch als Text "per Hand" eingeben kann. Das könnte etwa so aussehen: N4912.34 E00856.78


    * Na ja, und später hätte ich auch gern noch das MPTP-Format der Benefon-Geräte implementiert ( aber das ist nicht so eilig und ist dann sicherlich auch keine grosse Sache mehr ).


    Klaus

    Zitat

    Original von Garry
    @blackvara:


    Was meintest Du mit PPC2002 unterstützt Handys?
    Kann man ohne Zusatzsoftware direkt auf die SMS zugreifen?
    Wie geht das?


    Garry


    Hi nicht ganz richtig es ist so das im system für programme die codes eingebaut sind und leicht programmiert werden können. z.B SMS senden usw...

    @GPSKlaus



    du meinst wohl die header infos aus der E-Mail. Ja die handynr kann ich daraus auslesen. muss nur schauen wie :)


    zu deinen verschiedenen koordinaten: also ich hab keine ahnung von dem zeugs :)
    ich würde sagen ihr einigt euch unter euch wie das format für die einzelnen parameter aussehen soll, macht ne liste und du erklärst mir wie das umgerechnet wird.


    aber ich glaub wir haben nen größeres problem. ich denk das das forum hier für den thread langsam unübersichtlich wird :( ich denke wir sollten verschiedene posts in der rubrik starten je nachdem zu was für nem teil des projekts der beitrag gehört:


    z.B.:
    - Programmierung
    - Daten senden
    - Datentypen
    - Website


    is jetzt net so toll gewählt aber sowas in der art :)

    Zitat

    Original von doNaT0
    @GPSKlaus
    du meinst wohl die header infos aus der E-Mail. Ja die handynr kann ich daraus auslesen. muss nur schauen wie :)


    Ja genau, die meine ich. Dann könnte man sich im E-Mailtext ( ausser vielleicht bei Gauss-Krüger; siehe dazu unten ) auf die reine Nutzinformation beschränken


    Zitat

    Original von doNaT0
    zu deinen verschiedenen koordinaten: also ich hab keine ahnung von dem zeugs :)
    ich würde sagen ihr einigt euch unter euch wie das format für die einzelnen parameter aussehen soll, macht ne liste und du erklärst mir wie das umgerechnet wird.


    So können wir es machen.
    Ist es richtig, dass am Protokollanfang jeweils ein paar eindeutige Zeichen zur Identifikation des benutzten Formats stehen müssen? ( also z.B. "$GPRMC" bei NMEA-RMC ). Den Gauss-Krüger-Daten würde ich dazu z.B. ein "GK" voranstellen.



    Mein Vorschlag:
    - Allgemein / Sonstiges
    - Datenübertragung ( GSM-Data/GPRS )
    ( Anm.: da das vermutlich nur per PPC geht, gehört hier auch dessen Programmierung mit dazu )
    - Datenübertragung ( E-Mail-SMS )
    - Navigationsdatenprotokolle ( NMEA, Gauss-Krüger usw. )
    - Website ( Datenauswertung )


    Klaus

    Zitat

    Original von GPSKlaus



    So können wir es machen.
    Ist es richtig, dass am Protokollanfang jeweils ein paar eindeutige Zeichen zur Identifikation des benutzten Formats stehen müssen? ( also z.B. "$GPRMC" bei NMEA-RMC ). Den Gauss-Krüger-Daten würde ich dazu z.B. ein "GK" voranstellen.


    da musst du blackvara fragen warum das dabei steht. es ist kein problem aber ich hab damit nix zu tun :) aber ihr klärt das schon ;)

    Zitat

    Original von doNaT0


    da musst du blackvara fragen warum das dabei steht. es ist kein problem aber ich hab damit nix zu tun :) aber ihr klärt das schon ;)


    Hier haben wir jetzt ein Verständnisproblem:
    "$GPRMC" ist der Header des wichtigsten NMEA-Protokolltyps; das ist schon klar, aber mir ging es hier um etwas anderes:
    Wenn Deine Auswertsoftware fähig sein soll, verschiedene Protokolltypen zu decodieren, dann müssen diese doch vom Programm zuerst einmal eindeutig voneinander unterschieden werden können. Dazu ist es m.E. nötig, dass jeder Typ mit einer ihn identifizierenden typischen Zeichenfolge beginnt. Oder sehe ich das falsch?


    Klaus

    @GPSKlaus


    hmm weiß ich net genau. ich könnte auch an hand der struktur der koordinaten bestimmen welches format verwendet wird. schreib doch mal bitte welche formate es gibt und wie so ein format im allgemeinen aussieht. also mit der angabe von z.b. $GPRMC gehts auf jedenfall. aber wir wollen ja die danteübertragung klein halten :)


    hab gerade deine mail gelesen. das is genau das was ich wollte :) ähm da sind aber nur 3 formate aufgelistet oder?

    Einmal editiert, zuletzt von doNaT0 ()

    @Donato
    Ich stelle Dir einmal die unterschiedlichen Protokolltypen zusammen und schicke sie Dir ( incl. Erläuterungen ).


    Bei den meisten Formaten ( z.B. NMEA-RMC ) können die benötigten Nav.-Daten ( Koordinaten von Längen- und Breitengrad ) im Wesentlichen direkt aus den empfangenen Strings extrahiert werden; bei anderen ( z.B. bei GK ) ist dagegen eine relativ aufwendige Umrechnung erforderlich. Dazu liefere ich Dir aber eine Subroutine, die Du dann an Deine Programmierplatform vermutlich aber erst noch etwas anpassen musst.


    Für die ganze Angelegenheit ist es m.E. noch wichtig zu wissen, in welchem Format das von Dir dann ausgewählte Map-Visualisierungsprogramm seine Eingaben erwartet.


    Klaus

    also ich würde sagen wir machen das am anfang auf ner lösung wie z.b. mapblast. weiß noch nicht welches format die benötigen. aber warum musst du das wissen? ich mein ich muss ja die koordinaten umrechnen und wegschicken. da spielts ja für dich eigentlich keine rolle?


    ich hab auch mit map24 (www.map24.de) kontakt aufgenommen. auf deren system basieren flottenlösungen wie z.b. die von mercedes... :)


    hab folgende preise für deren produkt MapTP bekommen:



    1. Preis für Basislizenz
    =======================

    1000,- pro Monat


    2. Preis für MapTP VM ( Ein VM ist ein "Vehicle Month", also ein Fahrzeug, das mindestens einen Tag im Monat an das System angeschlossen
    ist.): ============================================================

    bis 9.999 VMs: 3,- pro VM
    10.000 - 19.999 VMs: 2,50 pro VM
    ab 20.000 VM: 2,- pro Fahrzeug



    3. Kartendaten
    ========================


    - West Europa: 2,00 pro VM,
    - Ost Europa: 1,00 pro VM


    4. Zusatzangebote:
    ========================


    - Das Hosting über Map24 erhöht den variablen MapTP VM Preis um 30%


    - Der Routenberechnungsservice erhöht variablen MapTP VM Preis um 30%


    - Geocoding erhöht den variablen MapTP VM Preis um 10%


    - Reverse geocoding erhöht den variablen MapTP VM Preis um 10%


    - Beratung und Anpassungsarbeiten: 1.150,- pro Manntag

    Diese Preise sind auch zur allgemeinen Information für Sie gedacht und unverbindlich. Sollten Sie hierzu ein formelles Angebot wünschen, werde ich Ihnen dies gerne zusenden.

    @Donato


    Hoppala, das sind doch ganz erhebliche Preise ( für eine Hobbyanwendung! ).
    Ich habe mir ( vielleicht etwas zu naiv ) vorgestellt, dass man die Daten nur an eine bestimmte Web-Adresse schickt und sie dort visualisiert bekommt.
    Ich habe so etwas vor etwa einem Jahr einmal mit MapBlast durchgespielt, aber da war das absolut kostenfrei.
    http://www.kh-gps.de/mapblast.de


    Irgendwo habe ich allerdings gelesen, dass MapBlast nicht mehr ( vielleicht aber auch nur nicht mehr kostenfrei ) existieren soll.


    Und Du hast natürlich recht, ICH muss NICHT wissen, welches Format dabei erforderlich ist :) .


    Klaus

    Bezahllösung ist schlecht...
    Ich schlage vor, wir fangen erstmal mit MarcoPoloReiseplaner auf dem PC an und beschränken uns auf Europa. Neu kostet der ca. 30Euro, ältere Versionen gibt es praktisch geschenkt, habe hier auch noch welche (Original) herumliegen.


    Die Daten kann man einfach per (auch virtuellem) Comport einspeisen.
    Mit dieser Lösung kann man auch jede andere MAP-Software verwenden und funktioniert ebenso auf dem PPC, z.B. mit TomTom oder Oziexplorer.


    Garry

    @GPSKlaus


    hab mir eben das Programm mal angekuckt. Also da wird ja lediglich ein Kartenausschnitt angezeigt. Aber die Position wird auf der Karte nicht mit einem Symbol gekennzeichnet.


    Das was da Mapblast macht kann sicherlich auch map24 umsonst...

    @Garry


    Ich denke wir reden hier über zwei unterschiedliche Sachen:
    Das eine ist die Online-Auswertung empfangener Daten auf doNaTo's Server. Diese sollte man ( nach Codierung in ein einheitliches Format ) m.E. erst einmal als Text ausgeben.
    Dann ergab sich halt die Frage, ob man sie nicht auch für eines der existierenden Online-Map-Programme aufbereiten sollte. OK soweit!


    Etwas anderes ist es dann, diese Daten auch mithilfe eines beim Nutzer vorhandenen Programmes auszuwerten. Dazu würde es vermutlich sinnvoll sein, wenn sie in den NMEA-Formaten verfügbar wären.
    Dann könnten diese Daten von Jedermann mit der jeweils bevorzugten Software benutzt werden.


    @Donato
    Es muss auch Möglichkeiten zur Anzeige von Wegpunktpositionen geben. Das ist vermutlich nur eine Frage der richtig konfigurierten erweiterten Adresse.
    Irgendwo auf den Seiten der Map-Anbieter sollte sich auch die dafür erforderliche Protokollbeschreibung finden lassen.


    Klaus