[Geoserver-devel] Build failed in Hudson: geoserver-1.7.x #422
See http://hudson.opengeo.org/hudson/job/geoserver-1.7.x/422/changes -- [...truncated 2016 lines...] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) 04 Dec 07:49:10 ERROR [geoserver.ows] - org.geoserver.wfs.WFSException: Unknown namespace [youdontknowme] at org.geoserver.wfs.kvp.QNameKvpParser.parseToken(QNameKvpParser.java:54) at org.geoserver.ows.FlatKvpParser.parse(FlatKvpParser.java:76) at org.geoserver.ows.util.KvpUtils.parse(KvpUtils.java:471) at org.geoserver.ows.Dispatcher.parseKVP(Dispatcher.java:1049) at org.geoserver.ows.Dispatcher.init(Dispatcher.java:245) at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:191) at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153) at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875) at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571) at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.geoserver.test.GeoServerAbstractTestSupport.dispatch(GeoServerAbstractTestSupport.java:957) at org.geoserver.test.GeoServerAbstractTestSupport.dispatch(GeoServerAbstractTestSupport.java:924) at org.geoserver.test.GeoServerAbstractTestSupport.getAsServletResponse(GeoServerAbstractTestSupport.java:443) at org.geoserver.test.GeoServerAbstractTestSupport.get(GeoServerAbstractTestSupport.java:424) at org.geoserver.test.GeoServerAbstractTestSupport.getAsDOM(GeoServerAbstractTestSupport.java:656) at org.geoserver.test.GeoServerAbstractTestSupport.getAsDOM(GeoServerAbstractTestSupport.java:637) at org.geoserver.wfs.GetFeatureTest.testAlienNamespace(GetFeatureTest.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at org.geoserver.test.GeoServerAbstractTestSupport.runTest(GeoServerAbstractTestSupport.java:125) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:25) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache
[Geoserver-devel] Build failed in Hudson: geoserver-1.7.x #421
See http://hudson.opengeo.org/hudson/job/geoserver-1.7.x/421/changes Changes: [jdeolive] null check in encodeFormatOptions() [jdeolive] reducing log level of message stating no default regionating strategy set -- [...truncated 2017 lines...] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) 04 Dec 06:42:00 ERROR [geoserver.ows] - org.geoserver.wfs.WFSException: Unknown namespace [youdontknowme] at org.geoserver.wfs.kvp.QNameKvpParser.parseToken(QNameKvpParser.java:54) at org.geoserver.ows.FlatKvpParser.parse(FlatKvpParser.java:76) at org.geoserver.ows.util.KvpUtils.parse(KvpUtils.java:471) at org.geoserver.ows.Dispatcher.parseKVP(Dispatcher.java:1049) at org.geoserver.ows.Dispatcher.init(Dispatcher.java:245) at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:191) at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153) at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875) at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571) at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.geoserver.test.GeoServerAbstractTestSupport.dispatch(GeoServerAbstractTestSupport.java:957) at org.geoserver.test.GeoServerAbstractTestSupport.dispatch(GeoServerAbstractTestSupport.java:924) at org.geoserver.test.GeoServerAbstractTestSupport.getAsServletResponse(GeoServerAbstractTestSupport.java:443) at org.geoserver.test.GeoServerAbstractTestSupport.get(GeoServerAbstractTestSupport.java:424) at org.geoserver.test.GeoServerAbstractTestSupport.getAsDOM(GeoServerAbstractTestSupport.java:656) at org.geoserver.test.GeoServerAbstractTestSupport.getAsDOM(GeoServerAbstractTestSupport.java:637) at org.geoserver.wfs.GetFeatureTest.testAlienNamespace(GetFeatureTest.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at org.geoserver.test.GeoServerAbstractTestSupport.runTest(GeoServerAbstractTestSupport.java:125) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:25) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingM
[Geoserver-devel] [jira] Created: (GEOS-2475) KML reflector fails to return proper GroundOverlay with raster layer in flat mode
KML reflector fails to return proper GroundOverlay with raster layer in flat mode - Key: GEOS-2475 URL: http://jira.codehaus.org/browse/GEOS-2475 Project: GeoServer Issue Type: Bug Components: Google Earth KML Output Reporter: Justin Deoliveira Assignee: David Winslow Fix For: 1.7.1 http://localhost:8080/geoserver/wms/kml?layers=nurc:Img_Sample&mode=flat results in: nurc:Img_Sample 0 http://localhost:8080/geoserver/wms? format_options=KMPLACEMARK:false;KMATTR:true;SUPEROVERLAY:false;& service=wms& srs=EPSG:4326& width=256& styles=raster& height=256& transparent=false& bbox=-131.5401427998,2.298047200134,-61.31693720005,72.5212527998& request=GetMap& layers=nurc:Img_Sample& format=application/vnd.google-earth.kml+xml& version=1.1.1 There are two issues: 1) the format should be an image format and 2) the image should be transparent -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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
[Geoserver-devel] [jira] Created: (GEOS-2474) Merge KMATTR and KMPLACEMARK
Merge KMATTR and KMPLACEMARK Key: GEOS-2474 URL: http://jira.codehaus.org/browse/GEOS-2474 Project: GeoServer Issue Type: Improvement Affects Versions: 1.7.0 Reporter: Mike Pumphrey Assignee: David Winslow Priority: Minor Fix For: 1.7.1 KMATTR (true/false) determines if the pop-up description is displayed when a vector feature is clicked on. KMPLACEMARK (true/false) determines if the pop-up description is displayed when a raster feature is clicked on. Is there really a need for both of these? Given context (reflector mode, etc.) can't we combine these into one attribute, say, KMPOPUP? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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
Re: [Geoserver-devel] css for confluence
When do you plan to reboot the server Mike? Mike Pumphrey wrote: > I agree that the headings aren't very differentiable. However, I'm > personally not a big fan of the colored backgrounds or horizontal rules. > I much much prefer the headings to be differentiated by size of font > (and perhaps color). I don't feel terribly strongly about this though, > just trying to keep the pages looking clean. > > But since it looks like commits were already done, never mind. :) > > Thanks, > Mike Pumphrey > OpenGeo - http://opengeo.org > > > Justin Deoliveira wrote: >> OK, i will try again :). >> >> I find the confluence headings h2, h3, h4, etc... do not differentiate >> themselves enough. I found the old headings styles much easier to follow. >> >> I think this could be easily solved by giving h2. heading a background >> and h3. a horizontal rule. Or vice versa, which ever works. >> >> Mike Pumphrey wrote: >>> I normally bother Chris Patterson for questions of this nature. :) >>> >>> Thanks, >>> Mike Pumphrey >>> OpenGeo - http://opengeo.org >>> >>> >>> Justin Deoliveira wrote: Hi all, I sent a message about headings in confluence being hard to differentiate with the current styles but not no response. How can i get to the css for the wiki. I would like to make some minor modifications. Thanks, -Justin >> >> -- 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
Re: [Geoserver-devel] css for confluence
I agree that the headings aren't very differentiable. However, I'm personally not a big fan of the colored backgrounds or horizontal rules. I much much prefer the headings to be differentiated by size of font (and perhaps color). I don't feel terribly strongly about this though, just trying to keep the pages looking clean. But since it looks like commits were already done, never mind. :) Thanks, Mike Pumphrey OpenGeo - http://opengeo.org Justin Deoliveira wrote: > OK, i will try again :). > > I find the confluence headings h2, h3, h4, etc... do not differentiate > themselves enough. I found the old headings styles much easier to follow. > > I think this could be easily solved by giving h2. heading a background > and h3. a horizontal rule. Or vice versa, which ever works. > > Mike Pumphrey wrote: >> I normally bother Chris Patterson for questions of this nature. :) >> >> Thanks, >> Mike Pumphrey >> OpenGeo - http://opengeo.org >> >> >> Justin Deoliveira wrote: >>> Hi all, >>> >>> I sent a message about headings in confluence being hard to >>> differentiate with the current styles but not no response. How can i >>> get to the css for the wiki. I would like to make some minor >>> modifications. >>> >>> Thanks, >>> >>> -Justin >>> >>> > > - 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
[Geoserver-devel] [jira] Created: (GEOS-2473) Fix up default formats returned by reflector
Fix up default formats returned by reflector Key: GEOS-2473 URL: http://jira.codehaus.org/browse/GEOS-2473 Project: GeoServer Issue Type: Bug Reporter: David Winslow Assignee: David Winslow Fix For: 1.7.1 flat should get kml everything else should get kmz. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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
[Geoserver-devel] Making abstracts in release data do work for us
Once the REST layer page is out, people will be looking at metadata more. In particular, people will likely look at the default release data more. This opens up the necessity of making that metadata more compelling and also the opportunity to make it work for GeoServer--by talking about what the software can be used for, or pointing out particular features, or just catching the eye of somebody who stumbles upon an exposed layer page and wonders, "what is this?" Here's an example: http://atlas.openplans.org:8080/geosearch/rest/topp/states.html If this seems like a good idea to others, I'd be happy to write some blurbs for the other release data. Thanks, Sebastian Benthall OpenGeo - http://opengeo.org - 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
Re: [Geoserver-devel] css for confluence
OK, i will try again :). I find the confluence headings h2, h3, h4, etc... do not differentiate themselves enough. I found the old headings styles much easier to follow. I think this could be easily solved by giving h2. heading a background and h3. a horizontal rule. Or vice versa, which ever works. Mike Pumphrey wrote: > I normally bother Chris Patterson for questions of this nature. :) > > Thanks, > Mike Pumphrey > OpenGeo - http://opengeo.org > > > Justin Deoliveira wrote: >> Hi all, >> >> I sent a message about headings in confluence being hard to >> differentiate with the current styles but not no response. How can i >> get to the css for the wiki. I would like to make some minor >> modifications. >> >> Thanks, >> >> -Justin >> >> -- 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
[Geoserver-devel] css for confluence
Hi all, I sent a message about headings in confluence being hard to differentiate with the current styles but not no response. How can i get to the css for the wiki. I would like to make some minor modifications. Thanks, -Justin -- 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
[Geoserver-devel] [jira] Created: (GEOS-2472) superoverlays do not work on raster layers without specifying mode=raster
superoverlays do not work on raster layers without specifying mode=raster - Key: GEOS-2472 URL: http://jira.codehaus.org/browse/GEOS-2472 Project: GeoServer Issue Type: Bug Reporter: Justin Deoliveira Assignee: David Winslow Fix For: 1.7.1 http://localhost:8080/geoserver/wms/kml?layers=nurc:Img_Sample fails but http://localhost:8080/geoserver/wms/kml?layers=nurc:Img_Sample&mode=raster works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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
[Geoserver-devel] [jira] Created: (GEOS-2471) Support namespace filter WMS getCapabilities
Support namespace filter WMS getCapabilities Key: GEOS-2471 URL: http://jira.codehaus.org/browse/GEOS-2471 Project: GeoServer Issue Type: New Feature Reporter: Francesco Izzi Assignee: Andrea Aime Fix For: 1.7.2 it would be great to have the filter that return wms capabilities only of single namespace for examples http://localhost:8080/geoserver/ows?service=WMS&request=GetCapabilities&namespace=topp -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - 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
[Geoserver-devel] Scheduling 1.7.2 new features
Hi, following yesterday discussion during the GeoServer IRC meeting I've been looking into Jira for "New Feature", "Improvement" or "Task" issues that are scheduled for 1.7.2. Actually yesterdays we talked only about "New Feature", but since the issue type has not been used consistently in the past, I thought to expand a bit the search: http://jira.codehaus.org/sr/jira.issueviews:searchrequest-printable/temp/SearchRequest.html?fixfor=14681&type=4&type=2&type=3&type=5&pid=10311&resolution=-1&sorter/field=priority&sorter/order=DESC&tempMax=1000 Wow, there are 53. It's not like these are the real new features scheduled for 1.7.2, as being there is more of a side effect of having been scheduled by someone for some 1.6.x or 1.7.x release and have been moved forward ever since. So ok, the idea of the roadmap was to present a few compelling new features making up the theme of a release. Here is what I would like to see in 1.7.2 (but I have no funding for those atm, thought I could pour some of my personal time into some of these during the holidays should OpenGeo decide not to sponsor these directly): * http://jira.codehaus.org/browse/GEOS-2288 Directory datastore. This is an old issue actually, we looked into integrating that datastore in the past already (1.5.x something). The thin is that the datastore as it stands is not usable, but a rewrite is easy and I have some ideas coming togheter already. * http://jira.codehaus.org/browse/GEOS-665 From the "I love low effort big gain" department, here is one that would multiply WFS output format count by 10 at the least and there is also a patch that could be used as a started * http://jira.codehaus.org/browse/GEOS-2296 This one is from "pain in the axe" ;-) department, I keep on hearing people asking for ECW support, and Frank at FOSS4G suggested a way out, but it requires rebuilding all of the GDAL native parts so that ECW is turned into a plugin. I guess this one would need some GeoSolutions work, so take it just as a Christmas wish, would you? :) * http://jira.codehaus.org/browse/GEOS-2433 This is almost done, so why not? * http://jira.codehaus.org/browse/GEOS-1783 This one I already coded, but requires a small change in the (sigh) unmantained refererencing subsystem. A small gift to all italian people getting crazy because GeoServer reprojects data 100m away only because it's using the Sardinia ellipsoid parameters whilst most of the data of course resides somewhere else * http://jira.codehaus.org/browse/GEOS-2386 This one I have already in progress as well, and it's a nice new one for people with huge data sets and a need to serve them with WFS Well, that's sort of my personal wish list out of those 53 issues (and as I said, I can probably sponsor personally one or two or these, the others need OpenGeo/someone else's get go) Anybody else? 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
Re: [Geoserver-devel] state of release [was] Re: sorry for missing IRC, here are my thoughts
I like the work Justin has done on the Roadmap process, I think our core interest will lie with the transition to the 2.0 series, when Ben gets back we'll confer and try to provide details. Timing is still fairly challenging to predict. So, you have a default +0 from me to pragmatic inclusions of features in 1.7 releases, assuming these need to be discussed among the affected stakeholders. but I do look forward to a better process! Rob A On Wed, Dec 3, 2008 at 3:08 AM, Chris Holmes <[EMAIL PROTECTED]> wrote: > > > Ok, so this discussion, though it's lead to quite good discussions and > directions, has thrown us (OpenGeo) a fairly big curve ball. Which is > our fault, as the KML stuff we are working on is still being improved at > the last moment - we are normally more ahead of the game. > > In the future I hope we can come up with a process that makes it so this > doesn't happen, with more future planning and understanding. But I'd > also like to see easier mechanisms to move quickly when needed, the time > spent on all these conversations has slowed us down considerably. They > obviously needed to happen, and we should have prepped more, but so it > goes. And right now it's still not clear how we could move forward as > quickly as we'd need to. > > So right now we're probably going to back down from our really big PR > release, as time is just getting too tight to feel really good about the > release. We hope to do one in a month or so, when we get some external > sites crawled by GeoSearch, talking about how this data is now on the > GeoWeb. > > But we will do some sort of release announcement, hopefully emphasizing > the KML Super Overlays. But right now we're unsure what to do about the > GeoSearch stuff. Right now it'd probably be more work to code the > appropriate extension points, since there needs to be switches in the > core KML code to activate it or not. So we could do that. Or we can > put together the GSIP in the next day or two to get it passed. Or else > get an exception to have the GSIP in place for 1.7.2, what we were > originally hoping for, but it sounds like Jody wants to require a GSIP. > Which we are happy to do now, as it's no longer going to be a focus. > > So that we don't fall in to inaction, if no one says anything we will go > forth with a GSIP, which we'd need a vote finalized for by the end of > the week. If anyone is going to have objections to the GSIP do let us > know as soon as possible. Just wanted to give a heads up with where we > are at in the release process, and to see if anyone had thoughts. We'll > be aiming to announce the release on December 9, and would really like > to have it built with people on the lists testing in the next few days. > > Chris > > Jody Garnett wrote: >>> 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 >> >> - >> 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. > > > -- > Chris Holmes > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > - > This SF.Net email is sponsored by the Moblin Your Move Deve
