However, much it makes your work easier deleting others objects to do so is not the best way to go about it: particularly if a user has spent a lot of time and effort as in this case.
You may feel that farms do not need to be explicitly mapped, but others are interested in such things and the information which can be derived from them. I think it's important to respect others mapping peccadilloes unless they cannot be verified on the ground.
Personally I think farms should not be mapped field by field: the barrier=* tags are much more useful to achieve this type of result: and are much more informative, whether for walkers, conservationists, or just general cartography.
A default value for farmland is not really very sensible. Are grouse moors or upland sheep pasturage really farmland? This also includes large areas dedicated to the military, nature conservation, wetlands etc. All of which we map in different ways in OSM (and this does include the South East see the Surrey heaths).
You could have probably plonked your woods down without worrying about the farmland polys: I'm pretty sure that mapnik renders farmland at the bottom of the 'painter's algorithm' stack. This is certainly the approach I took with extracting landuse data from OSM (see http://sk53-osm.blogspot.co.uk/2011/01/ … g-osm.html for example). Of course it is better to do it properly, but when time constrained adding new data can be done without deleting existing stuff.
Yes, this is an issue, but not, I think, a serious one.
The way I have approached this is to think of the primary categories as a hierarchy, something like retail -> commercial -> industrial -> residential. These days there is little overlap of industrial/residential, but in town and city centres if the predominant ground floor usage is retail I'll tag the landuse as retail, if office buildings at ground floor level, then commercial and so forth.
Thus an area like that around Langstrasse in Zurich, where there are shops (and dodgy nightclubs) on the ground floor and in basements, offices in higher levels of buildings and apartments in the attics, would be tagged retail. This makes sense if you think about what you observe in terms of movement and types of people in the area (footfall). You will also see this reflected in rental values for the ground floor sites, local authority zoning regulations etc.
In South-east Asia where the shop-house is a long-standing feature of even small towns it might be reasonable to use a different tag.
Once you have applied the main landuse tag there is plenty of scope for adding additional tags, such as residential=*. For instance I have used residential=student_village to distinguish residential landuse for gated sets of flats which can only be rented to students. Once could also imagine adding tags for secondary landuse (e.g., landuse=retail, secondary_landuse=residential), although I am unaware of such usage.
The key to these things is to ask what you want to use it for. We have established that OSM landuse has a good correspondence (both qualitatively and quantitatively, see http://firstname.lastname@example.org) with other landuse/landcover schemes such as CORINE and Urban Atlas of the European Environment Agency. Example applications of landuse/landcover include: hydrological models (using assumptions about runoff and surface sealing), ecological information (my own interest), resource utilisation, traffic demand models, etc. Within OSM we may well use landuse to determine if areas have been adequately mapped: landuse=retail with no shop=* nodes or ways points to missing data and so forth.
Lastly, the abutters=* tag is more or less in abeyance. It is a useful tag if you only pass through an area and cannot survey landuse. With the widespread availability of aerial images this is rarely a problem now.
Wikimedia geolocated information may well be derived from sources incompatible with OpenStreetMap, please don't use it!
For anywhere in Great Britain there are numerous usable sources (i.e., with a license known to be compatible with OSM) which are far more reliable and detailed: these included Out-of-copyright Ordnance Survey maps (NPE & Provisional edition 25k), Ordnance Survey OpenData (e.g., StreetView, Locator, Meridian etc)., NAPTAN (bus stops and location gazetteer).
For Norfolk all Civil Parishes have already been mapped from Ordnance Survey Boundary Line data. The parish you link to is mapped already (http://www.openstreetmap.org/browse/relation/1022500). Many civil parishes in the British Isles do not correspond to villages (for instance Meering - http://en.wikipedia.org/wiki/Meering - in Nottinghamshire has consistently had a population of 0 or 1 for most of its existence), or correspond to villages which disappeared hundreds of years ago.
You can use place=locality or place=hamlet for smaller named places within the parish which are not of village size.
There have been several research projects comparing road lengths in gridded squares from OSM and other sources. The most recent of these is for Florida: http://www.gim-international.com/issues … _Data.html.
Far and away the best tool for doing fancy things with buildings are those in JOSM. Have a look at this page on the wiki http://wiki.openstreetmap.org/wiki/JOSM … dingsTools.
Shift-J in JOSM is very useful too as it can merge rectangular shapes to create more complicated ones.
Also the terracer plugin is neat.
Wow rather too much information.
The bounding box you are querying and the scale you are using will never deliver good query performance. Neither the planet_osm tables nor the mapnik stylesheet are designed for rendering a large area including Belgium, London, the outskirts of Paris, and most of the Netherlands at this scale. Your bounding box approximates to this tile http://b.tile.openstreetmap.org/6/32/21.png. As you can see Mapnik on the main site renders very few features for this bounding box (largely roads from the planet_osm_roads table).
You queries include some detail information (e.g., picnic sites).
The main mapnik stylesheet is probably best regarded as optimised for mid-scale and large-scale maps.
SO, briefly, if this is what you want to do, you'll have to live with the performance.
The osm2pgsql tables are designed to be queried using bounding boxes, which is why they are indexed on the primary key and the geometry columns: I see no bounding boxes on your sample query plans.
In the absence of bounding boxes I would expect to see table scans. Adding indexes on the tag-based columns can certainly help performance, but penalises update times. In Postgres you can add indexes with conditions as well, which may well improve index selectivity for
Please provide more context: are these mapnik queries (they look like it to me), are these the complete queries, what data do you have loaded (country, rowcounts from planet_osm tables), what is the area that you are querying. Have you vacuumed all the tables? What platform & resources do you have available?
What I don't like in Zinal are nodes with just building=yes and name=*. What is this?!?
My guess, and I emphasize that it is a guess, is that they are apartments. I did not map the area so I do not really know.
Looking at some old photos of the area, I'd agree.
building=yes on a node is perfectly valid tagging: it adds information which is not otherwise available. There is no aerial coverage of the area so drawing building outlines was probably not feasible, and I fancy housenumbers in these villages are probably allocated numerically in the order in which buildings are built throughout the commune, so I'm not sure that addresses can be added conveniently.
Of course a survey could enable this data to be enhanced: but, its certainly something some can build on.
Houses not yet on an OSGB map are unlikely to be copyright by them (but one can never be sure :-)).
Make sure the developer understands the implications of the OSM licenses CC-BY-SA & ODbL, and that you get the relevant permission. I don't see problems with this: there's a win for the developer in that the properties are on the map, and many of the materials are openly available as site marketing material and so on. You both need to be aware of what might have been based on OSGB stuff.
If you have a really good relationship with the developer you might ask for the house outlines in a vector format (ESRI Shapefiles are far & away the easiest to deal with). It's a lot easier to re-project a shapefile & convert it into an OSM file suitable for importing than rectifying images.
There are also programs available which pull shapes out of PDF files (used with the French Land Registry data), but I dont pretend to know how they work or how you deal with projections with them.
As for getting a lock, even with my dedicated GPS devices I tend to leave them out in the open for 10 minutes before mapping: I get better results. Many gadgets are also sensitive to how they are held & orientation.
Using scanned images is possible, but pretty technical, and certainly needs some understanding of map projections. However, usually the bigger obstacle is that the map's copyright will be owned by someone, and it's important to get their permission before using it as a source (this is why using Google aerial photos is a no-no). Unfortunately in Britain it is highly likely that the developer's map has significant elements of the detailed Ordnance Survey products, and that it was created using the OS GPS ground stations.
The route to working with scanned images is: a) georectify the image (tools such as GDAL, QGIS can do this); and b) get it accessible through a WMS or TMS server (there is a service called WHOOTS which does this for web accessible images). Normally this route is mainly used in OSM with public domain US military maps for humanitarian and crisis mapping. It has a steep learning curve. Editing then has to be done with one of the off-line editors (JOSM or Merkaator) as the on-line potlatch editor does not support WMS/TMS backgrounds.
Depending on the size of the area of the development, and whether you walk or cycle, it should take no more than a couple of hours to get decent GPS traces. Many people have just done things like vary the route to the paper shop, or where they walk the dog, and have thus collected the data incidentally. Personally I'd reckon this to be quite a bit quicker than trying to get permission & then re-jigging the map as a background.
If there are no other maps of the development then mapping it in OSM provides a great service for everyone in the area. An estate on the N. side of Cambridge was mapped some years ago and OSM was the only viable map for removal vans, taxi drivers, pizza delivery folk, and of course visiting friends and family. I know of similar stories in Ireland.
Some Bristol OSM contributors met-up recently: they ma be able to help. Check the OSM wiki Bristol page.
When you split two ways in either Potlatch ('x' or cut tool) or JOSM ('p) the two child ways remain joined at the node where they were cut. In Potlatch this will be clear by the outer square box round the node.
To remove the join (i.e., create two nodes instead of one) you can use Shift-J in Potlatch or "g" in JOSM. "j" works in both tools to re-glue the nodes together.
You may find it a lot easier to grab a GB, England or London download from geofabrik & use osmosis to filter the data.
OCM is built on Postgres & Mapnik, the garmin versions with mkgmap: so it has all data available and appearance is in down to the rules rather than some selected sub-set of the data.
The archetype is Blackadder's work in Sutton Coldfield (postcode district B72): http://osm.org/go/euzPdIkQ and http://blog.mappa-mercia.org/2011/02/wh … tcode.html. Chris Hill has also posted on what's involved http://chris-osm.blogspot.com/2011/03/hu14.html.
I've had a go and it hugely adds to the effort for an existing survey. If you want something to do in your lunch break or need 20 minutes away from the computer then its fine: I think this is what Andy (Blackadder) did. It's not enough to draw stuff in from aerial imagery, it needs to be surveyed too: is it a fence, wall, hedge; is it still there.
A quicker approach is to trace 'property boundaries', i.e., based on fences and other information. There has recently been a lot of discussion about the best way to tag these on talk-tagging, much of it summarised on the wiki (http://wiki.openstreetmap.org/wiki/Talk … e%3Dgarden).
Cadastral boundaries per se don't seem to me to suitable for OSM: they are not amenable to ground verification, and its not clear what value they have in OSM anyway. Cadastral maps also have inaccuracies: I once bought a house where the Land Registry had everyone on the street owning only half of the land for their own garage, but also owning half of the land for their neighbours garage. I don't know how many transactions had completed with this error, before our own, but we had an unusually thorough and competent lawyer.
At the very least you are not picking up route relations with route=bicycle. The NCN 4 and the local cycle route along Cornwall Road are examples of these http://www.openstreetmap.org/browse/relation/2696.
BTW its a lot more useful to see the predicate that you send to jxapi than having a link to it. I have no desire to download the data.
Wow what a lot of questions: most of which look like the really justify in-depth answers. Quickly, my 2 cents.
At the moment I think OSM is pretty much the only game in town for the source of much of the regular map data which you want. That doesn't mean it can do everything, but most other sources will either be encumbered by copyright, legal, technical, or financial restrictions. There is already a technical eco-system for mapping for the blind and wheelchair users. Probably the email list devoted to the Loro-Dux project (http://wiki.openstreetmap.org/wiki/LoroDux) might be a better place to get detailed answers.
It's impossible to cover the range of things done by OSM or its possibilities in a message. The best way to find out these things might be to attend the State of the Map conference in Denver this September: http://wiki.openstreetmap.org/wiki/Stat … e_Map_2011. Last year there was a significant presence from people interested in similar problems.
You will almost certainly need your own format for data on the device: the main OSM XML format is designed for moving data from place to place. Most applications have separate internal formats.
A lot of data should probably be held externally to the map data (sounds, buildings etc): a problem arises of ensuring that the linkage between the map data and external files remains persistent. OSM does not provide a mechanism to do this at present, although I believe there is a ground swell of interest in working out how this might be done.
The OpenSource flight simulator groups (X-Plane and FlightGear) are either using or planning to use OSM data in 3-D apps: there may be some common technical ground.
In the Val d'Annivers most people around will not be locals. The local families I know tend to have rather good local knowledge: some are reputed to be lineal descendants of refugees from Attila the Hun's army defeated at Chalons. IIRC their knowledge tends to be of the form "I dont know why they built at place X, it avalanches every 200 years".
Most of the villages consist of tourist accommodation or second homes. I would therefore try and map any hotels, restaurants & bars. Cafes are useful for a wet day, or for coffee and cake at the end of a long one. Group accommodation is often plentiful in Swiss alpine villages and worth mapping. The sheer number of rent-able apartments means that mapping this is roughly the same as doing all the addresses. The tourist office will be an important source of information, and for finding holiday apartments.
I think all bus stops are now in, but I'm not sure how extensively the post bus network is mapped: this is a hugely useful resource for hikers.
Sporting facilities, ostensibly built for tourists, are often very heavily used by locals at all times of year. I remember wandering around Chateaux D'Oex one November looking for somewhere to eat, but it was very quite. I walked back to the station and passed the ice rink which was crammed with locals of all ages and had a very good Menu de Jour.
Pharmacies, doctors. Newsagent (will usually sell maps and a few books of local interest, I always case these places out). The town hall (may be the police point too), and schools are obviously of interest to locals. Petrol station if one exists. But most of all, a lot of the permanent residents will make their living from tourism: mapping their businesses helps them too.
Many villages will use a version of the cadastral map for showing where holiday accommodation is located: for me this represents a target level of detail to aim for.
Have a good trip.
Its easier to find the problem if you post a permalink (bottom right corner of OSM screen) to the location. If you change the lat & lon parameters to mlat & mlon it will stick a marker on the OSM map.
I'm sure that there are plenty of routing errors in the US: although most interstates should have been reviewed by now. MA is a special case because the MassGIS data was imported by town/city rather than county as for everywhere else in the States. This means that there are more potential cases for duplicate nodes (two nodes in the same place, which may need to be joined).
The server which renders the tiles has had an upgrade and is currently re-importing the planet, so it is unable to do tile rendering at the moment.
Of course this is a bit annoying: the upgrade should improve the speed with which tiles get rendered so we'll benefit soon.
In the meantime you can try and get Osmarender to render your data or look at MapQuest (and probably some other sites) which use different rendering servers. Or you can render stuff locally using Mapertitive.
In the old days of a 2009 OSM was like this all the time, so I taught myself how to do local rendering so as to avoid having to wait a week to see my mistakes!
I doubt if that helps at all. Keep to the convention that zoom level 0 is the whole earth: 17 & 18 are the most detailed ones rendered by mapnik.
Each higher zoom level requires 4 tiles for each tile in the level above. Therefore all the tiles for zoom levels 1 to n-1 will consume much less space than level n. See http://wiki.openstreetmap.org/wiki/Tile_Disk_Usage
Most implementations render tiles on demand for higher zoom levels: not just for disk space reasons, but also because of database performance.
From your description this sounds much more like an OpenLayers question than a strict OSM query. I suggest that you look at the OpenLayers example page http://openlayers.org/dev/examples/. There are several marker related examples, such as this one: http://openlayers.org/dev/examples/markers.html.
There are quite a apps using OpenLayers with a marker layer and OSM: http://www.livingwithdragons.com/elephants is just one I can think of immediately.
The one thing I would not do is use highway=unpaved. This tag has fallen out of use because a) the surface tag does the unpaved bit and b) you miss whether its a residential/unclassified/whatever type of road. Most apps using OSM data will not route on surface=unpaved either.
There is highway=road for roads where (for various reasons) the mapper is not confident of status: effectively this is a request for someone to check this road out.
Seriously, ask on talk-es. There are plenty of folk who are happy to answer in english.