Planning to map the Bürgerbus line. There are a few stops missing which need a visit to locate them. A rough idea of the line is here.

Доброго времени суток! Сегодня поведаю Вам крайне занимательный рассказ о том, как чудесный город Кривой Рог меняет природу вокруг себя. Речь будет не о тоннах вредных выбросов в атмосферу (хотя менее значимой эта проблема не становится), а о реке Саксагань и том, как её пришлось изменить ради города. Я постараюсь ссылаться на информационные источники, но в основном это будет отсебятина, так как информации об этом крайне мало.

Сам город растянулся в как раз по течению реки Саксагань. С северного раёна и до самого исторического центра, где впадает в реку Ингулец. Тут, в 1775 году, где сливаются две величественных реки, берет начало история Кривого Рога. По одной из версий, а точнее легенде, примерно в том месте проживал некий казак Рог, в честь которого и был назван город.

Время идет и не стоит на месте. Примерно в 1881 голу археологом Полем Александром Николаевичем под городом были обнаружены колоссальные залежи железной руды, Криворожский железорудный бассейн, или же просто Кривбасс. С этого момента начинается активное развитие Кривого Рога,

На данный момент в городе 5 ГОКов, 10 шахт, и масса карьеров, часть из которых уже не функционирует (к примеру, гранитные). Из-за этого Кривой Рог с космоса похож на кляксу. Серое пятно посреди плодородных полей Украины, изувеченное огромными ямами.

И река Саксагань стояла на пути. Крупное месторождение железной руды было обнаружено в как раз в том месте, где текла река. Именно там сейчас расположено 2 карьера - "Южный" и "Северный".

Поэтому было принято решение пустить реку под городом. Так был построен Криворожский деревационный тоннель. Диаметр тоннеля - 3.5 метров. Общая протяженность - 5.2 километра. К вспомогательным сооружениям относятся входной и выходной порталы, ещё один промежуточный портал и 5 вентиляционных спускных шахт. Туннель находится на балансе и обслуживается государственным предприятием "Кривбасспромводоснабжение". Естественное течение реки навсегда было изменено.

И вот теперь история и легенды уже звучат совсем в ином свете. Нет больше слияния рек в историческом центре. Но как быть? Кроме территории нынешних карьеров, к тому моменту река проходила через центральные парки города. Осушить реку было бы катастрофой! Поначалу с этим ничего не делали. Часть реки была стала просто заводью Ингульца. По прошествии некоторого времени у этого были негативные последствия. Так как вода уходила в тупик, по сути, она была стоячей. А стоячая вода со временем начинает цвести и жутко пахнуть. С этим нужно было что-то делать.

Так, посоветовавшись все с тем же "Кривбасспромводоснабжением" было принято решение реку вычистить и построить трубопровод от Карачуновского водохранилища до бывшего русла реки. Таким образом появилась "новая"-старая Саксагань.

Вот такая история.

Очень подробно и много можно найти информации на городских новостных порталах. Там ещё больше ссылок, реальные документы и фото.

Все новости, связанные с этими событиями на 0564

Очень хорошие статьи с фото о входном и выходном порталах.

Спасибо за внимание!

prima di trasferire qui tutto il diario vorrei fare una prova di scrittura e verificare

I wrote an article about OpenStreetMap and its related services and applications

http://jakobmiksch.eu/post/openstreetmap_overview/

Es ist wieder einmal so weit, ein kommerzieller Tile Vermarkter beglückt die Community erneut mit einer Frage. Frage, nicht wirklich, denn diese ist bereits als selbst erfüllenden Prophezeiung formuliert.

"Wir brauchen feste Regeln für die Verwendung von Multipolygnen!"

https://forum.openstreetmap.org/viewtopic.php?id=64439 Es ist nun nicht so, als ob Multipolygone nicht bereits oft genug diskutiert worden wären. Das Ergebnis aus solchen Diskussionen entsprach bislang offensichtlich nicht vollständig den Wünschen der Tile Verwerter. Nun anstatt eigene Probleme mit Multipolygonen zuzugeben, versuchen Tile Vermarkter uns Mappern die selbst gewünschte Lösung durch wiederholtes Nachfragen uns suggestiv unter zuschieben.

In Changeset Diskussionen ist man hingegen nicht ganz so zimperlich, da wird aus einem OSM Wiki "Möglichst vermeiden", Flux ein Nein. https://www.openstreetmap.org/changeset/56911458

Das soll sich nun offensichtlich ändern. Nieder mit den lästigen Multipolygonen. Dass Multipolygone für eine weitere Detaillierung von OSM unerlässlich sind, wird hierbei unter den Tisch gekehrt. Es zählt dass das eigene Produkt grobe bunte Karten Tiles klaglos funktioniert.

Wir Mapper sollen also die Zukunft von OpenStreetMap freiwillig, dem schnellen Kommerz an OSM Tiles verdienenden Firmen Opfern. Ich sage dazu Nein. Karten Tile- Verwerter sollen besser an Ihrem eigenen Renderer arbeiten.

Wir Mappen nicht für deren Renderer. NEIN

Turkmenistan aspires to renewed status as the "hub" or "crossroads" of Central Asia, harkening back to the days of the Great Silk Road that connected Xian in China to Istanbul, Jerusalem, and Antioch, and from there to Rome and beyond. I thus took it upon myself to check out and ensure proper mapping of as much of Turkmenistan's national highway system as I could, and then to check out its border crossings with neighboring countries. They are now all easily identifiable, both national highways and border crossings, I think properly tagged, and in the case of highways, every gas station I could see has been added to the map (still have a few FIXMEs out there, and there are undoubtedly some gas stations I haven't found yet, but...) So far other mappers and I have mapped 156 gas stations in Turkmenistan, up from the very few on the map in 2015. Turkmenistan is ready for higher volumes of motor traffic and has a better road atlas on line to help navigate!

கடந்த முறை ஊர் (அதிராம்பட்டினம்) சென்றிருந்த போது openstreetmap.org ல் நான் தொகுத்த மரங்களின் பட்டியல் (படம்). இன்று இந்த மரங்கள் பல சாய்ந்து விட்டன. நான் வைத்த ஒரு மரத்துடன் இந்த மரஙக்ளும் சாய்ந்தது வருத்தமாக இருக்கிறது. வெறும் மூன்று நாள் விடுமுறையில் சென்றிருந்தும் இவற்றை குறிக்கவேண்டும் என்பதும் எனது பயண நோக்கமாக இருந்தது.

பள்ளிக்குழந்தைகளை வைத்து கணக்கெடுப்பு பயிற்சியுடன் இவற்றை குறிக்க ஒருங்கிணைக்க வேண்டும் என்று விரும்பினேன். (அப்படி ஒரு ஒருங்கிணைப்பு அனுபவம் எல்லாம் இல்லை.)

மரங்களை கணக்கெடுத்து குறிப்பதன் அவசியம் தற்போது இன்னும் அதிகமாகியிருக்கிறது.

எங்குமே இல்லாத வகையில், நமதூரில் குப்பைத் தொட்டிகள், குப்பை சேரும் இடங்களையும் சிலவற்றையும் குறித்திருக்கிறேன். osm ல் சாக்கடை வாய்க்கால், நீர்வழி, தெருவிளக்குகள், மின்மாற்றிகள் என்று சகலத்தையும் குறிக்க முடியும்.

நேற்றைய கஜா புயலில் பிரபலான windy.com தளத்தின் base openstreetmap.org என்பது குறிப்பிடத்தக்கது.

பேரிடர் காலங்களில் நுட்ப வசதிகளை பயன்படுத்துவது அதிகரித்து வருகிறது. hotosm.org போன்ற தளங்கள் இவற்றிற்கு உதவுகின்றன. கஜா புயல் பாதித்த பகுதிகளைக் கூட்டாக தொகுக்க Task manager ல் ஆக்டிவேட் செய்ய கோரியிருக்கிறேன். அவ்வாறு அங்கு வரும் பட்சத்தில் உலகம் முழுவதும் உள்ள தன்னார்வலர்கள் தொகுப்பார்கள்.

இந்த தொகுத்தலில் ஆர்வமிருப்பவர்கள், ஐபோன் வைத்திருப்பவர்கள் "Go Map" App download செய்து தொகுத்தலைத் துவங்கலாம். கணினி வழியே உலாவியில் நேரடியாகவும் தொகுக்கலாம். நுட்ப அறிவுள்ளவர்கள், JOSM எனும் கருவியை தரவிறக்கி தொகுக்கலாம்.

இந்த தளத்தை மற்றும் கருவிகளின் தமிழாக்கம் செய்யும் முயற்சியும் ஒருபுறம் நடக்கிறது. இவற்றிலும் நீங்கள் பங்கெடுக்கலாம். * https://transifex.com/openstreetmap/id-editor/ * https://translations.launchpad.net/josm

புயல் பாதித்த எனது ஊர் அதிராம்பட்டினத்தின் வரைபடம் https://www.openstreetmap.org/way/425908820#map=15/10.3433/79.3824

We started a new meet-up about OpenStreetMap and other geo-related topics. Check our blog post: http://maptime.io/salzburg/event/2018/11/13/Stammtisch/

Dona a OpenStreetMap Colombia

La respuesta es que sí, es necesario que diferentes grupos se den a la tarea de instalar y mantener infraestructura propia para diferentes ejercicios, en el caso de Colombia, desde hace más de 4 años decidimos tener nuestra propia instancia de UMAP, El Servidor de Tareas, Un TMS propio y desde hace poco un StaticMap.

Esta infraestructura tiene un costo que hemos mantenido año tras año con donaciones y con el trabajo de varias personas, finalizando este año queremos pedir la ayuda de la comunidad de OSM para que nos ayuden a recoger no más de 2000 mil dolares para pagar esta infraestructura por otros dos años y poder seguir soportandola, creamos la siguiente campaña para donaciones

Servicios resilentes

Una de las fortalezas de los proyectos de Cultura Libre, Software libres, Datos abiertos etc es que su infraestructura sea resilente y que pueda ser replicable de manera sencilla, esta apuesta aunque es difícil OpenStreetMap y Wikipedia son una muestra de lo que se puede lograr cuando el código es 100% abierto, pensando en esto desde OpenStreetMap Colombia siempre hemos pensando que parte de lo que nos puede ayudar a crear datos abiertos de nuestros territorios es poder tener nuestras propias infraestructuras para gestionar el trabajo que realizamos por un lado para no depender de las jerarquías de otros usos horarios y poder utilizar las diferentes plataformas con las dinámicas de las comunidades locales, en este caso desde Colombia le apostamos a que las plataformas que mantenemos como el servidor de tareas y el UMAP lo use todo Latam y esto es algo que ha pasado de forma orgánica a través de los años.

Tener nuestros propios servidor también nos ha permitido crear herramientas propias como Tupale.co que nació como una herramienta para hacer un mapa sobre el conflicto en Medellín y que con el paso de los años la hemos podido proyectar como una herramienta que puede permitir a las comunidades crear su propio sistema de información comunitario geográfico y participativo, utilizando de fondo las tecnologías de OpenStreetMap para georeferenciar, este a su vez es software libre siguiendo la filosofía de los proyectos que apoyamos. Este proyecto también es abierto a toda la comunidad de Latam quienes con solo registrarse pueden crear diferentes aplicaciones donde la mayoría son cartografías sociales de diferentes tipos.

Es por eso que pedimos la ayuda de todos, para poder continuar desarrollando herramientas que se adapten a las comunidades con las que trabajamos.

Recuerda donar en el siguiente enlace: Campaña para donaciones

Yesterday was the last OSMF board meeting before this year's Annual General Meeting. And like it is already kind of tradition this last meeting had more visitors listening in than any on the previous meetings and IIRC even more than last years pre-election meeting making it probably the largest board meeting in OSMF history.

And this despite the guests having to wait for half an hour because the board started the meeting with a closed session.

And here is where the surreal part started. The closed part was - as you can read on the meeting agenda - meant to determine if two of the board members (Frederik and Heather) had a conflict of interest regarding the subject of the OSMF organized editing policy or guideline as it is now called. This is because apparently two other board members (Mikel and Martijn) were already considered to have a conflict of interest (and after me asking at the end of the meeting confirmed that they recused themselves). Now we don't know the details yet - no word was uttered by the board in the public part of the meeting about the outcome of the closed part of the meeting (did i already mention it was surreal?). We know that apparently Frederik and Heather were not determined to have a conflict of interest because they participated in the vote later. But we don't know who decided this and we don't know who decided that those who had a conflict of interest were allowed to participate in the discussion none the less.

The most amazing thing however is that this discussion and decision if there is a CoI for the various board members happened literally just minutes before the decision on the matter and not years ago when the whole process to develop an OSMF policy was started. And as if to rub in everyone's face that to fully participate in and influence the whole process from within the board despite an obvious conflict of interest is apparently no problem in today's OSMF Mikel essentially kicked off the public part of the meeting (after approval of the minutes from the last one and a few minor other things) by criticizing about the new organized editing policy draft (that i strongly criticized as being whitewashed and essentially mostly free of any hard requirements) that (and i obviously paraphrase here) the data working group should not have the right to sanction corporations for not doing what the policy requires them to do - specifically using as an example the requirement to document their organized activities on permanently available OSMF platforms (the wiki) rather than channels they control and can delete as they like (like github). The audacity of this is simply mind-boggling - both in substance of criticizing the possibility that a mostly toothless policy can potentially be enforced but also in the way of at least from my perspective dropping any pretense to act in the interest of the OpenStreetMap community en large on this matter, which we happen to know through among other things the survey the OSMF made, is to a significant part concerned about organized activities.

Never in the history of the OSMF board meetings - and i have listened in to quite a few of them - have i regretted so much that there is no verbatim transcript of the meetings. As a piece of real-life comedy this was just priceless.

But i am getting carried away. What inevitably followed was the vote on the weakened policy or guideline (it was approved). The punch line was a comment Peter gave with his vote critizing that apparently very recently yet another policy draft was proposed to the board that was apparently written by a mapping company and was discussed by the board. My request after the meeting that this draft be made available to the OSMF members was rejected since the board does not give out details of their internal conversation or documents they receive. But the fact that on a matter of policy making concerning the OSM community the OSMF board discusses specific drafts without making them available to the members or the OSM community is fairly remarkable. The board can obviously not control who sends them drafts for policy documents but they can surely refuse to look at and discuss drafts that cannot be made available to the OSMF members and the OSMF community. That this apparently did not happen is to me a major issue.

I kind of wonder what would happen if someone leaked this ominous draft. Because the only handle agaist making this public would be copyright and this would obviously require someone to claim authorship of said document. And i kind of assume whoever wrote and pitched this to the board does not really want to be associated with it...

After this topic was through everyone was clearly exhausted from the whole performance. The only major other thing discussed was the membership fee waiver program - which was considered to be urgent due to the potential influence of members eligible for voting in the upcoming elections. The discussion of this was quite reasonable and the result fairly acceptable although in total i think the concept of waiving membership fees upon request is not a solution for the overall problem of the lack of proportional representation of the OSM community in the OSMF.

That more or less closed this memorable OSMF board meeting.

Like Heather did in the meeting (she kind of managed to beat me on that) I would like to express thanks to Martijn and Peter for their work on the board - neither of who apparently re-runs in the upcoming elections.

Hoje venho trazer pra vocês um tutorial do Java Openstreetmap - Josm em formato .PDF ou .odt para que vocês conheça a ferrramenta de edição do Josm no openstreetmap.

JOSM - Edição Detalhada

Os contribuidores do OpenStreetMap passam muito tempo a editar. Quanto mais você edita, melhor se torna, e mais aprende. Esta secção contém tutoriais que o ajudarão a editar com o JOSM, que é o editor preferido para muitos utilizadores e tem muito mais opções de configuração do que o editor iD.

Primeiro Passo sera esse;

INSTALAR O JOSM

Você pode ter alguns problemas a instalar o JOSM se o Java não estiver já instalado no seu computador. Se tiver problemas, experimente descarregar e instalar o Java. Pode descarregá-lo aqui: página em português - http://www.java.com/pt_BR/ ou página em inglês http://www.java.com/en/download/

Procure o ficheiro de instalação do JOSM que acabou de descarregar. Clique duas vezes rapidamente para iniciar a instalação. Aceite a instalação em Inglês. Clique ‘OK’, ‘Next’, ‘I Agree’, e ‘Install’. Quando a instalação estiver terminada, clique “Finish’ para iniciar o JOSM pela primeira vez. Mais tarde, quando quiser iniciar o JOSM, pode fazê-lo clicando no menu “Iniciar” (ou “Start” na versão em inglês do Windows) no canto inferior esquerdo do seu computador, e escolhendo o JOSM na lista de programas que aparece. Você pode ver uma janela que aparece a perguntar se quer atualizar o programa (em inglês “update the software”). Se tiver acabado de instalar não precisa fazer a atualização porque é o mais recente (mas mais tarde se vir esse aviso, é conveniente ir atualizando para poder dispor de melhorias no programa). Clique no botão que diz “Cancelar”. Se não quiser ver esta mensagem novamente, escolha a opção na parte inferior da janela antes de pressionar “Cancelar” (é recomendável deixar o aviso de disponibilidade de atualização e ir atualizando a aplicação).

Depois de Instalado,

Acesse o site; https://learnosm.org/pt/josm/start-josm/#modificar-a-configura%C3%A7%C3%A3o-do-josm e faça a configuração do Josm

Proxímo passo sera acessar esse tutorial, https://learnosm.org/pt/josm/editing-with-josm/

Tutorial em Formato .PDF https://learnosm.org/files/beginner_start-osm_pt.pdf

Baixe o Arquivo em Formato .odt https://learnosm.org/files/beginner_id-editor_pt.odt

Tutorial do Josm no Guia Osm BR. http://cms.guiaosmbr.webnode.com/l/iniciacao-ao-josm/

Fonte: https://learnosm.org/pt/josm/start-josm/

Entre no Site do Learnosm; - https://learnosm.org/pt/josm/

• https://learnosm.org/pt/josm/start-josm/

• https://learnosm.org/pt/josm/editing-with-josm/

• https://learnosm.org/pt/josm/aerial-imagery/

• https://learnosm.org/pt/coordination/

Raphaelmirc Recife/PE. http://cms.guiaosmbr.webnode.com

Added details to Phila. NE Airport KPNE from FAA airport chart 00528AD

OSMの検索はちょっと癖のある仕様になっているっぽいのでメモ代わりに　チェーン店をいくつか検索する中で気づいたこと

検索（Nominatim）の仕様について

1
基本的に最寄りの通り(street)のから住所を拾ってくる形式になっているため、通りがcityを跨いでいる場合に他の市町村の住所が表示されることがあり、正しい住所で検索に引っかからない

2
branchタグを用いたチェーン店の記法（支店名をbranchタグに記述する方法）は検索結果には表示されないし引っかからない
wikiの説明にあるスマホアプリのOsmAndが調べた中で本家web等で全てのタグを見る以外で表示してくれる唯一の環境だったが、このアプリを使っても検索には引っかからない
JA:Key:branch - OpenStreetMap Wiki

3
そうなると支店名で調べられないため、他の方法に頼るしか無くなるが、Nominatimはaddr:city、street、housenumberしか拾わない為、町名から検索するにはノードにaddr:quarterタグを付加してもダメで、町全体にアドミンレベルのリレーションを書いて判別させなければならない
Nominatim/FAQ - OpenStreetMap Wiki
Nominatim/Development overview - OpenStreetMap Wiki

4
ファジー検索が効かないため、町名も俗称や大まかな地域名だとダメ、近くのPOI（複合商業施設名など）を入れてもダメ 、というか入れる方がダメで1件もヒットしなくなる

5
郵便番号（addr:postcode）は住所判別に用いるランクが高く設定されているものの、入力しても勝手に住所を補完してくれるわけでは無い

6
ポリゴンやリレーションで町や大字に相当するquarterや、丁目に相当するneighbourhoodが囲われている場合で、近くのstreetの所属がNominatimに正しく判別されている場合は正確に表示される
　正しい例
　　ノード: ‪サブウェイ‬ (‪1932711044‬) | OpenStreetMap
　　　ノードに対しaddrタグを設定していなくても、区の境界を跨いでいる日比谷通りから自動で住所を拾い、千代田区内幸町二丁目だと正しく表示され、千代田区と港区の両方でヒットする
　間違いの例
　　ノード: 4367781989 | OpenStreetMap
　　　addrタグが登録されておらず、正しい住所は千代田区東神田町にあり、町のリレーションも作られその中にノードがあるが、区の境界を跨いでいる清洲橋通りがNominatim上で中央区の住所に判別されている為、住所表示は中央区東神田となり、千代田区と中央区の両方でヒットする

おそらくstreetに付与される情報として、Nominatimが隣接する区を冗長的にノードの住所としても検索結果に出るようにしているっぽい
　行政境界を跨いでいるウェイがどの基準でどちらの所属になるよう判別されるのかは不明
　　始点の位置や経由するノードの数？
Nominatimの個別ページに行くと黒字の住所（多くの場合タグで登録したもの）と、そうでないのにグレーアウトして表示されている住所がある
　OpenStreetMap Nominatim: Search 日比谷通り
　　黒字で千代田区に加えグレーで港区の表示もされている
　OpenStreetMap Nominatim: Search サブウェイ
　　ノードにaddrタグは付加されていないが、日比谷通りのものと同じ情報が付加されている　内幸町と内幸町二丁目のページには港区のグレー表示は無い

解決策

市区町村(quarterやcity)の行政境界を描く　
　アドミンレベルのリレーションでなければ住所には反映されない？
　　問題点
　　　行政境界を調べられる公式かつ著作権フリーの情報源が見つからない
　　　マップ編集時に行政境界と道路を兼ねているウェイを見分けるのが難しい（背景をOSM表示に切り替え、既存のウェイの描画を消す必要がある）

通りを行政区画を跨ぐ度に分ける
　通りから住所表記を拾ってるらしい以上検索に出る住所表記を直すのには必須で、簡単かつ確実ではあるが表示が冗長化しそう

他のnameタグを使って補完する
　表記や俗称についてはalt_name、short_name、loc_name、reg_nameなどを使えば解決できる場合もあるか？
JA:名称 - OpenStreetMap Wiki

operatorタグ
　operatorタグもNominatimに反映されるが、検索の役には立ちづらい？誤った用法だと見受けられるものが多い（ショッピングモールの中のチェーン店のoperatorとしてモールの名称を付与している）のが気になる
JA:Key:operator - OpenStreetMap Wiki

モール
　モール（複合商業施設）についてはIndoor mappingなどがあるようだが、検索に反映されるようなものでは無さそう
JA:Tag:shop=mall - OpenStreetMap Wiki

There are problems with level=* tag stemming from the fact that not all mappers agree on what it means. This problem comes up more often in some geographic areas than in others where different floor numbering traditions exist. In this sense it is like name=* tag where certain parts of a name stop looking like parts of a name after being translated into a different language.

So what are exactly the problems with level=*? Some people think that the value of this tag should be whatever floor number that is used in place. You can usually but not always read it off some plaque, floor plan or elevator button. Other people think that the value should be a number such that the first floor at or above the ground level gets number 0, the floor above it gets 1 and so on. Those two different ways of assigning a value could be exactly the same, especially for English-speaking areas where they have a "ground floor" as level=0 and a "first floor" as level=1. If you are from those places, you may not even understand that there's a problem. If you are from a place like Russia or the US, it's evident for you that those ways are different. I'll be using Russia as an example because it's where I map.

But there should be no debate about the exact definition of level=* tag because we have a wiki where it's perfectly documented, right? Not quite. First of all, we don't have one wiki, we have multiple wikis in different languages. Those languages may correspond to areas with different floor numbering traditions, which in turn affects the wiki contents. Again, this is like name=*, where local wiki editors put their preferred spin on what should and what should not be part of a name.

Even if we stick to English wiki, we still won't avoid the problems with its current contents. You may get different impression on what level=* actually means depending on where you start and where you end reading the page, and also whether you follow the links to certain other pages or not. In fact, since I mentioned other pages, how do you know which wiki page you have to read in the first place? You may think that it's obviously Key:level, but that page disagrees with you, sending you elsewhere for further information. You may also remember building:min_level=* tag which also takes on level as a value. Or is it a different level? Is there a definition of level that exists independently of particular tags?

What can those disagreements lead to? We can look at this from the point of view of a data user and of a data editor. For a user, let's say you want to get to a POI which is inside a building. You look it up in some app, for example OsmAnd, and the app would tell you which floor the POI is on. So you see among other things about the POI something like "Floor: 1". Actually, OsmAnd will say "Level: 1", but that's going to happen if you have English interface. In Russian it's going to be "Этаж" which is literally a floor. At this point we can remember what happens to the wikis in different languages and look at this as an attempt to bolster a particular interpretation of level=* through localization. I'm talking about level tag because the number you see in the app comes from this tag. As a user, you may not know anything about tags and possible differences in their interpretations. Your most likely interpretation of the number you see is going to be that it's a floor number, a designation of a floor inside the building, which is either evident from local traditions or directly written somewhere. You are unlikely to attempt to determine level zero and then count the specified number of levels upwards. In fact, this counting operation may seem unnecessarily complicated and even nonsensical, which looks like a good argument to just use the self-evident floor number as a value of level tag. With this assumption you'll only get the correct floor number if the last editor of level tag on the particular POI shares this opinion. If not, in Russia you'll most likely end one level below the POI. Sometimes it'll be two levels. It's going to happen when "first floor" is slightly below the ground. In some cases the level will coincide with the floor number even under this "counting" interpretation, but you wouldn't know that in advance.

What are the problems for editors? Obviously, different people may want different values for the same tag on the same object. This may lead to edit wars. You may then propose to keep whatever level numbering scheme already exists in a certain building and make everyone follow this scheme. Unfortunately this is not always possible. In order to know what scheme is in place you have to find stuff that is already mapped with level tag and figure out what scheme it corresponds to. There's a chance that no single scheme would fit because different things were mapped by people with different opinions. This is likely to happen if there are many elements tagged with level. On the other hand there could be few and you wouldn't notice them. All this scheme guessing has to be done because nobody indicates what scheme is to be followed at a particular place. Nobody indicates that because according to most mappers there's only one right scheme and other schemes shouldn't exist.

Even if you know the scheme, you can find yourself in a situation where you have to change already existing level values. For example, you may tag all of the POIs along a street in one manner and eventually you get to a place that was mapped differently. Do you stop and change your way starting with this place? Do you go back and retag everything you already have entered? If you have entered a lot and there's only a few things mapped differently, it makes more sense to retag those few things.

Of course having two different interpretations of one tag is inconvenient. We are better off with just one that makes more sense and is easier to use. And we already know which one it is. Just write the local traditional floor number, you can always check it on place, you don't need to figure out where's **level zero, you don't need to count floors, you don't need to follow the rules made up by foreigners who don't know how things work in your country. That's how people who prefer this particular scheme think, however there are reasons to think otherwise.

That other way of thinking goes as follows. We had the definition of level that has 0 assigned to the first level above the ground level for at least seven years. This definition is used in Simple 3D buildings (S3DB) for about as long. All of the software that uses S3DB data relies on this definition. It would be inconvenient to come up with another "indoor" level numbering scheme. It may not even be a numbering because floors can be designated by letters and then you wouldn't know the vertical order of levels without extra data. Even some of software that mainly concerned with indoor visualizations like OpenLevelUp assumes 0-based numbering. So there is only one scheme that works, it's been around for a long time, and it's how it defined in the wiki. That last statement about the wiki is a bit of a wishful thinking done by the proponents of this scheme.

Those were the ideas behind the two major level numbering schemes: locally-defined labeling (it's may not be strictly numbering) and 0-based numbering. As you can see, the proponents of these schemes can be pretty convinced that their scheme is the correct one and they want the level tag for themselves. In addition you can come up with many more schemes. For example, you may want 1-based numbering where you say that those who think that ground floor and first floor are two different floors got their traditions wrong and have to adapt to 1-based counting because all normal people count from one.

One noteworthy scheme lies between the two major ones. A scheme that we'll call locally-based numbering attempts to fix some issues with locally-defined labeling. It uses only numbers that make the vertical level sequence well-defined. For this scheme you replace all non-numeric level labels with numbers. For example, if a building had level K below level 0, like described in this comment, you replace K with -1. Usually it's the same as matching the number sequence ..., -2, -1, 0, 1, 2, ... as close as possible with all numeric labels. In this case the result is usually going to be the same as picking either 0-based or 1-based numbering, whatever fits best.

There's one extra quirk that is skipped levels. Imagine a 100-storey building without 13th floor. The best match with the sequence would involve setting level=2 for 1st floor, level=3 for 2nd and so on until 12th floor. This is not what people typically want to do so it's fixed by extra hack. This hack can be added to any of the numbering schemes mentioned above. It consists of declaring some of levels as non existent and their numbers are thrown out of the sequence before it's matched with numeric labels. It also makes level numbers incompatible with S3DB levels, in case you use it with 0-based numbering.

For places like Russia, no matter what scheme you pick, you lose either compatibility with existing tools or traditional floor numbers, maybe both. Losing traditional numbers is particularly annoying because you have to use numbers that are almost always one off and it's easy to make mistakes because of that. I think that compatibility with tools is the main divide here. Those who use S3DB want to see the visualizations with tools that assume 0-based numbering. After a while they get somewhat comfortable with that scheme and are more likely to stick with it for other things. Those who don't use S3DB see 0-based numbering as something alien.

How prevalent are the problems described here, are they worth your attention? In the place I map, Saint Petersburg, Russia, both main schemes are in use. That means you can't rely on levels displayed by apps like OsmAnd. I've seen levels changed from one scheme to another when next user comes to edit elements with existing level tags. I had to do it myself too, in the situations I described above. Now I mostly avoid the buildings such as malls that are mapped using the other scheme, but eventually I'll have to do something about them. I haven't yet seen full-blown edit wars over level values, however currently there's nothing that would stop one from happening.

What's to be done about it? You can do something about the editing apps, the end-user apps and the tagging conventions with their documentation. That last thing is going to be the subject of another post, but I can tell right away what can be done with the editors even if we don't agree on the exact meaning of level tag. This is for editors with indoor mode such as Vespucci. In this mode you don't have to enter the level values directly, the editor sets them for you. You only have to select the level to be displayed. The level selector can be modified to display some other number instead of the actual level value, or display both actual and altered values alongside each other. The simplest way to specify how to alter the value is to have the level offset option that takes numeric values. For example, with the +1 offset, level=0 would be displayed as 1. A more elaborate options would be required to skip (or insert) certain numbers and replace numbers with letters (or letters with numbers), but the simple offset would solve a lot of problems.

I tried to write this post from neutral point of view without preferring any particular scheme. You can read about my opinion on which scheme is better and which one do I use in my previous post (in Russian). It's quite long, but you only need sections Вертикальная геометрия and Как я маплю. The next thing to be discussed about levels is what exactly the wiki says. I'm going to leave it for another post.

bom dia mapeadores do mundo e do Brasil.

Venho novamente através desse diário convidar a todos para Conhecer e divulgar o Guia OSM BR, um site idealizado para todos os mapeadores e com bastante material para aprendizado, baixar programas e servir de guia para todos os mapeadores.

Acesse o site do Guia Osm BR. https://guiaosmbr.webnode.com

Bom mapeamento a todos e um ótimo final de semana,

Raphaelmirc Recife/PE. https://guiaosmbr.webnode.com

어젯밤부터 방금까지 자동화 편집 행동 강령을 한국어로 번역했습니다.

현재 영어를 기반으로 스페인어, 프랑스어, 포르투갈어 번역본이 있는 상황인데(일본어는 문서만 존재하다시피 함), 여기에 한국어 번역본이 추가된 것에 기쁘게 생각합니다.

사실 한국어를 사용하는 OSM 편집자가 얼마나 된다고 굳이 한국어로 번역해야 하나 하는 생각도 들었는데, 무엇보다 일단 저한테 필요해서 번역했습니다.

한국어 OSM 기여자들에게 도움이 되길 바라며, (그럴 일이 있을지는 모르겠지만) 일본어 번역자에게도 참고 자료로써 쓰일 수 있다면 좋겠습니다.

여담으로, 주간OSM(WeeklyOSM) 번역 작업에도 참여하고 있으니, 많이 봐 주시면 감사하겠습니다. 그리고 이제 알았는데, LearnOSM에 한국어가 표시되네요.

현재 참여하고 있는 번역 작업(자주 하는 순서대로 내림차순)

• 주간OSM(WeeklyOSM) 번역(매주 1번, 금~토)
• LearnOSM 사이트 번역(가끔씩)
• StreetComplete 번역(가끔씩)
• JOSM 프로그램 및 사이트(도움말) 번역(가끔씩)
• OSM 위키 번역(가끔씩)

The OpenStreetMap project is organized on an international level by the OpenStreetMap Foundation, under British law.

Some companies are paying employees to join, and there are rumors that they give voting instructions.

In recent years, the Board has gradually lost its balance. Over-representation of some areas and groups makes it difficult to maintain a balanced and diversity of government action and raises some conflict of interest issues. Therefore, it is important that all kinds of mappers join in to balance things out.

On December 15 there are board elections, and everyone who was a member before November 15 can vote.

489 ballots were cast during the last election. By way of comparison, in the last few days, 17 employees from a single US company have joined. This might not be anything sinister, but it's worrying especially shortly before the board election, and getting the largest amount of OSMF members is the best safeguard of balance.

https://join.osmfoundation.org/normal-membership is the form. It costs £15 (about €17 or $20), it takes 4 minutes, it's important and it's too late in 24 hours. I am a candidate for the board election, but of course you distribute your votes however you want.

Last week there was a small change to the API which means some GPS traces are now returned unordered whereas previously they may have been ordered. This obviously has implications for editors' GPS display. Potlatch 2 now copes with this by doing some basic proximity testing in an attempt to 'reorder' the unordered points, which restores the GPS layer to some degree of sanity.

At the same time, I took the opportunity to fix something that's been bugging me for months. Historically, Potlatch 2 draws all the features crossing the current viewport, and then removes the sprites when they're no longer visible. This is fine except when you pan across a 2000km power line, which takes ages to draw as a dotted line at z19, and bogs down Flash's display performance for evermore. For such large objects, P2 now only draws the on-screen part, which makes it a whole bunch snappier.

I spent some time clarifying the Fox Chase-Newtown branch of the old Reading Company, currently the Fox Chase SEPTA commuter rail branch. It starts at Shady Lane and continues to Country Line Rd. as two separate agreements between SEPTA and Montgomery County. Anticipating a 2019 agreement between SEPTA and the City of Phila. for the section between Rhawn St. and Shady Lane.

Mini abstract

I've found a 600+ rows Bed&Breakfast dataset, available opendata by RAFVG. No geo coordinates. Since hiousenumbers were recently imported from RAFVG dataset, I decided to go for geocoding. To get reliable coordinates I used csvgeocode script attached to nominatim geocoding service. Nominatim requires almost perfect (standardized) odonyms, hence I started openrefine and a reconcile service which comes in a separate jar. Reconcile service needs a csv with authoritative names, which I get from overpass-turbo and some filtering.

Dataset

Bed and Breakfast is a rather new dataset (Oct 17) with more than 600 POIs. Many useful fields such as

• name and operator
• phone
• email
• site
• opening hours
• category (standard, comfort, superior)

Cleaninig data

Such duty has been accomplished by OpenRefine and Reconcilie plugin, connected as a reconciliation service,

In order to standardize messy B&B addresses (entered by B&B operators theirselves) I had to provide Reconcile with an authoritative set of highway names, which I got from overpass-turbo (see Strade d'Italia diary entry).

Geocoder

Just happened for other projects, I choose csvgecode which features pretty simple usage.

Here is a run using mapbox service:

$ csvgeocode input.csv output.csv --handler mapbox --delay 1000 --verbose --url "http://api.tiles.mapbox.com/v4/geocode/mapbox.places/{{INDIRIZZO}},{{CAP}} {{COMUNE}}.json?access_token="

here using nominatim, instead:

$ csvgeocode input.csv output.csv --handler osm --delay 1000 --verbose --url "http://nominatim.openstreetmap.org/search?q={{INDIRIZZO 1}}, {{COMUNE}}&format=json" Rows geocoded: 468
Rows failed: 114
Time elapsed: 879.4 seconds

114 rows not geocoded expose a geocoder problem with apostrophes in city field. Workaround to bypass such not escapable apostrophe is both removing it (ie: Farra d'Isonzo >> Farra disonzo) or use postcode instead. Same problem for address, which only remove solution (ie: San Francesco d'Assisi >> San Francescao dassisi). Of course above edits are for geocoding sake only. Besides, part of "success" geocoding rows could have been geocoded even with missing housenumber, resulting in highway centroid coordinates. To limit these false positives, I had to check which municipality were imported, faceting out rows belonging to municipalities in red

Conflating

Conflation matched just 11 POIs, so If you want to collaborate in B&B import, here you can find the audit map to review mostly new nodes.