温德姆·刘易斯 (Wyndham Lewis)曾形容加拿大为“一个巨大的、空荡荡的栖息地”。 这位英国作家并不是唯一一个形容这个国家广阔、宏伟、且人口稀少的人。考虑到加拿大在地理上是世界上第二大的国家,很多人认为它大部分地区是空旷的,这也是可以理解的。 这种观念让社交媒体评论员,如Slazac,能够通过发布一张粗略的地图并评论“加拿大人真蠢,他们抱怨住房危机,但他们有这么多空地可以建城市”来吸引290万观众。 鉴于这种普遍存在的神话,加拿大的大城市异常拥挤的现象是违反直觉的。 例如,多伦多地区是北美人口密度第二高的城市区域。温哥华地区排名第四。 加拿大的居民和新移民都以一种奇怪而强烈的方式被其城市吸引,而这些城市明显受到边界的限制。 这有助于解释为什么房价高得惊人。 前卑诗省新民主党省长贺谨(John Horgan) 手下的省公务员领袖唐·赖特(Don Wright) 制作了一张图表,显示北美唯一比多伦多人口密度更高的城市区域是纽约。 通过测量每个城市中心30公里范围内的人口密度,赖特发现,纽约的人口密度最高,达到每平方公里 15,014 人。 多伦多地区排名第二,每平方公里有6,006人。接下来是旧金山地区,每平方公里有5,843人,温哥华则为5,568人。蒙特利尔排名第七,每平方公里有5,219人。 相比之下,温哥华南边的邻居西雅图则宽敞得多,每平方公里只有2,483人。 加拿大三大城市人口密度高的原因有几个。其一是加拿大拥有世界上最高的国际移民率之一,另一个原因是缺乏扩展空间。 尽管加拿大看似广阔,但只有4.3%的土地可以种植农产品,而美国为17%,德国为33%,印度为52%。 这导致政客们感到有压力要保护农田和其他绿地,尤其是在温哥华和多伦多周围。因此,这两个城市在地理上比其他北美城市受限得多。 “加拿大的土地很多,但大部分地方都没有人居住。”赖特说。 他表示,在1970年代,加拿大的市政政客通常通过扩展边界到附近的农田来应对人口快速增长。但赖特发现,根据市政边界,美国的人均城市土地占有量比加拿大高出 50%。 加拿大政客重新划分农田用于住房的时代大多已经过去。“我们知道,农业土地保护区在卑诗省是一个信仰的体现。”赖特说。而安大略省省长罗伯·福特去年试图重新划定多伦多周围绿地的一小部分用于新建住房时,也遭遇了巨大反对。 加拿大的城市没有像其他地方那样向郊区和农田扩展,而是以墨尔本大学可持续发展教授布兰丹·格里森(Brendan Gleeson)所说的“垂直扩张”而闻名。 根据摩天大楼中心的数据,加拿大拥有全球第三多的100米以上的建筑物,总数为472,仅次于人口众多的中国和美国。 虽然格里森不反对高密度发展,但他对低质量、外观丑陋且过于密集的高楼感到担忧。更何况,住宅楼往往会产生更多的碳排放。 这一现实情况与加拿大颇具影响力的商业游说团体世纪倡议的主张相吻合,该组织一直在敦促自由党政府到 2100 年将多伦多大都会区的人口从目前的 800 万增加到 3350 万,并将温哥华大都会区的人口从目前的 300 万增加到 1200万。 但温哥华市的人口密度自二战以来已经增加了三倍。除了为数百座住宅塔楼划分区域外,长期以来,它还允许每个“单户住宅”地块包含两到四个独立住宅。 近年来,温哥华市,像本拿比和其他郊区一样,也大幅增加了更多高楼的划分区域。去年,卑诗省新民主党通过了44号法案,取消了全省范围内的单户住宅划分,改为每个地块可建四到六个住宅。47号法案还要求在离轻轨站和公交枢纽10分钟步行范围内的区域,建造8至20层的建筑。 这种划分看起来是好意的,但悲剧在于,这并没有降低房价。根据包括本拿比和列治文市市长以及UBC大学建筑系教授帕特里克·康登(Patrick Condon)在内的多方观点。 康登说:“温哥华地区的密集化可能是北美最激进的,但它并没有带来我们期望的可负担住房。” 虽然康登教授表示,理论上密集化有可能在某天降低价格,但他的研究表明,即使开发商被允许违背多伦多和温哥华大多数居民的意愿,推平农田来建造住房,住房负担不起的问题可能依然存在。 该怎么办?许多住房分析师和银行经济学家现在表示,加拿大的永久和临时移民水平必须从目前每年130万人减少,直到住房供应赶上需求。 “我认为,我们恢复一定程度的宜居性的唯一机会是联邦政府必须减少移民数量,”赖特说。他建议将年度人口增长减少到30万人。国家银行经济学家Stéfane Marion和Alexandra Ducharme提出了30万到50万的目标。 这样的减少可能不会受到世纪倡议和一些企业的欢迎,但无疑会缓解住房需求。 |
Copyright © 1999 - 2024 by Sinoquebec Media Inc. All Rights Reserved 未经许可不得摘抄 | GMT-5, 2024-11-25 03:14 , Processed in 0.141984 second(s), 23 queries .