I’m currently mapping a camping place using site survey, the Dutch national height map (AHN3), and the (much) older Mapbox Satellite imagery. I am using the proposed camp_site=pitch tags for each individual pitch and ref for their identification. Considering that the cartography will not be updated in this direction yet I’ll host my own, including an interactive application for assignment and planning.
I am looking for support on the following issue: considering that I have highway=service, highway=track I would like to have my pitches be reached by a journey planner. Given that landuse=grass is set on a multipolygon below the reachability isn’t inferred by edges touching. As example I have drawn tracks to the individual places on the south side of the image.
I could draw straigth lines to the red selected pitch above, but considering these tracks will be rendered as brown lines, that really doesn’t do justice to the situation. Obviously I could use a highway key with a user defined tag such as grass. This will hide the tags in the current openstreetmap cartography rendering. An alternative is to create an additional landuse grass surface (as area) that is touching the entrance points, but maybe there is a better solution. I am open for suggestions.
Please do not map tracks that don’t physically exist on the ground just to make life easier for a router. That would be a case of mapping for the renderer.
Even though it might not be recognized by any journey planner, the most I would consider doing is adding appropriate vehicle and foot access tags with a value of destination, or private.
The answer above is the “you should not” while I am searching for means to support topology. The field of grass could be tagged with highway=service, surface=grass, area=yes because the field is there to facilitate people and vehicles to get there. Similar to a landing strip of a small airport. My guess is that the rendering of that combination will look nowhere near landuse=grass, could file a bug for that.
Given that routers only consider highway keys I wonder about alternatives to mapping tracks with user defined values.
http://wiki.openstreetmap.org/wiki/Key:area (specifically the Note: Most pedestrian routing algorithms do not currently route correctly across area features, tending to route around the edge.)
You should map it as an area and wait until routers catch up. If people continue to mis-map for routers, there is no incentive for the router developers to do the job properly.
There isn’t just one rendering, and you should not map based on how it will be rendered.
Mapping as an area is not going to be negotiable here. The only issue is whether it is better to describe it as a field with vehicle access or a vehicle yard with a grass surface.
If, in time, ruts appear, where vehicles are always following the same route, you can change the mapping to reflect those as tracks.
To be honest, I don’t think I would map the vehicle aspects at all, except maybe to have barrier=entrance on each pitch entrance.
Firstly this is field not a service road. So using highway tags is inappropriate, and certainly tagging for the router. At best these are artificial routing paths inferred by location of camping plots.
Secondly, the area clearly allows motor_vehicle=customers or motor_vehicle destination: so these are valid tags to place on the camping ground. However, it seems reasonable to assume that these are de facto given’s for caravan & camp sites.
My third approach would be to add them but with non-highway tags which could be transformed by data consumers to match highway tags. These implicit routes are partially analogous to off-piste ski routes or tidal routes. They have reasonably defined bounds to those in the know, but no permanent on-the-ground evidence. Another analogy would be ‘artificial_paths’ for rivers passing through lakes which I think have been mapped (probably as waterway=river, artificial_path=yes which suffers because one still sees a river whereas the way is really there to support the connectivity of the river system).
In conclusion I’d go for something like route=highway_access, highway_access=service, surface=grass, access=customers; which then can be transformed with LUA or mkgmap to a given highway tag.
(Personally I wouldn’t map these at all, but am interested in the equivalent waterway, hiking & skiiing route problems. I also believe that over time we should make tagging more explicit rather than relying on implicit assumptions).
