Modify

Opened 3 years ago

Closed 4 months ago

Last modified 4 months ago

#10529 closed enhancement (fixed)

Visually deprecate old multipolygon styles

Reported by: stoecker Owned by: team
Priority: major Milestone: 17.04
Component: Core Version:
Keywords: multipolygon Cc: skyper, Klumbumbus, pnorman

Description (last modified by stoecker)

Currently we still support old styles of multipolygon see ElemStyles.java. I think it is time to somehow deprecate them more than we do now.

  • So probably first is to disable the VERY old method of inner=outer completely.
  • second is to never display outer styles for complete multipolygon anymore.
  • Third is probably to visually mark the no-style on multipolygons as bad for these cases, where the outers have one common style.

Probably instead of removing code, we can turn it of with a default-false variable?

Attachments (7)

oldMP.png (9.9 KB) - added by Klumbumbus 3 years ago.
unclosed.png (8.6 KB) - added by Klumbumbus 3 years ago.
error_area.png (11.4 KB) - added by Klumbumbus 3 years ago.
red_diagonal.png (162 bytes) - added by Klumbumbus 3 years ago.
red_diagonal5.png (164 bytes) - added by Klumbumbus 3 years ago.
hiding untagged inners.png (31.7 KB) - added by Klumbumbus 3 years ago.
diagonal_wider.png (436 bytes) - added by Klumbumbus 3 years ago.

Download all attachments as: .zip

Change History (95)

comment:1 Changed 3 years ago by stoecker

According to trunk/data_nodist/multipolygon.osm type 1 (very old) is anyway broken :-)

comment:2 Changed 3 years ago by stoecker

Cases 07/01 and 06/03 don't even create a warning ATM. That's broken.

comment:3 Changed 3 years ago by stoecker

Unclosed areas (multipolygon or not) should no longer be displayed as proper area. They should be marked somehow.

With proper old-style handling cases 03 and 04 of example should be identical. They are not, so this is also broken ATM.

There should be a real cleanup of area style handling.

comment:4 Changed 3 years ago by skyper

Cc: skyper added

comment:5 Changed 3 years ago by Don-vip

You may add unit tests that use this file for non-regression :)

comment:6 Changed 3 years ago by Don-vip

Keywords: multipolygon added

comment:7 in reply to:  description ; Changed 3 years ago by bastiK

Replying to stoecker:

Currently we still support old styles of multipolygon see ElementStyles.java. I think it is time to somehow deprecate them more than we do now.

  • So probably first is to disable the VERY old method of inner=outer completely.

I think we should remove the very old style completely. This should get rid of some ugly special handling in the code.

  • second is to never display outer styles for complete multipolygon anymore.
  • Third is probably to visually mark the no-style on multipolygons as bad for these cases, where the outers have one common style.

There are basically two styles in use:

(a) area tags on multipolygon relation
(b) area tags on outer way(s)

If in (b), the tags of the outer ways do not match, this is an error.

The 3rd suggestion I understand that you like to discourage the style (b) somehow. Before we can remove support for this, we should get some kind statistics, how much style (a) and (b) is used overall in the data base and maybe how much it is used in multipolygons that have been created / modified in the last year.

What do you mean by suggestion 2? Surely the outer way can be a highway, so a line style is okay.

comment:8 in reply to:  3 ; Changed 3 years ago by bastiK

Replying to stoecker:

Unclosed areas (multipolygon or not) should no longer be displayed as proper area. They should be marked somehow.

With proper old-style handling cases 03 and 04 of example should be identical. They are not, so this is also broken ATM.

Aren't they identical? Just the tag is different, so there is a another color.

comment:9 in reply to:  7 Changed 3 years ago by stoecker

Replying to bastiK:

Replying to stoecker:

Currently we still support old styles of multipolygon see ElementStyles.java. I think it is time to somehow deprecate them more than we do now.

  • So probably first is to disable the VERY old method of inner=outer completely.

I think we should remove the very old style completely. This should get rid of some ugly special handling in the code.

Fine with me.

  • second is to never display outer styles for complete multipolygon anymore.
  • Third is probably to visually mark the no-style on multipolygons as bad for these cases, where the outers have one common style.

There are basically two styles in use:

(a) area tags on multipolygon relation
(b) area tags on outer way(s)

If in (b), the tags of the outer ways do not match, this is an error.

The 3rd suggestion I understand that you like to discourage the style (b) somehow. Before we can remove support for this, we should get some kind statistics, how much style (a) and (b) is used overall in the data base and maybe how much it is used in multipolygons that have been created / modified in the last year.

What do you mean by suggestion 2? Surely the outer way can be a highway, so a line style is okay.

Broken thinking. :-) 2 and 3 boil down to "Never care for area styles on multipolygon outer members". Currently with a default false variable to be able to turn it back.

I think our task as editor is to get cleaner style, so we should not wait for the DB anymore, but start acting. Compatibility phase was long enough. It's deprecated for years now. Based on a request on dev mailinglist some month ago.

So my suggestions would be:

  • cleanup
  • fix 2 broken validator cases
  • check or fix validator: any area draw styles on outer ways should be warnings
  • disable handling of "outer" styles for multipolygons
  • disable display of unclosed areas (polygon or unclosed ways)

Last 2 should be announced in start page.

I had a look at multipolygon/boundary now again and JOSM's (or also my) secret (or not so secret) steps to cleanup database resulted in major reduction of ambiguities. E.g. exclave/enclave is completely dead. Special cases dropped. Boundary type Multipolygon is dying. So a new task ...

comment:10 in reply to:  8 Changed 3 years ago by stoecker

Replying to bastiK:

Replying to stoecker:

Unclosed areas (multipolygon or not) should no longer be displayed as proper area. They should be marked somehow.

With proper old-style handling cases 03 and 04 of example should be identical. They are not, so this is also broken ATM.

Aren't they identical? Just the tag is different, so there is a another color.

Right. Why the hell did I use different styles for each row? No idea.

comment:11 Changed 3 years ago by Klumbumbus

Cc: Klumbumbus added

comment:12 Changed 3 years ago by bastiK

In 7563/josm:

see #10529 - remove "very old" multipolygon style (area tags on both inner and outer ways)
(actually, this was never supported for MapCSS styles)

comment:13 Changed 3 years ago by bastiK

This is all I plan to do on this topic for now... :)

comment:14 Changed 3 years ago by stoecker

In 7565/josm:

see #10529 - fix one validator test case for multipolygon

comment:15 Changed 3 years ago by stoecker

In 7566/josm:

see #10529 - add another test case for inner/outer

comment:16 Changed 3 years ago by stoecker

In 7567/josm:

see #10529 - add parameter to disable outer-way styled multipolygons, defaults still to true

comment:17 Changed 3 years ago by stoecker

Description: modified (diff)

Added a parameter now. Question is how the default value should be.

I didn't find the relevant code yet where I can tell JOSM, that unclosed areas aren't areas. The value "pretendWayIsClosed" seems to be wrong place. Any suggestions where to search?

comment:18 Changed 3 years ago by stoecker

In 7568/josm:

see #10529 - fix Javadoc

comment:19 in reply to:  17 ; Changed 3 years ago by bastiK

Replying to stoecker:

Added a parameter now. Question is how the default value should be.

Had a quick look at two extracts (Hamburg and Corse): With the search terms type:relation type=multipolygon tags:1 and type:relation type=multipolygon I can see that at least 137 out of 351 and 799 out of 1516 multipolygons are tagged with area style at the outer way(s). Suppressing all these with a default value of false seems a bit extreme to me.

I didn't find the relevant code yet where I can tell JOSM, that unclosed areas aren't areas. The value "pretendWayIsClosed" seems to be wrong place. Any suggestions where to search?

The MapCSS specification states that the area selector only applies to closed ways/polygons. I took the liberty to redefine this and allow also unclosed ways, because it has always been like this in JOSM. If you are determined to change this, it would seem reasonable to change the meaning of area back to the standard meaning. This is done here for map styles and here for the MapCSS Validator rules.

What about incomplete relations, e.g. large forests, where you usually download only a small part of all the polygon ways?

Last edited 3 years ago by bastiK (previous) (diff)

comment:20 in reply to:  19 ; Changed 3 years ago by stoecker

Replying to bastiK:

Replying to stoecker:

Added a parameter now. Question is how the default value should be.

Had a quick look at two extracts (Hamburg and Corse): With the search terms type:relation type=multipolygon tags:1 and type:relation type=multipolygon I can see that at least 137 out of 351 and 799 out of 1516 multipolygons are tagged with area style at the outer way(s). Suppressing all these with a default value of false seems a bit extreme to me.

A bit too much. You're right. Probably first step is to increase warning to error level in JOSM? OTOH we are in a much better position to improve situation than for example the osm2pgsql guys who would like to have a cleaner state of data :-)

I didn't find the relevant code yet where I can tell JOSM, that unclosed areas aren't areas. The value "pretendWayIsClosed" seems to be wrong place. Any suggestions where to search?

The MapCSS specification states that the area selector only applies to closed ways/polygons. I took the liberty to redefine this and allow also unclosed ways, because it has always been like this in JOSM. If you are determined to change this, it would seem reasonable to change the meaning of area back to the standard meaning. This is done here for map styles and here for the MapCSS Validator rules.

What about incomplete relations, e.g. large forests, where you usually download only a small part of all the polygon ways?

Yes. It's not so easy. That's why JOSM already implements this "also show partial". For now I think we should have one (or more) hidden option to make display stricter and let's see, what we can do with them. Partial multipolygons probably should still be displayed, but not broken complete data.

comment:21 Changed 3 years ago by stoecker

In 7569/josm:

see #10529 - some better warnings for old style multipolygon tagging

comment:22 Changed 3 years ago by bastiK

In 7570/josm:

see #10529 - remove duplicate test (same as NO_STYLE_POLYGON)

comment:23 Changed 3 years ago by bastiK

In 7571/josm:

see #10529 - raise validator level from information to warning for multipolygons with area style tags at the outer way(s)

comment:24 Changed 3 years ago by stoecker

Added a startup note, so users know why they get new warnings.

@bastik:

Im not so sure if "No area style for multipolygon" as "warning" is really a good idea. It will fire for any type which we don't have a style for.

comment:25 in reply to:  20 ; Changed 3 years ago by bastiK

Replying to stoecker:

Replying to bastiK:

Replying to stoecker:

Added a parameter now. Question is how the default value should be.

Had a quick look at two extracts (Hamburg and Corse): With the search terms type:relation type=multipolygon tags:1 and type:relation type=multipolygon I can see that at least 137 out of 351 and 799 out of 1516 multipolygons are tagged with area style at the outer way(s). Suppressing all these with a default value of false seems a bit extreme to me.

A bit too much. You're right. Probably first step is to increase warning to error level in JOSM?

This test has been at information level so far (so basically invisible). Should be enough to raise it to warning for now (done in [7571]).

I didn't find the relevant code yet where I can tell JOSM, that unclosed areas aren't areas. The value "pretendWayIsClosed" seems to be wrong place. Any suggestions where to search?

The MapCSS specification states that the area selector only applies to closed ways/polygons. I took the liberty to redefine this and allow also unclosed ways, because it has always been like this in JOSM. If you are determined to change this, it would seem reasonable to change the meaning of area back to the standard meaning. This is done here for map styles and here for the MapCSS Validator rules.

What about incomplete relations, e.g. large forests, where you usually download only a small part of all the polygon ways?

Yes. It's not so easy. That's why JOSM already implements this "also show partial". For now I think we should have one (or more) hidden option to make display stricter and let's see, what we can do with them. Partial multipolygons probably should still be displayed, but not broken complete data.

Instead of switching the rendering off completely, we could also change the drawing in other ways, e.g. somehow mark the point where the area is broken or make the color more transparent, etc.

Same goes for area styles on outer ways: If the color was for example overlayed by a subtle pattern, this would probably bother many people and make them fix the multipolygon tagging.

comment:26 Changed 3 years ago by bastiK

In 7572/josm:

see #10529 - fix "typo" in [7571]

comment:27 in reply to:  24 Changed 3 years ago by bastiK

Replying to stoecker:

Added a startup note, so users know why they get new warnings.

@bastik:

Im not so sure if "No area style for multipolygon" as "warning" is really a good idea. It will fire for any type which we don't have a style for.

This was a mistake, thanks.

comment:28 in reply to:  25 ; Changed 3 years ago by stoecker

What about incomplete relations, e.g. large forests, where you usually download only a small part of all the polygon ways?

Yes. It's not so easy. That's why JOSM already implements this "also show partial". For now I think we should have one (or more) hidden option to make display stricter and let's see, what we can do with them. Partial multipolygons probably should still be displayed, but not broken complete data.

Instead of switching the rendering off completely, we could also change the drawing in other ways, e.g. somehow mark the point where the area is broken or make the color more transparent, etc.

Same goes for area styles on outer ways: If the color was for example overlayed by a subtle pattern, this would probably bother many people and make them fix the multipolygon tagging.

That sounds fine for me. I assume we need support of the core to change the styles accordingly?

comment:29 Changed 3 years ago by stoecker

In 7573/josm:

see #10529 - fix wording

comment:30 Changed 3 years ago by stoecker

Cc: pnorman added

comment:31 Changed 3 years ago by pnorman

I'd love to see more valid MPs - in particular, only new-style MPs and old-style MPs where all outers have identical tags and no tags on the relation but type=multipolygon.

An old-style MP with no tags on the relation but type, no tags on the inner and consistent tags on the outers shouldn't be rendered differently as it's perfectly correct and there are no problems parsing it.* I'd prefer a new-style MP, but the old-style one isn't wrong in any way, so shouldn't be rendered differently.

*Aside from the fact that relations are a pain to process and take about 100 times as long per element than ways. Seriously, if you don't need to make a relation, don't.

comment:32 in reply to:  31 Changed 3 years ago by stoecker

Replying to pnorman:

I'd love to see more valid MPs - in particular, only new-style MPs and old-style MPs where all outers have identical tags and no tags on the relation but type=multipolygon.

These warnings are there for a long time already and multipolygons violating them were buggy all the time. I now added new warnings about mismatch between tagged multipolygon and also tagged outer ways.

An old-style MP with no tags on the relation but type, no tags on the inner and consistent tags on the outers shouldn't be rendered differently as it's perfectly correct and there are no problems parsing it.

For you and mapnik and all the other users: Yes. But we are editor developers, we can be a little stricter, e.g. with an UGLY overlay (see comment 25).

  • I'd prefer a new-style MP, but the old-style one isn't wrong in any way, so shouldn't be rendered differently.

We can deprecate old style in favor of directly tagged multipolygons. Some years later other tools like osm2pgsql can then drop old-style-support :-)

This old tagging methods have been required backwards support to actually introduce proper multipolygon support at all when Frederik did the proposal and I the JOSM implementation. Also the very-old-style was needed then. Nothing of this is required today, so we can start dropping support step-by-step. I'm pretty sure that if old-style looks ugly in JOSM it's usage will drop dramatically (valdiator warnings also have effects, but not that much).

  • Aside from the fact that relations are a pain to process and take about 100 times as long per element than ways. Seriously, if you don't need to make a relation, don't.

I think that's clear.

comment:33 in reply to:  28 ; Changed 3 years ago by bastiK

Replying to stoecker:

Instead of switching the rendering off completely, we could also change the drawing in other ways, e.g. somehow mark the point where the area is broken or make the color more transparent, etc.

Same goes for area styles on outer ways: If the color was for example overlayed by a subtle pattern, this would probably bother many people and make them fix the multipolygon tagging.

That sounds fine for me. I assume we need support of the core to change the styles accordingly?

Depends what we do exactly.

@Klumbumbus (and others): Do you have any ideas, how this should presented? Sketches and full designs are very welcome!

comment:34 in reply to:  33 ; Changed 3 years ago by Klumbumbus

Replying to bastiK:

@Klumbumbus (and others): Do you have any ideas, how this should presented? Sketches and full designs are very welcome!

Just to make sure, that I understand it correct: you want to visually display if a multipolygon is old-style (which means all tags on outer and only type=multipolygon on the relation), right?

comment:35 in reply to:  34 ; Changed 3 years ago by bastiK

Replying to Klumbumbus:

Replying to bastiK:

@Klumbumbus (and others): Do you have any ideas, how this should presented? Sketches and full designs are very welcome!

Just to make sure, that I understand it correct: you want to visually display if a multipolygon is old-style (which means all tags on outer and only type=multipolygon on the relation), right?

Yes, exactly. This and a second completely independent project where we want to make it visually more obvious that an area / a polygon is unclosed.

Changed 3 years ago by Klumbumbus

Attachment: oldMP.png added

comment:36 in reply to:  35 Changed 3 years ago by Klumbumbus

Replying to bastiK:

Replying to Klumbumbus:

Replying to bastiK:

@Klumbumbus (and others): Do you have any ideas, how this should presented? Sketches and full designs are very welcome!

Just to make sure, that I understand it correct: you want to visually display if a multipolygon is old-style (which means all tags on outer and only type=multipolygon on the relation), right?

Yes, exactly. This and a second completely independent project where we want to make it visually more obvious that an area / a polygon is unclosed.

I can imagine a red dashed overlay on the outer line, see screenshot


However I'm not sure if completely dropping display of old MPs wouldn't be better. Both would have the same result: old MPs look different from new ones and the mappers start changing to the new style.

comment:37 in reply to:  35 ; Changed 3 years ago by Klumbumbus

Replying to bastiK:

... we want to make it visually more obvious that an area / a polygon is unclosed.

You already see that the outline is interrupted while the fill-color is still present up to the imaginary line between the two end nodes. Also after the validator ran, it highlights the end nodes with a circle (see screenshot). Don't you think this is enough?
In general I'm not sure if it is a good idea to implement validation features in the main style.


Last edited 3 years ago by Klumbumbus (previous) (diff)

Changed 3 years ago by Klumbumbus

Attachment: unclosed.png added

comment:38 Changed 3 years ago by stoecker

Validator itself is not enough to really reach the desired goal. It usually is only called for changed objects, which limits the scope a lot. And many people simply ignore it.

The red dash are too normal in my eyes. But validator layer is a good idea. What about overlaying (or under?) thick red lines for old-style multipolygons or full red circles for unclosed area ends?

I did a test today in an area I know and fixed approx. 10 old multipolygons, where two of them have been broken when interpreting the rules strict (mixed tagging). I believe getting rid of the old style completely will reduce such issues a lot.

comment:39 Changed 3 years ago by Klumbumbus

Fully downloaded unclosed area styles can also be changed from warning to error level in the validator. This will also lead to more fixing. I think most people try to fix atleast all errors before uploading.

Last edited 3 years ago by Klumbumbus (previous) (diff)

comment:40 Changed 3 years ago by aceman

The unclosed segment may be so small (nodes so close together), that nobody will notice it visually and it may even be off-screen. So a validator error and visual uglyfication of the WHOLE AREA of the polygon is something I'd support ;)

comment:41 in reply to:  37 ; Changed 3 years ago by stoecker

Replying to Klumbumbus:

In general I'm not sure if it is a good idea to implement validation features in the main style.

I agree with that after some consideration. My suggestion would be an "dataquality.mapcss" in core, which is activated by default. This way it is separate from main style, but still default in core. See also #10545.

comment:42 in reply to:  40 Changed 3 years ago by stoecker

Replying to aceman:

visual uglyfication

Nice wording. :-)

comment:43 in reply to:  12 Changed 3 years ago by Don-vip

Replying to bastiK:

In 7563/josm:

see #10529 - remove "very old" multipolygon style (area tags on both inner and outer ways)
(actually, this was never supported for MapCSS styles)

This change broke 4 unit tests:
http://donvip.fr/jenkins/job/JOSM/1401/testReport/

comment:44 Changed 3 years ago by Don-vip

In 7579/josm:

see #10529 - fix mapcss unit test

comment:45 in reply to:  41 Changed 3 years ago by Klumbumbus

Replying to stoecker:

My suggestion would be an "dataquality.mapcss" in core, which is activated by default. This way it is separate from main style, but still default in core. See also #10545.

Sounds good. Likely we can reuse some of the rules in https://josm.openstreetmap.de/browser/trunk/data/validator and just replace the "throwWarning:..." by a nice ugly style.

Changed 3 years ago by Klumbumbus

Attachment: error_area.png added

Changed 3 years ago by Klumbumbus

Attachment: red_diagonal.png added

comment:46 in reply to:  40 Changed 3 years ago by Klumbumbus

Replying to aceman:

The unclosed segment may be so small (nodes so close together), that nobody will notice it visually and it may even be off-screen. So a validator error and visual uglyfication of the WHOLE AREA of the polygon is something I'd support ;)

A suggestion for a style:

(made with fill-image with this image: )

Last edited 3 years ago by Klumbumbus (previous) (diff)

Changed 3 years ago by Klumbumbus

Attachment: red_diagonal5.png added

comment:47 Changed 3 years ago by aceman

Looks awfully good :) However, would it be possible to NOT apply this while the user is drawing the polygon so it is obviously unclosed? Only apply it after he removes focus from the object? I worry this could obstruct the imagery layer he is drawing onto, e.g. tracing some houses/area.

comment:48 in reply to:  47 Changed 3 years ago by Klumbumbus

Replying to aceman:

Looks awfully good :) However, would it be possible to NOT apply this while the user is drawing the polygon so it is obviously unclosed? Only apply it after he removes focus from the object? I worry this could obstruct the imagery layer he is drawing onto, e.g. tracing some houses/area.

I was just thinking nearly the same. During editing multipolygons, they are often unclosed or otherwise broken until you are done with your edits. If the error style bothers to much, the mappers will just deactivate it permanetaly which would be bad. I think the error styles should have high opacity.

comment:49 Changed 3 years ago by pnorman

A change like this should probably be announced and discussed on a wider scale than the JOSM issue tracker. Does someone want to summarize it?

comment:50 in reply to:  49 Changed 3 years ago by stoecker

Replying to pnorman:

A change like this should probably be announced and discussed on a wider scale than the JOSM issue tracker. Does someone want to summarize it?

No. It's still JOSM developers, who develop JOSM and not a community. We are happy about feedback, but we are no democratic institution.

comment:51 in reply to:  47 Changed 3 years ago by stoecker

Replying to aceman:

Looks awfully good :)

Same here. I'd use this for old-style multipolygons. But maybe it's to much and we should only do a smaller overlay over the lines (e.g. twice as thick as the PNG).

However, would it be possible to NOT apply this while the user is drawing the polygon so it is obviously unclosed?

Yes, that's nothing for unclosed polygons (think about partial ones as well). For unclosed ones I would simply mark the open ends with larger circles. That helps without disturbing.

I'd say let's implement it (non-default), test it, get some outside feedback and then decide whether it gets active or not.

comment:52 in reply to:  41 Changed 3 years ago by bastiK

Replying to stoecker:

Replying to Klumbumbus:

In general I'm not sure if it is a good idea to implement validation features in the main style.

I agree with that after some consideration. My suggestion would be an "dataquality.mapcss" in core, which is activated by default. This way it is separate from main style, but still default in core. See also #10545.

Good idea, I like it!

comment:53 Changed 3 years ago by stoecker

Milestone: 14.10

Anyone able to make that style - first with:

  • unclosed way endpoint markers
  • ugly overlay for oldstyle outer ways

Actually I still have not yet had a look at how mapcss is done :-(

comment:54 Changed 3 years ago by bastiK

No time, sorry.

comment:55 in reply to:  54 Changed 3 years ago by stoecker

Replying to bastiK:

No time, sorry.

You're in the same club :-)

comment:56 in reply to:  53 Changed 3 years ago by Klumbumbus

Replying to stoecker:

Anyone able to make that style - first with:

  • ugly overlay for oldstyle outer ways

the code could look like:

relation[type=multipolygon][!natural][!landuse][!amenity][!tourism][!shop][!leisure][!waterway][!boundary][!building][!landcover][!place][!man_made][area!=yes]::old_MP {
    fill-image: "???/diagonal_wider.png";
    fill-opacity: 0.15;
}

I made a new image for this (), which is less obtrusive. I think the fill opacity should not be higher than 0.15. A problem with this is, that the fill image hides untagged inners (see screenshot).


  • unclosed way endpoint markers

There are several problems to implement this in mapcss. First is #10299 and second is that you cannot check within mapcss if a multipolygon relation is closed or not. Atleast I couldn't find a way.

I think there are a lot of more or less complex situations, which are not possible to handle in mapcss. Therfore I think in general the best would be to let the validator tests do the calculation if there is an error and then it creates classes or properties of the objects which then simply can be used in mapcss to create the style.
Example:

node.endnode_of_unclosed_area::unclosed_area {
    symbol-size: 16;
    symbol-shape: circle;
    symbol-stroke-color: red;
    symbol-stroke-width: 1;
    symbol-stroke-opacity: 0.8;
}

Would that be possible?

Changed 3 years ago by Klumbumbus

Attachment: hiding untagged inners.png added

Changed 3 years ago by Klumbumbus

Attachment: diagonal_wider.png added

comment:57 Changed 3 years ago by stoecker

Would that be possible?

Yes. I'd prefer that. These checks should not be done in mapcss, but in the core and only displayed.

comment:58 Changed 3 years ago by Klumbumbus

The code for the overpass turbo wizard, if you want to search for old multipolygons in your region:

type:relation and type=multipolygon and natural!=* and landuse!=* and amenity!=* and tourism!=* and shop!=* and leisure!=* and waterway!=* and boundary!=* and building!=* and landcover!=* and place!=* and "man_made"!=* and area!=yes

comment:59 Changed 3 years ago by Don-vip

Milestone: 14.1014.11

comment:60 Changed 3 years ago by Don-vip

status of this?

comment:61 Changed 3 years ago by stoecker

Nothing new. We still need backend support for the necessary pseudo-classes.

comment:62 Changed 3 years ago by Don-vip

Milestone: 14.1114.12

comment:63 Changed 3 years ago by Don-vip

Milestone: 14.1215.01

comment:64 Changed 3 years ago by Don-vip

Milestone: 15.0115.02

move tickets that have not been treated this month to next milestone

comment:65 Changed 2 years ago by Don-vip

Milestone: 15.0215.03

comment:66 Changed 2 years ago by stoecker

Milestone: 15.0315.04

Move one month.

comment:67 Changed 2 years ago by simon04

In 8237/josm:

see #10529 - MapCSS: add :unclosed_multipolygon pseudo-class and >:open_end selector to go from relations to their open end nodes

For example, relation:unclosed_multipolygon >:open_end node matches open end nodes of unclosed multipolygon relations.

comment:68 Changed 2 years ago by Klumbumbus

:unclosed_multipolygon should not trigger for incomplete downloaded multipolygons.

comment:69 Changed 2 years ago by simon04

In 8252/josm:

see #10529 - MapCSS: :unclosed_multipolygon should not trigger for incomplete multipolygons

comment:70 Changed 2 years ago by simon04

@Klumbumbus: Would you add the desired visual styles?

comment:71 Changed 2 years ago by Klumbumbus

I think it is better to add the visual style in the next milestone. Such a big change of the default style should have some more testing time and maybe user feedback until it is part of JOSM-stable.

Open issues are:

  • fill image hides untagged ways (inners or outers of MPs are often untagged ways)
  • find a better way than in comment:56 to select old style multipolygons (tags on outer instead of relation)
    • maybe a pseudoclass that is true for relations, which are an "area" by the definition of JOSM. so the code could be:
relation[type=multipolygon]!:area::old_MP {
    fill-image: ".../diagonal_wider.png";
    fill-opacity: 0.15;
}

comment:72 Changed 2 years ago by simon04

Milestone: 15.0415.05

comment:73 Changed 2 years ago by Don-vip

Milestone: 15.0515.06

comment:74 Changed 2 years ago by Don-vip

Milestone: 15.0615.07

skip milestone 15.06

comment:75 Changed 2 years ago by Don-vip

Milestone: 15.0715.08

Milestone renamed

comment:76 Changed 2 years ago by Don-vip

Milestone: 15.08

Removing from milestone as it seems nobody's working on it right now.

comment:77 Changed 5 months ago by stoecker

Jochen Topf started MapRoulette challenges (http://area.jochentopf.com/fixing.html) to get rid of the old stuff. Probably that makes this ticket obsolete. :-)

comment:78 Changed 5 months ago by Stereo

On the gripping hand, that kind of style would make the challenge easier to solve :-)

comment:79 Changed 5 months ago by Klumbumbus

I see only a challenge "Self-Intersecting Multipolygon Relations" not something about old style multipolygons (tags on outer instead of on relation).

comment:80 Changed 5 months ago by stoecker

Click on the top left link to see the complete picture. ☺️

comment:82 Changed 5 months ago by stoecker

In 11782/josm:

see #10529 - increase important multipolygon problems to error level, better separate output of boundary and multipolygon

comment:83 Changed 4 months ago by stoecker

In 11908/josm:

see #10529 - don't display outer-way-style multipolygons by default - next step is to remove the related code completely

comment:84 Changed 4 months ago by stoecker

When the old style is gone there is a new question: What to do with area styles on outer ways in the future.

The correct definition for OSM will be, that area styles on outer ways are independent. Anyway I think that this is very complex and will lead to many complications. It is also seldom useful. Hopefully OSM definition will discourage usage of this.

Handling in JOSM would be very complicated, as selecting the outer way of a multipolygon does often mean to display or handle the multipolygon itself in different ways/aspects.

My suggestion would be to leave the current implementation, which drops display of an area way style in case the way is an outer member of a multipolygon.

Essentially I suggest to discourage but not prevent area styles on outer ways. Comments?

comment:86 in reply to:  84 Changed 4 months ago by aceman

Replying to stoecker:

The correct definition for OSM will be, that area styles on outer ways are independent. Anyway I think that this is very complex and will lead to many complications. It is also seldom useful. Hopefully OSM definition will discourage usage of this.

Handling in JOSM would be very complicated, as selecting the outer way of a multipolygon does often mean to display or handle the multipolygon itself in different ways/aspects.

When the OSM wiki specifies this change, JOSM can do what you propose. So then you propose drawing another enclosing way (even on the same nodes) and this one gets the tags that would be on the outer way of the multipolygon (e.i. the staduim tags from my example) ?

comment:87 Changed 4 months ago by stoecker

Milestone: 17.04
Resolution: fixed
Status: newclosed

comment:88 Changed 4 months ago by stoecker

In 12026/josm:

see #10529 - drop code completely

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set. Next status will be 'closed'.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.