New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Presets #164
Comments
Yay. Couple of half-baked thoughts: This is going to be the thing that people customise most for their own deployments of iD. So having the preset files human-editable is good. Probably the thing I regret most about P2 is that nobody (me included) can get their head round the .xml files P2 uses (JSON FTW), although I guess that does have the advantage that people are reticent with pull requests for the latest wiki-inspired tagging madness. There are too many damn tags and getting them all in a format that doesn't completely bamboozle the user is good. I quite like the idea of providing a text search box and then intelligently providing presets that match the search string - IIRC later versions of Mapzen did this. Recent versions of P2 have shown two lines of presets by default and then a 'Show more' disclosure button, which is another way to do it. Not every 'attribute' is of course covered by a traditional key/value tag (would that this was true). Increasingly concepts are represented in relations instead - routes, turn restrictions etc. - and sometimes this is a bit arbitrary, so cycle routes are done in relations, but road routes using the 'ref' tag. Mostly. The newbie user really shouldn't have to worry about that, iD should just sort it all out for them. There is a large degree of brainfuck involved in achieving that (e.g. searching for existing relations if relevant) and it may not be a target for an alpha release. ;) The binary preset/advanced distinction that P2 (and other apps) enforces is a bit of a blind alley. Ideally the presets should try and 'friendlify' as many tags as possible; any tags that haven't been used should be written out at the bottom using the usual key/value grid. So the original concept I had for the iD tagging interface was pretty much (assuming an already-tagged object):
...while the actual "you've created a new object, what do you want it to be?" interface would be based on the top two levels in node.json/way.json - so Roads -> Motorway, Railways -> Abandoned trackbed, etc. |
@systemed -- could what you call an 'editor' also be called a 'form'? |
Yes. |
Two additional thoughts: Two-step tagging Many keys only make sense together with other keys, while others function like main types. There is a certain overlapping hierarchy between keys. Further, not all keys make sense on nodes and ways. E. g. I'm suggesting a user interface that narrows down my first decision to a 'main' key. (Is this a road, a building, a point of interest, etc?), letting the user refine the decision in one or more second steps (is this a primary highway, a oneway, a church, a kiosk, etc.). Smart suggestions If a user manually adds a tag, how can we suggest this tag in a smart way. Good for repetitive tasks. |
What presets should we start with? What are the most widely used and important? Judging by taginfo:
From the technical side, I think it would be great if we could package together the rendering CSS and presets for a given 'topic' (e.g. each of the above). The basics would come prepackaged with iD but folks could write and distribute their own for specialized tagging. I think JOSM supports something like this (not sure it supports preset-specific CSS though). |
Any thoughts about compatibility with JOSM presets for these? importer, converter, etc |
Yeah, that's definitely something we'll keep in mind. One of my tasks on this is to put together a summary of prior art, so if anyone want to drop some links that would be great. |
There's some miscellaneous uploaded presets here: http://josm.openstreetmap.de/wiki/Presets But you may find the documentation about the format http://josm.openstreetmap.de/wiki/TaggingPresets of more use. It says it's outdated though! |
It would be wonderful to have some magic that converts the natural language of a newcomer into OSM tags. For example, with the tag boxes visible in alpha-0.0.0, a new mapper might type restaurant=Five Guys, or Aphrodite=nail salon. Can that be auto-magically converted into amenity=fast_food + cuisine=burger + name=Five Guys or shop=beauty + beauty=nails + name=Aphrodite ? Because that would be awesome. P2-style presets are part-way there; once you drag a preset from the right category, some basic tag suggestions appear in the form. Can this be extended to work without categories first? iD already breaks down contributions to nodes / ways as a quick "don't bother with highway-related tags for nodes". |
Discussion of XML schemes in diaries: http://www.openstreetmap.org/user/-karlos-/diary/18480 |
GMM has a great search. It might be a bit slow for experienced users of iD though. Maybe show the most recently used presets in the drop down before the user starts typing? Switching between searching for presets and manual tag entry would be interesting. |
The amount of presets and relations and, well, things to map can be quite overwhelming (Tom's example states more than 2000 categories) For new users, or users who are not very avid mappers this might just be a bit too much. It would be interesting if presets could be linked to a user profile. For example, if the HOT team is very interested in knowing where residential areas are in a region, they could configure their editor so that users who login for the first time would only show this preset. More advanced HOT contributors would have a different profile in their editor and see additional presets (camps, forest, just as samples) One way to do that would be to allow implementers of the editor to configure a preset-server and define a protocol between that server and the client to pull down presets, instead of baking the presets in the editor (like JOSM is doing for example) We are having a mobile app in beta that is doing this (in a very basic way). We can link presets to a user on the server, so when a user logs in to the mobile app, it downloads that single preset only. This allows for mapping exercises, where we capture things like 'All latrines' or "names of villages". Sounds very basic, but there are quite big areas in the world where anything more complex is a challenge. Especially on mobile, in the environment we operate in (Uganda) removing options was a thing we saw as an opportunity. And while at it: omg, this is looking great. Amazing job. |
Cobbling together ideas in the |
I was thinking about a possibility to choose tags with only one textbox. You write "residen" and you can choose from highway=residental, landuse=residental and building=residental (all tags with more than x occurrences). If you write "oneway" you can choose from oneway=yes, oneway=no, oneway=-1. My second idea is to have a tag cloud with tags most commonly used with the first tag written in. So if your first tag is highway=residental, you get a tag cloud with tags from this link: http://taginfo.openstreetmap.org/tags/highway=residential#combinations Of course, we should make a list of tags that should be filtered out, like "tiger:" and similar tags. |
Presets work is well underway; followups to individual issues. |
Okay, the return of presets. /cc @samanwpbb @jfirebaugh
Basic preset use cases:
Examples:
Issues:
This shouldn't clash too much with the existing tag editor, it should try to leverage stuff like taginfo, etc as much as possible.
We want this to look nice but also be similar enough to OSM styles.
The text was updated successfully, but these errors were encountered: