Actually, GML2 could handle complex features just fine, just the
implementations were all built around simple features.
GML3 modularised GML, and then added a whole bunch of modules. And it
changed a few things
fromt the release:
"GML Version 3.1.0 adds new geometries, is more compliant with the ISO/TC
211 family of specifications, and contains some items for increased
efficiency and simplicity. It "maintains backward compatibility for GML
version 3.0.0 and 2.1.2 instance documents by preserving, but deprecating,
some schema components that have been replaced by different constructs in
the current version."
Sorry about being pedantic, :-)
rob
On 11/13/07, Adrian Custer <[EMAIL PROTECTED]> wrote:
>
>
> 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
>
-------------------------------------------------------------------------
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
