Template talk:重庆轨道交通RDT/环线

目前版本似乎太过拥挤[编辑]

RT，要是能改写成类似{{北京地铁RDT/2}}、{{北京地铁RDT/10}}、{{上海地铁RDT/4}}会不会更好些？或者是{{成都地铁RDT/7}}、{{哈尔滨地铁3号线RDT}}--Liuxinyu970226（留言） 2023年3月13日 (一) 13:13 (UTC)[回复]

希望同样编辑过这个的@Yy6941、Htmlzycq、Owennson、RedLightPOP、Dimlys1994、David Xuang、D0GXXX 1981发表己见。--Liuxinyu970226（留言） 2023年3月13日 (一) 13:29 (UTC)[回复]

这个模板最开始是我在英维实现的，排版的风格也更接近英维（参见en:Circle line (London Underground)），之后有其他用户将其搬到缺少RDT的中维，后续我也有同时更新两边的模板，这是现状的由来（以及，其实之前因为空缺被搬到中维的重庆RDT并不只是这一个）
个人认为中维本地流行的RDT风格（以及日维）在信息传达方面是存在严重的问题的（层级不清、主次不分等等），此前曾发起过讨论（WikiProject_talk:城市軌道交通#失控的RDT）
造成拥挤的原因之一就是您加入了和环线并没有什么关系的27号线吧，能阐述一下理由吗？

--DvXg 📬 2023年3月13日 (一) 13:43 (UTC)[回复]

囧rz……唉，怎么说呢，当年的跟风主义作崇，好些重庆的RDT们都我从英文版搬来翻译了一顿。--Liuxinyu970226（留言） 2023年3月13日 (一) 13:53 (UTC)[回复]

在文种不同的基础上，由于汉字在相同点数下占的空间更满，直接照搬后中维的版本可能会显得文字行距不足，这一点我是同意的。但因为行距显得不足就滥加交叉线路以期拉开行距我觉得是需要商榷的。--DvXg 📬 2023年3月13日 (一) 13:55 (UTC)[回复]

Hmmm，你再读一遍我说的话，看看我提到的讨论串，我反对的就是你举的例子里的风格。那个讨论串就是其他RDT被改成本地这种啰嗦的风格的时候我发的，只是最后也没有具体的共识才一直搁置。--DvXg 📬 2023年3月13日 (一) 13:59 (UTC)[回复]

关于类似成都等的风格应用到环线上的特殊问题：虽然可以列举出很多交叉的线路，但一条线路多次出现的时候是没有、也不太可能连起来的（否则宽度要上天），这样一定程度上给两线的拓扑关系的展示带来了困难和可能的误导。个人认为RDT承载不了这样的信息过载，同时一条线的所有交叉线路也并不同等重要。--DvXg 📬 2023年3月13日 (一) 14:15 (UTC)[回复]

那个既往讨论，如果要我看：

“本地普遍滥用HUB”一点似乎确实受日语版影响颇大，这一点我曾通过某特殊渠道联系到日语版的一位管理员，按ta的说法，日本的“换乘站”们往往基于ta们的民族主义风格（或者情绪）更注重所谓“路线集团”及“实用主义（我不知道这样翻译utilitarian是否妥当）”，于是是个“换乘站”就都HUB组团贴上（哪怕站名不同的情况也给...），不过近几年到也出现一些TINT系，反而KBL啥的那边用的鲜少（还是那人说法，因为要考虑到Suica、Pasmo、ICOCA等各大IC卡带来的行为便利），ta甚至解释到为啥日语版迄今对于将RDT内容模板化持消极态度（ta们没几个RDT是实打实模板，很多都一直直接放正文的），就是为了防止部分标签被多领域滥用造成验证侵权工作上的困难。
至于(u)vSTR、(u)vBHF，不扯远，1号线的某段错位问题让我感受到这两种v真的适合本站么？这种东西以我理解会不会更适合用在几乎无交叉的共线或双线的情况下？但是对于大中华地区，就我所知的路线共线情况，光上下行就很容易在某些节点存在多次交叉，或是大型号道岔联络，更遑论各种渡线侧线啥的。
KDST（可能也涉及KBST）也是一个令我感到揪心的东西，英维那边但凡编辑纽约或者伦敦相关的，就我所知都不止一次抱怨KB/DST定义不明，有些语言读者可能误以为是货运车站或者halt（讲真我真不知道railway halt翻译成中文究竟应该是什么，说信号所/号志站吧有时又不一定有信号设施，说车厂啥的，问题是绝大多数东南亚的halt很可能只是单线路段上一小段复线段就可以叫halt，根本不会有管理房屋），英维那边现在一直提倡用YRD替代KB/DST以避免概念争议。
站点大小这事（也就是HST相关）觉得应该支持尽量推广，没准以后大陆会各种快慢行车模式，或是跨线车遍地开花呢。
最后(u)tINT是啥啊？总感觉这东西更像是没画完的十字换乘？

--Liuxinyu970226（留言） 2023年3月13日 (一) 14:31 (UTC)[回复]

这些都不是最大的问题，最大的问题是仅仅交叉一次的线路就要列出不合理，起码作为线路导读部分做提示用的图不合理。要看线路交叉关系的应该去找线网图和配线图。

就这几点而言的话

v系列我个人只在并行线以及支线分叉前的并行区段用。1号线的用法不太对，拐弯的图标都是错的。后面的问题不太理解在说什么。
DST本来就是车厂/货运车站的双重定义。halt应该是HST。YRD看名字的确是yard，但是既然在commons被定义为line feature，似乎本意是指货运编组站。在本地其实不算太大的问题，有文字配注，读者也不会认为线路外的设施是货运站或者小站。
小站问题还是没有既有的划定标准，也没什么可能的标准。快慢车是有pBHF的。
TINT没有特殊含义，就是表面看上去的元素的组合。其中因为有一些兼容性问题，一直用着旧版INT的样式没有重制，所以看上去可能有点奇怪。

--DvXg 📬 2023年3月13日 (一) 15:40 (UTC)[回复]

TINT参见c:Talk:BSicon/Icon_geometry_and_SVG_code_neatness/Archive_4#TINT_interchange_stations—DvXg 📬 2023年3月13日 (一) 15:44 (UTC)[回复]

问题是这么紧凑的RDT反而也会对某些视弱人士带来严重的理解问题（不信么，{{唐山铁路枢纽RDT}}了解一下，都被多位管理员下场吐槽了说是蜈蚣才看得懂）--Liuxinyu970226（留言） 2023年3月16日 (四) 00:39 (UTC)[回复]

这程度离唐山那个还差得远呢，起码这图是一行最多一站……和这个模板类似风格的en:Circle line (London Underground)的图也一直没见改，在MOS:亲和力都不是指引的中维说这个，说服力实在是不强。不过我觉得本地的{{Routemap}}也许可以考虑一下在其他尺寸不变的前提下略微缩小文字号数，这样连续的行不至于显得距离不够。--DvXg 📬 2023年3月16日 (四) 01:21 (UTC)[回复]

唐山那个图可以考虑参考en:Template:Overground_RDT改改，用横向展开改善一下排版。中维常见绘图样式的纵向延展太离谱了，按理来说枢纽图这种东西纵向不应该超过一屏的。--DvXg 📬 2023年3月16日 (四) 01:26 (UTC)[回复]

世界最(－)強烈反对，那个英维地上铁页面占幅巨大，甚至暗含各种沿线剧透，只会造成更多无缘无故的Lint错误。英维那边讨论页已经有人公开抱怨“This is quite hard to read”。我还是那句话，目前这个环线排版只会造成更多（最起码数以百万计）终端设备本可以很容易避免的代码溢出。--Liuxinyu970226（留言） 2023年3月19日 (日) 04:02 (UTC)[回复]

I literally can't understand what you are talking about now.

什么“剧透”？
什么“溢出”？

--DvXg 📬 2023年3月19日 (日) 08:34 (UTC)[回复]

@Bob Wehn：您可否看看上述讨论？似乎根本朝向反共识的歪路发展。--Liuxinyu970226（留言） 2023年3月31日 (五) 00:23 (UTC)[回复]

你叫谁来都得先把你自己的观点说清楚。现在甚至不是你没有prove your point的问题，而是你根本没有有效地put your point的问题。

轨道线路图的“剧透”是什么问题？“代码溢出”又是什么黑话？（很明显，这个模板并没有超出模板展开大小限制）如果你不明白自己正在搬弄的技术名词是什么意思（比如“Lint”），最好就不要使用。
“这么紧凑的RDT反而也会对某些视弱人士带来严重的理解问题”到底体现在哪里？有没有考虑过你推崇的中维/日维画图风格塞了过多无用信息，反而会对所有不特定读者带来信息获取的障碍呢？比如你维护的Template:重庆轨道交通RDT/1，无关线路杂乱无章、文字注解没有用字体大小体现信息层级（车站信息很显然比隧道、站场重要），18号线连起来了但没有完全连，还在明明可以用45°倾角线路的地方用了连续超过三个90°转弯（小龙坎附近），让我怀疑你对示意图的理解到底为何？我是真的不理解，略去多余线路、尽量一行一站的展现方式为什么会被指责为对视障人士亲和力不足。

--DvXg 📬 2023年3月31日 (五) 09:30 (UTC)[回复]

个人认为仅包含对应线路的RDT不如车站列表。

就本人在城市轨道交通范围内对RDT的理解，就是保留线网图对应线路附近的所有元素（包括简单的相交），拉直展开。若是环线还需要找到一个合适的切断处。存在实体的同级和更高级的轨道交通（就本人目前遇到的即国铁主线和同一轨道交通系统的线路）均须保留，不存在所谓的“多余线路”。故本人(＋)傾向支持Liuxinyu970226的主张。

关于车站拓扑关系问题，本人认为由于交叉的线路之间并不是孤立的，所以有必要将其表示出来。而在使线路之间的关系更加紧密的换乘站就更有必要将其展示。不过简要描绘，与条目互相印证，形成类似的对称约束即可。

关于模板过长的问题，如有必要，请使用{{Routemap}}的startCollapsible功能，如{{台灣高速鐵路RDT}}的大量隧道。就当前模板，如有兴趣，可以参阅本人自用的修改版。

就与{{唐山铁路枢纽RDT}}类似的复杂网状结构而言，在有方便的维护工具的前提下，可以考虑en:Template:Overground RDT的排版方式。

不过，Liuxinyu970226的部分解释需要进一步阐释，David Xuang也切不可直接引用英文维基。就本人看来，精简过于复杂冗余的CRT早期模板固然是好事，但David Xuang的主张似乎有些矫枉过正。

以上均为本人当前的个人观点，可能存在疏漏、不恰当、错误甚至自相矛盾之处，且本人不善言辞。建议重启讨论，取得普遍共识并定下正式规则。祝两位编安。Bob Wehn（留言） 2023年4月1日 (六) 14:07 (UTC)[回复]

您应该了解startCollapsible的样式存在诸多问题，在稍复杂的场景下即会出现展开与原本的行无法纵向对齐的问题，折叠状态下的问题亦需要在展开时手动遮盖，不堪实际场景使用。

列出所有相交线路在并不显然是应然的，这应当首先仰赖于类OSM的数据服务的。我的主张也并非全盘不列出，而是按同台/直通/并行/共线线路、同期线路、其余线路的优先级进行筛选，突出重点信息，这在大陆“一切地铁城轨皆地铁”、画饼巨型地铁网的现状下尤为重要。全部列出尚有如下几点阻碍：

与纵向信息的展现密度相抵触，特别是在本线的场景下会影响本线本身的拓扑展现（环状）；
在本地的维护强度下无法保证全面且准确。随着新线增加，需要维护的内容将近似以 $O(n^{2})$ 的复杂度膨胀，而CRT的系列条目即使在现状下即缺乏维护（新车站无人建条、时刻表更新滞后种种）；
英维当然不是金标准，但同时本地/日维的实践有着强烈的WP:FAN色彩，伴有作图能力缺失（滥用基本图标导致示意图过于复杂），这一点是我希望能从英维借鉴的。

--DvXg 📬 2023年4月1日 (六) 15:31 (UTC)[回复]

@David Xuang：

```
startCollapsible
```
就算存在诸多问题，但是中文维基社群数十年以来都习惯了，凭什么就阁下一句抱怨我们就要摒弃一个早已入乡随俗的变量呢，要按这说法岂不是中文维基社群应该彻底抛弃各种{{navbox}}们。
本地/日维的实践有着强烈的WP:FAN色彩要按这说法每个线路及车站条目底下的站点导航模板（例如{{北京地铁14号线}}、{{广州地铁13号线}}啥的）也别要了，那些也是日文学来的
这在大陆“一切地铁城轨皆地铁”阁下究竟是否来自大陆？如果是那么是否了解《关于印发“十四五”城市轨道交通规划建设实施方案的通知》（虽然网络上找不到原文但至少我有幸通过特殊渠道阅读过其中部分），其中明确提到要求申请修建地铁城市沿线中心城区每平方公里人口要三万以上（人口密度），而城轨则不需要遵守这一要求
至于此前阁下反过来ad hominem我说轨道线路图的“剧透”是什么问题？“代码溢出”又是什么黑话？^{[開玩笑的]}我又再三访问了英维的en:London Overground一文，在插入那个Overground RDT的地方我是亲眼看到了以下两段文字重叠在一块：

“

Out-of-station interchange...
...off-peak service pattern is:

”

虽然不同浏览器的显示方式有别，我又无能力确认您的电脑上是否能复现，但既然有用户提出了文字重叠，那么何尝不反过来要求英维修改这方面的技术故障，反而是在明知有故障时却还要求本站希望能从英维借鉴的呢？再说底下legend插入这么多图标，谁能认为不是剧透呢：

“

Station National Rail

Accessible station Thameslink

Interchange station Elizabeth line

Accessible interchange Docklands Light Railway

London Underground

Internal interchange London Trams

Out-of-station interchange London River Services

”

与纵向信息的展现密度相抵触，特别是在本线的场景下会影响本线本身的拓扑展现（环状）可阁下推荐的版本不反而造成了与横向信息展现密度存在更严重的抵触，特别是本应可以进一步写入的线网关系却不得不委曲求全另起一节，造成本可以轻松避免的超大白色内容区块？
英维当然不是金标准我倒是支持，因为ta们的标准有时候更像是渣标准，ta们一股脑封杀CGTN，我们却没有（而是综合上下文考虑涉事CGTN来源是否可靠），ta们清一色认为南华早报是普遍可靠来源，我们也没有（而是有时需要避免提及早报中极端偏激的一手报道）
最后阁下提供的回退理由中最后一句话在维持当前线路收录标准统一性的前提下暂时移除我反而希望阁下好好解释一下，MOS我是没听说过这个要求。

--Liuxinyu970226（留言） 2023年4月2日 (日) 02:20 (UTC)[回复]

startCollapsible的问题严重到折叠与非折叠部分之间完全无法对齐，最近编辑en:Template:CRT Line 5尝试了多种语法仍然无法让江跳线折叠的同时正常对齐，如果你觉得这可以忍受我实在无话可说；
滑坡谬误、稻草人谬误；
成都地铁18号线、北京地铁亦庄线这类线路放在其他地区（S-Bahn、RER、JR、大手私铁）都不会首先考虑由地铁运营，这才是我说的“一切城轨皆地铁”；另，在维基少玩查成分、开盒那套话术，这是在玩火；
给出的文字甚至不在同一个section，Windows和Android上的稳定版Microsoft Edge、ESR版Mozilla Firefox以及维基百科安卓客户端均无法复现，并且无法证明此渲染问题与其采用的绘图方式有任何联系，如果问题是在Safari上那应当优先考虑是Safari的bug，毕竟一个行内插入的table元素与下一段发生overlap无论如何不是W3C标准下的正常渲染行为；“剧透”这个词仍然用得莫名其妙，实在无法理解一个图例和“透露读者可能尚未观看的影视作品内容而损害其体验”有任何关系；
完整的线网关系应该由地图（map）而不是示意图（diagram）展现：地图的变形已经很严重了，变形到完全没有方位信息的{{Routemap}}更无法承担展示线路关系的作用；究其本意，示意图应当起到类似车站屏蔽门顶部信息版的“重要信息导览”的作用，Routemap不是配线图；具体到本例，主条目重庆轨道交通的线网图和重慶軌道交通環線#车站列表所展示的线路走向图才是应当完整展现线路拓扑关系的处所；我说得应该够明白了，无论如何示意图干不了展示线网关系的事，因为现实中的线网关系不只是拓扑关系，舍弃了方位信息的纯拓扑信息没有单独展示的价值，特别是在CRT就没有一条接近直线的线路的现状下，单开一节也解决不了问题，唯一正确的实践是插一张正儿八经的插图专门展示线路走向和线网关系；
和主题无关；
这是暂时性回退，因为现状下实在没有不展示其他线路而一定要展示27号线的必要性，特别是在27号线在南岸甚至不与环线换乘的情况下。条目应保持自身的一致性，要加也应该全加。

--DvXg 📬 2023年4月2日 (日) 05:50 (UTC)[回复]

另，虽然阁下的攻击有立稻草人之嫌，但重庆轨道交通目前确实使用的不是日维式的站点导航模板，而是统合为单一模板以提高阅读体验。参见Template:重庆轨道交通车站。--DvXg 📬 2023年4月2日 (日) 11:49 (UTC)[回复]

@David Xuang

“

完整的线网关系应该由地图（map）而不是示意图（diagram）展现

”

真当中华人民共和国测绘法不当回事？--Liuxinyu970226（留言） 2023年11月5日 (日) 10:23 (UTC)[回复]