Opened 6 years ago

Last modified 5 years ago

#17100 closed enhancement

complain about name=parking or name=Parking for amenity=parking — at Version 4

Reported by: mkoniecz Owned by: team
Priority: normal Milestone: 19.03
Component: Core validator Version:
Keywords: template_report Cc:

Description (last modified by mkoniecz)

What steps will reproduce the problem?

  1. Create a closed way with amenity=parkink and name=parking
  2. Run validator

What is the expected result?

Validator complains about undesirable descriptive name and proposes to remove it.

What happens instead?

Nothing

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

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2018-12-11 00:24:50 +0100 (Tue, 11 Dec 2018)
Build-Date:2018-12-11 02:32:21
Revision:14551
Relative:URL: ^/trunk

Identification: JOSM/1.5 (14551 en) Linux Ubuntu 16.04.5 LTS
Memory Usage: 497 MB / 869 MB (294 MB allocated, but free)
Java version: 1.8.0_191-b12, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: :0.0 1920x1080
Maximum Screen Size: 1920x1080
Dataset consistency test: No problems found

Plugins:
+ OpeningHoursEditor (34535)
+ buildings_tools (34724)
+ continuosDownload (82)
+ imagery_offset_db (34641)
+ measurement (34529)
+ reverter (34552)
+ todo (30306)

Last errors/warnings:
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet

Change History (5)

by mkoniecz, 6 years ago

Attachment: invalid parking names.png added

comment:1 by mkoniecz, 6 years ago

Attachment has history how many such names were present according to the http://taghistory.raifer.tech/ tool

comment:2 by GerdP, 6 years ago

This is quite special. Similar problem that I came across: building=house with name=house or shop=* with name=Shop.
Do you think about a test that would flag any name=v where this v also appears for another tag (excluding all other name tags
like name:de or alt_name etc), maybe ignoring the case so that Shop and shop do both match?

comment:3 by mkoniecz, 6 years ago

This is quite special. Similar problem that I came across: building=house with name=house or shop=* with name=Shop

Yes, my plan was to propose this obvious and relatively popular case and check whatever this rule type would be considered as OK. And in case of inclusion later propose some other potential matches from my list that are added so often that I am unable to process them on my own.

Do you think about a test that would flag any name=v where this v also appears for another tag (excluding all other name tags
like name:de or alt_name etc)

I worry that it may have many false positives. For start, in my own validator script I already exclude:

  • places (there are places with all kinds of bizarre name, like city in Turkey called Batman - and probably somewhere there is a village actually called Parking)
  • restaurants (restaurants sometimes have deliberately crazy and bizarre names, restaurant named Parking would not be outside what is normal)
  • peaks (some peaks also have truly weird names, I expect the same for other natural features but they are not mapped so often so I still have to run into one)

Sometimes descriptive name indicates that editor got confused (like tourism=attraction, name=hotel) and in such cases simply removing name is not helping.

There are also objects tagged solely with name=parking - for such cases removing names is not helping at all.

Overall I think that it would be safer to start from known popular descriptive names and add more manually rather than start from generic rule and add exclusions. I think that first would achieve the same results with less work and less false positives exposed to mappers. But the second approach is also OK.

Last edited 6 years ago by mkoniecz (previous) (diff)

comment:4 by mkoniecz, 6 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.