osmprefs a poor choice for URL Scheme

[andrewg_oz]

I'm concerned that "osmprefs" as the URL scheme is too generic. IMHO we should be using the "vespucci" scheme!

That way we could extend the URL beyond just preferences. I'm thinking here about what might be needed to support OAuth. OAuth needs to take the user to a web site for authentication, then does a "callback" to a URL we supply. I presume that URL could be a "vespucci" scheme URL that launches Vespucci into an appropriate activity.

Cheers,

Andrew

[Marcus Wolschon]

Sounds reasonable.

What is everyone's oppinion about releasing in the market?

[andrewg_oz]

Not yet! I'm currently tweaking the tag editor and would like to add way spending to the EasyEdit mode. How about we target for a release next week?

Andrew

[Marcus Wolschon]

Sounds good.
I wasn't thinking about "right now" anyway.

[Jo]

Where can I find a version to beta test in the mean time? With the latest from Jan, I can't switch on the creation of GPX traces.

Would it be possible to keep track of which tags usually require numerical input and switch the on screen keyboard accordingly?

The same question for values that will almost always start capitalised?

I believe it would improve usability tremendously.

I'm adding rwn_ref a lot lately. Is there a place where I can add this to what gets autocompleted? It would be really nice if it were learning this by itself...

Thanks for all the good work.

Polyglot

2012/9/6 Marcus Wolschon <marcus....@gmail.com>

[Marcus Wolschon]

On Thu, Sep 6, 2012 at 9:05 AM, Jo <winf...@gmail.com> wrote:

Where can I find a version to beta test in the mean time? With the latest from Jan, I can't switch on the creation of GPX traces.

Would it be possible to keep track of which tags usually require numerical input and switch the on screen keyboard accordingly?

I thought about doing that for house numbers but sadly they are just *mostly* numerical and Android doesn't support
a way to choose numerical input mode without restricting input to just numerical values.
(At least none that I'm aware of.)
Would make my own house-number tagging so much easier to have large 0-9 buttons instead of a QWERTZ keyboard.

Currently we only have autocomplete and a special autocomplete for nearby street names.
 

The same question for values that will almost always start capitalised?

I believe it would improve usability tremendously.

I'm adding rwn_ref a lot lately. Is there a place where I can add this to what gets autocompleted? It would be really nice if it were learning this by itself...

I'm not aware of the rwn_ref tag.
What does it represent?

 

[andrewg_oz]

s/spending/appending/

Phone auto-correct strikes again! :-(

I've just checked in my TagEditor improvements (r314) and changed the URL scheme to vespucci (r315).

On Thursday, September 6, 2012 1:24:18 PM UTC+8, Marcus Wolschon wrote:

Sounds good.
 I wasn't thinking about "right now" anyway.

It sounded "sooner" rather than "later" to me! ;-)

I think the new editor is well worth getting out ASAP, but there are a couple things I'd like to get in before we release.

As I've mentioned elsewhere, the new EasyEdit mode successfully rolls just about all the functionality of the previously separate editing modes into a single mode. I *really* dislike applications that operate in modes. What I really, really want is to get *all* the existing editing functionality into the EasyEdit mode. At that point we could remove the editing modes entirely and just use EasyEdit, but I am *not* advocating that for this release. There should be a transition release with all the modes in it so that people used to the separate modes aren't faced with a sudden change. The release after can drop all the modes.

So that we can get the best feedback in relation to EasyEdit, I feel it is important for it to do everything the separate modes can do. Currently what is missing is: Append and File OpenStreetBug. Jan has already pointed out that Append can be achieved by creating a new way and merging/joining with the target way. I consider that to be quite different from how Potlatch and JOSM currently work. Rather than a New/Merge workflow, they default to an Append/Split workflow. IMHO our users will be looking for an "append" function, so therefore we should provide one.

What I'm thinking is that when an end node of a way is selected, there is an extra "Append" action available. Selecting that will flip the selection to the way and change the context to "Create way" (but actually appending to the way, not creating a new way). That should cover the append function.

That leaves "File OpenStreetBug". I know Jan doesn't like the idea of a pop-up context menu, but I can't think of anything better. Specifically, what I'm thinking is a long-press should pop up a menu asking if a bug should be filed (Yes/No). If Yes, the bug is created as "File OpenStreetBug" does now. If No, the existing EasyEdit long-press processing takes place to create a node/way. Note that all this only occurs if the user has enabled OpenStreetBugs in the preferences. If that is disabled, there will be no pop-up, and a long press will behave exactly as it does in EasyEdit right now.

I'm happy to consider alternatives. To me, the ultimate goal is to be able to remove editing modes entirely from the UI. i.e. no "OpenStreetBug" mode. Have I mentioned that I really dislike modes? :-)

When Append and File OpenStreetBug are integrated into EasyEdit, that will be a good time for the release. I can't think of anything else that would hold things up?

Andrew

[andrewg_oz]

On Thursday, September 6, 2012 3:48:05 PM UTC+8, Marcus Wolschon wrote:

On Thu, Sep 6, 2012 at 9:05 AM, Jo <winf...@gmail.com> wrote:

Where can I find a version to beta test in the mean time? With the latest from Jan, I can't switch on the creation of GPX traces.

Would it be possible to keep track of which tags usually require numerical input and switch the on screen keyboard accordingly?

I thought about doing that for house numbers but sadly they are just *mostly* numerical and Android doesn't support
a way to choose numerical input mode without restricting input to just numerical values.
(At least none that I'm aware of.)
Would make my own house-number tagging so much easier to have large 0-9 buttons instead of a QWERTZ keyboard.

Currently we only have autocomplete and a special autocomplete for nearby street names.
 

The same question for values that will almost always start capitalised?

I believe it would improve usability tremendously.

I'm adding rwn_ref a lot lately. Is there a place where I can add this to what gets autocompleted? It would be really nice if it were learning this by itself...

I'm not aware of the rwn_ref tag.
What does it represent?

http://wiki.openstreetmap.org/wiki/Key:rwn_ref

 

@Polyglot: Currently, all our autocompletes come from a copy of the JOSM presets file we've embedded inside Vespucci. The copy we have doesn't mention rwn_ref and I haven't checked if JOSM have revised their file since we grabbed our copy. I note that Jan has added something to do with custom presets as part of his GSoC project. It's in the preferences, but I don't know how that works. I think we need some additions to our wiki?!

Also, I concur with Markus in relation to custom keyboards and capitalisation. Android makes that sort of thing difficult. Not only that, but somewhere there would need to be instructions telling Vespucci which OSM keys were numeric versus text versus capitalised. The logical place would be the presets file, but JOSM makes no provision for that sort of thing. In short, it's way too hard to consider right now! :-(

[Marcus Wolschon]

On Thu, Sep 6, 2012 at 4:45 PM, andrewg_oz <andrew....@gmail.com> wrote:

Sounds good.

 I wasn't thinking about "right now" anyway.

It sounded "sooner" rather than "later" to me! ;-)

Well, the market version is already very old. ;)

As I've mentioned elsewhere, the new EasyEdit mode successfully rolls just about all the functionality of the previously separate editing modes into a single mode. I *really* dislike applications that operate in modes. What I really, really want is to get *all* the existing editing functionality into the EasyEdit mode. At that point we could remove the editing modes entirely and just use EasyEdit, but I am *not* advocating that for this release. There should be a transition release with all the modes in it so that people used to the separate modes aren't faced with a sudden change. The release after can drop all the modes.

I'm not sure we should do this.
The reason is simply to avoid accidential changes because mobile input while walking, riding a bicycle,
being shaken around in a bus or train,... is much more imprecise then in the lab.
It should be easy to make small, intended changes without fighting the UI just because you have a hard time
tapping without swiping/... .

I'm all for making the EasyEdit mode more powerfull but I'm reluctant to remove the existing modes.
The current UI paradigm is to have the ActionBar and context sensitive ActionModes.
So the whole platform has modes as a concept.
On the desktop this is avoided to make all functionality easy to access but in our case
I'm not that sure about making things too easy to access. You'd be either fighting constant confirmation and feedback
or making accidential changes with lots of either UNDO or not noticing you made a change or searching
for the change you are reported to have made.

So that we can get the best feedback in relation to EasyEdit, I feel it is important for it to do everything the separate modes can do. Currently what is missing is: Append and File OpenStreetBug. Jan has already pointed out that Append can be achieved by creating a new way and merging/joining with the target way.

How would you append a single node then? You can't create a way with less then 2 nodes.

That leaves "File OpenStreetBug". I know Jan doesn't like the idea of a pop-up context menu, but I can't think of anything better.

Me neither. I don't like it but can't think of a better way.
Problem is, how to give hints that long-pressing is actually doing anything.

Marcus

[Jo]

2012/9/6 andrewg_oz <andrew....@gmail.com>

On Thursday, September 6, 2012 3:48:05 PM UTC+8, Marcus Wolschon wrote:

On Thu, Sep 6, 2012 at 9:05 AM, Jo <winf...@gmail.com> wrote:

Where can I find a version to beta test in the mean time? With the latest from Jan, I can't switch on the creation of GPX traces.

Would it be possible to keep track of which tags usually require numerical input and switch the on screen keyboard accordingly?

I thought about doing that for house numbers but sadly they are just *mostly* numerical and Android doesn't support
a way to choose numerical input mode without restricting input to just numerical values.
(At least none that I'm aware of.)
Would make my own house-number tagging so much easier to have large 0-9 buttons instead of a QWERTZ keyboard.

Currently we only have autocomplete and a special autocomplete for nearby street names.
 

The same question for values that will almost always start capitalised?

I believe it would improve usability tremendously.

I'm adding rwn_ref a lot lately. Is there a place where I can add this to what gets autocompleted? It would be really nice if it were learning this by itself...

I'm not aware of the rwn_ref tag.
What does it represent?

http://wiki.openstreetmap.org/wiki/Key:rwn_ref

Yes, I'm mapping a new addition to the walking node networks which are sprouting like mushrooms in Belgium

 

@Polyglot: Currently, all our autocompletes come from a copy of the JOSM presets file we've embedded inside Vespucci. The copy we have doesn't mention rwn_ref and I haven't checked if JOSM have revised their file since we grabbed our copy. I note that Jan has added something to do with custom presets as part of his GSoC project. It's in the preferences, but I don't know how that works. I think we need some additions to our wiki?!

Also, I concur with Markus in relation to custom keyboards and capitalisation. Android makes that sort of thing difficult. Not only that, but somewhere there would need to be instructions telling Vespucci which OSM keys were numeric versus text versus capitalised. The logical place would be the presets file, but JOSM makes no provision for that sort of thing. In short, it's way too hard to consider right now! :-(

That's really unfortunate. Oh well, maybe one day...

Polyglot

[andrewg_oz]

On Thursday, 6 September 2012 23:06:34 UTC+8, Marcus Wolschon wrote:

On Thu, Sep 6, 2012 at 4:45 PM, andrewg_oz <andrew....@gmail.com> wrote:

I'm not sure we should do this.
The reason is simply to avoid accidential changes because mobile input while walking, riding a bicycle,
being shaken around in a bus or train,... is much more imprecise then in the lab.
It should be easy to make small, intended changes without fighting the UI just because you have a hard time
tapping without swiping/... .

I always survey on a bicycles, and I always stop before whipping the phone out to edit :-) Same for walking. I haven't been a passenger in a vehicle and tried to map, though.

 

I'm all for making the EasyEdit mode more powerfull but I'm reluctant to remove the existing modes.
The current UI paradigm is to have the ActionBar and context sensitive ActionModes.
So the whole platform has modes as a concept.
On the desktop this is avoided to make all functionality easy to access but in our case
I'm not that sure about making things too easy to access. You'd be either fighting constant confirmation and feedback
or making accidential changes with lots of either UNDO or not noticing you made a change or searching
for the change you are reported to have made.

I think it's difficult to make accidental tag changes. Accidental geometry changes are possible, and that has happened to me. The new Undo feature goes a long way to helping, but perhaps some sort of a geometry lock/unlock would be the solution. It wouldn't prevent creation of new nodes and ways, but prevent accidental dragging of existing nodes. 

 

So that we can get the best feedback in relation to EasyEdit, I feel it is important for it to do everything the separate modes can do. Currently what is missing is: Append and File OpenStreetBug. Jan has already pointed out that Append can be achieved by creating a new way and merging/joining with the target way.

How would you append a single node then? You can't create a way with less then 2 nodes.

A node by itself would also get the "Append" action.

 

[Marcus Wolschon]

On Thu, Sep 6, 2012 at 5:31 PM, andrewg_oz <andrew....@gmail.com> wrote:

On Thursday, 6 September 2012 23:06:34 UTC+8, Marcus Wolschon wrote:

On Thu, Sep 6, 2012 at 4:45 PM, andrewg_oz <andrew....@gmail.com> wrote:

I'm not sure we should do this.
The reason is simply to avoid accidential changes because mobile input while walking, riding a bicycle,
being shaken around in a bus or train,... is much more imprecise then in the lab.
It should be easy to make small, intended changes without fighting the UI just because you have a hard time
tapping without swiping/... .

I always survey on a bicycles, and I always stop before whipping the phone out to edit :-) Same for walking. I haven't been a passenger in a vehicle and tried to map, though.

I never stop to edit but do it one-handed while walking.
(That's why I really like slide-keyboards. The typing thumb is also helping in holding the phone.)
Mostly house-numbers and other such metadata with only very few geometry-changes.
 

 

I'm all for making the EasyEdit mode more powerfull but I'm reluctant to remove the existing modes.
The current UI paradigm is to have the ActionBar and context sensitive ActionModes.
So the whole platform has modes as a concept.
On the desktop this is avoided to make all functionality easy to access but in our case
I'm not that sure about making things too easy to access. You'd be either fighting constant confirmation and feedback
or making accidential changes with lots of either UNDO or not noticing you made a change or searching
for the change you are reported to have made.

I think it's difficult to make accidental tag changes. Accidental geometry changes are possible, and that has happened to me. The new Undo feature goes a long way to helping, but perhaps some sort of a geometry lock/unlock would be the solution. It wouldn't prevent creation of new nodes and ways, but prevent accidental dragging of existing nodes. 

But would make editing geometry wich is found to be off much harder.
Let's first complete the missing functionality and then have a look at this, okay?
One step at a time.

[Jan Schejbal]

Am 2012-09-06 17:01, schrieb andrewg_oz:
> I note that Jan has added something to do with custom presets as part
> of his GSoC project. It's in the preferences, but I don't know how
> that works.

I have added some documentation in the wiki. You can add a URL to a
preset XML file in the preferences. The preset will then be downloaded
and you can select it.

Kind regards,
Jan

[andrewg_oz]

On Monday, September 10, 2012 10:55:41 AM UTC+8, Jan Schejbal wrote:

I have added some documentation in the wiki. You can add a URL to a
preset XML file in the preferences. The preset will then be downloaded
and you can select it.

In other words:

http://josm.openstreetmap.de/wiki/Help/Preferences/Map#TaggingPresets

?

BTW, I went looking on our code.google.com wiki first and didn't find anything new. Then I thought about looking on the OSM wiki. I think there is now a bit too much technical info in our OSM wiki entry, which would be better moved to our project pages. I also think we need revised documentation in light of our (forthcoming) new version. I'll see if I have time next weekend.