Hi all,

tracking a Geotools scale computation bug I noticed that, besides

the bounds where the gt2 bug triggers (wide area maps) the scale

computed by the two are really different.

To give you an idea of the difference, here is what mapbuilder says

in the usual STATES geoserver demo map, and what Geoserver writes in the logs:

Full image: GS: 36.762.687,974/MB: 45,928,485

Zoom to Colorado bounds: GS 5.640.721,831/MB: 6,976,998

Zoom to Florida bounds: GS 9.905.392,698 /MB: 11,101,198

This is pretty bad for a couple of reasons:

* the diffence is so big that I think there's something more

than just a little difference in spheroids

* a user setting max/min scale denominators in the SLD

won't see them work as expected on MapBuilder

Our algorithm basically does:

* compute the screen bounds diagonal in meters, assuming 90DPI

(a comment in the code states that's the OGC standard, thought I could

not find this neither in WMS nor in SLD spec..)

* compute the orthodromic distance between the coordinates of

the lower left and upper right corners of the geographic

envelope using quite a sophisticated algorithm, see http://svn.geotools.org/geotools/branches/2.3.x/module/referencing/src/org/geotools/referencing/GeodeticCalculator.java, the method is computeDirection (since this method computes both distance and azimut).

* divide the two to get the scale.

What is the MapBuilder algorithm doing instead?

Any idea where the difference may lay?

Cheers

Andrea

Andrea,

* compute the screen bounds diagonal in meters, assuming 90DPI

(a comment in the code states that's the OGC standard, thought I could

not find this neither in WMS nor in SLD spec..)

Its near the beginning of the SLD doc - there's an entire section on

the problem (it actually say .28mm, page 27, which is about 90pdi).

* compute the orthodromic distance between the coordinates of

the lower left and upper right corners of the geographic

envelope using quite a sophisticated algorithm,

There was also an earlier discussion on this, as this isnt quite the

correct method. If you read the SLD section I mentioned above, you're

also supposed to somewhat keep the scale constant through pans.

Imagine you're looking at a bbox with a certain scale at the equator

and you pan towards the poles. According to the SLD spec you should

have a constant scale through this entire panning process (at least

for some projections). Also, if you're pulling in layers from

different mapservers, they're supposed to be calculating scale

similarly.

The problem is if you dont have a constant scale then you could be

inadvertently turning rules (min/max scale) on and off during pan

operations (also during tiling operations) which is usually considered

aesthetically unpleasing. Some users complained about this.

See the discussion on "actual vs standard map scale" in section 10.2

of the SLD spec.

So, the difference is probably mapbuilder is computing "standard

scale" and geotools is computing "actual scale".

Please read the SLD section I mentioned as its a bit complex (but

probably easy to program) but the results of doing what they say are a

bit "crazy" (especially near the poles or for projections that

significantly distort).

dave

David Blasby ha scritto:

Andrea,

* compute the screen bounds diagonal in meters, assuming 90DPI

(a comment in the code states that's the OGC standard, thought I could

not find this neither in WMS nor in SLD spec..)

Its near the beginning of the SLD doc - there's an entire section on

the problem (it actually say .28mm, page 27, which is about 90pdi).

* compute the orthodromic distance between the coordinates of

the lower left and upper right corners of the geographic

envelope using quite a sophisticated algorithm,

There was also an earlier discussion on this, as this isnt quite the

correct method. If you read the SLD section I mentioned above, you're

also supposed to somewhat keep the scale constant through pans.

Imagine you're looking at a bbox with a certain scale at the equator

and you pan towards the poles. According to the SLD spec you should

have a constant scale through this entire panning process (at least

for some projections). Also, if you're pulling in layers from

different mapservers, they're supposed to be calculating scale

similarly.

The problem is if you dont have a constant scale then you could be

inadvertently turning rules (min/max scale) on and off during pan

operations (also during tiling operations) which is usually considered

aesthetically unpleasing. Some users complained about this.

See the discussion on "actual vs standard map scale" in section 10.2

of the SLD spec.

So, the difference is probably mapbuilder is computing "standard

scale" and geotools is computing "actual scale".

Please read the SLD section I mentioned as its a bit complex (but

probably easy to program) but the results of doing what they say are a

bit "crazy" (especially near the poles or for projections that

significantly distort).

Very much agree. I read that section earlier, and sent a mail

to geotools devel proposing we change the way scale is computed.

We could make it pluggable as well.

Cc'ing geotools since I did not think about panning and scale change

issues, but they are of course there in any projected system, the

more evident the more you go away from the projection center.

Cheers

Andrea

Hi Andrea,

The problem with trying to match scale values is that there is inherent

assumptions about screen resolution. We changed ours some time ago to

match what GeoServer was using for that value.

In any case, our calculation is a very simple one: pixel resolution *

scaleFactor. For lat/long, we make a further assumption for the radius

of the earth to convert decimal degrees to meters. Pixel resolution is

an exact value so if you are comparing between systems it would be

better to use that.

From our Extent.js object:

var Rearth = 6378137.0; // Radius of the earth (sphere);

different from Proj value?

var degToMeter = Rearth*2*Math.PI/360;

//var mbScaleFactor = 72 * 39.3701; //PixelsPerInch*InchesPerMapUnit;

magic numbers

//need to determine magic number for

lat/lon

var mbScaleFactor = 3571.428; //magic number, for Geoserver SLD

compatibility

// 1/0.00028 (0.28 mm "is a common actual

size for

// contemporary display" as written in

the SLD specification ...

Mike

-----Original Message-----

From: mapbuilder-devel-bounces@lists.sourceforge.net

[mailto:mapbuilder-devel-bounces@lists.sourceforge.net] On

Behalf Of Andrea Aime

Sent: January 25, 2007 5:07 AM

To: mapbuilder-devel@lists.sourceforge.net

Cc: Geoserver-devel

Subject: [Mapbuilder-devel] Difference between MapBuilder

scale andGeoserver scale

Hi all,

tracking a Geotools scale computation bug I noticed that,

besides the bounds where the gt2 bug triggers (wide area

maps) the scale computed by the two are really different.

To give you an idea of the difference, here is what

mapbuilder says in the usual STATES geoserver demo map, and

what Geoserver writes in the

logs:

Full image: GS: 36.762.687,974/MB: 45,928,485 Zoom to

Colorado bounds: GS 5.640.721,831/MB: 6,976,998 Zoom to

Florida bounds: GS 9.905.392,698 /MB: 11,101,198

This is pretty bad for a couple of reasons:

* the diffence is so big that I think there's something more

than just a little difference in spheroids

* a user setting max/min scale denominators in the SLD

won't see them work as expected on MapBuilder

Our algorithm basically does:

* compute the screen bounds diagonal in meters, assuming 90DPI

(a comment in the code states that's the OGC standard,

thought I could

not find this neither in WMS nor in SLD spec..)

* compute the orthodromic distance between the coordinates of

the lower left and upper right corners of the geographic

envelope using quite a sophisticated algorithm, see

http://svn.geotools.org/geotools/branches/2.3.x/module/referen

cing/src/org/geotools/referencing/GeodeticCalculator.java,

the method is computeDirection (since this method computes

both distance and azimut).

* divide the two to get the scale.

What is the MapBuilder algorithm doing instead?

Any idea where the difference may lay?

Cheers

Andrea

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

-----------

Take Surveys. Earn Cash. Influence the Future of IT Join

SourceForge.net's Techsay panel and you'll get the chance to

share your opinions on IT & business topics through brief

surveys - and earn cash

http://www.techsay.com/default.php?page=join.php&p=sourceforge

&CID=DEVDEV

_______________________________________________

mapbuilder-devel mailing list

mapbuilder-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel

Adair, Mike ha scritto:

Hi Andrea,

The problem with trying to match scale values is that there is inherent

assumptions about screen resolution. We changed ours some time ago to

match what GeoServer was using for that value.

Hum, some time ago. I wonder if Geoserver changed its way of doing

things later, or if we are using an old MapBuilder release.

In any case, our calculation is a very simple one: pixel resolution *

scaleFactor. For lat/long, we make a further assumption for the radius

of the earth to convert decimal degrees to meters. Pixel resolution is

an exact value so if you are comparing between systems it would be

better to use that.

From our Extent.js object:

var Rearth = 6378137.0; // Radius of the earth (sphere);

different from Proj value?

var degToMeter = Rearth*2*Math.PI/360;

//var mbScaleFactor = 72 * 39.3701; //PixelsPerInch*InchesPerMapUnit;

magic numbers //need to determine magic number for

lat/lon

var mbScaleFactor = 3571.428; //magic number, for Geoserver SLD

compatibility

// 1/0.00028 (0.28 mm "is a common actual

size for

// contemporary display" as written in

the SLD specification ...

Definitely not the thing we are doing. But I think we may want at least a pluggable mechanism that allows for a scale computation that's "real"

and the one that works against the SLD spec (which seems to be the way

you do it btw).

Cheers

Andrea