See comments inline below: On Wed, Feb 2, 2011 at 6:29 AM, M∡rtin Koppenhoefer <[email protected]> wrote: > you deleted one of the more important parts of this relation IMHO: the > label-node which would serve as a suggested label placement.
Okay, I added this one back, though I'm not fond of it myself. I don't like the idea of having elements that are purely for presentational purposes, though I understand the benefit. Would be great to get more feedback on this one, anyone else? One question I then have is where do we put the details of the site, such as name, operator, website, etc? Do we tag them on the perimeter way, the label node, or the site relation? If it can be in multiple places, which takes precedence? Current implementations would render both the perimeter and label, so we certainly don't want both to be tagged, but maybe we can have the perimeter OR label tagged (to support current implementations) as well as the relation itself. No easy solution it seems. > I made > some of these relations and I was never sure, which objects I should > put into the relation (as for instance the spatial configuration > already says that everything inside the perimeter is part of the > site). I understand the uncertainty. For me, when I tag a school it makes sense to add the parking lot, building, and pitches as members of the site relation, but not the sidewalks or roads. I suppose I try and just add the important "features" of a site, but this will certainly vary from mapper to mapper. However I think it is important to have the relation and not just rely on assuming all objects within the perimeter are members of the site. > I guess a possible rendering implementation could be to not > render the single parts (if they are pois) but only the relation > (depending on the zoom, this for low zooms obviously), so in the > relation we could put all single pois that wouldn't have to be > rendered in low zooms. I like this idea, so I'll add a section to the wiki on rendering. > > There should also be a role "ticket_office" or similar As I mentioned on the discussion page, I think that is outside the scope of this proposal. There are way too many roles that could be added, many of which are unneeded since you can just look at the members themselves for this information. In those cases that warrant additional roles, a separate proposal should be started. > > We could differentiate main entrances from lateral ones This would be useful, though I'm not sure how we'd do this. I think it might be better to add tags to the entrance nodes themselves rather than come up with additional roles. > > We could have a role for exits. As I mentioned on the discussion page, I'm not sure of the usefulness of this, especially since we really have three possibilities, entrance_only, exit_only, and entrance_or_exit. We should be having highways (footway/path/service/etc) connecting to the "entrance" nodes, and if only entrance or exit is allowed at those points we should add the oneway tag to the way. > > We should encourage people to add opening_hours. Hmm, this could be useful, considering you can have a zoo where some exhibits are open for different times compared to others and to the zoo itself. Do we add this to the perimeter or to the relation? I suppose this is the same dilemma as the rest of the tags; tagging the relation makes more "sense" but no implementations support it, plus most (?) existing use of site puts tags on the perimeter (e.g. the school article suggests tagging the perimeter). > > ... > > But the most encouraging part for the mappers would surely be an > implementation for the renderers. > I think that would be great, but we should probably try and get this proposal approved first. Please take a look at the rendering section I added to the wiki and make or suggest modifications. > Btw.: there are already 128136 of these relations in the data. Please > put the description of roles you removed back into the wiki. > Wow, more than I expected. I should try and analyze these to see how tagging has been done. -Josh _______________________________________________ Tagging mailing list [email protected] http://lists.openstreetmap.org/listinfo/tagging
