On Tue, May 22, 2012 at 1:28 AM, Frank Gasdorf
<[email protected]>wrote:
> 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.
>
> Yup, that sounds good. It would be nice to keep some
backward compatibility in place though since that module has been released
(although its not really used from what i can tell).
So, create the proposed package structure with all the classes. And then
leave the existing KMLConfiguration and KML in their location but make them
subclass from the v1_1 classes. We can also deprecate them.
> 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?
>
No, unfortunately the way the parser works is that it requires the version
to be known before hand. It wouldn't be hard to come up with a convenience
or utility method that could buffer the input stream, parse the root
attribute to figure out the namespace and then match it to a specific
configuration.
>
> 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.
> >
>
--
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
