Opened 18 years ago
Closed 17 years ago
#1857 closed defect (fixed)
SLD label implementation is non-conformant to OGC SLD spec
Reported by: | Owned by: | assefa | |
---|---|---|---|
Priority: | high | Milestone: | 5.0 release |
Component: | WMS Server | Version: | 4.8 |
Severity: | normal | Keywords: | |
Cc: | havard.tveite@… |
Description
Hi list, I am trying to get Mapserver (version 4.8.4) to display labels for a certain attribute column. This works fine if I use the non-conformant OGC request (only part of my SLD): <TextSymbolizer><Label>MY_COLUMN</Label> According to the OGC SLD spec Mapserver should just label with MY_COLUMN as a static string. But it does not work if I use it the way the example in the SLD spec indicates (using ogc:PropertyName): <TextSymbolizer><Label><ogc:PropertyName>MY_COLUMN</ogc:PropertyName></Label> I get: [Thu Aug 10 08:06:30 2006] [error] [client 145.50.39.34] Thu Aug 10 08:06:30 2006 - msDBFGetItemIndex(): DBASE file error. Item 'PropertyName' not found. Example from SLD spec: <TextSymbolizer> <Geometry> <ogc:PropertyName>locatedAt</ogc:PropertyName> </Geometry> <Label> <ogc:PropertyName>hospitalName</ogc:PropertyName> </Label> Why is this important? So that you can label using attribute values and static strings combined, like: <Label>This is city "<ogc:PropertyName>NAME</ogc:PropertyName>" of state <ogc:PropertyName>STATE</ogc:PropertyName></Label> Can this be fixed?
Change History (12)
comment:2 by , 18 years ago
Milestone: | → 4.10 release |
---|
Setting target to 4.10 to implement support for both: <TextSymbolizer><Label><ogc:PropertyName>MY_COLUMN</ogc:PropertyName></Label> <TextSymbolizer><Label>MY_COLUMN</Label>
comment:4 by , 18 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Looks like a dup to me. Assigned bug to Assefa since SLD is his territory.
comment:5 by , 18 years ago
Cc: | added |
---|
comment:7 by , 18 years ago
add support for parsing label tags with property name : <TextSymbolizer><Label><ogc:PropertyName>MY_COLUMN</ogc:PropertyName></Label>. Old way of doing is still supported. Does not do support things like <Label>This is city "<ogc:PropertyName>NAME</ogc:PropertyName>" of state <ogc:PropertyName>STATE</ogc:PropertyName></Label> If statifactory, please close the bug.
comment:8 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I have verified this one and it works fine now. Thanks! Closing.
comment:9 by , 17 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Reopen bug : support of mixing static text with column names is missing.
comment:10 by , 17 years ago
I have added in the CVS HEAD the support of mixing the static text and attributes. The way it is done is that all text symbolizers now set the class.text attribute instead of using the layer's label item. These cases seem to work for me : * <Label><ogc:PropertyName>MY_COLUMN</ogc:PropertyName></Label> would give as class text ([MY_COLUMN]) * <Label>MY_COLUMN</Label> would give ([MY_COLUMN]) * <Label>aaa <ogc:PropertyName>TXT</ogc:PropertyName> bbb <ogc:PropertyName>TXT</ogc:PropertyName>ccc</Label> would give (aaa [TXT]bbb [TXT]ccc) Couple of things : * do you see any problem of always using the class text instead of the layer label item ? * I saw a problem when parsing the xml where the white spaces in front of the label values are stripped out (in the 3rd example above, spaces before the sting "bbb" are striped out). I think this comes from the CPL xml paring code (gdal) but I need to confirm that with Frank.
comment:11 by , 17 years ago
FYI the schema does not allow for whitespace _and_ an element, so:
<Label>aaa <ogc:PropertyName>TXT</ogc:PropertyName> bbb<ogc:PropertyName>TXT</ogc:PropertyName>ccc</Label>
would not work.
comment:12 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Tom, I guess it would be for the user to validate the SLD (or should we do that ?). As it stands now, we use OGR to parse the xml and if the xml is valid (just the structure), we assume it is a valid SLD.
Closing this bug. Changes have benn in for some time. If there are specific bugs, we will open new ones.
Note:
See TracTickets
for help on using tickets.