Strange effect with man_made closedways: presets with type="closedway" or "node,closedway" are not displayed in the "Presets" view

jajajaneeneenee commented 9 months ago

Vespucci Version

19.3.3

Download source

Google Play Store

Device (Manufacturer and Model)

Samsung A33

Android Version

13

Behaviour/Symptoms

Today I experienced a strange effect – not sure if it is new (since version 19.3.3?) or not. Perhaps it exists since a longer time, and I never noticed that ...

If you have a closedway tagged with a man_made=* tag (no matter which value, even man_made=xyz), preset items with type="closedway" (or type="node,closedway") are not displayed in the editor in the "Presets" view.

But presets with type="node,closedway,multipolygon" or type="closedway,multipolygon" are displayed.

And this really only seems to happen with man_made tags – I didn't try ALL possible tags (keys), but the most important keys like amenity, building, natural, ... and I didn't find another tag with this effect for the editor.

Note: this does not mean, that a man_made closedway object is not matching with its preset in the editor ("Properties" tab) – this works fine without any problems.

It happened in my case with several custom presets for man_made=street_cabinet with different sub keys (I gave them type="node,closedway" and not type="node,closedway,multipolygon" for obvious reasons), and if I want to change such a closedway and choose another man_made=street_cabinet custom item, this is not possible by choosing another preset, because it isn't displayed in the editor view, I have to edit the value in the details tab manually. And also, not other item e.g. type="node,closedway" is displayed ...

How to recreate

Create a simple closedway and tag it with e.g. man_made=street_cabinet.
Take a look in the "Presets" view if items with type="node,closedway" are displayed or not (e.g. "Street cabinet" itself or "Parking Space" or "Toll Booth") – in my case they are not displayed.
(If you want: change the main tag of the closeway to e.g. barrier=toll_booth and see if such presets are displayed – in my case, they are displayed now).

I hope you can reproduce that, and it's not a side effect of something else on my device only (I had some strange Vespucci crashes today, perhaps since version 19.3.3?). I also did an Android restart, enabled only ONE preset file, and so on ... The effect was always there.

simonpoole commented 9 months ago

Currently not repeatable. There is no difference between the matching code for man_made and amenity (or anything else fwiw). Are you sure the way you tested on is actually closed?

simonpoole commented 9 months ago

I had some strange Vespucci crashes today, perhaps since version 19.3.3?.

If you submitted two crash dumps yesterday, they were due to out of memory errors. If you want help with that pls open an issue, and include the output of the debug page and any files you had loaded.

jajajaneeneenee commented 9 months ago

Currently not repeatable. There is no difference between the matching code for man_made and amenity (or anything else fwiw). Are you sure the way you tested on is actually closed?

Yes, I am very sure about that. I just made another try and could reproduce it at once – activated only the "simonpoole – beautified-JOSM-preset" (last release) ...

But after some longer trial and error series I came across a surprising cause – and that is that it has to do with the (custom) DataStyling I use. I would never have thought that DataStyling could affect the display of presets in the editor. Therefore, I never used another DataStyling to test. But you should always believe everything is possible...

Concrete: I actually just tried styling by man_made closedways a while ago a method with which you can ensure that an outline is always drawn completely OUTSIDE so that half of it is not overlaid by a (transparent) fill color, which results in poor rendering results. I used a black, thin casing outline with a negative offset value (because I also wanted a different colored, slightly transparent filling) and added an area="true" to the closedway styling with the fill color, so that it always has the same line rotation direction – so the negative offset value always has an effect to the outside.

And if I simply remove the area="true" attribute, the strange effect is gone!

This also explains, that I noticed the effect only with man_made closedways – because the combination of an item with type="node,closedway" (without "multipolygon") and such a (custom) styling with area="true" is quite rare – or possibly really only with man_made items, I didn't check it completely ...

Here the complete example: My custom styling for street_cabinet closedways looks like this (and I used a similar styling for all other man_man tags and also for the default styling for man_made closedways – for new or unknown man_made values):

<feature type="black_closedway_outline_casing_outside_0_3" widthFactor="0.3" offset="-0.5" color="ff000000" style="STROKE" cap="BUTT" join="MITER" />

<feature type="way" tags="man_made=street_cabinet" color="77556788" closed="true" area="true" style="FILL" labelZoomLimit="20" casingStyle="black_closedway_outline_casing_outside_0_3" iconPath="preset">
    <feature type="way" tags="name" labelKey="name" />
    <feature type="way" tags="ref" labelKey="ref" />
    <feature type="way" tags="operator" labelKey="operator" />
    <feature type="way" tags="model" labelKey="model" />
    <feature type="way" tags="manufacturer" labelKey="manufacturer" />
    <feature type="way" tags="material" labelKey="material" />
</feature>

My closedway tagged with man_made=street_cabinet looks like this (and I also use another icon – but this is the one from the "Simonpoole – beautified-JOSM-preset"):

Screenshot_1_closedway_with_man_made_street_cabinet

With the area="true" attribut, the "Presets" view of man_made items looks like this: Screenshot_2

Without the area="true" attribut, it looks like this (as it should be): Screenshot_3

Now I just hope that this was REALLY the cause – and not a number of strange side effects adding up or something similar.

Is it possible that you can fix this strange behavior (which is not really understandable for the normal user) and I can keep my styling? Perhaps it's a very simple code change ... I hope so ... Or do I have to change it and loosing clean black outlines with a fill color (which could also be easier to create, but that's another topic, I was happy to find a way to do it ...)?

jajajaneeneenee commented 9 months ago

I had some strange Vespucci crashes today, perhaps since version 19.3.3?.

If you submitted two crash dumps yesterday, they were due to out of memory errors. If you want help with that pls open an issue, and include the output of the debug page and any files you had loaded.

Yes, it was me. But does it make any sense to create an output of the debug page now if no crash has occurred (today I was lucky ... no crash)? I don't really understand ... And I also thought you would get such an output with the error report. Don't you?

I didn't open a problem because I couldn't have described what led to the crashes, I didn't do anything extraordinary before that – and it wasn't the same process on both occasions. It just happened.

But because you speak about out of memory errors: I think I didn't load a very large area for mapping (and no gpx tracks or so on, I use only Bing and Osmose as additional layers), but my (custom) DataStyling XML has really grown (because with XML a lot of things can only be achieved by X repetitions of code, often repetitions of larger code blocks with a small difference at the beginning). It's not exactly what you'd call a "slim" styling code. It currently has 89793 lines (with many comments ...) with > 8,000,000 characters (approx. 8 MB uncompressed, plus > 1000 mainly SVG icons). This has been a bit of a concern for me for some time now ... is it something to be concerned about or shouldn't this be a problem for Vespucci at all (or can the Android/Samsung memory management be a problem – the phone has 6 GB RAM ... should be enough I think)? And my custom preset files are also not very small either – I use 4 of them with 82187, 30004, 33474 and 4206 lines ... plus the icons of course (I mainly use SVG). But Vespucci has performed bravely so far! It seems to be coded well ...

Would you need all these files for an analysis? (Wouldn't be very easy, because they contain a lot of personal comments and so on ...). They are not in a condition to be published, is what I meant to say. I only use them for myself so far.

simonpoole commented 9 months ago

Yes, it was me.

Could you pls create a new issue for this, the issue has no bearing on this one.. Simply strip out the comments from your style file for the upload as the parser throws them away any way. An Android app gets a max of 512MB of heap in the virtual machine, and while it is unlikely that you could exceed that with a style file alone, in combination you can. The debug screen will indicate how much memory you have used in any case.

simonpoole commented 9 months ago

But after some longer trial and error series I came across a surprising cause

This is not so surprising, though I agree it should be better documented.

Setting the area attribute in the style file will lead to matching objects being treated as "areas" for preset purposes throughout the system, this is an undocumented side effect. We are doing this because there is no way of determining if a closed way should be treated as an area or as a linear object without employing heuristics and/or configuration.

To make things worse for many kinds of objects it isn't even really clear what we are modelling in OSM when we map them. Are we mapping the outline or the area (think about buildings for example)? Some times we just treat them as whatever is convenient at the moment.

Preset matching will currently not match presets that only have closedway as "type" with objects that are considered areas, but will match if the type includes multipolygon. But see below.

Back to the issue at hand: setting the area attribute in the style file for street_cabinet leads to such objects being treated as an area, so only preset items will match that contain multipolygon in the type attribute. Or include the undocumented extension area in the type attribute, which is what multipolygon gets mapped to internally.

MarcusWolschon / osmeditor4android