Re: [Geoserver-users] Scale discrepancy between Web Mercator and BC-Albers

2016-02-15 Thread Martin Davis 
Are you suggesting that GeoServer computes the scale at a single known
point for all map request extents, no matter where on the globe they are
located?Does the OGC standard specify this?

If so, I guess that might explain the discrepancy between SLD scale and
true image scale, at our latitudes (49 to 60) ?




On Mon, Feb 15, 2016 at 2:35 PM, Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
>
>
> I am not sure if I understood the problem but I wonder how the true scale
> suits together with Web Mercator. I guess that you do not expect that the
> tiles of the same zoom level would use different styles at equator than in
> Canada or Finland even the true scale differs a lot.
>
>
>
> -Jukka Rahkonen-
>
>
>
> Martin Davis wrote:
>
>
>
> We are displaying map images in Web Mercator, from a GeoServer with native
> CRS as BC-Albers (EPGS:3005).
>
>
>
> We are using an OpenLayers client to display the map images.  We have
> confirmed that the geodetic scale displayed by OpenLayers is approximately
> the true scale of the map images (modulo the fact that OL uses a fixed
> resolution of 72 DPI).
>
>
>
> Based on the zoom levels at which layers become visible, it appears that
> GeoServer's internal computed scale is from 2 to 4 times larger than the
> client scale.
>
>
>
> Is this expected?
>
>
>
> Is there any way to determine a way to map between client scale and
> Geoserver scale, so that we can configure the client to track GeoServer
> visibility faithfully?
>
>
>
> Is there any way to display the internal GeoServer scale to make it
> possible to confirm if this analysis is correct?
>
>
>
>
>
> GeoServer ver 2.6 (although I believe this is happening in 2.8 as well)
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] User isolation in Geoserver

2016-02-15 Thread Brian Farrell 
Jim,

Well, I thought this was resolved, but a week of use by students and a
script attempting to automate the process, I'm back with the same error.
I've started with a clean installation of Geoserver. Below are the steps I
took to set up Geoserver, steps to reproduce the bug, full error message,
and build information.

Workspace Isolation Bug Reproduction Instructions

Setting up the environment
1. Clear all pre-loaded workspaces from geoserver
2. Create a workspace named ‘shared’ as the default workspace
3. Enable the ‘shared’ workspace
4. Create a workspace named ‘student0workspace’. Do not make it the default
workspace
5. Enable the ‘student0workspace’ workspace
6. Add a new role named ‘student0role’
7. Add a new user named ‘student0’ and give it the ‘student0role’ role.
8. Add three new data security rules that give ‘student0role’ read, write,
and admin access to ‘student0workspace’.
9. Make sure the catalog mode is set to Hide.

Reproducing the bug
1. Log in as ‘student0’
2. Add a new shapefile store. Name it ‘states_store’ and publish the
states.shp file under data > shapefiles
3. Click publish for the states layer
4. Fill in the Declared SRS and attempt to calculate the native bounding
box (‘Compute from data’). The following error will occur in the geoserver
error log (full error message at the end): “Error computing the native BBOX
java.io.IOException: Schema 'student0workspace:states' does not exist.”

Note: interestingly enough, if while stuck on step 4, the workspace
configuration is re-opened and saved (even without any changes), the layer
will publish properly (assuming a layer style is created in the workspace
and selected under the publishing tab).



2016-02-15 17:41:06,628 ERROR [data.resource] - Error computing the native
BBOX
java.io.IOException: Schema 'student0workspace:states' does not exist.
at
org.geotools.data.store.ContentDataStore.ensureEntry(ContentDataStore.java:621)
at
org.geotools.data.store.ContentDataStore.getFeatureSource(ContentDataStore.java:393)
at
org.geotools.data.store.ContentDataStore.getFeatureSource(ContentDataStore.java:687)
at
org.geoserver.catalog.ResourcePool.getFeatureSource(ResourcePool.java:1183)
at
org.geoserver.catalog.impl.FeatureTypeInfoImpl.getFeatureSource(FeatureTypeInfoImpl.java:125)
at
org.geoserver.catalog.CatalogBuilder.getNativeBounds(CatalogBuilder.java:561)
at
org.geoserver.catalog.CatalogBuilder.getNativeBounds(CatalogBuilder.java:543)
at
org.geoserver.web.data.resource.BasicResourceConfig$1.onSubmit(BasicResourceConfig.java:120)
at
org.apache.wicket.ajax.markup.html.form.AjaxSubmitLink$1.onSubmit(AjaxSubmitLink.java:68)
at
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior.onEvent(AjaxFormSubmitBehavior.java:143)
at
org.apache.wicket.ajax.AjaxEventBehavior.respond(AjaxEventBehavior.java:177)
at
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:300)
at
org.apache.wicket.request.target.component.listener.BehaviorRequestTarget.processEvents(BehaviorRequestTarget.java:119)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:484)
at
org.apache.wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:160)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.springframework.web.servlet.mvc.ServletWrappingController.handleRequestInternal(ServletWrappingController.java:159)
at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:923)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:852)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:882)
at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:789)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at
org.geoserver.filters.ThreadLocalsCleanupFilter.doFilter(ThreadLocalsCleanupFilter.java:28)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:75)
at

Re: [Geoserver-users] Scale discrepancy between Web Mercator and BC-Albers

2016-02-15 Thread Martin Davis 
Yes, we realize that's an issue. In our case we're only concerned with a
relatively small area (the province of BC), so the variation in true scale
across the area is not that large (around 20%).  We realize that we won't
get 100% correlation, but we'd like to at least get it looking right better
than 50% of the time!

The issue is that it's very hard to determine what a scale limit in a SLD
corresponds to in terms of client (true, screen) scale.   It seems odd that
the GeoServer scale would be a factor of 2 or more different to the true
(image) scale.

There does appear to be a rough correlation, which may even be a linear
factor.  But it's hard to tell without seeing the exact scale that
GeoServer is using in its SLD algorithm.

As examples, here's some scale limits from SLDs, with the corresponding
largest client scale (approximate)  at which the layer is visible

SLD Client Zoom Level
 10,000,000 4,399,000 6
 6,000,000 2,297,000 7

 2,000,000 565,000 9
 1,000,000 282,000 10
 500,000 143,000 11
 20,000 8,957  15


On Mon, Feb 15, 2016 at 2:35 PM, Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:

> Hi,
>
>
>
> I am not sure if I understood the problem but I wonder how the true scale
> suits together with Web Mercator. I guess that you do not expect that the
> tiles of the same zoom level would use different styles at equator than in
> Canada or Finland even the true scale differs a lot.
>
>
>
> -Jukka Rahkonen-
>
>
>
> Martin Davis wrote:
>
>
>
> We are displaying map images in Web Mercator, from a GeoServer with native
> CRS as BC-Albers (EPGS:3005).
>
>
>
> We are using an OpenLayers client to display the map images.  We have
> confirmed that the geodetic scale displayed by OpenLayers is approximately
> the true scale of the map images (modulo the fact that OL uses a fixed
> resolution of 72 DPI).
>
>
>
> Based on the zoom levels at which layers become visible, it appears that
> GeoServer's internal computed scale is from 2 to 4 times larger than the
> client scale.
>
>
>
> Is this expected?
>
>
>
> Is there any way to determine a way to map between client scale and
> Geoserver scale, so that we can configure the client to track GeoServer
> visibility faithfully?
>
>
>
> Is there any way to display the internal GeoServer scale to make it
> possible to confirm if this analysis is correct?
>
>
>
>
>
> GeoServer ver 2.6 (although I believe this is happening in 2.8 as well)
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] Scale discrepancy between Web Mercator and BC-Albers

2016-02-15 Thread Rahkonen Jukka (MML) 
Hi,

I am not sure if I understood the problem but I wonder how the true scale suits 
together with Web Mercator. I guess that you do not expect that the tiles of 
the same zoom level would use different styles at equator than in Canada or 
Finland even the true scale differs a lot.

-Jukka Rahkonen-

Martin Davis wrote:

We are displaying map images in Web Mercator, from a GeoServer with native CRS 
as BC-Albers (EPGS:3005).

We are using an OpenLayers client to display the map images.  We have confirmed 
that the geodetic scale displayed by OpenLayers is approximately the true scale 
of the map images (modulo the fact that OL uses a fixed resolution of 72 DPI).

Based on the zoom levels at which layers become visible, it appears that 
GeoServer's internal computed scale is from 2 to 4 times larger than the client 
scale.

Is this expected?

Is there any way to determine a way to map between client scale and Geoserver 
scale, so that we can configure the client to track GeoServer visibility 
faithfully?

Is there any way to display the internal GeoServer scale to make it possible to 
confirm if this analysis is correct?


GeoServer ver 2.6 (although I believe this is happening in 2.8 as well)
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Scale discrepancy between Web Mercator and BC-Albers

2016-02-15 Thread Martin Davis 
We are displaying map images in Web Mercator, from a GeoServer with native
CRS as BC-Albers (EPGS:3005).

We are using an OpenLayers client to display the map images.  We have
confirmed that the geodetic scale displayed by OpenLayers is approximately
the true scale of the map images (modulo the fact that OL uses a fixed
resolution of 72 DPI).

Based on the zoom levels at which layers become visible, it appears that
GeoServer's internal computed scale is from 2 to 4 times larger than the
client scale.

Is this expected?

Is there any way to determine a way to map between client scale and
Geoserver scale, so that we can configure the client to track GeoServer
visibility faithfully?

Is there any way to display the internal GeoServer scale to make it
possible to confirm if this analysis is correct?


GeoServer ver 2.6 (although I believe this is happening in 2.8 as well)
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Re: [Geoserver-users] EPSG:900913 vs EPSG:3857

2016-02-15 Thread David Alda Fernandez de Lezea 
Ok Andrea.

Thanks for your help.

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: lunes, 15 de febrero de 2016 10:04
Para: David Alda Fernandez de Lezea
CC: GeoServer Users
Asunto: Re: [Geoserver-users] EPSG:900913 vs EPSG:3857

David,
I believe my previous mail contains an answer to both your questions, please 
check it again?

About selecting what's native, that's not allowed for any data source, I agree 
making it editable
would make sense for WMS cascasding though, if you feel like implementing such 
support, or sponsoring it, there is a guide you can follow here:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

Cheers
Andrea


On Mon, Feb 15, 2016 at 9:53 AM, David Alda Fernandez de Lezea  
wrote:
Andrea,

But what about selecting which is your native. Geoserver assumes that it is 
3857 in my case but the layers can be viewed on:

CRS:84
EPSG:4326
EPSG:25830
EPSG:3857

EPSG:102100

(Taken from the getcapabilites document of the remote service)

So the native selection should be made by the user in my opinion.

If I set Forced to Declared, is GeoServer making a re-projection or it's just 
using the specified SRS code and passes it to the remote requests?

Thanks.

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: lunes, 15 de febrero de 2016 9:36
Para: David Alda Fernandez de Lezea
CC: GeoServer Users
Asunto: Re: [Geoserver-users] EPSG:900913 vs EPSG:3857
On Mon, Feb 15, 2016 at 8:24 AM, David Alda Fernandez de Lezea  
wrote:
Hi Andrea,

Thanks for your response. I'll try to harvest all the information you ask me 
for as soon as possible.

Related with this I'd like to ask about something in GeoServer. When you add 
WMS cascaded DataStore and add layers from it, apparently there's no way to 
specify the CRS in which you want to consume the data. I mean, let's say the 
Remote WMS A serves data in three different CRS's. When I add a layer from it, 
the Native CRS text box is filled with a value that can't be changed and I 
can't select which is the Native CRS (can I?). This forces me to probably make 
a re-projection in cases that perhaps it wouldn't be necessary. Is there a way 
to set which is the Native CRS apart from editing the XML's?

The native CRS is internal information that is not published outside of 
GeoServer, and it's not used much
by GeoServer either.
You can set it up a "reproject from native to declared", the WMS really works 
under a "reproject from native
to requested" in that case, so if the two match, GeoServer should not be doing 
any reprojection.
At least in theory... it's been several years since I last looked in that part 
of the code, I might be remembering
it wrong.

Try it out and let us know 

Cheers
Andrea

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

Ing. Andrea

Re: [Geoserver-users] EPSG:900913 vs EPSG:3857

2016-02-15 Thread Andrea Aime 
David,
I believe my previous mail contains an answer to both your questions,
please check it again?

About selecting what's native, that's not allowed for any data source, I
agree making it editable
would make sense for WMS cascasding though, if you feel like implementing
such support, or sponsoring it, there is a guide you can follow here:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

Cheers
Andrea


On Mon, Feb 15, 2016 at 9:53 AM, David Alda Fernandez de Lezea <
da...@hazi.eus> wrote:

> Andrea,
>
> But what about selecting which is your native. Geoserver assumes that it
> is 3857 in my case but the layers can be viewed on:
>
> CRS:84
> EPSG:4326
> EPSG:25830
> EPSG:3857
> 
> EPSG:102100
>
> (Taken from the getcapabilites document of the remote service)
>
> So the native selection should be made by the user in my opinion.
>
> If I set Forced to Declared, is GeoServer making a re-projection or it's
> just using the specified SRS code and passes it to the remote requests?
>
> Thanks.
>
> 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: lunes, 15 de febrero de 2016 9:36
> Para: David Alda Fernandez de Lezea
> CC: GeoServer Users
> Asunto: Re: [Geoserver-users] EPSG:900913 vs EPSG:3857
>
> On Mon, Feb 15, 2016 at 8:24 AM, David Alda Fernandez de Lezea
>  wrote:
> Hi Andrea,
>
> Thanks for your response. I'll try to harvest all the information you ask
> me for as soon as possible.
>
> Related with this I'd like to ask about something in GeoServer. When you
> add WMS cascaded DataStore and add layers from it, apparently there's no
> way to specify the CRS in which you want to consume the data. I mean, let's
> say the Remote WMS A serves data in three different CRS's. When I add a
> layer from it, the Native CRS text box is filled with a value that can't be
> changed and I can't select which is the Native CRS (can I?). This forces me
> to probably make a re-projection in cases that perhaps it wouldn't be
> necessary. Is there a way to set which is the Native CRS apart from editing
> the XML's?
>
> The native CRS is internal information that is not published outside of
> GeoServer, and it's not used much
> by GeoServer either.
> You can set it up a "reproject from native to declared", the WMS really
> works under a "reproject from native
> to requested" in that case, so if the two match, GeoServer should not be
> doing any reprojection.
> At least in theory... it's been several years since I last looked in that
> part of the code, I might be remembering
> it wrong.
>
> Try it out and let us know
>
> 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 di Montramito 3/A
> 55054  Massarosa (LU)
> 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

Re: [Geoserver-users] EPSG:900913 vs EPSG:3857

2016-02-15 Thread David Alda Fernandez de Lezea 
Andrea,

But what about selecting which is your native. Geoserver assumes that it is 
3857 in my case but the layers can be viewed on:

CRS:84
EPSG:4326
EPSG:25830
EPSG:3857

EPSG:102100

(Taken from the getcapabilites document of the remote service)

So the native selection should be made by the user in my opinion.

If I set Forced to Declared, is GeoServer making a re-projection or it's just 
using the specified SRS code and passes it to the remote requests?

Thanks.

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: lunes, 15 de febrero de 2016 9:36
Para: David Alda Fernandez de Lezea
CC: GeoServer Users
Asunto: Re: [Geoserver-users] EPSG:900913 vs EPSG:3857

On Mon, Feb 15, 2016 at 8:24 AM, David Alda Fernandez de Lezea  
wrote:
Hi Andrea,

Thanks for your response. I'll try to harvest all the information you ask me 
for as soon as possible.

Related with this I'd like to ask about something in GeoServer. When you add 
WMS cascaded DataStore and add layers from it, apparently there's no way to 
specify the CRS in which you want to consume the data. I mean, let's say the 
Remote WMS A serves data in three different CRS's. When I add a layer from it, 
the Native CRS text box is filled with a value that can't be changed and I 
can't select which is the Native CRS (can I?). This forces me to probably make 
a re-projection in cases that perhaps it wouldn't be necessary. Is there a way 
to set which is the Native CRS apart from editing the XML's?

The native CRS is internal information that is not published outside of 
GeoServer, and it's not used much
by GeoServer either.
You can set it up a "reproject from native to declared", the WMS really works 
under a "reproject from native
to requested" in that case, so if the two match, GeoServer should not be doing 
any reprojection.
At least in theory... it's been several years since I last looked in that part 
of the code, I might be remembering
it wrong.

Try it out and let us know 

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 di Montramito 3/A
55054  Massarosa (LU)
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

Re: [Geoserver-users] EPSG:900913 vs EPSG:3857

2016-02-15 Thread Andrea Aime 
On Mon, Feb 15, 2016 at 8:24 AM, David Alda Fernandez de Lezea <
da...@hazi.eus> wrote:

> Hi Andrea,
>
> Thanks for your response. I'll try to harvest all the information you ask
> me for as soon as possible.
>
> Related with this I'd like to ask about something in GeoServer. When you
> add WMS cascaded DataStore and add layers from it, apparently there's no
> way to specify the CRS in which you want to consume the data. I mean, let's
> say the Remote WMS A serves data in three different CRS's. When I add a
> layer from it, the Native CRS text box is filled with a value that can't be
> changed and I can't select which is the Native CRS (can I?). This forces me
> to probably make a re-projection in cases that perhaps it wouldn't be
> necessary. Is there a way to set which is the Native CRS apart from editing
> the XML's?
>

The native CRS is internal information that is not published outside of
GeoServer, and it's not used much
by GeoServer either.
You can set it up a "reproject from native to declared", the WMS really
works under a "reproject from native
to requested" in that case, so if the two match, GeoServer should not be
doing any reprojection.
At least in theory... it's been several years since I last looked in that
part of the code, I might be remembering
it wrong.

Try it out and let us know

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 di Montramito 3/A
55054  Massarosa (LU)
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.

---
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

[Geoserver-users] Geoserver ImageMosaicJDBC problem with interpolation setting

2016-02-15 Thread hanshupe 
I use the ImageMosaicJDBC plugin to connect to an Oracle raster table. Maybe
someone can clarify some things about the interpolation settings. There are
multiple locations where I can define the interpolation which is confusing
to me: 

.) gdal_translate 
gdal_translate -of georaster... 
co GENPYRAMID=BILINEAR ^ 
okay this one is for the pyramid generation 

.) .xml file for ImageMosaicJDBC 
scaleop interpolation="2" 

.) GeoServer Layer setting 
Default interpolation setting=xx 

The problem I have: I get a black/grey scaled border (screenshot) around my
raster layer when I open it via WMS and I used the setting scaleop
interpolation="2" or"3" in my ImageMosaicJDBC xml (with 1-NN it would work).
Creating a layer with the same GeoTIFF, but from the file system instead of
ImageMosaicJDBC it works like expected.

 

Btw. I don't understand how that .xml file of ImageMosaicJDBC works. Is it
only accessed once when I create a new data store? Or is it accessed every
time the layer is accessed? 

Thanks for any clarification about that.



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Geoserver-ImageMosaicJDBC-problem-with-interpolation-setting-tp5250499.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users