Bug 227933 - Review Request: libproj4 - Cartographic projection library
Review Request: libproj4 - Cartographic projection library
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Package Reviews List
http://www.cora.nwra.com/~orion/fedora/
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-08 17:56 EST by Orion Poplawski
Modified: 2009-01-30 13:54 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-30 13:54:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2007-02-08 17:56:39 EST
Spec Name or Url: http://www.cora.nwra.com/~orion/fedora/libproj4.spec
SRPM Name or Url:
http://www.cora.nwra.com/~orion/fedora/libproj4-050319-1.fc6.src.rpm
Description: 

This library supports over 170 projections including many used in national
grid systems.  Many more projections are available by selection of appropriate
values for control parameters of current base projections.

Circa 2002 the libproj4 system is an outgrowth of the author's PROJ.4 system
and corrected inconsistencies of the old system and  improved overall
operation.  It also ensured that identifier namespace became restricted to
PJ_*/pj_*.  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.
Comment 1 Michael Schwendt 2007-02-09 18:08:30 EST
> %post -p /sbin/ldconfig
> 
> %postun -p /sbin/ldconfig
>
> %files
> %defattr(-,root,root,-)
> %doc manual.pdf
> %{_bindir}/lproj

Huh? /sbin/ldconfig but no libs?

> %files devel
> %defattr(-,root,root,-)
> %{_includedir}/lib_proj.h
> %{_libdir}/libproj4.so

Is this shared lib supposed to be linked to and available at
run-time? In that case it is included in the wrong package.

And it is poorly named. On the contrary, the PROJ.4 system uses
a versioned soname.

> %doc manual.pdf

This aims at developers and should be moved into the -devel package.
Comment 2 Jason Tibbitts 2007-06-27 19:05:12 EDT
Any response to Michael's comments?
Comment 3 Jason Tibbitts 2007-07-08 12:38:32 EDT
Still no response; setting NEEDINFO.  I will close this ticket soon if there is
no further progress.
Comment 4 Orion Poplawski 2007-07-09 16:14:09 EDT
Sorry for the delay.  Got an update here:

http://www.cora.nwra.com/~orion/fedora/libproj4.spec
http://www.cora.nwra.com/~orion/fedora/libproj4-050319-2.src.rpm

* Mon Jul  9 2007 - Orion Poplawski <orion@cora.nwra.com> - 050319-2
- Move .so to main package and manual to -devel.

Upstream makes no provision for a versioned soname.  As I understand it, it is
problematic to add one in case upstream decides on a different scheme later on.
Comment 5 Balint Cristian 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
Comment 6 Balint Cristian 2008-08-25 17:04:55 EDT
  My statements are really functionality related. Again i personaly would't like
this package just for sake of its existence in fedora.

 However lets debate this issue.

//cristian.
Comment 7 Fabian Affolter 2009-01-29 08:53:49 EST
Why is the "fedora-review" flag set on this?
Comment 8 Orion Poplawski 2009-01-30 13:54:48 EST
I believe because back in the day, that is what one did when one submitted a review.

I don't have a burning need for this to be in Fedora.  But gdl uses this library rather than the main PROJ.4 distribution.  Actually, gdl uses a very old version (now) of libproj4, so we'll see where that moves.  I'll close for now.

Note You need to log in before you can comment on or make changes to this bug.