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 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
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
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
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,
I've changed this back to 3 reserves based on the unanimous opinion against
Martin's proposal. The whole area needs simplification to replace multiple
overlaid ways with multipolygon relations . I do have some knowledge of the
area having done 2 walking surveys there. There is also an SSSI for
On 09/06/19 23:58, Martin Wynne wrote:
we now have 2 natural=heaths named as nature reserves and with
operator tags but
without nature reserve tags.
Hi Adam,
But they are now nested within a larger area which does have a nature
reserve tag. Much of the publicity material for this area
7 Jun 2019, 20:11 by mar...@templot.com:
> It's possible to see the property boundaries on old maps, but after visiting
> the site again yesterday I can find little remaining physical evidence of the
> boundaries, with many footpaths crossing between them.
>
> The web sites refer to them
Hi Martin,
I echo Gareth, Mateusz and Warin's view that this should have stayed mapped
as separate nature reserves. The previous areas would have (hopefully)
marked the legal boundary of the individual nature reserves - something
which we have now lost. I see for example that the area you have
Thanks for the comments.
There are in fact 3 adjacent nature reserves with different names and
ownerships.
It's possible to see the property boundaries on old maps, but after
visiting the site again yesterday I can find little remaining physical
evidence of the boundaries, with many
I am reminded of at least one single way I have edited (there could be
more, it was some time ago)... it is a single way used for;
boundary of 2 states of Australia
boundary of 2 councils
boundary of 2 National Parks - note that these 'National Parks' are
administered by the individual states
5 Jun 2019, 19:55 by mar...@templot.com:
> But on the OSM standard map, the common boundary is shown as a bold green
> line, which bears no relation to anything on the ground and could be
> misleading for visitors.
>
Note that maps are not aerial images - there is often significant level of
The bounds of an area don’t mean there’s a barrier there. But a nature reserve
does render on that map in a similar way to a tree line or hedgerow would be
rendered.
I’d leave it as it is. The problem is appears to how it renders, rather than
how it is mapped. It could be totally fine with a
14 matches
Mail list logo
