[Proj] Robinson discrepancy btwn proj and cs2cs
William K
woklist at charter.net
Wed Aug 17 14:49:42 EDT 2005
(forgot about the list change - Mac OS X Mail address 'memory'
feature had the old address, now removed)
I thought it might be some spheroid transformation thing, from some
past cs2cs questions on the list. My brain shorts out a bit when I
start to think about ellipsoids, spheroids and datums - so, which one
is giving the correct value?
I'm guessing that MAPublisher is not a good comparison, since it
tends to dumb down projection stuff (never sure what it does
sometimes, especially with ellipsoid transformations, and no sphere
selection, you have to enter major/minor ellipsoid axes).
I thought I had looked at this before, but using the sphere ellipse
in proj 4.4.9 gives:
Sumomo:~ williamk$ proj +proj=robin +ellps=sphere
0 45
0.00 4799694.61
^C
Sumomo:~ williamk$ cs2cs +proj=longlat +ellps=sphere +to +proj=robin
+ellps=sphere
0 45
0.00 4799694.61 0.00
^C
They're the same now, but different from either ellipsoid case.
Closer to the proj ellipsoid. I could only read off coordinates from
a clikc in a GRASS window, so they're not exact, but at a large
enough zoom, they're very close to the cs2cs case.
I guess it's just habit to use WGS84 for small-scale stuff (regions/
continents and world), I should probably update my habits, huh?
Remove those transformation issues from the equation (literally).
I'll check this with GRASS and MAPublisher when I'm feeling better
and back at work (hopefully tomorrow).
Oh, and what is that 3rd number in the cs2cs output? The man page
didn't say.
On Aug 17, 2005, at 1:11 PM, Frank Warmerdam wrote:
> William,
>
> I believe the issue is that Robinson is a spherical-only projection.
> So internally the ellipsoid is changed from WGS84 to a sphere.
> The cs2cs command notices that the two coordinate systems have
> different earth models, and applies a sphere to ellipsoid conversion
> as part of the operation.
>
> The ellipsoid to ellipsoid conversion approach changed in a
> fairly recent PROJ.4 library release, hence the dfference. In
> the past, if there was no datum shifting information, lat/long values
> were treated unchanged when going from raw ellipse to raw ellipse.
>
> I am considering changing the "new" behavior, since it seems to
> different from what most other systems do, and what people expect.
> Feedback on this idea is welcome.
>
> PS. I have rerouted this email to proj at lists.maptools.org, and I have
> completely removed the proj list from xserve.flids.com.
>
-----
William Kyngesburye <kyngchaos at kyngchaos.com>
http://www.kyngchaos.com/
"Oh, look, I seem to have fallen down a deep, dark hole. Now what
does that remind me of? Ah, yes - life."
- Marvin
More information about the Proj
mailing list