Martin Koppenhoefer <dieterdre...@gmail.com> writes: > 2013/1/6 Dave F. <dave...@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.
pgpsKp63TFvDu.pgp
Description: PGP signature
_______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
