Opened 12 years ago

Closed 10 years ago

Last modified 10 years ago

#229 closed enhancement (fixed)

shp2pgsql ability to transform from one spatial ref to another

Reported by: robe Owned by: jadams
Priority: medium Milestone: PostGIS 2.0.0
Component: postgis Version: main
Keywords: history Cc:


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.

Change History (8)

comment:1 Changed 12 years ago by pramsey

Resolution: wontfix
Status: newclosed

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

comment:2 Changed 12 years ago by robe

Resolution: wontfix
Status: closedreopened

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

comment:3 Changed 12 years ago by pramsey

Milestone: postgis 1.5.0postgis 2.0.0

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?

comment:4 Changed 12 years ago by 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

comment:5 Changed 12 years ago by pramsey

Milestone: postgis 2.0.0FUTURE

comment:6 Changed 10 years ago by jadams

Owner: changed from pramsey to jadams
Status: reopenednew

comment:7 Changed 10 years ago by jadams

Resolution: fixed
Status: newclosed

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.

comment:8 Changed 10 years ago by robe

Keywords: history added
Milestone: PostGIS FuturePostGIS 2.0.0
Note: See TracTickets for help on using tickets.