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 )
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 , 14 years ago
Component: | MapServer C Library → WFS Server |
---|---|
Owner: | changed from | to
comment:2 by , 14 years ago
Cc: | 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 , 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 , 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 , 14 years ago
Cc: | 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 , 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 , 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
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