WFS-Search: Use actual SRS from mapframe/changeEPSG

[frankjaeger]

WFS-Search positions the Mapframe in the "initial" SRS of the gui. That's wrong, when the SRS has changed by using the "changeEPSG" gui element.

Let WFS-search ask for the actual SRS before processing a search. Then use actual SRS for positioning the mapframe.

See ALKIS (PostNAS) Mapbender-Plugin in ​http://trac.wheregroup.com/PostNAS/browser/trunk/data/mapbender/http/nav for var "$epsg" and "function sendGuiEpsg ()".

See also Ticket #712

[verenadiewald]

works for me, can you give more information?

[verenadiewald]

current gui srs is used for WFS getFeature request, so Mapbender reacts correct -> you have to ensure your wfs can deal with parameter srsName for on-the-fly-transformation

[armin11]

Replying to verenadiewald:

current gui srs is used for WFS getFeature request, so Mapbender reacts correct -> you have to ensure your wfs can deal with parameter srsName for on-the-fly-transformation

The parameter srsName will only be handled up from wfs 1.1.0. The list of supported srs for a wfs was not handled by mapbender til 2 weeks ago. Maybe mapbenders gazetteer module don't react on this? Have to be tested. In trunk, there is now a handling of different srs for each featuretype. It is mangaged in the database on loadWFS and updateWFS. Also the latlonBboxes for each featuretype are managed since 2 weeks. This is needed to fullfil the INSPIRE demands for Download Services and to generate the metadata elements!

Please test if a srs from the featuretype_epsg table is added to the WFS getfeature request in case of WFS 1.1.0.