Als Software-Entwickler mit 15 Jahren Berufs-Praxis wurde ich immer wieder mit folgender Problematik konfrontiert: welche Städte haben welche Postleitzahlen, welche Städte gehören zu welchen Bundesländern, welche Bundesländer haben welche Städte, welche Bundesländer hat ein Land? Am besten weltweit, am besten international mit Multi-Lingualität.

Nach dem stets unzählige Datenbanken eingekauft wurden, die nie wirklich das Gelbe vom Ei trafen, teilweise schwer administrierbar und/oder unvollständig waren, entschloss ich mich dazu, eine eigene Struktur aufzubauen und diese mit diversen Quellen zu "füttern".

Das Endresultat dieser Überlegungen, bereits praxis-erprobt, liegt hier nun als sxgeo! vor. Kommerzielle Geo-Datenbanken bereiteten bereits an der Stelle Probleme, als das die Daten maximal in der 1. oder 2. Normalform vorlagen. Sie mussten immer erst aufbereitet werden, um praxistauglich zu werden. Abfragen innerhalb der gekauften SQL-Struktur waren und sind nicht selten sehr teuer  und somit wenig geeignet für hoch-skalierbare Anwendungen oder Web-Applications mit hohem Traffic.

Hier setzt sxgeo! an! Mit sxgeo! wollte ich anfänglich für diverse Intranet-Anwendungen und einem Online-Portal eine gewisse Unabhänigkeit erreichen. Ich wollte frei sein von vorgegebenen schlechten Strukturen. Mir schwebte eine Lösung vor, welche relational in hochperformanten Systemen angewendet werden kann, und von fremden Datenquellen lediglich gespeist werden muss. Ich wollte die Hierarchie zwischen geografischen Objekten (Kontinente, Staaten, Bundesländer, Landkreise, Städte, Postleitzahlen) relationell aufteilen und in einer Datenbankstruktur abbilden, welche es mir ermöglicht, jedes Geografische Objekt mit einer ID anzusprechen. Gleichzeitig sollte es möglich sein, jeweils via ParentID auf das übergeordnete geografische Element zuzugreifen als auch auf die Unter-Elemente (also von der Stadt auf den Landkreise, von dem Bundesland auf den Staat, vom Staat auf alle Bundesländer oder alle Städte aller Bundesländer).

SXGEO! entstandt zunächst in der Struktur: die Datenbank als solche und die Abbildung per Programmcode, testdriven entwickelt. Später suchte ich nach Quellen und band diese ein. Inzwischen setze ich ausschließlich auf die Quelle geonames.org. Deren Datenstruktur ist zwar eher erbärmlich und benötigt ein dringendes Refactoring, bevor man sie einsetzen kann, aber die Vollständigkeit ist enorm. Somit bindet sxgeo derzeit den Datenstand von geonames.org in die sxgeo-Struktur ein und verhilft den geonames-Daten zu einer ordentlichen, relationellen Struktur. Es ist und wird jederzeit gewährleistet, andere Datenquellen ebenso einbeziehen zu können.

sxgeo! wurde so entwickelt, das die Datenquelle als solche jederzeit ausgetauscht werden kann. Tatsächlich ist es jederzeit möglich, verschiedene Datenquellen anzuwenden. Entsprechende Import-Tools ermöglichen den Import aus der jeweiligen Quelle, auch wenn zunächst in der aktuellen Version lediglich geonames.org implementiert wurde. Dies hängt damit zusammen, das geonames.org derzeit das am meisten frequentierte Geo-Netzwerk darstellt, während andere Quellen nunmehr seit 2-3 Jahren keine Aktualisierung erfuhren und somit nicht mehr in das aktuelle Release einfliessen.

Mit sxgeo! möchte ich als Software-Entwickler und IT-Consultant unabhängig sein. Dafür wurde es entwickelt. Auf mehrfache Anfrage habe ich das Projekt veröffentlicht und stelle es Ihnen somit zur Verfügung. Sie zahlen nicht für die Daten, sie zahlen für eine gut durchdachte Datenstruktur, für ein anschauliches Objektmodell, für umfangreiche Initial-Daten und für einen guten Support.

Alles in allem verringern Sie Ihre Entwicklungskosten durch den Einsatz von sxgeo! dramatisch.