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@xxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rezso@xxxxxxxx --- Comment #5 from Balint Cristian <rezso@xxxxxxxx> 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review