Repository navigation
Draw many polylines as tiles, with the Boston roads sample - #119
Merged
Merged
Conversation
The overlay went two frames after the list reached Polygons(), and the map then showed no polygons for about 6.5 s while the SDK merged holes, prepared and handed over the tiles. It now counts PolygonState.onAdded for the current load (callbacks from an earlier dataset are ignored) and shows the time in the stats line.
Switching the area while the polygons were being drawn closed the loading overlay at once (and during reading it never came back), and a callback for a state of the replaced list counted toward the new one. Each onAdded now records its id; the count is redone against every list handed to the map, an id already on the map counts for it, and the overlay goes when every distinct id of the list is in. Same as ios-sdk and react-sdk.
The building ids (Overture's, 36 characters each) were most of every file, and the page is a polygon demo. MCPG v2 drops them: a polygon's id on the map is its index in the file. Counts and coordinates are zigzag varints of the same 1e-6 degree differences, a ring's closing vertex is not stored (the reader closes the ring again), and a header byte says which fields the file carries: height, land use (as an index), the downtown area, name. Same format as the React and iOS samples. Downtown is now a v2 asset too (boston-downtown.bin, 0.25 MB, was 2.2 MB of JSON). The pushed city files become boston-city-buildings.bin (2.1 MB, was 10.5) and boston-city-parcels.bin (4.0 MB, was 14.1). The InfoBubble and the tap line show the area (outline less holes) where they showed the Overture id or the parcel id. The attribution stays. BostonDataTest decodes a fixture and the bundled file.
The city-wide buildings (2.1 MB) and parcels (1.9 MB) now ship in assets/boston next to downtown; nothing has to be pushed with adb. The React sample's examples/basic/tools/boston/ builds them (see its README). MCPG v2 gains a header byte, digits: coordinates are integers of 10^-digits degree. Buildings and downtown stay at 1e-6; parcels are at 1e-5 with near-collinear vertices dropped (0.5 m). The decoding tests cover both units and check the bundled city files.
…t feat/overlay-on-added Each with feat/polygon-tiling (and through it develop) merged in.
Every road of Boston (Overture transportation segments, 54,645 polylines, 234,765 points, assets/boston/boston-city-roads.bin, about 1 MB) with one Polylines() call: coloured, widened and stacked by road class, a loading overlay until every road's onAdded, a tap InfoBubble (class, name, length) at the point on the road nearest the tap, a Tiles / Native switch (PolylineTiling) and an overlap check (polygon tiles < circle < road tiles < marker). Opens from '--es page boston-roads' with camera / tiling / overlap extras for measurements. The MCPG v2 reader learns the road class (16) and lines (32) bits; the roads decoder test uses the fixture the React and iOS tests share. android-sdk-core, android-sdk-compose and the ten providers move to their feat/polyline-tiling commits.
…verlay-on-added android-sdk-core's gitlink conflicted; it now points at android-sdk-core's feat/overlay-on-added, which has merged that repository's feat/polygon-tiling (and so the develop it took in).
android-sdk-core's gitlink conflicted; it points at android-sdk-core's feat/polyline-tiling after that branch merged feat/overlay-on-added.
This was referenced Nov 9, 2026
Merged
Merged
Merged
Merged
Contributor
Author
|
CI: base が develop/main でないので Test は PR で走らないため、workflow_dispatch で実行しました(https://github.com/MapConductor/android-sdk/actions/runs/42699020250)。android-sdk-core の ZoomAltitudeConverterGoldenTest 2 件が落ちます。develop でも同じ 2 件が落ちる(https://github.com/MapConductor/android-sdk/actions/runs/42699917590)ため、このブランチ由来ではありません(このブランチは ZoomAltitudeConverter に触れていません。手元の JDK では通る、浮動小数の完全一致の試験)。submodule 側の各 PR の build はすべて成功しています。 |
Contributor
Author
|
向け先を |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
なぜ
ポリゴンと同じように、ポリラインも数万本を渡せるようにするためです。ボストン市内の道路(54,645 本・234,765 頂点)をネイティブの線で描くと、iOS の Google で全 onAdded まで 114 秒・1.5 GB、Android の Google は Java ヒープが尽きて落ちます。ポリゴンのタイル化(
feat/polygon-tiling)と同じ仕組みで、多数のポリラインをラスタータイルとして描きます。設計の要点(web・Android・iOS で同じ)
Polylines(states):Polygonsと同じ形のまとめて渡す部品。そのインスタンスが足した id だけを足し引きするので、複数のPolylines/Polylineが同じ地図で共存できます(iOS は既存のPolylines(_:)のまま)。PolylineTilingOptions/PolylineTileSet/PolylineTiler/PolylineController.tiler: 名前と既定値(2,000 本以上または頂点 50,000 以上)はポリゴンと 1 対 1。レイヤー id はmc-polyline-tiles。ShapeTileSet/ShapeTiler/ShapeTileRendererに移し、Polygon*はその上の薄い層になりました。公開 API は追加のみです。polylineTilingOptions、Android は compose のPolylineTiling(options)、iOS はMapViewContent.polylineTilingOptions/PolylineTiling要素。このリポジトリで変えたこと
pages/polyline/boston/、ViewModel・データの読み込み・「Overlap check」)。読み込みの試験BostonRoadsDataTest。boston-city-roads.bin(1,019,811 B、gzip 597 KB): Overturetransportation/segment2026-10-21.0 の road を、Analyze Boston の市境で切ったもの。54,645 本・234,765 頂点(元 362,585)。1e-5°、直線上の頂点を 0.5 m で省く(両端は残す)。ID は持たず、種別(u8)と名前だけ。examples/basic/tools/boston/README.md。feat/polyline-tilingへ。検証(Android、追従後の 158d1ee)
--rerun): core 375・compose 10・arcgis 18・googlemaps 5・here 6・longdo 6・mapbox 1・mappls 4・maptiler 9・tomtom 3・example-app 13 すべて通過。openmobilemaps は 17 件中 1 件失敗(OpenMobileMapsDriverConformanceTest、develop の 5df7b09 で入ったLog.isLoggableがモックされていないため。このブランチの差分は触れていない)。PolygonTileRenderer$Model/$Simplifiedと、PolylineOverlayの 1 引数コンストラクタの行の位置が動いただけ)。時間とメモリ(ボストンの道路 54,645 本・234,765 頂点)
web(Chromium、Playwright。「全 onAdded / 次のフレーム」ms)
JS ヒープ(GC 後): MapLibre ⇄ Google をタイルで 4 往復 251.0 → 266.4 → 267.0 MB(2 往復目以降は横ばい)。ネイティブだと Google の時に 475 MB 前後。MapLibre ⇄ Leaflet は 251.1 → 253.2 MB。
Android(タブレット、MapLibre)
Google: タイル化ありで描画 0.87 s(録画)。ネイティブは OOM で落ちる(下記)。
メモリ: MapLibre ⇄ Google を 6 往復、PSS 899,652 K → 最大 1,060,426 K → 916,405 K、native heap 182,752 K → 181,524 K。増え続けません。
iOS(iPad、Release。「読み込み → 全 onAdded」と footprint)
ほかのプロバイダ(z16、タイル化あり): Mapbox 1,028 ms / 397 MB、MapTiler 914 / 310、Mappls 1,727 / 241、MapKit 1,021 / 393、ArcGIS 923 / 164、ArcGIS2D 943 / 370、HERE 1,175 / 483、TomTom 1,229 / 303、Longdo 2,499 / 144、OMM 895 / 394。
メモリ: MapLibre ⇄ Google を 8 往復、277 MB → 往復中 259〜396 MB → 260 MB。増え続けません。
挙動の変わる所
PolylineManager.find、タイルでもネイティブでも同じ)。許容距離 = 既存の指の大きさ(tapTolerance)+ 線幅 / 2。太い線は縁から指の大きさ以内であたります。複数あたれば最も近い線。外接矩形で先に候補を絞るので、5 万本でも毎タップ全点をなめません。返す位置(線上の最近点)は今までどおりです。OverlayStacking.rasterKey(styleLayerId:))。追加の順に関係なく、ポリラインのタイルがネイティブのポリラインの下に入ります。SDK の制約で重なり順を守れないもの
確認できていないもの
OutOfMemoryErrorで落ちます(GoogleMap.addPolyline→PolylineOptions.writeToParcel、Java ヒープが上限 512 MB に到達)。1 本ずつ Parcel に詰めて GMS に渡すためで、タイル化ありなら落ちません。このため Google のタイル化あり/なしの時間は並べられていません。OpenMobileMapsDriverConformanceTest1 件(develop のLog.isLoggableがモックされていない)、iOS ArcGIS・TomTom の単体テスト各 1 件、iOS Google のテストターゲットのビルド(GoogleMaps が iOS 17 を要求)。base について
ポリラインの差分だけをレビューできるように、base は
feat/overlay-on-added(feat/polygon-tiling+ onAdded + ボストンのサンプル。そのリポジトリに無い場合は develop)にしています。feat/polygon-tilingは develop にマージ済みなので、feat/overlay-on-addedが develop に入ったら、この PR の base を develop に付け替えてください。追従は rebase せず merge commit で行いました(
origin/feat/polygon-tiling→feat/overlay-on-added→feat/polyline-tiling)。マージの順番
feat/overlay-on-added(onAdded とボストンのサンプル)を develop へ。入ったら下の PR の base を develop に付け替えます。feat/overlay-on-added)develop)develop)develop)develop)develop)feat/overlay-on-added)feat/overlay-on-added)develop)develop)develop)develop)プロバイダは android-sdk-core の
PolylineTiler/ 重なり順を使うので core が先です。どの PR もまだマージしていません。マージはレビューのうえで判断してください。