Diary Entries in English

Recent diary entries

Posted by BushmanK on 29 November 2016 in English. Last updated on 30 November 2016.

Browsing through the issues at Openstreetmap-carto (also known as OSM Standard style or “Mapnik” style) tracker on GitHub, I came across several issues, both open and closed, touching the topic of rendering vertical man-made structures such as poles, masts, and towers.

Communication engineering was my thing for awhile, so it always strikes me when at least two of these terms - mast and tower - are used in an uncertain manner. In one of the discussions on GitHub, the difference between masts and towers was called “philosophical”. Actually, there is no philosophy (at least if you don’t look at wrong and misleading examples in OSM Wiki). Because of that, I’ve added an engineering definition to pages of man_made=tower and man_made=mast both in English and Russian because what is in the first section of those pages makes zero sense and contradicts the basic principles of tagging, because it uses comparative terms such as “bigger” and “smaller” to distinguish between these structures. Tags tower:construction=guyed* are obviously redundant because if you need that, it means that object must be tagged as a mast, not as a tower.

I didn’t want to rewrite the whole “definition” without discussing it, while I don’t really believe that discussion could be successful, so I just added clear definition in case if someone would prefer it. Just for the reference:

Mast is a vertical man-made structure, supported by the guy lines and the anchoring system.

Tower is a vertical free-standing man-made structure, supported by its own foundation only.

(Anyone can find it even in Wikipedia, so it makes me wondering, how ignorant an author of these OSM Wiki articles was to write that.)

See full entry

Posted by alexkemp on 28 November 2016 in English. Last updated on 1 December 2016.

The chap that I saw on Phoenix Farm Estate yesterday (Sunday 27 November) could not believe that I thought that his shed was worth a photo. My reasons were simple: partly it was the quality of the build: Google StreetView is October 2014 & shows a very nondescript garage, whilst the modern shed+garage is very smart. However, the reason that clinched it for me was the name that he had put upon the door of the shed next to the garage:

“The Man Cave”

man cave

Coda:

Phoenix is actually the next estate and not the current one.

Location: Gedling, Carlton, Gedling, Nottinghamshire, East Midlands, England, NG4 4BH, United Kingdom
Posted by alexkemp on 28 November 2016 in English.

There are some gardens that I come across whilst mapping that simply cry out to be featured in these Diary pages. There are two today, both located on an unadopted road (the householders have to pay for all road upkeep) in Gedling that I first walked on Wednesday 23 November on a truly dreadful day. The rain was interfering with the smartphone’s capacitative action, so I went back on last Sunday 27 November.

The first garden below is included simply because I found it sweet (and why not?):

aaah!

The next seemed to epitomise water action. It was pouring down from above and even flowing in a culvert below, so it seemed only fair to have galleons in a pond as well:

See full entry

Location: Gedling, Carlton, Gedling, Nottinghamshire, East Midlands, England, NG4 4BH, United Kingdom
Posted by kocio on 28 November 2016 in English.

Dear all,

Today, v2.45.0 of the openstreetmap-carto stylesheet (the default stylesheet on openstreetmap.org) has been released.

Changes include:

  • Rendering all shops without a specific icon as a dot, not just a whitelist
  • Scrub pattern change to random
  • Changing pitch and track color
  • Railway stations rendering as major buildings
  • Rendering the name of man_made=bridge inside the polygon
  • Documentation updates (including cartography design goals and icon design guidelines)
  • Icons general code cleaning
  • Various bug fixes

Thanks to all the contributors for this release, including micahcochran, a new contributor.

For a full list of commits, see https://github.com/gravitystorm/openstreetmap-carto/compare/v2.44.1…v2.45.0

As always, we welcome any bug reports at https://github.com/gravitystorm/openstreetmap-carto/issues.

You may also like to know that this release is the first with 3 new project maintainers on board. Please be aware that we’re going to drop some legacy dependencies soon (like Mapnik 2), so we’re approaching a big version change.

Posted by alexkemp on 27 November 2016 in English. Last updated on 8 February 2019.

There is a splendidly-named 1903 house & land called Scot Grave Farm (farmhouse, farmyard) on Arnold Lane that I revisited today (on the older maps it is called “Scotgrave Farm”):

Scot Grave Farm house

The owner has both an old BT red phonebox & red Postbox in his yard:

See full entry

Location: Scot Grave Farm, Gedling, Carlton, Gedling, Nottinghamshire, East Midlands, England, United Kingdom

Here are the few observations from the OpenStreetMap edits between 11 November - 25 November. We looked into the filters like mass deletions, iD editor + mass deletions, possible imports, edited a name tag, mass modifications using OSMCHA for reviewing the changesets.

Commented:

  • Deleted tracks: changeset
  • Added random pedestrian highways and buildings: changeset
  • Deleted highways and few buildings: changeset 1, 2, 3
  • Deleted buildings and some amenities: changeset 1, 2, 3
  • Incorrect tagging: changeset
  • Changed road classification: changeset
  • Deleted neighborhood tags: changeset
  • Added Korean names in name:en tag: changeset
  • Deleted streams: changeset

Community members commented on the following changesets:

Reverted:

  • Added province tags to address: Community member commented and reverted the changeset
  • Undiscussed import: Community member commented and reverted the changeset 1, 2
  • Deleted houses and residential roads: Reverted the changesets with a comment 1, 2, 3
  • Deleted buildings and roads. Community member commented and reverted the changeset.
  • Added orphan nodes over buildings and highways. we reverted the changeset with a comment

These were some of the inconsistent data for this week. Do keep an eye out and comment on changesets, which will make us maintain the quality of data in OpenStreetMap.

Look forward for another roundup next week.

Posted by Glassman on 26 November 2016 in English.

One of my goals is to increase the number of mappers in Washington State by contacting them after their first edit with suggestions to help them get involved. My message was taken from the Brussels community. I can’t say it helps keep people mapping but it certainly doesn’t hurt. At least no one has asked me not to send them messages. (Most just ignore me.)

Because my process is manual, I look at every first edit and fix many of them. Those first edits often have common quality errors. I don’t believe they are from bad users, but from a process that could use improvement. We could insist that new users complete a course before they are allowed to edit. But that isn’t going to get us new mappers. Having existing mappers validate new users edits takes time away from their normal mapping.

When I do fix an edit, I include the change in the Welcome message. Occasionally I’ll leave a changeset message when I’m not sure what they were intending. Originally I was leaving a message and not fixing them, but after realizing that many didn’t go back to fix the problem I just started to do it myself.

I tried to look at this from a quality improvement perspective. First collect data then define the problem and finally look at solutions. My new mapper process has been running for over a year. While I haven’t done a proper job of documenting errors, something I’d like to do, some just keep reoccurring. Today I’m just focusing one one.

Problem Statement

New users edits do not include the lack of a tag to describe the business. For example, someone added an insurance office. The tag included the name, address, and phone number. Occasionally they will add a tag keyword to indicate what the business does. But no office=insurance. To the editor, this looks a good edit.

The developers did fix the problem of tags with just name=. It now notifies the user that they need to enter more information. We now need to take this to the next level.

See full entry

Work is in progress, features are improved and added. See the OSM Wiki page for more details and read some background infos below.

There is an Twitter-Feed: @OSM__go (two underscores!). You may follow the latest activities, upcoming ideas and related things.

Tile processing

Overpass seemed to be slow but my measurement was wrong because Javascript even delays console.log while callback code is running. A close inspection showed: Overpass is great, my code with a lot of string copy was slow and is now replaced by jQuery.js and getJSON. Much better, much faster but there was still that “wait-cursor”. Again it was me. I had simple linear searches for already existing nodes or ways. I replaced them by arrays with the OSM-ID as index. Odd to debug but fast. Now, the default load radius is set up to 800m and still fast. Or fine, if you are in a dense city. Old hardware devices may have trouble and get slow. Now the download will stop.

See full entry

Location: South Bank, Waterloo, London Borough of Lambeth, Greater London, England, SE1 9PZ, United Kingdom
Posted by Chetan_Gowda on 25 November 2016 in English. Last updated on 6 March 2017.

The SF Bay area community is trying to import height data for buildings in the city of San Francisco.

sf_comparison

Why we are adding height tag?

Adding height to existing buildings will enhance the data especially when used with popular renderers like OSM Buildings and Mapbox GL JS.

What is the source of data?

We are using raw LIDAR derived building height data released by SF local government under a CC0 (Creative Commons) license (data download here).

How are we combining the height to existing buildings?

For each building in OSM, we compare the footprint from SF goverment buildings, if there is 70% overlap, we add the height. Buildings with existing height tag won’t be touched.

The task is hosted in OSM-US. The importing has begun at http://tasks.openstreetmap.us/project/71

Note: Before jumping into the task, please read all the instructions carefully.

To know more about the project, or if you have ideas please post them here:

See full entry

Posted by BharataHS on 25 November 2016 in English. Last updated on 28 November 2016.

A previous diary post-The invalid areas of the map introduced us to invalid relations formed due to multipolygon relation being broken due to various errors. The post has a comprehensive discussions on different errors, its severity and respective simple fixes. It also has these interesting open questions which needs to be debated.

It seems like a huge majority of the issues need to be carefully reviewed by hand and cleaned up. What does a realistic approach to clean the map look like?

The flexibility of the current map editors allows mappers to continue to create features that don’t make sense like a way tagged as a forest. Is it time for stricter validity checks on uploads?

The current diary post walks through the tools which aids in fixing these invalid multi polygon relations which not only remains erroneous part of the map but also affects the map rendering.

Start by reading this documentation on multipolygons if you are trying to understand the basics.

How to identify invalid multipolygons ?

An error debugging tool from Geofabrics - OSM Inspector tool aids in identifying these invalid relations in OpenStreetMap. The tool can be either used in a web browser interface or as a layer in JOSM editor.

To use OSM inspector in a web browser,

  1. Go to http://tools.geofabrik.de/osmi
  2. Select Areas from ‘View’ menu.
  3. Left panel contains the list of all possible errors which enables user to toggle between errors.
  4. The map window highlights the node causing error and allows user to pan, zoom over the map in order to inspect the affected portion of the relation.
  5. The Selection panel at the right edge of the page displays the selected object and the small icons on the top leads you to map editors where one can fix the issue and also to open OpenStreetMap.

See full entry

Posted by alexkemp on 25 November 2016 in English. Last updated on 30 November 2016.

Mapillary is a Swedish organisation that, like Marvin the Paranoid Android in Hitchhiker’s Guide to the Galaxy, has a Data Centre for storing photographs as big as the planet. When you Register with them you can store GPS-registered photos on their site (really useful when surveying for later mapping).

My profile on Mapillary shows that I’ve uploaded 3,500 photos and have travelled 179.6 km whilst doing that. It also shows that I’ve uploaded the last 81 photos 6 times (making 486 total uploads in that sequence).

I’m currently mapping in the north of Nottingham in a district called ‘Gedling’ (south of Arnold Lane and north of Westdale Lane). 81 is a very typical number for me to shoot in a morning or afternoon whilst mapping. I used to use the Mapillary app in JOSM to upload, but tend to upload directly from a browser these days (the JOSM app requires a confirmation within a browser, so I cut out the middleman).

The sequence went very normally with those 81 photos, except that the Mapillary browser did not confirm the uploads within my profile. At first, I also got zero reply from Mapillary support. I kept trying to upload…

I eventually got an email from Katrin at Mapillary support, and she copied the email to Peter. According to the email that Peter sent this morning, the issue was because the “harvester for manually uploaded images has not been running” (he restarted it, so all 6 identical sets of images were harvested at once). Problems with a Harvester seem the correct kind of issue for this time of year.

Update:

I sent an email to Peter saying “So, no-one could manually upload photos? And I’m the only one that manually uploads photos?? Good lord.” Fortunately, he seems to have a sense of humour. He replied that:

  • no web-uploaded images have been processed in the last 2 days
  • that affected ~200 people
  • it involved ~500k images
  • mobile apps use another method, so uploads did not actually stop
    (they halved, hence no-one at Mapillary noticed)

Joke:

See full entry

Location: Gedling, Carlton, Gedling, Nottinghamshire, East Midlands, England, NG4 4BH, United Kingdom
Posted by poornibadrinath on 24 November 2016 in English. Last updated on 25 November 2016.

In the last two weeks, as a part of improving the quality of base-map data of Singapore on OpenStreetMap, the Mapbox data team along with the community has completed adding missing streets and buildings in Singapore.

For this task, the team used a combination of Mapbox and Bing satellite imagery to improve the road network and building footprints data. We presently have managed to refresh more than ~1200 kilometers of roads. Additionally, we also have added close to ~40,280 buildings.

Take a look at the visualisation below which shows the buildings added during the last two weeks.

sg_builings

See full entry