SK53 has commented on the following diary entries

Post When Comment
Quantifying HOT participation inequality: it's complicated. 10 months ago

I miss the detail of how you derive the labour hours for contributors. If I edit offline in JOSM and do not sign-up via the Tasking Manager how do you know how long I spend on my edits? Many experienced contributors to OSM will tend to prefer their personal workflow to that imposed by TM.

Other well known factors contributing to these phenomenon in extreme citizen science (following Hakaly's terminology) activities are:

  • Skills. Contributors have different skill levels. In this context core skills will be: familiarity with OSM editors, interpretation of aerial imagery, familiarity with OSM tagging, personal workflow. In many domains those who have mastered core skills can result in 10-100 fold greater productivity compared with those who haven't: but particularly true in citizen science context.
  • Triage. Some contributors may focus better on the easy to map important stuff rather than trying to complete a square. My impression is that proportionally a lot more effort will be spent on the final stages of square completion than earlier phases. I would expect this to also show a Pareto curve.
  • Early Mover advantage. A skilled experience contributor practising triage may map a much larger percentage of the easily mapped things in a particular area if they start contributing at an early stage in the project. This was certainly true of Haiti: it was quite hard for newcomers to find something useful to contribute around Port-au-Prince within a few days. Another factor in this is its much easier to draw a road network on a blank area of the map.

I suspect that on-the-ground experience cuts both ways: it eases interpretation, but at the same time inhibits mapping stuff known to be more complex than imagery allows.

Audio Mapping first steps 10 months ago

I still use audio mapping but rarely try & get it to match my GPS track: partially because I have an older digital dictaphone with only around 1-2 hours storage, and secondly because I found the voice-activated feature more practical, which effectively dropped the timestamps.

Transcription of files and/or direct editing OSM whilst listening to the audio is still cumbersome.

As for automated recognition, I feel that there is great scope for this is in validating existing OSM data so as to effectively re-survey places. It is quite difficult to spot changes in densely mapped places, and some kind of map=>speech in conjunction with simple recognition a very simple set of speech responses might help.

How can we double the number of active mappers in the US in a year? 11 months ago

One idea which I like are the creation of locally-based OpenStreetMap sites. Son & father team, Will and Richard Phillips, have done this for Nottingham and Evesham in the UK. Some of this work was presented at the recent SoC/BCS Mapping Together conference in York.

These sites also pull in open data from local & central government bodies and make use of a range of raster map layers (including historical ones). Thus, they not only make thematic data from OSM more readily visible, but also assist the mapping process by making the trawl through potentially useful open data much more focussed.

(Please note that Richard passed away very recently).

Data issues in Japan 11 months ago

It would have been great if this post had been written in the language of the local mappers. Perhaps you could reach out to someone in the OSM Japanese community who could assist you with translating this post. I think it is vitally important that future communication be carried out at least bilingually, but best with the lead documentation in Japanese.

As an aside much of the Yahoo import contains a large number of redundant tags. I'm not absolutely sure, but I think the main import was carried out shortly after the Great Tōhoku earthquake. Needless to say the attention of most mappers was dedicated to mapping areas directly affected by the earthquake.

This issue is typical of a) imports; and b) areas which are intensively mapped after a disaster. A huge volume of data is which is beyond the capacity of the local community to maintain. Even resolving the current issues does not address the key one. Always the best strategy for improving OSM is to grow the local community to the point where it does have enough capacity to improve the mapping in rural areas.

tagging cricket nets 11 months ago

There isn't a problem, and hasn't been for years. The problem is only in the eyes of the active members of the tagging list.

Average number of tags per way in OpenStreetMap 11 months ago

You need to use a different graph type: the data is not appropriate for a stacked graph.

Postigs question - find out the unnecessary points that exist on the map 12 months ago

I did actually do a calculation on this for part of the USA (TIGER data suffers particularly from over-noding).

To do so you need a snapshot database. Only nodes without tags and only appearing once in the way_nodes table need to be checked. I just compared length of the shortest line from the node to a straight line between the adjacent nodes. I can't find the code I ran, but certainly there's great scope for reducing the size of data in the US.

Trolltags 12 months ago

@redsteakraw: OHM is not conceived as a dumping ground for random things which no longer exist in the real world.

As currently constituted it works for the construction of well-defined data sets which are consistently mapped for a specific historic period. These data sets are currently quite small and manageable. Adding every recently demolished building from OSM brings nothing to OHM (you can find them from the OSM Full History dumps) and makes the work of server maintenance, editing and data consumption much harder than it needs to be for a project which is at an early stage.

Support Green Mapping (Classification), Volunteers for Grass&Green Needed 12 months ago

Looks like a well-chosen subject area where there is a real need for significant improvement in OSM. Wishing you every success.

Mapping Streams in Mountain Areas about 1 year ago

One trick I find is that if using JOSM the basic structure of the terrain tends to standout in Landsat imagery. Sketching the basic pattern of the streams and rivers at low zooms can really help to maintain orientation once refining the detail at higher zooms. I often trace ridge lines for the same reason. Using Overpass-turbo can help keep an overall prespective on ones work.

Mapping Streams in Mountain Areas about 1 year ago

One trick I find is that if using JOSM the basic structure of the terrain tends to standout in Landsat imagery. Sketching the basic pattern of the streams and rivers at low zooms can really help to maintain orientation once refining the detail at higher zooms. I often trace ridge lines for the same reason. Using Overpass-turbo can help keep an overall prespective on ones work.

Potlatch without Flash about 1 year ago

@zarl: really that comparison is entirely subjective.

As someone with approaching 10,000 changesets who nearly always uses Potlatch, I suspect that the idea that it is 'only for beginners' is just not supported by the evidence (see for instance Editor Usage Stats page on the wiki). I certainly don't find JOSM 'more fluid': I find it better for a limited set of tasks: extensive relation editing, large scale mapping of buildings, complex manipulation of tags associated with multiple elements, performing reverts etc. and keeping a copy of stuff when I dont have an internet connection and will do a series of small edits.

Obviously Potlatch's lifetime is dependent on Flash support, but the fact that it is 'not actively developed' also reflects that it is pretty complete for most editing purposes. However, there have been at least two recent useful additions to the functionality of Potlatch (tasks, & bookmarks), and the first point release in several years, so I suspect that is also overstated. There is abundant evidence that part of 'not actively developed' is an overly hostile style of communication with the principal developers (and this is not restricted to Potlatch).

Lets get away from the idea that there needs to be a hierarchy of editors, whether it be in some measure of quality or experience of users. Different people have different approaches to how they map and add data to OSM: people will tend to gravitate to the editor which suits them and the kind of things they map. I for instance dislike the modal approach of JOSM, whereas a friend who uses CAD software in her day job ,of landscape design, likes it for the same reason.

Not only is there scope for all existing editors (there are still a few folk who prefer Merkaartor), but there are plenty of other editing models which are as yet unexplored (various mobile approaches obviously, but voice activated as suggested by RIchard @ sotm-us this year, and editors which instead of modelling OSM concepts, model real-world ones). However, we have a long-standing problem of relatively few people willing to put up with the flak of editor development.

New road style for the Default map style - the first version about 1 year ago


The OS map example is excellent, because it also shows you things which are more or less impossible to read even on the 1:25k cartography of the OSGB. Notably that there are footways between some of the roads in the top right-hand corner. This is a personal bugbear of mine with the Explorer maps: it is more or less impossible to use them to navigate in urban areas which are rich in paths. For instance, about 5 years ago, I was in Corby and needed to walk from the centre to a hotel on the outskirts. Much of Corby was blank on OSM so I used my Explorer map: the safe route I took was around 1.5 km longer than the shortest route, because I did not want to risk finding myself in a dead end. Currently OSM standard rendering is much more satisfactory for this purpose than OSGB: even if OSM was not designed at the outset for such a purpose.

In practical terms this is because OSGB shows hedges & fences in urban areas which tend to create too much clutter for things like paths to be readable. It does make for an attractive product, but they certainly have scope for improving this: for instance subtle difference in style for urban/rural areas (which is something we should consider for OSM).

New road style for the Default map style - the first version about 1 year ago

Hmm, markdown for images doesn't seem to have worked. Here are links:

Red Motorways on OSGB 7th series:

Blue Motorways on AA Road maps:

New road style for the Default map style - the first version about 1 year ago

With respect to the motorways are blue issue. It might be interesting to look at the history of this colour selection by the Ordnance Survey.

Historically the 1 inch series used red for primary roads ('A' roads) whether they were designated trunk or not: the difference was shown by a "T" in brackets after the road number.

OSGB 7th Series Motorway rendering

Here's the same area on current OSGB Landranger via Bing Maps.

When Landranger 1:50k maps were introduced in 1974 one of the major changes in appearance was that motorways became blue. I am sure there were three factors behind this: the maps had become much less useful for both motorists & pedestrians as the motorway system developed; blue was also the colour of motorway signs and thirdly, for cost reasons, they needed to use one of the existing colours (IIRC 7th series used a 7 colour print process). I am sure they considered any implications of confusion with rivers at the time.

I can't remember much fuss about this change: there was a considerable brouhaha about administrative borders and path symbols being too similar (which led to a change quite quickly).

Trunk roads became green much later (and trunk & primary are still shown with similar styles on the more walker-oriented 1:25k maps), but I would think the motivation was similar: to make the maps more useful/appealing to motorists.

I'm not absolutely sure, but I think blue for motorways may have first appeared on AA maps. Here's one example from the mid-1970s:

AA map with blue motorways

shops as closed-Way building outlines, but also as Nodes in the center? about 1 year ago

As someone who has been working to create a global POI dataset of retail outlets I can confidently state that this is fairly straightforward if one uses osmconvert (or for more limited data overpass with the centroid feature).

Processing the data to remove duplicate node/polygon elements turns the simple code into something far more complex. Interestingly following MarkusHD's approach means that things like address data can be incorporated trivially in the data set. So I'm happy with duplication of addresses (straightforward as we, like many others, treat addresses as attributes of elements, rather than elements themselves), but vehemently object to duplicating elements themselves.

"Duck Lanes" on OSM? about 1 year ago

Please dont map animal tracks in general & certainly not as paths. First in some places there are many many animal tracks (mountainsides with sheep come to mind). Secondly, animal tracks tend to change depending on circumstances. Thirdly, mapping lots of traces which are not necessarily usable by people will just make OSM data hard to use.

Thoughts on the import of address nodes in JOSM using MassGIS L3 Parcel data to aid in adding addresses to buildings in MA over 1 year ago

Virtually all the MassGIS imports have suffered from major and significant problems. Firstly the import of streets did not join ways at boundaries. As the import was on city/town boundaries rather than county elsewhere making MA routable was extremely tedious.

Current parcel boundaries do not seem to be massively accurate. For instance this playground in Yarmouth Port is not contained within the two forks of Playground Lane and Old Church Road. It's a while since I last visited, but Google StreetView & Bing aerial imagery confirm that the MassGIS boundary shown on OSM is inaccurate. A little to the East beyond the end of Damaris Drive there are multiple overlapping polygons for wetland & conservation areas: very difficult to work out what they are doing. I've tidied some of these up using aerial imagery/memory in the vicinity of Bass Hole/Grey's Beach, but my impression is many of these polygons are more general than we expect with OSM.

Another area with problems in the past was the Hyannis Transportation Centre. Most buildings had been imported, but as they were imported some considerable time after the roads; the new road network was not in place. I added this (and fortunately Lars Ahlzen has done more) when trying to put the P&B bus route in.

The significant problem with these imports is that everything looks complete, but in reality it requires considerable revision, checking against current status, and judicious removal of useless data (see the large number of tags on the playground above). Very large numbers of highway=residential are nothing of the sort, but most likely driveways to properties (certainly along the Kings Highway in Barnstable, Yarmouth Port, & Dennis places I'm reasonably familiar with).

A side effect of this is if one looks at POI density in the Upper Cape, it is woeful. Only 28 restaurants mapped in the Barnstable admin division, which includes multiple popular holiday resorts including Hyannisport. (Only 1 in Rockport, 4 in Gloucester, 1 in Plymouth, 8 in Harwich, and NONE on Nantucket, etc). It doesn't help that GNIS nodes are often inaccurately placed (such as Friends Meeting House on Nantucket which is several streets away from its actual location), and close to its likely location MASS GIS buildings sit on top of MASS GIS roads.

All in all these are reasons why I would be extremely cautious about further mass imports of data for Massachusetts. I cant be certain, but my basic feeling is that at least POIs would be better represented in the absence of these imports. Adding housenumbers would give further weight to the appearance of a complete and detailed map: but in practice in places I know, OSM is much less useful than it could be.

Alternative processes would be to put your data set up somewhere so that local users could use this as the basis for mapping (e.g., as a tiled layer or similar), or simply make it available in such a way that it can be integrated with OSM data at the data consumption stage, so that applications can use it (in practice geolocated address nodes may be all that is needed)

Vikumberg, Fünfenberg, Tabor nad Botačem, Draški Tabor, Tabor di Draga, Castello di Moccó, Lorencan, Sv. Lorenc over 1 year ago

Great bit of detective work!

Melbourne tram stop project - first post over 1 year ago

You might like to take note of Mapillary. Open Data from VicRoads is being progressively loaded onto Mapillary: this may really help add details without committing to visit every tram stop.

I cant find an example with trams because many of these sequences have not yet been fully processed by Mapillary and dont yet show up as a blue line on the map.