Modify

Opened 11 years ago

Closed 10 years ago

#9066 closed enhancement (wontfix)

presets: including other preset extracts

Reported by: A_Pirard Owned by: team
Priority: normal Milestone:
Component: External preset Version: latest
Keywords: include presets Cc: A_Pirard

Description (last modified by A_Pirard)

One may want to assemble fast accessed, specialized preset menus like "Most common tags for street survey" without duplicating parts of defaultpresets.xml and having to synchronize these parts with JOSM updates.
<group ... <include name=URL/group-name.../[item-name]> ... </group> would greatly help.
A list may be supported at the last level: group1,...,groupN or item1,...,itemN. Also !itemX, usefully.
Ending / may be a double check for including groups rather than items.
Thousands of people TYIA !!!

update:

This is certainly not a duplicate of #8958 as such.

In #8958, a preset writer X, say of defaultpresets.xml, notices that he is writing things multiple times and he first makes a library of which he can reuse the elements down to the deepest key, a combo in the example.

In #9066, a plain user Y wants to ease his or anybody's life by bundling together for fast access the items or groups, no deeper, that are most used for a particular activity, say street survey, e.g. not the waterways, paths or motorways, but certainly all kinds of streets, Z crossings, traffic calming etc... He certainly does not want to ask writer X to establish a library before being able to do that.

But if you want #9066 to go down to copy the deepest key level and override values too, then writer X will notice that he can use an extended
URL/group-name.../[item-namekey-name] to address the elements from any element and hence that a library is not really needed.
Note that if removing the library hurts, you can call a dummy <group name="library"... with the property to accept any tree of keys and addressed with the extended URL or a simplified form thereof. If you really want to create a new data type called <library> then it probably ought to have a name and the URL specification has to be extended beyond groups and items.

In short, the two enhancements work differently to do two different things, but they can be merged to do both using a single method.

Ask me to copy this text as an comment of #9066 if everybody prefers a merge.

Attachments (0)

Change History (9)

comment:1 by A_Pirard, 11 years ago

Description: modified (diff)

comment:2 by Don-vip, 11 years ago

Resolution: duplicate
Status: newclosed

Closed as duplicate of #8958.

comment:3 by A_Pirard, 11 years ago

Description: modified (diff)
Resolution: duplicate
Status: closedreopened

comment:4 by A_Pirard, 11 years ago

Similar but not a duplicate. I explained that in an update of the description. Cheers.

comment:5 by simon04, 10 years ago

A possible implementation (already containing a patch) is being discussed in #9327.

comment:6 by A_Pirard, 10 years ago

After seeing the specs of the patch was written for #9327, I wonder if it wouldn't be little extra work to support the much wider scope of #9066 with a syntax similar to the following, at least with <fileref>="/" in a first time:

<include name=[<fileref>]group:name:Water/group:name:Water/item:name:Drain />
or a whole group instead of an item (or part of an item...)
<include name=[<fileref>]group:name:Water/group:name:Water />
where <ref>=
nothing: current file
"/": default preset
"/something/": reference to some preset file

with which
<include name=chunk:id:highway_base>
would be equivalent to
<reference ref="highway_base" />

comment:7 by simon04, 10 years ago

A few concerns:

  • performance penalties when reading defaultpresets.xml over and over again to evaluate and <include> of external presets
  • why would one include an entire item into another preset?
  • this will break the XML validation (currently, the ids of chunk/reference are tested for uniqueness/existence, respectively)

… be little extra work …

Unfortunately not, since the preset parsing code is quite complex. See for yourself: TaggingPresetReader.java

in reply to:  7 comment:8 by A_Pirard, 10 years ago

Replying to simon04:

  • performance penalties when reading defaultpresets.xml over and over again to evaluate and <include> of external presets

I thought that, at the time of compiling the <include> tag, an already compiled form of the information could be found in memory and used.

  • why would one include an entire item into another preset?

What are you calling a "preset"? I spoke of including items or groups in a preset file. That's much in the same spirit as one makes program shortcuts on one's desktop.

  • this will break the XML validation (currently, the ids of chunk/reference are tested for uniqueness/existence, respectively)

??? You "reference" made up chunks identified with an id and I would "include" existing elements that need no more validation than if they were not included and that are identified by their names.

Anyway. I just met the new <preset_link> tag as the reply to one of my bugs and the best inventive idea to make oneself a set of shortcuts is now to create an item called "manythings" and to fill it with <preset_link>s if that works.

comment:9 by simon04, 10 years ago

Resolution: wontfix
Status: reopenedclosed

Since #9327 and #7797 provide similar features, we won't implement this ticket.

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. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.