<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
So I did some tests on the Geomoose services (both v2.7.1 and 2.8.0)
using different Spatial Reference Systems (SRS) .<br>
<br>
The Short story:<br>
<br>
You can have the Geomoose mapping website in one SRS and the
data in another (even lat/lon) as long as the SRS of the MAP object
in the map file and the LAYER(s) in the map file are the same. For
example Geomoose website in Web Mercator, MAP object in UTM and
LAYER in UTM. Another example is Geomoose website in Web Mercator,
MAP object in Lat/Lon (e.g. EPSG:4326) and LAYER in Lat/Lon. Both
of these configurations will work with the stock Geomoose services.<br>
<br>
<br>
The Long story:<br>
<br>
A few of the PHP files make the assumption that the MAP object and
the LAYER object(s) in the map file have the same SRS. Here's a
table showing the results of my tests. All of the tests use Web
Mercator as the display SRS in Geomoose. UTM/UTM means that the MAP
object SRS is UTM as is the LAYER SRS. UTM/Geo means the MAP
object is UTM but the LAYER SRS is Lat/lon (AKA
Geographic,EPSG4326). Geo/Geo means both the MAP object and LAYER
objects SRS are Lat/lon. So you can see that as long as the MAP and
LAYER SRS are the same, the Geomoose service functions will work.<br>
<br>
<tt> v2.7.1 v2.8.0</tt><tt><br>
</tt><tt>Map/Layer SRS: UTM/UTM UTM/Geo Geo/Geo </tt><tt>UTM/UTM
UTM/Geo Geo/Geo</tt><tt><br>
</tt><tt> ======= ======= ======= ======= =======
===</tt><tt>====<br>
</tt><tt>Function:</tt><tt><br>
</tt><tt>---------</tt><tt><br>
</tt><tt>Rendering yes yes yes yes yes
yes</tt><tt><br>
</tt><tt>Printing yes yes yes </tt><tt><tt> </tt>
yes yes yes</tt><tt><br>
</tt><tt>Identify yes yes yes </tt><tt><tt>
</tt>yes yes yes</tt><tt><br>
</tt><tt> Feature Report yes no(1) yes </tt><tt><tt>
</tt>yes no(1) yes</tt><tt><br>
</tt><tt>Popups yes yes yes </tt><tt><tt>
</tt>yes yes yes</tt><tt><br>
</tt><tt>Select Features yes no(2) yes </tt><tt><tt>
</tt>yes no(2) yes</tt><tt><br>
</tt><tt> highlight yes - yes </tt><tt><tt>
</tt>yes - yes</tt><tt><br>
</tt><tt> PDF Mailing Labels yes - yes </tt><tt><tt>
</tt>yes - yes</tt><tt><br>
</tt><tt> HTML Mailing Labels yes - yes </tt><tt><tt>
</tt>yes - yes</tt><tt><br>
</tt><tt> CSV Mailing Labels yes - yes </tt><tt><tt>
</tt>yes - yes</tt><tt><br>
</tt><tt>Search Parcels yes no(3) yes </tt><tt><tt>
</tt>yes no(3) yes</tt><tt><br>
</tt><tt> highlight yes - yes </tt><tt><tt>
</tt>yes - yes</tt><tt><br>
</tt><tt> Zoom-to link yes - no(4) </tt><tt><tt>
</tt>yes - no(4)</tt><tt><br>
</tt><br>
<br>
(1) map portion empty, but parcel attributes displayed<br>
The "bug":feature_report.php assumes the map and layer portions of
the map file use the same SRS and so set the map object's extent to
the shape bounds without re-projecting it.<br>
<br>
(2) Found Shapes: 0<br>
The "bug":select.php assumes the map and layer portions of the map
file use the same SRS<br>
<br>
(3) No results found for your query! <br>
The "bug":query.php assumes the map and layer portions of the map
file use the same SRS so do not re-project the results of "$ext =
$queryLayer->getExtent();" which returns the extent of the
shapefile in the layer's SRS.<br>
<br>
(4) Zooms to the wrong location<br>
The "bug": the search_result.html template needs to be changed to
return coordinates with decimal precision:<br>
parcel-shape="[shpxy precision=5]" <br>
and of course the SRS of the coordinates must be changed to:<br>
'EPSG:4326'<br>
<br>
<br>
<pre class="moz-signature" cols="72">Best Regards,
Brent Fraser</pre>
<div class="moz-cite-prefix">On 7/27/2015 1:38 PM, Brent Fraser
wrote:<br>
</div>
<blockquote cite="mid:55B688B4.1000404@geoanalytic.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
That may be true, but it lets too many bugs/limitations through
testing. And if the functions work for Geographic coordinate
data, they will likely work for projected data sets.<br>
<br>
I think I'll try converting the parcels to geographic
coordinates and see how many functions still work...<br>
<pre class="moz-signature" cols="72">Best Regards,
Brent Fraser</pre>
<div class="moz-cite-prefix">On 7/27/2015 12:29 PM, James Klassen
wrote:<br>
</div>
<blockquote
cite="mid:CAHqX7964TX_BowH1Dsj65hw6A=ZN7pTg1dyh+euE3ySPr7eVaw@mail.gmail.com"
type="cite">
<p dir="ltr">26915 (or county coordinates) would be more
appropriate for the parcel data. First it is what it was and
second parcels are one of the most likely layers to be in a
local projection.</p>
<div class="gmail_quote">On Jul 27, 2015 12:38 PM, "Brent
Fraser" <<a moz-do-not-send="true"
href="mailto:bfraser@geoanalytic.com">bfraser@geoanalytic.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Bobb,<br>
<br>
Yes! Change the parcel data to EPSG:4326 and test the
rendering, Identify, Select Features, Search Parcels,
Printing, and Feature Report functions (that would likely
decrease my support workload by 80%).<br>
<pre cols="72">Best Regards,
Brent Fraser</pre>
<div>On 7/27/2015 8:17 AM, Basques, Bob (CI-StPaul) wrote:<br>
</div>
<blockquote type="cite"> All,
<div><br>
</div>
<div>I wonder if it wouldn’t be prudent to include data
from more than one projection in order to insure that
all reprojection conversions are working.
<div><br>
</div>
<div>bobb</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<div>
<blockquote type="cite">
<div>On Jul 26, 2015, at 12:37 PM, TC Haddad
<<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:tchaddad@gmail.com">tchaddad@gmail.com</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">
<div>
<div>
<div>
<div><br>
</div>
Just as an overall comment, there are
2 very distinct user groups for the
demo - people who only care about Web
Mercator stuff working, and people who
are trying to work in a local
projection.<br>
<br>
</div>
What we have in the demo is working
pretty well for the first group, and it
is a bit unfriendly to beginners in the
second group, as projections show up in
multiple places where beginners are
likely to run into trouble (e.g. even
setting up your zoom levels in the
Mapbook.xml). It's compounded if a user
runs into a bug, and doesn't know it's a
bug.<br>
<br>
</div>
Probably worth a review of the docs to see
how we might improve in this area...<br>
<br>
</div>
Tanya<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Jul 26,
2015 at 10:12 AM, Brent Fraser <span
dir="ltr"> <<a moz-do-not-send="true"
href="mailto:bfraser@geoanalytic.com"
target="_blank">bfraser@geoanalytic.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">Tanya,<br>
<br>
Just by looking at the code in
Github I see that there is still no
re-projection of the extent before the
query call, so i expect that is is
still broken (but I will try v2.8).
Now that I'm getting results back I
ran into the "zoom to results" bug
you've referenced, so that saved me
some time. Thanks!<br>
<br>
Personally, I think the parcel data in
our demo should be in EPSG:4326 so we
can discover these problems in our
testing before release.<br>
<pre cols="72">Best Regards,
Brent Fraser</pre>
<div>
<div>
<div>On 7/26/2015 10:57 AM, TC
Haddad wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div><br>
</div>
There was a bug that was
fixed recently that may
relate:<br>
<br>
<a moz-do-not-send="true"
href="https://github.com/geomoose/geomoose/issues/90" target="_blank">https://github.com/geomoose/geomoose/issues/90</a><br>
<br>
</div>
You could try grabbing the
relevant changes to
query.php:<br>
<br>
<a moz-do-not-send="true"
href="https://github.com/geomoose/geomoose-services/commit/dacfa7e2648c5bcd3ec38308cb1199621a07c390"
target="_blank">https://github.com/geomoose/geomoose-services/commit/dacfa7e2648c5bcd3ec38308cb1199621a07c390</a><br>
<br>
</div>
Or you could try a 2.8 install
to see if the same problem is
present (before filing a new
issue...).<br>
<br>
<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On
Sun, Jul 26, 2015 at 9:32
AM, Brent Fraser <span
dir="ltr"> <<a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:bfraser@geoanalytic.com"><a class="moz-txt-link-abbreviated" href="mailto:bfraser@geoanalytic.com">bfraser@geoanalytic.com</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
Hi Developers (and
others),<br>
<br>
While debugging a user's
problem with using his
data with query.php, I see
that line 376 in github
(or line 420-ish in GM
2.7.1):<br>
<br>
$ext =
$queryLayer->getExtent();<br>
<br>
then the layer's extent is
used for the query a
little later:<br>
<br>
$queryLayer->queryByRect($ext);<br>
<br>
This fails to find any
features since in my case
the coordinate systems of
the map and layer are
different, and the
queryByrect must be done
using a rectangle in the
MAP's SRS not the LAYER's
SRS. I did a little hack
to re-project the extent
just before the
queryByRect:<br>
<br>
//
re-project the layer's
extent into the map SRS
for querying:<br>
$map_projection_def =
$map->getProjection();<br>
$map_projection_obj =
ms_newProjectionObj($map_projection_def);<br>
<br>
if($queryLayer->getProjection()
!= NULL) {<br>
$projection =
$queryLayer->getProjection();<br>
}<br>
if($projection != NULL) {<br>
#
reproject the query shape
as available.<br>
$projection =
ms_newProjectionObj($projection);<br>
}<br>
if($projection) {<br>
$ext->project($projection,
$map_projection_obj);<br>
}<br>
if($DEBUG) {<br>
error_log(implode(',',
array($ext->minx,$ext->miny,$ext->maxx,$ext->maxy)));<br>
error_log("<br/>extent
for query in map
SRS.<br/>");<br>
}<br>
<br>
I thought I would get
comments before filing an
Issue.<br>
<br>
So any comments?<span><font
color="#888888"><br>
<br>
-- <br>
Best Regards,<br>
Brent Fraser<br>
<br>
<br>
_______________________________________________<br>
Geomoose-users mailing
list<br>
<a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:Geomoose-users@lists.osgeo.org"><a class="moz-txt-link-abbreviated" href="mailto:Geomoose-users@lists.osgeo.org">Geomoose-users@lists.osgeo.org</a></a><br>
<a
moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://lists.osgeo.org/mailman/listinfo/geomoose-users"><a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/geomoose-users">http://lists.osgeo.org/mailman/listinfo/geomoose-users</a></a><br>
</font></span></blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
_______________________________________________<br>
Geomoose-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Geomoose-users@lists.osgeo.org"
target="_blank">Geomoose-users@lists.osgeo.org</a><br>
<a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/geomoose-users"
target="_blank">http://lists.osgeo.org/mailman/listinfo/geomoose-users</a></div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Geomoose-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Geomoose-users@lists.osgeo.org">Geomoose-users@lists.osgeo.org</a><br>
<a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/geomoose-users"
rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/geomoose-users</a><br>
</blockquote>
</div>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Geomoose-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Geomoose-users@lists.osgeo.org">Geomoose-users@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/geomoose-users">http://lists.osgeo.org/mailman/listinfo/geomoose-users</a></pre>
</blockquote>
<br>
</body>
</html>