Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding rendering of landuse=plant_nursery #2537

Merged
merged 1 commit into from
Mar 21, 2017

Conversation

kocio-pl
Copy link
Collaborator

@kocio-pl kocio-pl commented Jan 7, 2017

Resolves #1772.

vpb_7rtj
5axxl gk

@polarbearing
Copy link
Contributor

Thanks. However the examples confuse me a bit. How are they tagged?

Is the nursery the smaller green area in both? In the second, where does the outline come from, and is the tree pattern from a larger forest landuse?

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Jan 7, 2017

Yes, both are in the middle. I wanted to show how the same color looks in different rather popular environments.

This is the first one:
http://www.openstreetmap.org/way/154336775

The second one is just fenced and being part of the forest:
http://www.openstreetmap.org/way/336901548

@polarbearing
Copy link
Contributor

Fine then, this explains it. This was my example from the issue, next to a forest and sports environment: http://www.openstreetmap.org/way/9759196

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Jan 7, 2017

Here you are:
xxj2lg_2

@polarbearing
Copy link
Contributor

Beautiful :-)

@imagico
Copy link
Collaborator

imagico commented Jan 7, 2017

If an area color is used with and without a pattern the version without usually indicates a less specific, more general variant. This is not the case here. Therefore i would try a pattern as suggested in #1772 - it does not have to be exactly as suggested there, other variants could work as well.

The wiki page needs a clearer definition that makes clear that a site where plants are going to grow old in place is not a plant nursery - otherwise people could start tagging any newly planted forest a plant nursery.

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Jan 7, 2017

Aren't you afraid that it will look like an orchard?

👍 for wiki update.

@imagico
Copy link
Collaborator

imagico commented Jan 7, 2017

It should look like a different kind of orchard (or more precisely: both should look like variants of the same base class, i.e. intensive care permanent plant growth for a specific purpose).

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Jan 7, 2017

Is there a way to save the pattern from your script as SVG file instead of base64 data in URL? I would like to start using vector patterns.

@polarbearing
Copy link
Contributor

I suggest to merge this as an improvement over not rendering at all, and discuss a potential pattern afterwards.

@imagico
Copy link
Collaborator

imagico commented Jan 7, 2017

@kocio-pl - you can save the data link like any other link (right click or open and save page as...)

@polarbearing - as i like to put it: the good enough is the enemy of the great, we should aim for the best solution possible under the circumstances, settling for a good enough discourages work on making it great.

You could also see it more formally - settling for a good enough would mean closing one issue but opening another (for making it better). The aim should be to reduce the number of of open issues and not just replacing the more severe ones with less severe ones.

@polarbearing
Copy link
Contributor

polarbearing commented Jan 7, 2017

Well, the new issue would be about plant lifecycles in general, there is some need for discussion as well as we learned from the wood logging example.

As for a pattern, I could imagine a trapezoid with a line growing from it, i.e. a pot with a small plant.

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Jan 7, 2017

It's not user friendly solution, but I did it. Worse problem seems to be that the vector pattern is not visible at all, even when making background white or light grey. Changing the code line with orchard pattern shows orchard dots, so it seems that either SVG file is not suitable for Mapnik or there is some software error. Could anybody else test it?

@imagico
Copy link
Collaborator

imagico commented Jan 7, 2017

For direct use in mapnik you probably need to render inlined. See imagico/jsdotpattern#3

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Jan 8, 2017

as i like to put it: the good enough is the enemy of the great, we should aim for the best solution possible under the circumstances, settling for a good enough discourages work on making it great.

You probably know it and this is simply your statement, but original quotation was actually a big red warning against "perfection" hell.

You could also see it more formally - settling for a good enough would mean closing one issue but opening another (for making it better). The aim should be to reduce the number of of open issues and not just replacing the more severe ones with less severe ones.

In this case it's not too much work to add desired pattern and your proposition makes sense for me, so I'm just willing to do it and there's no problem with this ticket.

But while the aim is exactly how I see it, this attitude doesn't actually help closing any issues - they stay unresolved for such a long time that we've lost any trace of some of them, even with tags. I sometimes feel as the ticket archeologist (Peter is also trying to dig there). Hard numbers tell we have about 380 open issues and this is not getting any lower despite some PRs that could do it (I know: because they could be better).

This is exactly what I call "analysis paralysis" and "overengineering":

Overengineering can be desirable when safety or performance on a particular criterion is critical, or when extremely broad functionality is required, but it is generally criticized from the point of view of value engineering as wasteful.

We have finite supply of resources, the project is not about nuclear power station, the data is changing constantly and small changes accumulated proved to be effective. Issues closing rate shows me that it's working the other way around: perfect is the enemy of good.

What really works is for example suggesting possible solutions, just like in this ticket. If you could find the issues that could be fixed, it would help exterminate some of them. This is also what I would really appreciate.

@kocio-pl
Copy link
Collaborator Author

kocio-pl commented Jan 9, 2017

Making right vector pattern seems to be harder than expected and I have questions about the link you gave:

  1. Why the size of the pattern is 128 and not something much smaller, when it's so regular?
  2. What do you mean by render inlined? Clicking "render (inlined)" does produce SVG file that looks like this:
    b9pki kc

@imagico
Copy link
Collaborator

imagico commented Jan 9, 2017

Why the size of the pattern is 128 and not something much smaller, when it's so regular?

That is explained on http://blog.imagico.de/some-pattern-math-regular-patterns/ - the closest hexagonal dot packing has an irrational aspect ratio so the mismatch from the ideal grid depends on the size the pattern is rendered at. It is possible that in this particular case you can also use a smaller size - i have not tried. But in general this is the problem here. Of course if you ultimately want a pixel aligned pattern the whole thing is fairly moot although the whole point in using an SVG directly is to be resolution independent.

What do you mean by render inlined? Clicking "render (inlined)" does produce SVG file that looks like this:

As said on imagico/jsdotpattern#3 i have never tested the results with mapnik. If there is a problem bug reports are welcome (although i can't promise a fix, it depends on how difficult mapnik is in that regard). Have you tried opening the SVG in inkscape, saving it there and using that?

@imagico
Copy link
Collaborator

imagico commented Jan 9, 2017

Regarding over-engineering:

You seem to neglect that this is primarily a design project and not an engineering project. In engineering aiming for perfection is often frowned upon because of diminishing returns. Above a certain level of quality the effect improvements in engineering have on the ultimate results (like a product manufactured or a service) are negligible and the improvements - if at all - have an effect only internally, like on reliability and efficiency. Therefore at least from a purely short term economical perspective you aim not to over-engineer.

However in design we do not have this phenomenon. Every imperfection in design has a direct influence on the quality of the results. So you cannot really transfer common wisdom from engineering here.

But even in engineering related aspects of this project there is a long tradition in not sacrificing overall long term aims for short term improvements - something i also learned the hard way by the way - see #646 (comment)

And regarding open issues - a huge portion of issues that have been open for a long time are fixes for problems and not feature additions. As i have pointed out multiple times already we should aim more at addressing those than adding new features which - even with high standards in design that are not satisfied with a good enough solution - will inevitably lead to new issues. Just look at https://github.com/gravitystorm/openstreetmap-carto/issues?q=is%3Aopen+is%3Aissue+label%3Aeasy for example.

@kocio-pl
Copy link
Collaborator Author

I was not able to render SVG file properly, so I stick with PNG for now. Rendering with pattern:
v1znmaco
raivwt8p
tv0oh6sb

@imagico
Copy link
Collaborator

imagico commented Jan 13, 2017

Looks all right to me - although contrast could probably be somewhat weaker so the overall weight of the pattern is not larger than for orchard.

@kocio-pl
Copy link
Collaborator Author

What color do you suggest other than what was included in the link? The only visible difference for me is more dense pattern.

@kocio-pl kocio-pl mentioned this pull request Jan 19, 2017
@matthijsmelissen
Copy link
Collaborator

Thanks, looks very nice!

@matthijsmelissen matthijsmelissen merged commit 7b65eda into gravitystorm:master Mar 21, 2017
@kocio-pl kocio-pl deleted the plant_nursery branch March 21, 2017 23:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants