Fragen zu opengeodb (PLZ-Koordinaten, Performance, andere RDBMS)

[Andreas Korthaus]

Hallo!

Soweit ich die Datenbank (letzte Version von sf.net) verstehe, beziehen sich die Koordinaten auf Städte, und nicht auf PLZ, richtig?

Das heißt also, wenn ich für eine PLZ in Berlin eine Umkreissuche machen will, finde ich alle PLZs in Berlin mit 0 km, Entfernung,  oder?

Noch eine andere Frage, was muss ich beachten, damit die in der DB erzeugten Indizes bemutzt werden? Mich interessieren 2 Arten von Suchen:

1. Angaben zu einer PLZ suchen (Koordinaten, etc.), das sieht etwas so aus:

SELECT t.loc_id as loc_id, c.lon as lon, c.lat as lat
FROM geodb_textdata as t
LEFT JOIN geodb_coordinates as c
ON c.loc_id = t.loc_id
WHERE t.text_val = 12345 && t.text_type = 500300000
AND t.valid_until >= CURDATE() AND c.valid_until >= CURDATE()

Verwende ich hierbei die Indices so wie sie gedacht sind? Oder sollte man anders suchen?

2. Umkreissuche um diese Koordinaten herum. Ist der SQL-Code wie er in GeoClass verwendet wird auf die Indices optimiert (oder anders herum)?

Wenn ich das hier richtig gelesen habe, wird die Datenbank um Straßennamen und Ortsteile erweitert. Ist hierbei zu erwarten, dass die PLZ-Suche z.B. für Berlin genauere Distanzen im Stadtgebiet hinbekommt? Ist das überhaupt aussichtsreich Koordinaten für Straßennamen zu integrieren? Mal so in %, wie vollständig bekommt man das mit frei verfügbaren Daten überhaupt hin?

Macht es eigentlich nicht Sinn, zumindest sin() und cos() Ergebnisse in der Datenbank zu speichern, so dass die nicht bei einem Full-Table Scan 40.000 mal neu berechnet werden? Großartig Platz wegnehmen dürfte das nicht...

Noch eine Frage zu anderen Datenbanken:

Hat schonmal jemand die Daten in MSSQL oder Oracle eingetragen? Geht das grundsätzlich oder was für Probleme sind  hierbei zu erwarten?
Oder was ist mit OpenGIS Implementierung in MySQL? Könnte man die nicht sinnvollerweise nutzen?

Viele Grüße
Andreas
_________________________________________________________________________
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten!
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Thomas Preymesser]

On 11/02/2008, akorthaus@... <akorthaus@...> wrote:

Hallo!

Soweit ich die Datenbank (letzte Version von sf.net) verstehe, beziehen sich die Koordinaten auf Städte, und nicht auf PLZ, richtig?

nö.

Mein Ruby-Gem findet für die PLZen 13359 bzw. 13357 folgende Koordinaten:
52.5623515502214
13.3876310000699
52.5525768798017
13.3838173801168

wie man sieht, sind die sehr wohl unterschiedlich.

Gruß
-Thomas

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

akorthaus@... wrote:
> Hallo!
>
> Soweit ich die Datenbank (letzte Version von sf.net) verstehe,
> beziehen sich die Koordinaten auf Städte, und nicht auf PLZ,
> richtig?

Ja

> Das heißt also, wenn ich für eine PLZ in Berlin eine Umkreissuche
> machen will, finde ich alle PLZs in Berlin mit 0 km, Entfernung,
> oder?

Ja



> Wenn ich das hier richtig gelesen habe, wird die Datenbank um
> Straßennamen und Ortsteile erweitert. Ist hierbei zu erwarten, dass
> die PLZ-Suche z.B. für Berlin genauere Distanzen im Stadtgebiet
> hinbekommt?

Ja

> Ist das überhaupt aussichtsreich Koordinaten für
> Straßennamen zu integrieren?

Ja

 > Mal so in %, wie vollständig bekommt man
> das mit frei verfügbaren Daten überhaupt hin?

Sie z.B. http://wiki.openstreetmap.org/index.php/Bayern - für Berlin
habe ich es noch nicht probiert.

> Macht es eigentlich nicht Sinn, zumindest sin() und cos() Ergebnisse
> in der Datenbank zu speichern, so dass die nicht bei einem Full-Table
> Scan 40.000 mal neu berechnet werden? Großartig Platz wegnehmen
> dürfte das nicht...

Das kommt auf deine Anwendung an. Deine Argumentation ist schlüssig,
dass du dir wiederholte Berechnungen sparen kannst.

Schönen Gruß
Martin
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Thomas Preymesser wrote:

> On 11/02/2008, akorthaus@...<akorthaus@...>  wrote:
>> Hallo!
>>
>> Soweit ich die Datenbank (letzte Version von sf.net) verstehe, beziehen
>> sich die Koordinaten auf Städte, und nicht auf PLZ, richtig?
>
>
> nö.
>
> Mein Ruby-Gem findet für die PLZen 13359 bzw. 13357 folgende Koordinaten:
> 52.5623515502214
> 13.3876310000699
> 52.5525768798017
> 13.3838173801168
>
> wie man sieht, sind die sehr wohl unterschiedlich.

Dann stammen die aber wohl nicht aus dem letzten SF-Dump - denn dort
findet sich die 13357 und 13359 als PLZ von Berlin
http://fa-technik.adfc.de/code/opengeodb.pl?locid=14356;c=DE

Sieht man hingegen in http://fa-technik.adfc.de/code/opengeodb/PLZ.tab 
nach, so findet man deine Koordinaten von PLZ-Gebieten:

#loc_id plz lon lat Ort
...
13055 13357 13.3838173801168 52.5525768798017 Berlin
13056 13359 13.3876310000699 52.5623515502214 Berlin

Der aktuelle SF-Dump enthält nur wenige PLZ-Gebiete - die liegen derzeit
ausserhalb und werden nicht dem Dump hinzugefügt.

Schönen Gruß
Marrtin
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Andreas Korthaus]

Hi!

> > Soweit ich die Datenbank (letzte Version von sf.net) verstehe,
> > beziehen sich die Koordinaten auf Städte, und nicht auf PLZ,
> > richtig?
>
> Ja

Aber im neusten Dump auf dem von Dir verlinkten Server ist das anders, oder? Denn wenn ich da eine PLZ angebe und die Entfernung zu Städten in der Umgebung errechnen, ändern sich die Werte bei benachbarten PLZs in einer Stadt.

>  > Mal so in %, wie vollständig bekommt man
> > das mit frei verfügbaren Daten überhaupt hin?
>
> Sie z.B. http://wiki.openstreetmap.org/index.php/Bayern - für Berlin
> habe ich es noch nicht probiert.
>
> > Macht es eigentlich nicht Sinn, zumindest sin() und cos() Ergebnisse
> > in der Datenbank zu speichern, so dass die nicht bei einem Full-Table
> > Scan 40.000 mal neu berechnet werden? Großartig Platz wegnehmen
> > dürfte das nicht...
>
> Das kommt auf deine Anwendung an. Deine Argumentation ist schlüssig,
> dass du dir wiederholte Berechnungen sparen kannst.

Ist irgendwo erklärt, was die folgende Dateien auf dem Server enthalten?
DE.sql
DE.tab
DE9.tab
PLZ.tab

Sind z.B. in PLZ.tab alle PLZs inkl. Angaben zu Koordianten und Ort drin, die auch im kompletten Dump stehen?

Hat DE9 dasselbe Format wie DE?

Was ist der inhaltliche Unterschied zw. DE.sql und DE.tab?

Kann man auf dem Server vielleicht auch die Skripte speichern, mit denen die Listen aus der Datenbank extrahiert wurden? Wäre sicher hilfreich als Vorlage oder für den Fall, dass die Dateien irgendwann nicht mehr gepflegt werden...  (Mich würde z.B. interessieren, wie man nicht-Deutschland Einträge komplett rausbekommt, prinzipiell kann ich mir da vorstellen wie das geht, ist aber alles so verstreut gespeichert...)

Jedenfalls wäre die Abfrage der PLZ.tab für mich deutlich effizienter als die der Datenbank. Zur Zeit brauche ich für eine Umkreissuche auf Basis der GeoClass mit aktuellem Dump ca. 10 Sekunden, Das geht natürlich nicht auf einer Homepage...

Ist ja auch verständlich wenn der gesuchte Datensatz mit jedem anderen Mittels sphärischer Trigonometrie vergleichen werden muss... Cachen der sin() und cos() Werte würde sicher was bringen, ich weiß aber nicht ob das genug ist, werden das testen. Zur Not berechne ich einfach die Eckpunkte eines Quadranten mit den gesuchten Koordinaten in der Mitte, so dass nur ein paar Bits vergleichen werden müssen... Ist natürlich nicht ganz so genau, aber sollte für viele Zwecke ausreichen. Oder spricht da was dagegen?


Wie kommt es eigentlich, dass die Indices so groß sind?

Grüße
Andreas
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

akorthaus@... wrote:

>>> Soweit ich die Datenbank (letzte Version von sf.net) verstehe,
>>> beziehen sich die Koordinaten auf Städte, und nicht auf PLZ,
>>> richtig?
>> Ja
>
> Aber im neusten Dump auf dem von Dir verlinkten Server ist das
> anders, oder?

Nicht dass ich wüsste

> Denn wenn ich da eine PLZ angebe und die Entfernung zu
> Städten in der Umgebung errechnen, ändern sich die Werte bei
> benachbarten PLZs in einer Stadt.

Beispiel?


> Ist irgendwo erklärt, was die folgende Dateien auf dem Server
> enthalten? DE.sql DE.tab DE9.tab PLZ.tab

Nein, da muss jemand mal ein README schreiben.

DE.tab - die Basisdaten für Deutschland
DE.sql - die Basisdaten konvertiert nach SQL
DE9.tab - erste Anfänge eines Straßenverzeichnisses für opengeodb,
exemplarisch Baden-Württemberg. Inzwischen liegen auch Niedersachsen und
Bayern vor. Diese Daten unterliegen der OSM-Lizenzierung (CC-BY-SA)!


> Sind z.B. in PLZ.tab alle PLZs inkl. Angaben zu Koordianten und Ort
> drin, die auch im kompletten Dump stehen?

Nein, PLZ.tab enthält die Daten von Postleitzahlgebieten, typ 100800000


> Hat DE9 dasselbe Format wie DE?

ja

> Was ist der inhaltliche Unterschied zw. DE.sql und DE.tab?

sql vs. txt

> Kann man auf dem Server vielleicht auch die Skripte speichern, mit
> denen die Listen aus der Datenbank extrahiert wurden? Wäre sicher
> hilfreich als Vorlage oder für den Fall, dass die Dateien irgendwann
> nicht mehr gepflegt werden...  (Mich würde z.B. interessieren, wie
> man nicht-Deutschland Einträge komplett rausbekommt, prinzipiell kann
> ich mir da vorstellen wie das geht, ist aber alles so verstreut
> gespeichert...)

Die kannst du am besten im wiki selbst veröffentlichen:
http://opengeodb.giswiki.org/wiki/OpenGeoDB


> Jedenfalls wäre die Abfrage der PLZ.tab für mich deutlich effizienter
> als die der Datenbank. Zur Zeit brauche ich für eine Umkreissuche auf
> Basis der GeoClass mit aktuellem Dump ca. 10 Sekunden, Das geht
> natürlich nicht auf einer Homepage...

Ich selbst verwende direkt diese PLZ.tab für
<http://www.fa-technik.adfc.de/Codierung/anbieter>

> Ist ja auch verständlich wenn der gesuchte Datensatz mit jedem
> anderen Mittels sphärischer Trigonometrie vergleichen werden muss...
> Cachen der sin() und cos() Werte würde sicher was bringen, ich weiß
> aber nicht ob das genug ist, werden das testen. Zur Not berechne ich
> einfach die Eckpunkte eines Quadranten mit den gesuchten Koordinaten
> in der Mitte, so dass nur ein paar Bits vergleichen werden müssen...
> Ist natürlich nicht ganz so genau, aber sollte für viele Zwecke
> ausreichen. Oder spricht da was dagegen?

Bei mir läuft das anders - ich berechne von der Mittelpunktskoordinate
erst einmal die gewünschten Abweichung in lat/lon (also z.B. 45±1 / 9±1)
und berechne die Entfernung dann nur für jene Einträge, die sowohl im
Bereich lat=44..46 als auch lon=8..10 erfüllen. Alle anderen sind schon
zuvor ausgeschieden.

Schönen Gruß
Martin
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Andreas Korthaus]

    > Denn wenn ich da eine PLZ angebe und die Entfernung zu
    > Städten in der Umgebung errechnen, ändern sich die Werte bei
    > benachbarten PLZs in einer Stadt.

    Beispiel?

z.B. Aachen: PLZ 52062 und 52078
Beide haben loc_id: 13352

Aber bei 52062 ist das erste Ergebnis (Aachen) 0,3 km entfernt, bei 52078 ist es ebenfalls Aachen, aber > 1km entfernt. Entsprechend haben auch die folgenden Städte andere Distanzen.

Allerdings weiß ich nicht ob das vorher anders war, das hatte ich nicht getestet. Da aber deutlich mehr Koordinaten-Daten in der neuen Version enthalten sind, war ich davon ausgegangen, dass sich hier was geändert hat.

Was mich daran aber wundert ist die Tatsache, dass 2 PLZs, die die gleiche loc_id haben, anscheinend andere Koordinaten haben. Ich hatte das eigentlich so verstanden, dass in der Koordinaten-Tabelle die loc_id referenziert ist. Aber irgendwie muss es ja noch einen zweiten Schlüssel geben, sonst müssten die Koordinaten gleich sein. Was wäre dieser Schlüssel?

Bei Berlin gab es keine Änderung da haben die PLZs die ich getestet hatte alle dieselben Koordinaten (ausgerechnet bei Berlin ;-).


    > Ist irgendwo erklärt, was die folgende Dateien auf dem Server
    > enthalten? DE.sql DE.tab DE9.tab PLZ.tab

    Nein, da muss jemand mal ein README schreiben.

Vermutlich habt Ihr das schon häufiger erklärt, könnt Ich nicht einfach 2-3 Postings aus dieser Liste  in die README eintragen oder von irgendwo verlinken, oder einfach  einen Abschnitt wie den Folgenden in in die README eintragen? Alles ist besser als gar keine Infos. Muss ja keine perfekte Umschreibung sein...

    DE.tab - die Basisdaten für Deutschland
    DE.sql - die Basisdaten konvertiert nach SQL
    DE9.tab - erste Anfänge eines Straßenverzeichnisses für opengeodb,
    exemplarisch Baden-Württemberg. Inzwischen liegen auch Niedersachsen und
    Bayern vor. Diese Daten unterliegen der OSM-Lizenzierung (CC-BY-SA)!


    > Sind z.B. in PLZ.tab alle PLZs inkl. Angaben zu Koordianten und Ort
    > drin, die auch im kompletten Dump stehen?

    Nein, PLZ.tab enthält die Daten von Postleitzahlgebieten, typ 100800000

OK, geodb_type_names  sagt mir, dass es 500300000 gibt (Postleitzahl) und 100800000 (Postleitzahlgebiet). Was genau ist der Unterschied, vor allem für eine Umkreissuche in der Praxis?

Sind beide Listen vollständig?


    > Kann man auf dem Server vielleicht auch die Skripte speichern, mit
    > denen die Listen aus der Datenbank extrahiert wurden? Wäre sicher
    > hilfreich als Vorlage oder für den Fall, dass die Dateien irgendwann
    > nicht mehr gepflegt werden...  (Mich würde z.B. interessieren, wie
    > man nicht-Deutschland Einträge komplett rausbekommt, prinzipiell kann
    > ich mir da vorstellen wie das geht, ist aber alles so verstreut
    > gespeichert...)

    Die kannst du am besten im wiki selbst veröffentlichen:
    http://opengeodb.giswiki.org/wiki/OpenGeoDB

Ich hab die Skripte ja nicht. Ich dachte mir nur, dass jemand irgendwelche kleinen Skripte für solche Zwecke geschrieben hat, z.B. um die auf dem Server vorhandenen Dateien zu generieren, dann könnte derjenige die ja mit hochladen. Oder mit in die README. Wenn ich mal so ein Skript schreiben sollte, kommt das ins Wiki.

    > Jedenfalls wäre die Abfrage der PLZ.tab für mich deutlich effizienter
    > als die der Datenbank. Zur Zeit brauche ich für eine Umkreissuche auf
    > Basis der GeoClass mit aktuellem Dump ca. 10 Sekunden, Das geht
    > natürlich nicht auf einer Homepage...

    Ich selbst verwende direkt diese PLZ.tab für
    <http://www.fa-technik.adfc.de/Codierung/anbieter>

Da hast Du zum Teil dasselbe Problem. Vergleich mal die Ausgabe für 10777 und 13355. Beide haben nach Berlin Mitte 0 km, aber die Angaben für alle anderen folgenden Orte unterscheiden sich. Beim Standard-Dump sind die Listen komplett gleich.

   Bei mir läuft das anders - ich berechne von der Mittelpunktskoordinate
   erst einmal die gewünschten Abweichung in lat/lon (also z.B. 45±1 / 9±1)
   und berechne die Entfernung dann nur für jene Einträge, die sowohl im
   Bereich lat=44..46 als auch lon=8..10 erfüllen. Alle anderen sind schon
   zuvor ausgeschieden.

Ja, genau das hatte ich auch gemeint.

Wie ist das in unseren Breiten, wieviel km hat hier 1° long. bzw. lat.?
Und wie stark ist die maximale Abweichung von diesem Wert für Orte am Rand?
Hast Du ggfs. nen guten Link wo man das nachlesen / ausrechnen kann?

Noch eine andere Frage, wieso wird bei so vielen Programmen der Radius des Äquators auf eine Ganzzahl gerundet? Performance oder ist das irgendein Standard? Wie machst Du das?

Jedenfalls schonmal vielen Dank für die Hilfe!


Grüße
Andreas
_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

akorthaus@... wrote:

>> Denn wenn ich da eine PLZ angebe und die Entfernung zu Städten in
>> der Umgebung errechnen, ändern sich die Werte bei benachbarten PLZs
>> in einer Stadt.
>
> Beispiel?
>
> z.B. Aachen: PLZ 52062 und 52078 Beide haben loc_id: 13352
>
> Aber bei 52062 ist das erste Ergebnis (Aachen) 0,3 km entfernt, bei
> 52078 ist es ebenfalls Aachen, aber>  1km entfernt. Entsprechend
> haben auch die folgenden Städte andere Distanzen.

Solange du nicht die entsprechenden Koordinaten mit ausgeben lässt,
erscheint mir dein Ergebnis nicht nachvollziehbar. Beachte aber, dass es
zu Aachen mehr als einen Eintrag gibt:
http://fa-technik.adfc.de/code/opengeodb.pl?parts=13352;c=DE


> Was mich daran aber wundert ist die Tatsache, dass 2 PLZs, die die
> gleiche loc_id haben, anscheinend andere Koordinaten haben.

Das geht eigentlich nicht.

>> Ist irgendwo erklärt, was die folgende Dateien auf dem Server
>> enthalten? DE.sql DE.tab DE9.tab PLZ.tab
>
> Nein, da muss jemand mal ein README schreiben.
>
> Vermutlich habt Ihr das schon häufiger erklärt, könnt Ich nicht
> einfach 2-3 Postings aus dieser Liste  in die README eintragen oder
> von irgendwo verlinken, oder einfach  einen Abschnitt wie den
> Folgenden in in die README eintragen? Alles ist besser als gar keine
> Infos. Muss ja keine perfekte Umschreibung sein...

Wenn ich mal nichts wichtigeres zu tun habe, werde ich es machen.
opengeodb muss aber keineswegs eine einer-macht-alles-show sein.


> OK, geodb_type_names  sagt mir, dass es 500300000 gibt (Postleitzahl)
> und 100800000 (Postleitzahlgebiet). Was genau ist der Unterschied,
> vor allem für eine Umkreissuche in der Praxis?

Die PLZ ist die PLZ eines opengeodb-Eintrags.

Die 100800000 ist ein PLZ-Gebiet, mit einem repräsentativem
Namenseintrag und Koordinaten zu eben jenem PLZ-Gebiet.

> Sind beide Listen vollständig?

Nein - nur zu 99,99 %.

> Ich selbst verwende direkt diese PLZ.tab für
> <http://www.fa-technik.adfc.de/Codierung/anbieter>
>
> Da hast Du zum Teil dasselbe Problem. Vergleich mal die Ausgabe für
> 10777 und 13355. Beide haben nach Berlin Mitte 0 km, aber die Angaben
> für alle anderen folgenden Orte unterscheiden sich. Beim
> Standard-Dump sind die Listen komplett gleich.

Das kommt daher, dass der ADFC-Kreisverband Mitte für alle Berliner
gleich zuständig ist.

Deswegen MUSS bei passender PLZ die Entfernung auf Null gesetzt werden,
selbst bei unterschiedlichen Koordinaten von Anbieter und PLZ-Gebiet.


> Ja, genau das hatte ich auch gemeint.
>
> Wie ist das in unseren Breiten, wieviel km hat hier 1° long. bzw.
> lat.?

Stelle die Formeln entsprechend um und rechne es aus. Je nach
Breitengrad kommt was anderes heraus - und eine Bogensekunde auf dem
Äquator misst genau eine Seemeile.


> Noch eine andere Frage, wieso wird bei so vielen Programmen der
> Radius des Äquators auf eine Ganzzahl gerundet? Performance oder ist
> das irgendein Standard? Wie machst Du das?

Die Erde ist keine perfekte Kugel - da müsstest du schon genauer die
Abplattung mit einberechnen, bevor dich Nachkommastellen interessieren
müssten.


Lies z.B. mal http://opengeodb.hoppe-media.com/index.php?FAQEntfernung

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

akorthaus@... wrote:

> Wenn ich das hier richtig gelesen habe, wird die Datenbank um
> Straßennamen und Ortsteile erweitert. Ist hierbei zu erwarten, dass
> die PLZ-Suche z.B. für Berlin genauere Distanzen im Stadtgebiet
> hinbekommt?

Kommentar dazu am Rande: die aktuellen opengeodb-Einträge für Berlin
sind eher dürftig. Ich selbst habe hier 457 Einträge für Berlin, wie z.B.

11 Berlin Bundesland
110 Berlin NUTS
11000 Berlin kreisfreie Stadt
11000000 Berlin (Gemeindeebene)
1100000001 Mitte Stadtbezirk
110000000101 Mitte Stadtteil
110000000102 Moabit Stadtteil
...
1100000002 Friedrichshain-Kreuzberg Stadtbezirk
110000000201 Friedrichshain Stadtteil
1100000002011 Stralau Ortslage

Alleine 268 davon sind schon Kleingartenanlagen.

In der opengeodb veröffentlicht habe ich nur jene Einträge, für die ich
Koordinaten hatte. Sollte ich den Rest hinzufügen, alle mit der
Koordinate Mitte? Ganz ohne Koordinaten?

Schönen Gruß
Martin
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Andreas Korthaus]

Am 12.02.08 schrieb Martin Trautmann <traut@...>:

> Solange du nicht die entsprechenden Koordinaten mit ausgeben lässt,
> erscheint mir dein Ergebnis nicht nachvollziehbar. Beachte aber, dass es
> zu Aachen mehr als einen Eintrag gibt:
> http://fa-technik.adfc.de/code/opengeodb.pl?parts=13352;c=DE

OK, es gibt tatsächliche mehrere Einträge für die PLZs. Beispiel folgende Abfrage für PLZ 52078:

SELECT * FROM geodb_textdata WHERE text_val=52078

da gibt es bei gleichem text_typ (500300000) 3 verschiedene loc_id Einträge:

13352 - das ist der Standardeintrag von Aachen, dem alle PLZs von Aachen zugeordnet sind
113425 - der fast die identischen Einträge enthält
113426 - hier sind nur 2 PLZ- Einträge eines bestimmte Stadtteils enthalten.

Woher weiß ich jetzt, wenn ich das automatisiert abfrage, welche loc_id die korrekte (also die exakteste) ist?

> Die PLZ ist die PLZ eines opengeodb-Eintrags.

Also ist es gar nicht so schlau in der geodb_textdata Tabelle nach so einer PLZ zu suchen, weil wie ich ja oben gesehen habe, mehrere opengeodb Einträge dieselbe PLZ haben können, und da weiß ich halt nicht, wie ich den exaktesten auswähle.

> Die 100800000 ist ein PLZ-Gebiet, mit einem repräsentativem
> Namenseintrag und Koordinaten zu eben jenem PLZ-Gebiet.

Die sind im normalen Dump aber nicht enthalten sondern nur in der PLZ.tab, oder?

> > Noch eine andere Frage, wieso wird bei so vielen Programmen der
> > Radius des Äquators auf eine Ganzzahl gerundet? Performance oder ist
> > das irgendein Standard? Wie machst Du das?
>
> Die Erde ist keine perfekte Kugel - da müsstest du schon genauer die
> Abplattung mit einberechnen, bevor dich Nachkommastellen interessieren
> müssten.

Ja, aber die Kugel ist doch ein, wenn auch nicht ganz realitätsgetreues, vereinfachendes Modell. Daher macht es in meinen Augen durchaus Sinn in diesem Modell möglichst exakte Eckdaten zu verwenden um nicht neben der "Unvollkommenheit der Erdkugel" noch weitere Verfälschungen mit einzurechnen. Aber gut, auf die kurzen Entfernungen wird man den Unterschied sicher sowieso nicht bemerken...

_________________________________________________________________________
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten!
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

akorthaus@... wrote:

> Woher weiß ich jetzt, wenn ich das automatisiert abfrage, welche
> loc_id die korrekte (also die exakteste) ist?

Überhaupt nicht - weil du die Koordinaten eines Ortes bekommst und nicht
die einer PLZ
>
>> Die PLZ ist die PLZ eines opengeodb-Eintrags.
>
> Also ist es gar nicht so schlau in der geodb_textdata Tabelle nach so
> einer PLZ zu suchen, weil wie ich ja oben gesehen habe, mehrere
> opengeodb Einträge dieselbe PLZ haben können, und da weiß ich halt
> nicht, wie ich den exaktesten auswähle.

Wenn du es aber trotzdem machen willst, dann verwende den Eintrag mit
der tiefsten Ebene, weil das je feiner desto genauer wird.

>> Die 100800000 ist ein PLZ-Gebiet, mit einem repräsentativem
>> Namenseintrag und Koordinaten zu eben jenem PLZ-Gebiet.
>
> Die sind im normalen Dump aber nicht enthalten sondern nur in der
> PLZ.tab, oder?

Kann sein, dass einige PLZ-Gebiete im Dump enthalten sind, weil sie mit
einem Startdatum versioniert wurden, im Unterschied zu allen anderen
PLZ-Einträgen, die seit Umstellung auf fünf Stellen neu sind.

>>> Noch eine andere Frage, wieso wird bei so vielen Programmen der
>>> Radius des Äquators auf eine Ganzzahl gerundet? Performance oder
>>> ist das irgendein Standard? Wie machst Du das?
>> Die Erde ist keine perfekte Kugel - da müsstest du schon genauer
>> die Abplattung mit einberechnen, bevor dich Nachkommastellen
>> interessieren müssten.
>
> Ja, aber die Kugel ist doch ein, wenn auch nicht ganz
> realitätsgetreues, vereinfachendes Modell. Daher macht es in meinen
> Augen durchaus Sinn in diesem Modell möglichst exakte Eckdaten zu
> verwenden um nicht neben der "Unvollkommenheit der Erdkugel" noch
> weitere Verfälschungen mit einzurechnen. Aber gut, auf die kurzen
> Entfernungen wird man den Unterschied sicher sowieso nicht
> bemerken...

Eben - die Kugel ist vereinfachend. Warum solltest du mit einem
genauereren Erdradius versuchen, die Genauigkeit von 99,9 auf 99,99 % zu
erhöhen, wenn ein anderer Fehler die Genauigkeit schon auf 98 %
reduziert. Die Angaben als Luftlinie sind ohnehin rein akademischer
Natur: Ein Flieger würde einige hundert Meter höher fliegen und
entsprechend weitere Wege zurücklegen. Ausserdem dürften die wenigsten
auf der Luftlinie unterwegs sein können.

Warum also akademisch eine Genauigkeit vorgeben, von der jeder
Akademiker dir erläutern kann, dass du dir nur was in die Tasche lügst.
Nimm's als brauchbares prinzipielles Vergleichsmerkmal und nicht als
absolute Wahrheit - und experimentiere mit den Werten herum, was du
letzendlich mit einer anderen Genauigkeit gewinnen würdest.

Schönen Gruß
Martin
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Peter Wendorff]

Martin Trautmann schrieb:
> Kommentar dazu am Rande: die aktuellen opengeodb-Einträge für Berlin
> sind eher dürftig. Ich selbst habe hier 457 Einträge für Berlin, (..)
>
> In der opengeodb veröffentlicht habe ich nur jene Einträge, für die ich
> Koordinaten hatte. Sollte ich den Rest hinzufügen, alle mit der
> Koordinate Mitte? Ganz ohne Koordinaten?
>  
Ich würde sie ohne Koordinaten einfügen, dann kann man sich als
Programmierer überlegen, ob man die Koordinaten des nächsten Eintrags
mit Koordinaten in der Hierarchie aufwärts benutzt.
Das wäre dann also z.B. die Koordinate der kreisfreien Stadt Berlin.
Vorteil: Man kann direkt daraus erkennen, dass die Genauigkeit der
koordinate eben erst die der Stadtebene ist, während sonst der
Trugschluss aufkäme, die Stadtteile lägen alle quasi übereinander (was
übrigens, merke ich grade, bei 'ner ringförmigen Stadt sowieso bei
Flächen-MIttelpunkten möglich wäre).
Wer die Koordinaten gerne auch direkt bei den Einträgen hätte, könnte
dies auch über ein recht simples Script erledigen

Gruß
Peter Wendorff
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Ralf Weber]

Hi akorthaus@...,

 > Zur Zeit brauche ich für eine Umkreissuche auf Basis der GeoClass mit
aktuellem Dump ca. 10 Sekunden, Das geht natürlich nicht auf einer
Homepage...

10 Sekunden?

Ich habe jetzt das Gespräch nicht weiter mitbekommen und evtl.ist auch
mein Datenbestand ein älterer - aber ich habe vor längerem eine
heuristische Standortermittlung programmiert bei der am Ende auch über
eine Umkreissuche die umliegenden Orte des ermittelten Punktes gesucht
werden. Diese gesamte Berechnung dauert weniger als 10 Sekunden bei mir.

zu sehen unter:

http://www.wonderer.de/Geo/locateIt.php

Grüße aus Sachsen, Ralf...
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Ralf Weber]

akorthaus@... schrieb:

>     > Denn wenn ich da eine PLZ angebe und die Entfernung zu
>     > Städten in der Umgebung errechnen, ändern sich die Werte bei
>     > benachbarten PLZs in einer Stadt.
>
>     Beispiel?
>
> z.B. Aachen: PLZ 52062 und 52078
> Beide haben loc_id: 13352
>
> Aber bei 52062 ist das erste Ergebnis (Aachen) 0,3 km entfernt, bei 52078 ist es ebenfalls Aachen, aber > 1km entfernt. Entsprechend haben auch die folgenden Städte andere Distanzen.
>
> Allerdings weiß ich nicht ob das vorher anders war, das hatte ich nicht getestet. Da aber deutlich mehr Koordinaten-Daten in der neuen Version enthalten sind, war ich davon ausgegangen, dass sich hier was geändert hat.
>
> Was mich daran aber wundert ist die Tatsache, dass 2 PLZs, die die gleiche loc_id haben, anscheinend andere Koordinaten haben. Ich hatte das eigentlich so verstanden, dass in der Koordinaten-Tabelle die loc_id referenziert ist. Aber irgendwie muss es ja noch einen zweiten Schlüssel geben, sonst müssten die Koordinaten gleich sein. Was wäre dieser Schlüssel?
>
> Bei Berlin gab es keine Änderung da haben die PLZs die ich getestet hatte alle dieselben Koordinaten (ausgerechnet bei Berlin ;-).
>
>
>     > Ist irgendwo erklärt, was die folgende Dateien auf dem Server
>     > enthalten? DE.sql DE.tab DE9.tab PLZ.tab
>
>     Nein, da muss jemand mal ein README schreiben.
>
> Vermutlich habt Ihr das schon häufiger erklärt, könnt Ich nicht einfach 2-3 Postings aus dieser Liste  in die README eintragen oder von irgendwo verlinken, oder einfach  einen Abschnitt wie den Folgenden in in die README eintragen? Alles ist besser als gar keine Infos. Muss ja keine perfekte Umschreibung sein...
>
>     DE.tab - die Basisdaten für Deutschland
>     DE.sql - die Basisdaten konvertiert nach SQL
>     DE9.tab - erste Anfänge eines Straßenverzeichnisses für opengeodb,
>     exemplarisch Baden-Württemberg. Inzwischen liegen auch Niedersachsen und
>     Bayern vor. Diese Daten unterliegen der OSM-Lizenzierung (CC-BY-SA)!
>
>
>     > Sind z.B. in PLZ.tab alle PLZs inkl. Angaben zu Koordianten und Ort
>     > drin, die auch im kompletten Dump stehen?
>
>     Nein, PLZ.tab enthält die Daten von Postleitzahlgebieten, typ 100800000
>
> OK, geodb_type_names  sagt mir, dass es 500300000 gibt (Postleitzahl) und 100800000 (Postleitzahlgebiet). Was genau ist der Unterschied, vor allem für eine Umkreissuche in der Praxis?
>
> Sind beide Listen vollständig?
>
>
>     > Kann man auf dem Server vielleicht auch die Skripte speichern, mit
>     > denen die Listen aus der Datenbank extrahiert wurden? Wäre sicher
>     > hilfreich als Vorlage oder für den Fall, dass die Dateien irgendwann
>     > nicht mehr gepflegt werden...  (Mich würde z.B. interessieren, wie
>     > man nicht-Deutschland Einträge komplett rausbekommt, prinzipiell kann
>     > ich mir da vorstellen wie das geht, ist aber alles so verstreut
>     > gespeichert...)
>
>     Die kannst du am besten im wiki selbst veröffentlichen:
>     http://opengeodb.giswiki.org/wiki/OpenGeoDB
>
> Ich hab die Skripte ja nicht. Ich dachte mir nur, dass jemand irgendwelche kleinen Skripte für solche Zwecke geschrieben hat, z.B. um die auf dem Server vorhandenen Dateien zu generieren, dann könnte derjenige die ja mit hochladen. Oder mit in die README. Wenn ich mal so ein Skript schreiben sollte, kommt das ins Wiki.
>
>     > Jedenfalls wäre die Abfrage der PLZ.tab für mich deutlich effizienter
>     > als die der Datenbank. Zur Zeit brauche ich für eine Umkreissuche auf
>     > Basis der GeoClass mit aktuellem Dump ca. 10 Sekunden, Das geht
>     > natürlich nicht auf einer Homepage...
>
>     Ich selbst verwende direkt diese PLZ.tab für
>     <http://www.fa-technik.adfc.de/Codierung/anbieter>
>
> Da hast Du zum Teil dasselbe Problem. Vergleich mal die Ausgabe für 10777 und 13355. Beide haben nach Berlin Mitte 0 km, aber die Angaben für alle anderen folgenden Orte unterscheiden sich. Beim Standard-Dump sind die Listen komplett gleich.
>
>    Bei mir läuft das anders - ich berechne von der Mittelpunktskoordinate
>    erst einmal die gewünschten Abweichung in lat/lon (also z.B. 45±1 / 9±1)
>    und berechne die Entfernung dann nur für jene Einträge, die sowohl im
>    Bereich lat=44..46 als auch lon=8..10 erfüllen. Alle anderen sind schon
>    zuvor ausgeschieden.
>
> Ja, genau das hatte ich auch gemeint.
>
> Wie ist das in unseren Breiten, wieviel km hat hier 1° long. bzw. lat.?
> Und wie stark ist die maximale Abweichung von diesem Wert für Orte am Rand?
> Hast Du ggfs. nen guten Link wo man das nachlesen / ausrechnen kann?
>
> Noch eine andere Frage, wieso wird bei so vielen Programmen der Radius des Äquators auf eine Ganzzahl gerundet? Performance oder ist das irgendein Standard? Wie machst Du das?
>
> Jedenfalls schonmal vielen Dank für die Hilfe!
>
>
> Grüße
> Andreas
> _______________________________________________________________________
> Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
> kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220
>

--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)