Revue des autres blogs (non sélectionnés)

Orientierungshilfe beim Mappen im Ahrtal (berichtigt)

blogs.openstreetmap.org - sam 21 aoû 2021 - 12:14

Moin!

vor einigen Tagen hatte ich einen Link gepostet leider mit Fehler.

Damit dieser nochmal “in Vordergrund geholt wird” hier nochmal

https://lvermkv.maps.arcgis.com/apps/webappviewer/index.html?id=da78a306408441769ff803ec349789bc

Hinweis: Daten sind stets vor Ort zu prüfen, da unbekannt wie aktuell diese noch sind.

Jan

Ein paar Worte zu den Plänen der OSMF zur Verhaltensregulierung

blogs.openstreetmap.org - ven 20 aoû 2021 - 17:22

Die OpenStreetMap Foundation OSMF hat vor kurzem angefangen, Ihre Pläne und Ideen zur Verhaltensregulierung auf Kommunikationskanälen unter Kontrolle der OSMF öffentlich vorzustellen. Und ich habe von mehreren Seiten die Erwartung kommuniziert bekommen, dass ich dazu Stellung nehme - vor dem Hintergrund, dass ich zu dem Thema Verhaltensregeln in OpenStreetMap sowohl ganz grundsätzlich als auch zu konkreten Ideen und den diesen zugrunde liegenden philosophischen Konzepten und Wertvorstellungen schon einiges geschrieben habe.

Ich tue dies hier wie bereits zuvor in meiner Muttersprache, insbesondere um klarzustellen, dass englischen Muttersprachlern zu diesem Thema keine Deutungshoheit über die Begriffe und Argumente zusteht. Eine maschinelle Übersetzung auf Englisch ist unten der Einfachheit halber angefügt, diese ist aber ausdrücklich nicht dafür gedacht, unter der Annahme der Bedeutungsgleichheit gelesen zu werden.

Wer jetzt ähnlich wie beim sogenannten diversity statement vor eineinhalb Jahren eine detaillierte Textkritik erwartet, den muss ich allerdings enttäuschen. Dies liegt zum einen daran, dass die vorgestellten Texte bis jetzt nur Entwürfe darstellen und noch keine offiziellen Regeln der OSMF. Vor allem aber werden diese Dokumente nicht wie das sogenannte diversity statement als allgemeine Regeln und Wertvorstellen für die gesamte OSM-Community präsentiert, sondern als Regeln für zwei Mailinglisten, welche von der OSMF betrieben werden. Wenn eine Gruppe von Aktiven in der OSMF gerne Kommunikationskanäle hätte, auf denen sie sicherstellen können, dass alle Teilnehmer dort und deren Kommunikation ihren kulturellen Werten und Vorstellungen von angemessenem Verhalten entsprechen und Menschen, die dies nicht können oder wollen, dort ausgeschlossen werden, dann ist daran meiner Ansicht nach überhaupt nichts dran auszusetzen. Und eine Kritik daran käme - egal ob sie grundsätzlich ethisch-philosophisch oder subjektiv aus Perspektive einer anderen Kultur mit anderen Werten erfolgt - einer Kulturkritik gleich. Und wenngleich eine solche Kulturkritik denke ich hier durchaus legitim wäre, würde sie vor dem Hintergrund der übergreifenden Frage, wie denn in OpenStreetMap Leute aus verschiedenen Teilen der Welt mit vollkommen unterschiedlichen Wertvorstellungen und sozialen Traditionen gleichberechtigt miteinander kooperieren können, nicht viel zur Sache beitragen.

Dass hier für die Einrichtung solcher kulturspezifischer Kommunikationskanäle existierende Mailinglisten, welche bis jetzt auch für Menschen weit außerhalb dieses Kulturkreises wichtige Funktionen erfüllen, umgewidmet werden sollen, ist natürlich keine besonders freundliche und rücksichtsvolle Vorgehensweise. Aber das ist nichts, womit die weltweite OSM-Community nicht klar käme.

Auch wenn es natürlich auf den ersten Blick recht skurril erscheint, wenn ein Regelwerk der Verhaltenskontrolle, welches als zentrales Element die unbedingte Intoleranz gegenüber bestimmten Verhalten kundtut (also dass bestimmtes Verhalten unbedingt sanktioniert wird unabhängig vor welchem kulturellen und persönlichem Hintergrund und aus welcher Motivation heraus sich jemand so verhält), als Instrument für mehr Vielfalt präsentiert wird, leuchtet dies beim näheren Hinsehen durchaus ein. Die Toleranz gegenüber anderen Kulturen, Werten und Verhaltensweisen, welche für die inter-kulturelle Zusammenarbeit in OpenStreetMap so essentiell ist, bedeutet nämlich letztendlich auch, dass wir diese Toleranz auch gegenüber Menschen aufbieten müssen, die nicht in der Lage oder willens sind, völlig reziprok unsere Andersartigkeit in Verhalten und Kultur gegenüber ihnen zu tolerieren.

Was mir jedoch Sorgen macht ist, dass im Zuge der Planungen für diese verhaltensregulierten Kommunikationskanäle Leute aus der OSMF, welche an diesen Planungen beteiligt sind, in Ihrer Arbeit völlig reflexions- und kritikfrei auf totalitäre Ideen Bezug nehmen. Ich denke hierbei vor allem an die Initiative von Steve Coast von 2010, welche von einem aktuellen OSMF-Vorstands-Mitglied verharmlosend als seems crazy today charakterisiert wird und welche Grundlage aktueller offizieller OSMF-Policy ist (wenngleich diese natürlich weitgehend ohne praktische Bedeutung ist) als auch ohne kritische Diskussion der fragwürdigen Herkunft dieser Konzepte wieder in die geplanten Regeln zur Verhaltensregulierung eingegangen ist. In erheblichem Maße gilt dies jedoch auch für das Ende letzten Jahres veröffentlichte Pampflet, welches in der OSMF ganz selbstverständlich als Grundlage für die Arbeit verwendet wird ohne dass es (zumindest in der Öffentlichkeit) auch nur Ansätze zu einer kritischen Auseinandersetzung mit den dort kommunizierten Ideen gegeben hat.

Vor diesem Hintergrund möchte ich eines noch mal ganz deutlich betonen: OpenStreetMap ist ein soziales Experiment. Die dahinter stehende Idee ist, dass Menschen von überall auf der Welt mit völlig unterschiedlichen persönlichen und kulturellen Hintergründen, die größtenteils aufgrund sprachlicher und anderweitiger Hürden kaum verbal miteinander kommunizieren können, über das gemeinsame Ziel der Sammlung lokalen geographischen Wissens über ihre jeweilige Umgebung gleichberechtigt miteinander kooperieren. Obwohl OpenStreetMap als Daten-Sammlung mittlerweile ohne Zweifel als Erfolg betrachtet werden kann, ist die Frage, ob OpenStreetMap mit der beschriebenen Idee als soziales Projekt erfolgreich ist, noch völlig offen. Wie das Experiment ausgeht, wird maßgeblich davon abhängen, ob die Gesellschaften und Kulturen, aus denen sich OpenStreetMap rekrutiert - und zwar jetzt und in der Zukunft - reif und tolerant genug sind, um die geschilderte gleichberechtigte Zusammenarbeit über kulturelle, sprachliche und persönliche Grenzen hinweg zu ermöglichen.

Im Grunde ist dieser Grundsatz von Toleranz ohne die Bedingung der unmittelbaren Reziprozität (will heißen, dass man Akzeptanz und Respekt gegenüber Andersartigkeit in Werten und Verhalten gegenüber anderen zeigt, unabhängig davon, ob diese im selben Maße Toleranz zeigen) der Kern von dem, was bereits seit den frühen Jahren von OpenStreetMap als assume good faith/intentions zu den wenigen Grundwerten des Projektes gehört.

Schaffen wir es nicht mehrheitlich individuell wie auch kollektiv, diese soziale Reife und Toleranz aufzubringen, dann wird OpenStreetMap als soziales Projekt scheitern. Dies wäre nicht unmittelbar sichtbar, OpenStreetMap als Daten-Sammlung ohne dies geschilderte soziale Komponente der gleichberechtigten kultur-übergreifenden Kooperation könnte natürlich zumindest eine Zeit lang fortbestehen. Aber es wäre dann halt im Grunde nichts anderes als eine Neuauflage der Internationalen Weltkarte im digitalen Zeitalter unter Nutzung von Crowdsourcing - mit ähnlichen kolonialen und kulturimperialistischen Tendenzen und damit langfristig auf dem Weg, vom selben Schicksal ereilt zu werden.

Machine translation in English by deepl.com follows, should not be read under the assumption of semantic equivalence.

A few words about OSMF’s plans for behavioral regulation

The OpenStreetMap Foundation OSMF has recently started to publicly present your plans and ideas for behavior regulation on communication channels under OSMF control. And I have been communicated from several quarters the expectation that I comment on this - against the background that I have already written quite a bit on the subject of behavioral regulation in OpenStreetMap, both quite fundamentally and on specific ideas and the philosophical concepts and values that underlie them.

I do so here, as I have done before, in my native language, especially to make clear that native English speakers have no interpretive authority over the concepts and arguments on this topic. A machine translation in English is added below for convenience, but this is expressly not intended to be read under the assumption of equality of meaning.

However, if you are now expecting a detailed textual critique similar to the so-called diversity statement a year and a half ago, I must disappoint you. On the one hand, this is due to the fact that the presented texts are only drafts so far and not yet official rules of the OSMF. Above all, these documents are not presented as general rules and values for the whole OSM community like the so-called diversity statement, but as rules for two mailing lists which are operated by the OSMF. If a group of active people in the OSMF would like to have communication channels where they can make sure that all participants there and their communication conform to their cultural values and ideas of appropriate behavior, and people who can’t or don’t want to do that are excluded there, then I don’t think there is anything wrong with that at all. And a criticism of this - regardless of whether it is fundamentally ethical-philosophical or subjective from the perspective of another culture with other values - would be tantamount to cultural criticism. And even though such a cultural critique would be legitimate here, it would not contribute much to the overall question of how people from different parts of the world with completely different values and social traditions can cooperate with each other in OpenStreetMap.

The fact that for the establishment of such culture-specific communication channels existing mailing lists, which until now have fulfilled important functions for people far outside this cultural circle, are to be repurposed here, is of course not a particularly friendly and considerate approach. But this is nothing that the worldwide OSM community would not be able to cope with.

Even if it seems quite bizarre at first glance, when a set of rules for behavior control, which as a central element announces the unconditional intolerance of certain behavior (i.e. that certain behavior will be sanctioned regardless of the cultural and personal background and motivation for which someone behaves in such a way), is presented as an instrument for more diversity, this makes sense on closer inspection. Tolerance towards other cultures, values and behaviors, which is so essential for inter-cultural cooperation in OpenStreetMap, ultimately also means that we have to offer this tolerance towards people who are not able or willing to tolerate our difference in behavior and culture towards them in a completely reciprocal way.

What worries me, however, is that in the course of planning for these behavior-regulated communication channels, people from the OSMF who are involved in this planning refer to totalitarian ideas in their work completely without reflection or criticism. I am thinking in particular of Steve Coast’s 2010 initiative, which is belittlingly characterized by a current OSMF board member as seems crazy today and which is the basis of current official OSMF policy (though of course largely without practical significance) as well as having been reincorporated into the planned rules for behavior regulation without critical discussion of the questionable origins of these concepts. To a considerable extent, however, this also applies to the pampflet published at the end of last year, which is quite naturally used as a basis for work in the OSMF without there having been even the beginnings (at least in public) of a critical discussion of the ideas communicated there.

Against this background, I would like to emphasize one thing again very clearly: OpenStreetMap is a social experiment. The idea behind it is that people from all over the world with completely different personal and cultural backgrounds, who for the most part can hardly communicate verbally with each other due to language and other barriers, cooperate with each other on an equal footing over the common goal of collecting local geographic knowledge about their respective surroundings. Although OpenStreetMap as a data collection can now undoubtedly be considered a success, the question of whether OpenStreetMap with the described idea is successful as a social project is still completely open. How the experiment turns out will largely depend on whether the societies and cultures from which OpenStreetMap is recruited - both now and in the future - are mature and tolerant enough to allow the described equal cooperation across cultural, linguistic and personal boundaries.

In essence, this principle of tolerance without the condition of immediate reciprocity (that is, showing acceptance and respect for otherness in values and behavior toward others, regardless of whether they show tolerance to the same degree) is the core of what has been the assume good faith/intentions among the few core values of the project since the early years of OpenStreetMap.

If we do not manage, individually as well as collectively, to bring up this social maturity and tolerance by a majority, then OpenStreetMap will fail as a social project. This would not be immediately visible, OpenStreetMap as a data collection without this described social component of equal cross-cultural cooperation could of course continue at least for a while. But it would then be basically nothing more than a new edition of the International World Map in the digital age using crowdsourcing - with similar colonial and cultural imperialistic tendencies and thus in the long run on the way to be met by the same fate.

Translated with www.DeepL.com/Translator (free version)

Educational Institutes and Schools

blogs.openstreetmap.org - ven 20 aoû 2021 - 12:43

श्री भगवान विद्यालय, बालमटाकळी, तालुका शेवगांव, जिल्हा अहमदनगर. जि.प. प्रा. शाळा, बालमटाकळी, तालुका शेवगांव, जिल्हा अहमदनगर. कर्मवीर एस. एन. हायस्कूल, न्यू बालाजी नगर, औरंगाबाद. Government Polytechnic Aurangabad. Maharashtra College of Engineering, Nilanga Dist. Latur. Swami Ramanand Teerth Marathwada University, Nanded. Maharashtra State Board Of Secondary and Higher Secondary Education, Pune Divisional Board Aurangaabad. अभिनव चित्रशाला, नांदेड। श्री बालंबिका सांस्कृतिक मंडळ बालमटाकळी ता. शेवगाव. महाराष्ट्र राष्ट्रभाषा सभा पुणे। मराठवाडा विज्ञान विकास मंच, औरंगाबाद. श्री शारदा मंदिर कन्या प्रशाला औरंगाबाद. अमानविश्व विद्यालय, औरंगाबाद. मराठवाडा शिक्षण प्रसारक मंडळ. देवगिरी हायस्कूल औरंगाबाद. वेद विज्ञान अनुसंधान संस्था, शिवपुरी अक्कलकोट. महाराणा प्रताप हायस्कूल औरंगाबाद. जगदंबा शिक्षण प्रसारक मंडळ मंठा. सुधाकरराव नाईक हायस्कूल, औरंगाबाद. भ्रष्टाचार विरोधी जन आंदोलन समिती औरंगाबाद. औरंगाबाद जिल्हा यशवंतराव चव्हाण पुण्यतिथी समिती. कर्मवीर श्री शंकरसिंग नाईक हायस्कूल, औरंगाबाद. Directorate of Employment & Self-Employment. Department of Youth Affairs & Sports. Government of India and State Sports Directorates. INDO GERMAN TOOL ROOM, AURANGABAD. The Institution of Engineers (India). ABHINAV VIDYA MANDIR, BHAYANDAR (E), DIST. THANE, MAHARASHTRA. महाराष्ट्र लोकसेवा आयोग. INDIAN ARMY/NAVY, Selection Centre, Bhopal. INDIAN ARMY Selection Centre, Bangalore. कमला नेहरु शिक्षण संस्था, औरंगाबाद. मेहेरसिंग नाईक विद्यालय व कनिष्ठ महाविद्यालय, औरंगाबाद. श्री रंगदास स्वामी शिक्षण विकास मंडळ, आणे.

2021 HOT Staff OSM FIGHT Heavyweight Championship

blogs.openstreetmap.org - ven 20 aoû 2021 - 8:30

At HOT’s ‘all staff meeting’ today, we held live finals of the 2021 HOT Staff OSM FIGHT Heavyweight Championship!

For those that don’t know, OSM Fight is a website that allows two OSM mappers to compete against each other based on a number of different metrics.

We had started a few weeks ago with team ‘group stages’ and then entered a knock out competition phase. Only the semi-final and final were left to play…

It was really fun and included pretend betting and ‘ringside’ interviews with the new champion, “Road Wrestler” ramyaragupathy and the defeated “Changeset Champion” clairedelune

More importantly, it gave us a really good excuse to talk about aspects of OpenStreetMap that don’t come up that much in HOT, especially for staff without experience outside of remote mapping and / or humanitarian mapping…

For example, when interviewing the valiant loser, clairedelune, post-fight, we got to discuss what OSM notes are and how you can see them, add them, resolve them etc…

When interviewing our new heavyweight champion, ramyaragupathy, we asked her how she had mapped in so many different countries and it was a great excuse to talk about MapRoulette and how different tools support different types of contribution.

I have always really loved OSM Fight and this was an interesting and fun way to leverage it to help people explore different aspects of OSM… Highly recommended! (and thanks as always, Pascal Neis :D )

Как я Overpass осваивал и квест в MapRoulette делал

blogs.openstreetmap.org - jeu 19 aoû 2021 - 14:54

У ОСМ в России большая проблема с деревнями. Деревни есть, а домов нет. Раньше были проблемы с космоснимками, а сейчас с этим проблем нет.

В общем озадачился, начал потихоньку обрисовывать дома и столкнулся с некоторыми неудобствами. Визуально искать неотрисованные деревни сложно и велик шанс пропустить их.

Поэтому нужно было создать квест на MapRoulette, чтоб можно было последовательно обрисовывать деревни, а данные можно загрузить с помощью Overpass.

Пришло время осваивать Overpass

В ходе изучения была найдена старая тема на форуме “Overpass API - примеры запросов”. Собственно там и был найден подходящий запрос и немного модифицирован.

Для эксперимента был выбран Хиславичский район Смоленской области. Из-за большой нагрузки приходится ограничиваться областью района.

area ["boundary"="administrative"] ["name"="Хиславичский район"] ->.b; ( node(area.b) ["place"~"hamlet|village|locality"]; )->.c; ( way[building](around.c:500)->.build; ) -> .build; ( node(around.build:100) ["place"~"hamlet|village|locality"]; ) -> .d; (.c; - .d;)->.result; .result out center;

Что делает данный запрос?

Выбираем район и сохраняем в переменную b:

area ["boundary"="administrative"] ["name"="Хиславичский район"] ->.b;

Далее ищем деревни в этой области. Значением locality отмечаются заброшенные деревни, решил тоже выделить чтоб перепроверить.

( node(area.b) ["place"~"hamlet|village|locality"]; )->.c;

Ищу деревни в которых есть обрисованные здания в радиусе 500 метров. К сожалению я не понял как с помощью Overpass написать запрос где наоборот нет зданий.

( way[building](around.c:500)->.build; ) -> .build;

У меня есть набор зданий, но я не знаю как мне найти точку населенного пункта. Придётся делать схожий запрос, но теперь ищем точку НП в радиусе 100 метров от здания и сохраняем в переменную d. 100 метров будут гарантировать что точка деревни точно относится к зданию, а не к ближайшей деревне.

( node(around.build:100) ["place"~"hamlet|village|locality"]; ) -> .d;

Далее беру предыдущий набор всех всех деревень и вычитаю из них деревни в которых мы нашли здания. В result получаем НП у которых нет зданий в 500 метрах.

(.c; - .d;)->.result; .result out center;

https://overpass-turbo.eu/s/19Z8

Выгрузил результат в виде geojson и загрузил в MapRoulette. Встроенный в рулетку Overpass почему-то не справился с запросом. https://maproulette.org/browse/challenges/20454

В MapRoulette есть русский язык и создание квеста достаточно простая процедура.

Из интересного. Нашлась разделенная на две части деревня, у которой здания были нарисованы, но точка стояла между этими половинками, из-за чего она попала в выборку.

Tam Jai Cake

blogs.openstreetmap.org - jeu 19 aoû 2021 - 10:48

ละติจูด 9.10061 ลองติจูด 99.3078

Orientierungshilfe beim Mappen im Ahrtal

blogs.openstreetmap.org - jeu 19 aoû 2021 - 7:16

Moin!

falls sich Mappen in die Region aufmachen habe ich folgende Karte als Ortierungshilfe gefunden: https://lvermkv.maps.arcgis.com/apps/whinweisebappviewer/index.html?id=da78a306408441769ff803ec349789bc

Hinweis: Daten sind stets vor Ort zu prüfen, da unbekannt wie aktuell diese noch sind.

Jan

Я

blogs.openstreetmap.org - mer 18 aoû 2021 - 21:24

Я

راه اندازی و ساخت و تعمیر + بازسازی

blogs.openstreetmap.org - mer 18 aoû 2021 - 13:30

برای بازسازی اشیا معیوب و قیمتی مشاوره همه نوع کار فنی کم هزینه ترین راه و ساخت و طراحی لوازم نایاب باارزش بهینه سازی و طراحی جدید تبدیل به کامپیوتری تبلیغات تحت وطراحی آرم و سایت با ما بصورت رایگان مشاوره بگیرید . 9351511083 2537750939 تماس بگیرید .

"Resmî" İlçe Sınırları Dosyası ve neden resmî olmadığı ile ilgili bir yazı

blogs.openstreetmap.org - mer 18 aoû 2021 - 12:42

Bahis konusu dosyanın bulunduğu adres

Bu dosyaların varlığından Türkiye OSM camiasının duayenlerinden olan ve “Katpatuka” rumuzuyla katkıda bulunan uğraştaşım Roman Bey sayesinde haberim oldu. Onun da benden yine başka bir uğraştaşım olan Nesim Bey sayesinde haberi olmuş. Öncelikle ne kadar okuyup okumayacağınızı bilemesem de ikinize de OSM Türkiye verisine bulunduğunuz büyük katkılardan dolayı minnettar ve müteşekkirim.

Gelelim dosyaya. Dosyada bazı ilçelerin sınırları aşırı tahminî ya da yanlış çizilmiş.

İstanbul

Silivri’nin güneybatıdaki Gümüşyaka tarafından sınırı İBB’nin ve Silivri Belediyesinin kent rehberlerindeki sınırdan farklı. Beylikdüzü’nün Gürpınar tarafı denizin bir kısmını içine alacak şekilde görünüyor. Avcılar’ın Ispartakule kısmı Başakşehir sınırlarına dahil edilmiş görünüyor. Başakşehir ilçe sınırı oldukça yanlış. Başakşehir ilçe olduktan sonra Esenler’den kopan, TEM altındaki kısımları Bağcılar’a verilen askerî alan da Esenler’de bırakılmış. Fatih’in Boğaz ve Marmara kıyıları kara sınırıymışçasına alınmış. Üsküdar’ın Boğaz kıyılarının tamamı, Beykoz’un da bir kısmı kara sınırıymışçasına alınmış.

İzmir

Dikili’nin kuzey sahilleri kare kare çizilmiş. Torbalı’nın batı sınırı biraz yanlış. Bornova ve Buca’nın Kemalpaşa ile olan sınırı; şahsımın da baz aldığı İzmir Büyükşehir Belediyesinin kent rehberindeki sınırlarla ihtilaflı.

Malatya

Bu ildeki bütün ilçe sınırlarını düzelttiğim için yorum yapabileceğim. Söz konusu dosyanın önizlemesinde Malatya’nın ilçe sınırlarının hepsinin tahminen çizildiği oldukça belli ve şahsımın da baz aldığı Malatya Büyükşehir Belediyesinin kent rehberiyle hiçbir şekilde uyuşmuyor.

عروض لايف المواشي

blogs.openstreetmap.org - mer 18 aoû 2021 - 0:48

يشرفنا متابعتكم لـ ‫سناب‬ ‫لايف‬ المواشي‬ Halalforest ‫عروض يومياً متنوعة‬ ‫طرح افضل الأدوية البيطرية‬ ‫تغطيات الاسواق‬ الحلال ‫عرض‬ مايتعلق ‫وزارة البيئة والزراعة والمياة من ‫اخبار‬ والاستيراد‬ ودعم صغار مربي الماشية وموعد صرفها رابط السناب https://www.snapchat.com/add/halalforest

Displaying all the postboxes and post offices in the world on an editable map for a postcard application

blogs.openstreetmap.org - mar 17 aoû 2021 - 20:18

I’ve been working on a project for a few months now, and keep getting stuck with time out errors from the Overpass API, which I think might be due to the fact that there are so many postboxes and post offices in the world. (Maybe?)

**Background on the project and ideal vision:

I’m helping the guy who runs postcrossing.com (a free website where people from all over can pull an address and send and receive postcards from each other) to build a map where people can easily find the postbox or post office closest to them in order to mail their postcards. This could be especially helpful if people are on holiday or not close to home and are not super aware of the postboxes and post offices in the area. This would be a map that is embedded in a website - there is no app yet for postcrossing.com and does not seem like there will be on in the near future.

I want the postboxes and post offices to be on different layers, so that I can style the icons individually.

The map should be easy to understand and ideally, would also offer the option to edit if need be (i.e add a postbox or post office that does not yet exist on the map, and be able to add opening hours for the post offices and collection times for the postboxes. There would also be the option to add a photo of the postbox or post office.

**Progress thus far:

I began this project using the Overpass API and putting that information into a uMap, which you can find here: http://u.osmfr.org/m/528331/

I set up the cache under remote data to be once a day, but I still get a red error message that says, “problem in the response,” and gets a 429 error in the console when I move about the map.

I first wrote an OSM Diary entry about this project here: https://www.openstreetmap.org/user/Nicolelaine/diary/396957

Someone suggested that I create a bounding box, following this French tutorial here: https://wiki.cartocite.fr/doku.php?id=umap:10_-_je_valorise_les_donnees_openstreetmap_avec_umap

I tried to do this, and I’m not sure if I did it incorrectly, or if this sort of suggestion just does not work for a worldwide map. I was still getting the same error messages as before.

Someone else suggested that I create a dynamic query (https://www.mappa-mercia.org/2014/09/creating-an-always-up-to-date-map.html) using Overpass, but I think that is what I’m already doing, as I have the dynamic option selected in the remote data section for each layer in uMap.

Another person suggested that I use MapComplete, which seemed like the perfect solution, as it allowed me to create a theme where one could upload photos of the postboxes and post offices, as well as add in postboxes and post offices that don’t already exist on the map, as well as add in the opening times for the post offices (there is not yet a special rendering for pickup times for postboxes.) This seemed to work great, but I continue to get time out errors as I move about the map. As this is intended to be used worldwide, it seems like MapComplete won’t work either. You can view the current theme here: https://mapcomplete.osm.be/?test=true&userlayout=https://gist.githubusercontent.com/RobinLinde/3353a12c1f721fdfb027429f61a7e887/raw/e3bc41972b4c28a3028b4ce243f83b9138920bae/post.json#welcome

**Suggestions that might work:

1.) Someone suggested that I try using git scraping to make this work, as described here: https://hackmd.io/OkwpRqQ7QXC3p8C0jfTUGQ?view

This seems to work, but I don’t know if it’s possible to put this in MapComplete. It seems like it might be possible in uMap though: https://github.com/nicolelaine/postboxes-history/commits/main

2.) It sounds like support to fetch data from (tiled) geojson, and one day (in a far, far future) such a thing might be possible. However, I’m not sure how this works or would help in my situation.

**My questions:

*Do you know any way that it’s possible to achieve what I’m going for without running into these time out errors?

*Is there any way to make what I’m hoping to achieve happen with the Overpass API or is this a lost cause, and I should start looking at how to do this locally with a real time database?

*Does anyone have experience with fetching data from (tiled) geojson? How could that work for this project?

Uma Analise sobre uso de Mapas Online

blogs.openstreetmap.org - mar 17 aoû 2021 - 19:27

Fizemos uma pequena pesquisa para conhecer melhor o uso dos mapas online e o conhecimento do OpenStreetMap no Brasil, cerca de 97 pessoas ao redor do Brasil responderam nossa pesquisa. acompanhe os resultado a abaixo:

Gostaria de agradecer a todos que responderam nosso questionário a Lules por ter trabalhado nessa pesquisa e aos meus apoiadores Claus Wahlers, Karl Prieb, Luiza Figueiro e a Gabriela Pires graça ao apoio de vocês esse trabalho pode ser feito!

Muito obrigado!

você pode baixar os dados da pesquisa por esse link

GSoC 2021 Final Report for OpeningHoursEvaluator

blogs.openstreetmap.org - mar 17 aoû 2021 - 18:58
Introduction

Hi everyone! As GSoC 2021 is coming to a close, I am writing this diary entry as a final report on the progress of my GSoC project, the OpeningHoursEvaluator, in the second period of GSoC.

Previous entries Project Summary

An evaluator for opening hours tag according to OSM opening hours specification.

Second Period’s Summary

Just to recap, the evaluator from the first period supports almost all the syntaxes defined by the specifications, ranging from something as small as time and a wider range such as year. Building from my previous progress, I have added geocoding to the evaluator, for use in calculation of variable time such as dawn, dusk, sunrise, sunset. I have also added support for holiday data for the corresponding opening hours tag PH and SH, which currently supports 168 countries. Combined with my progress in the first period, the current evaluator now supports evaluation of all the syntax defined by the grammar, and is ready for use in production.

Source code

GitHub repository: https://github.com/goodudetheboy/OpeningHoursEvaluator

Timeline
  • Jul 12-18
    • Add more detailed documentations for first period’s word
    • Test and fix bugs
  • Jul 19-25
    • Add support for variable time (dawn, dusk, sunrise, sunset)
    • Add dedicated geocoding for evaluator, with automatic lookup of timezone and location based on coordinates
    • Look up suitable holiday data for use when checking holidays
    • Add documentation
  • Jul 26-Aug 2: Since the holiday data I found is only raw strings, and needs pre-processing to calculation to date, from this point on, I worked on creating a parser for this holiday data. The work was done on a different repository, which can be found here
    • Create custom gson deserializer to create objects from holiday data
    • Add support for Gregorian dates (MM-DD and YYYY-MM)
    • Add support for start of month
    • Add support for easter/orthodox calculation
    • Add support for Hijra calendar
    • Add support for Hebrew calendar
    • Add support for East Asian calendars, including Chinese, Korean, and Vietnamese
    • Add support for astronomical time calculation such as Equinox and Solstice
    • Add support for different start time
    • Add support for nth weekday in month
    • Add support for changing weekday if holiday falls on certain weekday
  • Aug 2-8: Keep working on the parser
    • Add support for extra weekday if holiday falls on certain weekday
    • Add support for enabling holiday only on certain years
    • Add support for enabling holiday only on certain weekdays
    • Add support for enabling holiday only in year interval
    • Add support for enabling holiday since certain years
    • Add support for Julian calendar
    • Add documentation
  • Aug 9-15
    • Add support for public holidays (PH) and school holidays (SH) on a national level
    • Add support for PH and SH on a regional level (including states and subregions of a country)
    • Add documentation
    • 0.0.1 published to Maven Central!
Initial goal satisfaction

I have set out to add support for the variable time calculation and holiday support for the evaluator, and I believe that I have completed both of the core objectives for my second period. I even went ahead and created a Java library to grab holidays of countries in the world. However, I did also set out to fix all the bugs that I have listed in my previous diary entry, but due to some time constraints I did not get around to dealing with all of them in this period. More information on this in the Shortcomings section.

Shortcomings

Though I have set out to finish these bugs, there are some features that I have yet to fully implement, including:

  • Time cutting when a definite time range cut an open-end time range

This bug will be dealt with post-GSOC, as well as other core improvements.

Acknowledgments

Throughout GSOC, I am really grateful to my mentors Simon Poole and Rebecca Schmidt, who have been extremely helpful to me for answering my questions about evaluation of certain opening hours, giving feedbacks about code snippets, and providing all the help they can regarding the technical side of things. Special thanks to Simon for hosting the namespace where my project is published to on Nexus Repository!

I would like to thank the authors of opening_hours.js, whose Javascript version of the evaluator has helped me a great deal in creating test cases for my evaluator.

I would like to thank the authors of date-holidays for their incredible data of holidays in the world, supporting 168 countries and many other subregions, which I used to add support for the PH and SH in the evaluator.

And I would like to thanks OSM and its community for giving me this opportunity to participate in Google Summer of Code with them!

What’s next after GSoC?

There are many bugs that I have not have the time to deal with, and these will be fixed later. More improvements on core features will be planned in a later date, or taken from the Issues section of the repository.

I will keep maintaining this project for as long as I can! If there are any issues, please raise them on the Issues section of the OpeningHoursEvaluator and I will deal with them as soon as possible.

My Location

blogs.openstreetmap.org - mar 17 aoû 2021 - 18:11

Dr. Hedgewar Rugnalya - Aurangabad, Ciigma Hospital, AKASHWANI KENDRA, Saint Francis De Sales High School, High Court Aurangabad

Nominatim Feedback Reporter - GSoC'21 Final Report

blogs.openstreetmap.org - lun 16 aoû 2021 - 23:03
Important Links Source Code

Nominatim-Feedback-Reporter

Diary entries Hosted server About the project

This is a GSoC project, which has been developed over the Summer of 2021 by Yash Srivastava (darkshredder). This project is mentored by Marc Tobias (mtmail) and Sarah Hoffmann (lonvia).

Project Description

OSM’s main search engine Nominatim did not provide a way to report feedback on the search results that they think to be wrong.

This project aims to provide a web interface to report such feedback and store them in a logs file. So that the feedback can be analyzed, fixed and can be re-run by the maintainers to see if the problem is still there.

Implementation

The following step was followed to implement this project:

  • Selecting the frontend and backend framework for the project.
  • Finding a way to fetch multiple results for reverse geocoding as nominatim only returns a single result.
    • We used overpass API to fetch multiple results and then to provide an option to select a correct result base on reverse search results.
  • Hosting the frontend and backend code on the server.
    • Our frontend UI can be found here.
    • Our backend API can be found here.
  • Testing the frontend and backend code.
    • We used puppeteer and mocha to add integration tests to the frontend.
    • We used pytest for unit testing backend code.
  • Setting up the continuous integration pipeline.
    • We used GitHub Actions to integrate the CI pipeline to test as well as build our frontend and backend code.
Final product at the end of the GSoC

After phase-1 was completed, I along with my mentors had a discussion about the flow of the web interface and we decided to change some of the screens to make it more user friendly.

The screenshots below show the final product of the project.

Now we have a review page for all the feedback that was reported.

What did I learn?
  • Worked on completely new frameworks and how to adapt to them.
  • How to add testing to the project.
  • Worked on integrating CI pipeline where I ran backend as a daemon process and frontend ran tests and stored all the logs files in the backend.
  • Working and hosting APIs and frontend code on the server. This was the first time I worked integrating certbot to enable HTTPS on our website.
What next?
  • UI can be made user friendly.
  • Currently overpass API fetch only data that has name tag. So we need to add a checkbox that will fetch all the data rather than only name tag. ISSUE: #3
  • Whole application can be dockerized.
  • Accessibility features can be added.
Acknowledgement

I would like to thank my mentors Marc Tobias and Sarah Hoffmann for helping and guiding me in the project throughout the GSoC journey!

I am thankful to Google Summer Of Code for providing me with an opportunity to work with OpenStreetMap.

Mi experiencia como organizadora y aprendizajes del State of the Map (SotM) 2021

blogs.openstreetmap.org - lun 16 aoû 2021 - 22:25

Nota: Esta traducción al español es posible gracias a Cyberjuan, ¡gracias! Puedes leer la versión en inglés aquí. (Note: This translation to Spanish is made possible by Cyberjuan, thank you! You can read the English version here).

Tuve la suerte de ser seleccionada como uno de los académicos de la conferencia State of the Map 2018 (mis reflexiones aquí). Este año, tuve la oportunidad de ser parte del Grupo de trabajo (WG) del SotM 2021 organizando la conferencia en línea SotM 2021.

Principalmente he trabajado en el Equipo de Comunicaciones. Comparto en este diario mi experiencia como organizadora y mis aprendizajes, ya que esto puede ayudar a otros organizadores a planificar sus eventos en línea, o similares.

¡A continuación una larga lectura!

1. Reclutamiento de voluntarios para SotM WG (vea la invitación a la Convocatoria de voluntarios mediante la lista de correos)

Debido a la pandemia, el SotM se volvió virtual. Dado que no había un ofrecimiento comunitario involucrado, la presidenta de SotM invitó a los miembros de la comunidad de OSM a unirse al SotM WG. Ella promovió esto a través de la lista de correo y fue compartido por miembros de la comunidad a través de las redes sociales y otros canales comunitarios.

Clave: Definir claramente la estructura del grupo de trabajo (sub-grupos/sub-equipos), sus funciones y quién dirige los equipos, y cómo unirse (tan simple como enviar un correo electrónico).

2. Organización de la estructura/flujo de trabajo del equipo (comunicación sincronizada y asincrónica)

Como se ve en la invitación, hay pequeños grupos/sub-grupos de trabajo dentro del Grupo de trabajo del SotM para una coordinación más organizada.

Claves:

  1. Coordinación: Creación de sub-equipos y sub-grupos de trabajo, incluyendo alguna forma de tener comunicación asincrónica (coordinación sin reuniones) para aquellos que no pueden asistir a las reuniones en vivo.

  2. Toma de decisiones: Llegamos a decisiones mediante la construcción de un consenso grupal, lo que ha fomentado una participación más activa de los voluntarios.

3. Formato de la conferencia (3 días, en línea)

El SotM 2021 sigue un formato de 3 días como un evento físico.

Contras: No recomiendo el formato de 3 días consecutivos ya que es demasiado exigente para el equipo organizador (para un evento online).

Recomendación: Lo que realmente recomiendo es el formato virtual de 3 días de Pista ng Mapa 2020, quienes organizaron la conferencia de 3 días durante 3 viernes en noviembre de 2020. Permitiendo que el equipo organizador se recargue para el siguiente día de la conferencia (¡durante una semana!). #avisodesvergonzado ¡La convocatoria de propuestas para el Pista ng Mapa 2021 ya está abierta!

4. Plataformas de conferencias: Venueless y BBB

Pros:

  1. La interfaz de la plataforma de conferencias, Venueless, es simple y fácil de usar. Parece algo floja con los videos. 2.El número de canales o salas es mínimo y suficiente para que los participantes se familiaricen.
  2. Los videos permiten el modo ligero/solo escuchar.
  3. Algunos participantes han informado que escuchan simultáneamente tanto las charlas en el escenario principal como los talleres y paneles.

Contras:

  1. Para los participantes con un ancho de banda muy bajo, las BBB (sesiones en vivo) generalmente fallan.
  2. Si eres un organizador que quiere una plataforma todo en 1, es posible que Venueless no sea lo indicado, ya que necesitarás un servicio separado para la gestión de contenido (SotM 2021 usó Pretalx), gestión de tickets (Pretaix) e interpretación (Mumble).

Recomendación: deberíamos haber probado la plataforma con los conferencistas para que estén familiarizados y evitar confusiones durante la conferencia.

5. Aumentar la accesibilidad garantizando un espacio seguro

a. Interpretación y subtitulado de idiomas en vivo

El equipo organizador de SotM 2021 realizó experimentalmente interpretación y subtítulos en vivo.

El lado tecnológico es simple, los intérpretes y los oyentes se conectan al servidor HOT en Mumble. Van al canal del idioma de su elección. Los intérpretes ven la transmisión en vivo y simultáneamente brindan interpretaciones en vivo en el canal, siendo los únicos que pueden hablar en el canal.

Preparación

  • SotM abrió convocatoria de intérpretes voluntarios en la comunidad.
  • Recibimos algunos, pero solo la mitad de los que se ofrecieron como voluntarios realmente lo hicieron.
  • Solo se ofrecieron interpretaciones en vivo de las charlas pregrabadas. Los intérpretes recibieron un enlace de acceso a las charlas pregrabadas para que pudieran tomar notas/preparar su interpretación.
  • Probamos Mumble con los intérpretes voluntarios.
  • Se publicó un calendario de interpretación en la wiki de OSM con una guía sobre el uso de mumble para los oyentes/audiencia.

Durante el evento

  • Les pedimos a los intérpretes que se graben para que sus contribuciones no se pierdan y podamos luego agregar subtítulos de audio o texto a las charlas de la conferencia.
  • El equipo de comunicaciones promovió activamente el horario de interpretación (en la plataforma de la conferencia y en Twitter para llegar a quienes no tenían tickets).
  • Me di cuenta de que solo el canal ruso tenía oyentes (el canal más popular).
  • Los administradores de soporte de Mumble se aseguraron de que los intérpretes grabaran sus charlas y estuvieran atentos en caso de surgir preguntas de los oyentes/oradores sobre Mumble.

Luego

  • Compartimos un enlace con los intérpretes donde puedan cargar su audio grabado.
  • La traducción a diversos idiomas y el subtitulado todavía está en proceso :)

Claves:

  1. Mumble permite ver si hay oyentes, y encontramos que la oferta fue mayor que la demanda. Nos centramos más en conseguir traductores voluntarios (oferta) que en evaluar qué idioma preferían los participantes (demanda).
  2. Deberíamos haber promocionado más esta función antes de la conferencia.

b. Cumplimiento del Código de Conducta

Se redactó un Código de Conducta (CoC) SotM 2021. Nos aseguramos de que sea visible ahora que permitimos más interacciones entre los participantes. Creo que confiamos más en la moderación pasiva/basada en informes.

Recomendación: Lo que recomendaría para que se aplique estrictamente el CoC es tener una moderación activa con una persona CoC para cada sala/canal. La sala posterior a la charla tuvo mucho tráfico, pero no estaba segura de si había una persona CoC en la sala. Sin embargo, no recibimos ningún informe.

6. Estrategia de comunicaciones antes/durante/después del SotM 2021

Antes

  • Publicar activamente en TODOS los canales de la comunidad, redes sociales, listas de correo.
  • Actualizaciones al menos una vez a la semana durante el último mes antes del evento para generar expectativa y entusiasmo.
  • Fuimos invitados a hablar en un podcast para conversar sobre el evento
  • Hubo un diseñador visual/de afiches designado y un comunicador/promotor de textos.

Durante el evento

  • El Grupo de trabajo de Comunicación tuvo acceso a la cuenta de Twitter a través de Tweetdeck.
  • ¡Tweetdeck es genial! ¡aprovechamos el programador de tuits!

En Twitter (Programación de tuits):

  1. Para charlas con interpretación en vivo: programar un tuit 10 minutos antes de que comience la sesión.
  2. Por sesión, programar un tuit 30 minutos antes del inicio de la sesión.
  3. Programar un tuit al momento de la pausa de la sesión y con la hora a la que volveremos.
  4. En la plataforma de conferencias, enviar un mensaje en el chat Talks y en el chat global basado en texto, cuando:
  • Hay una próxima sesión con interpretación en vivo
  • Hay una próxima sesión de panel de discusión (canal de Talleres y Paneles + hora)
  • Hay una próxima sesión informal (BoF) (y en qué canal + hora) + promocionar que aún pueden inscribirse en el BoF.

Luego

  • Publicar activamente en TODOS los canales de la comunidad, redes sociales, listas de correo.
7. Comentarios y posconferencia

En lugar de un formulario de encuesta, SotM tiene la costumbre de documentar los comentarios mediante la wiki de OSM. Creamos una página de comentarios con un enlace a un pad para comentarios y enlaces para publicaciones de blog posteriores a la conferencia.

Clave: La wiki de OSM permite un informe de retroalimentación colaborativo.

FIN

¡Saludos a los increíbles voluntarios de SotM 2021 (ver hilo de Twitter)!

Si tienes comentarios sobre la conferencia, agrégalos a la página Wikipage de comentarios sobre la conferencia.

Si fuiste voluntario durante el evento, ¡no dudes en agregar tus aprendizajes y conclusiones también! ¡Gracias! :)

Nota: Esta traducción al español es posible gracias a Cyberjuan, ¡gracias! Puedes leer la versión en inglés aquí. (Note: This translation to Spanish is made possible by Cyberjuan, thank you! You can read the English version here).

What I did in OpenStreetMap in July 2021

blogs.openstreetmap.org - lun 16 aoû 2021 - 21:34
What I did in OpenStreetMap in July 2021

2021: Jan. Feb. Mar. Apr. May June

2020: Jan. Feb. Mar. Apr. May June July Aug. Sept. Oct. Nov. Dec.

Hochwasserkatastrophe in Deutschland

blogs.openstreetmap.org - lun 16 aoû 2021 - 21:21

Moin!

ich muss jetzt einfach einmal einige Worte loswerden.

Wir mappen in der ganzen Welt wenn irgendwo eine Flutwelle über das Land herbricht oder auch die Erde erbebt.

Mir ist bekannt, dass zu Beginn der Hochwasserkatastertrophe im Ahrtal und auch in den anderen Gebieten, die vermutlich nicht so bekannt sind - dennoch schwerst getroffen sind, darum gebeten wurde die Karte unverändert zu lassen.

Zwischenzeitlich erkennt man in den Karten die eine oder andere Behilfsbrücke und auch die als zerstört gekennzeichneten Straßen.

Aber ansonsten ist es in den OSM-Kanälen sehr ruhig um das Human-Mappen im eigenen Land.

Ich sehe gerade einen Bericht mit Markus Wipperfürth, einem der Helfer der ersten Stunde, und wieder wird auf Google Maps verwiesen. Dabei sind das doch mehr als veraltete Daten vermutlich.

Irgendwo hatte ich einmal von Bilder einer Befliegung etwas gehört, aber dann ist es wieder stumm geworden.

….

Ich lasse hier meinen Beitrag einmal offen enden.

Gruß Jan

Abogados Anaheim

blogs.openstreetmap.org - lun 16 aoû 2021 - 19:24

abogados de accidentes de auto cerca de mi Anaheim - Every year, there are about 857 bicycle fatalities and over 450,000 seriously injured in the United States as a result of accidents. For that reason, it is useful to understand exactly what causes the accidents and, importantly, how to avoid serious injuries when cycling. The most common types of accidents when it comes to bikes and cars are: road traffic accidents (like running into a car), bicycle accidents, and hit-and-run accidents. Let’s take a look at each of them to see what caused them.

https://abogadosdeaccidentesenanaheim.com

Pages