[OSM-talk] Multi tag rendering (Was Rendering of Farmland not 'Light' enough?)
Greg Troxel
gdt at ir.bbn.com
Sun Jan 6 18:57:57 GMT 2013
Martin Koppenhoefer <dieterdreist at gmail.com> writes:
> 2013/1/6 Dave F. <davefox at madasafish.com>:
>> On 06/01/2013 16:24, Martin Koppenhoefer wrote:
>>> The problem is with the mapper mixing up linear and polygon features on
>>> the same osm object.
>>
>> I completely disagree with this. He mapped it accurately as a field with a
>> fence around it. The fact the renderer intentionally put in some code that's
>> unable to handle it is *not* the mappers fault.
>
>
> no, he mapped ambiguously and that's the reason why he gets into
> trouble. A field with a fence around it could for instance be mapped
> as fenced=yes on the field (one object in this case, using an
> attribute for the fence). If you want to map a field and a fence, use
> 2 objects, one for the field and one for the fence. This matters also
> when you add more tags, and where it would not be clear to which
> object they refer to, stupid example: start_date=1968 : is this the
> fence or the field?
A perhaps unreasonable view, stated overly strongly:
The real issue is that there isn't a formal data model that defines
semantics from a collection of objects. Neglecting the issue about
breaks in fences (which is really a separate nit), a closed way with
an area tag and a line barrier tag can be deemed to mean both.
There's a similar issue with a point that has foo=bar and baz=bam
tags, where normally a point only has one.
So one approach is that renderers (including mkgmap) have to essentially
process tags, remove them, and try again. The other is to prohibit
multiple semantics on an object, and make people use relations. Both
are arguably reasonable choices; the project should define one of them
as the standard approach. Then, one can say whether the tagging or the
renders/transformers are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20130106/4bc51bd7/attachment-0001.pgp>
More information about the talk
mailing list