Talk:Relation:site

Status draft (Moved from Talk:Relations/Proposed/Site)

I do not understand yet why the status was downgraded. Maybe the description is not good enough. Or some mappers do not stick to the description. See the page heritage=* the section Case: a number of related objects are protected e.g. an ensemble. Or the German side of it. (On the English side is additional: site:type=heritage. I do not know if it is necessary.) An example is relation/3288954. Several buildings belong to a monument. The type=site is also rendered on historic.place example. Move the mouse over the icon in the middle and all related houses will be highlighted. Can you explain for me again was wrong with the tag?--geozeisig (talk) 07:45, 18 November 2019 (UTC)

You are right, the status of this proposal should be "Proposed" because there was a RFC email in September 2011 and again in 2015. I have updated the proposal page with the changed status. --Jeisenbe (talk) 07:57, 18 November 2019 (UTC)

The proposal is now very old and no longer relevant. Things just got its way. The status is now at least in use. Of course, we can try to put wrong developments in the right direction.--geozeisig (talk) 14:42, 18 November 2019 (UTC)

This is the talk page for the Proposal called "Site Relation". A proposal cannot have status "in use." The proposal statuses are: draft / proposed / voting / rejected or abandoned. --Jeisenbe (talk) 02:06, 19 November 2019 (UTC)

Sorry but I was redirected from the page Relation:site - Discussion. Maybe we should take the redirection out. --geozeisig (talk) 07:45, 19 November 2019 (UTC)

Note the discussion above was copied and pasted from https://wiki.openstreetmap.org/w/index.php?title=Talk:Relations/Proposed/Site&diff=0&oldid=1923633 --Jeisenbe (talk) 06:39, 10 December 2019 (UTC)

Clarify bolded text

I find the text explaining when the site relation is inappropriate impossible to interpret:

"This relation is not to be used in cases where the element can be represented by one or more areas and neither linear ways nor nodes outside these areas would have to be included or excluded from within these areas. "

My understanding from the proposal is that sites should be open ways, nodes or both. I guess this is trying to say areas can also be members where the site also includes open ways or nodes outside the area(s)? When or how could linear ways or nodes outside an area need to be excluded from within the area? This sounds impossible to me but it's perfectly possible I'm not getting it. Also, by its nature an 'and neither nor x or y' set of clauses is very complex for English. Can we break it into two or three bullet points, like "should not be used in the following situations: x; y; z"? TrekClimbing (talk) 12:01, 15 August 2021 (UTC)

I tried to simplify it, but maybe I lost something important. "ways nor nodes outside these areas would have to be (...) excluded from within these areas" is right now not mentioned - despite being technically true. If there is actual use case for that - then it should be mentioned Mateusz Konieczny (talk) 09:41, 16 August 2021 (UTC)

Thanks Mateusz, the reworded version is much clearer. Regarding excluded from within the area, I'm still not sure I understand. Maybe it's the meaning of exclude since I don't see how the relation can be used to exclude. Is what's meant that if the nodes or lines can be encompassed in areas the relation shouldn't be used? TrekClimbing (talk) 16:22, 16 August 2021 (UTC)

I think that if something is representable as multipolygon then multipolygon should be used instead. Mostly because multipolygons are far less confusing and dramatically easier to map, edit, support and process. Mateusz Konieczny (talk) 08:49, 18 August 2021 (UTC)

Oh, I just noticed this discussion. I wound up undoing the bullet points, but hopefully the sentence ended up straightforward enough that it's no longer needed. I did break up some of the counterexamples into more digestible bullet points. – Minh Nguyễn ^💬 07:13, 19 August 2021 (UTC)

Historic districts

In the United States, historic districts on the National Register of Historic Places or another register (heritage=*) are sometimes defined based on bounding streets, which would call for some sort of place=* area representation perhaps. But sometimes they're defined in terms of a list of buildings themselves, scattered around a neighborhood with plenty of non-contributing buildings in between. I'm inclined to view the latter as a good use of site relations as opposed to multipolygons, even though the contributing buildings are typically already mapped as areas. In my opinion, the shape of each individual building is irrelevant to the historic district as a whole, but the spatial relationship among the buildings is relevant. No one considers themselves to have "entered" the historic district when they enter one of the contributing buildings, but they have visited the historic district. I don't feel particularly strongly about using a site relation instead of a multipolygon, but it seems reasonable in this case. – Minh Nguyễn ^💬 20:53, 19 August 2021 (UTC)

Noticed Key:heritage#Case:_a_number_of_related_objects_are_protected_e.g._an_ensemble had been wrongly suggesting to use site:type=heritage instead of the standard site=*. ---- Kovposch (talk) 04:23, 20 August 2021 (UTC)

On the topic: Is the lot of the building included in the historic district? If the conservation is focused on the structures, this would be true. ---- Kovposch (talk) 04:43, 20 August 2021 (UTC)

@Kovposch: The federal NRHP has much weaker protections than state and local historic preservation programs and has a much more limited definition of conservation than one might expect. If I'm not mistaken, when a building is listed either on its own or as a contributing property in the NRHP, it's normally just the building unless otherwise specified. [1] That said, there's plenty of gray area, another reason not to focus too heavily on the precise boundary of the district in these cases. Sometimes not even the whole building is considered to be contributing. – Minh Nguyễn ^💬 06:10, 20 August 2021 (UTC)

Why no relation members allowed?

Does anyone know why relation members are not allowed for site relation? So it is unfortunately not possible to have other sites or buildings with building parts as members, which is sometimes needed for heritage sites. See this example: while it was possible to use the way of Schloss Sanssouci (which is part of another relation) as member, it is more difficult for the many separated areas of Weinbergterrassen. It is more practical to let this areas be grouped and add the relation to the parent relation "Schloss Sanssouci mit Kolonnaden und Weinbergterrassen", which is a heritage site (so this example breaks the rule). --Sinuhe20 (talk) 15:30, 27 June 2022 (UTC)

First of all, type=multipolygon should be allowed as . It's a common oversight in wiki. Proposed features/Site Perimeter shows this.

Usually nesting inside another is avoided to reduce complexity. Can you explain the situation here? type=site is used for single entity. Can type=cluster be used for the latter 9674821 9674821? Since it is a group or landscape.

--- Kovposch (talk) 06:35, 28 June 2022 (UTC)

So you think Weinbergterrassen should have been modeled as multipolygon? Ok, that's possible, I see it's more common to use the main outlines as members than the relations. But Relation:boundary also allows relations (subareas) as members. --Sinuhe20 (talk) 10:37, 28 June 2022 (UTC)

subarea is discouraged. It is not necessary. --- Kovposch (talk) 06:44, 6 November 2022 (UTC)

I wanted to combine several different objects, including multipolygons, into one object. In my case, these are municipal schools and kindergartens. As opposed to schools of regional subordination in the same territory.

I can use the "owner" tag. But compiling such a list through the search is not a trivial task, you need to know what parameter to look for.

In my mind, a relation can be a good helper. Maybe I should use another method? -- dr&mx (talk) 10:11, 4 November 2022 (UTC)

1. No, you should not do that. They are not one thing together, but different things of their own.
2. No, it's not that difficult. You can add ownership=* and owner:wikidata=*, in addition to owner=*.
3. Relations are not categories

--- Kovposch (talk) 06:48, 6 November 2022 (UTC)

How should I describe an object that consists of a school grounds as a multipolygon and a node with the tag of a school for young children, which is located two streets away?-- dr&mx (talk) 08:52, 6 November 2022 (UTC)

How related are they ? --- Kovposch (talk) 12:54, 7 November 2022 (UTC)

Two parts of one school -- dr&mx (talk) 17:49, 7 November 2022 (UTC)

That's a question of what is a "school" feature. In amenity=university which we don't use for relating the entire university organization only, brand=* has been experimentally used to show different campuses of the same university organization. So similarly the meaning of amenity=school and amenity=kindergarten may be treated as campuses.
Unless their curriculum and operation are integrated within a single level (eg grade 1--3 and 4--6 in separate detached campuses for the same primary school, with direct progression, no graduations), I won't use an amenity=* to include both of them. landuse=education including the two amenity=* could be acceptable, if they are close enough.
--- Kovposch (talk) 21:17, 7 November 2022 (UTC)

Useful for a collection of information boards?

There are a series of information boards in Wisconsin which are all under the Wisonsin's Maritime Trails umbrella. Would tying these together into a Site relation be an appropriate use of this feature, or is another feature better suited for this relation? Or should all these boards just exist as-is with no relation between them? Mecheye (talk) 17:43, 28 June 2023 (UTC)

guidepost is included in route=foot . It seems natural to include boards of the trail. But there was an argument on the appropriateness and method concerning information in Talk:Relation:route#role=information for related features. --- Kovposch (talk) 10:39, 29 June 2023 (UTC)

Oh sorry, it's not a walking trail. They look very far apart though? Maybe eg network=* or even brand=* is better? subject=* would already be used for the ship. The name=* or title=* may include next line (sub-title?) of "Wisconsin’s Maritime Trails" ie "Historic Shipwreck", up to the ship name. --- Kovposch (talk) 13:05, 29 June 2023 (UTC)

Yeah, it isn't so much a "trail" as it is a collection of boat-related information boards! Good shout on the network=* suggestion, I'll add that in. Thanks! Mecheye (talk) 13:18, 29 June 2023 (UTC)