Re: [Tagging] RFC - proposal page for camp_site=
I have fleshed out the camp_site proposal page a bit. https://wiki.openstreetmap.org/wiki/Proposed_features/Camp_Site And added some text in the discussion page identifying the three decisions that need to be made before the proposal proceeds - 1 -Is this the right model ? By model, I mean the idea we can divide up all camp sites into between four and six categories, separated by a small set of facilities. 2. Assuming yes, what are the category names and what facilities are the key ones, the ones that define the category ? 3. How to tag the other information that needs be associated with a well documented camp_site ?? I don't necessarily think that this proposal need to define 3) but it sure would help the mapper if it did. I'm quite happy to make that bit a vague suggestion or list of optional approaches but would rather get a consensus. Seen a lot of complains about how renderers won't to this and that but they would say we don't have our act together in this respect ! David ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - proposal page for camp_site=
Does any formal definition of a postfix to a key exist? A prefix in prefix:key like in abandoned:shop tells something about the state for the key. In a proposal like camp_site:restaurant=yes it means that restaurant belongs to camping (a kind of site relation in a line). In practice in this example tourism=camp_site camp_site:restaurant=yes camp_site:bar=yes would be the same as tourism=camp_site restaurant=yes bar=yes You need such a construction if you want to give additional information about the attribute, for example tourism=camp_site restaurant:opening_hours=18:00-22:00 bar:opening_hours=17:00-24:00 It is a way to use existing definitions of attributes (like opening hours for restaurant) for multiple namespace keys on a single node. amenity=restaurant;bar doesn't allow this. It is a clean solution, but I haven't found osm suffixes are set up this way. As far as I have seen osm doesn't treat postfixes in a special way: peanut:butter is parsed the same way as peanut_butter, in other words the complete key peanut:butter has to be defined, unlike abandoned:shop with separate definitions for abandoned and shop. Correct? info/tagging https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - proposal page for camp_site=
Okay - I have a question - If Jan’s proposal sets the basic category, And this one sets the amenity level, Is is possible to base this around access to the spaces? it seems to set the whole tone of the camp. RV Caravan / car camping / tent camping? An RV camp usually has spaces and facilities meant for RVs, Car camping has spots with a parking spot at each site and space for tenting next to it ( a “Auto Camp” in Japan, and a lot of US State/national park camps) , and tents are plots laid out near each other, with cars or other access *not* directly next to the sites (like a large scout camp or camping in some traditional parks with grass and a playground). I would like to designate the level that way first, and then make a bunch of camp_site:x=yes/no tags to denote facilities that are common to the sites or the camp itself. There will be a million different combinations of amenities from camp to camp and country to country, so setting the basic *layout* type of the camp is the most important. I have found some really bare and tiny camps with nice kitchens which would not fit nicely into the categories based around amenity - so set the amenities by themselves - and base it around camp layout. camp_site:restaurant=yes camp_site:water=yes camp_site:space_water=no campsite:kitchen=yes camp_site:space_bbq=no camp_site:space_power=yes camp_site:attendant=yes This is really extesible, as some countries have amenties that are unheard of in other countries (netting, fishing ponds) etc, and are easily added without trying to redefine the entire camp_site= values. and for camps that offer the additional types of camping, as sometimes an RV camp has some car camping spots, then add it as an additional value, since for the example it’s predominantly an RV camp. camp_site=car_camping=yes Javbw On Mar 30, 2015, at 4:23 PM, David Bannon dban...@internode.on.net wrote: On Mon, 2015-03-30 at 05:44 +, Jan van Bekkum wrote: .. I hope someone else will stand up to kick off the camp_site=* proposal for facility levels. OK Jan, hint taken. https://wiki.openstreetmap.org/wiki/Proposed_features/Camp_Site Very early, lot more needs be done. I'm going to be tight on time over next couple of weeks so anyone with a keyboard .. David ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - proposal page for camp_site=
2015-03-30 10:05 GMT+02:00 johnw jo...@mac.com: camp_site:restaurant=yes camp_site:water=yes camp_site:space_water=no campsite:kitchen=yes camp_site:space_bbq=no camp_site:space_power=yes camp_site:attendant=yes I still believe that this kind of model is not preferable, because these lists tend to get very long (i.e. they clutter the object leading to the already observable problem that important tags get forgotten or not updated/corrected because of too many secondary and tertiary tags), and they repeat in a redundant way what should already be mapped as objects on their own (restaurant, bbq, toilets, water points, ...). They tend to increase inconsistency (because if e.g. the bbq space becomes unfunctional, people might likely remove them from the map, but might forget to remove refering redundant tags from containing objects that are higher in the hierarchy). If we'd continue with this logic, we might even replicate these on the town? place=town, town:camp_site=yes, town:camp_site:restaurant=yes, town:camp_site:restaurant:cuisine=italian? Some things might make sense to be seen as attributes on the camp_site, e.g. whether there is power available, while others like the presence of a restaurant or a shop should be better mapped as objects on their own. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - proposal page for camp_site=
On Mar 30, 2015, at 1:05 AM, johnw jo...@mac.com wrote: Okay - I have a question - If Jan’s proposal sets the basic category, And this one sets the amenity level, Is is possible to base this around access to the spaces? it seems to set the whole tone of the camp. RV Caravan / car camping / tent camping? An RV camp usually has spaces and facilities meant for RVs, Car camping has spots with a parking spot at each site and space for tenting next to it ( a “Auto Camp” in Japan, and a lot of US State/national park camps) , and tents are plots laid out near each other, with cars or other access *not* directly next to the sites (like a large scout camp or camping in some traditional parks with grass and a playground). I would like to designate the level that way first, and then make a bunch of camp_site:x=yes/no tags to denote facilities that are common to the sites or the camp itself. There will be a million different combinations of amenities from camp to camp and country to country, so setting the basic *layout* type of the camp is the most important. I have found some really bare and tiny camps with nice kitchens which would not fit nicely into the categories based around amenity - so set the amenities by themselves - and base it around camp layout. camp_site:restaurant=yes camp_site:water=yes camp_site:space_water=no campsite:kitchen=yes camp_site:space_bbq=no camp_site:space_power=yes camp_site:attendant=yes This is really extesible, as some countries have amenties that are unheard of in other countries (netting, fishing ponds) etc, and are easily added without trying to redefine the entire camp_site= values. and for camps that offer the additional types of camping, as sometimes an RV camp has some car camping spots, then add it as an additional value, since for the example it’s predominantly an RV camp. camp_site=car_camping=yes Javbw On Mar 30, 2015, at 4:23 PM, David Bannon dban...@internode.on.net wrote: On Mon, 2015-03-30 at 05:44 +, Jan van Bekkum wrote: .. I hope someone else will stand up to kick off the camp_site=* proposal for facility levels. OK Jan, hint taken. https://wiki.openstreetmap.org/wiki/Proposed_features/Camp_Site Very early, lot more needs be done. I'm going to be tight on time over next couple of weeks so anyone with a keyboard .. Might also want to review the older proposal at https://wiki.openstreetmap.org/wiki/Proposed_features/Extend_camp_site Some of the things like camp_site:space_*=yes/no seem to be well covered under https://wiki.openstreetmap.org/wiki/Proposed_features/Extend_camp_site#Tagging_of_individual_pitches Cheers, Tod smime.p7s Description: S/MIME cryptographic signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - proposal page for camp_site=
On Mar 30, 2015, at 6:17 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: Some things might make sense to be seen as attributes on the camp_site, e.g. whether there is power available, while others like the presence of a restaurant or a shop should be better mapped as objects on their own. I guess that makes sense. I was thinking of tagging the tiny amenities that you would find at each site that might be very difficult to map, such as water, power, etc. But I guess if you can map the spaces area (pitches?) then I guess they could be an attribute of the space. Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - proposal page for camp_site=
On Mon, 2015-03-30 at 17:05 +0900, johnw wrote: camp_site:restaurant=yes camp_site:water=yes camp_site:space_water=no campsite:kitchen=yes camp_site:space_bbq=no John, this model would work fine if the end user was using a interactive tool where he could say show me all the camps that comply with this list of facilities. But we very quickly identified twenty or so characteristic of a camp and I reckon we could easily extent that to 50 to a 100 if we really tried. So, its not possible to show that on a flat map, even a fairly specialised one. Thats where the idea of identifying a very small set of key characteristics arose. Thats map-able and is a key to a subsequent list of characteristics. So the proposed new keys, camp_site= and camp_type= do not exclude all the other things you mention and others. They could be seen as more a top level filter, that an end user can use to narrow down their search. Its in response to the very wide range of possible camp types you might find. Locally important facilities, tent/van issues, details of pitch facilities and so on are all still usable and should (but not must) still be mapped. David ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
