[Proj] .NET / C# port of proj4

[Jason Askew]

 C software can most definately be linked into C#.  But that crosses
the mangaed/unmanaged code space, which isn't ideal.

I can think of several advantages, however (and I'm sure someone can
counter-match some disadvantages).

First off, I don't feel bad putting code into c# / .NET becuase it is
fairly portable with the Mono project covering the Unix/Linux side of
things.

The other is the vast simplifications I've encoutered and will
continue to do so, I'm sure.

Like the linked list for paralist and PJ_GRIDINFO...  they're gone,
replaced with very simple storage classes using C# generics.  All the
code to handle those linked list is gone, replaced mainly with a
foreach loop.

And string manipulation has gone from the world of pointers, strcpy,
sprintf to actual human readable code =).

File manipulation is easier.

I digress.

There is another side to this, this one is specific to windows...
I've got a hardware accelerated DirectX GIS viewer prototype working,
along with thin-plate-spline image warping (realtime!).  My end goal
is a real-time hardware acclerated (there's a lot of horsepower in the
GPUs these days) for doing image rectification/georeferencing.

I probably don't need to explain the aspect that Proj4 is filling in
such a piece of software.


On 6/7/06, Gerald I. Evenden <gerald.evenden at verizon.net> wrote:
> On Wednesday 07 June 2006 4:45 pm, Jason Askew wrote:
> > I am 10 hours into a C# / .NET port of proj4.
> >
> > My current focus is getting one specific function to work, that being
> > pj_transform from pj_transform.c
> >
> > I am at the point now that I'm dealing with PJ_GRIDINFO and
> > pj_apply_gridshift and other such matters.
> >
> > Kinda of a top down approach, if you will.
> >
> > This is not my first C to C# conversion but is definately by far the
> > most challenging.
> >
> > Anyway, I have questions.  As this will probably be the first post of
> > many, I'm going to use .NET / C# as the start of all my subjects lines
> > to keep a common format for this topic going.
> >
> > Most questions should be about the logic or concepts behind the project.
> >
> > So, question one:
> >
> > In file: pj_transform.c
> >
> > projected_loc is defined as so:
> >
> > XY         projected_loc;
> >
> > XY being defined as:
> >
> > typedef struct { double x, y; }     XY;
> >
> > buy then later in pj_transform.c, u and v members show up in
> > pj_transforms.c, like so:
> >
> >                     projected_loc.u = x[point_offset * i];
> >                     projected_loc.v = y[point_offset * i];
> >
> > I must be missing something painfully obvious.  I see the defines
> > wrapped around the def of the XY struct, i.e.:
> >
> > #ifndef PJ_LIB__
> > #define XY projUV
> > #define LP projUV
> > #else
> > typedef struct { double x, y; }     XY;
> > typedef struct { double lam, phi; } LP;
> > #endif
> >
> > but PJ_LIB__ is defined.
> >
> > Not to mention pj_inv and pj_inv expect the XY for and not the projUV form.
> >
> > I must be missing something obvious.
> >
> > Jason
>
> As the one who started all that, I will take the blame.  In some cases it does
> not matter whether it is geographic or Cartesian data being passed around so
> I used a generic UV name for a reference of material that was identical as
> far as the hardware was concerned.
>
> PROJ_LIB__ (same as old PJ_LIB__) designates that lib_proj.h is being used in
> a projection routine and the the macros defined inside its area are only
> applicable in those routines.
>
> I think PROJ_UV is only used in lproj.c.
>
> Don't worry about it. ;-)
>
> Can't C material be linked to C# software?  If not, pity.
> --
> Jerry and the low-riders: Daisy Mae and Joshua
> "Cogito cogito ergo cogito sum"
>    Ambrose Bierce, The Devil's Dictionary
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>