[Geomoose-users] Problem in query.php if layer SRS different from map SRS
Brent Fraser
bfraser at geoanalytic.com
Mon Jul 27 17:02:37 PDT 2015
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" <bfraser at geoanalytic.com
>> <mailto:bfraser at geoanalytic.com>> wrote:
>>
>> 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 <tchaddad at gmail.com> 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
>>>> <bfraser at geoanalytic.com <mailto:bfraser at geoanalytic.com>> wrote:
>>>>
>>>> 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:
>>>>>
>>>>> https://github.com/geomoose/geomoose/issues/90
>>>>>
>>>>> You could try grabbing the relevant changes to query.php:
>>>>>
>>>>> https://github.com/geomoose/geomoose-services/commit/dacfa7e2648c5bcd3ec38308cb1199621a07c390
>>>>>
>>>>> 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
>>>>> <bfraser at geoanalytic.com> wrote:
>>>>>
>>>>> 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
>>>>> Geomoose-users at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Geomoose-users mailing list
>>>> Geomoose-users at lists.osgeo.org
>>>> <mailto:Geomoose-users at lists.osgeo.org>
>>>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>>>
>>
>>
>> _______________________________________________
>> Geomoose-users mailing list
>> Geomoose-users at lists.osgeo.org
>> <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-users/attachments/20150727/1cde7384/attachment-0001.html>
More information about the Geomoose-users
mailing list