[Qgis-developer] Re: AW: [Qgis-user] why is EPSG:2180 not recognised?

[Richard Duivenvoorde]

Hi Micha,

we (actually Maciej..) are currently busy with the process of generating 
the srs.db on basis of the current official epsg-db using a script. In 
that way we can try to keep in sync with all 'official' epgs-changes.

for 2039 this means:
old
+proj=tmerc +lat_0=31.73439361111111 +lon_0=35.20451694444445 
+k=1.000007 +x_0=219529.584 +y_0=626907.39 +ellps=GRS80 +units=m +no_defs

new
+proj=tmerc +lat_0=31.73439361111111 +lon_0=35.20451694444445 
+k=1.0000067 +x_0=219529.584 +y_0=626907.39 +ellps=GRS80 
+towgs84=-48,55,52,0,0,0,0 +units=m +no_defs

It seems that that is what you want isn't it?

Regards,

Richard Duivenvoorde


Micha Silver wrote:
> Hello Richard:
> This thread from about two months ago on the qgis-users list got me to 
> recheck the projection parameters in QGIS for our local CRS. I found 
> that there's another error in the srs.db for epsg code 2039 for Israel.
> The correct proj4 string includes a datum tranform:  +towgs84=-48,55,52
> That part of the string does not appear in the distributed srs.db. I 
> added the correction with sqlitebrowser, and checked on-the-fly 
> projection, and it corrects an ~80 m. error that I was seeing before 
> when viewing WGS84 (GPS collected) data in the Israeli CRS.
> I seem to remember that you were "volunteered" to try to keep the srs.db 
> up to date. If I'm wrong, I appologize, and you can just ignore this. If 
> you are working on a mechanism to keep the srs.db in step with epsg, 
> then note this small discrepancy.
> 
> BTW, Arcview (8.3) also does the datum transform wrong! Same 80m. error. 
> Thanks to GRASS + proj4 to keep us on track...
> 
> Regards,
> Micha
> 
> Richard Duivenvoorde wrote:
>> Jean-Claude Repetto wrote:
>>
>>> Please read this thread on the PROJ.4 ML :
>>> <http://www.nabble.com/epsg-parameters-td16447986.html>
>>>
>>> This is Frank Warmerdam's answer :
>>>  >
>>>  > The problem is that if EPSG offers more than one transformation to
>>>  > WGS84 for a datum, the automated translation gives up and offers none
>>>  > of them preferring for the user to make the decision themselves.
>>>  >
>>>
>>> I think it would be better to create the srs.db database directly 
>>> from the EPSG database.
>>
>> Hi Jean-Claude,
>> if I read that nabble-thread, my conclusion is: it's at this moment 
>> not possible to do a 1to1 translation for the EPSG-db to srs.db 
>> because of the simple fact that one epsg can have more set's of 
>> parameters which are 'valid/best' for different parts of the world.
>>
>> I think there are some options though:
>>
>> - add the definition YOU prefer for this specific epsg to your local 
>> srs.db in qgis (using for example sqliteadmin)
>>
>> - it's also possible roll you're own projection for a qgis project 
>> isn't it? So you could make some 'template'-project in which you 
>> defined the projection with the exact parameters of you preference.
>>
>> - incorporate ALL available definitions of these multi-paramter-EPSG's 
>> and add some interaction with the user to qgis in case there are more 
>> definitions available for one EPSG-code. And let the user choose from 
>> this list?
>>
>> by the way: I will try to update the srs.db to match the ones used for 
>> proj (so only the ones where there is one set of parameters for one epsg)
>>
>> Richard Duivenvoorde
>> _______________________________________________
>> Qgis-user mailing list
>> Qgis-user at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>>
>>
>>
>> This mail was sent via Kinneret Mail-SeCure System.
>>
>>
> 
>