shp2pgsql ability to transform from one spatial ref to another

[robe]

I'm thinking this is a very simple thing to add to have another switch that allows a user to transform from the native spatial ref of the data to the desired spatial ref. (of course if they want this, they would be obliged to specify a from and a to similar to ogr2ogr)

If the -s and whatever switch for to (maybe a -t) is specified, then we add an ST_Tranform call to the insert/copy. Or am I making this sound simpler than it is.

Would save me a bit of hassle, though no one has complained about it. I'm also thinking it might be more important when we have geography --- if you get state plane data or something of that sort (that you commonly get on state sites), then you'll want to transform it to 4326 before feeding into geography.

[pramsey]

I think we'll always have more important things to do. For people who need this functionality operationally, there's ogr2ogr.

[robe]

Well ogr2ogr doesn't support geography yet and I still prefer the dbf handling ability of shp2pgsql over that of ogr2ogr.

My thinking for this was more of the usecase

geometry (of stateplane/nad../utm) -> directly convert to geography

and for that you will have to write transform glue anyway is my understanding so why not offer the same logic for those who want to transform on the fly.

When you are trying to load up all of tiger -- its really nice to have that be a one step process. Instead of load --> transform -> drop column

[pramsey]

Without a native SRTEXT handler, this isn't going to happen. Remember that shp2pgsql has no access to the spatial_ref_sys table so it would have to handle the SRTEXT in the .prj file itself. Basically, if we make shp2pgsql depend on OGR, then we could do it. At which point... maybe we drop our shp2pgsql code more-or-less entirely and replace it with an OGR-based loader?

[robe]

I suppose that wouldn't work in copy mode. I guess I was thinking about the sql insert mode and that we would do something like

INSERT INT.... ST_Transform(goemhere, 4326)

In which case the not having spatial_ref_sys access is kind of a non-issue since psql will have such access

[jadams]

Resolved in trunk in revision 6922. The new parameter is -r <srid>, the srid to reproject from. -s is the srid to reproject to, unless you use -G in which case 4326 is the srid to reproject to. So the combination of -G and -r will allow you to go directly from a state plane shapefile to a geography table.

-r does not work with -D.