Talk:Relations are not categories

User issue?

I understand your frustration. Perhaps it's not just users' Wikipedia habits, but something not-quite-intuitive about relations? That would be another way to see this issue. Just suggesting, and spraying plenty of eu de toilette on myself at the same time. :~) --Hubne 12:16, 18 November 2008 (UTC)

Partly disagree

I understand and agree that the footways example shouldn't be relations (except when "Footways in East Anglia" is some kind of network of signed footways, in which case not all footways in East Anglia are part of it, just those belonging to the network).

Now, for the HSBC ATMs I disagree: these ATMs obviously belong together in some special way, and the operator=HSBC can better be moved to a higher level, since it's actually much easier to misspell HSBC. It's really not making it difficult for editors to put these in relations. And I guess that's the main issue you have with relations? That newbies wouldn't be able to handle them, so we have to not use them whenever we can? --Eimai 13:16, 18 November 2008 (UTC)

One of the main issues is that the OSM clients and server do not cope well with large objects, such as a massive relation containing thousands of ATMs. Therefore you should either a) avoid creating large objects, or b) fix all major software and clients for this not to be a problem. I suspect a) will be easier. :) --Richard 13:51, 18 November 2008 (UTC)

Yeah, (a) is easier, but I doubt you seriously think it's the better solution as well... Relations with so many objects already exist and there will only be more of them in future, making it necessary to do (b) anyway or we'd end up with a server and clients that can't handle OSM data. --Eimai 14:37, 18 November 2008 (UTC)

I do seriously think it is the better solution. Working with big objects is never good. Hardware and bandwidth are always finite, and we should keep the barrier to entry for new clients low, rather than requiring ever-more complex programming. Plus, if our (very few) developers are to spend time improving their clients, I would far rather they spent it on UI and accessibility. Infinite-size relations count as "nice to have", not "must have".

Most "large relation" problems could be solved by use of XAPI (or a similar service); better tagging; or nested relations - and client support for the latter would be a more sensible thing to spend developer time on.

We have already seen several problems with the server/connection/client timing out due to ridiculously large objects ([1] is one example), with data being lost as a result. API 0.6 will impose a maximum way length and I hope there will be a maximum relation size, too. --Richard 15:55, 18 November 2008 (UTC)

Well, you can't impose a maximum relation size since the ways to have a tree-like structure for relations aren't ready yet, and then you'd need to adjust all clients anyway to easily allow relations in relations, and all renderers to make use of it. And I don't understand why it's needed to download/upload entire objects anyway, if you have a route relation of 5000km and just see a kilometer of it in your editor, you don't need any notion of the other 4999, right? The great thing with relations is that it's based on objects that have a location, i.e. nodes and ways. So once you know which nodes are in view, you know the ways you need, and with that you can get a list of relations. So no need to download full relations if you know their identifiers, just download their keys and values.

I don't have a lot of knowledge on the API right now, but is there really no option to just download the keys and values and not the members? --Eimai 17:17, 18 November 2008 (UTC)

Well, to some extent - but all sorts of things start causing problems in that case. Our software isn't sufficiently robust to download objects of that size, even ignoring the dependencies. We have a situation right now where someone has (by accident) deleted a relation - a European road, I believe - but the history can't be recovered because the XML parser blows up trying to assemble a document that large. --Richard 22:43, 18 November 2008 (UTC)

Of course we can impose a maximum relation size, and we will. If you want to model something with more than 1,000 members then OpenStreetMap is, at present, not the right tool to do it. Better turn away some users and their ideas of data modelling than risk breaking it for the rest of them. --Frederik Ramm 04:16, 28 November 2008 (UTC)

E-Roads

On Talk:WikiProject Europe/E-road network there's currently a discussion going on, whether there should be a relation which contains all the routes or not. As we can talk to "those who invented relations" here, I want to ask you, what is your opinion. My opinion: I'm strongly in favour of a relation which connects these routes, because you have to save the name of the network only once (but in different languages) and you can have one website (if a tag for this gets finally accepted). And you can define a common layout for the icons, ... So ... what are your opinions on this topic? -- Skunk 10:29, 14 December 2008 (UTC)

We already have a precedent: use the 'network' tag. The National Cycle Network in the UK is defined by "those ways in the UK bounding box belonging to a relation with network=ncn". The E-road network in Europe should be the same. --Richard 15:15, 21 December 2008 (UTC) (who didn't invent relations, but whose editor popularised them ;) )

I think, this is a bad database model. Do applications really have to keep their own database of possible networks? (somebody might want to know the name of the 'e-road'-network). -- Skunk 08:00, 31 December 2008 (UTC)

Reverse Relations?

I was thinking about this whole issue. As I already wrote in E-Roads, to have a relation would allow to collect information about a network at one place. To take the example of the HSBC-ATMs: In the relation we can collect the name of the company in different languages next to the website maybe an address and so on (just examples) - it's much more powerful. I accept that having a relation of all ATMs of HBSC would be very bulky. Why not introduce 'reverse relations' for these cases? There you would apply the membership to the members. The member would hold the information that e.g. 'operator' references some reverse-relation. E.g. operator='#12345' - the reverse-relation 12345 holds all important information. E.g.

Node 1 (name='ATM1', lon/lat=somewhere, operator='#12345')

Node 2 (name='ATM2', lon/lat=somewhere, operator='#12345')

RevRel 12345 (name='HSBC', website='http://www.hsbc.com', ...)

-- Skunk 09:43, 21 December 2008 (UTC)

I've been thinking exactly the same thing; a way to represent non-spatial entities relevant to the spatial ones we are mapping. Since 'Reverse Relation' is a bit bulky, maybe 'Entity' would be a better name for it. --Hai-Etlik 07:50, 3 March 2011 (UTC)

Wouldn't this be solved by creating an empty relation that represents HSBC (as suggested here) and then entering the id of the relation as the operator?

--Matej Lieskovský (talk) 09:57, 19 December 2017 (UTC)

Link to the solution is missing

The link to the Xapi explanation is missing and the Xapi explanation is not translated at all. No wonder that relations are used. --Lulu-Ann 13:19, 9 January 2009 (UTC)

Subway entrances and subway stations

Quote from the text of the page : They are meant to model a close (and usually local) relation between objects, for example: This entrance leads to that subway station

I wholeheartedly agree that this is an extremely useful use of relations :) especially at large stations where several modes of transport interconnect, - it is common to have a bus station, a tram stop, a commuter rail and a mainline station within the same complex and with extremely similar (if not similar) names. A local example for me is the Gare du Nord/Magenta complex in Paris.

However, none of the four established types seems to fit and I haven't been able to select a corresponding type in the proposed ones - of which "site" would seem to be the best match, but there again I'm unsure.

What is your opinion ? I'd be especially interested to hear the writers of the original piece that is featured on this page, since they themselves pushed forward this use of relations !

--232 U 1 19:30, 12 January 2009 (UTC)

What is "HSBC ATM machines"?

Could anybody explain the term "HSBC ATM machines"? I know, that HSBC is the world's largest banking group. Thank you! -- 20:06, 22 March 2009 (UTC)

An ATM is something you get cash from ([2]). --Eimai 20:21, 22 March 2009 (UTC)

Collection relations and wikidata

How about a relation, that adds a general information about the institution?

For example Russian post. There are a few thousand offices and most of them has a wikipedia link to Post Of Russia article. I have been literally instructed that in such case a relation should be created and wikipedia=* and wikidata=* should be only put in the relation tags. Which seems a generally good idea, because some offices may have separate wikipedia articles and with a relation one could have both articles related to the object - a specific one in object's tags and a general one (Post Of Russia) in relation's tags. Rmikke (talk) 09:17, 27 July 2017 (UTC)

Please discuss tagging issues on the Tagging mailing list. There is a much wider audience. You have to subscribe the mailing list before you can post on it. --Nakaner (talk) 18:24, 27 July 2017 (UTC)

No category/object ambiguity when Wikidata in use

Hi, what a "category" is?
The article have problematic assertions for some cases, because people in general not see the difference between the "colective of objects for classification" (a category) and "the object" (that is the whole object with its parts).

When there are a hiearchy of whole/parts, and it is parents are not categories?

Wikidata tag can help us to show and void ambiguities.
... A wheel is not a car, my hand is not I. Wikidata is used to representing concepts, and "a part" is a different concept of "the whole".

--Krauss (talk) 20:57, 3 August 2018 (UTC)

Part/whole cases

Example 1

This is a river relation, a composition of many member-ways, and a whole concept with the Wikidata tag Q6110511. The relation is enveloping the ways, and it is good, it is not a bed application for relation. Lets check a sample of member-ways: way1, way2 or way3. Why only way3 have also the Wikidata tag, and all other ~50 members of the same river have no Wikidata tag?
The answer is: the Wikidata tag is correct in the relation, and it is wrong in the way.

Example 2

The Mosa river (Q41986), is a whole represented by the relation (envelope) 1075197.
There are many other relations, ways and nodes that are parts of relation 1075197. Can they use the Wikidata tag Q41986?
Lets check by Overpass/AM5... Hum, all are with the tag Q41986... So, in strict sense all are wrong.

Example 3

... centroid (node) of a city, that is a "label anchor"... and the relation (administrative) that is the whole... The centroid is an technical artifact to simplify representation, so, in nowadays is commom in OSM to preserve node-centroid and the envelope-relation with the same Wikidata tag.
PS: perhaps in the future we can delete all these "dummy centroids"...

Example 4

...

The whole tagging-conventions

The "database element that represents the whole":

• Exemple of streeets: Relation:street vs Relation:associatedStreet

• Exemple of rivers: ...

The "set of elements with same tag" that repreents the whole:

• Exemple of nodes that are or not "part of the street". See Relation:street#Members, there are two very distinct conventions to the envelope-relation:
  1. the street is only the set of ways;
  2. the street is also the set of nodes (node representing one or more addresses belonging to the street).

• ...

Hierarchies of part/whole and genre/species

...

Categories

... a set of database element that have the same tag but is not a whole, is only a collection of similar or related elements...

Strong oppose to this rule

This rule is 10+ years old when the server infrastructure may have been overloaded and could not cope with larger relations. This may not be the case any more. I propose to delete this rule. At least some relations that hold objects of same type are very helpful for finding these objects and working with them (desktop editors like JOSM etc.) and also for listing objects (all Autobahns in Germany etc.). OSM objects are much more accessible for both viewers and editors when grouped in relations. Connection to Wikidata is another relevant point. Also one does not have to use the queries to list the objects which are very complicated for many people.--Kozuch (talk) 10:17, 14 May 2021 (UTC)

It is still would make editing more complicated for no gain at all, would require wasting massive amount of time to keep them up to date. I see no reason to change practice Mateusz Konieczny (talk) 18:37, 14 May 2021 (UTC)

Examples

Like a lot of pages on this wiki, I think this essay would benefit from some representative examples of the kind of relation that is being frowned upon. For starters, this superrelation encompasses the "Public roads in Romania", each member itself being a category of routes. (I'm waiting for the "Global road network" relation.) – Minh Nguyễn ^💬 20:35, 26 January 2022 (UTC)

Agreed. WW2 Defences of Cornwall (13367998) would also be a good candidate. -501ghost (talk) 00:48, 3 July 2022 (UTC)

The street lights go on at those hours

Let's say there are 57 street lights that go on until 9:00 p.m., and then there are 68 street lights that go on till midnight. Well every time the Streetlight Committee changes the hours do I have to go and edit every single affected street light? Jidanni (talk) 12:02, 16 December 2022 (UTC)

Yes, you do need to edit them separately, but you can run a query with Overpass Turbo to find all the relevant street lights and edit them all at once. A relation would definitely be incorrect here. --501ghost (talk) 12:06, 16 December 2022 (UTC)

Too centralized on Wikipedia?

Wikipedia is not the only wiki that uses categories; there are countless many others. This is pointing towards Wikipedia contributors, and other wikis have the same categories system. Ewrt1 (talk) 05:57, 10 March 2024 (UTC)