[OSM-talk] Tagging hierarchies

[Karl Newman]

On Jan 13, 2008 5:01 PM, Robin Paulson <robin.paulson at gmail.com> wrote:

> On 14/01/2008, Karl Newman <siliconfiend at gmail.com> wrote:
> >  Let's not confuse rendering issues with data issues. The point was that
> the
> > single high-level water tag could be used to designate water. Adding
> > area=yes will indicate that it is an area (lake, etc.), not just a line.
>
> thanks Karl, i'd lost track of where this was going
>
> the point i was making is that we don't need to say area=yes for
> lakes. if it's a lake, always draw it as an area.
> any object drawn as a way and tagged 'lake' can easily be ignored by
> the renderer, as this is not valid, and frankly IMO it's confusing. in
> what circumstances could this be useful?
>
> no need for the area tag at all
>

But that gets back to the specialized tagging (renderers/data consumers
having to know about lakes, reservoirs, etc.). If it were just
natural=water, area=yes, (or whatever the proposed tag was), then it could
be dealt with appropriately regardless of the waterway type.

For that matter, I wish all closed ways which designate an area were marked
as such. I'm working on writing a tiling task for Osmosis which will carve
up data into rectangular grids (for feeding into GPS map creators such as
mkgmap). It has to treat closed ways differently than linear features (hard
clip them with synthetic nodes right at the boundaries and link the clipped
parts together). Without a universal tag such as area=yes designating a way
as a polygon (simply having a closed way is not sufficient--witness
roundabouts), the tiling task will have to know about every type of tag
which implicitly designates a polygon. Then when a new implicit polygon tag
is added, the task won't correctly treat it as a polygon until it's told
about it. We really could use a generic method for designating polygons.

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20080113/cc0ad5f9/attachment.html>