Re: [JPP-Devel] Network Installation
Sunburned Surveyor wrote: Hi, > Thank you for the patch Andreas. I apologize if I missed it earlier. I didn't send it over the list, so you didn't miss anything here. I just made the patch via svn diff ;-) Best regards, Andreas -- l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 18496-11 fax ++49 +228 1849629 http://www.lat-lon.dehttp://www.deegree.org - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] OpenJUMP releases and bug management
Michaël Michaud wrote: Hi, > Here are some thoughts about releases and bug management. > I think we miss some rules to decide when a new version of OJ has to be > released, and that lack of visibility may be a disadvantage for OJ's > adoption. I totally agree with this point. > The release rules should be linked to bug reports and feature requests, > but bug reports have to be sorted before they can be used as a base for > release decision. ACK. > A proposition is to let the default level 5 for bugs which have to be > fixed before a stable release, to use level 1 and 2 for bugs which have > to be fixed ASAP (before any release) and to set less important bugs to > priority 6 or more... (any other suggestion is welcome). > Any one having access to the bug tracker should be able to initiate this > hierarchy, subsequent changes should be asked to the community. > Major releases (version changes) could work the same way but based on > feature requests (feature requests for version 1.2, for 1.3...) I think that's a great idea. Since the list of bugs/feature requests is already quite long, that would make working on it more rewarding, with each bug fixed being one step towards the next release. Best regards, Andreas -- l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 18496-11 fax ++49 +228 1849629 http://www.lat-lon.dehttp://www.deegree.org - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] [udig-devel] Transformation/Reprojection
... you are right Sunburned .. lot's of classes and Interfaces in GT2, but still: a working, yet tested transformation module, already fed with the EPSG codes. choose two and get a mathtransformation is userfriendly, from my point of view. If you need an intermediate cs, you are still free to define it (as wkt string e.g.) and transform to it, and then on. I am still waiting for some sparetime to come around and to start update the cts extension to GT2.3 ... as there was no real feedback from the list (except from Sunburned), I didn't felt no need to hurry on this ... anyway, if somebody else is already working on it, I can maybe give a hand. sunshine & regards from cologne ede -- > Why does everything in GeoTools have to be so hard? > > I spent a few minutes this afternoon looking at their reprojection > code. I had to wind my way through the methods of at least 3 or 4 > classes before I got to code packages in an external plug-in, and I > haven't even hit the source code that actually does the > transformations. > > It seems like part of the complexity may be caused by the fact that > the "user code" can go directly from one spatial reference system to > another. I still think it would be a lot easier to go from the source > coordinate system to a common intermediate system, and then from the > common intermediate system to the target system. (You could still hide > this common intermediate spatial reference system from the end user of > OpenJUMP.) I bet that would eliminate a lot of the "in-between" > classes in GeoTools. > > This system forces all of the transformation logic on the > impelementer, but this same transformation logic is packaged outside > of UDig anyways. At least in the system I described the implementer > only has to worry about getting to and from the common intermediate > system and his own system. > > I'll have to chew on this some more. > > The Sunburned Surveyor > > On 9/4/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > >> We had talked a little the other day about a incorporating third-party >> reprojection code into OpenJUMP. I sent a post to the UDig list, since >> I know they support "on-the-fly" reprojection. >> >> I know we don't necessarily want to mess with "on-the-fly" >> reprojection in OpenJUMP, but maybe we couls use the reprojection code >> from UDig for a stand-alone utility or for a OpenJUMP plug-in. >> >> Jody Garnett put a section on the wiki for us that talks about this: >> >> http://docs.codehaus.org/display/GEOTDOC/Welcome+to+JUMP+Developers >> >> The Sunburned Surveyor >> >> >> >> -- Forwarded message -- >> From: Sunburned Surveyor <[EMAIL PROTECTED]> >> Date: Sep 4, 2007 3:27 PM >> Subject: Re: [udig-devel] Transformation/Reprojection >> To: User-friendly Desktop Internet GIS <[EMAIL PROTECTED]> >> >> >> Jody wrote: "Since this question is asked every couple of months by a >> jump developer it has made its way into the geotools user guide..." >> >> I really apologize about that. I'm sure that I'm the jackass that >> keeps asking the same question. UDig, GeoTools, GeoAPI, Kosmo, SIGLE, >> SkyJUMP, DeeJUMP... >> >> I have a hardtime keeping track of it all sometimes. Please be patient with >> me. >> >> The section you added to the wiki will be very helpful. I will look it >> over and will also forward this message to the JPP Developer List. >> >> Thanks for all of your help. I look forward to trying out UDig on my >> GIS project. :] >> >> SS >> >> >> On 9/4/07, Jody Garnett <[EMAIL PROTECTED]> wrote: >> >>> Sunburned Surveyor wrote: >>> We were discussing options for reprojection/transformation code on the OpenJUMP development list the other day. I know that UDig offers on the fly reprojection, which is why I'm currently trying to download it and get it running. I was curious, is the ,low-level reprojection code something UDig gets from the GeoTools library, or is it code unique to UDig? Does the low-level reprojection code work with GeoTools features, or does it transform individual coordinates? Is it possible to access the API for transformation of individual coordinates? >>> It is from the GeoTools library; you can use the "referencing module" >>> with out depending on any GeoTools feature stuff. It is suitable for >>> OpenJUMP etc... >>> >>> Since this question is asked every couple of months by a jump developer >>> it has made its way into the geotools user guide: >>> - http://docs.codehaus.org/display/GEOTDOC/Welcome+to+JUMP+Developers >>> It seems to me that it would make sense to share reporojection code between OpenJUMP and UDig, especially if we can transform individual coordinate and don't need to deal with the feature model problem. >>> Yes it makes sense to share; interfaces via geoapi and implementation >>> via geotools, and hopfully swing widgets and swt widgets as well ;-) >>> >>> Don't worry
Re: [JPP-Devel] About embedded help
Hi SS you wrote: "We have the contect sensitive help in OpenJUMP wired to Open the URL to the wiki. We then provide select PDF files for important help topics as a download on SourceForge for those that might not always have an internet connection." I still consider that OJ has to open a small HELP.PDF file (people have to download it and put in a OJ folder). A small PDF (with all the essential information about the tools and functions) could be translated in different languages. Even if it is not regularly upgraded as the wiki page, it is very usefull. This will help people who doesn't use english to understand the function. I can provide Italian translation, our beloved users or developers can translate in whatever language they use. E.g. the main OJ languages (Finnish, French, German) Of coarse we can in OpenJUMP menu also the the alternative to open the regular wiki page, in this case only in English -- Stefan's idea was to use "export to HTML" in the wiki page. This probabily will make the work more easy. Unfortunately this command seems not to work :( -- P.S. This will help also to the "internationalization" of OJ. If we have some help.pdf docs in other languages, there's no need to internationalization all OJ but only the lebels of menus Peppe --- Sunburned Surveyor <[EMAIL PROTECTED]> ha scritto: > Larry wrote: "One of the problems is that once you > have published a PDF, it is around forever > regardless of how out of > date it becomes. The web is always up to date, > which is why most new > software uses web links for help." > > You know, I never thought of that. Thanks for > pointing it out. > > Peppe wrote: "You're right Larry, but I think we > shall consider the > people who cannot be on-line every time they work. > And > also thet probabily there are still places in the > World where Internet is not so availabe whenever you > switch on a laptop (e.g. in Italy! But I would like > to > know the opinion of Ravi from India)." > > This is an excellent point Peppe. > > How is this for a suggestion: > > We have the contect sensitive help in OpenJUMP wired > to Open the URL > to the wiki. We then provide select PDF files for > important help > topics as a download on SourceForge for those that > might not always > have an internet connection. > > The Sunburned Surveyor > > P.S. - Larry - I've never opened up a URL from a > Java program before. > Would it be possible to come up with some code that > would allow a > plug-in developer to do this in a relatively easy > way? I'm not asking > you to write the code of course, i'm just wondering > if it is > conceptually possible or practical. > > > > > On 9/4/07, Giuseppe Aruta <[EMAIL PROTECTED]> > wrote: > > You're right Larry, but I think we shall consider > the > > people who cannot be on-line every time they work. > And > > also thet probabily there are still places in the > > World where Internet is not so availabe whenever > you > > switch on a laptop (e.g. in Italy! But I would > like to > > know the opinion of Ravi from India). > > We probabily can leave both ideas open: 1) a > > connection to the wikipage as on-line help and 2) > the > > possibility to put a small pdf with all the > important > > information to know > > > > regards, > > peppe > > > > > > --- Larry Becker <[EMAIL PROTECTED]> ha > scritto: > > > > > Actually I like the idea that the wiki IS the > help. > > > We can put in a > > > menu item that simply opens the wiki help page. > > > This is the simplest > > > solution and consolidates all of the help work > with > > > no duplication of > > > effort. Keeping PDFs up to date could be a big > > > effort. I have tried > > > to do this on other projects. One of the > problems > > > is that once you > > > have published a PDF, it is around forever > > > regardless of how out of > > > date it becomes. The web is always up to date, > > > which is why most new > > > software uses web links for help. > > > > > > regards, > > > Larry > > > > > > On 9/4/07, Sunburned Surveyor > > > <[EMAIL PROTECTED]> wrote: > > > > Peppe, > > > > > > > > Maybe #2 is the way to go then Peppe. We'll > need > > > to give some thought > > > > to how we organize the PDFs in a directory, > and we > > > should still think > > > > about separating the text from the images in > the > > > PDF files to reduce > > > > layout changes during translation. > > > > > > > > SS > > > > > > > > On 9/2/07, Giuseppe Aruta > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > --- Sunburned Surveyor > > > <[EMAIL PROTECTED]> > > > > > ha scritto: > > > > > > > > > > > I have thought about this question of > > > integrating > > > > > > help into OpenJUMP > > > > > > quite a bit. > > > > > > > > > > > > Here are some of my thoughts, if anyone is > > > > > > interested: > > > > > > > > > > > > [1] We could use the JavaHelp system. It > seems > > > > > > fairly comprehensive, > > > > > > is being developed and maintained by Sun > > > > > > Microsystems, and
Re: [JPP-Devel] Reorganization of OpenJUMP Wiki
Hi SS, I am glad that you open this discussion. I was thinking about since I am interested about how to make OJ more visible for non-english users. I am sending, attached to this email, a "proposal" to internationalized OJ Wiki Page. This sample is in English, but I image similar pages in Finnic, French, German, Italian, etc, all linked together This page would be a sort of "small brother" of the main page (which remains in English). But it must have the essntial about OJ (what's OJ, download, how to setup, how to put the relative language, the docs (in relative language, otherwise in English), the plugin and User and Devel list). Everything in one page. I did this page taking from WIKIs what I thought was important for OJ If you and other developers agree I can try to write the Italian WIKI page as a sample Regards, peppe --- Sunburned Surveyor <[EMAIL PROTECTED]> ha scritto: > I have a short post on the OpenJUMP blog about > reorganizing our > OpenJUMP wiki to be a little more structured. > > If you are interested you can read the post here: > > http://openjump.blogspot.com/ > > The Sunburned Surveyor > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? > Stop. > Now Search log events and configuration files using > AJAX and a browser. > Download your FREE copy of Splunk now >> > http://get.splunk.com/ > ___ > 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Window menu patch
I'm going to check this patch in Paul Austin wrote: > All, > > I have created a patch which should remove the hard coding of the number > of items in the Window menu. This allows use to expand the window menu > as required in plugins without needing to modify > com.vividsolutions.jump.workbench.ui.WorkbenchFrame. > > Can someone apply the following patch to their source on > com.vividsolutions.jump.workbench.ui.WorkbenchFrame and test to make > sure it works with Task frames and attribute frames. (Eclipse Team>Apply > Patch on the file to patch). > > Thanks, > Paul > > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > ___ > 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Window menu patch
Hi Paul, Sorry not to give feed back about your patches (I don't use eclipse neither *nix and always face a problem with the patch file you send - I have to find a solution as this is the standard way to test someone else modification). Anyway, If you commit the change, I'll update my code and test it ASAP. Michael Paul Austin a écrit : >I'm going to check this patch in > >Paul Austin wrote: > > >>All, >> >>I have created a patch which should remove the hard coding of the number >>of items in the Window menu. This allows use to expand the window menu >>as required in plugins without needing to modify >>com.vividsolutions.jump.workbench.ui.WorkbenchFrame. >> >>Can someone apply the following patch to their source on >>com.vividsolutions.jump.workbench.ui.WorkbenchFrame and test to make >>sure it works with Task frames and attribute frames. (Eclipse Team>Apply >>Patch on the file to patch). >> >>Thanks, >>Paul >> >> >> >>- >>This SF.net email is sponsored by: Splunk Inc. >>Still grepping through log files to find problems? Stop. >>Now Search log events and configuration files using AJAX and a browser. >>Download your FREE copy of Splunk now >> http://get.splunk.com/ >> >> >>___ >>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: Splunk Inc. >Still grepping through log files to find problems? Stop. >Now Search log events and configuration files using AJAX and a browser. >Download your FREE copy of Splunk now >> http://get.splunk.com/ >___ >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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
