2012/5/22 Justin Deoliveira <[email protected]>: > Hey Frank, > > On Mon, May 21, 2012 at 3:27 PM, Frank Gasdorf <[email protected]> > wrote: >> >> Thanks Justin, >> >> this is a good point to start! I've done something similar but was nut >> sure about the xmlcodgen configurations. The main difference >> was the property "destinationPackage" 've set to >> org.geotools.kml.v2_2.bindings > > > Yeah, and it not a crucial settings... by default the binding classes will > be generated in the root of the package structure for the module being run > in. >> >> >> But it seems to me, that (most) of the bindings are identical over the >> versions, aren't they? >> Could you just send me your maven command line and goals to generate >> the packages and sources. I'd like to add 2.0 support as well. > > Indeed, most of the bindings will be identical and in this case I generally > try to reuse directly or by subclassing. You will find examples of this in > many of the other xsd modules such as sld, filter, and gml. I suggest a > similar approach for kml. > > As an example consider the filter 1.0 configuration > class: org.geotools.filter.v1_0.OGCConfiguration. The class registers all > the filter bindings. If you look at the filter 1.1 configuration class > "org.geotools.filter.v1_1.OGCConfiguration" you will notice is does much the > same, but it uses mostly the 1.0 bindings and only implements bindings for > things not in 1.0, or for things in which the xml representation has > changed. > > This works well in cases like filter 1.0 and 1.1 that actually share the > same xml namespace. It doesn't work so well in cases where the xml namespace > changes, like for instance between filter 1.1 and 2.0. In that case a > similar approach is used but it involves subclassing the bindings from the > existing namespace and overriding names. For instance, look > at org.geotools.filter.v2_0.FESConfiguration. You will see it uses its own > set of bindings but if you look at one of them, say for > instance org.geotools.filter.v2_0.bindings.BeyondBinding you will see it > subclasses the old binding and simply overrides getTarget(). > > Does that make sense? >
Absolutely! For the 2.0 stuff I guess the namespace is the same like in 2.1 (kml) therefor I'm going to start with this and will subclass (if possible) the 2.1 classes from the 2.0 classes afterwards. Would you agree to refactor the current package structure and move the 2.1 classes (KML & KMLConfiguration) to a v2_1 sub-package. And following the "naming convention" what about the v22 package, could we rename it to v2_2 as well? I know this are minor non functional changes but its based on package structures of the other xsd modules. Do you have any idea how to choose the correct configuration if I only have a ZipInputStream of a FileInputStream of kmz/kml file. Does the geotools library have some utility classes to grep schema url from xml? Is it possible to set the Configuration dynamically dependent from the schema url of the xml? I'm looking forward to get a first shot till end of this month. -Frank >> >> Cheers, >> Frank >> >> 2012/5/21 Justin Deoliveira <[email protected]>: >> > Hey Frank, >> > >> > I actually started this work a while back on a github branch. It would >> > be >> > great if you could resurrect it! >> > >> > https://github.com/jdeolive/geotools/tree/kml >> > >> > -Justin >> > >> > On Sat, May 19, 2012 at 2:15 PM, Frank Gasdorf >> > <[email protected]> >> > wrote: >> >> >> >> Hello List, >> >> >> >> in the new uDig plugin for kml/kmz support we are using the geotools >> >> 8-SNAPSHOT [3] version. I had a look into it and have seen, that KML >> >> Schema 2.1 is supported. This in mind I was wondering about a >> >> successfully kml import from a 2.2 source. Nevertheless a kml with >> >> schema reference 2.0 broke up with a NullPointerException, during >> >> parsing a longitude value thats null. >> >> >> >> Could anybody describe how to invoke the geotools maven xmlcodegen >> >> plugin to add support for 2.0 as well as 2.2. My read is, that its >> >> possible to generate the sources into different packages, like v2_0, >> >> v2_1 and v2_2 for the databindings. I tried a bit but in result I hat >> >> a lot TODO's in code for types and conversions of xml values/types >> >> into java objects. >> >> >> >> I guess the conversions could be done in a commen kml package like for >> >> LookAt [1] type and some others, because these types seems to be >> >> identical over the different versions. >> >> >> >> Has anybody created bindings for 2.0 before? >> >> >> >> >From the users side I'm interested in kml support where the parser >> >> uses the correct configuration, independently from default >> >> (uncompressed) KMZ and compressed KMZ. From my point of view is a bit >> >> different to lets say WMS where the supported version is in the >> >> request itself and the client can request a capability document for >> >> each supported version (1.3, 1.1.1, 1.0.0) and catches the Exceptions >> >> a server responses. >> >> Right here its possible that the user have huge files. >> >> >> >> Do you have any suggestions how to extent the current implementation? >> >> IMHO the user should only select a kml file and the "Importer" should >> >> handle all the rest, without additional interaction to select the >> >> version of the "quasi" standard (prior 2.2) and standard since 2.2. >> >> [2]. >> >> >> >> Is there somewhere Service [4] support I couldn't find? Do you have >> >> any plans to add kml service support? Is it possible to contribute, if >> >> there is anybody who acts as a mentor? >> >> >> >> Looking forward! >> >> >> >> Frank >> >> >> >> [1] https://developers.google.com/kml/documentation/kmlreference >> >> [2] http://www.opengeospatial.org/standards/kml >> >> [3] >> >> >> >> https://github.com/uDig/udig-platform/tree/master/plugins/eu.udig.catalog.kml >> >> [4] >> >> >> >> http://udig.refractions.net/files/docs/api-geotools/org/geotools/catalog/Service.html >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Live Security Virtual Conference >> >> Exclusive live event will cover all the ways today's security and >> >> threat landscape has changed and how IT managers can respond. >> >> Discussions >> >> will include endpoint security, mobile security and the latest in >> >> malware >> >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> >> _______________________________________________ >> >> GeoTools-Devel mailing list >> >> [email protected] >> >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > >> > >> > >> > >> > -- >> > Justin Deoliveira >> > OpenGeo - http://opengeo.org >> > Enterprise support for open source geospatial. >> > > > > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
