[Geomoose-users] Problem in query.php if layer SRS different from map SRS
Dan Little
theduckylittle at gmail.com
Mon Dec 21 09:12:13 PST 2015
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 <tchaddad at gmail.com> wrote:
>
> 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>
>>>> 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
>>> 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 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
More information about the Geomoose-users
mailing list