[Geoserver-devel] Building the complex-features branch

GeoServer GeoServer Developer
1

Hello,

What is the status of the complex-features branch? I've been trying to get it
to build, but I can't even get the Geotools part of it to work. I've asked
about that on the gt2-users mailinglist, but haven't had a reply yet. I'm
hoping there's someone here who is working on cf. I seem to recall something
on the wiki about merging it into mainline soon, perhaps that is half-done
and that is the reason for my problems?

FWIW, I can build Geotools trunk just fine (Sun JDK 1.5, Maven 2.0.7), but
when compiling complex-features Maven says:

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

GroupId: org.geotools
ArtifactId: gt2-module
Version: 2.2-SNAPSHOT

Reason: Unable to download the artifact from any repository

org.geotools:gt2-module:pom:2.2-SNAPSHOT

from the specified remote repositories:
central (http://repo1.maven.org/maven2)

Thanks for any help,

Lourens

--
ir. Lourens Veen Universiteit van Amsterdam - IBED
Nieuwe Achtergracht 166
Wetenschappelijk Programmeur 1018 WV Amsterdam, The Netherlands
EcoGRID-GAN tel: 020-5257453 fax: 020-5257431

2

Lourens Veen ha scritto:

Hello,

What is the status of the complex-features branch? I've been trying to get it to build, but I can't even get the Geotools part of it to work. I've asked about that on the gt2-users mailinglist, but haven't had a reply yet. I'm hoping there's someone here who is working on cf. I seem to recall something on the wiki about merging it into mainline soon, perhaps that is half-done and that is the reason for my problems?

I wasn't involved in the complex feature branch so take what I say with a grain of salt. Yet, afaik the branch is long dead, any attempt to merge it as is has failed.

On the other side, GeoTools trunk has just got a new feature model that
allows complex features to be modelled. Yet, all the code is still using
the subclass specific to simple features, that is, afaik, every attempt to actually use the superclass will fail with a class cast exception
of some sort.

I believe there is work planned to relax these limitations a bit at a time. For the moment, we just performed the switch and we have finger
crossed hoping the switch did not break too many things.
Justin, what is the short and long term plan about real complex features?

Cheers
Andrea

3

On Wednesday 10 October 2007 09:13:37 Andrea Aime wrote:

Lourens Veen ha scritto:
> Hello,
>
> What is the status of the complex-features branch? I've been trying to
> get it to build, but I can't even get the Geotools part of it to work.
> I've asked about that on the gt2-users mailinglist, but haven't had a
> reply yet. I'm hoping there's someone here who is working on cf. I seem
> to recall something on the wiki about merging it into mainline soon,
> perhaps that is half-done and that is the reason for my problems?

I wasn't involved in the complex feature branch so take what I say with
a grain of salt. Yet, afaik the branch is long dead, any attempt to
merge it as is has failed.

Ouch. That is bad news.

Thanks for your quick reply. Perhaps I should explain a bit more about my
problem then, to see if there is another possible solution.

I have a database with observations, and each observation has a location.
These locations are mostly standardised grid blocks, so that often many
observations share the same location. I have a client that has controls to
build a filter on the observations, and an OpenLayers map to retrieve and
display the relevant observations from a Geoserver WFS.

So far so good, except that I get lots of results (this is a _big_ database)
and drawing them all takes way too much time. Also, since many of the
observations are in the same position, there is no point in drawing all of
them. So, what I really want is not to get observations from the WFS, but
locations at which there was at least one observation with the properties
specified in the filter.

In SQL terms, I'd like something like

SELECT loc_geom, loc_id, COUNT(obs_id)
FROM locations NATURAL JOIN observations
WHERE [filter on columns of observations table]
GROUP BY loc_id;

I can select attributes using a PropertyName clause in my WFS query, I can
join locations and observations using a view in the DB, and I can do the
WHERE clause by specifying an OGC Filter in the WFS query. What I can't do is
the COUNT and GROUP BY (or DISTINCT ON).

So, when I saw http://docs.codehaus.org/display/GEOS/DerivedFeatureType I
figured that support for that was right around the corner, and then it
referred me to the ComplexDataStore project (this "community schema" support
is something else that I'll be needing in a while), which as I understand is
the complex-features branch in SVN, which doesn't build.

I'm considering either a very ugly (and hopefully very temporary) hack that
lets me pass a magic PropertyName that is rewritten into COUNT/GROUP BY
clauses somewhere deep inside the Geotools PostGIS plugin, or to have another
look at deegree WFS, which claims to offer complex features (I'm not sure if
it'll group them though, so that might not help any). I'd rather stick with
Geoserver though, because of its more open development model.

Thanks,

Lourens

--
ir. Lourens Veen Universiteit van Amsterdam - IBED
Nieuwe Achtergracht 166
Wetenschappelijk Programmeur 1018 WV Amsterdam, The Netherlands
EcoGRID-GAN tel: 020-5257453 fax: 020-5257431

4

Hi Lourens,
this is exactly the kind of thing you could do with the community
schemas unsupported modules in geotools 2.4 branch and geoserver's
trunk community-schema community modules. Actually, supporting
observations and measurements is a key driving use case for the
effort. That said, its functional prototype and currently can serve
WFS 1.1 (gml3) output, no WMS. But we're going to push that out to get
the whole thing working now that geotools trunk is changing to geoapi
feature model.
I'll say more about how you can start experimenting with it later
today as I'm on webmail now and trying to set up a dev environment.
Once I'm ready to go, I'll put hands on to ensure everything is still
working and provide you instructions on how to get going.

regards,

Gabriel

On 10/10/07, Lourens Veen <veen@anonymised.com> wrote:

On Wednesday 10 October 2007 09:13:37 Andrea Aime wrote:
> Lourens Veen ha scritto:
> > Hello,
> >
> > What is the status of the complex-features branch? I've been trying to
> > get it to build, but I can't even get the Geotools part of it to work.
> > I've asked about that on the gt2-users mailinglist, but haven't had a
> > reply yet. I'm hoping there's someone here who is working on cf. I seem
> > to recall something on the wiki about merging it into mainline soon,
> > perhaps that is half-done and that is the reason for my problems?
>
> I wasn't involved in the complex feature branch so take what I say with
> a grain of salt. Yet, afaik the branch is long dead, any attempt to
> merge it as is has failed.

Ouch. That is bad news.

Thanks for your quick reply. Perhaps I should explain a bit more about my
problem then, to see if there is another possible solution.

I have a database with observations, and each observation has a location.
These locations are mostly standardised grid blocks, so that often many
observations share the same location. I have a client that has controls to
build a filter on the observations, and an OpenLayers map to retrieve and
display the relevant observations from a Geoserver WFS.

So far so good, except that I get lots of results (this is a _big_ database)
and drawing them all takes way too much time. Also, since many of the
observations are in the same position, there is no point in drawing all of
them. So, what I really want is not to get observations from the WFS, but
locations at which there was at least one observation with the properties
specified in the filter.

In SQL terms, I'd like something like

SELECT loc_geom, loc_id, COUNT(obs_id)
FROM locations NATURAL JOIN observations
WHERE [filter on columns of observations table]
GROUP BY loc_id;

I can select attributes using a PropertyName clause in my WFS query, I can
join locations and observations using a view in the DB, and I can do the
WHERE clause by specifying an OGC Filter in the WFS query. What I can't do is
the COUNT and GROUP BY (or DISTINCT ON).

So, when I saw http://docs.codehaus.org/display/GEOS/DerivedFeatureType I
figured that support for that was right around the corner, and then it
referred me to the ComplexDataStore project (this "community schema" support
is something else that I'll be needing in a while), which as I understand is
the complex-features branch in SVN, which doesn't build.

I'm considering either a very ugly (and hopefully very temporary) hack that
lets me pass a magic PropertyName that is rewritten into COUNT/GROUP BY
clauses somewhere deep inside the Geotools PostGIS plugin, or to have another
look at deegree WFS, which claims to offer complex features (I'm not sure if
it'll group them though, so that might not help any). I'd rather stick with
Geoserver though, because of its more open development model.

Thanks,

Lourens

--
  ir. Lourens Veen Universiteit van Amsterdam - IBED
  Nieuwe Achtergracht 166
  Wetenschappelijk Programmeur 1018 WV Amsterdam, The Netherlands
  EcoGRID-GAN tel: 020-5257453 fax: 020-5257431

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldán

5

Lourens Veen ha scritto:

On Wednesday 10 October 2007 09:13:37 Andrea Aime wrote:

Lourens Veen ha scritto:

Hello,

What is the status of the complex-features branch? I've been trying to
get it to build, but I can't even get the Geotools part of it to work.
I've asked about that on the gt2-users mailinglist, but haven't had a
reply yet. I'm hoping there's someone here who is working on cf. I seem
to recall something on the wiki about merging it into mainline soon,
perhaps that is half-done and that is the reason for my problems?

I wasn't involved in the complex feature branch so take what I say with
a grain of salt. Yet, afaik the branch is long dead, any attempt to
merge it as is has failed.

Ouch. That is bad news.

Thanks for your quick reply. Perhaps I should explain a bit more about my problem then, to see if there is another possible solution.

I have a database with observations, and each observation has a location. These locations are mostly standardised grid blocks, so that often many observations share the same location. I have a client that has controls to build a filter on the observations, and an OpenLayers map to retrieve and display the relevant observations from a Geoserver WFS.

So far so good, except that I get lots of results (this is a _big_ database) and drawing them all takes way too much time.

Have you considered using the WMS filters instead? It's a custom GeoServer extension, you can add a &FILTER=XXX to a WMS call and
get filtered results. That should be much faster than retrieving
data via WFS and draw in OpenLayers.

As for WFS, I see Gabriel is providing you with some extra hints.
Cheers
Andrea

6

Andrea Aime ha scritto:

Lourens Veen ha scritto:

On Wednesday 10 October 2007 09:13:37 Andrea Aime wrote:

Lourens Veen ha scritto:

Hello,

What is the status of the complex-features branch? I've been trying to
get it to build, but I can't even get the Geotools part of it to work.
I've asked about that on the gt2-users mailinglist, but haven't had a
reply yet. I'm hoping there's someone here who is working on cf. I seem
to recall something on the wiki about merging it into mainline soon,
perhaps that is half-done and that is the reason for my problems?

I wasn't involved in the complex feature branch so take what I say with
a grain of salt. Yet, afaik the branch is long dead, any attempt to
merge it as is has failed.

Ouch. That is bad news.

Thanks for your quick reply. Perhaps I should explain a bit more about my problem then, to see if there is another possible solution.

I have a database with observations, and each observation has a location. These locations are mostly standardised grid blocks, so that often many observations share the same location. I have a client that has controls to build a filter on the observations, and an OpenLayers map to retrieve and display the relevant observations from a Geoserver WFS.

So far so good, except that I get lots of results (this is a _big_ database) and drawing them all takes way too much time.

Have you considered using the WMS filters instead? It's a custom GeoServer extension, you can add a &FILTER=XXX to a WMS call and
get filtered results. That should be much faster than retrieving
data via WFS and draw in OpenLayers.

Oh, the description of the custom params is here:
http://docs.codehaus.org/display/GEOSDOC/WMS+vendor+parameters

Cheers
Andrea

7

Hi all,

even though the complex-features branch is history, the functionality is being ported to the mainstream geotools code base. Currently there are unsupported modules for geotools 2.4 and geoserver trunk. We are currently remediating a few issues relating to the recently published Observations and Measurements, SensorML and SensorWebEnablement (SWE) schems from the OGC.

Please advise if you need more info at this stage. Sorry I wasdnt watching gt-users - probably wont do this until the modules are reayd for supported status.

Regards
Rob Atkinson

Andrea Aime wrote:

Andrea Aime ha scritto:
  

Lourens Veen ha scritto:
    

On Wednesday 10 October 2007 09:13:37 Andrea Aime wrote:
      

Lourens Veen ha scritto:
        

Hello,

What is the status of the complex-features branch? I've been trying to
get it to build, but I can't even get the Geotools part of it to work.
I've asked about that on the gt2-users mailinglist, but haven't had a
reply yet. I'm hoping there's someone here who is working on cf. I seem
to recall something on the wiki about merging it into mainline soon,
perhaps that is half-done and that is the reason for my problems?
          

I wasn't involved in the complex feature branch so take what I say with
a grain of salt. Yet, afaik the branch is long dead, any attempt to
merge it as is has failed.
        

Ouch. That is bad news.

Thanks for your quick reply. Perhaps I should explain a bit more about my problem then, to see if there is another possible solution.

I have a database with observations, and each observation has a location. These locations are mostly standardised grid blocks, so that often many observations share the same location. I have a client that has controls to build a filter on the observations, and an OpenLayers map to retrieve and display the relevant observations from a Geoserver WFS.

So far so good, except that I get lots of results (this is a _big_ database) and drawing them all takes way too much time.
      

Have you considered using the WMS filters instead? It's a custom GeoServer extension, you can add a &FILTER=XXX to a WMS call and
get filtered results. That should be much faster than retrieving
data via WFS and draw in OpenLayers.
    
Oh, the description of the custom params is here:
http://docs.codehaus.org/display/GEOSDOC/WMS+vendor+parameters

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  

8

On Wednesday 10 October 2007 11:51:43 Andrea Aime wrote:

Lourens Veen ha scritto:
>
> I have a database with observations, and each observation has a location.
> These locations are mostly standardised grid blocks, so that often many
> observations share the same location. I have a client that has controls
> to build a filter on the observations, and an OpenLayers map to retrieve
> and display the relevant observations from a Geoserver WFS.
>
> So far so good, except that I get lots of results (this is a _big_
> database) and drawing them all takes way too much time.

Have you considered using the WMS filters instead? It's a custom
GeoServer extension, you can add a &FILTER=XXX to a WMS call and
get filtered results. That should be much faster than retrieving
data via WFS and draw in OpenLayers.

That could get complex though. The next step, after displaying the locations
on the map, is to allow the user to select one or more locations. The
observations at the selected locations are then displayed in a separate
table. Having to have the server redraw the map (with the associated delay)
every time a user (de)selects something would get tedious quickly I think,
especially if there are lots of users. The beauty if doing things client-side
is that the amount of compute power increases linearly with the load :-).

Lourens

--
ir. Lourens Veen University of Amsterdam - IBED
Nieuwe Achtergracht 166
Scientific Software Engineer 1018 WV Amsterdam, The Netherlands
EcoGRID-GAN t: +31 20-5257453 f: +31 20-5257431

9

On Wednesday 10 October 2007 11:47:43 Gabriel Roldan wrote:

Hi Lourens,
this is exactly the kind of thing you could do with the community
schemas unsupported modules in geotools 2.4 branch and geoserver's
trunk community-schema community modules. Actually, supporting
observations and measurements is a key driving use case for the
effort. That said, its functional prototype and currently can serve
WFS 1.1 (gml3) output, no WMS.

Functional prototype is all I need. This sounds perfect. Well, if it also does
GeoJSON then it would be really perfect, but I can live with GML.

But we're going to push that out to get
the whole thing working now that geotools trunk is changing to geoapi
feature model.
I'll say more about how you can start experimenting with it later
today as I'm on webmail now and trying to set up a dev environment.
Once I'm ready to go, I'll put hands on to ensure everything is still
working and provide you instructions on how to get going.

Yes, please.

Thanks,

Lourens

--
ir. Lourens Veen Universiteit van Amsterdam - IBED
Nieuwe Achtergracht 166
Wetenschappelijk Programmeur 1018 WV Amsterdam, The Netherlands
EcoGRID-GAN tel: 020-5257453 fax: 020-5257431

10

On Wednesday 10 October 2007 13:06:56 Rob Atkinson wrote:

Hi all,

even though the complex-features branch is history, the functionality is
being ported to the mainstream geotools code base. Currently there are
unsupported modules for geotools 2.4 and geoserver trunk. We are
currently remediating a few issues relating to the recently published
Observations and Measurements, SensorML and SensorWebEnablement (SWE)
schems from the OGC.

Please advise if you need more info at this stage. Sorry I wasdnt
watching gt-users - probably wont do this until the modules are reayd
for supported status.

I'll let Gabriel help me get something set up first I guess. My main interest
is in getting a Geoserver up and running that does what I want it to do. I'll
ask if it turns out that I need more than that.

Lourens

--
ir. Lourens Veen University of Amsterdam - IBED
Nieuwe Achtergracht 166
Scientific Software Engineer 1018 WV Amsterdam, The Netherlands
EcoGRID-GAN t: +31 20-5257453 f: +31 20-5257431

11

Hi all,
sorry for the delay and the cross-post.
I'm trying to reply on a single message to the community-schema status
requests made over the last couple days.

Updated build docs:
<http://docs.codehaus.org/display/GEOS/Complex+Datastore&gt;

Note, however, that's for the braves willing to test alpha code, which lacks a
lot of documentation and may be difficult to get going.
Yet, I encourage you to try it out and keep asking questions, hopefully we'll
be able to improve this stuff a big deal in the near future.

Best regards,

Gabriel

On Wednesday 10 October 2007 04:01:57 pm Lourens Veen wrote:

On Wednesday 10 October 2007 13:06:56 Rob Atkinson wrote:
> Hi all,
>
> even though the complex-features branch is history, the functionality is
> being ported to the mainstream geotools code base. Currently there are
> unsupported modules for geotools 2.4 and geoserver trunk. We are
> currently remediating a few issues relating to the recently published
> Observations and Measurements, SensorML and SensorWebEnablement (SWE)
> schems from the OGC.
>
> Please advise if you need more info at this stage. Sorry I wasdnt
> watching gt-users - probably wont do this until the modules are reayd
> for supported status.

I'll let Gabriel help me get something set up first I guess. My main
interest is in getting a Geoserver up and running that does what I want it
to do. I'll ask if it turns out that I need more than that.

Lourens