[Geoserver-devel] sorry for missing IRC, here are my thoughts

GeoServer GeoServer Developer
1

Hi all,

Sorry I missed the IRC meeting today, was out of the office. I just read through the logs and wanted to share my thoughts.

It was no shock to me that people are surprised about the sudden move to make rest and geosearch core modules. First off, i have to apologize b/c this process has been poorly managed by me. These needed to be included in 1.7.1 and I did not spend any time before hand working to get them to a "releasable" state.

The requirement to include these modules comes down from those who pay the bills... so not getting them into this release is not really an option.

So the best I could come up with is a compromise. To include them in this release but start the process toward moving them to core modules, test coverage, documentation, etc... And indeed making this a blocker for the 1.7.2 release.

So I know we are diverging from project policy for this release but I ask for leniency.

Moving past his and ensuring that this sort of situation does not pop up again. We *desperately* need a proper and detailed road map for the project. Currently we sort of organize jira for a single release pushing back all sorts of issues to the next release and doing it all over again. While this works on a release by release basis its not all that great for long term planning. Having a proper road map in place would allow us to much better plan when requirements come in from people with money who want features.

I am open to strategies on how to plan this road map. I know a lot of different people want to see a lot of different things and have different requirements. So I am not sure how to proceed in order to build a balanced and fair road map.

Thoughts? Suggestions?

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

2

Justin Deoliveira ha scritto:

Hi all,

Sorry I missed the IRC meeting today, was out of the office. I just read through the logs and wanted to share my thoughts.

It was no shock to me that people are surprised about the sudden move to make rest and geosearch core modules. First off, i have to apologize b/c this process has been poorly managed by me. These needed to be included in 1.7.1 and I did not spend any time before hand working to get them to a "releasable" state.

The requirement to include these modules comes down from those who pay the bills... so not getting them into this release is not really an option.

So the best I could come up with is a compromise. To include them in this release but start the process toward moving them to core modules, test coverage, documentation, etc... And indeed making this a blocker for the 1.7.2 release.

Would making them into an extension for 1.7.1 and move them to core
by 1.7.2 be an acceptable (maybe a little more in line with policy)
path?

So I know we are diverging from project policy for this release but I ask for leniency.

Moving past his and ensuring that this sort of situation does not pop up again. We *desperately* need a proper and detailed road map for the project. Currently we sort of organize jira for a single release pushing back all sorts of issues to the next release and doing it all over again. While this works on a release by release basis its not all that great for long term planning. Having a proper road map in place would allow us to much better plan when requirements come in from people with money who want features.

Yep, very much agreed.

I am open to strategies on how to plan this road map. I know a lot of different people want to see a lot of different things and have different requirements. So I am not sure how to proceed in order to build a balanced and fair road map.

Well, all the people involved in GeoServer work some way or the other
for consultancy companies and as you said we need to pay our bills
as well.
So I guess the roadmap should point towards directions,
items, give a scope, and make sure it has enough sponsoring (but
just throwing out ideas is ok, provided we don't pretend others
to realize our dreams). But let it generic and relaxed enough to
allow for the extra stuff that plops into our consultancy
bucked and that really allows the people working on GeoServer to
live.

Hard balance to strike I know, but then again, we have only limited
control of what eager users might decide to sponsor tomorrow (and
when that happens it's a pity to let it go away).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

3

When you say "its not an option" because of "those who pay the bills",
you sound like you are either declaring post-facto or proposing a move
to a "Cathedral" model of OS. GeoTools/GeoServer has previously prided
itself as being a "Bazaar".

If this is not the intention, then a better mechanism needs to be
found. IMHO nothing should be promised to clients as "will be core"
until it has been run past the community and accepted by a formal
vote. The ability to meet the needs of paying clients is a well
understood requirement, but we need all to be playing by the same
rules for anyone else to have a chance of bringing resources.

Working up such a roadmap, with resourcing mapped to it, needs to be a
formal commitment by the community to support that roadmap by not
taking on mutually incompatible obligations - and this means not
suspending or dropping pieces of work being depended on by others
because of a new opportunity. We need to negotiate both inclusion and
changes to the roadmap.

Rob A

On Wed, Nov 26, 2008 at 5:54 AM, Andrea Aime <aaime@anonymised.com> wrote:

Justin Deoliveira ha scritto:

Hi all,

Sorry I missed the IRC meeting today, was out of the office. I just read
through the logs and wanted to share my thoughts.

It was no shock to me that people are surprised about the sudden move to
make rest and geosearch core modules. First off, i have to apologize b/c
this process has been poorly managed by me. These needed to be included
in 1.7.1 and I did not spend any time before hand working to get them to
a "releasable" state.

The requirement to include these modules comes down from those who pay
the bills... so not getting them into this release is not really an option.

So the best I could come up with is a compromise. To include them in
this release but start the process toward moving them to core modules,
test coverage, documentation, etc... And indeed making this a blocker
for the 1.7.2 release.

Would making them into an extension for 1.7.1 and move them to core
by 1.7.2 be an acceptable (maybe a little more in line with policy)
path?

So I know we are diverging from project policy for this release but I
ask for leniency.

Moving past his and ensuring that this sort of situation does not pop up
again. We *desperately* need a proper and detailed road map for the
project. Currently we sort of organize jira for a single release pushing
  back all sorts of issues to the next release and doing it all over
again. While this works on a release by release basis its not all that
great for long term planning. Having a proper road map in place would
allow us to much better plan when requirements come in from people with
money who want features.

Yep, very much agreed.

I am open to strategies on how to plan this road map. I know a lot of
different people want to see a lot of different things and have
different requirements. So I am not sure how to proceed in order to
build a balanced and fair road map.

Well, all the people involved in GeoServer work some way or the other
for consultancy companies and as you said we need to pay our bills
as well.
So I guess the roadmap should point towards directions,
items, give a scope, and make sure it has enough sponsoring (but
just throwing out ideas is ok, provided we don't pretend others
to realize our dreams). But let it generic and relaxed enough to
allow for the extra stuff that plops into our consultancy
bucked and that really allows the people working on GeoServer to
live.

Hard balance to strike I know, but then again, we have only limited
control of what eager users might decide to sponsor tomorrow (and
when that happens it's a pity to let it go away).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

Ok, I should give a bit more context. We have not promised any client that anything 'will be in core'. And if the community wants to block the KML stuff that OpenGeo is hoping to get in to core we are fine with that. OpenGeo is completely committed to more of a Bazaar type of model.

Justin's statement that it's not an option because it's a requirement of those who pay the bills is a bit strong. The requirement has come from me (with my OpenGeo manager hat on) very strongly, but my 'requirements' are always meant to be done in a way that works with the community. We have not committed to deliver anything to a client, we will still get paid.

I apologize for not being more clear on why we want this piece in so much. The requirement is actually out of a strong desire to take GeoServer to the next level by trying to tell a really compelling story with the next release. I originally posted on the GeoServer blog in May http://blog.geoserver.org/2008/05/13/geoserver-and-googles-geo-search/

These sets of improvements to me are the next evolution of the GeoWeb, making it so people can find real data by searching for it directly on Google Maps, and view huge datasets on Google Earth in a compelling way. This is two technological pieces that no one else has - vector super overlays in Google Earth and automatic generation of sitemaps. This has been OpenGeo's main focus for the 1.7.x release, indeed we had no real 'features' in the 1.7.0 release, the cool stuff came from GeoSolutions. But we put in months and months of effort to make a stable base, and even pulled our KML stuff from 1.7.0 when it wasn't stable enough.

What we are asking for is a temporary exception to the recently created process. I do hope the community can appreciate that we just as easily could have developed all the new stuff directly on trunk and slid it in with no discussion. But OpenGeo has taken a lead role on creating the community section, the extension section, and defining the process to get things in - doing all the grunt work to write the GSIPs and get them passed.

I hope that the GeoServer project remains flexible enough to grant exceptions when companies have screwed up and do just need to get things in. But in this case if the community does want to block the inclusion of these modules then I will accept that decision. Though I push down requirements fairly hard at times, as a manager I have always and always will accept the decisions of the PSC over OpenGeo's needs. And we've also always ensured that the PSC never has a majority of OpenGeo employees, despite the fact it'd be easy to argue we should from code contribution perspectives, and I even had Gabriel step down from the PSC when he joined us.

In this particular case I have been frustrated, as we've been working for many, many months on this. We have screwed up, especially with the GeoSearch, because we haven't been able to get the feedback we need on it from the crawlers. So I apologize for pushing on this requirement hard internally, which has lead to Justin asking for a very temporary exemption to the policy we defined.

If it must be blocked then I will just hold off on the PR push we were going to make, the hope for me was it would push the project forward to become the clear leader in web mapping, with technology that no one else has. But if we can't do that _with_ the community then it's better to just not. Perhaps we need to establish a process for exemptions? Because I think we want to have a way to be agile enough that we don't get in to burdening bureaucratic requirements that prevent cool things from happening.

Going forward, it would be really, really helpful if others could drive 'the better mechanism to be found'. OpenGeo ends up having to translate fairly vague notions that there should be more community in to the GSIPs and the process that makes it happen. We could use help with that. We could really use someone else taking the lead on defining the roadmap, gathering up everyone's plans and publishing them publicly. We're still in a position of being the one who has to ping each group that we know about - and more broadly we end up being the one to implement community building tasks when the PSC requires them. It'll be a _lot_ easier for OpenGeo to follow a set of community norms if we can just be a part of a community, and indeed would greatly prefer that. Going forward we will put more resources in to community building, as there are a few things I think we could do to improve it. But I'd really like to see others driving as well, so it's truly balanced.

I hope this comes off right. I'm trying to say that OpenGeo remains as committed to a bazaar model as we have always been. And we can continue put resources in to making that happen. But I think having others put more resources in to ensuring the bazaar model would do a lot more, so that it's not just voices objecting when we screw something up, but it's a broad group of people truly defining the norms together. From my perspective I'd love it if OpenGeo was no longer in the drivers seat, and could just follow norms that the community decides, but I'm still struggling with how to get there.

If the above seems vague, the concrete thing I'd like to see from 'the PSC' is an update of the roadmap - http://geoserver.org/display/GEOS/Roadmap I've always updated that myself, pinging every group I know is involved, figuring out what resources are actually committed. It's in desperate need of an update, and it'd be great if the PSC could negotiate it in public and get everyone talking about the resources to be put in.

And I apologize that I personally have not put as much time in to community building. I've been driven in my job a whole lot to try to bring money in and make things work, and at times it warps my perspective. Sometimes in my position I necessarily have to view the community requirements as a hurdle in 'getting things done'. But at my core I truly and deeply believe in the value of a real, collaborative community, and appreciate everyone who pushes me towards that more. Indeed I don't like how much I think about money and business cases these days. But hopefully soon OpenGeo will hire great people who will hold the drive to financial sustainability so I can be more the voice of community and collaboration, as it's a role I personally like a whole lot more.

best regards,

Chris

Rob Atkinson wrote:

When you say "its not an option" because of "those who pay the bills",
you sound like you are either declaring post-facto or proposing a move
to a "Cathedral" model of OS. GeoTools/GeoServer has previously prided
itself as being a "Bazaar".

If this is not the intention, then a better mechanism needs to be
found. IMHO nothing should be promised to clients as "will be core"
until it has been run past the community and accepted by a formal
vote. The ability to meet the needs of paying clients is a well
understood requirement, but we need all to be playing by the same
rules for anyone else to have a chance of bringing resources.

Working up such a roadmap, with resourcing mapped to it, needs to be a
formal commitment by the community to support that roadmap by not
taking on mutually incompatible obligations - and this means not
suspending or dropping pieces of work being depended on by others
because of a new opportunity. We need to negotiate both inclusion and
changes to the roadmap.

Rob A

On Wed, Nov 26, 2008 at 5:54 AM, Andrea Aime <aaime@anonymised.com> wrote:

Justin Deoliveira ha scritto:

Hi all,

Sorry I missed the IRC meeting today, was out of the office. I just read
through the logs and wanted to share my thoughts.

It was no shock to me that people are surprised about the sudden move to
make rest and geosearch core modules. First off, i have to apologize b/c
this process has been poorly managed by me. These needed to be included
in 1.7.1 and I did not spend any time before hand working to get them to
a "releasable" state.

The requirement to include these modules comes down from those who pay
the bills... so not getting them into this release is not really an option.

So the best I could come up with is a compromise. To include them in
this release but start the process toward moving them to core modules,
test coverage, documentation, etc... And indeed making this a blocker
for the 1.7.2 release.

Would making them into an extension for 1.7.1 and move them to core
by 1.7.2 be an acceptable (maybe a little more in line with policy)
path?

So I know we are diverging from project policy for this release but I
ask for leniency.

Moving past his and ensuring that this sort of situation does not pop up
again. We *desperately* need a proper and detailed road map for the
project. Currently we sort of organize jira for a single release pushing
  back all sorts of issues to the next release and doing it all over
again. While this works on a release by release basis its not all that
great for long term planning. Having a proper road map in place would
allow us to much better plan when requirements come in from people with
money who want features.

Yep, very much agreed.

I am open to strategies on how to plan this road map. I know a lot of
different people want to see a lot of different things and have
different requirements. So I am not sure how to proceed in order to
build a balanced and fair road map.

Well, all the people involved in GeoServer work some way or the other
for consultancy companies and as you said we need to pay our bills
as well.
So I guess the roadmap should point towards directions,
items, give a scope, and make sure it has enough sponsoring (but
just throwing out ideas is ok, provided we don't pretend others
to realize our dreams). But let it generic and relaxed enough to
allow for the extra stuff that plops into our consultancy
bucked and that really allows the people working on GeoServer to
live.

Hard balance to strike I know, but then again, we have only limited
control of what eager users might decide to sponsor tomorrow (and
when that happens it's a pity to let it go away).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

5

Apologies, my intentions were poorly phrased. "not an option" was too strong a statement. Really what the point of the email was is that I wanted an exception in project policy for a single release. But lesson learned, the community has spoken. Won't make the mistake again.

-Justin

Rob Atkinson wrote:

When you say "its not an option" because of "those who pay the bills",
you sound like you are either declaring post-facto or proposing a move
to a "Cathedral" model of OS. GeoTools/GeoServer has previously prided
itself as being a "Bazaar".

If this is not the intention, then a better mechanism needs to be
found. IMHO nothing should be promised to clients as "will be core"
until it has been run past the community and accepted by a formal
vote. The ability to meet the needs of paying clients is a well
understood requirement, but we need all to be playing by the same
rules for anyone else to have a chance of bringing resources.

Working up such a roadmap, with resourcing mapped to it, needs to be a
formal commitment by the community to support that roadmap by not
taking on mutually incompatible obligations - and this means not
suspending or dropping pieces of work being depended on by others
because of a new opportunity. We need to negotiate both inclusion and
changes to the roadmap.

Rob A

On Wed, Nov 26, 2008 at 5:54 AM, Andrea Aime <aaime@anonymised.com> wrote:

Justin Deoliveira ha scritto:

Hi all,

Sorry I missed the IRC meeting today, was out of the office. I just read
through the logs and wanted to share my thoughts.

It was no shock to me that people are surprised about the sudden move to
make rest and geosearch core modules. First off, i have to apologize b/c
this process has been poorly managed by me. These needed to be included
in 1.7.1 and I did not spend any time before hand working to get them to
a "releasable" state.

The requirement to include these modules comes down from those who pay
the bills... so not getting them into this release is not really an option.

So the best I could come up with is a compromise. To include them in
this release but start the process toward moving them to core modules,
test coverage, documentation, etc... And indeed making this a blocker
for the 1.7.2 release.

Would making them into an extension for 1.7.1 and move them to core
by 1.7.2 be an acceptable (maybe a little more in line with policy)
path?

So I know we are diverging from project policy for this release but I
ask for leniency.

Moving past his and ensuring that this sort of situation does not pop up
again. We *desperately* need a proper and detailed road map for the
project. Currently we sort of organize jira for a single release pushing
  back all sorts of issues to the next release and doing it all over
again. While this works on a release by release basis its not all that
great for long term planning. Having a proper road map in place would
allow us to much better plan when requirements come in from people with
money who want features.

Yep, very much agreed.

I am open to strategies on how to plan this road map. I know a lot of
different people want to see a lot of different things and have
different requirements. So I am not sure how to proceed in order to
build a balanced and fair road map.

Well, all the people involved in GeoServer work some way or the other
for consultancy companies and as you said we need to pay our bills
as well.
So I guess the roadmap should point towards directions,
items, give a scope, and make sure it has enough sponsoring (but
just throwing out ideas is ok, provided we don't pretend others
to realize our dreams). But let it generic and relaxed enough to
allow for the extra stuff that plops into our consultancy
bucked and that really allows the people working on GeoServer to
live.

Hard balance to strike I know, but then again, we have only limited
control of what eager users might decide to sponsor tomorrow (and
when that happens it's a pity to let it go away).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

6

Cool guys,

thanks for the clarification. I personally dont have a problem with
making a informed, mutually agreed exception (but then I'm bypassing
1.7 tactically so dont really have a valid vote IMHO :slight_smile:

I'll do my best to help fill in some of the roadmap aspects we are
committed to resourcing, probably as they become clearer.

FYI INSPIRE is about to publically release draft schemas - life is
going to hot up for Community schema support - I've fielded questions
from half a dozen agencies in the meteorology domain this week, and
they are not even in the first tranche of INSPIRE standards

Rob

On Thu, Nov 27, 2008 at 2:32 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Apologies, my intentions were poorly phrased. "not an option" was too strong
a statement. Really what the point of the email was is that I wanted an
exception in project policy for a single release. But lesson learned, the
community has spoken. Won't make the mistake again.

-Justin

Rob Atkinson wrote:

When you say "its not an option" because of "those who pay the bills",
you sound like you are either declaring post-facto or proposing a move
to a "Cathedral" model of OS. GeoTools/GeoServer has previously prided
itself as being a "Bazaar".

If this is not the intention, then a better mechanism needs to be
found. IMHO nothing should be promised to clients as "will be core"
until it has been run past the community and accepted by a formal
vote. The ability to meet the needs of paying clients is a well
understood requirement, but we need all to be playing by the same
rules for anyone else to have a chance of bringing resources.

Working up such a roadmap, with resourcing mapped to it, needs to be a
formal commitment by the community to support that roadmap by not
taking on mutually incompatible obligations - and this means not
suspending or dropping pieces of work being depended on by others
because of a new opportunity. We need to negotiate both inclusion and
changes to the roadmap.

Rob A

On Wed, Nov 26, 2008 at 5:54 AM, Andrea Aime <aaime@anonymised.com> wrote:

Justin Deoliveira ha scritto:

Hi all,

Sorry I missed the IRC meeting today, was out of the office. I just read
through the logs and wanted to share my thoughts.

It was no shock to me that people are surprised about the sudden move to
make rest and geosearch core modules. First off, i have to apologize b/c
this process has been poorly managed by me. These needed to be included
in 1.7.1 and I did not spend any time before hand working to get them to
a "releasable" state.

The requirement to include these modules comes down from those who pay
the bills... so not getting them into this release is not really an
option.

So the best I could come up with is a compromise. To include them in
this release but start the process toward moving them to core modules,
test coverage, documentation, etc... And indeed making this a blocker
for the 1.7.2 release.

Would making them into an extension for 1.7.1 and move them to core
by 1.7.2 be an acceptable (maybe a little more in line with policy)
path?

So I know we are diverging from project policy for this release but I
ask for leniency.

Moving past his and ensuring that this sort of situation does not pop up
again. We *desperately* need a proper and detailed road map for the
project. Currently we sort of organize jira for a single release pushing
back all sorts of issues to the next release and doing it all over
again. While this works on a release by release basis its not all that
great for long term planning. Having a proper road map in place would
allow us to much better plan when requirements come in from people with
money who want features.

Yep, very much agreed.

I am open to strategies on how to plan this road map. I know a lot of
different people want to see a lot of different things and have
different requirements. So I am not sure how to proceed in order to
build a balanced and fair road map.

Well, all the people involved in GeoServer work some way or the other
for consultancy companies and as you said we need to pay our bills
as well.
So I guess the roadmap should point towards directions,
items, give a scope, and make sure it has enough sponsoring (but
just throwing out ideas is ok, provided we don't pretend others
to realize our dreams). But let it generic and relaxed enough to
allow for the extra stuff that plops into our consultancy
bucked and that really allows the people working on GeoServer to
live.

Hard balance to strike I know, but then again, we have only limited
control of what eager users might decide to sponsor tomorrow (and
when that happens it's a pity to let it go away).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

7

On Wed, Nov 26, 2008 at 11:55 AM, Rob Atkinson <robatkinson101@anonymised.com> wrote:

Cool guys,

thanks for the clarification. I personally dont have a problem with
making a informed, mutually agreed exception (but then I’m bypassing
1.7 tactically so dont really have a valid vote IMHO :slight_smile:

I’ll do my best to help fill in some of the roadmap aspects we are
committed to resourcing, probably as they become clearer.

Thanks Rob.

FYI INSPIRE is about to publically release draft schemas - life is
going to hot up for Community schema support - I’ve fielded questions
from half a dozen agencies in the meteorology domain this week, and
they are not even in the first tranche of INSPIRE standards

Cool. Let’s try to come up with perhaps a specific roadmap / pitch to put on the GeoServer site, so we can point people at a plan, that they can help accelerate with funding. I’ll try to put some time in to this next week, perhaps we can try to pass it around on a wiki site. I think Justin took a first crack at it, turning the stuff Gabriel mentioned in to a document.

C

Rob

On Thu, Nov 27, 2008 at 2:32 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Apologies, my intentions were poorly phrased. “not an option” was too strong
a statement. Really what the point of the email was is that I wanted an
exception in project policy for a single release. But lesson learned, the
community has spoken. Won’t make the mistake again.

-Justin

Rob Atkinson wrote:

When you say “its not an option” because of “those who pay the bills”,
you sound like you are either declaring post-facto or proposing a move
to a “Cathedral” model of OS. GeoTools/GeoServer has previously prided
itself as being a “Bazaar”.

If this is not the intention, then a better mechanism needs to be
found. IMHO nothing should be promised to clients as “will be core”
until it has been run past the community and accepted by a formal
vote. The ability to meet the needs of paying clients is a well
understood requirement, but we need all to be playing by the same
rules for anyone else to have a chance of bringing resources.

Working up such a roadmap, with resourcing mapped to it, needs to be a
formal commitment by the community to support that roadmap by not
taking on mutually incompatible obligations - and this means not
suspending or dropping pieces of work being depended on by others
because of a new opportunity. We need to negotiate both inclusion and
changes to the roadmap.

Rob A

On Wed, Nov 26, 2008 at 5:54 AM, Andrea Aime <aaime@anonymised.com> wrote:

Justin Deoliveira ha scritto:

Hi all,

Sorry I missed the IRC meeting today, was out of the office. I just read
through the logs and wanted to share my thoughts.

It was no shock to me that people are surprised about the sudden move to
make rest and geosearch core modules. First off, i have to apologize b/c
this process has been poorly managed by me. These needed to be included
in 1.7.1 and I did not spend any time before hand working to get them to
a “releasable” state.

The requirement to include these modules comes down from those who pay
the bills… so not getting them into this release is not really an
option.

So the best I could come up with is a compromise. To include them in
this release but start the process toward moving them to core modules,
test coverage, documentation, etc… And indeed making this a blocker
for the 1.7.2 release.

Would making them into an extension for 1.7.1 and move them to core
by 1.7.2 be an acceptable (maybe a little more in line with policy)
path?

So I know we are diverging from project policy for this release but I
ask for leniency.

Moving past his and ensuring that this sort of situation does not pop up
again. We desperately need a proper and detailed road map for the
project. Currently we sort of organize jira for a single release pushing
back all sorts of issues to the next release and doing it all over
again. While this works on a release by release basis its not all that
great for long term planning. Having a proper road map in place would
allow us to much better plan when requirements come in from people with
money who want features.

Yep, very much agreed.

I am open to strategies on how to plan this road map. I know a lot of
different people want to see a lot of different things and have
different requirements. So I am not sure how to proceed in order to
build a balanced and fair road map.

Well, all the people involved in GeoServer work some way or the other
for consultancy companies and as you said we need to pay our bills
as well.
So I guess the roadmap should point towards directions,
items, give a scope, and make sure it has enough sponsoring (but
just throwing out ideas is ok, provided we don’t pretend others
to realize our dreams). But let it generic and relaxed enough to
allow for the extra stuff that plops into our consultancy
bucked and that really allows the people working on GeoServer to
live.

Hard balance to strike I know, but then again, we have only limited
control of what eager users might decide to sponsor tomorrow (and
when that happens it’s a pity to let it go away).

Cheers
Andrea

–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

This SF.Net email is sponsored by the Moblin Your Move Developer’s
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

8

It was no shock to me that people are surprised about the sudden move to make rest and geosearch core modules. First off, i have to apologize b/c this process has been poorly managed by me. These needed to be included in 1.7.1 and I did not spend any time before hand working to get them to a "releasable" state.
  
The requirement to include these modules comes down from those who pay the bills... so not getting them into this release is not really an option.
  

I am not surprised by the direction; can I ask for a GSIP to be written (if not approved) for the 1.7.1 release? There are a couple of RnD links passed around in the IRC logs; but nothing formal we can consider for approval...

I am open to strategies on how to plan this road map. I know a lot of different people want to see a lot of different things and have different requirements. So I am not sure how to proceed in order to build a balanced and fair road map.
  

I find it useful to have a separation between deadlines/funded work and strategic direction. We only really get in trouble when deadlines are endangered by so much active development a release window cannot be found. I agree that Jira is not the best tool for this sort of planning.

Jody

9

Chris Holmes wrote:

    FYI INSPIRE is about to publically release draft schemas - life is
    going to hot up for Community schema support - I've fielded questions
    from half a dozen agencies in the meteorology domain this week, and
    they are not even in the first tranche of INSPIRE standards

Cool. Let's try to come up with perhaps a specific roadmap / pitch to put on the GeoServer site, so we can point people at a plan, that they can help accelerate with funding. I'll try to put some time in to this next week, perhaps we can try to pass it around on a wiki site. I think Justin took a first crack at it, turning the stuff Gabriel mentioned in to a document.

Rob may be understating things a bit; I found a couple of Australian groups considering deegree simply based on their community schema support; and not entertaining the option of GeoServer. I also found a lot of interested in the versioned wfs work - which made me happy because it is very cool.

Jody

10

Ciao all,
please, read below...
-------------------------------------------------------
Eng. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

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

On Wed, Nov 26, 2008 at 2:59 PM, Chris Holmes <cholmes@anonymised.com> wrote:

Ok, I should give a bit more context. We have not promised any client
that anything 'will be in core'. And if the community wants to block
the KML stuff that OpenGeo is hoping to get in to core we are fine with
that. OpenGeo is completely committed to more of a Bazaar type of model.

Justin's statement that it's not an option because it's a requirement of
those who pay the bills is a bit strong. The requirement has come from
me (with my OpenGeo manager hat on) very strongly, but my 'requirements'
are always meant to be done in a way that works with the community. We
have not committed to deliver anything to a client, we will still get paid.

I apologize for not being more clear on why we want this piece in so
much. The requirement is actually out of a strong desire to take
GeoServer to the next level by trying to tell a really compelling story
with the next release. I originally posted on the GeoServer blog in May
http://blog.geoserver.org/2008/05/13/geoserver-and-googles-geo-search/

These sets of improvements to me are the next evolution of the GeoWeb,
making it so people can find real data by searching for it directly on
Google Maps, and view huge datasets on Google Earth in a compelling way.
This is two technological pieces that no one else has - vector super
overlays in Google Earth and automatic generation of sitemaps. This has
been OpenGeo's main focus for the 1.7.x release, indeed we had no real
'features' in the 1.7.0 release, the cool stuff came from GeoSolutions.
But we put in months and months of effort to make a stable base, and
even pulled our KML stuff from 1.7.0 when it wasn't stable enough.

What we are asking for is a temporary exception to the recently created
process. I do hope the community can appreciate that we just as easily
could have developed all the new stuff directly on trunk and slid it in
with no discussion. But OpenGeo has taken a lead role on creating the
community section, the extension section, and defining the process to
get things in - doing all the grunt work to write the GSIPs and get them
passed.

I hope that the GeoServer project remains flexible enough to grant
exceptions when companies have screwed up and do just need to get things
in. But in this case if the community does want to block the inclusion
of these modules then I will accept that decision. Though I push down
requirements fairly hard at times, as a manager I have always and always
will accept the decisions of the PSC over OpenGeo's needs. And we've
also always ensured that the PSC never has a majority of OpenGeo
employees, despite the fact it'd be easy to argue we should from code
contribution perspectives, and I even had Gabriel step down from the PSC
when he joined us.

In this particular case I have been frustrated, as we've been working
for many, many months on this. We have screwed up, especially with the
GeoSearch, because we haven't been able to get the feedback we need on
it from the crawlers. So I apologize for pushing on this requirement
hard internally, which has lead to Justin asking for a very temporary
exemption to the policy we defined.

If it must be blocked then I will just hold off on the PR push we were
going to make, the hope for me was it would push the project forward to
become the clear leader in web mapping, with technology that no one else
has. But if we can't do that _with_ the community then it's better to
just not. Perhaps we need to establish a process for exemptions?
Because I think we want to have a way to be agile enough that we don't
get in to burdening bureaucratic requirements that prevent cool things
from happening.

I am not personally against having these changes commited on the 1.7.x branch.
Honestly, I have been travelling a lot lately, therefore I am not been
able to fllow everything with the attention I would like to have,
anyway, it sounded a bit strange to slide in such changes at the very
lst moment.
The risk to break existing working things is pretty high. IMHO.
However, I think that in such cases
if the community agrees, a "release early, release often approach"
woudl work, so slide those changes in and aim for the next minor
release as quickly as possible, making sure to include feedback.

On the other side, I am glad to tell you that the perception of the
GeoServer is going up to the stars wherever I go .-).

Going forward, it would be really, really helpful if others could drive
'the better mechanism to be found'. OpenGeo ends up having to translate
fairly vague notions that there should be more community in to the GSIPs
and the process that makes it happen. We could use help with that. We
could really use someone else taking the lead on defining the roadmap,
gathering up everyone's plans and publishing them publicly. We're still
in a position of being the one who has to ping each group that we know
about - and more broadly we end up being the one to implement community
building tasks when the PSC requires them. It'll be a _lot_ easier for
OpenGeo to follow a set of community norms if we can just be a part of a
community, and indeed would greatly prefer that. Going forward we will
put more resources in to community building, as there are a few things I
think we could do to improve it. But I'd really like to see others
driving as well, so it's truly balanced.

You are right on this, and I personally think that myself and the
other guys have been espcially bad on communication.
I mean, pretty bad about coomunicating what we are doing as well as
pretty bad about communicating what we will do and we would like to
do.
I am imposing myself to change this habit and start putting out more
information both for the community as well as for the users.

I hope this comes off right. I'm trying to say that OpenGeo remains as
committed to a bazaar model as we have always been. And we can continue
put resources in to making that happen. But I think having others put
more resources in to ensuring the bazaar model would do a lot more, so
that it's not just voices objecting when we screw something up, but it's
a broad group of people truly defining the norms together. From my
perspective I'd love it if OpenGeo was no longer in the drivers seat,
and could just follow norms that the community decides, but I'm still
struggling with how to get there.

If the above seems vague, the concrete thing I'd like to see from 'the
PSC' is an update of the roadmap -
http://geoserver.org/display/GEOS/Roadmap I've always updated that
myself, pinging every group I know is involved, figuring out what
resources are actually committed. It's in desperate need of an update,
and it'd be great if the PSC could negotiate it in public and get
everyone talking about the resources to be put in.

I agree with you that _everybody_ that is part of the community should
expose its roadmap and participate to the generic roadmap.
This is a good opportunity to attract funding as well, therefore, I
will try to provide more information myself as far as we are
concerned.

Apart from this, I think it would be nice as well to have a pge where
we can sketch ideas/problems/solutions/thoughts before going to the
roadmap.
I have set up a sample page here
http://geoserver.org/display/GEOS/GeoServerEE+and+general+GeoServer+improvements+discussion
where me, alessio and aaime have dumped some thoughts about things to
improve.
It might be nice to have people check them, add new things then
probably move the discussion to ml.
In my mind I see this stages:

- sketch idea for new feature/improvement/fix on a wiki page
- move the idea to the ml for feedback and consensus
- update the roadmap looking for funding
- move from roadmap to gsip when funding is avaliable.

This way we could:

a> tell people what we would like to do and how (sketches + roadmpa)
b> tell people what we are doing (GSIP)

What do you guys think?

Simone.

And I apologize that I personally have not put as much time in to
community building. I've been driven in my job a whole lot to try to
bring money in and make things work, and at times it warps my
perspective. Sometimes in my position I necessarily have to view the
community requirements as a hurdle in 'getting things done'. But at my
core I truly and deeply believe in the value of a real, collaborative
community, and appreciate everyone who pushes me towards that more.
Indeed I don't like how much I think about money and business cases
these days. But hopefully soon OpenGeo will hire great people who will
hold the drive to financial sustainability so I can be more the voice of
community and collaboration, as it's a role I personally like a whole
lot more.

best regards,

Chris

Rob Atkinson wrote:
> When you say "its not an option" because of "those who pay the bills",
> you sound like you are either declaring post-facto or proposing a move
> to a "Cathedral" model of OS. GeoTools/GeoServer has previously prided
> itself as being a "Bazaar".
>
> If this is not the intention, then a better mechanism needs to be
> found. IMHO nothing should be promised to clients as "will be core"
> until it has been run past the community and accepted by a formal
> vote. The ability to meet the needs of paying clients is a well
> understood requirement, but we need all to be playing by the same
> rules for anyone else to have a chance of bringing resources.
>
> Working up such a roadmap, with resourcing mapped to it, needs to be a
> formal commitment by the community to support that roadmap by not
> taking on mutually incompatible obligations - and this means not
> suspending or dropping pieces of work being depended on by others
> because of a new opportunity. We need to negotiate both inclusion and
> changes to the roadmap.
>
>
> Rob A
>
> On Wed, Nov 26, 2008 at 5:54 AM, Andrea Aime <aaime@anonymised.com> wrote:
>> Justin Deoliveira ha scritto:
>>> Hi all,
>>>
>>> Sorry I missed the IRC meeting today, was out of the office. I just read
>>> through the logs and wanted to share my thoughts.
>>>
>>> It was no shock to me that people are surprised about the sudden move to
>>> make rest and geosearch core modules. First off, i have to apologize b/c
>>> this process has been poorly managed by me. These needed to be included
>>> in 1.7.1 and I did not spend any time before hand working to get them to
>>> a "releasable" state.
>>>
>>> The requirement to include these modules comes down from those who pay
>>> the bills... so not getting them into this release is not really an option.
>>>
>>> So the best I could come up with is a compromise. To include them in
>>> this release but start the process toward moving them to core modules,
>>> test coverage, documentation, etc... And indeed making this a blocker
>>> for the 1.7.2 release.
>> Would making them into an extension for 1.7.1 and move them to core
>> by 1.7.2 be an acceptable (maybe a little more in line with policy)
>> path?
>>
>>> So I know we are diverging from project policy for this release but I
>>> ask for leniency.
>>>
>>> Moving past his and ensuring that this sort of situation does not pop up
>>> again. We *desperately* need a proper and detailed road map for the
>>> project. Currently we sort of organize jira for a single release pushing
>>> back all sorts of issues to the next release and doing it all over
>>> again. While this works on a release by release basis its not all that
>>> great for long term planning. Having a proper road map in place would
>>> allow us to much better plan when requirements come in from people with
>>> money who want features.
>> Yep, very much agreed.
>>
>>> I am open to strategies on how to plan this road map. I know a lot of
>>> different people want to see a lot of different things and have
>>> different requirements. So I am not sure how to proceed in order to
>>> build a balanced and fair road map.
>> Well, all the people involved in GeoServer work some way or the other
>> for consultancy companies and as you said we need to pay our bills
>> as well.
>> So I guess the roadmap should point towards directions,
>> items, give a scope, and make sure it has enough sponsoring (but
>> just throwing out ideas is ok, provided we don't pretend others
>> to realize our dreams). But let it generic and relaxed enough to
>> allow for the extra stuff that plops into our consultancy
>> bucked and that really allows the people working on GeoServer to
>> live.
>>
>> Hard balance to strike I know, but then again, we have only limited
>> control of what eager users might decide to sponsor tomorrow (and
>> when that happens it's a pity to let it go away).
>>
>> Cheers
>> Andrea
>>
>> --
>> Andrea Aime
>> OpenGeo - http://opengeo.org
>> Expert service straight from the developers.
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

11

Jody Garnett ha scritto:
...

Cool. Let's try to come up with perhaps a specific roadmap / pitch to put on the GeoServer site, so we can point people at a plan, that they can help accelerate with funding. I'll try to put some time in to this next week, perhaps we can try to pass it around on a wiki site. I think Justin took a first crack at it, turning the stuff Gabriel mentioned in to a document.

Rob may be understating things a bit; I found a couple of Australian groups considering deegree simply based on their community schema support; and not entertaining the option of GeoServer.

Hum, is it really because of the ability to support complex features
natively, or just about the support of XSLT transformations?
If GeoServer had an XSLT based output format, would that solve the
problem?

I also found a lot of interested in the versioned wfs work - which made me happy because it is very cool.

Nice, that subsystem need some more love but it's definitely one
of the areas where we're one step ahead (maybe a bit too much ahead,
WFSV has been lying there for two years as of now...)

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

12

Simone Giannecchini ha scritto:

<snip>

Apart from this, I think it would be nice as well to have a pge where
we can sketch ideas/problems/solutions/thoughts before going to the
roadmap.
I have set up a sample page here
http://geoserver.org/display/GEOS/GeoServerEE+and+general+GeoServer+improvements+discussion
where me, alessio and aaime have dumped some thoughts about things to
improve.
It might be nice to have people check them, add new things then
probably move the discussion to ml.
In my mind I see this stages:

- sketch idea for new feature/improvement/fix on a wiki page
- move the idea to the ml for feedback and consensus
- update the roadmap looking for funding
- move from roadmap to gsip when funding is avaliable.

This way we could:

a> tell people what we would like to do and how (sketches + roadmpa)
b> tell people what we are doing (GSIP)

yes, and:

c> have ideas laid down enough to make reasonable estimates when looking
for sponsors

I like the idea quite a bit. I also would like to throw in the mix
the notion that a new module has to stage a little in extensions,
so that users can hit it for some time, before moving it into core.
And ask for a GSIP for that kind of move: given that the module
in question has already been in extensions and thus already has
a wiki page, decent code coverage and a maintainer the GSIP would
just have to explain why the module is important enough to become
part of the standard distribution, and the PSC should already have
an idea about the module, so the whole GSIP+vote should be quick.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

13

Cool. Let's try to come up with perhaps a specific roadmap / pitch to
put on the GeoServer site, so we can point people at a plan, that they can
help accelerate with funding. I'll try to put some time in to this next
week, perhaps we can try to pass it around on a wiki site. I think Justin
took a first crack at it, turning the stuff Gabriel mentioned in to a
document.

Rob may be understating things a bit; I found a couple of Australian
groups considering deegree simply based on their community schema support;
and not entertaining the option of GeoServer.

Hum, is it really because of the ability to support complex features
natively, or just about the support of XSLT transformations?
If GeoServer had an XSLT based output format, would that solve the
problem?

XSLT is not a solution in the long term - its slow, difficult to write
and will be very difficult to maintain when we have a few thousand
feature types in common use (eg INSPIRE).

Also, transforming queries using XSLT requires a lot of logic, and the
ability to execute any feature-relationship queries seems completely
infeasible.

And of course, standard SLD's can be defined against standard feature
types, (even if implemented as named WMS styles). So you would need
three complicated configurations for every feature type if you are
unable to model it properly internally.

The other bit of work, the ability to plug in functions, might allow
you to get away with this, but that would mean re-expressing the
standards in terms of supported functions, not feature models. I dont
see this happening in the near future.

The feedback I have from some of the people using Deegree in the
GeoSciML community is that would still welcome a configurable native
capability.

I haven't really thought to much about the implications for WFS-T to be honest.

Rob A

14

Rob Atkinson ha scritto:

Cool. Let's try to come up with perhaps a specific roadmap / pitch to
put on the GeoServer site, so we can point people at a plan, that they can
help accelerate with funding. I'll try to put some time in to this next
week, perhaps we can try to pass it around on a wiki site. I think Justin
took a first crack at it, turning the stuff Gabriel mentioned in to a
document.

Rob may be understating things a bit; I found a couple of Australian
groups considering deegree simply based on their community schema support;
and not entertaining the option of GeoServer.

Hum, is it really because of the ability to support complex features
natively, or just about the support of XSLT transformations?
If GeoServer had an XSLT based output format, would that solve the
problem?

XSLT is not a solution in the long term - its slow, difficult to write
and will be very difficult to maintain when we have a few thousand
feature types in common use (eg INSPIRE).

Also, transforming queries using XSLT requires a lot of logic, and the
ability to execute any feature-relationship queries seems completely
infeasible.

And of course, standard SLD's can be defined against standard feature
types, (even if implemented as named WMS styles). So you would need
three complicated configurations for every feature type if you are
unable to model it properly internally.

The other bit of work, the ability to plug in functions, might allow
you to get away with this, but that would mean re-expressing the
standards in terms of supported functions, not feature models. I dont
see this happening in the near future.

The feedback I have from some of the people using Deegree in the
GeoSciML community is that would still welcome a configurable native
capability.

I haven't really thought to much about the implications for WFS-T to be honest.

Whoa, I wasn't suggesting to use XSLT as the mapping tool. I was
suggesting it as a stop gap measure for
people that want to return a specific XML structure.
I said "output format" and I mean it, everything works within
the native type, only the output XML would be transformed (the very
last stage in the pipe).
And I'm not saying this because I'm particularly in love with
XSLT, but because:
* I've heard that in the community schema test over there someone
   used DeeGree because they could setup XSLT transformation and
* because a user already provided some code to make that kind of
   output format possible, I would just need to adapt it a little
   since the solution provided is not flexible enough imho: http://www.nabble.com/Adding-a-servlet-filter-for-XSL-transformation-on-WFS-gml-td19569283.html

(and with XSLT one could generate whatever he wants, not only other GML)

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

15

I'm all in favour of supporting XSLT, but not as an "outputFormat" -
rather as a configurable per-layer per-output format option.

XSLT would be fantastic as a stopgap to fix things or support encoding
options we want to play with but not code against, or to handle
complexity we cant efficiently handle with mappings

Rob

On Thu, Nov 27, 2008 at 7:52 PM, Andrea Aime <aaime@anonymised.com> wrote:

Rob Atkinson ha scritto:

Cool. Let's try to come up with perhaps a specific roadmap / pitch to
put on the GeoServer site, so we can point people at a plan, that they
can
help accelerate with funding. I'll try to put some time in to this
next
week, perhaps we can try to pass it around on a wiki site. I think
Justin
took a first crack at it, turning the stuff Gabriel mentioned in to a
document.

Rob may be understating things a bit; I found a couple of Australian
groups considering deegree simply based on their community schema
support;
and not entertaining the option of GeoServer.

Hum, is it really because of the ability to support complex features
natively, or just about the support of XSLT transformations?
If GeoServer had an XSLT based output format, would that solve the
problem?

XSLT is not a solution in the long term - its slow, difficult to write
and will be very difficult to maintain when we have a few thousand
feature types in common use (eg INSPIRE).

Also, transforming queries using XSLT requires a lot of logic, and the
ability to execute any feature-relationship queries seems completely
infeasible.

And of course, standard SLD's can be defined against standard feature
types, (even if implemented as named WMS styles). So you would need
three complicated configurations for every feature type if you are
unable to model it properly internally.

The other bit of work, the ability to plug in functions, might allow
you to get away with this, but that would mean re-expressing the
standards in terms of supported functions, not feature models. I dont
see this happening in the near future.

The feedback I have from some of the people using Deegree in the
GeoSciML community is that would still welcome a configurable native
capability.

I haven't really thought to much about the implications for WFS-T to be
honest.

Whoa, I wasn't suggesting to use XSLT as the mapping tool. I was
suggesting it as a stop gap measure for
people that want to return a specific XML structure.
I said "output format" and I mean it, everything works within
the native type, only the output XML would be transformed (the very
last stage in the pipe).
And I'm not saying this because I'm particularly in love with
XSLT, but because:
* I've heard that in the community schema test over there someone
used DeeGree because they could setup XSLT transformation and
* because a user already provided some code to make that kind of
output format possible, I would just need to adapt it a little
since the solution provided is not flexible enough imho:
http://www.nabble.com/Adding-a-servlet-filter-for-XSL-transformation-on-WFS-gml-td19569283.html

(and with XSLT one could generate whatever he wants, not only other GML)

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

16

Rob Atkinson ha scritto:

I'm all in favour of supporting XSLT, but not as an "outputFormat" -
rather as a configurable per-layer per-output format option.

In my mind I was figuring out two ouptut formats, XSLT-GML2, XSLT-GML3,
that would generate GML2 or GML3 respectively and apply a trasformation
that has either:
- setup in the feature type (maybe by dropping a file in the feature
   type folder)
- specified in the request as a format_option (as a URL to an accessible
   resource, much like &sld=... in WMS)
Think about someone interested in generating an HTML report out of
the features GML for example.

How would you play this instead?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

17

Rob Atkinson ha scritto:

The original type is totally meaningless _unless_ its known to the
client, so being able to meet a known schema is a useful role of XSLT.

Sorry, but given that the client cannot do any meaningful filter
because the actual schema is not the one in which the
features are returned, I fail to see the use of XSLT for schema
mapping unless the client uses a plain jane G

You are right there is no value using XSLT over an introspected
private feature type, cos if you know that you have a private
agreement and you can hard-code anything you like.

XSLT that replaces the returned GML is uselss for any kind of generic
client, no matter if the original feature type is introspected or
community.

all this is kinda academic unless the ability to use XSLT is actually
being contemplated. It would be cool, but just cant see it being
terribly useful as a generic XSLT format - you want to name all the
specific one's and override any existing ones if you choose to, then
its very very useful whenever we have a glitch in a format - a
deployer can always use an XSLT while we get the glitch fixed.

Oh, so all of this would just be a way to work around issues
in the encoder? This is such a small corner case that I won't
waste my time on such an implementation.

An XSLT output format can be much more powerful than this for
people that are coding up custom clients, and there are many
of those today. And there are also people that asked about it
because of the very practical reasons they are proficient
with XSLT and thus they can get whatever they need (e.g., an
HTML output, a pure text file, a custom json representation)
-> an output format that they are looking for, but that
has not been coded yet.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

18

Andrea Aime ha scritto:

Rob Atkinson ha scritto:

The original type is totally meaningless _unless_ its known to the
client, so being able to meet a known schema is a useful role of XSLT.

Sorry, but given that the client cannot do any meaningful filter
because the actual schema is not the one in which the
features are returned, I fail to see the use of XSLT for schema
mapping unless the client uses a plain jane G

... a plain jane GetFeature, that is
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

19

Andrea Aime wrote:

Cool. Let's try to come up with perhaps a specific roadmap / pitch to put on the GeoServer site, so we can point people at a plan, that they can help accelerate with funding. I'll try to put some time in to this next week, perhaps we can try to pass it around on a wiki site. I think Justin took a first crack at it, turning the stuff Gabriel mentioned in to a document.

Rob may be understating things a bit; I found a couple of Australian groups considering deegree simply based on their community schema support; and not entertaining the option of GeoServer.

Hum, is it really because of the ability to support complex features natively, or just about the support of XSLT transformations?

My understanding is that they do two things: a) a simple join b) xslt transformation to clean up the mess

If GeoServer had an XSLT based output format, would that solve the problem?

It may go a long ways in the right direction (but so would a fill in the blank template and that would be easier to debug); I suspect that the simple join may be where some of the value is.

I also found a lot of interested in the versioned wfs work - which made me happy because it is very cool.

Nice, that subsystem need some more love but it's definitely one of the areas where we're one step ahead (maybe a bit too much ahead,
WFSV has been lying there for two years as of now...)

So long! Well we better drum up more action...
Jody

20

Rob Atkinson ha scritto:

Hem Rob, can you please keep the ml cc'ed?

Thanks for the clarifications about your intentions. We'll liaise if
we want to exploit this feature in the short term.

I may have failed to convince you, but at least a dozen significant
(in the spatial data provision and best-practice setting)
organisations have chosen Deegree or home-grown hacks as a short term
solution because of this "corner case" - they actually failed to fully
articulate requirements until the last few days and we found that 5%
case where we couldnt do it "out-of-the-box" became a killer.

I'm still puzzled on how this can be used for anything other than
a last minute fix for a demo. On a real production server with real
clients hitting it, how do you cope for the changes in the structure
of the feature type when a filter tries to handle it?
Moreover, this kind of change would not require hijacking only the
standard GML output, but also the DescribeFeatureType response
(by all means doable as well, but before considering poking with
code that works and risk introducing bugs I need a solid
case).
The beauty of an output format is that it does not touch at all
the core WFS code so if any bug is lurking, it affects only that
part of the code. (GeoServer _must_ be solid, I won't settle
for anything less than production ready)

My bad for not investing in this solution as a backup strategy, but I
thought a year's effort cajoling test cases had us reasonably safe,
until like a flock of starlings they all suddenly decided on a model
change at the last moment.

Sigh, adding an XSLT thing to your branch would have been a matter of
a few days work, you should have told us...

Very pleased to hear your strategy wont preclude the hijack option -
that's really all I wanted to raise.

We may even be able to resource the effort in the new year, save you a weekend.

Now that would be nice :slight_smile:
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.