#9327 closed enhancement (fixed)
[beta Patch] De-duplicate contents of defaultpresets
Reported by: | simon04 | Owned by: | team |
---|---|---|---|
Priority: | major | Milestone: | 14.01 |
Component: | Internal preset | Version: | |
Keywords: | deduplication, reference | Cc: | Pedja, kendzi |
Description
To reduce the length and duplicated parts of defaultpresets.xml
, I tested the following idea: For <optional>
elements, an id="x"
may be specified. When inserting a <reference ref="x"/>
element any time later, the corresponding optional elements are retrieved again.
Please see the attached patch for details and an example on the barrier presets. What do you think?
Attachments (4)
Change History (33)
by , 10 years ago
Attachment: | 9327v1.patch added |
---|
by , 10 years ago
Attachment: | 9327v2.patch added |
---|
comment:2 by , 10 years ago
Summary: | [alpha Patch] De-duplicate contents of defaultpresets → [beta Patch] De-duplicate contents of defaultpresets |
---|
v2: A more concise and flexible implementation using <chunk id="x">...</chunk>
at the beginning of the preset file, which can be used using <reference ref="x"/>
.
After reading through the mentioned tickets, I think there're similar ideas with small differences in the implementation (separate files vs. designated parts in main preset file, etc.). I somewhat prefer a single file (as in the current path) since it doesn't require a change in the i18n process, and it permits a simple find operation of the editor within the same file when editing presets.
follow-up: 4 comment:3 by , 10 years ago
I'm the reporter of #9066.
My idea is that someone who wants to make a specialized set of the existing presets he uses most for a special activity should not copy the definitions he clones but link to them. The link is general, like an URL, and may fetch from any source. The source needs not to be modified. It is not only a question of internal optimization of the default presets, it's using them, or any, from the outside.
The intention was to reuse whole presets as is, but after being erroneously duplicated with #8958, I imagined that the two ideas could be merged, i.e. link with modification. Modification, of course, can fail if an out of control external source gets modified incompatibly.
Any method to do that is much welcome. Thanks!!!
comment:4 by , 10 years ago
Replying to A_Pirard:
I'm not sure to fully grasp your idea. Please give a small example to illustrate.
comment:5 by , 10 years ago
Hi. Much explanation in the other tickets. Simple. Suppose you survey streets for example.
Instead of repeatedly fumbling for the features scattered in a number of 3-level trees, it speeds up work to make a custom arrangement of the presets you use most. And a link is obviously always more interesting than a copy in case the preset is updated. There is probably much duplication of outdated presets in the private and public preset mass.
Being able to override the contents, especially with a chunk you link to, is a real plus. For example, every time I read about tagging the street address of something, I recall to not forget the website (which contains the address). Look at supermarket aso, no website. Your idea and mine will make possible the inclusion of a "coordinates" chunk for address, phone,... not forgetting website.
comment:7 by , 10 years ago
I happened to come across http://josm.openstreetmap.de/wiki/Presets/BENELUX and what he says in Description is an example of what you ask for.
comment:8 by , 10 years ago
Replying to A_Pirard:
How exactly would your idea be written to the defaultpresets.xml
file? What cannot be done with the syntax from attachment:9327v2.patch?
comment:9 by , 10 years ago
v3: Manually extracted frequent combinations. Here's the change in terms of wc
(lines, words, bytes):
old 7545 28113 525237 data/defaultpresets.xml new 7039 21667 447575 data/defaultpresets.xml
by , 10 years ago
Attachment: | 9327v3.patch added |
---|
follow-up: 11 comment:10 by , 10 years ago
follow-up: 12 comment:11 by , 10 years ago
Replying to A_Pirard:
My #9066 idea is not to write anything to defaultpresets.xml but to private preset files.
Have you read #9066 and the mentioned preset file?
Please show an example of how it can be done with your syntax.
I read it several times, but didn't get the idea. That's why I asked for an example in comment:4 and comment:8.
The title of this ticket is "De-duplicate contents of defaultpresets" and that's why the patch de-duplicates the defaultpresets.
comment:12 by , 10 years ago
The initial idea of #9066 is to include without duplicating it any preset element from any file to another preset file. It was erroneously duplicated to your more restricted "de-duplicating [internal] contents of defaultpresets" concern. After pointing out the difference, I wrote that the same patch could achieve both goals at the same time.
My URL-like concept can identify both the XML element and the file in which it is comes from.
I just can't figure how to explain that something LIKE
<include name=filename(=URL)/group-name/[item-name]>
can do what you want by including almost anywhere almost any XML element picked from any file
while
<reference ref="highway_base" />
can obviously not pick an XML element from any file
and hence not do what I want (as you say it could).
For example:
<include name=/http://josm.openstreetmap.de/browser/trunk/data/defaultpresets.xml/Highways/Streets/Motorway>
or
<include name=/http://josm.openstreetmap.de/browser/trunk/data/defaultpresets.xml/group.name=Highways/group.name=Streets/item.name=Motorway>
or
<include name="chunk.id=barrier">
or WHATEVER EQUIVALENT SYNTAX YOU DEVISE, it's up to you if you do that.
follow-up: 14 comment:13 by , 10 years ago
Please no need for uppercase speech, it's rude.
I think I understand your request now, we could simply use XML namespaces for that.
ref=bar
=> item defined in current preset file
ref=foo:bar
=> item defined in preset file referenced by namespace foo
As why I referenced your ticket in this one, it's because it's a similar (but not identical) topic we must have in mind while implementing this ticket, that's all.
comment:14 by , 10 years ago
Replying to Don-vip:
Please no need for uppercase speech, it's rude.
Were computers invented by rude people? :-) (there was no lowercase before)
No, it's just emphasis. No worse than JOSM ;-)
I think I understand your request now, we could simply use XML namespaces for that.
ref=bar
=> item defined in current preset file
ref=foo:bar
=> item defined in preset file referenced by namespacefoo
If any file can be assigned a namespace, that's fine.
But remember that any XML element (at least group and item) can be referenced, not just made up ones like chunk.
Thanks for your attention.
comment:17 by , 10 years ago
Cc: | added; removed |
---|---|
Keywords: | deduplication reference added |
Milestone: | → 14.01 |
The patch looks good, let's give it a try !
We can then close this ticket and try to implement external references with namespaces in #9066.
by , 10 years ago
Attachment: | chunk_problem.patch added |
---|
Syntax accepted but presets do not work as expected
comment:20 by , 10 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I tried to refactor railways but it does not work, I think it's not currently possible to mix references, combos, then references ?
Btw I'm leaving tomorrow morning for new year's eve vacation, I'll see progress updates, if any, next year :)
Take a break Simon as well, you have earned it ;)
Happy new year !
comment:21 by , 10 years ago
In principle this combination should work. I'll investigate.
Vincent, enjoy your vacation and Happy New Year! See you … :-)
comment:23 by , 10 years ago
Replying to simon04:
A possible implementation [for #9066] (already containing a patch) is being discussed in #9327.
I just wrote #9066 comment 6 to restate even more precisely, now in terms of more precise syntax, how a slightly wider scope of this patch would satisfy not only the de-duplication of defaultpresets.xml by its implementors but also the de-duplication of anypresets.xml by its author who duplicates for convenience items of other files.
Note that the latter does not have access to add chunks and ids to the other files.
follow-up: 27 comment:24 by , 10 years ago
Great consolidation, thanks! This will surely prevent some current or future divergence of similar preset blocks.
Are these blocks intentionally not referencing highway_yesno_incline_oneway_lit and opencoding the elements instead? Is it because you really want to insert motorroad/oneway:bicycle into the middle of the block?
397 <reference ref="highway_base" />
398 <check key="oneway" text="Oneway" />
399 <check key="motorroad" text="Motorroad" />
400 <reference ref="highway_yesno_incline" />
401 <check key="lit" text="Lit" />
415 <reference ref="highway_base" />
416 <check key="oneway" text="Oneway" />
417 <check key="motorroad" text="Motorroad" />
418 <reference ref="highway_yesno_incline" />
419 <check key="lit" text="Lit" />
552 <reference ref="surface" />
553 <check key="oneway" text="Oneway" />
554 <check key="oneway:bicycle" text="Oneway for bicycle" />
555 <reference ref="highway_yesno_incline" />
556 <check key="lit" text="Lit" />
comment:27 by , 10 years ago
Replying to aceman:
Are these blocks intentionally not referencing highway_yesno_incline_oneway_lit and opencoding the elements instead? Is it because you really want to insert motorroad/oneway:bicycle into the middle of the block?
Those haven't been found in the manual search+replace process. I changed the first two of them, but I'd stick with the current "Bicycle Road" since otherwise the order of "Oneway" bla bla "Oneway for bicycle" is really strange.
A big +1 on the idea :)
For implementation, consider also the ideas proposed here:
We definitively need this to maintain presets in the long term.