[Tagging] Feature Proposal - RFC - Site Relation
josh at joshdoe.com
Wed Feb 2 13:22:43 GMT 2011
See comments inline below:
On Wed, Feb 2, 2011 at 6:29 AM, M∡rtin Koppenhoefer
<dieterdreist at gmail.com> 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
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.
More information about the Tagging