[Geoserver-devel] Status update + merge

Hi,

I’ve successfully merged my and Niels’s work. It was surprisingly easy with only one minor conflict. I noticed that you have discussed having a shared branch for me, Niels and Reni. This would be wise indeed as the danger of us either working on the same thing or against each other is pretty big.

The merged is at https://github.com/sampov2/geotools/tree/wfs-ng-improvements-sq

Do note however that my work stretches out to the geoserver codebase as well, though there’s not too many changes there to date. (https://github.com/sampov2/geoserver/tree/feature-wfsng-storedquery)

We need to figure out who’s responsible for the wfs-ng module in GS. Niels, Reni, have you built wfs-ng as a GS module yet? I’ve built one, but I made the mistake of naming it an “extension” instead of “community” so I probably have to at least redo that part.

The main goal of my work is pretty much done. There are two things that need to be discussed though:

  1. Stored query “feature type”

As discussed when I started this feature, the stored queries are currently exposed as special feature types provided by the data source. There’s a naming convention which then can be used to separate true feature types from stored queries. Is this still fine with everyone involved?

https://github.com/sampov2/geotools/blob/wfs-ng-improvements-sq/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/impl/WFSContentDataStore.java#L43

  1. Configuration UI

I haven’t written an UI to configure the stored query parameter mappings. As cascading stored queries are quite rare, do you think such a GUI is needed? Maybe writing clear documentation on how the featuretype.xml needs to be amended would be fine?

The configuration is required if the feature type should do dynamic mapping of query attributes (bbox, crs, etc) to stored query parameters. This configuration is not required for the SQL ViewParams to be mapped as stored query parameters. That happens automatically.

Sampo

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Thu, May 15, 2014 at 11:09 AM, Sampo Savolainen <
sampo.savolainen@anonymised.com> wrote:

Hi,

I've successfully merged my and Niels's work. It was surprisingly easy
with only one minor conflict. I noticed that you have discussed having a
shared branch for me, Niels and Reni. This would be wise indeed as the
danger of us either working on the same thing or against each other is
pretty big.

The merged is at
https://github.com/sampov2/geotools/tree/wfs-ng-improvements-sq

Do note however that my work stretches out to the geoserver codebase as
well, though there's not too many changes there to date. (
https://github.com/sampov2/geoserver/tree/feature-wfsng-storedquery)

We need to figure out who's responsible for the wfs-ng module in GS.
Niels, Reni, have you built wfs-ng as a GS module yet? I've built one, but
I made the mistake of naming it an "extension" instead of "community" so I
probably have to at least redo that part.

The main goal of my work is pretty much done. There are two things that
need to be discussed though:

1. Stored query "feature type"

As discussed when I started this feature, the stored queries are currently
exposed as special feature types provided by the data source. There's a
naming convention which then can be used to separate true feature types
from stored queries. Is this still fine with everyone involved?

https://github.com/sampov2/geotools/blob/wfs-ng-improvements-sq/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/impl/WFSContentDataStore.java#L43

2. Configuration UI

I haven't written an UI to configure the stored query parameter mappings.
As cascading stored queries are quite rare, do you think such a GUI is
needed? Maybe writing clear documentation on how the featuretype.xml needs
to be amended would be fine?

The configuration is required if the feature type should do dynamic
mapping of query attributes (bbox, crs, etc) to stored query parameters.
This configuration is not required for the SQL ViewParams to be mapped as
stored query parameters. That happens automatically.

Sampo, GeoServer wise there is an extra snatch.

GeoServer core currently depends on the wfs module in order to support WMS
feature portrayal services,
that is, requests where the indication of the data to be painted is
provided in the request by giving
a link to a capabilities document and a feature type.

I see a few ways forward:
1) drop feature portrayal support and make wfs a community module
2) make fetaure portrayal behavior pluggable, and implement it in a wfs
extension/community module or another module that would depend on it
3) replace the current wfs in core, and have core depend on wfs-ng instead

1) has backwards compatibility issues for the functionality we lose, and
whoever is cascading a WFS today would have to add a new extension module
when upgrading geoserver

2) is hard to implement

3) is risky and requires a GSIP, but if we do it only on trunk it's (imho)
probably the best path forward

Cheers
Andrea

--

Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

On Thu, May 15, 2014 at 12:42 PM, Andrea Aime
<andrea.aime@anonymised.com>wrote:

GeoServer core currently depends on the wfs module in order to support WMS
feature portrayal services,
that is, requests where the indication of the data to be painted is
provided in the request by giving
a link to a capabilities document and a feature type.

I see a few ways forward:
1) drop feature portrayal support and make wfs a community module
2) make fetaure portrayal behavior pluggable, and implement it in a wfs
extension/community module or another module that would depend on it
3) replace the current wfs in core, and have core depend on wfs-ng instead

1) has backwards compatibility issues for the functionality we lose, and
whoever is cascading a WFS today would have to add a new extension module
when upgrading geoserver

2) is hard to implement

3) is risky and requires a GSIP, but if we do it only on trunk it's (imho)
probably the best path forward

Considering that WFS-NG is supposed to replace WFS (due to the quality and
maintainability of the old module), 3) sounds like the correct way to go.

Also, 2) makes little sense in the broader side of things: why should WFS
be good at something that WFS-NG is not good at, and vice versa? Both
modules attempt to solve the same issue and we don't want development
effort to be split between the two.

As WFS and WFS-NG don't share namespace, it would be feasible to start on
this path by adding gt-wfs-ng as a core dependency and then transitioning
the portrayal support to WFS-NG when it's ready. It should even be possible
to use legacy WFS features even after GS transitions to use NG as a default
- there's probably little need to break the old configuration. (at least
until we want to scrap the old WFS module)

If this path is taken, where (=in which module) should the
XStreamPersisterInitializer code required for stored query configuration
live?

Sampo

--
Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

Thanks for the merging Sampo, looks good.

Cheers
Niels

On 15/05/14 11:09, Sampo Savolainen wrote:

Hi,

I've successfully merged my and Niels's work. It was surprisingly easy with only one minor conflict. I noticed that you have discussed having a shared branch for me, Niels and Reni. This would be wise indeed as the danger of us either working on the same thing or against each other is pretty big.

The merged is at https://github.com/sampov2/geotools/tree/wfs-ng-improvements-sq

Do note however that my work stretches out to the geoserver codebase as well, though there's not too many changes there to date. (https://github.com/sampov2/geoserver/tree/feature-wfsng-storedquery)

We need to figure out who's responsible for the wfs-ng module in GS. Niels, Reni, have you built wfs-ng as a GS module yet? I've built one, but I made the mistake of naming it an "extension" instead of "community" so I probably have to at least redo that part.

The main goal of my work is pretty much done. There are two things that need to be discussed though:

1. Stored query "feature type"

As discussed when I started this feature, the stored queries are currently exposed as special feature types provided by the data source. There's a naming convention which then can be used to separate true feature types from stored queries. Is this still fine with everyone involved?

https://github.com/sampov2/geotools/blob/wfs-ng-improvements-sq/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/impl/WFSContentDataStore.java#L43

2. Configuration UI

I haven't written an UI to configure the stored query parameter mappings. As cascading stored queries are quite rare, do you think such a GUI is needed? Maybe writing clear documentation on how the featuretype.xml needs to be amended would be fine?

The configuration is required if the feature type should do dynamic mapping of query attributes (bbox, crs, etc) to stored query parameters. This configuration is not required for the SQL ViewParams to be mapped as stored query parameters. That happens automatically.

  Sampo

--
Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com <mailto:sampo.savolainen@anonymised.com>
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com <http://www.spatineo.com>, twitter.com/#!/spatineo <http://twitter.com/#!/spatineo&gt;
www.linkedin.com/company/spatineo-inc <http://www.linkedin.com/company/spatineo-inc&gt;

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Hi,

Should I just create a pull request on your branch and then I could continue work on a branch based off your branch? This would mean bundling our changes into a single changeset. I haven’t heard any opposition to this idea, though. Thoughts?

Sampo

···

On Mon, May 19, 2014 at 11:23 AM, Niels Charlier <niels@anonymised.com> wrote:

Thanks for the merging Sampo, looks good.

Cheers
Niels

On 15/05/14 11:09, Sampo Savolainen wrote:

Hi,

I’ve successfully merged my and Niels’s work. It was surprisingly easy with only one minor conflict. I noticed that you have discussed having a shared branch for me, Niels and Reni. This would be wise indeed as the danger of us either working on the same thing or against each other is pretty big.

The merged is at https://github.com/sampov2/geotools/tree/wfs-ng-improvements-sq

Do note however that my work stretches out to the geoserver codebase as well, though there’s not too many changes there to date. (https://github.com/sampov2/geoserver/tree/feature-wfsng-storedquery)

We need to figure out who’s responsible for the wfs-ng module in GS. Niels, Reni, have you built wfs-ng as a GS module yet? I’ve built one, but I made the mistake of naming it an “extension” instead of “community” so I probably have to at least redo that part.

The main goal of my work is pretty much done. There are two things that need to be discussed though:

  1. Stored query “feature type”

As discussed when I started this feature, the stored queries are currently exposed as special feature types provided by the data source. There’s a naming convention which then can be used to separate true feature types from stored queries. Is this still fine with everyone involved?

https://github.com/sampov2/geotools/blob/wfs-ng-improvements-sq/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/impl/WFSContentDataStore.java#L43

  1. Configuration UI

I haven’t written an UI to configure the stored query parameter mappings. As cascading stored queries are quite rare, do you think such a GUI is needed? Maybe writing clear documentation on how the featuretype.xml needs to be amended would be fine?

The configuration is required if the feature type should do dynamic mapping of query attributes (bbox, crs, etc) to stored query parameters. This configuration is not required for the SQL ViewParams to be mapped as stored query parameters. That happens automatically.

Sampo

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
[http://p.sf.net/sfu/SauceLabs](http://p.sf.net/sfu/SauceLabs)
_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)


“Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.”
http://p.sf.net/sfu/SauceLabs


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

There is currently a pull request for my changes being reviewed.
I'm not sure when your changes will be reviewed and by whom. But I assume they need to be reviewed separately, and preferably not at the same time. But it is already good that your changes have now a base from my branch.

Regards
Niels

On 19/05/14 10:48, Sampo Savolainen wrote:

Hi,

Should I just create a pull request on your branch and then I could continue work on a branch based off your branch? This would mean bundling our changes into a single changeset. I haven't heard any opposition to this idea, though. Thoughts?

Sampo

On Mon, May 19, 2014 at 11:23 AM, Niels Charlier <niels@anonymised.com <mailto:niels@anonymised.com>> wrote:

    Thanks for the merging Sampo, looks good.

    Cheers
    Niels

    On 15/05/14 11:09, Sampo Savolainen wrote:

    Hi,

    I've successfully merged my and Niels's work. It was surprisingly
    easy with only one minor conflict. I noticed that you have
    discussed having a shared branch for me, Niels and Reni. This
    would be wise indeed as the danger of us either working on the
    same thing or against each other is pretty big.

    The merged is at
    https://github.com/sampov2/geotools/tree/wfs-ng-improvements-sq

    Do note however that my work stretches out to the geoserver
    codebase as well, though there's not too many changes there to
    date.
    (https://github.com/sampov2/geoserver/tree/feature-wfsng-storedquery)

    We need to figure out who's responsible for the wfs-ng module in
    GS. Niels, Reni, have you built wfs-ng as a GS module yet? I've
    built one, but I made the mistake of naming it an "extension"
    instead of "community" so I probably have to at least redo that part.

    The main goal of my work is pretty much done. There are two
    things that need to be discussed though:

    1. Stored query "feature type"

    As discussed when I started this feature, the stored queries are
    currently exposed as special feature types provided by the data
    source. There's a naming convention which then can be used to
    separate true feature types from stored queries. Is this still
    fine with everyone involved?

    https://github.com/sampov2/geotools/blob/wfs-ng-improvements-sq/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/impl/WFSContentDataStore.java#L43

    2. Configuration UI

    I haven't written an UI to configure the stored query parameter
    mappings. As cascading stored queries are quite rare, do you
    think such a GUI is needed? Maybe writing clear documentation on
    how the featuretype.xml needs to be amended would be fine?

    The configuration is required if the feature type should do
    dynamic mapping of query attributes (bbox, crs, etc) to stored
    query parameters. This configuration is not required for the SQL
    ViewParams to be mapped as stored query parameters. That happens
    automatically.

      Sampo

    -- Sampo Savolainen
    R&D Director, Spatineo Oy
    sampo.savolainen@anonymised.com <mailto:sampo.savolainen@anonymised.com>
    +358-407555649 <tel:%2B358-407555649>
    Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
    www.spatineo.com <http://www.spatineo.com>,
    twitter.com/#!/spatineo <http://twitter.com/#!/spatineo&gt;
    www.linkedin.com/company/spatineo-inc
    <http://www.linkedin.com/company/spatineo-inc&gt;

    This message may contain privileged and/or confidential
    information. If you
    have received this e-mail in error or are not the intended
    recipient, you
    may not use, copy, disseminate, or distribute it; do not open any
    attachments, delete it immediately from your system and notify
    the sender
    promptly by e-mail that you have done so.

    ------------------------------------------------------------------------------
    "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
    Instantly run your Selenium tests across 300+ browser/OS combos.
    Get unparalleled scalability from the best Selenium testing platform available
    Simple to use. Nothing to install. Get started now for free."
    http://p.sf.net/sfu/SauceLabs

    _______________________________________________
    Geoserver-devel mailing list
    Geoserver-devel@lists.sourceforge.net <mailto:Geoserver-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/geoserver-devel

    ------------------------------------------------------------------------------
    "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
    Instantly run your Selenium tests across 300+ browser/OS combos.
    Get unparalleled scalability from the best Selenium testing
    platform available
    Simple to use. Nothing to install. Get started now for free."
    http://p.sf.net/sfu/SauceLabs
    _______________________________________________
    Geoserver-devel mailing list
    Geoserver-devel@lists.sourceforge.net
    <mailto:Geoserver-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com <mailto:sampo.savolainen@anonymised.com>
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com <http://www.spatineo.com>, twitter.com/#!/spatineo <http://twitter.com/#!/spatineo&gt;
www.linkedin.com/company/spatineo-inc <http://www.linkedin.com/company/spatineo-inc&gt;

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

Ok. I hadn’t noticed you were this far along. I was proposing merging our changesets to avoid us from diverging from this point onwards. As you’re almost done so we should be pretty safe from that.

Andrea, Justin, or anyone: do you guys have any comments regarding the questions I brought up earlier when I started this thread?

Sampo

···

On Mon, May 19, 2014 at 11:54 AM, Niels Charlier <niels@anonymised.com> wrote:

There is currently a pull request for my changes being reviewed.
I’m not sure when your changes will be reviewed and by whom. But I assume they need to be reviewed separately, and preferably not at the same time. But it is already good that your changes have now a base from my branch.

Regards
Niels

On 19/05/14 10:48, Sampo Savolainen wrote:

Hi,

Should I just create a pull request on your branch and then I could continue work on a branch based off your branch? This would mean bundling our changes into a single changeset. I haven’t heard any opposition to this idea, though. Thoughts?

Sampo

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Mon, May 19, 2014 at 11:23 AM, Niels Charlier <niels@anonymised.com> wrote:

Thanks for the merging Sampo, looks good.

Cheers
Niels

On 15/05/14 11:09, Sampo Savolainen wrote:

Hi,

I’ve successfully merged my and Niels’s work. It was surprisingly easy with only one minor conflict. I noticed that you have discussed having a shared branch for me, Niels and Reni. This would be wise indeed as the danger of us either working on the same thing or against each other is pretty big.

The merged is at https://github.com/sampov2/geotools/tree/wfs-ng-improvements-sq

Do note however that my work stretches out to the geoserver codebase as well, though there’s not too many changes there to date. (https://github.com/sampov2/geoserver/tree/feature-wfsng-storedquery)

We need to figure out who’s responsible for the wfs-ng module in GS. Niels, Reni, have you built wfs-ng as a GS module yet? I’ve built one, but I made the mistake of naming it an “extension” instead of “community” so I probably have to at least redo that part.

The main goal of my work is pretty much done. There are two things that need to be discussed though:

  1. Stored query “feature type”

As discussed when I started this feature, the stored queries are currently exposed as special feature types provided by the data source. There’s a naming convention which then can be used to separate true feature types from stored queries. Is this still fine with everyone involved?

https://github.com/sampov2/geotools/blob/wfs-ng-improvements-sq/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/impl/WFSContentDataStore.java#L43

  1. Configuration UI

I haven’t written an UI to configure the stored query parameter mappings. As cascading stored queries are quite rare, do you think such a GUI is needed? Maybe writing clear documentation on how the featuretype.xml needs to be amended would be fine?

The configuration is required if the feature type should do dynamic mapping of query attributes (bbox, crs, etc) to stored query parameters. This configuration is not required for the SQL ViewParams to be mapped as stored query parameters. That happens automatically.

Sampo

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
[http://p.sf.net/sfu/SauceLabs](http://p.sf.net/sfu/SauceLabs)
_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)


“Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.”
http://p.sf.net/sfu/SauceLabs


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

Hey Sampo,

Sorry I haven’t been following the work too closely, but my first initial thoughts.

  1. What would be the consequence of not using the naming convention and just exposing the stored queries directly as they are named? Is it solely to make it explicit that the type is a stored query, and requires extra parameters to function?

  2. We generally discourage users from editing configuration files directly so not sure how much of an option that is. It would also make the feature unusable with alternative backends like jdbcconfig. While I am not saying it’s a show stopper to have no config UI it would certainly be ideal.

-Justin

···

On Mon, May 19, 2014 at 4:27 AM, Sampo Savolainen <sampo.savolainen@anonymised.com889…> wrote:

Ok. I hadn’t noticed you were this far along. I was proposing merging our changesets to avoid us from diverging from this point onwards. As you’re almost done so we should be pretty safe from that.

Andrea, Justin, or anyone: do you guys have any comments regarding the questions I brought up earlier when I started this thread?

Sampo


“Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.”
http://p.sf.net/sfu/SauceLabs


Geoserver-devel mailing list
Geoserver-devel@anonymised.comt
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

On Mon, May 19, 2014 at 11:54 AM, Niels Charlier <niels@anonymised.com> wrote:

There is currently a pull request for my changes being reviewed.
I’m not sure when your changes will be reviewed and by whom. But I assume they need to be reviewed separately, and preferably not at the same time. But it is already good that your changes have now a base from my branch.

Regards
Niels

On 19/05/14 10:48, Sampo Savolainen wrote:

Hi,

Should I just create a pull request on your branch and then I could continue work on a branch based off your branch? This would mean bundling our changes into a single changeset. I haven’t heard any opposition to this idea, though. Thoughts?

Sampo

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Mon, May 19, 2014 at 11:23 AM, Niels Charlier <niels@anonymised.com> wrote:

Thanks for the merging Sampo, looks good.

Cheers
Niels

On 15/05/14 11:09, Sampo Savolainen wrote:

Hi,

I’ve successfully merged my and Niels’s work. It was surprisingly easy with only one minor conflict. I noticed that you have discussed having a shared branch for me, Niels and Reni. This would be wise indeed as the danger of us either working on the same thing or against each other is pretty big.

The merged is at https://github.com/sampov2/geotools/tree/wfs-ng-improvements-sq

Do note however that my work stretches out to the geoserver codebase as well, though there’s not too many changes there to date. (https://github.com/sampov2/geoserver/tree/feature-wfsng-storedquery)

We need to figure out who’s responsible for the wfs-ng module in GS. Niels, Reni, have you built wfs-ng as a GS module yet? I’ve built one, but I made the mistake of naming it an “extension” instead of “community” so I probably have to at least redo that part.

The main goal of my work is pretty much done. There are two things that need to be discussed though:

  1. Stored query “feature type”

As discussed when I started this feature, the stored queries are currently exposed as special feature types provided by the data source. There’s a naming convention which then can be used to separate true feature types from stored queries. Is this still fine with everyone involved?

https://github.com/sampov2/geotools/blob/wfs-ng-improvements-sq/modules/unsupported/wfs-ng/src/main/java/org/geotools/data/wfs/impl/WFSContentDataStore.java#L43

  1. Configuration UI

I haven’t written an UI to configure the stored query parameter mappings. As cascading stored queries are quite rare, do you think such a GUI is needed? Maybe writing clear documentation on how the featuretype.xml needs to be amended would be fine?

The configuration is required if the feature type should do dynamic mapping of query attributes (bbox, crs, etc) to stored query parameters. This configuration is not required for the SQL ViewParams to be mapped as stored query parameters. That happens automatically.

Sampo

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
[http://p.sf.net/sfu/SauceLabs](http://p.sf.net/sfu/SauceLabs)
_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@anonymised.comists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)


“Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.”
http://p.sf.net/sfu/SauceLabs


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com889…
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

Hi Justin,

···

On Tue, May 20, 2014 at 6:50 AM, Justin Deoliveira <jdeolive@anonymised.com…3839…> wrote:

  1. What would be the consequence of not using the naming convention and just exposing the stored queries directly as they are named? Is it solely to make it explicit that the type is a stored query, and requires extra parameters to function?

I’m mostly concerned with naming conflicts. One option would be to define a static namespace for stored queries (something like “http://geotools.org/wfs-ng/stored-query”) and have the local part contain the stored query id directly. Do you think it would be a problem that all wfs-ng data stores would report features in the same name space? Especially noting that all WFS 2.0 implementations offer the GetFeatureById stored query.

  1. We generally discourage users from editing configuration files directly so not sure how much of an option that is. It would also make the feature unusable with alternative backends like jdbcconfig. While I am not saying it’s a show stopper to have no config UI it would certainly be ideal.

Ok. I’ll check if the hours in the project with FMI allow for me to write the UI. There’s probably enough left, but it’s nevertheless good to know that a missing UI not a complete show stopper.

Sampo

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.