題:
馬德里的32 / 33R跑道實際上有彎道嗎?
FreeMan
2017-01-18 20:51:46 UTC
view on stackexchange narkive permalink

在馬德里機場的這張衛星圖像中( MAD / LEMD)...

Screen cap from Google maps
來源: Google地圖衛星視圖 sup>
maps.google.nl的備用鏈接對我來說仍然呈現錯誤,但對其他人來說卻很好... sup>

...看來32 / 33R跑道的著陸區有一個非常明顯的左彎。

根據我從傑普森機場得到的解釋數據,似乎沒有任何跡象表明存在這種糾結:

Jeppesen airport diagram
由uvairlines.com託管的Jeppesen 第50頁。 sup>

真的在那兒,還是Google處理不同圖像的人工產物?顯然正在發生某些情況,因為您可以在圖像中看到兩個RWY32 & RWY33標記,而Jeppesen清楚地將其標識為33。降落?我認為觸地得分的目標是圖像左上角的兩個長實線,不包括扭結,但是,有足夠的橡膠指示觸地得分比閾值更接近閾值。

有趣的是,我只是關注了您的鏈接,並且我也看到了與DeltaLima答案中的清晰32不同的紐結。
很高興知道,我並沒有完全瘋掉和/或被Google選出來進行心理控制實驗,@Notts90! :)
更新:在我的手機(iPhone 5s)和使用IE的PC上,如果我放大足夠,它將重新加載圖像,並且我看到DeltaLima得到的筆直圖像,如果我縮小了,則得到了扭曲的圖像。在裝有鉻的PC上,我只能得到扭結的圖像。因此,Google似乎會顯示多個緩存的圖片,具體取決於您的瀏覽器和縮放級別,具體取決於您看到的內容。
也許是因為跑道數量增加了兩倍。跑道的第一部分是33R,而後扭結是32. :)
到目前為止,@reirab是我所聽到的最合理的解釋! :D
我的猜測是,您有兩個圖像集的圖像,其中至少一個沒有正確地進行地理參考。.新圖像集的版權為2017。 “ 33”是舊集合的一部分,是頂部圖像,底部圖像(“ 32”)來自新集合。所使用的設定可能隨變焦等級而變化。
@mins我了解Google Maps / Google Earth的版權日期始終是當年。我認為只有Google Earth可以顯示攝影的實際日期。
從Google Maps和MapQuest來看,我認為32R接近尾端沒有任何紐結。
看起來像兩個相鄰衛星圖像之間的重疊(拼接)。在城市中,這種情況更為明顯,因為與鄰居相比,房屋以另一種方式“傾斜”。
那麼...為什麼要投票?到目前為止有3個?
是的,這條跑道有一個彎頭-因為它的難度中等。如果從西南向北滾動7差距,您會看到超硬難度跑道,其中有一個迴路—迴路。
我投票結束這個題為離題的問題,因為它與航圖繪製和[正射校正]有關。最好在[gis.se](http://gis.stackexchange.com/)上回答。
七 答案:
Jamiec
2017-01-18 22:17:05 UTC
view on stackexchange narkive permalink

您的問題的一個有趣特徵是圖像中的跑道號明顯雙重曝光。而且我懷疑它也會解釋/解釋為什麼您在圖像中看到一個紐結。

有時,跑道會更改編號。這樣做的原因基本上是,跑道只有36個可能的標記(1-36),但是指定為18的跑道可以定向在175-184度之間的任何位置。通常,跑道的實際方向會四捨五入到最接近的10。因此,指向184度的跑道將指定為“跑道18”。

多年以來,磁變化在漂移(例如,十年前,英國南部為+3度,現在為+1)。這可能使一條跑道曾經具有184度的磁性,現在變為186度的磁性,因此需要將其名稱從“ 18號跑道”更改為“ 19號跑道”。

現在,關於您的圖像,我想Google在32號跑道時大獲全勝,並在重新指定(並重新粉刷!)33號跑道後又(至少是部分地)再次搶占了機場。維基百科的文章

2012年9月20日,兩條15/33跑道均被重命名為14R / 32L(最長)和14L / 32R(最短)。

將圖像縫合在一起的動作以及使用中的圖像處理算法,意味著您會得到一種圖像的一部分和另一種圖像的一部分。它幾乎可以肯定在現實生活中不存在,因此對飛行員在該跑道周圍的操縱沒有影響。

實際上,@DeltaLima確實在回答中提到了跑道重新編號,儘管他沒有提供參考。
@FreeMan我覺得他對此發表了非常積極的評論,並沒有真正解決那顯然是您失真圖像的根源。我想您可能想知道跑道為何會更改數字的一些背景知識。因此答案。
足夠合理的解釋。
@FreeMan另外,您還有3個答案:“在計算機上工作”,“在計算機上工作”和“僅圖像”。我什麼都不會稱呼“對這個問題的好答案”,而且不會對其他回答者表示不敬。
這種扭結在Google衛星照片中非常頻繁地出現。
@MichaelHampton是的,他們願意。我懷疑這是因為Google的算法使用磁北來定向圖像,並且隨時間變化。
這個答案似乎歸結為“我猜這是一件假象”,而沒有給出該觀點的理由。問題不是關於標記,而是關於扭結。 OP使用標記作為解釋扭結的一種方式,但是這個答案並沒有增加。
我之所以投票,是因為我認為它猜的太多了:1)“ Google很明顯使用磁北來定向他們的圖像”,2)這種特殊的扭結是由圖像方向引起的。
不要以個人身份對待,@Jamiec,有人否決了我的原始問題。 (沒有評論,我可能會添加...)
@FreeMan哦,我一點都不接受。人人有權徵求意見。
扭結可能是這兩個圖像在此處疊加的結果,可能是從不同角度拍攝的,並且由於地球是圓形的而不是平坦的,因此無法完美對齊。通常,由於長直線物體在地圖上並不常見,因此這並不明顯。
DeltaLima
2017-01-18 21:07:52 UTC
view on stackexchange narkive permalink

您彎曲屏幕了嗎?

我的Google地圖表現更好:

enter image description here

還請注意,將15/33跑道重編號為14由於磁航向的變化,/ 32在2012年左右的某個地方。

有趣。我只是意識到,我發現的Jeppesen板上的日期是2008年,並將其標記為33。有趣的是,即使是Ctrl-F5(強制Firefox刷新圖像而不是將其從緩存中拉出)仍然顯示出彎曲。不過,當我稍微縮小一點時,從325°到321°的彎角比較小,但是繞第二個6欄左側的白色圓圈繞過的彎頭更多。非常有趣,您可能會得到一張張貼Google地圖圖像和ROIMason的Bing圖像的支票-我會花點時間看一下還有多少其他地圖圖像出現。 :)
根據Notts90在我的OP上的評論,您正在使用美國版本的Google地圖,還是在其他國家/地區使用本地化版本?即,您可以提供圖片的源鏈接嗎?我想知道不同服務器上是否有不同的映像...
我在荷蘭(.nl)使用荷蘭語(.nl)[Google地圖](https://www.google.nl/maps/@40.4743267,-3.5381307,385m/data=!3m1!1e3)。
有趣的是,它仍然對我來說渲染不正確!它的外觀與我的maps.google.com鏈接完全相同。哦,好吧,我將這歸納為“其中一件事情” ...
@DeltaLima甚至更好,我可以在一個瀏覽器(使用Maps lite)中看到凹痕,而在另一個瀏覽器中卻看不到。因此,它不僅是圖像處理偽像,而且是[緩存中的一個](http://shouldiblamecaching.com/)
許多Google Maps處理都是在服務器端進行的。因此,一個瀏覽器的Javascript引擎可能與另一個瀏覽器的徽章不同。
ROIMaison
2017-01-18 20:59:09 UTC
view on stackexchange narkive permalink

此Bing地圖上的圖像顯示了相同的區域,但沒有扭結,所以我認為這是圖像處理工件。

通過此鏈接在Bing地圖上查找 >

enter image description here

來源:必應地圖

tar
2017-01-19 02:29:10 UTC
view on stackexchange narkive permalink

問題是跑道是否筆直,所以讓我們從方便的東西開始,這是已知的筆直東西。

請注意,跑道上的磨損痕跡(較深的中心線)也會切成一條在跑道旁邊-而第一運動定律表明這不太可能。這就是為什麼我會賭很多錢,因為它是人工製品,而不是現實。

[lolz]當然,那裡可能經常發生側風,這總是會導致飛機在跑道本身彎曲的確切位置側向移動...但是為什麼要停在那裡?也許施工人員也受到了這種風的影響,這就是為什麼他們首先將其彎曲的原因![/ lolz]

runway image showing sideways slice in wear marks

“也許施工人員同樣受到了那風的影響……”。 a西班牙果酒。
也許那風吹走了跑道的那部分。 :-)
RomaH
2017-01-20 01:42:37 UTC
view on stackexchange narkive permalink

這很可能是航空正射攝影中的錯誤校正的偽像。

進行空中攝影或LiDAR的飛機在拍攝風景時會飛出“橫行”圖案,從而產生長條圖像。

Nadir courtesy of ESRI
ESRI圖像

然後處理原始圖像並縫合在一起以創建合成圖像並進行矯正。該過程在很大程度上是自動化的,該算法使用相似的點作為參考點將圖像縫合在一起。 此處類似的過程,是手動完成的。有時,由於各種原因,邊緣不能完全對齊:飛行矢量校正,不同的鏡頭,鏡頭變形等。然後將圖像拼接在一起時,計算機會拉伸或擠壓圖像以適合兩個已知的良好參考點之間的邊緣。

它將對圖像進行插值,這意味著有時參考點之間的邊緣不對齊,從而在跑道上產生怪異的扭結。這些錯誤很常見,並且經常在容易識別斷點的線性物體上發現。


重新閱讀關於跑道標識的 Jamiec答案:這是縫合的舊照片就像答案所暗示的那樣使用老照片;技術是一樣的,工件看起來也很相似!

Irl Concord
2017-01-20 02:41:22 UTC
view on stackexchange narkive permalink

FWIW,32/33的另一端標記為14L。這意味著(我相信)它是一對跑道(在您進入時)為140°時的左側。因此32/33末端應標記為140 + 180 = 320°,即32,並且由於它現在在右側,因此應為32R。我測量了實際的航向,將屏幕上的水平方向設為真實的東西向(不一定如此,這取決於Google的地理投影的細節),並且獲得了323°(也與32一致)。最終,扭結髮生在人們經常看到的背景顏色發生明顯變化的地方,大概是在將兩個不同的圖像合併在一起的地方。重複的數字在重疊區域中。 33是假的(但我根本看不到它來自哪裡)。

其他答案解釋了為什麼有跑道圖像標記為33。
pericynthion
2017-01-18 20:55:54 UTC
view on stackexchange narkive permalink

不,這只是圖像配準工件。

可以通過提供顯示跑道平直的圖像或像其他答案一樣提供有關此假象可能在此處的原因的更多信息來改善此答案。


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...