More vertical objects rendering and tuning

[kocio-pl]

Follow up to #2671 (comment)
Fixes #3275

Changes proposed in this pull request:

• adding rendering:
  • tower:construction=dish
  • tower:construction=dome
  • tower:type=cooling
  • tower:type=watchtower with tower:type=observation icon
  • man_made=chimney
  • man_made=communications_tower
• hiding verticals located on roofs

Rendering with links to the example places: #3158 (comment).

[geozeisig]

man_made=communications_tower with dome so it is different from tower:type=communication:

twice as big:

[kocio-pl]

Could you publish a gist?

[geozeisig]

Communication_tower.svg

[kocio-pl]

Does anybody know how to expand our code for height to work with optional unit "m"?

Current code is based on ele code (where units are not possible):

openstreetmap-carto/project.mml

Line 1466 in ea769f4

WHEN tags->'height' ~ '^-?\d{1,4}(\.\d+)?$' THEN (tags->'height')::NUMERIC

I was trying to replace this regex with something like:

^-?\d{1,4}(\.\d+)?(\s[m])?$

or with additional grouping:

^(-?\d{1,4}(\.\d+)?)(\s[m])?$

and it looks more or less OK with testing ( https://regex101.com/ ), but it doesn't work. I guess it tries to evaluate the whole expression instead of just the first group, but I don't know how to fix it.

[kocio-pl]

Rendering tests (with initial zoom levels):

tower:construction=dish (+tower:type=communication), z17
Before

After

tower:construction=dome, z17
Before

After

tower:type=cooling, z17
Before

After

tower:type=watchtower, z18
Before

After

man_made=chimney, z16
Before

After

man_made=communications_tower, z13
Before

After

Hiding tower=communication+location=rooftop, z14
Before

After

[wmyrda]

Tower look great.

For regex I would try this ^-?\d{1,3}(.\d+\s[m])?$

One thing I can say is that changing from 1,4 to 1,3 seems reasonable hence in ele we have places located at high above 1000m while for object high I believe all of them would fit under 999 including Burj Khalifa (hence 3 digits only).
Adding \s[m] directly into the expression seems logical and just might work.

[wmyrda]

I noticed addition of man_made=communications_tower to the code. Even when I like as many tags added to rendering as possible personally I find logic behind such a specification a bit redundant to man_made=tower.
eg. https://www.openstreetmap.org/node/3109071579 works just fine for that kind of object.

Question is would it not be better to simply change all instances of man_made=communications_tower
to man_made=tower & tower:construction=freestanding & tower:type=communication which specifies just that instead of rendering similar object which would add more cpu power requirements to the rendering server for another inquiry?
Also not to lose any information that we are dealing with big object for nodes with missing height add height=101 as man_made=communications_tower specification states that object has to be of that size or higher.

[kocio-pl]

I'm pretty sure that many towers/masts are mistagged. But that is - partly - due to lack of rendering them and I hope this will improve over time.

I've been thinking about it and decided that it makes sense to have man_made=communications_tower when you have no specific knowledge about height, but you know that it's large. We lack some tags like this in OSM, but they can be very handy.

Of course, if tagging habits and documentation will change, we can change rendering too to follow it, but at the moment it seems right for me to render them - 3970 uses and a wiki page that I can understand how it's different from regular towers is enough for me.

[kocio-pl]

For regex I would try this ^-?\d{1,3}(.\d+\s[m])?$

Doesn't work, I still think it tries to treat "m" as a number and fails:

Postgis Plugin: ERROR: invalid input syntax for type numeric: "230.68 m"

[wmyrda]

I used to create many regex syntaxes for nano editor with most recent being https://github.com/mikaku/Monitorix/blob/master/docs/monitorix.nanorc but as you see it is much simpler than that for sql query so that is why I said it "might" work ;)
One more idea is to completely throw out that numeric expression. Do you still use THEN (tags->'height')::NUMERIC? That definitely would change whole string into numeric.

As for man_made=communications_tower I guess you are right and it is better to render it hence it is well established map feature, but it does not change my humble opinion that it is somewhat redundant to man_made=tower

[kocio-pl]

tower:type=radar icon is currently missing, do you have an idea how should it look like? I would think of something like:

• https://proxy.duckduckgo.com/iu/?u=https%3A%2F%2Fcdn1.iconfinder.com%2Fdata%2Ficons%2Finternet-3-3%2F512%2F115-128.png&f=1
• https://cdn4.iconfinder.com/data/icons/airport-7/500/6-128.png
• https://www.iconfinder.com/icons/328194/airport_control_tower_radar_icon#size=128

but most probably like this type:

• https://www.canstockphoto.com/silhouette-military-radar-dish-vector-31525352.html

[turnsole80]

The first of these seems to be the most appropriate to me, the others looks a bit cluttered. The exception would dome radars (radomes) that should keep their bulbous head look

[wmyrda]

First one actually look to me like an icon for night club, cocktails or something similar. Second I like, but it looks like airport control tower and question is whether that is always the case that radar is also located there. I just do not know that, but still I like that one the most.
Third one has to much information which may be hard to fit in 14x14 icon. The last one is a radar all right, but good for ground radar, not for radar tower. Besides towers are less likely to be mobile :)

[kocio-pl]

I was talking with a fellow coder and he found a solution with a "lookaround" regex feature:

^-?\d{1,3}(\.\d+)?((?=\s*m$)|$)

It works properly on https://regex101.com/, so I will test it soon.

[kocio-pl]

Unfortunately it doesn't work... However there's a section about lookarounds in PostgreSQL documentation, so maybe someone could dig into this a bit more:

https://www.postgresql.org/docs/9.6/static/functions-matching.html#POSIX-CONSTRAINTS-TABLE

[SomeoneElseOSM]

tower:type=radar icon is currently missing, do you have an idea how should it look like?

Is https://github.com/SomeoneElseOSM/openstreetmap-carto-AJT/blob/master/symbols/radartower.png any use?

[meased]

I used this for the waterfall code:

^(\d{1,4}(\.\d+)?)\s?m?$

This allows whitespace at the end of the line (casting to NUMERIC will ignore this). We could disallow it like this:

^(\d{1,4}(\.\d+)?)(\s?m)?$

[kocio-pl]

Great! I think we should use restricted version (trailing space is a mistake) and we should also restrict height to 3 digits, because the highest waterfall has just 979 m. I guess even (\s?m) should be changed into (\sm), because such units should be always used after one space.

[Tomasz-W]

After countless times of trying to make a readable radar 14x14 design, my proposal:

I've tried with 2d and 3d, with many proportions, and it's the best what I can propose at the moment. If you have any suggestions, give me a feedback.

[wmyrda]

@Tomasz-W I have mixed filling about that look for tower:type=radar as is kinda resembles the candy on the stick.
At the same time I think that we have so much problem with picturing radar towers as they come in all kind of shapes and sizes. Maybe we should show tower:type=radar only when it is accompanied by tower:construction? Having that said I would propose following:

tower:type=radar & tower:construction=lattice
https://img-new.cgtrader.com/items/105121/776fc696b6/large/big-radar-tower-3d-model-low-poly-rigged-max-obj-3ds-fbx-dae-tga.jpg
tower:type=radar & tower:construction=freestanding
https://d1o2pwfline4gu.cloudfront.net/m/t/601/6012345/a-0005.jpg
tower:type=radar & tower:construction=dome
https://wiki.openstreetmap.org/wiki/File:Tower_dome.svg - use the one we have for dome

[Tomasz-W]

What about radar shape merged with obstervation tower stand?

[wmyrda]

I really like idea the most from all the previously proposed. Could You also try icon with the same top part but with solid base like in your previous example? Just so we have variation for tower:construction=freestanding

[Tomasz-W]

@wmyrda

• (observation tower base)
• (halftoned-version)
• (solid base)

[wmyrda]

I kinda like "observation tower base" more than "halftoned-version", but if others have different opinion I would not mind to have either as it does differentiates it more from hunting stand.

Solid base looks ok, but I think we could also try using base with 2/3 wideness of the rectangular box on the top to make it a bit wider which could give it more indication that it is not mounted on the pole.

[geozeisig]

I miss man_made=communications_tower in Carto release v4.10.0.

[pnorman]

I have a few concerns

• We're adding 5 more icons. Any symbol addition needs to be worth the cost of additional icons, and no reason is given for why we want to render these. I makes it hard to address if it should be merged without a reason for the changes.

• The icons don't meet our guidelines. In particular

• Stroke is used in a couple places

On an icon-by-icon basis

The top of the stack should align with a pixel edge, as should the bottom of the clouds. The cloud might be too complex for 14px.

The alignment looks good except for the horizontal lines at the base, which are almost on a pixel edge.

The visual weight of this icon is much higher than other icons.

The upper edges should be straight and aligned to pixel edges.

The lines that are almost on a pixel edge need aligning

Can we get more alignment with pixel edges? The right of the bottom base can be aligned.

[pnorman]

don't set stroke-width, etc

[pnorman]

no stroke-width, etc

[pnorman]

no stroke-width, etc

[pnorman]

no stroke

[pnorman]

no stroke-width, etc

[kocio-pl]

We're adding 5 more icons. Any symbol addition needs to be worth the cost of additional icons, and no reason is given for why we want to render these. I makes it hard to address if it should be merged without a reason for the changes.

I'm glad you have asked. I was thinking about it myself and came to the conclusion that I find lack of more "tower" shapes disturbing. This is so broad category of objects, that the only thing that make them similar are their height and (to some lesser degree) proportions. No wonder generic tower shape looks much like the mast - it can be anything, so the neutral option seems to be to show generic idea of "height". This is especially true for cooling towers and that's why their visual weight is higher - they are big and "heavy" in reality, totally unlike masts:

https://commons.wikimedia.org/wiki/File:Didcot_power_station_cooling_tower_zootalures.jpg

Stroke is used in a couple places

I believe this is what Inkscape puts in the files automatically. I have never used a stroke in our icons, yet I have found it multiple times. Think about it as a stroke value that would be used in case you'd be using this feature (even if you're not).

[kocio-pl]

The icons don't meet our guidelines. In particular

@Tomasz-W Do you think this can be improved (mostly pixel aligning) without losing readability?

[kocio-pl]

BTW: the whole cooling issue is dynamic and not settled yet - we're in the middle of abrupt changes, so expect things to change in the future anyway:

[dieterdreist]

@kocio-pl Yes, it is dynamic, are you going to add man_made=cooling_tower to the rules?

[kocio-pl]

I deny predicting the future... Let's re-examine this after some time, like 6-12 months.

[Zverik]

Okay, found one of the retaggers: https://www.openstreetmap.org/changeset/59147983

[imagico]

See also

https://taginfo.openstreetmap.org/tags/tower:type=cooling#map
https://taginfo.openstreetmap.org/tags/man_made=cooling_tower#map

Classic case of two competing taggings and different regional preferences and no clear dominance. Also great example to illustrate why absolute use numbers say very little about acceptance and popularity when the tagged object is relatively rare and there might be a lot of mappers who support a certain tagging but have very little opportunity to actually use it and this way manifest their opinion in actual use numbers.

[imagico]

Note the neutral approach would be to render neither but this would only be neutral if man_made=tower + tower:type=cooling is not rendered with a generic tower symbol.

[wmyrda]

Hooray for getting this merged!
Just of of curiosity why some svg files have the xmlns:dc= and alike data as one liner while others have them spread out in different lines. IMHO for all the svg files in repository they should be kept consistent whichever whey is preferred.

[dieterdreist]

sent from a phone

On 22. Jun 2018, at 17:44, Christoph Hormann ***@***.***> wrote: Note the neutral approach would be to render neither

or render both. This could still come under the banner of avoiding tag fragmentation, as otherwise there could be much more than just 2 different tags. Regarding the support of consistent tagging, cooling towers do not fit at all under the definition of man_made=tower (there is no doubt that they aren’t buildings, are not accessible and do not have platforms, etc.), nor do lighting towers or communication towers (those defined as subtypes tower:type for man_made=tower, while those defined for man_made=communications_tower do, this is super absurd). As much as I like the icons and would like to see all those things on the map, the system is a mess and the definitions of the generic tower and the tower:type subclasses are in mutual contradiction. Nonetheless it doesn’t cover all “tower” occurrences, e.g. leaves out water towers, power towers and communication_tower s.

[wmyrda]

cooling towers do not fit at all under the definition of man_made=tower

Cooling tower just like the name says is a tower just of specific use. Same goes for all other towers and if you ask me all other man_made=* structures resembling any type of tower should be changed to man_made=tower and tower:type=* for consistency. This is natural approach as man_made=tower engineering definition explains. It is just OSM always has to mix things up and say something stupid as "A tower is accessible and provides platforms" which has nothing to do with basic tower definition.
It is obvious from historical data shown in this thread that users agree with that natural approach and like tower:type=* and just some manual intervention had to change things up. That being said I am glad it is ["tower:type" = 'cooling'] that is rendered.

[dieterdreist]

sent from a phone

On 23. Jun 2018, at 07:36, wmyrda ***@***.***> wrote: Cooling tower just like the name says is a tower just of specific use.

and a power tower is a tower as well? A bridge is a dental restoration? The name is one thing, common characteristics another.

[imagico]

Once again: please stop the tagging discussion, this has no place here. If mappers decide to consistently tag cooling towers foo=bar it would not be the place of this style to tell them they are wrong.

And @dieterdreist - no, tag fragmentation does not start only when there are more than two synonyms for the same type of feature.

[kocio-pl]

Some tag discussion is OK for me here, because we try to interpret the state of things to render them properly. But given your idea of anarchic tagging, I see no place to tell anybody to be wrong (just being different from majority in best case).

tag fragmentation does not start only when there are more than two synonyms for the same type of feature.

Could you explain what do you mean by that?

[dieterdreist]

sent from a phone

On 23. Jun 2018, at 12:20, kocio-pl ***@***.***> wrote: tag fragmentation does not start only when there are more than two synonyms for the same type of feature. Could you explain what do you mean by that?

if different concepts are used to describe things, where there is some overlap of meaning of these tags, it would also be tag fragmentation (especially if there were many different concepts and overlaps, and all would be similar in number of uses).

[imagico]

Could you explain what do you mean by that?

I meant to turn down the attempt from @dieterdreist to relativize long standing principles of this style with a 'but it could be worse' argument.

We have had the common practice in the past that if there are several tagging schemes competing with similar support to be the method to tag certain real world features that we avoid taking sides by rendering one of them but not the other, especially if there are different regional preferences like here and such a decision can be seen as regional favoritism. At the same time we have traditionally avoided adding rendering of multiple tags with no discernible difference in meaning to avoid supporting tagging fragmentation. The situation here is somewhat special because both before and after merging this PR we were not neutral because we previously rendered man_made=tower (and therefore also man_made=tower + tower:type=cooling) with a generic tower symbol. So you can rightfully argue if this change makes this worse or not. And generic man_made=tower has been rendered for a really long time. But i consider it important to uphold the principles i explained even if in this case there is no way to fully put the genie back into the bottle so to speak. So i pointed out that we have a case here where we should normally refrain from rendering either of the competing tags.

By the way it is well possible that some of the recent re-tagging activity is due to cooling towers typically being quite high and height being used for importance rating of towers now. It seems many of the more recent re-taggings are on cooling towers with a height tag. In other words: Before this PR there could have been an incentive for re-tagging to man_made=cooling_tower to avoid the prominent unsuitable symbol, after this PR the incentive might turn into the opposite direction. It is important to be mindful about how we are messing with the mappers here - deliberately or not.

[dieterdreist]

sent from a phone

On 23. Jun 2018, at 14:10, Christoph Hormann ***@***.***> wrote: And generic man_made=tower has been rendered for a really long time.

actually not, in my perception it is rendered only relatively recently

[imagico]

Right, sorry, my mistake - i had mixed mast and tower in my recollection. That means #2671 was the change initially messing with things.

[dieterdreist]

2018-06-23 14:48 GMT+02:00 Christoph Hormann <notifications@github.com>:

Right, sorry, my mistake - i had mixed mast and tower in my recollection. That means #2671 <#2671> was the change initially messing with things.

does this have implications on your reasoning?

[imagico]

Not much - it just means that the problem could have been avoided in #2671 and it puts additional support on the observation described in the last paragraph.

[dieterdreist]

sent from a phone

On 23. Jun 2018, at 15:33, Christoph Hormann ***@***.***> wrote: Not much - it just means that the problem could have been avoided in #2671 and it puts additional support on the observation described in the last paragraph.

would it be open for consideration to remove the rendering of man_made=tower when it is combined with tower:type=cooling ? IMHO this could be a temporary fix for the dilemma

[imagico]

As i said this would be the neutral approach to the issue.

But as also said this would not nullify the previous influence we already exercised (as mentioned with this PR included in two different directions).

For me this is all much more about raising awareness and making conscious decisions than about trying to correct decisions afterwards (which does not prevent making the same mistakes again in the future anyway).

[dieterdreist]

sent from a phone

On 23. Jun 2018, at 16:46, Christoph Hormann ***@***.***> wrote: For me this is all much more about raising awareness and making conscious decisions than about trying to correct decisions afterwards (which does not prevent making the same mistakes again in the future anyway).

for me man_made=cooling_tower is the better tag, more consistent with the rest of the tags (water_tower, communication_tower, power=tower, not conflicting with the man_made=tower definition), and it is clear, if we do not render it but render tower:type=cooling it will not make it As we are aware of this issue now, why would we not fix it (fixing in this context means acting in accordance with the self proclaimed goals and criteria/procedures). We (OSM system of tagging and rendering) have fixed several very elemental object types just relatively late, after more than a decade of mapmaking, e.g. squares, unpaved roads, bridges, and now towers. It is possible to adjust decisions.

[kocio-pl]

That means #2671 was the change initially messing with things.

From my point of view, the story of roots of this small problem goes much deeper. This PR was solution based on issue #2556 (with code implemented first by @wmyrda), which has been formal proposition to solve the problem described on 29.11.2016 in @BushmanK blog entry. And the mess was born with rendering telecommunication icon for variety of towers and masts (I don't even know when).

It's a normal thing for me to see the things evolving and finding new problems while trying to fix the old ones. Also OSM is not a static project, and osm-carto should follow.

would it be open for consideration to remove the rendering of man_made=tower when it is combined with tower:type=cooling ?

Do you mean rendering "stick" or not rendering any tower icon at all?

We (OSM system of tagging and rendering) have fixed several very elemental object types just relatively late, after more than a decade of mapmaking, e.g. squares, unpaved roads, bridges, and now towers. It is possible to adjust decisions.

For me it's more than possible - it's needed.

[sinanna]

@kocio-pl I would like to report another mechanical retagging on cooling towers (by user ForstEK): http://www.openstreetmap.org/changeset/60118947

He even refuses to accept a revert and started a "Wikipedia-style" edit war: http://www.openstreetmap.org/changeset/60189430

[SomeoneElseOSM]

@sinanna As per https://wiki.osmfoundation.org/wiki/Data_Working_Group , I'd suggest dropping an email to the DWG explaining the problem. http://resultmaps.neis-one.org/osm-discussion-comments?uid=1737608 suggests that they have some "previous" here.

[geozeisig]

Now tower:construction=dish will be rendered. But only if man_made=tower is used. Frequently, however, man_made=telescope (here) is also used or man_made=antenna (here).
Is this a tagging error? Or can we also render telescope with it?