file size issue

[Jerl Simpson]

Lowell,

Thanks for the info.  I found out after some time that the ODBC
connection only works for Point shape layers.  Well, I think that's
the case anyway.  Some documentation I found said as much.  The data
I'm looking at is Line data.

Thanks again,

Jerl

On 6/24/05, Lowell Filak <lfilak at medinaco.org> wrote:
> The following message was sent by Jerl Simpson <jerl.simpso at GMAIL.COM>
> on Mon, 20 Jun 2005 08:37:29 -0500.
> 
> > That's the same conclusion I came to as well.  I thought I could
> > either use the C API or I could use the tile index files.  They are
> > all broken up into smaller files.  The issue with that is I would have
> > to modify the shp2mysql.pl file so it did not create a new table in
> > the database for each file of the tiling.
> >
> > Thanks again,
> >
> > Jerl
> >
> >
> > >
> > > Jerl,
> > >
> > > I think I may have missed something. If my understanding (from a
> > > conference session today) is correct the problem lies in GEO::Shapelib
> > > itself. It appears that it reads the geometries into an array which
> > > would still mean you would need enough ram to read the entire shapefile.
> > > The only workaround is to use shapelib via C directly instead of through
> > > the perl module. From C you would be able to iterate over each entity.
> 
> Jerl,
> 
> There is 1 last option if you would like to create an arrays.i include
> file for swig'ng shapelib.
> What I have currently is a swig'd version of shapelib that sort-of
> works. The geometry data is extracted from the shape into a few C arrays
> and there is a typemap required to make those available as perl arrays,
> otherwise they show up as _p_double=SCALAR(0x...) and are unuseable.
> 
> Lowell
>