[PATCH] Possibility to specify custom MapPaintSettings for MapCSS rendering.

[zkir]

Problem

The UrbanEye3D plugin provides a 3D rendering of OSM data. To display the ground, it uses JOSM's RenderingHelper and StyledMapRenderer to render a 2D map image(s) with a custom MapCSS style.

The problem is, that the global JOSM preferences from OSM Data tab (e.g. "Draw oneway arrows", "DrawSegment numbers", mappaint.shownames ), are affecting rendering in 3D window also.
This is not a desired behaviour, and it looks quite surprising. Style for the groundplane in 3D window was designed to look "realistic", and all titles and arrows were excluded from it.
However, they reappear if the settings in question are activated. (see screenshots).

Proposed Solution

The proposed solution introduces a mechanism to create and use a "neutral" set of MapPaintSettings for the rendering process, ensuring it is independent of global user preferences.
The patch is composed of three main changes:

1. In MapPaintSettings.java:
   • A new static factory method, createNeutralSettings(), is introduced. This method returns a settings object specifically configured to be non-intrusive for realistic rendering. It disables settings that add symbolic cartographic elements (e.g., showDirectionArrow=false, showOnewayArrow=false, showNamesDistance=0), while inheriting other defaults (like colors and node sizes) from the global INSTANCE.

2. In StyledMapRenderer.java:
   • A new constructor is added that accepts a MapPaintSettings object.
   • The getSettings() method is updated to use these custom settings if they are provided. If no custom settings are passed, it falls back to the global MapPaintSettings.INSTANCE to maintain existing behavior.

3. In RenderingHelper.java:
   • The class is updated to take advantage of the new mechanism. It now instantiates StyledMapRenderer with the neutral settings provided by MapPaintSettings.createNeutralSettings().

Performance and memory impact

• No negative performance impact. No addtional operations or activites are added.
• Additional instance of MapPaintSettings is created, but only if RenderingHelper is used. In normal scenario there is no additional memory consumption.

[stoecker]

Whoa. Is there no better way than creating a function with a zillion arguments? setXXX() instead?

[stoecker]

BTW: That function will break all the time and thus is not a good interface for a plugin.

[zkir]

Patch, version 2, much shorter.

[zkir]

OK, it was not the best idea.
How about this variant?

It is much shorter and more close to the point: non relevant settings are overridden.

If you approve creation of setters for only fields in question (7 out of 27, which is strange a bit for me), I will do that and move the fabric method directly to the RenderingHelper class.

If I am missing something obvious, please advise.

[stoecker]

I'm not totally sure what you're asking, but if you ask if creating setXXX()-functions is ok, then yes. I don't very much like them, as they clutter the code, but it is the Java way and where needed we should add them.

If not needed, the current patch looks fine to me. No issue with that. Additional functions can always be added in future :-)

[zkir]

OK, if this version is fine with you, it's also OK with me.
Let's keep it.