From danny.sotzny at gmx.de  Wed Jul  4 22:57:29 2007
From: danny.sotzny at gmx.de (Danny Sotzny)
Date: Wed, 4 Jul 2007 22:57:29 +0200
Subject: [opengeodb] Geocoding andersherum
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAFg3UUjvvHBKh3/GZ9TJorQihQAAEAAAAMHaSoOZOThPnUrQBnpNRF4BAAAAAA==@gmx.de>

Hallo

Ich suche momentan genau das gegenteil :) Ich habe GeoDaten und möchte dazu
die nächst gelegene Straße / Ort wissen.
Hintergrund ist der das ein Kumpel von mir Bilder mit GeoDaten hat (GPX bzw.
NMEA) und dazu wäre es sehr sinnvoll die nächst gelegene Straße autom.
wissen zu können.

Ich sage mal so profan "Das kann ja jedes Navi" - Aber gibt es sowas frei
bzw. für ein geringes Entgeld ?!

Hat da jemand ne Idee oder einen Link ?


Mit freundlichen Grüßen 
 Danny Sotzny


From robert.boeck at googlemail.com  Thu Jul  5 10:59:04 2007
From: robert.boeck at googlemail.com (=?ISO-8859-1?Q?Robert_B=F6ck?=)
Date: Thu, 05 Jul 2007 10:59:04 +0200
Subject: [opengeodb] Geocoding andersherum
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAFg3UUjvvHBKh3/GZ9TJorQihQAAEAAAAMHaSoOZOThPnUrQBnpNRF4BAAAAAA==@gmx.de>
References: <!&!AAAAAAAAAAAYAAAAAAAAAFg3UUjvvHBKh3/GZ9TJorQihQAAEAAAAMHaSoOZOThPnUrQBnpNRF4BAAAAAA==@gmx.de>
Message-ID: <f6ibso$bdk$1@sea.gmane.org>

Danny Sotzny wrote:

> Ich suche momentan genau das gegenteil :) Ich habe GeoDaten und möchte dazu
> die nächst gelegene Straße / Ort wissen.

Das müsste mit der OpenGeoDB doch gehen. Mache eine Umkreissuche um
deine Geokoordinaten und lasse das Ergebnis nach Distanz sortieren ...

cu, Robo :)


From traut at gmx.de  Thu Jul  5 16:42:39 2007
From: traut at gmx.de (Martin Trautmann)
Date: Thu, 5 Jul 2007 16:42:39 +0200
Subject: [opengeodb] Geocoding andersherum
In-Reply-To: <f6ibso$bdk$1@sea.gmane.org>
References: <!&!AAAAAAAAAAAYAAAAAAAAAFg3UUjvvHBKh3/GZ9TJorQihQAAEAAAAMHaSoOZOThPnUrQBnpNRF4BAAAAAA==@gmx.de>
	<f6ibso$bdk$1@sea.gmane.org>
Message-ID: <0D47FE08-E02A-4655-9D9A-94EC685C11B8@gmx.de>


On 5. Jul 2007, at 10:59, Robert Böck wrote:

> Danny Sotzny wrote:
>
>> Ich suche momentan genau das gegenteil :) Ich habe GeoDaten und  
>> möchte dazu
>> die nächst gelegene Straße / Ort wissen.
>
> Das müsste mit der OpenGeoDB doch gehen. Mache eine Umkreissuche um
> deine Geokoordinaten und lasse das Ergebnis nach Distanz sortieren ...

Das könnte auch online eingebaut werden, falls daran Interesse besteht.


From wolfgang.uhr at devsup.de  Tue Jul 10 08:22:10 2007
From: wolfgang.uhr at devsup.de (Wolfgang Uhr)
Date: Tue, 10 Jul 2007 08:22:10 +0200
Subject: [opengeodb] Wiki: Eigentor Google
In-Reply-To: <20070625131756.75780@gmx.net>
References: <20070625131756.75780@gmx.net>
Message-ID: <46932592.2080508@devsup.de>

Hallo

Bei der Gelegenheit denke mal nach über die Zeilen

<meta name="robots" content="index,follow">
<meta name="revisit-after" content="14 days">

und was du damit sagst.

Die zweite Zeile kannst du vergessen, die bringt gar nichts.

Mein erster Ansatz wäre eine Änderung:
<meta name="robots" content="noindex,nofollow">

Herzliche Grüße
Wolfgang Uhr


Martin Trautmann schrieb:
> Hallo,
> 
> leider habe ich den Wiki-Ansatz wohl zu einfach gestrickt: Fehleintraege und Loeschung koennen durch einen einfachen URL ausgeloest werden.
> 
> Seit Google http://fa-technik.adfc.de/Codierung/opengeodb.pl fand, wurden einige Aenderungen dort durch den googlebot wieder rueckgaengig gemacht.
> 
> Wie soll ich das verhindern?
> 
> Auf die Schnelle kann ich durch den passenden robots-Eintrag Google wieder bitten, draussen zu bleiben. Aber schon die naechste Suchmaschine kann das wieder ausloesen.
> 
> - Bilderratespielchen: Soll ich ein Captcha einbauen, wo die Ziffern und Buchstaben aus einer verhunzten Grafik ausgelesen oder Rechenspielchen "2+2=" geloest werden muessen?
> 
> - Login: duerfen nur angemeldete Besucher die Inhalte aendern?
> 
> - Angabe einer E-Mail-Adresse: duerfen nur Besucher bei Angabe einer E-Mail-Adresse die Inhalte aendern? Soll diese sogar ueber E-Mail-Bestaetigung und Web-URL in dieser Mail Eingang finden?
> 
> Im Moment tendiere ich zum Login: Anlegen darf jeder, aendern vielleicht auch. Zuruecksetzen und Loeschen duerfen nur angemeldete Besucher.
> 
> Schoenen Gruss
> Martin


From cwaldeck at iverse.org  Wed Jul 11 08:56:53 2007
From: cwaldeck at iverse.org (Carsten Waldeck)
Date: Wed, 11 Jul 2007 08:56:53 +0200
Subject: [opengeodb] PLZ - geodaten - mappingtabelle fuer schweiz und
	oesterreich
Message-ID: <6897B81D-C382-446B-8F73-DC88BE2F51E8@iverse.org>


hallo zusammen,

ich bin neu hier auf dieser liste. darf ich mich vorstellen?
carsten waldeck aus darmstadt, interfacedesigner und
GEO fan.

wollte gerade eine anwendung bauen, die auch schweiz
und A integriert und hatte den tollen datensatz:
"opengeodb-0.2.4d-UTF8-text-plz.txt"
bei euch gefunden.

im header sind da auch unter:
"Abkürzungen Bundesländer / Kantone"
schweiz und oesterreich mit aufgefuehrt, aber
dann kommen nur die deutschen bundeslaender.

gibt es diese daten auch fuer schweiz und oesterreich?
tut mir leid, wenn das vielleicht eine sehr banale frage
ist...ich hatte auch im archiv schon ein bisschen
gestoebert, bin aber nicht so richtig fuerndig geworden.

uebrigens: eine suchfunktion fuer das archiv waere toll!!

super, dass es euch gibt und danke fuer all den
wert, den ihr erzeugt und zur verfuegung stellt!
ich bin begeistert!


herzliche gruesse aus darmstadt,


carsten





From traut at gmx.de  Wed Jul 11 09:05:04 2007
From: traut at gmx.de (Martin Trautmann)
Date: Wed, 11 Jul 2007 09:05:04 +0200
Subject: [opengeodb] PLZ - geodaten - mappingtabelle fuer schweiz und
	oesterreich
In-Reply-To: <6897B81D-C382-446B-8F73-DC88BE2F51E8@iverse.org>
References: <6897B81D-C382-446B-8F73-DC88BE2F51E8@iverse.org>
Message-ID: <10FBFA55-20AF-4298-840D-610EA34233D6@gmx.de>


On 11. Jul 2007, at 8:56, Carsten Waldeck wrote:
>
> gibt es diese daten auch fuer schweiz und oesterreich?
> tut mir leid, wenn das vielleicht eine sehr banale frage
> ist...ich hatte auch im archiv schon ein bisschen
> gestoebert, bin aber nicht so richtig fuerndig geworden.

Hallo Carsten,

du hast im Archiv keinen Hinweis auf http://fa-technik.adfc.de/ 
Codierung/opengeodb.pl gefunden?

Es ist richtig, dass es noch keine explizite plz-Datei fuer Schweiz  
und Oesterreich existiert, wie sie fuer D bereitsteht. Die Daten  
stecken aber ebenso in der normalen CH.tab und A.tab drin - du musst  
sie nur herausfiltern.

> uebrigens: eine suchfunktion fuer das archiv waere toll!!

Welches Archiv? Die Mailingliste?

> herzliche gruesse aus darmstadt,

Schönen Gruß von einem Ex-Darmstädter,
Martin


From iloetzsch at asci-systemhaus.de  Thu Jul 19 12:16:26 2007
From: iloetzsch at asci-systemhaus.de (=?ISO-8859-1?Q?Ingmar_L=F6tzsch?=)
Date: Thu, 19 Jul 2007 12:16:26 +0200
Subject: [opengeodb] Geo Daten von Deutschland
In-Reply-To: <ea63748a0706240408t27d3660ag9dfc4aa2f15df07b@mail.gmail.com>
References: <ea63748a0706240346y7ded1b8lfcd7542c8f53654c@mail.gmail.com>	<5C4CFDDC-DC9B-4748-AB26-DFB73F8BC2FD@gmx.de>
	<ea63748a0706240408t27d3660ag9dfc4aa2f15df07b@mail.gmail.com>
Message-ID: <469F39FA.5040408@asci-systemhaus.de>

>> Im Moment parken die auf http://fa-technik.adfc.de/Codierung/
>> opengeodb.pl

Hallo,

ich habe unter der angegebenen Adresse die gezippte Datei
opengeodb-0250_2007-05-22.sql runtergeladen und versucht, die Daten in
meine PostgreSQL-Datenbank zu importieren, nach Anpassung der
abweichenden DDL selbstverständlich. Dabei bin ich auf folgende Probleme
gestoßen:

1. Die Tabelle geodb_textdata hat einen CHECK-CONSTRAINT

    check (
      (
        (
          (text_type = 500100000 or text_type = 500100004 or
           text_type = 500100002 or text_type = 500700000 or
           text_type = 500700001 or text_type = 500800000 or
           text_type = 500800000 or text_type = 500900000
          ) and
          text_locale like '__%' and
          is_native_lang is not null and
          is_default_name is not null
        ) or
        (
          (text_type = 500100001 or text_type = 500100003 or
           text_type = 500300000 or text_type = 500500000 or
           text_type = 500600000
          ) and
          text_locale is null and
          is_native_lang is null and
          is_default_name is null
        )
      ) and
        (
          (valid_since is null and date_type_since is null) or
          (valid_since is not null and date_type_since is not null)
        )
    )

Das bedeutete u. a., dass in der Spalte text_type, der 2. Spalte der
Tabelle wohlgemerkt, nur die aufgeführten Werte 500100000, 500100004,
... erlaubt sind. Das zweite INSERT-Statement in Zeile 212 lautet jedoch

INSERT INTO geodb_textdata
VALUES(106,400200000,'2',null,null,null,null,null,'3000-01-01',300500000);

will also 400200000 in die Spalte 2 schreiben, was wegen des CHECK
fehlschlägt. Dieses Problem betrifft sehr viele Zeilen.

2. Laut DDL sind die Primärschlüssel integer, bei den Daten gibt es aber
viele Statements mit größeren Werten, z. B. in Zeile 224.

3. Laut DDL hat die Tabelle geodb_intdata 7 Spalten. Es gibt aber
Statements mit 8 Werten (vermutlich bei allen mit dieser Tabelle), z. B.
in Zeile 232.

Wie kommt es zu diesen Fehlern und was empfehlen die Insider als Workaround?

Vielen Dank, Ingmar


From Martin.Trautmann at Micronas.com  Thu Jul 19 12:59:12 2007
From: Martin.Trautmann at Micronas.com (Trautmann Martin)
Date: Thu, 19 Jul 2007 12:59:12 +0200
Subject: [opengeodb] Geo Daten von Deutschland
In-Reply-To: <469F39FA.5040408@asci-systemhaus.de>
Message-ID: <270C99F9FA07234AB7B0AD4236393A49113905@EXCHANGE3.Micronas.com>

> >> Im Moment parken die auf http://fa-technik.adfc.de/Codierung/
> >> opengeodb.pl
> 
> Hallo,
> 
> ich habe unter der angegebenen Adresse die gezippte Datei
> opengeodb-0250_2007-05-22.sql Dabei bin ich auf folgende Probleme
> gestoßen:
> 
> 1. Die Tabelle geodb_textdata hat einen CHECK-CONSTRAINT
> 
>     check (
>       (
>         (
>           (text_type = 500100000 or text_type = 500100004 or
>            text_type = 500100002 or text_type = 500700000 or
>            text_type = 500700001 or text_type = 500800000 or
>            text_type = 500800000 or text_type = 500900000
>           ) and
>           text_locale like '__%' and
>           is_native_lang is not null and
>           is_default_name is not null
>         ) or
>         (
>           (text_type = 500100001 or text_type = 500100003 or
>            text_type = 500300000 or text_type = 500500000 or
>            text_type = 500600000
>           ) and
>           text_locale is null and
>           is_native_lang is null and
>           is_default_name is null
>         )
>       ) and
>         (
>           (valid_since is null and date_type_since is null) or
>           (valid_since is not null and date_type_since is not null)
>         )
>     )
> 
> Das bedeutete u. a., dass in der Spalte text_type, der 2. Spalte der
> Tabelle wohlgemerkt, nur die aufgeführten Werte 500100000, 500100004,
> ... erlaubt sind. Das zweite INSERT-Statement in Zeile 212 lautet jedoch
> 
> INSERT INTO geodb_textdata
> VALUES(106,400200000,'2',null,null,null,null,null,'3000-01-01',300500000);
> 
> will also 400200000 in die Spalte 2 schreiben, was wegen des CHECK
> fehlschlägt. Dieses Problem betrifft sehr viele Zeilen.


Hallo Ingmar,

Besten Dank für diese Rückmeldung - auf so etwas hatte ich schon lange gehofft. Demzufolge muss natürlich die 400200000 dem obigen CHECK hinzugefügt werden.

> 2. Laut DDL sind die Primärschlüssel integer, bei den Daten gibt es aber
> viele Statements mit größeren Werten, z. B. in Zeile 224.
> 
> 3. Laut DDL hat die Tabelle geodb_intdata 7 Spalten. Es gibt aber
> Statements mit 8 Werten (vermutlich bei allen mit dieser Tabelle), z. B.
> in Zeile 232.

Autsch - fuer Oesterreich / Ausland habe ich hier ueberall 10stellige Ergaenzungen vorgenommen. Fuer deutsche Ortsteile verwende ich derzeit bis 12stellige Nummern (die sind noch nicht in der opengeodb). Fuer Strassen brauche ich derzeit 13stellige Nummern.

Gibt's sonstige Begrenzungen auf z.B. max. 15 Stellen? 16 Bits bieten 65 000 Eintraege, mit Vorzeichen nur die Haelfte. Das erscheint mir viel zu wenig fuer eine opengeodb.

Mit 64-bit-Integer waer's kein Problem. Mit 32-bit signed komme ich nur bis 2 000 000 000. Von daher sollte ich die id wohl entsprechend eindampfen?

Wie ist Integer in SQL ueberhaupt definiert?
 
> Wie kommt es zu diesen Fehlern und was empfehlen die Insider als
> Workaround?

Probleme melden, Vorschlaege unterbreiten, Fehler korrigieren (lassen) :-)

Schoenen Gruss
Martin


Micronas GmbH
Company Headquarters / Sitz der Gesellschaft: Freiburg i. Br. - Municipal Court of / Amtsgericht: Freiburg i. Br. HRB 428. VAT ID / USt-IdNr.: DE 811127087
Management / Geschäftsführung: Dr. Wolfgang Kalsbach, Chairman / Vorsitzender, Hans-Jürgen Désor, Klaus Heberle,
Nikolaus V. Kaeppeler, Wilfried Lowinski, Dirk Wieberneit, Wolfgang Kühn - Chairman of Supervisory Board / Vorsitzender des Aufsichtsrats: Heinrich W. Kreutzer



From marc-xx at freenet.de  Sat Jul 21 02:52:09 2007
From: marc-xx at freenet.de (Marc)
Date: Sat, 21 Jul 2007 02:52:09 +0200
Subject: [opengeodb] Daten fuer Dortmund
Message-ID: <000d01c7cb31$5ed630c0$0202a8c0@kira>

geogr. Länge (longitude):  7.400737
in Radiant:  0.12916722772417
in Grad Minute Sekunde:  E 7° 24' 3''

geogr. Breite (latitude):  51.530237
in Radiant:  0.89937229998301
in Grad Minute Sekunde:  N 51° 31' 49'' 

Dortmund, Nordrhein-Westfalen
Kennzeichen: DO
PLZ: 44369


From tobwen at gmx.de  Sat Jul 21 02:58:28 2007
From: tobwen at gmx.de (Tobias Wendorff)
Date: Sat, 21 Jul 2007 02:58:28 +0200
Subject: [opengeodb] Daten fuer Dortmund
References: <000d01c7cb31$5ed630c0$0202a8c0@kira>
Message-ID: <002401c7cb32$405e3e70$0300a8c0@workstation>

MMh, das sind aber eher die Koordinaten für die Stadtteile Hafen
oder Deusen. Okay, kann man ja anhand der PLZ erkennen.


Marc wrote:
> geogr. Länge (longitude):  7.400737
> in Radiant:  0.12916722772417
> in Grad Minute Sekunde:  E 7° 24' 3''
>
> geogr. Breite (latitude):  51.530237
> in Radiant:  0.89937229998301
> in Grad Minute Sekunde:  N 51° 31' 49''
>
> Dortmund, Nordrhein-Westfalen
> Kennzeichen: DO
> PLZ: 44369 


From iloetzsch at asci-systemhaus.de  Sun Jul 22 22:54:32 2007
From: iloetzsch at asci-systemhaus.de (=?ISO-8859-1?Q?Ingmar_L=F6tzsch?=)
Date: Sun, 22 Jul 2007 22:54:32 +0200
Subject: [opengeodb] Geo Daten von Deutschland
In-Reply-To: <270C99F9FA07234AB7B0AD4236393A49113905@EXCHANGE3.Micronas.com>
References: <270C99F9FA07234AB7B0AD4236393A49113905@EXCHANGE3.Micronas.com>
Message-ID: <46A3C408.3000003@asci-systemhaus.de>

Hallo,

wegen der Probleme habe ich erstmal die Version 0.24 verwendet.

> Autsch - fuer Oesterreich / Ausland habe ich hier ueberall 10stellige Ergaenzungen vorgenommen. Fuer deutsche Ortsteile verwende ich derzeit bis 12stellige Nummern (die sind noch nicht in der opengeodb). Fuer Strassen brauche ich derzeit 13stellige Nummern.

Bedeutet das, dass in eine neue Spalte 10- bis 13-stellige Werte kommen?
> 
> Gibt's sonstige Begrenzungen auf z.B. max. 15 Stellen? 16 Bits bieten 65 000 Eintraege, mit Vorzeichen nur die Haelfte. Das erscheint mir viel zu wenig fuer eine opengeodb.
> 
> Mit 64-bit-Integer waer's kein Problem. Mit 32-bit signed komme ich nur bis 2 000 000 000. Von daher sollte ich die id wohl entsprechend eindampfen?
> 
> Wie ist Integer in SQL ueberhaupt definiert?

Nach meinen Erfahrungen mit PostgreSQL bedeutet int (auch integer oder
int4) 32 Bit mit einem Wertebereich von -2^31 bis 2^31 - 1 und bigint
(auch int8) 64 Bit mit -2^63 bis 2^63 - 1. Letzeres reicht für 18 Stellen.

Gruß Ingmar


From traut at gmx.de  Sun Jul 22 23:22:44 2007
From: traut at gmx.de (Martin Trautmann)
Date: Sun, 22 Jul 2007 23:22:44 +0200
Subject: [opengeodb] Geo Daten von Deutschland
In-Reply-To: <46A3C408.3000003@asci-systemhaus.de>
References: <270C99F9FA07234AB7B0AD4236393A49113905@EXCHANGE3.Micronas.com>
	<46A3C408.3000003@asci-systemhaus.de>
Message-ID: <60B02090-2E0C-453C-9E94-38CEEE6F7748@gmx.de>


On 22. Jul 2007, at 22:54, Ingmar Lötzsch wrote:

> Hallo,
>
> wegen der Probleme habe ich erstmal die Version 0.24 verwendet.
>
>> Autsch - fuer Oesterreich / Ausland habe ich hier ueberall  
>> 10stellige Ergaenzungen vorgenommen. Fuer deutsche Ortsteile  
>> verwende ich derzeit bis 12stellige Nummern (die sind noch nicht  
>> in der opengeodb). Fuer Strassen brauche ich derzeit 13stellige  
>> Nummern.
>
> Bedeutet das, dass in eine neue Spalte 10- bis 13-stellige Werte  
> kommen?

Kommt darauf an, was die Leute wollen - ich bin da pragmatisch.
Schönen Gruß
Martin


From tobwen at gmx.de  Tue Jul 24 13:59:24 2007
From: tobwen at gmx.de (Tobias Wendorff)
Date: Tue, 24 Jul 2007 13:59:24 +0200
Subject: [opengeodb] PLZ 61381 wird nicht gefunden
References: <3FD09022-B2E1-4329-A6E2-6682256CBCE4@mz-mediadesign.de>
Message-ID: <001001c7cdea$1440f070$0300a8c0@workstation>

Markus Zellner Mediadesign wrote:
> http://opengeodb.hoppe-media.com/examples/location.php?id=16710&q=Friedrichsdorf

Was ist denn da mit der Ausgabe los?

Im Header steht "utf-8" als Charset und mein Firefox stellt sich
auch darauf ein.

Sämtliche Umlaute werden allerdings falsch dekodiert "Höhe" & Co.

Grüße
Tobias



From typo3_maillist at tamas.szalai.de  Fri Jul 27 17:16:04 2007
From: typo3_maillist at tamas.szalai.de (Tamas Szalai)
Date: Fri, 27 Jul 2007 17:16:04 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
Message-ID: <1185549364.24627.7.camel@localhost>

Hallo Liste,

ich hoffe das mir hier jemand helfen, bzw. einen Tipp geben kann, was in
meiner SQL-Abfrage falsch ist.

Erreichen möchte ich, dass ich die Liste der deutschen Bundesländer mit
dazugehöriger ID als Ergebnis bekomme. Ich habe mir die GeoDB in meine
lokale MySQL-Datenbank eingespielt und starte folgende Abfrage:

SELECT die_id.loc_id as "ID", der_text.text_val as "Bundesland"
FROM geodb_hierarchies die_id, geodb_textdata der_text 
WHERE die_id.level = '3' 
LIMIT 30

Leider kommen da irgendwie zuviele und vor allem falsche Werte. Beim
ersten Versuch (ohne Limit) hat es mir gleich auch meinen Rechner lahm
gelegt :D

Mit der Bitte um Ratschläge und/oder Tipps zur korrekten Abfrage
verbleibe ich


mit freundlichen Grüßen

Tamas Szalai


From georg at familieverweyen.de  Fri Jul 27 19:31:38 2007
From: georg at familieverweyen.de (Georg Verweyen)
Date: Fri, 27 Jul 2007 19:31:38 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <1185549364.24627.7.camel@localhost>
References: <1185549364.24627.7.camel@localhost>
Message-ID: <46AA2BFA.3050608@familieverweyen.de>

Hallo Tamas,

ohne weitere Einschränkungen bekommst Du ein Kreuzprodukt zwischen allen 
Datensätzen von geodb_hierarchies und geodb_textdata, wobei Du nur die 
Einschränkung auf Level 3 gesetzt hast. Hier fehlt noch eine 
grundsätzliche Where-Bedingung zwischen den Tabellen. Dann fehlt noch 
die gewünschte Sprache und die Einschränkung für Deutschland.

MfG      Georg V.
Tamas Szalai schrieb:
> Hallo Liste,
>
> : gelöscht :
>
> Erreichen möchte ich, dass ich die Liste der deutschen Bundesländer mit
> dazugehöriger ID als Ergebnis bekomme. 
: gelöscht :
> SELECT die_id.loc_id as "ID", der_text.text_val as "Bundesland"
> FROM geodb_hierarchies die_id, geodb_textdata der_text 
> WHERE die_id.level = '3' 
> LIMIT 30
>   
: Rest gelöscht :



From typo3_maillist at tamas.szalai.de  Mon Jul 30 14:12:33 2007
From: typo3_maillist at tamas.szalai.de (Tamas Szalai)
Date: Mon, 30 Jul 2007 14:12:33 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <46AA2BFA.3050608@familieverweyen.de>
References: <1185549364.24627.7.camel@localhost>
	<46AA2BFA.3050608@familieverweyen.de>
Message-ID: <1185797553.9654.7.camel@localhost>

Am Freitag, den 27.07.2007, 19:31 +0200 schrieb Georg Verweyen: 
> Hallo Tamas,
> 
> ohne weitere Einschränkungen bekommst Du ein Kreuzprodukt zwischen allen 
> Datensätzen von geodb_hierarchies und geodb_textdata, wobei Du nur die 
> Einschränkung auf Level 3 gesetzt hast. Hier fehlt noch eine 
> grundsätzliche Where-Bedingung zwischen den Tabellen. Dann fehlt noch 
> die gewünschte Sprache und die Einschränkung für Deutschland.
> 
> MfG      Georg V.

Vielen Dank erstmal für Ihre Antwort ... Ich habe meine Abfrage neu
definiert:

SELECT 	g.loc_id AS "ID", 
	g.text_val AS "Bundesland"


FROM 	geodb_textdata g, 
	geodb_hierarchies gh, 
	geodb_textdata g1

WHERE 	gh.loc_id = g.loc_id
AND 	gh.id_lvl2 = g1.loc_id 
AND 	g1.text_val = 'Deutschland'
AND 	g1.text_type = 500100000
AND 	g.text_type = 500100000
AND 	gh.level = 3 

Ist das so in Ordnung? Das Ergebnis sind jedenfalls die 16 Bundesländer.

Mein nächstes Problem ist, die Landkreise zu einem einezelnen Bundesland
aus der datenbank zu ermitteln. Vorschläge? ;o)





From typo3_maillist at tamas.szalai.de  Mon Jul 30 16:34:40 2007
From: typo3_maillist at tamas.szalai.de (Tamas Szalai)
Date: Mon, 30 Jul 2007 16:34:40 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <1185797553.9654.7.camel@localhost>
References: <1185549364.24627.7.camel@localhost>
	<46AA2BFA.3050608@familieverweyen.de>
	<1185797553.9654.7.camel@localhost>
Message-ID: <1185806080.6088.8.camel@localhost>

Am Montag, den 30.07.2007, 14:12 +0200 schrieb Tamas Szalai:
> Mein nächstes Problem ist, die Landkreise zu einem einezelnen Bundesland
> aus der datenbank zu ermitteln. Vorschläge? ;o)

Ich muss mir mal ausnahmsweise selber antworten ... habe mir folgende
SQL-Query erdacht:

SELECT  g.loc_id AS "ID", 
        g.text_val AS "Landkreis"

FROM    geodb_textdata g, 
        geodb_hierarchies gh, 
        geodb_textdata g1

WHERE   gh.loc_id = g.loc_id
AND     gh.id_lvl3 = g1.loc_id
AND	g1.loc_id = 116
AND     g.text_type = 500100000
AND	g1.text_type = 500100000
AND	gh.level = 5

da kommen wohl bei einigen Bundesländern die Landkreise doppelt, bzw.
sind die insgesamt zuviel. Bei dem Beispiel hier werden Niedersachsen 97
Ergebnisse zugeordnet, obwohl eigtl. laut wikipedia nur max. 45 kommen
dürften.

Mache ich bei meinen Abfragen grundsätzlich etwas falsch?


TIA


From michael at md-d.org  Mon Jul 30 16:40:55 2007
From: michael at md-d.org (Michael Diederich)
Date: Mon, 30 Jul 2007 16:40:55 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <1185806080.6088.8.camel@localhost>
References: <1185549364.24627.7.camel@localhost>	<46AA2BFA.3050608@familieverweyen.de>	<1185797553.9654.7.camel@localhost>
	<1185806080.6088.8.camel@localhost>
Message-ID: <46ADF877.8070504@md-d.org>

Hallo,

Tamas Szalai schrieb:
> Am Montag, den 30.07.2007, 14:12 +0200 schrieb Tamas Szalai:
>> Mein nächstes Problem ist, die Landkreise zu einem einezelnen Bundesland
>> aus der datenbank zu ermitteln. Vorschläge? ;o)
> 
> Ich muss mir mal ausnahmsweise selber antworten ... habe mir folgende
> SQL-Query erdacht:
> 
> SELECT  g.loc_id AS "ID", 
>         g.text_val AS "Landkreis"
> 
> FROM    geodb_textdata g, 
>         geodb_hierarchies gh, 
>         geodb_textdata g1
> 
> WHERE   gh.loc_id = g.loc_id
> AND     gh.id_lvl3 = g1.loc_id
> AND	g1.loc_id = 116
> AND     g.text_type = 500100000
> AND	g1.text_type = 500100000
> AND	gh.level = 5
> 
> da kommen wohl bei einigen Bundesländern die Landkreise doppelt, bzw.
> sind die insgesamt zuviel. Bei dem Beispiel hier werden Niedersachsen 97
> Ergebnisse zugeordnet, obwohl eigtl. laut wikipedia nur max. 45 kommen
> dürften.
> 
> Mache ich bei meinen Abfragen grundsätzlich etwas falsch?

Ich kann das frühstens im Laufe der Woche ausprobieren, aber eventuell 
hilft dir ein

group by gh.loc_id

oder

group by g.loc_id

bereits.

HTH,

Michael


From typo3_maillist at tamas.szalai.de  Mon Jul 30 16:47:37 2007
From: typo3_maillist at tamas.szalai.de (Tamas Szalai)
Date: Mon, 30 Jul 2007 16:47:37 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <46ADF877.8070504@md-d.org>
References: <1185549364.24627.7.camel@localhost>
	<46AA2BFA.3050608@familieverweyen.de>	<1185797553.9654.7.camel@localhost>
	<1185806080.6088.8.camel@localhost>  <46ADF877.8070504@md-d.org>
Message-ID: <1185806857.6088.12.camel@localhost>

Am Montag, den 30.07.2007, 16:40 +0200 schrieb Michael Diederich:
> Hallo,

> Ich kann das frühstens im Laufe der Woche ausprobieren, aber eventuell 
> hilft dir ein
> 
> group by gh.loc_id
> 
> oder
> 
> group by g.loc_id
> 
> bereits.
> 
> HTH,
> 
> Michael
> 

aha ... nur noch 48 Ergebnisse - sehr gut. danke. :o)


From georg at familieverweyen.de  Mon Jul 30 19:26:23 2007
From: georg at familieverweyen.de (Georg Verweyen)
Date: Mon, 30 Jul 2007 19:26:23 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <1185806857.6088.12.camel@localhost>
References: <1185549364.24627.7.camel@localhost>	<46AA2BFA.3050608@familieverweyen.de>	<1185797553.9654.7.camel@localhost>	<1185806080.6088.8.camel@localhost>
	<46ADF877.8070504@md-d.org> <1185806857.6088.12.camel@localhost>
Message-ID: <46AE1F3F.7050402@familieverweyen.de>

Hallo Tamas,

mein Beispielsscript schreibt die richtige Anzahl raus, es sollte 
relativ einfach sein, sich das SQL-Statement zu testzwecken von PHP 
protokollieren zu lassen.

MfG        Georg V.

P.S.: http://www.familieverweyen.de/txt_0037.htm

Tamas Szalai schrieb:
> Am Montag, den 30.07.2007, 16:40 +0200 schrieb Michael Diederich:
>   
>> Hallo,
>> Ich kann das frühstens im Laufe der Woche ausprobieren, aber eventuell 
>> hilft dir ein
>>
>> group by gh.loc_id
>>
>> oder
>>
>> group by g.loc_id
>>
>> bereits.
>>
>> HTH,
>>
>> Michael
>>
>>     
>
> aha ... nur noch 48 Ergebnisse - sehr gut. danke. :o)
>
>   

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://lists.phpbar.de/pipermail/opengeodb/attachments/20070730/46261e24/attachment.html 

From typo3_maillist at tamas.szalai.de  Tue Jul 31 12:34:12 2007
From: typo3_maillist at tamas.szalai.de (Tamas Szalai)
Date: Tue, 31 Jul 2007 12:34:12 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <1185806857.6088.12.camel@localhost>
References: <1185549364.24627.7.camel@localhost>
	<46AA2BFA.3050608@familieverweyen.de>	<1185797553.9654.7.camel@localhost>
	<1185806080.6088.8.camel@localhost>  <46ADF877.8070504@md-d.org>
	<1185806857.6088.12.camel@localhost>
Message-ID: <1185878052.5872.13.camel@localhost>

Am Montag, den 30.07.2007, 16:47 +0200 schrieb Tamas Szalai:
> aha ... nur noch 48 Ergebnisse - sehr gut. danke. :o)
> 

Mein nächstes und wahrscheinlich auch letztes Problem ist folgende
Abfrage:

SELECT 	g.loc_id AS "ID", 
	g.text_val AS "Ort"

FROM	geodb_textdata g, 
	geodb_textdata g1, 
	geodb_hierarchies gh 

WHERE 	gh.loc_id = g.loc_id
AND	gh.id_lvl5 = g1.loc_id
AND	g1.loc_id = 524
AND	g.text_type = 500100000
AND	g1.text_type = 500100000
AND	gh.level = 6

GROUP BY g.loc_id
ORDER BY 2

Dies soll mir die Gemeinden/Orte aus einem Landkreis anzeigen. Als
Beispiel dient hier der Landkreis Sangerhausen. Die Orte werden
angezeigt und stimmen auch soweit überein, nur stören die Postleitzahlen
im Ergebnis. 
Wie kann ich diese entfernen? 
Warum werden die PLZ überhaupt mit angezeit, wo der text_type nur den
Namen anzeigen soll?


TIA


From mack at ifis.cs.tu-bs.de  Tue Jul 31 12:49:41 2007
From: mack at ifis.cs.tu-bs.de (Thomas Mack)
Date: Tue, 31 Jul 2007 12:49:41 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <1185878052.5872.13.camel@localhost>
References: <1185549364.24627.7.camel@localhost>
	<1185806857.6088.12.camel@localhost>
	<1185878052.5872.13.camel@localhost>
Message-ID: <200707311249.42533.mack@ifis.cs.tu-bs.de>

Am Dienstag, 31. Juli 2007 12:34 schrieb Tamas Szalai:
> Am Montag, den 30.07.2007, 16:47 +0200 schrieb Tamas Szalai:
> > aha ... nur noch 48 Ergebnisse - sehr gut. danke. :o)
>
> Mein nächstes und wahrscheinlich auch letztes Problem ist folgende
> Abfrage:
>
> SELECT 	g.loc_id AS "ID",
> 	g.text_val AS "Ort"
>
> FROM	geodb_textdata g,
> 	geodb_textdata g1,
> 	geodb_hierarchies gh
>
> WHERE 	gh.loc_id = g.loc_id
> AND	gh.id_lvl5 = g1.loc_id
> AND	g1.loc_id = 524
> AND	g.text_type = 500100000
> AND	g1.text_type = 500100000
> AND	gh.level = 6
>
> GROUP BY g.loc_id
> ORDER BY 2
>
> Dies soll mir die Gemeinden/Orte aus einem Landkreis anzeigen. Als
> Beispiel dient hier der Landkreis Sangerhausen. Die Orte werden
> angezeigt und stimmen auch soweit überein, nur stören die Postleitzahlen
> im Ergebnis.
> Wie kann ich diese entfernen?
> Warum werden die PLZ überhaupt mit angezeit, wo der text_type nur den
> Namen anzeigen soll?

Der Name eines Postleitzahlgebietes ist die Postleitzahl dieses Gebietes.

500100000 ist der Name eines Eintrags. Es gibt z.Zt. zwei verschiedene 
Eintragstypen: nämliche Orte (oder so ähnlich) als einen Typ, und 
Postleitzahlgebiete als weiterer Typ.

Diese beiden Typen werden in der geodb_locations unterschieden. Da Dich nur 
die Ortsnamen interessieren, machst Du noch einen weiteren Join über die die 
geodb_locations:

FROM ..., geodb_locations loc
WHERE ... AND loc.loc_type = .... AND loc.loc_id = g.loc_id

Außerdem solltest Du auch auf is_default_name überprüfen, sonst kann es 
geschehen, daß Du mehrere Ortsnamen für ein und denselben Ort (oder 
Bundesland oder Landkreis o.ä.) bekommst. Also so etwas wie:

... AND g.is_default_name = true AND g1.is_default_name = true


Thomas

From michael at md-d.org  Tue Jul 31 12:57:44 2007
From: michael at md-d.org (Michael Diederich)
Date: Tue, 31 Jul 2007 12:57:44 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <200707311249.42533.mack@ifis.cs.tu-bs.de>
References: <1185549364.24627.7.camel@localhost>	<1185806857.6088.12.camel@localhost>	<1185878052.5872.13.camel@localhost>
	<200707311249.42533.mack@ifis.cs.tu-bs.de>
Message-ID: <46AF15A8.7050709@md-d.org>

Thomas Mack schrieb:
..
> Der Name eines Postleitzahlgebietes ist die Postleitzahl dieses Gebietes.
..

Ist das ganze eigentlich dokumentiert oder wusstest du das jetzt einfach 
nur so? Ich hatte kurz gegoogelt, aber nichts gefunden und auf 
opengeodb.de habe ich einiges gefunden, aber nicht das im Detail. Findet 
man dort auch die Updates von Martin Trautmann?

Michael


From mack at ifis.cs.tu-bs.de  Tue Jul 31 13:02:24 2007
From: mack at ifis.cs.tu-bs.de (Thomas Mack)
Date: Tue, 31 Jul 2007 13:02:24 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <46AF15A8.7050709@md-d.org>
References: <1185549364.24627.7.camel@localhost>
	<200707311249.42533.mack@ifis.cs.tu-bs.de>
	<46AF15A8.7050709@md-d.org>
Message-ID: <200707311302.25302.mack@ifis.cs.tu-bs.de>

Am Dienstag, 31. Juli 2007 12:57 schrieb Michael Diederich:
> Thomas Mack schrieb:
> ..
>
> > Der Name eines Postleitzahlgebietes ist die Postleitzahl dieses Gebietes.
>
> ..
>
> Ist das ganze eigentlich dokumentiert oder wusstest du das jetzt einfach
> nur so? Ich hatte kurz gegoogelt, aber nichts gefunden und auf
> opengeodb.de habe ich einiges gefunden, aber nicht das im Detail. Findet
> man dort auch die Updates von Martin Trautmann?

Ich weiß es, weil das DB-Schema noch von mir stammt. Dokumentiert hatte ich 
aus meiner Sicht alles. Inklusive Beispielanfragen etc.. Schau mal auf 
sourceforge.net . Was der Martin alles gemacht hatte, habe ich nicht mehr 
mitverfolgt.

Thomas

From typo3_maillist at tamas.szalai.de  Tue Jul 31 13:07:34 2007
From: typo3_maillist at tamas.szalai.de (Tamas Szalai)
Date: Tue, 31 Jul 2007 13:07:34 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <200707311249.42533.mack@ifis.cs.tu-bs.de>
References: <1185549364.24627.7.camel@localhost>
	<1185806857.6088.12.camel@localhost>
	<1185878052.5872.13.camel@localhost>
	<200707311249.42533.mack@ifis.cs.tu-bs.de>
Message-ID: <1185880054.5872.15.camel@localhost>

Am Dienstag, den 31.07.2007, 12:49 +0200 schrieb Thomas Mack:
> Der Name eines Postleitzahlgebietes ist die Postleitzahl dieses Gebietes.
> 
> 500100000 ist der Name eines Eintrags. Es gibt z.Zt. zwei verschiedene 
> Eintragstypen: nämliche Orte (oder so ähnlich) als einen Typ, und 
> Postleitzahlgebiete als weiterer Typ.
> 
> Diese beiden Typen werden in der geodb_locations unterschieden. Da Dich nur 
> die Ortsnamen interessieren, machst Du noch einen weiteren Join über die die 
> geodb_locations:
> 
> FROM ..., geodb_locations loc
> WHERE ... AND loc.loc_type = .... AND loc.loc_id = g.loc_id
> 
> Außerdem solltest Du auch auf is_default_name überprüfen, sonst kann es 
> geschehen, daß Du mehrere Ortsnamen für ein und denselben Ort (oder 
> Bundesland oder Landkreis o.ä.) bekommst. Also so etwas wie:
> 
> ... AND g.is_default_name = true AND g1.is_default_name = true
> 
> 
> Thomas

Danke!

SELECT 	g.loc_id AS "ID", 
	g.text_val AS "Ort"

FROM	geodb_textdata g, 
	geodb_textdata g1, 
	geodb_hierarchies gh,
	geodb_locations loc

WHERE 	gh.loc_id = g.loc_id
AND	gh.id_lvl5 = g1.loc_id
AND	g1.loc_id = 524 /*ID des Landkreises*/
AND	g.text_type = 500100000
AND	g1.text_type = 500100000
AND	loc.loc_type = 100700000
AND	loc.loc_id = g.loc_id
AND	g.is_default_name = true 
AND	g1.is_default_name = true
AND	gh.level = 6

GROUP BY g.loc_id
ORDER BY 2

funzt. :o)


From mack at ifis.cs.tu-bs.de  Tue Jul 31 13:16:35 2007
From: mack at ifis.cs.tu-bs.de (Thomas Mack)
Date: Tue, 31 Jul 2007 13:16:35 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <1185806857.6088.12.camel@localhost>
References: <1185549364.24627.7.camel@localhost> <46ADF877.8070504@md-d.org>
	<1185806857.6088.12.camel@localhost>
Message-ID: <200707311316.35795.mack@ifis.cs.tu-bs.de>

Am Montag, 30. Juli 2007 16:47 schrieb Tamas Szalai:
> Am Montag, den 30.07.2007, 16:40 +0200 schrieb Michael Diederich:

> > Ich kann das frühstens im Laufe der Woche ausprobieren, aber eventuell
> > hilft dir ein
> >
> > group by gh.loc_id
> >
> > oder
> >
> > group by g.loc_id
> >

> aha ... nur noch 48 Ergebnisse - sehr gut. danke. :o)

Ok, das mag eine gültige Methode sein. Das Problem liegt darin, daß Dir 
offenbar nicht ganz klar ist, welche Datensätze mehrfach vorkommen können. Im 
Grunde kann JEDER Datensatz mehrfach in der DB vorkommen. Z.B. dann, wenn er 
im Laufe der Zeit seine Zugehörigkeit zu einem Landkreis o.ä. geändert hätte. 
Siehe Gültigkeitsdaten, die bei jedem Datensatz existieren.

Oder auch die verschiedenen Namen, die ein Ort haben kann. Z.B. Munich / 
München als ein bekanntes Beispiel. Oder Niedersachsen / Lower Saxony. Oder 
selbst wenn wir im hier gebräuchlichen Bereich bleiben, gibt es z.B. in der 
Gegend um Bautzen zwei unterschiedliche offizielle Namen für die Orte: einmal 
sorbisch, einmal deutsch (obwohl die sorbischen Einträge noch immer fehlen).

Bei Texteinträgen solltest Du generell nach '... AND is_default_name = true' 
suchen, ansonsten generell nach '... AND valid_until >= date('today')'.

Z.B. habe ich gerade mal in der geodb_hierarchies und der geodb_textdata einer 
älteren OpengeoDB Version geschaut. In der hierarchies sind 2375 von 40120 
Einträgen nicht mehr gültig, in der geodb_textdata sind es 24 von 109916 
Daten. Diese würdest Du alle erstmal doppelt zurückbekommen, wenn Du Dich 
nicht auf ein Datum festlegst.

Grüße,
Thomas

From typo3_maillist at tamas.szalai.de  Tue Jul 31 14:01:21 2007
From: typo3_maillist at tamas.szalai.de (Tamas Szalai)
Date: Tue, 31 Jul 2007 14:01:21 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <200707311316.35795.mack@ifis.cs.tu-bs.de>
References: <1185549364.24627.7.camel@localhost> <46ADF877.8070504@md-d.org>
	<1185806857.6088.12.camel@localhost>
	<200707311316.35795.mack@ifis.cs.tu-bs.de>
Message-ID: <1185883281.5872.24.camel@localhost>

Am Dienstag, den 31.07.2007, 13:16 +0200 schrieb Thomas Mack:
> Oder auch die verschiedenen Namen, die ein Ort haben kann. Z.B. Munich / 
> München als ein bekanntes Beispiel. Oder Niedersachsen / Lower Saxony. Oder 
> selbst wenn wir im hier gebräuchlichen Bereich bleiben, gibt es z.B. in der 
> Gegend um Bautzen zwei unterschiedliche offizielle Namen für die Orte: einmal 
> sorbisch, einmal deutsch (obwohl die sorbischen Einträge noch immer fehlen).

Wenn ich Sie jetzt richtig verstehe, wird mir also nicht immer der
deutsche Name zurückgegeben? 
> 
> Bei Texteinträgen solltest Du generell nach '... AND is_default_name = true' 
> suchen, ansonsten generell nach '... AND valid_until >= date('today')'.

Hier mal alle 3 Abfragen nacheinander in aktualisierter Form:

SELECT  g.loc_id AS "ID", 
        g.text_val AS "Bundesland"


FROM    geodb_textdata g, 
        geodb_hierarchies gh, 
        geodb_textdata g1

WHERE   gh.loc_id = g.loc_id
AND     gh.id_lvl2 = g1.loc_id 
AND     g1.text_val = 'Deutschland'
AND     g1.text_type = 500100000
AND     g.text_type = 500100000
AND     g.is_default_name = true 
AND     g1.is_default_name = true
AND	g.valid_until >= '2007-07-31'
AND	g1.valid_until >= '2007-07-31'
AND     gh.level = 3 
ORDER BY 2

##############################################

SELECT  g.loc_id AS "ID", 
        g.text_val AS "Landkreis"

FROM    geodb_textdata g, 
        geodb_textdata g1, 
        geodb_hierarchies gh

WHERE   gh.loc_id = g.loc_id
AND     gh.id_lvl3 = g1.loc_id
AND	g1.loc_id = 122 /*ID des Bundeslandes*/
AND     g.text_type = 500100000
AND	g1.text_type = 500100000
AND     g.is_default_name = true 
AND     g1.is_default_name = true
AND	g.valid_until >= '2007-07-31'
AND	g1.valid_until >= '2007-07-31'
AND	gh.level = 5

GROUP BY g.loc_id
ORDER BY 2

##############################################

SELECT  g.loc_id AS "ID", 
        g.text_val AS "Ort"

FROM    geodb_textdata g, 
        geodb_textdata g1, 
        geodb_hierarchies gh,
        geodb_locations loc

WHERE   gh.loc_id = g.loc_id
AND     gh.id_lvl5 = g1.loc_id
AND     g1.loc_id = 316 /*ID des Landkreises*/
AND     g.text_type = 500100000
AND     g1.text_type = 500100000
AND     loc.loc_type = 100700000
AND     loc.loc_id = g.loc_id
AND     g.is_default_name = true 
AND     g1.is_default_name = true
AND	g.valid_until >= '2007-07-31'
AND	g1.valid_until >= '2007-07-31'
AND     gh.level = 6

GROUP BY g.loc_id
ORDER BY 2

Bei der letzten Abfrage (Landkreis Wernigerode) ist komischwerweise 2x
Elbingerode mit verschiedener ID im Ergebnis. :/

> Grüße,
> Thomas


From mack at ifis.cs.tu-bs.de  Tue Jul 31 14:20:05 2007
From: mack at ifis.cs.tu-bs.de (Thomas Mack)
Date: Tue, 31 Jul 2007 14:20:05 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <1185883281.5872.24.camel@localhost>
References: <1185549364.24627.7.camel@localhost>
	<200707311316.35795.mack@ifis.cs.tu-bs.de>
	<1185883281.5872.24.camel@localhost>
Message-ID: <200707311420.06159.mack@ifis.cs.tu-bs.de>

Am Dienstag, 31. Juli 2007 14:01 schrieb Tamas Szalai:
> SELECT  g.loc_id AS "ID",
>         g.text_val AS "Ort"
>
> FROM    geodb_textdata g,
>         geodb_textdata g1,
>         geodb_hierarchies gh,
>         geodb_locations loc
>
> WHERE   gh.loc_id = g.loc_id
> AND     gh.id_lvl5 = g1.loc_id
> AND     g1.loc_id = 316 /*ID des Landkreises*/
> AND     g.text_type = 500100000
> AND     g1.text_type = 500100000
> AND     loc.loc_type = 100700000
> AND     loc.loc_id = g.loc_id
> AND     g.is_default_name = true
> AND     g1.is_default_name = true
> AND	g.valid_until >= '2007-07-31'
> AND	g1.valid_until >= '2007-07-31'
> AND     gh.level = 6
>
> GROUP BY g.loc_id
> ORDER BY 2
>
> Bei der letzten Abfrage (Landkreis Wernigerode) ist komischwerweise 2x
> Elbingerode mit verschiedener ID im Ergebnis. :/

Also mal kurz dazu:

1) 'GROUP BY' kenn ich so, daß alle Attribute gruppiert werden müssen (also 
auch g.text_val), bis auf einen arithmetischen Operator (also 
z.B.avg(g.loc_id), sonst macht das keinen Sinn, und sonst klappt das auch 
nicht. Mein Postgres sieht es genauso, deshalb funktioniert diese Anfrage bei 
mir nicht in dieser Form.

2) Wenn ich 'GROUP BY g.loc_id' weglasse, bekomme ich nur ein Elbingerode in 
WR.

3) Elbingerode gibt es in WR und in OHA in meiner älteren DB hier. Was gibt 
denn ein 'SELECT * from geodb_hierarchies where loc_id=16096 or 
loc_id=16097;' bei Dir zurück?

Thomas

From typo3_maillist at tamas.szalai.de  Tue Jul 31 14:46:48 2007
From: typo3_maillist at tamas.szalai.de (Tamas Szalai)
Date: Tue, 31 Jul 2007 14:46:48 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <200707311420.06159.mack@ifis.cs.tu-bs.de>
References: <1185549364.24627.7.camel@localhost>
	<200707311316.35795.mack@ifis.cs.tu-bs.de>
	<1185883281.5872.24.camel@localhost>
	<200707311420.06159.mack@ifis.cs.tu-bs.de>
Message-ID: <1185886008.5872.32.camel@localhost>

Am Dienstag, den 31.07.2007, 14:20 +0200 schrieb Thomas Mack:
> Also mal kurz dazu:
> 
> 1) 'GROUP BY' kenn ich so, daß alle Attribute gruppiert werden müssen (also 
> auch g.text_val), bis auf einen arithmetischen Operator (also 
> z.B.avg(g.loc_id), sonst macht das keinen Sinn, und sonst klappt das auch 
> nicht. Mein Postgres sieht es genauso, deshalb funktioniert diese Anfrage bei 
> mir nicht in dieser Form.
> 
> 2) Wenn ich 'GROUP BY g.loc_id' weglasse, bekomme ich nur ein Elbingerode in 
> WR.

Den Tipp mit dem GROUP BY hatte ich hier gestern in der Liste bekommen,
da ich mehrfach doppelte Resultate hatte. Lasse ich 'GROUP BY g.loc_id'
habe ich also noch mehr doppelte Resultate im Ergebnis.

> 3) Elbingerode gibt es in WR und in OHA in meiner älteren DB hier. Was gibt 
> denn ein 'SELECT * from geodb_hierarchies where loc_id=16096 or 
> loc_id=16097;' bei Dir zurück?
> 

Habe die Abfrage ausgeführt. Im Anhang (hoffentlich wird das nicht
rausgefiltert) befindet sich eine result.txt, mit dem Ergebnis.

> Thomas
-------------- nächster Teil --------------
mysql> SELECT * from geodb_hierarchies where loc_id=16096 or loc_id=16097;
+--------+-------+---------+---------+---------+---------+---------+---------+---------+---------+---------+-------------+-----------------+-------------+-----------------+
| loc_id | level | id_lvl1 | id_lvl2 | id_lvl3 | id_lvl4 | id_lvl5 | id_lvl6 | id_lvl7 | id_lvl8 | id_lvl9 | valid_since | date_type_since | valid_until | date_type_until |
+--------+-------+---------+---------+---------+---------+---------+---------+---------+---------+---------+-------------+-----------------+-------------+-----------------+
|  16096 |     6 |     104 |     105 |     116 |     174 |     347 |   16096 |    NULL |    NULL |    NULL | NULL        |            NULL | 2004-12-31  |       300100000 | 
|  16096 |     6 |     104 |     105 |     116 |       0 |     347 |   16096 |    NULL |    NULL |    NULL | 2005-01-01  |       300100000 | 3000-01-01  |       300500000 | 
|  16097 |     6 |     104 |     105 |     122 |     190 |     316 |   16097 |    NULL |    NULL |    NULL | NULL        |            NULL | 2003-12-31  |       300100000 | 
|  16097 |     7 |     104 |     105 |     122 |       0 |     316 |   35883 |   16097 |    NULL |    NULL | 2004-01-01  |       300100000 | 3000-01-01  |       300500000 | 
+--------+-------+---------+---------+---------+---------+---------+---------+---------+---------+---------+-------------+-----------------+-------------+-----------------+
4 rows in set (0.00 sec)

mysql> quit

From mack at ifis.cs.tu-bs.de  Tue Jul 31 15:26:13 2007
From: mack at ifis.cs.tu-bs.de (Thomas Mack)
Date: Tue, 31 Jul 2007 15:26:13 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <1185886008.5872.32.camel@localhost>
References: <1185549364.24627.7.camel@localhost>
	<200707311420.06159.mack@ifis.cs.tu-bs.de>
	<1185886008.5872.32.camel@localhost>
Message-ID: <200707311526.13954.mack@ifis.cs.tu-bs.de>

Am Dienstag, 31. Juli 2007 14:46 schrieb Tamas Szalai:
> Am Dienstag, den 31.07.2007, 14:20 +0200 schrieb Thomas Mack:
> > Also mal kurz dazu:
> >
> > 1) 'GROUP BY' kenn ich so, daß alle Attribute gruppiert werden müssen
> > (also auch g.text_val), bis auf einen arithmetischen Operator (also
> > z.B.avg(g.loc_id), sonst macht das keinen Sinn, und sonst klappt das auch
> > nicht. Mein Postgres sieht es genauso, deshalb funktioniert diese Anfrage
> > bei mir nicht in dieser Form.
> >
> > 2) Wenn ich 'GROUP BY g.loc_id' weglasse, bekomme ich nur ein Elbingerode
> > in WR.
>
> Den Tipp mit dem GROUP BY hatte ich hier gestern in der Liste bekommen,
> da ich mehrfach doppelte Resultate hatte. Lasse ich 'GROUP BY g.loc_id'
> habe ich also noch mehr doppelte Resultate im Ergebnis.
>
Um doppelte Resultate auszufiltern, gibt es 'distinct': select distinct 
g.loc_id, g.text_val FROM ...

Aber wenn Du mal schaust, dann siehst Du, daß Elbingerode seit 1.1.2005 nicht 
mehr zum Regierungsbezirk Magdeburg gehört (weil es seit dem keine 
Regierungsbezirke mehr gibt in Sachsen-Anhalt).

Also bekommst Du zwei Datensätze zurück: einmal das Elbingerode, wie es bis 
zum 31.12.2004 existierte, und einmal das Elbingerode, wie es seit dem 
1.1.2005 existiert. Beide Einträge haben level=6, beide Einträge haben als 
Landkreis Wernigerode, usw. usf.. DESHALB bekommst Du halt beide Einträge 
zurückgeliefert.

Schau halt, welche Datensätze Du eigentlich haben willst: nur aktuelle, oder 
alle. Und wenn Du alle Orte haben möchtest, die je zum Landkreis WR gehörten, 
kannst Du anschließend mit distinct die doppelten ausfiltern. Ansonsten mußt 
Du halt sagen, welches Datum Dir genehm wäre (... AND valid_until 
>= '31.7.2007' oder so etwas).

Thomas

From typo3_maillist at tamas.szalai.de  Tue Jul 31 15:51:54 2007
From: typo3_maillist at tamas.szalai.de (Tamas Szalai)
Date: Tue, 31 Jul 2007 15:51:54 +0200
Subject: [opengeodb] Was stimmt mit meiner SQL-Abfrage nicht?
In-Reply-To: <200707311526.13954.mack@ifis.cs.tu-bs.de>
References: <1185549364.24627.7.camel@localhost>
	<200707311420.06159.mack@ifis.cs.tu-bs.de>
	<1185886008.5872.32.camel@localhost>
	<200707311526.13954.mack@ifis.cs.tu-bs.de>
Message-ID: <1185889914.5872.46.camel@localhost>

Am Dienstag, den 31.07.2007, 15:26 +0200 schrieb Thomas Mack:
> Schau halt, welche Datensätze Du eigentlich haben willst: nur aktuelle, oder 
> alle. Und wenn Du alle Orte haben möchtest, die je zum Landkreis WR gehörten, 
> kannst Du anschließend mit distinct die doppelten ausfiltern. Ansonsten mußt 
> Du halt sagen, welches Datum Dir genehm wäre (... AND valid_until 
> >= '31.7.2007' oder so etwas).

Also mit DISTINCT kann ich das GROUP BY weglassen - das funktioniert
schonmal. Der Doppeleintrag von Elbingerode blieb aber trotzdem und
deswegen habe ich noch folgendes gemacht:

SELECT DISTINCT	...

FROM  		...
        	geodb_hierarchies gh,

WHERE   	...
AND		gh.valid_until >= '2007-07-31'
		...

Damit werden mir nun nur noch die aktuell zugeordneten Gemeinden, der
jeweiligen Landkreise angezeigt, richtig? Also der Doppeleintrag von
Elbingerode ist auf jeden Fall verschwunden, dafür aber auch ein paar
andere Orte, die dann wohl nicht mehr im Landkreis mit dabei sind, bzw.
irgendwo eingemeindet wurden(?)...

Ergebnis ohne valid_until in der Hierarchie = 34
Ergebnis mit valid_until in der Hierarchie = 30

Also für mich wäre ein aktuelles Ergebnis besser als eines mit doppelten
Orten.

btw habe ich das valid_until gleich mal noch in meine anderen Abfragen
hinzugefügt :o)

> 
> Thomas