Modify

Opened 5 years ago

Last modified 5 years ago

#12468 new enhancement

enhance display of boundaries in relation list dialog

Reported by: Klumbumbus Owned by: team
Priority: normal Milestone:
Component: Core Version:
Keywords: Cc: stoecker, bastiK, Don-vip

Description (last modified by Klumbumbus)

I received this idea via a pm from a user.

all boundary relations display the text boundary (...) in the relation list dialog
This could be more specific by adding the boundary type from our presets.
Additional for boudary=protected_area the value of protect_class could be shown in [] like this is already done for administrative boundaries with admin_level

So the display of relation/5874542 could enhance from:

boundary (...)

to

boundary: protected area [4] (...)

(See also #12467 for related regression.)

Attachments (0)

Change History (12)

comment:1 Changed 5 years ago by Klumbumbus

Description: modified (diff)

comment:2 Changed 5 years ago by simon04

We have a few options:

  • define presets and use name_template, see wiki:NameTemplate
  • add the most common boundary values to i18n/specialmessages.java and enhance org.openstreetmap.josm.gui.DefaultNameFormatter#getRelationTypeName (similar to type=place)

comment:3 Changed 5 years ago by simon04

Milestone: 16.02

comment:4 in reply to:  2 ; Changed 5 years ago by Klumbumbus

Replying to simon04:

Wow. I didn't know this exists. Using JOSM for several years and still discovering great features :)

Which of the two methods is preffered?

I case of first method: we already have presets in Geography/boundaries/*

I played a bit with name_template and this is the result (for the protected area boundary):

name_template="Boundary: Protected Area ?{ protect_class=* '[{protect_class}] ' | ''}"
name_template_filter="boundary=protected_area"

Seems to work fine. Any improvements? The whole page wiki:NameTemplate is a bit confusing and hard to understand.

I'm not sure what is with i18n. Will name_template be a i18n string?

comment:5 in reply to:  4 ; Changed 5 years ago by simon04

Cc: stoecker bastiK Don-vip added

Replying to Klumbumbus:

Which of the two methods is preffered?

I don't know. DefaultNameFormatter is quite a mess with various special treatments (e.g., addr:*) mixed with two or more parallel user-configurable systems (such as the pref key relation.nameOrder and the preset name_template). It might be a good idea to move some parts to name_templates in the defaultprestes. Other opinions?

I'm not sure what is with i18n. Will name_template be a i18n string?

Not yet, but that could be added. The translators would be confronted with the name_template syntax, however.

comment:6 in reply to:  5 Changed 5 years ago by bastiK

Replying to simon04:

Replying to Klumbumbus:

Which of the two methods is preffered?

I don't know. DefaultNameFormatter is quite a mess with various special treatments (e.g., addr:*) mixed with two or more parallel user-configurable systems (such as the pref key relation.nameOrder and the preset name_template).

I think it's not too bad. We might as well include protect_class as another special treatment, makes no difference. On the long run, I agree a text-file configuration would be better.

It might be a good idea to move some parts to name_templates in the defaultprestes. Other opinions?

I'm not sure what is with i18n. Will name_template be a i18n string?

Not yet, but that could be added. The translators would be confronted with the name_template syntax, however.

Probably overkill, but a new and separate MapCSS-based system would work better for translations, e.g.

relation[boundary=protected_area][!protect_class] {
  label: tr("Boundary: Protected Area");
}
relation[boundary=protected_area][protect_class] {
  label: tr("Boundary: Protected Area [{0}]", tag("protect_class"));
}

comment:7 Changed 5 years ago by Don-vip

the name_template approach sounds good. I did not know it neither, as it is not used in default presets. That's a good opportunity to use this feature and make it more visible to our users.

comment:8 Changed 5 years ago by Don-vip

Milestone: 16.0216.03

comment:9 Changed 5 years ago by Don-vip

Milestone: 16.0316.04

Milestone renamed

comment:10 Changed 5 years ago by Don-vip

Milestone: 16.0416.05

comment:11 Changed 5 years ago by Don-vip

Milestone: 16.0516.06

comment:12 Changed 5 years ago by Don-vip

Milestone: 16.06

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to Klumbumbus
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment


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

 
Note: See TracTickets for help on using tickets.