[Geomoose-users] Problem in query.php if layer SRS different from map SRS
TC Haddad
tchaddad at gmail.com
Mon Jul 27 17:12:40 PDT 2015
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:
http://lists.osgeo.org/pipermail/geomoose-users/2015-July/005735.html
so that we have an easy way to get to your findings.
On Mon, Jul 27, 2015 at 5:02 PM, Brent Fraser <bfraser at geoanalytic.com>
wrote:
> 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> 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>
>> 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>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>Geomoose-users at lists.osgeo.org
>>>> <http://lists.osgeo.org/mailman/listinfo/geomoose-users>
>>>> 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
>>
>>
>>
>>
>> _______________________________________________
>> Geomoose-users mailing list
>> Geomoose-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>>
>
>
>
> _______________________________________________
> Geomoose-users mailing listGeomoose-users at lists.osgeo.orghttp://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/c14cf6d7/attachment-0001.html>
More information about the Geomoose-users
mailing list