Re: [OSM-talk-fr] un début de OSM - mon commerce

[Cyrille37 OSM via Talk-fr]

Bonjour,

Le 14/12/2020 à 18:13, Yves P. a écrit :

puis-je suggérer d'améliorer les outils existant (par ex OsmMyBiz) au lieu de 
refaire une nouvelle rue depuis zéro ?

Si possible oui.


Je suis un peu dépité quand je renseigne osm a un commerçant de devoir lui 
renseigner 3 roues incomplètes au lieu d'un écosystème intégré.

C'est bien le problème§me, il n'y a rien d'adapté pour la France et de complet 
(par exemple on peut rajouter une entreprise, mais pas mettre à jour les 
informations existantes).


Tout ceci est en accord avec ce que Marc répète, et je le rejoins : 
contribuer aux logiciels existants pour les enrichir plutôt que de créer 
de nouveaux logiciels.


C'est vrai qu'il est souvent plus difficile de commencer à contribuer 
sur un logiciel existant que d'en démarrer un nouveau, mais c'est payant 
sur le long terme, pour les contributeurs et les utilisateurs. Et puis 
ça fait "Bien Commun" au lieu de "Le mien il est mieux" :-)


Cyrille37.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-ja] CC0データのインポート(GTFSデータ)

[Satoshi IIDA]

いいだです。

> 「データ提供元への追加了承は不要ですよね？」という意味での質問
おおっと、失礼しました。
はい、そのとおりで、追加了承は不要です。

> GTFS-JPのマニュアル
紹介いただいたとおり、基本的には地理院地図をベースにしようね、という内容になっているので大きな問題ではないと思っています。
見える化共通入力フォーマットで使われるshape.txtについては
たしかにGoogle Maps由来のようですが、
経路の形状なので、道路のデータをそのままインポート、というよりも、
routeリレーションを作るときの参考にする、くらいにしか使えないのじゃないかな、という気がします。
どちらにしろ、使わないほうがシロにはなりすが。

なお、データセット（つまり事業者さん）がわかれば、
バックヤードでどういうツールを使っているのかは裏とりできる気がしますので、
主に中部地域のデータを参照してよいか迷う場合など、必要あれば声かけください。



2020年12月15日(火) 10:20 OKADA Tsuneo :

> 岡田です。
>
> 下り専門さん、コメントありがとうございます。
> そこまでは思い至りませんでした。
>
> バスのGTFSデータ作成で利用されているツールのいくつかのマニュアルを確認してみました。
>
> まず、バス停の位置(stop.txt)については
>
> 1.見える化共通入力フォーマット
> https://www.rosenzu.com/net/mieru/fm/
> で停留所の位置を地図で指定して入力するツールでは
> 地理院地図を利用しているようです。
>
> 2.西沢ツールでのバス停登録も地理院地図を利用するようです。
> 下記マニュアルのp.36
>
> https://home.csis.u-tokyo.ac.jp/~nishizawa/gtfs/200806gtfsmaker-text-for-v7-61.pdf
>
> 3.「その筋屋」というアプリでも地理院地図を利用しているように見えます。
> 下記マニュアルのpp.7-8の地図デザイン
> http://gtfs-jp.org/gunma2019/gunma-sonosujiya-b.pdf
>
> ということで、これらのツールを使用していれば地理院地図から作っていそうです。
>
> ただshapeファイルについては
> https://www.rosenzu.com/net/mieru/fm/
>
> を見ると、「バス停位置をGooglemapで読み込んで、
> Googlemap上でshapeファイルを作成しましょう」と
> なっているので、これはNGかもしれませんね。
>
> ただこれを言うと、OSMに限らず、Googlemap以外の乗り換え案内サービスに
> 使用することも下記のGoogleマップの規約からNGのように思いますが、
> どうなんでしょうね？？
>
> Google マップ / Google Earth 追加利用規約
> https://www.google.com/intl/ja/help/terms_maps/
> 
> 2.禁止行為
> d.Google マップ / Google Earth を使用して地図関連の別のデータセット（地図やナビゲーションのデータセット、
> ビジネス リスティングのデータベース、メーリング リスト、テレマーケティング リストを含む）を、Google マップ
>  / Google Earth に代わるまたはそれに類似するサービスで使用する目的で作成すること。
> 
>
> ちなみに、航路・フェリー向けのGTFS作成ツールのマニュアルでは
> stop, shapeとも「地理院地図を使って作りましょう」となっていました。
> https://www.mlit.go.jp/maritime/content/001332113.pdf
>
>
>
>
>
>
>
>
> 2020年12月14日(月) 21:51 下り専門 :
>
>> 下り専門です。
>>
>> 念のため、データ提供元に作成方法も問い合わせてみたいですね。
>> Google Maps を参照して作成されていたら使えないですよね。
>>
>> stops.txt だけだったら↓これで変換できるかも。
>> https://github.com/kudarisenmon/gtfs-osm-converter
>>
>>
>> 2020年12月14日(月) 16:23 OKADA Tsuneo :
>> >
>> > 岡田です。
>> >
>> > いいださん、コメントありがとうございます。
>> >
>> > 私の言葉が少し足りていませんでしたが、「データ提供元への追加了承は不要ですよね？」
>> > という意味での質問でした。
>> > いいださんに示していただいたOSM側の手順については認識しておりますので、
>> > 大丈夫です。
>> >
>> > 私の場合インポート用のデータを作成するのが一番大変そうです。。
>> > (QGISを触ってみるところから？)
>> >
>> >
>> > 2020年12月14日(月) 12:25 Satoshi IIDA :
>> >>
>> >> いいだです。
>> >>
>> >> > CC0で公開のデータについてはインポートしても問題ないという認識で良いでしょうか？
>> >> いいえ、残念ながら、ライセンスの互換性だけでは、インポートの作業を行うことはできません。
>> >> インポート作業を行うためには、インポートガイドラインに従い、
>> >> 必要な情報（ライセンス、作業方法、作業責任者の情報など）をまとめた上で、
>> >> その地域ローカル（日本だと、このtalk-jaメーリングリスト）と、
>> >> 全世界のImportsメーリングリストで合意を得る必要があります。
>> >>
>> >> インポートガイドライン:
>> https://wiki.openstreetmap.org/wiki/JA:%E3%82%A4%E3%83%B3%E3%83%9D%E3%83%BC%E3%83%88/%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3
>> >> 書き方の例（位置参照情報）:
>> https://wiki.openstreetmap.org/wiki/MLIT_ISJ/import2019_outline
>> >>
>> >> 先日、MIERUNEさんからQGISでGTFSを読み込むプラグインが公開され、
>> >> OSMで使える形式への変換も楽になってきていると思うので、
>> >> もし進められると嬉しいですね。
>> >> （CC0で追加了承を得る手間が無いのも素晴らしいです！）
>> >>
>> >>
>> >>
>> >> 2020年12月13日(日) 20:49 OKADA Tsuneo :
>> >>>
>> >>> 岡田です。
>> >>>
>> >>> データのインポートについて確認です。
>> >>>
>> >>> バス会社のGTFSデータでいくつか、CC0のライセンスのものがあります。
>> >>> (富山県、山梨県、岡山県などの一部の会社)
>> >>>
>> >>> CC0で公開のデータについてはインポートしても問題ないという認識で良いでしょうか？
>> >>>
>> >>> --
>> >>> 岡田常雄(OKADA Tsuneo)
>> >>> tsuneo.ok...@gmail.com
>> >>> ___
>> >>> 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
>> >
>> >
>> >
>> > --
>> > 岡田常雄(OKADA Tsuneo)
>> > tsuneo.ok...@gmail.com
>> > ___
>> > 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
>>
>
>
> --
> 岡田常雄(OKADA Tsuneo)
> tsuneo.ok...@gmail.com
> ___
> 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] [Tagging] How to put a name tag on an area with more than one type?

[Joseph Eisenberg]

Re:  "why the OSM Foundation has a small budget and can't afford to hire
more than a cursory staff for the most critical needs"

This conversation was on the Tagging list, but I'm responding here to keep
on-topic.

It is worth mentioning that the small size of the OSMF organisation and
budget is considered a positive choice, rather than a handicap, by many
mappers who want OpenStreetMap to stay a volunteer-run, open, independent
community.

OpenStreetMap runs mostly based on volunteer mapper time, plus some
important volunteer time to provide services like functioning data servers,
geocoding and routing apps, and renderings. Only a small amount of money is
needed to keep everything running, and funding from just a part of the
mapper and database user community has been enough for this in the past.

In contrast, Wikimedia has a huge budget and a big organisation, but all
the control and decision-making is done by a small group. The large
expenses require extensive fundraising activities.

Some mappers and perhaps some on the current OSMF board would like to see
lots more funding to make it possible to do things like have more map
styles available, improved editing applications, faster servers, etc. - but
more funding means more fundraising and a bigger organisation and so on.
Once you start that, it's hard to cut off the funding, so there's a big
risk of fundraising suddenly drops off due to a recession or changes in
corporate priorities.

The current "do-ocracy" has disadvantages too, because it tends to
prioritize the interests of people who have the ability to do things on
computers:

Re: "when you speak of "OSM", you are not speaking to some big corporate
entity with a glass lobby, a receptionist, and someone to answer the phone
-- you are speaking to a loose tribe of individual volunteers that are
collaborating on a free map of the world."

And it's that way due to choices that this community has made over time. It
could be different, and might change in the future, based on the choices we
all make.

Personally I see benefits to both models, but the risks are much bigger on
one side.

-- Joseph Eisenberg

On Mon, Dec 14, 2020 at 2:44 PM Brian M. Sperlongano 
wrote:

> I agree with Mateusz that the wiki IS the project's standard document for
> the meaning of tagging (from the perspective of data consumers) and how to
> tag (from the perspective of mappers).  Note that both perspectives are
> important.  But to address the specific point, there is no standard
> document for renderer implementers, because there is no such thing as a
> standard renderer implementation.  A renderer (something that turns data
> into a map) is just one of very many ways to use and visualize geospatial
> data.
>
> I know you did not intend to criticize the volunteers that make this
> project happen, but consider that when you dismiss the wiki as "no
> documentation", it can be interpreted as dismissing the hard work of
> countless people that volunteered their time to develop (and translate!) a
> large and complex documentation base.  Most software developers find
> documentation to be a chore and the last thing they deal with.  That is why
> as someone who has the skills, time, and interest to contribute, I've
> expended considerable effort improving the wiki's tagging documentation,
> and when I've found gaps or problems, I've worked to draft and advance
> proposals to address the deficiencies.  I saw a need and began filling it,
> and my contributions to that documentation are something I am proud of.
>
> For a project that provides its only product for free, it should be
> obvious why the OSM Foundation has a small budget and can't afford to hire
> more than a cursory staff for the most critical needs.  Consider changing
> your perspective to "what am I able to contribute to make this project
> stronger?" rather than "here are the things that are wrong".
>
> As the author of a product that consumes OSM data, I am grateful to all of
> the programmers, mappers, and technologists that have built the various
> pieces of this ecosystem without which my product wouldn't exist.  It would
> be awfully presumptuous of me to complain that this thing provided to me
> entirely for free is in some way lacking, and I'm glad I am able to "give
> back" in this small way.
>
> This is just a gentle reminder that when you speak of "OSM", you are not
> speaking to some big corporate entity with a glass lobby, a receptionist,
> and someone to answer the phone -- you are speaking to a loose tribe of
> individual volunteers that are collaborating on a free map of the world.
>
> On Mon, Dec 14, 2020 at 4:15 PM Mateusz Konieczny via Tagging <
> tagg...@openstreetmap.org> wrote:
>
>>
>>
>>
>> Dec 14, 2020, 22:03 by and...@torger.se:
>>
>> Ok, understood. However as far as I know OSM lacks a standard document
>> for render implementors to actually know how data should be interpreted.
>>
>> In part it is https://wiki.openstreetmap.org/ in part it is 

[talk-au] [Feedback wanted] OpenStreetMap Oceania local chapter

[Edoardo Neerhut]

Hi everyone,

*Tl;dr: *Please help us set a vision and goals for the Oceania
OpenStreetMap local chapter.

*A local chapter is established*
As some of you already know, OSGeo Oceania is now the local chapter for the
OpenStreetMap Foundation in Oceania. We are the first regional local
chapter, with other local chapters operating at a country level. I believe
there is a lot to be gained by working together as a region.

The OSM wiki describes local chapters
 as follows:
*Local Chapters are country-level or region-level not-for-profit legal
entities representing the area's map and mappers when dealing with local
government, business, and media, established with the OpenStreetMap
Foundation (OSMF) , giving
them a link to the legal and copyright governing body.*

This is a good description, but it is still rather broad and it is up to us
as a community to define the specifics. This includes what we want our
local chapter to achieve and how it can support our varied OSM efforts.

*An OpenStreetMap Special Interest Group (OSM SIG)*
For this reason, we have created an OpenStreetMap Special Interest Group
(OSM SIG) that forms part of OSGeo Oceania. This is a group that will meet
periodically to establish some of these goals and hopefully actively work
towards them soon. We've had two meetings thus far and are due for another.
Here are the previous meeting minutes:

   - 2020-07-23
   

   - 2020-08-10
   


Anyone is welcome to join and to take part in the OSM SIG. I propose the
next meeting to take place on January 22nd at 12pm UTC +11. I have added a
meeting to the newly created OSGeo Oceania public calendar
.
Let me know if you have any trouble accessing it and I can send you the
invite.

*OSM SIG charter*
We're working on a charter

that will help define some of these goals. It'll be something we can refer
back to regularly to make sure we're on the right track. It needs a lot of
work and we'd love input from the wider community. Please take a look at it
and make suggestions. The QGIS SIG charter

is further ahead and can provide inspiration.

Really looking forward to seeing input from you all.

Kind regards,

Ed
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[Philippe Verdy]

Le jeu. 26 nov. 2020 à 17:32, Frédéric Rodrigo  a
écrit :

> >> Ça donne 1537 changesets concernant chacun entre 1 et 96 bureaux de
> poste.
> > pq pas si t'as envie... mais un import avec des changeset n'ayant
> > parfois qu'un bureau, cela limite l'intérêt du changeset.
> > perso un changeset pour la france ou un par région, cela me choque
> > pas, ces bureaux n'avaient de toute façon pas d'horaire.
> > mais peu importe ton choix à ce niveau, ce point est pour moi ok,
>
> Même avis ici aussi.
>
> 1 537 changets pour 9 730 objets. Ça fait quand même vraiment beaucoup de
> changesets.


Un simple découpage par les deux premiers chiffres du code postal suffirait
: 100 changesets maxi et ça donne pas tant d'objets que ça par changeset
(au pire ~200 points dans un département densément peuplé et assez grand
avec beaucoup de bureaux, en région parisienne, ou dans le Nord, et en fait
moins dans les départements plus ruraux où il n'y a même pas un bureau par
commune). Ca donne des changeset tout à fait exploitables, faciles à
analyser et de taille raisonnable.

L'autre solution: les importer en triant la liste simplement par code
postal, et faire un changeset par groupe de taille fixe comme 500 codes
(donc 500 noeuds ou polygones), la limite d'OSM étant autour de 2000. On
fera enb sorte de garder les DROM et COM séparés (ils sont très distants
territorialement des autres et entre eux, c'est mieux pour éviter d'irriter
les autres utilisateurs d'OSM hors de France).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import fichier CSV OSM

[Philippe Verdy]

Ce CSV peut cependant être utile à des outils de rapprochement existants,
comme Osmose qui *propose* (mais ne fait pas) de l'intégration. On a le cas
par exemple pour l'intégration des écoles et de toutes sortes
d'équipements, dont de nombreux sont déjà dans OSM, mais ne demandent qu'à
être rapprochés et validés.
De même pour ce sujet des adresses, on a l'intégration BANO: n'est-il pas
plus simple alors de rapprocher ce CSV venant de l'office du tourisme du
fichier produit par la mairie pour la BAN, sachant qu'au final il y aura
rapprochement entre la BAN et BANO pour une intégration OSM ?

Dans ce cas on peut inviter l'office du tourisme à se rapprocher du/des
mairie(s) concernées pour voir comment ils peuvent tous se synchroniser et
"accorder leurs violons", afin que chacun s'enrichisse directement (il faut
savoir que l'intégration d'OSM vers les autres sources est très difficile,
et très long, le guichet d'échange BAN/BANO ne fonctionnant bien que dans
un seul sens, BAN vers BANO et pas l'inverse, même quand on fait les
signalements dans l'outil adhoc créé pour la BANO, il faut des mois ou plus
pour voir les différences disparaître ou pour que celles-ci soient
requalifiées une fois un accord trouvé).

Donc je pense qu'il est plus prudent pour l'office de tourisme de se
rapprocher avec la BAN s'il veut une intégration plus rapide, mais si ça
bloque sur ce point, il peut faire un second rapprochement ensuite avec les
outils BANO (qui affichent déjà les différences BAN/BANO, et permet
justement de trouver ce qui devrait être vérifié en priorité dans les
autres bases à rapprocher. Si l'office de tourisme pense qu'il a de
meilleures données qualifées que la mairie pour la BAN, alors il peut
contribuer directement dans OSM sur ces points particuliers, et il mettra
donc assez vite à jour le rapprochement BAN/BANO vers un peu plus de
convergence.

Mais tout ce processus de convergence est long, il faut être patient et
accepter des marges acceptables de différence correspondant à l'emploi de
chaque base de données: souvent un office de tourime n'a pas besoin par
exemple du même degré de précision spatiale, et il peut communiquer aussi
sur des noms et orthographes proches correspondant à un usage local ou
fréquent ou lié à d'autres langues : OSM a déjà pas mal de champs pour ces
variations de noms, mais rien pour les variations de géométrie, le seul
critère à retenir étant le facteur d'échelle de la carte qu'on veut
réaliser et afficher: un office de rtourisme n'a pas forcément besoin d'un
point très précis pour faire une carte de tout son territoire couvert (à
l'échelle d'une ou plusieurs communes, ou à l'échelle d'un site particulier
avec ses zones de service liées : hôtels, restaus, campings, accès et
réseaux de transport).

En revanche il peut être intéressant pour lui de voir comment mieux
qualifier les tags de nomenclature OSM afin de correspondre aux usages,
notamment pour les recherches thématiques. OSM est riche sur ce point, mais
il peut y avoir des surprises : les outils de recherche par tag d'OSM
permettent de faire le point de ce qui manque ou serait en trop (et aussi
des outils comme UMap qui peuvent faire cette recherche et l'afficher à la
fois sur une carte et dans un tableau de données, qu'on peut alors exporter
facilement pour le comparer à un autre fichier externe). Qui sait, vous y
trouverez sans doutes des points et données dont vouxd n'aviez pas idée ou
que vous avez oubliés aussi: une petite enqupête de votre côté et vous
pouvez les valider dans vos fichiers et les faire remonter et rapprocher
avec d'autres bases.

Tout ceci participe d'un échange participatif où chaque acteur peut
travailler et contribuer. Au final cela vise à la convergence, mais on
n'aura jamais une convergence absolue, automatique et instantanée (même
pour ds données dites "réglementaires" et supposées à déclaration
obligatoire, car il y a aussi des délais légaux pour le faire et des délais
de rectification) car tout finit par changer un jour et tout le monde ne
sera pas au courant en même temps ni n'aura encore pu vérifier de son côté.
Il est donc important dans toute base de garder un suivi daté des
modifications afin de savoir ce qui a été validé et quand et estimer la
fraicheur relative de ce qui est présent dans une base : cela permet aussi
de planifier et étaler dans le temps les travaux de revérification et
correction sans avoir tout à faire tout de suite et être pris à agir dans
l'urgence (ce qui peut demander un travail énorme et de gros moyens humains
et en temps dont chacun ne dispose pas).



Le ven. 27 nov. 2020 à 12:42, Marc_marc  a écrit :

> Bonjour,
>
> Le 27.11.20 à 10:26, Maïtena HARISTOUY a écrit :
> > Dans le cadre de mon activité professionnelle au sein de l'OT Pays
> > Basque, je fais partie des contributeurs OSM et je me demande s'il est
> > possible d'importer un fichier CSV dans OSM afin de mettre à jour OSM.
>
> les imports suivent une procédure très carré
> 

Re: [OSM-ja] CC0データのインポート(GTFSデータ)

[OKADA Tsuneo]

岡田です。

下り専門さん、コメントありがとうございます。
そこまでは思い至りませんでした。

バスのGTFSデータ作成で利用されているツールのいくつかのマニュアルを確認してみました。

まず、バス停の位置(stop.txt)については

1.見える化共通入力フォーマット
https://www.rosenzu.com/net/mieru/fm/
で停留所の位置を地図で指定して入力するツールでは
地理院地図を利用しているようです。

2.西沢ツールでのバス停登録も地理院地図を利用するようです。
下記マニュアルのp.36
https://home.csis.u-tokyo.ac.jp/~nishizawa/gtfs/200806gtfsmaker-text-for-v7-61.pdf

3.「その筋屋」というアプリでも地理院地図を利用しているように見えます。
下記マニュアルのpp.7-8の地図デザイン
http://gtfs-jp.org/gunma2019/gunma-sonosujiya-b.pdf

ということで、これらのツールを使用していれば地理院地図から作っていそうです。

ただshapeファイルについては
https://www.rosenzu.com/net/mieru/fm/

を見ると、「バス停位置をGooglemapで読み込んで、
Googlemap上でshapeファイルを作成しましょう」と
なっているので、これはNGかもしれませんね。

ただこれを言うと、OSMに限らず、Googlemap以外の乗り換え案内サービスに
使用することも下記のGoogleマップの規約からNGのように思いますが、
どうなんでしょうね？？

Google マップ / Google Earth 追加利用規約
https://www.google.com/intl/ja/help/terms_maps/

2.禁止行為
d.Google マップ / Google Earth を使用して地図関連の別のデータセット（地図やナビゲーションのデータセット、
ビジネス リスティングのデータベース、メーリング リスト、テレマーケティング リストを含む）を、Google マップ
 / Google Earth に代わるまたはそれに類似するサービスで使用する目的で作成すること。


ちなみに、航路・フェリー向けのGTFS作成ツールのマニュアルでは
stop, shapeとも「地理院地図を使って作りましょう」となっていました。
https://www.mlit.go.jp/maritime/content/001332113.pdf








2020年12月14日(月) 21:51 下り専門 :

> 下り専門です。
>
> 念のため、データ提供元に作成方法も問い合わせてみたいですね。
> Google Maps を参照して作成されていたら使えないですよね。
>
> stops.txt だけだったら↓これで変換できるかも。
> https://github.com/kudarisenmon/gtfs-osm-converter
>
>
> 2020年12月14日(月) 16:23 OKADA Tsuneo :
> >
> > 岡田です。
> >
> > いいださん、コメントありがとうございます。
> >
> > 私の言葉が少し足りていませんでしたが、「データ提供元への追加了承は不要ですよね？」
> > という意味での質問でした。
> > いいださんに示していただいたOSM側の手順については認識しておりますので、
> > 大丈夫です。
> >
> > 私の場合インポート用のデータを作成するのが一番大変そうです。。
> > (QGISを触ってみるところから？)
> >
> >
> > 2020年12月14日(月) 12:25 Satoshi IIDA :
> >>
> >> いいだです。
> >>
> >> > CC0で公開のデータについてはインポートしても問題ないという認識で良いでしょうか？
> >> いいえ、残念ながら、ライセンスの互換性だけでは、インポートの作業を行うことはできません。
> >> インポート作業を行うためには、インポートガイドラインに従い、
> >> 必要な情報（ライセンス、作業方法、作業責任者の情報など）をまとめた上で、
> >> その地域ローカル（日本だと、このtalk-jaメーリングリスト）と、
> >> 全世界のImportsメーリングリストで合意を得る必要があります。
> >>
> >> インポートガイドライン:
> https://wiki.openstreetmap.org/wiki/JA:%E3%82%A4%E3%83%B3%E3%83%9D%E3%83%BC%E3%83%88/%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3
> >> 書き方の例（位置参照情報）:
> https://wiki.openstreetmap.org/wiki/MLIT_ISJ/import2019_outline
> >>
> >> 先日、MIERUNEさんからQGISでGTFSを読み込むプラグインが公開され、
> >> OSMで使える形式への変換も楽になってきていると思うので、
> >> もし進められると嬉しいですね。
> >> （CC0で追加了承を得る手間が無いのも素晴らしいです！）
> >>
> >>
> >>
> >> 2020年12月13日(日) 20:49 OKADA Tsuneo :
> >>>
> >>> 岡田です。
> >>>
> >>> データのインポートについて確認です。
> >>>
> >>> バス会社のGTFSデータでいくつか、CC0のライセンスのものがあります。
> >>> (富山県、山梨県、岡山県などの一部の会社)
> >>>
> >>> CC0で公開のデータについてはインポートしても問題ないという認識で良いでしょうか？
> >>>
> >>> --
> >>> 岡田常雄(OKADA Tsuneo)
> >>> tsuneo.ok...@gmail.com
> >>> ___
> >>> 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
> >
> >
> >
> > --
> > 岡田常雄(OKADA Tsuneo)
> > tsuneo.ok...@gmail.com
> > ___
> > 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
>


-- 
岡田常雄(OKADA Tsuneo)
tsuneo.ok...@gmail.com
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [talk-latam] cómo establecer un contact —estable— con YMUP?

[Mario Frasca]

Dear Rory, you wrote on HOT task 9844:

From my understanding they made efforts to engage you and ask for your 
help. Further, I believe the YouthMappers chapter in Panama responded 
to you and shared with you the OSM Wiki pages (per the OEG guidelines) 
they had created for these tasks on another OSM channel
While we don't provide links, we're leaving space for misunderstanding, 
so instead of misunderstanding you, let me tell you I simply do not 
understand what you're talking about, would you mind providing some 
detail?  I'm not aware of (recent) efforts to get in contact and 
definitely of any effort at all for staying in contact.  I do not even 
know who's the new president of the chapter, let alone the members, or 
their plans.


the DWG blocked some of their accounts, and in the text of the message 
they received there was this part:


The most important bit here is that every single member of your team 
is recognizable as being in our team (e.g. by writing something on the 
user profile page) and that the team leadership is reachable for us.
The page they created does not contain a list of their members, and none 
of the persons who's read the message has complied with this request.


as said, we don't know who's at the leadership.

so, no, I don't believe the YouthMappers chapter in Panama responded to 
either me nor the DWG.


best regards,

Mario Frasca

the complete text of the lock message follows (containing still open 
questions):



Dear Youth Mappers at Panama University,

recently, a number of complaints have been raised against your work in 
OpenStreetMap. Here are some of them:


https://resultmaps.neis-one.org/osm-discussion-comments?uid=12196736 

https://resultmaps.neis-one.org/osm-discussion-comments?uid=4366434 

https://resultmaps.neis-one.org/osm-discussion-comments?uid=4366436 

https://resultmaps.neis-one.org/osm-discussion-comments?uid=4928257 



We’re always happy if new poeple join OSM, but if you train students 
to contribute to OSM, you have a responsibility to monitor the quality 
and ensure that if other mappers raise complaints, these complaints 
are heard and acted upon.


In your future work in OSM, please observe the organised editing 
guidelines outlined here:


https://wiki.osmfoundation.org/wiki/Organised_Editing_Guidelines 



The most important bit here is that every single member of your team 
is recognizable as being in our team (e.g. by writing something on the 
user profile page) and that the team leadership is reachable for us.


The guidelines also require that you document your mapping efforts. 
One user has done this for you in his diary entry:


https://www.openstreetmap.org/user/mariotomo/diary/395025 



But this is not a job that the community should be doing for you - it 
is you whou should be providing this documentation.


Please, in your future OSM projects, ensure that students receive 
proper training and follow the organised editing guidelines.


It is not a big deal if someone makes a mistake - we all make 
mistakes. But, since you are introducing new people to OSM every year, 
you really need to make it a part of that introduction to explain to 
students that they need to work together with the existing OSM 
community, and that they don’t exist in an empty space.


I am writing this as a block message to all accounts that are 
currently involved hoping that it finally reaches someone who is 
responsible, as the individual accounts do not list a contact address, 
have not reacted to changeset comments, and emails from OSM mappers to 
i...@youthmappers.org  have been without 
response.


Please ignore this message and accept my apologies if you are not 
involved with the group.


Thank you for your understanding Frederik Ramm OSMF Data Workin Group 
Ticket#202012071024



On 14/12/2020 08:48, Mario Frasca wrote:

queridos jóvenes mapeadores de la universidad de Panamá,

estoy comentando unas ediciones que están entrando en vuestras áreas 
de interés, ejecutadas en forma de revisión de los datos brutos, sea 
insertados durante vuestros "mapathon", sea llegando gracias a los 
proyectos que siguen abiertos y siguen atrayendo principiantes.


en particular Marianne_pty me responde 
(https://www.openstreetmap.org/changeset/95350683), y me pide que no 
le dé comentarios generales.


pero, cuál canal tenemos abierto, para los comentarios generales?

intento vuestro correo e involucro la lista regional.

en el caso de Colón, los YMUP han escojido un lugar en que se está 
tumbando y reconstruyendo. las fotos están —todas 

Re: [Talk-GB] Removing all stiles from bridleways

[Andy Mabbett]

On Mon, 14 Dec 2020 at 20:57, ael via Talk-GB  wrote:

> I would regard this as vandalism if it is removing surveyed real stiles
> to suit an ideal world where they are not permitted on bridleways.

I favour the definitions used on the English Wikipedia, which make it
clear that vandalism is deliberate harm, and that any well-intentioned
edit, even if incorrect, is not vandalism, because:

If an editor treats situations which are not clearly vandalism as such, it
may harm the encyclopedia by alienating or driving away potential editors.

https://en.wikipedia.org/wiki/Wikipedia:Vandalism#What_is_not_vandalism

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Talk-GB Digest, Vol 171, Issue 52

[Neil Matthews]

Apologies, I assumed this was a ongoing project that started last month, 
c.f. https://www.openstreetmap.org/changeset/94154740#map=8/51.900/-1.599


I'm definitely not keen on seeing welly-boot mapping remapped by 
armchair mappers -- there are too many real-world issues that don't map 
easily (sorry!) to more abstract ontologies.


I do think it would be great quarterly project (if the stile's wrong -- 
a lot else might be too).


And if this is a key issue for you, then perhaps asking OSM editor 
developers to give a gentle warning for "stile" on "bridleway" might be 
a great idea -- and help reduce inadvertant problems. -- and stop them 
coming back.

(I think "block" should be ok though -- probably just there to stop cars)

Cheers,
Neil

P.S. I only raised it on talk-gb as it covered a large area -- I have no 
problem reverting smaller changesets in my locality that are incorrect.



From: Richard Fairhurst 
To: "talk-gb OSM List (E-mail)" 
Subject: Re: [Talk-GB] Removing all stiles from bridleways

Neil Matthews wrote:

  Looks like there's been an attempt to remove all stiles from
bridleways

Um, no there hasn't?

The changeset you've pointed to (which is one of mine) has a single stile moved 
to the side of a bridleway. I've done this a handful of times in the past, too, 
usually where the stile is clearly misplaced at a footpath/bridleway junction 
node rather than off to the side on a footpath, but occasionally at an isolated 
bridleway location like this.

A barrier=stile on a long-established UK bridleway is 99.9% a mapping error. 
Bridleways are open to horses and bikes, and so stiles are forbidden - PRoW 
officers are pretty hot on this. You will sometimes see a stile placed to the 
side of a gate: in OSM this is usually mapped as a highway=footway through the 
stile and highway=bridleway through the gate, though of course there's no 
distinct public footpath PRoW in this case.

OSM is an iterative process of fixup and improvement, and shouting "mechanical edit!" 
every time someone makes a change that hasn't been surveyed in walking boots and then manually 
etched onto the hard disc platters of a server somewhere in Amsterdam is not hugely helpful. I 
mean, just change it back and say "put back pending survey" if you feel that strongly, it 
doesn't need an entire mailing list thread.

Richard
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openstreetmap.org/pipermail/talk-gb/attachments/20201214/1e3ca890/attachment-0001.htm>

--



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [talk-cz] Moderní komunikační kanál?

[Pavel Dobes]

Ahoj,

misto Slacku se u nas pouzival Mattermost (https://mattermost.com/). Tech
alternativ, pokud clovek neche slack bude vic.

PaD

ne 6. 12. 2020 v 22:38 odesílatel Jan Macura  napsal:

> Ahoj
>
> On Sat, 5 Dec 2020 at 17:23, Jirka Sedláček  wrote:
>
>> Ale discord mi přijde jako totální peklo, za mě by vyhovoval Slack – jen
>> tam je ta free podmínka, kterou zmiňoval Marián. Uchovává se tuším jen
>> 1 posledních zpráv - a to je pekelně málo. Dalo by se to asi hacknout
>> přes nějakej na to napojenej archivátor, ale … ale proč.
>>
>
> Jen tak na okraj, když už se tu ten Slack skloňuje, existuje jeho solidní
> open source alternativa jménem Rocket Chat . Just
> sayin', kdyby tomu chtěl někdo věnovat čas a zkoušet to.
>
> H.
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-GB] Removing all stiles from bridleways

[Chris Hodges]

I've also had an electric fence across a bridleway, and some very grumpy 
cows the other side of it. Luckily the farmer appeared and was very 
happy to let me through or it would have been retracing 3km of grassy 
riding on a touring bike.


I'm rather prone to bike-hiking, even if not keen on it, so see the 
benefit of a correct "bicycle=yes" - and I'll try to fill in the 
tracktype, surface, and sometimes (rather subjective) bike difficulty 
when I get home.  After Saturday's ride one bridleway should have been 
tagged "surface=water"


As for comfy Cotswolds - I'm not far from there, so I know you get 
things like locked gates wrapped in barbed wire on bridleways, within 
the boundaries of the changeset that prompted this



On 14/12/2020 21:51, Andy Townsend wrote:

On 14/12/2020 20:57, Richard Fairhurst wrote:
A barrier=stile on a long-established UK bridleway is 99.9% a mapping 
error. Bridleways are open to horses and bikes, and so stiles are 
forbidden - PRoW officers are pretty hot on this.


That may be the case in the comfy Cotswolds but I'm not sure that 
necessarily the case everywhere else in the country. :)


Actual steps on bridleways are common enough that I had to add a 
rendering for them at map.atownsend.org.uk (see 
https://map.atownsend.org.uk/maps/map/map.html#zoom=19=54.417701=-0.525549 
).  I might have recently mentioned 
https://map.atownsend.org.uk/maps/map/map.html#zoom=21=54.0087259=-1.0201263 
(a bridleway with an electric fence across it) on this list as well.


There are plenty of signed bridleways where horse access might be 
difficult for other reasons:  I set horse_scale=demanding on 
https://www.openstreetmap.org/way/762748920 , but on balance it should 
perhaps be a higher value due to the difficulty in negotiating the 
descent.  A subsequent mapper added bicycle=yes there - that's 
entirely correct, but the depth of the mud and the thickness of the 
trees would would be a challenge to even the keenest MTBer.


With regard to this alleged stile, the previous tagging and location 
would suggest to me a barrier=horse_stile (mentioned earlier in the 
thread) on the bridleway rather than a barrier=stile off it, but so 
much here needs remapping or at the very least rechecking (the stream 
differs greatly from the imagery, at least one of the bridleways looks 
like a track to me, no designation tags) that personally I'd just 
stick it in the "needs survey" bucket.


Best Regards,

Andy



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb




___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Removing all stiles from bridleways

[Andy Townsend]

On 14/12/2020 20:57, Richard Fairhurst wrote:
A barrier=stile on a long-established UK bridleway is 99.9% a mapping 
error. Bridleways are open to horses and bikes, and so stiles are 
forbidden - PRoW officers are pretty hot on this.


That may be the case in the comfy Cotswolds but I'm not sure that 
necessarily the case everywhere else in the country. :)


Actual steps on bridleways are common enough that I had to add a 
rendering for them at map.atownsend.org.uk (see 
https://map.atownsend.org.uk/maps/map/map.html#zoom=19=54.417701=-0.525549 
).  I might have recently mentioned 
https://map.atownsend.org.uk/maps/map/map.html#zoom=21=54.0087259=-1.0201263 
(a bridleway with an electric fence across it) on this list as well.


There are plenty of signed bridleways where horse access might be 
difficult for other reasons:  I set horse_scale=demanding on 
https://www.openstreetmap.org/way/762748920 , but on balance it should 
perhaps be a higher value due to the difficulty in negotiating the 
descent.  A subsequent mapper added bicycle=yes there - that's entirely 
correct, but the depth of the mud and the thickness of the trees would 
would be a challenge to even the keenest MTBer.


With regard to this alleged stile, the previous tagging and location 
would suggest to me a barrier=horse_stile (mentioned earlier in the 
thread) on the bridleway rather than a barrier=stile off it, but so much 
here needs remapping or at the very least rechecking (the stream differs 
greatly from the imagery, at least one of the bridleways looks like a 
track to me, no designation tags) that personally I'd just stick it in 
the "needs survey" bucket.


Best Regards,

Andy


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Removing all stiles from bridleways

[Edward Catmur via Talk-GB]

On Mon, 14 Dec 2020, 20:58 ael via Talk-GB, 
wrote:

> On Mon, Dec 14, 2020 at 08:30:01PM +, Neil Matthews wrote:
> > Looks like there's been an attempt to remove all stiles from bridleways
> --
> > pretty sure I've seen this done in other edits -- agree that they're a
> > potential anomaly but should they really be a mechanical edit (even if by
> > hand)? See https://www.openstreetmap.org/changeset/95739504
> > https://lists.openstreetmap.org/listinfo/talk-gb
>
> I would regard this as vandalism if it is removing surveyed real stiles
> to suit an ideal world where they are not permitted on bridleways.
>
> Perhaps I have misunderstood?
>

My understanding is that the stiles in question were mapped as a tag on a
bridleway / footway junction, and have been moved to a node on the footway.
This is highly likely to be to be correct, since a (foot) stile is a
construction at the point where a path crosses a fence and so topologically
cannot occur at a junction.

I would generally feel OK doing this without a ground survey if it was
reasonably clear that there is a fence paralleling the bridleway, and that
the footpath is crossing. This might be visible on aerial photography where
the bridleway runs in the gap between two fields, for example.

>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Removing all stiles from bridleways

[Richard Fairhurst]

Neil Matthews wrote:
> Looks like there's been an attempt to remove all stiles from
> bridleways

Um, no there hasn't?

The changeset you've pointed to (which is one of mine) has a single stile moved 
to the side of a bridleway. I've done this a handful of times in the past, too, 
usually where the stile is clearly misplaced at a footpath/bridleway junction 
node rather than off to the side on a footpath, but occasionally at an isolated 
bridleway location like this.

A barrier=stile on a long-established UK bridleway is 99.9% a mapping error. 
Bridleways are open to horses and bikes, and so stiles are forbidden - PRoW 
officers are pretty hot on this. You will sometimes see a stile placed to the 
side of a gate: in OSM this is usually mapped as a highway=footway through the 
stile and highway=bridleway through the gate, though of course there's no 
distinct public footpath PRoW in this case.

OSM is an iterative process of fixup and improvement, and shouting "mechanical 
edit!" every time someone makes a change that hasn't been surveyed in walking 
boots and then manually etched onto the hard disc platters of a server 
somewhere in Amsterdam is not hugely helpful. I mean, just change it back and 
say "put back pending survey" if you feel that strongly, it doesn't need an 
entire mailing list thread.

Richard
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Removing all stiles from bridleways

[ael via Talk-GB]

On Mon, Dec 14, 2020 at 08:30:01PM +, Neil Matthews wrote:
> Looks like there's been an attempt to remove all stiles from bridleways --
> pretty sure I've seen this done in other edits -- agree that they're a
> potential anomaly but should they really be a mechanical edit (even if by
> hand)? See https://www.openstreetmap.org/changeset/95739504
> https://lists.openstreetmap.org/listinfo/talk-gb

I would regard this as vandalism if it is removing surveyed real stiles
to suit an ideal world where they are not permitted on bridleways.

Perhaps I have misunderstood?

ael

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Removing all stiles from bridleways

[Jon Pennycook]

I have seen at least one bridleway with a stile (not a horse stile).
Bridleways that were recently upgraded from public footpaths may still have
old barriers. Just because there is a right of way, it doesn't mean that
it's fully accessible (e.g a BOAT near Alton that has steps at one end).

Jon

On Mon, 14 Dec 2020, 20:31 Neil Matthews, 
wrote:

> Looks like there's been an attempt to remove all stiles from bridleways
> -- pretty sure I've seen this done in other edits -- agree that they're
> a potential anomaly but should they really be a mechanical edit (even if
> by hand)? See https://www.openstreetmap.org/changeset/95739504
>
> Cheers,
> Neil
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Tagging bike ramp/ bike path down steps

[Edward Bainton]

>  I recall some means of tagging a step-over gate on a bridleway
but can't remember or instantly find the tag.

barrier=horse_stile

On Mon, 14 Dec 2020 at 19:48, Chris Hodges  wrote:

> Accessibility tagging for bike routes would be great, and mean a lot of
> work on the ground. Things like gate/bollard widths would be good, and
> some of the stuff to keep motorbikes out - though some at least can be
> tagged; I recall some means of tagging a step-over gate on a bridleway
> but can't remember or instantly find the tag.  Some would be a bit
> subjective (especially where length and width are constrained), but
> something comparably coarse to wheelchair=limited would be a start
>
> Despite riding a normal (except for being huge and laden with
> accessories) bike, and being able to lift it, accessibility of bike
> infrastructure is an area of particular interest for me.  I actually
> went for a child seat instead of a trailer because of the
> restrictiveness of some of the bike paths round here.
>
> "Dismount" seems like by far the best tag if your average commuter
> cyclist or even a skilled roadie couldn't ride it - and some of the
> examples I've seen would put off most hardcore mountain bikers, while
> steps have been OK on my hybrid (each step longer than the bike, drops
> small).
>
>
> On 14/12/2020 17:27, Simon Still wrote:
> > I’d agree with your approach and I’ve raised this before, but haven’t
> > had the time to come back to it.
> >
> > From a routing perspective it would be useful to be able to tag
> > ACCESSIBILITY  - ie sections of route that are unsuitable for some
> > users - not related to the legality but so that disabled cyclists
> > (unable to dismount), those using trailers  or trikes or other
> > non-standard cycles could specify a route that avoided sections where
> > they could not ride.
> >
> > Yes, I think bicycle dismount is correct tagging in this case not
> > because of the legality but because of the steps.  If the bridge was
> > had a ramp, or there was a subway, and it *could* be ridden across
> > (even if there was a cyclist dismount sign) then I think tagging the
> > dismount would be wrong.
> >
> >
> >
> >> On 14 Dec 2020, at 17:19, Michael Collinson  >> > wrote:
> >>
> >> FYI, here's the schema I personally use in Sweden, where heavy use is
> >> made of ramped staircases, though not thankfully on major cycle
> >> routes. My objective is to allow routers to intelligently route for
> >> both sport/club/large group riding and happy meandering or commute:
> >>
> >> bicycle=yes only on very shallow low incline steps where it is is
> >> safe and practical to cycle an ordinary bike - not common but does
> >> happen. Sometimes on shallow slopes a gravelled or informal path to
> >> one side also exists.
> >>
> >> where there is a ramp:
> >> ramp=yes
> >> bicycle=dismount   (here I am tagging on practicality rather than
> >> legalities, Sweden is much more relaxed than UK)
> >> ramp:stroller=yes   where it is a double ramp, (a forgotten transport
> >> demographic)
> >>
> >> on short or low-incline flights of steps where an alternate route
> >> would be much longer:
> >> bicycle=carry (informal/experimental)
> >>
> >> I also strongly encourage step_count=x as that gives a bicycle router
> >> more quantitative input on whether to route or avoid.
> >>
> >> And lastly from unnerving Spanish experience, some sort of hazard
> >> tagging at the top of steps where a formal cycle route plunges down a
> >> steep flight of steps around a corner!
> >>
> >> Mike
> >>
> >> On 2020-12-14 17:34, Jon Pennycook wrote:
> >>> resending as I think I sent it from the wrong email address.
> >>>
> >>> However, blue advisory signs about HGVs are tagged as
> >>> hgv=discouraged, not as hgv=yes despite there being a legal right of
> >>> way for HGVs (sometimes, similar signs are shown for all vehicles,
> >>> eg on fords or ORPAs) - see "discouraged" at
> >>>
> https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation
> >>>
> >>>
> >>> https://wiki.openstreetmap.org/wiki/Bicycle#Bicycle_Restrictions says
> >>> bicycle=dismount should be used for 'signs saying "Cyclists dismount"'.
> >>>
> >>> Any sensible router should know that most bicycles ought to dismount
> >>> for most steps in the same way they might suggest getting off and
> >>> walking on a short footway. Specifying bicycle=yes on steps may
> >>> override the built-in default (I think it does for CycleStreets).
> >>>
> >>> I would suggest not having a bicycle tag at all on steps in
> >>> preference to bicycle=yes on steps. Ramp:bicycle=yes/no is a useful
> >>> tag though.
> >>>
> >>> Jon
> >
> >
> > ___
> > Talk-GB mailing list
> > Talk-GB@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-gb
>
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>

[Talk-GB] Removing all stiles from bridleways

[Neil Matthews]

Looks like there's been an attempt to remove all stiles from bridleways 
-- pretty sure I've seen this done in other edits -- agree that they're 
a potential anomaly but should they really be a mechanical edit (even if 
by hand)? See https://www.openstreetmap.org/changeset/95739504


Cheers,
Neil


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] "GPS trace" tracking county boundary

[Andy Townsend]

On 14/12/2020 19:21, Edward Bainton wrote:


Glad I'm not going mad. Does it say anything useful or interesting 
that the "GPS trace" is a few metres away from the boundary as marked 
on the map? (Sorry if this has been answered recently: there was 
extensive discussion on alignment not long ago, but too technical for 
me to follow easily.)


That "county boundary GPS traces" has been there about 10 years or so at 
a guess?  According to OSM's GPS traces, my first mapping in Rutland was 
around 10 years ago and I think those boundaries were there then.  I 
can't see that it ever added any value; it just serves to confuse people 
like me trying to use GPS traces to help align other imagery.


I don't remember it being discussed recently, though it has cropped up 
before (maybe 8-10 years ago?).


Best Regards,

Andy


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Please SWITCH to Mailman 3 & hyperkitty

[ipswichmapper--- via talk]

Thanks, for the links. Very insightful diiscussion at Github, however the forum 
link isn't working.
-- 
 


14 Dec 2020, 19:48 by talk@openstreetmap.org:

>
>
>
> Dec 14, 2020, 20:23 by j...@liotier.org:
>
>> On 12/14/20 8:13 PM, >> ipswichmap...@tutanota.com>>  wrote:
>>
>>> > A bigger problem is that the UI for list owners ishorrid.
>>>
>>> Ok. What alternative solutions do you propose?
>>>
>>
>> From Tom's answer, you might gather that there are higher  priorities 
>> that absorb administrative resources - so unless you  can offer a hand, 
>> I'm afraid that things will remain as they are  for now.
>>
>>
> See
> https://github.com/openstreetmap/operations/issues/377
> https://forum.openstreetmap.org/viewtopic.php?id=68929
> https://wiki.openstreetmap.org/w/index.php?title=Top_Ten_Tasks=20100=2072003=1971678
>
>

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Please SWITCH to Mailman 3 & hyperkitty

[Paul Johnson]

On Mon, Dec 14, 2020 at 1:51 PM ipswichmapper--- via talk <
talk@openstreetmap.org> wrote:

> You are right. If updating to mailman 3 will take monrhs of work it is
> probably not worth trying to make any changes right now.
>

Recurring OpenStreetMap theme:  If fixing something takes absolutely any
effort at all, then it's not worth doing, even if the effort already is
underway.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] "GPS trace" tracking county boundary

[Chris Hodges]

Either a datum mix-up or different roundings used in the constants for 
the back-and-forth conversion.  Either way that's not a real trace


On 14/12/2020 19:33, Colin Smale wrote:


On 2020-12-14 20:21, Edward Bainton wrote:


With plenty of portages...
Glad I'm not going mad. Does it say anything useful or interesting 
that the "GPS trace" is a few metres away from the boundary as marked 
on the map? (Sorry if this has been answered recently: there was 
extensive discussion on alignment not long ago, but too technical for 
me to follow easily.)
If my suspicion is correct that a converted version of the OS 
Boundary-Line data was uploaded as GPX, then the small shift just 
indicates that the exact parameters used to convert from the OS 
coordinate system (Eastings and Northings) to the system used by GPS 
and OSM were different.


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb




___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Please SWITCH to Mailman 3 & hyperkitty

[Mateusz Konieczny via talk]

Dec 14, 2020, 20:23 by j...@liotier.org:

> On 12/14/20 8:13 PM, > ipswichmap...@tutanota.com>  wrote:
>
>> > A bigger problem is that the UI for list owners ishorrid.
>>
>> Ok. What alternative solutions do you propose?
>>
>
> From Tom's answer, you might gather that there are higher  priorities 
> that absorb administrative resources - so unless you  can offer a hand, 
> I'm afraid that things will remain as they are  for now.
>
>
See
https://github.com/openstreetmap/operations/issues/377
https://forum.openstreetmap.org/viewtopic.php?id=68929
https://wiki.openstreetmap.org/w/index.php?title=Top_Ten_Tasks=20100=2072003=1971678

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Please SWITCH to Mailman 3 & hyperkitty

[ipswichmapper--- via talk]

You are right. If updating to mailman 3 will take monrhs of work it is probably 
not worth trying to make any changes right now.

I was wondering, however, what changes to the mailing list the team are 
considering doing in the future, as Tom said they are looking into things.
Thanks,
IpswichMapper-- 
 


14 Dec 2020, 19:23 by j...@liotier.org:

> On 12/14/20 8:13 PM, > ipswichmap...@tutanota.com>  wrote:
>
>> > A bigger problem is that the UI for list owners ishorrid.
>>
>> Ok. What alternative solutions do you propose?
>>
>
> From Tom's answer, you might gather that there are higher  priorities 
> that absorb administrative resources - so unless you  can offer a hand, 
> I'm afraid that things will remain as they are  for now.
>
>
>
>
>
>
>
>
>> -- 
>>
>> 14 Dec 2020, 19:07 by >> t...@compton.nu>> :
>>
>>> That's just the instructions on how to migrate the data
>>> and it doesn't cover anything related to actually  installing
>>> and configuring all the components of mailman 3 from a
>>> quick look which is a big issue given that it's not  packaged
>>> and it's a not a single tool like mailman 2 but rather is
>>> a collection of separate components.
>>>
>>> Given that we're already looking at other things there is
>>> no point in spending several months and many man hours on
>>> attempting a migration to something that we have to install
>>> from source and then try and keep up to date without any
>>> upstream packages.
>>>
>>> You're right that the UI tries to be a web forum but from
>>> personal experience I can say that it fails - it's probably
>>> a better UI as a simple archiver but it's no use as a way
>>> of reading lists day to day. The only thing that's ever
>>> got close to that is Discourse.
>>>
>>> A bigger problem is that the UI for list owners is horrid.
>>>
>>> Tom
>>>
>>> On 14/12/2020 18:58, >>> ipswichmap...@tutanota.com>>>  wrote:
>>>
 Python's mailing lists use mailman 3:

 https://www.python.org/community/lists/   
  
 

 What is the problem with the UI ? It seems far, far more
 useable than pipermail and hyperkitty feels like a forum.

 If upgrading isn't possible, well then I guess bad luck.The 
 mailman focs doesn't make it look that hard (is itskipping 
 over OSM server specific steps that make theprocess harder?)

 https://docs.mailman3.org/en/latest/migration.html   
  
 

 Thanks,
 IpswichMapper
 -- 



 14 Dec 2020, 18:45 by  t...@compton.nu :

 It's not going to happen.

 Virtually nobody uses mailman 3 with the exception ofFedora
 and I know from using it there that the UI is adisaster.

 Also it's not packaged for Ubuntu and it's far morecomplicated 
 to
 deploy than what we have.

 Don't think of mailman 3 as an upgrade - it's basicallya
 totally different product.

 There is talk of a change, but it won't be to mailman 3.

 Tom

 On 14/12/2020 18:42,  ipswichmap...@tutanota.com  wrote:

 Okay thanks, I'll contact him on github. I don't havdmailman
 administration experience, or that much codingexperience for
 that matter. I was just suprised that we are stuck with10+
 years old cluttered pipermail when hyperkitty isactually 
 useable.

 -- 


 14 Dec 2020, 18:37 by  j...@liotier.org :

 From looking at the Mailman Chef cookbook at
 https://github.com/openstreetmap/chef/tree/master/cookbooks/mailman
  
  ,
 Tom Hughes is the person you should ask. If you havemailman
 administration experience, maybe you could make ithappen.


 On 12/14/20 7:18 PM, ipswichmapper--- via talk wrote:


 I was wondering if all the lists on
 https://lists.openstreetmap.org
  
 could be switched to Mailman 3 and hyperkitty (thenewest
 archiver).

 Currently, pipermail is used to archive, and its UI is
 *unusable*.
 Comparatevely, hyperkitty is a lot more like a forum.

 From my experience, the mailing lists are *far moreactive*
 than
 the forum, so it would be good to have it searchable& more
 accessible (the only downside to this is newer usersmight
 use the
 mailing list now. I don't think this is a 

Re: [Talk-GB] Tagging bike ramp/ bike path down steps

[Chris Hodges]

Accessibility tagging for bike routes would be great, and mean a lot of 
work on the ground. Things like gate/bollard widths would be good, and 
some of the stuff to keep motorbikes out - though some at least can be 
tagged; I recall some means of tagging a step-over gate on a bridleway 
but can't remember or instantly find the tag.  Some would be a bit 
subjective (especially where length and width are constrained), but 
something comparably coarse to wheelchair=limited would be a start


Despite riding a normal (except for being huge and laden with 
accessories) bike, and being able to lift it, accessibility of bike 
infrastructure is an area of particular interest for me.  I actually 
went for a child seat instead of a trailer because of the 
restrictiveness of some of the bike paths round here.


"Dismount" seems like by far the best tag if your average commuter 
cyclist or even a skilled roadie couldn't ride it - and some of the 
examples I've seen would put off most hardcore mountain bikers, while 
steps have been OK on my hybrid (each step longer than the bike, drops 
small).



On 14/12/2020 17:27, Simon Still wrote:
I’d agree with your approach and I’ve raised this before, but haven’t 
had the time to come back to it.


From a routing perspective it would be useful to be able to tag 
ACCESSIBILITY  - ie sections of route that are unsuitable for some 
users - not related to the legality but so that disabled cyclists 
(unable to dismount), those using trailers  or trikes or other 
non-standard cycles could specify a route that avoided sections where 
they could not ride.


Yes, I think bicycle dismount is correct tagging in this case not 
because of the legality but because of the steps.  If the bridge was 
had a ramp, or there was a subway, and it *could* be ridden across 
(even if there was a cyclist dismount sign) then I think tagging the 
dismount would be wrong.




On 14 Dec 2020, at 17:19, Michael Collinson > wrote:


FYI, here's the schema I personally use in Sweden, where heavy use is 
made of ramped staircases, though not thankfully on major cycle 
routes. My objective is to allow routers to intelligently route for 
both sport/club/large group riding and happy meandering or commute:


bicycle=yes only on very shallow low incline steps where it is is 
safe and practical to cycle an ordinary bike - not common but does 
happen. Sometimes on shallow slopes a gravelled or informal path to 
one side also exists.


where there is a ramp:
ramp=yes
bicycle=dismount   (here I am tagging on practicality rather than 
legalities, Sweden is much more relaxed than UK)
ramp:stroller=yes   where it is a double ramp, (a forgotten transport 
demographic)


on short or low-incline flights of steps where an alternate route 
would be much longer:

bicycle=carry (informal/experimental)

I also strongly encourage step_count=x as that gives a bicycle router 
more quantitative input on whether to route or avoid.


And lastly from unnerving Spanish experience, some sort of hazard 
tagging at the top of steps where a formal cycle route plunges down a 
steep flight of steps around a corner!


Mike

On 2020-12-14 17:34, Jon Pennycook wrote:

resending as I think I sent it from the wrong email address.

However, blue advisory signs about HGVs are tagged as 
hgv=discouraged, not as hgv=yes despite there being a legal right of 
way for HGVs (sometimes, similar signs are shown for all vehicles, 
eg on fords or ORPAs) - see "discouraged" at 
https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation 



https://wiki.openstreetmap.org/wiki/Bicycle#Bicycle_Restrictions says 
bicycle=dismount should be used for 'signs saying "Cyclists dismount"'.


Any sensible router should know that most bicycles ought to dismount 
for most steps in the same way they might suggest getting off and 
walking on a short footway. Specifying bicycle=yes on steps may 
override the built-in default (I think it does for CycleStreets).


I would suggest not having a bicycle tag at all on steps in 
preference to bicycle=yes on steps. Ramp:bicycle=yes/no is a useful 
tag though.


Jon



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb




___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] "GPS trace" tracking county boundary

[Colin Smale]

On 2020-12-14 20:21, Edward Bainton wrote:

> With plenty of portages... 
> 
> Glad I'm not going mad. Does it say anything useful or interesting that the 
> "GPS trace" is a few metres away from the boundary as marked on the map? 
> (Sorry if this has been answered recently: there was extensive discussion on 
> alignment not long ago, but too technical for me to follow easily.)

If my suspicion is correct that a converted version of the OS
Boundary-Line data was uploaded as GPX, then the small shift just
indicates that the exact parameters used to convert from the OS
coordinate system (Eastings and Northings) to the system used by GPS and
OSM were different.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Please SWITCH to Mailman 3 & hyperkitty

[Jean-Marc Liotier]

On 12/14/20 8:13 PM, ipswichmap...@tutanota.com wrote:

> A bigger problem is that the UI for list owners is horrid.

Ok. What alternative solutions do you propose?


From Tom's answer, you might gather that there are higher priorities 
that absorb administrative resources - so unless you can offer a hand, 
I'm afraid that things will remain as they are for now.





--

14 Dec 2020, 19:07 by t...@compton.nu:

That's just the instructions on how to migrate the data
and it doesn't cover anything related to actually installing
and configuring all the components of mailman 3 from a
quick look which is a big issue given that it's not packaged
and it's a not a single tool like mailman 2 but rather is
a collection of separate components.

Given that we're already looking at other things there is
no point in spending several months and many man hours on
attempting a migration to something that we have to install
from source and then try and keep up to date without any
upstream packages.

You're right that the UI tries to be a web forum but from
personal experience I can say that it fails - it's probably
a better UI as a simple archiver but it's no use as a way
of reading lists day to day. The only thing that's ever
got close to that is Discourse.

A bigger problem is that the UI for list owners is horrid.

Tom

On 14/12/2020 18:58, ipswichmap...@tutanota.com wrote:

Python's mailing lists use mailman 3:

https://www.python.org/community/lists/


What is the problem with the UI ? It seems far, far more
useable than pipermail and hyperkitty feels like a forum.

If upgrading isn't possible, well then I guess bad luck. The
mailman focs doesn't make it look that hard (is it skipping
over OSM server specific steps that make the process harder?)

https://docs.mailman3.org/en/latest/migration.html


Thanks,
IpswichMapper
-- 




14 Dec 2020, 18:45 by t...@compton.nu:

It's not going to happen.

Virtually nobody uses mailman 3 with the exception of Fedora
and I know from using it there that the UI is a disaster.

Also it's not packaged for Ubuntu and it's far more complicated to
deploy than what we have.

Don't think of mailman 3 as an upgrade - it's basically a
totally different product.

There is talk of a change, but it won't be to mailman 3.

Tom

On 14/12/2020 18:42, ipswichmap...@tutanota.com wrote:

Okay thanks, I'll contact him on github. I don't havd mailman
administration experience, or that much coding experience for
that matter. I was just suprised that we are stuck with 10+
years old cluttered pipermail when hyperkitty is actually useable.

-- 



14 Dec 2020, 18:37 by j...@liotier.org:

From looking at the Mailman Chef cookbook at
https://github.com/openstreetmap/chef/tree/master/cookbooks/mailman
,
Tom Hughes is the person you should ask. If you have mailman
administration experience, maybe you could make it happen.


On 12/14/20 7:18 PM, ipswichmapper--- via talk wrote:


I was wondering if all the lists on
https://lists.openstreetmap.org

could be switched to Mailman 3 and hyperkitty (the newest
archiver).

Currently, pipermail is used to archive, and its UI is
*unusable*.
Comparatevely, hyperkitty is a lot more like a forum.

From my experience, the mailing lists are *far more active*
than
the forum, so it would be good to have it searchable & more
accessible (the only downside to this is newer users might
use the
mailing list now. I don't think this is a downside, but I
understand why others would think so).

Also, Mailman 3 still gets updates, while *mailman2 is on
maintainance mode and won't recieve feature updates.*

I strongly recommend that the mailing lists are upgraded to
mailman3 with hyperkitty: this will make the mailing lists
so, so
much more useable.




-- Tom Hughes (t...@compton.nu)
http://compton.nu/



-- 
Tom Hughes (t...@compton.nu)

http://compton.nu/


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-es] Servidor de cache de tiles de OSM para evitar sobrecargar los servidores

[Miguel Sevilla-Callejo]

Muchas gracias Xavier,

Además de la imagen de Docker, ¿has publicado el Dockerfile o el
Dockercompose con el que reconstruir uno mismo la imagen?

La idea de Docker está muy bien pero ante las limitaciones que están
incluyendo recientemente en DockerHub es mejor saber como reconstruirse
uno mismo  la cosa.

Muchas gracias

Miguel

On 12/12/2020 15:47, Xavier Barnada wrote:
> Buenas tardes,
>
> A raíz de una charla en el grupo de telegram de la comunidad catalana
> de OSM, nos dimos cuenta de que hay servicios que están usando los
> tiles de OSM directamente en sus aplicaciones y esto puede provocar un
> exceso de tráfico en estos.
>
> Debido a esto he creado un docker que lo que hace es un proxy del
> servidor de tiles + caché de estos. De esta forma se si alguien repite
> la petición de una imagen que ya está en el caché se evita la petición
> al servidor.
>
> Está hecho con una librería que se llama Tilestache, si alguien tiene
> curiosidad o quiere más información me puede contactar sin problema.
>
> https://hub.docker.com/repository/docker/xevib/osmcache
>
> Saludos
> Xavier Barnada
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es


pEpkey.asc
Description: application/pgp-keys
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-GB] "GPS trace" tracking county boundary

[Edward Bainton]

With plenty of portages...

Glad I'm not going mad. Does it say anything useful or interesting that the
"GPS trace" is a few metres away from the boundary as marked on the map?
(Sorry if this has been answered recently: there was extensive discussion
on alignment not long ago, but too technical for me to follow easily.)

On Mon, 14 Dec 2020 at 18:50, Mark Goodge  wrote:

>
>
> On 14/12/2020 17:49, Martin Wynne wrote:
> > On 14/12/2020 17:27, Edward Bainton wrote:
> >> Any thoughts on why when I enable "public GPS traces" in iD, I get one
> >> that
> >> near enough exactly tracks the LA boundary South Kesteven:Peterborough
> >> (at
> >> Deeping St James)?
> >>
> >
> > Someone took their tracker with them when "Beating the Bounds"?
>
> In a canoe?
>
> Mark
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] OSM and Google

[Tom Hughes via talk]

No it couldn't - the google problem he refers to was with
their authentication service not their DNS service.

Tom

On 14/12/2020 19:10, James wrote:

are you using 8.8.8.8 or 4.4.4.4 as a dns? could explain it.

On Mon., Dec. 14, 2020, 1:58 p.m. Niels Elgaard Larsen, > wrote:


Google services was down for an hour today. I noticed that at the
same time I could
not push my edits with JOSM due to "internal server error"

Was that a coincidence or do we somehow depend on Google?



-- 
Niels Elgaard Larsen


___
talk mailing list
talk@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk




--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Please SWITCH to Mailman 3 & hyperkitty

[ipswichmapper--- via talk]

> A bigger problem is that the UI for list owners is horrid.

Ok. What alternative solutions do you propose?-- 

14 Dec 2020, 19:07 by t...@compton.nu:

> That's just the instructions on how to migrate the data
> and it doesn't cover anything related to actually installing
> and configuring all the components of mailman 3 from a
> quick look which is a big issue given that it's not packaged
> and it's a not a single tool like mailman 2 but rather is
> a collection of separate components.
>
> Given that we're already looking at other things there is
> no point in spending several months and many man hours on
> attempting a migration to something that we have to install
> from source and then try and keep up to date without any
> upstream packages.
>
> You're right that the UI tries to be a web forum but from
> personal experience I can say that it fails - it's probably
> a better UI as a simple archiver but it's no use as a way
> of reading lists day to day. The only thing that's ever
> got close to that is Discourse.
>
> A bigger problem is that the UI for list owners is horrid.
>
> Tom
>
> On 14/12/2020 18:58, ipswichmap...@tutanota.com wrote:
>
>> Python's mailing lists use mailman 3:
>>
>> https://www.python.org/community/lists/ 
>> 
>>
>> What is the problem with the UI ? It seems far, far more useable than 
>> pipermail and hyperkitty feels like a forum.
>>
>> If upgrading isn't possible, well then I guess bad luck. The mailman focs 
>> doesn't make it look that hard (is it skipping over OSM server specific 
>> steps that make the process harder?)
>>
>> https://docs.mailman3.org/en/latest/migration.html 
>> 
>>
>> Thanks,
>> IpswichMapper
>> -- 
>>
>>
>>
>> 14 Dec 2020, 18:45 by t...@compton.nu:
>>
>>  It's not going to happen.
>>
>>  Virtually nobody uses mailman 3 with the exception of Fedora
>>  and I know from using it there that the UI is a disaster.
>>
>>  Also it's not packaged for Ubuntu and it's far more complicated to
>>  deploy than what we have.
>>
>>  Don't think of mailman 3 as an upgrade - it's basically a
>>  totally different product.
>>
>>  There is talk of a change, but it won't be to mailman 3.
>>
>>  Tom
>>
>>  On 14/12/2020 18:42, ipswichmap...@tutanota.com wrote:
>>
>>  Okay thanks, I'll contact him on github. I don't havd mailman
>>  administration experience, or that much coding experience for
>>  that matter. I was just suprised that we are stuck with 10+
>>  years old cluttered pipermail when hyperkitty is actually useable.
>>
>>  -- 
>>
>>
>>  14 Dec 2020, 18:37 by j...@liotier.org:
>>
>>  From looking at the Mailman Chef cookbook at
>>  https://github.com/openstreetmap/chef/tree/master/cookbooks/mailman
>>  ,
>>  Tom Hughes is the person you should ask. If you have mailman
>>  administration experience, maybe you could make it happen.
>>
>>
>>  On 12/14/20 7:18 PM, ipswichmapper--- via talk wrote:
>>
>>
>>  I was wondering if all the lists on
>>  https://lists.openstreetmap.org
>>  
>>  could be switched to Mailman 3 and hyperkitty (the newest
>>  archiver).
>>
>>  Currently, pipermail is used to archive, and its UI is
>>  *unusable*.
>>  Comparatevely, hyperkitty is a lot more like a forum.
>>
>>  From my experience, the mailing lists are *far more active*
>>  than
>>  the forum, so it would be good to have it searchable & more
>>  accessible (the only downside to this is newer users might
>>  use the
>>  mailing list now. I don't think this is a downside, but I
>>  understand why others would think so).
>>
>>  Also, Mailman 3 still gets updates, while *mailman2 is on
>>  maintainance mode and won't recieve feature updates.*
>>
>>  I strongly recommend that the mailing lists are upgraded to
>>  mailman3 with hyperkitty: this will make the mailing lists
>>  so, so
>>  much more useable.
>>
>>
>>
>>
>>  -- Tom Hughes (t...@compton.nu)
>>  http://compton.nu/
>>
>
>
> -- 
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
>

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and Google

[James]

are you using 8.8.8.8 or 4.4.4.4 as a dns? could explain it.

On Mon., Dec. 14, 2020, 1:58 p.m. Niels Elgaard Larsen, 
wrote:

> Google services was down for an hour today. I noticed that at the same
> time I could
> not push my edits with JOSM due to "internal server error"
>
> Was that a coincidence or do we somehow depend on Google?
>
>
>
> --
> Niels Elgaard Larsen
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and Google

[Tom Hughes via talk]

On 14/12/2020 18:54, Niels Elgaard Larsen wrote:

Google services was down for an hour today. I noticed that at the same 
time I could not push my edits with JOSM due to "internal server error"


Was that a coincidence or do we somehow depend on Google?


It was a coincidence.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Please SWITCH to Mailman 3 & hyperkitty

[Tom Hughes via talk]

That's just the instructions on how to migrate the data
and it doesn't cover anything related to actually installing
and configuring all the components of mailman 3 from a
quick look which is a big issue given that it's not packaged
and it's a not a single tool like mailman 2 but rather is
a collection of separate components.

Given that we're already looking at other things there is
no point in spending several months and many man hours on
attempting a migration to something that we have to install
from source and then try and keep up to date without any
upstream packages.

You're right that the UI tries to be a web forum but from
personal experience I can say that it fails - it's probably
a better UI as a simple archiver but it's no use as a way
of reading lists day to day. The only thing that's ever
got close to that is Discourse.

A bigger problem is that the UI for list owners is horrid.

Tom

On 14/12/2020 18:58, ipswichmap...@tutanota.com wrote:

Python's mailing lists use mailman 3:

https://www.python.org/community/lists/ 



What is the problem with the UI ? It seems far, far more useable than 
pipermail and hyperkitty feels like a forum.


If upgrading isn't possible, well then I guess bad luck. The mailman 
focs doesn't make it look that hard (is it skipping over OSM server 
specific steps that make the process harder?)


https://docs.mailman3.org/en/latest/migration.html 



Thanks,
IpswichMapper
--



14 Dec 2020, 18:45 by t...@compton.nu:

It's not going to happen.

Virtually nobody uses mailman 3 with the exception of Fedora
and I know from using it there that the UI is a disaster.

Also it's not packaged for Ubuntu and it's far more complicated to
deploy than what we have.

Don't think of mailman 3 as an upgrade - it's basically a
totally different product.

There is talk of a change, but it won't be to mailman 3.

Tom

On 14/12/2020 18:42, ipswichmap...@tutanota.com wrote:

Okay thanks, I'll contact him on github. I don't havd mailman
administration experience, or that much coding experience for
that matter. I was just suprised that we are stuck with 10+
years old cluttered pipermail when hyperkitty is actually useable.

-- 




14 Dec 2020, 18:37 by j...@liotier.org:

 From looking at the Mailman Chef cookbook at
https://github.com/openstreetmap/chef/tree/master/cookbooks/mailman
,
Tom Hughes is the person you should ask. If you have mailman
administration experience, maybe you could make it happen.


On 12/14/20 7:18 PM, ipswichmapper--- via talk wrote:


I was wondering if all the lists on
https://lists.openstreetmap.org

could be switched to Mailman 3 and hyperkitty (the newest
archiver).

Currently, pipermail is used to archive, and its UI is
*unusable*.
Comparatevely, hyperkitty is a lot more like a forum.

 From my experience, the mailing lists are *far more active*
than
the forum, so it would be good to have it searchable & more
accessible (the only downside to this is newer users might
use the
mailing list now. I don't think this is a downside, but I
understand why others would think so).

Also, Mailman 3 still gets updates, while *mailman2 is on
maintainance mode and won't recieve feature updates.*

I strongly recommend that the mailing lists are upgraded to
mailman3 with hyperkitty: this will make the mailing lists
so, so
much more useable.




-- 
Tom Hughes (t...@compton.nu)

http://compton.nu/





--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Please SWITCH to Mailman 3 & hyperkitty

[ipswichmapper--- via talk]

Python's mailing lists use mailman 3:

https://www.python.org/community/lists/

What is the problem with the UI ? It seems far, far more useable than pipermail 
and hyperkitty feels like a forum.

If upgrading isn't possible, well then I guess bad luck. The mailman focs 
doesn't make it look that hard (is it skipping over OSM server specific steps 
that make the process harder?)

https://docs.mailman3.org/en/latest/migration.html

Thanks,
IpswichMapper-- 
 


14 Dec 2020, 18:45 by t...@compton.nu:

> It's not going to happen.
>
> Virtually nobody uses mailman 3 with the exception of Fedora
> and I know from using it there that the UI is a disaster.
>
> Also it's not packaged for Ubuntu and it's far more complicated to deploy 
> than what we have.
> Don't think of mailman 3 as an upgrade - it's basically a
> totally different product.
>
> There is talk of a change, but it won't be to mailman 3.
>
> Tom
>
> On 14/12/2020 18:42, ipswichmap...@tutanota.com wrote:
>
>> Okay thanks, I'll contact him on github. I don't havd mailman administration 
>> experience, or that much coding experience for that matter. I was just 
>> suprised that we are stuck with 10+ years old cluttered pipermail when 
>> hyperkitty is actually useable.
>>
>> -- 
>>
>>
>>
>> 14 Dec 2020, 18:37 by j...@liotier.org:
>>
>>  From looking at the Mailman Chef cookbook at
>>  https://github.com/openstreetmap/chef/tree/master/cookbooks/mailman
>>  ,
>>  Tom Hughes is the person you should ask. If you have mailman
>>  administration experience, maybe you could make it happen.
>>
>>
>>  On 12/14/20 7:18 PM, ipswichmapper--- via talk wrote:
>>
>>>
>>> I was wondering if all the lists on
>>>  https://lists.openstreetmap.org 
>>>  could be switched to Mailman 3 and hyperkitty (the newest archiver).
>>>
>>>  Currently, pipermail is used to archive, and its UI is *unusable*.
>>>  Comparatevely, hyperkitty is a lot more like a forum.
>>>
>>>  From my experience, the mailing lists are *far more active* than
>>>  the forum, so it would be good to have it searchable & more
>>>  accessible (the only downside to this is newer users might use the
>>>  mailing list now. I don't think this is a downside, but I
>>>  understand why others would think so).
>>>
>>>  Also, Mailman 3 still gets updates, while *mailman2 is on
>>>  maintainance mode and won't recieve feature updates.*
>>>
>>>  I strongly recommend that the mailing lists are upgraded to
>>>  mailman3 with hyperkitty: this will make the mailing lists so, so
>>>  much more useable.
>>>
>>
>>
>
>
> -- 
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
>

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OSM and Google

[Niels Elgaard Larsen]

Google services was down for an hour today. I noticed that at the same time I could 
not push my edits with JOSM due to "internal server error"


Was that a coincidence or do we somehow depend on Google?



--
Niels Elgaard Larsen

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] "GPS trace" tracking county boundary

[Mark Goodge]

On 14/12/2020 17:49, Martin Wynne wrote:

On 14/12/2020 17:27, Edward Bainton wrote:
Any thoughts on why when I enable "public GPS traces" in iD, I get one 
that
near enough exactly tracks the LA boundary South Kesteven:Peterborough 
(at

Deeping St James)?



Someone took their tracker with them when "Beating the Bounds"?


In a canoe?

Mark

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Please SWITCH to Mailman 3 & hyperkitty

[Tom Hughes via talk]

It's not going to happen.

Virtually nobody uses mailman 3 with the exception of Fedora
and I know from using it there that the UI is a disaster.

Also it's not packaged for Ubuntu and it's far more complicated
to deploy than what we have.

Don't think of mailman 3 as an upgrade - it's basically a
totally different product.

There is talk of a change, but it won't be to mailman 3.

Tom

On 14/12/2020 18:42, ipswichmap...@tutanota.com wrote:
Okay thanks, I'll contact him on github. I don't havd mailman 
administration experience, or that much coding experience for that 
matter. I was just suprised that we are stuck with 10+ years old 
cluttered pipermail when hyperkitty is actually useable.


--



14 Dec 2020, 18:37 by j...@liotier.org:

 From looking at the Mailman Chef cookbook at
https://github.com/openstreetmap/chef/tree/master/cookbooks/mailman
,
Tom Hughes is the person you should ask. If you have mailman
administration experience, maybe you could make it happen.


On 12/14/20 7:18 PM, ipswichmapper--- via talk wrote:


I was wondering if all the lists on
https://lists.openstreetmap.org 
could be switched to Mailman 3 and hyperkitty (the newest archiver).

Currently, pipermail is used to archive, and its UI is *unusable*.
Comparatevely, hyperkitty is a lot more like a forum.

From my experience, the mailing lists are *far more active* than
the forum, so it would be good to have it searchable & more
accessible (the only downside to this is newer users might use the
mailing list now. I don't think this is a downside, but I
understand why others would think so).

Also, Mailman 3 still gets updates, while *mailman2 is on
maintainance mode and won't recieve feature updates.*

I strongly recommend that the mailing lists are upgraded to
mailman3 with hyperkitty: this will make the mailing lists so, so
much more useable.






--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Please SWITCH to Mailman 3 & hyperkitty

[ipswichmapper--- via talk]

Okay thanks, I'll contact him on github. I don't havd mailman administration 
experience, or that much coding experience for that matter. I was just suprised 
that we are stuck with 10+ years old cluttered pipermail when hyperkitty is 
actually useable.
-- 
 


14 Dec 2020, 18:37 by j...@liotier.org:

>
> From looking at the Mailman Chef cookbook at > 
> https://github.com/openstreetmap/chef/tree/master/cookbooks/mailman> ,  
> Tom Hughes is the person you should ask. If you have mailman  
> administration experience, maybe you could make it happen.
>
>
>
>
> On 12/14/20 7:18 PM, ipswichmapper---  via talk wrote:
>
>>
>> I was wondering if all the lists on >> https://lists.openstreetmap.org>>  
>> could be switched to Mailman 3 and hyperkitty (the newestarchiver).
>>
>> Currently, pipermail is used to archive, and its UI is >> unusable>> .   
>>  Comparatevely, hyperkitty is a lot more like a forum.
>>
>> From my experience, the mailing lists are >> far more active>>  than the 
>> forum, so it would be good to have it searchable &more accessible 
>> (the only downside to this is newer users mightuse the mailing list 
>> now. I don't think this is a downside, butI understand why others 
>> would think so).
>>
>> Also, Mailman 3 still gets updates, while >> mailman2 is on  
>> maintainance mode and won't recieve feature updates.
>>
>> I strongly recommend that the mailing lists are upgraded tomailman3 
>> with hyperkitty: this will make the mailing lists so,so much more 
>> useable.
>>

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Please SWITCH to Mailman 3 & hyperkitty

[Jean-Marc Liotier]

From looking at the Mailman Chef cookbook at 
https://github.com/openstreetmap/chef/tree/master/cookbooks/mailman, Tom 
Hughes is the person you should ask. If you have mailman administration 
experience, maybe you could make it happen.



On 12/14/20 7:18 PM, ipswichmapper--- via talk wrote:


I was wondering if all the lists on https://lists.openstreetmap.org 
could be switched to Mailman 3 and hyperkitty (the newest archiver).


Currently, pipermail is used to archive, and its UI is *unusable*. 
Comparatevely, hyperkitty is a lot more like a forum.


From my experience, the mailing lists are *far more active* than the 
forum, so it would be good to have it searchable & more accessible 
(the only downside to this is newer users might use the mailing list 
now. I don't think this is a downside, but I understand why others 
would think so).


Also, Mailman 3 still gets updates, while *mailman2 is on maintainance 
mode and won't recieve feature updates.*


I strongly recommend that the mailing lists are upgraded to mailman3 
with hyperkitty: this will make the mailing lists so, so much more 
useable.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Please SWITCH to Mailman 3 & hyperkitty

[ipswichmapper--- via talk]

Hello,

I was wondering if all the lists on https://lists.openstreetmap.org could be 
switched to Mailman 3 and hyperkitty (the newest archiver).

Currently, pipermail is used to archive, and its UI is unusable. Comparatevely, 
hyperkitty is a lot more like a forum.

>From my experience, the mailing lists are far more active than the forum, so 
>it would be good to have it searchable & more accessible (the only downside to 
>this is newer users might use the mailing list now. I don't think this is a 
>downside, but I understand why others would think so).

Also, Mailman 3 still gets updates, while mailman2 is on maintainance mode and 
won't recieve feature updates.

I strongly recommend that the mailing lists are upgraded to mailman3 with 
hyperkitty: this will make the mailing lists so, so much more useable.

Thanks,
IpswichMapper
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] "GPS trace" tracking county boundary

[Martin Wynne]

On 14/12/2020 17:27, Edward Bainton wrote:

Any thoughts on why when I enable "public GPS traces" in iD, I get one that
near enough exactly tracks the LA boundary South Kesteven:Peterborough (at
Deeping St James)?



Someone took their tracker with them when "Beating the Bounds"?

 https://en.wikipedia.org/wiki/Beating_the_bounds

Martin.

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] "GPS trace" tracking county boundary

[Colin Smale]

I suspect someone has uploaded a GPX version of the boundary from OS
Boundary-Line. It doesn't look like an actual trace from a GPS receiver.


On 2020-12-14 18:27, Edward Bainton wrote:

> Any thoughts on why when I enable "public GPS traces" in iD, I get one that 
> near enough exactly tracks the LA boundary South Kesteven:Peterborough (at 
> Deeping St James)? 
> 
> See https://www.openstreetmap.org/#map=16/52.6543/-0.2655=G 
> 
> It seems unlikey that it really is a GPS trace - or is it? 
> 
> Thanks. 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] "GPS trace" tracking county boundary

[Edward Bainton]

Any thoughts on why when I enable "public GPS traces" in iD, I get one that
near enough exactly tracks the LA boundary South Kesteven:Peterborough (at
Deeping St James)?

See https://www.openstreetmap.org/#map=16/52.6543/-0.2655=G

It seems unlikey that it really is a GPS trace - or is it?

Thanks.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Tagging bike ramp/ bike path down steps

[Simon Still]

I’d agree with your approach and I’ve raised this before, but haven’t had the 
time to come back to it.  

From a routing perspective it would be useful to be able to tag ACCESSIBILITY  
- ie sections of route that are unsuitable for some users - not related to the 
legality but so that disabled cyclists (unable to dismount), those using 
trailers  or trikes or other non-standard cycles could specify a route that 
avoided sections where they could not ride.

Yes, I think bicycle dismount is correct tagging in this case not because of 
the legality but because of the steps.  If the bridge was had a ramp, or there 
was a subway, and it *could* be ridden across (even if there was a cyclist 
dismount sign) then I think tagging the dismount would be wrong. 



> On 14 Dec 2020, at 17:19, Michael Collinson  wrote:
> 
> FYI, here's the schema I personally use in Sweden, where heavy use is made of 
> ramped staircases, though not thankfully on major cycle routes. My objective 
> is to allow routers to intelligently route for both sport/club/large group 
> riding and happy meandering or commute:
> 
> bicycle=yes only on very shallow low incline steps where it is is safe and 
> practical to cycle an ordinary bike - not common but does happen. Sometimes 
> on shallow slopes a gravelled or informal path to one side also exists.
> 
> where there is a ramp:
> ramp=yes
> bicycle=dismount   (here I am tagging on practicality rather than legalities, 
> Sweden is much more relaxed than UK)
> ramp:stroller=yes   where it is a double ramp, (a forgotten transport 
> demographic)
> 
> on short or low-incline flights of steps where an alternate route would be 
> much longer:
> bicycle=carry (informal/experimental) 
> 
> I also strongly encourage step_count=x as that gives a bicycle router more 
> quantitative input on whether to route or avoid.
> 
> And lastly from unnerving Spanish experience, some sort of hazard tagging at 
> the top of steps where a formal cycle route plunges down a steep flight of 
> steps around a corner!
> 
> Mike
> 
> On 2020-12-14 17:34, Jon Pennycook wrote:
>> resending as I think I sent it from the wrong email address.
>> 
>> However, blue advisory signs about HGVs are tagged as hgv=discouraged, not 
>> as hgv=yes despite there being a legal right of way for HGVs (sometimes, 
>> similar signs are shown for all vehicles, eg on fords or ORPAs) - see 
>> "discouraged" at 
>> https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation 
>> 
>> 
>> https://wiki.openstreetmap.org/wiki/Bicycle#Bicycle_Restrictions 
>>  says 
>> bicycle=dismount should be used for 'signs saying "Cyclists dismount"'.
>> 
>> Any sensible router should know that most bicycles ought to dismount for 
>> most steps in the same way they might suggest getting off and walking on a 
>> short footway. Specifying bicycle=yes on steps may override the built-in 
>> default (I think it does for CycleStreets). 
>> 
>> I would suggest not having a bicycle tag at all on steps in preference to 
>> bicycle=yes on steps. Ramp:bicycle=yes/no is a useful tag though.   
>> 
>> Jon

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Tagging bike ramp/ bike path down steps

[Jon Pennycook]

Yes -  step_count is also very useful

Jon

On Mon, 14 Dec 2020 at 17:21, Michael Collinson  wrote:

> FYI, here's the schema I personally use in Sweden, where heavy use is made
> of ramped staircases, though not thankfully on major cycle routes. My
> objective is to allow routers to intelligently route for both
> sport/club/large group riding and happy meandering or commute:
>
> bicycle=yes only on very shallow low incline steps where it is is safe and
> practical to cycle an ordinary bike - not common but does happen. Sometimes
> on shallow slopes a gravelled or informal path to one side also exists.
>
> where there is a ramp:
> ramp=yes
> bicycle=dismount   (here I am tagging on practicality rather than
> legalities, Sweden is much more relaxed than UK)
> ramp:stroller=yes   where it is a double ramp, (a forgotten transport
> demographic)
>
> on short or low-incline flights of steps where an alternate route would be
> much longer:
> bicycle=carry (informal/experimental)
>
> I also strongly encourage step_count=x as that gives a bicycle router more
> quantitative input on whether to route or avoid.
>
> And lastly from unnerving Spanish experience, some sort of hazard tagging
> at the top of steps where a formal cycle route plunges down a steep flight
> of steps around a corner!
>
> Mike
>
> On 2020-12-14 17:34, Jon Pennycook wrote:
>
> resending as I think I sent it from the wrong email address.
>
> However, blue advisory signs about HGVs are tagged as hgv=discouraged, not
> as hgv=yes despite there being a legal right of way for HGVs (sometimes,
> similar signs are shown for all vehicles, eg on fords or ORPAs) - see
> "discouraged" at
> https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation
>
> https://wiki.openstreetmap.org/wiki/Bicycle#Bicycle_Restrictions says
> bicycle=dismount should be used for 'signs saying "Cyclists dismount"'.
>
> Any sensible router should know that most bicycles ought to dismount for
> most steps in the same way they might suggest getting off and walking on a
> short footway. Specifying bicycle=yes on steps may override the built-in
> default (I think it does for CycleStreets).
>
> I would suggest not having a bicycle tag at all on steps in preference to
> bicycle=yes on steps. Ramp:bicycle=yes/no is a useful tag though.
>
> Jon
>
> On Mon, 14 Dec 2020 at 15:31, Jon Pennycook 
> wrote:
>
>> However, blue advisory signs about HGVs are tagged as hgv=discouraged,
>> not as hgv=yes despite there being a legal right of way for HGVs
>> (sometimes, similar signs are shown for all vehicles, eg on fords or ORPAs)
>> - see "discouraged" at
>> https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation
>>
>> https://wiki.openstreetmap.org/wiki/Bicycle#Bicycle_Restrictions says
>> bicycle=dismount should be used for 'signs saying "Cyclists dismount"'.
>>
>> Any sensible router should know that most bicycles ought to dismount for
>> most steps in the same way they might suggest getting off and walking on a
>> short footway. Specifying bicycle=yes on steps may override the built-in
>> default (I think it does for CycleStreets).
>>
>> I would suggest not having a bicycle tag at all on steps in preference to
>> bicycle=yes on steps. Ramp:bicycle=yes/no is a useful tag though.
>>
>> Jon
>>
>> On Mon, 14 Dec 2020 at 11:04, Simon Still  wrote:
>>
>>>
>>>
>>> On 13 Dec 2020, at 19:18, Edward Catmur via Talk-GB <
>>> talk-gb@openstreetmap.org> wrote:
>>> On Sun, 13 Dec 2020, 19:14 David Woolley, 
>>> wrote:
>>>
 On 13/12/2020 19:05, Edward Catmur via Talk-GB wrote:
 > Also, the steps should have bicycle=dismount, not =yes. This will
 allow
 > people who can't dismount to go around by the road.

 Only if it is illegal to try to cycle up and down the steps.  Otherwise
 it is the duty of the renderer (router) to infer that this will be
 necessary because of the steps.

>>>
>>> The sign visible on Mapillary says (white on blue) "Steps ahead cyclists
>>> dismount". That seems pretty clear to me.
>>>
>>>
>>>
>>> White on Blue ‘cyclists dismount’ signs are only advisory.  It may be
>>> foolish to cycle down (or up) the steps but it’s not illegal.
>>>
>>>
>>> ___
>>> Talk-GB mailing list
>>> Talk-GB@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-gb
>>>
>>
> ___
> Talk-GB mailing 
> listTalk-GB@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-gb
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Tagging bike ramp/ bike path down steps

[Michael Collinson]

FYI, here's the schema I personally use in Sweden, where heavy use is 
made of ramped staircases, though not thankfully on major cycle routes. 
My objective is to allow routers to intelligently route for both 
sport/club/large group riding and happy meandering or commute:


bicycle=yes only on very shallow low incline steps where it is is safe 
and practical to cycle an ordinary bike - not common but does happen. 
Sometimes on shallow slopes a gravelled or informal path to one side 
also exists.


where there is a ramp:
ramp=yes
bicycle=dismount   (here I am tagging on practicality rather than 
legalities, Sweden is much more relaxed than UK)
ramp:stroller=yes   where it is a double ramp, (a forgotten transport 
demographic)


on short or low-incline flights of steps where an alternate route would 
be much longer:

bicycle=carry (informal/experimental)

I also strongly encourage step_count=x as that gives a bicycle router 
more quantitative input on whether to route or avoid.


And lastly from unnerving Spanish experience, some sort of hazard 
tagging at the top of steps where a formal cycle route plunges down a 
steep flight of steps around a corner!


Mike

On 2020-12-14 17:34, Jon Pennycook wrote:

resending as I think I sent it from the wrong email address.

However, blue advisory signs about HGVs are tagged as hgv=discouraged, 
not as hgv=yes despite there being a legal right of way for HGVs 
(sometimes, similar signs are shown for all vehicles, eg on fords or 
ORPAs) - see "discouraged" at 
https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation 
 



https://wiki.openstreetmap.org/wiki/Bicycle#Bicycle_Restrictions 
 says 
bicycle=dismount should be used for 'signs saying "Cyclists dismount"'.


Any sensible router should know that most bicycles ought to dismount 
for most steps in the same way they might suggest getting off and 
walking on a short footway. Specifying bicycle=yes on steps may 
override the built-in default (I think it does for CycleStreets).


I would suggest not having a bicycle tag at all on steps in preference 
to bicycle=yes on steps. Ramp:bicycle=yes/no is a useful tag though.


Jon

On Mon, 14 Dec 2020 at 15:31, Jon Pennycook > wrote:


However, blue advisory signs about HGVs are tagged as
hgv=discouraged, not as hgv=yes despite there being a legal right
of way for HGVs (sometimes, similar signs are shown for all
vehicles, eg on fords or ORPAs) - see "discouraged" at
https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation



https://wiki.openstreetmap.org/wiki/Bicycle#Bicycle_Restrictions

says bicycle=dismount should be used for 'signs saying "Cyclists
dismount"'.

Any sensible router should know that most bicycles ought to
dismount for most steps in the same way they might suggest getting
off and walking on a short footway. Specifying bicycle=yes on
steps may override the built-in default (I think it does for
CycleStreets).

I would suggest not having a bicycle tag at all on steps in
preference to bicycle=yes on steps. Ramp:bicycle=yes/no is a
useful tag though.

Jon

On Mon, 14 Dec 2020 at 11:04, Simon Still mailto:simon.st...@gmail.com>> wrote:




On 13 Dec 2020, at 19:18, Edward Catmur via Talk-GB
mailto:talk-gb@openstreetmap.org>> wrote:
On Sun, 13 Dec 2020, 19:14 David Woolley,
mailto:for...@david-woolley.me.uk>> wrote:

On 13/12/2020 19:05, Edward Catmur via Talk-GB wrote:
> Also, the steps should have bicycle=dismount, not =yes.
This will allow
> people who can't dismount to go around by the road.

Only if it is illegal to try to cycle up and down the
steps.  Otherwise
it is the duty of the renderer (router) to infer that
this will be
necessary because of the steps.


The sign visible on Mapillary says (white on blue) "Steps
ahead cyclists dismount". That seems pretty clear to me.




White on Blue ‘cyclists dismount’ signs are only advisory.  It
may be foolish to cycle down (or up) the steps but it’s not
illegal.


___
Talk-GB mailing list
Talk-GB@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-gb



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


___

Re: [OSM-talk-fr] un début de OSM - mon commerce

[Yves P.]

> puis-je suggérer d'améliorer les outils existant (par ex OsmMyBiz) au lieu de 
> refaire une nouvelle rue depuis zéro ?

Si possible oui.


> Je suis un peu dépité quand je renseigne osm a un commerçant de devoir lui 
> renseigner 3 roues incomplètes au lieu d'un écosystème intégré.

C'est bien le problème§me, il n'y a rien d'adapté pour la France et de complet 
(par exemple on peut rajouter une entreprise, mais pas mettre à jour les 
informations existantes).


> la liste de souhait a été évoqué ici et sur là ml aussi cette année 

As-tu des liens stp ?

__
Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Mapping a single Royal Mail mailbox with two references

[Stephen Colebourne]

Here is an example to copy from. Note post_box:apertures tag and the
semi-colon (no spaces) in the ref.
https://www.openstreetmap.org/node/8172063557

Stephen

On Mon, 14 Dec 2020 at 13:49, Mat Attlee  wrote:
>
> What's the most appropriate way to map a single physical Royal Mail mailbox 
> with two signs and references? I recently stumbled upon such a mailbox and 
> created a POI for each sign / reference:
>
> https://www.openstreetmap.org/node/8214997322
> https://www.openstreetmap.org/node/8215022917
>
> However given the collection times are the same and it is just one physical 
> mailbox would it be better to have a single POI with two references?
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Tagging bike ramp/ bike path down steps

[Jon Pennycook]

resending as I think I sent it from the wrong email address.

However, blue advisory signs about HGVs are tagged as hgv=discouraged, not
as hgv=yes despite there being a legal right of way for HGVs (sometimes,
similar signs are shown for all vehicles, eg on fords or ORPAs) - see
"discouraged" at
https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation

https://wiki.openstreetmap.org/wiki/Bicycle#Bicycle_Restrictions says
bicycle=dismount should be used for 'signs saying "Cyclists dismount"'.

Any sensible router should know that most bicycles ought to dismount for
most steps in the same way they might suggest getting off and walking on a
short footway. Specifying bicycle=yes on steps may override the built-in
default (I think it does for CycleStreets).

I would suggest not having a bicycle tag at all on steps in preference to
bicycle=yes on steps. Ramp:bicycle=yes/no is a useful tag though.

Jon

On Mon, 14 Dec 2020 at 15:31, Jon Pennycook  wrote:

> However, blue advisory signs about HGVs are tagged as hgv=discouraged, not
> as hgv=yes despite there being a legal right of way for HGVs (sometimes,
> similar signs are shown for all vehicles, eg on fords or ORPAs) - see
> "discouraged" at
> https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation
>
> https://wiki.openstreetmap.org/wiki/Bicycle#Bicycle_Restrictions says
> bicycle=dismount should be used for 'signs saying "Cyclists dismount"'.
>
> Any sensible router should know that most bicycles ought to dismount for
> most steps in the same way they might suggest getting off and walking on a
> short footway. Specifying bicycle=yes on steps may override the built-in
> default (I think it does for CycleStreets).
>
> I would suggest not having a bicycle tag at all on steps in preference to
> bicycle=yes on steps. Ramp:bicycle=yes/no is a useful tag though.
>
> Jon
>
> On Mon, 14 Dec 2020 at 11:04, Simon Still  wrote:
>
>>
>>
>> On 13 Dec 2020, at 19:18, Edward Catmur via Talk-GB <
>> talk-gb@openstreetmap.org> wrote:
>> On Sun, 13 Dec 2020, 19:14 David Woolley, 
>> wrote:
>>
>>> On 13/12/2020 19:05, Edward Catmur via Talk-GB wrote:
>>> > Also, the steps should have bicycle=dismount, not =yes. This will
>>> allow
>>> > people who can't dismount to go around by the road.
>>>
>>> Only if it is illegal to try to cycle up and down the steps.  Otherwise
>>> it is the duty of the renderer (router) to infer that this will be
>>> necessary because of the steps.
>>>
>>
>> The sign visible on Mapillary says (white on blue) "Steps ahead cyclists
>> dismount". That seems pretty clear to me.
>>
>>
>>
>> White on Blue ‘cyclists dismount’ signs are only advisory.  It may be
>> foolish to cycle down (or up) the steps but it’s not illegal.
>>
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Mapping a single Royal Mail mailbox with two references

[Peter Neale via Talk-GB]

The Wiki says,
"Sometimes several post boxes are standing together and can most often be 
tagged with one single node. If the boxes have different reference numbers this 
is tagged as ref=12242;23214. You can also use two separate nodes in such 
cases, which may be more appropriate if the boxes are two separate physical 
entities. It would also be necessary to use two nodes if the two boxes had 
different collection times or item restrictions and you wanted to tag these 
differences."
So, if their type and collection times are the same, I think you can choose to 
tag 2 separate nodes, or one node with 2 refs, separated by a semi-colon.
Regards,Peter


On Monday, 14 December 2020, 13:51:24 GMT, Mat Attlee 
 wrote:  
 
 What's the most appropriate way to map a single physical Royal Mail mailbox 
with two signs and references? I recently stumbled upon such a mailbox and 
created a POI for each sign / reference:

https://www.openstreetmap.org/node/8214997322https://www.openstreetmap.org/node/8215022917
However given the collection times are the same and it is just one physical 
mailbox would it be better to have a single POI with two 
references?___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
  ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-legal-talk] Brexit & EU database rights

[Simon Poole]

https://www.gov.uk/guidance/sui-generis-database-rights-after-the-transition-period 
is the UKs governments guidance on this.  On re-reading I agree that the 
withdrawal agreement itself is rather ambiguous, and there is a lot of 
conflicting advice on the matter, see for example 
https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwiL38fux83tAhXNCuwKHYHXAjgQFjABegQIAhAC=https%3A%2F%2Fwww.herbertsmithfreehills.com%2Ffile%2F37041%2Fdownload%3Ftoken%3DOr7GPtMf=AOvVaw0jZK9j_3jP6xJNsnbzaKJ5 
or 
https://www.gevers.eu/en/tb8PacLcwp/brexit--copyright-and-sui-generis-database-right.php 
that states just like the UK governments guidance that the rights will 
continue on post end of the transition period in the EEA.


I suspect clarity on this could only come from the official EU side of 
things, not that it really matters as in any case action is required by 
the OSMF.


Simon

Am 14.12.2020 um 13:34 schrieb Tom Hummel:

Hi Simon,

My understanding is that 58.2 covers the rights of UK based entities, 
with other words it extends the directives article 11 to cover UK 
residents and entities.
From 58 II: “The following persons and undertakings shall be deemed to 
comply” … (basically) people and entities in the UK.


Does “deem to comply” mean, those persons have to comply? It reads as 
if the people mentioned in 58 II are subject to an obligation (the 
duty to obey the rights from 58 I) not the beneficiary. 58 seems to 
talk about EU entities that are, essentially, UK based or active 
within the UK.


Art 58 in general seems to be concerned with continuing EU database 
law within the the UK for EU subjects, not the other way around: 
“holder of a right in relation to a database […] maintain an 
enforceable intellectual property right in the United Kingdom, under 
the law of the United Kingdom”.


Meaning, OSMF, or any EU entity ftm, continues to hold database rights 
within the UK, but not within the EU – only under more general 
provisions. Not even art. 4 TRIPs seems to grant any more rights, 
since lack of any other more favorable agreements among trips members.


I have found an english legal opinion:
===
https://www.womblebonddickinson.com/uk/insights/articles-and-briefings/brexit-and-database-rights


Accordingly, in the event no agreement is reached […] whereby:

· the UK will continue to recognise Database Right of EU (and UK) 
qualifiers so they will not lose rights to which they were entitled 
in the UK on the date of withdrawal


· the EU will cease to recognise Database Right of UK qualifiers in 
respect of databases created *before* the date of withdrawal.

Thanks for your courtesy!

Tom









OpenPGP_signature
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

[Talk-de] Weihnachtskarten 2020

[Frederik Ramm]

Hallo,

Weihnachten ist dieses Jahr für die meisten etwas anders als sonst, aber
unverändert gibt's unsere kleine Geofabrik-Weihnachtskarten-Aktion.

Wie schon im letzten Jahr bieten wir Euch hier auf der deutschen
Mailingliste und im deutschen Forum an, kostenlos eine große Karte von
einem Gebiet Eurer Wahl auszudrucken und Euch zu schicken.

Das Angebot gilt nur bis morgen (Dienstag) mittag. Wir drucken alle
Aufträge in der Reihenfolge, in der sie reinkommen, und nur so lange,
bis wir am Dienstag abend nach Hause gehen. Da bringen wir dann auch
gleich alles zur Post.

Wenn ihr eine Karte zugeschickt haben möchtet, brauchen wir von Euch:

* entweder ein fertiges PNG (bzw Link zum Download desselben)
* oder einen Link zu einer Karte, die ihr auf Hartmuts MyOSMatic-Seite
erstellt habt (https://print.get-map.org/)
* oder die Koordinaten eines Ausschnitts (alternativ Link zu einem
Rechteck auf tools.geofabrik.de/calc), dann erzeugen wir ein Bild im
Standard-Carto-Stil oder um deutschen OSM-Stil

und außerdem

* das Papierformat - wenn nicht anders angegeben, drucken wir "Super A0"
mit 15035x10559 Pixel, ca 1,30x0,90m
* die Adresse, wo es hingehen soll. Wir verschicken nur an deutsche
Adressen, sonst wird der Spaß zu teuer!

Das ganze per Email an weihnachtsdr...@geofabrik.de

Wir drucken die Karte, falten sie, und verschicken sie in einem Umschlag
im Format B4. Wir übernehmen alle Kosten, auch das Porto.

Die Aktion ist als Dankeschön für die unermüdliche Arbeit der
Mapperinnen und Mapper in OSM gedacht. Bitte verzichtet darauf, das
ganze in sozialen Medien weiterzuverbreiten - bis sich das rumspricht,
ist die Warteschlange eh voll, und es gibt nur lange Gesichter.

Bye
Frederik

PS: Wer die Karte gern gerollt und nicht gefaltet haben will ODER wer
einen Versand ins Ausland wünscht: Das geht auch, aber dann müsst ihr
uns eine entsprechende Post-Briefmarke (für gefalteten Versand ins
Ausland) oder DHL-Paketmarke "Paket bis 5kg" (für den aufgerollten
Versand in einer quaderförmigen Schachtel - die Größenbeschränkungen
beim "2kg"-Paket sind zu knapp) als PDF generieren und zuschicken.

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[talk-latam] cómo establecer un contact —estable— con YMUP?

[Mario Frasca]

queridos jóvenes mapeadores de la universidad de Panamá,

estoy comentando unas ediciones que están entrando en vuestras áreas de 
interés, ejecutadas en forma de revisión de los datos brutos, sea 
insertados durante vuestros "mapathon", sea llegando gracias a los 
proyectos que siguen abiertos y siguen atrayendo principiantes.


en particular Marianne_pty me responde 
(https://www.openstreetmap.org/changeset/95350683), y me pide que no le 
dé comentarios generales.


pero, cuál canal tenemos abierto, para los comentarios generales?

intento vuestro correo e involucro la lista regional.

en el caso de Colón, los YMUP han escojido un lugar en que se está 
tumbando y reconstruyendo. las fotos están —todas — desactualizadas, 
Bing muestra una realidad que ya no existe, mientras Maxar muestra 
muchos edificios destechados, o sea ya no son `building` sino 
`disused:`, `abandoned:` o quizás serían `landuse=greenfield`, tal vez 
ya `landuse=construction` o podrían ser nuevos edificios ya entregados.


o sea: al momento mapear Colón es difícil, y les cuento que no entiendo 
vuestra decisión de empujar maperos principiantes en un lugar tan 
complicado y dinámico.  igualmente difícil (aunque menos dinámico) es 
vuestro mapeo de San Miguelito, donde tuvieron que llamar expertos 
extranjeros, creo que de HOT, para revisar las ediciones, que lo están 
haciendo sin consultarse con los maperos activos en el país.


Marianne_pty escribe que vuestro grupo también se siente comprometido 
con "la zona de Chiriquí afectada por el Huracán". pero no entiendo, ya 
tienen sin completar la actividad HOT 4917, el área de Guna Nega, las 
comunidades amenazadas por los ríos en en sur del distrito de Mariato, 
porqué no concentrarse en una cosa, sencilla o por lo menos a su 
alcance, y completarla aprendiendo de ella?


además: cuál zona? 
https://wiki.openstreetmap.org/wiki/File:YMUP-2020-11-organized-editing-Chiriqu%C3%AD.jpg


cordialmente,

Mario Frasca


___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

[Talk-GB] Mapping a single Royal Mail mailbox with two references

[Mat Attlee]

What's the most appropriate way to map a single physical Royal Mail mailbox
with two signs and references? I recently stumbled upon such a mailbox and
created a POI for each sign / reference:

https://www.openstreetmap.org/node/8214997322
https://www.openstreetmap.org/node/8215022917

However given the collection times are the same and it is just one physical
mailbox would it be better to have a single POI with two references?
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Diversity-talk] Etiquette Guidelines bad | Re: Code of conduct

[Mikel Maron]

Yes. And in case you haven’t seen, the board has asked the lccwg to convene and 
come up with recommendations — including Code of Conduct and moderation 
processes — for the OSMF Board to adopt. 
https://blog.openstreetmap.org/2020/12/11/message-from-osmf-board-chair-on-mailing-list-behavior/
 

Mikel

On Sunday, December 13, 2020, 9:16 PM, arnalie faye vicario 
 wrote:

The current Etiquette Guidelines is not enough. By the title, it is just a 
"guideline"  - a suggestion or a piece of advice. 
We really need a CODE of Conduct that is enforceable with a committed moderator 
or working group.
 As a non-native English speaker, I have to look up the definitions in the 
dictionary to confirm.

=Arnalie
On Thu, Dec 10, 2020 at 1:06 AM Mikel Maron  wrote:

The etiquette guidelines have issues, but I’m not sure that’s one. If there was 
moderation and enforcement in place, than we wouldn’t need to call out 
publicly. Moderator could step in to do that. Prefer that way of handling it.

Mikel

On Wednesday, December 9, 2020, 11:33 AM, Rory McCann  
wrote:

Have any of yous read the Ettiquette Guidelines¹? They're rubbish.

Frederik broke them by publically calling Mike Migurski out, and for not 
assuming he was acting in good faith. *But* if anyone publishes something 
saying “What Frederik did was wrong” (like I (& others) did), then they are 
also breaking the Ettiquette Guidelines! That's a horrible outcome!

¹ https://wiki.osmfoundation.org/wiki/Etiquette

On Wed, 9 Dec 2020, at 16:57, Maggie Cawley wrote:
> I am so happy to see this thread. I believe it will take all of us 
> coming together and speaking with a unified voice to bring upon the 
> change we need at the global level. As Clifford mentioned, a few of us 
> from the LCCWG met on Monday to start talking about next steps. It's 
> not about one statement, but rather that discussions and comments like 
> those from this past week affect us all as we work to build diverse 
> communities around the world.  
> 
> Rob, Clifford and I discussed the need for a CoC, but when Rob pointed 
> out the Etiquette Guidelines exist and are pretty widely accepted it 
> seems like a logical place to start. It would also enable us to move a 
> bit more quickly since the document exists and won't need many rounds 
> of community feedback. What is missing is the process for moderation 
> and a committee available to moderate any complaints on breaches of 
> etiquette. It would be helpful to review and suggest edits to the 
> existing guidelines during this process as well. For the US CoC it took 
> about 8 months to finalize the CoC and moderation process, and find 
> volunteers for a committee.
> 
> I look forward to growing the conversation. Thanks Heather for starting 
> this thread here and to all of you who are stepping forward!
> 
> Maggie Cawley
> 
> 
> On Tue, 8 Dec 2020 at 21:30, arnalie faye vicario  
> wrote:
> > Hello/*Kumusta*,
> > 
> > *Salamat*/Thanks everyone for continuing the conversations and taking this 
> > seriously.
> > 
> > It is good to speak up and comment about it in our individual capacities, 
> > but a collective can build a fire  (charcoal comparison). 
> > 
> > This is what we did in OSM PH's Call to Correct Narratives About Geospatial 
> > Work in the Philippines (re: Amazon-HOT video).  
> > 
> > 
> > Also, I would like to quote and highlight what David Garcia 
> > (@mapmakerdavid) has shared in Twitter:
> >> It is not just the maps that matters. Who *makes* the maps matters. Who 
> >> *tells* the stories of the mapping matters, too. Who *LEADS* the mapping 
> >> and storytelling also matters. Who *gets powerful* due to the mapping and 
> >> storytelling matters most.
> > 
> > Thank you Geochicas, Celine @mapeadora, Heather, Rebecca, Miriam 
> > @mapanauta, Nelson Minar, LCCWG Group, OSMF past/present Board members 
> > (Kate, Rory and Mikel), HOT Community WG and everyone who expressed support 
> > and has spoken up (apologies if I missed your name). It is really 
> > encouraging and inspiring. Please add your thoughts in the document: 
> > https://docs.google.com/document/d/130JCTX9ve4H4ORXznmIVTpXiN3TX8nRGA8ayuTZ9ECI/edit
> > 
> > In case you missed it (like me), here is what Celine sent in the OSM talk 
> > mailing list: 
> > https://lists.openstreetmap.org/pipermail/talk/2020-December/085727.html.
> > 
> > Let us keep the fire burning!
> > 
> > =Arnalie
> > 
> > On Wed, Dec 9, 2020 at 5:54 AM Clifford Snow  
> > wrote:
> >> I should mention that what we, Maggie Crawely, Rob Nickerson and myself, 
> >> want to accomplish is to create a committee to moderate the existing 
> >> etiquette guidelines and later update the guidelines to reflect best 
> >> practices of Code of Conducts.We planned to form a sub committee under the 
> >> LCCWG since CoC is critical to Local Chapters. We did a survey of Local 
> >> Chapters and those 

Re: [Talk-GB] Idea - OSMUK walkers' map application -- -& server

[Nick Whitelegg via Talk-GB]

Hello Adam,

OK - that's great, thanks!

Does the AWS hosting include full shell access? We'll need that to install the 
relevant software.

Let me know if/when the server space is available.

In the meantime I will create a Hetzner server to start experimenting, this 
will be around EUR4/month which I am prepared to meet in the short term, I will 
also give accounts to trusted members of the community on request to work on 
the project should they wish.

Nick





From: OSMUK 
Sent: 13 December 2020 18:36
To: talk-gb@openstreetmap.org 
Cc: Nick Whitelegg 
Subject: Re: [Talk-GB] Idea - OSMUK walkers' map application -- -& server

Hey Nick,

This sounds like a great project and so I’m sure OSMUK can help with server 
space. We have just migrated hosting to AWS due to our previous host shutting 
down, so one option is to provide some space on there.

Best,

Adam

--
Adam Hoyle
[m] 07973 428 333
On 11 Dec 2020, 15:02 +, Nick Whitelegg via Talk-GB , wrote:

Hello Andy,

Thanks for this.

My own feeling regarding what server we need is "start small, to get it going" 
and then as soon as OSMUK can commit to funding (*if* they can, of course) 
and/or several people share the cost, then scale up. Hetzner's model is very 
flexible in this regard, for instance I started with an 8GB RAM VM before I 
found it wasn't quite adequate for my needs and upgraded the same VM to the 
16GB version (and added some disc space, I think, too). For now I am willing to 
spend a small amount (below EUR/GBP 5) for a month or two to get things going 
if there's sufficient interest.

I'd broadly agree to an extent about going the Mapnik route although I would 
prefer another person with more experience in the niceties of current Mapnik 
stylesheet development to do large-scale tweaks;  I would be happy to do small​ 
tweaks on such things as, for example, making designations appear in a similar 
style to Landranger which might be an idea for familiarity purposes. On the 
other hand, vector rendering would have some advantages for the aims of this 
project - an interactive map of the countryside in which POIs and paths can be 
clicked to add/retrieve information. I believe Tangram can do this quite 
easily; I have dabbled in Tangram and it's quite easy to setup a simple 
stylesheet though haven't tried it with anything complex. Tangram also has some 
nice things like being able to be rendered in both isometric and (via A-Frame 
components, https://aframe.io) even in 3D. I have to admit having a personal 
like for the vector approach,   it shifts more processing onto the client, good 
in a world where standard client hardware, desktop and mobile, is pretty 
powerful while powerful server hardware is expensive.

I wouldn't personally be so fussed about things like minutely updates until it 
becomes a 'production' map, while in development mode I think the best approach 
is to keep it simple and cheap to run. In terms of my own projects I do quite 
rigorous filtering of the OSM data before populating the DB, to reject things 
mostly of interest to urban areas which only use up space and resources in a 
walking-oriented map. Another way of keeping initial costs down would be to 
concentrate on one or a few counties, ideally well-mapped ones with many ROWs, 
hills, water features etc.

So I'd be quite happy - if​ there's interest - to setup a cheaper Hetzner 
server for now. If we want to go the mapnik route I'd be happy to do a basic 
setup there as well, as in, get mod_tile working and use your style unmodified. 
My main personal contribution to the project would be to work on the server- 
and client-side scripting necessary to develop an interactive POI map. We'd 
also of course need people with strong web design and UX skills - alas, mine 
are not so great!

As for other points - things like https cert renewal seem easy with Let's 
Encrypt; have been using that succesfully for a while now.

Nick



Nick Whitelegg
Senior Lecturer in Computing (Internet)  | School of Media Arts and Technology
Southampton Solent University  | RM424 | East Park Terrace | Southampton SO14 
0YN
T: 023 8201 3075 | E: 
nick.whitel...@solent.ac.uk | W: 
solent.ac.uk

Disclaimer

From: Andy Townsend 
Sent: 11 December 2020 13:40
To: talk-gb@openstreetmap.org 
Subject: Re: [Talk-GB] Idea - OSMUK walkers' map application -- -& server



On 11/12/2020 09:59, Nick Whitelegg via Talk-GB wrote:

In the early stages I think we could run it on cheap hosting hardware, like 
most projects in the OSM ecosystem. I suspect for a while usage would be light 
and limited to those in the OSM community. I use Hetzner for my hosting 
(OpenTrailView, Hikar, MapThePaths) - I pay around EUR 19/month but that is for 
a larger system that has to deal with the whole of Europe rather than just the 
UK.

 

Re: [OSM-ja] CC0データのインポート(GTFSデータ)

[下り専門]

下り専門です。

念のため、データ提供元に作成方法も問い合わせてみたいですね。
Google Maps を参照して作成されていたら使えないですよね。

stops.txt だけだったら↓これで変換できるかも。
https://github.com/kudarisenmon/gtfs-osm-converter


2020年12月14日(月) 16:23 OKADA Tsuneo :
>
> 岡田です。
>
> いいださん、コメントありがとうございます。
>
> 私の言葉が少し足りていませんでしたが、「データ提供元への追加了承は不要ですよね？」
> という意味での質問でした。
> いいださんに示していただいたOSM側の手順については認識しておりますので、
> 大丈夫です。
>
> 私の場合インポート用のデータを作成するのが一番大変そうです。。
> (QGISを触ってみるところから？)
>
>
> 2020年12月14日(月) 12:25 Satoshi IIDA :
>>
>> いいだです。
>>
>> > CC0で公開のデータについてはインポートしても問題ないという認識で良いでしょうか？
>> いいえ、残念ながら、ライセンスの互換性だけでは、インポートの作業を行うことはできません。
>> インポート作業を行うためには、インポートガイドラインに従い、
>> 必要な情報（ライセンス、作業方法、作業責任者の情報など）をまとめた上で、
>> その地域ローカル（日本だと、このtalk-jaメーリングリスト）と、
>> 全世界のImportsメーリングリストで合意を得る必要があります。
>>
>> インポートガイドライン: 
>> https://wiki.openstreetmap.org/wiki/JA:%E3%82%A4%E3%83%B3%E3%83%9D%E3%83%BC%E3%83%88/%E3%82%AC%E3%82%A4%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3
>> 書き方の例（位置参照情報）: 
>> https://wiki.openstreetmap.org/wiki/MLIT_ISJ/import2019_outline
>>
>> 先日、MIERUNEさんからQGISでGTFSを読み込むプラグインが公開され、
>> OSMで使える形式への変換も楽になってきていると思うので、
>> もし進められると嬉しいですね。
>> （CC0で追加了承を得る手間が無いのも素晴らしいです！）
>>
>>
>>
>> 2020年12月13日(日) 20:49 OKADA Tsuneo :
>>>
>>> 岡田です。
>>>
>>> データのインポートについて確認です。
>>>
>>> バス会社のGTFSデータでいくつか、CC0のライセンスのものがあります。
>>> (富山県、山梨県、岡山県などの一部の会社)
>>>
>>> CC0で公開のデータについてはインポートしても問題ないという認識で良いでしょうか？
>>>
>>> --
>>> 岡田常雄(OKADA Tsuneo)
>>> tsuneo.ok...@gmail.com
>>> ___
>>> 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
>
>
>
> --
> 岡田常雄(OKADA Tsuneo)
> tsuneo.ok...@gmail.com
> ___
> 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] Usages des cartes IGN pour contribuer à OSM [était : Évolution de l'IGN, ouverture de données

[Adrien Carpentier]

Hello

> Mince, je confonds. Avec quoi, je ne sais plus.
>
Peut-être la convention BAN : IGN, Etalab, la Poste et OSM de 2014?
https://www.lemonde.fr/blog/data/2014/11/14/base-dadresse-union-de-raison-entre-lign-et-openstreetmap/
++
Adrien
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] un début de OSM - mon commerce

[Marc_marc]

Bonjour,

> Le 14 déc. 2020 à 11:40, Baptiste Lemoine - Cipher Bliss 
>  a écrit :
> 
> avec un nom temporaire "bizOSM"

puis-je suggérer d'améliorer les outils existant (par ex OsmMyBiz) au lieu de 
refaire une nouvelle rue depuis zéro ?
Je suis un peu dépité quand je renseigne osm a un commerçant de devoir lui 
renseigner 3 roues incomplètes au lieu d'un écosystème intégré.
la liste de souhait a été évoqué ici et sur là ml aussi cette année 

Cordialement,
Marc



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Creazione di un Diversity and Inclusion Group in OSM Italia

[Vittorio Bertola via Talk-it]

Il 2020-12-13 09:17 Francesco Ansanelli ha scritto:

> Ciao, 
> 
> sono in parte d'accordo con Martin... 
> Seguo da circa 2 anni talk-it e non mi sembra di ricordare episodi di 
> discriminazione (in particolare di genere). Quindi auspico di capire se si 
> tratta di un'attività "di contorno" (non vorrei essere frainteso ma CoC, 
> linguaggio inclusivo, gruppi LGBTQ, ecc.. sono stati una moda tra i progetti 
> open source nell'ultimo anno) oppure se ci sono state davvero frasi di odio 
> per l'appartenenza a minoranze? 
> Credo di parlare a nome di tutti, se dico che è benvenuto/a nella comunità 
> chiunque voglia farne parte e lo/la invito a condividere anche qui le sue 
> esperienze.

Aggiungo i miei 2 cent: partecipo regolarmente alla IETF e mesi fa c'è
stata una flame infinita quando la Chair e un gruppetto di attivisti di
alcune NGO per i diritti digitali hanno cercato di far passare
d'autorità il divieto di utilizzare nelle RFC determinati termini
ritenuti offensivi per gli afroamericani (master/slave ecc.). Alle prime
obiezioni del tutto naturali, tipo "come facciamo con i vecchi standard
già pubblicati o con il resto dell'industria che usa questi termini",
oppure "perché proprio queste parole e non altre che possono essere
offensive per altre etnie" (io avevo chiesto di aggiungere all'elenco
"spaghetti code"...), o semplicemente dubbi sull'uso di una procedura
straordinaria dall'alto per questo specifico atto, sono partite dai
proponenti accuse di insensibilità e razzismo, blog post "vergogna IETF"
sui siti delle NGO e così via, e la discussione è abbastanza degenerata;
il tutto per un processo di pulizia del linguaggio che per fortuna sta
già silenziosamente avvenendo di suo, senza la necessità di formalizzare
piani d'azione e direttive. Insomma, in quel caso le buone intenzioni
hanno finito per essere controproducenti. 

Del resto, personalmente ritengo che fare un gruppo a parte solo di
partecipanti di minoranze può essere utile in certi contesti, ma in
altri può avere il risultato di creare e rafforzare divisioni che
altrimenti non sarebbero nemmeno percepite. 

Quindi sarebbe utile capire se, anche inconsapevolmente, ci sono stati
episodi di discriminazione in questa comunità, in modo da affrontare il
problema in concreto, o se lo sbilanciamento di genere nella
partecipazione è solo un effetto dello sbilanciamento generale nel
settore professionale dell'informatica, su cui bisogna agire (e lo si
sta facendo) a ben altri livelli. 

Ciao, 

-- 
vb.   Vittorio Bertola - vb [a] bertola.eu   <
>now blogging & more at http://bertola.eu/   <___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [talk-cz] Zdroj názvů ulic

[Jan Dudík]

Registr je fajn věc na určení, zda se ulice jmenuje Dvořákova, A. Dvořáka,
Ant. Dvořáka, Antonína Dvořáka nebo Bedřicha Smetany či Aloise Dvořáka.
Ale OTG je zase k určení toho, jestli ten kousek mezi Petrovičovou,
Dvořákovou a Lidickou je součást některé z těch tří nebo je to nějaká
čtvrtá...
https://www.openstreetmap.org/query?lat=49.78325=14.17166

JAnD



po 14. 12. 2020 v 11:21 odesílatel Michal Fabík 
napsal:

> On 12/13/20 4:42 PM, Jan Martinec wrote:
>
> Ahoj, autoritativní je OTGR.
>
> Co je na ceduli? ;)
>
>
> Ahoj,
> s přístupem "co je na ceduli" jsem jednou docela tvrdě narazil, protože na
> ceduli může být třeba "Masarykova třída" a 100 m dál "Masarykova tř."
> prostě proto, že na příslušné místo se dost velká cedule nevešla. Případně
> na ceduli můžou být třeba různé pravopisné/typografické chyby
> ("T.G.Masaryka" místo "T. G. Masaryka" apod.). Směrodatný by prý měl být
> registr ulic v podobě nějaké místní vyhlášky nebo podobného předpisu
> (netuším, jak se to správně jmenuje).
>
> --
> Michal Fabík
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-GB] Tagging bike ramp/ bike path down steps

[Simon Still]

> On 13 Dec 2020, at 19:18, Edward Catmur via Talk-GB 
>  wrote:
> On Sun, 13 Dec 2020, 19:14 David Woolley,  > wrote:
> On 13/12/2020 19:05, Edward Catmur via Talk-GB wrote:
> > Also, the steps should have bicycle=dismount, not =yes. This will allow 
> > people who can't dismount to go around by the road.
> 
> Only if it is illegal to try to cycle up and down the steps.  Otherwise 
> it is the duty of the renderer (router) to infer that this will be 
> necessary because of the steps.
> 
> The sign visible on Mapillary says (white on blue) "Steps ahead cyclists 
> dismount". That seems pretty clear to me. 
> 


White on Blue ‘cyclists dismount’ signs are only advisory.  It may be foolish 
to cycle down (or up) the steps but it’s not illegal.


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [talk-cz] Zdroj názvů ulic

[petr . kadlec]

> s přístupem "co je na ceduli" jsem jednou docela tvrdě narazil, protože na
> ceduli může být třeba "Masarykova třída" a 100 m dál "Masarykova tř."
> prostě proto, že na příslušné místo se dost velká cedule nevešla. Případně
> na ceduli můžou být třeba různé pravopisné/typografické chyby
> ("T.G.Masaryka" místo "T. G. Masaryka" apod.). Směrodatný by prý měl být
> registr ulic v podobě nějaké místní vyhlášky nebo podobného předpisu
> (netuším, jak se to správně jmenuje).
>

Tak jasně, pro takovéhle nuance (o tom, že velikost písmen na tabuli ani
nepoznám) je lepší dohledat v nějakém autoritativním zdroji (anebo taky v
příručkách pravopisu), ale to, na které křižovatce je rozhraní dvou ulic,
je opravdu lepší OTG než oficiální registr (i když by to pochopitelně mělo
být vždycky stejné, což v tomhle případě i je, takže pohoda jazz). Třeba
proto, že je vcelku podstatnou funkcí mapy, abych se s ní zorientoval v
terénu; třeba když někoho budu navigovat a řeknu mu „z ulice X odboč do
ulice Y“ a on projede ulici X pětkrát tam a zpátky a ulice Y z ní nikde
neodbočuje, protože OTG vznikne ulice Y až na vedlejší křižovatce, zatímco
u ulice X je ještě značená jako Z…

-- Petr Kadlec / Mormegil
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] Usages des cartes IGN pour contribuer à OSM [était : Évolution de l'IGN, ouverture de données

[Vincent Bergeot]

Bonjour,

Le 13/12/2020 à 18:12, Marc_marc a écrit :

Le 13.12.20 à 18:07, Vincent de Château-Thierry a écrit :

La seule convention en vigueur actuellement entre OSM-Fr et l'IGN date
de juin 2019

elle devient vide de contenu réel non ?
puisque son intérêt pour osm était d'avoir accès à la BDOrtho


pour les contributeurs OSM, je suis d'accord.

Cependant pour OSM-France (dans le cadre de son soutien du projet OSM, 
visibilité du projet, local chapter, relais, organisation des sotm-fr, 
) avoir une convention avec l'IGN ne concerne pas QUE la bd ortho, 
c'est bien aussi du réseau, du lobbying, de faire caisse de résonance, 
de montrer quelques trucs qui se font en dehors de l'IGN



qui ne sera plus restraint dans 19j.
après reste l'excuse de s'en servir pour faire du réseau...


OSM-fr ne cherche pas d'excuses pour faire du réseau (je parle bien de 
l'association osm-fr car la convention est entre osm-fr et l'IGN). Au 
contraire même il me semble qu'OSM-fr revendique faire du 
réseau-lobbying pour donner à voir le projet OSM, montrer les possibles. 
Quand l'IGN  demande à OSM-fr son avis sur la future géoplateforme, que 
nous nous étonnons qu'il n'y ait pas davantage d'OSM, voire un serveur 
overpass, voire des rendus de tuiles ... c'est bien du réseau-lobbying 
pour faire avancer ce qui est l'objet social même d'osm-fr.


my2cents


--
Vincent Bergeot


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] un début de OSM - mon commerce

[Baptiste Lemoine - Cipher Bliss]

Bonjour,
hier avec quelques contributeurs sur le canal osm-fr telegram/riot on s'est 
lancés dans l'ébauche d'une version OSM pour que les commerçants puissent 
renseigner des informations de leur commerce, un peu à la façon ça reste 
ouvert, inspiré par onosm.org.

on s'est créé une équipe sur Framateam avec un nom temporaire "bizOSM" pour en 
discuter, et on a ébauché des propositions sur un pad fourni par Cquest:

Le géocodeur addok a été enrichi et trouve maintenant des points d'intérêt par 
SIREN et SIRET. l'idéal serait bien entendu de pouvoir prendre rdv pour voir 
comment on organise ça de façon structurée.
Je vous invite à discuter de tout ça sur le framateam si vous souhaitez y 
contribuer https://framateam.org/bizosm/channels/town-square

Baptiste LEMOINE  - tykayn - Dirigeant de Cipher Bliss.com ,
---
Tel 0185461173  / Signal 0627130837 , Telegram: Tykayn , Mastodon: @tykayn, 
Riot: @tykaynchu:matrix.org N° SIRET: 79942416300035 GPG: 64A8 9B18 65E6 6523 
FD86 7CB5 8796 1FCA F978 54FF clé Duniter / Ğ1: 
8c4mVVPAHd4yLYcxWM4U8Z3zUb4WpRX1iGtX5T7tbEFE - tykayn

Sent with ProtonMail Secure Email.

signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-cz] Zdroj názvů ulic

[Michal Fabík]

 On 12/13/20 4:42 PM, Jan Martinec wrote:

Ahoj, autoritativní je OTGR.

Co je na ceduli? ;)


Ahoj,
s přístupem "co je na ceduli" jsem jednou docela tvrdě narazil, protože na
ceduli může být třeba "Masarykova třída" a 100 m dál "Masarykova tř."
prostě proto, že na příslušné místo se dost velká cedule nevešla. Případně
na ceduli můžou být třeba různé pravopisné/typografické chyby
("T.G.Masaryka" místo "T. G. Masaryka" apod.). Směrodatný by prý měl být
registr ulic v podobě nějaké místní vyhlášky nebo podobného předpisu
(netuším, jak se to správně jmenuje).

-- 
Michal Fabík
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz