Re: [OSM-talk] Draft updated privacy policy
I've updated the document https://wiki.openstreetmap.org/wiki/Updated_Privacy_Policy#Log_files_and_Information_submitted_to_OSMF_Services with some additional text to address the handful of things people felt were missing. If there are no further comments I would suggest using this as a replacement till such a time that we have a completely redone policy. Simon Am 16.06.2015 um 13:17 schrieb Simon Poole: And now for something completely different. I've produced an updated version of the OSM privacy policy: http://wiki.openstreetmap.org/wiki/Updated_Privacy_Policy (the original resides here: http://wiki.openstreetmap.org/wiki/Privacy_Policy). This is largely a private undertaking, it however has been available to stakeholders in the original document and the relevant OSMF working groups for comments and suggestions which have been worked in to the text. The LWG has somewhere on its to-do list an item on a complete review and rewrite of the privacy policy, this is not a replacement for that. It is however likely that whoever does that rewrite would refer to this document or the original privacy policy for the OSM related specifics. Neither the original policy nor this document are published and/or approved OSMF documents, but they should likely be considered for that, at least until a full rewrite is completed. My motivation was mainly that there are some things that should be in the document that are not, and the complications that a complete rewrite as in for example https://wikimediafoundation.org/wiki/Privacy_policy will entail. All that said, the changes are, with one exception, likely uncontroversial and simply document what is current practice. Obvious and clear for old hands, probably not so for newcomers. The exception is the addition of a clause that allows us (the OSM community) to use information submitted to an OSMF run services to be used to support improving the OSM data. Right now the only use of this that I could think of is to mine nominatim queries for missing addresses, postcodes and the like. The is currently NOT done, because it is a potential touchy issue, but it would have some obvious benefits. Comments on the draft are likely best added to the discussion page. Please keep the scope of any comments limited to the changes and not to untouched original text, one day there will be a complete rewrite and that will be the time to address any other issues. Simon ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
Quelqu'un a l'expérience de geogig http://geogig.org/ geogig http://sourceforge.net/projects/geogig/ (anciennement geogit) ? Il y a comme une petite restriction : /The default underlying object database (berkeley db) is single user./ Quand à la comparaison avec Wikimafia, leur problème c'est qu'ils ont des administrateurs (*) non neutres (contrairement à leur règlement mais comme ce sont les administrateurs qui administrent...). Du coup ils sont possibilité de mettre des pages en modification bloquée/protégée/semi-protégée. Un tag data_protection=blocked / protected... et une date de fin pourrait être une solution (à condition que les éditeurs les prennent en compte). Allez faisons riches: data_protection:level data_protection:until data_protection:ref (ref : référence à une page de discussion). Je préfère pouvoir compter sur le bons sens que sur l'administration qui peut être corrompue. Et si le comportement d'un utilisatieur pose problème on peut le bloquer. Jean-Yvon (*) au sens informatique, pas au sens associatif. Le 18/07/2015 02:14, Philippe Verdy - verd...@wanadoo.fr a écrit : Bref ce qui est décide le mois n est vite obsolète des le mois n+1, comme est en fait la totalité de la base qui n'a strictement aucun degré de protection. La dessus osm fait beaucoup moins bien que wikilrdua qui permet a tout moment de tracer des décisions prises tout en ne bloqyantvpas tout définitivement sur des bases obsolètes car il est ensuite permis de présenter de nouveaux arguments et d'évoluer mêle su c'est moins facile que lors des premières éditions ou chacun faisait ses modifs avec moins de besoin pour une concertation. Il faudra bien qu'osm passe a un système de versionnelent multuniveau maus aussi ouvert sue peut l'être gît. Ca voudra dire permettre d'avoir différents forks de la base de données et des échanges et validations et fusions d'une base a l'autre. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Relation Itinéraires vélo
Petits rappels: Sur un highway, ref est utilisé pour la nomenclature de la route elle même, pas pour les multiples itinéraires (vélo, mais aussi bus, rando, etc) qui pourraient passer par là. Même logique pour name=* Les itinéraires sont décrits à l'aide de relations et c'est sur la relation qu'on indiquera son numéro / ref / name. Pour la nomenclature européenne des routes (exemple E54), on utilise un deuxième tag pour ça: int_ref Le 15/07/2015 21:46, George Kaplan a écrit : Un way automobile qui est emprunté par une route cycliste prend-il comme référence, en plus de la référence de type D 951, la référence cycliste, E 32 : Ref= D 951;E 32 ? C'est même l'essentiel des itinéraires cyclables, ils empruntent beaucoup de routes à circulation générale de faible fréquentation. Pour répondre à ta question, c'est non : j'ai lu quelque part à mes début d'OSM, qu'en France, la convention veut que l'on n'indique qu'une seule référence. Je ne retrouve plus l'origine de cette information. Merci de vos réponses Bernard -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] 盆栽園のタグについて
いいだです。 ちゃんと調べていないのですが、 詳しいタグは未定義として、 amenity=nurseryは、育児施設としてProposedされているものです。 http://wiki.openstreetmap.org/wiki/Proposed_features/Nursery なので、とりいそぎ、amenity=plant_nurseryのほうがよいのじゃないかと思います。 https://taginfo.openstreetmap.org/search?q=nursery#values ちなみに盆栽村っていうのがどんな施設かまったくわからないのですが、 これは、盆栽を育てる（苗床）の施設なのでしょうか。それとも、展示のための施設？ amenityだと、サービスや公共のための施設ぽいので、 craftなどのキーのほうがよいような気がしています。 2015年7月18日 14:46 Takeshi FURUTA MQSOL LLC fur...@mq-sol.jp: ふるた＠Code for SAITAMAです。 本日、大宮盆栽村でのマッピングパーティを行いました。来園自由の盆栽園があ るのですが、Taginfoを調べましたがぴったりとしたタグがないので、仮に以下 のタグ付けを行いました。 amenity:nursery 種苗店 nursery:dwarf_tree もしくは nursery:bonsai として登録しています。正しいタグがあれば登録し直したいと思います。 合同会社 マップクエストソリューションズ （ http://mq-sol.jp/ ） 代表 古田 武士 ( fur...@mq-sol.jp ) 住所： 〒331-0013 埼玉県戸田市喜沢１−３３−８ ベルテラス板橋２０２ 電話： 03-5843-5923 携帯：090-8985-1587 FAX： 048-229-0554 ___ 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-ja] 盆栽園のタグについて
こんにちは。muramotoです。 私も盆栽園がどういった施設か正確にはわからないのですが、 種苗店の名のとおり販売が主体なら、shop=garden_centre http://wiki.openstreetmap.org/wiki/JA:Tag:shop%3Dgarden_centre 鑑賞が主体なら、leisure=garden http://wiki.openstreetmap.org/wiki/JA:Tag:leisure%3Dgarden ではいかがでしょうか。 2015年7月18日 15:52 Satoshi IIDA nyamp...@gmail.com: いいだです。 ちゃんと調べていないのですが、 詳しいタグは未定義として、 amenity=nurseryは、育児施設としてProposedされているものです。 http://wiki.openstreetmap.org/wiki/Proposed_features/Nursery なので、とりいそぎ、amenity=plant_nurseryのほうがよいのじゃないかと思います。 https://taginfo.openstreetmap.org/search?q=nursery#values ちなみに盆栽村っていうのがどんな施設かまったくわからないのですが、 これは、盆栽を育てる（苗床）の施設なのでしょうか。それとも、展示のための施設？ amenityだと、サービスや公共のための施設ぽいので、 craftなどのキーのほうがよいような気がしています。 2015年7月18日 14:46 Takeshi FURUTA MQSOL LLC fur...@mq-sol.jp: ふるた＠Code for SAITAMAです。 本日、大宮盆栽村でのマッピングパーティを行いました。来園自由の盆栽園があ るのですが、Taginfoを調べましたがぴったりとしたタグがないので、仮に以下 のタグ付けを行いました。 amenity:nursery 種苗店 nursery:dwarf_tree もしくは nursery:bonsai として登録しています。正しいタグがあれば登録し直したいと思います。 合同会社 マップクエストソリューションズ （ http://mq-sol.jp/ ） 代表 古田 武士 ( fur...@mq-sol.jp ) 住所： 〒331-0013 埼玉県戸田市喜沢１−３３−８ ベルテラス板橋２０２ 電話： 03-5843-5923 携帯：090-8985-1587 FAX： 048-229-0554 ___ 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 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-talk-fr] [Osmose] Ajout d'un test sur la nature en tant que nom d'objet
Le 17 juil. 2015 à 16:25, Yves Pratter yves.prat...@gmail.com mailto:yves.prat...@gmail.com a écrit : J’ai rajouté de mémoire ce qu’on trouve sur le cadastre (Croix, Fontaine) et ce que je trouve dans taginfo (Fontaine d’eau potable). Pour les croix, overpass en trouve : 326 pour “name=Croix” dont 267 pour “name=Croix and historic=wayside_cross” : http://overpass-turbo.eu/s/atM http://overpass-turbo.eu/s/atM 23 pour “name=Croix and amenity=place_of_worship” : http://overpass-turbo.eu/s/atT http://overpass-turbo.eu/s/atT 4 pour “name=Croix and aerialway=station” : http://overpass-turbo.eu/s/atU http://overpass-turbo.eu/s/atU A Megève, le nom a été mis sur les pylônes de départ et d’arrivé au lieu d’être mis sur le téléski 3 pour “name=Croix and historic=memorial” : http://overpass-turbo.eu/s/atO http://overpass-turbo.eu/s/atO 1 pour “name=Croix and natural=peak” : http://overpass-turbo.eu/s/atS http://overpass-turbo.eu/s/atS Pour les fontaines : « name=fontaine and amenity=drinking_water » « name=fontaine and amenity=fountain » « name=fontaine and natural=spring » « name=fontaine and man_made=water_well » « name=fontaine and landuse=basin » « name=fontaine and amenity=public_building » « name=fontaine and natural=water » il y a aussi le tag name sans aucun autre tag. — Yves___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] 盆栽園のタグについて
いいだです。 種苗店の名のとおり販売が主体なら、shop=garden_centre http://wiki.openstreetmap.org/wiki/JA:Tag:shop%3Dgarden_centre 鑑賞が主体なら、leisure=garden http://wiki.openstreetmap.org/wiki/JA:Tag:leisure%3Dgarden +1 2015年7月18日 16:23 tomoya muramoto muramototom...@gmail.com: こんにちは。muramotoです。 私も盆栽園がどういった施設か正確にはわからないのですが、 種苗店の名のとおり販売が主体なら、shop=garden_centre http://wiki.openstreetmap.org/wiki/JA:Tag:shop%3Dgarden_centre 鑑賞が主体なら、leisure=garden http://wiki.openstreetmap.org/wiki/JA:Tag:leisure%3Dgarden ではいかがでしょうか。 2015年7月18日 15:52 Satoshi IIDA nyamp...@gmail.com: いいだです。 ちゃんと調べていないのですが、 詳しいタグは未定義として、 amenity=nurseryは、育児施設としてProposedされているものです。 http://wiki.openstreetmap.org/wiki/Proposed_features/Nursery なので、とりいそぎ、amenity=plant_nurseryのほうがよいのじゃないかと思います。 https://taginfo.openstreetmap.org/search?q=nursery#values ちなみに盆栽村っていうのがどんな施設かまったくわからないのですが、 これは、盆栽を育てる（苗床）の施設なのでしょうか。それとも、展示のための施設？ amenityだと、サービスや公共のための施設ぽいので、 craftなどのキーのほうがよいような気がしています。 2015年7月18日 14:46 Takeshi FURUTA MQSOL LLC fur...@mq-sol.jp: ふるた＠Code for SAITAMAです。 本日、大宮盆栽村でのマッピングパーティを行いました。来園自由の盆栽園があ るのですが、Taginfoを調べましたがぴったりとしたタグがないので、仮に以下 のタグ付けを行いました。 amenity:nursery 種苗店 nursery:dwarf_tree もしくは nursery:bonsai として登録しています。正しいタグがあれば登録し直したいと思います。 合同会社 マップクエストソリューションズ （ http://mq-sol.jp/ ） 代表 古田 武士 ( fur...@mq-sol.jp ) 住所： 〒331-0013 埼玉県戸田市喜沢１−３３−８ ベルテラス板橋２０２ 電話： 03-5843-5923 携帯：090-8985-1587 FAX： 048-229-0554 ___ 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 ___ 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] [Osmose] Ajout d'un test sur la nature en tant que nom d'objet
Le 18/07/2015 10:02, Yves Pratter a écrit : Le 17 juil. 2015 à 16:25, Yves Pratter yves.prat...@gmail.com mailto:yves.prat...@gmail.com a écrit : J’ai rajouté de mémoire ce qu’on trouve sur le cadastre (Croix, Fontaine) et ce que je trouve dans taginfo (Fontaine d’eau potable). Pour les croix, *overpass* en trouve : * 326 pour “name=Croix” dont * 267 pour “name=Croix and *historic=wayside_cross*” : http://overpass-turbo.eu/s/atM * 23 pour “name=Croix and *amenity=place_of_worship*” : http://overpass-turbo.eu/s/atT * 4 pour “name=Croix and *aerialway=station*” : http://overpass-turbo.eu/s/atU A Megève, le nom a été mis sur les pylônes de départ et d’arrivé au lieu d’être mis sur le téléski * 3 pour “name=Croix and *historic=memorial*” : http://overpass-turbo.eu/s/atO * 1 pour “name=Croix and *natural=peak*” : http://overpass-turbo.eu/s/atS Pour les fontaines : « name=fontaine and amenity=drinking_water » « name=fontaine and amenity=fountain » « name=fontaine and natural=spring » « name=fontaine and man_made=water_well » « name=fontaine and landuse=basin » « name=fontaine and amenity=public_building » « name=fontaine and natural=water » il y a aussi le tag name sans aucun autre tag. Il faudrait tester la proposition de tag automatiquement en fonction du name, pour les name sans autres tags pertinent en fonction des statistiques de ce même name quand il y a d'autres tags. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] Valori multipli per highway
io scopi forestali, e gli scopi agricoli li ho sempre intesi tali, probabilmente quindi sbagliando, quando la strada è usata per attività economiche basate sulla foresta o l'agricoltura...qui parliamo di manutenzione al fine di farci passare le persone quindi non è di per se la gestione della foresta l'attività economica, ma il turismo in essa e in quest'ottica la gestione della foresta diventa una conseguenza di quell'attività economica, non lo scopo della strada...è la stessa cosa? è questo che non capisco...avrei pensato al massimo ad un service...la situazione mi sembra similare per esempio al parco della Reggia di Caserta http://www.openstreetmap.org/way/24225619 dove le way sono segnate come pedonali (forse visto come sono strutturate era meglio un pedestrian) ma la strada usata regolarmente da vari mezzi boschivi per la manutenzione del verde(e anche i mezzi della guardia credo privata per il monitoraggio della zona). Dovrebbe essere anche quello track quindi? - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Valori-multipli-per-highway-tp5849984p5850434.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] name principale vette montagna su confini nazionali
Non sto seguendo la discussione con i cugini d'oltralpe. Mah... che dire? Che a livello internazionale quello che per tutti, da sempre è universalmente riconosciuto come Mont Blanc, al momento è questo: http://gis.19327.n5.nabble.com/file/n5850436/montblanc.jpg Al di la delle battute, qui direi che non bisogna cadere in questioni nazionalistiche, geopolitiche-amministrative oppure di convenienza turistica, che non dovrebbero riguardarci. Il name che viene mostrato a schermo è uno. Mettere il doppio nome io personalmente, non sono daccordo. Non è un problema che si chiamino Mont Blanc, Matterhorn, Castor ect... quello che conta è che la regola logica da applicare, per questi casi sia uguale e da tutti riconosciuti ed accettata dalla comunità Saluti Otourly Wiki wrote Ho lasciato un messaggio su talk-fr :http://talk-fr.openstreetmap.narkive.com/8aIohXsv/osm-talk-fr-frontiere-franco-italienne-du-mont-blanc Florian Le Vendredi 17 juillet 2015 16h12, Max1234Ita lt; max1234ita@ gt; a écrit : Più che soltanto i francesi bisognerebbe capire se ci sono delle direttive OSM a livello internazionale, non credo che al mondo ci siano solo Italia e Francia a litigarsi montagne, fiumi, laghi, ecc... Poi ci può stare un confronto tra mappatori italo/franco/svizzero/austro/sloveni al fine di riunire in un solo punto le informazioni ridondanti. Io, a buonsenso, proporrei un solo nodo, così taggato: natural=peak name=Mont Blanc/Monte Bianco (in rigoroso ordine *alfabetico*, così da ridurre le possibili contese su chi ha rivendicato per primo la vetta nel corso della Storia) name:it=Monte Bianco name:fr=Mont Blanc ele=4810 Sarebbe troppo pragmatica una soluzione di questo genere? Ciao, Max -- View this message in context: http://gis.19327.n5.nabble.com/name-principale-vette-montagna-su-confini-nazionali-tp5850301p5850406.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@ https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@ https://lists.openstreetmap.org/listinfo/talk-it -- View this message in context: http://gis.19327.n5.nabble.com/name-principale-vette-montagna-su-confini-nazionali-tp5850301p5850436.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
tous les projets collaboratifs ont des niveaux de privilèges qui s'acquirent avec l'expérience passée sur un projet et des postes pouvant être remis en cause par un processus collectif ou par désistement. Ce n'est pas toujours simple pour gérer les conflits aux niveaux les plus privilégiés, mais un bon moyen de les éviter est d'offrir un système ne restreignant jamais la création de forks ni le nombre de serveurs pour les héberger. Git est un tel système qui évite la concentration des pouvoirs et permet à chaque branche de se développer sans perturber les autres qui préfèrent une autre branche (la notion de trunk est en fait purement locale à un seul des serveurs, les autres serveurs de branche ont chacun leur préférence sur la branche principale à utiliser, il n'y a as plus de mérite pour une branche ou pour une autre quelque soit le nombre des utilisateurs qui les référence, et cela fait aussi disparaitre les notions d'urgence à déployer et la tentation de vouloir effacer ou refuser le travail d'un voisin. Le 18 juillet 2015 10:13, osm.sanspourr...@spamgourmet.com a écrit : Quelqu'un a l'expérience de geogig http://geogig.org/ geogig http://sourceforge.net/projects/geogig/ (anciennement geogit) ? Il y a comme une petite restriction : *The default underlying object database (berkeley db) is single user.* Quand à la comparaison avec Wikimafia, leur problème c'est qu'ils ont des administrateurs (*) non neutres (contrairement à leur règlement mais comme ce sont les administrateurs qui administrent...). Du coup ils sont possibilité de mettre des pages en modification bloquée/protégée/semi-protégée. Un tag data_protection=blocked / protected... et une date de fin pourrait être une solution (à condition que les éditeurs les prennent en compte). Allez faisons riches: data_protection:level data_protection:until data_protection:ref (ref : référence à une page de discussion). Je préfère pouvoir compter sur le bons sens que sur l'administration qui peut être corrompue. Et si le comportement d'un utilisatieur pose problème on peut le bloquer. Jean-Yvon (*) au sens informatique, pas au sens associatif. Le 18/07/2015 02:14, Philippe Verdy - verd...@wanadoo.fr a écrit : Bref ce qui est décide le mois n est vite obsolète des le mois n+1, comme est en fait la totalité de la base qui n'a strictement aucun degré de protection. La dessus osm fait beaucoup moins bien que wikilrdua qui permet a tout moment de tracer des décisions prises tout en ne bloqyantvpas tout définitivement sur des bases obsolètes car il est ensuite permis de présenter de nouveaux arguments et d'évoluer mêle su c'est moins facile que lors des premières éditions ou chacun faisait ses modifs avec moins de besoin pour une concertation. Il faudra bien qu'osm passe a un système de versionnelent multuniveau maus aussi ouvert sue peut l'être gît. Ca voudra dire permettre d'avoir différents forks de la base de données et des échanges et validations et fusions d'une base a l'autre. ___ 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-cz] OSMAnd+ stahuje polskou Wikipedii Česka???
Zdravím, Wikipedie se t.č. stahuje podle lokalizace hesla do regionu, ne podle jazyka. Teď jsem ve Francii a k nekterym místům mi to nabídlo heslo v několika jazycích, třeba holandštinu nebo italštinu :-) Možná by to chtělo přidat filtr k zobrazení pouze preferovaného jazyka či jazyků... Petr Dne 18.7.2015 1:35 Matěj Cepl mc...@cepl.eu napsal(a): Nevíte někdo proč OSMAnd+ (z f-droid) 2.1.1 stahuje pro Česko polský text Wikipedie? Matěj -- http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC [...] a superior pilot uses his superior judgment to avoid having to exercise his superior skill. -- http://www.jwz.org/blog/2009/09/that-duct-tape-silliness/#comment-10653 ___ 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] 盆栽園のタグについて
にしむらです 販売目的の種苗店に近いものを探されているなら shop=garden_centre もありかと思います http://wiki.openstreetmap.org/wiki/JA:Tag:shop=garden%20centre?uselang=ja 2015/07/18 15:52、Satoshi IIDA nyamp...@gmail.com のメッセージ: いいだです。 ちゃんと調べていないのですが、 詳しいタグは未定義として、 amenity=nurseryは、育児施設としてProposedされているものです。 http://wiki.openstreetmap.org/wiki/Proposed_features/Nursery なので、とりいそぎ、amenity=plant_nurseryのほうがよいのじゃないかと思います。 https://taginfo.openstreetmap.org/search?q=nursery#values ちなみに盆栽村っていうのがどんな施設かまったくわからないのですが、 これは、盆栽を育てる（苗床）の施設なのでしょうか。それとも、展示のための施設？ amenityだと、サービスや公共のための施設ぽいので、 craftなどのキーのほうがよいような気がしています。 2015年7月18日 14:46 Takeshi FURUTA MQSOL LLC fur...@mq-sol.jp: ふるた＠Code for SAITAMAです。 本日、大宮盆栽村でのマッピングパーティを行いました。来園自由の盆栽園があ るのですが、Taginfoを調べましたがぴったりとしたタグがないので、仮に以下 のタグ付けを行いました。 amenity:nursery 種苗店 nursery:dwarf_tree もしくは nursery:bonsai として登録しています。正しいタグがあれば登録し直したいと思います。 合同会社 マップクエストソリューションズ （ http://mq-sol.jp/ ） 代表 古田 武士 ( fur...@mq-sol.jp ) 住所： 〒331-0013 埼玉県戸田市喜沢１−３３−８ ベルテラス板橋２０２ 電話： 03-5843-5923 携帯：090-8985-1587 FAX： 048-229-0554 ___ 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 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-ar] Felicitaciones a todos los maperos
Hola Gabriel, Me alegro que te haya gustado el mapa. Si bien hay lugares más completos que otros, creo que en general el nivel de cobertura es bastante parejo en todo el país. Cualquier colaboración es bienvenida y aporta a OSM, ya sea desde promoción con tus conocidos o donde puedas, ediciones de cosas que quieras mejorar, hasta incluso usar el mapa y avisarnos de cosas a agregar/corregir. Saludos, Pablo 2015-07-15 12:47 GMT-03:00 Gabriel gepat...@gmail.com: Recien vuelvo de unos días de vacaciones en BsAs, y es la segunda vez que uso los mapas de OSM en el GPS: la primera para venir de La Falda a San Martín de los Andes, y la segunda para ir y venir de SMA a BA. Tengo que felicitarlos a todos, el nivel de detalle del mapa es genial, apenas si faltan algunas rutas o caminos que cruzan la RN5 entre Santa Rosa y Mercedes. El resto está super completo. Si el nivel de detalle y cobertura del mapa es tan bueno en todo el país, deberíamos ver como hacer para promocionarlo y que lo use más gente. Por mi parte, no vuelvo más al Mapear. Saludos! -- [image: --] Gabriel Patiño [image: http://]about.me/gepatino http://about.me/gepatino?promo=email_sig ___ Talk-ar mailing list Talk-ar@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ar ___ Talk-ar mailing list Talk-ar@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ar
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
*Franchement je suis d'accord aussi, mais quoi qu'on du se ici ou dans divers forums, il y aura toujours un utilisateur plus malin qui voudra corriger en étant persuadé qu'il a raison et qui n'aura rien lu de ce qui se passe ici. * Salut, Un moyen sur serait de transférer la discussion sur le wiki d'openstreetmap et d'adjoindre sur les éléments du tracé concernant cette zone de chevauchement un commentaire renvoyant sur cette discussion et une page spécifique à la gestion des frontières. Demander à ne pas manipuler sauf personne compétente de la même manière que les points géodésiques. C'est le wiki qui guide la manière de taguer et de dessiner donc autant que ce soit décrit au bon endroit. La liste de discussion c'est pour affirmer, corriger, ou confirmer des points de vue sur les bonnes pratiques ou des sujets permettant de compléter des informations manquantes de mon point de vue. *Le 18 juillet 2015 11:34, Philippe Verdy verd...@wanadoo.fr verd...@wanadoo.fr a écrit :* *tous les projets collaboratifs ont des niveaux de privilèges qui s'acquirent avec l'expérience passée sur un projet et des postes pouvant être remis en cause par un processus collectif ou par désistement. Ce n'est pas toujours simple pour gérer les conflits aux niveaux les plus privilégiés, mais un bon moyen de les éviter est d'offrir un système ne restreignant jamais la création de forks ni le nombre de serveurs pour les héberger. Git est un tel système qui évite la concentration des pouvoirs et permet à chaque branche de se développer sans perturber les autres qui préfèrent une autre branche (la notion de trunk est en fait purement locale à un seul des serveurs, les autres serveurs de branche ont chacun leur préférence sur la branche principale à utiliser, il n'y a as plus de mérite pour une branche ou pour une autre quelque soit le nombre des utilisateurs qui les référence, et cela fait aussi disparaitre les notions d'urgence à déployer et la tentation de vouloir effacer ou refuser le travail d'un voisin.* Tu sous-entends qu'OSM à choisi une gestion à la mode de l'armée mexicaine ;-) * (ref : référence à une page de discussion). Je préfère pouvoir compter sur le bons sens que sur l'administration qui peut être corrompue. Et si le comportement d'un utilisatieur pose problème on peut le bloquer. Jean-Yvon (*) au sens informatique, pas au sens associatif.* Tiens ça me rappel le principe de google mapmaker... Tu as beau avoir pris les info sur le terrain et être cartographe, on te votre modification a été refusé car nous n'avons pas le moyen de vérifier ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Il est clair que la licence actuelle de PSS n'est pas compatible avec une intégration de toute ou partie de ces données dans OSM. A chaque fois qu'on parle d'import ou autre, il faut TOUJOURS s'occuper de la partie légale avant de s'attaquer à la technique. ça évite de perdre du temps pour se retrouver coincer au final. Il me semble que ce point a été soulevé relativement tôt à propos de PSS. Autre chose non évaluée... d'où viennent les données de localisation de PSS ? C'est sur un fond Google ou par géocodage que les lat/lon ont été déterminés ? Dans ce cas, PSS ne peut pas les utiliser ailleurs que sur Google Maps et OSM ne peut pas non plus les réutiliser... Il y a une différence de philosophie importante entre PSS et OSM. Le choix d'une licence CC-by-NC-ND très peu libre et ouverte par rapport à l'ODbL qui limite très peu les usages mais pousse à contribuer. Malheureusement ce n'est pas la première fois qu'on ne peut faire converger un projet de ce type avec OSM sauf à faire comprendre aux contributeurs de ce projet qu'ils font un petit peu fausse route... par exemple en utilisant GMaps d'un côté et donc en autorisant Google à faire ce qu'ils veulent des données PSS (y compris un usage commercial) et de l'autre à ne pas trouver un moyen de collaborer avec OSM... Faire naitre une vraie réflexion côté PSS est à mon avis la meilleure suite. Le 16/07/2015 23:03, Jérôme Seigneuret a écrit : Désolé pou l’émoticône. Mais c'était juste une pointe sarcastique. Je te rejoins en tous points. J'ai aussi une double casquette comme Jean Yvon. Il présente ce sûr quoi j'ai pas voulu m’étaler. Je ne sais pas si la 3D commence à percer mais la hauteur peut en effet être intéressante. Ça alimentera http://osmbuildings.org/ Le 16 juillet 2015 22:32, osm.sanspourr...@spamgourmet.com mailto:osm.sanspourr...@spamgourmet.com a écrit : Par rapport à la réponse de Jérôme j'allais vous répondre en MP : Je dirais +1, sauf que vu l'émoticône, je dis : Donc en clair ça sert à rien *;-( *Je suis aussi d'accord avec le nouveau message de Jérôme.* * Par contre ça vaut peut-être le coup de revenir vers eux : à quoi ça leur sert de restreindre cette information à but non commercial. Le nom des bâtiments et la hauteur ne sont pas des secrets. Donc c'est de l'information publique. Demander d'ajouter : source:name=/PSS-archi.eu /source:height=/PSS-archi.eu/ Me semblerait plus efficace (pour nous car sinon on ne peut l'utiliser) et pour eux (plus grande visibilité si on extrait ou regarde des données de près). Et proposer de mettre un ref:pss-archi pour leur référence. Tu dis en plus que c'est fait par des bénévoles, il me semble donc évident que ça ne devrait pas poser de soucis s'ils peuvent faire un sondage auprès de leurs bénévoles, passer à la licence ODbL, n'est-on pas des centaines de milliers de bénévoles à l'avoir fait ? N. B. : je suis contributeur à tire privé, mais je monte une pile OSM à titre professionnel. Ça ne nous permet que de proposer un service de meilleure qualité qu'une carte Nasa Blue Marble ou Natural Earth, on ne vendra pas notre solution un centime de plus. Et la hauteur d'un bâtiment ou son nom c'est un plus pour les secours. Personnellement il me semble bien plus valorisant pour PSS-archi.eu d'offrir les données à OSM. Tiens, je suis allé sur leur site : http://www.pss-archi.eu/pss_maps.php?latlng=43.6619110572607, 7.19417005777359z=18 http://www.pss-archi.eu/pss_maps.php?latlng=43.6621633061906850,7.1947547793388370z=16 Aïe, Evil Map ? Et ça ne leur fait pas mal de payer Evil Map pour qu'Evil Map puisse disposer de ces informations ? Ça ne leur fait pas mal d'informer Google des bâtiments les plus intéressants (par pistage des requêtes sur le site) ? Ici lors de ma petite visite sur leur site 68 requêtes Google vers 7 sites Google. Tu ne veux pas leur proposer une switch2osm install party en échange d'une licence ODbl ? ;-). Si tu regardes le site, les bâtiments sont en zone francophone. L'annonce de la publication sur un bulletin hebdomadaire d'OSM Europe (si leur site n'était pas qu'en français) leur ferait une belle promo gratuite. N. B. : avec ma casquette professionnelle je viens de mettre à jour de la doc pour avoir un serveur de tuiles créé en conteneur OpenVZ sur un environnement ProxMox. Je vais passer les mises à jour à faire sur la doc à Thomas G., ce temps je l'ai passé sur mon temps de travail et le message de correctif sera sur mon temps de bénévole. Tout le monde y gagne. Et si PSS veut essayer de monter une pile en s’inspirant de ma doc' (en échange de retours), pas de soucis. Avant qu'on ne me pose la question : je vais sans doute voir auprès de ma hiérarchie si la partie ProxMox/OpenVZ peur
Re: [Talk-br] tag ref
Marcio Leia o que escrevi de novo Voce tava me perguntando sobre algum trechos pequenas por volta do um trevo O resposta e que são no relação Nao disse que nao e para colorau ref nenhuma nas trechos, so disse que não preciso no cada trecho - porque estou no relação. As vezes voce me dar duvida seriou sobre o que eu mesmo escrevendo, as vezes eu usando palavras errados porque Portuguese não e meu idioma natal, mas o palavra cada acho tem mesmo sentido em Portuguese em como usando o tradução desse palavra em meu idioma natal. Também passei 3 links para o wiki (em Ingles) sobre uso do ref=*, uso do relação do route, e relação das rodovias. Não passou os links para mesmos traduzidos porque não sei o qualidade de tradução. On 7/18/15, thunder...@gpsinfo.com.br thunder...@gpsinfo.com.br wrote: Amigos, mais uma vez o Aun e eu estamos discordando em changeset feito por mim ontem a noite após ter identificado a tarde erros em dois trevos da BR-101 ao trafegar do Rio de Janeiro – RJ para Barra de São Francisco – ES, onde me encontro no momento. O erro identificado por mim era, quando do cruzamento, roteamento indevido pelos acessos do trevo e não pela rodovia. Ao chegar em Barra de São Francisco – ES decidi de imediato entrar no OSM para tentar identificar a razão daqueles roteamentos indevidos e de imediato identifiquei que os acessos se encontravam com a classe primary e não _link como recomendado. Identifiquei também que existiam restrições de manobra incorretas impedindo o roteamento pela rodovia em cruzamento do trevo. Durante o desgastante debate entre ele e eu foi por ele citado: “ Todos os rodovias ES e em conforma dados do DER-ES e IJSN, o ref=* estou nas relações e não preciso ser inserido no cada trecho da rodovia.” Quer dizer que o ref, estando na relação rota, não precisa estar na etiqueta ref da via:? Isso é novidade para mim. Onde está isso definido? Marcio ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] tag ref
Voce me perguntou sobre o identificação do rodovia, que estou no relação. Perguntando mesmo coisa como voce, onde disse que preciso ser inserido no cada trecho da rodovia? Nem dizendo isso. O ref estou no relação, que identificando rodovia inteiro. O ref deve ser inserido no trechos do rodovia O ref não e necessário no cada pedaço pequeno do rodovia, por exemplo pontes sobre córregos, cada pequena link no um trevo, etc. On 7/18/15, thunder...@gpsinfo.com.br thunder...@gpsinfo.com.br wrote: Aun, compreendo a sua dificuldade de comunicação em nosso idioma, entretanto foi citado por você: “ Todos os rodovias ES e em conforma dados do DER-ES e IJSN, o ref=* estou nas relações e não preciso ser inserido no cada trecho da rodovia.” Essa sua citação, em especial a de não precisar ser inserida no cada trecho da rodovia foi novidade para mim que edito inserindo sempre o ref na rodovia, mesmo estando ele na relação. Os links por você passados citam que a ref pode ser empregada na relação rota, entretanto isso não significa e tampouco exime do emprego dessa na etiqueta ref da via que no meu entender deve ser priorizada uma vez que os aplicativos extraem essa informação da via e não da relação. Caso esteja somente sendo empregada na relação vamos alterar as configurações do nosso style do Mkgmap. -Mensagem Original- From: Aun Johnsen Sent: Saturday, July 18, 2015 11:27 AM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] tag ref Marcio Leia o que escrevi de novo Voce tava me perguntando sobre algum trechos pequenas por volta do um trevo O resposta e que são no relação Nao disse que nao e para colorau ref nenhuma nas trechos, so disse que não preciso no cada trecho - porque estou no relação. As vezes voce me dar duvida seriou sobre o que eu mesmo escrevendo, as vezes eu usando palavras errados porque Portuguese não e meu idioma natal, mas o palavra cada acho tem mesmo sentido em Portuguese em como usando o tradução desse palavra em meu idioma natal. Também passei 3 links para o wiki (em Ingles) sobre uso do ref=*, uso do relação do route, e relação das rodovias. Não passou os links para mesmos traduzidos porque não sei o qualidade de tradução. On 7/18/15, thunder...@gpsinfo.com.br thunder...@gpsinfo.com.br wrote: Amigos, mais uma vez o Aun e eu estamos discordando em changeset feito por mim ontem a noite após ter identificado a tarde erros em dois trevos da BR-101 ao trafegar do Rio de Janeiro – RJ para Barra de São Francisco – ES, onde me encontro no momento. O erro identificado por mim era, quando do cruzamento, roteamento indevido pelos acessos do trevo e não pela rodovia. Ao chegar em Barra de São Francisco – ES decidi de imediato entrar no OSM para tentar identificar a razão daqueles roteamentos indevidos e de imediato identifiquei que os acessos se encontravam com a classe primary e não _link como recomendado. Identifiquei também que existiam restrições de manobra incorretas impedindo o roteamento pela rodovia em cruzamento do trevo. Durante o desgastante debate entre ele e eu foi por ele citado: “ Todos os rodovias ES e em conforma dados do DER-ES e IJSN, o ref=* estou nas relações e não preciso ser inserido no cada trecho da rodovia.” Quer dizer que o ref, estando na relação rota, não precisa estar na etiqueta ref da via:? Isso é novidade para mim. Onde está isso definido? Marcio ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-at] Import Baumkataster Linz
Bäume reinholen finde ich immer gut. :-) Ist die ID tatsächlich eindeutig? In Wien hat sich herausgestellt, dass diese nur für einen Straßenzug einzigartig ist. Auf jeden Fall kann diese aber bei einem späteren Abgleich nützlich sein, um beispielsweise ein ungenaueres geometrisches Matching zu verfeinern - tree:ref . Siehst du dich mit dem manuellen Überarbeiten des Imports raus? Es sind doch schon einige Bäume drinnen (1645 Stück), von denen sich nach einer schnellen Überprüfung mit einem 5-Meter Puffer ca 257 mit den Linzer Daten überschneiden. (die KML Datei, die genau diese Bäume enthält, ist unter: http://www.gisforge.com/files/doubletrees.kml ) Definitiv machbar, aber ein bisschen Arbeit ... Am 2015-07-17 um 22:45 schrieb Flaimo: Hallo, mittlerweile wurde der Baumkataster Linz in einer, meiner Meinung nach kompatiblen Lizenz, unter http://ckan.data.linz.gv.at/package/baumkataster-2015 bereit gestellt. Ich habe die Daten für JOSM aufgearbeitet: https://www.dropbox.com/s/a1psbxi8c9qpcz3/baumkataster%20linz%202015-07-17.osm?dl=0 Sofern keine Einwände bestehen würde ich die Daten gerne importieren und danach die bereits zuvor erfassten ungenaueren Duplikate per Hand eliminieren. Alle Bäume sind mit denotation=urban als unwichtige Bäume gekennzeichnet und haben die beiden IDs aus der Quelle eingetragen (ref + area_ref) über die man später aktualisierte Daten synchronisieren könnte. Bitte um Feedback von der Community, ob das OK geht, oder ob etwas gegen den Import spricht. flaimo ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-lt] Lietuvos adresai
Sveiki Šiek tiek informacijos apie adresus Lietuvoje, įvedimą, tikrinimą ir kaip/iš kur juos atsisiųsti: http://blog.openmap.lt/2015/07/18/lietuvos-adresai/ -- Tomas ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Merci Jean-Yvon et Jérôme pour vos retour, avec vos arguments et avec l'aide de Christian, notre vénérable président, je vais essayer de les convaincre d'abandonner cette satanée clause NC ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Efficacité d'une requête Overpass (around)
overpass doit faire un choix entre une recherche géographique et une
recherche par tags.
Si on a des tags qui permettent de filtrer suffisamment il est
préférable dans bien des cas de ne pas ajouter de bbox ou area.
line:SNCF étant suffisamment filtrant, on peut à mon avis éviter bbox
et area.
On touche quand même aux limites de l'utilisation de l'overpass pour un
usage live, overpass n'étant pas vraiment prévu pour ce genre d'usages.
Solutions:
- monter une instance overpass locale, avec uniquement les données d'ile
de France... qui sera bien plus rapide qu'une instance monde
- mettre en place un cache ou regénérer à intervalle régulier un fichier
geojson à partir de l'overpass publique...
Le 17/07/2015 10:43, Vincent Génin a écrit :
Merci beaucoup à tous pour vos réponses.
Je pensais vraiment qu'une area bien definie faciliterait la tâche à
Overpass et je n'ai même pas testé sans...
Je vais tenter avec un BBox grossière et sans et voir ce que ça donne.
Pour le tilde, je ne vais pas pouvoir m'en passer si je veux faire un
truc propre, puisque qu'une gare peut desservir plusieurs lignes.
Je vais ajouter et nettoyer un peu les appels pour les services et
équipements (supprimer les acces=private/no ou voir comment avoir qq
chose de plus propre pour les terrains de tennis par exemple).
Merci en tout cas pour vos retours, et je vous tiens au courant de
l'avancée du projet.
Le 17 juil. 2015 02:25, Thierry Bézecourt thie...@thbz.org
mailto:thie...@thbz.org a écrit :
Oui, et on pourrait même supprimer carrément la bounding box car
la condition sur la relation limite les résultats de manière
équivalente (d'ailleurs la ligne C est, sauf erreur, entièrement
en Île-de-France).
De plus, il me semble que le tilde (présente dans le lien sur
Overpass) ralentit la requête.
La requête suivante (http://overpass-turbo.eu/s/atj) dure moins de
10 secondes et devrait être facile à adapter pour d'autres lignes
de RER. Evidemment, il faut faire attention à ne pas mettre une
condition trop large sur la relation...
[out:json];
rel[line:SNCF=C];
node(around:800)[sport=swimming];
out body qt;
rel[line:SNCF=C];
way(around:800)[sport=swimming];
out body center qt;
Thierry
Le 17/07/2015 08:19, Philippe Verdy a écrit :
La délimitation a l'Île-de-France au sens strict construit un
polygone
très complexe. Ce serait peut-être plus rapide avec juste une
bounding
box. Quitte a chercher des picines autour des gares et qu'il
n'y a pas
tant que ca de gares, il suffit juste d'avoir une bounding bix
englobant
les gares. Et après on n'est guère mieux qu'a 1 km près pour
trouver les
piscines mais on n'a pas besoin de la précision fine des
frontieres de
l'Île-de-France... Est-genant si tu as des résultats en
Normandie ou
Picardie ?
Le 16 juil. 2015 16:11, Pierre-Yves Berrard
pierre.yves.berr...@gmail.com
mailto:pierre.yves.berr...@gmail.com
mailto:pierre.yves.berr...@gmail.com
mailto:pierre.yves.berr...@gmail.com a
écrit :
Le 16 juillet 2015 15:09, Vincent Génin
vincent.ge...@gmail.com mailto:vincent.ge...@gmail.com
mailto:vincent.ge...@gmail.com
mailto:vincent.ge...@gmail.com a écrit :
Bonjour à tous,
Désolé si la question est un peu spécifique, mais je
n'ai pas
trouvé de liste pour Overpass.
Pour une utilisation personnelle, je recherchais des
piscines
autour des gares de la ligne C du RER.
J'ai fait quelques tests et utilise cette requête :
http://overpass-turbo.eu/s/asI
{{geocodeArea:Île-de-France}}-.searchArea;
rel[line:SNCF=C](area.searchArea);
node(around:800)[sport=swimming](area.searchArea);
out body qt;
rel[line:SNCF=C](area.searchArea);
way(around:800)[sport=swimming](area.searchArea);
out center qt;
Cependant, elle prend pas mal de temps à s'exécuter
(~60s).
Bonjour,
Il y aurait peut-être à creuser sur la première ligne, en lui
passant directement le numéro de la relation Ile-de-France.
Je n'ai plus en tête la syntaxe exacte : quelque chose du
style
3600 + le numéro de la relation.
Ça éviterait de passer par nominatim (?), mais je ne sais
pas si ça
gagne beaucoup de temps.
PY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
[OSM-ja] 怪しいsourceタグについて
ぞあ.です。 お世話になります。 編集の参考にするためにsourceタグを抜き出してみましたのですが、その中にラ イセンス上、他の媒体への転載が許可されていないと思われるsourceがいくつか ありました。 問題のありそうなデータは修正か削除をしなければならないと思いますが、どん な攻略法がよいでしょうか。 抽出したsourceの一覧は Bitbucket に置いてあります。 特にリストの後半に怪しいものが多かったです。 https://bitbucket.org/zoar/osm-sources-ja/src/6054ed1130ceb920eb849bd9efa36a1a0c7cc170/source_uniq.txt?at=master -- Twitter : @k_zoar Mail : k_z...@k-side.net http://hdyc.neis-one.org/?k_zoar ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Le 18 juillet 2015 15:29, Christian Quest cqu...@openstreetmap.fr a écrit : Il est clair que la licence actuelle de PSS n'est pas compatible avec une intégration de toute ou partie de ces données dans OSM. A chaque fois qu'on parle d'import ou autre, il faut TOUJOURS s'occuper de la partie légale avant de s'attaquer à la technique. ça évite de perdre du temps pour se retrouver coincer au final. Il me semble que ce point a été soulevé relativement tôt à propos de PSS. Oui c'est vrai mais le temps n'a pas été complètement perdu parce que mon programme m'a ensuite permis de faire l'import des immeubles parisiens (avec pas mal de modifications tout de même) à partir des données libres disponibles data.paris.fr. Je suis d'ailleurs en train de le faire fortement évoluer pour pouvoir faire des suppression/ajouts d'immeubles et sous-immeubles (toujours pour l'open data de Paris), je vous en reparlerai dans un autre thread. Autre chose non évaluée... d'où viennent les données de localisation de PSS ? C'est sur un fond Google ou par géocodage que les lat/lon ont été déterminés ? Dans ce cas, PSS ne peut pas les utiliser ailleurs que sur Google Maps et OSM ne peut pas non plus les réutiliser... Hmm c'est un autre point qui pourrait être bloquant effectivement, je vais leur rappeler.. ceci dit c'est pas du tout sûr car pour un nombre important d'immeuble les coordonnées correspondent très mal avec les immeubles visibles sous la vue satellite de GMaps (et d'où le fait que mon import ne pouvait importer que 31k immeubles sur les 43k€ présents dans leur export). Il y a une différence de philosophie importante entre PSS et OSM. Le choix d'une licence CC-by-NC-ND très peu libre et ouverte par rapport à l'ODbL qui limite très peu les usages mais pousse à contribuer. Malheureusement ce n'est pas la première fois qu'on ne peut faire converger un projet de ce type avec OSM sauf à faire comprendre aux contributeurs de ce projet qu'ils font un petit peu fausse route... par exemple en utilisant GMaps d'un côté et donc en autorisant Google à faire ce qu'ils veulent des données PSS (y compris un usage commercial) et de l'autre à ne pas trouver un moyen de collaborer avec OSM... Faire naitre une vraie réflexion côté PSS est à mon avis la meilleure suite. J'espère qu'on l'a fait, maintenant il n'y a plus qu'a attendre... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-de] mangelhafte Namensnennung auf Mapbox-Karten
Hallo, On 17.07.2015 15:32, Martin Koppenhoefer wrote: [...] das fände ich ginge ein bisschen weit, freiwillig kann man die gerne auch noch aufzählen, aber empfehlen oder gar fordern würde ich es nicht. Man könnte auch noch weitergehen und das Betriebssystem sowie alle dort verwendeten tools zitieren, zB. libpng, Merkator als Erfinder der spezifischen Projektion wäre als essentieller Bestandteil vielleicht sogar noch angemessen, den ehemaligen Geographielehrer des Kartenerstellers ginge wiederum etwas weit. Ja das geht natürlich zu weit. Wenn diese Forderung in der Lizenz stehen würde, fände wohl keine große Verbreitung statt. Irgendwo muss es eine Grenze geben, sonst wird es einfach nur lächerlich. Zurück zu den Daten: Bei der Attributierung der Daten hat man sich bei OSM dafür entschieden NaturalEarth nicht zu erwähnen. Gedeckt von der Public Domain Lizenz: No permission is needed to use Natural Earth. Crediting the authors is unnecessary. However, if you wish to cite the map data, simply use one of the following. ...und dann kommen Zitatbeispiele. Man könnte zumindest eine Quelle angeben. Es ist nur nicht gewollt. Die gleiche Situation gibt es mit den Höhenlinien in der Radfahrerkarte und den Schummerungen der Mapquest Open Karte auf osm.org Ich gehe mal von SRTM-Daten aus, die ebenfalls Public Domain sind und deshalb keine Attribuierung notwendig ist. Je nach Quelle des Downloads, z.b. USGS [1], wird vom Anbieter jedoch eine Angabe gefordert. Auf osm.org erfährt man nicht mal das dort andere Quellen außer OSM benutzt wurden. Die Regeln unter [2] sind auch für Viele nicht eindeutig. Setz mal 10 Leute in einen Raum, lass sie die Regeln lesen und eine OSM-Karte attribuieren. Wäre mal interessant was dabei raus kommt. Aber egal, ich bin kein Anwalt und möchte auch gar nicht bis ins letzte Detail alles mit Vorschriften regeln. Ich halte es für richtig, nicht korrekter Attribuierung nachzugehen. Was aber korrekt ist, ist selbst in der OSM-Welt nicht eindeutig. Enorm wichtig finde ich das es überhaupt freie Daten gibt. Viele Grüße Lars [1] https://lta.cr.usgs.gov/citation [2] http://www.openstreetmap.org/copyright ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Import Baumkataster Linz
Der Baumkataster scheint mir von guter Qualitt zu sein. Man muss aber darauf achten, dass Aktualisierungen auch automatisch in die Datenbank (z.b. per Abgleich durch Bot) bernommen werden. Der Baumkataster verzeichnet nur Bume auf ffentlichem Grund. Nach einer kurzen Durchsicht der Karte zeigt sich, dass solche bislang kaum eingetragen sind. Wenn eine Liste dieser 257 Bume erstellt wird, dann wre ein Import samt manuellem Abgleich von Duplikaten kein Problem. MfG, LH Gesendet:Samstag, 18. Juli 2015 um 12:32 Uhr Von:Markus Mayr markus4mayr.li...@gmail.com An:talk-at@openstreetmap.org Betreff:Re: [Talk-at] Import Baumkataster Linz Bume reinholen finde ich immer gut. :-) Ist die ID tatschlich eindeutig? In Wien hat sich herausgestellt, dass diese nur fr einen Straenzug einzigartig ist. Auf jeden Fall kann diese aber bei einem spteren Abgleich ntzlich sein, um beispielsweise ein ungenaueres geometrisches Matching zu verfeinern - tree:ref . Siehst du dich mit dem manuellen berarbeiten des Imports raus? Es sind doch schon einige Bume drinnen (1645 Stck), von denen sich nach einer schnellen berprfung mit einem 5-Meter Puffer ca 257 mit den Linzer Daten berschneiden. (die KML Datei, die genau diese Bume enthlt, ist unter: http://www.gisforge.com/files/doubletrees.kml ) Definitiv machbar, aber ein bisschen Arbeit ... Am 2015-07-17 um 22:45 schrieb Flaimo: Hallo, mittlerweile wurde der Baumkataster Linz in einer, meiner Meinung nach kompatiblen Lizenz, unter http://ckan.data.linz.gv.at/package/baumkataster-2015 bereit gestellt. Ich habe die Daten fr JOSM aufgearbeitet: https://www.dropbox.com/s/a1psbxi8c9qpcz3/baumkataster%20linz%202015-07-17.osm?dl=0 Sofern keine Einwnde bestehen wrde ich die Daten gerne importieren und danach die bereits zuvor erfassten ungenaueren Duplikate per Hand eliminieren. Alle Bume sind mit denotation=urban als unwichtige Bume gekennzeichnet und haben die beiden IDs aus der Quelle eingetragen (ref + area_ref) ber die man spter aktualisierte Daten synchronisieren knnte. Bitte um Feedback von der Community, ob das OK geht, oder ob etwas gegen den Import spricht. flaimo ___Talk-at mailing listTalk-at@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Import Baumkataster Linz
Hallo, bezüglich der Baum-ID habe ich schon im Vorfeld mit dem stets bemühten Stefan Pawel, Projektleiter von Open Commons Linz, Rücksprache gehalten. Es schaut so aus, dass sich die eindeutige Kennung durch die Baumnummer (tree:ref) und der Flächen-ID (tree:ref_area) zusammensetzt. Deswegen habe ich beide Werte einzeln als Tags dranngelassen, weil ich nicht weiß, ob es eine offizielle zusammengesetzte Schreibweise gibt. Manuelle QA von 250 Bäumen halte ich jetzt nicht für so einen großen Aufwand, noch dazu wo vermutlich eh ich selber die meisten Bäume in Linz gemappt habe. flaimo 2015-07-18 12:32 GMT+02:00 Markus Mayr markus4mayr.li...@gmail.com: Bäume reinholen finde ich immer gut. :-) Ist die ID tatsächlich eindeutig? In Wien hat sich herausgestellt, dass diese nur für einen Straßenzug einzigartig ist. Auf jeden Fall kann diese aber bei einem späteren Abgleich nützlich sein, um beispielsweise ein ungenaueres geometrisches Matching zu verfeinern - tree:ref . Siehst du dich mit dem manuellen Überarbeiten des Imports raus? Es sind doch schon einige Bäume drinnen (1645 Stück), von denen sich nach einer schnellen Überprüfung mit einem 5-Meter Puffer ca 257 mit den Linzer Daten überschneiden. (die KML Datei, die genau diese Bäume enthält, ist unter: http://www.gisforge.com/files/doubletrees.kml ) Definitiv machbar, aber ein bisschen Arbeit ... Am 2015-07-17 um 22:45 schrieb Flaimo: Hallo, mittlerweile wurde der Baumkataster Linz in einer, meiner Meinung nach kompatiblen Lizenz, unter http://ckan.data.linz.gv.at/package/baumkataster-2015 bereit gestellt. Ich habe die Daten für JOSM aufgearbeitet: https://www.dropbox.com/s/a1psbxi8c9qpcz3/baumkataster%20linz%202015-07-17.osm?dl=0 Sofern keine Einwände bestehen würde ich die Daten gerne importieren und danach die bereits zuvor erfassten ungenaueren Duplikate per Hand eliminieren. Alle Bäume sind mit denotation=urban als unwichtige Bäume gekennzeichnet und haben die beiden IDs aus der Quelle eingetragen (ref + area_ref) über die man später aktualisierte Daten synchronisieren könnte. Bitte um Feedback von der Community, ob das OK geht, oder ob etwas gegen den Import spricht. flaimo ___ Talk-at mailing listTalk-at@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
Tout à fait d'accord avec la suggestion de porter la discussion sur le wiki. Les listes de diffusion ont peu de mémoire et sont difficiles d'accès. Les pages de discussion du wiki sont l'une des grandes forces de Wikipédia, car on peut y voir de manière organisée les discussions qui ont eu lieu il y a cinq ou dix ans. Thierry Le 18/07/2015 20:13, Jérôme Seigneuret a écrit : / / /Franchement je suis d'accord aussi, mais quoi qu'on du se ici ou dans divers forums, il y aura toujours un utilisateur plus malin qui voudra corriger en étant persuadé qu'il a raison et qui n'aura rien lu de ce qui se passe ici. / Salut, Un moyen sur serait de transférer la discussion sur le wiki d'openstreetmap et d'adjoindre sur les éléments du tracé concernant cette zone de chevauchement un commentaire renvoyant sur cette discussion et une page spécifique à la gestion des frontières. Demander à ne pas manipuler sauf personne compétente de la même manière que les points géodésiques. C'est le wiki qui guide la manière de taguer et de dessiner donc autant que ce soit décrit au bon endroit. La liste de discussion c'est pour affirmer, corriger, ou confirmer des points de vue sur les bonnes pratiques ou des sujets permettant de compléter des informations manquantes de mon point de vue. /Le 18 juillet 2015 11:34, Philippe Verdy verd...@wanadoo.fr mailto:verd...@wanadoo.fr a écrit : / /tous les projets collaboratifs ont des niveaux de privilèges qui s'acquirent avec l'expérience passée sur un projet et des postes pouvant être remis en cause par un processus collectif ou par désistement. Ce n'est pas toujours simple pour gérer les conflits aux niveaux les plus privilégiés, mais un bon moyen de les éviter est d'offrir un système ne restreignant jamais la création de forks ni le nombre de serveurs pour les héberger. Git est un tel système qui évite la concentration des pouvoirs et permet à chaque branche de se développer sans perturber les autres qui préfèrent une autre branche (la notion de trunk est en fait purement locale à un seul des serveurs, les autres serveurs de branche ont chacun leur préférence sur la branche principale à utiliser, il n'y a as plus de mérite pour une branche ou pour une autre quelque soit le nombre des utilisateurs qui les référence, et cela fait aussi disparaitre les notions d'urgence à déployer et la tentation de vouloir effacer ou refuser le travail d'un voisin./ Tu sous-entends qu'OSM à choisi une gestion à la mode de l'armée mexicaine ;-) / (ref : référence à une page de discussion). Je préfère pouvoir compter sur le bons sens que sur l'administration qui peut être corrompue. Et si le comportement d'un utilisatieur pose problème on peut le bloquer. Jean-Yvon (*) au sens informatique, pas au sens associatif./ Tiens ça me rappel le principe de google mapmaker... Tu as beau avoir pris les info sur le terrain et être cartographe, on te votre modification a été refusé car nous n'avons pas le moyen de vérifier ___ 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-br] tag ref
Amigos, mais uma vez o Aun e eu estamos discordando em changeset feito por mim ontem a noite após ter identificado a tarde erros em dois trevos da BR-101 ao trafegar do Rio de Janeiro – RJ para Barra de São Francisco – ES, onde me encontro no momento. O erro identificado por mim era, quando do cruzamento, roteamento indevido pelos acessos do trevo e não pela rodovia. Ao chegar em Barra de São Francisco – ES decidi de imediato entrar no OSM para tentar identificar a razão daqueles roteamentos indevidos e de imediato identifiquei que os acessos se encontravam com a classe primary e não _link como recomendado. Identifiquei também que existiam restrições de manobra incorretas impedindo o roteamento pela rodovia em cruzamento do trevo. Durante o desgastante debate entre ele e eu foi por ele citado: “ Todos os rodovias ES e em conforma dados do DER-ES e IJSN, o ref=* estou nas relações e não preciso ser inserido no cada trecho da rodovia.” Quer dizer que o ref, estando na relação rota, não precisa estar na etiqueta ref da via:? Isso é novidade para mim. Onde está isso definido? Marcio___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
Pour résumé, il y a de nombreuses zones contestées dans le monde. Dans le cas particulier, les deux gouvernements reconnaissent qu'il y a un litige. Ils n'ont pas l'intention de le résoudre. Il n'y a pas un pays qui occupe plus la zone que l'autre. Le cas USA-Canada semble similaire. Je pense qu'il faut trouver un moyen de matérialiser ça dans la base. Par exemple, séparer la frontière en deux et aussi définir une zone spéciale entre les deux avec des tags indiquant que c'est une zone contestée. Je veux bien lancer une discussion sur [tagging] sur comment tagger une zone contestée qui est amenée à le rester ad vitam æternam. Un moyen sur serait de transférer la discussion sur le wiki d'openstreetmap On peut aussi mettre du wiki mais tout le monde ne va pas consulter non plus, loin s'en faut. Et il n'y a pas besoin d’administrateurs sachant qu'il n'y a pas de guerre d'édition et qu'il n'y a pas de raison d'en avoir puisque les gouvernements reconnaissent le désaccord. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-br] tag ref
Explico. Até onde sei a tag surface, quando não definida, é assumido paved pelo sistema e comprovado por mim quando em roteamento por vias pavimentadas. Se é assumido pelo sistema não perco tempo em inserir nas inúmeras vias pavimentadas que tenho desenhado. Agora aponte alguma unpaved não inserida por mim. Para essas me preocupo em inserir porque afetam diretamente o roteamento. A tag ref não afeta o calculo de rota em si, mas facilita a navegação visual porque a sigla da rodovia é estampada na caixa hbox (highway-symbol:hbox) do mapa e ainda aparece nas instruções em texto das manobras quando da navegação GNSS. -Mensagem Original- From: Aun Johnsen Sent: Saturday, July 18, 2015 4:12 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] tag ref Voce dizendo que eu não valorizo as vias desenhado, e que voce valorizando eles tao muito. Me esplica porque eu ainda não vi voce adicionar o tag surface? Desde que viu o importância desse tag por roteamento eu sempre tentando adiciona-lo onde ha dados pra identificar se e pavimentada (surface=paved) ou não pavimentada (surface=unpaved). Se voce olhando, maioria dos ways editado por mim os últimos 6 meses tem algum tag de surface. Eu deu tag ref=* menus prioridade, porque eles vai ser inseridos por projetos que trabalho, e não afetando roteamento. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
Très bien. Le résultat de la discussion méritera tout de même d'être mis quelque part sur le wiki, car c'est l'endroit le plus visible pour la plupart des contributeurs. Et ce serait bien de signaler le lancement de cette discussion sur talk-it (ce que peut sans doute faire celui qui l'a lancée, puisqu'il vient de là-bas). Thierry Le 19/07/2015 04:39, Eric SIBERT a écrit : Pour résumé, il y a de nombreuses zones contestées dans le monde. Dans le cas particulier, les deux gouvernements reconnaissent qu'il y a un litige. Ils n'ont pas l'intention de le résoudre. Il n'y a pas un pays qui occupe plus la zone que l'autre. Le cas USA-Canada semble similaire. Je pense qu'il faut trouver un moyen de matérialiser ça dans la base. Par exemple, séparer la frontière en deux et aussi définir une zone spéciale entre les deux avec des tags indiquant que c'est une zone contestée. Je veux bien lancer une discussion sur [tagging] sur comment tagger une zone contestée qui est amenée à le rester ad vitam æternam. Un moyen sur serait de transférer la discussion sur le wiki d'openstreetmap On peut aussi mettre du wiki mais tout le monde ne va pas consulter non plus, loin s'en faut. Et il n'y a pas besoin d’administrateurs sachant qu'il n'y a pas de guerre d'édition et qu'il n'y a pas de raison d'en avoir puisque les gouvernements reconnaissent le désaccord. Eric ___ 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] Frontière franco-italienne du Mont-Blanc
Le 18 juil. 2015 13:13, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : Tu sous-entends qu'OSM à choisi une gestion à la mode de l'armée mexicaine ;-) Je ne peux pas sous-entendre ca car tout ce que je sais de l'armée mexicaine je l'ai vu avec leurs faucons sur les champs élysées a parus il y a quelques jour ou a l'époque de zorro et des films américains traitant de la guerre entre les deux pays ou des révolutions successives. Comment elle fonctionne et quels rapport elle peut avoir avec les forces de police et les mafias locales du trafic de drogues et d'armes ou les gangs et trafics humains, ou encore avec les migrants clandestin ne me parle pas du tout de ce que faut cette armée aujourd'hui et ce qu'elle représente réellement alors que l'Amérique latine a profondément changé dans ses régimes et les relations internationales qu'ils entretiennent. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
Dès qu'on fait des cartes (avec des villes que l'on nomme (dans quelle langue?), des zonages (de pouvoir...) que l'on trace ), on fait de la politique. Une frontière ça sert à quoi ? C'est avant tout pour savoir si en allant d'un point A à un point B on va changer ou pas de souveraineté administrative (juste histoire d'avoir son visa en règle, ce qui est quand même préférable au cas où la maréchaussée se pointe...). J'ai regardé la carte du Sahara Occidental et c'est bien la position qui semble être retenue par OSM : l'administration de fait (via le Mur des Sables) d'un territoire dessine la frontière. C'est je pense la position la plus apolitique possible (si tant est que ce puisse être possible tant qu'on parle de frontière...) me semble-t-il. D'ailleurs c'est une déclinaison du c'est le terrain qui prime que j'ai entendu à plusieurs reprises dans ces fils de discussion. On reste factuel en actant une situation de fait (car une carte c'est fait pour servir, le lecteur basique d'OSM n'est ni diplomate, ni géographe, ni historien, il veut savoir dans quel pays(i.e. souveraineté administrative) c'est ce qu'il cherche sur la carte). OSM a vocation, je le pense, à répondre à répondre à minima à ce besoin basique et dire dans les fait c'est ici ou là. Pour en revenir au Mont-Blanc. La partie contestée est semble-t-il inhabitée. Sauf mon ignorance, il me semble qu'il n'y a jamais eu d'échauffourés entre l'Italie et la France à ce sujet, avec échanges de coups de feu, mouvement de troupes sur le terrain etc..Donc à priori il semble impossible de trouver une administration de fait (par une administration civile ou une occupation militaire) de la partie concernée. Les revendications de part et d'autres étant non concordantes cela veut dire donc tout simplement que la frontière n'est pas tracée.Les deux points extrémaux de la frontière posant problème devraient être reliés par une ligne en pointillés (comme dans les vieux atlas papiers) indiquant qu'il n'y a pas de tracé de frontière bilatéralement reconnue. Et ça semble le plus logique. Lorsqu'on ne sait pas, OSM doit répondre on ne sait pas Une autre solution qui me semble moins satisfaisante et moins logique, serait de faire passer la frontière d'un pays par la frontière revendiquée par l'autre, et laisser ce qui est reconnu par l'un et pas par l'autre en dehors des deux territoires(zone disputée). Le Vendredi 17 juillet 2015 19h32, Sylvain Maillard sylvain.maill...@gmail.com a écrit : Salut, pour le tracé de la frontière franco-italienne, le CNIG a une page qui liste quelques compte-rendus de réunions, et il y a notamment un document avec les positions des bornes frontières officielles : http://cnig.gouv.fr/?page_id=8653 Les derniers ajustements ont été effectués pour harmoniser les 2 tracés dans le cadre d'INSPIRE. En ce qui concerne le point précis du mont-blanc, on est face à 2 entités politiques légitimes avec chacune un point de vue, et qui sont tous les deux reconnus au niveau international : il est prévu que les 2 tracés figurent dans le bases européennes ! (voir diapo 13 sur http://cnig.gouv.fr/wp-content/uploads/2015/05/2015-10fronti%C3%A8res_GTEI_VF.pdf) Je pense que dans ce cas précis, OSM a plutôt vocation à afficher les 2 tracés ... Du côté l'organisation des secours, il y a des accords internationaux entre la France et l'Italie pour une coopération complète des services de secours qui interviennent sur le secteur ... Sylvain Le 17 juillet 2015 18:19, Florian LAINEZ winner...@free.fr a écrit : Le 17 juillet 2015 17:39, Eric Sibert courr...@eric.sibert.fr a écrit : Ce qui ne semble pas très en accord avec les recommandations de la fondation de n'avoir qu'une frontière. Ça serait plutôt d'avoir une frontière qui coupe la poire en deux (en surface? avec ou sans passage par le sommet?) et tracer à part avec des tags spécifiques les revendications de chaque pays. On ouvrirait ainsi la boite de Pandore, cf. le débat sur le Sahara Occidental. En effet si on commence à prendre en compte les revendications des pays, on fait de la politique. Je ne suis pas contre de manière théorique (donner le point de vue de chacun peut être une bonne chose) mais cela amène de nombreuses complications du type 1. Prends-t-on en compte les revendications uniquement des états ou également des organisations ? 2. Qu'est ce qui définit un état ? le fait qu'il soit reconnu par d'autres ? Mais si tous les autres ne le reconnaissent pas, on met une limite ? Quels critères prendre en compte ? (exemple de l'Ukraine) etc ... Si je ne me trompe pas, le débat sur le Sahara Occidental avait abouti sur la solution de ne pas intégrer la vision Marocaine dans la base OSM mais de leur fournir un serveur pour créer un rendu local intégrant cette donnée. On met le Mont blanc dans nos frontières sur le rendu fr ou ça ressemble à une galère à gérer ? -- FlorianLainez @overflorian
Re: [OSM-talk-fr] Relation Itinéraires vélo
C'est ce qui se passe si 'le format de référence' est insensé, voir ridicule. Il n'y a aucune raison d'ajouter des espaces superflues. De toute façon je suppose que des expressions régulières peuvent aider pour retrouver les 2 formes/formats. Polyglot 2015-07-18 21:15 GMT+02:00 Jérôme Seigneuret jseigneuret-...@yahoo.fr: Il me semble dans le wiki que la question a déjà été posé sur le wiki concernant l'espace sur les int_ref http://wiki.openstreetmap.org/wiki/Key:int_ref *The reference format is E followed by a space followed by up to 3 digits* Il y a pas mal de page à revoir car cet espace n'est pas ajouter dans les descriptions. C'est pénible pour les recherches. Un coup on le met un coup non et dès fois les parties de relations ne suivent pas la même règle. Il y a un MS_BOT pour la correction automatique des références N, A, E, D et C il me semble car la question s'était posé pour les RNx ou R.N x ou R.N.x N x Je pense que les itinéraires de vélo ne doivent pas déroger à la règle. Il faut une normalisation des ref similaires pour garder une cohérence sur la recherche et la lecture. La page ref du wiki présente bien l'espace entre la lettre de départ et la valeur numérique. D'ailleurs, comment les outils de vérification ou d'intégration test cette valeur? ___ 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-br] tag ref
Marcio Eu nao editei os ref=* no cada trecho enquanto tava processando os dados do DER-ES e IJSN, porque ja tava muito trabalho. Eu pode começar inserir os dados ao poucos, e também quando e pronto rodar o script do IJSN_IMPORT vai ser incluído no maioria dos trechos. Eu nao concordo que e necessário ter o ref no cada trecho mesmo pequenos, e nenhuma documentação sobre rodovias, refs, routes, suporta seu opinião. Voce e livre inclui o ref nos trechos onde voce editando. Nao dizendo que e errado inclui o ref no cada trecho, so dizendo que não e necessário, e não vai perder meu sonho se falta. On 7/18/15, thunder...@gpsinfo.com.br thunder...@gpsinfo.com.br wrote: Aun, na minha opinião o ref é necessário em todos os trechos da rodovia, independente de serem pontes ou em pequenos trechos dela divididos. Defendo isso para que a rodovia mantenha em todo o seu percurso configurações semelhantes. Vamos a um exemplo pratico: A rodovia em debate é a ES-291 vista em http://www.openstreetmap.org/way/151561551 A ref desse longo trecho está na relação, mas não está presente em qualquer segmento da rodovia. Isso faz com que o Hbox da ref não seja estampado no mapa OSM e tampouco nos mapas gerados pelos compiladores que conheço. Você se prende a cada segmento da rodovia e eu critico toda a rodovia como pode ser visto no exemplo. Você julga correto isso? -Mensagem Original- From: Aun Johnsen Sent: Saturday, July 18, 2015 12:32 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] tag ref Voce me perguntou sobre o identificação do rodovia, que estou no relação. Perguntando mesmo coisa como voce, onde disse que preciso ser inserido no cada trecho da rodovia? Nem dizendo isso. O ref estou no relação, que identificando rodovia inteiro. O ref deve ser inserido no trechos do rodovia O ref não e necessário no cada pedaço pequeno do rodovia, por exemplo pontes sobre córregos, cada pequena link no um trevo, etc. On 7/18/15, thunder...@gpsinfo.com.br thunder...@gpsinfo.com.br wrote: Aun, compreendo a sua dificuldade de comunicação em nosso idioma, entretanto foi citado por você: “ Todos os rodovias ES e em conforma dados do DER-ES e IJSN, o ref=* estou nas relações e não preciso ser inserido no cada trecho da rodovia.” Essa sua citação, em especial a de não precisar ser inserida no cada trecho da rodovia foi novidade para mim que edito inserindo sempre o ref na rodovia, mesmo estando ele na relação. Os links por você passados citam que a ref pode ser empregada na relação rota, entretanto isso não significa e tampouco exime do emprego dessa na etiqueta ref da via que no meu entender deve ser priorizada uma vez que os aplicativos extraem essa informação da via e não da relação. Caso esteja somente sendo empregada na relação vamos alterar as configurações do nosso style do Mkgmap. -Mensagem Original- From: Aun Johnsen Sent: Saturday, July 18, 2015 11:27 AM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] tag ref Marcio Leia o que escrevi de novo Voce tava me perguntando sobre algum trechos pequenas por volta do um trevo O resposta e que são no relação Nao disse que nao e para colorau ref nenhuma nas trechos, so disse que não preciso no cada trecho - porque estou no relação. As vezes voce me dar duvida seriou sobre o que eu mesmo escrevendo, as vezes eu usando palavras errados porque Portuguese não e meu idioma natal, mas o palavra cada acho tem mesmo sentido em Portuguese em como usando o tradução desse palavra em meu idioma natal. Também passei 3 links para o wiki (em Ingles) sobre uso do ref=*, uso do relação do route, e relação das rodovias. Não passou os links para mesmos traduzidos porque não sei o qualidade de tradução. On 7/18/15, thunder...@gpsinfo.com.br thunder...@gpsinfo.com.br wrote: Amigos, mais uma vez o Aun e eu estamos discordando em changeset feito por mim ontem a noite após ter identificado a tarde erros em dois trevos da BR-101 ao trafegar do Rio de Janeiro – RJ para Barra de São Francisco – ES, onde me encontro no momento. O erro identificado por mim era, quando do cruzamento, roteamento indevido pelos acessos do trevo e não pela rodovia. Ao chegar em Barra de São Francisco – ES decidi de imediato entrar no OSM para tentar identificar a razão daqueles roteamentos indevidos e de imediato identifiquei que os acessos se encontravam com a classe primary e não _link como recomendado. Identifiquei também que existiam restrições de manobra incorretas impedindo o roteamento pela rodovia em cruzamento do trevo. Durante o desgastante debate entre ele e eu foi por ele citado: “ Todos os rodovias ES e em conforma dados do DER-ES e IJSN, o ref=* estou nas relações e não preciso ser inserido no cada trecho da rodovia.” Quer dizer que o ref, estando na relação rota, não precisa estar na etiqueta ref da via:? Isso é novidade para mim. Onde está isso definido? Marcio
Re: [OSM-talk-fr] Relation Itinéraires vélo
Il me semble dans le wiki que la question a déjà été posé sur le wiki concernant l'espace sur les int_ref http://wiki.openstreetmap.org/wiki/Key:int_ref *The reference format is E followed by a space followed by up to 3 digits* Il y a pas mal de page à revoir car cet espace n'est pas ajouter dans les descriptions. C'est pénible pour les recherches. Un coup on le met un coup non et dès fois les parties de relations ne suivent pas la même règle. Il y a un MS_BOT pour la correction automatique des références N, A, E, D et C il me semble car la question s'était posé pour les RNx ou R.N x ou R.N.x N x Je pense que les itinéraires de vélo ne doivent pas déroger à la règle. Il faut une normalisation des ref similaires pour garder une cohérence sur la recherche et la lecture. La page ref du wiki présente bien l'espace entre la lettre de départ et la valeur numérique. D'ailleurs, comment les outils de vérification ou d'intégration test cette valeur? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des données de PSS dans OSM
Le 18/07/2015 16:24, Vincent Frison a écrit : Le 18 juillet 2015 15:29, Christian Quest cqu...@openstreetmap.fr mailto:cqu...@openstreetmap.fr a écrit : Il est clair que la licence actuelle de PSS n'est pas compatible avec une intégration de toute ou partie de ces données dans OSM. A chaque fois qu'on parle d'import ou autre, il faut TOUJOURS s'occuper de la partie légale avant de s'attaquer à la technique. ça évite de perdre du temps pour se retrouver coincer au final. Il me semble que ce point a été soulevé relativement tôt à propos de PSS. Oui c'est vrai mais le temps n'a pas été complètement perdu parce que mon programme m'a ensuite permis de faire l'import des immeubles parisiens (avec pas mal de modifications tout de même) à partir des données libres disponibles data.paris.fr http://data.paris.fr. Je suis d'ailleurs en train de le faire fortement évoluer pour pouvoir faire des suppression/ajouts d'immeubles et sous-immeubles (toujours pour l'open data de Paris), je vous en reparlerai dans un autre thread. Tu as bien fait de ne pas te baser que sur PSS justement, du coup ce que tu as fait sert heureusement pour d'autres sources de données. Autre chose non évaluée... d'où viennent les données de localisation de PSS ? C'est sur un fond Google ou par géocodage que les lat/lon ont été déterminés ? Dans ce cas, PSS ne peut pas les utiliser ailleurs que sur Google Maps et OSM ne peut pas non plus les réutiliser... Hmm c'est un autre point qui pourrait être bloquant effectivement, je vais leur rappeler.. ceci dit c'est pas du tout sûr car pour un nombre important d'immeuble les coordonnées correspondent très mal avec les immeubles visibles sous la vue satellite de GMaps (et d'où le fait que mon import ne pouvait importer que 31k immeubles sur les 43k€ présents dans leur export). Il faut clarifier cette source de localisation (ou ces sources). -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Efficacité d'une requête Overpass (around)
Il faut surtout filtrer et garder les arrêts et non pas faire le traitement
sur l'intégralité du linéaire
Voici la requête sans Nominatim:
[out:json];
area[type=boundary][admin_level=4][name=Île-de-France]- .s;
/* Relation pour le RER C remplacer la lettre du ref par celle de la ligne
*/
rel[network=RER][ref=C](area.s);
/* Récupération des arrêts */
node(r:stop) - .r;
/* Récupération des piscines à 800m des gares */
(node(around.r:800)[sport=swimming];
way(around.r:800)[sport=swimming];);
out center qt;
Pour filter sur le type d'accès, il faut soit le faire après [sport=
swimming]
[network=RER][ref=C] ça marche pour le RER A à D mais pour le
transilien c'est différent
Bon courage
Le 18 juillet 2015 15:19, Christian Quest cqu...@openstreetmap.fr a écrit
:
overpass doit faire un choix entre une recherche géographique et une
recherche par tags.
Si on a des tags qui permettent de filtrer suffisamment il est préférable
dans bien des cas de ne pas ajouter de bbox ou area.
line:SNCF étant suffisamment filtrant, on peut à mon avis éviter bbox et
area.
On touche quand même aux limites de l'utilisation de l'overpass pour un
usage live, overpass n'étant pas vraiment prévu pour ce genre d'usages.
Solutions:
- monter une instance overpass locale, avec uniquement les données d'ile
de France... qui sera bien plus rapide qu'une instance monde
- mettre en place un cache ou regénérer à intervalle régulier un fichier
geojson à partir de l'overpass publique...
Le 17/07/2015 10:43, Vincent Génin a écrit :
Merci beaucoup à tous pour vos réponses.
Je pensais vraiment qu'une area bien definie faciliterait la tâche à
Overpass et je n'ai même pas testé sans...
Je vais tenter avec un BBox grossière et sans et voir ce que ça donne.
Pour le tilde, je ne vais pas pouvoir m'en passer si je veux faire un truc
propre, puisque qu'une gare peut desservir plusieurs lignes.
Je vais ajouter et nettoyer un peu les appels pour les services et
équipements (supprimer les acces=private/no ou voir comment avoir qq chose
de plus propre pour les terrains de tennis par exemple).
Merci en tout cas pour vos retours, et je vous tiens au courant de
l'avancée du projet.
Le 17 juil. 2015 02:25, Thierry Bézecourt thie...@thbz.org a écrit :
Oui, et on pourrait même supprimer carrément la bounding box car la
condition sur la relation limite les résultats de manière équivalente
(d'ailleurs la ligne C est, sauf erreur, entièrement en Île-de-France).
De plus, il me semble que le tilde (présente dans le lien sur Overpass)
ralentit la requête.
La requête suivante (http://overpass-turbo.eu/s/atj) dure moins de 10
secondes et devrait être facile à adapter pour d'autres lignes de RER.
Evidemment, il faut faire attention à ne pas mettre une condition trop
large sur la relation...
[out:json];
rel[line:SNCF=C];
node(around:800)[sport=swimming];
out body qt;
rel[line:SNCF=C];
way(around:800)[sport=swimming];
out body center qt;
Thierry
Le 17/07/2015 08:19, Philippe Verdy a écrit :
La délimitation a l'Île-de-France au sens strict construit un polygone
très complexe. Ce serait peut-être plus rapide avec juste une bounding
box. Quitte a chercher des picines autour des gares et qu'il n'y a pas
tant que ca de gares, il suffit juste d'avoir une bounding bix englobant
les gares. Et après on n'est guère mieux qu'a 1 km près pour trouver les
piscines mais on n'a pas besoin de la précision fine des frontieres de
l'Île-de-France... Est-genant si tu as des résultats en Normandie ou
Picardie ?
Le 16 juil. 2015 16:11, Pierre-Yves Berrard
pierre.yves.berr...@gmail.com mailto:pierre.yves.berr...@gmail.com a
écrit :
Le 16 juillet 2015 15:09, Vincent Génin vincent.ge...@gmail.com
vincent.ge...@gmail.com
mailto:vincent.ge...@gmail.com a écrit :
Bonjour à tous,
Désolé si la question est un peu spécifique, mais je n'ai pas
trouvé de liste pour Overpass.
Pour une utilisation personnelle, je recherchais des piscines
autour des gares de la ligne C du RER.
J'ai fait quelques tests et utilise cette requête :
http://overpass-turbo.eu/s/asI
{{geocodeArea:Île-de-France}}-.searchArea;
rel[line:SNCF=C](area.searchArea);
node(around:800)[sport=swimming](area.searchArea);
out body qt;
rel[line:SNCF=C](area.searchArea);
way(around:800)[sport=swimming](area.searchArea);
out center qt;
Cependant, elle prend pas mal de temps à s'exécuter (~60s).
Bonjour,
Il y aurait peut-être à creuser sur la première ligne, en lui
passant directement le numéro de la relation Ile-de-France.
Je n'ai plus en tête la syntaxe exacte : quelque chose du style
3600 + le numéro de la relation.
Ça éviterait de passer par nominatim (?), mais je ne sais pas si ça
gagne beaucoup de temps.
PY
Re: [Talk-br] tag ref
Voce dizendo que eu não valorizo as vias desenhado, e que voce valorizando eles tao muito. Me esplica porque eu ainda não vi voce adicionar o tag surface? Desde que viu o importância desse tag por roteamento eu sempre tentando adiciona-lo onde ha dados pra identificar se e pavimentada (surface=paved) ou não pavimentada (surface=unpaved). Se voce olhando, maioria dos ways editado por mim os últimos 6 meses tem algum tag de surface. Eu deu tag ref=* menus prioridade, porque eles vai ser inseridos por projetos que trabalho, e não afetando roteamento. On 7/18/15, Aun Johnsen li...@gimnechiske.org wrote: Eu mandei os links em inglês porque muitos desses paginas e desatualizadas em Portuguese, seu exemplo e um deles, provavelmente o pagina não e atualizada desde 2009. To trabalhando com um script para rodar os dados do IJSN, que vai corrigir nome, ref, superfície, lanes, entre outros no estado inteiro. Esse script não e pronto para rodar, ainda tem algum problemas para resolver antes. Eu tentando resolver esse script, realinhar dados desalinhado no região Grande Vitoria, inserir dados para melhorar roteamento, principalmente no região Grande Vitoria, e monitorando atividade no Espírito Santo pra evitar que dados seja quebrados, e voce reclamando que não inserir algum etiquetas do ref=*? Talvez e melhor tira folga do OSM e deixa voce resolver todo isso, porque pelo jeito vai ser resolvida próxima quinzena, ou não? On 7/18/15, thunder...@gpsinfo.com.br thunder...@gpsinfo.com.br wrote: Infelizmente essa é a situação que venho esbarrando constantemente no OSM Brasil, a falta de padrão. Eu defendo o ref em toda rodovia, independente das divisões de segmentos nela inseridos, você defende a inclusão do ref somente na relação rota. Como nenhuma documentação suporta minha opinião posso também dizer que nenhuma suporta a sua. Pela referencia padrão ( http://wiki.openstreetmap.org/wiki/Key:ref ) identificamos que o ref pode ser empregado em pontos, ways, áreas e relações. Já no padrão para o Brasil ( http://wiki.openstreetmap.org/wiki/Pt-br:Key:ref ) foi omitido o emprego dela nas relações. Pelo que identificamos essa rodovia ES-291 foi editada por você há 10 meses atrás e naquela ocasião deixou de inserir a ref nela, situação que permanece até hoje e agora compreendo já que você dá mais valor a relação do que a via desenhada no mapa. Eu já priorizo a via desenhada e em segundo plano a relação rota. Finalmente solicito a você que procure dedicar mais do seu tempo disponível editando e corrigindo erros existentes no mapa que sabemos não são poucos. Tenho perdido muito tempo debatendo com você em cada changeset que faço. Tem até demonstrado que está vigiando todas minhas edições e isso não está sendo saudável a ninguém, tampouco ao OSM. Em vez de ficar me vigiando aproveite esse tempo para corrigir erros como faço. Recentemente tivemos um longo debate em um changeset meu do novo Trevo do Roque em Porto Velho e por fim fui obrigado a solicitar e mostrar a você imagens aéreas atuais extraídas no dia por um helicóptero para comprovar que minha edição estava correta. Perdi um precioso tempo providenciando isso e que poderia muito bem ser empregado corrigindo outros erros do mapa. -Mensagem Original- From: Aun Johnsen Sent: Saturday, July 18, 2015 1:14 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] tag ref Marcio Eu nao editei os ref=* no cada trecho enquanto tava processando os dados do DER-ES e IJSN, porque ja tava muito trabalho. Eu pode começar inserir os dados ao poucos, e também quando e pronto rodar o script do IJSN_IMPORT vai ser incluído no maioria dos trechos. Eu nao concordo que e necessário ter o ref no cada trecho mesmo pequenos, e nenhuma documentação sobre rodovias, refs, routes, suporta seu opinião. Voce e livre inclui o ref nos trechos onde voce editando. Nao dizendo que e errado inclui o ref no cada trecho, so dizendo que não e necessário, e não vai perder meu sonho se falta. On 7/18/15, thunder...@gpsinfo.com.br thunder...@gpsinfo.com.br wrote: Aun, na minha opinião o ref é necessário em todos os trechos da rodovia, independente de serem pontes ou em pequenos trechos dela divididos. Defendo isso para que a rodovia mantenha em todo o seu percurso configurações semelhantes. Vamos a um exemplo pratico: A rodovia em debate é a ES-291 vista em http://www.openstreetmap.org/way/151561551 A ref desse longo trecho está na relação, mas não está presente em qualquer segmento da rodovia. Isso faz com que o Hbox da ref não seja estampado no mapa OSM e tampouco nos mapas gerados pelos compiladores que conheço. Você se prende a cada segmento da rodovia e eu critico toda a rodovia como pode ser visto no exemplo. Você julga correto isso? -Mensagem Original- From: Aun Johnsen Sent: Saturday, July 18, 2015 12:32 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] tag ref Voce me
Re: [OSM-talk-fr] Frontière franco-italienne du Mont-Blanc
Le sujet de la discussion italienne : https://www.mail-archive.com/talk-it@openstreetmap.org/msg46931.htmlAvec l'autre problématique :Le tag:name devrait contenir les deux noms du Mont-Blanc (Monte Bianco) classés par ordre alphabétique. Florian Le Dimanche 19 juillet 2015 0h00, Thierry Bézecourt thie...@thbz.org a écrit : Très bien. Le résultat de la discussion méritera tout de même d'être mis quelque part sur le wiki, car c'est l'endroit le plus visible pour la plupart des contributeurs. Et ce serait bien de signaler le lancement de cette discussion sur talk-it (ce que peut sans doute faire celui qui l'a lancée, puisqu'il vient de là-bas). Thierry Le 19/07/2015 04:39, Eric SIBERT a écrit : Pour résumé, il y a de nombreuses zones contestées dans le monde. Dans le cas particulier, les deux gouvernements reconnaissent qu'il y a un litige. Ils n'ont pas l'intention de le résoudre. Il n'y a pas un pays qui occupe plus la zone que l'autre. Le cas USA-Canada semble similaire. Je pense qu'il faut trouver un moyen de matérialiser ça dans la base. Par exemple, séparer la frontière en deux et aussi définir une zone spéciale entre les deux avec des tags indiquant que c'est une zone contestée. Je veux bien lancer une discussion sur [tagging] sur comment tagger une zone contestée qui est amenée à le rester ad vitam æternam. Un moyen sur serait de transférer la discussion sur le wiki d'openstreetmap On peut aussi mettre du wiki mais tout le monde ne va pas consulter non plus, loin s'en faut. Et il n'y a pas besoin d’administrateurs sachant qu'il n'y a pas de guerre d'édition et qu'il n'y a pas de raison d'en avoir puisque les gouvernements reconnaissent le désaccord. Eric ___ 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] highway=trunk en France
Bonjour, Jérôme Seigneuret wrote J'aurais tendance à dire qu'il ne faut pas simplifier à la voie express. La voie rapide c'est ce qui y a de plus probant même si elle n'est pas à 110 (valeur par défaut). La présence d'un C107 ou pas, on s'en fou. C'est juste un panneaux de rappel précisant les conditions d'accès. Bon j'ai l'impression de tourner en rond en fait là, donc je laisse tomber ça sert à rien de persévérer. Je laisse tel quel, si un jour quelqu'un repasse les chemins en primaire, alors je me contenterais d'ajouter bicycle=no. Merci quand même pour vos réponses, et si un jour ça évolue faites-moi signe. Cordialement. -- View this message in context: http://gis.19327.n5.nabble.com/highway-trunk-en-France-tp5821793p5850477.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-de] mangelhafte Namensnennung auf Mapbox-Karten
sent from a phone Am 18.07.2015 um 16:26 schrieb Lars Lingner gislars+l...@googlemail.com: Zurück zu den Daten: Bei der Attributierung der Daten hat man sich bei OSM dafür entschieden NaturalEarth nicht zu erwähnen. Natural Earth-daten sind soweit ich weiß in den OSM Daten nicht drin. Sie werden zwar im Carto-OSM Stil verwendet, aber der ist nur ein Fork von Andy Allan des alten Mapnik Stils, den er uns freundlicherweise für die Startseite zur Verfügung stellt, und der auf OSMF Ressourcen gerendert und gehostet wird (der einzige derartige Stil auf der Hauptseite). Das ist aber kein offizieller Stil oder so ;-) Jedenfalls ist das freie Software und wird als CC0 veröffentlicht https://github.com/gravitystorm/openstreetmap-carto/blob/master/LICENSE.txt Vielleicht will man die Attribution möglichst kurz halten, und Klarheit für evtl. Forks schaffen (die einfache Forkbarkeit ist ein wichtiges Entwicklungskriterium in diesem Projekt) Ich finde auch, man könnte das hier z.B. ergänzen, wahrscheinlich ist es nur ein Versehen, dass da scheinbar nirgends (Richtung Endnutzer) drauf hingewiesen wird: http://wiki.openstreetmap.org/wiki/Standard_tile_layer Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-ja] 盆栽園のタグについて
三浦です。 盆栽（bonsai)は英語圏でも、十分に「天ぷら」なみに浸透していますね。 盆栽の展示販売、兼鑑賞をおこなう施設で、 絵画における画廊のような施設として認識してました。 盆栽の単価は高額ですので、売上の多くは販売だとおもいますが、 施設の利用者数では、鑑賞のほうが多いでしょう。 観光で訪れることも多い施設です。 種苗店というと、商店街にある花屋さんくらいのイメージを もつことがあります。グリーンセンターというと、ホームセンターの ような規模をかんがえるかもしれません。 盆栽村だと、ホームセンター建物程度の面積に、庭園と建物があり、 盆栽が展示販売されています。 shop=garden_centre に一票です。 加えて、 nursery:bonsai でしょうか 三浦 On 2015年07月18日 17:57, Satoshi IIDA wrote: いいだです。 種苗店の名のとおり販売が主体なら、shop=garden_centre http://wiki.openstreetmap.org/wiki/JA:Tag:shop%3Dgarden_centre 鑑賞が主体なら、leisure=garden http://wiki.openstreetmap.org/wiki/JA:Tag:leisure%3Dgarden +1 2015年7月18日 16:23 tomoya muramoto muramototom...@gmail.com: こんにちは。muramotoです。 私も盆栽園がどういった施設か正確にはわからないのですが、 種苗店の名のとおり販売が主体なら、shop=garden_centre http://wiki.openstreetmap.org/wiki/JA:Tag:shop%3Dgarden_centre 鑑賞が主体なら、leisure=garden http://wiki.openstreetmap.org/wiki/JA:Tag:leisure%3Dgarden ではいかがでしょうか。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 盆栽園のタグについて
ふるた＠Code for SAITAMAです。 みなさんレスありがとうございます。 色々と話が出たところ、三浦さんの説明でほぼ正しいです。一番安いので７００ 円（ほぼ苗）から高いので数千万円まである面白いところでした。７００円でも 育て方しだいでは７万円にも７０万円にもなるという話でした。 種類も松だけでなくいろいろな木々が鉢植えになっていてバリエーションの豊富 さに目を奪われました。興味ない方でも一度遊びにきてください。個人的には、 実のなる木（金柑・姫リンゴ）がすきですが。 さて、タグですが三浦さんの提案通りに加えて補足のタグを合わせる形で shop=garden_centre garden_centre:bonsai がいいと思います。この後、登録した部分を直しておきます。 On Sun, 19 Jul 2015 11:26:53 +0900 Hiroshi Miura(@osmf) miur...@osmf.jp wrote: 三浦です。 盆栽（bonsai)は英語圏でも、十分に「天ぷら」なみに浸透していますね。 盆栽の展示販売、兼鑑賞をおこなう施設で、 絵画における画廊のような施設として認識してました。 盆栽の単価は高額ですので、売上の多くは販売だとおもいますが、 施設の利用者数では、鑑賞のほうが多いでしょう。 観光で訪れることも多い施設です。 種苗店というと、商店街にある花屋さんくらいのイメージを もつことがあります。グリーンセンターというと、ホームセンターの ような規模をかんがえるかもしれません。 盆栽村だと、ホームセンター建物程度の面積に、庭園と建物があり、 盆栽が展示販売されています。 shop=garden_centre に一票です。 加えて、 nursery:bonsai でしょうか 三浦 On 2015年07月18日 17:57, Satoshi IIDA wrote: いいだです。 種苗店の名のとおり販売が主体なら、shop=garden_centre http://wiki.openstreetmap.org/wiki/JA:Tag:shop%3Dgarden_centre 鑑賞が主体なら、leisure=garden http://wiki.openstreetmap.org/wiki/JA:Tag:leisure%3Dgarden +1 2015年7月18日 16:23 tomoya muramoto muramototom...@gmail.com: こんにちは。muramotoです。 私も盆栽園がどういった施設か正確にはわからないのですが、 種苗店の名のとおり販売が主体なら、shop=garden_centre http://wiki.openstreetmap.org/wiki/JA:Tag:shop%3Dgarden_centre 鑑賞が主体なら、leisure=garden http://wiki.openstreetmap.org/wiki/JA:Tag:leisure%3Dgarden ではいかがでしょうか。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja 合同会社 マップクエストソリューションズ （ http://mq-sol.jp/ ） 代表 古田 武士 ( fur...@mq-sol.jp ) 住所： 〒331-0013 埼玉県戸田市喜沢１−３３−８ ベルテラス板橋２０２ 電話： 03-5843-5923 携帯：090-8985-1587 FAX： 048-229-0554 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
