2019年11月27日水曜日

v6.0.0 がリリースされました

v6.0.1 がリリースされました
日本時間で(2019.10.2)に v6.0.1 がリリースされました。

Releases 6.0.1 - openlayers/openlayers GitHub
(https://github.com/openlayers/openlayers/releases/tag/v6.0.1)より

6.0.1

Hot on the heels of the 6.0 release, this patch release includes a few fixes for existing functionality. There should be nothing special needed to upgrade an application from 6.0.0 to 6.0.1. See the 6.0.0 release notes for details on upgrading from an older version.

6.0 リリースのすぐ後に、このパッチリリースは現在の機能のいくつかの修正を含んでいます。6.0.0 から 6.0.1 へアプリケーションを更新するために必要とされるものは特にありません。以前のバージョンからの更新についての詳細は、6.0.0 リリースノートを参照してください。


v6.0.0 がリリースされました
日本時間で(2019.9.27)に v6.0.0 がリリースされました。

Releases 6.0.0 - openlayers/openlayers GitHub
(https://github.com/openlayers/openlayers/releases/tag/v6.0.0)より

6.0.0

Wow. The 6.0 release includes changes from 1780 commits in 544 pull requests since the 5.3 release. Thanks to all who contributed to this effort.

ワォ。6.0 リリースは、5.3 リリース以来の 544 のプルリクエストの 1780 コミットからの変更を含んでいます。この尽力に貢献された全てに感謝します。

A major feature in this release is the ability to compose layers with different renderer types. Previously, the map used a single rendering strategy, and all layers in your map had to implement that strategy. Now it is possible to have a map with layers that use different rendering technologies. This makes it possible, for example, to have Canvas (2D) layer composed together with a WebGL based layer in the same map. It is also possible to create layers with custom renderers. So you could have a map that uses another library (like d3) to render one layer and use OpenLayers to render the other layers. We will continue to take advantage of this new flexibility in future releases.

このリリースの主な機能は異なるレンダラタイプでレイヤを構成する性能です。以前は、マップはシングルレンダリングストラテジを使用し、マップのすべてのレイヤはそのストラテジを実行しなければなりませんでした。現在、異なるレンダリング技術を使用するレイヤのマップを持つことが可能です。これは、例えば、同じマップに WebGL ベースのレイヤと一緒に構成された Canvas (2D) レイヤを持つことを可能にします。同じように、カスタムレンダラとともにレイヤを作成することが可能です。一つのレイヤを描画するためにもう一つのライブラリ(d3)を使い、他のレイヤを描画するために OpenLayers を使うマップを持つことができるでしょう。今後のリリースでこの新しい柔軟性を利用し続けます。

In addition, the 6.0 release includes a number of vector tile rendering improvements and should have a lower memory footprint overall. The release also includes a number of experimental features that are not yet part of the stable API. Take a look through the examples for a new WebGL based renderer and the experimental useGeographic() function. Watch upcoming releases for more detail on these.

加えて、6.0 release は数多くのベクタタイルレンダリングの改善を含み、全体的に少ないメモリの負荷を持つはずです。このリリースは、未だに安定していない API の一部である多くの実験的な機能も含んでいます。新しい
WebGL ベースのレンダラと実験的な  useGeographic() 関数の例を通して見てください。これらについて更に詳しいことは今後のリリースに注目してください。

This release includes a number of backwards incompatible changes. Take a careful look at the notes below when upgrading your application from the 5.3 release.

このリリースは過去に逆上った互換性のない変更を多く含んでいます。アプリケーションを 5.3 リリースからアップグレードするときは、下記の注釈に注視してください。


■Backwards incompatible changes
過去に逆上った互換性のない変更

□Usage of map.forEachLayerAtPixel
map.forEachLayerAtPixel の使い方

Due to performance considerations, the layers in a map will sometimes be rendered into one
single canvas instead of separate elements.
This means map.forEachLayerAtPixel will bring up false positives.

パフォーマンスの検討によって、マップ中のレイヤは別々のエレメントに換えて単一のキャンバスに時々描画されます。これは map.forEachLayerAtPixel が false を有効にすることを意味します。

The easiest solution to avoid that is to assign different className properties to each layer like so:

それを避ける最も簡単な解決策は、それぞれのレイヤに異なる className プロパティをこのように割り当てることです。
new Layer({
   // ...
   className: 'my-layer'
})
Please note that this may incur a significant performance loss when dealing with many layers and/or
targetting mobile devices.

これは、多くのレイヤと対象のモバイルデバイスまたはそのどちらかを処理するときに、重要なパフォーマンス低減を生じることに注意してください。


□Removal of TOUCH constant from ol/has
ol/has からの TOUCH コンスタントの削除

If you were previously using this constant, you can check if 'ontouchstart' is defined in window instead.

以前、このコンスタントを使っていたなら、代わりに window に 'ontouchstart' が定義されているか確認します。
if ('ontouchstart' in window) {
  // ...
}

□Removal of GEOLOCATION constant from ol/has
ol/has からの GEOLOCATION コンスタントの削除

If you were previously using this constant, you can check if 'geolocation' is defined in navigator instead.
以前、このコンスタントを使っていたなら、代わりに navigator に 'geolocation' が定義されているか確認します。
if ('geolocation' in navigator) {
  // ...
}

□Removal of CSS print rules
CSS プリントルール の削除

The CSS media print rules were removed from the ol.css file. To get the previous behavior, use the following CSS:
CSS メディアプリントルールは ol.css ファイルから削除されました。以前の動作を得るには、次の CSS を使ってください:
@media print {
  .ol-control {
    display: none;
  }
}

□Removal of optional this arguments
オプショナル this 引数を削除

The optional this (i.e. opt_this) arguments were removed from the following methods.
Please use closures, the es6 arrow function or the bind method to achieve this effect (Bind is explained here:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind).

オプショナル this 引数(例えば opt_this)が次のメソッドから削除されました。クロージャやアロー関数、この効果を達成するための bind メソッドで使ってください。(Bind はここに説明があります:https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind)

● forEachCorner in ol/extent
● LRUCache#forEach
● RBush#forEach and RBush#forEachInExtent


□The setCenter, setZoom, setResolution and setRotation methods on ol/View do not bypass constraints anymore
ol/View の setCenter、setZoom、setResolution、setRotation メソッドは、もはや、制約をバイパスしません

Previously, these methods allowed setting values that were inconsistent with the given view constraints.
This is no longer the case and all changes to the view state now follow the same logic:
target values are provided and constraints are applied on these to determine the actual values to be used.

以前、これらのメソッドは、与えられた view の制約(訳注:ol6 API ol/View 「The constraints」参照)と一致しない値を設定することを許可しました。
これは事実ではなく、全ては、現在、同じ論理に従う view の状態(訳注:ol6 API ol/View 「The view states」参照)に変更します:
ターゲット値が提供され、制約は、これらについて、使用される実際の値を決定するために適用されます。


□Removal of the constrainResolution option on View.fit, PinchZoom, MouseWheelZoom and ol/interaction.js
View.fit、PinchZoom、MouseWheelZoom、ol/interaction.js の constrainResolution オプションの削除

The constrainResolution option is now only supported by the View class. A View.setConstrainResolution method was added as well.

constrainResolution オプションは、現在、View クラスによってのみサポートされます。その上、View.setConstrainResolution メソッドが追加されました。

Generally, the responsibility of applying center/rotation/resolutions constraints was moved from interactions and controls to the View class.

一般的に、center/rotation/resolutions 制約を提供する責務は、インタラクションとコントロールから View クラスに移行されました。


□The view extent option now applies to the whole viewport
view extent オプションは、現在、すべての viewport に適用します

Previously, this options only constrained the view center. This behaviour can still be obtained by specifying constrainCenterOnly in the view options.

以前、このオプションは view center だけ制約していました。この動作は view オプションの constrainCenterOnly を指定することによって、まだ、得られます。

As a side effect, the view rotate method is gone and has been replaced with adjustRotation which takes a delta as input.

副影響として、view rotate メソッドはなくなり、入力されるデータとしてデルタを受け取る adjustRotation に置き換えられました。


□The view is constrained so only one world is visible
view は一つだけ世界(地図)が表示するように制約されます。

Previously, maps showed multiple worlds at low zoom levels. In addition, it used to be possible to pan off the north or south edge of the world. Now, the view is restricted to show only one world, and you cannot pan off the edge. To get the previous behavior, configure the ol/View with multiWorld: true.

以前、マップは低いズームレベルで複数の世界が(並んで)表示されました。加えて、北または南の縁を離れてパンすることができました。現在、view は一つだけ世界地図を表示するように制限され、縁を離れてパンできません。以前の動作を得るために、ol/View を multiWorld: true に設定します。


□Removal of deprecated methods
非推奨メソッドの削除

The inherits function that was used to inherit the prototype methods from one constructor into another has been removed.
The standard ECMAScript classes should be used instead.

あるコンストラクタからもう一つのものへ prototype メソッドを継承するために使用される inherits 関数は、削除されました。
代わりに、標準 ECMAScript クラスを使用します。

The deprecated getSnapToPixel and setSnapToPixel functions from the ImageStyle class have been removed.

ImageStyle クラスから非推奨 getSnapToPixel と setSnapToPixel が削除されました。


□New internal tile coordinates
新しい内部タイル座標

Previously, the internal tile coordinates used in the library had an unusual row order – the origin of the tile coordinate system was at the top left as expected, but the rows increased upwards. This meant that all tile coordinates within a tile grid's extent had negative y values.

以前、ライブラリで使用されていた内部タイル座標は、一般的でない行順でした - タイル座標システムの原点は予想通り左上にありましたが、行は上方向に増加しました。これは、タイルグリッドの範囲のすべてのタイル座標がマイナスのy値を取ることを意味します。

Now, the internal tile coordinates used in the library have the same row order as standard (e.g. XYZ) tile coordinates. The origin is at the top left (as before), and rows or y values increase downward. So the top left tile of a tile grid is now 0, 0, whereas it was 0, -1 before.

現在、ライブラリで使用されている内部タイル座標は、標準(例えば、XYZ)タイル座標と同じ行順を持っています。原点は(以前と同様に)左上で、行、または、y値は下に向かって増加します。以前は、0, 1 だったタイルグリッドの左上は、現在、0, 0 です。

x, y values for tile coordinates
タイル座標の x, y 値
origin
  *__________________________
  |        |        |        |
  |  0, 0  |  1, 0  |  2, 0  |
  |________|________|________|
  |        |        |        |
  |  0, 1  |  1, 1  |  2, 1  |
  |________|________|________|
  |        |        |        |
  |  0, 2  |  1, 2  |  2, 2  |
  |________|________|________|
This change should only affect you if you were using a custom tileLoadFunction or tileUrlFunction. For example, if you used to have a tileUrlFunction that looked like this:

この変更は、カスタムの tileLoadFunction または tileUrlFunction を使う場合にだけ影響を与えます。例えば、このように tileUrlFunction を用いていたなら:
// before
function tileUrlFunction(tileCoord) {
  const z = tileCoord[0];
  const x = tileCoord[1];
  const y = -tileCoord[2] - 1;
  // do something with z, x, y
}
You would now do something like this:
現在、この様なものにします
// after
function tileUrlFunction(tileCoord) {
  const z = tileCoord[0];
  const x = tileCoord[1];
  const y = tileCoord[2];
  // do something with z, x, y
}
In addition (this should be exceedingly rare), if you previously created a ol/tilegrid/WMTS by hand and you were providing an array of sizes, you no longer have to provide a negative height if your tile origin is the top-left corner (the common case). On the other hand, if you are providing a custom array of sizes and your origin is the bottom of the grid (this is uncommon), your height values must now be negative.

加えて(これはきわめてまれですが)、以前、独自に ol/tilegrid/WMTS を作成して配列サイズを提供していた場合、タイルの原点が(一般の場合の)左上ならマイナスの高さを提供する必要はありません。一方で、カスタムの配列サイズを提供していて原点がグリッドの底(これは一般的でない)の場合、現在、高さの値はマイナスでなければなりません。


□Removal of the "vector" render mode for vector tile layers
ベクタタイルレイヤの "vector" レンダモードの削除

If you were previously using VectorTile layers with renderMode: 'vector', you have to remove this configuration option. That mode was removed. 'hybrid' (default) and 'image' are still available.

以前、VectorTile レイヤを renderMode: 'vector' で使っていた場合、この設定オプションを削除しなければなりません。そのモードは削除されました。'hybrid'(初期値)と 'image' はまだ有効です。


□Removal of the "renderMode" option for vector layers
ベクタレイヤの "renderMode" オプションの削除

If you were previously using Vector layers with renderMode: 'image', you have to remove this configuration option. Instead, use the new ol/layer/VectorImage layer with your ol/source/Vector.

以前、Vector レイヤを renderMode: 'image' で使っていた場合、この設定オプションを削除しなければなりません。代わりに、 ol/source/Vectorと一緒に new ol/layer/VectorImage レイヤを使います。


□New declutter behavior
新しい declutter 動作

If a map has more than one layer with declutter set to true, decluttering now considers all Vector and VectorTile layers, instead of decluttering each layer separately. Only VectorImage layers continue to be decluttered separately. The higher the z-index of a layer, the higher the priority of its decluttered items.

マップに declutter 設定が true のレイヤが一つ以上ある場合、デクラッタ(整頓)は、以前、それぞれのレイヤを個別にデクラッタする換わりに、現在、すべての Vector と VectorTile レイヤを考慮しています。VectorImage レイヤだけが個別にデクラッタされています。レイヤの z-index が高くなると、そのデクラッタ項目のプライオリティが高くなります。

Within a layer, the declutter order has changed. Previously, styles with a lower zIndex were prioritized over those with a higher zIndex. Now the opposite order is used.

レイヤで、デクラッタ順は変わります。以前、低い zIndex の style は高い zIndex を持つものを超えるプライオリティがありました。現在、反対の順序が使用されます。

On vector layers, even if decluttered images or texts have a lower z-Index than polygons or lines, they will now be rendered on top of the polygons or lines. For vector tile layers, this was the case already in previous releases.

ベクタレイヤについて、デクラッタされたイメージとテキストがポリゴン、または、ラインより低い z-Index を持つ場合、現在、ポリゴン、または、ラインの上に描画されます。ベクタタイルレイヤでは、これは以前のリリースですでにこうなっています。


□New prerender and postrender layer events replace old precompose, render and postcompose events
新しい prerender および postrender レイヤイベントは古い precompose および render、postcompose と置き換えます

If you were previously registering for precompose and postcompose events, you should now register for prerender and postrender events on layers. Instead of the previous render event, you should now listen for postrender. Layers are no longer composed to a single Canvas element. Instead, they are added to the map viewport as individual elements.

以前、precompose および postcompose イベントを登録した場合、現在、レイヤの prerender および postrender イベントを登録すべきです。以前の render イベントの換わりに、現在、postrender をリッスンすべきです。レイヤは単一の Canvas エレメントにもう構成されません。代わりに、それらは個別のエレメントとして map の viewport に追加します。


□New getVectorContext function provides access to the immediate vector rendering API
getVectorContext 関数は直近の ベクタレンダリング API の利用を提供します

Previously, render events included a vectorContext property that allowed you to render features or geometries directly to the map. This is still possible, but you now have to explicitly create a vector context with the getVectorContext function. This change makes the immediate rendering API an explicit dependency if your application uses it. If you don't use this API, your application bundle will not include the vector rendering modules (as it did before).

以前、render イベントは、直接マップにフィーチャ(事物)、または、ジオメトリ(幾何学的形状)を描画することを許可する vectorContext プロパティを含んでいます。これはまだ可能ですが、現在、getVectorContext 関数を使用してベクタコンテキストを明示的に作成しなければなりません。この変更は、アプリケーションが使用している場合、直近のレンダリング API を明示的な依存関係にします。この API を使わない場合、アプリケーションのバンドルは(以前と同じように)ベクタレンダリングモジュールを含みません。

Here is an abbreviated example of how to use the getVectorContext function:
これは getVectorContext 関数の使い方の簡易な例です:
import {getVectorContext} from 'ol/render';

// construct your map and layers as usual

layer.on('postrender', function(event) {
  const vectorContext = getVectorContext(event);
  // use any of the drawing methods on the vector context
});

□Layers can only be added to a single map
レイヤは1つのマップにだけ追加されます

Previously, it was possible to render a single layer in two maps. Now, each layer can only belong to a single map (in the same way that a single DOM element can only have one parent).

以前、2つのマップに1つのレイヤを描画することが可能でした。現在、各レイヤは(1つの DOM エレメントが1つの親だけ持てるのと同じ方法で)1つのマップにだけ所属することができます。


□The OverviewMap requires a list of layers.
OverviewMap はレイヤのリストが必要です

Due to the constraint above (layers can only be added to a single map), the overview map needs to be constructed with a list of layers.

上記(レイヤは1つのマップにだけ追加される)の制約に従って、オーバビューマップはレイヤのリストとともに構築される必要があります。


□The ol/Graticule has been replaced by ol/layer/Graticule
ol/Graticule は ol/layer/Graticule によって置き換えられました

Previously, a graticule was not a layer. Now it is. See the graticule example for details on how to add a graticule layer to your map.

以前、経緯度線網(graticule)はレイヤではありませんでした。現在、そうです。マップに経緯度線網レイヤを追加する方法の詳細は graticule example を参照してください。


□ol/format/Feature API change
ol/format/Feature API の変更

The getLastExtent() method, which was required for custom tileLoadFunctions in ol/source/Vector, has been removed because it is no longer needed (see below).

getLastExtent() メソッドは、ol/source/Vector のカスタムの tileLoadFunctions に必要とされましたが、もはや必要とされないので削除されました(下記参照)。


□ol/VectorTile API changes
ol/VectorTile API の変更

● Removal of the getProjection() and setProjection() methods. These were used in custom tileLoadFunctions on ol/source/VectorTile, which work differently now (see below).

getProjection() と setProjection() メソッドの削除。これらは ol/source/VectorTile のカスタムの tileLoadFunctions に使用され、現在動作は困難です(下記参照)。

● Removal of the getExtent() and setExtent() methods. These were used in custom tileLoadFunctions on ol/source/VectorTile, which work differently now (see below).

getExtent() と setExtent() メソッドの削除。これらは  ol/source/VectorTile のカスタムの tileLoadFunctions に使用され、現在動作は困難です(下記参照)。


□Custom tileLoadFunction on a VectorTile source needs changes
VectorTile ソースのカスタムの tileLoadFunctions は変更が必要

Previously, applications needed to call setProjection() and setExtent() on the tile in a custom tileLoadFunction on ol/source/VectorTile. The format's getLastExtent() method was used to get the extent. All this is no longer needed. Instead, the extent (first argument to the loader function) and projection (third argument to the loader function) are simply passed as extent and featureProjection options to the format's readFeatures() method.

以前、アプリケーションは ol/source/VectorTile のカスタムの  tileLoadFunctions でレイヤの setProjection() と setExtent() を呼び出す必要がありました。getLastExtent() メソッドのフォーマットは範囲(extent)を取得するために使用されました。これは全て必要なくなります。代わりに、範囲(loader 関数の第1引数)と投影法(projection)(loader 関数の第3引数)は、extent と featureProjection オプションとして readFeatures() メソッドへ渡されます。

Example for an old tileLoadFunction:
古い tileLoadFunction の例:
function(tile, url) {
 tile.setLoader(function() {
  fetch(url).then(function(response) {
   response.arrayBuffer().then(function(data) {
    var format = tile.getFormat();
    tile.setProjection(format.readProjection(data));
    tile.setFeatures(format.readFeatures(data, {
     // featureProjection is not required for ol/format/MVT
     // featureProjection は ol/format/MVT を必要としません
     featureProjection: map.getView().getProjection()
     }));
     tile.setExtent(format.getLastExtent());
    })
   })
  }
});
This function needs to be changed to:
この関数は次のように変更されることが必要です:/div>
function(tile, url) {
 tile.setLoader(function(extent, resolution, projection) {
  fetch(url).then(function(response) {
   response.arrayBuffer().then(function(data) {
    var format = tile.getFormat();
    tile.setFeatures(format.readFeatures(data, {
     // extent is only required for ol/format/MVT
     // extent は ol/format/MVT だけ必要です
     extent: extent,
     featureProjection: projection
      }));
    })
  })
 }
});

□Drop of support for the experimental WebGL renderer
実験的 WebGL レンダラのサポートを削除します

The WebGL map and layers renderers are gone, replaced by a WebGLHelper function that provides a lightweight,
low-level access to the WebGL API. This is implemented in a new WebGLPointsLayer which does simple rendering of large number of points with custom shaders.

WebGL マップとレイヤレンダラはなくなり、WebGL API への軽量、低レベルアクセスを提供する WebGLHelper 関数によって置き換えられます。これは、カスタム shaders を使用して多数の点(point)を簡単に描画する new WebGLPointsLayer が実行されます。

This is now used in the Heatmap layer.

これは、現在、Heatmap レイヤに使用されます。

The removed classes and components are:
削除されるクラスとコンポーネントは:

● WebGLMap and WebGLMapRenderer
● WebGLLayerRenderer
● WebGLImageLayer and WebGLImageLayerRenderer
● WebGLTileLayer and WebGLTileLayerRenderer
● WebGLVectorLayer and WebGLVectorLayerRenderer
● WebGLReplay and derived classes, along with associated shaders
● WebGLReplayGroup
● WebGLImmediateRenderer
● WebGLMap
● The shader build process using mustache and the Makefile at the root


□Removal of the AtlasManager
AtlasManager の削除

Following the removal of the experimental WebGL renderer, the AtlasManager has been removed as well. The atlas was only used by this renderer.
The non API getChecksum functions of the style is also removed.

実験的 WebGL レンダラの削除の後で、AtlasManager も同様に削除されました。地図はこのレンダラによってのみ使用されました。
API でないスタイルの getChecksum 関数も削除されます。


□Change of the behavior of the vector source's clear() and refresh() methods
ベクタソースの clear() と refresh() メソッドの動作の変更

The ol/source/Vector#clear() method no longer triggers a reload of the data from the server. If you were previously using clear() to refetch from the server, you now have to use refresh().

ol/source/Vector#clear() メッソドはサーバからデータの再読込をもう引き起こしません。以前、サーバから再取得するために clear() を使っていた場合、現在、refresh() を使わなければなりません。

The ol/source/Vector#refresh() method now removes all features from the source and triggers a reload of the data from the server. If you were previously using the refresh() method to re-render a vector layer, you should instead call ol/layer/Vector#changed().

ol/source/Vector#refresh() は、現在、ソースからすべてのフィーチャを削除し、サーバからデータの再読み込みを引き起こします。以前、ベクタレイヤを再描画するために使っていた場合、代わりに、ol/layer/Vector#changed() 呼び出した方がいいでしょう。


□Renaming of getGetFeatureInfoUrl to getFeatureInfoUrl
getGetFeatureInfoUrl を getFeatureInfoUrl に改名

The getGetFeatureInfoUrl of ol/source/ImageWMS and ol/source/TileWMS is now called getFeatureInfoUrl.

ol/source/ImageWMS と ol/source/TileWMS の getGetFeatureInfoUrl は、現在、getFeatureInfoUrl と呼ばれています。


□getFeaturesAtPixel always returns an array
getFeaturesAtPixel は常に配列を返します

getFeaturesAtPixel now returns an empty array instead of null if no features were found.

getFeaturesAtPixel は、現在、フィーチャが見つけられない場合、null の代わりに空の配列を返します。


□Hit detection with unfilled styles
塗りつぶされていないスタイルのヒットデテクション(検知)

Hit detection over styled Circle geometry and Circle and RegularShape styles is now consistent with that for styled Polygon geometry. There is no hit detection over the interior of unfilled shapes. To get the previous behavior, specify a Fill style with transparent color.

スタイルされた Circle ジオメトリと Circle と RegularShape スタイル一面のヒットデテクション(hit detection)は、現在、スタイルされた Polygon ジオメトリのそれと一致します。塗りつぶされていない形状の内側一面のヒットデテクションはありません。以前の動作を取得するために、透明色の Fill スタイルを指定します。


■Other changes
その他の変更

□Allow declutter in image render mode
イメージレンダモードの declutter を許可
(訳注:declutter 片付ける、不要なものを処分する)

It is now possible to configure vector tile layers with declutter: true and renderMode: 'image'. However, note that decluttering will be done per tile, resulting in labels and point symbols getting cut off at tile boundaries.
Until now, using both options forced the render mode to be hybrid.

現在、declutter: true と renderMode: 'image' でベクタタイルレイヤを設定することができます。しかしながら、declutter はタイルごとに実行され、結局タイルの境界でラベルやポイントが切断されることに注意してください。
現在まで、両方のオプションを使うために レンダモード(renderMode)を hybrid にさせます。


□Always load tiles while animating or interacting
アニメーションやインタラクションを動作しながら常にタイルをロードします

ol/PluggableMap and subclasses no longer support the loadTilesWhileAnimating and loadTilesWhileInteracting options. These options were used to enable tile loading during animations and interactions. With the new DOM composition render strategy, it is no longer necessary to postpone tile loading until after animations or interactions.

ol/PluggableMap と subclasses は loadTilesWhileAnimating と loadTilesWhileInteracting オプションをもうサポートしません。これらのオプションは、アニメーションとインタラクションの間、タイルロードが可能でした。新しい DOM コンポジションレンダストラテジ(DOM composition render strategy)で、アニメーションとインタラクションの後まで、タイルロードを延期する必要はもうありません。


(Changes も参照して下さい。)

0 件のコメント: