Re: [OSM-dev] GSoC: OpenGL view for JOSM

[Michael Zangl]

Hi Wiktor

Am 18.03.2015 um 22:59 schrieb Wiktor Niesiobedzki: Hi Michael,

 Your proposal looks like it's well thought. I'm not proficient with
 OpenGL programming, but I'd like to ask you a few questions about your
 vision:
 1. Do you have any benchmarks, that OpenGL / Vertex Buffer Objects
 outperform 2d drawing, when we need only to draw simple lines?

OpenGL can draw single lines, but this is sort of deprecated. You can
draw a rectangle instead (or a slightly different shape, respecting line
caps). As Paul already said, I sent some benchmarks on the mailing list.
You can try it yourself:
https://github.com/michaelzangl/josm
To compile, you need to extract the jogamp-all-platforms to your eclipse
project directory. Only line drawing is implemented (and everything else
is disabled in Java2D). Don't be scared by the high times for geometry
computation, many normals get computed several times, point iterators
converted to array lists, ... This mainly aims at testing the render
time that would be possible with OpenGL.

This does not use VBOs. I have experience with those from a 2D-game I
made that makes heavy use of small geometry tiles. With those, there
should be even more speed improvements on modern graphic cards.

The main aim of this project is not to reduce the overall render time of
the whole scene (although this is likely to happen) but mostly focus on
reducing the render time in a way that makes the view feel responsive to
the user.

 2. Have you tried to profile JOSM (for example - with visualvm) and
 confirmed, that it's 2d API, that lacks the performance?

Yes, I have. This already lead to two tickets ;-) (11231, 11227, both in
the mapcss code). After mapcss is parsed (and then cached), most time is
spend sending the paint calls of Java2D. This cannot be parallelized (in
contrast to computing the OpenGL geometry and bulk-sending it afterwards).

 3. There is at least one 3d plugin for JOSM using OpenGL - Kendzi3D
 (http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Kendzi3D) that I'm
 aware of, have you tried playing with it?

No, I was not even aware of that plugin. That plugin also uses jogl to
render. It is not aimed at editing the map but more at having a 3D
preview of the map (like the Mapnik style is for 2D).

 4. There might be a lot of space for improvement, if we could early
 decide, whether object should be at all considered for drawing, at
 specific zoom level, or if we could simplify objects, that we are
 drawing

Most of these improvements should be done in the style, not the drawing
code itself. Simplification of objects might be a good option for larger
drawing areas, but it would also require some sort of geometry cache.

Michael

 Cheers,
 
 Wiktor
 
 2015-03-09 13:58 GMT+01:00 Michael Zangl 
 openstreet...@michael.fam-zangl.net:
 Hello,

 This is a thing that annoyed me for a long time: JOSM is slow when
 zooming out. I would like to improve this and have enough spare time
 this summer to work on this as GSoC project.

 I am currently studying computer science at the KIT (Karlsruhe,
 Germany). My OSM name is michael2402.

 Motivation
 Currently, JOSM uses the default Java 2D framework. While this is
 portable (it just works) and also supports 2d graphic acceleration using
 OpenGL, it is not as fast as a plain OpenGL implementation would be.
 This is why I would suggest adding a second render mode to JOSM which
 would then use OpenGL and all it's modern features like VBOs to
 accelerate rendering and allow a smooth moving of a zoomed-out map.

 The idea:
 I would like to add a second rendering mode that only uses OpenGL. Users
 are then able to chose between classic rendering and the new OpenGL
 render styles.

 The basic idea is that this interface can be used if you want to work in
 an urban area with a lot of details and change e.g. the public transport
 system so you need to zoom out a lot. The current renderer is pretty
 slow as soon as there are many objects in the view. Therefore, even a
 not-fully-featured Renderer can be beneficial for users to get an
 overview over the area.

 I would then add a new rendering interface that exposes the new features
 required/provided by OpenGL. That interface should be prepared to accept
 3D-Positions (although I don't plan on using them, but maybe someone
 might want to add shadows or even a real 3D building view in the
 future). We have to discuss how this works, but currently I am in favor
 of offsetting all nodes to the ground elevation (so a barrier=wall might
 be from 0 to 1 meter), then adding the elevation we got from elevation
 tags (ele, NASA data, ...)

 That rendering interface can then be used by plugins to add their own
 styles. This would be necessary if one wanted to add real 3D objects,
 like trees. This is more like a bonus feature, so I will be writing a
 test plugin to test the interface. We also need a way to add ground
 (= Background) images for background layers.

 I would then create one plugin that can uses

[OSM-dev] GSoC Application: JOSM OpenGL data view

[Michael Zangl]

Hi,

I already posted this on josm-dev (and there already were some
discussions about it here).

I am applying for this year's GSoC to improve the rendering speed and UI
responsiveness in JOSM:
http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/michaelz/5750085036015616

Feel free to discuss it and leave feedback.

Michael Zangl

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

[OSM-dev] GSoC: OpenGL view for JOSM

[Michael Zangl]

 and the objects it should render).
3 Weeks: Create a VBO drawing library.
3 Weeks: Add a mappaint style renderer (hopefully being able to use as
much of an existing renderer as possible). Make objects clickable. Bonus
(I can't tell if I have time, but basically this should be the same as
any other observed object changes): Support hover and active.
2 Weeks: (to be discussed which): Add a new render layer for background
images. It should then be possible to draw a GeorefImage list and e.g.
the Bing map.

Main challenges:
- Prevent code-duplication as much as possible.
- Get the OpenGL-Part as stable as possible (not fully featured, but
non-crashing), so that it can be included in trunk after GSoC is over.

To be discussed:
- How much of this can be a plugin? Is it possible to use a plugin for
all of this or should as much of it be in core? I would suggest adding
the basic OpenGL stuff to Core and implementing the layer renderers as
plugins. That way, each of them can be improved independently.
- Should the layer Painters be a private for to each layer (and provided
by it) or should they be provided by a central system (get me the
Painter for ...)
- Use shaders for the background images.
- I did not find an OpenGL MapCSS renderer. This could be a nice project
to have (for other editors, smartphones, ...). Are there any efforts
currently? We don't need to do things twice...
- Should we support multiple renderers? I really opt for this, we could
e.g. add a mini-map to the sidebar to show where you are on the map or
even support opening multiple Edit-Windows (imagine having the official
Map with house numbers on one screen and the map with Bing sattelite on
the other, house number mapping would just get so much easier ;-))

What are your thoughts on this?

In hope of a lot of feedback,
Michael Zangl

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

[OSM-dev] GSoC: Improve the UI of OsmAnd

[Michael Zangl]

Hi,

I do not even know, if OsmAnd is even supported by the OpenStreetMap
project, but I was so annoyed of it this week that I wrote a proposal to
improve it.

The proposal is public, so last-minute GSoC applications might still be
possible for the same project, since I belive that my JOSM project will
be more beneficial to OSM and that it is a nicer, more compact project
ideal for GSoC.

http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/michaelz/5700735861784576

Regards,
Michael

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

Re: [OSM-dev] Multipolygon decoding

[Michael Zangl]

Hello,

Josm renders them and only uses it's own Java objects after reading the
XML. There are two rendering phases: Collecting the styles to be
rendered and then painting everything on the screen.

Here are some hints on where to get started:

The generation of styles for a multipolygon is triggered here:
> https://github.com/openstreetmap/josm/blob/7a780ca01e8b2b31fbfa243af1db37d032ba7853/src/org/openstreetmap/josm/gui/mappaint/ElemStyles.java#L367

Style collection (finding what needs to be drawn):
> https://github.com/openstreetmap/josm/blob/7a780ca01e8b2b31fbfa243af1db37d032ba7853/src/org/openstreetmap/josm/data/osm/visitor/paint/StyledMapRenderer.java#L1837

We inherit the style of the surrounding ways from the multipolygon. That
way, multipolygon borders can be rendered like normal ways.
> https://github.com/openstreetmap/josm/blob/7a780ca01e8b2b31fbfa243af1db37d032ba7853/src/org/openstreetmap/josm/gui/mappaint/ElemStyles.java#L203

Old (deprecated) polygons inherit their style from the outer lines:
> https://github.com/openstreetmap/josm/blob/7a780ca01e8b2b31fbfa243af1db37d032ba7853/src/org/openstreetmap/josm/gui/mappaint/ElemStyles.java#L301

And finally the real rendering of the area (borders are rendered since
their line segments got the style from the multipolygon).
> https://github.com/openstreetmap/josm/blob/7a780ca01e8b2b31fbfa243af1db37d032ba7853/src/org/openstreetmap/josm/data/osm/visitor/paint/StyledMapRenderer.java#L615

Michael


Am 03.01.2016 um 23:24 schrieb Mikoláš Štrajt:
> Hello,
> I am developing my own rendering software and I struggled on decoding 
> multipolygon relations. It seems to be bit tricky. I tried to found some 
> info about it, but all I found is this wiki page: http://wiki.openstreetmap.
> org/wiki/Relation:multipolygon/Algorithm
> 
> Can you point to some example of code decoding multipolygons? I would 
> especially like something that will be written with renderer in mind (ie 
> source code is part of some renderer).
> 
> Note that my software decodes OSM XML file itself, I don't want to use 
> PostGIS as backend.
> 
> 
> 
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
> 


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

Re: [OSM-dev] Removing functionality and giving just No as answer

[Michael Zangl]

Hi,

A few words of someone who is just "using" the OSM website:

I personally think the current Menu is full enough. We should focus on
making that menu better for normal visitors. I could not really think of
a use case where a normal user would want to see a specific map tile. In
my opinion, they should not even know that map tiles exist. If you want
to export a part of the map, use the image functionality in the export tab.

I like that the main site has some dev stuff on it and is sort of a
browser for the database. But for many people, it is the first point
where they get in touch with OSM. And they don't know what a attribute
list is, they don't know about relations and for them, most
functionality of the page is not usable (changesets, object queries,
...). Compared to other map pages, the page is really "technical" the
way it is now.

I support the decision to not include that link to the tile source on
the website: This is a not a dev playground, this is a website that
should be used by millions of normal users. It should provide an entry
point for people that want to improve the OSM database. It should not be
a maintenance tool.

Michael

Am 24.02.2017 um 12:41 schrieb Tom Hughes:
> On 24/02/17 11:33, Dave F wrote:
> 
>> On 24/02/2017 11:19, Tom Hughes wrote:
>>
>>> Well it was a little odd that we suddenly got several people who are
>>> not regular commenters turning up in the space of a few minute to add
>>> "me too" style responses.
>>
>> What's wrong with that? There are numerous discussions in Dev that I
>> have no interest in, but on occasion there's something relevant to my
>> OSM usage & I will make a comment. This current topic appears to be
>> relevant to a few other users.
> 
> The problem is that there is a subset of people that think tickets are a
> popularity contest and that if they can just get enough people to vote
> for a ticket it will be accepted/implemented/whatever.
> 
> That's not how it works however, in almost any open source project in
> fact, because things are done because people want to work on them and
> are accepted when they are the right thing, whether they are being asked
> for by one person or a hundred people.
> 
> Even if a hundred people turned up to say they would use this that tells
> us nothing about the other million mappers that have no idea what github
> even is so it's really not helpful to fill everybody's mail boxes up
> with "+1" messages that we're all just going to ignore anyway.
> 
> Tom
> 


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

Re: [OSM-dev] Multipolygon relation way member without role

[Michael Zangl]

Am 19.09.2016 um 05:50 schrieb patrick keshishian:
> It seems that this association is a mistake. If so, is there a
> better place to report these sort of things as I come across them?
> As I am still learning my way through the data, I don't wish to
> do wholesale edits.

You can add a note about this:

http://www.openstreetmap.org/note/new#map=19/21.59793/-158.10305 ;-)

Michael

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

Re: [OSM-dev] Polygon inner/outer relation in osm file

[Michael Zangl]

Hi,

There is no order for any of the multipolygon members. When I create them,
I try to sort them (outer before inner, then to form circles). JOSM
combines them to form circles for some months now. But there is no
convention.

So it is up to you to match the corresponding outer/inner rings and
find out if the multipolygon is valid.

> http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Valid_Multipolygon_conditions

Michael

Am 23.08.2016 um 09:39 schrieb patrick keshishian:
> Greetings,
> 
> What is the mechanism used, while processing "relation"-s, in
> matching "inner" and "outer"-s of polygons?
> 
> Examining some example data extracts (from geofabrik.de) it looked
> as if an "outer" is followed by its "inner"-s (if any).
> 
> But soon I came across ones like this:
> 
>changeset="17984334" uid="574654" user="Tom_Holland">
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
> 
> I am really hoping to be missing something obvious, and that the
> import (or render) software does not examine each "inner" against
> each "outer" to determine the association.
> 
> Also hoping this is the appropriate list for this sort of questions.
> 
> --patrick
> 
> [0] http://www.openstreetmap.org/relation/3215648#map=16/19.9202/-155.8783
> 
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
> 


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

Re: [OSM-dev] GSoC 17 : JOSM- New main menu

[Michael Zangl]

Hi,

That ticket is just a rough starting point. Simply implementing the
changes there won't be enough for a full GSoC - you would be done in a
week ;-). Some minor, easy changes may already be applied - don't worry
about them. Your task would be to work on the big picture. So part of
your task is defining the task you will be working on ;-). You can work
on other parts of the UI (context menus, ...) if you feel the need for it.
This is not like a university project where you get a todo list and
simply work on it.

If you have further questions on details, feel free to mail me privately
without CCing the mailing list. In cases like this one that need
clarification about a JOSM ticket, it is best to write your answer below
that ticket. Don't worry, I'll get a mail as soon as you write a comment
there.

Michael

Am 09.03.2017 um 18:51 schrieb Nathiesha Maddage:
> Hi Micheal,
> 
> I studied the MainMenu class and the associated Activity classes, and
> got a basic idea on how the code is structured. I will get more
> familiarized with it as you have suggested, to come up with a clean up
> plan for the source code. 
> I think the required changes of visual menu is all listed here [1]. I
> went through that and got an idea about the proposed changes. However I
> could not find a few of the listed problems, in the JOSM version I compiled.
> 
> eg: 
> 
>   * Remove functionality - *Copy coordinates actions*
>   * Move menu items - *Jump to position -> Two items up and name it Zoom
> to coordinates...*
>   * Restructure the Tools menu - *Areas: Mirror , join, multipolygon*
> 
> Are those issues already fixed? Or I might have missed them? And are
> there any other new requirement other than those, that need to be done?
> 
> I still could not try out installing new plugins and observe how they
> fit in. I will do so.
> 
> [1]. https://josm.openstreetmap.de/ticket/13456#no1
> 
> On Wed, Mar 8, 2017 at 12:17 AM, Michael Zangl
> <openstreet...@michael.fam-zangl.net
> <mailto:openstreet...@michael.fam-zangl.net>> wrote:
> 
> Hi Nathiesha,
> 
> For this particular project, I'd recommend that you familiarize yourself
> with the editing options that JOSM provides. Fell free to install many
> plugins and see how they integrate into JOSM.
> 
> You should also get familiar with the menu code, starting at the
> MainMenu class. It currently has a lot of public fields and other ugly
> code. You should develop a cleanup plan for both the source code and the
> the visual menu. Feel free to use object-oriented approaches. The new
> menu should be compatible to the old API as good as possible, since all
> JOSM plugins depend on it and we don't want to break them all. You can
> use the adapter pattern for this, so don't worry too much about it.
> 
> Michael
> 
> Am 07.03.2017 um 19:17 schrieb Nathiesha Maddage:
> > Hi Michael,
> >
> > Thanks for the quick reply.
> >
> > I am Nathiesha Maddage, a final year undergraduate at University of
> > Moratuwa, Sri Lanka. I participated in GSoC 2016 as well and completed
> > the project successfully, by developing an Eclipse plugin.
> >
> > I was interested in OSM, since I was doing my final year University
> > project on visualizing the land use with OSM data and Google satellite
> > images. I went through the project list and I am interested in the JOSM
> > project , new main menu. I am familiar with Java and I am getting
> > familiarized with JOSM.
> >
> > I compiled the source code using Eclipse. I will go through it to get a
> > basic understanding about the code and the project structure. And I will
> > use the JOSM mailing list and bug tracker, as you have suggested, if I
> > find any question regarding the code.
> >
> > Is there any other resources that I should follow in the meantime, that
> > would be useful for this project?
> >
> > Github -https://github.com/nathiesha
> > LinkedIn - https://www.linkedin.com/in/nathiesha-maddage-48710096/
> <https://www.linkedin.com/in/nathiesha-maddage-48710096/>
> > <https://www.linkedin.com/in/nathiesha-maddage-48710096/
> <https://www.linkedin.com/in/nathiesha-maddage-48710096/>>
> >
> >
> > On Tue, Mar 7, 2017 at 11:24 PM, Michael Zangl
> > <openstreet...@michael.fam-zangl.net
> <mailto:openstreet...@michael.fam-zangl.net>
> > <mailto:openstreet...@michael.fam-zangl.net
> <mailto:openstreet...@michael.fam-zangl.net>>> wrote:
> >
> > Hi,
> >
&

Re: [OSM-dev] GSoC 17 : JOSM- New main menu

[Michael Zangl]

Hi,

I am the one who proposed that project.

Getting your own compiled version of JOSM is a good starting point.

You can experiment with the github repository. It has not been updated
since January, but this should be no problem since there were only minor
changes since then. It is just a read-only mirror of the SVN repository.

For detailed questions about the code, JOSM has a own mailing list:
https://lists.openstreetmap.org/listinfo/josm-dev
But we tend to use the bug tracker more, so you can simply comment on
that ticket.

If you have any further questions about the project, I'm always open to
a chat session ;-).

Michael

Am 07.03.2017 um 18:14 schrieb Nathiesha Maddage:
> Hi all,
> 
> I downloaded the JOSM source code from the git hub repository [1]
> because I am more familiar with git than svn. Is that OK, or should I
> download the source code from the SVN repository, as git repository is
> listed as unofficial in the website [2]?
> 
> [1]. https://github.com/openstreetmap/josm
> [2]. https://josm.openstreetmap.de/wiki/Source%20code
> 
> -- 
> Best Regards,
> *Nathiesha Maddage*
> Undergraduate,*
> *
> Department of Computer Science & Engineering,
> Faculty of Engineering,
> University of Moraduwa,
> Sri Lanka.
> 
> 
> 
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
> 


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

Re: [OSM-dev] GSoC 17 : JOSM- New main menu

[Michael Zangl]

Hi Nathiesha,

For this particular project, I'd recommend that you familiarize yourself
with the editing options that JOSM provides. Fell free to install many
plugins and see how they integrate into JOSM.

You should also get familiar with the menu code, starting at the
MainMenu class. It currently has a lot of public fields and other ugly
code. You should develop a cleanup plan for both the source code and the
the visual menu. Feel free to use object-oriented approaches. The new
menu should be compatible to the old API as good as possible, since all
JOSM plugins depend on it and we don't want to break them all. You can
use the adapter pattern for this, so don't worry too much about it.

Michael

Am 07.03.2017 um 19:17 schrieb Nathiesha Maddage:
> Hi Michael,
> 
> Thanks for the quick reply. 
> 
> I am Nathiesha Maddage, a final year undergraduate at University of
> Moratuwa, Sri Lanka. I participated in GSoC 2016 as well and completed
> the project successfully, by developing an Eclipse plugin.
> 
> I was interested in OSM, since I was doing my final year University
> project on visualizing the land use with OSM data and Google satellite
> images. I went through the project list and I am interested in the JOSM
> project , new main menu. I am familiar with Java and I am getting
> familiarized with JOSM.
> 
> I compiled the source code using Eclipse. I will go through it to get a
> basic understanding about the code and the project structure. And I will
> use the JOSM mailing list and bug tracker, as you have suggested, if I
> find any question regarding the code. 
> 
> Is there any other resources that I should follow in the meantime, that
> would be useful for this project?
> 
> Github -https://github.com/nathiesha
> LinkedIn - https://www.linkedin.com/in/nathiesha-maddage-48710096/
> <https://www.linkedin.com/in/nathiesha-maddage-48710096/>
> 
> 
> On Tue, Mar 7, 2017 at 11:24 PM, Michael Zangl
> <openstreet...@michael.fam-zangl.net
> <mailto:openstreet...@michael.fam-zangl.net>> wrote:
> 
> Hi,
> 
> I am the one who proposed that project.
> 
> Getting your own compiled version of JOSM is a good starting point.
> 
> You can experiment with the github repository. It has not been updated
> since January, but this should be no problem since there were only minor
> changes since then. It is just a read-only mirror of the SVN repository.
> 
> For detailed questions about the code, JOSM has a own mailing list:
> https://lists.openstreetmap.org/listinfo/josm-dev
> <https://lists.openstreetmap.org/listinfo/josm-dev>
> But we tend to use the bug tracker more, so you can simply comment on
> that ticket.
> 
> If you have any further questions about the project, I'm always open to
> a chat session ;-).
> 
> Michael
> 
> Am 07.03.2017 um 18:14 schrieb Nathiesha Maddage:
> > Hi all,
> >
> > I downloaded the JOSM source code from the git hub repository [1]
> > because I am more familiar with git than svn. Is that OK, or should I
> > download the source code from the SVN repository, as git repository is
> > listed as unofficial in the website [2]?
> >
> > [1]. https://github.com/openstreetmap/josm
> <https://github.com/openstreetmap/josm>
> > [2]. https://josm.openstreetmap.de/wiki/Source%20code
> <https://josm.openstreetmap.de/wiki/Source%20code>
> >
> > --
> > Best Regards,
> > *Nathiesha Maddage*
> > Undergraduate,*
> > *
> > Department of Computer Science & Engineering,
> > Faculty of Engineering,
> > University of Moraduwa,
> > Sri Lanka.
> >
> >
> >
> > ___
> > dev mailing list
> > dev@openstreetmap.org <mailto:dev@openstreetmap.org>
> > https://lists.openstreetmap.org/listinfo/dev
> <https://lists.openstreetmap.org/listinfo/dev>
> >
> 
> 
> ___
> dev mailing list
> dev@openstreetmap.org <mailto:dev@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/dev
> <https://lists.openstreetmap.org/listinfo/dev>
> 
> 
> 
> 
> -- 
> Best Regards,
> *Nathiesha Maddage*
> Undergraduate,*
> *
> Department of Computer Science & Engineering,
> Faculty of Engineering,
> University of Moraduwa,
> Sri Lanka.
> 


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

Re: [OSM-dev] GSoC Doubts

[Michael Zangl]

Hi Vishal,

First of all: congratulations for getting selected for this years GSoC. 
I am looking forward to mentoring your project (using deep learning for 
satellite image recognition)


This mailing list and the OSM IRC channel are mostly for general 
development. You can have a look at JOSM, since your UI will be 
integrating there. Most communication for JOSM is done in the issue 
tracker [1]. You can have a look in there, but most of it is unrelated 
to your GSoC.


We will discuss the details of your GSoC in private mails, especially 
the ones concerning the detailed scope of your work and all the 
technical issues that arise during your GSoC.


During your GSoC, your main communication with the community will be the 
progress report that you do in regular intervals. You may get some 
feedback on those reports from community members.


Michael

[1] https://josm.openstreetmap.de/report

On 08.05.19 10:12, Vishal R wrote:

Hi,
     First, thank you OSM for selecting my proposal for Google Summer of 
Code. I have some doubts and I was hoping the community could help me 
with them.
     I am bit active in OSM's IRC channels and mailing list. Are there 
any other communities I should be active in?
     Will I by using services like GitHub for my project, or does OSM 
have a repo service for projects like these?


Thank you
Vishal R

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



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

Re: [OSM-dev] JOSM project deployment in PT_Assistant plugin

[Michael Zangl]

Hi,

The josm-dev mailing list is the correct list to send this message to. 
Mind that the JOSM team may often take up to a day to respond - we are 
not onlne 24/7


Michael

On 23.02.20 13:47, Vaibhav Bisht wrote:

Hii,
Vaibhav here, I have compiled the PT_Assistant plugin with Gradle but 
most of the classes are extending from JOSM so my question is?


where can I find the JOSM source code inside the PT_Assistant plugin?

Is there any source code of JOSM inside the plugin or is there any .jar 
file for JOSM inside PT_Assistant plugin. Please let me know where can I 
find it inside my PT_Assistant plugin.

And also how would I update the JOSM code.
By the way, I already have the JOSM source code but I would like to know 
where can I find it inside my PT_Assistant.

Thank you
Truly yours
Vaibhav

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



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

Re: [OSM-dev] having problem in Installing pt_assistant manually in josm

[Michael Zangl]

Hi

That project is using gradle. Import it as gradle project in IntelliJ / Eclipse.

On the terminal, type:
./gradlew runJosm

https://gitlab.com/floscher/gradle-josm-plugin#readme

Michael

Am 3. Februar 2020 12:55:49 MEZ schrieb Vaibhav Bisht 
:
>hello, OSM-dev  community,
>Vaibhav here, currently I want to work on the josm projects
>pt_assistant plugin but there is a problem I can't install it manually.
>I
>tried the following link
>https://josm.openstreetmap.de/wiki/DevelopersGuide/DevelopingPlugins
>but
>then when I tried to compile the build.xml file inside the pt_assistant
>directory it gave me this error   (BUILD FAILED
>/home/dev135/pt_assistant/build.xml:9: Cannot find
>/home/dev135/build-common.xml imported from
>/home/dev135/pt_assistant/build.xml).
>
>If Any of you know how can I install the pt_assistant plugin then
>please
>let me know? Because When I am opening the build.xml file inside my ant
>environment it's not showing any compile file like it was supposed to.
>Btw
>I have forked it from the GitHub it from its repo here
>https://github.com/JOSM/pt_assistant/
>
>PS - Currently I am using the eclipse with the ant environment.
>Please help!
>Yours's truly
>Vaibhav
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] No reply from josm community

[Michael Zangl]

Hi,

At JOSM, we are still in the very early planing stages of GSoC, so we 
have no fixed ideas / mentors list. The ideas list is currently 
relatively empty [1]. But feel free to have a look at the software / 
open issues list. In the past years, we had many projects that were 
suggested by students and that were not on our ideas list.


Michael


[1] 
https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2020/Project_ideas#JOSM_editor




On 28.01.20 12:45, Vaibhav Bisht wrote:

Hello devs of OSM community
    Vaibhav here recently I posted an email regarding GSoC 
on the josm mailing list. There has been no reply from the last 3-days 
since I have sent the email. I wanted to know if Josm is still active. 
here's the link to my mail

https://lists.openstreetmap.org/pipermail/josm-dev/2020-January/008269.html
If you have any information about it please help!
Yours sincerely
Vaibhav

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



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

Re: [josm-dev] Fwd: GSoC: OpenGL view for JOSM

[Michael Zangl]

Hi everyone,

Thanks for the feedback on my idea. Based on the feedback and the tests
I made the past few days, I wrote a GSoC application.

http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/michaelz/5750085036015616

Feel free to leave feedback/your thoughts on this.

Regards,
Michael

Am 09.03.2015 um 18:19 schrieb Michael Zangl:
 Hi,

 I'm also posting this on the JOSM-List in hope to get feedback on the
 technical parts here.

 Regards,
 Michael

  Weitergeleitete Nachricht 
 Betreff: [OSM-dev] GSoC: OpenGL view for JOSM
 Datum: Mon, 09 Mar 2015 13:58:41 +0100
 Von: Michael Zangl openstreet...@michael.fam-zangl.net
 An: d...@openstreetmap.org

 Hello,

 This is a thing that annoyed me for a long time: JOSM is slow when
 zooming out. I would like to improve this and have enough spare time
 this summer to work on this as GSoC project.

 I am currently studying computer science at the KIT (Karlsruhe,
 Germany). My OSM name is michael2402.

 Motivation
 Currently, JOSM uses the default Java 2D framework. While this is
 portable (it just works) and also supports 2d graphic acceleration using
 OpenGL, it is not as fast as a plain OpenGL implementation would be.
 This is why I would suggest adding a second render mode to JOSM which
 would then use OpenGL and all it's modern features like VBOs to
 accelerate rendering and allow a smooth moving of a zoomed-out map.

 The idea:
 I would like to add a second rendering mode that only uses OpenGL. Users
 are then able to chose between classic rendering and the new OpenGL
 render styles.

 The basic idea is that this interface can be used if you want to work in
 an urban area with a lot of details and change e.g. the public transport
 system so you need to zoom out a lot. The current renderer is pretty
 slow as soon as there are many objects in the view. Therefore, even a
 not-fully-featured Renderer can be beneficial for users to get an
 overview over the area.

 I would then add a new rendering interface that exposes the new features
 required/provided by OpenGL. That interface should be prepared to accept
 3D-Positions (although I don't plan on using them, but maybe someone
 might want to add shadows or even a real 3D building view in the
 future). We have to discuss how this works, but currently I am in favor
 of offsetting all nodes to the ground elevation (so a barrier=wall might
 be from 0 to 1 meter), then adding the elevation we got from elevation
 tags (ele, NASA data, ...)

 That rendering interface can then be used by plugins to add their own
 styles. This would be necessary if one wanted to add real 3D objects,
 like trees. This is more like a bonus feature, so I will be writing a
 test plugin to test the interface. We also need a way to add ground
 (= Background) images for background layers.

 I would then create one plugin that can uses MapCSS to render a style in
 the view. That way, many existing styles can be used with the new
 interface. This will be the most part of the work on this project.

 As library I would currently prefer JOGL, since I already have
 experience with it and it contains some additional features we would
 need (like text rendering support and the ability to be added as swing
 panel).

 Current status:
 - Currently, each layer draws it self to the Java Graphics. Most layers
 are not really extensible (like the GPX-Track feature), which makes it
 hard to modify them using plugins (like adding non-standard accuracy
 info to GPX and drawing the accuracy area instead of the line).
 - Layers are drawn the way they are ordered in the side view.
 - There are basically two types of layers: Background layers
 (ImageryLayer.java, TMSLayer.java, ...) and data layers (GpxLayer.java,
 OsmDataLayer.java, ...)

 Implementation details/ideas (so far):
 - JOSM create a list of Drawer objects for each layer.
 - I would like to use a 2D plane (which can then be offsetted using
 shaders) to be the background for all of the map. There is only one
 background pane with the textures of background layers added to it. I
 will have to look more into shaders (like supporting an unlimited number
 of textures on a single area) but I hope this is possible.
 -- Fallback: Just render the images as rectangle, one over the other,
 using opacity settings and disabling the depth buffer (the way it is
 done currently). Cache using VBOs. This is not as modern as shaders
 would be, but it is simple.
 - Layers make heavy use of VBOs. I would like to provide a nice
 interface to draw and cache VBO structures. This will also speed up
 drawing of the map a lot, since the map does not change. Thinks it
 should do include:
 -- Draw a point at the given lat/lon
 -- Draw a line of width x with given (lat/lon/width) point pairs and
 color, closed or open.
 -- Draw a filled area (without contour)
 -- Add text at a given position.
 -- MapCSS properties this basically supports: width, color (rgba),
 dashes, linecap, linejoin, fill-color (rgba

[josm-dev] Fwd: GSoC: OpenGL view for JOSM

[Michael Zangl]

Hi,

I'm also posting this on the JOSM-List in hope to get feedback on the
technical parts here.

Regards,
Michael

 Weitergeleitete Nachricht 
Betreff: [OSM-dev] GSoC: OpenGL view for JOSM
Datum: Mon, 09 Mar 2015 13:58:41 +0100
Von: Michael Zangl openstreet...@michael.fam-zangl.net
An: d...@openstreetmap.org

Hello,

This is a thing that annoyed me for a long time: JOSM is slow when
zooming out. I would like to improve this and have enough spare time
this summer to work on this as GSoC project.

I am currently studying computer science at the KIT (Karlsruhe,
Germany). My OSM name is michael2402.

Motivation
Currently, JOSM uses the default Java 2D framework. While this is
portable (it just works) and also supports 2d graphic acceleration using
OpenGL, it is not as fast as a plain OpenGL implementation would be.
This is why I would suggest adding a second render mode to JOSM which
would then use OpenGL and all it's modern features like VBOs to
accelerate rendering and allow a smooth moving of a zoomed-out map.

The idea:
I would like to add a second rendering mode that only uses OpenGL. Users
are then able to chose between classic rendering and the new OpenGL
render styles.

The basic idea is that this interface can be used if you want to work in
an urban area with a lot of details and change e.g. the public transport
system so you need to zoom out a lot. The current renderer is pretty
slow as soon as there are many objects in the view. Therefore, even a
not-fully-featured Renderer can be beneficial for users to get an
overview over the area.

I would then add a new rendering interface that exposes the new features
required/provided by OpenGL. That interface should be prepared to accept
3D-Positions (although I don't plan on using them, but maybe someone
might want to add shadows or even a real 3D building view in the
future). We have to discuss how this works, but currently I am in favor
of offsetting all nodes to the ground elevation (so a barrier=wall might
be from 0 to 1 meter), then adding the elevation we got from elevation
tags (ele, NASA data, ...)

That rendering interface can then be used by plugins to add their own
styles. This would be necessary if one wanted to add real 3D objects,
like trees. This is more like a bonus feature, so I will be writing a
test plugin to test the interface. We also need a way to add ground
(= Background) images for background layers.

I would then create one plugin that can uses MapCSS to render a style in
the view. That way, many existing styles can be used with the new
interface. This will be the most part of the work on this project.

As library I would currently prefer JOGL, since I already have
experience with it and it contains some additional features we would
need (like text rendering support and the ability to be added as swing
panel).

Current status:
- Currently, each layer draws it self to the Java Graphics. Most layers
are not really extensible (like the GPX-Track feature), which makes it
hard to modify them using plugins (like adding non-standard accuracy
info to GPX and drawing the accuracy area instead of the line).
- Layers are drawn the way they are ordered in the side view.
- There are basically two types of layers: Background layers
(ImageryLayer.java, TMSLayer.java, ...) and data layers (GpxLayer.java,
OsmDataLayer.java, ...)

Implementation details/ideas (so far):
- JOSM create a list of Drawer objects for each layer.
- I would like to use a 2D plane (which can then be offsetted using
shaders) to be the background for all of the map. There is only one
background pane with the textures of background layers added to it. I
will have to look more into shaders (like supporting an unlimited number
of textures on a single area) but I hope this is possible.
-- Fallback: Just render the images as rectangle, one over the other,
using opacity settings and disabling the depth buffer (the way it is
done currently). Cache using VBOs. This is not as modern as shaders
would be, but it is simple.
- Layers make heavy use of VBOs. I would like to provide a nice
interface to draw and cache VBO structures. This will also speed up
drawing of the map a lot, since the map does not change. Thinks it
should do include:
-- Draw a point at the given lat/lon
-- Draw a line of width x with given (lat/lon/width) point pairs and
color, closed or open.
-- Draw a filled area (without contour)
-- Add text at a given position.
-- MapCSS properties this basically supports: width, color (rgba),
dashes, linecap, linejoin, fill-color (rgba), font-size, text-color,
text-offset, text.
-- What we won't support: z-index (but we could order the elements
before drawing), casing, extrude, icons, text-position.
- Each VBO is tied to map objects that it depends on. That way, it only
needs to be updated if those objects change. Doing this is done by the
renderer (which also has knowledge of all MapCSS styles).
-- The MapCSS renderer needs to be adjusted to keep track of object

Re: [josm-dev] GSoC: OpenGL view for JOSM

[Michael Zangl]

Hi,

Thanks for the feedback.

Am 10.03.2015 um 11:22 schrieb Dirk Stöcker:
 On Mon, 9 Mar 2015, Michael Zangl wrote:
 
 This is a thing that annoyed me for a long time: JOSM is slow when
 zooming out. I would like to improve this and have enough spare time
 this summer to work on this as GSoC project.
 
 First: Further improving the drawing speed in JOSM is a very appreciated
 goal!
 
 And now the bigger part with the BUT:
 
 I don't think that implementing OpenGL drawing interface will be a
 working solution.
 
 * It doesn't look like Java bindings for OpenGL are something which can be
   considered a standard. As JOSM is cross-plattform it probably never can
   be integrated into the core. See e.g. PROJ4 plugin, which never will
   make it into core.

You are right, JOGL (which I would use) is only available for Linux,
Windows and Mac. There are no real standard libraries out there. It
would also be a big dependency to add it to JOSM. This is why I favor to
adding it as a plugin, but there will probably changes needed to make it
work.

 * I doubt that the final drawing speed really is the limiting factor. We
   did a lot of optimizations in the last years and these mainly focused on
   reducing the number of displayed elements and the element access: This
   resulted in major speed improvements. Did you do a simple check and
   disable ONLY the final paint functions from drawing and check speed
   increase?

No, I did not. This would not give you the real speed improvements.
Because if you really wanted to test the speed improvements, you would
need to disable all drawing calls for unchanged Elements. Those elements
could be cached in the GPU and would only need to be invalidated once
they are changed.

 * Your proposal contains so much, that it is impossible to get more than a
   study in the given time (except you are an software development
   magician). NOTE: A solution which does not cover the same display
   quality as we have now (i.e. fully support of existing style
   capabilities) will be unusable to us later.

This depends on what your goals are: Are you trying to replace the
current view? Then yes, you need all features and full compatibility
(and all plugins need to be changed, ...).

Are you just adding an alternative display mode? Then it would be
possible for people to use it for basic mapping, and switch to the plain
java renderer when using more advanced styles. But you don't use a
lane-checking style when you have a zoomed-out map.

I am definitely not planing on supporting everything. There are just so
many plugins and tools using their custom drawing that this would not

 Instead of OpenGL a road to have more success seems to be caching
 approaches and display data reduction. E.g. we probably draw a lot
 information, which actually is not really visible (One example: in low
 zoom many streets will be overlayed and displayed as single points -
 there is actually no sense in drawing them).

I have done this before in a game:
http://www.settlers-android-clone.com/

The background consists of a grid of tiny triangles that each get their
own texture. At first we tested a lot of Java 2D, including caching,
pre-rendering tiles and only displaying them, faster datastructures to
render the images (like getting all geometry in a single array and just
walking that array) and classic OpenGL rendering. All of this did not
allow us to run smoothly on a fast graphic card.

In the end, we ended up using OpenGL with VBOs. The whole Background is
a single VBO in which areas get invalidated as soon as the ground
changes. You can see some images on the web page to get an impression of
how many stuff there is moving.

 Also in one point I read that since the map does not change. That's
 actually never true. People permanently zoom and pan and change data, so
 there are permanent changes.

There are only a few changes per frame relative to the amount of data
that is presented to the user. Even if you pan a full screen width per
second, that would be 30 frames (if you want it really smooth: 60) which
the current implementation renders everything, the OpenGL implementation
would only need to send the new elements to the graphic card (and
instruct it to render the old ones).

 * An intelligent way to only reevaluate stuff which really changed (we had
   already a try to use dirty marking and adapted painting, but it never
   got working reliable and thus finished) or

This would be essential to use VBOs reliably. Do you have any references
of what was already tried? I simply expected the DataChangedEvent to be
fired every time the OSM data was changed (and adding own invalidation
events for hover/active). This would handle most data that is displayed,
the rest (tools, bounding boxes, ...) should not introduce much drawing
overhead.

 * An way to do asynchronous map refresh and simple display of scaled
   previous state until done with the proper sectorized refresh (i.e. like
   for TMS/WMS) or
 * Whatever

Re: [josm-dev] Fwd: GSoC: OpenGL view for JOSM

[Michael Zangl]

Hi,
Thanks for the comment.

The main problem I have with the Icons is the packing. I don't want to
use a single texture for every icon, since a texture switch is
expensive. This can be solved, I already did that in jsettlers and can
probably copy some code. The main problem would be to find the icons to
pack together on a texture. Icon drawing is already in the current code
(if there was a texture present, you could just draw a quad and supply
UV coordinates).

I also have not yet looked at the text-along-line feature. If it is that
simple, I will add it. I never did rotated text with JOGL. Changing the
rotation matrix for every call is expensive and JOGL does not expose
it's backing texture. So we might need to copy some of JOGLs text
drawing (which is basically to use Java2D to draw the text onto a
texture and then use that texture on the screen). That way, we could use
VBOs, get a really fast text drawing and can rotate every letter as we
want to.

Using GLG2D is a good idea. I might just add that for all unsupported
layers. Although I cannot add it for drawing unsupported things on the
OSM layer, it should make most plugins compatible with OpenGL. Drawing
Swing components on top of JOGL and the other way around is an option I
don't like, since it went wrong the last time I tried it (mouse events
not beeing captured correctly, ...). But it might also just need some
more tweaking.

Michael

Am 23.03.2015 um 15:19 schrieb Paul Hartmann:
 On 17.03.2015 11:41, Michael Zangl wrote:
 Thanks for the feedback on my idea. Based on the feedback and the tests
 I made the past few days, I wrote a GSoC application.

 http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/michaelz/5750085036015616


 Feel free to leave feedback/your thoughts on this.
 
 The comment section on the Melange platform doesn't seem to be public,
 so I post it here again:
 
 Nice application! I'm all for setting realistic, achievable goals. But I
 was impressed, how much you could do in a small time, and hoped, you
 would aim for a full (or nearly full) replication of the Java2D
 rendering. A display without icons is kind of pointless, we don't need
 another Wireframe mode! Also, the text along line feature is an
 integral part of the standard style by now, and I wouldn't want to miss it.
 
 Keep in mind, that you don't have to implement everything from scratch:
 As long as you can draw individual letters on screen, it should be
 possible to build on the existing code for text along line. Yes, this
 often sounds simpler than it actually is, but you could at least put in
 on the agenda as a secondary goal.
 
 I have looked at your code and was surprised, how complicated it is, to
 even draw a simple line. This makes me wonder: Have you investigated any
 higher level libraries, that offer a Java2D-like interface with a JOGL
 backend? First thing I found was this GLG2D [1]. I know you want to use
 VBO caching and other low-level techniques, but at least you could copy
  paste some existing code, to make life easier.
 
 Another big issue I have with your proposal, is that you seem to settle
 with a hard switch between JOGL and Java2D. I.e. either every layer and
 paint mode must support OpenGL or it isn't used at all. I think this is
 not really desirable as it restricts the usage a lot. It makes this a
 toy project and technology show-off, when it could be a general turbo
 mode that just works for basically every user (with fairly modern
 hardware).
 
 You should investigate, how this can be fixed (can be during the work
 period). One option would be a Java2D-JOGL bridge like GLG2D.
 Alternatively, it seems to be possible to mix JOGL and Java2D in certain
 ways [2]. What are the performance implications? If you come to the
 conclusion, that it is not possible at all, this is fine, but the
 results should be documented properly.
 
 [1] https://github.com/brandonborkholder/glg2d
 [2] http://www.java-gaming.org/index.php?topic=10813.0
 
 
 
 ___
 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

[josm-dev] Editable tags panel table

[Michael Zangl]

Hi,

One thing that always annoyed me about JOSM is that it has those many
modal dialogs. In other editors, you can simply fill in the key/value
table, in JOSM you always need to double-click on the value, then move
your mouse and click on the position where you want to edit the value
(assuming you want to fix a typo). Then you need to explicitly confirm
that dialog by pressing Enter.

The current implementation of the tags table is not that clean as well
(PropertiesDialog), the whole table model is coded there. There is a
nice and relatively clean tag editor table that is currently used for
relations and changesets. It supports inline editing using autocomplete
text fields.

The TagCellEditor is currently already added to the second column of the
table (but not the key column), but it cannot be used because all table
cells are set to uneditable.

Has there been any work on using this as a feature for the tags panel on
the right? It would make the code cleaner and improve usability.

Those are the difficulties I see with it:
* Currently, JOSM keyboard events are global to the window, we need to
disable them as long as the table is edited.
* We should use double-clicking for editing (currently, a single click
edits keys and values).
* The table model might need to be changed to support some nicer way of
auto-completion. We could include the combo box already used in presets
here.
* We need the table model to fire change events as soon as any key/value
is changed. Currently, it only supports bulk changes.
* The model does support different values per key, but it does not count
them. This needs to be changed.

What are your thoughts on it? Has there alreardy been someone working on
this? If that change is desired, I will spend some time writing a patch
for changing the table.

Michael

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

[josm-dev] First release of OpenGL MapView (GSoC)

[Michael Zangl]

Hi,

I am working on providing an OpenGL alternative to the Java2D map view
for this years GSoC. This work has come to a point, where I can release
a first test version and start making changes ready to be merged into JOSM.

Implementing this was pretty challenging. I replace a lot of tasks of
the map view (Drawing the map). But the MapView has so many more
constraints, is accessed as static field, does not really follow the MVC
pattern (or any other design pattern :-(). Simply subclassing it or
writing a second map view is not possible. This is why I am trying to
track the map view. I pass on mouse events to the listeners registered
to the map view, react to redraw requests and pull out the data to draw
when drawing my OpenGL view.

I opened a ticket and described the changes made to JOSM there. It still
needs review, so feel free to comment.
https://josm.openstreetmap.de/ticket/11625

A full diff is here:
https://github.com/michaelzangl/josm/compare/mirror...gsoc-opengl

BETA-TESTING
I compiled a JOSM version that works with the plugin. You need to use
that version to use the plugin.
You can download the modified JOSM and the plugin here:
https://github.com/michaelzangl/josm/releases/tag/v0.1

You should be able to start JOSM without errors. A new button is in the
toolbar. Whith that button, you can enable OpenGL drawing. You see the
border switching from red to blue and the map rendered in OpenGL. There
might be some issues with the rendering (e.g. textures on areas not
drawing) but it should be useable and mouse/keyboard interaction should
be as usual. You should also be able to use any existing plugins. If you
experience issues, feel free to contact me or open a ticked on Github:
https://github.com/michaelzangl/josm-plugin-opengl/issues
You don't need to report optical issues (textures missing, ...) or that
the scale in the upper left hand corner is hidden sometimes. This is
still work in progress.

Things you can do:
- Test it with your plugins, report any compatibility issues.
- State if there are any objections to deprecating rectangle/polygon
drawing in Navigateable Component.
- Test if there are any issues with synchronizing the addLayer/...
methods.

Michael Zangl

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

[josm-dev] GSoC: Improving the UI response time by using OpenGL.

[Michael Zangl]

Hi,

I have finished my GSoC project. The aim was to improve the UI response
time by using OpenGL instead of Java2D for drawing.

The result of this is a plugin with which you can switch between OpenGL
and Java2D drawing.
You can get test if yourself using the binary [1].
Or by building it from source [2].

Feel free to test, report issues and give feedback.
Due to the geometry cache you might need to give JOSM some more memory
when loading big data sets.

The main goal of the plugin was to improve the performance of the map
view and the response times to user events (hover/...).
I did a comparison between the Java2D drawer and OpenGL. Java2D is
better at drawing static, complex geometries (like multipolygons with
holes). OpenGL has the great advantage of being able to re-use the
geometries it rendered in the last frame. This is why it may take longer
for the whole file you loaded to render for the first time, but moving
the map, zooming and minor changes like hovering, selecting or moving
one primitive are faster.

This plugin is intended for all people that want to work in denser areas
and are afraid to load larger datasets or zoom out because that might
slow down JOSM.

Michael Zangl

[1] https://github.com/michaelzangl/josm-plugin-opengl/releases/tag/v0.2
[2] https://github.com/michaelzangl/josm-plugin-opengl/
[3]
https://github.com/michaelzangl/josm-plugin-opengl/wiki/Performance-comparison

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

[josm-dev] Cleaning MapView

[Michael Zangl]

Hi,

Currently, MapView is a collection of global flags, variables and lots
of stuff that has nothing to do with simply viewing the map. Some fields
are not even accessed by MapView itself and only used as global flag.

I want to improve this, mostly to make the OpenGL plugin more reliable
and fix some issues I encountered there the right way (and not just work
around them).

This includes
- Moving the layer code to a new class. There is one global instance of
it holding the JOSM layers. Even if there are no layers (and there is no
MapView), this instance stays there and thus we do not need any public
static addListener() methods. This also makes plugin registration easier.
- The new classes have around 300 lines each, including documentation.
This imprives readability.
- Change event listeners to only get an event object. This allows us to
extend the events in the future without breaking everything.
- Get rid of all if(... instanceof ...) code.

Changing this requires changing a lot of things and rewriting some
management code from scratch. I added a compatibility layer for all
methods, so old code should work as it did before.

Current status:
#11637 Moves navigation code - I'll clean up this one.
#11838 Moves the layer management (new and ready to be discussed).

My Roadmap:
After #11838 is merged, I would like do the minor but unrelated
improvements:
* Move the refreshTitle()-Code out of MapView
* remove the AudioPlayer.reset()-calls
* Clean getLayerInformationForSourceTags()

For the navigation component code, I would like to modify #11637 to get
all coordinate conversion code to the ZoomData class. This would allow
us to change the map rendering code to work on a ZoomData instance
instead on the NavigationComponent and thus allow background rendering
(again, OpenGL-Plugin related).

Feel free to post any thoughts you have on this and any problems you see
;-).

Michael Zangl

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

Re: [josm-dev] Cleaning MapView

[Michael Zangl]

Am 08.09.2015 um 14:28 schrieb Dirk Stöcker:
> On Tue, 8 Sep 2015, Michael Zangl wrote:
> 
>> Currently, MapView is a collection of global flags, variables and lots
>> of stuff that has nothing to do with simply viewing the map. Some fields
>> are not even accessed by MapView itself and only used as global flag.
> 
> If you modify MapView, please keep one major goal in mind: E.g. in
> conflict resolution and relation view it would be a good idea to display
> different datasets (e.g. before, after). If the whole code can be
> capsulated enough, so that this is possible, that would be a major step
> forward, especially for conflict resolution. Mainly this means MapView
> (the view component, not the stuff around) should be reusable in
> different places and accept different data sets.

Yes, this is my main goal. I also thought of a small overview MapView in
the sidebar to not get lost when mapping details so easily. The long
term goal should be to make the MapView a real view that can be
instanced as many times as you want (even 0 times, which allows you to
run JOSM without a GUI).

The layer code I wrote already supports multiple layer sets, so you can
even have one view displaying the old OSM state + Bing and one view
displaying the new state + Bing.

Michael


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

Re: [josm-dev] JosmPlugin, Catching the DataDelete Event

[Michael Zangl]

Am 25.11.2015 um 13:55 schrieb Paul Hartmann:
>
> The cleanest solution is to patch JOSM core so your plugin can intercept
> the delete action. (Similar to DatasetListener, but the "listener"
> returns a boolean value which tells JOSM to continue or abort the delete
> action.)

An even cleaner way would be to pass an Event-Object with a
cancel()-method on to the listener. This would allow for more additions
- both parameters and return values - in the future without breaking the
API.

Michael

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

GSoC-Core: Status after 4 weeks

[Michael Zangl]

Hi,

A short note on the current GSoC progress for plugin writers and
interested users.

4 weeks ago I started to restructure some of JOSM main classes. A lot
has changed in the last few weeks. Some of the changes are affecting
plugins and large parts of JOSM, this is a short summary.
- Main.getLayerManager() should be used to access all layers. You can
add and remove layers there. Listeners fire in EDT now so this should
save you some code. You don't have to check if the map frame is
displayed, the layer manager will then simply be empty.
- The initializeMapFrame(old, new) calls should only be used to make
things on the map view (add listeners, modify UI).
- initializeMapFrame(...) is called after the first layer was added.
- Layer listeners are not that tolerant any more. Add them only once and
only remove the ones you added (and remember to remove them...)
- JOSM Tests are changing to use the new JOSMTestRules class. It allows
more control over the environment your test is run in and needs less
time to set it up.
- You should trigger a repaint for a single layer by calling
layer.invalidate()

Old methods are deprecated and have a javadoc comment explaining how to
migrate. Although I try to provide as much compatibility as possible
there may be some bugs due to changes in the code.

What will change:
- Layers get a new paint() method. You can then directly access the
MapViewState during that paint call. This will allow us to do
parallel/asynchronous/partial draws in the future.
- Layers get a replacement for hookUpMapView() that will allow them to
support multiple MapView instances.
- The pasteBuffer will be removed since we can use the system clipboard
for that (note for users: You can copy+paste between two different JOSM
windows then)

Methods/fields will be deprecated until the end of the year.

Feel free to post your thoughts on the changes. You can find the things
I am currently working on there:
http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2016/AcceptedProjects/JOSM_core
https://josm.openstreetmap.de/query?keywords=~gsoc-core

Michael

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

[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] 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] How do I edit big relations and detailed contours now that XML style is removed?

[Michael Zangl]

Hi,

Which style are you using?

MapCSS styles can be pretty fast. It depends on the style you used how
fast it really is. You can use --trace to display the rendering times
(style preparation and actual drawing)

Some things to keep in mind for style performance:
- [key=value] selectors use a fast lookup. Use them as much as you can.
- [key] selectors (and other selectors requiring the presence of a key)
are only taken into account for that single key.
- * selectors are very expensive.
- Avoid complex expressions

Style computation is cached. The most dominant work is to actually paint
the image. Those are things you should avoid:
- Dashed lines
- Texts, especially texts on ways
- Icons
- Multiple draw passes per element (outlines, ...)

So you should get MapCSS drawing pretty fast by creating your own style.

Michael

PS: In my opinion, we should even remove the wireframe mode. MapCSS can
handle those simple things almost as fast as the current wireframe
implementation.

Am 28.03.2016 um 14:49 schrieb Ilya Zverev:
> Hi,
> 
> Two weeks ago XML style and the corresponding infrastructure were removed 
> from JOSM (see https://josm.openstreetmap.de/ticket/12282). I was a frequent 
> user of that style, because it is much faster than the MapCSS one. Especially 
> when there are hundreds thousands of nodes in a view.
> 
> Today I've tried to fix the multipolygon relation of lake Ladoga: 
> https://josm.openstreetmap.de/ticket/12282 (2k members), and when zoomed out, 
> JOSM works with 1 frame per 5 seconds, even for button presses. A month ago I 
> would just enable the XML style and proceed to fix the relation. Now the only 
> options seems to be enabling the wireframe mode. But it is too bare for any 
> serious work.
> 
> So, is there a way to have a custom build with XML styles or to enable these 
> the hard way?
> Did removing XML styles make anything better in JOSM?
> 
> IZ
> ___
> 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

GSoC: Restructuring JOSM core

[Michael Zangl]

Hello,

I am Michael Zangl. For this year's GSoC I am planing to restructure
some core components of josm.

There are currently lots of global references and circular dependencies
in this code. Especially Main and MapView have many unwritten
implications and do a lot of instanceof.

My goal is to make the structure of those more flexible. Starting next
week, I will work on moving global state to new classes. In three
months, I hope to have restructured the map view classes so that the
view component can be used multiple times.

I am not planing to implement any new features. Some small ones will
come along the way and there might be some minor changes in the visual
appearance. The bug report system will be improved by allowing
developers to add more data to bug reports than just the stack trace.
Some API will change - especially to allow for new features like
multiple MapViews. But there will be a compatibility layer for some time
so that most old plugins should work without any changes.

I try to minimize the impact for users of the latest builds. Every
version should be usable. But you might encounter more bugs than usual,
especially when using plugins I did not think of. Feel free to file them
in the tracker and add me (michael2402) - I will have a look at it.

If you are interested in the progress, have a look at the timeline.
There are links to all relevant issues:
http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2016/AcceptedProjects/JOSM_core

Michael Zangl

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

GSoC is over - core results

[Michael Zangl]

Hi all,

Google summer of code has officially ended.

I was working on the core of JOSM a lot for the past three months. You
probably didn't notice much, except for some bug report windows popping
up when using the latest JOSM version.

But there were a lot of changes under the hood that should make JOSM
more robust in the long run. But you may have noticed the side effects
of them while using JOSM:
- The bug report dialog is easier to use
- JOSM won't crash completely on rendering problems - you can still save.
- Copy and Paste supports pasting between windows
- A new paste-at-source action
- Download areas are displayed correctly in every projection.

A new imagery rendering code will come in 16.9, it will then allow you
to use imagery for every projection.

Feel free to report any problems you encounter.

Main changes for (plugin) developers are:
- You can use Main.getLayerManager() to access the layers. No need to
check if the map view was created
- Register listeners on the layer manager instead of the map view
- Listener registration order is enforced - you cannot add them twice.
- Your layers should call invalidate() every time they are changed - no
need to use the isChanged flag any more.
- You should try to avoid accessing Main.map.
- There is a new MapViewPath class. It makes drawing lines easier.
- Do not use the JOSM Predicates class any more
- You can use multiple MapViews to e.g. display an old version of the
data. Imagery support is on the way.
- You can access preferences by e.g. creating a ColorProperty object and
then calling get()/put() on it. No need for the Main.pref.get...
methods. You can even add a listener on that object to get notified for
changes of that specific preference. Create a cached version of it using
.cached() if you access it often.

A more complete project history can be found at:
http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2016/AcceptedProjects/JOSM_core

Michael

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

Re: 16.10 release

[Michael Zangl]

Hi,

I am one of those that could not really find time the last weeks.

#13809 is the only major issue. It is only related to testing.
#13724 I could not find a cause for this one. A release would be
beneficial here to get debug data if anyone triggers it again.
#13604 and #13725 are only annoying but won't do any harm.

#13665 is very old but was unoticed until now since validation is
stricter now.

Suppressing the error message will allow the user to continue working
with JOSM in most cases for the active issues, so I'd say we can give it
a go.

Michael

Am 31.10.2016 um 19:45 schrieb Vincent Privat:
> Hi,
> There are a number of long-standing defects in 16.10 milestone that I would
> like to see closed for the release, but it seems I am not the only one who
> lacks time to fix them:
> https://josm.openstreetmap.de/milestone/16.10
> 
> On the other hand I think the current development state is far more stable
> than previous tested release, so maybe we could release now.
> 
> What do you think? Is there at least a ticket really blocking the release?
> 
> Vincent
> ___
> 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: [GSoC] Project proposal

[Michael Zangl]

Hi,

Yes, this is all you need for the proposal - along with some other
information mentioned there (your experience, ...). Don't worry to much
about visual details for now ;-).

I strongly suggest that you try to work with the JOSM source a bit. You
might even find some small things to tweak, feel free to create a ticket
with the patch on track then.

Michael

Am 13.03.2017 um 16:37 schrieb Madhavan Seshadri:
> Hi Michael,
> 
> Thank you so much for your suggestions.
> 
> I shall try to come up with the Mock-up by the end of this week and
> shall email you the same for comments. Hopefully, the designs will be
> beneficial for the proposal.
> 
> As such is the basic UI Mockup + proposed UI changes +  project timeline
> is sufficient for the proposal?
> 
> Best Regards,
> Madhavan
> 
> On 13 March 2017 at 18:13, Michael Zangl
> <openstreet...@michael.fam-zangl.net
> <mailto:openstreet...@michael.fam-zangl.net>> wrote:
> 
> Hi Madhavan,
> 
> Using the ticket as a starting point is a good way to go. For the GSoC
> project, you are free to suggest whatever you want - feel free to use
> your creativity.
> 
> You are free to search the features for yourself. You could try to
> improve the way Plugin Buttons integrate into JOSM (try installing all
> available plugins and see how the tool bar and menu looks then).
> 
> You can have a look at other components as well - the tool bar, the side
> menu, the context menus, tool bars of some dialogs, ...
> 
> In the end, there should be a proposal that covers what you want to do
> in the 3 months of GSoC. This can be a short time so don't bring a list
> that is too long, but simply moving some menu items would not be enough.
> You can always mark things as optional.
> 
> If you have questions or some design proposals (Mock-Up, ...), feel free
> to ask them here. You can also try using our ticket system (track) to
> answer to that ticket or to create a new enhancement ticket if you feel
> the need that something else should be changed. We use track a lot and
> you will be working with it during GSoC to discuss patches/features.
> 
> Michael
> 
> Am 13.03.2017 um 07:30 schrieb Madhavan Seshadri:
> > Hi JOSM Development Team,
> >
> > I am Madhavan Seshadri and I study Computer Science at Nanyang
> > Technological University Singapore. I have previously used JOSM
> during my
> > internship at BMW Munich and I am really excited to contribute to the
> > development of this tool. I have prior experience in developing UI
> with
> > JAVA Swing and also have an experience in making docking panel
> using Java
> > Swing.
> >
> > As such, I would be particularly interested in improving the UI of
> the tool
> > by starting with the following ticket
> > https://josm.openstreetmap.de/ticket/13456
> <https://josm.openstreetmap.de/ticket/13456> . Kindly let me know on
> how I
> > can get started with writing the proposal and what should be the
> necessary
> > features/design I should be including in the same.
> >
> > Best Regards,
> >
> > Madhavan
> >
> 
> 
> 
> 
> 
> -- 
> Seshadri Madhavan

Re: [GSoC] Project proposal

[Michael Zangl]

Hi Madhavan,

Using the ticket as a starting point is a good way to go. For the GSoC
project, you are free to suggest whatever you want - feel free to use
your creativity.

You are free to search the features for yourself. You could try to
improve the way Plugin Buttons integrate into JOSM (try installing all
available plugins and see how the tool bar and menu looks then).

You can have a look at other components as well - the tool bar, the side
menu, the context menus, tool bars of some dialogs, ...

In the end, there should be a proposal that covers what you want to do
in the 3 months of GSoC. This can be a short time so don't bring a list
that is too long, but simply moving some menu items would not be enough.
You can always mark things as optional.

If you have questions or some design proposals (Mock-Up, ...), feel free
to ask them here. You can also try using our ticket system (track) to
answer to that ticket or to create a new enhancement ticket if you feel
the need that something else should be changed. We use track a lot and
you will be working with it during GSoC to discuss patches/features.

Michael

Am 13.03.2017 um 07:30 schrieb Madhavan Seshadri:
> Hi JOSM Development Team,
> 
> I am Madhavan Seshadri and I study Computer Science at Nanyang
> Technological University Singapore. I have previously used JOSM during my
> internship at BMW Munich and I am really excited to contribute to the
> development of this tool. I have prior experience in developing UI with
> JAVA Swing and also have an experience in making docking panel using Java
> Swing.
> 
> As such, I would be particularly interested in improving the UI of the tool
> by starting with the following ticket
> https://josm.openstreetmap.de/ticket/13456 . Kindly let me know on how I
> can get started with writing the proposal and what should be the necessary
> features/design I should be including in the same.
> 
> Best Regards,
> 
> Madhavan
> 

Re: JOSM enhancements vs. separate plugin

[Michael Zangl]

Hi,

About your concrete example: There are several questions to think of:

* Is your functionality a generic task? (in your case, this would be 
something like "create a convex hull")


* Is that functionality required by a lot of users?

* Is your functionality approved by the community? Or will there be 
objections? In your case, you should especially mind if your plugin 
creates "correct" results and if it can be applied by a unexperienced 
user without creating incorrect data.


* Does it integrate into JOSM in an intuitive way? We try not to add 
more buttons to the main menu. A nice example is the reworked download 
dialog last year: It added some overpass download features while at the 
same time making the UI easier to understand.



So if there is a place where this feature could be included that does 
not interfere with other functionality (e.g. in a preset, ...) and is 
universally usable, it can/should be included in core. In your case, the 
script is so special that it may be very useful for other people doing 
exactly the task you do, but not for the general audience of JOSM. This 
is why a plugin is best in this case.



There are several more reasons why we add a functionality to core. They 
include:


* It is a function that allows basic access to the Openstreetmap data. 
Like the notes layer: There are probably relatively few people using it 
and it would be easy to extract to a plugin, but it is a traditional 
feature of the OSM website.


* It is a function that many other plugins / workflows may depend on. 
Like downloading Data using Overpass.


* It is a feature that is used by JOSM internally and where providing it 
for the user just means an other button, but not maintaining more code. 
Like the Join overlapping Areas tool.


* The author of that functionality had core commit access and just was 
too lazy to write a plugin for it. One example I did are the color 
filters on imagery layers (mainly because they required core 
modifications any way and were much easier to integrate that way).



Michael


On 09.05.2018 07:25, Jiri Hubacek wrote:

Dear JOSM devs,

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?

Thanks,
jiri

Re: Publish plugin issue

[Michael Zangl]

Hi,

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.


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.


For CI, the way I would do it is to simply build the artifacts inside 
${plugin.build.dir} and add a target to publish them to a maven server. 
I would set the default publish URL to something like "$buildDir/maven" 
and make a parameter to overwrite it for the CI server. That way, we can 
easily test it locally without having to worry about directory layouts 
and the build server can still collect them somewhere centralized.


Michael




On 30.05.2018 20:07, Holger Mappt wrote:

On 2018-05-30 at 11:57 +0200 Dirk Stöcker wrote:

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


Hi,

Build the files to do what with them? Would a nodist directory 
parallel to dist be an option if the JARs are not to be uploaded to 
the repository?


The conflict will occur if the JARs are released later on. An 
svn:ignore will not help in that case. It is better to have separate 
directories for released and not released files.


Regards,
Holger

Re: Publish plugin issue

[Michael Zangl]

The idea of the quasi-standard files is to have them in a structure in 
which IDEs can pull them in automatically.


We only have few plugins that use a build system that could make use of 
such a functionality. And as far as I have seen, most of them use git 
and are outside of the source tree anyways.



This would only really make sense if we convert the plugins to not 
depend on jar-Files but instead use some more modern dependency system 
that supports dependency versioning. That way it would be easier to test 
plugins that depend on each other in different version combinations and 
it would be easier for us to reporduce plugin errors by not only loading 
the plugin list of that user, but instead loading the exact plugin 
versions the user used including the source tree to our IDE for debugging.


This would require many changes to JOSM and the way JOSM is built. We 
are far away from this (e.g. see #8269).



Michael


On 31.05.2018 08:27, Dirk Stöcker wrote:

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

Re: YourKit free license for JOSM core developers

[Michael Zangl]

Hi,

I'm interested (since I already did quite some profiling on the 
rendering stuff).


But to be honest, I probably won't have the time to do anything useful 
in that direction this year.


Michael

On 22.06.2018 19:46, Vincent Privat wrote:

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

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


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

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

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


On Mon, 18 Jun 2018, Vincent Privat wrote:

In return they require that we place a small free-form text

acknowledgment/testimonial at the project web site. The acknowledgment
should contain:

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

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



Can we choose that text? I'd prefer an honest text instead of Marketing
BlaBla.

Like

JOSM core developers are uing the https://www.yourkit.com/
java/profiler/">YourKit Java Profiler, as we found other tools
lacking required functionality for profiling. YourKit supports open source
projects by granting developers free licenses.

@Dirk: no objection to add this to the JOSM website?




Would it be ok on one (or more) of the development related pages like

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

That's one click away from the start page.

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

Re: frozen editor while panning or zooming of the map

[Michael Zangl]

Hi,

No, getResponseCode() is not only for logging. It just happens to be the 
first method that is called on the HTTP result and triggers the Thread 
to wait for the HTTP response (therefore the long wait). Since we need 
the response any way, it won't be a noticeable performance improvement 
to wrap that block in an if statement.


Tile loading should be in background. You can completely ignore those 
loader threads and need to focus on the AWT Event Thread instead. This 
is the thread that should not be blocked. It can be blocked by several 
things, e.g.:

* Synchronisation (waiting e.g. for a tile thread)
* Graphics rendering (filters / ...)
* Stop-the-world garbage collection
* ...

All the things you *should* not see but something happened in your case 
that triggered one of those many possible events.


Since your freeze are multiple seconds, they might be long enough for 
you to trigger a stack trace. For this, you need a tool that generates 
such strack traces (e.g. VisualVM) connected to JOSM and ready to do a 
stack trache just by klicking one button (open the correct tab, put the 
window next to JOSM). Once JOSM freezes, quickly trigger that button. If 
you are fast enough, you get the exact spot where JOSM spends it's time.


Michael

On 10.09.2018 01:11, Stephan Knauss wrote:

Hello,

I sometimes suffer delays of 10-15s when panning or zooming the map.

I had the impression it started to become worse when tile serving was 
switched over to https, but switching back to http did not fully fix it.
With JOSM being updated in parallel all not that great to track down 
such issues. Just seeing in the terminal window large gaps between tile 
requests. Hiding imagery tiles always makes it fast. So it is certainly 
related.


So today I tried again to reproduce it, this time with YourKit Profiler 
connected.


I noticed some shorter delays, but couldn't fully reproduce the extreme 
delays.


Majority of time (about 60%) was spent in what I guess is tile loading:
HttpClient.java:91 
org.openstreetmap.josm.tools.HttpClient.connect(ProgressMonitor)


I have typically the two DG layers active sometimes also esri and bing 
to compare the images and alignment. With my large screen having 4k 
resolution, I might have a significant larger window visible than the 
average user.
I sometimes feared that mapbox might throttle the tile delivery. My 
connection itself is a fast 50 MBit link which typically is fast towards 
mapbox.


I then thought to make it a bit harder for JOSM and reduced the maximum 
connections per host down from 12 connections to 6 connections.


I got multiple seconds of frozen map now. After panning or zooming the 
view is frozen. Mouse still moves, but the line I am currently painting 
no longer follows the cursor. Just jumps back after five to ten seconds.


Now the majority of time is spent here:

HostLimitQueue.java:30 
org.openstreetmap.josm.data.cache.HostLimitQueue.poll(long, TimeUnit)


Can you please give some high-level explanation on how the GUI is 
connected to tile loading?


My expectation would be that tile loading happens in the background. In 
case of a blocked download (for whatever reason) my expectation would be 
that just the background tiles are not updated. panning, zooming or 
editing should not wait on it.
Is there a critical section somewhere which would be better not shared 
between the editor and tile loading?


How much personal details is recorded in the profiler snapshots? Would 
it help if I share one? Anyone more experienced interested in running a 
profiling session via skype?



If I read the call tree correctly, then below:
HttpClient.java:91 
org.openstreetmap.josm.tools.HttpClient.connect(ProgressMonitor)

the routines
HttpClient.java:149 <...> 
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode()

and
HttpClient.java:149 <...> java.net.HttpURLConnection.getResponseCode()

use 40% of the time there. Do I get it right that this is only used for 
logging? Maybe only do this then in case log-level is at least info


### Eclipse Workspace Patch 1.0
#P JOSM
Index: src/org/openstreetmap/josm/tools/HttpClient.java
===
--- src/org/openstreetmap/josm/tools/HttpClient.java    (revision 14108)
+++ src/org/openstreetmap/josm/tools/HttpClient.java    (working copy)
@@ -144,13 +144,15 @@
  try {
  connection.connect();
  final boolean hasReason = reasonForRequest != null && 
!reasonForRequest.isEmpty();

-    Logging.info("{0} {1}{2} -> {3}{4}",
-    requestMethod, url, hasReason ? (" (" + 
reasonForRequest + ')') : "",

-    connection.getResponseCode(),
-    connection.getContentLengthLong() > 0
-    ? (" (" + 
Utils.getSizeString(connection.getContentLengthLong(), 
Locale.getDefault()) + ')')

-    : ""
-

Re: JOSM developers meetup at Karlsruhe?

[Michael Zangl]

Hi,

I'll be coming on October 20th ;-)

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

Server down?

[Michael Zangl]

Hi,

I just tried to access SVN / Website and they seem to be down.

Michael

Re: The (dark) future of Java on desktop

[Michael Zangl]

I don't think it's worth speculating now.

(1) The linked document mostly focuses on Java web start (which is just
a convenience for some users - but we can ship JOSM otherwise, e.g.
using a launcher like many java programs do) and other non-JOSM
technologies (we have only one class depending on JavaFX)

(2) For Swing/AWT (that's what we use), I could not find any hint that
it will be dropped. Instead, Oracle is stating that it will be supported
at least until 2026 - that's 8 years. Finding a programming framework
that will be supported in 8 years is very difficult. Even web browsers
change faster than this and many web applications that worked 5 years
ago are already broken.
(They mentioned the java 11 release explicitly because it is a LTS release)

Don't worry, we will be fine with java for now ;-).

And if one day we won't, computers will be so powerful that we can
transpile everything to javascript :D

Michael

Am 08.03.2018 um 23:54 schrieb 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)
>>>
>>

Re: JOSM developers meetup at Karlsruhe?

[Michael Zangl]

On 15.10.2018 19:55, Dirk Stöcker wrote:
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.


OK, that's clear. That also my opinion to always have a backup plan in 
case things get bad / people leave the project / ...


@All
I'm looking forward to discuss all those issues with you and find a way 
that would work for JOSM.


Michael

Re: JOSM developers meetup at Karlsruhe?

[Michael Zangl]

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?

[Michael Zangl]

I think #15229 alone would be enough for those two days.

When we talk about that (and about reorganizing the plugins) we will 
probably come across many things we could change to make plugin 
integration more robust.


For example, we could change the @since Javadoc-tags, to a real 
@ApiVersion annotation to mark this public API
That way, we could test which API the plugin is compatible with 
automatically and add sonar rules to check for e.g. method calls that 
are not annotated (reason for an annotation: It is much easier to access 
using compile time tools)


One thing that came to my mind is test-reorganization so that they match 
the structure of #15229 and that we can have per-module test results. 
And we should discuss ways to re-organize the sources in a way that we 
get IDE support for the dependencies.


Seems like I should be planning to stay two days in Karlsruhe...

Michael

On 14.10.2018 21:05, Vincent Privat wrote:

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

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

Do you have something else in mind?


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


Hi,

are there any specific issues we will be working on those days?

Michael

On 03.09.2018 22:36, Vincent Privat wrote:

Hello,
I was thinking for quite some time about setting up a meeting between

JOSM

developers somewhere in Germany (for convenience).
As Christine and Frederik are inviting OSM developers to Karlsruhe on
October 20th-21st, I just registered myself!
Would other team members be interested? I'd love to meet everyone in

person!

As for JOSM projects/activities for this hack week-end, there are plenty

of

them to work on, it will depend on who's there :)
Cheers,
Vincent

Re: JOSM developers meetup at Karlsruhe?

[Michael Zangl]

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
* Switch to a different / decentralized source versioning system?
* Change the project layout fundamentally (different source dir layout)
* Change the way in which JOSM is started (e.g. to replace webstart)

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


Michael

On 15.10.2018 13:43, Dirk Stöcker wrote:

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

Re: Caching mechanisms on GPX layers

[Michael Zangl]

Hi,

I just had a short look at the patch that is attached to the ticket, 
assuming it contains the code you used to split things.


I did not have a deep look at it, but from what I can tell, you copy 
over the waypoints to a new layer.


Mind that this should not be done. New WayPoints always need to be 
created for the new layer. So you need to call the WayPoint copy 
constructor for every waypoint you add to the new layer.


The connectivity is cached using those waypoint objects.

Michael

On 15.09.2018 03:48, 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?

Thanks,
Niklas (Bjoeni)

Re: Plugin installation without restart

[Michael Zangl]

Hi,

A plugin update always requires a restart - you cannot get around this.

The technical reason is that JOSM cannot unload the old plugin classes. This is 
why an activation of a plugin is possible without restart, but deactivating it 
is not.

Am 27. Februar 2019 13:33:49 MEZ schrieb Jiri Vlasak :
>Hi Gerd,
>
>thanks for your time. I am pretty sure I miss something trivial.
>
>On Sat, Feb 23, 2019 at 08:10:12AM +, Gerd Petermann wrote:
>> Hi Jiri,
>> 
>> my understanding is that your plugin either requires a restart (set
>plugin.canloadatruntime to false in build.xml)
>
>The `canLoadAtRuntime = true` should be set properly [1].
>
>> or it should work so that it reacts on a event to rebuild everything
>(maybe costly)
>
>I am confused a little bit with "reacts on a event" part. The plugin
>constructor add entries to menu:
>
>public class MapathonerPlugin extends Plugin
>{
>/**
> * Constructs a new {@code MapathonerPlugin}.
> */
>public MapathonerPlugin(PluginInformation info)
>{
>super(info);
>MainMenu mm = MainApplication.getMenu();
>JMenu hm = mm.addMenu("Mapathoner",
>tr("Mapathoner"),
>KeyEvent.VK_M,
>mm.getDefaultMenuPos(),
>ht("/Plugin/Mapathoner"));
>
>hm.setMnemonic(KeyEvent.VK_M);
>
>mm.add(hm, new BatchCircleBuildingAction());
>mm.add(hm, new BatchOrthogonalBuildingAction());
>mm.add(hm, new BatchLBuildingAction());
>hm.addSeparator();
>mm.add(hm, new PickResidentialAreaAction());
>}
>}
>
>Which should be ok ("Adding a menu entry to the main menu in the plugin
>Constructor" [3]). Also, shortcuts are bound to actions.
>
>Thanks for any pointer,
>jiri
>
>[1]: https://gitlab.com/qeef/mapathoner/blob/master/build.gradle
>[2]:
>https://gitlab.com/qeef/mapathoner/blob/master/src/main/java/org/openstreetmap/josm/plugins/mapathoner/MapathonerPlugin.java
>[3]:
>https://josm.openstreetmap.de/wiki/DevelopersGuide/PluginInstallationWithoutRestart
>
>> Gerd
>> 
>> 
>> Von: Jiri Vlasak 
>> Gesendet: Dienstag, 19. Februar 2019 07:47
>> An: josm-dev@openstreetmap.org
>> Betreff: Plugin installation without restart
>> 
>> Dear JOSM devs,
>> 
>> I would like to ask about the difference between installing and
>upgrading JOSM
>> plugin. In my case, the installation does not the restart of JOSM
>[1]. However,
>> when the plugin is upgraded, the new functionality does not work
>until restart.
>> 
>> The plugin adds JMenu with multiple options.
>> 
>> Thanks,
>> jiri
>> 
>> [1]:
>https://josm.openstreetmap.de/wiki/DevelopersGuide/PluginInstallationWithoutRestart
>> 

IntelliJ vs Eclipse

[Michael Zangl]

I noticed that a lot of devs have changed from Eclipse to IntelliJ

The free community edition is fine for working on JOSM and we have some 
ultimate licenses available if any core dev needs them.


We currently have those build systems checked into our svn repository:
* ant
* Eclipse
In #17218 [1] I added a first patch to support IntelliJ as well.
The problem is: If we add support for IntelliJ, we have to update 3 
build systems every time we change something. So it would be best to 
drop Eclipse then. Eclipse was not developed that much in the last view 
years and lacks behind IntelliJ a lot, especially when it comes to 
debugging.


Therefore, I would like to get a short heads up from JOSM core devs, if 
you are using (or want to be using) IntelliJ or Eclipse (or if you don't 
care).


It is probably best if we continue the discussion in the ticket.

Michael

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

Re: warnings after importing PT_Assistant plugin project

[Michael Zangl]

Hi,

You cannot configure IntelliJ to use Subversion - that plugin only uses GIT.

If you want the automated plugin versioning to work, you need to check 
out the plugin from the git repository. You probably did not do that and 
just downloaded the plugin ZIP file - this will work fine to do some 
testing, but for achtual development you should use git.


Michael


On 03.03.20 12:32, Jiri Vlasak wrote:

Hi,

On Tue, Mar 03, 2020 at 08:16:20AM +0530, Vaibhav Bisht wrote:

Hello,
I have recently moved on from eclipse to IntelliJ ide now the problem is
that when I imported the project in the IDE I got three following warnings
WARNING: Could not detect the project version, you are probably not
building inside a git repository!
WARNING: The project version is currently the default value `unspecified`.
WARNING: To change the version number, either build in a git-repository or
set the version manually by adding the line `project.version = "1.2.3"` to
the Gradle build script.

I think that there could be some build issues here. Please let me know what
it is


so it looks like you don't use git for development. Maybe you use svn and need
to configure IntelliJ to use Subversion?

jiri