Re: [gdal-dev] Design for sub-second accuracy in OGR ?

On 6 April 2015 at 09:39, Even Rouault wrote: > I should have mentionned what currently exists indeed : > > struct { > GInt16 Year; > GByte Month; > GByte Day; > GByte Hour; > GByte Minute; > GByte Second; > GByte TZFlag; /*

Re: [gdal-dev] Design for sub-second accuracy in OGR ?

Ok, this explanation looks reasonable. Best regards, Dmitry 07.04.2015 01:15, Even Rouault пишет: Le lundi 06 avril 2015 23:32:40, Dmitriy Baryshnikov a écrit : Why not read all date/time data from records as accurate as possible? That's what I intended and prototyped. Drivers analyze the

Re: [gdal-dev] Design for sub-second accuracy in OGR ?

Le lundi 06 avril 2015 23:32:40, Dmitriy Baryshnikov a écrit : > Why not read all date/time data from records as accurate as possible? That's what I intended and prototyped. Drivers analyze the date/time value and they set it with an evolution of the existing SetField() method for date/times, wh

Re: [gdal-dev] Design for sub-second accuracy in OGR ?

Why not read all date/time data from records as accurate as possible? For example for OFTDate we get date by GetFieldAsDateTime and time is zero. It's strange to analyse data structure during reading the records as we

Re: [gdal-dev] Add Mercator_variant_A method?

Le lundi 06 avril 2015 23:09:09, Brad Hards a écrit : > On Mon, 6 Apr 2015 01:56:16 PM you wrote: > > Le lundi 06 avril 2015 13:26:11, Brad Hards a écrit : > > > The problematic part is that "PROJECTION" definition. I was originally > > > going to argue it should be Mercator_1SP, but it looks like

Re: [gdal-dev] Design for sub-second accuracy in OGR ?

Le lundi 06 avril 2015 23:11:21, Dmitriy Baryshnikov a écrit : > Hi Even, > > It seems to me that this is duplicating of RFC 50: OGR field subtypes. > For example we have the master field type DateTime and Subtype - Year. > So the internal structure for date/time representation may be adopt to > s

Re: [gdal-dev] Design for sub-second accuracy in OGR ?

Hi Even, It seems to me that this is duplicating of RFC 50: OGR field subtypes. For example we have the master field type DateTime and Subtype - Year. So the internal structure for date/time representation may be adopt to such technique. Best regards, Dmitry 06.04.2015 15:02, Even Rouault

Re: [gdal-dev] Add Mercator_variant_A method?

On Mon, 6 Apr 2015 01:56:16 PM you wrote: > Le lundi 06 avril 2015 13:26:11, Brad Hards a écrit : > > The problematic part is that "PROJECTION" definition. I was originally > > going to argue it should be Mercator_1SP, but it looks like the EPSG > > decided to change it (in EPSG::2010.058) to this

Re: [gdal-dev] Design for sub-second accuracy in OGR ?

Le lundi 06 avril 2015 13:48:47, Even Rouault a écrit : > Le lundi 06 avril 2015 11:32:33, Dmitriy Baryshnikov a écrit : > > The first solution looks reasonable. But there is lack in precision > > field - there the only time is significant: > > > > ODTP_HMSm > > ODTP_HMS > > ODTP_HM > > ODTP_H >

Re: [gdal-dev] Add Mercator_variant_A method?

Le lundi 06 avril 2015 13:26:11, Brad Hards a écrit : > I'm looking at geopackage support, and particularly at the NGA's draft > "profile". > > It defines (and references) some spatial reference systems, including some > interesting variations that will require more work later. For tonight, lets >

Re: [gdal-dev] Design for sub-second accuracy in OGR ?

Le lundi 06 avril 2015 11:32:33, Dmitriy Baryshnikov a écrit : > The first solution looks reasonable. But there is lack in precision > field - there the only time is significant: > > ODTP_HMSm > ODTP_HMS > ODTP_HM > ODTP_H As I didn't want to multiply the values in the enumeration, my intent was

[gdal-dev] Add Mercator_variant_A method?

I'm looking at geopackage support, and particularly at the NGA's draft "profile". It defines (and references) some spatial reference systems, including some interesting variations that will require more work later. For tonight, lets look at just one case: PROJCS["WGS 84 / World Mercator",

Re: [gdal-dev] Unable to find various object files for GEOS and ogrsqlitedatasource

I think the issue was enabling geos support in the configure process but not passing it the directory for geos_config. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Unable-to-find-various-object-files-for-GEOS-and-ogrsqlitedatasource-tp5196680p5200064.html Sent from the G

Re: [gdal-dev] Design for sub-second accuracy in OGR ?

The first solution looks reasonable. But there is lack in precision field - there the only time is significant: ODTP_HMSm ODTP_HMS ODTP_HM ODTP_H etc. Best regards, Dmitry 05.04.2015 22:25, Even Rouault пишет: Hi, In an effort of revisiting http://trac.osgeo.org/gdal/ticket/2680, which