Hi, I am trying to render tiles in 8 bit palette format Though the colors are not coming out correctly.
Please provide tips if any Thanks Yash -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Wednesday, December 09, 2009 4:07 AM To: [email protected] Subject: Geoserver-devel Digest, Vol 43, Issue 12 Send Geoserver-devel mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/geoserver-devel or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Geoserver-devel digest..." Today's Topics: 1. Re: Proposal to implement limited virtual services (Justin Deoliveira) 2. Re: Proposed Schedule for Release for 2.0.1 (Andrea Aime) 3. [jira] Created: (GEOS-3704) WMS + featureid filter + multiple layer -> exception (Andrea Aime (JIRA)) 4. [jira] Created: (GEOS-3705) java.lang.RuntimeException on TIF import (Sebastian Benthall (JIRA)) 5. [jira] Created: (GEOS-3706) Directory of Raster files as a data store (Sebastian Benthall (JIRA)) 6. [jira] Created: (GEOS-3707) GeoServerLoader will fail with NPE if the "styles" subdirectory is missing (Andrea Aime (JIRA)) 7. Re: Proposal to implement limited virtual services (Rob Atkinson) 8. [jira] Created: (GEOS-3708) Strange URL validation in Shapefile importer (Sebastian Benthall (JIRA)) ---------------------------------------------------------------------- Message: 1 Date: Tue, 08 Dec 2009 08:30:42 -0500 From: Justin Deoliveira <[email protected]> Subject: Re: [Geoserver-devel] Proposal to implement limited virtual services To: Jody Garnett <[email protected]> Cc: Geoserver-devel <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Jody Garnett wrote: > Hi Justin: > >> Recently OpenGeo has received funding to implement the idea of virtual >> services in a limited form. The basic idea is to provide service >> endpoints for each workspace so you can make requests like: >> >> http://.../geoserver/topp/wfs?request=.... > > So "topp" is the name of the service being offered in the above request. One question is the following valid. > > http://.../geoserver/topp?Request=GetCapabilities&Service=WFS&Version=1. 1..... > > I am trying to see if the service really is "topp" and the service supports one or more protocols... Yes, that is the idea. Of course at the moment we don't have the ability to turn off any of the services (aside from security). > >> Basically what we currently do with workspace filters as a query >> parameter with some additions. The full GSIP is written up here: >> >> http://geoserver.org/display/GEOS/GSIP+44+-+Virtual+services+with+worksp aces >> >> One thing to note is how this plays with resource publishing split since >> there is some overlap in this functionality and what resource pub split >> will provide. I wrote up some notes at the end of the proposal on this. >> But the gist of it is that the upgrade path should be quite smooth. > > Thanks Justin it is a well written proposal; the only section I had trouble with was the security implications. It is unclear if the approach you are advocating here is a change to the default security subsystem; or just an approach to use how to handle security at a future point in time? If it is a change for right now could you provide an example snippet of how to configure what you are describing? The security implications are that if you plan to use a specific workspace endpoint, do not expect to be able to access layers from other workspaces. There will be zero configuration required. > >> Actually this work fills one of the gaps that was shot in the resource >> pub proposal by Jody in that it did not explicitly specify the ability >> to specify a map in a url path as opposed to specifying it in the query >> string. > > Thanks I picked up - and think the URL will be much more stable in this respect. Agreed, looks much nicer. > >> Comments and feedback welcome. > > One assumption and a question > > I assume this work needs to be made available in the stable 2.0.x series. > WIth that in mind what is your deadline for this work, and does the deadline include the functionality being issued as part of a release. Yes, I will need this work to take place on the stable branch. As for when to release the date can be flexible. Since 2.0.1 is coming soon (or so i hear ;)) I would think targeting 2.0.2 would make most sense. > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------ Message: 2 Date: Tue, 08 Dec 2009 10:11:35 -0500 From: Andrea Aime <[email protected]> Subject: Re: [Geoserver-devel] Proposed Schedule for Release for 2.0.1 To: Mark Leslie <[email protected]> Cc: Geoserver-devel <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mark Leslie wrote: > I would like to propose a release of 2.0.1 as my Christmas gift to all > of you. This would require a week of testing to commence on the 14th of > December, with me tagging the release on the 21st. Due to overlapping > commitments, I expect the release to actually be released a few days > later, but to be out by the 25th. Hey, thanks for stepping up. I think it would be very good, we already have 80 jira issues closed that were scheduled for 2.0.1: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery= project+%3D+GEOS+AND+fixVersion+%3D+%222.0.1%22+AND+status+in+%28Resolve d%2C+Closed%29 We also have a good number of new features, just listing what comes to mind we have point and polygon labelling improvements, much improved sql server and mysql NG datastores, dateline wrapping easter egg, geometry transformations. On the other side we have a number of blocker and critical issues to solve, but I hear that Justin started to work on them: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery= project+%3D+GEOS+AND+fixVersion+%3D+%222.0.1%22+AND+status+%3D+Open+ORDE R+BY+priority+DESC%2C+key+DESC So I guess we might be good? Opinions? Cheers Andrea ------------------------------ Message: 3 Date: Tue, 8 Dec 2009 09:41:55 -0600 (CST) From: "Andrea Aime (JIRA)" <[email protected]> Subject: [Geoserver-devel] [jira] Created: (GEOS-3704) WMS + featureid filter + multiple layer -> exception To: [email protected] Message-ID: <11353899.29837.1260286915161.javamail.haus-j...@codehaus01.managed.cont egix.com> Content-Type: text/plain; charset=ISO-8859-1 WMS + featureid filter + multiple layer -> exception ---------------------------------------------------- Key: GEOS-3704 URL: http://jira.codehaus.org/browse/GEOS-3704 Project: GeoServer Issue Type: Bug Reporter: Andrea Aime Assignee: Andrea Aime Fix For: 2.0.1 This happens because the featureid filter is not propagated to all layers -- 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 ------------------------------ Message: 4 Date: Tue, 8 Dec 2009 11:22:55 -0600 (CST) From: "Sebastian Benthall (JIRA)" <[email protected]> Subject: [Geoserver-devel] [jira] Created: (GEOS-3705) java.lang.RuntimeException on TIF import To: [email protected] Message-ID: <2883615.29942.1260292975195.javamail.haus-j...@codehaus01.managed.conte gix.com> Content-Type: text/plain; charset=ISO-8859-1 java.lang.RuntimeException on TIF import ---------------------------------------- Key: GEOS-3705 URL: http://jira.codehaus.org/browse/GEOS-3705 Project: GeoServer Issue Type: Bug Affects Versions: 2.0.x Reporter: Sebastian Benthall Assignee: Andrea Aime Attachments: logs.txt, PtoQ_M7_2_MiProyecto_Tr1000.tif When attempting to add a new Store from a GeoTIFF file, I get the following error in the web UI: {{Could not list layers for this store, an error occurred retrieving them: null}} Attached is the offending file and the stack trace from the GeoServer logs. Expected behavior: successful loading of the file as a new Store and the listing of the layers within it, or else an error message informing me what is wrong with the file. -- 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 ------------------------------ Message: 5 Date: Tue, 8 Dec 2009 11:30:55 -0600 (CST) From: "Sebastian Benthall (JIRA)" <[email protected]> Subject: [Geoserver-devel] [jira] Created: (GEOS-3706) Directory of Raster files as a data store To: [email protected] Message-ID: <9915813.29946.1260293455260.javamail.haus-j...@codehaus01.managed.conte gix.com> Content-Type: text/plain; charset=ISO-8859-1 Directory of Raster files as a data store ----------------------------------------- Key: GEOS-3706 URL: http://jira.codehaus.org/browse/GEOS-3706 Project: GeoServer Issue Type: New Feature Reporter: Sebastian Benthall Assignee: Andrea Aime A client would like us to configure GeoServer with a lot of raster data in GeoTIFF format. The data comes in directories; each directory has several files that cover the same kind of data (e.g. earthquake risk exposure) but varying by some parameter (e.g. the time period from which the data was sampled.) When adding all these files to the GeoServer configuration from the web UI, I currently have to make a new Store for each of these layers, even though the paths and configuration are almost identical. A major workflow improvement would be to allow the user to add a "directory of raster files" to GeoServer as a Store, and then configure each of the individual layers from the list of layers. That would save me a ton of copying, pasting, and clicking. -- 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 ------------------------------ Message: 6 Date: Tue, 8 Dec 2009 12:44:55 -0600 (CST) From: "Andrea Aime (JIRA)" <[email protected]> Subject: [Geoserver-devel] [jira] Created: (GEOS-3707) GeoServerLoader will fail with NPE if the "styles" subdirectory is missing To: [email protected] Message-ID: <15622441.29991.1260297895313.javamail.haus-j...@codehaus01.managed.cont egix.com> Content-Type: text/plain; charset=ISO-8859-1 GeoServerLoader will fail with NPE if the "styles" subdirectory is missing ------------------------------------------------------------------------ -- Key: GEOS-3707 URL: http://jira.codehaus.org/browse/GEOS-3707 Project: GeoServer Issue Type: Bug Components: Configuration Reporter: Andrea Aime Assignee: Justin Deoliveira Fix For: 2.0.1 Following up a report from the users list I noticed the GeoServerLoader code will fail with an NPE if pointed to a data dir that does not have a styles subdirectory. There is code such as: {code} File styles = resourceLoader.find( "styles" ); for ( File sf : list(styles,new SuffixFileFilter(".xml") ) ) { {code} which is not guarded against the possibility the dir is not there. Wondering if the proper fix would be to use findOrCreate or just add a guard. -- 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 ------------------------------ Message: 7 Date: Wed, 9 Dec 2009 06:34:14 +1100 From: Rob Atkinson <[email protected]> Subject: Re: [Geoserver-devel] Proposal to implement limited virtual services To: Justin Deoliveira <[email protected]> Cc: Geoserver-devel <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=ISO-8859-1 cool - just wanted to put the idea forward early to make sure its considered. Perhaps a note to that effect in the GSIP? On Wed, Dec 9, 2009 at 12:35 AM, Justin Deoliveira <[email protected]> wrote: > > > Rob Atkinson wrote: >> >> I notice you talk about workspaces in one sentence then "a map" in >> another sentence. ?My understanding is that workspaces are bound to >> default namespaces (app-schema will get you out of that, but I've yet >> to get my head around whether workspaces just become an impedence >> overhead, or whether they effectively get bound to differend back-end >> operational systems). > > Yes, at this point in time a workspace == namespace, and we don't really > have the notion of a map. When resource publishing split comes workspace > will not be bound to a namespace. A namspace will simply be an attribute of > a layer and not a container for layers. They will exist and be manged > independently. >> >> A "map" has a completely different set of semantics. >> >> I see no particular reason a namespace or back-end operational system >> is necessarily the only way of splitting up the geoserver services - >> you are building a very inflexible solution IMHO. I would like to have >> virtual services where you can put any resource the service should >> offer, not just those defined by a namespace (either a made-up one or >> an app-schema). >> > Yeah, so do I. And while I am at it I would also like to win the lottery > tomorrow. We are at a middle ground. What you are asking for is coming when > the full blown resource publishing split occurs. But this is an intermediate > step. > >> Can we not have a first-class concept of a service, and then map one >> or more workspaces to it as a convenience mechanism? >> >> I'd also like a single workspace to be available via multiple virtual >> services to different audiences (simple, complete, and transactional >> for example). >> >> i.e. the mix of functionality for a single workspace is as valid a >> reason for virtualisation as partitioning the set of resources across >> workspaces. >> >> Rob >> >> On Tue, Dec 8, 2009 at 4:48 AM, Justin Deoliveira <[email protected]> >> wrote: >>> >>> Hi all, >>> >>> Recently OpenGeo has received funding to implement the idea of virtual >>> services in a limited form. The basic idea is to provide service >>> endpoints for each workspace so you can make requests like: >>> >>> http://.../geoserver/topp/wfs?request=.... >>> >>> Basically what we currently do with workspace filters as a query >>> parameter with some additions. The full GSIP is written up here: >>> >>> >>> http://geoserver.org/display/GEOS/GSIP+44+-+Virtual+services+with+worksp aces >>> >>> One thing to note is how this plays with resource publishing split since >>> there is some overlap in this functionality and what resource pub split >>> will provide. I wrote up some notes at the end of the proposal on this. >>> But the gist of it is that the upgrade path should be quite smooth. >>> >>> Actually this work fills one of the gaps that was shot in the resource >>> pub proposal by Jody in that it did not explicitly specify the ability >>> to specify a map in a url path as opposed to specifying it in the query >>> string. >>> >>> Comments and feedback welcome. >>> >>> -Justin >>> >>> -- >>> Justin Deoliveira >>> OpenGeo - http://opengeo.org >>> Enterprise support for open source geospatial. >>> >>> >>> ------------------------------------------------------------------------ ------ >>> Join us December 9, 2009 for the Red Hat Virtual Experience, >>> a free event focused on virtualization and cloud computing. >>> Attend in-depth sessions from your desk. Your couch. Anywhere. >>> http://p.sf.net/sfu/redhat-sfdev2dev >>> _______________________________________________ >>> Geoserver-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > ------------------------------ Message: 8 Date: Tue, 8 Dec 2009 16:36:55 -0600 (CST) From: "Sebastian Benthall (JIRA)" <[email protected]> Subject: [Geoserver-devel] [jira] Created: (GEOS-3708) Strange URL validation in Shapefile importer To: [email protected] Message-ID: <25084116.30110.1260311815233.javamail.haus-j...@codehaus01.managed.cont egix.com> Content-Type: text/plain; charset=ISO-8859-1 Strange URL validation in Shapefile importer -------------------------------------------- Key: GEOS-3708 URL: http://jira.codehaus.org/browse/GEOS-3708 Project: GeoServer Issue Type: Bug Affects Versions: 2.0.x Reporter: Sebastian Benthall Assignee: Andrea Aime Attachments: PQUEPOS_Escenario_190.dbf, PQUEPOS_Escenario_190.shp, PQUEPOS_Escenario_190.shx With a certain shapefile (attached) given a certain path in the Shapefile Store creation workflow, the URL field's validator seems to append an extra "file://" before the URL I enter, and then reports an error. Logs show a stack trace (also attached). The original input to the URL field is: {{file:data/Ejemplo_Puerto_Quepos-CRI/Esc190/PQUEPOS_Escenario_190.shp}} That input is changed to the following when I click "Save": {{file://file:data/Ejemplo_Puerto_Quepos-CRI/Esc190/PQUEPOS_Escenario_19 0.shp}} The error reported in the page UI is: {{Error creating data store, check the parameters. Error message: Shapefile not found:file:/file:data/Ejemplo_Puerto_Quepos-CRI/Esc190/PQUEPOS_Escenario _190.shp}} Expected behavior: The data store should be created from the Shapefile. If the Shapefile is invalid, then I should get an error (hopefully an informative one about what's wrong with the Shapefile), but in this case the URL field should not change. -- 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 ------------------------------ ------------------------------------------------------------------------ ------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ------------------------------ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel End of Geoserver-devel Digest, Vol 43, Issue 12 *********************************************** Please help Logica to respect the environment by not printing this email / Pour contribuer comme Logica au respect de l'environnement, merci de ne pas imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei, die Umwelt zu schützen. / Por favor ajude a Logica a respeitar o ambiente nao imprimindo este correio electronico. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
