I encountered opinion that it is a terrible thing to add tags with relatively low use tags to iD presets. Given reason was that it basically forces such tagging on everyone, and block organic growth of possible alternative taggings.
Do you think it is fine to add sat shop=* or amenity=* that is currently not very widely established?
Should I always start from creating thread at forums here to get feedback first?
Should I add only ones proposed to be included in JOSM/Vespucci presets and not rejected there? To be more specific: ones present in one of these presets would be valid targets, ones proposed very recently are not valid targets yet.
Or what I did so far (gathering info about trash from variety of sources, using my own judgement when choosing target) is working well enough? See Pull requests ¡ openstreetmap/id-tagging-schema ¡ GitHub for list of changes I implemented so far
Or should I found something else to do with my time as this kind of activity is harmful and dubious? (it will not be hard to find something on my TODO list, though replacement will be unlikely to be osm-related)
There are also other options that I see.
Supporting only approved tags (going through a proposal process of it is not approved yes) seems to be a bad idea. For start, some approved ones were clearly bad ideas. Also this adds a very significant overhead.
And anyway how object is supported (its icon, label and so on) is not a part of proposal and may turn a good idea into a really bad one.
At the end of the day, recommendations have to start somewhere. I do think there should be a toggle in iD for if you want to disable automatic tagging based on presets. It should be on by default since new mappers will be guided in the right direction but experienced mappers may opt to trust their own tagging prowess for details.
Yes - that would be ideal, especially if there is likely to be disagreement or a wider perspective is needed. (which is basically everything in OSM )
(ex: for shop=gold_buyer - this is common in some places, but in other regions these shops might buy all kinds of metals and jewels, or may be part of the business of a pawn shop)
Absolutely not - your contributions are a benefit to the project.
Agreed - itâs unreasonable to expect everything to go through the proposal process. If itâs a particularly contentious tag - the discussions here on the forum are (imo) sufficient.
Well, I disagree with that. I appreciate your contributions.
I donât think itâs fine for iD/NSI/tagging-schema to add a preset without somewhat wider discussion. That discussion doesnât always have to be a full wiki proposal. But the iD ecosystem has an unfortunate history of creating faits accompli that only reflect the experiences of 2-3 people on iD-related github and then propagating them via prompts to âupgrade tagsâ.
I believe editor presets, especially in OSMâs default editor, should mostly be for tags which have already gone through some kind of vetting which helps confirm that they work for both mappers and data consumers.
Significant organic usage in both the OSM database and applications of different types would provide this signal. So would some kind of intentional process (of which a wiki proposal would be one possible example). But a tag which is rarely used and undiscussed likely shouldnât be part of editor presets.š
(š Except, in editors which support this feature, custom presets which a mapper actively chooses to install.)
Anecdote: Recently a new building= was considered for iD. After some cautious comments from maintainers, I separately replied on the wiki discussion, without knowing the activity on iD. In reality, it was almost all from a mass addition years ago. The wiki article was created last year, and doesnât match the actual usage. Both the wiki author, and iD contributor have misinterpreted it literally without basic research, which is obvious by simply looking at the Taghistory graph on the landing Taginfo âoverviewâ tab.
Given that iD already suggests autocompletes regardless for better or worse, a preset is not absolutely necessary to promote their use. If technically feasible, I would suggest adding a 3rd intermediate method between autocompletes and presets, to have âverifiedâ autocompletes that would function as less established suggestions than presets.
Although we would then, of course, have to work out an optimum number! Just off the top of the head, I would 1000 uses definitely, 500 probably / possibly, <100 no?
As a general observation I donât believe there is a good solution for this given the current restraints.
As I pointed out to @Mateusz_Konieczny privately in prior discussions, it isnât the low usage count itself that is the issue, there are objects that just by there very nature are quite rare and nobody would expect them to be mapped 10â000s of times.
The causes for the tensions are more:
the leverage provided by having a specific tagging enshrined in iD that leads to any alternative taggings, concerns etc. being moot,
the lack of coordination with other presets sources by the maintainers of id-tagging-schema, in particular with JOSM and Vespucci, leading to competing tagging for the same real world objects,
the absence of support for custom presets in iD. If anything Vespucci relies even more than iD on presets for tagging, but because weâve âalwaysâ (since 2012) supported custom presets, there is no pressure to include niche tagging in our default presets (though they are by far the most complete set).
And it isnât simply a case of just supporting âapprovedâ tagging schemes. Not only is there sensible and in use tagging outside of the approval process, quite often schemes get approved that donât make any sense and clearly shouldnât be alleviated to main stream until they have actually proven themselves (see the recent education proposal for example).
There is a small condition that can skew the information we receive from the OSM wiki when consulting certain TAGs, it is related to the Language in which it is consulted.
Explained my process= when I have doubts about a key=value always I consult the wiki in English or German and then I have to make a balance to select the best option to faithfully represent what I want to map. In my particular case, as I am a Spanish speaker, the information in Spanish that I find on the wiki may be incomplete, incorrect, poorly translated, or point to regionalisms. In Spanish we also have variations with meanings similar to those that exist between the English spoken in England and in USA but multiplied by 21, so depending on the nationality of who edited the OSM wiki, the key=value selection process is facilitated or not.
Adding an alternative labeling scheme that is less used or not established and combined with possibly poor documentation on the wiki depending the query language could make things worse considering that iD is the gateway to editing in OpenStreetMap.
It took me some time to understand the correct meaning of lagoon as a different element from the diminutive of lake, in Spanish laguna (lagoon) It is a small lake.
It works fine as you have done so far, it is up to us mappers to properly research what we want to map.
I have always been of the opinion that although we must make it easier to use tools, we cannot expect a shovel and a pickaxe to dig a mine on their own. Whoever has time to write and suggest changes on Github also has time to search the wiki and taginfo to find the best option that best describes an object.
Please donât, or at least not until you complete your current task, leaving your current job in the hands of someone less experienced will make things more complicated and confusing.
P.S. NSI in Spanish are crazy, the things Iâve seen, now for a newbie it must be a source of continuous doubts, errors and headaches.
For shop=* and probably amenity=* and craft=*, I think we should be more lenient to create presets for less well established values. The frequency of such features vary widely from region to region: in some they are common (but possible mis-tagged because of a lack of a preset), in others they may not exist at all.
In my region (Bulgaria), mobile phones are almost exclusively sold at service providers (shop=telecommunication) and in webshops, while there are plenty of shops that sell mobile phone accessories and repair mobile phones but donât sell mobile phones. However, the only apparently suitable preset that shows when searching for âmobileâ in iD is for shop=mobile_phone, so this is often selected by mistake. I guess that if there were presets for shop=telecommunication, shop=mobile_phone_accessories and craft=electronics_repair + electronics_repair=phone that can be found when searching for âmobileâ, tagging would be much more accurate. However, this is only an example that applies to one region, and in other regions the frequencies of features for mobile phone-related businesses might be completely different.
The higher goal is to promote appropriate tagging, and if the introduction of a shop preset promotes correct tagging in one region (no matter how small) without causing tagging mistakes in others, it should be introduced. That it doesnât occur in the rest of the world should not be a reason not to introduce it.
That would seem to simply be an issue with the synonyms/terms in iD and not with the presets themselves.
Assuming it is reasonable to have some properties of a RWO (real world object) defined by sub-tags and not requiring 100â000s of top level tags and corresponding presets.
)