[Geomoose-users] Scalebar & Measure

Brent Fraser bfraser at geoanalytic.com
Fri Dec 17 14:57:11 EST 2010


Johan,

   A slightly better approximation for the correction factor to 
select/buffer distances would be cos(Lat).  For example,  cos(32.5) = 
0.843   I'll leave it up to you to decide which Latitude to use, but 
center of the view would be ok for state and city scale distances.

Best Regards,
Brent Fraser


On 12/17/2010 11:44 AM, Johan Forsman wrote:
>
> 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 patchhttp://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/cd65bb8e/attachment.html


More information about the Geomoose-users mailing list