Hi,
the function Tools>Generate>Buffer...
creates a buffer with End Cap Style but
without attributes from the source layer.
The function Tools>Analysis>geometrc functions...>Buffer
creates a buffer with attributes but without End Cap Style.
Is it possible to have a buffer-function
with attribute
Hi Uwe,
I'm working on it now.
regards,
Larry Becker
On 8/31/07, Uwe Dalluege <[EMAIL PROTECTED]> wrote:
> Hi,
>
> the function Tools>Generate>Buffer...
> creates a buffer with End Cap Style but
> without attributes from the source layer.
>
> The function Tools>Analysis>geometrc functions...>
Hi,
I noticed that WFS plugin is missing from the plugin page at
openjump.org. However, I think it is worth mentioning there, perhaps
with a short description. The following is too long for that page but
perhaps it could be used for advertising in some other place.
"OpenJUMP WFSPlugin is WFS v.
Hi,
Salut Stefan (J'espère que la fin de thèse se passe bien),
The new GDBMS named GDMS is here :
http://geosysin.iict.ch/irstv-trac/wiki/GDBMS/Project.
R1.
2007/8/31, Stefan Steiniger <[EMAIL PROTECTED]>:
>
> without reading your email - just a hint:
> Did you had a look on GDBMS (see sourcef
I've been trying to find a quick way to create Polygons from selected
LineStrings in one of my OpenJUMP GIS projects. I've been using the
suggestion to set up a temporary Layer were I paste a copy of the
LineStrings I've selected, then I use the polygonize tool to actually
create the Polygons.
I t
Hi,
I have played with quite a nice software that I had tried never before, OSSIM
(www.ossim.org). As a by-product here is a table about what kind of TIFF files
OpenJUMP can open at present.
result with result with
Ossim tiff writer driverJUMP native
Thanks for the announcement Larry. We hope that you enjoy working with OpenJUMP.
The Sunburned Surveyor
On 8/19/07, Larry Reeder <[EMAIL PROTECTED]> wrote:
> Hey all,
>
> Mentaer (Stefan) suggested I send a message to the JPP list to let
> everyone know about a new OpenJump database plugin. I kno
Thanks for taking care of this Mihael.
SS
On 8/21/07, Michaël Michaud <[EMAIL PROTECTED]> wrote:
> Done !
>
> Michaël
>
> Sunburned Surveyor a écrit :
>
> >Why don't we add the method back with the deprecated tag. We can put a
> >comment in the source code file stating that the method can be remo
Hi SS,
No magic here. SelectTool is itself an abstract class, so selection
is initialized in the classes that extend SelectTool like
SelectFeaturesTool, SelectLineStringsTool, SelectPartsTool, and
SelectOneItemTool.
regards,
Larry
On 8/31/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> I'
Thank you Larry. I missed the fact that the SelectTool was abstract.
Thank you for pointing that out.
SS
On 8/31/07, Larry Becker <[EMAIL PROTECTED]> wrote:
> Hi SS,
>
> No magic here. SelectTool is itself an abstract class, so selection
> is initialized in the classes that extend SelectTool li
Cool...
I think that one way around the "slow union" problem is to develop a
"Cascading Union" function. This will build up a union of multiple
geometries by forming them into a tree, and recursively unioning the
branches of the tree from the leaves to the root.In theory this
should provi
Hi Martin,
The union operation is implemented by buffering the union of the
input, rather than the union of the input buffered, if you see the
distinction. I was hoping JTS had already optimized this, but from
what you are saying, I would guess not.
Larry
On 8/31/07, Martin Davis <[EMAIL PROT
Yes.. as far as i know JTS has no optimization, but..
* I implemented in the mapgen toolbox an union based on attributes that
utilizes the jts quadtree.
* recently Michael improved the JUMP deliverd union to speed up (can't
remember how) and added as well an option for unioning only when
attrib
ah.. anyway.. thanx Larry!
Larry Becker schrieb:
> Hi Martin,
>
> The union operation is implemented by buffering the union of the
> input, rather than the union of the input buffered, if you see the
> distinction. I was hoping JTS had already optimized this, but from
> what you are saying, I
Not sure I do see... Either way, if you are doing repeated calls to
union(), then this is going to be slow. But maybe you mean that you are
*combining* the input geometries in to a single multi-geometry, and then
buffering that once? That should be faster, then. Although... for
complex inpu
Stefan Steiniger wrote:
> Yes.. as far as i know JTS has no optimization, but..
>
> * I implemented in the mapgen toolbox an union based on attributes that
> utilizes the jts quadtree.
>
Nifty..
What kind of performance improvement did you get? Did this use a
cascaded approach?
--
Martin
Hi Martin,
The way I optimized the union plugin in OpenJUMP is not as clever as
using a quadtree, but it is equivalent in the ideal case of regularly
distributed features.
I just grouped features in a regular grid which size is computed based
on the featurecollection envelope and size (number o
17 matches
Mail list logo
