[fdo-dev] SHP provider

[Haris Kurtagic]

Hi Dan,

true, but I thought that decimal is superset of single and double also
int16 can go ?
some of them can be problematic like int64 (isnt dbf about string than
it go in ?) but I wonder how is it implemented in mg and other
providers, right now?

I didn't want to go in details of every specific data types, just I
think some of them can be added?
Of course, data types conversions can be very complex.


Haris

-----Original Message-----
From: Dan Stoica [mailto:dan.stoica at autodesk.com] 
Sent: Monday, October 30, 2006 4:32 PM
To: dev at fdo.osgeo.org
Subject: RE: [fdo-dev] SHP provider

Hi Haris,

You cannot map double to decimal or int64 to 4 bytes numeric without the
risk of data truncation. And this is unacceptable as any other data
corruption.

Dan.

-----Original Message-----
From: Haris Kurtagic [mailto:haris at sl-king.com]
Sent: Monday, October 30, 2006 7:24 AM
To: dev at fdo.osgeo.org
Subject: RE: [fdo-dev] SHP provider


Hi Pierre,

True, DBF has limited number of types, and for other data sources there
is also limited number and no exact match to fdo data types
For example in Oracle there is no boolean etc..
Match between db type and fdo type is no so strict, I think.
For example right now shp provider is matching dbf number to int32, why
not to int16 or int64.

I was thinking that when for example apply schema is executed some types
could be changed , I suppose single,double would go to decimal, int to
numeric, etc.

Haris 

-----Original Message-----
From: Pierre Dalcourt [mailto:pierre.dalcourt at autodesk.com] 
Sent: Monday, October 30, 2006 1:15 PM
To: dev at fdo.osgeo.org
Subject: RE: [fdo-dev] SHP provider


Hi,

Its possible for SHP Provider to support more FDO data types.
However, you have to consider SHP/DBF limitations.  DBF only supports a
few types: numeric (stored in ascii format), string, blob, date, and
boolean.  To distinguish between int16/int32/int64 for example, you
would need to store some metadata indicating which of these types the
column represents.  There is (theoretically) no room for custom metadata
in the DBF/SHP files, although perhaps there is a way to hack around
that.  You would have to store metadata in a separate file.  There is
already code to store such information in an xml file, but it is
currently (mostly) disabled for technical reasons.  There are also other
considerations, such as the fact that since DBF stores numbers in ascii
format while FDO represents numbers in binary format, the range of
numbers you can store in FDO or DBF will never match up exactly.  Also,
you have to consider that applications outside your own will be
editing/creating SHP/DBF files which might break any artificial numeric
limits you impose since they are not aware of your metadata.

Pierre

-----Original Message-----
From: Haris Kurtagic [mailto:haris at sl-king.com]
Sent: October 29, 2006 11:56 AM
To: dev at fdo.osgeo.org
Subject: RE: [fdo-dev] SHP provider


As a meter a fact it is very simple, basically for shp provider data
store is the folder.
Apply schema will create shp files in folder (data store).

Anyhow I agree that this command should be implemented, it is important
to try to keep consistency across providers, to have a common level of
functionality as high as possible.

Haris

-----Original Message-----
From: Mateusz Loskot [mailto:mateusz at loskot.net] 
Sent: Sunday, October 29, 2006 2:46 PM
To: dev at fdo.osgeo.org
Subject: Re: [fdo-dev] SHP provider

Haris Kurtagic wrote:
> Hi,
> 
> Shape provider is suporting very limited range of fdo data type's.
> 
> I believe it is small change to add double,single int32,int64,..
> 
> Fdo shp provider is open for contributations ?

Haris, I'd like to join your question.
I'm also wondering the reason CreateDataStore command has not been
implemented yet.
Theoretically, it seems as not a big challenge, but I suppose there are
some details which I can't see but which make it tricky.
I'd be thankful for some comments from SHP provider developer(s).

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org For additional
commands, e-mail: dev-help at fdo.osgeo.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org
For additional commands, e-mail: dev-help at fdo.osgeo.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org
For additional commands, e-mail: dev-help at fdo.osgeo.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org
For additional commands, e-mail: dev-help at fdo.osgeo.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org
For additional commands, e-mail: dev-help at fdo.osgeo.org