[WIP] Add render for power portals and insulators

[flacombe]

Fixes #2107
Proposed rendering has been discussed there and contributors all agree. Don't forget to ask them prior to edit this PR.

Changes proposed in this pull request:

• Add power portals and insulators in project.mml as nodes and ways
• Render them in power.mss according to the pictures below

Test rendering with links to the example places:
Let's take this massive power substation : https://www.openstreetmap.org/way/110086345

Before

After

[Tomasz-W]

@gustavecha Can you try with thinner line? I think it's unnecessary too prominent.

[flacombe]

@kocio-pl will go on testing it
I think this will lead to fine tuning of ways width

[sommerluk]

I would suggest to not use green colour for the connection dots. Green should be rather reserved to natural features like trees and so an. Black dots seem more appropriate.

[matkoniecz]

I am also unhappy about green dots, for me it looks very weird.

I would also keep green for natural features and leisure.

[flacombe]

Indeed the green wasn't a great choice and I updated the mss to change that.

[kocio-pl]

Sorry for the time it took me to comment this code. The biggest question I have here is - do we really need 4 new data layers? As far as I understand (which might be not true) adding new layers can make performance problems.

[Tomasz-W]

I think it all should be coloured by "@power-line-color" to match the rest of power system rendering. I would use 1.5 width for power insulators ways.

[flacombe]

@kocio-pl I use the 4 layers in the mss so I guess yes we need them. If you see a better design, no problem to reduce the amount of layers.

@Tomasz-W I didn't use the same grey as I wish to lightly distinguish portals from lines. This is done on purpose.

[kocio-pl]

I guess it's enough that this is just wider, because it's clear from the context, no need to change the color. Could you test the rendering?

I'm not even sure why we need both power-minorline and power-line in the current code. They have different minzoom, but I'm not sure what is better performance-wise: less data layers or separating objects rendered on higher zoom level. @matkoniecz what do you think about it?

Usage:

[flacombe]

I've tested with #888888 for portals.
It makes it less explicit and confuse with busbar lines at the middle of the substation.
Should I use line-width:2 for portals ?

This PR isn't a right place to debate about the minor_line/line I'm afraid. let's only focus on portals and insulators please

[kocio-pl]

I'm not too familiar with electricity distribution in general and in OSM, could you show an example of such a busbar, so I could understand the problem?

[flacombe]

Busbars are power lines in a substation allowing to switch the power from one incoming power line to another outgoing from the substation.
These are such on the picture, going to background to foreground on top several poles : https://wiki.openstreetmap.org/w/images/9/92/Power_400kv_dual_coupling_circuitbreaker.jpg
Lower orthogonal bars are bays connecting to incoming power lines
The two big Y devices on the foreground are circuits breakers just like the tiny one in your house actually.
This is a busbar : https://www.openstreetmap.org/way/239366609
This is a bay : https://www.openstreetmap.org/way/637316846

Power portals are metallic but grounded (not powered) supports. Power lines are anchored with insulators on them but not connected (unless a big lightning could appear and damage stuff around).

Tavel substation has recently been updated with actual bays between incoming lines and busbars : https://www.openstreetmap.org/#map=18/44.01483/4.64341

Then, despite all power stuff shouldn't clutter render, I think that it should not confuse between powered elements and grounded ones. May we use two different greys for that ?

[kocio-pl]

I see now and I think you're right.

Should I use line-width:2 for portals ?

Make a test, please.

[flacombe]

Here is the result with portal width 2px with @power-line-color

[kocio-pl]

It doesn't stand up too much, I prefer original look. Power stations are quite boring and unified, some elements should look different enough to help understand its structure, not only to see a lot of similar lines.

[sommerluk]

Hi @gustavecha

First of all, thanks for this pull request. I think it is a good idea to have a more complete rendering of power infrastructure, and your code is a good starting point for this.

Here I try to provide a more detailed review of your PR to allow more fine-tuning.

About the colour choice for the portals: It’s important to stick to our current colour scheme. The rendering might seem “boring”, but that’s nothing negative at all. Maps have to be “boring” to a certain extend to remain legible, especially if they are so feature-rich like this map style is. Having too many different colours is confusing. Therefore the colour for the portals should be a standard colour. This could be either the standard “power” colour of maybe also another appropriate colour, maybe the “man-made” colour.

I’m thinking about it might be better not to render insulators at all.

• One reason is consistency: All power towers for high voltage lines do not have the lines directly fixed on them, but they are fixed with insulators. Though most of the power=tower nodes do not have a power=insulator explicitly tagged, treating insulators on portals somewhat special seems inconsistent.

• Another reasons is the proposed rendering style: In circuit diagrams, the dot means “connection”. Using the same shape here for the opposite (=insulator) seems missleading.

• The rendering is not strictly necessary, because in most cases, lines crossing portals will indeed be connected by insulators with the portal. So it is perfectly possible to read the map also when the insulators are not explicitly rendered.

The other, more technical comments of this review you can find inline in the code.

Thanks again for the PR!

[kocio-pl]

The rendering might seem “boring”, but that’s nothing negative at all.

We try to give feedback to the mappers, so yes, there is clear downside of rendering all the elements the same, it's not about entertaining them. 😄

We show different colors of nodes for shops/gastronomy/offices because of that, we show roads with different colors and size to help determine more about them other than just being road, we also show power poles different exactly because of this. Power station should also be more than just a bunch of identical lines, if we know they differ and play different role there. More solid/important elements of the structure should use stronger color.

[flacombe]

We show different colors of nodes for shops/gastronomy/offices because of that, we show roads with different colors and size to help determine more about them other than just being road, we also show power poles different exactly because of this. Power station should also be more than just a bunch of identical lines, if we know they differ and play different role there. More solid/important elements of the structure should use stronger color.

I second this point of view.
Portals are mainly installed in substations which are enclosed perimeters.
Carto render may encourage users to map them as accurately as possible.
I only suggest to use two different grays, not to change everything regarding power and make carto look like this : https://openinframap.org/#17.48/44.014884/4.64264 (where portals are not yet rendered ayway)

[sommerluk]

@kocio-pl Shops and offices are big categories. It makes sense that they have their own colour. But if we would introduce individual colours for each individual rather seldom feature, than we would not only run out of available colours soon, but we would also have a horrible mess in the map soon. So: No, we do not need at all individual colours for each feature. Groups are more important, so the map stays legible.

@gustavecha Please stick with the currently existing colours. You could try @man-made-icon or @power-line-color or use the same colour of #power-poles. You can also darken or lighten existing colours:

@my_new_colour: darken(@my_old_colour, 5%);
@my_other_new_colour: lighten(@my_other_old_colour, 5%);

[jeisenbe]

Thank you for these improvements. Sorry for the delay in review.

The new rendering works well on z16, but it could still be better at higher zoom levels. There the points seems a little too small, especially at z18 and above, and they could still be more similar to the ways. (The best option would be to generate a way in SQL, perpendicular to the power line and use this for rendering, but that's a bit complex)

z16 comparison (left current, right after)

z17 after

z18 after

Also the lines in project.mml about power=insulator can be removed now.

[jeisenbe]

@flacombe are you able to update this PR with the changes requested above?

To test the rendering, I'd recommend trying our setup with Docker. It's easier to work with in many cases.

[flacombe]

Hi all,

Be sure I'm after that, a bit overloaded this week.
I'll be in Karlsruhe this weekend, and it will be a good occasion to close this PR.

[flacombe]

I've made the changes I find necessary to this PR. Thanks for the review and useful hints to improve it.
I hope this would meet our expectations this time

Generating ways with SQL as to make them orthogonal to the power line is a good idea, unfortunately it would take time I haven't this week :(

[jeisenbe]

This is the best rendering so far, just a small change needs to be made about the initial zoom level.

However, I'm still not certain about using the different rendering for ways and nodes. Perhaps there are other contributors who would be able to give their thoughts about this.

Example rendering:
z15 - icon shown on nodes but no rendering for ways; this needs to be fixed.

z16

z17

z18

[jeisenbe]

@sommerluk - what do you think about this idea?

Generating ways with SQL as to make them orthogonal to the power line

That would allow as to use the same, linear rendering style for both ways and nodes, rather than using a different rendering for the two ways of mapping, but it would increase the complexity of the SQL.

[sommerluk]

The good thing about doing this in SQL is that it results in nice rendering (the orientation of the portal rendering depends on the power line).

However, I have no experience with such SQL queries and do not know how to do this.

[jeisenbe]

@imagico - what are your thoughts about the current test renderings?

1. Is it acceptable to have a different rendering for ways and nodes: linear vs abstract icon, as currently in this PR?

2. How complicated would it be to generate a way in SQL, orthogonal to the power line way, based on the power=portal node? I haven't figured out how to do this.

3. Would it be better to render the POI icon at all nodes where a power=portal way intersects a power=line? How complicated is the SQL for that?

[imagico]

The most important thing about rendering is that it needs to be intuitively understandable and that it does not create counterproductive incentives.

You can do join queries to determine the intersecting power lines but you need to make sure you cover all the cases that might occur - including more than one power line intersecting the feature. I am not sure if that amount of complexity makes sense for a feature like this of relatively low overall significance.

From the most recent sample rendering it seems there might be a risk of the line rendering being confused with other linear features, in particular minor service roads

[jeisenbe]

Should we just render the nodes then? Perhaps we can consider this a situation like barrier=gate where mapping as a linear way is not really helpful or necessary? But the examples of linear ways for power=portal seem a little more consistent than the situation with barrier=gate

[flacombe]

Here I come with some SQL to generate portal ways for node ones.
I only test it on France import and it needs improvement (indexes, restrict on portal power line sections...), but you've got the general idea.
I've been really inspired by this discussion : https://gis.stackexchange.com/questions/90167/how-to-create-a-buffer-on-a-linestring-with-varying-or-increasing-decreasing-wid?rq=1

We've got approx 500 portal nodes and 440 of them are connected to a power line
0.001 distance buffer in ST_OffsetCurve could be tuned according voltage (the more the voltage increase, larger will be the portal).
Let me know how do you feel with that process and I'll take time to improve it later with your comments

DROP TABLE IF EXISTS powerlines_bounds;
DROP TABLE IF EXISTS powerlines_dumps;
DROP TABLE IF EXISTS powerlines_portals;

CREATE TABLE IF NOT EXISTS powerlines AS select osm_id, area, z_order, way_area, tags, ST_Transform(way,3857) AS way from planet_osm_line where tags->'power'='line';
CREATE TABLE IF NOT EXISTS powerportals AS select osm_id, area, z_order, tags, ST_Transform(way,3857) AS way from planet_osm_point where tags->'power'='portal';
CREATE INDEX ON powerportals USING gist(way);

-- Create negative/positive offset geoms from line
-- Intersect and cut powerlines with portal nodes: we keep only 10% of lines that actually connect to a portal node
-- LineMerge is used to normalise continuous multilinestrings and no issue if a single line touches several portal, inner join will duplicate it.
CREATE TABLE powerlines_bounds AS WITH powerlines_geom AS (
    SELECT
	 pl.osm_id,
         ST_LineSubstring(ST_LineMerge(pl.way), GREATEST(0, ST_LineLocatePoint(ST_LineMerge(pl.way), pp.way)-0.1), LEAST(1, ST_LineLocatePoint(ST_LineMerge(pl.way), pp.way)+0.1)) AS geom,
         COALESCE(pl.tags->'voltage','100000') AS voltage
    FROM powerlines pl
    INNER JOIN powerportals pp
         ON ST_Touches(pp.way, pl.way))

     SELECT
        osm_id,
	geom,
        ST_OffsetCurve(geom, 7, 'quad_segs=4 join=mitre') AS pos_bound, 
        ST_Reverse(ST_OffsetCurve(geom,-7, 'quad_segs=1 join=mitre')) AS neg_bound
    FROM powerlines_geom;

-- Dump points from both actual lines and boundaries
CREATE TABLE powerlines_dumps AS SELECT
    osm_id,
    0::bigint as portal,
    (ST_DumpPoints(pos_bound)).geom AS pos_bound_dump,
    (ST_DumpPoints(neg_bound)).geom AS neg_bound_dump,
    (ST_DumpPoints(geom)).geom AS geom_dump
FROM powerlines_bounds;
CREATE INDEX ON powerlines_dumps using gist(geom_dump);

-- Qualify geom_dump with portal nodes. Drop anything else.
UPDATE powerlines_dumps SET portal=pp.osm_id FROM powerportals pp WHERE ST_Equals(pp.way, powerlines_dumps.geom_dump);
DELETE FROM powerlines_dumps WHERE portal < 1;

-- Draw virtual portals
-- Distinct on portal_id as to draw only one portal when several lines share the same portal
CREATE TABLE powerlines_portals AS SELECT DISTINCT ON (pld.portal)
    pld.osm_id AS line_osm_id,
    pld.portal AS portal_osm_id,
    ST_MakeLine(pld.pos_bound_dump, pld.neg_bound_dump) AS portal_line,
    ST_Azimuth(pld.pos_bound_dump, pld.neg_bound_dump) AS portal_azimuth
FROM powerlines_dumps pld;

All the best

[flacombe]

SQL code upside updated with following changes:

• Move to SRID 3857 as to produce actual orthogonal portals and accurate lengths
• Virtual portals are now 14m wide
• Bugfix regarding ST_OffsetCurve producing extra nodes messing in index comparison between lines and offset nodes: Only 10% of connected lines are now kept to prevent this to occur. Not-connected-to-a-portal lines are ignored from the beginning.
• Index creation as to ease ST_Equals between line nodes and portals
• Distinction for portals supporting several lines

Final result in red, black is when calculation is done with EPSG 4326.

[imagico]

To avoid you putting too much work into an approach that we can't use here:

• anything will have to be done on the fly from the standard osm2pgsql tables. Creating custom tables with processed data like you seem to intend doing is not going to work with minutely updates on the database.
• keep in mind those 14m are Mercator meters, not real ground meters. We probably will not want something like that. Drawing dimensions of things should either be a certain size on the ground (an approach we have not used in the past for reasons of complexity - see Variable width rendering of aeroway=runway and aeroway=taxiway at high zooms #1853) or in a certain size on screen (you can use !scale_denominator! for calculating the pixel size in SQL).
• you should keep in mind that code complexity is always a significant concern for us here so if you add something technically more complex there should be a really good reason for that design wise.

[jeisenbe]

@imagico and @sommerluk - do you see any way that this PR can move forward with rendering just the power=portal nodes (or just the ways)?

[imagico]

Rendering nodes only could work, rendering ways only not - due to the numbers.

In principle i would not mind a unified rendering of both nodes and ways if it conforms with the mentioned criteria.

[flacombe]

Hi @imagico

Rendering nodes only could work, rendering ways only not - due to the numbers.

I don't get your point, could you elaborate a bit more please?

[imagico]

If we render a certain tag on ways but not on nodes it communicates to mappers that this tag is supposed to be used on ways but not on nodes. Since 80 percent of the uses of power=portal are on nodes that would in this case mean steering mappers to massively change their mapping behavior. We do not want to do that.

[flacombe]

According to https://wiki.openstreetmap.org/wiki/Tag:power%3Dportal portals can be mapped on both nodes and ways.
Nodes approach is simpler and allow mapping at first sight while mapping is more accurate with ways
=> https://wiki.openstreetmap.org/wiki/File:Power_substation_portal.jpg is better as a way.

I spent weeks to move from nodes power=portal to power=portal ways + power=insulator on anchor points. It's a long term work.

On the other hand it's not desirable to make mappers think portals are only available on nodes by render them without ways, are you?

[pnorman]

I'm looking at this, I see two reviews requesting changes and a number comments. Is there a route forward for this PR?

[jeisenbe]

It does not appear that we can get a good rendering for both ways and nodes. I would be willing to render the symbol only on nodes, but I don't know if @flacombe would support this idea - it appears he is in favor of mapping these features as ways in many cases.

[flacombe]

Hi
As mapping portals as ways is more valuable than as points (you get the actual length of portal with a way), i'd be in favour of rendering both nodes and ways.
Nodes will remain nodes as proposed process to convert them as ways isn't applicable to osm-carto.

Rendering nodes only may encourage to convert existing ways as nodes and it's not a really good thing to do.

All the best

[jeisenbe]

As mapping portals as ways is more valuable than as points (you get the actual length of portal with a way), i'd be in favour of rendering both nodes and ways.

Do you have any new cartographic ideas for rendering these features when mapped as ways?

[jeisenbe]

I'm closing this PR since it has merge conflicts and will not work in the current format.

However, it's possible that a new PR would be accepted which renders the same symbol for power=portal nodes and also for power=insulator nodes which are members of a power=portal way: see previous comments (#3464 (comment) but also #3464 (comment))

That would be a way to render both nodes and ways (at least when the ways intersect a power=insulator node) which might be acceptable.