Proposal talk:Site

From OpenStreetMap Wiki
Jump to navigation Jump to search
Talk:Relation:site - Other languages

Need for the label role

Resolved

There should not be role=label but the amenity (or other) key should be put on the relation. I don't see a reason for role=building (or role=other), either. The "role" can be determined from the tags on the member. For example, if it has been tagged building=yes, its role obviously is that of a building. -- 3247 23:59, 2 January 2008 (UTC)

Okay, I guess I misunderstood the relations a tad. However, with relations, does it not make sense to provide hints to the renderer as to the role of each of the members? There may be several nodes in the site but only one of them is the chief, central node. Does it not make sense to specify that one (e.g. with <member type="node" ref="123" role="label"/>)? --Milliams 12:40, 3 January 2008 (UTC)
It might make sense to provide a hint where to put the name. However, it's semantically better to put tags on the relation and not on an arbitrary node: The name usually is a property of the site (i.e. the object represented by the relation), not of a single spot (represented by the node). It's even possible that the node (name=Foo University Tower) has different tags than the relation (name=Foo University). 3247 23:09, 8 January 2008 (UTC)
I don't like the mandatory label node, this should in most cases be auto-placed by the renderer. In some cases it might make sense to place the label at a specific point (for example if the main part of the site is very off-center), but I'd rather we use a separate, general relation for that, with type=labelhint or something. Bobkare 14:18, 25 January 2008 (UTC)
Labels are evil (TM), the role has been removed (see #Adopting).--Jojo4u (talk) 13:58, 20 August 2015 (UTC)

Group of map features

Resolved

After reading Proposed features/Square, I came to the conclusion that a "site" might actually be a sub-type of a "group of map features". Therefore, it might be better to use the following tags:

Key Value Discussion
type group marks the relation as a group of related objects
group:type string site|street|plaza|... - the type of the group.

3247 21:38, 12 January 2008 (UTC)

Every relation groups objects in one way or the other, so what you're doing there is adding an unnecessary level of indirection: if every relation is a group then every relation would need type=group and the detailed type description with group:type=blah. But this can simply be done with type=blah. --Shepard 22:24, 31 August 2008 (UTC)
I concur that this is an important generalisation to do, but suggest a name like cluster and a more general approach. Here's an example with a hospital:
Key Value Discussion
type cluster This tells the renderer to treat the rest of the tags as those of a normal node.
amenity hospital
name *
* Perhaps more attributes that apply for a hospital.
I can think of this beeing useful even for schools and groups of islands. Using a relation named site for the latter would sound odd so that's why I suggest cluster. Surely there are many more examples of when this relation could be used, and this is one advantage of using standard key/values. For instance a renderer doesn't have to implement all those cases, but can think of the relation as an ordinary node and render the icon/name on the centre of gravity/the label node. Of course only tags that apply for nodes will work. --Erik Lundin 21:47, 29 January 2009 (UTC)
Some time has passed, but I like your idea and did now create a proposal for type=cluster. --Fkv (talk) 11:53, 7 January 2015 (UTC)
Thanks for the proposal. Site should be used for grouping of man-made objects.--Jojo4u (talk) 13:56, 20 August 2015 (UTC)

more than one label?

Resolved

Relations/Proposed/Label, which is similar to this proposal except for being renderer-only, with no semantics, allows multiple label nodes, which might be useful for very large sites. Should we allow the same here? --21:46, 10 January 2009 (UTC)

Well, changed it. Change it back if you disagree. --Tordanik 21:07, 20 January 2009 (UTC)
Labels are evil (TM), the role has been removed (see #Adopting).--Jojo4u (talk) 13:52, 20 August 2015 (UTC)

Name of the parts of the Site

I was thinking if we shouldn't invent a new tag as name of the parts of the site. Take for expmple the Vienna University of Technology (Technische Universität Wien) [1]. All the buildings still have the name of the university in their name e.g. ("Technische Universität Wien (Informatik)"), which in my opinion is not bad for applications that don't know how to handle sites. On the other hand for Apps that can handle Sites just the name of the function of the building ("Informatik", "Main Building") would be sufficient. Maybe we should tag the parts of the site with "site_name=Main Building"? Comments? -- Skunk 04:22, 8 April 2009 (UTC)

I think we should avoid duplicates data, so it will be better to have the site name only in the relation. Applications will then adapte. At least, this should be in the specification on the relation, but in practice, you may duplicate the data… --NicolasDumoulin 01:14, 4 July 2010 (UTC)

Level

See also: level --Lulu-Ann 08:15, 10 May 2009 (UTC)

Type of site

I'm proposing that we use a site relation for the tagging of railway stations and other public transport interchanges. For this, I suggest we introduce a sub-type of 'site' by using site=*. So for example, we'd have site=railway_station. Frankie Roberto 12:02, 8 August 2009 (UTC)

It's a bad idea to do things such as type=school. We already have amenity=school, and there shouldn't be more than one tag that determines what sort of object something is. It seems your public transport interchanges are different from what this proposal is trying to do: This proposal is about site information for things that in simpler cases can be ordinary nodes or areas. Your interchanges, as I understand them, are always relations, because they are there only to group stops/platforms together. Therefore, wouldn't it be better to choose your own relation type? (type=interchange? type=station?) --Tordanik 15:13, 8 August 2009 (UTC)
actually there would be an advantage in case a site contains more than one POI. you will often find the combination amenity=restaurant + tourism=hotel. by adding a site=restaurant or site=hotel, it could offer a hint on which POI it should prefer when rendering the element in maps. --Flaimo 19:07, 4 May 2011 (BST)
  1. Public transport stations are nowadays tagged with as area public_transport=station. The relevant parts of puplic transport interchanges are tagged with as relation type=stop_area.
  2. Regarding site=* vs amenity=*/leisure=*/...: the current definition of the proposal deprecated the usage of site=* for the reasons Tordanik mentions.
  3. Regarding ambivalence: Every POI can be tagged ambivalently. There is no need to solve it only in this relation.
--Jojo4u (talk) 15:35, 8 September 2015 (UTC)

New roles

Hello, I just used Relation:site for the first time ( http://www.openstreetmap.org/browse/relation/226099 ), and I felt the need to add two new roles to the relation: perimeter and entrance.

perimeter is an optional role, and must be a closed way, which encloses [1] all the other members (buildings, ways, whatever). It's the one who should be tagged name=, if the whole site has a common name.

entrance is an optional role too, and should be added to nodes serving as entrances to the perimeter (they can be barrier=*, or a building=entrance, if the building wall is part of the perimeter).

[1] meaning that the way composing the "perimeter" shares nodes belonging to other ways too, doing so we don't add useless nodes. Example: http://www.openstreetmap.org/browse/way/40020693

Any comment on this? --Hanska 17:52, 2 September 2009 (UTC)

Yes, I totally agree for both new role. I've also the relation using the entrance role! As you, I've used the building=entrance on my node, but it is redondant with the role, isn't it? --NicolasDumoulin 01:17, 4 July 2010 (UTC)
Yes, I agree too. I would help renderer MrFrem82 11.34, 26/8/2010
I agree too, i think the perimeter role is the most important one and deprecates the originally proposed label role in most cases. I currently for example use to tag schools with their whole ground area as amenity=school and connect it to the buildings on the campus with a site relation using the perimeter role.
I think the entrance role is useful if the entrance to a site is not directly connected to a building (as in that case building=entrance or entrance=* on the node would be enough) or if a "site" like a shop inside of a building, which has many entrances, has an associated, designated entrance and must be semantically connected to it. --Cg909 00:07, 29 September 2010 (BST)
+1 from me Lulu-Ann
I've just added these two roles to the page. I think shortly we should put an RFC to the mailing list. - Joshdoe 13:55, 1 February 2011 (UTC)
Your definition that the perimeter "must be a closed way which encloses all the other members" contradicts the first sentence on the proposal page which says that the site relation is for grouping elements "not within a single area". Or do you mean a convex hull? This can be calculated by applications easily by doing a recursive lookup of the coordinates of the members. --Fkv (talk) 12:25, 7 January 2015 (UTC)
The wording "not within a single area" was added in 2011 after a RFC on the mailing list. Now the role perimeter indeed contradicts the propsal, I'm working on it.--Jojo4u (talk) 11:46, 10 August 2015 (UTC)

even more roles

I suggest the following roles to be optionally used:

  • Role parking for a parking that serves mainly the site
  • Role bus_stop for a bus_stop that serves mainly the site
  • Role ticket_office for a ticket office
  • Role exit if an "entrance" can only be used to leave the site

-- Dieterdreist 15:13, 11 January 2011 (UTC)

I think some of these are a good idea, but I'm not sure if it should be part of the main proposal, as we should focus on those elements which are common to all "sites." This list could easily expand very quickly. For example exit might not be good enough, as we'd need to add an entrance_only. I think this can be solved more simply by using oneway ways connecting to the entrance nodes. - Joshdoe 13:55, 1 February 2011 (UTC)

I would give roles to all members of a site. It's not good practise to give no role to a member. At first, you could just add custom to the proposal (means the mapper has to come up with something appropriate, like the roles above). The standard set of roles can be extended later on via other proposals, or via documentation of usage. --Sanderd17 16:00, 30 June 2012 (BST)

It is perfectly good practise to give no roles to members. If an amenity=parking is a member of the site it's implied role is clear. Also for example an entrance=* node.--Jojo4u (talk) 13:46, 20 August 2015 (UTC)

Site key and tagging perimeter vs relation

Resolved

I really like this proposal, though there is one thing I'm still not sure about, and that is whether we should be tagging the perimeter or the relation with tags such as amenity=school and name=*. I suppose my first point (made by others as well) is that we shouldn't be using site=school as that's duplicating work with amenity=*, leisure=*, etc. I think it makes more sense to tag the relation with the name and type of site (using amenity=*, leisure=*, etc.), however most if not all data out there has this information tagged on the perimeter, and this data is rendered appropriately. If this practice continues, it makes sense to tag the relation with the name=*, but more information would be redundant. What does everyone think? - Joshdoe 20:25, 1 February 2011 (UTC)

Why should you use the site relation if there is a perimeter? Isn't it the case that if there is a perimeter every node/way within it "belongs" to the perimeter. So if you have a clear university campus for example, draw the campus as an area and tag it as university. Everything within that area is automatically part of the university. In my view, the site relation is only necessary in cases where the university/shool/whatever is not clearly within it's own area. A good example is the university of Vienna relation 33319. The university buildings are scattered throughout the city, so you cannot draw an area around it. In that case I would tag the site relation with the amenity and name tags. --richardbrinkman (talk) 14:58, 26 July 2015 (UTC)
I' trying to further develop the role perimeter (not encompassing all members but parts of them). But the main tag should remain on the relation.--Jojo4u (talk) 13:43, 20 August 2015 (UTC)

not connected areas

Resolved

What about not connected area. For example the CERN area is divided in some sub sites:

--wiso 11:04, 5 February 2011 (UTC)

Use a multipolygon.--Jojo4u (talk) 16:45, 18 June 2015 (UTC)
As a follow-up: The CERN sites are mapped separately as area (landuse=commercial, office=research) atm. I'm not convinced to group them all in a big site relation.--Jojo4u (talk) 13:40, 20 August 2015 (UTC)

What should not be site

Resolved

Hi, thanks for the proposal and your work! Might be cause my lack of native english but it might be useful to say what not to tag as site. My usecase would be a campus map so universities, scientific areas, military bases,.... Is that what you expect this relation to group things like that? Are there usecases where site shouldn't be used?--!i! This user is member of the wiki team of OSM 20:35, 9 February 2011 (UTC)

I hope this is much clearer now, also see examples section.----Jojo4u (talk) 15:40, 8 September 2015 (UTC)

The site-relation is a broken concept

Site is for grouping various things together, where the mapper thinks, they belong together. A different mapper may then have another opinion about what belongs together. But you can add various roles, which are never affecting all the objects, which I think belong together. So it's better to put all the main object keys into the role field, seperated with ";", as usual. Otherwise the renderers would not know, what objexts have been grouped together in this relation. ;-)

The problems are, beside that I can put different kinds of objects into this realtion for the same thing to describe (e.g. a school), that the scope of what have been grouped in this relation is not clear. So you will find a school in the first, a hispital in the second and a military base in the third. And because all are tagged with type=site, the renderers always know what is in there. ;-)

I Think it will be better to use specialized relations, which only group a restricted set of clearly defined objects in one field together. --Fabi2 00:01, 10 February 2011 (UTC)

There I disagree Fabi. This open concept is a good playground to see if people will use this feature to create campus/school/.... maps. Yes they might be get a personal view on the site but this is a natural consequence of all what OSM is ;) --!i! This user is member of the wiki team of OSM 07:14, 10 February 2011 (UTC)

Isn't this RFC a bit late?

Resolved

http://taginfo.openstreetmap.de/tags/type=site#wiki

There are already over 128,000 relations of this type (I'm guessing many of these though are UK naptan imported bus stop "pairs" which may or may not end up retagged as stop areas).

-- EdLoach 14:33, 10 February 2011 (UTC)

Yes but isn't it good to make a clear vote and "justify" exising proposals? That would be a good point to make a preset for editors. --!i! This user is member of the wiki team of OSM 17:58, 10 February 2011 (UTC)
I think that an RFC is needed anyway to initiate discussion. But if you start voting, you should take into account that the proposal may be voted down. --Fkv (talk) 12:34, 7 January 2015 (UTC)

There are "only" around 15000 uses which are not NAPTAN/IGN imports (see proposal page). This is not a huge number but still quite a bit. This relation needs discussion in order to get more approval and documented use cases.--Jojo4u (talk) 15:56, 8 September 2015 (UTC)

site relations for parking

just wanted to inform everybody, that i wrote a parking proposal which makes use of the site relation: it's basically RFC: http://wiki.openstreetmap.org/wiki/Proposed_features/parking -- Flaimo 22:13, 17 March 2011 (UTC)

Existing use for housing complexes

I've used (seemingly) hundreds of site relations to identify groups of residential dwellings, with the following tagging scheme. It would be nice to integrate this with the proposal:

  • type = site
  • site = housing
  • housing_type = apartment | condominium | mobile_home | house | public_housing
  • name = *
  • builder = *

Member roles:

  • boundary = A landuse=residential area defining the borders of the site
  • access = The roads that are used to enter/exit the site
  • gate = Access control gates (usually on roads of access role)
  • office = On-site leasing/rental office building
  • <nothing> = Roads lying completely within site
  • gym
  • clubhouse
  • pool
  • whirlpool
  • etc.

There are currently 522 uses of site=housing. The examples I found ([2]) can be described by using an area/multipolygon. The roles are not needed, since each feature within that area describes itself well enough.--Jojo4u (talk) 16:54, 8 September 2015 (UTC)


clarifying the use of site=*

the proposal states: "(optional) The type of site (eg school or railway_station). This might be redundant, considering we already have amenity=*, leisure=*, railway=*, etc."

this should be clarified now, since other proposals start to relate on this. for my parking proposal i use type=site + site=parking, while the playground proposal uses type=site + leisure=playground. i don't care so much about which one to take, but there should be a decision made now. --Flaimo 16:13, 27 April 2011 (BST)

I think It's better to use the method from the playground proposal. Otherwise there could be cases where the tag is not uniquely identified. For example there is railway=station and public_transport=station. So type=site + site=station would be ambiguous. --Marko Knöbl 14:43, 21 November 2011 (UTC)
There seems to be a consensus to not use the site=* tag. I suggest removing it from the proposal. --Fkv (talk) 12:41, 7 January 2015 (UTC)
I agree.--Jojo4u (talk) 16:48, 18 June 2015 (UTC)
I marked it as legacy since site=parking is still valid.--Jojo4u (talk) 13:33, 20 August 2015 (UTC)

address data in a site relation

Resolved

how should site relations be used together with address tags? for example, if you have a complex building, split up into different parts (maybe because of different height tags), it would make sense to add the address tags to the site relation itself. of course if an building has more than one house number, the address data should be tagged on the entrance nodes. --Flaimo 14:11, 28 April 2011 (BST)

Adresses are attributes. When an adresses belongs to a building, the addr:* tags should go to the building, not the entrances. When the address belongs to the whole site, the addr:* tags should go to the relation. Remember, however, that site relations require disjunct areas by definition, and those certainly have distinct addresses. --Fkv (talk) 12:51, 7 January 2015 (UTC)


Adopting

The authors of the proposal are no longer active (Special:Contributions/Milliams and Special:Contributions/Joshdoe), I would like to adopt this proposal. How should this be done?

The list of pages linking here is massive. I would like to keep the page name. Current idea is to make a section with link to old id with mention of orginal author.--Jojo4u (talk) 11:36, 10 August 2015 (UTC)

All examples have been removed since they are better described as area/multipolygon. I'm looking for better ones. Also the label role has been removed. The lead developer of the standard style says here: "Never ever do anything with anything tagged as a "label", that way madness lies."

You should be extremely careful in modifying a page which is that much linked to: are you really sure you understood what people meant with site relations until now ? I suggest you wait for actual discussion here or on the tagging list before introducing new concepts into this. Especially if you want it to be 'adopted'. --Yvecai (talk) 13:56, 16 August 2015 (UTC)
I perfectly understand what people meant with site relations in 2009 and 2011. I'm picking up the transformation which started with the for RFC [[3]]: This relation should not be used when a polygon is sufficent. The role perimeter in it's old form is contradicting this definition. Also the label role is fiercly rejected by cartographers. This leaves the entrance role which is discussed below.--Jojo4u (talk) 14:21, 20 August 2015 (UTC)

Redefining perimeter, remove entrance

I redefined the role perimeter. It is still optional and encircles only a subset of the features so that you don't have to tag all of them inside. Also entrance role was removed since the perimeter does not encompass the whole site.--Jojo4u (talk) 15:26, 11 August 2015 (UTC)

Very strange modification: if you can encircle features with a polygon, why on earth would you use a site relation ??? --Yvecai (talk) 13:49, 16 August 2015 (UTC)
It's about encirceling a subset. Some parts of an university can be represented as area (campus), but some parts only as members of a site relation (spread buildings). Only one element can be tagged amenity=university, though. So the role perimeter brings the area (campus) into the relation which is tagged amenity=university. But I will move this concept to a new proposal since it might be controversial and my goal is to get this proposal accepted.--Jojo4u (talk) 14:26, 20 August 2015 (UTC)

entrance

I disagree to remove the entrance role. The entrance role make sense whether there is a perimeter or not. The entrance role could be given to any element of the site, on the perimeter or not, what do you think? I wonder how can we check how many site elements already have the role=entrance in the DB? I don't think taginfo could help here.
Also see Tag:amenity=parking_entrance --Yvecai (talk) 06:16, 16 August 2015 (UTC)
Could you please give 1-3 examples where the entrances are not obvious from tagging and need a role? (obvious: entrance=*, amenity=parking_entrance). Another possibility to mark where to go first might be amenity=reception_desk. The page Tag:amenity=parking_entrance adds nothing to the entrance role, it just replicates the former usage here without giving a good cause.
Taginfo has good info on site relations. Of all members 0.43% have the role entrance. To get an upper limit: If the existing entrance members are used only once per relation, 1832/135341 gives 1,4% of all site relations with role entrance.--Jojo4u (talk) 11:50, 16 August 2015 (UTC)
0.43% is still 1832 times a user take the entrance role as something useful, that's a lot of work by hand. A (maybe bad) example of use was for me the entrance of some cross-country ski sites. They are often very informal and not on the perimeter, and I used the role on place=locality, small huts, parking, simple nodes ... Other had probably done differently in a variety of manner.
I like to see the wiki as a source of documentation, so if somebody has used the role=entrance from this wiki page, I think it's good if a re-definition includes the previous one. I propose role=entrance : An element of the relation can be given this role, indicating where to enter the site. That does not hurt.
"Not hurting" is not good enough. Please, real world examples. You new defintion is a starting point. I want to avoid the proliferation of roles (#even_more_roles)--Jojo4u (talk) 14:29, 20 August 2015 (UTC)
A main entrance (entrance=main) to a building or building part may or may not be the main entrance to the whole site. But that's a flaw intrinsic to the entrance=* tags, and the "entrance" role wouldn't provide a general solution to that problem. --Fkv (talk) 09:17, 23 June 2016 (UTC)

why not just use multipolygon?

"A common example is a university site with a number of buildings scattered throughout across the city." - why multipolygon is not sufficient for this case? Mateusz Konieczny (talk) 10:29, 7 April 2016 (UTC)

It seems to be sufficient - I missed the fact that outer ways may have tagging on their own since all the talk is about moving the tags from the outer ways to the relation ;) So the following examples from the proposal are better suited as multipolygon:
--Jojo4u (talk) 08:03, 10 April 2016 (UTC)
Update: Oh well, relation Weißenhofsiedlung has touching outer rings (more than one point), so no multipolygon possible.--Jojo4u (talk) 08:33, 10 April 2016 (UTC)
Thanks for edit to proposal, now it is clear why such relation may be useful Mateusz Konieczny (talk) 20:11, 12 April 2016 (UTC)
Another use case: A site consisting of one one part of one floor of a building, and a non-congruent part of another floor of the same building. One example is the Ephesos Museum (way 324725228) in the Hofburg in Vienna. The Ephesos museum extends to two levels, so I tagged it with level=0;1. But on level=0, it occupies only part of that area. This could be resolved using a site relation. The members would get a level=0 and level=1 tag, while all other tags would go to the relation. --Fkv (talk) 10:00, 23 June 2016 (UTC)

State of documentation

Quote from osm-carto bug #2108: Given that nobody thought that proper documentation of that relation would be important.

The site relation is still a proposal which is lacking good discussion. So it's not advisable to document the current state on the tag main page (http://wiki.openstreetmap.org/wiki/Relation:site).--Jojo4u (talk) 08:26, 10 April 2016 (UTC)

The status of this page was recently set to 'abandoned', which I think is not appropriate for a tag used >140k times and still growing. I'd consider the discussion to be still on. --Polarbear w (talk) 09:14, 14 April 2018 (UTC)

Tag proposal is abandoned, tag is in use Mateusz Konieczny (talk) 12:52, 14 April 2018 (UTC)
Ok. But currently the feature page redirects here, thus it is the only documentation about the usage. Probably we should recreate a feature page, describing the current, very heterogeneous, use of the tag.--Polarbear w (talk) 18:30, 14 April 2018 (UTC)
"we should recreate a feature page, describing the current, very heterogeneous, use of the tag", I completely agree (though I am not promising that I will write this) Mateusz Konieczny (talk) 04:48, 15 April 2018 (UTC)

Use for group of features close to each other?

Hi, I have used site relations a few times for groups of lakes that have a name as group instead of or in addition to individual names. One example would be "Hellroaring Lakes" relation 6077541. After reading the proposal again I'm less sure now that this is one of the intended ways of using a site relation, because the relation would not be tagged as a feature: The individual members would already have been tagged as lakes. Instead, the relation only holds attributes relating to the group as a whole as opposed to the individual members. I'm interested in your opinion if this use of site relations is ok, and if not, if you can suggest any alternatives. --Lyx (talk) 21:25, 14 April 2016 (UTC)

The proposal currently says: This relation is understood to group man-made objects. For groups of natural objects which share the same name see proposed relation Cluster. This would be a perfect fit for your lakes. As you noticed, every site relation needs a main tag/feature - so the usage of type=cluster plus natural=lake as members solves the problem of inventing some new site relation types (e.g. site=lake_group or site=natural_cluster).--Jojo4u (talk) 21:37, 15 April 2016 (UTC)
It fits better than site, but in my opinion, inventing relation types for such use cases (e.g. type=lake_group is preferable over very generic relation types like "cluster". It's much more understandable how to use a "lake group" relation or, say, a "street" relation than something more abstract, and it can be specialized for the use case at hand. --Tordanik 14:13, 16 April 2016 (UTC)
I disagree: inventing new relation types for every different kind of members is a sure way to make this "dead data", as no-one will bother to write special software to process a multitude of rarely used and highly specialised relation types. So, a generic approach is needed with all specialisation happening when processing the relation members in their function as independent map features, and only generic functionality like having a name for the cluster or carrying a wikipedia link happening in the relation. --Lyx (talk) 22:19, 16 April 2016 (UTC)
This would need mapping practice and experimentation. Currently I understand type=cluster to only ensemble features of the same tag (from proposal: caves, buildings, lakes, cliff, islands). So the type of cluster is "a group of [tag of the members]". Sometimes this might fail since a pond might belong to a group of lakes. So you would need cluster=lake.
On the other hand the site relation got developed further away from member roles label/perimeter/entrance as laid out in the cluster proposal. So there might be a generic algorithm for site=* like taking the tag of the members and appending site=*_group, e.g. site=lake_group, site=building_group.
The probability of getting both site and cluster in wide usage is smaller than one of them.
--Jojo4u (talk) 12:56, 17 April 2016 (UTC)
Processing a cluster with both lakes and ponds does not need to fail. Applications can handle this in various ways, e.g. by taking the tags which make up most of the members, or by simply taking the first member. When the application renders a the name of lakes and ponds in different styles, rendering the name of a group of lakes and ponds in either style is ok. We should keep the data model simple and leave it to the applications how to use and generalize the data. --Fkv (talk) 09:07, 23 June 2016 (UTC)

impractical Pandora's box

"As @SomeoneElseOSM also noticed, type=site relations are a kind of Pandora's box in terms of usage in a rendering tool chain... They are ill defined, with lot's of degrees of freedom in terms of what can be stored in them (nodes, ways, and even other (multipolygon-)relations), meaning they can be hard to process and making them hard to translate to a relational database schema as e.g. in PostGIS, and difficult to symbolize. Potentially, type=site relations could contain an endless chain of nested relations, as nothing in the Wiki page prohibits or even discourages endless nesting of relations (http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site). I would definitely recommend limiting processing of type=site relations to very specific and hopefully better/well defined sub-cases (if they exist...)." from https://github.com/gravitystorm/openstreetmap-carto/issues/2940#issuecomment-343680705 is a good summary of a problem.

It is extremely complicated to support rendering of such objects Mateusz Konieczny (talk) 17:43, 11 November 2017 (UTC)

Festung Torgau example

It is unclear what is represented by this relation. I created https://www.openstreetmap.org/note/1553070 for now, but unless explained I plan on removing this example from the list. Mateusz Konieczny (talk) 15:49, 7 October 2018 (UTC)

Es ist Eindeutig, was diese Beziehung darstellt, nähmlich die sichtbaren Überreste der "Festung Torgau". Lutz (talk) 11:51, 17 März 2019 (UTC)

Relation:site page has been created

I noticed that User:Geozeisig has turned the Relation:site page from a redirect into an actual documentation page. That may be justified, as site is #7 of relations by uses, but I feel such a major step shouldn't be done sneakily and we should at least make sure nothing important is lost in the move. I've already copied a few (imo essential) paragraphs from the proposal over onto the new page, but I ask the rest of you to also have a look at it. --Tordanik 19:46, 9 May 2019 (UTC)

Is this relation interpreted by any database users?

It's mentioned above that this type of relations could be difficult to handle, since it can contain nodes, ways AND other relations such as multipolygons.

Has this type of relation been intereted and used by any database user, including but not limited to map renderers, routing applications, data analysis, GIS or any other application?

If not, I think there should be a warning about this on Relation:site. --Jeisenbe (talk) 14:19, 13 November 2019 (UTC)

The type=site is rendered on the website historic.place example. Move the mouse over the icon in the middle and all related houses will be highlighted --geozeisig (talk) 07:45, 18 November 2019 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Site&oldid=2517630"