原文の意味がいまいちわからない。。。

[miya0001]

The layer format is designed so that the data required for a layer is contiguous in memory, and so that layers can be appended to a Vector Tile without modifying existing data.

メモリ内で連続してることって具体的にはどういうイメージなんですかね？

[hfu]

翻訳としては、私だったら次のようにします。

レイヤのフォーマットは、ひとつのレイヤに必要なデータが記憶領域内で接するように設計されている。このようにすることによって、既存のデータを変更することなく、レイヤがベクトルタイルに追加できる。

memory は、本来 data なり a file としたほうが正しいのかもしれません。

レイヤを再現するのに必要な情報が、ファイル内で一つの塊（chunk?)になっていることを意味すると思います。

気がきいていないフォーマットだと、ファイルの中にヘッダ領域のようなものがあって、一つのレイヤに関係するデータがファイル内で飛び石上に配置される場合があります。この場合、例えば12レイヤあるところに1レイヤ加えて13レイヤにしようとすると、ヘッダを再構成し、ボディを再構成し、それを接合するといったややこしいことをしなければなりません。

しかし、「ひとつのレイヤに必要なデータが記憶領域内で接するように設計」することで、12レイヤに1レイヤを加えて13レイヤにするときには、単にタイルを cat すればよいだけになります。

これは、ベクトルタイルの「レイヤコンポジション」を可能にする性質です。

ちなみに、国土地理院が2000年代前半に提供していた電子国土Webシステムのベクトルタイル形式でも、この性質を満たすように設計しており、よってベクトルワイズに cat することで、データのマージができるようになっていました。

[miya0001]

a fileだとすっきりきますね。そもそもなんですがこの仕様書の「ベクトルタイル仕様書」というのは単純なファイルフォーマットだけを想定しているのではなくたとえばREST APIからのレスポンスとかSQLからの結果とかそういうことも想定して Memory という表現なんですかね。
拡張子が .mvt であることとのことなので、ファイルフォーマットに関する仕様だと理解しているのですが、そのあたり頭が混乱してきました。笑

[hfu]

おっしゃる通り、MVT (vector-tile-spec) はファイルシステム上のファイルの仕様というにとどまらず、サーバサイドで生成されるレスポンスの符号化仕様でもありますね。

ファイルの仕様というよりは、本来、ウェブで言う「リソース」の仕様なのだと思います。その点で、file という言葉を避けたい気持ちが原作者にあった可能性があると思います。

先のコメントで「レイヤコンポジション」と申し上げた処理も、複数のレイヤを一つのリクエスト・レスポンスに束ねるための表現で、複数のレイヤを束ねる処理は、オンデマンドにサーバ行い、適宜キャッシュをかませる実装が現実的な気がします。

ただし、初歩的な理解は、ファイルシステムで実現された static なリソース、すなわちファイルのための仕様、といいう理解で十分に良いと感じます。

レイヤコンポジションの例として、Mapzen さんの Vector Tile Service の説明から関係部分を貼り付けます。URL は https://mapzen.com/projects/vector-tiles/ です。