[Tagging] Feature Proposal - RFC - Site Relation
dieterdreist at gmail.com
Thu Feb 3 19:01:15 GMT 2011
2011/2/2 Tobias Knerr <osm at tobias-knerr.de>:
> It might be useful in some cases, but it shouldn't be overused. If the
> site is adequately described by a polygon, it can and imo should be
> mapped as an area with the appropriate tags.
> For example, a school that occupies one site with some buildings, sport
> facilities ... can trivially be mapped as an area with amenity=school
> and other tags (such as name) referring to the entire site, with
> separate elements for the buildings contained within.
> A site relation wouldn't add any information that cannot be determined
> by an is-in-polygon test, a well-explored algorithmic task.
IMHO a site relation would allow for more complex situations. Say you
have an archaeological site. There will be a main entrance (or 2), a
place where to buy tickets (not necessarily geometrically inside the
site itself) and service entrances that may be used only by staff.
Then there might be surveillance cameras that are positioned outside
the actual site, ...
I was recently mapping an archaeological site, where part of it was
fenced and required a fee. Other parts were located around, but not
all of them adjacent (some had fields between them and the "main"
site). I created 3 site relations: one for the part that was fenced
and required a fee, one for the rest and one to combine the 2 site
The site relation allows for rendering hints IMHO. You can group
distinct objects (polygons) into a bigger whole, allowing for the
renderer to understand the size (and therefor prominence to display
it) of the complex. Currently, if you split big areas into smaller
distinct areas, this information gets lost.
More information about the Tagging