[OSRS-PROJ] PROJ.4 usage in mapserver system - orthographicusage thread

Steve Lime steve.lime at dnr.state.mn.us
Wed Aug 20 12:17:44 EDT 2003


Has this discussion gone on off the list, I've seen no other follow-ups?
As one of the lead MapServer developers I'm certainly interested in
seeing problems resolved if they exist. I'm not however, an expert in
the current projection support within the software. I'm curious how, in
practice, other graphically oriented systems deal with the problem. 

Steve

Stephen Lime
Data & Applications Manager

Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937

>>> gerald.evenden at verizon.net 08/15/03 10:38AM >>>
Further evaluation of mapserver seems to indicate that examination
of the return of procedure msProjectPoint's return value is not
made.  It appears that a fundamental flaw may exist within mapserver
that makes it fail when points cannot be projected because they
are out of range of the projection procedure.

An expert in the internals of mapserver needs to respond to this
assessment before anyone can proceed.

PS: traffic on this group seems to have dwindled---NE power outage?

On Thu, 2003-08-14 at 22:49, Gerald I. Evenden wrote:
> I got curious about this "mapserver" system and its relation to
> PROJ.4 so I pulled it down and took a look at it.
> 
> Routines of interest seem to be mapproject.c and mapresample.c
> and calls to pj_transform and pj_fwd.
> 
> I noted that the output of pj_fwd was *not* tested for error
> in mapproject.c.  The output of pj_transform was checked
> (functional return) but I could not find it in the mapserver
> distribution and assume it was your value added to PROJ.4.
> 
> If the program was used so that data went directly through
> pj_fwd/inv, per the second half of the function  msProjectPoint
> then failure will occur since the return will be MS_SUCCESS
> regardless of the success of the pj_fwd/inv call.
> 
> The patch appears obvious but I will not attempt it until I
> successfully install the system.  I suspect the pj_transform
> is related to datum changes so I can ignore it (dummy procedure)
> for non datum shift usage.
-- 
Gerald I. Evenden <gerald.evenden at verizon.net>

----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.
----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.



More information about the Proj mailing list