[Gdal-dev] Mysql support

[Howard Butler]

Joe,

Section 3.2.2.2 of the OGC SFSQL Spec (99-049) doesn't seem to say 
anything about the storage of the geometry type column in the 
geometry_columns table.  By "standard" do you mean to say the OGC 
SFSQL spec, or how the shp2mysql perl script was loading the data? 
In the OGR MySQL driver, I am currently doing what PostGIS does for a 
geometry_columns table, which was a 30 character field for type.

I can only speculate on the MySQL crashing.  Is it the server 
crashing, or the client?  Is everything on Windows, or is the server 
on windows and the client is connecting from something else?

I did most of my development with 5.0.16.  Are you using the same 5.x 
version, or something different?  Frank did some work on getting 
things to behave well on the 4.x series, and he did some testing on 
Windows.  Anyway, the MySQL bugzilla had quite a few issues related 
to WKB generation.  This is one possibility.

The other is that query is possibly doing a double free and/or there 
is something funky with the spatial filter setting stuff.  Without a 
traceback, it is hard to know.

Any more info you can give me to go from would be great.  Also, you 
might put together a GDAL bugzilla report with this stuff and CC me 
to it.  We can track it there.

Howard



At 12:00 PM -0500 2/18/06, Miller Joseph wrote:
>Howard,
>I was manually using sql to create the tables.  I tried extracting sql
>from the old perl script that came with mapserver to create the tables,
>but it looks like you guys interpret the standard a little different (eg
>the feature type as a varchar intead of an int in the geometry_columns
>table).  I got the Feb 18 build and it worked fine for loading and
>getting metadata using ogr2ogr and ogrinfo.  I then rebuilt mapserver
>with the new gdal build but was unable to get anything to display using
>shp2img.  I consistently get a "memory cannot be read error" followed by
>the MySQL service crashing.  Is anyone else getting this or maybe it is
>just a windows issue?  I am using mysql 5.0 on an xp pro machine.
>
>Thanks,
>Joe
>
>-----Original Message-----
>From: Howard Butler [mailto:hobu at iastate.edu]
>Sent: Friday, February 17, 2006 2:18 PM
>To: Miller Joseph; gdal-dev at lists.maptools.org
>Subject: Re: [Gdal-dev] Mysql support
>
>Joe,
>
>If you can do a cvs update, there were quite a few changes to the mysql
>driver yesterday and the day before.  These may have an impact on your
>issues.
>
>Also, you can just let ogr2ogr *create* the spatial_ref_sys and
>geometry_columns table for you in a fresh database without manually
>doing it yourself.  Were you just letting ogr2ogr do it, or were you
>doing with some sort of sql command?
>
>Howard
>
>At 12:14 PM 2/17/2006, Miller Joseph wrote:
>>Content-class: urn:content-classes:message
>>Content-Type: multipart/alternative;
>>          boundary="----_=_NextPart_001_01C633ED.EB75D952"
>>
>>Hey all,
>>With some tweaking of ogrmysqllayer.cpp and pcrtypes.h I was able to
>>get the daily build of feb 13 to compile and link on a windows xp
>>system using visual c 6.0.
>>
>>I used to ogr2ogr to create the Geometry_Columns table and I created a
>>spatial_ref_sys table as described in:
>><http://home.gdal.org/projects/osvecdb/sfsql-schema.html>http://home.gd
>>al.org/projects/osvecdb/sfsql-schema.html
>>
>>I altered the geometry_columns so that the srid column was a foreign
>>key from the spatial ref table.
>>
>>I am still not having luck having ogrinfo reflect the srid information
>>I entered.  I even made sure that data I entered using the Geomfromtext
>
>>function included the srid.  My question is whether I am doing
>>something wrong or if I should wait for a later build to be released
>>before the spatial_ref_sys table is supported??
>>
>>Thanks in advance,
>>Joe Miller
>>
>>_______________________________________________
>>Gdal-dev mailing list
>>Gdal-dev at lists.maptools.org
>>http://lists.maptools.org/mailman/listinfo/gdal-dev