User talk:U30303020

NukSu Kosmos Rules

Hi there. You mind if I ask what the problem with requesting the page be deleted was? That seemed like a good solution to me. It was just taking a long time for an admin to do it for some reason. Requesting the page "cleaned up" doesn't seem right though. As the issue isn't about the quality of the articles content, but more if it should be here in the first place or not. Thanks. --Adamant1 (talk) 01:27, 13 August 2018 (UTC)

I am personally not sure whether it is wise to delete all references to Kosmos rendering, even though it is outdated, but I am not objecting against it. If you want to delete it, simply use {{d|Kosmos is apparently not available anymore}}. This way everyone knows your intentions and there are no empty pages which could have been created by accident. Thanks. U30303020 (talk) 09:15, 13 August 2018 (UTC)

Hi there. Oh my bad. I thought I had requested it be deleted by adding the {{delete|whatever}} thing to it. I must of screwed it up somehow. I'm not really sure if Kosmos references should be deleted either. There's a lot of other Kosmos related pages I requested be deleted like 2 months ago and it never happened. But I was originally doing it as part of the Wiki Cleanup Project thing and I'm not sure what other options there are. The cleanup project page wasn't very clear on it either unfortunately. Oh well, such is life. Thanks for getting back to me at least. --Adamant1 (talk) 09:29, 13 August 2018 (UTC)

I was the one who added the list of defunct projects to the cleanup page. In the specific case of Kosmos there were a lot of links from lists of renders on the main page for various languages that needed sorting out, listing it in a cleanup project lets speakers of that language get involved. Several pages have been removed from the list when only incoming links with historical value were left. You could argue whether or not rules for Kosmos count as having historical value. --Andrew (talk) 11:50, 13 August 2018 (UTC)

Wynndale, thanks for the information. Looking back, I guess fixing dead links like the cleanup project requested was different then getting rid of Kosmos rules wholesale and it was my call to attempt it, not the cleanup projects. Although I do think there might be historical value in saving Kosmos rules, maybe the information should be on a single, clearly "historical" page. As it was, most of the pages I requested be deleted where extremely redundant, if not outright exact copies of other pages like the user pages where, and gave the impression the information was still usable. Although my solution might not be the "best" one, at least it was attempt at remedying things. There's no reason the aggrieved masses can't put the time into creating said page though if history is so important. Then at least things wouldn't be misleading for new users etc. Unfortunately, people like Verdy_P wouldn't allow me to take the step of changing the language in the pages to past tense or even put a banner on them saying the information was outdated. Even after being chastised by an administrator twice for not allowing it. So I guess I won't be the one to do it. Since I don't have enough clout or whatever with the "gatekeepers" like Verdy_P and the others who act in similar ways to him. --Adamant1 (talk) 21:11, 13 August 2018 (UTC)

Network relation is preferred for junction node networks

Hello U30303020,

You just deleted a lot of information about network relations. However, this is still the correct way to group the routes and nodes of a junction network, at least in the Netherlands and Belgium.

Relations are indeed not to be used for a category of things, like cycleways in London, but this is not the case for junction node networks. You just 'deprecated' the tag without discussion on the forum. I restored some text on the inline skating place. Discussion is now taking place on the Dutch forum. Please have a look there before deleting more information.

I felt obligated to do these edits as there was someone new to the wiki promoting network relations for public transport (not in Benelux). The fact is that network-relations in PT have to be updated regularly (at least once a year) which usually does not happen. In addition, there is the network=*-Tag. This combination justifies a classification as a "Category"-Relation for me (the relation contains all bus/tram/... lines with operator=XYZ or network=XYZ).

After using the talk page of this person, I wondered how she/he came up with this idea. I found numerous pages relating to network-relations (most of them regarding Public transport). I purposely only used the ambox template on the dutch pages as I already had the feeling that you probably actively use network relations (should have probably used talk pages instead).

Most of my changes related to one page and their numerous translations. There was a discussion on a talk page the mentioned articles link to (Talk:Relations/Proposed/Network) back in 2014. I basically checked the pages linking to this article.

Just for my personal interest and to understand you: Why do you need a relation like this 25673592567359? Would it not be the same as querying Overpass Turbo for "all nodes with rcn_ref=*" or is that a misunderstanding?

I think you misunderstood the discussion about category-relations. Indeed a category-relation like 'cycleways in London' or 'bus lines by Connexxion in South-Holland' shouldn't be used. However there are actual networks, that are not just a category, but a comprehensive spatial network.

In the last decade consensus about network relations has been reached in the Dutch community about at least the following cases:

* A network of junction nodes. Hiking, cycling, skating, horse riding, paddling and motorboat networks exist. These network relations consist of the routes and junction nodes in such a network. There are a lot of these networks in the Benelux. An example is Fietsnetwerk Midden-Delfland.

* A public transport concession. This is not a category like 'bus lines by Connexxion in South-Holland', but a comprehensive network of bus, tram or metro lines that are sold to one operator for a couple of years. An example is Haaglanden Streek.

Both network relation are approved by the Dutch community. Discussion has been present in the forum and before that in the old-fashioned mailing list.

The use of these kinds of network relations is approved, because of the easy maintenance. Information about the network itself is in the network relation and not on every single route or node. In the Netherlands these kind of relations are well-maintained and updated almost immediately after they change in real life. The network relations is also used to make this validation easier. The validation tool Knooppuntnet uses them for validation junction node networks.

Actually the operator-tags on bus stops in my region are often outdated, while the network relations and the line relations are up to date.

I hope this makes the actual use of network relations for non-categories more clear. For categories the network relation should of course not be used. So I think it is better to add this distinction to the page instead of deleting information and just deprecating a vastly used tag.

Thank you for the explanations.
I did some research about this. Looking over the border to Germany, there seems to be a slightly different approach:

Networks of Junction-Nodes

Discussed in heated debates in 2015 [1], ended up with mappers ignoring each other, some map this as relations/networks, others map other things and do not care. In some provinces they are mapped like in Nordrhein-Westfalen, in others partially only, most of them do not have such networks as someone in the mailing list pointed out. They do have hiking networks apparently.

Public Transport Concessions

The idea of such relations was doomed on the mailing list as they change regularly and have no relevance for the users. A proposed relation schema of the operators themselves is marked as outdated in the English version (not by me). The current situation seems to be that everything is mapped in the route=* or route_master=* relations and network relations are abandoned [2] and ignored [3] (examples: 6626366263 missing underground line 4, 26646362664636 with note=divide, divide, divide). This is contrary to the Dutch approach.

Seen from a more general perspective, there have been some problems with this approach:

Relations become huge and unmanageable: official biking network (ca. 5000 members, > 1000 versions). Solved apparently with superrelations such as 3321633216 which contains relations like "all bike routes in city xyz".

Mappers repeatedly do not understand where to add their relations (some simply place them in the master relations).

Newly created objects are not added to this schema.

This has lead to the passive ignoring mentioned above where some care and create and others do (deliberately ?) state not to update the relations (referring here to PT in specific).

Apparently there is a broader view on this point as I have thought, but also more than what you (A67-A67) said.
We should take all of this into account, create the new article as suggested, and I will fix my changes. Ok? U30303020 (talk) 17:22, 22 August 2018 (UTC)

Thank you for the new page. It gives a good, neutral view of the idea of network relations. A67-A67 (talk) 11:36, 29 August 2018 (UTC)

Rollercoaster in attraction proposal

Just wanted to thank you for the good work regarding archiving the attraction proposal (in particular restoring the original roller coaster description by removing the suggestions how to map the tracks). --Dieterdreist (talk) 10:00, 24 September 2018 (UTC)

You are welcome. It was difficult to find the right version (there were constant changes over the years). U30303020 (talk) 07:23, 25 September 2018 (UTC)