User:快乐的老鼠宝宝

From OpenStreetMap Wiki
Jump to navigation Jump to search
 快乐的老鼠宝宝 (on OSM · edits · contribs · heatmap · comments)

关于我

简介

`快乐的老鼠宝宝` is a user living in Mainland of China.

Message on this wiki usually will not be respond at once, you can try to email me!


语言 用户框
Babel user information
zh-N 中文是这位用户的母语。
zh-Hans-N 简体中文是这位用户的母语。
en-2 This user has intermediate knowledge of English.
ja-1 この利用者は初級の日本語ができます。
Users by language
查户口
This user submits data to OpenStreetMap under the name
 快乐的老鼠宝宝 (on OSM).
I support OSM by being a member of the OpenStreetMap Foundation. Are you?
cat silhouette This user…       
      …is not a cat.
活跃地域
This user hails from China.
快乐的老鼠宝宝 has mapped in the People's Republic of China
快乐的老鼠宝宝 has mapped in Japan.
使用的编辑器
JOSM 快乐的老鼠宝宝 submits data to OpenStreetMap using JOSM.
iD 快乐的老鼠宝宝 submits data to OpenStreetMap using iD.
使用的平台
Firefox 快乐的老鼠宝宝 prefers Mozilla Firefox.
operating system icon
Windows logo
 快乐的老鼠宝宝 uses Windows
operating system icon
Android logo
 快乐的老鼠宝宝 uses Android

污点

“呐……人家……已经不干净了呢……”

论述

不要滥用official_name作为正统（也不要过度简化）

现在有些国内绘图者，觉得找到了一个冗长繁杂的学名，就要一字不落的照搬照抄，这样不好。

OSM的name代表的是大家常用的名字，有代表性的名字。如果一定要凡事就上溯到学名，觉得这样才高级才算写对了写全了写出它本来的面目，搞书呆子主义，茶园的produce是不是也要填写“ Camellia sinensis(L.)O.Kuntze” 而不是 “tea” 啊？(后注：这种生物学名确实存在，OSM中的spcies就是要写学名的)

例如https://zh.wikipedia.org/wiki/%E9%A6%96%E9%83%BD%E5%8C%BB%E7%A7%91%E5%A4%A7%E5%AD%A6#%E9%99%84%E5%B1%9E%E5%8C%BB%E9%99%A2%E4%B8%8E%E4%B8%B4%E5%BA%8A%E5%8C%BB%E5%AD%A6%E9%99%A2 这里面的医院名字，name就应该是“北京天坛医院”而不是“首都医科大学附属北京天坛医院”，也不要走过度简化凡事简称缩写的路子写成“天坛医院”，前者应当是official_name，而后者则可以是short_name与alt_name。

台湾编辑者琉璃百合之前在“用正确的标签做正确的事”一文中举的St. St. 的例子，就是讽刺过度缩写的一个例证。大家是要站在中文母语使用者的角度，把最日常最常见的东西，展现出来的。

2022年3月6日，北京时间21:05 第一稿

2022年7月8日，北京时间22:15 修正与增补


项目

项目开展原则

  1. 有能力上GSoC的，对更多人有贡献的，优先上GSoC；
  2. 上不去GSoC的，争取以OSMChina的身份上OSPP
  3. 依然上不去的的，搞好与诸学生联盟合作，争取上车机会。

项目与相关组织

OSMChina

Geo-Yuheng

LaoshuBaby

  • python-NSI （名字重新起，会是一个各个编辑器preset的中心化产物，可以往各个需要preset的地方转译，可以理解为babel）

不成熟的想法

鼠宝宝允许任何人不使用评论区直接在正文中添加内容和发表评论，但禁止任何删除，只有我可以。

对于不成熟的想法，这里按照完善度分为了 IDEA（只是有一点概念性的想法）、PRE_PROPOSAL（有一些具体的想法）、PORTAL（）几个等级。

对于PRE_PROPOSAL分类的想法，可能在未来直接移动出去，单独开一个Proposal页面供讨论和投票。仍在Idea阶段的，需要进一步的完善。

较完善的想法和已经足够成熟的方案，可能移动到待完善的草案中，未来将试着向社区提出。（目前它们存在于我的个人页面而不是社区文档的主要原因，其实只是因为它们尚未被广泛讨论或认可，以及仍有修改空间，因此仅作为个人标准采用，当然也欢迎其他人来参考。）

Portal可能永远不会变成单独的页面，而是作为一种政见和主张存在。可能未来会单独单开一列。

IDEA: 期望在未来提出的Tag

IDEA: 未能解决的note

IDEA: 驾校道路用途标签化

北京市驾校补全计划

参看 http://bj.bendibao.com/zffw/20061122/15522.shtm

东方时尚http://www.dfss.com.cn/#/ 龙泉驾校http://www.lqjx.top/ 京都府驾校（官网可信度未考据，应该可以）https://www.jdfjx.com/bancheluxian/266.html 北京公交驾校（官网可信度未考据，应该可以）https://www.gjjx.com.cn/ 海淀驾校（官网可信度不高）http://m.haijia.com.cn/ 远大驾校（没找到官网）

程序化处理

可以考虑给不同类型的道路弯道直道之类都加上标签，或者在service之外另外设立一种驾校路的标签，出于渲染兼容性建议service=training/practise之类的

IDEA: 中国长城

[out:xml][timeout:255];

Template:GeocodeArea:中国->.searchArea;

nwr[historic=citywalls](area.searchArea);

(._;>;); out meta;

目前来说，单纯使用这样的标签查询全国的城墙很难专门把长城提取出来，如果是希望在地图上单独渲染长城这一条线的话是比较难以单纯依靠OSM获取数据的，因此希望开一个proposal专门设计一个tag用于描述中国长城，而且为了不和现有的工作流产生冲突，我们还是希望能在citywalls=*下面设计一个value而不是在historic下面，毕竟长城确实也是一个比较特殊的城墙。

IDEA: 千万不要睡过头也千万不要上错车的车

这里记载一些我认为比较算得上神车的车，会希望在OSM里面复刻这些逆天交路，虽然不太可行。毕竟OSM能收录各种本线各停的关系就不错了。而对于中国国铁，能知道到站就不错了，到达站台是经常变的。根本就没法画进去。除非你有一整本JR时刻表和CR的内部调度资料。

（为什么没有新干线的のぞみ和ひかり列举进来呢，因为大家都知道它可能是什么以及可能会发生什么，而且买票指定席都会有告知时间，你不会当作普通的各停车混在一起的车去坐）

  • CR-杭州，下一站深圳
  • CR-天津，下一站南京南
  • CR-南昌，下一站北京

“稍微睡一觉，等会起来上班有精神” “卧槽？这下要旷工了”

  • JR东日本-ひたち/ときわ（上野-水户）

“啊是常磐线，是6号/8号站台，那待会就能回松户了” “卧槽？是水户？”

  • JR东日本-はやぶさ（大宫-仙台）

“回家吧，睡一觉就到宇都宫了” “卧槽，见鲁迅去了？”

  • 小田急-スーパーはこね（新宿-小田原）

“啊打算去町田找朋友玩呢，这个车快一点，上车再补票吧” “卧槽，下一站就看猴子提灯去了？”

  • 京阪-洛乐快速特急
  • OGF世界-BIWAHIME

IDEA: 立交桥用途标签化

如上，给不同匝道都补全，各部分加标签并且能够自动判断是什么类型，方便程序化分析立交桥成分是苜蓿叶还是什么涡轮之类

IDEA: 日本停车场问题

如图， https://imgur.com/a/gVkN5WD 这样的日本停车场，你要如何才能把这里面的关键点正确传达出来并且用OSM标签来表示呢？

其实已经有符合这样图中的案例出现了：https://www.openstreetmap.org/way/1508890300

目前的Key:charge和Key:capacity都没法准确描述这种含有分时段最大料金和部分车位可用的容量情况的事实

另外，就算是知道了各个停车场的位置，真的到了GW高峰期找车位的时候也是一个车位难求吧？也不可能接入各家停车场的空位展示系统的。


IDEA: 日本营业时间问题

例如下面的这样的营业时间在日本是很常见的

営業時間 11:00〜22:30（OS22:00）
※店舗の状況により変更になる場合があります。
定休日 第3水曜日 ※祝日の場合は翌日

但是用OSM的opening_hours=*的话要如何标识呢？

IDEA: 日本建筑物桥梁纪年法问题

在日本记录建筑物和桥梁等工程的年份（尤其是是有定礎（ていそ）的时候），很多都是用和历来记录的，昭和平成令和都有

但是start_date=*是要转换为公历的，希望找到一个能记录原始数据不要进行任何转换的东西，类似gramps里面记录人的生平都是优先记录原始数据，仅在内部参与运算先后的时候会使用公历

因此我想到习惯性的加:ja或者:JP之类限定符，我用了一个start_date:ja=*然后发现已经有很多前辈先先后后的使用了二百多次了（不过确实没有start_date:JP=*）

大概回头还要把之前遇到的有日期的桥梁，如果我强制写了公历的，大概还要再追加一个和历（那么就要牵扯到另一个问题了，如果一开始写的“一九六四年十二月三十一日”这种算不算:ja，或者如果直接写的1964年12月31日，是不是可以来一个 start_date:ja=no？）

然后查了一下，目前有单独分语言的start_date=*的，就是只有start_date:ja=*和start_date:fr=*两个，很好奇为什么法语会有单独的，但明明欧洲国家是用公历的啊。汉语和韩语的没有单独分出来，大概是因为这两个国家都是直接公历纪年的，所以基本是一比一转换并不存在“需要记录原始的非公元纪年的文本”的问题。（但是阿拉伯语地区的很多物件是否会有使用伊斯兰历记载的问题呢？）

IDEA: 日本邮编符号在地址的问题

在日本大部分场合下邮编前面会加一个〒符号，但在OSM数据中日本地址目前尚未明确是按照何种方式记载，日本邮编目前是否中间加入分割线也尚未达成共识。

至少在addr:postcode=*里面是没有对这种场合进行规定的，而日语页面则是多年来一直空白。

嘛，这个我觉得可能讨论起来会比较方便，至少比东亚的是否加号要方便。

另外日本还有一种问题是地址是否使用全汉字还是尽可能转换为数字，如 https://www.openstreetmap.org/node/13875821434 中就对照官方地址使用了汉字作为丁目和番地的表示。实际上注意到生活中习惯把番地保留汉字而丁目留数字，那么OSM这边有成文规范吗？

PRE_PROPOSAL: 照明类型

这个实在太混乱了，我是建议分为如下的两个key：

  • lit:type,用于分类区分非描述光源特性的属性。
    如是作为路灯？建筑物上的灯？在招牌上的灯？固定的？（hangged/street lamp/billboard/landscape lights）
    或者另外一种分类方式是物体本身会发光？其他东西去打灯照着？（我想不出value）
  • lit:source，值可以是led/sodium/gaslight
  • lit:color_temperature，值从1000K-10000K等

PRE_PROPOSAL: 大仓库旁边卡车专用的区域标注

例如如下所示的 https://imgur.com/a/e7kH8vm 特点是：基本是敞篷而且只能用来卡车卸货的时候不要淋雨用，可以横着进入可以竖着进入

PRE_PROPOSAL: 体育场地标注参考方案

对于整块体育场街区的

对于所有与运动有关场地的

  • 游泳池leisure=swimming_pool
  • 游泳设施leisure=sports_centre + sport=swimming

具体运动的场地：leisure=pitch+sport=*，不知道运动种类的呢？

具体运动的场地的划线：Proposed_features/pitch_markings

还有考虑标线怎么处理的问题。

PRE_PROPOSAL: 仅限残障人士用的button

How to tag a crossing that have button but the button only designed for wheelchair using people, to let them have a longer time to pass the street?

https://www.openstreetmap.org/changeset/179459377

https://wiki.openstreetmap.org/wiki/JA:Key:button_operated

PORTAL: Wikidata alternative in OSM

Wikidata is a very great project, it let knowledge in different area linked as a network, by its item/property/lexeme. But I don't think WMF is neutral and political-no-concerned. Although in different counties Wikidata community and OSM community have close relationship and I'm already contributed a lot on it, I can't say it can be OSM's de-facto identifier is a good thing.

So I want to find a new identifier for OSM elements. It should be:

1. Open edit. Everyone can edit it if something not completed.(May need a account) 2. Must have static and permanent link so visitor can go for that node/entry/item directly.

Don't care about who operating and hosting it, can be a NGO, can be a encyclopedia, can be a search engine company, that don't matter. I just wander something can given us more possibility on identifier's choose.

Thank you!

PORTAL: 中华美食计划

全都给你添加到 Key:cuisine里去，弘扬中华美食。

你好谢谢小笼包再见

注意，它可能不仅在中国大陆有，TW，JP，KR等地可能都有。只是发源于大陆这边，所以我会盯着那些想fork到Taiwanese cuisine的人哦。（也会盯着那些想申遗的人的哦）

Tag:cuisine=malatang

麻辣烫正式脱离火锅，成为独特的一种cuisine，强调它和火锅的区别，避免申遗。并明确的把起源在中国给标注出来。

（哎，我们就不用那个冗长的Spicy Hot Pot，当初选择归到火锅就是受这个影响觉得别和政府对着干，上面定性为火锅我就跟着用。现在看来不明确用拼音写，就有人想搞文化小偷呢）

Proposed page content for Tag:cuisine=malatang, if you like you can create the page use those wikitext
{{ValueDescription
|key=cuisine
|value=hot_pot
|description= A place that mainly sells hot pots.
|image=
|onNode=yes
|onWay=no
|onArea=yes<!--includes multipolygons-->
|onRelation=no
|group = food and beverages
|combination=
* {{Tag|amenity|fast_food}}
|status=inuse

}}For place that mainly sells hot pots. 

Note that it is to be used in addition to a main tag, typically {{Tag|amenity|restaurant}}

== Spelling ==

As [[Tag:cuisine=hot_dog]], this should not be spelled as <s>"hotpot"</s>, you should use "'''hot_pot'''" in OSM editing.

== External links ==
{{wikipedia|en|Hot pot}}.
{{wikipedia|en|Malatang}}.

Tag:cuisine=lanzhou_lamian（兰州拉面，暂定这个英文）

兰州拉面是Ramen？堂堂华夏的拉面要和你猪骨头的日本拉面共用一个Ramen？气抖冷，咱兔子家的拉面啥时候才能站起来。也不要和四川的担担面混为一谈。

A place that mainly sells noodles. Examples include Japanese, Chinese, Korean noodles such Japanese udon, soba, and ramen; Chinese dandan noodles and tan men; Korean renmyon and bibin myon; and Vietnamese phở and bún. Common throughout East Asia and increasingly worldwide. Use more specific tags if available.
--Key:cuisine

我觉得这个非常不合适，如果日本的各种拉面都能划分这么细，我们中华家的面绝对不亚于这些，西北八大怪搬出来，那可是不止一点啊。裤带面啊拉条子啊……想想就流口水了吧（派蒙流口水.JPG)

如果可以，顺便把preset里面的ramen搞成Japanese Ramen，翻译成日本拉面而不是拉面，“不要蹭我们哥哥的热度哦~”，说不定那边看到加了Japanese还怪高兴的绝的输出了，其实是我们要正名！

后记：确实可以单独搞一个lamian的分类？因为核心差异就是中国面是拉出来的，而日本面是切出来的。以及中国的米粉mifen/mixian估计也应该独立出一个来。

但是这样也有问题，日本的udon/soba之类也是单独的tag，而兰州拉面在本地是叫牛肉面的，又会有本地人外地人的称呼争议（但日本大家叫soba叫udon又都是全国一致的）。要说担担面用dandan（tantan是日式的中华）那应该没啥争议。

Tag:cuisine=roujiamo/mantou（肉夹馍和馒头，暂定这个英文）

不是burger/bread，日常很常见的东西。https://www.openstreetmap.org/changeset/148863649 有讨论过。Chinese burger确定说的不是塔斯汀？Steam Bread确定不是G胖烤的面包？

Tag:cuisine=hot_pot

火锅正名计划，为中国火锅正名，让人看到hot_pot就知道这个是中国美食。并把所有不合标准的hotpot都扬喽。（全都给你扬咯）

Tag:cuisine=shaxian（沙县小吃，暂定这个英文）

这次必须正式独立出来，不至于变成NSI里的generic name，让它成为一个preset

Others / 其他

看起来过度用力的没必要的纯图一乐的提案，基本就是满天拼音化了，图一乐吧。

Useless
食品 标签
饭 黄焖鸡米饭 cuisine=braised_chicken_rice
盖浇饭 cuisine=gaifan
炒饭 cuisine=chinese_fried_rice
面 炒面 cuisine=chow_mein
烩面 cuisine=hui_mian
刀削面 cuisine=knife-cut_noodle
担担面 cuisine=dandan_noodle
𰻝𰻝面 cuisine=biangbiang_noodle
热干面 cuisine=reganmian
炸酱面 cuisine=zhajiangmian
米线 cuisine=mixian
米粉 cuisine=rice_noodle
螺蛳粉 cuisine=luosifen
沙河粉 cuisine=shahe_fen
粉丝 cuisine=cellophane_noodle
小吃 馄饨 cuisine=wonton
饺子 cuisine=jiaozi
包子 cuisine=baozi
小笼包 cuisine=xiaolongbao
糖水 cuisine=tong_sui
粥 cuisine=congee
烧饼 cuisine=shaobing
煎饼 cuisine=jianbing
臭豆腐 cuisine=stinky_tofu

待完善的草案

和 不成熟的想法不同，这里是记载了一些完成度较高的基本上预备准备提出的草案。

它们在未来有希望变成单独的页面链接。使用目前完善度最高的 DRAFT 分级。


DRAFT: 中国常见树木标注方案

提案内容

关于树龄问题、朝代问题、目前暂无发现有合适的标签。欢迎朋友们推荐给我，直接评论于此即可。

而不少古树被地方政府评级为 A类/甲类/一级 古树/历史名树 之类，目前不知道有什么好的方案来进行结构化的描述

乔木行道树

  • 柳树
  • 槐树：Styphnolobium japonicum
  • 梧桐树
  • 杨树

乔木花树果树

  • 樱花
  • 苹果树
  • 梨树
  • 杏树
  • 桃树

灌木

  • 冬青
  • 龙柏

类似项目

可以从OSMBC上找找有没有其他的树种库，应该是有一个常见树种列表的

渲染优化

此外，希望在自定义的渲染中，渲染树木的时候，可以体现出宽度，体现出不同树种在不同纬度带的颜色，但这样需要引入两个判断量即落叶常绿之类品种或者学名品种，以及纬度，可能会非常不精确，感觉要学习MC那样做渐变图取色了。

DRAFT: 道路区域标注方案

1. 用来查询目前城市中有多少道路区域？ 

[out:xml][timeout:255];

// 1. エリア設定

{{geocodeArea:東京都}}->.tokyoArea;
{{geocodeArea:北京市}}->.beijingArea;

// 2. クエリ本体
(
  wr[area=yes]
     [highway]                  // highway タグの存在を保証
     [highway!="rest_area"]     // highway の値が rest_area ではない
     [highway!="services"]     // highway の値が rest_area ではない
     [highway!=pedestrian]      // highway の値が pedestrian ではない
     [highway!=service]         // highway の値が service ではない
     (area.tokyoArea);
  wr[area=yes]
     [highway]                  // highway タグの存在を保証
     [highway!="rest_area"]     // highway の値が rest_area ではない
     [highway!="services"]     // highway の値が rest_area ではない
     [highway!=pedestrian]      // highway の値が pedestrian ではない
     [highway!=service]         // highway の値が service ではない
     (area.beijingArea);
);

// 3. 出力
// 全ての結果をまとめて取得し、出力する
(
  ._;
  >;
);
out body;

2. 目前常用的可以用来精细绘图的tag？

起码是我在用的

但是micromapping如果要去看精度，对于已经建成的区域和不容易变化的区域来说，有很多可以做的，比如：

  • 路口交叉区域可能也要结合road_marking=*（停止线或者横道线）或者highway=stop（停车标，如日本「止まれ」）之类来绘制标线，还要在路口和人行横道区域贴一点barrier=kerb（甚至还可以标出高差）
  • 人行道区域可能和我曾经提出的人行道宽度是冲突的tag？（毕竟都是希望用不同的方式来推动更精细的渲染。对于没有绘制为区域的人行道，用宽度去render和在编辑器里展示范围也是好的，而且如果有自动拖拽两边生成的工具就更好了）

对于人行道的宽度是否有标签？

因为比如东京上野或者涩谷之类前面的人行道都非常特殊。

有很宽的，有交叉的，这些要如何表示？

3. 那么在哪里可以学到呢？

  • 对于路口和交叉口，可以看德国，如 r19581983（某个不知名小镇）或者柏林新克尔恩的 w964589558 （德国人已经有时间到开始画区域了）
  • 对于人行横道线，可以看苏黎世，如 https://www.openstreetmap.org/edit#map=20/47.3769227/8.5437595 这附近
  • 对于交通岛，可以看品川阜头或者新宿三丁目（以及有老日把安全岛作为步行者天国处理了，不是很懂），以及各种fence也画上去的话工作量就更大了

DRAFT: 中国小区标注方案

因为觉得这部分争议可能比较大，直接放手册不太好，所以先在个人主页挂一下，有意见可以直接动手改或者批注，确定了再贴回Zh-hans:中国标注指南


居民区区域划分参考方案--多期建设问题

  • 1. 若是小区分期建设，且分期建设之间有明确的围墙或公路阻隔，应认为是两个不同的landuse。楼的编号完全依照on the ground原则。有条件时应用barrier=*将分割画出。
  • 2. 若是小区分期建设，但位于同一地块内，中间没有明显区分，只是“路这边老区，路那边新区”的区别：


2.1. 若编号连续则全部on the ground执行，应合在同一个landuse内
2.2. 若编号不连续依然应位于同一个landuse内，但是在编号前加注“老区”、“新区”

建筑名理论上由小区名+楼号构成（有如街边未命名建筑xx路xx号之称呼）。「老区」「新区」之称未曾见过，曾见的有#期、#组团、#村，不应将其视为编号组成。--Lepus (talk) 17:53, 1 May 2022 (UTC)

2.2 示例（纯属虚构）：“四季花城”小区分为“春园”、“夏园”、“秋园”、“冬园”四个区，小区各分区共用一个出入口，中间依靠主干道划分没有围墙分割，均各自有3栋楼，则应出现“春园#1”、“夏园#1”、“秋园#1”、“冬园#1”。landuse的name写作“四季花城”。

  • 3. 若是数个小区实质上是不同小区，但位于同一个大院中：


3.1. 若编号是连续的，应视作同一个小区，仅在前面加注宣传的小区名称，landuse采用同一个并复合填写名称

3.1 示例（纯属虚构）：“天空岛”的3座居民楼（#1-#3）和“世界树”的4座居民楼（#4-#7）混合在一个地块，编号连续，则landuse的name写作“天空岛/世界树”，编号分别为“天空岛#1”~“天空岛#3”及“世界树#4”~“世界树#7”

不建议在无整体代称的landuse上填多个名称。--Lepus (talk) 17:53, 1 May 2022 (UTC)


3.2. 若编号不连续（或不完全连续），应视作两个不同的区域，landuse分别加注各自名称。分界线按照分区的道路决定。小区公用的门应位于landuse交叠边界上。

  • 如有部分地区根据风俗习惯，编号跳过4（1、2、3、5、6...）或者以其他号码代替4的（1、2、3、3A、5、6...），应视为连续。

不同时期的户型风格分类

对于这一点似乎还应该同时参考日本的团地、mansion、apart之类的风格名字，台湾的大厦啊之类的名字

或者是三室一厅两室一厅一卫一卧之类俗称能不能规范化？类似隔壁1LDK，3LDK，1D之类的习惯称呼

以及如果是有三维或者室内的精细建模的话就可以给某个空间指定卧室或者厨房或者在上面提供标记了


外部链接

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=User:快乐的老鼠宝宝&oldid=3060283"