[Geomoose-users] Dealing with scales
Jim Klassen
klassen.js at gmail.com
Thu Jun 20 07:15:35 PDT 2013
You probably need to create the projection definition.
in ...wherever geomoose is.../htdocs/projections
create a EPSG2263.js file with the following line in it:
Proj4js.defs["EPSG:2263"] = "+proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666 +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001 +y_0=0 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048006096012192 +no_defs";
Then add the EPSG2263.js file to geomoose.html and geomoose_dev.html (next to or replace the one for EPSG26915)
On Jun 20, 2013, at 8:54 AM, Robert R. Raiz wrote:
> Hello Jim,
>
> In the mapbook I have the following params:
>
> <param name="projection">EPSG:2263</param>
> <param name="max_extent">1115163,61542,1581609,527988</param>
> <param name="initial_extent">1115163,61542,1581609,527988</param>
> <param name="always_scroll_zoom">true</param>
> <param name="measure_tool.show_area_segments">false</param>
> <param name="layer_controls.metadata.on">false</param>
> <param name="group_checkboxes">true</param>
> <param name="default_tab">Catalog</param>
> <param name="ground_units">ft</param>
> <param name="maxResolution">156543.03390625</param>
> <param name="numZoomLevels">20</param>
> <param name="reference_map.enabled">false</param>
> <param name="coordinate_display.usng">true</param>
> <param name="fractional_zoom">true</param>
>
> I added the <param name="ground_units">ft</param> following your advice and it is almost perfect (1:43157 GeoMoose and 1:448286 Chameleon);
>
> One thing I noticed in Firebug. Although I can see the layers, I get two errors (atually, one - 2 times):
>
> GET EPSG2263.js 404 NotFound (/geomoose/libs/proj4js/lib/defs/EPSG2263.js was not found on this server)
>
>
> On Thu, Jun 20, 2013 at 4:13 PM, Jim Klassen <klassen.js at gmail.com> wrote:
> It looks like CONFIGURATION.ground_units is simply being passed into OpenLayers as OpenLayers.Map.units. The scale combo-box is using OpenLayers.Map.getScale.
>
> The OpenLayers page [1] says it supports feet, but indicates the parameter is only used if it is not defined in the projection. What projection do you have set in the configuration section of your mapbook? Alternatively, what do the following three lines output from Firebug (or other javascript console) while viewing your GeoMoose site?
>
> ====
>
> Map.getProjection();
>
> Map.units;
>
> Map.getProjectionObject().proj.units;
>
> ====
>
> Digging up my old county coordinates example... Proj4js doesn't seem to recognize units=sft. Map.units = "m" and proj.units = "null". If I set:
>
> <param name="ground_units">ft</param>
>
> Then Map.units="ft" and the initial scale changes from 1:6933504 with meters to 1:2113331 with feet (a factor of ~ 3.28 which is what would be expected).
>
> [1] http://dev.openlayers.org/docs/files/OpenLayers/Map-js.html#OpenLayers.Map.units
>
> On Jun 20, 2013, at 2:46 AM, Robert R. Raiz wrote:
>
>> Hello all,
>>
>> Did some more research on this and I would point out a few aspects.
>>
>> I tested with the demo files and there, it all seems ok. The thing is, in the demo shapefile, we have the data in meters and so is the mapbook.xml file configured. eg: <param name="ground_units">m</param>.
>>
>> All my shapes, projections, all the data I have is in feet. I guess this is the problem as I don't think there is a ground_units param for feet (only ‘m’, ‘in’, ‘mi’, ‘dd’).
>>
>> The only place where I found something related to feet was in the \geomoose\htdocs\php\print.php file which deals with the print option:
>>
>> if($ground_units == 'ft') {
>> $inches_per_unit = 12.0;
>> }
>>
>> Really close to the difference I gave as an example in my first post (1:448286 - Chameleon and in GeoMoose I have 1:35203 for the same extent); 448286/35203 =~ 12,7
>>
>> As I am not a developer (but would like to be sometime in the future), I would need some guidelines as to where I could add/modify/update the ground_unit param (eg: <param name="ground_units">ft</param>) so GeoMoose could treat correctly the feet unit of measurement and have a correct scale. I think it would be a huge enhancement for this to be supported as especially US data is kept mostly in projections using feet.
>>
>> I really appreciate all the feedback received,
>>
>>
>> On Wed, Jun 19, 2013 at 9:30 PM, James Klassen <klassen.js at gmail.com> wrote:
>> I second that. Even feet vs meters should only be a factor of 3. My experience is GeoMoose scales are close to but not exactly the same as MapServer scales (when DPI is left as defaults). I haven't tried a site using feet lately, but I know it used to work (the first GeoMoose site was in feet.)
>>
>> I'm sorry I am too swamped right now to dig into this further at the moment. Hopefully someone else on the list can help you more.
>>
>> On Jun 19, 2013 11:07 AM, "Brent Fraser" <bfraser at geoanalytic.com> wrote:
>> Since the difference in the reported scale between Chameleon and Geomoose is over an order of magnitude, I suspect there is a units mis-configuration somewhere. Just where depends on which reported scale is closer to what's expected...
>>
>> Best Regards,
>> Brent Fraser
>> On 6/19/2013 9:37 AM, Robert R. Raiz wrote:
>>> Hello James,
>>>
>>> Well, yes, actually for me it is important to know that the MINSCALE / MAXSCALE from map files will be read accordingly in GeoMoose. I need the correspondence between them to be correct and to be able to check the correct rendering of features.
>>>
>>> I tested today and it seems what I have in the lower right part (GeoMoose) is not quite ok compared to what I have in the mapfile (I am only referring to scale here);
>>>
>>> To sum up, seeing the big difference between the scales in Chameleon and GeoMoose at the same extent, I do not understand how this could work. To give a short eg: I have a class rendered in the mapfile between MINSCALE 2000 and MAXSCALE 6000. How can see this range (class) in GeoMoose if I cannot rely on the scale in the bottom right corner.
>>>
>>> Hope I am not missing something here :)
>>>
>>>
>>> On Wed, Jun 19, 2013 at 6:08 PM, James Klassen <klassen.js at gmail.com> wrote:
>>> Not really since the browsers don't accurately report screen DPI, so traditional scales in the interactive map are rather meaningless. The main place the scale is important is to allow printing to a known scale. Assuming GeoMoose's DPI matches MapServer's (and I think it is at least close), it also helps when setting min/max scale denominators in MapServer layers/classes.
>>>
>>> The scale reported in the interface (in the drop down in the lower right) is a scale assuming some nominal display DPI. (Either 72, 75 or 96 I think, but would have to check to be sure.)
>>>
>>> The scales parameter in the mapbook is actually a resolution. (It is simply passed into OpenLayers to setup the zoom levels, primarily for the popular tiled basemaps.)
>>>
>>> On Jun 19, 2013 9:41 AM, "Robert R. Raiz" <raizrobert at gmail.com> wrote:
>>> Oh, as usual, I find something right after I post..
>>> I read that "The scales are actually ground units per pixel resolution settings and not true scales. "
>>>
>>> Is it possible to somehow change this to render actual scales?
>>>
>>>
>>> On Wed, Jun 19, 2013 at 5:33 PM, Robert R. Raiz <raizrobert at gmail.com> wrote:
>>> Hello all,
>>>
>>> As I said in a previous post, I am trying to replace the old Chameleon web mapping tool with GeoMoose.
>>>
>>> Something that I did not quite understand, is why the scales are different in these two mapping tools if they have the same extent;
>>>
>>> So, I have an extent in the mapfile. Chameleon is giving me a scale of 448286 and in GeoMoose I have 1:35203
>>>
>>> Can you please tell me what am I missing? I first thought that it has something to do with the ground_units param (as I need the units in feet);
>>>
>>> Thank you,
>>> --
>>> Raiz Roland Robert
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Raiz Roland Robert
>>>
>>>
>>>
>>> _______________________________________________
>>> Geomoose-users mailing list
>>> Geomoose-users at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>>>
>>>
>>>
>>>
>>> --
>>> Raiz Roland Robert
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Geomoose-users mailing list
>>> Geomoose-users at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>>
>>
>> _______________________________________________
>> Geomoose-users mailing list
>> Geomoose-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>>
>>
>>
>>
>> --
>> Raiz Roland Robert
>>
>>
>
>
>
>
> --
> Raiz Roland Robert
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-users/attachments/20130620/febf985c/attachment.html>
More information about the Geomoose-users
mailing list