inzwischen entdecken immer mehr Tourismusverbände die Bedeutung von OSM und plegen die touristisch relevante Infrastruktur ihres Gebietes wie Örtlichkeiten mit gesicherter Bierversorgung, Übernachtungsmöglichkeiten aller Art, Sehenswürdigkeiten, ausgeschilderte Wegenetze, …
So kann OSM durch die Ortskenntnisse der Touristiker zeitnah aktuell gehalten werden, was grundsätzlich zu begrüßen ist.
Natürlich steht dahinter auch ein Marketing-Interesse und es sollen damit acuh besondere Betriebe wie z.B. Naturparkwirte, Partnerbetriebe eines Tourismusgebietes, Mitglieder besonderer Marketingaktionen, usw. Das Tagging erfolgt z.B. durch das Erfinden neuer Keys oder durch unsachgemäße Zweckentfremdung des Namens, hier auch noch verbunden mit zwei URLs in Website.
Wie lenkt man das in vernünftige Bahnen? Mein erster Gedanke wäre network, aber ein Museum kann z.B. ein Partnerbetrieb sein und gleichzeitig einem überregionalen Museumspass für kostenlosen Eintritt angehören. Für solche m:n-Beziehungen wären Sammelrelationen ideal, aber diese sind ja bei uns verpönt.
Hat jemand noch andere Ideen?
Ich werde die beiden als Beispiel genannte Projekte auf diese Diskussion aufmerksam machen.
“drink:viez” halte ich für vollkommen in Ordnung, es handelt sich ja wirklich um eine Getränkespezialität die dort angeboten wird.
Dinge wie “Partnerbetriebe” sind da schon schwieriger. Ich halte nichts davon, für jeden Verband einen komplett eigenen Tag zu benutzen, das wird nur unübersichtlich. Das sollte direkt von Anfang an mit einem ordentlich definierten Namespace laufen. Am besten etwas in der Art von “association:DE:Verband”. Das Länderkürzel verhindert Überschneidungen bei Namen und das Prefix “association” (Platzhalter für einen guten Begriff) sorgt für Ordnung.
zum Ziegenhof Menzenschwand: Name ist der Eigenname des Betriebs, mehr nicht. Dass etwas ein Partnerbetrieb von X ist, ist kein Name. Erst wenn der Betrieb nach außen unter einer gemeinsamen Marke auftritt und die Eigenheiten des Einzelbetriebs weit zurücktreten, ist die Gemeinschaftsmarke das namensbestimmende. Das trifft bei klassischen Filial-Modellen (Lebensmitteldiscounter), Franchise-Modellen (z.B. McDonalds) und auch oft inhabergeführten Lebensmittelmärkten (Edeka, Rewe) [1]. Ein Ziegenhof kann nicht nur Partnerbetrieb des Biosphärengebiet Schwarzwald, sondern auch Demeter-zertifiziert usw. sein. Es wäre auch eine gleichzeitige Partnerschaft mit einem Tourismusverband möglich.
Selbst bei Angabe der Partnerschaft in description=* oder anderen Tags habe ich gewisse Bauchschmerzen.
Das Erfassen der angebotenen Produkte in OSM ist umstritten. Das ist ein ziemlich geek-iges Thema. Zwar ist die Überprüfbarkeit gegeben, aber irgendwie fürchte ich die Key-Explosion.
Viele Grüße
Michael
[1] Manche der Geschäfte gehören auch der zentralen oder regionalen Genossenschaft/Gesellschaft.
Ich sehe bei sowas durchaus “den” Sinn einer Relation. Ähnlich wie bei einer Bus-route oder einem Radweg ist das Problem hier: Objekte ohne eine Gemeinsamkeit sollen in Relation gebracht werden. So ein Hof kann Teil diverser Partnerschaften sein und aus meiner Sicht ist es nicht Sinnvoll für jeden “Verband” einen Tag zu erfinden. Aber klar: Es geht auch mit: “network:Biosphärengebiet_Schwarzwald = yes”
Evtl. wird es bei einem Hotel deutlicher: Ein “Hilton Menzenschwand”
Es ist nicht sinnvoll eine Relation “alle Hilton Hotels” zu verpassen, weil es der Marke “Hilton” angehört aber wenn genau dieses Hotel eine Partnerschaft mit Verband xyz eine Partnerschaft hat, ist es aus meiner Sicht sinnvoll. Ein Hotel hat idR. eine Marke, kann aber n Partnerschaften haben.
Weil es auch angesprochen wurde: Bei Zertifizierungen denke ich bspw. auch nicht, dass eine Relation sinnvoll ist.
ich sehe den Sinn nicht, aber eine Bürde für alle die die Daten verarbeiten. Ein zusätzlicher tag ist vergleichsweise leicht, da sehe ich den Sinn zwar auch nicht, aber dafür kostet es nicht viel, bei Relationen ist das anders.
Technisch gesehen könnte man natürlich immer eine Relation machen und dafür weniger tags auf den Objekten haben (oder auch gar keine und nur auf den Relationen). Nur würde man so ein System anders aufbauen, bei uns ist der Weg, Objekte mit tags zu beschreiben, und dafür ist das Ökosystem optimiert
