[GRASS-dev] Re: [gdal-dev] interpretation of nodata in OGR libraries

Markus Neteler neteler at osgeo.org
Tue Oct 7 14:54:28 EDT 2008


(carrying over to grass-dev)

On Tue, Oct 7, 2008 at 8:40 PM, Frank Warmerdam <warmerdam at pobox.com> wrote:
> Dylan Beaudette wrote:
>>
>> Hi,
>>
>> I am not sure if this is a DBF issue, or something deeper in OGR, but
>> there does not appear to be a mechanism for preserving 'nodata' or NULL
>> values when exporting from GRASS to vector formats through v.out.ogr.
>
> ...
>>
>> It seems that on export via OGR there is some kind of mangline of nodata.
>> This issue is a serious problem anytime you need to move vector data between
>> applications, through the use of an intermediate file (usually a shapefile).
>>
>> Any ideas on what could be causing this problem? Fixing it would solve
>> several important issues. If need be I will file a new ticket on the topic.
>>
>> Relevent tickets?
>> http://trac.osgeo.org/gdal/ticket/809
>> http://trac.osgeo.org/gdal/ticket/528
>
> Dylan,
>
> Generally speaking OGR understands about null attribute values, though
> there may be no way to represent them in some formats.  They should work
> fine in shapefile format though.
>
> Reviewing the mk_att() function in v.out.ogr's main.c I don't see
> any effort to distinguish between null and non-null attributes so
> I think the problem is just a limitation of v.out.ogr.  If possible,
> I'd suggest fixing it there.

Sounds good :)
Does anyone know how to fix
 vector/v.out.ogr/main.c
to support NULLs? I see db_set_value_null() in
 lib/db/dbmi_base/value.c
which might be relevant.

Markus


More information about the grass-dev mailing list