SK53 has commented on the following diary entries
|How can I get accurate locations in a forest ?||7 months ago||
This is a great little project. Only stopped at Squamish for lunch & a beer so don't really know what the forest trails are like.
I think as others have said you are pushing the limits of what consumer-grade GPS might deliver. Here's a local open space where I regularly get 4 m accuracy on my etrex display (also used by the local geo-specialists to test their fancy pro-GPSes), you can see the variability of the tracks ((1) from OSM; (2) from Strava)
I think part of what you should be doing as the next steps are detailed micro-mapping of features along the trails. I don't know exactly what things will be useful, but anything which helps refine precise location and most importantly gets the relative topology of everything correct. In your situation I'd probably try to grab pictures along the trails: Mapillary provides a good way to review such image sequences.
|Kiln not seen(rendered) in OpenStreetMap||7 months ago||
You can make a request on github for the CartoCSS style, but I suspect that this is a fairly specialised rendering need. Given that CartoCSS doesn't render features like amenity=doctors it might only receive a low priority.
In the short term I would suggest making use of either umap or OverpassTurbo. I have built a simple Overpass query and added a naive style using the windmill icon (in lieu of a proper kiln icon). It is here. I hope this gives some ideas of what is possible with these tools
If you want some more help I can be reached by email SK53 dot osm at gmail dot com.
|Question on Features Related to Waterbodies||8 months ago||
My feeling is that not a great deal has been done in this area of late, but for sure there already exists a range of suitable tags, some of which are rendered on OpenSeaMap.
|Can I produce a Hypsometric tints in OpenStreetMap?||9 months ago||
OpenCycleMap has hypsometric tinting. I don't know how it's done on a large scale, but I suspect using one of the gdal tools. This blog post by MapBox contains more info.
|First Diary: Minor Fruit and Question||9 months ago||
For your agricultural terrace I think the most useful tag is barrier=retaining_wall in conjunction with landuse=farmland. It's really a matter of taste whether you map each terrace separately or not. Given the widespread use of terraces all over the world including these places I've recently mapped - Unterengadin, Northern Italy, Lesotho, Nepal, the Philippines - this question should be of wide interest.
There is also the possibility of subtagging (also called adjectival tagging) the farmland, but this has been done 6 times for farmland=terraced. The problem here is that this tag may be in use for describing the purpose of the farmland (e.g., plant nursery), as well as its physical form (e.g., paddy field, terraced): and if more extensively used may actually require more than one tag, for instance for terraced rice paddies.
|Impossible export||10 months ago||
Check on OSM Help: it is more or less standard not to be able to download an image from the main OSM website. It is very server intensive and these days with nearing 2 million signed-up contributors the main map servers just don't have the downtime from routine tasks to render these requests.
There are other options, many listed at OSM on Paper on the Wiki.
|Walking Papers||10 months ago||
Many folk use Field Papers these days: last print 10 minutes ago!
|The Missing Mappers Problem?||11 months ago||
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.
|New Starter||about 1 year ago||
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.
|Look who's using openstreetmap||about 1 year ago||
Shame they didn't attribute OSM though.
|Panoramic views aka "Street View" on OSM?||about 1 year 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||about 1 year 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||about 1 year 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||over 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||over 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||over 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"||over 1 year ago||
That or a vanity/cringe listen!
|Important unpaved roads exist, so wiki.openstreetmap.org/wiki/Highway needs a reboot||over 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||over 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||over 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.