Modify

Opened 9 years ago

Closed 7 years ago

Last modified 7 years ago

#5679 closed defect (fixed)

[Patch] Validator: value of name tag not in presets if a preset specifies a name value

Reported by: stephankn Owned by: team
Priority: normal Milestone:
Component: Core validator Version: tested
Keywords: TagChecker Cc:

Description (last modified by mrwojo)

Version 3592, Validator 23917

Validator reports "Value xxx for key name not in presets"
This is reported for street names on highway=residential, amenity=marketplace and atm.
Very likely for others as well.

As a street name is unlikely to ever appear in presets (as well as names for markets) this false positive should be fixed.
Is there any situation where we safely can check the value of the name key against presets? It might be better to exclude the name tag from checks.

Sample node (marketplace): 694991740

Attachments (2)

Test5679.xml (662 bytes) - added by mrwojo 7 years ago.
a full preset file that reveals this issue
5679.patch (4.2 KB) - added by mrwojo 7 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 9 years ago by bastiK

Cannot reproduce, node 694991740 does not produce a validation problem for me. You could try the latest version of JOSM with validator build in and post a *.osm file if the problem persists.

comment:2 Changed 9 years ago by stephankn

Can also reproduce with JOSM latest (3685).

Exact message in Validator:
"Presets do not contain property value - Value 'Doi Saket Market' for key 'name' not in presets"

Validator settings from config:

validator.tests=Coastlines=true,MultipolygonTest=true,SimilarNamedWays=true,UntaggedNode=true,RelationChecker=true,CrossingWays=true,NodesWithSameName=true,TagChecker=true,OverlappingWays=true,UnclosedWays=true,WronglyOrderedWays=true,UnconnectedWays=true,SelfIntersectingWay=true,DuplicatedWayNodes=true,NameMismatch=true,DuplicateWay=true,UntaggedWay=true,TurnrestrictionTest=true,DuplicateNode=true
validator.testsBeforeUpload=Coastlines=true,MultipolygonTest=true,SimilarNamedWays=true,UntaggedNode=true,RelationChecker=true,CrossingWays=true,NodesWithSameName=true,TagChecker=true,OverlappingWays=true,UnclosedWays=true,WronglyOrderedWays=true,UnconnectedWays=true,SelfIntersectingWay=true,DuplicatedWayNodes=true,NameMismatch=true,DuplicateWay=true,UntaggedWay=true,TurnrestrictionTest=true,DuplicateNode=true
validator.visible=true

In case it helps (don't understand why, you can load the element in josm) here is the osm file:

<?xml version='1.0' encoding='UTF-8'?>
<osm version='0.6' generator='JOSM'>
  <node id='694991740' timestamp='2010-04-13T02:37:25Z' uid='61891' user='stephankn' visible='true' version='1' changeset='4410343' lat='18.872912' lon='99.1372162'>
    <tag k='amenity' v='marketplace' />
    <tag k='name' v='Doi Saket Market' />
  </node>
</osm>

comment:3 Changed 8 years ago by simon04

I cannot reproduce this neither (r4280, fresh settings; tested with attached .osm file as well as with node 694991740 from the server).

Last edited 8 years ago by simon04 (previous) (diff)

comment:4 Changed 8 years ago by skyper

Owner: changed from team to stephankn
Status: newneedinfo

Validator changed a lot !

Is this still reproducable with current latest or tested and an new/empty preference directory ?

See Help/ResetPreferences how to locate the preferences.

What kind of operating system do you use and what is your java version ?

Thanks

comment:5 Changed 8 years ago by stephankn

Owner: changed from stephankn to team
Status: needinfonew

Can reproduce with 4332

To reproduce you need to have BOTH options enabled:
"Show informational level" and
"Check property values"

In addition I discovered that it is needed to have an additional set of presets active.

You can even create a new node, assign it name=xxx and get the complaint "Value 'xxx' for key 'name' not in presets".

I did try to track it down and found it is related to the presets file containing a "name=something" entry.
I use these presets to quickly tag a convenience store (I just notice I might switch to brand, but not relevant for this bug):

So generally speaking all keys that might allow freetext entries but have a preset which suggests a specific value will show this behavior.

This was my preset used:

         <item name="7ELEVEN" icon="http://upload.wikimedia.org/wikipedia/en/thumb/d/d4/7-eleven-brand.svg/16px-7-eleven-brand.svg.png" type="node">
            <link href="http://wiki.openstreetmap.org/wiki/Tag:shop=convenience" />
            <label text="Edit convenience store" />
            <key key="shop" value="convenience" />
            <key key="name" value="7ELEVEN" />
            <combo key="opening_hours" text="Opening hours" de.text="Öffnungszeiten" values="24/7" default="24/7" delete_if_empty="true" />
         </item>

I will replace the keyword 'key' in my presets with 'text'. That causes the validator to accept any value. An ugly side-efect is that I now have a text-field in the dialog. As I want to one-click set the value this just fills up the dialog box. Also for presets setting 'operator' or 'brand' I would not need the text field as the purpose of the preset is just to set it without additional edits.

For a selection combo of different operators I see no workaround, so I'm going to leave this bug open:

<combo key="operator" text="Operator" values="Bangkok Bank,Siam Commercial Bank,Bank of Ayudhya" default="" delete_if_empty="true" />

comment:6 Changed 7 years ago by mrwojo

Description: modified (diff)
Keywords: TagChecker added
Summary: Validator: value of name tag not in presetsValidator: value of name tag not in presets if a preset specifies a name value

I was able to repro this with the preset item in stephankn.

By specifying a value for name in the preset, TagChecker deduces that the name key has a limited set of values and thus warns when it's not one of those values (in this case anything other than "7ELEVEN").

The S:, E:, and F: lines in ignoretags.cfg apply only to keys that have no known preset values, so it's not as simple as adding E:name. Perhaps it should be that simple?

Changed 7 years ago by mrwojo

Attachment: Test5679.xml added

a full preset file that reveals this issue

comment:7 Changed 7 years ago by bastiK

Resolution: fixed
Status: newclosed

In 5379/josm:

fixed #5679 - Validator: value of name tag not in presets if a preset specifies a name value

(respect key ignore rules E, S and F also for tags where some value for this key is found in the presets)

comment:8 in reply to:  6 Changed 7 years ago by bastiK

Replying to mrwojo:

I was able to repro this with the preset item in stephankn.

By specifying a value for name in the preset, TagChecker deduces that the name key has a limited set of values and thus warns when it's not one of those values (in this case anything other than "7ELEVEN").

The S:, E:, and F: lines in ignoretags.cfg apply only to keys that have no known preset values, so it's not as simple as adding E:name. Perhaps it should be that simple?

I changed the checks as you suggested, please test with your samples.

Changed 7 years ago by mrwojo

Attachment: 5679.patch added

comment:9 Changed 7 years ago by mrwojo

Resolution: fixed
Status: closedreopened
Summary: Validator: value of name tag not in presets if a preset specifies a name value[Patch] Validator: value of name tag not in presets if a preset specifies a name value

I've confirmed that it's still open with latest. It correctly finds that it should ignore name, but it still does the value check after that.

I've attached a patch against latest that seems to do everything as expected.

comment:10 Changed 7 years ago by bastiK

Resolution: fixed
Status: reopenedclosed

In 5380/josm:

fixed #5679 - Validator: value of name tag not in presets if a preset specifies a name value (patch by mrwojo)

comment:11 in reply to:  9 Changed 7 years ago by bastiK

Replying to mrwojo:

I've confirmed that it's still open with latest. It correctly finds that it should ignore name, but it still does the value check after that.

I've attached a patch against latest that seems to do everything as expected.

Yes, [5379] was rubbish. Thanks for patch, looks correct now!

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.

Add Comment


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

 
Note: See TracTickets for help on using tickets.