Users' diaries

Recent diary entries

Cycle node networks and mountain passes

Posted by Richard on 4 October 2017 in English (English)

I've just added support for a couple more tags to's directions and thought it worth mentioning - everyone likes seeing their mapping being used.

First up, now includes 'knooppunten' (cycle node networks) in turn-by-turn directions. These are found in the Netherlands, Belgium and parts of Germany, and help you navigate dense cycle route networks. Here's an example:

Knooppunten example

This picks up rcn_ref= or lcn_ref= tags on nodes. also includes mountain passes in the turn-by-turn directions, for people who like riding somewhere hillier:

Mountain pass example

These are nodes (on highways) tagged natural=saddle or mountain_pass=yes with a name tag. If there's an ele tag, this will be output too.

Live in Western Europe now; will be in North America in the next update in a week or so's time. mapping and routing is updated from OSM roughly once a month. And thanks to everyone who has added knooppunten and mountain pass info to OSM!

Bicycle Parking on Worcester Boulevard

Posted by Adam Heinz on 3 October 2017 in English (English)

A quick lunchtime stroll with osmTracker in hand resulted in creating bicycle parking points on Worcester Boulevard, Christchurch, New Zealand.

The gps trace wobbled around a lot as it didn't seem to be able to get a good fix among the tall buildings but it was accurate enough to identify the points on the LINZ aerial photos.

Adam Heinz 3 October 2017

Mapping Center Turn Lanes in the United States

Posted by mvexel on 3 October 2017 in English (English)

When I moved to the United States six years ago, center turn lanes were a new thing to me. Two Way Left Turn Lanes (TWLTL) , as they are officially called, make traffic safer on busy roads where left turns are made frequently, by offering a dedicated lane for left turns:

design Source: MUTCD

When I first started to map these lanes, there was no documentation on the OpenStreetMap wiki on them, so I just started to map ways that have them with center_turn_lane=yes, thinking that I'd revisit them later if the community came up with more sensible tagging scheme.

In 2012, infamous US mapper NE2 created a page dedicated to TWCTL, adopting the British spelling centre_turn_lane=yes. There are around 6000 uses of this tag, most of them in the United States. The page was created without much if any discussion in the US community: there is only one reference to it on the talk-us mailing list[1].

Since 2012, more elaborate tools and tagging schemes have emerged to map lane configurations. I particularly like the Turn Lanes Editor JOSM plugin which, together with the Lane and Road Information paint style, offers an intuitive and visual way to add lane details to ways.


As you can see, when a two-lane road with a TWLTL is tagged using the plugin, the map paint style offers the correct interpretation. The tags on this way would be as follows:

lanes=3; lanes:forward=1; lanes:backward=1; lanes:both_ways=1; turn:lanes:both_ways=left

Even though this looks much more complicated than just centre_turn_lane=yes, the plugin makes it straightforward to map (it even remembers recently used configurations so you can easily apply to other ways) and it uses the generic lanes tagging schema that is already in wide use, and allows for tagging even the most complex lane configurations.

TWLTL have been a topic of discussion in the Telenav mapping team. We have been adding a lot of lane configuration details in Detroit and Phoenix. For now, I gave the team the following guidance:

  • For ways that don't have TWLTL tagging yet, use the plugin and the generic lanes / turn:lanes schema.
  • Where (local) mappers have already added centre_turn_lane tagging, leave it alone.

I would rather have one consistent tagging style for the United States (and other countries where TWLTLs are common. I would prefer to use the lanes / turn:lanes tagging for that. What do you think?

[1] The OSM mailing lists are notoriously hard to search. I used wget -r -np -l 1 -q -A gz && find . -name \*.gz -exec gunzip {} + && find . -name \*.txt -exec cat {} + | grep centre_turn_lane

Composite keys in OpenStreetMap: ref:highway, highway:ref or highway_ref?

Posted by Zverik on 3 October 2017 in English (English)

We all used building:levels and alt_name without giving it a second thought. Why are these keys built that way? Why not levels:building? To me, it looks like there is a rule for building composite keys.


ref is the basic tag for storing a reference number. For a reference number in some third-party table, we add a suffix: ref:third_party. That is because the new tag still contains a reference number. We have all such numbers in ref* keys. The rule of thumb is, the meaning of a value is defined by the basic tag before the suffix. ref:third_party is still a ref, and source:maxspeed is a source.

Sometimes we cannot use suffixes for historical reason. That is the case with name: we use name:en and other suffixes for names in other languages. For that reason, we build composite keys by prepending a content with an underscore: local_name or place_name. These are still names — a reversed order from the semicolon notation.

Of course, an underscore is also used for multi-word keys: public_transport and admin_level.


Then, there are namespaces. The most known is addr: with addr:housenumber and so on. Without a suffix, addr key has no meaning. The same with contact: and turn:. Namespaces are used for marking a group of tags that have the same meaning, have similar value formats and they are usually described on a single wiki page.

Some namespaces are used for tying properties to a part of the object described by the main tag, and for adding more specific properties of it. For example, building:* tags describe attributes of a building, and we also have roof:type and fire_hydrant:type. These words are most often put on the same object as a key or a value, e.g. building=yes or amenity=fire_hydrant, but also can mean a part of a structure denoted by these tags, like how buildings almost always have a roof.

The definition for namespaces is very vague, and some people mistake basic tags for namespaces. For example, we have 2.6k addr tags in the database. Sometimes people try to impose an prefix on a set of established and well-used tags to group these: it improves sorting in editors and allows for introducing many more similarly-named keys without "polluting" the namespace-less set of tags. That is what happend with "contact:" prefix: it is rare to see imports using "phone" and "website" tags without it.

Suffix or a namespace?

Telling a basic tag with a suffix from a namespace of the second type is harder. For example, what would be correct, building:height or height:building? roof:height or height:roof? This depends on four things:

  1. Which of the basic tags for each of parts is used more often, hence is expected to come first? In this case, building is used 28 times more that height. roof key is virtually unused.
  2. Which of these parts is more commonly used as a namespace? height: is used as a namespace for only three popular (more than a hundred usages) keys, none of which is globally spread. For building:, the number of prefixed keys with more than a hundred usages is around 120, for roof: — around 30.
  3. When removing the suffix, will the value be meaningful for the basic tag? It definitely won't be for building=100 m and roof=100 m, but will be for height=100 m.
  4. Will the basic tag without a suffix have the same meaning for the kind of objects with other similarly namespaced keys? In case of buildings, height would be enough without a suffix, and these tags are pretty widespread. But roofs are parts of buildings, so you would have either a suffix or a namespace.

So, for building height you would use a plain height key because of the fourth point. But for roof height, you would choose roof:height because roof: is commonly used as a prefix, as per the second point, unlike height:.

A case against brand:wikipedia

The reason for this post is the recent import of thousands of brand:wikipedia and brand:wikidata tags. I argue that the better choice would be wikipedia:brand and wikidata:brand, for the same reason as source:maxspeed and ref:whatever.

I accept the introduction of separate tags for an object and its brand: we can have two links for the McDonalds brand and a single notable restaurant under that brand. That covers the item 4 in the above list, and item 2 is not applicable, since both wikipedia and brand keys have not been used for namespaces. But points 1 and 3 are in favour of wikipedia:brand: the value is still a wikipedia article, and it is processed similarly to the value of wikipedia tag. And we have four times more wikipedia keys than brand keys.

To conclude, I suggest we do a mass-retagging of these imported or automatically processed keys before this mistake creeps into the wiki. Either wikipedia:brand or brand_wikipedia would be better options.

Past mistakes

In some cases we failed to notice composite keys in proposals that are built contrary to the norm described here. Now you have to do some non-obvious tagging, which requires looking for the correct keys in the wiki:

  • bridge:name instead of bridge_name (like old_name)
  • source:ref, though the correct key source_ref is used 10 times more often. Note that ref:source would not be entirely correct, since you should be more specific in the suffix. source=tmnt with ref:tmnt=1 would be the correct choice, better than source_ref=1.
  • This whole section on *:wikipedia prompted by this edit. Thankfully, we have only 20k of these keys, including the imported brand:wikipedia, so there is still time to fix this.

Routing QA

Posted by Cascafico on 3 October 2017 in Italian (Italiano)

Mini abstract

Come riportato nella wiki sul routing. "Checking your fix. After you have fixed an error on the map you will need to wait until the revised version of the map propagates into the routing engine you are using. This delay will depend for each engine...", uno dei problemi della Qualty Assurance (QA) è il tempo che intercorre tra la modifica OSM e l'integrazione nei database di routing. Per quel che ho visto, Grasshopper è più rapido ad aggiornarsi di Mapzen ed OSMRM, ma si tratta sempre di alcune ore per il primo e più di un giorno per gli altri.

Se trovo un problema di routing ad uno svincolo e cerco di risolverlo, il riscontro va ben oltre il tempo di editing, Vediamo quindi se possiamo ovviare a questo ritardo, in modo casalingo...

Individuiamo un router

Routino sembra essere semplice, funzionale e flessibile. La mia scelta è caduta su questo SW, perchè funziona agilmente anche sul mio OrangePi, con il quale posso fare routing sui dati per il Friuli Venezia Giulia. Per aree più estese si incontrerebbero presto i limiti hardware di questa macchinetta, per cui lasciamo il routing mondiale ai servizi sopraccitati e dedichiamoci a come generare al volo una sorta di patchwork on-demand...

Automatizziamo la compilazione

L'utilizzatore deve poter scegliere la zona geografica che vuole controllare; all'uopo (non avendo conoscenze di programmazione html5) ho creato un bot Telegram che ho chiamato RoutinoBot ed un bash script che ne gestisce i dati ottenuti. Quello che succede è:

  • il bot chiede una "Location" (da spedirgli con la "graffetta")
  • lo script lancia una query [aggiungere barrier] con le coordinate ricevute che scarica un .osm contente solo highway e restriction [e barrier] di un'area di lato 0.002° [cos(latitudine) TBD]
  • lo script esegue alcune operazioni di pulizia (il tool di routino planetsplitter non accetta tag "metà" e "note" nei .osm in input) ed aggiona database ed estremi della mappa navigabile;
  • al bot viene mandato un messaggio da @Cascafico [TBM] a segnalare l'aggiornamento.
  • la mappa navigabile, aggiornata con la nostra patch, é accesibile sulla webGUI di routino

Per ogni Location inviata, sul server viene salvato il relativo .osm e viene ricompilato il database di routino [aggiornamento incrementale TBD]. Considerato che è un servizio di test finalizzato al controllo QA di dati "freschi", ogni Location più vecchia di 24h viene cancellata.

[articolo in compilazione...]

Craft mapping is the best method...

Posted by RobJN on 2 October 2017 in English (English) say a minority of people.

If you read the OpenStreetMap mailing lists, or follow (non-OSM) news then you'd be forgiven for thinking that we live in a world where people's views have become incredibly narrow. But in shock news from State of the Map 2017 we discover that most people can happily live alongside their fellow mappers.

During my live-polling session at SotM, I asked the audience to participate in a series of questions via the online polling system, DirectPoll. You can watch the video and review the results in full.

But today, say hooray to the 85% who say that "We need all forms of mapping / they are all equally important".

OSM Live Polling results


Оновлення супутникових знімків Mapbox

Posted by andygol on 2 October 2017 in Ukrainian (Українська)

Нещодавно ми додали 8.2 мільйонів км² знімків високої роздільної здатності від DigitalGlobe до нашого шару супутникових знімків. Більш докладно про це дивіться тут →

Всі знімки доступні для використання в OpenStreetMap для мапінгу! 🎉

Ми покращили покриття наступних регіонів та територій:


Головні міста та території навколо: на Близькому Сході, Індії, Китаї, Туреччині, В'єтнамі, Таїланді, Малайзії, Південній Кореї, Індонезії та Філіппінах.


Єгипет та частково Кенія.


Великі міста в Польщі, Україні, Румунії, Ісландії та Угорщині. Також, Париж та Москва.

Південна Америка

Основні райони Бразилії, Парагваю, Уругваю, Аргентини та Чилі.

Північна Америка

Великі частини Мексики, Куби та Центральної Америки, а також південні міста Канади.

Ці знімки надають можливість для докладного нанесення на мапу виступів будинків, напрямків руху по смугах, дерев та багато чого іншого! Приємного мапінгу!🌐

Ріо-де-Жанейро Ріо-де-Жанейро

Сплав деревини біля Ванкувера Сплав деревини біля Ванкувера

Вулкан Іджен, Східна Ява, Індонезія Вулкан Іджен, Східна Ява, Індонезія

Новий президентський палац, Абу-Дабі, ОАЕ Новий президентський палац, Абу-Дабі, ОАЕ

Часті питання

Мапінг: Всі ці знімки ліцензовано для використання в OSM для додавання даних.

Джерела: Усі знімки надані DigitalGlobe; вони були отримані з їх супутників.

Дати: Різноманітні. Ми не надаємо інформацію про дати знімків в їх метаданих, але ми знаємо, що це важливо для OSM, і ми сподіваємося зробити це в майбутньому.

Якщо ви зіткнулись з дефектами на знімках, у вас є потреба в знімках для певної території та якщо у вас є інші зауваження та пропозиції – скористайтесь формою зворотнього зв’язку →


Posted by lpelo2000 on 2 October 2017 in Italian (Italiano)

Ciao, oltre che il paesello di mio padre, Grotte Santo Stefano, ho mappato spot anche Casciana Terme: paese in provincia di Pisa dove sono andato a fare qualche giorno di terme nel dicembre del 2016.

Sto utilizzando l'app StreetComplete per completare i tag mancanti per le mappature già eseguite dei posti in cui mi trovo.


"Mapping Well With Mapsme"

Posted by Anton Khorev on 1 October 2017 in Russian (Русский)

После прочтения этого топика на форуме возникает желание прокомментировать упомянутый там доклад Mapping Well With Mapsme.

"Вместо того, чтобы собственно редактировать данные, можно добавлять метки"

Чего не было сказано: метку может не получиться поставить в нужное место, особенно если оно занято площадным объектом - это может проявляться по-разному в зависимости от зума. Можно попробовать ставить метку на фиктивный объект, для чего сначала надо добавить любую точку, затем поставить на неё метку, затем удалить точку. Удалить точку можно только если она не отправлена, см. ниже.

Подобным образом ставить метки вряд ли удобно и делать это надо осторожно. Я попробовал для примера создать фиктивную точку, но тут проявилась такая особенность - показывать последнее известное местонахождение, даже когда об этом никто не просит. В итоге вид съехал ко входу в метро, перед которым я выключил gps, а я не помнил, куда я поставил точку. Хорошие новости: даже добавленные пользователем точки попадают в результаты поиска.

"При добавлении места выдаётся длинный список типов, но мы типа об этом подумали и у нас есть поиск"

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

" отсылает данные, когда приложение закрывается"

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

Если нужно включить интернет, а только для его не перекрыть, то перед включением интернета можно для гарантии прибить через диспетчер приложений. А если ещё и на карту смотреть хочется, то у вас наверняка установлен osmand. Ещё надо проверить вариант помехи отправки данных посредством разлогинивания.

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

"Обычное имя, которое без языка, защищается, чтобы его не грохнули туристы"

Сам рассказ про редактирование названий сопровождается скриншотом, где поле "English" заполнено по-японски - имеет обыкновение самостоятельно его заполнять. Докладчика это не смущает, хотя для пользователя наверняка важно, запишется это всё в name:en или нет. Когда я подобное заполнение поля "English" русским названием удалял, в результате не создавалось и name:ru. Я до сих пор не уверен, что именно произойдёт при редактировании имени, и логика там, похоже, менялась в недавних версиях.

Защиту "настоящего" name можно охарактеризовать и по-другому: не даём пользователю ожидаемого способа полностью переименовать точку. В результате этого в разных name будут разные названия. Тогда зачем вообще давать редактировать название, ведь можно было бы давать только добавлять новые языковые варианты. Например, можно было бы показать "настоящее" нередактируемое название, а рядом поставить кнопочку "добавить перевод". У некоторых объектов название менять и не дают, например у зданий и, следовательно, у poi, совпадающих со зданиями. В этом случае под редактирование подставляется номер дома, хорошо, что там валидатор.

"Если попытаться создать точку очень близко к другой точке, то вместо этого будет выполнено редактирование"

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

Так отредактировать, не зная того, что это именно редактирование, можно даже невидимую из точку. В докладе утверждается, что это редко происходит, но происходит. И зачем оно происходит? Тут можно подумать, что это защита от всем известных мапсмешных дублей, но если бы эта защита работала, то дубли не были бы всем известны. Работать она так не сможет, потому что никто не мапит с сантиметровой точностью, и дубль спокойно разместится метрах в трёх от своего предшественника.

"Если вы при добавлении точки не можете найти для неё правильный тип, то поставьте неправильный и напишите заметку, а правильный поставьте потом"

Здесь докладчик даёт вредный совет. Не удивляйтесь, если подобные действия будут считать вандализмом. Поскольку правильный тип из вы и позже не поставите, это тот случай, где на вопрос "как правильно редактировать из" ответом является "никак". То есть из придётся либо редактировать неправильно, желательно задерживая загрузку данных способом, описанным выше, либо не редактировать, а ставить метку, с возможными проблемами, описанными ещё выше.

Mapping party Viverone 01/10/2017

Posted by mikki65 on 1 October 2017 in Italian (Italiano)


Marking Monuments and Statues, Tagging New Construction

Posted by apm-wa on 1 October 2017 in English (English)

The Asian Indoor and Martial Arts Games are over so traffic is going back to normal.

Today we (my wife, daughter and I) visited Vatutin Cemetery to collect locations of more grave monuments commemorating prominent people. The Mapillary upload is underway so I should get that done fairly soon. A number of them have streets named after them here in Ashgabat.

I have added a number of historic names of streets in downtown Ashgabat to the OSM database so that folks who use an old historical name will potentially find the entire list of names, wherever I have been able to find them. Not done yet--there are still a few mysteries!

Also, signs are now up on the 11 new retail buildings in the former Gazha neighborhood, though not one of them is open yet. I have tagged the buildings with the names as shown on the outside of the buildings, and added a few driveways and parking lots that serve them. I shot Mapillary imagery at night, capturing all the neon.

Neon-lit shop on Mollanepes köçesi in Ashgabat

Location: Alley of Glory, Ashgabat, 744020, Turkmenistan

number of keys grows, and grows, and grows ...

Posted by Harald Hartmann on 1 October 2017 in English (English)

In the past three weeks (starting from 10th Sep) I have worked on the OSM Latest Keys list almost every day (with an average of one hour each time). In doing so, I have strictly adhered to

If using information from this page to make changes to the OSM database - please keep in mind the usual guidelines: No mechanical edits, no changes without checking validity of tags, inform the original mapper politely, don't delete any relevant information...

and didn't make a single change itself, but instead wrote nearly 500 changeset comments.

Of these 500 changeset comments, only half of the comments were answered and the error addressed was corrected by the original mapper. In the other half it was felt so (exact numbers I could not find unfortunately), that in turn the half corrected itself (without a reply by changeset comment to confirm), and the other half fixed by other mappers (eg mueschel , Thomas8122, mapper999, and others).

I personally hoped that the curve of historical development would be flatter. For this I then created the following graphic today, which show the last three weeks as well as the three weeks before the start of my action:

number of keys

Yes, it was flatter, but not as flat as I had hoped. Of the approximately 990 new keys in the last three weeks, only about 330, so only one third have disappeared again, the other two thirds have remained ... and will probably remain, since there are no more simple misspellings or incorrectly used keys. Well, maybe you could get 50%, but a hard fight would have to be done to convince the original mapper to keep more (abstract) to the existing tagging.

On the topic "misspellings" I had right at the beginning of the action asked in the german forum how to minimize new keys. It would be nice, if the editors would do this job, but they will probably not make more. Also the request API: check (and notificate) for new keys after close changeset, has been denied. It follows that ultimately it only helps if a series of mappers continuously work on the list mentioned above.

PS: There is also another interesting large range, if you look at the keys list and sort it by object (count): according to taginfo there are about 24,000 keys, almost one third of the total keys, which at all only one time were used! And probably a third of them are just misspellings.

PPS: Last but not least, there is the similar key list by taginfo ...

Article de sensibilisation à OpenStreetMap auprès des enseignants

Posted by Cdrik_69 on 1 October 2017 in French (Français)

Je viens de rédiger cet article sur le site de la Délégation Académique au Numérique Éducatif de l'Académie de Lyon :

OpenStreetMap, la cartographie collaborative !

A noter que l'article est en licence CC by-sa.

Anzahl der Keys wächst, und wächst, und wächst ...

Posted by Harald Hartmann on 30 September 2017 in German (Deutsch)

In den vergangenen drei Wochen (beginnend ab 10.09.) habe ich mich fast täglich (mit durchschnittlich je einer Stunde Zeitaufwand) mit der OSM Latest Keys Liste beschäftigt und auseinandergesetzt. Dabei habe ich mich strikt an

If using information from this page to make changes to the OSM database - please keep in mind the usual guidelines: No mechanical edits, no changes without checking validity of tags, inform the original mapper politely, don't delete any relevant information...

gehalten und keine einzige Änderung selbst durchgeführt, sondern stattdessen fast 500 Changeset-Kommentare geschrieben.

Von diesen 500 Changeset wurden nur knapp die Hälfte beantwortet und der angesprochene Fehler größtenteils auch vom ursprünglichen Mapper korrigiert. Bei der anderen Hälfte war es gefühlt (genaue Zahlen konnte ich leider nicht ermitteln) so, dass wiederum die eine Hälfte es selbst korrigiert hat (ohne dies durch eine Antwort per Changeset Kommentar zu bestätigen), und die andere Hälfte von anderen Mappern (z.B. mueschel, Thomas8122, mapper999, und weitere) korrigiert wurden.

Erhofft habe ich mir persönlich von der ganzen Arbeit, dass die Kurve der historischen Entwicklung flacher wird. Dazu habe ich mir dann heute folgene Grafik erstellt, welche die letzten drei Wochen sowie die drei Wochen vor dem Beginn meiner Aktion zeigen:

Anzahl Keys pro Tag

Ja, sie wurde flacher, aber nicht so flach wie ich erhofft hatte. Von den ca. 990 neuen Keys in den letzten drei Wochen, sind nur ca. 330, also nur ein Drittel wieder verschwunden, die anderen zwei Drittel sind geblieben ... und werden wohl auch bleiben, da es sich dort nicht mehr um einfache Schreibfehler oder falsch verwendete Keys handelt. Gut, vielleicht könnte man noch auf 50 Prozent kommen, dazu müsste aber ein harter Kampf geführt werden, um den ursprünglichen Mapper davon zu überzeugen, sich mehr (abstrakter) an das bestehende Tagging zu halten.

Zum Thema "Schreibfehler" hatte ich gleich am Anfang der Aktion im Forum gefragt, wie man neue Keys minimieren kann/könnte. Es wäre zwar schön, wenn es die Editoren machen würden, werden sie aber wohl eher nicht machen. Auch die Anfrage API: check (and notificate) for new keys after close changeset, also auf neue Schlüssel beim Abschließen eines Changesets zu Prüfen und zu Benachrichtigen, wurde abgelehnt. Daraus folgt, dass es letztendlich nach aktuellem Stand nur hilft, wenn sich eine Reihe von Mappern findet, welche die o.g. Liste kontinuierlich "abarbeitet".

PS: Es gibt da auch noch einen anderen interessanten großen Bereich, wenn man sich die keys Liste anschaut und mal nach Objekt(-anzahl) sortiert: laut taginfo gibt es ca. 24.000 keys, also fast wieder ein Drittel der gesamten Keys, die überhaupt nur ein einziges mal verwendet wurden/werden!! Und davon sind vermutlich auch wieder ein Drittel einfach nur "Schreibfehler".

PPS: Zu guter letzt gibt es ja auch noch die ähnliche Keys Liste von taginfo...

Erreur carte France 67300 schiltigheim

Posted by PhareT on 30 September 2017 in French (Français)

La numérotation de deux immeubles est fausse: rue Jean Monnet à Schiltigheim 67300. Les 4 et 4a doivent être inversés

Як все почалося

Posted by Urii_67 on 29 September 2017 in Ukrainian (Українська)

Почалося з того,що підігнали мені навігатор Garmin родом із Америки. Поїхав я з ним до села жінки - побачив , що доріг в селі не промальовано ГЕТЬ ! Зразу малював у Google але щось мене відлякало.
Тоді десь прочитав за OSM та почав мапити.

Why shouldn't everything have a name?

Posted by SomeoneElse on 28 September 2017 in English (English)

A previous diary entry explains how I created a basic map legend for a map that I maintain that highlights various things common near me that tend not to get shown very well elsewhere - public footpaths, hiking trails, offices, that sort of thing. It struck me that a lot more things had names than almost any other map (other than OSM Bright) actually shows.

I therefore went through a process of looking to see what tags people used names with (it's almost everything - here's a named cattle grid), and what they used as the "naming tag" for various things (mostly "name", obviously). The result is here:

Map legend showing named POIs

although to get a better idea of things click here and zoom around.


Posted by madrono244 on 28 September 2017 in Spanish (Español)

El madroño es uno de los muchos nombres comunes que tienen los árboles con nombre científico Arbutus Unedo, este árbol es parte de la especie de arbusto y su género es Arbutus. Este género se caracteriza por formar parte de la familia Ericaceae, este grupo está compuesto por 11 especies y hasta 100 descritas, entre los cuales se encuentran algunos árboles y arbustos nativos del mediterráneo, Norteamérica y Europa occidental.

Esta familia es conocida como Ericaceae y se caracteriza por pertenecer a la orden de las ericales. Aqu´se incluyen árboles, arbustos o matas, leñosas y de fruto. Abunda en las zonas templadas y frías, más que todo trópicos, con presencia en las montañas. Pueden adaptarse a terrenos con poca fertilidad y se desenvuelven en suelos ácidos, se desarrollan gracias a la simbiosis producida por las micorrizas.

Características del Madroño El madroño tiene muchas características emocionantes que lo identifican, vamos a echar un vustaz y aprende más sobre este árbol increíble que puede ser un elemento decorativo y muy tierno por su pequeño tamaño de arbusto. Identificar este árbol puede tener una corteza áspera, con colores que va desde pardo a rojiza y está fisurada, no puede desprenderse en ningún momento.

Si hablamos de las ramas más jóvenes son de color rojo, mientras que las hojas son lanceoladas, dentadas y tienen un haz de color verde oscuro y brillante con un envés de color pálido y sin vellos, es decir, son hojas lampiñas.

Si hablamos de las características de estas flores, podríamos decir que estas son muy pequeñas, de color blanco y de vez en cuando rojizas, son fluorescentes que cuelgan de sus brotes. Tienen una forma original y agradable.

Por otro lado, el fruto se puede identificar por su forma común de baya, el color varía entre naranja y rojo, tiene cientos de verrugas ásperas y el diámetro es de al menos 2 cm. Puede madurar en otoño y si hay flores, estas servirán para los frutos del año próximo.

Mara Ort: A map is a map is a map?

Posted by -karlos- on 28 September 2017 in English (English)

Many Mappy Minutes

Posted by mvexel on 28 September 2017 in English (English)

In my last diary, I announced that I would be restarting the virtual Mappy Hour for US / North America mappers. We had our first edition tonight and I enjoyed it very much.

Around 10 people participated. Kate Chapman from OpenStreetMap US joined us to talk about the upcoming State of the Map US conference, which is only four weeks away. We chatted about a variety of interesting topics: welcoming new members, how people become interested in OSM, membership of the OSM Foundation, hack weekends, how to best announce OSM events, and many more things.

The plan was to have this be a mappy 'hour' but we ended up spending two hours talking. We came up with a new name: Many Mappy Minutes. We decided to organize it about once a month. The next Many Mappy Minutes will be on November 1, at 5:30pm Pacific Time. Zoom worked well, so we will continue to meet on there: . You can also dial in from a normal phone. I hope to talk to you then!