[Geomoose-users] Highlight projection issue

Brent Fraser bfraser at geoanalytic.com
Mon Jun 21 12:26:36 EDT 2010


I thought this sounded familiar.  I've filed an issue:
http://www.geomoose.org/trac/ticket/96

It seems Jim K., Steve L., and I discussed this problem in April 2009 
(http://osgeo-org.1803224.n2.nabble.com/Reprojection-of-shpext-and-mapext-in-templates-td2310145.html#a2310145)

Brent



Johan Forsman wrote:
> I decided to project the source data to the intended webmap projection and just store it that way. Everything is more-or-less in order now and there is a minor performance improvement without the on-the-fly projection.
> 
> Thanks for the pointers.
> 
>> -----Original Message-----
>> From: Len Kne [mailto:lkne at houstoneng.com]
>> Sent: Thursday, June 17, 2010 4:26 PM
>> To: Johan Forsman; geomoose-users at lists.sourceforge.net
>> Subject: Re: [Geomoose-users] Highlight projection issue
>>
>> So it looks like there is some work to be done with GeoMOOSE services to
>> fully support querying layers in projections different than GeoMOOSE...
>> Since you are using PostGIS, you could do the transformation there with
>> st_transform().  The re-projection can also happen on the service-side of
>> the service or on the client-side with a GeoMOOSE user extension. This
>> should work:
>>
>> TransformAndZoomExtension = new OpenLayers.Class(GeoMOOSE.UX.Extension, {
>>         srcPrj: new OpenLayers.Projection('EPSG:26915'),
>>         load: function() {
>>         },
>>         zoom: function(minx,miny,maxx,maxy) {
>>                 var bounds = new
>> OpenLayers.Bounds(minx,miny,maxx,maxy).transform(this.srcPrj,Map.projectio
>> n);
>>                 Map.zoomToExtent(bounds);
>>         },
>>         CLASS_NAME: "TransformAndZoomExtension"
>> });
>> GeoMOOSE.UX.register('TransformAndZoomExtension');
>>
>> transformAndZoom = new TransformAndZoomExtension();
>>
>> Look at http://www.geomoose.org/docs/user_extensions.html for details on
>> adding a user extension to GeoMOOSE.
>>
>> Then in your template, you would point to
>> transformAndZoom.zoom([shpminx],[shpminy],[shpmaxx],[shpmaxy]);
>>
>> Len
>>
>> -----Original Message-----
>> From: Johan Forsman [mailto:Johan.Forsman at LA.GOV]
>> Sent: Thursday, June 17, 2010 2:33 PM
>> To: geomoose-users at lists.sourceforge.net
>> Subject: Re: [Geomoose-users] Highlight projection issue
>>
>> Followup to my own message.
>>
>> I have confirmed that the link returned by the javascript snippet below
>> contains the correct extent IF interpreted as the original EPSG:26915
>> projection.
>> In other words somewhere along the way the bounds are not reprojected.
>>
>> If I use a single water well in my PostGIS (that uses EPSG:26915) as
>> example:
>>
>> Stored coordinates are 748178.83, 333429.45 in NAD83 UTM15N.
>>
>> Mapserver projects those to EPSG:900913 and obtains -10066017.27,
>> 3517260.50 according to my Geomoose interface, which uses 900913. This is
>> the correct location.
>>
>> If I use my Geomoose interface and check the location in Algeria, it is
>> indeed in agreement with the UTM numbers above.
>>
>> To reiterate, all locations plot in the correct location, the highlight is
>> now in the correct location, but the query-generated link appears to use
>> the unprojected EPSG:26915 coordinates, taking me to Algeria.
>>
>> What can I do?
>>
>> Thanks!
>> Johan.
>>
>>
>>> -----Original Message-----
>>> From: Johan Forsman [mailto:Johan.Forsman at LA.GOV]
>>> Sent: Thursday, June 17, 2010 11:17 AM
>>> To: geomoose-users at lists.sourceforge.net
>>> Subject: [Geomoose-users] Highlight projection issue
>>>
>>> All:
>>>
>>> Focusing on the itemquery/highlight.map projection issue now. I
>>> thought I had it covered, but the plot has thickened.
>>>
>>> Making the changes described below indeed fixed the highlight problem,
>>> but there is still an underlying issue.
>>>
>>> If I click on the link generated by the
>>>
>>> javascript:GeoMOOSE.changeLayerUrl('highlight',...
>>> GeoMOOSE.zoomToExtent(662056.373600,3344506.451400,662056.373600,33445
>>> 06.4
>>> 51400)
>>>
>>> function in the template file it zooms to the same spot in Algeria
>>> that the highlight was previously placed.
>>> There is clearly something sinister going on with the source of that
>>> extent.
>>>
>>> Where can I look / what info can I provide to help troubleshoot this?
>>>
>>> Or am I simply overlooking something embarrassingly simple?
>>>
>>> Thanks!
>>> Johan.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Johan Forsman [mailto:Johan.Forsman at LA.GOV]
>>>> Sent: Thursday, June 17, 2010 8:03 AM
>>>> To: Len Kne; geomoose-users at lists.sourceforge.net
>>>> Subject: Re: [Geomoose-users] query.php configuration confusion
>>>>
>>>> Ok, I found a solution to the highlight issue.
>>>>
>>>> Adding the 900913 projection block to the MAP section in
>>>> highlight.map
>>> did
>>>> not by itself change anything. However, if I also added the
>>>> projection that the data is stored as in the LAYER definition in the
>>>> highlight.map files it worked.
>>>>
>>>> To summarize, to make the query and select highlighting work, in my
>>> case,
>>>> when the data is stored in a different projection than what is used
>>>> in
>>> the
>>>> final output, the highlight.map files must look similar to this:
>>>>
>>>> ------------------------------
>>>> MAP
>>>> PROJECTION
>>>>     "init=epsg:900913"
>>>> END
>>>> TRANSPARENT true
>>>> SYMBOL
>>>>     NAME 'circle'
>>>>     TYPE ellipse
>>>>     POINTS
>>>>             1 1
>>>>     END
>>>>     FILLED true
>>>> END
>>>>
>>>> LAYER
>>>>     PROJECTION
>>>>             "init=epsg:26915"
>>>>     END
>>>>     NAME 'points'
>>>>     TYPE POINT
>>>>     STATUS DEFAULT
>>>>     CLASS
>>>>             SYMBOL 'circle'
>>>>             COLOR 0 255 255
>>>>             SIZE 16
>>>>     END
>>>> END
>>>> ----------------------------
>>>>
>>>>> -----Original Message-----
>>>>> From: Len Kne [mailto:lkne at houstoneng.com]
>>>>> Sent: Wednesday, June 16, 2010 3:47 PM
>>>>> To: Johan Forsman; geomoose-users at lists.sourceforge.net
>>>>> Subject: RE: query.php configuration confusion
>>>>>
>>>>> Your parameters look right.  How about this -  queryitem, query
>>>>> and
>>>> select
>>>>> create a temp shape file with the results and then use a built in
>>>>> map
>>>> file
>>>>> to show the results.  Look for highlight.map in
>>>>> htdocs/php/itemquery and/or htdocs/php/select.  In the MAP object
>>>>> of the file, add the
>>> 900913
>>>>> projection information.  This should re-project the highlight
>>>>> results before returning them to GeoMOOSE.
>>>>>
>>>>> Len
>>>>>
>>>>> -----Original Message-----
>>>>> From: Johan Forsman [mailto:Johan.Forsman at LA.GOV]
>>>>> Sent: Wednesday, June 16, 2010 3:37 PM
>>>>> To: Len Kne; geomoose-users at lists.sourceforge.net
>>>>> Subject: RE: query.php configuration confusion
>>>>>
>>>>> Hi Len, thanks for the response.
>>>>>
>>>>> On Issue 1  suspected that was it. I will attempt to craft an
>>>>> expanded section for each layer I wish to query.
>>>>>
>>>>> On Issue 2:
>>>>> Settings.ini contains
>>>>>   projection=EPSG:900913
>>>>>
>>>>> Mapbook contains
>>>>>   <param name="projection">EPSG:900913</param>
>>>>>
>>>>> Mapfiles contain
>>>>>   PROJECTION
>>>>>           "init=epsg:900913"
>>>>>   END
>>>>> at the top, and
>>>>>   PROJECTION
>>>>>           "init=epsg:26915"
>>>>>   END
>>>>> for each layer.
>>>>>
>>>>> Did I miss something?
>>>>>
>>>>> Thanks!
>>>>> /Johan.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Len Kne [mailto:lkne at houstoneng.com]
>>>>>> Sent: Wednesday, June 16, 2010 3:22 PM
>>>>>> To: Johan Forsman; geomoose-users at lists.sourceforge.net
>>>>>> Subject: RE: query.php configuration confusion
>>>>>>
>>>>>> Hi Johan
>>>>>>
>>>>>> Issue 2 - check conf/settings.ini to see what the projection is
>>>>>> set
>>>> to.
>>>>>> Server-based services use this value for the projection, while
>>> client-
>>>>>> based services use the mapbook.
>>>>>>
>>>>>> For issue 1, I think you are going to need "fieldnameX" for each
>>> layer
>>>>>> you are querying.  As your service is now configured, I would
>>>>>> expect it to only query Layer0 using fieldname0 and value0.  I
>>>>>> do not
>>> believe
>>>>>> you will be able to query across multiple layers with one value
>>>>>> without some custom coding of query.php.
>>>>>>
>>>>>> Len
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Johan Forsman [mailto:Johan.Forsman at LA.GOV]
>>>>>> Sent: Wednesday, June 16, 2010 2:08 PM
>>>>>> To: geomoose-users at lists.sourceforge.net
>>>>>> Subject: [Geomoose-users] query.php configuration confusion
>>>>>>
>>>>>> All:
>>>>>>
>>>>>> Two issues to seek advice on this afternoon.
>>>>>>
>>>>>> Platform is GM2.2, using webmaps as base with EPSG:900913 in the
>>>>>> mapbook and settings.ini files. Source data is in EPSG:26915,
>>>>>> being projected on- the-fly by MapServer to EPSG:900913. All
>>>>>> layers I have render very nicely in all the right spots.
>>>>>>
>>>>>> Issue 1:
>>>>>> I would like to use the new query.php function to search several
>>>>>> tables in my PostGIS from one dialog. I have looked at the
>>>>>> examples
>>> in
>>>>>> the documentation but it appears I am not fully comprehending
>>>>>> the
>>>>> syntax.
>>>>>> I have 5 layers I wish to search, each has its own table in
>> PostGIS.
>>>>>> 6 of the layers/tables have 2 identical fieldnames I wish to be
>>>>>> able to search on, "pwsid" and "sysname".
>>>>>> The remaining table has two fields I wish to be able to search
>>>>>> on, "regowner" and "newid" (ignore layer4 for now).
>>>>>>
>>>>>> I used the "query.php" block from the demo mapbook and
>>> added/replaced
>>>>>> my own layers.
>>>>>> When I test the query layer0 and layer1 are turned on in the
>>>>>> map,
>>> but
>>>>>> results are only returned for layer0.
>>>>>>
>>>>>> I have a <input type...layer? for each layer.
>>>>>> I have a <input type...template? for each layer entry, but they
>>>>>> all use value="itemquery" since each layer definition in the
>>>>>> referenced mapfiles have unique templates defined there.
>>>>>>
>>>>>> I am suspecting the problem lies somewhere with the "fieldname0"
>>>>>> and "value0" parameters? In fieldname0 I have included all 4 of
>>>>>> the fields, from 5 different tables, I wish to be able to
>>>>>> specify the
>>>> search
>>>>> from.
>>>>>> At the bottom of this message I have placed the query.php block
>>>>>> as
>>> it
>>>>>> looks currently. Please ignore the square footage bit; it's
>>> remaining
>>>>>> from the demo, and I don't have an immediate need for the
>>>>>> boolean
>>>>> functions.
>>>>>> I have been unable to stitch together a series of input types
>>>>>> that covers the bases. Does someone on the list have a query
>>>>>> block to
>>> share
>>>>>> that does this that I may model mine after?
>>>>>>
>>>>>>
>>>>>> Issue 2:
>>>>>> All the layers plot where they should, but the highlights from
>>>>>> the query results plot in Algeria. To emphasise, ONLY the
>>>>>> highlights
>>> plot
>>>>>> in the wrong place.  Clearly a projection error, but where? This
>>> also
>>>>>> happens with the old itemquery.php since I switched from using
>>>>>> EPSG:26915 in my mapbook to EPSG:900913.
>>>>>>
>>>>>> Thanks for taking the time!
>>>>>> And I do apologize for the rudimentary XML skills that are
>>> apparently
>>>>>> absent in my mapbook.
>>>>>>
>>>>>> /Johan.
>>>>>>
>>>>>> ----------------------
>>>>>>         <service name="search_facilities">
>>>>>>                 <url>php/query.php</url>
>>>>>>                 <step type="input">
>>>>>>                         <input type="hidden" name="highlight"
>>> value="true"/>
>>>>>>                         <input type="hidden" name="mode"
>> value="search"/>
>>>>>>                         <input type="hidden" name="layer0"
>>>>>> value="wells/sdwis_wells"/>
>>>>>>                         <input type="hidden" name="layer1"
>>>>>> value="surfacewater/intakes"/>
>>>>>>                         <input type="hidden" name="layer2"
>>>>>> value="surfacewater/treatmentplants"/>
>>>>>>                         <input type="hidden" name="layer3"
>>> value="storage/all"/>
>>>>>>                         <input type="hidden" name="layer4"
>>>>>> value="wells/swap_wells"/>
>>>>>>                         <input type="hidden" name="layer5"
>>>>>> value="wells/ldotd_all"/>
>>>>>>
>>>>>>                         <input type="hidden" name="template0"
>>>>>> value="itemquery"/>
>>>>>>                         <input type="hidden" name="template1"
>>>>>> value="itemquery"/>
>>>>>>                         <input type="hidden" name="template2"
>>>>>> value="itemquery"/>
>>>>>>                         <input type="hidden" name="template3"
>>>>>> value="itemquery"/>
>>>>>>                         <input type="hidden" name="template4"
>>>>>> value="itemquery"/>
>>>>>>                         <input type="hidden" name="template5"
>>>>>> value="itemquery"/>
>>>>>>
>>>>>>                         <input type="select" name="fieldname0"
>>> title="Search
>>>>> By:">
>>>>>>                                 <option value="sysname">System
>> Name</option>
>>>>>>                                 <option
>> value="pwsid">PWSID</option>
>>>>>>                                 <option
>> value="regowner">Registered
>>> owner</option>
>>>>>>                                 <option value="newid">Well id
>>> number</option>
>>>>>>                         </input>
>>>>>>                         <input type="select" name="comparitor0"
>>> title="That: ">
>>>>>>                                 <option value="like-
>> icase">Contains</option>
>>>>>>                                 <option value="right-like-
>> icase">Begins
>>>>> With</option>
>>>>>>                                 <option value="eq-str">Matches
>>> Exactly</option>
>>>>>>                         </input>
>>>>>>                         <input type="user" name="value0"
>> title=""/>
>>>>>>                         <input type="hidden" name="fieldname1"
>>>>>> value="FIN_SQ_FT"/>
>>>>>>                         <input type="select" name="operator1">
>>>>>>                                 <option value="or">OR</option>
>>>>>>                                 <option value="and">AND</option>
>>>>>>                         </input>
>>>>>>                         <input type="select" name="comparitor1"
>>> title="Having
>>>>> Fin. Sq. Ft.
>>>>>> ">
>>>>>>                                 <option value="gt">Greater
>> Than</option>
>>>>>>                                 <option value="eq">Equal
>> To</option>
>>>>>>                                 <option value="lt">Less
>> Than</option>
>>>>>>                         </input>
>>>>>>                         <input type="user" name="value1"
>> title=""/>
>>>>>>                 </step>
>>>>>>         </service>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------
>>>>>> ----
>>> --
>>>>>> ----
>>>>>> ----
>>>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad
>>>>>> Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental
>> unit.
>>>>>> See the prize list and enter to win:
>>>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>>> _______________________________________________
>>>>>> Geomoose-users mailing list
>>>>>> Geomoose-users at lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/geomoose-users
>>>> --------------------------------------------------------------------
>>>> ----
>>> --
>>>> ----
>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad
>>>> Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit.
>>>> See the prize list and enter to win:
>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>> _______________________________________________
>>>> Geomoose-users mailing list
>>>> Geomoose-users at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geomoose-users
>>> ----------------------------------------------------------------------
>>> ----
>>> ----
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad
>>> Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit.
>>> See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> Geomoose-users mailing list
>>> Geomoose-users at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geomoose-users
>> --------------------------------------------------------------------------
>> ----
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's
>> Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit.  See the prize
>> list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Geomoose-users mailing list
>> Geomoose-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geomoose-users
>>
>> --------------------------------------------------------------------------
>> ----
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Geomoose-users mailing list
>> Geomoose-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geomoose-users
> 
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
> lucky parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Geomoose-users mailing list
> Geomoose-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geomoose-users
> 





More information about the Geomoose-users mailing list