[patch] integrate josm tag help with osm wiki

[cmuelle8]

Hi,

it annoyed me that by pressing F1 in the property pane no help for tags was given - so I wrote a patch which takes you to the proper Key:X site in the osm wiki by intuitively pressing F1 after selecting a tag in the property pane..

it also works for relations if a type tag in the relation is set..

best regards and i'd be glad if somebody could apply it to josm core..,
cmuelle8

[cmuelle8]

PropertiesDialog.java.patch

[bastiK]

This feature would be a very hidden, as the user can't expect such a behaviour... F1 normally opens the internal JOSM help browser.

What about a right click menu to launch the wiki doc in browser?

Might be useful to have lookup for key=value, as well, e.g. ​http://wiki.openstreetmap.org/wiki/Tag:amenity=parking.

[cmuelle8]

Replying to bastiK:

This feature would be a very hidden, as the user can't expect such a behaviour... F1 normally opens the internal JOSM help browser.

I find it very intuitive, since it follows the simple semantic of getting "online-help" by pressing F1. Note that I do not overwrite the key binding for other parts of JOSM - and please also note that the semantic of F1 is "context-sensitive" in virtually any other application as well.. Seriously, getting general josm help when the user really expects help for a certain element (the tag) is not very useful - that is why i integrated this.

You might want to argue that the context-sensitive help of the properties dialog should display online help for the properties dialog of josm, true - but since it's use is very simple (simpler than knowing the semantic of the single tag key=value pairs), I think it does not hurt to have it this way..

Someone seeking help on the dialog panels will always get it using Help > Help (which directs to the josm wiki help at the moment where help topics for some of the dialogs exist, but not all of them).

What about a right click menu to launch the wiki doc in browser?

Maybe add this additionally (and show the key binding in this menu :) )? For me this would not suffice, since it is not fast enough. I'm a mapper myself and I'm continuously trying to optimize my workflow by using shortcut keys - using the mouse is fine for people getting accustomed to the software, but it's not useful for long-time users..

Might be useful to have lookup for key=value, as well, e.g. ​http://wiki.openstreetmap.org/wiki/Tag:amenity=parking.

This is true, I actually had this programmed, extracting the value from the HashMap that's in the second column of the table..

.., but I found it is too hard to decide WHEN to take the value into account (e.g. it does not make sense for ref=, name= etc.) If there is a subsite to every amenity key on the osm wiki, one could conditionally program the feature to only add a value it the key is /amenity/ - but this would lead to hardcoding a set of keys, where adding the value tag is useful - I did not want to do this)

regards,
christian

[bastiK]

Replying to Christian Müller <cmue81@…>:

Replying to bastiK:

This feature would be a very hidden, as the user can't expect such a behaviour... F1 normally opens the internal JOSM help browser.

I find it very intuitive, since it follows the simple semantic of getting "online-help" by pressing F1. Note that I do not overwrite the key binding for other parts of JOSM - and please also note that the semantic of F1 is "context-sensitive" in virtually any other application as well.. Seriously, getting general josm help when the user really expects help for a certain element (the tag) is not very useful - that is why i integrated this.

You might want to argue that the context-sensitive help of the properties dialog should display online help for the properties dialog of josm, true - but since it's use is very simple (simpler than knowing the semantic of the single tag key=value pairs), I think it does not hurt to have it this way..

agreed

Someone seeking help on the dialog panels will always get it using Help > Help (which directs to the josm wiki help at the moment where help topics for some of the dialogs exist, but not all of them).

What about a right click menu to launch the wiki doc in browser?

Maybe add this additionally (and show the key binding in this menu :) )? For me this would not suffice, since it is not fast enough. I'm a mapper myself and I'm continuously trying to optimize my workflow by using shortcut keys - using the mouse is fine for people getting accustomed to the software, but it's not useful for long-time users..

But it is an error to focus on advanced features, only. Then the software becomes unusable as is already the case with the various modifiers in add/select/delete mode.

Might be useful to have lookup for key=value, as well, e.g. ​http://wiki.openstreetmap.org/wiki/Tag:amenity=parking.

This is true, I actually had this programmed, extracting the value from the HashMap that's in the second column of the table..

.., but I found it is too hard to decide WHEN to take the value into account (e.g. it does not make sense for ref=, name= etc.) If there is a subsite to every amenity key on the osm wiki, one could conditionally program the feature to only add a value it the key is /amenity/ - but this would lead to hardcoding a set of keys, where adding the value tag is useful - I did not want to do this)

When curser is hovering over key column, use key; otherwise key=value. In context menu show both options. Another option is to scan the various links in the preset file.

[cmuelle8]

if there exists a "Tag:key=value" page in osm wiki (verified w/ wgArticleId of the actual webpage), use that for help, else use "Key:key"

[cmuelle8]

Replying to bastiK:

But it is an error to focus on advanced features, only. Then the software becomes unusable as is already the case with the various modifiers in add/select/delete mode.

yeah, strong point i agreed to before. i did not say that i did not want to see the option in the context menu as well.. it's just that it isn't coded yet :)

When curser is hovering over key column, use key; otherwise key=value. In context menu show both options. Another option is to scan the various links in the preset file.

good ideas.. at the moment i go online and look if the page in the wiki exists - which is a third idea. i like using the preset file, too, but i have not looked into the code enough yet, to know how to use it - is the PresetHandler the right adress to go to? - or some other object at runtime, I can query to get the links?

I would not want to explicitely parse that file myself (for the given purpose).

regards

[bastiK]

Replying to Christian Müller <cmue81@…>:

Replying to bastiK:

But it is an error to focus on advanced features, only. Then the software becomes unusable as is already the case with the various modifiers in add/select/delete mode.

yeah, strong point i agreed to before. i did not say that i did not want to see the option in the context menu as well.. it's just that it isn't coded yet :)

When curser is hovering over key column, use key; otherwise key=value. In context menu show both options. Another option is to scan the various links in the preset file.

good ideas.. at the moment i go online and look if the page in the wiki exists - which is a third idea.

Even better...

i like using the preset file, too, but i have not looked into the code enough yet, to know how to use it - is the PresetHandler the right adress to go to? - or some other object at runtime, I can query to get the links?

IIRC, for initialization of autocompletion it collections all key=value pairs from the presets. This might be a starting point.

[cmuelle8]

simplified page-exists determination, took locale into account

[cmuelle8]

Hi,

ok, the only thing missing is the context menu entry.. plz, if someone knows how to delete my other two patches (or crossline them), do that..

what's in store:

• take locale josm is using when determining the page
• look if the response code is a 200 - else use Key: - if Key: does not exist, use Map_Features webpage as a last resort

regards..

[bastiK]

does it work with openjdk?

[cmuelle8]

Replying to bastiK:

does it work with openjdk?

why should it not - because of the sun import declaration? i did not test with openjdk, but have a look here:

​http://hg.openjdk.java.net/jdk7/tl/jdk/file/be1ca1f90114/src/share/classes/sun/net/www/protocol/http/

[cmuelle8]

change eclipse autogenerated import from sun.net... to java.net.HttpURLConnection for portability..

[bastiK]

(In [3525]) see #5443 (patch by Christian Müller) - integrate josm tag help with osm wiki

[bastiK]

Does not work with spaces and other special character in tag value e.g. name=Main Street

There are issues with locales and redirection, e.g. DE:Tag:lit=yes (does not exist), Tag:lit=yes -> redirected to Key:lit. Should be DE:Key:lit. Simply changing the order is not enough to fix it.

I don't get it to work with relations as you cannot select an entry from the list.

[cmuelle8]

Replying to bastiK:

Does not work with spaces and other special character in tag value e.g. name=Main Street

this is fixed already, I didn't upload the patch yet, since I'm still working on the context menu with help - for newer josm users..

There are issues with locales and redirection, e.g. DE:Tag:lit=yes (does not exist), Tag:lit=yes -> redirected to Key:lit. Should be DE:Key:lit. Simply changing the order is not enough to fix it.

this is true, but a wiki problem - if a redirection in the german version for the entry in question existed, german locale would be shown. i do not want to reorder the links checked, since i could miss a specific site for a key=value pair in the default locale, when a Key:key entry for the josm locale exists. consider this:

/DE:Tag:amenity=studio   (missing in the wiki)  
/Tag:amenity=parking     (has a proper wiki entry, is not a redirection)
/DE:Key:amenity          (exists, proper wiki entry)

in this case I'd like to have the more specific english wiki entry rather than the last, localized, less specific version. so at this point we have to live with the inconsistent linkage in the osm wiki (or load parts of the page and see, if it is a redirection).

I don't get it to work with relations as you cannot select an entry from the list.

On my side this works - can you be more specific? It does not work if you are in the relation editor.. The key binding is for the propertyDialog only (for now at least) - if you select a way in the MapView you have the properties listed in the PropertyTable and below, if the way belongs to any relation, you find a MembershipTable

(single-click) selecting the Relation that the way is a member of and hitting F1 will bring you to the Relation:type wiki entry (where type is one of multipolygon, route, etc.)

[cmuelle8]

Replying to bastiK:

Does not work with spaces and other special character in tag value e.g. name=Main Street

error correction for the example above..

/DE:Tag:amenity=studio   (missing in the wiki)  
/Tag:amenity=studio      (has a proper wiki entry, is not a redirection)
/DE:Key:amenity          (exists, proper wiki entry)

[bastiK]

Replying to Christian Müller <cmue81@…>:

Replying to bastiK:

There are issues with locales and redirection, e.g. DE:Tag:lit=yes (does not exist), Tag:lit=yes -> redirected to Key:lit. Should be DE:Key:lit. Simply changing the order is not enough to fix it.

this is true, but a wiki problem - if a redirection in the german version for the entry in question existed, german locale would be shown. i do not want to reorder the links checked [...]

that's what i mean by it is not so easy to fix. Maybe load ​http://wiki.openstreetmap.org/w/index.php?title=Tag:lit%3Dyes&redirect=no and see if it is a redirection. But is a little ugly.

I don't get it to work with relations as you cannot select an entry from the list.

On my side this works - can you be more specific? It does not work if you are in the relation editor.. The key binding is for the propertyDialog only (for now at least) - if you select a way in the MapView you have the properties listed in the PropertyTable and below, if the way belongs to any relation, you find a MembershipTable

(single-click) selecting the Relation that the way is a member of and hitting F1 will bring you to the Relation:type wiki entry (where type is one of multipolygon, route, etc.)

try way that is member of exactly 1 relation and has no attributes. (otherwise it works for me)

[cmuelle8]

misc fixes and the popup menu feature for josm newbies

[cmuelle8]

adapted to bastiK's changes.., please apply only the last patch..

[cmuelle8]

adapted to bastiK's changes.., please apply only this last patch..

[cmuelle8]

Replying to bastiK:

that's what i mean by it is not so easy to fix. Maybe load ​http://wiki.openstreetmap.org/w/index.php?title=Tag:lit%3Dyes&redirect=no and see if it is a redirection. But is a little ugly.

ugly, but works - see latest patch..

try way that is member of exactly 1 relation and has no attributes. (otherwise it works for me)

did you already make this work in r3525? i've seen code from you checking for null on get("type").. i'd be happy to see the last patch soon, since it contains the URLEncoder thingy that does away with the spaces-in-string problem.

regards,
cmuelle8

[bastiK]

(In [3529]) see #5443 (patch by Christian Müller) - integrate josm tag help with osm wiki (improvements)

[bastiK]

Works.

Two more minor things:

• connection timeout (or at least put it in background thread)

• use proxy if selected by user

Maybe the default behaviour is already correct (haven't checked) but I'd guess it's not.

[bastiK]

Moved the bugs to new pages: #5464, #5465