On 28/06/2019 00:56, Warin wrote:
that are also holes in them (they usually omit making the hole, so an
added car parking area will be covered by trees until I notice
I believe that is a renderer bug. Generally smaller, fully nested,
areas should cut out holes in incompatible backgrounds
On 27/06/19 22:11, Martin Wynne wrote:
seen this done in various places, but I've never understood the point
it. The two representations are identical in terms of the data, but
the latter requires 2.5 times as many objects and is much more of a
pain to work with in the editors.
This happens
28 Jun 2019, 02:29 by for...@david-woolley.me.uk:
> On 28/06/2019 00:56, Warin wrote:
>
>> that are also holes in them (they usually omit making the hole, so an added
>> car parking area will be covered by trees until I notice
>>
>
> I believe that is a renderer bug. Generally smaller, fully
On Wed, 26 Jun 2019 at 21:08, Brian Prangle wrote:
> The whole area needs simplification to replace multiple overlaid ways with
> multipolygon relations.
I'm curious about what you mean here. Are you referring to replacing
(in a simple example) two square closed ways that share a common edge,
On 27/06/2019 10:49, Robert Whittaker (OSM lists) wrote:
The two representations are identical in terms of the data, but
the latter requires 2.5 times as many objects and is much more of a
pain to work with in the editors. All to avoid having a common line
segment between two areas
I'd
seen this done in various places, but I've never understood the point
it. The two representations are identical in terms of the data, but
the latter requires 2.5 times as many objects and is much more of a
pain to work with in the editors.
This happens a lot in my area. Huge areas of
6 matches
Mail list logo
