Sorry about that Stefan and Larry.
I was forwarding a portion of a message that I had sent to the Kosmo guys
and forgot to change the reference to SkyJUMP. I did the same thing to Ugo.
That is the last time I ever use cut and paste in an e-mail message.
The Sunburned Surveyor
On 2/28/07, Stefan Steiniger [EMAIL PROTECTED] wrote:
Hei Sun,
why do you speak in points [1] to [3] about Kosmo and not SkyJUMP?
stefan
Sunburned Surveyor schrieb:
Larry,
I'm not quite sure about your plans for work on SkyJUMP, and I know your
flexibility with the project is limited by some government restrictions.
However, I have set up a section of the JPP wiki for collaborative
development, and there is a page there for SkyJUMP.
If you think you will be able to participate in the collaborative
development of OpenJUMP I invite you to participate. I'm sure you are
very busy, but if you get time and want to participate It would be great
to have the following three things done:
[1] Provide me with a Java Package Map for Kosmo that I can post on
the wiki.
[2] Send me a brief e-mail when new classes/interfaces are added to an
official release of Kosmo, or when existing classes/interfaces are
modified in Kosmo.
[3] Select 2 or 3 of the improvements to Kosmo that you would like to
see in OpenJUMP.
Let me know what you think of this. If you don't think you'll be able to
participate in this because of your particular situation, I understand,
and I'll remove the SkyJUMP page from the wiki.
I look forward to hearing from you.
Landon
On 2/27/07, *Larry Becker* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I just had a look at some of the ideas in the Google Summer of Code
and I think it is going to be tough to win any students over from
sexy
projects like One Laptop Per Child to something as boring as GIS.
Still, there must be some GIS programmer students out there
somewhere
so here is my two cents:
Speaking of boring, one of the most repetitive tasks in GIS has to
be
heads-up digitizing using a background raster. Batch automated
digitizing has been tried many times and found mostly to be a
failure.
How about an interactive tool that snaps the cursor based on the
color and intensity of the background raster. I'm sure you can all
imagine algorithms that would be possible and useful to implement.
JUMP's snap manager would make this easy to implement for all cursor
tools, but the basic code should be valid for any Java based
GIS. In
fact, the only problem with this suggestion is that it will be tough
to keep from working on it ourselves. :-)
regards,
Larry Becker
P.S. Sunburned, Kosmo seems to have DXF and DWG support.
On 2/27/07, Sunburned Surveyor [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Stefan,
See my comments below.
You wrote: aehm.. we (JUMP) currently has a DXF plugin by
Michael Michaud?
Do you
now this?
What about DWG?
Why do you chosen this format (It is rather usefull for CAD
Geometries
than for GIS )
I know about the DXF plug-in and have looked at the code. I've
even given it
a trial run. I'd like to build on Muchael's work by adding
support for some
other DXF features. For example, I'd like the user to have
control over how
polylines are converted. You could have them represented by [1]
line
strings, [2] individual line segments, or if they are closed
polylines [3]
as polygons. There are other things I would like to improve as
well.
You wrote: What about DWG?
DWG is a closed, binary format. There are some third-party
libraries out
there that will allow programs to read DWG files. However, these
libraries
are not open source and are not written in Java, that I know of.
There are
also some legal issues surrounding there use, and Autodesk is a
big Gorilla.
I'd rather not get OpenJUMP involved in that mess. DXF is
intended as a
transfer format of Autodesk CAD data to other programs, and I
think good DXF
support in OpenJUMP would be sufficient.
You wrote: Why do you chosen this format (It is rather usefull
for CAD
Geometries
than for GIS )
You must remember I deal mostly with GIS data creation, not
manipulation and
analysis. Good support for import and export of CAD data will be
a critical
requirement for OpenJUMP, if I am to implement it as the main GIS
program at
my day job. I imagine the same would apply to most
engineering/surveying
outfits. I realize this may not be a need of most OpenJUMP users,
but it is
of special importance to me. :]
You wrote: ok..In which direction? What about some
triangulation,
