An sich spricht nichts dagegen. Im Gegenteil, gerade wenn es mit einer Site-Relation verknüpft ist, halte ich es für eine sehr gute Darstellungsweise. Aber natürlich erfordert es mehr Aufwand, und gerade wenn keine hochauflösenden Luftaufnahmen vorhanden sind, ist die Fläche auch nicht leicht auszumachen.
Ich kann mich da nur anschließen, das klingt nach einem sehr sauberen und aufgeräumten Tagging-Schema, das nicht nur für die Renderer gut zu verwerten ist, sondern sich ganz allgemein gut automatisiert auswerten lässt. Eine site-Relation sagt viel besser aus, wozu z.B. ein Parkplatz gehört, als wenn da nur ein Name dransteht. Letzteres ist nur sehr mühselig bis gar nicht automatisiert auszuwerten.
Davon abgesehen hat man auf diese Weise gleich die Nutzung der gesamten Fläche erfasst und nicht nur die Gebäude und Parkplätze. Dinge wie Schulhöfe oder Grünflächen gehören schließlich genau so zu den Einrichtungen einer Schule oder einer Klinik wie die Gebäude, entsprechend sollte man sie ebenfalls mit einbeziehen.
+1
Bleibt die Frage, wer das überhaupt automatisiert auswerten will? Ich denke, fürn normalen Kartennutzer ist ein name=Kundenparkplatz hilfreicher als eine Relation. Die Site-Relation ist sowieso mit Vorsicht zu genießen, da sie nur eine von mehreren Proposals zum Zusammenfassen von Objekten ist. Andere Vorschläge sind type=collection, type=cluster… Auch bei den Members, Rollen, Vererbungen und Labels scheiden sich noch die Geister.
In manchen Fällen kann man den Namen nur mit einer Relation sinnvoll setzen (siehe meine Beispiele [hier](auf Proposal talk:Collected Ways - OpenStreetMap Wiki)). Bei Schulen und Supermärkten denke ich, dass man ohne Relation auskommt.
Wenn ich z.B. eine interaktive Karte mit Geschäften erstellen möchte, macht es Sinn, wenn man z.B. durch einen Klick aufs das Geschäft anzeigen lassen kann, welche Einrichtungen dazugehören, unter anderem eben auch Parkplätze. Umgekehrt führt ein Klick auf den Parkplatz zum dazugehörigen Geschäftsgebäude. Die müssen nicht immer an der gleichen Stelle sein (Beispiel: Geschäft in der Fußgängerzone, zugehöriger Parkplatz über eine Unterführung zu erreichen - wie soll man sowas “von Hand” finden?). Um sowas zu basteln, ist es sinnvoll, die OSM-Daten so zu gestalten, dass man zusammengehörige Objekte wie Parkplatz und Gebäude eines Geschäftes einander automatisiert zuordnen kann.
Einen Namen an einen Parkplatz setzen kann man auch mittels der Site-Relation, und das sogar noch flexibler als über das name-tag. Man muss dem Renderer nur beibringen, Parkplätzen, die Mitglied einer Site-Relation sind, einen passenden Namen zu geben. Für eine deutschsprachige Karte kann ein ALDI-Parkplatz dann als “ALDI-Kundenparkplatz” beschriftet sein, für eine englische dagegen als “ALDI customers’ parking lot”. So spart man sich das “-Kundenparkplatz” im name-Tag.
Allzu weit darf der Parkplatz nicht entfernt sein, sonst sind die Kunden sowieso verärgert. Wenn ein Parkplatz nur auf der anderen Straßenseite ist, dann fällt er dem Kartenbetrachter auf. Um so mehr, wenn der Parkplatz einen sprechenden Namen hat.
Den spart man nur, wenn es für Kundenparkplätze eine eigene Rolle gibt, sonst weiß der Renderer nicht, ob das ein Kunden-, ein Lieferanten- oder ein Mitarbeiterparkplatz ist. Wenn man für so spezielle Sachen eigene Rollen braucht, dann kann von Flexibilität keine Rede mehr sein.
Eine Site-Relation hätte schon den Vorteil, dass sich damit endlich definieren lässt, für wen das access=permissive auf Parkplätzen gilt. Über diese access-Gruppe ist die Mehrsprachigkeit vielleicht sogar gut machbar, z.B. access=permissive, permissiion=customer. Aber das müsste man erst mal proposen. Status quo ist, dass ein name=Kundenparkplatz angezeigt wird, während alles andere nur hypothetisch ist.
wird das denn nicht durch den access-tag des parkplatzes geregelt?
Kundenparkplatz: access=permissive
Mitarbeiterparkplatz: access=private
Lieferantenparklatz: access=delivery
Und bitte gegebenfalls auch die Wege auf dem Parkplatz entsprechend markieren.
Alles kein Problem
Edbert (EvanE)
Das wird zwar häufig verwendet, ist aber eigentlich falsch:
Auf einem Kundenparkplatz ist das Parken aber nicht generell erlaubt, sondern eben nur für Kunden - also eher ‘destination’ (wenn man denn klarmachen könnte, “was” die Destination ist…).
Das mit der Karte für den menschlichen Betrachter war natürlich nur ein Beispiel. Aber es gibt ja auch z.B. Routenplaner, und was “nah” und “weit” ist, kommt u.a. auch darauf an, ob man sich als Fußgänger oder Autofahrer einem Geschäft nähert. Beispiel: Geschäft XY hat seinen Haupteingang in Straße X, dieser ist auch entsprechend getaggt. Dort gibt es keine Parkplätze. Zusätzlich gibt es aber einen Parkplatz auf der Rückseite, der über Straße Y zu erreichen ist. Ein Routenplaner sollte einen Fußgänger, der zu Geschäft XY möchte, auf Straße X schicken, einen Autofahrer aber auf Straße Y, auch wenn sich das Geschäft dichter an X befindet. Dafür muss er aber wissen, dass der Parkplatz zu Geschäft XY gehört - und das kann er einfacher mit einer Relation herausfinden.
Wie schon oben von wambacher gesagt, könnte man das über das access-Tag unterscheiden. Das sagt ja gerade aus, wer dort parken darf und wer nicht - und ist auch für mein Beispiel des Routingprogramms anwendbar. Das wird, wenn es gut programmiert ist, einen Kunden auf einen Kundenparkplatz und nicht auf einen Mitarbeiterparkplatz schicken, wenn diese entsprechende access-Tags haben.
Vielleicht sollte man sogar ein access=customer vorschlagen, schließlich sind Kundenparkplätze und andere Einrichtungen, die nur für Kunden gedacht sind (z.B. Toiletten), ziemlich gebräuchlich.
Natürlich muss man das erst mal proposen und bis dahin ist ein name-Tag am Parkplatz ja gar nicht so unpraktisch. So wie alle neuen Vorschläge muss sowas erst mal seinen Gang gehen, etabliert sein und von der Software ausgewertet werden.
Gibt es überhaupt einen Tag für den Haupteingang?
Wie sollte man überhaupt am besten das Hauptgebäude auf einer Fläche “Kindergarten” markieren? Schließlich wollen sicher die wenigsten zum Spielgeräteschuppen geroutet werden.
BBO
Ich hatte jetzt einfach an building=entrance gedacht, und evtl. noch die Adresse dazu. Der zum Parkplatz gehörige Eingang aus meinem Beispiel wird sicher auch ein building=entrance tragen.
Es gab da mal ein Proposal, wie man die Nutzungsart von Gebäuden taggen könnte - allerdings ist das schon eine Weile her und ich habe lange nichts in der Richtung gehört, vielleicht ist das auch wieder in der Versenkung verschwunden…
Ja, da wär ich dafür. Wer hat Lust, das Proposal zu erstellen?
Proposal scheint mir nicht nötig:
Nein, destination ist was ganz anderes. Das ist z.B. für Ortsdurchfahrten, wo die Durchfahrt verboten ist, weil der Transit die Umfahrung benutzen soll. (Diese Verbote offenbaren übrigens Planungsfehler, denn auf der Umfahrung sollte man eigentlich schneller sein, und dann wäre kein Verbot nötig…)
Bei einem Parkplatz ist access=destination unsinnig, weil dort zu parken schon impliziert, dass dort das Ziel ist.
Nein, access=customer ist schon die richtige Idee. Genauer gesagt wäre ein Kundenparkplatz access=permissive + vehicle=customer, denn durchgehen darf ja jeder, nicht nur die Kunden.
Das ist jetzt die Windschutzscheibenperspektive. Umfahrungen sind auch dazu da, Ortskerne zu entlasten und wieder eine gewisse Lebensqualität zu ermöglichen. Wenn dafür die Blechdose eine Minute länger braucht, um am Ort vorbeizukommen, ist das keine Katastrophe. Verkehrsplanung heisst heutzutage zum Glück nicht mehr nur, dass Autos möglichst schnell überall hin kommen sollen.
Sorry für OT. Ich gebe zu, dass ich damit angefangen habe. Nein, das ist keine Windschutzscheibenperspektive, denn als Radfahrer hat man mit den Umfahrungen erst recht keine Freude, weil selbst für die Durchfahrt die Wege länger werden, oft auf “ausgenommen Radfahrer” vergessen wird, und weil alle Straßen nur für Autofahrer angeschrieben sind. Wenn du z.B. von hier nach Wien willst, wirst du von den Wegweisern über alle Umfahrungen und zuletzt sogar auf die Autobahn geschickt. Sogar mit einiger Ortskenntnis habe ich mich nach dem Bau der Umfahrungen dauernd verfahren, weil sie so verschlungen sind und alles falsch angeschrieben ist. Das Gebiet war einst super für Rennradtouren - gerade, weite Straßen und wenig Verkehr. Jetzt kann man es zum Radfahren vergessen, die Straßen bestehen nur noch aus Kurven und Kreisverkehren.
Dabei wird übersehen, dass die Kfz sich nicht in Luft auflösen, sondern durch den Nachbarort fahren, oder durch mehrere Nachbarorte, wie Umwege das so an sich haben. Selbst wenn die Kfz durch die vielen Verbote auf die Umfahrungen gezwungen werden, dann machen sie eben dort den Lärm und die Abgase, und die Umfahrungen zerschneiden die Landschaft. Damit geht das ganze Umland der Umfahrungen als Erholungsgebiet verloren. Und das Verrückteste ist, dass die Orte wachsen, und irgendwann ist die Umfahrung dann doch wieder mitten im Ort, nur mit dem Unterschied, dass jedes Fahrzeug nun nun den doppelten oder dreifachen Weg durchs Siedlungsgebiet zurücklegt, also die Belastung vervielfacht wurde.
Ich werde mich mal am Wochenende ans Werk machen 
adressen gehören meiner meinung nach nicht auf das gelände gemappt. bei großen betriebsflächen kommt es sehr wohl vor, dass dort mehrere gebäude mit mehreren unterschiedlichen adressen stehen. ich habe mir angewöhnt, die firmendaten/schuldaten, usw auf die fläche zu mappen, die adresse aber auf das gebäude, welches auf dem gelände steht. es gibt dann noch die anderen varianten wo mehrere hausnummern zu einem gebäude führen, da wird dann auf den entrance node gemappt, bzw auch die variante wo mehrere firmen im gleichen gebäude untergebracht sind (teils mit unterschiedlichen adressdaten wie zB in shopping malls). aber dazu gibts eh eigene themen hier im forum…
Es gibt da sehr unterschiedliche Situationen. Natürlich macht es Sinn, Hausnummern an Gebäuden zu erfassen, wenn mehrere mit unterschiedlichen Hausnummern auf einem Gelände stehen. Es gibt aber ja auch Fälle, wo es nur eine Hausnummer, aber mehrere Gebäude gibt. Und da halte ich es für logisch, die Fläche zu taggen. Sicher gibt es in vielen solchen Fällen offiziell für die anderen Gebäude auch Hausnummern mit Buchstaben dran, aber wenn die nicht am Gebäude stehen und man nicht zufällig offizielle Informationen freigegeben bekommt, kann man das ja nicht wissen.
Noch ein schönes Beispiel zum Thema Hausnummern bei größeren Flächen: Das DESY in Hamburg besitzt zwei Eingänge, einen zur Notkestraße und einen zur Luruper Chaussee. Ebenso besitzt es zwei Adressen: Notkestraße 85 und Luruper Chaussee 149. Es handelt sich aber nur um eine einzige, zusammenhängende Fläche. Auf dem Gelände befinden sich ca. 80 Gebäude mit jeweils eigenen Gebäudenummern, die aber keine Hausnummern sind und auch nicht im Zusammenhang zu den beiden Adressen stehen. Einige der Gebäude gehören zu DESY, andere gehören zur Uni (auch wenn sich beide gleichermaßen auf dem DESY-Gelände befinden), wieder andere werden gemeinsam genutzt. Üblicherweise wird für die DESY-Einrichtungen die Adresse Notkestraße 85 benutzt, für die Uni-Einrichtungen dagegen Luruper Chaussee 149. Das hat dann u.a. zur Folge, dass verschiedene Arbeitsgruppen im gleichen Gebäude Post an verschiedene Adressen bekommen. Wohin also mit den Adressen in so einem Fall? Eigentlich machen nur die Eingänge Sinn.
Ach ja, access=customer ist jetzt proposed.
http://wiki.openstreetmap.org/wiki/Proposed_features/customer