Guys, thanks a lot, I do have the answer. The script is not generic.
Have a nice day, jiri On 05/09/2018 02:50 PM, Michael Zangl wrote: > Hi, > > About your concrete example: There are several questions to think of: > > * Is your functionality a generic task? (in your case, this would be > something like "create a convex hull") > > * Is that functionality required by a lot of users? > > * Is your functionality approved by the community? Or will there be > objections? In your case, you should especially mind if your plugin > creates "correct" results and if it can be applied by a unexperienced > user without creating incorrect data. > > * Does it integrate into JOSM in an intuitive way? We try not to add > more buttons to the main menu. A nice example is the reworked download > dialog last year: It added some overpass download features while at the > same time making the UI easier to understand. > > > So if there is a place where this feature could be included that does > not interfere with other functionality (e.g. in a preset, ...) and is > universally usable, it can/should be included in core. In your case, the > script is so special that it may be very useful for other people doing > exactly the task you do, but not for the general audience of JOSM. This > is why a plugin is best in this case. > > > There are several more reasons why we add a functionality to core. They > include: > > * It is a function that allows basic access to the Openstreetmap data. > Like the notes layer: There are probably relatively few people using it > and it would be easy to extract to a plugin, but it is a traditional > feature of the OSM website. > > * It is a function that many other plugins / workflows may depend on. > Like downloading Data using Overpass. > > * It is a feature that is used by JOSM internally and where providing it > for the user just means an other button, but not maintaining more code. > Like the Join overlapping Areas tool. > > * The author of that functionality had core commit access and just was > too lazy to write a plugin for it. One example I did are the color > filters on imagery layers (mainly because they required core > modifications any way and were much easier to integrate that way). > > > Michael > > > On 09.05.2018 07:25, Jiri Hubacek wrote: >> Dear JOSM devs, >> >> I would like to ask question about the JOSM enhancements. Where is the >> line between functionality acceptable upstream and the feature that >> should be in separate plugin? >> >> The concrete example - I wrote some script for automatic creation of >> residential area around the selected buildings. I rewrote it to Java to >> be able to push it upstream but it looked too specific to be included in >> "Tools" menu. So I created the plugin (mapathoner). Are there any >> guidelines for these decisions? >> >> Thanks, >> jiri >> > >
