Recent

Author Topic: proj.4 wrapper  (Read 3179 times)

ggkia

  • Newbie
  • Posts: 2
proj.4 wrapper
« on: December 27, 2016, 10:21:26 am »
Hello everyone
It is my first post here but i use free pascal for 2 years now

Anyway to the topic...
I uploaded a proj.4 wrapper
It is raw, not comments and just a single example, but basic stuff is there.

https://github.com/giangianoulas/fp_proj.4

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: proj.4 wrapper
« Reply #1 on: December 27, 2016, 08:05:43 pm »
I uploaded a proj.4 wrapper
It is raw, not comments and just a single example, but basic stuff is there.

Looks like a good start, but I can see some areas where you'll want to tighten it up a bit. There are probably only a couple of us here who do GIS and mapping with Pascal, so if want others to use your wrapper, you'll need to make sure it's fairly polished and well tested.

Also, some documentation would be helpful. For example, how do you use this? That's always interesting to hear about. Or perhaps a bit of discussion where the PROJ library would be useful compared to the GDAL library (eg, small size and minimal dependencies vs. GDAL's much larger size and dependency on other libraries). And where it's not useful (eg, when you need GDAL anyway to work with vector and raster files).

Here are some comments, in no particular order:

(1) PChar might one day point to PWideChar. That would break your code, so you need to use PAnsiChar with C string parameters. Or better yet, define in pj_types.pas your own type, something like,

  PJ_CSTR = PAnsiChar;

Now use PJ_CSTR wherever you're currently passing PChar.

(2) You probably need to take care that the record types are packed the same as they are in C. For example, you could do something like this:

 {$IFDEF MSWINDOWS}
  {$packrecords default} //assume library compiled with Visual C++, natural alignment
 {$ELSE}
  {$packrecords c} //assume library compiled with GCC
 {$ENDIF}

Be sure to test this thoroughly though.

(3) You might want to declare the function prototypes separately. The way you have it now, the only way someone can use the PROJ library is via your wrapper class, which dynamically loads the library.

(4) For a wrapper, you shouldn't need to use SysUtils and Classes in the wrapper units. No point in adding a dependency to them if they're not needed.

(5) Don't use the ancient StrPas function. Just cast the returned C string with AnsiString.

(6) Your example app requires Lazarus to be installed to compile it. That's overkill for a simple console app, which should only require FPC.

(7) Is there some reason why you post the binaries in your repository too? I would just link to the main PROJ site for binary downloads:

http://proj4.org

In any case, I don't think what you've posted is complete. Normally the PROJ library includes a number of data files.

(8) Even without testing, your wrapper's default Create constructor will fail on OS X. Not sure about Windows. Normally you want to pass a complete (expanded) path to LoadLibrary. While it's probably okay to assume that on Windows the proj.dll file will be in the same directory as the executable, proj.dll alone is probably not enough of a path.

(9) I'm puzzled by your paths to the Linux PROJ library. On Ubuntu, the normal location would be /usr/lib/libproj.so. That should be all you need for a default path. Note that the library will look in /usr/share/proj for its data files.

(10) Did you use a tool to parse the C header files? Sometimes that's a handy thing to do to prevent typos. I often use Ryan's parser here:

https://github.com/genericptr

While designed for Objective C, since ObjC superset of C it works pretty well with C headers too.


If you're interested in GIS and mapping with Pascal, you'll probably find this article useful:

https://macpgmr.github.io/MacXPlatform/PascalDynLibs_3.html

And if you're interested in mapping in a Web app, parts 2 and 3 in this article series should be of interest:

https://macpgmr.github.io/MacXPlatform/WebAppOverview.html


-Phil

ggkia

  • Newbie
  • Posts: 2
Re: proj.4 wrapper
« Reply #2 on: December 28, 2016, 08:32:05 am »
Phil

Thank you for your feedback.
I will consider those things and make the improvements at some point.

I added the binaries because i didnnot notice the precompiled on official site   :P

Anyway it will be updated soon with the fixes mentioned and some more

 

TinyPortal © 2005-2018