ラインやポリゴンのデータもストリーム処理でベクトルタイルに変換する。Rubyで。
ラインやポリゴンのデータもストリーム処理でベクトルタイルに変換するプログラムを作成したので共有する。Rubyでgeoruby-ext（特にRGeo経由でGEOS）を使う。
使い方
$ ruby convert.rb [theme] [z] [shapefiles...]
- theme は、{z}/{x}/{y}.geojson が置かれるフォルダ名を想定している。例えば std という文字列を与えると、ベクトルタイルは std/{z}/{x}/{y}.geojson というフォルダに置かれることになる。
- z は、ズームレベルを指定する。例えば 14 を指定する。
- shapefile は、データソースとなる Shapefile を指定する。複数のShapefileを指定すると、立て続けに map して、まとめて reduce する。結果的にデータがひとつのタイルセットにコンポジットされる。Shapefileの文字コードはShift_JISになっていることを前提としており、処理の中で UTF-8 に変換されて出力される*1。なお、出力されるベクトルタイルには UTF-8 文字列がそのままに書きだされるようにしてあり、Unicodeエスケープはされない。
convert.rbは本エントリでこれから紹介する。これまで、ストリーム処理でMapReduce的にベクトルタイル変換する方法を実現するために、map.rbとreduce.rbを別々に作成してきたが、今回は小手先の工夫を加えて、一つのスクリプトでmapとreduceの両方が処理されるようにした。また、UNIXパイプを作って sort や reduce.rb につなぐ部分も、すべて convert.rb の中におさめてしまっている。結果として、上記のようなコマンドラインで処理できるようにした。
コマンドラインパラメータが適切でないときの処理は、現在のところほとんどまともでない。
利用例は、例えば次の通りである。
$ ruby convert.rb bus_stop 14 bus_stop.shp
ソースコード
上記の convert.rb のソースコードはこの節で示す通りである。georuby-ext が導入されていることが前提になるので、必要に応じて、
$ gem install georuby-ext
する。それ以外には特段、特別なライブラリーは必要としない。（georuby-ext が RGeo に依存し、RGeo が GEOS（GEOS = Geometry Engine, Open Source）に依存するので、結果的に GEOS が導入される。）あと、内部で sort コマンドを呼ぶので、UNIX で普通に存在するような sort が存在しない環境では動かないかもしれない。なお、将来、タイル化に並列分散処理を導入する場合には、sort コマンドのかわりに MapReduce 処理系（Hadoop等）を入れることになるのではないだろうか。
# coding: utf-8 require 'georuby-ext' # gem install georuby-ext require 'geo_ruby/shp' require 'fileutils' require 'json' include GeoRuby::Shp4r module Math def self.sec(x) 1.0 / cos(x) end end module XYZ def self.pt2xy(pt, z) lnglat2xy(pt.x, pt.y, z) end def self.lnglat2xy(lng, lat, z) n = 2 ** z rad = lat * 2 * Math::PI / 360 [n * ((lng + 180) / 360), n * (1 - (Math::log(Math::tan(rad) + Math::sec(rad)) / Math::PI)) / 2] end def self.xyz2lnglat(x, y, z) n = 2 ** z rad = Math::atan(Math.sinh(Math::PI * (1 - 2.0 * y / n))) [360.0 * x / n - 180.0, rad * 180.0 / Math::PI] end def self.xyz2envelope(x, y, z) GeoRuby::SimpleFeatures::Envelope.from_points([ GeoRuby::SimpleFeatures::Point.from_coordinates( xyz2lnglat(x, y, z)), GeoRuby::SimpleFeatures::Point.from_coordinates( xyz2lnglat(x + 1, y + 1, z))]) end end class GeoRuby::SimpleFeatures::Geometry def tile(z) lower = XYZ::pt2xy(self.bounding_box[0], z) upper = XYZ::pt2xy(self.bounding_box[1], z) rg = self.to_rgeo lower[0].truncate.upto(upper[0].truncate) {|x| upper[1].truncate.upto(lower[1].truncate) {|y| env = XYZ::xyz2envelope(x, y, z).to_rgeo intersection = rg.intersection(env) if intersection.is_empty? $stderr.print "e" next end if intersection.respond_to?(:each) intersection.each {|g| $stderr.print "m" yield x, y, JSON.parse(g.to_georuby.as_geojson) } else $stderr.print "s" yield x, y, JSON.parse(intersection.to_georuby.as_geojson) end } } end end def write(geojson, tzxy) path = tzxy.join('/') + '.geojson' print "writing #{geojson[:features].size} features to #{path}\n" [File.dirname(path)].each {|d| FileUtils.mkdir_p(d) unless File.exist?(d)} File.open(path, 'w') {|w| w.print(JSON.dump(geojson))} end def map(t, z, paths) IO.popen("sort | ruby #{__FILE__}", 'w') {|io| fid = 0 paths.each {|path| ShpFile.open(path) {|shp| shp.each{|r| fid += 1 prop = r.data.attributes prop[:fid] = fid $stderr.print "[#{fid}]" prop.each {|k, v| if(v.class == String) prop[k] = v.encode('UTF-8', 'CP932') end } r.geometry.tile(z) {|x, y, g| f = {:type => 'Feature', :geometry => g, :properties => prop} io.puts([t, z, x, y, JSON.dump(f)].join("\t") + "\n") } } } } $stderr.print "\n" } end def reduce last = nil # to extend the scope of the variable geojson = nil # to extend the scope of the variable while gets r = $_.strip.split("\t") current = r[0..3] if current != last write(geojson, last) unless last.nil? geojson = {:type => 'FeatureCollection', :features => []} end geojson[:features] << JSON.parse(r[4]) last = current end write(geojson, last) end def help print <<-EOS ruby convert.rb {theme} {z} {shapefiles...} EOS end if __FILE__ == $0 if ARGV.size == 0 reduce else begin # ruby convert.rb test 10 /Users/hfu/Downloads/A13-11_42_GML/a001420020120310.shp map(ARGV[0], ARGV[1].to_i, ARGV[2..-1]) rescue p $! help end end end
上記とまったく同じものを、gistにも置いておく。
確認用 HTML ファイル
今回のツールで、[theme] を test に設定*2して作成したベクトルタイルを確認するためのHTMLファイル index.html のサンプルを共有する。
<!doctype html> <html> <head> <meta charset="UTF-8"> <title></title> <link rel="stylesheet" href="http://cdn.leafletjs.com/leaflet-0.7.2/leaflet.css"/> <script src="http://cdn.leafletjs.com/leaflet-0.7.2/leaflet.js"></script> <script src="http://handygeospatial.github.io/mapsites/js/leaflet-hash.js"></script> <script src="http://handygeospatial.github.io/mapsites/js/TileLayer.GeoJSON.js"></script> <style> body {padding: 0; margin: 0} html, body, #mapdiv {height: 100%; width: 100%;} .leaflet-container {background: #fff;} </style> </head> <body> <div id="mapdiv"> <script> var std = L.tileLayer( 'http://cyberjapandata.gsi.go.jp/xyz/std/{z}/{x}/{y}.png', {attribution: "地理院タイル（標準地図）" }); var vec = new L.TileLayer.GeoJSON( './test/{z}/{x}/{y}.geojson', {attribution: 'vector tile', minZoom: 7, maxZoom: 18, unique: function(feat) {return feat.properties['fid']}}, {style: {"clickable": true, "stroke": false, "fillColor": "#3f3"}, onEachFeature: function(feature, layer) { layer.bindPopup(JSON.stringify(feature.properties)); }}); var map = L.map('mapdiv', { center: [32.9263, 130.0378], zoom: 12, layers: [std, vec]}); var hash = L.hash(map); L.control.layers({'地理院タイル（標準地図）': std}, {'vector tile': vec}).addTo(map); </script> </body> </html>
これを、データを作った場所と同じフォルダにおいて、例えば python の SimpleHTTPServer を用いてサーブしてブラウザで確認すれば良い。
$ python -m SimpleHTTPServer
通常 http://localhost:8000/ で表示されることになる。なお、ベクトルタイルデータすべてについてそうであるが、ベクトルタイルデータは CORS（cross-origin resource sharing）されるか又は同一オリジンから参照されることが必要なので、file: スキームでは通常表示されないことから、SimpleHTTPServer を使う必要がある。
検証状況
色塗り系ポリゴンファイルを変換してみて、上記の確認用HTMLを用い、問題ない位置に表示されることを確認している。ループの外に出せる to_rgeo 呼び出しを適切にループの外に置くことにより、ナイーブな実装にくらべてそれなりの高速化を実現したりしている。
所感
やや未熟なところはあるが、読んでくださる方が読んでくだされば、基本的なアイディアはすべて伝わると考える。
この先は、ocra など使って「普通のパソコン」でも使って頂ける形を追求する線と、速度を求めて並列分散処理を追求する線に分化する必要が出てくる。但し、それより前に、処理速度の相場観を得るためにある程度の実戦経験を積む段階が必要になる。
ICUのRuby実装twitter-cldr-rbの動作確認をする
i18n 界隈では、昔から ICU - International Components for Unicode が知られている。最近、このRuby実装である twitter/twitter-cldr-rb · GitHub を知ったので、このGithubページのREADMEにある Usage をなぞるだけであるが手元の OS X で動作確認してみた。
導入
$ gem install twitter_cldr Fetching: camertron-eprun-1.1.0.gem (100%) Successfully installed camertron-eprun-1.1.0 Fetching: twitter_cldr-3.0.3.gem (100%) Successfully installed twitter_cldr-3.0.3 Parsing documentation for camertron-eprun-1.1.0 Installing ri documentation for camertron-eprun-1.1.0 Parsing documentation for twitter_cldr-3.0.3 Installing ri documentation for twitter_cldr-3.0.3 Done installing documentation for camertron-eprun, twitter_cldr after 8 seconds 2 gems installed
動作確認
irb を使って次のように確認を進めた。
irb(main):001:0> require 'twitter_cldr' => true
問題なく導入されている。
irb(main):002:0> TwitterCldr.supported_locales => [:af, :ar, :be, :bg, :bn, :ca, :cs, :cy, :da, :de, :el, :en, :"en-GB", :es, :eu, :fa, :fi, :fil, :fr, :ga, :gl, :he, :hi, :hr, :hu, :id, :is, :it, :ja, :ko, :lv, :ms, :nb, :nl, :pl, :pt, :ro, :ru, :sk, :sq, :sr, :sv, :ta, :th, :tr, :uk, :ur, :vi, :zh, :"zh-Hant"]
サポートされているロケール。:ja も問題なく含まれている。
irb(main):003:0> 2014.localize(:ja).to_s => "2,014"
日本の三桁区切りの入れ方。カンマを使う。
irb(main):004:0> 2014.localize(:de).to_s => "2.014"
ドイツの三桁区切りの入れ方。ピリオドを使う。国際規格ではこちらの流儀に合わせると聞いたことがある。
irb(main):005:0> 500.localize(:ja).to_currency.to_s(:currency => 'EUR') => "€500.00"
500を日本語にローカライズして、ユーロ表示で通貨として文字列化した、ということだと思う。
irb(main):006:0> 500.localize(:ja).to_currency.to_s(:currency => 'eur') => "eur500.00" irb(main):007:0> 500.localize(:ja).to_currency.to_s(:currency => 'JPY') => "¥500"
eurが小文字だと、ユーロとは認識されない。JPYは日本円。
irb(main):008:0> TwitterCldr::Shared::Currencies.currency_codes => ["ADP", "AED", "AFA", "AFN", "ALK", "ALL", "AMD", "ANG", "AOA", "AOK", "AON", "AOR", "ARA", "ARL", "ARM", "ARP", "ARS", "ATS", "AUD", "AWG", "AZM", "AZN", "BAD", "BAM", "BAN", "BBD", "BDT", "BEC", "BEF", "BEL", "BGL", "BGM", "BGN", "BGO", "BHD", "BIF", "BMD", "BND", "BOB", "BOL", "BOP", "BOV", "BRB", "BRC", "BRE", "BRL", "BRN", "BRR", "BRZ", "BSD", "BTN", "BUK", "BWP", "BYB", "BYR", "BZD", "CAD", "CDF", "CHE", "CHF", "CHW", "CLE", "CLF", "CLP", "CNX", "CNY", "COP", "COU", "CRC", "CSD", "CSK", "CUC", "CUP", "CVE", "CYP", "CZK", "DDM", "DEM", "DJF", "DKK", "DOP", "DZD", "ECS", "ECV", "EEK", "EGP", "ERN", "ESA", "ESB", "ESP", "ETB", "EUR", "FIM", "FJD", "FKP", "FRF", "GBP", "GEK", "GEL", "GHC", "GHS", "GIP", "GMD", "GNF", "GNS", "GQE", "GRD", "GTQ", "GWE", "GWP", "GYD", "HKD", "HNL", "HRD", "HRK", "HTG", "HUF", "IDR", "IEP", "ILP", "ILR", "ILS", "INR", "IQD", "IRR", "ISJ", "ISK", "ITL", "JMD", "JOD", "JPY", "KES", "KGS", "KHR", "KMF", "KPW", "KRH", "KRO", "KRW", "KWD", "KYD", "KZT", "LAK", "LBP", "LKR", "LRD", "LSL", "LTL", "LTT", "LUC", "LUF", "LUL", "LVL", "LVR", "LYD", "MAD", "MAF", "MCF", "MDC", "MDL", "MGA", "MGF", "MKD", "MKN", "MLF", "MMK", "MNT", "MOP", "MRO", "MTL", "MTP", "MUR", "MVP", "MVR", "MWK", "MXN", "MXP", "MXV", "MYR", "MZE", "MZM", "MZN", "NAD", "NGN", "NIC", "NIO", "NLG", "NOK", "NPR", "NZD", "OMR", "PAB", "PEI", "PEN", "PES", "PGK", "PHP", "PKR", "PLN", "PLZ", "PTE", "PYG", "QAR", "RHD", "ROL", "RON", "RSD", "RUB", "RUR", "RWF", "SAR", "SBD", "SCR", "SDD", "SDG", "SDP", "SEK", "SGD", "SHP", "SIT", "SKK", "SLL", "SOS", "SRD", "SRG", "SSP", "STD", "SUR", "SVC", "SYP", "SZL", "THB", "TJR", "TJS", "TMM", "TMT", "TND", "TOP", "TPE", "TRL", "TRY", "TTD", "TWD", "TZS", "UAH", "UAK", "UGS", "UGX", "USD", "USN", "USS", "UYI", "UYP", "UYU", "UZS", "VEB", "VEF", "VND", "VNN", "VUV", "WST", "XAF", "XAG", "XAU", "XBA", "XBB", "XBC", "XBD", "XCD", "XDR", "XEU", "XFO", "XFU", "XOF", "XPD", "XPF", "XPT", "XRE", "XSU", "XTS", "XUA", "XXX", "YDD", "YER", "YUD", "YUM", "YUN", "YUR", "ZAL", "ZAR", "ZMK", "ZMW", "ZRN", "ZRZ", "ZWD", "ZWL", "ZWR"]
通貨コードの一覧。
irb(main):009:0> 1999.localize.to_short_decimal.to_s => "2K" irb(main):010:0> 1999.localize.to_long_decimal.to_s => "2 thousand"
数字を上記のように書く。
irb(main):011:0> 1999.localize(:ja).to_long_decimal.to_s => "2千" irb(main):012:0> 1999.localize(:ja).to_short_decimal.to_s => "2千"
日本語の場合、short_decimal も long_decimal も同じ。
irb(main):013:0> 1999.localize(:ja).spellout => "千九百九十九"
スペルアウト。
irb(main):014:0> 1999.localize(:ja).rbnf.group_names => ["SpelloutRules", "OrdinalRules"]
ルール一覧。
irb(main):015:0> 1999.localize(:ja).to_rbnf_s('SpelloutRules', 'spellout-ordinal') => "第千九百九十九"
序数。
irb(main):016:0> 1999.localize(:ja).to_rbnf_s('OrdinalRules', 'digits-ordinal') => "第1999"
数値をそのまま残すバージョンの序数。
irb(main):017:0> require 'time' => false irb(main):018:0> DateTime.now.localize(:ja).to_full_s => "2014年6月4日水曜日 5時13分00秒 UTC +00:00"
日付。time は twitter_cldr に依存してかロードされていたらしい。
irb(main):019:0> (DateTime.now + 0.5).localize(:ja).until.to_s => "12時間後"
相対時間。
irb(main):020:0> ['山', '川', '海'].localize(:ja).to_sentence => "山、川、海"
列挙。"山、川及び海" にはならない。
irb(main):021:0> TwitterCldr::Formatters::Plurals::Rules.all_for(:ja) => [:other]
複数形のルール。
irb(main):022:0> :ja.localize(:ja).as_language_code => "日本語" irb(main):023:0> :ja.localize(:de).as_language_code => "Japanisch"
言語。
irb(main):024:0> TwitterCldr::Shared::PostalCodes.for_territory(:de).valid?(30159) TypeError: no implicit conversion of Fixnum into String from /usr/local/Cellar/ruby/2.1.1_1/lib/ruby/gems/2.1.0/gems/twitter_cldr-3.0.3/lib/twitter_cldr/shared/postal_codes.rb:55:in `=~' from /usr/local/Cellar/ruby/2.1.1_1/lib/ruby/gems/2.1.0/gems/twitter_cldr-3.0.3/lib/twitter_cldr/shared/postal_codes.rb:55:in `valid?' from (irb):24 from /usr/local/bin/irb:11:in `<main>' irb(main):025:0> TwitterCldr::Shared::PostalCodes.for_territory(:de).valid?("30159") => true
郵便番号。valid? の引数は、数値ではなくて文字列でなければならない。
irb(main):026:0> TwitterCldr::Shared::PhoneCodes.territories.include?(:ja) => false irb(main):027:0> TwitterCldr::Shared::PhoneCodes.territories => [:ac, :ad, :ae, :af, :ag, :ai, :al, :am, :an, :ao, :aq, :ar, :as, :at, :au, :aw, :ax, :az, :ba, :bb, :bd, :be, :bf, :bg, :bh, :bi, :bj, :bl, :bm, :bn, :bo, :br, :bs, :bt, :bw, :by, :bz, :ca, :cc, :cd, :cf, :cg, :ch, :ci, :ck, :cl, :cm, :cn, :co, :cr, :cu, :cv, :cx, :cy, :cz, :de, :dj, :dk, :dm, :do, :dz, :ec, :ee, :eg, :er, :es, :et, :fi, :fj, :fk, :fm, :fo, :fr, :ga, :gb, :gd, :ge, :gf, :gg, :gh, :gi, :gl, :gm, :gn, :gp, :gq, :gr, :gt, :gu, :gw, :gy, :hk, :hn, :hr, :ht, :hu, :id, :ie, :il, :im, :in, :io, :iq, :ir, :is, :it, :je, :jm, :jo, :jp, :ke, :kg, :kh, :ki, :km, :kn, :kp, :kr, :kw, :ky, :kz, :la, :lb, :lc, :li, :lk, :lr, :ls, :lt, :lu, :lv, :ly, :ma, :mc, :md, :me, :mg, :mh, :mk, :ml, :mm, :mn, :mo, :mp, :mq, :mr, :ms, :mt, :mu, :mv, :mw, :mx, :my, :mz, :na, :nc, :ne, :nf, :ng, :ni, :nl, :no, :np, :nr, :nu, :nz, :om, :pa, :pe, :pf, :pg, :ph, :pk, :pl, :pm, :pr, :ps, :pt, :pw, :py, :qa, :re, :ro, :rs, :ru, :rw, :sa, :sb, :sc, :sd, :se, :sg, :sh, :si, :sj, :sk, :sl, :sm, :sn, :so, :sr, :ss, :st, :sv, :sy, :sz, :tc, :td, :tf, :tg, :th, :tj, :tk, :tl, :tm, :tn, :to, :tr, :tt, :tv, :tw, :tz, :ua, :ug, :us, :uy, :uz, :va, :vc, :ve, :vg, :vi, :vn, :vu, :wf, :ws, :ye, :yt, :za, :zm, :zw] irb(main):028:0> TwitterCldr::Shared::PhoneCodes.territories.include?(:jp) => true
電話番号。電話番号は言語ではなくて国に対応するものなので、国コードで指定しなければならなかった。
irb(main):029:0> TwitterCldr::Utils::CodePoints.from_string("😁") => [128513]
Unicode コードポイント。
irb(main):030:0> ['いしば', 'いしはら'].sort => ["いしはら", "いしば"] irb(main):031:0> ['いしば', 'いしはら'].localize(:ja).sort => #<TwitterCldr::Localized::LocalizedArray:0x007f9247280ec0 @base_obj=["いしば", "いしはら"], @locale=:en> irb(main):032:0> ['いしば', 'いしはら'].localize(:ja).sort.to_a => ["いしば", "いしはら"]
ソート。いしばいしはら課題 - Relevant, Timely, and Accurate も参考。
時間制約もあり無愛想になってしまったが、とりあえず以上。
ツールとしてのいくつかのことばの定義
思考のツールとして、いくつかの言葉をかりそめに定義しておく。
オンラインデータ
使用可能な形でオンラインアクセス可能になっているデータを指す。伝統的に、インターネット提供されるデータは、直接使用することは不可能なアーカイブ形式で配布されることが多かった。この場合、まずデータを特定し、ダウンロードし、展開し、デスクトップGISソフトウェアで開いて、必要に応じてスタイルを設定し、設定を保存し、初めて使用可能となる。
オンラインデータの場合には、オンラインでアクセスできるリソースそのものがウェブブラウザなどで解釈可能となっているため、上記のようなステップを多数省略することができる。その裏返しとして、処理をしながらデータを取り込む必要があるため、処理の特性に応じて十分にパフォーマンスを発揮できるようなデータの分割方法等の工夫が必要である。最も知られており最も実績がある工夫の一つが「タイル」（後述）である。
オンラインデータの副次的効果としては、「ダウンロード」、「複製」、「二次利用」といった概念を相対化しうる余地があるというところがある。通常の使用において、ダウンロードや複製といった具体的な操作は、クラウドサービスでファイルシステムが隠蔽されるのと同じような意味で隠蔽される。また、一次的なデータ取得と二次利用がブラウザ内で一体として実施されるのが通常の使用になる。
ウェブネイティブ
ウェブ（ウェブブラウザ）での使用を本位とする、ということである。ウェブネイティブは、データ設計にもソフトウェア設計にもひとつの指標となる。例えば、XMLにおいては文字コードは文書内に記述するが、ウェブネイティブに発想するのであれば、HTTPリクエストヘッダ及びHTTPレスポンスヘッダで表現すべきである。表示のスタイルは、SVGのCSS（≒CartoCSS）を用いるのがウェブネイティブであろう。ウェブネイティブの考え方を持ち込むことにより、スコープの絞れた仕様の検討が可能である。ウェブ環境の現状は、ウェブネイティブが必要でありかつ可能であるという絶妙な状況にある。
ウェブデータ
ウェブネイティブなオンラインデータ。「オンラインデータ」及び「ウェブネイティブ」は、私の頭の中でかなり重要なコンセプトになっているが、かりそめにこれらのコンセプトを組み合わせた場合、ウェブデータと言えるのではないかと思う。ウェブデータ的な地理空間情報は、典型的なジオ応用以外にも抵抗なく使われる、データのインフラストラクチャのようなものを構成しなければならない。
【開始】georuby-ext を通じた RGeo ベースのジオメトリ処理
最近久しぶりにジオメトリ処理の引き合いを頂きまして、定例なのですが今 Ruby でジオメトリ処理をするための方法の確認を開始しました。
使用するライブラリ
Shapefile等データの取り扱いには、これまでよくGeoRubyを使っていましたので、GeoRubyと連結の良い、georuby-extを使うことにしました。GeoRubyはこれまで通り、非互換な拡張が続いているようであり、また日本語ファイル名を処理している場合に特異かもしれませんが、古めのRubyでは上手く動かない場合があるようです。ここでは新しめのRuby（2.1以降）で、次のようにして GeoRuby 及び georuby-ext を導入することを前提としています。
$ gem install georuby-ext
GeoRubyにはいくつか分派があるようなのですが、あえていきなり georuby-ext を指示して導入することにより、それが依存する GeoRuby を導入することになります。そのようにするのが確実だと思います。
georuby-ext は、手元のOS Xだと問題なく導入できています。内部でGEOSを呼んだりするので、依存ライブラリの問題でWindows等ではそれなりに苦労するかもしれません。
RGeo
GEOSが行うようなジオメトリ処理は、RGeoが実施します。
https://github.com/rgeo/rgeo/blob/master/Spatial_Programming_With_RGeo.md
RGeoでジオメトリ処理を開始
基本的に、上にリンクを掲げたドキュメントのとおりですが、基本的な流れは次のとおりです。
$ irb irb(main):001:0> require 'georuby-ext' => true irb(main):002:0> factory = RGeo::Geographic::simple_mercator_factory => #<RGeo::Geographic::Factory:0x007fc9729a2138 （中略） irb(main):003:0> g = factory.point(135, 35) => #<RGeo::Geographic::ProjectedPointImpl:0x3fe4b94b4d48 "POINT (135.0 35.0)"> irb(main):004:0> g.buffer(1) => #<RGeo::Geographic::ProjectedPolygonImpl:0x3fe4b94ac170 "POLYGON ((135.00000898315284 35.000000000000014, 135.0 34.99999264143168, 134.99999101684716 35.000000000000014, 135.0 35.00000735856771, 135.00000898315284 35.000000000000014))"> irb(main):005:0> g.lon => 135.0
MapReduce的ベクトルタイル作成のマルチスケール処理方法
map.rb、sort、reduce.rb を使った「MapReduce的ベクトルタイル作成」ですが、次のようにすると、少なくともポイントデータについては問題なく、マルチスケールのベクトルタイルを高速に作成できそうですね。
- 作成する最大のズームレベルにおいて、z/x/y に各レコードを map
- sort してからタイルファイル（z/x/y）に reduce。これで MapReduce 的処理は終わり。
- 更に、ズームレベル z のデータからズームレベル z - 1 のデータを作成。具体的には、z/x/yのデータを、{z-1}/{(x / 2).floor}/{(y / 2).floor} に縮約。
- 必要なだけ z をデクリメントして上記と同じ処理。
- 縮約タイルを作成する際に、レコード数を記録しただけのタイルを作っておけば、概要タイルも簡単に作成できる。又は、レコード数タイルは飛ばしていきなり概要タイルを作ってもよい。
dejimaはオープンリダイレクタ？
オンラインデータのクロスオリジンプロキシdejimaの作成 - 世界の測量で作成した http://dejima.herokuapp.com/ は、よくは分かりませんがOAuth問題で言われているオープンリダイレクタのようですね。
OAuth 2.0 の脆弱性 (!?) "Covert Redirect" とは - OAuth.jp
Rebuild: 43: Kent is More Professional (Kenn Ejima)
dejimaを利用したGeoJSONファイルのクロスドメイン読み込み
先ほど作成したdejimaプロキシを用いてleaflet-omnivoreからクロスドメインでGeoJSONファイルを読み込むサンプルを作成した。
ソース
<!doctype html> <html> <head> <meta charset='UTF-8'> <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"> <meta name="apple-mobile-web-app-capable" content="yes"/> <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" /> <title>leaflet-omnivore</title> <link rel='stylesheet' href='leaflet-0.8-dev.css'> <script src='leaflet-0.8-dev.js'></script> <script src='leaflet-hash.js'></script> <script src='leaflet-omnivore.min.js'></script> <style> html, body, #mapdiv {margin: 0; padding: 0; width: 100%; height: 100%;} div.leaflet-container {background: #fff;} </style> </head> <body> <div id='mapdiv'/> <script> map = new L.Map('mapdiv', {zoom: 12, center: [36.0571, 136.2305]}); hash = new L.Hash(map); icon = L.icon({ iconUrl: 'https://raw.githubusercontent.com/handygeospatial/cobmaki/' + 'master/dst/C01_03_sannkakutenn_tikakuhenndoukannsokutenn_18_shadow.png', iconSize: [18, 18]}); map.addLayer(new L.TileLayer( 'http://cyberjapandata.gsi.go.jp/xyz/std/{z}/{x}/{y}.png', {attribution: '地理院タイル'})); omnivore.geojson( 'http://dejima.herokuapp.com/?url=' + 'https://raw.githubusercontent.com/shimizu/dataSet/master/fukui_kindergarten/fukui_kindergarten.geojson', {}, L.geoJson(null, { pointToLayer: function(feature, latlng) { return L.marker(latlng, {icon: icon}); }, onEachFeature: function(feature, layer) { layer.bindPopup(feature.properties['保育園名']); } }) ).addTo(map); // the original csv file is from a CC BY SA work at: // https://github.com/shimizu/dataSet/tree/master/fukui_kindergarten </script> </body> </html>
