Pipeline should be visible

[Cetusek]

Why are pipelines not rendered? They are good landmarks.

[RobJN]

Above ground pipelines may be landmarks and therefore you could argue that they should be rendered. The underground pipelines shouldn't be rendered as they will confuse the map view.

For a map of pipeline in OSM see http://www.itoworld.com/map/220

[javbw]

If the pipe is tagged overground/overhead/outdoor, why can't it be rendered at, lets say, Zoom level 17 and higher? Zenrin's data in Japan shows pipes at high zoom levels (what Google switches to as you zoom in Japan).

http://goo.gl/maps/853rS

It's for some pretty big pipes.

[matkoniecz]

I am sure that it is a good idea to display pipelines, except underground ones. Note that there are pipeline bridges.

[Cetusek]

Of course I ment overground pipelines. Is there any chance to make them visible?

[matthijsmelissen]

What's the tagging scheme to distinguish between underground/overground?

In the Sahara, pipelines are also important landmarks: http://www.theleader.info/media/images/articles/thumbnails/11784_320x0.jpg They are in fact so visible that some of the used to be tagged in OSM as 'highway=primary' from early low-res satellite imagery!

[Klumbumbus]

What's the tagging scheme to distinguish between underground/overground?

http://wiki.openstreetmap.org/wiki/Key:location

[matkoniecz]

So probably the best solution is to show only ones with location=overground

[Cetusek]

You are right. What should we do to achieve this goal?

[RobJN]

The best way would be to get involved with writing the code (the style-sheets on this github project). In github terminology that means forking the code to your personal space, updating the code, and supplying a "Pull Request" back to this github project. That's all explained on github's help (or just google it) as it's a github process not an OpenStreetMap process.

You may want to watch Andy's workshop at the recent SotM-EU conference. https://www.youtube.com/watch?v=W7La0UXec3A

If you cannot find someone willing to help with this, you will simply have to wait until one of the other members on this github project pick it up. There's quite a back-log so patience will be required.

[Rovastar]

Do we have location as a tag in the db, if not then then it will be trickier too.

I do think we could render these I see the benefit. I suppose the next question is how do we want it to look. We have soooo many different colours and styles for the lines on the map. Any suggestions that do not clash?

[pnorman]

Do we have location as a tag in the db

Don't believe so, which puts this to 3.0+

[matkoniecz]

Maybe dark gray line, wider than barriers? It is a special kind of barrier, so it should be OK to have it similar. With bridge casings for elevated ones (with bridge=*).

[kocio-pl]

Maybe dark gray line, wider than barriers? It is a special kind of barrier, so it should be OK to have it similar. With bridge casings for elevated ones (with bridge=*).

Sounds good for me.

I'm also thinking about segmented line, resembling pipe joinings (rough ASCII sketch):

|——||——||——||——||——|

[javbw]

Maybe With bridge casings for elevated ones (with bridge=*).

I'm also thinking about segmented line, resembling pipe joinings (rough ASCII sketch):

|――||――||――||――||――|

Where I am there are a lot of "pipe bridges" - a buried 1m pipe pops out of the ground, crosses a river, and goes back underground.

Any render that would help people not confuse them with a pedestrian crossable bridge would be wonderful - as they are often near or go over other ways. I know that the routing engines would ignore them, but visually would look like a bridge a person could cross (but are gated off and very dangerous).

Javbw

[kocio-pl]

It looks like Mapnik currently offers only simple line endings - and of course CartoCSS too:

https://github.com/mapnik/mapnik/wiki/LineSymbolizer#linesymbolizer https://www.w3.org/TR/SVG/painting.html#StrokeLinecapProperty https://carto.com/docs/carto-engine/cartocss/properties#line-cap-keyword

[kocio-pl]

I have finally found a way to do it:

The trick was to use image (LinePatternSymbolizer in Mapnik), the same as in the cliff rendering - above rendering is done simply with replacing the SVG file. The only problem was that segments had no space between them, despite the space on both ends. However adding invisible blocks (alpha=0) helped.

Now we can get back to design. What color should be used? What segment length (currently 13 px total, with endings x 1 px), endings size (5x1 px) and the space between segments (1+1=2 px)?

[Tomasz-W]

Surely it's too strong at the moment. It also is too sililar to aerialway=* rendering, eg. https://www.openstreetmap.org/#map=16/46.2161/6.7975

[kocio-pl]

The spaces are too small? What's your proposition?

All the lines are similar and it's just the convention. I believe the context will make it clear - aerialways consist of short straight lines and have stations on both ends, pipelines tend to be long and curved.

[turnsole80]

I like it. If you can get it to work, i'll carry the same ideas to carry over to #1999 , because right now i'm drawing a blank there.

Colour wise, i'd go with that generic grey you use for things like bunkers, etc

[eigenwillig]

@kocio-pl Could you please publish the code with LinePatternSymbolizer here?

[kocio-pl]

Sorry but no, I lack the time for the project currently, I focus on next release now. But anyone can copy the code for a cliff rendering and tune it using my SVG file as a base (it can be adjusted too). Anybody willing to make the PR?

[kocio-pl]

I wanted to wait a bit before some colors for borders are decided (especially country borders), but it seems to be resolved now, so the question is what color should be used for showing pipelines?

[kocio-pl]

I guess z14 would be good (the same as power lines) probably using some dark purple - grey is too generic and may resemble railways, while pipelines are much less dense, so it should not take too much attention anyway (dense items should be muted, sparse can be brighter).

[jeisenbe]

@flacombe this would be good to work on prior to #3180 or #3179.

[IgorEliezer]

Now we can get back to design. What color should be used? What segment length (currently 13 px total, with endings x 1 px), endings size (5x1 px) and the space between segments (1+1=2 px)?

Could the segment length be longer, like on the map below?

(OSM: https://www.openstreetmap.org/#map=18/-23.81791/-46.50558)

I just think it will be a bit too dense in places where there are packs of pipelines running close together, such as this: https://www.openstreetmap.org/#map=18/-23.86584/-46.45869.

[jeisenbe]

I agree with the comment above https://github.com/gravitystorm/openstreetmap-carto/issues/640#issuecomment-46413344 - could be similar to barriers, but wider (at least at high zoom levels). The dashed / segmented idea is worth testing, but perhaps suggests an underground pipeline?

I checked a few map legends which I've previously downloaded. The French, British and Norwegian maps did not list this as a feature.

The Australian topo maps showed this:

Old USGS topo maps showed this:

Newer USGS legend:

Since those styles also show contour lines, they tend to show many features in black. We can consider using gray or another less prominent color instead, and we have the complication of different zoom levels to consider, and rendering many more features, including dashed gray lines for some types of underground / under contruction railways.

[kocio-pl]

I'm glad to see the discussion here. We can test bold light gray lines with longer segments, what I think is important is to keep the T-shaped spaces between segments. Is anynody interested in making the sketch?

The other important thing is if we should render underground pipelines - my experience with cities shows that we should not render underground objects with some exceptions (like roads) to avoid clutter,

[jeisenbe]

It's also possible to get the rendering just using 2 lines with line-dash-array, like is done with aerialways, eg:

      line/line-width: 1;
      line/line-join: round;
      line/line-cap: round;
      line/line-color: #707070;
      line/line-dasharray: 0,1,24,1;

      dash/line-width: 3;
      dash/line-join: round;
      dash/line-color: #707070;
      dash/line-dasharray: 0,1,1,22,1,1; 
      dash/line-clip: false;

(Just an example, the colors and lengths and widths should all be adjusted)

line-dasharray: 0,1,24,1; means "do not render the line for the first 1 pixel length, then render 24 pixels, then do not render for 1 pixels".

line-dasharray: 0,1,1,22,1,1; means 1 pixel off, then 1 on, then 22 off, then 1 on, then 1 off - since this is 3 pixels wide, it makes the dashes / slashes at each end of the 24 pixel long line (above).

Example (pipeline with many aerialways and railways):

Could probably be rendered in the aerialways or bridge layer, since most location=overground pipelines are elevated above ground level.

According taginfo, there are 38,187 ways with man_made=pipeline + location=overground. There are also 3300 with bridge=yes., and on overpass there are 2569 ways with location=overhead which could be rendered.

[kocio-pl]

Great! Thanks, Joseph, I think it's more or less ready to be deployed in this form.

It looks decent for me, joinings are easily visible and the whole look is distinctive in comparison with other line features, even color is OK. What I also like is that you have found a way to make it as a CartoCSS code, which is much shorter and easier to control than images, and that was my aim from the beginning, but I failed to achieve it.

There are probably some bridges with pipelines, I think we should render them similar to the roads. Another detail to check would be name or ref labels.

[jeisenbe]

You are welcome. I have a number of PRs open, so I hope someone else can continue to work on this one, but I look forward to reviewing it.

[kocio-pl]

@Adamant36 Would you like to try that?

[flacombe]

I'm interested to give it a try if someone can help me to fix the install of Kosmtik on Debian buster with npm 6.11.3 and njs 10.16.3

Following errors are raised when using npm install kosmtik

node-pre-gyp ERR! Tried to download(403): https://mapbox-node-binary.s3.amazonaws.com/mapnik/v3.7.2/node-v64-linux-x64-Release.tar.gz 
node-pre-gyp ERR! Pre-built binaries not found for mapnik@3.7.2 and node@10.16.3 (node-v64 ABI, glibc) (falling back to source compile with node-gyp) 
node-pre-gyp ERR! Tried to download(undefined): https://mapbox-node-binary.s3.amazonaws.com/mapnik/v3.7.2/node-v64-linux-x64-Release.tar.gz 
node-pre-gyp ERR! Pre-built binaries not found for mapnik@3.7.2 and node@10.16.3 (node-v64 ABI, glibc) (falling back to source compile with node-gyp)

@jeisenbe did you provide the same dasharrays you use in the demo picturs shown before in https://github.com/gravitystorm/openstreetmap-carto/issues/640#issuecomment-530789947 ?

[kocio-pl]

Did you try our Docker environment?

[jeisenbe]

dasharrays you use in the demo

Yes, it was the same. I based the rest of the CSS code off of the current rendering for aerialways, in aerialways.mss

[flacombe]

Did you try our Docker environment?

Unfortunately, don't have enough time to handle Docker for now Using Kosmtik sounds lighter to me to test this

Yes, it was the same.

Great

[kocio-pl]

I'm not sure if you know what Docker is? It's not an application similar to Kosmtik, just a way to run ready-made virtual environments without speed overhead (at least on Linux). Our environment runs Kosmtik bypassing native npm/njs hell and allows easy import of data - see here for a quick start guide:

https://github.com/gravitystorm/openstreetmap-carto/blob/master/DOCKER.md#quick-start

Does it help you?

[jeisenbe]

@flacombe - I highly recommend trying Docker, it works quite easily, if you have a good internet connection and a little time.

[jeisenbe]

OK, I said I wasn't going to work on this issue, but then I did.

https://www.openstreetmap.org/#map=17/54.74094/20.32948.png z19 z18 z17

I was surprised that it is hard to find long, straight pipelines. These turn out to be mainly underground (except in Alaska), so most of the rendered pipelines are only a few hundred meters or few kilometers long. Many are water pipelines associated with hydroelectric facilities or water aquaducts, though there are also many oil and gas pipelines connecting industrial facilities and ports.

котельная - https://www.openstreetmap.org/#map=15/54.6602/21.0624

I checked if we could try usage=transmission vs usage=distribution to render pipelines earlier or later, but these tags are not very common yet, especially together with location=overground/overhead which are the ones that will render.

I've found that at high zoom levels would might be able to render a different center line color depending on the substance=* - e.g. blue for water, something different for natural gas or oil.

Any ideas on what colors would be appropriate for gas and oil pipelines?

https://www.openstreetmap.org/#map=19/53.19025/-3.84260 z19 water pipelines

z18 water

z16

z14

z13 - probably the lowest possible level, since we don't have a way to distinguish short and long pipelines, though z14 may be the best limit. z12 would be fine for usage=transmission, if this were actually a common tag.

[jeisenbe]

Test with very short pipelines, substance=gas (rendered in #d0d0d0):

https://www.openstreetmap.org/#map=18/53.23763/-3.05405

[IgorEliezer]

Any ideas on what colors would be appropriate for gas and oil pipelines?

Based on pipe color code standards, which may vary a bit depending on the region:

• blue = water
• green = sewage
• yellow = gas
• orange = corrosive fluids
• brown = combustible fluids

---

If you want to test overground pipelines:

• Water penstock (8 lines): https://www.openstreetmap.org/#map=18/-23.86580/-46.45821
• Gas (4 lines): https://www.openstreetmap.org/#map=17/-23.85063/-46.50240

[kocio-pl]

Another idea might be to use some dots inside, since it's hollow. I don't know however if it's technically possible or how to use it exactly.

In general this solution looks quite good, I think it's better than my original idea.

[javbw]

I am wondering what the "bridge" rendering is for pipelines. Will it use a similar dark gray casing?

The renderings so far look really great.

There are a lot of pipeline bridges in Japan - a large structure With an integrated pipeline supported for the distance where it crosses a river above-ground (and then disappears back underground).

I map a lot of pipeline bridges, which are more than just "a pipe that happens to cross a stream" - there are plenty of those too, but there are also plenty of these large "pipeline bridges" as well.

For all the exposed hydroelectric pipelines on mountainsides, the current renderings will look great.

Keep up the great work!

Javbw

[kocio-pl]

Looking at https://wiki.openstreetmap.org/wiki/Key:substance and https://taginfo.openstreetmap.org/tags/man_made=pipeline#combinations it looks like the most popular substances are:

• 14.78% | substance=gas
• 11.29% | substance=water
• 6.97% | substance=oil

with all the others below 1000 usage limit (or unused), which means (41.61%-33.14%) 8.47% combined. It might be good to test even the low usage to know what can be needed in practice.

There is also https://taginfo.openstreetmap.org/keys/pipeline#values with some values like water, aqueduct, sewer,␣water, heating_pipeline or sewer, but all below 1k.

There is also usage defined on the wiki, but only 5.34% of cases are defined, with not a single one above 1k limit.

[jeisenbe]

@kocio-pl, substance=gas, substance=water and substance=oil are by far the most common, making up 80% of all uses of the key, so these are the 3 that have been tried so far. There are 12,700 pipeline ways with substance=gas, water or oil and location=overground or overhead.

The next is substance=heat but this isn't recommended on the wiki (should be steam or hot_water, but these are still rare: 640 ways overground or overhead combined). After that is substance=sewage but this is still under 2000 uses overall, and only 238 are location=overground/overhead, so probably rendering the top 3 is enough.

The main benefit is rendering substance=water so that water pipelines are logically connected to canals and water tunnels.

type=water is also still quite common, with 7000 uses, but this has been replaced by substance=water, so we should not render it.

@IgorEliezer - thank you.

• blue = water

This one is logical and the rendering is intuitive

• green = sewage

If this tagging becomes more common we could consider it later, perhaps a blue-green hue?

yellow = gas

I tried this, but it looks too similar to secondary roads, I'm afraid. That's why I tried #d0d0d0 above

orange = corrosive fluids

Not very common (less than 200 of the top two, substance=ammonia and substance=chemical). And orange would also look similar to primary or trunk roads.

brown = combustible fluids

For this substance=oil is quite common. I'll need to find some different locations to test this, as well as darker gray (maybe 999), my first thought.

[jeisenbe]

There are a lot of pipeline bridges in Japan - a large structure With an integrated pipeline supported for the distance where it crosses a river above-ground

I've included bridge=yes and =aqueduct as an equivalent to location=overhead in the code, so they will render.

Currently the rendering tests have been done with all pipelines above bridges and below aerialways (actually in the aerialways layer, but rendered underneath them - they could also go in the bridges layer so that they could render below bridges that have a higher layer tag, but this would be more complicated), so like bridges they go above all roads and waterways, since this seems to match actual practice: if they are overground/overhead they have to go above roads, or else they should be location=underground for that section.

I don't think it would be easy to make an intuitive pipeline-bridge rendering, but it is not necessary: these are not bridges which you can walk across, unlike a railway, road or waterway bridge.

[javbw]

On Oct 30, 2019, at 4:24 PM, Joseph E notifications@github.com wrote:

I don't think it would be easy to make an intuitive pipeline-bridge rendering, but it is not necessary: these are not bridges which you can walk across, unlike a railway, road or waterway bridge.

Perhaps the rendering is unneeded, but when you have a large bridge structure (long arching Steel supports and pier structures similar to a regular bridge, but the load it carries is a pipeline, it seems like it should be rendered similarly to other ways that have bridge=* also tagged on it.

I’m not talking about an overhead pipe on some supports that happens to over a stream, not a long section of plain pipeline that crosses a river, but a very large and elaborate structure that crosses a river that contains within it a pipeline.

https://www.openstreetmap.org/way/304370909 here is an example. It might be mapped incorrectly, but you can see the size of the structure I am talking about in imagery.

If you feel that rendering a bridge outline is unnecessary, okay. But in the same way a bridge carries a road bed, a set of rails, or concrete footway, these large structures also carry pipeline across a difficult crossing, and are more than a mere tunnel that happens to be above ground or overhead.

I think you have done a good job with the regular pipe rendering, and if it is too difficult to implement, that’s okay - but I do think there is a reason to have a “bridge” version of pipeline.

Javbw.

[jeisenbe]

rendering a bridge outline

The physical outline of a bridge structure is rendered from the tag man_made=bridge, which is mapped as an area. This tag is also appropriate for pipeline bridges, though it's not exactly what you were asking for.

[javbw]

the tag man_made=bridge, which is mapped as an area. This tag is also appropriate for pipeline bridges, though it's not exactly what you were asking for.

I was thinking the same thing, and I guess it's the solution for now, but there are a couple dozen pipe bridges like this in my region of Japan alone (Whereas I can't remember seeing one before in California), so eventually a simple way-only rendering for a pipelines+bridge=yes should be developed if it's not impossible or ruins the current rendering ('cause it is a great rendering for a pipeline).

Thanks for the replies.

Javbw

[jeisenbe]

Tests with different colors for the main types of substance= - water, gas and oil, as well as null:

Dark brown for oil, gray for gas, water-color for water: ![Uploading z17-pipeline-colors-brown-blue-gray.png…]()

Dark gray for oil, light gray for gas and water same:

[kocio-pl]

I think brown for oil makes more sense and makes bigger visual difference (another color). Name is another property worth showing (as on the examples).

Is this ready for deployment in your opinion? I see no missing pieces now.