Hi Uwe,
Thanks for answering,
>the Save Dataset As File ... saves the files and build
>automaticly the suffix!
>With Save dataset as ... you can save PostGIS tables with
>the PostGIS plugin.
>
>I think if Save dadaset as ... could build automatcly the
>suffix for files it would be a wondeful stor
Hi Michael,
the Save Dataset As File ... saves the files and build
automaticly the suffix!
With Save dataset as ... you can save PostGIS tables with
the PostGIS plugin.
I think if Save dadaset as ... could build automatcly the
suffix for files it would be a wondeful story.
But I think today we d
Jonathan,
Thanks for the comment. I've actually got "Working Effectively With
Legacy Code" on my Safari Bookshelf.
The Sunburned Surveyor
On 6/25/07, Jonathan Aquino <[EMAIL PROTECTED]> wrote:
> Yeah, unit tests are best done with the underlying objects rather than the
> GUI itself. Testing the
Yeah, unit tests are best done with the underlying objects rather than the
GUI itself. Testing the GUI is hard - but that's OK, as testing the non-GUI
code is already a great thing to do.
A couple of great books on unit testing:
- "Working Effectively with Legacy Code" by Michael Feathers
- "Tes
On a more serious note I would recommend doing it off the list in case
the person may be embarrassed receiving corrections.
Paul
Sunburned Surveyor wrote:
> I just wanted to let everyone know that there is no need for members
> of our community that use English as a second language to apologize
Hi SS,
Would they be American or (real :) ) English corrections ;)
Paul
Sunburned Surveyor wrote:
> I just wanted to let everyone know that there is no need for members
> of our community that use English as a second language to apologize
> for their grammar and spelling.
>
> I think we all reco
I just wanted to let everyone know that there is no need for members
of our community that use English as a second language to apologize
for their grammar and spelling.
I think we all recognize that OpenJUMP has a global user and developer
community and that this is something that appeals to many
After reading over Peppe's e-mails about OpenJUMP documentation I have
decided to provide a simple little template for OpenJUMP docs written
in a word processor. (I realize Scribus isn't for everyone.) I will
make this available in MS Word and OpenOffice.
I'll still be working on help docs in Scri
Peppe,
I am sorry that it has taken me so long to get back to you. I am
finally making some time to work on the OpenJUMP documentation.
Peppe wrote: "the Page orientation has a landscape (1,00x8,50
inch) size. This is good for Presentation (That's not
a bad Idea!). Nevertheless we lose a lot of s
Doesn't seem excessive to me.
Larry
On 6/25/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> Larry wrote: "IMO Javadoc comments should be short statements of
> > purpose. They shouldn't talk about algorithms, but should document
> > anything unusual about parameters. For example, Object para
Larry wrote: "IMO Javadoc comments should be short statements of
> purpose. They shouldn't talk about algorithms, but should document
> anything unusual about parameters. For example, Object parameters are
> used in RenderManager methods, but it isn't documented what Objects
> are acceptable."
E
My answer is a confident "I think so" - as long as there's no JUMP
function which relies on mutating Coordinates to work correctly. AFAIK
this should be the case - but it's been a long time and many code
changes since I've been really close to the code.
I think the right design to use here is
Hi Martin. Correct me if I'm wrong, but if we implemented use of
CoordinateSequences piecemeal driver-by-driver, starting with
ShapeFile, wouldn't everything continue to function normally in JUMP?
Wouldn't JTS hide the internal representation from us?
thanks,
Larry
On 6/25/07, Martin Davis <[EMA
Hi SS,
OK by me. IMO Javadoc comments should be short statements of
purpose. They shouldn't talk about algorithms, but should document
anything unusual about parameters. For example, Object parameters are
used in RenderManager methods, but it isn't documented what Objects
are acceptable.
reg
I have realized how important unit tests are in my development. This
is something I learned the hard way after many hours of debugging
something that could have been caught in a unit test.
However, I seem to be running into an obstacle when I try to write
unit tests with a lot of my work for OpenJ
I'm currently adding Javadoc comments and anylizing methods for unit
testing in my code for OpenJUMP's pluggable rendering system. I have a
question about commits to the OpenJUMP SVN that I wanted to run by you
guys:
Does anyone have a problem with me adding Javadoc comments to public
methods curr
Unfortunately JTS isn't completely ported to use CoordinateSequences
only. But this should be mostly an internal issue. If you're using any
method which doesn't explicitly take a Coordinate[] you're safe (for
instance, all the methods on Geometry will work fine). If you're doing
low-level st
Larry,
Larry Becker schrieb:
> [...]
> I'm hoping someone will verify that this solution works for printing
> plugins.
I will implement a path for the Print/Layout plug-in to be able
to test it. I'm quiet a bit busy at the moment so results will only
be available in two days.
> [...]
Regards,
Yes, and I was right about being guilty too. The ISA tools are full
of ".x =" assignments.
Martin, does all of JTS support the JTS CoordinateSequence, or do you
need to convert to Coordinate arrays before calling JTS functions? I
see, for example, that there are LineString constructors for both
Oh, oh. If com.vividsolutions.jts.geom.LineSegment.setCoordinates()
is any indication, JTS is probably going to prevent making this
policy retroactive. There seem to be several places where Coordinate
values are passed into methods and have their x,y values modified.
regards,
Larry
On 6/25/07,
I agree with Martin. Modifying Coordinate values in-place is probably
a bad idea, however I'm pretty sure I've been guilty. What I'm trying
to figure out now, is a good way to find out where and how many times.
regards,
Larry Becker
On 6/25/07, Martin Davis <[EMAIL PROTECTED]> wrote:
>
>
> Mich
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
Michaël Michaud wrote:
>
> @Martin : Please, can you explain what immutability means for
> coordinates. I see that x,y,z are public fields (and I remember I often
> changed them via small scripts, especially the z value). But may be I
> have no clear idea about immutability and its advantages.
Hi Sascha,
Thanks for taking a good look at the "Interactive Mode Switch"
solution. I agree with your analysis. Setting the interactiveMode
back to true in the flash runnable is a big improvement. It takes
care of an issue that I have noticed with the selection background
renderer drawing af
Hello there
I would greatly appreciate a small amount of your time to assist with
my doctoral research at The University of Newcastle. The research
concerns open source licensing and we're seeking developers working on
Java projects. The research is supervised, ethics-approved, anonymous
and resul
25 matches
Mail list logo
