On Tue, 2007-11-13 at 10:08 +0100, Robert Jacolin wrote: > Justin Deoliveira a écrit : > > Hi Robert, > > > > > Hi, > thank you for your answer ! > > GML3 is quite different from GML2. The changes on teh geometry elements > > that you noted are one of differences. The feature stuff is still pretty > > similar. And then there is a wack of more stuff that we don't really use. > > > For my information, can you precise this 'wack of more stuff' ? Why > don't you use them ? > GML 3 seems a little used (and no SAX parser exists in geotools).
Hey, You should look up the concept of 'Simple Features'. This is a set of features which have a simple array of single valued attributes. This means, for one, that the Features can be stored in a single row in a database. This structure for features has been the staple of GIS for years and is relatively well understood. GML 2.x was able to deal with such features only. 'Complex Features' are a different thing and GML 3.x tries to support those. Not only can the features have attributes with arbitrary complexity but that complexity can be built in layers from different providers so you need to track the namespaces that define the different elements. Note also that GML 3.x is merely a schema framework. To have a 'real' schema, you need a profile of GML 3.x. So no one will support GML 3.x but only various profiles of the GML 3.x standard. Geotools trunk has just now landed the third or fourth attempt to try to support GML 3.x. There have been lots of attempts at this that have not born fruit because they were too complex to integrate but the latest appears to have worked. Apparently there are still serious issues around Filters and therefore around all the internal selection mechanisms. So this is all still 'experimental'. Justin was pointing you toward the docs for his work on these "Complex Features". Yes things are different because the very core of the 'Data model' has changed to something much more complicated (and therefore able to do much more). So that's the reality of Geotools today. If you need to do GML 3.x you need to be on the experimental, not yet released, geotools trunk. cheers, adrian > > > So patching the GML2 parsing stuff is one alternative. However a full > > blown gml3 parser / encoder has been written on geotools 2.4.x and > > trunk. There are some docs here: > > > > http://docs.codehaus.org/display/GEOTDOC/GML+XML+Support > > > > The docs are a bit out of date, i apologize. But just use > > org.geotools.gml3.Configuration and the code is the same. > > > > You may want to give the new parser a try and see how it goes. Are you > > parsing straight gml? Or gml from a wfs? > > > GML is used without WFS in my project. > > I didn't use the gml3 parser because I wanted reuse some piece of code > someone writted in the eXist project to index GML2 data. So I used the > same mechanism which uses SAX events to parse the geometry elements : > when a coordinate (coord, coordinate in gml 2, pos and posList in gml 3) > is found, the points are sent to GMLFilterGeometry to build the Geometry > object, ... > It was very simple to integrate it (once I compiled eXist and geoTools :) ). > > If I use gml3.Configuration, I need to implement a new class in a very > different way (more difficult to maintain and need more time to > develop), load the file (it can be huge o what about the memory) and > analyse it. > > But in the two ways, I'm not sure I will catch all coordinates and > geometry to build, for example, if GML3 add new Geometry object... > > Regards, > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
