From: Justin D. <jde...@op...> - 2006-08-29 15:57:51
|
Hi all, There are a few classes sitting on FM that I require on trunk as part of the xml work. The first is an implementation of org.opengis.feature.type.Name, which is essentially the same as QName. The second is an implementation of org.opengis.feature.Schema, which basically maps a bunch of names to attribute types. These classes shouldn't affect any existing code and are a precursor to the FM plan presented earlier. Anyone have any problems with this? -Justin -- Justin Deoliveira The Open Planning Project jde...@op... |
From: Jody G. <jga...@re...> - 2006-08-29 16:28:27
|
Note as maintain of module/api Justin did talk to me first, I apologize for not emailing the list. Here is what the changes look like.... > C:\java\geotools\trunk\module\api>svn up > U src\org\geotools\data\Query.java > U src\org\geotools\data\FIDSQuery.java > U src\org\geotools\data\ALLQuery.java > A src\org\geotools\feature\type > A src\org\geotools\feature\type\TypeName.java > A src\org\geotools\feature\Name.java Glancing through svn since my last commit, I can see a few other changes - thanks for the hard work everyone. Jody > remove unused dependency > ------------------------------------------------------------------------ > r20914 | chorner | 2006-08-09 23:48:52 +0200 (Wed, 09 Aug 2006) | 1 line > > GEOT-848, GEOT-916: SQLEncoder.filtercapabilities now protected and > not static; migrated to FilterType.NONE/ALL instead > of 12345/-12345; harmonized SQLEncoder.createFilterCapabilities subclasses > ------------------------------------------------------------------------ > r20971 | afabiani | 2006-08-11 10:15:58 +0200 (Fri, 11 Aug 2006) | 1 line > > > ------------------------------------------------------------------------ > r21001 | jdeolive | 2006-08-15 03:48:03 +0200 (Tue, 15 Aug 2006) | 1 line > > temporarily added some geoapi interface methods > ------------------------------------------------------------------------ > r21020 | aaime | 2006-08-16 17:24:42 +0200 (Wed, 16 Aug 2006) | 1 line > > Fixes for GEOT-920 > ------------------------------------------------------------------------ > r21152 | desruisseaux | 2006-08-22 17:44:32 +0200 (Tue, 22 Aug 2006) | > 2 lines > > Replaced IllegalArgumentException by MismatchedDimensionException in > envelope methods, which is a more accurate descript > ion of the error. Because MismatchedDimensionException is a subclass > of IllegalArgumentException, existing "catch (Illeg > alArgumentException e)" code should continue to work. > Note: The formatting of ReferencedEnvelope has been affected in > something closer to a previous formatting. This is consi > stent with the formatting of some other classes like JTS, but probably > not of all classes in main module. This formattin > g may changes again soon by application of Javaloppy. The mean reason > way "svn diff" see a differences in about everylin > es is because of the replacement of tabulations by spaces. > ------------------------------------------------------------------------ > r21240 | jdeolive | 2006-08-29 06:15:37 +0200 (Tue, 29 Aug 2006) | 1 line > > changed sort by reference to the geoapi interface, instead of > deprecated geotools interface > ------------------------------------------------------------------------ > r21255 | jdeolive | 2006-08-29 18:01:23 +0200 (Tue, 29 Aug 2006) | 1 line > > added > ------------------------------------------------------------------------ > r21256 | jdeolive | 2006-08-29 18:03:40 +0200 (Tue, 29 Aug 2006) | 1 line > > added > ------------------------------------------------------------------------ > r21257 | jdeolive | 2006-08-29 18:04:06 +0200 (Tue, 29 Aug 2006) | 1 line > > formatting > Hi all, > > There are a few classes sitting on FM that I require on trunk as part of > the xml work. The first is an implementation of > org.opengis.feature.type.Name, which is essentially the same as QName. > > The second is an implementation of org.opengis.feature.Schema, which > basically maps a bunch of names to attribute types. > > These classes shouldn't affect any existing code and are a precursor to > the FM plan presented earlier. Anyone have any problems with this? > > -Justin > > |