Re: [Tagging] Feature Proposal - RFC - Site Relation

[Marc Gemis]

I think it is also used with historic, not only heritage, e.g. [1]

Thus there are at most ca. 3800 more.[2]

regards

m.

[1]
http://gk.historic.place/historische_objekte/translate/nl/index-nl.html?zoom=17=50.66496=7.24869=BTFFFTT=r3580734
[2] http://taginfo.openstreetmap.org/keys/historic#overview

On Sun, Sep 6, 2015 at 10:07 PM, Joachim  wrote:

> The relation type=site proposal [1] has been around for seven years
> now. Milliams is the original creator of the draft while Joshdoe
> cleaned up the proposal page, added some to the discussion and also
> sent out an RFC in 2011 [2].
>
> The relation has a bit of troubled history since the original idea -
> usage for a typical school - is strongly discouraged now. The RFC
> brought up the point that the relation is not needed if the feature
> can be represented by a polygon.
>
> The definition now is: "A way to group features (represented by
> nodes/ways/areas/relations) which belong together but cannot be
> adequately described by an area/multipolygon. [...] This relation is
> understood to group man-made objects. For groups of natural objects
> which share the same name see proposed relation Cluster. "
> Further changes since the last RFC:
> * The key site=* has been deprecated, better use the full tag instead
> (e.g. amenity=university).
> * The label role has been removed since this is strongly resisted by
> cartographers.[3]
> * The entrance role has been removed since it did not fit the new
> definition. Discussion is ongoing to readd it.
> * The perimeter role has been moved to a sub-proposal with new definition.
> * Documented usage examples from the wiki have been added.
>
> I'd like to bring your attention to the proposal. Please visit the
> proposal page [1] and add your comments to the discussion.
>
> Cheers, Joachim (Jojo4u)
>
> [1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site
> [2]
> https://lists.openstreetmap.org/pipermail/tagging/2011-February/006730.html
> [3]
> https://github.com/gravitystorm/openstreetmap-carto/pull/546#issuecomment-45504933
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - Site Relation

[Joachim]

The relation type=site proposal [1] has been around for seven years
now. Milliams is the original creator of the draft while Joshdoe
cleaned up the proposal page, added some to the discussion and also
sent out an RFC in 2011 [2].

The relation has a bit of troubled history since the original idea -
usage for a typical school - is strongly discouraged now. The RFC
brought up the point that the relation is not needed if the feature
can be represented by a polygon.

The definition now is: "A way to group features (represented by
nodes/ways/areas/relations) which belong together but cannot be
adequately described by an area/multipolygon. [...] This relation is
understood to group man-made objects. For groups of natural objects
which share the same name see proposed relation Cluster. "
Further changes since the last RFC:
* The key site=* has been deprecated, better use the full tag instead
(e.g. amenity=university).
* The label role has been removed since this is strongly resisted by
cartographers.[3]
* The entrance role has been removed since it did not fit the new
definition. Discussion is ongoing to readd it.
* The perimeter role has been moved to a sub-proposal with new definition.
* Documented usage examples from the wiki have been added.

I'd like to bring your attention to the proposal. Please visit the
proposal page [1] and add your comments to the discussion.

Cheers, Joachim (Jojo4u)

[1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site
[2] https://lists.openstreetmap.org/pipermail/tagging/2011-February/006730.html
[3] 
https://github.com/gravitystorm/openstreetmap-carto/pull/546#issuecomment-45504933

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Site Relation

[fly]

Am 03.02.2011 20:01, schrieb M∡rtin Koppenhoefer:
 2011/2/2 Tobias Knerr o...@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.
 
 
 +1
 
 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.
 
 
 +1

please change the example on the proposal page, because a site-relation
is not need for this case

 A site relation wouldn't add any information that cannot be determined
 by an is-in-polygon test, a well-explored algorithmic task.
 
  ...
 
 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
 relations.

maybe we can use this as example on the poposal page.

Thanks fly



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Site Relation

[Josh Doe]

Tobias and Eugene,
I understand your point, so I've added  a few sentences to the
proposal [1] about using simpler tools when appropriate.

-Josh

[1]: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site#Proposal

On Wed, Feb 2, 2011 at 2:58 PM, Tobias Knerr o...@tobias-knerr.de wrote:
 Josh Doe wrote:
 The Relation:type=site proposal [1] has been around for over two
 years, and I think it is a very useful relation, so I'd like to help
 it get approved.
 [...]
 I've been using this relation for schools and playgrounds,
 and I believe it is a needed addition to our tagging arsenal.

 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.

 I can support the proposal if (and only if) it is made clear that site
 relations are only to be used where simpler tools aren't sufficient.

 Tobias Knerr

 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Site Relation

[M∡rtin Koppenhoefer]

2011/2/2 Tobias Knerr o...@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.


+1

 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.


+1

 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
relations.

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.

Cheers,
Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Site Relation

[M∡rtin Koppenhoefer]

you deleted one of the more important parts of this relation IMHO: the
label-node which would serve as a suggested label placement. 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 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.

There should also be a role ticket_office or similar

We could differentiate main entrances from lateral ones

We could have a role for exits.

We should encourage people to add opening_hours.

...

But the most encouraging part for the mappers would surely be an
implementation for the renderers.

Btw.: there are already 128136 of these relations in the data. Please
put the description of roles you removed back into the wiki.


Cheers,
Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Site Relation

[Josh Doe]

See comments inline below:

On Wed, Feb 2, 2011 at 6:29 AM, M∡rtin Koppenhoefer
dieterdre...@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
 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
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Site Relation

[Tobias Knerr]

Josh Doe wrote:
 The Relation:type=site proposal [1] has been around for over two
 years, and I think it is a very useful relation, so I'd like to help
 it get approved.
 [...]
 I've been using this relation for schools and playgrounds,
 and I believe it is a needed addition to our tagging arsenal.

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.

I can support the proposal if (and only if) it is made clear that site
relations are only to be used where simpler tools aren't sufficient.

Tobias Knerr

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Site Relation

[Eugene Alvin Villar]

On Thu, Feb 3, 2011 at 3:58 AM, Tobias Knerr o...@tobias-knerr.de wrote:
 I can support the proposal if (and only if) it is made clear that site
 relations are only to be used where simpler tools aren't sufficient.

+1

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging