[Geomoose-users] Problem in query.php if layer SRS different from map SRS
Brent Fraser
bfraser at geoanalytic.com
Tue Dec 22 08:09:50 PST 2015
Dan,
I'm not sure I need to file a ticket, based on my table below from
the previous email.
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:
MAP
PROJECTION
"+init=epsg:4326"
END # of PROJECTION
:
LAYER
: # no need for a projection object here
END # Layer
END # Map
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.
i just need to make sure I edit my search template to be (note the
"precision=5" and "EPSG:4326"):
<!-- MapServer Template -->
<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 *precision=5*]"
href="javascript:GeoMOOSE.zoomToPointsList(dojo.byId('gm-parcel-[PLOTNO_1]').getAttribute('parcel-shape'),
'*EPSG:4326*');">[PLOTNO_1]</a><br/>
<b>PLOT_NO2:</b> [PLOTNO_1]<br/>
<hr/>
so the zoom-to link works.
Best Regards,
Brent Fraser
On 12/21/2015 10:12 AM, Dan Little wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-users/attachments/20151222/3e8722a8/attachment-0001.html>
More information about the Geomoose-users
mailing list