The makers of Kosmo have been in touch with me about participating in
greater collaborative development of OpenJUMP, which I think is a great
thing.
Manuel has forwarded me a list of changes they have made to the OpenJUMP
Core. I will make an effort this week to get a section on the JPP wiki that
will have a list of the changes made to the JUMP/OpenJUMP core by the
independent development teams. I'm hoping this will allow us to start
talking about what we would like to put in and keep out of a new "merged"
core that the development teams can use.
I really need to do some more thinking about how this collaboration and
possibly "merge" might work. I'll try to have some thoughts for the list
this week. Please be patient with my efforts. :]
As a side note, my work on the next OpenJUMP/OpenJUMP-Ex release has stalled
while I try to take care of this administrative stuff. As soon as I have
some of these things taken care of, I will wrap up the release and make it
public.
The Sunburned Surveyor
P.S. - If you don't already know Manuel, please give him and the rest of the
Kosmo team a warm welcome.
---------- Forwarded message ----------
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Feb 20, 2007 5:12 AM
Subject: Suggested Procedures For Collaborative Development Of OpenJUMP
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Hello Landon:
We are reading your document. We think it is a good starting point. We
are studying it and hope next week we will have a more detailed
analysis.
Any case I would like to know your opinion about some thoughts we have.
* In the last days there are, like you said, something like " gaining
momentum" in the JPP developer list. Do you think we must maintain our
mail interchange here (in your personal mail) or there (in JPP
developers list)? We are not sure if we must be first introduced by
you or Stefan. Of course, if you think so, feel free to forward this
and past mails to the list.
* There are an special interest issue. There are several mails about
Jump Core and why different "brands" make different cores. We think,
as Paolo Rizzi, core matter is a very important one. You said you were
writing a report with all the feeding you are having so we have made a
preliminary list of which important core optimizing modifications we
already made. Some of the main changes/improvements:
Different rendering procedures for each data origin:
Optimized/different for image/point/line/polygon layers.
Different data access for each different origin:
Not possible for most applications to load entire layer data in memory
(for example, huge database vector layers, dozens/hundreds of
different small-medium database layer in the same view, etc.).
Different spatial index for each type (shapefile layers, memory
layers, database layers...).
New database on demand access, full read/write access:
PostgreSQL/GIS, MySQL, Oracle Spatial/Locator.
New optimized full read/write numeric data tables access:
.dbf, .mdb, .csv, PostgreSQL, MySQL, Oracle.
Optimized image access:
ecw, mrsid, jpg, bmp... with transparent to user catalog creation from
images in a specific directory.
Advanced printing module:
Able to print at different resolution heavy image and vector layers.
Utility for automatic cartographic serial printing. Full image and
vector printing. (Still we have work to get what we think must be a
full professional high quality output).
Very advanced and professional SLD OGC symbology:
With numeric and geometric filters, rules, metadata, etc.
Advanced query builder:
With numeric and geometric filters too, rules, metadata, etc.
Full projection view/data support.
You can change projections on the fly.
New hyperlink managing environment:
1:1, 1:n supported.
New Layer-Layer, Layer-Table and Table-Table managing environment:
This let us to incorporate a very complex client database model inside
Kosmo, navigate across and use it.
New geoproccesing tools:
(Just like an extension).
New CAD editing tools.
Dxf read/write:
In next few days.
New project managing interface:
Views, tables, layouts, relations, hyperlinks,...
New advanced topology quality control rules:
On line or batch processing.
New scientific field calculator.
New advanced numeric field editing:
With field data domain, for complex database models and error
decreasing in data introduction.
Of course, some of them starting from scratch and some of them reusing
existing module/source code. All of them present in the incoming
V:1rc1. All of them internationalized.
Hope it will be useful for you to know.
Regards,
Manuel
--
Manuel Navarro
[EMAIL PROTECTED]
Director Técnico de SAIG // SAIG Technical Director
www.saig.es -- Tlf: +34 652803042
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
