[Geoserver-devel] Adding a new parameter to GetMap to control the scale computation method

GeoServer GeoServer Developer
1

Hi,
I would like to propose that we add a new parameter to GetMap (and GetFeatureInfo)
requests to control how we compute the scale denominator.

The current code instructs the renderer to use the OGC compliant scale computation,
e.g.:

rendererParams.put(StreamingRenderer.SCALE_COMPUTATION_METHOD_KEY, StreamingRenderer.SCALE_OGC);

This is done for compatibility, but it’s well known that the scale computation
against geographic data is way off the true scale, the SLD spec basically
requires to use equations that assume the earth is a cylinder.

When doing GetMap to be displayed on a computer that is not an issue, as people
do not measure the map on a display by hand, but normally have a distance tool
available instead.

However, when we are using GetMap to integrate the result in a printed map, then
we have a problem: people do measure the printed map by hand, and need an
accurate result.

Indeed mapfish-print does use accurate equations (so that the printed map is actually
measurable by hand), not the OGC ones, and this is causing
issues when printing, like for example layers disappearing due to scale dependencies
triggering when they were not meant to.

So, for the sake of printing (and PDF output too), I’m proposing to add a new vendor
parameter to GetMap to control how we compute the scale:
&scaleMethod=ogc/accurate (default to ogc of course)

The method would not be part of format_options, as it’s not really format dependent,
but it would be a new top level vendor parameter.
Since it’s a new features, I’d commit it on master after the feature freeze ends

Opinions?

Cheers
Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

2

The approach sounds fine, and I agree it is not really a format option.

Aside: I am still keen to list available vendor options in the GetCapabilities vendor capabilities section (on the off chance we can “share” common vendor capabilities with MapServer and others). Is it feasible to use vendor capabilities? I feel not listing options here is a recurring mistake we are making.

···

Jody Garnett

On Mon, Aug 4, 2014 at 4:01 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
I would like to propose that we add a new parameter to GetMap (and GetFeatureInfo)
requests to control how we compute the scale denominator.

The current code instructs the renderer to use the OGC compliant scale computation,
e.g.:

rendererParams.put(StreamingRenderer.SCALE_COMPUTATION_METHOD_KEY, StreamingRenderer.SCALE_OGC);

This is done for compatibility, but it’s well known that the scale computation
against geographic data is way off the true scale, the SLD spec basically
requires to use equations that assume the earth is a cylinder.

When doing GetMap to be displayed on a computer that is not an issue, as people
do not measure the map on a display by hand, but normally have a distance tool
available instead.

However, when we are using GetMap to integrate the result in a printed map, then
we have a problem: people do measure the printed map by hand, and need an
accurate result.

Indeed mapfish-print does use accurate equations (so that the printed map is actually
measurable by hand), not the OGC ones, and this is causing
issues when printing, like for example layers disappearing due to scale dependencies
triggering when they were not meant to.

So, for the sake of printing (and PDF output too), I’m proposing to add a new vendor
parameter to GetMap to control how we compute the scale:
&scaleMethod=ogc/accurate (default to ogc of course)

The method would not be part of format_options, as it’s not really format dependent,
but it would be a new top level vendor parameter.
Since it’s a new features, I’d commit it on master after the feature freeze ends

Opinions?

Cheers
Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

On Mon, Aug 4, 2014 at 9:01 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

The approach sounds fine, and I agree it is not really a format option.

Aside: I am still keen to list available vendor options in the
GetCapabilities vendor capabilities section (on the off chance we can
"share" common vendor capabilities with MapServer and others). Is it
feasible to use vendor capabilities? I feel not listing options here is a
recurring mistake we are making.

When something bothers me, and it's not too hard to implement, I normally
go and create a pull request.
Here is a (non exaustive) list of vendor options as a starting point:
http://docs.geoserver.org/latest/en/user/services/wms/vendor.html

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

4

Thanks Andrea, I was just wondering it is only bothering me? Or if it was like a project decision I missed out on?

···

Jody Garnett

On Mon, Aug 4, 2014 at 12:30 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Aug 4, 2014 at 9:01 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

The approach sounds fine, and I agree it is not really a format option.

Aside: I am still keen to list available vendor options in the GetCapabilities vendor capabilities section (on the off chance we can “share” common vendor capabilities with MapServer and others). Is it feasible to use vendor capabilities? I feel not listing options here is a recurring mistake we are making.

When something bothers me, and it’s not too hard to implement, I normally go and create a pull request.
Here is a (non exaustive) list of vendor options as a starting point:
http://docs.geoserver.org/latest/en/user/services/wms/vendor.html

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

5

On Mon, Aug 4, 2014 at 10:21 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

Thanks Andrea, I was just wondering it is only bothering me? Or if it was
like a project decision I missed out on?

I don't think it was a project decision.

Personally I don't see the usefulness, the majority of "desktop"/non
programmable
WMS clients are not able to make anything with these options (afaik),
and these are often used in verticals where you can actually control the
requests.

Jira contains a ton of tickets, 1203 open ones in particular.

I for one looked in the pile during the last two weekends, found 30+ that
were
worth fixing and resolved them (ok, part of them were
just worth closing because incomplete and without further feedback, and a
few
of them sucked out half a day of work before getting fixed).

You can try that too, maybe you'll find something that you feel is worth
working on :slight_smile:

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

6

Hi,
here is a pull request for the topic at hand, with docs and test:
https://github.com/geoserver/geoserver/pull/674

The pull grew larger than I anticipated because looking around I’ve found that the scale
denominator was computed in different ways in different places, and sometimes it was
different than the one computed by streaming renderer.

I’ve thus centralized the scale computation in WMSMapContent and made sure the
code there matches what streaming renderer does. As a result a couple of tests
had to be modified.

Cheers
Andrea

···

On Mon, Aug 4, 2014 at 1:01 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
I would like to propose that we add a new parameter to GetMap (and GetFeatureInfo)
requests to control how we compute the scale denominator.

The current code instructs the renderer to use the OGC compliant scale computation,
e.g.:

rendererParams.put(StreamingRenderer.SCALE_COMPUTATION_METHOD_KEY, StreamingRenderer.SCALE_OGC);

This is done for compatibility, but it’s well known that the scale computation
against geographic data is way off the true scale, the SLD spec basically
requires to use equations that assume the earth is a cylinder.

When doing GetMap to be displayed on a computer that is not an issue, as people
do not measure the map on a display by hand, but normally have a distance tool
available instead.

However, when we are using GetMap to integrate the result in a printed map, then
we have a problem: people do measure the printed map by hand, and need an
accurate result.

Indeed mapfish-print does use accurate equations (so that the printed map is actually
measurable by hand), not the OGC ones, and this is causing
issues when printing, like for example layers disappearing due to scale dependencies
triggering when they were not meant to.

So, for the sake of printing (and PDF output too), I’m proposing to add a new vendor
parameter to GetMap to control how we compute the scale:
&scaleMethod=ogc/accurate (default to ogc of course)

The method would not be part of format_options, as it’s not really format dependent,
but it would be a new top level vendor parameter.
Since it’s a new features, I’d commit it on master after the feature freeze ends

Opinions?

Cheers
Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it