I have added an introductory page on complex features.
http://docs.geoserver.org/trunk/en/user/data/app-schema/complex-features.html
All feedback is appreciated. I think I have been fair to simple features. 
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Ben Caradoc-Davies ha scritto:
I have added an introductory page on complex features.
http://docs.geoserver.org/trunk/en/user/data/app-schema/complex-features.htmlAll feedback is appreciated. I think I have been fair to simple features.
Yes you were, it's a good read which I would recommend most
people to look at 
One thing that might raise eyebrowses is that the comparison
table in the "complex features" section appears to be
identifying complex features with open standards.
While the two are often found in combination, a standard could
mandate a simple feature schema (in which case one would
probably end up using the schema mapping abilities of app-schema,
but not the generation of complex features),
and a custom application could define a non standardized target
schema just because the nature of the data it provides
is better served by a complex feature setup.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Yes - this is the reason we renamed it "app-schemas" - the idea is the
schema is defined by a wider application that is implemented using a
services architecture.
Of course one could publish an "introspective schema" (i.e. based on
your private persistence model) as an application schema, but no-one
else could repeat it without either an identical persistance
technology and model, or the app-schema function to map things, so
we're back where we were.
so, there is a necessity to have the app-schema capability to support
open standards for data transfer, regardless of how complex they are,
and this is why the connection is obvious.
This may raise eyebrows, but its just a natural progression of the
service architecture paradigm, and pretty much unavoidable if we use
OGC or other document/literal service styles.
Rob
On Tue, Sep 22, 2009 at 8:29 AM, Andrea Aime <aaime@anonymised.com> wrote:
Ben Caradoc-Davies ha scritto:
I have added an introductory page on complex features.
http://docs.geoserver.org/trunk/en/user/data/app-schema/complex-features.htmlAll feedback is appreciated. I think I have been fair to simple
features.Yes you were, it's a good read which I would recommend most
people to look atOne thing that might raise eyebrowses is that the comparison
table in the "complex features" section appears to be
identifying complex features with open standards.While the two are often found in combination, a standard could
mandate a simple feature schema (in which case one would
probably end up using the schema mapping abilities of app-schema,
but not the generation of complex features),
and a custom application could define a non standardized target
schema just because the nature of the data it provides
is better served by a complex feature setup.Cheers
Andrea--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Hi,
very nice explanation. I like it also because I had no idea about complex
featue types before reading it. Just one missing information for me is "What
to do to make complex features in GeoServer". It would be best to make
tutorial, if it is not too much time to spend. If it is too complex, please
try to make that process just in some points. (just a few dots with
description what to have be done, something like "code new derivate of class
ABC and implement abstract methods")
Have a nice day.
On Tuesday 22 September 2009 09:07:07 Rob Atkinson wrote:
Yes - this is the reason we renamed it "app-schemas" - the idea is the
schema is defined by a wider application that is implemented using a
services architecture.Of course one could publish an "introspective schema" (i.e. based on
your private persistence model) as an application schema, but no-one
else could repeat it without either an identical persistance
technology and model, or the app-schema function to map things, so
we're back where we were.so, there is a necessity to have the app-schema capability to support
open standards for data transfer, regardless of how complex they are,
and this is why the connection is obvious.This may raise eyebrows, but its just a natural progression of the
service architecture paradigm, and pretty much unavoidable if we use
OGC or other document/literal service styles.Rob
On Tue, Sep 22, 2009 at 8:29 AM, Andrea Aime <aaime@anonymised.com> wrote:
> Ben Caradoc-Davies ha scritto:
>> I have added an introductory page on complex features.
>> http://docs.geoserver.org/trunk/en/user/data/app-schema/complex-features
>>.html
>>
>> All feedback is appreciated. I think I have been fair to simple
>> features.
>
> Yes you were, it's a good read which I would recommend most
> people to look at
>
> One thing that might raise eyebrowses is that the comparison
> table in the "complex features" section appears to be
> identifying complex features with open standards.
>
> While the two are often found in combination, a standard could
> mandate a simple feature schema (in which case one would
> probably end up using the schema mapping abilities of app-schema,
> but not the generation of complex features),
> and a custom application could define a non standardized target
> schema just because the nature of the data it provides
> is better served by a complex feature setup.
>
> Cheers
> Andrea
>
>
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
> -------------------------------------------------------------------------
>----- Come build with us! The BlackBerry® Developer Conference in SF,
> CA is the only developer event you need to attend this year. Jumpstart
> your developing skills, take BlackBerry mobile applications to market and
> stay ahead of the curve. Join us from November 9-12, 2009. Register
> now! http://p.sf.net/sfu/devconf
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel---------------------------------------------------------------------------
--- Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
OdbornÃk na vÅ¡etko je zlý odbornÃk. Ja sa snažÃm byÅ¥ výnimkou potvrdzujúcou
pravidlo.
On 22/09/09 14:29, Andrea Aime wrote:
One thing that might raise eyebrowses is that the comparison
table in the "complex features" section appears to be
identifying complex features with open standards.
While the two are often found in combination, a standard could
mandate a simple feature schema (in which case one would
probably end up using the schema mapping abilities of app-schema,
but not the generation of complex features),
and a custom application could define a non standardized target
schema just because the nature of the data it provides
is better served by a complex feature setup.
Indeed! I had a section on the possible use of application schemas for simple features, but I removed it because I thought it confused the issue. I might have to put it back in if its absence is so obvious. I have tried to avoid any inference that application schemas are all complex, but it is easy to make that assumption.
If you nest all feature properties by reference, app-schema output begins to look rather a lot like simple features (but not quite) ...
I prefer to think of GeoServer simple features as being automatic-schema or inferred-schema features, because their schema is (typically) inferred from the database schema. They might be simple, but, in my view, that is not their defining characteristic.
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
On 22/09/09 15:40, ĽubomÃr Varga wrote:
very nice explanation. I like it also because I had no idea about complex
featue types before reading it. Just one missing information for me is "What
to do to make complex features in GeoServer". It would be best to make
tutorial, if it is not too much time to spend.
Aha, this is the Application Schema Support (app-schema) extension (go up one level from the complex feature page). The tutorial is banished to the tutorial section of the user manual.
I am rewriting them right now. They are somewhat ghastly but should improve a lot over the next few days.
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Ben Caradoc-Davies ha scritto:
On 22/09/09 14:29, Andrea Aime wrote:
One thing that might raise eyebrowses is that the comparison
table in the "complex features" section appears to be
identifying complex features with open standards.
While the two are often found in combination, a standard could
mandate a simple feature schema (in which case one would
probably end up using the schema mapping abilities of app-schema,
but not the generation of complex features),
and a custom application could define a non standardized target
schema just because the nature of the data it provides
is better served by a complex feature setup.Indeed! I had a section on the possible use of application schemas for simple features, but I removed it because I thought it confused the issue. I might have to put it back in if its absence is so obvious. I have tried to avoid any inference that application schemas are all complex, but it is easy to make that assumption.
If you nest all feature properties by reference, app-schema output begins to look rather a lot like simple features (but not quite) ...
I prefer to think of GeoServer simple features as being automatic-schema or inferred-schema features, because their schema is (typically) inferred from the database schema. They might be simple, but, in my view, that is not their defining characteristic.
Absolutely. My remark was more on the lines that one does not need
to be publishing a standard schema to benefit from the app-schema
module.
One can have a real need for complex features in an application that
does not need to share a common profile, or in a field where the
standard bodies have not provided any reference, or simply because
for the needs at hand the reference schema is considered too
complex.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.