Re: Issue with personalized style

[Dirk Stöcker]

Hello,


I am writing to ask you because I created a custom style that I uploaded to the 
wiki [1], but it is not available in the list within JOSM. I checked the 
structure with other styles and it seems correct to me, what did I do wrong?


A better place for such a question is a JOSM ticket. (And waiting 1 month 
before asking. Respect!)


You were the first one who wrote "meta{" instead of any form with a 
whitespace after meta. I fixed the regexp for parsing the data.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: A functioning Public Transport plugin

[Dirk Stöcker]

On Fri, 13 Nov 2020, ipswichmapper--- wrote:


Can this addon be rewritten as an open-source addon that supports PTV2 and 
actually works?


Why should we rewrite it? It's already open source like most (all?) official 
plugins.

https://josm.openstreetmap.de/browser/osm/applications/editors/josm/plugins/public_transport

As for improvements, feel free to help yourself if you think a topic 
important enough. Patches are always welcome.


Otherwise all JOSM contributors developing stuff in their free time and 
they naturally choose tasks which are important or interesting to 
themself.


We're happy to help everybody who wants to help but does not yet have 
enough knowledge if the willigness to learn is visible.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Call to plugin authors: svgs in JOSM

[Dirk Stöcker]

Hello,


Can I ask for svn (or git) access to pointInfo plugin? Or I have to create
ticket with patch?


Can you please try (with your JOSM account). Should work now.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Call to plugin authors: svgs in JOSM

[Dirk Stöcker]

Hello,


I know, I've investigated the code, when I tried to make it work. Now I need
design a better icon for cursor modifier. My current attempt looks ugly :-(


Welcome in the club. That's usually the case when programmers design 
icons. :-)


Note from experience: For small sizes the SVGs must be properly aligned 
e.g. regarding position and size of the lines or otherwise it looks bad. 
The script in josm scripts directory also allows to check for some common 
issues in SVGs which josm does not like.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Call to plugin authors: svgs in JOSM

[Dirk Stöcker]

On Tue, 15 Sep 2020, Marián Kyral wrote:


It is much better now. Still not perfect, but I will tune it.


Note than in the source code like for png it is a good idea to not add the 
svg exension. JOSM automagically handles that.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

[Dirk Stöcker]

On Mon, 17 Aug 2020, Malcolm Herring via josm-dev wrote:


On 16/08/2020 19:21, Dirk Stöcker wrote:

 With "svn relocate" it's possible to switch an existing working copy to
 the new URL without a full re-checkout.


For those of us with only basic SVN experience, perhaps your could provide 
the full command string for this operation.


See the linked wiki page:


*  From the former OSM Subversion repository (recommended if you're also 
interested in plugins):
   svn co https://josm.openstreetmap.de/osmsvn/applications/editors/josm
*  If the old URL ​https://svn.openstreetmap.org/applications/editors/josm is 
used, then go to the working copy and call svn relocate with the new URL.


So when you did checkout

https://svn.openstreetmap.org/applications/editors/josm

the command must be insde "josm" dir:

svn relocate https://josm.openstreetmap.de/osmsvn/applications/editors/josm

For other dirs change path accordingly.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

OSM-SVN shut down, JOSM copy takes over

[Dirk Stöcker]

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: Plugin translation

[Dirk Stöcker]

On Tue, 14 Jul 2020, Dirk Stöcker wrote:


 Could someone give me 101 on how in the world I'll be able to create
 working .pot files (which then could go into the GitHub repo and into
 Transifex from there if I so need in the future) and .lang files from
 there?


The i18n directory isn't meant for single plugin translation. It joins all 
the files into one large translation file (or 3 files).


Your easiest choice probably is to call gettext commandline tool manually:

find ../plugins/plugname -iname "*.java" |xargs xgettext -k -ktrc:1c,2 
-kmarktrc:1c,2 -ktr -kmarktr -ktrn:1,2 -ktrnc:1c,2,3 -o plugname.pot


Or you need to create an ant target for a single plugin extraction.


I added a target singlepluginpot to extract pot file for a single plugin.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Plugin translation

[Dirk Stöcker]

Hello,


Could someone give me 101 on how in the world I'll be able to create
working .pot files (which then could go into the GitHub repo and into
Transifex from there if I so need in the future) and .lang files from there?


The i18n directory isn't meant for single plugin translation. It joins all 
the files into one large translation file (or 3 files).


Your easiest choice probably is to call gettext commandline tool manually:

find ../plugins/plugname -iname "*.java" |xargs xgettext -k -ktrc:1c,2 
-kmarktrc:1c,2 -ktr -kmarktr -ktrn:1,2 -ktrnc:1c,2,3 -o plugname.pot

Or you need to create an ant target for a single plugin extraction.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Remove missing plugins from local josm

[Dirk Stöcker]

Hello,


When I start JOSM I get a few warnings about missing plugins:
2020-07-04 10:04:03.485 WARNING: Missing plugin main version in plugin 
annotation-tester
2020-07-04 10:04:03.496 WARNING: Missing plugin main version in plugin 
nearclick
2020-07-04 10:04:03.499 WARNING: Missing plugin main version in plugin 
osmarender
2020-07-04 10:04:03.500 WARNING: Missing plugin main version in plugin 
plastic_laf


When I go to the plugins in the configuraton, only annotation-tester shows 
up, but it is unchecked and it says "annotation-tester: Version unknown 
(local: unknown)". The other three are not even in the list (I did download 
the list and I am viewing all plugins).

How can I clean this up so the messages disappear?


Very likely you have old files somewhere on your disk. Find and delete 
them.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Accessing third-party repositories

[Dirk Stöcker]

Hello Frederik,


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.


As Vincent already said this is a temporary situation and will be changed.


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.


JOSM allows to access really a lot of different web resources
* tag specific web sites
* OSM wiki
* JOSM server
* OSM SVN
* plugin/presets/style/rules files and embedded elements (icons)
* maps and map icons.

I try to keep it in a way, so that any connects not going to the JOSM 
or OSM API server somehow must be initially user-initiated (which is not 
100% true ATM, as e.g. maps icons are fetched (and cached) even if you not 
actively add a maps). And probably I also overlook something.



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?


I fear that would only be annoying like these famous cookie requests 
nowadays. And for plugins it would not be possible to enforce. JOSM is 
designed to be an online software and it's not so easy to prevent that 
without loosing much of what JOSM is.


Anyway I created ticket https://josm.openstreetmap.de/ticket/18712 for a 
bit more control.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Accessing third-party repositories

[Dirk Stöcker]

On Fri, 14 Feb 2020, Simon Poole wrote:


ELI has a privacy url field, though I believe Vespucci is currently the
only editor that a) points this out, and b) makes the link accessible to
end users.


See https://josm.openstreetmap.de/ticket/17285 for this.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

JOSM development in the last year

[Dirk Stöcker]

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: Getting tiles for plugin usage

[Dirk Stöcker]

On Thu, 17 Oct 2019, Jiri Vlasak wrote:


there was Missing Maps hackathon this weekend in Pilsen, Czech Republic. One of
the tasks we were working on was click building feature [1] -- building plot
based on mouse click to the middle of the building.

I am interested in getting background imagery in effective way. Currently, the
following steps are used:
1. Mouse listener knows the coordinates.
2. Coordinates are recomputed to TileXY.
3. New tiles around the mouse click are created in array (9 of them).
4. Based on Tile URL, Images are downloaded and used for algorithm.

I feel like downloading Tiles multiple times is not effective.


I'd recommend the meachnism already included in JOSM, e.g. the Tile loader 
classes which also do caching.



Also, I think that we found a bug in Tile.getUrl() -- for Esri imagery, it
returns:

https://{switch:services,server}.arcgisonline.com/arcgis/rest/services/World_Imagery/MapServer/tile/{zoom}/{y}/{x}/17/79468/63554.png

Instead of proper URL. And I have the same issues with Maxar.


Seems you use a templated tile url in a non-templated environment:

See here for a description of the templated format:
https://josm.openstreetmap.de/wiki/Maps#TileMapServicesTMS

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: view/plugin showing age of an object

[Dirk Stöcker]

Hello,


i am regularly visiting areas and try to find last modifications.
Typically this is caused by some routing regressions i get automatically
notified of.

So i know the rough area something has changed so i open the area and
now try to find recent changes. By recent i mean between 7 days to 2 hours.

Typically i click through suspect objects and look up their
history.

Optimally i'd like to have something like the maxspeed view which shows
the relative age of the objects in view. I couldnt find anything which
does this, and i couldnt find if i can access node/way metadata in
MapCSS e.g. calculate objects age.

Is there anything i didnt see?


Use the "timestamp:" search function?

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Server down?

[Dirk Stöcker]

On Sat, 23 Feb 2019, Martin Koppenhoefer wrote:


I can't reach josm.openstreetmap.de


can confirm it, me neither


Up again. A kernel bug caused a hanging system.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Wiki Spam

[Dirk Stöcker]

Hello,

ATM it seems spammers are getting more active again. If you see Spam in 
JOSM wiki please use the report function (there is a spam report button on 
each page and ticket when logged in).


Please also report "despammed" texts or tickets closed as spam or similar 
things. Spammers sometimes use such methods to hide their Spam and in JOSM 
wiki we always completely delete Spam.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

[Dirk Stöcker]

On Sat, 3 Nov 2018, Vincent Privat wrote:


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


That would help the Wiki side maybe, but probably not us. We do ATM one 
call per link. I only see a speedup when we could get all the i18n links 
at once somehow. I check the docs, but didn't find a solution.


There is an easy way for speedup. Use WWW::Mechanize instead of wget 
calls. But that increases the frequency of page calls and is not so good 
an idea. That's exactly what I use as rule to block IPs and WIKI admins 
wont be so different :-)


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

[Dirk Stöcker]

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

[Dirk Stöcker]

On Sat, 3 Nov 2018, Simon Poole wrote:


I normally don't edit compressed files.


Yes, and?


Your argument would be perfectly valid
(well if we forget that the entries have to be parsed)


Parsing throws away any nonmatching language, so runtime memory 
requirements wont change and I doubt that the parser time decrease due to 
removal of a few tags is relevant compared to a runtime user visible 
uneeded behaviour change.


if the URLs were stored in a separate file, as is, bloating a manually 
curated file, it is bonkers.


That's a source-code file! The software is not and should not be optimized 
for source code files. I opened the file with my editor a few seconds ago 
and loading time and scrolling time and any working time is not really 
measurable, so there is also no issue to fix here (unlike e.g. with the 
maps wiki, which was split into many subpage, as it became unmanageable 
at its time).


I don't think something is broken here, so it also needs no fix.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

[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
--
http://www.dstoecker.eu/ (PGP key available)

Re: JOSM developers meetup at Karlsruhe?

[Dirk Stöcker]

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?

[Dirk Stöcker]

On Mon, 15 Oct 2018, Michael Zangl wrote:

Since you are the one one objecting the loudest so far and won't be 
attending, what are the points that would convince you to do one of the 
following:


* Switch to a different build system


It must have advantages over the current one and must work offline and 
without third party server infrastructure.



* Switch to a different / decentralized source versioning system?


It must have advantages over the current one and must work without third 
party server infrastructure.



* Change the project layout fundamentally (different source dir layout)


I have no opinion here. Can't remember that I ever voiced either pro nor 
contra. If it makes sense why not? Thought the general rule applies here 
as well: It must have advantages over the current layout.


And changes must be incremental, like all JOSM changes.


* Change the way in which JOSM is started (e.g. to replace webstart)


I don't use Webstart myself, as I don't use Windows. Whatever solution is 
the best here should be implemented. In the history Webstart was not the 
suggested solution, people downloaded the installers or the JAR-files as 
main method. Webstart has a lot of advantages and keeping an method as 
simple as that working would be a fine goal.


But probably changing the exe to be a full-featured compiled Java exe is 
also a good way. That decision is up to the Windows users and developers.


For most proposals, you currently have a "is no option" opinion, which makes 
it difficult for us to discuss anything we could apply later.


Don't mix that: For the first two points I currently have a big no, as 
suggestions involve mostly relying on third party services (in case of git 
even on Microsoft). I'm too long in this business to ever do that again 
for a critical infrastructure component.


It was simply too often that services said "Sorry, we terminate this now" 
or even "We encriple this now" to me that I trust such things if I can do 
otherwise in a similar way. ATM we could simply copy our backup to a new 
server and go on in case our service is shutdown now (with some hard work 
reinstalling...). I don't want to give up that possibility for a bit of 
additional niceties.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: JOSM developers meetup at Karlsruhe?

[Dirk Stöcker]

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?

[Dirk Stöcker]

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?

[Dirk Stöcker]

On Sun, 14 Oct 2018, Michael Zangl wrote:

For example, we could change the @since Javadoc-tags, to a real @ApiVersion 
annotation to mark this public API


That would require a different development model for JOSM. And 
especially it would need a lot of work spend for defining, describing 
and supporting a stable API.


That manpower simply does not exist, so there is no chance for a stable 
API.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Caching mechanisms on GPX layers

[Dirk Stöcker]

On Sat, 15 Sep 2018, Niklas B wrote:


(maybe this time..?)

Hi,

I'm currently implementing an option to cut overlapping GPX tracks when
merging them into one layer (followup of #16681
 "*allow multiple tracks to be
processed and prioritized (from different sources, e.g. GPS + phone +
Google Timeline)*", but when merging layers because this is not
specifically related to geotagging / geoimage layers).

Everything works fine, but the resulting GPX layer is not displayed
correctly: Some lines are displayed between tracks that are not connected
anymore (because another track was on top of it, so the underlying track
needed to be split) and also some weird lines connecting points that were
never connected appear - haven't figured them out yet.

Before I debug that any further: What caching mechanisms are there in
place, what do I have to reset? I'm already calling invalidate() (in
GpxData, which calls the appropriate listeners) and tried removing the
cached "dir" values from all of the waypoints, but it didn't help.
The layer will however be displayed perfectly fine if it's converted to a
data layer (and back) or saved as GPX and reloaded.

Any ideas on what might be the reason for that?


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)?


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: JOSM developers meetup at Karlsruhe?

[Dirk Stöcker]

On Mon, 3 Sep 2018, Vincent Privat wrote:


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 :)


In case someone is there: I'll be on INTERGEO in Frankfurt probably on 
17th of October.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: YourKit free license for JOSM core developers

[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 href="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: Publish plugin issue

[Dirk Stöcker]

On Thu, 31 May 2018, Michael Zangl wrote:

I'm not a fan of having distribution binary files in the source code 
repository or in any other repository that has to be at a specific place in 
the directory tree.


That may be the case, but it is the way it is and the task is not the 
reinvent the wheel, but to fix the trouble at hand.


We currently have all snapshot plugin jars including source/javadoc on the 
nexus server:


https://josm.openstreetmap.de/nexus/content/groups/public/org/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.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Publish plugin issue

[Dirk Stöcker]

On Wed, 30 May 2018, Holger Mappt wrote:


Build the files to do what with them?


Hmm. I think because these are a Quasi-Standard :-) Don't know.

Would a nodist directory parallel to 
dist be an option if the JARs are not to be uploaded to the repository?


They could be in the /dist. Would that be ok?

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Publish plugin issue

[Dirk Stöcker]

On Wed, 30 May 2018, Holger Mappt wrote:

I don't see how that can be done without conflicts. If the sources and 
javadoc JARs are generated but not svn added and svn committed then those 
JARs are SVN private files. Everyone who runs the according target will have 
those private files in her/his working copy dist directory. If someone svn 
adds and svn commits the JARs then the next svn update will show merge 
conflicts because the JARs are now in the repository and the working copy as 
private files and SVN doesn't know what to do.


A clean solution is to either add the sources and javadoc JARs to all targets 
and to create+commit them for all plugins in dist, or not to do that. The 
sources and javadoc JARs that were added in r34045 were deleted in the next 
revision, so my assumption is that we don't want those JARs in dist.


So what's the plan with sources and javadoc JARs?


Vincent wants these files to build, but they should not to be released.

Add an svn:ignore in build directory?

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: JOSM enhancements vs. separate plugin

[Dirk Stöcker]

On Fri, 11 May 2018, Martin Koppenhoefer wrote:


BSD ~  0%
Mac ~  8%
Linux   ~ 27%
Windows ~ 65%


Thank you. For comparison, these are numbers for market share and the
difference to JOSM (April 2018) [1]:

BSD 0%  (the same, either they are very niche or they are in the 2,45%
unknown and use an OS that effectively protects them from revealing their OS)
OSX 13,2% JOSM has 40% less OSX users compared to their supposed market
share Linux 1,7% JOSM has 1588% of Linux users ...
Win 81,7% JOSM has 20% less Win users

these are alternative numbers [2]

BSD 0.01 %
OSX 8,7%  -> -8%
Linux 2,3 % -> 1174%
Windows 88,6 % -> -27%


These numbers had always a systematic bias towards Windows. They are a 
sales marketshare and not a realistic representation of OS usage. E.g. all 
my private and nearly all the company computers I bought are counted as 
Windows systems, but they all operate under Linux. Only for embedded or 
industrial systems and servers it actually makes sense to buy a system 
without preinstalled Windows. But even these are probably not counted as 
Linux systems.


So probably JOSM's numbers are simply more realistic. That MacOS numbers 
are similar is a good indicator for that assumption.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: JOSM enhancements vs. separate plugin

[Dirk Stöcker]

Hello,


interesting, do you also have numbers for the operating systems used by Josm 
users in general (win, linux, osx, other unixes, etc.)?


Yes.

BSD ~  0%
Mac ~  8%
Linux   ~ 27%
Windows ~ 65%

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: JOSM enhancements vs. separate plugin

[Dirk Stöcker]

On Wed, 9 May 2018, Jo wrote:


I guess it all depends on availability of time of the core team. What
surprises me is that plugins that everybody probably have installed like
buidings-tools and utilsplugin2 are not 'adopted' into core.


No single plugin has more than 50% user base. Even not the ones 
automatically installed with windows installer.


That probably tells you something about how likely it is that others 

would be.

No. It tells you nothing.

As utilsplugin2 is specifically our "not ready or wanted for core" 
test plugin your comment is even less useful.



2018-05-09 7:25 GMT+02:00 Jiri Hubacek :


I would like to ask question about the JOSM enhancements. Where is the
line between functionality acceptable upstream and the feature that
should be in separate plugin?

The concrete example - I wrote some script for automatic creation of
residential area around the selected buildings. I rewrote it to Java to
be able to push it upstream but it looked too specific to be included in
"Tools" menu. So I created the plugin (mapathoner). Are there any
guidelines for these decisions?


There are guidelines, but they are not easy to explain. It is a personal 
decision based on a few major questions:


- is the function interesting for a large part of the user base
- does it fit into the overall concept of the editor
- is it mature enough to be in the core
- do we want to be responsible for it in the future
- does the LICENSE match the core requirements
- is there already a similar functionality

So chances for generic important mature functions with no similar feature 
existing are good. For others not.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: IDs for validator rules

[Dirk Stöcker]

On Mon, 30 Apr 2018, Florian Schäfer wrote:


I have a question about validator rules in JOSM, because I want to write 
several new rules for the wikipedia plugin as
part of my Summer of Code.

As far as I can see the ID of each test should be unique and JOSM core uses the 
IDs from 1 to 3799 (see [1]). So can I
simply choose a range of IDs at random somewhere above 3800. Or is there a 
central place where all IDs that are not in
core are collected?


Much over 3800. The internal list will continue growing in steps of 100.

Something like 1..10099

Not like PT Assistant using numbers now used by the core.


The comment on line [1] is marked with FIXME, because the current situation is 
not very good. The global uniqueness of
the IDs is not guaranteed.


You misunderstand that comment. The assignment to a test is a bit broken 
by concept. There are many tests now that have one ID, but actually do 
many different tests (e.g. the CSS based ones). The ID based skip only 
allows to skip them all or not. It should be more finegrained.



Would it make sense to no longer use integers as IDs for the TestErrors, but 
instead use the
fully-qualified class name of the Test-class and an integer that only has to be 
unique inside this one class?
If an integer ID is needed, the class name could be hashed (and maybe 
truncated) and use the resulting bytes as ID.


No. This does not solve the problem at all, only makes it more complex. 
Not the ID assignment to the test is the problem, but the subdividing of 
(some) tests. Even after some years I don't really see a solution, as e.g. 
strings hashes also fail in many situations. But it is probably not so 
important, as most people don't even know there are ignore features for 
individual tests results.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: josm startup 21 Minutes on current hardware // Disable network updates on start?

[Dirk Stöcker]

Hello,


today it hit me again - Josm updates styles on startup which made
the Startup take

2018-04-10 02:21:01.354 INFO: Log level is at INFO (INFO, 800)
[ ... ]
2018-04-10 02:41:33.656 INFO: Toolbar action 1323558253_wikipedia-icon_24 
overwritten: kendzi.josm.kendzi3d.action.LoadTextureLibraryAction gets 
kendzi.josm.kendzi3d.action.ShowPluginDirAction

Take 21 Minutes.

I am on a DSL Light aka 384KBit/s link and josm without my interaction
first updated a sign style which in itselt is 46MByte

I have disabled plugin autoupdate for the very same reason.

Is there a way to disable even more autoupdate stuff on startup?


Hmm. You could simply donwload the files and instead of adding the URLs 
add the local copy.


I suggest to open a ticket for this.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Support HTTPS

[Dirk Stöcker]

On Sun, 25 Mar 2018, Alexander Zatko wrote:


excellent. Thank you.


The TMS is not HTTPS-capable ATM? Will contacting the provider help?

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Support HTTPS

[Dirk Stöcker]

On Sun, 25 Mar 2018, Alexander Zatko wrote:

I would like to fix the entries for SK / freemap and see where in the 
wiki this can be done. However, I do not know how to test it.


When you change an Maps entry (https://josm.openstreetmap.de/wiki/Maps and 
subpages) click the preview button. In this preview page is (like in the 
normal one) behind each entry a {view} link. Open this link (best in a new 
tab/page to not loose changes) and check it.


This preview does not detect all possible problems (e.g. some certificate 
issues are not detected), but is a very good indication whether it works 
or not.



Is it possible to import a modified version of the wiki xml into JOSM?


That's also possible. You can add another maps source in expert 
preferences.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Support HTTPS

[Dirk Stöcker]

Hello,

for some years we are step by step migrating JOSM to https. Many others 
are doing the same, so the https usage is increasing a lot everyday.


Now JOSM server is completely https itself and in the last weeks also 
external resources like maps, styles, plugins, rules, presets step by step 
have been migrated. There are still some hundred links not using https, 
but many hundreds have been fixed already.


To get rid of the remaining ones I created a ticket:
https://josm.openstreetmap.de/ticket/16123

This contains a list of servers, which answer on port 443, but links are 
still in http. Servers who not answer on port 443 are not included!


Please help fixing these entries!

1) Some entries may simply be fixed by switching the link (e.g. these 
with 200 OK message).

 a) If in the wiki simply fix it (and test it!)
 b) If external inform the author and document it in the ticket

2) Some are broken server setups
 a) If an openstreetmap service please inform the authors to fix it and 
document this in the ticket
 b) If not OSM and you know the contacts, ask them friendly to fix it and 
document what you did in the ticket
 c) Otherwise only document the server state in the ticket for later 
checks


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: The (dark) future of Java on desktop

[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

[Dirk Stöcker]

On Thu, 8 Mar 2018, Dirk Stöcker wrote:

[nothing]

Sorry, operator error :-)

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: The (dark) future of Java on desktop

[Dirk Stöcker]

On Thu, 8 Mar 2018, 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.




Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: i18n - mapcss external rules

[Dirk Stöcker]

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
c) JOSM base language is English. You'd need to change the files 
accordingly. The base language setting in the header essentially is to 
exclude non-English stuff from translation.

c) see below.


Is it actually possible to translate mapcss external validators ?


Yes and no:
https://josm.openstreetmap.de/ticket/11392

The "Development tasks JOSM" is missing, but could be done easily when 
someone starts using this :-) It was not done because there is no data 
requiring it yet...


If you have done the above steps and have a zip file with translation data 
included give me a call (best via the ticket) and I'll implement the 
missing core file loader.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: josm Trac out of disk space

[Dirk Stöcker]

On Thu, 15 Feb 2018, 積丹尼 Dan Jacobson wrote:


Can't report any more JOSM bugs:

Trac detected an internal error:
OperationalError: could not extend file "base/16387/711454": No space left on 
device
HINT:  Check free disk space.


Fixed. Jenkins was going amok the second time now.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

[Dirk Stöcker]

Hi,


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."


I think once a year is enough. But I spread the word... My private server 
is there, I successfully told people to get servers there, most of my 
company servers are there, ...


The invitation to the data center was because of our company, not the 
private stuff - We have a NUMBER of servers rented ;-)


Last time I searched for backup servers at other companies and it is 
really complicated to find same quality and functionality for not more 
than double the price (if you keep in mind that you get what you pay for - 
Hetzner has different support levels depending on the price you pay - for 
the cheap virtual servers you should know what you do!).


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Thanks to our server sponsor Hetzner and all the JOSM contributors

[Dirk Stöcker]

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)

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

[Dirk Stöcker]

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
--
http://www.dstoecker.eu/ (PGP key available)

Re: JOSM and .kml polyline colour editing

[Dirk Stöcker]

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: Java releases every six months

[Dirk Stöcker]

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: Order in JOSM files

[Dirk Stöcker]

On Tue, 8 Aug 2017, Jochen Topf wrote:

I would urge you to keep the order because that makes many things much 
more efficient. For instance checking whether a file contains an object 
twice is trivial when there is a known order but very expensive without. 
My code for assembling multipolygons for instance needs to make sure 
that IDs aren't in a file twice and it uses this very efficient way 
instead of creating much more complex data structures which would need 
more RAM and make everything slower.


In general we will not make any changes only to do changes. So the chance 
that element order stays fixed as it is now is high. I'm not aware that it 
changed in the past.


BUT: You asked if you can rely on this. And the answer to this is that 
this cannot be guaranteed. :-)


But you simply can ignore this and hope that JOSM continues to produce 
nice files and chances are high your hope will be fulfilled.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Order in JOSM files

[Dirk Stöcker]

On Tue, 8 Aug 2017, Jochen Topf wrote:


When JOSM saves OSM files it uses a particular order: First nodes, then
ways, then relations as usual. For each object type it first writes out
objects with negative IDs (ie objects that are not uploaded yet), then
objects with positive IDs, both are ordered by absolute value.

Is this something I can rely on or is this just something that happened
accidentally with my version of JOSM when I tried this?

The reason I am asking: I sometimes get requests for Osmium features
from people who want to do something with files saved from JOSM, like
renumber them to have only small positive IDs, or convert them into
other formats. Osmium can read JOSM files and handle negative IDs, so
these things mostly work, but in some cases having a known order helps
(or is even necessary for correct functioning). I am currently working
on some things there but if JOSM would not keep to this order in the
future they would break again.


I would not rely on the order of the individual elements. There are ideas 
to rework the data storage to prevent changing IDs for the new objects 
(allows better diffs). That may have other side effects as well. I would 
expect the only thing you can rely on is the nodes, ways, relation order.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

[Dirk Stöcker]

On Tue, 18 Jul 2017, Vincent Privat wrote:


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.


This is again such a "packinging friendly" software which has unclear 
dependencies and assumes that a build server has internet access and 
instead of simply checking dependencies properly it tries to download them 
in the build process (typical brainfucked maven behaviour).


Some people are working on a package, but yet there is nothing really 
working. A properly working build setup would be fine.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

[Dirk Stöcker]

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?

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

JOSM server scraper

[Dirk Stöcker]

Hello,

if whoever started this month to massively scrape the data from JOSM 
server reads this mailing list: STOP IT!


The "403 Forbidden" should have been enough to understand this is 
unwanted. Circumventing the blocks shows that you did not learn the 
lesson.


I have no problem with slow page crawlers, but spending the majority of 
our CPU power for one website downloader is beyond any acceptable 
standards.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Advice on JOSM remote control

[Dirk Stöcker]

On Thu, 30 Mar 2017, Ian Feeney wrote:


Thanks for the reply.

Can you explain a little more about how I mark the XML data as upload=no please?


Don't use gpx. Use osm style data.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: interested in the idea 'Change build system to gradle' and prepare to write a proposal

[Dirk Stöcker]

Hello,


I am Hongfei Shen(you can call me Jeffy).I study Software Engineering at
Software School, Dalian University of Technology, China.I have learnt
Groovy and Gradle last winter vacation.In that vacation, I was interested
in web-development and was coding back-end using Groovy. In this summer
vacation I’d like to work on the idea ‘JOSM: Change build system to
gradle’.I think a good and easy-to-use build method is something like
infrastructure to a program and creating that is both meaningful and
interesting. But for now, I am wondering what I should do to write a good
proposal. Learning plan about ANT, learning how the project is build, or
anything? Could you please give me some suggestions?


I removed this GSOC idea. While ant has surely drawbacks it is not planned 
ATM to change the build system of JOSM. A conceptual study would 
be possible, but that effort could better be spent on other projects.


See also https://josm.openstreetmap.de/ticket/8269

If you want to contribute to JOSM in another place, have a look at our bug 
tracker for ideas. There are many ideas and some of them big enough for an 
GSOC project.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: GSoC - Specialized relation editor for public transport routes

[Dirk Stöcker]

On Wed, 22 Mar 2017, Giacomo Servadei wrote:


I'm an Italian student from Politecnico di Milano. I'm currently in the
process of making the proposal for polyglot's project idea of further
developing the pt_assistant plugin.
One part of the proposal is to implement a specialized version of the
editor with ad hoc functionalities for editing route relations (for example
reporting the validation results on that route or helping filling the gaps
by finding ways ecc).
In the code I saw that the relation editor we are all used to see is just
the generic one which will be showed if nothing more specific for that type
of relation has been registered. So the idea of a specialized relation
editor is already contemplated in JOSM. The point is that I did not find
any real example of such a specialized version of the dialog, at least in
the core.
Is there a plugin that does this and that I can take a look at? If not, are
there some best practice that should be followed and which I should be
aware of?


Does turn-restriction plugin provide a special relation editor? That's the 
only one I could think of. The idea to provide specialized relation 
editors was never fully implemented. Also the presets contain information 
about layout of relations and their members which is not used as much as 
it could. Much to improve :-)


If you will implement something in this area, create JOSM bug reports 
containing patches when core adaptions are needed. As you may know JOSM's 
plugin interface is always work in progress.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Haiti imagery and IPv6

[Dirk Stöcker]

Hello,

in december when there were 3 of the 4 haiti imageries offline I asked per 
http://openstreetmap.fr/contact about its status and received a quick answer.


Tried it. No Reaction, no change.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Haiti imagery and IPv6

[Dirk Stöcker]

Hello,

the server "wms.openstreetmap.fr" has an IPv6 address, but does not 
deliver anything over IPv6. Does anybody know who needs to contacted to 
fix this? It's a french URL, maybe the French talk groups knows the 
operator?


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Offline OSM vector file plugin to edit in the field - OBF vector format or other

[Dirk Stöcker]

On Sun, 26 Feb 2017, Pierre Béland wrote:

What I suggest is that JOSM adapt to different operational context out 
of our northern countries with high speed internet. To navigate with OSM 
in JOSM should be as easier as smarthpone offline applications for 
people that need to work offline because of bad / expensive access to 
internet networks.  My experience with smarthpones applications is that 
they are reliable, they provide fluidity. JOSM Caching is surely not as 
easy and reliable as these offline maps.  And badly, moving in an area 
with no internet connection, you realize that your setups are not ok and 
you have no background imagery.


I agree that Obf is not a standard. The best would be that one standard 
emerge for offline vector files. In the meantime, what can we do to 
adapt to all the countries / areas without high internet inexpensive 
bandwith?


I still have no idea what your issue is.

JOSM is an editor. Displaying imagery and navigation plugins and all that 
stuff is only to aid that functionality, not the main purpose.


For editing you need the raw data, so whatever you want to do, you need to 
download the OSM data for the area you want to edit (beforehand or 
online). If you do mapping on the ground you don't additionally need any 
other maps or imagery.


The only improvement I'd see to reduce bandwidth is a more compressed 
server data exchange (not using XML, but smaller formats) and differential 
data exchange (only transmitting changes).


If I overlook something please explain your use case better.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: Offline OSM vector file plugin to edit in the field - OBF vector format or other

[Dirk Stöcker]

On Sat, 25 Feb 2017, Pierre Béland wrote:

Smarthphones did provide us access to all of Haiti on OSMAnnd or 
Maps.Me. Our team was able to store tracks and waypoints on our phones. 
We did also use Mapillary and ODK tools. But at the end of the day, we 
could not edit the data in JOSM, bringing in these various infos to 
compare with the OSM map as a background. This, even if I tried 
previously to cache OSM tiles for the area, I did not have access to 
these tiles while in the field with no internet access. A cache could be 
a solution. A better solution is to Add an Offline OSM Vector map plugin 
to JOSM. This would be a great enhancement for OSM contributors that 
experience difficulty to access data online.


I don't understand what you request at all.

- JOSM has tile caches which usually are small, but you can increase size
- JOSM is an vector map editor - its main task is to display vector data
- JOSM can load stored offline data files in XML and also PBF format

Everything already there.

OBF support could be included in a plugin, but I don't see much sense to 
support a storage format of a single application.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: JOSM Translations

[Dirk Stöcker]

On Sun, 19 Feb 2017, Martin Koppenhoefer wrote:


I admit I have copied the initial message from Dirk to talk, thinking that
indeed there might be people around of those languages with missing
translations, not knowing that help could be needed but willing to give a
hand:
https://lists.openstreetmap.org/pipermail/talk/2017-February/077579.html

I excuse if this was premature...


I'm not subscribed to any other list anymore, so feel free to spread the 
word. Everthing which helps to improve the situation is welcome.


Sanitizing my language I have seen :-)

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: JOSM Translations

[Dirk Stöcker]

On Sun, 19 Feb 2017, Holger Mappt wrote:

It would be interesting to know how important translations are. Maybe it is 
okay for most of the users to use the English version.


The last days:

8079 (31.7%) en
5489 (21.5%) de
2615 (10.3%) ru
2157 ( 8.5%) fr
1541 ( 6.0%) en_GB
1018 ( 4.0%) es
 849 ( 3.3%) it
 709 ( 2.8%) pl
 468 ( 1.8%) ja
 426 ( 1.7%) nl
 311 ( 1.2%) zh_TW
 309 ( 1.2%) pt_BR
 239 ( 0.9%) zh_CN
 223 ( 0.9%) cs
 186 ( 0.7%) en_AU
 175 ( 0.7%) hu
 126 ( 0.5%) sv
 101 ( 0.4%) id
  92 ( 0.4%) uk
  81 ( 0.3%) sk
  57 ( 0.2%) da
  49 ( 0.2%) fi
  48 ( 0.2%) pt
  45 ( 0.2%) ca
  39 ( 0.2%) lt
  31 ( 0.1%) el
  17 ( 0.1%) nb
   5 ( 0.0%) be
   3 ( 0.0%) tr
   3 ( 0.0%) bg
   2 ( 0.0%) et
   2 ( 0.0%) gl
   1 ( 0.0%) vi
   1 ( 0.0%) ast

62% use a non-english version. That number would probably be higher if the 
translations in some languages would be better.


I think one of the issues is the enormous number of strings. We reached 1 
a few weeks ago. And there is a pretty high update frequency. You need days 
to catch up if no translation was done for a few months.


Yes. That's obvious. That burden can only be reduced when distributed to 
more shoulders (althought single people did translate thousands of texts).


Here everybody with more than 3000 translations:
14921 - pitort - ca   = 7959 - ca@valencia= 6962
10844 - andygol- ru   =  290 - uk   =10554
10486 - Viktar Palsciuk- be   =10486
10451 - mmyfl  - zh_CN=10451
10195 - Dirk Stöcker   - de   = 5146 (others: many languages as fixes)
10080 - aceman444  - cs   = 5220 - sk   = 4860
 8594 - Minh Nguyễn- vi   = 8594
 8132 - DiGro  - nl   = 8132
 7543 - edrux  - ast  = 7524 - es   =   19
 7512 - Davide Prade   - it   = 7512
 7441 - RPome  - pt   = 7441
 6726 - fujimoto   - ja   = 6726
 6186 - Casiope
 5972 - Chao-Hsiung Liao   - zh_TW= 5972
 5698 - Jørn   - da   = 5698
 5694 - Dalibor Jelínek- cs   = 5693 - sk   =1
 5656 - Báthory Péter  - hu   = 5656
 5633 - Casiope- fr   = 5633
 5335 - Felipe L.  - pt_BR= 5335
 4710 - Vlado  - sk   = 4710
 4562 - Dee-earlsoft   - en_GB= 4562
 3873 - Emilio Gomez Fernandez - es   = 3872 - fr   =1
 3858 - Sophea Sok - km   = 3858
 3720 - Aleksey Kabanov- ru   = 3720
 3584 - Robert Readman - en_AU= 3266 - en_GB=  318
 3309 - Ettore Atalan  - de   = 3309
 3110 - Rui- pt   = 3110
 3097 - Hiroshi Miura  - ja   = 3097
 3035 - Vitor George   - pt_BR= 3035

Another issue is the quality of the strings. Some source strings are not 
English (but French, Dutch, Polish, etc), have unknown acronyms in it, or


These are bugs and should be fixed.

it's just not clear what the string is about. That mainly affects plugins and 
the imagery. I sometimes open a ticket if the quality is bad. JOSM core 
tickets are resolved promptly, but plugin authors are lazy or don't respond


Yes. That's an issue. The success of JOSM has some drawbacks and 
unmaintained plugins is one of them. The core developers try to manage 
them, but we already have lots of core issues. No solution for this ATM. 
For things like translating issues tickets should nevertheless be opened. 
They are usually easy to fix and thus also easy to handle by the core 
team.


at all. There is no good way to address issues with the imagery strings 
(there is actually no way).


See answers in related ticket #12179.

One solution could be to separate the JOSM core strings from the plugin and 
imagery strings. Then translators can concentrate on the JOSM core, it would 
reduce the timeout errors, and it becomes doable to actually translate all 
(core) strings.


The other solution would be the long discussed migration to transifex. It 
includes also the splitting in 3 string groups.


Plugins are a different topic. I think there is no way to attract people to 
translate a large number of strings that nobody will ever read. An idea would 
be to rank the untranslated strings by the number of plugin installations (do 
we know this?) to start with the important strings. But Launchpad sorts them 
alphabetically, not by importance.


Oh. We know EVERYTHING :-) Don't ask me why this list has reversed order 
to the languages though - probably I implemented them at different 
times...


   4 (* 0.1%) NanoLog
  10 (* 0.2%) matsim
  15 (* 0.2%) videomapping
  22 (* 0.3%) sds
  27 (* 0.4%) globalsat
  32 (* 0.5%) czechaddress
  35 (* 0.6%) michigan_left
  35 (* 0.6%) epci-fr
  37 (* 0.6%) plastic_laf
  38 (* 0.6%) native_password_manager
  41 (* 0.6%) wms-turbo-challenge2
  45 (* 0.7%) canvec_helper
  46 (* 0.7%) scoutsigns
  48 (* 0.8%) OSMRecPlugin
  48 (* 0.8%) surveyor
  50 (* 0.8%) touchscreenhelper
  51 (* 0.8%) o5m
  51 (* 0.8%) pointInfo
  51 (* 0.8

JOSM Translations

[Dirk Stöcker]

Hello,

I had a look at our translation statistics recently and I find it awful, 
that there is no real progress to see, compared to the situation a few 
years ago.


A few languages are well maintained, but already such common languages 
like French and Spanish have large gaps.


Mainly a few individuals keep the whole translations business alive (many 
thanks to these mostly unnamed heros BTW).


Does anybody have ideas how more translators could be attracted for the 
languages which have many missing texts?


We do daily text uploads and although launchpad has issues from time to 
time it usually is stable. The tools exist.


I think the main problem is that people aren't aware they could help and 
are needed to do so.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Re: 2015 NAIP imagery not adding properly - How to fix?

[Dirk Stöcker]

On Fri, 10 Feb 2017, Albert Pundt wrote:


I've been trying to get the Pennsylvania 2015 NAIP imagery into JOSM as
Bing is horribly outdated in most areas, and USGS takes so long to load the
tiles it's unusable.

However, I can't seem to add the layer properly. I enabled remote control,
and used the link in this  page,
but the layer seems to be offset horizontally by half the width of the
world, and an odd flickering Pennsylvania in the middle that doesn't appear
at all at anything but the lowest zoom levels. Upon further
experimentation, it seems to do this for all the states' layers. Here
 is a demonstration video
showing this odd problem, and here

is my question about this on help.osm.org that I posted in addition to this
email.

What do I need to do to make this work?


Very likely your current projection does not match. It seems the server 
supports only EPSG:4326. JOSM's default is EPSG:3857.


The best solution would be to add the imagery sources to JOSMs list 
of imagery instead of using these links. Maybe you can work together with 
the author of the link list to add these links (if allowed to be used for 
OSM). It's a wiki and can be changed!


See here:
https://josm.openstreetmap.de/wiki/Maps
https://josm.openstreetmap.de/wiki/Maps/USA

This list provides some advantages:
* simply choose the imagery from JOSM settings directly instead of manual work
* automatic updates
* additional information like projections are handled automatically
* boundaries of the imagery allow automatic selection of applicable data
* JOSM's workaround to acces EPSG:4326 with EPSG:3857 is usable

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

B OSM Map

[Dirk Stöcker]

Hello,

does anybody know a contact address for the B OSM map on the wmflabs 
servers?


https://josm.openstreetmap.de/wiki/Maps#OpenStreetMapMapnikBlackWhite

The new tiles actually aren't black and white anymore.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: GSoC is over - core results

[Dirk Stöcker]

On Wed, 24 Aug 2016, Michael Zangl wrote:


Google summer of code has officially ended.


and thus it's also time to thank Michael for all the work he did.

I accepted to be his mentor for this projects, but only after ensuring
that my two co-admins Paul and Vincent agreed to help me, because I
expected not to have enough time for really good mentorship.

But Michael actually is very good at what he did and Vincent did most of
the work integrating the patches which seldom needed much rework
(otherwise probably also Vincent would have come to his limits seeing the
amount of patches by Michael). So hid did not need much advise beside 
the discussions in the tickets.


And the result is very good. There isn't much visible to the user now
(maybe except more bug reports in the last two months :-), but a lot of
JOSM's main classes are much more future compatible than before. The only
similar changes I remember have been the display filtering mechanism and
the introduction of the QuadTree storage and both were essential for
allowing to grow JOSM with the increased demands.

I hope Michael will also find time in the future to contribute to JOSM
even if the student times are nearly over and real world awaits him :-)

Again a lot of thanks to Michael (and to Vincent)!

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

[josm-dev] JOSM mailinglist and DKIM

[Dirk Stöcker]

Hello,

the josm-mailinglist destroys DKIM signatures, as each messages gets 
[josm-dev] added to the subject and that breaks any signature. To get rid 
of that effect I'll turn off adding [josm-dev] in the subject in a few days.


As the mailinglist software adds enough information to a josm-dev-mail, 
automatic filtering still should be easy, e.g. using the List-Id header.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] JOSM question

[Dirk Stöcker]

On Tue, 26 Apr 2016, EthnicFood IsGreat wrote:


I have a custom paint style that I use.  Recently I changed the name
of my style.  Now in the JOSM preferences, display settings, colors,
my custom colors are duplicated—they are all listed under my old style
name, and also all listed under my new name.  I wanted to delete the
old ones, but the Remove button is always grayed out, even if I select
one.  How do I get rid of the duplicate listings?


Are you sure the old style is really disabled? As far as I remember you 
only can delete unused colors.



BTW, this is my first post to this list.  Is this the appropriate list
for this question?


For questions yes. In case it is a bug the bugtracker will then be the 
right place.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] i18n for release

[Dirk Stöcker]

On Tue, 26 Apr 2016, Paul Hartmann wrote:

what are the required steps for i18n update before a release? Is it enough to 
do the following?


$ cd josm/i18n
$ ant updatecore
$ svn ci ../core


Yes. That's one of the possibilities.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] GSoC application for JOSM core

[Dirk Stöcker]

On Fri, 18 Mar 2016, Michael Zangl wrote:


Those are the tasks I identified and of which I think that they can fill
a summer - a lot of the work will be required for backward
compatibility, testing and fixing bugs.
https://docs.google.com/document/d/1CfGQBtsTljYg0N56sjeomZVRPTasyLoaAqVgbwDmzKs/edit?usp=sharing


You're sure this only fills a summer?


I am pretty sure I won't get even close to what I personally would like
to do, but it should be a good starting point.


Students - Estimated times are always so optimistic. Reality usually 
multiplies that by 3 or more ;-)


From the document above it's fine to have multiple goals, but I think you 
should group that into

 * must be reached
 * should be reached
 * nice to have
so that in case of short time you can focus more on the important parts.

Also keep in mind that the constant integration approach means that you 
have to write code which will or may be dropped in later steps of the 
development again.



Nice to hear. I am worried most about breaking plugins, especially the
ones that do not use the documented API but assume some internal state
of JOSM. I won't be able to test them all or even know of them.


JOSM has no stable API. This is a design decision which has advantages and 
drawbacks. Advantage is that plugins can do nearly everything. Drawback is 
that plugins do nearly everything. :-)


Our solution to this is that JOSM core comes first. We do what's 
necessary. If we break used APIs, then we fix the plugins in SVN (and 
github openstreetmap project). Plugins not in these repositories must be 
fixed by their authors.


We try to add deprecation warnings to ease this approach, but it's not 
required.


So: Caring for plugins is needed, but it should not stop necessary changes 
in the core.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] New Server

[Dirk Stöcker]

On Sun, 14 Feb 2016, Paul Hartmann wrote:


 I'll do the final switch of the server today approx between 17:00 and
 19:00 CET.

 Jenkins and Sonar probably will take a bit longer to work 100 %again,
 but all the major parts visible for users should be back at 19:00 CET.


Thanks for your server administration and communication with Hetzner (sponsor 
of our server for about 3 years)! Lots of work and little appreciation - the 
better you do the job, the less people notice... :)


Do not forget Vincent, who did and does help a lot!

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] New Server

[Dirk Stöcker]

Hello,

I'll do the final switch of the server today approx between 17:00 and 
19:00 CET.


Jenkins and Sonar probably will take a bit longer to work 100 %again, but 
all the major parts visible for users should be back at 19:00 CET.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] Latest josm seems to be crashing Xorg

[Dirk Stöcker]

On Tue, 9 Feb 2016, ael wrote:


As I said before, my most recent attempts to submit tickets seemed
to silently fail.


That should not be the case. You either should get an error message or a 
new ticket is created. JOSM-Server is one of the most straight-forward 
servers I know and I try to keep it that way. No login or special 
procedure required for ticket submissions.


Only exception is SPAM slipping through - This is silently discarded by 
the admins, but I assume your tickets did not look like SPAM to an admin?


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

[josm-dev] New Server

[Dirk Stöcker]

Hello,

this year our server sponsor Hetzner was again so kind to supply a more 
powerful server for our always increasing needs. Thanks a lot to them for 
the powerful and stable hardware and the sponsoring.


We will move the server somewhen in the next 2 weeks, probably this 
weekend. Outage time may be 1 or 2 hours.


I'll try to announce it when final move is coming.

To give you an indication what the server does currently, here some stats. 
Compare them to same mail from last year in February :-)


Somes Google stats from December:
HTTPS clicks:8.719
HTTPS impressions:   181.268
HTTP clicks: 591
HTTP impressions:31.554
Links to the webpage:3.175.115 (1.203.477 not from openstreetmap.de)

Server-Monitoring (AWStats) Dezember 2015:
Visitors:70.313
Visits:  191.347
Pages:   2.792.029
Accesses:4.422.137
Transmitted bytes:   287.77 GB

We get about 2600 submissions to the Trac webinterface each day, 99% of 
these are SPAM. Usually SPAM slips through very seldom and is deleted 
extremely fast.


All the numbers increased a bit and we now do mainly HTTPS instead of 
HTTP. I hope the new server will help with the resource requirements of 
jenkins and sonar which make the current one a bit slow ATM.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] DNS timeout/fail on startup

[Dirk Stöcker]

On Sat, 2 Jan 2016, Florian Lohoff wrote:


Just let the very first DNS request for josm.openstreetmap.org
fail/timeout - You get a popup "Network errors occured"
and "Change proxy setting". This is abolute nonesense. I dont
use any proxy - A simple DNS query failed - Thats life. I might
even be offline - that would be perfectly allright.


That's the standard dialog, as most issues are proxy settings. 
Improvements to the wording are always welcome.



I could use josm afterwards pressing cancel on the "Change proxy
settings" but i have situation where this does not work and
i cant up-/download data.


Either report a bug describing an issue or stop complaining about JOSM 
problems. You seem to have an instable network connection, but that's not 
our fault. It's not JOSM's task to fix your network.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] IPv6 problems

[Dirk Stöcker]

On Sat, 2 Jan 2016, Simon Legner wrote:


what about an expert (for now) option (such as prefer.ipv6=jvm) to
disable JOSM's algorithm completely and solely rely on the JVM to
figure out the correct way to connect to a server? According to [1] …

IPv6 in Java is transparent and automatic. Porting is not necessary; there is 
no need to recompile source files.


That text is a bunch of shit. Sorry :-)

It would be automatic when Java would follow the OS, but no, they needed 
to implement their own rules. And these rules say:

 * Always use IPv4 except for IPv6 only addresses or
 * Always use IPv6 except for IPv4 only addresses and
 * You need to choose before doing any network I/O.

Only thing automatic is that you don't need to use new functions and care 
for address format as you often need to do in C/C++.


So essentially we have three options
 * reimplement nearly the whole network stuff
 * don't use IPv6
 * use the testing approach and see what troubles users have.

Currently we use method 3 and adapted detection when necessary. The magic 
in JOSM tries to detect when IPv6 is usable and does fallback tp IPv4 when 
unsure. Current implementation is relatively reliable except for the 
mentioned corner cases. I'm willing to fix the detection when issues 
occur, but not for partially broken network providers. Users should issue 
complaints with their providers in these cases.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] IPv6 problems

[Dirk Stöcker]

On Sun, 3 Jan 2016, Simon Legner wrote:


On Sat, Jan 2, 2016 at 11:26 PM, Simon Legner  wrote:

what about an expert (for now) option (such as prefer.ipv6=jvm) to
disable JOSM's algorithm completely and solely rely on the JVM to
figure out the correct way to connect to a server?


I checked the code: This should already work w/o any code changes. Set
`prefer.ipv6` to `jvm` (or anything different from `auto` and `true`)
in the advanced preferences. If necessary, set one of the JVM system
properties [1].


That disables IPv6 usage and is identical to "false".

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] IPv6 problems

[Dirk Stöcker]

On Fri, 1 Jan 2016, Philip Homburg wrote:


- Ideally, operating systems should ship with a happy eyeballs implementation
 in the C library. I don't know any that does. It is not such a great idea
 for applications to roll their own. Mostly because you may want knobs to
 configure things system wide.


For C there probably are libraries.


- All applications should loop over all addresses returned by getaddrinfo.
 There is simply no excuse not to. If java makes it impossible to iterate
 over all addresses that it is java that is horribly broken.


I disagree here. ATM most services only have one IPv4 address. In the 
transition time between protocols many will have IPv4 AND IPv6 but in the 
near future (let's say 5-10 years) most will either have IPv4 OR IPv6 and 
dual stack will slowly fade out.


And it's not so easy to handle multiple connects. You can either optimize 
for speed (open multiple connections parallel) or for load (open one after 
the other) or ignore it (single connect) or randomly choose an address 
(e.g. what postfix does). All of these methods have advantages and 
disadvantages and depend on the application.


And it's not so easy to decide when a connection works or not, as it can 
fail on multiple levels and so on and so on. Many programs are extremely 
simple and implementing a full featured we-try-all network access is total 
overkill. So also in the future the majority of tools will only open one 
connection and try once. It's wishful thinking to assume otherwise.


For our company applications it took me a lot of time and experience to 
create a non-blocking non-threading portable C network library to cope 
with the many existing issues. I know how much work that involves both in 
the application and the libraries.


Thus the main question here is if parallel connects are important 
enough, so that JOSM needs to support that feature or not. Currently I 
think not.


We have a number of network issues with the Java network code beside the 
rather ugly IPv6 handling and maybe in the future we'll replace it with 
another library and maybe that will include algorithms for multiple 
connects. The question already came up in a recent ticket. But that's a 
lot of work and also does not magically solve all the problems.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] IPv6 problems

[Dirk Stöcker]

On Fri, 1 Jan 2016, Philip Homburg wrote:


It is really simple. An application should do nothing more than trying each
address in turn in the order returned by getaddrinfo. Either connect(2)
succeeds and you are done or there is a failure and you try the next address.


That does cause large timeouts in todays internet where packets are often 
dropped and not rejected. This is no option for JOSM in that easy 
configuration. To get it working an implementation must be more complex.



Trying only one address has been bad practice since before IPv6 was even
invented.


I disagree.


Of course, tweaking /etc/gai.conf to prefer IPv4 over IPv6 is also an option.
(Assuming java uses getaddrinfo under the hood)


Sadly Java does not follow this, but only has an option to say in advance 
whether IPv6 or IPv4 addresses should be preferred. And then it follows 
that rule ignoring the OS and the fact whether it works or not. And you 
cannot change this without a restart of the tool.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] IPv6 problems

[Dirk Stöcker]

On Fri, 1 Jan 2016, Simon Legner wrote:


I tried to find some reference implementations for the RFC6555 / Happy
Eyeballs in Java – without success. None of the popular HTTP client
libraries [1, 2, 3] seem to have any support for this algorithm.
Instead, they seem to attempt connections sequentially to the resolved
addresses [4, 5].


Beside browsers nearly no software uses Happy Eyeballs as far as I know. 
Most software only does a single connect for a single IP. Some rotate the 
IP's, so each attempt tries another one. Some try one after another and so 
on.


All of these multi-connect mechanisms are workarounds. E.g. what do you do 
when you have a bad setup, where IPv6 connection is fine, but goes to the 
wrong destination. When do you decide that IPv4 must be used in this case.


That was a scenario I did see some often years ago with umanaged IPv6 
setups and service moving to another server without changing also the IPv6 
address.


Opening a TCP connection can become extremely complex when you want to 
care for all the possible misconfigurations.


We did not add multi-connect attempts for IPv4 only networks, why should 
we do it now? All IPv6 cases we had until now have been clearly broken 
connectivity. We can spend a lot of time to hide these errors, but what's 
the result? Will the users fix their setup? No.


I know these issues from 8 years ago when I started support for IPv6. 
Broken setups, providers not monitoring outages of IPv6, broken routes, 
... It's 8 years later now! You can buy working IPv6 connectivity. I don't 
see such IPv6 specific errors anymore today. Hiding the errors which 
occur with other providers wont help in my eyes - only fixing them is 
right.


BTW the stats say: Google has 10% IPv6 now. We have about 2%. I'd say it 
works when I compare this to other HTTP based services which I run which 
are in the 0.x% range still.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] IPv6 problems

[Dirk Stöcker]

On Fri, 1 Jan 2016, Florian Lohoff wrote:


There are too few users with that specific issue to care for them
right now with an automatic approach.


Germany - Bigges Community - Largest ISP Telekom is switching all
DSL contracts to Dualstack. Kabel Deutschland is already handing
out IPv6 be default with DS Light. So within a very short timeframe
you'll see a lot more people complaining.


No. Because only a minority will walk between IPv6-enabled and IPv4-only 
networks.



Java does not support on-the-fly detection, but this setting must be
done before first network usage and cannot be changed later. We
can't change that behaviour. Feel free to submit a Java bug report.


There is no such thing as a on-the-fly detection. You as the application
author need to write the detection. You need robust "connect" logic
which tries ipv6 and falls back to ipv4 when the connect does not
work. The latest RFCs gives even more advice on how to work around
long delays induced by servers advertising ipv6 and not responding
to it or intermitted ipv6 problems e.g. packet loss in the v6 path. This
is the daily business for an ISP - You path are different for v4 than
for v6 so you have different latencys, paths, packet loss probabilities
etc.


As said: We don't provide Happy Eyeballs. WHY should JOSM try to resolve 
the issues of the ISP? Loss on the path, delays, ... are all ISP issues 
and have to be solved by the ISP. Happy eyeballs only hides them.


The only valid argument ATM is that JOSM needs one additional start when 
you switch from an IPv6 enabled network to a non-enabled network. That's a 
known bug. And as said the reason is that Java does not allow us to change 
behaviour after we did a first network connection. I'll check if we can at 
least auto-restart it in this case.



My user setup is continously broken and i work around it. YOU refuse
to even implement 20 year old Best Common Practices written in RFCs
for a good reason.


It's not my problem that you have a constantly broken setup. I have not. 
I use IPv6 for years now at home and in my company and all our internal 
traffic goes over IPv6 and I have no reasons for workarounds.


When I had IPv6 trouble then I contacted the ISP and they fixed it which 
in the end resulted in better monitoring on their side and less trouble.



http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.de/110207


Also this is a typical setup error. If someone accesses "localhost", then 
the tool also must listen on localhost which nowadays means IPv4 and IPv6 
otherwise the address must be 127.0.0.1 which is the IPv4 address for 
localhost.



Sorry - NO - I have a perfectly working ipv6 setup with German Telekom
at home. Even there i need workarounds with josm not falling back
to ipv4 with the tracer plugin.


Then contact the tracer author and tell him to fix his software and not 
to try to access illegal address. Either the tracer plugin must use 
127.0.0.1 only or the tracer tool itself must listen also on ::1.



EVERY single connection needs the fallback logic for itself without
cached prior knowledge of the environment.


No. It does not need this. No software does this for IPv4. Why should we 
do this for IPv6? To make IPv4/IPv6 transition smoother some people 
thought that IPv6 errors should be silently ignored. And what's the result 
- people like you assume that having errors is ok. IT IS NOT OK.



With mobility my ipv4 only connection can change to dualstack to dslight
to a pure ipv6 with 6to4 NAT back to ipv4. If my services are reachable
Dualstack there should be service everywhere. With JOSM the first
change in network environment needs an application restart.


As told multiple times this has technical reasons. Java does not allow to 
switch the handling of IPv6 after I did a single network access. I would 
be happy to have it like for all other tools which follow the OS 
preference, but that's not possible ATM. If you can't live with it, 
disable it. I don't rewrite the whole Java network stack only to satisfy 
your need for perfection.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] IPv6 problems

[Dirk Stöcker]

On Wed, 30 Dec 2015, Greg Troxel wrote:


I have been running JOSM for a long time, on a Mac, currently at OSX
10.7.  I have functional IPv6, but my tunnel is from OCCAID, and
occasionally some places are unreachable - currently
api.openstreetmap.org is one of them.

josm starts up and proclaims:

 INFO: Detected useable IPv6 network, prefering IPv6 over IPv4.


If you have a version older than 8706 you should update. If you have a 
newer one read the description below.



which is fine, but then when downloading data (simple pushing of
download icon, letting area be, and then pushing the download button in
the popup) normally, I get an API error.  I can ping
api.openstreetmap.org on v4, but not v6, where I get a network
unreachable in New York.  If I had a 2-minute delay and then a download,
there would be a more subtle happy eyeballs issue, but I totally failed
to download data a few hours ago.

Just now, I was able to download data.

So it seems that there is some notion of only trying one address family,
vs. trying all addresses in all familes in some sort order, and only
failing if all fail.

OSX itself has some version of Happy Eyeballs which uses RTT on v4 and
v6 to the address (prefix?) to decide which to try first, I think via
sorting getaddrinfo results.  I am totally unclear on how this interacts
with Java.


JOSM and Java do not try different protocols. If you (and the remote 
server) have IPv6 it uses IPv6, if not IPv4.


It seems you have a broken IPv6 connection which sometimes works and 
sometimes not. You should fix it.


Trying multiple connections can hide such broken connections, but most 
applications don't do this. Web browsers are the main exception. JOSM not.



This can likely be reproduced by configuring nonworking IPv6.


No. JOSM verifies if IPv6 works by testing one IPv6 connection (to JOSM 
server). Thus it can detect whether IPv6 works or not.


But it cannot detect a partially broken connection and I also don't plan 
to do something about this. This must be fixed on user side.


To get JOSM working with your setup set expert option "prefer.ipv6" to 
"false". That simply disables IPv6.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] IPv6 problems

[Dirk Stöcker]

On Thu, 31 Dec 2015, Florian Lohoff wrote:


I disagree on that. The fallback to v4 should be per CONNECTION and
not per application restart. The RFCs are pretty clear on this
and further behaviour improvements on intermitted ipv6 connectivity.


We had the same discussion already here. Most of the arguments are there 
already.


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


JOSM is a pain in the ass concerning ipv6. I typically roam with my
notebook between dualstack and ipv4 only locations with suspend/resume
and most of the time i need to save session restart josm etc.
Its not even deterministic what the error looks like it just
complains on some random network access ...


If you switch between such networks disable IPv6 with "prefer.ipv6" set 
to "false" or use a start script to set correct settings.


There are too few users with that specific issue to care for them right 
now with an automatic approach.


Java does not support on-the-fly detection, but this setting must be done 
before first network usage and cannot be changed later. We can't change 
that behaviour. Feel free to submit a Java bug report.



Trying multiple connections can hide such broken connections, but
most applications don't do this. Web browsers are the main
exception. JOSM not.


So you are clearly not adhearing to BCPs for dual stack application
development. There has to be a fallback to ipv4 for every single
connection attempt not just once we restart the application.


We also do not fallback to secondary IPV4 addresses and so on and so on. 
Happy Eyeballs is a feature and we don't have that feature.



Just one of the most recent RFCs making this very clear that
intermitted ipv6 connectivity is a common case and needs to be
worked around in the application:

https://tools.ietf.org/html/rfc6555


Don't know where you find the statement in the RFC above. Problems in 
section 3 of the document still have to be fixed, the document itself 
provides only a workaround to "enjoy nearly identical performance" even 
without fixing the problems. Time advanced since 1994 where the first 
statement from section 3 comes and also since 2012 where the RFC was 
written. I see no sense in spending lots of work on fixing broken user 
setups. If you can convince Java to support IPv6 better and switching 
during runtime, we'll use it. Otherwise we expect users to use proper 
networks settings.



I used to work in the ISP Business for 15 years and applications
like JOSM are the main hinderance for ipv6 acceptance.


For me the main problem are ISP's which provide broken or no IPv6 
connectivity.


If a provider has broken IPv4 connectivity and does not route to certain 
parts of the internet users will switch to another provider very soon. 
That's a provider issue.


Same is true for IPv6 - only that here the application should be the 
problem?



"It does not work when i enable ipv6" is the customer complaint
so ipv6 is kept turned off.


Correct answer would be "so I use another provider where it works".

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] IPv6 problems

[Dirk Stöcker]

On Thu, 31 Dec 2015, Greg Troxel wrote:


I should clarify: My IPv6 setup is working fine.  The problem is that my
upstream ISP has routes to most parts of the v6 world but is missing a
few, I'm guessing due to a peering dispute.  This is the same sort of
thing that can happen in v4, although I think it is less common.  So
this is a "internet connectivity problem in the core", not setup issues
on my end.


Actually that's what I would call a broken IPv6. If that happens for IPv4 
you would switch to another provider. For IPv6 you assume the application 
should fix it. JOSM does not offer that feature due to the missing support 
for this in main Java and not enough reasons to reimplement that 
ourselves.


Another solution compared to disabling IPv6 totally would be to add the 
IPv4 addresses of the non-working servers to your /etc/hosts (path correct 
for Mac?). This changes the resolvers answers, so JOSM will not know that 
these serves have IPv6 and also not try it for these, but for all the 
others.


Anyway the correct solution would be to get your provider to fix the 
routing or change provider.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] SunCertPathBuilderException

[Dirk Stöcker]

On Tue, 15 Dec 2015, Stephan Knauss wrote:

I hadn't checked the certificate store yet, but could it be that the server 
has to include an intermediate certificate? So not the complete chain is 
delivered? This would explain the failure.


Cert chain is/was complete. It seems Java still does not include StartSSL, 
but Unix versions and browsers use the system certstore. So standalone 
non-Unixes fail. All others work.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] SunCertPathBuilderException

[Dirk Stöcker]

On Tue, 15 Dec 2015, Stephan Knauss wrote:


Dirk Stöcker writes:

Cert chain is/was complete. It seems Java still does not include StartSSL, 
but Unix versions and browsers use the system certstore. So standalone 
non-Unixes fail. All others work.


probably you wanted to say WOsign here, but yes, neither that, nor Startcom 
nor IdenTrust (for Let's Encrypt) is included in the Java store.


No. Really StartSSL. Wosign main cert is signed by StartSSL and I always 
supply the whole chain from Intermediate, Wosign main to StartSSL 
(although e.g. Firefox has all of these 3 already included).


Just to have it as a reference in the mailing list archives: In the support 
forum Let's Entrypt said they had applied to be included in Oracles cacert 
list. So hopefully for the next renewal we'll have a better alternative.


As far as I know StartSSL also tried and had no success till now and 
probably gave up.


This is the command to dump the contents of the certificate store to see 
whether a specific CA is included.


Well I use Linux and here it worked.

The last time I used Windows was when I wanted to update my Windows 8 to 
10. Took 2 days and the result is a broken OS (at least it booted once) 
and I will now expand my Linux partition and drop Windows completely. 
Still have an older Vista in a VM for seldom use. :-)


Ciao
--
http://www.dstoecker.eu/ (PGP key available)
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] SunCertPathBuilderException

[Dirk Stöcker]

On Tue, 15 Dec 2015, Blake Girardot wrote:


There are 3 or 4 "me too's" now on that talk-us thread.

Some people are providing the info you asked for.

The "me too's" start here:

https://lists.openstreetmap.org/pipermail/talk-us/2015-December/015785.html

and the "next message" link should take you through the rest of the reports.


Switched back to Globalsign for now, but actually I don't see why it 
sometimes works and why sometimes not.


Seems Java with Windows 7 does not work, Java with Windows 7 in browser 
works. Then we have to wait until Windows 7 dies to use it and renew 
Globalsign.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

[josm-dev] JOSM Server certificate

[Dirk Stöcker]

Hello,

today I switched our server certificate from Globalsign to Wosign. Works 
fine on my Linux systems also with Java.


Could others please test and report if there are Java versions rejecting 
the certificate.


If we have trouble we need to apply for a new Globalsign certificate, 
which is much more effort than Wosign.


The old certificate is still valid till end of December, so there is still 
a little time.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] SunCertPathBuilderException

[Dirk Stöcker]

On Mon, 14 Dec 2015, Blake Girardot wrote:

I am just forwarding this as I saw the note about changing the server 
certificate and thought this might be relevant. I realize it is not a very 
helpful report, but if it is relevant, we could follow up with him to get 
more information.


Yes. Is relevant. I need OS, JOSM version and Java version. Could you 
please ask for it?


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] Renaming a validator rule

[Dirk Stöcker]

On Mon, 14 Dec 2015, Nelson A. de Oliveira wrote:


How feasible it is to rename a validator rule in
https://josm.openstreetmap.de/wiki/Rules ?


Not a good idea.


Technically, can rules be renamed?


Yes.

People who use the current rules will stay with an outdated rule forever 
if it gets renamed?


Yes.


Is there a way to force users migrating from one rule to another one?


I think if the old URL vanishs completely some weeks later they will get 
an error, but I'm not toally sure. Also don't know if that error can be 
skipped or results in dropping the old rule. It's somewhere in the 
caching code :-)


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] Renaming a validator rule

[Dirk Stöcker]

On Mon, 14 Dec 2015, Nelson A. de Oliveira wrote:


Technically, can rules be renamed?


In my last mail I talk about the whole rule and wiki page. It's no issue 
to simply change the "title" of the rule if that helps.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] GeoJSON can be written but not read?

[Dirk Stöcker]

On Tue, 10 Nov 2015, Ian Dees wrote:


I wrote a plugin a long time ago to draw GeoJSON in JOSM, but JOSM broke
its API enough times that it no longer works.


That's the reason why we recommend to develop in OSM-SVN instead of own 
places, as in SVN we care for necessary updates.


https://josm.openstreetmap.de/wiki/DevelopersGuide/DevelopingPlugins#Publishingaplugin

Don't complain about your own decision especially as this plugin was never 
added to the list of JOSM plugins.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] GeoJSON can be written but not read?

[Dirk Stöcker]

On Wed, 11 Nov 2015, Ian Dees wrote:


I wrote a plugin a long time ago to draw GeoJSON in JOSM, but JOSM broke

its API enough times that it no longer works.


That's the reason why we recommend to develop in OSM-SVN instead of own
places, as in SVN we care for necessary updates.


You're saying that you update plugins on behalf of authors if they're in
the SVN repository?


We keep plugins in working shape. Don't know what you mean by "on behalf". 
JOSM is a community projects which means multiple people are working on 
it. The author mentioned in the manifest usually is the main or first 
author and thus gets credit for that. In nearly no case it is the only 
author.


For people who can't accept that model there are these other methods. Each 
author can decide which of the options he chooses and has to accept the 
drawbacks.



It's such a joy trying to participate in the JOSM developer community.


It should be clear that I do not believe that you do or did participate in 
the JOSM developer community. When you do something you always choose your 
own way.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] GeoJSON can be written but not read?

[Dirk Stöcker]

On Wed, 11 Nov 2015, Paul Wölfel wrote:


There's also a github Project Group for JOSM (https://github.com/JOSM) and
my plugin areaselector (https://github.com/JOSM/JOSM-areaselector) is being
developed under that group. The project is included in the JOSM source as
svn:external and collaborative developing works great! I.e. Vincent updated
the plugin to work with log2 and updates the language file very often!

It might help, if you transfer your project on github to the JOSM group, so
more people can help to keep your plugin up to date!


For the GitHub project apply the same rules :-)

I added a note about this account to the plugin development page, so it 
is no longer secret knowledge.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] Translation discussions

[Dirk Stöcker]

On Sun, 18 Oct 2015, Holger Mappt wrote:

would be good, I think Transifex supports that. Dirk, do you still work on a 
Trac based system? Will it support translation discussions? To be able to 
discuss the source string would be good too.


A little. It's still my goal. I hope I have some time for this in the 
holidays end of the year.


same issue? Should we change more source strings to improve the translation 
process? Or is it good as it is?


Clearly a YES, as currently nearly no feedback goes into the source 
strings :-)


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] JOSM Version check source (VersionTest macro) to troubleshoot strange version

[Dirk Stöcker]

On Fri, 9 Oct 2015, Sebastiaan Couwenberg wrote:


No. As you mark it as Debian in the agent it's correct to strip the SVN
text. This patch as far as I remember was designed in cooperation with
me. For SVN we react different in tickets - We tell the user first to
update to recent SVN version assuming the user can build the software
himself. This is not the correct reply for Debian version, so the SVN
should not be there. Simply change the patch to set "Debian" instead of
"SVN", as I see that there is no patch in the GIT yet for this purpose.


Based on the bug report and your changes to the VersionTest macro, it
seemed the patch may have been unneeded in the first place.

I prefer the User-Agent without SVN substring anyway, so I'll happily
keep it for the Debian package.

The Debian Build-Name change is currently only available in the
00-build.patch on the stretch branch:

https://anonscm.debian.org/cgit/pkg-grass/josm.git/tree/debian/patches/00-build.patch?h=stretch#n57


Hmm, maybe these two together need some rework. If you simply change 
Is-Local-Build (above the Build-Name) to false the patch to Version.java 
can be dropped and manifest is more correct.


Removing SVN from the other line in build.xml is probably still required 
(we don't use build.xml but a makefile on the server). But I'd include 
that single change in your 00-build.patch for better readability.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] JOSM Version check source (VersionTest macro) to troubleshoot strange version

[Dirk Stöcker]

On Fri, 9 Oct 2015, Sebastiaan Couwenberg wrote:


Is the source for the JOSM Version check, the VersionTest macro used in
StartupPageSource wiki, available somewhere?


Yes. But not public :-)


It currently is unable to handle the version used for the Debian package
which is reported as a strange version:

'8159 Debian nl) Linux Debian GNU/Linux unstable (sid'

This was triggered by the addition of the Build-Name property to better
identify the Debian builds.


Works now? Please check that it checks against tested and does not tell to 
update unless there's really a newer one. SVN version already tell you 
to update when a new latest is there.



I suspect that the VersionTest regex doesn't support the use of the
Build-Name property.


Nah, it was hardcoded to only "SVN". Sometimes it seems brain is turned 
off when writing such code.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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

Re: [josm-dev] JOSM Version check source (VersionTest macro) to troubleshoot strange version

[Dirk Stöcker]

Hello,

Works now? Please check that it checks against tested and does not tell to 
update unless there's really a newer one. SVN version already tell you to 
update when a new latest is there.


Need to correct me. For SVN it only tells you to update when you are least 
50 versions behind. So it can't be tested ATM, as tested to latest diff is 
only 40.


Ciao
--
http://www.dstoecker.eu/ (PGP key available)

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