Levantamento e registo em OSM dos prédios rústicos do sul do distrito de Évora e do norte do distrito de Beja. Não pretendendo ser um registo exaustivo, para tal existem as entidades oficiais, tem como objectivo permitir uma referenciação geográfica genérica fora das localidades. Os montes, mesmo que em ruínas (building:ruins), são assinalados com precisão (place:isolated_dwelling), sendo que as herdades e hortas ficam assinaladas de modo menos preciso, não sendo sequer utilizado o centroide das mesmas, o que implica que estas propriedades não ficam facilmente delineadas nem fica registada a identificação dos seus limites (São identificadas com um ou mais pontos, com a tag place:farm)

After several years of work buildings are still patchy in OSM in London. The gaps are all too obvious when you use apps such as Maps.me, and of course mapping houses leads to better mapped roads.

After a time when I solidly filled in all of the houses in an area near where I live, I decided to change my mapping approach. I am now filling in buildings and addresses facing A roads and bus routes in half a London borough, the bit of Richmond upon Thames that is south of the river and east of the rest of the borough.

I see these buildings as important because:

1. People travelling along these roads get a full set of houses that they can follow.
2. As these are the longest roads they are the most valuable to search using the whole address because the street name is not precise enough.
3. This includes a large proportion of businesses that are worth mapping.
4. The gaps between mapped houses are broken up, this makes them more attractive for the long tail of occasional mappers to fill in the gaps; some of them could be our next enthusiasts.

As I write there is still a bit of work left.

One thing that [ have ducked out of tackling so far is the landuse polygons, which are a mess. They often intersect buildings, the commercial landuse in Barnes bears little resemblance to the actual town centre and polygons that were drawn arbitrarily on the map in Richmond acquired concocted names. The only quick thing I could have done would be to delete them completely, which I do not want to do unilaterally.

What could be done is to redraw the polygons adding the extents of the relevant properties to create one or more residential/commercial/other polygon for every street block, as the logical conclusion of landuse polygons that exclude roads. Extents are now available for import though it may very well be better to add them from aerial imagery.

In der Wochennotiz https://wiki.openstreetmap.org/wiki/Wochennotiz wird vielfach auf eine sogenannte Mailingliste verwiesen.

In OpenStreetMap gibt es zwei verschiedene Diskussionsräume. Die Wochennotiz wird daher auch in beiden Räumen publiziert. OSM Neulinge sind durchaus verwirrt.

a. Mailingliste: eine Mailingliste Identität bedingt lediglich eine beliebige e-mail Adresse

b. Webforum: die Nutzer Identität im Webforum ist mit der OSM- Mapper Identität verknüpft

Meine Versuch einer Erklärung:

a. Mailinglisten Beiträge behandeln OSM eher aus der Sicht des Daten Anwenders. Externe Stakeholder stellen OSM Ressourcen zur Verfügung, wirken selbst aber eher nicht als Mapper mit. Externe Stakeholder benutzen daher gerne als deren Kommunikationskanal Mailinglisten. Beispiel https://lists.openstreetmap.org/pipermail/talk-at/

b. Forumsbeiträge beschreiben die Sicht der OSM Mapper. Beispiel: https://forum.openstreetmap.org/viewtopic.php?pid=704020#p704020

Manche OSM Mitwirkende benutzen auch beide Diskussionsräume, für Verwirrung in der Diskussion in OpenStreetMap ist daher regelmäßig gesorgt. Auch daher da offensichtlich den Mailinglisten und so auch OSM Externen, viel Gewicht in der Entscheidungsfindung zugebilligt wird.

01-14内容：历山路—花园路—花园庄东路—山大路—山大南路片区初步

The TIGER import in the USA is one of the largest and messiest imports in OSM, but of course it is getting cleaned up over time. It can be hard to estimate progress, but one rough metric is the number of nodes and ways that haven't been changed since import. This number goes down over time. For the past 3 years, I've been tracking these numbers in a spreadsheet.

• For nodes, it is the last-modified-by for accounts 'woodpeck_fixbot' and 'TIGERcnl'
• For ways, it is the last-modified-by for accounts 'bot-mode' and 'DaveHansenTiger'

Over the last 3 years (since June 2015):

• Nodes have decreased from 139.6 to 127.6 million (average 11k/day)
• Ways have decreased from 8.00 to 6.08 million (average 1688/day)

What's remarkable to me, as you can see from the trendlines, is how steady the rates are. At this rate, all of TIGER won't be cleaned up (or at least touched) for another 31.7 years (for nodes) or 9.9 years (for ways).

Почему пришлось взяться за POI

Если мы посмотрим на карту в масштабах города, то самыми важными объектами на ней будут, скорее всего, улицы, затем дома с адресами, а затем POI. На счёт этого порядка важности можно поспорить, некоторые утверждают, что без адресов карта бесполезна, хотя мне кажется, что это преувеличение. Лично я ближайшие POI помню не по номеру дома, и на вопросы, где находится дом номер такой-то обычно ответить не могу. Кстати, нередко такие вопросы задают рядом с искомым домом, после чего я проверяю, есть ли табличка с номером, и обычно она есть.

Дальше встречаются разные мнения, какие именно разновидности POI важнее. Например, кто-то скажет, что аптеки. На вопрос, что важнее – магазин или столовая, я пока решил не отвечать, и заняться всеми POI, которые подходят под определение, которое я приведу в одной из следующих записей. POI, которые под него попадают, выделены мной не по степени важности, а по степени находимости на местности и скорости изменений.

Мы знаем, что объекты на местности могут меняться, причём разного рода объекты будут меняться с разной скоростью. Из перечисленного выше, улицы меняются редко: иногда появляются новые, иногда продлеваются старые, иногда у них меняется название, и можно считать, что они практически никогда не исчезают. Правда, они могут закрываться на ремонт, что важно для навигации, но за этим не так сложно уследить, потому что самих улиц мало относительно других перечисленных выше объектов. Здания тоже меняются редко: иногда строятся новые, иногда перестраиваются старые. Во временных масштабах существования осма, отрисовка зданий – почти одноразовое дело.

Другое дело – магазины, кафе и т.п. По весьма примерным подсчётам их «время полураспада» составляет 5 лет. То есть если вы их все отметите и подождёте 5 лет, половина из них уже не будет существовать. И если их много, то найдётся какой-нибудь магазин, который закроется или откроется практически сразу после вашей проверки. А их очень даже может быть много – так много, что они на рендер не поместятся. Значит, просто один раз сходить и отметить подобного рода точки, а затем считать, что дело сделано, не выйдет.

Я хочу, чтобы данные о POI в осме были как можно ближе к действительности. Ясно, что для этого придётся перепроверять уже однажды проверенные места. Решать вопрос, куда и когда идти проверять можно по-разному, но при этом не обойтись без информации о том, когда производилась предыдущая проверка. Есть ли в данных осма такая информация?

Время проверок

Первое, что можно вспомнить, это время создания пакета правок. Однако, это время вовсе не обязательно совпадает со временем, когда редактирующий участник видел точку на месте. Строго говоря, оно всегда не совпадает, потому что правка делается позже проверки. Можно, конечно, пытаться делать правку сразу, но часто бывает некогда. Например, я сначала ставил себе задачу вводить данные на следующий день после проверки, потом срок превратился в две недели, теперь я рад, когда отстаю меньше, чем на два месяца. Иногда правка точки вообще не означает, что участник её видел или проверял каким-либо другим способом, например, сдвиг здания вместе со всем его содержимым или замена url. Короче, время проверки надо брать из какого-то другого места.

Вторая идея – пользоваться тегом check_date. Для POI он редко используется, так что первый недостаток – то, что придётся тегировать под x, где x – организация процесса обновления данных о POI. Может возникнуть вопрос, а уместна ли в принципе простановка на точки, линии и отношения тега check_date и подобных ему метаданных. Если нет, то мы могли бы его ставить на пакет, ведь у пакетов тоже есть теги. Тогда, правда, придётся аккуратно делать пакеты, чтобы они не затрагивали лишнего. Такая же проблема была бы и при использовании даты создания пакета, но проблема эта не единственная.

Другим источником проблем является то, что проверять приходится не сами точки, ну или не только сами точки, а ещё и места, где эти точки могут быть. Изначально в данных осм точек нет, так что и check_date искать не на чем. Допустим, мы ставим дату проверки на пакет, и список пакетов, в которых её надо искать, мы составим вручную, чтобы не просматривать все пакеты, затрагивающие интересующее нас место. Но что нам делать, если мы пройдём по месту, и увидим, что в соответствующих ему данных ничего менять не надо. Например, там как не было POI, так и нет. Тогда и правок делать не надо, пакет создавать не из чего, дату проверки писать некуда и читать неоткуда. И, вообще-то, мы так и не определили, что такое интересующие нас места. В осме таких объектов точно нет.

Места проверок

Становится понятно, что придётся задать информацию о местах за пределами данных осма, и информацию об их проверках тоже хранить не в осме. И подобное уже реализовано в MapCraft. Но эти нарезки носят одноразовый характер: вот вам участок, где что-то не нарисовано, пойдите нарисуйте, затем отметьте, что задача выполнена и всё. А у нас – не всё, нам надо перепроверить участок через некоторое время, и сами участки должны быть определены с учётом таких перепроверок.

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

Естественное желание – сделать участки непересекающимися, чтобы любая точка попадала только в один из них. Но так не выйдет, потому что некоторые заведения находятся на углу квартала, причём даже вход в них находится прямо на углу. Да и физически POI не являются точками, а значит никто не мешает рисовать их полигонами, а полигон запросто может пересечься с несколькими участками. Полигоны для POI, правда, обычно не используют, к причинам этого мы ещё вернёмся. Итого наши участки могут перекрываться, особенно на углах кварталов, и POI может находиться одновременно в нескольких участках.

Помимо POI, выходящих на улицу, есть ещё POI во дворах, подземных переходах, торговых комплексах, бизнес-центрах. С ними иметь дело сложнее, и они для меня являются второстепенной задачей. Первая сложность тут ещё со сбором данных: их не видно с панорам улиц, и gps рядом с ними не работает, значит пройтись на месте с OsmTracker'ом, а вводить уже потом за компом не получится. Поэтому я пока не брался за ТК и не решил, на какие участки их делить. Весь ТК как один участок – это, наверное, слишком много с точки зрения «целиком проверить за один заход». Если делить, то, видимо, на этажи, хотя тогда получатся не просто перекрывающиеся участки, а полностью совпадающие в проекции на плоскость, а это по ряду причин неудобно.

Со внутриквартальными POI есть свои сложности. В центре Петербурга, как правило, зайти во двор можно через арку, а далее пройти можно только в ограниченную часть квартала. Часто из двора определённого дома никуда попасть нельзя, кроме как обратно на улицу. В этом случае можно сделать участком весь этот двор. Но если таким образом доступна большая часть квартала, да и сам квартал большой, то делить на участки придётся как-то по-другому. В новостройках придётся, видимо, делить вдоль внутриквартальных проездов. Мне это предстоит делать уже и в Центральном районе рядом с Московским вокзалом.

Метаданные проверок

Поскольку для начала я решил никаких инструментов не писать, то и сохранять данные пришлось самым примитивным способом. Это был csv-файл с записями (название участка, дата проверки, пакет правок). Название участка служит его идентификатором и обычно выглядит как (название улицы, тип улицы, диапазон номеров домов). Конечно, в будущем это должно стать таблицей в базе данных, и тогда идентификатором участка мог бы быть суррогатный ключ ещё одной таблицы с данными об участках. Но при редактировании вручную суррогатный ключ, то есть число, которое само по себе ничего не значит, использовать неудобно.

Информация о том, когда была произведена проверка, представлена в виде даты. Точнее даты время мне знать не нужно, соответственно я не слежу за тем, во сколько часов сколько минут я начал проверять определённый участок, главное, чтобы это было время регулярной проверки, об этом позже. Другой вопрос – не нужно ли специально хранить менее точные данные, например, из соображений privacy. Когда я начну принимать данные от других участников, мне, возможно, придётся вернуться к этому вопросу. По поводу намеренного предоставления менее точных данных есть две точки зрения. Одна из них – что для недавнего времени надо давать менее точную информацию, а позже её можно уточнить. Другая – что наоборот по прошествии времени данные надо делать менее детальными. Мне больше подходит первый вариант, в том числе потому что он получается сам собой. Собранные данные я ввожу не сразу, так что если вы захотите узнать, где я сейчас нахожусь, глядя на предоставляемые мной данные о проверках участков, то я уже давно оттуда ушёл. Вторая точка зрения связана с тем, что при точных данных о том, где кто когда был, идущих далеко назад по времени, можно сделать вывод, какие места данный человек имеет обыкновение посещать, например, в определённый день недели. Но те места, информацию о которых я ввожу в рамках данных проверок – это не те места, в которые я хожу с какой-либо другой целью. В большинство проверяемых заведений я вообще не захожу.

Что касается третьего элемента в записи – номера пакета правок, то как мы уже знаем, его может и не быть. Соответственно, уже с самого начала его указывать было необязательно. Тут можно поинтересоваться, зачем в принципе записывать пакет, ведь дата проверки берётся не из него. В данный момент это просто средство для меня, чтобы искать пакеты правок, относящиеся к определённому месту. По обычной истории правок это делать неудобно. В идеале хотелось бы иметь способ получить всю информацию по POI, признанную мной правильной на момент проверки, и она содержалась бы в пакете, если бы правки в обязательном порядке затрагивали все точки и, желательно, ничего кроме точек. Но это не так, хотя отчасти я пользуюсь записанными пакетами в качестве временного средства сделать snapshot данных. (примечание на июнь 2018: кое-что поменялось между написанием и публикацией; собственно snapshot уже делается, и полей в соответствующем csv-файле уже не три)

Далее обнаружилось, что не всегда реально сделать правки для всего участка за один заход. Соответственно, пришлось разрешить указывать множество пакетов правок для одной проверки. Связано это с тем, что попадаются участки, на которых может быть хоть пятьдесят POI, например, Лиговский проспект между площадью Восстания и Транспортным переулком (1, 2), и это если исключить из него Московский вокзал и «Галерею». Придумывать особенный способ деления на участки поменьше для «POI-плотных» мест мне не хочется, так как при текущем способе деления границы участков очевидны даже без разглядывания картинок, где они нарисованы, тем более, что изначально они не были нарисованы.

Метаданные участков

Сначала данные об участках содержались в первую очередь в их названиях. Названия эти состоят из названий улиц и диапазонов номеров домов. Названия улиц не уникальны во всём субъекте федерации, но уникальны внутри центральных районов. В районах, включающих разные населённые пункты, типа Пушкинского, подобной уникальности может уже не быть, но ими я пока систематически не занимаюсь. Если к названию улицы добавить номера домов, то так можно задать сторону квартала, выходящую на определённую улицу – тот тип участков, которые я проверяю в первую очередь. Проблема тут в том, что номеров по нужной улице может не существовать. Улицами здесь я называю всё, что в Петербурге официально ими считается, и отображается зелёными линиями в rgis. Это включает и площади, а по ним часто не бывает номеров, тогда в название участка приходится вместо них писать, какая это сторона, например, юго-западная. Даже если номера и есть, то они не всегда очевидны, их может не быть в осме и так далее. Дополнительно к номерам я решил давать текстовое описание, которое позволит в сочетании с именем участка найти его, даже если я ошибусь с номерами. Сначала это привело к появлению ещё одного csv-файла с записями (название участка, описание).

Через некоторое время это стало неудобно, ведь по прежнему не было никаких машиночитаемых данных о расположении участков. Расположение можно задать, нарисовав полигон, покрывающий участок. Несвязные участки, для которых это не сработает, скорее всего, не понадобятся. Так как я ввожу данные из josm, то и участки легче рисовать в нём же. Поскольку участки не являются данными осма, то их можно держать в отдельном слое. В нём можно рисовать полигоны и задавать им теги name и description для того, что было в csv-файле. Данные самих проверок, в принципе, тоже можно было бы сохранять в тегах полигона, но это менее удобно, и пока я этого не делаю. Слой с участками сохраняется в файл, а не закачивается в базу осма.

Недостатки у работы со слоем-файлом такие:

• А вдруг его случайно закачаешь, тем более, что josm будет предлагать это сделать, если вносить изменения. К счастью, вскоре после того, как я перешёл к использованию слоя, в josm была добавлена возможность запретить закачивать слой, если в его файле есть xml-атрибут upload='never', поставленный на корневой элемент. Достаточно один раз его вручную поставить, и этот недостаток исчезает.

• А вдруг в него случайно скачаешь данные осма, ведь их в нём быть не должно. Операцию скачивания ещё и нельзя отменить, так что приходится следить, какой слой выбран, и хранить версии файла, например, в git, чтобы в случае скачивания и сохранения лишних данных можно было бы откатиться к «чистой» версии. Впрочем, недавно был добавлен и атрибут download='never'.

• josm всё-таки предназначен для редактирования данных осма, и у всех объектов должен быть осмовский идентификатор. А какие идентификаторы у объектов, которых в осме нет и не будет, то есть у наших участков? Всему, что не закачано, josm даёт временные идентификаторы – отрицательные числа - но нет гарантий, что они постоянны. А если мы начали пользоваться системой контроля версий, то изменения идентификаторов для нас нежелательны. Можно попробовать переустановить идентификаторы перед записью в git так, чтобы изменений было поменьше, но пока я этим не занимаюсь.

Теперь у нас есть набор метаданных, пригодный, например, для визуализации свежести данных POI. Про сами эти не-мета-данные POI будет написано в одной из следующих записей дневника.

01-13内容：解放路—历山路—山大南路—历山东路片区初步

Sharing our experiences can help us shape where we want to go. Over the past months, I have been approached by many people wanting to talk about the 'community gaps' or the 'diversity' issues in OSM. On the Diversity-talk mailing list, we've touched on the topics and aim to support each other. How can we become more welcoming in OSM? What are the steps we can take to be more 'open' with each other, and to new people?

Experiences in OSM

Open Gender Monologues is a way to share our collective stories. We want to raise awareness on gender issues in OSM. We'd love to hear your story, your experiences. You can share anonymously or with your name. We also welcome anyone who would like to share in person at the SOTM Open Gender Monologues session. And, if you want to have your story read, we can help. Here is a 3 minute survey to contribute and details on the session:

There are amazing, generous people doing fantastic things in OSM. This is what I would love to hear people consistently say about OSM. And, often, they do. But, the other side of the feedback/experience, is sometimes less helpful for OSM's mission. There are issues with how OSM collectively manages diversity, inclusion, and community engagement. To what extent are we "open"? It is not simply about the license, the open data, or FOSS. It is a mentality and a culture of "openness". Only by fully understanding and talking about the problems, can we productively move beyond it.

It might seem that there is just one or two stories. That has not been my understanding. The under current statements follow a pattern: "oh, ignore the tone on OSM mailing lists", "it is not you, this is how the community has always talked with each other", "cold response", or "mailing lists are sometimes hard" or "it is just one or two people. Ignore them." Honestly, if people's experiences in OSM less than kind and welcoming, then we are not doing as well as we could.

Be an ally

Can you share the survey across the OSM community? It would be helpful for supporters and allies of OSM to also share their experiences with OSM.

Share Open Gender experiences

OSM in the Open

What are the experiences in the wider 'open communities' around OSM? Last week I read this article OSM should be the priority of the open source community. Yes, and, on the flip side how can OSM learn from those communities?

About Open Gender Monologues @ SOTM

We'll host a session at the State of Map - Milan (July 28 - 30, 2018) This session will not be like any usual panel. We want to raise awareness of the struggles and successes of women and LGBTQ in the OpenStreetMap community - using their own words and experiences. Open Heroines is a global community supporting diversity in open communities. We share voices of women in open government, open data and civic tech.

• About Open Heroines
• What is the Open Gender Monologues
• SOTM Schedule

The session is being co-hosted by Kate Chapman and Heather Leson.

within this hours i moved from 7th position to 5th position and from 5th position to 3rd position . it's that great.....

Olá a todos,

Estava fazendo uma pesquisa sobre museus em Laranjal Paulista para ver se havia alguma notícia ou se a prefeitura já tinha inaugurado o Museu do Imigrante.

Para minha surpresa, vi nos resultados que alguém marcou no Google Maps uma antiga casinha acanhada localizada no núcleo rural de Boa Vista como museu. A casa é simples, com tijolos parcialmente a vista e com uma escrita "Boa Vista" pintado à mão na fachada como a dar boas-vindas aos visitantes do local.

Foto: Erica DalBello

Pelo que sei não há museus na zona rural do município. Achei que algo estava errado e quis averiguar.

No mesmo resultado da pesquisa tinha um link para um trabalho fotográfico sobre a casa exposto no site da fotógrafa Erica DalBello. Ela relata que ela nasceu naquela casa e que quando ela era criança "havia um jardim lindo na frente" e que "ficou abandonada por muitos anos e hoje virou um depósito".

O que mais me admira é que uma construção tão simples ainda está de pé e não teve a mesma sorte de várias outras mais relevantes como escolas e capelas rurais hoje demolidas. E o fato de ter escrito "Boa Vista" na fachada adiciona um elemento pitoresco e icônico à localidade; e não é a primeira vez que vi uma foto desta casa na Internet.

Considerando o valor sentimental de uma edificação tão simples e que a casinha ainda está de pé e possui valor pitoresco para os locais, achei por bem dedicar a minha edição nº 2999 para registrar a edificação no OpenStreetMap.

Local: https://www.openstreetmap.org/?mlat=-23.11920&mlon=-47.86792#map=19/-23.11920/-47.86792

---

Descrição:

Uma antiga singela casa que já possuiu um jardim na frente. Ficou abandonada por muitos anos e hoje é usada como depósito. Pitoresca por ter na sua fachada escrito "Boa Vista", que é o nome da localidade.

Igor Eliezer Arquiteto e Urbanista

I left Niger to map Lagos chhee what have i done

I have posted a Gazetteer of Ashgabat Street Names which represents hours and hours of digging through Russian- and Turkmen-language materials in search of information on where these street names came from. In the course of this research over the past three years I have learned a great deal about Ashgabat's and Turkmenistan's history, and hope others will take time to browse the material collected so far.

alquiler de Autos en Guayaquil Ecuador, vans, suv automatico, furgonetas, servicio de transporte ejecutivo

The Navigation Data team at Mapbox is releasing 184k turn restriction detections located across 35.2k intersections and 23 cities for the OpenStreetMap community.

Interactive Map

GeoJSON File

We generated these turn restriction detections by applying our machine learning computer vision models to Microsoft Streetside Imagery, from which Mapbox has acquired the right to contribute these detections to OpenStreetMap.

One thing to note is that these “detections” are merely proposed turn restrictions and are not equivalent to substantiated turn restrictions. The mapping team at Mapbox has been manually verifying these detections and subsequently mapping verified turn restrictions onto OpenStreetMap. We are releasing these detections to the OpenStreetMap community, so that those who wish to move faster on improving OpenStreetMap based on these detections can do so.

Microsoft has just integrated its Streetside imagery for the United States into iD, a popular web-based editor for contributing to OpenStreetMap. This is the same imagery currently visible on Bing Maps now embedded into a popular editing application initially developed and now maintained by Mapbox. For each of our turn restriction detection (download the GeoJSON file by clicking on "GeoJSON File" link above), we've included:

• "label" : type of turn restriction detected
• "prediction_date" : date on which we ran our detection model on Streetside image
• "bubble_id" : id associated to a streetside "bubble", or the discrete 360 degree view of a location.
• "streetside_url" : URL to the Streetside image associated with each detection.

Below are a few examples from the Streetside Imagery API:

• San Francisco, CA : regulatory--no-right-turn--g1
• Washington, DC : regulatory--no-u-turn--g1
• Bellevue, WA : regulatory--no-left-turn--g2
• New York, NY : regulatory--no-entry--g1

01-12内容：解放路—山大路—山大南路—历山东路片区初步

Hi everyone! I'm Henry from the moon and I love to maintain maps on earth. If you want some dust from the surface from the moon, then hit me up and send me some lasersignals at night from the earth. I would like to sell you some dust!

of course...I'm just kidding! It ships directly to your home on earth within a few hours for free!

#waitingforyoursignals

Itt található egy hasznos oktatóvideó, ami bemutatja, hogy a turistautak ábrázolására használt kapcsolatokat hogyan lehet szerkeszteni a JOSM-ban.

Konkrétan egy útszakasz megváltozását frissíti a térképen a bemutató. A "route" kapcsolatból kiveszi a régi útszakaszokat és másikat rak a helyére. A szükséges előkészítő műveletek és más hasznos tippek is láthatók, érdemes megnézni:

https://www.youtube.com/watch?v=89lLUJnw9jc

Köszi a készítőjének! :)

Japanese famous (prank and imaginary *note) university "Shinsyu University of International" announces they have switched their access map to OpenStreetMap. It shows their campus in interactive map.

It was reported via twitter, and I have checked if it causes vandalism or something worse.

But curiously, there are no such a campus data on osm.org.

As checked html source of the page, I found they built their own map instance. From their html,

OSM本家に負荷をかけないよう、またまぜか国際信州学院大学が表示されない(おそらく知名度不足)ので12以上でズームしていてキャンパスの近くなら自前の地図で表示

In order to avoid harm to OSM website, and due to OSM does not show "Shinsyu University of International" in their map (Probably we are not so famous), so render our map if zoom level upper 12 and near the campus.

Nice joke, I'm tricked :)

*note: SUI claims they are REAL university.

Hatte ich den schon mal?

Welche Richtung geht eine Fahrspur in Richtung "Bus"? Oder Richtung "psv"?

Besonders beliebt in Berlin und in NRW.

Das Schöne an dem Tagging ist, dass man das in der Regel als Ortsunkundiger nicht korrigieren kann. Also bleibt's bis zum Sankt Nimmerleins-tag wie's is

Подскажите кто - нибудь, почему на обновленной версии 4.3 навигатор Ситигид не подводит непосредственно к адресу ? г. Великий Новгород