Hi,
so, finally I found a solution although I still don't know the cause:
After some searching on the server I found out that below
$GEOSERVER_DATA_DIR/gwc_layers a xml-config-file for each gwc-layer is created.
For the problematic layer the corresponding xml-file had a wrong extend.
After deletion of the xml-file a restart of the tomcat was necessary as GWC was
throwing an exception when one of the web-GUIs of the integrated GWC was
accessed.
After restarting tomcat I had to reactivate "Create a cached layer" in the
"Cache-Tab" of the specific layer (I do not know the real names of the check
boxes and tabs as my Geoserver-GUI is in German (BTW is there a way to switch
the GUI to another language?)).
After "Save" the xml-config-file for the layer was created again in
$GEOSERVER_DATA_DIR/gwc_layers. Up to here the XML-file has no
extend-information but the gridSetName is already defined.
I then created the cache and the result was as expected.
I hope this might help somebody in the future. Is this seen as a bug and should
I file a ticket? I can't actually tell when and why the wrong extend made its
way in the config-file.
Here's a part of output of diff -u "wrong xml" "correct xml":
<extent>
<coords>
- <double>239323.44497139292</double>
+ <double>200000.0</double>
<double>5129639.24594039</double>
- <double>812763.4449713929</double>
+ <double>1032886.6793141605</double>
<double>6200000.0</double>
</coords>
</extent>
Regards
Torsten
-----Ursprüngliche Nachricht-----
Von: Drey, Torsten
Gesendet: Dienstag, 7. Februar 2017 10:28
An: [email protected]; 'Julian Hollingbery'
Betreff: AW: [Geoserver-users] Caching beyond the bounds of a UTM Zone
Hi Julian,
yes, you are right that I should be careful with setting the alignement.
Unfortunately, it doesn't change the behavior.
I changed the <alignTopLeft> to "true", but the effect still is there. BTW, the
effect is also there when I use the integrated demo from GWC.
I then also tested another layer (just in case..), the result is all the same.
What also seems strange to me is that I can query the not-displaying tiles in
the GWC-Demo. Here is another screenshot which is documenting this:
https://drive.google.com/open?id=0B0Id8TV87m2qU1cyNGxtQ1pjLUk
You can see the pointer used for querying and the result below the map. So, the
data is somehow present but not displaying. Does this behavior maybe help to
identify the cause? Or is this just because the GetFeatureInfo is handled by
Geoserver?
In general I assume the set up is fine as the layer is cached and displaying
correctly in the scales 1:4M and 1:2M. I just don't see a reason for not
caching correctly in greater scales.
Best regards
Torsten
-----Ursprüngliche Nachricht-----
Von: Julian Hollingbery [mailto:[email protected]]
Gesendet: Montag, 6. Februar 2017 17:02
An: Drey, Torsten; [email protected]
Betreff: SV: [Geoserver-users] Caching beyond the bounds of a UTM Zone
Hi Torsten,
I notice that you have
<alignTopLeft>false</alignTopLeft>
I don't have that tag in my geowebcache.xml at all. Mind you, it is quite a lot
of versions since I configured my GWC..
Reading
http://geowebcache.org/docs/current/concepts/gridsets.html#from-gridsets-to-tiles,
I wonder if you are using WMTS in QGIS, and it might make a difference for you
setting it to "true" or omitting it?
Regards,
Julian
-----Oprindelig meddelelse-----
Fra: [email protected] [mailto:[email protected]]
Sendt: 6. februar 2017 16:19
Til: [email protected]
Emne: Re: [Geoserver-users] Caching beyond the bounds of a UTM Zone
Hi,
thanks for your reply Julien; it helped to know that it should work in general!
I made some progress regarding the caching of a layer in utm zone 32 and 33 but
it doesn't work out completely.
What I did is to truncate the old cache and create a new grid set. I also
changed the bounds a little bit.
Here's an extract from geowebcache.xml:
<srs>
<number>25832</number>
</srs>
<extent>
<coords>
<double>200000.0</double>
<double>5100000.0</double>
<double>1300000.0</double>
<double>6200000.0</double>
</coords>
</extent>
<alignTopLeft>false</alignTopLeft>
<scaleDenominators>
<double>4000000.0</double>
<double>2000000.0</double>
<double>1000000.0</double>
<double>500000.0</double>
<double>250000.0</double>
<double>100000.0</double>
<double>50000.0</double>
<double>25000.0</double>
<double>10000.0</double>
<double>5000.0</double>
<double>2500.0</double>
What is working:
For the scales 1:4.000.000 and 1:2.000.000 the tiles are generated as expected.
What is not working:
For every larger scale tiles are missing in the east. It's probably best
described with some screenshots:
I did the screenshots from inside QGIS. On top of the hillshaded dem (in grey;
this is the one to be tiled, loaded as WMTS in QGIS) is a layer of germany (in
blue, just to make things clearer).
Here is correct example for 1:2.000.000:
https://drive.google.com/open?id=0B0Id8TV87m2qSFRZOGRPaDg0TGs
Here is one for 1:1.000.000:
https://drive.google.com/open?id=0B0Id8TV87m2qYnk1S1Z5dk4tSHM
You can already see that tiles are missing in the east.
And finally one for 1:500.000:
https://drive.google.com/open?id=0B0Id8TV87m2qZ1kzd0FPOE5XQ3c
And the issue is getting more obvious.
All the tiles are generated just fine in all other directions, i.e. north,
south, west.
Does somebody maybe have an idea which would point me in the right direction?
Thanks & best regards
Torsten
-----Ursprüngliche Nachricht-----
Von: [email protected]
[mailto:[email protected]]
Gesendet: Dienstag, 31. Januar 2017 09:33
An: [email protected]
Betreff: Geoserver-users Digest, Vol 128, Issue 48
Send Geoserver-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/geoserver-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific than "Re:
Contents of Geoserver-users digest..."
Today's Topics:
1. Caching beyond the bounds of a UTM Zone
([email protected])
2. Re: Caching beyond the bounds of a UTM Zone (Julian Hollingbery)
----------------------------------------------------------------------
Message: 1
Date: Tue, 31 Jan 2017 07:21:10 +0000
From: <[email protected]>
Subject: [Geoserver-users] Caching beyond the bounds of a UTM Zone
To: <[email protected]>
Message-ID:
<1331e1d0258149928f3f67f60bf21...@he105660.emea1.cds.t-internal.com>
Content-Type: text/plain; charset="us-ascii"
Dear List,
I posted my question already on the GeoWebCache-mailing list but there is not
much traffic on the mailing list (2 Posts in January) and I'm not sure if the
list is still used frequently. As I didn't get any response there I try it
here; sorry if this is seen as a double posting.
Here's what I would like to achieve and the related question/problem:
I would like to cache data with GWC which is extending one EPSG-Projection and
UTM Zone.
The data covers Germany and is projected to ETRS89 / UTM Zone 32N, i.e.
EPSG:25832. As Germany extends the bounds of EPSG:25832 the eastern part of the
data "belongs" actually to UTM Zone 33N (EPSG:25833).
I defined a gridset based on EPSG:25832 but extended the bounds of the gridset
to the east in order to cover the data/Germany completely.
When the data is cached with gwc, the caching is not executed for the data
which extends the projected bounds of EPSG:25832, i.e. the self-defined gridset
bounds are ignored.
Is this the normal and desired behavior? Is there a way to get the data cached
beyond the natural EPSG-bounds?
For me it seems like a normal use case, but I couldn't find a solution yet.
I'm using:
Geoserver 2.10.0 with the integrated GWC. Geoserver is running on Java
1.8.0_102 64bits, Red Hat 6.5
The projected bounds of EPSG:25832 are (according to geoserver):
Min X: 239,323.44497139292
Min Y: 4,290,144.074117256
Max X: 760,676.555028607
Max Y: 9,320,086.206909368
Whereas my defined gridset extends those bounds to the east. Max X is
therefore: 930,000.
Thanks & best regards
Torsten
--------------------------------------------------------------------------
T-Systems International GmbH
Telekom-IT
Torsten Drey
Oberkasseler Strasse 2, 53227 Bonn, Germany
+49 228 9841-3690 (Phone)
+49 228 9841-3990 (Fax)
E-Mail: [email protected]<mailto:[email protected]>
Internet: http://www.t-systems.com
PegaProducts: http://www.pegaware.com/
www.t-systems.de/pflichtangaben<http://www.t-systems.de/pflichtangaben>
www.t-systems.com/compulsory-statement<http://www.t-systems.com/compulsory-statement>
Big changes start small - conserve resources by not printing every e-mail.
Notice: This transmittal and/or attachments may be privileged or confidential.
It is intended solely for the addressee named above. Any dissemination, or
copying is strictly prohibited. If you received this transmittal in error,
please notify us immediately by reply and immediately delete this message and
all its attachments. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 2
Date: Tue, 31 Jan 2017 08:32:53 +0000
From: Julian Hollingbery <[email protected]>
Subject: Re: [Geoserver-users] Caching beyond the bounds of a UTM Zone
To: "[email protected]" <[email protected]>,
"[email protected]"
<[email protected]>
Message-ID:
<db6pr0502mb290235a2c3e6c1cc93b36a01bb...@db6pr0502mb2902.eurprd05.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Don't know how helpful this is to you, but just to say that it is possible:
On our standalone GWC 1.9.1, retrieving WMS from a GeoServer 2.9.1, I have a
tileset running EPSG:25832 nicely within these bounds:
<extent>
<cords>
<double>200000</double>
<double>5997000</double>
<double>930000</double>
<double>6450000</double>
</cords>
</extent>
Regards,
/julian
Fra: [email protected] [mailto:[email protected]]
Sendt: 31. januar 2017 08:21
Til: [email protected]
Emne: [Geoserver-users] Caching beyond the bounds of a UTM Zone
Dear List,
I posted my question already on the GeoWebCache-mailing list but there is not
much traffic on the mailing list (2 Posts in January) and I'm not sure if the
list is still used frequently. As I didn't get any response there I try it
here; sorry if this is seen as a double posting.
Here's what I would like to achieve and the related question/problem:
I would like to cache data with GWC which is extending one EPSG-Projection and
UTM Zone.
The data covers Germany and is projected to ETRS89 / UTM Zone 32N, i.e.
EPSG:25832. As Germany extends the bounds of EPSG:25832 the eastern part of the
data "belongs" actually to UTM Zone 33N (EPSG:25833).
I defined a gridset based on EPSG:25832 but extended the bounds of the gridset
to the east in order to cover the data/Germany completely.
When the data is cached with gwc, the caching is not executed for the data
which extends the projected bounds of EPSG:25832, i.e. the self-defined gridset
bounds are ignored.
Is this the normal and desired behavior? Is there a way to get the data cached
beyond the natural EPSG-bounds?
For me it seems like a normal use case, but I couldn't find a solution yet.
I'm using:
Geoserver 2.10.0 with the integrated GWC. Geoserver is running on Java
1.8.0_102 64bits, Red Hat 6.5
The projected bounds of EPSG:25832 are (according to geoserver):
Min X: 239,323.44497139292
Min Y: 4,290,144.074117256
Max X: 760,676.555028607
Max Y: 9,320,086.206909368
Whereas my defined gridset extends those bounds to the east. Max X is
therefore: 930,000.
Thanks & best regards
Torsten
--------------------------------------------------------------------------
T-Systems International GmbH
Telekom-IT
Torsten Drey
Oberkasseler Strasse 2, 53227 Bonn, Germany
+49 228 9841-3690 (Phone)
+49 228 9841-3990 (Fax)
E-Mail: [email protected]<mailto:[email protected]>
Internet: http://www.t-systems.com
PegaProducts: http://www.pegaware.com/
www.t-systems.de/pflichtangaben<http://www.t-systems.de/pflichtangaben>
www.t-systems.com/compulsory-statement<http://www.t-systems.com/compulsory-statement>
Big changes start small - conserve resources by not printing every e-mail.
Notice: This transmittal and/or attachments may be privileged or confidential.
It is intended solely for the addressee named above. Any dissemination, or
copying is strictly prohibited. If you received this transmittal in error,
please notify us immediately by reply and immediately delete this message and
all its attachments. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech
sites, SlashDot.org! http://sdm.link/slashdot
------------------------------
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
End of Geoserver-users Digest, Vol 128, Issue 48
************************************************
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech
sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
