[Geoserver-devel] OGC Scale computation (way) off when working against CRS in any unit but meters

GeoServer GeoServer Developer
1

Hi,
sorry for the cross post, but we’re close to RC1 and a user just reported
an issue of some gravity.

The current OGC scale computation code is:

public static double calculateOGCScale(ReferencedEnvelope envelope, int imageWidth, Map hints) {
// if it’s geodetic, we’re dealing with lat/lon unit measures
if(envelope.getCoordinateReferenceSystem() instanceof GeographicCRS) {
return (envelope.getWidth() * OGC_DEGREE_TO_METERS) / (imageWidth / getDpi(hints) * 0.0254);
} else {
return envelope.getWidth() / (imageWidth / getDpi(hints) * 0.0254);
}
}

Now, the geographic crs case is using a fixed conversion ratio that is given by OGC,
and that ends up dividing:
(envelope.getWidth() * OGC_DEGREE_TO_METERS) → meters
with:
imageWidth / getDpi(hints) * 0.0254 → meters

However, in the case of projected CRS, we end up with:
envelope.getWidth() → meters, feet, whatever the unit of measure of the rendering is
over
(imageWidth / getDpi(hints) * 0.0254) → meters

Which means, when computing the scale on projected CRS using anything but meters,
we get a wrong value (e.g., if it’s feet, 3 times off…)

Now, the fix is somehow obvious (we just ask Unit to provide the conversion factor),
but the consequences are not: every SLD and every scale dependent code in general
will end up being affected, and quite a bit so, but this fix.

I propose that we add a system variable to control the unit conversion, and
leave it on by default on trunk (that is, in RC1 too), and leave it dormant on
the stable series. People will still be able to switch it on and off manually
using the system variable, e.g.
-Dorg.geotoools.render.lite.scale.unitCompensation=true

What do you think?

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

+1.

···

On Fri, Aug 15, 2014 at 7:47 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
sorry for the cross post, but we’re close to RC1 and a user just reported
an issue of some gravity.

The current OGC scale computation code is:

public static double calculateOGCScale(ReferencedEnvelope envelope, int imageWidth, Map hints) {
// if it’s geodetic, we’re dealing with lat/lon unit measures
if(envelope.getCoordinateReferenceSystem() instanceof GeographicCRS) {
return (envelope.getWidth() * OGC_DEGREE_TO_METERS) / (imageWidth / getDpi(hints) * 0.0254);
} else {
return envelope.getWidth() / (imageWidth / getDpi(hints) * 0.0254);
}
}

Now, the geographic crs case is using a fixed conversion ratio that is given by OGC,
and that ends up dividing:
(envelope.getWidth() * OGC_DEGREE_TO_METERS) → meters
with:
imageWidth / getDpi(hints) * 0.0254 → meters

However, in the case of projected CRS, we end up with:
envelope.getWidth() → meters, feet, whatever the unit of measure of the rendering is
over
(imageWidth / getDpi(hints) * 0.0254) → meters

Which means, when computing the scale on projected CRS using anything but meters,
we get a wrong value (e.g., if it’s feet, 3 times off…)

Now, the fix is somehow obvious (we just ask Unit to provide the conversion factor),
but the consequences are not: every SLD and every scale dependent code in general
will end up being affected, and quite a bit so, but this fix.

I propose that we add a system variable to control the unit conversion, and
leave it on by default on trunk (that is, in RC1 too), and leave it dormant on
the stable series. People will still be able to switch it on and off manually
using the system variable, e.g.
-Dorg.geotoools.render.lite.scale.unitCompensation=true

What do you think?

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

GeoTools-Devel mailing list
GeoTools-Devel@anonymised.coms.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

–

Justin Deoliveira
VP Engineering | Boundless
jdeolive@anonymised.com
@boundlessgeo

3

Good call +1 (is this the same confusion reported on the user list?)

···

Jody Garnett

On Fri, Aug 15, 2014 at 6:47 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
sorry for the cross post, but we’re close to RC1 and a user just reported
an issue of some gravity.

The current OGC scale computation code is:

public static double calculateOGCScale(ReferencedEnvelope envelope, int imageWidth, Map hints) {
// if it’s geodetic, we’re dealing with lat/lon unit measures
if(envelope.getCoordinateReferenceSystem() instanceof GeographicCRS) {
return (envelope.getWidth() * OGC_DEGREE_TO_METERS) / (imageWidth / getDpi(hints) * 0.0254);
} else {
return envelope.getWidth() / (imageWidth / getDpi(hints) * 0.0254);
}
}

Now, the geographic crs case is using a fixed conversion ratio that is given by OGC,
and that ends up dividing:
(envelope.getWidth() * OGC_DEGREE_TO_METERS) → meters
with:
imageWidth / getDpi(hints) * 0.0254 → meters

However, in the case of projected CRS, we end up with:
envelope.getWidth() → meters, feet, whatever the unit of measure of the rendering is
over
(imageWidth / getDpi(hints) * 0.0254) → meters

Which means, when computing the scale on projected CRS using anything but meters,
we get a wrong value (e.g., if it’s feet, 3 times off…)

Now, the fix is somehow obvious (we just ask Unit to provide the conversion factor),
but the consequences are not: every SLD and every scale dependent code in general
will end up being affected, and quite a bit so, but this fix.

I propose that we add a system variable to control the unit conversion, and
leave it on by default on trunk (that is, in RC1 too), and leave it dormant on
the stable series. People will still be able to switch it on and off manually
using the system variable, e.g.
-Dorg.geotoools.render.lite.scale.unitCompensation=true

What do you think?

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

GeoTools-Devel mailing list
GeoTools-Devel@anonymised.coms.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

4

+1 too - that does explain his issue.

Ian

···

On 15 August 2014 15:24, Jody Garnett <jody.garnett@anonymised.com> wrote:

Good call +1 (is this the same confusion reported on the user list?)

GeoTools-Devel mailing list
GeoTools-Devel@anonymised.coms.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

–
Ian Turton

Jody Garnett

On Fri, Aug 15, 2014 at 6:47 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
sorry for the cross post, but we’re close to RC1 and a user just reported
an issue of some gravity.

The current OGC scale computation code is:

public static double calculateOGCScale(ReferencedEnvelope envelope, int imageWidth, Map hints) {
// if it’s geodetic, we’re dealing with lat/lon unit measures
if(envelope.getCoordinateReferenceSystem() instanceof GeographicCRS) {
return (envelope.getWidth() * OGC_DEGREE_TO_METERS) / (imageWidth / getDpi(hints) * 0.0254);
} else {
return envelope.getWidth() / (imageWidth / getDpi(hints) * 0.0254);
}
}

Now, the geographic crs case is using a fixed conversion ratio that is given by OGC,
and that ends up dividing:
(envelope.getWidth() * OGC_DEGREE_TO_METERS) → meters
with:
imageWidth / getDpi(hints) * 0.0254 → meters

However, in the case of projected CRS, we end up with:
envelope.getWidth() → meters, feet, whatever the unit of measure of the rendering is
over
(imageWidth / getDpi(hints) * 0.0254) → meters

Which means, when computing the scale on projected CRS using anything but meters,
we get a wrong value (e.g., if it’s feet, 3 times off…)

Now, the fix is somehow obvious (we just ask Unit to provide the conversion factor),
but the consequences are not: every SLD and every scale dependent code in general
will end up being affected, and quite a bit so, but this fix.

I propose that we add a system variable to control the unit conversion, and
leave it on by default on trunk (that is, in RC1 too), and leave it dormant on
the stable series. People will still be able to switch it on and off manually
using the system variable, e.g.
-Dorg.geotoools.render.lite.scale.unitCompensation=true

What do you think?

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

GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

5

On Fri, Aug 15, 2014 at 4:24 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

Good call +1 (is this the same confusion reported on the user list?)

I believe so, you reported my pull request about accurate scale computation
as a possible
solution, but it's not really addressing the same problem (as it would
probably make
the scale computation correct for that case, but would also make any
request involving
output in geographic coordinates quite far from being OGC compliant)

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

Here is a pull request:
https://github.com/geotools/geotools/pull/527

Review very much welcomed, I’m supposedly in vacation today and looking after my
children, and might not have time to look into this deeper for a good week

Cheers
Andrea

···

On Fri, Aug 15, 2014 at 3:47 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
sorry for the cross post, but we’re close to RC1 and a user just reported
an issue of some gravity.

The current OGC scale computation code is:

public static double calculateOGCScale(ReferencedEnvelope envelope, int imageWidth, Map hints) {
// if it’s geodetic, we’re dealing with lat/lon unit measures
if(envelope.getCoordinateReferenceSystem() instanceof GeographicCRS) {
return (envelope.getWidth() * OGC_DEGREE_TO_METERS) / (imageWidth / getDpi(hints) * 0.0254);
} else {
return envelope.getWidth() / (imageWidth / getDpi(hints) * 0.0254);
}
}

Now, the geographic crs case is using a fixed conversion ratio that is given by OGC,
and that ends up dividing:
(envelope.getWidth() * OGC_DEGREE_TO_METERS) → meters
with:
imageWidth / getDpi(hints) * 0.0254 → meters

However, in the case of projected CRS, we end up with:
envelope.getWidth() → meters, feet, whatever the unit of measure of the rendering is
over
(imageWidth / getDpi(hints) * 0.0254) → meters

Which means, when computing the scale on projected CRS using anything but meters,
we get a wrong value (e.g., if it’s feet, 3 times off…)

Now, the fix is somehow obvious (we just ask Unit to provide the conversion factor),
but the consequences are not: every SLD and every scale dependent code in general
will end up being affected, and quite a bit so, but this fix.

I propose that we add a system variable to control the unit conversion, and
leave it on by default on trunk (that is, in RC1 too), and leave it dormant on
the stable series. People will still be able to switch it on and off manually
using the system variable, e.g.
-Dorg.geotoools.render.lite.scale.unitCompensation=true

What do you think?

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