[postgis-devel] PostGIS in Action: regress difference from PostGIS 1.5
lr at pcorp.us
Sun Mar 31 08:55:17 PDT 2013
I guess some people really like to go thru our examples with a
fine-tooth comb. Anyway there was one that we just grabbed from our old
book not expecting it to change, low and behold the answer is different.
This I think is a result of resourcing of epsg files in PostGIS 2.0, and it
feels like a mistake that the datum was stripped.
From: Reston, VA, United States
Query for SRID in section 3.3.1 returns no rows
Posted: Mar 28, 2013 4:01 PM
Click to reply to this thread Reply
The select statement on pages 109-110 in version 2 of the PDF returns no
rows. Specifically, the proj4text column for the row having srid value 4269
does not contain the string "nad83," so the where clause condition
"proj4text ILIKE '%nad83%'" excludes that row.
I see that I get the correct row if I replace that clause with "srtext ILIKE
'%nad83%'" however I get back four additional rows, too.
The query at the bottom of page 110 returns no rows for the same reason.
Oh, this is with PostGIS 2.0.1 installed as part of OpenGeo suite 3.0.1.
Furthermore, in the source code download for PostGIS 2.0.3, the file
spatial_ref_sys.sql does not insert '+datum=NAD83' into proj4text in any row
as far as I can tell.
Message was edited by:
Added mention of second query on pg. 110 and spatial_ref_sys.sql.
Re: Query for SRID in section 3.3.1 returns no rows
Posted: Mar 31, 2013 10:49 AM in response to: dconger in response to:
Click to edit this message... Click to reply to this thread
Well that's annoying. I think this was from our 1.5 example and we didn't
In PostGIS 1.5, the proj4text for 4269 was:
+proj=longlat +ellps=GRS80 +datum=NAD83 +no_defs
and it was the only one that had datum=NAD83 in it.
In 2.0 as part of resourcing from epsg files, it seems this was updated to
not have a datum and is now equivalent in meaning to the other 4 rows you
are coming up with.
If you look at the others, you'll see they have exactly the same proj4text
which is all PostGIS cares about. I'll ask if this was a mistake in
resourcing that the datum was stripped or if it was intentional.
Thanks again for the catch. Much appreciated.
Leo and Regina
More information about the postgis-devel