Dictionary styles <\/SPAN>は、マップやアプリケーションで属性豊富なデータを視覚化するための高度にカスタマイズ可能な方法を提供します。個々のシンボルパーツの<\/SPAN><\/SPAN>look-up table<\/SPAN><\/SPAN><\/STRONG>、属性値をシンボルキーに接続する<\/SPAN><\/SPAN>dictionary script<\/SPAN><\/SPAN><\/STRONG>、および微調整のための<\/SPAN><\/SPAN>configuration file<\/SPAN><\/SPAN><\/STRONG>とともに、これらのスタイルはDictionary Rendererと組み合わせて使用され、データ内の複数の属性によって駆動される複雑なシンボルを構築できます。 <\/SPAN><\/SPAN><\/P>\n私はLiving Atlasの<\/SPAN><\/SPAN>Alternative Fuel Stations layer<\/SPAN><\/SPAN><\/A>のために辞書スタイルを作成しました。このレイヤーは各ステーションの情報を一目で提供します。 <\/SPAN><\/SPAN> <\/span><\/P>\n
<\/span><\/span><\/span><\/P>\nこのブログでは、私が作成した辞書スタイルを詳しく見ながら、自分だけのカスタム辞書スタイルを作成するためのトップヒントをいくつか共有します。読みながらスタイルを探索したい場合は、こちら<\/SPAN>にリンクがあります。<\/SPAN><\/SPAN>the style<\/SPAN><\/SPAN><\/A> と、すでにそのスタイルで構成されたレイヤーがあるweb map<\/A>もあります。 <\/SPAN><\/SPAN><\/SPAN><\/P>\n
Tip 1 6 スタイル作成時に使用するリソースを集める <\/SPAN><\/SPAN><\/H3>\n新しい辞書スタイルを作り始めるときは、いつもお気に入りのリソースを手元に用意しています。最初は同僚Thadによるこのブログです：<\/span> Create custom dictionary styles for ArcGIS.<\/span> このブログでは、スタイル作成に必要なすべてのツールと手順が最初から最後まで共有されています。私のお気に入りツールは：<\/span> <\\/span>\n\n?~`[];',./\\-=\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ 探求する価値のあるサンプルスタイル。<\/SPAN> <\/SPAN><\/P>
ヒント <\/SPAN>2<\/SPAN> 013013 組み込みのデフォルトシンボルキーを忘れないでください <\/SPAN><\/SPAN><\/SPAN><\/H3>
各個別のシンボルパーツには、ルックアップテーブル<\/STRONG>に定義されたユニークなキーがあります。これらのシンボルパーツを作成および編集する最良の方法はArcGIS Proで行うことです。まず、スタイルをプロジェクトカタログに追加し、次にAlternative Fuel Stationsスタイルをダブルクリックしてテーブルを開きます。ここでスタイル内のすべてのシンボルパーツが見つかります。 <\/SPAN> <\/SPAN><\/P>
まずFuel Typeシンボルに注目しましょう。7つの燃料タイプシンボルと1つのデフォルトシンボル（後ほど説明します）があり、それぞれ独自のユニークキーを持っています。デフォルトキーを除き、これらのキーはFuel_Type<\/STRONG> フィールドにある燃料タイプの略語に続く「fuel-」という形式に従っています。 <\/SPAN> <\/SPAN><\/P>
<\/span><\/P>
dictionary script<\/STRONG>は、属性値を使用してシンボルキーを構築する方法についての指示を含むArcadeスクリプトです。dictionary scriptは$feature.Fuel_Type<\/FONT>を使用して燃料タイプキーを生成します。これは最初にリストされているキーなので、フィーチャが評価されると、タイプキーが最初に返されます。 <\/SPAN> <\/SPAN><\/P>
<\/span><\/P>
Fuel_Type<\/STRONG><\/FONT>が空白の場合や、「ELEC」ではなく完全な名前「Electric」が使われた場合はどうなるでしょうか？この仮定の場合、スクリプトは「fuel-」および「fuel-Electric」という、ルックアップテーブルに存在しない2つのキーを返します。ここでデフォルトシンボルが登場します！<\/SPAN> <\/SPAN><\/P>
Dictionary rendererには、スクリプトで最初に返されたキーがルックアップテーブルに存在しない場合に使用される組み込みのデフォルトシンボルキーがあります。ポイントの場合は「Invalid_P」、ラインの場合は「Invalid_L」、ポリゴンの場合は「Invalid_A」というキーでシンボルを追加するだけです。 <\/SPAN><\/P>
ヒント <\/SPAN>3<\/SPAN> 013 プリミティブオーバーライドでシンボルプロパティ値を変化させる<\/SPAN><\/SPAN> <\/SPAN><\/SPAN><\/H3>
poColorを指定します。プリミティブオーバーライドの構文はpo:<primitive_name>|<property_name>|<value>です。このスタイルでは、検証シンボルを描画する際に、status-colorでタグ付けされたシンボルの任意の部分について、色がpoColorの値に置き換えられます。
次に、プリミティブ名でシンボルの部分にタグを付けます。このオーバーライドは、ルックアップテーブル内の検証済みおよび未検証シンボルのストロークに適用されます。ルックアップテーブルからVerifiedシンボルを選択し、レイヤープロパティタブに移動します。ここから要素のドロップダウンを使ってShape Fillシンボルまで掘り下げ、そのシンボルをフォーマットして塗りつぶしとストロークのプロパティにアクセスします。構造タブでストロークの隣にある小さなタグ記号をクリックし、プリミティブ名としてstatus-colorを指定します。未検証シンボルでも同様に繰り返します。
シンボル要素にタグが付けられたことで、このスタイルはわずか2つの個別のシンボル部分を使って、検証ステータスと稼働ステータスの8通りすべてのアウトライン組み合わせをサポートできるようになりました。
ヒント 4 – 設定プロパティを活用する
もしAlternative Fuel Stations Living Atlasレイヤーをご存知なら、「ちょっと待って、そのデータには‘verified’フィールドがないじゃないか！」と思うかもしれませんね。見抜かれました。私は将来のブログで役立つように‘verified’フィールドを追加した修正済みサブセットを使用しています。このスタイルはverifiedフィールドで動作しますが、おそらくLiving Atlasレイヤーを使っていてそのフィールドがデータにない場合もあるでしょう。だからこそ、検証フィールドを含めるか無視するかを選べる設定プロパティを作成しました。
設定ファイルはJSONオブジェクトで、シンボル描画方法を変更する追加設定オプションを定義できます。このスタイルには複数の設定オプションがありますが、まずuse_Verified_Field設定から始めましょう。ここでは設定名、デフォルト値、可能な値、および簡単な説明を指定しました。また辞書スクリプトで利用されるシンボルフィールドとしてVerifiedフィールドも含めています。ArcGIS Proでこれがどのように機能するかがよくわかります：
use_Verified_Field設定がオンの場合、辞書スクリプトはverifiedフィールドの値を使って実線または破線用のキーを返します。オフの場合はすべてのフィーチャに対して実線用のキーを返します。辞書スクリプトで設定プロパティの値を活用するには構文$config.nameまたはこの場合$config.use_Verified_Fieldを使用します：
これで、このスタイルを使ってレイヤーにシンボル化する誰もがverifiedフィールドを使用するかどうか制御できます。
ヒント 5 – ラベルにはシンボルフィールドかテキストフィールドどちらを使うべきか知ること
最後の設定プロパティは、どのようにシンボル部分 はデータ内のシンボロジーフィールドを使用して計算されますが、ここではラベルのオン・オフを切り替えるプロパティを見てみましょう。レイヤー内で、EV charging stations は所属するネットワークに関する情報をEV_Networkフィールドに含んでいます。もしステーションがネットワークに属していない場合、そのフィールドには「Non-networked.」と入力されます。
まず、ラベル用の新しいシンボルをルックアップテーブルに追加し、レイヤープロパティタブでそれがシェイプテキストシンボルであることを確認します。データ内のEV networkを使用するには、テキスト文字列を括弧内のフィールド名、つまり[EV_Network]に置き換えます：
設定ファイルでは、 show_EV_Networkプロパティを作成し、ラベルのオン・オフを切り替えられるようにしました。また、EV_Networkフィールドをシンボルフィールドとして指定しました。なぜテキストフィールドではないのか？と疑問に思うかもしれません。テキストフィールドはすべてのフィーチャーにラベルを付けたい場合に最適です。もしテキストフィールドを使っていたら、すべてのフィーチャーがそれぞれのEV_Network値でラベル付けされ、ネットワークに属さないEVステーションには「Non-networked」というラベルが付いてしまいます。私はネットワークに属するEVステーションだけにラベルを付けたかったので、それを辞書スクリプトの条件にしました：
テキストフィールドは辞書スクリプトからアクセスできないため、ロジック内で変数として使用できません。スクリプトはラベルキーを返すかどうか判断するためにEV_Network値を使う必要があるので、設定ファイルでこのフィールドをシンボルフィールドとして含めました。
ヒント 6 – ユニークなプリミティブ名を使う
[connector type]_markerという構文に従ったprimitive nameがタグ付けされています（例：J1772_marker、CHAdeMO_markerなど）。
したがって、ステーションに2つのコネクタ、J1772とCHAdeMOがある場合、キーは次のようになります：
• バナーキー: background-2
• コネクタータイプキー: con-J1772;po:J1772_marker|OffsetX|17;` と `con-CHAdeMO;po:CHAdeMO_marker|OffsetX|28;
前回のprimitive overridesの例とは異なり、各symbol partには一意のprimitive nameが必要です。これは、それぞれのsymbolに適用されるオフセット値が重ならないようにするためです。
### ヒント 7 – 描画順でキーを返す
この辞書スクリプトの最後の行では、キーの文字列を返します。これによりクライアントは最終的なシンボルを作成するために使用する個々のsymbol partsを知ることができます。文字列内でキーが現れる順序がsymbol partsが描画される順序を決定します。このスタイルで描かれた最終シンボルを見ると、コネクタータイプはバナーの上に描かれ、バナーは燃料タイプシンボルとアウトラインの下に描かれ、一方でアクセシビリティインジケーターは上に描かれていることがわかります。
この辞書ではすべての構成プロパティがオンの場合、キーは次の順序で返されます：燃料タイプ、ネットワーク名、EVバナー、EVコネクタータイプ、検証済みキー、燃料タイプ、およびアクセス。燃料タイプキーは2回返されます。これは組み込みデフォルトキー（Invalid_P）が最初に返されたキーがルックアップテーブルにない場合のみ使用されるためです。燃料タイプキーを2回追加することで適切な描画順序が保証されますが、もう一つの方法として不要な塗りつぶしシンボルを削除して「埋もれる」可能性のあるシンボルを取り除くこともあります。
以上で、自分だけのカスタム辞書スタイルを作成するための私のお勧めトップヒントはすべてです！このスタイルについてさらに詳しく知りたい場合はこちらからダウンロードするか、自分自身でカスタムスタイル作成を始めてみてください。コメント欄でカスタム辞書スタイル作成についてどんなアイデアがあるか教えてください！
