Re: Tracer2 Plugin / Alternative / WFS?

[Vincent Privat]

Hi Marián,
Have you identified what remains to be done in order to replace the
original tracer plugin?
Cheers,
Vincent

Le lun. 14 déc. 2020 à 08:47, Marián Kyral  a écrit :

>
> Forget to cc josm-dev@openstreetmap.org :-(
>
>
>
> -- Původní e-mail --
> Od: Marián Kyral 
> Komu: Florian Lohoff 
> Datum: 14. 12. 2020 8:41:58
> Předmět: Re: Tracer2 Plugin / Alternative / WFS?
> "
> Hi Florian,
>
>
>
> -- Původní e-mail --
> Od: Florian Lohoff 
> Komu: josm-dev@openstreetmap.org
> Datum: 13. 12. 2020 20:43:18
> Předmět: Tracer2 Plugin / Alternative / WFS?
> "
> Hi,
> as the ALKIS Data for example for Northrhine-Westfalia have been
> republished as CC0 it is possible to use the Tracer2 Plugin and External
> Helper which have bitrottet a bit over the last years and are prone
> to backtraces/crashes and other problems.
>
> As Northrhine-Westfalia has also published the Building Outlines as
> a shape it would also be possible to use the outlines from the shape.
>
> While thinking about it it would a pretty plugin for be able to click
> somewhere and get a feature from a WFS Service which surrounds
> the clicked point.
>
> There is no point in trying an import as 90% of the buildings are
> there already. I'd rather like to see a simpler point-and-click
> feature by feature update/import.
>
> Is there some kind of WFS based Plugin? "
>
>
>
> In Czechia we have developed a new version of original Tracer plugin. It
> is
> modular and the LPIS module is using WFS. The plan was to replace the
> original Tracer plugin, but it did not happened yet. It is developed
> separately in my github repository and the plugin is called tracer-testing
> in JOSM.
>
>
>
>
> https://github.com/mkyral/josm-tracer/blob/development/src/org/
> openstreetmap/josm/plugins/tracer/modules/lpis/LpisServer.java
>
>
>
>
> Please check it, fell free to test and create a new module. Maybe it is a
> time to move forward and replace the original Tracer plugin. I have made
> "Classic" module, that should work in the same way as original module, but
> it is not tested a much as it needs mono server on localhost.
>
>
>
>
>
> Regards,
>
> Marián
>
>
>
> "
>
> Flo
> --
> Florian Lohoff f...@zz.de
> UTF-8 Test: The  ran after a , but the  ran away
> ""
>

Re: OSM-SVN shut down, JOSM copy takes over

[Vincent Privat]

Thank you Dirk for taking care of this. This is something I wanted to
handle myself but I have a ĺot of personal stuff going on so no time for
(J)OSM atm. Once things are easier for me I'll look to complete the gitlab
migration at least for these plugins. With what Florian did for the
Git[hub|lab] plugins and the migration script Wiktor wrote long ago I think
we have sufficient tooling to start the git infrastructure.
Cheers,
Vincent

Le dim. 16 août 2020 à 20:22, Dirk Stöcker  a
écrit :

> Hello,
>
> the OSM SVN is shut down. Currently it is read-only.
>
> We have a copy of the JOSM and JMapViewer parts on JOSM server now:
>
> https://josm.openstreetmap.de/osmsvn/
>
> This copy will be be used from now on for further development. Maybe in
> future that will become Git (or not, who knows...).
>
> Write access is currently possible for all JOSM-SVN users. Others please
> use the JOSM wiki to submit patches. I didn't decide yet if it will stay
> this way, for the moment it's simply easier :-)
>
> See also
> https://josm.openstreetmap.de/wiki/Source code
> https://josm.openstreetmap.de/wiki/DevelopersGuide/DevelopingPlugins
>
> With "svn relocate" it's possible to switch an existing working copy to
> the new URL without a full re-checkout.
>
> Ciao
> --
> http://www.dstoecker.eu/ (PGP key available)
>
>

Re: Planned removal of JavaScript API of JOSM configuration XML files

[Vincent Privat]

For reference, the up-to-date link for [1] is rather
https://openjdk.java.net/jeps/372

Le jeu. 5 mars 2020 à 19:53, Simon Legner  a écrit :

> Hi all,
>
> due to the planned removal of the JavaScript engine Nashorn from Java
> [1], we have to take action. Nashorn was in use for three features of
> JOSM core:
> 1. opening_hours validator based on opening_hours.js [2]
> 2. overpass-wizard (in download dialog) [3]
> 3. JavaScript API of JOSM configuration XML files [4]
>
> Item 1 has been resolved by migrating to OpeningHoursParser written by
> Simon Poole for Vespucci. [5]
> For item 2, we plan to use a hosted service (likely on the JOSM
> server) for turning user input into Overpass Queries. [6]
> For item 3, we don't see a viable alternative. We plan to remove this
> feature with the next JOSM release unless someone steps up with a
> killer-user-case and migration plan
>
> Thanks for reading and happy mapping,
> Simon (simon04)
>
> [1] https://openjdk.java.net/jeps/335
> [2] https://github.com/opening-hours/opening_hours.js
> [3]
> https://josm.openstreetmap.de/wiki/Help/Action/Download#DownloadfromOverpassAPI
> [4]
> https://josm.openstreetmap.de/wiki/Help/Preferences/ImportExport#JavaScriptAPI
> [5] https://josm.openstreetmap.de/ticket/18140
> [6] https://josm.openstreetmap.de/ticket/18164
> [7] https://josm.openstreetmap.de/ticket/18830
>
>

Re: Accessing third-party repositories

[Vincent Privat]

Hi Frederik,
I agree with you. We plan to switch back to solely JOSM server through
https://josm.openstreetmap.de/ticket/18599
Cheers,
Vincent

Le ven. 14 févr. 2020 à 13:51, Frederik Ramm  a écrit :

> Hi,
>
> upon starting JOSM I was greeted by, among other things, messages that
> loaded content from "wikidata.org" and "sophox.org".
>
> I have not actively enabled something that would make these queries, nor
> have I been asked for my consent to transmit the fact that someone is
> using JOSM at this IP number to wikidata.org or sophox.org.
>
> I can understand that if I load Ilya's geochat plugin it will phone home
> to Ilya's server, or if I enable certain imagery layers they will load
> data from the imagery server. Also it is clear that JOSM will access the
> OSM and JOSM servers. But I think that we should not add random third
> party web sites that are under control of neither OSMF nor the JOSM team
> to the mix without explaining this to the user and asking for their
> consent.
>
> Would it perhaps make sense to build a generic "consent to access server
> X" feature into the JOSM core, and anyone - whether core or plugin -
> would then have to acquire user consent once before accessing a remote
> resource?
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
>

Re: JOSM development in the last year

[Vincent Privat]

I'm surprised by the Windows/Linux ratio.
I always noticed a quite stable ratio around 70% Windows, 20% Linux, 10%
Mac (+/- 5% margin).
Isn't just that more Linux people used JOSM during the holidays than
Windows people? Such an increase looks strange otherwise.

Le jeu. 2 janv. 2020 à 00:45, Dirk Stöcker  a
écrit :

> Hello,
>
> another year is done. To satisfy curiosity I'll give some stats about what
> we were doing last year.
>
> JOSM is still a 100% volunteer project. Server is sponsored by FOSSGIS,
> otherwise no money flows (thought I can't speak for the patch submitters,
> but I'm sure none is working full-time for JOSM :-)
>
> I talked to people at conferences and some wondered about that fact: They
> assumed JOSM consists of a group of at least 5 paid workers.
>
> JOSM Server-Stats:
> - Incoming IP-Traffic 13TB/year, outgoing IP-Traffic 14TB/year (together
> that is a constant 7MBit/s :-)
> - Wiki/ticket submissions 350.000/year with a SPAM quota of 97%
> - About 50 SPAM slipping through per year and need manual fixing (usually
> they are also manual entered)
> - That leaves about 10.000 valid wiki/ticket submissions a year!
> - 13 million page views and 29 million page impressions (majority of bots
> and also JOSM filtered out)
> - Server is using about 500GB harddisk space
> - New tickets: 1300/year (count of new and closed tickets last year
> approx. equal)
> - 1000 SVN revisions of JOSM core
> - I'm not aware of major troubles this year, server runs smoothly (uptime
> is 312 days BTW :-).
>
> As you can see by these numbers JOSM isn't a small hobby project (for some
> time now). Ohlooh estimates costs to about 190 man-years. A lot of
> contribution goes into it.
>
> Some info based on the statistics we gather via the JOSM requests to the
> JOSM server (recent stats, vary always by a few %):
> - Mainly used with Java 8 (72%), Java 11 (16%) and Java 12 (8%)
> - 99% IPv4 and only 1% IPv4 users (web-page has higher IPv6 ratio)
> - 54% Windows, 37% Linux, 9% MacOS (Linux numbers are going up...)
> - 46% English, 17% German, 7% French, 6% Russian, 5% British, 3% Polish
> users based on the choosen GUI language.
> - Majority of users using tested version, approx 70% using one of the last
> 3 (i.e. version of October to December)
>
> Thanks to all the people contributing to JOSM in one of the many ways
> possible. Major thanks to my co-admin Vincent who does most of the work
> regarding the ticket handling. Special thanks to translators who come by
> and simply translate a lot.
>
> A note to some people: Be more relaxed.
>
> Happy new year to everybody out there
> --
> http://www.dstoecker.eu/ (PGP key available)
>
>

Re: [OSM-dev-fr] Intégration java OSM

[Vincent Privat]

Hello,
ça tombe bien, JOSM est en Swing :)
L'appli est encore monolithique, mais un composant est géré de manière
autonome (JMapViewer):
https://trac.openstreetmap.org/browser/subversion/applications/viewer/jmapviewer
https://web.archive.org/web/20190425171755/https://wiki.openstreetmap.org/wiki/JMapViewer
https://tracker.debian.org/pkg/jmapviewer

Il est facilement embarquable dans n'importe quelle appli Swing. Nécessite
Java 8+.

Tu peux voir comment on l'utilise dans JOSM aux endroits suivants:
- download dialog:
https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/gui/bbox/SlippyMapBBoxChooser.java
- history dialog:
https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/gui/history/CoordinateInfoViewer.java
- imagery preferences:
https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/gui/preferences/imagery/ImageryProvidersPanel.java

Dans les préférences d'imagerie, on dessine les limites des sources
disponibles par dessus un fond OSM. Tu dois pouvoir t'en inspirer pour
afficher tes infos.

A+
Vincent

Le mar. 27 août 2019 à 19:15, Frédéric Rodrigo  a
écrit :

> Je pense que la question porte plutôt sur l'intégration de cartes dans
> une application Java.
>
> https://wiki.openstreetmap.org/wiki/FR:Mapsforge
> https://docs.mapbox.com/android/java/overview/
>
>
>
> Le 27/08/2019 à 18:57, marc marc a écrit :
> > Bonjour,
> >
> > si tu veux intégrer une carte avec les marqueurs,
> > umap pourrait faire l'affaire.
> > si tu veux gérer toi-même le fond, cela ne conviendra pas.
> >
> > Cordialement,
> > Marc
> >
> > Le 26.08.19 à 18:15, pe...@valentinbru.com a écrit :
> >> Bonjour,
> >>
> >> Je travaille actuellement sur la conception d’un logiciel de marketing
> >> en java/Swing , j’ai actuellement des positions Latitude/Longitude de
> >> croisements avec mes infos que j’aimerais afficher sur une map et je
> >> n’ai pas trouvé d’équivalent à OpenLayers ou Leaflet pour intégrer la
> >> map OSM dans mon application  je voulais donc savoir si vous aviez
> >> connaissance d’une librairie ou api qui peut faire ça ?
> >>
> >> Merci beaucoup,
> >>
> >> *Valentin BRU*
> > ___
> > dev-fr mailing list
> > dev-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/dev-fr
>
>
>
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: method that returns left or right hand traffic for a given location

[Vincent Privat]

Hi Jo,
Take a look to :righthandtraffic MapCSS pseudo-class and/or
RightAndLefthandTraffic class.
Cheers,
Vincent

Le jeu. 22 août 2019 à 22:29, Jo  a écrit :

> Hi,
>
> In PT_Assistant we want to be able to tell mappers some stops are on the
> wrong side of the highway. This depends on driving direction, obviously.
>
> Is there a method in core that can be used to query this information?
>
> Polyglot
>

JOSM summer releases

[Vincent Privat]

Hello,
I just have released JOSM 15238 as the "final" 19.06 release (after 2
hotfixes due to recent regressions in relation editor, my bad).
We're the 10th of July and 19.07 was expected to be released around 28 of
July.
As most of core developers are already, or going to be, in holidays, not
enough work will be made in the coming two weeks to be worth a new release.
Hence I have deleted the 19.07 milestone and affected all its assigned
tickets to 19.08, expected for 25th of August.
Mappy holidays,
Vincent

Re: compiling the GIT version -> duplicate classes

[Vincent Privat]

This is probably caused by the recent change of svn:externals.
Try to delete the folder scr/org/apache, then update your repo again (svn
up).
It should solve this issue.

Le mar. 18 juin 2019 à 15:05, Helmut Jarausch  a écrit :

> On 06/18/2019 02:02:50 PM, Vincent Privat wrote:
> > Does it happen if you use the official svn repo instead of the git
> > mirror ?
>
> Sorry, my mistake.
> I did use https://josm.openstreetmap.de/svn/trunk
>
> >
> > Le mar. 18 juin 2019 ?  11:22, Helmut Jarausch
> > _ j_ a_ r_ a_ u_ s_ c_ h_ @_ s_ k_ y_ n_ e_ t_ ._ b_ e a
> > écrit? :
> >  Hi,
> >  when I try to compile the GIT sources I (now) get lots of errors
> > like
> >
> >  ?  ?  ? [javac]?
> >
> > /var/tmp/portage/sci-geosciences/josm-9/work/josm-9/src/org/
> >  apache/commons/jcs/access/AbstractCacheAccess.java:42:?
> >  error: duplicate class:?
> >  org.apache.commons.jcs.access.AbstractCacheAccess
> >  ?  ?  ? [javac] public abstract class AbstractCacheAccessK,
> > V
> >
> >  What am I missing?
> >  Please bear in mind that I have next to no knowledge in Java.
> >
> >  Many thanks for a hint,
> >  Helmut
> >
>
>

Re: compiling the GIT version -> duplicate classes

[Vincent Privat]

Does it happen if you use the official svn repo instead of the git mirror ?

Le mar. 18 juin 2019 à 11:22, Helmut Jarausch  a écrit :

> Hi,
> when I try to compile the GIT sources I (now) get lots of errors like
>
>  [javac]
> /var/tmp/portage/sci-geosciences/josm-9/work/josm-9/src/org/apache/commons/jcs/access/AbstractCacheAccess.java:42:
>
> error: duplicate class:
> org.apache.commons.jcs.access.AbstractCacheAccess
>  [javac] public abstract class AbstractCacheAccess
>
> What am I missing?
> Please bear in mind that I have next to no knowledge in Java.
>
> Many thanks for a hint,
> Helmut
>

Re: Sourcing java on JOSM build for OSX

[Vincent Privat]

Hi Marc,
JOSM bundle for macOS is currently built using this fork of "appbundler":
https://github.com/teras/appbundler

It seems the launcher doesn't care about JAVA_HOME but chooses explicitely
JavaAppletPlugin by default:
https://github.com/teras/appbundler/blob/master/appbundler/native/main.m#L57

It should be reported and fixed there, until we can switch to the new
"jpackager" tool that will appear soon in OpenJDK itself:
https://bugs.openjdk.java.net/browse/JDK-8200758

Cheers,
Vincent

Le jeu. 13 juin 2019 à 22:47, Marc Grober  a écrit :

> I am currently running High Sierra and JDK 12. I have been trying to
> identify how to get the JOSM (latest-tested) OSX build
> (https://josm.openstreetmap.de/download/macosx/josm-macosx.zip) to
> source JDK 12 as opposed to using the JRE identified by the Java Panel
> (which is the now defunct "internet plugin"). I have run the jar that
> comes in the package, and I have also replaced that jar with
> latest-tested downlaoded directly, with no change in behavior if I run
> from Applications. If I run from command line, JOSM sources the java set
> in JAVA_HOME.
>
> I have been unable to find anything that identifies whether any of the
> OSX files (like info.plist) or JOSM settings provide the option to set
> how JOSM sources Java, and JOSM does not source JAVA_HOME if started
> from Applications.
>
> I can't tell whether the current state of affairs is a feature, a bug,
> or simply an artifact of my own ignorance.
>
> But, I am guessing that more and more OSX users will be confronting the
> same problem, and it may get worse as I have heard that Apple will be
> eliminating the Java Panel and plugin location in new version of the OS.
>
> Since JOSM works just fine if invoked from CLI, I have to assume that
> something in Contents is pointing JOSM to the Internet plugin, instead
> of to JAVA_HOME.
>
> Can someone tell me how, where one can find and adjust this, and perhaps
> this could be modified in the OSX build to first look to see if
> JAVA_HOME is set, and then use Java from there?
>
> --
> "There are more things in heaven and earth, Horatio,
> Than are dreamt of in your philosophy. "
>
>
>

Re: IntelliJ vs Eclipse

[Vincent Privat]

You won't find consensus between those who prefer Eclipse and those who
prefer IntelliJ. Either we support both of them of none.
Personally I still use Eclipse even if I have a an IJ license but that's
more because I'm so used to use Eclipse I didn't find the time to "learn"
IntelliJ rather than a personal preference.
Cheers,
Vincent

Le dim. 2 juin 2019 à 21:29, Simon Poole  a écrit :

> As a non-JOSM dev, but forced to use IntelliJ now and then, and somebody
> who really doesn't particularly like Eclipse: IntelliJ sucks so badly
> that it makes eclipse look like the pinnacle of UI design. Just try
> using IntelliJ with less than perfect eyesight, that is just one aspect
> of many.
>
> The canonical solution would be to move to gradle as the underlying
> build system, which works for both, potentially with a little bit of
> work on the eclipse side (and I use that setup with a tiny weeny company
> trying to make it impossible).
>
> Simon
>
> * the involvement of the tiny weeny company with IntelliJ would be a
> reason on its own not to move without an alternative.
>
> Am 02.06.2019 um 20:59 schrieb Michael Zangl:
> > I noticed that a lot of devs have changed from Eclipse to IntelliJ
> >
> > The free community edition is fine for working on JOSM and we have
> > some ultimate licenses available if any core dev needs them.
> >
> > We currently have those build systems checked into our svn repository:
> > * ant
> > * Eclipse
> > In #17218 [1] I added a first patch to support IntelliJ as well.
> > The problem is: If we add support for IntelliJ, we have to update 3
> > build systems every time we change something. So it would be best to
> > drop Eclipse then. Eclipse was not developed that much in the last
> > view years and lacks behind IntelliJ a lot, especially when it comes
> > to debugging.
> >
> > Therefore, I would like to get a short heads up from JOSM core devs,
> > if you are using (or want to be using) IntelliJ or Eclipse (or if you
> > don't care).
> >
> > It is probably best if we continue the discussion in the ticket.
> >
> > Michael
> >
> > [1] https://josm.openstreetmap.de/ticket/17218
> >
>
>

Re: "JOSM and Java" on German forum

[Vincent Privat]

Thanks! You can also link to
https://www.openstreetmap.org/user/josmeditor/diary/172694
Also published to https://weeklyosm.eu/josm-and-java-on-german-forum

Le dim. 5 mai 2019 à 23:57, Gertrud Simson  a
écrit :

> Am So., 5. Mai 2019 um 22:40 Uhr schrieb Vincent Privat:
>
> > Can someone speaking German share the link there?
> >
>
> Done.
> Regards, Stefan.
>

"JOSM and Java" on German forum

[Vincent Privat]

Hello,
Today's weeklyOSM speaks about this German thread:
https://forum.openstreetmap.org/viewtopic.php?id=65470

I read a lot of incorrect statements there so I twitted some detailed
explanations here:
https://twitter.com/josmeditor/status/1125135390426505218

Can someone speaking German share the link there? Find below the copy/paste
of my tweets:


Many incorrect statements about the new @Java license from @Oracle on the
German @openstreetmap forum (
https://forum.openstreetmap.org/viewtopic.php?id=65470) mentioned in
@weeklyOSM. Let's see in detail what all is this about. #Thread
#openstreetmap #java ⬇️
First of all, a little bit of history/terminology. Java was created in 1995
by Sun. We call "Java" both the programming language and the platform that
runs JOSM (JRE = Java Runtime Environment). Several platforms, from
multiple vendors, exist.
The JDK (Java Development Kit) contains the JRE but also developer tools
(mainly, the java compiler). In 2006, around the release of Java 6, Sun
announced its intention to open-source Java in a new project: @OpenJDK.
OpenJDK is badly named, like OpenStreetMap. We don't only map streets...
Well OpenJDK project does not only concern the JDK but the whole Java
platform (language, spec, tools, APIs, etc.). @speakjava explains it nicely
at https://www.azul.com/how-do-we-define-java/
Sun open sourced many things from Java into the OpenJDK project, but not
all things. In particular, Windows/Mac installers and deployment
technologies like #WebStart were not open sourced (we don't know why).
It means OpenJDK is only a "source code" project. Building it is very
complex, and nobody took the pain to distribute free binaries for Windows &
Mac. Only @RedHat did it for Linux in the IcedTea project. If you have 100%
free Java on Linux, it's thank to them.
In 2009 Oracle bought Sun. They didn't change things radically until
recently. So even today most of Windows and Mac users are still using
proprietary JRE binaries from Oracle, that are built upon open source
project OpenJDK.
Oracle made a very good job in releasing Java 8 in 2014, then Java 9 in
2017. We even collaborated with them in mutual good faith. Then, all hell
broke loose.
They changed the Java release cycle to to a fixed 6 months schedule (2
versions per year). We are now at Java 12 (which is by the way the most
unimpressive version of Java: nothing new in it).
They changed the licence of the Oracle JDK: basically if you are an
enterprise and want to use Oracle binaries, you have to pay.
They introduced the notion of Long Term Support versions (LTS). Java 8 is
an LTS, Java 11 too. For more details about "release train" and licencing,
see the excellent blog post by @hendrikEbbers:
https://dev.karakun.com/java/2018/06/25/java-releases.html
And concerning the Java 8 binaries that almost everyone uses on Windows and
Mac, they changed the licence to a free "for personal desktop use, through
at least the end of 2020":
https://www.java.com/en/download/faq/distribution.xml
These changes came from nowhere and the Java community was not prepared for
it. So it required some time until we can get to a free replacement to the
Oracle binaries on Windows and Mac, and that's why we didn't advise anyone
to switch to something else yet.
But we're almost there thanks to @adoptopenjdk! This community-based
project offers free downloads of OpenJDK on all platforms!
https://adoptopenjdk.net/releases.html
We're just waiting for the availability of a few enhancements of the
AdoptOpenJDK installer before advising everyone to switch.
1) The inclusion of JavaFX (another technology abandoned by Oracle and now
maintained by @GluonHQ), which is used by JOSM to play MP3 files, and by
some plugins like Microsoft StreetSide:
https://github.com/AdoptOpenJDK/openjdk-build/issues/577
2) The inclusion of IcedTea-Web (the free implementation of Java #WebStart
which has also been abandoned by Oracle):
https://github.com/AdoptOpenJDK/openjdk-build/issues/898 We can thank
@RedHat (again) for this project, plus also @karakun and @adoptopenjdk for
their work
3) An auto-update feature to make sure everyone can automatically get
security updates: https://github.com/AdoptOpenJDK/openjdk-installer/issues/4
Once all these issues are resolved (hopefully long before end of 2020)
we'll ask everyone to switch to AdoptOpenJDK. Until now, even if we despise
Oracle for all of this, we still advise to keep the current Oracle JRE, at
least for the automatic security updates.
This is also why we still target Java 8 as a minimum. Once everyone is able
to run JOSM using AdopOpenJDK binaries, we'll likely switch to Java 11!
Which is by the way now maintained by @RedHat and not by Oracle :)


Cheers,
Vincent

Re: Develop for JOSM core or plugin?

[Vincent Privat]

Another tip: you can run JOSM with --trace so that a lot of
keyboard-related information will be displayed on the standard output.

Le mar. 30 avr. 2019 à 22:14, Vincent Privat  a
écrit :

> Hello,
> To build and run JOSM, see instructions at
> https://josm.openstreetmap.de/wiki/Source%20code#CompilingusingAnt
> Concerning hotkeys, you should start to get familiar with these classes
> and see how they are used, this should help you to understand most of
> keyboard interactions in JOSM:
>
>
> https://josm.openstreetmap.de/doc/org/openstreetmap/josm/actions/JosmAction.html
>
> https://josm.openstreetmap.de/doc/org/openstreetmap/josm/actions/mapmode/MapMode.html
>
> https://josm.openstreetmap.de/doc/org/openstreetmap/josm/gui/util/KeyPressReleaseListener.html
>
> https://josm.openstreetmap.de/doc/org/openstreetmap/josm/gui/util/ModifierExListener.html
>
> https://josm.openstreetmap.de/doc/org/openstreetmap/josm/gui/widgets/DisableShortcutsOnFocusGainedTextField.html
>
> https://josm.openstreetmap.de/doc/org/openstreetmap/josm/tools/KeyboardUtils.html
>
> https://josm.openstreetmap.de/doc/org/openstreetmap/josm/tools/Shortcut.html
>
> See also https://josm.openstreetmap.de/wiki/DevelopersGuide
>
> Welcome to JOSM development!
>
> Le mar. 30 avr. 2019 à 19:31, Tom H.  a écrit :
>
>> Thank you all for your suggestions, I think I've decided to update the
>> core instead of making a separate plugin, since hotkeys are simple enough
>> to implement and may get frequent use from users.
>>
>> I now wonder can anyone point me to the right direction as to where to
>> begin to integrate new hotkeys into JOSM, like what are the relevant
>> files/classes I should modify? And further, is there a tutorial to learn
>> how to create JOSM builds? Or had there been any relevant threads in the
>> archive? Sorry for all the questions, I'm just very new. Thanks!
>>
>

Re: Develop for JOSM core or plugin?

[Vincent Privat]

Hello,
To build and run JOSM, see instructions at
https://josm.openstreetmap.de/wiki/Source%20code#CompilingusingAnt
Concerning hotkeys, you should start to get familiar with these classes and
see how they are used, this should help you to understand most of keyboard
interactions in JOSM:

https://josm.openstreetmap.de/doc/org/openstreetmap/josm/actions/JosmAction.html
https://josm.openstreetmap.de/doc/org/openstreetmap/josm/actions/mapmode/MapMode.html
https://josm.openstreetmap.de/doc/org/openstreetmap/josm/gui/util/KeyPressReleaseListener.html
https://josm.openstreetmap.de/doc/org/openstreetmap/josm/gui/util/ModifierExListener.html
https://josm.openstreetmap.de/doc/org/openstreetmap/josm/gui/widgets/DisableShortcutsOnFocusGainedTextField.html
https://josm.openstreetmap.de/doc/org/openstreetmap/josm/tools/KeyboardUtils.html
https://josm.openstreetmap.de/doc/org/openstreetmap/josm/tools/Shortcut.html

See also https://josm.openstreetmap.de/wiki/DevelopersGuide

Welcome to JOSM development!

Le mar. 30 avr. 2019 à 19:31, Tom H.  a écrit :

> Thank you all for your suggestions, I think I've decided to update the
> core instead of making a separate plugin, since hotkeys are simple enough
> to implement and may get frequent use from users.
>
> I now wonder can anyone point me to the right direction as to where to
> begin to integrate new hotkeys into JOSM, like what are the relevant
> files/classes I should modify? And further, is there a tutorial to learn
> how to create JOSM builds? Or had there been any relevant threads in the
> archive? Sorry for all the questions, I'm just very new. Thanks!
>

Re: Develop for JOSM core or plugin?

[Vincent Privat]

Sounds like a feature small enough and useful to all to be considered a
core enhancement.

Le sam. 27 avr. 2019 à 11:22, Jiri Vlasak  a écrit :

> On Fri, Apr 26, 2019 at 02:53:49PM -0700, Tom H. wrote:
> > Hi All,
> >
> > I'm using JOSM constantly in my day to day job, and I'm having a few
> ideas
> > for using hotkeys to toggle some of the layer settings that can now only
> be
> > activated by point and click. I'm new to contributing in JOSM but am
> > currently looking through the dev docs, and I was just wondering if it's
> > better to realize my hotkey ideas via a plugin, or trying to
> incorporating
> > them into the JOSM core?
>
> tl;dr (generic) ? upstream : plugin ;
>
> There was already discussion when I started developing the plugin. Feel
> free to
> see the "JOSM enhancements vs. separate plugin" thread [1].
>
> Have a nice day,
> jiri
>
> [1]:
> https://lists.openstreetmap.org/pipermail/josm-dev/2018-May/thread.html
>
>

Re: Enabling jaw (Java-atk-wrapper) by default ? (Bug#900912)

[Vincent Privat]

If enabled by default, please offer a reliable way for applications to
disable it. We don't need it for JOSM, and we have been so impacted with
jaw's problems in the past years that we will never want it enabled by
default for us.

Le dim. 7 avr. 2019 à 12:08, Samuel Thibault  a
écrit :

> Hello,
>
> Matthias Klose, le sam. 06 avril 2019 15:46:21 +0200, a ecrit:
> > On 06.04.19 15:13, Paul Gevers wrote:
> > > We're late already, I would want this rather sooner than latter
> > > in buster, such that there is some real live testing before we release.
> > > Sure, there are chances for bugs, but if that's the case, let's find
> > > them and fix them.
> >
> > I disagree.  I'll do the next upload with Samuel's proposed patches, not
> > enabling that by default, together with the planned security update.
> Then
> > people can start testing if the wrapper works.
>
> Well, I'm afraid that what will happen is that the people who will
> test will simply find out that it just works for them (just like it
> does already for them with openjdk-8) ; will we then conclude near the
> release that it should be enabled by default for Buster, and then be hit
> by the much wider exposition to jaw?
>
> If on the contrary we enable it by default during the freeze, we will
> have *way* more testing coverage, and thus be much more confident with
> keeping it enabled by default in Buster if we don't see bug reports.
>
> > Enabling features during the freeze which were broken most of the time
> > during the development cycle sounds risky.
>
> Just ftr: what was broken was the load of jaw in openjdk-11, jaw itself
> seems to work in openjdk-8 for people needing it.
>
> Samuel
>

Re: github or subversion?

[Vincent Privat]

The OSM SVN has been deprecated but we're still using it. It will take some
time until we move the plugin sources to JOSM infrastructure. You can (and
must) use SVN until further notice.
Cheers,
Vincent

Le lun. 11 févr. 2019 à 22:01, Malcolm Herring via josm-dev <
josm-dev@openstreetmap.org> a écrit :

> The plugins developer guide says use SVN, but that repo says that SVN is
> deprecated & to use GIT instead. Which is the correct?
>
>
>

Re: Add templated version of wiki href to link element in presets

[Vincent Privat]

Yes it's slower and slower over time.
I guess it can be improved a lot by using MediaWiki API, see
https://josm.openstreetmap.de/ticket/16702

Le sam. 3 nov. 2018 à 21:25, Dirk Stöcker  a
écrit :

> On Sat, 3 Nov 2018, Vincent Privat wrote:
>
> > By the way the script doesn't work anymore, I was unable to update the
> > strings for last release.
>
> Someone replaced a bold small dot with a large normal dot in the wiki :-)
>
> Fixed and Updated.
>
> Whoa takes it long nowadays...
>
> (We could optimize and parallelize the access, but I doubt wiki admins
> will be happy about that :-)
>
> Ciao
> --
> http://www.dstoecker.eu/ (PGP key available)
>
>

Re: Add templated version of wiki href to link element in presets

[Vincent Privat]

By the way the script doesn't work anymore, I was unable to update the
strings for last release.

Le sam. 3 nov. 2018 à 16:40, Simon Poole  a écrit :

> I normally don't edit compressed files.
>
> Your argument would be perfectly valid (well if we forget that the
> entries have to be parsed) if the URLs were stored in a separate file,
> as is, bloating a manually curated file, it is bonkers.
>
> Simon
>
>
> Am 03.11.2018 um 16:33 schrieb Dirk Stöcker:
> > On Sat, 3 Nov 2018, Simon Poole wrote:
> >
> >> The current default preset has 12'214 lines of which roughly 5'564 are
> >> used for href attributes in the "link" element. I actually suspect that
> >> the number of lines used for the href entries is increasing faster than
> >> the actual preset content and it is only a matter of time before they
> >> will outnumber the rest. This makes the, already far too large file,
> >> larger than necessary and requires continuous maintenance of the entries
> >> for no good reason.
> >
> > This entries are maintained by an automatic script and most of the
> > data is compressed away to zero (remember, JAR is a zipped file format!)
> >
> >> If we used a template this could be reduced to 1'500 plus a couple of
> >> potential special cases. My suggestion would be to add a "template"
> >> attribute to the link element, with a placeholder {country} (or similar)
> >> for the two letter iso code plus the colon (including the colon makes
> >> adding a special entry for EN unnecessary).
> >
> > What you suggest is a more complex approach, which essentially strips
> > away the already perfectly compressible parts. Probably the additional
> > code required will outweight the save space. So that approach will
> > result in the opposite of the wanted goal.
> >
> > Ciao
>
>
>

Re: Strava heatmap plugin

[Vincent Privat]

First one: publish the plugin now and mark it as dependent of the minimum
JOSM development version. Plugins don't have to care about of JOSM being
tested or latest: they just have to reference the minimum compatible
version.

Le mer. 31 oct. 2018 à 15:14, allierosm  a écrit :

> just to clarify my question:
>
> Would it make sense to publish the plugin now and mark it as dependent of
> a JOSM development version, or rather wait until the next JOSM milestone is
> released and then publish the plugin?
> Le 31/10/2018 à 13:37, allierosm a écrit :
>
> Hello,
>
> I have made a pre-release available:
> https://github.com/JOSM/strava_heatmap/releases/tag/v0.9
>
> There is an open issue (https://github.com/JOSM/strava_heatmap/issues/2)
> and the fix will require an enhancement that is planned for the next JOSM
> milestone (https://josm.openstreetmap.de/ticket/16910).
> Until then I suppose it is better not to publish the plugin in the plugins
> list?
>
> Le 30/10/2018 à 13:09, Vincent Privat a écrit :
>
> I have invited you to the organization. Then we must follow this
> procedure:
> https://help.github.com/articles/transferring-a-repository-owned-by-your-personal-account/#transferring-to-an-organization
>
> Le mar. 30 oct. 2018 à 12:40, allierosm  a écrit :
>
>> Hello,
>>
>> Sure, I can move the plugin repository to the Github JOSM organization,
>> just let me know how to proceed.
>>
>>
>> Le 29/10/2018 à 21:29, Vincent Privat a écrit :
>>
>> Thanks! I have added a new Trac component "Plugin strava_heatmap" and set
>> you as maintainer.
>> I have reaffected #16100 to this new plugin.
>>
>> I see your plugin defines strings to be translated. Would you like to
>> bring this new plugin to the Github JOSM organization? This way it's easier
>> for everyone to update plugin translations. You will of course remain full
>> admin of the repository.
>>
>> Cheers,
>> Vincent
>>
>> Le lun. 29 oct. 2018 à 21:01, allierosm allierosm 
>> a écrit :
>>
>>> Strava heatmap plugin
>>>
>>> Hello,
>>>
>>> I have developed a JOSM plugin that provides access to the
>>> high-resolution
>>> Strava heatmaps: https://github.com/allier-osm/strava_heatmap
>>>
>>> Some month ago Strava has put in place a new authentication system on
>>> their
>>> tile server. Since then, only the low-resolution heatmaps are available
>>> in
>>> JOSM: At a zoom level > 12, the tile server expects the client to
>>> provide a
>>> session cookie.
>>>
>>> As discussed in https://josm.openstreetmap.de/ticket/16100,
>>> implementing an
>>> OAuth connector would be ideal to get access to the high-resolution
>>> heatmaps. But until such a connector is implemented a simple workaround
>>> consists in retrieving the authentication cookies from the Strava website
>>> and setting them in the tile server URL. The plugin I developed automates
>>> this process.
>>>
>>> Any feedback is welcome :-)
>>>
>>

Re: Server upgrade maintenance

[Vincent Privat]

Website is back, 2 hours top!

Le mar. 30 oct. 2018 à 17:08, Jo  a écrit :

> Good luck!
>
> Op di 30 okt. 2018 om 16:40 schreef Vincent Privat <
> vinc...@josm.openstreetmap.de>:
>
> > Hello,
> > We'll begin the maintenance in ~20 minutes, at 17:00.
> > Cheers,
> > Vincent
> >
> > Le sam. 27 oct. 2018 à 16:57, Vincent Privat <
> > vinc...@josm.openstreetmap.de>
> > a écrit :
> >
> > > Hi,
> > >
> > > As discussed in #16231 [1], we will soon upgrade our server to Ubuntu
> > > 18.04 LTS.
> > >
> > > The planned upgrade is currently scheduled to 30th October 2018 in the
> > > evening, date being subject to change.
> > >
> > > Website and all JOSM services will be unavailable during the upgrade.
> > >
> > > Cheers,
> > > Vincent
> > >
> > > [1] https://josm.openstreetmap.de/ticket/16231
> > >
> >
>

Re: Server upgrade maintenance

[Vincent Privat]

Hello,
We'll begin the maintenance in ~20 minutes, at 17:00.
Cheers,
Vincent

Le sam. 27 oct. 2018 à 16:57, Vincent Privat 
a écrit :

> Hi,
>
> As discussed in #16231 [1], we will soon upgrade our server to Ubuntu
> 18.04 LTS.
>
> The planned upgrade is currently scheduled to 30th October 2018 in the
> evening, date being subject to change.
>
> Website and all JOSM services will be unavailable during the upgrade.
>
> Cheers,
> Vincent
>
> [1] https://josm.openstreetmap.de/ticket/16231
>

Re: Strava heatmap plugin

[Vincent Privat]

I have invited you to the organization. Then we must follow this procedure:
https://help.github.com/articles/transferring-a-repository-owned-by-your-personal-account/#transferring-to-an-organization

Le mar. 30 oct. 2018 à 12:40, allierosm  a écrit :

> Hello,
>
> Sure, I can move the plugin repository to the Github JOSM organization,
> just let me know how to proceed.
>
>
> Le 29/10/2018 à 21:29, Vincent Privat a écrit :
>
> Thanks! I have added a new Trac component "Plugin strava_heatmap" and set
> you as maintainer.
> I have reaffected #16100 to this new plugin.
>
> I see your plugin defines strings to be translated. Would you like to
> bring this new plugin to the Github JOSM organization? This way it's easier
> for everyone to update plugin translations. You will of course remain full
> admin of the repository.
>
> Cheers,
> Vincent
>
> Le lun. 29 oct. 2018 à 21:01, allierosm allierosm  a
> écrit :
>
>> Strava heatmap plugin
>>
>> Hello,
>>
>> I have developed a JOSM plugin that provides access to the high-resolution
>> Strava heatmaps: https://github.com/allier-osm/strava_heatmap
>>
>> Some month ago Strava has put in place a new authentication system on
>> their
>> tile server. Since then, only the low-resolution heatmaps are available in
>> JOSM: At a zoom level > 12, the tile server expects the client to provide
>> a
>> session cookie.
>>
>> As discussed in https://josm.openstreetmap.de/ticket/16100, implementing
>> an
>> OAuth connector would be ideal to get access to the high-resolution
>> heatmaps. But until such a connector is implemented a simple workaround
>> consists in retrieving the authentication cookies from the Strava website
>> and setting them in the tile server URL. The plugin I developed automates
>> this process.
>>
>> Any feedback is welcome :-)
>>
>

Re: Strava heatmap plugin

[Vincent Privat]

Thanks! I have added a new Trac component "Plugin strava_heatmap" and set
you as maintainer.
I have reaffected #16100 to this new plugin.

I see your plugin defines strings to be translated. Would you like to bring
this new plugin to the Github JOSM organization? This way it's easier for
everyone to update plugin translations. You will of course remain full
admin of the repository.

Cheers,
Vincent

Le lun. 29 oct. 2018 à 21:01, allierosm allierosm  a
écrit :

> Strava heatmap plugin
>
> Hello,
>
> I have developed a JOSM plugin that provides access to the high-resolution
> Strava heatmaps: https://github.com/allier-osm/strava_heatmap
>
> Some month ago Strava has put in place a new authentication system on their
> tile server. Since then, only the low-resolution heatmaps are available in
> JOSM: At a zoom level > 12, the tile server expects the client to provide a
> session cookie.
>
> As discussed in https://josm.openstreetmap.de/ticket/16100, implementing
> an
> OAuth connector would be ideal to get access to the high-resolution
> heatmaps. But until such a connector is implemented a simple workaround
> consists in retrieving the authentication cookies from the Strava website
> and setting them in the tile server URL. The plugin I developed automates
> this process.
>
> Any feedback is welcome :-)
>

Server upgrade maintenance

[Vincent Privat]

 Hi,

As discussed in #16231 [1], we will soon upgrade our server to Ubuntu 18.04
LTS.

The planned upgrade is currently scheduled to 30th October 2018 in the
evening, date being subject to change.

Website and all JOSM services will be unavailable during the upgrade.

Cheers,
Vincent

[1] https://josm.openstreetmap.de/ticket/16231

Re: JOSM and lack of memory

[Vincent Privat]

Thanks.
You're using a 32-bit JRE, please uninstall it and install the 64-bit one:
https://www.java.com/en/download/manual.jsp
Cheers,
Vincent

Le lun. 22 oct. 2018 à 20:23, Bob Hawkins  a
écrit :

> Vincent
> I thank you for your reply.
> Herewith the first three blocks of the Status Report as you requested:
> {{{
> URL:https://josm.openstreetmap.de/svn/trunk
> Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
> Last:Changed Date: 2018-10-01 23:59:36 +0200 (Mon, 01 Oct 2018)
> Build-Date:2018-10-01 22:08:47
> Revision:14289
> Relative:URL: ^/trunk
>
> Identification: JOSM/1.5 (14289 en_GB) Windows 10 64-Bit
> OS Build number: Windows 10 Home 1803 (17134)
> Memory Usage: 172 MB / 247 MB (69 MB allocated, but free)
> Java version: 1.8.0_191-b12, Oracle Corporation, Java HotSpot(TM) Client VM
> Screen: \Display0 1920x1080
> Maximum Screen Size: 1920x1080
>
> Plugins:
> + ImproveOsm (145)
> + apache-commons (34506)
> + apache-http (34632)
> + ejml (34389)
> + geotools (34513)
> + jna (34633)
> + jts (34524)
> + opendata (34675)
> + reverter (34552)
> + utilsplugin2 (34506)
>
> With regards
> Bob Hawkins
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>

Re: JOSM and lack of memory

[Vincent Privat]

Can you please share the first three blocks of your status report ? (Help
-> Show Status Report)

Le lun. 22 oct. 2018 à 10:46, Bob Hawkins  a
écrit :

> I created a topic here
> https://forum.openstreetmap.org/viewtopic.php?pid=672431#p672431 almost a
> year ago, regarding sudden lack of memory.
> User Klumbumbus pointed me, helpfully, to josm.jnlp, which, the heap size
> having been edited, solved the problem.  I discovered, a month ago,
> josm.jnlp would not open.  Klumbumbus suggested downloading the current
> jnlp file from the josm website, but this did not help.  It did not matter
> too much at the time because josm.jar seemed to be working satisfactorily.
> Trying to work with it yesterday, however, was painful: Use of Bing aerial
> imagery causes any actions to be so slow that I have to delete it each time
> I wish to carry out an edit.  This is unacceptable in the longer term.
> Klumbumbus wrote, “(Also note that since Java 11 jnlp files are not
> working anymore at all since oracle removed this feature.)”, which I do not
> understand.
> I cannot be the sole JOSM user experiencing this frustration.  I wonder,
> therefore, what other solution exists?
> With regards
> Bob Hawkins
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>

Re: JOSM developers meetup at Karlsruhe?

[Vincent Privat]

I'm home :)
It was a real pleasure to finally meet everyone of you after all these
years, I really enjoyed this week-end!
I think this meetup was successful as we managed to discuss a lot about
what we want to do next with JOSM.
Michael has compiled the different discussed subjects in new Trac tickets
(thanks!) and I see Simon already attached the photos of our brainstorming
(thanks too!), all tickets can be retrieved with the hack-weekend-2018-10
keyword:
https://josm.openstreetmap.de/query?status=!closed=~hack-weekend-2018-10
Let's see this week how things go. Right now I'm going to take a long
sleep, I'm exhausted!
Cheers,
Vincent

Le ven. 19 oct. 2018 à 00:00, Jo  a écrit :

> Standards, some people can't seem to get enough of them :-)
>
> Polyglot
>
> Op do 18 okt. 2018 om 21:16 schreef Dirk Stöcker <
> openstreet...@dstoecker.de
> >:
>
> > On Mon, 15 Oct 2018, Vincent Privat wrote:
> >
> > >> After 1 day INTERGEO on Wednesday and at least 1 day RTCM standards
> > >> committee meeting on Thursday the chances are pretty low that I'll
> visit
> > >> another conference voluntarily soon. :-)
> > >
> > > It's not really a conference, it's more likely coding, talking and
> > drinking
> > > beers :) And it's not often I come to Germany ;)
> >
> > Now it is 1 day fair and 2 days standards committee and I feel like
> > afterwards I need a months holidays :-)
> >
> > My advice to everybody: If you get asked to participate in
> > standardization, RUN, as fast as possible. Don't look back!
> >
> > I wish you all fun at the meeting.
> >
> > Ciao
> > --
> > http://www.dstoecker.eu/ (PGP key available)
> >
> >
>

Re: JOSM developers meetup at Karlsruhe?

[Vincent Privat]

It's not really a conference, it's more likely coding, talking and drinking
beers :) And it's not often I come to Germany ;)

Le lun. 15 oct. 2018 à 14:17, Dirk Stöcker  a
écrit :

> On Mon, 15 Oct 2018, Vincent Privat wrote:
>
> > Can we convince you to come at least? :)
>
> After 1 day INTERGEO on Wednesday and at least 1 day RTCM standards
> committee meeting on Thursday the chances are pretty low that I'll visit
> another conference voluntarily soon. :-)
>
> Ciao
> --
> http://www.dstoecker.eu/ (PGP key available)
>
>

Re: JOSM developers meetup at Karlsruhe?

[Vincent Privat]

Can we convince you to come at least? :)

Le lun. 15 oct. 2018 à 13:45, Dirk Stöcker  a
écrit :

> On Mon, 15 Oct 2018, Wiktor Niesiobedzki wrote:
>
> > maybe less working on, but I'd like to discuss controversial tickets:
> > https://josm.openstreetmap.de/ticket/16420
> > https://josm.openstreetmap.de/ticket/8269
> >
> > I hope that face to face discussion may move us forward.
>
> You still need to convince me of the benefits and I'm not in Karlsruhe.
>
> Ciao
> --
> http://www.dstoecker.eu/ (PGP key available)
>
>

Re: JOSM developers meetup at Karlsruhe?

[Vincent Privat]

Good idea! There is also another long-standing ticket for which I would
like to move forward:
https://josm.openstreetmap.de/ticket/8645

Le lun. 15 oct. 2018 à 09:58, Wiktor Niesiobedzki  a écrit :

> Hi,
>
> maybe less working on, but I'd like to discuss controversial tickets:
> https://josm.openstreetmap.de/ticket/16420
> https://josm.openstreetmap.de/ticket/8269
>
> I hope that face to face discussion may move us forward.
>
> Cheers,
>
> Wiktor
>
> On Sun, 14 Oct 2018 at 19:27, Michael Zangl  >
> wrote:
>
> > Hi,
> >
> > are there any specific issues we will be working on those days?
> >
> > Michael
> >
> > On 03.09.2018 22:36, Vincent Privat wrote:
> > > Hello,
> > > I was thinking for quite some time about setting up a meeting between
> > JOSM
> > > developers somewhere in Germany (for convenience).
> > > As Christine and Frederik are inviting OSM developers to Karlsruhe on
> > > October 20th-21st, I just registered myself!
> > > Would other team members be interested? I'd love to meet everyone in
> > person!
> > > As for JOSM projects/activities for this hack week-end, there are
> plenty
> > of
> > > them to work on, it will depend on who's there :)
> > > Cheers,
> > > Vincent
> > >
> >
> >
>

Re: JOSM developers meetup at Karlsruhe?

[Vincent Privat]

There are at least two tickets for which I'd like to get help:
https://josm.openstreetmap.de/ticket/15229
https://josm.openstreetmap.de/ticket/16082

I was also thinking to start a major plugin cleanup projet. I think we have
too many plugins and we should see how to reduce this number (inclusion in
core, deletion or merging plugins together)

Do you have something else in mind?


Le dim. 14 oct. 2018 à 19:26, Michael Zangl 
a écrit :

> Hi,
>
> are there any specific issues we will be working on those days?
>
> Michael
>
> On 03.09.2018 22:36, Vincent Privat wrote:
> > Hello,
> > I was thinking for quite some time about setting up a meeting between
> JOSM
> > developers somewhere in Germany (for convenience).
> > As Christine and Frederik are inviting OSM developers to Karlsruhe on
> > October 20th-21st, I just registered myself!
> > Would other team members be interested? I'd love to meet everyone in
> person!
> > As for JOSM projects/activities for this hack week-end, there are plenty
> of
> > them to work on, it will depend on who's there :)
> > Cheers,
> > Vincent
> >
>
>

Re: Caching mechanisms on GPX layers

[Vincent Privat]

Did you check if GpxDrawHelper.gpxDataChanged is called? This is where the
GPX drawing cache is reset.

Le sam. 15 sept. 2018 à 15:25, Niklas B  a écrit :

> ... and this is why I hate mailing lists.
> How it looks like after merging:
> http://fs5.directupload.net/images/180915/n57lqu5o.png
> And after converting back and forth:
> http://fs1.directupload.net/images/180915/bjg4nn5a.png
>
> Sorry for the mess
> Niklas
>
> Am So., 16. Sep. 2018 um 01:20 Uhr schrieb Niklas B <
> b.n.burch...@gmail.com
> >:
>
> > Am Sa., 15. Sep. 2018 um 22:41 Uhr schrieb Dirk Stöcker <
> > openstreet...@dstoecker.de>:
> >
> >> Maybe your troubles come from the fact that JOSM has different settings
> >> for local and server based GPS data (i.e. distances for continuous track
> >> handling)?
> >
> >
> > No, unfortunately not. All tracks were loaded locally and the connected
> > points don't really make any sense at all, on productive data I had
> > connected trackpoints that were multiple months apart and on the other
> side
> > of the globe... (just for clarification btw: My implementation cuts
> > timewise overlapping tracks)
> >
> > Here's an example (it looks that weird because I'm planning on using it
> > for unit tests and it's supposed to cover pretty much every specific
> case,
> > e.g. entire "high level" track segments being between two waypoints of a
> > "low level" track etc.)
> >
> > This is how it looks like directly after merging:
> >
> >
> > And this is how it's supposed to look like / how it looks after
> converting
> > it back and forth:
> >
> >
> > The GpxData is correct, at least when being exported, so I'm pretty sure
> > it's some kind of caching / rendering issue...
> >
> > But if nobody has an idea I'll just finish the patch first, maybe someone
> > finds the bug after I published it. I just thought that there might be
> some
> > kind of caching somewhere that I wasn't aware of.
> >
> > Cheers
> > Niklas
> >
>

Re: JOSM developers meetup at Karlsruhe?

[Vincent Privat]

It's of course open to everyone "interested in JOSM development". Not just
current developers :) I'm happy to see so many people coming!

Le dim. 9 sept. 2018 à 15:39, Holger Mappt  a écrit :

> Hi,
>
> I don't consider myself a real JOSM developer and I didn't have much
> time to contribute lately. But I would like to spend more time working
> on the project, so that's a good reason to get it started. Count me in.
>
> Regards,
> Holger
>
>
> On 03.09.18 at 22:36 Vincent Privat wrote:
> > Hello,
> > I was thinking for quite some time about setting up a meeting between
> JOSM
> > developers somewhere in Germany (for convenience).
> > As Christine and Frederik are inviting OSM developers to Karlsruhe on
> > October 20th-21st, I just registered myself!
> > Would other team members be interested? I'd love to meet everyone in
> person!
> > As for JOSM projects/activities for this hack week-end, there are plenty
> of
> > them to work on, it will depend on who's there :)
> > Cheers,
> > Vincent
> >
>
>
>

JOSM developers meetup at Karlsruhe?

[Vincent Privat]

Hello,
I was thinking for quite some time about setting up a meeting between JOSM
developers somewhere in Germany (for convenience).
As Christine and Frederik are inviting OSM developers to Karlsruhe on
October 20th-21st, I just registered myself!
Would other team members be interested? I'd love to meet everyone in person!
As for JOSM projects/activities for this hack week-end, there are plenty of
them to work on, it will depend on who's there :)
Cheers,
Vincent

Re: "AtkWrapper not found" error impacting JOSM on Ubuntu/Mint

[Vincent Privat]

Hello,
The bug is closed so there is nothing to expect from OpenJDK. The solution
must come from Debian or a new bug created.
The Java version which introduced the regression is
10.0.2+13-Ubuntu-1ubuntu0.18.04.1
because it contains the fix to move accessibility.properties in the "conf"
folder. The issue did not occur before because the configuration file
enabling ATK wrapper was not found by openjdk. A few hours after this
version was delivered by Ubuntu we started to receive a dozen of bug
reports, until I delivered a JOSM hotfix mitigating the issue.

Patching openjdk with your try/catch proposal and making the ATK wrapper a
Recommends sounds a good idea.

Don't wait for openjdk guys for an answer: they simply don't care anymore
with desktop technologies.

Cheers,
Vincent

Le ven. 24 août 2018 à 11:47, Samuel Thibault  a
écrit :

> Hello,
>
> Vincent Privat, le mer. 22 août 2018 21:01:16 +0200, a ecrit:
> > Samuel, do you know when the root issue will be fixed in Java ATK
> wrapper?
>
> The root issue is in openjdk, not the wrapper. Openjdk has apparently
> removed the way that was used to load the wrapper, without apparently
> making sure that another way was implemented. I have forwarded the issue
> upstream
>
> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8204862
>
> but apparently they don't have the issue (I guess they don't actually
> manage to enable the wrapper in the configuration file).
>
> > > > Since today we are spammed by bug reports from Linux Mint and Ubuntu
> when
> > > > people try to launch JOSM with the latest Java update
> > > > (10.0.2+13-Ubuntu-1ubuntu0.18.04.1):
>
> Which version is introducing the issue exactly?  AFAIK it's the whole
> openjdk >= 9 which poses the problem.
>
> > Has it ever been considered that this package is made optional rather
> than a
> > strict dependency of openjdk--jre?
>
> The problem is not the dependency, but what openjdk itself is doing. ATM
> it seems to be insisting on loading the wrapper even when it's not
> available.  I guess catching exceptions around
> src/java.desktop/share/classes/java/awt/Toolkit.java's getDefaultToolkit
> call to loadAssistiveTechnologies, to just print the exception but not
> abort, would allow to make the dependency a Recommends only.
>
> Concerning actually managing to load the wrapper, see the backlog of
> #900912. I have commited to the git repo of java-atk-wrapper what is
> said to be needed for making it loadable with openjdk 9 and later, but
> as I said there, we still seem to be lacking in openjdk a path where the
> wrapper can be put for openjdk to find it. And it's been a month without
> anybody answering.
>
> Samuel
>

Re: "AtkWrapper not found" error impacting JOSM on Ubuntu/Mint

[Vincent Privat]

JOSM 14178 has been released as new tested version to workaround this
problem.
Samuel, do you know when the root issue will be fixed in Java ATK wrapper?
Has it ever been considered that this package is made optional rather than
a strict dependency of openjdk--jre? Most users don't need it.
Cheers,
Vincent

Le mer. 22 août 2018 à 02:49, Vincent Privat 
a écrit :

> I remember too, it was indeed a nightmare and I don't want to live that
> again.
> It took me a while but I found a workaround that doesn't need any user
> action nor any adherence to ATK wrapper.
> We can just catch the AWTError and try again to re-create our MainFrame.
> As the ATK initialization fails only after the AWT toolkit has been
> created, the second call succeeds:
> https://josm.openstreetmap.de/changeset/14177/josm
>
> Kevin, can you please check tomorrow that it works for you too?
> I'm leaving the ticket open a few days as we will probably receive many
> more bug reports this week.
>
> Right now it's too difficult to disable ATK on Java 10 and remain
> compatible with Java 8. I'll revisit this topic once we migrate to Java 11.
>
> Cheers,
> Vincent
>
> Le mer. 22 août 2018 à 01:14, Kevin Kenny  a
> écrit :
>
>> On Tue, Aug 21, 2018 at 5:48 PM Vincent Privat
>>  wrote:
>> >
>> > I found this bug:
>> > https://bugs.launchpad.net/ubuntu/+source/openjdk-lts/+bug/1788250
>> > Vincent
>> >
>> > Le mar. 21 août 2018 à 23:27, Vincent Privat <
>> vinc...@josm.openstreetmap.de>
>> > a écrit :
>> >
>> > > Hello,
>> > > Since today we are spammed by bug reports from Linux Mint and Ubuntu
>> when
>> > > people try to launch JOSM with the latest Java update
>> > > (10.0.2+13-Ubuntu-1ubuntu0.18.04.1):
>> > >
>> > > https://josm.openstreetmap.de/ticket/1
>> > >
>> > > The error is "ClassNotFoundException:
>> org.GNOME.Accessibility.AtkWrapper".
>> > >
>> > > Is it a known issue? We cannot really workaround it unless telling
>> every
>> > > impacted user to manually disable ATK wrapper in
>> accessibility.properties.
>> > >
>> > > Thanks,
>> > > Vincent
>> > >
>>
>> Even deleting the ATK wrapper in accessibility.properties doesn't help,
>> you also have to launch JOSM with a command like
>>
>> java -Xmx1g -Xbootclasspath/a:/usr/share/java/java-atk-wrapper.jar
>> -jar ~/josm/josm-tested.jar
>>
>> When I do both things, it appears to work around the problem.
>>
>> AtkWrapper is a nightmare. I remember when
>> https://josm.openstreetmap.de/ticket/12022
>> had me using Meerkartor for a while.
>>
>

Re: "AtkWrapper not found" error impacting JOSM on Ubuntu/Mint

[Vincent Privat]

I remember too, it was indeed a nightmare and I don't want to live that
again.
It took me a while but I found a workaround that doesn't need any user
action nor any adherence to ATK wrapper.
We can just catch the AWTError and try again to re-create our MainFrame. As
the ATK initialization fails only after the AWT toolkit has been created,
the second call succeeds:
https://josm.openstreetmap.de/changeset/14177/josm

Kevin, can you please check tomorrow that it works for you too?
I'm leaving the ticket open a few days as we will probably receive many
more bug reports this week.

Right now it's too difficult to disable ATK on Java 10 and remain
compatible with Java 8. I'll revisit this topic once we migrate to Java 11.

Cheers,
Vincent

Le mer. 22 août 2018 à 01:14, Kevin Kenny  a
écrit :

> On Tue, Aug 21, 2018 at 5:48 PM Vincent Privat
>  wrote:
> >
> > I found this bug:
> > https://bugs.launchpad.net/ubuntu/+source/openjdk-lts/+bug/1788250
> > Vincent
> >
> > Le mar. 21 août 2018 à 23:27, Vincent Privat <
> vinc...@josm.openstreetmap.de>
> > a écrit :
> >
> > > Hello,
> > > Since today we are spammed by bug reports from Linux Mint and Ubuntu
> when
> > > people try to launch JOSM with the latest Java update
> > > (10.0.2+13-Ubuntu-1ubuntu0.18.04.1):
> > >
> > > https://josm.openstreetmap.de/ticket/1
> > >
> > > The error is "ClassNotFoundException:
> org.GNOME.Accessibility.AtkWrapper".
> > >
> > > Is it a known issue? We cannot really workaround it unless telling
> every
> > > impacted user to manually disable ATK wrapper in
> accessibility.properties.
> > >
> > > Thanks,
> > > Vincent
> > >
>
> Even deleting the ATK wrapper in accessibility.properties doesn't help,
> you also have to launch JOSM with a command like
>
> java -Xmx1g -Xbootclasspath/a:/usr/share/java/java-atk-wrapper.jar
> -jar ~/josm/josm-tested.jar
>
> When I do both things, it appears to work around the problem.
>
> AtkWrapper is a nightmare. I remember when
> https://josm.openstreetmap.de/ticket/12022
> had me using Meerkartor for a while.
>

Re: "AtkWrapper not found" error impacting JOSM on Ubuntu/Mint

[Vincent Privat]

I found this bug:
https://bugs.launchpad.net/ubuntu/+source/openjdk-lts/+bug/1788250
Vincent

Le mar. 21 août 2018 à 23:27, Vincent Privat 
a écrit :

> Hello,
> Since today we are spammed by bug reports from Linux Mint and Ubuntu when
> people try to launch JOSM with the latest Java update
> (10.0.2+13-Ubuntu-1ubuntu0.18.04.1):
>
> https://josm.openstreetmap.de/ticket/1
>
> The error is "ClassNotFoundException: org.GNOME.Accessibility.AtkWrapper".
>
> Is it a known issue? We cannot really workaround it unless telling every
> impacted user to manually disable ATK wrapper in accessibility.properties.
>
> Thanks,
> Vincent
>

"AtkWrapper not found" error impacting JOSM on Ubuntu/Mint

[Vincent Privat]

Hello,
Since today we are spammed by bug reports from Linux Mint and Ubuntu when
people try to launch JOSM with the latest Java update
(10.0.2+13-Ubuntu-1ubuntu0.18.04.1):

https://josm.openstreetmap.de/ticket/1

The error is "ClassNotFoundException: org.GNOME.Accessibility.AtkWrapper".

Is it a known issue? We cannot really workaround it unless telling every
impacted user to manually disable ATK wrapper in accessibility.properties.

Thanks,
Vincent

Re: New version of JOSM noticably sluggisher and becoming unresponsive

[Vincent Privat]

Please try first by disabling this plugin before blaming JOSM...

Le dim. 19 août 2018 à 11:41, Maarten Deen  a écrit :

> In this case I was also working with bus routes and the PT Assistant.
>
> Regards,
> Maarten
>
> On 2018-08-19 11:35, Jo wrote:
> > I'm also noticing that JOSM sometimes hangs. In my case it is then
> > consuming >300% processing power. I often see it right after panning
> > the map.
> >
> > I'm beta testing PT_Assistant and can't be sure whether that has
> > something to do with it. It's drawing many labels for all the bus
> > stops, which are calculated based on route membership. This worked
> > well before, but then it was only shown for the stops of the active
> > route relation.
> >
> > Polyglot
> >
> > Op zo 19 aug. 2018 om 11:01 schreef Maarten Deen :
> >
> >> I don't know if other people notice this too, but the new version of
> >>
> >> JOSM (14163) is noticably more shluggish than the previous version.
> >> Moving nodes is not fluent but jerky. And after some time it just
> >> stops
> >> responding.
> >> It starts with the same symptoms as I mentioned in bug 16403 [1] and
> >>
> >> then after a while it just stops working. It is just unresponsive
> >> without taking processor power.
> >>
> >> Doing several restarts I notice different strange behaviours. I
> >> thought
> >> maybe it was related to having a large dataset open so now I have a
> >> smaller one, but now I have the "Add value?" dialog open and I can't
> >>
> >> change anything there and the ok, cancel or help buttons are
> >> unresponsive. And obviously I can't click on the main screen because
> >> the
> >> Add value? dialog is modal.
> >> For some reason the JAVA debug screen is also unresponsive.
> >>
> >> I'm going back to an older version because this does not work at all
> >> for
> >> me.
> >>
> >> [1] 
> >>
> >> Regards,
> >> Maarten
>
>

Re: JMapViewer release downloads no longer available

[Vincent Privat]

OK. This is not linked to JMapViewer itself but likely caused by a software
upgrade or a change of configuration on OSM SVN server.
Can you adapt the Debian watcher to the new links?
It's also possible to get the latest version with this SVN command:

$ svn propget ReleaseVersion
https://svn.openstreetmap.org/applications/viewer/jmapviewer
2.7

Cheers,
Vincent

Le sam. 18 août 2018 à 15:35, Sebastiaan Couwenberg  a
écrit :

> On 08/18/2018 03:20 PM, Vincent Privat wrote:
> > What do you mean by "not available"? The page is displayed and we can
> > download releases from there.
>
> IIRC there was an index page which contained the links to all the releases.
>
> This was used by uscan(1) in the Debian package to check for new
> upstream releases. This doesn't work any more:
>
> $ uscan --report
> uscan warn: In debian/watch,
>   no matching hrefs for pattern
>
>
> https://svn.openstreetmap.org/applications/viewer/jmapviewer/releases/(\d+(?
> <https://svn.openstreetmap.org/applications/viewer/jmapviewer/releases/(%5Cd+(?>
> :\.\d+)*)
> at /usr/bin/uscan line 4307,  line 3.
>
> Looking at the page HTML the links to the version directories changed from:
>
>2.0/
>
> To:
>
> 
>
> > Le sam. 18 août 2018 à 12:16, Sebastiaan Couwenberg 
> a
> > écrit :
> >
> >> With the deprecation of svn.openstreetmap.org, the JMapViewer release
> >> page [0] is no longer available.
> >>
> >> The banner at the top refers to the OpenStreetMap organisation on
> >> GitHub, but there is no jmapviewer project there.
> >>
> >> Are there plans to move jmapviewer to GitHub, or if not, can the release
> >> download page be restored?
> >>
> >> [0]
> https://svn.openstreetmap.org/applications/viewer/jmapviewer/releases/
>
>
>

Re: JMapViewer release downloads no longer available

[Vincent Privat]

Hi Sebastiaan,
What do you mean by "not available"? The page is displayed and we can
download releases from there.
Cheers,
Vincent

Le sam. 18 août 2018 à 12:16, Sebastiaan Couwenberg  a
écrit :

> With the deprecation of svn.openstreetmap.org, the JMapViewer release
> page [0] is no longer available.
>
> The banner at the top refers to the OpenStreetMap organisation on
> GitHub, but there is no jmapviewer project there.
>
> Are there plans to move jmapviewer to GitHub, or if not, can the release
> download page be restored?
>
> [0] https://svn.openstreetmap.org/applications/viewer/jmapviewer/releases/
>
> Kind Regards,
>
> Bas
>
>

Re: YourKit free license for JOSM core developers

[Vincent Privat]

Wiki updated: https://josm.openstreetmap.de/wiki/DevelopersGuide#YourKit
We should receive the licenses tomorrow.
Cheers,
Vincent


2018-06-22 23:20 GMT+02:00 Michael Zangl :

> Hi,
>
> I'm interested (since I already did quite some profiling on the rendering
> stuff).
>
> But to be honest, I probably won't have the time to do anything useful in
> that direction this year.
>
> Michael
>
>
> On 22.06.2018 19:46, Vincent Privat wrote:
>
>> I only got answer from Dirk. Nobody else interested? Paul, Wiktor,
>> Michael?
>>
>> 2018-06-18 21:00 GMT+02:00 Vincent Privat :
>>
>> I guess we can chose our own text, that was only the marketing example
>>> they gave me :)
>>> For the page, any page is OK. If you look at the list of supported
>>> projects:
>>> https://www.yourkit.com/customers/
>>>
>>> The page linked there is not always the front page. For example ActiveMQ
>>> has defined a "thanks" page:
>>> http://activemq.apache.org/thanks.html
>>>
>>> 2018-06-18 19:37 GMT+02:00 Dirk Stöcker :
>>>
>>> On Mon, 18 Jun 2018, Vincent Privat wrote:
>>>>
>>>> In return they require that we place a small free-form text
>>>>
>>>>> acknowledgment/testimonial at the project web site. The acknowledgment
>>>>> should contain:
>>>>>
>>>>> 1) The YourKit logo and a text that JOSM uses YourKit profiler. The
>>>>> following logo must be used:
>>>>> https://www.yourkit.com/images/yklogo.png
>>>>>
>>>>> 2) Acknowledgment should contain a hyperlink reference to YourKit web
>>>>> site.
>>>>> For example:
>>>>> "YourKit supports open source projects with its full-featured Java
>>>>> Profiler.
>>>>> YourKit, LLC is the creator of https://www.yourkit.com/
>>>>> java/profiler/">YourKit Java Profiler, innovative and intelligent
>>>>> tools
>>>>> for profiling Java and .NET applications."
>>>>>
>>>>>
>>>> Can we choose that text? I'd prefer an honest text instead of Marketing
>>>> BlaBla.
>>>>
>>>> Like
>>>>
>>>> JOSM core developers are uing the https://www.yourkit.com/
>>>> java/profiler/">YourKit Java Profiler, as we found other tools
>>>> lacking required functionality for profiling. YourKit supports open
>>>> source
>>>> projects by granting developers free licenses.
>>>>
>>>> @Dirk: no objection to add this to the JOSM website?
>>>>
>>>>>
>>>>>
>>>> Would it be ok on one (or more) of the development related pages like
>>>>
>>>> https://josm.openstreetmap.de/wiki/DevelopersGuide
>>>>
>>>> That's one click away from the start page.
>>>>
>>>> Ciao
>>>> --
>>>> http://www.dstoecker.eu/ (PGP key available)
>>>>
>>>>
>>>>
>>>
>

Re: YourKit free license for JOSM core developers

[Vincent Privat]

I only got answer from Dirk. Nobody else interested? Paul, Wiktor, Michael?

2018-06-18 21:00 GMT+02:00 Vincent Privat :

> I guess we can chose our own text, that was only the marketing example
> they gave me :)
> For the page, any page is OK. If you look at the list of supported
> projects:
> https://www.yourkit.com/customers/
>
> The page linked there is not always the front page. For example ActiveMQ
> has defined a "thanks" page:
> http://activemq.apache.org/thanks.html
>
> 2018-06-18 19:37 GMT+02:00 Dirk Stöcker :
>
>> On Mon, 18 Jun 2018, Vincent Privat wrote:
>>
>> In return they require that we place a small free-form text
>>> acknowledgment/testimonial at the project web site. The acknowledgment
>>> should contain:
>>>
>>> 1) The YourKit logo and a text that JOSM uses YourKit profiler. The
>>> following logo must be used:
>>> https://www.yourkit.com/images/yklogo.png
>>>
>>> 2) Acknowledgment should contain a hyperlink reference to YourKit web
>>> site.
>>> For example:
>>> "YourKit supports open source projects with its full-featured Java
>>> Profiler.
>>> YourKit, LLC is the creator of https://www.yourkit.com/
>>> java/profiler/">YourKit Java Profiler, innovative and intelligent
>>> tools
>>> for profiling Java and .NET applications."
>>>
>>
>> Can we choose that text? I'd prefer an honest text instead of Marketing
>> BlaBla.
>>
>> Like
>>
>> JOSM core developers are uing the https://www.yourkit.com/
>> java/profiler/">YourKit Java Profiler, as we found other tools
>> lacking required functionality for profiling. YourKit supports open source
>> projects by granting developers free licenses.
>>
>> @Dirk: no objection to add this to the JOSM website?
>>>
>>
>> Would it be ok on one (or more) of the development related pages like
>>
>> https://josm.openstreetmap.de/wiki/DevelopersGuide
>>
>> That's one click away from the start page.
>>
>> Ciao
>> --
>> http://www.dstoecker.eu/ (PGP key available)
>>
>>
>

Re: YourKit free license for JOSM core developers

[Vincent Privat]

I guess we can chose our own text, that was only the marketing example they
gave me :)
For the page, any page is OK. If you look at the list of supported projects:
https://www.yourkit.com/customers/

The page linked there is not always the front page. For example ActiveMQ
has defined a "thanks" page:
http://activemq.apache.org/thanks.html

2018-06-18 19:37 GMT+02:00 Dirk Stöcker :

> On Mon, 18 Jun 2018, Vincent Privat wrote:
>
> In return they require that we place a small free-form text
>> acknowledgment/testimonial at the project web site. The acknowledgment
>> should contain:
>>
>> 1) The YourKit logo and a text that JOSM uses YourKit profiler. The
>> following logo must be used:
>> https://www.yourkit.com/images/yklogo.png
>>
>> 2) Acknowledgment should contain a hyperlink reference to YourKit web
>> site.
>> For example:
>> "YourKit supports open source projects with its full-featured Java
>> Profiler.
>> YourKit, LLC is the creator of https://www.yourkit.com/
>> java/profiler/">YourKit Java Profiler, innovative and intelligent
>> tools
>> for profiling Java and .NET applications."
>>
>
> Can we choose that text? I'd prefer an honest text instead of Marketing
> BlaBla.
>
> Like
>
> JOSM core developers are uing the https://www.yourkit.com/
> java/profiler/">YourKit Java Profiler, as we found other tools
> lacking required functionality for profiling. YourKit supports open source
> projects by granting developers free licenses.
>
> @Dirk: no objection to add this to the JOSM website?
>>
>
> Would it be ok on one (or more) of the development related pages like
>
> https://josm.openstreetmap.de/wiki/DevelopersGuide
>
> That's one click away from the start page.
>
> Ciao
> --
> http://www.dstoecker.eu/ (PGP key available)
>
>

YourKit free license for JOSM core developers

[Vincent Privat]

Hello,
We receive more and more tickets about performance problems when
zooming/panning the map.
The subject is complex and to help analyzing it I asked to YourKit a free
license for JOSM, as neither VisualVM nor Java Mission Control match my
need to find hotspots:
https://www.yourkit.com/java/profiler/features/

They agreed so we can receive personal licenses for every JOSM core
developer interested in using this tool.

In return they require that we place a small free-form text
acknowledgment/testimonial at the project web site. The acknowledgment
should contain:

1) The YourKit logo and a text that JOSM uses YourKit profiler. The
following logo must be used:
https://www.yourkit.com/images/yklogo.png

2) Acknowledgment should contain a hyperlink reference to YourKit web site.
For example:
"YourKit supports open source projects with its full-featured Java Profiler.
YourKit, LLC is the creator of https://www.yourkit.com/
java/profiler/">YourKit Java Profiler, innovative and intelligent tools
for profiling Java and .NET applications."

I tried the tool with a trial license and it is really great so it will
help to fix performance bottlenecks.

@Dirk: no objection to add this to the JOSM website?
@team: for those interested, please send me in private your name, surname
and e-mail information you would like to share with YourKit to obtain the
personal license. I'll send the list by Friday.

Cheers,
Vincent

Re: Publish plugin issue

[Vincent Privat]

Hello,
This involves unneeded work from us. As said before, please restore the
previous mechanism, which is being used for Nexus, and simply make sure
only the plugin jar is commited, this is the only change that is required.
Best regards,
Vincent

2018-06-01 11:07 GMT+02:00 Holger Mappt :

> On 2018-05-31 at 21:00 +0200 Dirk Stöcker wrote:
>
>> On Thu, 31 May 2018, Michael Zangl wrote:
>>
>> We currently have all snapshot plugin jars including source/javadoc on
>>> the nexus server:
>>>
>>> https://josm.openstreetmap.de/nexus/content/groups/public/or
>>> g/openstreetmap/josm/plugins/
>>>
>>> You can pull them from there if you need them for anything.
>>>
>>> For local development, you could just check out and add the source
>>> directory of the plugin to your favorite IDE, you don't need a jar file for
>>> this.
>>>
>>
>> You forget that the nexus server uses this build procedure. If it is
>> disabled files will be gone there as well.
>>
>
> Hi,
>
> That is the first hint what the sources and javadoc JARs are used for. Is
> there a description how the Nexus thing works? What targets does it call?
> How does it know what files are to be kept and from where to take them?
>
> How about a new target like "dist-all" that can be used to generate
> everything that one can dream of? That target is used by Nexus or by
> whoever wants everything. The regular plugin developer will continue to use
> "dist". "dist-all" will generate the JARs in the dist directory,
> *-javadoc.jar and *-sources.jar are in the ignore list already. No SVN
> update/commit for sources.jar and javadoc.jar.
>
> Regards,
> Holger
>
> PS: The shenron.openstreetmap.org mail server delays the emails, e.g.
> Dirks email was delayed by 8 hours. Does someone know why it does that? The
> messages show up in the mail archive immediately, but I need to wait until
> I get it to be able to reply.
>
>
>

Re: Publish plugin issue

[Vincent Privat]

Ah sorry I totally misunderstood your change. Please restore what I did, I
thought you would only modify the "publish" target to ignore the files when
committing to SVN, not delete the targets!

2018-05-29 22:03 GMT+02:00 Holger Mappt :

> Hi,
>
> I implemented the two changes in r34224 and r34225. This undid most of the
> changes to build-common.xml from r34045 where plugin-sources.jar and
> plugin-javadoc.jar were added.
>
> Marián, it should work for you now.
>
> Regards,
> Holger
>
>
> On 2018-05-27 at 12:18 +0200 Vincent Privat wrote:
>
>> No objections:)
>>
>> Le sam. 26 mai 2018 à 22:54, Holger Mappt > gmane.org> a écrit :
>>
>> Hi Marián,
>>>
>>> There are two problems and I can confirm your issue.
>>>
>>> Problem one is "ant update-current" which expands ../dist/${plugin.jar}
>>> to ../dist/home/marian/projekty/josm/josm_plugins/dist/pointInfo.jar
>>> instead of ../dist/pointInfo.jar. The ../dist/ must be removed in the
>>> target, the path to dist is part of ${plugin.jar} already.
>>>
>>> Problem two is that "ant commit-dist" tries to commit
>>> pointInfo-javadoc.jar and pointInfo-sources.jar. I think they should not
>>> be committed. They are in the ignore list (svn pl -v ../../dist) and I
>>> don't see that other plugins have them in dist. SVN fails to commit the
>>> two files because they are not "svn add"ed.
>>>
>>> I assume you are the only one who uses the publish target. Otherwise all
>>> others would see the same problem.
>>>
>>> Who else uses "ant publish"? If there are no objections I will make
>>> these two changes to build-common.xml:
>>> * Remove ../dist/ from update-current
>>> * Do not update/publish/commit plugin.sources.jar and plugin.javadoc.jar
>>>
>>> Regards,
>>> Holger
>>>
>>
>
>

Re: Publish plugin issue

[Vincent Privat]

No objections:)

Le sam. 26 mai 2018 à 22:54, Holger Mappt  a écrit :

> Hi Marián,
>
> There are two problems and I can confirm your issue.
>
> Problem one is "ant update-current" which expands ../dist/${plugin.jar}
> to ../dist/home/marian/projekty/josm/josm_plugins/dist/pointInfo.jar
> instead of ../dist/pointInfo.jar. The ../dist/ must be removed in the
> target, the path to dist is part of ${plugin.jar} already.
>
> Problem two is that "ant commit-dist" tries to commit
> pointInfo-javadoc.jar and pointInfo-sources.jar. I think they should not
> be committed. They are in the ignore list (svn pl -v ../../dist) and I
> don't see that other plugins have them in dist. SVN fails to commit the
> two files because they are not "svn add"ed.
>
> I assume you are the only one who uses the publish target. Otherwise all
> others would see the same problem.
>
> Who else uses "ant publish"? If there are no objections I will make
> these two changes to build-common.xml:
> * Remove ../dist/ from update-current
> * Do not update/publish/commit plugin.sources.jar and plugin.javadoc.jar
>
> Regards,
> Holger
>
>
> On 2018-05-23 at 22:31 +0200 Marián Kyral wrote:
> > Hi,
> > sorry for the late reply.
> >
> > Dne 17.5.2018 v 22:03 Holger Mappt napsal(a):
> >> Hi Marián,
> >>
> >> Looks like you managed to publish the PointInfo plugin in the meantime
> >> (r34195).
> > Yes, I did it manually by committing the binary with proper commit
> message.
> >
> >> An SVN status with ! is never good. I assume there was a newer version
> >> in the repo that was not fetched because you had a modified
> >> dist/pointInfo.jar. Run svn status with option -u (to see what updates
> >> are in the repository), delete your modified pointInfo.jar, svn update
> >> dist, publish.
> > And this is strange. I deleted the binary and restored them from repo.
> > Then I run "ant publish", it deleted binary in "dist" folder, compile
> > it, created the "*-source.jar" and "*-javadoc.jar" files and svn commit
> > fails on messages I've sent.
> >
> >
> > *Just tested now ant the result is the same. Folders are clean*
> >
> > [22:06:24 marian@worker pointInfo (master)]$ svn status -u
> > Status against revision:  34216
> > [22:10:39 marian@worker pointInfo (master)]$ svn status -u ../../dist
> > Status against revision:  34216
> >
> > *But:*
> >
> > [22:10:55 marian@worker pointInfo (master)]$ ant publish
> > Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on
> > -Dswing.aatext=true
> > Buildfile:
> > /home/marian/projekty/josm/josm_plugins/plugins/pointInfo/build.xml
> >
> > ensure-svn-present:
> >
> > core-info:
> >   [echo] Building against core revision 13823.
> >   [echo] Plugin-Mainversion is set to 12666.
> > [delete] Deleting:
> > /home/marian/projekty/josm/josm_plugins/plugins/pointInfo/core.info.xml
> >
> > commit-current:
> >   [echo] Commiting the plugin source with message 'PointInfo: Adds a
> > link to photo metadata in Catastro module. Patch by Javier Sánchez
> > Portero.' ...
> >
> > update-current:
> >   [echo] Updating plugin source ...
> >   [echo] Updating
> > /home/marian/projekty/josm/josm_plugins/dist/pointInfo.jar ...
> >   [exec] Result: 1
> >
> > [...]
> >
> > commit-dist:
> >   [echo]
> >   [echo] * Properties of published
> > /home/marian/projekty/josm/josm_plugins/dist/pointInfo.jar *
> >   [echo] Commit message: 'PointInfo: Adds a link to photo
> > metadata in Catastro module. Patch by Javier Sánchez Portero.'
> >   [echo] Plugin-Mainversion: 12666
> >   [echo] JOSM build version: 13823
> >   [echo] Plugin-Version: 34216
> >   [echo] * / Properties of published
> > /home/marian/projekty/josm/josm_plugins/dist/pointInfo.jar *
> >   [echo]
> >   [echo] Now commiting
> > /home/marian/projekty/josm/josm_plugins/dist/pointInfo.jar ...
> >   [echo]
> >   [exec] Result: 1
> >
> > publish:
> >
> > BUILD SUCCESSFUL
> > Total time: 11 seconds
> >
> >
> > *The svn.log*
> >
> > [22:15:06 marian@worker pointInfo (master)]$ cat svn.log
> > [...]
> >
> > Updating '.':
> > At revision 34216.
> > Skipped
> > '../dist/home/marian/projekty/josm/josm_plugins/dist/pointInfo.jar'svn:
> > E155007: None of the targets are working copies
> >
> > Skipped
> >
> '../dist/home/marian/projekty/josm/josm_plugins/dist/pointInfo-javadoc.jar'
> > Skipped
> >
> '../dist/home/marian/projekty/josm/josm_plugins/dist/pointInfo-sources.jar'
> > svn: E29: Commit failed (details follow):
> > svn: E29:
> > '/home/marian/projekty/josm/josm_plugins/dist/pointInfo-sources.jar' is
> > not under version control
> >
> > *And current status:*
> >
> > [22:15:10 marian@worker pointInfo (master)]$ svn status -u
> > ?svn.log
> > Status against revision:  34216
> > [22:23:10 marian@worker pointInfo (master)]$ svn status -u ../../dist
> > M34216   ../../dist/pointInfo.jar
> > Status against 

Re: Release Announcement: General Availability of JDK 10

[Vincent Privat]

Hi Dalibor,
One last question concerning JOSM & Quality Outreach.
Three years ago I asked about this:
https://bugs.openjdk.java.net/browse/JDK-8058778
There was real progress making us believe it would land in Java 9, then
nothing.
Can you please give us a status update?
Thanks,
Vincent


2018-04-11 12:02 GMT+02:00 dalibor topic <dalibor.to...@oracle.com>:

> Hi Vincent,
>
> On 10.04.2018 19:47, Vincent Privat wrote:
>
>> Hi Rory, Dalibor,
>> Thank you. I thought we started something constructive between our open
>> source project and Oracle.
>> But our last bug report concerned WebStart, which is very slow with
>> Java9+.
>> I spent quite a few hours investigating the issue and created I think a
>> nicely described bug report 3 months ago:
>> https://bugs.openjdk.java.net/browse/JDK-8196053
>> All of this for nothing: the bug has been closed as won't fix...
>>
>
> Thank you for the bug report. Per http://www.oracle.com/technetw
> ork/java/eol-135779.html
>
> "Although the deployment stack may be included in Java SE 9 or later
> releases, Java SE 8 is the recommended and only supported version of the
> deployment stack."
>
> I hope that makes it clearer why this particular issue was closed.
>
> If you find that the problem which you have noticed with WebStart persists
> on Java SE 8, please do consider filing a separate issue at bugs.java.com.
>
> cheers,
> dalibor topic
>
> Vincent
>>
>> 2018-03-22 14:26 GMT+01:00 Rory O'Donnell <rory.odonn...@oracle.com
>> <mailto:rory.odonn...@oracle.com>>:
>>
>> Hi Vincent,
>>
>> Let me add my thanks as well , you have been mentioned on a number
>> of occasions in the Quality reports.
>>
>> Best regards, Rory
>>
>>
>>
>> On 22/03/2018 13:00, dalibor topic wrote:
>>
>> Hi Vincent,
>>
>> thank you very much for all your hard work so far in the Quality
>> Outreach - for the bug reports, testing, feedback and all the
>> help.
>>
>> I understand that the end of the road for Java Web Start with
>> Java SE 11 is disappointing. I think the alternative that may be
>> worth exploring would be to use jlink instead, but I also
>> completely understand that it's not something you'd want to
>> spent your time on now, in any case.
>>
>> All the best for you and the JOSM project, and thank you for all
>> your contributions. I'll ask Rory to drop JOSM from the Outreach
>> Wiki, and stop sending e-mails to the josm-dev mailing list.
>>
>> cheers,
>> dalibor topic
>>
>>
>> -- Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA, Dublin,Irelan
>> <https://maps.google.com/?q=Oracle+EMEA,+Dublin,Irelan=gmail=g>
>> d
>>
>>
>>
> --
> <http://www.oracle.com> Dalibor Topic | Principal Product
> <https://maps.google.com/?q=%7C+Principal+Product=gmail=g>
> Manager
> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
> <tel:+491737185961>
>
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment
>

Re: The (dark) future of Java on desktop

[Vincent Privat]

Indeed, I think the JOSM message of the day in September won't be exactly
polite against Oracle!

2018-04-16 20:44 GMT+02:00 Jo <winfi...@gmail.com>:

> Good news! Who needs Oracle anyway :-)
>
> Polyglot
>
> 2018-04-16 20:36 GMT+02:00 Vincent Privat <vincent.pri...@gmail.com>:
>
>> Hello,
>> I got in contact with Jiri Vanek. He might be our saviour.
>> As some of you may know, he's the one behind IcedTea-Web (ITW: the free &
>> open-source implementation of Java WebStart in the IcedTea project):
>> https://icedtea.classpath.org/wiki/IcedTea-Web
>>
>> The project is still actively developed (the 1.8 version is in progress).
>> http://icedtea.classpath.org/hg/icedtea-web/
>>
>> Last year, Jiri added support for Windows, which I validated with the
>> RedHat build.
>> Jiri's also part of the AdoptOpenJdk initiative which aimes to provide a
>> build farm of OpenJDK with certified binaries on all platforms:
>> https://adoptopenjdk.net/releases.html
>>
>> If I understood correctly, these builds are going to provide JavaFX and
>> ITW
>> once the version 1.8 is finished!
>>
>> So we have to test ITW on Windows and macOS to make sure it works with
>> Java
>> 10 and early builds of Java 11. Then we'll have to check if it still works
>> once Oracle completely removes Java WebStart (I don't know the impacts it
>> could have on ITW).
>>
>> I'm currently trying to build & test ITW on Windows.
>>
>> Cheers,
>> Vincent
>>
>> 2018-04-11 20:41 GMT+02:00 Vincent Privat <vincent.pri...@gmail.com>:
>>
>> > One month already and I still don't know what to do regarding WebStart.
>> > I found out this: https://developers.redhat.com/
>> products/openjdk/download/
>> > Red Hat is providing an implementation of OpenJDK 8 on Windows
>> containing:
>> > - OpenJDK
>> > - OpenJFX
>> > - WebStart based on IcedTea-Web
>> > - An auto-update feature (a small simple script registered to Windows
>> Task
>> > Scheduler)
>> >
>> > The good news:
>> > - This is exactly what we would need for JDK 11.
>> > - I tested it and it works perfectly. We have nothing to change in JOSM
>> to
>> > make it work with this runtime.
>> >
>> > The bad news:
>> > - It is only available to Java developers. A (free) RedHat account is
>> > required, and it is forbidden to redistribute it.
>> > - there is a version of Java 9 but it does only contain OpenJDK (thus it
>> > is useless)
>> > - there is no macOS runtime
>> >
>> > Does someone on this list has a professionnal RedHat account, or know
>> > someone there? I'd like to know if we can hope to see RedHat releasing
>> > OpenJDK 11 it as a public runtime, free or charge and not requiring a
>> user
>> > account, which would contain the same components as their OpenJDK 8
>> > version. This way we would only have to tell people to uninstall their
>> > Oracle runtime and install the Red Hat runtime instead.
>> >
>> >
>> > 2018-03-10 18:05 GMT+01:00 Vincent Privat <vincent.pri...@gmail.com>:
>> >
>> >> If we were to abandon AWT/Swing, migrating to SWT might be another
>> >> option. I don't think it would be easy, but at least it's actively
>> >> maintained: https://www.openhub.net/p/swt/contributors/summary
>> >>
>> >> 2018-03-09 10:40 GMT+01:00 Dirk Stöcker <openstreet...@dstoecker.de>:
>> >>
>> >>> On Thu, 8 Mar 2018, Richard wrote:
>> >>>
>> >>> On Thu, Mar 08, 2018 at 08:36:21AM +0100, Frederik Ramm wrote:
>> >>>>
>> >>>> You could sit down today and re-implement everything in, say, C++,
>> and
>> >>>>> it would be relatively straightforward, and while the result would
>> not
>> >>>>> share any of JOSM's codebase, it would still encapsulate all the
>> >>>>> experience and brainpower that has flown into JOSM development over
>> the
>> >>>>> years.
>> >>>>>
>> >>>>
>> >>>> true in principle but you would need a protable GUI that doesn't
>> suck or
>> >>>> you end up programming for at least 3 platforms with 3 sets of bugs,
>> >>>> 3 sets of dependencies etc.
>> >>>>
>> >>>
>> >>> Reimplementing an existing software like JOSM which has an estimated
>> >>> cos

Re: The (dark) future of Java on desktop

[Vincent Privat]

Hello,
I got in contact with Jiri Vanek. He might be our saviour.
As some of you may know, he's the one behind IcedTea-Web (ITW: the free &
open-source implementation of Java WebStart in the IcedTea project):
https://icedtea.classpath.org/wiki/IcedTea-Web

The project is still actively developed (the 1.8 version is in progress).
http://icedtea.classpath.org/hg/icedtea-web/

Last year, Jiri added support for Windows, which I validated with the
RedHat build.
Jiri's also part of the AdoptOpenJdk initiative which aimes to provide a
build farm of OpenJDK with certified binaries on all platforms:
https://adoptopenjdk.net/releases.html

If I understood correctly, these builds are going to provide JavaFX and ITW
once the version 1.8 is finished!

So we have to test ITW on Windows and macOS to make sure it works with Java
10 and early builds of Java 11. Then we'll have to check if it still works
once Oracle completely removes Java WebStart (I don't know the impacts it
could have on ITW).

I'm currently trying to build & test ITW on Windows.

Cheers,
Vincent

2018-04-11 20:41 GMT+02:00 Vincent Privat <vincent.pri...@gmail.com>:

> One month already and I still don't know what to do regarding WebStart.
> I found out this: https://developers.redhat.com/products/openjdk/download/
> Red Hat is providing an implementation of OpenJDK 8 on Windows containing:
> - OpenJDK
> - OpenJFX
> - WebStart based on IcedTea-Web
> - An auto-update feature (a small simple script registered to Windows Task
> Scheduler)
>
> The good news:
> - This is exactly what we would need for JDK 11.
> - I tested it and it works perfectly. We have nothing to change in JOSM to
> make it work with this runtime.
>
> The bad news:
> - It is only available to Java developers. A (free) RedHat account is
> required, and it is forbidden to redistribute it.
> - there is a version of Java 9 but it does only contain OpenJDK (thus it
> is useless)
> - there is no macOS runtime
>
> Does someone on this list has a professionnal RedHat account, or know
> someone there? I'd like to know if we can hope to see RedHat releasing
> OpenJDK 11 it as a public runtime, free or charge and not requiring a user
> account, which would contain the same components as their OpenJDK 8
> version. This way we would only have to tell people to uninstall their
> Oracle runtime and install the Red Hat runtime instead.
>
>
> 2018-03-10 18:05 GMT+01:00 Vincent Privat <vincent.pri...@gmail.com>:
>
>> If we were to abandon AWT/Swing, migrating to SWT might be another
>> option. I don't think it would be easy, but at least it's actively
>> maintained: https://www.openhub.net/p/swt/contributors/summary
>>
>> 2018-03-09 10:40 GMT+01:00 Dirk Stöcker <openstreet...@dstoecker.de>:
>>
>>> On Thu, 8 Mar 2018, Richard wrote:
>>>
>>> On Thu, Mar 08, 2018 at 08:36:21AM +0100, Frederik Ramm wrote:
>>>>
>>>> You could sit down today and re-implement everything in, say, C++, and
>>>>> it would be relatively straightforward, and while the result would not
>>>>> share any of JOSM's codebase, it would still encapsulate all the
>>>>> experience and brainpower that has flown into JOSM development over the
>>>>> years.
>>>>>
>>>>
>>>> true in principle but you would need a protable GUI that doesn't suck or
>>>> you end up programming for at least 3 platforms with 3 sets of bugs,
>>>> 3 sets of dependencies etc.
>>>>
>>>
>>> Reimplementing an existing software like JOSM which has an estimated
>>> cost of more than hundred development years (
>>> https://www.openhub.net/p/josm) in another language in an non-profit OS
>>> application is doomed to fail in my eyes. The motivation for a programmer
>>> to take an existing software and reimplement everything again is low. For a
>>> very long time you will not have something which is usable and inbetween
>>> you have tasks to do, but no positive feedback. That may work when the
>>> people are paid for it, but not when programmers need to be motivated. I'd
>>> consider people beeing motived by such a task very strange. :-)
>>>
>>> Rather than that if JOSM really dies some of the better ideas of it will
>>> be taken and implemented in existing or new software (which BTW is already
>>> happening, e.g. osmosis taking the Validator MapCSS or many other things).
>>>
>>> If there is a way to automatically convert the code and start with a
>>> working base, then the situation is different...
>>>
>>> But I also don't think this is necessary (ATM).
>>>
>>>
>>> Ciao
>>> --
>>> http://www.dstoecker.eu/ (PGP key available)
>>>
>>>
>>
>

Re: The (dark) future of Java on desktop

[Vincent Privat]

One month already and I still don't know what to do regarding WebStart.
I found out this: https://developers.redhat.com/products/openjdk/download/
Red Hat is providing an implementation of OpenJDK 8 on Windows containing:
- OpenJDK
- OpenJFX
- WebStart based on IcedTea-Web
- An auto-update feature (a small simple script registered to Windows Task
Scheduler)

The good news:
- This is exactly what we would need for JDK 11.
- I tested it and it works perfectly. We have nothing to change in JOSM to
make it work with this runtime.

The bad news:
- It is only available to Java developers. A (free) RedHat account is
required, and it is forbidden to redistribute it.
- there is a version of Java 9 but it does only contain OpenJDK (thus it is
useless)
- there is no macOS runtime

Does someone on this list has a professionnal RedHat account, or know
someone there? I'd like to know if we can hope to see RedHat releasing
OpenJDK 11 it as a public runtime, free or charge and not requiring a user
account, which would contain the same components as their OpenJDK 8
version. This way we would only have to tell people to uninstall their
Oracle runtime and install the Red Hat runtime instead.


2018-03-10 18:05 GMT+01:00 Vincent Privat <vincent.pri...@gmail.com>:

> If we were to abandon AWT/Swing, migrating to SWT might be another option.
> I don't think it would be easy, but at least it's actively maintained:
> https://www.openhub.net/p/swt/contributors/summary
>
> 2018-03-09 10:40 GMT+01:00 Dirk Stöcker <openstreet...@dstoecker.de>:
>
>> On Thu, 8 Mar 2018, Richard wrote:
>>
>> On Thu, Mar 08, 2018 at 08:36:21AM +0100, Frederik Ramm wrote:
>>>
>>> You could sit down today and re-implement everything in, say, C++, and
>>>> it would be relatively straightforward, and while the result would not
>>>> share any of JOSM's codebase, it would still encapsulate all the
>>>> experience and brainpower that has flown into JOSM development over the
>>>> years.
>>>>
>>>
>>> true in principle but you would need a protable GUI that doesn't suck or
>>> you end up programming for at least 3 platforms with 3 sets of bugs,
>>> 3 sets of dependencies etc.
>>>
>>
>> Reimplementing an existing software like JOSM which has an estimated cost
>> of more than hundred development years (https://www.openhub.net/p/josm)
>> in another language in an non-profit OS application is doomed to fail in my
>> eyes. The motivation for a programmer to take an existing software and
>> reimplement everything again is low. For a very long time you will not have
>> something which is usable and inbetween you have tasks to do, but no
>> positive feedback. That may work when the people are paid for it, but not
>> when programmers need to be motivated. I'd consider people beeing motived
>> by such a task very strange. :-)
>>
>> Rather than that if JOSM really dies some of the better ideas of it will
>> be taken and implemented in existing or new software (which BTW is already
>> happening, e.g. osmosis taking the Validator MapCSS or many other things).
>>
>> If there is a way to automatically convert the code and start with a
>> working base, then the situation is different...
>>
>> But I also don't think this is necessary (ATM).
>>
>>
>> Ciao
>> --
>> http://www.dstoecker.eu/ (PGP key available)
>>
>>
>

Re: Release Announcement: General Availability of JDK 10

[Vincent Privat]

Hi Rory, Dalibor,
Thank you. I thought we started something constructive between our open
source project and Oracle.
But our last bug report concerned WebStart, which is very slow with Java9+.
I spent quite a few hours investigating the issue and created I think a
nicely described bug report 3 months ago:
https://bugs.openjdk.java.net/browse/JDK-8196053
All of this for nothing: the bug has been closed as won't fix...
Vincent

2018-03-22 14:26 GMT+01:00 Rory O'Donnell :

> Hi Vincent,
>
> Let me add my thanks as well , you have been mentioned on a number of
> occasions in the Quality reports.
>
> Best regards, Rory
>
>
>
> On 22/03/2018 13:00, dalibor topic wrote:
>
>> Hi Vincent,
>>
>> thank you very much for all your hard work so far in the Quality Outreach
>> - for the bug reports, testing, feedback and all the help.
>>
>> I understand that the end of the road for Java Web Start with Java SE 11
>> is disappointing. I think the alternative that may be worth exploring would
>> be to use jlink instead, but I also completely understand that it's not
>> something you'd want to spent your time on now, in any case.
>>
>> All the best for you and the JOSM project, and thank you for all your
>> contributions. I'll ask Rory to drop JOSM from the Outreach Wiki, and stop
>> sending e-mails to the josm-dev mailing list.
>>
>> cheers,
>> dalibor topic
>>
>>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin,Ireland
>
>

Re: Unprocessed patch

[Vincent Privat]

Hi Lukas,
Sorry for this! We've got a lot of tickets and very few team members to
process them :)
I'll have a look very soon :)
Vincent

2018-03-22 7:30 GMT+01:00 Toggenburger Lukas 
:

> Dear JOSM developers
>
> At https://josm.openstreetmap.de/ticket/15711 I submitted a patch that
> highlights layers with an offset two months ago, but unfortunately I've got
> no reaction to it.
>
> Can you have a look and give me feedback?
>
> Best regards
>
> Lukas (skorbut)
>
>

Re: Release Announcement: General Availability of JDK 10

[Vincent Privat]

Hi Rory,
Thanks for the heads-up.
I am particularly unhappy about [3] and [4] as Oracle is removing on
purpose key technologies used by JOSM, without replacement nor acceptable
explanation (for WebStart).
WebStart removal will have negative impacts for our project, this is not a
good news at all.
As a consequence I won't invest any second of my benevol time anymore to
help you to improve the adoption of JDK. I'm thinking in particular about
the previous request to try to enable JDK coverage in our unit tests. As we
have no interest in this, and Oracle has no interest in maintaining the key
technologies we use, I am sure you will understand.
Regards,
Vincent

2018-03-21 11:30 GMT+01:00 Rory O'Donnell :

> Hi Vincent,
>
> A number of items to share with you today :
>
>
> *1) JDK 10 General Availability *
>
>
> JDK 10, the first release produced under the six-month rapid-cadence
> release model [1][2], is now Generally Available.
> We've identified no P1 bugs since we promoted build 46 almost two weeks
> ago, so that is the official GA release, ready for production use.
> GPL'd binaries from Oracle are available here: http://jdk.java.net/10
>
> This release includes twelve features:
>
>- 286: Local-Variable Type Inference 
>- 296: Consolidate the JDK Forest into a Single Repository
>
>- 304: Garbage-Collector Interface 
>- 307: Parallel Full GC for G1 
>- 310: Application Class-Data Sharing
>
>- 312: Thread-Local Handshakes 
>- 313: Remove the Native-Header Generation Tool (javah)
>
>- 314: Additional Unicode Language-Tag Extensions
>
>- 316: Heap Allocation on Alternative Memory Devices
>
>- 317: Experimental Java-Based JIT Compiler
>
>- 319: Root Certificates 
>- 322: Time-Based Release Versioning 
>
>
> *2) JDK 11 EA build 5, under both the GPL and Oracle EA licenses, are now
> available at **http://jdk.java.net/11 ** .*
>
>- Schedule, status & features
>- http://openjdk.java.net/projects/jdk/11/
>   - Release Notes:
>   - http://jdk.java.net/11/release-notes
>- Summary of changes
>   - https://download.java.net/java/early_access/jdk11/5/jdk-11+5.html
>
> *3) The Z Garbage Collector Project, early access builds available : *
>
>
> The first EA binary from from The Z Garbage Collector Project, also known
> as ZGC, is now available. ZGC is a scalable low latency garbage collector.
> For information on how to enable and use ZGC, please see the project wiki.
>
>- Project page: http://openjdk.java.net/projects/zgc/
>- Wiki: https://wiki.openjdk.java.net/display/zgc/Main
>
>
>
>
>
> *4) Quality Outreach Report for **March 2018 *
> *is available *
>
>- https://wiki.openjdk.java.net/display/quality/Quality+
>Outreach+report+March+2018
>
> * 5) *
> *Java Client Roadmap Update *
>
>- We posted a blog [3] and related white paper [4] detailing our plans
>for the Java Client.
>
>
>
> Rgds,Rory
> [1] https://mreinhold.org/blog/forward-faster
> [2] http://mail.openjdk.java.net/pipermail/discuss/2017-
> September/004281.html
> [3] Blog: https://blogs.oracle.com/java-platform-group/the-future-of-
> javafx-and-other-java-client-roadmap-updates
> [4] Whitepaper: http://www.oracle.com/technetwork/java/javase/
> javaclientroadmapupdate2018mar-4414431.pdf
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
>

Re: JOSM Memory usage with large files

[Vincent Privat]

Hello,
Can you please launch josm with "java -jar -Xmx4096M
-XX:+HeapDumpOnOutOfMemoryError josm-tested.jar" command line and share the
(compressed) resulting heap dump somewhere?
See
https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/clopts001.html
for details.
Cheers,
Vincent

2018-03-21 18:17 GMT+01:00 Mike N :

> Hi, we're working on an import (long announced and documented) of
> buildings in the area - I'm working with Windows with no problem -Xmx4096M
> , and Ubuntu with no problem.   Another mapper helping with the import is
> experiencing a problem in which the JOSM / java grabs a huge amount of
> memory such as 11-15G of RAM when editing or uploading a file consisting of
> 10K - 15K nodes / 3K buildings which brings the computer to a standstill
> since the computer only has 8G of RAM.
>
>   What kinds of things could cause this problem, and what are some tips
> that might point us in the right direction?
>
>   Thanks, system info follows.
> -
>  System configuration:
>
> 8G physical RAM
> JOSM 13500
>
> Only Mapillary plugin
>
> Java 1.8.0_151
> OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.1
> 7.10.2-b12)
> OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
>
> Distro: POP OS https://system76.com/pop
>
>

Re: The (dark) future of Java on desktop

[Vincent Privat]

If we were to abandon AWT/Swing, migrating to SWT might be another option.
I don't think it would be easy, but at least it's actively maintained:
https://www.openhub.net/p/swt/contributors/summary

2018-03-09 10:40 GMT+01:00 Dirk Stöcker :

> On Thu, 8 Mar 2018, Richard wrote:
>
> On Thu, Mar 08, 2018 at 08:36:21AM +0100, Frederik Ramm wrote:
>>
>> You could sit down today and re-implement everything in, say, C++, and
>>> it would be relatively straightforward, and while the result would not
>>> share any of JOSM's codebase, it would still encapsulate all the
>>> experience and brainpower that has flown into JOSM development over the
>>> years.
>>>
>>
>> true in principle but you would need a protable GUI that doesn't suck or
>> you end up programming for at least 3 platforms with 3 sets of bugs,
>> 3 sets of dependencies etc.
>>
>
> Reimplementing an existing software like JOSM which has an estimated cost
> of more than hundred development years (https://www.openhub.net/p/josm)
> in another language in an non-profit OS application is doomed to fail in my
> eyes. The motivation for a programmer to take an existing software and
> reimplement everything again is low. For a very long time you will not have
> something which is usable and inbetween you have tasks to do, but no
> positive feedback. That may work when the people are paid for it, but not
> when programmers need to be motivated. I'd consider people beeing motived
> by such a task very strange. :-)
>
> Rather than that if JOSM really dies some of the better ideas of it will
> be taken and implemented in existing or new software (which BTW is already
> happening, e.g. osmosis taking the Validator MapCSS or many other things).
>
> If there is a way to automatically convert the code and start with a
> working base, then the situation is different...
>
> But I also don't think this is necessary (ATM).
>
>
> Ciao
> --
> http://www.dstoecker.eu/ (PGP key available)
>
>

Re: The (dark) future of Java on desktop

[Vincent Privat]

WebStart is going away. It is the only part of Java that isn't open source
and they explicitely stated they won't open source it:
https://twitter.com/DonaldOJDK/status/971492781616136194

So at least starting from September we'll have to make the WebStart link
less prominent as it won't work anymore for Windows and macOS users having
their Java up-to-date. It will work natively only on Linux, where openjdk
package includes the retro-engineered free version of WebStart
(netx/icedtea-web):
https://icedtea.classpath.org/wiki/IcedTea-Web

I don't know if the few (single?) people behind IcedTea-Web will have the
desire to maintain it after Oracle drops it from JDK. I don't know either
if icedtea-web requires jar signing: maybe we will be able to drop the
requirement to sign josm.jar, thus asking to Frederik to pay for the
certificates ;)

JavaFX will be given to someone else soon. Maybe the Eclipse Foundation,
like Java EE which has be transferred to Eclipse, without the permission to
call it Java EE anymore. Or maybe the Apache Foundation, where they already
made OpenOffice and Hudson die there (given that they have been
successfully forked as LibreOffice and Jenkins).

AWT and Swing will still be here in Java 11. But the fact they mention it
explicitely today probably means they have plans to remove it as soon as
Java 12 development starts (in 6 months). I have no idea if the new project
will create enough traction to have enough contributors (volunteers or pais
staff from other companies), we'll see. Swing is still used a lot in the
industry. At least we should be able to fix Swing bugs ourselves when we
find ones.

Concerning JOSM it means we will probably have to ship AWT, Swing and
JavaFX in josm.jar. In JDK9 the desktop module (AWT+Swing) weights 13Mb,
the various JavaFX modules 30Mb. JOSM jar is only 12Mb today.

Cheers,
Vincent

2018-03-08 11:19 GMT+01:00 Dirk Stöcker :

> On Thu, 8 Mar 2018, Dirk Stöcker wrote:
>
> [nothing]
>
> Sorry, operator error :-)
>
>
> Ciao
> --
> http://www.dstoecker.eu/ (PGP key available)
>

The (dark) future of Java on desktop

[Vincent Privat]

Oracle issued this sad, frustrating and almost depressing statement today:

https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates
http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf

Forget the "yay this is an exciting moment" of the blog post and read the
details in the white paper: basically it seems all client technologies
(WebStart, AWT, Swing, JavaFX...) are going to die sooner or later.

I'm not sure what it implies for the long-term development of JOSM, but
nothing good I fear.

Vincent

Re: i18n - mapcss external rules

[Vincent Privat]

The i18n scripts are located in
https://svn.openstreetmap.org/applications/editors/josm/i18n/
Cheers,
Vincent

2018-03-03 17:35 GMT+01:00 Frédéric Rodrigo :

> Le 27/02/2018 à 08:38, Dirk Stöcker a écrit :
>
>> On Mon, 26 Feb 2018, Noémie Lehuby wrote:
>>
>> I've written some mapcss external validators for JOSM. They are hosted in
>>> Github and listed in the dedicated wiki page.
>>>
>>> They are in French, and I would like to make them available in the
>>> language of the user.
>>>
>>> I've set the baselanguage property in the metadata and also tried to add
>>> the tr() function. But I can't find my rules in Launchpad.
>>>
>>> Is there something I'm missing ?
>>>
>>
>> Yes.
>>
>> a) External validators will not automatically be translated in JOSM. You
>> need to setup your own translation infrastructure.
>> b) You need to convert the translated data to ".lang" files (scripts for
>> this are in i18n directory of OSM-JOSM-SVN) and attach these in a directory
>> "data" inside the zip file download
>>
>
> Please, can you explicit this point. I not able to found the script.
> Thank.
> Frédéric.
>
>
>

Re: Windows Defender causing JOSM problems

[Vincent Privat]

Toby, are you still able to reproduce? My Windows Defender has been updated
today and I cannot reproduce, even when downloading JOSM from IE or Edge.
A manual scan doesn't report any warning neither.

2018-02-21 17:34 GMT+01:00 Toby Murray :

> JOSM plugins are not a factor here. Windows is scanning and flagging
> the josm-latest.jar file as soon as a browser downloads it. I don't
> remember exactly which class files it is flagging. One was an inner
> class dealing with XML parsing. Given that the IntelliJ problem seems
> to be with a regex related class, I wonder if there is a certain regex
> string that is triggering it. I'm all Linux at work so I'll have to
> check at home tonight to see if there is something simple in common
> between the JOSM classes and the IntelliJ problem.
>
> Toby
>
> On Wed, Feb 21, 2018 at 5:52 AM, Florian von der Schäferbande 
>  wrote:
> > Here are some other instances where this issue occurs:
> >
> > https://intellij-support.jetbrains.com/hc/en-us/
> community/posts/36091624-Trojan-Skeeyah-H
> > https://youtrack.jetbrains.com/issue/IDEA-186808
> > https://answers.launchpad.net/sikuli/+question/664458
> >
> > Maybe that could help with finding the cause. There are some mentions of
> scripting in these links. Do you by chance have the scripting plugin
> installed?
> >
> > Am 21. Februar 2018 12:38:21 MEZ schrieb Mike N :
> >>On 2/21/2018 3:46 AM, Toby Murray wrote:
> >>> Windows Defender has apparently taken offense to JOSM in the latest
> >>> malware signature update. Starting on February 19th mine started
> >>> claiming to detect a trojan named Skeeyah.H in 3 different class
> >>files
> >>> inside of the JOSM JAR. Defender helpfully removed these class files
> >>> from the JAR. JOSM is not amused by this and crashes on launch with a
> >>> NoClassDefFoundError.
> >>
> >> What version of JOSM was this?   I haven't seen this yet with Windows
> >>Defender and JOSM 13367.
> >
> > --
> > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>
>

Re: Windows Defender causing JOSM problems

[Vincent Privat]

Ok now I understand those strange bug reports on Windows... thanks for the
insights I'll see what we can do.

Le 21 févr. 2018 12:53 PM, "Florian von der Schäferbande " <
flor...@schaeferban.de> a écrit :

> Here are some other instances where this issue occurs:
>
> https://intellij-support.jetbrains.com/hc/en-us/
> community/posts/36091624-Trojan-Skeeyah-H
> https://youtrack.jetbrains.com/issue/IDEA-186808
> https://answers.launchpad.net/sikuli/+question/664458
>
> Maybe that could help with finding the cause. There are some mentions of
> scripting in these links. Do you by chance have the scripting plugin
> installed?
>
> Am 21. Februar 2018 12:38:21 MEZ schrieb Mike N :
> >On 2/21/2018 3:46 AM, Toby Murray wrote:
> >> Windows Defender has apparently taken offense to JOSM in the latest
> >> malware signature update. Starting on February 19th mine started
> >> claiming to detect a trojan named Skeeyah.H in 3 different class
> >files
> >> inside of the JOSM JAR. Defender helpfully removed these class files
> >> from the JAR. JOSM is not amused by this and crashes on launch with a
> >> NoClassDefFoundError.
> >
> > What version of JOSM was this?   I haven't seen this yet with Windows
> >Defender and JOSM 13367.
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>

Re: Thanks to our server sponsor Hetzner and all the JOSM contributors

[Vincent Privat]

While we are thanking people, I'd like to thank you, Frederik and FOSSGIS
for the certificate sponsorship allowing us to sign JOSM jar so that it is
accepted by Oracle.
This is the kind of administrative stuff invisible and unknown for almost
everyone, but crucial to make JOSM easily available and up to date on all
platforms.
Cheers,
Vincent

2018-02-05 18:54 GMT+01:00 Charlotte Wolter :

> Dirk,
>
> Do you keep a calendar, so you can remember to contact
> Hetzner regularly, and not just when the sponsorship is ending? It
> seems to me that anyone who gives such a valuable service should
> get regular contact, if only to say "Thanks."
>
> Charlotte
>
>
>
> At 07:13 AM 2/5/2018, you wrote:
>
>> Hello,
>>
>> each year at the beginning of February our server sponsoring has to be
>> renewed. End of last year I remembered I have to do it, but now I simply
>> forgot to contact our Sponsor (www.hetzner.de). Well, they contacted me
>> and asked if we still want. Hey, I really like these guys! Last year they
>> invited me to a celebration at their server center and it was very
>> interesting to see what they do to keep servers online all the time. Thanks
>> a lot.
>>
>> Also lots of thanks to all the JOSM contributors in the last year. If you
>> follow the timeline of JOSM there are each day dozens or hundreds of
>> entries (new tickets, wiki changes, source code changes, ...). And usually
>> differing opinions between contributors are resolved without conflicts
>> (which is not naturally the case in such projects).
>>
>> I'm glad that JOSM is such an active and living project!
>>
>> Ciao
>> --
>> http://www.dstoecker.eu/ (PGP key available)
>>
>
> Charlotte Wolter
> 927 18th Street Suite A
> Santa Monica, California
> 90403
> +1-310-597-4040
> Mobile: 310-663-3699
> techl...@techlady.com
> Skype: thetechlady
>
>

Re: MapCSS validation for Osmose

[Vincent Privat]

Hi Frédéric,
Thanks and congrats, this is an awesome news! :)
I'm really excited about the possibility of having a united MapCSS
validator database shared between Osmose and JOSM.
Concerning your issues:
- level mapping: I see no problem to add osmose-specific declarations in
our mapCSS definitions
- translations: Yes currently all translations are hosted on Launchpad. To
get them you can take a look at
https://svn.openstreetmap.org/applications/editors/josm/i18n/launchpad.pl .
The bazaar repository URL is lp:~openstreetmap/josm/josm_trans
- inside tags missing in country-specific rules: I will create a ticket to
naoliv for the Brazilian rules
- validation issue with de_openrailwaymap: maybe you can create a ticket on
their Github to see if the check is correct/needed

I need to find the time to play with these new Osmose issues, I'll let you
know.
Cheers,
Vincent


2018-01-28 20:07 GMT+01:00 Frédéric Rodrigo :

> Hi,
>
> I passed the three last months to add support of mapcss validation into
> Osmose.
>
> I rewrite an antlr4 grammar for the mapccs and produce a python parser.
> Then I use the parser to generate python code for selectors, declarations
> and mapcss functions. The result is some kind of "compilation" of mapcss in
> python. The generated code use one of the Osmose checking framework to do
> the Job.
>
> Osmose have many validator engines. The simplest only check tags of one
> object at once (no geometries involved nor object relations). I only
> generate code for rules able to be lunched on this engine (it's possible to
> support the others, but to do).
>
> The result of running the official JOSM and contrib rules for the whole
> world is now available on Osmose, from at least a week. We refresh the
> result every two days. (Technically the whole world is not yet computed,
> but it's a matter of finishing to update all the Osmose backends around the
> world).
>
>
> So, show me the data!
>
> http://osmose.openstreetmap.fr/en/errors/?limit=0=9xxx;
> useDevItem=true
>
> http://osmose.openstreetmap.fr/en/map/#item=9xxx=
> true=12=49.4805=6.3461=1 (play with the severity
> selector if nothing displayed)
>
> This page take a while to load, you can sort on column by clicking on the
> header (and wait).
>
> All this content is on Osmose but not yet publicly displayed.
>
>
> All this checks have generated so far 20.1 millions of issues. I excluded
> one rule of official JOSM validator because just this rule raise 4 millions
> of issues ("Unnamed unclassified highway").
>
> The goal of supporting mapcss in Osmose is to try to state a common format
> for data validation. The next step is to move a part of Osmose validation
> to mapcss and make them available into JOSM as contrib.
>
>
> During doing all this stuff we encountered some problems.
>
> - Osmose issue level VS JOSM throw level: Osmose report only issues where
> there is a high probability of something go wrong, with level mean the
> impact on data usability. But JOSM have an orthogonal level with Error,
> Warning, Other. For now, I simply map throwError to Osmose level1 and so on.
>
> - Translation. Because we use official MapCSS, we also reuse translation
> too. The only way to get it is via bzr ?
>
> - Harmonisation of throw level in contrib: contrib mapcss validator have a
> very different use of throw level and sometime the inside() selector is
> missing. Not yet done, but I plan to blacklist in Osmose lot of rules from
> "Brazilian-Specific" and lower some other ("transport"). I added the
> ability in Osmose to limit a mapccs validator file to a country, whatever
> the inside() selector are used or not.
>
> - I generate the selectors and the declarations in python but also I
> generate the tests. And I'm able to run all the included tests. Except one
> from the contrib de_openrailwaymap, in short the test try to validate that
> "5" != "05". As the content are numbers, my implementation check 5 != 5,
> and it fails.
>
>
> About port of Osmose hand writen python rules to Mapcss, we should add
> some extension into mappcss declarations (like "osmose-level" or
> "osmose-item"). And I plan to add this kind of declaration into some
> existing mapcss validation rule files to avoid duplicating the report to
> user, one from JOSM ruleset, one from Osmose ruleset.
>
>
> The grammar and the mapcss2osmose code: https://github.com/osm-fr/osmo
> se-backend/tree/master/mapcss
>
> The Osmose analysers produced from mapcss code (all MapCss* files):
> https://github.com/osm-fr/osmose-backend/tree/master/plugins
>
> I'm widely open to comment.
>
> Reagrds.
>
> Frédéric.
>
>
>
>

Re: I18n of JOSM plugins (with Gradle build) via Transifex

[Vincent Privat]

The SVN external allows us to detect compilation failure with Jenkins, it's
very useful!

2018-01-17 13:40 GMT+01:00 Florian Schäfer <flor...@schaeferban.de>:

> That would be another option. I'd be ok with either of these.
>
> Let's continue the discussion in the ticket https://josm.openstreetmap.
> de/ticket/8645 . I prepared a patch that would ignore plugins with a
> `.tx/config` file.
>
> Florian
>
>  Weitergeleitete Nachricht 
> Von: Dirk Stöcker <openstreet...@dstoecker.de>
> Reply-to: josm-dev@openstreetmap.org
> An: josm-dev@openstreetmap.org
> Betreff: Re: I18n of JOSM plugins (with Gradle build) via Transifex
> Datum: Wed, 17 Jan 2018 09:23:46 +0100 (CET)
>
> On Tue, 16 Jan 2018, Vincent Privat wrote:
>
> > We should definitively avoid to push translations to Launchpad now,
> > for
> > plugins having a ".tx" folder.
>
> Simply remove the "svn:external" in the SVN.
>
> Ciao
>

Re: I18n of JOSM plugins (with Gradle build) via Transifex

[Vincent Privat]

Hello,
I's OK to stay in the JOSM organization. We already have a GitHub
organization for JOSM, and I still hope someone will carry the effort of
migrating JOSM core translations from Launchpad to Transifex.
Concerning geojson, no one is maintaining it. As you did all the recent
commits, I consider you as the current maintainer ;)
So if you want to migrate this one as well to Transifex, go ahead and
create a PR, I'll merge it.

We should definitively avoid to push translations to Launchpad now, for
plugins having a ".tx" folder.
Cheers,
Vincent


2018-01-16 15:35 GMT+01:00 Florian Schäfer :

> Go ahead! At least plugins with currently no translations on Launchpad
> could then use that project (e.g. the `scripting` plugin).
>
> For the Mapillary project, it probably needs some discussion if the
> translated strings from Launchpad could be imported to Transifex.
> Asking every single translator for permission to change the license
> sounds pretty complicated to me, but I also  hesitate to restart from
> scratch and discard the previous work.
>
> Florian
>
>
>
>  Weitergeleitete Nachricht 
> Von: Simon Poole 
> An: josm-dev@openstreetmap.org
> Betreff: Re: I18n of JOSM plugins (with Gradle build) via Transifex
> Datum: Tue, 16 Jan 2018 15:11:35 +0100
>
> Well we would only want translations that are essentially rights free,
> this is not a philosophical question, just a practical matter, as the
> real benefit (outside of exposure to a larger group of translators) is
> access to large amount of pre-translated expressions.
>
> But if that is OK, I can make you a maintainer (note there is a
> downside
> that you have to re-invite any already existing translators).
>
> Simon
>

Re: Availability of JOSM reported bug fixes in JDK10

[Vincent Privat]

Hello Muneer,
I confirm the first problem is fixed, thank you!
For the second one I cannot confirm as I was unable to reproduce it myself.
Cheers,
Vincent


Le 15 janv. 2018 07:34, "Muneer Kolarkunnu"  a
écrit :

Hi Vincent,



JOSM reported below Java bugs are resolved and fix is included in JDK10.



https://bugs.openjdk.java.net/browse/JDK-8191078 : Wrong "Package not
found" warning

https://bugs.openjdk.java.net/browse/JDK-8172244 : AIOOBE in
KeyStore.getCertificateAlias on Windows



JDK 10 EA build is available at http://jdk.java.net/10/

Can you please confirm the fixes.



Regards,

Muneer

Quality Engineer

Oracle, Bangalore, India

Re: Plugins: deprecated API to be removed

[Vincent Privat]

Hi Jo,
This should work:

from org.openstreetmap.josm.gui import MainApplication

editLayer = MainApplication.getLayerManager().getEditLayer()
if editLayer and editLayer.data:
selectedElements = editLayer.data.getSelected()

If you don't need editLayer you could simplify it to:

editData = MainApplication.getLayerManager().getEditDataSet()
if editData:
selectedElements = editData.getSelected()

Cheers,
Vincent

2017-12-02 11:00 GMT+01:00 Jo <winfi...@gmail.com>:

> Hi Vincent,
>
> Thank you for cleaning up the source code. Of course I run into a problem
> when using the scripting plugin.
>
> How can I get all the selected elements?
>
> This is what worked untill a few days ago:
>
> from org.openstreetmap.josm import Main
>
> editLayer = Main.getLayerManager().getEditLayer()
> if editLayer and editLayer.data:
> selectedElements = editLayer.data.getSelected()
>
> I tried a few incantations, but no luck.
>
> Cheers,
>
> Polyglot
>
>
> 2017-11-28 1:07 GMT+01:00 Vincent Privat <vincent.pri...@gmail.com>:
>
>> First batch of deprecated APIs removed:
>> https://josm.openstreetmap.de/changeset/13173/josm
>> Cheers,
>> Vincent
>>
>> 2017-11-26 16:42 GMT+01:00 Vincent Privat <vincent.pri...@gmail.com>:
>>
>> > Hello,
>> > JOSM 13170 has been released. This is the last stable version before we
>> > remove a lot of deprecated APIs.
>> > Make sure your plugins compile without deprecation warning!
>> > Vincent
>> >
>> > 2017-10-30 21:20 GMT+01:00 Vincent Privat <vincent.pri...@gmail.com>:
>> >
>> >> Hi Holger,
>> >> Sorry for not responding earlier, but I have already updated a lot of
>> >> plugins, see https://github.com/openstreetm
>> ap/josm-plugins/commits/master
>> >> Still some work to do (around 1100 deprecation warnings)
>> >> Cheers,
>> >> Vincent
>> >>
>> >> 2017-10-30 21:16 GMT+01:00 Holger Mappt <holger...@gmx.net>:
>> >>
>> >>> On 2017-10-23 at 00:15 +0200 Paul Hartmann wrote:
>> >>>
>> >>>> On 21.10.2017 17:49, Holger Mappt wrote:
>> >>>>
>> >>>>> Is the sonar the right place to see what is deprecated, i.e. what
>> >>>>> needs to be changed? [1]
>> >>>>> [1] https://josm.openstreetmap.de/sonar/project/issues?id=josm-p
>> >>>>> lugins=false=squid%3ACallToDeprecatedMethod
>> >>>>>
>> >>>>
>> >>>> Possible, but the normal way would be to have the java compiler
>> output
>> >>>> deprecation warnings (use compiler option -Xlint:deprecation for
>> javac to
>> >>>> see details).
>> >>>>
>> >>>
>> >>> The trick is to call "ant clean" before "ant", otherwise the
>> deprecation
>> >>> messages are not shown. Option -Xlint:deprecation is on by default if
>> >>> ../build-common.xml is imported from build.xml.
>> >>>
>> >>> Thanks,
>> >>> Holger
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >
>>
>
>

Re: Plugins: deprecated API to be removed

[Vincent Privat]

First batch of deprecated APIs removed:
https://josm.openstreetmap.de/changeset/13173/josm
Cheers,
Vincent

2017-11-26 16:42 GMT+01:00 Vincent Privat <vincent.pri...@gmail.com>:

> Hello,
> JOSM 13170 has been released. This is the last stable version before we
> remove a lot of deprecated APIs.
> Make sure your plugins compile without deprecation warning!
> Vincent
>
> 2017-10-30 21:20 GMT+01:00 Vincent Privat <vincent.pri...@gmail.com>:
>
>> Hi Holger,
>> Sorry for not responding earlier, but I have already updated a lot of
>> plugins, see https://github.com/openstreetmap/josm-plugins/commits/master
>> Still some work to do (around 1100 deprecation warnings)
>> Cheers,
>> Vincent
>>
>> 2017-10-30 21:16 GMT+01:00 Holger Mappt <holger...@gmx.net>:
>>
>>> On 2017-10-23 at 00:15 +0200 Paul Hartmann wrote:
>>>
>>>> On 21.10.2017 17:49, Holger Mappt wrote:
>>>>
>>>>> Is the sonar the right place to see what is deprecated, i.e. what
>>>>> needs to be changed? [1]
>>>>> [1] https://josm.openstreetmap.de/sonar/project/issues?id=josm-p
>>>>> lugins=false=squid%3ACallToDeprecatedMethod
>>>>>
>>>>
>>>> Possible, but the normal way would be to have the java compiler output
>>>> deprecation warnings (use compiler option -Xlint:deprecation for javac to
>>>> see details).
>>>>
>>>
>>> The trick is to call "ant clean" before "ant", otherwise the deprecation
>>> messages are not shown. Option -Xlint:deprecation is on by default if
>>> ../build-common.xml is imported from build.xml.
>>>
>>> Thanks,
>>> Holger
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

Re: Plugins: deprecated API to be removed

[Vincent Privat]

Hello,
JOSM 13170 has been released. This is the last stable version before we
remove a lot of deprecated APIs.
Make sure your plugins compile without deprecation warning!
Vincent

2017-10-30 21:20 GMT+01:00 Vincent Privat <vincent.pri...@gmail.com>:

> Hi Holger,
> Sorry for not responding earlier, but I have already updated a lot of
> plugins, see https://github.com/openstreetmap/josm-plugins/commits/master
> Still some work to do (around 1100 deprecation warnings)
> Cheers,
> Vincent
>
> 2017-10-30 21:16 GMT+01:00 Holger Mappt <holger...@gmx.net>:
>
>> On 2017-10-23 at 00:15 +0200 Paul Hartmann wrote:
>>
>>> On 21.10.2017 17:49, Holger Mappt wrote:
>>>
>>>> Is the sonar the right place to see what is deprecated, i.e. what needs
>>>> to be changed? [1]
>>>> [1] https://josm.openstreetmap.de/sonar/project/issues?id=josm-p
>>>> lugins=false=squid%3ACallToDeprecatedMethod
>>>>
>>>
>>> Possible, but the normal way would be to have the java compiler output
>>> deprecation warnings (use compiler option -Xlint:deprecation for javac to
>>> see details).
>>>
>>
>> The trick is to call "ant clean" before "ant", otherwise the deprecation
>> messages are not shown. Option -Xlint:deprecation is on by default if
>> ../build-common.xml is imported from build.xml.
>>
>> Thanks,
>> Holger
>>
>>
>>
>>
>>
>>
>>
>

Re: JOSM and .kml polyline colour editing

[Vincent Privat]

Nope, the plugin loads it as an OSM data layer. But it can be converted to
a GPX layer then.

2017-11-20 15:34 GMT+01:00 Dirk Stöcker <openstreet...@dstoecker.de>:

> On Mon, 20 Nov 2017, Vincent Privat wrote:
>
> The color/colour tag is not natively used to colorize ways.
>> You could write your own map paint style to do so, see
>> https://josm.openstreetmap.de/wiki/Styles#CreateStyle
>>
>
> Isn't KML loaded alike to GPX? In this case he simply needs to right click
> the layer and select a color.
>
> Ciao
> --
> http://www.dstoecker.eu/ (PGP key available)
>
>

Re: JOSM and .kml polyline colour editing

[Vincent Privat]

Hi,
The color/colour tag is not natively used to colorize ways.
You could write your own map paint style to do so, see
https://josm.openstreetmap.de/wiki/Styles#CreateStyle
Cheers,
Vincent

2017-11-20 13:55 GMT+01:00 Bob Hawkins :

> I copy here a post from OpenStreetMap Forum>Editors, to which I have
> received no answer:
> I have found the presence of Public Rights of Way .kml files in JOSM to be
> very useful for comparative purposes.  One drawback is that they appear as
> grey polylines.  I cannot see a facility to change colour, and wonder if
> anyone knows differently?  A colour key is present with a hexadecimal value
> as an attribute, but changing that has no effect.
> NOTE: I have changed the colour codes in Notepad to no effect, either.
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>

Re: Client side testing

[Vincent Privat]

If someone's paid at Oracle to work on Jenkins plugins, this bug is a good
candidate :)
(given the Hudson/Jenkins history I don't think so, but well, sometimes we
have good surprises, as I can see Jenkins is used to power
https://ci.adoptopenjdk.net/)

2017-11-07 22:18 GMT+01:00 Alexandre (Shura) Iline <
alexandre.il...@oracle.com>:

> The issue is pretty generic and also pretty old. :(
>
> Thank you anyway.
>
> Let me know if there is anything we could help with on our side.
>
> Shuta
>
>
>
> On Nov 7, 2017, at 1:11 PM, Vincent Privat <vincent.pri...@gmail.com>
> wrote:
>
> OK I tried to setup the JDK coverage, and this is NOT easy.
> Right now I'm blocked by a bug in the Jenkins Jacoco plugin:
> https://issues.jenkins-ci.org/browse/JENKINS-36168
> Need to solve it first.
> If I find how to setup JDK coverage for an Ant project, it will deserve
> serious documentation. I will probably update JOSM wiki, but maybe it could
> land somewhere on https://wiki.openjdk.java.net/display/quality/Quality+
> Outreach for other projects?
>
> 2017-11-06 23:51 GMT+01:00 Alexandre (Shura) Iline <
> alexandre.il...@oracle.com>:
>
>>
>> On Nov 6, 2017, at 2:48 PM, Vincent Privat <vincent.pri...@gmail.com>
>> wrote:
>>
>> Sure! Currently coverage is restricted to JOSM classes, for obvious
>> performance reasons, as we run a full build after each commit.
>> But I can add a parameter to change the monitored packages in our EA
>> builds.
>> Is it OK if I add java, javax, sun and com.sun ? Or do you prefer to
>> restrict only to packages from java.desktop module?
>>
>>
>> Thank you!
>>
>> Frankly, java.desktop is what I am more interested myself right now.
>>
>> java, javax, sun and com.sun would also cover what I am asking for, of
>> course.
>>
>> Shura
>>
>>
>>
>>
>> 2017-11-06 19:31 GMT+01:00 Alexandre (Shura) Iline <
>> alexandre.il...@oracle.com>:
>>
>>> This is great that you are touching the new builds, thank you, Vincent.
>>>
>>> I am not familiar with JOSM code, but the app is great! I have played
>>> with it in the past.
>>>
>>> Do you think it would be possible, in addition to what you are doing, to
>>> collect code coverage for the  JDK code? Specifically for the now existing
>>> java.desktop module. I do not know much of JaCoCo - we are using JCov, as
>>> you can imagine - so I do not know how easy it is. If it is easy, can you
>>> flip the switch?
>>>
>>> Shura
>>> > On Nov 3, 2017, at 8:33 AM, Vincent Privat <vincent.pri...@gmail.com>
>>> wrote:
>>> >
>>> > Hello Rory,
>>> > Thank you :)
>>> >
>>> > Here is how we test various OpenJDK builds:
>>> > 1.1: we use only EA builds from http://jdk.java.net/
>>> > 2.1.1: no
>>> > 2.1.2/2.1.3: we run all unit and integration tests of JOSM
>>> > 2.1.4: yes, using jacoco
>>> > 2.2: all tests are automated
>>> > 2.3: it depends. During OpenJDK9 cycle we did not run a test series
>>> for each weekly build, but rather once every two or three builds, unless we
>>> were waiting for a specific correction from OpenJDK or another tool. At the
>>> end of development, we were not waiting for any correction from OpenJDK but
>>> were eagerly waiting for the updates of ASM and everything that as blocked
>>> by the non-availability of ASM (in particular various Maven plugins)
>>> > 2.4: Yes, they are visible here:
>>> > - JOSM core: https://josm.openstreetmap.de/
>>> jenkins/job/Java-EarlyAccess-JOSM/
>>> > - JOSM community plugins: https://josm.openstreetmap.de/
>>> jenkins/job/Java-EarlyAccess-JOSM-Plugins/
>>> >
>>> > I just have initiated JDK10 tests today, and we have 53 failures
>>> caused by Byte Buddy not recognizing Java version 10:
>>> >
>>> > java.lang.IllegalArgumentException: Unknown Java version: 10
>>> >   at nl.jqno.equalsverifier.internal.lib.bytebuddy.ClassFileVersi
>>> on.ofJavaVersion(ClassFileVersion.java:135)
>>> >
>>> >
>>> > I'm sure Rafael is aware of it. I will see how to update our tools
>>> (equalsverifier here).
>>> >
>>> > Cheers,
>>> > Vincent
>>> >
>>> > 2017-11-03 14:05 GMT+01:00 Rory O'Donnell <rory.odonn...@oracle.com>:
>>> >
>>> > Hi Vincent,
>>> >
>>> > I noticed tha

Re: Client side testing

[Vincent Privat]

OK I tried to setup the JDK coverage, and this is NOT easy.
Right now I'm blocked by a bug in the Jenkins Jacoco plugin:
https://issues.jenkins-ci.org/browse/JENKINS-36168
Need to solve it first.
If I find how to setup JDK coverage for an Ant project, it will deserve
serious documentation. I will probably update JOSM wiki, but maybe it could
land somewhere on
https://wiki.openjdk.java.net/display/quality/Quality+Outreach for other
projects?

2017-11-06 23:51 GMT+01:00 Alexandre (Shura) Iline <
alexandre.il...@oracle.com>:

>
> On Nov 6, 2017, at 2:48 PM, Vincent Privat <vincent.pri...@gmail.com>
> wrote:
>
> Sure! Currently coverage is restricted to JOSM classes, for obvious
> performance reasons, as we run a full build after each commit.
> But I can add a parameter to change the monitored packages in our EA
> builds.
> Is it OK if I add java, javax, sun and com.sun ? Or do you prefer to
> restrict only to packages from java.desktop module?
>
>
> Thank you!
>
> Frankly, java.desktop is what I am more interested myself right now.
>
> java, javax, sun and com.sun would also cover what I am asking for, of
> course.
>
> Shura
>
>
>
>
> 2017-11-06 19:31 GMT+01:00 Alexandre (Shura) Iline <
> alexandre.il...@oracle.com>:
>
>> This is great that you are touching the new builds, thank you, Vincent.
>>
>> I am not familiar with JOSM code, but the app is great! I have played
>> with it in the past.
>>
>> Do you think it would be possible, in addition to what you are doing, to
>> collect code coverage for the  JDK code? Specifically for the now existing
>> java.desktop module. I do not know much of JaCoCo - we are using JCov, as
>> you can imagine - so I do not know how easy it is. If it is easy, can you
>> flip the switch?
>>
>> Shura
>> > On Nov 3, 2017, at 8:33 AM, Vincent Privat <vincent.pri...@gmail.com>
>> wrote:
>> >
>> > Hello Rory,
>> > Thank you :)
>> >
>> > Here is how we test various OpenJDK builds:
>> > 1.1: we use only EA builds from http://jdk.java.net/
>> > 2.1.1: no
>> > 2.1.2/2.1.3: we run all unit and integration tests of JOSM
>> > 2.1.4: yes, using jacoco
>> > 2.2: all tests are automated
>> > 2.3: it depends. During OpenJDK9 cycle we did not run a test series for
>> each weekly build, but rather once every two or three builds, unless we
>> were waiting for a specific correction from OpenJDK or another tool. At the
>> end of development, we were not waiting for any correction from OpenJDK but
>> were eagerly waiting for the updates of ASM and everything that as blocked
>> by the non-availability of ASM (in particular various Maven plugins)
>> > 2.4: Yes, they are visible here:
>> > - JOSM core: https://josm.openstreetmap.de/
>> jenkins/job/Java-EarlyAccess-JOSM/
>> > - JOSM community plugins: https://josm.openstreetmap.de/
>> jenkins/job/Java-EarlyAccess-JOSM-Plugins/
>> >
>> > I just have initiated JDK10 tests today, and we have 53 failures caused
>> by Byte Buddy not recognizing Java version 10:
>> >
>> > java.lang.IllegalArgumentException: Unknown Java version: 10
>> >   at nl.jqno.equalsverifier.internal.lib.bytebuddy.ClassFileVersi
>> on.ofJavaVersion(ClassFileVersion.java:135)
>> >
>> >
>> > I'm sure Rafael is aware of it. I will see how to update our tools
>> (equalsverifier here).
>> >
>> > Cheers,
>> > Vincent
>> >
>> > 2017-11-03 14:05 GMT+01:00 Rory O'Donnell <rory.odonn...@oracle.com>:
>> >
>> > Hi Vincent,
>> >
>> > I noticed that JOSM have been commended in the last two Quality reports
>> [1] [2] for the number and
>> > indeed the quality of bugs you have found and logged against various
>> early access releases.
>> > Thanks again for your contribution to the quality of our releases!
>> >
>> > The big question is how do you do it ?
>> >
>> > We would love to hear more details about your test environment, what
>> tests you run etc. Below is a
>> > series of questions that come to mind, but there may be other details
>> that you would like to share.
>> >   • Builds
>> >   • do you build your own OpenJDK builds, use Oracle's or
>> other EA builds ?
>> >   • Tests
>> >   • What tests do you run
>> >   • do you run the JCK ?
>> >   • open regression tests ?
>> >   • other tests ?
>> >   • do you measure code coverage ?
>> >   • Are the tests Automated or Manual ?
>> >   • How frequently to do execute the tests
>> >   • Are the results visible via an external link
>> > Rgds, Rory
>> >
>> > [1] https://wiki.openjdk.java.net/display/quality/Quality+Outrea
>> ch+report+September+2017
>> > [2] https://wiki.openjdk.java.net/display/quality/Quality+Outrea
>> ch+report+March+2017
>> > --
>> > Rgds,Rory O'Donnell
>> > Quality Engineering Manager
>> > Oracle EMEA , Dublin, Ireland
>> >
>> >
>>
>>
>
>

Re: Client side testing

[Vincent Privat]

Sure! Currently coverage is restricted to JOSM classes, for obvious
performance reasons, as we run a full build after each commit.
But I can add a parameter to change the monitored packages in our EA
builds.
Is it OK if I add java, javax, sun and com.sun ? Or do you prefer to
restrict only to packages from java.desktop module?

2017-11-06 19:31 GMT+01:00 Alexandre (Shura) Iline <
alexandre.il...@oracle.com>:

> This is great that you are touching the new builds, thank you, Vincent.
>
> I am not familiar with JOSM code, but the app is great! I have played with
> it in the past.
>
> Do you think it would be possible, in addition to what you are doing, to
> collect code coverage for the  JDK code? Specifically for the now existing
> java.desktop module. I do not know much of JaCoCo - we are using JCov, as
> you can imagine - so I do not know how easy it is. If it is easy, can you
> flip the switch?
>
> Shura
> > On Nov 3, 2017, at 8:33 AM, Vincent Privat <vincent.pri...@gmail.com>
> wrote:
> >
> > Hello Rory,
> > Thank you :)
> >
> > Here is how we test various OpenJDK builds:
> > 1.1: we use only EA builds from http://jdk.java.net/
> > 2.1.1: no
> > 2.1.2/2.1.3: we run all unit and integration tests of JOSM
> > 2.1.4: yes, using jacoco
> > 2.2: all tests are automated
> > 2.3: it depends. During OpenJDK9 cycle we did not run a test series for
> each weekly build, but rather once every two or three builds, unless we
> were waiting for a specific correction from OpenJDK or another tool. At the
> end of development, we were not waiting for any correction from OpenJDK but
> were eagerly waiting for the updates of ASM and everything that as blocked
> by the non-availability of ASM (in particular various Maven plugins)
> > 2.4: Yes, they are visible here:
> > - JOSM core: https://josm.openstreetmap.de/jenkins/job/Java-EarlyAccess-
> JOSM/
> > - JOSM community plugins: https://josm.openstreetmap.de/
> jenkins/job/Java-EarlyAccess-JOSM-Plugins/
> >
> > I just have initiated JDK10 tests today, and we have 53 failures caused
> by Byte Buddy not recognizing Java version 10:
> >
> > java.lang.IllegalArgumentException: Unknown Java version: 10
> >   at nl.jqno.equalsverifier.internal.lib.bytebuddy.ClassFileVersion.
> ofJavaVersion(ClassFileVersion.java:135)
> >
> >
> > I'm sure Rafael is aware of it. I will see how to update our tools
> (equalsverifier here).
> >
> > Cheers,
> > Vincent
> >
> > 2017-11-03 14:05 GMT+01:00 Rory O'Donnell <rory.odonn...@oracle.com>:
> >
> > Hi Vincent,
> >
> > I noticed that JOSM have been commended in the last two Quality reports
> [1] [2] for the number and
> > indeed the quality of bugs you have found and logged against various
> early access releases.
> > Thanks again for your contribution to the quality of our releases!
> >
> > The big question is how do you do it ?
> >
> > We would love to hear more details about your test environment, what
> tests you run etc. Below is a
> > series of questions that come to mind, but there may be other details
> that you would like to share.
> >   • Builds
> >   • do you build your own OpenJDK builds, use Oracle's or
> other EA builds ?
> >   • Tests
> >   • What tests do you run
> >   • do you run the JCK ?
> >   • open regression tests ?
> >   • other tests ?
> >   • do you measure code coverage ?
> >   • Are the tests Automated or Manual ?
> >   • How frequently to do execute the tests
> >   • Are the results visible via an external link
> > Rgds, Rory
> >
> > [1] https://wiki.openjdk.java.net/display/quality/Quality+
> Outreach+report+September+2017
> > [2] https://wiki.openjdk.java.net/display/quality/Quality+
> Outreach+report+March+2017
> > --
> > Rgds,Rory O'Donnell
> > Quality Engineering Manager
> > Oracle EMEA , Dublin, Ireland
> >
> >
>
>

Re: Plugins: deprecated API to be removed

[Vincent Privat]

Hi Holger,
Sorry for not responding earlier, but I have already updated a lot of
plugins, see https://github.com/openstreetmap/josm-plugins/commits/master
Still some work to do (around 1100 deprecation warnings)
Cheers,
Vincent

2017-10-30 21:16 GMT+01:00 Holger Mappt :

> On 2017-10-23 at 00:15 +0200 Paul Hartmann wrote:
>
>> On 21.10.2017 17:49, Holger Mappt wrote:
>>
>>> Is the sonar the right place to see what is deprecated, i.e. what needs
>>> to be changed? [1]
>>> [1] https://josm.openstreetmap.de/sonar/project/issues?id=josm-p
>>> lugins=false=squid%3ACallToDeprecatedMethod
>>>
>>
>> Possible, but the normal way would be to have the java compiler output
>> deprecation warnings (use compiler option -Xlint:deprecation for javac to
>> see details).
>>
>
> The trick is to call "ant clean" before "ant", otherwise the deprecation
> messages are not shown. Option -Xlint:deprecation is on by default if
> ../build-common.xml is imported from build.xml.
>
> Thanks,
> Holger
>
>
>
>
>
>
>

Re: JOSM 12914

[Vincent Privat]

Hello,
Thanks to Paul's efforts JOSM 12921 is now available as hotfix.
Thanks Tod for reporting us this major issue today!
Vincent

2017-10-03 20:41 GMT+02:00 Matthieu Gaillet :

>
> I use the packaged version of 12792 without any problem on High Sierra.
>
> > On 3 Oct 2017, at 18:45, Paul Hartmann  wrote:
> >
> > On 03.10.2017 17:32, Tod Fitch wrote:
> >> Got a notice to upgrade JOSM today so I downloaded the latest
> josm-tested.jar
> >> Issues:
> >> This apparently needs a whole new setup.
> >
> > There was a major bug in that Mac OS X was not recognized correctly and
> JOSM behaved as if it runs on a Linux computer (#15395). This is fixed in
> version 12919, which will soon be published as a bug fix release.
> >
> > The problem was introduced on 7th September ([12776]) but unfortunately
> not reported so far, so thanks for that!
> >
> > Paul
> >
>
>
>

Re: JOSM 12914

[Vincent Privat]

Hi Tod,
Please file a bug report with your status report. Screenshots and
information about your language and keyboard layout will be needed too.
Cheers,
Vincent


2017-10-03 17:32 GMT+02:00 Tod Fitch :

> Got a notice to upgrade JOSM today so I downloaded the latest
> josm-tested.jar
>
> Issues:
> This apparently needs a whole new setup. Not a problem, except my
> passwords are kept in a KeePass file, are randomly generated and are very
> long. In other words, impossible to remember and very difficult to type.
> This new version of JOSM does not allow copying and pasting from the
> Macintosh KeePassX file. So I have to type the password. But there are no
> options to show what I am typing. I finally got it in right but it took me
> a while and was very frustrating. Please, please, please allow pasting
> passwords!
>
> None of my familiar Macintosh keyboard shortcuts seem to work. Is there
> some way to restore the keyboard setup used on earlier JOSM versions?
>
> Thanks!
>
>
>
>

Re: [OSM-dev-fr] Beta-test du support des fichiers du cadastre dans JOSM

[Vincent Privat]

Hello,
les données ont été publiées sur data.gouv.fr aujourd'hui comme prévu:
http://www.data.gouv.fr/fr/datasets/pci-vecteur-plan-cadastral-informatise/

le beta test JOSM commence ! :)

Le 27 septembre 2017 à 23:22, Vincent Privat <vincent.pri...@gmail.com> a
écrit :

> bien sûr, je suis dispo pour toute question (mail, twitter, etc.)
>
> Quelques explications:
> Le plugin nécessite JOSM "latest", il permet d'ouvrir les lots édigéo via
> file/open, ou en drag, soit de l'archive tar.bz2, soit du fichier .THF.
> Les géométries sont automatiquement simplifiées pour éviter d'avoir des
> piscines avec 500 nœuds. Le souci des bâtiments coupés en 2 au milieu d'une
> limite de parcelle ne se pose pas, vu qu'il s'agit des géométries natives
> du cadastre.
> Actuellement sont chargés le bâti, les limites administratives, les
> parcelles & sections, les adresses, la voirie, et diverses autres choses
> (puits, pylônes, cimetières, bâtiment de culte, etc.)
> Ne sont pas chargés: les infos de mitoyenneté (mur, fossé) parce que
> représentées par un nœud, et les choses qui sont bizarrement regroupées
> dans le cadastre telles que "terrains de sport et petits ruisseaux"
> (WTF?!), ou bien "parking, terrasse, surplomb", etc.
> Pour les curieux la correspondance entre les données du cadastre et les
> tags OSM se fait ici:
> https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/
> org/openstreetmap/josm/plugins/fr/cadastre/edigeo/
> pci/EdigeoPciReader.java#L37
>
> Je suis curieux de savoir:
> - s'il manque des catégories de classification de voirie
> - si vous rencontrez des plantages
> - si des tags vous semblent incorrects/incomplets
> - si des géométries vous paraissent trop simplifiées, ou pas assez
>
> et pour les motivés:
> - si vous voyez des oublis par rapport à la doc du cadastre:
> https://www.data.gouv.fr/s/resources/plan-cadastral-informatise/
> 20170906-150737/standard_edigeo_2013.pdf
>
>
> Le 27 septembre 2017 à 11:04, Vincent de Château-Thierry <osm.v...@free.fr
> > a écrit :
>
>>
>> > De: "Vincent Privat" <vincent.pri...@gmail.com>
>> >
>> > Hello,
>> > Les données du Cadastre doivent normalement apparaître d'ici vendredi
>> > sur data.gouv.fr :
>> > http://www.data.gouv.fr/fr/datasets/pci-vecteur-plan-cadastr
>> al-informatise/
>> >
>> > On peut déjà avoir un accès anticipé aux données en demandant
>> > directement sur Twitter:
>> > https://twitter.com/jdesboeufs/status/910196623984164867
>> >
>> > Ce que j'ai fait la semaine dernière, et il en ressort une nouvelle
>> > version du plugin cadastre-fr de JOSM qui supporte le format
>> > "Edigéo" utilisé par la DGFiP:
>> > https://twitter.com/VincentPrivat/status/912353254562025472
>>
>> Simplement classe :)
>>
>> > Pour l'instant il n'y a pas encore d'API permettant de télécharger
>> > les données d'une bbox, il faut connaître le numéro du lot Edigéo
>> > (mais ça va venir).
>> >
>> > Je cherche des beta testeurs pour le support de ce format de fichier,
>> > je n'ai testé que sur 2 ou 3 communes de Haute-Garonne, des gens
>> > intéressés ?
>>
>> Oui, mais ça implique un peu d'assistance de ta part, pour la prise en
>> main. Tu vois si tu peux...
>>
>> merci
>> vincent
>>
>> ___
>> dev-fr mailing list
>> dev-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev-fr
>>
>
>
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Beta-test du support des fichiers du cadastre dans JOSM

[Vincent Privat]

bien sûr, je suis dispo pour toute question (mail, twitter, etc.)

Quelques explications:
Le plugin nécessite JOSM "latest", il permet d'ouvrir les lots édigéo via
file/open, ou en drag, soit de l'archive tar.bz2, soit du fichier .THF.
Les géométries sont automatiquement simplifiées pour éviter d'avoir des
piscines avec 500 nœuds. Le souci des bâtiments coupés en 2 au milieu d'une
limite de parcelle ne se pose pas, vu qu'il s'agit des géométries natives
du cadastre.
Actuellement sont chargés le bâti, les limites administratives, les
parcelles & sections, les adresses, la voirie, et diverses autres choses
(puits, pylônes, cimetières, bâtiment de culte, etc.)
Ne sont pas chargés: les infos de mitoyenneté (mur, fossé) parce que
représentées par un nœud, et les choses qui sont bizarrement regroupées
dans le cadastre telles que "terrains de sport et petits ruisseaux"
(WTF?!), ou bien "parking, terrasse, surplomb", etc.
Pour les curieux la correspondance entre les données du cadastre et les
tags OSM se fait ici:
https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37

Je suis curieux de savoir:
- s'il manque des catégories de classification de voirie
- si vous rencontrez des plantages
- si des tags vous semblent incorrects/incomplets
- si des géométries vous paraissent trop simplifiées, ou pas assez

et pour les motivés:
- si vous voyez des oublis par rapport à la doc du cadastre:
https://www.data.gouv.fr/s/resources/plan-cadastral-informatise/20170906-150737/standard_edigeo_2013.pdf


Le 27 septembre 2017 à 11:04, Vincent de Château-Thierry <osm.v...@free.fr>
a écrit :

>
> > De: "Vincent Privat" <vincent.pri...@gmail.com>
> >
> > Hello,
> > Les données du Cadastre doivent normalement apparaître d'ici vendredi
> > sur data.gouv.fr :
> > http://www.data.gouv.fr/fr/datasets/pci-vecteur-plan-
> cadastral-informatise/
> >
> > On peut déjà avoir un accès anticipé aux données en demandant
> > directement sur Twitter:
> > https://twitter.com/jdesboeufs/status/910196623984164867
> >
> > Ce que j'ai fait la semaine dernière, et il en ressort une nouvelle
> > version du plugin cadastre-fr de JOSM qui supporte le format
> > "Edigéo" utilisé par la DGFiP:
> > https://twitter.com/VincentPrivat/status/912353254562025472
>
> Simplement classe :)
>
> > Pour l'instant il n'y a pas encore d'API permettant de télécharger
> > les données d'une bbox, il faut connaître le numéro du lot Edigéo
> > (mais ça va venir).
> >
> > Je cherche des beta testeurs pour le support de ce format de fichier,
> > je n'ai testé que sur 2 ou 3 communes de Haute-Garonne, des gens
> > intéressés ?
>
> Oui, mais ça implique un peu d'assistance de ta part, pour la prise en
> main. Tu vois si tu peux...
>
> merci
> vincent
>
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] Beta-test du support des fichiers du cadastre dans JOSM

[Vincent Privat]

Hello,
Les données du Cadastre doivent normalement apparaître d'ici vendredi sur
data.gouv.fr:
http://www.data.gouv.fr/fr/datasets/pci-vecteur-plan-cadastral-informatise/
On peut déjà avoir un accès anticipé aux données en demandant directement
sur Twitter:
https://twitter.com/jdesboeufs/status/910196623984164867
Ce que j'ai fait la semaine dernière, et il en ressort une nouvelle version
du plugin cadastre-fr de JOSM qui supporte le format "Edigéo" utilisé par
la DGFiP:
https://twitter.com/VincentPrivat/status/912353254562025472

Pour l'instant il n'y a pas encore d'API permettant de télécharger les
données d'une bbox, il faut connaître le numéro du lot Edigéo (mais ça va
venir).

Je cherche des beta testeurs pour le support de ce format de fichier, je
n'ai testé que sur 2 ou 3 communes de Haute-Garonne, des gens intéressés ?
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: Release Announcement: General Availability of JDK 9

[Vincent Privat]

Hello Rory,
Congratulations!
We're ready :)
We announced full Java 9 compatibility and support on 2017-09-02.
Best regards,
Vincent

2017-09-21 22:17 GMT+02:00 Rory O'Donnell :

> Hi Vincent,
>
> Three items to share with you today
>
>
>
>-
> *JDK 9 General Availability *
>   - GPL'd binaries from Oracle are available here:
>  - http://jdk.java.net/9
>   - See Mark Reinhold's email for more details on the Release [1]
>   - delivery of Project Jigsaw [2]
>
>
>- Are you JDK 9 Ready ?
>- The Quality Outreach wiki has been updated to include a JDK 9 Ready
>   column.
>   - If you would like us to identify your project as JDK 9 ready ,
>   please let me know and I will add it to the wiki.
>
>
>- Quality Outreach Report for September 2017 is available
>   - many thanks for your continued support and welcome to the new
>   projects!
>
>
>
> Rgds,Rory
> [1] http://mail.openjdk.java.net/pipermail/announce/2017-
> September/000230.html
> [2] https://mreinhold.org/blog/jigsaw-complete
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
>

Re: Java releases every six months

[Vincent Privat]

someone did ^^ https://twitter.com/glaforge/status/905710144675307520

2017-09-06 22:00 GMT+02:00 Vincent Privat <vincent.pri...@gmail.com>:

> Haha you can ask him directly :)
> https://twitter.com/mreinhold/status/905444853076566016
>
> 2017-09-06 21:44 GMT+02:00 Dirk Stöcker <openstreet...@dstoecker.de>:
>
>> On Wed, 6 Sep 2017, Vincent Privat wrote:
>>
>> "the version strings of feature releases will be of the form $YEAR.$MONTH.
>>> Thus next year’s March release will be 18.3, and the September long-term
>>> support release will be 18.9."
>>>
>>
>> Will the march 2100 release then be 100.3 ? ;-)
>>
>> Ciao
>> --
>> http://www.dstoecker.eu/ (PGP key available)
>>
>
>

Re: Java releases every six months

[Vincent Privat]

Haha you can ask him directly :)
https://twitter.com/mreinhold/status/905444853076566016

2017-09-06 21:44 GMT+02:00 Dirk Stöcker <openstreet...@dstoecker.de>:

> On Wed, 6 Sep 2017, Vincent Privat wrote:
>
> "the version strings of feature releases will be of the form $YEAR.$MONTH.
>> Thus next year’s March release will be 18.3, and the September long-term
>> support release will be 18.9."
>>
>
> Will the march 2100 release then be 100.3 ? ;-)
>
> Ciao
> --
> http://www.dstoecker.eu/ (PGP key available)
>

Java releases every six months

[Vincent Privat]

Hello,
Mark Reinhold announced a big change for Java today:
https://mreinhold.org/blog/forward-faster

"after Java 9 we adopt a strict, time-based model with a new feature
release every six months, update releases every quarter, and a long-term
support release every three years."
"the version strings of feature releases will be of the form $YEAR.$MONTH.
Thus next year’s March release will be 18.3, and the September long-term
support release will be 18.9."

I cannot yet evaluate the impact for JOSM. What drives our migration
schedules is often the availability of the latest version of Java on Ubuntu
LTS. We will see in the coming months how Debian and Ubuntu adapt their
update cycle.

Vincent

I propose that after Java 9 we adopt a strict, time-based model with a new
feature release every six months, update releases every quarter, and a
long-term support release every three years propose that after Java 9 we
adopt a strict, time-based model with a new feature release every six
months, update releases every quarter, and a long-term support release
every three years.

[OSM-dev-fr] Fwd: Osmose - format de fichiers des issues

[Vincent Privat]

Sur la bonne mailing list...

-- Message transféré --

Aux devs Osmose qui me lisent :)

Nouveau projet JOSM en cours:
- https://josm.openstreetmap.de/ticket/14704: export des warnings du
validator en xml/json
- https://josm.openstreetmap.de/ticket/15182: version "standalone" du
validateur (jar allégé, en ligne de commande sans interface graphique)

Question: le format décrit sur le wiki [1] est-il toujours d'actualité ? Je
pense le réutiliser/l'étendre pour cette fonction. Des fois que ça puisse
amener à de l’interopérabilité... :)

[1]: https://wiki.openstreetmap.org/wiki/Osmose#Issues_file_format

A+
Vincent
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: Presets in iD not in vespucci/JOSM

[Vincent Privat]

Nice, could you please create a ticket for component "internal preset"?
We'll sort out possible enhancements for JOSM.

2017-08-22 16:57 GMT+02:00 Simon Poole :

> I semi-manually generated a list of presets (using taginfos project
> documentation) that "only" iD has, compared to vespucci. While the
> vespucci - JOSM presets have diverged somewhat, the list may still be of
> interest for this group.
>
> https://github.com/simonpoole/beautified-JOSM-preset/issues/27
>
> Some of the presets are IMHO bogus, but the majority isn't.
>
> Simon
>
>
>

Re: [OSM-dev-fr] Problème sur serveur d'orthophoto Toulouse ?

[Vincent Privat]

Pas de souci avec ta conf, c'est bien le serveur qui a un souci.

Le 18 août 2017 à 08:05, Art Penteur  a écrit :

> Bonjour,
>
>Depuis JOSM, lorsque j'essaye d'afficher l'orthophotoplan Toulouse
> 2015 (serveur wms.openstreetmap.fr/tms/...) je n'ai plus d'image et un
> message : erreur HTTP 502 lors du chargement des tuiles.
>
>Un gentil administrateur qui ne soit pas en vacances pourrait-il me
> dire s'il y a effectivement un problème côté serveur, ou si c'est ma
> config JOSM qu'il faudrait mettre à jour ?
>
> Art.
>
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: Ready for JDK 9 ?

[Vincent Privat]

Hello Muneer,
I have created incident 9050418 for point 2.
Best regards,
Vincent

2017-08-08 13:03 GMT+02:00 Muneer Kolarkunnu <abdul.kolarku...@oracle.com>:

> Hi Vincent,
>
>
>
> Regarding the points in the below email:
>
> (2) Can you please raise an incident for this?
>
> (3) I added josm-interest label on JDK-8058778 and we let you know once it
> get fixed.
>
>
>
> Regards,
>
> Muneer
>
>
>
> *From:* Rory O'Donnell
> *Sent:* Tuesday, August 08, 2017 3:53 PM
> *To:* Vincent Privat
> *Cc:* Rory O'Donnell; Dalibor Topic; Balchandra Vaidya; Muneer
> Kolarkunnu; josm-dev
> *Subject:* Re: Ready for JDK 9 ?
>
>
>
> Great news, thanks for the update!
>
> Rgds,Rory
>
>
>
> On 08/08/2017 10:59, Vincent Privat wrote:
>
> Hello Rory,
>
> Just in time ! We announced the JDK9 full compatibility less than 2 days
> ago:
>
> https://josm.openstreetmap.de/ticket/11924
>
>
>
> The compatibility effort was significant, but shared with the whole Java
> ecosystem (as we created bug reports to Ant, Groovy, EqualsVerifier,
> Geotools, FindBugs/SpotBugs, ErrorProne, etc.).
>
>
>
> Aside Jigsaw, the three JDK9 changes that impacted us most were:
>
> 1) The Math improvements to Math.cos in b105 (JDK-8143353, see
> https://josm.openstreetmap.de/ticket/11889 + https://josm.openstreetmap.
> de/ticket/13387). It took us a long time to spot why
>
> our floating point calculations changed in JDK9. But we noticed a huge
> performance gain, and more accurate results too. This is a huge
> improvement, thanks!
>
> 2) The deprecation of _MASK constants in favor of _DOWN_MASK constants
> (JDK-8143077). It was not easy to switch because ActionEvent does not
> provide extended modifiers (there's no getModifiersEx() method in this
> class. I think it should have been added in 9, could you please consider it
> in 10 ?).
>
> 3) The impossibility to disable the "proprietary API warning" in 9 (we
> disabled it with non-supported option -XDignore.symbol.file in 8). Until we
> switch our codebase to a version of Java providing the new certificate
> creation API (JDK-8058778), we must keep our current implementation based
> on sun.x509 packages. Currently the best I can do is tell our Jenkins
> instance to filter this warning.
>
>
>
> Congrats for this major release of Java,
>
> Best regards,
>
> Vincent
>
>
>
>
>
>
>
> 2017-08-08 11:30 GMT+02:00 Rory O'Donnell <rory.odonn...@oracle.com>:
>
>
> Hi Vincent,
>
> Thank you very much for all your testing of JDK 9 during its development!
> Such contributions have significantly helped shape and improve JDK 9.
>
> Now that we have reached the JDK 9 Final Release Candidate phase [1] , I
> would like to ask if your project can be considered to be 'ready for JDK
> 9', or if there are any remaining show stopper issues which you've
> encountered when testing with the JDK 9 release candidate.
>
> JDK 9  b181 is available at http://jdk.java.net/9/
>
> If you have a public web page, mailing list post, or even a tweet
> announcing you project's readiness for JDK 9, I'd love to add the URL to
> the upcoming JDK 9 readiness page on the Quality Outreach wiki.
>
>
> Looking forward to hearing from you,
> Rory
>
> [1] http://openjdk.java.net/projects/jdk9/
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
>
>
>
>
> --
>
> Rgds,Rory O'Donnell
>
> Quality Engineering Manager
>
> Oracle EMEA , Dublin, Ireland
>
>

Re: Ready for JDK 9 ?

[Vincent Privat]

Hello Rory,
Just in time ! We announced the JDK9 full compatibility less than 2 days
ago:
https://josm.openstreetmap.de/ticket/11924

The compatibility effort was significant, but shared with the whole Java
ecosystem (as we created bug reports to Ant, Groovy, EqualsVerifier,
Geotools, FindBugs/SpotBugs, ErrorProne, etc.).

Aside Jigsaw, the three JDK9 changes that impacted us most were:
1) The Math improvements to Math.cos in b105 (JDK-8143353, see
https://josm.openstreetmap.de/ticket/11889 +
https://josm.openstreetmap.de/ticket/13387). It took us a long time to spot
why
our floating point calculations changed in JDK9. But we noticed a huge
performance gain, and more accurate results too. This is a huge
improvement, thanks!
2) The deprecation of _MASK constants in favor of _DOWN_MASK constants
(JDK-8143077). It was not easy to switch because ActionEvent does not
provide extended modifiers (there's no getModifiersEx() method in this
class. I think it should have been added in 9, could you please consider it
in 10 ?).
3) The impossibility to disable the "proprietary API warning" in 9 (we
disabled it with non-supported option -XDignore.symbol.file in 8). Until we
switch our codebase to a version of Java providing the new certificate
creation API (JDK-8058778), we must keep our current implementation based
on sun.x509 packages. Currently the best I can do is tell our Jenkins
instance to filter this warning.

Congrats for this major release of Java,
Best regards,
Vincent



2017-08-08 11:30 GMT+02:00 Rory O'Donnell :

>
> Hi Vincent,
>
> Thank you very much for all your testing of JDK 9 during its development!
> Such contributions have significantly helped shape and improve JDK 9.
>
> Now that we have reached the JDK 9 Final Release Candidate phase [1] , I
> would like to ask if your project can be considered to be 'ready for JDK
> 9', or if there are any remaining show stopper issues which you've
> encountered when testing with the JDK 9 release candidate.
>
> JDK 9  b181 is available at http://jdk.java.net/9/
>
> If you have a public web page, mailing list post, or even a tweet
> announcing you project's readiness for JDK 9, I'd love to add the URL to
> the upcoming JDK 9 readiness page on the Quality Outreach wiki.
>
>
> Looking forward to hearing from you,
> Rory
>
> [1] http://openjdk.java.net/projects/jdk9/
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
>

Re: Order in JOSM files

[Vincent Privat]

Hello,
I rely on the ordering too.

This is a prerequisite to provide readable patches to boundaries.osm, see:
https://josm.openstreetmap.de/ticket/14833
https://josm.openstreetmap.de/ticket/15036

The other prerequisite is to keep stable ids. I have a working patch in
#14833 but not yet submitted as I must test it extensively before changing
this crucial part of JOSM.

2017-08-08 11:07 GMT+02:00 Jochen Topf :

> On Tue, Aug 08, 2017 at 10:51:36AM +0200, Simon Poole wrote:
> > And another data point: the implementation in Vespucci does not sort by
> > id (not only in theory, the output is really not ordered, which doesn't
> > cause issues with JOSM).
> >
> > Or put differently: if that becomes a requirement, it would be a good
> > idea to versionize the format (which naturally wouldn't actually solve
> > your issue).
>
> For me the files ceated by JOSM are important, not what JOSM reads.
> Having JOSM create something that is stricter than what it can read is
> perfectly backwards compatible. But I'd encourage you to also use the
> same kind of ordering in Vespucci, see my other mail for reasons.
>
> Not sure versioning would help us here. What would help is some kind of
> flag in the header of the file that tells us if the file is ordered and
> in what way. Than any software can directly see whether it can work with
> the file and, possibly, which algorithm to use.
>
> Jochen
> --
> Jochen Topf  joc...@remote.org  https://www.jochentopf.com/
> +49-351-31778688
>
>

[OSM-dev-fr] Stats sur les angles des highways

[Vincent Privat]

Hello,
On vient de nous soumettre cette idée:
https://josm.openstreetmap.de/ticket/15044

ça me semble une bonne idée mais pour trouver la valeur adéquate du seuil
je serai curieux d'avoir les angles moyens, médians et maximum entre 2
nodes consécutifs qu'on peut trouver dans la base pour chaque type de
highway.

Quelqu'un saurait faire ça ? (avec postgis ou autre)

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

Re: Compile problem: package com.sun.javafx.application does not exist

[Vincent Privat]

See https://josm.openstreetmap.de/ticket/2089#comment:16

Fedora just added support for openjfx, 2.5 years after Debian.
For OpenSUSE, no fresh news apart Java developers complaining about lack of
support.


2017-07-18 13:49 GMT+02:00 Eric Ladner :

> On Tue, Jul 18, 2017 at 3:47 AM Dirk Stöcker 
> wrote:
>
> > On Mon, 17 Jul 2017, Holger Mappt wrote:
> >
> > > Thank you for the package name. For openSUSE it is java-openjfx. I was
> > > searching for javafx before, but that results in netbeans-javafx, which
> > is
> > > not the right thing. I'm able to compile now.
> >
> > Which RPM did you install?
> >
> >
> Dirk,
>
> According to this
> https://ask.fedoraproject.org/en/question/93407/there-is-no-
> javafx-packages-in-openjdk-180-fedora-gnulinux/
>  , there is no javafx RPM for Red Hat based systems.
>
> The only option appears to be:  get the official Oracle 1.8 JDK.
>
> That post is a little old, though, but I couldn't find anything to the
> contrary.
>
>  Eric
>

Re: utils2 enhancements

[Vincent Privat]

If it's specific to buildings it might be better to enhance the
building_tools plugin:
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/BuildingsTools

You can then submit a patch on the JOSM bugtracker for review.

Cheers,
Vincent

2017-06-21 13:44 GMT+02:00 Bjoern Hassler :

> Dear friends,
>
> we've been looking at developing some plugins for JOSM, e.g. to facilitate
> fixing certain issues (e.g. assistance in replacing node-buildings by
> way-buildings, similar to 'replace geometry') as well as assistance
> adjusting residential areas (e.g. setting an arbitrary but consistent
> border to the next building).
>
> At the moment, we have some of this as javascripts in the scripting plugin.
> However, it would be good to transform it into a proper plugin. I think it
> could form a separate plugin, but it could also be integrated into utils2.
>
> Does anybody / the developers of utils2 have a view about this?
>
> Many thanks!
> Bjoern
>

Re: FW: Availabilty of JOSM reported bug fix in 8u152 b02 ea build

[Vincent Privat]

Hi Muneer,
I confirm the bug is fixed. Thanks!
Vincent

2017-04-21 13:19 GMT+02:00 Muneer Kolarkunnu :

> +josm-dev
>
>
>
> *From:* Muneer Kolarkunnu
> *Sent:* Wednesday, April 19, 2017 3:04 PM
> *To:* vincent.pri...@gmail.com
> *Cc:* Rory O'Donnell
> *Subject:* Availabilty of JOSM reported bug fix in 8u152 b02 ea build
>
>
>
> Hi Vincent,
>
>
>
> JOSM reported below bug is resolved and fix is included in the build 8u152
> b02.
>
>
>
> https://bugs.openjdk.java.net/browse/JDK-8169056 :
> StringIndexOutOfBoundsException in Pattern.compile with CANON_EQ flag
>
>
>
> Build is available here: https://jdk8.java.net/download.html
>
> Can you please confirm the fix.
>
>
>
> Regards,
>
> Muneer
>
> Quality Engineer
>
> Oracle, Bangalore, India
>

Re: mac ox package and wiki update

[Vincent Privat]

Hi Richard,
Thank you for your contribution to the wiki.
As you may have noticed, the wiki is community-based. Most of people who
edit it are not JOSM core developers. This allows us to focus on improving
JOSM code rather than maintaining documentation.
This modification has been made by a community member who I'm sure did not
meant to start an edit war.
Looking at the change:
https://josm.openstreetmap.de/wiki/Download?action=diff=107

I think Stereo simply wanted to remove the obsolete information about 10.8
and did not notice he removed the information about 10.12.

I'm going to restore it. Thanks for making us notice this mistake. I hope
you will change your mind and continue to contribute to the JOSM wiki :)

2017-03-26 16:31 GMT+02:00 Richard Welty :

> a couple of weeks ago i updated the wiki with a procedure for getting
> the josm app working in mac os 10.12 that was different from prior
> versions.
> in the interim i see that my update was removed in an edit labeled
>
> "Removed obsolete and irrelevant macOS info"
>
> the one method left in the wiki for mac os x does not work on my mac
> running mac os 10.12.3. the method that works is the one i added to
> the wiki. i know this because i just updated and things went the same
> way as before.
>
> in the interests of avoiding an edit war in the wiki i am not
> putting it back. but folks, if you're going to do an edit like that,
> you should be very sure you're right, and then double check.
>
> richard
>
> --
> rwe...@averillpark.net
>  Averill Park Networking - GIS & IT Consulting
>  OpenStreetMap - PostgreSQL - Linux
>  Java - Web Applications - Search
>
>
>
>