hi,
nach einer längeren diskussion bei talk-de zum thema postleitzahlen hab ich mich kurzfristig entschlossen, einen kleinen fork meines ol-projektes zu machen.
daraus ist das hier geworden: http://wnordmann.homeunix.com/otm/plz.html
ist absolut beta und bedarf noch einiger verbesserungen.
die performance könnte besser sein
ab zoom-level 13 kommt was
ruhig mal auf den fleck klicken
der server ist nachts down
die werte stammen aus einer live-db und entstehen aus nodes/buildings (addr:postcode=) und straßen (postal_code=)
konvexe hüllkurven (hüllen mit dellen) kommen wenn postgis 2.x live ist. postgis 1.5.2 kann nur konkave hüllen
es wird noch einiges dran erweitert - wenn bedarf besteht (z.b. borders)
abgedeckt wird bbox um deutschland - sorry: A und CH sind (noch) nicht komplett
lg
walter
p.s. da, wo sich die flächen richtig überlappen, ist bestimmt was mit euren daten faul und genau da soll dieses teil helfen.
Auf dem Land mit den “konvexen Dörfen” mag das noch angehen,
wir haben aber z. B. hier in Nürnberg so Straßen wie die Allersberger, die “schlangenartig” durch links/rechts unterschiedliche PLZs
“durchschlängeln” mit ihrer eigenen PLZ. Richtig ekelig sag ich Dir.
Aus jenem Grund bin auch nicht mehr gar so 100% überzeugt, PLZ einzig als Gebiete darzustellen und es eher wie die
Post selbst zu machen, jene nur an Straßen(abschnitte) zu “pappen” (quasi in einer Database abzuhandlen).
jo, das ist schon arg schlimm.
ich hoffe, dass mit postgis 2.0 das etwas besser wird. dann sind nämlich auch flächen möglich, die eindellungen haben.
ist etwas schwer zu beschreiben: eine “krumme banane” ist derzeit fast ein dreick, da einfach die beiden spitzen miteinander verbunden werden. das muss/soll sich aber ändern (nur wann?)
die daten kommen ja ganz frisch aus “unserer” datenbase; da wird keine der grenzen, die jetzt drinstehen, verwendet.
wenn ich bei bedarf noch die borders als extra layer anzeige - so wie es der osm-inspector macht- sieht man ja “theorie” und “osm-wirklichkeit”
ich habe damit schon mächtig viel schrott gesehen (auch meinen).
und mehr als ein tool soll es ja auch nicht sein.
gruss
walter
also, so ein richtiger schlauch ist das ja nicht. soweit mal das anhand der wenigen punkte sagen kann. was nicht drin ist, kann das programm auch nicht darstellen.
und dass sich krumme flächen derzeit überlappen, hatte ich ja schon gesagt.
mal sehen, ob ich an die beta-version von postgis 2 rankomme.
Nettes Tool. Geschwindigkeitsrekorde bricht es nicht.
Unter einer Minute live gerechnet ist jedoch nicht schlecht.
Ein nettes Beispiel ist der Baroper Marktplatz (Nähe Bahnhof
Dortmund-Barop) Nördlich sind andere PLZ als südlich.
Die gleiche Ecke im OSM-Inspektor.
Was ich wirklich anmerken wollte, sind die Großkunden
der Post, die eigene PLZ haben. Die liegen dann irgendwo
innerhalb eines ‘normalen’ PLZ-Gebietes.
Das gibt es in Dortmund öfter, z.B. hier.
Aber es stimmt, es sind zu wenig Daten (im OSM) und diese auch noch teilweise veraltet.
Bzgl. Großkunden
Die waren mW beim PLZ-Import 2010 kein Thema.
In vielen Großstädten z. B. haben die Behörden/Finanzämter eigene PLZs, nicht nur in Dortmund
jo, hat mich auch überrascht. Wenn man bedenkt, was die DB dafür rödeln muß. (Suche alle Nodes, Ways und Straßen im aktuellen Fenster nur aufgrund der Koordinaten …) -
Da kommen in einerGroßstadt bei Zoomlevel 13 schon mal mehrere tausend zusammen. Ich kann die Platten richtig klappen hören.
Das hast Du dir aber gleich ne “richtig fiese Ecke” ausgesucht. Wie sagt man doch: “Es gibt keine Probleme sondern nur Herausforderungen”
Tja, wenn die da sind, warum sollte ich die nicht so darstellen? Ich hab aber noch keine Idee, wie ich damit umgehen soll.
Einfach weglassen (Anzahl der Knoten=1)? Find ich nicht gut, da es ja auch ein echter Datenfehler sein könnte.
Andere Farbe?
Irgenwas aus den eventuell vorhandenen Tags rausholen? - auch nicht so gut: die letzten beiden Fehler, die ich in Bonn beseitigt habe, waren Stolpersteine mit falscher PLZ.
Wobei ich mich wirklich frage, was das soll. Demnächst haben wohl auch noch HKTS (*) eine Postanschrift
speziellen Tag machen? NEE
Auf jeden Fall sollten die Großkunden, wenn sie in OSM als Objekt drin sind, auch “ihre” PLZ haben. Oder?
gruss
walter
HKTS verpasse ich keine Adressen, aber z. B. Spielplätze - die auch nie Post bekommen (und selten eigene Namen haben) - schon.
Stellen wir uns dazu einmal diesen Dialog vor:
Sie: Schatz, hol doch mal Marco vom Kinderspielplatz ab.
Er: Von welchem?
Sie: Na dem in der Braugasse.
Bin mir nicht so sicher, Großfirmen haben oft 2 Adressen: eine (Post-)Lieferadresse und eine Besucheradresse.
Wie z. B. eine Versicherung ihre Post bekommt, ist mir relativ egal, hingegen eine Behörde zu finden
finde ich schon eher interressant.
hi frank,
die Großfirmen haben ja normalerweise mindestens 2 postl.Zahlen. Derzeit findet mein Progrämmchen ja alle und versucht die darzustellen.
da sehe ich derzeit 4 Situationen:
a) nix drin → nix auf Karte - irgendwie logisch
b) “örtliche” plz drin: → in der “großen Wolke”
c) “eigene” plz drin → hot-spot auf karte
d) beide drin: wolke + hot-spot
wobei bei der letzteren der erfasser schon richtig mühe geben musste (2 pois, building + addr-node, …) um zwei verschiedene plz in osm reinzukriegen.
ich habe -inzwischen- die gleiche meinung wie du: die ortsbezogene plz ist für fast alle belange wichtiger. briefe kommen so auch an.
daraus folgt: addr:postcode ist die ortsbezogene plz obwohl sie bei der post-ag anders verwendet wird
morgen schau ich mal ins wiki rein.
gruss
walter.
Moin,
in der Mailinglist habe ich den Vorschlag gemacht, Großkunden-PLZ zu kennzeichnen, damit sie zB
in Validierungstools, die gegen die PLZ Polygone checken, hier keinen False-Positive melden.
für ein Programm ist das dann noch schwieriger.
Wie unterscheidet man “gute” von “bösen” Objekten?
Ich werd mal meine db quälen und versuchen, einige Spezialfälle rauszukitzeln.
Da ich das Teil aber derzeit als Tool sehe, mit dem man “sein” Gebiet bereinigen kann, sollte das nicht so kritisch sein.
“Meine” Ausreisser kennen ich inzwischen.
Inzwischen hab ich Postgis 2.0.0. beta gefunden und schlage mich damit rum.
Damit gehen konkave Hüllkurven, sodass die Banane endlich krumm wird.
p.s. ich hoffen nur, dass es keine Firmen/Behörden in osm gibt, die mehrfach an verschiedenen Orten mit der gleichen Postfach-Plz eingetragen sind; dann wird’s richtig lustig.
Eigentlich garnicht.
Das sind alles erst einmal Adressen mit abweichender PLZ.
Ob das eigene Postleitzahlen sind oder Fehler müsste man
im Einzelfall prüfen.
Alternative wäre, dass du eine Liste mit Großkunden-PLZ
vorhälst. Also eine Art Positiv-Liste.
Ich fürchte, dass dies durchaus vorkommt.
Mehrere Gebäude mit einer gemeinsamen Poststelle
kann ich mir gut vorstellen.
In Dortmund z.B. zieht sich das Finanzamt über eine
ganze Häuserzeile hin. Da dürfte jedes Haus eine eigene
Hausnummer haben. Allerdings weis ich nicht, wie dort
die Postzustellung geregelt ist.
ich hab mit diese Ecke mal richtig genau angesehen und mit den online.daten der post verglichen:
fast alle daten in osm in dieser ecke sind falsch.
a) die blaue line in osm entspricht fast vollständig google-daten (maps.google.com)
b) die graue linie (importierte …) ist schon besser, aber nicht in osm drin
c) mein program zeichnet die nodes, so wie sie in osm drin sind. da fehlen aber welche und manche sind falsch
d) die rote linie entspricht der post-auskunft.
am hedreisch, baruper bahnhof, baruper marktplatz und die harkortstrasse sind komplet 225, der rest in der ecke ist 227.
ich hab die osm-daten natürlich nicht geändert (lizenz)
ich glaube, dass da noch verdammt viel zu tun ist.
gruss
walter
Großkunden der Post sind ja nicht nur Firmen, sondern auch Behörden und damit würde “type=company” nicht so gut passen.
Gemäß wikipedia:de gibt auch noch einen dritten Typus, den der Postfach-PLZ. (und wenn man diesen auch noch berücksichtigen
würde, dann hätte man 20 PLZs in einem Hauptpostamt (sprich Gebäude), dies würde einen renderer doch etwas in Bedrängnis bringen.
So drastisch würd’ ich das nicht ausdrücken wollen. Sicher,
einige Hausnummer sind nicht eingetragen
und
einige sind wohl verkehrt.
Aber der/die Grenzzeichner kann immer nur so gut sein, wie es die Datenlage im OSM erlaubt.
Da bei der Baroper Bahnhofstraße zusätzlich nicht aufgepasst wurde, liegt das Gesamtbild leider etwas im argen
