Re: [JPP-Devel] Language files - an outline

[Giuseppe Aruta]

--- Michaël Michaud <[EMAIL PROTECTED]> ha
scritto:

> Hi Giuseppe,
> 
> I just want to point out another method to change OJ
> language (at least 
> for window users).
> You can change the regional parameters (in the
> windows configuration 
> panel) to the language you choose (ex. english),
> start OpenJUMP, and 
> then, if you want, come back to your original
> settings. OJ will use the 
> regional parameters set at the moment you run the
> JVM starting OpenJUMP.
> 
> Hope this helps.
> Michaël



Hi Michaël

This is probabily what a people with a smart
knowledgment of computers can do. I was thinking about
people who do not know anything about JAVA or anything
else of programming.
These people would take benefits of a chenging
language tool

Peppe



  ___ 
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] Review of Peppe's "List of Functions"

[Giuseppe Aruta]

Hi SS,
and thanks for your review.
Some functions really required a better explanation.
Good job!

Peppe

> I did some more work on the "Edit" top-level menu
> functions today
> after work, although I'm not quite finished. I
> changed some of bold
> funtion names on the wiki to match the actual
> English menu command in
> OpenJUMP. I also touched up some sentence fragments
> and
> past/present/future tense usage.
> 
> I just wanted to let you guys (and especially Peppe)
> know that I am
> still chipping away at my review.
> 
> Good work on the docs Peppe! We'll definitely have
> to get some form of
> this documentaiton into embedded PDF in the future.
> 
> 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] New Italian Language file

[Giuseppe Aruta]

I have just found and corrected some minor errors in
the Italian language file. I also translate the new
Tools fom English to Italian.
I send the file as an attachment of this mail

Peppe


  ___ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

jump_it.zi
Description: 1329960653-jump_it.zi
-
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] Language files - an outline

[Giuseppe Aruta]

Hi Larry

> Perhaps Peppe's use case can be handled by simply
> including all of these
> scripts in the release.  

I only check if it is possible with a simple Jar tool

> I think switching languages
> after the program is
> running would require a lot of rework.

. users can be invited to restart OJ to changer
language..

Peppe


  ___ 
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] Questions About Strings On "Select By Type Plug-In"

[Larry Becker]

Sounds fine to me.

Larry

On 10/8/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
>
> I think that will be just fine Larry. Do you have any problem with me
> changing the last check box label for the English translation?
>
> SS
>
> On 10/8/07, Larry Becker <[EMAIL PROTECTED]> wrote:
> > Hi SS,
> >
> >   Good catch.  SelectByTypePlugin is one of mine.  The cryptic dialog
> name
> > is caused by a common problem with plugins, forgetting to override the
> > getName() method. I can fix it by having it return the same string that
> > appears on the menu.  Is that sufficient?  Anything else will require a
> new
> > translation.
> >
> > Larry
> >
> >
> > On 10/8/07, Sunburned Surveyor < [EMAIL PROTECTED]> wrote:
> > >
> > > I have a couple questions about the dialog box for the "Select by
> > > type" plug-in. Actually, I really need to just ask permission for a
> > > couple of changes to the English strings. :]
> > >
> > > I'd like to change the title of the dialog for the plug-in from
> > > "SelectByTypePlugIn" to "Select by Geometry" or "Select by Geometry
> > > Plug-In".
> > >
> > > I would also like to change the label for the last check box from "On
> > > selected layers only" to "On Selected Layers Only" to be consistent
> > > with the rest of the GUI and the dialog itself.
> > >
> > > Are there any objections to these changes?
> > >
> > > The Sunburned Surveyor
> > >
> > > P.S. - A screenshot of the current dialog is attached.
> > >
> > >
> >
> -
> > > 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
> > >
> > >
> > >
> >
> >
> >
> > --
> >  http://amusingprogrammer.blogspot.com/
> >
> -
> > 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
>



-- 
http://amusingprogrammer.blogspot.com/
-
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] Postgis connection

[Stefan Steiniger]

Hei Eric,

ok...If you commit then add it to the "plugins" folder
http://jump-pilot.svn.sourceforge.net/viewvc/jump-pilot/plug-ins/

stefan

Eric Lemesre wrote:

> Hi Stefan,
>
> Thank for your intervention with Uwe,
> I rebuild directory structure and commit in a new directory this plug in.
>
> probebly befor this WE.
>
> Eric
>
> 2007/10/8, Stefan Steiniger < [EMAIL PROTECTED] 
> >:
>
> Hei Eric,
>
> Uwe agrees to put the postgis plugin on the svn.
> for the rest - because I never used maven - can you simple outline the
> directory structure on the SVN. So I have a better image what you want
> to do.
>
> stefan
>
> Eric Lemesre wrote:
>
> > Hi Stefan,
> >
> > I am a newbee ;-) ,
> >
> > I like maven concept. We can resolve jar dependencies and provide
> > an easy way to donwload any library, build reporting, run test
> Etc ...
> >
> > My second contribution is not ready and  I commit nothink.
> >
> > But make maven repository like gt2 is probably a good idea.
> >
> > With Maven we can have by exemple :
> >
> >1.   PlugIn
> >   pom.xml for build all subfolder
> >  1. ChartPlugIn
> > pom.xml and all necessary file and folder for it.
> >  2. PostgisPlug (if Uwe agrees to add the plugin)
> > pom.xml ...
> >2. a target directory with in all jar and
> workbench-properties.xml
> >   with plugin reference
> >
> > Comment?
> >
> > @+
> > Eric
> >
> > 2007/10/4, Stefan Steiniger <[EMAIL PROTECTED]
> 
> > >>:
> >
> > Hei Eric,
> >
> > i don't realy understnd what you want to do.
> > a) you want submit improvements?
> >
> > b) you want to make new plugin folders in the repository
> (for the 4
> > plugins below)?
> > => this should be possible, but i need to look how and where
> to store
> > (i.e. adapt the structure)
> > notes:
> > * i am not sure if we shall include the Category tools..
> > Actually, I need to ask Arnd how Pirol will move on and if
> there is
> > somebody maintaining the code)
> > * the srid support plugin is not needed for newer OJ 1.2 X
> versions,
> > since it is now included in OJ. So you ma change the code in
> the SVN
> > codebase?
> > * i guess Uwe agrees to add the plugin code to the SVN - but we
> > may talk
> > to him first
> >
> > c) you want to have it "all"(?) in a "maven" folder to
> compile an
> > extension? - Or do you want to create a separate maven folder?
> > => I would prefer a separate folder
> >
> > but maybe others help for interpretation ;)
> > comments are welcome
> >
> > stefan
> >
> > Eric Lemesre wrote:
> >
> > > Hi,
> > >
> > > No source in repository.
> > > I have a working copy and modify directory structure for
> Maven 2.
> > >
> > > I have :
> > > plugin
> > >  * chartPlugIn (org.OpenJUMP.Graph from Erwan Bocher)
> > >  i add a bar chart in JInertnalFrame. and I hope in some
> time a
> > > refresh button.
> > >  * JumpPostGIS ( net.refractions.postgis from Uwe Dalluege)
> > >  i add a where clause
> > >  * sridsupport (de.hawhamburg.sridsupport)
> > >  the same
> > >  * CategoryTools
> (de.fhOsnabrueck.jump.pirol.plugIns.CategoryTools
> > > from LBST-PF-3\orahn)
> > >  juste some translate
> > > Etc
> > > ...
> > > and all plugin is package by command
> > > mvn package
> > >
> > > It is probably possible to make Maven2 repository for
> OpenJump?
> > >
> > > Eric
> > >
> > > PS: I forward this mail to the liste.
> > >
> > >
> > > 2007/10/3, Michaël Michaud < [EMAIL PROTECTED]
> 
> >  >
> > >     > >
> > > Hi,
> > >
> > > Good point Eric, I didn't know you worked with Uwe
> > Dalluege's Postgis
> > > Plugin.
> > > You're right, there is something wrong with putting a
> > BigDecimal value
> > > into an AttributeType.DOUBLE jump attribute.
> > >
> > > I don't know if you can commit this change into the
> svn, as
> > I did not
> > > see the source file in the repository.
> > >
> > > Michaël
> > >
> > >

Re: [JPP-Devel] Upper Limit On Data Size For OpenJUMP

[Martin Davis]

I wouldn't try and set quantitative upper limits, just let them be 
dictated by available memory and processor size.

But it seems reasonable to state that the architecure is primarily 
designed for in-memory datasets (although that isn't strictly true, 
since the DataStore framework shows how the same architecture can be 
used to deal with datasets in external memory accessed on-the-fly and 
via caching).  Perhaps a better description is that in JUMP features 
which are visible are expected to be in-memory.

Personally I wouldn't try and go further than the current 
in-memory/caching feature stream architecture.  Moving to a completely 
external-memory based architecture (such as uDig) brings a whole passel 
of new problems you have to work around (mostly to do with not having a 
feature available when you want to work on it).

The caching Layer paradigm is pretty powerful - it could easily be 
extended to handle huge shapefiles, for instance, by providing a 
suitable driver. 

If the big-point-dataset thing is really such a big deal, I think it 
could be  handled by loading the points into a very compact internal 
representation (say an array of doubles), fronted by a FeatureCollection 
implementation which simply creates Geometries and Features on-demand.  
I suspect that this might scale very well for viewing.  Obviously a 
custom data loader would be required, but there's no free lunch.

Sunburned Surveyor wrote:
> I wonder if it is worth discussing whether or not there will be a
> reasonable and practical limit to the size of data that we will try to
> support in OpenJUMP. (For example, a maximum of 1,000 layers and
> 2,000,000 features.)
>
> I realize this is a little tricky, because each computer will be able
> to handle different loads on memory and processor, but I think the
> basic concept might have merit. I question the wisdom of modifications
> to the core made in support of these super huge datasets when this
> probably isn't our typical use case.
>
> The reality is that most of our users probably aren't working with
> huge datasets. I think we have to remember that there will always be a
> practical limit to the amount of data a computer program can work
> with.
>
> As an example, at my day job we don't expect AutoCAD to handle
> millions of points that come from our Laser Scanner. We have very
> specialized software built specifically to handle millions of points.
> This software filters, screens and processes these millions of points
> to produce data that normal AutoCAD can handle. (For example, it
> produces a "plane" from a set of points collected on the surface of a
> wall, or a cylinder from a set of points collected on the surface of a
> pipe.)
>
> Perhaps a better approach to huge GIS datasets is special tools that
> can modify the data to produce meaningful results that can be used in
> OpenJUMP on most computers.
>
> Or maybe we have a "specialized" version of OpenJUMP  built to work
> with super huge data sets that eliminates a lot of the bells and
> whistles that users of smaller data sets enjoy. Or maybe we have a
> plug-in that reads a millions of points and creates a surface from the
> results. Or maybe we have a plug-in that reads in giant shapefiles,
> such as a shapefile of all the roads in Europe, and then "tiles" this
> into smaller, more manageable shapefiles.
>
> At any rate, I don't think OpenJUMP can be all things to all people,
> and it might be worth considering when we cross the line that requires
> use of some programs designed especially for the use of huge datasets.
>
> Any comments?
>
> The Suburned 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
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


-
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] Extract Layers, Large Selections, Fences, and other thoughts

[Martin Davis]

Makes sense to me.  The selection handler design is one thing that 
really doesn't scale all that well.  It's a tough problem - how do you 
keep track of an arbitrary set of things without actually keeping 
references to them?

Actually, this problem was the motivation behind my developing the 
Geometry Function tool.  When I need to extract a big set of things 
determined by a spatial Area-Of-Interest, I just create a new layer with 
the AOI shape, and then use Geometry Function with the intersects 
predicate to extract the desired features to a new layer.  I think this 
is exactly what you're proposing with your Copy Fenced Features to New 
Layer plugin, right?  Seems like a good thing to have this available a 
bit more directly.

The advantage to using Geometry Function/intersects is that it's easy to 
use an existing feature geometry as the Mask.  At one point I was 
thinking it would be nice to have a Set Fence from Geometry menu item as 
well.

Larry Becker wrote:
> Hi,
>
>   Recent work with Extract Layers by Geometry Type, and improving 
> OpenJump's support for very large selections, has convinced me that 
> JUMP needs a mechanism for dealing with subsets of large layers.  
> Although the selection mechanism is very flexible, it is very 
> expensive in terms of memory and processing.  To seem what I mean, 
> consider Arnd's million point layer problem.  To break the layer into 
> more manageable pieces, he tried to select some of the points and move 
> them to another layer.  When this is done with such a large selection, 
> the UI must build gigantic data structures.  The result is an 
> extremely slow response or an out of memory error.
>
> An approach that might work for some problems is to use the Fence tool 
> to indicate a subset of the data that can be used in place of a 
> selection.  The advantage is that no data structures are needed and 
> there are no selection handles to draw.  I was thinking of producing 
> another Layer Extract plugin that would extract features in the Fence 
> to a new layer.  By coding support methods in a utility class, we 
> could gradually add support for "features in fence" subsets to the 
> other tools.
>
> What do you think?
>
> regards,
>
> Larry Becker
>
> -- 
> http://amusingprogrammer.blogspot.com/
> 
>
> -
> 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
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


-
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] Upper Limit On Data Size For OpenJUMP

[Michaël Michaud]

Martin Davis a écrit :

>I wouldn't try and set quantitative upper limits, just let them be 
>dictated by available memory and processor size.
>
>But it seems reasonable to state that the architecure is primarily 
>designed for in-memory datasets (although that isn't strictly true, 
>since the DataStore framework shows how the same architecture can be 
>used to deal with datasets in external memory accessed on-the-fly and 
>via caching).  Perhaps a better description is that in JUMP features 
>which are visible are expected to be in-memory.
>  
>
One limitation of DataStore framework, as far as I experienced it, is 
that each time you zoom
or pan, needed features are loaded into memory as if they were new 
features (new fid), and you
loose other features (features located out of the window) as if they had 
never existed. This way,
it is not possible to process a whole featurecollection.
My vision woud be something between, with only references loaded into 
memory (id and
envelope) but references for every features of the featurecollection. 
With a good cache system,
it should make it possible to load much bigger datasets than with 
in-memory loaders and
caching should make it possible to keep reasonable performance.
Even if it seems reasonable and feasable to me, until now, I could not 
realize it (or only
versions with terrible performance drawbacks :-( )

>Personally I wouldn't try and go further than the current 
>in-memory/caching feature stream architecture.  Moving to a completely 
>external-memory based architecture (such as uDig) brings a whole passel 
>of new problems you have to work around (mostly to do with not having a 
>feature available when you want to work on it).
>  
>
I agree that managing large dataset in a read/write mode is quite 
difficult and needs a good
framework to manage transactions (I think kosmo team did a good work 
this way).
But I think read-only datasets is also an interesting usecase, and is 
not as difficult to manage
as a read/write driver.

>The caching Layer paradigm is pretty powerful - it could easily be 
>extended to handle huge shapefiles, for instance, by providing a 
>suitable driver. 
>  
>
Agile (alvaro zabala) wrote a good scalable shapefile driver in the 
past. I could make it work
with OJ after a minor modification, but I remember there were many 
dependencies.

>If the big-point-dataset thing is really such a big deal, I think it 
>could be  handled by loading the points into a very compact internal 
>representation (say an array of doubles), fronted by a FeatureCollection 
>implementation which simply creates Geometries and Features on-demand.  
>I suspect that this might scale very well for viewing.  Obviously a 
>custom data loader would be required, but there's no free lunch.
>  
>
Nice to benefit ideas from the jump architect :-)

Thanks

>Sunburned Surveyor wrote:
>  
>
>>I wonder if it is worth discussing whether or not there will be a
>>reasonable and practical limit to the size of data that we will try to
>>support in OpenJUMP. (For example, a maximum of 1,000 layers and
>>2,000,000 features.)
>>
>>I realize this is a little tricky, because each computer will be able
>>to handle different loads on memory and processor, but I think the
>>basic concept might have merit. I question the wisdom of modifications
>>to the core made in support of these super huge datasets when this
>>probably isn't our typical use case.
>>
>>The reality is that most of our users probably aren't working with
>>huge datasets. I think we have to remember that there will always be a
>>practical limit to the amount of data a computer program can work
>>with.
>>
>>As an example, at my day job we don't expect AutoCAD to handle
>>millions of points that come from our Laser Scanner. We have very
>>specialized software built specifically to handle millions of points.
>>This software filters, screens and processes these millions of points
>>to produce data that normal AutoCAD can handle. (For example, it
>>produces a "plane" from a set of points collected on the surface of a
>>wall, or a cylinder from a set of points collected on the surface of a
>>pipe.)
>>
>>Perhaps a better approach to huge GIS datasets is special tools that
>>can modify the data to produce meaningful results that can be used in
>>OpenJUMP on most computers.
>>
>>Or maybe we have a "specialized" version of OpenJUMP  built to work
>>with super huge data sets that eliminates a lot of the bells and
>>whistles that users of smaller data sets enjoy. Or maybe we have a
>>plug-in that reads a millions of points and creates a surface from the
>>results. Or maybe we have a plug-in that reads in giant shapefiles,
>>such as a shapefile of all the roads in Europe, and then "tiles" this
>>into smaller, more manageable shapefiles.
>>
>>At any rate, I don't think OpenJUMP can be all things to all people,
>>and it might be worth considering when we cross the line that requires
>>use of some programs designed especially for the 

Re: [JPP-Devel] Extract Layers, Large Selections, Fences, and other thoughts

[Michaël Michaud]

>At one point I was 
>thinking it would be nice to have a Set Fence from Geometry menu item as 
>well.
>  
>
Yes, this is a feature I missed sometimes.
That makes me remember that trying to copy/paste geometry from an 
existing layer to the fence,
I get strange things like having 2 geometries in the fence layer.
(I know I have to reproduce it to be able to fill a bug report).

Michaël

>Larry Becker wrote:
>  
>
>>Hi,
>>
>>  Recent work with Extract Layers by Geometry Type, and improving 
>>OpenJump's support for very large selections, has convinced me that 
>>JUMP needs a mechanism for dealing with subsets of large layers.  
>>Although the selection mechanism is very flexible, it is very 
>>expensive in terms of memory and processing.  To seem what I mean, 
>>consider Arnd's million point layer problem.  To break the layer into 
>>more manageable pieces, he tried to select some of the points and move 
>>them to another layer.  When this is done with such a large selection, 
>>the UI must build gigantic data structures.  The result is an 
>>extremely slow response or an out of memory error.
>>
>>An approach that might work for some problems is to use the Fence tool 
>>to indicate a subset of the data that can be used in place of a 
>>selection.  The advantage is that no data structures are needed and 
>>there are no selection handles to draw.  I was thinking of producing 
>>another Layer Extract plugin that would extract features in the Fence 
>>to a new layer.  By coding support methods in a utility class, we 
>>could gradually add support for "features in fence" subsets to the 
>>other tools.
>>
>>What do you think?
>>
>>regards,
>>
>>Larry Becker
>>
>>-- 
>>http://amusingprogrammer.blogspot.com/
>>
>>
>>-
>>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