Re: [Geoserver-users] Links from WMS - Solved

[Jair Santos]

Thank you Jukka,

 

This is the solution I was looking for. Very simple and effective. It worked
smoothly.

 

Cheers.

 

JJ.

 

From: Rahkonen Jukka (MML) [mailto:jukka.rahko...@maanmittauslaitos.fi] 
Sent: Tuesday, November 17, 2015 1:47 AM
To: Jair Santos ; 'GeoServer Mailing List List'

Subject: Re: [Geoserver-users] Links from WMS

 

Hi,

 

We have saved links as well as some other formatting like line breaks into a
text field of a database table as html-formatted strings. At least that
works with Mapserver but why not with Geoserver as well. You will see a link
if you click a red fishing restriction area in
http://www.paikkatietoikkuna.fi/web/en/map-window?ver=1.17

=10=413832.469_6948702.876=base_35+100+default,137
3+100+default&=true

 

The link is saved into the database as

http://www.ely-keskus.fi/pohjois-savo
target=_blank>www.ely-keskus.fi/pohjois-savo
 

 

The referred site is under a DOS attack just now and the link does not show
anything but normally it works.

 

-Jukka Rahkonen-

 

 

 

Jair Santos wrote:

 

Hello all,

 

I am requesting information from Geoserver in a popup overlay using WMS as
source for a 

 

http://192.168.1.111:8080/geoserver/wms?SERVICE=WMS

=1.3.0=GetFeatureInfo=image%2Fpng=true
ERY_LAYERS=bmid_reserv=bmid_reserv_FORMAT=text%2Fhtml=228=20
6=256=256=EPSG%3A3857==-13284144.019737352%2C64
30800.063688448%2C-13283838.271624211%2C6431105.811801588

 

Parts of the information are links to pdf documents, so the user can
download them from the popup. The data is coming from Postgres that do not
support links as datatypes and Geoserver sends the information as plain
text. Is there a way that geoserver can provide them as links?

 

info_reservoir = wms_bmid_reservoir.getGetFeatureInfoUrl(
evt.coordinate, viewResolution, 'EPSG:3857',
{ 'INFO_FORMAT': 'text/html' })
content.innerHTML = '';
overlay.setPosition(coordinate);

 

Thanks in advance for any ideas.

 

JJ.

 

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

[Geoserver-users] Transparent ExternalGraphic as Polygon fill

[Ian Turton]

Can anyone say if GeoServer honours the Opacity setting for an
externalgraphic composed of a png image (with transparent background)? I'm
sure I've done this in the past but I can't find the SLD file anywhere.

Currently I have:


   
   
 
   
 
 image/png
   
   0.5
 
 
   


Which is (apparently) valid according to the SLD editor (and my reading of
the spec) but definitely doesn't make a transparent fill.


Cheers
Ian
-- 
Ian Turton
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] *****SPAM***** gs:Unique performance over HTTP GET

[Ben Caradoc-Davies]

On 18/11/15 22:54, Andrea Aime wrote:
> On Tue, Nov 17, 2015 at 4:27 PM, César Augusto Ribeiro 
> wrote:
>> (Why spam?)
> Don't know, the server of our mail provider adds it automatically...

Looks like SpamAssassin, which adds this string to enable client-side 
filtering, running on the mail server. In addition to dubious senders 
and mail servers, SpamAssassin can also detect spam based on content. I 
suggest that words like "unique", "performance", and "neighborhood" in 
close proximity might look like spam. I have seen a beef jerky recipe 
that could not be delivered because it contained the word "meat" many 
times in close proximity (blocked by IronPort in that case). Our robot 
overlords never sleep.

Kind regards,

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

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

[Geoserver-users] GeoServer's spatial filter preventing SQL view layer from working

[cheesybiscuits]

I've created a function within Oracle for on-the-fly clustering that I hoped
to query via GeoServer using an SQL view layer.

The function takes as its arguments the bounding box and the number of grid
cells to use in a basic gridded clustering process (i.e. find the centre of
mass for points within each grid cell). Please note I've tried the Point
Stacker extension and it isn't adequate for my needs. Executing the
following query within Oracle gives the list of sdo_geometry objects that I
expect:

select * from table(package_name.function_name(-180, -90, 180, 90, 3);

My intention is to make WMS requests to GeoServer with the viewparams
parameter included that provides all required arguments. Because of the way
the function works the returned sdo_geometry objects will only ever be
within the provided bounding box.

I can successfully create an SQL view layer within GeoServer using this
syntax and everything seems OK while publishing. However when I access the
layer everything falls apart. GeoServer takes my query and wraps it as
follows:

SELECT GEOMETRY as GEOMETRY FROM (select * from
table(package_name.function_name(-180, -90, 180, 90, 3))) VTABLE WHERE 
SDO_FILTER(GEOMETRY, ?, 'mask=anyinteract querytype=WINDOW') = 'TRUE'

Oracle then errors because the function's table return type doesn't have a
spatial index to use with SDO_FILTER. Although I did find a  somewhat
similar problem on GIS.SE

  
the same solution does not apply as my function returns a table, not a
single object, and Oracle doesn't permit indexes on named table types.

As things currently stand I don't think I can make this work, and the only
thing that could potentially help is to prevent GeoServer from appending its
SDO_FILTER mask. However I'm guessing this just isn't possible without
digging into the source and creating a custom build (totally not an option).

Can anyone tell me if there's something I've missed here, or suggest a
different approach for solving the same problem? Any thoughts would be very
much appreciated.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/GeoServer-s-spatial-filter-preventing-SQL-view-layer-from-working-tp5237269.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

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

Re: [Geoserver-users] GeoServer Migration Plan

[David Alda Fernandez de Lezea]

Hi,

Ticket created:

https://osgeo-org.atlassian.net/browse/GEOS-7317

Thanks Andrea.

Regards,

Agur bero bat,



David Alda Fernández de Lezea
Área de Sistemas de Información Geográfica, Planificación Territorial y 
Forestal Informazio Geografikoen Sistemak, Lurralde eta Baso Antolaketaren 
Arloa.
da...@hazi.eus | www.hazi.eus
T 945 003 240 – M 627 923 170 – F 945 003 290 
Hazi | Granja Modelo de Arkaute s/n | 01192 Arkaute – Araba
 
*  LEGE OHARRA   ***   AVISOLEGAL   
***   DISCLAIMER   *
Mezu hau pertsonala eta isilpekoa da eta baimenik gabeko erabilera debekatua 
dago legalki. Jasotzailea ez bazara ezabatu mezua, bidali eta kontserbatu gabe.
Este mensaje es personal y confidencial y su uso no autorizado está prohibido 
legalmente. Si usted no es el destinatario, proceda a borrarlo, sin reenviarlo 
ni conservarlo.
This message is personal and confidential, unauthorised use is legally 
prohibited. If you are not the intended recipient, delete it without resending 
or backing it.

De: andrea.a...@gmail.com [mailto:andrea.a...@gmail.com] En nombre de Andrea 
Aime
Enviado el: miércoles, 18 de noviembre de 2015 10:59
Para: David Alda Fernandez de Lezea
CC: GeoServer Users
Asunto: Re: [Geoserver-users] GeoServer Migration Plan

Hi David,
nope, no clue as to why you're hitting that class, the XML seems "normal".
But I guess it does not hurt adding it to the whitelist.
Can you open a ticket at https://osgeo-org.atlassian.net/projects/GEOS/summary 
with
the stack trace above?

Cheers
Andrea


On Mon, Nov 16, 2015 at 9:19 AM, David Alda Fernandez de Lezea  
wrote:
Hi Andrea,

Thanks for your response. Here's what's inside the xml files:

Layer.xml


  ForriskAlturaMediaEtrs89
  LayerInfoImpl-3f30cbbb:14d7ae3d4ba:-6323
  VECTOR
  
    StyleInfoImpl-4e0b98bf:12475d46fdd:-7fe0
  
  
    
      StyleInfoImpl-38e82ce1:14cd58a4153:-75bf
    
  
  
    FeatureTypeInfoImpl-3f30cbbb:14d7ae3d4ba:-6324
  
  
    0
    0
  



Featuretype.xml


  FeatureTypeInfoImpl-3f30cbbb:14d7ae3d4ba:-6324
  ForriskAlturaMediaEtrs89
  TB_RIESGO_INC_VIENTO_ET89
  
    NamespaceInfoImpl-2828037a:14d74b05c20:-775b
  
  Forrisk - Altura Media (m)
  TB_RIESGO_INC_VIENTO_ET89
  PROJCS[UTM Zone 30, (ETRS 89), 
  GEOGCS[ETRS 89, 
    DATUM[ETRS 89, 
      SPHEROID[GRS 80, 6378137.0, 298.257222100883]], 
    PRIMEM[Greenwich, 0.0], 
    UNIT[degree, 0.017453292519943295], 
    AXIS[Longitude, EAST], 
    AXIS[Latitude, NORTH]], 
  PROJECTION[Transverse_Mercator], 
  PARAMETER[central_meridian, -3.0], 
  PARAMETER[latitude_of_origin, 0.0], 
  PARAMETER[scale_factor, 0.9996], 
  PARAMETER[false_easting, 50.0], 
  PARAMETER[false_northing, 0.0], 
  UNIT[m, 1.0], 
  AXIS[x, EAST], 
  AXIS[y, NORTH]]
  EPSG:25830
  
    463435.23
    603054.68
    4702205.332
    4811327.358
  
  
    -3.452
    -1.726
    42.465
    43.455
    EPSG:4326
  
  FORCE_DECLARED
  true
  
    false
  
  
    DataStoreInfoImpl-2828037a:14d74b05c20:-775a
  
  0
  0
  false
  false
  false



Regards,


Agur bero bat,



David Alda Fernández de Lezea
Área de Sistemas de Información Geográfica, Planificación Territorial y 
Forestal Informazio Geografikoen Sistemak, Lurralde eta Baso Antolaketaren 
Arloa.
da...@hazi.eus | www.hazi.eus
T 945 003 240 – M 627 923 170 – F 945 003 290
Hazi | Granja Modelo de Arkaute s/n | 01192 Arkaute – Araba
 
*  LEGE OHARRA   ***   AVISOLEGAL   
***   DISCLAIMER   *
Mezu hau pertsonala eta isilpekoa da eta baimenik gabeko erabilera debekatua 
dago legalki. Jasotzailea ez bazara ezabatu mezua, bidali eta kontserbatu gabe.
Este mensaje es personal y confidencial y su uso no autorizado está prohibido 
legalmente. Si usted no es el destinatario, proceda a borrarlo, sin reenviarlo 
ni conservarlo.
This message is personal and confidential, unauthorised use is legally 
prohibited. If you are not the intended recipient, delete it without resending 
or backing it.

De: andrea.a...@gmail.com [mailto:andrea.a...@gmail.com] En nombre de Andrea 
Aime
Enviado el: sábado, 14 de noviembre de 2015 14:01
Para: David Alda Fernandez de Lezea
CC: GeoServer Users
Asunto: Re: [Geoserver-users] GeoServer Migration Plan
On Wed, Nov 11, 2015 at 11:21 AM, David Alda Fernandez de Lezea 
 wrote:
11 Nov 11:14:46 WARN [org.geoserver] - Failed to load layer for feature type 
'ForriskAlturaMediaEtrs89'
com.thoughtworks.xstream.converters.ConversionException: Unauthorized class 
found, see logs for more details on how to handle it: 
com.thoughtworks.xstream.mapper.DynamicProxyMapper$DynamicProxy : Unauthorized 
class found, see logs for more details on how to handle it: 
com.thoughtworks.xstream.mapper.DynamicProxyMapper$DynamicProxy

This one is a side effect of our hardening against remote execution attacks, 
which allowed people with
access to the REST api (admins) to 

[Geoserver-users] GetFeature (WFS1.1.0) returns MultiCurve instead of MultiLineString

[Dominik Gärner]

Hi,
upgrading Geoserver from 2.7.3 to 2.8.0 results in some changes in the response 
of WFS (1.1.0) GetFeature requests. I have a normal Shape source with geometry 
type MultiLineString. In Geoserver 2.7.3 (and earlier) GetFeature und 
DescribeFeature returns MultiLineString to this layer. In the newer version 
2.8.0 the GetFeature returns a MultiCurve (even though the layer itself and 
DescribeFeature is still telling MultiLineString).

Is this a bug or is there a reason for it? Can I change this behaviour (my 
application connected to Geoserver can't handle MultiCurves)?

Best Regards
Dominik


--

Dominik Gärner
GRINTEC GmbH
Anzengrubergasse 6, 8010 Graz, Austria
Tel: +43(316)383706-0
mailto:dominik.gaer...@grintec.com
http://www.grintec.com

FN 47845k Handelsgericht Graz
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] *****SPAM***** gs:Unique performance over HTTP GET

[Andrea Aime]

On Tue, Nov 17, 2015 at 4:27 PM, César Augusto Ribeiro 
wrote:

> (Why spam?)
>

Don't know, the server of our mail provider adds it automatically...


>
> Hey Andrea,
>
> I need to do these requests in an javascript application. I suppose I
> can't rely on request builder to do it, I'm I wrong?
>

You're not


> I understand that OGC dropped support, so the recommended way is to build
> the "xml" in my application and then POST it somehow?
>

Yes


>
> Do you believe it would have any performance gain?
>

Honestly I don't know, but the request builder actually does a local HTTP
POST request, so, if it's fast,
that might be involved

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

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

Re: [Geoserver-users] Layer Preview

[Julian Hollingbery]

Hi Pedro,

Check the geoserver log to see if there are any errors.
If not, make sure that the bounding box used by the preview (check the actual 
URL) contains actual data. If it does, verify that you can use one of the 
default styles (point, poly or line).

/julian

-Oprindelig meddelelse-
Fra: Pedro [mailto:pedro.fe...@gmail.com] 
Sendt: 17. november 2015 16:19
Til: geoserver-users@lists.sourceforge.net
Emne: Re: [Geoserver-users] Layer Preview

Well it seems that my problem in Layer Preview is now different

Layer Preview any of the preloaded data in OpenLayers and I just get a blank 
map.

Any thoughts?


Thanks
Pedro 



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Layer-Preview-tp5236856p5236903.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

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

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

Re: [Geoserver-users] GetFeature (WFS1.1.0) returns MultiCurve instead of MultiLineString

[Rahkonen Jukka (MML)]

Hi,

I would read this 
http://docs.geoserver.org/stable/en/user/services/wfs/schemamapping.html
and then try something like


MultiSurface is what GML 3 most often uses and I suggest to file a feature 
request for your application about that. However, mismatch between 
DescribeFeatureType and GetFeature may be a bug in Geoserver 2.8 but I am not 
sure. MultiCurve with just linear members is the same as MultiLineString but I 
can't say if client that is prepared to receive MultiLineStrings but is getting 
those enclosed inside MultiCurves has good enough reason for throwing an error.

-Jukka Rahkonen-


Dominik Gärner wrote:

Hi,
upgrading Geoserver from 2.7.3 to 2.8.0 results in some changes in the response 
of WFS (1.1.0) GetFeature requests. I have a normal Shape source with geometry 
type MultiLineString. In Geoserver 2.7.3 (and earlier) GetFeature und 
DescribeFeature returns MultiLineString to this layer. In the newer version 
2.8.0 the GetFeature returns a MultiCurve (even though the layer itself and 
DescribeFeature is still telling MultiLineString).

Is this a bug or is there a reason for it? Can I change this behaviour (my 
application connected to Geoserver can't handle MultiCurves)?

Best Regards
Dominik


--

Dominik Gärner
GRINTEC GmbH
Anzengrubergasse 6, 8010 Graz, Austria
Tel: +43(316)383706-0
mailto:dominik.gaer...@grintec.com
http://www.grintec.com

FN 47845k Handelsgericht Graz
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GetFeature (WFS1.1.0) returns MultiCurve instead of MultiLineString

[Stefano Iacovella]

Ciao Dominik,

I am just trying it with 2.7.3
I receive a MultiLineString with GML 3.1 or GML 2, but the same features
are returned as MultiCurve if I ask it for GML 3.2
What GML version is your response?

Cheers,

Stefano

---
41.95581N 12.52854E


http://www.linkedin.com/in/stefanoiacovella

http://twitter.com/#!/Iacovellas

2015-11-18 9:21 GMT+01:00 Dominik Gärner :

> Hi,
>
> upgrading Geoserver from 2.7.3 to 2.8.0 results in some changes in the
> response of WFS (1.1.0) GetFeature requests. I have a normal Shape source
> with geometry type MultiLineString. In Geoserver 2.7.3 (and earlier)
> GetFeature und DescribeFeature returns MultiLineString to this layer. In
> the newer version 2.8.0 the GetFeature returns a MultiCurve (even though
> the layer itself and DescribeFeature is still telling MultiLineString).
>
>
>
> Is this a bug or is there a reason for it? Can I change this behaviour (my
> application connected to Geoserver can’t handle MultiCurves)?
>
>
>
> Best Regards
>
> Dominik
>
>
>
> --
>
> Dominik Gärner
> GRINTEC GmbH
> Anzengrubergasse 6, 8010 Graz, Austria
> Tel: +43(316)383706-0
> mailto:dominik.gaer...@grintec.com
> http://www.grintec.com
>
> FN 47845k Handelsgericht Graz
>
>
> --
>
> ___
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GeoServer Migration Plan

[Andrea Aime]

Hi David,
nope, no clue as to why you're hitting that class, the XML seems "normal".
But I guess it does not hurt adding it to the whitelist.
Can you open a ticket at
https://osgeo-org.atlassian.net/projects/GEOS/summary with
the stack trace above?

Cheers
Andrea


On Mon, Nov 16, 2015 at 9:19 AM, David Alda Fernandez de Lezea <
da...@hazi.eus> wrote:

> Hi Andrea,
>
> Thanks for your response. Here's what's inside the xml files:
>
> Layer.xml
>
> 
>   ForriskAlturaMediaEtrs89
>   LayerInfoImpl-3f30cbbb:14d7ae3d4ba:-6323
>   VECTOR
>   
> StyleInfoImpl-4e0b98bf:12475d46fdd:-7fe0
>   
>   
> 
>   StyleInfoImpl-38e82ce1:14cd58a4153:-75bf
> 
>   
>   
> FeatureTypeInfoImpl-3f30cbbb:14d7ae3d4ba:-6324
>   
>   
> 0
> 0
>   
> 
>
>
> Featuretype.xml
>
> 
>   FeatureTypeInfoImpl-3f30cbbb:14d7ae3d4ba:-6324
>   ForriskAlturaMediaEtrs89
>   TB_RIESGO_INC_VIENTO_ET89
>   
> NamespaceInfoImpl-2828037a:14d74b05c20:-775b
>   
>   Forrisk - Altura Media (m)
>   TB_RIESGO_INC_VIENTO_ET89
>   PROJCS[UTM Zone 30, (ETRS 89),
> 
>   GEOGCS[ETRS 89, 
> DATUM[ETRS 89, 
>   SPHEROID[GRS 80, 6378137.0, 298.257222100883]], 
> PRIMEM[Greenwich, 0.0], 
> UNIT[degree, 0.017453292519943295], 
> AXIS[Longitude, EAST], 
> AXIS[Latitude, NORTH]], 
>   PROJECTION[Transverse_Mercator], 
>   PARAMETER[central_meridian, -3.0], 
>   PARAMETER[latitude_of_origin, 0.0], 
>   PARAMETER[scale_factor, 0.9996], 
>   PARAMETER[false_easting, 50.0], 
>   PARAMETER[false_northing, 0.0], 
>   UNIT[m, 1.0], 
>   AXIS[x, EAST], 
>   AXIS[y, NORTH]]
>   EPSG:25830
>   
> 463435.23
> 603054.68
> 4702205.332
> 4811327.358
>   
>   
> -3.452
> -1.726
> 42.465
> 43.455
> EPSG:4326
>   
>   FORCE_DECLARED
>   true
>   
> false
>   
>   
> DataStoreInfoImpl-2828037a:14d74b05c20:-775a
>   
>   0
>   0
>   false
>   false
>   false
> 
>
>
> Regards,
>
>
> Agur bero bat,
>
>
>
> David Alda Fernández de Lezea
> Área de Sistemas de Información Geográfica, Planificación Territorial y
> Forestal Informazio Geografikoen Sistemak, Lurralde eta Baso Antolaketaren
> Arloa.
> da...@hazi.eus | www.hazi.eus
> T 945 003 240 – M 627 923 170 – F 945 003 290
> Hazi | Granja Modelo de Arkaute s/n | 01192 Arkaute – Araba
>
> *  LEGE OHARRA   ***   AVISOLEGAL
> ***   DISCLAIMER   *
> Mezu hau pertsonala eta isilpekoa da eta baimenik gabeko erabilera
> debekatua dago legalki. Jasotzailea ez bazara ezabatu mezua, bidali eta
> kontserbatu gabe.
> Este mensaje es personal y confidencial y su uso no autorizado está
> prohibido legalmente. Si usted no es el destinatario, proceda a borrarlo,
> sin reenviarlo ni conservarlo.
> This message is personal and confidential, unauthorised use is legally
> prohibited. If you are not the intended recipient, delete it without
> resending or backing it.
>
> De: andrea.a...@gmail.com [mailto:andrea.a...@gmail.com] En nombre de
> Andrea Aime
> Enviado el: sábado, 14 de noviembre de 2015 14:01
> Para: David Alda Fernandez de Lezea
> CC: GeoServer Users
> Asunto: Re: [Geoserver-users] GeoServer Migration Plan
>
> On Wed, Nov 11, 2015 at 11:21 AM, David Alda Fernandez de Lezea
>  wrote:
> 11 Nov 11:14:46 WARN [org.geoserver] - Failed to load layer for feature
> type 'ForriskAlturaMediaEtrs89'
> com.thoughtworks.xstream.converters.ConversionException: Unauthorized
> class found, see logs for more details on how to handle it:
> com.thoughtworks.xstream.mapper.DynamicProxyMapper$DynamicProxy :
> Unauthorized class found, see logs for more details on how to handle it:
> com.thoughtworks.xstream.mapper.DynamicProxyMapper$DynamicProxy
>
> This one is a side effect of our hardening against remote execution
> attacks, which allowed people with
> access to the REST api (admins) to launch a random executable on the
> machine running GeoServer.
> We basically had to provide a white-list of files that can be
> de-serialized from XML.
>
> This one, com.thoughtworks.xstream.mapper.DynamicProxyMapper$DynamicProxy,
> is new and unexpected.
> Can you share what's in the ForriskAlturaMediaEtrs89 configuration files?
> It will be in a path like:
>
>
> /workspaces///ForriskAlturaMediaEtrs89/*.xml
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> 

Re: [Geoserver-users] Geoserver create coverage via rest api

[David Haynes II]

Hi Brad,

Hope this helps clear things up

/workspaces//coveragestores//coverages/
workspacename  = GLI_CEREAL
coveragestore  = BARLEYHAR
coverage  = BARLEYHAR

I successfully created a image mosaic jdb coveragestore by posting an xml
at url1
url1:
http://geoserver.terrapop.org/geoserver/rest/workspaces/GLI_CEREAL/coveragestores/

This resulted in a successful coveragestore at the following address, url2.
However, no coverage/layer was automatically published from this
coveragestore. So I am looking for an example of creating the coverage from
the coveragestore I believe.
url2:
http://geoserver.terrapop.org/geoserver/rest/workspaces/GLI_CEREAL/coveragestores/BARLEYHAR

Also, I tried posting a coverage.xml to this new url and received a 403
error
http://geoserver.terrapop.org/geoserver/rest/workspaces/GLI_CEREAL/coveragestores/BARLEYHAR/coverages

On Tue, Nov 17, 2015 at 11:01 PM, Brad Hards  wrote:

> On Tue, 17 Nov 2015 04:34:05 PM David Haynes II wrote:
> > I tried posting to an xml to this url
> > "/workspaces//coveragestores//coverages/" and received a 401
> > error.
> Can you say what you are really posting? What are ,  and  here?
> Also, can you confirm that that isn't the full URL (i.e. you really did
> put a
> machine name and protocol to the URL)?
>
> What is the data type you are trying to upload?
>
> What user are you trying to upload as?
>
> Brad
>
>
> --
> ___
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>



-- 
David Haynes, Ph.D.
Research Associate Terra Populus
Minnesota Population Center
612-626-3933
www.terrapop.org
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Exposing NETCDF files as Image Mosaic accross a time index

[Ferguson, Steve -FS]

Greetings,


I have been attempting to create an image mosaic for NETCDF files like this one 
(http://54.183.9.182/wff_153080300.nc) that I want to index by the time 
dimension in order to add additional forecast files as they become available. I 
am using the 2.9 SNAPSHOT version from 11/17 for all components.

I have tried to simply specify the directory within which this file sits as an 
image mosaic store, but this results in the following error :

19 Nov 01:01:54 WARN [netcdf.NetCDFGeoreferenceManager] - Unsupported axis: 
double lat(y=299, x=399);
  :units = "degrees_north";
  :long_name = "latitude";
  :standard_name = "latitude";
  :_CoordinateAxisType = "Lat";
in input: /gdata2/netcf/wff/wff_153080300.nc has been found
19 Nov 01:01:54 WARN [netcdf.NetCDFGeoreferenceManager] - Unsupported axis: 
double lon(y=299, x=399);
  :units = "degrees_east";
  :long_name = "longitude";
  :standard_name = "longitude";
  :_CoordinateAxisType = "Lon";
in input: /gdata2/netcf/wff/wff_153080300.nc has been found
19 Nov 01:03:28 ERROR [imagemosaic.Utils] -
java.lang.NullPointerException
19 Nov 01:03:28 WARN [gce.imagemosaic] - Failure occurred while collecting the 
granules
org.apache.commons.io.DirectoryWalker$CancelException: Operation Cancelled
at 
org.apache.commons.io.DirectoryWalker.checkIfCancelled(DirectoryWalker.java:395)
at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:368)
at org.apache.commons.io.DirectoryWalker.walk(DirectoryWalker.java:335)
at 
org.geotools.gce.imagemosaic.ImageMosaicDirectoryWalker$MosaicDirectoryWalker.(ImageMosaicDirectoryWalker.java:114)
at 
org.geotools.gce.imagemosaic.ImageMosaicDirectoryWalker.run(ImageMosaicDirectoryWalker.java:196)
at org.geotools.gce.imagemosaic.Utils.createMosaic(Utils.java:360)
at org.geotools.gce.imagemosaic.Utils.checkSource(Utils.java:1250)
at 
org.geotools.gce.imagemosaic.ImageMosaicReader.initReaderFromURL(ImageMosaicReader.java:519)
at 
org.geotools.gce.imagemosaic.ImageMosaicReader.(ImageMosaicReader.java:471)
at 
org.geotools.gce.imagemosaic.ImageMosaicFormat.getReader(ImageMosaicFormat.java:483)
at 
org.geotools.gce.imagemosaic.ImageMosaicFormat.getReader(ImageMosaicFormat.java:103)
at 
org.geoserver.catalog.ResourcePool.getGridCoverageReader(ResourcePool.java:1441)
at 
org.geoserver.catalog.ResourcePool.getGridCoverageReader(ResourcePool.java:1369)
at 
org.geoserver.catalog.impl.CoverageStoreInfoImpl.getGridCoverageReader(CoverageStoreInfoImpl.java:59)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.geoserver.catalog.impl.ModificationProxy.invoke(ModificationProxy.java:146)
at com.sun.proxy.$Proxy53.getGridCoverageReader(Unknown Source)
at 
org.geoserver.web.data.layer.NewLayerPageProvider.getItemsInternal(NewLayerPageProvider.java:90)
at 
org.geoserver.web.data.layer.NewLayerPageProvider.getItems(NewLayerPageProvider.java:59)
at 
org.geoserver.web.wicket.GeoServerDataProvider.fullSize(GeoServerDataProvider.java:245)



I have tried to specify properties to the indexer in indexer.properties as 
outlined here 
(http://geoserver.geo-solutions.it/multidim/en/imagemosaic/index.html) but that 
produces the following error:

19 Nov 01:12:16 WARN [netcdf.NetCDFGeoreferenceManager] - Unsupported axis: 
double lat(y=299, x=399);
  :units = "degrees_north";
  :long_name = "latitude";
  :standard_name = "latitude";
  :_CoordinateAxisType = "Lat";
in input: /gdata2/netcf/wff/wff_153080300.nc has been found
19 Nov 01:12:16 WARN [netcdf.NetCDFGeoreferenceManager] - Unsupported axis: 
double lon(y=299, x=399);
  :units = "degrees_east";
  :long_name = "longitude";
  :standard_name = "longitude";
  :_CoordinateAxisType = "Lon";
in input: /gdata2/netcf/wff/wff_153080300.nc has been found
19 Nov 01:12:18 WARN [imagemosaic.catalog] - This granule catalog was not 
properly dispose as it still points to:ServiceInfo
description=Features from ShapefileDataStore
19 Nov 01:13:49 ERROR [imagemosaic.Utils] - Invalid mosaic schema 
SimpleFeatureTypeImpl cloud identified extends 
Feature(x:x,y:y,lat:lat,lon:lon,surface_temperature:surface_temperature,surface_dewpoint:surface_dewpoint,surface_rh:surface_rh,surface_wind_speed:surface_wind_speed,surface_wind_direction:surface_wind_direction,mixing_height:mixing_height,lifted_index:lifted_index,haines_middle:haines_middle,haines_high:haines_high,ventilation_index:ventilation_index,cloud:cloud,precipitation:precipitation,z:z,height:height,temperature:temperature,relative_humidity:relative_humidity,wind_speed:wind_speed,wind_direction:wind_direction,time:time),
 it should have a geometry 

Re: [Geoserver-users] GeoServer's spatial filter preventing SQL view layer from working

[Martin Davis]

I think this is the same issue discussed in this (lengthy) thread:

http://osgeo-org.1560.x6.nabble.com/Reducing-query-data-size-in-Oracle-td5192620.html

TLDR: not possible right now, apparently requires clever development to
make it work.

If there has been improvement on this front it would be great to know about
it.  Or would be great to have someone implement a workaround!

On Wed, Nov 18, 2015 at 12:08 PM, cheesybiscuits 
wrote:

> I've created a function within Oracle for on-the-fly clustering that I
> hoped
> to query via GeoServer using an SQL view layer.
>
> The function takes as its arguments the bounding box and the number of grid
> cells to use in a basic gridded clustering process (i.e. find the centre of
> mass for points within each grid cell). Please note I've tried the Point
> Stacker extension and it isn't adequate for my needs. Executing the
> following query within Oracle gives the list of sdo_geometry objects that I
> expect:
>
> select * from table(package_name.function_name(-180, -90, 180, 90, 3);
>
> My intention is to make WMS requests to GeoServer with the viewparams
> parameter included that provides all required arguments. Because of the way
> the function works the returned sdo_geometry objects will only ever be
> within the provided bounding box.
>
> I can successfully create an SQL view layer within GeoServer using this
> syntax and everything seems OK while publishing. However when I access the
> layer everything falls apart. GeoServer takes my query and wraps it as
> follows:
>
> SELECT GEOMETRY as GEOMETRY FROM (select * from
> table(package_name.function_name(-180, -90, 180, 90, 3))) VTABLE WHERE
> SDO_FILTER(GEOMETRY, ?, 'mask=anyinteract querytype=WINDOW') = 'TRUE'
>
> Oracle then errors because the function's table return type doesn't have a
> spatial index to use with SDO_FILTER. Although I did find a  somewhat
> similar problem on GIS.SE
> <
> http://gis.stackexchange.com/questions/92554/can-i-create-an-oracle-spatial-view-from-a-non-spatial-table
> >
> the same solution does not apply as my function returns a table, not a
> single object, and Oracle doesn't permit indexes on named table types.
>
> As things currently stand I don't think I can make this work, and the only
> thing that could potentially help is to prevent GeoServer from appending
> its
> SDO_FILTER mask. However I'm guessing this just isn't possible without
> digging into the source and creating a custom build (totally not an
> option).
>
> Can anyone tell me if there's something I've missed here, or suggest a
> different approach for solving the same problem? Any thoughts would be very
> much appreciated.
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/GeoServer-s-spatial-filter-preventing-SQL-view-layer-from-working-tp5237269.html
> Sent from the GeoServer - User mailing list archive at Nabble.com.
>
>
> --
> ___
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
--
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] GeoServer's spatial filter preventing SQL view layer from working

[Andrea Aime]

Hi Martin,
it certainly looks similar, most likely same.

No new development, still not possible, people still welcome to chip in
with resources/funds:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

Cheers
Andrea

On Thu, Nov 19, 2015 at 6:32 AM, Martin Davis  wrote:

> I think this is the same issue discussed in this (lengthy) thread:
>
>
> http://osgeo-org.1560.x6.nabble.com/Reducing-query-data-size-in-Oracle-td5192620.html
>
> TLDR: not possible right now, apparently requires clever development to
> make it work.
>
> If there has been improvement on this front it would be great to know
> about it.  Or would be great to have someone implement a workaround!
>
> On Wed, Nov 18, 2015 at 12:08 PM, cheesybiscuits <
> thomaschrist...@gmail.com> wrote:
>
>> I've created a function within Oracle for on-the-fly clustering that I
>> hoped
>> to query via GeoServer using an SQL view layer.
>>
>> The function takes as its arguments the bounding box and the number of
>> grid
>> cells to use in a basic gridded clustering process (i.e. find the centre
>> of
>> mass for points within each grid cell). Please note I've tried the Point
>> Stacker extension and it isn't adequate for my needs. Executing the
>> following query within Oracle gives the list of sdo_geometry objects that
>> I
>> expect:
>>
>> select * from table(package_name.function_name(-180, -90, 180, 90, 3);
>>
>> My intention is to make WMS requests to GeoServer with the viewparams
>> parameter included that provides all required arguments. Because of the
>> way
>> the function works the returned sdo_geometry objects will only ever be
>> within the provided bounding box.
>>
>> I can successfully create an SQL view layer within GeoServer using this
>> syntax and everything seems OK while publishing. However when I access the
>> layer everything falls apart. GeoServer takes my query and wraps it as
>> follows:
>>
>> SELECT GEOMETRY as GEOMETRY FROM (select * from
>> table(package_name.function_name(-180, -90, 180, 90, 3))) VTABLE WHERE
>> SDO_FILTER(GEOMETRY, ?, 'mask=anyinteract querytype=WINDOW') = 'TRUE'
>>
>> Oracle then errors because the function's table return type doesn't have a
>> spatial index to use with SDO_FILTER. Although I did find a  somewhat
>> similar problem on GIS.SE
>> <
>> http://gis.stackexchange.com/questions/92554/can-i-create-an-oracle-spatial-view-from-a-non-spatial-table
>> >
>> the same solution does not apply as my function returns a table, not a
>> single object, and Oracle doesn't permit indexes on named table types.
>>
>> As things currently stand I don't think I can make this work, and the only
>> thing that could potentially help is to prevent GeoServer from appending
>> its
>> SDO_FILTER mask. However I'm guessing this just isn't possible without
>> digging into the source and creating a custom build (totally not an
>> option).
>>
>> Can anyone tell me if there's something I've missed here, or suggest a
>> different approach for solving the same problem? Any thoughts would be
>> very
>> much appreciated.
>>
>>
>>
>> --
>> View this message in context:
>> http://osgeo-org.1560.x6.nabble.com/GeoServer-s-spatial-filter-preventing-SQL-view-layer-from-working-tp5237269.html
>> Sent from the GeoServer - User mailing list archive at Nabble.com.
>>
>>
>> --
>> ___
>> Geoserver-users mailing list
>> Geoserver-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>
>
>
> --
>
> ___
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>


-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi