inheritance and colors

[Landwirt]

I use a custom style to draw areas like landuse=* and natural=* with a border of 1px. To not add line attribues to every rule I added rules like this to the stylesheet:

<rule>
    <condition k="landuse" />
    <line width="1" />
</rule>

This works insofar as the landuse areas have a thin border then - or so it seems. The border is only visible when selecting the area. There is also a visible effect when the area is part of a multipolygon - when zooming in and out the border color changes randomly.
So to set a proper color for the border you have to add a line attribute again to every rule making the above approach rather useless.

Enhancement request(s):

• add a color attribute
  
• add a default color to every rule via the new attribute or by using line and area attributes with colour properties
  
• additional: use "color" instead of "colour"

Examples:

<rule>
   <condition k="landuse" v="farm"/>
   <color value="farm#C1A764"/>
</rule>
<rule>
   <condition k="landuse" v="farm"/>
   <color value="farm#C1A764"/>
   <line width="1" colour="scrub#007000"/>
</rule>

<rule>
   <condition k="amenity" v="school"/>
   <color value="building#cb9999"/>
   <area colour="amenity_light#f7efb7"/>
</rule>
<rule>
   <condition k="amenity" v="school"/>
   <line colour="building#cb9999"/>
   <area colour="amenity_light#f7efb7"/>
</rule>

[stoecker]

I do not fully understand your problem. But generally when you have conflicting attributes then you need to assign priorities to them or you will get random results.

[Landwirt]

Ok, some steps to reproduce: the default line width for area borders seems to be 2-3 pixel, so add <line width="3" /> to one or more area rules and compare it with the standard style. Both styles should look the same, but they don't - regardless of the priority.
When the areas with the modified style are part of a multipolygon, you can see that the border color changes while moving and zooming around in the view.

[ulfl]

First of all, your report is pretty confusing, first you're talking about line widths, then about colours.

Second: We're using british english throughout OSM, so colour is probably the better key name.

Third: Please don't start with multipolygons to check the rule things. The multipolygons have a complicated implementation and may contain bugs unrelated to the rules you are trying. Might be a much better idea to start with lines/areas to get things straight and after that's ok have a look at the multipolygons.

The main point I understood was to have a sort of cascading elemstyles.xml. I was also thinking about this for a while. Unfortunately, the required changes would mean a lot of development effort, so please don't expect any changes here soon.

[landwirt@…]

Replying to ulfl:

First of all, your report is pretty confusing, first you're talking about line widths, then about colours.

Second: We're using british english throughout OSM, so colour is probably the better key name.

Everywhere in josm I see "color" used except for this particular style property. Just wanted to note ... ignore.

Third: Please don't start with multipolygons to check the rule things. The multipolygons have a complicated implementation and may contain bugs unrelated to the rules you are trying. Might be a much better idea to start with lines/areas to get things straight and after that's ok have a look at the multipolygons.

The multipolygon was just an example, because there is apparently a connection to this problem.

The main point I understood was to have a sort of cascading elemstyles.xml. I was also thinking about this for a while. Unfortunately, the required changes would mean a lot of development effort, so please don't expect any changes here soon.

Well, I add a patch ... for the color problem at least, seems to be a minor problem at all.

[Landwirt]

fix missing border colors

[stoecker]

Yes. colour is old style, but you know - backwards compatibility.

Applied in r1501.

[landwirt@…]

With the recent mappaint changes the bug came back. The added patch isn't the solution, but it fixes the problem for me and should give you a hint where to look for it.

[stoecker]

Still an issue? If yes, please provide an example again.

[Landwirt]

style with bug

[anonymous]

Load the attached example in josm, load some data with landuse, natural and/or building areas. See what happens with the border colors when you zoom in and out.

[stoecker]

Load this additional to internal style or exclusive?

[anonymous]

Well, with internal styles the visual effect of the bug is a bit more colorful. Without the internal styles the lines are all gray, but some polygons (landuse/natural/building) disappear when zooming ... black border colors on black background.

[stoecker]

Display is ok

[stoecker]

Moved display a bit and got this

[stoecker]

Do you mean this:

to

This again seems to be one of the strange java painting bugs which probably are related to clipping at the borders.

[Landwirt]

No, not really what I meant. This bug is about the fact that border colors can become null. JOSM picks a random color then. Perhaps if the patch I attached 5 months ago doesn't give a clue then test the following. It will add an assert at the position where the line color can become null.

Index: src/org/openstreetmap/josm/data/osm/visitor/paint/MapPaintVisitor.java
===================================================================
--- src/org/openstreetmap/josm/data/osm/visitor/paint/MapPaintVisitor.java	(revision 3304)
+++ src/org/openstreetmap/josm/data/osm/visitor/paint/MapPaintVisitor.java	(working copy)
@@ -17,6 +17,8 @@
 import java.util.Comparator;
 import java.util.LinkedList;
 
+import junit.framework.Assert;
+
 import org.openstreetmap.josm.Main;
 import org.openstreetmap.josm.data.Bounds;
 import org.openstreetmap.josm.data.coor.EastNorth;
@@ -189,6 +191,10 @@
                     putError(w, tr("Area style way is not closed."), true);
                 }
             }
+
+            LineElemStyle lineStyle = new LineElemStyle((LineElemStyle) areaStyle.getLineStyle());
+            Assert.assertNull(lineStyle.color);
+
             areaStyle.getLineStyle().paintPrimitive(w, paintSettings, painter, data.isSelected(w), false);
         }
     }

Try ​http://www.openstreetmap.org/?lat=54.07231&lon=11.97897&zoom=16 for example to trigger the assert.

[stoecker]

Fix in r3319.