[fdo-dev] SHP provider

[Pierre Dalcourt]

True, SHP Provider currently supports int32 in applyschema.  It was
added because Map needed it for technical reasons (if memory serves
correctly).  Int32's are mapped to DBF numeric type with 0 scale and a
predetermined length, but it's not a 100% accurate mapping and there is
unfortunately no way to make it 100% accurate.

So yes, you could support double, single, int16, int64 in the same
manner.  But as I've mentioned in a recent email, you have to be aware
that other applications will create DBF data that doesn't map properly
to whatever corresponding FDO type you picked.  For example, If you want
to create an int16 fdo property via ApplySchema, and you create a DBF
numeric column with length=5 and scale=0, another app that writes to SHP
might insert a value "80000" which doesn't fit in an int16.  In such a
case when the FDO client tries to read this data, you will likely have
to throw an exception indicating the data is out of range (in the future
it would be better to have a logging system in place so we can skip or
truncate such values, and log warnings instead of throwing exceptions).

Pierre

-----Original Message-----
From: Haris Kurtagic [mailto:haris at sl-king.com] 
Sent: 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