SEO

Hi,

One function that we would love to see in pgAdmin would be a wrapper
for pgsql2shp, so that you can export queries to a shapefile directly.
Would that be possible?

WBL

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

I mean, would it be technically possible.
It might be possible for us to provide funding if it is.

On Nov 13, 2007 2:49 PM, Willy-Bas Loos <willybas@gmail.com> wrote:
> Hi,
>
> One function that we would love to see in pgAdmin would be a wrapper
> for pgsql2shp, so that you can export queries to a shapefile directly.
> Would that be possible?
>
> WBL
>

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Willy-Bas Loos wrote:
> I mean, would it be technically possible.
> It might be possible for us to provide funding if it is.
>
> On Nov 13, 2007 2:49 PM, Willy-Bas Loos <willybas@gmail.com> wrote:
>> Hi,
>>
>> One function that we would love to see in pgAdmin would be a wrapper
>> for pgsql2shp, so that you can export queries to a shapefile directly.
>> Would that be possible?

It's possible, but we don't tend to add arbitrary functionality for
add-ons. If we look to support postgis, we need to do it fully.

Regard,s Dave

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

what would that mean?
It´s all SQL, so what else is to be supported? Maybe shp2pgsql too? (i
don´t see why, pgAdmin supports output to file (CSV) now, but no
matching function backwards)
Or would it mean collaborating with uDig (run by refractions btw), to
provide a complete gis viewing experience? Sounds like that would only
complicate things needlessly.
Is anybody else out there interested in PostGIS support for pgAdmin?

And finally, would it be possible for us to create an add-on to
pgAdmin ourselves and share it w/ the world? (e.g. the one i
proposed). That is, without introducing upgrade possibilities.

Cheers,

WBL

On Nov 15, 2007 5:57 PM, Dave Page <dpage@postgresql.org> wrote:
>
> Willy-Bas Loos wrote:
> > I mean, would it be technically possible.
> > It might be possible for us to provide funding if it is.
> >
> > On Nov 13, 2007 2:49 PM, Willy-Bas Loos <willybas@gmail.com> wrote:
> >> Hi,
> >>
> >> One function that we would love to see in pgAdmin would be a wrapper
> >> for pgsql2shp, so that you can export queries to a shapefile directly.
> >> Would that be possible?
>
> It's possible, but we don't tend to add arbitrary functionality for
> add-ons. If we look to support postgis, we need to do it fully.
>
> Regard,s Dave
>

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Willy-Bas Loos wrote:
> what would that mean?
> It´s all SQL, so what else is to be supported? Maybe shp2pgsql too? (i
> don´t see why, pgAdmin supports output to file (CSV) now, but no
> matching function backwards)
> Or would it mean collaborating with uDig (run by refractions btw), to
> provide a complete gis viewing experience? Sounds like that would only
> complicate things needlessly.
> Is anybody else out there interested in PostGIS support for pgAdmin?

I'm interested in supporting it, but if we're going to do it, we should
do it properly. If there really is nothing needed but to allow dumping
of shapes, then thats fine, but it doesn't seem like it would be all
(and I don't know PostGIS so can't really make an informed comment).

Mark; can you comment on what would be needed in pgAdmin to claim we
support PostGIS?

> And finally, would it be possible for us to create an add-on to
> pgAdmin ourselves and share it w/ the world? (e.g. the one i
> proposed). That is, without introducing upgrade possibilities.

There is no add-in functionality at the moment, though we have discussed
using the embeddable python interpreter to add something.

I'm happy to accept suitable patches to do what is required in the core
code though, provided they cover enough for us to claim we support
PostGIS, and not just odd bits of it.

/D

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On Fri, 2007-11-16 at 13:00 +0000, Dave Page wrote:

> I'm interested in supporting it, but if we're going to do it, we should
> do it properly. If there really is nothing needed but to allow dumping
> of shapes, then thats fine, but it doesn't seem like it would be all
> (and I don't know PostGIS so can't really make an informed comment).
>
> Mark; can you comment on what would be needed in pgAdmin to claim we
> support PostGIS?


Hi Dave,

In terms of operation, PostGIS is 95% server-side code, with the only
client-side code being the shp2pgsql/pgsql2shp loaders which are used to
convert from shapefiles to PostGIS and vice-versa. pgsql2shp connects to
a database and writes a shapefile to local disk, whereas shp2pgsql
outputs a series of INSERTs to stdout which can be piped through psql
for insertion.

The hardest part is likely to be how to ensure that pgAdmin ships with
the latest versions of these executables if this is the way you decide
to go; they do tend to get subtly tweaked between releases to iron out
corner cases.

In general, I think the biggest complaint regarding pgAdmin on the
mailing lists relates to the fact that the display control won't display
results with really long lines (geometries representing country outlines
can be fairly big), although I'm not sure whether there is anything much
that can be done about this


HTH,

Mark.

--
ILande - Open Source Consultancy
http://www.ilande.co.uk



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Mark Cave-Ayland wrote:
> On Fri, 2007-11-16 at 13:00 +0000, Dave Page wrote:
>
>> I'm interested in supporting it, but if we're going to do it, we should
>> do it properly. If there really is nothing needed but to allow dumping
>> of shapes, then thats fine, but it doesn't seem like it would be all
>> (and I don't know PostGIS so can't really make an informed comment).
>>
>> Mark; can you comment on what would be needed in pgAdmin to claim we
>> support PostGIS?
>
>
> Hi Dave,
>
> In terms of operation, PostGIS is 95% server-side code, with the only
> client-side code being the shp2pgsql/pgsql2shp loaders which are used to
> convert from shapefiles to PostGIS and vice-versa. pgsql2shp connects to
> a database and writes a shapefile to local disk, whereas shp2pgsql
> outputs a series of INSERTs to stdout which can be piped through psql
> for insertion.

Oh, in that case then it does sound like what Willy-Bas is asking for
would be all we need :-)

Willy-Bas; are you able to look at this? I'm not sure if any of the
regular developers would be interested or have time (I fall firmly into
the latter category right now).

> The hardest part is likely to be how to ensure that pgAdmin ships with
> the latest versions of these executables if this is the way you decide
> to go; they do tend to get subtly tweaked between releases to iron out
> corner cases.

I would probably not ship them (there would be licencing issues there
anyway), but just add a config option so the user can select the version
they want

> In general, I think the biggest complaint regarding pgAdmin on the
> mailing lists relates to the fact that the display control won't display
> results with really long lines (geometries representing country outlines
> can be fairly big), although I'm not sure whether there is anything much
> that can be done about this

No, not really - it's a limitation of the wxWidgets/OS controls. I've
had complaints like that in the past and found it was because people
were trying to display a table full of 6MB shapes! Even one or two of
those is more than the grid will ever handle well for fairly obvious
reasons I think.

Thanks Mark!

/D

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

> Willy-Bas; are you able to look at this? I'm not sure if any of the
> regular developers would be interested or have time (I fall firmly into
> the latter category right now).
I'm not a C programmer myself, but I'll see what resources i can win
for this case. It won't be very easy, so if you do happen to find
programmers who are willing and able, that would be lovely.
Like i said, it might be possible to provide some funding.

Thanks!

WBL

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend