WMS anomaly in the request

Hello,

I tried to add a WMS feed but there’s an anomaly in the request.

Can you correct that please ?

Since the version 1.3 it is no longer “srs” but “crs”:

https://docs.geoserver.org/stable/en/user/services/wms/basics.html

… In the Getmap operation the srs parameter is called crs in 1.3.0. Geoserver supports both keys regardless of version…

There is also a double “&” in the request.

Finally, is it possible to include an option to change the width and height of the image?

Before (Don’t work) :

https://inspire.cadastre.gouv.fr/scpc/15014.wms?request=GetMap&service=WMS&layers=AMORCES_CAD,LIEUDIT,CP.CadastralParcel,SUBFISCAL,CLOTURE,DETAIL_TOPO,HYDRO,VOIE_COMMUNICATION,BU.Building,BORNE_REPERE&&srs=EPSG:3945&bbox=1655928.149618,4192140.039449,1660515.658208,4194248.139725&format=image/png&width=256&height=256&version=1.3&styles=

After :

https://inspire.cadastre.gouv.fr/scpc/15014.wms?request=GetMap&service=WMS&layers=AMORCES_CAD,LIEUDIT,CP.CadastralParcel,SUBFISCAL,CLOTURE,DETAIL_TOPO,HYDRO,VOIE_COMMUNICATION,BU.Building,BORNE_REPERE&crs=EPSG:3945&bbox=1655928.149618,4192140.039449,1660515.658208,4194248.139725&format=image/png&width=256&height=256&version=1.3&styles=

Thank you very much,

Thank you, @Anthony

I’ve created ticket MWGIS-214, and submitted the updates.

I have not yet looked into your sizing request.

Regards,
Jerry.

Hello,

Thanks for the fix. Do you have a release date for the next release?

Regards,
Anthony.

Hello @jerryfaust

I still have an anomaly, with the change of the parameter ‘crs’ it is necessary to reverse the longitude and latitude in the BBOX.

https://docs.geoserver.org/stable/en/user/services/wms/basics.html

Axis Ordering

The WMS 1.3.0 specification mandates that the axis ordering for geographic coordinate systems defined in the EPSG database be latitude/longitude, or y/x. This is contrary to the fact that most spatial data is usually in longitude/latitude, or x/y. This requires that the coordinate order in the BBOX parameter be reversed for SRS values which are geographic coordinate systems.

The BBOX recovery function (in the source code):

Before:

CString WmsProviderBase::GetBoundingBox(CPoint &pos, int zoom)
{
	PointLatLng pnt1;
	_projection->FromXYToProj(pos, zoom, pnt1);

	PointLatLng pnt2;
	pos.x++;
	pos.y++;
	_projection->FromXYToProj(pos, zoom, pnt2);

	CString s;
	s.Format("%f,%f,%f,%f",
		MIN(pnt1.Lng, pnt2.Lng),
		MIN(pnt2.Lat, pnt1.Lat),
		MAX(pnt2.Lng, pnt1.Lng),
		MAX(pnt1.Lat, pnt2.Lat));

	return s;
}

After :

CString WmsProviderBase::GetBoundingBox(CPoint &pos, int zoom)
{
	PointLatLng pnt1;
	_projection->FromXYToProj(pos, zoom, pnt1);

	PointLatLng pnt2;
	pos.x++;
	pos.y++;
	_projection->FromXYToProj(pos, zoom, pnt2);

	CString s;
	s.Format("%f,%f,%f,%f",
		MIN(pnt2.Lat, pnt1.Lat),
		MIN(pnt1.Lng, pnt2.Lng),
		MAX(pnt1.Lat, pnt2.Lat));
		MAX(pnt2.Lng, pnt1.Lng),
		
	return s;
}

Thanks for your help,
Regards,
Anthony.

Hello Anthony.

I’m sorry I haven’t gotten back to this until now. I notice that the change you submitted is not syntactically correct, having the closing parenthesis and terminating semi-colon after the third coordinate - MAX(pnt1.Lat, pnt2.Lat)); rather than the fourth.

I presume that you have a working implementation, and I wonder if you could submit that. I’d rather paste in your working implementation than have me enter something that might not be correct (since I’m not set up to test this and may not understand exactly what it should be).

Thank you very much.
Respectfully,
Jerry.

Hello @jerryfaust,

I just delivered my changes : https://github.com/MapWindow/MapWinGIS/pull/191

Regards,
Anthony,

Hello Anthony.

I finally got around to merging your pull request. Thank you for submitting that. It will be in the next build.

Regards,
Jerry.

Hello everybody

I am not entirely happy with these changes. As far as I can see, the values are now reversed for all WMS versions. But this is only valid for version 1.3 and (according to https://docs.geoserver.org/latest/en/user/services/wms/basics.html) only for certain EPSG.

Additionally: it is possible to output the version with 1.3.0 and not only 1.3 at WmsCustomProvider.cpp.

Regards,
Christoph

Hello Christoph (@christophsuter), and welcome.

I’ve looked into what you’re saying, and I believe you’re right. The OCX is not taking into account the WMS Version, and the coordinates of the bounding box are always reversed.

Presuming that the caller will specify the WMS Version prior to making any WMS calls, we can rely on the version to properly format the string, including

  1. srs/crs differences, and
  2. reversal of the values.

Even though GeoServer accepts either srs or crs, it makes sense to follow the documentation and provide the appropriate syntax based on the version.

Does this sound correct?

Regards,
Jerry.

Hello Jerry.

Thank you very much for the quick response. I’m actually new here and using MapGisWindow for an open source project (hopefully more about that later).

This is an idea to adjust the coordinates depending on the version. I’m a bit unsure, because in the geoserver documentation is written " axis ordering as defined in the EPSG database". That means, depending on the EPSG the axes are swapped or not. I would prefer if we had one more property which could control the process: should the coordinates be used like xy or yx as bbox. As soon as tkWmsVersion.w13 is selected, yx is selected by default.

Thanks for you help. Regards.
Christoph

Please have a look at my Pull Request: https://github.com/MapWindow/MapWinGIS/pull/199 where I added a new property tkWmsBoundingBoxOrder for defining LngLat, LatLng or Auto ordering. With Auto it takes the WMS Version for the ordering.

Best regards,
Christoph

Hello @christophsuter

I was debugging a WMS layer issue and noticed the following code in WmsProviderBase.cpp:

if (bbo == tkWmsBoundingBoxOrder::bboAuto)
{
	switch (version)
	{
	case wv13:
		bbo = tkWmsBoundingBoxOrder::bboLongLat;
	case wvEmpty:
	case wv100:
	case wv110:
	case wvAuto:
	case wv111:
	default:
		bbo = tkWmsBoundingBoxOrder::bboLongLat;

	}
} 

Every case falls through to the default. I am changing it to the following (for case wv13, making it LatLong and adding the break)

if (bbo == tkWmsBoundingBoxOrder::bboAuto)
{
	switch (version)
	{
	case wv13:
		bbo = tkWmsBoundingBoxOrder::bboLatLong;
		break;
	case wvEmpty:
	case wv100:
	case wv110:
	case wvAuto:
	case wv111:
	default:
		bbo = tkWmsBoundingBoxOrder::bboLongLat;

	}
}

I’m mentioning this a sort of a sanity check. Do you agree with this?

Thank you,
Jerry.

@jerryfaust Right, of course this has to be changed as you suggested. Please apologize that it was wrong. I have tested it, but with a geoserver version where I changed the bounding box…

Thanks a lot

Change has been submitted as a follow-up to Jira issues MWGIS-214.

1 Like

Hello @christophsuter

I didn’t understand how to change: tkWmsBoundingBoxOrder

Could you put an example please?

Thank you

Hello @Anthony

There is no public method to set the bounding box order. The order is internally set, based on the version of WMS on the server. So currently, for WMS version 1.3, the order will be Lat/Long, and for all prior versions, it will be Long/Lat.

I don’t know enough about WMS services to know whether it makes sense to allow the caller to override the order. Are there good reasons to override the defaults?

Jerry.

Hello @jerryfaust,

Yes in fact I have just read the documentation again: https://docs.geoserver.org/stable/en/user/services/wms/basics.html and it depends on the epsg.
In my case we have just changed to 3857 and it does not work because for this epsg it’s reverse : east/north and not north/east.
Would it be possible to allow modification of tkWmsBoundingBoxOrder please?

Thank you!

Is this still an issue with the latest version of MapWinGIS?

Hello,

I haven’t seen the option to reverse latitude longitude in the latest version. Besides, would it be possible to have a parameter to modify the width and height? Some WMS streams don’t work in 256*256 :frowning:

I created [MWGIS-257] Make image size of WMS adjustable for this so we won’t forget.