Netzgedanken


Umkreissuche mit Lucene

12_2011
In einem aktuellen Projekt haben wir eine Suche nach freien Pflegeplätzen in Hamburg und dem angrenzenden Umland umgesetzt.
Das Konzept sah eine Umkreissuche vor. Das Budget verlangte, dass die Suche sich mit wenig Aufwand realisieren lassen sollte.

Die Aufgabe

Im Interface für die Suche wählen die User entweder einen Ort auf einer Karte aus oder sie geben eine Adresse postalisch als Strasse und Ort ein. Anschliessend entscheiden sie sich für einen Radius. Als Ergebnis werden alle freien Pflegeplätze angezeigt, die sich im gewählten Umkreis befinden.

Für diese Anwendung ist es nicht wichtig, dass die Ergebnisse sich *exakt* im gewählten Radius befinden. Der Umkreis stellt nur eine Annäherung dar; ob sich ein Objekt im 5 km-Radius oder im 6,75 km-Radius befindet, ist für den Nutzen der Suche unerheblich.

Daher können wir – anstatt die Objekte auf einen Kreis einzuschränken – einen Bounding-Box-Ansatz benutzen, der alle Objekte  findet, die innerhalb eines Rechtecks liegen. Bounding Box ist algorithmisch einfacher als das Einschränken auf einen exakten Radius. Wenn die Ergebnisse wieder auf einer Karte dargestellt werden, ist der Bounding-Box-Ansatz für die User auch nützlicher, weil im Ergebnis alle Objekte enthalten sind, die sich im jeweiligen Kartenausschnitt finden.

Lucene oder relationale Datenbank

Da wir die Pflegeheime nicht als Objekte in einer relationalen Datenbank vorliegen haben (sie werden als generische Content-Objekte im CMS gespeichert) und die gesamte Suche im Projekt mit Lucene implementiert wurde, haben wir uns dafür entschieden, auch für die Umkreissuche Lucene einzusetzen.

Berechnung

Aus der Wikipedia haben wir entnommen, dass zwei Breitengrade immer einen Abstand von 111 km haben, während der Abstand der Längengrade mit der geographischen Breite variiert. Am Äquator ist der Abstand zwischen den Längengraden am größten, am Pol laufen sie in einem Punkt zusammen.
Für Deutschland gilt, dass die Abstände der Längengrade zwischen etwa 75 km ganz im Süden und 64 km ganz im Norden laufen. Wir nehmen für Hamburg und Umgebung daher näherungsweise 66 km pro Längengrad an.

Die Adressen der Pflegeheime liegen nur postalisch vor. Für die Umkreissuche haben wir uns mit Hilfe der Google-Geocoding-API[1] die entsprechenden Koordinaten besorgt und sie im Lucene-Index gespeichert.

Die Eingabe der User überführen wir ebenfalls mit dem Google Geocoder in Koordinaten. Für die Suche nach Objekten in der Nähe ist dann nur noch das Bestimmen der Rechteck-Grenzen und eine einfache Range-Search in Lucene nötig:


left = center_lng - 1/66 * radius
right = center_lng + 1/66 * radius
bottom = center_lat + 1/111 * radius
top = center_lat + 1/111 * radius

latitude:[<bottom> TO <top>]) longitude:[<left> TO <right>]

Mit dieser Lösung ist es ohne viel Aufwand möglich, bestehende Lucene-Suchen um einen Umkreis-Filter zu erweitern.

In the last months we refactored a Flex/Flash app to HTML5.

The app is part of the german university ranking. It allows the user to select criteria and to watch universities rearranging in a circular manner.

It is called Quick Ranking and it is hosted by ZEIT ONLINE.

Why

The main reasons to use HTML5 instead of Flex/Flash were:

  • make the app accessible for IOS-based devices
  • integrate the app more tightly in the surrounding website
  • facilitate app development. No special tools are required, no compilation is needed.

For sure, not every flash app is suitable to be refactored to HTML5. The Flash animation engine is still outstandig and if you have a lot of elements moving and flying around, maybe Sound and Video and cutting edge visual effects, Flash is still state of the art.

But most of the Flash Apps are not cutting edge. They shift some elements from A to B, the user can interact lightly, elements are shown and hidden. No too fancy.

And that is exactly the kind of app we decided to reimplement in HTML5.

Canvas Object

Our first approach was to use the Canvas Object. We saw outstandig examples, very fast browser based games and we thought that Canvas Object is the way to go. Especially if you want to do it real HTML5, like the pros do. But after first experiments we were rather desillusionated. Canvas is fast, regarding the performance in the browser, but it’s very slow, regarding development speed.

With Canvas you have to do all the things again, that you – as a web developer – did the last time some 15 years ago, while you were studying animation arts and discovered that you can use computers as well instead of good old Bolex cameras. With Canvas you need (some say, you are enabled… :)) to do all the basic things from “Essential Computer Graphics, Volume 1″ again. Implement double or tripple buffering for smoothness. Repaint the background when your object moves. Doing dirty region analysis. Re-implement the easing stuff. When the going gets tough, the tough get going…

DIVs

But hold on. What we realized – after understanding what it really means to work with Canvas – is: Modern Browsers have really good graphic engines as well. You don’t have to do it on your own. Why not using div animation and your good old friend jQuery.

That is, what we finally did. With the help of jQuery we create DOM elements on the fly, scale them and move them around. Performance is rather good, however we had a close eye on tuning all the time.

Speed

We found some rules, that increased the speed of our app massively:
* create as few DOM elements as possible. Especially IE was speed up significantly, when creation of DOM elements were reduced
* do not scale images in animations. Remember the concept of key phases from your former analog animation days. If you have an image inside a div and the div has a border, and you want to scale them down, just do the following: Only animate the border and do the resizing of the image in one step at the beginning or at the end. Your audience won’t notice, but your CPU will
* don’t use jQuery live()-Events when you create and delete DOM elements a lot. Live()-events are comfortable, but it is much more performant to attach the event directly to the target element. Remember that live() events mean, that jQuery has to scan the DOM-tree for matching elements. That costs.


White Label Fotocommunity

Die Fotocommunity-Plattform erlaubt den Aufbau und den Betrieb von Webanwendungen, in denen Benutzer Fotos hoch laden und mit anderen teilen können.

Sie ist als White-Label-Angebot konzipiert, kann also einfach für andere Kunden angepasst werden.

Features der Software sind:

  • Upload
    Fotos hoch laden, auch mehrere gleichzeitig. Auslesen der Meta-Daten aus den IPTC-Tags. Manuelle Korrekturmöglichkeiten. Verschlagwortung.
  • Alben
    Beliebig viele Alben können erstellt werden. Fotos werden in Alben organisiert.
  • Ritch UGC
    Fotos und Alben kommentieren, zu Favoriten hinzufügen, Schlagworte vergeben.
  • Rechte kontrollieren
    Für jedes Bild kann individuell eingestellt werden, ob es in der Originalgröße heruntergeladen werden kann.
  • Suche
    nach Namen, Schlagworten, Metadaten
  • Usermanagment
    Registrieren, Verwalten von Usern, Passwort vergessen …

Die Fotocommunity-Plattform ist eine Java-Anwendung, die auf dem Play-Framework basiert.

Sie benutzt die Folge 3 UGC-Plattform, die Komponenten für User Generated Content-Angebote – wie Usermanagement, Kommentieren, Aktivitäten-Tracking, Umfragen, Gallerien etc. – bereitstellt und in diversen Projekten in den letzten Jahren zum Einsatz gekommen ist.


Recommendation-Engine von Folge 3

Schwarm-Intelligenz. Empfehlungen bilden mit einer Recommendation Engine.

  • “Interessantes Thema! Welche Artikel behandeln ähnliche Themen?”
  • “Ich habe Rindfleisch, Zitronengras und Kardamom. Was passt dazu?”
  • “Diese Wohnung gefällt mir ganz gut. Was gibt es an vergleichbarem?

Solche und ähnliche Fragen lassen sich mit unserer Recommendation Engine beantworten.

Empfehlungsarten

Die Software bildet die folgenden Arten von Empfehlungen:

  • Produktempfehlungen
    Das ist die gut bekannte Funktion “Wer sich für dieses Produkt interessiert hat, interessierte sich auch für die Folgenden”. Die Empfehlungen basieren auf den anonymisierten Bewegungsmustern der Site-Besucher. Was ein “Produkt” ist, ist nur durch die Vorstellungskraft eingeschränkt. Wir empfehlen bereits jetzt Bücher, Nachrichten-Artikel, Bilder, Universitäten, Studiengänge, Rezepte
  • Unterstützes Auswählen
    In komplexen Eingabemasken werden Benutzer durch Realtime-Empfehlungen geleitet. Sobald die Benutzerin zwei oder drei Kriterien ausgewählt hat, werden ihr weitere Kriterien empfohlen.
  • Matching / Unscharfes Suchen
    Wenn Sie ihren Benutzer “Erweiterte Suchen” anbieten, also Suchmasken, in denen sich die Suche auf bestimmte Eigenschaften ihrer “Produkte” einschränken lässt, dann können Sie die Recommendation Engine benutzen, um diese Suchen unscharf durchzuführen. Unscharfe Suchen oder Matching finden den best fit, also auch Artikel, die nur einigen der Kriterien 100%ig entsprechen.
  • Profil-basierte Empfehlungen
    Diese Empfehlungen werden auf Basis der Ähnlichkeit von Benutzern untereinander gebildet. Im Gegensatz zu den vorherigen Methoden benutzt dieses Verfahren nicht die impliziten Bewegungsmustern sondern basiert auf Profil-Informationen, die zu einem Benutzer gespeichert sind.


Über die Recommendation Engine

Die Empfehlungs-Engine ist eine Software von Folge 3. Wie alle Recommendation-Ansätze versucht sie, semantisch bedeutsame Relationen zu entdecken und führt dazu statistische Analysen in Tracking-Daten durch.

Die Datenbestände müssen nicht riesig sein, um aussagekräftige Empfehlungen zu bilden. In einem einigermaßen homogenen Umfeld reichen um die zweitausend Tracking-Datensätze pro Tag aus.

Die Empfehlungs-Engine ist in Java implementiert und benötigt als Backend eine relationale Datenbank (Postgres, MySQL, Oracle).

Sie basiert auf Mahout, einem weiteren exzellenten Projekt aus dem Apache-Lucene-Dunstkreis.

Sie kann entweder als Bibliothek in bestehende Anwendungen integriert werden. Oder sie läuft als eigenständiger Server, der über eine REST-API Tracking-Daten entgegennimmt und Empfehlungen ausliefert.


Eclipse locked up when building workspace

Yesterday eclipse worked as expected. But when starting up this morning it hangs forever (at least for to long for me to wait for it) on “building workspace “.

After excluding the ususal suspects (subversive, m2eclipse, mac osx firewall) it turned out – this time- , that one project referenced an outdated builder (org.openarchitectureware.base.oawBuilder) that was removed from my system some months ago. It seems that I forgot that particular project when migrating from oaw to the eclipse modelling project.

Removing the builder manually from the .project-file enabled eclipse to build the workspace and me to hack my first lines of code this morning.

And I have absolutely no idea why it suddenly stopped working. Or the other way around: why it did work over the last months.


Alfresco Share: The remote server may be unavailable …

Alfresco Share is a webapp that connects via HTTP-Requests to an anlfresco repository. The default installation assumes, that the alfreso repository is accessible at localhost:8080.
Kompletten Artikel lesen


“Update SVN Cache” locked eclipse

This morning Eclipse was locked after starting up. The progress bar indicated “Update SVN cache” as the blocking thread .
I restarted eclipse several times, including with “-clean” option, but that produced no result.

After fiddling with eclipse and railed at Polarion for some time, I remember

Kompletten Artikel lesen


Migrating OAW 4.3.1 to Eclipse Galileo

We recently decided to migrate our eclipse environment as soon as possible to Galileo. This implied that we had to migrate our openarchitectureware projects as well.

We are using OAW since 2006 in many projects. Most of them are still running and we moved them periodically to current OAW releases. So the task for today was to migrate OAW 4.3.1  to the Galileo release.

The migration was not really painful, but I had to collect  hints from several sources and it took me some time, to get running workflows again.

Therefor I decided to write down once the neccessary migration steps. Kompletten Artikel lesen


Don’t rename Eclipse.app

Don’t rename Eclipse.app! At least, don’t do it on MacOS X. I did it, because I have several Eclipse versions installed and I wanted to distinguish them in the Dock. This caused Eclipse to crash on startup. But not immediately. It took some time untill the error emerged and this made it difficult for me to relate the startup failure to the renaming of the app. Kompletten Artikel lesen

« vorheriger Eintrag