やった！ 私たち（
piumossoと
預言者 ）はYandex.Martセミナーに参加しました。 そして、ほぼ2週間が経過しましたが、私たちは覚えていて気に入ったものについて書くことにしました。 さらに、最近
、セミナーからの講義のすべての
ビデオがネットワークにアップロードされました。 開発者会議は、サモカトナヤの「古い」Yandexオフィスで非常に快適な雰囲気の中で開催されました。主催者に感謝します。 聴衆は2種類でした-実際には、開発者とプロジェクトマネージャーです。 レポート自体も、一部は技術的であり、一部は情報提供のためのものでした。 多数の質問が寄せられ、その多くが回答を受け取りました。
APIパースペクティブ
...または新しい年に私たちを待っているもの：
支店1.1
- KMLサポートの改善（YMapsML形式が作成されたとき、KMLは独自性のマークを付けましたが、オープン標準になったため、Yandexも注意を払っています）、GPXサポート
- 新機能のモジュール性のサポート（残念ながら、この段階では、カーネルレベルではなく、新しい追加モジュールのレベルで。これは、たとえばポリゴンが必要ない場合でも、カーネルは88キロバイトのコードを保持することを意味します）。
- 「メトロ」モジュール（最寄りの地下鉄駅を検索）;
- ホットスポットモジュール（マップ上のレンダリングを使用して、マップ上に多くのオブジェクトを表示する機能）。
これらのユーティリティはすべてそもそもリリースされますが、Yandexは伝統的に用語に名前を付けていません。 その後、後方互換性の喪失に関連するかなり深刻なAPIアップグレードが行われます（これはブランチ1.2になります）。 これは、行われた間違いを修正し、APIのコンポーネント部分のアーキテクチャをやり直して速度を上げ、コードの量を減らすために行われます。 原則として、Googleにはほぼ同じ目標があり（
新しいAPI v3カードの
バージョンは 5月にリリースされました）、モバイルバージョンに重点が置かれています。
支店1.2
- 統一されていないAPIの統一。
- 目印とポリゴンの代わりにGeoObject + Geometry（このペアでは、Geometryが座標に関連付けられたすべてのロジックを担当します）。
- MultiGeometry（1つのオブジェクトに対する複数のジオメトリの対応）;
- 全体的なモジュール性によるコアサイズの削減。
- イベントでの作業の利便性の向上。
- デバッグの利便性を改善します。
また、
Tiler-画像をタイルに自動的にスライスして、APIを使用して独自の「マップ」を作成するプログラム。 この投稿を書いている間、すでに外出できました:)
近い将来に期待しないこと
残念ながら（または幸い）、当面の計画では、交通情報用のAPI、パノラマ用のAPI、またはBird's Eyeスナップショットの作成、またはマップ用のFlash APIのいずれにも言及しませんでした。 いつかこのすべてが表示される可能性があります。
ゲスト
マップの開発者は、仲間のAPIユーザーに、サイトでのYandex.Mapsの実装に関する成功、問題、考えを共有するよう呼びかけました。 YandexマップとGoogle検索のオリジナルマッシュアップである
maplos.comの作成者の話を聞くのは特に興味深いものでした。 彼はサーバー上のオブジェクトの地理座標を保存しないことに興味がありますが、Googleの発行からそれらを受け取り、<user request> + <street name>に基づく一連の要求を形成し、ジオコーダーを使用して結果を地図に表示します。 キエフでのみ機能しますが。
質問への回答
開発者は、彼から寄せられたすべての質問に非常に喜んで答えてくれましたが、登録中に残した緊急の質問を無視しませんでした：「なぜGoogleマップではなくYandexマップですか？」
このトピックを完全に明らかにするスライドの内容は次のとおりです。
mpetruninスライドの作成者、素晴らしい
taxovik.ruサービスの作成者、これも講演者の一人でした。
私たちにとって、多くの人にとって、決定的な要因はロシアのさまざまな都市のマップの可用性であり、Googleをどのように見てもまだそうではなく、そのAPIのフルパワーは多くの場合適用されません。 Yandex.Mapsが新しいプロジェクトと
古いプロジェクトに表示されるのを待ちます:)
管理および法的問題カードの問題
著作権とキーに関する法的立場が発表されました。 キーは、APIのユーザーがライセンス契約の条件に同意したことを示すサインです。 したがって、どのカードプロバイダーがYandexに対する権利を「委任」するかによれば、その著作権はカードがそれに属していることをまったく意味しないため、さまざまなデータソースが平準化されます。
カードはさまざまな「良い」サプライヤからのものであり、あまり良いサプライヤではありません。 形式
-ArcGISおよび
MapINFO 。
マテリアルの操作は、データの統合と、ベクターオブジェクトの要件、インデックス作成、レンダリング（および設計）への準拠の制御に帰着します。 Yandexは、受け取ったレンダリングの外観を改善するという点で動く余地があると考えています。
Yandexとサプライヤーの関係は一方的ではありません。同社はバグ報告の仲介者でもあります。 ユーザーが見つけたエラーをサプライヤに送信し、その排除を制御します。 この動作は、ライセンス契約の下で、Yandexがベクターカードに対して独自の調整を行うことができないという事実によるものです。
別の歌は衛星画像であり、それを操作する際に、地理オブジェクトと物理座標の曲がった地理参照の問題があります（ベクトルマップは常に正確で適切ではないため）
ボーナス
APIのメインユーザーはYandexそのものです！ 開発者から、注意する価値のあるいくつかのニュアンスを学びました。 まず、もちろん、クライアントの最適化に多くの時間を費やしました。最も効果的な方法は、ロードをプリロードに分割することでした。追加モジュール、追加レイヤー。 サービスとレイヤーの操作は独立して機能します。 maps.yandex.ruの複雑さは非常に大きいため、一般的なコントローラーのアーキテクチャスキームが編成されました。 メインモジュール（検索フォーム、ポイントのクリック、ルートシート、マップ、ルート）が相互に直接相互接続されていないという事実にありますが、さまざまなイベントを監視し、このルーチンからモジュールを解放する共通のコントローラーを介しています。
一部の人にとっては発見かもしれませんが、Yandex.NETマップAPIには、
少しパッチが適用されていますが、本格的なjQuery 1.3.2が含まれています。 マップAPIに基づくプロジェクトの場合、jsライブラリを再度ロードせずに数十キロバイトを節約できます。
おわりに
Yandex Mapsの開発者が喜んで一般の人々とコミュニケーションを取り、レポートの形式があまり時間的に制限されておらず、Yandexoidsと直接会って話をしたいという人たちがとても気に入った。 繰り返しますが、セミナーには有益で興味深い情報が豊富にありました。ビデオを見ることをお勧めします。
ワークショップのフォトギャラリーを見るセミナーの講義のビデオ