Uff, man das sind ganz schön viele detailierte Informationen, bisher würde ich einfach
amenity=public_building sowie
addr:=
website=*
setzen, dann kann sich doch jeder die Infos aus dem Web raussuchen?
Für die Nummer könnte man ref=* verwenden, aber das wäre wirklich ein wenig abstrakt, hmm…
Zustimmung - sowas wie die vorgesetzte Behoerde oder sowas ist schon ein sehr spezieller Anwendungsfall. Das waere zwar technisch mit Relationen modellierbar, aber das wollen wir nicht wirklich - solche Informationen sollten anderswo (Wikipedia?) gesammelt werden.
Bedenke, dass die Dinge, von denen Du sprichst, keine Geodaten sind. Sie haben nichts mit dem konkreten Gebaeude oder Ort zu tun, in dem das Finanzamt sitzt; es sind abstrakte Informationen. Fuer sowas ist OSM nicht gemacht.
(Ich weiss, dass einige das gern ignorieren und beispielseise per Relationen die komplette Besitzhierarchie einer Einzehandelskette abzubilden versuchen, aber das aendert nichts daran, dass solche Informationen in OSM schwer wartbar sind und eigentlich in einem anderen, besser geeigneten System gepflegt werden sollten.)
Naja, man trägt ja z.B. bei Gemeinden auch den amtlichen Gemeindeschlüssel ein, bei Landkreisen das KfZ-Kennzeichen, bei Kreisstraßen die Nummer… Solche Daten findet man “vor Ort” auch nicht immer und so ohne weiteres. Und wenn solche Ämter eine eindeutige Numerierung haben, ist es schon nicht ganz unlogisch, sowas einzutragen.
Wo wir schon den Gemeindeschlüssel ansprechen: Der wird bei Gemeinde-Relationen als de:amtlicher_gemeindeschlüssel=* eingetragen. Vermutlich braucht man für Finanzämter etwas vergleichbares.
und vielen Dank für die schnelle Aussage und super Begründun warum das mit der vorgesetzten Behörde nicht nütig ist, werde ich also weglassen und nur amenity=public_building und website=* setzen. Was ich schon gern abbilden würde ist die bufa-Nummer weil sie eindeutig ist die jedem Finanzbeamten sofort sagt, welches der 5 Finanzämter mit “FA München” gemeint ist und eben wegen der Steuernummernvergabe. Wie wäre ref:bufa=**** ? (idee stammt von http://wiki.openstreetmap.org/wiki/Key:ref )
und die Großkunden-PLZ wäre demnach auch wegzulassen, weil keine Geoinformation, sondern Postverkehrs-Daten.
alles klar. Hinter operator=* würde ich eher die Gebietskörperschaft vermuten der das Gebäude gehört / die es nutzt also operator=Freistaat Bayern , also für Organisationsstruktur meiner Meinung nach weniger geeignet. Aber da keine Geodaten ganz weglassen ?
in Sachen Großkunden-PLZ: damit habe ich keine PostFACHnummer gemeint, sondern die eigene PLZ, die manche Großempfänger haben. So kann man ein FA in München unter
der Hausadresse anschreiben FA München Katharina-von-Bora-Straße 4 80333 München
dem Postfach anschreiben also FA München Postfach 200226 80008 München
oder Großkunden-PLZ verwenden FA München 80275 München ; wobei keine Straße oder Postfach nötig ist
Nein, das ist kein Postfach. Großkunden haben eine eigenen Postleitzahl.
Die kriegen ihre Post üblicherweise in Postsäcken oder größer.
Im Prinzip wäre addr:postcode richtig dafür. Aber die gilt eben nur für Postsendungen, gegebenenfalls sogar nur für Briefpost. Die Besuchsanschrift hat die übliche Postleitzahl des entsprechenden Gebietes. maggot27 hat ja ein schönes Beispiel aus München gebracht.
Das Problem ist generell, wie man darstellt, dass die Postanschrift (für Briefe), die Lieferanschrift (für Pakete und größer) und die Besuchsanschrift unterschiedlich sein können. Ich kenne da auch keine Lösung.
Postfachanlagen haben übrigens auch eine eigene Postleitzahl.
@maggot27:
Auch von mir herzlich willkommen im Forum.
Die Oberbehörde dürfte doch eher eine Oberfinanzdirektion als direkt das Ministerium sein.
In den Stadtstaaten und dem relativ kleinen Saarland geht es vielleicht ohne diese Zwischenebene.
Ein Postfach-Adresse, wenn man sie aufnehmen will, lautet übrigens addr:pobox (Postfachnummer) und addr:pobox:postcode (für die Postleitzahl) oder besser noch contact:pobox und contact:pobox:postcode, da dies eigentlich nicht mit der lokalen Adresse (oder wie EvanE so schön sagte Besuchsanschrift) zu schaffen hat. Eine Großkunden-PLZ habe ich ehrlich gesagt in OSM noch nicht gesehen (aber auch nicht danach gesucht), das wird auch schwierig, da es eine typische deutsche Erfindung im Postverkehr ist. [Diskussionsvorschlag: contact:major]
@maggot27: Wenn Du das Tag ref:bufa verwendest, trägst Du es bitte auch im Wiki ein (auch mit den Hinweis, dass es einen vierstelligen Wert haben muss)?
Ich würde es befürworten, auch solche Angaben aufzunehmen - falls sie bekannt sind.
Kann das addr:pobox und addr:pobx:postcode oder das contact nicht auch auf der http://wiki.openstreetmap.org/wiki/DE:Key:addr eingetragen werden?
Wenigstens unter Disskussion - so findet man es bei Bedarf.
Über das Eintragen der Großkunden-PLZ kann ich dann auch die örtliche Adresse ersehen, da bei manchen Unternehmen nur die Postfach-Angaben auf dem Schriftverkehr stehen.
Gegen die Gebäude, die von den Finanzämtern genutzt werden, und den Namen daran
hat niemand etwas. Das sind schließlich Geo-Informationen.
Gegen die Nummer der Finanzämter (ref=* oder ref:Bufa=*) hat ebenfalls niemand etwas…
Wogegen sich Walter wendet ist eine Relation, um die Hierarchie der Finanzverwaltung abzubilden.
Das sind keine Geo-Informationen mehr sondern Organigramme und gehören daher nicht wirklich in OSM.
Genau das schreibe ich doch auch in meinem Post. Ich habe nirgendwo vorgeschlagen, Finanzämter in eine Relation zu packen oder ähnliches. Stattdessen habe ich einfach nur die Analogie zwischen dem Tagging von Gemeindeschlüsseln bei einer Gemeinde-Relation und dem Tagging der Finanzamt-Nummer bei einem Finanzamt gezogen. Wenn es dagegen keine Einwände gibt, wozu dann dieses ganze Gepolter?
Naja, Gemeindegrenzen und Abbbiegebeschränkungen sind so genommen auch keine echten Geoinformationen, sondern “Organigramme” für die politische Verwaltung bzw. Straßennutzung…
Die Idee mit der Organisationsstruktur gibt’s ja zusätzlich schon in Form der unsäglichen type=site-Relation, was eine unstrukturierte Sammlung von irgendwas ist, wo der Mapper gerade denkt, daß es zusammmen gehören würde, da kann man von einen Pollerreihe bis zu Gebäuden im Prinzip rein tun, was man gerne möchte und deshalb wird das auch niemand sinnvoll auswerten können, da hilft es auch nicht, wenn man sich ein paar passende Rollen für die Objekte ausdenkt.
Ich habe mich bereits versucht, die Angaben von addr:hamlet, addr:village aus der deutsche Fassung herauszubekommen, aber das ist irgendwie festverdrahtet. Vielleicht komme ich ja in meiner letzten Urlaubswoche dazu, ist auf jeden Fall auf meinen Radar.
Nee, lass das mal lieber drin. Es gibt schließlich andere Adressierungsschemen als Land, Stadt, Straße, Nummer.
Erfassung von Postfach, Großkunden-PLZ und Wohnungsnummern sollte ruhig als Erweiterungsvorschlag ergänzt werden. Allerdings sollte man damit auf der englischen Seite beginnen und das nachher in weitere Sprachen übersetzen.