Modify

Opened 10 years ago

Closed 10 years ago

#5564 closed defect (fixed)

[patch OK] Issue with bridge preset

Reported by: Nakor Owned by: team
Priority: normal Milestone:
Component: Core Version: latest
Keywords: Cc: ulfl

Description (last modified by Nakor)

Select a way.
Choose the bridge preset.
Click Apply preset.

ACTUAL RESULT:
Nothing happens

EXPECTED RESULT:
bridge=yes should be added to the way

Attachments (4)

ComboDefaultValue.diff (1.7 KB) - added by AlfonZ 10 years ago.
Enabled filling of default value for Combo
DefaultCombo-Address.osm (1.9 KB) - added by AlfonZ 10 years ago.
Geometries for example how default works for Combos
DefaultValuesFilling-property.diff (4.6 KB) - added by AlfonZ 10 years ago.
patch for filling default values controlled by property
DefaultValuesFilling-property_4018.diff (4.5 KB) - added by Nakor 10 years ago.
Patch updated against 4018

Download all attachments as: .zip

Change History (26)

comment:1 Changed 10 years ago by Nakor

Description: modified (diff)

comment:2 Changed 10 years ago by AlfonZ

Selected way has to have some other tag filled. Applying bridge preset to a way with no tags works as expected.

Changeset r3581 changed bridge preset from Key to Combo.
The difference being, that Key's value is being applied always, Combo's default value is being applied only if all items in selection have no tags.
Check's behaviour looks similar to Combo's, Text's to Key's.

There is a comment in the source code "use default only in case it is a totally new entry", so this behaviour might be correct.

Changeset r3481 is related to this as well.

comment:3 Changed 10 years ago by anonymous

Using the bridge preset used to set the bridge=yes tag. It is pretty annoying to have to do an extra click to set bridge=yes.

Can we please go back to previous behavior?

comment:4 Changed 10 years ago by stoecker

Oneclick presets has a bridge presets for this.

comment:5 Changed 10 years ago by Nakor

I do not understand why empty ways get bridge=yes set automatically but not others.

In the US we had the TIGER import. TIGER import does not know anything about bridges, my typical scenario is split a way where there is a bridge, set it has a bridge and depending on the situation add a layer tag.

Before I would open the bridge preset dialog, set the layer if needed and apply. Now I need to additionally set bridge=yes. Using the one-click preset is not a solution as I would need to go back and change the layer if needed.

So can we either:

1) have the default bridge=yes apply to ALL ways (empty or not)

2) keep the current behavior by default and have an option to force behavior described in 1)

Thanks,

N.

Last edited 10 years ago by Nakor (previous) (diff)

comment:6 Changed 10 years ago by stoecker

This is a security measure, so calling a preset does not overwrite data unwanted. Maybe we need to find a solution to specially enable it. I will have a look, but it may take time. As said, you can use the oneclick preset. It opens no dialog at all, but only sets bridge=yes.

comment:7 Changed 10 years ago by Nakor

What about making the security measure smarter i.e. does not overwrite an existing tag (i.e. do nothing if there is a bridge=no for instance) but add a non-existing key (i.e. set bridge=yes if there is no bridge key)?

Issue with one-click is I still have to go back edit the layer (and it also forces me to go through the menu unless there is a way to put it in the toolbar).

Changed 10 years ago by AlfonZ

Attachment: ComboDefaultValue.diff added

Enabled filling of default value for Combo

comment:8 Changed 10 years ago by AlfonZ

It looks to me that the security measures you are talking about have already been added in r591 and r949.
Default value (in the case of bridge bridge=yes) will be applied only if all selected ways have no bridge tag.

If there is existing bridge tag, its value will show up in preset dialog, default value will not overwrite it.

In the case of selecting two or more ways with different bridge values, <different> will show up in preset dialog and user can leave it as it is or change it.

Is there a case I missed?

Please see attached patch.

comment:9 Changed 10 years ago by stoecker

Sorry, but there is a reason why the values aren't taken always. They would apply always when calling a dialog and this is unwanted. This is only wanted for the key settings, not for additional or optional entries.

I don't understand what troubles you have with oneclick. This is a normal presets file, so it works exactly like all the other presets including the possibility to add it to the toolbar.

Changed 10 years ago by AlfonZ

Attachment: DefaultCombo-Address.osm added

Geometries for example how default works for Combos

comment:10 Changed 10 years ago by AlfonZ

I still don't see why filling default value in preset dialog (in case of no prior values) is a bad thing. It will show up in dialog and user can review it. It won't be set without user supervision.

Please try following:
Open attached DefaultCombo-Address.osm

  1. Select first way.
  2. Open Annotation/Addresses preset, fill it up (e.g. HouseNumber=1, StreetName=Foo, CityName=Bar, CountryCode=QQ) and apply.
  3. Select second way. It has no tags.
  4. Open Annotation/Addresses preset. StreetName, CityName and CountryCode is already filled up due to use_last_as_default="true", which is as intended.
  5. Select third way. It has some building tags.
  6. Open Annotation/Addresses preset. StreetName, CityName is already filled, CountryCode is not. The difference being that StreetName and CityName are Texts, CountryCode is Combo.

As I understand it, the intent was that CountryCode will be filled up as well. Otherwise you'll be forced to select correct country for each address you entered; or use other tricks to accomplish that.

My other point is, that there is difference between how default works for Text and Combo. They should be unified, IMHO. Default for Checks behaves even more differently, but they are more complicated.

comment:11 Changed 10 years ago by Nakor

I will explain one more time the issue with one-click: I use the one click, then I need to edit the layer field; with the previous behavior I would just open, the bridge preset, fill layer if needed and apply.
And this is not talking about the current inconsistency between the bridge preset and the tunnel preset.

Is there any reason why the following proposition cannot be applied (besides having someone coding it)?

not overwrite an existing tag (i.e. do nothing if there is a bridge=no for instance) but add a non-existing key (i.e. set bridge=yes if there is no bridge key)

comment:12 Changed 10 years ago by stoecker

Due to changes in the past the possibilities have been increased (i.e. the use_last_ad_default you mention, which is also potentially dangerous). The combo boxes are used for lots of presets and for lots of optional parameters and they should not be set when not really checked. When activate them always, then we add lots of unnecessary and also most often wrong data to the database. I don't say this topic shouldn't be fixed, but to output the values of combo boxes always is not the way to go.

Probably way to go is have a "set_always" tag.

Changed 10 years ago by AlfonZ

patch for filling default values controlled by property

comment:13 Changed 10 years ago by AlfonZ

First, some statistics from the internal presets.
There is total of 410 Combos that can be summed up to 128 unique Combos. 117 out of 129 have default="", only 11 have non-empty default or use_last_as_default:

  • Highways/Streets/Motorway,Motorway Link,Trunk,Trunk Link/lanes
  • Highways/Streets/Bridge/bridge
  • Highways/Streets/Bridge/layer
  • Highways/Streets/Tunnel/layer
  • Transport/Car,Motorcycle/Parking/parking
  • Sports/Sport (Ball)/Golf/leisure
  • Man Made/Power/Power Line/power
  • Facilities/Tourism/Information Board/board_type
  • Facilities/Health/Pharmacy/dispensing
  • Annotation/Addresses/addr:country
  • Annotation/Address Interpolation/addr:interpolation

Anyways, I have prepared another patch, see attached DefaultValuesFilling-property.diff

It unifies when is the default value applied in Texts, Combos and Checks, controlled by taggingpreset.fill-default-for-tagged-primitives property (feel free to change the name to more appropriate).

When the property value is true, check for (other) tags in selected item(s) is skipped.
This changes the current behaviour for Texts and Checks, which were using default value even for tagged items (see Address example above).

comment:14 Changed 10 years ago by Nakor

Can we get this fixed?

I see that for instance the prking preset automatically applies parking=surface. How is this different from bridge automatically applying bridge=yes?

Thanks in advance

comment:15 Changed 10 years ago by stoecker

I had not yet the time to test your patch. Applying default values for text and check probably is a bug and it sounds as you patch fixes it. But as said I had no time for it yet.

comment:16 Changed 10 years ago by AlfonZ

Cc: ulfl added

comment:17 Changed 10 years ago by stoecker

Summary: Issue with bridge preset[patch needs testing] Issue with bridge preset

Changed 10 years ago by Nakor

Patch updated against 4018

comment:18 Changed 10 years ago by Nakor

I have been using since without any problem so far. I attached a version updated against 4018. Please commit.

comment:19 Changed 10 years ago by Nakor

Summary: [patch needs testing] Issue with bridge preset[patch OK] Issue with bridge preset

comment:20 Changed 10 years ago by Fabi2

See #5903 for the real reason, why this does not work any longer. It was a side effect of fixging the escaping of <combo> (#5892).

comment:21 Changed 10 years ago by Fabi2

Sorry does not see, that this was reported long before.

comment:22 Changed 10 years ago by stoecker

Resolution: fixed
Status: newclosed

In [4050/josm]:

fix #5564 - patch by Nakor - unify handling of default values in presets

Modify Ticket

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

Add Comment


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

 
Note: See TracTickets for help on using tickets.