Hat jemand eine Idee, wie man einen Ski- und Schneeschuhverleih eintragen kann?
Ich würde es passend zu amenity=boat_rental oder amenity=bicycle_rental als
amenity=ski_rental
snowshoe=yes
sowie Name und Adresse eintragen. Aber ich hab bisher nichts weiter gefunden.
Der “rental” Zustand hier ist eh panne… Für jede Art ein eigenes “amentiy”. 
Nicht ganz… https://wiki.openstreetmap.org/wiki/DE%3ATag%3Arental%3Dstrandkorb 
Ich würde
amenity=rental (unüblich)
rental=ski
machen.
Dann habe wir aber wieder das Galama mit den mehrfachen Eigenschaften… 
Mögliche Lösung
rental:ski=yes
rental:snowshoes=yes
rental:snowboards=yes
rental:xxx
Sei mutig! 
Bei amenity=ski_rental wird man im Wiki auf shop=ski weitergeleitet 
Die https://wiki.openstreetmap.org/wiki/Piste_Maps bietet beides an:
rental=ski → 323 mal (https://taginfo.openstreetmap.org/tags/rental=ski)
amenity=ski_rental → 224 mal (https://taginfo.openstreetmap.org/tags/amenity=ski_rental)
und ganz viele, wo beides enthalten ist.
[OT] Immer wieder die falsche Verwendung des Namens:
name=Skiverleih
name=Snowboardtestcenter Skischule Verleih
name=Ski und Schlittenverleih
u.s.w.
[/OT]
Wie ich schon schrieb… wer die Wahl hat, hat die Qual. Und egal wie du es machst… einer wird kommen und sagen das ist falsch… 
+1
+1
Gibt es denn überhaupt im nennenswerten Umfang Geschäfte mit solchem Verleih, die NICHT im Rahmen eines Sportgeschäftes laufen ?
Wir hätten dann zunächst shop=
mit Zusätzen von rental=
Eine neue amenity halte ich für deutlich übertrieben.
Ob nennenswert oder nicht, es gibt sie. Und damit haben sie m. M. n. eine Berechtigung für die Datenbank und für spezielle Karten.
Wir haben hier ein Kleinunternehmen, das betreibt im Sommer ein Bikeverleih und im Winter ein Skiverleih.
Sehe ich auch so, denn bei einem gemeinsamen Bike- und Skiverleih (siehe oben) gibt´s schon ein Problem: amenity=bicycle_rental und amenity=ski_rental in einem Punkt.
Aus diesem Grund gefällt mir die andere Lösung besser. Dann konsequenterweise auch für alle anderen amenity=*_rental.
Leider hat sich amenity=bicycle_rental offensichtlich schon etabliert: https://taginfo.openstreetmap.org/search?q=amenity%3Dbicycle_rental
Nun im Wiki ist auch als Alternative shop=bicycle + service:bicycle:rental=yes für einen Fahrradladen mit Fahrradverleih notiert, aber das passt aber nicht mit der Definition des Schlüssel service überein (siehe https://wiki.openstreetmap.org/wiki/DE:Key:service))
Taginfo sagt, dass es auch neun Mal das Tag service:rental:ski gibt (falls es noch nicht erwähnt wurde). Aus dem Gedanken der Service Beschreibung der Fahrradläden (nach meinen dunklen Erinnerung kommt dies Beschreibungsform dort her), müsste es jedoch service:ski:rental lauten.
Edit: Kommentierung der Schreibweise ergänzt.
Und wenn es nun aber gar kein shop=bicycle ist?!
Es zwingt ja keiner dazu, dass etwas ein Geschäft (im Sinne eines Laden) ist. Es wäre doch auch ein
denkbar.
Denkbar schon. Aber es ist keine Touristeninformation.
Es ist einfach eine Garage bzw. ein Schuppen neben einem Wohnhaus und der Bewohner vermietet eben zu unterschiedlichen Jahreszeiten unterschiedliche Dinge.
Ich habe mich bei dem Beispiel nicht auf Deine Situation bezogen, sondern ein Beispiel für ein realistisches Szenario gebracht, in dem kein Geschäft im Spiel ist. Für Deinen speziellen Fall würde ich es mit EinKonstanzer halten: amenity=rental.
Ich denke noch immer, das passt eher zu shop. Damit werden ja nicht nur Artikel sondern auch Dienstleistungen angeboten (Beispiel: shop=beauty), und darunter fällt doch auch eine Vermietung. Ich denke, ein Geschäft (shop), das bestimmte Artikel nicht nur vermietet sondern häufig auch verkauft, bietet deshalb eine gute logische Anknüpfung für das Produkt.
Wenn ich an ein Geschäft denke, das sich mit Schneeschuhen “beschäftigt”, also egal ob Verkauf oder Vermietung, denke ich an shop und suche einen shop.
shop=snowshoe
rental=yes
sale=no. (evtl.)
Nach deiner Lesart müssten dann für Schneeschuhe, Langlaufski und Räder
shop=snowshoe
shop=ski
shop=bicycle u. dgl.
in einem Punkt vereint werden. Das geht ja bekanntlich nicht.