Overlapping transparent polylines produce darker regions

[eddiemuc]

It seems that drawing polylines (e.g. Routes) with VTM with a certain thickness and a semi-transparent color leads to "darker edges" when those line segments are overlapping on polyline points. This effect is also visible when zooming out.

Update: Also "spikes" appear with thick lines at small zooms.

Some screenshots:

Screenshot zoomed a bit above the polyline:

Screenshot close to polyline:

More details and code to reproduce issue can be found on this PR: #1081

[devemux86]

Also "spikes" appear with thick lines at small zooms.

[devemux86]

@eddiemuc playing with the OpenGL calls, but it needs more work and tests:

[eddiemuc]

Very impressive! How did you do it?

Two comments:

• do you have any idea yet why one of the "turns" of the polyline is a "spike" while the others are "flat"?
• comparing with Google Maps: it would be ok if lines really crossing each other create a "darker" pattern IMHO. Only on the "turns" this should not happen. See below an example screenshot from GMaps for same polyline:

[charlenni]

A good article to this problem could be found here. Interesting are the diagrams where you could see, that your double drawing take place, when two of the segments are drawn on top of each other.

[devemux86]

@charlenni thanks, this is a very interesting document.

The lines certainly need more work at the corners.

[devemux86]

Very impressive! How did you do it?

@eddiemuc I tested this code in LineBucket.java#L643.

if (!Color.isOpaque(line.color)) {
    gl.depthMask(true);
    gl.clear(GL.DEPTH_BUFFER_BIT);
    GLState.test(true, false);
}

[fm-sys]

comparing with Google Maps: it would be ok if lines really crossing each other create a "darker" pattern IMHO. Only on the "turns" this should not happen.

IMHO this is not necessary. Just because Google does it, it doesn't have to be good. If it's easier to never create the darker pattern we should go that way. But no strong preference, both is fine for me...

BTW, thanks @devemux86 for looking into this issue!

[charlenni]

It isn't because of Google having it this way (btw. Mapbox too), it is, because it is a bug. There shouldn't any of this dark parts at the edges. And the spike is also a problem, because it isn't the same edge form as the rest.

[eddiemuc]

comparing with Google Maps: it would be ok if lines really crossing each other create a "darker" pattern IMHO. Only on the "turns" this should not happen.

IMHO this is not necessary. Just because Google does it, it doesn't have to be good. If it's easier to never create the darker pattern we should go that way. But no strong preference, both is fine for me...

BTW, thanks @devemux86 for looking into this issue!

That's correct. What I rather meant to say is: if it is for any reason much easier implementation-wise to just fix the dark pattern in turns (and not in crossings) then that would also be acceptable for us (because we accept it in GMaps as well). I wanted to lift the "implementation burden" a bit, that's all. Sorry for the confusion.

[devemux86]

If anyone knows OpenGL and wants to help, I am happy to review pull requests.

For now I can push something like the above solution, probably via an option.

---

To avoid the spikes at zoom, use the pointReduction(false) in the Style.

Corners to be round instead of miter or bevel, needs work in LineBucket.
(the bevel currently is applied with a condition)

[devemux86]

@eddiemuc

I merged #1084 in the latest snapshot, please test it in your implementation.

As it is a core change, it can be enabled via Parameters.TRANSPARENT_LINES.

[eddiemuc]

@eddiemuc

I merged #1084 in the latest snapshot, please test it in your implementation.

As it is a core change, it can be enabled via Parameters.TRANSPARENT_LINES.

Looks MUCH better with the fix applied:

But the "spike" remains, even when I set pointReduction(false)

Also zooming out leaves the polyline visible:

[devemux86]

Also zooming out leaves the polyline visible:

The layers are always visible unless we hide them.

The pointReduction disables or not the default reduction of points when we zoom out.
When the line is too thick, the point reduction can show spikes around some line areas.

You can try without setting it, which is the default and see if it works better in your case.

But the "spike" remains

Do you mean the line joins at the corners, this is different and needs new implementation.
Currently the best we can do is to force the bevel join in more corners:

Corners to be round instead of miter or bevel, needs work in LineBucket.
(the bevel currently is applied with a condition)

[eddiemuc]

Already as is your change is a huge improvement! Thanks a lot!

The pointReduction disables or not the default reduction of points when we zoom out. When the line is too thick, the point reduction can show spikes around some line areas.

You can try without setting it, which is the default and see if it works better in your case.

When I leave point reduction on then at a certain zoom level the polyline "thing" vanishes. That's a good thing. But the "vanish" zoom level is too far out. Is there any way to have more control over this?

The most "zoomed out" level where polyline thingy is still visible:

One more "zoomed-out" level where polyline finally vanishes:

But the "spike" remains

Do you mean the line joins at the corners, this is different and needs new implementation. Currently the best we can do is to force the bevel join in more corners:

I mean the spike circled in red in following screenshot. But this is IMHO not the most pressing issue, I would consider this a minor thing.

[devemux86]

Try without using the point reduction call, that is leave it on (as default).

Otherwise you can hide the layer at the required zoom level.

[eddiemuc]

Try without using the point reduction call, that is leave it on (as default).

I looked into the underlying code of pointReduction and found that the flag just sets a default constant drop distance to the line bucket. Experimenting with this I found that the zooming problem could be solved in a great way if the drop distance could be set directly (as a float) on the Style object. I prepared PR #1085 for this and would be glad if you would consider adding such a feature.

[eddiemuc]

Sorry, PR #1085 (I updated the previous comment)

[devemux86]

I prepared PR #1085 for this and would be glad if you would consider adding such a feature.

@eddiemuc thanks! 👍

[eddiemuc]

With PRs #1084 and #1085 merged I would consider this issue solved. Thanks a lot!

@devemux86 : we would like to include these fixes into c:geo (but don't want to use the snapshots for official c:geo builds). There was no release since the two PRs were merged, so we considered using jitpack.io. However, we noticed that since 0.19.0 both mapsforge and vtm seem not to build on jitpack.io any more (see https://jitpack.io/#mapsforge/mapsforge for mapsforge and https://jitpack.io/#mapsforge/vtm for vtm). Do you know the reason for this? Is there any other way to link to a stable build of e.g. 8d43af4 (current master's head)

[devemux86]

@eddiemuc thanks for your contributions!

Does JitPack require special rules?
I just update Gradle when needed and make sure that it builds successfully and publish also works.

You can use the snapshots, the latest or a fixed version.
I always use the snapshots, releases are just snapshots with a label.

[eddiemuc]

Does JitPack require special rules? I just update Gradle when needed and make sure that it builds successfully and publish also works.

Apparently jitpack requires a project to explicitely specify the Java version used for compile if it is not Java 8. See https://jitpack.io/docs/BUILDING/#java-version. This is why the build currently fails (see https://jitpack.io/com/github/mapsforge/vtm/0.20.0/build.log).

However, sorry for that, I somehow thought that mapsforge and vtm support jitpack (because we used it in the past :-)).

You can use the snapshots, the latest or a fixed version. I always use the snapshots, releases are just snapshots with a label.

I found just one snapshot release here: https://oss.sonatype.org/#nexus-search;quick~vtm
Wouldn't that one be overwritten any time a new commit is brought to vtm master? Sorry if this is a dumb question.

[devemux86]

@eddiemuc the snapshot builds and versions are here:
https://oss.sonatype.org/content/repositories/snapshots/org/mapsforge/

[devemux86]

@eddiemuc probably instead of:

implementation 'org.mapsforge:vtm:master-SNAPSHOT'

could use for example:

implementation 'org.mapsforge:vtm:master-20231227.121602-914'

[devemux86]

Wouldn't that one be overwritten any time a new commit is brought to vtm master?

This only happens when using:

implementation 'org.mapsforge:vtm:master-SNAPSHOT'

[eddiemuc]

implementation 'org.mapsforge:vtm:master-20231227.121602-914'

There seems to be no consistency across the different sub-libs of VTM with regards to such snapshot version numbers, or I am doing something wrong here again?

E.g. using above version master-20231227.121602-914 gives me:

Using one earlier version master-20231227.121602-913 gives me:

[devemux86]

@eddiemuc indeed Maven publishes independently the modules, so need to use a fixed version for each one.

[eddiemuc]

@eddiemuc indeed Maven publishes independently the modules, so need to use a fixed version for each one.

Ok, thanks! Using different versions it worked out. It's a bit tricky though.

[devemux86]

I added jitpack.yml in Mapsforge and VTM in jitpack branch and they seem to build successfully.

@eddiemuc can you test if they work in c:geo?

https://jitpack.io/#mapsforge/mapsforge/jitpack-SNAPSHOT
https://jitpack.io/#mapsforge/vtm/jitpack-SNAPSHOT

[eddiemuc]

I added jitpack.yml in Mapsforge and VTM in jitpack branch and they seem to build successfully.

@eddiemuc can you test if they work in c:geo?

https://jitpack.io/#mapsforge/mapsforge/jitpack-SNAPSHOT https://jitpack.io/#mapsforge/vtm/jitpack-SNAPSHOT

Works fine!

[devemux86]

@eddiemuc thanks for the confirmation!

I merged the JitPack support in both Mapsforge and VTM repositories.

[eddiemuc]

@eddiemuc thanks for the confirmation!

I merged the JitPack support in both Mapsforge and VTM repositories.

Thanks a lot! I will now link this version to our master build (until VTM release 0.21.0 comes out :-))