[OSM-ja] [import 依頼] 香川-岡山県境のインポートをお願いします。

2011-08-03 Per discussione show_ichi

Show-ichi です。

前々から気になっていたのですが、どなたか香川-岡山県境をインポートしていただけませんでしょうか。
当然陸上部分のみで、県境未確定部分は無しの方向で。

ついでに可能であれば、愛媛−広島県境のほうもお願いしたく……

-- Show-ichi

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-ja] Bing で作図する場合の source タグについて.

2011-02-15 Per discussione show_ichi
Show-ichi です。

日本語の議論として、明確なものは記憶にありません。

英語版をざっと見た感じ、source の付与については、考え方が二通りあるようで、
それぞれを仮に網羅方式と包含方式とでもしておきましょう。

網羅方式は単純で、すべてのエレメントにsourceタグをつけることです。
利点はいうまでもなく、ユーザーにとってソースの確認がワンパスで可能なこと。
欠点はこれまたいうまでもなく、作成者の手間です。

包含主義は、対象となるエレメントをすべて子として有する親要素に代表として付加する
方法です。長短は上記の逆で、作成者の手間は最低限、ユーザーの手間は多大です。

nodeのソースを同時に作成した親要素のwayのみに記述するやり方は包含方式ですが、
欠点があります。大きなものとして、同時に作成したnodeを残したまま、wayを削除可能
である点が挙げられます。これにより、nodeのソース参照は不可能ではないにしろかなり
面倒になります。

そこで、包含方式をとる場合、一度確定したら削除も修正も受け付けない changeset に
sourceを記述することが推奨されているようです。
当然、uploadする際には、複数のソースからなる要素が混ざらないようにする必要があり
ますが、網羅することに比べればさほどの手間ではありません。

何か誤解があれば、指摘願います。

TANAKA Toshihisa さんは書きました:
としです.

Bing で作図する場合の source タグについて教えてください.

http://wiki.openstreetmap.org/wiki/JA:Bing

を見ると,

source=Bing タグを使ってください。

とありますので,source=Bing を入れるとして,それは way だけで良いのでしょうか?
node には source=Bing タグは不要と言う認識で良いでしょうか?

私は過去に,オルソ化空中画像で古墳を作図していた時,全 node に source タグを入れました.
全 node に source タグを入れるのは,データ上過剰かもしれないと思いましたが,

1) OSM のデータ構造として,「way は複数の node で構成される」仕様であること.
2) 空中写真をなぞると言うことは,
a) node を打ち
b) way を作る.
と言う事で,JOSM もメルカトルも,道を作成する場合は上記 a)/b) を自動的に作るだけで,
way だから node が無いと言うわけではない.

上記の理由から,全 node に source タグを入れることにしたのですが,
Bing は way のみで良いでしょうか?

もし,この辺既に議論済みでしたらすみません.

ではこれにて.

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-ja] 車両進入制限のあるアーケード街

2011-02-14 Per discussione show_ichi
Show-ichi です。

S.Higashi さんは書きました:
今回の場所は普通のunclassifiedサイズなのでご指摘の通り道路を一本にして
以下のようにタグ付けしようと思います。

unclassified は“Unclassified roads typically form the lowest form of the 
interconnecting grid network.  と説明されているように、交通ネットワークの
一部という性格を有している道路ですが、アーケード街は通常時は交通の用を担い
ませんから、unclassified は不適切だと思いますし、pedestrian であることを
明確に示した方がユーザーに親切です。

タグ付けは以下でいいとおもいます。
highway=pedestrian
covered=yes
vehicle=permissive
hour_on=10:00:00
hour_off=22:00:00

アクセス制限は highway=pedestrian 自体が内包していますので、省略
可能だと思います。

pedestrianが広くなってエリアになってくると(駅前広場のようなところ)、
エリアとは別に人の通る経路をfootwayで表現したら良いんですかね。

これは ikiya さんに教えてもらったのですが、route=foot が良いようです。
駅構内といった建物内の通路も、これで記述してます。


___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-ja] 車両進入制限のあるアーケード街

2011-02-13 Per discussione show_ichi
Show-ichi です。

S.Higashi さんは書きました:
<アーケード>
http://www.openstreetmap.org/browse/way/99270198
highway=pedestrian
area=yes
covered=yes

covered=yes は「何かに上空を覆われている物」を表すタグですから、「覆っている」アーケードに
付すのではなく、「覆われている」道路の方に付します。

--Show-ichi

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-ja] 車両進入制限のあるアーケード街

2011-02-13 Per discussione show_ichi
Show-ichiです。

不注意で「<アーケード>」が、建物としてのアーケードを表している物と勘違いしてました。

その上で補足です。エリア上の highway=pedestrian の範囲内に ウェイの highway=unclassfied を
記述するのは筋が悪いです。両者は物理的に同じ道路ですから、二重表現に相当すると考えます。
covered=yesを「道路」側に移し、「<アーケード>」を建物として表現するか。削除すべきでしょう。
そもそも pedestrian は「アーケード街」のような、車が通行可能なように設計されているけれど
商業・観光的要請から車両進入禁止にしている道路を、footway と区別するために導入されたと
理解していますが。

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-ja] 橋梁の竣工年はどんな Tag をつければよいのでしょう?

2010-11-11 Per discussione show_ichi
ikiya さんは書きました:
ikiyaです。

回答ありがとうございます。
そうですね。竣工、建造年は容易に分かるのですが共用開始年は
なかなか分かりません。
竣工、建造年に見合う良いTagはあったらお願いします。
Key:start_dateは使わずnoteか何かで書いておきます。

エディタだけが判ればいいなら勝手なでっち上げですが

bridge:start_date=

という書き方もありかなと……

#本格的に使うなら proposal として提出すべきだろうけれど

現状でユーザー側にも示すおつもりなら description 一択でしょうが。

#highway に付ける name に橋の名前を書くのは
#構成上誤りなのではないかという気がしてきた……

-- Show-ichi

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-ja] 日本の都道府県道一覧( y asu747 さん作成)

2010-08-16 Per discussione show_ichi
こんにちは Show-ichi です。

kondoh yasunori さんは書きました:
あと、知ってる方、教えて欲しいのですが、リレーション使って県道を表現して
るような箇所ってあるのでしょうか。具体例があれば対応したいと思っています。
(自転車道県道の場合・県道が自動車専用道の場合・県道が国道を重用している
場合となにかしら個別に対応してそうな感じはするのですが・・・)

私が主に編集している四国の東部域では、基本的に全ての国道・県道へリレーションを付加しています。
あと、ごく短いway(橋やトンネルとか) や dual carrigeway の片一方など、ref を付けていないway
があります。また、県道でも有料道路の場合は、当然 expressway で記述しています。
また複数県にまたがる県道は、当然ながら一つのリレーションで管理しています。
リレーションにはnetworkタグなど(県道ならnetwork=JPRとか)付せば便利なのでしょうが、何もしてません。

-- Show-ichi

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


[OSM-ja] Fwd: データベース更新作 業のおしらせ

2010-06-26 Per discussione show_ichi
データベース更新作業の事前通知を翻訳・転送します。
-
OpenStreetMap,

翻訳して各地域のリストにコピーしてください。
2010年7月の2日(金曜)および第3(土曜)に、sysadminチームがデータベース・サーバの記憶装置のアップグレードを予定しています。
この期間、編集はできません。

当初の計画、修正の対象:
7月1日21:00(GMT)(日本時間2日06時) - APIおよびウェブサイトのリードオンリー化。(編集不可)
7月2日12:00(GMT)(日本時間2日21時) - API利用不可。www.openstreetmap.org 上では地図のブラウジングとエクスポートのみ
が可能。
7月3日午後(GMT)(日本時間3日21時以後)- APIおよびウェブサイトが復旧。(編集可能)

期間中、ウィキの利用は可能です。
追加の情報と進行状況は以下で提供予定です。:
http://wiki.openstreetmap.org/wiki/July_2010_DB_Upgrade

よろしくお願いします。

OpenStreetMap Sysadminチーム

-
ここまで。以下原文。
--
OpenStreetMap,

Please translate and copy to local lists.

On the 2nd (Friday) and 3rd (Saturday) of July 2010 the sysadmin team
will be upgrading the database server's storage.

Editing will not be available during this period.

Initial plan, subject to revision:
 1st July 21:00 (GMT) - API and website read-only. (no edits)
 2nd July 12:00 (GMT) - API unavailable. Only Map browsing and map
export available on www.openstreetmap.org
 3rd July Afternoon (GMT) - API and website return. (edit resumes)

The wiki will remain available for the duration.

Futher information and progress status will be posted here:
http://wiki.openstreetmap.org/wiki/July_2010_DB_Upgrade

Regards
 Grant
 OpenStreetMap Sysadmin Team
--- 

Show-ichi --

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-ja] 複数のソースから構成した エリアについて

2009-11-21 Per discussione show_ichi
Shun N. Watanabe さんは書きました:
なんとなく最初のオルソ写真の source タグを消したいと言うのがやりたいこと
なんでしょうが、無理です。
変更は派生著作物を作った扱いになるので、(それが理由で全遍歴を管理しています)
違うソースで動かしたって消すべきではありません。
その場合、新しくウェイをオルソ写真でないソースから作りなおすべきです。
また、半分だけ調査により作り、オルソ化写真で半分だけつくって、
一つのウェイを作るとそれは共同著作になるので、やっぱりソースは2つです。

いや「任意の時点のデータとソースの一対一対応を明確に記述する必要がある」と考えているだけです。
もともとsource はそのために設けられているはずです。
仮に著作権の問題だとすれば、「別々のソースから2つのwayを作ったんだけど、OSMの仕様から
1つにしなくちゃいけない。それじゃ、共同著作物になっちゃうから、明確に2者の範囲を明示して
それぞれの権利を個別に保持しておきたい」ということもできるでしょう。範囲と著作者が誰にも
わかるように区分して記述してあれば共同著作物にはならないはずです(そうじゃないと
雑誌やアンソロジーの類が成り立たない)。

それに単なるデータ、誰が書いても同じ表現になるもの(緯度経度とか)に対しては著作権は
付与されないですよねえ。node や way は値が正しければ、だれがどのように調べて記述しても、
同じ表現になりますから(特に緯度経度しかデータを持たないnodeならなおさら)。
ライセンスと著作権は別物ですし、ライセンス上求められているものについては、
履歴には全部残っている(つまり、一度書いてしまえばシステム上何をしようが消せず、
ライセンスで求められている記述は残存する)のだから、編集の結果以前のソースを
基にしたデータがすべて消えてしまったら、カレントのsource からはその分は削除すべき
でしょう。ある時点のデータが何を基にして決められたのか曖昧にするのは害悪だと思います。

#ほんとうに著作権について記述しなければならないなら、source じゃなくて copyright タグ
を設けてそちらに書くべきだよねえ。

なにかまだ見当違いなら、これ以上は問題の池を見ないと何とも言えません。
そのときは、way の ID か、座標をください。
北緯34.29度、東経134.20にある野間池です。西側を走る県道141号線の改良により、
オルソ写真が撮影された当時とは池の形が変わっています。

-- Show-ichi

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-ja] 複数のソースから構成した エリアについて

2009-11-20 Per discussione show_ichi
こんにちは、Show-ichiです。

Shun N. Watanabe さんは書きました:
nazotoko の渡邊です。

水面って降水量次第でしょっちゅう変わりますから、
道路が地図上で水に沈んだとか以外はあんまり細かく
描かなくてもいいですよ。

水位などによる一時的な変化は考慮していません。あくまでも埋め立てによる恒久的な変化を
問題にしています。

とりあえず機械じゃなくて、人間がソースが二つあるとわかればOK です。

ひとつの way が複数のソースから構成されたことがわかっても、そのwayの一部を
修正したとき、元のソースから来たデータが残存しているかわからなければ、
意味がないと思うのですが。

--Show-ichi


___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


[OSM-ja] 複数のソースから構成した エリアについて

2009-11-19 Per discussione show_ichi

こんにちは、Show-ichiです。

香川県に引っ越してきて、そこいら辺にあるため池をあたるを幸いオルソ化航空写真を利用しつつ、
アップしているのですが、航空写真は結構古いため輪郭が現状とは異なるものが、いくつかあります。
そこで、ログデータと組み合わせて、描いているのですが、source の書き方に困りました。
ため池は landuse=reservoir なのですが、area として描く以上、way は閉じている必要があります。
つまり、source が異なる部分に分割することができません。
ひとつのタグとして併記するという手段も考えられますが、後の編集の結果、特定の source を使用している
部分が別の source で上書きされてしまった場合それをタグデータからは判断できず source 情報を適切に更新
できないという問題があります。
source 毎に nodes のリストを作ってどこかに書いておくというのは手間とシステム設計の面から論外です。
とりあえずは、水域データということで area に waterway=riverbank を重ねがきし、個々に source を記述して
お茶を濁しています。
適切な relation を定義して、area 用 way と source 記述用 ways をパックしておくのが妥当なところだとは
思うのですが、記述の進んでいる欧米圏では、今まではどうしていたのでしょうか。area は単一のsource を
基にしか描いていないのでしょうか。

-- Show-ichi


___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-ja] 施設はポイントそれともエ リア

2009-11-10 Per discussione show_ichi

こんにちは、Show-ichi です。

OSMデータのカーナビ用最適化を、削除の方向で行うのは賛成できません。
OSM上で月極駐車場を探せないというのもおかしな話です。
要は適切にタグ付けし、カーナビ側もタグを見て適切に峻別すればよいだけでしょう。

S.Higashi さんは書きました:
東です。
すみません、自分で迷っていることもあって駐車場のとこだけ。

 このパブリックという解釈は、ちょっと難しいですねぇ。
 国際会議センターというのはよく分かりますが、映画館というと映画館
 にも来ない人も使っちゃいますよね。スーパーマーケットもそれの傾向
 があると思います。

パブリックおよび制限付きのパブリックって線引きが難しいですね。
思うに利用する人の気持ちの問題じゃないでしょうか ;)

近い将来OSMカーナビで駐車場を探していたとして
たどりつた駐車場で「あなたは停められません」とか
「本当にウチに用があるんですか」とか
いわれるようなところには
駐車場マークを表示しないようにしましょう、
ということではないかと。

 それで海外ではどうかなぁと思って、ちょっと見てみたのですが、以下の
 ようにSafewayというスーパーマーケットの駐車場は、駐車場として表記
 しているみたいです。というわけで、コンビニは駐車場でOK、銀行なども
 そうかなぁと思ったりします。

コンビニで買い物をする場合はいいのですが、目的は近くの公園での花見だった、というような場合に
私、小心者なのでコンビニの駐車場を教えてもらってもちょっと困りそうです。

スーパーマーケットは日本しか知りませんが、置きっぱなしで仕事に行っても
所定の手続き(駐車料金を払うとか)をすれば誰でも駐車できる感覚なので、
パブリックだと感じます。

国際会議センター、展示会場、役所などは、そこに用が無い人は停めちゃいけない気がしますが
広い場所が想定されることもあり、駐車場の案内があって欲しい気持の方が強いです。

ということで、感覚(気持ち)でパブリックな度合いの強い順に並べるとこんな感じです。

場所:駐車場タグ要否

公営の駐車場:○
時間制駐車場:○
スーパーマーケット:○
スポーツ公園の駐車場:○
国際会議センター:○
役所:○
コンビニ:×
銀行:×
病院:×
飲食店:×
月極駐車場:×
個人宅:×
会社:×

なんだか難しいなぁー

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-ja] JOSM などの翻訳

2009-09-24 Per discussione show_ichi
こんにちは、Show-ichiです。

転勤間際で時間がないので少しだけ。

S.Higashi さんは書きました:
東です。

道路の解釈論議の一助にと思い、glossary 形式でまとめてみました。
定義が近いと思われるものは,で区切り、異なると思われるものは|で区切りました。
(素人考えで恐縮ですがgrade1 の解釈以外は大きなズレは無いように感じました)
ご参考まで。

Primary主要地方道,(原則)2桁以下のナンバー
Secondary  一般都道府県道,(原則)3桁以上のナンバー
Tertiary   センターラインのあるもの,県道でないもの
unclassified   舗装林道,舗装されており現在も人が住んでる集落行きの道,あぜ道なのか里道なのかタダのわだちなのか分からな
いけどクルマが通れる圧石路(圧石路もコンクリート以前の古い舗装手段)
footway人しか歩かない雑草の生えた街中のケモノミチみたいなの,車が通れない,街路
path   山とか野原の中,郊外田園地帯
track  草ボーボーな軽トラしか走らない川の脇の道

grade1 整備された市町村道もしくは林道のダート|舗装されてはいるがひどくひび割れていて維持されていないような道
grade2 比較的交通量の多いダートな私道,生活感あふれる道で土だがよく整備されている
grade3 普通乗用車で何とか通れるダート路(わだちがあったりするレベル),ブルトーザー整備もあまりされてないけど使われては
いる道,日本の田んぼの間にある軽トラやトラクターで走る農道のような道
grade4 なかなか整備されず普通乗用車では通行困難な道,四駆じゃないと走れないようなでこぼこ道や拳大くらいの石がゴロゴロし
てたり道の半分が崩れているような冒険的な道
grade5 わだちのタイヤの部分にも草が生えてきてほぼ廃道状態,辛うじてわだちが2つ見える

主要地方道と一般都道府県道をわけるのはいいのですが、グローバルには Tertiary が2車線(片道1車線)固定で、
運用されているように見えるのが懸念材料です。ほとんどのTertiary にはlanes の指定がありませんし、JOSMのプリセットにも
lanes を指定する項目がありません。
また、track のgrade1は舗装されているものに限られてると考えます。日本の場合は、最初は未舗装だったところへ、
コンクリートを流しただけの簡易舗装をした林道などのイメージです。それ以外の完全未舗装はgrade2以下になります。
少なくとも、私はそう運用しています。
footway の「人しか歩かない雑草の生えた街中のケモノミチみたいな」ものは明確にバイクや自転車などの通行が規制されて
いない限りpathだと考えます。footwayは道路の設計者が明確に歩行者のみが通行することを主目的として設置された道路に
限るべきかと。私は街中のビルの谷間の路地のような物理的に4輪車が通行できない狭い道路はpathとして扱っています。

-- Show-ichi

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-ja] 最近すごいところ

2009-06-15 Per discussione show_ichi
こんにちは、Show-ichiです。

SHIBATA Akira さんは書きました:
この辺の誰が入力したとかいう情報ってどうにかすると見られるものでしょうか?

openstreetmap.org で地図を表示させると、右上に“+”のマークがあります。
これをクリックすると、Base Layer の選択ができますが、下のほうに Overlay layer の
選択チェックボックスがあります。
このうち Data のチェックを入れると、表示されている範囲の node と way の情報が
見ることができるんですけど……あんまり知られてない?

範囲が広いと、データ量が多すぎると起こられるので、なるべく大縮尺でどうぞ。

== Show-ichi

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-ja] JOSMの翻訳

2009-05-08 Per discussione show_ichi
こんにちは、Show-ichi です。

highway=trunk
operator=○○県

とかいうのは無しの方向ですか?

== Show-ichi

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-ja] 国道1号線(京橋〜守口/ 滋賀〜亀山)作成しました.

2009-04-09 Per discussione show_ichi
こんにちは としさん。徳島のShow-ichiです。

TANAKA Toshihisa さんは書きました:
ところで,Double carriage way に直接関係無いかも?ですが,もしどなたかご存知,あるいは明確ルール
でしたらご教示頂けるとうれしいのですが,OSM の道路は,

中央分離帯がある道は,二つの道路で引く

というルールかご存知でしょうか?

いちおう、OSM Wikiの Editing Standards and Conventions - Divided highways 
(http://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Divided_highways)
で解説されています。趣旨は物理的な障害物で車線が仕切られている道路は、仕切られている部分ごとに複数の way で描きま
しょう、ということです。たとえ二つの車線が同じ向きでも、仕切られていれば別々に引くべき(should)だ。と書かれています
(must ではありません)。

わたしもこのルールに従って記述しています、というか基本的に分離帯の幅は一定ではないので、別々の一方通行の道路が併走し
ていると見なして引いています。上記のルールにはnordの位置はそろえるように推奨していますが、直線ならともかくカーブで曲
率が異なりきれいに描けない場合はあえてずらします。

ただ自動車専用道(motorway)に関してはこのルールに例外を設けて運用しています。それは暫定的な対向片道一車線区間の場合
で、たとえポールなどで仕切られていて車線の変更ができないようになっていても、一本のway で表わすことにしています。

== Show-ichi

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


[OSM-ja] FirefoxのアドオンでOSM 閲覧

2009-03-25 Per discussione show_ichi
おひさしぶりです。Show-ichiです。

忙しくてOSM的には冬眠中でしたが啓蟄の声と共にぼちぼち活動再開です。

本題のFirefoxなのですが、Mini Map Sidebarというアドオンを見つけました。
地名をDDするとその場所の地図を表示するというしろものなのですが、
Google Map などにあわせて、MapnikとOsmarenderが表示可能です。
2クリックでGoogleの地図や衛星画像とOSMデータとを切り替えられるので
なかなかおもしろいです。

-- Show-ichi

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-ja] 京都&名古屋での活動

2008-07-25 Per discussione show_ichi

こんにちは、Show-ichi です。

ikiyaです。
今年4月にズームレベル9で全国キャプチャしたものがありました。
もっとアップの絵が欲しいですが、とりあえず四国を含む絵は
こんな感じです。(元画像はbmp)使えないかな?

ikiya さん提供の画像には、私の編集はまだありません。この時点での四国に
引かれている国道等は Debeso さんの編集だったはずです。
しかし、やはり思うに、広島で活動されている yamasan は、わたし以上の
編集量ではないでしょうかねえ。

-- Show-ichi

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-ja


Re: [OSM-ja] 京都&名古屋での活動

2008-07-23 Per discussione show_ichi

こんにちは、徳島で活動中の Show-ichi です。

昨日(7/22)メールチェックをサボっている間に、いきなり徳島が話題の中心になっておののかして
もらっております。

たしかに、徳島県内のほぼ全ての道路と県北部の海岸線と河川は、5月から今までに私が手を入れた
か新たに引いたものです。

私は主に,大阪近辺の地図を作っていますが,大阪と徳島は地理上近く,
大阪の地図を編集していてたまたま目に入り,

「うぉぉぉ!,すごいイキオイで(徳島の地図が)出来てる...」

と感じ,OSC 京都でお話させて頂いた次第です.

といっていただくのは、とてもこそば恥ずかしいのですが、ルーキーに対するお褒めの言葉として
ありがたく受け取っておきます。

まあ、外出の機会を無駄にせず、ガソリン代を気にすることなく週末を費やして計画的に効率よく
記録していけば、一人でも2ヶ月半でこのくらいはできますよ、との事例に使っていただければ
幸いです。

西日本では、私以外にも広島で精力的に活動されている方がいるので、

とはいえ、いままでにいろいろと試してみて、一人でできることの限界もひしひしと感じております。
特に徒歩や自転車による調査は、EN版Wikiでも謳われているようにペアによる活動が適切のようです
ねえ。

-- データは増えるが、アップロードする時間がとれない Show-ichi 

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-ja


[OSM-ja] Napnik と [#x30E1;#x30FC;#x30EB;#x30A2;#x30C9;#x30EC;#x30B9;#x4FDD;#x8B77;] の変化

2008-07-17 Per discussione show_ichi
Show-ichi です。

1.Mapnik

国道439号(徳島-大豊間)のデータをアップして、さあ Mapnik のレンダリング結果を見てみようと
昨日(7/16)の夕方にアクセスしたところ、まだ更新されてない。「今回は遅いなあ」ととおもいつつ、
今日(7/17)の朝になってもまだで、ようやく昼頃に更新されたと思ったら、なんと、z15以降の大縮尺
でRelations:Route の name 値がレンダリングされているではありませんか。way の name の
方が優先ですが、それでもついに…という感じ。こうなるとRelations:Route が重複している
部分の表示法を規定できる Template のような機能がほしくなってしまう。

[#x30E1;#x30FC;#x30EB;#x30A2;#x30C9;#x30EC;#x30B9;#x4FDD;#x8B77;]

Wiki の Platform Status(http://wiki.openstreetmap.org/index.php/Platform_Status) 
によると、
7月15日の更新で、これまでは手動更新だった小縮尺(Lowzoom)タイルが2時間ごとに自動的にリクエスト
されるようになった模様。

-- Show-ichi --

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-ja


[OSM-ja] Relations/Route の話

2008-07-07 Per discussione show_ichi
Show-ichi です。

遅くなりましたが、半月ほど前に ikiya さんからリクエストのあった Relation/Route 
について、私が現時点で理解しているところをまとめてみました。

1. Relations とは

Relations は昨年の10月に導入された比較的新しい機能で、node, way, area といった 
OSM のオブジェクトをひとまとめにグループ化することができます。英単語 relation
とは「関係」という意味で、つまり複数のオブジェクトの間に何らかの関係が存在してい
ることを示すためにある機能です(この機能が導入する以前は、name や refを同一のも
のにそろえるなど間接的な手段が用いられてきたようです)。

Relations が示す「関係」の一次的な意味は type タグの値で規定し、導入以来さまざま
な提案がされてきていますが、現時点では multipolygon, restriction, route の3つが
確立されています。

・multipolygon:これは area を対象とする relation で、特定の area に穴を開けるた
めに用いられます。
・restriction:これは Restrictions タブの拡張で、交差点における「右折禁止」や
「直進のみ」など、ひとつの node やway だけでは記述できない交通制限を表し
ます。
・route: これは way を対象とし、基本的にある地点(起点)から別の地点(終点)まで
続く、一聯の経路を表します。

また、特定の relation に含められたオブジェクトには、専用の値(role) を与えること
ができます。multipolygon では 本体の area に outer、穴となる area に inner 
という値を与えることで、それぞれがもつ役割を明らかにしています。
一つのオブジェクトには複数の Relations を指定可能で、role も個別の値を指定するこ
とができます(multipolygon であれば、複数の穴を開けたり、入れ子状に「穴の中に
area があり、さらにその中に穴がある」という状態も表現可能)。
個々の relation は固有のID番号で管理されており、Potlatch や JOSM から確認可能です。

2. Relations/route とは

上記の通り、Relations/Route とは、複数の way から構成される特定の経路を表すため
に用いられます。たとえば、国道や県道、自転車道、自然歩道、バス路線、鉄道路線、営
業路線、巡礼路、マラソンコース、市街地サーキット、ラリーやロードレースのステージ
ルートなど、way の集合で表されるものなら、何でも表現することが可能です。最近 
base layer として導入された Cycle Map はこの Relations/Route を大々的に使用した
アプリケーションです。
個々の way には複数のRelation が指定可能ですから、重複国道や国道を走るバス路線な
ど、他のルートの存在を気にする必要はありません。

3. Relations/Route のタグ

Relations/route で使用するタグには以下のものがあります。 

Key Value   意味
typeroute   relation の一次タグ。route を指定。
route   route としての一次タグ。これでルートとしての意味を規定します。
road国道、高速道路などの道路路線
bicycle 自転車道
foot歩道
bus バス路線
pilgrimage  巡礼路
detour  迂回路
name名前
ref 参照名
network 複数の route が構成するネットワークの名前。
operatorroute の管理者。
state   route の状態
proposed設置が予定されている経路
alternate   代替経路
temporary   正規の経路が使用できない場合などで一時的に設定された経路
connection  複数の route を連結する route (moterway_link などと同様
の意味合い)。
symbol  特定のルートを指し示すシンボルマーク(具体的な使用法は良
くわかりません)
description route 固有の特徴の解説

3-1 規定済みの role

規定済みの role は主にバス路線用です。

Role意味
forward/backwardroute 用の oneway です。往復で異なるroute を使用
する区間を示します。
stop_number   バス停 node に指定します。numberは停車する順番
です。
forward/backward_stop_number  往復で異なるルートを通る、もしくは停車するバス停
が異なる場合に使用します。

表の Recurrence? が何を意味するのかはよくわかりません。

4. Route の編集

4-1. Potlatch

・作成:新しい route に含まれる way を選択し、画面の右下に3つ縦に並んだ円形のア
イコンのうち真ん中のもの(図柄は鎖)をクリックします。Add way to a 
relation と先頭に表示されたダイアログが現れますので、中央のリストボック
スに Create a new relation と表示されているのを確認して、右下の Add
と書かれたボタンをクリックします。
すると、先頭に Relation と書かれた新しいダイアログが開きます。また、左下
にある way のタグには白抜きの relation と書かれたタグが加わります。右
側の白抜きの四角い部分は role 値を入力するところです。
ダイアログの Relation の後ろの数字はサーバ登録前の仮番号です。ダイアロ
グの中央には node や way と同じデザインのタグ一覧があり、初期状態では 
type タグだけが入力待ち状態で表示されていますので、値として route を入
力します。
次に右上の丸十字状のアイコンをクリックすることで、タグの追加が可能です。
これによりroute, name, ref など必要なタグを加えていきます。特に name の
指定は重要で、他の route と明確に区別された判りやすい名称を記述してくだ
さい。ref も区別しやすいものがベターです。
入力が全て終われば、右下の OK ボタンをクリックしてください。作成に成功す
れば、選択した図上の way に薄紫色の縁取りが加わります。
・追加:既存の route に way を追加するには、追加したい way を選択し、relation ア
イコン(左下の真ん中)をクリックします。表示されたダイアログの真ん中にあ
るリストボックスの右端をクリックすると、その時点でダウンロードされている
(オブジェクトに関連付けられた)relation の一覧が表示されます。当然です
が、route 用だけでなく、multipolygon 用など一緒くたで、現状ではソート手
段はありませんので、数が多くなると探すのが大変です。また選択の手がかりは
name と ref の値しかありませんので、作成時に適当な名前を付けてしまうと、
この時点で後悔することになります。
選び出したら、左下の Add ボタンをクリックします。地図上の way に薄紫色
の縁取りが加わり(すでに他の route が指定してあれば色が濃くなります)、
左下に relation タグ(表示は 「route タグの値+ref値」)が追加され、必要
に応じて role 値を指定します。
・削除:取り除きたい way を選択し relation タグの右端の×アイコンをクリックしま
す。relation から全てのオブジェクトを削除しても、Potlatch が起動中は残存
していますが、一旦終了してしまうと、二度と指定することはできないようです
(固有ID番号を用いて指定する方法はないようです。何か情報をお持ちの方は教
授願います)。
・編集:編集したい route に登録されている way を選択し、relation タグをダブルク
リックすると、ダイアログが表示されます。

4-2. JOSM

・表示:JOSM で Relations を編集するには、まずリストを表示させる必要があります。
左側の一聯のアイコンのうち一番下の方の歯車が描かれたアイコンをクリックす
ると Relation と書かれたリストが表示されます。
・作成:リストの左下の new ボタンをクリックします。タイトルに Create new relation 
と書かれたダイアログが表示されますので、Tags 欄に type, route, name タグ
など、必要なものを記述します。JOSM でも relation の選択は name が基本で
すので、適切な名称付けが必要です。
タグ入力の終了後、関連付けする way を選択し(複数選択可)、左下の Add 
Sele... ボタンをクリックすると、Members 欄に選択した way が表示されます。
必要に応じて role 値を入力してください。
また、選択した way の Properties/Memberships リストには Member Of 欄に作
成した route が表示されます。
・追加:リストの中からroute を選択し、右下の Edit ボタンをクリックもしくはリスト