[Geomoose-users] Feature Reports notes

[Dan Little]

The structural problem that you're working around is something that we
solved with the query.php tool.

So query.php has a "field0" and then a "value0" field that will perform the
query.  We can, theoretically, migrate to a setup like that. The
feature_report service was really meant to be an example of something one
COULD do and less a reusable component.  We could certainly evolve it as a
few folks have made mention of its need.



On Tue, Jun 2, 2015 at 11:02 AM Brent Fraser <bfraser at geoanalytic.com>
wrote:

>  Dan,
>
> Good idea; we do need more user/implementer doc on Feature Reports.  But
> first I'd like your opinion on a small structural change to the Feature
> Report service.
>
> Currently the service is defined as:
>
>     <service name="feature_report" display="false" keep-others="true">
>         <url>php/feature_report.php</url>
>         <input type="hidden" name="layers" value="lmic/fsa"/>
>
>         <input type="hidden" name="src"/>
>         <input type="hidden" name="PIN"/>
>     </service>
>
>
> The inclusion of "PIN" identifier means that the service is specific to a
> particular layer with a key attribute named "PIN".  If I have 20 layers I'd
> like to do Feature Reports on, I'd need 20 different services defined each
> with a different key name; possible but painful.
>
> My solution is to not use the layer's key name, but use something generic
> like "GM_FID", then change line 67 in feature_report.php from:
>
>
>     $layer->setFilter(str_replace('%qstring%', urldecode($_REQUEST[
> *$qItem*]), $query_info->getAttribute('string')));
>
> to
>
>     $layer->setFilter(str_replace('%qstring%', urldecode($_REQUEST[
> *'GM_FID'*]), $query_info->getAttribute('string')));
>
> With those changes only one feature_report service needs to be defined
> (but you would still need separate identify and report templates for each
> layer, but that's ok).
>
> To really get and understanding of the problem, pick two layers in our
> demo data-set and configure them to do Feature Reports (it will all become
> clear).
>
> Best Regards,
> Brent Fraser
>
> On 6/2/2015 8:35 AM, Dan Little wrote:
>
> Brent,
>
> Is there any chance you can create a summarized clarification in an RST
> doc or a Google doc? I'm sorry, I don't follow every post to full
> understanding so if you can get something I can get more suitable for
> posting on the docs website then I'll do it!
>
>  Thanks!
>
>  On Mon, Jun 1, 2015 at 7:02 PM Brent Fraser <bfraser at geoanalytic.com>
> wrote:
>
>>  Ok, as it turns out it IS necessary to put the key name in the service
>> definition (so follow my instructions sent at 10:57 below).  For now.
>>
>> I think the fix would be fairly simple:  change feature_report.php to
>> reference the "PID" parameter (maybe "FID" would be a better name?).
>>
>> Specifically, change line 67 from:
>>
>> $layer->setFilter(str_replace('%qstring%', urldecode($_REQUEST[$qItem]),
>> $query_info->getAttribute('string')));
>>
>> to
>> $layer->setFilter(str_replace('%qstring%', $_REQUEST['PID'],
>> $query_info->getAttribute('string')));
>>
>> And an implementer would now specify:
>>
>> <tr><td align="left"><b><a href = "javascript:GeoMOOSE.startService('
>> *feature_report*', {'*PID*' : '[BF_ID]', 'src' :
>> 'Hydrography/Lakes'})">Report</a></b></td></tr>
>>
>> (if the layer's unique key was named "BF_ID")
>>
>> Best Regards,
>> Brent Fraser
>>
>>  On 6/1/2015 5:15 PM, Brent Fraser wrote:
>>
>> I need to correct the information is sent earlier.  The first part of the
>> instructions below ("Edit the feature_report service...") is not necessary
>> as the key field name is specified in the template ("<query item="), not
>> the service definition.
>>
>> Best Regards,
>> Brent Fraser
>>
>> On 6/1/2015 10:57 AM, Brent Fraser wrote:
>>  There doesn't seem to be a lot of documentation for the Feature Report
>> service, so I made some notes:
>>
>> Feature Reports
>>
>>   Edit (or copy) the feature_report service in the mapbook to add the
>> key field, for example:
>>
>>
>>     <service name="feature_report_Hydrography" display="false"
>> keep-others="true">
>>
>>       <url>php/feature_report.php</url>
>>
>>       <input type="hidden" name="layers" value="Backgrounds/osm"/>
>>
>>       <input type="hidden" name="src"/>
>>
>>       <input type="hidden" name="BF_ID"/>
>>
>>    </service>
>>
>>
>>    Add the metadata to the feature’s map file:
>>
>>        METADATA
>>
>>            'identify_record'       'BF_HYDRO_POLYGON_identify.html'
>>
>>            'popups'                'BF_HYDRO_POLYGON_popups.html'
>>
>>            'feature_report'        'BF_HYDRO_POLYGON_report.xml'
>>
>>        END # of METADATA
>>
>> Edit the _identify template to add a link to generate and view the
>> report.  For example my BF_HYDRO_POLYGON_identify.html template has:
>>
>> <tr><td align="left"><b><a href = "javascript:GeoMOOSE.startService(
>> 'feature_report_Hydrography', {'BF_ID' : '[BF_ID]', 'src' :
>> 'Hydrography/Lakes'})">Report</a></b></td></tr>
>>
>>
>> Create the report xml file (in my case the file is named
>> BF_HYDRO_POLYGON_report.xml) modifying the key name and the PDF report
>> name:
>>
>>    <query item="BF_ID" string="%qstring%"/>
>>
>>     <!-- This is the template -->
>>
>>    <template>BF_HYDRO_POLYGON_template.pdf</template>
>>
>> Create the report PDF file
>>
>>     Copy the parcel_template.pdf to the name you entered in the report
>> xml file, for example:
>>
>> copy parcel_template.pdf BF_HYDRO_POLYGON_template.pdf
>>
>> --
>> Best Regards,
>> Brent Fraser
>>
>>
>>
>> _______________________________________________
>> 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/20150602/cd98b33a/attachment-0001.html>