Opened 16 years ago
Closed 15 years ago
#2474 closed defect (fixed)
DateTime -> Date write support in Shapefile support
Reported by: | candrsn | Owned by: | Mateusz Łoskot |
---|---|---|---|
Priority: | high | Milestone: | 1.5.4 |
Component: | OGR_SF | Version: | unspecified |
Severity: | normal | Keywords: | shape |
Cc: | warmerdam |
Description
Shapefile write support for DateTime is hinted to in this notice
"Field %s create as date field, though DateTime requested.\n",
but the value written is always null.
This patch causes the conversion to take place.
--- ogr/ogrsf_frmts/shape/shape2ogr.cpp 2008-02-10 05:59:48.000000000 -0500 +++ ogr/ogrsf_frmts/shape/shape2ogr.cpp 2008-07-14 19:20:56.000000000 -0400 @@ -1242,6 +1242,7 @@
break;
case OFTDate:
+ case OFTDateTime:
{
OGRField sFld; int nFullDate =
Change History (5)
comment:1 by , 16 years ago
Cc: | added |
---|---|
Keywords: | shape added |
Owner: | changed from | to
Priority: | normal → high |
comment:2 by , 16 years ago
Status: | new → assigned |
---|
comment:3 by , 16 years ago
Mateusz,
Frank's patch had no effect for my attempt. (I have tried both SDE92 and PG as datasources, GML casts this to string so it is not a good datasource for testing)
I think a big decision needs to be made here. OFTDate and OFTDateTime are core types in the ogr model.
Things that cannot be handled by readers as explicit OGR types are often cast into OFTString as a weak type by the source driver.
Frank's patch yields no mechanism to cast writes of OFTDateTime into either OFTDate nor OFTString for shapefiles.
The big decision is to throw an error on attempting to handle OFTDateTime or cast OFTDateTime to some other type. I think OFTTime will have the same issues.
Each driver should implement (or downcast each datatype) or throw exceptions on the core OGR datatypes.
C.
comment:4 by , 16 years ago
Mateusz,
Please setup a test case, and debug through the code to see why my patch doesn't work. The idea is that the field is properly set to be OFTDate, and when SetField() is called on the field in the OGRFeature (either using the string or date/time methods) it should be properly initialized. Then the shapefile driver should treat it like any other OFTDate.
Note that the decision was already made to automatically degrade OFTDateTime to OFTDate. OFTTime is not handled, and presumably will trigger an error in the shapefile CreateField() method. I don't see any need to change these policies - just to fix the code to follow them.
comment:5 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Carl,
I have applied a fix in trunk (r14924) that instead sets the field type to OFTDate at the point where the field is added to the layer. This should achieve the same result with better "truth in advertising" about the field.
Mateusz,
Could you please add a test case to the test suite for this case, confirming that my fix actually works (it is untested). At that point please migrate the fix back to 1.5 branch.