Selbst wenn das heute grundsätzlich noch so sein sollte, was ich bezweifle, heisst das keineswegs, dass das immer so bleiben muss. Vor noch nicht allzu langer Zeit hätte sich niemand vorstellen können, dass z.B. Gemeinden ihre Wasserversorgung an einen Investor verkaufen oder dass die Deutsche Bundespost privatisiert wird und die Mitarbeiter heute Hilfskräfte sind und keine Beamten mehr. Ich glaube nicht, dass es Sinn macht, sich hier selber Grenzen aufzuerlegen, die eigentlich unnötig sind und schon morgen eventuell nicht mehr gelten.
Ein Bauhof ist im Normalfall ein Gelände, auf dem der Eigner Maschinen und Gerät abstellt und teilweise auch wartet sowie Material (zwischen)lagert.
Bei kleinen Baufirmen/Bauhandwerkern “craft=builder, roofer, carpenter” befindet sich der Bauhof im Normalfall auf dem Firmengelände, wo auch das Büro und oft auch das Wohnhaus steht (die typischen Familienbetriebe), so dass eine separate Erfassung nicht nötig ist.
Für große Baufirmen (construction companies), egal ob Hoch- Tief- oder Ingenieurbau gibt es kein “craft=”, da sie gewerkeübergreifend arbeiten. Diese Firmen haben im Normalfall irgendwo ein Verwaltungsgebäude (office=construction_company) und irgendwo anders einen Bauhof oder auch mehrere. Von diesen Bauhöfen rede ich und sehe keinen Grund, warum man die nicht genau so als Bauhof taggen sollte wie die Bauhöfe von Städten und Gemeinden. Warum nicht? Die physische Präsenz OTG ist exakt dieselbe und die Möglichkeit, sowohl owner als auch operator zu spezifizieren sind durch existierende subkeys gegeben.
Bei den gemeindeeigenen Bauhöfen spielt das eher keine Rolle. Bei den Bauhöfen der privaten Baufirmen ist die Hauptrolle der Lagerplatz. Manchmal gibt es Reinigungsplätze für Geräte und z.B. Schalung, manchmal auch kleine Werkstattgebäude (Container, Schuppen) für kleinere Reparaturarbeiten, aber nicht an den Baumaschinen, das machen immer externe Servicebetriebe.
Die Nebengebäude ließen sich m.E. separat auszeichnen, z.B.
aber dazu bedarf es schon sehr detaillierter Kenntnisse, da sich das von außen/oben nicht erkennen lässt, da sind das dann einfach irgendwelche Schuppen oder Container auf dem Bauhof-Gelände.
Das ist genau der Grund, warum wir uns hier die Finger wundschreiben … :D.
Wobei ich mir nicht vorstellen kann, dass es beim Thema “landuse” einen allgemeingültigen Konsens geben kann, dazu ist der Bauchladen an Werten einfach zu inkohärent. Daher gibt es zu diesem Thema bereits eine ganze Reihe Topics und selbst in der Wiki gibt es zu einigen values keine konkrete Meinung, da heisst es dann z.B. “consider using … instead” o.äh. Ist sicher immer eine schöne Diskussion wert.
das bedeutet gar nichts, weil viele mapper für xy keinen abweichenden landuse taggen, auch wenn er anders ist. Was sind denn abgesehen vom landuse die tags die diese Objekte beschreiben? Solange landuse nicht für die Bodennutzung sondern eine immaginäre generalisierte durchschnittliche Bodennutzung riesiger Gebiete verwendet wird braucht man sich das im Detail eigentlich gar ni ansehen. Ist höchstens brauchbar für 1:100000 Maßstäbe als bebaute Fläche (oft nichtmal das, weil Parks und mehr im residential mit drin sind)
Da habe ich schon drauf geachtet und nur Beispiele genommen, die ihr eigenes landuse Gebiet haben. Die office und amenity tags sind alle korrekt und einheitlich.
Wenn das Verwaltungsgericht landuse=civic_admin ist, das Oberverwaltungsgericht aber landuse=government ist das beste Beispiel, dass es an einem System fehlt.
und so einen tag brauchen wir halt auch für die Bauhöfe. Ich würde landuse erstmal rauslassend aus der Diskussion um das spezifische tagging, sonst (er)finden wir wieder nichts was wir dokumentieren können
Mammi71
(One feature, Six mappers and still More ways to map it)
34
+1
Wir brauchen schlicht nicht für jedes Fleckchen OSM ein landuse. Für Schulgelände nicht, für Klärwerke nicht und m.E. auch für Bauhöfe und Straßenmeistereien nicht. Das sind alles meist singuläre Einrichtungen die mit man_made/amenity/… hinreichend genau und auch als Fläche gemappt werden können und teilweise bereits ein eigenes Rendering haben.
Apropo Rendering: für Bauhöfe und Straßenmeistereien kann ich mir durchaus das gleiche Rendering auf der Standardkarte vorstellen wie bei den Klärwerken- diese Objekte sind angesichts der Lage und der Art der Bebauung auch ansonsten hinreichend optisch unterscheidbar (und datentechnisch auswertbar angesichts unterschiedlichem Tagging sowieso).
Wer unbedingt ne optische Unterscheidung braucht - man könnte solchen Flächen auch icons mitgeben, wie bei den unterschiedlichen Wäldern. Aber das finde ich bereits von weit untergeordneter Bedeutung.
Finde ich prinzipiell gut. Die Frage ist nur: Solche Grundstücke haben ja häufig auch mal eine Wiese oder einen kleinen Wald mit drauf, kann man da man_made drüber legen?
Ans Verwaltungsgebäude könnte ja noch ein office=*.
Bei Forstamt und Grünflächenamt wäre dann nur die Frage:
Auch depot=maintenance_yard (auf jeden Fall nicht falsch) oder ausdifferenzieren?
Von den 3 Gebäuden sind 2 Holzschuppen, eines ist so eine Art offener Unterstand, alles einstöckig (wenn ich mich richtig erinnere . war schon länger nicht mehr dort). Dann gibt es noch ein paar Haufen Pflastersteine, Sand und Mutterboden und das war’s.
Sollten zu dem Gelände wirklich Wald oder Wiese gehören, würde ich persönlich diese Fläche ausklammern, da sie nicht zum Daseinszweck des Bauhofs gehören. Kann man aber sicher auch anders sehen.
Zu Forstämtern kann ich nicht viel sagen. Ich kenne solche nur als Verwaltungsgebäude, nicht als eine Art Bauhof. Klar ist schon, dass auch die Geräte für die Forstbewirtschaftung irgendwo abgestellt und gereinigt werden müssen, aber machen die Forstämter das selber? Oder haben die dafür auch eher Subunternehmer, die die Arbeiten ausführen?
Wenn es vergleichbare Einrichtungen sind, würde ich auf jeden Fall bei depot=maintenance_yard bleiben, und bei Bedarf eher eine Stufe weiter runter differenzieren maintenance=roads/forestry/urban_green, aber ob sich das noch sinnvoll auswerten lässt, würde ich jetzt mal offen lassen.
+1, zu viele Ebenen und zu allgemeine Werte sind dann auch nicht optimal.
Da könnte ich mir auch eher depot=public_transport oder eventuell einen komplett eigen Tag public_transport=depot vorstellen. Ist es wirklich sinnvoll alle Depots in einen Topf zu hauen oder gibt es eventuell ein paar klare Abgrenzungen?