[Geoserver-devel] [jira] Created: (GEOS-2724) Support construction of XSD schema type from complex feature type

[Ben Caradoc-Davies (JIRA)]

Support construction of XSD schema type from complex feature type
-

 Key: GEOS-2724
 URL: http://jira.codehaus.org/browse/GEOS-2724
 Project: GeoServer
  Issue Type: Improvement
  Components: WFS
Reporter: Ben Caradoc-Davies
Assignee: Andrea Aime




-- 
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



--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] BoundingBoxes for all SRS?

[Jody Garnett]

We could also fix the GeoTools parsing; if you have a specific capabilities
document we could use to write a test case it would be good.
Jody

On Wed, Mar 11, 2009 at 2:50 AM, Per Engström  wrote:

> Hello list.
> I've been working on GeoWebCache (GWC) for some time now and I've just come
> across a bit of a problem when caching layers with multiple projections
> (SRS:s). The problem occurs when the Capabillities document only specifies a
> BoundingBox for one SRS and not one BoundingBox for each SRS. This is ok
> according to OGC:s WMS spec 1.1.1:
> "A server which has the ability to transform data to different SRSes 
> *may*choose not to
> provide an explicit BoundingBox for every possible SRS available for each
> Layer.  The
> server *should* provide BoundingBox information for at least the native
> SRS of the Layer."
>
> As I understand this is the default behaviour of GeoServer.
>
> However, GeoTools (GWC utilizes GeoTools for parsing the Capabilities
> document) is not able to recognize SRS:s that does not have a specified
> BoundingBox, thus GWC is unable to recognize and cache the layer in those
> projections.
>
> My question is:
> Is there a way to force GeoServer to provide a BoundingBox for all SRS:s
> provided?
>
> Regards,
> Per Engström
>
>
>
> --
>
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Summer of Code 2009

[Jody Garnett]

I saw Summer of Code 2009 ideas mentioned a couple IRC meetings ago ... it
looks like the doors are open and OSGeo sorting out their application. Their
wiki currently links to this page from 2008:-
http://geoserver.org/display/GEOS/Summer+of+Code+2008

Jody
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] FOSS4G 2009 Call for Presentation Abstracts

[Jody Garnett]

The Organising Committee would like to welcome all interested
participants to submit abstracts for presentations for the Free and Open
Source Software for Geospatial conference (FOSS4G), being held in
Sydney, Australia October 20-23. FOSS4G offers participants an
opportunity to learn from and share your knowledge, experience and ideas
with a group of like minded individuals representing a wide array of
industries, governments, technologies and nationalities.

Presentations are open to all those interested and will comprise a 30
minute slot which includes hand-over, introductions and 5 minutes for
questions. Presentations will be selected which have a strong "Open
Geospatial" theme to them. The committee is looking for a mixture of
technical and non-technical presentations.


In deference to the conference theme of “User Driven,” topics of
particular interest are:

* Case Studies: Share your experiences implementing and using open
  source geospatial. What problems were you attempting to solve? How
  successful were you and at what cost? What can others learn from
  your experience?
* Business Case: Have you had to sell the Open Source concept within
  your organisation? How did you present the concept to management?
  How did you present the cost/benefit scenarios and build the
  business case? What hurdles did you encounter and how did you
  surmount them?
* Collaboration: Have you faced the trials of collaboration between
  organisations, remote offices or team members scattered to the far
  corners of the globe? What steps have you taken to improve the
  efficiency of your collaboration: open or de facto standards,
  decentralised data collection, or the myriad of solutions that
  only you could describe?
* Security: Securing you data while ensuring ease of access to those
  select few within your inner circle can be a daunting task. Share
  you successes, and your failures, with others facing their own
  security issues.
* Developments: Have you created a shiny new widget that is about to
  change the world? Or has your time-honoured project finally
  completed a much requested feature or two? Bring us up to date
  with the new developments in your open source geospatial software
  products with all the latest buzz: what does it do, how are people
  using it and what is in store for the next year.

For more information, visit the FOSS4G site
at http://2009.foss4g.org/presentations/

The deadline for presentation submissions is June 1st 2009. See you in
Sydney.


FOSS4G 2009 Highlights

*The Climate Challenge Integration Plugfest (CCIP)*: FOSS4G will launch
the OGC's Climate Challenge Integration Plugfest (CCIP), which
demonstrates standards based interoperability between Open Source and
Proprietary geospatial applications. It consists of a server with
multiple virtual machines, each installed with geospatial applications
offering standards based web services. All web services will demonstrate
a common dataset, and will be accessed by a range of geospatial client
applications installed on client
computers.http://external.opengis.org/twiki_public/bin/view/ClimateChallenge2009/WebHome

Presenters are encouraged (but not mandated) to make use of scenarios
and on-site data from the Climate Challenge Integration Plugfest (CCIP).
This is especially important as demand for access to data over the
internet is expected to be high, and Australia has notoriously slow
connections to the outside world.

*FOSS4G Live DVD*: LiveDVDs, based on the Xubuntu operating system and
including Geospatial Open Source Software, will be given to all
delegates. Users can boot a Live DVD on their computer and trial the
software without installing or effecting the existing
system.http://wiki.osgeo.org/wiki/Live_GIS_Disc

*Installfest*: The Installfest will give delegates the opportunity to
meet in a common area and install a wide variety of FOSS software on
their laptops, EE PC or any other system they care to bring in.
Community members will be around to assist with any troubles and provide
help and insight into the software. The install fest will take place
after workshops on the first day.

*Workshops and Tutorials*: Workshops and Tutorials allow presenters to
lead attendees through applications, integration solutions, or other
topics in an interactive environment. Half-day workshops (3 hours) will
be held in computer rooms on the first day. Tutorials (90 minutes) will
be held in standard presentation rooms, run concurrently with
presentations during the third and fourth days.

*Presentations*: The meat of the conference are it's presentations.
Drawing on a huge community of local, regional and international experts
we will discuss some of the most current and poignant topics in the
industry today.

*Demo Theatre*: During lunch and coffee breaks the demonstration theatre
will be showcasing live software. These short demonstrati

[Geoserver-devel] KMLVectorTransformerTest

[David Winslow]

hey all,

in trying to add a test to my patch for
http://jira.codehaus.org/browse/GEOS-2670, I noticed that
KMLVectorTransformerTest is disabled; (it builds a mockdata that always
returns false for isOnline(), so it never gets run.)

Can someone shed some light on why this is the case?

--
David Winslow
OpenGeo - http://opengeo.org/


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Build failed in Hudson: geoserver-trunk #819

[Hudson]

See http://hudson.opengeo.org/hudson/job/geoserver-trunk/819/changes

Changes:

[jdeolive] set svn:ignore

--
[...truncated 44 lines...]
svn: Cannot read from to 
'http://hudson.opengeo.org/hudson/job/geoserver-trunk/ws/geoserver/externals/.svn/format'
 : path refers to directory or read access is denied
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:49)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.open(SVNAdminAreaFactory.java:132)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.doOpen(SVNWCAccess.java:344)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:261)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.probeOpen(SVNWCAccess.java:279)
at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:1881)
at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:1818)
at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2172)
at 
hudson.scm.SubversionSCM$BuildRevisionMapTask.invoke(SubversionSCM.java:631)
at 
hudson.scm.SubversionSCM$BuildRevisionMapTask.invoke(SubversionSCM.java:601)
at hudson.FilePath.act(FilePath.java:301)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:308)
at hudson.model.AbstractProject.checkout(AbstractProject.java:558)
at 
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:215)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:181)
at hudson.model.Run.run(Run.java:659)
at hudson.model.Build.run(Build.java:101)
at hudson.model.ResourceController.execute(ResourceController.java:70)
at hudson.model.Executor.run(Executor.java:65)
ERROR: Failed to parse svn info for external 
http://svn.openlayers.org/sandbox/topp/styler2 at geoserver/externals/openlayers
org.tmatesoft.svn.core.SVNException: svn: 
'http://hudson.opengeo.org/hudson/job/geoserver-trunk/ws/geoserver/externals'  
is not a working copy
svn: Cannot read from to 
'http://hudson.opengeo.org/hudson/job/geoserver-trunk/ws/geoserver/externals/.svn/format'
 : path refers to directory or read access is denied
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:49)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.open(SVNAdminAreaFactory.java:132)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.doOpen(SVNWCAccess.java:344)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:261)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.probeOpen(SVNWCAccess.java:279)
at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:1881)
at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:1818)
at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2172)
at 
hudson.scm.SubversionSCM$BuildRevisionMapTask.invoke(SubversionSCM.java:631)
at 
hudson.scm.SubversionSCM$BuildRevisionMapTask.invoke(SubversionSCM.java:601)
at hudson.FilePath.act(FilePath.java:301)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:308)
at hudson.model.AbstractProject.checkout(AbstractProject.java:558)
at 
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:215)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:181)
at hudson.model.Run.run(Run.java:659)
at hudson.model.Build.run(Build.java:101)
at hudson.model.ResourceController.execute(ResourceController.java:70)
at hudson.model.Executor.run(Executor.java:65)
ERROR: Failed to parse svn info for external 
http://svn.opengeo.org/who/ems/trunk/lib at geoserver/externals/tree
org.tmatesoft.svn.core.SVNException: svn: 
'http://hudson.opengeo.org/hudson/job/geoserver-trunk/ws/geoserver/externals'  
is not a working copy
svn: Cannot read from to 
'http://hudson.opengeo.org/hudson/job/geoserver-trunk/ws/geoserver/externals/.svn/format'
 : path refers to directory or read access is denied
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:49)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNAdminAreaFactory.open(SVNAdminAreaFactory.java:132)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.doOpen(SVNWCAccess.java:344)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:261)
at 
org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.probeOpen(SVNWCAccess.java:279)
at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:1881)
at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:1818)
at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2172)
at 
hudson.scm.SubversionSCM$BuildRevisionMapTask.invoke(SubversionSC

Re: [Geoserver-devel] merging data and main into single module

[Justin Deoliveira]

Just a quick note that i have gone ahead with the move. So long data module.

Justin Deoliveira wrote:
> Hi all,
> 
> I was wondering if anyone had any objections to merging the data and 
> main modules on trunk into a single module. Basically having main absorb 
> data.
> 
> My use case is the mock testing stuff, currently it can't see anything 
> in main which is causing problems. I propose the merge b/c a) it solves 
> my problem and b) I think the merge makes sense for a couple of reasons:
> 
> 1) data has all the mock test setup, but all the test support classes 
> are in main, there is no practical reason for the separation
> 
> 2) setting up test dependencies for mock tests is currently a pain b/c 
> modules have to declare both dependencies (test scope dependencies are 
> not transitive)
> 
> 3) data only has a few utility for data access in it, it does not really 
> warrant a separate module imho.
> 
> Thoughts? Objections?
> 
> -Justin
> 


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

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Wicket UI design breaking meeting logs

[Andrea Aime]

Christopher Patterson ha scritto:
> Following up:
> 
> Ext has pretty robust theming options, so I think that it'll be 
> reasonable to shoot for an Ext theme which aligns with our Geoserver 
> look & feel. I haven't found anything as simple as jQuery's themeroller 
> though - so if anyone knows of an equivalent I'd love to hear about it.
> 
> So, I think that our plan of action is probably to have someone (most 
> likely me, unless there are other volunteers) figure out how to create 
> an Ext theme which complements the GeoServer 2 interface.
> 
> I have some work for Orton coming down the pike, and will be at SXSW 
> this coming week, but can add this into my queue if folks think that's 
> the best path forward. (also: should I open a JIRA to track this work?)

Sounds good to me. Thought, I'd like to hear Styler/GeoExt people
opinion on the subject too (see previous mails folks :-) )

Cheers
Andrea

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

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Wicket UI design breaking meeting logs

[Christopher Patterson]

Following up:

Ext has pretty robust theming options, so I think that it'll be  
reasonable to shoot for an Ext theme which aligns with our Geoserver  
look & feel. I haven't found anything as simple as jQuery's  
themeroller though - so if anyone knows of an equivalent I'd love to  
hear about it.

So, I think that our plan of action is probably to have someone (most  
likely me, unless there are other volunteers) figure out how to create  
an Ext theme which complements the GeoServer 2 interface.

I have some work for Orton coming down the pike, and will be at SXSW  
this coming week, but can add this into my queue if folks think that's  
the best path forward. (also: should I open a JIRA to track this work?)

Chris


On Mar 10, 2009, at 1:10 PM, Arne Kepp wrote:

> The Ext look reminds me a lot about Office 2003*, with a little  
> "Windows
> XP Media Edition" shading added. I think it was a neat trick to make
> people realize AJAX applications can replace traditional desktop
> applications ("They look the same, therefore they must be equal").
>
> But I don't think Ext has a look that is worth pursuing, we'll look  
> like
> 2003 in 2010. Better to go with whatever wicket can give us easily,  
> and
> tone down Ext. I don't know how easy that is either, but JQuery has  
> some
> pretty fancy stuff** coming up, Ext must offer some features in this
> department too.
>
> -Arne
>
>
> *: http://www.winsupersite.com/images/reviews/office2003_beta2_02.gif
> **: http://jqueryui.com/themeroller/ , try changing things in the menu
> on the left hand side
>
> Andrea Aime wrote:
>> Hi all,
>> today we had a breakout meeting on #geoserver to discuss how to
>> move forward with the new UI, in terms of styles and functionality.
>> The participants to the meeting were all looking at a running  
>> GeoServer
>> with the new UI (which was running on my PC, so sorry, not available
>> for the world to see now).
>>
>> The two core topics were:
>> - mixing wicket and extjs ui elements, how to deal with the obviuos
>>   look and feel inconsistency? (think the styler integration, but
>>   also the incoming geoext based layer preview)
>>
>>   The takeout from this is that we have two options
>>   * we can redo the GeoServer css to look
>> like extjs components, but that might be difficult, and we had a
>> GSIP about branding and some time after that a designer redid the
>> GeoServer UI to use colors and fonts mandated by that GSIP,
>> so, do we still have to follow that GSIP?
>> And, how do other poeple feel about an GeoServer UI that looks
>> like a set of exjts widgets? (sample here:
>> http://extjswordpress.net/)
>>   * we restyle the extjs UI to look like the new GeoServer UI  
>> instead,
>> that is, white background, blue titles, and so on.
>> We don't know how hard that would be, and would this be welcomed?
>>
>>   Of course a third option is possible, that is, to have the two
>>   look different, but there was a decent consensus that it might
>>   not have been the best way to go (feel free to say otherwise,
>>   we're discussing this).
>>
>> - second topic is a review of how the catalog tree UI is going to
>>   be replaced with a pageable, sortable, filterable table based
>>   pages, one for workspaces, one for stores and one for layers.
>>   The topic goes on discussing how to increase connectinos between
>>   the various pages, provide handy views for users, and how to
>>   handle mass deletes
>>
>> Feedback welcomed
>> Cheers
>> Andrea
>>
> 
>
>
> -- 
> Arne Kepp
> OpenGeo - http://opengeo.org
> Expert service straight from the developers
>
>
> --
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [jira] Created: (GEOS-2723) replace "raster" and "vector" with icons in layer table

[Justin Deoliveira (JIRA)]

replace "raster" and "vector" with icons in layer table
---

 Key: GEOS-2723
 URL: http://jira.codehaus.org/browse/GEOS-2723
 Project: GeoServer
  Issue Type: Improvement
Reporter: Justin Deoliveira
Assignee: Andrea Aime
 Fix For: 2.0.x




-- 
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



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

[Geoserver-devel] [jira] Created: (GEOS-2722) Layer group editor

[Justin Deoliveira (JIRA)]

Layer group editor
--

 Key: GEOS-2722
 URL: http://jira.codehaus.org/browse/GEOS-2722
 Project: GeoServer
  Issue Type: Improvement
Reporter: Justin Deoliveira
Assignee: Andrea Aime
 Fix For: 2.0.x


A nice editor which allows the user to define layer groups by choosing from 
lists of styles and layers, rather than typing them into a text box.

-- 
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



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

[Geoserver-devel] BoundingBoxes for all SRS?

[Per Engström]

Hello list.

I've been working on GeoWebCache (GWC) for some time now and I've just  
come across a bit of a problem when caching layers with multiple  
projections (SRS:s). The problem occurs when the Capabillities  
document only specifies a BoundingBox for one SRS and not one  
BoundingBox for each SRS. This is ok according to OGC:s WMS spec 1.1.1:
"A server which has the ability to transform data to different SRSes  
may choose not to
provide an explicit BoundingBox for every possible SRS available for  
each Layer.  The
server should provide BoundingBox information for at least the native  
SRS of the Layer."


As I understand this is the default behaviour of GeoServer.

However, GeoTools (GWC utilizes GeoTools for parsing the Capabilities  
document) is not able to recognize SRS:s that does not have a  
specified BoundingBox, thus GWC is unable to recognize and cache the  
layer in those projections.


My question is:
Is there a way to force GeoServer to provide a BoundingBox for all  
SRS:s provided?


Regards,
Per Engström

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

Re: [Geoserver-devel] Wicket UI design breaking meeting logs

[Arne Kepp]

The Ext look reminds me a lot about Office 2003*, with a little "Windows 
XP Media Edition" shading added. I think it was a neat trick to make 
people realize AJAX applications can replace traditional desktop 
applications ("They look the same, therefore they must be equal").

But I don't think Ext has a look that is worth pursuing, we'll look like 
2003 in 2010. Better to go with whatever wicket can give us easily, and 
tone down Ext. I don't know how easy that is either, but JQuery has some 
pretty fancy stuff** coming up, Ext must offer some features in this 
department too.

-Arne


*: http://www.winsupersite.com/images/reviews/office2003_beta2_02.gif
**: http://jqueryui.com/themeroller/ , try changing things in the menu 
on the left hand side

Andrea Aime wrote:
> Hi all,
> today we had a breakout meeting on #geoserver to discuss how to
> move forward with the new UI, in terms of styles and functionality.
> The participants to the meeting were all looking at a running GeoServer
> with the new UI (which was running on my PC, so sorry, not available
> for the world to see now).
>
> The two core topics were:
> - mixing wicket and extjs ui elements, how to deal with the obviuos
>look and feel inconsistency? (think the styler integration, but
>also the incoming geoext based layer preview)
>
>The takeout from this is that we have two options
>* we can redo the GeoServer css to look
>  like extjs components, but that might be difficult, and we had a
>  GSIP about branding and some time after that a designer redid the
>  GeoServer UI to use colors and fonts mandated by that GSIP,
>  so, do we still have to follow that GSIP?
>  And, how do other poeple feel about an GeoServer UI that looks
>  like a set of exjts widgets? (sample here:
>  http://extjswordpress.net/)
>* we restyle the extjs UI to look like the new GeoServer UI instead,
>  that is, white background, blue titles, and so on.
>  We don't know how hard that would be, and would this be welcomed?
>
>Of course a third option is possible, that is, to have the two
>look different, but there was a decent consensus that it might
>not have been the best way to go (feel free to say otherwise,
>we're discussing this).
>
> - second topic is a review of how the catalog tree UI is going to
>be replaced with a pageable, sortable, filterable table based
>pages, one for workspaces, one for stores and one for layers.
>The topic goes on discussing how to increase connectinos between
>the various pages, provide handy views for users, and how to
>handle mass deletes
>
> Feedback welcomed
> Cheers
> Andrea
>   



-- 
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers


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

[Geoserver-devel] [jira] Created: (GEOS-2721) Layer Group Configuration

[Justin Deoliveira (JIRA)]

Layer Group Configuration
-

 Key: GEOS-2721
 URL: http://jira.codehaus.org/browse/GEOS-2721
 Project: GeoServer
  Issue Type: Sub-task
Reporter: Justin Deoliveira
Assignee: Justin Deoliveira




-- 
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



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

[Geoserver-devel] [jira] Created: (GEOS-2720) Security UI: manager users and rights in the web UI

[Andrea Aime (JIRA)]

Security UI: manager users and rights in the web UI
---

 Key: GEOS-2720
 URL: http://jira.codehaus.org/browse/GEOS-2720
 Project: GeoServer
  Issue Type: New Feature
  Components: Wicket UI
Reporter: Andrea Aime
Assignee: Andrea Aime




-- 
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



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

[Geoserver-devel] [jira] Created: (GEOS-2719) Allow configuration of multiple layers in a single action

[Andrea Aime (JIRA)]

Allow configuration of multiple layers in a single action
-

 Key: GEOS-2719
 URL: http://jira.codehaus.org/browse/GEOS-2719
 Project: GeoServer
  Issue Type: Improvement
Reporter: Andrea Aime
Assignee: Andrea Aime
 Fix For: 1.7.4


>From a user at FOSS4G 2008: I have 100 shapefiles in a directory, how do I 
>configure them quickly?

I guess, by filtering the ones the user wants to configure, eventually specify 
an ovverride bbox and srs, and have geoserver make a best guess at everything 
else

-- 
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



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

Re: [Geoserver-devel] Wicket UI design breaking meeting logs

[Andrea Aime]

For the record, the subject was meant to be
"Wicket UI design _breakout_ meeting logs".

Dammit, some days the spell checker is just not enough...

Cheers
Andrea

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

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

[Geoserver-devel] [jira] Created: (GEOS-2718) Add icons to show on which column the table is corrently sorted, and in which direction

[Andrea Aime (JIRA)]

Add icons to show on which column the table is corrently sorted, and in which 
direction
---

 Key: GEOS-2718
 URL: http://jira.codehaus.org/browse/GEOS-2718
 Project: GeoServer
  Issue Type: Improvement
  Components: Wicket UI
Reporter: Andrea Aime
Assignee: Andrea Aime




-- 
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



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

[Geoserver-devel] [jira] Created: (GEOS-2717) Use icons for raster/vector layers and for store types.

[Andrea Aime (JIRA)]

Use icons for raster/vector layers and for store types.
---

 Key: GEOS-2717
 URL: http://jira.codehaus.org/browse/GEOS-2717
 Project: GeoServer
  Issue Type: Improvement
  Components: Wicket UI
Reporter: Andrea Aime
Assignee: Andrea Aime
 Fix For: 2.0.x


Atm the tables are using plain text

-- 
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



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

[Geoserver-devel] [jira] Created: (GEOS-2715) Provide a list of stores in the workspace editor

[Andrea Aime (JIRA)]

Provide a list of stores in the workspace editor


 Key: GEOS-2715
 URL: http://jira.codehaus.org/browse/GEOS-2715
 Project: GeoServer
  Issue Type: Improvement
Reporter: Andrea Aime
Assignee: Andrea Aime
 Fix For: 2.0-alpha1


Should be part of a separate tab, and have pretty much the same functionality 
as the stores page, but pre-filtered on a single workspace

-- 
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



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

[Geoserver-devel] [jira] Created: (GEOS-2716) Add back links in the store/layer pages

[Andrea Aime (JIRA)]

Add back links in the store/layer pages
---

 Key: GEOS-2716
 URL: http://jira.codehaus.org/browse/GEOS-2716
 Project: GeoServer
  Issue Type: Improvement
  Components: Wicket UI
Reporter: Andrea Aime
Assignee: Andrea Aime


Link back to the owning workspace and store

-- 
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



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

[Geoserver-devel] [jira] Created: (GEOS-2714) Provide a list of configured layers and unconfigured layers in the datastore edit page

[Andrea Aime (JIRA)]

Provide a list of configured layers and unconfigured layers in the datastore 
edit page
--

 Key: GEOS-2714
 URL: http://jira.codehaus.org/browse/GEOS-2714
 Project: GeoServer
  Issue Type: Improvement
Reporter: Andrea Aime
Assignee: Andrea Aime
 Fix For: 1.7.4


One tab for the configured layers, one tab for the unconfigured ones, as a 
convenience. 
Should be available only when the datastore is fully configured, not when 
adding it.
The unconfigured one should behave pretty much like the layers page "add new 
layer" drop down, whilst the configured layers should pretty much behave like 
the "layers" page, but pre-filtered on the current store, without the add drop 
down, and maybe without the workspace and store columns, which should be 
obvious ones in this context

-- 
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



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

[Geoserver-devel] [jira] Created: (GEOS-2713) Add a separate bulk delete page to the workspaces/stores/layers pages

[Andrea Aime (JIRA)]

Add a separate bulk delete page to the workspaces/stores/layers pages
-

 Key: GEOS-2713
 URL: http://jira.codehaus.org/browse/GEOS-2713
 Project: GeoServer
  Issue Type: Improvement
Affects Versions: 1.7.3
Reporter: Andrea Aime
Assignee: Andrea Aime
 Fix For: 1.7.4


The page would be linked form a "batch delete" link. It would contain the same 
layers that the main page shows (same filters), with no links in labels, and 
with a checkbox on the side, pre-checked, to confirm delete.
The user would be able to unckeck a few items if he wants to, then press a 
button to actually batch delete the selection. A confirmation dialog is in 
order, especially for stores and workspaces, to show how many stores and layers 
the opeartion would remove. (either that, or have the UI show multiple tables 
with the whole predicted set of to be deleted items)

-- 
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



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

[Geoserver-devel] [jira] Created: (GEOS-2712) Let people configure simple mosaic transparently from the UI

[Simone Giannecchini (JIRA)]

Let people configure simple mosaic transparently from the UI


 Key: GEOS-2712
 URL: http://jira.codehaus.org/browse/GEOS-2712
 Project: GeoServer
  Issue Type: New Feature
Affects Versions: 2.0-alpha1, 1.7.3
Reporter: Simone Giannecchini
Assignee: Simone Giannecchini
Priority: Minor
 Fix For: 1.7.4, 2.0.x


Let people configure simple mosaic transparently from the UI without having to 
create any property 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



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

Re: [Geoserver-devel] Access to NVARCHAR2 fields in Oracle

[Andrea Aime]

Bernhard Kiselka ha scritto:
> Hello,
> 
> I would like to use the value of a field specified as NVARCHAR2 in my 
> Oracle database within my sld.
> I can't access the value, because I do not see this field in the field 
> list of the feature type.
> 
> Could you please implement the Oracle field type NVARCHAR2?

This has already been done, you need to use GeoServer 1.7.3 and
the oracle-ng datastore.

Btw, please ask your questions on the users list, this ml is for
developers to talk each other, not for users to report problems
or ask new features.

Cheers
Andrea

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

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

[Geoserver-devel] Access to NVARCHAR2 fields in Oracle

[Bernhard Kiselka]

Hello,

I would like to use the value of a field specified as NVARCHAR2 in my 
Oracle database within my sld.
I can't access the value, because I do not see this field in the field 
list of the feature type.

Could you please implement the Oracle field type NVARCHAR2?

Thanks a lot,
Bernhard

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

[Geoserver-devel] Wicket UI design breaking meeting logs

[Andrea Aime]

Hi all,
today we had a breakout meeting on #geoserver to discuss how to
move forward with the new UI, in terms of styles and functionality.
The participants to the meeting were all looking at a running GeoServer
with the new UI (which was running on my PC, so sorry, not available
for the world to see now).

The two core topics were:
- mixing wicket and extjs ui elements, how to deal with the obviuos
   look and feel inconsistency? (think the styler integration, but
   also the incoming geoext based layer preview)

   The takeout from this is that we have two options
   * we can redo the GeoServer css to look
 like extjs components, but that might be difficult, and we had a
 GSIP about branding and some time after that a designer redid the
 GeoServer UI to use colors and fonts mandated by that GSIP,
 so, do we still have to follow that GSIP?
 And, how do other poeple feel about an GeoServer UI that looks
 like a set of exjts widgets? (sample here:
 http://extjswordpress.net/)
   * we restyle the extjs UI to look like the new GeoServer UI instead,
 that is, white background, blue titles, and so on.
 We don't know how hard that would be, and would this be welcomed?

   Of course a third option is possible, that is, to have the two
   look different, but there was a decent consensus that it might
   not have been the best way to go (feel free to say otherwise,
   we're discussing this).

- second topic is a review of how the catalog tree UI is going to
   be replaced with a pageable, sortable, filterable table based
   pages, one for workspaces, one for stores and one for layers.
   The topic goes on discussing how to increase connectinos between
   the various pages, provide handy views for users, and how to
   handle mass deletes

Feedback welcomed
Cheers
Andrea

--
aaime: Ok, so to sum up, tenzochris is going to revamp the whole css one 
more time?
tenzochris: and I think (from my taskload) that converting this to look 
more like Styler is the biggest single task
jdeolive: would be easier to go the other way?
tenzochris: jdeolive: how so?
jdeolive: it seems to me like css is something easier changed in ext, 
rather than wicket
jdeolive: but i am just guessing on that
tenzochris: jdeolive: that's an interesting question. I haven't played 
with Ext at all, so don't know what that setup is like
tenzochris: there's probably an argument to be made that it'd be easier 
to match styler (which is heavily Ext), by using Ext
tenzochris: I don't know what the implications are in terms of wicket 
plus (or versus) Ext for any of this, though
jdeolive: no problem, i am open to either
aaime: there is no integration between the two, we'd have to grab a 
javascript dev and make him redo the whole ui
aaime: (in pure javascript + rest)
aaime: I'm against this idea, but it's just me, if the GeoServer PSC 
thinks it's better to redo it in javascript, so be it
jdeolive: tenzochris: yeah, we more or less decided that "integration" 
would be just popping up a new page to run the javascript in
jdeolive: since integration is a pretty big pain
tenzochris: aaime: so it's sounding like a binary decision
jdeolive: aaime: noone is even putting that up for consideration :(
aaime: alterantives would be to have some ext components integrated in a 
wicket page, but on that field, everything is to be developed from 
scratch afaik
aaime: thought it's possible, there are existing jquery and dojo based 
components in wicket as far as I know
jdeolive: and i managed to mock up an ext based one
jdeolive: but it was painful painful painful
jdeolive: and very basic
aaime: so having a wicket CSS that looks like extjs would indeed ease up 
the future integration of extjs snipppets within a wicket based page
***jdeolive still thinks an ext css that looks like wicket would make 
more sense at this point... and would ease aaime's hesitation to have 
geoserver look like ext
jdeolive: i have seen ext demos that chagne teh style sheet and make the 
app look completely differnet
jdeolive: i just think it has been better designed to allow for 
customizabilty than wicket
jdeolive: i could be wrong
tenzochris: okay, so in terms of next steps, is this something the PSC 
needs to discuss?
jdeolive: apologies for harping on this point
jdeolive: i will shut up now
aaime: Just take my UI hesitation as a personal feeling, I'm ok to have 
the ui look like wicket, I just won't like it
tenzochris: or is the goal for me to come up with CSS for wicket which 
matches the Ext work over on styler
pramsey [n=pram...@63.250.104.229] è entrato nella stanza.
aaime: (tyo have the ui look like extjs, that is)
aaime: tenzochris, afaik, another complete revamp should be matter of 
some discussion on the ml at least
jdeolive: tenzochris: i was say the latter, and would prefer that we 
make styler look like wicket, or come up with some common middle ground 
between the two
aaime: giv

[Geoserver-devel] BoundingBoxes for all SRS?

[Per Engström]

Hello list.

I've been working on GeoWebCache (GWC) for some time now and I've just  
come across a bit of a problem when caching layers with multiple  
projections (SRS:s). The problem occurs when the Capabillities  
document only specifies a BoundingBox for one SRS and not one  
BoundingBox for each SRS. This is ok according to OGC:s WMS spec 1.1.1:
"A server which has the ability to transform data to different SRSes  
may choose not to
provide an explicit BoundingBox for every possible SRS available for  
each Layer.  The
server should provide BoundingBox information for at least the native  
SRS of the Layer."


As I understand this is the default behaviour of GeoServer.

However, GeoTools (GWC utilizes GeoTools for parsing the Capabilities  
document) is not able to recognize SRS:s that does not have a  
specified BoundingBox, thus GWC is unable to recognize and cache the  
layer in those projections.


My question is:
Is there a way to force GeoServer to provide a BoundingBox for all  
SRS:s provided?


Regards,
Per Engström


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

[Geoserver-devel] [jira] Created: (GEOS-2711) New data directory and persistence structure

[Justin Deoliveira (JIRA)]

New data directory and persistence structure


 Key: GEOS-2711
 URL: http://jira.codehaus.org/browse/GEOS-2711
 Project: GeoServer
  Issue Type: Task
  Components: Configuration
Affects Versions: 2.0-alpha1
Reporter: Justin Deoliveira
Assignee: Justin Deoliveira
Priority: Critical
 Fix For: 2.0-beta1


Moving away from the DTO / persisting every thing at once model means we need a 
different on disk / data directory format.

-- 
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



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

[Geoserver-devel] [jira] Reopened: (GEOS-2144) Map Preview Page

[Justin Deoliveira (JIRA)]

 [ 
http://jira.codehaus.org/browse/GEOS-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Deoliveira reopened GEOS-2144:
-


> Map Preview Page
> 
>
> Key: GEOS-2144
> URL: http://jira.codehaus.org/browse/GEOS-2144
> Project: GeoServer
>  Issue Type: Sub-task
>  Components: Wicket UI
>Affects Versions: 2.0-alpha1
>Reporter: Gabriel Roldán
>Assignee: Andrea Aime
> Fix For: 2.0.x
>
>
> The map preview page shows the list of available WMS layers and allows to 
> open up a simple map in the available output formats
> - (/) shows only enabled layers
> - (/) shows the available output formats for the map preview per layer
> - uses human friendly names for the output formats

-- 
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

   

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

[Geoserver-devel] [jira] Created: (GEOS-2710) ScaleDenominators in KML

[David Winslow (JIRA)]

ScaleDenominators in KML


 Key: GEOS-2710
 URL: http://jira.codehaus.org/browse/GEOS-2710
 Project: GeoServer
  Issue Type: Bug
  Components: Google Earth KML Output
Affects Versions: 1.7.3
Reporter: David Winslow
Assignee: David Winslow
Priority: Minor


Look into using region-based rendering (a la regionated superoverlays) to 
produce scale-dependent KML output.

-- 
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



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

Re: [Geoserver-devel] Help required in Build Geoserver using Maven

[Justin Deoliveira]

Hi Ravi,

(could you please keep mail on the public list so others can learn from 
the experience as well)

Unfortunately you are hitting trunk when it is in a volatile state. We 
just had a code sprint a few weekends ago, and part of what we did move 
the web module to a folder called "legacy".

To pick it up we use what is called a "mvn profile". Basically any time 
you want do a maven command, you need the switch -P legacy to include 
the old web module.

We are also avtively working on a new web module to take its place, 
named web2, it lives in teh community folder. To enable it you use the 
probile "web2".

So, to compile with the old web module:

mvn -P legacy clean install

Where the web module will be found under legacy/web.

Hope that helps. Let me  know if you have any more problems. Again my 
apologies for the state of trunk right now.

-Justin

Ravichandra K.N wrote:
> Thanks for your reply.
> 
> Now i was able to build successfully. but what next i didn't understand.
> 
> let me tell you the steps i followed.
> 
> 1. created a folder geoserver_dev in c: drive. [i'm using windows].
> 
> 2. then svn checkout https://svn.codehaus.org/geoserver/trunk/src 
> 
>  i did the check using above url. Inside c:\geoserver_dev. It checked in 
> all the folders as it was shown in the site.
> 
> 3. mvn install. this time mvn install was Build successful. This 
> commonad executed from c:\geoserver_dev\src.
> 
> 4. now i'm not able to find the web directory, to start the Jetty:run. i 
> didn't find the /web directory inside my geoserver_dev folder. I was 
> trying to execute the command from the same path. but i was not able to.
> 
> Please let me know where i have to find the /web directory. I tried from 
> .m2 repository but i could not find there.
> 
> I'm bit confused how to run the jetty. [:(]
> 
> Hope you understood my problem.
> 
> regards,
> Ravi
> 
> 
> On Thu, Mar 5, 2009 at 9:12 PM, Justin Deoliveira  > wrote:
> 
> Hi Ravi,
> 
> it is a little out of date but the maven quickstart can be found here:
> 
> http://geoserver.org/display/GEOSDOC/2+Maven+Quickstart
> 
> It would help if you included the failures you are getting so we can
> better comment on what might be wrong.
> 
> Another thing to keep in mind is that trunk can be unstable at
> times, and it might just be that the build is broken. You can check
> this by visiting http://hudson.opengeo.org/hudson/, and noting the
> status of "geoserver-trunk". Which at the moment appears to be down :(
> 
> -Justin
> 
> ravichandrakn wrote:
> 
> Hi All,
> 
> I'm new to this community, I'm trying to Build geoserver using
> maven.
> 
> the following are the version i'm using.
> apache-maven-2.0.10
> subversion: svn-1.3.0-setup
> 
> After i checkout the geoserver code from svn checkout
> https://svn.codehaus.org/geoserver/trunk
> i was trying to build using mvn install. Build failure and 8
> failures its
> showing.
> I don't know why it's throwing so may failures.
> Can anyone please post the step-by-step procedure to build
> geoserver using
> maven. The Available reference in geoser.org 
> is too confusing and didn't
> explain properly.
> 
> regards,
> Ravi.
> 
>  
> 
> 
> 
> -- 
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
> 
> 
> 
> 
> -- 
> Regards,
> Ravi,
> Integra Micro Systems(P) ltd,
> Bangalore-92.
> +919845787811


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

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

Re: [Geoserver-devel] GSIP 33 - rest configuration module

[Justin Deoliveira]

> 
> Just one observation. From the roadmap it seems we won't have
> resource/map split in 2.0.
> At the moment layers are published on:
> /layers/[.]
> but when we push on the separation and make maps (virtual geoservers
> with a limited set of layers), they will be probably put into:
> /[.]
Yeah, I thought a little about this. And basically my thought is that to 
deprecate the /layers/ syntax once we the split. To support the old 
syntax we use the same lookup tricks we use today for layers and feature 
types: 1) check for a prefixed name and 2) check for case of a single 
layer with that name, etc...

For instance to reference the following layer:

/maps/m/layer/l

We allow people to use /layers/m:l

Or just /layers/l

If only a single map has a layer named "l".

-Justin

> 
> This kind of change will occur most likely in some 2.x.y release,
> depending one when resource to actually develop it become available.
> So we'll probably break the rest API, but (I guess) not in 2.0.0
> 
> Cheers
> Andrea
> 


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

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

[Geoserver-devel] [jira] Created: (GEOS-2709) Add a chooser for raster supported formats, interpolation methods

[Andrea Aime (JIRA)]

Add a chooser for raster supported formats, interpolation methods
-

 Key: GEOS-2709
 URL: http://jira.codehaus.org/browse/GEOS-2709
 Project: GeoServer
  Issue Type: Task
Reporter: Andrea Aime
Assignee: Andrea Aime
 Fix For: 2.0.x


The supported formats list and the interpolation methods list are actually 
closed sets of options, thus we should provide a UI that allows only to choose 
what's available.
The same goes to some extent to the response SRS, but the list is very long. We 
could have auto-complete there, and disallow adding a SRS code that we don't 
actually know about.

-- 
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



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

[Geoserver-devel] [jira] Reopened: (GEOS-2160) Raster Resource Configuration

[Andrea Aime (JIRA)]

 [ 
http://jira.codehaus.org/browse/GEOS-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Aime reopened GEOS-2160:
---


> Raster Resource Configuration
> -
>
> Key: GEOS-2160
> URL: http://jira.codehaus.org/browse/GEOS-2160
> Project: GeoServer
>  Issue Type: Sub-task
>  Components: Wicket UI
>Affects Versions: 2.0-alpha1
>Reporter: Gabriel Roldán
>Assignee: Gabriel Roldán
> Fix For: 2.0.x
>
>
> -  Data:
> -- Coverage Metadata
> --- (/) Title
> --- (/) Abstract
> --- (/) Keywords
> --- (/) Native SRS
> --- (/) Native bounding box
> --- (/) LatLon bounding box
> -- Coverage Settings
> --- (/) Request CRS (1..*)
> --- (/) Response CRS (1..*)
> --- (/) Interpolation methods (1..*)
> --- (/) Native format ( informative )
> --- (/) Supported formats (1..*)
> - Publishing
> -- (/) Name
> -- (/) Enabled
> -- HTTP Settings
> --- (/) Set response cache headers
> --- (/) Cache timeout
> -- WMS Settings
> --- (/) Default Style
> --- (/) Additional Styles (0..*)
> --- (/) WMS Path
>  

-- 
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

   

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

[Geoserver-devel] [jira] Created: (GEOS-2708) Wicket UI: have lat/lon bbox generated from the native bbox automatically

[Andrea Aime (JIRA)]

Wicket UI: have lat/lon bbox generated from the native bbox automatically
-

 Key: GEOS-2708
 URL: http://jira.codehaus.org/browse/GEOS-2708
 Project: GeoServer
  Issue Type: Task
Reporter: Andrea Aime
Assignee: Andrea Aime
 Fix For: 2.0.x


The wicket UI has the native and lat/lon bboxes editable, both, at the same 
time. This is inconsistent, as one can be derived from the other.
I'd say, let's make the native editable and have the lat/lon non editable, 
automatically generated each time the native one changes (ajax updates)

-- 
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



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

[Geoserver-devel] [jira] Reopened: (GEOS-2158) Vector Resource Configuration

[Andrea Aime (JIRA)]

 [ 
http://jira.codehaus.org/browse/GEOS-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Aime reopened GEOS-2158:
---


> Vector Resource Configuration
> -
>
> Key: GEOS-2158
> URL: http://jira.codehaus.org/browse/GEOS-2158
> Project: GeoServer
>  Issue Type: Sub-task
>  Components: Wicket UI
>Affects Versions: 2.0-alpha1
>Reporter: Gabriel Roldán
>Assignee: Gabriel Roldán
> Fix For: 2.0.x
>
>
> - Data:
> -- (/) Title
> -- (/) Abstract
> -- (/) Keywords
> -- (/) Native SRS
> -- (/) Native bounding box
> - Publishing
> -- (/) Enabled
> -- (/) Name
> -- (/) Set HTTP Response Cache Headers
> -- (/) Cache Timeout (seconds)
> -- WFS Settings
> --- (/) Max Features
> -- WMS Settings
> --- (/) Default Style
> --- (/) Additional Styles
> --- (/) WMS  Path
> -- GeoSearch
> --- (/) Enable Indexing
> -- KML Format Settings
> --- (/) Default Regionating Attribute
> --- (/) Default Regionating Method
> --- (/) Features Per Regionated Tile

-- 
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

   

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

[Geoserver-devel] [jira] Created: (GEOS-2707) Document wicket ui extension points, i18n usage, coding conventions and style guidelines

[Andrea Aime (JIRA)]

Document wicket ui extension points, i18n usage, coding conventions and style 
guidelines


 Key: GEOS-2707
 URL: http://jira.codehaus.org/browse/GEOS-2707
 Project: GeoServer
  Issue Type: Task
Reporter: Andrea Aime
Assignee: Andrea Aime
 Fix For: 2.0.x


We need to write down some documentatino for everything we do that's not 
covered by the official wicket documentation. In particular:
* our custom i18n framework (how to use it)
* the extension points, such as panels, menu items, how to make one, how to 
register it into the spring context
* some style guidelines so that the UI code has some uniformity (stuff like 
"create the page structure into the constructor but factory out actions and the 
like in their own methods)
* point to classes of general use, something like the 
sortable/filterable/pageable table approach that seems to becoming pervasive in 
the UI

-- 
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



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

[Geoserver-devel] [jira] Reopened: (GEOS-2156) DataStore Configuration

[Andrea Aime (JIRA)]

 [ 
http://jira.codehaus.org/browse/GEOS-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Aime reopened GEOS-2156:
---


> DataStore Configuration
> ---
>
> Key: GEOS-2156
> URL: http://jira.codehaus.org/browse/GEOS-2156
> Project: GeoServer
>  Issue Type: Sub-task
>  Components: Wicket UI
>Affects Versions: 2.0-alpha1
>Reporter: Gabriel Roldán
>Assignee: Gabriel Roldán
> Fix For: 2.0.x
>
>
> Allows to set up a DataStore based on its configuration parameters
> - (/) Data Source name
> - (/) Enabled
> - (/) Namespace
> - (/) List of datastore parameters dynamically generated based on the 
> {{DataAccessFactory.Param}} it expects

-- 
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

   

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

Re: [Geoserver-devel] GSIP 33 - rest configuration module

[Andrea Aime]

Chris Holmes ha scritto:
...
> Personally I don't see a huge reason to try to commit to backwards 
> compatibility with the 1.7.x rest api and the 2.0.x rest api.  Don't get 
> me wrong, it'd be super nice.  But if we are doing a major version 
> change we do have the luxury of breaking apis if we need to.  Clients 
> should not expect that a 2.0 version of the product will have a 
> completely backwards compatible api.
> 
> Of course I do think our design of a rest api should not be tightly 
> coupled to how we make our catalog - it should be independent concepts 
> ideally.  But realistically this is our first attempt, and though it's 
> not bad we'll probably see how we can improve it.  Since we are moving 
> to 2.0 we do have the chance to 'throw one away', and make a really nice 
> one for 2.0. 

Just one observation. From the roadmap it seems we won't have
resource/map split in 2.0.
At the moment layers are published on:
/layers/[.]
but when we push on the separation and make maps (virtual geoservers
with a limited set of layers), they will be probably put into:
/[.]

This kind of change will occur most likely in some 2.x.y release,
depending one when resource to actually develop it become available.
So we'll probably break the rest API, but (I guess) not in 2.0.0

Cheers
Andrea

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

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

[Geoserver-devel] [jira] Created: (GEOS-2706) Invalid url for format type 'ArcSDE Raster'

[LukaszLagosz (JIRA)]

Invalid url for format type 'ArcSDE Raster'
---

 Key: GEOS-2706
 URL: http://jira.codehaus.org/browse/GEOS-2706
 Project: GeoServer
  Issue Type: Bug
  Components: ArcSDE
Affects Versions: 1.7.3, 1.7.2
 Environment: Windows 2003 standard
Reporter: LukaszLagosz
Assignee: Andrea Aime
 Attachments: geoserver_bug.png

Hi.
I have a big problem with getting ArcSDE rasters work with GeoServer.
I have done everything just like in 
http://docs.codehaus.org/display/GEOTDOC/ArcSDE+DataStore
But still when I'm trying to make a Coverage Data Store I get "Invalid url" all 
the time.

Is the pattern of the url writen in the link I get OK ?
sde://user:p...@host[geosdoc::port]/[GEOSDOC:instance]#raster_table_name[GEOSDOC:;extra_param=extra_value]

I've tryied many combinations in this url, but I still get "invalid url" and 
none error in Geoserver logs.
I'm using Oracle10g and ArcSDE 9.1 with latest service packs.



-- 
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



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

Re: [Geoserver-devel] GSIP 33 - rest configuration module

[Chris Holmes]

On Mon, Mar 9, 2009 at 3:54 PM, Justin Deoliveira wrote:

> Andrea Aime wrote:
> > Jody Garnett ha scritto:
> > ...
> >> Okay that is probably the step I was missing; with that in mind can we
> >> make the decision to keep the api we publish here stable for GeoServer
> >> 2.0 - even if that means we present new capabilities in GeoServer 2.0
> >> in a slightly screwed form (ie we may not get away with pure
> >> reflection?).
> >
> > For 2.0 I believe so. But I don't have the crystal ball.
> > If some significant contribution comes in, or some significant new
> > functionality is sponsored, we may have to change the api.
> >
> > As far as I remember in the REST world one tends to "version" the
> > api and try to keep at least one old version around, not sure what
> > Justin's plan are on this one thought.
> The api is going to undoubtedly change as we continue to change the
> configuration. I have tried to hit a middle ground with the current rest
> api that hits some of the concepts that we anticipate, 1) it groups by
> workspace, not namespace, and 2) makes layer a separate entity when in
> reality it is not, etc.. Versioning the api makes a lot of sense to me.
> And when it does come to change I don't anticipate any issues with going
> though a normal deprecation cycle first.


Personally I don't see a huge reason to try to commit to backwards
compatibility with the 1.7.x rest api and the 2.0.x rest api.  Don't get me
wrong, it'd be super nice.  But if we are doing a major version change we do
have the luxury of breaking apis if we need to.  Clients should not expect
that a 2.0 version of the product will have a completely backwards
compatible api.

Of course I do think our design of a rest api should not be tightly coupled
to how we make our catalog - it should be independent concepts ideally.  But
realistically this is our first attempt, and though it's not bad we'll
probably see how we can improve it.  Since we are moving to 2.0 we do have
the chance to 'throw one away', and make a really nice one for 2.0.

C



>
> >
> >> To handle the kind of structural changes you seem demanding for, we
> >> need to work on trunk and change the catalog api accordingly, and we
> >> need some funding to make the changes, or someone that wants to
> >> spend his time working on it.
> >>
> >>
> >> I was not aware this was pure reflection.
> >
> > It was figured speech, I was not implying the usage of Java reflection
> > (thought it's actually used in the classes, but don't exactly know to
> > which extent).
> It uses reflection for serializing and deserializing catalog objects.
> The rationale was 1) we already have a bunch of utilities that help us
> do reflection and 2) we already had the xstream encoder/decoder which
> works reflectively so using it for rest was a pretty big win to support
> XML and JSON out of the box.
> >
> >> The topic of GSIP 33 is "is this REST api good to deal with the
> >> GeoServer catalog we have today?", what you're trying to discuss is
> >> "is the catalog API good for the
> >> next 5 years?" which is definitely a interesting topic, but a
> >> different one.
> >>
> >>
> >> I was trying to hit the middle ground of; how do we intergrate a few
> >> of tomorrows features into the api being published today. I tried to
> >> make some suggestions that would agree with the plan out outlined in
> >> the documentation.
> >
> > What makes people react negatively to your suggestion is that they
> > come with request of more work and no contribution on your part.
> > The idea is welcomed, but the way you're expressing it seems like
> > twisting people arm into doing more work than they have resources for...
> > not surprisingly you get negative reactions.
> I think this may be a mis understanding of what feedback to a proposal
> should be. I think most people want feedback to be concise and something
> they can readily factor into a proposal, where as often your feedback is
> thinking much longer term and at times off topic.
> >
> >>
> >> Let's talk about it, but in a different thread, and then let's put
> >> the result, along with an estimation, on the roadmap ideas, and see
> >> if anyone is up to funding it.
> >>
> >>
> >> I do not think we need to go that far; I just wanted to account for
> >> how future work would be integrated into the api as published. I do
> >> not want to publish an API we know is going to be broken in the next
> >> year.
> >
> > Then let's stop doing anything in GeoServer. The current development
> > model does not allow to account for such long term concerns.
> > Release early and often does not work well with "let's account for next
> > 5 years". When we're lucky it has a glimpse of what's coming in the
> > next year.
> >
> > Just look, for example, at the roadmap ideas page. It has topic to cover
> > one/two years of development. Yet none of them has direct sponsoring
> > so far, so I cannot say whether they will be developmen

Re: [Geoserver-devel] GSIP 33 - rest configuration module

[Andrea Aime]

Jody Garnett ha scritto:
> As far as I remember in the REST world one tends to "version" the
> api and try to keep at least one old version around, not sure what
> Justin's plan are on this one thought.
> 
> 
> That sounds like a good approach.  
> 
> What makes people react negatively to your suggestion is that they
> come with request of more work and no contribution on your part.
> 
> 
> I understand that - I tried to outline some integration options that 
> would not disturb the existing rest layout but that was lost in the noise.

I interpreted all your comments as requests to modify the catalog api.
I have the impression Justin did the same.
There is a communication gap here.

> This is my first serious review of the API being presented and I am 
> trying to treat it with all the respect it deserves. This is a test of 
> the process for merging in a community module is it not? And thus my 
> first chance to review.

Afaik we're well beyond test, it's definitely not the first module
that goes thru the process already, the difference is that this is big
enough to warrant a GSIP instead of a plain mail asking for feedback.

As for lack of mails, yeah, that is indeed a problem, we're using
IRC and other communication mails too much and cutting off people
that for various reasons can follow the project only reading the
mailing list. I guess we should get the habit of posting to the
mailing list logs interesting dicussions happening on IRC.
Mind, that might mean multiple IRC snippets posted each day.

Cheers
Andrea

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

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