トップ ＞ PC版地図アプリGIS ＞ PC版地図アプリGIS開発記録

PC版地図アプリGIS開発記録

2025.3.14 二重線描画でエラー

京成本線を横切る太い線は左下の谷津干潟の描画で生まれるようだ。

谷津干潟でエラーが起きるのでなく、細長い「本大久保１号緑地」が問題。 中ズームの間引きでエラーが起きる。単純な閉曲線ではなくなる。

何年か前は、間引きでも閉ループを維持していたが、今は単純化している。

少なくとも当面は簡単な方法で回避したい。

閉曲線の内側に平行な線分を引き、隣り合う線分の交点を求めている。いびつな閉曲線では うまくいかない。

太い境界線を描画し、閉曲線の外になるものを消せば、所望の結果が得られる。 画素単位の処理には時間がかかるが、対象となるポリゴンは少ないので、レンダリング時間としては可能である。 

OSM.getIntersection: zoom=13 osm_id=574549074 a1*b2=65.462962 a2*b1=57.842807 xA=340.882477 yA=300.487274 xB=357.275208 yB=304.499939 xC=359.026947 yC=296.899933 xD=342.712860 yD=293.371368
OSM.getIntersection: zoom=13 osm_id=574549074 a1*b2=-0.277500 a2*b1=-7.897655 xA=359.026947 yA=296.899933 xB=342.712860 yB=293.371368 xC=345.737946 yC=296.557861 xD=345.659302 yD=296.073761
OSM.getIntersection: zoom=13 osm_id=574549074 a1*b2=7.935727 a2*b1=0.315571 xA=345.737946 yA=296.557861 xB=345.659302 yB=296.073761 xC=340.882477 yC=300.487274 xD=357.275208 yD=304.499939
OSM.getIntersection: zoom=13 osm_id=574549074 a1*b2=65.462962 a2*b1=57.842807 xA=341.500671 yA=297.961853 xB=357.893402 yB=301.974518 xC=358.477295 yC=299.441162 xD=342.163208 yD=295.912598
OSM.getIntersection: zoom=13 osm_id=574549074 a1*b2=-0.277500 a2*b1=-7.897655 xA=358.477295 yA=299.441162 xB=342.163208 yB=295.912598 xC=343.171570 yC=296.974762 xD=343.092926 yD=296.490662
OSM.getIntersection: zoom=13 osm_id=574549074 a1*b2=7.935727 a2*b1=0.315571 xA=343.171570 yA=296.974762 xB=343.092926 yB=296.490662 xC=341.500671 yC=297.961853 xD=357.893402 yD=301.974518
OSM.getIntersection: zoom=13 osm_id=574549074 a1*b2=65.462978 a2*b1=57.842827 xA=-43.117527 yA=300.487274 xB=-26.724791 yB=304.499939 xC=-24.973049 yC=296.899933 xD=-41.287140 yD=293.371368
OSM.getIntersection: zoom=13 osm_id=574549074 a1*b2=-0.277500 a2*b1=-7.897657 xA=-24.973049 yA=296.899933 xB=-41.287140 yB=293.371368 xC=-38.262074 yC=296.557861 xD=-38.340717 yD=296.073761
OSM.getIntersection: zoom=13 osm_id=574549074 a1*b2=7.935729 a2*b1=0.315571 xA=-38.262074 yA=296.557861 xB=-38.340717 yB=296.073761 xC=-43.117527 yC=300.487274 xD=-26.724791 yD=304.499939
OSM.getIntersection: zoom=13 osm_id=574549074 a1*b2=65.462985 a2*b1=57.842827 xA=-42.499344 yA=297.961853 xB=-26.106607 yB=301.974518 xC=-25.522692 yC=299.441162 xD=-41.836784 yD=295.912598
OSM.getIntersection: zoom=13 osm_id=574549074 a1*b2=-0.277500 a2*b1=-7.897658 xA=-25.522692 yA=299.441162 xB=-41.836784 yB=295.912598 xC=-40.828430 yC=296.974762 xD=-40.907074 yD=296.490662
OSM.getIntersection: zoom=13 osm_id=574549074 a1*b2=7.935729 a2*b1=0.315571 xA=-40.828430 yA=296.974762 xB=-40.907074 yB=296.490662 xC=-42.499344 yC=297.961853 xD=-26.106607 yD=301.974518

2025.3.5 man_made=bridgeで layerがおかしい

JOSMでチェックするとデータは man_made=bridge;layer=1 であるが、 calcZorderでは layerが 0 である。

parseTags直後では layer=1 である。

calcZorderは道路等についてのみ。

とりあえず、man_made=bridgeだけ例外処理をした。

2025.2.21 鉄道と道路が交差するところで、鉄道の描画が一部おかしい

踏切アイコン(ｘ)はまだ描画していない。

何故かスマホ版とかなり違っていた。

スマホ版では鉄道の casing は bridge のときだけ。線路の描画は fill で行っている。

2025.2.18 東京都の島しょ部の境界線(boundary=administrative)が描画されない

プログラムの修正で描画されるようになった。

2025.2.17 drawIconMulti完了

富士山で崖(natural=peak)の描画を確認した。

2025.2.16 道路の描画をほぼ完成した

道路名描画はこれから。

2025.2.16 OSMバイナリレコード作成にバグ混入か[解決]

地図の表示とバイナリレコード作成を一体化したが、 ハイズームではフォルダ数、ファイル数が３倍ほど増えた。

mid、low では誤りはなさそう。

japan-high12ではファイル数 22万、サイズ 13GB、ディスク上のサイズ 3.4GBとなった。 誤ったフォルダに同じレコードが保存されているようだ。

以前は xフォルダは 3430～3800、これが 3226～3830 に増えている。

railway=subway を railway=rail と同格にしたが、このとき、バグが混入したのかもしれない。

ディレクトリを変更したが、宣言があちこちに分散しており、この修正漏れが原因かもしれない。

レンダリングに使わない巨大なリレーションレコードは除外しているが、この処理に不具合が起こり、 このレコードが無数のファイルになっている可能性が高い。

kanto-high12でもファイル数 20万、サイズ 10GBになる。重複が多いレコードは high12 ではなく、high8 に置くはず。

relation処理を止めたが、状況は大差なかった。

Encoder結果はファイルサイズは同じであるが、中身に違いはないか、コマンドプロンプトでバイナリチェックしてみる。 

C:\Users\hatad>fc \map\obf1\kanto\way.obf \gisdata\obf\kanto\way.obf /b
ファイル \MAP\OBF1\KANTO\way.obf と \GISDATA\OBF\KANTO\WAY.OBF を比較しています
FC: 相違点は検出されませんでした

Encoderには問題がないことが確認できた。やはり、Parser に問題がある。

53KBのあやしいファイルをダンプしてみた。差分化のために、ノードを挿入するため、同じパターンが続くことはありうる。 レコード末尾(タグ部)に 「Southeast Asia-Japan Cable」となっている。 アジア地域を結ぶ光海底ケーブルのようだ。航路と同じく、巨大なラインレコードのようだ。

タグは man_made=pipeline; substance=cable; …　であろうか？

多分、これまでは、タグではねていたのであろう。なにかのはずみで抽出されるようになったのであろう。

しかし、なぜ、high8 に置かれないのだろう。 

/mh/bin/dump /gisdata/dat/kanto-high12/3226/1622.dat

引数の順番を間違えていた。 

//new Parser().parse(selectedArea, "high", 8, 12);
new Parser().parse(selectedArea, "high", 12, 8);

   < way id="1324108117" visible="true" version="1" changeset="157919807" timestamp="2024-10-15T12:50:55Z" user="wvdp" uid="436419">
   < nd ref="12252877455"/>
   < nd ref="12252877454"/>
   < nd ref="12252877453"/>
   < nd ref="12252877452"/>
   < nd ref="12252877451"/>
   < nd ref="12252877450"/>
   < nd ref="12252877449"/>
   < nd ref="12252877448"/>
   < nd ref="12252877447"/>
   < nd ref="12252877439"/>
   < nd ref="12252877446"/>
   < nd ref="12252877445"/>
   < nd ref="12252877435"/>
   < nd ref="12252877433"/>
   < nd ref="12252877444"/>
   < nd ref="12252877443"/>
   < nd ref="12252877429"/>
   < nd ref="12252877442"/>
   < nd ref="12252877428"/>
   < nd ref="12252877427"/>
   < nd ref="12252877412"/>
   < nd ref="12252877426"/>
   < nd ref="12252877425"/>
   < nd ref="12252877424"/>
   < nd ref="12252877423"/>
   < nd ref="12252877422"/>
   < nd ref="12252877421"/>
   < nd ref="12252877420"/>
   < nd ref="12252877419"/>
   < nd ref="12252877418"/>
   < nd ref="12252877417"/>
   < tag k="communication" v="line"/>
   < tag k="name" v="Southeast Asia-Japan Cable"/>
   < tag k="seamark:cable_submarine:category" v="fibre_optic"/>
   < tag k="seamark:type" v="cable_submarine"/>
   < tag k="short_name" v="SJC"/>
   < tag k="submarine" v="yes"/>
   < tag k="telecom:medium" v="fibre"/>
   < tag k="wikidata" v="Q7390539"/>
   < /way>

2025.2.14 記録開始

リファレンス