SK53 has commented on the following diary entries
|Starting around my local area||11 months ago||
It's quite likely that many POIs (post offices, places of worship, schools etc) came from the Geographical Names Service (GNIS). These are rarely located accurately (anything from a couple of blocks to a couple of counties out): a real bonus is when someone locally can improve these locations. Good hunting.
|Birding Spots of Bangalore||11 months ago||
Do tell more. Would be interested in sharing experiences about what is useful to map for birders.
|Mapping small / lesser known businesses in Slums of Mumbai||11 months ago||
If these are small shops or small craft workshops then tag them as such. It would be an excellent exercise to have one or two such places mapped in detail: only in doing so does one discover exactly what might need to be tagged.
I'd slightly take issue with the idea that selling good through a middle man is outdated. Many OSM contributors in North America & Europe, likely sell their labour exactly that way as contractors in IT industries. Certainly friends who run craft shops in Britain also need the middle men to provide them with work when tourists aren't around during the winter.
Direct selling can often be much more expensive than using intermediaries, and particularly so for smaller businesses, but I applaud your sympathy for these folk. It's worth talking to some of them: I think you might be surprised how well they know the marketplace they are in. Certainly I've had some really illuminating conversations with people running fast food outlets and local stores in the UK whilst out mapping.
|West Street Blues||about 1 year ago||
If you use a North America-based Garmin extract this may well happen!
I doubt it this applies to the most widely used UK-based extract (that by Talky Toaster).
UK addresses are a well-understood issue: they require diligent on-the-ground surveying. To say this is not everyone's cup of tea, would be an understatement. The main result of an open address initiative was to place under suspicion our biggest potential source of open address data: so whereas 18 months ago it looked like a lot of basic data could be developed semi-automatically, we're back to where we were before.
For several years I have been advocating using the Food Hygiene Open Data to add address data to already mapped POIs as a way of bootstrapping post codes and addresses.
|Cleaning up NHD in North Carolina||about 1 year ago||
@bdiscoe: no problems, its meaning was fairly obvious. As for canal/ditch in W US: this is a real mess. We also don't have sensible ways of separating an irrigation channel which is a foot wide from massive 60-100 foot ones, and those from canals for boats. My impression is most of the CO ones I little more than cut & cover channels of a few inches/feet; but one cant see anything on aerial imagery & therefore tends to the (false) presumption that NHD data knows what its doing.
I played a bit with a random area in the Upper Colorado Basin, where the data isn't quite as insane as in NC, but just a quick random edit stripped a few thousand nodes out of the imported NHD data.
|Cleaning up NHD in North Carolina||about 1 year 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||about 1 year 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||about 1 year 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: http://labs.strava.com/heatmap/#13/81.77449/17.00025/yellow/bike.
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||about 1 year 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||about 1 year 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 year 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:
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 year 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?||over 1 year 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||over 1 year 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||over 1 year 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||over 1 year 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||over 1 year 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||over 1 year 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||over 1 year 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||over 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.