[Qgis-developer] Aliases of features attributes in Mapserver's WMS GetProjectSettings and GetFeatureInfo

[Marcel Dancak]

Good to know about your work on Server config redesign, I will wait until
you finish it.

I have looked into source code and found one drawback for using aliases in
GetFeatureInfo request in GML format. Attribute name is encoded as XML
element and therefore it cannot contain empty spaces. Because of that,
empty spaces are now replaced with "_" and this will make attribute name
looks less user friendly. So in my case it doesn't really matter that much
whether alias or name will be returned, there always will be needed some
post-processing of GML document before showing result to the user.

And one other question that raise after Bernhard's reply. If
GetProjectSettings will have both "alias" and "name" attributes, does it
somehow change the "displayField" attribute of Layer's element? Cause now
it is also filled by alias value (or name if alias is not defined).


Marcel


2014-04-08 9:26 GMT+02:00 Marco Hugentobler <marco.hugentobler at sourcepole.ch
>:

> Hi Marcel
>
> Sounds good to have both name and alias in GetProjectSettings and to use
> name for FILTER.
>
>
> >Another question is, what should be used as attribute name in
> GetFeatureInfo response, alias or name? Current mapserver returns prefer
> aliases (if defined) in plain XML format, >but in GML format it always
> returns names. In my opinion, names should be used in both formats and
> aliases could be passed as additional info (if particular format allows
> that), >or not used at all in GetFeatureInfo cause clients would be able to
> perform mapping from names to aliases by info from GetProjectSettings.
>
> I think it should behave similar to the info-tool in QGIS and give the
> alias. Standard WMS clients can then display the text / html without being
> aware there is a difference between name/alias. Specialised clients (e.g.
> QGIS webclient, Lizmap, ...) can read alias / name from project settings
> and use that for filter string (which is also non-standard).
>
>
> >but in GML format it always returns names
> >And the last issue is that mapserver always returns all features
> attributes in GetFeatureInfo response is GML format, even if they are
> marked to be excluded in WMS server.
>
> These are two bugs in the gml featureInfo code.
>
> Pull requests are welcome. However, to avoid merging conflicts, it might
> be good to wait for https://github.com/qgis/QGIS/pull/1296 .
>
> Regards,
> Marco
>
>
>
>
> On 08.04.2014 08:05, Marcel Dancak wrote:
>
>> Hi, I found some issues in Mapserver when using aliases for features
>> attributes.
>>
>> GetProjectSetting response has features attributes of vector layer in
>> this form
>>
>> <Attribute typeName="INTEGER" precision="0" length="0"
>> editType="LineEdit" type="qlonglong" comment="" name="PK_UID"/>
>>
>> where "name" property contains either attribute's alias (if defined) or
>> its name. So you are loosing attribute's name when using aliases, and that
>> make it impossible to perform searching by this attribute with
>> GetFeatureInfo request (with FILTER parameter). Separate "alias" property
>> would be much better.
>>
>> Another question is, what should be used as attribute name in
>> GetFeatureInfo response, alias or name? Current mapserver returns prefer
>> aliases (if defined) in plain XML format, but in GML format it always
>> returns names. In my opinion, names should be used in both formats and
>> aliases could be passed as additional info (if particular format allows
>> that), or not used at all in GetFeatureInfo cause clients would be able to
>> perform mapping from names to aliases by info from GetProjectSettings.
>>
>> And the last issue is that mapserver always returns all features
>> attributes in GetFeatureInfo response is GML format, even if they are
>> marked to be excluded in WMS server.
>>
>>
>> I have all these issues fixed and I can create a pull requests, but first
>> I want to discuss about it and maybe another solutions will came out.
>>
>>
>> Marcel
>>
>
>
> --
> Dr. Marco Hugentobler
> Sourcepole -  Linux & Open Source Solutions
> Weberstrasse 5, CH-8004 Zürich, Switzerland
> marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140408/2836515e/attachment.html>