Re: [Geoserver-users] Username not captured in the layer requests

2011-10-31 Thread Jeffrey Johnson
This is actually nothing specific to opengeo suite, but with the
monitoring community module. But after talking to Sheetal, I think the
problem lies in the fact that the geonode security module is being
used and not standard GeoServer security. We will take it up on the
geonode list.

Thanks.

Jeff

On Oct 31, 2011, at 19:08, Andrea Aime  wrote:

> On Mon, Oct 31, 2011 at 12:40 AM, Sheetal Gadkari
>  wrote:
>> Hi,
>>
>> I have got a problem in using the Geo-server analytics extracted from
>> http://suite.opengeo.org/builds/trunk/opengeosuite-ee-trunk-latest-analytics.zip
>>
>> I deployed the package successfully in Geo-server with Postgress database. 
>> Each layer request is successfully logged into the Request table. But 
>> looking into each row i noticed that the user name is not captured in the 
>> Request table. I need the user who access the layer for some reporting and 
>> financial purposes.
>>
>> Can you please advise on this problem?
>
> GeoServer does not have a "analytics" module, as far as I know that is
> an extension
> of the OpenGeo suite, so you should ask on the suite forums, not here
>
> Cheers
> Andrea
>
>
> --
> ---
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:  +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> ---
>
> --
> Get your Android app more play: Bring it to the BlackBerry PlayBook
> in minutes. BlackBerry App World™ now supports Android™ Apps
> for the BlackBerry® PlayBook™. Discover just how easy and simple
> it is! http://p.sf.net/sfu/android-dev2dev
> ___
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users


[Geoserver-users] Fwd: Constraints of requested bounding box and resolution?

2011-08-09 Thread Jeffrey Johnson
Forwarded from Ole Nielson on geonode-dev



Dear all,

We are developing an application for risk modelling based on spatial
data hosted in GeoServer and accessed through REST and OGC Services.


We came across what at first looked like precision issues in raster
resolutions when resolutions of downloaded data was different to what
was requested. This causes problems not just with our numerical
calculations but also for the integrity checks we have implemented
(e.g. that two layers have the same geo transform up to machine
precision).



However, a closer look reveals that it is probably more a matter of
what GeoServer does if asked for an impossible combination of bounding
box and grid resolution. The little study below would indicate that
the bounding box takes precedence and that resolution will be adjusted
from the requested resolution to something that is consistent.

Can someone please let us know if this assumption is correct and also
how to robustly compute consistent combinations of bounding
box/resolution so that the response from GeoServer is guaranteed to be
as requested?



Alternatively, what are your thoughts on changing the algorithm so
that the bounding box is changed to follow the grid point resolution
(I believe this is what is done in tools like Arc)?

Cheers and thanks
Ole

PS - I have attached a little Python program to assist with this study


--
Downloading using native parameters
--

Before uploading the file, gdalinfo reports

Origin = (122.5775001,2.0225000)
Pixel Size = (0.025,-0.025)

Corner Coordinates:
Upper Left  ( 122.5775000,   2.0225000) (122d34'39.00"E,  2d 1'21.00"N)
Lower Left  ( 122.5775000,  -2.0025000) (122d34'39.00"E,  2d 0'9.00"S)
Upper Right ( 126.6025000,   2.0225000) (126d36'9.00"E,  2d 1'21.00"N)
Lower Right ( 126.6025000,  -2.0025000) (126d36'9.00"E,  2d 0'9.00"S)
Center  ( 124.590,   0.010) (124d35'24.00"E,  0d 0'36.00"N)


Downloading with REST using the exact same parameters
curl 
"http://localhost:8001/geoserver-geonode-dev/ows?version=1.0.0&service=wcs&request=getcoverage&format=GeoTIFF&store=false&coverage=shakemap_20110505155015&crs=EPSG:4326&bbox=122.5775,-2.0025,126.6025,2.0225&resx=0.0250&resy=0.0250";
> dnld.tif

gdalinfo reports the exact same numbers as expected.


--
Downloading with adjusted bounding box
--

However, if I change the bounding box slightly (western boundary from
122.5775 to 122.58) and download again with the revised command:

curl 
"http://localhost:8001/geoserver-geonode-dev/ows?version=1.0.0&service=wcs&request=getcoverage&format=GeoTIFF&store=false&coverage=shakemap_20110505155015&crs=EPSG:4326&bbox=122.58,-2.0025,126.6025,2.0225&resx=0.0250&resy=0.0250";
> dnld.tif

gdalinfo reports resolution values adjusted for the change in bounding box:

Origin = (122.578,2.0225000)
Pixel Size = (0.024984472049690,-0.025)

Corner Coordinates:
Upper Left  ( 122.580,   2.0225000) (122d34'48.00"E,  2d 1'21.00"N)
Lower Left  ( 122.580,  -2.0025000) (122d34'48.00"E,  2d 0'9.00"S)
Upper Right ( 126.6025000,   2.0225000) (126d36'9.00"E,  2d 1'21.00"N)
Lower Right ( 126.6025000,  -2.0025000) (126d36'9.00"E,  2d 0'9.00"S)
Center  ( 124.5912500,   0.010) (124d35'28.50"E,  0d 0'36.00"N)

So instead of the requested 0.025 we get 0.02498447204969

-
Downloading with adjusted resolution
-

Similarly, and this is what triggered this question, if I change the
resolution slightly (from 0.025 to 0.03) but keep the original
bounding box and download with the command

curl 
"http://localhost:8001/geoserver-geonode-dev/ows?version=1.0.0&service=wcs&request=getcoverage&format=GeoTIFF&store=false&coverage=shakemap_20110505155015&crs=EPSG:4326&bbox=122.5775,-2.0025,126.6025,2.0225&resx=0.0300&resy=0.0300";
> dnld.tif

gdal info reports

Origin = (122.5775001,2.0225000)
Pixel Size = (0.030037313432836,-0.030037313432836)

Corner Coordinates:
Upper Left  ( 122.5775000,   2.0225000) (122d34'39.00"E,  2d 1'21.00"N)
Lower Left  ( 122.5775000,  -2.0025000) (122d34'39.00"E,  2d 0'9.00"S)
Upper Right ( 126.6025000,   2.0225000) (126d36'9.00"E,  2d 1'21.00"N)
Lower Right ( 126.6025000,  -2.0025000) (126d36'9.00"E,  2d 0'9.00"S)
Center  ( 124.590,   0.010) (124d35'24.00"E,  0d 0'36.00"N)

So instead of the requested 0.03 we get 0.030037313432836
"""Script to investigate relationship between specified bounding box and resolution in geoserver downloads via the REST interface.
"""

import os

bounding_box = [122.580, -2.0025

[Geoserver-users] Problems with 'compatible' projections?

2011-04-01 Thread Jeffrey Johnson
Hi All,

Can anyone shed some light on what the following error indicates when
requesting a coverage via WCS in a projection different than the
coverages original projection? Im not sure what 'compatible' or
TargetGG means in this context.

"Illegal value for argument "TargetCRS must be compatible with TargetGG CRS"

The source layer is in EPSG:28356 and I am trying to request it in EPSG:32756

gdalwarp has no trouble at all converting between the two if I request
in the native and use -t_srs for the target.

Thanks,

Jeff

--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users