[Tagging] Feature Proposal - RFC - Enhancing natural=peak tag

Matthijs Melissen info at matthijsmelissen.nl
Wed Jul 9 12:01:29 UTC 2014


On 9 July 2014 00:05, Daniel Koć <daniel at xn--ko-wla.pl> wrote:
> W dniu 08.07.2014 20:04, yvecai napisał(a):
>> However, if rendering is an interesting topic, wiki is full of
>> rendering examples and advices that aren't followed anywhere. Let the

> You don't even realize how sad is this observation for me...
>
> What is the role of writing documentation than - and approving it or
> declining? You can always use the tags as you like it, and they will be
> rendered this way or another (or not a all), so why waste the time proposing
> and documenting?

I think it's best to think of it as a two step process: first propose
the tags that describe the reality (here), then propose how they
should be rendered (on the openstreetmap-carto Github).

That said, I also don't have problems with a rendering paragraph in
the proposal - as long as it's clear that it's meant as illustration
of the proposal, and not (directly) as a proposal to change existing
rendering.

Both tagging and rendering discussions are already difficult enough as
they are - separation of concern simplifies the discussion (also, some
people are only interested in rendering and others only in tagging).

I think your rendering proposal makes sense by the way, but as I said,
it's a two step process. Tagging and rendering decisions can (and
should) be made independent.

> But inside the project I think we need some more coherency. If there's an
> approved proposal with rendering hints, at least the default render should
> take it into account.

I don't think that's necessary, see above.

> And I see the difference in scale of peaks type, which should
> be properly visualised to not make default map cluttered with unnecessary
> details (like https://github.com/gravitystorm/openstreetmap-carto/issues/689
> ).

Yes, I agree this needs to be solved.

-- Matthijs



More information about the Tagging mailing list