Hi Jukka, On 26 Sep 2005 at 14:34, Jukka Sirviö wrote:
> ok, thanks for prompt comments. I should thank you again for your contribution. Your cooperation is more than welcome! > Thus it > seems that the use of inner classes is common practise when dealing > with classes that represent the datamodel of some geographic data. Well, let's say that you can use a inner class if you want to hide some details from outside. Having public Reader/Writers would be great if we could separate the logic from accessing sequential text files from the record format, for example. This way we could have a single TextDataStore supporting different text formats using different FeatureReaders/Writers. This would be great, we could centralize buffering/caching and transaction logic... but it ain't so easy, so, especially when you're in a hurry for developing things, you choose the quick-and-dirty solution. ;o) > I agree also that MapInfo have irritating way to support mixed > geometries and text and style information inside mif (and tab). I > think the styles used in mif -files should never be considered > 'business critical', instead the handling of core information > (naturally that's geographical data) is the main information we should > take care about. It's good to notice that you have been thinking this > issue and you already have some workaround ideas. The main problem is that the MapInfo and GeoTools datamodels are not perfectly compatible (i.e. a JTS Geometry does not have a Style, nor a Feature has it). Moreover, MIF means MapInfo Interchange Format, and has been designed more for import/export operations. I think it's advisable to convert data from MIF to other formats (we're using PostGIS) if you need to work with it. For performance issues, we could envisage more general solutions, like a CachingDataStore (read once, serve many times). > I remember that I read some conversation that geotools should not > provide 'official' support for interchange data formats like MIF. > Instead geotools should concentrate to provide support for 'real' > dataformats like shp. I think of course it would be better to have > support for 'real' MapInfo tab but how to hack the data format > specifications? This is a good point. We should go for a MapInfo TAB support, of course. There's a project in C language - mitab - which has already developed a good API for handling TAB files from outside MapInfo: http://mitab.maptools.org/ A great part of the library is composed of the Geometry classes, which are already in the JTS library. Right now I've no time for porting the mitab library into geotools. Any volunteer? ;o) Anyway, if MapInfo native format support is given, one problem still remains: TAB data format carry the same problems/limitations seen for MIF (unsupported types, styles). We should use a common logic to support both TAB and MIF files. > Yours: > Jukka Sincerely Sig -- Luca Sigfrido Percich ([EMAIL PROTECTED]) Agenzia Milanese Mobilità e Ambiente s.r.l. (http://www.ama-mi.it) Direzione Sistemi Informativi e Modellistica Via Beccaria, 19 - 20122 Milano - tel. +39 02 884.67.262 ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
