Berghütten

Übernahme aus Tagging von Felswänden:

Dies wäre noch “im Angebot”:

A lean-to is a building located in the mountains or into the wild intended to provide shelter against rain.

tourism = lean_to {name ‘${name} (Lean-to)’ | ‘Lean-to’} [0x2b06 resolution 23]

A Wilderness hut is a building located in the mountains or into the wild intended

to provide shelter, heating to hikers and climbers.

tourism = wilderness_hut {name ‘${name} (Wilderness hut)’ | ‘Wilderness hut’} [0x2b06 resolution 23]

Beides gibt’s in den Östereicher Alpen fast nicht.

Klaus

Vielleicht sollte man noch Grillhütten aufnehmen, die haben mancherorts fast Berghüttenniveau, auch wenn dort Übernachtungen (zumindest offiziell) meistens verboten sind, und da herrscht taggingtechnisch ebenfalls Wildwuchs.
Auch da gibt es die offen zugänglichen und die verrriegelt- verrammelt- und vergitterten, je nach lokaler Eigenart und “Operator”… Wenn z.B. in den rheinland-pfälzischen 25.000er Naturparkskarten eine “GH” verzeichnet ist, dann ist es immer sehr spannend vor was man dann am Ende landet…
Als Reiter interessiert mich dann nur noch, ob daneben eine nette Wiese ist, wo mein Pferd fressen kann, ein nett plätschernder Bach, wo es saufen kann, oder die Hütte sogar auf legalem Weg anfahrbar ist und es einen Parkplatz gibt… wobei diese Dinge in einer Karte publik zu machen stellenweise schon an Geheimtipverrat grenzen…

Nahmd,

Da kann man das Grillen von der Hütte trennen. Fürs Grillen gibts “amenity=bbq; fuel=wood; covered=yes”.

Je nachdem ob zugänglich Shelter oder einfach nur Gebäude.

landuse=meadow; water=stream; amenity=parking; …

Dieses Probleme halte ich für unlösbar. Auf dem Westweg durchn Schwarzwald habe ich zur Übernachtung vorbereitete Hütten gefunden. Eine davon so genial gelegen, dass sie die Etappenplanung deutlich vereinfacht, sogar mit Wasser in nächster Nähe. Ich weiss aber nicht, ob ich die entsprechend etikettieren sollt, weil das Sauforgien anziehen könnte.

Gruß Wolf

Das wird vielfach aber auch mit amenity=shelter +bbq=yes getagged, und damit geht das Chaos los.
Ob der Grill von der Hütte abseits steht oder eingebaut ist, ist meiner Ansicht nach nicht wesentlich. Im Moment wird amenity=shelter für alles verwendet was ein Dach hat auch wenn es nur ein überdachter Unterstand ist (oder “Sitzraufe” in Thüringen). Unter einer Grillhütte versteht man dagegen sprachlich schon etwas geräumigeres, mit etwas mehr Platz und Komfort. Man müsste das vielleicht taggingtechnisch deutlicher unterscheiden können.

Beim übrigen stimme ich Dir voll und ganz zu! :slight_smile:

Die Sachverhalte detailliert zu erfassen finde ich in Bezug auf den Datenbestand gut.
Letztendlich sollte man aber zu maximal jeweils 3 Kategorien (alpine_hut, shelter) kommen.
Unterscheidungen darüberhinaus lassen sich entweder schwer darstellen
oder werden nicht verstanden bzw. wahrgenommen (sowohl beim Ersteller als auch Leser).

Klaus

Hier mal der aktuelle Zwischenstand:

  • rote Hütte = mit Bewirtung
  • weisse Hütte = ohne Bewirtung
  • blauer Unterstand

Sonstige Anmerkungen:

  • Drei von fünf Scharten (N.N.) sind wohl noch namenlos.
  • Ob das Kliff korrekt ist müßte man mal prüfen.
  • Die Lesbarkeit der Signaturen wurde verbessert.
  • Die Objekte “Joch, Berghütte und Gipfel” sind mit Höhenangabe,
  • und die Beschriftung ist in unterschiedlichen Farben ausgeführt.
  • Die Höhenangabe bei der “Leutascher Dreitorspitze” fehlt.

Klaus

Nahmd,

d’accord

  1. Richtige Hütte bewirtschaftet.
  2. Richtige Hütte unbewirtschaftet.
  3. Sonstiger Unterschlupf

Bei 2:
– Betten/Lager/Decken/Kochmöglichkeit/Wenn im Winter offen Heizmöglichkeit: wird angenommen.

  • Zusatzangabe: ob/wie zugänglich

Bei 3:
– Angenommen wird Regenunterstand und allgemeine Zugänglichkeit (letztere nicht gegeben → nicht Shelter sondern banales Gebäude)
– Alles weitere muss explizit angegeben werden.

Ja.

Wobei ich bei unbewirtschaftetetn Hütten eine Markierung ob offen oder avkey (oder ärgeres) und bei Shelter ob zu einer Übernachtung geeignet sehr hilfreich fände.

Und eine Anmerkung: es geht hier in einen Bereich, in dem durch falsche Angaben Menschen in bedrohliche Situationen kommen können. Wer wie ich schon mal abends vor einer unbewirtschafteten Hütte gestanden hat, bei der der AV-Schlüssel nicht passte und vor der Wahl stand, ob 1. unter dem Vordach übernachten, 2. Parforcemarsch ins Tal und versuchen da spät in der Nacht noch eine Pension zu finden oder 3. versuchen mit Gewalt zu öffnen, weiß, was eine Falschinformation anrichten kann¹.

Natürlich kann man keine Garantie abgeben – das können die Führer und offiziellen Karten auch nicht. Selbst wenn ich heute noch nachgeschaut habe, dass die Hütte offen ist, kann schon morgen ein Schloss daran hängen oder Ärgeres.

Nur sollte man beim Konzipieren des Taggings darauf achten, dass bei den häufig vorkommenden Falschtaggings nicht mehr vorgetäuscht wird als da ist. Also eher zu wenig darstellen als zuviel. Daher stammt auch meine Idee zur Angabe der Übernachtungsmöglichkeit bei Shelter. Ist die in einem (eher obskuren) Tag codiert, so wied die nicht so leicht aus versehen auf “true” gestellt.

Gruß Wolf

¹) Ich habe dann Methode 4 gewählt: feststellen, dass es ein zweites Schlüsselloch gibt, und dann dieses (richtige) zum Aufsperren benutzen.

Jo, sieht gut aus…

Woran hast Du ohne/mit Bewirtschaftung in den Tags unterschieden?

Das Kliff ist weg, ich hab gestern mal angefangen, die Landschaft dort bunter zu gestalten…

Grüße, Max

Nahmd,

Zur Kartendarstellung:

:slight_smile: :slight_smile: :slight_smile:

Die Signatur für Scharte/Sattel würde ich aber dünner und nur in schwarz halten. Dezent. Keinesfalls outlined und bunt ausgemalt.

Zum Karteninhalt:

Die Rotmoosalm bietet Bewirtung und Übernachtung. Ich hab die Daten ergänzt.

Das sind nur schwach ausgeprägte Sättel ohne Namen.
Einfach die Punkte, an denen der Südsteig vom Hauptkamm herunterkommende Rippen quert.

Eine ganz grundsätzliche Tagging-Frage: wie markiert man, dass ein Objekt definitiv keinen Namen hat?
Nicht vorhandenes Namensfeld kann ja auch bedeuten: noch nicht erfasst, Handlungsbedarf.

Das ist Unfug. Da endet einfach nur der Wald.
Dieses Problem führt aber wohl offensichtlich einmal durch den Wetterstein :confused:

Gruß Wolf

Zunächst mal an einem zusätzlichen Tag: amenity = restaurant

Klaus

vielleicht noch als ergänzung:

*) nummer des hüttentelefons
*) internet auftritt der hütte

bei jeden besseren gps kann man diese daten natürlich auch per poi laden. entsprechende daten findet man zb bei alpin-koordinaten.de. schöner wäre eine direkte integration.

Nahmd,

Habe ich bei allen von mir bearbeiteten Hütten erfasst.

Nur kann bei weitem nicht alles, was in der OSM-Datenbank erfasst ist, auch in den Karten ausgedrückt werden.

Gruß Wolf

Nahmd,

Habe soeben der Fairniss halber auch Rotmoosalm und Steinernes Hüttl mit einem Restaurant bestückt.

Gruß Wolf

Ich frage mich, ob diese zusätzlichen restaurant-tags zu alpine_hut nötig sind. Im Proposal dazu steht ja schon, dass eine “tourism=alpine_hut” bewirtet ist (“Permanent human presence during opening dates from keepers to provide services (food, clean up, advices, …)”). Nicht dass wir hier gerade ganz vielen Hütten ihre Küche wegnehmen, weil wir auf restaurant wert legen…

Eigentlich finde ich überhaupt das Proposal zu Gebäuden in der Wildnis und den Bergen recht gut, gerade was die Abstufung von Bewirtet - Selbstversorger - Biwakschachtel betrifft. Nur kannte ich das z.B. bis vor ein paar Tagen noch gar nicht und die vielen Shelters zu den wenigen Basic_huts im Alpenraum zeigen, dass ich nicht alleine bin.

Grüße, Max

Moins,

Gewiss sollte man beim Auswerten diese Implikation Tag1/Val1→Tag2/Val2 beachten (Wink mit dem man_made=pole).
Aber solange die Regeln über gefühlte 6178261982618927 Seiten im Wiki verstreut sind, kann man sich darauf nicht verlassen.

Die bewitschafteten Berghütten würden mit hoher Sicherheit nicht auf einer Restauranttester-Seite auftauchen, einfach weil die kaum die Regel aus der Alpin-Szene kennen.

Die Implikationen gehören irgendwo zentral erfasst und zur Verfügung gestellt, so dass man die trivial in Auswertungen übernehmen kann. U.a. auch in die Download Apis mit Tag-Condition. Alternativ auch durch ein automatisches Einfügen (in unserem Fall von amenity=restaurant) per Trigger oder regelmäßigem Cleanup-Lauf auf der DB.

Die Zusatztags gefallen mir. shower und capacity benutze ich schon länger. Das staff= ist die fehlende Unterscheidung zwischen bewirtschaftet und unbewirtschaftet.

Die drei Zwischenstufen zwischen alpine_hut und Shelter halte ich für etwas übertrieben.
– wilderness_hut ist ok für Hütten wie das Wildalmkirchlbiwak, voll geschlossen mit Lagern, ansonsten aber weit unter alpin_hut-Standard.
– Das eigene Tag für “echte” Biwakschachteln ist auch ok, das braucht im Grunde nur auf Spezialkarten dargestellt zu werden.
– lean_to aber würde ich shelter zuschlagen.

Das Einführen neuer Toplevel-Tags ist problematisch, weil die die Auswerter hinterherhinken (die Defaultkarte grundlos teils um Jahre, siehe fell, scree, rock; ich möchte nicht wissen, wo sonst noch). Hier aber noch leicht zu fixen: ich kann tourism=wilderness_hut; amenity=shelter taggen (OMMM™). Wer wilderness_hut beachtet, sollte dem Prio vor Shelter geben. Und sobald die Auswerter aufgeholt haben, kann man per Skript die Tags nachziehen.

Ich habe eben noch einen Teil der Allgäuer und der Berchtesgadener Hütten auf Proposal-Stand gebracht: das geht schnell von der Hand, die Vorschläge sind intuitiv.

Gruß Wolf

Hier mal der (rein theoretische) Versuch einer Kategorisierung:

Primäre Unterscheidung:

  • Objekt (auch) für Übernachtung gedacht
  • Objekt nicht für Übernachtung gedacht

Sekundäre Unterscheidung für Objekte mit Übernachtung:

  • alpine_hut: Alpenvereinshütte mit Bewirtung (Signatur: roter Giebel, rote Wand)
  • alpine_hut: Alpenvereinshütte ohne Bewirtung (Signatur: roter Giebel, weisse Wand)
  • wilderness_hut: einfacher als Alpenvereinshütte (Signatur: weisser Giebel, weisse Wand)
  • lean_to: sehr einfach (Signatur: Flachdach, weisse Wand)

Sekundäre Unterscheidung für Objekte ohne Übernachtung:

  • shelter

Abgeleitete Merkregeln:

  • je vollständiger das Objekt einem Haus gleich, desto “besser” ist es
  • je “roter” ein Objekt ist, desto “besser” ist es

Es gilt jedoch: Jede Erkenntnisse die auf rein theoretischen Überlegungen beruht, ist, was Realität anbelang, zunächst inhaltsleer.

Frage somit: Paßt die vorgenannte Logik auf die Realität ?

Klaus

Normalerweise stellt die FZK Objekte “ohne Namen” nicht dar - diese Objekte sind typischerweise entweder unfertig oder minder wichtig.
Hier gibt es jedoch Ausnahmen für Objekte die teilweise in der Tat keine Bezeichnung haben, wie z.B. einige Höhlen und Gipfel.
Ich würde die Scharten dann aus der Liste der Ausnahmen wieder rausnehmen (d.h. keine Bezeichnung = keine Darstellung).

Klaus

PS: Gibt es in den Alpen wirklich Gipfel ohne Namen oder geografische Bezeichnung ?

Ich finde, das passt.

Die Unterscheidung mit/ohne Bewirtung am Restaurant-Tag festzumachen halte ich für falsch, aber zumindest im Alpenraum hab ich wenige Gegenbeispiele gefunden, wo das anders eingetragen wäre.

Falls Du eine Legende dazu schreibst, lass das Wort “Alpenverein” weg. Es gibt auch andere Vereine oder Unternehmer, die Hütten betreiben. Ich würde auch bei “shelter” nicht dazuschreiben, dass die zum Schlafen ungeeignet sind, eigentlich dienen Biwakschachteln nur als Schlafplatz. Aber das betrifft alles die Beschriftung (oder das Routing mit automatisch vorgeschlagenen Übernachtungen…), nicht das Darstellen.

In der Realität fehlen eigentlich alle wilderness_huts und lean_tos. Aber Es schadet ja nicht die zu rendern, vielleicht motiviert das zum Eintragen :wink:

Grüße, Max

Bei den “lean_to”-Objekten dürfte dies vermutlich daran liegen, dass diese Objekte allgemein als “shelter” getaggt sind.
Das Objekt im Screenshot oben ist mit “Schüsselkar-Biwak” bezeichnet, dürfte gemäß vorstehenden Logik wohl ein “lean_to” sein.

Klaus