SK53 has commented on the following diary entries

Post When Comment
Copying from Google Maps 18 days ago

Please remember that after the 2010 earthquake in Haiti OSM had explicit permission to use some post-quake imagery owned by Google. In any analysis please make sure to take this into account.

Surau and parking in building enhancement suggestion 4 months ago

I think the useful thing you can do is to add a description of the place_of_worship=musalla tag on the wiki. I suspect these locations which I have mapped fit this description too:

Releasing Turn Restriction Detections 5 months ago

I only checked one in Pittsburgh, and that also appeared to be mapped.

Mapping Baseball Fields 6 months ago

One example of a cluster of fields of different sizes:

Mapping Baseball Fields 6 months ago

There are many places where there are fields if different sizes: the smaller ones presumably for small children. This is also true for soccer pitches: facilities in primary schools are often much smaller than standard pitches ( and I presume smaller than the minimum regulation size, which used to be 100 by 50 yards).

Routing QA [eng] 7 months ago

For basic motor routing graphhopper with CH requires less post-processing.

Mapping Swadlincote (Derbyshire) only by strolls 7 months ago

Indeed it's great to see someone mapping in this area. Little correction we go to Derby 1 time out of 3 (every quarter).

The villages S of Swad (Coton-in-the-Elms etc) are a potential target for a footpath mapping meeting just after Christmas (more soon).

Canal and bridges 8 months ago

Don't believe the wiki: bridge_ref is the standard used in the UK.

Possibly importing USGS forest data about 1 year ago

I fully support the remarks.of Vincent de Philly & Imagico.

I have made a number of experiments trying to extract natural woodland from landsat imagery for Tierra del Fuego using tools in QGIS. Most landsat data which is relatively cloud free has deep shadows making it very hard to find suitable filtering conditions even when applying corrections for the angle of view. No doubt similar or entirely different problems apply elsewhere. Note that the Natural Earth urban areas were created using remote processing of landsat data and are full of errors.

There are active OSM contributors with real in-depth experience of processing remote imagery for detecting aspects of woodland: I'm thinking of NextGIS who created a QGIS plugin which they used for finding old-growth forests in Russia (notably in the depths of Siberia). Such people/organisations should be consulted on data quality for this dataset.

OSM works best when we don't race to complete some particular feature class with poor quality data. It is much better to be a little bit patient and allow the organic growth of the community to both work on getting additional sources of imagery/data, and to map these features. As VdP says things like Corine data require so much post-import reworking that the data is often seriously out-of-date before people get round to it.

I believe, but cannot be certain, that there is some possibility of using this, or similar data, in a similar way to the Natural Earth urban areas for low zoom rendering.

import geonames data over 1 year ago

I'd agree with @Zverik. Even for the United Kingdom geonames data is of very variable quality. I wouldn't be surprised if places local to you are incorrectly located or their names are not immediately recognisable to you. Often they are extracted from old US military maps and transcription of names may not follow modern standards; furthermore in many places some names may no longer be used. See what I wrote about geonames in Pakistan a while back.

Nothing is more valuable than the knowledge you yourself have. I know it is frustrating when there are places lacking in detail, but OSM seems to work best with a slow but steady approach to adding data. The Tortoise not the Hare (

Alpine Ski World Championship meets OpenStreetMap: Who are the Mapping Champions? over 1 year ago

Hmm, a shame one of the medallists appears to be adding fantasy ski runs in the Engadin area.

Finding dragged nodes over 1 year ago

OSM-GB a project at the University of Nottingham which ran over 2011-2013 provided all these type of error checking for Great Britain, but like every other OSM error checking routine it tended to produce too many false positives. Many of the TO-FIX reported errors may indeed be errors but many are one-or-more of a) trivial; b) unimportant (eg in service roads); or c) require too much time to investigate. Eyeballing a list of contributors in a region is still often the best way to identify changes which need checking.

One kind of check we have relatively little of is dramatic changes in geometry for something which has been stable for a long time. Of course this wouldn't work in the US with TIGER fixup, or with re-drawing NPE waterways in the UK, but it would make it easier to see potentially regressive edits.

Are you joking ?? over 1 year ago

@BushmanK I dont rely on the documentation as this is often misleading and not infrequently an interpretation of one person, or a small group of people. I'd far rather that the wiki described HOW people used tags than saying how they SHOULD use tags. As fo descriptive and prescriptive grammars the former does not preclude tags being wrong: anyone tagging a lake highway=motorway is indubitably wrong.

On the other hand the US interpretation of landuse=forest (and a few other tags leisure=recreation_ground, place=hamlet, highway=residential etc) is very far removed from usage anywhere else. So even if it is consensus tagging in the US it is not on a worldwide basis.

@Circeus: that looks like individual townships of national forest land have also been tagged forest even though the landuse tag has gone from the large polygon (national or state forest).

Are you joking ?? over 1 year ago

The issue is that US mappers have used landuse=forest to map administrative areas owned and managed by the Federal US Forest Service (mainly National Forests). In virtually all the National Forest areas much of the land is actually used for other purposes: for instance in Summit County Colorado many of the main ski resorts are situated within the National Forest.

Unfortunately, although the topic is discussed from time to time on talk-us, no real consensus has been reached to use this tag in ways closer to how the rest of the world uses it. Recent discussions do suggest some viable alternative tagging approaches, but I'm not holding my breath.

Validating Wikidata tags on OpenStreetMap over 1 year ago

Not mentioned is that wikidata co-ordinates will many times represent data added to Wikipedia from sources which are not compatible with the OSM licence.

Equally I presume that there are many objects both in wikidata and OSM (notably imported GNIS nodes) which may agree in location but in fact are wrong.

Some wikidata objects are a very long way from their actual location: see Likely because the originator of a wikipedia article copied over information from another article & forgot to change the lat/long information.

The Italian community had a tool for comparing wikipedia and OSM items (sorry dont have a link), but it was based on administrative geography (usually represented in the wikipedia articles & wikidata) and on classes of objects (places, historic buildings ...). There were a number of advantages in my view: one could focus both on topic & area; missing or incorrect data showed up both ways. Fixing things could be done purely by searching for a putative missing object in OSM, adding it to OSM & then potentially fixing wikipedia. In this way the only information I used from wikipedia was a) such and such a place exists; and b) it's located within a given admin geography.

In summary there are multiple reasons why a straight comparison of locations may not only be misleading but may encourage use of undesirable sources for edits which may not improve OSM.

POI standardization: Tractor Supply Co. over 1 year ago

I'd completely forgotten that I'd documented this on the wiki! Mapping in a couple of small country towns I came to realise we'd missed this category, and after a bit of sleuthing I realised that it was not insignificant: say, a couple of hundred in the UK.

Let's collect more information about formats in the US. I'd be rather surprised if there were not something similar in Canada and Argentina. I presume they evolved from the historical general dry goods store. If the TSC category is slightly different from those in the UK then maybe the formal use in Retail Week rural_supplies will cover a broader scope better.

POI standardization: Tractor Supply Co. over 1 year ago

I wonder if there's any overlap between your shop=farm_supply and what we map in the UK (or at least the East Midlands) as shop=country_store.

These sell a range of farm supplies, but usually in smallish sizes so you cant buy enough seed to sow 25 hectares with wheat. I get the impression that most customers are folk with a few acres, probably grazing for horses: small-holders, hobbyist farmers, stables etc. Therefore the pet side is significant.

Mapping natural and planted habitats over 1 year ago

Again can only agree. There's many a time when it's the only thing I've been able to do because image resolution not enough to pick out which parts of a woodland are conifers & which not.

Mapping natural and planted habitats over 1 year ago

Dont know why I didn't comment before. I think I am very much in agreement with this. It's not just that using a multiple dimensional tagging approach helps inexperienced users, but in many cases even the most experienced user only knows "here be trees".

Other dimensions:

  • Canopy height
  • Species mix
  • Ground layer: is this a bluebell wood or a marsh
  • Field layer: is it bracken, heather, bilberry, bruchholz, brash, bramble
  • Shrub layer: does it exist, what is it composed of, density etc
  • Tree spacing
  • Dominant species (when appropriate)
  • in management: plantation (i.e. regularly spaced in rows for easier harvesting), coppicing with standards, selective removal etc
Railway Crossings challenge for MapRoulette over 1 year ago

With respect to Postgis queries: gridding the data is always a good strategy for reducing in-memory processing requirements. For analysing European & US road networks I've experimented with grid sizes anywhere from 7.5 minutes to 10 degrees. I would imagine for this task you'd probably be fine with something of the order of 1 degree.

Another route for your data would have been Overpass querying for highways sharing a node with a railway. Max Erickson is usually my goto guy for how to do this kind of thing.

If you used Osmosis to populate a snapshot schema then you just need a plain SQL query on using ways, and way_nodes. You want all nodes in the way_node table which belong to at least 2 ways, something along the lines of the following (untested) (SELECT DISTINCT node_id FROM way_nodes wn JOIN ways w ON wn.way_id = WHERE (w.tags?'highway OR w.tags?'railway') GROUP BY node_id HAVING COUNT(DISTINCT way_id) > 1) and COUNT(DISTINCT COALESCE(w.tags->'highway', w.tags->'railway') > 1). I'd actually do this as separate queries to reduce the number of table scans on the big initial hit on way_nodes.