[Bug 227933] Review Request: libproj4 - Cartographic projection library

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=227933


Balint Cristian <rezso at rdsor.ro> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rezso at rdsor.ro




--- Comment #5 from Balint Cristian <rezso at rdsor.ro>  2008-08-25 17:00:51 EDT ---

>The old PROJ.4 system is still available at some web sites such
> as Remote Sensing Organization site.  The web sites associated with PROJ.4
> may have performed their own modification to the PROJ.4 library so there is
> no guarantee of the same collection of projections nor functional equivalence.

Hold on a bit, lets clarify first please.

  First, proj.4 passed incubation at osgeo.org and ATM is the main library for
whole osgeo.org suite. Libproj4 is a bit too early, proj4 _is_ alive and
getting
love but at this time with joint efforts of osgeo.org:
http://trac.osgeo.org/proj/

  Second, ask osgeo.org chairman opinion (Frank Warmerdam):

cbalint> folks, what is the diff btwn:
http://members.verizon.net/~vze2hc4d/proj4/ and http://trac.osgeo.org/proj/ ?!
FrankW> libproj4 is Geralds version of proj.4 that focuses on only projections.
FrankW> The long term plan is to refactor proj.4 to use it, withproj.4
providing initialization files, datums, and other high level coordinate system
services
<FrankW> but for the time being, you are generally best off using proj.4 unless
you really want to try one of Gerald's new bits of work.
cbalint> FrankW, is it sure that osgeo will rebase on that libproj ? Might be
matacrs related ?
<FrankW> It is not sure. 
<FrankW> It is just my intention (and Geralds).
<FrankW> But I've intended to do it for some time and it hasn't happened yet.
<cbalint> FrankW, thanks for quick response.
<FrankW> Certainly it will be within the metacrs project if it occurs.

 Clearly its too early. If import this to fedora will create more schizo' for
following packages:
 - ogdi
 - gdal
 - grass
 - mapserver
 - qgis

A bounch of other real struggling issues, a bit dataset related, let me
introduce:

 Its enough that we/I have problem with projections database (EPSG) (i am
unsatisfied, but I might wait metacrs instead) since there are 2 variants of
.csv sets one for proj.4 and one for gdal in .csv format as geodetic datas,
best should be to emmit a new 'epsg-dataset' fedora one called package to unify
and be able respin any time any fresh epsg sets for fedora purpose and share it
commonly to any package that use it it (grass/gdal/proj), its doable, and this
mini=project might go metacrs upstream, unless metacrs have far way better
solution and decide to rewrite all api's handling these issues of datasets.
  I dont really like how epsg datas are derived now into .csv,  I was talking
with EPSG in particular how to choose best TransformationParams for a
projection to avoid duplicates, a problem where gdal choosed to drop and avoid
to threat the problem (one main issue). I work on this within elegand solution
using EPSG-pgsl->sqlite->.csv with a fancy logic to generate our epsg-dataset


 A third one problem, related to this libproj4 especialy one that induce
confusion in lower functional layers (i mean here not database but how math
libraries (I mean libroj4 itself) will probaly induce more problems, i even
dont want to think it.

  Please see if interested what metacrs is related:
http://wiki.osgeo.org/wiki/MetaCRS

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.