[Geoserver-users] Geopackage plugin for 2.5.1

2014-06-02 Thread Koivusalo, Tuomas 
Hi,

we are interested in testing Geopackage format in Geoserver, but apparently 
there is no functioning version of plugin for 2.5.x. ares.boundlessgeo.com does 
have community package for 2.5, but zip contains only 
sqlite-jdbc-spatialite-3.7.2-2.4.jar. Is there version of plugin for 2.5.x or 
should we do testing with development version of Geoserver?

Br,

Tuomas Koivusalo
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] SRID 89189 and Geoserver

2014-04-09 Thread Koivusalo, Tuomas 
Hi,

apparently it is not known by default, but you can add it's definition to 
$GEOSERVER_DATA_DIR/user_projections/epsg.properties.

Br,

Tuomas Koivusalo

From: Steven Campbell [mailto:s.campb...@poole.gov.uk]
Sent: 9. huhtikuuta 2014 14:51
To: 'Rahkonen Jukka (Tike)'; geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] SRID 89189 and Geoserver

Hi Jukka

Apologies I meant to write 81989, do you know if GeoServer works with 81989?

Thanks

Steve

From: Rahkonen Jukka (Tike) [mailto:jukka.rahko...@mmmtike.fi]
Sent: 09 April 2014 12:44
To: Steven Campbell; 
geoserver-users@lists.sourceforge.net
Subject: Re: SRID 89189 and Geoserver

Hi,

No, it is unknown to Geoserver. What it is for a projection? Obviously it is 
not an EPSG-projection nor Oracle SRID. Do you know the parameters of your 
SRID? You can look examples of different ways for giving the parameters from 
the links in http://spatialreference.org/ref/epsg/3067/

-Jukka Rahkonen-

Steven Campbell wrote:

Hi

Does anyone know if GeoServer use the SRID 89189?

Thanks

Steve



Steve Campbell | GIS Manager
Corporate Strategy and Communications
Borough of Poole | Civic Centre | Poole BH15 2RU
Tel: 01202 633 362
Email: s.campb...@poole.gov.uk
Website:www.boroughofpoole.com
Think Green! Please Recycle

DISCLAIMER: This email and any files transmitted with it may be confidential, 
legally privileged and protected in law and are intended solely for the use of 
the individual to whom it is addressed. The copyright in all documentation is 
the property of the Borough of Poole and this email and any documentation must 
not be copied or used other than as strictly necessary for the purpose of this 
email, without prior written consent which may be subject to conditions. Any 
view or opinions presented are solely those of the author and do not 
necessarily represent those of the Borough of Poole. The Borough of Poole 
reserves the right to inspect incoming and outgoing emails. If you have 
received this email in error please contact the sender by return and confirm 
that its contents have been destroyed. Telephone enquiries should be directed 
to the Borough switchboard on 01202 633633.'
DISCLAIMER: This email and any files transmitted with it may be confidential, 
legally privileged and protected in law and are intended solely for the use of 
the individual to whom it is addressed. The copyright in all documentation is 
the property of the Borough of Poole and this email and any documentation must 
not be copied or used other than as strictly necessary for the purpose of this 
email, without prior written consent which may be subject to conditions. Any 
view or opinions presented are solely those of the author and do not 
necessarily represent those of the Borough of Poole. The Borough of Poole 
reserves the right to inspect incoming and outgoing emails. If you have 
received this email in error please contact the sender by return and confirm 
that its contents have been destroyed. Telephone enquiries should be directed 
to the Borough switchboard on 01202 633633.'
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Character encoding

2013-10-10 Thread Koivusalo, Tuomas 
Hi,

I have encountered same issue and talked about it here earlier, but I left for 
holidays right afterwards and didn't have time to debug it further. Issue is 
most definitely bug, apparently regression from version 2.3.4 onwards. I 
couldn't replicate issue with 2.3.3 but it appears in all later versions. I 
think this should be reported as bug, although it would probably be good if we 
could find out more accurately what component is causing this issue to help 
with debugging.

//koivutu

-Original Message-
From: Uggla Henrik [mailto:henrik.ug...@kristianstad.se] 
Sent: 10. lokakuuta 2013 13:47
To: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Character encoding

I think it might be a bug. In the Geoserver logs I found:

2013-10-10 12:34:01,240 WARN [wicket.Localizer] - Tried to retrieve a localized 
string for a component that has not yet been added to the page. This can 
sometimes lead to an invalid or no localized resource returned. Make sure you 
are not calling Component#getString() inside your Component's constructor. 
Offending component: [MarkupContainer [Component id = dummy]]

No one else experienced this? Please help.

My /etc/environment:
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
LANGUAGE="sv:en"
LANG="sv_SE.UTF-8"
LC_ALL="sv_SE.UTF-8"
LC_MESSAGES="sv_SE.UTF-8"
LC_NUMERIC="sv_SE.UTF-8"
LC_TIME="sv_SE.UTF-8"
LC_MONETARY="sv_SE.UTF-8"
LC_PAPER="sv_SE.UTF-8"
LC_IDENTIFICATION="sv_SE.UTF-8"
LC_NAME="sv_SE.UTF-8"
LC_ADDRESS="sv_SE.UTF-8"
LC_TELEPHONE="sv_SE.UTF-8"
LC_MEASUREMENT="sv_SE.UTF-8"

My /etc/default/locale:
LANG="sv_SE.UTF-8"

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register > 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Possible regression in encoding handling in Geoserver 2.3.5

2013-09-03 Thread Koivusalo, Tuomas 
Hi,

It would seem like 2.4-RC1 suffers from same issue. It looks like encoding is 
changed to UTF-8 if I try to enter ä or ö to title, causing the problem. I 
checked layer xmls with file -bi before and after testing it.

-Tuomas



-Original Message-
From: Koivusalo, Tuomas [mailto:tuomas.koivus...@cgi.com] 
Sent: 3. syyskuuta 2013 15:46
To: fg...@users.sourceforge.net; geoserver
Subject: Re: [Geoserver-users] Possible regression in encoding handling in 
Geoserver 2.3.5

Hi,

It seems that most of the files are in us-ascii encoding, layer 
featuretype.xml's are for some part in utf-8 (by quickly glancing through list 
I'd say that layers containing Scandinavian letters are in UTF-8, otherwiser 
us-ascii). None of the properties files seem to be in UTF-8. 

My browser is configured to use English. 

I'm downloading 2.4-RC1 right now, I'll check if I can replicate issue there.

Br,

Tuomas Koivusalo

-Original Message-
From: frank.gasd...@gmail.com [mailto:frank.gasd...@gmail.com] On Behalf Of 
Frank Gasdorf
Sent: 3. syyskuuta 2013 15:39
To: Koivusalo, Tuomas; geoserver
Subject: Re: [Geoserver-users] Possible regression in encoding handling in 
Geoserver 2.3.5

Just an additional question : Which language have you configured in you 
browser? Makes it easier to find the problematic file ;)

Thanks
- Frank


2013/9/3 Frank Gasdorf 


There was an issue and it should be fixed since 2.3.1 
(http://jira.codehaus.org/browse/GEOS-5641) Wondering what has been changed 
since...

Could you please check the properties file encodings. I may be that 
some files are UTF-8 I guess.

Have you tried with 2.4-RC1 - same probem here?

- Frank


    2013/9/3 Koivusalo, Tuomas 


Hi all,

I just upgraded customers Geoserver from 2.3.1 to 2.3.5 and it 
seems that something has changed in encoding handling. Some of the configured 
layers have ä's & ö's In their title and this has previously worked ok. After 
upgrading, if layer configuration is saved encoding in title is broken, so end 
result is complete gibberish like so:

Pyörätiet -> Pyörätiet
Pylväät -> Pylväät

So it looks like it is double encoded. I could fix this by 
using recode UTF-8..latin1 featuretype.xml, but saving layer configuration will 
break it again. I remember similar behavior with 2.0 series of Geoserver, but 
this has worked fine since 2.1+ until now. Does anyone else have this issue or 
is it possible that some exotic configuration (which I don't think we have, but 
you never know) could affect this?

Br,
Tuomas Koivusalo




--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 
2012, more!
Discover the easy way to master current and previous Microsoft 
technologies
and advance your career. Get an incredible 1,500+ hours of 
step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!

http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users






--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies and 
advance your career. Get an incredible 1,500+ hours of step-by-step tutorial 
videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Possible regression in encoding handling in Geoserver 2.3.5

2013-09-03 Thread Koivusalo, Tuomas 
Hi all,

I just upgraded customers Geoserver from 2.3.1 to 2.3.5 and it seems that 
something has changed in encoding handling. Some of the configured layers have 
ä's & ö's In their title and this has previously worked ok. After upgrading, if 
layer configuration is saved encoding in title is broken, so end result is 
complete gibberish like so:

Pyörätiet -> Pyörätiet
Pylväät -> Pylväät

So it looks like it is double encoded. I could fix this by using recode 
UTF-8..latin1 featuretype.xml, but saving layer configuration will break it 
again. I remember similar behavior with 2.0 series of Geoserver, but this has 
worked fine since 2.1+ until now. Does anyone else have this issue or is it 
possible that some exotic configuration (which I don't think we have, but you 
never know) could affect this?

Br,

Tuomas Koivusalo
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] load balancing - jetty and Appache

2013-09-03 Thread Koivusalo, Tuomas 
Hi,

Last time I used jetty I had to manually download ajp-library for jetty and add 
it to my jetty installation. I haven't been following jetty development very 
closely lately, but at least in past ajp-connector wasn't included by default.

-Tuomas

From: gerome
Sent: ‎30.‎8.‎2013 16:34
To: 
geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] load balancing - jetty and Appache

Hi,
I have 2 jetty geoserver instances on the same server.
one is on the 8080 port the other on the 8081
I have an Appache in front of these 2 geoserver and with the
mod_proxy_balancer working.

I would like to use the mod_proxy_ajp. I've read that I should add a
connector in the jetty.xml
but when I add it, the server doesn't start

my jetty.xml









  
  

3
2
8443
  
  


  

  8009

  


do any one has an method with this issue ?



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/load-balancing-jetty-and-Appache-tp5075226.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Possible regression in encoding handling in Geoserver 2.3.5

2013-09-03 Thread Koivusalo, Tuomas 
Hi,

It seems that most of the files are in us-ascii encoding, layer 
featuretype.xml's are for some part in utf-8 (by quickly glancing through list 
I'd say that layers containing Scandinavian letters are in UTF-8, otherwiser 
us-ascii). None of the properties files seem to be in UTF-8. 

My browser is configured to use English. 

I'm downloading 2.4-RC1 right now, I'll check if I can replicate issue there.

Br,

Tuomas Koivusalo

-Original Message-
From: frank.gasd...@gmail.com [mailto:frank.gasd...@gmail.com] On Behalf Of 
Frank Gasdorf
Sent: 3. syyskuuta 2013 15:39
To: Koivusalo, Tuomas; geoserver
Subject: Re: [Geoserver-users] Possible regression in encoding handling in 
Geoserver 2.3.5

Just an additional question : Which language have you configured in you 
browser? Makes it easier to find the problematic file ;)

Thanks
- Frank


2013/9/3 Frank Gasdorf 


There was an issue and it should be fixed since 2.3.1 
(http://jira.codehaus.org/browse/GEOS-5641) Wondering what has been changed 
since...

Could you please check the properties file encodings. I may be that 
some files are UTF-8 I guess.

Have you tried with 2.4-RC1 - same probem here?

- Frank


    2013/9/3 Koivusalo, Tuomas 


Hi all,

I just upgraded customers Geoserver from 2.3.1 to 2.3.5 and it 
seems that something has changed in encoding handling. Some of the configured 
layers have ä's & ö's In their title and this has previously worked ok. After 
upgrading, if layer configuration is saved encoding in title is broken, so end 
result is complete gibberish like so:

Pyörätiet -> Pyörätiet
Pylväät -> Pylväät

So it looks like it is double encoded. I could fix this by 
using recode UTF-8..latin1 featuretype.xml, but saving layer configuration will 
break it again. I remember similar behavior with 2.0 series of Geoserver, but 
this has worked fine since 2.1+ until now. Does anyone else have this issue or 
is it possible that some exotic configuration (which I don't think we have, but 
you never know) could affect this?

Br,
Tuomas Koivusalo




--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 
2012, more!
Discover the easy way to master current and previous Microsoft 
technologies
and advance your career. Get an incredible 1,500+ hours of 
step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!

http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users






--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Possible regression in encoding handling in Geoserver 2.3.5

2013-09-03 Thread Koivusalo, Tuomas 
Hi all,

I just upgraded customers Geoserver from 2.3.1 to 2.3.5 and it seems that 
something has changed in encoding handling. Some of the configured layers have 
ä's & ö's In their title and this has previously worked ok. After upgrading, if 
layer configuration is saved encoding in title is broken, so end result is 
complete gibberish like so:

Pyörätiet -> Pyörätiet 
Pylväät -> Pylväät

So it looks like it is double encoded. I could fix this by using recode 
UTF-8..latin1 featuretype.xml, but saving layer configuration will break it 
again. I remember similar behavior with 2.0 series of Geoserver, but this has 
worked fine since 2.1+ until now. Does anyone else have this issue or is it 
possible that some exotic configuration (which I don't think we have, but you 
never know) could affect this?

Br,
Tuomas Koivusalo



--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Working with cyrillic layer names

2012-11-08 Thread Koivusalo, Tuomas 
.DefaultPageFactory.createPage(DefaultPageFactory.java:188)
 ... 89 more Caused by: java.lang.IllegalArgumentException: Argument page must 
be not null at 
org.apache.wicket.request.target.component.PageRequestTarget.(PageRequestTarget.java:43)
 at org.apache.wicket.RequestCycle.setResponsePage(RequestCycle.java:768) at 
org.apache.wicket.Component.setResponsePage(Component.java:3248) at 
org.geoserver.web.data.resource.ResourceConfigurationPage.(ResourceConfigurationPage.java:115)
 at 
org.geoserver.web.data.resource.ResourceConfigurationPage.(ResourceConfigurationPage.java:94)
 ... 94 more

Error given out by SLD:

http://localhost:80/geoserver_21/schemas/wms/1.1.1/WMS_exception_1_1_1.dtd";> 
   
  The requested Style can not be used with this layer.  The style specifies 
an attribute of Наименован and the layer is: test:Soilmap


Any ideas?

Best regards,

Tuomas 

-Original Message-
From: Koivusalo, Tuomas [mailto:tuomas.koivus...@logica.com] 
Sent: 8. marraskuuta 2012 18:30
To: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] Working with cyrillic layer names

Hi all,

 

Is there any way to get Geoserver to function with Cyrillic layer names? I have 
PostGIS database with data with Cyrillic content, and I’m trying to publish 
that through Geoserver. I can add datastore and even layer normally, and 
everything seems to work ok. Even GetCapabilities show layer name correctly. 
But when I try to view layer through WMS (either with Layer Preview or Desktop 
GIS software), I get following error:

 

http://localhost/geoserver_22/schemas/wms/1.1.1/WMS_exception_1_1_1.dtd";> 
   

  Could not find layer 
test:Карта_классов_земель_Тосненский_р



 

Data in database is encoded as UTF-8. Everything works correctly if  I write 
layer name in latin characters, metadata, featureinfo, layer title, all work 
fine in Cyrillic. But Cyrillic layer name makes everything fail.  This behavior 
is same in both 2.1 and 2.2 Geoservers. Does anybody has any idea is there some 
way to work around this, or should this be considered as a bug?

 

Best regards,

 

Tuomas Koivusalo 

 


Think green - keep it on the screen. This e-mail and any attachment is for 
authorised use by the intended recipient(s) only. It may contain proprietary 
material, confidential information and/or be subject to legal privilege. It 
should not be copied, disclosed to, retained or used by, any other party. If 
you are not an intended recipient then please promptly delete this e-mail and 
any attachment and all copies and inform the sender. Thank you. 

Think green - keep it on the screen.

This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Working with cyrillic layer names

2012-11-08 Thread Koivusalo, Tuomas 
Hi all,

Is there any way to get Geoserver to function with Cyrillic layer names? I have 
PostGIS database with data with Cyrillic content, and I’m trying to publish 
that through Geoserver. I can add datastore and even layer normally, and 
everything seems to work ok. Even GetCapabilities show layer name correctly. 
But when I try to view layer through WMS (either with Layer Preview or Desktop 
GIS software), I get following error:

http://localhost/geoserver_22/schemas/wms/1.1.1/WMS_exception_1_1_1.dtd";> 
   
  Could not find layer 
test:Карта_классов_земель_Тосненский_р


Data in database is encoded as UTF-8. Everything works correctly if  I write 
layer name in latin characters, metadata, featureinfo, layer title, all work 
fine in Cyrillic. But Cyrillic layer name makes everything fail.  This behavior 
is same in both 2.1 and 2.2 Geoservers. Does anybody has any idea is there some 
way to work around this, or should this be considered as a bug?

Best regards,

Tuomas Koivusalo


Think green - keep it on the screen.

This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] (solved) WMS 1.3.0 stopped working.

2012-11-01 Thread Koivusalo, Tuomas 
Hi again,

I have managed to fix this problem, or at leat found a workaround for it. 
Problem was with custom EPSG definitions, both override and customly added one. 
Originally both custom definitions used had AXIS definitions like this:

 AXIS["Easting", EAST], AXIS["Northing", NORTH]

I had to switch these around to get WMS 1.3.0 to work with these projections. 
Regardless of CITE compliance setting, WMS 1.1.1 keeps working. 

I'm not sure if this is a bug or if I'm missing something, but according to 
documentation, Geoserver should be able to do that coordinate switch 
automatically, and it clearly works that way with non-custom projections. 

Regards,
Tuomas Koivusalo
________
From: Koivusalo, Tuomas [tuomas.koivus...@logica.com]
Sent: 30 October 2012 17:16
To: Andrea Aime
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] WMS 1.3.0 stopped working.

Hi all,

I have spent time further studying this. I upgraded Geoserver 2.2.1, and after 
that I cannot see firstly mentioned stack trace, so that doesn't have anything 
to with issue. Apparently bad credentials error is related to changing log 
levels, and I misread the log.

Actual problem seems to be related using particular projection. If WGS84 is 
used, WMS 1.3.0 works just fine. If EPSG:3878 is used, nothing is shown. 
EPSG:3878 is custom projection, which have been added to user.projections file, 
and also we have override for 3131 to be regarded as 3878. As far as I can tell 
this isconfigured ok, and it worked with Geoserver 2.0.2.

However, I cannot get any errors when doing requests with EPSG:3878 and WMS 
1.3.0, no matter the log level. This is what I get out with Geoserver developer 
log level:

30 Oct 17:06:35 TRACE [org.geoserver.ows.OWSHandlerMapping] - No handler 
mapping found for [/ows]
30 Oct 17:06:35 DEBUG [org.geoserver.ows.OWSHandlerMapping] - Mapping [/ows] to 
HandlerExecutionChain with handler [org.geoserver.ows.Dispatcher@7c4d1082] and 
1 interceptor
30 Oct 17:06:35 INFO [org.geoserver.wms] -
Request: getServiceInfo
30 Oct 17:06:35 DEBUG [org.geoserver.ows] - Getting layers and styles from 
LAYERS and STYLES
30 Oct 17:06:35 DEBUG [org.geoserver.ows] - establishing style_name style for 
workspace:layer
30 Oct 17:06:35 DEBUG [org.geoserver.wms] - setting up map
30 Oct 17:06:35 DEBUG [org.geoserver.wms.map] - setting up 525x767 image
30 Oct 17:06:35 DEBUG [org.vfny.geoserver.responses.wms.map] - setting to 
transparent
30 Oct 17:06:35 INFO [org.geoserver.wms] -
Request: getMap
Time = []
Filter = null
Format = image/png
Buffer = 0
Height = 767
Width = 525
Tiled = false
Palette = null
SRS = urn:x-ogc:def:crs:EPSG:3131
FeatureVersion = null
Legend = false
Styles = [StyleImpl[ name=style]]
Layers = [org.geoserver.wms.MapLayerInfo@36f3a6e8]
MaxFeatures = null
Bbox = ReferencedEnvelope[6813327.606167 : 6844244.968612, 476567.20795 
: 497725.194201]
RemoteOwsType = null
RemoteOwsURL = null
Env = {}
FormatOptions = {}
Angle = 0.0
CQLFilter = null
Elevation = []
FeatureId = null
StartIndex = null
ViewParams = null
Crs = PROJCS["ETRS89 / ETRS-GK24FIN",
  GEOGCS["ETRS89",
DATUM["European_Terrestrial_Reference_System_1989",
  SPHEROID["GRS 1980", 6378137.0, 298.257222101, AUTHORITY["EPSG","7019"]],
  AUTHORITY["EPSG","6258"]],
PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],
UNIT["degree", 0.017453292519943295],
AXIS["Longitude", EAST],
AXIS["Latitude", NORTH],
AUTHORITY["EPSG","4258"]],
PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],
UNIT["degree", 0.017453292519943295],
AXIS["Longitude", EAST],
AXIS["Latitude", NORTH],
AUTHORITY["EPSG","4258"]],
  PROJECTION["Transverse_Mercator"],
  PARAMETER["central_meridian", 24.0],
  PARAMETER["latitude_of_origin", 0.0],
  PARAMETER["scale_factor", 1.0],
  PARAMETER["false_easting", 50.0],
  PARAMETER["false_northing", 0.0],
  UNIT["m", 1.0],
  AXIS["Easting", EAST],
  AXIS["Northing", NORTH],
  AUTHORITY["EPSG","3131"]]
BgColor = java.awt.Color[r=255,g=255,b=255]
Transparent = true
SldBody = null
ValidateSchema = false
Sld = null
SldVersion = null
TilesOrigin = null
Filters = null
Exceptions = SE_XML
KMScore = 40
KMattr = true
Version = 1.3.0
Request = GetMap
Get = true
RawKvp = 
{BBOX

Re: [Geoserver-users] WMS 1.3.0 stopped working.

2012-10-30 Thread Koivusalo, Tuomas 
Hi all,

I have spent time further studying this. I upgraded Geoserver 2.2.1, and after 
that I cannot see firstly mentioned stack trace, so that doesn't have anything 
to with issue. Apparently bad credentials error is related to changing log 
levels, and I misread the log. 

Actual problem seems to be related using particular projection. If WGS84 is 
used, WMS 1.3.0 works just fine. If EPSG:3878 is used, nothing is shown. 
EPSG:3878 is custom projection, which have been added to user.projections file, 
and also we have override for 3131 to be regarded as 3878. As far as I can tell 
this isconfigured ok, and it worked with Geoserver 2.0.2.

However, I cannot get any errors when doing requests with EPSG:3878 and WMS 
1.3.0, no matter the log level. This is what I get out with Geoserver developer 
log level:

30 Oct 17:06:35 TRACE [org.geoserver.ows.OWSHandlerMapping] - No handler 
mapping found for [/ows]
30 Oct 17:06:35 DEBUG [org.geoserver.ows.OWSHandlerMapping] - Mapping [/ows] to 
HandlerExecutionChain with handler [org.geoserver.ows.Dispatcher@7c4d1082] and 
1 interceptor
30 Oct 17:06:35 INFO [org.geoserver.wms] - 
Request: getServiceInfo
30 Oct 17:06:35 DEBUG [org.geoserver.ows] - Getting layers and styles from 
LAYERS and STYLES
30 Oct 17:06:35 DEBUG [org.geoserver.ows] - establishing style_name style for 
workspace:layer
30 Oct 17:06:35 DEBUG [org.geoserver.wms] - setting up map
30 Oct 17:06:35 DEBUG [org.geoserver.wms.map] - setting up 525x767 image
30 Oct 17:06:35 DEBUG [org.vfny.geoserver.responses.wms.map] - setting to 
transparent
30 Oct 17:06:35 INFO [org.geoserver.wms] - 
Request: getMap
Time = []
Filter = null
Format = image/png
Buffer = 0
Height = 767
Width = 525
Tiled = false
Palette = null
SRS = urn:x-ogc:def:crs:EPSG:3131
FeatureVersion = null
Legend = false
Styles = [StyleImpl[ name=style]]
Layers = [org.geoserver.wms.MapLayerInfo@36f3a6e8]
MaxFeatures = null
Bbox = ReferencedEnvelope[6813327.606167 : 6844244.968612, 476567.20795 
: 497725.194201]
RemoteOwsType = null
RemoteOwsURL = null
Env = {}
FormatOptions = {}
Angle = 0.0
CQLFilter = null
Elevation = []
FeatureId = null
StartIndex = null
ViewParams = null
Crs = PROJCS["ETRS89 / ETRS-GK24FIN", 
  GEOGCS["ETRS89", 
DATUM["European_Terrestrial_Reference_System_1989", 
  SPHEROID["GRS 1980", 6378137.0, 298.257222101, AUTHORITY["EPSG","7019"]], 
  AUTHORITY["EPSG","6258"]], 
PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], 
UNIT["degree", 0.017453292519943295], 
AXIS["Longitude", EAST], 
AXIS["Latitude", NORTH], 
AUTHORITY["EPSG","4258"]], 
PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], 
UNIT["degree", 0.017453292519943295], 
AXIS["Longitude", EAST], 
AXIS["Latitude", NORTH], 
AUTHORITY["EPSG","4258"]], 
  PROJECTION["Transverse_Mercator"], 
  PARAMETER["central_meridian", 24.0], 
  PARAMETER["latitude_of_origin", 0.0], 
  PARAMETER["scale_factor", 1.0], 
  PARAMETER["false_easting", 50.0], 
  PARAMETER["false_northing", 0.0], 
  UNIT["m", 1.0], 
  AXIS["Easting", EAST], 
  AXIS["Northing", NORTH], 
  AUTHORITY["EPSG","3131"]]
BgColor = java.awt.Color[r=255,g=255,b=255]
Transparent = true
SldBody = null
ValidateSchema = false
Sld = null
SldVersion = null
TilesOrigin = null
Filters = null
Exceptions = SE_XML
KMScore = 40
KMattr = true
Version = 1.3.0
Request = GetMap
Get = true
RawKvp = 
{BBOX=6813327.606167,476567.207950,6844244.968612,497725.194201, CRS=EPSG:3131, 
TRANSPARENT=TRUE, VERSION=1.3.0, FORMAT=image/png, SERVICE=WMS, HEIGHT=767, 
REQUEST=GetMap, LAYERS=workspace:LAYER, STYLES=, DPI=67, WIDTH=525}
BaseUrl = http://ip:80/geoserver/
RequestCharset = UTF-8
30 Oct 17:06:35 DEBUG [org.geoserver.wms.map] - Writing png image ...
30 Oct 17:06:35 DEBUG [org.geoserver.wms.map] - Writing png image ... done!
30 Oct 17:06:35 DEBUG [org.geoserver.filters] - Not compressing output for 
mimetype: image/png

I have been testing this with Quantum GIS 1.8.0 and using layer preview, log 
looks about same in both cases. Also, I haven't seen any additional info on 
other log levels.

Could this be some kind of re-projection problem with our custom EPSG? Any 
ideas would be appreciated.

Thanks!

Regards,

Tuomas Koivusalo


From: andrea.a...@gmail.com [

Re: [Geoserver-users] WMS 1.3.0 stopped working.

2012-10-24 Thread Koivusalo, Tuomas 
Hi again,

I tweaked log level and now I can see 'bad credentials' error message when 
trying to use wms 1.3.0. I tried this through layer preview as admin-user, so I 
don't even know what credentials I could be missing. Also, security config 
don't appear to have any specific rules for wms. Any clues or ideas would be 
appreciated.

Tuomas Koivusalo
________
From: Koivusalo, Tuomas
Sent: 23.10.2012 13:11
To: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] WMS 1.3.0 stopped working.

Hello all,

we recently updated GS 2.0.2 instance directly to 2.2. Everything worked fine 
for a while, but after few adjustments to configuration it would seem that WMS 
version 1.3 has stopped from working. Through 1.3 we cannot get map even 
through layer preview. I have studied configuration and I cannot find anything 
weird in it, all of the WMS configuration is identical to what we had before. 
Also, when trying to use WMS 1.3.0, there are no clear error messages in log, 
it just doesn't give out data. Only error I can find is this:

2012-10-19 12:46:19,595 ERROR [geoserver.wms] - Failed to compute the scale 
denominator, wms_scale_denominator env variable is unset 
java.lang.IllegalArgumentException: The provided envelope is outside the source 
CRS definition area at
org.geotools.renderer.lite.RendererUtilities.calculateScale(RendererUtilities.java:589)
at
org.geotools.renderer.lite.RendererUtilities.calculateScale(RendererUtilities.java:472)
...

I did look this error up by Google, but results I found would indicate that 
this shouldn't be a real problem. I have also tried to re-deploy geoserver.war, 
but obviously we need to retain data_dir, so that didn't fix anything.

We are running  Geoserver 2.2 on Debian Squeeze, openJDK 1.6.0_18 and Tomcat 
6.0.35. We have Inspire 2.2 snapshot plugin and oracle jdbc connection plugin 
installed.

Does anybody has any idea what could potentially be wrong here?

-Tuomas

Think green - keep it on the screen. This e-mail and any attachment is for 
authorised use by the intended recipient(s) only. It may contain proprietary 
material, confidential information and/or be subject to legal privilege. It 
should not be copied, disclosed to, retained or used by, any other party. If 
you are not an intended recipient then please promptly delete this e-mail and 
any attachment and all copies and inform the sender. Thank you.


Think green - keep it on the screen.

This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] WMS 1.3.0 stopped working.

2012-10-23 Thread Koivusalo, Tuomas 
Hello all,

we recently updated GS 2.0.2 instance directly to 2.2. Everything worked fine 
for a while, but after few adjustments to configuration it would seem that WMS 
version 1.3 has stopped from working. Through 1.3 we cannot get map even 
through layer preview. I have studied configuration and I cannot find anything 
weird in it, all of the WMS configuration is identical to what we had before. 
Also, when trying to use WMS 1.3.0, there are no clear error messages in log, 
it just doesn't give out data. Only error I can find is this:

2012-10-19 12:46:19,595 ERROR [geoserver.wms] - Failed to compute the scale 
denominator, wms_scale_denominator env variable is unset 
java.lang.IllegalArgumentException: The provided envelope is outside the source 
CRS definition area at
org.geotools.renderer.lite.RendererUtilities.calculateScale(RendererUtilities.java:589)
at
org.geotools.renderer.lite.RendererUtilities.calculateScale(RendererUtilities.java:472)
...

I did look this error up by Google, but results I found would indicate that 
this shouldn't be a real problem. I have also tried to re-deploy geoserver.war, 
but obviously we need to retain data_dir, so that didn't fix anything.

We are running  Geoserver 2.2 on Debian Squeeze, openJDK 1.6.0_18 and Tomcat 
6.0.35. We have Inspire 2.2 snapshot plugin and oracle jdbc connection plugin 
installed.

Does anybody has any idea what could potentially be wrong here?

-Tuomas


Think green - keep it on the screen.

This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Weird issue with style

2012-07-10 Thread Koivusalo, Tuomas 
Hi,

I managed to resolve this issue by myself. Part of the problem came  from 
Quantum GIS caching broken style so I'm not exactly sure which change to SLD 
fixed the issue. Changes are that snippet from SLD below was actually working 
but I didn't notice it because of caching issue. I think I must try to recreate 
problem as it would seem that it was some kind of bug in SLD handling so it 
would be useful to actually know what caused this issue.

-Tuomas Koivusalo

-Original Message-----
From: Koivusalo, Tuomas [mailto:tuomas.koivus...@logica.com] 
Sent: 4. heinäkuuta 2012 15:10
To: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] Weird issue with style

Hi all,

 

I have been tinkering around with a SLD style for relatively simple data served 
from PostGIS database. Basicly It is collection of multilinestring-type 
geometries, and style should changes color and width of lines according to 
value in certain column. There are six possible values. For some unknown reason 
five of these rules work, but one of them just doesn't. All other lines are 
drawn correctly, but no style is applied to line segments containing this 
value. Rule itself is completely identical to other six, only difference being 
in color of the line. Example below.

 





  Kovat asfalttibetonit (AB)

  Kovat asfalttibetonit (AB)

  



  paalluok

  10



  

  



  #FF

  3

  1



  





 



  

  Pehmeät asfalttibetonit (PAB)

  Pehmeät asfalttibetonit (PAB)

  



  paalluok

  20



  

  



  #0070FF

  3

  1



  





 

I have been unable to get any error logging out of Geoserver about this issue, 
it is as if that single rule is just skipped. Data in database does seem to be 
ok, there are segments with correct value and they contain correct type of 
geometry (and values are similar to other possible values). 

 

Any ideas how to deal with this issue would be appreciated. I'm running 
Geoserver 2.1.4 on top of RHEL5 and Tomcat 6.

 

-Tuomas Koivusalo


Think green - keep it on the screen. This e-mail and any attachment is for 
authorised use by the intended recipient(s) only. It may contain proprietary 
material, confidential information and/or be subject to legal privilege. It 
should not be copied, disclosed to, retained or used by, any other party. If 
you are not an intended recipient then please promptly delete this e-mail and 
any attachment and all copies and inform the sender. Thank you. 

Think green - keep it on the screen.

This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Weird issue with style

2012-07-10 Thread Koivusalo, Tuomas 
Hi all,

I have been tinkering around with a SLD style for relatively simple data served 
from PostGIS database. Basicly It is collection of multilinestring-type 
geometries, and style should changes color and width of lines according to 
value in certain column. There are six possible values. For some unknown reason 
five of these rules work, but one of them just doesn't. All other lines are 
drawn correctly, but no style is applied to line segments containing this 
value. Rule itself is completely identical to other six, only difference being 
in color of the line. Example below.




  Kovat asfalttibetonit (AB)
  Kovat asfalttibetonit (AB)
  

  paalluok
  10

  
  

  #FF
  3
  1

  





  
  Pehmeät asfalttibetonit (PAB)
  Pehmeät asfalttibetonit (PAB)
  

  paalluok
  20

  
  

  #0070FF
  3
  1

  



I have been unable to get any error logging out of Geoserver about this issue, 
it is as if that single rule is just skipped. Data in database does seem to be 
ok, there are segments with correct value and they contain correct type of 
geometry (and values are similar to other possible values).

Any ideas how to deal with this issue would be appreciated. I'm running 
Geoserver 2.1.4 on top of RHEL5 and Tomcat 6.

-Tuomas Koivusalo


Think green - keep it on the screen.

This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users