Opened 12 years ago
Closed 11 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 )
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 , 12 years ago
Description: | modified (diff) |
---|
comment:2 by , 12 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
comment:3 by , 12 years ago
Description: | modified (diff) |
---|---|
Resolution: | duplicate |
Status: | closed → reopened |
comment:4 by , 12 years ago
Similar but not a duplicate. I explained that in an update of the description. Cheers.
comment:5 by , 11 years ago
A possible implementation (already containing a patch) is being discussed in #9327.
comment:6 by , 11 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" />
follow-up: 8 comment:7 by , 11 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
comment:8 by , 11 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 , 11 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
Closed as duplicate of #8958.