[Mapserver-dev] Fwd: Re: MapServer MySQL interface

[Steve Lime]

--=_ECB3EAF8.046517BC
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

That thread continued...
--=_ECB3EAF8.046517BC
Content-Type: message/rfc822

Received: from mail.state.mn.us
	(state.mn.us [156.99.125.109])
	by co5.dnr.state.mn.us; Fri, 20 Dec 2002 21:50:03 -0600
Return-Path: <bear at prometheus.org.yu>
Received: from ns0.tippnet.co.yu by mail.state.mn.us with ESMTP for steve.lime at dnr.state.mn.us; Fri, 20 Dec 2002 21:49:59 -0600
Received: from dual (d45.tippnet.co.yu [62.108.118.175])
	by tina2.tippnet.co.yu (8.11.6/linuxconf) with ESMTP id gBL3prl14127
	for <steve.lime at dnr.state.mn.us>; Sat, 21 Dec 2002 04:51:53 +0100
Date: Fri, 20 Dec 2002 04:52:09 +0100
From: Attila Csipa <bear at prometheus.org.yu>
To: "Steve Lime" <steve.lime at dnr.state.mn.us>
Subject: Re: MapServer MySQL interface
In-Reply-To: <se033034.095 at co5.dnr.state.mn.us>
References: <se033034.095 at co5.dnr.state.mn.us>
Message-Id: <20021220043202.F033.BEAR at prometheus.org.yu>
X-Mailer: Becky! ver. 2.00.11
X-RAVMilter-Version: 8.4.1(snapshot 20020919) (tina2.tippnet.co.yu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

> I thought the PostGIS folks were planning a MySQL implementation of
> PostGIS. Just want to make sure before heading down this road...

I am aware of that, but it I'm not sure it will be all that soon and
that my solution is in direct competition with it. Stored procedures
(which will be used by postgis) will appear in mysql 4.1 at the earliest,
but it looks like this particular feature may slip to even later, since it
recently disappeared from the 4.1 features list (but this might be an
error in the list itself, tho, I'm not on the mysql dev lists). Second,
maybe even more important that this is NOT a mysql implementation of
postgis, but rather a separate approach. As you maybe noticed my
connector implementation is based on almost pure ansi sql, so with
minimal changes it can be used practically with ANY sql database. It IS
slower than postgis, but even with postgis-mysql 4.1 available, this
solution is an option because it does not require to jump on a
relatively unstable new mysql, does not require to install postgis if
you do not already have it and, finally, it does not require additional
knowledge beside plain sql to use and modify. So basically it is a
'sql-lite' connector - compatible with practically everything and easy
to use, the downside being slower than a regular postgis approach.

Regards,
Attila

--=_ECB3EAF8.046517BC--