-
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
fountain rendering problems #1934
Comments
Could you be more specific, so we can talk about precise cases? There are a lot of fountains in this area. For me it looks like few different problems with z17 mainly, some justified (which should be fixed if possible) and some just showing tagging problems (which is a good thing), so let's discuss more detailed examples. |
Not sure how i can be more specific - I listed the problems and all of them are visible in the images shown. They are widespread, you should not have difficulties finding other examples in other places. And i don't see how any of the issues mentioned can be considered a tagging problem - either there is a fountain at a certain point or not - other than mapping a fountain where there is none i don't see how tagging can be incorrect. It seems by the way that some labels are rendered below the water circle, some above. Unless you avoid overlap with labels altogether you have to render this below. I am not sure if it is technically possible to do so and make sure it is only rendered if also the dot is rendered. |
Another good example for most of the problems in combination: |
I mean I'd like to separate problems per object, not further combine them. Unfortunately I have very little time lately and less searching and guessing is preferable for me. For example this should be probably tagged as one fountain on the area instead of 2 points - if at all, because I don't see anything like nozzle on Bing. I think most of the time this artefact will disappear, because in area fountain icon/name will be displayed in the centre, not on the border. It's still possible that perfectly valid tagging could produce such artefacts, but that is true for everything, so if it will be a question of tagging, we don't have to resolve it here. But it takes a lot of precious time for me to draw such conclusion. This rendering is broken and I haven't seen such thing before when testing. I probably took the circle like the tree, but it doesn't behave the same, so I have to investigate it closer. Lack of blue dot inside also needs some testing. So in my opinion the problem 1) and 2) are worth digging. But further testing which ones disappear between z17 and z18 (problem 3) also needs some time to check and this is more than I have right now. I also need example for problem 4) - do you mean this one? I consider it justified example of generalization, but I don't want to write too much before I'm sure what do you think and if this is the problem you were talking about, in the first place. I meant being "specific" in this sense. What are your conclusions and propositions regarding current rendering? |
I don't want to turn this into a tagging discussion, the examples i showed all seem valid tagging to me including the Barcelona ones. There is also nothing in the tag definition saying that several fountains within the same water areas are generally to be mapped as one fountain - this would also appear quite strange as a rule.
Not specifically but every case where the water circle overlaps a water area and is not fully enclosed within it is misleading. Every case of a fountain without a water area is likewise. With the sizes chosen this is the case for the majority of situations. There is no way for the map user to decide if the water area shown is real or not. The Barcelona example is fairly good for illustrating this.
I said this before: rendering a water color circle around every fountain is a bad idea and rendering a symbol at z18 larger in ground units, i.e. more than twice the size than at z17 is also not going to work well. |
Having the context for a dot - water circle - is still more important to me than occasional rendering problems (aside from problems 1 and 2, which, I agree, should be fixed). It seems I just have different priorities in this matter than you. Leaving just a dot at z17 would make your problem much bigger - like dozen times, not just twice. And you could say the same about trees (first the dot, then a dot with a circle), but I don't remember it was ever an issue when introducing this "french style" tree rendering. I find it even more smooth transition than typical "lack of rendering -> suddenly rendering from next zoom level", as we do most of the time. |
Yes, i already pointed this out in #1804 (comment)
No, unlike water basins around fountains trees are always real objects, there is nothing in the styling of trees in this style that implies something that is not there. They also change rendering size from one zoom level to the next in a reasonable manner (slightly stepped - something i pointed out in #978 (comment) - but that's a minor problem). |
Hm, as a matter of fact it looks like exactly the same problem: by rendering green circle you claim the tree has always (1) green canopy with (2) specific diameter. Which may be true for a typical tree (as with typical fountain type), but not in all the cases (as with not typical fountains) - for example some trees are dead and some fountains have no water basin. |
On zoom level 17 the fountain circle is rendered above the place=square node name: |
Would you like to investigate if moving layers could help without introducing some nasty side effects? |
As already indicated in #1804 there are a number of problems with the new rendering of fountains. Specifically:
Examples:
http://www.openstreetmap.org/#map=17/47.99291/7.85374
http://www.openstreetmap.org/#map=17/49.00819/8.40933
The text was updated successfully, but these errors were encountered: