Opened 12 years ago
Last modified 12 years ago
#4227 new defect
Horizontal lines drawn for empty labels
Reported by: | rblazek | Owned by: | pramsey |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | PostGIS Interface | Version: | 6.0 |
Severity: | normal | Keywords: | |
Cc: | rblazek, tbonfort, sdlime |
Description
If a label field is empty, horizontal line / box is drawn instead of nothing. It happens if:
- CONNECTIONTYPE POSTGIS
- label field is of type character
- label style is defined
Label style example:
LABEL STYLE COLOR 192 192 192 END END
Postgres: "Values of type character are physically padded with spaces to the specified width n, and are stored and displayed that way. However, the padding spaces are treated as semantically insignificant."
It seems that Mapserver takes those empty spaces to create labelpoly geometry. It is probably wrong and definitely inconvenient.
Attachments (1)
Change History (8)
by , 12 years ago
Attachment: | ms_label.png added |
---|
comment:1 by , 12 years ago
Cc: | added |
---|
comment:2 by , 12 years ago
Can you provide a sample dataset? Padding spaces are generally removed from attributes by the underlying driver. I know that's the case with SHP/DBF.
Steve
comment:3 by , 12 years ago
Cc: | added |
---|---|
Component: | MapServer C Library → PostGIS Interface |
Owner: | changed from | to
I really think this is a driver issue in terms of what spaces mean and so forth. It would be very inefficient to do trimming higher up in the code. Other option is fix this in your SQL so that blanks are trimmed.
Steve
comment:4 by , 12 years ago
Cc: | added |
---|
follow-up: 6 comment:5 by , 12 years ago
Yeah, would it not be easier to just
alter table mytable alter column mycolumn type varchar(N);
I'm not inclined to globally trim fields, because some people might be deliberately putting them in there.
comment:6 by , 12 years ago
Replying to pramsey:
Yeah, would it not be easier to just
alter table mytable alter column mycolumn type varchar(N);
Yes, I can change column types. I found this problem after Shapefile import via OGR, it created character columns so I thought it could be a common problem worth to fix.
I'm not inclined to globally trim fields, because some people might be deliberately putting them in there.
That is why I wrote "probably wrong" because I am no sure what is correct. IMO, other types like varchar or text should not be trimmed, but character should be trimmed in the same way it is trimmed by Postgres, I tried in psql:
inserted retrieved 'xxx' 'xxx' 'xxx ' 'xxx' ' xxx' ' xxx' '' '' null null
i.e. trim all spaces from the end of the string, regexp ' *$'.
It is not clear to me however, where the trimming is done in Postgres. It is not in psql because I tried to concatenated with other strings in select. It must be done on server side. How is it possible that it comes not trimmed to Mapserver?
comment:7 by , 12 years ago
Actually, your test is wrong, because you are concatenating in the server, which is adding the space truncating behavior. Here's a test that shows that white space, front and back, is preserved all the way through
postgis20=# \a Output format is unaligned. postgis20=# select 't'::char(1),' d '::char(4),'t'::char(1); bpchar|bpchar|bpchar t| d |t (1 row)
Example map