Skip to content
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

Closed
tmcw opened this issue Dec 3, 2012 · 17 comments
Closed

Presets #164

tmcw opened this issue Dec 3, 2012 · 17 comments

Comments

@tmcw
Copy link
Contributor

tmcw commented Dec 3, 2012

Okay, the return of presets. /cc @samanwpbb @jfirebaugh

Basic preset use cases:

  • Adding a road: recommend typical kinds of roads
  • Adding a building/amenity: recommend typical kinds of things, and then recommend typical fields, like telephone number, etc.

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.

@systemed
Copy link
Collaborator

systemed commented Dec 3, 2012

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):

  1. Tags are matched against each item in node.json/way.json, resulting in a list of 'editors'
  2. Editors are read one-by-one and written out in sequence
  3. Any tags not covered by an editor are written out to a grid at the bottom

...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.

@Jonobennett
Copy link
Contributor

@systemed -- could what you call an 'editor' also be called a 'form'?

@systemed
Copy link
Collaborator

systemed commented Dec 4, 2012

Yes.

@ghost ghost assigned samanpwbb Dec 4, 2012
@lxbarth
Copy link
Contributor

lxbarth commented Dec 13, 2012

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. oneway=yes only makes sense on a highway. building and highway keys cannot coexist on the same geometry. A node cannot be a highway.

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.

@jfirebaugh
Copy link
Member

What presets should we start with? What are the most widely used and important? Judging by taginfo:

  • highways
  • buildings
  • addresses
  • hydrography

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).

@timwaters
Copy link

Any thoughts about compatibility with JOSM presets for these? importer, converter, etc

@jfirebaugh
Copy link
Member

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.

@timwaters
Copy link

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!

@iandees
Copy link
Collaborator

iandees commented Jan 11, 2013

JOSM has a preset search functionality that it would be good to try and replicate. The text entered by the user would be really useful to collect so we can find out what things users are trying to map and build presets for them to guide their mapping.

Screen Shot 2013-01-11 at 3 37 26 PM

@ghost
Copy link

ghost commented Jan 28, 2013

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".

@tmcw
Copy link
Contributor Author

tmcw commented Jan 29, 2013

Discussion of XML schemes in diaries: http://www.openstreetmap.org/user/-karlos-/diary/18480

@tmcw
Copy link
Contributor Author

tmcw commented Jan 29, 2013

Class GMM

@iandees
Copy link
Collaborator

iandees commented Jan 29, 2013

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.

@batje
Copy link

batje commented Jan 30, 2013

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.

@tmcw
Copy link
Contributor Author

tmcw commented Jan 30, 2013

Cobbling together ideas in the presets branch now: https://github.com/systemed/iD/tree/presets

@ghost ghost assigned tmcw Jan 31, 2013
@Janjko
Copy link

Janjko commented Jan 31, 2013

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.

@jfirebaugh
Copy link
Member

Presets work is well underway; followups to individual issues.

nickplesha pushed a commit to mapillary/iD that referenced this issue Jun 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants