Hello everybody,
As a bike traveler, I am often using OSM data about hotel/hostel/guesthouse. The price information is often missing though very useful for me.
I want to tag the price of a hotel I am in but not sure how to do it. Wiki pages (Key:charge or Key:charge:conditional) are not precise enough to help me. There are different types of rooms (the cheap double room is at 50000 MNT (mongolian money) without shower, the expensive one is at 100000 MNT with a shower included.
Q1 : If I put only one price, should I put the minimum (charge=50000 MNT/room) or average price (charge=75000 MNT/room) ?
Q2 : Is it possible to give a range (charge=50000-100000 MNT/room) ?
Q3 : Is it possible to give a precise description of the prices (charge=50000 MNT/room with another tag charge:conditional=100000 MNT/room @ shower) ?
I am not mastering the conditional scheme so any help welcome
Please don’t add prices that will fluctuate as frequently and largely as hotels, where there are also many room or service variants. It is not easily maintainable and trackable. It will be prone to spamming and scams by them and SEO to market a misleading “lowest price from”.
I will only consider adding =alpine_hut , or maybe even =hostel , if they are fixed and few. Use eg charge:url= to link to the price list, similar to opening_hours:url= . Furtheremore, reservation:url= to see the prices by attempting to reserve directly.
When it comes to fluctuations, I think it is true for all charge= tags. All prices are submitted to inflation and changes, not only hotel. So I don’t see why other features would have this info and not hotel. It is still useful to have an idea, and you can check the date of modification to qualify the info.
Thanks for the solutions you propose but there are far from the reality in central Asia and Mongolia where I travel. The hotels I’m talking about don’t have websites. No url to provide. You can only get this information from the ground. Often the prices are quite simple (dorm versus room, or simple versus double). Sometimes you can find the infos on Google Maps in the comments and it helps the travelers a lot. I thought putting the info on OSM was a way to help make open data more competitive against proprietary data
in many regions, hotel prices vary by the day and even by the hour, depending on the number of free rooms they currently have. If prices are less dynamic, it could make sense to store them to give an indication
Perhaps worth noting that charge:conditional had been used fewer than 2000 times in the whole world, and taginfo suggests that no applications have registered as using this tag. So it’s probably fair to say that rules for this tag have not been worked out in detail. To some extent they may be inferred from more heavily used conditional tags (access restrictions), but I don’t think everything will have a direct equivalent. Also, it’s quite possible that map users will only ever see this information in raw tag format which will likely be rather cryptic.
In addition to what others have said, I will discuss the problems in charge= now. First in fact, you can have =* /room/night as the time rate with the quantity, although there are some discrepancy in their order. So one needs to decide whether it should be used, or even =* /night alone if paying per room can be assumed.
For the necessity of *:conditional= , there are 2 parts. The quantity unit is flexible. It doesn’t have to be =* /room . Could possibly be /single , /double , /twin , and somehow /bed for bunk beds perhaps. (cf both beds= and rooms= are used) At other facilities, /room may mean booking the entire room with many beds, or there could even be no beds.
I don’t know whether all the rooms at your example have double beds. Still, it can’t express room with shower “nicely”. Maybe if it has “economy”, “deluxe”, etc titles as on sleeper train clases (although those fares float as flight tickets do in EU).
Next, semicolon multival is actually used. It’s not a must to immediately resort to *:conditional= . However for simplicity, it’s best minimized. Particularly, modes /hgv etc have been used, ignoring the precedence of modal suffix charge:hgv= , and causing actual quantity units viz /axle to be squeezed in /hgv/axle .
Others have doubted whether charge:conditional= is supported by any application. To be fair, on one hand, I will also ask whether the different units and formats in charge= are actually parsed by any app. On the other hand, arbitrary conditions viz @ shower are both unreliable, and unclear. Can it mean paying extra to use a shower outside the room? So I will at least make use of quoted comments from opening_hours= to insert ; "with shower") in charge:conditional= .
Improperly, there are 37 charge= with comments directly inside. Recently, phone= was discussed for how it should be extended as well. Talk:Key:phone - OpenStreetMap Wiki
For completeness, I will end by mentioning quoted comments have problem with multilingual support, while opening_hours= only specified it for the local language as name= is. There are some dozens of opening_hours:en= , opening_hours:fr= , etc language suffixes.
At the bottom line, if it is treated as raw text, it might as well be freeform for now. description= has the advantage any user should be able to read it, while there is a 255char length limit, and prices compete for valuable estate with any other info not expressible specifically. There are a few charge:descripion= too, similar to standard wheelchair:description= ,
Indeed ! I guess day-to-day prices are more frequent in rich countries and big hotels. And I agree that those moving prices cannot be tracked.
Based on @alan_gr and @Kovoschiz 's answers, I conclude that the charge:conditional might not be useful. I guess /night can be assumed and should be the default. Indeed /room might not be precise enough and /single , /double , /twin , and /bed are simple and efficient options. Though I’m thinking that they are not real units (no possible conversion from single to double, contrary to minutes-hours, litres, etc), they describe different products, so it may be more appropriate to tag charge:single=*, charge:double=*…, isn’t it ?
For the shower, because it is so specific, it might better fit in the description indeed !
charge= doesn’t have such requirement established yet. Inventing *:single= etc suffix now is less useful and organized.
You can’t convert /person , /room , etc up or down either, other than having /2 people , /2 rooms , etc if there are discounts. There already 2 /beds , and 14 /tent being used, so that’s what I’m alluding to. There are some single or double in freeform text, surprisingly for =camp_sitecharge | Keys | OpenStreetMap Taginfo
How do I add two simple prices in a hostel (not moving on a daily basis, not found on internet), if there are two prices: one for dorm and one for double room ?
In this case, I sticked to simple suffixes charge:bed=750 RUB charge:double=2000 RUB
because I didn’t want to use multiple values (wiki says it’s dirty ) : charge=750 RUB/bed;2000 RUB/double. Should I use multiple values instead ?
Sorry to insist but the rare hostels/guesthouse with dirty name="cheap room for XXX Kirghiz money" I found on my way helped me a lot so I’d like to come to a good way of providing prices so other slow travelers could benefit from it.
You need to understand where semicolon are avoided in context. There is no such aversion on charge= . There are 1954 unique charge= with ; . charge:*= hasn’t been defined as this extensible. It won’t be supported at all.
