Re: JOSM developers meetup at Karlsruhe?

[Wiktor Niesiobedzki]

pon., 15 paź 2018 o 13:46 Dirk Stöcker 
napisał(a):
>
> 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.

That's really a shame, I really hoped for your presence at meetup though I
had misinterpret your earlier declaration. We will miss you there.

Cheers,

Wiktor

Re: JOSM developers meetup at Karlsruhe?

[Wiktor Niesiobedzki]

Hi,

maybe less working on, but I'd like to discuss controversial tickets:
https://josm.openstreetmap.de/ticket/16420
https://josm.openstreetmap.de/ticket/8269

I hope that face to face discussion may move us forward.

Cheers,

Wiktor

On Sun, 14 Oct 2018 at 19:27, Michael Zangl 
wrote:

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

Re: JOSM developers meetup at Karlsruhe?

[Wiktor Niesiobedzki]

Hi,

Sounds like a great plan. I'd love to meet you. Count me in.

Cheers,

Wiktor

2018-09-03 23:31 GMT+02:00 Florian Schäfer :

> Hi Vincent,
> great idea, I think I'd most definitely stop by.
> I'm not yet sure if I'll have the time to participate in hacking on that
> weekend, but at least for a JOSM meetup I would join you in Karlsruhe.
>
> Cheers,
> Flo(scher)
>
>
> Am 03.09.2018 um 22:36 schrieb Vincent Privat:
>
>> Hello,
>> I was thinking for quite some time about setting up a meeting between JOSM
>> developers somewhere in Germany (for convenience).
>> As Christine and Frederik are inviting OSM developers to Karlsruhe on
>> October 20th-21st, I just registered myself!
>> Would other team members be interested? I'd love to meet everyone in
>> person!
>> As for JOSM projects/activities for this hack week-end, there are plenty
>> of
>> them to work on, it will depend on who's there :)
>> Cheers,
>> Vincent
>>
>
>
>

Re: The (dark) future of Java on desktop

[Wiktor Niesiobedzki]

My reading of this Oracle post is that is to actually change the way you
ship the applications. Instead of relying on JRE installation on client
station - ship your code bundled with JRE as jlink does (and take care
about all the updates yourself).

Anyway I guess that we can assume that number of end-user installations of
JRE will be shrinking, so shipping JRE together with your application might
be already a good idea. We should watch what Eclipse will do about it (and
all the commercial tooling based on Eclipse). My guess is that they will
not give up on it so easily.

It means then that we need to cover all platforms in our build system. This
would be the case also whatever programming language we will take.

If JOSM were to abandon Java as a language maybe we should think about
extending/repackaging/repurposing QGis? I guess that probably there were
such ideas in the past?

Cheers,

Wiktor

2018-03-08 19:07 GMT+01:00 Vincent Privat :

> WebStart is going away. It is the only part of Java that isn't open source
> and they explicitely stated they won't open source it:
> https://twitter.com/DonaldOJDK/status/971492781616136194
>
> So at least starting from September we'll have to make the WebStart link
> less prominent as it won't work anymore for Windows and macOS users having
> their Java up-to-date. It will work natively only on Linux, where openjdk
> package includes the retro-engineered free version of WebStart
> (netx/icedtea-web):
> https://icedtea.classpath.org/wiki/IcedTea-Web
>
> I don't know if the few (single?) people behind IcedTea-Web will have the
> desire to maintain it after Oracle drops it from JDK. I don't know either
> if icedtea-web requires jar signing: maybe we will be able to drop the
> requirement to sign josm.jar, thus asking to Frederik to pay for the
> certificates ;)
>
> JavaFX will be given to someone else soon. Maybe the Eclipse Foundation,
> like Java EE which has be transferred to Eclipse, without the permission to
> call it Java EE anymore. Or maybe the Apache Foundation, where they already
> made OpenOffice and Hudson die there (given that they have been
> successfully forked as LibreOffice and Jenkins).
>
> AWT and Swing will still be here in Java 11. But the fact they mention it
> explicitely today probably means they have plans to remove it as soon as
> Java 12 development starts (in 6 months). I have no idea if the new project
> will create enough traction to have enough contributors (volunteers or pais
> staff from other companies), we'll see. Swing is still used a lot in the
> industry. At least we should be able to fix Swing bugs ourselves when we
> find ones.
>
> Concerning JOSM it means we will probably have to ship AWT, Swing and
> JavaFX in josm.jar. In JDK9 the desktop module (AWT+Swing) weights 13Mb,
> the various JavaFX modules 30Mb. JOSM jar is only 12Mb today.
>
> Cheers,
> Vincent
>
> 2018-03-08 11:19 GMT+01:00 Dirk Stöcker :
>
> > On Thu, 8 Mar 2018, Dirk Stöcker wrote:
> >
> > [nothing]
> >
> > Sorry, operator error :-)
> >
> >
> > Ciao
> > --
> > http://www.dstoecker.eu/ (PGP key available)
> >
>

Github mirror not updated

[Wiktor Niesiobedzki]

Hi,

It looks like GitHub mirror of OSM is not updated any more. Last
update was on 21st of October.

What needs to be done to bring this service up?

Or shall I just setup my own sync service with my JOSM GitHub mirror?


Cheers,

Wiktor

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

Re: How-To Progress Monitor

[Wiktor Niesiobedzki]

Hi,

I guess that you may find
org.openstreetmap.josm.gui.layer.gpx.DownloadWmsAlongTrackAction
helpful. This is the class that downloads WMS along GPX track. Let me
give you a short guide around the code:

PrecacheWmsTask is the class that is executed in background. The task
is submitted to background thread for execution as:
Main.worker.execute(task);

It means that task is executed in one shared background thread across JOSM.

PrecacheWmsTask.realRun method implements, what needs to be done in background.

To implement user friendly Progress Monitor you can do as follow:
use: progressMonitor.setTicksCount(int) to set how many units of work
(ex. images) you have at the begging of realRun()
and then, when unit of work is done, use progressMonitor.worked(1) to
notify, that one unit is already done (ex. one image is processed)

You should also watch progressMonitor.isCancelled() to shut down your
background work if user cancels it.

I guess this has helped you.

Cheers,

Wiktor


2016-10-22 17:07 GMT+02:00 Holger Mappt :
> Hi,
>
> I'm writing a plugin that processes a number of images after a menu item was
> selected.  What is the right way to do that in a way that doesn't block the
> GUI with an indication of the progress?  I guess I have to run some kind of
> task that updates the progress after every image.  Then some GUI component
> displays a progress bar (with an optional cancel button).  I implemented
> something that is based on javax.swing.ProgressMonitor and
> javax.swing.SwingWorker according to the code sample from the Java tutorial
> (https://docs.oracle.com/javase/tutorial/uiswing/examples/components/ProgressMonitorDemoProject/src/components/ProgressMonitorDemo.java),
> but it's not working.  The progress window opens after the 101st image and
> then blocks the execution of the task.
>
> What is the recommended JOSM way to do that?  Is there a good example where
> I can learn from?  JOSM has a ProgressMonitor interface and some classes
> that implement it, but there is no documentation and the plugins I looked at
> are quite complex with an endless chain of subroutines.  Any help is
> appreciated.
>
> Thanks,
> Holger
>
> ___
> josm-dev mailing list
> josm-dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/josm-dev

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

Re: [josm-dev] JDK 9 EA build 105 is available

[Wiktor Niesiobedzki]

Rory,

One question though, is this fix something, that could you could also
consider including in Java 8? We need to plan, how and when to phase
out our work-around code.

Cheers,

Wiktor

2016-02-15 20:02 GMT+01:00 Wiktor Niesiobedzki <o...@vink.pl>:
> Hi Rory,
>
> I can confirm, that the fix is working and I see now all the header
> fields returned.
>
> Thank you very much for the fix.
>
> Cheers,
>
> Wiktor
>
> 2016-02-15 19:22 GMT+01:00 Rory O'Donnell <rory.odonn...@oracle.com>:
>>
>> Hi Vincent,
>>
>> Early Access b105 <https://jdk9.java.net/download/> for JDK 9 is available
>> on java.net, it includes a fix for :
>>
>>  * JDK-8146450 : Java Web Start resource cache doesn't store all HTTP
>>response headers
>>
>> Can you confirm fix is working.
>>
>> Thanks,Rory
>>
>> --
>> Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA , Dublin, Ireland
>>
>> ___
>> josm-dev mailing list
>> josm-dev@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/josm-dev

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

Re: [josm-dev] JDK 9 EA build 105 is available

[Wiktor Niesiobedzki]

Hi Rory,

I can confirm, that the fix is working and I see now all the header
fields returned.

Thank you very much for the fix.

Cheers,

Wiktor

2016-02-15 19:22 GMT+01:00 Rory O'Donnell :
>
> Hi Vincent,
>
> Early Access b105  for JDK 9 is available
> on java.net, it includes a fix for :
>
>  * JDK-8146450 : Java Web Start resource cache doesn't store all HTTP
>response headers
>
> Can you confirm fix is working.
>
> Thanks,Rory
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
> ___
> josm-dev mailing list
> josm-dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/josm-dev

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

Re: [josm-dev] Build without apache-commons-jcs?

[Wiktor Niesiobedzki]

Hi,

We had already such discussion some time ago:
https://lists.openstreetmap.org/pipermail/josm-dev/2015-June/007377.html

The result is, that it's really hard for us to provide working JOSM
without JCS. As far as our build are concerned, we totally ignore most
of JCS build dependences, and left only log4j (IIRC). But - if you
would like to provide full apache-commons-jcs, then you indeed need to
have all of this build available.

But I find it hard to believe that EHEL doesn't contain log4j for example.

Cheers,

Wiktor

2016-01-16 17:39 GMT+01:00 Matěj Cepl :
> Hi,
>
> I am trying to build JOSM rev9329 on RHEL-7 and it fails on
> missing apache-commons-jcs
> (http://koji.fedoraproject.org/koji/taskinfo?taskID=12577054).
> Unfortunately, build that in EPEL-7 seems to be quite
> complicated (see the list of missing dependencies in
> https://kojipkgs.fedoraproject.org//work/tasks/6502/12576502/root.log),
> so I would like to ask whether it could be possible to build
> JOSM (perhaps with a bit degraded performance) without that. It
> is just some kind of cache, isn't it?
>
> Best,
>
> Matěj Cepl
>
> --
> https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
> GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
>
> The law, in its majestic equality, forbids the rich as well as
> the poor to sleep under bridges, to beg in the streets, and to
> steal bread.
> -- Anatole France
>
>
> ___
> josm-dev mailing list
> josm-dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/josm-dev

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

Re: [josm-dev] Image extraction from TMS cache

[Wiktor Niesiobedzki]

Hi Holger,

If you use josm code, there is a directory locking code, that prevents
from accessing cache simultaneously from different processes, as they
do not share memory structures that store current disk file layout and
may lead to corrupted reads/writes. So you should have JOSM shut down
first, before extracting the PNG.

There is no information stored about original file format. But you can
try to extract CacheEntry objects, which getContent() should return
original file content. But you will need to do file format
identification by your self using "magic" (like file), as uses this
magic to identify file format.

Cheers,

Wiktor

2015-12-20 18:33 GMT+01:00 Holger Mappt <holger...@gmx.net>:
> Hi,
>
> I re-package josm-latest.jar into my cachextractor.jar to have a self
> contained archive. I missed to copy data/preferences.xsd, which killed my
> JOSM preferences. Now I copy directory data in addition to **/*.java and the
> cache read works.
>
> What do I need to do to shut down JOSM if it was started with the functions
> in JOSMFixture.init() (no GUI mode)? Looks like there is a background
> process. I call System.exit(0), but I would like to stop all running
> processes first.
>
> The other thing that caused me some headache was the export disk file
> format. The old cache that wrote tile files to disk wrote *.png files. I
> tried different PNG writers, but my files were always about 8 times bigger.
> It took me some time to figure out that even JPEG files were written with
> the .png file name extension. Now I save the tiles as JPEG and everything is
> fine. Does the current cache have information about the original tile file
> (format, data)?
>
> Regards,
> Holger
>
>
> Am 12.12.2015 um 20:09 schrieb Wiktor Niesiobedzki:
>>
>> As for your problem - this is kind of the problem we face also writing
>> the unit tests. It is solved by calling:
>> org.openstreetmap.josm.JOSMFixture.createUnitTestFixture().init();
>>
>> Though keep in mind, that this is part of the testing code, so it's
>> located here:
>>
>> http://josm.openstreetmap.de/browser/josm/trunk/test/unit/org/openstreetmap/josm/JOSMFixture.java
>>
>> This should give you a hint, how to initiate "headless" mode.
>>
>> Cheers,
>> Wiktor
>>
>> 2015-12-12 18:52 GMT+01:00 Holger Mappt:
>>>
>>> My idea was to write a small program that calls TMSLayer.getCache() to
>>> get
>>> the TMS cache. But to do that I need to initialize JOSM (preferences, TMS
>>> layer, and tile cache). How would I do that? Is there something like a
>>> headless mode where I can hook into? I tried to call some of the
>>> initialization methods, but there are too many dependencies and I would
>>> need
>>> a running JOSM to make that work.

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

[josm-dev] [HEADSUP] Changes to AlignImageryPanel - https://josm.openstreetmap.de/wiki/Maps review needed

[Wiktor Niesiobedzki]

Hi,

I've just committed a fix for bug: #12034. Part of the solution is to
make the AlignImageryPanel "do not show again" setting to be per
imagery source, as well as - provide the ability in the maps
definitions to mark the imagery source as properly
georeferenced/aligned.

This is something what I've heard from people working with newbies on
OSM/JOSM, that saying to the users "and ignore this message" is not
good when they do work with good imagery source, but it is something,
that should be reminded later, when someone for example opens Bing.

As for now, we do not mark, if imagery source is properly aligned or
not - I'm asking you to review the imagery sources on:

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

Re: [josm-dev] [HEADSUP] Changes to AlignImageryPanel - https://josm.openstreetmap.de/wiki/Maps review needed

[Wiktor Niesiobedzki]

Hi,

I've just committed a fix for bug: #12034. Part of the solution is to
make the AlignImageryPanel "do not show again" setting to be per
imagery source, as well as - provide the ability in the maps
definitions to mark the imagery source as properly
georeferenced/aligned.

This is something what I've heard from people working with newbies on
OSM/JOSM, that saying to the users "and ignore this message" is not
good when they do work with good imagery source, but it is something,
that should be reminded later, when someone for example opens Bing.

As for now, we do not mark, if imagery source is properly aligned or
not - I'm asking you to review the imagery sources on:
https://josm.openstreetmap.de/wiki/Maps

And mark those, which are properly aligned with additional tags:

true


I've already made necessary changes for Maps/Poland, as it was easy
for me to verify quality of these source.

Cheers,

Wiktor

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

Re: [josm-dev] Renaming a validator rule

[Wiktor Niesiobedzki]

2015-12-14 20:16 GMT+01:00 Dirk Stöcker :
> On Mon, 14 Dec 2015, Nelson A. de Oliveira wrote:
>> 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 :-)

As far as my experience goes, failure to download fresh rule will
result in using old file until it's cached version is removed.

Though CachedFile:448 indicates, that should be the case only for two
weeks (using default maxAge), but that's not what I've experienced
when some validator rules were moved.

Cheers,

Wiktor

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

Re: [josm-dev] Image extraction from TMS cache

[Wiktor Niesiobedzki]

Hi,

Your cache was reset probably due to this change:
http://josm.openstreetmap.de/changeset/9064/josm

We moved from IndexedDiskCache do BlockDiskCache.

As for your problem - this is kind of the problem we face also writing
the unit tests. It is solved by calling:
org.openstreetmap.josm.JOSMFixture.createUnitTestFixture().init();

Though keep in mind, that this is part of the testing code, so it's
located here:
http://josm.openstreetmap.de/browser/josm/trunk/test/unit/org/openstreetmap/josm/JOSMFixture.java

This should give you a hint, how to initiate "headless" mode.

Cheers,

Wiktor

2015-12-12 18:52 GMT+01:00 Holger Mappt :
> My idea was to write a small program that calls TMSLayer.getCache() to get
> the TMS cache. But to do that I need to initialize JOSM (preferences, TMS
> layer, and tile cache). How would I do that? Is there something like a
> headless mode where I can hook into? I tried to call some of the
> initialization methods, but there are too many dependencies and I would need
> a running JOSM to make that work.
>
> Does it work to write a plugin that can be called from the command line, but
> without the GUI?
>
> The other option is to re-implement the tile cache code without some of the
> dependencies. That seems to be a lot of work. It needs modifications every
> time the JOSM tile cache is modified.
>
> BTW, was the tile cache code modified recently? My cache was reset (erased)
> yesterday.
>
> Holger
>

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

Re: [josm-dev] WMTS scales - proper definition of 1m along meridian

[Wiktor Niesiobedzki]

2015-07-04 22:33 GMT+02:00 Wiktor Niesiobedzki o...@vink.pl:
 2015-07-02 23:57 GMT+02:00 Paul Hartmann phaau...@gmail.com:
 On 02.07.2015 23:33, Wiktor Niesiobedzki wrote:


 I think it should go into the data/epsg file. The normal epsg file for Proj4
 contains this info, e.g.:
 # ATS77 / UTM zone 19N
 2219 +proj=utm +zone=19 +a=6378135 +b=6356750.304921594 +units=m +no_defs
 

 (The +units=m part)

 The format is explained here:
 https://github.com/OSGeo/proj.4/wiki/GenParms

 Thank you very much. That was exactly what I need. I'll update the
 epsg file with definitions of units and to_meter, as well as add
 support for this values in CustomProjection.

Ok,

After more twiddling with WTMS I found some other challenge regarding
EPGS - natural coordinate order, examples:
4326  - Axes: latitude, longitude. Orientations: north, east
2180  - Axes: northing, easting (x,y). Orientations: north, east
3857  - Axes: easting, northing (X,Y). Orientations: east, north
31370 - Axes: easting, northing (X,Y). Orientations: east, north.

Those above are taken from:
http://www.epsg-registry.org/

As you can see, there are some projections, where coordinates are
switched, and some, when they are not. My guess is maybe this could be
defined by setting axes=neu or axes=enu, as described in proj.4

But I do not see this extensively used in proj.4/nad/epsg
(https://github.com/OSGeo/proj.4/blob/master/nad/epsg) - only 28
entries with wsu value.

Do you think that we can induce this value from some other information
from our epsg file, or shall I add this information to our projection
definition?

Cheers,

Wiktor

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

Re: [josm-dev] WMTS scales - proper definition of 1m along meridian

[Wiktor Niesiobedzki]

2015-07-02 23:57 GMT+02:00 Paul Hartmann phaau...@gmail.com:
 On 02.07.2015 23:33, Wiktor Niesiobedzki wrote:


 I think it should go into the data/epsg file. The normal epsg file for Proj4
 contains this info, e.g.:
 # ATS77 / UTM zone 19N
 2219 +proj=utm +zone=19 +a=6378135 +b=6356750.304921594 +units=m +no_defs
 

 (The +units=m part)

 The format is explained here:
 https://github.com/OSGeo/proj.4/wiki/GenParms

Thank you very much. That was exactly what I need. I'll update the
epsg file with definitions of units and to_meter, as well as add
support for this values in CustomProjection.

Cheers,

Wiktor

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

[josm-dev] WMTS scales - proper definition of 1m along meridian

[Wiktor Niesiobedzki]

Hi,

Currently I'm working on WMTS support. As some of you may know (and
those who do not, I refer to
http://www.opengeospatial.org/standards/wmts) uses notion of
scaleDenominator that's crucial to tile positioning. More less -
scaleDenominator tell how many meters are on the tile per pixel.

I tried several of algorithms to get the number of meters along
meridian for current JOSM projection, the best I could find is:

Projection proj = Main.getProjection();
EastNorth p1 = new EastNorth(0, 0);
EastNorth p2 = new EastNorth(0, 1);
double metersPerDegree =
proj.eastNorth2latlon(p1).greatCircleDistance(p2);

But still this doesn't give satisfactory results. From my manual
trials, I guessed following correct values, depending on the
projection used:
EPSG:3857 (Mercator) - 1
EPSG:2180 (PUWG1992) - 1
EPSG:4326 (WGS84) - 94.87428468118 (this one - got from OpenLayers
unit test source code)

But I got:
EPSG:3857 (Mercator) - 0.9988243474118915
EPSG:2180 (PUWG1992) - 0.9988243474118915
EPSG:4326 (WGS84) - 111319.4558866885

Looking through the OpenLayers code I see, that they define 4 values
got getMetersPerUnit():
- degrees (94.87428468118)
- feet (0.3048)
- meters (1)
- us feet (.3048006096)

Do I understand correctly, that for base projections:
- org.openstreetmap.josm.data.projection.proj.LonLat - I should use degrees
- org.openstreetmap.josm.data.projection.proj.Mercator - I should use meters
- org.openstreetmap.josm.data.projection.proj.TransverseMercator - I
should use meters

But I'm not sure about:
org.openstreetmap.josm.data.projection.proj.LambertConformalConic
org.openstreetmap.josm.data.projection.proj.SwissObliqueMercator

Which unit I should use there?

I plan to extend Projection interface to include getMetersPerUnit
method and implement necessary constants in
org.openstreetmap.josm.data.projection.proj.* classes.

Does anybody has any objections with such approach?

Cheers,

Wiktor

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

Re: [josm-dev] WMTS scales - proper definition of 1m along meridian

[Wiktor Niesiobedzki]

2015-07-02 23:12 GMT+02:00 Paul Hartmann phaau...@gmail.com:
 On 02.07.2015 21:47, Wiktor Niesiobedzki wrote:

 Currently I'm working on WMTS support. As some of you may know (and
 those who do not, I refer to
 http://www.opengeospatial.org/standards/wmts) uses notion of
 scaleDenominator that's crucial to tile positioning. More less -
 scaleDenominator tell how many meters are on the tile per pixel.
 I tried several of algorithms to get the number of meters along
 meridian for current JOSM projection,


 This value is not constant along a meridian, but depends on the latitude
 (and sometimes longitude). Also, the value in east direction can be
 different from the value in north direction (e.g. in WGS84).

 [...]

 What you get here is not metersPerDegree, but metersPerNorthing. As far as I
 know, this is the only way to find that number (but you have to plug in the
 actual location). I've implemented this for the Piclayer plugin:
 https://trac.openstreetmap.org/browser/subversion/applications/editors/josm/plugins/piclayer/src/org/openstreetmap/josm/plugins/piclayer/layer/PicLayerAbstract.java#L304
 Anyhow, I'm pretty sure you don't need this for a WMTS implementation.

I understand, that how much real meters you get per unit of latitude
as well as per unit of longitude differs for different part of the
ellipsoid/sphere. But that's not what WMTS specification ask. The
crucial part of spec says:

pixelSpan = scaleDenominator × 0.28e-03 / metersPerUnit(crs);
tileSpanX = tileWidth × pixelSpan;
tileSpanY = tileHeight × pixelSpan
tileMatrixMaxX = tileMatrixMinX + tileSpanX × matrixWidth;
tileMatrixMinY = tileMatrixMaxY - tileSpanY × matrixHeight;

And uses following wording: the coefficient to convert the coordinate
reference system (CRS) units into meters (metersPerUnit)

And metersPerUnit(crs) function is something I do need for proper
computations. As I said, if I use the constant, I get working WMTS
layer for WGS84 (no matter at which longitude and latitude), as well
as for Mercator and PUWG1992. This is also the way OpenLayers
implement their support for WMTS.

 Do I understand correctly, that for base projections:
 - org.openstreetmap.josm.data.projection.proj.LonLat - I should use
 degrees
 - org.openstreetmap.josm.data.projection.proj.Mercator - I should use
 meters
 - org.openstreetmap.josm.data.projection.proj.TransverseMercator - I
 should use meters


 There is no reason to switch to other units as this is only an internal
 number and not exposed to the user. The unit is arbitrary, so you can just
 stick to meters.

But there are some EPGS projections, that use other units internally
(foot for example; EPGS:26782 and EPGS:3739 to use the ones shown in
OpenLayers testcases).

The question is:
1. Should I implement this as a part of Projection (I think this is
preferred way, though the name metersPerUnit is misleading, though
even OGC uses such name, so I would keep this with disclaimer)
2. Should I implement this as a part of WMTS tile source internal
conversions, but then I would need to create my own dictionary of
projections and which units internally do they use.

Cheers,

Wiktor

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

[josm-dev] HEADSUP - maual cleanup of working copy required

[Wiktor Niesiobedzki]

Hi,

As I've just commited (8526) change, that removes JAX-B bindings, you
need to remove one file:
src/org/w3/_2001/xmlschema/Adapter1.java

From your working copy, before ant compile task will succeed.

As this is one time fix, I decided to not overload build.xml file with
removal of this file.

Take care,

Wiktor

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

Re: [josm-dev] JCS as optional dependency

[Wiktor Niesiobedzki]

Hi,

I don't quite understand what's your goal. All dependencies are
included in josm*.jar. Do you intend to create your own *jar for
distribution without dependencies and use separate packages to provide
them?

Cheers,

Wiktor

2015-06-17 0:21 GMT+02:00 Sebastiaan Couwenberg sebas...@xs4all.nl:
 Would it be possible to make JCS an optional dependency and use the
 previous caching mechanism if it's not available?

 This would make it easier to package current JOSM tested snapshots (and
 backports for these) until JCS is more widely available in distributions
 (JCS 2.0 is still at beta1). There are still several missing pieces to
 get JCS packaged in Debian for example.

 Kind Regards,

 Bas

 --
  GPG Key ID: 4096R/6750F10AE88D4AF1
 Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

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

Re: [josm-dev] JCS as optional dependency

[Wiktor Niesiobedzki]

On Wednesday, June 17, 2015, Sebastiaan Couwenberg sebas...@xs4all.nl
wrote:

 On 06/17/2015 09:28 AM, Wiktor Niesiobedzki wrote:
  I don't quite understand what's your goal. All dependencies are
  included in josm*.jar. Do you intend to create your own *jar for
  distribution without dependencies and use separate packages to provide
  them?

 For software to be included in Debian the software itself and all its
 dependencies need to be built from source, because Debian cares deeply
 about its commitment to Free Software.

 Just shipping JARs is not acceptable because .class files are not
 source. While shipping binaries is the norm in the Java world, this is
 incompatible with the Free Software principle of allowing users to
 modify the software they receive. That requires the software in its
 preferred form for modification (source code).

 But when you download the source code from our repository, you will get
all the dependencies. Ant build will create a jar that will contain all
necessary dependencies within. What's wrong with such approach?

Cheers,

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

Re: [josm-dev] Image extraction from TMS cache

[Wiktor Niesiobedzki]

Hi,

There is no general general cache explorer for JCS, as it is
implementation dependant, what it stores in the cache. Generally -
what's in there, it's just plain Java objects.

So what you could do, is to create small java program, that would
extract all the files from JOSM cache, based on josm.jar. And further
functionality just depends on what you want to do with cache content.

Cheers,

Wiktor

2015-06-01 20:45 GMT+02:00 Holger Mappt holger...@gmx.net:
 Hi,

 Is this something I can do on the command line or do I need to write a Java
 program?  What would be a good starting point?  I was assuming that there is
 some kind of cache explorer, but I couldn't find one.

 Thanks,
 Holger



 Am 28.05.2015 um 22:14 schrieb Wiktor Niesiobedzki:

 Hi,

 This is +/- propietary standard of Apache Java Caching System
 (https://commons.apache.org/proper/commons-jcs/). We are currently
 using Indexed Disk Cache as store for tiles, so the easiest way
 forward, is just to use JCS, to read the file, and then use keySet()
 method, to get all the data that is stored in cache.

 Cheers,

 Wiktor

 2015-05-28 20:30 GMT+02:00 Holger Mappt holger...@gmx.net:

 Hi,

 I assume the new TMS cache with the files TMS.data and TMS.key uses some
 standard.  What tools can I use to extract the images from that cache? I
 do
 some post-processing for offline mapping with Mapserver.

 Thanks,
 Holger

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

Re: [josm-dev] Image extraction from TMS cache

[Wiktor Niesiobedzki]

Hi,

This is +/- propietary standard of Apache Java Caching System
(https://commons.apache.org/proper/commons-jcs/). We are currently
using Indexed Disk Cache as store for tiles, so the easiest way
forward, is just to use JCS, to read the file, and then use keySet()
method, to get all the data that is stored in cache.

Cheers,

Wiktor

2015-05-28 20:30 GMT+02:00 Holger Mappt holger...@gmx.net:
 Hi,

 I assume the new TMS cache with the files TMS.data and TMS.key uses some
 standard.  What tools can I use to extract the images from that cache? I do
 some post-processing for offline mapping with Mapserver.

 Thanks,
 Holger

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

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