OpenStreetMap

Users' diaries

Recent diary entries

Kolejna genialna mapa historyczna

Posted by km2bp on 19 January 2018 in Polish (Polski)

Mapa ta obejmująca teren Dolnego Śląska i trochę więcej to połączenie OSM oraz map Googli na którą naniesiono zdjęcia budynków zarówno te współczesne jaki i dawne wraz z opisem ich historii. Są też pozaznaczane na mapie miejsca ważnych obiektów już nieistniejących.

W tym przykładzie wycinek mojego miasta https://dolny-slask.org.pl/532476,Zielona_Gora,Kosciol_Najswietszego_Zbawiciela.html

About another OSMF board meeting

Posted by imagico on 19 January 2018 in English (English)

Some time ago i reported here my impression of the first public OSMF board meeting and i kind of feel motivated to make another report on the most recent meeting.

I have attended quite a few of these meetings as a guest in the meanwhile and in most of them there were very few people listening in - rarely more than one or two in addition to myself. Listening to these meetings gives you a bit of insight into how the board ticks, how they communicate and how they make decisions. The last meeting had a quite extraordinary number of visitors and also seemed quite a bit different in several aspects. You can read up the formal minutes of all of the meetings on the OSMF wiki - what i here want to present is my personal impression and commentary on the thing. This is my subjective impression so there are certainly things i understood in a different ways than others and there are likely things i missed because i did not pay attention to them. If you want a neutral record of the meeting look at the minutes or better yet listen in on the meetings yourself.

Let me start by thanking the board for continuing to hold the meetings in public, i think this is of fundamental importance for connecting OSMF politics to the OSM community base. This diary entry is my contribution to this discourse - both by communicating my impression of the meetings to a larger audience than those who were able to be at the meeting and to provide feedback to the board on how their work is perceived.

It was the first meeting after the last board elections so there was the selection of officers - which was ultimately uninteresting because the same people as last time were elected.

Next topic discussed was the membership fee waiver program drafted by the MWG. What amazed me about this is that while there was some discussion among the board members there was no specific mentioning of the discussion that had occured in public on the OSMF mailing list about what is the best and fairest way to actually get more people to become OSMF members. Although a decision can of course be made on the proposal as it exists (which is purely for handling technical payment difficulties) it does not seem very productive to me to approve the MWG draft without giving feedback to the MWG and the community members who are interested in lowering the barriers for people to become an OSMF members on if and how moving in that direction is considered desirable by the board. There were vague statements of individual board members that further work should be done regarding the membership fees but no commitment or acknowledgement of the need to substantially lower the barriers.

I think this might indicate kind of a more general problem. During the last year we have seen - largely through Dorothea's work - a significant improvement of communication of overall OSMF matters to the OSM community but this might hide the fact that there is still a lot of room for improvement of the communication between the OSMF and the OSM community on specific matters. This is something the OSM community can work on (by better articulating their wishes and opinions to the board and WGs, better identifying the right point of time to provide input) but it is also something the OSMF board can and needs to work on. If input from the OSM community on matters of policy of the OSMF is being offered but either not considered or considered but the fact that and how it is is not communicated to the people providing this input that is a serious communication problem.

Next was a discussion about a possible face-to-face meeting of the board. The history of the board face-to-face meetings is an interesting one. When the first more recent dedicated meeting of this kind was planned in 2016 (not sure if there were other similar meetings in the early board history or more or less complete meetings of the board during other events like SotM) the main argument was that the board members getting to know each other in person was very useful and important for a practical working relationship. Last year there was then another dedicated face-to-face meeting although the board composition had not changed (since both Frederik and Kate were re-elected) so this argument was obviously not the primary reason any more.

When the board reported on the last meeting on the OSMF blog i mentioned in a comment:

... But i sincerely hope that with a meeting like this costing quite a bit of both time and money you do evaluate the success of it in terms of measurable results – in other words: Go in with a clear idea what you intend to accomplish and evaluate afterwards if you managed to do so.

which pretty much summarizes my attitude to this subject. If a face-to-face meeting is useful i see no reason not to have one but IMO the board needs to justify and demonstrate to the OSMF members and the OSM community as a whole that it actually is worth the money spent. If you look at the list of "what we want to change" from the 2016 meeting you can get doubts about this.

There were some comments in that direction in the discussion but everything was pretty vague and non-committal overall. What i distinctly noted is that no one even mentioned the fact that there is a SotM conference this summer in Italy and travel costs could be significantly reduced probably by making a meeting there.

Next topic was re-activating the osmf-announce mailing list for official announcements. This was an interesting and useful discussion about the purpose of this announcement mailing list and also the possibilities and the needs to communication to members from parties other than the board - like for example for initiatives from the membership to put forward proposals without going through and potentially even against the will of the board.

Then there was an item "Taking a stand against people publicly bad-mouthing the OSM project, OSM community, or OSMF" put forward by Frederik. This was about the infamous tweet by Dale Kunce which is the most recent and one of the most blatant examples of people badmouthing the OSM community on twitter and other social media channels. Frederik suggested that the OSMF board should make a clear statement to condemn such claims and make clear that the OSMF board stands behind the OSM community against people collectively calling them racists and other things while encouraging everyone to bring any specific cases of racism, misogyny or other discriminating behaviour to the attention of the board.

What followed were reactions mainly from Heather and Mikel who from my point of view very skillfully tried to spin this into yet another call for stricter rules on OSM communication channels, codes of conduct and policing use of these channels. This argument more or less went along the following lines:

  • the OSMF cannot control what is said on Twitter (which was of course not what Frederik was suggesting)
  • there were quite a few unfriendly, inpolite or similar statements on OSMF managed channels recently the Twitter statements should be seen in context with (i can't really help but this seemed oddly similar to Trump's famous "there was violence on both sides")
  • the OSMF should therefore strengthen and enforce rules on what may be said on OSM communication channels (which instead of condemning Dale Kunce's rant would actually kind of support it)

I of course paraphrase here, this is not literally what has been said but if i try to extract the essence of the arguments that have been made this is more or less what i end up with.

Peda was the only board members who spoke in support of Frederik's proposal so in the end no decision from the OSMF board to take a stand on bad-mouthing OSM and the OSM community. You can interpret this as you like. By the way Dale Kunce is president of HOT and works for the American Red Cross - the organization that has made the USD 25k donation to the OSMF last year that was kept 'secret' for more than half a year. Even if you are not into looking for conspiracies from a PR perspective this is really kind of like running at full speed towards a concrete wall. What credibility does a board that cannot even condemn a clearly outrageous statement that sweepingly calls essentially all OSMF members racists have on matters of communication tone in intercultural communication?

After that the meeting had already been running for an hour and several board members indicated they wanted to close it - Peda suggested to vote on the budget for 2018 before doing that.

For the visitors this is kind of a strange situation since the budget at this point is not public so you listen to a discussion about a budget that you cannot look at. The discussion however was mostly about the implications of the recent 200k donation and how this should be taken into account for financial planning. Ultimately the budget was approved as it was drafted by Frederik.

A followup meeting was scheduled for next week to cover the remaining agenda items.

It is still too early to draw conclusion in what direction the new board tends politically - even if there have been a few indications towards that in the way people communicated in the meeting. What i can say in review of all the board meetings i listened to overall is an increasing trend towards conservativism (mostly in the sense of sticking to a certain way of doing things because you are used to it rather than because there are convincing arguments to actually do it this way). This is not astonishing considering all of the current board members have been on the board for quite some time or bring in a certain experience from elsewhere how they are used to things being done they try to continue in this venue.

Also the board - with Ilya leaving - has become significantly less culturally diverse, we now essentially have a US-German-Canadian board. The most exotic voice on the board now seems to be Peda who is the only real hobby mapper with no professional relationship to OSM whose views maybe best represent those of a typical OSM mapper (though with a distinctly German perspective of course). Given that Peda is clearly the board member least fluent in English he also has the least chance to convincingly articulate his views against his rhetorically more skilled colleagues.

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é! https://vi-vn.facebook.com/OngNuocPPRVesboThanhTrang/

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: https://tasks.hotosm.org/project/4037 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.

https://tasks.hotosm.org/project/4037

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.

Drawbacks:

  • 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.

Drawbacks:

  • 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.

Rationale:

  • 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.

Drawbacks:

  • 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.

Conclusion

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.

Nachteile:

  • 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.

Nachteile:

  • 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.

Nachteile:

  • 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.

Beispiel:

Fazit

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)

ASPACH LE HAUT /HEIDELBERG 265KM KASSEL 530KM HANNOVER HOMBOURD NIEBULL 1072 Km SAKSBORG ODENSE/ ALS TONDER (DANEMARK) 21,8km FÄBörg (ferries 33 euros) SAKSBORG /KOLDING 88,84km KOLDING/NYBORG 95,6km NYBORG/KORSOR 51 EUROS POUR 2 ADULTES KORSOR/COPENHAGUE 112KM COPENHAGUE/MALMO ferries 50 euros ou pont suede MALMO/KRISTIANSTAD 111KM VIA URSHULL 206KM KALMAR/STOCKHOLM 713KMS Avec péage.

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 planet.openstreetmap.org 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.

PLANET_FILE='data.osm.pbf'

PLANET_URL='http://download.geofabrik.de/europe/liechtenstein-latest.osm.pbf'
PLANET_MD5_URL="${PLANET_URL}.md5"

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

Header:
  Bounding boxes:
    (9.47108,47.0477,9.63622,47.2713)
  With history: no
  Options:
    generator=osmium/1.5.1
    osmosis_replication_base_url=http://download.geofabrik.de/europe/liechtenstein-updates
    osmosis_replication_sequence_number=1764
    osmosis_replication_timestamp=2018-01-15T21:43:03Z
    pbf_dense_nodes=true
    timestamp=2018-01-15T21:43:03Z

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' )"

$CURL -o 'state.txt' "${REPLICATION_BASE_URL}/${REPLICATION_SEQUENCE_NUMBER}.state.txt"

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

PLANET_FILE='data.osm.pbf'

PLANET_URL='http://download.geofabrik.de/europe/liechtenstein-latest.osm.pbf'
PLANET_MD5_URL="${PLANET_URL}.md5"
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 https://unix.stackexchange.com/a/113798/149591
REPLICATION_SEQUENCE_NUMBER="$( printf "%09d" "$(osmium fileinfo -g 'header.option.osmosis_replication_sequence_number' "${PLANET_FILE}")" | sed ':a;s@\B[0-9]\{3\}\>@/&@;ta' )"

$CURL -o 'state.txt' "${REPLICATION_BASE_URL}/${REPLICATION_SEQUENCE_NUMBER}.state.txt"

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 osm.org, 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 nominatim.osm.org 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: https://www.youtube.com/channel/UC0jDNhn6t-PLVvqMPL-ZWbg

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. https://www.openstreetmap.org/#map=18/44.42965/8.95093

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: https://tasks.hotosm.org/project/4027

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.

Buildings

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 Maps.me. 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 Maps.me.

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