Hi all,
First let me introduce myself. I'm Alex van den Hoogen and I'm currently
employed at Geodan in the Netherlands. Geodan is a GIS development company.
We make quite a lot of use of GeoServer and other open- and closed-source
GIS-products and we want to contribute to the open-source
Hi,I write to know if you develop a temporary layer, deleting after a fixed period.My idea is to create a layer and set the time to live for it, after this period I delete from Geoserver the layer and optionally the data from filesystem or database.If the user want to maintain the layer, he can
Hi devs,
I've just noticed that in my absence both users and dev mailing list
maintenance for post
originating from non subscribers went unattended (since the beginning of
September).
I am wondering, is there anyone around willing to help with ml maintenance?
Alternatively, shall we just
Title: Message Title
Nicola Lagomarsini created an issue
On Tue, Sep 9, 2014 at 11:03 AM, samanta.biasio...@sinergis.it wrote:
Hi,
I write to know if you develop a temporary layer, deleting after a fixed
period.
My idea is to create a layer and set the time to live for it, after this
period I delete from Geoserver the layer and optionally the
Hi Alex,
as Mauro said, the norm in GeoServer is to have a single commit per jira
ticket, with the commit message
referring to the ticket number/title.
Each fix need to have at least a test to go with it, and if you plan to
provide several fixes (which is great!)
please do sign and send the OSGeo
My question is related to the issue
https://jira.codehaus.org/browse/GEOS-6651 which ended up to be a user
error related to the bbox value. It seems that when version 1.3.0 bbox
coordinates are swapped, only some of the images are shown properly.
This seems to depend on the srs-value. For
On Wed, Sep 24, 2014 at 11:58 AM, Ville Karppinen ville.karppi...@fmi.fi
wrote:
My question is related to the issue
https://jira.codehaus.org/browse/GEOS-6651 which ended up to be a user
error related to the bbox value. It seems that when version 1.3.0 bbox
coordinates are swapped, only some
As suggested by Andrea and Mauro, I've resubmitted the issues in seperate
pull requests on Github.
Kind regards,
Alex van den Hoogen
-
*Geodan*
Buitenhaven 27-A
5211 TP 's-Hertogenbosch (NL)
www.geodan.nl
-
2014-09-24
Hi,
I would like to propose a new extension point that can be used to
generalize,
and make pluggable, the configuration of a FeatureTyeInfo into a data store,
for feature types that are configured as opposed to being native to the
store.
We have this situation already with SQL views, where the
Judging from some of the mails that have just arrived on the list users are
unaware that their messages aren't coming through so we should probably
bounce them with instructions on how to join the list.
In general I think it's a good thing for people to join the list so they
see replies to their
Hi Ville,
White map is not an error, BBOX just does not find any data. With these
parameters you will see something.
REQUEST=GetMap
SERVICE=WMS
VERSION=1.1.1
WIDTH=459
HEIGHT=346
LAYERS=vantaa_vrad
TRANSPARENT=TRUE
FORMAT=image%2Fpng
OK shall I just release GeoServer with the current release of GWC (1.5.3)
from July ? or the 1.6-RC?
Ian
On 23 September 2014 18:12, Kevin Smith ksm...@boundlessgeo.com wrote:
Sorry, I'll try to fit it in, but my bandwidth for this is constrained at
the moment.
On 23 September 2014 08:17,
I thought I'd have a go at addressing
https://jira.codehaus.org/browse/GEOS-5976 as a beginner's task in GeoServer
development. This is to add configuration and output of DataURL elements for
Layers in the WMS GetCapabilities response. I got some pointers from Ben
Caradoc-Davies as to which
A summary based on previous comments to give a clear idea of this issue:
Some layers which work OK with WMS 1.1.1 give an error with valid 1.3.0
requests.
EPSG:3067 is easting-northing system so there is no need to flip the
axis for 1.3.0 bbox.
Version 1.1.0 gives an image:
On Wed, Sep 24, 2014 at 2:02 PM, Ville Karppinen ville.karppi...@fmi.fi
wrote:
Version 1.3.0 gives an error, even if an image is expected (no need to
flip bbox, using CRS instead of SRS in URL):
Hi,
I made a test with Geoserver 2.6-RC1 by creating a new image mosaic from
scratch. I used two aerial images which are natively in EPSG:3067. The
resulting layer works without errors both through WMS 1.1.1 and WMS 1.3.0.
I would recommend to build the mosaic again by increasing it little by
Hey Ian. One issue Kevin ran into was the geotools artifacts not being
available in the maven repo. Have you run the geotools publish step yet?
On Wednesday, September 24, 2014, Ian Turton ijtur...@gmail.com wrote:
OK shall I just release GeoServer with the current release of GWC (1.5.3)
from
Whoops - I knew there was something I had to do this morning
I'll do it now
Ian
On 24 September 2014 14:39, Justin Deoliveira jdeol...@boundlessgeo.com
wrote:
Hey Ian. One issue Kevin ran into was the geotools artifacts not being
available in the maven repo. Have you run the geotools publish
Title: Message Title
Alex van den Hoogen created an issue
Thanks, Ian.
Releasing with 1.5.3 probably wouldn't work. There are changes in the 1.6
branch that that GS 2.6 depends on so it would just break things. As a
last resort, 1.6.0-RC1 would be a better choice.
My time Is still constrained but I think I should be able to complete the
process
Thanks Kevin
Is this mosaic issue that has come up a blocker for 2.6.0? from the sound
of it is serious but does it only affect Finland? :-)
Ian
On 24 September 2014 16:52, Kevin Smith ksm...@boundlessgeo.com wrote:
Thanks, Ian.
Releasing with 1.5.3 probably wouldn't work. There are
Ian, at some point we have to make a cut, otherwise we are going back to a
feature based release model, instead of a time boxed one.
Or alternatively, we may decide to jump over this one shift all our
programmed releases one month?
But honestly I don't like the idea one bit.
Cheers
Andrea
On
+1 from me.
I would like to move some of the REST API hacks from 2.6.x into
ResourcePool (so we manage datastore caches in a consistent fashion).
Actually with that in mind, and seeing you have a dispose() hook, I
recommend:
abstract class FeatureTypeHelper {
boolean canHandle(
On Wed, Sep 24, 2014 at 7:31 PM, Jody Garnett jody.garn...@gmail.com
wrote:
+1 from me.
I would like to move some of the REST API hacks from 2.6.x into
ResourcePool (so we manage datastore caches in a consistent fashion).
Actually with that in mind, and seeing you have a dispose() hook, I
On Wed, Sep 24, 2014 at 7:42 PM, Andrea Aime andrea.a...@geo-solutions.it
wrote:
My concern is FeatureTypeHelper would be used to manage additional
external HashMaps outside of ResourcePool.
Ah, to clarify, FeatureTypeInitializer is not meant to manage other
hashmaps (don't know which those
Thanks for the clarification Andrea - I only mentioned ResourcePool
HashMaps to introduce my concern about API abuse :)
Initializer or Callback) - but if we already use Initializer then lets
stick with that.
So the only useful feedback am left with is the difference between flush
and dispose. As
On Wed, Sep 24, 2014 at 8:04 PM, Jody Garnett jody.garn...@gmail.com
wrote:
Thanks for the clarification Andrea - I only mentioned ResourcePool
HashMaps to introduce my concern about API abuse :)
Initializer or Callback) - but if we already use Initializer then lets
stick with that.
I'm
Title: Message Title
Kristine created an issue
I don't seem to have permissions to deploy to the new maven repository.
Otherwise everything is built, tested, and ready to go. I'll ask Justin
about it when I see him tomorrow morning.
On 24 September 2014 10:04, Andrea Aime andrea.a...@geo-solutions.it
wrote:
Ian, at some point we have to
30 matches
Mail list logo
