#962 closed defect (fixed)
Postgis table with float type attribute interprets null as zero.
Reported by: | cgsbob | Owned by: | jef |
---|---|---|---|
Priority: | major: does not work as expected | Milestone: | |
Component: | Vectors | Version: | Trunk |
Keywords: | Cc: | warmerdam | |
Must Fix for Release: | No | Platform: | Debian |
Platform Version: | Awaiting user input: | yes |
Description
I tried to use Symbology>Continuous Color on a field that has nulls and noticed that these null values are interpreted as 0. As a result, I am getting a lot of black dots on my map (which I hoped would not show up on my map) along with white to red colored dots.
I also notice that "Open attribute table" shows these fields as 0 instead of null.
Attachments (4)
Change History (20)
comment:1 by , 15 years ago
Cc: | added |
---|
by , 15 years ago
Attachment: | nullprob.png added |
---|
This illustrates Continuous Color (and other) rendering problems with nulls
follow-up: 3 comment:2 by , 15 years ago
Replying to cgsbob: The image I just uploaded has a bug :-) The beginning arrow coming from the pgadmin3 window should begin at record 141 (one cell below).
comment:3 by , 15 years ago
comment:4 by , 15 years ago
Owner: | changed from | to
---|
follow-up: 6 comment:5 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:6 by , 15 years ago
comment:7 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
follow-up: 9 comment:8 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
fixed in r8282
follow-up: 10 comment:9 by , 15 years ago
follow-up: 11 comment:10 by , 15 years ago
Awaiting user input: | set |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
comment:11 by , 15 years ago
Replying to jef:
Replying to cgsbob:
Replying to jef:
fixed in r8282
I wish this was an easier bug to fix, but there is still a problem :-) The null point features the color range white to red). When you zoom in these null point features disappears.
Sorry, I don't get what you're saying. Did you post get mixed up?
Yes, I did mix up my post. I was trying to say that the features that have null attribute still appear in my map and when I zoom in those features they disappear. I'll upload some pics to demonstrate.
by , 15 years ago
Attachment: | nulls_appear.png added |
---|
shades of red is from continuous color render. black feature has null attribute.
by , 15 years ago
Attachment: | zoom_lower_right.png added |
---|
zoom into lower right of maps...red features disappear
comment:12 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:13 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
follow-up: 15 comment:14 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
thanks for the patience. I think I finally got it right.
follow-up: 16 comment:15 by , 15 years ago
Replying to jef:
thanks for the patience. I think I finally got it right.
I just updated from svn. Everything (well, almost everything :) ) is all right. One little cosmetic change you can make is to update the extent.
Thanks for all your work!
comment:16 by , 15 years ago
Replying to cgsbob:
One little cosmetic change you can make is to update the extent.
I don't think the is a rendering issue. If you don't want to handle the null features at all, I'd suggest that you filter them out using a where clause.
I chatted about this very briefly on IRC and Bob reasonable suggested that the attribute table ought to show the field as NULL (perhaps blank) and the rendering might just not draw features with null fields for classification.
I skimmed the OGR provider and I see it makes no effort to distingish between NULL and non-null fields. Is it intended that providers can return features with NULL attributes marked in some fashion in the attribute map? Perhaps, those attributes should just not be added to the attribute map for that feature?
Skimming the Postgres provider, it also seems to make no effort to distingish between null and non-null field values.
Perhaps the problem is just at the provider level?