[josm-dev] GSoC application for JOSM core

[Michael Zangl]

Hi,

I decided to apply to GSoC once again this year.

During my GSoC last year I noticed that there are many things in JOSM
core that are working but make extending JOSM painful. I already send in
many small patches over the last year but I did not have the time to go
any further and work on some of the bigger tasks. Especially #11838 and
#11637 did not get the focus they deserved and starved a bit.

This is why I propose to restructure some things, especially around the
MapView.

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

Michael

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

Re: [josm-dev] Multiline labels in JOSM?

[Paul Hartmann]

On 19.03.2016 20:40, Tobias Wendorff wrote:

Hi there,

is it possible to place multiline labels in MapPaint unsing MapCSS?
I've played around with eval(replace()) and \n in every variation
(\\n, "\n", '\n', "\\n", '\\n' etc.), but can't get the label to
break :(


No, automatic line break doesn't work at the moment. What you can do is 
place multiple labels, one below the other like this:


node[shop=supermarket] {
text: auto;
}
node[shop=supermarket]::snd_label {
text: "opening_hours";
text-offset-y: -15;
text-offset-x: 7;
}

Paul




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

[josm-dev] Multiline labels in JOSM?

[Tobias Wendorff]

Hi there,

is it possible to place multiline labels in MapPaint unsing MapCSS?
I've played around with eval(replace()) and \n in every variation
(\\n, "\n", '\n', "\\n", '\\n' etc.), but can't get the label to
break :(

Best regards,
Tobias


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

Re: [josm-dev] Styling of selected ways?

[simson.gert...@gmail.com]

There is already a ticket: https://josm.openstreetmap.de/ticket/9920

Stefan

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

Re: [josm-dev] Styling of selected ways?

[Paul Hartmann]

On 19.03.2016 13:11, Tobias Wendorff wrote:

Am Fr, 18.03.2016, 20:53 schrieb Tobias Wendorff:

I've generated a style for JOSM with very wide lines (width=40).
It looks very well, but whenever I'm selecting a way, I'm getting
a big fat (non-greek) red line.


Dirk just pointed me here:
https://josm.openstreetmap.de/wiki/Help/Styles/MapCSSImplementation#PseudoClasses


Yes, the :selected pseudo class that should work for lines.

As for the style-customization of the yellow crosses: this isn't 
possible at the moment, but it doesn't sound too difficult to add. 
Please open a ticket for this feature request.


Paul

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

Re: [josm-dev] Styling of selected ways?

[Tobias Wendorff]

Am Fr, 18.03.2016, 20:53 schrieb Tobias Wendorff:
> I've generated a style for JOSM with very wide lines (width=40).
> It looks very well, but whenever I'm selecting a way, I'm getting
> a big fat (non-greek) red line.

Dirk just pointed me here:
https://josm.openstreetmap.de/wiki/Help/Styles/MapCSSImplementation#PseudoClasses


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

[josm-dev] Styling of selected ways?

[Tobias Wendorff]

Hi there,

that might be not the correct place to ask this question, but since
I've been registered on this list for a while, I'm giving it a try.

I've generated a style for JOSM with very wide lines (width=40).
It looks very well, but whenever I'm selecting a way, I'm getting
a big fat (non-greek) red line.

Pictures:
http://fs5.directupload.net/images/160318/6c7veuan.png
http://fs5.directupload.net/images/160318/nb2rmdu2.png

Is it possible to style the selections? Also, is it possible to
change the colors of the yellow crosses to create a new node on
the line's middle point?

Thanks a lot
Tobias


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

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

[Michael Zangl]

Am 18.03.2016 um 12:09 schrieb Dirk Stöcker:
> On Fri, 18 Mar 2016, Michael Zangl wrote:
> 
>> I decided to apply to GSoC once again this year.
>>
>> During my GSoC last year I noticed that there are many things in JOSM
>> core that are working but make extending JOSM painful. I already send in
>> many small patches over the last year but I did not have the time to go
>> any further and work on some of the bigger tasks. Especially #11838 and
>> #11637 did not get the focus they deserved and starved a bit.
>>
>> This is why I propose to restructure some things, especially around the
>> MapView.
>>
>> 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.

> I appreciate many of the ideas you have to make the core components more
> modular. That's a lot of work and if finished will allow us to start
> some things which are wanted for some time (e.g. using the MapView in
> other places).

Yes, this was one of my intentions. I don't know if I can get there
during this year's GSoC, especially because layers assume that they are
only displayed once (and there is a lot of layer code...).

> Is there a chance that GSoC accepts such an approach, as it's hard to
> show your own work when a constant review process lies inbetween?

Simply do a SVN grep for "Patch by..." ;-). Both MapView and bug
tracking are components that will require rewriting / new code in large
parts. That way, a lot of new code is at one place. I don't think that
this should be a problem for Google.

OSM already had several such projects (e.g. improving the road style).

They might have more problems with dependencies on other work though but
I do not have many of them here. I could work mostly on myself, although
I hope to have feedback from and discussion with the community.

> We did similar things in the past, e.g. when replacing the data storage
> with QuadTree. In such cases we accept less mature code and constant
> fluctuation for some time as long as it does not break the software
> completely and the changes come in small steps. We'll get fire from the
> latest-user in that time, but one could say that's appreciated feedback :-)

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.

Michael

___
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] Auto center new node

[Florian Lohoff]

On Sat, Mar 19, 2016 at 11:53:43AM +0100, Florian Lohoff wrote:
> 
> Hi,
> i just updated to the latest josm and was immediatly annoyed by
> josm trying to auto center/scroll to a new node beeing set. 
> 
> I looked through the settings and i couldnt find anything obvious.
> 
> Is there a way to disable that behaviour? I dont think it should be
> default either.

Forget it - after thinking about it for another 5 Minutes i found
the "Viewport following". I have no clue how it enabled and why
i never stumbled on that before ...

Flo
-- 
Florian Lohoff f...@zz.de
  We need to self-defend - GnuPG/PGP enable your email today!


signature.asc
Description: Digital signature
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

[josm-dev] Early Access builds of JDK 9 b110 & JDK 9 with Project Jigsaw b110 (#4664) are available on java.net

[Rory O'Donnell]

Hi Vincent,

Early Access b110  for JDK 9 is 
available on java.net, summary of  changes are listed here 
.
Among other fixes , the following changes are also included from builds 
108 to 110


 o removal of the OS X-specific com.apple.concurrent package
 o update to the JAX-WS RI integration to latest version
   (2.3.0-SNAPSHOT)
 o disabling of Diffie-Hellman keys smaller than 1024 bits

Early Access b110  (#4664) for JDK 9 with 
Project Jigsaw is available on java.net.
We expect this will be the last EA build before we integrate into JDK 9. 
This means that this

EA build is essentially what will be jdk-9+111 next week.

As always, please help out by trying out existing code and libraries to 
see what works and
doesn't work. We have a detailed list of compatibility issues listed in 
JEP 261 [2].


Also feedback and questions from those that trying the EA build to 
modularize existing
code would be appreciated. We also want to know what works and doesn't 
work here [3]


Rgds,Rory


[1] https://jdk9.java.net/jigsaw/
[2] http://openjdk.java.net/jeps/261
[3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/

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