Meaningless informational messages for contact: prefix

[GerdP]

What steps will reproduce the problem?

1. Enable informational messages
2. Validate an object with contact:phone or contact:website, e.g. way 76472099
3. Note that 3 informational messages are created with Presets do not contain property value

What is the expected result?

None of these messages, nobody would expect a specific contact to be in the presets

What happens instead?

Each contact:*=* tag seems to produce a message.

Please provide any additional information below. Attach a screenshot if possible.

The corresponding keys should probably be specified in ignoretags.cfg?

Revision:19019
Is-Local-Build:true
Build-Date:2024-03-23 08:02:02

Identification: JOSM/1.5 (19019 SVN en_GB) Windows 10 64-Bit
OS Build number: Windows 10 Pro 2009 (19045)
Memory Usage: 1787 MB / 1888 MB (709 MB allocated, but free)
Java version: 17.0.5+8, Eclipse Adoptium, OpenJDK 64-Bit Server VM
Look and Feel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Screen: \Display0 1920×1080 (scaling 1.00×1.00)
Maximum Screen Size: 1920×1080
Best cursor sizes: 16×16→32×32, 32×32→32×32
System property file.encoding: UTF-8
System property sun.jnu.encoding: Cp1252
Locale info: en_GB
Numbers with default locale: 1234567890 -> 1234567890
VM arguments: [-agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:57733, -ea, --add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED, --add-opens=java.base/java.io=ALL-UNNAMED, --add-opens=java.base/java.lang=ALL-UNNAMED, --add-opens=java.base/java.nio=ALL-UNNAMED, --add-opens=java.base/java.text=ALL-UNNAMED, --add-opens=java.base/java.util=ALL-UNNAMED, --add-opens=java.base/jdk.internal.loader=ALL-UNNAMED, --add-opens=java.desktop/java.awt=ALL-UNNAMED, --add-opens=java.desktop/javax.swing.text.html=ALL-UNNAMED, --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED, --add-modules=java.scripting,java.sql, -javaagent:D:\eclipse-java-2020-09\eclipse\configuration\org.eclipse.osgi\3603\0\.cp\lib\javaagent-shaded.jar, -Dfile.encoding=UTF-8, -Dstdout.encoding=UTF-8, -Dstderr.encoding=UTF-8]
Dataset consistency test: No problems found

Plugins:
+ FastDraw (36226)
+ OpeningHoursEditor (36226)
+ RoadSigns (36226)
+ SimplifyArea (36209)
+ apache-commons (36176)
+ buildings_tools (36226)
+ comfort0 (36200)
+ conflation (0.6.11)
+ jts (36004)
+ o5m (36126)
+ pbf (36176)
+ poly (36126)
+ reltoolbox (36226)
+ reverter (36230)
+ splinex (36126)
+ undelete (36226)
+ utilsplugin2 (36226)

Tagging presets:
+ https://raw.githubusercontent.com/ruosm-presets/literan-moscow/master/russian_shops.xml

Validator rules:
+ d:\java_tools\JOSM\mygeometry.mapcss
+ https://josm.openstreetmap.de/josmfile?page=Rules/GermanySpecific&zip=1
+ c:\josm\core\resources\data\validator\geometry.mapcss

Last errors/warnings:
- 00000.551 W: extended font config - overriding 'filename.Myanmar_Text=mmrtext.ttf' with 'MMRTEXT.TTF'
- 00000.555 W: extended font config - overriding 'filename.Mongolian_Baiti=monbaiti.ttf' with 'MONBAITI.TTF'

[GerdP]

Seems this is caused by preset ​https://raw.githubusercontent.com/ruosm-presets/literan-moscow/master/russian_shops.xml
I've only installed this to test something, but I still think the messages should be suppressed.

[taylor.smock]

We have contact: in the default presets. See source:trunk/resources/data/defaultpresets.xml@19017:9517-9553#L9514​ .

Is there a contact:* that is not in that list that is causing problems?

[GerdP]

I guess the problem with the mentioned preset is that it contains specific values?

[taylor.smock]

Hrm. I wouldn't have expected that to cause problems. That seems more like a bug in the test, since they are freeform text in the default preset.

[GerdP]

traceback from Eclipse:

Thread [main-worker-0] (Suspended (breakpoint at line 1180 in TagChecker))	
	TagChecker.tryGuess(OsmPrimitive, String, String, MultiMap<OsmPrimitive,String>) line: 1180	
	TagChecker.checkSingleTagComplex(MultiMap<OsmPrimitive,String>, OsmPrimitive, String, String) line: 1065	
	TagChecker.check(OsmPrimitive) line: 658	
	TagChecker(Test$TagTest).visit(Way) line: 136	
	Way.accept(OsmPrimitiveVisitor) line: 180	
	TagChecker(Test).visit(Collection<OsmPrimitive>) line: 218	
	TagChecker.visit(Collection<OsmPrimitive>) line: 1287	
	ValidationTask.realRun() line: 192	
	ValidationTask(PleaseWaitRunnable).doRealRun() line: 94	
	ValidationTask(PleaseWaitRunnable).run() line: 142	
	Executors$RunnableAdapter<T>.call() line: 539	
	FutureTask<V>.run() line: 264	
	ProgressMonitorExecutor(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) line: 1136	
	ThreadPoolExecutor$Worker.run() line: 635	
	Thread.run() line: 833	

[GerdP]

With the preset enabled this code returns true false because getPresetValues() returns a list of values for e.g. contact:email

   public static boolean isTagIgnored(String key, String value) {
        if (isKeyIgnored(key))
            return true;
        final Set<String> values = getPresetValues(key);
        if (values != null && values.isEmpty())
            return true;
        if (!isTagInPresets(key, value)) {
            return ignoreDataTag.stream()
                    .anyMatch(a -> key.equals(a.getKey()) && value.equals(a.getValue()));
        }
        return false;
    }

[taylor.smock]

The only way to fix this would be to get presets matching a key and primitive type, then iterate through them looking for one of them to be freeform.

That might be a pretty significant performance hit, but I'd have to profile. We could probably cache the results to reduce the performance impact.

EDIT: Stream to find freeform text:

        TaggingPresets.getTaggingPresets().stream().anyMatch(preset ->
                preset.data.stream()
                        .filter(KeyedItem.class::isInstance)
                        .map(KeyedItem.class::cast)
                        .anyMatch(item -> key.equals(item.key) && item instanceof Text)
        );

[GerdP]

Sorry, I don't know much about presets. What does freeform text mean?

[taylor.smock]

When I say "freeform text", I mean that the user can enter any valid value text for the tag.

Example: name=🔥🍔 (yes, there are some businesses that use emoji as their name).

For stuff like name, we have freeform text fields, since we cannot know in advance what values are "valid".

[GerdP]

OK, I guessed that, but I don't know how a preset defines a tag as freeform.

[taylor.smock]

Oh. Sorry. I misunderstood.

We use the text​ key.

[GerdP]

Thanks.

[GerdP]

initial approach with cached results

[GerdP]

keys which are detected to contain freeform text

[GerdP]

I've used your code and tested it with the special preset. It works quite well and I see no performance issues. I guess the lookup in the hashset is even faster than the creation and handling of the meaningless messages.
It filters also keys like alt_name, short_name, and inscription, which is good.

One problem so far: With the unpatched version I see e.g. Value 'anti-slip' for key 'surface' not in presets. (4)

I was surprised to find e.g. depth or maxweight, but that's probably because the presets don't show any example values.

[GerdP]

freeform keys are only interesting if the presets contain a value list

[GerdP]

With the 2nd patch the default presets the collection freeformKeys contains only these two keys:

material
surface

I think we want to show messages for these, so I wonder if the preset is wrong? If not, the approach with ignoretags.cfg seems the better solution.

[taylor.smock]

The same preset is at fault for both of those keys. See man_made=planter​.

Looking at ​osmwiki:Tag:man_made=planter, we should probably just reference the most complete list of surfaces/materials.

[GerdP]

Ah, I see, the preset man_made=planter doesn't use a combo key and therefore is special. The same is true for the Russian POIs preset, right?
So, I really think the attached patch is the wrong approach. Maybe a similar test should be performed when the presets are verified?

[taylor.smock]

The same is true for the Russian POIs preset, right?

I've never used the preset, but I think it is very similar to the name suggestion index.

Maybe a similar test should be performed when the presets are verified?

I don't think I understand what you are getting at. Options for what I think you were trying to say:

• Find conflicting key types when we validate external presets in jenkins
• Find matching presets for a tagged object and validate that the matching preset is "correct" given a specified tag
  • We'd want to find and cache the presets first, and if any preset with the specified tag "matches", then all is good.

[GerdP]

I meant the validation tests in jenkins.

[taylor.smock]

Fair enough. But we cannot ensure that preset authors will follow best practices. And I would guess the Russian POI preset is using something like <key key="contact:website" value="https://example.org"/>.

[GerdP]

Yes, see ​https://raw.githubusercontent.com/ruosm-presets/literan-moscow/master/russian_shops.xml

[GerdP]

Ticket #23713 has been marked as a duplicate of this ticket.