placemarker Bugs
ok, placemarker oder yql anfrage kommen definitiv mit einigen wiki artikeln nicht klar. Viele Städe zB. Berlin,Dortmund,Essen, Wuppertal,Passau liefern keine Orte zurück wobei zB. die englische Seite für Passau Ergebnisse liefert, die englische für Berlin aber wieder nicht. hat es vielleicht mit dem documentype:html/text zutun?
bzw. was wäre die geschickteste variante es via xpath an placemaker zu parsen, vorrausgesetzt die api, kommt einfach teilweise mit der seitenstruktur nicht klar...
und das australien, finnland problem existiert halt weiterhin.
ai... dass kann sein, denn gerade bei längeren texten schien das problem aufzutauchen!
Jetzt gibt es eine MultipleContentGeoWikiApp, die alle HTML-Paragraphen (< p >) im Artikel an Placemaker gibt, und deren extrahierten Plätze zusammenfasst. Damit kann man nun etwa auch Orte des "Passau"-Artikels lesen.
Dies ist recht roh. Hier müssten natürlich noch die Dupletten rausgenommen werden (z.B. indem man statt eine Liste ein Set nutzt), und vor allem der XPath angepasst werden, so dass nicht einfach alle p's, sondern etwa alle Abschnitte eingelesen werden können.
Ich bin jetzt erstmal weg, und versuch, da nachher nochmal drüber zu schauen.
Well, es scheint in XPath nicht direkt möglich zu sein, die Absätze aus Wikipedia-Artikeln sauber auszulesen.
Leider ist die Struktur bei den Artikeln ja folgendermaßen:
<h2>Leben</h2>
<p>Er wurde geboren...</p>
<p>Und ging dann...</p>
<h2>Beruf</h2>
<p>Nach seiner Ausbildung...</p>
Mit dem XPath
//div[@id="bodyContent"]/*[preceding::h2 and following::h2 and not(local-name()='h2')]
erhält man alle Nodes zwischen zwei Headlines (<h2>), aber eben nicht zusammengefasst. Man muss also
in jedem Fall in Java die einzeln auslesen und jeweils neu an Placemaker schicken -
so, wie ich das bereits in MultipleContentGeoWikiApp gemacht hatte. Tja, naja...
pläne.
ich werde nach wie vor das verlinkte seiten thema focussieren, und mich wohl mit lino zusammentun.
einen genauen plan, sprich skizzen gibt es nicht, sondern erstmal eine reihe von experimenten auch in die dritte dimension, um zu schauen, was man an mustern erkennen kann um diese dann im nächsten schritt noch stärker herauszuarbeiten.
das bild oben ist wiki/Kongo die Rote line ist der "Leitartikel"
hat sich beim letzten Treffen eigentlich noch etwas zum Placemarker Australien/Finnland Bug getan?
Nächstes Treffen: Mo, 18.01.
Und wieder hat die Gemeinschaft entschieden:
Montag, 18.01. von 10:00 - 13:00
Diesmal wieder im IDL.
(Wenn mehrere von euch nicht an der FH sind, können wir das auch wieder in Berlin machen, wenn sich nochmal ein freundlicher Host bereit findet. Bitte kommentieren.)
Sorry! Ich hab das mit bis Freitag irgendwie nicht mitbekommen (nachgetragen). Montags geht bei mir nicht, da hab ich nenn Kurs.
Ok. Vielleicht schaffst du es ja, für eine halbe Stunde ins IDL rüber zu kommen.
Ansonsten bin ich Montag auch nach 13 Uhr in Potsdam. Dann könntest du ja später vorbei kommen.
hab um 14Uhr Kurs und komm dann früher nach Potsdam, von daher fänd ich das IDL gut.
bin auch im LAB am start.
Ja, IDL ist für mich auch gut.
farbe
hab das ganze mal mit farben ausprobiert.
zip: "spinnennetz_farbig".
was geht sonst so bei euch?
grüße vom code-dilletant.
Spinnweben
bei den materialen hab ich ein zip (spinnweben) hochgeladen, das erste experimente mit dieser blubberartigen verbindung der einzelnen orte zeigt.
gut daran ist:
die flächen, an denen nichts passiert (z.b. atlantik) werden nicht gefüllt.
durch die spinnwebenartigen verbindungen können große entfernungen gut dargestellt werden, da je weiter sich zwei orte voneinander befinden, die "spinnwebe" zum mittelpunkt immer dünner wird. bei sich naheliegenden orten sind die verbindungen dagegen sehr flächig.
in diesem fall entsteht zwischen europa und nordamerika eine "spinnnwebenmasse" die ,finde ich, gut visualisiert, dass die bauhausmeister viel auf beiden kontinenten gearbeitet haben und dazu auch immer hin und her gereist sind.
gut ist, dass aber durch die verbindungen keine richtung festgelegt wird, von wo nach wo sie sich bewegt haben.
würde man die orte nur mit linien verbinden bekäme man schnell den eindruck, dass nur ein einziger transfer visualisiert wird.
insgesamt hängt alles irgendwie zusammen und trifft sich aber überwiegend in deutschland wieder.
probleme:
bei vielen übereinanderlagerungen kann es schnell ziemlich verwirrend werden, denke ich.
liest man artikel aus, bei denen sich die orte alle sehr nah beieinander befinden, kann man die einzelnen verbindungen nicht mehr erkennen, bzw voneinander unterscheiden.
der algorhytmus könnte deswegen schwierig zu schreiben sein, da es sehr viele verschiedenen verbindungsmöglichkeiten gibt, die immer eine andere form annehmen.
alternativ könnte man natürlich auch die wichtigsten orte des textes mit größeren grauen kreisen darstellen, was wieder zu einer anderen gesamtdarstellung führt. (letzte seite des PDFs)
was findet ihr so?
versuchs mal mit farbe. ich glaube da bekommt man nen besseren überblick. jeder artikel ne andere.
Gefällt mir gut, der Ansatz. Durch diese webigen, gezogenen Verbindungen erhält das einen interessanten organischen Charakter, wodurch eine gewisse Ungenauigkeit vermittelt wird. Daher finde ich es auch nicht besonders problematisch, dass die Verbindungen künstlich sind und nicht etwa auf einer zeitlichen Reihenfolge basieren.
Um die verschiedenen Artikel besser voneinander abzutrennen und unterscheiden zu können, könnten Farben tatsächlich helfen. Dein obiges Farbexperiment allerdings finde ich nicht so gelungen, was evtl. an den gewählten Farben liegt. Zudem solltest du mal probieren keine Satellitenkarte zu verwenden. Im SVN unter data habe ich grad eine einfache Länderkarte reingestellt.
Statt Farben könnte auch eine Interaktion helfen. Wenn der Nutzer die verschiedenen Artikel (z.B. über eine dynamische Legende) auswählen, und sich so die ihn interessierenden "Spinnennetze" anschauen könnte, wäre dies möglicherweise auch vielversprechend.
ok, das mit den farben war nur so mal ausprobiert. die sind schon komisch, das ist mir klar. wenn es aber mehr artikel werden, müssten noch viel mehr verschiedene farben ins spiel kommen, was ein problem werden könnte.
interaktiv würde sich anbieten, ich finde aber auch dieses kaugummiartige ineinandergeflochtene konstrukt ziemlich interessant, weil man da wichtige orte gut erkennen kann und so eine fusion der artikel entsteht.
finktioniert halt wahrscheinlich nur bei artikel, die irgendwas miteinander zu tun haben.
ich find allgemein eine farbe besser, mal sehn, was mir noch einfällt.
chea.
Ich hab im SVN grad einen neuen PlaceExtractor hinzugefügt (und das ein wenig umgebaut), der jetzt direkt die Placemaker API nutzt, und nicht via YQL geht. Das hat den Vorteil, dass wir nun auch POST (statt nur GET)-Anfragen machen können, und somit längere Texte zum Extrahieren hinschicken können.
Leider nur beschränkt Placemaker (ob direkt oder via YQL) die Texte auf 50kB. Dies ist offenbar auch der Grund, warum die von dir genannten Beispiele keine Ergebnisse liefern.
Ich werde gleich noch ein Beispiel committen. Dies nur schonmal als Info für die Leute, die derzeit dran arbeiten, ein SVN-Update zu machen.
10. Januar 2010 um 13:50 Uhr