Re: [Geoserver-devel] Problems with GeoServer 1.7.5

Andrea Aime wrote: > Mauro Bartolomeoli ha scritto: >> Testing GeoServer 1.7.5, I found a strange behaviour in WMS: when the >> requested bounding box is little (10 to 50 meters) in comparison to >> the requested featuretype/s bbox (some kilometer to hundreds of >> kilometers). Memory used sta

Re: [Geoserver-devel] Catalog, namespaces, workspaces, layer names...

well, for a start its great to see the issue being debated before finalisation of code :-) I'm not over the intricacies of the beast to be honest, just providing a "sanity check". One thing I'd point out - namespaces do not exist to disambiguate the feature type on the server - they exist to disa

Re: [Geoserver-devel] Catalog, namespaces, workspaces, layer names...

Ben Caradoc-Davies wrote: > Andrea Aime wrote: >> But isn't the namespace a publishing property, and >> so something that should be set at the layer >> level? > > Some feature types get their namespaces glued on at publishing time. > Some have their namespace as an intrinsic property; for example

Re: [Geoserver-devel] Catalog, namespaces, workspaces, layer names...

Rob Atkinson wrote: > what if we have the same feature type being delivered by multiple > stores This, in my understanding, is one of the goals of the resource/publishing split. I hope one day that we can bind (for example) each workspace to a different WFS service URL in the same GeoServer ins

Re: [Geoserver-devel] Catalog, namespaces, workspaces, layer names...

Andrea Aime wrote: > But isn't the namespace a publishing property, and > so something that should be set at the layer > level? Some feature types get their namespaces glued on at publishing time. Some have their namespace as an intrinsic property; for example, app-schema feature types. You thi

Re: [Geoserver-devel] Proxy Community Module

Hi, I just skimmed through it, and maybe I am missing something. But it sounds and looks like by default it allows anyone to go anywhere? I realize we will not be shipping this by default, but I don't think that's a good idea anyway. We should include a regex filter from the start (can be simp

Re: [Geoserver-devel] Catalog, namespaces, workspaces, layer names...

Rob Atkinson wrote: > Thinking out aloud... > > what if we have the same feature type being delivered by multiple > stores - for example a common gazetteer view of the different feature > types. Or sometimes we have several sub-types, and we want to provide > a single view using a supertype. I ma

Re: [Geoserver-devel] xstream persistence and metadata map

Justin Deoliveira wrote: > I have gone and implemented the map as based on this thread. I would > love a review: I've posted my feedback on the issue. Basically it looks good, I just keep on thinking there's no need for MetadataMap to implementa java.util.Map. Proposed change being it either ju

Re: [Geoserver-devel] Catalog, namespaces, workspaces, layer names...

Thinking out aloud... what if we have the same feature type being delivered by multiple stores - for example a common gazetteer view of the different feature types. Or sometimes we have several sub-types, and we want to provide a single view using a supertype. This situation does occur in practi

[Geoserver-devel] Hudson build is back to normal: geoserver-trunk #1239

See http://hudson.opengeo.org/hudson/job/geoserver-trunk/1239/changes -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution

[Geoserver-devel] [jira] Reopened: (GEOS-3076) GetLegendGraphics with width/height results in a ClassCastException

[ http://jira.codehaus.org/browse/GEOS-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Deoliveira reopened GEOS-3076: - Ok. that fix does not do it, breaks the build so reverted it. I think I understand why the custom w

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

See http://hudson.opengeo.org/hudson/job/geoserver-trunk/1238/changes Changes: [jdeolive] GEOS-3076, passing in raw kvp map to old style kvp readers -- [...truncated 3829 lines...] at org.geoserver.test.GeoServerAbstractTestSupport.dispatch(GeoSer

Re: [Geoserver-devel] Building jars for comumnity modules & other details

> I see; I meant to say a community module, in that case. How does one > package one of those up into a distributable jar, without dependencies > hanging out in the Maven repository or such? Well you can follow the steps in the guide and create an artifact descriptor, etc... etc.. but if you j

Re: [Geoserver-devel] xstream persistence and metadata map

I have gone and implemented the map as based on this thread. I would love a review: http://jira.codehaus.org/browse/GEOS-3164 -Justin Gabriel Roldan wrote: > Andrea Aime wrote: >> Gabriel Roldan ha scritto: >>> Andrea Aime wrote: Justin Deoliveira ha scritto: > Hi all, > > A fe

[Geoserver-devel] [jira] Created: (GEOS-3164) Change metadata on catalog and config objects to be a type safe converting map

Change metadata on catalog and config objects to be a type safe converting map -- Key: GEOS-3164 URL: http://jira.codehaus.org/browse/GEOS-3164 Project: GeoServer Is

Re: [Geoserver-devel] Building jars for comumnity modules & other details

On Jun 16, 2009, at 4:23 PM, Justin Deoliveira wrote: > Hi Alan, > > Alan Gerber wrote: >> Today I committed the printing module to subversion in /community/ >> printing. Documentation as it stands is at >> > >; is that the correct place?

Re: [Geoserver-devel] Proxy Community Module

That patch includes all the changes I needed to get things to compile in eclipse and with maven. I guess the service modules get pulled through some dependency? -- David Winslow OpenGeo - http://opengeo.org/ On Tue, 2009-06-16 at 14:16 -0600, Justin Deoliveira wrote: > I am curious as to how t

Re: [Geoserver-devel] Building jars for comumnity modules & other details

Hi Alan, Alan Gerber wrote: > Today I committed the printing module to subversion in /community/ > printing. Documentation as it stands is at > >; is that the correct place? However, it's not terribly useful > right now for a couple of re

Re: [Geoserver-devel] Proxy Community Module

I am curious as to how these compile? I guess you had to add dependencies on all the service modules? On 1.7.x the W*SConfig classes were all in main, but in trunk the W*SInfo classes are in the respective service modules. David Winslow wrote: > Okay, a basic proxy restlet has hit trunk. I had

Re: [Geoserver-devel] XStreamPersister.SRSConverter taking a lot of time

Andrea Aime wrote: > Justin Deoliveira ha scritto: >> Unfortunately I have run into this issue in a few places, and the only >> time the answer is to do a full lookup. I always to try to set >> fullScan to false, but it seems to only work some of the time. I >> understand the cost of the lookup

[Geoserver-devel] Building jars for comumnity modules & other details

Today I committed the printing module to subversion in /community/ printing. Documentation as it stands is at ; is that the correct place? However, it's not terribly useful right now for a couple of reasons: 1. You need to bulid your own G

Re: [Geoserver-devel] Proxy Community Module

Okay, a basic proxy restlet has hit trunk. I had to make a few modifications to the rest module to get it to compile, but have not committed these. A patch is attached if someone (jdeolive, maybe?) would care to review. I guess I'll need to update the code anyway when the changes from 1.7.x are

Re: [Geoserver-devel] XStreamPersister.SRSConverter taking a lot of time

Justin Deoliveira ha scritto: > Unfortunately I have run into this issue in a few places, and the only > time the answer is to do a full lookup. I always to try to set fullScan > to false, but it seems to only work some of the time. I understand the > cost of the lookup but I see no other altern

[Geoserver-devel] [jira] Created: (GEOS-3163) NullPointerException on a (bad) WMS request

NullPointerException on a (bad) WMS request --- Key: GEOS-3163 URL: http://jira.codehaus.org/browse/GEOS-3163 Project: GeoServer Issue Type: Improvement Components: WMS Affects Versions:

Re: [Geoserver-devel] About CatalogBuilder.buildFeatureType()/buildLayer()

Andrea Aime wrote: > Andrea Aime ha scritto: >>> Are you talking about the code that calls featureSource.getBounds()? I >>> am ok with breaking out expensive operations into a separate methods. >> Yep, that's the one. > > Another long-ish operation is looking up the SRS from the native CRS > usin

Re: [Geoserver-devel] XStreamPersister.SRSConverter taking a lot of time

Unfortunately I have run into this issue in a few places, and the only time the answer is to do a full lookup. I always to try to set fullScan to false, but it seems to only work some of the time. I understand the cost of the lookup but I see no other alternative in a case where you *need* an S

Re: [Geoserver-devel] About CatalogBuilder.buildFeatureType()/buildLayer()

Andrea Aime ha scritto: >> Are you talking about the code that calls featureSource.getBounds()? I >> am ok with breaking out expensive operations into a separate methods. > > Yep, that's the one. Another long-ish operation is looking up the SRS from the native CRS using: ftinfo.setSRS( CRS.look

[Geoserver-devel] XStreamPersister.SRSConverter taking a lot of time

Hi, investigating why saving a feature type was taking so long on trunk I found out this code: @Override public String toString(Object obj) { CoordinateReferenceSystem crs = (CoordinateReferenceSystem) obj; try { return "EPSG:" + CRS.lookupEpsgCode(crs, true); } catch

Re: [Geoserver-devel] About CatalogBuilder.buildFeatureType()/buildLayer()

Justin Deoliveira ha scritto: > I guess the latter. I agree that its better design to just have the > builder do what it can, and not throw exceptions, seems more inline with > what a builder should do. The downside is that this logic will have to > replicated elsewhere. And there is possibilit

Re: [Geoserver-devel] Proxy Community Module

The proxy is not for hosting the application itself, but allowing it to circumvent the same-origin policy imposed on JavaScript applications by web browsers (JavaScript applications cannot make HTTP requests to domains other than the one hosting the page they run in). This is only needed for OpenL

Re: [Geoserver-devel] Proxy Community Module

David Winslow ha scritto: > Hey all, > > In order to simplify deployment of OpenLayers applications on top of > GeoServer, I would like to create a community module on trunk that > mimics the proxy.cgi script that is often used with OpenLayers. > Basically, this script accepts a URL as a query par

Re: [Geoserver-devel] Problems with GeoServer 1.7.5

Mauro Bartolomeoli ha scritto: > Testing GeoServer 1.7.5, I found a strange behaviour in WMS: when the > requested bounding box is little (10 to 50 meters) in comparison to the > requested featuretype/s bbox (some kilometer to hundreds of kilometers). > Memory used starts to grow during renderin

Re: [Geoserver-devel] Proxy Community Module

No objections here. +1 David Winslow wrote: > Hey all, > > In order to simplify deployment of OpenLayers applications on top of > GeoServer, I would like to create a community module on trunk that > mimics the proxy.cgi script that is often used with OpenLayers. > Basically, this script accepts a

[Geoserver-devel] Proxy Community Module

Hey all, In order to simplify deployment of OpenLayers applications on top of GeoServer, I would like to create a community module on trunk that mimics the proxy.cgi script that is often used with OpenLayers. Basically, this script accepts a URL as a query parameter and forwards the request to ano

[Geoserver-devel] Problems with GeoServer 1.7.5

Testing GeoServer 1.7.5, I found a strange behaviour in WMS: when the requested bounding box is little (10 to 50 meters) in comparison to the requested featuretype/s bbox (some kilometer to hundreds of kilometers). Memory used starts to grow during rendering until I get an OutOfMemory. The same

Re: [Geoserver-devel] About CatalogBuilder.buildFeatureType()/buildLayer()

Andrea Aime wrote: > Hi, > I'm trying to use CatalogBuilder.buildFeatureType() and I'm > having some troubles with its behaviour, so I'm looking > for ways to fix it. > (see full source code here: > http://svn.codehaus.org/geoserver/trunk/src/main/src/main/java/org/geoserver/catalog/CatalogBuilder

[Geoserver-devel] About CatalogBuilder.buildFeatureType()/buildLayer()

Hi, I'm trying to use CatalogBuilder.buildFeatureType() and I'm having some troubles with its behaviour, so I'm looking for ways to fix it. (see full source code here: http://svn.codehaus.org/geoserver/trunk/src/main/src/main/java/org/geoserver/catalog/CatalogBuilder.java) The basic issue I'm hav

Re: [Geoserver-devel] Catalog, namespaces, workspaces, layer names...

Hi Andrea, Andrea Aime wrote: > Hi, > I'm getting tangled in a seemingly simple issue. > I want to know if a FeatureTypeInfo with a certain > name is available in the catalog already to avoid > duplicates. > > Now, logics tells me there should not be two feature > types with the same name in the

[Geoserver-devel] Catalog, namespaces, workspaces, layer names...

Hi, I'm getting tangled in a seemingly simple issue. I want to know if a FeatureTypeInfo with a certain name is available in the catalog already to avoid duplicates. Now, logics tells me there should not be two feature types with the same name in the workspace. Right? However, the catalog uses a

[Geoserver-devel] [jira] Created: (GEOS-3162) OutOfMemoryError

OutOfMemoryError Key: GEOS-3162 URL: http://jira.codehaus.org/browse/GEOS-3162 Project: GeoServer Issue Type: Bug Affects Versions: 1.7.5 Environment: 1.7.5 with mysql plugin. On Windows Vista. Repor

[Geoserver-devel] [jira] Created: (GEOS-3161) GeoServer accepts characters in typenames that lead to non well-formed XML

GeoServer accepts characters in typenames that lead to non well-formed XML -- Key: GEOS-3161 URL: http://jira.codehaus.org/browse/GEOS-3161 Project: GeoServer Issue Type

Re: [Geoserver-devel] Build GeoServer WAR with Wicket in DEPLOYMENT mode?

Andrea Aime wrote: > Ben Caradoc-Davies ha scritto: >> What is the correct way to build a GeoServer WAR so that, on deployment, >> it is in Wicket PRODUCTION mode? > > Change the applicationContext.xml file in the web2/app module. I think you mean web2/core. > I still haven't figured out a bett