[JPP-Devel] Please use the ChangeLog!
Hi together! We have a ChangeLog file now. It would be very nice to use it. I know this needs a bit of adaption and discipline ... Michaël? Regards, Sascha - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Please use the ChangeLog!
Oups :-! Thanks for the reminder, I feel I will have hard time to get well-disciplined ! Michaël Sascha L. Teichmann a écrit : >Hi together! > >We have a ChangeLog file now. It would be very >nice to use it. I know this needs a bit of >adaption and discipline ... Michaël? > >Regards, > Sascha > >- >This SF.net email is sponsored by DB2 Express >Download DB2 Express C - the FREE version of DB2 express and take >control of your XML. No limits. Just data. Click to get it now. >http://sourceforge.net/powerbar/db2/ >___ >Jump-pilot-devel mailing list >Jump-pilot-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] JTS/CursorTool side effects with shared vertices from shapefile?
Sascha, See my comments below. Sascha wrote: "It would be nice to have a "immutable policy" for coords and geometries but we'll have to catch all the horses first." Like I said above, I recognize that it would be difficult to catch all the horses running loose already, but we can still encourage plug-in developers to not do this in the future. Sascha wrote: "(Another annoying lock-in problem of a plug-in system that is open too wide ... - 2¢)" I was thinking about this the other day. One side effect of having such a flexible plug-in architecture is that just about every public interface in the program is exposed to plug-in developers. While this is extremely powerful, it also seems to lead to some pretty ugly interdependencies. I'm beginning to realize that is why so many mock objects are required to write JUnit tests for some of my OpenJUMP code. Everything is intertwined. Perhaps this is why Eclipse uses the concept of "extension points". I guess they were trying to narrow down the access points for plug-ins. Pluggable design is a great thing, but it really seems to mess with some other programming concepts like modularity and refactoring. Still, I think we can limits the effects of this by coming up with some guidelines to help plug-in developers. Sascha wrote: "BTW: I'm not sure if the CoordinateSequence idea will save a lot of memory. It may be right that the data is packed more tightly and the object overhead would be trimmed, but we might also see a lot of temporal garbage when using the data. JTS is not 'streamlined' with this idea so I suspect a lot of internal 'new Coordinate(..)'s when we're transforming the data (e.g rendering). AFAIK the packed versions of CoordinateSequence have a SoftReference cache mechanism for toArray() inside. I don't know how often this is really called, but objects hanging at SoftReference tombstones are kept quiet long by the GC. ... Just as a hint. Evaluating this maybe connected with some work and at the end it might turn out that there will be probably little to no gain." I think that this would be good material for the JTS list. Sascha wrote: "If we further take into account that only large data sets with a lot of shared vertices will profit from this I would recommend to think about the ratio effort/work." Yup, this might be only be worth it for large data sets. I wonder if you could do this by making a special implementation of the FeatureCache like I am doing with the FeatureCache. The Sunburned Surveyor On 6/26/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote: > > Sunburned Surveyor schrieb: > > [...] > > Sascha's idea about eliminating duplicate coordinate objects in large > > polygon layers and linesting layers is interesting. I have some > > questions for him on that, but I will put them in another thread so > > things don't get so confusing. > > [...] > > If they are worthy a new thread ... > > > [...] > > I'm sorry if I confused things. I didn't say we should implement > > Sascha's idea, just that I thought it was interesting. :] > > For now: We have side effects. Martin has at least one > plug-in which modifies coordinates in place, > Michaël is modifying z-values in place, Larry stated > that the ISA tools are full of coord.x = ... stuff. > My initial question was asking for side effects so I > see these facts as show stoppers for the idea. > > It would be nice to have a "immutable policy" for coords and > geometries but we'll have to catch all the horses first. > (Another annoying lock-in problem of a plug-in system > that is open too wide ... - 2¢) > > BTW: I'm not sure if the CoordinateSequence idea will save a > lot of memory. It may be right that the data is packed more > tightly and the object overhead would be trimmed, but we > might also see a lot of temporal garbage when using the data. > JTS is not 'streamlined' with this idea so I suspect a lot > of internal 'new Coordinate(..)'s when we're transforming the data > (e.g rendering). AFAIK the packed versions of CoordinateSequence > have a SoftReference cache mechanism for toArray() inside. > I don't know how often this is really called, but objects hanging > at SoftReference tombstones are kept quiet long by the GC. > ... Just as a hint. Evaluating this maybe connected with > some work and at the end it might turn out that there > will be probably little to no gain. > > If we further take into account that only large data sets > with a lot of shared vertices will profit from this > I would recommend to think about the ratio effort/work. > > Regards, > Sascha > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net >
Re: [JPP-Devel] MrSID and ECW ermapper
Peppe, I am going to forward this message to Stefan. He has been very busy lately, and may not have tome to read all of the messages on the JPP Developer List. SS On 6/28/07, Giuseppe Aruta <[EMAIL PROTECTED]> wrote: > Hi Paul and Stefan, > We know that OJ can read SID and ECW raster files, can > I write on OJ Tips Webpage how to activate these > functions (including to be carefull about copyright)? > I think people can have benefits. > > PS. Regarding ECW dlls. I read the ECW SDK > documentation and it seems to me there isn't any > restriction to use their library, except reproducing > their copyright. > > Peppe > > --- Paul Austin <[EMAIL PROTECTED]> ha scritto: > > > Hi Stefan, > > > > I think you are right on the sun-jai, I think I > > remember I had to > > download older versions under gentoo, but now it > > does it so I think > > distribution is fine. > > > > Where was the ermapper jar download from? > > > > Paul > > > > Larry Becker wrote: > > > I think that JAI can be distributed according to > > the "2. License to > > > Distribute Software." section. What are you > > seeing that says > > > otherwise? > > > > > > Jan-Oliver Wagner has posted that the ERMapper > > license phrase "at no > > > charge to the public" is contradictory with the > > terms of GPL/LGPL. > > > See: > > > http://intevation.de/pipermail/freegis-list/2006-September/002959.html > > > > > > I don't agree with Jan's interpretation, but I > > think Stefan did in a > > > previous post. > > > > > > regards, > > > Larry Becker > > > > > > > > > On 6/28/07, Paul Austin <[EMAIL PROTECTED]> > > wrote: > > > > > >> Does anyone know what versions of buoy and > > ermapper we are using? > > >> > > >> Also do we know what the licensing is for the > > ermapper jar (i.e. should > > >> we be distributing it). > > >> > > >> I think that for the JAI libraries we should also > > not be distributing > > >> them according to the license, people have to > > download these themselves > > >> (pain I know) > > >> > > >> > > > https://sdlc3b.sun.com/ECom/EComActionServlet/DownloadPage:~:com.sun.sunit.sdlc.content.DownloadPageInfo;jsessionid=A2C5F28639FAB978AF4582E28AC5E86B;jsessionid=A2C5F28639FAB978AF4582E28AC5E86B?viewLicenceId_5= > > >> > > >> > > >> Paul > > >> > > >> > > > - > > >> This SF.net email is sponsored by DB2 Express > > >> Download DB2 Express C - the FREE version of DB2 > > express and take > > >> control of your XML. No limits. Just data. Click > > to get it now. > > >> http://sourceforge.net/powerbar/db2/ > > >> ___ > > >> Jump-pilot-devel mailing list > > >> Jump-pilot-devel@lists.sourceforge.net > > >> > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > >> > > >> > > > > > > > > > > > > > > > > - > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 > > express and take > > control of your XML. No limits. Just data. Click to > > get it now. > > http://sourceforge.net/powerbar/db2/ > > ___ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > > > > ___ > L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: > http://it.docs.yahoo.com/nowyoucan.html > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Buoy and ermapper
Would it be possible to put together a list on the OpenJUMP wiki that identifies each library used with OpenJUMP, which version is required for the stable release, what the library is required for, and the license it is released under? I can set this page up if someone can help me fill it out. We could then ask plug-in developers to enter information about the libraries required by their plug-ins. This is just a thought. The Sunburned Surveyor On 6/28/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > > Jan-Oliver Wagner has posted that the ERMapper license phrase "at no > > charge to the public" is contradictory with the terms of GPL/LGPL. > > See: http://intevation.de/pipermail/freegis-list/2006-September/002959.html > > > > I don't agree with Jan's interpretation, but I think Stefan did in a > > previous post. > > yep.. i agreed with Jan's interpretation. That is why it is not included > in the download version (or is it?). but some libs are on the src > repository to enable the debugging. For instance there are also some > dll's which we got from JUMP, but i think we should not ship them. > > about JAI.. i am not sure what the problem would be in terms of > licensing? With respect to image libraries: I don't know how far Erwans > project is, but they had some ideas working with another lib (ImageJ) > which i would personally prefer.. in the far future > > stefan > > > > > regards, > > Larry Becker > > > > > > On 6/28/07, Paul Austin <[EMAIL PROTECTED]> wrote: > >> Does anyone know what versions of buoy and ermapper we are using? > >> > >> Also do we know what the licensing is for the ermapper jar (i.e. should > >> we be distributing it). > >> > >> I think that for the JAI libraries we should also not be distributing > >> them according to the license, people have to download these themselves > >> (pain I know) > >> > >> https://sdlc3b.sun.com/ECom/EComActionServlet/DownloadPage:~:com.sun.sunit.sdlc.content.DownloadPageInfo;jsessionid=A2C5F28639FAB978AF4582E28AC5E86B;jsessionid=A2C5F28639FAB978AF4582E28AC5E86B?viewLicenceId_5= > >> > >> > >> Paul > >> > >> - > >> This SF.net email is sponsored by DB2 Express > >> Download DB2 Express C - the FREE version of DB2 express and take > >> control of your XML. No limits. Just data. Click to get it now. > >> http://sourceforge.net/powerbar/db2/ > >> ___ > >> Jump-pilot-devel mailing list > >> Jump-pilot-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > >> > > > > > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Rendering problems affecting the quality of printing
Larry, I know it is very easy to convert to SVG by using the JTS graphics painted on the LayerViewPanel and the Batik libs. I wonder if some of the problems could be eliminated by using the JTS Goemetries and Layer styling information to convert directly to SVG. Just a thought. The Sunburned Surveyor On 6/29/07, Larry Becker <[EMAIL PROTECTED]> wrote: > More surprises (for me). Someone stop me if this is already > documented. If you set the line width to zero, you get very faint > lines. The documentation for BasicStroke says, "If width is set to > 0.0f, the stroke is rendered as the thinnest possible line for the > target device and the antialias hint setting." > > Apparently when you create a new layer, the line width defaults to 1. > I never noticed that you could drag it left to 0, or if I did I must > have assumed it was an error. > > This could be very handy when you are printing and the lines are > showing up too wide on the print device, or just when you have a lot > of linestrings very close together. > > regards, > Larry > > On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > Interesting... It turns out that when rendering antialiased lines, > > Java2D actually draws lines with fractional widths as shown in the > > attached JumpWindow screen capture. This would make it possible to > > modify the Change Style line width slider to support floating point > > values that represent very thin lines. > > > > Larry > > > > On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > > To give a better idea of problem (1), I have attached two jpegs. They > > > were made by doing a screen capture within Inkscape while zoomed to > > > 800%. They are labeled before and after and show the effects of > > > scaling the line width by 0.1 in BasicStyle setLineWidth(). The SVG > > > files were created using Stefan's "Print Image in SVG Format." Other > > > printing plug-ins may already be implementing their own solutions. > > > > > > regards, > > > Larry Becker > > > > > > On 6/26/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > > > Larry, > > > > > > > > This is a great post. Thanks for documenting some of the problems we > > > > are having with the rendering system. Perhaps I need to take a crack > > > > at these with my pluggable renderering system, instead of stand alone > > > > labels. I'll give this some thought. > > > > > > > > The Sunburned Surveyor > > > > > > > > On 6/25/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > > > > The purpose of this thread is to document problems with BasicStyle > > > > > rendering that primarily affect the quality of printing plug-ins > > > > > > > > > > Problem (1): > > > > > > > > > > BasicStyle lineStroke defaults to width 1. See Geoff's "About Line > > > > > Decorations and Printing" thread in the archives: > > > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg00075.html > > > > > > > > > > Proposed solution (1.A): > > > > > > > > > > The problem seems to me that JUMP is starting out with the line width > > > > > way too large. In other applications I have used much smaller default > > > > > line widths. In order to do this we would need to modify > > > > > BasicStyle.setLineWidth(int lineWidth) to use a float instead of an > > > > > int and change setLineWidth(1) to setLineWidth(0.1) or something > > > > > smaller in the constructor. > > > > > > > > > > > > > > > Problem (2): > > > > > > > > > > The relative scale of symbols and text changes when changing from > > > > > screen resolution to printer resolution. See Geoff's ""Re: > > > > > [JPP-Devel] JumpPrinter" thread in the archives: > > > > > http://www.mail-archive.com/jump-pilot-devel@lists.sourceforge.net/msg00998.html > > > > > > > > > > Proposed solution (2.A): > > > > > > > > > > I haven't thought this one through very well, but it would seem that > > > > > we need to have some sort of renderer DPI setting (there's those pesky > > > > > english units again). Unfortunately there doesn't seem to be any > > > > > Java2D support for this concept that I could find, so we would > > > > > probably have to implement the scaling ourselves. Someone else may > > > > > have already thought of a better solution. > > > > > > > > > > There are probably other printer related rendering problems I haven't > > > > > heard about. > > > > > > > > > > regards, > > > > > Larry Becker > > > > > > > > > > -- > > > > > http://amusingprogrammer.blogspot.com/ > > > > > > > > > > - > > > > > This SF.net email is sponsored by DB2 Express > > > > > Download DB2 Express C - the FREE version of DB2 express and take > > > > > control of your XML. No limits. Just data. Click to get it now. > > > > > http://sourceforge.net/powerbar/db2/ > > > > > ___ > > > > > Jump-pilot-devel mailing list > > > > > Jump-pilot-devel@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-de
Re: [JPP-Devel] Rendering problems affecting the quality of printing
@Larry: IIRC the zero policy was introduced by Sun as a reaction to some user complains at bugs.sun.com that lines were vanishing when the scale becomes very small. I can't remember when that was done. Before 1.4? @SS: What do you think does Batik? It simply creates elements from g2d.lineTo(new Line.Double(..)) calls and same for other geometries. There is no magic in there. These primitives are generated by a Java2DConverter which takes a JTS geometry as an input. In pure terms of geometry they are identical! Okay .. at the moment they are piped through Larry's decimating Java2DConverter, but I'm going to check-in the PreciseJava2DConverter from the Print/Layout plug-in as temporal replacement (see Viewport.setJava2DConverter()). This will improve Stefan's SVG plug-in. The only thing that will make the SVG look different will be a different styling. The right sizes of the graphical attributes must have a physical measure. The output medium has to have a physical measure. Than you can determine the right scales. What we need is a concept of a physical size based output device. Renderers must be aware of this. This leads to a lot of refactoring. As an alternative we can build a complete new rendering path, which has to be consistent with the old one. WYSIWYG is another word that comes to mind. What if someone add a new Layerable with new Renderers? Should she or he implement the same logic twice? - Sascha Sunburned Surveyor schrieb: > Larry, > > I know it is very easy to convert to SVG by using the JTS graphics > painted on the LayerViewPanel and the Batik libs. > > I wonder if some of the problems could be eliminated by using the JTS > Goemetries and Layer styling information to convert directly to SVG. > > Just a thought. > > The Sunburned Surveyor > > On 6/29/07, Larry Becker <[EMAIL PROTECTED]> wrote: >> More surprises (for me). Someone stop me if this is already >> documented. If you set the line width to zero, you get very faint >> lines. The documentation for BasicStroke says, "If width is set to >> 0.0f, the stroke is rendered as the thinnest possible line for the >> target device and the antialias hint setting." >> >> Apparently when you create a new layer, the line width defaults to 1. >> I never noticed that you could drag it left to 0, or if I did I must >> have assumed it was an error. >> >> This could be very handy when you are printing and the lines are >> showing up too wide on the print device, or just when you have a lot >> of linestrings very close together. >> >> regards, >> Larry >> >> On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: >>> Interesting... It turns out that when rendering antialiased lines, >>> Java2D actually draws lines with fractional widths as shown in the >>> attached JumpWindow screen capture. This would make it possible to >>> modify the Change Style line width slider to support floating point >>> values that represent very thin lines. >>> >>> Larry >>> >>> On 6/28/07, Larry Becker <[EMAIL PROTECTED]> wrote: To give a better idea of problem (1), I have attached two jpegs. They were made by doing a screen capture within Inkscape while zoomed to 800%. They are labeled before and after and show the effects of scaling the line width by 0.1 in BasicStyle setLineWidth(). The SVG files were created using Stefan's "Print Image in SVG Format." Other printing plug-ins may already be implementing their own solutions. regards, Larry Becker On 6/26/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > Larry, > > This is a great post. Thanks for documenting some of the problems we > are having with the rendering system. Perhaps I need to take a crack > at these with my pluggable renderering system, instead of stand alone > labels. I'll give this some thought. > > The Sunburned Surveyor > > On 6/25/07, Larry Becker <[EMAIL PROTECTED]> wrote: >> The purpose of this thread is to document problems with BasicStyle >> rendering that primarily affect the quality of printing plug-ins >> >> Problem (1): >> >> BasicStyle lineStroke defaults to width 1. See Geoff's "About Line >> Decorations and Printing" thread in the archives: >> http://www.mail-archive.com/[EMAIL PROTECTED]/msg00075.html >> >> Proposed solution (1.A): >> >> The problem seems to me that JUMP is starting out with the line width >> way too large. In other applications I have used much smaller default >> line widths. In order to do this we would need to modify >> BasicStyle.setLineWidth(int lineWidth) to use a float instead of an >> int and change setLineWidth(1) to setLineWidth(0.1) or something >> smaller in the constructor. >> >> >> Problem (2): >> >> The relative scale of symbols and text changes when changing from >> screen resolution to printer resolution. See Geoff's ""Re: >> [JPP-Devel] JumpPr
