[josm-dev] Common presets for OSM editors?

[Paul Hartmann]

On 23.06.2015 17:23, Dirk Stöcker wrote:
> On Tue, 23 Jun 2015, Paul Hartmann wrote:
>
>> We already have a mechanism to include previously defined "chunks" by
>> reference in the defaultpresets.xml file. This could be used to
>> include presets from the editor-presets.xml file at the correct place
>> (or not).
>> Preferably, when we make the includes, the result should be unchanged
>> or an improvement.
>
> That is unlikely. When the result is the same then it's a license
> violation. And to have a start from scratch improve JOSM presets
> everywhere which have many man-months work included is impossible.
>
> And a "do the same but slightly modified" I would reject, because that
> would invalidate all translators work for nothing.
>
>> Given all that, I see no major reason to block this initiative. We
>> would not drop what we have, but slowly migrating to something else.
>
> You (all) know my opinion about this approach [...].

I know your concerns about abandoning our imagery database. There we 
have a comprehensive and well established wiki-based system. A fairly 
large number of users contribute imagery sources on a regular basis. 
When WMS/TMS URLs change, this gets updated pretty fast. All that with 
very little work on our part.

I can understand that it is a risk to drop the wiki-system in favor of a 
github repository, where we don't know yet, if we would get to the same 
level of participation.

However, you have to acknowledge, that it is a completely different 
situation with the core presets. We could, right now, move the 
defaultpresets.xml file to a github repository, and include it as an svn 
external repository. (As we do for github-hosted plugins areaselector 
and conflation to simplify translation.) There is no major technical 
reason not to do this.

Therefore I don't understand why you are clinging to the JOSM 
infrastructure in this case. It seems natural to start on neutral ground 
for a project with a mission to conciliate.

For the license issue, it does not matter where the files are hosted.

I would agree, that the whole project is highly ambitious, because of 
the difficulties and workload involved. But if someone (or a group of 
people) is very committed, it's not impossible to solve these problems.

As long as we go in small steps and selectively import the parts that 
have been unified in a reasonable way, there is no loss on our side.

Paul