Re: [OSM-talk] Multi tag rendering (Was Rendering of Farmland not 'Light' enough?)
On 06/01/2013 15:01, Lennard wrote: On 6-1-2013 15:51, Dave F. wrote: On a related topic; if a field has a barrier tag it changes colour rendering at zoom 16: That's because having a landuse on it as well pushes it into the polygon table. It's subsequently rendered as a barrier area, ie. with the barrier=hedge fill. So a similar mess to mkgmap/garmin maps where it assumes there can be only one primary tag. Never been able to understand why this quite simple problem can't be sorted. Cheers Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multi tag rendering (Was Rendering of Farmland not 'Light' enough?)
2013/1/6 Dave F. dave...@madasafish.com: On 06/01/2013 15:01, Lennard wrote: On 6-1-2013 15:51, Dave F. wrote: On a related topic; if a field has a barrier tag it changes colour rendering at zoom 16: That's because having a landuse on it as well pushes it into the polygon table. It's subsequently rendered as a barrier area, ie. with the barrier=hedge fill. So a similar mess to mkgmap/garmin maps where it assumes there can be only one primary tag. Never been able to understand why this quite simple problem can't be sorted. The problem is with the mapper mixing up linear and polygon features on the same osm object. You could tag a way with barrier=hedge and then add this way as outer way to a multipolygon relation tagged with landuse=farmland. (Strange btw., because how would you then access the field? Usually the hedge would have to be interrupted anyway, so the multipolygon approach could also be used to add more detail and have a part of the outline free from the barrier tag). An alternative is to expect that whoever makes a map out of the data will duplicate the geometry and use one way as linear feature and the other as area, but how would you know looking at a closed way if this hedge is linear or mapped as polygon? These issues will probably be solved automatically with a new area type for osm objects. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multi tag rendering (Was Rendering of Farmland not 'Light' enough?)
On Sun, 2013-01-06 at 17:24 +0100, Martin Koppenhoefer wrote: The problem is with the mapper mixing up linear and polygon features on the same osm object. You could tag a way with barrier=hedge and then add this way as outer way to a multipolygon relation tagged with landuse=farmland. (Strange btw., because how would you then access the field? Would you not use gate and/or stile tags? Phil (trigpoint) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multi tag rendering (Was Rendering of Farmland not 'Light' enough?)
2013/1/6 Philip Barnes p...@trigpoint.me.uk: On Sun, 2013-01-06 at 17:24 +0100, Martin Koppenhoefer wrote: The problem is with the mapper mixing up linear and polygon features on the same osm object. You could tag a way with barrier=hedge and then add this way as outer way to a multipolygon relation tagged with landuse=farmland. (Strange btw., because how would you then access the field? Would you not use gate and/or stile tags? Yes, you can do this, but the problem of mixing up linear and polygon features has nothing to do with it. Cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multi tag rendering (Was Rendering of Farmland not 'Light' enough?)
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. You could tag a way with barrier=hedge and then add this way as outer way to a multipolygon relation tagged with landuse=farmland. But it's not a multi-polygon. Don't tag/map inaccurately for the renderer. (Strange btw., because how would you then access the field? Usually the hedge would have to be interrupted anyway Err... a POI barrier? , so the multipolygon approach could also be used to add more detail and have a part of the outline free from the barrier tag). An alternative is to expect that whoever makes a map out of the data will duplicate the geometry and use one way as linear feature and the other as area, but how would you know looking at a closed way if this hedge is linear or mapped as polygon? I'm only a hobbiest programmer but why can't an IfThenElse statement with a DoWhile loop solve the problem? I'm not sure how Mapnik works, but assuming it's the same principle as mkgmap (it has the same problem), the renderer shouldn't jump to another file table just because it finds one renderable object. It should also know that barriers are either linear of POI as it's on the perimeter of a polygon it's easy to distinguish. These issues will probably be solved automatically with a new area type for osm objects. cheers, Martin I think it's a 'new' way of rendering that will be the solution. Regards Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multi tag rendering (Was Rendering of Farmland not 'Light' enough?)
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? cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multi tag rendering (Was Rendering of Farmland not 'Light' enough?)
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
