Opened 9 years ago
Closed 9 years ago
#12104 closed enhancement (fixed)
mapcss: partial fill
Reported by: | Klumbumbus | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | 15.12 |
Component: | Core mappaint | Version: | |
Keywords: | fill area multipolygon | Cc: | bastiK |
Description
partial fill of areas similar to id editor.
Attachments (13)
Change History (69)
comment:1 by , 9 years ago
by , 9 years ago
Attachment: | partialfill.png added |
---|
comment:5 by , 9 years ago
There is a bug with multipolygons
What steps will reproduce the problem?
- unclosed multipolygon (missing part or incomplete downloaded)
- partial fill is drawn between first and last point (for outer and also for inner)
Please provide any additional information below. Attach a screenshot if possible.
I didn't check fill image
Revision: 9015 Repository Root: http://josm.openstreetmap.de/svn Relative URL: ^/trunk Last Changed Author: Don-vip Last Changed Date: 2015-11-16 03:23:57 +0100 (Mon, 16 Nov 2015) Build-Date: 2015-11-16 02:34:08 URL: http://josm.openstreetmap.de/svn/trunk Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last Changed Rev: 9015 Identification: JOSM/1.5 (9015 de) Windows 7 32-Bit Memory Usage: 344 MB / 742 MB (150 MB allocated, but free) Java version: 1.8.0_65, Oracle Corporation, Java HotSpot(TM) Client VM VM arguments: [-Djava.security.manager, -Djava.security.policy=file:C:\Program Files\Java\jre1.8.0_65\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>\bin, -Djnlpx.origFilenameArg=C:\Program Files\josm-latest-bla.jnlp, -Djnlpx.remove=true, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.heapsize=256m,768m, -Djnlpx.splashport=51181, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.vmargs=LURqYXZhLnV0aWwuQXJyYXlzLnVzZUxlZ2FjeU1lcmdlU29ydD10cnVlAA==] Dataset consistency test: No problems found
follow-up: 9 comment:6 by , 9 years ago
Shouldn't setting resource://styles/standard/elemstyles.mapcss:boolean:partial_fill
to false
(in JOSM's advanced prefs) get the old behavior back?
follow-up: 10 comment:7 by , 9 years ago
This would fix the problem of closed incomplete multipolygons. But I'm not sure if it would break anything, Don-vip?
-
src/org/openstreetmap/josm/data/osm/visitor/paint/relations/Multipolygon.java
229 229 } 230 230 } 231 231 } 232 if (!initial) { // fix #7593233 poly.closePath();234 }235 232 for (PolyData inner : inners) { 236 233 appendInner(inner.poly); 237 234 }
comment:9 by , 9 years ago
Replying to naoliv:
Shouldn't setting
resource://styles/standard/elemstyles.mapcss:boolean:partial_fill
tofalse
(in JOSM's advanced prefs) get the old behavior back?
Yes, however it somehow only works when you use the style settings gui https://josm.openstreetmap.de/attachment/wiki/Help/Dialog/MapPaint/style-settings.png
comment:10 by , 9 years ago
comment:11 by , 9 years ago
Keywords: | fill area multipolygon added |
---|
by , 9 years ago
Attachment: | linecap.png added |
---|
follow-ups: 15 39 comment:13 by , 9 years ago
by , 9 years ago
Attachment: | area-unclosed-closed.png added |
---|
follow-up: 16 comment:15 by , 9 years ago
Replying to Klumbumbus:
I think atleast the linecap for closed inners should be fixed.
Done.
The linecap is a bit strange in some cases.
Yes, but at the moment, I don't know how to fix this.
For large incomplete multipolygons (riverbank, forest), the area-margin is sometimes on the wrong side. Without any additional information, there is no way to tell for sure, what is inner and what is outer. One way to deal with this, would be to draw a margin on both sides, as long as the area is not closed:
It would make a clear distinction between closed and "almost closed" ways.
I'm not really sure about this and would like to hear your opinions.
by , 9 years ago
follow-up: 28 comment:16 by , 9 years ago
Replying to bastiK:
For large incomplete multipolygons (riverbank, forest), the area-margin is sometimes on the wrong side. Without any additional information, there is no way to tell for sure, what is inner and what is outer. One way to deal with this, would be to draw a margin on both sides, as long as the area is not closed:
I think this would be good, becasue it would avoid other strange renderings like in the following picture.
And since the width is half on each side it should not be mixed up with a line where two closed areas touch each other.
follow-up: 18 comment:17 by , 9 years ago
My humble opinion is that this fill style should not be turned on by default for users. While it's nice to have, it should be opt-in. Style options are quite deep buried anyway.
Also, there is no logic to discriminate areas for which it makes no sense, like buildings.
follow-up: 19 comment:18 by , 9 years ago
Replying to RicoElectrico:
My humble opinion is that this fill style should not be turned on by default for users. While it's nice to have, it should be opt-in. Style options are quite deep buried anyway.
Thanks for your input! Could you give practical reasons, why you prefer the complete fill to the new style?
Also, there is no logic to discriminate areas for which it makes no sense, like buildings.
We could turn partial fill off for buildings and other selected features. Technically, this would be not a problem. So far, I like that everything is consistent, but there is certainly room for optimization and fine tuning.
comment:19 by , 9 years ago
Replying to bastiK:
Replying to RicoElectrico:
My humble opinion is that this fill style should not be turned on by default for users. While it's nice to have, it should be opt-in. Style options are quite deep buried anyway.
Thanks for your input! Could you give practical reasons, why you prefer the complete fill to the new style?
IMO the mapview is more confusing, because there are more lines.
comment:20 by , 9 years ago
by , 9 years ago
Attachment: | buildings.PNG added |
---|
by , 9 years ago
Attachment: | buildings-filled.png added |
---|
comment:21 by , 9 years ago
This is an interesting example:
First, there are multiple nested areas stacked on top of each other ("ADM" building inside medical faculty building inside university). The partial fill version sure looks more complicated, but the question should be, which view makes it easier to see the structure of areas and understand the data without clicking through each object. For example take the area with the red highlight in the partial-fill image. In the filled version, I can't really tell for sure, if this is a single connected area or not. In the other image, this is quite clear, even without red highlight.
Second, the outline of the "ADM" building is not properly lined up with the other building, the ways are intersecting. This error can be seen in both versions, but in the partial fill image, this is more eye-catching because the overlapping lines are duplicated on the inside of the margin.
That said, I agree, that the partial fill is much less useful for smaller objects and I wouldn't mind turning it off for buildings, etc.
follow-ups: 23 25 comment:22 by , 9 years ago
Tomorrow I must release JOSM as new tested because of certificate issue. Can we set this new behaviour disabled by default until we are all happy with it? :)
comment:23 by , 9 years ago
Replying to Don-vip:
Tomorrow I must release JOSM as new tested because of certificate issue. Can we set this new behaviour disabled by default until we are all happy with it? :)
+1
comment:25 by , 9 years ago
Replying to Don-vip:
Tomorrow I must release JOSM as new tested because of certificate issue. Can we set this new behaviour disabled by default until we are all happy with it? :)
Alright.. :)
follow-up: 29 comment:28 by , 9 years ago
Replying to Klumbumbus:
I think this would be good, becasue it would avoid other strange renderings like in the following picture.
And since the width is half on each side it should not be mixed up with a line where two closed areas touch each other.
Done. There is an Einstein pref to turn it on/off and set the relative width (currently 80%).
Replying to Don-vip:
+1 to exclude buildings, it is confusing in urban areas.
I have an alternative idea, that handles all kinds of small areas, not just buildings or what we explicitly set in the style:
Calculate the area of the unfilled black part in the center. If it is less than 50% of the total area, turn off partial fill for this object and fill it completely.
In my first test, this worked quite well and removed the strange looking artifacts in buildings, etc.
comment:29 by , 9 years ago
Replying to bastiK:
Calculate the area of the unfilled black part in the center. If it is less than 50% of the total area, turn off partial fill for this object and fill it completely.
That sounds good!
comment:32 by , 9 years ago
I've implemented this idea, please have a look!
Again, there is an advanced parameter (draw.area.partial_fill_threshold
) to tweak the threshold (currently at 50%). This feature is turned off by setting the parameter to something large, e.g. 1000.
Feel free to experiment with all the parameters and suggest alternative values!
follow-up: 36 comment:33 by , 9 years ago
I tested a bit and I think the margin on both sides does not work so good as expected. There are problems especially when MPs are used. With margin on both sides:
- you do not see which side is the inner side which makes the mapview more confusing (The case from comment:16 is in reality rare and mostly the inner side of unclosed areas is shown correct.)
- you do not see different colors if they are not the same on both sides, see the following gif
by , 9 years ago
Attachment: | margin.gif added |
---|
by , 9 years ago
comment:34 by , 9 years ago
Low zoom is also problematic when partial fill is activated and the dataset contains some uncomplete downloaded MPs, see attachment:zoom.gif
comment:36 by , 9 years ago
Replying to Klumbumbus:
I tested a bit and I think the margin on both sides does not work so good as expected. There are problems especially when MPs are used. With margin on both sides:
- you do not see which side is the inner side which makes the mapview more confusing (The case from comment:16 is in reality rare and mostly the inner side of unclosed areas is shown correct.)
- you do not see different colors if they are not the same on both sides, see the following gif
Okay, this is pretty convincing. I've turned off the margin on both sides.
comment:37 by , 9 years ago
follow-up: 41 comment:39 by , 9 years ago
Replying to Klumbumbus:
The linecap is a bit strange in some cases.
Could you try again with [9077]?
by , 9 years ago
Attachment: | artefact1.png added |
---|
by , 9 years ago
Attachment: | artefact2.png added |
---|
by , 9 years ago
Attachment: | artefact3.png added |
---|
by , 9 years ago
Attachment: | partial fill test.osm added |
---|
follow-up: 43 comment:41 by , 9 years ago
Replying to bastiK:
Replying to Klumbumbus:
The linecap is a bit strange in some cases.
Could you try again with [9077]?
There are some minor artefacts on lower zoom:
attachment:"partial fill test.osm" for testing
by , 9 years ago
Attachment: | artefact4.png added |
---|
comment:42 by , 9 years ago
I tried to workaroud this issue on low zoom with open multipolygons (see also comment:34) by lowering the fill extend of open multipolygons with lower zoom. But it seems that it is not possible within mapcss, because the pseudoclasses :closed and :unclosed_multipolygon handle uncomplete and just not fully downloaded multipolygons different (which is good in other cases). Atleast I could not find a way that reduces the fill extend only for unclosed multipolygons, but not for closed multipolygons or for ways.
follow-up: 44 comment:43 by , 9 years ago
Replying to Klumbumbus:
I tried to workaroud this issue on low zoom with open multipolygons (see also comment:34) by lowering the fill extend of open multipolygons with lower zoom. But it seems that it is not possible within mapcss, because the pseudoclasses :closed and :unclosed_multipolygon handle uncomplete and just not fully downloaded multipolygons different (which is good in other cases).
Is it?
Atleast I could not find a way that reduces the fill extend only for unclosed multipolygons, but not for closed multipolygons or for ways.
Another option would be to also turn to ordinary fill for small unclosed areas. This would be like in [9063], but maybe with a different, very conservative threshold. When the user draws a building or parking lot, it shouldn't alternate between partial fill and complete fill depending on the current size of the area, this would be confusing.
Replying to Klumbumbus:
There are some minor artefacts on lower zoom
Yes, it turned out to be a rather difficult problem. So far, I could not find an algorithm, that works perfectly for all cases. The current code works well, when the extent is smaller than the distances of the end-nodes to all the other polygon edges (like in comment:13). This should be the case for downloaded incomplete multipolygons, except at low zoom.
When the user is drawing an area, there can be somewhat strange overlaps, as you show in the screenshots. At the moment, I think this is acceptable: It shouldn't happen too often and the area will be closed in the end - then it looks fine.
follow-up: 46 comment:44 by , 9 years ago
Replying to bastiK:
Replying to Klumbumbus:
I tried to workaroud this issue on low zoom with open multipolygons (see also comment:34) by lowering the fill extend of open multipolygons with lower zoom. But it seems that it is not possible within mapcss, because the pseudoclasses :closed and :unclosed_multipolygon handle uncomplete and just not fully downloaded multipolygons different (which is good in other cases).
Is it?
Well, the pseudoclass :unclosed_multipolygon
was once developed for validation purposes. There the difference between open multipolygons and actually complete but just uncomplete downloaded multipolygons was important. See ticket:10529#comment:68. However we could rethink the definition of these pseudoclasses. (Maybe split them up and make an own pseudoclass for :complete_downloaded
, to make them independent!?)
comment:46 by , 9 years ago
Replying to Klumbumbus:
Well, the pseudoclass
:unclosed_multipolygon
was once developed for validation purposes. There the difference between open multipolygons and actually complete but just uncomplete downloaded multipolygons was important. See ticket:10529#comment:68. However we could rethink the definition of these pseudoclasses. (Maybe split them up and make an own pseudoclass for:complete_downloaded
, to make them independent!?)
Thanks, I wasn't aware of this. I've added a pseudoclass :closed2
, which ignores the fact that the multipolygon is downloaded completely and just checks for open ends. This is meant as an (internal) temporary solution, until we figure this out. In addition, there is a new pseudoclass :completely_downloaded
in [9099], like you suggested.
As you can see, I've moved much of the code into the style sheet, so it should be easier to adapt. The extent for unclosed areas is now smaller - to visually distinguish from closed areas and (as a side effect) reduce the artifacts further.
follow-up: 49 comment:47 by , 9 years ago
This is working very nice. Great job!
However I think we should use fill-extent-threshold: 50%;
instead of 70%. The reason is that with partial fill it is much harder to see if a building way is properly aligned to the aerial imagery and with 70% a lot of "normal sized" buildings use the partial fill to early.
I think we should also make this parameter a josm_pref, so advanced users can adjust it (without editing the mapcss style and then forever use their outdated copy).
comment:49 by , 9 years ago
Replying to Klumbumbus:
This is working very nice. Great job!
However I think we should usefill-extent-threshold: 50%;
instead of 70%. The reason is that with partial fill it is much harder to see if a building way is properly aligned to the aerial imagery and with 70% a lot of "normal sized" buildings use the partial fill to early.
Okay, sure.
I think we should also make this parameter a josm_pref, so advanced users can adjust it (without editing the mapcss style and then forever use their outdated copy).
Yes, good idea.
follow-up: 53 comment:50 by , 9 years ago
area[setting("partial_fill")]:closed2 { fill-extent: 25; fill-extent-threshold: JOSM_pref(partial_fill_extent_threshold, 50%); }
Does not work. Do we need an additional prop() here?
comment:51 by , 9 years ago
Works for me, but we have to keep an eye on the performance. Preferences lookup was a reason for slowness before, it is probably better to add an intermediate cache for this.
follow-up: 54 comment:53 by , 9 years ago
Replying to Klumbumbus:
Does not work.
Okay, I had to make sure the style is actually updated, when the preference value is changed.
comment:54 by , 9 years ago
comment:56 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
In 9005/josm: