[JPP-Devel] VectorialProcedures - Help with read and save shapefiles or others formats
Hi guys, I implements one extension with basic vectorial procedures. At first time I read the layers of OpenJUMP and collect the features, but now I want read external files with extension, like shapefiles and others formats, without open this in OpenJUMP. In my extension I will make a button for localise what archive the user want process a vectorial procedures. After the this he can chose if the resultant layer will be import at OpenJUMP or simply save in same folder with same format. What classes I need to use ? What api help me with that task ? If I need to export same file and save that with a commons formats, how I do that ? Thanks, Leandro Leal - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] VectorialProcedures - Help with read and save shapefiles or others formats
Hi Leandro, Look at "com/vividsolutions/jump/workbench/driver/" I recommend you start with Shapefile driver (ShapefileInputDriver.java). Another interesting improvement will be the option of select and save the result in a output file. In the same directory you will find a ShapefileOutputDriver also. Regards, Nacho 2008/5/16 Leandro Leal Parente <[EMAIL PROTECTED]>: > Hi guys, > > I implements one extension with basic vectorial procedures. At first time I > read the layers of OpenJUMP and collect the features, but now I want read > external files with extension, like shapefiles and others formats, without > open this in OpenJUMP. In my extension I will make a button for localise > what archive the user want process a vectorial procedures. After the this he > can chose if the resultant layer will be import at OpenJUMP or simply save > in same folder with same format. > > What classes I need to use ? > What api help me with that task ? > If I need to export same file and save that with a commons formats, how I > do that ? > > Thanks, > Leandro Leal > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] VectorialProcedures - Help with read and save shapefiles or others formats
See also: com.vividsolutions.jump.io for ShapefileReader and ShapefileWriter. Also org.geotools.shapefile directory. regards, Larry On Fri, May 16, 2008 at 6:07 AM, Nacho Uve <[EMAIL PROTECTED]> wrote: > Hi Leandro, > > Look at "com/vividsolutions/jump/workbench/driver/" > > I recommend you start with Shapefile driver (ShapefileInputDriver.java). > > Another interesting improvement will be the option of select and save the > result in a output file. In the same directory you will find a > ShapefileOutputDriver also. > > Regards, > Nacho > > 2008/5/16 Leandro Leal Parente <[EMAIL PROTECTED]>: > > Hi guys, >> >> I implements one extension with basic vectorial procedures. At first time >> I read the layers of OpenJUMP and collect the features, but now I want read >> external files with extension, like shapefiles and others formats, without >> open this in OpenJUMP. In my extension I will make a button for localise >> what archive the user want process a vectorial procedures. After the this he >> can chose if the resultant layer will be import at OpenJUMP or simply save >> in same folder with same format. >> >> What classes I need to use ? >> What api help me with that task ? >> If I need to export same file and save that with a commons formats, how I >> do that ? >> >> Thanks, >> Leandro Leal >> > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > -- http://amusingprogrammer.blogspot.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] wiki, svn, and more...
Eric, I am sorry that I am responding to your e-mail so late. Thank you very much for such a detailed and well-thought out response to some of our documentation software/management issues. I don't know that we are quite ready to migrate to a Trac software management system, as we're pretty comfortable with our SourceForge site, but I do appreciate the suggestions. However, I do think that two (2) of your suggestions have some real merit, and should be acted upon. The first suggestion has to do with how we organize or categorize bug reports. I'm going to repost this section of your message and ask the other programmers for some comments. The other suggestion about allowing users to offer payment for bug fixes and small feature enhancements also seems to have some merit, and I know it has been mentioned before. I'm a little nervous about it, but I'm willing to put aside some of my concerns to give it a try. I hope it would be a good thing for both users and programmers at the end of the day. Let me cook something up, and I'll let everyone preview and comment. Thank you for your involvement. You were'n't being ignored, I'm just now getting around to cleaning out my Gmail inbox. The Sunburned Surveyor On Tue, Apr 22, 2008 at 4:36 PM, Eric Jarvies <[EMAIL PROTECTED]> wrote: > hello everyone, > > have you considered instead using a subversion/trac setup? the nice thing > about this setup is that it eliminates a lot of redundancy as it relates to > application documentation. for example, as bugs, feature requests, etc., > are reported, those same entries can then be re-purposed as documentation. > if the repo is setup correctly from the get-go, meaning end-user gui stuff > like buttons, menu selections, operations, etc. are indexed in the > bug/feature request menu selections, and associated with the respective > classes/interfaces, then this allows non-programmers to easily report a bug > or feature request to the right place. an example of what i mean is this: > go to openump at sourceforge and select 'submit new bug' and look at the > 'category' pull-down menu selections. in this menu the user has: > interface > jts > misc. > openjump > plugin > wfsplugin > the above selections serve no useful purpose for the average user, who in > all likeliness will be reporting the majority of the problems/bugs. this > means it serves little purpose for those who may work on correcting the > problem. bug/ticket reporting should be designed for the end user, not the > programmer. the association however is what is important to the programmer, > and making sure that the ticket that was reported is associated with the > correct page/portion/snippet of code that in fact is responsible. this > means each source code document should have a plain english reference in > it(commented out), or multiple references throughout the document as is > needed/warranted. > imo, the easiest and best way to do this is by using the gui elements, such > as menu items, icon/button items, and contextual menu items as the means of > reference. thus, if i was using oj, and encountered a bug, or have an idea > of how something could work better(feature request), the oj repo should > offer me the following when i am submitting a ticket: > Submit New Ticket: > pull-down menu #1: > bug > minor(does not work correctly) > medium(works intermittently) > major(does not work) > feature request > core > plug-in > spelling correction > menus > help > operations > appearance > menu > icon > layout > > pull-down menu #2: > vista > xp > os x > linux > > pull-down menu #3: > File > Edit > View > Layer > Tools > Queries > Spatial Query > Attribute Query > Simple Query > Analysis > Generate > Warp > Edit Geometry > QA > Edit Attributes > Generalization > Measure in Feet > Customize > Scripting > Image > Plugins > QA > Window > Help > in the above shortened example, lets say the user selected Bug, OS X, > Tools > Queries > Spatial Query . upon doing so, the respective page(s) of > source code that is responsible for 'Spatial Query' should associated. when > the user writes a summary and submits the ticket, at that point it is > immediately associated with the proper source code page(s). this way, when > a programmer looks to address the issue, he need not hunt around trying to > locate it's exact location. furthermore, upon ticket submission, the user, > and any other user that may view the ticket, can see it's respective > association/source code. > of course, this means that during the setup of the initial repo, all of this > association has to be done. this is something i am willing to do, but will > require on you(programmers) who are familiar with the entire inner workings > of oj, to help me. of course, once it's done, then thereafter it's just a > matter of properly commenting any new source code pages/code snippets in > existing pages. > anther suggestion i will make is that once the above is completed, we take > and create donation pool
[JPP-Devel] Suggested Improvements To Bug Categorization
Eric posted some suggestions to improve the way we categorize our bugs a few days ago. I wanted to repost it and see if any of our programmers had comments on the suggestion: The Sunburned Surveyor Eric wrote: go to openump at sourceforge and select 'submit new bug' and look at the 'category' pull-down menu selections. in this menu the user has: interface jts misc. openjump plugin wfsplugin the above selections serve no useful purpose for the average user, who in all likeliness will be reporting the majority of the problems/bugs. this means it serves little purpose for those who may work on correcting the problem. bug/ticket reporting should be designed for the end user, not the programmer. the association however is what is important to the programmer, and making sure that the ticket that was reported is associated with the correct page/portion/snippet of code that in fact is responsible. this means each source code document should have a plain english reference in it(commented out), or multiple references throughout the document as is needed/warranted. imo, the easiest and best way to do this is by using the gui elements, such as menu items, icon/button items, and contextual menu items as the means of reference. thus, if i was using oj, and encountered a bug, or have an idea of how something could work better(feature request), the oj repo should offer me the following when i am submitting a ticket: Submit New Ticket: pull-down menu #1: bug minor(does not work correctly) medium(works intermittently) major(does not work) feature request core plug-in spelling correction menus help operations appearance menu icon layout pull-down menu #2: vista xp os x linux pull-down menu #3: File Edit View Layer Tools Queries Spatial Query Attribute Query Simple Query Analysis Generate Warp Edit Geometry QA Edit Attributes Generalization Measure in Feet Customize Scripting Image Plugins QA Window Help - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] OpenJUMP Google Summer of Code 2008 Update
I checked the Google Summer of Code timeline this morning. Our two (2) students will need to keep a couple of important dates in mind: July 14, 2008 Mid Term Evaluation August 11, 2008 "Pencils Down" Code Completion This means we'll basically need to be done writing new code by August 11th. I know this deadline will arrive faster than we think. I would like to concentrate on getting a usable "chunk" of code by that time, even if it is just a small chunk. Chris has provided me with a brief written outline of his plans for JTin, and we talked some more when we met in person last week. I feel pretty comfortable with where he is headed. Stefan has asked him for a little more documentation, which is fine. It would be great if he has time to wrap that documentation up in the next week or two. I'm a little more worried about Leandro's project. This is not entirely his fault. Part of the problem is the language barrier, and the other is the complexity of the project he selected. I'm really worried that we might finish the summer without functioning code, much less functioning code that enhances OpenJUMP in some way. I would really like to get some brief documentation on how Leandro will tackle his project so we now where he is headed. This is important, as the document will be part of my evaluation. I believe Stefan has already sent him a suggested outline for this doc. I'd like to have both our students plan on walking me trough their existing code on Monday, August 4th. This will give me a week to put the mid-term evaluation's together. I'll make sure the evalutation for Leandro get's reviewed by Stefan and Nacho. I want to thank Stefan, Leandro, Nacho, and Chris for all of the help with this summer program. The Sunburned Surveyor - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Proposal For JPP Bazaar
In response to a suggestion by Eric I have put together a web site for a proposed "JPP Bazaar". This web site would allow users to post "bounties" or small payments for bug fixes, other improvements, and documentation for OpenJUMP. I believe that such a site may help cultivate a productive environment for continued improvement of OpenJUMP. The main purpose of the proposed site would be to match up users willing to fund small improvements with programmers willing to make these improvements. It would also allow users that seek the same improvement to combine small funding pools to pay for work. I have no idea how much use a site like this would see, but it the traffic wasn't insane I'd be willing to do the following: - Accept requests from users, review these requests, assist the users with editing of the request if necessary, and posting of the requests. - Post the profiles of programmers willing to consider requests. - Coordinate contact between programmers and the users making the requests. - Categorize incoming requests. I would not, however, want to become involved in payment or work performance issues. :] I'd just be running something like a classified ads section... You can view a shell for the site that I created here: http://www.redefinedhorizons.com/jppbazaar/ Note: This is just a sample. None of the hyperlinks are active, and the list of programmers willing to participate may change. (I'd check with all of the programmers before officially launching the site.) Any comments? Is this a good idea? Is it a bad idea? I'm curious what others think... Landon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Suggested Improvements To Bug Categorization
Hei guys, and sorry for having forgotten Erics message too. I agree, we need to review the options for bug submission. I will see over the next days how to change that and what options for customization of the bug report tool we have. thank you Stefan PS: If I haven't done something on it until end of next week, would somebody please remind me? Sunburned Surveyor wrote: > Eric posted some suggestions to improve the way we categorize our bugs > a few days ago. I wanted to repost it and see if any of our > programmers had comments on the suggestion: > > The Sunburned Surveyor > > Eric wrote: > > go to openump at sourceforge and select 'submit new bug' and look at > the 'category' pull-down menu selections. in this menu the user has: > interface > jts > misc. > openjump > plugin > wfsplugin > > > the above selections serve no useful purpose for the average user, who > in all likeliness will be reporting the majority of the problems/bugs. > this means it serves little purpose for those who may work on > correcting the problem. bug/ticket reporting should be designed for > the end user, not the programmer. the association however is what is > important to the programmer, and making sure that the ticket that was > reported is associated with the correct page/portion/snippet of code > that in fact is responsible. this means each source code document > should have a plain english reference in it(commented out), or > multiple references throughout the document as is needed/warranted. > > > imo, the easiest and best way to do this is by using the gui elements, > such as menu items, icon/button items, and contextual menu items as > the means of reference. thus, if i was using oj, and encountered a > bug, or have an idea of how something could work better(feature > request), the oj repo should offer me the following when i am > submitting a ticket: > > > Submit New Ticket: > > > pull-down menu #1: > bug > > minor(does not work correctly) > > medium(works intermittently) > > major(does not work) > feature request > > core > > plug-in > > spelling correction > > menus > > help > > operations > > appearance > > menu > > icon > > layout > > > > pull-down menu #2: > vista > > xp > > os x > > linux > > > > pull-down menu #3: > File > > Edit > > View > > Layer > > Tools > > Queries > > Spatial Query > > Attribute Query > > Simple Query > > Analysis > > Generate > > Warp > > Edit Geometry > > QA > > Edit Attributes > > Generalization > > Measure in Feet > > Customize > Scripting > > Image > Plugins > QA > Window > Help > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Suggested Improvements To Bug Categorization
Ok... as I had now some time already, I modified the tracker groups and categories. I could not add any new selection menu, so we have to live with those 2 options. . Categories : I basically chosed the menu structure (suggested by Eric) . Groups : I changed/added to the OS . The available importance values can not be customized. so we need to live with the rating from 1..10 @Eric: Trac is an option, but it needs maintenance and an extra sever which we don't have. Sourceforge may not be the best.. but a) it meets our needs in general, b) we don't need to maintain the system and c) they are steadily improving. I hope that is reasonable? thank you for your feedback Stefan Steiniger schrieb: > Hei guys, > > and sorry for having forgotten Erics message too. > I agree, we need to review the options for bug submission. I will see > over the next days how to change that and what options for customization > of the bug report tool we have. > > thank you > Stefan > > PS: If I haven't done something on it until end of next week, would > somebody please remind me? > > Sunburned Surveyor wrote: >> Eric posted some suggestions to improve the way we categorize our bugs >> a few days ago. I wanted to repost it and see if any of our >> programmers had comments on the suggestion: >> >> The Sunburned Surveyor >> >> Eric wrote: >> >> go to openump at sourceforge and select 'submit new bug' and look at >> the 'category' pull-down menu selections. in this menu the user has: >> interface >> jts >> misc. >> openjump >> plugin >> wfsplugin >> >> >> the above selections serve no useful purpose for the average user, who >> in all likeliness will be reporting the majority of the problems/bugs. >> this means it serves little purpose for those who may work on >> correcting the problem. bug/ticket reporting should be designed for >> the end user, not the programmer. the association however is what is >> important to the programmer, and making sure that the ticket that was >> reported is associated with the correct page/portion/snippet of code >> that in fact is responsible. this means each source code document >> should have a plain english reference in it(commented out), or >> multiple references throughout the document as is needed/warranted. >> >> >> imo, the easiest and best way to do this is by using the gui elements, >> such as menu items, icon/button items, and contextual menu items as >> the means of reference. thus, if i was using oj, and encountered a >> bug, or have an idea of how something could work better(feature >> request), the oj repo should offer me the following when i am >> submitting a ticket: >> >> >> Submit New Ticket: >> >> >> pull-down menu #1: >> bug >> >> minor(does not work correctly) >> >> medium(works intermittently) >> >> major(does not work) >> feature request >> >> core >> >> plug-in >> >> spelling correction >> >> menus >> >> help >> >> operations >> >> appearance >> >> menu >> >> icon >> >> layout >> >> >> >> pull-down menu #2: >> vista >> >> xp >> >> os x >> >> linux >> >> >> >> pull-down menu #3: >> File >> >> Edit >> >> View >> >> Layer >> >> Tools >> >> Queries >> >> Spatial Query >> >> Attribute Query >> >> Simple Query >> >> Analysis >> >> Generate >> >> Warp >> >> Edit Geometry >> >> QA >> >> Edit Attributes >> >> Generalization >> >> Measure in Feet >> >> Customize >> Scripting >> >> Image >> Plugins >> QA >> Window >> Help - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
