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

Existing preset formats #1

Open
iandees opened this issue Jun 20, 2015 · 6 comments
Open

Existing preset formats #1

iandees opened this issue Jun 20, 2015 · 6 comments

Comments

@iandees
Copy link
Member

iandees commented Jun 20, 2015

Is there a way to maintain presets in a format that can support the existing major editors?

@1ec5
Copy link
Member

1ec5 commented Jun 20, 2015

Potlatch 2 doesn’t have quite as extensive a repertoire of presets, but here’s an example of a preset file. Vespucci uses a preset file apparently based on JOSM’s format. Merkaartor has its own format too.

Some additional considerations:

  • iD makes use of osmlab/name-suggestion-index and taginfo to expand the set of available tags beyond hand-documented presets.
  • Editors have distinct places for localized preset strings. For example, JOSM and Merkaartor presets are localized in-place, while iD’s preset strings are located in editor-wide localization files (translated via Transifex). A fork of Potlatch 2 adds preset localization (also translated at Transifex), but I’m unaware of any site that uses it.
  • Each editor has a different icon needs, and icons appear to be part of the preset definitions in most of these editors.

@1ec5
Copy link
Member

1ec5 commented Jun 20, 2015

iD and Potlatch 2 presets specify abstract “fields”, whereas JOSM’s presets define UI widgets in a specific layout intended for a modal dialog. JOSM’s approach may be incompatible with other editors, because each editor is laid out differently and built on very different UI toolkits. iD is built on HTML, which is far more freeform than some of the UI toolkits used by desktop editors. On the other hand, a mobile editor like Vespucci would have severe space constraints and relatively limited input options.

This project would be useful in terms of unifying presets as model objects / data, but it should be as generic as possible when it comes to input fields, to avoid forcing editor interfaces into a lowest common denominator.

@systemed
Copy link

In theory I'd be happy to adapt P2 to something common, even if that's just a formalisation of how iD does it. In practice... the P2 tagging UI wasn't something I wrote and I've always struggled with remembering how exactly it works, so I couldn't necessarily promise to spend a couple of days getting to grips with it and then rewriting it all, I'm afraid. But you never know.

Given the resistance of JOSM to adopting something as simple as editor-imagery-index, and messages like https://lists.openstreetmap.org/pipermail/josm-dev/2015-June/007420.html, I wouldn't expend too much effort on trying to get JOSM along for the ride.

All of which means: better to focus on a format for today and tomorrow's editors, rather than something that can be forced into such aberrations of yesteryear as Flex and Java. @1ec5's last para is spot on.

@simonpoole
Copy link

@1ec5 while it is true that JOSM includes some UI specific layout parameters, they can simply be ignored (which is what vespucci does) or used differently, and the rest does not have more semantic impact than say the check object in iD presets. It is difficult to see what you think yet another preset format could bring to the table given that JOSM already has everything and the kitchen sink.

@systemed there is nothing language specific about JOSM presets at all.

@bryceco
Copy link

bryceco commented Jul 3, 2015

In Go Map!! I'm using the ID preset files. The JOSM presets were a non-starter due to license, but even ignoring that I considered the iD presets to be more intuitive for novice users and better suited for a mobile interface.

But in principle I agree a shared preset definition file hosted in a neutral location would be a good thing.

@HolgerJeromin
Copy link

We should agree about the licence. Open another issue for that?

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

6 participants