Openstreetmap-carto: 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 [email protected] and [email protected] (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 [email protected] and [email protected] (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 [e-mail] 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:

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.

[daniel-callejas-sevilla]

I'm a humble user of OSM who wants to see pipelines rendered. This issue is labeled "help wanted". How can I help?

[kocio-pl]

First thing - do you have our Docker environment container running? The basic instructions are here:

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

[daniel-callejas-sevilla]

Apologies for polluting here. The Docker environment fails to build at step node-pre-gyp install --fallback-to-build.

[jeisenbe]

Is your problem related to issue #3907?

What is your operating system and version of Docker and Docker-compose?

[jidanni]

Yes one would expect a massive

bridge  aqueduct
diameter    2000
location    overhead
man_made    pipeline
substance   water

to be somewhere on the map. All that is currently left are the steps leading up to it, giving the impression that it was destroyed.

Such giant pipelines over rivers would be important escape routes in cases of disaster and need to be on the map soon.

[HolgerJeromin]

Such giant pipelines over rivers would be important escape routes in cases of disaster

Many / all of those are not public accessible. This osm way lacks a footway tag probably for a reason.

You can not escape velociraptors on pipelines like this one:
https://s3.amazonaws.com/american-rivers-website/wp-content/uploads/2016/02/24211115/oil-pipeline-above-river-credit-Travis-flickrCC.jpg

and need to be on the map soon.

This style is no live saving device!

[javbw]

Javbw

On Dec 19, 2019, at 6:54 PM, Holger Jeromin [e-mail] wrote:

Many / all of those are not public accessible. This osm way lacks a footway tag probably for a reason.

While I agree that:

• these don’t have a footway that is accessible (fence blocks to the narrow service “path” on top and shouldn’t be tagged)

• OSM should be used as a guide in an emergency,

• such informal “evacuation sites” shouldn’t me mapped as such

But these pipeline bridges are landmarks that people recognize - locals would go to them in a tsunami/disaster as a last resort because the approaches are often much higher than the surrounding land.

For the pure landmark value (whatever importance is derived from that), these pipeline “bridges” should be mapped in some manner.

I would suggest the person use man_made=bridge on the area (to map the area the bridge occupies, which will be rendered) but the pipeline ways should have a black casing (if possible), similar to all other ways commonly tagged as a bridge.

Javbw.

[jidanni]

(As a quick check to see if this bug still exists, one can look at the a random section of the Trans Alaska Pipeline. Even though on imagery the road is as big as the pipeline, but alas the latter is not rendered, not even at highest zoom.) (One would think the service road might give us a hint where the pipeline is. But it goes beyond it and ends at the river.)

[jidanni]

Better footing on this massive water pipeline / aqueduct / bridge tagged as above but not rendered.

[daniel-callejas-sevilla]

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.

Where can I find the PR with your changes? I'd like to try it in local.

[jeisenbe]

https://github.com/jeisenbe/openstreetmap-carto/tree/pipeline - this is the branch that I was using to test possible renderings for man_made=pipeline, but I did not submit a PR yet.

[jeisenbe]

@daniel-callejas-sevilla were you interested in submitting an PR to add this feature? Do you need any help?

[Adamant36]

@jeisenbe, would the PR be at a mergable point close to where your test branch has it or would it still need any major modification?

[jeisenbe]

It's usable for testing. It would be good to check the rendering in
several different places and look for any potential problems with the
data or rendering.

[Adamant36]

A place in Poland with the pipelines running next to each other. It looks fine from z19-z17, but starts getting iffy after that.

z19

z18

z17

z16

z15

z14

[flacombe]

Easier for me to write than to do, it may be an option to make them disappear or even show like solid lines < z17

[Adamant36]

I think making not display at anything more zoomed out then z17 is probably the answer. If we make them solid lines it would be hard to tell them from other things. They don't look good sooner then z17 by themselves anyway.

Single pipeline z16 (check out the last two parts on the left side. Doesn't look good due to the pipeline doing a little zigzag)

Doesn't look to bad at z15 or z14 if they are straight.
z15

z14

Single pipeline over water at z18. I was looking for a water pipeline over water but couldn't find one.

[jeisenbe]

We show even minor power lines, streams, private driveways and private
footways at z16 or sooner, so it would be strange to limit pipelines
to z17.

[jidanni]

Note these are often thousands of kilometers long structures.
It would be very frustrating needing to zoom in and out hunting for these like a blind man.

[jeisenbe]

these are often thousands of kilometers long structures

Most of the very long pipelines are underground, though I understand
that Alaska and other areas with tundra are exceptions, and there are
some water aqueduct pipelines that are 10s of kilometers long which I
tested.

[Adamant36]

We show even minor power lines, streams, private driveways and private
footways at z16 or sooner, so it would be strange to limit pipelines
to z17.

Yeah, I agree.

[jidanni]

I can thankfully see this underground canal
https://www.openstreetmap.org/way/219361140#map=12/24.1175/120.9406
all the way down to zoom 12.

If you think of it from the point of view of oil companies, they would rather not have the public know about their pipelines.

But from the point of view of environmentalists, it is important to know about pipelines.

I recall opening up great (paper) atlases of the world in the library, and seeing the whole Russian infrastructure, Trans-Siberian pipeline, railroad, highway, all on the same big map. That's what made them great.

[jidanni]

If people are concerned about the Amazon forests, they would like to see where pipelines have got to, not only roads, at the same zoom levels. High voltage power lines too. One look at OSM and people will say "Now there's a map that puts the (vegan) meat on the table!" (Of course with a crowding factor added to keep them from getting too dense.)

[jidanni]

Goo* etc. commercial, and especially government maps, have all kinds of pressures to keep various multinational corporations' stuff off the map. This is where OSM can outshine them.

[jidanni]

Also if you think about it, this is where we can get the most bang for
the buck: well at least for high voltage lines, as they are straight,
one needs only to add their towers from imagery, and connect them with
straight lines. Sure the electric company and governments won't
cooperate by even telling you what the name of the power line is (due to
national security for high voltage infrastructure). But all one needs is
one trip to one tower to read the tower label sign to get the name of
the line. Voila. Line complete. I suppose pipelines are similar.

[Adamant36]

@jeisenbe, any suggestions since its your design and code?

[jeisenbe]

You could try adjusting the different colors for different
substance= values and test if you think they work intuitively or
not. You can also try adjusting the width at the different zoom levels
if you notice any problems.

I would recommend testing in several different real-world locations
where there are a variety of other features mapped nearby

For the initial zoom level, I tried z12 and z14, I believe, and it's
currently set to z14. You could try changing this, but right now it's
the same as power=line and major barriers like barrier=hedge and
barrier=city_wall, which makes sense - an overground pipeline is a
major barrier (can't walk or drive under it), and an overhead pipeline
is a significant landmark like a power line.

But if you have other ideas it would be reasonable to try a different z level.

Treat it like you are the maintainer reviewing the PR, and submit what
you would be willing to approve, if you were making the final
decision.

[javbw]

Just my two cents: it may not be perfect, but it looked decent enough to me at z19 to be implemented.

Javbw

On Jan 14, 2020, at 5:29 PM, Joseph E [e-mail] wrote:

I would recommend testing in several different real-world locations
where there are a variety of other features mapped nearby

[jeisenbe]

@Adamant36 - were you considering opening a PR for this?

[Adamant36]

uuummm, yeah. But it doesn't look good at certain zoom levels and everyone thinks they should still be rendered at those levels. So, that needs to be worked out first.

[jeisenbe]

Remind me, what was the problem with the rendering tests at z16?

[Adamant36]

I don't know. I just thought it could have looked better. Although I don't have an exact, specific problem with it though. We really could just do the PR as is. Since it looks good otherwise and I don't think the problem on z16 (if there even is one) is worth holding it up.

[Adamant36]

@jeisenbe, you want me to do the PR for it?

[jeisenbe]

Yes. Opening a PR will help us get ideas from other contributors.

If you don’t think it is ready yet, then you can add “[WIP]” for now, and
ask for help with the parts that you think need improving.

[pnorman]

If you don’t think it is ready yet, then you can add “[WIP]” for now, and
ask for help with the parts that you think need improving.

It's better to do it as a draft PR if you don't think its ready.