+1 well said. On Mon, Apr 16, 2012 at 8:50 PM, Alan Mintz <[email protected]>wrote:
> At 2012-04-16 11:46, Sam Kuper wrote: > > 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 > >
_______________________________________________ newbies mailing list [email protected] http://lists.openstreetmap.org/listinfo/newbies
