[postgis-devel] KML from PostGIS patch
pramsey at refractions.net
Tue Dec 5 10:55:18 PST 2006
I'd suggest not doing the transform and just leave it as a documented
requirement to use transform() inside. If you do it internally, for
people who have bad SRS settings on their geometry you'll have to do
various reporting of errors.
On 5-Dec-06, at 10:47 AM, Eduin Carrillo wrote:
> Ok. Here a new patch with these changes. What about transform the
> geometry to
> WGS84 directly from lwgeom_kml.c? I made public the "transform"
> function in
> lwgeom_pg.h (Datum transform(PG_FUNCTION_ARGS);) and tried this
> code but
> postgresql crashes... ideas?
> geom = (PG_LWGEOM *)DatumGetPointer(DirectFunctionCall2(
> transform, PointerGetDatum(geom), 4326));
> --- strk at refractions.net escribió:
>> On Mon, Dec 04, 2006 at 01:02:01PM -0600, Eduin Carrillo wrote:
>>> Hi list.
>>> I were looking for a fast way to produce kml code from PostGIS
>>> but AsKML
>>> function were just a Wish
>>> WishList) . Finally,
>>> this is a patch for revision 2531 to add the long waited AsKML
>>> function to
>> Hi Eduin, I took a look at your patch.
>> I'd reccomend you be explicit about supported geometry types
>> (there's a switch with a default case assuming it's a colelction).
>> I'm sure you copied that parts from other files, but since curved
>> geometries are being added we should actually be explicit
>> in *all* other files too to make sure a curve is not implicitly
>> considered a COLLECTION, resulting in a likely disaster.
>> Also, please consider adding a regress test for the function,
>> see the regress/ directory.
> Correo Yahoo!
> Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
> Regístrate ya - http://correo.espanol.yahoo.com/
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
More information about the postgis-devel