<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2015-03-30 10:05 GMT+02:00 johnw <span dir="ltr"><<a href="mailto:johnw@mac.com" target="_blank">johnw@mac.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2f8" class="a3s" style="overflow:hidden">camp_site:restaurant=yes<br>
camp_site:water=yes<br>
camp_site:space_water=no<br>
campsite:kitchen=yes<br>
camp_site:space_bbq=no<br>
camp_site:space_power=yes<br>
camp_site:attendant=yes<br>
</div></blockquote></div><br><br>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? <br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Martin<br></div></div>