Hey Frank,
On Mon, May 21, 2012 at 3:27 PM, Frank Gasdorf
<fg...@users.sourceforge.net>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?
> Cheers,
> Frank
>
> 2012/5/21 Justin Deoliveira <jdeol...@opengeo.org>:
> > 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 <
> fg...@users.sourceforge.net>
> > 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
> >> 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.
> >
>
--
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
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
