web2/GSIP-34 corrupts CITE wfs-1.0 data directory
-
Key: GEOS-2808
URL: http://jira.codehaus.org/browse/GEOS-2808
Project: GeoServer
Issue Type: Bug
Components: Global
Rep
Christian Müller ha scritto:
> Last week I posed a question about having a FeatureSource which has also
> some generalizations of the vector data to speed up response time and reduce
> data transfer.
>
> While it is is surely not the problem to implement such a FeatureSource, I
> need the Sca
DescribeFeatureType fails twelve CITE WFS 1.0 tests
---
Key: GEOS-2809
URL: http://jira.codehaus.org/browse/GEOS-2809
Project: GeoServer
Issue Type: Bug
Components: WFS
Re
Properly handle workspaces, stores and layers whose name is not filesystem
friendly
---
Key: GEOS-2810
URL: http://jira.codehaus.org/browse/GEOS-2810
Project: GeoServer
Thanks for the information.
I never had the intension to generalise on the fly. I want to implement the
same principle I used
with the imagemosaic-jdbc module, storing pyramid levels in the datastore.
All the pre generalized geometries have to be valid, because WFS should also
be supported.
Ben Caradoc-Davies ha scritto:
> Justin,
>
> there are three different geoserver/data/citewfs-1.1* directories.
>
> The CITE test guide asserts the need for H2 support (which I built), but
> describes using the citewfs-1.1 directory (which uses postgis),
> http://gridlock.openplans.org/geoserver
Justin,
there are three different geoserver/data/citewfs-1.1* directories.
The CITE test guide asserts the need for H2 support (which I built), but
describes using the citewfs-1.1 directory (which uses postgis),
http://gridlock.openplans.org/geoserver/1.7.x/doc/developer/cite-test-guide/index.ht
Hi Ben,
I don't think this is actually a problem. I have seen DFT tests fail
like this in the past and never found a reason why. I think it is just
an issue with the wfs 1.0 tests, but something i have never isolated.
Just to be sure can you include the log of one of the tests. For example:
sh
Andrea Aime wrote:
> Ben Caradoc-Davies ha scritto:
>> Justin,
>>
>> there are three different geoserver/data/citewfs-1.1* directories.
>>
>> The CITE test guide asserts the need for H2 support (which I built),
>> but describes using the citewfs-1.1 directory (which uses postgis),
>> http://gridlo
Justin Deoliveira ha scritto:
>>> There are three citewfs-1.1* directories:
>>> citewfs-1.1
>> Used for plain wfs-1.1 tests, no xlink, using postgis
> Actually, afaik postgis does not pass the 1.1 cite test suite. Unless
> someone did some work to get them to pass. So i usually don't use this
> c
>
> Mumble mumble. It's been quite a while since I last run the CITE WFS
> tests but I remember them to pass fully (minus the issue that one cannot
> have WCS 1.0 and WCS 1.1 deployed at the same time in order to run
> the WCS 1.0 tests)?
> s it something specific from trunk, from the svn script
Christian Müller ha scritto:
> But anyway, I do not want any generalization on the fly and 1) is my first
> target.
>
> Passing difference/offset in the native CRS as a hint would make me happy
> :-)
> If the hint is missing, you always get the base geometries, the same holds
> true if the val
Hi,
I'm a bit in a bind for a number of issues related to resource
validation and resource names.
Say I'm adding again an existing dataset, without aliasing it,
and I press submit to add the "clone" [1]. What I get is, rightfully,
the following stack trace:
java.lang.IllegalArgumentException: Res
Andrea Aime wrote:
> Hi,
> I'm a bit in a bind for a number of issues related to resource
> validation and resource names.
>
> Say I'm adding again an existing dataset, without aliasing it,
> and I press submit to add the "clone" [1]. What I get is, rightfully,
> the following stack trace:
>
> ja
Andrea Aime wrote:
> Hi,
> I'm a bit in a bind for a number of issues related to resource
> validation and resource names.
>
> Say I'm adding again an existing dataset, without aliasing it,
> and I press submit to add the "clone" [1]. What I get is, rightfully,
> the following stack trace:
>
> ja
Andrea, I am not sure what you are meaning
"same data source can provide different geometries properties"
1a)
I assume you mean that within one feature type we can have more than one
geometry property.
Since a feature has a default geometry, this is the one we should use. If I
have a feature
Christian Müller ha scritto:
> Andrea, I am not sure what you are meaning
> "same data source can provide different geometries properties"
> 1a)
> I assume you mean that within one feature type we can have more than one
> geometry property.
Indeed.
> Since a feature has a default geometry, this
Hi all,
I have found in a couple of places when writing listeners for the
catalog doing stuff like this:
public void handleModifyEvent(CatalogModifyEvent event) {
if ( event.getSource() instanceof DataStoreInfo ) {
}
else if ( event.getSource() instanceof FeatureTypeInfo ) {
See http://hudson.opengeo.org/hudson/job/geoserver-trunk/902/changes
Changes:
[jdeolive] GEOS-2798, adding a listener to catalog for purging cache on
modification events
[jdeolive] GEOS-2796, ensuring no spaces when maps are encoded
--
[...truncated 408
Justin Deoliveira ha scritto:
> Hi all,
>
> I have found in a couple of places when writing listeners for the
> catalog doing stuff like this:
>
>public void handleModifyEvent(CatalogModifyEvent event) {
> if ( event.getSource() instanceof DataStoreInfo ) {
>
> }
> else if (
ecw only in wgs84
-
Key: GEOS-2811
URL: http://jira.codehaus.org/browse/GEOS-2811
Project: GeoServer
Issue Type: Bug
Components: WCS
Affects Versions: 1.7.3
Environment: Windows
Reporter: Th
CatalogImpl.validate(ResourceInfo, false) does not handle name change
-
Key: GEOS-2812
URL: http://jira.codehaus.org/browse/GEOS-2812
Project: GeoServer
Issue Type: Bug
See http://hudson.opengeo.org/hudson/job/geoserver-trunk/903/changes
Changes:
[jdeolive] changed resolve() to ensure listener list is set before resource
pool is created
[jdeolive] changed assertion to reflect map encoding changes
[jdeolive] fixing recursive call
-
Justin Deoliveira ha scritto:
> This is a tough issue. The make a copy and validate the copy seems hacky
> to me... and relies on how the in memory catalog is implemented
> internally. Also the validate() methods are not public api, which means
> we would have ot make them public api, which rais
>
> Works for me, but how do we deal with code that wants to throw a
> safeguard exception in the last else? The usual "there is a programing
> error, I don't know what this thing is" kind of exception.
Good point, never thought of that. However, everything in Catalog is
more or less a "closed
See http://hudson.opengeo.org/hudson/job/geoserver-trunk/904/changes
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lis
Include maintainer information with extensions code
---
Key: GEOS-2813
URL: http://jira.codehaus.org/browse/GEOS-2813
Project: GeoServer
Issue Type: Improvement
Affects Versions: 1.7.3
> - the same column can contain geometries with different spatial
> reference system too. I know it sounds crazy, but as far as I remember
> OGC WFS makes sure that you can handle that case as well... mixed
> with the fact that in GeoServer you have to declare a SRS anyways
> (we have no w
Justin Deoliveira ha scritto:
>> - the same column can contain geometries with different spatial
>> reference system too. I know it sounds crazy, but as far as I remember
>> OGC WFS makes sure that you can handle that case as well... mixed
>> with the fact that in GeoServer you have to declar
>>
>> The spec definitely does not prohibit it. But the CITE tests only
>> ensure we can handle multiple geoms in the same referencing system.
>
> Then I wonder why we have all this code around checking the JTS Geometry
> user data for a per-geometry CRS (in the rendering code in particular,
> i
1)
Andrea, after the last messages I would propose:
Pass the resolution hint if you are sure that nothing bad can happen.
However you do it, I rely on getting the hint with feature types having one
geometry property with the same CRS.
2) I did a quick implementation of GeneralizingFeatureSourc
Hi Ben,
I'll be giving a shot to app-schema support on trunk and am wondering if
there's already any backend that supports SQL queries as the source of data,
like we did with the SQLDataStore interface on the complex-features branch?
cheers,
--
Gabriel Roldan
http://www.opengeo.org
--
Not that I know of, Andrea and I talked about doing this for jdbc-ng but
never got around to it.
Gabriel Roldán wrote:
> Hi Ben,
>
>
> I'll be giving a shot to app-schema support on trunk and am wondering if
> there's already any backend that supports SQL queries as the source of
> data, like
Possible Memory Leak
Key: GEOS-2814
URL: http://jira.codehaus.org/browse/GEOS-2814
Project: GeoServer
Issue Type: Bug
Components: PostGIS, WMS
Affects Versions: 1.7.3
Environment: Debian Etch, Posg
WMS Decoration Layout
-
Key: GEOS-2815
URL: http://jira.codehaus.org/browse/GEOS-2815
Project: GeoServer
Issue Type: New Feature
Reporter: David Winslow
Assignee: David Winslow
Fix For
I have created a GSIP for this improvement. Open the feedback
floodgates!
http://geoserver.org/display/GEOS/GSIP+35+-+WMS+Decorations
--
David Winslow
OpenGeo - http://opengeo.org/
On Mon, 2009-03-23 at 11:22 -0400, David Winslow wrote:
> Hi all,
>
> For a project I'm working on, I would like
See http://hudson.opengeo.org/hudson/job/geoserver-1.7.x/812/changes
--
started
ERROR: svn: PROPFIND request failed on '/geoserver/branches/1.7.x/src'
svn: svn.codehaus.org
org.tmatesoft.svn.core.SVNException: svn: PROPFIND request failed on
'/geoserver/bra
Good stuff David. I looked over the proposal quickly and did a quick
code review and here is what i got:
* I wonder if the interface is better named MapDecoration, or
MapOverlay? Decoration seems a bit too abstract
* I notice the old package naming structure is being used in the
community modu
Hi all,
Most of the discussion in todays road map update revolved around
relaxing the "bug fix only" restrictions on 1.7.x. The rationale being
that there a number of funded features coming down the pipe from various
places.
So the first action item:
* Allow new features on 1.7.x which are a)
Greetings all. As you may or may not recall, GeoServer is revamping its
documentation! [1]
A few of us have been working to come up with the basic framework for the new
user guide (with the developers guide in progress as well). The new
documentation is being rendered using Sphinx [2], and wr
Thanks for the update.
> Issues that come to mind are:
>
> 1) Setting up a permanent repository for versioned docs.
> We discussed in the IRC meeting today [6] to have the docs possibly hosted
> at http://docs.geoserver.org/x.y.z
A question; is this a url to the published documentation (ie an
Hi Jody.
> A question; is this a url to the published documentation (ie an
> alternative to http://gridlock.openplans.org/geoserver/1.7.x/doc/user)
> or is it an svn repository for working on the docs?
I think docs.geoserver.org would probably be a link to the built docs (i.e.
gridlock). The so
Hi
I've been waiting for the basic app-schema capabilities to come on
line so I can test them, after that my priority will be working out
what to do with geomtryless - which relies on sql-datastore.
I'm wondering whether I will be able to completely deprecate the
geomtryless module by either:
a)
On Tue, 2009-03-31 at 15:01 -0600, Justin Deoliveira wrote:
> Good stuff David. I looked over the proposal quickly and did a quick
> code review and here is what i got:
>
> * I wonder if the interface is better named MapDecoration, or
> MapOverlay? Decoration seems a bit too abstract
My order o
>>
>> * I wonder if the interface is better named MapDecoration, or
>> MapOverlay? Decoration seems a bit too abstract
>
> My order of preference is Decoration > MapDecoration > MapOverlay. The
> Map prefix seems unnecessary since this is in the wms package. I am not
> planning to dig in my he
Justin Deoliveira wrote:
> I don't think this is actually a problem. I have seen DFT tests fail
> like this in the past and never found a reason why. I think it is just
> an issue with the wfs 1.0 tests, but something i have never isolated.
OK, so long as you are happy with them. My main concern
Gabriel Roldán wrote:
> I'll be giving a shot to app-schema support on trunk and am wondering if
> there's already any backend that supports SQL queries as the source of data,
> like we did with the SQLDataStore interface on the complex-features branch?
Gabriel, the only thing I know of is GeoTo
See http://hudson.opengeo.org/hudson/job/geoserver-1.7.x/813/changes
--
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lis
PropertyIsLike failure in CITE WFS 1.1 test
---
Key: GEOS-2816
URL: http://jira.codehaus.org/browse/GEOS-2816
Project: GeoServer
Issue Type: Bug
Components: WFS
Reporter: Ben Cara
> Works for me, but how do we deal with code that wants to throw a
> safeguard exception in the last else? The usual "there is a programing
> error, I don't know what this thing is" kind of exception.
I think that shows up as a null pointer exception; or a compile error
- since the visitor pattern
Justin,
I have completed CITE WFS 1.0 and 1.1 testing of these patches, as
documented below. The tests indicate that the patches do not cause any
additional test failures. Are you happy for me to commit these patches?
Kind regards,
Ben.
Original Message
Subject: [jira] Com
51 matches
Mail list logo
