Modify

Opened 12 years ago

Closed 10 years ago

Last modified 10 years ago

#7797 closed defect (fixed)

prompt for website (obsolete-proof, else contact...?) in preset for school, shop etc.

Reported by: A_Pirard Owned by: team
Priority: normal Milestone: 14.01
Component: Internal preset Version: latest
Keywords: preset link Cc: A_Pirard

Description

I read several similar requests and I'm up to date (5267).
But when I preset a school, town hall, shop ... I see no prompt for

  • principally a website as it normally covers all the other information in a way with no risk to become obsolete
  • alternatively (if no site or one lacking that info): embedding (appending) the contact preset

I think it's important to suggest, especially the novice, to add this info.
And to do it with the correct tags (contact: ...)

Attachments (0)

Change History (19)

comment:1 by simon04, 12 years ago

Component: CoreInternal preset

And to do it with the correct tags (contact: ...)

Recently, we had a discussion about the two contact schemes: see #6461.

Contact information can be added to basically anything w/ people involved. Therefore we have a separate contact preset. I'm unsure whether to add them to all presets. There might be other opinions, though …

comment:2 by A_Pirard, 12 years ago

Thanks for your attention.

You're right, it's overkill.

The idea is mostly to *prompt* the user for the information.

Show that it exists and suggest to use it (take me by the hand :-))

Hence, one/two buttons to pop contact presets up would be OK to do that.

I would add the website, though, because it stands out and can be used alone.

comment:3 by A_Pirard, 11 years ago

For an existing object, I have seen a "contact" button above the Properties Window.
This is almost what I call a "prompt" and it would be nice to see it in the preset window while creating the object.
The label might be "WWW & contact" in case someone decides that a contact makes no sense for that particular object while WWW may apply to almost anything.

in reply to:  3 comment:4 by stoecker, 11 years ago

Replying to A_Pirard:

For an existing object, I have seen a "contact" button above the Properties Window.

This is simply a check of the presets. It shows all matching presets. It will appear when contact information is entered.

That is no solution for what you have in mind.

comment:5 by skyper, 11 years ago

I have some presets which could be included like contacts, e.g. payments, addr:* .

Overall would be a nice feature.

comment:6 by skyper, 11 years ago

Keywords: preset link added

See also #8959

comment:7 by A_Pirard, 10 years ago

I have just added a shop and preset "shop" still only prompts for name and opening hours.
This bug focuses on website (Annotation Contact), but let us recall that Annotation Address Information is mandatory.
There is no prompting for them in many places.
Would patch for #9327 help either include those prompts or include a popup feature feature for them?

comment:8 by simon04, 10 years ago

In 6572/josm:

see #7797 - extend presets by <preset_link preset_name="..." /> to add a link to another preset, exemplified in "Education" presets

comment:9 by simon04, 10 years ago

Milestone: 14.01

Please make suggestions (best in form of a patch) for other links!

comment:10 by A_Pirard, 10 years ago

Oops, I had not spotted that comment 6 stating "preset link added" is exactly what I suggested. A bit terse ;-)
I suppose that writing "best in form of a patch" saves at least 50 people a ½ hour search ;-)
I'd gladly send patches, but that article adds even more questions. I'm no Java and I can't decently use svn for this.
I would gladly run and modify my own copy of defaultpresets and post a diff file at times.
But that page should indicate what standard Linux command to use, and...
most importantly, the presets should be recompiled without restarting JOSM repeatedly during one's real work.
That would really boost presets improvements.

in reply to:  10 ; comment:11 by stoecker, 10 years ago

Replying to A_Pirard:

I'd gladly send patches, but that article adds even more questions. I'm no Java and I can't decently use svn for this.
I would gladly run and modify my own copy of defaultpresets and post a diff file at times.

Usage of SVN has many advantages for us. Especially we get the patches in a format which is easy usable. You don't need to compile your own JOSM, but working in a SVN repository makes it easier for us (and you).

But that page should indicate what standard Linux command to use, and...

I nevertheless added the plain diff command.

most importantly, the presets should be recompiled without restarting JOSM repeatedly during one's real work.

That is no user visible change, so very low priority :-)

in reply to:  11 comment:12 by A_Pirard, 10 years ago

Replying to stoecker:

Replying to A_Pirard:

most importantly, the presets should be recompiled without restarting JOSM repeatedly during one's real work.

That is no user visible change, so very low priority :-)

So that helping JOSM is getting very low priority then :-(

comment:13 by simon04, 10 years ago

I understand that it is convenient to write dozens of feature requests and let the 2–3 currently active JOSM developers do all the implementation work …

Statements like "So that helping JOSM is getting very low priority then" make me feel really angry. I'm unsure whether that is due to missing understanding of how much effort that is to implement and test (plus many dependencies like validator tests relying on the presets) and the small gain (restarting JOSM takes less than 10 seconds on a recent computer). Just to let you know: the current 7047 lines in the defaultpresets.xml have all been written without that feature.

Btw: It's not me who requested this feature!

So far …

in reply to:  13 ; comment:14 by A_Pirard, 10 years ago

Replying to simon04:

Statements like "So that helping JOSM is getting very low priority then" make me feel really angry.

In principle, I should do as many other people do: just use JOSM.
But, helpfully and enthusiastically despite my age, I'm not the kind to take without return and I cooperate as much as I'm able to (also advertising JOSM and helping people use it). So, I am willing to make preset updates "during my real OSM work" (which is often very intricate). But that means saving the current, and sometimes up to 3, layers very often to .osm files, restarting JOSM (much more than 30 seconds on a busy computer, mind you), reopening the .osm files and 3 to 5 imagery layers and getting back to work. That's more than 2 minutes, ideally for each update, unless JOSM accepts badly tested presets.
So, statements like "That is no user visible change, so very low priority" take cooperation very lightly.
And, if you notice well, I repeat almost exactly what you say (as a consequence) and you get angry !!!???

Btw: It's not me who requested this feature!

And BTW, I'm not making suggestions for myself but for the benefit of all. My preset suggestions aim at making better presets and hence better tagging. I even know faulty user presets that cause tagging errors, even GPS sending to the wrong way.
I'm not the kind to throw an "add sound" at developers. Doing some (light, mostly script) programming myself, I know what it takes and I always care to suggest good "value for sweat".
If I suggested preset_link, it's because many needed tags are missing from OSM and because those tags are missing from the presets and because they're a chore to add.
If I suggested a sort of making a "desktop" of links aka shortcuts to existing groups or items, it's because I'm aware that fumbling into the preset tree is not easy and that making a rearranged "what you find while walking in the street" desktop of links would not only ease the fumbling but also be suggestive for the palette or features to tag easily.
And now, if you underestimate a 10000 (7000 lines + much more user) preset updates @ 30 sec overhead each, you get 5000 hours (200 days, 3 working years) as the time that would have been spared to human kind if JOSM needed no restart.
As I'm visualizing the preset feature as a subsystem that should normally be started and stopped independently of JOSM, I suggest that restarting it is a really "good value for sweat" suggestion.
I'm not the kind to get angry. But I hope that this using more than 10 words will have made you understand that giving user cooperation working in the darkness a "very low priority" because it's not visible is sounding very very disappointing.

Best 2014 to the 3 of you ;-)

in reply to:  14 comment:15 by stoecker, 10 years ago

Statements like "So that helping JOSM is getting very low priority then" make me feel really angry.

In principle, I should do as many other people do: just use JOSM.
But, helpfully and enthusiastically despite my age, I'm not the kind to take without return and I cooperate as much as I'm able to (also advertising JOSM and helping people use it). So, I am willing to make preset updates "during my real OSM work" (which is often very intricate). But that means saving the current, and sometimes up to 3, layers very often to .osm files, restarting JOSM (much more than 30 seconds on a busy computer, mind you), reopening the .osm files and 3 to 5 imagery layers and getting back to work. That's more than 2 minutes, ideally for each update, unless JOSM accepts badly tested presets.

Usually you don't need to restart JOSM often for presets. Once is enough. Obvious validation issues can be checked with commandline tools or proper XML editors (nearly each editor shows you obvious validation errors, when loading the schema file is supported even the non-obvious ones are detected).

xmllint data/defaultpresets.xml --schema data/tagging-preset.xsd

Any problem with help is, that it only helps when it reduces the work. When we need to spend days to implement a feature only for someone to help us, then it is no help at all. If it would be easy to reload stuff during runtime, then we'd already implemented that. I don't know the exact situation here, but it is probably about one week work to do that. I.e. nearly no benefit and a lot of work --> low priority.

Except you find someone who actually WANTS to do that.

So, statements like "That is no user visible change, so very low priority" take cooperation very lightly.

No. Only realistic. Too often we get "I'd cooperate IF ...". In 99% of cases there comes nothing when IF is implemented.

And, if you notice well, I repeat almost exactly what you say (as a consequence) and you get angry !!!???

No. You changed the statement, so that it is accusatory.

As I'm visualizing the preset feature as a subsystem that should normally be started and stopped independently of JOSM, I suggest that restarting it is a really "good value for sweat" suggestion.

Please understand, that developers usually immediately implement nice little suggestions. For anything which takes more time, benefit needs to be evaluated. If you don't do the programming you are unable to do so. You simply have to accept, that something which may look easy to you actually is complicated as hell and other things you think are complicated take mere seconds to implement.

I'm not the kind to get angry. But I hope that this using more than 10 words will have made you understand that giving user cooperation working in the darkness a "very low priority" because it's not visible is sounding very very disappointing.

We have lots of additional presets and lots of updates to the internal one.

It's obvious that we don't have a problem here, so any improvement in the preset handling is only sugar on top. That does not mean that the new features (new XML tags) aren't a good thing, as some of these have been planned for a long time (the chunk and reference stuff for 5 years now).

comment:16 by Don-vip, 10 years ago

Ticket #8959 has been marked as a duplicate of this ticket.

comment:17 by A_Pirard, 10 years ago

I'll be short and conclude. You're speaking of long sessions dedicated to preset update. I'm speaking of updates found useful as they're met "during one's real work", remember. I testify that I don't feel at all like stopping the whole JOSM machinery to write and test each of them. And I suppose nobody does. That is not accusatory at all. It's stating a logical consequence, a fact good for you to know.
Now if you need no help, if you've got a full stock of presets waiting to be released, if someone with a computer science degree and a lifetime experience doesn't know what programming takes, I'd better indeed return to programming that SVG display program for Wikimedia instead.
Don't forget to review user presets and to put right those that cause wrong tags.

comment:18 by Don-vip, 10 years ago

Resolution: fixed
Status: newclosed

In 6618/josm:

fix #7797 - add contact link to shops, health, etc.

in reply to:  18 comment:19 by A_Pirard, 10 years ago

fix #7797 - add contact link to shops, health, etc.

Many thanks and happy New Year again.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.