Programmierung: Kurse auslesen per OCR ohne API

bei manchen Datenanbietern, hat man das Gefühl, dass diese Ihre Daten selbst per OCR von den Börsen holen, wenns mal wieder sehr langsam geht oder die solchen Datenmüll liefern, dass diese jedem der weiss worum es geht sofort aufgefallen wäre...

Aber im Ernst:
Wer programmieren kann, für den ist OCR das letzte, was in Frage kommt. Wenn überhaupt macht das nur bei analogen Datenquellen wie z.B. BloombergTV Sinn, wo ich mal für einen Kunden per OCR die Future-Kurse einlesen sollte.
Als ich die Kosten genannt hatte, ist der dann doch auf die Kurse von IAB für 8EUR / Monat gegangen !

Übriggeblieben war eine Lösung, um bei News die orangenen Texteinblendungen zu erfassen. Das "Abgreifen" von Daten, also das redigitalisieren von Textinformationen verstößt zu 99% immer gegen irgendwelche Urheber- / Nutzungsrechte !!!

Wenn man Daten abgreifen will, dann gibt es auch noch das umleiten und analysieren des Datentreams am Netzwerkinterface, sowie das Rastern von Charts.
(Wenn man Herrn Ebert ärgern wollte ginge beides. Man könnte als Chartbuch-Benutzer so an die puren CSI-Daten in Textform kommen, um diese selbst weiter zu nutzen...)

Also OCR für Kurse in "Quasi-Echtzeit" ist eine Krampflösung, aber geht wenn man will !
Das Abgreifen ist auf Datenebene meist einfacher, aber egal was man da macht es ist rechtlich sehr bedenklich !!!

Warum gefällt mir als Softwaredesigner* diese Idee nicht?

*Bezeichne mich zwar generell eher als Programmierer, aber ich das hier passt das andere Wort besser.

OCR ist fehleranfällig.

Ich weiß nicht, wie man überwachen könnte, ob die Zeichen richtig erkannt wurden. Wenn nicht, wäre mir das zu gefährlich, egal ob die Fehlerrate 0.001, 0.000001, oder wie gering auch immer ist (hängt von den Details ab). Stell Dir vor, die Putzfrau wischt den Schirm mit dem nassen Lappen ab, und ab da "erkennt" der Scanner die Hälfte der "1" als "7" ...

Gruß,
Asamat

@ Asamat [#4]
sorry das ist ja lustig ... wenn ich dich jetzt richtig verstehe, willst du den Bildschirm auf einen Scanner legen ...

Man darf Bildschimscannen nicht mit dem OCR von gescannten "Papierdokumenten" / Faxen vergleichen !!!

NEIN, Mit "scannen" vom Bildschirm ist hier die weitere Verarbeitung der Kopie des Bildschirminhalt als Grafikdaten gemeint. Also das was du mit den Tasten "ALT+DRUCK" in die Zwischenablage kopieren kannst, um es dann z.B. im WORD oder einen Grafikprogramm zu Dokumentationszwecken als Bild einzufügen und zu speichern !

OCR vom Bildschirm auf normalen Windowsprogrammen klappt zu 100% wenn:
- der Zeichensatz 100% bekannt ist, also ein installierter Windowsfont ist
- der Hintergrund konstant oder definiert regelmäßig(Farbverlauf) ist
- der Text horizontal dargestellt wird

All diese ist in jedem normalen Windowsfenster gegeben, nur ADOBE-Produkte machen das anders (stets interne Postscript-Fonts, eigene Kantenglättung, Zeichen mit Rundungen unten kommen etwas tiefer wie gerade Linen, also ein "O" steht tiefer als "Z")

Probleme gibts, von denen ich glücklicherweise noch gar nicht gehört habe.

Grüsse und das schöne Wochenende möglichst nicht zum Scannen verwenden
Albert

@ TimeTrade [#5]
Danke. Mich würde es einfach mal sehr interessieren, wieviel würde es ca. "kosten" deiner Meinung nach? Diese Zahlen der Kursfelder jede Sekunde in Excel zu schreiben? Fontsize kann man einstellen, aber der Hintegrund ändert sich grün/rot mit den Kursbewegungen...

Bezüglich "Netzverkehr" hört sich für mich aufwendiger an.

@ Marzell [#6]
:-) am WE sind die realtimes Kurse ja eher nicht üppig, die Versuchung hält sich so in Grenzen...

@ AAA [#7]

Das größere Problem bei der Aktion, ist die Daten schnell und sauber in EXECL rein zu bekommen, denn ich bin kein Microsoft/EXECL Experte :)

Pi mal Daumen die Kosten, wenn man sowas pauschal incl. Service machen muss:

- OCR-Lizens mit "Formulartemplate" => ~800USD plus je ~300USD pro weiteren PC
(http://www.charactell.com/iReadPrices.html)

- Windowshintergrundprogramm zum zyklischen Erfassen einer konfigurierbaren Region eines ausgewählten Fensters, was die Daten mit Timestamp erfasst und auch als fortlaufende ASCII-Datei speichert und für EXECL einen "altmodischen" DDE-Server bereitstellt => ~800..1000EUR

- ActiveX/COM-Server oder "RTD"-Server für EXECL habe ich selbst nicht in der "Toolbox", ohne Einarbeitung oder Zukaufkomponente geht hier nix, also pauschal auch ~1000EUR

Also je nach komplexität der Schnittstelle zu EXECL zw. 1600€ und 2600€ zuzüglich MwSt. für die erste Lizenz, für jeden weiteren PC sind dann die ~250€ fällig, welche durchgereicht werden.

(Bitte keine Diskussionen, warum so kommerziell und "teuer", warum nicht auf Basis von OpenSource-Projekten... Ganz einfach, davon kenne ich nix und alles was ich nicht kenne kostet Zeit, selbst die Suche nach geeigneten Sachen kostet Zeit und damit letzendlich noch mehr Geld...)

@ TimeTrade [#5]

Klingt einleuchtend, was Du schreibst; diese Variante von OCR kannte ich nicht. Die OCR-Mechanismen und -Software, die ich kenne, haben in keinem Fall eine 0%-ige Fehlerrate.

Eigentlich ist die Bezeichnung OCR für das, was Du beschreibst, falsch; sehe ich das richtig? Es wird ja gar nichts optisch erkannt oder versucht zu erkennen, sondern elektronisch.

Gruß,
Asamat

@ Asamat [#9]

Computer erkennen NIE etwas optisch !
Wenn nicht schon Grafikdaten vorliegen, dann wird erst digitalisiert (z.B. Papier im Scanner).
Die Verarbeitung von digitalen Grafikdaten nennt man bei OCR auch optisch, weil es im Sinn ja "Bild"daten sind.

OCR über Templates, d.h. die zu erwartenden Zeichen/Symbole sind in Position/Größe/Form/Ausrichtung vollständig bekannt, ist eine Sonderform mit exakter Auswertbarkeit, wenn die Daten in rein digitaler Form verarbeitet werden.

@ Alle

warum den Umweg über das Einscannen von Bildern?

Alle in Ihrem Quotecenter-Screen angezeigten Daten werden schliesslich auch vorher auf Ihren Rechner übertragen. Entsprechend wäre es nach m.E. sinniger diesen Traffic oder explizit den Darstellungscode mitzulesen und auszuwerten.

Eine Shell mit wget, egrep, cut und echo reichen hierfür bereits vollkommen aus. Piped man diesen Inhalt direkt in eine Datenbank / Excel-Datei und hinterlegt den Vorgang in einem Cron-Job, haben Sie Ihr eigentliches Ziel bereits mit einer hohen Präzision (der des Datenanbieters) erreicht.

Gruß,
fledgeling

@ TimeTrade [#8]
Danke, Du meinst dann das:
"CT-20, CT-Basic + Form recognition + form registration + OMR" für 795.-
Vielleicht komme ich mal drauf zurück.

Und wie würden sich die Kosten auf "Netzwerkebene" belaufen? Wäre doch sicher mehr als die Kosten für die obige OCR-SoftLizenz.

@ fledgeling [#11]
Mach(en Sie) doch mal "@all" ein Angebot. ;-)

@ AAA [#12]

solange im Netzwerk nur ein PC die Daten "aufnimmt", ist die OCR Lizens auch nur einmal fällig. Der eigene Aufwand, die Daten ins Netzwerk zu verteilen ist sehr gering.

Der Hauptaufwand liegt wieder im Tool, was die Anforderung erfüllt, dass im EXCEL selbstaktualisierende Felder 1x pro Sekunde geupdatet werden sollen.
Dieses ist dann einseitig ein netzwerkfähiger Client, der die Daten (vom OCR, oder was auch immer...) empfängt, und lokal als "DDE"- oder "RTD/COM"-Server selbstaktualisierend in EXCEL einfügt.

Über ein offizielles API geht vieles einfacher/besser/schneller/sicherer (z.B Oanda hat eins, IAB & TPRT sowieso).

Das undokumentierte mithören/analysieren der im HTTPS Kanal verschlüsselten Netzwerkdaten ist aufwendiger wie diese "Ein Sekunden OCR".
Egal was für Daten, man kann diese per Pipe weder einfach einfügen noch selbst aktualisierend darstellen und auswerten. Ist halt WIN/MS-Office und kein UNIX.

Aber wie gesagt, ich mache nur den Weg der Lösung über eine separte Programmlösung unter Windows. Ob das auch als VBA-Macro oder extern als Script Lösung geht, das ist mir egal, ist einfach nicht meine Baustelle.

(Ich behaupte aber trotzdem mal ganz frech, das kein Script mit puren Systemtools per CronJob und Pipe irgendwelche selbstaktualisierende Daten live in MS-EXCEL bekommt ;)

Jeder soll ja bekommen was er will, nur frage ich mich immer wieder, warum man sich mit einer Büroanwendung wie EXCEL im Liveeinsatz so quälen will...

@ TimeTrade [#13]
"warum man sich mit einer Büroanwendung wie EXCEL im Liveeinsatz so quälen will..."
Will man eigentlich nicht! Nur, IAB API-Daten hab ich schon in Excel geschaufelt u. darum eine Vorstellung von der Sache, einfach "Größenordnungsmäßig". Und das war ein Punkt der mich interessiert hat. Dabei habe ich auch festgestellt, dass mir Excel teilweise dafür nicht paßt, aber man kann damit mal was "ausprobieren"...

Der Grund, warum ich überhaupt auf die Idee kam, liegt an der marketindexplattform von abn, die hat keine api (soweit ich weiß, obwohl oanda technology). Habe mich gefragt, wie sich dort die "MM" "Kurse" zu den an den Börsen gehandelten Future underlyings verhalten.

@ AAA [#14]

ABN hat eine API, und zwar das womit die Ihr Java-Applet mit Daten füttern.

Selbst hier auf TMW hat der Webmaster so die ABN Daten in den "TMW-Style" gebracht.

Der einfache Weg wäre also, mal hier beim Webmaster anzufragen, was er machen musste, um die ABN Daten in seine Tabellen zu bekommen. Oder man fragt direkt bei ABN mal an, wie man an deren Daten für ein eigenes "Applet" nutzen kann.

Ein alternativer Weg ist z.B. das Abgreifen der Daten dieses java-Applets hier auf TMW, da hier nach erstem schnellen Check kein verschlüsseltes Protokoll intern verwendet wird. Nur wiederspricht das sicher etwas den Nutzungsbedingungen, zu denen Herr Ebert die Daten von ABN hier für das Board bezieht...

(Man darf bei ABN aber auch nicht die Frage nach einem automatisierbaren Quote/Orderinterface direkt stellen, die haben Angst, das man deren Quotelogik der endlosen MiniFutures durchschaut und über die realen Future in Abhängigkeit des gestellten asymetrischen Spreads zum eigenen Vorteil handeln könnte)

@ TimeTrade [#15]
Da http://www.terminmarktwelt.de/cgi-bin/nforum.pl?ABN=Group hatte ich noch nie vorbeigeschaut. Aber diese Daten haben doch nix mit der marketindex Plattform zu tun, oder doch?

"die haben Angst, das man deren Quotelogik..."
Eben. So können sie schön über ihre "Blackbox-Mittelkurse" - es gibt ja keine Trades/Volumenangaben zu den Kursen auf der Plattform, verschleiern. Und wenn ihnen was nicht paßt, sagen sie einfach da hätte kein "Mittelkurs" stattgefunden, die Kerze geht zwar durch den Bereich, aber da habe keine Trades stattgefunden... ;-)

@ AAA [#12]

ich werde mich in Kürze hierzu melden und Ihnen 'meine Methode' erläutern.

...mit etwas mehr Zeit

Zusammenfassend aus den obigen Postings:
- primäres Anliegen scheint der automatische Übertrag von wechselnden Webseiteninhalten in Excel Dateien
- weiterhin soll dieses möglichst auch aus einem Daten-Stream 1x pro Sekunde sein
- ebenfalls soll sich Excel selbstständig updaten

<snip #12>
Mach(en Sie) doch mal "@all" ein Angebot. ;-)
<snip>
Nö, ich hab schon einen Job und möchte mir keine Gedanken über Rechteverwertung (außerhalb des privaten Bereichs) machen, zumal 'diese' Lösung so simpel ist - ich würd' mich schämen. Unterstützt wird jedoch immer gerne...

Weiterhin würde die Low-Cost Lösung in diesem Fall (bedingt durch den angedeuteten Cronjob) auch nur minutenbasiert arbeiten - wäre dafür aber innerhalb von wenigen Minuten zu implementieren. Wie angedeutet, irgendein uralt-PC (ab PII) mit einem beliebigen Unix / Linux würde ausreichen, neben einer Shell sollte noch wget und perl, für datenbankbasiertes Arbeiten ggf noch mysql o.ä. installiert sein.

Die Basis: Mittels wget würde eine beliebige HTTP(S) Seite geholt, anhand immer gleicher Merkmale mit cut oder sed und awk die essentiellen Daten extrahiert und dann in eine Datei (db) geleitet werden.

Als Beispiel sei hier mal als Wert VW und Datenquelle die Yahoo "Realtime-Seite" genommen...

//Datenempfang
wget 'http://de.finance.yahoo.com/q/ls?s=VOW.DE'
(funktioniert natürlich auch bei HTTPS und / oder Passwortnotwendigkeit)

//Zeitstempel erzeugen (wobei auch der durch Yahoo gelieferte genutzt werden kann) und in Datei wegscheiben
echo `date +%H:%M` > /tmp/rohergebnis.txt

//aktuellen Wert extrahieren und hinter Zeitstempel anhängen
cat ls\?s\=VOW.DE|egrep 'Mittelkurs'|cut -d'>' -f 24-|cut -d'&' -f 1 >> /tmp/rohergebnis.txt

//aufbereiten (z.B. das Kommata für de-Excel durch einen Punkt ersetzen)
perl -p -i -e 's/,/./g' /tmp/rohergebnis.txt

//Tabulator für Excel einfügen
perl -p -i -e 's/ /\t/g' /tmp/rohergebnis.txt

//damit's 'schöner' klingt und Excel es versteht...
mv rohergebnis.txt ergebnis.csv

//bei z.B. mysql-Nutzung eben noch in db anhängen
mysql -e "LOAD DATA INFILE '/tmp/ergebnis.csv' INTO TABLE tabelle" dbname
(ggf um User und Pwd erweitern)

Entsprechend sechs Zeilen in einem kleinen (und zugegebenermaßen sehr unschönem, aber auch sehr einfachem und auch für jeden Anfänger verständlichem) Skript und jede Minute wird einmal der Kurswert weggeschrieben...

Es muss hierbei kein Traffic entcrypted werden und der Skriptansatz kann ebenfall beliebig erweitert / verfeinert werden. Mir fällt hier Etliches ein, bzw. ich nutze selbst Ähnliches, jedoch würde dann der Rahmen gesprengt - es soll sich nur um das Darlegen einer gaaaaanz einfachen Methode für das Grabben von (z.B. Yahoo-) 'Echtzeitdaten' sein.
Wie man Excel zur Aktualisierung zwingt - keine Ahnung, nicht meine Baustelle... Sekündliches Auslesen würde ebenfalls erheblichen Mehraufwand bedeuten...

Gruß,
fledgeling

@ fledgeling [#18]

Hab dein Beitrag jetzt erst gesehen.

Es handelt sich um ein "Java-Prog." aus dem Webbrowser gestartet, auf dem die Kurse erscheinen, kein html, drum die Sachem mit "Screen-OCR". Ich glaube du gehst von html aus!?

"... - primäres Anliegen scheint der automatische Übertrag von wechselnden Webseiteninhalten..."

So haben wir von zwei verschiedenen Dingen gesprochen. Aber beim nächsten Websiteauslesen, weiß ich Bescheid ;)

MfG und schönes WE

@ AAA [#19]

<snip>
Es handelt sich um ein "Java-Prog." aus dem Webbrowser gestartet, auf dem die Kurse erscheinen, kein html, drum die Sachem mit "Screen-OCR". Ich glaube du gehst von html aus!?
<snip>
Jip, aus dem Startposting war diese Info (noch) nicht zu entnehmen. Des weiteren fiel mir auf, dass der dargestellte 'Schmutzweg' nur für datenbankbesiertes Arbeiten Sinn macht. Ansonsten wären minimale Modifikationen notwendig...

Javadarstellungen hingegen sind fallabhängig. Kann ich mal einen BSP-Link bekommen, damit ich mir's mal ansehe?

Gruß

Also mit dem chartauslesen aus dem Web geht doch ohne Programmierung und viel einfacher.

Hier mein REAL DURCHGEFÜHRTER Programmierer- und Druckersparmodus:

Man nehme einen ATARI ST 520+ und einen entsprechenden Schwarz-Weiss Monitor.

Man nehme Butterbrotspapier (= durchsichtiges Pergamentpapier) und klebe dies mit Tesafilm auf den Bildschirm, wenn der chart zu sehen ist.

Man zeichne mit Bleistift die durchscheinenden Linien nach - und FERTIG ist die Analyse. Man braucht noch nicht mals einen Drucker. So einfach gehts !

So habe ich es selber in der PRAXIS gemacht.*

gruss hans

* ok, es war 1984, aber es war so....

@ fledgeling [#20]

Ich schrieb: "Preise von einem Broker ohne API zu verarbeiten"... :-) da dachte ich nicht jemand könnte an html denken! :-))

Um die "Plattform" zu testen kommt man glaube ich nicht drumrum einen Haufen von Formularkästchen zu füllen.

https://http://www.abnamromarketindex.com/de/kostenlos-testen-info.php5

Aber ansonsten ist es ja weit gehend die Software von oanda, wenn du abn nicht hast. Bei oanda hast vielleicht sowieso einen account?

@ he96 [#21]

Gib nicht so an! ;-) ...und ab wann warst du "mit BTX" online?

@ AAA [#22]

Haha - wer BTX kennt, hat sich selber als GRUFTIE enttarnt <g>

Näh, aber BTX und DATEX-J hatte ich nie...

Online erst ab 1996 , siehe 96 in meinem nick, das zur Beruhigung für alle die, die immer nur schweiniches dabei dachten...

gruss hans

Lool, BTX, das waren noch Zeiten, da hat der junge goso Charts auf Millimeterpapier gezeichnet.

@ goso [#24]

""Der JUNGE goso"" <<<<<<g>>>>>>>

Ich hatte "damals" immer einen USD/DEM chart auf Millimeterpapier bei mir und mittags um 1300 Uhr nach dem Bundesbank Fixing selber Kurse eingetragen - und den RSI im Taschenrechner gerechnet und eingetragen. Seit dem weiss wenigstens ICH was RSI für ein bullshit ist und waste of time.

Nach dann über die Wochen und Monate einige "Getränke- und Essensspuren" auf dem CHART prasselten, meinte ein Kollege: "Das ist kein chart, das ist ein Butterbrotspapier"...

Wenigstens hat man dieses Problem heute nicht mehr - nur noch die Getränke die in die Tastatur "hüpfen".

gruss hans