Hi Justin: After a bit of research I can produce a GMLDecode/GMLEncode class. You recommended using "the gml" module as a location; trouble is only the wfs module depends on all the needed configurations.
To parse results from WFS and OpenLayers we need to depend on the WFS configuration as well; as it provides its own abstract FeatureCollection. So options: - reintroduce gt-gml unsupported module - ask gt-xml to depend on everything (this may be smart in terms of migration) - add the code to gt-wfs (since it currently has all the dependencies) Another small question just in the WFS code base: WFSFeatureTypeTransformer is a one trick pony marked as a "sad hack until the new feature model is available". The actual code looks to update a feature type to a new CoordianteReferenceSystem. Jody On 01/06/2010, at 12:47 AM, Justin Deoliveira wrote: > Yeah, the gtxml method is horrible from a IDE point of view. One thing I > always planned to do was add shortcut classes: > > GMLParser/GMLEncoder > FilterParser/FilterEncoder > etc... > > On 10-05-31 12:44 AM, Jody Garnett wrote: >> Time has come for me to tackle one of Micaheal's requests from a couple >> months ago ... How do we parse/encode GML. >> >> To start with I have asked a few co-workers that have tried GeoTools parsing >> lately. Mostly I got a list of ways that do not work. Interestingly they all >> share an approach in common ... >> >> Typing in the IDE and using command completion to come up with things like: >> - GMLParsing - this is actual a demo of how to parse using GMLConfiguration >> - FeatureCollectionParser - actually part of the implementation of WFS 1.1.0 >> - GML configuration for GML2 extending XSD >> - GML configuration for GML3 extending XSD >> - GML configuration for GML3.2 extending XSD >> - GML configuration for WCS extending XSD >> - GMLParsingUtils - used internally by the GML2 bindings >> - GMLFeatureCollection - returned by WFS 1.0 implementation from FCBuffer >> - etc... >> >> So the only thing I can do in these cases is improve the javadocs to point >> people in the correct direction. >> >> Jody >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Geotools-devel mailing list >> Geotools-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
