Klettern

Drazhar wrote:

..-
Das einzige was mehr in die Details zum klettern geht ist http://wiki.openstreetmap.org/wiki/Prop … s/Climbing aber das zielt wohl eher aufs taggen einzellner Routen ab, was bei langen Mehrseillängentouren ja sinn machen könnte, aber beim sportklettern wo an Felsen teilweise die Routen weniger als 1m Abstand zueinander haben und sich evtl sogar kreuzen macht das wohl eher wenig Sinn :-/

Es wäre meiner Meinung nach sehr prakisch klettern genauer taggen zu "können" um aus den OSM Daten auch eine Art Übersichtskarte bekommen zu können 🙂

Dein link geht auf ein Propsal - somit einen Vorschlag - , an dem sich seit Oktober 2009 nichts mehr getan hat 🤔
Ansonsten: mach mal 🙂
Im Ernst: Wenn keiner anfinge, eine gute Idee zu entwickeln, vorzuschlagen und umzusetzen, hätten wir in OSM nur highway=yes.

Bin zwar kein Kletterer. Aber wird es nicht schwierig, in der zweidimensionalen Welt von OSM, mehrere fast senkrecht verlaufende Wege, die auch noch eng beieinander liegen, vernünftig abzubilden und auszuwerten 🤔

hurdygurdyman wrote:

Bin zwar kein Kletterer. Aber wird es nicht schwierig, in der zweidimensionalen Welt von OSM, mehrere fast senkrecht verlaufende Wege, die auch noch eng beieinander liegen, vernünftig abzubilden und auszuwerten 🤔

Aus diesem Grund finde ich das bisherige Proposal auch eher unsinnig. Es geht mir nicht darum einzellne Routen zu taggen. Das machst höchstens Sinn bei langen Mehrseillängen und hier kann man unter Umständen (bei alpinen Mehrseillängen) auch noch auf die SAC Sachen zurückgreifen (man will ja nicht zu viele neue Tags haben).

hurdygurdyman wrote:

Ansonsten: mach mal smile

Wie? Einfach ins Wiki gehen und was posten? Ich beschäftige mich erst 1-2 Wochen mit OSM und will net gleich Unfug ins Wiki schreiben :-P

Drazhar wrote:

Wie? Einfach ins Wiki gehen und was posten? Ich beschäftige mich erst 1-2 Wochen mit OSM und will net gleich Unfug ins Wiki schreiben :-P

Nicht unbedingt, zumindest nicht sofort. Du kannst auch erstmal POI, die mit sport=climbing getaggt sind, etwa mit climbing=* ergänzen, wobei Du Dir für * noch passende Werte ausdenken mußt, welche die oben von Dir genannten Varianten bzw. Unterarten repräsentieren. Wenn sich dann einige wiederkehrende, brauchbare Wert herauskristallisiert haben (und Du vielleicht auch allgemein etwas mehr Erfahrung mit OSM gesammelt hast), schreibst Du einen neuen Proposal.

Ich werde mich heute Abend mal etwas mit dem Thema beschäftigen.
Was dafür recht sinnvoll wäre, wäre die Möglichkeit über Tagwatch die vorhanden Nodes mit sport=climbing runterladen zu können. Es gibt ja hier: http://tagwatch.stoecker.eu/Germany/En/ … mbing.html die Möglichkeit den Tag etwas genauer anzuschauen und ich dachte man kann über diesen Link: http://tagwatch.stoecker.eu/osmxapi/*%5 … limbing%5D die Punkte runterladen, zum schauen wo sie getaggt wurden. Jedoch bekomm ich es nicht hin die Datei runterzuladen 🙄 . Ich habe es über Firefox, explorer und wget probiert 🙁

Drazhar wrote:

... Jedoch bekomm ich es nicht hin die Datei runterzuladen 🙄 . Ich habe es über Firefox, explorer und wget probiert 🙁

Der Link verweist auf die chronisch überlastete XAPI. Funktionierende Alternativen findest Du im Wiki unter den Stichworten JXAPI und Overpass API.

Hmm...was es auch noch zu bedenken gibt: Es gibt je nach Region unterschiedlichen Einteilungen der Schwierigkeitsgrade.

Was mir so spontan einfällt, wäre ein Node pro Kletterfelsen und da dann min. und max. Schwierigkeit erfassen. Evtl. noch ein Link, wo man mehr Infos finden kann, wenn es sowas gibt.

Als spontane Lösung würde ich entweder generell auf die franz Skala verweisen (meiner Meinung die genause und meist verwendete), was natürlich viele diskussionen hervorrufen würde. Deshalb muss man wohl für die Bewertung wegen min/max einen extra Tag für jede Skala machen (z.B. climbing:fr=6a climbing:UIAA=6+). Aber so genau habe ich mir noch keine Gedanken gemacht 🙂

Link auf jedenfall, da es mittlerweile für viele Gebiete online Infos gibt (z.b. http://www.climbers-paradise.com/ )

edit: Danke für den overpass API Tip! http://overpass-api.de/api/xapi?node[sport=climbing][@meta] hat funktioniert 🙂

Ich würde erstmal bei groben Unterteilungen anfangen und mich dann um sowas wie Schwierigkeitsscala zu kümmern...

Also erstmal climbing=rock/boulder/waterfall/ice/indoor/artificial_wall (oder so ähnlich, oder vielleicht wäre climbing:type=rock... besser?) festlegen, und dann weitere Spezifizierungen dazunehmen.

Sowas wie Schwierigkeitsgrade würde ich eher zum Schluss machen, weil dann bekommt man auch vielleicht die Eiskletterer unter den Hut...

Jap, ich würde auch sagen, dass die Schwierigkeit erstmal nicht so das Thema sein sollte. Die osm Daten sollen ja auch keinen Kletterführer ersetzen! Viel mehr eine Übersicht bieten und zur Wegfindung helfen. Evtl wenn man mal irgendwo ist und sieht, dass man hier klettern kann, kurz vorbeischauen (stichwort DeepWaterSoloing)

Aber es freut mich, dass direkt so viele Anmerkungen kommen. Ich dachte zuerst, dass das Thema keinen intressiert, weils noch nicht im wiki ist 😉

Drazhar wrote:

Als spontane Lösung würde ich entweder generell auf die franz Skala verweisen (meiner Meinung die genause und meist verwendete)

Wo? In Österreich wird nur UIAA verwendet.

Am besten gibt man immer die Skala an, die in dem Gebiet üblich ist. Denn wenn man fürs Mapping umrechnet und dann muss der Anwender zurück umrechnen um sich was drunter vorstellen zu können, dann hat man 2 Umrechnungen und damit sind Fehler vorprogrammiert.

War ja klar, dass sowas bald kommt wenn ich sowas schreibe 🙂

fkv wrote:

In Österreich wird nur UIAA verwendet.

Erstmal möchte ich nochmal auf http://www.climbers-paradise.com/ verweisen, wo es sich ja um Österreich handelt und meines Wissens wird hier primär franz. verwendet, oder? Auch meine Erfahrungen in Österreich waren eher weniger in Richtung UIAA, aber ich war auch noch nicht in sooo vielen Gebieten in Österreich 🙂

Man kann ja eine OSM Skala einführen, dann muss jeder umrechnen 🙂

Hallo Drazhar!
Bei Taginfo findest du weitere, schon verwendete Tags, z.B. zum Gestein, zu Bohrhaken und eben zu Schwierigkeitesgraden.

Drazhar wrote:

Erstmal möchte ich nochmal auf http://www.climbers-paradise.com/ verweisen, wo es sich ja um Österreich handelt und meines Wissens wird hier primär franz. verwendet, oder?

Das ist sehr eigenartig. Mir kommt vor, die Website richtet sich hauptsächlich an deutsche Touristen. In Übersichten finden sich französische Schwierigkeitsangaben, in den Routendetails dann aber die ortsüblichen (UIAA). Z.B. http://www.climbers-paradise.com/klette … ugang.html und http://www.climbers-paradise.com/klette … -5-sl.html

Ja, das werde ich mir heute Abend zu Gemüte führen.

Ich habe mal eine Frage wegen Unterscheidungen von den Klettermöglichkeiten (z.B. Sportklettern, Bouldern, etc.). Wenn man das z.B. über climbin:type=boulder machen würde, wäre es nicht möglich zu definieren, dass man an einem Fels/Spot bouldern und klettern kann, oder?
Wenn man die Problematik so aufziehen würde:
climbing:sport=yes
climbing:boulder=yes
climbing:deepwater=
climbing:multipitch=
etc. etc.
könnte man multitaggen. In einer Vorlage könnte man das recht einfach über Checkboxen regeln, ohne Vorlage wärs dafür recht kompliziert. Hat jemand ein Beispiel wie man das anders regeln könnte, um multitagging zu ermöglichen?

edit: Ich würde das mit den schwierigkeitsskalen wirklich erstmal hinten anstellen. Wir reden ja auch um das Taggen von Gebieten/Felsen und nicht von einzelnen Routen. Man müsste eh einmal den Grad der leichtesten und einmal der schwersten Route angeben. Eine weitere Überlegung wäre z.B.:
climbing:scale=franz/UIAA/....
climbing:min=
climbing:max=

Ich weis nicht ob das sinnvoll umsetzbar ist, aber man hätte alles in 3 Tags abgedeckt und müsste nicht sowas in der Art machen:
climbing:fr_min=
climbing:fr_max=
climbing:UIAA_min=
climbing:UIAA_max=
etc.

Aber wir sind ja noch im Denkprozess 🙂

Drazhar wrote:

Ja, das werde ich mir heute Abend zu Gemüte führen.

Ich habe mal eine Frage wegen Unterscheidungen von den Klettermöglichkeiten (z.B. Sportklettern, Bouldern, etc.). Wenn man das z.B. über climbin:type=boulder machen würde, wäre es nicht möglich zu definieren, dass man an einem Fels/Spot bouldern und klettern kann, oder?

Jein. Grundsätzlich heißt es immer, daß mehrere Werte in einem Tag möglich sind und per Semikolon getrennt werden (jedenfalls in den Fällen, wo Mehrfachwerte sinnvoll sind: also etwa information="map;guidepost", oneway="yes;no" dagegen weniger). Praktisch macht das kein Mensch, wohl auch weil die bestehenden Renderer solche Mehrfachwerte nicht auswerten.

Deine Idee

Drazhar wrote:

climbing:sport=yes
climbing:boulder=yes
climbing:deepwater=
climbing:multipitch=
etc. etc.

ist in jedem Fall eine mögliche Lösung. In diese Richtung scheint der Trend auch bei anderen Taggings zu gehen. Gut ist auch, alle spezifischen Informationen in einem climbing:*-Namensraum zu sammeln, damit keine Namenskonflikte auftreten.

Drazhar wrote:

climbing:sport=yes
climbing:boulder=yes
climbing:deepwater=
climbing:multipitch=
etc. etc.

Nein, bitte nicht unendlich viele Keys. Was spricht gegen:
climbing=multipitch
climbing=boulder
usw.?

climbing=sport würde ich weglassen, weil das entweder zu multipitch oder zu crag gehört. Also eher climbing:bolted=sport/alpine/no oder so.

Oli-Wan wrote:

Grundsätzlich heißt es immer, daß mehrere Werte in einem Tag möglich sind und per Semikolon getrennt werden (jedenfalls in den Fällen, wo Mehrfachwerte sinnvoll sind: also etwa information="map;guidepost", oneway="yes;no" dagegen weniger). Praktisch macht das kein Mensch

Ich schon. Oft geht es nicht anders. Ein Beispiel hast du grad genannt.

fkv wrote:

Nein, bitte nicht unendlich viele Keys. Was spricht gegen:
climbing=multipitch
climbing=boulder
usw.?

Es gibt einige Gebiete in denen man mehr machen kann als nur bouldern oder nur sportklettern oder nur Mehrseillängen. Und das multitaggen mit ; getrennt ist nicht toll zu rendern. Viele Tags zu haben ist jetzt auch nicht super kompliziert, da man einfach über ne Vorlage taggen kann. Außerdem wären es ja nicht unendlich viele (ca. 8-10?)

fkv wrote:

Also eher climbing:bolted=sport/alpine/no oder so.

climbing:bolted würde ich auch so benutzen. Evtl etwas differenzierter. Ich kenne sportklettergebiete mit 1m Hakenabständen (z.B. Tirol) und bin Pfälzerwald mit sogut wie keinen Haken gewohnt. Dazwischen sind noch einige Stufen die einen Kletterer intressieren könnte. Aber damit kann man sich ja noch beschäftigen 🙂. Ich geb dir Recht, dass man climbing:sport nicht braucht 🙂

Drazhar wrote:

Es gibt einige Gebiete in denen man mehr machen kann als nur bouldern oder nur sportklettern oder nur Mehrseillängen. Und das multitaggen mit ; getrennt ist nicht toll zu rendern.

Mit verschiedenen Keys ist es auch nicht einfacher zu rendern. Wie soll ein Klettergarten, in dem man auch bouldern kann, dargestellt werden?

Viele Tags zu haben ist jetzt auch nicht super kompliziert, da man einfach über ne Vorlage taggen kann. Außerdem wären es ja nicht unendlich viele (ca. 8-10?)

Eben, weißt du selber nicht. Die Anzahl ist undefiniert. Dir fallen ein paar ein, mir auch, ein paar Monate später fallen jemandem weitere ein. Das ist ein typischer Fall für Werte und nicht für Keys.

Wenn etwas mit z.B. climbing:style=crag;boulder getagged ist, kann ich das in einem Renderer (z.B. mkgmap) behandeln wie climbing:style=crag bzw. wie climbing:style=boulder ? Wenn ja, dann wäre es kein Problem so zu taggen. Jedoch glaube ich, dass das nicht geht und man dem Renderer sagen müsste climbing:style=crag;boulder . Das wäre beim rendern komplizierter, da es viele viele Kombinationen gibt.
Außerdem ist es bei einer Vorlage angenehmer einfach ein Häkchen zu setzen, wenn man dort Bouldern kann oder Eisklettern. Und ich glaube nicht, dass es mehr als 10 sinnvolle Arten vom klettern gibt (man muss ja auch net jeden Schnickschnack abdecken)

Das ist auch nichts mkgmap-spezifisches. Es gibt keinen Auswerter, der bei der Anfrage nach climbing:style=boulder ein Objekt mit climbing:style=crag;boulder zurückgibt. Ein weiterer Nachteil wäre, dass man nichts näher spezifizieren kann. Ein climbing:boulder=yes kann man durch ein ersetzen von yes weiter spezialisieren. Bspw. in dem man die Anzahl der Routen angibt. Hängt halt davon ab, wie man es definiert und was wichtig ist.

Drazhar wrote:

Wenn etwas mit z.B. climbing:style=crag;boulder getagged ist, kann ich das in einem Renderer (z.B. mkgmap) behandeln wie climbing:style=crag bzw. wie climbing:style=boulder ?

Genau, Du mußt es dem verwendeten Renderer nur beibringen. Oder einen Präprozessor bauen, der z.B. (einfachste Lösung) von mehreren bekannten Werten immer nur den ersten nimmt und in den Wert einsetzt [1]. Es gibt kein grundsätzliches Problem mit solchen Mehrfachwerten. Es wird nur, wie oben schon geschrieben, von niemandem fast niemandem so praktiziert, weil die Renderer es bisher nicht unterstützen. Laut dem offiziellen Mantra ist uns das egal, aber praktisch kann sich wohl niemand davon freisprechen, daß er seine Einträge gerne z.B. in Mapnik sehen möchte.

[1] etwa sed 's/\(v=[^";]*\);[^"]*"/\1"/'

Nahmd,

hurdygurdyman wrote:

Bin zwar kein Kletterer. Aber wird es nicht schwierig, in der zweidimensionalen Welt von OSM, mehrere fast senkrecht verlaufende Wege, die auch noch eng beieinander liegen, vernünftig abzubilden und auszuwerten 🤔

Deshalb hab ich (mindestens) einmal "highway=ladder" an eine Node gesetzt.
.oO( Das braucht dann ein "ele={von}..{bis}" 🙂

Gruß Wolf

aighes wrote:

Das ist auch nichts mkgmap-spezifisches. Es gibt keinen Auswerter, der bei der Anfrage nach climbing:style=boulder ein Objekt mit climbing:style=crag;boulder zurückgibt. Ein weiterer Nachteil wäre, dass man nichts näher spezifizieren kann. Ein climbing:boulder=yes kann man durch ein ersetzen von yes weiter spezialisieren. Bspw. in dem man die Anzahl der Routen angibt. Hängt halt davon ab, wie man es definiert und was wichtig ist.

Die Anzahl der Routen hinter die Definition schreiben anstatt yes ist eigentlich eine gute Idee, dann hätte man z.B.:
climbing:crag=12
climbing:boulder=4
was sagen würde, es hat 12 kletterrouten und 4 boulder
leute, die diese info net wollen können es ja rendern mit climbing:crag=* etc.
Jedoch darf dann keiner climbing:boulder=no taggen, sonst muss man das beim rendern noch ausschließen 🙂

....dann render halt climbing:crag!=no 😉

Stimmt allerdings 🙂
Wie gesagt bin noch recht frisch dabei 🙂

Mal als Offtopic:
Wenn man sich entscheiden sollte die Routenzahl hinten die Art des Kletterns zu schreiben, wäre es einfach umzusetzen, dass beim Rendern geschaut wird welche Zahl größer ist? Bzw. sowas in der Art:
climbing:crag > climbing:boulder & climbing:crag > climbing:multipitch [symbol für crag]
Also das man im prinzip beim rendern das Symbol der kletterart angezeigt bekommt, welche am meisten vertrehten ist? 😄

Die Sektion Trier des Alpenvereins benutzt sogar OSM :-)

http://dav-trier.de/pages/klettern/klet … n-igel.php

So, ich würde mich langsam hinsetzen und nen Konzept zum Taggen überlegen. Nur ne Frage: Sollte ich das direkt ins wiki schreiben oder erstmal hier ins Forum?

Ich poste hier mal meine grobe Tagauflistung. Die Values muss ich mir noch überlegen, vor allem für die Einteilung der Schwierigkeitsgraden. Ich würde hierzu nicht auf irgendeine Skala zurückgreifen, stattdessen 3-5 Bereiche einteilen. Damit kann man dann auch direkt das Eisklettern beurteilen. Natürlich ist das dann nicht so genau, aber meiner Meinung nach muss man über OSM auch nicht genau wissen ob das jetzt von 5-9 oder von 4-8 etc. etc. geht... wichtiger ist es, obs was im Bereich bis 6, von 6 bis 8, von 8 bis 9 und von 10 bis ... gibt (ähnliches bei Eisklettern/mixed)

sport=climbing
name= [Name des Felsens/Ortes]
climbing:sport=
climbing:boulder=
climbing:ice=
climbing:mixed=
climbing:deepwater=
climbing:multipitch=

ele= [Höhe der Einstiege]
climbing:length= [Felshöhe/Routenlänge]
climbing:grades= [Schwierigkeit der Routen]
climbing:rock= [Felsart]
climbing:quality= [Felsqualität]
climbing:approach= [Zustiegszeit in Minuten]
climbing:equipment= [wie ist die Absicherung]
climbing:orientation= [Felsausrichtung]
website= [Homepage mit Infos, falls vorhanden]

hinter den Kletterarten würde ich als Values zulassen: yes ODER Routenzahl

Nahmd,

Drazhar wrote:

Die Values muss ich mir noch überlegen, vor allem für die Einteilung der Schwierigkeitsgraden. Ich würde hierzu nicht auf irgendeine Skala zurückgreifen, stattdessen 3-5 Bereiche einteilen. Damit kann man dann auch direkt das Eisklettern beurteilen. Natürlich ist das dann nicht so genau, aber meiner Meinung nach muss man über OSM auch nicht genau wissen ob das jetzt von 5-9 oder von 4-8 etc. etc. geht... wichtiger ist es, obs was im Bereich bis 6, von 6 bis 8, von 8 bis 9 und von 10 bis ... gibt (ähnliches bei Eisklettern/mixed)

Ich empfehle, auf bestehende Ontologien zurückzugreifen, sofern die frei verfügbar sind, in diesem Falle die der UIAA. Das erspart Mehrdeutigkeiten und Dokumentationsaufwand (in vielen Sprachen). Die Genauigkeit reduzieren kann man beim Rendern der Daten immer noch.

Gruß Wolf

Das Problem ist, dass es unzählige Skalen gibt. Ziel ist Kletterstellen zu Beschreiben und keine genauen Routeninformationen zu geben. In der Regel reicht es vollkommen zu wissen, ob ich in einem Gebiet als Anfänger die Möglichkeit habe zu klettern oder ob ich als Freak auch noch Routen finden kann. Jeder normale Kletterer greift auf einen Führer oder ähnliches zurück.

Ich würde Schwierigkeitsgrade so wie im Proposal vorgeschlagen angeben, mit allen Varianten. Vermeidet Streitigkeiten, weil da gibt es zu große nationale und regionale Vorlieben. Spätestens wenn Eis dazukommt, verlassen wir die UIAA und messen Winkel oder so.

Eisklettern würde ich noch unterscheiden in Gletschereis und Wasserfall. Ob "rock" dann passt, wenn wir auch Eis mit aufnehmen und künstliche Wände?

"approach" würde ich weglassen, schliesslich schreiben wir bei einem Kino auch nicht dazu, wie weit es zur nächsten Bushaltestelle ist und wir dürfen nicht davon ausgehen, dass alle vom nächsten Parkplatz loslaufen. Zur Not sollen die Leute eine Landkarte bemühen, OSM zum Beispiel.

Bei "equipment" wüsste ich nicht, ob das das Material ist, was ich brauche oder das, was schon dort hängt.

"climbing:boulder=*" finde ich gut. Wird aber schon in diesem Proposal verwendet, was verwirrt. Die meinen damit einen grossen Felsblock, nicht das Verb "bouldern". Das wird sich aber nicht vermeiden lassen, weil Alternative kenne ich zumindest keine und neue Worte erfinden wäre noch verwirrender.

Grüße, Max

PS: Da oben stehen nur negative Dinge. Ist aber nicht so gemeint, ich find die Idee gut, das zu ordnen und die Vorschläge auch. Und mein angewandtes Wissen über Eis und Fels ist bisschen angestaubt. Kann sein, dass die Fachbegriffe sich geändert haben 😉

Hallo,
das mit den grades missfällt mir ein wenig. Hier sollte man auf die vorhandenen Skalen zurückgreifen und diese entsprechend eintragen. Da man nicht jede Route einzeln eintragen kann, fände ich eine Spanne sehr sinnvoll. climbing:UIAA:max=xyz bzw. climbing:UIAA:min=abc etc. Daraus dann abzuleiten, ob hier ein Anfänger glücklich wird oder ein Experte oder gar beide ist dann die Aufgabe des Auswerters. Ebenso der vergleich zwischen den einzelnen Systemen.

Es gibt min 9 Skalen für das reine klettern.
Dazu kommt min eine Skala für das Eisklettern (ich vermute es gibt aber mehrere) und eine weitere für das mixed. Falls man noch das technische Klettern mit aufnimmt ist das nochmal mindestens eine Skala mehr. Das ergibt dann schonmal mindestens 24 unterschiedliche Tags. In meinen Augen ist das viel komplizierter als eine grobe Einteilung zu machen in welchem Bereich man sich bewegt.
Ist aber Ansichtssache. Da die meisten hier lieber min/max Bereiche wollen, wird sich das auf die Masse wohl auch niederschlagen. Evtl fällt uns ja noch ein besseres System ein 🙂

@maxbe: Ach, ich nehm so Sachen nicht persönlich 🙂
approach war ich auch nicht so überzeugt, aber ich hab in der Vergangenheit schon oft ein Gebiet nach der Zustiegslänge ausgewählt, vor allem beim Sportklettern 😉 Aber da man ja grundsätzlich eine OSM Karte mit den Infos dabei hat, kann man das wohl auch gut selbst abschätzen

"equipment" wird im englischen häufig verwendet um "Absicherung" zu erklären. Außerdem ist ein Maß für die Absicherung auch gleichzeitig ein Maß dafür, ob man mobile Sicherungsgeräte mitnehmen soll oder nicht. Ich bin auch nicht ganz glücklich mit climbing:equipment, aber climbing:bolts hat mich noch weniger angesprochen 🙂

Beim Eisklettern muss man den Tag für rock ja nicht angeben. Wobei es einfacher wäre für rock einen allgemeineren Begriff zu finden, unter dem man indoor und Eis auch definieren kann. Ich hab für Eisqualität eher den reiter climbing:quality gedacht (auch für indoof). Gletschereis würde ich nicht unbedingt mit in Klettern nehmen, das zählt in meinen Augen dann doch mehr in Richtung Bergsteigen, aber wäre eine Überlegung Wert.

Bei den Skalen sehe ich den Vorteil, dass man sich als Mapper keine Gedanken machen muss, ob das nun für Anfänger noch geeignet ist oder ob sich ein Experte hier langweilt. Weiterhin kann der Auswerter das ganze beliebig rendern. Vom bloßen Text min-max bis hin zu "für Anfänger geeignet" etc.

Das Argument stimmt schon 🙂

Da hab ich ja jetzt schon keine Lust drauf meine Styles für mkgmap drauf anzupassen 😄 Aber naja, man kanns ja auch einfach schlicht weglassen 🙂

Ich hab heute zwar etwas angefangen nen Artikel fürs wiki zu schreiben, aber hab dann doch gemerkt, dass ich zu wenig Ahnung von den ganzen Formatierungen habe. Wird also wohl noch etwas dauern, aber immerhin kann sich dann alles noch etwas entwickeln hier

Nahmd,

Drazhar wrote:

Das Problem ist, dass es unzählige Skalen gibt.

Ganz so viele sind es nicht. Und es gibt mehr und es gibt weniger verbreitete.
Eine *weitere* Skala zu erfinden braucht es aber wirklich nicht.

Man muss die Skala auch nicht vorschreiben, sondern kann einfach die verwendete Skala mit erfassen:

http://www.openstreetmap.org/browse/way/132408581

Zur Schwierigkeitsbewertung bei Bergwegen verwenden wir die SAC-Scale. Das hält mich aber nicht davon ab, zusätzlich den Farbcode von den Wegweisern zu erfassen. Was daraus nachher gemacht wird? Wir taggen doch nicht für den *OMMMMMM* 🙂

Dinge draußen zu erfassen ist fürchterlich zeitaufwendig – da sollte man soweit irgend möglich vollständig und "objektiv" erfassen. Information, die bereits beim Erfassen verloren geht, kann ich nur wiedergewinnen, indem ich nochmal raus an die entsprechende Stelle laufe.

Drazhar wrote:

Ziel ist Kletterstellen zu Beschreiben und keine genauen Routeninformationen zu geben. In der Regel reicht es vollkommen zu wissen, ob ich in einem Gebiet als Anfänger die Möglichkeit habe zu klettern oder ob ich als Freak auch noch Routen finden kann.

Wir erfassen wir die Daten? Wenn ichs Ottonormalgeodatenerfasser in den Bergen am Einstieg einer Kletterroute vorbeikomme, werde ich da höflich fragen, wie die Route heißt und welche Schwierigkeit sie hat, sodann mein Diktiergerät zücken und die Daten aufsprechen (und dann sehen, dass ich Land gewinne, bevor die Herren mit der unbequemen Jacke anrücken). Sobald wieder online, ein Punktfeature "Kletterrouteneinstieg" erfassen mit Position und Höhe aus dem GPS-Track und Name und Schwierigkeit vom Diktafon. Alles objektiv ohne Bewertung. Die ich auch nicht leisten könnte.

Eine Gebietsübersichtsangabe kann beim Erstellen einer Karte erzeugt werden. Denn woher soll ich vorher wissen, wie die erstellt wird? Wer weiß, auf welche Ideen die Geodatennutzer noch kommen? Wer traut sich da eine Vorhersage?

Drazhar wrote:

Jeder normale Kletterer greift auf einen Führer oder ähnliches zurück.

Meine Kristallkugel ist zur Zeit in der Inspektion, daher kann ich nicht in die Zukunft schauen. Aber ist es denn ausgeschlossen, dass ein Irrer ein Suchformular baut und auf der Ergebnisseite zu Online-Topos verknüpft?

Wenn wir "objektiv" erfassen und nicht bereits die Applikation im Hinterkopf haben, verbauen wir auch keine Möglichkeiten.

Gruß Wolf

Oli-Wan wrote:

Drazhar wrote:

Wenn etwas mit z.B. climbing:style=crag;boulder getagged ist, kann ich das in einem Renderer (z.B. mkgmap) behandeln wie climbing:style=crag bzw. wie climbing:style=boulder ?

Genau, Du mußt es dem verwendeten Renderer nur beibringen. Oder einen Präprozessor bauen, der z.B. (einfachste Lösung) von mehreren bekannten Werten immer nur den ersten nimmt und in den Wert einsetzt [1]. Es gibt kein grundsätzliches Problem mit solchen Mehrfachwerten. Es wird nur, wie oben schon geschrieben, von niemandem fast niemandem so praktiziert, weil die Renderer es bisher nicht unterstützen. Laut dem offiziellen Mantra ist uns das egal, aber praktisch kann sich wohl niemand davon freisprechen, daß er seine Einträge gerne z.B. in Mapnik sehen möchte.

Gibts auch schon in mkgmap:

amenity=fast_food␣&␣cuisine␣~␣'.*pizza.*'␣[0x2a0a␣resolution␣24]

erfasst alles, was irgendwo im key cuisine was mit Pizza stehen hat.

Gruß,
ajoessen

Also da Fazit ist wohl, dass es gewollt ist auf die bisherigen Skalen zurückzugreifen. Ist halt auch fraglich ob man einfach so weiß wie schwer die einfachste und die schwerste Route ist. Also ich bin momentan von keinen der beiden Möglichkeiten überzeugt (also ursprüngliche Skalen oder grobe Einteilung). Aber das Angeben der Schwierigkeit ist eh nur ein zusätzliches Feature was in meinen Augen erstmal garnicht so wichtig ist 🙂

@ajoessen:
Sehr praktisch zu wissen, danke 😄
Ich muss mich wohl noch etwas mehr mit den Möglichkeiten von mkgmap beschäftigen.
Was mich hier auch intressieren würde ist, ob es möglich ist eine Beschreibung für die POIs zu setzen? Also wie {name '......'} den Namen eines Punktes beschreibt, nur um eine Beschreibung zu geben. Ich kann das nicht in den http://wiki.openstreetmap.org/wiki/Mkgm … tyle_rules nicht finden und zum selbst Testen hab ich z.Z nicht so viel Zeit 🙂

Drazhar wrote:

Ich muss mich wohl noch etwas mehr mit den Möglichkeiten von mkgmap beschäftigen.
Was mich hier auch intressieren würde ist, ob es möglich ist eine Beschreibung für die POIs zu setzen? Also wie {name '......'} den Namen eines Punktes beschreibt, nur um eine Beschreibung zu geben.

Ja, so sollte das funktionieen, oder default_name, falls das Objekt nicht doch einen eigenen Namen mitbringt.

Zum testen nehme ich übrigens einen kleinen Ausschnitt zum rendern, der läuft im nullkommanix durch. Die Daten kann man z.B. von JOSM nehmen, und dann auch gleich darin testweise abändern.

Gruß,
ajoessen

ja, so teste ich das auch immer... aber man muss ja auch immer noch aufs GPS übertragen, dann schaltet sich das immer aus wenn man das kabel wieder rauszieht.... das summiert sich auf 😄
das {name ...} geht ist mir klar und dass ich das auch allgmein spezifizieren kann auch. Aber ob ich eine Beschreibung für einen POI setzen kann weiß ich nicht 🙁

edit: Ich habe mal angefangen einen Artikel zu schreiben und diesen geposted. Kritisiert soviel ihr könnt, dann kann mans verbessern. Schwierigkeitsbewertung fehlt noch, das mach ich demnächst dazu. Satzbau/Rechtschreibung könnten etwas vermurkst sein, da ich momentan auf der Arbeit bin und das nur nebenher geschrieben habe 🙂
http://wiki.openstreetmap.org/wiki/DE:T … 3Dclimbing

Darf ich eigentlich die deutsche Seite auf englisch übersetzen und direkt http://wiki.openstreetmap.org/wiki/Tag:sport%3Dclimbing überschreiben?

Drazhar wrote:

Darf ich eigentlich die deutsche Seite auf englisch übersetzen und direkt http://wiki.openstreetmap.org/wiki/Tag:sport%3Dclimbing überschreiben?

Machen darfst du alles, musst aber damit leben, dass alle anderen auch alles dürfen. Z.B. deinen Seitenänderung einfach rückgängig machen.

Gruß,
ajoessen

Hallo zusammen,

schon über längere Zeit habe ich immer mal wieder auf http://wiki.openstreetmap.org/wiki/Prop … s/Climbing geschaut und den Eindruck gewonnen, dass das Proposal sich in den Details verheddert und nicht recht voran kommt. In OSM sind über all die Jahre nichtmal die Klettergebiete rein gekommen - schade! Im verregneten Kletter-Urlaub in Finale Ligure (IT) hätten wir gern in OSM (als grenzüberschreitende Plattform) nach Klettergebieten in trockenen Regionen (zB Frankreich, Monaco) gesucht, aber mangels Masse in OSM funktionierte das nicht. Ich hoffe, dass der hier verfolgte pragmatische Ansatz besser als das Proposal funktioniert :-)

Kann eigentlich jemand von Euch aus Erinnerung, Wiki oder sonstigen Quellen sagen, ob wir (OSM Community) mit den Alpenvereinen mal wegen einem Datenimport oder gar einer Synchronisation (zB zu DAV Felsinfo) gesprochen haben? Die 3 Seiten http://wiki.openstreetmap.org/wiki/Pote … atasources und http://wiki.openstreetmap.org/wiki/Datenquellen und http://wiki.openstreetmap.org/wiki/Import/Catalogue habe ich ohne Treffer durchsucht.
Idee: Wenn OSM einige Informationsteile von DAV Felsinfo http://www.dav-felsinfo.de/html/index.p … Itemid=347 und den anderen Vereinen auf einer Plattform bündeln und mit Back-Link zur jeweiligen Detailseite anbieten würde, hätten doch alle etwas davon: OSM fast alle Felsen im Datenbestand, die Alpenvereine mehr eingehende Links (potenziell alles was OSM-Daten nutzt) & nützlichere OSM-basierte Karten für ihre Unternehmungen, und die Anwender könnten OSM als weltweit nutzbaren "zentralen Verteiler" nutzen 🙂 Vielleicht ist der DAV sogar interessiert, OSM-Karten für die Felsinfo zu nutzen, denn so richtig schick finde ich die aktuell genutzten nicht gerade 😉 und "Internal Server Error" statt Karte nervt auf Dauer ja auch 😛

maxbe wrote:

"approach" würde ich weglassen, schliesslich schreiben wir bei einem Kino auch nicht dazu, wie weit es zur nächsten Bushaltestelle ist und wir dürfen nicht davon ausgehen, dass alle vom nächsten Parkplatz loslaufen. Zur Not sollen die Leute eine Landkarte bemühen, OSM zum Beispiel.

Sehe ich genauso; der Zustieg kann oft von verschiedenen Punkten aus erfolgen (welchen fürs Tag auswählen?) und die Zustiegszeit lässt sich ja durchaus mittels Routing-Algorithmen berechnen, d.h. diese könnten von einer Software verwendet werden, die OSM nach Kletter-relevanten Aspekten filtert/durchsucht/auswertet.

maxbe wrote:

"climbing:boulder=*" finde ich gut. Wird aber schon in diesem Proposal verwendet, was verwirrt. Die meinen damit einen grossen Felsblock, nicht das Verb "bouldern". Das wird sich aber nicht vermeiden lassen, weil Alternative kenne ich zumindest keine und neue Worte erfinden wäre noch verwirrender.

Im Proposal http://wiki.openstreetmap.org/wiki/Prop … s/Climbing finde ich climbing:boulder nicht?! Selbst wenn, wäre das so lange wurscht, wie nicht derselbe Wert zweimal unterschiedliche Bedeutung trägt...

Netzwolf wrote:

Man muss die Skala auch nicht vorschreiben, sondern kann einfach die verwendete Skala mit erfassen

Finde ich sympathisch :-)
climbing:grade:UIAA und climbing:grade:french und so weiter finde ich nicht so schön, weil es viele Keys erzeugt, aber sonst fällt mir keine Lösung ein, wie nebeneinander verschiedene Skalen (zB für Eis, freies, und technisches Klettern) für ein einziges Element in benutzbarer Form umsetzbar wären.

Netzwolf wrote:

Drazhar wrote:

Jeder normale Kletterer greift auf einen Führer oder ähnliches zurück.

Meine Kristallkugel ist zur Zeit in der Inspektion, daher kann ich nicht in die Zukunft schauen. Aber ist es denn ausgeschlossen, dass ein Irrer ein Suchformular baut und auf der Ergebnisseite zu Online-Topos verknüpft?

@Kristallkugel: 🤣
@Auswertung: Dass sowas wie http://www.xctrails.org/ auch fürs Klettern kommt, hoffe ich sehr! 😄
@Führer: Ich stimme da Drazhar zu: Auf Ebene von OSM sollten wir erstmal daran arbeiten, überhaupt Gebiete/Sektoren/Felsen/Boulderblöcke/Hallen/... zu erfassen, also "was auf eine Karte gehört". Sehr gerne auch mit Meta-Infos wie Links zu Betreibern & Topos usw, Routenanzahl, Schwierigkeitsbereich, usw. also vom grundlegenden Ansatz her ähnlich wie bei DAV Felsinfo http://www.dav-felsinfo.de/html/index.p … Itemid=347 nur halt global und nicht nur für DE. Für die Details (Routenverlauf, wie viele Haken, usw) benutzen Kletterer wohl auf absehbare Zeit Führer/Topos, egal ob Papier oder Online, schon allein weil diese Detailfülle realistisch betrachtet nicht so schnell in OSM rein kommen wird, wenn wir (die OSM-Community) innerhalb von Jahren nichtmal grundlegende Mapping-Konventionen fürs Klettern zuwege bringen... Schon eine solche Aufteilung/Kooperation habe ich bspw. bei Langlauf (xctrails.org) als ausgesprochen hilfreich zu schätzen gelernt und hätte auch keinerlei Problem damit, wenn sie ein Dauerzustand wäre! 🙂

So, genug Text für 1 Posting 😉 aber das will noch "raus": Ich finde toll, hier ein paar Leute gefunden zu haben, die das Thema OSM + Klettern aktiv voran treiben wollen! 🙂
Viele Grüße aus Freiburg, Georg

Also ich hab es mittlerweile etwas aufgegeben OSM zum Klettern zu verwenden (fürs Bergsteigen, Zustiege etc. natürlich nicht).

Ich kann dir nur http://27crags.com/ wärmstens empfehlen! Es ist natürlich bei weitem nicht vollständig, aber meiner Meinung nach ein super Ansatz!

edit: Ich füge weiterhin Gebiete bei OSM hinzu. Soweit ich weiß werden diese aber nicht auf der Garminkarte verwendet

Moin!

Drazhar wrote:

Ich kann dir nur http://27crags.com/ wärmstens empfehlen! Es ist natürlich bei weitem nicht vollständig, aber meiner Meinung nach ein super Ansatz!t

Danke für den Tipp - ist deutlich besser als alles was ich so kannte 🙂

Exemplarisch drei Sachen, die einen großen Unterschied zu einer Lösung mit bzw. im Geiste von OSM veranschaulichen
1) Du kommst an die zugrunde liegenden Daten nicht dran, kannst die Daten also nicht offline nutzen (mobiles Internet? in Bergen kein/langsamer Empfang oder im Ausland teuer!) und kannst sie auch nicht weiter verarbeiten, bspw. eine Kletterfels-Suche bauen, die sowohl räumliche & kletterspezifische Aspekte berücksichtigt (zB "alle Felsen mit 3 sechsern mit maximal 45min Anfahrt").
2) Bei 27crags.com kann man keine weiteren Informationen hinterlegen, von Zeiten für Kletterverbote (Vogelbrut) über Kommentare (welche Führer das Gebiet abdecken) bis zu Links (Webcam, aktuelle Kletterverbote). Und das nur, weil die Seite dafür keine Felder in der GUI anbietet. In OSM kannst Du das alles dagegen ganz einfach machen; es ist wesentlich flexibler.
3) Schau Dir mal http://27crags.com/crags/paretone/map an - die Karte enthält nichtmal den riesigen Bus-Parkplatz und erst recht nicht den Zustieg (bei OSM hab ich den einfach ergänzt, bei GM geht das aber nicht ohne weiteres), das Satelliten-Bild ist wegen Wolken völlig unbrauchbar, und eine Beschreibung gibt's nicht, einen Verweis auf Details (Website oder Führer) fehlt auch. Ergo: Du hast keine Ahnung, wie Du da hin kommst, und vor Ort ist's auch nicht erkennbar (keine Tafel/Karte/... und jede Menge Wände aber nur 3 zurück versetzte sind gebohrt). Dann schau Dir mal im Vergleich http://www.openstreetmap.org/?lat=44.13 … 28&zoom=17 an. Same same für http://27crags.com/crags/bric-scimarco/map und http://www.openstreetmap.org/browse/node/674079012 Ich habe mit ihnen Kontakt aufgenommen, ob sie eine - in diesen Fällen deutlich nützlichere - OSM Kartenart nicht als dritte Kartenart aufnehmen wollen 🙂

Von daher: Es ist eine gute Seite, die ich sicher nutzen werde, aber sie bietet nicht annähernd so vielseitige Möglichkeiten wie OSM 🙂 Wäre schön, wenn Du an Bord bleiben würdest!

Drazhar wrote:

edit: Ich füge weiterhin Gebiete bei OSM hinzu. Soweit ich weiß werden diese aber nicht auf der Garminkarte verwendet

Zu Garmin kann ich nichts sagen, habe meines vor Jahren verkauft. Bei Locus und anderen mapsforge-basierten Softwares auf Android kann ich die Themes für Vektorkarten einfach anpassen, bspw. habe ich mir damit Loipennamen in die Karten reinrendern lassen (waren nur 2 XML-Elemente einzufügen); fürs Klettern geht das sicher analog. Vielleicht findest Du ja einen ähnlich anpassbaren Renderer, der Garmin-kompatible Karten erstellt? Wenn Mobile Atlas Creator Karten erstellen kann, die zu Deinem Garmin kompatibel sind, bräuchtest Du nur noch eine (ggf. manuell einzufügende) Datenquellen suchen, die Kletter-Sachen rendert.
HTH, Georg

🙂

1) Wie oft braucht man realistisch eine osm Karte wo man sieht wo ein Fels ist und was es dort gibt, ohne jedoch topos zu haben? Spontan im Urlaub irgendwo klettern? Da schau ich meist eh im vor raus was es gibt, dann kann man sich ein topo kaufen oder die 27crags offline speichern 🙂

2) Doch man kann Verbote eintragen. Einfach eine entsprechende mail an access@27crags.com und die tragen das binnen 1 bis 2 tagen ein (siehe z.b Ziegelhausen)

3) Parkplätze kann man eintragen. Zustiege leider noch nicht, das stimmt. Ich hoffe das kommt noch 🙂

Ich finde auch die Ticklist und Todo list super (wie bei 8a.nu nur gibt bei 27crags noch topos) 🙂

Aber du hast schon recht. Ideal wäre eine APP für 27crags mit der man alle Gebiete in einer Gegend offline speichern kann 😉
Und dazu noch eine super genaue und alles beinhaltente osm 😉

Gruß Philip

Edit: wie gut ein Gebiet bei 27crags erfasst ist, liegt auch immer bei der community. Das ist bei Osm nicht anders. Da gibt es kaum detaillierte Beschreibungen.
Bei 27crags kann man alles was man will in einen Hinweis zum Gebiet schreiben. Zum Beispiel "Izier". Da war ich auch zu faul viel zu machen und hab einfach auf einen kostenlosen topo im Internet verwiesen.

Ich denke für den Zweck wäre eine POI-Datei viel sinnvoller. Dazu könnte man sich bspw. sport=climbing von der Overpass-API laden, mit osmconvert alle zu einem Node machen, die osm-Datei dann zu einer gpx-Datei konvertieren (sollte mit gpsBabel gehen) und dann mit dem POILoader von Garmin zu einer gpi-Datei machen und auf dem Gerät deponieren.

schoschi wrote:

climbing:grade:UIAA und climbing:grade:french und so weiter finde ich nicht so schön, weil es viele Keys erzeugt, aber sonst fällt mir keine Lösung ein, wie nebeneinander verschiedene Skalen (zB für Eis, freies, und technisches Klettern) für ein einziges Element in benutzbarer Form umsetzbar wären.

Inzwischen habe ich mehrmals uiaa_scale=* gesehen. Das gefällt mir sehr gut, zumal der Key analog zu sac_scale=* benannt ist.
Fürs Bouldern kann man boulder_scale=* verwenden, usw.

aighes wrote:

Ich denke für den Zweck wäre eine POI-Datei viel sinnvoller. Dazu könnte man sich bspw. sport=climbing von der Overpass-API laden, mit osmconvert alle zu einem Node machen, die osm-Datei dann zu einer gpx-Datei konvertieren (sollte mit gpsBabel gehen) und dann mit dem POILoader von Garmin zu einer gpi-Datei machen und auf dem Gerät deponieren.

Denke ich auch, das ist wohl die simpelste Methode wenn es um Nodes aus OSM geht die in ein Garmin sollen. Schau dir mal diese Anleitung an:
http://gps.maroufi.net/gpi-pois.shtml

Dort etwas nach unten scrollen zu "POIs aus Openstreetmap"

Schöne Grüße
unixasket

fkv wrote:

Inzwischen habe ich mehrmals uiaa_scale=* gesehen. Das gefällt mir sehr gut, zumal der Key analog zu sac_scale=* benannt ist.

Ja, damit wäre eine gewisse Konsistenz gewahrt. Dafür könnte man nicht mehr nach Elementen suchen, die irgendeine Bewertung enthalten (climbing:grade:*), und man hätte in der Eigenschaften-Liste eines Elements man nicht alle Skalen als ein Block (weil alle den gleichen Präfix climbing:grade:* haben) sondern verstreut zwischen den anderen Tags (climbing:french_scale oben, dazwischen alles Mögliche, climbing:uiaa_scale unten), wobei wohl nur selten mehr als 2-3 Skalen angegeben werden dürften. Gerade das mit dem Suchen finde ich ein gewichtiges Argument, auch, weil man dann bspw. in Renderern mit nur einer einzigen Angabe für alle Skalen die Schwierigkeit als Text ausgeben lassen könnte.

Das ist ja eine reine Sache der Darstellung der Editoren. 😉

Drazhar wrote:

3) Parkplätze kann man eintragen. Zustiege leider noch nicht, das stimmt. Ich hoffe das kommt noch 🙂
...
Aber du hast schon recht. Ideal wäre eine APP für 27crags mit der man alle Gebiete in einer Gegend offline speichern kann 😉
Und dazu noch eine super genaue und alles beinhaltente osm 😉

Hm. Was ich ideal ansehen würde: 27crags & Co würden all die Kletter-Community-Aspekte speichern (Favoriten, Empfehlungen, Fotos, etc pp) und OSM die Wegeinformation - es ist wenig nützlich, wenn auf 27crags jemand den Zustieg als way in die Karte eingetragen hat, die Routing-Software aber auf OSM-Daten beruht daher den Zustieg nicht finden kann, und Du im Gelände auch "nur" eine OSM Karte hast. Stell Dir vor, 27crags würde im Kartenfenster direkt OSM mit Potlach anbieten, um Zustiege & POIs wie Quellen, Toiletten usw. zu ergänzen/korrigieren! Das ergäbe maximalen Nutzen und die geringste Hürde (Nutzer könnten alles an einer Stelle bearbeiten, egal ob 27crags- oder OSM-Daten).

Ich hab soweit ich weiß mal als Anregung an 27crags gegeben, dass sie OSM Karten zusätzlich zu Google anbieten sollen, da diese oft gerade bei Zustiegen genauer sind und kostenlos.

Aber ich denke die sind relativ langsam mit der Weiterentwicklung 😉
Evtl kann sich ja jemand, der Plan davon hat, anbieten etwas in die Richtung aus zu helfen 🙂

Drazhar wrote:

Ich hab soweit ich weiß mal als Anregung an 27crags gegeben, dass sie OSM Karten zusätzlich zu Google anbieten sollen, da diese oft gerade bei Zustiegen genauer sind und kostenlos. Aber ich denke die sind relativ langsam mit der Weiterentwicklung 😉

Auch ich habe sie angeschrieben. Einige Anregungen, meist "kleine" Verbesserungen, haben sie in wenigen Tagen umgesetzt, und auch an der Seite mit den Karten wollen sie etwas machen, wobei ich gut verstehen kann, dass das etwas länger dauert, weil es in 2 Hinsichten "etwas Größeres" ist
1) Einbindung von OSM als Karte - aber welches der x Render-Themes sollen sie nehmen? In der Standard-Karte tauchen einige relevante Dinge nicht auf, u.a. Kletter-Spots. Wie ist die Performance welches Tile-Servers? Und wie sollen die Overlays aussehen? Usw. Die Vielfältigkeit & Offenheit von OSM macht OSM nicht nur mächtig, sondern auch aufwendig.
2) Wahrscheinlich gibt zu weitergehender Verbindung zwischen 27crags und OSM zunächst eine 27crags-interne Diskussion, insbesondere welche Daten bei ihnen und welche bei OSM liegen sollen - die Daten & User sind schließlich das Kapital einer Website. Gut fände ich, wenn die Zustiegs-Infos komplett in OSM lägen, und Potlach direkt innerhalb 27crags verfügbar wäre 🙂 So könnten beide Seiten sich auf ihre Stärken fokussieren (OSM Karteninformationen / 27cras Climbing-Community) und Nutzer könnten mit Zustiegs-Daten richtig viel machen (offline nutzen, Routenplaner von daheim bis zum Fels nutzen,...).

Servus!

Wie gehts nun weiter? Ich hab jetzt zwei Klettergebiete eingetragen und denke das alles drin ist um ein Gebiet zu beschreiben!

Grüße

Was soll weiter gehen?
Einfach immer fleißig eintragen und hoffen das sich noch mehr Leute anschließen 😉

Evtl noch zusätzlich auf 27crags mit helfen und dort auch hoffen 😄

Also ist das so schon angenommen?

Der Zweck dieses Vorschlags ist, in überschaubarer Zeit ein einigermaßen einheitliches Tagging....

Im englischen steht noch nix drin...

Gogul wrote:

Also ist das so schon angenommen?

Der Zweck dieses Vorschlags ist, in überschaubarer Zeit ein einigermaßen einheitliches Tagging....

Im englischen steht noch nix drin...

Moin, auch ich habe nach Eintragen von einigen Klettergebieten das Gefühl, dass das vorgeschlagene Tagging-Schema sinnvoll ist und mir fehlte bislang auch nichts Wichtiges. Wenn niemand anderer Ansicht ist, könnten wir den Vorschlag in die "größere Runde" geben, also auf englisch und als proposed feature eintragen - den genauen Prozess kenne ich nicht und werde die nächsten 1,5 Monate auch keine Muße haben, mich da reinzuarbeiten. Wenn jemand anders das tun mag: Gern 🙂
Georg

Was mir noch eingefallen ist:
Evt. macht es noch Sinn zu beschreiben ob die Routen mit Umlenkern/Umlenkrollen bestückt sind, also in die Richtung climbing:top_carabiner=all, most, few, no; wobei ich nicht weiß ob top_carabiner der richtige Begriff ist...
Kann man bei der Routenazahl auch ein "c.a." angeben?
Ich kann mal schaun ob ich Zeit finde das ins Englische zu übertragen.
Grüße

Hallo zusammen,

ich habe ein paar Felsen in meiner Umgebung getagt und möchte gerne auf overpass-turbo.eu/s/1xO hinweisen. Damit kann man leicht eine Kletter Gegend erkunden oder tags in osm ergänzen. Auf der Karte sind Klettergebiete mit vielen Routen mit einem größeren Kreis dargestellt und Kletterhallen in blauer Farbe. Von overpass turbo kann man auch leicht kml oder gps Dateien exportieren, die sich dann auf dem Handy offline nutzen lassen ( z.B.: Oruxmaps, Locus oder Google Earth).

Wie sieht für mich die perfekte Welt aus:
Jedes Klettergebiet hat eine weltweit eindeutige ID (z.B. id="DAV:1274" für Hainstadt im Odenwald). Diese ID ist in OpenStreetMap getagt. Weitere Infos sind nicht getagt sondern liegen bei anderen Diensten. Es gibt Apps/Dienste die von OpenStreetMap die Klettergebiets'ID abfragen und mit Daten von anderen Diensten wie DAV Felsinfo oder 27crag verbinden.

Wie sieht für mich eine mögliche praktische Welt aus:
wir taggen in unserer Umgebung z.b: für Hainstadt im Odenwald nur:
website=http://felsinfo.alpenverein.de/felsinfo/odenwald/hainstadt/1274
plus
url=http://27crags.com/crags/hainstadt
und wir pflegen die Kletter Infos beim DAV und bei 27crags & wir bauen uns eine App die das kombiniert. Eine solche App wird zwar erstmal nicht leicht, da weder DAV noch 27crags ihre Daten einfach per api zugänglich machen, aber dennoch denkbar. Falls genug dieser links eingetragen sind, dann sind sie bestimmt hilfreich,da sie von fast allen apps im OSM Umfeld dargestellt werden. Grundsätzlich kann ich so eine App programmieren, die Wetterinfos, Anfahrtszeiten und OSM links mischt.
Was meint Ihr ?

Viele Grüße
Martin

Hallo zusammen,

Da sport=climbing in OSM ja nach wie vor nicht gerendert wird habe ich am Wochenende angefangen eine Website mit einer Kletterkarte zu machen. Von der Funktionalität her wird sich das nicht so sehr von der oben von mktravel geposteten Karte unterscheiden - bloß dass es für Endanwender gedacht ist und schöne Icons etc. enthält 😉

Die Daten kommen aus der oben bereits erwähnten overpass API und werden dynamisch mit leaflet.js über die Standard OSM Karte gelegt. Je nach Kletterart (climbing:sport/climbing:bouldering/..) wird ein unterschiedliches Symbol angezeigt, wenn man drauf klickt bekommt man mehr Infos dazu.
Die Karte ist noch in Arbeit, aber ich werde hier einen Link posten, sobald sie soweit ist...

vorgeschlagene Tagging-Schema sinnvoll ist und mir fehlte bislang auch nichts Wichtiges

Mir ist aufgefallen, dass viele Hochseil-/Klettergärten mit sport=climbing getaggt sind. Das ist im bisherigen Tagging-Vorschlag nicht berücksichtigt. Entweder man sollte ein sport=ropes_course (teilw. sowiso schon verwendet) einführen, oder bei sport=climbing noch mit climbing:ropes_course=yes unterscheiden.

Jedes Klettergebiet hat eine weltweit eindeutige ID

IDs?!? Für jeden kletterbaren Felsen in der ganzen Welt?

Weitere Infos sind nicht getagt sondern liegen bei anderen Diensten

Davon halte ich nichts. Die Daten bei DAV/27crag/.. sind nicht unter freier Lizenz verfügbar. Es macht daher durchaus Sinn grundlegende Infos, wie z.B. Kletterart (Sport/Bouldern/Trad/...) in OSM zu erfassen.

Viele Grüße,
Benedikt

bstegmaier wrote:

....
Mir ist aufgefallen, dass viele Hochseil-/Klettergärten mit sport=climbing getaggt sind. Das ist im bisherigen Tagging-Vorschlag nicht berücksichtigt. Entweder man sollte ein sport=ropes_course (teilw. sowiso schon verwendet) einführen, oder bei sport=climbing noch mit climbing:ropes_course=yes unterscheiden.

Ich würde sport=ropes_course bevorzugen. Es sollte dann aber schnell im Wiki geändert werden - sonst wir es immer mehr *=climbing. Und wenn möglich in OSM geändert werden, weil nicht nur ich nach einem bereits passenden Objekt suche und diese Schlüssel/Werte übernehme.

sport=climbing noch mit climbing:ropes_course=yes

+1

Grüße,
Chris (Der noch keinen Seilkurs gesehen hat wo nicht auch geklettert wird)

geri-oc wrote:

Ich würde sport=ropes_course bevorzugen.

Ich auch, weil es mit Sport(fels)klettern an sich ja wenig zu tun hat.

bstegmaier: schöne Icons

gehen auch in http://overpass-turbo.eu/s/1yp - auch wenn das Icon nicht so schön ist

bstegmaier: climbing:ropes_course=yes

+1

bstegmaier wrote:

mktravel wrote:

Wie sieht für mich die perfekte Welt aus: Jedes Klettergebiet hat eine weltweit eindeutige ID

IDs?!? Für jeden kletterbaren Felsen in der ganzen Welt?

Von der Anzahl her sind das nichtmal kleine Krümel im Vergleich zum Kuchen aller Nodes in OSM 🙂 und letztlich vergibt OSM bereits IDs für alle Kletterfelsen weltweit (die Node-/Way-Nummer). Allerdings bezweifle ich, dass andere diese verwenden werden, während weltweit genutzte IDs mir sehr realistisch erscheinen, wenn die großen Alpenvereine oder IG Klettern sich darauf verständigen und die ID-Vergabe regeln (bspw. ein zentraler ID-Server der IDs aus WSG84-Koordinaten generiert, technisch und finanziell nix Dolles). Durch solche IDs sehe ausgesprochen viele Möglichkeiten, weil ich mit der Schweizer EGID, BAKOM-Flat-ID usw. arbeite und deren Vorteile bei der Business2Business-Kommunikation mitbekomme -- die IDs würden völlig neue Möglichkeiten schaffen, bspw. zuverlässige Suche nach allen Papier-Kletterführern mit diesem Fels (selbst in fremden Sprachen!), einfache vollautomatische Aggregation der Daten aus verschiedeen Diensten (OSM/DAV-Felsinfo/27crags/usw),...
Wenn jemand einen Draht zu entsprechenden Ansprechpartnern bei DAV, OeAV o.ä. hat, bitte mal anfragen 🙂

bstegmaier wrote:

mktravel wrote:

Weitere Infos sind nicht getagt sondern liegen bei anderen Diensten

Davon halte ich nichts. Die Daten bei DAV/27crag/.. sind nicht unter freier Lizenz verfügbar. Es macht daher durchaus Sinn grundlegende Infos, wie z.B. Kletterart (Sport/Bouldern/Trad/...) in OSM zu erfassen.

Das mit den Linzenzen ist ein wichtiger Aspekt: Die Daten könnten bspw. leider nicht einfach so für selbstgemachte Gebietsführer, Flyer, eine App oder gar "konkurrierende" Webseiten genutzt werden. 🙁
Ein anderer Aspekt: Es bringt wenig, wenn Daten online von irgendwo gezogen werden könnten, ich am Fels bzw. an der Hütte aber keinen Empfang habe -- die zentralen Daten (also für eine nützliche Kartendarstellung relevante Daten wie bspw. Name, Typ der Kletterei (für Icons), vielleicht Schwierigkeitsbereich (wie Farbe bei Skipisten) u.ä.) sollten wie von bstegmaier geschrieben in den OSM-Daten drin sein, die man ja bereits problemlos offline in Locus usw. verwenden kann. Zusatzdaten wie Bewertungen, Wetter usw. sollten dagegen in spezialisierten Diensten ausgelagert sein; die machen in Kartendaten nicht viel Sinn.

mktravel wrote:

Wie sieht für mich eine mögliche praktische Welt aus: wir taggen in unserer Umgebung z.b: für Hainstadt im Odenwald nur website=http://felsinfo.alpenverein.de/felsinfo/odenwald/hainstadt/1274 ... und wir pflegen die Kletter Infos beim DAV und bei 27crags & wir bauen uns eine App die das kombiniert. ... Grundsätzlich kann ich so eine App programmieren, die Wetterinfos, Anfahrtszeiten und OSM links mischt. Was meint Ihr ?

Die zentralen Daten sollten wegen Offline-Fähigkeit, Kartendarstellung usw (siehe oben) IMHO in OSM drin sein, denn Du willst wohl kaum Locus nachbauen ;-)
Sinnvoll fände ich eine App, die spezifische Kletter-Daten zwischenspeichert, also ein "Offline-Reader" für 27crags o.ä. und dazu optimaler Weise offline Datenerstellung (Topo-Zeichnung, Ticklist, usw.) die beim nächsten Netzempfang hochgeladen wird. Diese App würde dann Locus usw. für die Kartendarstellung, Navigation usw. aufrufen und optimalerweise auch von denen aufgerufen werden können (zB per Add-On, das Koordinaten und ggf. Ausrichtung an die App weitergibt, die nach entsprechenden Detail-Kletterinfos sucht). Für die App wären mit 27crags oder anderen Datenquellen lizenzrechtliche Aspekte zu klären, wobei ich mir gut vorstellen kann, dass der DAV und/oder 27crags sowieso gerne eine App hätten, sie lediglich nicht auf die Beine gestellt kriegen, und Dich daher vielleicht sogar unterstützen, bspw. eine API anbieten. Freundlich nachfragen kann man ja mal 🙂

gormo wrote:

geri-oc wrote:

Ich würde sport=ropes_course bevorzugen.

Ich auch, weil es mit Sport(fels)klettern an sich ja wenig zu tun hat.

Direkt beim Tag sport oder leisure einen eigenen Wert für Hochseilgärten (zB high_ropes_course) zu setzen finde ich auch besser, und das sieht der Vorschlag http://wiki.openstreetmap.org/wiki/Prop … ope_course ja auch schon so vor.

chris66 wrote:

sport=climbing noch mit climbing:ropes_course=yes

+1
Grüße, Chris (Der noch keinen Seilkurs gesehen hat wo nicht auch geklettert wird)

Nach meiner Erfahrung wird in vielen Hochseilgärten nur wenig (nahe gar nicht) geklettert, sondern vor allem Leitern hochgestiegen, über wacklige Elemente gelaufen und Seilrutschen entlang gesaust usw. Entsprechend sind im Vergleich zum Klettern die Bewegungsabläufe sehr anders, ebenso die Anforderungen, die Zielgruppen und Rahmenbedingungen (meist kein eigenes Material erlaubt, oft nur unter Aufsicht erlaubt,...). Es gibt mehr Gemeinsamkeiten mit Klettersteigen (Leitern, Seilbrücken usw. gibt's auch da), aber auch hier sind die Unterschiede recht groß. Daher finde ich wenig sinnvoll, Hochseilgärten als eine Spezialisierung von Klettern zu taggen, und deutlich sinnvoller, einen eigenen Wert für den Tag Sport "Hochseilgärten" zu haben -- so wie es für Tennis und Badminton auch getrennte Werte gibt 🙂

gormo wrote:

geri-oc wrote:

Ich würde sport=ropes_course bevorzugen.

Ich auch, weil es mit Sport(fels)klettern an sich ja wenig zu tun hat.

Der Meinung bin ich auch. Außerdem ist von dem http://wiki.openstreetmap.org/wiki/DE:T … 3Dclimbing so gut wie nichts für (Hoch-)Seilgärten anwendbar. Es gibt keinen Fels sondern idR Bäume, keine Schwirigkeitsgrade in den üblichen Kletterskalen, die Absicherung erfolgt ganz anderst, etc.

Ich habe ein Proposal vom Juni entdeckt, das eine weitere Variante vorschlägt:
http://wiki.openstreetmap.org/wiki/Prop … ope_course

Die Statistik der unterschiedlichen tags laut tagwatch:
26x sport=ropes_course
11x leisure=high_ropes_course
8x leisure=ropes_course
1x sport=high_ropes_course
+unbestimmbare Anzahl an sport=climbing tags

4700

chris66 wrote:

4700

Das sind jetzt aber alle sport=climbing Tags, oder? Für die Hochseilgarten-Frage wäre interessant den Anteil der der Seilgärten an diesen 4700 zu kennen...

Nahmd,

bstegmaier wrote:

chris66 wrote:

4700

Das sind jetzt aber alle sport=climbing Tags, oder? Für die Hochseilgarten-Frage wäre interessant den Anteil der der Seilgärten an diesen 4700 zu kennen...

Die kannst Du zum Teil nur am Namen erkennen. 🤔
Da hilft nur die 4792 Einträge herunterladen und sichten.

Gruß Wolf

Ich habe gerne eine bildliche Vorstellung von meiner (Kletter) Umgebung und dem proposal.

Deshalb habe ich alle Hochseilgärten in meiner Umgebung auf leisure=high_ropes_course und alle Kletterhallen auf leisure=sport_centre getagged.
Zum Veranschaulichen habe ich mit overpass turbo eine Karte aller Kletterfelsen erstellt, wobei die Hochseilgärten und Kletterhallen ausgeblendet werden: http://overpass-turbo.eu/s/1zd
Mit overpass turbo ist auch möglich nur die Kletterhallen oder Hochseilgärten anzuzeigen (dazu im overpass turbo link entsprechend aus/einkommentieren).

Ich finde so kann man gut die Lücken im Entwurf testen und die Logik für mögliche Apps oder Karten testen.
z.B. ist mir http://www.openstreetmap.org/browse/node/2378569097 aufgefallen, da ist wohl ein Kinderspielplatz als sport:climbing gesetzt(ich war selbst nie dort vor Ort). Keine Ahnung ob wir das noch im Entwurf berücksichtigen sollen., aber schaut Euch doch mal in Eurer Gegend um.

Etwas möchte ich noch loswerden: wenn man eine Statistik macht, dann sollte man in der Regel Mittelwert + Min + Max oder Mittelwert +Standardabweichung angeben.
Entweder wir geben für jeden Klettergrad die Anzahl der einzeln Routen an, z.B.
climbing:grade:UIAA:V:4 (4 Routen im Grad V)
climbing:grade:UIAA:VI:2 (2 Routen im Grad VI) mit an
oder ergänzen zu den climbing:grade:UIAA:min und climbing:grade:UIAA:max noch climbing:grade:UIAA:std für die Standardabweichung
... nur so als Vorschlag

Viele Grüße
Martin

nanu, meine natürlich zu den climbing:grade:UIAA:min und climbing:grade:UIAA:max noch climbing:grade:UIAA:mean für den Mittelwert
(oder ersetzen min,max durch mean und std)

mktravel wrote:

...
Deshalb habe ich alle Hochseilgärten in meiner Umgebung auf leisure=high_ropes_course ....

Find es mit sport=high_ropes_course besser, da die meisten Hochseilgärten in Wäldern liegen. Sollte es tatsächlich einer mit Stangen sein, wäre eine Fläche mit leisure=* und sport=high_ropes_course angebracht.

Bei Hallen würde ich

building=yes
leisure=sport_centre
sport=climbing oder sport=high_ropes_course

nutzen. Es gibt Kletter-Seil-Hallen aber auch welche mit künstlichen Kletterwänden.

Ja, so richtig glücklich bin ich mit den Hochseilgärten auch noch nicht. Ich habe das tag leisure=high_ropes_course deswegen genommen, weil es so im proposal (http://wiki.openstreetmap.org/wiki/Prop … ope_course) drinsteht.

geri-oc wrote:

Find es mit sport=high_ropes_course besser, da die meisten Hochseilgärten in Wäldern liegen.

sport=high_ropes_course finde ich auch besser, schade das es so nicht im proposal ist.

Ich bringe noch eine dritte Variante ein. Wir taggen Hochseilgärten mit climbing:sport=no und auch alles andere unter sport=climbing was nicht wirklich Freiklettern ist. Das ist konform zu http://wiki.openstreetmap.org/wiki/DE:T … 3Dclimbing und sollte später auch einfach von offline Karten oder Apps ausgewertet werden können.

geri-oc wrote:

Find es mit sport=high_ropes_course besser
...
Bei Hallen würde ich
building=yes
leisure=sport_centre
sport=climbing oder sport=high_ropes_course
nutzen. Es gibt Kletter-Seil-Hallen aber auch welche mit künstlichen Kletterwänden.

Meinst Du das "oder" als "logisches oder" oder "entweder oder"? 🙂 Das ist wichtig; es gibt Hallen, die mehrere Sportarten anbieten. Ich sehe folgende Möglichkeiten
1) verschiedene Tags nutzen: Klettern und oben Hochseilgarten durch leisure=high_ropes_course und sport=climbing taggen. Das Potenzial dieser Variante ist bei 2-3 Sportarten ausgeschöpft.
2) für einen Tag mehrere Werte nutzen, also sport=climbing;high_ropes_course - das beherrschen AFAIK so einige Programme für Weiterverarbeitung von OSM-Daten nicht gut, und in der Darstellung wird üblicherweise nur eine Sportart per Icon angezeigt (statt mehrere Icons für ein einziges Objekt).
3) für jede Sportart einen eigenen Node oder Polygon innerhalb des building-polygons erstellen. Schön, weil beliebig viele Sportarten möglich sind, damit alle Programme zurecht kommen, und alle Sportarten per Icon dargestellt werden können. Zu vernachlässigen ist IMHO dass das ggf. nicht akkurat wäre, weil die nodes nebeneinander wären (lassen sich in JOSM usw sonst ganz schlecht handhaben), auch wenn die Sportarten übereinander gemacht werden (zB unten Fitness oben Hochseil). Der Ansatz ist insofern akkurat, als dass die Tags seltenst wirklich zum Gesamt-Gebäude gehören, sondern meist nur an bestimmten Bereichen im/am Gebäude zu verorten wären.

Ich fände 3) sinnvoll - skaliert gut, einfach & praktikabel, ohne konzeptionell nennenswert "unsauber" zu sein. Ob sport oder leisure = high_ropes_course ist mir völlig egal, es ist ja zum größten Teil sportliche leisuretime ;-) außer für die wenigen, die dort arbeiten.

mktravel wrote:

Ja, so richtig glücklich bin ich mit den Hochseilgärten auch noch nicht. Ich habe das tag leisure=high_ropes_course deswegen genommen, weil es so im proposal (http://wiki.openstreetmap.org/wiki/Prop … ope_course) drinsteht. sport=high_ropes_course finde ich auch besser, schade das es so nicht im proposal ist.

Ist ja ein Proposal - schreibe doch auf der Diskussionsseite, was aus Deiner Sicht den für/gegen sport und leisure spricht. Dann können andere ihre Sicht ergänzen und am Ende haben wir einen gut begründeten Favoriten 🙂

mktravel wrote:

Ich bringe noch eine dritte Variante ein. Wir taggen Hochseilgärten mit climbing:sport=no und auch alles andere unter sport=climbing was nicht wirklich Freiklettern ist. Das ist konform zu http://wiki.openstreetmap.org/wiki/DE:T … 3Dclimbing und sollte später auch einfach von offline Karten oder Apps ausgewertet werden können.

Ich sehe Hochseilgärten nicht als einen Typ von Kletterei, Begründung siehe Post #67.
Wenn die Mehrheit sagen sollte, dass Hochseilgärten ganz klar eine von vielen Kletter-Varianten ist, sollte nicht climbing:sport=no gesetzt werden (bei vielen yes/no-Tags wird "no" angenommen wenn nichts gesetzt wurde) weil wir dann auch alle anderen Klettervarianten auf no setzen müssten, um einen Hochseilgarten zu taggen, sondern es müsste umgekehrt climbing:high_ropes_course=yes gesetzt werden, weil das eindeutig ist UND wir dann auch ausdrücken können, dass es irgendwo einen Hochseilgarten mit Freikletter-Elementen und Bouldern gibt 🙂

mktravel wrote:

Etwas möchte ich noch loswerden: wenn man eine Statistik macht, dann sollte man in der Regel Mittelwert + Min + Max oder Mittelwert +Standardabweichung angeben.
Entweder wir geben für jeden Klettergrad die Anzahl der einzeln Routen an, z.B.
climbing:grade:UIAA:V:4 (4 Routen im Grad V)
climbing:grade:UIAA:VI:2 (2 Routen im Grad VI) mit an
oder ergänzen zu den climbing:grade:UIAA:min und climbing:grade:UIAA:max noch climbing:grade:UIAA:std für die Standardabweichung
... nur so als Vorschlag

Puh...ganz ehrlich, das wäre mir zu aufwendig 🙄 Ich schau gern nach dem niedrigsten und höchsten Grad und trage den ein, aber von allen 20, 50 oder 100 Routen die Grade aufzuaddieren und durch die Anzahl zu teilen ist mir dann doch zu aufwendig. 😐

Ein optionales climbing:grade:UIAA:mean können wir von mir aus vorsehen, aber bei einer "Pflichtangabe" fürchte ich einfach, dass dann kaum noch jemand taggen mag - und mir ist wichtig, dass überhaupt Kletterfelsen in OSM rein kommen, denn bislang fehlt der größte Teil an Felsen: Selbst im OSM-freudigen Deutschland sind bspw. in der Frankenjura mit vielen Studenten (sind tendenziell oft Mapper) laut http://overpass-turbo.eu/s/1zT bloß rund 120 Climbing-Objekte vorhanden, dabei gibt es allein 68 Gebiete/Orte in http://www.frankenjura.com/klettern/panorama mit jeweils bis zu rund 20 Felsen und in Summe mindestens 300 (mehr gibt die Suche nicht zurück), d.h. in OSM fehlt der Großteil der Felsen... Dass in Finale Ligure (am Mittelmeer in Italien) laut http://overpass-turbo.eu/s/1zW bloß 58 Climbing-Objekte erfasst sind, spricht für eine geringe Erfassungsquote, denn da wimmelt es nur von kletterbaren Kalkwänden - in 20-30 Minuten Zustieg kommt man leicht an 5-10 anderen Wänden mit Haken vorbei und muss erstmal rausfinden, welche welche ist...Luxusproblem 😄

schoschi wrote:

es gibt Hallen, die mehrere Sportarten anbieten. Ich sehe folgende Möglichkeiten
1..2..3..

Das könnte evtl. auch gehen:
4) sport=multi, climbing:sport=yes, ..

Laut Vorschlag in der Wiki soll climbing:length=* die durchschnittliche Routenlänge angeben.

Das macht finde ich, wenig Sinn: Viele relevanter für die Entscheidung welches Seil man mitnimmt, ist eher die maximale Routenlänge. Dementsprechend ist in den meisten Kletterführern auch die maximale Wandhöhe und eventuell noch die minimale angegeben.

Ich würde daher eine der folgenden Varianten vorschlagen:
a) climbing:length gibt die maximale Routenlänge an
b) climbing:length:max und climbing:length:min geben einen Bereich an

Was meint ihr?

bstegmaier wrote:

..Routenlänge...Wandhöhe...

Hm, da muss ich mich selbst an der Nase packen. Man muss vorsichtig sein, dass man diese zwei Begriffe nicht miteinander vermixt!
Gemeint war in meinem Post immer 'Routenlänge'.

Ich habe mich im wiki von osm angemeldet und sowohl http://wiki.openstreetmap.org/wiki/Prop … ope_course also auch http://wiki.openstreetmap.org/wiki/Prop … ope_course angepasst so wie es mir möglich war. Ebenso hab ich die Hochseilgärten in meinem Gebiet umgetagged.

Was sind Pflichtabgaben? Alle tags sind doch optional: http://wiki.openstreetmap.org/wiki/DE:Map_Features

OpenStreetMap lässt prinzipiell alle möglichen Schlüssel und Werte zu. Trotzdem ist es natürlich für die Anwendung der OSM-Daten von Vorteil, wenn Einigkeit darüber herrscht, welche Basiseigenschaften durch welche Datenrepräsentation ausgedrückt werden.

Für mich ist es schon relevant was ich hauptsächlich in einen Klettergebiet erwarten kann, eher UIAA 4-5 oder 7-8. Das kann ich bei min 1 und max 10 nicht sehen.

bstegmaier wrote:

Da sport=climbing in OSM ja nach wie vor nicht gerendert wird habe ich am Wochenende angefangen eine Website mit einer Kletterkarte zu machen.

Die Karte ist jetzt vorerst hier verfügbar:
http://openclimbingmap.bstegmaier.de/

Name, Schwierigkeitsgrad, Orientierung, etc. werden falls vorhanden beim Klick auf das Kletter-Symbol angezeigt.
(edit)Die Daten werden mit Hilfe der Overpass API geladen - diese ist nicht besonders schnell. Es kann also einige Sekunden dauern, bis alle Klettergebiete angezeigt werden.(/edit)

Zur Zeit werden nur sport=climbing nodes angezeigt, ways fehlen noch. Aber daran werde ich noch arbeiten...

Habe den Wiki-Eintrag jetzt nochmal abgeändert: mit climbing:length=* kann man (wie bisher auch) die durchschnittliche Länge angeben... zusätzlich können aber mit climbing:length:min=* die minimale und, ganz wichtig, mit climbing:length:max=* die maximale Länge genauer spezifiziert werden.

Noch etwas grundlegenderes zu den aufgelisteten Kletterarten: Es gibt bisher keine geeignete Möglichkeit um trad climbing/tradional climbing zu taggen. (im Gegensatz zum Sportklettern keine Haken vorhanden, Sicherung erfolgt komplett selbst, siehe englische! Wikipedia)

Theoretisch könnte man climbing:sport=yes zusammen mit climbing:bolted=no verwenden - das funktioniert aber nur so lange ausschließlich trad Routen und keine einzige sport climbing Route vorhanden ist! Außerdem wird in vielen Ländern (z.B. England) rigoros zwischen diesen zwei Kletterarten unterschieden, weswegen dort climbing:sport=yes für trad climbing Routen allein schon vom Begriff her falsch wäre..

Ich schlage daher die Einführung von climbing:trad=* zusätzlich zu den bestehenden Kletterarten vor. Jemand dagegen? 😉

Zur Info: ich habe die sport=climbing Wiki-Seite ins Englische übersetzt.

bstegmaier wrote:

http://openclimbingmap.bstegmaier.de/

🙂 mir gefällt die Karte! Sehr gut ist, wie die Gebiete zusammengefasst werden, falls es mehrere gibt. Habe mich mit der Karte schon mal im Rhein-Main Gebiet umgeschaut und es funktioniert dort gut.

bstegmaier wrote:

Zur Zeit werden nur sport=climbing nodes angezeigt, ways fehlen noch. Aber daran werde ich noch arbeiten...

Mit Overpass kann ich helfen, falls Du da Unterstützung brauchst.

Viel Arbeit war wohl auch die Übersetzung im Wiki und die Arbeit an den Details wie climbing:trad, die ich unterstützten möchte. Ich finde es gut ,dass es mit dem Wiki eine Übersicht gibt, die hier im Forum manchmal verloren geht( mir gehts jedenfalls so). Bin selber auch ohne Haken geklettert und mir fällt erstmal auch nichts Besseres als climbing:trad zur Unterscheidung ein.

Ich habe den englischen Entwurf nicht gleich gefunden und setzt mal hier den Link rein http://wiki.openstreetmap.org/wiki/Tag:sport%3Dclimbing

Es gibt auch noch in diesem Post den Vorschlag, die Klettergrade analog zu sac_scale=* als uiaa_scale=* einzutragen. Mir scheint das einfacher und ich bin dafür das noch zu ändern (im Wiki und den tags). Sobald ich dazu komme, mach ich das dann.

Für den praktischen Erfolg glaube ich, dass es wichtig ist, noch gute und schlechte Beispiele in das wiki mit einzubringen.
Es gibt derzeit die Probleme mit Klettergärten und Kinderspielplätzen, die im Sinne von Klettern als Sport falsch getagged sind.
Sobald ich dazu komme, sieht man es im wiki.

mktravel wrote:

mir gefällt die Karte!

danke 🙂

mktravel wrote:

Mit Overpass kann ich helfen, falls Du da Unterstützung brauchst.

danke für das angebot! inzwischen hab ich rausgefunden wie die query und die verarbeitung der daten aussehen muss. es werden jetzt auch ways mit sport=climbing angezeigt...
was noch etwas stört, ist, dass die anfragen an die overpass api relativ lang dauern. wenn du da ne idee hast, wäre ich dankbar.

mktravel wrote:

Es gibt derzeit die Probleme mit Klettergärten und Kinderspielplätzen, die im Sinne von Klettern als Sport falsch getagged sind.

Unter leisure=playground und playground=* steht, wie man Spielplatzgeräte taggen soll. Leider fehlen dort die oft auf Spielplätzen anzutreffenden Mini-Kletterwände, weswegen die wohl auch in Zukunft oft mit sport=climbing getaggt werden. Vermutlich wäre es sinnvoll das Spielplatz tagging Schema um playground=climbingwall (ohne Unterstriche, damit konsistent mit den anderen Geräten) zu erweitern?

bstegmaier wrote:

was noch etwas stört, ist, dass die anfragen an die overpass api relativ lang dauern. wenn du da ne idee hast, wäre ich dankbar.

option 1) leicht: anderen overpass server benutzen und schauen ob der schneller ist z.B. http://overpass.osm.rambler.ru/ hat bessere hardware
option 2) schwer: parallele Programierung, die Bounding Box in 4 Bounding Box unterteilen und parallel abfragen und dann Ergebnisse zusammen fügen, habe leider keinen Beispiel code dafür
option 3) schwer: caching, selber jede Nacht die Felsen abfragen und als Datei speichern, dann in dieser Datei suchen, habe leider keinen Beispiel code dafür

Unter leisure=playground und playground=* steht, wie man Spielplatzgeräte taggen soll. Leider fehlen dort die oft auf Spielplätzen anzutreffenden Mini-Kletterwände, weswegen die wohl auch in Zukunft oft mit sport=climbing getaggt werden. Vermutlich wäre es sinnvoll das Spielplatz tagging Schema um playground=climbingwall (ohne Unterstriche, damit konsistent mit den anderen Geräten) zu erweitern?

So eine Ergänzung zu playground=climbingframe wär ganz gut, vielleicht begeistern sich dann Klettereltern dafür so etwas zu taggen.
Ich brauche eine bessere Vorstellung davon. Ich habe einen solchen Spielplatz via OSM in meiner Umgebung gefunden und werde das nächste mal auf dem Weg zu Kletterhalle mal einen Umweg machen und ein Foto schießen. Wenn das dann so eine playground=climbingwall ist, dann läßt sich das einfacher als Vorschlag mit reinsetzen.

mktravel wrote:

option 1) anderen overpass server

werd ich mal ausprobieren

mktravel wrote:

option 2) Bounding Box unterteilen und parallel abfragen

das wird schon so gemacht. muss aber bei gelegenheit mal testen, ob das tatsächlich einen Geschwindigkeitsvorteil bringt.

mktravel wrote:

option 3) caching

daran hab ich auch schon gedacht. das hätte auch den vorteil, dass ich die tags davor verarbeiten und anreichern könnte und später bei der darstellung im browser nicht mehr so viele Spezialfälle behandeln muss. Aber den Nachteil, dass es aufwendig ist und nicht in 'Echtzeit' (Ich finds schöner, wenn die Resultate meiner edits sofort auf der Karte sichtbar sind 😉)

Danke für dein Tipps!

mktravel wrote:

Ich brauche eine bessere Vorstellung davon

In der Regel ist das ein 1-2m hohes Brett mit 5-10 Griffen. Oft in Verbindung mit ner Rutsche oder anderen Spielplatzgeräten.
Das hier ist z.B. bei mir in der Nähe:

noch ein Hinweis zu option 3) caching

es gibt im Bereich Langlaufen etwas vergleichbares http://www.xctrails.org/map.html?type=xc
in dem Blog http://www.xctrails.org/blog/?page_id=308 dazu steht:

Die Daten auf XCTrails werden nächtlich aus der Openstreetmap-Datenbank aktualisiert.

Und hier gibt es mehr Infos zur Implementierung: http://wiki.openstreetmap.org/wiki/XC_Map_Changelog

local XAPI interface is based on https://github.com/iandees/xapi-servlet

bstegmaier wrote:

In der Regel ist das ein 1-2m hohes Brett mit 5-10 Griffen.

Ich habe die Spielplatz Kletterwand hier https://wiki.openstreetmap.org/wiki/Tal … good_names hinzugefügt. Dein Foto habe ich dazu mit Lizenz = unbekannt verwendet. Ich hoffe das ist so ok. Dort wird u.a. auch Ropes course auf einem Spielplatz gezeigt.

mktravel wrote:

Ich habe die Spielplatz Kletterwand hier Talk:Proposed_features/Playground_Equipment#Put_new_objects_here_to_find_good_names hinzugefügt.

Auf dieser Diskussionsseite hat sich schon seit 2 Jahren nichts mehr getan, aber warten wirs mal ab 😉

mktravel wrote:

Dein Foto habe ich dazu mit Lizenz = unbekannt verwendet.

Klar. Habs die Lizenz auf public domain geändert.

Ich habe das Rhein Main Gebiet so eingetragen das es für mich mit OsmAnd auf dem Handy nutzbar ist. Das heißt fast alle Felsen und Kletterhallen sind drin und alle Seilgärten und Spielplätze draussen.
Wenn man in Osmand die Karte für Hessen lädt und einen Filter auf Sport=Klettern setzt,

dann kann man sich die Klettermöglichkeiten in der Umgebung auflisten lassen:

oder auch auf der Karte darstellen lassen

Wenn man einen der Punkte antippt kann man sich auch die Detailinformationen zum Klettern anschauen (das plugin zum editieren von OSM muss geladen sein)

Für mich ist dass schon nützlich. Vor allem für die Anfahrt zu einem Felsen, wenn ich mal nicht direkt von zu Hause losfahre.
Ich hoffe das ist ein bisschen Motivation, auch weitere Klettergebiete ähnlich einzutragen.

Hallo!

Wie geht ihr denn mit verschiedenen Sektoren eines Klettergartens um?

Grüße

Gogul wrote:

Wie geht ihr denn mit verschiedenen Sektoren eines Klettergartens um?

Bin dafür jeden Sektor einzeln zu taggen. Also die Sektoren nicht zusammenfassen. Gut für die Orientierung wäre es, wenn der Tag an einem Punkt am Eingang in den Sektor hängt.

bstegmaier wrote:

was noch etwas stört, ist, dass die anfragen an die overpass api relativ lang dauern. wenn du da ne idee hast, wäre ich dankbar.

Ich habe jetzt was schnelles gefunden, hier zwei Beispiele:

http://martinkoeller.github.io/ClimbingMap/

Die Daten werden von overpass im json runtergeladen (wget -O target2.osm "http://overpass-api.de/api/interpreter?data=[out:json];node[\"climbing:sport\"];out;way[\"climbing:sport\"];out;>;out;"
). Auf der leaflet Karte werden sie dann einfach per javascript geladen. Es erfolgt dann keine Liveanfrage an overpass. D.h. wenn man die Daten auf der Karte auffrischen will, dann muss man Sie erneut cachen .

😄

mktravel wrote:

Gogul wrote:

Wie geht ihr denn mit verschiedenen Sektoren eines Klettergartens um?

Bin dafür jeden Sektor einzeln zu taggen. Also die Sektoren nicht zusammenfassen. Gut für die Orientierung wäre es, wenn der Tag an einem Punkt am Eingang in den Sektor hängt.

Mit dem selben tag wie ein ganzer Klettergarten? Dann erscheint jeder Sektor als eigener Klettergarten auf den Karten...

Gogul wrote:

Mit dem selben tag wie ein ganzer Klettergarten? Dann erscheint jeder Sektor als eigener Klettergarten auf den Karten...

Jeder Sektor mit einem eigenem Tag. Dann erscheint jeder Sektor als eigener Klettergarten auf Osmand aber in Karten die clustern können ala http://martinkoeller.github.io/ClimbingMap/ oder http://openclimbingmap.bstegmaier.de/ wird es passend zusammengefasst.

Also nein, ein Tag pro Sektor, aber das ist nur meine Meinung. Am besten ich tag mal ein Sektorgebiet (Morgenbachtal oder Schriesheim) so wie ich es für gut halte. Sobald ich es getagt habe melde ich mich noch mal. Oder hat hier jemand ein Vorzeigegebiet ? Im Moment ist bin eher draussen als im Internet, kann also ein bisschen dauern.

Hallo zusammen,

freut mich, dass es jetzt auch Karten fürs Klettern gibt, wie sie für Langlauf, Wandern usw. schon länger existieren. 🙂Natürlich fände ich eine Kombination der beiden am besten 😎 An http://martinkoeller.github.io/ClimbingMap/ gefällt mir, dass bei MouseOver der Felsen-/Gebietsname als Ballon Help erscheint (beschleunigt die Suche nach bestimmtem Felsen und wäre bei Gruppierungen ganz besonders nützlich weil's reinzoomen unnötig wird) und dass auch bei Zoomstufen <12 climbing-Nodes angezeigt werden (so kann ich leichter herausfinden, wo es überhaupt climbing-Nodes gibt). Bei http://openclimbingmap.bstegmaier.de/ finde ich die Detail-Infos schöner & nützlicher (bspw. klickbare Links und vor allem "Edit" denn der ganze gemappte Schmu fällt erst mit Karte richtig auf) und die Icons praktischer, zum einen die Farbe (grau lässt die vielen im Wald liegenden Felsen besser herausstechen) und zum anderen, dass für Wänden/Bouldern/Hallen unterschiedliche Icons existieren.

FYI zur Darstellung in Mapnik: Im Issue https://github.com/gravitystorm/openstr … issues/844 geht es darum, dass Sport-POIs in die OSM-Mapnik-Karte gerendert werden. Dabei wird Climbing nicht mehr explizit aufgeführt, sondern nur über den Link https://trac.openstreetmap.org/ticket/3159 zum Ticket im alten Tracker-System und von dort zum dezidierten Ticket für Climbing https://trac.openstreetmap.org/ticket/2761 - keine Ahnung, ob Climbing im aktuellen Ticket explizit erwähnt werden sollte...kenne die Gepflogenheiten da nicht.

FYI, um den Weg zum Felsen mit dem Handy zu finden: Apps, die mapsforge als Kartenformat nutzen (Locus, Oruxmaps usw.), können mit v2.2.2 des sehr eleganten + detailreichen Themes Elevate auch Climbing darstellen (neben Wanderwegen, Klettersteigen, Klippen, Geröll usw). Bezugsquelle ist http://www.openandromaps.org/kartenlege … hike-theme

Viele Grüße,
Georg

Hallo!

Ich hät mal zwei fragen:
1) Im englischen wiki darf sport=climbing an ways geklebt werden, beim deutschen nicht. Letzteres macht für mich mehr sinn aber das englische geht ja vor, was ist nun richtig?
2) Wie geht das mit dem proposal für Hochseilgärten http://wiki.openstreetmap.org/wiki/Prop … ope_course aus? Kann man das schon benutzen oder muss man das proposal erst nochmal anstupsen?

Danke schonmal!

Also sport=climbing habe ich schon gesehen in den Alpen bei einem Kletterrsteig, ist also ggf. sinnvoll, wobei dies teilweise mit Via ferrata kollidieren könnte.
Im Fall des Wikis vermute ich, dass das deutsche angepasst werden müsste.

Für Hochseilgärten scheint es auch mehrere Möglichkeiten zu geben, siehe Climbing Adventure mit Link auf das genannte Proposal.
Wenn man aufgrund von Taginfo entscheidet, gewinnt climbing_adventure mit 154:0.

Gogul wrote:

Im englischen wiki darf sport=climbing an ways geklebt werden, beim deutschen nicht. Letzteres macht für mich mehr sinn aber das englische geht ja vor, was ist nun richtig?

Der Grund für das Einfügen des Ways war "Using sport=climbing in conjunction with natural rock features like natural=cliff for crags and natural=stone for boulders seems like the most appropriate usage".

Da würde ich lieber entlang des Grates eine climbing=route setzen oder die Wandflächen links und rechts des Grates als Fläche mappen. Steine sind sowieso Punkte oder Flächen. Als Zusatztag zu natural=cliff könnte ichs mir aber schon nützlich vorstellen. Vielleicht auch als Tag einer Aussenmauer eines Hauses (bei 90° hat man es ja schwer mit der Fläche einer Wand von oben gesehen)

R0bst3r wrote:

wobei dies teilweise mit Via ferrata kollidieren könnte.

Davor hätte ich auch Angst. Ein highway=* mit sport=climbing wäre verwirrend, aber man könnte die auch einfach ignorieren. Kletterrouten sind ja schon mit climbing=route als solche gekennzeichnet.

Grüße, Max

PS: Ob deutsch oder englisch Vorrang hat ist hier schwer zu sagen. Die englische Seite behauptet ja von sich, eine Übersetzung der deutschen zu sein 😉

Danke, ich werds mal mit climbing_advanture probieren!
sport=climbing für Klettergärten mag ich am wandfuß irgendwie lieber als an nem cliff mit drangehängt, obwohl letzteres schon auch sinn macht, da sieht man gleich wie breit das gebiet ist.

Gogul wrote:

sport=climbing für Klettergärten mag ich am wandfuß irgendwie lieber als an nem cliff mit drangehängt, obwohl letzteres schon auch sinn macht, da sieht man gleich wie breit das gebiet ist.

Ich hab mal ein paar natural=cliff + sport=climbing gesucht. So wie in dieser Gegend finde ich eigentlich einen Klettergarten ganz gut und detailliert mit climbing an Wegen erfasst.

An der Darstellung muss man noch arbeiten: kleinräumige Erfassung führt zu einem ziemlich überladenen Bild und bei breiten Wänden hat man auch nichts davon, wenn irgendwo in der Mitte der Wand ein kleines grünes Klettersymbol klebt. Aber das ist kein Problem des Taggings.

Hallo in die Runde,
Ich bin grad dabei, die Klettergebiete um Leipzig einzutragen.
Da es einige Zugangsbeschränkungen in den Steinbrüchen um Leipzig gibt (im Gaudlitzberg dürfen zum Beispiel nur DAV-Leipzig-Mitglieder klettern, kam mir der key climbing:access_restriction=* (z.b. no/only members of DAV Leipzig)
Man könnte diesen key auch gleich für (temporäre) Kletterverbote mitverwenden: z.B. climbing:access_restriction=forbidden from...to...

Gibt es dazu Meinungen?
Vorschläge? 🙂

trampintheforest wrote:

Hallo in die Runde,
Ich bin grad dabei, die Klettergebiete um Leipzig einzutragen.
Da es einige Zugangsbeschränkungen in den Steinbrüchen um Leipzig gibt (im Gaudlitzberg dürfen zum Beispiel nur DAV-Leipzig-Mitglieder klettern, kam mir der key climbing:access_restriction=* (z.b. no/only members of DAV Leipzig)
Man könnte diesen key auch gleich für (temporäre) Kletterverbote mitverwenden: z.B. climbing:access_restriction=forbidden from...to...

Gibt es dazu Meinungen?
Vorschläge? 🙂

Ich finde es braucht kein extra climbing:access=*, weil access=* beinhaltet ja schon das Betreten und andere Verkehrsmittel werden auf Felsen nicht unterwegs sein. Aber es schadet auch nicht, auswerten wird das wenn überhaupt sowieso nur eine sehr spezielle Auswertung.

Für zeitweise Beschränkungen gib es conditional restrictions, z.B. "access:conditional = no @ (Feb-May)" wenn man zur Brutzeit nicht klettern darf.

Ausdrücke wie "access=only members of DAV Leipzig" würde ich grundsätzlich vermeiden. Wer sollte sowas auswerten können, ohne jeden Verein zu kennen. Dann lieber "access=private" und den Verein irgendwo anders unterbringen ("operator=DAV S. Leipzig" z.b.).

Grüße und willkommen im Forum
Max

maxbe wrote:

Dann lieber "access=private" und den Verein irgendwo anders unterbringen ("operator=DAV S. Leipzig" z.b.).

So hab ichs gemacht.
Danke für die Tipps

Würdest du dann fee=yes setzen (im Sinne des Mitgliedsbeitrags des jeweiligen Vereins)?

trampintheforest wrote:

Würdest du dann fee=yes setzen (im Sinne des Mitgliedsbeitrags des jeweiligen Vereins)?

Nein.

Bei fee=yes würde ich erwarten, dass ich auch als Nichtmitglied vorbeikommen kann und am Eingang ein Kassenhäuschen vorfinde. Also falls der DAV da nicht "Tagesmitgliedschaften" für 2,50 Euro anbietet... 😉

FYI, ich habe die DE und EN Version der Wiki-Seite https://wiki.openstreetmap.org/wiki/DE: … 3Dclimbing miteinander konsistent gemacht und auch diverse Formulierungen überarbeitet, entrümpelt usw.

In den DE+EN Diskussionsseiten machen leider wenige mit. Ich hätte insbesondere gern mehr Meinungen, ob :mean zu :usual oder :typical und climbing:quality=* zu climbing:rock_quality=* geändert werden sollten, weil diese Bezeichner trefferender sind - je früher wir das machen, desto mehr Mapper gewöhnen sich gleich die "finale" Formulierung an.