On 16 April 2012 02:15, Serge Wroclawski <[email protected]> wrote:
- On Sun, Apr 15, 2012 at 8:57 PM, James Ewen <[email protected]> wrote:
- > My personal feeling is that if you're going to map landuse to the
- > physical edge of the road, then you should create the road as a
- > polygon to show the edge of the road sharing the edge of the landuse.
- Roads as polygons is really poorly supported in OSM, and by poorly
- supported, I mean that for the most part, they're not at all, and
- should be avoided.
- While you might be able to render them, the renderer already has
- support for rendering road size based on road type- using areas will
- mess that up. In addition, AFAIK, none of the routing engines in OSM
- support roads as areas, so using them would be a problem for both
- renderers and routers.
In my view, OSM's lack of support for roads (which are polygons, not lines) as polygons is a bug in dire need of fixing.
Technically, everything is a polygon, since a line cannot exist in the physical world. So, proper tools (including OSM) either add a width property to them or assume a width based on other criteria (like road class). This works fine for most purposes, and avoids the performance penalties of unnecessary detail.
Map roads as polygons, I say! And any of us finds that the tools don't facilitate that, then (s)he should stop tagging for the moment and turn her/his attention to improving the tools.
If we get this right, then eventually we'll be able to use OSM to look up the dimensions of roads, pavements, traffic islands, central reservations, etc, which has the potential to be very useful in support of open planning.
I disagree. Even professionals see no need for this. County road databases (all that I've seen) are all based on centerlines, with traffic classes, widths, etc. well-used for necessary traffic planning. The details of particular curb, lane, and island placements are all available in the various map books, which are often available online by links. This isn't because of lack of capability - all current tools have support for polygons - it's simply a matter of using the right feature for the job. There's no reason to overload one map layer with all that detail that is of no importance to the vast majority of consumers.
In the OSM world, I believe it's not presumptive to say that the vast majority of mappers are unwilling to go out there with a survey crew and measure the type of details your talking about, nor to (probably manually) import them from engineering drawings, nor to want to support the performance penalty caused by having to render all that detail, for no real benefit to them or anyone they can think of.
Alan Mintz <[email protected]>
_______________________________________________ newbies mailing list [email protected] http://lists.openstreetmap.org/listinfo/newbies
