Hello Michael.
First time, many thanks for both, your comments and your effort to test
Kosmo-Desktop1.0rc1, and sorry for delay (we have been out of office in
a free gis conference).
Some quickly technical questions:
-Source code for 1.0rc1 is now available. We did available 1.0rc1
compiled version las week for windows to let some of you could view the
program, not just the very old last version 0.8.3, and loose a lot of
effort to analyze it. Sorry for any inconvenience.
-About specific functions inside Kosmo, you are right: we try not to
include any specific, only very common functions for all user we have
been in touch in the last 15 years (small, medium, large
administrations, single users, facilities entreprises, etc.). Any
specific work for a client include both, a small generic functions group
we think can be useful for all the other diverse users, and a big
specific functions group for each client. We try to do first group very
generic and include it at Kosmo base, and the specific development
inside new extensions. Why: in this way we can use part of our
bussiness revenue to improve Kosmo for all users, moreover our personal
investment. We think this is the best way to be able our open source
code project be strong and maintenable in time.
-About collaboration, we hope to be able to improve it. It is always
good for all.
Well, now I will try answer your questions (answer start with "K-": )
****************
Packaging
****************
-- Only one very big bundle (75 837 ko) : I'd like a lighter bundle for
people having a jre on their machine (many people I guess)
++ On the other hand : no problem to install kosmo on my windows
machine, no problem to launch it, no error message
K-Yes, you are right. Today publised a version without jre inside,
although this is for us the best way for users to install without any
problem, and to use it later too without problems with java automatic
updates. We plan also to publis minor updates with just only the
neccesary files.
****************
First impression
****************
++ Interface is much like OpenJUMP interface : clear enough to
understand what I should do to start working without reading a hundred
pages manual. I appreciate that saig has added several important
functionnalities without adding complexity to the menus (in fact, there
are more buttons in the ToolBar, but buttons which are not usable for a
task are grayed, and the interface looks simple)
-- Internationalization is far from being complete, even for english
language
-- I did not start to work (I did not load any data), but there is
already 38 Mo of committed memory. OpenJUMP uses less than 8 Mo when it
has just been started.
K-Please, could you send us the log file at /bin/logs in order to check
it (We thougt it was 100% translated, maybe forgot any in the final
compilation. In fact, to avoid it, some of our technician work usually
in english languaje version).
K-Yes, it start so, but later you can work with huge vectorial and image
layers, and memory go up and down, without a very dangerous memory
quantity. Memory is no usually the main limit to work inside Kosmo.
****************
Coordinate System
****************
++ Coordinate System Mangement is well integrated. First time I tried to
create a project, I was asked for a coord ref system. After that, the
coord ref sys name appeared in the project title. The second time, kosmo
remembered what is my favorite system to work and proposed to me to keep
it. Thanks.
-- I did not find our new french reference system (RGF93 / Lambert 93)
but I'm sure we'll be able to add it (take care, the precise
transformation from the old french ref system to the new RGF93 system is
not based on a simple 7 param transformation...)
I did not check if kosmo can do transformation and if it does it well
K-You are welcome (this es a MAIN objective for us, to do it very
friendly for the user). We use geotools for this task.
****************
Using services (wms) : not tested
****************
K- similar interface than coordinate system, we hope it is very friendly
for users.
****************
Loading data from file
****************
++ shapefile is loaded very quicly and with low memory consomption (less
than 10 Mo for 22 000 features). Memory consumption climb from 10 to 70
Mo when I check the "load into memory" checkbox. This is nearly twice
the size of the layer in OpenJUMP !
-- I did not find gml import/export option
K-Well, we focus shapefile management NOT in memory. Really, at first
versions it was no included. It has been designed mainly for
Kosmo-server. So, this is not usually the best way to work in desktop mode.
++ DXF / DWG / DGN formats are supported : I did not test them yet
++ can load attribute data files (mdb or dbf)
K-too from Oracle, MySQL and PostgreSQL
-- I could not read the geometry coordinates from the "View/Edit
attribute" or the "Feature info" panel. This is possible (and useful) in
OpenJUMP. No way to check if z coordinates of a shapefile 3D is
correctly read.
K-We thought this was not a useful option, so we decided not to include
it. We know we were wrong and it will be in next releases.
-- in the "load table" panel, the cancel button (on the right side of
the panel) has no effect.
K-yes, yes, yes....and "accept" button too. We always forget to remove
them!!! In next release :-) .
****************
Loading table
****************
-- one can load a table in mdb or dbf format, and save a layer as excel
(without geometry). It should be useful to have the same format for
input and output. It should also be useful to propose a csv input. csv
is proposed as a plugin, but only for data with point geometry ==> IMHO,
formats available for geographic data I/O and for attribute data I/O is
not very clear.
K-yes, it is not very clear.
****************
Loading file from database : not tested yet
****************
****************
Loading images
****************
-- it is strange that the core can't read images but JAI library is
necessary for kosmo's installation.
++ the image extension is very simple to add and works fine :
no problem to read tiff, jpg2000, ecw, jpg
-- graphic display is a bit slow for some formats (especialy jpg 2000 -
ecw is fast)
K-image access is in the core, not in an extension.
****************
Editing data
****************
++ kosmo is able to modify a onDemandDataSource layer with a "Commit
Changes" system which is quite simple and clear
-- if I want to remove a modified layer from the project, I am asked if
I want to save the changes : yes / no / cancel. If cancel is choosen,
the layer is removed without being saved, which is an unexpected
behaviour !!!
K-yes you are right. In next release.
-- no way to create a layer with mixed geometries (points, lines polygons)
K-yes
-- no way to create a layer with 3D geometries
K-yes. Kosmo kept Z coordinate if it is included in the geometry layer,
but can`t modify it from the user interface.
-- a new layer can only be saved as a shapefile (or excel but without
geometry)
K-You can save as shapefile, MySQL, PostGIS and Oracle with the "save
as" option
****************
MISCELLANEOUS REMARKS
****************
Feature model : it seems that a layer may have only one geometry type
(point / line / polygon).
K- yes.
I found no information about the z coordinate management.
K-No management yet, only read/write function.
There are two attribute types different from OJ : long and float. Is
float really useful ? why not boolean ? Do you think it may be useful to
add constraints on AttributeType for compatibility with databases and
shapefile/dbf (ex field width, number of decimal) ?
K-To think.
when I measure an area, a layer "Area" is created. The bb of this layer
doest not correspond to its content, as shown by the zoom to layer command
K- zoom to layer applies a "buffer" to bb area, in order to view
correctly the external border of the area feature.
STYLES
labels should not be revered (the head down)
K- in next release it will be a user option.
the capability to display vertex does not exist (it exists in JUMP)
K- you are right, it is only possible in edition mode
styles can be saved in independant file : is sls file format a standard
? why not use sld ?
K- We will check it ( I am not sure now, but I think the file is SLD
format, only different in the extension name. If so, we will change the
extension name).
no possibility to synchronize label zoom with map zoom
K- finishing. Next short release.
the "sorting rows" function is very slow : it is much more slow than
OpenJUMP equivalent function, even when the layer is loaded in memory
(after I have check the load into memory checkbox)
K- This happen only with a layer in memory (not recommended). It is
possible to go up and down very very quickly inside a shapefile table
with more than one million records.
-- WARNING : after few manipulations, yesterday, I have broken a valid
shapefile which is no more readable with kosmo. Message is
java.lang.NullPointerException
at
org.saig.core.dao.datasource.filedatasource.shape.geometry.RuleStyle.<init>(RuleStyle.java:109)
at
org.saig.core.renderer.ShapeRenderer.getRulesInScale(ShapeRenderer.java:667)
at org.saig.core.renderer.ShapeRenderer.render(ShapeRenderer.java:172)
Sorry, I don't know how to reproduce the error.
I wanted to try the "relation" capability, but my first try ended with a NPE
K-It looks a very extrange point for that error. Please, could you send
us the log file/s inside the kosmo log directory.
Thanks again for all
Best regards.
Antonio Muñoz
__________ Información de NOD32, revisión 2092 (20070303) __________
Este mensaje ha sido analizado con NOD32 antivirus system
http://www.nod32.com
Michaël Michaud escribió:
> Hi all
>
> I can't resist any longer to give my feeling on the subject.
> Firstly, I think the mail title should be "suggestion by Paolo"
> instead of Pedro :-)
>
> I have made some tests with kosmo rc1 and I am quite impressed by the
> work.
> Not only because they added some capabilities which we have missed for
> a long time in openjump, but also because IMHO, kosmo suceeded in
> adding new capabilities AND keeping JUMP's philosophy : a simple and
> clean user interface for a powerful tool. This is my user point of
> view. I had no time to see the code and the many libraries kosmo
> depends on.
>
> I'm not trying to say OpenJUMP has to switch to kosmo because I agree
> with erwan, SS and pedro's remarks. We must make sure that kosmo is
> stable enough (my feeling is rc1 is less stable than OJ now, but it is
> already quite stable), and we must keep OJ as light and extensible as
> possible. I also agree with you when you mention that saig develop
> kosmo for particular clients and that OJ must stay a kind of
> "universal" and "open" platform. But I did not find particular
> functions in kosmo which are uncompatible with OJ's goal. Only useful
> additions fitting well with the goal of OJ.
>
> So what ? Many questions in front of us, and even more work. Maybe
> we'll have to switch to kosmo in a near future just because kosmo
> progresses much faster than OJ (and than JUMP). Before that, I think
> it is our interest to get a better collaboration with saig team, and
> start studying how the best of both projects could be merged (I think
> kosmo did not benefit the developments made the last two years on JUMP
> and OJ) : what are the differences in the feature model, what are the
> differences in the rendering engine, what has to be done to make a OJ
> plugin work with Kosmo ? This last question is important because there
> are many important plugins developped by JUMP (conflation suite,
> roadmatcher...), by Larry's team, Stefan, Ugo, Pirol university, R1...
> and nobody like to loose one's work. I think Kosmo team could help on
> these subjects.
>
> Finally, i'd like to thank Kosmo team to have open their code and
> given some explanations about their plans. I hope a good collaboration
> will go on and benefit to everybody.
>
> I attach a small file with remarks issued from the few tests I have
> made with kosmo since yesterday.
>
> Michaël
>
>
>
> __________ Información de NOD32, revisión 2092 (20070303) __________
>
> Este mensaje ha sido analizado con NOD32 antivirus system
> http://www.nod32.com
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
>
>
> __________ Información de NOD32, revisión 2092 (20070303) __________
>
> Este mensaje ha sido analizado con NOD32 antivirus system
> http://www.nod32.com
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
>
> __________ Información de NOD32, revisión 2092 (20070303) __________
>
> Este mensaje ha sido analizado con NOD32 antivirus system
> http://www.nod32.com
>
-------------------------------------------------------------------------
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
