OpenOffice.info

Aloha

marci hat geschrieben:hab aber absolut keine Idee, ob dies mit Basic so überhaupt umsetzbar wäre.

Prinzipiell ist (fast) alles umsetzbar, auch Dein Vorhaben.

Du müsstest halt in Deiner Datenbank zu jedem Ort (bzw. jeder PLZ, je nach Aufbau) die Koordinaten hinterlegen (entweder die tatsächlichen geographischen Koordinaten oder die aus einem eigenen Koordinatensystem, dass den westlichsten Punkt der Grenze sowie den südlichsten Punkt der Grenze als Nullpunkt hat - also ein Rechteck um die Deutschlandkarte, dass den westlichsten und südlichsten Punkt berührt - die Lage des Ortes innerhalb dieses Koordinatensystems musst Du dann beim Einfügen berechnen).
Dann müsstest Du nach Eingabe des km-Betrags für jeden einzelnen Eintrag in der DB den Abstand zum Ursprungspunkt berechnen und diejenigen herausfiltern, deren Abstand kleiner als der eingegebene km-Betrag ist.
Je nach Größe der DB könnte das schon einige Zeit in Anspruch nehmen, aber umsetzbar ist es auf jeden Fall.

Aloha

Da mich das Thema irgendwie auch persönlich interessiert hat, habe ich mal eine beispielhafte Datenbank erstellt.

Im Formular wird die Entfernung zwischen zwei Orten berechnet, deren geographische Koordinaten in der Datenbank hinterlegt sind (in der Form "50° 49′ N, 8° 46′ O" oder "50° 49′ 12″ N, 8° 46′ 30″ O", als String, wichtig ist nur das trennende Komma) und die Filterung über einen eingegebenen Umkreis zum ausgewählten Ausgangspunkt erlaubt.
Die Entfernung wird nicht ganz korrekt berechnet, die tatsächlichen Werte können um ca 0,25 % abweichen bei großen Entfernungen.

Die Koordinaten zu fast ausnahmslos allen Orten findet man bei Wikipedia (meist ganz rechts oben in der Ecke), aber sicher auch anderswo im Netz.

Die Beispieldatenbank muss nicht registriert werden o.Ä. sondern nur irgendwo physikalisch gespeichert sein (Andrew Pitonyak machts möglich).

Aloha

marci hat geschrieben:Hmmm... wenn du eine Gradangabe Nähe Grönland angibst, könnte es sich fast sogar zweistellig verzerren, wenn man mit Kreisberechnungen ankommt. Die Erdkugel ist ja bekanntlich an den Polen viel flacher.

Die benutzte Formel entspricht wie gesagt einer groben Näherung und hatte erstmal nur zum Ziel, innerhalb Deutschlands vernünftige Ergebnisse zu produzieren - dass Koordinaten z.B. auch südlich vom Äquator liegen können, habe ich ebenfalls erstmal ausser Acht gelassen

Und zum anderen hab ich gestern über vier Stunden nach einer Liste deutscher Orte (samt PLZ und Koordinaten) gesucht

Ich bin jetzt auf die Schnelle über
http://opengeodb.giswiki.org/wiki/OpenGeoDB bzw.
http://fa-technik.adfc.de/code/opengeodb/DE.tab (<- Über 5MB groß)
gestolpert, das sieht doch recht viel versprechend aus.

Ist eigentlich eine Suche mit der gleichen Anzahl an Tabellenwerten in Base schneller als in Calc?

Davon würde ich erstmal stark ausgehen.
Wenn ich wieder an einem Rechner mit installiertem OOo sitze, werde ich das aber mal ausprobieren.

Aloha

marci hat geschrieben:WAS ist DAS?

Eine Tabelle, die relativ viele Informationen zu Gemeinden und Postleitzahlen, unter anderem deren Koordinaten, enthält
Ob bzw. wie vollständig die Tabelle ist, kann ich nicht beurteilen - insgesamt sind es auf jeden Fall um die 65000 Einträge, wenn Du die Tabelle erstmal speicherst und dann mit Calc öffnest (importierst) hast Du vielleicht einen besseren Überblick.

Ich hatte heute mal wieder Zugriff auf OOo und hab den Berechnungsalgorythmus ein wenig verfeinert und deutlich beschleunigt - zum Testen in einem Calc-Sheet bin ich allerdings nicht gekommen.

Aber selbst mit der beschleunigten Berechnung dauert es schon mit 2000 DB-Einträgen eine ganze Weile (~2 Sekunden), bis die Filterung abgeschlossen ist, schliesslich muss für jeden einzelnen Eintrag die Entfernung neu berechnet werden.
Insofern stellt sich erstmal die Frage nach dem Umfang Deiner DB, bevor man sich Gedanken um eine Umsetzung macht.

Aloha

marci hat geschrieben:Man sollte sich aber noch a kleine Routine für den Import anlegen, die auto. die "0" vor 4stellige PLZs stellt.

4stellige PLZs? Ich dachte, sowas gibt es seit Mitte der 90er gar nicht mehr
Und ich hoffe doch sehr, dass Du Postleitzahlen (egal ob nun in Calc oder einer DB) nicht als Zahl, sondern als String hinterlegst.

Nur komm ich noch nicht damit klar, dass einige Datensätze mehrere PLZs besitzen. Ich hab gesehen, das einer sogar 14 PLZs hat.

Größere Städte Gemeinden / Städte haben mehrere Postleitzahlen (in der Regel, um die Stadt nochmal in Stadtteile zu unterteilen).
In der Tabelle wurden anscheinend Postleizahlen, die offensichtlich zu einer Stadt gehören, in einer Spalte zusammengefasst.

Ich hoffe sehr, dass mit dem Testsheet klappt noch.

Irgendwann bestimmt, nur habe ich mittlerweile aus "Prinzip" kein OOo mehr auf meinem Privatrechner installiert, daher kann ich nicht sagen, wann das sein wird

Ich frag mich nämlich schon seit einem Jahr, ob ich effektivere Lösungen gefunden hätte, wenn ich mit DB-Abfragen, statt Excel-Routinen, gearbeitet hätte

Das mit Sicherheit - eine vernünftig augfebaute und indizierte Datenbank wird spätestens ab einer bestimmten Größe immer schneller und handlicher sein als das Herumwerkeln mit Office-Anwendungen und -Dokumenten.
Aber gut, für den Schritt zurück wird es mittlerweile wohl eh zu spät sein.

Aloha

Die Sache mit den mehreren PLZs hatte ich schon verstanden.
Nur ist es so, dass
a) ein Ort mehrere PLZ haben kann, möglicherweise aber nur die Koordinaten des Stadtzentrums oder eines Stadtgebäudes o.Ä. bekannt sind
a) ein Ort noch mehrere kleinere Orte mit eigenen Postleitzahlen im nahen Umkreis haben kann und sich bis jetzt keiner die Mühe gemacht hat, für jede dieser Postleitzahlen die entsprechenden Koordinaten herauszusuchen, so dass eben mehrere PLZ den gleichen Koordinaten zugeordnet werden, obwohl dadurch kleine Ungenauigkeiten auftreten.

Ziel der Tabelle ist es, soweit ich verstanden habe, über die PLZ schnell und einfach die Koordinaten eines Ortes herauszubekommen, nicht unbedingt, zu jeder PLZ den entsprechenden Ortsnamen herauszufinden.
In Deiner Adress-DB wirst Du aller Voraussicht nach PLZ und zugehörigen Ortsnamen schon haben, Dich interessieren aus der Tabelle also nur die Koordinaten dazu.
Ob es für jede PLZ eine eigene Zeile gibt oder mehrere in einer zusammengefasst werden, ist dabei Jacke wie Hose.

Was den Aufwand angeht: das lässt sich aus der Ferne nicht beurteilen, da es immer darauf ankommt, was genau Du mit den Daten wie machst.

Aloha

Hatte heute mal wieder Zeit und OOo und hab das Ganze in ein Calc-Dokument gepackt.

Ein Sheet mit ca 1800 Orten aus der OpenGeoDB und deren Koordinaten sowie ein Suchsheet.
Den größten Zeitaufwand scheint das Kopieren der Daten in das Suchsheet zu verursachen, je nach Verwendung kann man da bestimmt noch einiges an Zeit sparen.

Schau mal, ob Du damit was anfangen kannst (ist erstaunlicherweise sogar schneller als die HSQL-DB, was ich höchst bedenkenswert finde).

Hallo DPunch,

hab´mich jetzt auch mal registriert.

Sooooo......... du wirst es nicht glauben, aber ich hatte dich eigentlich schon fast aufgegeben, da du dich soooooooooooooooooooooooo lang nicht gemeldet hast. *Erleichterung*

WOW. Du bist einfach SUPER! Genau DAS stellte ich mir vor. Das Gimmik mit der Anzeige der Such-Eigenschaften ist auch Klasse.

Jetzt weiß ich aber schon wieder nicht weiter. Da deinerseits so lang Funkstille war und ich die Problemstellung unbedingt lösen muß, sitze ich nun seit Tagen am Studieren diverser PDFs zum Thema HSQLDB und deren Schnittstellen-Programmierung. Mein Plan war nun eigentlich, alles komplett via Base zu realisieren - eben bevor du mir meine Calc-Lösung präsentiert hast.
Ich weiß auch nicht. Mit Calc kann ich umgehen und auch sämtliche andere Funktionen für mein Projekt programmieren - dennoch bin ich seit gerade eben am zweifeln, ob ich es nicht doch lieber in Base aufbauen sollte. Ich bin nämlich auf ein ganz gravierendes Problem aufmerksam geworden:
Über das Wochenende habe ich nun eine HSQLDB mit knapp 400.000 Referenz-Datensätzen (PLZs/Orten, Straßendaten, Geodaten und noch einiges mehr) angelegt und beim Kopieren der Daten aus Calc ist mir aufgefallen, dass das Calc-Dokument allein schon bei 60.000 belegten Zeilen fast 1 Minute zum Öffnen braucht. Wenn ich nun 400.000 Datensätze über mehrere Blätter verteile, reichen dann wohl bald kaum 10 Minuten, um das Ding zu Öffnen. Und meine Adress-Datensätze sind da noch gar nicht mit inbegriffen, wobei dort zudem jede Zeile fast 30 Werte mit oft über 100 Zeichen aufweist. Kannst du mir folgen?

Auch wenn ich jetzt durch dich, mein großer Meister , die Grundlage für alle weiteren Vorgänge in meinem Calc-Projekt habe, kann ich mit einer Datenbank, die so lang zum Öffnen braucht, nicht wirklich effektiv arbeiten. Zudem muß ich die Sheets ja auch nach Eintragungen speichern, was in meinem jetzigen Calc-Dokument mit knapp 1.000 Adressen schon fast 1s braucht.

WAS soll ich nur machen?

Und du meinst also, das die Calc-Berechnung echt schneller von Statten geht???????????? Des wär ja echt der Hammer!

GlG, Marci

Aloha

Die von Dir beschriebene Menge schreit ja geradezu nach einer ordentlichen Datenbank - obwohl es zwar durchaus möglich ist (und auch immer noch sehr häufig in kleineren Betrieben gemacht wird), sind Calc- (oder auch Excel-) Dokumente nunmal nicht für die Haltung solcher Datenmassen gedacht.

Du kannst ja ausserdem weiterhin mit Calc arbeiten und programmieren, nur dass Du Deine Daten dann nicht mehr aus einem Calc-Sheet bzw -Dokument beziehst, sondern aus einer Datenbank.
Insofern würde ich persönlich Dir auf jeden Fall zu einem echtem DBMS raten (z.B. MySql). Zumal dadurch, falls es denn mal nötig sein sollte, auch ein Multiuser-Betrieb ohne große Probleme möglich ist.

Aloooooha

hnm...... jetzt raucht langsam mein Kopf.

Also, ein Calc-Frontend für eine HSQLDB hatte ich mir auch schon vorgestellt... das wäre auch in meinem Interesse... aber WIE zum Teufel soll ich bloß eine MySQL-DB anlegen? DAVON hab´ich nun GAR KEINEN Plan. Mein Freund, bedenke bitte stets noch, dass du es hier mit einem Datenbank-Neuling zu tun hast.

Denkst du, dass dies wirklich nötig ist??? (eigentlich muß ich ja sagen, dass ich solch eine DB schon vor langer Zeit mal für andere Projekte geplant hatte ) Wenn ja: hast du vielleicht irgendwelche deutschen Installations- bzw. Betriebsreferenzen (wenn´s geht, für Anfänger), wo ich mich mal reinlesen kann und ggf. auch ein paar persönliche Tipps für mich? Und wie sähe dann die Schnittstellenprogrammierung in Calc aus? Muß ich dann jegliche DB-Verbindung mit der SQL-Sprachreferenz bedienen? Gibt´s dann in Calc überhaupt noch Basic-Anweisungen, die ich auch verstehen kann???

GlG, Marci

Aloha

Ob das wirklich nötig ist?
Das kannst allein Du entscheiden.
Zumindest das Grundwissen müsstest Du Dir halt aneignen, ansonsten macht das Ganze nicht viel Sinn. Da musst Du halt abwägen.
Zum Thema MySql, aufsetzen einen MySql-Servers, Step-By-Step-Anleitungen etc solltest Du im Internet mehr als ausreichend Informationen finden.

An der Programmierung selbst würde sich nur insofern was ändern, dass Du die Daten nicht mehr aus Calc-Zellen beziehst oder dort hinein schriebst, sondern von nun an eben per SQL-Statements aus der bzw. in die Datenbank.
Am besten verschaffst Du Dir einfach mal einen groben Überblick und entscheidest dann, ob Du meinst, dass Du damit klarkommst.

Dank dir.

Hab mir grad die Sprachreferenz runtergeladen und gehe sie in den nächsten Tagen durch. Schaut gar nicht soooooooooooo schlimm aus.

Also. bis die Tage...

GlG, Marci

Aloha DPunch,

also. Eine MySQL-DB habe ich nun erfolgreich mit Hilfe von XAMPP und PhpMyAdmin angelegt. Soweit schaut es ganz gut aus - die SQL-Befehle scheinen gar nicht so schwer.

Ich bereite jetzt gerade in einem Calc-Sheet die Daten für die DB vor (da die verschiedenen gegebenen Geo-Datensätze im Netz teils unvollständig bzw. auch fehlerhaft sind, und ich zudem auch die jetzigen 5 Datenbank-Sammlungen zu einer einzigen zusammenlegen möchte), hab aber ein Problem mit einer bestimmten Funktion: Und zwar habe ich mir folgendes kleines Makro zum Beseitigen doppelter Datensätze (Zeilen) gebastelt...
... welches aber seltsamerweise nicht 100%ig funktioniert. Aus dem Sheet wurden insgesamt etwa 4200 doppelte Datensätze entfernt - mal über den Daumen gepeilt sehe ich aber trotzdem noch über 500 Zeilen, die sich identisch sind. Hast du einen Rat?

GlG, Marci

Hat sich erledigt... mit der ersten Bedingung konnte er ja Datensätze mit leeren Feldern gar NICHT bearbeiten. Ich Dummchen...

Nichts für ungut...

Lg, Marci

Hallo Marci,

ist ja echt nett, Euch beiden so 'zuzuhören'.

Ich schlage mich seit drei Monaten mit der selbstgemachten Aufgabe herum, ein sehr umfangreiches Excel/VBA-Projekt in Calc/Basic umzuwandeln. Dauert irgendwie tierisch lange. Und ständig sagt mir mein Gefühl, daß das Quatsch ist, ich soll doch lieber gleich eine Datenbank anlegen.
Bitte sage mir doch mal, welche Literatur / welche Hilfen sind denn besonders gut oder verständlich. Ich bin, scheints, genauso blutiger DB-Anfänger und wage es einfach nicht, den Schritt von der Calc-Tabelle zur DB zu machen.
Wie geht das denn (wo stehts geschrieben): ein Calc-Frontend, welches auf eine DB zugreift?
Was schätzt Du, wieviel Einarbeitungszeit ist für einen durchschnittlich intelligenten Menschen nötig?

Viele Grüße
Volker