Re: [OSM-ja] マッピングスタイル募集!
石川といいます。 半日ドックの問診票を書きながらさらに追記。 # どっちかにせい!! OSM始めて始めて知ったこと: GPSって結構誤差があるのねぇ、ということ。 しばらくの間、通勤時にログ取りながら走っていたことがあるのですが、 実際のコースではせいぜい1mくらいのずれで走っているのに、GPSのログでは 4〜5mくらいの誤差になっています。 なので、自転車でちまちまと同じ道を複数回に分けてログ取っていると、 全然道がつながらなくて、「あれ?こんなとこに平行して道あったっけ?」なんて マヌケな疑問が出てきたりします。 そういう意味では、エンジン付きの車でバビューン!と一気取りしてサクッと 地図にして、二度とそこはログ取りしない!というのが悩まなくていいんですけど、 それでは精度悪そうだし。 皆さんはどうしてるんでしょう?何回かログを取ってバラついたデータをながめ、 ここぞというところに線を引いているんでしょうか?? # 電波遮るものが何もないところなんだから、もっと誤差少なくてもいいのにぃ。 2010/7/29 ISHIKAWA Sachihiro sachih...@gmail.com: 石川といいます。 ちょと追加。 「山下さんのマッピング成果」にもありましたが、自分も「「地図を作るために、そこに行くこと/そこを通ること」」を 楽しんでいます。 基本出不精なので、家の近所でも知らないところばかり。 家から1kmも離れていないのにこんなに知らない道がいっぱいあったなんて!!と思いながら走っています。 でもって、なんせ田舎なのでそういう道の傍らに小さい祠があったり、超小さい神社(畳1畳分くらい??)が あったり、素朴な如意輪観音が祭られている祠(?)を見つけたりして、そういうのを礼拝所としてマッピング したりしています。 2010/7/28 ISHIKAWA Sachihiro sachih...@gmail.com: 石川といいます。 名前=ケッタマシンマッピング 交通手段=ケッタマシンで歩道&車道をさっそうと?! (ケッタマシン:ごく一部地域で自転車のこと) 時間=最近はマッピング1時間、編集1時間くらい? 主なマッピング対象=近所の道路。 以前は水路関係(川とか用水とか)もがんばっていたが、 田舎の悲しさ農業用水がそれこそ網の目のようにあることが 分かってからは手を引いています。 あと、高圧線も押さえたいところですが、鉄塔の立っているところが とんでもないところだったりして、これも中途半端な状態。 ロガー=Garmin eTrex Vista Hcx、Garmin nuvi205 最近は専らeTrexの方をハンドルにマウントして走っています。 その他備品=ペン,メモ 先日、XperiaにOsmdroidをインストールして、既にマッピングが済んでいる 地図を表示して、まだ走破できていない道を確認しながらマッピングしました。 POIエディタ=なし!!POIは手抜き中。 気に入っているところ=そこそこ広い範囲を走れることと、一方通行気にしなくていいところ。 改善したいところ=POIの位置関係把握、自動車より気にしなくていい分見落としている道路標識 進行方向とか最高時速とか交差点の名前とか。 あと、森林・農地などのエリア把握や建物の形状把握なんかも必要だけど、 とりあえずは道路道路。 ログ読み出しアプリ=ロガーをPC直結 エディタ=JOSM コメント1=野暮用でちょっと離れたところ(電車で一時間くらい)によく行くのでそこは徒歩でログとってます。 あと仕事の都合で普段行かないところに行ったときも、ログとってます。 コメント2=eTrexは詳細地図を入れていないので、自分が作った地図をコンバートして入れています。 が、ずぼらな性格で最近は怠けがちで、既に作図済みの道もまだ未踏状態。 先日試してみたXperia併用策はなかなかいい感じだったので、しばらくこれで行ってみようか? コメント3=職務質問は。。。なんかそういう目で見られたくない小心者なので、何気なく何気なく。。。(汗 こんなところでしょうか。 nuvi205は画面も広いし電波もちゃんと拾うのでいいんですが、やっぱりログデータは既存の地図に 引っ張られることがあるのを体感してしまっているので、ログ取りにはいまいちかなーと思ってます。 GeoChachingにはいいかも。 -- -- nobichan -- -- nobichan -- -- nobichan ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] http://www.openstreetmap.jp/ について
白方です。 (2010/07/29 12:59), S.Higashi wrote: 現状回復とは、このうちどのあたりの機能を指されていますでしょうか。 とりあえず「いかにも」な状態はTomさんが作ってくださったページで 脱したとは思うのですが、情報提供という意味では (インフラとしてのCMSに加えて)とりあえずニュースブログが 動作するのがよいかなあ、という気がします。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] マッピングスタイル募集!
石川といいます。 御丁寧にありがとうございます。 原理関連の話は書籍等でも勉強しているので、 今はある程度わかっているつもりです。 あくまでも始めたばかりの頃の話ということで。。。 対処法については、参考にさせていただきます。というかあまり深く考えても仕方ないですしね。 とりあえずログとってアップするのがじゅうようということで。 では。 2010/07/31 3:59 say.n...@gmail.com: 清野です。 石川さんのご発言について。 その1 : GPSの測位誤差について。 http://ja.wikipedia.org/wiki/%E3%82%B0%E3%83%AD%E3%83%BC%E3%83%90%E3%83%AB%E3%83%BB%E3%83%9D%E3%82%B8%E3%82%B7%E3%83%A7%E3%83%8B%E3%83%B3%E3%82%B0%E3%83%BB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0 http://wwwsoc.nii.ac.jp/geod-soc/web-text/part2/2-4/2-4-1-1.html http://wwwsoc.nii.ac.jp/geod-soc/web-text/part2/2-4/2-4-1-1-1.html http://www.ngsc.co.jp/tec/gps_2.htm Googleで「GPS 精度 単独測位」で検索した結果、 良さそうなものをピックアップしたものですが、 この辺でまずGPS測量の基本原理を調べてみてはいかがでしょうか? (もしくは書籍を読んでみるのが一番良いかもしれません) なぜそのようなことが起きるのかについて、 原理を知っておけばある程度対処することも可能かと思います。 ちなみに多くの皆さんが使われているであろう、 普通に売られているGPSロガーの多くは 単独測位型と呼ばれるもので、 これらはその原理上、数m〜10数m程の測位誤差を含むのが一般的です。 その2 : 実際の対処法について。 http://ja.wikipedia.org/wiki/%E3%82%B0%E3%83%AD%E3%83%BC%E3%83%90%E3%83%AB%E3%83%BB%E3%83%9D%E3%82%B8%E3%82%B7%E3%83%A7%E3%83%8B%E3%83%B3%E3%82%B0%E3%83%BB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0#.E5.8F.97.E4.BF.A1.E5.8F.AF.E8.83.BD.E3.81.AA.E8.A1.9B.E6.98.9F.E3.81.AE.E5.80.8B.E6.95.B0.E3.83.BB.E9.85.8D.E7.BD.AE.E3.81.AB.E3.82.88.E3.82.8B.E5.BD.B1.E9.9F.BF こちらにも書かれていますが、 測位時のGPS衛星の配置状況によって、その測位精度は大きく変化してきます。 ですので、より高精度な測位が必要な場合は、 出来るだけ良い衛星配置になるタイミングを見計らって測位するのが 本来的には望ましいことです。 そのため、GPS衛星の飛来予測プログラムや軌道歴の情報も公開されており、 http://www.nikon-trimble.co.jp/support/index.html こうしたものを参考にしながら測位計画を立てたりもします。 また、その時の気候条件なども精度に影響を及ぼします。 しかし、これは本気の測量をする時の話で、 多くのOpen Street Mapperさんはそこまで考えてログ取りはしていないと思います。 ですので、普通はまず一回ログを取ってそれを元にWayを引き、 後はその後に同じ場所をログ取りした方が、 自分のログと以前アップロードされたログとを見比べて、 さらにそのWayを補正していく、 という手順を踏まれているのではないでしょうか。 その為にも、自分の取ったログはアップロードして公開しておき、 後に続いた人もそのログを参照しながらより精度の高いWayを引けるようにしておく、 ということが重要になってくるのではないかと思います。 人によっては、GPSロガーが記録している (OSMへのアップロード出来る*.gpxというファイル形式では 必須情報となっていないので、記述されていないことが多い) PDOP(Position Dilution of Precision)値を参考にしながら、 その値が低い場合はそのログを使わない、とか、 その部分だけはずしたログをアップロードする、 という判断をされている方もいます(関西のとしさんとか)。 ※PDOPとは? http://www.nikon-trimble.co.jp/glossary/index.html http://www.f2.dion.ne.jp/~ats_alfa/gps01.htm ※PDOPを含むDOPの説明(英語) http://en.wikipedia.org/wiki/Dilution_of_precision_(GPS) 以上、ものすごく簡単に、かつ、人様の資料を借りまくって 適当なご説明をしてしまいましたが、 お解り頂けましたでしょうか? 清野陽一 2010年7月31日1:19 ISHIKAWA Sachihiro sachih...@gmail.com: 石川といいます。 半日ドックの問診票を書きながらさらに追記。 # どっちかにせい!! OSM始めて始めて知ったこと: GPSって結構誤差があるのねぇ、ということ。 ... ___ Talk-ja mailing list talk...@openstreetmap.org... ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] マッピングスタイル募集!
清野です。 釈迦に説法でしたか…失礼いたしました。 単独測位はどうしてもそのくらいの誤差は含んでしまい、 我々ユーザーにはいかんともしがたい問題なので、 この辺は割り切るしかないと思います。 OSMも割り切って始まってるプロジェクトでしょうし。 # 日本国内に限って言えば、 # 準天頂衛星「みちびき」が実用段階に入れば、 # 単独測位でも測位精度の向上が見込めると思いますが、 # 残念ながらまだ時間がかかりそうです(既存の機器の対応はどうなんでしたっけ?識者の皆様) そのうち、「この地物は精度の高い測位をして描いたから、これを信じろ!!」 みたいな地物が出てくるかもしれません。 例えば、測量屋さんが自ら持っている機器を使って高精度な測量をして点を求めてくれたとか。 しかし、残念ながらそれを検証する術も無いので(基本的に自己申告)、 やはり現状ではみんながそれぞれのログを持ち寄って、 その正確さを検証するしかないんだと思います。 大事なのはひたすらみんなが自分の取ったログをアップして、 地物を描こうとしている人により多くの情報を提供してあげることだけなんだろうと思います。 それでは失礼いたします。 清野陽一 2010年7月31日9:34 ISHIKAWA Sachihiro sachih...@gmail.com: 石川といいます。 御丁寧にありがとうございます。 原理関連の話は書籍等でも勉強しているので、 今はある程度わかっているつもりです。 あくまでも始めたばかりの頃の話ということで。。。 対処法については、参考にさせていただきます。というかあまり深く考えても仕方ないですしね。 とりあえずログとってアップするのがじゅうようということで。 では。 2010/07/31 3:59 say.n...@gmail.com: 清野です。 石川さんのご発言について。 その1 : GPSの測位誤差について。 http://ja.wikipedia.org/wiki/%E3%82%B0%E3%83%AD%E3%83%BC%E3%83%90%E3%83%AB%E3%83%BB%E3%83%9D%E3%82%B8%E3%82%B7%E3%83%A7%E3%83%8B%E3%83%B3%E3%82%B0%E3%83%BB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0 http://wwwsoc.nii.ac.jp/geod-soc/web-text/part2/2-4/2-4-1-1.html http://wwwsoc.nii.ac.jp/geod-soc/web-text/part2/2-4/2-4-1-1-1.html http://www.ngsc.co.jp/tec/gps_2.htm Googleで「GPS 精度 単独測位」で検索した結果、 良さそうなものをピックアップしたものですが、 この辺でまずGPS測量の基本原理を調べてみてはいかがでしょうか? (もしくは書籍を読んでみるのが一番良いかもしれません) なぜそのようなことが起きるのかについて、 原理を知っておけばある程度対処することも可能かと思います。 ちなみに多くの皆さんが使われているであろう、 普通に売られているGPSロガーの多くは 単独測位型と呼ばれるもので、 これらはその原理上、数m〜10数m程の測位誤差を含むのが一般的です。 その2 : 実際の対処法について。 http://ja.wikipedia.org/wiki/%E3%82%B0%E3%83%AD%E3%83%BC%E3%83%90%E3%83%AB%E3%83%BB%E3%83%9D%E3%82%B8%E3%82%B7%E3%83%A7%E3%83%8B%E3%83%B3%E3%82%B0%E3%83%BB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0#.E5.8F.97.E4.BF.A1.E5.8F.AF.E8.83.BD.E3.81.AA.E8.A1.9B.E6.98.9F.E3.81.AE.E5.80.8B.E6.95.B0.E3.83.BB.E9.85.8D.E7.BD.AE.E3.81.AB.E3.82.88.E3.82.8B.E5.BD.B1.E9.9F.BF こちらにも書かれていますが、 測位時のGPS衛星の配置状況によって、その測位精度は大きく変化してきます。 ですので、より高精度な測位が必要な場合は、 出来るだけ良い衛星配置になるタイミングを見計らって測位するのが 本来的には望ましいことです。 そのため、GPS衛星の飛来予測プログラムや軌道歴の情報も公開されており、 http://www.nikon-trimble.co.jp/support/index.html こうしたものを参考にしながら測位計画を立てたりもします。 また、その時の気候条件なども精度に影響を及ぼします。 しかし、これは本気の測量をする時の話で、 多くのOpen Street Mapperさんはそこまで考えてログ取りはしていないと思います。 ですので、普通はまず一回ログを取ってそれを元にWayを引き、 後はその後に同じ場所をログ取りした方が、 自分のログと以前アップロードされたログとを見比べて、 さらにそのWayを補正していく、 という手順を踏まれているのではないでしょうか。 その為にも、自分の取ったログはアップロードして公開しておき、 後に続いた人もそのログを参照しながらより精度の高いWayを引けるようにしておく、 ということが重要になってくるのではないかと思います。 人によっては、GPSロガーが記録している (OSMへのアップロード出来る*.gpxというファイル形式では 必須情報となっていないので、記述されていないことが多い) PDOP(Position Dilution of Precision)値を参考にしながら、 その値が低い場合はそのログを使わない、とか、 その部分だけはずしたログをアップロードする、 という判断をされている方もいます(関西のとしさんとか)。 ※PDOPとは? http://www.nikon-trimble.co.jp/glossary/index.html http://www.f2.dion.ne.jp/~ats_alfa/gps01.htm ※PDOPを含むDOPの説明(英語) http://en.wikipedia.org/wiki/Dilution_of_precision_(GPS) 以上、ものすごく簡単に、かつ、人様の資料を借りまくって 適当なご説明をしてしまいましたが、 お解り頂けましたでしょうか? 清野陽一 2010年7月31日1:19 ISHIKAWA Sachihiro sachih...@gmail.com: 石川といいます。 半日ドックの問診票を書きながらさらに追記。 # どっちかにせい!! OSM始めて始めて知ったこと: GPSって結構誤差があるのねぇ、ということ。 ... ___ Talk-ja mailing list talk...@openstreetmap.org... ___ 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
[Talk-GB] Yet more musical chairs updates.
Hello everybody, I'm sure you all feel you've heard enough about my recent activities by now, but I do quite like the latest things I've added to musical chairs. There are now multiple view modes for high zoom levels - determining which entries the db will prioritize when there are too many entries to show at once. http://ris.dev.openstreetmap.org/oslmusicalchairs Try selecting 'recent status updates' in the top right selector. It will show you where the most recent streetname-related activity has been. robert. ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 12:24 AM, Alan Millar amillar...@gmail.com wrote: I haven't seen a conclusion on what people want to see in the naming convention (see for example the thread at http://lists.openstreetmap.org/pipermail/talk-us/2010-April/003138.html). Just because the conversation is ongoing, that doesn't mean you need to delete the data in the meantime. No, I don't need to, and I generally only do so when I'm otherwise editing the ways anyway. I've explained my reasons, and I haven't heard anything to change my mind about them. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
At 2010-07-30 07:28, Anthony wrote: On Fri, Jul 30, 2010 at 12:24 AM, Alan Millar amillar...@gmail.com wrote: I haven't seen a conclusion on what people want to see in the naming convention (see for example the thread at http://lists.openstreetmap.org/pipermail/talk-us/2010-April/003138.html). Just because the conversation is ongoing, that doesn't mean you need to delete the data in the meantime. No, I don't need to, and I generally only do so when I'm otherwise editing the ways anyway. I've explained my reasons, and I haven't heard anything to change my mind about them. [ This is long. Sorry. ] I really don't understand your argument. It's the nature of OSM that many people will contribute many types of data, much of which will not be cared about or understood by the majority of consumers. What's wrong with that, and why do you think removing it because you don't understand or like it is acceptable behavior in a crowd-sourced environment? The only reason that makes sense might be it's wrong. In the case of tiger:*, it's not wrong. It's in its own namespace because it indicates the value as it was in another database at the time of import. Not that I believe we need to justify it, but the three (at least) of us arguing to keep the tags in this thread, each for reasons that we've described, should be sufficient to prove that someone needs the data, and you really have no right to stomp on our work, or data that we need for our work. Also, we're not alone - many people recognized the need to fix the way names are stored. Having to go back to history will be adding an order of magnitude to the complexity of that. Have a look at tagwatch and you'll see that tiger:* is just one of many such import namespaces, most of which you are not likely to care about, whether they are doc'd or not. There's another, very important use for the tiger:reviewed tag. It was designed to let you know what ways need to be satellite- or GPS-aligned, since the original data was very poorly aligned. Having these render differently in JOSM is an important workflow tool. After I'm done aligning, I remove that tag, as documented in the wiki. When I've surveyed it in real life, I add source and source_ref tags to cite my source. BTW, someone started stomping on those as well because they saw no need for my picture #s[0], but after discussing it, was convinced to leave them alone. Someone asked a ways back whether the tiger:* tags could be combined into a single value, which leads me to think that there is a hidden reason that at least two people don't want these. Does it have something to do with the editing tools being used? In JOSM, the tags appear in alpha order, which ends up placing them almost always below any of the commonly edited tags. Is the real problem that other editors aren't doing this, resulting in clutter in the editing process? Can't we just solve this in editors, maybe by placing the common import namespaces last in sort order? FWIW, the only time I intentionally *remove* data is when I'm certain (or as close as possible to certain) that it is wrong, almost always replacing it with my own correct data. I believe this is one of the fundamental principles of the community, and would hope that others adhere to it. One recent exception is that, over a large chunk of southern California, a user had entered maxspeed values that were incorrectly converted from mph to kph using a wrong, and sometimes unpredictable, factor. I've moved the ones that I know to be wrong (because they are not integral multiples of 5 mph, are inconsistent with the road type, and were edited by this user) to bad_maxspeed=*. When adding the correct maxspeed from my own survey, I then remove the bad_maxspeed tag. Unfortunately, some remain with maxspeed=40, for which it is not possible to determine accuracy in all cases, but that's not a reason to remove them until I have proof. BTW, the same user also can't spell (English/American/Spanish names mostly), and I've spent a fair amount of time having to research and correct those, too. I don't wipe them out just because I think they're likely wrong, though, until I research them. Notes: [0] Those source_ref=AM909_* values in source_ref are links to the pics I have of the names of the streets. There are other source_ref:*=* values for other attributes that are proved by pics. At some point, they could be links to an online repository of these pics, given interest, and some post-processing to remove faces and license plates. Right now, they allow me to look back at partial surveys of attributes (like speed limits) and combine them with newer surveying to form a complete picture, and are an important part of my workflow. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 2:24 PM, Alan Mintz alan_mintz+...@earthlink.net wrote: There's another, very important use for the tiger:reviewed tag. As I've said above, that's the one tiger tag I don't remove (until I've reviewed the way, of course). You don't seem to have read that message. In it I went through each of the tiger tags individually and explained what was wrong with them. The tiger:tlid key in particular is in horrible shape, to the point where I guess at least 95% of them *are* wrong. Basically, the only tag I can imagine worth keeping would be the name_type, name_base, name_* ones, and those should be removed from the tiger:* namespace. But really before that can be done a standard should be decided on about how to store the names. Once that is done, I'll gladly produce a script to re-add all the name_base/name_types that I've deleted. Anyway, I hear what you're saying about removing things added by others, but when you fill the database with millions upon millions of entries with no apparent usefulness, I think part of the burden is on you to justify why they should stay. TIGER was great for filling up what was a nearly blank map. But gradually we should be moving beyond TIGER. Hopefully one day there will be no TIGER data left. That should be the goal. So I guess we're at an impasse. Because your message above hasn't provided me any new information. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Thu, Jul 29, 2010 at 4:11 PM, Dave Hansen d...@sr71.net wrote: So, the guys that actually went out and were nice enough to collect this TIGER data and share it with us have names for all these things: TLIDs. That's a pretty concrete, real-world meaning to some people. Not in osm context. DB id from an external DB are useless in osm. any can edit them. ways are merged and split over time many of them don't reflect any link to the tiger tlid anymore. it's just filling the planet files. I't is nice to have such a reference on the initial import but there is no use to keep them after edits. If we had changesets at the time it was imported then this is the place to add these tags. there they are readonly and don't fill the planet with useless info ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
Just for that short little bridge? This info should be right (which means *one* tlid) or it shouldn't be there at all. We shouldn't keep this crap around just for the hell of it. By deleting it you're not making it more correct. Never said I was. But deleting incorrect information is better than leaving it around, even if it isn't as good as correcting it. full ack How would I even go about checking? Is this really something we should be doing every time we make a bridge? what a waste of time, let's go mapping instead. this is a wast of time I think we should enhance Josm/Potlatch to remove these tags in the same way as it is done for created_by ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 11:24 AM, Alan Mintz alan_mintz+...@earthlink.netalan_mintz%2b...@earthlink.net wrote: I really don't understand your argument. It's the nature of OSM that many people will contribute many types of data, much of which will not be cared about or understood by the majority of consumers. What's wrong with that, and why do you think removing it because you don't understand or like it is acceptable behavior in a crowd-sourced environment? importing is not crowd-sourced! we should apply different rules here. what is wrong normally might be a very good thing for imports and the other way round The only reason that makes sense might be it's wrong. In the case of tiger:*, it's not wrong. It's in its own namespace because it indicates the value as it was in another database at the time of import. Not that I believe we need to justify it, but the three (at least) of us arguing to keep the tags in this thread, each for reasons that we've described, should be sufficient to prove that someone needs the data, and you really have no right to stomp on our work, or data that we need for our work. Also, we're not alone - many people recognized the need to fix the way names are stored. Having to go back to history will be adding an order of magnitude to the complexity of that. if you need them use a native tiger DB, working through history is such a pain that it doesn't make sense. GIS experts will know how to do this and can easily compare osm data with another DB. Have a look at tagwatch and you'll see that tiger:* is just one of many such import namespaces, most of which you are not likely to care about, whether they are doc'd or not. other trash doesn't make these tags more useful. We have all learned from early imports and since then changesets have been added to the API0.6 tiger import was done before and we can't blame anyone. but now we can do it better and fix old mistakes ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
At 2010-07-30 12:56, Apollinaris Schoell wrote: How would I even go about checking? Is this really something we should be doing every time we make a bridge? what a waste of time, let's go mapping instead. this is a wast of time I think we should enhance Josm/Potlatch to remove these tags in the same way as it is done for created_by Hopefully, you were talking about this specific case only, and not all tiger:*=* tags? Even still, matching the chain of TLIDs to the ways on either side may still prove to be useful at some point. Do we really need the database space that badly? Shouldn't an analysis be done to understand just how much space that is, what the server load will be, how much it expands the history, etc., as was done with the justified removal of tags from the nodes? -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 1:12 PM, Alan Mintz alan_mintz+...@earthlink.netalan_mintz%2b...@earthlink.net wrote: At 2010-07-30 12:56, Apollinaris Schoell wrote: How would I even go about checking? Is this really something we should be doing every time we make a bridge? what a waste of time, let's go mapping instead. this is a wast of time I think we should enhance Josm/Potlatch to remove these tags in the same way as it is done for created_by Hopefully, you were talking about this specific case only, and not all tiger:*=* tags? Even still, matching the chain of TLIDs to the ways on either side may still prove to be useful at some point. Do we really need the database space that badly? Shouldn't an analysis be done to understand just how much space that is, what the server load will be, how much it expands the history, etc., as was done with the justified removal of tags from the nodes? personally I think all of them. there is no value after editing. usually I keep tlid, zipcode, county, name_type even that this isn't very useful there can be still some use if an application doen't yet use county polygons or there is no info about zipcode otherwise in osm longterm even these should go away. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On 30 July 2010 21:00, Anthony o...@inbox.org wrote: On Fri, Jul 30, 2010 at 2:24 PM, Alan Mintz alan_mintz+...@earthlink.net wrote: There's another, very important use for the tiger:reviewed tag. As I've said above, that's the one tiger tag I don't remove (until I've reviewed the way, of course). You don't seem to have read that message. In it I went through each of the tiger tags individually and explained what was wrong with them. The tiger:tlid key in particular is in horrible shape, to the point where I guess at least 95% of them *are* wrong. How do you come to that figure? My guess would be that 95% are right. The only objects that may contain a TLID that refers to a different real life object and don't contain a TLID that refers to the actual object can be those that (a) underwent very heavy surgery (not simple splitting or joining, but exchanging tags and geometry with another object for example) or (b) were fictitious and shouldn't have been in tiger in the first place. Most objects have not been touched at all, out of those which have been touched by a mapper, most have been changed using common sense to find the shortest path to make the object correct (e.g. change street's name tag and leave geometry mostly alone or change geometry and leave the name alone, splitting, joining, etc) Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On 30 July 2010 22:12, Alan Mintz alan_mintz+...@earthlink.net wrote: Do we really need the database space that badly? I've heard arguments on the talk list that this clutters the database and similarly wikipedia= tags should be massively removed and if at all, links should be maintained then in the wikipedia database *to* our objects rather in our database to wikipedia pages. This just sounds like passing on the hot potato. Even if osm comes to be a point where references to ten different databases are kept for objects, it's still valuable information, and I personally don't see how it's inconvenient. If it hurts your eyes how the name= and highway= tags are lost among the other tags in your favourite editor, then perhaps modify the editor. Keep the links in whatever database it makes most sense, for example wikipedia pages are indexed by their title, which is a pretty stable reference, as opposed to OSM id's, that's why it make more sense to keep them here. TIGER data we can't edit, that's why it makes more sense to keep the id's here. Flickr (if treated as a big database where each photo is a record) had the balls to store references to osm objects, as well as dopplr.com IDs and foursquare.com venue IDs in their machine tags for each picture that is a photograph of a given object. There was no fear of cluttering their machine tags space. Why would it be an issue in osm? Also note that once there's a photo on flickr that is tagged with an osm object id and a foursquare.com venue id at the same time, you have a link between OSM and foursquare.com, no need to duplicate this information in either of these databases. If that osm object contains a tiger tlid, you can tie the foursquare.com venue to a tiger record and so on. I'm not asking anyone to go adding these tags, but just saying that they don't hurt, even if they're just a hint (a bridge that contains twenty TLIDs and perhaps only one of them is the right one). Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 6:36 PM, andrzej zaborowski balr...@gmail.com wrote: Also note that once there's a photo on flickr that is tagged with an osm object id and a foursquare.com venue id at the same time, you have a link between OSM and foursquare.com, no need to duplicate this information in either of these databases. If that osm object contains a tiger tlid, you can tie the foursquare.com venue to a tiger record and so on. Serious question: why would anyone want to do this? (putting aside the fact that foursquare is probably not for streets) Does the TLID have any significance outside TIGER? I'm not asking anyone to go adding these tags, but just saying that they don't hurt, even if they're just a hint (a bridge that contains twenty TLIDs and perhaps only one of them is the right one). What about a bridge that contains forty TLIDs and none is the right one because the right one was the fiftieth and that many TLIDs wouldn't fit in the maximum field size (255 characters, I believe)? The way I see it is that if I were mapping an area from scratch, nobody would go adding the TIGER tags. So if I completely redo an area, whether I use existing ways or draw new ways, there's no reason to keep the TIGER tags. If anyone objects, I can change my workflow to delete the old ways and create new ways rather than redrawing the old ways :) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 5:50 PM, Nathan Edgars II nerou...@gmail.comwrote: The way I see it is that if I were mapping an area from scratch, nobody would go adding the TIGER tags. So if I completely redo an area, whether I use existing ways or draw new ways, there's no reason to keep the TIGER tags. If anyone objects, I can change my workflow to delete the old ways and create new ways rather than redrawing the old ways :) I concur with this. My workflow involves removing TIGER data when I move a node/way using gps traces or satellite imagery. I saw no value in keeping this data. I believe I brought this topic up a while ago and no one ever really gave me a good reason not to do this. If anyone does object, I will delete the old way and draw a new one as Nathan stated as well, I just find more value in moving the ways because a history on the way will show that it originated from a TIGER Import, but no longer references to it because it is in fact, not that way anymore. I really see no need to reference it anymore. I do not however, go deleting TIGER tags off ways I do not touch. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On 31 July 2010 00:50, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 6:36 PM, andrzej zaborowski balr...@gmail.com wrote: Also note that once there's a photo on flickr that is tagged with an osm object id and a foursquare.com venue id at the same time, you have a link between OSM and foursquare.com, no need to duplicate this information in either of these databases. If that osm object contains a tiger tlid, you can tie the foursquare.com venue to a tiger record and so on. Serious question: why would anyone want to do this? (putting aside the fact that foursquare is probably not for streets) Does the TLID have any significance outside TIGER? Various use cases I can see right now, and there are more. * You may just want to display a link to the osm object or tiger object on a flickr photo page (flickr already does it for photos tagged with osm:node|way|relation= ), the service may even automatically extract metadata from either of the databases, like this is a building, this is a road, so even the computer can know what exactly is on the photo, no need to analyse the picture. Google could use it to enhance picture search etc. OSM gives you some information on the object, TIGER gives you other type of information (official classification, weird area codes etc), another database (like foursquare.com? not sure) can tell you the capacity of a bar and maybe even price level for a restaurant that's a node in OSM. * knowing which direction the camera looked, you can actually overlay the road geometry on it, make it clickable etc., same way Google Street View shows 3d lines for roads on the panoramas. * knowing that road A in TIGER crosses roads B, C and D, you can do sanity checks if the same ways cross each other in OSM, that may be helpful both to the tiger maintainers and to OSM. Same way you can check if a junction has the right number of roads meeting there. * you can provide routing in one area using map A, and seemlessly switch to map B when you cross some border and based on some other critera. In effect you can generate a single route using multiple maps, you can mix and match in any ways you like. Wikipedia page on Linked Data has more on this, there are endless possibilities. I'm not asking anyone to go adding these tags, but just saying that they don't hurt, even if they're just a hint (a bridge that contains twenty TLIDs and perhaps only one of them is the right one). What about a bridge that contains forty TLIDs and none is the right one because the right one was the fiftieth and that many TLIDs wouldn't fit in the maximum field size (255 characters, I believe)? The way I see it is that if I were mapping an area from scratch, nobody would go adding the TIGER tags. So if I completely redo an area, whether I use existing ways or draw new ways, there's no reason to keep the TIGER tags. If anyone objects, I can change my workflow to delete the old ways and create new ways rather than redrawing the old ways :) What I mean is keep the tags if it doesn't cost you anything. If it would impact your mapping effiency then perhaps it make more sense to skip them, it's a tradeoff. However when you map an area from scratch, what metadata do you add? Perhaps highway= classes and name=, all other other information are pretty boring to survey and it's easier to just copy them over from the tiger ways you delete. I just use ctrl+c + ctrl+shift+v, this copies all the tags in JOSM, and you can then modify the values if anything is wrong in that data. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 8:11 PM, andrzej zaborowski balr...@gmail.com wrote: On 31 July 2010 00:50, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 6:36 PM, andrzej zaborowski balr...@gmail.com wrote: Also note that once there's a photo on flickr that is tagged with an osm object id and a foursquare.com venue id at the same time, you have a link between OSM and foursquare.com, no need to duplicate this information in either of these databases. If that osm object contains a tiger tlid, you can tie the foursquare.com venue to a tiger record and so on. Serious question: why would anyone want to do this? (putting aside the fact that foursquare is probably not for streets) Does the TLID have any significance outside TIGER? Various use cases I can see right now, and there are more. * You may just want to display a link to the osm object or tiger object on a flickr photo page (flickr already does it for photos tagged with osm:node|way|relation= ), the service may even automatically extract metadata from either of the databases, like this is a building, this is a road, so even the computer can know what exactly is on the photo, no need to analyse the picture. Google could use it to enhance picture search etc. OSM gives you some information on the object, TIGER gives you other type of information (official classification, weird area codes etc), another database (like foursquare.com? not sure) can tell you the capacity of a bar and maybe even price level for a restaurant that's a node in OSM. * knowing which direction the camera looked, you can actually overlay the road geometry on it, make it clickable etc., same way Google Street View shows 3d lines for roads on the panoramas. * knowing that road A in TIGER crosses roads B, C and D, you can do sanity checks if the same ways cross each other in OSM, that may be helpful both to the tiger maintainers and to OSM. Same way you can check if a junction has the right number of roads meeting there. * you can provide routing in one area using map A, and seemlessly switch to map B when you cross some border and based on some other critera. In effect you can generate a single route using multiple maps, you can mix and match in any ways you like. I don't think you understand how the TLIDs are stored in OSM. They were never one TLID per way; the initial import joined a bunch of adjacent ways and concatenated the TLIDs. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On 31 July 2010 02:24, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 8:11 PM, andrzej zaborowski balr...@gmail.com wrote: On 31 July 2010 00:50, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 6:36 PM, andrzej zaborowski balr...@gmail.com wrote: Also note that once there's a photo on flickr that is tagged with an osm object id and a foursquare.com venue id at the same time, you have a link between OSM and foursquare.com, no need to duplicate this information in either of these databases. If that osm object contains a tiger tlid, you can tie the foursquare.com venue to a tiger record and so on. Serious question: why would anyone want to do this? (putting aside the fact that foursquare is probably not for streets) Does the TLID have any significance outside TIGER? Various use cases I can see right now, and there are more. * You may just want to display a link to the osm object or tiger object on a flickr photo page (flickr already does it for photos tagged with osm:node|way|relation= ), the service may even automatically extract metadata from either of the databases, like this is a building, this is a road, so even the computer can know what exactly is on the photo, no need to analyse the picture. Google could use it to enhance picture search etc. OSM gives you some information on the object, TIGER gives you other type of information (official classification, weird area codes etc), another database (like foursquare.com? not sure) can tell you the capacity of a bar and maybe even price level for a restaurant that's a node in OSM. * knowing which direction the camera looked, you can actually overlay the road geometry on it, make it clickable etc., same way Google Street View shows 3d lines for roads on the panoramas. * knowing that road A in TIGER crosses roads B, C and D, you can do sanity checks if the same ways cross each other in OSM, that may be helpful both to the tiger maintainers and to OSM. Same way you can check if a junction has the right number of roads meeting there. * you can provide routing in one area using map A, and seemlessly switch to map B when you cross some border and based on some other critera. In effect you can generate a single route using multiple maps, you can mix and match in any ways you like. I don't think you understand how the TLIDs are stored in OSM. They were never one TLID per way; the initial import joined a bunch of adjacent ways and concatenated the TLIDs. I don't see how it changes anything. If a piece of interstate I-405 is described by one relation or two ways one for each carriage in osm, and 10 segments in TIGER, than that's a way to describe it. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 8:28 PM, andrzej zaborowski balr...@gmail.com wrote: On 31 July 2010 02:24, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 8:11 PM, andrzej zaborowski balr...@gmail.com wrote: On 31 July 2010 00:50, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 6:36 PM, andrzej zaborowski balr...@gmail.com wrote: Also note that once there's a photo on flickr that is tagged with an osm object id and a foursquare.com venue id at the same time, you have a link between OSM and foursquare.com, no need to duplicate this information in either of these databases. If that osm object contains a tiger tlid, you can tie the foursquare.com venue to a tiger record and so on. Serious question: why would anyone want to do this? (putting aside the fact that foursquare is probably not for streets) Does the TLID have any significance outside TIGER? Various use cases I can see right now, and there are more. * You may just want to display a link to the osm object or tiger object on a flickr photo page (flickr already does it for photos tagged with osm:node|way|relation= ), the service may even automatically extract metadata from either of the databases, like this is a building, this is a road, so even the computer can know what exactly is on the photo, no need to analyse the picture. Google could use it to enhance picture search etc. OSM gives you some information on the object, TIGER gives you other type of information (official classification, weird area codes etc), another database (like foursquare.com? not sure) can tell you the capacity of a bar and maybe even price level for a restaurant that's a node in OSM. * knowing which direction the camera looked, you can actually overlay the road geometry on it, make it clickable etc., same way Google Street View shows 3d lines for roads on the panoramas. * knowing that road A in TIGER crosses roads B, C and D, you can do sanity checks if the same ways cross each other in OSM, that may be helpful both to the tiger maintainers and to OSM. Same way you can check if a junction has the right number of roads meeting there. * you can provide routing in one area using map A, and seemlessly switch to map B when you cross some border and based on some other critera. In effect you can generate a single route using multiple maps, you can mix and match in any ways you like. I don't think you understand how the TLIDs are stored in OSM. They were never one TLID per way; the initial import joined a bunch of adjacent ways and concatenated the TLIDs. I don't see how it changes anything. If a piece of interstate I-405 is described by one relation or two ways one for each carriage in osm, and 10 segments in TIGER, than that's a way to describe it. So how would you do any of the applications described above? They all require either a single TLID or everything to be tagged with a field that includes the correct TLID (due to joining, splitting, and redrawing, the latter is not true). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On 31 July 2010 02:33, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 8:28 PM, andrzej zaborowski balr...@gmail.com wrote: I don't see how it changes anything. If a piece of interstate I-405 is described by one relation or two ways one for each carriage in osm, and 10 segments in TIGER, than that's a way to describe it. So how would you do any of the applications described above? They all require either a single TLID or everything to be tagged with a field that includes the correct TLID (due to joining, splitting, and redrawing, the latter is not true). So your program tries to come up with a route, it knows it's driving on road A in osm. A has id=1 and is tagged tiger:tlid=20:21:22:23, and it is connected to road B (id=2, tiger:tlid=24:25:26:27) by node id=3. You also see that tiger way 23 meets 24. That clearly means that from osm road A you can go into tiger way 24 when you reach node id=3, without even looking at the geometry and fuzzy guessing things (remember routing works on huge graphs). Or say that the government releases a database that says how many traffic signals there are on each segment of road. Then you can find the junction nodes on which they should be in OSM, or at least count how many there should be on a given street. And yes, street names are not 100% correct or complete in OSM today.. we don't remove them though. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On 31 July 2010 03:02, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 8:44 PM, andrzej zaborowski balr...@gmail.com wrote: On 31 July 2010 02:33, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 8:28 PM, andrzej zaborowski balr...@gmail.com wrote: I don't see how it changes anything. If a piece of interstate I-405 is described by one relation or two ways one for each carriage in osm, and 10 segments in TIGER, than that's a way to describe it. So how would you do any of the applications described above? They all require either a single TLID or everything to be tagged with a field that includes the correct TLID (due to joining, splitting, and redrawing, the latter is not true). So your program tries to come up with a route, it knows it's driving on road A in osm. A has id=1 and is tagged tiger:tlid=20:21:22:23, and it is connected to road B (id=2, tiger:tlid=24:25:26:27) by node id=3. You also see that tiger way 23 meets 24. That clearly means that from osm road A you can go into tiger way 24 when you reach node id=3, without even looking at the geometry and fuzzy guessing things (remember routing works on huge graphs). But road A has been rerouted since the TIGER data was created and now ends at road C, without touching road B. You can't use shortcuts like this. Sure it can be outdated same as any other tag value. Or am I misunderstanding your example? If you already know A and B are joined at node 3, what do the TLIDs tell you? The TLIDs tell you you where you are if you want to switch from OSM routing to TIGER routing at that node for example. And they tell you road A in TIGER has (say) 4 crossings with other roads, so if that's not true in OSM, you know one of the maps needs fixing. If something changes between TIGER2006 and TIGER2009 you can see which osm segments may need fixing too. Or say that the government releases a database that says how many traffic signals there are on each segment of road. Then you can find the junction nodes on which they should be in OSM, or at least count how many there should be on a given street. TLID 24 has two lights and TLID 25 has three. Joined TLID 24;25 might have four or five. Well.. sure, possible, but that's assuming that the database was made in such unfortunate way that each single lights can be counted two or more times. The census data tends to not be that bad (at least in the design) Add one to the possible error for each new segment. Then split out bridges and it becomes unmanageable. Again note about bad data in osm.. Plus if your program sees a non-bridge segment with tiger:tlid=20:21:23 and a next (bridge) segment with the same tiger:tlid, it should really notice that the five traffic lights are somewhere on those two segments, not five on each. And yes, street names are not 100% correct or complete in OSM today.. we don't remove them though. So are you saying you or someone else will be checking all TLIDs against the TIGER data and correcting errors and adding missing ones? So people in Germany are mapping curb heights for streets. There's the openpistemap and special tagging for ski piste types. There's a whole spectrum of informations with different numbers of people who care about it, and it changes in time. (specially when a visualisation becomes available.. who cared about dupe nodes before the dupe nodes map?) Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
So are you saying you or someone else will be checking all TLIDs against the TIGER data and correcting errors and adding missing ones? I can imagine someone making some clever scripts and then manually verifying it where there are doubts as a kind of personal project of the week or something. A couple of months ago Marcus Wolschon has been reporting on the general talk list on his progress in adding the TMC road IDs to OSM in some parts of Germany or Austria. TMC is some kind of radio broadcast current traffic amount estimates, some satnavs can use it to avoid traffic jams automatically. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 9:40 PM, andrzej zaborowski balr...@gmail.com wrote: So are you saying you or someone else will be checking all TLIDs against the TIGER data and correcting errors and adding missing ones? I can imagine someone making some clever scripts and then manually verifying it where there are doubts as a kind of personal project of the week or something. A couple of months ago Marcus Wolschon has been reporting on the general talk list on his progress in adding the TMC road IDs to OSM in some parts of Germany or Austria. TMC is some kind of radio broadcast current traffic amount estimates, some satnavs can use it to avoid traffic jams automatically. Sounds like a useful ID number to map. Unlike TLIDs. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On 31 July 2010 04:06, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 9:40 PM, andrzej zaborowski balr...@gmail.com wrote: So are you saying you or someone else will be checking all TLIDs against the TIGER data and correcting errors and adding missing ones? I can imagine someone making some clever scripts and then manually verifying it where there are doubts as a kind of personal project of the week or something. A couple of months ago Marcus Wolschon has been reporting on the general talk list on his progress in adding the TMC road IDs to OSM in some parts of Germany or Austria. TMC is some kind of radio broadcast current traffic amount estimates, some satnavs can use it to avoid traffic jams automatically. Sounds like a useful ID number to map. Unlike TLIDs. Internet is a *network* of linked databases [1].. if someone has a TMC to TIGER mapping, you get a TMC to OSM mapping for free. Cheers 1. http://en.wikipedia.org/wiki/File:Lod-datasets_2009-07-14_colored.png (see US Census bubble) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 10:15 PM, andrzej zaborowski balr...@gmail.com wrote: On 31 July 2010 04:06, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 9:40 PM, andrzej zaborowski balr...@gmail.com wrote: I can imagine someone making some clever scripts and then manually verifying it where there are doubts as a kind of personal project of the week or something. A couple of months ago Marcus Wolschon has been reporting on the general talk list on his progress in adding the TMC road IDs to OSM in some parts of Germany or Austria. TMC is some kind of radio broadcast current traffic amount estimates, some satnavs can use it to avoid traffic jams automatically. Sounds like a useful ID number to map. Unlike TLIDs. Internet is a *network* of linked databases [1].. if someone has a TMC to TIGER mapping, you get a TMC to OSM mapping for free. Doesn't look like TMC is tied to ways, let alone the exact ways that TIGER uses: http://en.wikipedia.org/wiki/Traffic_Message_Channel#Criticism Have fun with your useless TLIDs. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us