[OSM-newbies] How to draw land-use areas
sam.kuper at uclmail.net
Tue Apr 17 03:50:25 BST 2012
On 17 April 2012 02:50, Alan Mintz <Alan_Mintz+OSM at earthlink.net> wrote:
> At 2012-04-16 11:46, Sam Kuper wrote:
> On 16 April 2012 02:15, Serge Wroclawski <emacsen at gmail.com> wrote:
> On Sun, Apr 15, 2012 at 8:57 PM, James Ewen <ve6srv at gmail.com> 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.
Boundaries are lines.
> 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
I don't think it works fine at all. Lots of sections of road aren't
symmetrical, for a start. Centreline plus width strikes me as misleading in
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.
Professionals at which aspects of which professions?
> 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
I'd be genuinely interested to see examples showing how to correlate the
data from such country road databases and map books. Please could you
> 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.
Are you proposing that OSM should use one layer for roads as lines, and
another layer for roads as polygons?
> 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,
Not yet. Give it time.
> for no real benefit to them or anyone they can think of.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the newbies