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: geoserver-devel-request@lists.sourceforge.net
[mailto:geoserver-devel-request@lists.sourceforge.net]
Sent: Wednesday, December 09, 2009 4:07 AM
To: geoserver-devel@lists.sourceforge.net
Subject: Geoserver-devel Digest, Vol 43, Issue 12
Send Geoserver-devel mailing list submissions to
geoserver-devel@lists.sourceforge.net
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
geoserver-devel-request@lists.sourceforge.net
You can reach the person managing the list at
geoserver-devel-owner@lists.sourceforge.net
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 <jdeolive@anonymised.com>
Subject: Re: [Geoserver-devel] Proposal to implement limited virtual
services
To: Jody Garnett <jody.garnett@anonymised.com>
Cc: Geoserver-devel <geoserver-devel@lists.sourceforge.net>
Message-ID: <4B1E5502.3010305@anonymised.com>
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 <aaime@anonymised.com>
Subject: Re: [Geoserver-devel] Proposed Schedule for Release for 2.0.1
To: Mark Leslie <mark.leslie@anonymised.com>
Cc: Geoserver-devel <geoserver-devel@lists.sourceforge.net>
Message-ID: <4B1E6CA7.9040408@anonymised.com>
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)" <jira@anonymised.com>
Subject: [Geoserver-devel] [jira] Created: (GEOS-3704) WMS + featureid
filter + multiple layer -> exception
To: geoserver-devel@lists.sourceforge.net
Message-ID:
<11353899.29837.1260286915161.JavaMail.haus-jira@anonymised.com
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)" <jira@anonymised.com>
Subject: [Geoserver-devel] [jira] Created: (GEOS-3705)
java.lang.RuntimeException on TIF import
To: geoserver-devel@lists.sourceforge.net
Message-ID:
<2883615.29942.1260292975195.JavaMail.haus-jira@anonymised.com
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)" <jira@anonymised.com>
Subject: [Geoserver-devel] [jira] Created: (GEOS-3706) Directory of
Raster files as a data store
To: geoserver-devel@lists.sourceforge.net
Message-ID:
<9915813.29946.1260293455260.JavaMail.haus-jira@anonymised.com
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)" <jira@anonymised.com>
Subject: [Geoserver-devel] [jira] Created: (GEOS-3707) GeoServerLoader
will fail with NPE if the "styles" subdirectory is missing
To: geoserver-devel@lists.sourceforge.net
Message-ID:
<15622441.29991.1260297895313.JavaMail.haus-jira@anonymised.com
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 <robatkinson101@anonymised.com>
Subject: Re: [Geoserver-devel] Proposal to implement limited virtual
services
To: Justin Deoliveira <jdeolive@anonymised.com>
Cc: Geoserver-devel <geoserver-devel@lists.sourceforge.net>
Message-ID:
<870f30290912081134v5c0fad6dsc9c3344caeed343d@anonymised.com>
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
<jdeolive@anonymised.com> 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
<jdeolive@anonymised.com>
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
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.
------------------------------
Message: 8
Date: Tue, 8 Dec 2009 16:36:55 -0600 (CST)
From: "Sebastian Benthall (JIRA)" <jira@anonymised.com>
Subject: [Geoserver-devel] [jira] Created: (GEOS-3708) Strange URL
validation in Shapefile importer
To: geoserver-devel@lists.sourceforge.net
Message-ID:
<25084116.30110.1260311815233.JavaMail.haus-jira@anonymised.com
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
Geoserver-devel@lists.sourceforge.net
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.