SK53 has commented on the following diary entries

At least 2 of these are active mappers (brianboru mainly maps in Birmingham, England and was lead organiser of sotm-13, SK53_bulk is an import account which I used to for NHD data for the Upper Colorado Basin). There may be other mappers from Europe who contributed to clean-up of the interstate system around 2009.

Be careful, a road tagged "highway=unclassifed" is not the same as one tagged "highway=road", the former is a minor road (which is a better name) the latter a road of undefined characteristics which will not be used by routers.

In general industrial estates will consist of a network of highway=unclassified and highway=service. Major feeder roads into the estates might be highway=tertiary. It is worth remembering that the OSM highway tags reflect a functional classification: if roads are very wide in an industrial estate to accommodate trucks, but they only lead to a couple of warehouses, they are still service roads.

The only problem with OpenStreetView is that the code has not been progressed for a long time. There are plenty of people loading photos to it (particularly in Eastern Europe). If more people used it the process of curating photos would be a bit easier: last year I was uploading hundreds of photos which each needed 3 independent checks (because OSV is somewhat more stringent in how images are checked than some other places).

A really big improvement with OSV would be in how images can be accessed. Perhaps using leaflet with clustering would make it easier to browse the photos, and direct ability to pull OSV photo thumbnails into something like JOSM would be a massive step forward (rather than through a downloaded KML).

OSV also could do with something based on photo date: some images are 3-4 years old and might not be totally reliable sources.

Lastly I dont think we need 360 panorama photos of streets: much more useful for mapping would be strip photos of either side of the street. Some kind of tool which would 'rectify' images based on photographer position and a small number of control points on the images + stitching together would provide something different from Google StreetView and IMO more useful for mapping.

If I am to ask a newcomer to map a bus stop on OSM I am pretty confident that they would find highway=bus_stop a more obvious tag than the public transport schema.

Whereas the latter has received support in the the German community I think it is fair to say that such support is lukewarm elsewhere. The problem with this schema is that it is trying to solve a problem which does not exist in OSM: normalisation of a database schema. Having a common mechanism for tagging a concept of place where one waits for a public transport service is much more important IFF the data is stored in conventional tables in a relational database. In such cases we want to overload concepts (platform, halt, bus stop, taxi rank) so as to represent them in a clean as way as possible. The same applies if we have an application which wants to process multi-modal transport: generic objects and functions help a great deal.

However, overloaded concepts are not what we need in OSM for mappers. What we need are concepts which sit most comfortably with the implicit classifications which people use. Most of us treat bus/tram stops, railway platforms, airport gates, and taxi ranks as distinct. By keeping the core tagging as close to how people think about things naturally makes it easier for mappers because they dont need to look through elaborate wiki pages (with the title "Proposed" to further confuse them) or resort to tools like taginfo to try and disambiguate these usages.

Furthermore simple post processing rules to take highway=bus_stop, railway=halt etc and merge them for a particular application turns out to be really straightforward. We have lots of good tools for doing this too, notably LUA with osm2pgsql. Given that any public transport data need considerable post-processing before they can be used for generating routes there is little or no advantage to force mappers to do some of this work at the expense of greater cognitive complexity.

This is a fairly obvious example of a conflict in OSM tagging between the extremely particular and the extremely generalised (by analogy to taxonomy, one might refer to these tendencies as 'splitters' and 'lumpers'). The public transport schema is definitely an example of the 'lumpers'. There is much of great value in the schema, but as with many data schemas, the true art is learning that pragmatic choices must be made between the purity of the base conceptual schema and the nitty gritty of what gets used. Direct implementation of conceptual schemas often leads to unforseen problems, not least of which is that people tend not to understand them and therefore re-invent instances of the concepts. In other words if highway=bus_stop had not existed before the public transport schema, I'm sure that it or something very similar would have been invented anyway.

Here in the UK moving to a less-restrictive licence than ODbL would mean the practical loss of a large proportion of the road network, many addresses and virtually all postcode data.

In France it would eliminate buildings and possibly landuse.

Similar problems will exist in any country where governments maintain copyright over things they produce (hint, there are more of these than the US PD model).

This is because some data have been obtained from open government sources, frequently manipulated and enriched by OSM mappers, but always subject to the original licences of the source data.

This suggestion has been made before (IIRC it was discussed at an early SotM) but has only gained acceptance from a fairly small part of the community (often those most involved in FLOSS activities). You have to explain why contributing to OSM in this scenario will be crowd-sourcing and and not crowd-serfing for major corporations and governments.

I imagine there are plenty of easier ways to achieve some of your objectives: a simple idea would be a waiver for certain organisations from specific ODbL obligations for specific areas or types of data (e.g., NYC Buildings). This would still need some kind of approval mechanism from contributors, but is likely to be orders of magnitude less hassle than going through a change the licence process again.

It's best to stay what is used stylistically locally, and from what you say in Taiwan, this is highway=footway.

Many of us believe that highway=path tends to be far too ambiguous and requires much more elaborate tagging than simply using highway=footway, with, for instance sac_scale=*. Whereas highway=path tells us nothing about the typical traffic it copes with. Others use highway=path for paths in the countryside, not in the town; and others still use it in a way analogous to highway=road (i.e., its been mapped by aerial survey and it may be a footpath a track or even just an animal track).

Of course it is possible to infer that a highway tagged with sac_scale is suitable for walking (or scrambling at the high end of the scale), but footway makes this absolutely clear, that it is a route predominantly for pedestrians.

If you know the paths, it is certainly useful to add sac_scale (especially on those sections of paths which are not straightforward sac_scale=hiking).

@Dick Tecktiv: WRONG. OSM data are used for analytical purposes, for instance the length of hedgerow in farmland is a good parameter for assessing the lands suitability for nesting habitat for birds. Most landuse will assign a landuse/landcover type of highway to encompass the road surface and its wider corridor (verges, pavements/sidewalks) etc. If your bring landuse to the road centre line then it forces people to make approximations for the areas used by the highway. What you suggest simply does not take account of the multitude of different things OSM data is used for.

For goodness sake please don't use addr tags to do this: some people use the address data to do things like routing. Using it to store character strings which already looked tacky on maps 30 years ago (tagging for the renderer) just makes everyone's job harder.

Please clean this up! Otherwise you may be forcing EVERY consumer of address data to write special code to remove all your 'poor-man's rendering' tags.

I also think you have guaranteed that any change requests you make regarding rendering will not be treated very seriously. We have hundred's of thousands of contributors and a core team of developers which struggles to reach the hundreds. Ask yourself why these people should prioritise what you want over lots of long-standing requests.

There is currently work to improve rendering of many items now that the rules have been migrated to CartoCSS rather than the unwieldy raw XML format used previously. However, this needs people to do the work rather than suggest that somehow it's an excuse.

Notwithstanding this, not everything will ever be rendered. It's just not sensible or practicable. Even at the zoom leves now in use things which do have rendering rules are not shown because of clashes between rendering rules. Cartography is as much the art of not showing things as well as showing them.

A fairly naive approach is to buffer existing OSM roads (try 10,20 & 50 metres) and then do a difference operation between the buffered roads & the SA road data. Obviously you'll lose roads within the buffer distance of existing roads but it will probably identify the vast bulk of roads which are missing.

Will probably work best in PostGIS rather than directly in QGIS unless you have loads of memory.

I liked what I saw of Mikel's SotM-US presentation simply because I felt it would make my life easier in a) organising the Nottingham pub meeting; b) discussing local mapping issues (currently done with a few people through email); and c) sending appropriate welcome / assistance messages to new mappers. (One might characterise these as 'curatorship' roles).

I don't see this as 'social' in the way of Twitter, Facebook, etc: but a pragmatic response to a need to better connect mappers who share an objective, need, or location. Many mappers are not available through any other route than their OSM user name: many, like me, would prefer not to be forced into using 'social' sites just because we contribute to OSM. So, equally, pragmatically the OSM platform is the obvious route.

If someone can come up with a wonderful way to fix the mailing lists (we lost a significant contributor from a local list recently) so that one's mail box isn't deluged by stuff, so that they aren't dominated by the same voices, so that discussion is aimed at moving OSM forward instead of point scoring or deprecation (of people , mapping & tags), then I'd be very happy. However, I don't see it happening, so we have to try something else.

There are two points in Alex's list which I really don't like, they both relate to sending messages to newcomers. I do a bit of this but SomeoneElse has been doing it for over 4 years.

Helping someone finding their way on OSM often is best done privately and we use the OSM message system for this. Forcing stuff out into the open (the wall), or into another channel will just reduce the ability to offer support to new mappers. The wiki discussions I've witnessed over the past 4 years have been in the open, but most have not benefited from this, and most only display (an apparent) consensus because the groups are self-selecting.

One last point, if you look at OSM Stammtischen in Germany the numbers which are meeting regularly and the core number of attendees are both quite small compared with the size of the mapping community. So I'd back Richard's point that the stereotype of extensive local meet-ups is not backed by much.

Whereas I believe OSM should be a good platform for this type of information we have some way to go in developing robust approaches to capturing it. (In fact my recent stuff on shops and other retail outlets is really about looking at the 'value' chain for creating data for a sub-set of commercial entities). I think the same issues are likely to apply for industrial entities.

Ensuring comprehensive coverage (initially for selected areas, broadening these out as the basic issues are better understood).

Although there are many directories containing this type of info, many are copyright and most have huge amounts of cruft in them. Even things like company registrations (if available as Open Data) are likely to have poor encoding of industry sector (no one checks, its just for the statisticians, so there are no serious controls).

One starting point is to look at specific industry sectors which tend to have large, obvioius and well-known industrial or manufacturing plants. Off the top of my head: steel works, car factories, shipbuilding, chemical works, petroleum refineries). It's probably easier to get the OSM community to map one or more of these as a challenge.

You can add atm to your list (probably more frequently used than any of the above).

It's fine to peeve, but it works two ways, there are plenty of tags which are completely opaque or confusing to native english speakers too.

IIRC cycleway=asl (advanced stop line) was discussed, but probably on the osm-gb IRC channel and around 67% of current uses are in Great Britain.

Some uses of abbreviations are inevitable, such as ref:INSEE (not obvious if you're not French) or ref:vatin, particularly when these are not supported by editors. Needing to type in cycleway=advanced_stop_line is a good way to discourage their mapping. Your examples happen to all be documented on the wiki, which is a tad surprising. Adding editor support for such keys can hide the naughtiness of illicit use of abbreviations in the value.