Talk:Relations/Proposed/Site

From OpenStreetMap Wiki
Jump to: navigation, search

Contents

Need for the label role

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)

Group of map features

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)

more than one label?

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)

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)

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)

even more roles

I suggest the following roles to be optionally used:

-- 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)

Site key and tagging perimeter vs relation

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)

not connected areas

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

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


What should not be site

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)

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?

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)

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:

Member roles:

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)

address data in a site relation

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)

Retrieved from "http://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Site"
Personal tools
Namespaces
Variants
Actions
site
Toolbox