Allerdings scheinen die Koordinaten-Daten in der aktuellen Version 0.2.5a gerunded bzw. deutlich ungenauer zu sein als in obigem Beispiel.
So sind z.B. mehrere Kölner Postleitzahlen (z.B. 50670 und 50678) unter einer loc_id zusammengefasst => die Entfernung beträgt 0,000km.
In obiger Demo wird jedoch eine präzise Entfernung berechnet.
Mache ich irgendwas falsch? Oder hab ich eine falsche Datei heruntergeladen?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Naja, nach meinem Verständnis geht es hierbei weniger um Code..schon bei einfachen db-queries erhält man ja schon die Koordinaten.
In der Tabelle geodb_coordinates sieht man auf den ersten Blick, dass alle Koordinaten auf ca 2-3 Stellen hinter dem komma gerundet sind. (bis auf die mit periodischer Endung)
Bei dem ADFC Beispiel ( http://www.fa-technik.adfc.de/Codierung/opengeodb.pl ) findet man selbige grobe Koordinaten wie in meiner aktuellen DB. Die Kölner PLZ 50670 oder 50678 fallen dort auch unter ein einziges gerundetes Koordinatenpaar.
Die Frage ist, welche DB das offizielle Beispiel auf hoppe-media verwendet..?
Waren die Koordinaten vielleicht in früheren Versionen genauer?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also auf http://www.sebastian-rikowski.de/plz/plz.php wird auch eine Entfernung berechnet. Hier wird noch eine alte Version von OpenGeoDB verwenden. Wenn ich mir die Zahlen in der aktuellen Version anschaue, gewinne ich auch den Eindruck, dass die Zahlen ein bischen gerundet wurden.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In der aktuellen opengeodb sind die bisherigen PLZ-Gebiete eher ein wenig ausgeklammert.
Bisher gab es hier spezielle Einträge vom Typ
(100800000,'de','Postleitzahlgebiet') und
(500100004,'de','Region eines Postleitzahlgebietes')
Derzeit sind diese Daten wenn, dann nur stiefmuetterlich drin. Sieht man sich z.B. Koeln an, so gibt es fuer ganz Koeln die genannte PLKZ 50670 und 50678 - da es aber nur einen Ort Köln gibt, haben alle PLZ-Angaben davon die gleiche Koordinate:
Bei Gelegenheit werden die PLZ.tab mal wieder in eine release einfliessen. Im Moment halte ich es aber beinahe fuer sinnvoller, diese Daten getrennt zu halten, da gerade fuer die Umkreissuche manche genau diese Daten benoetigen, aber nichts sonst.
Schoenen Gruss
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ich bin auch über diese "Ungenauigkeit" gestolpert. Insbesondere bei München ist das unpraktisch, weil da mitunter weit auseinander liegende Stadtteile keinerlei Distanz haben. Es wäre super, wenn die PLZ.tab teil des Releases wäre.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wie haste jetzt die Daten aus der PLZ.tab in die Datenbank geladen? Haste dir ein kleines Skript geschrieben was die einzelnen Felder per INSERT in die Datenbank haut?!
Wenn die Daten eh schon im nächsten Release dabei sind mach ich mir jetzt keine Arbeit. Ich brauch sie zur Zeit noch nicht.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-10-13
Die PLZ.tab ist aber von 2007 und enthält nur 8270 Datensätze.
Warum? Welche PLZ fehlen da im Gegensatz zur DE.sql?
Die DE.sql ist dgegen von Juli 2009 und ich bekomme da 16602 unterschiedliche PLZ/Ort-Datensätze raus, die ja dann aber leider für einen Ort (z.B. Berlin) die gleichen Lat/Lon Werte haben, obwohl Berlin 48km breit und 42km hoch ist. :(
Ich werde womöglich auch den Weg über geonames gehen und die PLZ des DE.sql Dumps per geonames Webservice "updaten"..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hast du auch schon geprueft, wie viele *unterschiedliche* PLZ-Angaben in diesen 16602 enthalten sind.
Die aktuelle PLZ.tab ist nicht perfekt: es fehlen etwa drei Angaben, fuer die noch niemand Koordinaten herausgesucht hat. Ich bezweifle aber, dass deren Fehlen fuer dich relevant waere.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo,
ich wollte die Datenbank verwenden um anhand von Postleitzahlen Entfernungen zu berechnen, ähnlich wie in dem beispiel auf hoppe-media:
http://opengeodb.hoppe-media.com/examples/distance.php
Allerdings scheinen die Koordinaten-Daten in der aktuellen Version 0.2.5a gerunded bzw. deutlich ungenauer zu sein als in obigem Beispiel.
So sind z.B. mehrere Kölner Postleitzahlen (z.B. 50670 und 50678) unter einer loc_id zusammengefasst => die Entfernung beträgt 0,000km.
In obiger Demo wird jedoch eine präzise Entfernung berechnet.
Mache ich irgendwas falsch? Oder hab ich eine falsche Datei heruntergeladen?
Vielleicht solltest du etwas Code senden.
Naja, nach meinem Verständnis geht es hierbei weniger um Code..schon bei einfachen db-queries erhält man ja schon die Koordinaten.
In der Tabelle geodb_coordinates sieht man auf den ersten Blick, dass alle Koordinaten auf ca 2-3 Stellen hinter dem komma gerundet sind. (bis auf die mit periodischer Endung)
Bei dem ADFC Beispiel ( http://www.fa-technik.adfc.de/Codierung/opengeodb.pl ) findet man selbige grobe Koordinaten wie in meiner aktuellen DB. Die Kölner PLZ 50670 oder 50678 fallen dort auch unter ein einziges gerundetes Koordinatenpaar.
Die Frage ist, welche DB das offizielle Beispiel auf hoppe-media verwendet..?
Waren die Koordinaten vielleicht in früheren Versionen genauer?
Also auf http://www.sebastian-rikowski.de/plz/plz.php wird auch eine Entfernung berechnet. Hier wird noch eine alte Version von OpenGeoDB verwenden. Wenn ich mir die Zahlen in der aktuellen Version anschaue, gewinne ich auch den Eindruck, dass die Zahlen ein bischen gerundet wurden.
In der aktuellen opengeodb sind die bisherigen PLZ-Gebiete eher ein wenig ausgeklammert.
Bisher gab es hier spezielle Einträge vom Typ
(100800000,'de','Postleitzahlgebiet') und
(500100004,'de','Region eines Postleitzahlgebietes')
Derzeit sind diese Daten wenn, dann nur stiefmuetterlich drin. Sieht man sich z.B. Koeln an, so gibt es fuer ganz Koeln die genannte PLKZ 50670 und 50678 - da es aber nur einen Ort Köln gibt, haben alle PLZ-Angaben davon die gleiche Koordinate:
http://fa-technik.adfc.de/code/opengeodb.pl?locid=19511;c=D
Ich habe jetzt mal die reinen PLZ-Rohdaten dazugestellt:
http://fa-technik.adfc.de/code/opengeodb/PLZ.tab
Auszug:
#locid plz lon lat Ort
8323 50670 6.95095743959049 50.9511722093173 Köln
8327 50678 6.96648245395115 50.9240361563136 Köln
Mit diesen Daten laeuft die Umkreissuche bei mir:
http://fa-technik.adfc.de/code/anbieter?search=50670;hide=H
Bei Gelegenheit werden die PLZ.tab mal wieder in eine release einfliessen. Im Moment halte ich es aber beinahe fuer sinnvoller, diese Daten getrennt zu halten, da gerade fuer die Umkreissuche manche genau diese Daten benoetigen, aber nichts sonst.
Schoenen Gruss
Martin
Ich bin auch über diese "Ungenauigkeit" gestolpert. Insbesondere bei München ist das unpraktisch, weil da mitunter weit auseinander liegende Stadtteile keinerlei Distanz haben. Es wäre super, wenn die PLZ.tab teil des Releases wäre.
Wundervoll, mit den Daten aus der PLZ.tab klappt es wunderbar, mehr brauch ich auch gar nicht.
Vielen Dank!
Wie haste jetzt die Daten aus der PLZ.tab in die Datenbank geladen? Haste dir ein kleines Skript geschrieben was die einzelnen Felder per INSERT in die Datenbank haut?!
Wenn die Daten eh schon im nächsten Release dabei sind mach ich mir jetzt keine Arbeit. Ich brauch sie zur Zeit noch nicht.
Die PLZ.tab ist aber von 2007 und enthält nur 8270 Datensätze.
Warum? Welche PLZ fehlen da im Gegensatz zur DE.sql?
Die DE.sql ist dgegen von Juli 2009 und ich bekomme da 16602 unterschiedliche PLZ/Ort-Datensätze raus, die ja dann aber leider für einen Ort (z.B. Berlin) die gleichen Lat/Lon Werte haben, obwohl Berlin 48km breit und 42km hoch ist. :(
Ich werde womöglich auch den Weg über geonames gehen und die PLZ des DE.sql Dumps per geonames Webservice "updaten"..
Hast du auch schon geprueft, wie viele *unterschiedliche* PLZ-Angaben in diesen 16602 enthalten sind.
Die aktuelle PLZ.tab ist nicht perfekt: es fehlen etwa drei Angaben, fuer die noch niemand Koordinaten herausgesucht hat. Ich bezweifle aber, dass deren Fehlen fuer dich relevant waere.