Opened 14 years ago

Last modified 14 years ago

#3445 new enhancement

Order of GetFeatureInfo Attributes

Reported by: tee Owned by: mapserverbugs
Priority: normal Milestone:
Component: WFS Server Version: unspecified
Severity: normal Keywords:
Cc: sdlime, tomkralidis, bartvde

Description (last modified by dmorissette)

A cool feature would be to give us the power to sort the GetFeatureinfo attributes by the order of the 'gml_include_items'-tag. It essential for generic tooltips.

e.g.

'gml_include_items' 'NAME,NUMBER,AREA' # 1. Name, 2. Number, 3. Area
#'gml_include_items' 'NUMBER,NAME,AREA' # 1. Number, 2. Name, 3. Area
'gml_NAME_alias' 'Name'
'gml_NUMBER_alias' 'Number'
'gml_AREA_alias' 'Area'

regards, Daniel

Change History (7)

comment:1 by sdlime, 14 years ago

Component: MapServer C LibraryWFS Server
Owner: changed from sdlime to mapserverbugs

I know the ticket is specific to WMS/getFeatureInfo but a GML production change would have a bigger impact on WFS and should be considered in that context first. Changing component.

Steve

comment:2 by sdlime, 14 years ago

Cc: sdlime added

Couple of options: 1) Create a gml_item_order metadata tag

Advantages: Non-disruptive since it's new behavior. Disadvantages: Would have to be kept in sync with gml_include_items which will be a source of error.

2) Use the order specified in gml_include_items

Advantages: Easy to implement. No new tags created to complicate things. Disadvantages: Disruptive, changing current behaviour.

3) Create a tag to turn on the behavior in 2)

Advantages: Easy to implement, not as easy as 2) though. Non-disruptive. Disadvantages: Yet another metadata tag...

Thoughts? Steve

comment:3 by assefa, 14 years ago

I am personally in favor of option 2) for the 6.0 version.

Note also that GetFeatureInfo has 2 more output mechanism beside the gml one discussed here. The same work should be done for at least the text/plain output which uses wms/ows_include/exclude items (function msDumpResult in mapwms.c). We should probably use the same functions as the gml ones so the work would be done only once.

There is also the templates output, but I don't think that the items order has an effect.

comment:4 by sdlime, 14 years ago

Probably should ping Bart and Tom K. for feedback. As for implementation I was thinking of just adding an "order" property to the GML items stuct (where alias, etc... are stored) then using that value to determine presentation order. That should be a relatively straight forward addition to both places.

You're right about templates. You set the order implicitly by how you write the template...

Steve

comment:5 by dmorissette, 14 years ago

Cc: tomkralidis bartvde added
Description: modified (diff)

I'd also vote for option 2, since it extends an existing mechanism and doesn't complicate things by adding new metadata. I doubt many users will be impacted by this behavior change, but just in case we should document the potential side-effect in the MIGRATION_GUIDE.TXT.

comment:6 by tomkralidis, 14 years ago

+1 for option 2. Most, if not all, client implementations I know of simply loop over the XML elements as opposed to picking them off by ordering.

We would also have to make sure any underlying XML Schemas honour this change (i.e. DescribeFeatureType output), as order does matter in xml schema.

comment:7 by sdlime, 14 years ago

I looking at implementing this and I'm afraid the simple solution probably isn't sufficient. We also support GML constants (i.e. XML elements not found in attribute tables but defined through metadata) and groups (i.e. complex types). Those should be considered in any ordering and the ordering should also extend into groups. We'd have to define cross element type ordering to pull that off...

Steve

Note: See TracTickets for help on using tickets.