SK53 has commented on the following diary entries

Post When Comment
Data issues in Japan about 22 hours 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 9 days 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 16 days 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 23 days 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 about 1 month 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 about 1 month 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 2 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 about 2 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 3 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 3 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 3 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 3 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

shops as closed-Way building outlines, but also as Nodes in the center? 4 months 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? 4 months 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 5 months 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 5 months ago

Great bit of detective work!

Melbourne tram stop project - first post 5 months 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.

#1009 - Nepal Earthquake, 2015, Gorkha 5 months ago

Some of the aerial imagery, particularly the grey scale MapBox imagery is quite difficult to interpret and in particular I have noticed that ridge lines and valley bottoms are often initially difficult to pick out.

The two ways to check are a) use the OpenCycleMap layer which shows contours and b) zoom out until you have Landsat satellite data. With the latter the overall topography becomes much clearer. (I may put a bit on the wiki in the next day or so now that you've raised it).

In areas where this is particularly difficult to interpret I actually crudely map ridge lines (natural=ridge) as well as waterways. This not only provides data, but helps to keep the context of the imagery clearer. I discuss this a little on my blog about mapping Lesotho.

How many amenities are open for a given time? 5 months ago

Nice thoughts.

I think the graphs are confusing because of the variable axes. In practice the vast majority of entries are parsable. I'd suggest making the % axis from 0-100, and perhaps adding another line showing total parsable entries using the right axis.

What I dont get a feel of is how many elements might have opening hours tags on them vs those that dont: for instance most shop=* might be expected to be valid elements for opening_hours.

Another thing which one might be able to pick up, in Germany at least, is the local Ruhetag, just from which day typically has different opening hours in an area.

Potlatch and contour lines 6 months ago

I imagine you used OpenCycleMap as a background layer. This no longer appears in the default layers. I dont know if this was deliberate, or accidental. I imagine you can still create this as a layer for Potlatch2.