Hi Andrea,

Thanks very much for your reply and sorry for the slow response. What you've 
described is exactly what happened - we've used the same data directory for a 
decade and just upgraded geoserver versions and apparently never had the demo 
epsg.properties file. We've now added the additional content from the Github 
link. Turns out when using this EPSG definition 
https://github.com/geoserver/geoserver/blob/f07bc711e0d4746e07ed98b08155519cf0982070/src/main/src/main/java/org/vfny/geoserver/crs/user_epsg.properties#L26C1-L26C656
 for 900913 (which differs from that at https://epsg.io/900913) the GWC issue 
disappears, and both WMS and GWC render content identically and in the correct 
location.

I've created a report of the GWC issue, it may be too niche to bother fixing 
but at least there's a record.

Cheers
Emma
________________________________
From: Andrea Aime <andrea.a...@geosolutionsgroup.com>
Sent: 21 December 2023 21:19
To: Emma Flukes <emma.flu...@utas.edu.au>
Cc: GeoServer Users <geoserver-users@lists.sourceforge.net>
Subject: Re: [Geoserver-users] Issues with GWC and Google Global Mercator 
(900913) after adding custom SRS

Hi Emma,
that's a weird situation.... EPSG:900913 is not actually part of the EPSG 
database, it's something
that the GeoServer community made up (it's "Google" written using numbers) and 
as such, it
can only exist if it's defined in the user_projections/epsg.properties file.

I'm guessing you started with a completely empty data directory, rather than 
the demo ones?
In that case GeoServer would start using a epsg.properties file found in the 
GeoServer own libraries,
but would then stop doing that once you define your own explicit 
epsg.properties, losing the EPSG:900913
definition.

The epsg.properties would normally have these contents, you should be adding 
your own extra projection to it:
https://github.com/geoserver/geoserver/blob/main/src/main/src/main/java/org/vfny/geoserver/crs/user_epsg.properties<https://github.com/geoserver/geoserver/blob/main/src/main/src/main/java/org/vfny/geoserver/crs/user_epsg.properties>

I can't find a report of this issue in the ticket tracker, could you please add 
one?
https://osgeo-org.atlassian.net/projects/GEOS/summary<https://osgeo-org.atlassian.net/projects/GEOS/summary>

Cheers
Andrea


On Wed, Dec 20, 2023 at 10:18 PM Emma Flukes 
<emma.flu...@utas.edu.au<mailto:emma.flu...@utas.edu.au>> wrote:
We recently needed to add a custom SRS for GDA2020 / Australian Albers. We did 
this successfully by creating the user_projections folder and epsg.properties 
file and adding the Geoserver one line definition from 
https://epsg.io/9473<https://epsg.io/9473>
Since then, GWC started failing for layers using Google Global Mercator 
(EPSG:900913). The behaviour was that no new tiles were generated on disc when 
interacting with cached layers at new zoom levels (no errors in logs). Seeding 
the cache also created no new tiles and this was the only error in the logs.
ERROR  [seed.MTSeeder] - Problem communicating with GeoServer
org.geowebcache.GeoWebCacheException: Problem communicating with GeoServer
We realised 900913 had disappeared from Geoserver's known SRS list since adding 
the custom SRS. Other common SRS such as EPSG:4326 that we also use for GWC 
continue to work fine.

We then added EPSG:900913 as an additional custom definition to the 
epsg.properties file, using the one-line Geoserver definition from 
https://epsg.io/900913<https://epsg.io/900913>. Google Global Mercator was 
again available from the SRS list and could be used GWC seeding as usual. We 
confirmed that new tiles were again being created on disc in the GWC directory. 
However, this custom defined 900913 SRS appears to be 'shifted' by 
approximately 15km due north (at -22 latitude), but only for tiles rendered by 
GWC. Any layers served out via WMS in 900913 without tile caching switched on 
are rendered fine, after the addition of the custom 900913 definition.

GWC is using the inbuilt gridset for 900913 (which has previously worked fine).

This is the exact contents of our epsg.properties file:
900913=PROJCS["Google_Maps_Global_Mercator",GEOGCS["WGS 
84",DATUM["WGS_1984",SPHEROID["WGS 
84",6378137,298.257223563]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]],PROJECTION["Mercator_1SP"],PARAMETER["central_meridian",0],PARAMETER["scale_factor",1],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],EXTENSION["PROJ4","+proj=merc
 +a=6378137 +b=6378137 +lat_ts=0 +lon_0=0 +x_0=0 +y_0=0 +k=1 +units=m 
+nadgrids=@null +wktext +no_defs"],AUTHORITY["EPSG","900913"]]
9473=PROJCS["GDA2020 / Australian 
Albers",GEOGCS["GDA2020",DATUM["Geocentric_Datum_of_Australia_2020",SPHEROID["GRS
 
1980",6378137,298.257222101],TOWGS84[0,0,0,0,0,0,0]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","7844"]],PROJECTION["Albers_Conic_Equal_Area"],PARAMETER["latitude_of_center",0],PARAMETER["longitude_of_center",132],PARAMETER["standard_parallel_1",-18],PARAMETER["standard_parallel_2",-36],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","9473"]]

Specific Qs:
Why has adding the custom SRS for GDA2020 caused Google Mercator to disappear 
from the SRS list? Have we missed any steps or defined this incorrectly? Is 
this a bug?
Why has re-adding Google Mercator as a custom SRS worked fine for WMS, but GWC 
now has a 'shifted' projection issue? Have we defined this incorrectly?
Is anyone successfully using both 9437 and 900913 with GWC?

This is the first custom SRS we've defined so I'm not sure whether the same 
disappearing Google Mercator issue would occur with an alternate SRS.

We're running Geoserver version 2.24.0

Thanks in advance for your help, this one has me stumped!


This email is confidential, and is for the intended recipient only. Access, 
disclosure, copying, distribution, or reliance on any of it by anyone outside 
the intended recipient organisation is prohibited and may be a criminal 
offence. Please delete if obtained in error and email confirmation to the 
sender. The views expressed in this email are not necessarily the views of the 
University of Tasmania, unless clearly intended otherwise.

_______________________________________________
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/<http://www.ianturton.com/talks/foss4g.html#/>
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html<http://geoserver.org/comm/userlist-guidelines.html>

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer<https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer>


Geoserver-users@lists.sourceforge.net<mailto:Geoserver-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-users<https://lists.sourceforge.net/lists/listinfo/geoserver-users>


--

Regards,

Andrea Aime

==
GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us<http://bit.ly/gs-services-us> for more 
information.
==

Ing. Andrea Aime
@geowolf
Technical Lead


GeoSolutions Group
phone: +39 0584 962313

fax:     +39 0584 1660272

mob:   +39  339 8844549


https://www.geosolutionsgroup.com/<https://www.geosolutionsgroup.com/>

http://twitter.com/geosolutions_it<http://twitter.com/geosolutions_it>

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa 
che ogni circostanza inerente alla presente email (il suo contenuto, gli 
eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i 
destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per 
errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei 
comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is addressed 
and may contain information that is privileged, confidential or otherwise 
protected from disclosure. We remind that - as provided by European Regulation 
2016/679 “GDPR” - copying, dissemination or use of this e-mail or the 
information herein by anyone other than the intended recipient is prohibited. 
If you have received this email by mistake, please notify us immediately by 
telephone or e-mail
_______________________________________________
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

If you want to request a feature or an improvement, also see this: 
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer


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

Reply via email to