-
Notifications
You must be signed in to change notification settings - Fork 822
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
Conversation
a13d0ff
to
60b2e81
Compare
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? |
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: The second one is just fenced and being part of the forest: |
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 |
Beautiful :-) |
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. |
Aren't you afraid that it will look like an orchard? 👍 for wiki update. |
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). |
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. |
I suggest to merge this as an improvement over not rendering at all, and discuss a potential pattern afterwards. |
@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. |
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. |
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? |
For direct use in mapnik you probably need to render inlined. See imagico/jsdotpattern#3 |
You probably know it and this is simply your statement, but original quotation was actually a big red warning against "perfection" hell.
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. |
Making right vector pattern seems to be harder than expected and I have questions about the link you gave: |
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.
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? |
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. |
60b2e81
to
7b65eda
Compare
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. |
What color do you suggest other than what was included in the link? The only visible difference for me is more dense pattern. |
Thanks, looks very nice! |
Resolves #1772.