[josm-dev] Discussion about Git (was: Apache mpoved to git, broken SVN external)

[Bodo Meissner]

Zitat von Dirk Stöcker :

Same issue. I've seen many external hosters dying over time  
(sourceforge does this right now finally), so relying on an external  
hoster when we can do it ourself easily is not a good idea.


I agree. But the selection of a hoster is a minor point. (with  
distributed VCS)


P.S. Maybe I'm simply already to old, but I don't understand that  
hype around Git. When I came from RCS and SCCS the CVS was a big  
improvement. SVN was a big improvement over CVS again.


I started with RCS, have used several version control tools, and am  
still using CVS, SVN, Git. I prefer Git (or Mercurial). When I have to  
use SVN, I try to use it with git-svn if possible.


But Git is not a followup to SVN but another philosophy. While it  
has many advantages it has also a set of disadvantages. For me SVN  
and Git are two different tools and selection which one should be  
used for a certain project depends on a lot of details.


I guess that's an FAQ theme. Suggestions to use Git pop up here from  
time to time.
I am involved with some other open source project which still uses  
CVS. I also get requests to move to Git. The main reason for not using  
Git is that there are scripts that use CVS commands, and I did not  
have time yet to adapt them to use Git instead of CVS.



For JOSM ATM disadvantages of Git overweight the advantages.


I would like to see a description of the disadvantages in a  
developers' FAQ list.



Bodo



___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] deleted text on Ru:WikiStart

[Bodo Meissner]

Zitat von Dirk Stöcker openstreet...@dstoecker.de:


On Wed, 19 Aug 2015, simson.gert...@gmail.com wrote:

a lot of text was deleted on Ru:WikiStart. Can someone with  
language skills please check if this is correct this way? Thanks.

https://josm.openstreetmap.de/wiki/Ru%3AWikiStart?sfp_email=sfph_mail=action=diffversion=51old_version=42sfp_email=sfph_mail=


Looks more like revision 45 goes berserk.


Looks as if the user simplified the documentation for beginners and  
wants to promote the Windows installer version over the jnlp  or jar  
versions.
He does not follow the concept that all language version should have  
similar structure and content, but I think he added useful information.


Maybe someone should ask him why he does not follow the concept and if  
these changes have been discussed in some Russian community.



Bodo





___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Netbeans // older josm code?

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 27.02.2011 18:41, schrieb Werner Horsch:

 I've tried
 a) running JOSM out of the IDE doesn't allow me to see the plugin and got a
 message JOSM strange version you should update

Hello Werner,

I usually worked on existing plugins with Eclipse. So I don't know if this also 
applies to Netbeans.

In Eclipse I debugged the plugin project but asked it to start JOSM's main 
class in the debug configuration.
(I think I always had the plugin installed in JOSM on my development system. 
Don't know if this has any influence on debugging JOSM with the plugin from 
Eclipse.)


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk1qwPUACgkQnMz9fgzDSqd2AACfTy22/hXQvgqeOgXKTYL9v2y5
U7EAnj0EScB2EM8CLH5I1SzG9JOOHhob
=Seus
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Proj4J - New plugin supporting 3000+ projections

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 25.02.2011 05:10, schrieb Josh Doe:

 I'd do so myself, but I don't want to be presumptuous and ask for an
 svn account.

Hello Josh,

I think it's OK if you do it yourself.
Since it's a new plugin it won't hurt anyone if it's committed to SVN. Put it 
next to hte other plugins.
Plugins are in the normal OSM SVN, not in JOSM SVN. It's easy to get an SVN 
account for the OSM SVN.


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk1nW/4ACgkQnMz9fgzDSqd0ngCdGInPKJv75yilbOsva7tjNDKn
5tkAn2s1zM0n6h0PzVh63KoF/CCxx71q
=8tRV
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Fwd: [OSM-talk] Landsat WMS is dead

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 09.01.2011 23:26, schrieb Stephan Knauss:
 Landsat WMS is dead. It looks like we had tiled WMS in the past. Someone 
 working to port it into imagery, yet?
 
 http://wiki.openstreetmap.org/wiki/User:Bomm#JOSM-WMS-Plugin_-_Tiled_WMS

I'm not working on this and I probably never will.

When I originally implemented NASA's tiled WMS, I asked for feedback but did 
not get any. At the same time major changes were implemented, so it was no 
longer possible to apply my modifications.
If anyone is interested, you are free to use my old patch as a base for a new 
implementation.


Bodo (bomm)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk0qT1kACgkQnMz9fgzDSqdM2QCfYNtWgfOdheFXApvlRrT+BT4I
s3UAn0eE3/WxTrpyMHzefpOA1ptfmbH/
=7aRf
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] WMS and remote-control

[Bodo Meissner]

 Am 25.08.2010 23:54, schrieb Stephan Knauss:

Sebastian Klein wrote:

Stephan Knauss wrote:

Sebastian Klein wrote:
How about adding the basic functionality into core? Providing the 
listener and accepting commands.
I consider this is a viable solution. It fixes the problem of version 
dependency between wmsplugin and remotecontrol. The core part of 
remotecontrol would go into JOSM main

[...]

Is this being worked on? Maybe for the next version after tested is 
released...

I'm not working on this and I will not.
I think the dependency between remotecontrol and wmsplugin is 
sufficiently handled.
If the basic functionality of remotecontrol would be part of JOSM core 
it would make it more difficult for me when I have to make changes.



Bodo

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Add nodes and ways via remoteControl

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 22.08.2010 10:31, schrieb Dirk Stöcker:

 If you can automate it, it may work.

Hello Dirk,

this is impossible. I cannot automatically detect if there are incompatible 
changes in remotecontrol.

 Otherwise you will find, that
 updating the version tends to be forgotten more often than it is updated.

You are right. If I go this way I can only add a comment that updating the API 
version is important, but I cannot make sure that I or future developers will 
never forget to update it.

 This is one of the reasons why josm has no upwards-compatibility for
 plugins.

The only possible thing would be to automatically update the API version on 
every change. But in this case it does not provide any advantage over using the 
SVN revision.

I think I will keep it simple:
WMSPlugin will not only check for a minimum SVN revision of remotecontrol but 
also for a maximum revision. Whenever remotecontrol gets recompiled with a new 
SVN revision, wmsplugin has to be updated. I will replace console messages with 
a normal message window to inform the user about this incompatibility.

What do you think about this solution?


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkxw6b0ACgkQnMz9fgzDSqd1ZwCfUwqmgzmnQ81VJJ3S/WWyVnvC
OB4AoJDkeFzL3F2keYt8fxevTm6WvqJX
=sk0b
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Add nodes and ways via remoteControl

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I added a getVersion method to remotecontrol. It returns an array of int values 
instead of an object with fields to avoid ClassNotFound when wmsplugin is 
loaded without remotecontrol.
On compatible extensions the minor version should be incremented, on 
incompatible changes the major version should be incremented and the minor 
version set to 0.
The handlers can individually specify the default value for the permission 
preference. Currently the default is false for add_node and true for the 
others.

As requested by Komяpa I also added a zoom command that does nearly the same 
as load_and_zoom without loading any data from the API.


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkxxiXYACgkQnMz9fgzDSqcC1gCaAsggbQRsthajsYZehcZk3YoI
1ocAnjLP5hdywkixI/0nwL20I7Tya/GD
=d9mN
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] WMS and remote-control

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 20.08.2010 16:33, schrieb Komяpa:

 If possible, would also be nice to have just zoom command
[...]

Done.
see http://wiki.openstreetmap.org/wiki/JOSM/Plugins/RemoteControl#zoom_command


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkxxigYACgkQnMz9fgzDSqcFQQCfWAz6JLWYxIujxWLOlmSQTDsk
0cMAoJw2NcF+cguDphuhkVjDIZrixNmL
=cdlh
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Add nodes and ways via remoteControl

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 22.08.2010 22:40, schrieb Sebastian Klein:
 Bodo Meissner wrote:
 I added a getVersion method to remotecontrol. [...] On compatible
 extensions the minor version should be incremented, on incompatible
 changes the major version should be incremented and the minor version
  set to 0.
 
 What is the minor version good for?

When I add a method to remotecontrol I will change the minor version only. An 
old version of wmsplugin can still use the new version of remotecontrol.
A new version of wmsplugin that needs the new method will not accept older 
minor versions of remotecontrol.
When I have to do incompatible changes I will change the major version. An 
older wmsplugin will never try to use a new major version of remotecontrol.
That's why I implemented a == check for the major version and a = check for 
the minor version.


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkxxkJAACgkQnMz9fgzDSqctnACfVSsmV+PyzMZPmH6PSke32uHb
A9sAniGZMbEuJvh+b2gYPkQGZsjvz8cb
=EZnF
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Add nodes and ways via remoteControl

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 20.08.2010 09:05, schrieb Sebastian Klein:

 Bodo Meissner wrote:

 My latest changes to implement remote control for wmsplugin
 made it impossible to change the default for an individual command. I
 think I should change this.
 I guess this will be an incompatible change, that means people who
 update only remotecontrol but not wmsplugin will probably get a hard
 error.
 
 There will always be people who have an old version of remotecontrol and
 now install wmsplugin

This is the simple case. wmsplugin checks for a minimum version of 
remotecontrol and does not try to use it if it's too old.

 and vice versa.

This is the complicated case because I cannot know up to which version 
remotecontrol will be compatible with the current version of wmsplugin.
The current wmsplugin will try to use an incompatible newer version of 
remotecontrol and probably get an exception.
 
 Imho a hard error (especially class not found) is not an option. Wms
 should not give an error since it uses reflection to find and execute
 the handler register method of remotecontrol.

When I experimented with remotecontrol and wmsplugin I sometimes got 
NoSuchMethodException and JOSM suggested to disable the plugin, but sometimes 
JOSM simply hung.
I don't know how to avoid this hanging.

 I will also implement a function to request the API version of the
 remotecontrol plugin. So in future wmsplugin will not use
 remotecontrol if it is too new.

I should have implemented a getVersion method with my first change, but now 
it's too late.
So I can avoid compatibility problems in future transitions but not for the 
next change.

 On the other hand remotecontrol should be able to handle multiple
 versions of the handler protocol or give a warning to the console, if
 the handler cannot be accepted for some reason.

My intention is that wmsplugin will use reflection to call the getVersion 
method. This will avoid any ClassNotFoundException when remotecontrol is not 
installed. Of course wmsplugin will call this method only if remotecontrol is 
loaded.
When remotecontrol returns a compatible version, wmsplugin will register its 
remote request handler, otherwise it will display a message that it cannot use 
remotecontrol.

 Sounds awfully complicated, but that's what you signed up for. :)

I think my solution is not that complicated but it will produce one 
incompatibility for the next transition as described above.


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkxwCXkACgkQnMz9fgzDSqfcUwCfcDzHEHlVK3nhnXc5W+1ZJDxs
J6AAn0srz+bT5ONZThG3k12IXNrosHCs
=BuIE
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Add nodes and ways via remoteControl

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 21.08.2010 20:48, schrieb Sebastian Klein:
 Bodo Meissner wrote:
 When I experimented with remotecontrol and wmsplugin I sometimes got
 NoSuchMethodException and JOSM suggested to disable the plugin, but
 sometimes JOSM simply hung.
 
 No console output?
 
 I will also implement a function to request the API version of the
 remotecontrol plugin. So in future wmsplugin will not use
 remotecontrol if it is too new.

 I should have implemented a getVersion method with my first change,
 but now it's too late.
 
 You can use reflection to check, if the method getVersion() exists. If
 not, this counts as version 0.

No need to do this. The next version of wmsplugin will register its handler 
only with a version of remotecontrol that has getVersion.
The problem is that I cannot change the existing wmsplugin.jar and this will 
not care about incompatible changes in remotecontrol.

(Maybe remotecontrol could use reflection on the RequestHandler subclass 
supplied at the registration call to find out the version of wmsplugin...
First: I'm not sure this will work. Maybe trying the registration will throw 
some exception. Second: This would get really complicated.)

 Let me try to summarize:
 wmsplugin.WMSRemoteHandler includes (compiles against) classes from
 remotecontrol plugin, but does not ship these classes. It relies on
 remotecontrol plugin to provide them.
 
 So each time the source code of remotecontrol.PermissionPref,
 remotecontrol.RequestHandler or
 remotecontrol.RequestHandlerErrorException changes, getVersion must
 return a new version number. This way wmsplugin can abort the
 registration and avoid an instantiation that would lead to ClassNotFound
 error.

... or NoSuchMethod error.

Exactly.

I'm not sure about adding interfaces or internal changes. Will wmsplugin 
compiled with a certain version of remotecontrol still work when I add a public 
method or change some private method?


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkxwLsQACgkQnMz9fgzDSqdybgCfWBbgwQPWNJY7WPsxbs7Ql2fw
QVoAoJ/7d/1MOrlSNvWRqnrjVpyEm4+Q
=eaJ4
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] WMS and remote-control

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 20.08.2010 16:33, schrieb Komяpa:

 If possible, would also be nice to have just zoom command, that
 won't load any data from OSM, but center view along bbox. If I've
 skipped it in documentation, please point me into it.

A zoom only command is not available. I will try to add this while working on 
the remotecontrol plugin.


Bodo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkxwL2cACgkQnMz9fgzDSqfLmQCeKRMcOS+hH6cZbnyYiU58CZaW
lXUAnj92iG2VucFlTGYt8mybN42hnVqs
=oPKw
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Mailing list configuration - reply address

[Bodo Meissner]

 Am 19.08.2010 19:57, schrieb Simone Cortesi:

a reply-to sent directly to the user is there just to prevent somebody
sending a personal mail to the whole list. any sufficiently advanced
mailer has a reply to all button.

+1
Thunderbird has a Reply to list button. This is active when it finds 
some mailing list headers.

A Reply-To: header makes it difficult to reply to the author.

Especially the subscribers of a developers' mailing list should know how 
to use (and configure) their MUA.



Bodo

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Add nodes and ways via remoteControl

[Bodo Meissner]

 Am 20.08.2010 01:59, schrieb Stephan Knauss:


The command is not only undocumented, but also the option to disable 
the command is not available in the config dialog. And default is 
enable...


The more I think about it the stronger gets my urge to change this 
behavior...


That's what I did now... 22702

I agree. My latest changes to implement remote control for wmsplugin 
made it impossible to change the default for an individual command. I 
think I should change this.
I guess this will be an incompatible change, that means people who 
update only remotecontrol but not wmsplugin will probably get a hard error.
I will also implement a function to request the API version of the 
remotecontrol plugin. So in future wmsplugin will not use remotecontrol 
if it is too new.



Bodo

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Mailing list configuration - reply address

[Bodo Meissner]

 Am 20.08.2010 02:17, schrieb Stephan Knauss:
Honestly: With the reply-to list add-On for Thunderbird I don't miss 
anything. It should be included in standard distribution.

Thunderbird 3.1.2 (don't know since when) has this ability by default.

Bodo

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] WMS and remote-control

[Bodo Meissner]

 Am 18.08.2010 23:49, schrieb Sebastian Klein:

So either the common protocol must be included in Josm core or
another possible solution would be to use reflection.


Yesterday I fixed the problem by using reflection in WMSPlugin.java to 
call functions of RemoteControlPlugin. (see WMSPlugin.initRemoteControl())

Maybe I can solve the problem by encapsulation.

Currently I use WMSRemoteHandler which is a subclass of 
org.openstreetmap.josm.plugins.remotecontrol.RequestHandler and this 
does not trigger the ClassNotFoundException.


I thought that it might be possible to move 
WMSPlugin.initRemoteControl() to some other class in wmsplugin.jar, 
maybe to WMSRemoteHandler and use normal calls instead of reflection.



Bodo

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] WMS and remote-control

[Bodo Meissner]

Hello Komяpa,

I modified the plugins remotecontrol and wmsplugin.
see
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/RemoteControl#other_commands
and
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/WMSPlugin#Remote_control

I hope this is what you imagined.
Please inform me about problems or suggestions.


Bodo
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/WMS-and-remote-control-tp5413841p5434261.html
Sent from the JOSM Development mailing list archive at Nabble.com.

___
josm-dev mailing list
josm-...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] WMS and remote-control

[Bodo Meissner]

 Am 18.08.2010 00:57, schrieb Stephan Knauss:
a while back I added the version command to enable web sites to detect 
a running JOSM.


I thought that a version number might be sufficient to let Websites 
know which commands are available in the reported protocol version.

That means I should increment the version number.

With the possibility to add arbitrary commands that seams to be not 
enough. I think it might be useful to provide a capabilities command. 
That would report back the available commands as well as the interface 
version of each command.

In theory this is a good idea.
Is there any website actually using the version number request?
Currently the website could simply try the command and check the response.

Should JOSM report only commands that are not disabled by configuration?
IIRC a non-existing command will produce the same response as a disabled 
command.



Bodo

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

[josm-dev] questions about plugin loading

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello all,

I started implementing remote control for WMS.
The remotecontrol plugin will provide an interface to register new handlers for 
additional commands and the WMS plugin will use this interface.
That means when the WMS plugin wants to make calls to the remotecontrol plugin, 
Josm must already have loaded this plugin.

If there is a guarantee that wmsplugin will always be loaded after 
remotecontrol, wmsplugin can register its remote control handler in its 
initialization. Otherwise wmsplugin must know when both wmsplugin and 
remotecontrol are loaded or when all plugins are loaded.

Is there a way to specify a dependency or a loading order? (wmsplugin requires 
remotecontrol or if remotecontrol is enabled it must be loaded before 
wmsplugin)
Does JOSM call a function of a plugin when all enabled plugins are loaded?


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkxoJWIACgkQnMz9fgzDSqdQMQCfaX6u4vOLobDklR4NfSoyBHcZ
ulgAnAxpDHdBXxBUtm8Jvh3igPxqlmhe
=1uBq
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] questions about plugin loading

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 15.08.2010 19:59, schrieb Dirk Stöcker:
 
 http://josm.openstreetmap.de/wiki/DevelopersGuide/DevelopingPlugins#ThemanifestfileforaJOSMplugin
 
 See Plugin-Requires, Plugin-Stage and Plugin-Early.

Thank you for the link.

 Thought you can't use Plugin-Requires, as WMS-plugin should not depend
 on remote-control.

I agree. I think in wmsplugin I can use 
PluginHandler.getPlugin(remotecontrol) to check if remotecontrol is available.

 Easiest is probably to use Plugin-Early in remote-control.

I will use something like attribute name=Plugin-Stage value=20/ for 
remotecontrol and attribute name=Plugin-Stage value=50/ for wmsplugin an 
add some explanatory comments.
(I want to reserve Plugin-Early for plugins that really need it.)


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkxoMqIACgkQnMz9fgzDSqf2NACfY40sD1UnsMV/rzxBFsUripk4
XscAn2ZUkbLWF5lxDvWgBVZVZ50l5Pg3
=bviz
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] WMS requiring an EULA acceptance

[Bodo Meissner]

Pieren wrote:
 
 It could be a WMS customization (blocking the
 images delivery if the user-agent is not in the white list), I don't know
 this part well enough to answer.
 

Matthias is right. You cannot rely on the client program. It is easy to
change the user agent. see
http://chrispederick.com/work/user-agent-switcher/


Matthias Meißer wrote:
 
 so best would be to let mappers somewhat register by mail/osm PM/.. so
 they
 can check who is online. During this step it is necessary to accept the
 EULA.
 


Pieren wrote:
 
 The things you suggest have been
 studied in details with their lawyers and they found this solution as a
 compromise (no user accounts to manage, simplicity, etc). Just click 'OK'
 on
 the text asking you to use the imagery for OSM only. Sounds reasonable.
 

With this simplicity they won't get any security.
As I already said you cannot rely on the client program.

I saw in the WMS plugin that you can specify cookies. (I don't know if it
works correct.)
Maybe the user can go to their website to accept the license. The user will
get a string that he has to copy and paste to his WMS configuration as a
cookie specification. The WMS server can reject requests without a known
cookie.
(But without other checks some cookies will sooner or later be known to
everyone.)

Or the website can create an individual URL after accepting the license. The
user can select the WMS - rectified image option and paste the URL.
(similar security problems here, maybe the URL can be restricted to a
specific IP address and could expire when unused for some time...)


Bodo
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/WMS-requiring-an-EULA-acceptance-tp5416309p5416706.html
Sent from the JOSM Development mailing list archive at Nabble.com.

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] JOSM-Tested

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 16.06.2010 16:55, schrieb Dirk Stöcker:
 On Wed, 16 Jun 2010, Matthias Julius wrote:

 A link to Launchpad
[...]
 There could also be one in each dialog when a translation into the
 current locale was not found.
 
 No. That is not a good idea.

Why not?


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkwZMe4ACgkQnMz9fgzDSqfr2QCfaQDSsZvjaqKMk8ctcQ2XQBdY
8WgAniTtfXs+U3S2ozdpZqn8Ja4Z8FZ5
=N2o3
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

[josm-dev] JOSM command line syntax and processing

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello developers,

is there any documentation about Josm's command line arguments?

While thinking about bug 4288 I tried to understand the processing of command 
line arguments.
It looks a bit strange and I think it is difficult to change or to extend.

In order to fix the bug it must be possible to process a set of image files 
instead of individual files.
I'm not sure if the command line processing should be changed to handle this or 
if batch importers should handle this automatically with a little help from the 
command line processing.
Maybe it's a good idea to clean up the command line processing.


As far as I found out this is the current implementation:

The command line args are passed to main() as String argArray[].
The array values are copied to a ListString argList.
A hash map that assigns a Collection of values to a key is created from 
argArray:
   all values not starting with -- are prepended with --download=
   if the value does not contain '=' everything after -- is regarded as a key 
and an empty string will be added to the value list
   if the value contains '=' the part between -- and '=' is used as a key and 
the part after '=' is added to the values list of this key
(This implementation stores options like -? or -h in the has map in the 
values list of key download.)

main() checks the HashMap for the existence of key reset-preferences (must 
have been --reset-preferences or --reset-preferences=foo) and for the first 
value of key language (--language=foo)

After this, main() checks argList for help options --help, -? and -h. In 
this case the program exits which means that the wrong values for the 
download key will be ignored

main() passes the HashMap args to preConstructorInit(args)

After creating the mainFrame and closing the splash screen, main() checks the 
HashMap args for no-maximize, geometry and maximize

At the end of main() a Runnable is added to the event queue that will pass the 
HashMap args to main.postConstructorProcessCmdLine()

Main.postConstructorProcessCmd() handles keys download, downloadgps and 
selection.
All individual values of download and downloadgps are passed to 
downloadFromParamString() which distinguishes between file: and http: URLs, 
strings that contain exactly 3 commas which are trated as a bounding box and 
other strings that are treated as a file name.

file: URLs and file name arguments are handled individually by 
OpenFileAction.openFile().


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktF/YoACgkQnMz9fgzDSqeBJQCdEMVUsRWAItc9Saa3ntxgxcQN
Z1IAn0w5zmE1oJIZ47MQdzQujHRAxwzT
=Pa1K
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Automatic tiles downloading in WMSPlugin

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Petr Dlouhý wrote on 02.09.2008 02:20:

 I think, I will please Bodo, when he returns wrom holiday. I implemented  
 something like delayed downloading, but much wiser. I implemented  
 synchronization between threads so only one thread is downloading tiles at  
 the moment AND the tile starts to be downloaded only, when the tile is  
 still isible. It means, that when looking around, only few useless tiles  
 gets downloaded.

Hello Petr,

this sounds great. I think I will test it soon.

As I have seen, you have submitted your version to SVN.
I will try to re-implement my experimental changes for NASA's tiled WMS
for the new version.

Could you, please, give me some hints where to look in the sources to
answer the following questions:

How do you define the coordinates and resolution of the tile to be
downloaded?
How do you find out if a tile has already been downloaded?


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjSv2MACgkQnMz9fgzDSqezfgCbBc84jGQGaI+Inxqvc+ZZmTHI
EJ4AnArb/ierhSXS7hFcstawDTyn0Lq4
=sXbv
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Automatic tiles downloading in WMSPlugin

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Petr Dlouhý wrote on 28.08.2008 15:51:

 Ok, I implemented save and load (bud I doubt, if it is usefull).

I think loading the images from a file must prevent the plugin from
downloading the images again. It might even be useful to optionally
switch off the automatic downloading when I know I already have the area
i'm interested in.

 I also  
 implemented grabber choosing through getGrabber(), but to get OSGBGrabber  
 working, it needs to be rewriten to thread support.

Does the plugin download several tiles at the same time? I hope this
does not place too much load on the servers.
Even with the old WMS plugin the Landsat WMS server was sometimes very
slow or down because of overload. If the load gets higher this might
annoy the people who run a WMS server.

 The new version could be downloaded from:
[...]

I will be in holidays for the next two weeks. That's why I don't have
time to test it now.

 
 I don't like waiting before the tiles get loaded, it would be very tiring.

If there was a configurable delay you could set the delay to 0 to get
the tiles downloaded immediately. I, personally, would set the delay to
something like 2 seconds

 The tiles are downloaded only if it's zoomed enough, so if you want to  
 look around without downloading new tiles, then just zoom out a little. I  
 found that very intuitive.

I do not want to look around but move the display to the next place to
work on. When I stop at some place only to release the mouse button,
move the mouse to the other end of the screen and then press the button
again, there is no need to start downloading this tile.

I think I had to zoom out very much to stop the automatic downloading.

Regarding zoom and automatic downloading I see a different problem.
I know one WMS server that returns white images if I zoomed in too much.
Normally I zoom out enough before manually downloading images, then I
zoom in to draw or check objects. In this zoom level I do not want any
downloads because it would fill the area with white images. To prevent
this problem with your plugin I would need a server specific limit for
the zoom level or image resolution. When I have zoomed in too much the
plugin should either not download any tiles or download tiles with the
maximum resolution available for this server.


Bodo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAki4J4QACgkQnMz9fgzDSqdmqgCeL//qxBcXTTC4r+P60isOshL3
NEIAoI5lD++0cwvShi1hNNOmwqOJEZjz
=1dh+
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Automatic tiles downloading in WMSPlugin

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Petr Dlouhý wrote on 28.08.2008 01:56:

 I made lot of changes, so I don't want to put the plugin into the SVN yet.
 Can anybody test it?

Hello Petr,

I used the first version of your plugin for a short test.
The automatic downloading is very useful when checking or mapping a
larger area.

I have some suggestions for improvement:

When scrolling around or changing the zoom level, the tile should not be
downloaded immediately but after some configurable delay when the view
is no longer changed. This would avoid downloading large amounts of
unwanted data. It might even be useful for some users or for some WMS
servers to completely disable automatic downloading.

As I already told in my reply to Frederik's message, I suggest to re-add
the save and load functions. This feature is useful to avoid repeated
downloading of the same area.

If you use remove the switch between WMSGrabber and OSGBGrabber it may
no longer be possible to use the NPE maps server[s]. So this might be an
important feature.


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAki2blkACgkQnMz9fgzDSqelxwCfWngJkhd9kJa2Y4vFiqXSbvd9
TzoAniPqj9wXZmKYXWG8u75cxmdFxjt7
=e+Wv
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Automatic tiles downloading in WMSPlugin

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Petr Dlouhý wrote on 25.08.2008 23:19:

 I remade WMSPlugin, so it is automaticaly downloading map tiles.
[...]
 You can download the source from  
[...]

Hello Petr,

please, create a patch file to make it easier to see your changes.

BTW: I recently create a largely modified version of wmsplugin to
support tiled WMS as defined by NASA for theit Landsat images. This
version is not yet in SVN because I still have an unresolved problem.
see http://wiki.openstreetmap.org/index.php/User:Bomm


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkizM7IACgkQnMz9fgzDSqfm+QCgkupYHHeeiHU0EXJcv5dp19Dv
uqoAn24Ao2jhwDyqEq7rWyIrZ9lFIejh
=dh1w
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Fwd: add-node idioticy

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Koppenhoefer wrote, on 20.08.2008 11:34:

| I would suggest to restrict adding nodes to click
| and drag and not to a simple click. The click without dragging the
| plus should remain select way as it was before. It will not be
| necessary to add a node and leave it where it was, so click and drag
| would be ideal for refining.

I agree. This is a good idea IMHO.


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkisE3IACgkQnMz9fgzDSqeAXACfbnQafFL0QcYfLxvITPwvVsiw
LakAn3gSGcbr73PZWO0hGn6ljkA/Ku6n
=rrh6
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] HTML entities

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dirk Stöcker wrote, on 20.08.2008 18:37:

| Is there a Java function, which can can convert the HTML amp;, apos;
and
| so on into UTF8? I did not find anything.

I found a reference to this but didn't try it myself.

http://mindprod.com/products1.html#ENTITIES

It is can be used for any non-military purpose.


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkisgQ4ACgkQnMz9fgzDSqdycQCfX5dGcgAMdsBiNTIu8rGthTrT
a+gAn2RGbg8J3NwMg1A5jfASrgm+QxbR
=XnrV
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] UngluePlugin source?

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robin Rattay wrote, on 17.08.2008 09:22:

| Is the source code of the UnGluePlugin available somewhere?

The source code (two small .java files) is in the .jar file.


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkin7QsACgkQnMz9fgzDSqdoVwCeL/cs/GaqMfOFmlTVIhzJYxpn
SFgAoJt+CCpqExRUfs6uNxyENcT6O16p
=BFWZ
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

[josm-dev] JOSM, plugins and Eclipse (was: Patch for sorting members in the relation editor)

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robin Rattay wrote, on 16.08.2008 21:21:
|
| I haven't found a way to debug a plug-in yet. Does anyone know how you
| do that with Eclipse?

I once got this hint from Frederik:

I added all the plugins I want to use (and debug) to JOSM (no need to
run it from Eclipse) using the normal plugin configuration stuff.

Then I checked out the JOSM project and plugin projects to the Eclipse
workspace.

To build the plugins with the .jar files created by the JOSM project in
Eclipse, I added the JOSM project to the plugin's build classpath.

To make JOSM use the plugins from the Eclipse workspace instead of the
.jar files from the plugin directory, I created a run configuration for
JOSM (with main class org.openstreetmap.josm.gui.MainApplication) and
added all plugin projects to User Entries with the Add Projects button.


Though I don't know what is the best way to build the plugins from Eclipse:

The first possibility is to checkout the whole tree from
svn.openstreetmap.org using Subclipse. With this I don't get project
configurations for the plugins and cannot build plugins inside Eclipse.
Running the ant scripts directly might work. When I import the
individual plugin projects from this tree I can build the plugins inside
Eclipse and the .jar files will be created in the correct directories,
but I cannot use the team functions in these plugin projects. (I have to
switch to the full OSM tree to use team functions.)

The second possibility is to checkout the individual plugin subtrees
from svn.openstreetmap.org. Eclipse finds project configurations for the
plugins automatically and I can build the plugins and use the team
functions, but the .jar files will be located outside the project tree
because of ../../dist in the build scripts.


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkinVqQACgkQnMz9fgzDSqcQFACfaIIx03x3Fk+u3S6t37I1kewM
RWMAmgM214sJ5zVpGWKmdEatHYbUe4tl
=2CBf
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Landsat tiled WMS support for wmsplugin implemented

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I tried to send this message with the big patch included but it did not appear 
on the list.
That's why I send it again but include only download links to the files.

The patch is available at
http://bodo-m.de/josm/wmsplugin.patch.txt
(For some files the patch wants to replace the whole file and does not show the 
individual changes, probably because of different UNIX/DOS line endings.)

A modified version of the .jar file created from my sandbox is available at.
http://bodo-m.de/josm/wmsplugin.jar


Bodo (bomm)

Bodo Meissner schrieb:

 Hello,
 
 I have implemented an extension for wmsplugin to support the tiled WMS 
 operation mode of the Landsat WMS server as specified on
 http://onearth.jpl.nasa.gov/tiled.html
 
 Before committing this to SVN I would like to get some feedback.
 
 Implementation overview:
 
 WMSGrabber now requests GetCapabilities and partially parses the response 
 into a WMSCapabilities object.
 If the server supports the GetTileService request it will perform this 
 request and parse the response into a tree of objects from wmsplugin.tiledwms.
 The root of the tree is a TiledPatterns object that contains TiledGroup 
 objects. A TiledGroup can contain other TiledGroup objects or TilePattern 
 objects. TiledPatterns, TileGroup and TilePattern correspond to XML tags in 
 the GetTileService response. A TilePattern tag contains one or more WMS 
 request strings that will be parsed into WMSRequest objects.
 
 If the WMS server supports tiled WMS, the images will be grabbed with 
 WMSGrabber.grabTiled() instead of WMSGrabber.grab().
 grabTiled() looks for the best matching WMS access pattern from the 
 TiledPatterns structure. To find the best match, I first select all 
 compatible patterns, i.e. patterns that have the same parameter values except 
 coordinates (bbox) and image size (width, height). From the compatible 
 patterns I select the pattern with the image resolution nearest to the 
 requested resolution. If available I use the smallest resolution greater than 
 or equal to the requested resolution, otherwise I use the highest available 
 resolution.
 From the best pattern, a set of requests is generated to get one or more 
 tiles of fixed size that fully cover the requested area and an area of images 
 is returned.
 
 If the WMS server does not support tiled WMS or this mode is disabled or if 
 no matching pattern is found, grabTiled() falls back to a normal WMS request 
 using grab().
 
 Additionally to the tiled WMS operation, I added a flag to the preferences to 
 enable/disable tiled WMS mode and a Clone button to create a new entry from 
 an existing one. With this it is easy to create tiled/normal variants of the 
 same WMS server.
 
 
 
 Currently the Landsat WMS server seems to work for non-tiled requests.
 When I download the same area using both tiled and normal WMS, there are some 
 small differences between the images in these two layers.
 I don't know yet the reason for this. It might be JOSM stretching individual 
 tiles instead of stretching a larger image or a different interpretation of 
 coordinates and image size between JOSM and the WMS server. (When I specify 
 the coordinates bounding box of the image, is this the center of the corner 
 pixels or the outer corner of these pixels?)
 
 
 If you want to test the tiled WMS access I suggest to clone the Landsat entry 
 and enable use tiled.
 If everything is OK, I will change the default to use tiled in the final 
 version, so it will use tiled WMS whenever possible.
 
 
 Bodo

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIc+VRnMz9fgzDSqcRAvVfAJ4srJyu8is+TsQPLiKyioLswRo/9gCeKEZf
TD/8xI6Hbo8j/i0HkYqT0sk=
=b4RU
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev

Re: [josm-dev] Translation into german

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dirk Stöcker schrieb:
 On Fri, 4 Jul 2008, Bodo Meissner wrote:
 
 Translate Man made with Zivilisationsbauten is also not one of the
 best.
 maybe simply Bauwerke (or Bauten)?
 
 Well, that's the problem. I don't see a real difference to the buildings 
 menu. :-)

Sorry, I checked josm-latest.jar version 645. This older version does not have 
a buildings menu entry, that's why I did not see the possible conflict. Now I 
compared with the latest version from SVN.
I would prefer the older menu structure health, education, culture over 
the new buildings because buildings will probably grow to a long list, and 
I would integrate (most of) the elements from man made into such a structure.
IMHO buildings as a classification is nearly as bad as man made.


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIbiJ3nMz9fgzDSqcRAgw1AJ96osQ5lihixcir1BXUYpvksLgW/ACfYqfq
41hj4MhwnPmSgdafbViK7xY=
=MSD2
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev

[josm-dev] JOSM plugin development with Eclipse and subclipse (wmsplugin)

[Bodo Meissner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello developers,

what is the best way to work on wmsplugin (or maybe other JOSM plugins) within 
Eclipse?

I checked out http://josm.openstreetmap.de/svn/trunk with subclipse as project 
JOSM.

Then I tried to check out the whole OSM tree http://svn.openstreetmap.org. I 
have to specify a project name. This project I cannot use for anything except 
SVN.
Then I imported the project wmsplugin from the complete OSM tree just checked 
out.
After setting the correct build path and class path(*) I can build and test the 
plugin from this project, but the team operations are not available there. I 
have to find the modified files in the project containing the full OSM tree to 
create patches etc.

(*)JOSM project as dependency in wmsplugin's build path and project wmsplugin 
as classpath in JOSM's run configuration

My next try was to check out only the wmsplugin subtree. This finds the project 
configuration from the .project file. I can work with this project including 
all SVN operations but there is a problem with the ANT build.
The file build.xml references a dist directory that is one directory up from 
the root of my Eclipse workspace. After creating such a directory I can build 
the plugin but the directory outside the workspace root seems to be wrong.
I assume I cannot commit the generated .jar this way.

What is the right way to do it? I would like to build the plugin and use SVN 
inside Eclipse.


Bodo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIbKQinMz9fgzDSqcRAmxxAJ9PcE1XNjrZOFTx0HcVPYf8b9Mh/ACfTDsr
+bwhX5T7fxCNrMbx7y2MzLQ=
=dtIR
-END PGP SIGNATURE-

___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev