Good feedback Peter and thanks for passing along the Crossing wiki. Some comments below:
On Tue, Sep 14, 2010 at 10:39, Peter Wendorff <wendo...@uni-paderborn.de>wrote: > Hi. > > On 14.09.2010 18:59, Sean Horgan wrote: > > [...] > > Also, if I wanted to capture specific data about that they offered, I'd > like to follow the amenity:recycling tagging scheme ( > http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drecycling): > > + homeless_shelter:programs=jobs > + homeless_shelter:meals_served=breakfast > + homeless_shelter:lodging=yes > + homeless_shelter:emergency_medical=yes > > Is this a good model to follow? > > I'm not sure. > I think, there are two general approaches to simulate a tree-style tagging > scheme like this. > The first is to use more keys (as you do here with homeless_shelter:*), the > second is to use more values and to concatenate multiple values by ; (like > you will have at > homeless_shelter:meals_served=breakfast;lunch > (compare crossing=island;traffic_signals) > > Ok, I'm following you. Similar to amenity:recycling, many of the examples in Crossing follow a yes/no model: traffic_signals:sound<http://wiki.openstreetmap.org/wiki/Key:traffic_signals:sound> =yes/no<http://wiki.openstreetmap.org/w/index.php?title=Tag:traffic_signals:sound%3Dyes/no&action=edit&redlink=1> traffic_signals:vibration<http://wiki.openstreetmap.org/wiki/Key:traffic_signals:vibration> =yes/no<http://wiki.openstreetmap.org/w/index.php?title=Tag:traffic_signals:vibration%3Dyes/no&action=edit&redlink=1> traffic_signals:arrow<http://wiki.openstreetmap.org/wiki/Key:traffic_signals:arrow> =yes/no<http://wiki.openstreetmap.org/w/index.php?title=Tag:traffic_signals:arrow%3Dyes/no&action=edit&redlink=1> traffic_signals:minimap<http://wiki.openstreetmap.org/wiki/Key:traffic_signals:minimap> =yes/no<http://wiki.openstreetmap.org/w/index.php?title=Tag:traffic_signals:minimap%3Dyes/no&action=edit&redlink=1> <http://wiki.openstreetmap.org/w/index.php?title=Tag:traffic_signals:minimap%3Dyes/no&action=edit&redlink=1>However, for a finite and relative small (< 10) set of values, I prefer a multivalued value string like "homeless_shelter:meals=breakfast;lunch" over something like this: homeless_shelter:breakfast=yes homeless_shelter:lunch=yes homeless_shelter:dinner=no For amenity:recycling, there is no limit to what could be recycled so I think it makes more sense to follow the yes/no model as a single value could get extremely large. The same appears to go for traffic_signals (I never thought you could break those down so discretely!). Both are good for some reasons: > using less keys provides easy access for the whole group of values; > using less values is more easy to parse and search - there is no string > slicing needed. > > But: > I would not mix these together. > I prefer consistency as well but I think I would only apply that for a particular tag. To continue the meals example, homeless_shelter:meals could be defined as a multivalued list from a set of known values (e.g. {no;breakfast;lunch;dinner;takeout}) while a list of programs/services offered by the shelter would follow the yes/no model: + homeless_shelter:lodging=yes + homeless_shelter:meals=no + homeless_shelter:job_placement=yes + homeless_shelter:veterans_services=yes + homeless_shelter:emergency_medical=yes Feedback is greatly appreciated! -- Sean > Perhaps that's only my POV - feel free to argument against. > > regards > Peter > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > http://lists.openstreetmap.org/listinfo/tagging > >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
