SK53 has commented on the following diary entries
|OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike||11 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||11 months 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||12 months 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||12 months 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.
|Land Use versus Residential Private Property||over 1 year ago||
Broadly speaking don't use landuse for zoning areas.
Use the landuse tags for what is on the ground (which of course ought to correspond with local zoning). Many local administrations will do zoning on a long-term timescale of perhaps several decades. It is no use to anyone to mark areas earmarked for new sections as residential if they are still farmland.
Secondly, dealing with many hundreds of landuse polygons will make landuse data from OSM more or less unusable. Because there is no enforcement that given types of polygons must not overlap, a lot of post-processing is needed on OSM data already. Increasing the number of objects (by perhaps a hundred- to a thousand-fold if you map individual house plots as residential and individual shops as retail. Additionally complex algorithms are then needed to define landuse beyond property boundaries.
I've yet to see a convincing use-case for mapping property boundary details in OSM: enough people have done it to show it's possible, but I'm not aware of anyone with a need to get this data from OSM. Incidentally the vast bulk of use-cases for landuse (including cartographic products) require reasonably generalised polygons.
|Think bout boundary of INDIA||over 1 year ago||
I suspect that you think that the boundary of India should include all of the pre-partition States of Jammu and Kashmir. However it is policy for OpenStreetMap to map what is on the ground. This effectively means that we try and map the Line of Control accurately, rather than areas claimed, but not controlled by India or Pakistan (and indeed China).
The reasons for this are straightforward, OSM is used in countries on both sides of border disputes and therefore it is impossible to adhere to both views of where notional borders might be. Furthermore OSM, unlike, say the maps of the Survey of India, does not serve political purposes. OSM is not a platform for fantasy maps, whether those created by individuals or mandated by legislation by governments.
I realise this may create problems for people in India where it may be an offence to represent the boundaries of India other than according to the states wishes, rather than any accordance with reality. For that purpose I would suggest using an external source for the boundary of India: moving the boundary away from the LoC will be treated as vandalism.
If on the other hand the boundary needs minor tweaks (which I'm sure it does) and you can map them based on personal observation or sources which are open, usable in OSM, and readily available for others to check that such mapping is accurate then do go ahead.
I have also answered this on [OSM Help](https://help.openstreetmap.org/questions/23042/how-could-we-edit-the-boundary-of-india-and-pakistan_.