Users' diaries

Recent diary entries

Non-English keywords in English iD interface.

Posted by Dzertanoj on 18 January 2018 in English (English)

I just noticed an interesting thing. If you want to create a point indicating a garbage dumpster (trash container or whatever similar) using iD with the English language interface, you add a point geometry and then start typing "garbage" in the Search field. Once you've typed "gar", found tagging options will be related to anything "garden" and "garbage", but there will also be a "ॐ Hindu Temple" as a sixth item. If you type one more letter and make it "garb", you'll have everything "garbage", but Hindu Temple will jump to the second place.

I'm not claiming that I know how it works, but I assume that there are keywords tied to an interface language and to every tag or set of tags for a specific object. They seem to be language-dependent (while it is still possible to type something in German, like "wald", and get Wood as an option), otherwise, there would be a lot more confusion with similarly spelled keywords from different languages.

However, I don't see any logic in this specific situation. As Wikipedia says, "Garbhagriha" is a Sanskrit word for a part of a Hindu temple (not even for a temple itself). How often might it be typed in Latin alphabet by iD users? Does it really belong to English interface, keeping in mind that English is not the main language in any of those countries where Hindu religion is prominent enough? It definitely belongs to Hindu and some other languages, but English? By the way, if you try typing "altar" (also a part of a temple in many religions) - nothing related to temples or cathedrals will pop up. Considering this logic, Hindu Temple should not show up on a list after typing "gar" or "garb" in a search form.

Just to be clear: I don't care if it will continue popping up - it looks amusing to me, not just "wrong". I'm not going to dig into iD's complicated structure and register on any translation services to fix that.

Ong PPR Vesbo Cao Cap Thanh Trang

Posted by Ống nước PPR Vesbo on 18 January 2018 in Vietnamese (Tiếng Việt)

Khi thi công một công trình xây dựng, việc thiết kế một hệ thống cấp nước là một việc cực kỳ quan trong. Để đảm bảo hệ thống được vận hành an toàn cùng sự đảm bảo vệ sinh an toàn thực phẩm thì việc lựa chọn một loại ống nước chất lượng phù hợp với tiêu chí công trình là một điều cần thiết.

Với chất lượng đã được khẳng định ở nhiều quốc gia lớn như Đức, Anh, Singapor... Ống cấp nước PPR Vesbo chính là sự lựa chọn hoàn hảo dành cho hệ thống cấp nước. Doanh Nghiệp Thành Trang với kinh nghiệm hơn 20 năm trong vật tư ngành nước đã tự hào trở thành đơn vị phân phối độc quyền sản phẩm ống PPR và phụ kiện PPR Vesbo trên cả nước Việt Nam.

Hãy cùng tìm hiểu thêm về sản phẩm Ống nước PPR để biết tại sao nó lại được tin dùng như thế nhé!

Mayon's core dange zone mapping is 100% complete - thank you!

Posted by GOwin on 17 January 2018 in English (English)

Mt. Mayon ash plume. Photo credits: unknown.

Mayon, the Philippines most active volcano, with 48 historical eruptions is restive. Over the weekend, tremors, lava fountaining, and lava collapse events has been noted. Government volcanologists report that “relatively high level of unrest as magma is at the crater and hazardous eruption is possible within weeks or even days.

The authorities has prohibited the public from entering the 6 kilometer-radius Permanent Danger Zone (PDZ), and the 7-km Extended Danger Zone (EDZ) on the southern flanks “due to the danger of rockfalls, landslides and sudden explosions or dome collapse that may generate hazardous volcanic flows.”

Yesterday morning, we appealed for help to map the 6-kilometer Permanent Danger Zone of Mayon, and the community responded quickly. Today, it's been 100% mapped, 57% validated (and still on-going). Thank you! The names of the generous mappers may be found in the project dashboard.

Mayon Permanent Danger Zone (PDZ): 100% mapped. 57% validated.

Today, a new project to map the 7-kilometer Extended Danger Zone (EDZ) around Mayon has been published: and we are again appealing for some of your precious time, and valued mapping skills, to map the EDZ. Most especially the priority tasks in the southern quadrant, where there are a number of villages and settlements.

Again, this is preemptive mapping activity to assist local government agencies and aid organizations to support future damage assessment. We call on the digital humanitarian community for their assistance for this project.

Location: New Lidong Trail, Legazpi, Albay, Bicol Region, 4508, Philippines

Motorway Junction Node Placement

Posted by daniel-j-h on 17 January 2018 in English (English)

It isn't always obvious where to position a highway=motorway_junction node that connects a motorway way to a motorway_link way (also known as an off-ramp or slip road). Over the years, mappers have used three different approaches.

Inconsistent placement of junction nodes can affect turn-by-turn navigation software, particularly instruction timing and rerouting. I'd like to raise awareness about the preferred placement, which is at the beginning of the gore, and explain why the other two approaches are suboptimal.

Throughout this post, I will refer to the term gore. A gore is a wedge that separates a ramp from the main motorway. A physical gore may be a barrier or a grassy area, whereas a theoretical gore simulates this separation using pavement markings and empty space. By “gore”, I am referring to the beginning of the theoretical gore, if present, or alternatively the physical gore.

Approach 1: Map the ramp node at the exit sign

Rationale: In the majority of urban areas a detailed overhead exit sign is located at the last point where the off ramp maneuver can take place - the physical or theoretical gore.


  • Many rural exits (and some urban exits, depending on the state) lack overhead signage. Instead, the only sign is located on the side of the road (at the beginning of the deceleration lane or even earlier), accompanied by a small “Exit” sign at the gore.
  • In many cases, the exit sign occurs well after a lane change restriction (change:lanes) begins (example - note the solid white line). However, lane issues should be remedied through tagging, not geometry alterations.

Example. In this case the exit sign and the theoretical gore are located at the same location. This is the last location where driver can exit the motorway. When the sign board is right next to the gore this approach makes sense.

Example. The exit sign does not coincide with the theoretical gore in this case. The exit sign is positioned much earlier than the gore. In this case mapping the exit from the sign position will not make sense.

Approach 2: Map the ramp node where the road begins to widen

Historically, some mappers have preferred to start the ramp at the point the road widens, mainly for aesthetic purposes.

Rationale: This appears smoother on a map rendering as it more accurately represents the path a driver should take to use the ramp.


  • If a driver has passed the point where the road begins to widen but has yet to reach the gore (or the start of chevron markings), it’s too early to reroute the user as if they missed the exit.
  • The exit may have a longer deceleration lane. If the junction node is placed at the beginning of the deceleration lane, the user’s distance to the junction node may differ from signage, creating confusion.
  • Does not accurately reflect the features on the ground.

Example (same junction as Approach 1 example):

Approach 3: Map the ramp node at the gore of the main road and ramp

This is the approach documented on the wiki. It balances the needs of renderers and routers.


  • Allows for precise lane mapping, as the junction node reflects reality.
  • Staggered exit lanes should be modeled using turn:lanes tags instead of separate ways.
  • The junction node reflects the exact point where it is no longer possible to cross back onto the highway, consistent with the practice of mapping a dual carriageway only when there’s a definite separation.


  • On rendered maps, the turn angle looks sharper than expected when zoomed way in.
  • Less sophisticated routers may consider the actual turn angle to be much sharper than in reality.
  • In some cases, the gore begins well after a lane change restriction (change:lanes) begins (example - note the solid white line). However, it’s better to add the lane change restriction as a change:lanes tag than to draw the entire exit lane as a separate way.

In approach 2 the ramp node is placed where the road begins to widen. In the same example, if approach 3 is used the ramp would appear like this:

Example: The junction node near the gore where it not possible to change lanes back to the highway.

Although this approach tries to place the junction node close to the gore, it isn’t necessary to make it exactly flush with the gore. The motorway_link would meet the motorway at a 90° angle, which would result in unintuitive rendering. A roughly 45° angle strikes a better balance between the needs of renderers and routers.


Based on this evaluation, we believe the best practice for mapping ramps is (Approach 3) map the ramp node at the gore of the main road and ramp. This follows the wider OSM convention of prioritizing mapping based on the physical barriers, is appropriate for diverse geographies, and aligns with developing work around lane guidance.

As next actions, from now on, the team at Mapbox will fix these ramp geometries by following the convention stated in approach 3 when we come across ramps mapped according to other approaches. It would be great to have everyone follow this approach as well when mapping ramps and make changes to existing ramp intersections that you come across. If there is consensus around this approach let’s update the wiki with further details to promote this practice.

Modellierung von Ausfahrten

Posted by daniel-j-h on 17 January 2018 in German (Deutsch)

Es ist nicht immer offensichtlich wo eine highway=motorway_junction Node, an der ein motorway_link Way abgeht, gemappt werden soll. Im Folgenden betrachte ich die drei am häufigst genutzten Modellierungsmethoden mit ihren Vor- und Nachteilen insbesondere im Hinblick auf die Routenplanung und Navigationsansagen.

Dabei dient folgendes Schema als Grundlage in welchem der “physical gore” die physische Abgabelung der Strasse und der “theoretical gore” den Beginn der Fahrbahnflächenmarkierung darstellt.

Modellierung I: Node am Ausfahrtsschild

In manchen Fällen gibt es ein letztes Überhangs-Schild an dem das Abbiegemaneuver noch getätigt werden kann.


  • Bei vielen ländlichen, und manchen städtischen, Ausfahrten fehlt ein solches Überhangs-Schild. Stattdessen gibt es ein Schild weit vorher am Strassenrand, gefolgt von einem kleinen “Exit” Schild.
  • In vielen Fällen ist das letztes Überhangs-Schild weit nach einem Spurwechselverbot (change:lanes) aufgestellt (Beispiel mit durchgezogener Linie). Diese Spurwechselverbote haben natürlich keinen Einfluss auf die Strassengeometrie.

Beispiel: hier ist das Ausfahrtsschild weit vor der eigentlichen Ausfahrt. Das Aufspalten des Weges bereits an diesem Schild macht keinen Sinn.

Modellierung II: Node an der Strassenaufteilung

Eine weitere Möglichkeit die highway=motorway_junction Node zu platzieren ist an der Stelle an der sich die Strasse beginnt aufzuteilen. Diese Art zu Mappen kommt vor Allem der Ästhetik beim Karten rendern zu Gute.


  • Falls der Autofahrer die Ausfahrtsnode verpasst hat ist es dennoch möglich die Ausfahrt zu nehmen und eine erneute Routensuche würde zu früh stattfinden.
  • Die Ausfahrt kann eine lange Abbremsspur haben was dazu führen kann, dass die Distanz, die die Routenplanung berechnet, nicht mit den Schildern übereinstimmt.

Beispiel für eine solche Situation:

Modellierung III: Node an der Fahrbahnflächenbegrenzung

Diese Art der Modellierung ist in der Wiki beschrieben. Dabei wird die Node so platziert, dass ein Autofahrer dort die letzte Möglichkeit zum Abbiegen hat.

Damit ist der Weg frei für ein präzises Spuren-mapping, und eventuelle staggered exit lanes können als turn:lanes getaggt werden.


  • Auf Karten sieht der Abbiegevorgang steiler aus als er eigentlich ist, wenn man nahe heran zoomt
  • Das Selbe gilt für Router, wobei die meisten Router sowieso nicht einfach die naechste Node zur Winkelberechnung nehmen.

Spurwechselverbote können jetzt mit dem change:lanes Tag gemappt werden, anstatt mit einem separaten Weg.



Basierend auf der Evaluation der oben aufgeführten drei verschiedenen Möglichkeiten der Modellierung und ihren Vor- und Nachteilen empfehle ich den letzten Ansatz: die Node an der Fahrbahnflächenmarkierung zu mappen.

Diese Art der Modellierung folgt der gebräuchlichen OSM Konvention physische Hindernisse zu mappen, trifft zu auf verschiedenste Länder, und macht den Weg frei für präzises Mappen von Spuren.

Voyage pays du nord

Posted by Miki d'Alsace68 on 17 January 2018 in French (Français)


Location: Haninge, Landskapet Södermanland, Stockholms län, Svealand, Suède

It starts with the planet - downloading OSM the right way

Posted by pnorman on 17 January 2018 in English (English)

This is a repost of an entry on my blog.

To do something with OpenStreetMap data, we have to download it first. This can be the entire data from or a smaller extract from a provider like Geofabrik. If you're doing this manually, it's easy. Just a single command will call curl or wget, or you can download it from the browser. If you want to script it, it's a bit harder. You have to worry about error conditions, what can go wrong, and make sure everything can happen unattended. So, to make sure we can do this, we write a simple bash script.

The goal of the script is to download the OSM data to a known file name, and return 0 if successful, or 1 if an error occurred. Also, to keep track of what was downloaded, we'll make two files with information on what was downloaded, and what state it's in: state.txt and configuration.txt. These will be compatible with osmosis, the standard tool for updating OpenStreetMap data.

Before doing anything else, we specify that this is a bash script, and that if anything goes wrong, the script is supposed to exit.

#!/usr/bin/env bash

set -euf -o pipefail

Next, we put the information about what's being downloaded, and where, into variables. It's traditional to use the Geofabrik Liechtenstein extract for testing, but the same scripts will work with the planet.



We'll be using curl to download the data, and every time we call it, we want to add the options -s and -L. Respectively, these make curl silent and cause it to follow redirects. Two files are needed: the data, and it's md5 sum. The md5 file looks something like 27f7... liechtenstein-latest.osm.pbf. The problem with this is we're saving the file as $PLANET_FILE, not liechtenstein-latest.osm.pbf. A bit of manipulation with cut fixes this.

CURL='curl -s -L'
MD5="$($CURL "${PLANET_MD5_URL}" | cut -f1 -d' ')"
echo "${MD5}  ${PLANET_FILE}" > "${PLANET_FILE}.md5"

The reason for downloading the md5 first is it reduces the time between the two downloads are initiated, making it less likely the server will have a new version uploading in that time.

The next step is easy, downloading the planet, and checking the download wasn't corrupted. It helps to have a good connection here.

$CURL -o "${PLANET_FILE}" "${PLANET_URL}" || { echo "Planet file failed to download"; exit 1; }

md5sum --quiet --status --strict -c "${PLANET_FILE}.md5" || { echo "md5 check failed"; exit 1; }

Libosmium is a popular library for manipulating OpenStreetMap data, and the osmium command can show metadata from the header of the file. The command osmium fileinfo data.osm.pbf tells us

  Bounding boxes:
  With history: no

The osmosis properties tell us where to go for the updates to the data we downloaded. Despite not needing the updates for this task, it's useful to store this in the state.txt and configuration.txt files mentioned above.

Rather than try to parse osmium's output, it has an option to just extract one field. We use this to get the base URL, and save that to configuration.txt

REPLICATION_BASE_URL="$(osmium fileinfo -g 'header.option.osmosis_replication_base_url' "${PLANET_FILE}")"
echo "baseUrl=${REPLICATION_BASE_URL}" > 'configuration.txt'

Replication sequence numbers needed to represented as a three-tiered directory structure, for example 123/456/789. By taking the number, padding it to 9 characters with 0s, and doing some sed magic, we get this format. From there, it's easy to download the state.txt file representing the state of the data that was downloaded.

REPLICATION_SEQUENCE_NUMBER="$( printf "%09d" "$(osmium fileinfo -g 'header.option.osmosis_replication_sequence_number' "${PLANET_FILE}")" | sed ':a;s@\B[0-9]\{3\}\>@/&@;ta' )"


After all this has been run, we've got the planet, it's md5 file, and the state and configuration that correspond to the download.

Combining the code fragments, adding some comments, and cleaning up the files results in this shell script

#!/usr/bin/env bash

set -euf -o pipefail


CURL='curl -s -L'

# Clean up any remaining files
rm -f -- "${PLANET_FILE}" "${PLANET_FILE}.md5" 'state.txt' 'configuration.txt'

# Because the planet file name is set above, the provided md5 file needs altering
MD5="$($CURL "${PLANET_MD5_URL}" | cut -f1 -d' ')"
echo "${MD5}  ${PLANET_FILE}" > "${PLANET_FILE}.md5"

# Download the planet
$CURL -o "${PLANET_FILE}" "${PLANET_URL}" || { echo "Planet file failed to download"; exit 1; }

md5sum --quiet --status --strict -c "${PLANET_FILE}.md5" || { echo "md5 check failed"; exit 1; }

REPLICATION_BASE_URL="$(osmium fileinfo -g 'header.option.osmosis_replication_base_url' "${PLANET_FILE}")"
echo "baseUrl=${REPLICATION_BASE_URL}" > 'configuration.txt'

# sed to turn into / formatted, see
REPLICATION_SEQUENCE_NUMBER="$( printf "%09d" "$(osmium fileinfo -g 'header.option.osmosis_replication_sequence_number' "${PLANET_FILE}")" | sed ':a;s@\B[0-9]\{3\}\>@/&@;ta' )"


Nominatim and Postcodes

Posted by lonvia on 16 January 2018 in English (English)

Nominatim (the search engine that powers the search box on the OpenStreetMap website) has recently changed significantly its way how postcodes are handled. This post tries to give a bit of background on what has changed and why.

When you search for a place on, Nominatim not only presents the name of the place in the result but a complete address. This address not only helps distinguish the different places but is also used to narrow down your search. This address is not a postal address as you would put on a postcard. It is more a textual description where the place is located, in which suburb, city, state, country etc. This information is fairly easy to compute from OSM data. There are areas for all these administrative areas. So Nominatim just needs to check in which areas a place is inside, order all appropriately and there is the address.

Postcodes, however, are different. In most countries there is no such thing as postcode areas. Postcodes are simply assigned to a some place (a house or POI) in a fashion that is deemed most practical for the local postal service. Often the post codes follow delivery routes. It might be possible to draw an area around houses with the same postcode but this would be an artificial distinction and there is no guarantee that the resulting areas don't overlap.

For that reason, there are very few boundaries in OSM that describe postcode areas. Mostly postcodes can be found on house numbers and POIs in the addr:postcode tag. But even here coverage is rather sparse. So when computing the address of a place, Nominatim has to go a different way to determine the most likely postcode for a place where no addr:postcode tag exists.

With the new version, Nominatim tries two different methods to infer the postcode of the place: an address lookup and an area-based lookup.

The address lookup comes first. Nominatim assembles all other parts of the address and then checks if any part of the address carries an addr:postcode tag that might apply. It does that going from the most specific part of the address, the street, up to the most generic one, the country. As soon as it finds an appropriate tag, it stops and uses the postcode. This means that when tagging postcodes you can start with assigning an approximate postcode for a larger area, like a complete village or suburb, and then later come back and add addr:postcode tags to the handful of houses that are the exception to rule (or even complete postcode coverage for the whole village and then delete the postcode tag on the village again).

If there is no postcode to be found in the address, Nominatim tries the area method. That means that it ideally should be looking for the closest object with an addr:postcode tag within a certain area and use that postcode as a guess. This is unfortunately a bit expensive, so Nominatim implements a simplified version. For each postcode, it looks for all the points in OSM that are tagged with the appropriate addr:postcode tag and computes one central point, the postcode centroid. When guessing the postcode of an object with the area method, the closest postcode centroid is used. This is not quite as accurate but considerably faster. The postcode centroids are also used when you search for a postcode. If OSM has no postcode area, then an artificial point is returned with the same location as the centroid.

Postcode centroids have been a feature of Nominatim for a long time. However, they have always been static and only computed once when the database was initially imported. Starting with the next release, postcodes become their own entity in Nominatim and can be regularly recomputed and updated. On this is already done once per day now.

Finally, there is also a change in the way postcodes are handled in your search query. Formerly, if you added a postcode to your search, you had to use the one that Nominatim had guessed for the place or you would get no result at all. That was particular annoying when Nominatim had guessed wrong and the search had the right postcode. With the new version Nominatim is now able to detect postcodes in the query and ignore them, if necessary. So if a place has a wrong postcode in Nominatim it is now nonetheless able to find the place by the correct address. There is one catch though: Nominatim needs to understand that the part of your query is indeed a postcode. At the moment it takes this information from OSM itself. That means it can really only detect (and ignore) postcodes that have been previously mapped in OSM somewhere. At some point, it will learn to detect postcodes by their format but that is a project for a future version of Nominatim.

Mi experiencia en SOTM 2017

Posted by juanlacueva on 16 January 2018 in Spanish (Español)

Conferencia de mapas abiertos en Japón - SOTM 2017

Del 18 al 20 de Agosto tuvo lugar la State of the Map 2017 en Aizuwakamatsu, Fukushima, Japón. . Esta es la conferencia internacional de OpenStreetMap, un mapa colaborativo de gran uso en el tercer sector.

Tuve el privilegio de participar presentando el Mapa de Asentamientos que desarrollamos con TECHO.

Además tuve la suerte de conocer grandes proyectos llevados a cabo por miembros de esta gran comunidad. Uno muy digno de destacar es el colectivo Geochicas que trabajan temas de género desde adentro de la comunidad haciendo un trabajo muy valioso.

En este canal se pueden ver las presentaciones de la conferencia:

Quiero agradecer a la OpenStreetMap Foundation por la ayuda para participar en este gran evento y la posibilidad de dar a conocer el gran trabajo hecho por TECHO.

Juan Ignacio

Location: 会津若松市, 福島県, 9650041, Japón

Cimitero Monumentale di Staglieno

Posted by Ale_Zena_IT on 16 January 2018 in Italian (Italiano)

Noi genovesi la chiamiamo l'ottava meraviglia del mondo per la concentrazione di opere d'arte. Nel periodo a cavallo di Natale abbiamo mappato quasi tutti i vialetti e parecchie decine di tombe migliorando ulteriormente il già buon dettaglio precedente. Negli stessi giorni abbiamo scattato forse 10.000 foto su Mapillary.

Location: Media Val Bisagno, Genova, GE, LIG, Italia

Relazioni autobus urbani AMT

Posted by Ale_Zena_IT on 16 January 2018 in Italian (Italiano)

Con la memoria, molti chilometri in auto e il prezioso aiuto di Laser82 (con un nick così immaginate che lavoro potrà fare :-) ) siamo a buon punto con le relazioni (versione 2) della rete AMT. Ad oggi su 121 linee principali (esclusi bus a chiamata vari) 91 hanno relazioni di andata, ritorno e route_master. Escludendo le linee notturne siamo a 80 linee su 99. Mancano ancora diverse relazioni delle linee barrate (ma diverse ci sono già).

Non vedo l'ora di vedere completato il lavoro (ma con le linee dell'estremo ponente ci vorrà più tempo). A lavoro fatto avviseremo anche l'azienda dei trasporti (che conosce già OSM e magari ci sta monitorando). Happy mapping!

Espírito Santo do Pinhal

Posted by BladeTC on 16 January 2018 in Brazilian Portuguese (Português do Brasil)

Concluí o mapeamento de Espírito Santo do Pinhal-SP, que só continha as ruas, previamente bem mapeadas, porem sem os nomes. Ao verificar a camada do IBGE Urbana, a mesma estava não só desalinhada, mas também levemente angulada, impedindo o aproveitamento para os nomes. Procurei na camada "Face" do Censo 2010 do IBGE, tinha o mesmo problema, mas foi possível corrigir o alinhamento e pude continuar o trabalho. Inseri nomes, praças, algumas estradas rurais, lagoas e matas, e fechado a nota que pedia o mapeamento da cidade.

Agora é esperar que usuários locais se interessem e adicionem POIs, construções e outros detalhes.

Duração, 4 dias, trabalhando aproximadamente duas horas por dia.

Location: Rua Barão de Mota Paes, Espírito Santo do Pinhal, Microrregião de São João da Boa Vista, Mesorregião de Campinas, São Paulo, Região Sudeste, Brasil

Detalles sobre la base área Las Palmas

Posted by Diego Sanguinetti on 16 January 2018 in Spanish (Español)

Saludos. He añadido algunos detalles de la base aérea con motivo de la visita del Papa Francisco a Lima el 18 de enero.

Location: Villa Militar Este, Chorrillos, Lima, 15063, Perú

AG Fahrrad-Stadtplan Wolfenbüttel

Posted by jhm-wf on 16 January 2018 in German (Deutsch)

Heute am 16.1.2018 wurde die AG zum Fahrradstadtplan für Wolfenbüttel und seine Ortsteile gegründet: - Valerie Dubiel, Stadt WF: Projektleitung - Jürgen Hartmann, ADFC WF, OSM-Mapping - Klaus Eckstein, ADFC WF

Ziel ist die Aktualisierung und Ergänzung der OSM-Daten im Kartenbereich sowie die Erzeugung eines auf Radfahrerbelange optimierten Kartenbildes für Online und Druck.

Wunschtermin: Juni 2018

Für die Erfassung der OSM-Elemente werden weitere Mapper aus der WF-Community gesucht, die Ergänzungen, Änderungen und Präzisierungen aus ihrem Umfeld benennen und/oder selbst in OSM editieren. Als Redaktionsschluss ist der 16.3.2018 angepeilt. Spätere Änderungen können in die Onlinekarte einfließen, jedoch nicht in die Druckversion.

OpenStreetMap volunteers - you're awesome!

Posted by GOwin on 16 January 2018 in English (English)

On-going humanitarian mapping around Mt. Mayon, Albay, Philippines

This morning, barely 12 hours ago, the OpenStreetMap volunteers from the Philippines set up a task to map an area threatened by the restive Mt. Mayon.

And the global community of digital humanitarians quickly responded:

48% mapped. 7% validated.

We're not done yet, but we wish to acknowledge everyone who quickly responded to our call. Thank you, folks. You're awesome - and you know it. ;)

If you have some minutes to spare, we still have a little over half to complete:

Location: New Lidong Trail, Legazpi, Albay, Bicol Region, 4508, Philippines

5000-esimo changeset

Posted by Aury88 on 16 January 2018 in Italian (Italiano)

Ieri ho festeggiato il mio 5000-esimo changeset. \o/

Location: Borgo Pignatelli, Albani Roccella, Gela, CL, SIC, 93012, Italia

New User

Posted by NinjaRage83 on 16 January 2018 in English (English)

Started mapping today. Nothing to grandiose. Fixed some streets in my city and added/fixed a few buildings and parks. It will take time, but I intend to fully map my area.

Location: Fremont Street, City of Gloversville, Fulton County, New York, 12078, United States of America

Days of mapping: Batangas City (January 2018)

Posted by TagaSanPedroAko on 16 January 2018 in English (English)

Once again, Batangas City's map is growing again with updates, particularly on mapping building floors, addresses and names, missing buildings and POI's, and land use zones.


In order to improve 3D renderings of the city's buildings, especially those in the Poblacion, number of floors are being added through on the ground work using In addition, tagging of building addresses are also done, as there are many buildings with known addresses that can be sighted on outdoor signage. Building numbering also exists, but not all buildings indicate them. Names of buildings are also one part of building map improvements, as the building name form one part of many POI addresses.

Not only missing building details are added, but also many missing buildings constructed or existent since the past year. I mapped new houses and apartments inside Duluhan in Cuta, and a new commercial building along Lt. Col. D. Atienza Street. Building remapping is also done to redraw buildings that does not align properly with the most recent images. As part of this, the building occupied by Novo Department Store is remapped using DigitalGlobe Standard imagery and physical survey.

Points of interest

Many POIs scattered on the urbanized Poblacion and Cuta areas are being added one by one, also on the ground using

Land use zones

Land use zones have been part of my mapping work for Batangas City, but it is not in my priority on the previous mapping. I now placed it in my list of tasks for the city, to mark land use zones the LGU's City Planning and Development Office should have added on their Comprehensive Land Use Plan. Supposedly, the land use tag should go on the large area, not on the individual buildings, especially buildings I, and Project NOAH volunteers, mapped. Land use has been already added on part of Poblacion (the area around barangays 15, 16, and 21), and some areas elsewhere, but most has been not yet mapped, so, I now slowly adding those zones based on previous data added to buildings by LGU employees.

Location: Duluhan, Cuta, Duluhan, Batangas City, Batangas, Calabarzon, 4200, Philippines

ЕженедельникОСМ 389, 390

Posted by Sadless74 on 15 January 2018 in Russian (Русский)

Постараюсь в этом году снова регулярно переводить ЕженельникОСМ

ЕженедельникОСМ 389 (26.12.2017-01.01.2018)

ЕженедельникОСМ 390 (02.01.2018-02.01.2018)

Может вы следите за жизнью русского сообщества OpenStreetMap и готовы присоединится с составлению еженедельных новостей? Напишите мне.

Comenzando con OpenStreetMap

Posted by VyrtualGhost on 15 January 2018 in Spanish (Español)

Editando y descubriendo lugares desde Cañada Juncosa

Desde que empecé a comenzar editando el mapa de OpenStreetMap, solamente me tomaba lo que hacia como hobbie, pero una vez empece a buscar zonas de otros paises y terrenos, me di cuenta que también aprendo y descubro lugares pequeños pero increibles y fascinantes.

Todo comenco editando mi pueblo, Cañada Juncosa. a partir de ahi pase a editar los pueblos del alrededor y Valencia. Una vez ya estaba aburrido de editar estas zonas, pase a editar al azar por el mundo. Y de momento he descubierto lugares como Boutilimit, en Mauritania o Islas en el norte de rusia con poblaciones que ni siquiera hubiese pensado que estubiesen en esos lugares tan inhóspitos.

De momento continuaré descubriendo nuevos lugares e ire poniendo en mi perfil todo lo que voy editando por si quereis seguir los pasos que voy dando.

Location: Calle Valencia, Cañada Juncosa, Cuenca, Castilla-La Mancha, España