[Geoserver-users] Issues with GWC and Google Global Mercator (900913) after adding custom SRS

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
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. 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=@anonymised.com +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.

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

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

Cheers
Andrea

···

Regards,

Andrea Aime

==
GeoServer Professional Services from the experts!

Visit 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/

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

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.aime@…10949…>
Sent: 21 December 2023 21:19
To: Emma Flukes <emma.flukes@…2348…>
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

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

Cheers
Andrea

On Wed, Dec 20, 2023 at 10:18 PM Emma Flukes <emma.flukes@…2348…> 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
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. 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:

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

Regards,

Andrea Aime

==
GeoServer Professional Services from the experts!

Visit 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/

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