Hi Dmitriy, > And what about string list field subtype? > I.e. I need restricted String field to accept only predefined strings > from the list?
That could potentially be modeled with a OFSTEnumeration subtype, and an extra member variable of OGRFieldDefn with the list of accepted strings. A similar idea could be used to model coded values, OFSTCodedEnumeration? + a map, found for example in some FileGDB tables, as explained recently in http://trac.osgeo.org/gdal/ticket/5741. > Also for integer or dates fields the value range(s) or time period(s) > set will be worth adding. I.e. the tube_width (Integer) can only be in > range 100-183 and etc. I'm not sure how drivers would get those constraints though ? From SQL CHECK constraints ? Or would it be something that would be set by the application ? > And finally I think the default field value is the subtype > responsibility too. Not sure what you mean. There's already an embryonic default field value mechanism, but AFAIK, it is not used anywhere in the code base except in ogrfielddefn.cpp, and there's this comment whose rationale I don't have knowledge above. /** * \brief Set default field value. * * Currently use of OGRFieldDefn "defaults" is discouraged. This feature * may be fleshed out in the future. * */ void OGRFieldDefn::SetDefault( const OGRField * puDefaultIn ) Anyway, I believe there's potential for further enhancements in that area, but I'd like to keep this RFC focused on the subtypes already mentionned in it. Best regards, Even > > Best regards, > Dmitry > > 20.11.2014 01:14, Even Rouault пишет: > > Hi, > > > > This is a call for discussion on RFC 50: OGR field subtypes > > > > http://trac.osgeo.org/gdal/wiki/rfc50_ogr_field_subtype > > > > Below the summary : > > """ > > This RFC aims at adding the capability of specifying sub-types to OGR > > fields, like boolean, 16 bit integers or 32 bit floating point values. > > The sub-type of a field definition is an additional attribute that > > specifies a hint or a restriction to the main type. The subtype can be > > used by applications and drivers that know how to handle it, and can > > generally be safely ignored by applications and drivers that do not. > > """ > > > > Even > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
