This is an elaboration of my posting to talk on 2009.11.26.
There is a construction that might "bridge the gap" between areas and graphs. In lack of a better word, I will call it a "multiplex" for now(I am sure there's a better word.)
Imagine an area like seen in the figure below. It represents an area that could be an intersection. On the edges of this polygon some "hot-spots" have been defined. They are marked with red, blue and green, respectively. The colors have no significance other that explanatory. The shape of the polygon and the position of "hot-spots" on the edges is arbitrary and can be defined by the user.
This would give you an object which would render nicely as an intersection, and there's of course the option of tagging a bunch of auxilliary information such number of traffic_lights, directional signs etc.
The nice thing about the multiplex is that lines (ways) can connect to the "hot-spots" from the outside, and the multiplex itself contains information about how the hotspots are connected internally. In the figure below is an example of a very complicated intersection that deals with roads with two tracks (red), bicycle ways (blue) and footways (green). The black dots inside the multiplex are internal nodes, providing connectivity for the internal connections. These are not accessible from "outside" the multiplex object.
The last image is an example of how the intersection multiplex might be connected to other roads. While drawing this image it occured to me that you don't need to use all the hotspots on the multiplex, so that idea is illustrated in the picture.
In the east-west direction, a two-lane road goes straight through the intersection, along with its and pedestrian and bicycle tracks (but it could be anything). To the north, the connecting road only has pedestrian tracks, nothing for bicycles. To the south, the intersection connects (the big black dot is an ordinary OSM node) to a road tagged e.g.
It is obvious at this point that such a multiplex could be used and reused, since the connectivity inside is quite general. One could imagine a set of templates dealing with many common situations, so all you'd have to do would be to connect adjoining roads to the template that fits a given situation.
One last remaining problem is the rendering. In this example, the intersection is straight north-south-east-west, but what if the intersection is oriented differently? I have no solution to this at the moment, but perhaps it would be worth separating the appearance of the object with the connectivity, so that the multiplex template merely deals with that and is "subclassed" adding a visual layout.
- All major and minor roads have been mapped and tagged
- Many tracks are still missing, esp. in the south of the island.
- Many locations added.
- Coastline now single polygon, some artifactual jaggies smoothed
- All JOSM errors fixed
General guidelines for drawing parallel ways
Cycleways in Denmark
Mapping the intersection Ny Munkegade/Langelandsgade
Tagging cycleways in Denmark
|header 1||header 2||header 3|
|row 1, cell 1||row 1, cell 2|
|row 2, cell 1||row 2, cell 2|
|row 3, cell 1||row 3, cell 2|