[Geomoose-users] Scalebar & Measure

Fri Dec 17 13:44:29 EST 2010

Yes, I also just attempted the geodesic:true setting both in main.js and compiled.js and it has no effect on the scale line. Was it not implemented in 2.8 perhaps? Well never mind; I just saw your followup indicating just that.

On point 2, if no OL function currently exists to perform the necessary correction, might it be possible to crudely apply a correction factor somewhere in the GM code for the selection buffer? It won't be accurate, but it will be substantially less inaccurate than the current state. Since mine appear to range from 0.89 to 0.86 (south to north) I might chose to use 0.875, which at worst results in a 2% deviation from the "true" value. Applied to the earlier example my 1-mile selection radius might then only be 0.98 miles (~100 feet to short), but this is far better than the current result of 0.86 miles.

From: Brent Fraser [mailto:bfraser at geoanalytic.com]
Sent: Friday, December 17, 2010 10:01 AM
To: Johan Forsman
Cc: 'geomoose-users at lists.sourceforge.net'
Subject: Re: [Geomoose-users] Scalebar & Measure

Johan,

  Interesting stuff.

  Looking at my experimental source from a few months back, I had added a property to main.js around line 98:

    if(CONFIGURATION.scale_line.enabled) {
        Map.addControl(new OpenLayers.Control.ScaleLine({
            bottomOutUnits: CONFIGURATION.scale_line.bottom_units,
            topOutUnits: CONFIGURATION.scale_line.top_units,
            geodesic: true,    /* bfraser */
            maxWidth: CONFIGURATION.scale_line.width
        }));
    }

but testing today it seems to have no effect in "correcting" the scalebar length.  I'll have to do more investigation.  Note from the OpenLayers doc:
geodesic

{Boolean} Use geodesic measurement.  Default is false.  The recommended setting for maps in EPSG:4326 is false, and true EPSG:900913.  If set to true, the scale will be calculated based on the horizontal size of the pixel in the center of the map viewport.

Your point 2 is a tough one.  The search radius is a map projection distance and would have to be corrected by the map projection point scale factor, or adjusted to be a geodesic distance.  I don't know if OpenLayers has a function to do either of those.

Best Regards,

Brent Fraser

On 12/17/2010 8:04 AM, Johan Forsman wrote:

All:

I just discovered this issue. After applying Brent's fix below the measure tool appears to return the correct values, but there are other remaining issues.

I am using the 900913 projection for all data.

1. The scale bar is off. 500 meters on the scale bar measures to 431 meters, or a factor of ~0.86. This is not a critical issue, but it would be "nice" if it measured the same.

2. The select feature, using By Point, is a very clever way to get all features within a certain radius of a point location. However this function will return a radius that is shorter by about the same amount as the scale bar. This is an important issue. I have attached 3 screenshots illustrating the problem.

The GM shot shows what is supposed to be a 1-mile radius, plus the new measurement (post-fix) to the most distant feature of interest.

The GE-EC shot shows the measured distance using an all-Google application.

The ArcGIS shot shows the actual size of a circle with an (presumably ArcGIS is authoritative) 1-mile radius in the same location. These data are in NAD83 UTM 15N.

I measured the scale factors on a 200 meter scale bar (1:6771) for my state (Louisiana) and found them to be about 0.86 at the northern extreme and 0.89 at the southern extreme.

Is there any way I can implement some type of automatic correction to the select tool, and any other tool that may be affected by this behavior? Certainly I can inform the users that they need to add x % to their chosen buffer, but I am not prepared to trust the users to really do that.

Thanks!

/Johan.

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

From: Brent Fraser [mailto:bfraser at geoanalytic.com]

Sent: Wednesday, May 26, 2010 1:53 PM

To: Len Kne

Cc: 'geomoose-users at lists.sourceforge.net<mailto:geomoose-users at lists.sourceforge.net>'

Subject: Re: [Geomoose-users] Scalebar & Measure

Len(and others interested in measuring),

   Here's my solution to the measure problem:

In main.js somewhere around line 138 add the two lines below marked with a

"//BWF":

 Tools['measure'] = new

OpenLayers.Control.GeoMooseMeasure(OpenLayers.Handler.MeasurePath,

measureToolOptions);

 Tools['measure'].geodesic = true;  //BWF

 Tools['measurearea'] = new

OpenLayers.Control.GeoMooseMeasure(OpenLayers.Handler.MeasurePolygon,

measureToolOptions);

 Tools['measurearea'].geodesic = true;  //BWF

Thoughts?

Brent

Brent Fraser wrote:

Paul, Len,

   Our scale problem is a (mostly) map projection issue.  All map

projections

introduce distortions in trying to represent a round(ish) Earth on a

flat plane.

  Mercator is no different: it is like wrapping an up-right cylinder

around the

Earth, projecting light from the center onto the cylinder

(http://en.wikipedia.org/wiki/Mercator_projection).  As you can imagine

the

distortions get "worse" the further from the equator.   The distortions

can be

modeled as a Point Scale Factor.  At the equator the Point Scale Factor

is 1.0,

at latitude 60 degrees North (or South), the scale factor is 0.5!

   So what's the solution?  Here's mine:

   1. Enhance Proj4 (and Proj4js) to return the Point Scale factor

(given the

projection and a location)

   2. Enhance MapServer and Openlayers to use the Point Scale Factor in

calculating distances and scale.

I'm trying to drum up interest, but so no takers....

   http://osgeo-org.1803224.n2.nabble.com/Point-Scale-factor-service-

td4938743.html

http://osgeo-org.1803224.n2.nabble.com/Re-3265-Scale-dependent-layer-

switching-error-with-Mercator-td4966902.html

Best Regards,

Brent Fraser

Len Kne wrote:

The scale bar issue with the web Mercator projection is a limitation of

OpenLayers, the application GeoMOOSE 2.x uses to render the map frame.

  There has been discussion on the OpenLayers site about providing a

patch (this link offers a patch http://trac.openlayers.org/ticket/1890

)

in the next version 2.9.  I'm sure GM will upgrade to OL 2.9, but not

sure there is any schedule in place to do this.

The cursor issue is also kind of fun because it seems each browser

handles the custom icons differently.  Here's the attribute in the

mapbook which defines the query for the Identify service:

cursor="url('cursors/identify2.cur') 9

9,url('cursors/identify2.cur'),auto"

This makes three attempts to draw the cursor, the first offsets the

mouse click 9 pixels from the top and the left.  Firefox can use this

value and seems to line the mouse click up pretty good with the

crosshair.  However, IE cannot handle the offset adjustment, so it

reads

the second cursor definition.  There are tools like AT File Mole which

can be used to edit the hotspot of a cursor.  Attached is the latest

version I have been using for Identify service, again this seems to

line

the crosshair up pretty well with the mouse click.  If you are using

Safari or Chrome, these setting don't seem to work at all and I would

recommend not using customer cursors with those browsers.

Len

*From:* Wirth, Paul [mailto:Paul.Wirth at kniferiver.com]

*Sent:* Saturday, May 01, 2010 9:03 PM

*To:* 'geomoose-users at lists.sourceforge.net<mailto:geomoose-users at lists.sourceforge.net>'

*Subject:* [Geomoose-users] Scalebar & Measure

Two questions:

1.       I have a web Mercator application, and I noticed that the

scalebar does not display the correct distance.  For instance, when the

scalebar shows a distance of 20 miles, it measures only 13.8 miles.  I

know the measure tools are working correctly, so I assume this is a

scalebar issue.  Any thoughts on how to fix this?

2.       I think this question was asked before, but I can't seem to

find it on the e-mail list.  With the measure tools, the cursor does

not

start measuring at the "crosshairs" when the user clicks, but rather in

the NW quadrant of the crosshairs.  Is there a way to change it so the

measure start point will be on the crosshairs?

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

-

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

-------

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

-

_______________________________________________

Geomoose-users mailing list

Geomoose-users at lists.sourceforge.net<mailto:Geomoose-users at lists.sourceforge.net>

https://lists.sourceforge.net/lists/listinfo/geomoose-users

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

------

_______________________________________________

Geomoose-users mailing list

Geomoose-users at lists.sourceforge.net<mailto:Geomoose-users at lists.sourceforge.net>

https://lists.sourceforge.net/lists/listinfo/geomoose-users

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

----

_______________________________________________

Geomoose-users mailing list

Geomoose-users at lists.sourceforge.net<mailto:Geomoose-users at lists.sourceforge.net>

https://lists.sourceforge.net/lists/listinfo/geomoose-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geomoose-users/attachments/20101217/f5f7e9f8/attachment.html