SK53 has commented on the following diary entries

Post When Comment
Cleaning up NHD in North Carolina 1 day ago

This is a really useful discussion.

I remember trying to tidy up bits of this data around Wrightsville Beach and giving up. It didn't help that my memory of what was there is rather fuzzy, but it was quite clear that some wetland features just shouldn't have been there. I suspect most of my cleanup was just node de-duplication. Certainly I did enough of that sort of thing to write-up my process. I think EdLoach used this idea tidying up Georgia landuse until someone objected.

Looks like I need to run over the Colorado Basin data too, also complicated by intermittent watercourses.

Lastly, I'd not come across the term "decimation" applied in this way before: obviously it's a GIS term. Not all of us have that background, although its fairly understandable after the second or third reading.

Hadjer Lamis, Chad - Tracing guide 14 days ago

An exemplary description of detail needed for intelligent remote mapping. The availability of photographs and on-the-ground descriptions (as well as a round up of the more typical gotcha's) should help everyone. Furthermore I think a lot of this description can be useful for many other parts of rural Africa, and even Asia. (It wouldn't do any harm to have such descriptions for Western cities either)

It may be useful to explicitly tag tukuls in some way. I vaguely recall thinking about this with mokhoros in Lesotho, and indeed over 9000 have been tagged explicitly and a few more with building=hut, hut=mokhoro. Personally, I have some reservations about building=hut for dwelling places, but can't think of a better alternative. Certainly it is better to use a generic tag than to have tens of regional names for small circular thatched buildings built from local materials, whether tukuls, mokhoro, or Sindhi round houses. One other thing I have wondered about such buildings is what materials are used for thatch, and whether its is possible to map where such resources are located.

Mapping my hometown Rajahmundry 21 days ago

@Warin61 is quite right, but the imagery alignment problems are very daunting for the mapper.

As @SimonPoole says getting some useful alignment traces really helps. In the past mappers in India without access to a smartphone capable of recording GPS traces have managed this by borrowing such a phone from a relative for an hour or two. Otherwise if you have a GPS-enabled phone an app such as GPS Tracker can be used.

Open spaces such as parks, temple precincts, wider highways are good places to try & capture decent GPS traces. Ideally you want a few as an individual trace will be affected by day to day vagaries.

There are a limited number of Strava tracks available in the area, but at least these can be used immediately:

You also may like to use an editor which uses the Imagery Offset database, which at least would allow the same offsets to be used consistently.

I would like to echo others comments that this is a nice write-up.

Units in OpenStreetMap 29 days ago

The place for a cleaner database is not the main OSM API DB which mappers contribute to, but as a separate database where tag values can be normalised, additional values added (for instance higher-level categories, perhaps multiple versions of ways with different degrees of simplification etc. At the moment all these things happen but in application specific databases (such as the osm2pgsql format & numerous routing formats including your own),

I think one or two people have tried this (e.g., OpenCageData), but as a community type activity it would run into precisely the issues the current data has: who selects the values & transforms. Normalisation of data structures is even worse: many things tagged in OSM look quite simple on the surface, but often turn into really complex data modelling issues if one wants to formally capture all the nuances of what is tagged (I have a 30+ entity model to encompass what gets added to post boxes & I haven't even added anything about collection times which are at minimum a similar order of complexity again).

I also don't think we're ready for it either. Your own example probably demonstrates that the number of height & weight restrictions actually mapped in the US is a drop in the ocean compared with those that exist. Only when significant numbers are mapped does the tagging tend to coalesce around more consistent values. My best guess this is occurs when around 5-10% of actual things have been mapped.

BTW: I would love to be able to tweak Graphhopper without having to code Java, in exactly the sort of ways RIchardF describes. I also appreciate that GH may have the same issues with respect to number of developers as OSM editors.

Units in OpenStreetMap 30 days ago

This is a really old discussion. When I first started contributing to OSM many speed limits in the UK were in metric units (I hesitate to call kph SI): no 30 mph, but 48.##, or 50 because it was easier. Guess what, folk couldn't be bothered to map speed limits, too complicated.

Maxheight in Britain is usually expressed in both feet and inches & a metric value: but the conversion used involves rounding. I believe there are some older rarely used places with only the older signage. Thus in this case both values should be tagged.

The last point is that over time there is a tendency to not just do the transformation (a speed limit sign to a speed limit on a road section), but also to map the actual original information (the sign itself). I think it was the Finns who first developed this idea. It greatly assists in checking for errors and for validating existing data. If units are converted it becomes much harder for someone to check that such data is correct: and don't ignore the likelihood that people will use approximations, perhaps to come back later when they've found a conversion formula.

As SomeoneElse said in the changeset comment: preprocessing out-of-band values is essential. You have to do it on data coming from databases with reasonably sensible constraints, so its unavoidable on data which is free text. Only today I've been processing postcodes and apart from partial values, garbage in the string etc, there have been several telephone numbers. Of course a nice thing is if one can 'close the loop': inform the contributor who generated those values in the hope that they will correct/improve them.

In summary: asking for contributors to do more will probably cause them to do less.

Quantifying HOT participation inequality: it's complicated. about 1 month 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 about 1 month 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? about 2 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 about 2 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 2 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 2 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 3 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 3 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 3 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 4 months 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 4 months 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 5 months 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 5 months 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 5 months 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 5 months 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