SK53 has commented on the following diary entries
|Panoramic views aka "Street View" on OSM?||11 months ago||
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.
|highway=bus_stop - Mappen für den Renderer||11 months ago||
This is your personal opinion.
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.
|OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike||12 months ago||
There are many points which you elide over.
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.
|Wrong tags on Path||about 1 year ago||
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).
|Landuse and highway sharing||about 1 year ago||
Farmers in the Western world these days are much more likely to have extremely accurate GPS which is used to determine exactly where to add fertiliser.
You make far too many assumptions about land registers, and anyway a lot of this data is not available, or very costly, in many countries (the whole reason OSM started in the first place).
|Landuse and highway sharing||about 1 year ago||
@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.
|BBC Radio 4 doc "Mapping the Void"||about 1 year ago||
That or a vanity/cringe listen!
|Important unpaved roads exist, so wiki.openstreetmap.org/wiki/Highway needs a reboot||about 1 year ago||
Just a minor note:
highway=primary in the UK can refer to:
So, even in the UK we have always had the notion that OSM highway tagging is a Functional classification. It so happens that the original highway classification in Great Britain was functional too.
We also have plenty of unpaved residential roads (and many are located in the SE: the 'By roads “not adopted”' of John Betjeman.
Unfortunately as Richard points out there is a tendency to reverse engineer wiki definitions from a subset of OSM data (i.e., usually prevailing practice with a few km of author's home patch).
|Poor man's rendering||about 1 year ago||
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.
The issue of marking areas of cemeteries happens to be well-known and is discussed and documented on the wiki: http://wiki.openstreetmap.org/wiki/Proposed_features/Section. I'm sure how well-developed it went from there, but I think we had a reasonable idea of what we wanted to do.
|Poor man's rendering||about 1 year ago||
For shops look at http://tiles.openstreetmap.fr this has many additional shop types rendered.
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.
|The Gun, The Blue Posts, and tonight the Monkey Puzzle||about 1 year ago||
Journalist was Kat Arney free-lancer for BBC, day job at Cancer Research as a Science Communicator. Also a harpist, and according to her twitter bio a keen knitter.
|exportation of roads||about 1 year ago||
You don't say which version of QGis you are using. However, it sounds very much like a known bug with the OSM plugin in versions 1.x.
This living does not handle 64-bit identifiers properly. Current versions of QGis (2.x) use a different method for accessing OSM data. Or you could get a shapefile from Geofabrik or bbbike websites.
For more on the problems with the QGis plying search the OSM help site.
|Artwork : only for tourists||over 1 year ago||
tourism=hotel is the one which bugs me. I spend around 10 years when most weekdays I was living in a hotel, but I sure as hell wasn't a tourist.
|Adding in missing roads from South Australian open data||over 1 year ago||
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.
|A Social OpenStreetMap.org Without Groups||over 1 year ago||
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.
|Mapping of industrial entities||over 1 year ago||
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.
Broadly speaking I think the problems are:
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.
|Fed up with abbreviations in tags||over 1 year ago||
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.
Personally I find traffic_sign one of the more opaque keys.
|Massachusetts Lake/Pond Cleanup||over 1 year ago||
It's good to see this cleared up, but it's a shame that the MASSGIS import has been preserved ahead of objects which were mapped by OSM contributors with some degree of local knowledge.
I added Scargo Pond back in 2009 long before any water body data were imported. Back then the Upper Cape looked weird because some landscape features had been imported and others hadn't.
When I look again at this area I am struck that although there is a lot of detail of buildings, conservation areas and so on, there are next to no POIs, or sign of anyone human mapping in the area.
|Land Use = Open Space Buffers||over 1 year ago||
I, and many others use landuse=grass for this purpose. Unfortunately this latter tag is also often (mis-)used for other types of grassland: for instance grass pasturage on farms (clearly landuse=farmland) and grass on sports fields (leisure=recreation_ground). (In many case this has obviously been used becaused it gets rendered : "tagging for the renderer").
The more general term which is widely used is the catch-all "amenity grassland" which covers most types of publically-owned grassland in cities (including sports fields, many public parks as well as the random bits of green space).
In either case tags with dual semantics are a real pain, but I would suggest sticking with landuse=grass, perhaps with some kind of adjectival tag landuse:grass=open_space_buffer, which would allow future disambiguation of the different semantics.
|Land Use versus Residential Private Property||over 1 year ago||
@CloCkWeRX I still don't get exactly why it needs to be in OSM: are you wanting to free cadastral data from commercial constraints,? 'cos it doesn't sound like it when you mention commercial datasets. The type of application you describe sounds mainly of interest to organisations which can afford non-free data.
Most of the applications that use landuse which I am interested in: contesting major planning changes, pollution in watersheds, environmental (habitats/biotopes etc) value of particular areas, and so on - are things which single individuals, small non-commercial groups, and charities are likely to want to do.
@AdamMartin it's nothing to do with database weight (if I understand what you mean by this), although lots of buildings from cadastral data in France are regarded by many mappers as 'bloat' (largely because houses w/o addresses arent very interesting), it's to do with the pain of processing lots of polygons. The nature of OSM is that one does have polygons in polygons.