Presets 'default' field is ignored

[Skybunny]

What steps will reproduce the problem?

1. Use a preset with defaults. An example is 'Bicycle Road', in Internal Presets, https://josm.openstreetmap.de/browser/trunk/data/defaultpresets.xml#L790 .
2. Set the Bicycle Road preset on a way, to get the detail entry box.
3. Defaults which are expected to be autofilled are not.

What is the expected result?

'vehicle' should be autofilled to 'no', and 'maxspeed' should be autofilled to '30'.

What happens instead?

Both values are ignored, as though they aren't part of the preset specification at all.

If editable is set to false on a combo key, then 'the first value identified in the list' is silently applied the first time the preset is used, and then explicitly shown in future uses. In either case, the actual specified 'default' value is apparently disregarded.

Please provide any additional information below. Attach a screenshot if possible.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2018-07-01 23:07:04 +0200 (Sun, 01 Jul 2018)
Revision:13996
Build-Date:2018-07-01 21:10:23
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (13996 en) Mac OS X 10.13.5
OS Build number: Mac OS X 10.13.5 (17F77)
Memory Usage: 284 MB / 5120 MB (116 MB allocated, but free)
Java version: 10.0.1+10, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: Display 69680128 1440x900
Maximum Screen Size: 1440x900
Dataset consistency test: No problems found

Plugins:
+ OpeningHoursEditor (34389)
+ apache-commons (34389)
+ ejml (34389)
+ geotools (34125)
+ jts (34206)
+ opendata (34389)
+ pbf (34389)
+ utilsplugin2 (34389)
+ wikipedia (v1.0.1)

Last errors/warnings:
- W: Missing plugin main version in plugin plastic_laf-sources
- W: Missing plugin main version in plugin pointInfo-javadoc
- W: Missing plugin main version in plugin pointInfo-sources
- W: Missing plugin main version in plugin poly-javadoc
- W: Missing plugin main version in plugin poly-sources
- W: Missing plugin main version in plugin print-javadoc
- W: Missing plugin main version in plugin print-sources
- W: Missing plugin main version in plugin utilsplugin2-javadoc
- W: Missing plugin main version in plugin utilsplugin2-sources
- W: No configuration settings found.  Using hardcoded default values for all pools.

[Skybunny]

As a further note, this behavior happens regardless of whether one is using an Internal Preset, or a preset they import directly to JOSM themselves.

[Don-vip]

Works on Windows with same version of Java. Do you have another machine which is not a Mac, to see if it comes from macOS?

[Skybunny]

I can reproduce this in 13996 if I install JDK 10.0.1 on Windows, running the jar file directly, and if I run in Web Start.

[Skybunny]

Okay, I figured out what the real issue is here. It has nothing to do with Java version, etc., because I got this to happen in Windows.

How NOT to reproduce it:

1. Draw a new line in JOSM that has no tags.
2. Select a preset.
3. You will get defaults (if any) autofilled for that object.

How to reproduce it:

1. Select a line that already has tags. Say, for example, you want to apply 'Culvert' to a portion of a 'waterway=stream' stream.
2. Select the culvert preset.
3. 'layer', which has a default value, will not be populated.

JOSM is being _too_ cautious in (presumably) not applying preset defaults to objects that have 'at least one tag', because two presets can be compatible with one another. iD deals with this all the time; you can tag a new way as (for example) highway=primary, split the way into three parts, and then select a radio button for (x) bridge while highlighting the way in the middle. This produces:

2 outer ways:
highway=primary

1 middle way:
highway=primary
bridge=yes
layer=1

The rule for a preset should be, IMO:

1. 'Overwrite tags that outright conflict with this preset when you write a new one.' This appears to be basically what happens today; if I select a way previously set with the Stream and overwrite it with River, waterway=stream is changed to waterway=river. Good. Culvert also changes a previously set 'tunnel=no' to 'tunnel=culvert'. Also good.
2. 'If a new preset brings default tags with it, overwrite those values as well.' This is the part that doesn't happen. In fact, it's so 'cautious' that the following happens:

1. Highlight a way that has waterway=river and layer=1 already set.
2. Select the 'culvert' preset.
3. When the preset dialog comes up, 'layer=1' is still set.
4. Applying the preset will leave you with waterway=river, tunnel=culvert, layer=1. Not ideal. PERFECT would be setting it to 'one less', meaning zero, or I'd still think '-1' would be great. But leaving it at 1 doesn't make any sense at all. The point of a preset with defaults payloads is lost.

OR...

1. Highlight a way that has (only) waterway=river set.
2. Select the 'culvert' preset.
3. When the preset dialog comes up, layer is unset despite there being a default for it. I'd have to do manual entry of '-1' each and every time I wanted to use this on an unset layer.
4. Applying the preset will leave you with waterway=river, tunnel=culvert. The required tag was added, but the default additional key layer was ignored entirely because this object had tags.

I realize I mentioned this before, but iD gets this one closer-to-right. If I select an object, A, and apply preset B, doing this will BOTH write the tags critical to the preset (yes, leaving others alone), and autofill defaults when that's applicable, such as changing 'level=*' to 'level=-1' -- but especially/at the least when said defaults don't exist at all.

[Skybunny]

Follow-up:

With regard to Overwrite tags that outright conflict with this preset when you write a new one.' ', this appears to be true to the extent that a key directly conflicts with one already on the object, (e.g., waterway=* when the presets in question are 'Stream' and 'River'. It does not do this when you select a way with say, 'railway=rail' and apply the 'Stream' preset, even though these two tags are essentially functionally incompatible with one another. iD _does_ remove a railway=rail tag when Stream is applied; I'm guessing there's a concept of 'is-not-comptabile-with' in their presets tables for this purpose. Looking at https://josm.openstreetmap.de/wiki/TaggingPresets I don't think there's a correlative, though I guess that could be an enhancement request in the future.

In any case, at the very least, defaults for applied presets could still be applied to objects that contain tags, the original thrust of this issue.

[Don-vip]

I think this is intentional and Dirk closed a similar ticket some time ago.

[anonymous]

I'll just say that I really _really_ hope this isn't closed as 'wontfix'. All not fixing this does, IMO, is create pointless work for editors, especially when you are wanting to use a preset like 'culvert' or 'bridge' to extend an already used preset like 'highway' or 'waterway'.

Why do this?
Imagine if you are wanting to follow the track of a stream and (properly!) split the way and add culverts under roads in the 10 places it appears. Not having a preset that allows default field fills 'just because a tag exists on that object' doesn't help. Sure, I COULD split them first, then go back and hope I remembered all of the splits I just did, doing the culvert preset with a batch operation against 10 objects (and manually typing in '-1' in the layer field), but I rather like the flow where I can just follow the line using imagery as a guide.

...or, I can continue to use iD for that, that does do the above. I'm trying hard to like and use JOSM, especially for its (search and mutliple object select capabilities) that iD just doesn't have. But the power of presets isn't just creating new objects from scratch; it's also refining or re-characterizing objects that already exist on the map.

[stoecker]

This is a WONTFIX. A cycle

• open preset
• click OK without changing anything

should not modify an object. With active defaults it would.

This is acceptable for new objects, but not for existing one.

For batch operations as you describe there are other possibilities (e.g. paste tags function). You don't need presets for such.

[Skybunny]

Aha: I found the ticket you're referring to, and yes, it was intentional then. https://josm.openstreetmap.de/ticket/8204

I will argue, as the person who raised that issue did, that there are uses for implementing this. (And I'm not saying this to rub salt in it, simply saying:) iD does it, whether or not JOSM does. If those on this project feel strongly about the potential for map damage with preset categories and subcategories containing default value payloads, they should be lodging a bug with iD telling them not to do it, also. Any highway or waterway preset in iD prominently features a default layer item which creates a default layer if not present (and whether or not tags are already present): see attached.

​https://github.com/openstreetmap/iD/issues/4384 (and the previous equivalent which I can't find right now, for bridge, but has been in there for years).

[Skybunny]

iD, before using the 'bridge' preset underneath a highway

[Skybunny]

iD, after using the 'bridge' preset underneath a highway

[Skybunny]

Anyway, with that, I won't press any harder. If manual tag edits on (one or more objects at a time) is how this needs to be done, that's how I'll do it. I like the convenience of being able to use a preset in those cases, but I can get away without it.

[stoecker]

Replying to Skybunny:

they should be lodging a bug with iD telling them not to do it, also.

It's not our task to judge iD or submit bug-reports to them. E.g. I personally don't use it at all.

Each of the editors has its own working style. If they would be the same there would be no need for two. You don't need to agree to all the decision we do, but you must accept them. In general these decisions are right, otherwise JOSM wouldn't be successful.

[Skybunny]

You don't need to agree to all the decision we do, but you must accept them.

I like the convenience of being able to use a preset in those cases, but I can get away without it.

No worries; this is me saying that. I hope there are no hard feelings! Just out to justify why I submitted the issue in the first place.

[stoecker]

Replying to Skybunny:

I hope there are no hard feelings!

No. In this case I would simply ignore you.

I just wanted to explain the policy, as your request is a valid one, even if it is a wontfix.