<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Dan,<br>
    <br>
      I'm not sure I need to file a ticket, based on my table below from
    the previous email.<br>
    <br>
      I deal with data from all of the the world, so I like to keep the
    data in a common coordinate system (epsg:4326, AKA lat/Lon WGS84). 
    And I like using Geomoose configured to display the data in Web
    Mercator.  So my new rule is to set up my map files to be:<br>
    <br>
    MAP<br>
        PROJECTION<br>
            "+init=epsg:4326"<br>
        END # of PROJECTION<br>
        :<br>
        LAYER<br>
            :  # no need for a projection object here<br>
        END # Layer<br>
    END # Map<br>
    <br>
      I used to set my MAP Projection to the output projection
    (old-school mapserver), but since Geomoose uses WMS protocol to
    request a rendered image from mapserver, it passes the desired
    projection (Web Mercator) and it is all good.<br>
    <br>
    i just need to make sure I edit my search template to be (note the
    "precision=5" and "EPSG:4326"):<br>
    <br>
    <tt><!-- MapServer Template --></tt><tt><br>
    </tt><tt><b>PLOT NO:</b> <a data-pin="[PLOTNO_1]"
      id="gm-parcel-[PLOTNO_1]" class='sprite-control
      sprite-control-find-selected' style="padding-left: 22px"
      parcel-shape="[shpxy <b>precision=5</b>]"
      href="<a class="moz-txt-link-freetext" href="javascript:GeoMOOSE.zoomToPointsList(dojo.byId('gm-parcel">javascript:GeoMOOSE.zoomToPointsList(dojo.byId('gm-parcel</a>-[PLOTNO_1]').getAttribute('parcel-shape'),
      '<b>EPSG:4326</b>');">[PLOTNO_1]</a><br/></tt><tt><br>
    </tt><tt><b>PLOT_NO2:</b> [PLOTNO_1]<br/></tt><tt><br>
    </tt><tt><hr/></tt><br>
    <br>
    so the zoom-to link works.<br>
    <br>
    <pre class="moz-signature" cols="72">Best Regards,
Brent Fraser</pre>
    <div class="moz-cite-prefix">On 12/21/2015 10:12 AM, Dan Little
      wrote:<br>
    </div>
    <blockquote
cite="mid:CABqPoBYF5_-O4of3hLgZqVJK-PwpYvFELKV0EUF1Dk+t8PK59A@mail.gmail.com"
      type="cite">
      <pre wrap="">Can someone formalize this into a ticket for me? Brent? Tanya?

I'd like to make sure I've got automated tests for this.  If I need to
pull in some OSM data to make a test then I will but if someone can
summarize this for me in a quick-and-tangible form I'll make it
happen.

On Mon, Jul 27, 2015 at 7:12 PM, TC Haddad <a class="moz-txt-link-rfc2396E" href="mailto:tchaddad@gmail.com"><tchaddad@gmail.com></a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">
Wow thanks Brent.

I would say we're at the point where this can be filed as a GitHub issue-
why don't you open one, and link to this thread using:

<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/pipermail/geomoose-users/2015-July/005735.html">http://lists.osgeo.org/pipermail/geomoose-users/2015-July/005735.html</a>

so that we have an easy way to get to your findings.



On Mon, Jul 27, 2015 at 5:02 PM, Brent Fraser <a class="moz-txt-link-rfc2396E" href="mailto:bfraser@geoanalytic.com"><bfraser@geoanalytic.com></a>
wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">
So I did some tests on the Geomoose services (both v2.7.1 and 2.8.0) using
different Spatial Reference Systems (SRS) .

The Short story:

        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.


The Long story:

  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.

                            v2.7.1                 v2.8.0
Map/Layer SRS:    UTM/UTM UTM/Geo Geo/Geo  UTM/UTM UTM/Geo Geo/Geo
                  ======= ======= =======  ======= ======= =======
Function:
---------
Rendering            yes    yes    yes        yes    yes    yes
Printing             yes    yes    yes        yes    yes    yes
Identify             yes    yes    yes        yes    yes    yes
 Feature Report      yes    no(1)  yes        yes    no(1)  yes
Popups               yes    yes    yes        yes    yes    yes
Select Features      yes    no(2)  yes        yes    no(2)  yes
 highlight           yes    -      yes        yes    -      yes
 PDF Mailing Labels  yes    -      yes        yes    -      yes
 HTML Mailing Labels yes    -      yes        yes    -      yes
 CSV Mailing Labels  yes    -      yes        yes    -      yes
Search Parcels       yes    no(3)  yes        yes    no(3)  yes
 highlight           yes    -      yes        yes    -      yes
 Zoom-to link        yes    -      no(4)      yes    -      no(4)


(1) map portion empty, but parcel attributes displayed
  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.

(2) Found Shapes: 0
  The "bug":select.php assumes the map and layer portions of the map file
use the same SRS

(3) No results found for your query!
  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.

(4) Zooms to the wrong location
  The "bug": the search_result.html template needs to be changed to return
coordinates with decimal precision:
parcel-shape="[shpxy precision=5]"
and of course the SRS of the coordinates must be changed to:
'EPSG:4326'


Best Regards,
Brent Fraser

On 7/27/2015 1:38 PM, Brent Fraser wrote:

  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.

  I think I'll try converting the parcels to geographic coordinates and
see how many functions still work...

Best Regards,
Brent Fraser

On 7/27/2015 12:29 PM, James Klassen wrote:

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.

On Jul 27, 2015 12:38 PM, "Brent Fraser" <a class="moz-txt-link-rfc2396E" href="mailto:bfraser@geoanalytic.com"><bfraser@geoanalytic.com></a> wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">
Bobb,

  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%).

Best Regards,
Brent Fraser

On 7/27/2015 8:17 AM, Basques, Bob (CI-StPaul) wrote:

All,

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.

bobb



On Jul 26, 2015, at 12:37 PM, TC Haddad <a class="moz-txt-link-rfc2396E" href="mailto:tchaddad@gmail.com"><tchaddad@gmail.com></a> wrote:


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.

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.

Probably worth a review of the docs to see how we might improve in this
area...

Tanya

On Sun, Jul 26, 2015 at 10:12 AM, Brent Fraser <a class="moz-txt-link-rfc2396E" href="mailto:bfraser@geoanalytic.com"><bfraser@geoanalytic.com></a>
wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="">
Tanya,

  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!

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.

Best Regards,
Brent Fraser

On 7/26/2015 10:57 AM, TC Haddad wrote:


There was a bug that was fixed recently that may relate:

<a class="moz-txt-link-freetext" href="https://github.com/geomoose/geomoose/issues/90">https://github.com/geomoose/geomoose/issues/90</a>

You could try grabbing the relevant changes to query.php:


<a class="moz-txt-link-freetext" href="https://github.com/geomoose/geomoose-services/commit/dacfa7e2648c5bcd3ec38308cb1199621a07c390">https://github.com/geomoose/geomoose-services/commit/dacfa7e2648c5bcd3ec38308cb1199621a07c390</a>

Or you could try a 2.8 install to see if the same problem is present
(before filing a new issue...).



On Sun, Jul 26, 2015 at 9:32 AM, Brent Fraser <a class="moz-txt-link-rfc2396E" href="mailto:bfraser@geoanalytic.com"><bfraser@geoanalytic.com></a>
wrote:
</pre>
              <blockquote type="cite">
                <pre wrap="">
Hi Developers (and others),

  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):

    $ext = $queryLayer->getExtent();

then the layer's extent is used for the query a little later:

    $queryLayer->queryByRect($ext);

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:

                    // re-project the layer's extent into the map SRS
for querying:
                    $map_projection_def = $map->getProjection();
                    $map_projection_obj =
ms_newProjectionObj($map_projection_def);

                    if($queryLayer->getProjection() != NULL) {
                        $projection = $queryLayer->getProjection();
                    }
                    if($projection != NULL) {
                        # reproject the query shape as available.
                        $projection = ms_newProjectionObj($projection);
                    }
                    if($projection) {
                        $ext->project($projection,
$map_projection_obj);
                    }
                    if($DEBUG) {
                        error_log(implode(',',
array($ext->minx,$ext->miny,$ext->maxx,$ext->maxy)));
                        error_log("<br/>extent for query in map
SRS.<br/>");
                    }

I thought I would get comments before filing an Issue.

So any comments?

--
Best Regards,
Brent Fraser


_______________________________________________
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>
              <pre wrap="">


</pre>
            </blockquote>
            <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>




_______________________________________________
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>
          <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>



_______________________________________________
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>
        <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>
      <pre wrap="">
</pre>
    </blockquote>
    <br>
  </body>
</html>