Difference between revisions of "Programming Languages Project"

From OSGeo
Jump to navigation Jump to search
(removed the potential members section)
m (link to carto library)
 
(34 intermediate revisions by 7 users not shown)
Line 1: Line 1:
−
note: this is the quick first draft, please feel free to refactor and add,
 
−
but when adding, consider linking to other pages first, or creating
 
−
a new page on this wiki
 
−
 
 
= Goals =
 
= Goals =
  
−
This project is intended for information about how different programming languages are used in OSG software and what's available.  
+
This project is intended for information about and discussion how different programming languages are used in OSG software and what's available.  
  
 
A specific interest for this project is to discuss how to enhance or achieve interoperability between libraries and tools written in different languages.
 
A specific interest for this project is to discuss how to enhance or achieve interoperability between libraries and tools written in different languages.
−
 
−
I'm not sure if there should be an official committee for this (probably not), but I think this kind of project is needed as it serves for example the educational project and developers.
 
  
 
= Audience =
 
= Audience =
  
−
The contents are inteded for beginning developers
+
The contents are inteded for  
−
who are looking for basic information and pointers, and
+
* beginning developers who are looking for basic information and pointers,
−
for more seasoned developers who may not be well informed
+
* more seasoned developers who may not be well informed what's happening among languages they are not using, and
−
what's happening among languages they are not using.
+
* educators, who teach GIS programming and software development.
  
 
= Interoperability =
 
= Interoperability =
  
 +
* Use a language-independent standards-based information exchange mechanism, examples: http, W?S, XML-RPC
 
* Maintain functionally equivalent libraries in two languages (JTS/GEOS)
 
* Maintain functionally equivalent libraries in two languages (JTS/GEOS)
−
* Use Swig (GDAL, GEOS)
+
* Use Swig (GDAL, GEOS, GRASS, OSSIM)
 
* Use .Net/mono (MapWindow)
 
* Use .Net/mono (MapWindow)
  
 
== Using Swig ==
 
== Using Swig ==
  
−
* How to achieve a robust mapping between memory management in low level language
+
* How to achieve a robust mapping between memory management in low level language and in the interface language?
−
and in the interface language?
+
 
 +
The problem is that in low level language the programmer usually explicitly deletes an object ([http://ootips.org/yonat/4dev/smart-pointers.html smart pointers are an exception]) and in a scripting language the programmer usually doesn't. The binding should somehow make sure that all low level objects exist as long as they are needed but not longer. Different schemes exist in both worlds for managing this, but their interaction may make the problem even worse, especially when a single binding code (swig) should take care of it.
 +
 
 +
This problem exists for example in GDAL, where things like
 +
<nowiki>band = gdal::Open('filename').GetRasterBand(0)</nowiki>
 +
usually result in bad objects.
  
 
= C, C++, Fortran and other "low-level" languages =
 
= C, C++, Fortran and other "low-level" languages =
Line 33: Line 33:
 
* Many fundamental libraries are written in these languages
 
* Many fundamental libraries are written in these languages
 
* These can be wrapped efficiently with Swig
 
* These can be wrapped efficiently with Swig
 +
 +
An example of this is the OSSIM library.  OSSIM is written in C++ and focuses on high performance remote sensing and image processing of many, very large files.  It also supports parallel processing mechanisms under the hood.  SWIG bindings for Java (JOSSIM) and upcoming bindings for Python (POSSIM) will enable programmers in these libraries to access powerful processing capabilities through the Java and Python scripting languages.
 +
 +
= C# and .Net =
 +
 +
See [[DotNetProjects]]
  
 
= Java =
 
= Java =
Line 44: Line 50:
 
Scripting languages take the burden of memory management and compilation and linking
 
Scripting languages take the burden of memory management and compilation and linking
 
off from the developer.
 
off from the developer.
 +
 +
== Perl ==
 +
 +
* Geo modules in CPAN: http://cpan.org/modules/by-module/Geo/
 +
* Cartography modules in CPAN (there's only one): http://cpan.org/modules/by-module/Cartography/
 +
* Geography modules in CPAN: http://cpan.org/modules/by-module/Geography
 +
* Tree::R module in CPAN: http://cpan.org/modules/by-module/Tree/
 +
* GDAL/OGR has Swig-based Perl interfaces: http://map.hut.fi/gdal-perl/
 +
* GRASS has prototype Swig-based Perl interfaces: (http://download.osgeo.org/grass/grass6_progman/swig/)
 +
* Discussion about gdal, ogr, some Geo, and Gtk2::Ex::Geo modules: http://map.hut.fi/PerlForGeoinformatics/
 +
* Geo-Perl email list: https://list.hut.fi/mailman/listinfo/geo-perl
 +
* FreeGIS database on Perl: http://freegis.org/database/?cat=24
 +
 +
todo:
 +
 +
* Perl bindings for GEOS
 +
 +
== PHP ==
 +
[http://www.php.net PHP] stands for "PHP: Hypertext Preprocessor" and is a widely-used Open Source general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. Its syntax draws upon C, Java, and Perl, and is easy to learn. The main goal of the language is to allow web developers to write dynamically generated webpages quickly, but you can do much more with PHP. (from the [http://de2.php.net/manual/en/preface.php PHP manual preface])
 +
* CartoWeb: http://cartoweb.org/
 +
* Chameleon: http://chameleon.maptools.org/index.phtml
 +
* Mapbender: http://www.mapbender.org
 +
* ka-map: http://ka-map.maptools.org/
 +
* PHP/MapScript (UMN MapServer): http://mapserver.gis.umn.edu/docs/reference/phpmapscript-class/class-intro/
 +
* kvwmap: http://kvwmap.sourceforge.net/
 +
* GRASS: http://grass.itc.it/spearfish/php_grass_earthquakes.php
  
 
== Python ==
 
== Python ==
  
−
== Perl ==
+
* Python Cartographic Library: http://zcologia.org/cartography
 +
* GRASS has prototype Swig-based Python interface: (http://mpa.itc.it/markus/grass61progman/swig/)
 +
 
 +
== R ==
 +
 
 +
R is a language for statistical computing.
  
−
* Geo:: modules
+
* R spatial: http://r-spatial.sourceforge.net/
 +
* GRASS-R interface (spgrass6 class): http://grass.itc.it/statsgrass/
  
 
== Ruby ==
 
== Ruby ==
 +
 +
* FreeGIS database on Ruby: http://freegis.org/database/?cat=63
 +
 +
== See Also ==
 +
* [[OSGeo Cartographic Library]] - focused on application for flexible map production - eg. for printing.
 +
 +
[[Category:Education]]

Latest revision as of 04:56, 24 March 2009

Goals

This project is intended for information about and discussion how different programming languages are used in OSG software and what's available.

A specific interest for this project is to discuss how to enhance or achieve interoperability between libraries and tools written in different languages.

Audience

The contents are inteded for

  • beginning developers who are looking for basic information and pointers,
  • more seasoned developers who may not be well informed what's happening among languages they are not using, and
  • educators, who teach GIS programming and software development.

Interoperability

  • Use a language-independent standards-based information exchange mechanism, examples: http, W?S, XML-RPC
  • Maintain functionally equivalent libraries in two languages (JTS/GEOS)
  • Use Swig (GDAL, GEOS, GRASS, OSSIM)
  • Use .Net/mono (MapWindow)

Using Swig

  • How to achieve a robust mapping between memory management in low level language and in the interface language?

The problem is that in low level language the programmer usually explicitly deletes an object (smart pointers are an exception) and in a scripting language the programmer usually doesn't. The binding should somehow make sure that all low level objects exist as long as they are needed but not longer. Different schemes exist in both worlds for managing this, but their interaction may make the problem even worse, especially when a single binding code (swig) should take care of it.

This problem exists for example in GDAL, where things like 

band = gdal::Open('filename').GetRasterBand(0)

usually result in bad objects.

C, C++, Fortran and other "low-level" languages

  • Many fundamental libraries are written in these languages
  • These can be wrapped efficiently with Swig

An example of this is the OSSIM library. OSSIM is written in C++ and focuses on high performance remote sensing and image processing of many, very large files. It also supports parallel processing mechanisms under the hood. SWIG bindings for Java (JOSSIM) and upcoming bindings for Python (POSSIM) will enable programmers in these libraries to access powerful processing capabilities through the Java and Python scripting languages.

C# and .Net

See DotNetProjects

Java

Java is a hybrid in the sense that it's used for fundamental libraries but it is also often preferred also for its high-level features (strong OO). Notable Java OSG include JTS, uDig, ...

Scripting languages

Scripting languages take the burden of memory management and compilation and linking off from the developer.

Perl

todo:

  • Perl bindings for GEOS

PHP

PHP stands for "PHP: Hypertext Preprocessor" and is a widely-used Open Source general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. Its syntax draws upon C, Java, and Perl, and is easy to learn. The main goal of the language is to allow web developers to write dynamically generated webpages quickly, but you can do much more with PHP. (from the PHP manual preface)

Python

R

R is a language for statistical computing.

Ruby

See Also

Retrieved from "http://wiki.osgeo.org/w/index.php?title=Programming_Languages_Project&oldid=36925"