- fixme=stub for end-of-incomplete-way nodes -- complete=no instead?
- highway=steps (for nodes)
- width=narrow together with highway=footway for narrow and indistinct and probably "inofficial" paths (Trampelpfad in German)
- hunting=raised_hide for hides (Hochsitz in German)
- forest=ride for what I think are rides -- straight "ways" without trees but without a path; this can often be made out on the aerial photography but aren't actually ways.
- forest=section for a forest that is subdivided into sections
- section_marker=* for tracking the stones that mark the corners of forest=section's.
Random ideas and questions
This is a collection of unfinished ideas and unasked questions to be worked out and possibly submitted where appropriate some time in the future. Just so I don't forget.
default tag values based on location
CSS-like mechanism for specifying default tags, where the "child"-relation is replaced by being within an area.
- all highways in Germany within any town get a default maxspeed=50 tag.
- all highways in Germany outside any town that are not motorway/trunk roads get a maxspeed=100 tag.
- all highway=track's in Germany get a default motorcar=no tag.
- all highway=track's in some desert state get a default motorcar=yes tag.
This would allow explicitly entering reasonable regional default values into the database.
I have no idea whether this is implementable.
zoning and overlapping ways
JOSM warns if two ways overlap. On the other hand, when entering zoning information, it seems to be reasonable to reuse nodes. That is, a block of residential housing that borders on a park results in overlapping outlines for these areas. What's the right way to do this?
separate layers for areas and ways
Editing in JOSM would become easier if areas and non-area ways were in some sense in different layers. I usually don't want a highway to actually intersect the border of some forest.
How to tag a paved road that's restricted to farming vehicles and bicycles and pedestrians? I like highway=track surface=paved, which to me implies the above access restrictions (in Germany, at least). But does highway=track in general imply surface=unpaved?
- http://wiki.openstreetmap.org/wiki/Map_Features#Tracktype suggests the use of tracktype=grade1 for paved tracks. Bmwiedemann 06:22, 23 December 2008 (UTC)
The current highway values seem to be somewhat UK-specific (trunk, unclassified in particular). I've seen highway=minor which seems like a more universal tag. Should different countries have their own set of tags? Can we find a universal class of tags that fits anywhere more or less?
How should an acute angle between two roads be entered properly?
Currently, I'm tagging forest ways as highway=track when it's wide enough for cars, and highway=footway for narrow paths. But how to distinguish a "Holzweg" without proper surface but wide enough for forest vehicles? These should not look the same as a real track on the map.
things I don't know how to tag
- Turnhalle (gym?)
- types of schools (amenity=school type=elementary/Hauptschule/Realschule?)
It should be possible to tag anything that occurs frequently with just one tag (+ possibly things like name, ref). I'd really like to avoid tagging maxspeed=30 for such residential roads... To some extent, tools can make it possible to work with large numbers of tags, but having built-in defaults seems more reasonable.
For perfectly parallel dual carriageways, why are we mapping two ways, instead of tagging a middleway as dual_carriageway=yes?
(This is related to the previous point.)
It should be possible to get a simplified map out of the OSM database, that contains single ways for motorways and single nodes for intersections. I believe the current data doesn't allow this. Would a combined-ways (dual-carriageway) relation allow computing nodes for a single way? If we make sure that nodes are in parallel and we take the midpoints? Or should there be a separate average way? All elements belonging to a junction as a relation?
created_by and user agent
I'm unclear on how created_by=* is defined -- creator or last editor? Anyhow, I would like to see this deprecated and the API to store the user agent header of the last edit together with user and timestamp data.