we do. If you find any problem just report back as a bug. But it's
already supported (though only tested against Oracle11g).
Cheers,
Gabriel
On Tue, 2011-02-08 at 11:29 +0800, Ben Caradoc-Davies wrote:
Gabriel,
do we support or plan to support ArcSDE 10 as a datastore backend?
Kind regards,
Hi,
I'm asking to satisfy a curiosity. I know that complex feature people
are all about
interoperability with application schemas and the like, but only the
cases demanding
complex features I keep on stumbling on do not use/require published
app schemas at all...
I'm wondering, assuming I can
While I very much appreciate the work the appschema folks have been doing I
do agree that there is room for a solution that does not involve xml schema
mapping, as your use case and past experiences clearly indicates.
As for going from featureType to xml schema without a predefined schema (for
On Tue, Feb 8, 2011 at 6:39 PM, Justin Deoliveira jdeol...@opengeo.org wrote:
While I very much appreciate the work the appschema folks have been doing I
do agree that there is room for a solution that does not involve xml schema
mapping, as your use case and past experiences clearly indicates.
On Tue, Feb 8, 2011 at 10:54 AM, Andrea Aime
andrea.a...@geo-solutions.itwrote:
On Tue, Feb 8, 2011 at 6:39 PM, Justin Deoliveira jdeol...@opengeo.org
wrote:
While I very much appreciate the work the appschema folks have been doing
I
do agree that there is room for a solution that does not
Improve PropertyCollector in ImageMosaic
-
Key: GEOT-3420
URL: http://jira.codehaus.org/browse/GEOT-3420
Project: GeoTools
Issue Type: Improvement
Components: gc imagemosaic
Affects
Andrea,
there is no support for converting complex FeatureTypes into schemas.
app-schema delivers schemas by returning a document that includes or
imports the application schemas from their canonical location.
The GML encoding requires a schema document to feed into EMF to
configure the
Still I think it could be possible to grab a hand made FeatureType and
derive its xsd, right? Even if it may break right now, it shouldn't be
that complicated?
What do you mean the encoder needs to know about substitution groups?
can't it work if there are no substitution groups? The FeatureType
Cannot read features from SQL datastore with NaN numeric values
---
Key: GEOT-3421
URL: http://jira.codehaus.org/browse/GEOT-3421
Project: GeoTools
Issue Type: Bug
I was thinking about non-feature polymorphic complex properties. For
example, CGI_Value and similar types from GeoSciML 2.0:
http://www.geosciml.org/geosciml/2.0/xsd/value.xsd
The GML striping rule requires that the type (XSD element) is encoded
before each property name.
There is an open source package called trang that converts an xml
document to an xml schema, among other things
http://www.thaiopensource.com/relaxng/trang-manual.html#xml-input
It is used by oXygen.
Tara
Gabriel Roldn wrote:
Still I think it could be possible to grab a hand made
[Back on the list]
Unit test. It is the only way to be sure.
Kind regards,
Ben.
On 09/02/11 15:42, Andrea Aime wrote:
On Wed, Feb 9, 2011 at 4:14 AM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
I was thinking about non-feature polymorphic complex properties. For
example,
On Wed, Feb 9, 2011 at 8:47 AM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
[Back on the list]
Unit test. It is the only way to be sure.
Yup. For the moment I was just checking the waters before wasting needless time
in a quote for something others might know it's just not doable
13 matches
Mail list logo
