[osmosis-dev] Informations about osmosis

[sorel]

The reason why I would like it to be splitted is more a design need.

Actually geotoolkit alone weight ~10Mb for ~65 Jars.
With the dependencies it's ~45Mb and ~125 Jars.

You can understand that with big project we need to have to handle very 
carefully
dependencies of it's overall size will explode.
We have ~100 maven modules to achieve a thin granularity so anyone can 
make an
application with just what is needed, not more.

The reason is for the end applications, an exemple is Java applets or 
web applications.
(web container like tomcat/glassfish/jboss start to complain when you go 
over 40Mb)

geotoolkit has plenty of sub projects, constellation, mapfaces, 
puzzle-gis, mdweb ...

I understand that thin control is not a real problem on small projects 
but at our level
we start to have a lot of 1+1+1+1 ... if you see what I mean :D.

I can't force you to split it of course, it's your project. it's just a 
kind of wish.

johann





Brett Henderson wrote:
> On Wed, Jan 27, 2010 at 10:43 PM, sorel <johann.sorel at geomatys.fr 
> <mailto:johann.sorel at geomatys.fr>> wrote:
>
>     Hello,
>
>     The main reason I see to split osmosis in modules is to achieve a
>     separation of tasks for
>     a better integration in third party application/library.
>
>
> How does a single jar prevent integration into other apps/libraries?
>  
>
>
>     My current work is to write the code to read/write osm files and
>     communicate with the server in geotoolkit.
>     I see osmosis has most of the functional code for thoses purposes
>     so it would be a waste of effort
>     to duplicate everything.
>
>
> Yep.
>  
>
>
>     Actualy osmosis is the only java library that we can potentialy
>     rely on, in fact the geotoolkit library is under LGPL
>     and JOSM or the salesman-traveler application dont have a
>     compatible license (GPL) nor a functional maven build. 
>
>
> It used to be GPL, so you're lucky there ;-)
>
> As for the maven build, it's a bit experimental at the moment and the 
> ant build is still the standard way of building it.  But it appears to 
> work so will hopefully work for you as well.
>
>
>     Our objective is to be able to acces OSM datas with normalized
>     data models like ISO 19109 (Feature), ISO 19107 (Geometry)
>     GML, WFS, WMS and so on ... we already have all this,
>     reprojection, rendering engines, styling (SLD / SE) ...
>     We just lack the "connection" part to OSM datas :).
>
>
> Okay, sounds great.
>  
>
>
>     I believe there are plenty of stuff  usefull in geotoolkit that
>     could be used in osmosis, some exemple would be
>     exporting to shapefile, gml or dynamicly generate image tiles,
>     swing map viewer and editor and all stuff related to reprojection
>     capabilities.
>
>
> That sounds interesting.  These aren't things that I'm able to tackle, 
> but perhaps others might.
>  
>
>
>
>     Back to the main subject :
>     I hope to be able to reuse osmosis code without importing
>     unnecessary code like pipelines, database exporter, command line
>     parser
>     and so one.
>
>
> Again, is the problem just a size issue.  Having classes you don't use 
> isn't a problem other than it takes up additional disk space.
>
> I'm not opposed to the idea of breaking up the jar into smaller 
> pieces, but unless you have some spare time to do it yourself it's 
> unlikely to happen any time soon.
>  
>
>
>
>     By the way I can't find any java code exemples anywhere,
>     reading/writing osm and so on ?
>     I can only find command line exemples.
>
>
> There aren't any unfortunately.  While I wrote most of the code with 
> the idea of osmosis being used as a library, other than Travelling 
> Salesman I'm not aware of it happening anywhere.  The current docs are 
> focused on command line usage as you've discovered.
>
> If you do need code examples, the best I can suggest is to find a 
> command on the following wiki page that does something similar, then 
> find the source code for it.
> http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage
>
> To find the source code, open the TaskRegistrar class, look for the 
> task name you're interested in, and next to the name will be the 
> factory that creates the task implementation.  For example to read in 
> an xml file, use the --read-xml example, find it in TaskRegistrar 
> listed as "read-xml", the factory implementation is XmlReaderFactory, 
> and it creates a class called XmlReader.
>
> Brett
>