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 )
What steps will reproduce the problem?
- Create a closed way with amenity=parkink and name=parking
- 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 , 6 years ago
Attachment: | invalid parking names.png added |
---|
comment:1 by , 6 years ago
comment:2 by , 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 , 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.
comment:4 by , 6 years ago
Description: | modified (diff) |
---|
Attachment has history how many such names were present according to the http://taghistory.raifer.tech/ tool