Re: [Geoserver-devel] Performance versus conformance in WFS 2.0 paging

[Ben Caradoc-Davies]

On 16/05/12 14:50, Andrea Aime wrote:
> Ben, it's a 7 lines mail, how could you miss the second sentence?
> "less ideally a way to at least detect if maxFeatures was explicitly
> provided (if we don't have that either,
> it's definitely not paging)"
> -->  you can know if client asked for paging

Andrea, I didn't miss what you wrote, it just didn't make sense to me. 
That isn't paging; this is usually just some poor client exploring a 
service and not wanting to get 1.3 million features. when it can only 
handle 200.

-- 
Ben Caradoc-Davies 
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Performance versus conformance in WFS 2.0 paging

[Andrea Aime]

On Wed, May 16, 2012 at 8:14 AM, Ben Caradoc-Davies
 wrote:
> On 16/05/12 14:07, Andrea Aime wrote:
>> In a nutshell, no, we need to grow a way to tell if paging was being
>> asked for or not.
>
> Can't be done. The problem is you don't know if paging is being asked
> for until you get the request for the next page.

Ben, it's a 7 lines mail, how could you miss the second sentence?

"less ideally a way to at least detect if maxFeatures was explicitly
provided (if we don't have that either,
it's definitely not paging)"

--> you can know if client asked for paging

Cheers
Andrea

-- 
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:      +39 0584 962313
mob:    +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Want to migrate from geoserver 1.7.x to 2.2 beta

[Manik Goyal]

Hi ,

I am currently working on geoserver 1.7.x and want to migrate to 2.2 beta 
version ,I copied the data folder from 1.7.x version to the 2.2 as 
mentioned in one of your blog still all the my layers/styles that i 
created in older version (geoserver 1.7.x) is not showing up in geoserver 
2.2 beta version, please let me know ,  what went wrong and how can I 
migrate from geoserver 1.7  to geoserver 2.2.

Thanks 
Manik Goyal







"Disclaimer: This message and any attachments contain information that may 
be RMSI Private Limited. confidential and/or privileged. If you are not 
the intended recipient (or authorized to receive for the intended 
recipient), and have received this message in error, any use, disclosure 
or distribution is strictly prohibited. If you have received this message 
in error, please notify the sender immediately by replying to the e-mail 
and permanently deleting the message from your computer and/or storage 
system"

http://www.rmsi.com 

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Performance versus conformance in WFS 2.0 paging

[Ben Caradoc-Davies]

I also found this stability requirement and a rather leading hint from 
p41 of the WFS 2.0.0 spec (OGC 09-025r1 and ISO/DIS 19142).

**

7.9.2.5.4.4
Sort processing
A web feature service that receives an ad hoc query expression without a 
sorting clause, shall generate a
response document in which features are presented in whatever order the 
server chooses. However, to
comply with this International Standard, servers shall ensure that 
whatever order is presented when an ad hoc
query, not containing a sort clause, is first executed is preserved 
across subsequent executions of the same
ad hoc query expression on the same set of features.
EXAMPLE
A server may choose to sort the features by their gml:id if the client 
has not specified a specific sorting
clause. Subsequent invocations of the same query expression on the same 
set of data should result in a response
document that presents the features in the same order.

**

Kind regards,
Ben.

On 16/05/12 12:16, Ben Caradoc-Davies wrote:
> I have encountered a decision point while fixing a bug in WFS 2.0 paging:
> https://jira.codehaus.org/browse/GEOS-5085
>
> WFS 2.0 paging is implemented by specifying startindex and count (like
> maxFeatures in 1.1.0) in a GetFeature request. Our implementation uses
> the presence of startindex to detect whether paging is in use; to ensure
> consistency across pages, results must be sorted when paging is in use.
> However, this has one undesirable implication: our use of startindex is
> at odds with the WFS 2.0 spec, which specifies that startindex defaults
> to zero.
>
> I see two options:
>
> Option 1: Performance
> - the presence of startindex triggers sorting for paging consistency
> - the absence of startindex means that responses can be unsorted for
> greater performance
> - startindex=0 and the absence of startindex are treated differently
> - clients that omit startindex for their first page of paged results
> will get inconsistent pages (was are *assuming* that all paging clients
> set startindex=0 for their first page, despite this being explicitly the
> default in the spec)
> - we will have a surprising nudge-nudge-wink-wink interpretation of the
> WFS 2.0 spec that differs from the tabulated default value of startindex
>
> Option 2: Conformance
> - startindex=0 has exactly the same effect as startindex not being
> specified
> - all WFS 2.0 responses will be sorted, at the cost of performance
> - we are conformant with the default values specified in the WFS 2.0 spec
>
> So, in a nutshell, should all WFS 2.0 responses be sorted?
>
> Kind regards,
>

-- 
Ben Caradoc-Davies 
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Moving code from GeoServer to GeoTools

[Ben Caradoc-Davies]

Thanks, Chris, that sounds like an ideal solution.

On 16/05/12 05:26, Chris Holmes wrote:
> I think the thing to do is have the PSC set a policy on migrating code from 
> GeoServer to GeoTools. I think it could set some threshold under which moving 
> code over is pre-approved, and that larger commits should ask the PSC? I 
> don't think it has to be a ton of red tape, just a GSIP that we adopt. And 
> then TOPP can reiterate that somehow officially, and not have to ask every 
> time.

-- 
Ben Caradoc-Davies 
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Performance versus conformance in WFS 2.0 paging

[Ben Caradoc-Davies]

On 16/05/12 14:07, Andrea Aime wrote:
> In a nutshell, no, we need to grow a way to tell if paging was being
> asked for or not.

Can't be done. The problem is you don't know if paging is being asked 
for until you get the request for the next page.

First request: "Hello, please give me 1000 features" (count=1000, no 
startindex)

(Client sees that numberMatched>1000)

Second request: "Hello, please give me the next 1000 features" 
(count=1000, startindex=1000)

How can GeoServer know if the client will ever make the second request? 
The client may just go away. But this is also a perfectly legitimate 
paging use-case, where the client asks for two pages.

If GeoServer gives the client 1000 unsorted features, it will not be 
able to respond to the second request and maintain consistency because 
unsorted responses are not stable.

Kind regards,

-- 
Ben Caradoc-Davies 
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Performance versus conformance in WFS 2.0 paging

[Andrea Aime]

On Wed, May 16, 2012 at 6:16 AM, Ben Caradoc-Davies
 wrote:
> I have encountered a decision point while fixing a bug in WFS 2.0 paging:
> https://jira.codehaus.org/browse/GEOS-5085
>
> WFS 2.0 paging is implemented by specifying startindex and count (like
> maxFeatures in 1.1.0) in a GetFeature request. Our implementation uses the
> presence of startindex to detect whether paging is in use; to ensure
> consistency across pages, results must be sorted when paging is in use.
> However, this has one undesirable implication: our use of startindex is at
> odds with the WFS 2.0 spec, which specifies that startindex defaults to
> zero.
>
> I see two options:
>
> Option 1: Performance
> - the presence of startindex triggers sorting for paging consistency
> - the absence of startindex means that responses can be unsorted for greater
> performance
> - startindex=0 and the absence of startindex are treated differently
> - clients that omit startindex for their first page of paged results will
> get inconsistent pages (was are *assuming* that all paging clients set
> startindex=0 for their first page, despite this being explicitly the default
> in the spec)
> - we will have a surprising nudge-nudge-wink-wink interpretation of the WFS
> 2.0 spec that differs from the tabulated default value of startindex
>
> Option 2: Conformance
> - startindex=0 has exactly the same effect as startindex not being specified
> - all WFS 2.0 responses will be sorted, at the cost of performance
> - we are conformant with the default values specified in the WFS 2.0 spec
>
> So, in a nutshell, should all WFS 2.0 responses be sorted?

In a nutshell, no, we need to grow a way to tell if paging was being
asked for or not.
Ideally detect and explicit startIndex=0, less ideally a way to at
least detect if
maxFeatures was explicitly provided (if we don't have that either,
it's definitely
not paging)

Cheers
Andrea


-- 
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:      +39 0584 962313
mob:    +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Performance versus conformance in WFS 2.0 paging

[Ben Caradoc-Davies]

Thanks, Simone. I agree with you in principle, but there are two issues 
that concern me:
(1) cluttering up the configuration with options that make it more 
complicated
(2) adding unexpected surprised for clients, who in any case cannot know 
how a GeoServer instance is configured.

Kind regards,
Ben.

On 16/05/12 13:57, Simone Giannecchini wrote:
> Ciao Ben, my 2 cents,
> IMHO standards are beatiful as long as they are useful (i.e they make like 
> simple or even just simpler). If by supporting a standard strictly we become 
> unnecessarily slow, then we are less useful to users therefore the standard 
> is failing.
>
> This does not mean that we should ignore rules mandated by the standards.My 
> usual suggestion in this kind of cases is to put a flag somewhere in the 
> config to switch between strict/non strict adeherence and go for the non 
> strict by default.
>
> Regards,
> Simone Giannecchini
> ---
> Ing. Simone Giannecchini
> GeoSolutions S.A.S.
> Founder
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:  +39 0584 962313
> mob:+39 333 8128928
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/simonegiannecchini
> http://twitter.com/simogeo
>
> ---
>
>
> On Wed, May 16, 2012 at 6:16 AM, Ben 
> Caradoc-Daviesmailto:ben.caradoc-dav...@csiro.au>>
>   wrote:
> I have encountered a decision point while fixing a bug in WFS 2.0 paging:
> https://jira.codehaus.org/browse/GEOS-5085
>
> WFS 2.0 paging is implemented by specifying startindex and count (like
> maxFeatures in 1.1.0) in a GetFeature request. Our implementation uses
> the presence of startindex to detect whether paging is in use; to ensure
> consistency across pages, results must be sorted when paging is in use.
> However, this has one undesirable implication: our use of startindex is
> at odds with the WFS 2.0 spec, which specifies that startindex defaults
> to zero.
>
> I see two options:
>
> Option 1: Performance
> - the presence of startindex triggers sorting for paging consistency
> - the absence of startindex means that responses can be unsorted for
> greater performance
> - startindex=0 and the absence of startindex are treated differently
> - clients that omit startindex for their first page of paged results
> will get inconsistent pages (was are *assuming* that all paging clients
> set startindex=0 for their first page, despite this being explicitly the
> default in the spec)
> - we will have a surprising nudge-nudge-wink-wink interpretation of the
> WFS 2.0 spec that differs from the tabulated default value of startindex
>
> Option 2: Conformance
> - startindex=0 has exactly the same effect as startindex not being specified
> - all WFS 2.0 responses will be sorted, at the cost of performance
> - we are conformant with the default values specified in the WFS 2.0 spec
>
> So, in a nutshell, should all WFS 2.0 responses be sorted?
>
> Kind regards,
>
> --
> Ben Caradoc-Davies
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>

-- 
Ben Caradoc-Davies 
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Moving code from GeoServer to GeoTools

[Andrea Aime]

On Tue, May 15, 2012 at 11:51 PM, Chris Holmes  wrote:
> For this case in particular, if we want to move faster, I feel comfortable
> approving the porting of all code done by OpenGeo employees on OpenGeo time
> to GeoTools. It looks like Simone also did some of the work, so I'd say if
> he is also comfortable with porting it over then we have approval. Or we can
> ask the PSC.

Which I already did a few days ago collecting, so far, 6 positive votes:
http://osgeo-org.1560.n6.nabble.com/PSC-Motion-allow-porting-portions-of-GetLegendGraphics-back-to-GeoTools-td4974361.html

I guess we can consider it approved?

Cheers
Andrea

-- 
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:      +39 0584 962313
mob:    +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] pegging to a gwc release

[Ben Caradoc-Davies]

+1 from me. This will as a side-effect work around Maven's brokenness 
with snapshots from some repos (gwc is normally the one that bites me).

On 16/05/12 06:29, Gabriel Roldan wrote:
> Hey all,
>
> with gwc / geoserver integration settling down I'd like to adopt the
> policy of always pegging geoserver to a released version of gwc,
> instead of having it as a SNAPSHOT policy.
> In the event that anything needs to change on gwc, it'd be better if
> we create a bug fix release or even a simple tag, but for instance
> would like the geoserver stable branch to be always on a released gwc
> version, although tag/snapshot would be good for trunk.
>
> Opinions? if no objections I'd peg both 2.1.x and trunk to gwc
> 1.3-RC3, which was released last week.
>
> Cheers,
> Gabriel
>

-- 
Ben Caradoc-Davies 
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Performance versus conformance in WFS 2.0 paging

[Simone Giannecchini]

Ciao Ben, my 2 cents,
IMHO standards are beatiful as long as they are useful (i.e they make like
simple or even just simpler). If by supporting a standard strictly we
become unnecessarily slow, then we are less useful to users therefore the
standard is failing.

This does not mean that we should ignore rules mandated by the standards.My
usual suggestion in this kind of cases is to put a flag somewhere in the
config to switch between strict/non strict adeherence and go for the non
strict by default.

Regards,
Simone Giannecchini
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313
mob:+39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

---


On Wed, May 16, 2012 at 6:16 AM, Ben Caradoc-Davies <
ben.caradoc-dav...@csiro.au> wrote:

> I have encountered a decision point while fixing a bug in WFS 2.0 paging:
> https://jira.codehaus.org/browse/GEOS-5085
>
> WFS 2.0 paging is implemented by specifying startindex and count (like
> maxFeatures in 1.1.0) in a GetFeature request. Our implementation uses
> the presence of startindex to detect whether paging is in use; to ensure
> consistency across pages, results must be sorted when paging is in use.
> However, this has one undesirable implication: our use of startindex is
> at odds with the WFS 2.0 spec, which specifies that startindex defaults
> to zero.
>
> I see two options:
>
> Option 1: Performance
> - the presence of startindex triggers sorting for paging consistency
> - the absence of startindex means that responses can be unsorted for
> greater performance
> - startindex=0 and the absence of startindex are treated differently
> - clients that omit startindex for their first page of paged results
> will get inconsistent pages (was are *assuming* that all paging clients
> set startindex=0 for their first page, despite this being explicitly the
> default in the spec)
> - we will have a surprising nudge-nudge-wink-wink interpretation of the
> WFS 2.0 spec that differs from the tabulated default value of startindex
>
> Option 2: Conformance
> - startindex=0 has exactly the same effect as startindex not being
> specified
> - all WFS 2.0 responses will be sorted, at the cost of performance
> - we are conformant with the default values specified in the WFS 2.0 spec
>
> So, in a nutshell, should all WFS 2.0 responses be sorted?
>
> Kind regards,
>
> --
> Ben Caradoc-Davies 
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] pegging to a gwc release

[Andrea Aime]

On Wed, May 16, 2012 at 12:29 AM, Gabriel Roldan  wrote:
> Hey all,
>
> with gwc / geoserver integration settling down I'd like to adopt the
> policy of always pegging geoserver to a released version of gwc,
> instead of having it as a SNAPSHOT policy.
> In the event that anything needs to change on gwc, it'd be better if
> we create a bug fix release or even a simple tag, but for instance
> would like the geoserver stable branch to be always on a released gwc
> version, although tag/snapshot would be good for trunk.
>
> Opinions? if no objections I'd peg both 2.1.x and trunk to gwc
> 1.3-RC3, which was released last week.

+1

Cheers
Andrea

-- 
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:      +39 0584 962313
mob:    +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] status of release scripts

[Justin Deoliveira]

Hi all,

I have been working on the scripts to automate our release process. Here is
where things are at.

First, if you want to take a look at the scripts they are in my github repo
in a branch called "build_scripts":

  https://github.com/jdeolive/geoserver/tree/build_scripts/build

Here is how they work. And I actually haven't setup all the hudson jobs
yet, but the underlying scripts are working. So here is how it will work.

On our main hudson server there is a job called "geoserver-release":

  http://hudson.opengeo.org/hudson/job/geoserver-release/

The job takes the following parameters:

  * branch to release from
  * revision to tag
  * release name

The underlying scripts actually take more parameters but i will get to
those later. When run the above job does the following:

 1. creates the tag from the specified parameters
 2. checks out the tag and preps for release, updating version numbers,
etc...
 3. performs the main release build
 4. assembles artifacts and uploads them to a distribution directory,
currently located here:

 http://gridlock.opengeo.org/geoserver/release/

 5. Fires off two installer jobs (one for windows, one for osx) on remote
hudsons. The two hudsons are currently on our internal network so i can't
provide access to them.
 6. When the installer jobs complete they upload the artifacts to the same
distribution directory specified above.

The end result is all the artifacts wind up in a single directory matching
the release name. For example:

http://gridlock.opengeo.org/geoserver/release/2.2-beta2/

The above list of tasks is an overview, the main release script actually
does a bit more which is what i would like to discuss. The script also
checks jira and determines two things:

 1. is the release actually released on jira
 2. does the release have any open/unresolved issues filed against it

To do so it uses the jira rest api (which is nice btw). This is something I
would like feedback on. We have a couple of options here on what to do with
respect to jira.

 1. don't do any checks against jira, and leave that a manual process
 2. halt the build if the release is not released in jira or there are
unresolved issues, making releasing on a jira manually a precursor to
running the script
 3. mark the release as released in jira, and push back any unresolved
issues to the next version

More options welcome.

The second thing I would like to discuss is how we handle the README.
Currently when we release we update the README on the main branch (and not
the tag). I would kind of like to avoid committing anything to the main
branch in an automated process. For example what happens if we run the
release, it fails and we run it again. We have to check if the readme has
been already updated, etc... While certainly possible with some script mojo
it seems like an error prone process I would like to avoid.

So what I would like to propose is the following. We don't ever update the
README on the main release branch. We leave it generic with information
about the project, where to find the docs, etc... On the tag we create we
would generate a new file called "RELEASE_NOTES.txt" (or something to that
effect) that contains the stuff we usually put in the README like revision
info and the new and noteworthy info for that release. To generate the new
and noteworthy for the release notes i was thinking we could come up with a
heuristic. One such heuristic could be to pull out any new feature or
improvement, and perhaps any issue that is a high priority one. Anyways,
you get the idea. And naturally it would contain the link to the entire
changelog from jira like we do now. Perhaps we should just stick to simple
and put the revision info and the changelog link in the release notes.
Probably what I will do for a first pass if people are into the idea.

Those are the two main things I need input on thus far. Aside from the
above stuff the main thing left to do is to do the upload to sourceforge. I
think this will be pretty straight forward. The idea is that there would be
a second release job (called geoserver-release-publish or something) that
would take the release tag as input and basically just upload all the
artifacts from the distribution directory to sourceforge. The idea is that
after the main release job (and the hudson installer jobs) complete the
person doing the release would do a quick sanity check on the artifacts,
fix issues, etc... Once completed the release publish job would do the
final push.

Oh, and another TODO will be to take the associated geotools info (version,
revision, etc...) and ensure that is what is included in the geoserver
build. I guess same goes for geowebcache as well.

That is it for now. Looking forward to hearing feedback.

-Justin

-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Live Security Virtual Conference
Exclusive li

[Geoserver-devel] Performance versus conformance in WFS 2.0 paging

[Ben Caradoc-Davies]

I have encountered a decision point while fixing a bug in WFS 2.0 paging:
https://jira.codehaus.org/browse/GEOS-5085

WFS 2.0 paging is implemented by specifying startindex and count (like 
maxFeatures in 1.1.0) in a GetFeature request. Our implementation uses 
the presence of startindex to detect whether paging is in use; to ensure 
consistency across pages, results must be sorted when paging is in use. 
However, this has one undesirable implication: our use of startindex is 
at odds with the WFS 2.0 spec, which specifies that startindex defaults 
to zero.

I see two options:

Option 1: Performance
- the presence of startindex triggers sorting for paging consistency
- the absence of startindex means that responses can be unsorted for 
greater performance
- startindex=0 and the absence of startindex are treated differently
- clients that omit startindex for their first page of paged results 
will get inconsistent pages (was are *assuming* that all paging clients 
set startindex=0 for their first page, despite this being explicitly the 
default in the spec)
- we will have a surprising nudge-nudge-wink-wink interpretation of the 
WFS 2.0 spec that differs from the tabulated default value of startindex

Option 2: Conformance
- startindex=0 has exactly the same effect as startindex not being specified
- all WFS 2.0 responses will be sorted, at the cost of performance
- we are conformant with the default values specified in the WFS 2.0 spec

So, in a nutshell, should all WFS 2.0 responses be sorted?

Kind regards,

-- 
Ben Caradoc-Davies 
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] pegging to a gwc release

[Justin Deoliveira]

Sounds good to me.

On Tue, May 15, 2012 at 4:29 PM, Gabriel Roldan  wrote:

> Hey all,
>
> with gwc / geoserver integration settling down I'd like to adopt the
> policy of always pegging geoserver to a released version of gwc,
> instead of having it as a SNAPSHOT policy.
> In the event that anything needs to change on gwc, it'd be better if
> we create a bug fix release or even a simple tag, but for instance
> would like the geoserver stable branch to be always on a released gwc
> version, although tag/snapshot would be good for trunk.
>
> Opinions? if no objections I'd peg both 2.1.x and trunk to gwc
> 1.3-RC3, which was released last week.
>
> Cheers,
> Gabriel
>
> --
> Gabriel Roldan
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> 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.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] pegging to a gwc release

[Gabriel Roldan]

Hey all,

with gwc / geoserver integration settling down I'd like to adopt the
policy of always pegging geoserver to a released version of gwc,
instead of having it as a SNAPSHOT policy.
In the event that anything needs to change on gwc, it'd be better if
we create a bug fix release or even a simple tag, but for instance
would like the geoserver stable branch to be always on a released gwc
version, although tag/snapshot would be good for trunk.

Opinions? if no objections I'd peg both 2.1.x and trunk to gwc
1.3-RC3, which was released last week.

Cheers,
Gabriel

-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Moving code from GeoServer to GeoTools

[Chris Holmes]

Hey, apologies for a bit of a delay on response to this.

So for me TOPP is just the entity that holds copyright, and it's up to the
PSC to decide any changes to that copyright. So I don't think I'd feel
comfortable with any OpenGeo employee saying it's ok, unless it's the
express wish of the PSC.

Now OpenGeo policy has always been to push the code to the lowest level of
libraries as possible, and that any code written for GeoServer is available
for GeoTools if people want to port it. And I feel comfortable giving that
approval to OpenGeo employees, and to anyone else who wants to take OpenGeo
code.

I think the thing to do is have the PSC set a policy on migrating code from
GeoServer to GeoTools. I think it could set some threshold under which
moving code over is pre-approved, and that larger commits should ask the
PSC? I don't think it has to be a ton of red tape, just a GSIP that we
adopt. And then TOPP can reiterate that somehow officially, and not have to
ask every time.

For this case in particular, if we want to move faster, I feel comfortable
approving the porting of all code done by OpenGeo employees on OpenGeo time
to GeoTools. It looks like Simone also did some of the work, so I'd say if
he is also comfortable with porting it over then we have approval. Or we
can ask the PSC.

Chris

On Mon, May 14, 2012 at 3:16 AM, Ben Caradoc-Davies <
ben.caradoc-dav...@csiro.au> wrote:

> On 14/05/12 14:34, Andrea Aime wrote:
>
>> It is my understanding that if you're the sole author of a particular
>> piece of code
>> you retain the right to re-license it without having to get approval from
>> The Open Planning Project (that is, you give TOPP the copyright without
>> losing
>> yours, might be wrong here).
>>
>
> Yes.
>
> GeoServer contributors assign their copyrights to TOPP:
>
> "For good and valuable consideration, receipt of which I acknowledge, I,
> ___,
> hereby transfer to The Open Planning Project ("TOPP") my entire right,
> title, and interest (including all
> rights under copyright) in the program GeoServer (“Program”), including
> original code, accompanying
> documentation and supporting files, changes and enhancements to the
> Program code and accompanying
> files, and all future modifications of the Program code and accompanying
> files, subject to the conditions
> below."
>
> Then TOPP licences it back to you for any purpose:
>
> "TOPP hereby grants me a royalty-free non-exclusive license to use or
> sub-license the Work
> assigned hereunder (i.e., if I am assigning changes and enhancements to
> the Program to TOPP, the license
> granted by TOPP to me is only for those changes and enhancements to the
> Program I assigned, it is not for
> the Program which I changed or enhanced itself) for any purpose. TOPP's
> rights shall otherwise continue
> unchanged."
>
> And so you should be able to sublicence it to OSGeo. I think this is what
> the second quote means. I'm not sure if you can assign your copyright
> again, as you no longer have it. But I am not a lawyer.
>
> My point is that the original author should be able to copy code from
> GeoServer to GeoTools, and TOPP should be able to authorise such copying,
> but in general, other developers cannot. To do so would allow rogue
> developers to sneak out from the clutches of the GPL (imagine some
> committing all of GeoServer into the GeoTools repo so they could claim it
> as LGPL).
>
>
>  Generally speaking we never had an automatic mechanism like you describe
>> though, to put it in place I believe we'd need quite a bit of red tape.
>>
>
> I think it is an issue that should be addressed. If we go to the effort of
> getting contributor agreements, then this issue should be addressed.
>
>
> --
> Ben Caradoc-Davies 
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] 5 years of Brazilian Community GeoServer

[Fernando Quadro]

Justin,

It would be very good a post on the birthday of the GeoServer-BR community.

Best Regards,

Fernando Quadro

2012/5/14 Justin Deoliveira 

> Congratulations Fernando! This is really great!
>
> We should do a blog post on the main geoserver blog to share this with
> everybody.
>
> On Sat, May 12, 2012 at 9:58 PM, Fernando Quadro wrote:
>
>> Hi all,
>>
>> It is with great pleasure that I write this post in celebration of another
>> anniversary of the GeoServer community-BR, for five years after the first
>>  training GeoServerconducted in Brazil (in ENUM III) was initiated this
>> community. Today we are more than 500 subscribers on the mailing list from
>> Yahoo not only in Brazil but severalPortuguese-speaking countries with
>> more than 3200 emails answered.
>>
>> The most important fact during those years was in 2008 when then
>> President Lulasigned the decree and GeoServer was "appointed" the
>> official map server of SDI(National Spatial Data Infrastructure) .
>>
>> Best Regards,
>>
>> Fernando Quadro
>>
>> http://www.fernandoquadro.com.br/html/2012/05/13/5-anos-de-geoserver-br/
>>
>>
>> --
>>
>> Fernando Quadro
>> http://www.fernandoquadro.com.br
>> twitter.com/fernandoquadro
>>
>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> 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.
>
>


-- 

Fernando Quadro
http://www.fernandoquadro.com.br
twitter.com/fernandoquadro
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [jira] (GEOS-5119) (Backport to 2.1.x) Allow KML Document Title to be set by format_options parameters

[Alessio Fabiani (JIRA)]

Alessio Fabiani created GEOS-5119:
-

 Summary: (Backport to 2.1.x) Allow KML Document Title to be set by 
format_options parameters
 Key: GEOS-5119
 URL: https://jira.codehaus.org/browse/GEOS-5119
 Project: GeoServer
  Issue Type: Improvement
Reporter: Alessio Fabiani
Assignee: Alessio Fabiani
 Attachments: kml_formatOptions_gs21x.patch

Beckporting the GEOS-5110 to GS 2.1.x branch

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [jira] (GEOS-5118) WMS animator reflector path not recognized by the dispatcher when running on standalone Jetty container

[Alessio Fabiani (JIRA)]

Alessio Fabiani created GEOS-5118:
-

 Summary: WMS animator reflector path not recognized by the 
dispatcher when running on standalone Jetty container
 Key: GEOS-5118
 URL: https://jira.codehaus.org/browse/GEOS-5118
 Project: GeoServer
  Issue Type: Bug
Affects Versions: 2.2-beta1
Reporter: Alessio Fabiani
Assignee: Alessio Fabiani




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [jira] (GEOS-5117) OpenLayers preview won't switch to an alternate style anymore

[Andrea Aime (JIRA)]

Andrea Aime created GEOS-5117:
-

 Summary: OpenLayers preview won't switch to an alternate style 
anymore
 Key: GEOS-5117
 URL: https://jira.codehaus.org/browse/GEOS-5117
 Project: GeoServer
  Issue Type: Bug
  Components: WMS
Affects Versions: 2.1.3
Reporter: Andrea Aime
Assignee: Andrea Aime
 Fix For: 2.1.4


A setStyle javascript method is missing

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Proposal for reorganizing Working With Data section in the User Guide

[Alessio Fabiani]

The doc structure looks nice, much more clear. Thanks.

Regards,
Alessio.

---
Ing. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: (+39) 0584 96.23.13
fax: (+39) 0584 96.23.13
mobile:(+39) 331 62.33.686

http://www.geo-solutions.it
http://geo-solutions.blogspot.com
http://www.linkedin.com/in/alessiofabiani
https://twitter.com/alfa7961
http://twitter.com/geosolutions_it
---



On Tue, May 15, 2012 at 2:24 AM, Martin Davis  wrote:

> Further to this task, I've prototyped the new directory structure and TOC
> of the User Guide, with the new Data sections.  The HTML of the TOC is
> attached for review of the structure and URL naming.
>
> This is a fairly major reorganization, and I've tried to strike a balance
> between creating a structure that reflects the actual content organization,
> and minimizing the impact on the directory structure.  In particular,
> - the app-schema content tree is not changed
> - this seem to required continuing to have a Working With Data section.
>  This isn't a bad thing - it is a good location to put general content on
> data
> - otherwise, content pages are now moved to new directories under the data
> directory.  Each has its own index.rst file.  This is also a good thing,
> since the index pages can now be tailored more appropriately to the type of
> content.
>
> If this looks good, I will start implementing the structure in SVN.  Since
> it will take some time, I'm planning to stage it over multiple commits.
>
> On Wed, May 2, 2012 at 9:33 AM, Martin Davis  wrote:
>
>> Ok, great.  I'll work on this as I have time.
>>
>>
>> On Tue, May 1, 2012 at 5:35 AM, Andrea Aime > > wrote:
>>
>>> On Tue, May 1, 2012 at 8:44 AM, Chris Holmes wrote:
>>>
 +1 on the reorg in general, and on cascaded services.

>>>
>>> +1 here too
>>>
>>>
>>> --
>> Martin Davis
>> OpenGeo - http://opengeo.org
>> Expert service straight from the developers.
>>
>>
>
>
> --
> Martin Davis
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel