Fehler in PLZ.tab

[Martin Trautmann]

Georg V. wrote:

> Und das genau ist derzeit einer der größten Fehler: Der Ebene wird (sogar
> länderspezifisch) einer Bedeutung zu geordnet, dabei gibt es doch die
> Ebenen-Bedeutung in der geodb_locations.

Hallo Georg,

wo in den Locations steht die Ebenen-Bedeutung drin?

Wie würdest du Deutschland / Baden-Württemberg / Südbaden / Breisgau /
Gundelfingen / Heuweiler einordnen, im Vergleich zu Europa / Vatikan /
Petersdom?

Es gibt vergleichbare politische Strukturebenen. In Deutschland ist das
die Gemeindebene unter der Kreisebene unter dem Bundesland. Du würdest
aber beispielsweise in Sachsen-Anhalt nach Wegfall der bisherigen
Regierungsbezirke alles eine Ebene nach oben schieben.

Gerade wegen der Vergleichbarkeit der politischen Gliederungen will in
in der opengeodb die Information haben, auf welcher politischen Ebene
sich der einzelne Eintrag befindet.

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

[Georg Verweyen]

Hallo Martin,

Der meinsame Knoten-/Ursprungs- Punkt ist die Welt: Also

Welt
+- Deutschland          <Staat>
|+- Baden-Württemberg   <Bundesland>
| +- Südbaden
|  +- Breisgau
|   +- Gundelfingen     <Ort>
|    +- Heuweiler       <Ortsteil>
+- Europa               <Erdteil>
 +- Vatikan             <Staat>
  +- Petersdom          <Gebäude>

Dann würde einer darauf kommen, das Deutschland auch in Europa liegt (und
die Ebenen oberhalb von Gundelfingen "Freiburg" und "Landkreis
Breisgau-Hochschwarzwald" lauten), damit ergibt sich:

Welt
+- Europa                <Erdteil>
 +- Deutschland          <Staat>
 |+- Baden-Württemberg   <Bundesland>
 | +- Freiburg
 | +- Landkreis Breisgau-Hochschwarzwald
 |  +- Gundelfingen      <Ort>
 |   +- Heuweiler        <Ortsteil>
 +- Vatikan              <Staat>
  +- Petersdom           <Gebäude>

Dadurch, das man den Objekten feste ID's (loc_id) erteilt, kann man dann
auch so Besonderheiten wie im Wikipedia-Artikel über PLZ Abschnitt Ausnahmen
abbilden:
--- Zitatanfang ---
Obwohl die fünfstelligen Postleitzahlen allein für das deutsche Bundesgebiet
entwickelt wurden, mussten auch Ausnahmen berücksichtigt werden. Das
österreichische Kleinwalsertal im Bundesland Vorarlberg und die Gemeinde
Jungholz in Tirol verfügen als Zollausschlussgebiete Österreichs bzw.
Zollanschlussgebiete Deutschlands sowohl über deutsche als auch über
österreichische Postleitzahlen.  ...
Eine weitere Ausnahme mit zwei Postleitzahlen bildet die Gemeinde Büsingen,
eine deutsche Exklave im Schweizer Kanton Schaffhausen. Hier gibt es
außerdem auch zwei verschiedene Telefonvorwahlen (in Klammern).
--- Zitatende ---

Mit freundlichen Grüßen Georg V.

P.S.: Dies m.E. die beste Datenstruktur, die man für hierarchische
Datenstrukturen verwenden kann.
P.S.2: Die Zeichnungen kann man besten "verstehen", wenn man einen
Zeichensatz mit fester Berite (wie Courier) zur Anzeige nimmt.
-----Ursprüngliche Nachricht-----
Martin Trautmann schrieb

>Georg V. wrote:
>
>> Und das genau ist derzeit einer der größten Fehler: Der Ebene wird
>> (sogar
>> länderspezifisch) einer Bedeutung zu geordnet, dabei gibt es doch die
>> Ebenen-Bedeutung in der geodb_locations.
>
>Hallo Georg,
>
>wo in den Locations steht die Ebenen-Bedeutung drin?
>
>Wie würdest du Deutschland / Baden-Württemberg / Südbaden / Breisgau /

Gundelfingen / Heuweiler einordnen,
>im Vergleich zu Europa / Vatikan / Petersdom?

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

[Martin Trautmann]

Georg V. wrote:

> Hallo Martin,
>
> Der meinsame Knoten-/Ursprungs- Punkt ist die Welt: Also
>
> Welt
> +- Deutschland          <Staat>
> |+- Baden-Württemberg   <Bundesland>
> | +- Südbaden
> |  +- Breisgau
> |   +- Gundelfingen     <Ort>
> |    +- Heuweiler       <Ortsteil>
> +- Europa               <Erdteil>
>  +- Vatikan             <Staat>
>   +- Petersdom          <Gebäude>
>
> Dann würde einer darauf kommen, das Deutschland auch in Europa liegt (und
> die Ebenen oberhalb von Gundelfingen "Freiburg" und "Landkreis
> Breisgau-Hochschwarzwald" lauten)

Hallo Georg,

dennoch fehlt dir damit schon innerhalb eines Landes die politische
Hierarchieebene. Die Daten sind insofern redundant, da du aus der Länge
des Gemeindeschlüssels in Deutschland die Ebene ableiten kannst. Dann
fangen die Probleme aber darunter an: Auf welcher Ebene willst du eine
Straße einstufen? Ich würde hier eine eigene Ebene empfehlen,
typischerweise ist das bei mir die Ebene, wo ich mit 113stelligem
Gemeindeschlüssel arbeite: Jede Strasse in Deutschland kann mit
achtstelligem Gemeindeschlüssel und fünfstelligem Straßenschlüsel
eindeutig eingestuft werden.

Es funktioniert nicht, dass du hierfür den von dir zitierten "Typ"
verwendest. Betrachte z.B. die Typen Stadtteil und Stadtbezirk. In
manchen Städten sind nach offizieller Lesart die Stadtbezirke eine Ebene
unter den Stadtteilen. In anderen ist es genau umgekehrt - und manchmal
gibt's nur das eine oder das andere.

Wo immer du etwas direkt unter einem anderen Eintrag einhängst, taugt
das nur lokal an dieser Stelle. Wenn die Ebenen-Info aber die
Information enthält, dass dazwischen "Leereinträge" fehlen (z.B. weil es
keine Regierungsbezirke in diesem Bundesland gibt), brauchst du die
Ebenen-Information, um im Baum Einträge auf gleicher Ebene mit einander
vergleichen zu können.

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

[Stefan Froehlich-3]

On Sun, Dec 09, 2007 at 09:23:29AM +0100, Martin Trautmann wrote:

> > Welt
> > +- Deutschland          <Staat>
> > |+- Baden-Württemberg   <Bundesland>
> > | +- Südbaden
> > |  +- Breisgau
> > |   +- Gundelfingen     <Ort>
> > |    +- Heuweiler       <Ortsteil>
> > +- Europa               <Erdteil>
> >  +- Vatikan             <Staat>
> >   +- Petersdom          <Gebäude>

> Wo immer du etwas direkt unter einem anderen Eintrag einhängst, taugt
> das nur lokal an dieser Stelle. Wenn die Ebenen-Info aber die
> Information enthält, dass dazwischen "Leereinträge" fehlen (z.B. weil
> es keine Regierungsbezirke in diesem Bundesland gibt), brauchst du die
> Ebenen-Information, um im Baum Einträge auf gleicher Ebene mit
> einander vergleichen zu können.

Wenn zwei Eintraege auf gleicher Ebene miteinander vergleichbar sein
sollen, dann lohnt es sich IMHO, eigene Tabellen dafuer zu verwenden:
beispielsweise Staaten, Ortschaften, Strassen.

Andernfalls ist das ein bisschen witzlos: wenn in einer Stadt der
Stadtteil unterhalb des Bezirks kommt, in der anderen oberhalb, dann
brauche ich auch keine uebergreifenden Vergleiche von Wiener, Muenchner
und Berliner Stadtteilen. Hier wuerde sich IMHO eher eine anonyme,
kaskadierbare Struktur anbieten.

Servus,
   Stefan

--
Stefan - die durchschlagendste Steigerungsform von heiter!
http://www.sloganizer.de/
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Stefan Froehlich wrote:

> Wenn zwei Eintraege auf gleicher Ebene miteinander vergleichbar sein
> sollen, dann lohnt es sich IMHO, eigene Tabellen dafuer zu verwenden:
> beispielsweise Staaten, Ortschaften, Strassen.

Der Vorschlag ergibt eine gänzlich andere Datenstruktur. Ob ich damit
etwas gewinne?

Würde es damit tatsächlich besser? Sollte man dann nicht eher trennen in
eigene Tabellen für deutsche Ortschaften? Oder für deutsche Bundesländer
und eine eigene für Schweizer Kantone? Oder sollten die bayrischen
Gemeinden in eine eigene Tabelle?

Ich finde, solche Umstrukturierungen liegen in der privaten Anwendung:
Jeder kann aus den aktuellen Basisdaten genau diese Sichtweisen
ableiten, so wie er sie braucht. opengeodb liefert hier nur das
Rohformat, und das in IMHO einer akzeptablen Form. Dass es dadurch
komplizierter wird als vielen lieb ist, ist unbestreitbar - und
anscheinend ein Attribut an die gewünschte Universalität.

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

[Stefan Froehlich-3]

> > Wenn zwei Eintraege auf gleicher Ebene miteinander vergleichbar
> > sein sollen, dann lohnt es sich IMHO, eigene Tabellen dafuer zu
> > verwenden: beispielsweise Staaten, Ortschaften, Strassen.

> Der Vorschlag ergibt eine gänzlich andere Datenstruktur. Ob ich
> damit etwas gewinne?

Das herauszufinden sollte das Ziel der Diskussion sein. Offenbar
gibt es Leute, die eine normalisierte Struktur sinnvoller faenden -
und eine konkrete Diskussion darueber gab es, jedenfalls in den
letzten paar Jahren, nicht.

> Würde es damit tatsächlich besser? Sollte man dann nicht eher
> trennen in eigene Tabellen für deutsche Ortschaften? Oder für
> deutsche Bundesländer und eine eigene für Schweizer Kantone? Oder
> sollten die bayrischen Gemeinden in eine eigene Tabelle?

Eine einheitliche Struktur fuer alle Daten ist (alles, wie immer,
IMHO) schon ratsam. Ob die Struktur flach oder gegliedert sein soll,
das koennte man einmal durchdenken, idealerweise am konkreten
Beispiel.

Hauptvorteile einer tieferen Strukturierung waere wohl, dass sich
Anwender mit dem Ableiten der benoetigten Daten etwas einfacher
taeten (dazu kommen eigentlich die meisten Anfragen hier), und
vielleicht auch noch, dass die Datenpflege etwas leichter gestaltet
werden koennte.

Die Informationsmenge an sich wird wohl gleich bleiben...

> Dass es dadurch komplizierter wird als vielen lieb ist, ist
> unbestreitbar - und anscheinend ein Attribut an die gewünschte
> Universalität.

Interessant ist eine Neustrukturierung fuer mich nur, wenn die
Universalitaet dabei erhalten bleibt (im Rahmen des sinnvollen
jedenfalls; Ablaufdaten und Hoeheninformationen fuer Kontinente sind
beispielsweise durchaus verzichtbar, wenn sie sich aus irgendwelchen
Gruenden nicht mehr darstellen lassen).

Servus,
   Stefan

--
Die gichtige Genialität lustiger Bayern. Stefan!
http://www.sloganizer.de/
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Georg Verweyen]

Martin Trautmann schrieb am 09.12.2007 09:23
> ...
> dennoch fehlt dir damit schon innerhalb eines Landes die politische
> Hierarchieebene. Die Daten sind insofern redundant, da du aus der
> Länge des Gemeindeschlüssels in Deutschland die Ebene ableiten kannst.
> ...

Nein! Und bitte der Gemeindeschlüssel ist eine typische deutsche
(Verwaltungs-)Erfindung! Und da die Datensammlung mal als
D-A-CH-Sammlung gestartet ist, ist dieses Kriterium schon damals nicht
ausreichend gewesen und kann nur zur Prüfung der Dateneingabe
herangezogen werden.

> ... In manchen Städten sind nach offizieller Lesart die Stadtbezirke
> eine Ebene unter den Stadtteilen. In anderen ist es genau umgekehrt -
> und manchmal gibt's nur das eine oder das andere. ...

Ein Grund mehr, dass man von dieser Regel der festen Ebenenzuordnung
wegkommt. Wir benötigen ein flexible Zuordnung von Hierarchien
(Nachfolger bzw. Vorgänger von reicht vollständig) und keine unflexiblen
Vorgaben.
> ... Wenn die Ebenen-Info aber die Information enthält, dass dazwischen
> "Leereinträge" fehlen (z.B. weil es keine Regierungsbezirke in diesem
> Bundesland gibt), brauchst du die Ebenen-Information, um im Baum
> Einträge auf gleicher Ebene mit einander vergleichen zu können. ...

Diese Kontrolle hat man sofort, wenn man dem Typ des Vorgängers mit dem
Typ des Nachfolgers vergleicht. Ein Gebäude als Nachfolger von einem
Erdteil ist mit Sicherheit falsch, ein Regierungsbezirk als Nachfolger
eines deutschen Bundeslandes normal, in gewissen Bundesländer aber eben
auch falsch.

Stefan Froehlich schrieb am 09.12.2007 09:11

> ... die Aufteilung in textdata, intdata,
> floatdata, locations und coordinates finde ich sehr ungluecklich,
> weil ueber den Datentyp definiert anstatt ueber den Inhalt.  

Ja, man könnte rein theoretisch eine allgemeingültige Tabelle mit einem
Attribut Typ Text, mit einen Attribut Dezimalzahl (Integer kann man dort
auch abbilden) etc abbilden, aber es ist üblich sich diese leeren
Attribute zu ersparen. Hier ist das Datenmodell sogar sauber.

> ... Eigene
> Tabellen fuer einzelne Objekte erschienen mir sinnvoller. ...

Bitte, Bitte nicht! Damit werden wir nur für die Aufnahme von neuen
Informationstypen unfexibel. Wir haben vor kurzen die Telefon-Nummern
dazu bekommen, wo hätten wir sie dann einbauen sollen? Deine Ideen für
eine Tabelle für jedes Objekt ist mehr etwas für die Endnutzer, die
jeweils nur ganz spezielle Informationen aus der Datensammlung
benötigen. Für diesen Typ der Nutzer ist ein denormalisierte und/oder
transponierte Sicht auf eine Teilmenge wie
   Bundesland; Regierungsbezirk; Kreis; Stadt; PLZ; Ortsvorwahl;
Koordinate sinnvoll, aber bei weitem nicht für den "Jäger und Sammler".
Wir müssen dazu kommen, dass wir ein Datenmodell zum Sammeln und jeweils
ein View für die gewünschten Präsentationssichten erhalten (das wäre ein
Grund tatsächlich eine relationale Datenbank als Sammelbecken zu nehmen).

Und abschliessend noch etwas zum Thema Strassen: Strassen passen nicht
in diese Datensammlung allenfalls Strassenabschnitte (oder wie passt die
A3 in Martins Argumentation), diese sind besser im Projekt OpenStreetMap
aufgehoben. Denn das Wichtigste bei Sammeln von Strassendaten ist nicht
die Existenz sondern eigentlich die Verknüpfungen zwischen den Strassen
(Grundfrage: Wie komme ich von Königswinter zum Petersdom?)

MfG        Georg V.

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

[Stefan Froehlich-3]

On Sun, Dec 09, 2007 at 07:42:43PM +0100, Georg Verweyen wrote:

*huch*

Ich dachte stets, Du seist der Nachfolger von Georg IV. :-)

> > ... Eigene Tabellen fuer einzelne Objekte erschienen mir sinnvoller.
> > ...

> Bitte, Bitte nicht! Damit werden wir nur für die Aufnahme von neuen
> Informationstypen unfexibel.

Deshalb schrieb ich: "von einzelnen". Dass Laender, Bezirke, Kreise
keine eigenen Tabellen bekommen duerfen, um allgemeingueltig zu
bleiben, ist mir klar. Ich halte es aber fuer ungeschickt, _alles_
in die gleiche Ebene zu pressen, aus zwei Gruenden:

a) zwingt es bei konkreten auch dort zu Transformationen, wo diese
gar nicht notwendig waeren (das betrifft primaer Erdteile und
Staaten) und

b) gibt es ja nicht nur Vorgaenger->Nachfolger Beziehungen

> Wir haben vor kurzen die Telefon-Nummern dazu bekommen, wo hätten
> wir sie dann einbauen sollen?

Das ist zu diskutieren. Bei Telefonvorwahlen gibt es, jedenfalls
sowei ich es weiss, eine 1:n Zuordnung zu Staaten und eine 1:n
Zuordnung zu Ortschaften. Damit wuerde mit je einem Feld bei Staaten
und Ortschaften alles abgedeckt sein. Stimmt die obige Annahme nicht
(d.h. mehr als eine Vorwahl fuer eine Ortschaft bzw. fuer einen
Staat), braucht es eine andere Loesung, wie z.B. im folgenden Absatz.

Aber, am Beispiel PLZ: wenn die ins flache Vorgaenger-Nachfolger
Modell eingebettet sind, gibt es immer Probleme, weil PLZ in unseren
Breitengraden m:n mit Ortschaften in Verbindung stehen (und auf
dieser Ebene am haeufigsten benoetigt werden). Gerade hier empfinde
ich die derzeitige Loesung als sehr unbefriedigend. Hier faende ich
eine eigenstaendige Tabelle "PLZ" geschickt, die dann n:m mit der
Tabelle "Ortschaft" verknuepft werden kann, aber genauso auch mit
den Objekten aus der Verwaltungshierarchie oder den Laendern.

> Deine Ideen für eine Tabelle für jedes Objekt ist mehr etwas für
> die Endnutzer,

Wie gesagt, _jedes_ Objekt geht keinesfalls, aber bei manchen
draengt es sich IMHO auf, sie zu isolieren.

> Und abschliessend noch etwas zum Thema Strassen: Strassen passen
> nicht in diese Datensammlung allenfalls Strassenabschnitte (oder
> wie passt die A3 in Martins Argumentation), diese sind besser im
> Projekt OpenStreetMap aufgehoben.

Ack.

Notfalls koennte man solche Daten natuerlich _auch_ mit den anderen
Tabellen verknuepfen, aber daraus wirklich sinnvolle Informationen
abzuleiten duerfte (auch von der Datenmenge her) den Rahmen der
opengeodb weit uebersteigen.

Servus,
   Stefan

--
Die kühne Idee, oder warum Stefan so grandios sattelt!
http://www.sloganizer.de/
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

Stefan Froehlich wrote:

> Aber, am Beispiel PLZ: wenn die ins flache Vorgaenger-Nachfolger
> Modell eingebettet sind, gibt es immer Probleme, weil PLZ in unseren
> Breitengraden m:n mit Ortschaften in Verbindung stehen (und auf
> dieser Ebene am haeufigsten benoetigt werden). Gerade hier empfinde
> ich die derzeitige Loesung als sehr unbefriedigend. Hier faende ich
> eine eigenstaendige Tabelle "PLZ" geschickt, die dann n:m mit der
> Tabelle "Ortschaft" verknuepft werden kann, aber genauso auch mit
> den Objekten aus der Verwaltungshierarchie oder den Laendern.

Der augenblickliche Ansatz erscheint da richtiger: Im Moment hat man die
Daten eher "seriell" und pumpt alles in eine Tabelle. Neben der
m:n-Sicht, welcher Ort welche Postleitzahlen enthält, gibt es aber
faktisch deine eigene Tabelle "PLZ" - markiert durch den Typ PLZ-Gebiet.
Es liegt nur an dir, diese herauszulösen und in eine eigene Tabelle zu
überführen.

>> Und abschliessend noch etwas zum Thema Strassen: Strassen passen
>> nicht in diese Datensammlung allenfalls Strassenabschnitte (oder
>> wie passt die A3 in Martins Argumentation), diese sind besser im
>> Projekt OpenStreetMap aufgehoben.
>
> Ack.
>
> Notfalls koennte man solche Daten natuerlich _auch_ mit den anderen
> Tabellen verknuepfen, aber daraus wirklich sinnvolle Informationen
> abzuleiten duerfte (auch von der Datenmenge her) den Rahmen der
> opengeodb weit uebersteigen.

Nun - es ist meine Hauptmotivation, die opengeodb überhaupt an der
Stelle mit einzubinden ;-)

... und es funktioniert problemlos.

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

[Sven Neuhaus]

Lucas Mengel schrieb:
> Gibts eigentlich irgendwo eine Liste mit den Länderbezeichnungen?
> Also quasi ein Index, welche Kennzahl welches Land bezeichnet?

Steht in der DB. So bekommt man z.B. die ISO-Kürzel heraus:

    SELECT DISTINCT tx.loc_id, text_val AS staat
    FROM geodb_textdata tx, geodb_locations lo
    WHERE text_type = 500100001 /* ISO_3166_1_ALPHA_2 */
    AND tx.loc_id = lo.loc_id
    AND lo.loc_type = 100200000 /* State */

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

[Martin Trautmann]

Felix Schwarz-5 wrote:

> ich habe gerade entdeckt, dass die PLZ.tab auf dem adfc-Server nicht dem
> neuesten Stand entspricht. So fehlt dort z.B. die Plz 04178, während sie
> im Dump 026 prinzipiell enthalten ist.

Zum 1. April 2001 erfolgte der Wechsel

04430 Böhlitz-Ehrenberg 04178 Leipzig
04430 Burghausen 04178 Leipzig
04430 Rückmarsdorf 04178 Leipzig

Von daher fehlt die 04178 tatsaechlich in der PLZ.tab.
Letzter mir bekannter Neuzugang ist die 06861 Dessau-Rosslau (Mitteilungsblatt der Deutschen Post, September 2007)

Schoenen Gruss
Martin


--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Martin Trautmann]

> Zum 1. April 2001 erfolgte der Wechsel

http://www.leipzig.de/de/buerger/service/info/gebiet/plz/index.aspx

--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)

[Felix Schwarz-5]

Martin Trautmann schrieb:
> Von daher fehlt die 04178 tatsaechlich in der PLZ.tab.

Wenn ich mich nicht total vertan habe, fehlen auch die folgenden Leipziger
Postleitzahlen in der PLZ.tab (auf der von dir geposteten Leipziger Plz-Karte
sind sie dargestellt):
04158 Leipzig
04288 Leipzig
04319 Leipzig

Zudem sind in der PLZ.tab ebenso nicht enthalten (Plz-Suche der Post kennt sie
als normale Straßenadressen):
01156 Dresden
01328 Dresden


--
Felix Schwarz
Software-Entwicklung und Beratung
Schwerpunkt: Entwicklung auf "Open Source"-Basis

www.schwarz.eu

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

[Martin Trautmann]

Felix Schwarz wrote:

> Martin Trautmann schrieb:
>> Von daher fehlt die 04178 tatsaechlich in der PLZ.tab.
>
> Wenn ich mich nicht total vertan habe, fehlen auch die folgenden Leipziger
> Postleitzahlen in der PLZ.tab (auf der von dir geposteten Leipziger Plz-Karte
> sind sie dargestellt):
> 04158 Leipzig
> 04288 Leipzig
> 04319 Leipzig
>
> Zudem sind in der PLZ.tab ebenso nicht enthalten (Plz-Suche der Post kennt sie
> als normale Straßenadressen):
> 01156 Dresden
> 01328 Dresden

Hallo Felix,

besten Dank - ohne Koordinaten kann ich sie aber nicht einpflegen.

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

[Felix Schwarz-5]

Hallo Martin,

Martin Trautmann schrieb:
> besten Dank - ohne Koordinaten kann ich sie aber nicht einpflegen.

Wie hast du die Koordinaten für die anderen PLZs errechnet/recherchiert?

--
Felix Schwarz
Software-Entwicklung und Beratung
Schwerpunkt: Entwicklung auf "Open Source"-Basis

www.schwarz.eu

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

[Martin Trautmann]

Felix Schwarz wrote:

> Wie hast du die Koordinaten für die anderen PLZs errechnet/recherchiert?

Mit der Leipziger Karte kannst du sie direkt entsprechend aus GoogleMaps
ablesen (Gebietsvergleich), für Dresden geht das z.B. über
Beispieladressen (Straßen)
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)