Diary Entries in English

Recent diary entries

First entry; really "Hello world!"

Posted by schleuss on 30 June 2016 in English (English)

Hello, OpenStreetMap!

I'm about to write a post covering the community-building effort behind the Great L.A. County Building Import.

But first, an introduction is due.

My name is Jon Schleuss and I'm a reporter and graphic artist at the Los Angeles Times. I spend a lot of time making maps and analyzing data to find better ways to tell new and different stories.

I've been at the Times for about three years now. I've built maps showing where L.A. County's homeless live, where L.A. City's soft-story buildings are, where you can afford to rent or own based on your income and where the dirtiest streets are.

Before moving to the big city I lived briefly in Seattle working at the Seattle Times there. I'm from Arkansas and put in time at the Arkansas Democrat-Gazette and KUAF 91.3 FM, an NPR-affiliated station in Fayetteville.

techlady and Data411 introduced me to editing OpenStreetMap in 2015 and I've been a fiend every since.

My hope is to strengthen the southern California community, using the Times as a labratory and promoter of open-source work.

When I'm not mapping or at work I'm making pies and reading, programming or at the racetrack.

More to come soon!

Location: Historic Core District, Bunker Hill, Los Angeles, Los Angeles County, California, 90014, United States of America

Weekly roundup - Suspicious mapping

Posted by Maanya on 30 June 2016 in English (English)

Here is a roundup of some suspicious changes to OpenStreetMap from this week (27 to 30 June): ​

  • This changeset an experienced editor changed the value of a major highway in Nepal from highway=trunk to highway=yes making the highway disappear from the map for 15 days. ​
  • This user traced multiple buildings but forgot to tag it as a building. Changeset
  • In this case the user was found adding an amenity on the road. Changeset
  • We also came across an edit where the user was found deleting the tag addr:housenumber from the buildings. Changeset

​ These were some of the inconsistent edits for this week. Do keep an eye and please comment on such changeset, this will help in maintaining the data on OSM accurate and coherent.

Building tools for LABuildings Import

Posted by manings on 30 June 2016 in English (English)

This is a part of a series of diaries sharing our experience on the ongoing LA Building Import into OpenStreetMap.

In the last 2.5 months we started importing building footprints over Los Angeles from open data available in LA county. Discussions about this import started early last year, after several discussions, planning and trial runs, we finally started the import this April. From its start, the import team agreed that this will be a community managed import. The goal is not only to improve building coverage of OpenStreetMap within the county but also to invite local mappers to actively participate in the whole process.

In this post, I will talk about the tools we built to coordinate this massive import. Many of the processes were based on an earlier buildings and addresses import in New York City with modifications needed due to the difference of data and the context of the local community.

Data sources

3 million buildings in LA County.

The data came from several open data sources provided by the Government of Los Angeles:

  • Building geometry (LA City, LA County) - building footprints digitized using high resolution stereo imagery under the Los Angeles Region Imagery Acquisition Consortium (LARIAC) Program.
  • Building type and use - from the Assessor's parcels database. Each building from has an associated parcel identifier (AIN), This identifier allowed us to link the type and use of each building.
  • Census blocks - this is not directly part of the data to be imported, we simply used the census blocks for dividing the data into manageable chunks.

We combined the building geometry and parcel information using the usual join by attribute GIS operation. This creates a single shapefile of buildings with all the parcel information for each building.

In total, we have >3 million buildings that needs to be checked for quality and a workflow to coordinate a massive community import process.

Data attributes to OSM tags

The Assessor's parcel data contains detailed usage of each property. We used this data to identify the type of building. To do this, we compared each attribute to taginfo and adopted tags already used by the community. For all other attributes that didn't have corresponding tags we used the generic building=yes. A CSV was created as a lookup to convert the shapefile attribute to OpenStreetMap key/value pairs.

From shapefile to .osm format

Like the NYC building import, we scripted the entire process pipeline so that we can execute in a single command. In general, the script performs the following steps:

  • Download and extract data in shapefile format.
  • Reproject from source spatial referencing system to long/lat WGS-84 (EPSG:4326).
  • Split buildings into smaller chunks based on census blocks.
  • Convert attributes to OpenStreetMap tags and export as osm format.
  • Upload to S3.

This automated process allowed us to easily re-run the conversion if we need to. For example, when we discovered data issues specific to buildings in Pasadena, we were able to exclude Pasadena in the next run of the script.

Coordinating the import via the Tasking Manager

To manage the coordination of import by the community, we used a separate instance of the OSM Tasking Manager. By using the Tasking Manager we can:

  • Split the import into smaller TM projects;
  • Track the progress of the import and;
  • Introduce a two-step process of import and validation.

But the current Tasking Manager does not allow downloading of import data from arbitrary polygons. To make this work, we implemented a new feature in the Tasking Manager that allows it to:

  • Upload a GeoJSON file with a property referencing the source URL of the .osm file,
  • When a contributor takes a task, the Extra Instructions section will have download URL for the import data. This URL will automatically download the data into JOSM.

These changes were merged into the main Tasking Manager code so anyone using the latest TM codebase can use this feature as well.

Once we had everything ready, we did a couple of trial runs to evaluate the mapping workflow.

During one of our trial runs, we discovered that since we are using arbitrary polygons instead of the usual square tasks, mappers find it difficult to visualize the edges of the task they are working on. This can introduce data conflicts especially when the imported data is now merged to the current data within OpenStreetMap. To solve this issue we added a background layer of census block boundaries that is automatically loaded when a user downloads the data.

Downloading data for import.

Automated merging of the split buildings

The trials also encountered cases where a small sliver of building was split from the main building.
Upon further investigation, these buildings are cut by the property lines of the assessor, during the LARIAC mapping.

Split buildings.

Since this came directly from the source data, we have no way of fixing this during the data conversion process. This required the user to manually merge the split buildings during the importing process.

While combining overlapping buildings in JOSM works, it requires several mouse clicks to merge two buildings. To make this process faster, we built a plugin in JOSM that merges two buildings and automatically assign the correct tags.

Merge LA buildings in 3 clicks with auto-tools plugin in JOSM.

As of this writing, 105 usernames added ~580K buildings. This is more than half for LA City.

500K buildings added. Map by F4map.

As we go along, we continue to improve the workflow and tooling, let us know how we can make this import better! Head over to and grab any task available. If you're a local, join our mapathons happening through MaptimeLA.

MaptimeLA building import mapathon. Photo by MaptimeLA.

In the next post, we will talk about how we interacted with the mapping community and the response by the local LA mappers on this import.

If you're in Seattle next month, catch the team at the SOTM-US where we talk more about this import.

More info about the import is available in the following links:

Location: Jefferson Park, Cienega, Los Angeles, Los Angeles County, California, 90018, United States of America

Splitting intersecting features

Posted by PlaneMad on 30 June 2016 in English (English)

While tracing an area of continuous buildings in India, realized there was no easy way to create such a pattern of features in JOSM.

How does one split a group of ways using an intersecting line. The More Tools>Split Object command comes closes but works only with a single way and line that it encloses and is quite laborious.


Terracer plugin does not work well since the area is not a perfect rectangle, so it does not get the axis right. Any other editor/plugin capable of drawing this quickly?

Location: Lakshmipuram, Hoysala Nagar, Bengaluru, Bangalore Urban, Karnataka, 560001, India

Missing Maps - Sierra Leone

Posted by Tallguy on 29 June 2016 in English (English)

Training in Freetown

Missing Maps training involving American Red Cross volunteers in Freetown, Sierra Leone on 3rd June 2016

“Good thanks, and you?”
“Great. How do you fancy a trip to Sierra Leone?” ……………………...

At various times in my life I've ended up training subjects including IT, and when Missing Maps started, training was my main involvement. I've been to many Mapathons, stood out the front, and done my best to make mapping 'happen' for people struggling with software & strange terms.

The trip to Sierra Leone was slightly different. 32 volunteers needed training in how to carry out surveys using software on mobile phones. Essentially they were carrying out a survey of village & health facilities, how many people, what sanitation – all of the things you would expect the American Red Cross would need to know in order to plan their operations. In addition some training would also be given to MSF personnel – similar sort of thing, but each organisation has its own version of the questions.

In 2014 I'd been one of many people trying to remotely map the areas affected by Ebola, tracing from satellite imagery. Sierra Leone, Guinea & Liberia, were mapped remotely, and names added as best we could. Some ground survey information had been added, but when you started looking at the information, you realised that it was lacking in the sort of detail you'd really like to see in a map - when we arrived in Sierra Leone, OSM had one water point mapped for the entire country.

Our first 5 days were in Freetown, planning and then delivering the training. Each morning we were carried by MSF car through heavy traffic in Freetown and I started to understand a little about the city. I could see people carrying water containers, others were having their morning wash at the side of the road. As we descended towards the coast I could look out onto a large open landfill site and its inhabitants – I couldn't see all of it, but it was at least the size of a football pitch. The river we crossed appeared to have many uses.

We concentrated on training the 32 volunteers who were to carry out the surveys. Many knew very little about mobile phones when we started, but we demonstrated, tested and practised until they understood enough to be able to do their surveys. The power cuts, wifi problems & equipment problems were all taken in our stride (we all had missing luggage, but luckily, enough had arrived for us to carry out the training). Our evenings were spent amending training plans, adapting to the changing needs & time scales. I'd even managed a brief trip round the market buying some clothes (When I first arrived I had only what I stood up in – if anyone finds a holdall with clothing for a Tallguy I'd be very interested).

I spent my weekend either travelling or making preparations for the week ahead where I was to be based in Kenema.

Supervising - based in Kenema

Red Cross Staff in Kailahun, Sierra Leone

Monday, Tuesday & Wednesday was spent travelling on a wide mixture of roads, some wide tarmac roads in better condition than the UK, and some roads that had never been surfaced and were so steep and uneven that my driver negotiated them in bottom gear in our 4x4, while we bounced around in the cab bruising our elbows on the doors. We were attempting to find some of our volunteers to make sure that everything was okay with them and their work. Everyone had mobile phones, but this didn't help much as there was very little in the way of signal.

At times we stopped before crossing bridges, walked over them, & jumped up & down to test them before driving over them. A lorry stuck in the mud caused a 4 hour detour. A brief phone call to one of the volunteers, who was surveying habitations with no roads at all, before the signal dropped off went something like….
“Glad you're okay, where are you?”
“I'm walking in the forest being bitten by beasts”
“Which town are you near?”
“I'm walking towards”….. and the call dropped.

My local driver was impressed that I could tell him the name of the villages which were coming up, and advise him of potential routes. He even enjoyed the game of slowing down on the approach to villages so I could take a photograph of the sign. He and his colleagues were even more impressed when I installed OsmAnd on the phones of those who wanted it, and gave them a brief training session. The drivers were an interesting group to talk to – at least one had been a local businessman who had seen his business gradually decline following Ebola.

Alongside the main roads you could see piles of sacks ready for sale. These were often filled with charcoal but had coya leaves in the top. Buy one, put the coya leaves in the bottom of your BBQ, add charcoal and light. You could see the rough shelters the charcoal producers used, in their little patch of cleared vegetation. Heavily used roads ending in piles of sand beside a river where they extracted large amounts of sand by hand – bought by the local builders. I'm not sure if the main aim for the people doing the digging was the sand or the potential diamonds – there were many diamond offices in Kenema.

Started, but not completed buildings with no roofs were a frequent sight.

My final days in Kenema were spent training staff in the potential uses of OSM - paper, phone apps., analysis, and how surveys for such things as water points could be carried out. The amount of detail in OSM was a surprise to all that I trained and I think we can expect lots of use.

In Freetown I found that Pete had been very busy, surveying water points and making contacts with many local organisations. We carried out a mapathon on one day & part of our last day was at a conference where we gave a presentation on Missing Maps, before finishing our packing and catching the ferry & plane.

Excuse me if I’m quiet for a while - still trying to replace all my lost clothes. Oh, and about 200 water points to add, 50+ village names and a few bits of road aligning to do.

Certainly an experience, and one that I’d be happy to repeat.

Most of my gps traces have been uploaded to OSM, so it you’re working on or anything else in Sierra Leone, have a check for downloadable gps traces.

For more info on Missing Maps, please see If you’re interested in finding out more & learning a little about ‘remote’ mapping, or something more technical, come along to one of the Missing Maps Mapathons - there are events throughout the world - if it’s in London, UK, you might even see me (Tall, bald, grey beard - easy to spot!).

Location: Lower Pipe Line, Wilberforce, Freetown, Western Area Urban, Western Area, Sierra Leone

Gedling as Big Brother?

Posted by alexkemp on 29 June 2016 in English (English)

The main trunk roads out of Nottingham are on the West & lead either to or across the M1 (the main English east-coast 6-lane motorway built in the 1970s). On the East side – which is where I live – most of the roads leading out of the town are B-roads, such as the B686 which can eventually take you to Southwell (pronounced locally as ‘suth-ell’) and Newark. That road is better known in Nottingham as Carlton Road then – at the point where Nottingham ends & Gedling begins – as Carlton Hill. At the top of that hill is (surprise, surprise) Carlton + Carlton shops.

If you are getting an impression of small-town & suburban for Carlton, then you are exactly right. The oldest date that I've spotted for a house in Carlton is 1906. The housing is mostly 1920/30s semi-detached with some Victorian (or later) Terraces + detached houses sprinkled amongst them.

The development of the shops is also a classic tale. Carlton is built upon a hill, and Carlton Hill is the road that leads in and out of Carlton on both sides. Enterprising householders at the top of the rise would have begun a shop in their front-room & extended into the back-room if successful.

However, there is not much room; the B686 is just 2 lanes and the maximum width on the pavement is only 3 metres. How very surprising, then, to see (what appear to be) two 10m+ surveillance masts in the middle of the pavement, one at either side + either end of the shopping street:

big brother masts?

I altered them to be mobile-phone masts before uplift, as I did not believe that Gedling council would be so gross as to place such eyesores in the street simply as CCTV cameras. However, after some thought I've reconsidered, and now think that yes, the police really are that insensitive. I've tagged one of them with “Big Brother?” to make it easier to find.


There were 2 buildings behind the main line of north-side Carlton shops that I needed to recheck (Little Bears nursery + Dolly's Tearoom), and have just returned. Whilst back on-site I took the opportunity to ask about the mast.

The masts were erected at least 8 years ago – the owner of Bella Monty (the mast is outside her shop) moved on to the street in 2008 & the masts were already present. And yes; Gedling Council truly is that crass, because they are CCTV camera masts.

The folks at Dolly's Vintage Tearoom (on the same block as the mast) were most dismissive of it. When they moved in some years ago they initially suffered some minor vandalism, probably from kids. The CCTV neither prevented the vandalism nor helped catch the kids.

I've altered the mast in question back to “man_made:surveillance”, and have removed the ‘?’ from “ref:Big Brother?”.

Counting up, there are 9 hairdressers (out of 45 shops total) on just one side of this street in Carlton:

  1. Strands
  2. Bella Monty
  3. Who's Next Barbers + Rebecca's Hair
  4. Beautiful Nails
  5. Reno & Paul Hairdressing
  6. The Ink House
  7. Kudos Beauty Clinic
  8. Hair Finity
  9. Wallis and Goodrich Hairdressing

That is 1 in every 5 shops in Carlton is a Hairdresser! Astonishing; but, I have to say, normal for Nottingham (I swear that Beeston, in the West of the city, has even more). And yes, I've naughtily included a Nail shop, a beauty clinic & a tatooist in the total, plus one of the shops is down a side-street (just), but I've also included all of the currently closed-down shops in the total number. Nottingham's girls love getting their hair done so much that they are easily able to support an army of other women + some men to attend to their every need. And the council spends thousands of pounds to watch them do it.

Location: Thorneywood, Sneinton, Nottingham, East Midlands, England, United Kingdom

First Video on OSM

Posted by mmahmud on 29 June 2016 in English (English)

I live in Dhaka, the capital of Bangladesh. It is a densely populated area to live in. Remote Mapping in Dhaka is also difficult because the imagery quality is not that great and the buildings are so dense that it is hard to separate from one another. However, I noticed that the imagery in Dhaka has two layers. Upto zoom level 18, there is one imagery that is quite clear but small to draw from. From zoom level 19, another imagery that is quite unclear, dense and sometimes covered in cloud. So I figured a way out to use the first imagery to draw from. I made a video about it. Here is the link:

So far, this is helping a lot. I am not sure if this trick can be used elsewhere but this is worth a try.

DOST - Project NOAH (ISAIAH) finishes mapping building footprints in Cavite

Posted by feyeandal on 29 June 2016 in English (English)

OpenStreetMap contributors, through the initiative of ISAIAH (Integrated Scenario-based Assessment of Impacts and Hazards) component under DOST - Project NOAH (Nationwide Operational Assessment of Hazards), have recently completed mapping the building footprints of Cavite.


One of the objectives of ISAIAH is to map the exposure elements such as buildings and critical facilities. Identifying the critical facilities such as schools, hospitals, and government offices, and other infrastructures will be essential in determining the areas vulnerable to disasters and can be used as a starting point in reducing disaster risk. All of these data will be used in improving community disaster management before, during and after emergencies. This initiative involves a collaborative partnership with the OpenStreetMap community.

Last March to April, Project NOAH conducted a series of OpenStreetMap training to its staff to digitize the building footprints in the selected provinces in the Philippines using the available imagery from Bing and MapBox. The provinces were selected according to the available imagery, land area and population of the provinces, and the available population data we have from the Philippine Statistics Authority as of 2010. Accordingly, Project NOAH created a mapping task on the HOT Tasking Manager for the province of Cavite. Since then, Project NOAH staff and OSM community started contributing to the mapping task.

Cavite Tasking Manager

As of June 28, the mapping task for Cavite is 100% complete and 18% validated. This mapping initiative helped increase the number of building footprints in Cavite from 110,506 to 631,825.

Below is the image of the downloaded building footprints in Cavite as of June 28.

Building footprints mapped in Cavite after NOAH initiative

You may view the map comparison of before-and-after edits here.

The translated building footprints data from OpenStreetMap are being utilized in one of Project NOAH tools, the WebSAFE application. It is used as an impact assessment tool for end-users to be able to readily identify the number of affected people and buildings in case a hazard scenario like flood affected a certain area. Using this tool, local government units can easily identify how many relief goods are needed to be allocated when a severe weather event happens.

WebSAFE for Cavite

Thank you for helping us map Cavite!

Project NOAH recently opened a new task for the province of Zambales. Click here to help us map the province. :)

Multi-Light Rendering and Voronoi Diagrams

Posted by Zabot on 29 June 2016 in English (English)

I spoke with B4sti and Tordanik last week about how to best attack shading with multiple light sources. As it stands, OSM2World can only handle a single light source, the sun. Adding any individual light source is not so much of a problem, some tweaks to what information is passed to the graphics card and now you have another light source. The problem is one of scalability. OpenGL breaks the faces of shapes to be rendered up into fragments. Each fragment must have its color calculated individually, based upon several factors, including the lighting. To add a second light source would require every fragment to consider both light sources. As you keep adding lights, each fragment must consider every light. This may not seem so bad, but there may be hundreds of thousands of fragments in a single frame. If each fragment has to consider 10 lights, thats one million calculations, and it only gets worse from there. But one could easily imagine a city scene with more then 10 lights, even just a highway with street lights would have more than that.

We can makes things a little bit easier on ourselves by only considering the closest light to each fragment. While this means we only have to do the lighting calculations for a single light source at each fragment, we still need to test the distance to every light source to find the shortest. We need some method to precompute the closest lighting source to each fragment so we can avoid the timing consuming process of calculating it. Unfortunately, we have no way of knowing where a fragment is ahead of time.

The solution we came up with is similar to the concept of a Voronoi Diagram. A Voronoi diagram is a mapping of points on a continuous plane to a finite set of seed points such that each point is mapped to the closest possible seed point.

Voronoi Diagram

(Each colored region would be affected by the lighting source closest to the vertex in that region)

If we imagine each seed point to be a vertex in our world geometry, then each vertex could be assigned a precomputed closest light source, and every point in the region belonging to that vertex would use that light source for its calculations. Typically, if we were to assign an ID to each vertex, OpenGL would use those values to interpolate the value for a fragment between those vertices. But by tweaking the behavior of this interpolation, we can make a fragment take the value from the closest vertex without interpolating it, and without performing any additional calculations. If we know already know which light is the closest, the calculation no longer depends on how many lights are in the scene, and the number of lights could be much greater.

Better Sunsets!

Posted by Zabot on 29 June 2016 in English (English)

After I had implemented moving the sun a few weeks ago, I realized that things looked out of place without an actual sun. So I busted out the physics textbook (google) and did some research. Sunset

The Physics

You might remember from your physics classes that light does one of three things when it strikes an object. It can be absorbed, reflected, or transmitted into the new medium. In the case of atmospheric scattering, we discount the last possibility because all of the particles are opaque. This leaves us with absorption and reflection. Absorption is fairly self explanatory, the farther light has to travel through the atmosphere, the less light is going to make it. Reflection is not quite as simple. Because the light could be reflected in any direction off of the particle, we further define reflection as in-scattering and out-scattering. Out-scattering is when light originally in a ray is reflected (scattered) away from (out of) the ray, lessening the final brightness. In-scattering is when light not originally out of a ray is scattered into the ray, increasing the final brightness. To define the final color of a fragment to a viewer, these three values most be calculated for every point along a ray from the fragment to the viewer. To see this in action, lets look at a sky without scattering.

If we consider the sun as a directional light source where all rays are parallel (not entirely true, but close enough for most purposes) then for each ray, we need only check if it is perfectly parallel to the sun, if it is then we see a bright sun at that ray, if not then there is no light and we see black. This is what you see if you look at the sun from space (Because the real world sun is not a perfect directional light source, there are several rays which are parallel to the sun, giving it its apparent size).


The first atmospheric affect we look at is absorption. During each collision with a particle, there is a probability that the light is absorbed. The further that light has to travel through the atmosphere, the higher the probability of a collision, and the more collisions there are, the more chances there are for that light to be absorbed. If it were possible to observe a planet where the atmosphere only absorbed light, you would still see the sun at a single point, but as it lowered in the sky the point would become dimmer as more light is absorbed by the atmosphere.


Next we introduce out-scattering, the effect will be similar to that of absorption, as light is removed from the ray but the process is slightly different. To examine it we need to look at the two types of scattering, Mie scattering and Rayleigh scattering. The two are different names for similar phenomena. Mie scattering is seen when the size of the particles doing the scattering is comparable to the wavelength of the light being scattered, such as water vapor in clouds, or smog and other large particles close to the surface. Rayleigh scattering is when the particles doing the scattering are much smaller than the wavelength of the light, such as the nitrogen in the atmosphere. Going to much further dives into some serious physics, but the important thing to take away is that Rayleigh scattering scatters shorter wavelengths (blue) more than it does longer wavelengths (red), while Mie scattering scatters all wavelength equally. During sunrise and sunset, the light from the sun has more atmosphere to travel through, so much of the blue light is scattered away, giving the dawn and dusk sun its red color. During the day, there is less atmosphere between your eyes and the sun to scatter away the blue light, and we are able to see it as the color of the sky.


In reality, every ray of light is eventually absorbed by something. Unfortunately, simulating the lifespan of every individual ray of light, potentially through dozens of bounces through the atmosphere can be incredibly computationally intensive. To make calculations easier, instead of simulating every bounce, we assume that once a ray has been out scattered, it effectively disappears. Now we can combine these two effects into a single factor, extinction, and model it as an exponential decay.

vec3 extinction(float dist, vec3 initial_light, float factor) {
    return initial_light - initial_light * pow(scatter_color, vec3(factor / dist));

scatter_color is what really defines the color of the sky, you can modify it in your config file by setting scatterColor = #xxxxxx. This color specifies how the sky scatters different colors of light. The gist of it is that a higher a channel is set, the more of it you will see in day time, and the less you see during sunrise and sunset.

Now we're getting somewhere, but we need some more support equipment if we want to render a sky. To calculate the amount of light that is lost to extinction, we need to know how much atmosphere the light is traveling through. This function is the product of the law of sines from trigonometry and a circular cross section of the atmosphere through the center of the earth, the viewer, and the point where the a ray from the viewer leaves the atmosphere.

float atmospheric_depth(float alt, vec3 dir) {                                                             
    float d = dir.y;
    return sqrt(alt * alt * (d * d - 1) + 1) - alt * d;

We have everything we need to define out-scattering and absorption, but we still need a way to define in-scattering. To calculate in-scattering, we use a phase function. This function estimates the probability that a ray will be scattered an angle alpha away from its original direction. This phase function comes from this GPU Gems article.

float phase(float alpha, float g) {
    float a = 3.0 * (1.0 - g * g);
    float b = 2.0 * (2.0 + g * g);
    float c = 1.0 + alpha * alpha;
    float d = pow(1.0 + g * g - 2.0 * g * alpha, 1.5);
    return (a / b) * (c / d);

To color the rest of the sky, we sample several points along a vector from the eye to the fragment we are trying to color and calculate the probability that light will be scattered from the sun towards the viewer. We scale the probability by the intensity of the sun to calculate the amount of light being scattered from the sun towards the viewer. But this light isn't done yet, it still has some atmosphere to travel through, so we calculate the amount of light that is lost going from the sample to the viewer. We add together the light from each sample point to find the total light that reaches the viewer. You can read the rest of the code here, and have a look at Florian Boesch's excellent article where I pulled the original algorithm from.


Posted by Rewa267 on 28 June 2016 in English (English)

Manurewa is the place to be right now.

Location: -29.191, 174.413

Let's pretend like contribution is an import.

Posted by BushmanK on 28 June 2016 in English (English)

Case of is, in many aspects, similar to cases of Potlatch and iD (on its early stage of deployment), but in certain aspects it is special. At least, in aspect of how frequent those edits are. Since currently it is hard to reach out to every editor user, it makes the whole situation a kind of similar to imports, where we have massive amount of data, originally not suitable for OSM, often - with questionable quality (should I remind everybody of TIGER and its consequences for American OSM?), with certain systematic issues.

If this analogy is acceptable, it's logical to apply certain import guidelines to it. Think about paragraphs 2.9, 1.1, 1.2, 1.4, 1.5, 2.1.

So, if these requirements are acceptable (I mean, nobody thinks it's impolite to require it) for imports, why it shouldn't be applied to, or whatever editor, which increases involvement of people, unaware of OSM guidelines, or provokes systematic mistakes? I've seen comments, where people literally opposed paragraph 2.9:

Take great care to avoid damaging the database and don't leave a messy import and assume that nameless OpenStreetMap contributors working in iD and Potlatch and will tirelessly complete your work. JOSM is better at for untangling messy data, but it's still difficult and you should do this work yourself if necessary.

And, by the way, it also says:

If your import does 'go wrong', or you needed to interrupt an upload half way through, then this should be reverted promptly. ... If you don't know how to revert an import, don't do the import in the first place.

When applied to editors, it means, that if it systematically provokes avoidable wrong edits, measures should be taken to prevent them. And developers should be prepared to do a cleanup.

I hope, nobody will read this diary entry as some kind of bullying of developers or another complain. That wasn't my intention. My intention was to demonstrate, that OSM community does have more or less detailed guidelines for quite similar situation.

GSoC: iD editor blog 3

Posted by kepta on 27 June 2016 in English (English)

Hey, I have made some major progress since I last talked about my work with iD. I am continuing my work with lane icons last time.

This is how the current lane selection looks like.

Also the iD is currently going through modularisation and we are tracking it here.

With the help of my mentors we decided to draw some awesome icons. You can track the update at this gitbub repo. These are some of the icons I recently created. Suggestions are welcomed.

bike bus hov pedestrian train

I am also organising an OSM hack weekend at Bangalore. If you are around don't miss this event. Link to the event

punto de encuentro.

Posted by Lalalian on 27 June 2016 in English (English)

Esta plaza, ubicada en la localidad de Loma Hermosa, en época de inundaciones, sirve de punto de reunión donde se junta mercadería, agua y alimento, los cuales se reparten en zonas mas afectadas, con la colaboración de un vecino que dispone de una flota de camiones.

Location: Chilavert, Partido de General San Martín, Buenos Aires, Argentina

Weekly roundup - Suspicious mapping

Posted by manoharuss on 27 June 2016 in English (English)

Here is this week's collection of suspicious mapping observed between 20 - 24th June.

  • This changeset from a new user was observed to be deleting POI's, beach, public toilets and adding a random square without reference to the imagery or any mentioned source. This was reverted.
  • This changeset changed name of the Paracel islands from Chinese to english, changed the locality from Chinese to Vietnamese, added a traingle on the map with no reference. This was reverted by the DWG.
  • This changeset was observed to be deleting a lot of buildings and roads.
  • This changeset deleted a lot of service roads.
  • In this changeset the nodes had landuse=farmland tag.
  • This changeset had given building=yes tag to resendential areas instead of the individual buildings.
  • This changeset deleted buildings using iD editor with no explanation in the comment.
  • This changeset deleted private roads using the iD editor. This was reverted by the community.
  • This changeset added address tags to every single object in the changeset including the nodes. The cleanup of this changeset was detailed in this diary post.

And ofcourse, look forward to this roundup again next week. If you observe any suspicious mapping, comment on the changeset and let the mapper know. Mistakes happen all the time.

Happy mapping!

Weekly observations between 27th to 30th June can be found here.

GPS Coordinate shortener: what3words vs Mapcode

Posted by ryebread on 27 June 2016 in English (English)

The moment I launched Navmii GPS I was presented with 3 words that looked like this:

I started looking for the explanation and found that's from the service called what3words, that attempts to solve the user-unfriendliness of GPS coordinates by splitting the whole world into 3m x 3m squares and assigning a unique set of 3 words to every location:

what3words website

Now, I got all excited and thought this is going to be the best thing ever, but my wife was skeptical and made a great point:

what3words address for a Robin Williams bench has an address of "script.export.noble". Move 3 meters east and you'll get "votes.began.hours". So it is allows you to precisely locate a feature. But here's the problem - you can't infer anything from these words. Unless you have an access to a device that has a mapping available, you can't know what continent it is on. This may not be the best use case, but when you have an address of "5 Child Street, Boston, Massachusetts, USA", you can assume "6 Child Street, Boston, Massachusetts, USA" will be somewhere nearby.

Okay, so I was less hyped and started looking into the way the words are generated, and it turned out the algorithm and the data is not in a public domain, and you need to use their REST API or offline SDK to perform the mapping.

Our goal is for what3words to become a global standard for communicating location. At the moment, the core what3words algorithms and data are not in the public domain. In the future, we may release some or all of our source code – we will continually evaluate the business case for doing this.

And then I've read this in their API License terms:

You must not pre-fetch, cache, index, copy, re-utilise, extract or store any what3words Data.

Well... you can contact them to get the SDK containing the data, but... I am not sure I like the idea of a company pushing a global addressing standard that you can't freely use. I've recently read w3w is selected by Mongolian Post office to provide addresses for locations that don't really have an official address. It will be interesting to see how this works in real life.

Another thing I encountered during my search for navigation was Mapcode (used, for example in Here Android app).

Originally created by TomTom, this system does not really rely on any centralized data. The algorithm, however, is patented:

In order to prevent misuse, unauthorised alterations, copying or commercial exploitation, please note that the ideas and algorithms behind the mapcode system have been patented and that the term "mapcode" is a registered trademark of the Stichting Mapcode Foundation. Our mapcode source code is released Apache License Version 2.0.

A good thing about Mapcode is that it shortens the coordinates to manageable tokens, and you can select the representation that better suits your needs. And the best part is that you don't need any server interaction for it all to work.

[rye@delorean ~]$ python3
Python 3.4.3 (default, Jun 13 2016, 16:33:53)
Type "help", "copyright", "credits" or "license" for more information.
>>> import mapcode
>>> mapcode.encode(42.52838, -83.36005)
[('7S.65B', 'US-MI'), ('S3K.6YD', 'US-MI'), ('CDS1.XWV', 'US-MI'), ... ]
>>> mapcode.decode('US-MI 7S.65B')
(42.528403, -83.360037)

Close enough.

Okay, guess what part of the world "US-MI 7S.65B" is in? How about bugs.bumps.glue? And I am pretty sure it is easy to figure out that "US-MI 7S.659" is nearby.

On the other hand, embedding the country/state into the code can cause the same issues as the country borders in disputed territories. The location above also has an international address of "T8BB9.T204", which has the same problems as w3w one, except that there are neither bugs nor glue.

So, what do you think? Does a world need a GPS coordinate shortener and if so, what would you use?

Location: Orchard Lake Road, Farmington Hills, Oakland County, Michigan, 48334, United States of America


Posted by sdilrukshini on 25 June 2016 in English (English)

Home town

Location: Thalawa Eppawala Road, Anuradhapura, Anuradhapura District, North Central, Sri Lanka

Well Done Tesco!

Posted by alexkemp on 25 June 2016 in English (English)

Tesco Carlton provide a well-maintained grassed area with trees, tucked unobtrusively between their store & Foxhill Road East. It has a wooden seat + rubbish bin, and was the perfect area on Thursday 23 June to eat a sandwich, choccy-bar + can of coke after a hard afternoon's surveying.

view from the bench

Refreshed, I went on to acquire the contact details for the Carlton Police Station (it turned out to be '999') (joke), then went home.

Location: Arnold CP, Gedling, Nottinghamshire, East Midlands, England, United Kingdom

Flood Lagoons? What Flood Lagoons?

Posted by alexkemp on 24 June 2016 in English (English)

On the Bing imagery within JOSM and (sacrilege!) Google maps (make sure that ‘Earth’ is enabled) you can find a Flood Lagoon nestled amongst all the Nottingham houses in Carlton, Nottingham NG4. The problem is that OSM does not have a “man_made:flood_lagoon” key/value, so I cannot show it to you on the OSM map (I made up what seemed to me to be the closest to what it should be but, of course, will neither store it nor show it).


I was surveying the even numbers on Foxhill Road Central on Monday 20 June when I came across a kiddie's playground at the corner-junction of Foxhill & Carnarvon Grove. See if you can spot in this picture the single sign of this flood lagoon (hint: it is the locked-gate entry to a narrow strip of grass + workman's hut at the back of the playground):—

Carnarvon Grove Play Area hiding a flood lagoon

My spider senses were tingling, but none of the locals that I asked knew what the hut was for.

Whilst entering Foxhill Road houses on to the OSM Map the next day I came across the Flood Lagoon on Bing, and very mysterious it looked indeed. I contacted Severn Trent & explained what I was doing & asked what on earth it was. She got out her own map & it was then that I discovered that it was “Flood Lagoon 5805”. I put it up on OSM, even though I knew that I was just wasting my time.

Yesterday (Thursday 23 June) I returned to survey the odd numbers on Foxhill. This time I was determined to see if I could get a photo of the lagoon. Fortunately for me there turned out to be a clear view of the lagoon from Radcliffe Gardens at the rear of Foxhill Road. I took a number of photos; unfortunately, I was also testing a new camera app on my phone, and some of them have simply vanished into the void. Two frames are left:—

Flood Lagoon 5805 pic#1 Flood Lagoon 5805 pic#1

Coda 1:

Thanks to some fast comments I've been able to find a tag documented on the OSM wiki (Tag:landuse=basin) that least allows me to show it to you on the map: Flood Lagoon 5805. That provides a viewable-outline in JOSM. Sadly, no outline in ordinary circumstances in, although the name can be searched for (“5805” could not be found previously).

Coda 2:

(Sunday 26 June)
...and now I am mighty confused. Flood Lagoon 5805 is identical in OSM to what was there before, but now shows on the map as a blue-infilled area. Is this due to some caching-issue on the server, or has there been an update in the tile-server?

Coda 3:

(Monday 27 June)
Carlton Foxhill Road Central Flood Prevention Lagoon:
(a flood prevention lagoon operated by Severn Trent) (contained within the area 426553952)

Sluice Valve 5805 (at the Pitch Close end) empties surface water from the Fairway Drive estate into the concrete channel of the lagoon. Water run-off can come from both playing pitches to the north-west of the Sports Centre and also from allotments to the north of the estate. The course of the concrete channel follows that of a stream which formerly ran here prior to development in the early part of the 20th Century (all such streams are now culverted).

Sluice Valve 6714 (at the Playground end) empties all contained water into the Carlton Foxhill Road Central CSO. That culvert (as long as I recall this information correctly, from an engineer that called me today) ends outside the Old Volunteer Pub on Burton Road.

The land surrounding the concrete channel between the 2 sluices has been graded into a deep basin to temporarily contain exceptional volumes of water during storm conditions.

Note: Severn Trent does NOT give this lagoon any name; I have therefore assigned it a sensible name for search purposes. Many thanks to Philip & others at Severn Trent for patience & explanations.

Location: Arnold CP, Gedling, Nottinghamshire, East Midlands, England, United Kingdom

Street Art: Nottingham NG4 Front Door Leaded Lights

Posted by alexkemp on 24 June 2016 in English (English)

I guess that I may be becoming obsessed, but I really like some of these front-door leaded light displays. Just 2 from yesterday's (Thursday 23 June) survey down the odd numbers on Foxhill Road (signs of intelligence? I started at the top of the hill):—

Who's that fool taking a photo?

foxhill door lights 1

Ah! Stayed out of the picture this time:

foxhill door lights 2

Location: Thorneywood, Sneinton, Nottingham, East Midlands, England, United Kingdom
Older Entries | Newer Entries