模板討論:重慶軌道交通RDT/環線
由Liuxinyu970226在話題目前版本似乎太過擁擠上作出的最新留言:9 個月前
目前版本似乎太過擁擠
編輯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)
- 你叫誰來都得先把你自己的觀點說清楚。現在甚至不是你沒有prove your point的問題,而是你根本沒有有效地put your point的問題。
- @Bob Wehn:您可否看看上述討論?似乎根本朝向反共識的歪路發展。--Liuxinyu970226(留言) 2023年3月31日 (五) 00:23 (UTC)
- I literally can't understand what you are talking about now.
- 世界最(-)強烈反對,那個英維地上鐵頁面占幅巨大,甚至暗含各種沿線劇透,只會造成更多無緣無故的Lint錯誤。英維那邊討論頁已經有人公開抱怨「This is quite hard to read」。我還是那句話,目前這個環線排版只會造成更多(最起碼數以百萬計)終端設備本可以很容易避免的代碼溢出。--Liuxinyu970226(留言) 2023年3月19日 (日) 04:02 (UTC)
- 問題是這麼緊湊的RDT反而也會對某些視弱人士帶來嚴重的理解問題(不信麼,{{唐山鐵路樞紐RDT}}了解一下,都被多位管理員下場吐槽了說是蜈蚣才看得懂)--Liuxinyu970226(留言) 2023年3月16日 (四) 00:39 (UTC)
- 那個既往討論,如果要我看:
- 關於類似成都等的風格應用到環線上的特殊問題:雖然可以列舉出很多交叉的線路,但一條線路多次出現的時候是沒有、也不太可能連起來的(否則寬度要上天),這樣一定程度上給兩線的拓撲關係的展示帶來了困難和可能的誤導。個人認為RDT承載不了這樣的信息過載,同時一條線的所有交叉線路也並不同等重要。--DvXg 📬 2023年3月13日 (一) 14:15 (UTC)
- 囧rz……唉,怎麼說呢,當年的跟風主義作崇,好些重慶的RDT們都我從英文版搬來翻譯了一頓。--Liuxinyu970226(留言) 2023年3月13日 (一) 13:53 (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的數據服務的。我的主張也並非全盤不列出,而是按同台/直通/並行/共線線路、同期線路、其餘線路的優先級進行篩選,突出重點信息,這在大陸「一切地鐵城軌皆地鐵」、畫餅巨型地鐵網的現狀下尤為重要。全部列出尚有如下幾點阻礙:
- 與縱向信息的展現密度相牴觸,特別是在本線的場景下會影響本線本身的拓撲展現(環狀);
- 在本地的維護強度下無法保證全面且準確。隨着新線增加,需要維護的內容將近似以 的複雜度膨脹,而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的地方我是親眼看到了以下兩段文字重疊在一塊:
- @David Xuang:
- 您應該了解
“ | Out-of-station interchange... ...off-peak service pattern is: |
” |
- 雖然不同瀏覽器的顯示方式有別,我又無能力確認您的電腦上是否能復現,但既然有用戶提出了文字重疊,那麼何嘗不反過來要求英維修改這方面的技術故障,反而是在明知有故障時卻還要求本站希望能從英維借鑑的呢?再說底下legend插入這麼多圖標,誰能認為不是劇透呢:
“ |
|
” |
- 與縱向信息的展現密度相牴觸,特別是在本線的場景下會影響本線本身的拓撲展現(環狀)可閣下推薦的版本不反而造成了與橫向信息展現密度存在更嚴重的牴觸,特別是本應可以進一步寫入的線網關係卻不得不委曲求全另起一節,造成本可以輕鬆避免的超大白色內容區塊?
- 英維當然不是金標準我倒是支持,因為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)
“ | 完整的線網關係應該由地圖(map)而不是示意圖(diagram)展現 | ” |