Re: [OSM-talk-fr] Plans lignes RER?
Tu as essayé avec la requête Overpass de Paul Mallet? Il faut appuyer sur Execute... http://overpass-turbo.eu/s/7UC Et bien sûr, tu changes: [ref=C] pour tirer les autres lignes. Avec exporter tu peux l'avoir dans d'autres formats. Et il y a moyen d'appliquer un autre style au résultat en ajoutant du MapCSS. Jo 2015-02-28 1:54 GMT+01:00 Shohreh codecompl...@free.fr: Merci mais je cherchais ça… http://gis.19327.n5.nabble.com/file/n5835271/plan-rer.gif http://www.plandeparis.info/plan-rer/plan-rer.gif … avec 1. une carte géographique en fond de carte, et 2. une seule ligne par carte (RER A, B, C, D, E) -- View this message in context: http://gis.19327.n5.nabble.com/Plans-lignes-RER-tp5835260p5835271.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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [talk-au] Proposed import of 19 bicycle repair stations in au/nz
A worldwide view of this feature can be found at: http://umap.openstreetmap.fr/en/map/bicycle-repair-stations_25364#4/-28.34/143.88 ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
[OSM-talk-be] My goodness!
Goodjour Bonday, Anyone noticed this? New icon next to Search GO Or was I absent minded? Amazed, André. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] My goodness!
It's been there for years, didn't you know it ? * On 28-02-15 04:01, André Pirard wrote: Goodjour Bonday, Anyone noticed this http://www.openstreetmap.org/directions?engine=osrm_carroute=48.858%2C2.294%3B51.501%2C-0.125#map=7/50.202/1.384? New icon next to Search GO Or was I absent minded? Amazed, André. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be * It was announced on 16/2 general mailing list = Routing on osm.org ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-fr] illustration pour les nouveaux cantons
Encore une mention intéressante au sujet des anciens cantons dans une section de l'article Wikipédia lié au redécoupage: En résumé, cela confirme encore que les anciens cantons ne sont pas encore morts et persistent au moins jusqu'en 2017, même si ce n'est plus pour les élections cantonales/départementales, et que les chefs-lieux de cantons ne sont pas totalement remplacés par les bureaux centralisateurs des nouveaux cantons. Il y a encore d'autres usages (nombreux) des anciens cantons (notamment dans le code rural), et cela justifie de les préserver dans la base (avec le statut disused:) pendant encore un peu plus de 2 ans. Bref on a une période de transition à assurer et on a bien fait de ne pas les supprimer (et à mon avis il peuvent rester jusqu'au redécoupage suivant pour les élections de mars 2021. Source : https://fr.wikipedia.org/wiki/Redécoupage_cantonal_de_2014_en_France#Perte_de_la_qualité_de_chef-lieu [citation] Ce nouveau découpage cantonal entraînera la perte de la qualité de chef-lieu pour certaines communes, en raison des regroupements de cantons et donc une perte financière à terme pour ces communes. En effet, la première fraction dite « bourg-centre » de la dotation de solidarité rurale (DSR) est notamment attribuée aux communes chefs-lieux de cantons ainsi qu'aux communes dont la population représente au moins 15 % de celle de leur canton (article L. 2334-21 du CGCT). La réduction du nombre de cantons pose donc la question de l'éligibilité des communes perdant leur qualité de chef-lieu de canton à la suite de cette réforme ainsi que de celles ne remplissant plus le critère de la part de la population communale dans la population cantonale. Selon l'article L. 3113-2 du CGCT modifié par la loi du 17 mai 2013 : « (...) II. -La qualité de chef-lieu de canton est maintenue aux communes qui la perdent dans le cadre d'une modification des limites territoriales des cantons, prévue au I, jusqu'au prochain renouvellement général des conseils départementaux. (...) ». Ainsi, tous les décrets de remodelage de la carte cantonale n'auront vocation à s'appliquer qu'au moment du renouvellement des conseils départementaux, soit en mars 2015. Par conséquent, ce n'est seulement qu'à compter de 2017, année au cours de laquelle sera prise en compte la situation des communes au 1er janvier 2016, que le redécoupage de la carte cantonale pourrait avoir un impact sur la répartition de la fraction « bourg-centre » de la DSR. [/citation] Avec en références : 1. [PDF] « Rapport d’information sur la mise en application de la loi organique n° 2013-402 du 17 mai 2013 relative à l’élection des conseillers municipaux, des conseillers communautaires et des conseillers départementaux et de la loi n° 2013-403 du 17 mai 2013 relative à l’élection des conseillers départementaux, des conseillers municipaux et des conseillers communautaires, et modifiant le calendrier électoral. », sur LégiFrance, p. 19-22 http://www.assemblee-nationale.fr/14/pdf/rap-info/i2129.pdf 2. Question écrite n° 09291 de M. Gérard Bailly (Jura - UMP) - Réponse du Ministère de l'intérieur, « Perte pour les chefs-lieux de canton des dotations spécifiques au titre de la fraction bourg centre », sur le site du Sénat, 20 février 2014 http://www.senat.fr/questions/base/2013/qSEQ131109291.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-be] My goodness!
Goodjour Bonday, Anyone noticed this? New icon next to Search GO Or am I absent minded? Amazed, André. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-fr] illustration pour les nouveaux cantons
Doucement je n'ai pas été aussi malpoli. Je vois simplement en contrôlenat le tout qu'il y a des communes dispersées, *même* dans d'autres départements, certaines prises deux fois dans deux cantons, toute une série de communes oubliées. Certes l'erreur est humaine, même en utilisant un script, ça n'empêche pas de se tromper en l'utilisant, et il est possible aussi que ton script ait quelques défauts ou qu'il a été trompé par certains cas particuliers, je n'ai pas regardé dans le détail, vu que je n'avais pas ce script sous les yeux et que je n'en ai jamais eu besoin. Le 28 février 2015 00:53, Christian Quest cqu...@openstreetmap.fr a écrit : Le 27 février 2015 22:52, Philippe Verdy verd...@wanadoo.fr a écrit : Le 27 février 2015 22:20, Christian Quest cqu...@openstreetmap.fr a écrit : 90% de ce qui a été semi-automatisé est ok et beaucoup de temps a été gagné par rapport à l'usage classique de comcommaker vu qu'on n'avait pas de liste de codes INSEE qui aurait permis de faire directement mieux. Les décrets contenaient les noms de communes exacts (à quelques différences comme les accents omis sur les capitales). Il fallait les faire coller avec le numéro de département pour éviter de prendre des homonymes. Malgré cela je ne sais pas comment tu t'es débrouillé pour aller chercher d'autres communes ailleurs, qui n'ont même pas le même nom et même pas toujours dans le même département. Toujours aussi prompt à prendre les gens pour des idiots, que ça fait du bien de ne plus lire ce genre de message ! Bien sûr que j'ai pris le n° de département pour éviter les homonymes... et j'ai fait gaffe pour l'unique cas d'homonyme dans le même département. Le script est sur https://gist.github.com/cquest/c008db0ea286ae289276 pour vérifier, c'est même le premier paramètre. -- Christian Quest - OpenStreetMap France ___ 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-ja] インポートデータに関する削除について
ikiyaです。 タスクマネージャでチェックしてみました。（チェックは終了） http://nyampire.info/project/6 緑色のセルは確認終了、インポートデータらしきものは確認できなかった「ＯＫですよエリア」 黄色のセルは、インポートデータ建物ありのエリアです。 思ったより黄色のセル範囲が多く残念でした。 農研さんの基盤地図情報タイル（旧基盤地図2500レベル、25000レベル）と 地理院タイルstdそれぞれをJOSMで背景表示させてでOSMデータと比較チェックしました。 http://wiki.openstreetmap.org/w iki/JA:GSI_KIBAN/Using_GSI_KIBAN_WMS 黄色セルですが、西の山間部はセル１つでインポート建物数個の削除が簡単なものもあれば、 削除作業が進められた東の市街地でも、まだ対象建物が多く残っているセルもあります。 大変ですが、タスクマネージャ使って削除作業進めるしかなさそうです。 対象ユーザーの方にはOSMユーザーメールで 直接、作業お知らせしておきます。 - Original Message - From: Satoshi IIDA nyamp...@gmail.com To: Muarkami Oki oki_aic...@yahoo.co.jp; OpenStreetMap Japanese talk talk-ja@openstreetmap.org Cc: ikiya insidekiwi...@yahoo.co.jp Date: 2015/2/28, Sat 08:50 Subject: Re: [OSM-ja] インポートデータに関する削除について いいだです。 ikiyaさん タクスマネージャーを使って、明らかに基盤地図情報以外のソースで書かれていることが確認できたエリヤ（OKですよエリヤ）を増やしていく作業を進めればよいと思います。 はい、そうですね。 ぱっと見ですが基本的に、吉野川流域の市町村と、徳島市周辺の海側を中心にインポートが行われているようです。 (山の中はあまりない、はず) JOSMで比較してみるなら、 基盤地図情報をそのものを背景にして見る（チェックする）ことがベストと思います。はい、それができるかたはそれのほうが良いと思います。 ただ、僕だけなのかもしれませんが、農研さんの基盤地図情報タイルはやたらと反応速度が悪く、 確認にかなりの時間がかかります。 また、元データからの変換も、 慣れたかたはさっとできますが、逆に、そうでないかたにはわりと手間かな、と思っています。 トレースの場合はBingを使われているようなので、 明らかに地理院地図とも異なった場所に建物が描かれているようであり、 地理院タイルでもそれなりに確認の用は足りるように見えます。 http://wiki.openstreetmap.org/wiki/JA:GSI_KIBAN もっといえば、建物データの緯度経度をdiffとってチェックできればよいのですが、 ちょっと僕には難しいです。すみません。 centreeさん 幸いなことに、削除（候補）のデータはおろか、 building=yesのデータも見つからない地域でした。 （わざと難しくなさそうな地域を狙ったのもありますが） いったん論議がまとまるまで作業を止めておきます。 はい、そういった、「対象データのない地域」を確定させることを最初にしよう、という話かと思います。 助かります。 ikiyaさんの案（タスクマネージャ―でまず情報収集） + 適度な期限の設定（期限が過ぎた場合の対応も決めておく）を すると、うまくいくような気もします…が、どうでしょう…？ 期限を切るのはよいですね。 作業の進捗スピードを見ながら決めるのがよいのかな、と思います。 user:kikkawamitsuru もインポートに使われているような気もします ありがとうございます、確認しました。 使われていますね。 Task Managerのほうにも追記を行いました。 また、すみませんが、今週末は僕が全く作業に動けません。 メールは見れると思いますので、ちょっと作業やってみて、 不明点などあればご意見いただけると嬉しいです。 -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [talk-au] Proposed import of 19 bicycle repair stations in au/nz
I just added the five missing stations (now all seven are mapped) around at the University of Queensland, St Lucia campus, Brisbane, early this afternoon: http://www.openstreetmap.org/changeset/29148423 Thought I just let you know (funny coincidence too). Cheers Am 28/02/15 um 15:55 schrieb Bryce Nesbitt: This is a request for comments on a proposed import of 19 bicycle repair stations, per: http://wiki.openstreetmap.org/wiki/Import/Dero_Bike_Repair The station locations are built from press releases and/or the scan of a QR code on the station. Experience shows the positions are good enough to find the location, but not spot on. Unlike many OSM features, these are not armchair mappable via air photo (unless you've got some special in with really good photos). ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au -- Stéphane Guillou If you want to encrypt your emails, please use my public PGP key: 0xE64FEFC7 You can learn about encryption on this website: http://lifehacker.com/how-to-encrypt-your-email-and-keep-your-conversations-p-1133495744 Please share your files in an open format for better interoperability. See http://www.documentliberation.org/ and https://en.wikipedia.org/wiki/Open_format ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [OSM-ja] インポートデータに関する削除について
いいだです。 和歌山県のデータについて、削除作業が完了しました。 ユーザ1029さんによるインポート建物オブジェクトが残っていないことを、OverPass turboで確認を行っています。 次は徳島県のデータの削除なのですが、 こちら、現在の状況を確認したところ、 ひとりで対応するのはかなり難しい状況でした。。。 「私がやる」といっておいて申し訳ないのですが、 以下にタスクとして登録しましたので、みなさま、ご協力をいただけないでしょうか。 http://nyampire.info/project/6 また、徳島県オープンデータ と mitsurukikkawaのアカウントでは、 すみません、引き続き、建物データの編集を実施しないようお願いします。 ``` 上記タスクの手順でも、ユーザによるフィルタをもとに対象となるデータの絞り込みを行います。 そのため、データが削除されているならよいのですが、編集、をされてしまうと、 その建物データが削除対象のデータかどうか、すべて目視でチェックしないといけなくなります。 なるべく早い作業完了のため、何卒ご協力ください。 ``` Tasking Managerの使い方に不安のある方は、 まず最初に海上のなにもオブジェクトがないエリアを選択し、何度かお試し作業をしてみてください。 ■検討事項 インポートによって追加された建物データに対して、 amenity=place_of_worship などのデータが付与されているものが散見されます。 こうしたデータは、新しくノードかエリアのオブジェクトを作成し、 そこにタグを移植して、インポートデータのオブジェクトを削除するのがよいのかな、と思っています。 ただし、正直言って、かなり手間になります。。。 いったんすべて削除をしてしまうのもひとつの手ではありますが、 過去に行われたKSJ2データ(公共施設)とのマージも行われているようで、 すべて削除した場合にはデータのロスがかなり大きいとも思っています。 ご意見いただけると嬉しいです。 -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[Talk-in] Fwd: OpenStreetMap events in 2015
No SoTM from OSMF this year.. But there'd be SoTM-US and SoTM-Scotland in June and October respectively.. Forwarded Message Subject:OpenStreetMap events in 2015 Date: Wed, 25 Feb 2015 01:17:42 + From: OpenStreetMap OpenStreetMap events in 2015 The OpenStreetMap Foundation has been organising the annual State of the Map (SotM) conference since 2007. These events have proved popular with our community and beyond, and have grown from a few dozen attendees to a high of 300 attendees at SotM 2013. This year we had two good bids to host SotM 2015, but issues beyond our control caused concerns about whether we could make this into a success. The SotM working group, with the support of the OSMF board, has therefore agreed that there will be no OSM Foundation organised conference this year. As the OpenStreetMap community has grown over the last 10 years, so has the conference scene. Even without OSMF organising a conference this year, there will still be a number of OSM-centered conferences, including SotM US http://stateofthemap.us/ at the UN’s New York headquarters in June, and SotM-Scotland http://wiki.openstreetmap.org/wiki/State_of_the_Map_Scotland_2015 in October. There are also many webinars, mapping parties, hack events and socials planned http://wiki.openstreetmap.org/wiki/Current_events for 2015. UN General Assembly hall https://www.flickr.com/photos/mukluk/434709325 SotM-US will be held at the UN headquarters in New York, 6-8 June 2015 (image CC-BY 2.0 Dan McKay) https://www.flickr.com/photos/mukluk/434709325/in/photostream/ The StateoftheMap Organizing Committee http://www.osmfoundation.org/wiki/StateoftheMap_Organizing_Committee has taken on a number of new members to support our efforts in 2015, 2016 and beyond. We are currently drafting a proposal on the future of SotM in which we are looking at the role of SotM within the project and how the OSMF SotM relates to the various regional events. We already have some views but we encourage you to share yours in the comments below. Preparations for State of the Map 2016 will be starting soon and we encourage local groups who may be interested in hosting SotM in their home country to contact us early. /Blog post by the StateoftheMap Organizing Committee/ ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne
2015-02-27 10:16 GMT+01:00 Nicolas Moyroud nmoyr...@free.fr: avoir directement les informations attributaires provenant des tags OSM, c'est quand même beaucoup plus exploitable que de devoir aller récupérer des données annexes dans une base externe et les joindre plus ou moins proprement avec les données provenant d'OSM. Avoir à faire ce genre de manipulations peut même être un frein à l'utilisation des données OSM. Mais comme les données dans OSM sont modifiables par n'importe quel gugus, on est de toute façon obligé de les croiser/comparer/vérifier avant une exploitation sérieuse. Ou alors, vous dites que certains attributs ne doivent pas être modifiables... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Coexistence du tag ref:FR:commune et ref:FR:FANTOIR [était CR rencontre DMI de Grenoble]
De: Pieren pier...@gmail.com 2015-02-26 21:31 GMT+01:00 DH dhel...@free.fr: N'est-ce pas là le fond du problème ? Faire un référentiel géographique mutualisé multi-domaines (on balaie large de l'occupation du sol, aux services publics en passant par l'adresse sans oublier les PEI et les limites en tous genres) sans tenir compte des nécessaires connexions avec les réutilisateurs/producteurs. Ces primary key sont nécessaires tant qu'une solution plus durable (uuid géographisée déjà évoquée sur cette liste) n'émerge et fasse consensus. Pour revenir au code ref:FR:commune sur les voies, limité à Orange et son interco pour l'instant, personne ne répond à une de mes questions : si on laisse se propager plusieurs codes uniques pour chaque voie, qui pourra dire stop à la prolifération de ces refs externes ? Et pourquoi vouloir dire stop ? Je te trouve bien pessimiste. Si ces refs sont le témoignage d'un besoin, et d'une réutilisation d'OSM dans un système géré au jour le jour, ça préfigure plutôt d'une maintenance qui, indirectement, a toutes les chances de profiter au contenu OSM en retour. Une voie accidentellement supprimée dans OSM, c'est une alerte potentiel dans le SIG du consommateur, et en retour une correction apportée dans OSM pour remette d'aplomb le référentiel. Ceux qui sont abonnés à la liste import savent à quel point le principe même de ref externe pour le croisement de données est mal accepté, voir refusé au moment des imports. Même le code fantoir doit encore justifier de sa légitimité à l'extérieur de la France. À l'inverse, envisager que le contenu OSM est autonome et peut se passer de clés et autres mécanismes pour interagir avec un contenu externe, c'est largement prétentieux en l'état de la base (je ne dis pas ça pour toi mais ceux qui tiennent ce discours). Et c'est oublier que l'intérêt premier d'OSM est d'être utilisé... Au moment de sa création, on nous a expliqué en long et en large que le cadastre n'étant pas suffisament fiable avec les dénominations, le code FANTOIR servirait à croiser les données OSM avec le cadastre avec succès dans tous les cas. Pour moi le code FANTOIR, et la problématique des rapprochements qui suscite beaucoup de questions et de contributions, est avant tout un outil pour mesurer l'avancement de notre couverture en voies nommées _dans OSM_, au niveau France. C'était ma première motivation pour faire http://cadastre.openstreetmap.fr/fantoir/ : permettre d'y voir clair surle reste à faire, par commune. Mais si maintenant, chacun vient avec son propre code interne, c'est plus difficile à admettre, surtout lorsqu'on sait que l'utilisateur a aussi le code fantoir en local, donc que le croisement automatique reste possible moyennant un petit effort au départ dans la mise en place des outils. Tony a expliqué le souci il me semble : le FANTOIR est long à émerger, localement, et le besoin d'un ID unique pour chaque voie arrive bien avant la publication d'un code FANTOIR. Donc non, l'utilisateur n'a pas _immédiatement_ le code fantoir en local. Ça simplifierait voire annulerait cette discussion, sinon. Denis, tu dis que le fantoir ne vient qu'en deuxième rang. Mais du point de vue d'OSM, il n'y a pas de rang ni de priorité dans les consommateurs de nos données. Il peut y avoir des producteurs de code ref mais nous n'avons pas à connaitre leur hiérarchie, ni leur priorité. A la limite, moi, je n'ai rien contre la généralisation des codes ref:FR:commune mais alors on supprime les codes FANTOIR. Ça rejoint le point ci-dessus sur le nombre de ref distinctes. Je préfère poser la question autrement : si des consommateurs de données veulent s'appuyer sur FANTOIR, et que d'autres préfèrent un ref:FR:commune, pourquoi trancher ? Ce cumul de 2 ref, peut-être demain de 5 ou 10, serait plutôt pour moi un excellent signe : celui que des acteurs qui n'ont rien à voir entre eux, ont tous besoin de consommer nos données, et vont donc avoir un intérêt (une motivation) pour surveiller et maintenir ces données. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Mechanically Cleaning Up FIXME Tags
Le 26.02.2015 19:25, Paul Johnson a écrit : Now that we have an anointed notes system, how about an automated move to notes, with the owner of the note being the person who originated the FIXME? Please, no. On http://resultmaps.neis-one.org/osm-notes-overview, [1] I prefer the first graph, showing how the notes db is already getting clustered -- too many openers, not enough closers. It seems that the OpenStreetBug experience is already getting reproduced (the negative part, not the beginning of it). JB. Links: -- [1] http://resultmaps.neis-one.org/osm-notes-overview, ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mechanically Cleaning Up FIXME Tags
On 27 February 2015 at 14:30, JB jb...@mailoo.org wrote: On http://resultmaps.neis-one.org/osm-notes-overview, I prefer the first graph, showing how the notes db is already getting clustered I find the page in fact a bit hard to read (but apart from that very useful). What is the difference between the first and fourth graph? In my opinion, the main performance indicator should be the monthly number of notes closed. As long as the monthly number of closed notes is increasing, I think it doesn't really matter if the proportion of close-to-open actions is increasing too. Is there any way in which I can read the monthly number of close actions from the graphs? -- Matthijs ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-cz] importy a talk-cz@ Re: ŘOPíky
Nic jste se mnou nediskutovali. Další věci budu dále dělat sám, dle svého nejlepšího vědomí a svědomí, bez Vaší konzultace, kdy neporadíte, ale vytýkáte. Děkuji za nespolupráci a z tohoto fóra odcházím. V tom pripade prosim o dodrzeni vsech pravidel importu. Aha, jednim z nich je diskuze na lokalnim foru, a pak na imports@... Takze ano, ROPiky vitam, ale ne, hromadne importy dle vlastniho svedomi nejsou dobry napad. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] Comment tagger des thermes ?
Il existe un leisure=spa peu utilisé, ainsi qu'un amenity=spa déconseillé. Le 27 février 2015 18:02, Félix Marty felixma...@outlook.com a écrit : Bonjour, J'ai du mal à tagger des thermes. Les tags pouvant être utilisés seraient je pense : amenity=public_bath + ... leisure=swimming_pool + ... landuse=recreation_ground + name=Établissement Thermal (c'est pas très bien) Il y aurait bien la proposition Hot Spring ( http://wiki.openstreetmap.org/wiki/Proposed_features/Hot_Spring ) mais elle ne me convient pas beaucoup. Cordialement, Félix Marty ___ 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-nl] Chipknip tags
On 02/27/2015 09:24 AM, Maarten Deen wrote: De Chipknip is sinds 1 januari niet meer operationeel. Ik denk dat de oplaadpunten nu zo'n beetje overal ook wel weggehaald zijn, in ieder geval zullen ze niet meer operationeel zijn. Volgens Taginfo [1] zijn er nog 292 instances can chipknip in OSM. Ik heb ze even gedownload en de meesten staan op banken (ik heb er in het verleden zelf heel veel toegevoegd) en op winkels. Is het een idee om die in een keer allemaal te verwijderen? Verder is er ook nog een tag voor de betaling met een chipknip, payment:ep_chipknip die veel minder gebruikt is [2], maar die kan ook verwijderd worden. Zijn er redenen om dit niet te doen? De oplaadpaal op Schiphol Plaza staat er (afgelopen maandag) nog en doet het nog - dwz je kan er nog geld terug laten storten, opladen kan uiteraard niet meer. ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-ph] Let's talk about Daang Maharlika Highway (Asian Highway 26)
I edited one ref at EDSA with 2 values of ref=1;AH26. http://osm.org/go/4zhSOFRqJ--?m= Rendering in Mapnik is not bad actually - which somehow approximate the looks of the physical marker http://www.rappler.com/newsbreak/iq/74846-ah26-road-sign It makes the Route 1 bigger and more visible, befitting for it's status as the country's primary backbone, well considering that the earlier single digit 1 route marker was the smallest icon. I will do the rest of EDSA later (or somebody else). Proceeding with caution (EDSA only), wait until I can get confirmation that the double-value ref will not mess up rendering of the majority of mapping ups on smartphones. as it may not be worth it at the moment :-) On Fri, Feb 27, 2015 at 9:32 PM, Rally de Leon rall...@gmail.com wrote: I will first assume that DPWH's Philippine National Highway Network (NHN) map as current and official information: https://dpwh.maps.arcgis.com/apps/OnePane/basicviewer/index.html?appid=4b48284a409844fab6876aa77be8bf58# Is the Route 1 referred in above map exactly equals AH26 updated route? Because, according to DPWH Department Order N0.15-2009: http://www.dpwh.gov.ph/pdf/issuances/DO/09/DO_015_S2009.pdf which requires the DPWH to install Route Markers along Asian Higway (AH26) route comprising MOSTLY segments of the Daang Maharlika commences from Laoag City and finally ends at the international seaport in Zamboanga City --take note of the word MOSTLY, which possibly means not all of Daang Maharlika. So which which? (best evidence is EDSA - AH26 was rerouted from an original alignment) So until verified on actual AH26 signboards in the field, map tracers may still assume it's aligned to the common Maharlika Highway as we originally know, as written on roadsigns, or as indicated on DPWH's NHN Route map. - About the official name (observations): 1. I already saw a couple of old signboards on the road and heard from locals the name Maharlika Highway (particularly in the Laguna and Quezon area), 2. I have seen many articles referring to AH26 as the Daang Maharlika Highway or its acronym/short_name DMH mentioned in some govt contracts, and also the official shortened name Daang Maharlika 3. BUT I have yet to see an old existing road sign that says Pan Philippine Highway or any relatively new article using said Pan Philippine Highway that was not based (or influenced) by the wiki article https://en.wikipedia.org/wiki/Pan-Philippine_Highway#References. What era was Pan-Philippine Highway Can somebody change the wiki article's title from Pan-Philippine Highway to the officially recognized and used Daang Maharlika or Daang Maharlika Highway; and just refer to the former as a historical trivia or as an alternative name? Re: EDSA and C-4 use on ref tag I learned from certain edits of user:joyvious324 that putting two values of ref is officially recognized and rendered on mapnik. I also happen to like the looks and functional (on mapnik) but I don't know if it will mess up Garmin ref rendering and on my favorite Maps.me apps. (eg. on EDSA's route marker C-4 on top of 1 using ref=C-4;1) Proposal (to use 2 values on ref) instead of ref=1 and int_ref=AH26: -Calling said road as C-4 is more of a trivial/historical thing, than being more useful info in giving direction, when you are actually referring to the world famous EDSA (except for the northernmost portion of this road called C-4 for lack of name); and because of the fact that we are being ordered to use both Route 1 and AH26 per compliance with DPWH D.O.15-2009, and as evidenced by the physical route marker already placed along EDSA see picture on: http://www.rappler.com/newsbreak/iq/74846-ah26-road-sign I would like to propose that we experiment the use of ref=1;AH26 tag (at least on EDSA for about 1 to 2 months pending observation if it well mess up the rendering in Garmin and other smartphone apps. :-) -- Relevance of this topic (AH26) was the Mamasapano Incident, wherein the main Mamasapano Highway was referred to a possibly erroneous name Maharlika Highway by many Senators and was already put on official records on Senate investigation. (basing on Google Map data and also previously on OSM which were both based on the wiki Pan Philippine Highway which may still be referring to the old AH26 alignment or a wrong info). In th future, the readers of this Senate report will be confused looking at a different road, which will not correspond to the new updated data on our digital maps (google or osm). There's a need for us to update and/or verify changes in the official routes of all other primary and secondary roads. ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk] Mechanically Cleaning Up FIXME Tags
On Fri, Feb 27, 2015 at 8:17 AM, Greg Troxel g...@ir.bbn.com wrote: I am still not sure I am following. A number of the top fixme values came from a single user, import, or manual (usually JOSM) edit. The proposal is a (semi) mechanical delete to check bounds, other tagging errors, then remove the keys. In other words, the process would start by loading the tagged objects and looking at them to see what's there. If someone wants to revert a changeset or delete data instead, that should be proposed first: http://taginfo.openstreetmap.org/search?q=FIXME ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-be] Viewing recent notes on OSM.org
Hi, How can I receive or view, open de recent notes from this map ? Immediately or after day XX Now I must control them one by one over en over again. Some notes are there longer then 6 months https://www.openstreetmap.org/#map=10/50.9039/4.5305layers=N Jakka ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] [Imports] Mechanically Cleaning Up FIXME Tags
On 27/02/2015, Christoph Hormann chris_horm...@gmx.de wrote: fixme=stream␣attributes␣missing fixme=stream␣attribute␣data␣missing have not been added by an import but in an attempt to fix a broken import. As far as i can see they indicate the waterway in question lacks a tag indicating if it is permanent or intermittent while the source data (NHD) generally contains such attributes and in the area in question a large fraction of waterways are non-permanent. Sensible ways to fix this particular problem would be (1) on the ground survey/check via aerial images (obviously) Aerial images won't let you decide between stream=intermitent and stream=ephemeral. At best you can rule out stream=permanent. So on the ground survey it is. (2) deriving the corresponding tag from existing 'nhd:fcode' tag (like for example here: http://www.openstreetmap.org/way/45949047) (3) newly getting the corresponding tag from the NHD source data (by matching with geometry or id) That looks like a good idea, that kind of data would be interesting to import. 3) should be more robust than 2). Note that in this context, having the objects tagged with fixmes is useless : * the list of stream ways with no stream type can be easily obtained using an overpass query * if importing the stream types from some existing source, the import won't care wether stream=fixme is set or not (it should of course warn about other stream=* values and leave them as-is). Even though there may not be an existing QA tool that checks the presence of stream=*, these tags seem to be as useless as fixme=name_missing. That doesn't mean that I'm eager to see them mass-deleted. IMHO the harm they do is about on par with the version churn of a mass delete would do. As a comparison, getting off-stream-topic for a bit, in Ireland we imported placenames from GNS a while ago, with a bunch of gns tags included just in case at the time and now deemed useless. We still have 7k such objects but we're not planning a mass-cleanup, we're quite happy to manually cleanup whenever we happen to be updating the place for some other reason. (4) remove the whole data where it has not been been modified by manual edits Given the generally sorry state of the NHD/Canvec waterway data in America option (4) might be the better thing to do (we are talking about stuff here that has not been touched for five years). Is the data so bad that you would consider removing it regardless of its fixme tags ? That seems a bit strange to me, but I admit not having looked at the data much. I've said it before, but the presence of bad fixme tags *should not influence* the decision to delete the object or not. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-fr] Comment tagger des thermes ?
Bonjour, J'ai du mal à tagger des thermes. Les tags pouvant être utilisés seraient je pense : amenity=public_bath + ... leisure=swimming_pool + ... landuse=recreation_ground + name=Établissement Thermal (c'est pas très bien) Il y aurait bien la proposition Hot Spring ( http://wiki.openstreetmap.org/wiki/Proposed_features/Hot_Spring ) mais elle ne me convient pas beaucoup. Cordialement, Félix Marty ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-ie] Requesting 17/9 SW
Requesting 17/9 SW pls. [Fermoy/Rathcormack if I am not mistaken] Thanks, - John. ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
[OSM-talk-fr] illustration pour les nouveaux cantons
Salut, Est-ce que quelqu'un pourrait m'indiquer ou me fournir une carte illustrant la modification en cours des cantons ? Peut-être une sorte d'avant/après, sur une zone ? Je voudrais la proposer pour la prochaine édition de weeklyOSM, au moins en version française. althio ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-be] Viewing recent notes on OSM.org
It would be great if it were possible to mark them as done/viewed/processed/handled or todo/followup-upon locally. Jo 2015-02-27 17:59 GMT+01:00 Sander Deryckere sander...@gmail.com: Hi Jakka, I don't think you should care for regions you don't know very well. It's better to let the locals handle it. But as a reply to your question, there's an API build that allows you to download a number of notes: https://wiki.openstreetmap.org/wiki/API_v0.6#Map_Notes_API However, no parameter is included to select on opening date, so you should download all and sort them locally. Some JOSM devs are developing a note reading plugin, maybe that plugin will allow to filter in some way. Regards, Sander 2015-02-27 17:52 GMT+01:00 Jakka vdmfrank...@gmail.com: Hi, How can I receive or view, open de recent notes from this map ? Immediately or after day XX Now I must control them one by one over en over again. Some notes are there longer then 6 months https://www.openstreetmap.org/#map=10/50.9039/4.5305layers=N Jakka ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-ie] Requesting 17/9 SW
Done http://mapwarper.net/maps?field=titlequery=IRL-GSGS-3906-17-09show_warped=0 D On 27 February 2015 at 17:16, John Kennedy jkenned...@gmail.com wrote: Requesting 17/9 SW pls. [Fermoy/Rathcormack if I am not mistaken] Thanks, - John. ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
Re: [OSM-talk] [Imports] Mechanically Cleaning Up FIXME Tags
On Friday 27 February 2015, moltonel 3x Combo wrote: (1) on the ground survey/check via aerial images (obviously) Aerial images won't let you decide between stream=intermitent and stream=ephemeral. At best you can rule out stream=permanent. So on the ground survey it is. I don't think the distinction between ephemeral and seasonal is any easier to make on the ground than via aerial images. But this isn't the point here of course. stream=* is exclusively used by NHD imports by the way. Note that in this context, having the objects tagged with fixmes is useless : * the list of stream ways with no stream type can be easily obtained using an overpass query No, waterway=* defaults to intermittent=no so if you have a waterway=stream from an NHD import with no other tags you don't know if this is permanent based on NHD attributes or just a lousy import. Given the generally sorry state of the NHD/Canvec waterway data in America option (4) might be the better thing to do (we are talking about stuff here that has not been touched for five years). Is the data so bad that you would consider removing it regardless of its fixme tags ? That seems a bit strange to me, but I admit not having looked at the data much. I've said it before, but the presence of bad fixme tags *should not influence* the decision to delete the object or not. The data is not bad at all, it is just badly imported. You simply cannot expect to get out anything meaningful by dumping the geometries as they are and doing a 1:1 translation of some of the NHD attributes into an arbitrary selection of OSM tags. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-be] Viewing recent notes on OSM.org
Hi Jakka, I don't think you should care for regions you don't know very well. It's better to let the locals handle it. But as a reply to your question, there's an API build that allows you to download a number of notes: https://wiki.openstreetmap.org/wiki/API_v0.6#Map_Notes_API However, no parameter is included to select on opening date, so you should download all and sort them locally. Some JOSM devs are developing a note reading plugin, maybe that plugin will allow to filter in some way. Regards, Sander 2015-02-27 17:52 GMT+01:00 Jakka vdmfrank...@gmail.com: Hi, How can I receive or view, open de recent notes from this map ? Immediately or after day XX Now I must control them one by one over en over again. Some notes are there longer then 6 months https://www.openstreetmap.org/#map=10/50.9039/4.5305layers=N Jakka ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-fr] Coexistence du tag ref:FR:commune et ref:FR:FANTOIR [était CR rencontre DMI de Grenoble]
Je prolonge la discussion sur la liste talk-fr parce qu'elle concerne tout le monde et que le contenu d'OSM ne relève pas de l'association: 2015-02-26 21:31 GMT+01:00 DH dhel...@free.fr: N'est-ce pas là le fond du problème ? Faire un référentiel géographique mutualisé multi-domaines (on balaie large de l'occupation du sol, aux services publics en passant par l'adresse sans oublier les PEI et les limites en tous genres) sans tenir compte des nécessaires connexions avec les réutilisateurs/producteurs. Ces primary key sont nécessaires tant qu'une solution plus durable (uuid géographisée déjà évoquée sur cette liste) n'émerge et fasse consensus. : Il ne faut pas se méprendre sur la chaine de valeur de l'information. Comme l'a justement rappelé Tony, la commune est TITULAIRE de la dénomination de la voirie. Le FANTOIR, certes national -merci Napoléon-, n'intervient qu'en 2ème rang avec toutes les erreurs de transcription de graphies, d'homophonies, etc. 2015-02-26 23:22 GMT+01:00 Guillaume Allegre allegre.guilla...@free.fr: MAIS je ne parlais pas de la donnée adresse et voirie (objet succinct du paragraphe suivant), mais des autres objets C'est bien de le préciser ;-) Ca soulève du coup d'autres questions (utilisation du même tag pour des objets totalement différents, quid de la doc, etc) mais bon. Pour revenir au code ref:FR:commune sur les voies, limité à Orange et son interco pour l'instant, personne ne répond à une de mes questions : si on laisse se propager plusieurs codes uniques pour chaque voie, qui pourra dire stop à la prolifération de ces refs externes ? Ceux qui sont abonnés à la liste import savent à quel point le principe même de ref externe pour le croisement de données est mal accepté, voir refusé au moment des imports. Même le code fantoir doit encore justifier de sa légitimité à l'extérieur de la France. Au moment de sa création, on nous a expliqué en long et en large que le cadastre n'étant pas suffisament fiable avec les dénominations, le code FANTOIR servirait à croiser les données OSM avec le cadastre avec succès dans tous les cas. Dont acte. Un argument que je suis aussi prêt à défendre à l'international car c'est une solution incontournable en France. Mais si maintenant, chacun vient avec son propre code interne, c'est plus difficile à admettre, surtout lorsqu'on sait que l'utilisateur a aussi le code fantoir en local, donc que le croisement automatique reste possible moyennant un petit effort au départ dans la mise en place des outils. Denis, tu dis que le fantoir ne vient qu'en deuxième rang. Mais du point de vue d'OSM, il n'y a pas de rang ni de priorité dans les consommateurs de nos données. Il peut y avoir des producteurs de code ref mais nous n'avons pas à connaitre leur hiérarchie, ni leur priorité. A la limite, moi, je n'ai rien contre la généralisation des codes ref:FR:commune mais alors on supprime les codes FANTOIR. Mais on sait tous que les communes peuvent croiser leurs codes avec ceux du cadastre mais que l'inverse n'est pas vrai et que c'est ingérable en dehors de la sphère commune/interco. Il faut rester pragmatique et ne laisser que le seul code fantoir, le seul qui soit ensuite réutilisable pour croiser les fichiers de toutes les communes par tout les consomateurs de données OSM. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [newbie] Pourquoi OSM n'affiche pas les grandes villes?
Bonjour Question de débutant sur un phénomène que je vois souvent sur OSM que ce soit avec le rendu Mapnik ou OCM : la carte affiche de petits patelins mais pas la grande ville à côté. Exemple : OSM affiche Carrières-sous-Poissy mais pas Poissy juste à côté et plus importante: http://www.openstreetmap.org/#map=13/48.9240/2.0617layers=Q Résultat, quand on prépare un parcours et qu'on ignore où se trouve la ville, on ne trouve pas et passage par Google Maps. Quelqu'un sait pourquoi? Merci. -- View this message in context: http://gis.19327.n5.nabble.com/newbie-Pourquoi-OSM-n-affiche-pas-les-grandes-villes-tp5835189.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
Re: [Talk-cz] ŘOPíky
p.s. ještě k předchozímu - původnímu objektu byly dány nové souřadnice a atributy dle ropik.net ... kde se bere jistota, že přispěvatelé ropiky.net mají lepší gpsky než přispěvatelé OSM? Dovolim si reagovat... GPSky mame pravdepodobne vsichni uplne stejne. Jenze je sakra rozdil mezi necim jinym... porovnavas totiz: 1. cloveka, ktery prosel kolem bunkru s GPSkou, a podle toho nakresli bunkr do OSM. 2. databazi bunkru, kde u kazdeho bunkru jsou trebas i desitky ruznych zamereni ruznymi lidlmi v ruznem obdobi, a vysledne souradnice jsou vypocteny jako prumer z techto mereni, navic s ignorovanim 'uletu'. Mno, nevim, v tomto porovnani bych si na OSM nevsadil! :-) Pochopitelne neco jineho bude, kdyz to nebude sedet s RUIAN. Pak bych doporucil se podivat primo na ropiky.net, z kolika a jakych souradnic se ta jejich poloha spocitala, jestli tam nebude neco podezreleho. A pak je na case hledat pricinu nesrovnalosti, protoze by mi prilo divne, kdyby to treba deset lidi zamerilo uplne jinak, nez rika RUIAN, ne? -- Lukas Gebauer. http://synapse.ararat.cz/ - Ararat Synapse - TCP/IP Lib. http://geoget.ararat.cz/ - Geocaching solution ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne
Bonjour, En effet, croiser comparer et vérifier semble obligatoire. Deux vérification doivent être réalisés régulièrement en cas d'ajout; suppression ou modification : - la géométrie Attention en cas de points proches (test à faire sur un tampon sachant que les bornes d’incendie sont au maximum à une distante de x mètres) donc traitement différencier suivant le type de colonne. Ne pas supprimer le point mais le mettre à jour et ne pas supprimer la source initiale) - les attributs (attention une suppression et une recréation change l'id donc ne pas faire de vérification sur ce seul champ en cas de suppression) En cas de modification il faut soit valider soit annuler. C'est le principe de modération suite à modification (mais en externe à OSM). Cela peut être géré par les opérateurs qui fournissent de l'information via des requêtes d'import et de comparaison de version de référentiel. Permet aussi les ajouts externe renseignés par d'autres contributeurs. PS: pour rappel il n'y a pas réellement de système de modération dans OSM sauf vérifier que ses propres ajouts n'ont pas fait l'objet d'une révision par un autre contributeur. C'est le cas des points de géodésie qui ne doivent pas être modifié mais qui pourraient l'être par mégarde. Il y a un batch de restauration il me semble. Pour les infos propre à l'exploitation je ne vois pas trop ou est le problème (cas de RTE). C'est un balisage spécifique débit et autre qui permettrait d'avoir l'info sur le terrain rapidement pour les équipes d'intervention si OSM est au finale utilisé pour cela. Agrémenté d'un GPS avec fond OSM et la base adresse à jour, ce serait vraiment un outil puissant pour les interventions. A savoir qu'en France c'est un opérateur public mais que ce n'est pas le cas partout en Europe! Dans certains cas extrême, les équipes d'intervention peuvent être prêté à d'autres pays (Cas de gros incendies ou incendies frontaliers) En tous cas OsmHydrant http://www.osmhydrant.org/fr/# est pratique pour détecter les zones ou les colonnes sont pas encore renseignées. Pour le coté vérif, c'est soit en analyse coté ESRI soit coté OSM avec Osmose. Pour une vérification spatiale de proximité je partirai plus sur du ESRI avec un formulaire de mise à jour entre point A (coté interne) et point B (coté OSM) avec mise à jour ( bascule attributaire + spatiale) et type de mise à jour et de validation dans la base interne avec suivi historique Jérôme Le 27 février 2015 13:44, Pieren pier...@gmail.com a écrit : 2015-02-27 10:16 GMT+01:00 Nicolas Moyroud nmoyr...@free.fr: avoir directement les informations attributaires provenant des tags OSM, c'est quand même beaucoup plus exploitable que de devoir aller récupérer des données annexes dans une base externe et les joindre plus ou moins proprement avec les données provenant d'OSM. Avoir à faire ce genre de manipulations peut même être un frein à l'utilisation des données OSM. Mais comme les données dans OSM sont modifiables par n'importe quel gugus, on est de toute façon obligé de les croiser/comparer/vérifier avant une exploitation sérieuse. Ou alors, vous dites que certains attributs ne doivent pas être modifiables... Pieren ___ 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] [propostition] Changement massif natural=rock vers bare_rock pour les surfaces ?
Et comme peu de réponses/d'intérêt (ça doit être moins sexy que les Fantoirs ou les débits de bornes incendie, j'approuve, j'encourage, (et je ne m'opposerais pas à ce que tu ailles plus loin, mais là, en tous cas, je ne vois pas qui ne serait pas d'accord). JB. Le 27.02.2015 11:47, sly (sylvain letuffe) a écrit : N'ayant pas eu beaucoup de réponse, je me permets une relance, pour une version réduite : J'ai 1083 ways et relation avec avec : natural=rock et source=Union européenne - SOeS, CORINE Land Cover, 2006. Je propose de m'en tenir à la conversion uniquement de ceux-là en natural=bare_rock ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne
Le 27 février 2015 09:54, MASSIOT Dominique dominique.mass...@sdis29.fr a écrit : Mais c'est vrai que il faut trouver un moyen de vérifier si qqn modifie les valeurs (à tort ou à raison), soit par erreur, soit par exemple autorisation du Sdis de modif des valeurs lors des tournées des PEI par les agents. Désolé de le dire mais le principe d'OSM avec une base libre c'est qu'on n'a surtout pas besoin d'autorisation d'un tiers pour modifier des données. En revanche on peut demander des sources, et c'est là que le SDIS peut fournir un source fiable servant aux vérifications. Si la base de données du SDIS n'as pas d'infos, la donnée dans OSM peut encore servir au SDIS qui fera ses propres vérifications on peut demander aux contributeurs de laisser une note indiquant que la source de référence a été avisée : il faut donc que cette dernière dispose d'un point de contact permettant de lui signaler les manques ou erreurs dans sa base, et d'une équipe pour gérer ces retours d'informations de la part du public (que celui-ci vienne d'OSM ou pas d'ailleurs). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-ie] Sheet request 26/17
Uploaded: http://mapwarper.net/maps?field=titlequery=IRL-GSGS-3906-26-17show_warped=0 D On 27 February 2015 at 10:19, Mark Tully markjtu...@gmail.com wrote: Hi, Can I request that 26/17 NW and SW be uploaded, please. Mark ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
Re: [OSM-talk-ie] Tag for lay by
On Fri, 2015-02-27 at 13:33 +, Karl Newsletters wrote: Could I also suggest highway=rest_area http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area if the area is meant to be used as a lay-by (e.g where you could pull in for a longer stop) If it is a bigger loop, i.e. they have straightened the road and just left a loop or ox-bow (inter cert geography -how are ye!). How about adding disused=yes to the usual highway tag? That would imply that the road is not accessible, whereas in reality these become lay-bys, where you can park to go for a walk, a bike ride, or just for a rest. I would tend to tag them as highway=service, service=parking_aisle and mark them with either a parking node, or a parking area if big enough. Phil (trigpoint) ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne
De: Jérôme Seigneuret jseigneuret-...@yahoo.fr - la géométrie Attention en cas de points proches (test à faire sur un tampon sachant que les bornes d’incendie sont au maximum à une distante de x mètres) donc traitement différencier suivant le type de colonne. Ne pas supprimer le point mais le mettre à jour et ne pas supprimer la source initiale) La proximité géométrique ne peut pas être un critère. Tu trouves en urbain des hydrants littéralement côte à côte, à quelques cm l'un de l'autre [1], et à l'inverse tu peux longer une route sur plusieurs km sans croiser aucun hydrant, faute par exemple de bâtiment ou d'installation motivant une implantation. En cas de modification il faut soit valider soit annuler. C'est le principe de modération suite à modification (mais en externe à OSM). Cela peut être géré par les opérateurs qui fournissent de l'information via des requêtes d'import et de comparaison de version de référentiel. Permet aussi les ajouts externe renseignés par d'autres contributeurs. PS: pour rappel il n'y a pas réellement de système de modération dans OSM sauf vérifier que ses propres ajouts n'ont pas fait l'objet d'une révision par un autre contributeur. C'est le cas des points de géodésie qui ne doivent pas être modifié mais qui pourraient l'être par mégarde. Il y a un batch de restauration il me semble. Une différence de taille avec les repères géodésiques, c'est le caractère référentiel de leur position géographique. Par définition, les repères ne peuvent bouger. Côté hydrants, s'agissant de relevés terrain par les contributeurs, ou de relevés via les SDIS, le positionnement n'a rien de parfait. Ça ne me semble ni réaliste (vu le caractère imparfait des sources) ni souhaitable sur le principe, de brancher sur ce contenu des bots de surveillance afin de reverter toute modification. En tous cas OsmHydrant est pratique pour détecter les zones ou les colonnes sont pas encore renseignées. Pour l'instant, la détection est assez facile :) http://taginfo.openstreetmap.fr/tags/emergency=fire_hydrant dit qu'en France on a 21000 PEI. Un lien donné récemment par François rappelle qu'un hydrant doit avoir un rayon d'action de 200m. L'INSEE [2] estime à 12 km2 la superficie urbaine en France. Mélangez tout ça et vous obtenez un besoin théorique d'hydrants d'environ 95 PEI. On ne serait donc pour l'instant qu'à 2% de couverture... y'a de la marge. vincent [1] : http://www.osmhydrant.org/en/#zoom=18lat=48.846715lon=2.316513 [2] : http://www.insee.fr/fr/themes/document.asp?reg_id=0ref_id=ip1364%C2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Coexistence du tag ref:FR:commune et ref:FR:FANTOIR [était CR rencontre DMI de Grenoble]
Le 27 février 2015 13:33, Pieren pier...@gmail.com a écrit : Je prolonge la discussion sur la liste talk-fr parce qu'elle concerne tout le monde et que le contenu d'OSM ne relève pas de l'association: 2015-02-26 21:31 GMT+01:00 DH dhel...@free.fr: Il ne faut pas se méprendre sur la chaine de valeur de l'information. Comme l'a justement rappelé Tony, la commune est TITULAIRE de la dénomination de la voirie. Le FANTOIR, certes national -merci Napoléon-, n'intervient qu'en 2ème rang avec toutes les erreurs de transcription de graphies, d'homophonies, etc. Et encore une fois on oublie de dire que la commune n'est TITULAIRE de la dénomination QUE pour la partie de la voirie située sur son territoire. Ce qui exclut les côtés des voiries situées sur une commune limitrophe (les deux communes peuvent se mettre d'accord pour utiliser le même nom, mais elles n'ont aucune obligation de le faire, même si elles sont dans la même intercommunalité, et notamment quand le segment de voirie partagé se prolonge à une extrémité ou l'autre (voire les deux) par un segment dont les deux côtés sont entièrement sur son territoire. Orange et sa CCPRO n'ont peut-être pas ce cas de doubles noms, mais Tony a voulu généraliser un peut vite à toutes les communes de France. Du coup on peut malgré tout se retrouver avec DEUX ref:FR:commune=* selon sa proposition de tag ! Toute la discussion à ce sujet est partie sur ce simple constat. J'ai encore une fois l'impression que personne ne veut le comprendre. Ça remet en cause le tag ref:FR:commune=* sur le segment de voie partagée (objet de type way dans OSM) sur ces cas là (et aussi le code FANTOIR propre à chaque commune). C'est là dessus qu'on a admis qu'il faudrait deux relations type=associatedStreet, avec pour chacune ses propres références en tags : ref:FR:commune=*, ref:FR:FANTOIR=*, addr:city=*... ainsi que addr:postcode=* (qui cependant a de grande chances d'être le même entre les deux relations, la Poste ne séparant que rarement ses tournées selon le côté de la rue, même si les deux cotés ne sont pas sur les mêmes communes, comme elle le fait en zone frontalière des communes rurales quand le chemin d'accès le plus pratique vers une ferme isolée vient de la commune voisine, la zone de distribution postale ne suivant pas toujours exactement les limites administratives). Et dans ce cas le name=* qu'on indique sur le chemin devrait inclure les deux noms avec un séparateur adéquat (le point-virgule collé n'est pas pratique, il est plus courant de mettre un nom unique avec un / encadré d'espaces), ou un seul nom si c'est le seul affiché sur place (parce qu'il n'y a encore aucune adresse sur le côté de l'autre commune et que celle-ci n'a pas jugé utile d'y poser un panneau indicateur); la relation type=associatedStreet devrait aussi avoir un tag name=* par défaut non ambigu (suffixé par le nom de la commune), et le nom isole de la voirie pour la commune concernée sera dans le tag addr:street=* de la relation. En résumé pour trouver le nom de voie effectif et sa référence FANTOIR (ou communale) pour les adresses postales, il faudrait : - regarder d'abord s'il existe une ou deux relations type=associatedStreet reprenant le segment de voie. - puis distinguer la commune pour savoir quelle relation type=associatedStreet utiliser quand il y en a deux (avec un problème : addr:city est le nom **postal** et pas toujours le nom de la commune elle-même, ce peut être une le nom d'une section de commune, la commune réelle étant omise des adresses postales, cas fréquent en cas de communes rurales fusionnées comportant plusieurs villages, qui d'ailleurs peuvent avoir conservé des codes postaux distincts): en cas d'ambiguïté on pourrait utiliser la codification proposée par Tony qui inclue dans ref:FR:commune les 5 chiffres du code INSEE (ce peut être un code INSEE d'une ancienne commune avant sa fusion ou celui d'une commune associée ou déléguée, ce code figure d'ailleurs encore dans le cadastre des communes fusionnée pour distinguer les numéros de sections cadastrales : il est marqué en préfixe avant le code Lettre+Chiffres de cette section pour les sections venant d'une commune associée ou déléguée) - puis regarder dans le relation addr:street=* (s'il y est il est prioritaire sur le name=* de la relation qui peut avoir des suffixes informatifs de désambiguïsation), - sinon le name=* de la relation, - sinon en dernier lieu le name=* du segment de voie (objet de type way). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] インポートデータに関する削除について
ikiyaです。 徳島県のインポートデータについてですが、 タスクマネージャーを使うのは賛成ですが、 削除にはもうワンステップ置いてもようかと思います。 まず、タクスマネージャーを使って、明らかに基盤地図情報以外のソースで書かれていることが確認できたエリヤ（OKですよエリヤ）を増やしていく作業を進めればよいと思います。 その結果、インポートデータが残っていそうなエリアが絞りだされるので、当事者とさらに話し合いや削除を依頼するなりの手立てができるかと思います。 さらにJOSM上で地理院地図の標準タイルと重ねて比較しても、 地理院タイルの解像度の低さや、地理院タイルのレンダリングと基盤地図情報の建築物外周線との違いから JOSM上での判断には難しい面もあります。 JOSMで比較してみるなら、基盤地図情報をそのものを背景にして見る（チェックする）ことがベストと思います。 JOSMでのチェックですが見てみると この周辺はまだ建物に２重ノードが大量に残っています。 http://www.openstreetmap.org/#map=18/34.17339/134.62052 このような場所を手分けして確認しあう作業がよろしいのではないでしょうか。 - Original Message - From: Satoshi IIDA nyamp...@gmail.com To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2015/2/27, Fri 21:28 Subject: Re: [OSM-ja] インポートデータに関する削除について いいだです。 和歌山県のデータについて、削除作業が完了しました。 ユーザ1029さんによるインポート建物オブジェクトが残っていないことを、OverPass turboで確認を行っています。 次は徳島県のデータの削除なのですが、 こちら、現在の状況を確認したところ、 ひとりで対応するのはかなり難しい状況でした。。。 「私がやる」といっておいて申し訳ないのですが、 以下にタスクとして登録しましたので、みなさま、ご協力をいただけないでしょうか。 http://nyampire.info/project/6 また、徳島県オープンデータ と mitsurukikkawaのアカウントでは、 すみません、引き続き、建物データの編集を実施しないようお願いします。 ``` 上記タスクの手順でも、ユーザによるフィルタをもとに対象となるデータの絞り込みを行います。 そのため、データが削除されているならよいのですが、編集、をされてしまうと、 その建物データが削除対象のデータかどうか、すべて目視でチェックしないといけなくなります。 なるべく早い作業完了のため、何卒ご協力ください。 ``` Tasking Managerの使い方に不安のある方は、 まず最初に海上のなにもオブジェクトがないエリアを選択し、何度かお試し作業をしてみてください。 ■検討事項 インポートによって追加された建物データに対して、 amenity=place_of_worship などのデータが付与されているものが散見されます。 こうしたデータは、新しくノードかエリアのオブジェクトを作成し、 そこにタグを移植して、インポートデータのオブジェクトを削除するのがよいのかな、と思っています。 ただし、正直言って、かなり手間になります。。。 いったんすべて削除をしてしまうのもひとつの手ではありますが、 過去に行われたKSJ2データ(公共施設)とのマージも行われているようで、 すべて削除した場合にはデータのロスがかなり大きいとも思っています。 ご意見いただけると嬉しいです。 -- 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
Re: [Talk-de] Strittige Adressen / Gemeindegrenzen
Das gibt es in der Tat! Sehr gutes Beispiel dafür, ist der Technologiepark Tübingen-Reutlingen (TTR). Dieser liegt in der Gemeinde Kusterdingen, aber im PLZ-Gebiet Reutlingen (Telefonvorwahl auch von Reutlingen). Am 27.02.2015 um 15:28 schrieb Hartmut Holzgraefe: On 26.02.2015 12:38, Florian Lohoff wrote: Ich habe bisher die Aussage vertreten das wir alle Adressen aufnehmen die in Benutzung sind und nicht nur die die offiziell im ALK stehen und von der Gemeinde vergeben werden (Mal davon abgesehen das die Gemeinden die Postleitzahlen gar nicht vergeben). Bei Telefonvorwahlen gibt es ja gelegentlich mal den Fall dass Anschlüsse zwar in Gemeinde A liegen, aber über die Ortsvermittlung in B angebunden sind und deshalb auch die Vorwahl von B haben ... Gibts das auch bei Postleitzahlen? D.h. amtlich steht das Haus zwar in Bielefeld, für die Post ist es aber einfacher da den Gütersloher Postboten vorbeizuschicken? Und so landet das Haus in einem Gütersloher Zustellbezirk mit entsprechender nicht-Bielefelder Postleitzahl? Und wenn ja: müssten wir dann für solche Sonderfälle statt einfach nur addr:*=... entsprechend official_addr:...= und postal_addr:...= unterscheiden? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] [newbie] Pourquoi OSM n'affiche pas les grandes villes?
La carte par défaut d'openstreetmap.org est plutôt technique : elle affiche plains d'infos mais ne sait pas toujours les classer. Fixer des priorités d'affichage est compliqué sur une carte mondiale où chacun a son point de vue sur ce que la carte devrait afficher. Ses règles d'affichages sont simples pour que la carte qu'il affiche par défaut (il en propose plusieurs autres) puisse être la plus actualisée possible pour montrer ce qui est dans la base (même des modifs récentes, et même si elles ont des erreurs). Ces noms affichés dépendent du niveau de zoom et de la densité des libellés susceptibles de s'y afficher (elle ne peut pas tout mettre, elle fonctionne surtout au premier trouvé premier affiché, mais une fois la place prise, il ne peut pas remplacer le libellé affiché d'une petite ville par celui d'une autres). Tu peux chercher d'autres rendus, plus efficaces pour la France comme celui d'openstreetmap.fr, ou voir le rendu de Mapquest, qui ont de meilleures règles de priorité et préparent des listes de libellés en les classant par priorité *avant* de commencer à les dessiner dans les tuiles (ce que fait aussi Google dans sa carte, sauf qu'en plus il tient compte du profil utilisateur pour ne pas afficher la même chose pour tout le monde... OSM ne profile pas ses utilisateurs, ne les piste pas selon les autres sites qu'il a visités ou selon ses déplacements repérés sur les smartphones équipés GPS et les produits et marques dont il a visité les sites ou sur lesquelles il a effectué des recherches sur le web ou suivi un lien publicitaire : ce n'est pas un robot qui choisit ce que l'utilisateur doit voir, c'est à l'utilisateur de choisir ce qu'il veut voir, en choisissant son rendu). Openstreetmap.org au départ n'est pas un service cartographique en tant que tel, c'est avant tout une interface pour contribuer aux données de sa base. Pour une utilisation en visualisation simple, il vaut mieux ne pas utiliser son rendu, connaissant ses faiblesses et le fait qu'il n'a pas été vraiment étudié pour un usage particulier (comme celui que tu veux pour préparer un parcours). Le 27 février 2015 15:32, Shohreh codecompl...@free.fr a écrit : Bonjour Question de débutant sur un phénomène que je vois souvent sur OSM que ce soit avec le rendu Mapnik ou OCM : la carte affiche de petits patelins mais pas la grande ville à côté. Exemple : OSM affiche Carrières-sous-Poissy mais pas Poissy juste à côté et plus importante: http://www.openstreetmap.org/#map=13/48.9240/2.0617layers=Q Résultat, quand on prépare un parcours et qu'on ignore où se trouve la ville, on ne trouve pas et passage par Google Maps. Quelqu'un sait pourquoi? Merci. -- View this message in context: http://gis.19327.n5.nabble.com/newbie-Pourquoi-OSM-n-affiche-pas-les-grandes-villes-tp5835189.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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Serveur proxy de tuiles du cadastre avec mode joker
Merci Vincent(s) pour vos réponse :-) J'ai ajouté une entrée avec les limites de la métropole (avec la Corse). -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-de] Positionsgenauigkeit der Daten (war: admin schläft)
Am 26.02.2015 um 22:39 schrieb Joachim: Nicht spekulieren, ins Wiki schauen! :) Habe in den letzten Wochen da kräftig dokumentiert und im Forum darüber diskutiert. Hat zwar keine hübschen Bilder sollte aber relativ komplett sein. http://wiki.openstreetmap.org/wiki/Stuttgart/Transportation An den Haltestellen solltes es train=yes anstatt rail=yes sein [1]. cu fly [1] https://wiki.openstreetmap.org/wiki/Key:public_transport#Values ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strittige Adressen / Gemeindegrenzen
On 26.02.2015 12:38, Florian Lohoff wrote: Ich habe bisher die Aussage vertreten das wir alle Adressen aufnehmen die in Benutzung sind und nicht nur die die offiziell im ALK stehen und von der Gemeinde vergeben werden (Mal davon abgesehen das die Gemeinden die Postleitzahlen gar nicht vergeben). Bei Telefonvorwahlen gibt es ja gelegentlich mal den Fall dass Anschlüsse zwar in Gemeinde A liegen, aber über die Ortsvermittlung in B angebunden sind und deshalb auch die Vorwahl von B haben ... Gibts das auch bei Postleitzahlen? D.h. amtlich steht das Haus zwar in Bielefeld, für die Post ist es aber einfacher da den Gütersloher Postboten vorbeizuschicken? Und so landet das Haus in einem Gütersloher Zustellbezirk mit entsprechender nicht-Bielefelder Postleitzahl? Und wenn ja: müssten wir dann für solche Sonderfälle statt einfach nur addr:*=... entsprechend official_addr:...= und postal_addr:...= unterscheiden? -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-in] Fwd: OpenStreetMap events in 2015
I am part of the organizing committee of State of the Map US this year. There is a great scholarship program to offset travel cost and the call for proposals is open. Check out the web site: http://stateofthemap.us/about/ On Fri, Feb 27, 2015 at 7:49 PM, Yogesh योगि yog...@karnatakaeducation.org.in wrote: No SoTM from OSMF this year.. But there'd be SoTM-US and SoTM-Scotland in June and October respectively.. Forwarded Message Subject: OpenStreetMap events in 2015 Date: Wed, 25 Feb 2015 01:17:42 + From: OpenStreetMap The OpenStreetMap Foundation has been organising the annual State of the Map (SotM) conference since 2007. These events have proved popular with our community and beyond, and have grown from a few dozen attendees to a high of 300 attendees at SotM 2013. This year we had two good bids to host SotM 2015, but issues beyond our control caused concerns about whether we could make this into a success. The SotM working group, with the support of the OSMF board, has therefore agreed that there will be no OSM Foundation organised conference this year. As the OpenStreetMap community has grown over the last 10 years, so has the conference scene. Even without OSMF organising a conference this year, there will still be a number of OSM-centered conferences, including SotM US http://stateofthemap.us/ at the UN’s New York headquarters in June, and SotM-Scotland http://wiki.openstreetmap.org/wiki/State_of_the_Map_Scotland_2015 in October. There are also many webinars, mapping parties, hack events and socials planned http://wiki.openstreetmap.org/wiki/Current_events for 2015. [image: UN General Assembly hall] https://www.flickr.com/photos/mukluk/434709325 SotM-US will be held at the UN headquarters in New York, 6-8 June 2015 (image CC-BY 2.0 Dan McKay) https://www.flickr.com/photos/mukluk/434709325/in/photostream/ The StateoftheMap Organizing Committee http://www.osmfoundation.org/wiki/StateoftheMap_Organizing_Committee has taken on a number of new members to support our efforts in 2015, 2016 and beyond. We are currently drafting a proposal on the future of SotM in which we are looking at the role of SotM within the project and how the OSMF SotM relates to the various regional events. We already have some views but we encourage you to share yours in the comments below. Preparations for State of the Map 2016 will be starting soon and we encourage local groups who may be interested in hosting SotM in their home country to contact us early. *Blog post by the StateoftheMap Organizing Committee* ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
Re: [OSM-talk-fr] Coexistence du tag ref:FR:commune et ref:FR:FANTOIR [était CR rencontre DMI de Grenoble]
2015-02-27 14:40 GMT+01:00 Vincent de Château-Thierry osm.v...@free.fr: Tony a expliqué le souci il me semble : le FANTOIR est long à émerger, localement, et le besoin d'un ID unique pour chaque voie arrive bien avant la publication d'un code FANTOIR. Donc non, l'utilisateur n'a pas _immédiatement_ le code fantoir en local. Ça simplifierait voire annulerait cette discussion, sinon. La discussion ne concerne que les voies qui ont déjà un code FANTOIR. Pour une commune, j'imagine que c'est l'immense majorité des cas. Pour les voies nouvelles qui n'ont pas encore de ref FANTOIR, j'ai déjà répondu par ailleurs que le tag ref:FR:commune était compréhensible, faute de mieux. si des consommateurs de données veulent s'appuyer sur FANTOIR, et que d'autres préfèrent un ref:FR:commune, pourquoi trancher ? Ce cumul de 2 ref, peut-être demain de 5 ou 10, serait plutôt pour moi un excellent signe : celui que des acteurs qui n'ont rien à voir entre eux, ont tous besoin de consommer nos données, et vont donc avoir un intérêt (une motivation) pour surveiller et maintenir ces données. Ben non, c'est là où on ne va pas être d'accord (tant pis, c'est pas mortel) et où tu va avoir beaucoup de mal à convaincre le reste des contributeurs. Multiplier les tags ref montre certes une belle dynamique de réutilisation mais elle rend surtout l'interprétation des données plus difficile par les humains... et inutile. Ce sont d'abord les humains qui maintiennent et maintiendront la voirie OSM dans le futur, pas des programmes de synchronisation avec des référentiels externes que personne n'a encore vu à l'oeuvre après 10 ans. Nous avons tout à gagner à utiliser un uuid (identifiant unique). Comme cela n'existe pas par défaut dans OSM, on peut parfaitement adopter le code FANTOIR et s'en contenter (et le ref:FR:commune là où il n'y en a pas). Sans vouloir être jacobin, il a l'avantage d'être déjà public, présent et cohérent sur l'ensemble du territoire, our toutes les communes, ce qui n'est pas le cas d'un ref:FR:commune. Concernant la prolifération de tags abscons, lorsqu'il y a des discussions sur les listes de diffusion internationales et qu'il faut choisir entre le confort des contributeur et celui des consommateurs (souvent pour éviter de faire un petit effort de programmation d'ailleurs), c'est toujours celui des contributeurs qui est au final privilégié car c'est le contributeur lambda, celui qui est près du terrain, qui fait la force du projet. La liste imports est remplie d'exemples de refs externes remis en question ou même finalement rejetés pour un import de nouveaux objets dans OSM. Alors en mettre 5 ou 10... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [newbie] Pourquoi OSM n'affiche pas les grandes villes?
Bonjour, A priori - car c'est le cas avec le rendu Mapnik utilisé par Mapbox - c'est parce qu'il y a une algorithme qui fait en sorte que les titres ne se chevauchent pas. Probablement, dans le cas cité, Poissy ne s'affiche pas car sinon le titre se chevauchera avec les panneaux routiers. Et puis, sauf pour les très grandes villes (scalerank 1 à 9), si j'ai bien compris, il n y a pas de hiérarchisation des villes selon la taille ou la population. Bonne fin de journée ! Joseph Rabie. Joseph Rabie ATELIER INTERNATIONAL DU GRAND PARIS Palais de Tokyo 13 avenue du Président Wilson 75116 - PARIS tél : + 33 (0)1.76.21.04.86 http://www.ateliergrandparis.fr _ Le 27/02/2015 15:32, Shohreh a écrit : Bonjour Question de débutant sur un phénomène que je vois souvent sur OSM que ce soit avec le rendu Mapnik ou OCM : la carte affiche de petits patelins mais pas la grande ville à côté. Exemple : OSM affiche Carrières-sous-Poissy mais pas Poissy juste à côté et plus importante: http://www.openstreetmap.org/#map=13/48.9240/2.0617layers=Q Résultat, quand on prépare un parcours et qu'on ignore où se trouve la ville, on ne trouve pas et passage par Google Maps. Quelqu'un sait pourquoi? Merci. -- View this message in context: http://gis.19327.n5.nabble.com/newbie-Pourquoi-OSM-n-affiche-pas-les-grandes-villes-tp5835189.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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSRM-talk] Transit routing
I have already built a Transit routing machine. It’s currently coded in Ruby on Rails, but if someone wants to build it with C++ to enhance calculations, it would be great. Right now, one calculation takse between 2 and 10 seconds for a network with multiple agencies and more than 9 millions stop times for a specific service time. The algorithm used is http://i11www.iti.uni-karlsruhe.de/extra/publications/dpsw-isftr-13.pdf It uses OSRM for transfer routing (walking). Contact me for more information about this. On Feb 27, 2015, at 3:33 AM, Dennis Luxen i...@project-osrm.org wrote: Hi, there are no immediate plans to build a transit router. —Dennis — Want to support OSRM development? Buy us a beer: http://www.amazon.de/registry/wishlist/1V2TKTFOZIU80 Am 27.02.2015 um 07:20 schrieb Mark Lester mc_les...@yahoo.co.uk: What plans, if any, are there to handle public transit systems in OSRM, and thus subsequently OSM. I am trying to develop an open access GTFS editor. I am running a route planning service using OTP, but I only really need that as part of a developer/editor environment, i.e with which to test a timetable before submitting. If I can shove my data at OSM I hope to get at some groups , in particular in India, to work on early projects and to get some momentum for developing a public Potlach for timetables. If anyone else has GTFS editor they want or already have floated, please get in touch. WikiTimetabe - Crowd Sourced Trip Planner WikiTimetabe - Crowd Sourced Trip Planner WikiTimeTable - Crowd Sourced Trip Planner - Choose a country from View on wikitimetable.com Preview by Yahoo ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSM-talk-ie] Tag for lay by
Could I also suggest highway=rest_area http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area if the area is meant to be used as a lay-by (e.g where you could pull in for a longer stop) If it is a bigger loop, i.e. they have straightened the road and just left a loop or ox-bow (inter cert geography -how are ye!). How about adding disused=yes to the usual highway tag? On 26 February 2015 at 10:33, moltonel 3x Combo molto...@gmail.com wrote: On 25/02/2015, Dave Corley davecor...@gmail.com wrote: Passing place might be the most suitable if that's the most likely usage. Do you have a link to the location? +1 for highway=passing_place. See the photo on the wiki[1], it doesn't have to be a grand feature. Remember that tag values may have been standardized by people whose dialect of English differ from yours. [1]:http://wiki.openstreetmap.org/wiki/Tag:highway=passing_place On 25 Feb 2015 22:23, Caroline Lewis carolinele...@eircom.net wrote: HI - what tag should be used for a lay-by - i have used passing place but not sure if that is correct - and lay-by maybe a bit grand for what looks like the old road which was left as a bit of a pull- in and there seems to be no tag for a lay-by ... ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
[talk-ph] Let's talk about Daang Maharlika Highway (Asian Highway 26)
I will first assume that DPWH's Philippine National Highway Network (NHN) map as current and official information: https://dpwh.maps.arcgis.com/apps/OnePane/basicviewer/index.html?appid=4b48284a409844fab6876aa77be8bf58# Is the Route 1 referred in above map exactly equals AH26 updated route? Because, according to DPWH Department Order N0.15-2009: http://www.dpwh.gov.ph/pdf/issuances/DO/09/DO_015_S2009.pdf which requires the DPWH to install Route Markers along Asian Higway (AH26) route comprising MOSTLY segments of the Daang Maharlika commences from Laoag City and finally ends at the international seaport in Zamboanga City --take note of the word MOSTLY, which possibly means not all of Daang Maharlika. So which which? (best evidence is EDSA - AH26 was rerouted from an original alignment) So until verified on actual AH26 signboards in the field, map tracers may still assume it's aligned to the common Maharlika Highway as we originally know, as written on roadsigns, or as indicated on DPWH's NHN Route map. - About the official name (observations): 1. I already saw a couple of old signboards on the road and heard from locals the name Maharlika Highway (particularly in the Laguna and Quezon area), 2. I have seen many articles referring to AH26 as the Daang Maharlika Highway or its acronym/short_name DMH mentioned in some govt contracts, and also the official shortened name Daang Maharlika 3. BUT I have yet to see an old existing road sign that says Pan Philippine Highway or any relatively new article using said Pan Philippine Highway that was not based (or influenced) by the wiki article https://en.wikipedia.org/wiki/Pan-Philippine_Highway#References. What era was Pan-Philippine Highway Can somebody change the wiki article's title from Pan-Philippine Highway to the officially recognized and used Daang Maharlika or Daang Maharlika Highway; and just refer to the former as a historical trivia or as an alternative name? Re: EDSA and C-4 use on ref tag I learned from certain edits of user:joyvious324 that putting two values of ref is officially recognized and rendered on mapnik. I also happen to like the looks and functional (on mapnik) but I don't know if it will mess up Garmin ref rendering and on my favorite Maps.me apps. (eg. on EDSA's route marker C-4 on top of 1 using ref=C-4;1) Proposal (to use 2 values on ref) instead of ref=1 and int_ref=AH26: -Calling said road as C-4 is more of a trivial/historical thing, than being more useful info in giving direction, when you are actually referring to the world famous EDSA (except for the northernmost portion of this road called C-4 for lack of name); and because of the fact that we are being ordered to use both Route 1 and AH26 per compliance with DPWH D.O.15-2009, and as evidenced by the physical route marker already placed along EDSA see picture on: http://www.rappler.com/newsbreak/iq/74846-ah26-road-sign I would like to propose that we experiment the use of ref=1;AH26 tag (at least on EDSA for about 1 to 2 months pending observation if it well mess up the rendering in Garmin and other smartphone apps. :-) -- Relevance of this topic (AH26) was the Mamasapano Incident, wherein the main Mamasapano Highway was referred to a possibly erroneous name Maharlika Highway by many Senators and was already put on official records on Senate investigation. (basing on Google Map data and also previously on OSM which were both based on the wiki Pan Philippine Highway which may still be referring to the old AH26 alignment or a wrong info). In th future, the readers of this Senate report will be confused looking at a different road, which will not correspond to the new updated data on our digital maps (google or osm). There's a need for us to update and/or verify changes in the official routes of all other primary and secondary roads. ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne
Bah... sans débit/pression, OSM fournit l'emplacement des piscines... qui servent de point d'eau d'urgence ici (pour les hélicos en cas de feux de forêts, ou pour les pompes des équipes de secours). Les questions de facture d'eau se règlent après, avec les assurances. Le jour où un feu de forêt menace, de toute façon ceux qui ont ces piscines pleines sont ravis de voir que la sécurité civile va pouvoir sauver leur propriété avec l'eau qui y est (d'autant plus que dans ces endroits isolés les pressions d'eau et débits sont assez faibles, que ça vienne du réseau public ou d'une pompe privée dans un puits, ou d'un système de récupération et filtration). OSM cartographie aussi les puits (s'ils sont visibles depuis l'espace public, mais normalement ils sont aussi déclarés aux agences de bassins, et doivent être contrôlés sanitairement en cas de consommation, et séparés des réseaux d'eau publics; il devrait exister des base de données publiques des puits dans les agences de bassins et dans les communes qui prélèvent des taxes locales sur l'utilisation de l'eau des sous-sols). Le 27 février 2015 09:54, MASSIOT Dominique dominique.mass...@sdis29.fr a écrit : Le fait qu'un fois versées dans OSM, les données points d'eau incendie puissent être complétées et améliorées par n'importe quel contributeur ne me pose pas problème...bien au contraire !! C'est le regard croisé des uns et des autres qui permettra de fiabiliser la base, dans une logique gagnant-gagnant ! Il s'avère qu'une partie des données attributaires (débit/pression) serait de fait difficilement vérifiable par tout un chacun. Mais l'exemple fourni par Donat démontre bien que c'est déjà le cas dans la base OSM. De mon point de vue, le fait de ne pas partager les informations de débit/pression empêcherait des exploitations éventuelles de la données. Le simple positionnement des points d'eau incendie me paraît assez limité en potentiel de ré-exploitation ultérieure. Alors que la mise à disposition des données de débit/pression ouvrirait des potentialités d'exploitation : - pour la sphère publique : fourniture pour les services communaux (plutôt petite commune) d'une information sur l'état des moyens de défense incendie sur son territoire, etc... - pour la sphère privée : possibilité pour un porteur de projet d'étudier les moyens de défense contre l'incendie disponibles à proximité d'uneimplantation envisagée, etc... Pour ce dernier exemple, il ne s'agit pas d'extrapolation. En effet, nous mettons à disposition la couche SIG des points d'eau incendie sur l'IDG GeoBretagne (avec MAJ mensuelle). J'ai été contacté dernièrement par une société pour un problème technique dans l'exploitation de la donnée en téléchargement. Elle souhaitait l' utiliser pour étudier un projet d'implantation. *Dominique Massiot* *SDIS 29 - Groupement Opération* *tel : 02 98 10 31 78* *De :* Donat ROBAUX [mailto:dona...@gmail.com] *Envoyé :* mercredi 25 février 2015 19:58 *À :* talk-fr@openstreetmap.org *Objet :* Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne -- Message transféré -- From: Pieren pier...@gmail.com To: Discussions sur OSM en français talk-fr@openstreetmap.org Cc: Date: Wed, 25 Feb 2015 17:54:05 +0100 Subject: Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne 2015-02-25 15:58 GMT+01:00 MASSIOT Dominique dominique.mass...@sdis29.fr : A l'instar de Yann (que je remercie pour ce gros travail de fond sur le sujet), je suis administrateur des données cartographiques d'un SDIS (Finistère). J'ai le sentiment qu'une exclusion des champs métiers constituerait un frein dans la démarche d'ouverture de ces données métiers par les SDIS... Une fois versées dans OSM, ces données peuvent être modifiées par n'importe qui. Alors comment, moi, simple contributeur, je pourrais vérifier une valeur de pression modifiée par un tiers ? Ou alors, vous considérez vous comme les seuls autorisés à modifier ces valeurs ? Si c'était le cas, il faudrait alors revoir votre modèle de contribution à OSM. Les informations et améliorations (en particulier de positionnement) peuvent parfaitement fonctionner dans les deux sens mais vous devrez de toute façon garder votre jeu de données originales de votre côté (comme référenctiel) et ne partager que ce qui peux être modifiable/améliorable par le public. Ensuite, vous devrez mettre en place un processus de consultation qui soit combine le meilleur des deux sources, soit prend en compte en local ce qui change dans OSM mais uniquement après vérification. A vous de voir. Pieren D'accord avec Pieren, mais en quoi est-ce différent pour les lignes haute-tension de RET ou ERDF, les caténaires ou les LAC pour lesquelles des données de lignes ne sont pas vérifiables par le français moyen? Mais c'est vrai que il faut trouver un moyen de
Re: [OSM-talk-fr] Coexistence du tag ref:FR:commune et ref:FR:FANTOIR [était CR rencontre DMI de Grenoble]
Bon, comme Pieren a l'air de batailler seul contre le vent, je pollue un peu la discussion juste pour dire qu'il n'est pas seul, et que j'ai aussi du mal avec ces ajouts de ref à outrance. On n'a pas écrit un jour que si une machine peut faire le travail, c'est à elle de le faire ? C'est sur, c'est plus facile pour tout le monde d'ajouter son identifiant unique dans la base, sans limite, puisqu'on peut en ajouter autant qu'on veut à chaque élément. Alors que chacun pourrait juste partir du ref naturel, ici probablement le Fantoir (puisque je vois mal quelqu'un aller croiser les ref de voirie avec les fichiers de chaque commune). À quand un ref:google/viamichelin/mappy dans OSM ? D'après certains, ce serait la preuve d'une belle réutilisation des données ? JB. Le 27.02.2015 15:27, Pieren a écrit : 2015-02-27 14:40 GMT+01:00 Vincent de Château-Thierry osm.v...@free.fr: Tony a expliqué le souci il me semble : le FANTOIR est long à émerger, localement, et le besoin d'un ID unique pour chaque voie arrive bien avant la publication d'un code FANTOIR. Donc non, l'utilisateur n'a pas _immédiatement_ le code fantoir en local. Ça simplifierait voire annulerait cette discussion, sinon. La discussion ne concerne que les voies qui ont déjà un code FANTOIR. Pour une commune, j'imagine que c'est l'immense majorité des cas. Pour les voies nouvelles qui n'ont pas encore de ref FANTOIR, j'ai déjà répondu par ailleurs que le tag ref:FR:commune était compréhensible, faute de mieux. si des consommateurs de données veulent s'appuyer sur FANTOIR, et que d'autres préfèrent un ref:FR:commune, pourquoi trancher ? Ce cumul de 2 ref, peut-être demain de 5 ou 10, serait plutôt pour moi un excellent signe : celui que des acteurs qui n'ont rien à voir entre eux, ont tous besoin de consommer nos données, et vont donc avoir un intérêt (une motivation) pour surveiller et maintenir ces données. Ben non, c'est là où on ne va pas être d'accord (tant pis, c'est pas mortel) et où tu va avoir beaucoup de mal à convaincre le reste des contributeurs. Multiplier les tags ref montre certes une belle dynamique de réutilisation mais elle rend surtout l'interprétation des données plus difficile par les humains... et inutile. Ce sont d'abord les humains qui maintiennent et maintiendront la voirie OSM dans le futur, pas des programmes de synchronisation avec des référentiels externes que personne n'a encore vu à l'oeuvre après 10 ans. Nous avons tout à gagner à utiliser un uuid (identifiant unique). Comme cela n'existe pas par défaut dans OSM, on peut parfaitement adopter le code FANTOIR et s'en contenter (et le ref:FR:commune là où il n'y en a pas). Sans vouloir être jacobin, il a l'avantage d'être déjà public, présent et cohérent sur l'ensemble du territoire, our toutes les communes, ce qui n'est pas le cas d'un ref:FR:commune. Concernant la prolifération de tags abscons, lorsqu'il y a des discussions sur les listes de diffusion internationales et qu'il faut choisir entre le confort des contributeur et celui des consommateurs (souvent pour éviter de faire un petit effort de programmation d'ailleurs), c'est toujours celui des contributeurs qui est au final privilégié car c'est le contributeur lambda, celui qui est près du terrain, qui fait la force du projet. La liste imports est remplie d'exemples de refs externes remis en question ou même finalement rejetés pour un import de nouveaux objets dans OSM. Alors en mettre 5 ou 10... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [talk-ph] OSM Notes opened for the Yolanda / Haiyan Typhoon and not yet resolved
As I mentioned in another thread, I am already changing landuse=brownfield to landuse=residential as I see them on the ground in Yolanda affected areas manually. I will work on the notes (resolving or fixing the map if needed) once my trip edits are finished. On 2/27/15, Pierre Béland pierz...@yahoo.fr wrote: Hi Dale, Unfortunately, I dont expect to be able to get to the summit. But as usual, we surely can discuss this remotely. Pierre De : Dale Kunce dale.ku...@gmail.com À : Pierre Béland pierz...@yahoo.fr; Daniel Joseph dan.b.jos...@gmail.com Cc : talk-ph@openstreetmap.org talk-ph@openstreetmap.org Envoyé le : Jeudi 26 février 2015 20h35 Objet : Re: [talk-ph] OSM Notes opened for the Yolanda / Haiyan Typhoon and not yet resolved I'd like the damage tagging scheme to be a topic of discussion at the HOT summit. @pierre do you think you could lead/propose a session. On Thu, Feb 26, 2015 at 8:14 PM Pierre Béland pierz...@yahoo.fr wrote: Talking of archiving the Yolanda info, while working for the Hagupit typhoon, I made propositions on the HOT Discussion list but only few comments.See http://gis.19327.n5.nabble.com/Damage-evaluation-tagging-schema-td5831094.html Plus still working on the Ebola activation and missed time assuring that this moves on. Pierre De : Daniel Joseph dan.b.jos...@gmail.com À : Pierre Béland pierz...@yahoo.fr Cc : talk-ph@openstreetmap.org talk-ph@openstreetmap.org Envoyé le : Jeudi 26 février 2015 19h54 Objet : Re: [talk-ph] OSM Notes opened for the Yolanda / Haiyan Typhoon and not yet resolved I actually reached out to ChrisEspectato (via an OSM account message) on 21 February to ask about the purpose of the notes. If I haven't heard back after some time I was planning on going through and closing the notes. With the anonymous notes, reaching out isn't possible. I think it's good to close some of the notes in the manner you mention. There are certainly some notes leftover from Yolanda that could be resolved (because they are no longer relevant or do not contain enough detail). On a side note, there are also many tags related to the Yolanda response that could be 'archived' or removed. Unfortunately this sort of cleanup work tends to be a lot less interesting than adding new details and features to the map. All the best,Dan On Fri, Feb 27, 2015 at 7:17 AM, Pierre Béland pierz...@yahoo.fr wrote: There is a discussion today on the general talk list about anonymous OSM notes. The Yolanda / Haiyan Activation is an example where such info could have helped if more infos provided and the possibility to interact with the person adding such note. To revise the OSM Notes and enhance the map, we can select this layer from openstreetmap.org Today, after more then a year, this info seems useless and I revises and resolves/closed some of these notes adding this comment: Incomplete infos from this note or comments not related to mapping objects . More then a year later, no more infos added. I am closing this note. I also see notes Created by ChrisEspectato with comments that seem to refer to an event or trip simply. #28 1-27-14 834am See http://www.openstreetmap.org/note/157873 regard Pierre ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk] Mechanically Cleaning Up FIXME Tags
On Wed, Feb 25, 2015 at 12:51 AM, Tobias Knerr o...@tobias-knerr.de wrote: On 25.02.2015 02:58, Bryce Nesbitt wrote: It is apparent that a number of imports have left tens of thousands of fixme notes that have a low chance of ever getting addressed. Pick your favorite from the lists above: set␣better␣denotation is my mine. That's from a mechanical edit that should never have happened in the first place. The edit was basically done in order to establish the denotation tag for trees, which was almost nonexistent before. The denotation values were not pulled from an external source, but based on guesses of the kind another tree within x meters = must be a cluster of trees. In my opinion, it could make sense to also remove the denotation keys on trees with set␣better␣denotation. After all, the continuing existence of that fixme shows that no human ever verified these. I also agree with the general goal to get rid of pointless fixme values. I've sent a message to the user, to open a discussion about mechanically reversing: fixme=set␣better␣denotation denotation=cluster Because these tags are scattered all over Europe, they are likely to eat mapper time during routine editing and fixme cleanup. The same tag appears on a limited number of seamarks http://www.openstreetmap.org/node/2456524071 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Imports] Mechanically Cleaning Up FIXME Tags
On Fri, Feb 27, 2015 at 9:04 AM, moltonel 3x Combo molto...@gmail.com wrote: On 27/02/2015, Christoph Hormann chris_horm...@gmx.de wrote: fixme=stream␣attributes␣missing fixme=stream␣attribute␣data␣missing have not been added by an import but in an attempt to fix a broken import. There seems to have been a similar effort for canals. See http://www.openstreetmap.org/way/45992170/history The original import was apparently dumped in without regard to OSM's structure. The fixup changeset added waterway=canal and the somewhat redundant: attribution=NHD canal=fixme fixme=canal/ditch attributes missing source=NHD However the desired attribute is not in NHD as far as I can tell. That NHD feature code is feature only no attributes so anyone trying to track that feature code down and add attributes will hit a wall. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] illustration pour les nouveaux cantons
Je comptais faire une passe de finition ce week-end sur les cantons pour vérifier que tout est d'équerre avant de trop communiquer dessus. A minima, voici la couverture des nouveaux cantons il y a une semaine, puis dimanche et aujourd'hui on est quasiment bleu partout https://twitter.com/cq94/status/569250859491692545/photo/1 https://twitter.com/cq94/status/569460664886042625/photo/1 https://twitter.com/cq94/status/569590250059763713/photo/1 Le 27 février 2015 18:19, althio althio.fo...@gmail.com a écrit : Salut, Est-ce que quelqu'un pourrait m'indiquer ou me fournir une carte illustrant la modification en cours des cantons ? Peut-être une sorte d'avant/après, sur une zone ? Je voudrais la proposer pour la prochaine édition de weeklyOSM, au moins en version française. althio ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-be] Viewing recent notes on OSM.org
Op 27 feb. 2015, om 17:52 heeft Jakka vdmfrank...@gmail.com het volgende geschreven: How can I receive or view, open de recent notes from this map ? Immediately or after day XX Now I must control them one by one over en over again. Some notes are there longer then 6 months On this site: http://resultmaps.neis-one.org/osm-notes-country?c=Belgium You at least have some options to see the notes on the map related to a given country. What I did for The Netherlands is, putting the RSS feeds (top left of the screen) into my RSS reader, which gives me an easy option to see/control all notes, sorted by date and their current status (open, comment, closed). Marc. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-fr] illustration pour les nouveaux cantons
Entre les terminer et les vérifier il y a encore de la marge. Certains erreurs ne sont pas visibles sur une simple carte montrant des polygones. Il faut vraiment tout passer en revue car des erreurs il y en a pas mal même si les polyygones sont fermés, ne laissent pas de trous et ne se superposent pas. Le 27 février 2015 19:21, Christian Quest cqu...@openstreetmap.fr a écrit : Je comptais faire une passe de finition ce week-end sur les cantons pour vérifier que tout est d'équerre avant de trop communiquer dessus. A minima, voici la couverture des nouveaux cantons il y a une semaine, puis dimanche et aujourd'hui on est quasiment bleu partout https://twitter.com/cq94/status/569250859491692545/photo/1 https://twitter.com/cq94/status/569460664886042625/photo/1 https://twitter.com/cq94/status/569590250059763713/photo/1 Le 27 février 2015 18:19, althio althio.fo...@gmail.com a écrit : Salut, Est-ce que quelqu'un pourrait m'indiquer ou me fournir une carte illustrant la modification en cours des cantons ? Peut-être une sorte d'avant/après, sur une zone ? Je voudrais la proposer pour la prochaine édition de weeklyOSM, au moins en version française. althio ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ 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-be] Viewing recent notes on OSM.org
Dat is steevast een goed antwoord op de vraag. Ne bank vooruit. Thx Marc Zoutendijk schreef op 27/02/2015 om 19:54: Op 27 feb. 2015, om 17:52 heeft Jakka vdmfrank...@gmail.com mailto:vdmfrank...@gmail.com het volgende geschreven: How can I receive or view, open de recent notes from this map ? Immediately or after day XX Now I must control them one by one over en over again. Some notes are there longer then 6 months On this site: http://resultmaps.neis-one.org/osm-notes-country?c=Belgium You at least have some options to see the notes on the map related to a given country. What I did for The Netherlands is, putting the RSS feeds (top left of the screen) into my RSS reader, which gives me an easy option to see/control all notes, sorted by date and their current status (open, comment, closed). Marc. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] Mechanically Cleaning Up FIXME Tags
On Fri, Feb 27, 2015 at 8:30 AM, JB jb...@mailoo.org wrote: Le 26.02.2015 19:25, Paul Johnson a écrit : Now that we have an anointed notes system, how about an automated move to notes, with the owner of the note being the person who originated the FIXME? Please, no. On http://resultmaps.neis-one.org/osm-notes-overview, I prefer the first graph, showing how the notes db is already getting clustered — too many openers, not enough closers. It seems that the OpenStreetBug experience is already getting reproduced (the negative part, not the beginning of it). So let's explore why people aren't working notes rather than complain about moving some objects that are essentially obsolete now that notes Is A Thing™. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mechanically Cleaning Up FIXME Tags
Bryce Nesbitt bry...@obviously.com writes: On Wed, Feb 25, 2015 at 1:10 AM, SomeoneElse li...@atownsend.org.uk wrote: On 25/02/2015 05:00, Bryce Nesbitt wrote: Any fixme in wide use I'm not interested in deleting. I'd strongly oppose the mechanical deletion of low volume fixme values. Mappers local to me often use individually worded fixmes describing something that needs investigation. By definition these values are not in wide use, but definitely should be kept. If I'm going to be in an area I always load the local notes and fixmes onto the Garmin so that if I'm near something that needs some attibute checking, I know about it. Hold on, you may have misunderstood. The only fixme tags proposed for deletion are the mechanically added ones on thousands of nodes. Any onesey twosey value would of course stay. Any value like continue that's has high counts, but edited by hundreds of unique users, would stay. I am still not sure I am following. There is a difference between: 1) identify foo as a fixme= value that is often associated with mechanical edit 2) therefore, remove all fixme=foo and 3) identify foo as a fixme= value that is often associated with mechanical edit 4) remove all fixme=foo tags *which were actually added by a mechanical edit* Do you mean 1/2 or do you mean 3/4? If 3/4, I think this is fine. If 1/2, I think it's going to remove hand-mapper fixme tags, which seems not ok. pgpF6KpEHBMw_.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] [newbie] Pourquoi OSM n'affiche pas les grandes villes?
Les règles de rendu ne gèrent pas correctement les conflits d'affichage. Ticket ouvert depuis un certain temps déja.voir https://github.com/gravitystorm/openstreetmap-carto/issues/1083 Pierre De : Shohreh codecompl...@free.fr À : talk-fr@openstreetmap.org Envoyé le : Vendredi 27 février 2015 9h32 Objet : [OSM-talk-fr] [newbie] Pourquoi OSM n'affiche pas les grandes villes? Bonjour Question de débutant sur un phénomène que je vois souvent sur OSM que ce soit avec le rendu Mapnik ou OCM : la carte affiche de petits patelins mais pas la grande ville à côté. Exemple : OSM affiche Carrières-sous-Poissy mais pas Poissy juste à côté et plus importante: http://www.openstreetmap.org/#map=13/48.9240/2.0617layers=Q Résultat, quand on prépare un parcours et qu'on ignore où se trouve la ville, on ne trouve pas et passage par Google Maps. Quelqu'un sait pourquoi? Merci. -- View this message in context: http://gis.19327.n5.nabble.com/newbie-Pourquoi-OSM-n-affiche-pas-les-grandes-villes-tp5835189.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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] インポートデータに関する削除について
centreeです。 タスクマネージャ、先走って#1-#3までやってしまいましたが… 幸いなことに、削除（候補）のデータはおろか、building=yesのデータも見つからない地域でした。 （わざと難しくなさそうな地域を狙ったのもありますが） いったん論議がまとまるまで作業を止めておきます。 ikiyaさんがおっしゃるように、確かに国土地理院の標準タイルとの比較では、 インポートかそうでないのか判断に迷うこともありますね…。 それで、ikiyaさんのおっしゃられるような、より丁寧な手順を踏むなら、 インポートではない貴重な情報を誤って消してしまうような危険は最小限に抑えられると思います。 反面、インポートデータの削除スピードは格段に落ちてしまいますので ODbLライセンスに反するデータを含む情報が（望まずとも）公開され続けてしまい こちらは、場合によっては対外的にも影響が出る可能性もあり、あまり望ましい状態とはいえないと思います。 当事者の編集権重視か、ODbLとの整合性重視か、それぞれ意見の分かれるところだと思いますが ikiyaさんの案（タスクマネージャ―でまず情報収集） + 適度な期限の設定（期限が過ぎた場合の対応も決めておく）を すると、うまくいくような気もします…が、どうでしょう…？ ikiyaさん 基盤地図情報をそのものを背景にして見る もし上記活動が本格化しましたら、よければ方法を教えてください… （すみません、初心者なのでタイルを背景にすることしかしらないもので…） いいださん user:mitsurukikkawa user:徳島県オープンデータ に加え user:kikkawamitsuru もインポートに使われているような気もしますが…勘違いだったらごめんなさい。 centree(むらかみ） - Original Message - From: ikiya insidekiwi...@yahoo.co.jp To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2015/2/27, Fri 23:09 Subject: Re: [OSM-ja] インポートデータに関する削除について ikiyaです。 徳島県のインポートデータについてですが、 タスクマネージャーを使うのは賛成ですが、 削除にはもうワンステップ置いてもようかと思います。 まず、タクスマネージャーを使って、明らかに基盤地図情報以外のソースで書かれていることが確認できたエリヤ（OKですよエリヤ）を増やしていく作業を進めればよいと思います。 その結果、インポートデータが残っていそうなエリアが絞りだされるので、当事者とさらに話し合いや削除を依頼するなりの手立てができるかと思います。 さらにJOSM上で地理院地図の標 準タイルと重ねて比較しても、 地理院タイルの解像度の低さや、地理院タイルのレンダリングと基盤地図情報の建築物外周線との違いから JOSM上での判断には難しい面もあります。 JOSMで比較してみるなら、基盤地図情報をそのものを背景にして見る（チェックする）ことがベストと思います。 JOSMでのチェックですが見てみると この周辺はまだ建物に２重ノードが大量に残っています。 http://www.openstreetmap.org/#map=18/34.17339/134.62052 このような場所を手分けして確認しあう作業がよろしいのではないでしょうか。 - Original Message - From: Satoshi IIDA nyamp...@gmail.com To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2015/2/27, Fri 21:28 Subject: Re: [OSM-ja] インポートデータに関する削除について いいだです。 和歌山県のデータについて、削除作業が完了しました。 ユーザ1029さんによるインポート建物オブジェクトが残っていないことを、OverPass turboで確認を行っています。 次は徳島県のデータの削除なのですが、 こちら、現在の状況を確認したところ、 ひとりで対応するのはかなり難しい状況でした。。。 「私がやる」といっておいて申し訳ないのですが、 以下にタスクとして登録しましたので、みなさま、ご協力をいただけないでしょうか。 http://nyampire.info/project/6 また、徳島県オープンデータ と mitsurukikkawaのアカウントでは、 すみません、引き続き、建物データの編集を実施しないようお願いします。 ``` 上記タスクの手順でも、ユーザによるフィルタをもとに対象となるデータの絞り込みを行います。 そのため、データが削除されているならよいのですが、編集、をされてしまうと、 その建物データが削除対象のデータかどうか、すべて目視でチェックしないといけなくなります。 なるべく早い作業完了のため、何卒ご協力ください。 ``` Tasking Managerの使い方に不安のある方は、 まず最初に海上のなにもオブジェクトがないエリアを選択し、何度かお試し作業をしてみてください。 ■検討事項 インポートによって追加された建物データに対して、 amenity=place_of_worship などのデータが付与されているものが散見されます。 こうしたデータは、新しくノードかエリアのオブジェクトを作成し、 そこにタグを移植して、インポートデータのオブジェクトを削除するのがよいのかな、と思っています。 ただし、正直言って、かなり手間になります。。。 いったんすべて削除をしてしまうのもひとつの手ではありますが、 過去に行われたKSJ2データ(公共施設)とのマージも行われているようで、 すべて削除した場合にはデータのロスがかなり大きいとも思っています。 ご意見いただけると嬉しいです。 -- 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 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-talk-fr] [newbie] Pourquoi OSM n'affiche pas les grandes villes?
Quelle serait la classification de Montréal (pas Montréal en Gers, bien jolie par ailleurs) ? https://github.com/gravitystorm/openstreetmap-carto/issues/1337 Pierre De : Joseph Rabie joseph.ra...@ateliergrandparis.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Vendredi 27 février 2015 9h55 Objet : Re: [OSM-talk-fr] [newbie] Pourquoi OSM n'affiche pas les grandes villes? Bonjour, A priori - car c'est le cas avec le rendu Mapnik utilisé par Mapbox - c'est parce qu'il y a une algorithme qui fait en sorte que les titres ne se chevauchent pas. Probablement, dans le cas cité, Poissy ne s'affiche pas car sinon le titre se chevauchera avec les panneaux routiers. Et puis, sauf pour les très grandes villes (scalerank 1 à 9), si j'ai bien compris, il n y a pas de hiérarchisation des villes selon la taille ou la population. Bonne fin de journée ! Joseph Rabie. Joseph Rabie ATELIER INTERNATIONAL DU GRAND PARIS Palais de Tokyo 13 avenue du Président Wilson 75116 - PARIS tél : + 33 (0)1.76.21.04.86 http://www.ateliergrandparis.fr _ Le 27/02/2015 15:32, Shohreh a écrit : Bonjour Question de débutant sur un phénomène que je vois souvent sur OSM que ce soit avec le rendu Mapnik ou OCM : la carte affiche de petits patelins mais pas la grande ville à côté. Exemple : OSM affiche Carrières-sous-Poissy mais pas Poissy juste à côté et plus importante: http://www.openstreetmap.org/#map=13/48.9240/2.0617layers=Q Résultat, quand on prépare un parcours et qu'on ignore où se trouve la ville, on ne trouve pas et passage par Google Maps. Quelqu'un sait pourquoi? Merci. -- View this message in context: http://gis.19327.n5.nabble.com/newbie-Pourquoi-OSM-n-affiche-pas-les-grandes-villes-tp5835189.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 ___ 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] [newbie] Pourquoi OSM n'affiche pas les grandes villes?
Il y avait... mais il n'y a(vait) plus, j'ai rectifié... https://www.openstreetmap.org/node/281385625/history Le 27/02/2015 16:52, Jérôme Seigneuret a écrit : En effet pas de place name=Poissy Voir sur Overpass avec une requête de type LIKE http://overpass-turbo.eu/s/7Un Pas de ref:INSEE=78498 non plus http://overpass-turbo.eu/s/7Uo Place est indispensable pour un affichage correct du nom de la ville or il n'y a que la relation pour le découpage communal http://www.openstreetmap.org/relation/911088#map=14/48.9266/2.0386 Le 27 février 2015 16:45, Jérôme Seigneuret jseigneuret-emp...@yahoo.fr mailto:jseigneuret-emp...@yahoo.fr a écrit : En effet pas de place name=Poissy Voir sur Overpass avec une requête de type LIKE http://overpass-turbo.eu/s/7Un Le 27 février 2015 15:55, Joseph Rabie joseph.ra...@ateliergrandparis.fr mailto:joseph.ra...@ateliergrandparis.fr a écrit : Bonjour, A priori - car c'est le cas avec le rendu Mapnik utilisé par Mapbox - c'est parce qu'il y a une algorithme qui fait en sorte que les titres ne se chevauchent pas. Probablement, dans le cas cité, Poissy ne s'affiche pas car sinon le titre se chevauchera avec les panneaux routiers. Et puis, sauf pour les très grandes villes (scalerank 1 à 9), si j'ai bien compris, il n y a pas de hiérarchisation des villes selon la taille ou la population. Bonne fin de journée ! Joseph Rabie. Joseph Rabie ATELIER INTERNATIONAL DU GRAND PARIS Palais de Tokyo 13 avenue du Président Wilson 75116 - PARIS tél : + 33 (0)1.76.21.04.86 tel:%2B%2033%20%280%291.76.21.04.86 http://www.ateliergrandparis.fr _ Le 27/02/2015 15:32, Shohreh a écrit : Bonjour Question de débutant sur un phénomène que je vois souvent sur OSM que ce soit avec le rendu Mapnik ou OCM : la carte affiche de petits patelins mais pas la grande ville à côté. Exemple : OSM affiche Carrières-sous-Poissy mais pas Poissy juste à côté et plus importante: http://www.openstreetmap.org/#map=13/48.9240/2.0617layers=Q Résultat, quand on prépare un parcours et qu'on ignore où se trouve la ville, on ne trouve pas et passage par Google Maps. Quelqu'un sait pourquoi? Merci. -- View this message in context: http://gis.19327.n5.nabble.com/newbie-Pourquoi-OSM-n-affiche-pas-les-grandes-villes-tp5835189.html Sent from the France mailing list archive at Nabble.com. ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [newbie] Pourquoi OSM n'affiche pas les grandes villes?
Bonjour, Cela pourrait être aussi parce qu'il n'y pas pas de noeud place pour Poissy ;-) A+ Bruno Le 27 février 2015 16:21, Pierre Béland pierz...@yahoo.fr a écrit : Les règles de rendu ne gèrent pas correctement les conflits d'affichage. Ticket ouvert depuis un certain temps déja. voir https://github.com/gravitystorm/openstreetmap-carto/issues/1083 Pierre -- *De :* Shohreh codecompl...@free.fr *À :* talk-fr@openstreetmap.org *Envoyé le :* Vendredi 27 février 2015 9h32 *Objet :* [OSM-talk-fr] [newbie] Pourquoi OSM n'affiche pas les grandes villes? Bonjour Question de débutant sur un phénomène que je vois souvent sur OSM que ce soit avec le rendu Mapnik ou OCM : la carte affiche de petits patelins mais pas la grande ville à côté. Exemple : OSM affiche Carrières-sous-Poissy mais pas Poissy juste à côté et plus importante: http://www.openstreetmap.org/#map=13/48.9240/2.0617layers=Q Résultat, quand on prépare un parcours et qu'on ignore où se trouve la ville, on ne trouve pas et passage par Google Maps. Quelqu'un sait pourquoi? Merci. -- View this message in context: http://gis.19327.n5.nabble.com/newbie-Pourquoi-OSM-n-affiche-pas-les-grandes-villes-tp5835189.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 ___ 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] Coexistence du tag ref:FR:commune et ref:FR:FANTOIR [était CR rencontre DMI de Grenoble]
Je n'emploierais pas les termes de refs à outrance quand il s'agirait ici d'une source communale, malgré tout officielle, pour peu qu'elle soit publique et libre, ce qui n'est pas le cas des ref Google, Michelin Mappy...) on voit bien qu'on a un problème avec une source nationale (mais qui a du fiat de son extension nationale du mal à tout coordonner et rester à jour, et les besoins locaux plus immédiats des communes dans ce qui est de leur compétence). Bref je ne m'oppose pas aux ref:FR:commune (en tant que complément utile des codes FANTOIR), à condition de les placer au bon endroit et que la source soit publiquement vérifiable et réutilisable librement, et qu'elle apporte une différence mesurable avec une valeur ajoutée. Les SIG communaux sont en chantier permanent, le FANTOIR aussi pour répondre aux besoinx plus globaux y compris dans les communes non dotées de leur propre SIG (ou qui n'en a pas confié la gestion à une intercommunalité ou une autre collectivité ou un prestataire de service externe); il va bien arriver un moment où ces deux vont arriver à se synchroniser au point que l'un ou l'autre disparaîtra (ne sera plus maintenu), mais pour l'instant ce n'est pas le cas. Le 27 février 2015 15:40, JB jb...@mailoo.org a écrit : Bon, comme Pieren a l'air de batailler seul contre le vent, je pollue un peu la discussion juste pour dire qu'il n'est pas seul, et que j'ai aussi du mal avec ces ajouts de ref à outrance. On n'a pas écrit un jour que si une machine peut faire le travail, c'est à elle de le faire ? C'est sur, c'est plus facile pour tout le monde d'ajouter son identifiant unique dans la base, sans limite, puisqu'on peut en ajouter autant qu'on veut à chaque élément. Alors que chacun pourrait juste partir du ref naturel, ici probablement le Fantoir (puisque je vois mal quelqu'un aller croiser les ref de voirie avec les fichiers de chaque commune). À quand un ref:google/viamichelin/mappy dans OSM ? D'après certains, ce serait la preuve d'une belle réutilisation des données ? JB. Le 27.02.2015 15:27, Pieren a écrit : 2015-02-27 14:40 GMT+01:00 Vincent de Château-Thierry osm.v...@free.fr: Tony a expliqué le souci il me semble : le FANTOIR est long à émerger, localement, et le besoin d'un ID unique pour chaque voie arrive bien avant la publication d'un code FANTOIR. Donc non, l'utilisateur n'a pas _immédiatement_ le code fantoir en local. Ça simplifierait voire annulerait cette discussion, sinon. La discussion ne concerne que les voies qui ont déjà un code FANTOIR. Pour une commune, j'imagine que c'est l'immense majorité des cas. Pour les voies nouvelles qui n'ont pas encore de ref FANTOIR, j'ai déjà répondu par ailleurs que le tag ref:FR:commune était compréhensible, faute de mieux. si des consommateurs de données veulent s'appuyer sur FANTOIR, et que d'autres préfèrent un ref:FR:commune, pourquoi trancher ? Ce cumul de 2 ref, peut-être demain de 5 ou 10, serait plutôt pour moi un excellent signe : celui que des acteurs qui n'ont rien à voir entre eux, ont tous besoin de consommer nos données, et vont donc avoir un intérêt (une motivation) pour surveiller et maintenir ces données. Ben non, c'est là où on ne va pas être d'accord (tant pis, c'est pas mortel) et où tu va avoir beaucoup de mal à convaincre le reste des contributeurs. Multiplier les tags ref montre certes une belle dynamique de réutilisation mais elle rend surtout l'interprétation des données plus difficile par les humains... et inutile. Ce sont d'abord les humains qui maintiennent et maintiendront la voirie OSM dans le futur, pas des programmes de synchronisation avec des référentiels externes que personne n'a encore vu à l'oeuvre après 10 ans. Nous avons tout à gagner à utiliser un uuid (identifiant unique). Comme cela n'existe pas par défaut dans OSM, on peut parfaitement adopter le code FANTOIR et s'en contenter (et le ref:FR:commune là où il n'y en a pas). Sans vouloir être jacobin, il a l'avantage d'être déjà public, présent et cohérent sur l'ensemble du territoire, our toutes les communes, ce qui n'est pas le cas d'un ref:FR:commune. Concernant la prolifération de tags abscons, lorsqu'il y a des discussions sur les listes de diffusion internationales et qu'il faut choisir entre le confort des contributeur et celui des consommateurs (souvent pour éviter de faire un petit effort de programmation d'ailleurs), c'est toujours celui des contributeurs qui est au final privilégié car c'est le contributeur lambda, celui qui est près du terrain, qui fait la force du projet. La liste imports est remplie d'exemples de refs externes remis en question ou même finalement rejetés pour un import de nouveaux objets dans OSM. Alors en mettre 5 ou 10... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing
Re: [OSM-talk-ie] Sheet request 26/17
Thanks Donal. I note on the Mapcraft job, these sheets are marked as green (9/9). Should the Mapcraft status these sheets be reclassified once they have been rectified or just leave it as it is? Mark On Fri, 27 Feb 2015 at 14:33 Donal Diamond donal.diam...@gmail.com wrote: Uploaded: http://mapwarper.net/maps?field=titlequery=IRL-GSGS- 3906-26-17show_warped=0 D On 27 February 2015 at 10:19, Mark Tully markjtu...@gmail.com wrote: Hi, Can I request that 26/17 NW and SW be uploaded, please. Mark ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
Re: [OSM-talk-ie] Sheet request 26/17
As part of brianh's and myself's initial work on out townlands project, I did ~ 50 sheets in SE Carlow and Wexford about 18 months ago. As mapwarper wasn't available for us then, I rectified them using desktop software and they were them installed on an OSM ran server called faffy. faffy died during some maintence and sheets are now no longer available. Probably best to do them all again on mapwarper as sheets can be constantly revisited and improved. I don't have the time or stomach to do them all again to be honest ;-) Townlands in Carlow and Wexford are complete anyway. Donal On 27 February 2015 at 15:17, Mark Tully markjtu...@gmail.com wrote: Thanks Donal. I note on the Mapcraft job, these sheets are marked as green (9/9). Should the Mapcraft status these sheets be reclassified once they have been rectified or just leave it as it is? Mark On Fri, 27 Feb 2015 at 14:33 Donal Diamond donal.diam...@gmail.com wrote: Uploaded: http://mapwarper.net/maps?field=titlequery=IRL-GSGS- 3906-26-17show_warped=0 D On 27 February 2015 at 10:19, Mark Tully markjtu...@gmail.com wrote: Hi, Can I request that 26/17 NW and SW be uploaded, please. Mark ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
Re: [OSM-talk-fr] [newbie] Pourquoi OSM n'affiche pas les grandes villes?
En effet pas de place name=Poissy Voir sur Overpass avec une requête de type LIKE http://overpass-turbo.eu/s/7Un Pas de ref:INSEE=78498 non plus http://overpass-turbo.eu/s/7Uo Place est indispensable pour un affichage correct du nom de la ville or il n'y a que la relation pour le découpage communal http://www.openstreetmap.org/relation/911088#map=14/48.9266/2.0386 Le 27 février 2015 16:45, Jérôme Seigneuret jseigneuret-emp...@yahoo.fr a écrit : En effet pas de place name=Poissy Voir sur Overpass avec une requête de type LIKE http://overpass-turbo.eu/s/7Un Le 27 février 2015 15:55, Joseph Rabie joseph.ra...@ateliergrandparis.fr a écrit : Bonjour, A priori - car c'est le cas avec le rendu Mapnik utilisé par Mapbox - c'est parce qu'il y a une algorithme qui fait en sorte que les titres ne se chevauchent pas. Probablement, dans le cas cité, Poissy ne s'affiche pas car sinon le titre se chevauchera avec les panneaux routiers. Et puis, sauf pour les très grandes villes (scalerank 1 à 9), si j'ai bien compris, il n y a pas de hiérarchisation des villes selon la taille ou la population. Bonne fin de journée ! Joseph Rabie. Joseph Rabie ATELIER INTERNATIONAL DU GRAND PARIS Palais de Tokyo 13 avenue du Président Wilson 75116 - PARIS tél : + 33 (0)1.76.21.04.86http://www.ateliergrandparis.fr _ Le 27/02/2015 15:32, Shohreh a écrit : Bonjour Question de débutant sur un phénomène que je vois souvent sur OSM que ce soit avec le rendu Mapnik ou OCM : la carte affiche de petits patelins mais pas la grande ville à côté. Exemple : OSM affiche Carrières-sous-Poissy mais pas Poissy juste à côté et plus importante: http://www.openstreetmap.org/#map=13/48.9240/2.0617layers=Q Résultat, quand on prépare un parcours et qu'on ignore où se trouve la ville, on ne trouve pas et passage par Google Maps. Quelqu'un sait pourquoi? Merci. -- View this message in context: http://gis.19327.n5.nabble.com/newbie-Pourquoi-OSM-n-affiche-pas-les-grandes-villes-tp5835189.html Sent from the France mailing list archive at Nabble.com. ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-be] Viewing recent notes on OSM.org
Op 27 feb. 2015, om 20:02 heeft Jakka vdmfrank...@gmail.com het volgende geschreven: Dat is steevast een goed antwoord op de vraag. Ne bank vooruit. En met deze link kun je wat verder terugkijken: http://resultmaps.neis-one.org/osm-notes-country-feed?c=Belgiuma=openedd=2014-04-01 Je kunt zelf de datum aanpassen. Marc. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] [Imports] Mechanically Cleaning Up FIXME Tags
On Friday 27 February 2015, Bryce Nesbitt wrote: There seems to have been a similar effort for canals. See http://www.openstreetmap.org/way/45992170/history The original import was apparently dumped in without regard to OSM's structure. The fixup changeset added waterway=canal and the somewhat redundant: attribution=NHD canal=fixme fixme=canal/ditch attributes missing source=NHD It adds a waterway tag which is wrong in at least 2/3 of the cases and adds the fixme indicating so. Removing the fixme now and keeping the wrong waterway tag would be like shooting yourself into the second foot after having already lost the first. I see only two option here - removing the data or fixing it based on other data sources (which is tricky of course). On the other hand this could be a fairly good candidate for something like maproulette. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Coexistence du tag ref:FR:commune et ref:FR:FANTOIR [était CR rencontre DMI de Grenoble]
Le 27/02/2015 13:33, Pieren a écrit : Denis, tu dis que le fantoir ne vient qu'en deuxième rang. Mais du point de vue d'OSM, il n'y a pas de rang ni de priorité dans les consommateurs de nos données. Il peut y avoir des producteurs de code ref mais nous n'avons pas à connaitre leur hiérarchie, ni leur priorité. A la limite, moi, je n'ai rien contre la généralisation des codes ref:FR:commune mais alors on supprime les codes FANTOIR. Mais on sait tous que les communes peuvent croiser leurs codes avec ceux du cadastre mais que l'inverse n'est pas vrai et que c'est ingérable en dehors de la sphère commune/interco. Il faut rester pragmatique et ne laisser que le seul code fantoir, le seul qui soit ensuite réutilisable pour croiser les fichiers de toutes les communes par tout les consomateurs de données OSM. Presque d'accord avec toi. Quand je parle de second rang à propos du FANTOIR, je parle d'un point de vue légal. FANTOIR est pratique, national, toussa comme l'IGN (troll detected ;-). Ce que je voulais souligner c'est l'importance de sourcer l'information au niveau objet (et non pas simplement au niveau changeset). OSM, d'un point de vue qualité de la donnée, DOIT (must) se soucier non seulement des limites de la source mais également des différents niveaux imbriqués, chacun dans leur mission stricte. OK, c'est lourd de demander cela à des gens qui prennent sur leur temps libre pour contribuer (aka je ne suis pas un contributeur lamda). Ok pour un système de subsidiarité des références sur la voirie ; l'important est de coller à la référence la plus solide légalement, de traquer les distorsions. Les progrès de la politique opendata des collectivités locales laissent encore beaucoup de marge par rapport à la DGFiP. Gageons que les initiatives des premières ne trouveront pas chez OSM une porte close hermétiquement, pour des raisons en partie dogmatiques. Je ne crois pas qu'OSM puisse aujourd'hui méconnaître l'écosystème de la production d'information publique. Il y a, visiblement, des efforts de communication à faire de part et d'autre. Nous (communauté OSM) ne pouvons pas co-construire la description du territoire uniquement sur la base de données libérées et d'efforts individuels (ou collectifs en réponse à des urgences décrétées ou imposées). C'est nécessaire mais pas suffisant (trop couteux par unité de compte). D'un autre côté, les producteurs de données publiques ne peuvent pas espérer qu'en simplement publiant leur production sous licence opendata, la base de données géolocalisées qu'est OSM non seulement sera réactive mais en plus fournira une donnée facilement réutilisable pour leur gestion. Toutefois, je crois qu'il y a un compromis durable possible. Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] illustration pour les nouveaux cantons
Je disais ça justement à ton sujet Christian, parce que que ce que tu as fait dans la Haute-Vienne, c'est du grand n'importe quoi (y compris les relations fausses que tu as indiquées dans la page wiki). D'ailleurs ce sont les cantons que tu as faits qui me donnent le plus de travail derrière en vérification et correction. Tu n'as apparemment fait qu'utiliser un outil automatique sans rien regarder, ni même pour voir si tu avais choisi les bonnes communes (parfois même pas dans le même département). Quand on utilise ComComMaker on regarde quand même avant d'importer tel quel, on réordonne pour voir s'il y a des trous, et au minimum on s'assure de la cohérence. Après ça il manque encore les bureaux centralisateurs, les autres données complémentaires. Le 27 février 2015 19:54, Philippe Verdy verd...@wanadoo.fr a écrit : Entre les terminer et les vérifier il y a encore de la marge. Certains erreurs ne sont pas visibles sur une simple carte montrant des polygones. Il faut vraiment tout passer en revue car des erreurs il y en a pas mal même si les polyygones sont fermés, ne laissent pas de trous et ne se superposent pas. Le 27 février 2015 19:21, Christian Quest cqu...@openstreetmap.fr a écrit : Je comptais faire une passe de finition ce week-end sur les cantons pour vérifier que tout est d'équerre avant de trop communiquer dessus. A minima, voici la couverture des nouveaux cantons il y a une semaine, puis dimanche et aujourd'hui on est quasiment bleu partout https://twitter.com/cq94/status/569250859491692545/photo/1 https://twitter.com/cq94/status/569460664886042625/photo/1 https://twitter.com/cq94/status/569590250059763713/photo/1 Le 27 février 2015 18:19, althio althio.fo...@gmail.com a écrit : Salut, Est-ce que quelqu'un pourrait m'indiquer ou me fournir une carte illustrant la modification en cours des cantons ? Peut-être une sorte d'avant/après, sur une zone ? Je voudrais la proposer pour la prochaine édition de weeklyOSM, au moins en version française. althio ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ 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-talk-be] Mogelijkheid om een SIMPELE 'button' of zoiets in josm te verkrijgen , om fouten door te seinen naar AGIV ?
Als je een fout vind, kan je contact opnemen met : AGIV-contactpunt. T 09 276 15 00 | F 09 276 15 05 | contactp...@agiv.be | www.agiv.be Het AGIV contactpunt is bereikbaar op weekdagen van 8u00 tot 17u00. doch, als je 'ettelijke' fouten vind, is het wel 'vermoeiend' om telkens een hele 'rimram' te moeten gaan mailen of telefoneren naar AGIV. Daarom zou het meer 'comfortabeler' zijn, als er een soort 'button' of zoiets, dat, wanneer je daar dan op klikt, je ergens direkt een 'link' kan geven met de coordinaten ofzoiets , waar de fout zit, en dan wat uitleg ... ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-ie] Looking for Maynooth Mappers
Tracey, On a side note, you can also use the following site to see who has edited OSM in Maynooth recently. You are welcome to message any of these people through the OSM site. They may not be on the mailing list so its impossible to know if they would have gotten your email http://resultmaps.neis-one.org/oooc?zoom=13lat=53.38172lon=-6.57544layers=B00TFT From looking at it, there are about 20 people who have Maynooth as their primary editing area however it looks like only 1 has been active in the last few months Dave On Fri, Feb 27, 2015 at 7:05 PM, Dave Corley davecor...@gmail.com wrote: Hi Tracey, I'm heading up to Leixlip this Sat (tomorrow) so I could swing by Maynooth and meet up to go through what you need to know and how to do what you want if there are no other mappers on the ground there. Dave On Fri, Feb 27, 2015 at 6:39 PM, Tracey P. Lauriault tlaur...@gmail.com wrote: Greetings OSM folks, i am working on a project with tidy towns, green campus and student union on a number of things. One of the Items is to produce a couple of layers with the location of maynooth bins, the location of bike racks, and eventually the location of waste hot spots in order to lobby for better locations and more bins, to get bike racks in the right place and more of them, and to inform a waste reduction plan/ pride in town type of strategy. I would love to lear how to do this and to work with a few others to populate some maps. i live in Maynooth and can find my way to any pub or cafe at anytime to meet up and talk more bout this. If anyone is interested let me know. i am around this weekend. Cheers tracey -- Tracey P. Lauriault http://www.maynoothuniversity.ie/progcity/contributors/tracey-p-lauriault/ https://gcrc.carleton.ca/confluence/display/GCRCWEB/Lauriault http://datalibre.ca/ @TraceyLauriault *Skype:* Tracey.P.Lauriault ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
Re: [OSM-talk-fr] illustration pour les nouveaux cantons
Concernant les tableaux du wiki, au moins tout ce que j'y ai mis est correct et vérifié et revérifié de façon itérative. Le shapefile du Minint je l'ai aussi, il se charge directement dans JOSM dans un calque de fond (pas besoin de QGIS dont je ne dispose pas). Mais je ne comptais utiliser ce shapefile que pour terminer les cantons compliqués du fait de certaines ambiguités ou erreurs relevées dans les décrets (et dont les copies sur LégiFrance ne mentionnent pas les corrections *réellement* appliquées, puisque concernant le premier décret rectificatif il a été mal intégré par LégiFrance dans sa version consolidée, mais il ne donne pas réellement accès au texte du décret rectificatif où il se contente de dire a modifié l'article numéro X de décret Y, comme si la version consolidée contenait le texte réel contenu dans le rectificatif; d'ailleurs même les versions PDF peuvent différer de la version texte/HTML sur LégiFrance, qui s'est carrément trompé en fabriquant ses propres PDF au lieu d'inclure une copie du JORF). Le 27 février 2015 22:20, Christian Quest cqu...@openstreetmap.fr a écrit : Le 27 février 2015 21:15, Philippe Verdy verd...@wanadoo.fr a écrit : Je disais ça justement à ton sujet Christian, parce que que ce que tu as fait dans la Haute-Vienne, c'est du grand n'importe quoi (y compris les relations fausses que tu as indiquées dans la page wiki). D'ailleurs ce sont les cantons que tu as faits qui me donnent le plus de travail derrière en vérification et correction. Tu n'as apparemment fait qu'utiliser un outil automatique sans rien regarder, ni même pour voir si tu avais choisi les bonnes communes (parfois même pas dans le même département). Quand on utilise ComComMaker on regarde quand même avant d'importer tel quel, on réordonne pour voir s'il y a des trous, et au minimum on s'assure de la cohérence. Après ça il manque encore les bureaux centralisateurs, les autres données complémentaires. Je suis en train justement de boucher les trous. J'ai sorti un shapefile pour les trouver facilement à l'aide de QGis: http://osm13.openstreetmap.fr/~cquest/cantons-2015-shapefile.zip Je comptais aussi comparer le shapefile officiel du ministère pour trouver les différences les plus importantes, puis refaire un match automatisé entre les tableaux du wiki et les relations OSM pour vérifier que tout collait. 90% de ce qui a été semi-automatisé est ok et beaucoup de temps a été gagné par rapport à l'usage classique de comcommaker vu qu'on n'avait pas de liste de codes INSEE qui aurait permis de faire directement mieux. Pour les infos complémentaires (bureau centralisateur)... OSM est itératif, ne l'oublions pas... mais là aussi j'ai sorti une liste en CSV depuis le JORF pour aider à contrôler le résultat final: https://gist.github.com/cquest/ac9bab78ba793a1641a6 -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] illustration pour les nouveaux cantons
Le 27 février 2015 22:20, Christian Quest cqu...@openstreetmap.fr a écrit : 90% de ce qui a été semi-automatisé est ok et beaucoup de temps a été gagné par rapport à l'usage classique de comcommaker vu qu'on n'avait pas de liste de codes INSEE qui aurait permis de faire directement mieux. Les décrets contenaient les noms de communes exacts (à quelques différences comme les accents omis sur les capitales). Il fallait les faire coller avec le numéro de département pour éviter de prendre des homonymes. Malgré cela je ne sais pas comment tu t'es débrouillé pour aller chercher d'autres communes ailleurs, qui n'ont même pas le même nom et même pas toujours dans le même département. De même que les ids faus dans la page wiki. Je pense que tu as voulu aller trop vite et oublié totalement toute vérification minimale. D'ailleurs la plupart des trous qui restent viennent de tes ajouts récents. Tu as du faire ça un soir quand tu étais un peu trop fatigué. Bref il faut tout revoir dans ce que tu as fait et ça prend presque autant de temps que si tu n'avais rien mis du tout (il y a des choses correctes en partie ce qui évite des recherches fastidieuses. Mais il faut faire le tri dans tout ça. J'ai fait des tas de vérifs de toutes sortes sur tous les départements 01 à 35, 43, 44, 50, 52, 54 à 57, 59, 60, 62, 63, 67, 69 à 71, 74 à 77, 80, 81, 88 à 95, et les trois départements d'outre-mer (encore incomplets mais pour lesquels le shapefile du Minint peut servir à combler les ways manquants... comme à Bastia aussi). Je suis assez confiant (même si sur certains j'ai du recorriger des cantons terminés mais cassés par des modifs ultérieures). La Bretagne a été la première région complète depuis des mois (entièrement par moi sauf le découpage de certaines villes). Il me reste à passer en revue : 2B (seulement pour le découpage de Bastia sur quelques ways), 34 (il manque encore quelques entrées), 36 à 42, 45 à 49, 51, 53, 58, 61, 64 à 66, 68, 72, 73, 78, 79, 82 à 87, et en outremer 971 et 974 (uniquement le découpage infracommunal). Au vu du boulot énorme que ça représente et des prochaines réorganisations administratives qui vont venir (il va certainement y avoir d'autres redécoupages d'arrondissements ailleurs qu'en Alsace-Moselle), et de la montée en force des pôles métropolitains et autres réformes adminsitratives attendues, il faut remettre en cause la solution du tout géométrique qui est une énorme perte de temps et demande trop de recherches. OSM reste une base de données et ne gère pas QUE la seule géométrie (évolutive... et malheureusement très fragile), il est temps de s'en souvenir. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-us] OSM on Science Friday
Now linked into our wiki here: https://wiki.openstreetmap.org/wiki/OpenStreetMap_in_the_media Thanks, Steve, Eric and Richard (Weait). Good program! SteveA California It was fun to do. Went to a studio and had some last minute problems with an ISDN line going down or something just before broadcast. Steve On Feb 24, 2015, at 8:47 AM, Eric Christensen e...@christensenplace.us wrote: I meant to pass this along last week but... There was a discussion about maps on mobile devices on last week's Science Friday (on NPR). While they started discussing Google Maps the aim quickly turned to OSM. http://sciencefriday.com/segment/02/20/2015/forecasting-the-future-of-maps.html ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk-fr] illustration pour les nouveaux cantons
Le 27 février 2015 21:15, Philippe Verdy verd...@wanadoo.fr a écrit : Je disais ça justement à ton sujet Christian, parce que que ce que tu as fait dans la Haute-Vienne, c'est du grand n'importe quoi (y compris les relations fausses que tu as indiquées dans la page wiki). D'ailleurs ce sont les cantons que tu as faits qui me donnent le plus de travail derrière en vérification et correction. Tu n'as apparemment fait qu'utiliser un outil automatique sans rien regarder, ni même pour voir si tu avais choisi les bonnes communes (parfois même pas dans le même département). Quand on utilise ComComMaker on regarde quand même avant d'importer tel quel, on réordonne pour voir s'il y a des trous, et au minimum on s'assure de la cohérence. Après ça il manque encore les bureaux centralisateurs, les autres données complémentaires. Je suis en train justement de boucher les trous. J'ai sorti un shapefile pour les trouver facilement à l'aide de QGis: http://osm13.openstreetmap.fr/~cquest/cantons-2015-shapefile.zip Je comptais aussi comparer le shapefile officiel du ministère pour trouver les différences les plus importantes, puis refaire un match automatisé entre les tableaux du wiki et les relations OSM pour vérifier que tout collait. 90% de ce qui a été semi-automatisé est ok et beaucoup de temps a été gagné par rapport à l'usage classique de comcommaker vu qu'on n'avait pas de liste de codes INSEE qui aurait permis de faire directement mieux. Pour les infos complémentaires (bureau centralisateur)... OSM est itératif, ne l'oublions pas... mais là aussi j'ai sorti une liste en CSV depuis le JORF pour aider à contrôler le résultat final: https://gist.github.com/cquest/ac9bab78ba793a1641a6 -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Serveur proxy de tuiles du cadastre avec mode joker
Le jeudi 26 février 2015 19:53:56 Vincent Privat a écrit : Si ça couvre la France entière - la France. On a déjà des emprises qui couvrent un pays entier, pas de souci. Soit. Je n'ai pas trouvé de polygone tout fait, mais ça me parait facile d'en tracer un vite-fait. En fait, je vais expliciter un peu ma question :-) : 1. L'emprise contient-elle les ROM ? 2. Est-ce que la précision de la limite de l'emprise à une importance ? 2.1 Cela évite-t-il d'envoyer des requêtes sur des zones non couvertes ? Est- ce une charge supplémentaire tolérable pour ce gentil WMS et son gentil proxy TMS de renvoyer un peu de blanc sur les bords ? 2.3 Doit-on (peut-on) exclure les communes non vectorisées ? Je force volontairement le côté naïf (sans toutefois me forcer exagérément). Merci -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne
Le fait qu'un fois versées dans OSM, les données points d'eau incendie puissent être complétées et améliorées par n'importe quel contributeur ne me pose pas problème...bien au contraire !! C'est le regard croisé des uns et des autres qui permettra de fiabiliser la base, dans une logique gagnant-gagnant ! Il s'avère qu'une partie des données attributaires (débit/pression) serait de fait difficilement vérifiable par tout un chacun. Mais l'exemple fourni par Donat démontre bien que c'est déjà le cas dans la base OSM. De mon point de vue, le fait de ne pas partager les informations de débit/pression empêcherait des exploitations éventuelles de la données. Le simple positionnement des points d'eau incendie me paraît assez limité en potentiel de ré-exploitation ultérieure. Alors que la mise à disposition des données de débit/pression ouvrirait des potentialités d'exploitation : - pour la sphère publique : fourniture pour les services communaux (plutôt petite commune) d'une information sur l'état des moyens de défense incendie sur son territoire, etc... - pour la sphère privée : possibilité pour un porteur de projet d'étudier les moyens de défense contre l'incendie disponibles à proximité d'uneimplantation envisagée, etc... Pour ce dernier exemple, il ne s'agit pas d'extrapolation. En effet, nous mettons à disposition la couche SIG des points d'eau incendie sur l'IDG GeoBretagne (avec MAJ mensuelle). J'ai été contacté dernièrement par une société pour un problème technique dans l'exploitation de la donnée en téléchargement. Elle souhaitait l' utiliser pour étudier un projet d'implantation. Dominique Massiot SDIS 29 - Groupement Opération tel : 02 98 10 31 78 De : Donat ROBAUX [mailto:dona...@gmail.com] Envoyé : mercredi 25 février 2015 19:58 À : talk-fr@openstreetmap.org Objet : Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne -- Message transféré -- From: Pieren pier...@gmail.commailto:pier...@gmail.com To: Discussions sur OSM en français talk-fr@openstreetmap.orgmailto:talk-fr@openstreetmap.org Cc: Date: Wed, 25 Feb 2015 17:54:05 +0100 Subject: Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne 2015-02-25 15:58 GMT+01:00 MASSIOT Dominique dominique.mass...@sdis29.frmailto:dominique.mass...@sdis29.fr: A l'instar de Yann (que je remercie pour ce gros travail de fond sur le sujet), je suis administrateur des données cartographiques d'un SDIS (Finistère). J'ai le sentiment qu'une exclusion des champs métiers constituerait un frein dans la démarche d'ouverture de ces données métiers par les SDIS... Une fois versées dans OSM, ces données peuvent être modifiées par n'importe qui. Alors comment, moi, simple contributeur, je pourrais vérifier une valeur de pression modifiée par un tiers ? Ou alors, vous considérez vous comme les seuls autorisés à modifier ces valeurs ? Si c'était le cas, il faudrait alors revoir votre modèle de contribution à OSM. Les informations et améliorations (en particulier de positionnement) peuvent parfaitement fonctionner dans les deux sens mais vous devrez de toute façon garder votre jeu de données originales de votre côté (comme référenctiel) et ne partager que ce qui peux être modifiable/améliorable par le public. Ensuite, vous devrez mettre en place un processus de consultation qui soit combine le meilleur des deux sources, soit prend en compte en local ce qui change dans OSM mais uniquement après vérification. A vous de voir. Pieren D'accord avec Pieren, mais en quoi est-ce différent pour les lignes haute-tension de RET ou ERDF, les caténaires ou les LAC pour lesquelles des données de lignes ne sont pas vérifiables par le français moyen? Mais c'est vrai que il faut trouver un moyen de vérifier si qqn modifie les valeurs (à tort ou à raison), soit par erreur, soit par exemple autorisation du Sdis de modif des valeurs lors des tournées des PEI par les agents. Donat Ce message a été scanné par l'antivirus du SDIS du Finistère ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-be] JOSM Remote control
On 26-02-15 20:52, Marc Gemis wrote: Somewhere last weekend a new certificate was installed on osm.org http://osm.org. It's some kind of weird certificate (don't know the details, but it was discussed on the josm-dev mailing list), since it is signed by startssl. StartSSL is a free certificate provider, and most probably firefox doesn't have the intermediate certificate chain on board which means it cannot verify. That is probably the reason, although I do not see startSSL as the certificate writer, I see rapidSSL instead. startSSL is not really a great one to use actually for a site like this. Apple products have the same problem with the latest GoDaddy certificates. https://www.sslshopper.com/cheapest-ssl-certificates.html You might want to try this in firefox: https://www.sslshopper.com/ssl-checker.html#hostname=https://www.openstreetmap.org And see if it gives you a chain error or not. It will work in chrome, but it depends on the browser. If you don't get the all-green in firefox, you just need to assemble a chain file with the missing intermediate certificates so the browser can validate. Note, this heavily depends on firefox (/browser) version, I see in my FF that it loads the intermediates fine: Common name: RapidSSL CA Organization: GeoTrust, Inc. Location: US Valid from February 19, 2010 to February 18, 2020 Serial Number: 145105 (0x236d1) Signature Algorithm: sha1WithRSAEncryption Issuer: GeoTrust Global CA Common name: GeoTrust Global CA Organization: GeoTrust Inc. Location: US Valid from May 20, 2002 to August 20, 2018 Serial Number: 1227750 (0x12bbe6) Signature Algorithm: sha1WithRSAEncryption Issuer: Equifax Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-nl] Chipknip tags
De Chipknip is sinds 1 januari niet meer operationeel. Ik denk dat de oplaadpunten nu zo'n beetje overal ook wel weggehaald zijn, in ieder geval zullen ze niet meer operationeel zijn. Volgens Taginfo [1] zijn er nog 292 instances can chipknip in OSM. Ik heb ze even gedownload en de meesten staan op banken (ik heb er in het verleden zelf heel veel toegevoegd) en op winkels. Is het een idee om die in een keer allemaal te verwijderen? Verder is er ook nog een tag voor de betaling met een chipknip, payment:ep_chipknip die veel minder gebruikt is [2], maar die kan ook verwijderd worden. Zijn er redenen om dit niet te doen? [1] https://taginfo.openstreetmap.org/keys/?key=chipknip [2] https://taginfo.openstreetmap.org/keys/?key=payment:ep_chipknip Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-fr] Serveur proxy de tuiles du cadastre avec mode joker
Bonjour, De: Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net En fait, je vais expliciter un peu ma question :-) : 1. L'emprise contient-elle les ROM ? Tu as les mêmes communes que celles accessibles sur http://www.cadastre.gouv.fr/ donc ici celles de Guyane, Guadeloupe, Martinique et Réunion, mais pas Mayotte. 2. Est-ce que la précision de la limite de l'emprise à une importance ? 2.1 Cela évite-t-il d'envoyer des requêtes sur des zones non couvertes ? Est- ce une charge supplémentaire tolérable pour ce gentil WMS et son gentil proxy TMS de renvoyer un peu de blanc sur les bords ? 2.3 Doit-on (peut-on) exclure les communes non vectorisées ? Je pense qu'on peux faire une emprise par excès, géométriquement simplifiée, sans coller aux limites de communes. En essayant à l'instant le WMS sur une commune raster, il y a bien un appel au service, mais pas de réponse ni plantage, donc c'est transparent à tous les sens du terme. Ça évite de plus de se lancer dans une maintenance au fil de l'apparition des communes vectorisées. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] place=quarterタグの現状と今後について
いいだです。 個人としてgithubのフォーラムに 投稿すること 誰もが個人として書き込んでいますし、 すべての経緯を説明するのではなく、現状と予定を伝えるだけでも十分だと思います。 boroughもレンダリングしてほしい、という要望もあるようですし、 書き込んでみてはどうでしょう？ (最初の投稿者の math1985さんはよく日本のことをご存知のかたですし、 うまくフォローしてくれると思いますよ :) ) 2015年2月27日 11:38 Muarkami Oki oki_aic...@yahoo.co.jp: 以前、quarterタグが標準タイルで表示されない件について質問させていただいた centree（むらかみ）です。 （https://www.mail-archive.com/talk-ja%40openstreetmap.org/msg08310.html） あのあと、OSM標準タイルにおいて、place=quarter はそのうちレンダリングされるだろうと 甘い期待を持っていたのですが、現状ではレンダリング要望はrejectされているみたいです。 https://github.com/gravitystorm/openstreetmap-carto/issues/798 なんとなく英語を読んでみると、reject後も熱い論議が提起されているみたいですが quarterタグを今後多く利用して行こうという流れになっている日本ユーザーからも良いタイミングで 要望が必要なのかなと思っていたりします。 ※過去の議論では、OSM標準タイルに、日本独特のレンダリングを望むのは難しく osm.jpに日本独特のレンダリングルールを盛り込むという方法で結論に至ったこともあったようなのですが、 PotlatchやiDがユーザーのこと（編集した後にわざわざosm.jpを見に行くとは考えにくい）また、 br osm.org にいろんな機能が組み込まれるようになったことも考えると、標準タイルでのレンダリングのことも 考えておく必要があるのかなと個人的には思っています。 それで、要望の方法とタイミングなんですが、皆さんどのようにお考えでしょうか？ quarterタグを徐々に増やしていって、日本での重要性と実績を元に要望を出すと通りやすいのかなと思いますが ・OSM標準タイルに表示されないのに、タグを増やすという作業へのモチベーションの問題 ・ISJからのインポート／基盤地図からの目視トレースなど、使える元データはあるが 日本での合意事項に従って活用しようとすると、正しくquarter / neigbourhood に分類、分かち書きできるか subareaを使ってのリレーションをうまく組めるか、など懸案事項も多いように思えます。 https://docs.google.com/spreadsheets/d/1eAE72mjCLoJVGZo5qRhCYK22UxVQ8bpbQSU9ZLHq40o/edit#gid=0 http://qiita.com/nyampire/items/423344fa75707dc138af http://wiki.openstreetmap.org/wiki/JA:MLIT_ISJ_CHOME そうすると、まずはquarterタグを増やす前に、日本での必要性を訴えて osm標準タイルでレンダリングしてもらえるよう要望を出しつつ、 quarterタグに何を入れるべきか、リレーションをどうするか、インポートをどうするかといった議論を並行して行ない 合意を形成した方が良いのかもしれません。 いいだしっぺの私ですが、上記のことで、私がお手伝いできそうなことは 個人としてgithubのフォーラムに 投稿することぐらいですが、 日本のMLでの歴史も踏まえてということになると英語での作文ということもあり自信がありません。 あまり出来ることがなくて恐縮なのですが、何かいいアイデアや、 上記のことに関してすでに行われている動きなどありましたら知識として共有させていただければと思います。 ※個人的には、自分の活動エリアに関して、標準タイルでもレンダリングされる neighbourhood やhamlet でタグ付けしたい誘惑に駆られています…というか 一部、neighbourhood でタグ付けしたものも残してしまっています… いけませんね、そのうち正しいものにしたいと思います…（汗） よろしくお願いします。 centree(むらかみ） ___ 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-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne
De: MASSIOT Dominique dominique.mass...@sdis29.fr De mon point de vue, le fait de ne pas partager les informations de débit/pression empêcherait des exploitations éventuelles de la données. Le simple positionnement des points d'eau incendie me paraît assez limité en potentiel de ré-exploitation ultérieure. Alors que la mise à disposition des données de débit/pression ouvrirait des potentialités d'exploitation : C'est un point positif en effet, car il vise à faciliter la réutilisation, sachant que le nombre d'attributs en question est limité à quelques uns. J'insiste sur ce point pour différencier de, par exemple, la publication des résultats du recensement par sexe et tranche d'âge, commune par commune. On passe là dans un volume d'informations ingérable à notre niveau, donc qui nécessite de ne publier dans OSM qu'une clé (le code INSEE par exemple) et de diffuser ailleurs les données détaillées. Retour aux hydrants : je serais néanmoins partisan, en complément, comme l'a suggéré Pierre, d'une publication régulière en lecture seule sur un portail comme data.gouv.fr afin de permettre des vérifications et croisements, voire l'identification de différentiels qui permettraient des mises à jour dans OSM, par ajout des nouveaux PEI par ex. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-cz] ŘOPíky
p.s. ještě k předchozímu - původnímu objektu byly dány nové souřadnice a atributy dle ropik.net ... kde se bere jistota, že přispěvatelé ropiky.net mají lepší gpsky než přispěvatelé OSM? __ a než ruian... h. ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-de] Neue Mailing-Liste für Mapper der Region Tübingen
Hallo, ich möchte hiermit die neue Mailing-Liste [1] für Mapper der Region Tübingen ankündigen. Viele Grüße, dktue [1] http://lists.openstreetmap.de/mailman/listinfo/tuebingen ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] Modélisation des points d'eau incendie - Projet d'import des données du SDIS de l'Essonne
Bonjour, Personnellement je ne vois absolument par pourquoi on devrait appliquer une règle si on ne peut pas vérifier, alors il ne faut pas le mettre dans OSM. C'est très difficile à appliquer en pratique (cela dépend des compétences de chacun) et à mon avis totalement contre-productif. En tout cas je suis tout à fait d'accord avec l'argument de Dominique. Quand on fait l'extraction des données OSM pour utilisation dans un SIG, avoir directement les informations attributaires provenant des tags OSM, c'est quand même beaucoup plus exploitable que de devoir aller récupérer des données annexes dans une base externe et les joindre plus ou moins proprement avec les données provenant d'OSM. Avoir à faire ce genre de manipulations peut même être un frein à l'utilisation des données OSM. Tant qu'à aller chercher des informations ailleurs, autant tout prendre ailleurs... Nicolas - Nicolas Moyroud Site web libre@vous : http://libreavous.teledetection.fr - ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [propostition] Changement massif natural=rock vers bare_rock pour les surfaces ?
N'ayant pas eu beaucoup de réponse, je me permets une relance, pour une version réduite : J'ai 1083 ways et relation avec avec : natural=rock et source=Union européenne - SOeS, CORINE Land Cover, 2006. Je propose de m'en tenir à la conversion uniquement de ceux-là en natural=bare_rock -- sly, direct contact : sylv...@letuffe.org http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-be] Mapping in West-Vlaanderen
volgens http://resultmaps.neis-one.org/oooc?zoom=10lat=51.08579lon=3.89178layers=B00TFT zijn er ook niet zo heel veel mappers in West-Vlaanderen. mvg m 2015-02-27 11:39 GMT+01:00 Jakka vdmfrank...@gmail.com: Ben Abelshausen schreef op 26/02/2015 om 14:55: Hallo, 2015-02-21 10:35 GMT+01:00 Ben Abelshausen ben.abelshau...@gmail.com mailto:ben.abelshau...@gmail.com: Laat zeker weten als je dit ziet zitten. Laat je niet afschrikken voor de workload want dat zal nogal meevallen denk ik. = écht niemand die dit ziet zitten? Met vriendelijke groeten, Best regards, Ben Abelshausen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be @Ben weinig reactie op de vraag. - Zijn de West-Vlaamse mappers wel lid van deze list? Andere fora?. Persoonlijk vind ik deze list niet zo gebruiksvriendelijk om in te zoeken te raadplegen. (mogelijk persoonlijk gebrek aan kennis) - Nieuw geïnteresseerde komen op OSM via de web editors en lopen na enkel mappingen vast, mijn persoonlijk ervaring was, hulp zoeken op het net is niet evident, je verdrinkt als het ware in de wiki pagina's en termen en je klikt je steeds verder weg, van wat je eigenlijk zoekt. Heb eens mijn nabije buren opgevraagd. En zit hier dicht bij Franse grens dus mogelijk Buitenlanders erbij. wijzigingensets van gebruikers in de buurt dagboekberichten van gebruikers in de buurt pinguin_8123 (1 km verwijderd) (geen bewerkingen) colnagoboys (3 km verwijderd) (geen bewerkingen) jorisvdc (3 km verwijderd) (geen bewerkingen) coyke (3 km verwijderd) (geen bewerkingen) rafel1810 (4 km verwijderd) (geen bewerkingen) bekvh (4 km verwijderd) (geen bewerkingen) Garlaban (5 km verwijderd) (geen bewerkingen) Aäron Catteeuw (5 km verwijderd)(geen bewerkingen) on4dfc (5 km verwijderd)(geen bewerkingen) Chris DW (6 km verwijderd) (geen bewerkingen) Butchamon (6 km verwijderd) (geen bewerkingen) bridgemen (6 km verwijderd) (geen bewerkingen) jeanclaude1946 (4 km verwijderd)Laatste bewerking (25 dagen geleden): (geen reactie) dieterv (5 km verwijderd) Laatste bewerking (9 maanden geleden): Name Hadewijchplein, add Maria Rosseelsstraat Vampouille (6 km verwijderd)Laatste bewerking (bijna 2 jaar geleden): Calculated at 2013-04-16 16:02:21.680379 with 2106 Variance=310.1005937408907482 lucvhz (5 km verwijderd)Laatste bewerking (bijna 3 jaar geleden): first update Trogie (3 km verwijderd)Laatste bewerking (bijna 5 jaar geleden): Just for walking/bicycle Aled82 (5 km verwijderd)Laatste bewerking (meer dan 2 jaar geleden): (geen reactie) grmpyoldman (5 km verwijderd) Laatste bewerking (meer dan 2 jaar geleden): (geen reactie) Jacques Moulin (4 km verwijderd)Laatste bewerking (meer dan 2 jaar geleden): prolongement de sentiers Toubac (6 km verwijderd)Laatste bewerking (meer dan 3 jaar geleden): (geen reactie) jhonnydewitte (521 m verwijderd)Laatste bewerking (meer dan 5 jaar geleden): (geen reactie) arenalpoas (5 km verwijderd)Laatste bewerking (meer dan 5 jaar geleden): (geen reactie) pfArt (6 km verwijderd) Laatste bewerking (meer dan 6 jaar geleden): (geen reactie) KoenDeSmet (3 km verwijderd)Laatste bewerking (meer dan een jaar geleden): (geen reactie) willyamm (5 km verwijderd) Laatste bewerking (meer dan een jaar geleden): (geen reactie) TomDupont (6 km verwijderd) Laatste bewerking (ongeveer 17 uur geleden): (geen reactie) JeanBernard (6 km verwijderd) Laatste bewerking (ongeveer 2 jaar geleden): (geen reactie) aardmanneke (4 km verwijderd) Laatste bewerking (ongeveer 4 jaar geleden): Verbetering naam Busschaertstraat Bernard Decock (4 km verwijderd)Laatste bewerking (ongeveer een maand geleden): Naam van het pad toegevoegd volgens recente kaart van Kortrijk Dus uit deze lijst moet ik al niet veel aanschrijven voor samenwerking. Of is er een mogelijkheid wanneer er een definitieve datum bepaald is om mapping party via een persoonlijk mailing deze al dan niet warm te maken om terug met OSM te werken. Ikzelf zal de mapping party zoveel mogelijk bijwonen om zelf te leren. (Newbie Oktober 2014 en geen ICT achtergrond puur natuur hobby.) En ben bereid om een belangrijk deel van mijn tijd aan het voorgesteld project te besteden. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-ja] Clean-up?: KSJ2 administrative boundary import
いいだです。 ■行政区境データのクリーンナップについて この件、特にご意見ないでしょうか？ 良しも悪しも無いと、どう進めたらよいものか、ちょっと迷います。。。 2015年2月16日 12:24 Satoshi IIDA nyamp...@gmail.com: いいだです。 国土数値情報(KSJ2)をもとにした行政区境データのインポートの進捗報告と、 行政区境データのクリンナップについての相談です。 ■進捗どうですか SotM Japan 2014で報告したとおり、 九州、四国、中国地方のインポートが完了しています。 また、京都や三重、愛知あたりまで完了しています。 今後は静岡、岐阜から北陸に抜け、関東を後回しとして、東北地方を予定しています。 http://www.slideshare.net/nyampire/ss-42685235 ■行政区境データのクリーンナップについて 現在、広島や九州地方を中心に、海岸部分の行政区境ウェイデータを削除し、 海上のウェイをouter role memberとして置き換えているかたがいらっしゃいます。 http://www.openstreetmap.org/relation/4097196 この方法は、OverPass API等のクエリをかけるにはよいのですが、 面積計算が正しく行えない、市町村の形状が正しく描かれないなどのデメリットが存在します。 また、海上の境界線は boundary=maritimeとして、landareaとは区別されるべきです。 http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dmaritime 加えて、海外(主にヨーロッパ)の行政区境データを確認したのですが、 海岸線と行政区境データは1つのウェイとしてあらわされていることがほとんどのようです。 その場合、natural=coaslineのウェイを、 type=boundaryのリレーション内にouter roleとして配置します。 サンプルとして、南伊勢町を対応してみました。 表示が重いですが、ご確認ください。 http://www.openstreetmap.org/relation/4538785 http://www.openstreetmap.org/way/131050057 (memberである海岸線ウェイのひとつ) 最終的に、行政区境データはこの形になるのが正しいと思っていますが、どうでしょうか？ みなさんのご意見をお待ちしています。 -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-cz] ŘOPíky
Jarní prázdniny jsou v průběhu února až dubna, navrhuji, aby se důležitá rozhodnutí v tomto období neřešila, zvláště ne, když mají v Brně jarní prázdniny-další jsou 29.2.-6.3.2016. Dále aby se neřešila v období červenec, srpen, začátek září, prosinec (sháníte dárky), a leden, to se podává daňové přiznání z nemovitosti, také jsem zapoměl na DPH každý měsíc. Nic jste se mnou nediskutovali. Další věci budu dále dělat sám, dle svého nejlepšího vědomí a svědomí, bez Vaší konzultace, kdy neporadíte, ale vytýkáte. Děkuji za nespolupráci a z tohoto fóra odcházím. Petr PS: mám v plánu dodělat označení žel. přejezdů, tak abysme si nelezli do zelí. Dík PSS: pokud má někdo pocit, že jsem mu přemístil node s řopíkem, tak má původní ID -- Původní zpráva -- Od: Karel Volný ka...@seznam.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 27. 2. 2015 11:41:09 Předmět: Re: [Talk-cz] ŘOPíky Dne Pá 27. února 2015 11:20:52, hanoj napsal(a): Nikde, a jak to chcete vyřešit? nechat duplicity? Před importem jsem se ptal, jak se řeší duplicity, nikdo 2 dny neodpověděl. *** Je vhodne nechat na dulezita rozhodnuti jako import klidne 14 dni. To jsme myslim s tebou jednou diskutovali... Je tak neprekonatelne? FTR, tady v Brně jsou teď jarní prázdniny spousta lidí je tedy tento _celý_ týden na dovolené přinejmenším někteří z nich vůbec bez přístupu k Internetu, a u těch, co přístup mají, bych si dovolil vyjádřit pochybnosti o ochotě a vůbec volném čase k řešení věcí z mailinglistů (ostatně i pokud jsou lidé doma, mohu jen závidět, pokud je na tom někdo tak dobře, že si může dovolit, aby u něj OSM mělo každodenně vyšší prioritu nežli třeba daňové přiznání, které pomalu klepe na dveře, apod.) K. ___ 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
Re: [OSM-ja] インポートデータに関する削除について
いいだです。 ikiyaさん タクスマネージャーを使って、明らかに基盤地図情報以外のソースで書かれている ことが確認できたエリヤ（OKですよエリヤ）を増やしていく作業を進めればよいと思います。 はい、そうですね。 ぱっと見ですが基本的に、吉野川流域の市町村と、徳島市周辺の海側を中心にインポートが行われているようです。 (山の中はあまりない、はず) JOSMで比較してみるなら、 基盤地図情報をそのものを背景にして見る（チェックする）ことがベストと思います。 はい、それができるかたはそれのほうが良いと思います。 ただ、僕だけなのかもしれませんが、農研さんの基盤地図情報タイルはやたらと反応速度が悪く、 確認にかなりの時間がかかります。 また、元データからの変換も、 慣れたかたはさっとできますが、逆に、そうでないかたにはわりと手間かな、と思っています。 トレースの場合はBingを使われているようなので、 明らかに地理院地図とも異なった場所に建物が描かれているようであり、 地理院タイルでもそれなりに確認の用は足りるように見えます。 http://wiki.openstreetmap.org/wiki/JA:GSI_KIBAN もっといえば、建物データの緯度経度をdiffとってチェックできればよいのですが、 ちょっと僕には難しいです。すみません。 centreeさん 幸いなことに、削除（候補）のデータはおろか、 building=yesのデータも見つからない地域でした。 （わざと難しくなさそうな地域を狙ったのもありますが） いったん論議がまとまるまで作業を止めておきます。 はい、そういった、「対象データのない地域」を確定させることを最初にしよう、という話かと思います。 助かります。 ikiyaさんの案（タスクマネージャ―でまず情報収集） + 適度な期限の設定（期限が過ぎた場合の対応も決めておく）を すると、うまくいくような気もします…が、どうでしょう…？ 期限を切るのはよいですね。 作業の進捗スピードを見ながら決めるのがよいのかな、と思います。 user:kikkawamitsuru もインポートに使われているような気もします ありがとうございます、確認しました。 使われていますね。 Task Managerのほうにも追記を行いました。 また、すみませんが、今週末は僕が全く作業に動けません。 メールは見れると思いますので、ちょっと作業やってみて、 不明点などあればご意見いただけると嬉しいです。 -- 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-fr] illustration pour les nouveaux cantons
Le 27 février 2015 22:52, Philippe Verdy verd...@wanadoo.fr a écrit : Le 27 février 2015 22:20, Christian Quest cqu...@openstreetmap.fr a écrit : 90% de ce qui a été semi-automatisé est ok et beaucoup de temps a été gagné par rapport à l'usage classique de comcommaker vu qu'on n'avait pas de liste de codes INSEE qui aurait permis de faire directement mieux. Les décrets contenaient les noms de communes exacts (à quelques différences comme les accents omis sur les capitales). Il fallait les faire coller avec le numéro de département pour éviter de prendre des homonymes. Malgré cela je ne sais pas comment tu t'es débrouillé pour aller chercher d'autres communes ailleurs, qui n'ont même pas le même nom et même pas toujours dans le même département. Toujours aussi prompt à prendre les gens pour des idiots, que ça fait du bien de ne plus lire ce genre de message ! Bien sûr que j'ai pris le n° de département pour éviter les homonymes... et j'ai fait gaffe pour l'unique cas d'homonyme dans le même département. Le script est sur https://gist.github.com/cquest/c008db0ea286ae289276 pour vérifier, c'est même le premier paramètre. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Plans lignes RER?
Merci mais je cherchais ça… http://gis.19327.n5.nabble.com/file/n5835271/plan-rer.gif http://www.plandeparis.info/plan-rer/plan-rer.gif … avec 1. une carte géographique en fond de carte, et 2. une seule ligne par carte (RER A, B, C, D, E) -- View this message in context: http://gis.19327.n5.nabble.com/Plans-lignes-RER-tp5835260p5835271.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
Re: [OSM-talk-fr] [newbie] Pourquoi OSM n'affiche pas les grandes villes?
À peine. Je viens de refaire le test avec Poissy, et ça n'apparaît toujours pas à des niveaux de zoom normaux, là où le hameau de Carrières-sous-Poissy apparait. Heureusement que je sais où se trouve Poissy ;-) Et je continue à détester le rendu MapNik (l'écrasante majorité du temps, je n'ai pas besoin de voir les blocs d'immeubles ni de toutes ces couleurs différentes), d'où ma préférence pour Mapquest. Mais au moins, j'ai mieux compris le choix d'OSM d'afficher ou pas des villes importantes. -- View this message in context: http://gis.19327.n5.nabble.com/newbie-Pourquoi-OSM-n-affiche-pas-les-grandes-villes-tp5835189p5835272.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
Re: [OSM-talk-be] Mogelijkheid om een SIMPELE 'button' of zoiets in josm te verkrijgen , om fouten door te seinen naar AGIV ?
On 2015-02-28 00:28, Glenn Plas wrote : Zie http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Using_AGIV_Crab_data/Reporting_errors_to_AGIV https://crab.agiv.be/Lara/Home/Index2 Lara heet het. Simpel is het niet bij veel fouten. Glenn Anything semblable voor SPW? ;-) There is a JOSM ExtTools plugin that allows a script (1) to be written, configured and invoked. The script is passed the coordinates of the clicked point. If that's all that's needed to make an AGIV report, the script could send an e-mail to contactp...@agiv.be. (plus standard and script prompted text, of course). I suppose it should be rather straightforward. The script is supposed to return a .osm file to update the current layer but I imagine that it can send an e-mail instead. JS example. VBS example. Also Scripting Plugin, but apparently less adequate. And what about reporting roadsign errors or such things to MET (Transport Ministry)? I spotted a missing 30 km/h zone sign in Esneux. I posted every MET e-mail address I could find without an answer. I wrote to the SPW help desk, asking for a MET alert address and she replied there is none. The sign stayed missing for 6 month until they planted a temporary one. And exceeding speed limit is a highest severity offense! And now it's the opposite end of zone sign that's broken down. In compensation, maybe? Cheers André. (1) program usually written in one of the many interpreted languages that are readily available in Unix On 27-02-15 22:52, hvdb wrote: Als je een fout vind, kan je contact opnemen met : AGIV-contactpunt. T 09 276 15 00 | F 09 276 15 05 | contactp...@agiv.be mailto:contactp...@agiv.be | www.agiv.be http://www.agiv.be Het AGIV contactpunt is bereikbaar op weekdagen van 8u00 tot 17u00. doch, als je 'ettelijke' fouten vind, is het wel 'vermoeiend' om telkens een hele 'rimram' te moeten gaan mailen of telefoneren naar AGIV. Daarom zou het meer 'comfortabeler' zijn, als er een soort 'button' of zoiets, dat, wanneer je daar dan op klikt, je ergens direkt een 'link' kan geven met de coordinaten ofzoiets , waar de fout zit, en dan wat uitleg ... ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
