Hi Frank, > I just had a look at the eu.udig.tools.jgrass bundle and I would like > propose a refactoring to extract the kml import/export feature into a > separate bundle. > > What do you think about a new bundle ed.udig.tools.jgrass.kml that is > basically taken from the mentioned bundle above and from package > eu.udig.tools.jgrass.kml
It is really ok for and I am happy this leads to a serious kml tool. I added the functionality without very deep thought, more based on what geotools already had. So I am +1 for this. the only thing I would do is to move it to a: eu.udig.tools.kml or maybe even eu.udig.kml since it has surely nothing to do with jgrass. Are you planning to make it a kind of datastore, i.e. load kml directly in the catalog? Or would it be more a import/export tool? > I'd like to describe the reason: First of all, it has no other > dependencies then geoapi, geotools and core udig api. > IMHO its easier to configure an end-user-product thats would like to > have kml support has nor requirements to show and analyze profiles, > have CVS support and all the other nice features from the tools.jgrass > bundle. > > Last but not least its easier to maintain and enhance (e.g. kml style support) > > In case you like the idea, should I create a new RFC for this > enhancement as well as a new issue in jira? Do you have other > suggestions? That all sounds great to me. Thanks Frank! Ciao, Andrea > > Cheers > Frank _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
