[OSM-ja] Tondabayashi/Road Building importについて
富田林市の浅野です。 富田林市地形図のOSMへのインポートについて、数々のご意見をいただきありがとうございます。 これまでのご意見と、それに対する対応について、以下のような経過と理解しています。Wikiにつきましても、ご意見の都度修正を行い、ご意見に対応する修正は完了しています。 今後、道路及び建物データの既存修正並びにインポート作業を実施し、2015年内にはインポートを終了させたいと考えています。 7月19日（提案） 富田林市として市内の各施設の案内サイトについて、27年度に背景地図をOSMに移行し、行政各事務に利用する地図や、市民や事業者から市への申請に利用される地図についてもOSMを推奨する計画を説明する。市が保有する地形図をクリエイティブ・コモンズ（CC-BY2.1JP）のライセンスに則って公開し、OSMに移植する作業は地域関係者が個人として行う。今後、毎年度の地形図差分（CC-BY）を用いて定期的な更新も予定している。 7月20日（意見） yh:widthはwidthに入れて良いのではないか。oneway=noは何も入力されていなければoneway=noとみなされる。道路データの向きも一方通行の向きと合っているのか。 7月20日（対応） 「oneway=yes」のみ対応する。市内のすべての一方通行の方向を把握している。 7月20日（意見） widthに「〜」を含む値を入れるのは適切ではないのでest_width等どうか？ 7月20日（対応） 「width」は通行形態（車両通行不可、軽車両のみ、対面1車線、同2車線、4車線等）を代表する数値として「yh:width」と同様の幅員区分で整理していたもの。OSMではそれらに対応するものとしてはhighwayが近いように思うので、インポートデータのwidth値を参照しながら、highwayを設定する。 7月20日（意見） 道路と建物の作業を同時に進めるより、道路、建物の順にして、Phase 1として道路、Phase 2で建物とフェーズを記載しておくと良い。 7月21日（対応） インポートする道路ラインと建物形状は、既に相互の位置関係は適正化しているため、どちらが先行しても問題はない。ただ、多くの方にご協力いただくことを前提とすれば、道路を優先するという順番を原則として進める。 7月20日（意見） 道路中心線および建物データには最低限のタグしか付与されていない。一方既存の建物にはname や building:levelなどがあり、インポート作業の際に既存データから転記を行うという手順か？ 7月21日（対応） 既存のデータのTagに関しては、最大限に尊重して転記する。 7月20日（意見） 道路データにhighwayのキーに対する値が入っていない。これは、既にOSMに入っているデータから移植するということでよいか？ また、国道・県道のrouteリレーションに対する作業を行う必要もある。道路を削除する必要がある場合には、このリレーションについても考慮すること。 7月21日（対応） highwayは、既存データ並びにインポートデータのWidthデータを参照して校正する。国道・府道・主要地方道は、既存データを優先しインポートデータはその位置修正の参考として利用する。 7月20日（意見） この作業専用のアカウントは誰が担当しているのか、わかるようにしたほうがよい。 7月21日（対応） ***_tondabayashi_import に統一する。 7月20日（意見） データの更新は何年次くらいの間隔で、新旧shapefileを2つを比較し、その差分データをOSMに適用するというイメージか？ 7月21日（対応） 富田林市の地形図は作成日と削除日を属性として保持してるため差分データは容易に抽出できる。その差分データをOSMに適用する。更新は毎年度実施する。 7月20日（意見） CC-BY 2.1は、OSMのODbLとの互換性がないので、富田林市から許諾をいただく必要がある。担当者レベルでもよいのでOKがとれているという認識でよいか？ 7月21日（対応） 市として取り組むことであれば問題はないと認識しているため改めて富田林市からの許諾は問題ないと思う。 7月20日（意見） 提供されているデータは、公共測量のデータと明記されており測量法の制限をうける可能性が非常に高いと考える。ついては富田林市に対して、公共測量成果の利用申請が必要かと思う。過去に行われた類似の作業である浦安市、鯖江市の場合は、OSMに対して利用したデータは公共測量成果に準ずる精度で作成された、市の保有するデータと認識している。 7月21日（対応） インポート予定の道路ライン・建物については富田林市が保有するGISデータという位置付けで公開している。紛らわしいため公開ページの説明欄にある「富田林市共有基盤（公共測量成果）2015年度版」から、「（公共測量成果）」を削除する。 7月22日（意見） インポート作業は大きなインパクトをもつので、道路の階層付けなど、どこまでがシステマチックに行われ、逆に、どこまでが個人の判断で修正が行われるのか、主に想定されそうな事柄は先に話しておきたい。 7月26日（対応） Shapeファイルから区分していく手順をTagging Plansにまとめた。 7月27日（意見） 小道のhighway=footway は原則としては歩行者のみが通行できる道路だと認識している。bicycle=yes を追加すると自転車も走れる道という風に拡張することも可能。似たタグとしてhighway=pathがある。これだと歩行者に限定されず、使い勝手が良いように思うが、雰囲気的に山道ような印象も受けたりしていて難しい。 7月28日（意見） footwayとpathの違いがわかりづらい、というのは英語MLでもたまに話題になる。明確な判断基準は無いように思う。都市内の歩行者道：footway、山道など：path、という印象があり、道路周囲の状況をみて適宜判断と思っている。 8月2日 正確に（機械的に）これらを区分するのは難し。概念として幅員が1.5ｍ未満の物理的に軽自動車が通れない小道に関しては、居住区域付近の路地（highway=footway(bicycle=yes/no)）と農林業用小道（highway=path）の２種類になるものと考える。なお、富田林市では広幅員の歩行者専用道路があり、これはhighway=pedestrianとします。また、幹線道路沿いの歩道については、市のデータインポートはないので、既存のデータを残存させる。 8月15日 みなさまから頂きましたご意見に関しましては、既にWikiに反映し修正作業が終了している。今後道路データの位置修正（国道・府道）とインポート（その他道路）を開始し、順次地区割りした建物データをインポートし、年内にインポート等一連の作業を完了させる予定。 以上。 -- ** 浅野 和仁 090-2067-9293 helicobacter_y...@hera.eonet.ne.jp（メインメール） 586-0077 河内長野市南花台四丁目7-5 ** ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 国立公園 (national_park) の編集について
いいだです。 議論ありがとうございます。 追加で連絡をいただいたとのことですので、 実施者のかたからコメントをいただけることを待ちます。 2015年8月22日 11:11 ikiya insidekiwi...@yahoo.co.jp: OSMFJのikiyaです。 OSMFJ内でも今回のnational-parkさんの国立公園データのインポートについて協議致しました。 チェンジセットへのコメント送信による注意喚起、ユーザーアカウントへのOSMメール送信で直接注意を行いました。 national-parkさんから回答がなければ、現状、広域にわたるこのデータをこのまま放置はできませんのでリバートを行いたいと考えます。 - Original Message - *From:* Yoichi SEINO say.n...@gmail.com *To:* OpenStreetMap Japanese talk talk-ja@openstreetmap.org *Date:* 2015/8/21, Fri 23:57 *Subject:* Re: [OSM-ja] 国立公園 (national_park) の編集について 清野です。 この方、今夜も活発にデータを投入されているようです。 残念ながらいいださんのコメントについては気がついていないようですね。 直接メッセージを送る、という手段もまだ残ってはいますが、 緊急性を優先するなら、瀬戸さんやにしむらさんのご提案もやむを得ないのではないかと思います。 他にも奈良県内にはライセンス的にグレー、 あるいはおそらく黒いものを積極的に入れてらっしゃる方がおられますが、 何度もコンタクトは取ろうとしておりますが、 返事はもらえた試しがありません。 こういう方とどうコミュニケーションを取っていくかは悩ましいところです。 荒っぽいやり方はではありますが、 ひとまずリバートするしかないのかもしれま せん。 最後の手段であり悲しいですが…。 2015/08/20 22:35 Yuichiro Nishimura nissy...@gmail.com: ならのにしむらです 下記についてですが，ライセンス的にOSMに投入できるかどうかという議論以前に，インポートのガイドライン・手続きを介していないインポートは大変問題であるように思います http://wiki.openstreetmap.org/wiki/JA:インポート/ガイドライン ひとまず削除してから，それでもなお必要なデータということであれば，インポートに関するwikiの整備，ローカルコミュニティにおける議論，データ所有者からのライセンス上の承認を得ること，imports MLへのレビュー依頼，などの手順を踏んで，その後インポートを行う必要があると思います． この面からも瀬戸さんが提起したリバート案に賛成です． 2015/08/20 22:12、Toshikazu SETO toss...@gmail.com のメール： 瀬戸です。 正確にはオープンデータの類とは異なるデータセットであること（OSMのライセンスとは相容れないので、積極的に残す理由が現状ない） 研究で以前利用したこともあるのですが、本データが他のデータに勝るような正確性があるかというと、個人的な感触ではそうでもない点 から、特にデータインポートに関する議論を経ずに行われた作業に対してライセンス的に疑念があるものであれば、リバートすることが現実的でないかと思います。 2015年8月17日月曜日、Satoshi IIDAnyamp...@gmail.comさんは書きました: いいだです。 遅くなってしまいましたが、変更セットへのコメントを行っています。 https://www.openstreetmap.org/changeset/33048672 2015年8月11日 9:22 Satoshi IIDA nyamp...@gmail.com: いいだです。 ありがとうございます。 ライセンス互換性、個別の許可の取得 なるほど、個別の許諾交渉というのはひとつの手かもしれませんね。 環境省生物多様性センターさんに知り合いはいないので、 正面からあたってみるしかないかんじですが、、、 OSMFJとして行うか、個人として行うかは別として、ちょっと検討してみます。 （事後報告になっちゃうのはかなり厳しい気がしています） 政府標準利用規約をCC-BY互換に改定 はい、議論の俎上にあがる可能性が高いと伺っています。 ただ、ライセンス変更の結果がでるのは早くても今年度末かと思いますので、 待つのはちょっと厳しいかなぁ、とも感じています。 # CC-BY 4.0互換（2.1 JPではなく）になると、 # OSMでも利用できる可能性が高くなることもあり、 # 委員会での議論の行方は僕もたいへん注目しています。 トレースについて これも、調製をおこなった地図（作品）の利用にあたるかと思いますので、 調製された主体に確認が必要ですね。環境省さんかぁ。。。 海上の公園について 明確に議論がされたことは無いと思っています。 海岸線を1km延伸した海上部分も含めたほうがよい、ということで、納得しました。 できれば、インポート作業されたかたの意見も伺いたいなぁ。。。 2015年8月9日 17:42 centree oki_aic...@yahoo.co.jp: centree です。 私も詳しくありませんが… (1) ライセンスについて 政府標準利用規約というのがあるのですね。恥ずかしながら存じ上げませんでした。 http://www.biodic.go.jp/trialSystem/info/nps.html この辺のデータをコンバートして投入したいなら、確かに量も量ですし、OSMFJで許諾をとって頂いておいた方が安心かと思います。 OSMはそんなに黒い（？）要途を主な目的としてはいないと思うので、交渉や問い合わせは可能なのではないかと思いますが 確かにOSMに投入すると、後の用途は限っていませんので『公序良俗』に照らし合わせ、どのように判断がでるかは未知数ですね。 ちなみに、もし、上記のような生のデータではなく、 http://www.env.go.jp/park/yakushima/intro/files/area_3.pdf のようなP DF媒体からのトレースということになると、背景画に承認番号付きの地理院の地図が使われているので 地図タイルのトレースのみが許諾されているOSMへの投入はNGなのではないかなと思います。 (2)海上の公園について 国立公園の資料を見ると、海上もしっかり公園と称されているようなので、基本的には含めるべきなのかなと思います。 ただ、瀬戸内海国立公園なんかは範囲も広く、なかなかスケールの大きい作業になりそうですが… centree - Original Message - From: tomoya muramoto muramototom...@gmail.com To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2015/8/9, Sun 15:19 Subject: Re: [OSM-ja] 国立公園 (national_park) の編集について muramotoです。 インポートやライセンス関係には不案内なため、類似の経験をお持ちの方のご意見を待ちたいところですが、ざっと調べた上での所感です。 (1)ライセンスについて ・環境省生物多様性センターのライセンスは、ご指摘のとおり、利用用途に制限があるようです(「公序良俗」制限)。一方でODbLには利用用途に制限がないようです。ODbLのほうが緩いので、使えないのではないかと思います。 ・そのため、データをOSMで利用する場合は、個別に許諾を得る必要があると思います。例えば、国土地理院はGSImaps利用のライセンスで「公序良俗」の制限を課していますが、大変有難いことにOSMFJの方が個別に許諾を取っていただいたとのことなので、私は安心してデータを利用させていただ いております。 http://wiki.openstreetmap.org/wiki/JA:GSImaps ・もしくは、政府標準利用規約をCC-BY互換に改定しようという動きもあるようなので、その結果を待つのもひとつの手だとは思います。 https://www.kantei.go.jp/jp/singi/it2/densi/kwg/dai2/siryou2.pdf (細かいですが、環境省生物多様性センターのライセンスは政府標準利用規約（第1.0版）に準拠のようです。) (2)海上の公園について ・海上が国立公園として指定されている(海域公園地区または普通地域)のであれば、海上も範囲に含めるべきだと思います。国立公園では、海岸から1kmまで「普通地域」として指定されているようです。 ・過去の議論において、海上を含めるのは不都合であるという結論に達したのであれば、それに従って良いと考えますが、個人的には議論の流れを知りたいとは思います。 2015年8月8日 22:31 Satoshi IIDA nyamp...@gmail.com: いいだです。 国立公園のデータについて、インポート、あるいはトレースを行っているような形跡が見受けられました。 例えば、この編集です。 https://www.openstreetmap.org/changeset/33048672 この編集には、いくつかの問題があります。 1. 議論がされていない talk-ja, imports、どのメーリングリストにも、事前の相談が行われていません。 2. ライセンスの互換性 ライセンスを確認すると、政府標準利用規約(ver. 1.1)のようです。 しかしながら、その互換性については、いまだ議論が行われておらず、 インポート作業を行うには、法的な互換性が保たれていることが必要かと思っています。 （いわゆる、3条ア 公序良俗条項、のところがメインです） 逆に言えば、ここが担保されていれば、多くのデータが利用可能になります。 議論をし、互換性について議論したいです。 ■方針について データ自体については、有用なデータだと感じていますので、 できれば使い続けたいと考えています。 ただし、海の上にまで公園の範囲が及んでしまうなど、 疑問点がいくつかありますので、1. の、議論が行われていない、のが いちばんつらいところだな、と感じています。 （以前に台灣で、同じように海上にも及んでしまう公園が設定されて、
Re: [OSM-ja] Tondabayashi/Road Building importについて
いいだです。 状況報告ありがとうございます。 今後、wikiの英訳とimports MLへの投稿も必要です。 ここまでくれば開始まであとすこしかと思います。 お手数ですが、よろしくお願いします m(_ _)m 2015年8月22日 13:57 浅野和仁 helicobacter_y...@hera.eonet.ne.jp: 富田林市の浅野です。 富田林市地形図のOSMへのインポートについて、数々のご意見をいただきありがとうございます。 これまでのご意見と、それに対する対応について、以下のような経過と理解しています。Wikiにつきましても、ご意見の都度修正を行い、ご意見に対応する修正は完了しています。 今後、道路及び建物データの既存修正並びにインポート作業を実施し、2015年内にはインポートを終了させたいと考えています。 7月19日（提案） 富田林市として市内の各施設の案内サイトについて、27年度に背景地図をOSMに移行し、行政各事務に利用する地図や、市民や事業者から市への申請に利用される地図についてもOSMを推奨する計画を説明する。市が保有する地形図をクリエイティブ・コモンズ（CC-BY2.1JP）のライセンスに則って公開し、OSMに移植する作業は地域関係者が個人として行う。今後、毎年度の地形図差分（CC-BY）を用いて定期的な更新も予定している。 7月20日（意見） yh:widthはwidthに入れて良いのではないか。oneway=noは何も入力されていなければoneway=noとみなされる。道路データの向きも一方通行の向きと合っているのか。 7月20日（対応） 「oneway=yes」のみ対応する。市内のすべての一方通行の方向を把握している。 7月20日（意見） widthに「〜」を含む値を入れるのは適切ではないのでest_width等どうか？ 7月20日（対応） 「width」は通行形態（車両通行不可、軽車両のみ、対面1車線、同2車線、4車線等）を代表する数値として「yh:width」と同様の幅員区分で整理していたもの。OSMではそれらに対応するものとしてはhighwayが近いように思うので、インポートデータのwidth値を参照しながら、highwayを設定する。 7月20日（意見） 道路と建物の作業を同時に進めるより、道路、建物の順にして、Phase 1として道路、Phase 2で建物とフェーズを記載しておくと良い。 7月21日（対応） インポートする道路ラインと建物形状は、既に相互の位置関係は適正化しているため、どちらが先行しても問題はない。ただ、多くの方にご協力いただくことを前提とすれば、道路を優先するという順番を原則として進める。 7月20日（意見） 道路中心線および建物データには最低限のタグしか付与されていない。一方既存の建物にはname や building:levelなどがあり、インポート作業の際に既存データから転記を行うという手順か？ 7月21日（対応） 既存のデータのTagに関しては、最大限に尊重して転記する。 7月20日（意見） 道路データにhighwayのキーに対する値が入っていない。これは、既にOSMに入っているデータから移植するということでよいか？ また、国道・県道のrouteリレーションに対する作業を行う必要もある。道路を削除する必要がある場合には、このリレーションについても考慮すること。 7月21日（対応） highwayは、既存データ並びにインポートデータのWidthデータを参照して校正する。国道・府道・主要地方道は、既存データを優先しインポートデータはその位置修正の参考として利用する。 7月20日（意見） この作業専用のアカウントは誰が担当しているのか、わかるようにしたほうがよい。 7月21日（対応） ***_tondabayashi_import に統一する。 7月20日（意見） データの更新は何年次くらいの間隔で、新旧shapefileを2つを比較し、その差分データをOSMに適用するというイメージか？ 7月21日（対応） 富田林市の地形図は作成日と削除日を属性として保持してるため差分データは容易に抽出できる。その差分データをOSMに適用する。更新は毎年度実施する。 7月20日（意見） CC-BY 2.1は、OSMのODbLとの互換性がないので、富田林市から許諾をいただく必要がある。担当者レベルでもよいのでOKがとれているという認識でよいか？ 7月21日（対応） 市として取り組むことであれば問題はないと認識しているため改めて富田林市からの許諾は問題ないと思う。 7月20日（意見） 提供されているデータは、公共測量のデータと明記されており測量法の制限をうける可能性が非常に高いと考える。ついては富田林市に対して、公共測量成果の利用申請が必要かと思う。過去に行われた類似の作業である浦安市、鯖江市の場合は、OSMに対して利用したデータは公共測量成果に準ずる精度で作成された、市の保有するデータと認識している。 7月21日（対応） インポート予定の道路ライン・建物については富田林市が保有するGISデータという位置付けで公開している。紛らわしいため公開ページの説明欄にある「富田林市共有基盤（公共測量成果）2015年度版」から、「（公共測量成果）」を削除する。 7月22日（意見） インポート作業は大きなインパクトをもつので、道路の階層付けなど、どこまでがシステマチックに行われ、逆に、どこまでが個人の判断で修正が行われるのか、主に想定されそうな事柄は先に話しておきたい。 7月26日（対応） Shapeファイルから区分していく手順をTagging Plansにまとめた。 7月27日（意見） 小道のhighway=footway は原則としては歩行者のみが通行できる道路だと認識している。bicycle=yes を追加すると自転車も走れる道という風に拡張することも可能。似たタグとしてhighway=pathがある。これだと歩行者に限定されず、使い勝手が良いように思うが、雰囲気的に山道ような印象も受けたりしていて難しい。 7月28日（意見） footwayとpathの違いがわかりづらい、というのは英語MLでもたまに話題になる。明確な判断基準は無いように思う。都市内の歩行者道：footway、山道など：path、という印象があり、道路周囲の状況をみて適宜判断と思っている。 8月2日 正確に（機械的に）これらを区分するのは難し。概念として幅員が1.5ｍ未満の物理的に軽自動車が通れない小道に関しては、居住区域付近の路地（highway=footway(bicycle=yes/no)）と農林業用小道（highway=path）の２種類になるものと考える。なお、富田林市では広幅員の歩行者専用道路があり、これはhighway=pedestrianとします。また、幹線道路沿いの歩道については、市のデータインポートはないので、既存のデータを残存させる。 8月15日 みなさまから頂きましたご意見に関しましては、既にWikiに反映し修正作業が終了している。今後道路データの位置修正（国道・府道）とインポート（その他道路）を開始し、順次地区割りした建物データをインポートし、年内にインポート等一連の作業を完了させる予定。 以上。 -- ** 浅野 和仁 090-2067-9293 helicobacter_y...@hera.eonet.ne.jp（メインメール） 586-0077 河内長野市南花台四丁目7-5 ** ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-talk] The Proposed Great Colour Shift
On Fri, Aug 21, 2015 at 5:13 AM, Colin Smale colin.sm...@xs4all.nl wrote: While we are at it, what about specific symbols for train/metro stations per operator? That is also a great landmark for map users. I'd settle for the transit map acknowledging that colour=* is a tag that exists for exactly the purpose of rendering transit maps, as it would make dealing with some systems (MTTA in Tulsa and especially TriMet in Portland come immediately to mind) easier to read and line up with the real world situation. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-be] Meetup
Ruben Maes wrote: As part of the still ongoing manual welcome new mappers effort, I just welcomed Ruben. He joined the Meetup group and would like to attend one. Any plans for an upcoming one? Haha, this is funny. Just subscribed to this list. I should mention I have exams until the 1st of September and I'm probably leaving for a holiday too. Keep me posted ;-) Greetings, Ruben -- The field from of an email is about as reliable as the address written on the back of an envelope. Use OpenPGP to verify that this message is sent by me. You can find my public key in the public directories, like pool.sks-keyservers.net. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Ich sehe wenig Nutzen in einer Detaildiskussion zu jedem Sonder- und Grenzfall, den es auf der Welt gibt. Es bleibt für mich bei dem, was ich Eingangs gesagt habe: es wäre schön, wenn Alle ein bisschen mehr drauf achten würden, beim Tagging von Wasserläufen das richtige Tag auszuwählen. Beispiele siehe mein Overpass-Link. Dass man bei Grenzfällen keine Doktorarbeit draus machen muss versteht sich denke ich von selbst. Über 90% der gezeigten Fälle sind jedoch denke ich völlig klar und eindeutig. OSM wird häufiger für Kartendarstellungen als zu Strukturanalysen des Gewässernetzwerkes verwendet. Das Tagging sollte sich m.E. eher an den Bedürfnissen der Hauptnutzung orientieren. Eben, und gerade deshalb ist die Unterscheidung künstlich-natürlich ja so wichtig. Ich habe es schon vielfach gesagt - eine konsistente und gut lesbare Darstellung von Gewässern in Karten gibt es nur mit Kenntnis der Struktur des Flussnetzwerkes. Selbst wenn alle Mapper anfangen würden, mit Messlatten durch Flüsse zu waten wäre das kein Ersatz. -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Bächen als waterway=ditch
On Friday 21 August 2015, Stephan Wolff wrote: Am 20.08.2015 14:20, schrieb Christoph Hormann: natürlich (also waterway=river/stream und ggf. waterway=riverbank bzw. water=river für das Polygon): es hat vor den menschlichen Eingriffen einen Wasserlauf gegeben, der im Verlauf und in seinem Einzugsgebiet dem jetzigen ähnelt. Der Nord-Ostsee-Kanal ersetzt die Eider zwischen Flemhuder See und Rendsburg. Er nimmt das Wasser der Obereider und aller ehemaligen Zuflüsse auf. Ist dieser Abschnitt ein natürliches Gewässer? Normalerweise lassen sich solche Fälle recht gut auf Grundlage der waterway-Relationen auflösen (meines Erachtens nach ist das der Hauptnutzen von diesen). Leider ist die Eider diesbezüglich seit einiger Zeit etwas amputiert: http://www.openstreetmap.org/relation/407956 Funktionieren tut das hingegen zum Beispiel bei der Rhone: http://www.openstreetmap.org/relation/1075117 welche - soweit ich mich erinnere - auch über diverse als Kanal getaggte Abschnitte verfügt. -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] rôle/fonctionnement de layers.openstreetmap.fr ?
Bonjour, On Fri, Aug 21, 2015 at 08:51:32AM +0200, Art Penteur wrote: Il y a quelque temps, à l'url http://layers.openstreetmap.fr/, on accédait à une carte, avec plusieurs couches disponibles, dont celle liée à BANO. Le fonctionnement ancien était un coup de chance (on tombait sur un service qui n'était pas destiné à être ouvert/maintenu), ou alors le fonctionnement actuel est une panne ? C'est une panne temporaire. En fait, les DNS ont été changé, et layers.openstreetmap.fr ne pointe plus sur la bonne machine. On corrige ça dès que possible. -- Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-be] Meetup
As part of the still ongoing manual welcome new mappers effort, I just welcomed Ruben. He joined the Meetup group and would like to attend one. Any plans for an upcoming one? -- The field from of an email is about as reliable as the address written on the back of an envelope. Use OpenPGP to verify that this message is sent by me. You can find my public key in the public directories, like pool.sks-keyservers.net. signature.asc Description: This is a digitally signed message part. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] The Proposed Great Colour Shift
sent from a phone Am 20.08.2015 um 11:59 schrieb Paweł Paprota ppa...@fastmail.fm: What you are proposing is basically design by committee (https://en.wikipedia.org/wiki/Design_by_committee) which is rampant everywhere in OSM and kills innovation. without advocating it, this can also work. The building of the German parliament comes to mind (Reichstag). Sir Foster had won the competition for the restructuring in the 1990ies, but with a complete different design (basically a huge roof covering the building and its surroundings, by the time referred to as Germany's biggest petrol station by some critics). After intervention of the parliament against this winning design, chosen by a committee of experts amongst all contributions to the competition, there was a longer process during which tens of different cupolas were presented and rejected, and after some iterations the actual design evolved. Foster had originally been against a new cupola but in the end the final design (heavily influenced by a committee) was widely acclaimed. There's few rules without exception ;-) cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] guichet
*entrance=yes* ou *main *dans ton cas c'est ok. Tu peux avoir plusieurs entrées principales c'est pas un problème. C'est le cas des supermarchés aussi. Ce qui correspond le mieux à ton cas c'est office http://wiki.openstreetmap.org/wiki/Key:office=travel_agent http://wiki.openstreetmap.org/wiki/Tag:office%3Dtravel_agent en point ou polygone. Si c'est un automate: amenity http://wiki.openstreetmap.org/wiki/Key:amenity=*vending_machine* vending http://wiki.openstreetmap.org/wiki/Key:vending =public_transport_tickets J'espère que ça répond à ton besoin. Jérôme Le 21 août 2015 15:57, Florian LAINEZ winner...@free.fr a écrit : Hello, Je relance cette discussion sans avoir eu de réponse et élargi ma question : comment taguer le point d'accès (l'endroit où le service est disponible) à un service qui s'applique à un polygone ? J'utilise entrance=main mais je trouve cela vraiment crade. Merci Le 22 avril 2015 10:57, Florian LAINEZ winner...@free.fr a écrit : Hello, J'ai un problème pour décrire ce guichet de gare https://www.openstreetmap.org/way/319273556 qui est aussi en photo ici https://plus.google.com/photos/+FlorianLainez/albums/6132374967150818465/6132375082657315010?authkey=CMXipZ3g7bTdOgpid=6132375082657315010oid=111005261746474513881#photos/+FlorianLainez/albums/6132374967150818465/6132375082657315010?authkey=CMXipZ3g7bTdOgpid=6132375082657315010oid=111005261746474513881 . En gros j'ai 3 éléments : - le polygone qui décrit la salle dans laquelle il y a le guichet : Building:part=room et tourism=information - un point sur ce polygone qui est l'entrée de service en bas : entrance=service et access=no - un point sur ce polygone qui est le guichet en lui-même, donc le point d'accès au service pour le public : pour l'instant je l'ai taggé entrance=main et access=yes mais cela ne me convient qu'à moitié car cela laisse penser que l'on peut entrer dans la pièce alors que ce n'est pas le cas. Je sais que vous allez me proposer de créer un point tourism=information séparé du polygone mais cela ne convient pas car ça ne décrit pas précisément la réalité. Une autre solution peut être ? Merci -- *Florian Lainez* @overflorian http://twitter.com/overflorian -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] The Proposed Great Colour Shift
On Friday 21 August 2015, Martin Koppenhoefer wrote: What you are proposing is basically design by committee (https://en.wikipedia.org/wiki/Design_by_committee) which is rampant everywhere in OSM and kills innovation. without advocating it, this can also work. The building of the German parliament comes to mind (Reichstag). [...] Oh, if we only had that kind of budget... (just for reference: that was 600 Million D-Mark back then) -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] talk Digest, Vol 132, Issue 47
hi im sorry Was troubled I talk with you later. Thanks On Fri, Aug 21, 2015 at 4:30 PM, talk-requ...@openstreetmap.org wrote: Send talk mailing list submissions to talk@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/talk or, via email, send a message with subject or body 'help' to talk-requ...@openstreetmap.org You can reach the person managing the list at talk-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of talk digest... Today's Topics: 1. Re: The Proposed Great Colour Shift (Martin Koppenhoefer) 2. Re: The Proposed Great Colour Shift (Martin Koppenhoefer) -- Message: 1 Date: Fri, 21 Aug 2015 12:56:06 +0200 From: Martin Koppenhoefer dieterdre...@gmail.com To: Paweł Paprota ppa...@fastmail.fm Cc: talk@openstreetmap.org talk@openstreetmap.org Subject: Re: [OSM-talk] The Proposed Great Colour Shift Message-ID: 2131db94-30a6-4dd9-bfb5-c7b975288...@gmail.com Content-Type: text/plain; charset=utf-8 sent from a phone Am 20.08.2015 um 11:59 schrieb Paweł Paprota ppa...@fastmail.fm: What you are proposing is basically design by committee (https://en.wikipedia.org/wiki/Design_by_committee) which is rampant everywhere in OSM and kills innovation. without advocating it, this can also work. The building of the German parliament comes to mind (Reichstag). Sir Foster had won the competition for the restructuring in the 1990ies, but with a complete different design (basically a huge roof covering the building and its surroundings, by the time referred to as Germany's biggest petrol station by some critics). After intervention of the parliament against this winning design, chosen by a committee of experts amongst all contributions to the competition, there was a longer process during which tens of different cupolas were presented and rejected, and after some iterations the actual design evolved. Foster had originally been against a new cupola but in the end the final design (heavily influenced by a committee) was widely acclaimed. There's few rules without exception ;-) cheers Martin -- Message: 2 Date: Fri, 21 Aug 2015 12:56:06 +0200 From: Martin Koppenhoefer dieterdre...@gmail.com To: Paweł Paprota ppa...@fastmail.fm Cc: talk@openstreetmap.org talk@openstreetmap.org Subject: Re: [OSM-talk] The Proposed Great Colour Shift Message-ID: 2131db94-30a6-4dd9-bfb5-c7b975288...@gmail.com Content-Type: text/plain; charset=utf-8 sent from a phone Am 20.08.2015 um 11:59 schrieb Paweł Paprota ppa...@fastmail.fm: What you are proposing is basically design by committee (https://en.wikipedia.org/wiki/Design_by_committee) which is rampant everywhere in OSM and kills innovation. without advocating it, this can also work. The building of the German parliament comes to mind (Reichstag). Sir Foster had won the competition for the restructuring in the 1990ies, but with a complete different design (basically a huge roof covering the building and its surroundings, by the time referred to as Germany's biggest petrol station by some critics). After intervention of the parliament against this winning design, chosen by a committee of experts amongst all contributions to the competition, there was a longer process during which tens of different cupolas were presented and rejected, and after some iterations the actual design evolved. Foster had originally been against a new cupola but in the end the final design (heavily influenced by a committee) was widely acclaimed. There's few rules without exception ;-) cheers Martin -- Subject: Digest Footer ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- End of talk Digest, Vol 132, Issue 47 * ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] rôle/fonctionnement de layers.openstreetmap.fr ?
OK. Merci à tous. Art. Le 21 août 2015 13:00, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit : Bonjour, On Fri, Aug 21, 2015 at 08:51:32AM +0200, Art Penteur wrote: Il y a quelque temps, à l'url http://layers.openstreetmap.fr/, on accédait à une carte, avec plusieurs couches disponibles, dont celle liée à BANO. Le fonctionnement ancien était un coup de chance (on tombait sur un service qui n'était pas destiné à être ouvert/maintenu), ou alors le fonctionnement actuel est une panne ? C'est une panne temporaire. En fait, les DNS ont été changé, et layers.openstreetmap.fr ne pointe plus sur la bonne machine. On corrige ça dès que possible. -- Jocelyn ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-legal-talk] GADM license - any news?
I found an interesting dataset commonly called Berkely GADM (http://www.gadm.org) and containing containing global administrative areas. It has a very pour and short license (or a wannabe-license) that says: - - - - - - This dataset is freely available for academic and other non-commercial use. Redistribution, or commercial use, is not allowed without prior permission. - - - - - - It is really too vague. But it is quite clear that the non commercial restriction makes this dataset not usefull for OSM. In the http://wiki.openstreetmap.org/wiki/Potential_Datasources page of the OSM wiki I found a comment posted in 2009 that says: - - - - - - I'll investigate the part containing global administrative areas (but called GADM). It seems to be very useful, because administrative boundaries are missing for large parts of the world. One table in the geodatabase (MS Access) contains information on copyright for every country. I'll try to contact one of the persons at Berkeley, and ask if they agree to lift the NC restriction for OSM. - - - - - - Do you know if any news have come in these six years? Do you know if OSM received a sort of direct permission to include those data in the OSM database? Another interesting issue is that Naturalearthdata.com (http://www.naturalearthdata.com/) includes the GADM dataset as a source of data (see http://www.naturalearthdata.com/downloads/10m-cultural-vectors/10m-admin-1-states-provinces/). But Naturalearthdata.com release ALL ITS DATA as public domain. So... something is missing in the workflow. Any ideas/suggestions? Thanks very much. Simone -- Simone Aliprandi - http://www.aliprandi.org | http://www.array.eu ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-us] Tagging National Forests
Uncle. Forests are not to be tagged forests. Tag as you like, everybody. We have a lot of work to do in this project. I'm now leaving for a national forest to recreate. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-at] Graz+Innsbruck: »Schiene und Straße wurden getrennt«
Hallo Jonathan! Du wurdest darauf hingewiesen, dass es schon eine Diskussion gab zum Lagegenauen Mappen von Schienen in Graz (Zusammenfassung unterhttp://wiki.openstreetmap.org/wiki/WikiProject_Austria/Stra%C3%9Fenbahnen#Stra.C3.9Fenbahnen_Graz), und auch die derzeitige Diskussion zeigt nicht, dass sich am Konsens etwas gendert hast, und trotzdem fngst du an die Schienen aufzutrennen?(Changeset:https://www.openstreetmap.org/changeset/33464314). Hier sind nun also die Schienen neben der Strae, obwohl sie in Wirklichkeit direkt auf der Fahrbahn sind? Bereits zuvor war die Lage der Schienen in der Gstinger Strae eindeutig (lanes=2, tracks=2), derVorteil erschliet sich mir also nicht. Auch bei komplizierteren Lagen kommt man mit tracks:lanes sehr weit. Wenn es nur um die Darstellung auf der Startseite geht, dann widerspricht das einem Grundprinzip von OSM: Wir taggen nicht fr den Renderer. Andreas PS:Dass das mit den selben Nodes fr getrennte Straen und Schienen schwierig ist, hast du selbst hier bewiesen:https://www.openstreetmap.org/way/30478743 Gesendet:Donnerstag, 20. August 2015 um 11:18 Uhr Von:Jonathan Gallagher gallag...@mentzdv.de An:talk-at@openstreetmap.org Betreff:Re: [Talk-at] Graz+Innsbruck: Schiene und Strae wurden getrennt Hallo Simon, ich gebe dir grundstzlich Recht, dass es problematisch ist zwei bereinander liegende Kanten im Editor schnell zu erkennen und voneinander zu unterscheiden. Auch sehe ich ein, dass meine Edits nicht ganz den (zuletzt am 3.12.2014 [1]) aktualisierten Richtlinien entsprechen. Ich habe es eher als einen ersten Schritt gesehen, einmal Strae von Schiene zu trennen, bevor man dazu bergehteine eigene Kante fr jede Fahrtrichtung der Tram zu mappen und die Fahrbahn fr Auto/Bus etc. entsprechend [1] auszurichten. Dass zu [1] scheinbar keine Diskussion stattfand, war mir nicht bewusst. Allerdings erscheint mir die Methode sinnvoll und abgesehen von Graz und Innsbruck wird sie meines Wissens inzwischen auch berall im deutschsprachigen Raum angewandt. Da die Mehrheit (und damit nehme ich auch Bezug auf den neuen Beitrag von Michael) mit den bereinander liegenden Kanten nicht glcklich zu seinscheint, will ich mich anbieten sie gem [1] neu zu mappen. Sprich: - Wo sich zweispurige Tramgleise mit dem Straenverkehr diesselbe Spur teilen, werden die zwei Gleise einzeln gemappt (mittig der Gleise) und die Strae als Kante dazwischen (siehe zb. Taborstrae, Wien [2]) - Wo zweispurige Tramgleise von Straen in beide Fahrtrichtungen umschlossen sind, werden die Gleise einzeln gemappt (mittig der Gleise) und die beiden Straen- fahrbahnen beidseitig davon (siehe zb. Rennweg, Wien [3]) - Wo Tramgleise einspurig verlaufen und sich mit Bus/Auto die Spur teilen, werden beide Spuren einzeln UND LEICHT VERSETZT GEMAPPT(?) (siehe zb. Taborstrae, Wien [4]) ODER MIT DENSELBEN NODES (?) Was sind die Meinungen hierzu? Die Zuordnungsfehler im Tagging, die Michael dazu veranlasst haben meine Edits zu reverten, bedaure ich. Ich werde in Zukunft besser darauf achten, dass mir sowas nicht passiert. Grundstzlich sehe ich es voll und ganz ein, dass sich einigegestrt fhlen, wenn jemand von auen (ich bin Wiener) nderungen vornimmt, ohne sich davor mit der lokalen Community abzusprechen. Das habe ich aus schlichter Unerfahrenheit verabsumt und hoffe auf eure Nachsicht. Der Stammtisch nchsten Montag, kommt etwas knapp. Bin mir nicht sicher, ob sich das fr mich ausgeht. Ansonsten bitte ich um eure Meinung hier in der Mailinglist. Gre, Jonathan [1]https://wiki.openstreetmap.org/w/index.php?title=DE:Tag:railway%3Dtramdiff=nextoldid=1112007 [2]https://www.openstreetmap.org/#map=19/48.21670/16.38187 [3]https://www.openstreetmap.org/#map=19/48.19637/16.38224 [4]https://www.openstreetmap.org/#map=19/48.21306/16.38046 Date: Wed, 19 Aug 2015 22:12:48 +0200 From: simon.leg...@gmail.com To: talk-at@openstreetmap.org CC: gallag...@mentzdv.de Subject: Re: [Talk-at] Graz+Innsbruck: Schiene und Strae wurden getrennt Hallo Jonathan, mir ist nicht klar, nach welchem der Punkte von der Wiki-Seite (welche im September 2014 ohne einer mir bekannten vorausgegangenen Diskussion und unabhngig von der englischen Seite gendert wurde [1]) du in Innsbruck und Graz vorgegangen bist. Auf der Seite heit es: Wo Trams zweispurig auf einer Strae verlaufen, die baulich nicht in Richtungsfahrbahnen getrennt ist, werden die Tramlinien als zwei Linien (jeweils in der Mitte der einzelnen Gleise) gezeichnet und die Strae als Linie dazwischen. Die Prmisse ist fr den Groteil in Innsbruck und Graz erfllt. Also msste die Straenbahngleise vllig unabhngig von der (dazwischen liegenden) Strae gemappt werden. Soweit ich das gesehen habe, hast du die Schiene deckungsgleich mit der Strae erfasst und die gleichen Knoten verwendet. Fr eine Pflege von einem der beiden Objekte halte ich das sehr unpraktisch, weil man zuerst feststellen muss, dass es zwei
Re: [Talk-at] Grenzimport Wien
Jens Steinhauser schrieb: * Als Quelle gibt er bei einigen Changesets [2] an. Der Datensatz steht unter CC BY 3.0 AT, ich kenne mich mit den Lizenzen nicht s gut aus, bin mir aber nicht sicher ob der Import so ohne weiteres moeglich ist ([3]). CC-BY 3.0 AT sollte kein Problem sein. CC-BY-SA 3.0 AT ist allerdings inkompatibel. Das SA macht den Unterschied. KaiRo ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] guichet
Hello, Je relance cette discussion sans avoir eu de réponse et élargi ma question : comment taguer le point d'accès (l'endroit où le service est disponible) à un service qui s'applique à un polygone ? J'utilise entrance=main mais je trouve cela vraiment crade. Merci Le 22 avril 2015 10:57, Florian LAINEZ winner...@free.fr a écrit : Hello, J'ai un problème pour décrire ce guichet de gare https://www.openstreetmap.org/way/319273556 qui est aussi en photo ici https://plus.google.com/photos/+FlorianLainez/albums/6132374967150818465/6132375082657315010?authkey=CMXipZ3g7bTdOgpid=6132375082657315010oid=111005261746474513881#photos/+FlorianLainez/albums/6132374967150818465/6132375082657315010?authkey=CMXipZ3g7bTdOgpid=6132375082657315010oid=111005261746474513881 . En gros j'ai 3 éléments : - le polygone qui décrit la salle dans laquelle il y a le guichet : Building:part=room et tourism=information - un point sur ce polygone qui est l'entrée de service en bas : entrance=service et access=no - un point sur ce polygone qui est le guichet en lui-même, donc le point d'accès au service pour le public : pour l'instant je l'ai taggé entrance=main et access=yes mais cela ne me convient qu'à moitié car cela laisse penser que l'on peut entrer dans la pièce alors que ce n'est pas le cas. Je sais que vous allez me proposer de créer un point tourism=information séparé du polygone mais cela ne convient pas car ça ne décrit pas précisément la réalité. Une autre solution peut être ? Merci -- *Florian Lainez* @overflorian http://twitter.com/overflorian -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [talk-au] Unauthorised bike trails in national parks
fors...@ozonline.com.au schrieb: Hi What (if any) is the correct tagging for unauthorised trails in national and state parks? For example, Ant Track https://www.openstreetmap.org/#map=18/-37.92599/145.32051 I have spoken with Parks Vic and they request that bike riders do not create additional trails and only use official trails. They would prefer if such unofficial trails were not mapped or named because it implies official status to park users. I think its hardly possible in OSM. At last: a trail is a trail. May be the Parks itself should add - aside access=no - a new tag for track-sections like surcharge=180 Dollar, bitcoin or else, or neutral surcharge=yes may be with any symbol, on the part of osm. Its more a matter of the Parks than OSM. best, t. I have not yet worked out how to contact the author of Ant Track. Thanks Tony ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-at] Grenzimport Wien
Hallo, On 08/21/2015 03:13 PM, Robert Kaiser wrote: * Als Quelle gibt er bei einigen Changesets [2] an. Der Datensatz steht unter CC BY 3.0 AT, ich kenne mich mit den Lizenzen nicht s gut aus, bin mir aber nicht sicher ob der Import so ohne weiteres moeglich ist ([3]). CC-BY 3.0 AT sollte kein Problem sein. Das ist in dieser Allgemeinheit leider nicht richtig. CC-BY gibt dem Lizenzgeber weitreichende Freiheit, wie er die ihm zustehende Namensnennung einfordert. Er *könnte* beispielsweise fordern, dass auf jeder Karte, die mit seinen Daten gemacht wird, unten sein Name steht. Sowas können wir nicht erfüllen - wir können nur bieten, dass man es am Changeset-Kommentar in der History sieht oder am Source-Tag (dessen Bestand wir nicht garantieren können) usw. Daher muss im Einzelfall mit dem CC-By-Lizenzgeber geklärt werden, ob er einverstanden ist. Das ist zwar eine Hürde für Importe, aber ich finde das gar nicht schlecht, so sieht man wenigstens, ob der Importeur sich Gedanken gemacht hat oder nicht ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-legal-talk] GADM license - any news?
On 8/21/2015 7:41 AM, Simone Aliprandi wrote: Do you know if any news have come in these six years? Do you know if OSM received a sort of direct permission to include those data in the OSM database? GADM is still under a non-commercial license. I don't know who said they were going to investigate, so you'd have to ask them, but I doubt anything came of it. Independently of that, we got permission for some datasets from GADM after the fact of a bad import, but this does not mean we can import anything new. Another interesting issue is that Naturalearthdata.com (http://www.naturalearthdata.com/) includes the GADM dataset as a source of data (see http://www.naturalearthdata.com/downloads/10m-cultural-vectors/10m-admin-1-states-provinces/). But Naturalearthdata.com release ALL ITS DATA as public domain. So... something is missing in the workflow. Any ideas/suggestions? I don't see anything that says the admin 1 theme is derived from GADM. I can see it listed in resources, but that's not a list of sources. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-at] Grenzimport Wien
Kevin Kofler schrieb: Robert Kaiser wrote: CC-BY 3.0 AT sollte kein Problem sein. CC-BY-SA 3.0 AT ist allerdings inkompatibel. Das SA macht den Unterschied. In diesem Fall ist es aber eh CC-BY ohne SA. Ja, der Mailing-Listen-Verweise war zu einer Diskussion über eine SA-Quelle. Zu Frederiks Bemerkung, das ist gut zu wissen, von wien.at (Stadt Wien) wissen wir, dass das Einverständnis für die Verwendung bzw. unsere Art der Nennung da ist. KaiRo ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] guichet
À défaut, wicket=yes ? Le 21/08/2015 18:15, Florian LAINEZ a écrit : je n'ai rien trouvé dans les tags indoor malheureusement : http://wiki.openstreetmap.org/wiki/Indoor_Mapping#Tags_in_use http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging Mon guichet ressemble à ça : http://images.midilibre.fr/images/2012/01/25/l-avenir-des-guichets-de-la-gare-sncf-menace_354067_510x255.jpg Il y a donc potentiellement plusieurs guichets donc plusieurs points d'accès au service. Comme je l'ai dis je ne pense pas que mettre le service sur un point soit la bonne solution car c'est bien le polygone en lui-même qui est le guichet. Le point n'est que l'endroit où l'on y accède. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] guichet
Il me semble que dans les votes de tag sur le wiki, il y a un amenity=reception_desk/reception_area/reception_point qui a été débattu ces derniers temps. Après, avec toutes les discussions qui ont suivi, je ne sais pas quelle a été l'issue… JB. Le 21/08/2015 17:05, Florian LAINEZ a écrit : Merci Jérôme pour ta réponse. Je ne me suis pas bien exprimé, ma question ne portait uniquement sur le tag à utiliser sur le point qui représente l'endroit où est délivré le service. Ce n'est pas à proprement parler une entrance puisque on ne peut pas entrer dans le polygone, mais c'est bien le point où l'on doit se présenter. Exemple avec un guichet qui est bien sur un polygone http://www.openstreetmap.org/way/365692666 mais qui a un point http://www.openstreetmap.org/node/3696985280 qui représente l'endroit où le guichetier accueille le grand public. Le 21 août 2015 16:23, Jérôme Seigneuret jseigneuret-...@yahoo.fr mailto:jseigneuret-...@yahoo.fr a écrit : *entrance=yes* ou *main *dans ton cas c'est ok. Tu peux avoir plusieurs entrées principales c'est pas un problème. C'est le cas des supermarchés aussi. Ce qui correspond le mieux à ton cas c'est office http://wiki.openstreetmap.org/wiki/Key:office=travel_agent http://wiki.openstreetmap.org/wiki/Tag:office%3Dtravel_agent en point ou polygone. Si c'est un automate: amenity http://wiki.openstreetmap.org/wiki/Key:amenity=*vending_machine* vending http://wiki.openstreetmap.org/wiki/Key:vending=public_transport_tickets J'espère que ça répond à ton besoin. Jérôme Le 21 août 2015 15:57, Florian LAINEZ winner...@free.fr mailto:winner...@free.fr a écrit : Hello, Je relance cette discussion sans avoir eu de réponse et élargi ma question : comment taguer le point d'accès (l'endroit où le service est disponible) à un service qui s'applique à un polygone ? J'utilise entrance=main mais je trouve cela vraiment crade. Merci Le 22 avril 2015 10:57, Florian LAINEZ winner...@free.fr mailto:winner...@free.fr a écrit : Hello, J'ai un problème pour décrire ce guichet de gare https://www.openstreetmap.org/way/319273556 qui est aussi en photo ici https://plus.google.com/photos/+FlorianLainez/albums/6132374967150818465/6132375082657315010?authkey=CMXipZ3g7bTdOgpid=6132375082657315010oid=111005261746474513881#photos/+FlorianLainez/albums/6132374967150818465/6132375082657315010?authkey=CMXipZ3g7bTdOgpid=6132375082657315010oid=111005261746474513881. En gros j'ai 3 éléments : - le polygone qui décrit la salle dans laquelle il y a le guichet : Building:part=room et tourism=information - un point sur ce polygone qui est l'entrée de service en bas : entrance=service et access=no - un point sur ce polygone qui est le guichet en lui-même, donc le point d'accès au service pour le public : pour l'instant je l'ai taggé entrance=main et access=yes mais cela ne me convient qu'à moitié car cela laisse penser que l'on peut entrer dans la pièce alors que ce n'est pas le cas. Je sais que vous allez me proposer de créer un point tourism=information séparé du polygone mais cela ne convient pas car ça ne décrit pas précisément la réalité. Une autre solution peut être ? Merci -- *Florian Lainez* @overflorian http://twitter.com/overflorian -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-at] Grenzimport Wien
Robert Kaiser wrote: CC-BY 3.0 AT sollte kein Problem sein. CC-BY-SA 3.0 AT ist allerdings inkompatibel. Das SA macht den Unterschied. In diesem Fall ist es aber eh CC-BY ohne SA. Kevin Kofler ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-cl] Regiones de Chile
El que se muestra en cada nivel de zoom está definido en las reglas que se le dan al motor de renderizado y el espacio disponible de acuerdo con la jerarquía de prioridades (si hay poco espacio se muestra primero lo más importante). En el caso de Mapnik para el render de la fundación, en el nivel 1 y 2 no muestra nada, en el nivel de zoom 3 muestra Santiago y Chile, en el 4 muestra el ref (I, II, III, IV, etc.), y del 5 al 19 muestra el name=* de la región. Respecto de todo esto, concuerdo con la posición de la etiqueta name=* sin el numero y este en el ref=*. Saludos, Julio Costa Zambelli Fundación OpenStreetMap Chile julio.co...@openstreetmap.cl http://www.openstreetmap.cl/ Cel: +56(9)89981083 2015-08-21 9:39 GMT-03:00 Marcelo Aliaga marc...@aliaga.cl: No tenemos algo como un estándar ISO de nomenclatura por cada región (intuyo que existe)? Tiene sentido que no aparezca el nombre completo en cada región -sin zoom- sino un indicativo (ej: estados en USA). 2015-08-20 22:17 GMT-03:00 Juan Pablo Tolosa Sanzana jptolosanz...@gmail.com: El problema que veo en la X Región es que cada isla es un miembro del multipolígono de la región, lo cual oculta el nombre de la isla u otra características. En las regiones de Aysén y Magallanes en cambio el multipolígono asociado a la región abarca hasta el límite del mar territorial. El 20/08/15 a las 18:17, Julio Costa Zambelli escibió: Cristián, No tengo muy claro a que se debe. Lo único que llamó mi atención fue que la vía del contorno de la isla participaba dos veces en cada relación (comunal y regional, al menos así me lo mostraba Potlatch2), por lo que borre una de cada una, dejándolo de modo normal. Veamos que pasa cuando tome estos cambios. Saludos, Julio Costa Zambelli Fundación OpenStreetMap Chile julio.co...@openstreetmap.cl http://www.openstreetmap.cl/ Cel: +56(9)89981083 2015-08-20 13:20 GMT-03:00 Cristián Serpell crist...@serpell.cl: Esa misma, muchas gracias! Como se ve, hay una isla en Chiloé que se llama Puqueldón que aparece al mismo nivel que el resto de las regiones. Cristián ___ Talk-cl mailing list Talk-cl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cl ___ Talk-cl mailing listTalk-cl@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cl ___ Talk-cl mailing list Talk-cl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cl -- Ing. Marcelo Aliaga Quezada marc...@aliaga.cl ___ Talk-cl mailing list Talk-cl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cl
Re: [OSM-talk-fr] guichet
je n'ai rien trouvé dans les tags indoor malheureusement : http://wiki.openstreetmap.org/wiki/Indoor_Mapping#Tags_in_use http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging Mon guichet ressemble à ça : http://images.midilibre.fr/images/2012/01/25/l-avenir-des-guichets-de-la-gare-sncf-menace_354067_510x255.jpg Il y a donc potentiellement plusieurs guichets donc plusieurs points d'accès au service. Comme je l'ai dis je ne pense pas que mettre le service sur un point soit la bonne solution car c'est bien le polygone en lui-même qui est le guichet. Le point n'est que l'endroit où l'on y accède. Le 21 août 2015 17:35, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : amenity=reception_desk http://wiki.openstreetmap.org/wiki/Proposed_features/reception_desk -- proposition rejetée reception_area http://wiki.openstreetmap.org/wiki/Proposed_features/reception_area -- proposition rejetée reception_point http://wiki.openstreetmap.org/wiki/Proposed_features/reception_point -- proposition rejetée Un polygone de type room a forcément des entrée. Il faut aller voir du coté des du schéma indoor. Sinon si la zone correspond à une zone réservé au service ton guichet est sur un des murs et dispose d'une entrée de service réservé aux employés : entrance=service Ton guichet est un bureau dans une pièces ou encastré dans le mur? Si c'est dans le mur le point est sur le mur avec le tag que je t'ai annoncé en haut Si tu peux dessiner un plan de la zone et le mettre en lien ça pourra clarifier la problématique. Jérôme Le 21 août 2015 17:29, Florian LAINEZ winner...@free.fr a écrit : l'issue a été négative justement : http://wiki.openstreetmap.org/wiki/Proposed_Features/amenity%3Dreception_desk d'où mon problème en ce moment ... Le 21 août 2015 17:15, JB jb...@mailoo.org a écrit : Il me semble que dans les votes de tag sur le wiki, il y a un amenity=reception_desk/reception_area/reception_point qui a été débattu ces derniers temps. Après, avec toutes les discussions qui ont suivi, je ne sais pas quelle a été l'issue… JB. Le 21/08/2015 17:05, Florian LAINEZ a écrit : Merci Jérôme pour ta réponse. Je ne me suis pas bien exprimé, ma question ne portait uniquement sur le tag à utiliser sur le point qui représente l'endroit où est délivré le service. Ce n'est pas à proprement parler une entrance puisque on ne peut pas entrer dans le polygone, mais c'est bien le point où l'on doit se présenter. Exemple avec un guichet qui est bien sur un polygone http://www.openstreetmap.org/way/365692666 mais qui a un point http://www.openstreetmap.org/node/3696985280 qui représente l'endroit où le guichetier accueille le grand public. Le 21 août 2015 16:23, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : *entrance=yes* ou *main *dans ton cas c'est ok. Tu peux avoir plusieurs entrées principales c'est pas un problème. C'est le cas des supermarchés aussi. Ce qui correspond le mieux à ton cas c'est office http://wiki.openstreetmap.org/wiki/Key:office=travel_agent http://wiki.openstreetmap.org/wiki/Tag:office%3Dtravel_agent en point ou polygone. Si c'est un automate: amenity http://wiki.openstreetmap.org/wiki/Key:amenity= *vending_machine* vending http://wiki.openstreetmap.org/wiki/Key:vending =public_transport_tickets J'espère que ça répond à ton besoin. Jérôme Le 21 août 2015 15:57, Florian LAINEZ winner...@free.fr a écrit : Hello, Je relance cette discussion sans avoir eu de réponse et élargi ma question : comment taguer le point d'accès (l'endroit où le service est disponible) à un service qui s'applique à un polygone ? J'utilise entrance=main mais je trouve cela vraiment crade. Merci Le 22 avril 2015 10:57, Florian LAINEZ winner...@free.fr a écrit : Hello, J'ai un problème pour décrire ce guichet de gare https://www.openstreetmap.org/way/319273556 qui est aussi en photo ici https://plus.google.com/photos/+FlorianLainez/albums/6132374967150818465/6132375082657315010?authkey=CMXipZ3g7bTdOgpid=6132375082657315010oid=111005261746474513881#photos/+FlorianLainez/albums/6132374967150818465/6132375082657315010?authkey=CMXipZ3g7bTdOgpid=6132375082657315010oid=111005261746474513881 . En gros j'ai 3 éléments : - le polygone qui décrit la salle dans laquelle il y a le guichet : Building:part=room et tourism=information - un point sur ce polygone qui est l'entrée de service en bas : entrance=service et access=no - un point sur ce polygone qui est le guichet en lui-même, donc le point d'accès au service pour le public : pour l'instant je l'ai taggé entrance=main et access=yes mais cela ne me convient qu'à moitié car cela laisse penser que l'on peut entrer dans la pièce alors que ce n'est pas le cas. Je sais que vous allez me proposer de créer un point tourism=information séparé du polygone mais cela ne convient pas car ça ne décrit pas précisément la réalité. Une autre solution peut être ? Merci -- *Florian Lainez* @overflorian
Re: [OSM-talk-fr] guichet
amenity=reception_desk http://wiki.openstreetmap.org/wiki/Proposed_features/reception_desk -- proposition rejetée reception_area http://wiki.openstreetmap.org/wiki/Proposed_features/reception_area -- proposition rejetée reception_point http://wiki.openstreetmap.org/wiki/Proposed_features/reception_point -- proposition rejetée Un polygone de type room a forcément des entrée. Il faut aller voir du coté des du schéma indoor. Sinon si la zone correspond à une zone réservé au service ton guichet est sur un des murs et dispose d'une entrée de service réservé aux employés : entrance=service Ton guichet est un bureau dans une pièces ou encastré dans le mur? Si c'est dans le mur le point est sur le mur avec le tag que je t'ai annoncé en haut Si tu peux dessiner un plan de la zone et le mettre en lien ça pourra clarifier la problématique. Jérôme Le 21 août 2015 17:29, Florian LAINEZ winner...@free.fr a écrit : l'issue a été négative justement : http://wiki.openstreetmap.org/wiki/Proposed_Features/amenity%3Dreception_desk d'où mon problème en ce moment ... Le 21 août 2015 17:15, JB jb...@mailoo.org a écrit : Il me semble que dans les votes de tag sur le wiki, il y a un amenity=reception_desk/reception_area/reception_point qui a été débattu ces derniers temps. Après, avec toutes les discussions qui ont suivi, je ne sais pas quelle a été l'issue… JB. Le 21/08/2015 17:05, Florian LAINEZ a écrit : Merci Jérôme pour ta réponse. Je ne me suis pas bien exprimé, ma question ne portait uniquement sur le tag à utiliser sur le point qui représente l'endroit où est délivré le service. Ce n'est pas à proprement parler une entrance puisque on ne peut pas entrer dans le polygone, mais c'est bien le point où l'on doit se présenter. Exemple avec un guichet qui est bien sur un polygone http://www.openstreetmap.org/way/365692666 mais qui a un point http://www.openstreetmap.org/node/3696985280 qui représente l'endroit où le guichetier accueille le grand public. Le 21 août 2015 16:23, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : *entrance=yes* ou *main *dans ton cas c'est ok. Tu peux avoir plusieurs entrées principales c'est pas un problème. C'est le cas des supermarchés aussi. Ce qui correspond le mieux à ton cas c'est office http://wiki.openstreetmap.org/wiki/Key:office=travel_agent http://wiki.openstreetmap.org/wiki/Tag:office%3Dtravel_agent en point ou polygone. Si c'est un automate: amenity http://wiki.openstreetmap.org/wiki/Key:amenity= *vending_machine* vending http://wiki.openstreetmap.org/wiki/Key:vending =public_transport_tickets J'espère que ça répond à ton besoin. Jérôme Le 21 août 2015 15:57, Florian LAINEZ winner...@free.fr a écrit : Hello, Je relance cette discussion sans avoir eu de réponse et élargi ma question : comment taguer le point d'accès (l'endroit où le service est disponible) à un service qui s'applique à un polygone ? J'utilise entrance=main mais je trouve cela vraiment crade. Merci Le 22 avril 2015 10:57, Florian LAINEZ winner...@free.fr a écrit : Hello, J'ai un problème pour décrire ce guichet de gare https://www.openstreetmap.org/way/319273556 qui est aussi en photo ici https://plus.google.com/photos/+FlorianLainez/albums/6132374967150818465/6132375082657315010?authkey=CMXipZ3g7bTdOgpid=6132375082657315010oid=111005261746474513881#photos/+FlorianLainez/albums/6132374967150818465/6132375082657315010?authkey=CMXipZ3g7bTdOgpid=6132375082657315010oid=111005261746474513881 . En gros j'ai 3 éléments : - le polygone qui décrit la salle dans laquelle il y a le guichet : Building:part=room et tourism=information - un point sur ce polygone qui est l'entrée de service en bas : entrance=service et access=no - un point sur ce polygone qui est le guichet en lui-même, donc le point d'accès au service pour le public : pour l'instant je l'ai taggé entrance=main et access=yes mais cela ne me convient qu'à moitié car cela laisse penser que l'on peut entrer dans la pièce alors que ce n'est pas le cas. Je sais que vous allez me proposer de créer un point tourism=information séparé du polygone mais cela ne convient pas car ça ne décrit pas précisément la réalité. Une autre solution peut être ? Merci -- *Florian Lainez* @overflorian http://twitter.com/overflorian -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list
Re: [OSM-ja] 国立公園 (national_park) の編集について
清野です。 この方、今夜も活発にデータを投入されているようです。 残念ながらいいださんのコメントについては気がついていないようですね。 直接メッセージを送る、という手段もまだ残ってはいますが、 緊急性を優先するなら、瀬戸さんやにしむらさんのご提案もやむを得ないのではないかと思います。 他にも奈良県内にはライセンス的にグレー、 あるいはおそらく黒いものを積極的に入れてらっしゃる方がおられますが、 何度もコンタクトは取ろうとしておりますが、 返事はもらえた試しがありません。 こういう方とどうコミュニケーションを取っていくかは悩ましいところです。 荒っぽいやり方はではありますが、 ひとまずリバートするしかないのかもしれません。 最後の手段であり悲しいですが…。 2015/08/20 22:35 Yuichiro Nishimura nissy...@gmail.com: ならのにしむらです 下記についてですが，ライセンス的にOSMに投入できるかどうかという議論以前に，インポートのガイドライン・手続きを介していないインポートは大変問題であるように思います http://wiki.openstreetmap.org/wiki/JA:インポート/ガイドライン ひとまず削除してから，それでもなお必要なデータということであれば，インポートに関するwikiの整備，ローカルコミュニティにおける議論，データ所有者からのライセンス上の承認を得ること，imports MLへのレビュー依頼，などの手順を踏んで，その後インポートを行う必要があると思います． この面からも瀬戸さんが提起したリバート案に賛成です． 2015/08/20 22:12、Toshikazu SETO toss...@gmail.com のメール： 瀬戸です。 正確にはオープンデータの類とは異なるデータセットであること（OSMのライセンスとは相容れないので、積極的に残す理由が現状ない） 研究で以前利用したこともあるのですが、本データが他のデータに勝るような正確性があるかというと、個人的な感触ではそうでもない点 から、特にデータインポートに関する議論を経ずに行われた作業に対してライセンス的に疑念があるものであれば、リバートすることが現実的でないかと思います。 2015年8月17日月曜日、Satoshi IIDAnyamp...@gmail.comさんは書きました: いいだです。 遅くなってしまいましたが、変更セットへのコメントを行っています。 https://www.openstreetmap.org/changeset/33048672 2015年8月11日 9:22 Satoshi IIDA nyamp...@gmail.com: いいだです。 ありがとうございます。 ライセンス互換性、個別の許可の取得 なるほど、個別の許諾交渉というのはひとつの手かもしれませんね。 環境省生物多様性センターさんに知り合いはいないので、 正面からあたってみるしかないかんじですが、、、 OSMFJとして行うか、個人として行うかは別として、ちょっと検討してみます。 （事後報告になっちゃうのはかなり厳しい気がしています） 政府標準利用規約をCC-BY互換に改定 はい、議論の俎上にあがる可能性が高いと伺っています。 ただ、ライセンス変更の結果がでるのは早くても今年度末かと思いますので、 待つのはちょっと厳しいかなぁ、とも感じています。 # CC-BY 4.0互換（2.1 JPではなく）になると、 # OSMでも利用できる可能性が高くなることもあり、 # 委員会での議論の行方は僕もたいへん注目しています。 トレースについて これも、調製をおこなった地図（作品）の利用にあたるかと思いますので、 調製された主体に確認が必要ですね。環境省さんかぁ。。。 海上の公園について 明確に議論がされたことは無いと思っています。 海岸線を1km延伸した海上部分も含めたほうがよい、ということで、納得しました。 できれば、インポート作業されたかたの意見も伺いたいなぁ。。。 2015年8月9日 17:42 centree oki_aic...@yahoo.co.jp: centree です。 私も詳しくありませんが… (1) ライセンスについて 政府標準利用規約というのがあるのですね。恥ずかしながら存じ上げませんでした。 http://www.biodic.go.jp/trialSystem/info/nps.html この辺のデータをコンバートして投入したいなら、確かに量も量ですし、OSMFJで許諾をとって頂いておいた方が安心かと思います。 OSMはそんなに黒い（？）要途を主な目的としてはいないと思うので、交渉や問い合わせは可能なのではないかと思いますが 確かにOSMに投入すると、後の用途は限っていませんので『公序良俗』に照らし合わせ、どのように判断がでるかは未知数ですね。 ちなみに、もし、上記のような生のデータではなく、 http://www.env.go.jp/park/yakushima/intro/files/area_3.pdf のようなP DF媒体からのトレースということになると、背景画に承認番号付きの地理院の地図が使われているので 地図タイルのトレースのみが許諾されているOSMへの投入はNGなのではないかなと思います。 (2)海上の公園について 国立公園の資料を見ると、海上もしっかり公園と称されているようなので、基本的には含めるべきなのかなと思います。 ただ、瀬戸内海国立公園なんかは範囲も広く、なかなかスケールの大きい作業になりそうですが… centree - Original Message - From: tomoya muramoto muramototom...@gmail.com To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2015/8/9, Sun 15:19 Subject: Re: [OSM-ja] 国立公園 (national_park) の編集について muramotoです。 インポートやライセンス関係には不案内なため、類似の経験をお持ちの方のご意見を待ちたいところですが、ざっと調べた上での所感です。 (1)ライセンスについて ・環境省生物多様性センターのライセンスは、ご指摘のとおり、利用用途に制限があるようです(「公序良俗」制限)。一方でODbLには利用用途に制限がないようです。ODbLのほうが緩いので、使えないのではないかと思います。 ・そのため、データをOSMで利用する場合は、個別に許諾を得る必要があると思います。例えば、国土地理院はGSImaps利用のライセンスで「公序良俗」の制限を課していますが、大変有難いことにOSMFJの方が個別に許諾を取っていただいたとのことなので、私は安心してデータを利用させていただ いております。 http://wiki.openstreetmap.org/wiki/JA:GSImaps ・もしくは、政府標準利用規約をCC-BY互換に改定しようという動きもあるようなので、その結果を待つのもひとつの手だとは思います。 https://www.kantei.go.jp/jp/singi/it2/densi/kwg/dai2/siryou2.pdf (細かいですが、環境省生物多様性センターのライセンスは政府標準利用規約（第1.0版）に準拠のようです。) (2)海上の公園について ・海上が国立公園として指定されている(海域公園地区または普通地域)のであれば、海上も範囲に含めるべきだと思います。国立公園では、海岸から1kmまで「普通地域」として指定されているようです。 ・過去の議論において、海上を含めるのは不都合であるという結論に達したのであれば、それに従って良いと考えますが、個人的には議論の流れを知りたいとは思います。 2015年8月8日 22:31 Satoshi IIDA nyamp...@gmail.com: いいだです。 国立公園のデータについて、インポート、あるいはトレースを行っているような形跡が見受けられました。 例えば、この編集です。 https://www.openstreetmap.org/changeset/33048672 この編集には、いくつかの問題があります。 1. 議論がされていない talk-ja, imports、どのメーリングリストにも、事前の相談が行われていません。 2. ライセンスの互換性 ライセンスを確認すると、政府標準利用規約(ver. 1.1)のようです。 しかしながら、その互換性については、いまだ議論が行われておらず、 インポート作業を行うには、法的な互換性が保たれていることが必要かと思っています。 （いわゆる、3条ア 公序良俗条項、のところがメインです） 逆に言えば、ここが担保されていれば、多くのデータが利用可能になります。 議論をし、互換性について議論したいです。 ■方針について データ自体については、有用なデータだと感じていますので、 できれば使い続けたいと考えています。 ただし、海の上にまで公園の範囲が及んでしまうなど、 疑問点がいくつかありますので、1. の、議論が行われていない、のが いちばんつらいところだな、と感じています。 （以前に台灣で、同じように海上にも及んでしまう公園が設定されて、 せめて近海くらいで止めよう、という編集が行われたと記憶しています。 たぶんこれ。 https://www.openstreetmap.org/relation/4074850/history ） このままゆくと、僕は、このかたの編集（と、たぶん同様の国立公園編集をされているもの）を すべて、ライセンス互換性の齟齬から、消さざるを得なくなっていまいます。 僕は、それをしたくありません。 議論をしたいです。 ご意見をお待ちしています。 -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire -- Satoshi
Re: [OSM-talk-fr] guichet
l'issue a été négative justement : http://wiki.openstreetmap.org/wiki/Proposed_Features/amenity%3Dreception_desk d'où mon problème en ce moment ... Le 21 août 2015 17:15, JB jb...@mailoo.org a écrit : Il me semble que dans les votes de tag sur le wiki, il y a un amenity=reception_desk/reception_area/reception_point qui a été débattu ces derniers temps. Après, avec toutes les discussions qui ont suivi, je ne sais pas quelle a été l'issue… JB. Le 21/08/2015 17:05, Florian LAINEZ a écrit : Merci Jérôme pour ta réponse. Je ne me suis pas bien exprimé, ma question ne portait uniquement sur le tag à utiliser sur le point qui représente l'endroit où est délivré le service. Ce n'est pas à proprement parler une entrance puisque on ne peut pas entrer dans le polygone, mais c'est bien le point où l'on doit se présenter. Exemple avec un guichet qui est bien sur un polygone http://www.openstreetmap.org/way/365692666 mais qui a un point http://www.openstreetmap.org/node/3696985280 qui représente l'endroit où le guichetier accueille le grand public. Le 21 août 2015 16:23, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : *entrance=yes* ou *main *dans ton cas c'est ok. Tu peux avoir plusieurs entrées principales c'est pas un problème. C'est le cas des supermarchés aussi. Ce qui correspond le mieux à ton cas c'est office http://wiki.openstreetmap.org/wiki/Key:office=travel_agent http://wiki.openstreetmap.org/wiki/Tag:office%3Dtravel_agent en point ou polygone. Si c'est un automate: amenity http://wiki.openstreetmap.org/wiki/Key:amenity= *vending_machine* vending http://wiki.openstreetmap.org/wiki/Key:vending =public_transport_tickets J'espère que ça répond à ton besoin. Jérôme Le 21 août 2015 15:57, Florian LAINEZ winner...@free.fr a écrit : Hello, Je relance cette discussion sans avoir eu de réponse et élargi ma question : comment taguer le point d'accès (l'endroit où le service est disponible) à un service qui s'applique à un polygone ? J'utilise entrance=main mais je trouve cela vraiment crade. Merci Le 22 avril 2015 10:57, Florian LAINEZ winner...@free.fr a écrit : Hello, J'ai un problème pour décrire ce guichet de gare https://www.openstreetmap.org/way/319273556 qui est aussi en photo ici https://plus.google.com/photos/+FlorianLainez/albums/6132374967150818465/6132375082657315010?authkey=CMXipZ3g7bTdOgpid=6132375082657315010oid=111005261746474513881#photos/+FlorianLainez/albums/6132374967150818465/6132375082657315010?authkey=CMXipZ3g7bTdOgpid=6132375082657315010oid=111005261746474513881 . En gros j'ai 3 éléments : - le polygone qui décrit la salle dans laquelle il y a le guichet : Building:part=room et tourism=information - un point sur ce polygone qui est l'entrée de service en bas : entrance=service et access=no - un point sur ce polygone qui est le guichet en lui-même, donc le point d'accès au service pour le public : pour l'instant je l'ai taggé entrance=main et access=yes mais cela ne me convient qu'à moitié car cela laisse penser que l'on peut entrer dans la pièce alors que ce n'est pas le cas. Je sais que vous allez me proposer de créer un point tourism=information séparé du polygone mais cela ne convient pas car ça ne décrit pas précisément la réalité. Une autre solution peut être ? Merci -- *Florian Lainez* @overflorian http://twitter.com/overflorian -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] guichet
Merci Jérôme pour ta réponse. Je ne me suis pas bien exprimé, ma question ne portait uniquement sur le tag à utiliser sur le point qui représente l'endroit où est délivré le service. Ce n'est pas à proprement parler une entrance puisque on ne peut pas entrer dans le polygone, mais c'est bien le point où l'on doit se présenter. Exemple avec un guichet qui est bien sur un polygone http://www.openstreetmap.org/way/365692666 mais qui a un point http://www.openstreetmap.org/node/3696985280 qui représente l'endroit où le guichetier accueille le grand public. Le 21 août 2015 16:23, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : *entrance=yes* ou *main *dans ton cas c'est ok. Tu peux avoir plusieurs entrées principales c'est pas un problème. C'est le cas des supermarchés aussi. Ce qui correspond le mieux à ton cas c'est office http://wiki.openstreetmap.org/wiki/Key:office=travel_agent http://wiki.openstreetmap.org/wiki/Tag:office%3Dtravel_agent en point ou polygone. Si c'est un automate: amenity http://wiki.openstreetmap.org/wiki/Key:amenity=*vending_machine* vending http://wiki.openstreetmap.org/wiki/Key:vending =public_transport_tickets J'espère que ça répond à ton besoin. Jérôme Le 21 août 2015 15:57, Florian LAINEZ winner...@free.fr a écrit : Hello, Je relance cette discussion sans avoir eu de réponse et élargi ma question : comment taguer le point d'accès (l'endroit où le service est disponible) à un service qui s'applique à un polygone ? J'utilise entrance=main mais je trouve cela vraiment crade. Merci Le 22 avril 2015 10:57, Florian LAINEZ winner...@free.fr a écrit : Hello, J'ai un problème pour décrire ce guichet de gare https://www.openstreetmap.org/way/319273556 qui est aussi en photo ici https://plus.google.com/photos/+FlorianLainez/albums/6132374967150818465/6132375082657315010?authkey=CMXipZ3g7bTdOgpid=6132375082657315010oid=111005261746474513881#photos/+FlorianLainez/albums/6132374967150818465/6132375082657315010?authkey=CMXipZ3g7bTdOgpid=6132375082657315010oid=111005261746474513881 . En gros j'ai 3 éléments : - le polygone qui décrit la salle dans laquelle il y a le guichet : Building:part=room et tourism=information - un point sur ce polygone qui est l'entrée de service en bas : entrance=service et access=no - un point sur ce polygone qui est le guichet en lui-même, donc le point d'accès au service pour le public : pour l'instant je l'ai taggé entrance=main et access=yes mais cela ne me convient qu'à moitié car cela laisse penser que l'on peut entrer dans la pièce alors que ce n'est pas le cas. Je sais que vous allez me proposer de créer un point tourism=information séparé du polygone mais cela ne convient pas car ça ne décrit pas précisément la réalité. Une autre solution peut être ? Merci -- *Florian Lainez* @overflorian http://twitter.com/overflorian -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- *Florian Lainez* @overflorian http://twitter.com/overflorian ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-at] Grenzimport Wien
On 21.08.2015 10:58, Jens Steinhauser wrote: Seit einigen Tagen traegt ein neuer User [1] in Wien jede Menge Grenzen ein (allerdings nicht als boundary=..., sondern als place=neighbourhood). ... * Die Bezirke die er eintraegt sind schon als admin_level=9 vorhanden, die meisten Graetzl schon als place-Nodes. D.h. da ist jetzt jede Menge Zeugs doppelt. * Ich kann keine vorherige Diskussion zum Import dieser Zählbezirksgrenzen, ob diese Daten irgendjemanden ausser dem Eintragenden intressieren und wie man diese Daten abbilden sollte, finden. * Auf meinen Changeset-Kommentar zu seiner Erdberg-als-Grenze Eintragung, dass Erdberg schon als place-Node vorhanden sei, loescht er dann einfach kommentarlos den place-Node raus [5], anstatt sich davor irgendwie abzusprechen. Er hat auch andere place-Nodes gelöscht, darunter einige von mir auf sorgfältig recherchierte Ortskerne gesetzte. Er versteht offenbar nicht, was Place-Nodes bedeuten. Nebenbei finden sich in seinen Changesets auch viele Löschungen tagloser Nodes. Abgesehen davon, dass diese Löschungen falsch sind, finde ich es schon anmaßend, wenn ein neuer User gleich wild zum Löschen anfängt. Kann bitte jemand diese Änderungen revertieren oder die DWG damit beauftragen? (Frederik, wenn du mitliest...) -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] Abandoned Rails
Err.. Ok. In that case we should keep all of Europe's borders within OSM going all the way back to the Roman empire before. Not such a good idea eh? If you want to map irrelevant data just to keep users happy then you'll be happy with me mapping every route I've walked ridden? I'll name them 'Dave's Routes' Not such a good idea eh? Do you keep old buildings. roads, schools etc? No. So why railways? There was a group who wanted to add historic data in the current database. I live in a city which dates back to Roman times. How unusable would that be if just all the buildings were added? If someone wants a historic railway map they should scrape the data into a separate database overlay onto a current OSM rendering. As an aside, personally I don't feel OSM is a community. I feel little comradeship to you or any other mappers. I contribute as I see it as better map to the alternatives. Dave F. On 21/08/2015 19:51, Gregory Arenius wrote: The OSM community is what OSM is even more than it is a map. People that are passionate about railways are a part of that community and they do contribute a lot, especially in the US where we don't have as many mappers. They pour lots of time and love and passion into their efforts. I don't think a policy of deleting that work just because what they're mapping isn't immediately visible on the ground is a good way of building and strengthening our community. In fact, as it is easy to see in this thread, its actively doing the opposite. And community is what makes OSM. I'd therefor like to propose that abandoned railways be treated like borders. Even if you can't see it along a given stretch there are people who can and they have put a huge amount of effort into that work. Lets respect that and strengthen the community rather than deleting it and doing the opposite. Cheers, Greg ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-at] Grenzimport Wien
On 21.08.2015 11:22, Robin Däneke wrote: Jedoch wurden ja die Kastralgemeimden erst kürzlich nach einer Diskussion in dieser Mailing Liste gemappt. Die Kastralgemeimden müssten also bereits drinnen sein... Nur im Süden. Vielleicht mache ich nächsten Herbst/Winter weiter. Der User der hier gemeint ist mappt Daten von Zählbezirken (was auch immer die angeben). Ich weiß auch nicht, was die angeben, aber was er mappt ist totaler Schmafu. Zählbezirke sind in irgendeiner Weise administrative Einheiten, das schreit also nach einer boundary-Relation. Auf keinen Fall passt das von ihm gesetzte place=neighbourhood. Erstens ist es nicht dafür gedacht, zweitens wird es in Wien und auch sonst überall für was anderes verwendet, und drittens wird es üblicherweise auf Nodes gesetzt, nicht auf Flächen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [talk-latam] [Talk-pe] Taller sobre OpenStreetMap con MapGive en Cusco, Peru
Hola Erika, Yo también voy a apoyar desde la distancia mapeando edificios y agregando otros datos, veo que las calles ya estan mapeadas en su mayoría. Edith. El 21 de agosto de 2015, 9:53, Erika Nunez erika.k.nu...@gmail.com escribió: Gracias, Johnattan! Buen idea, seria muy bien ponerlo en el blog. Estamos focalizando ahora en los edificios, caminos, y senderos, y hemos actualizado el task para reflejar eso y incluir mas información sobre el taller. Por supuesto, si alguien quiere participar desde la distancia, son más que bienvenidos a contribuir al mapa! Aqui están algunas estatisicas del task, hasta ahorita http://ec2-54-242-150-21.compute-1.amazonaws.com/mapgive-cusco/ Erika 2015-08-21 4:58 GMT-05:00 Johnattan Rupire jarja...@riseup.net: Genial Erika! si te parece bien, publicamos la invitación en el blog osmpe.ourproject.org, también puedes publicarla tú misma! :) Alguna vez estuve mapeando por allí, tengo alguna trazas gps en osm, Polyglot también hizo algunas rutas de transporte púlico, ¿Qué estarán mapeando? calles, rutas de transporte, PDIs? todo? Si se puede ayudar desde la distancia me gustaría participar... Saludos!!! El 2015-08-20 05:04, Erika Nunez escribió: Hola, Mapeadores! Queria informarles que vamos a conducir un taller sobre OpenStreetMap este fin de semana, con estudiantes y profesionales, en Cusco, Peru como parte de la iniciativa de MapGive y la colaboración entre la Universidad Nacional de San Antonio Abad del Cusco y la initiativa de Ciudades Secundarias. El taller introducirá técnicas de recopilación de datos de campo en OpenStreetMap (OSM), utilizando OpenMapKit y FieldPapers; edición en OpenStreetMap; y el uso de los datos de OpenStreetMap en GIS. El taller se centrará especialmente en las zonas de reciente crecimiento urbano en el Cusco. Hicimos una tarea para las areas, y ahorita estamos mapeando las areas, dando prioridad a las areas que vamos a empezar a visitar en campo este fin de semana. Si están interesados en contribuir o mapear en Cusco, aquí esta el link! Seria un gran ayuda. http://tasks.hotosm.org/project/1159#task/166 [1] Estamos traduciendo varios materiales relacionados a estas herramientas que podrian servir de ayuda a la comunidad de mapeadores de habla español. Vamos a compartir todos los materiales después del taller en una pagina de web. Estamos emocionados para esta oportunidad para crecer la comunidad de mapeadores :) Por favor, avísenme si tienen preguntas! Erika from MapGive Links: -- [1] http://tasks.hotosm.org/project/1159#task/166 ___ talk-latam mailing list talk-latam@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-latam ___ talk-latam mailing list talk-latam@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-latam ___ talk-latam mailing list talk-latam@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-latam
Re: [OSM-talk-fr] guichet
+1 pour la logique de PanierAvide, La sémantique simple est pour moi gage d'efficacité. Nous pouvons après préciser le type de prestation réalisée... Zimmy - Cordialement, ZIMMY Jean-Louis ZIMMERMANN Développeur territorial (CCPRO,FR84) Mandataire OSM-France sur le Grand-Sud-est -- View this message in context: http://gis.19327.n5.nabble.com/guichet-tp5841429p5852865.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Rencontre parisienne OSM
Bonjour à tous, Si vous êtes parisien, francilen ou que vous êtes de passage sur la capitale, nous vous proposons de nous rencontrer mardi 25 août 2015 à partir de 19h et ca se passe là (Restaurant Chez Papa) http://www.openstreetmap.org/node/2695378308 Donat ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Abandoned Rails
The OSM community is what OSM is even more than it is a map. People that are passionate about railways are a part of that community and they do contribute a lot, especially in the US where we don't have as many mappers. They pour lots of time and love and passion into their efforts. I don't think a policy of deleting that work just because what they're mapping isn't immediately visible on the ground is a good way of building and strengthening our community. In fact, as it is easy to see in this thread, its actively doing the opposite. And community is what makes OSM. I'd therefor like to propose that abandoned railways be treated like borders. Even if you can't see it along a given stretch there are people who can and they have put a huge amount of effort into that work. Lets respect that and strengthen the community rather than deleting it and doing the opposite. Cheers, Greg ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Abandoned Rails
Gregory Arenius greg...@arenius.com writes: The OSM community is what OSM is even more than it is a map. People that are passionate about railways are a part of that community and they do contribute a lot, especially in the US where we don't have as many mappers. They pour lots of time and love and passion into their efforts. I don't think a policy of deleting that work just because what they're mapping isn't immediately visible on the ground is a good way of building and strengthening our community. In fact, as it is easy to see in this thread, its actively doing the opposite. And community is what makes OSM. I'd therefor like to propose that abandoned railways be treated like borders. Even if you can't see it along a given stretch there are people who can and they have put a huge amount of effort into that work. Lets respect that and strengthen the community rather than deleting it and doing the opposite. Well said. I agree that community is being harmed by the deletionist mentality. pgpljzVYnofbV.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The Proposed Great Colour Shift
W dniu 20.08.2015 3:16, Jóhannes Birgir Jensson napisał(a): Should this be a new, alternative style instead? Looks like New Hope is coming to fix The Great Tertiary Problem ;-} : https://github.com/gravitystorm/openstreetmap-carto/pull/1736#issuecomment-133529853 However in my opinion more alternative styles on OSM.org are necessity anyway, as I have already wrote: https://lists.openstreetmap.org/pipermail/talk/2015-August/073895.html -- The train is always on time / The trick is to be ready to put your bags down [A. Cohen] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] highway et limites administratives confondues
Sbastien, on comptait pourtant sur toi pour tout corriger ;-). Francescu, je ne sais si cest la norme ou lexception, voici un exemple o la limite administrative et la route est entirement dans un dpartement (et non cheval). OSM reprsente bien la ralit du terrain. D 765 Rdn (Finistre) : http://www.openstreetmap.org/way/23471922#map=15/47.8267/-3.4874 D 765 Guidel (Morbihan) : http://www.openstreetmap.org/way/319569030#map=15/47.8267/-3.4874 Comme indiqu, la route dans la partie limitrophe des deux communes est en Rdn. Le lieu-dit Les Trois Pierres (les btiments louest) est indiqu Commune de Guidel alors que les panneaux de changement de dpartement sont au sud (l o la D 765 ne suit plus la limite Rdn/Guidel). Initialement je pensais comme toi que les routes taient entre les deux. Mais imagine que le Morbihan ne refasse pas sa route en mme temps que le Finistre : on ne va pas refaire la chausse sur la moiti de la largeur... surtout si on profite pour rectifier un virage. Il est plus simple quune seule entit soit charge de lentretien, quitte trouver un accord financier. Jean-Yvon On 21/08/2015 11:55, Francescu GAROBY wrote: Bonjour, Pour slectionner le bon lment, dans JOMS, fais un clic-molette : une pop-up apparatra, listant les nodes/ways/relations se trouvant sous ton clic. Tu pourras ainsi slectionner llment que tu veux, sans avoir dplacer quoique ce soit. Pour la diffrenciation entre highways et limites administratives, la tendance ici est sparer les 2 (personnellement, je trouve a dommage, mais bon...). Mais du coup, JOSM rle, en effet ! Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-at] Grenzimport Wien
Friedrich Volkmann wrote: Ich weiß auch nicht, was die angeben, aber was er mappt ist totaler Schmafu. Zählbezirke sind in irgendeiner Weise administrative Einheiten, das schreit also nach einer boundary-Relation. Auf keinen Fall passt das von ihm gesetzte place=neighbourhood. Erstens ist es nicht dafür gedacht, zweitens wird es in Wien und auch sonst überall für was anderes verwendet, und drittens wird es üblicherweise auf Nodes gesetzt, nicht auf Flächen. Ich vermute dahinter einen Versuch, die exakten Grenzen der Grätzel bzw. der historischen Ortschaften aus den verfügbaren offiziellen Daten zu eruieren. Das Problem dabei ist nur, daß diese Zählbezirke rein administrativ sind und in der Regel NICHT mit den historischen Grenzen der namensgebenden Ortschaften übereinstimmen, und wohl ebensowenig mit dem aktuellen Gebrauch. (Davor wird auch in der Wikipedia gewarnt.) Die Katastralgemeinden sind für solche Zwecke noch eher brauchbar, aber nur in den Außenbezirken. (In den Innenbezirken entsprechen sie ja den Bezirken und sind mit diesen fast, aber nicht ganz, deckungsgleich.) Sinnvolle Grenzen für Grätzel in den Innenbezirken gibt es bestenfalls auf historischen Karten (in denen noch die Vorstädte eingezeichnet waren), aber meistens wurden damals keine Grenzen eingezeichnet, und falls doch, entsprechen sie nicht notwendigerweise dem aktuellen Gebrauch. Kevin Kofler ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] Abandoned Rails
Hi I'd therefor like to propose that abandoned railways be treated like borders. Even if you can't see it along a given stretch there are people who can and they have put a huge amount of effort into that work. Lets respect that and strengthen the community rather than deleting it and doing the opposite. I 100% agree. The amount of data required to map abandoned railroads is tiny. An occasional way through a new development is not going to hurt anybody or impair normal mapping activity. Apparently, the people that like to map railroads think OSM is the best place to do this. We are not in any position to be chasing them off. OSM has a long, long way to go still. Above all else, it needs to more active mappers if we are serious about being the best map for the entire world. Also, It seems likely they are also mapping non controversial things like roads while working on the railroads. Dave F, OSM is doing just fine. It is full of contradictions, redundancies, disagreements, and broken rules (see the tagging list). It is not some kind of business database that requires normalization, strict schema definitions, and vigilant protection. It can't have any once sentence rules defining its boundaries. It is a great big blank sheet of paper, relax and let the railroad people draw on it a bit. Nobody is going to get hurt. Jason ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-ja] 国立公園 (national_park) の編集について
OSMFJのikiyaです。 OSMFJ内でも今回のnational-parkさんの国立公園データのインポートについて協議致しました。 チェンジセットへのコメント送信による注意喚起、ユーザーアカウントへのOSMメール送信で直接注意を行いました。 national-parkさんから回答がなければ、現状、広域にわたるこのデータをこのまま放置はできませんのでリバートを行いたいと考えます。 - Original Message - From: Yoichi SEINO say.n...@gmail.com To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2015/8/21, Fri 23:57 Subject: Re: [OSM-ja] 国立公園 (national_park) の編集について 清野です。 この方、今夜も活発にデータを投入されているようです。 残念ながらいいださんのコメントについては気がついていないようですね。 直接メッセージを送る、という手段もまだ残ってはいますが、 緊急性を優先するなら、瀬戸さんやにしむらさんのご提案もやむを得ないのではないかと思います。 他にも奈良県内にはライセンス的にグレー、 あるいはおそらく黒いものを積極的に入れてらっしゃる方がおられますが、 何度もコンタクトは取ろうとしておりますが、 返事はもらえた試しがありません。 こういう方とどうコミュニケーションを取っていくかは悩ましいところです。 荒っぽいやり方はではありますが、 ひとまずリバートするしかないのかもしれません。 最後の手段であり悲しいですが…。 2015/08/20 22:35 Yuichiro Nishimura nissy...@gmail.com: ならのにしむらです 下記についてですが，ライセンス的にOSMに投入できるかどうかという議論以前に，インポートのガイドライン・手続きを介していないインポートは大変問題であるように思います http://wiki.openstreetmap.org/wiki/JA:インポート/ガイドライン ひとまず削除してから，それでもなお必要なデータということであれば，インポートに関するwikiの整備，ローカルコミュニティにおける議論，データ所有者からのライセンス上の承認を得ること，imports MLへのレビュー依頼，などの手順を踏んで，その後インポートを行う必要があると思います． この面からも瀬戸さんが提起したリバート案に賛成です． 2015/08/20 22:12、Toshikazu SETO toss...@gmail.com のメール： 瀬戸です。 正確にはオープンデータの類とは異なるデータセットであること（OSMのライセンスとは相容れないので、積極的に残す理由が現状ない） 研究で以前利用したこともあるのですが、本データが他のデータに勝るような正確性があるかというと、個人的な感触ではそうでもない点 から、特にデータインポートに関する議論を経ずに行われた作業に対してライセンス的に疑念があるものであれば、リバートすることが現実的でないかと思います。 2015年8月17日月曜日、Satoshi IIDAnyamp...@gmail.comさんは書きました: いいだです。 遅くなってしまいましたが、変更セットへのコメントを行っています。 https://www.openstreetmap.org/changeset/33048672 2015年8月11日 9:22 Satoshi IIDA nyamp...@gmail.com: いいだです。 ありがとうございます。 ライセンス互換性、個別の許可の取得 なるほど、個別の許諾交渉というのはひとつの手かもしれませんね。 環境省生物多様性センターさんに知り合いはいないので、 正面からあたってみるしかないかんじですが、、、 OSMFJとして行うか、個人として行うかは別として、ちょっと検討してみます。 （事後報告になっちゃうのはかなり厳しい気がしています） 政府標準利用規約をCC-BY互換に改定 はい、議論の俎上にあがる可能性が高いと伺っています。 ただ、ライセンス変更の結果がでるのは早くても今年度末かと思いますので、 待つのはちょっと厳しいかなぁ、とも感じています。 # CC-BY 4.0互換（2.1 JPではなく）になると、 # OSMでも利用できる可能性が高くなることもあり、 # 委員会での議論の行方は僕もたいへん注目しています。 トレースについて これも、調製をおこなった地図（作品）の利用にあたるかと思いますので、 調製された主体に確認が必要ですね。環境省さんかぁ。。。 海上の公園について 明確に議論がされたことは無いと思っています。 海岸線を1km延伸した海上部分も含めたほうがよい、ということで、納得しました。 できれば、インポート作業されたかたの意見も伺いたいなぁ。。。 2015年8月9日 17:42 centree oki_aic...@yahoo.co.jp: centree です。 私も詳しくありませんが… (1) ライセンスについて 政府標準利用規約というのがあるのですね。恥ずかしながら存じ上げませんでした。 http://www.biodic.go.jp/trialSystem/info/nps.html この辺のデータをコンバートして投入したいなら、確かに量も量ですし、OSMFJで許諾をとって頂いておいた方が安心かと思います。 OSMはそんなに黒い（？）要途を主な目的としてはいないと思うので、交渉や問い合わせは可能なのではないかと思いますが 確かにOSMに投入すると、後の用途は限っていませんので『公序良俗』に照らし合わせ、どのように判断がでるかは未知数ですね。 ちなみに、もし、上記のような生のデータではなく、 http://www.env.go.jp/park/yakushima/intro/files/area_3.pdf のようなP DF媒体からのトレースということになると、背景画に承認番号付きの地理院の地図が使われているので 地図タイルのトレースのみが許諾されているOSMへの投入はNGなのではないかなと思います。 (2)海上の公園について 国立公園の資料を見ると、海上もしっかり公園と称されているようなので、基本的には含めるべきなのかなと思います。 ただ、瀬戸内海国立公園なんかは範囲も広く、なかなかスケールの大きい作業になりそうですが… centree - Original Message - From: tomoya muramoto muramototom...@gmail.com To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2015/8/9, Sun 15:19 Subject: Re: [OSM-ja] 国立公園 (national_park) の編集について muramotoです。 インポートやライセンス関係には不案内なため、類似の経験をお持ちの方のご意見を待ちたいところですが、ざっと調べた上での所感です。 (1)ライセンスについて ・環境省生物多様性センターのライセンスは、ご指摘のとおり、利用用途に制限があるようです(「公序良俗」制限)。一方でODbLには利用用途に制限がないようです。ODbLのほうが緩いので、使えないのではないかと思います。 ・そのため、データをOSMで利用する場合は、個別に許諾を得る必要があると思います。例えば、国土地理院はGSImaps利用のライセンスで「公序良俗」の制限を課していますが、大変有難いことにOSMFJの方が個別に許諾を取っていただいたとのことなので、私は安心してデータを利用させていただ いております。 http://wiki.openstreetmap.org/wiki/JA:GSImaps ・もしくは、政府標準利用規約をCC-BY互換に改定しようという動きもあるようなので、その結果を待つのもひとつの手だとは思います。 https://www.kantei.go.jp/jp/singi/it2/densi/kwg/dai2/siryou2.pdf (細かいですが、環境省生物多様性センターのライセンスは政府標準利用規約（第1.0版）に準拠のようです。) (2)海上の公園について ・海上が国立公園として指定されている(海域公園地区または普通地域)のであれば、海上も範囲に含めるべきだと思います。国立公園では、海岸から1kmまで「普通地域」として指定されているようです。 ・過去の議論において、海上を含めるのは不都合であるという結論に達したのであれば、それに従って良いと考えますが、個人的には議論の流れを知りたいとは思います。 2015年8月8日 22:31 Satoshi IIDA nyamp...@gmail.com: いいだです。 国立公園のデータについて、インポート、あるいはトレースを行っているような形跡が見受けられました。 例えば、この編集です。 https://www.openstreetmap.org/changeset/33048672 この編集には、いくつかの問題があります。 1. 議論がされていない talk-ja, imports、どのメーリングリストにも、事前の相談が行われていません。 2. ライセンスの互換性 ライセンスを確認すると、政府標準利用規約(ver. 1.1)のようです。 しかしながら、その互換性については、いまだ議論が行われておらず、 インポート作業を行うには、法的な互換性が保たれていることが必要かと思っています。 （いわゆる、3条ア 公序良俗条項、のところがメインです） 逆に言えば、ここが担保されていれば、多くのデータが利用可能になります。 議論をし、互換性について議論したいです。 ■方針について データ自体については、有用なデータだと感じていますので、 できれば使い続けたいと考えています。 ただし、海の上にまで公園の範囲が及んでしまうなど、 疑問点がいくつかありますので、1. の、議論が行われていない、のが いちばんつらいところだな、と感じています。 （以前に台灣で、同じように海上にも及んでしまう公園が設定されて、 せめて近海くらいで止めよう、という編集が行われたと記憶しています。 たぶんこれ。 https://www.openstreetmap.org/relation/4074850/history ） このままゆくと、僕は、このかたの編集（と、たぶん同様の国立公園編集をされているもの）を すべて、ライセンス互換性の齟齬から、消さざるを得なくなっていまいます。 僕は、それをしたくありません。 議論をしたいです。 ご意見をお待ちしています。 -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire
Re: [OSM-talk] The Proposed Great Colour Shift
I'd be tempted to leave motorways as blue - it's not such a critical problem as the invisible green trunk roads. Adding one more shade of red to the existing color-progression is probably achievable. Two seems to be pushing it. On Fri, Aug 21, 2015 at 11:47 PM, Daniel Koć daniel@koć.pl wrote: W dniu 20.08.2015 3:16, Jóhannes Birgir Jensson napisał(a): Should this be a new, alternative style instead? Looks like New Hope is coming to fix The Great Tertiary Problem ;-} : https://github.com/gravitystorm/openstreetmap-carto/pull/1736#issuecomment-133529853 However in my opinion more alternative styles on OSM.org are necessity anyway, as I have already wrote: https://lists.openstreetmap.org/pipermail/talk/2015-August/073895.html -- The train is always on time / The trick is to be ready to put your bags down [A. Cohen] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Hallo Stephan, ich habe jetzt nicht die ganze Diskussion verfolgt, aber zu diesen Aussagen möchte ich folgendes sagen: kann jemand eine sinnvoll anwendbare Definition von künstlichen / menschengemachten Wasserflächen geben? Ich denke, dass wir /diesen/ Unterschied /nicht/ mit unterschiedlichen Primär-tags ausdrücken sollten. Sondern wenn, dann durch ein *historisches Sekundär-tag*. z.B. durch waterway:artificial=(Jahreszahl der Fertigstellung) Entscheidend für waterway ist m.E. - die hydrologische Funktion (primär, Einzugsgebiet, Wasserscheide) - der Verkehrsweg (sekundär) Für stehende Wasserflächen: natürlich: die Wasserfläche existierte schon vor dem Beginn menschlicher Eingriffe/würde ohne menschliche Eingriffe existieren. Künstlich: aufgestaute oder gegrabene Seen (Wasserreservoir, Fischteich, Erholungsgebiet, Bergbau-Grundwassersee) Für Wasserläufe: natürlich: es hat vor den menschlichen Eingriffen einen Wasserlauf gegeben, der im Verlauf und in seinem Einzugsgebiet dem jetzigen ähnelt Beispiel für künstlich: Kanal von Korinth (GR) Beispiel für künstliche Korrektur natürlicher Gewässer: Linth-Kanal (CH) Bei großen Flüssen und Seen ist offensichtlich oder zumindest leicht zu ermitteln, ob sie vom Menschen geschaffen wurden. Es gibt drei Varianaten: 1. hat noch nie existiert, sondern wurde künstlich erschaffen 2. ist rein natürlich entstanden 3. der natürliche Verlauf wurde mehr oder weniger künstlich verändert 3 trifft vermutlich auf die meisten Gewässer irgendwie zu... Soll man zwei aktuell gleiche Wasserläufe mit unterschiedlichen Tags erfassen, wenn einer einen natürlichen Vorgänger hatte? Mit Sekundär-tags lässt sich das gut ausdrücken. Primär-tag sollte aber m.E. dafür gleich sein. Um auf Übersichtskarten nur Große Flüsse darzustellen fehlt dagegen eine Unterteilung in kleiner Fluss, großer Fluss und Strom Ja, da gibt es Entwicklungsbedarf :-) Sowohl hydrologisch, als auch verkehrsmässig, werden Flüsse in *Klassen* eingeteilt, die wir in OSM abbilden könnten. Interessant wäre auch die *mittlere Abflussmenge*. Mit herzlichem Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Graz+Innsbruck: »Schiene und Straße wurden getrennt«
From: kevin.kof...@chello.at Das stimmt so nicht. Zumindest ich habe die zweigleisigen Straßenbahnen für gut befunden und finde das immer noch. (Die Ausführung war teilweise nicht optimal, z.B., was Relationen anbelangt, aber die Probleme sind inzwischen behoben. Mit dem neuen Ist-Zustand bin ich zufrieden.) Als ich in Wien die Buslinien gemappt habe, fand ich die getrennten Gleise eigentlich sehr gut. So musste man bei Bussen die den Gleiskörper benützen nicht beim Eingeben der Route die Straße (oder zumindest eine Verbindung) zu einem fiktiven Gleis in der Mitte oder am Rand der Straße führen, sondern konnte bestehende, sich mit den Gleisen kreuzende Straßenteile am richtigen Ort verwenden, um die Busrelation auch mit dem richtigen Gleis zu verbinden. Ob ich da beim Busmapping alles richtig gemacht hab kann ich zwar nicht sagen, aber da meine Changes bisher kaum bis gar keine Änderungen erfuhren denke ich mal, dass da nicht so viel daneben ist... Es ist einfach leichter zu bearbeiten, je genauer es ist, wenn dieses Argument auch schon ein paar mal kam. Und in den Fällen (sollte es nur außerhalb Wiens geben), wo 2 Gleise noch als 1 Way gemappt sind, ist die Trennung von der Straße auch nur dann sinnvoll, wenn auch wirklich zweigleisig (und präzise, also die tatsächliche Position der Gleise) gemappt wird. Ein getrennter Way mit denselben Knoten wie die Straße bringt niemandem was (auch nicht den Leuten wie Railjet oder mir, die für zweigleisiges Straßenbahnmapping sind). Dem stimme ich zu. Wenn die Gleise direkt auf der Straße sind, ist das wohl etwas problematisch...Da wären wir dann bei der Frage, wie genau man mappen kann, will und soll. Das mit der, von Friedrich Volkmann angesprochenen Straßenfläche habe ich mir schon öfters gedacht. Wieso ist nicht jede Straße und dann der Gehsteig als Fläche (was es ja im Endefekt in natura ist) gemappt. Die Antwort ist wohl die Komplexität, die das auch zum Bearbeiten aber wohl auch rendering o.ä. bringen würde. Aber es wird hier doch mit zweierlei Maß gemessen, wenn ihr mir erlaubt Straßen mit Bäumen zu vergleichen: Auf OSM werden einzelne Bäume erfasst, manchmal auch nachgefragt, ob denn ein hohe Strauch nun ein Baum ist, aber die Straßen (aber vor allem die Gleise und ähnliches) sind [ausserhalb von Wien] noch nicht so detailgetreu auf der Karte. Also wenn man Gleise je FR mappt, wird man auch gleich die Straße so detailgetreu wie irgendwie möglich mappen müssen, dass nicht die Linien der Straße und der Geleise ein großer fetter Strich sind, sondern erkennbar und vor allem noch bearbeitbar nebeneinander liegen. In Wien schaut das ja gar nicht so schlecht aus. (Da hatte ich nur manchmal in JOSM Probleme eine Straße auszuwählen, weil eine Bezirksgrenze exakt drauf lag, aber mit den Gleisen, sofern ich sie anwählen musste, ging alles problemlos.) Es ist wohl sehr viel Arbeit, und auch ein Thema, dass man besser jeweils direkt Vor Ort bespricht (-- Stammtisch Graz) , bevor man da mit dem Ändern beginnt, denn man wird für alle nötigen Änderungen die so ein Vorhaben mit sich bringt auch Hilfe brauchen. Und wenn dann alle gegen einen sind wird das nicht gut ausgehen. Also aussprechen, Lösungen überlegen, und dann gemeinsam und nicht gegeneinander mappen. Mit freundlichen Grüßen aus Wien XXIRobin Däneke ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] stop deleting abandoned railroads
On 21/08/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 20.08.2015 um 14:59 schrieb Pieren pier...@gmail.com: where is the railway here ? were are the rails ? there aren't any rails, but there is a railbed, this cutting wouldn't make sense for a cycleway, would it? (inappropriate effort) IMHO (and I've been arguing against mapping railway=abandoned in many cases), I think that in this case tagging railway=abandoned (along with highway=cycleway and cutting=yes) is acceptable, meaning that I don't think the tag should be deleted, but I wouldn't add it myself. For: even an on the ground unmoving observer would easily figure out that this was a railway. Against: it is neither a railway nor abandoned, it is a cycleway, the characteristics of which can be fully described without refering to its railway origin. There has to be a point in a way's physical evolution when we can stop tagging railway=abandoned, where do you draw the line ? The it was a railway fact can if desired be kept in a relation with start/end tags (a rare case where these can work). ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-at] Grenzimport Wien
Jedoch wurden ja die Kastralgemeimden erst kürzlich nach einer Diskussion in dieser Mailing Liste gemappt. Die Kastralgemeimden müssten also bereits drinnen sein... Der User der hier gemeint ist mappt Daten von Zählbezirken (was auch immer die angeben). Bei diesen Daten sind offenbar kleinste Einheiten dabei... Also Bezirksgrätzl mit höchstens 10*10 Häuserblöcken, von was ich so gesehen hab bei den Changesets... Mich wundert das irgendwie... Das Simnering etwas weit raus läuft wäre möglich, aber der User sollte vielleicht mal darauf aufmerksam gemacht werden, dass er das hier vorher erklären sollte, bevor er wild drauf los mappt (und am Ende dann alles oder fast alles doppelt ist) MfG Robin Däneke Wien XXI PS: Falls ihr immer alle Changes in Wien und Umgebung sehen wollt, ich habe da mal ein RSS-Feed dafür erstellt: http://zverik.osm.rambler.ru/whodidit/scripts/rss.php?bbox=16.203445,48.060282,16.554321,48.296083 Date: Fri, 21 Aug 2015 11:07:16 +0200 From: sk...@ostblock.org To: talk-at@openstreetmap.org Subject: Re: [Talk-at] Grenzimport Wien -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015-08-21 10:58, Jens Steinhauser wrote: Was meint ihr zu den Eintragungen? Keine Ahnung, was die Datenqualität oder Lizenz angeht. Grundsätzlich sind in Wien die Grenzen der Katastralgemeinden nicht immer ident mit den Bezirksgrenzen. Allerdings ist das eher eine reichlich akademische Frage... Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV1upDAAoJEMZD4PEit0TYSjsH/3EnOWMqO2x/rbnrOFbtUyOV Nl9ePMnZWlB/XpB0sE6IVu1nBlDCKW0PP05Xrph57rvAjr+Kl1sCuLic9+XNG4rv sg/uc1LuHfNHR16Cnrk+j8nDDPvMz3JouLPQtSoK28m5Jn71UCT/0DAEjxqgOeBA ABtDMUfHaT7Wxqcd2ymMvn3bhLQwhWo/s6REnGq+2HcFWmnDGjBz38tBm+Q31Rpl MAf3dwJu+qlmIYzjebHAfHVEzssFUUN7wIk5UH+GS1tCoooUosn77oXmDBnvCyMB Eb9lCunZNpCOApPz04WyfE37NWJhLPUWH3LnvTdyId6eGejN2sER6bJmUzg16CE= =aXTO -END PGP SIGNATURE- ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] highway et limites administratives confondues
Bonjour, Pour sélectionner le bon élément, dans JOMS, fais un clic-molette : une pop-up apparaîtra, listant les nodes/ways/relations se trouvant sous ton clic. Tu pourras ainsi sélectionner l'élément que tu veux, sans avoir à déplacer quoique ce soit. Pour la différenciation entre highways et limites administratives, la tendance ici est à séparer les 2 (personnellement, je trouve ça dommage, mais bon...). Mais du coup, JOSM râle, en effet ! Francescu Le 21 août 2015 11:47, sebastien.bugzi...@gmail.com sebastien.bugzi...@gmail.com a écrit : Bonjour Je suis en train de mettre à jour / créer les relations pour les transports en commun de Pau. Je constate qu'il y a bien souvent des routes qui sont aussi des limites administratives. Josm les détecte d'ailleurs comme chemin confondus et affiche un warning. J'ai des difficultés à créer les relations dans ce cas. Souvent c'est la limite administrative qui est cliquable et je galère à dissocier les chemins pour pouvoir enfin sélectionner que la route qui m'intéresse. Voici un exemple : https://www.openstreetmap.org/relation/4345649 Je voudrais savoir si c'est bien comme ça que je dois procéder et si il n'y a pas un outil qui le ferait automatiquement. Du genre détection des chemins confondus, séparation des deux chemins avec peut être un léger offset de l'un par rapport à l'autre pour pouvoir les distinguer. Merci pour votre aide ! Sébastien ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] highway et limites administratives confondues
Dans JOSM tu peux utiliser le clic molette/bouton du centre pour avoir la liste des objets superposées. En gardant appuyé ça défile, ou avec avec la touche contrôle pour sélectionner dedans. Le 21/08/2015 11:47, sebastien.bugzi...@gmail.com a écrit : Bonjour Je suis en train de mettre à jour / créer les relations pour les transports en commun de Pau. Je constate qu'il y a bien souvent des routes qui sont aussi des limites administratives. Josm les détecte d'ailleurs comme chemin confondus et affiche un warning. J'ai des difficultés à créer les relations dans ce cas. Souvent c'est la limite administrative qui est cliquable et je galère à dissocier les chemins pour pouvoir enfin sélectionner que la route qui m'intéresse. Voici un exemple : https://www.openstreetmap.org/relation/4345649 Je voudrais savoir si c'est bien comme ça que je dois procéder et si il n'y a pas un outil qui le ferait automatiquement. Du genre détection des chemins confondus, séparation des deux chemins avec peut être un léger offset de l'un par rapport à l'autre pour pouvoir les distinguer. Merci pour votre aide ! Sébastien ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] quand Google court après OSM
Le 21/08/2015 00:14, Emilie Laffray a écrit : Oui enfin, il ne faut pas non plus faire une obsession vis a vis de Google. Je ne suis pas sure qu'il y ait une correlation; ca reste quelque chose qui est dans l'air du temps. C'est un truc qui me trotte dans la tête depuis un bout de temps et j'avais fait un premier pas en visualisant les bâtiments orientés par rapport aux points cardinaux. L'idée pour l'étape suivante est de mettre en place un interface de crowdsourcing simple pour indiquer l'orientation du faitage du toit... pour (phase suivante) alimenter un moteur comme opencv pour l'entrainer à reconnaitre tout seul l'orientation sur les images aériennes... Faute de temps, je ne suis pas allé plus loin que la première étape. De plus ce projet est le projet d'un employe (le fameux 20%), qui a ete repris par Google mediatiquement par la societe en premier lieu. Google reste malgre tout une societe assez concernee par le futur en terme d'ecologie. Cela n'est pas donc pas tres surprenant. Le campus de Google est a ce titre tres interessant avec des plantations de fraisiers a certains endroits. Bref, je digresse mais avoir Google faire de la pub sur ce genre de technologie ne peut que renforcer les societes qui font la meme chose ailleurs avec des technologies similaires. Hummm... écologie et datacenters massifs ça ne fait pas franchement bon ménage même avec quelques fraisiers pour faire passer la pilule ;) Un documentaire intéressant a été diffusé à ce sujet sur La Chaine Parlementaire dernièrement: http://www.lcp.fr/emissions/docs-ad-hoc/vod/168436-internet-la-pollution-cachee -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-cz] WeeklyOSM CZ 259-262 - červenec
Ahoj, Ty instrukce Mapboxu k mapování jsou super, hlavně část How to map X. Takhle nějak bych si to představoval. Názorné, s praktickými pohyblivými obrázky a když je potřeba tak i s videem. Třeba video o trasování budov - všechny triky, které tam ukazují sice znám, ale pro někoho to může být novinka. Nebylo by špatné to přeložit a doplnit o česká specifika. Koukal jsem, že tam mají i španělskou verzi, takže nějak to jde. Jo a znáte http://learnosm.org/ ? To je více zaměřeno na iD, ale taky tam chybí česká verze. Takový tip na dlouhé zimní večery, které se pomalu, ale jistě blíží ;-) Marián -- Původní zpráva -- Od: Tom Ka tomas.kaspa...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 18. 8. 2015 10:39:56 Předmět: [Talk-cz] WeeklyOSM CZ 259-262 - červenec Ahoj, je dostupné souhrnné vydání 259-262 týdeníku weeklyOSM za měsíc červenec: http://www.weeklyosm.eu/cz/archives/4639 Téma čísla: tag source (zdroj) * CZ importy studánek, zastávek hromadné dopravy a stromů (Na Ovoce) * Čištění turistických tras KČT (aneb sága pokračuje) * OSM může využívat Bing i pod firmou Uber * Instrukce k mapování pro interní týmy v MapBoxu * Mapování POI s OpenPOIMap * importy registru stromů v Rakousku (Linz) a Francii (Nice) * konec Flashe a editor Potlach * Práce pro MapBox v Berlíně Pěkné počtení... ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-it] mappare specie vegetali linkando wikipedia
Sto pensando a cosa fare a scuola di open ques'anno pensavo di mappare specie vegetali (e o animali l'orso!?!?!?) su openstreemap e/o progetti correlati linkando su wikipedia le schede di presentazione delle specie Avrei bisogno di qualche suggerimento? ciao matteo Ps so usare crowdmap (classico) e con quello potrei fare una cosa tipo tenno.crowdmap.com, mi piacerebbe però poter essere un minimo più collaborativo ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Am 21.08.2015 00:28, schrieb Christoph Hormann: On Thursday 20 August 2015, Stephan Wolff wrote: Welche kleinen Wasserläufe dieses Gebiets sind natürlich? http://www.openstreetmap.org/#map=13/54.3349/9.4072 Dort ist das eigentlich relativ einfach, denn die meisten natürlichen Wasserläufe sind hier kaum begradigt, so dass man sie gut an der Form erkennen kann. Die mäandernden Flüsse sind 20-60m breit. Das war nicht die Frage. Aber welche Gräben hatten einen natürlichen Vorgänger und müssten als stream erfasst werden? Der historische Ansatz passt nicht zu OSM. In OSM wird generell der aktuelle Zustand erfasst. Das Problem ist hier nicht die Erfassung historischer Zustände, sondern die Bewertung der Gegenwart aufgrund von Erkenntnissen über die Vergangenheit. Wollen wir von den Mappern verlangen, dass sie die Vergangenheit jedes Objekts ermitteln und danach das Haupttag festlegen? Soll ein Mapper ein Kleingewässer, dessen Vergangenheit er nicht ermitteln kann, als stream oder ditch taggen? Welche Anwendungen braucht die Unterscheidung nach der Entstehung des Gewässers? Alle Anwendungen, bei denen in irgendeiner Form eine Analyse der Struktur des Gewässernetzwerkes stattfindet. OSM wird häufiger für Kartendarstellungen als zu Strukturanalysen des Gewässernetzwerkes verwendet. Das Tagging sollte sich m.E. eher an den Bedürfnissen der Hauptnutzung orientieren. Der zentrale Punkt ist, dass natürliche Fließgewässer generell den steilsten Weg bergab fließen. Für Bergbäche mag es gelten. Für mäandernden Flüsse nicht. Begradigte Bäche und Entwässerungsgräben sind meist so angelegt, dass das Wasser auf direktem Weg ablaufen kann. In der ober genannten Region werden mehrerer Flüsse über Pumpwerke entwässert. Die Alte Sorge fließt dadurch auf den letzten 9km rückwärts. In den Gräben fließt das Wasser dagegen nur durch die Schwerkraft. Für künstliche Wasserläufe gilt beides nicht (Kontinuität im engeren Sinne natürlich schon, jedoch nicht nach außen wenn man Tunnel und Druckstollen mit einbezieht). Tunnel und Druckstollen wird man eher am tunnel-Tag als am waterway-Tag erkennen. ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk-fr] highway et limites administratives confondues
Bonjour Je suis en train de mettre à jour / créer les relations pour les transports en commun de Pau. Je constate qu'il y a bien souvent des routes qui sont aussi des limites administratives. Josm les détecte d'ailleurs comme chemin confondus et affiche un warning. J'ai des difficultés à créer les relations dans ce cas. Souvent c'est la limite administrative qui est cliquable et je galère à dissocier les chemins pour pouvoir enfin sélectionner que la route qui m'intéresse. Voici un exemple : https://www.openstreetmap.org/relation/4345649 Je voudrais savoir si c'est bien comme ça que je dois procéder et si il n'y a pas un outil qui le ferait automatiquement. Du genre détection des chemins confondus, séparation des deux chemins avec peut être un léger offset de l'un par rapport à l'autre pour pouvoir les distinguer. Merci pour votre aide ! Sébastien ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Am 20.08.2015 14:20, schrieb Christoph Hormann: natürlich (also waterway=river/stream und ggf. waterway=riverbank bzw. water=river für das Polygon): es hat vor den menschlichen Eingriffen einen Wasserlauf gegeben, der im Verlauf und in seinem Einzugsgebiet dem jetzigen ähnelt. Der Nord-Ostsee-Kanal ersetzt die Eider zwischen Flemhuder See und Rendsburg. Er nimmt das Wasser der Obereider und aller ehemaligen Zuflüsse auf. Ist dieser Abschnitt ein natürliches Gewässer? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] YoHours: opening_hours viewer and editor
Hello, I recently released a new version of YoHours, a website which allows everyone to create and view opening hours in the OSM syntax. It now supports seasons-dependent hours (month, week, day, holiday selectors). It's available here: http://github.pavie.info/yohours/ The code is available on GitHub: https://github.com/PanierAvide/panieravide.github.io/tree/master/yohours [1] If you have any suggestions, let me know :) Cordially, PanierAvide. Links: -- [1] https://github.com/PanierAvide/panieravide.github.io/tree/master/yohours ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] The Proposed Great Colour Shift
On Thu, Aug 20, 2015 at 5:17 PM, Minh Nguyen m...@nguyen.cincinnati.oh.us wrote: Lester Caine lester at lsces.co.uk writes: Just what is the convention in the US, Russia or China? Regarding the U.S., Paul and I describe the conventions here in detail: https://lists.openstreetmap.org/pipermail/talk/2015-August/073892.html But the short version is: real highway shields. Their absence is striking to Americans, far more than the highway colors (which aren't as uniform in U.S. print cartography as they are in the U.K.). There are plenty of technical issues to work out, in any case: https://github.com/gravitystorm/openstreetmap-carto/issues/508 Yeah, this is jarring for most North American users, as Canadian, Mexican and even some Japanese maps (probably more prevalent to English maps of Japan, though) often use the style popular in the US, and I would hope that rendering the refs off relations with shields should be considered mandatory for the next update. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] highway et limites administratives confondues
Merci pour ce raccourcit je ne connaissais pas ! Et il va m'être vraiment utile d'autant qu'il y a des infos supplémentaires qui apparaissent... Pour la séparation des chemins je trouve que c'est mieux d'avoir des objets indépendants. L'inconvénient c'est qu'on est obligé d'avoir beaucoup de nœuds... Bon de toute façon je ne vais pas tout corriger hein... ;) Sébastien On 21/08/2015 11:55, Francescu GAROBY wrote: Bonjour, Pour sélectionner le bon élément, dans JOMS, fais un clic-molette : une pop-up apparaîtra, listant les nodes/ways/relations se trouvant sous ton clic. Tu pourras ainsi sélectionner l'élément que tu veux, sans avoir à déplacer quoique ce soit. Pour la différenciation entre highways et limites administratives, la tendance ici est à séparer les 2 (personnellement, je trouve ça dommage, mais bon...). Mais du coup, JOSM râle, en effet ! Francescu Le 21 août 2015 11:47, sebastien.bugzi...@gmail.com mailto:sebastien.bugzi...@gmail.com sebastien.bugzi...@gmail.com mailto:sebastien.bugzi...@gmail.com a écrit : Bonjour Je suis en train de mettre à jour / créer les relations pour les transports en commun de Pau. Je constate qu'il y a bien souvent des routes qui sont aussi des limites administratives. Josm les détecte d'ailleurs comme chemin confondus et affiche un warning. J'ai des difficultés à créer les relations dans ce cas. Souvent c'est la limite administrative qui est cliquable et je galère à dissocier les chemins pour pouvoir enfin sélectionner que la route qui m'intéresse. Voici un exemple : https://www.openstreetmap.org/relation/4345649 Je voudrais savoir si c'est bien comme ça que je dois procéder et si il n'y a pas un outil qui le ferait automatiquement. Du genre détection des chemins confondus, séparation des deux chemins avec peut être un léger offset de l'un par rapport à l'autre pour pouvoir les distinguer. Merci pour votre aide ! Sébastien ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] The Proposed Great Colour Shift
While we are at it, what about specific symbols for train/metro stations per operator? That is also a great landmark for map users. On 2015-08-21 11:57, Paul Johnson wrote: On Thu, Aug 20, 2015 at 5:17 PM, Minh Nguyen m...@nguyen.cincinnati.oh.us wrote: Lester Caine lester at lsces.co.uk [1] writes: Just what is the convention in the US, Russia or China? Regarding the U.S., Paul and I describe the conventions here in detail: https://lists.openstreetmap.org/pipermail/talk/2015-August/073892.html But the short version is: real highway shields. Their absence is striking to Americans, far more than the highway colors (which aren't as uniform in U.S. print cartography as they are in the U.K.). There are plenty of technical issues to work out, in any case: https://github.com/gravitystorm/openstreetmap-carto/issues/508 Yeah, this is jarring for most North American users, as Canadian, Mexican and even some Japanese maps (probably more prevalent to English maps of Japan, though) often use the style popular in the US, and I would hope that rendering the refs off relations with shields should be considered mandatory for the next update. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk Links: -- [1] http://lsces.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-at] Grenzimport Wien
Hallo, Seit einigen Tagen traegt ein neuer User [1] in Wien jede Menge Grenzen ein (allerdings nicht als boundary=..., sondern als place=neighbourhood). * Als Quelle gibt er bei einigen Changesets [2] an. Der Datensatz steht unter CC BY 3.0 AT, ich kenne mich mit den Lizenzen nicht s gut aus, bin mir aber nicht sicher ob der Import so ohne weiteres moeglich ist ([3]). * Die Bezirke die er eintraegt sind schon als admin_level=9 vorhanden, die meisten Graetzl schon als place-Nodes. D.h. da ist jetzt jede Menge Zeugs doppelt. * Ich kann keine vorherige Diskussion zum Import dieser Zählbezirksgrenzen, ob diese Daten irgendjemanden ausser dem Eintragenden intressieren und wie man diese Daten abbilden sollte, finden. * Auf meinen Changeset-Kommentar zu seiner Erdberg-als-Grenze Eintragung, dass Erdberg schon als place-Node vorhanden sei, loescht er dann einfach kommentarlos den place-Node raus [5], anstatt sich davor irgendwie abzusprechen. Ueber die Grenzen von Erdberg laesst sich schwer Genaues finden, aber eine Eintragung nach Simmering hinein bis hinters Kraftwerk halte ich fuer Uebertrieben. Dieser Grenzverlauf wird wohl auch aus irgendeinem Stadt-Datensatz kommen, hat aber mit der heutigen Verwendung wenig zu tun. Ausserdem macht es so ein Verhalten eher schwer, mit jemandem konstruktiv zusammenzuarbeiten. Kennt von euch jemand den User? Was meint ihr zu den Eintragungen? lg, Jens [1] https://www.openstreetmap.org/user/mmarinschek [2] https://open.wien.at/site/datensatz/?id=e4079286-310c-435a-af2d-64604ba9ade5 [3] https://lists.openstreetmap.org/pipermail/talk-at/2015-June/007740.html [4] https://www.openstreetmap.org/changeset/33414472 [5] https://www.openstreetmap.org/changeset/33424395#map=17/48.20010/16.39908 ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] stop deleting abandoned railroads
sent from a phone Am 20.08.2015 um 14:59 schrieb Pieren pier...@gmail.com: where is the railway here ? were are the rails ? there aren't any rails, but there is a railbed, this cutting wouldn't make sense for a cycleway, would it? (inappropriate effort) why should we keep any mention about rails when it's a cycleway now ? because it's a cycleway in a railbed? map what we see, the path or track and the cuttings/embankments. map what we see does not mean to only look the next 2 meters in front of you. There clearly is an artificial cutting and if you look at this in a bigger context you (or at least someone else who neither isn't a railway expert) can likely understand that this is a former railway. railway=dismantled means there is no railway currently but there are clear traces / remains of a railway (because if there weren't we would not put it in Osm). How do you see that a highway is primary? without looking at a bigger picture you won't. if we mapped like you suggest, we would only map highway=road... cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Tagging National Forests
OK, so say so where so. (Tag in OSM accordingly). If you wish to subtract from the polygon areas which you are absolutely certain no timber production is allowed or possible, go for it. I won't argue. Your list is a good start. Well, perhaps we have a happy compromise here. Tell you what: I'll start with the assumption that a forest should be tagged forest. (That's fair, and/or I'm listening to your alternative proposition). WHEN, WHERE and IF you know a particular area to be expressly NOT a forest, you are perfectly welcome to exclude that subset from said polygon. I'm fine with that. Wikipedia says National Forest is a classification of federal lands in the United States. This doesn't mean that the name National forests implies a forest tag (it's just an administrative classification). Further Wikipedia says National Forests are largely forest and woodland areas. I guess this is why you want to use the landuse=forest tag as a first approximation with the intention that mappers will go ahead and modify (exclude subsets) appropriately. The problem with this approach is that it makes further editing hard and discouraging (exactly the opposite of creating forward momentum). When the landuse=forest tag is part of the administrative boundary one needs to create complicated mulitpolygones for any further refinement of the map. This stops (or at least discourages) me as a contributer from making the map better. Moreover the generic landuse=forest tag adds no new information that isn't already there with the name National Forest and the administrative boundary. It is OK to do first approximations when mapping, but one needs to make sure that these will not seriously hinder further refinement. For this reason I am against general tagging of vast areas simply because they are largely forests. Imagine somebody tagging Finnland (75% forests) as landuse=forest [or natural=wood]. In this sense my alternative proposition is remove the generic landuse=forest tag and thus encourage OSM contributors to go ahead and build a beautiful map. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-at] Seltsame Relationsüberschneidungen
On 20.08.2015 20:17, eest9 wrote: Dank der neuen Rendermethode von Wäldern ist mir heute folgende Situation aufgefallen: Hier überschneiden sich zB die Relationen http://www.openstreetmap.org/relation/4463260 und http://www.openstreetmap.org/relation/276576 bzw. auf der anderen Seite http://www.openstreetmap.org/relation/3187534 ... Selbst wenn man meint für Lichtungen sei es durchaus akzeptable wenn man keine Relation erstellt wäre es für mich falsch denn in diesem riesigen Ausmaß stellt etwas für mich keine Lichtung mehr dar. Das finde ich auch. Unabhängig davon finde ich aber auch den neuen Kartenstil extrem schlecht in mehrfacher Hinsicht. Hier sind also zwei Fehler zusammengekommen. Und ist das gesamte überhaupt eine Weidewiese? In dieser Höhenlage wahrscheinlich eher natural=fell, aber es gibt auch Anzeichen von Beweidung (Einzelbäume, fehlender Latschengürtel, hangstreichende Linien die wie Kuhgangeln aussehen). Ohne Ortskenntnis würde ich das nicht umtaggen. Darf das umgemapped werden so dass der Wald nicht mehr über der Wiese liegt? Das auf jeden Fall. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] rôle/fonctionnement de layers.openstreetmap.fr ?
C'est la page par défaut suite à une installation d'un serveur HTTP Apache 2. Il semble que la page par défaut n'ait pas été redirigé. Ou c'est un reset en cours? Tu peux utiliser ça en attendant: http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#7/47.000/2.000 Le 21 août 2015 08:51, Art Penteur art.pent...@gmail.com a écrit : Bonjour à tous (et surtout aux courageux et jamais assez remerciés admins d'openstreetmap.fr) , Il y a quelque temps, à l'url http://layers.openstreetmap.fr/, on accédait à une carte, avec plusieurs couches disponibles, dont celle liée à BANO. Maintenant, on tombe sur It works! This is the default web page for this server. The web server software is running but no content has been added, yet. Le fonctionnement ancien était un coup de chance (on tombait sur un service qui n'était pas destiné à être ouvert/maintenu), ou alors le fonctionnement actuel est une panne ? Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-at] Grenzimport Wien
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015-08-21 10:58, Jens Steinhauser wrote: Was meint ihr zu den Eintragungen? Keine Ahnung, was die Datenqualität oder Lizenz angeht. Grundsätzlich sind in Wien die Grenzen der Katastralgemeinden nicht immer ident mit den Bezirksgrenzen. Allerdings ist das eher eine reichlich akademische Frage... Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV1upDAAoJEMZD4PEit0TYSjsH/3EnOWMqO2x/rbnrOFbtUyOV Nl9ePMnZWlB/XpB0sE6IVu1nBlDCKW0PP05Xrph57rvAjr+Kl1sCuLic9+XNG4rv sg/uc1LuHfNHR16Cnrk+j8nDDPvMz3JouLPQtSoK28m5Jn71UCT/0DAEjxqgOeBA ABtDMUfHaT7Wxqcd2ymMvn3bhLQwhWo/s6REnGq+2HcFWmnDGjBz38tBm+Q31Rpl MAf3dwJu+qlmIYzjebHAfHVEzssFUUN7wIk5UH+GS1tCoooUosn77oXmDBnvCyMB Eb9lCunZNpCOApPz04WyfE37NWJhLPUWH3LnvTdyId6eGejN2sER6bJmUzg16CE= =aXTO -END PGP SIGNATURE- ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[OSM-talk-fr] rôle/fonctionnement de layers.openstreetmap.fr ?
Bonjour à tous (et surtout aux courageux et jamais assez remerciés admins d'openstreetmap.fr) , Il y a quelque temps, à l'url http://layers.openstreetmap.fr/, on accédait à une carte, avec plusieurs couches disponibles, dont celle liée à BANO. Maintenant, on tombe sur It works! This is the default web page for this server. The web server software is running but no content has been added, yet. Le fonctionnement ancien était un coup de chance (on tombait sur un service qui n'était pas destiné à être ouvert/maintenu), ou alors le fonctionnement actuel est une panne ? Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
