Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#1079 closed defect (fixed)

on the fly projections do not work

Reported by: pcav Owned by: homann
Priority: critical: causes crash or data corruption Milestone: Version 1.2.0
Component: Projection Support Version: Trunk
Keywords: srs.db datum Cc: lami@…, marco.pasetti@…, msieczka, neteler
Must Fix for Release: Yes Platform: All
Platform Version: Awaiting user input: yes

Description

Layers with different projections in some cases are not aligned properly when enabling on the fly projections. This may be due to GDAL, as ponted out by Maciek:

QGIS fails to recognize many SRSes at layer load time, due to a change in GDAL [1].

[1]http://www.nabble.com/forum/ViewPost.jtp?post=16592790&framed=y

Attachments (2)

qgis_fly_nodatum.png (51.1 KB) - added by hamish 13 years ago.
100m offset due to missing datum transform NZ Map Grid - LL WGS84
Gauss_Boaga.tar.gz (38.3 KB) - added by leolami 13 years ago.
Grass Location with towgs84 parameters

Download all attachments as: .zip

Change History (33)

comment:1 Changed 13 years ago by leolami

Cc: lami@… marco.pasetti@… added

I tried it in QGIS 0.10 for Windows build by Marco Pasetti and it works

fine. What about gdal version used here?

Leonardo

comment:2 Changed 13 years ago by msieczka

Cc: msieczka added
Milestone: Version 0.9.2
Platform: DebianAll
Priority: major: does not work as expectedcritical: causes crash or data corruption

AFAIK, QGIS fails to recognize only SRSs which contain an *explicit k parameter* in the SRS proj4 string (which are several hundred SRSs anyway). It does recognize other properly though. The nature of the problem depends on the *particular* coordinate system *and GDAL version*, and has it's background in the fact that QGIS uses proj4 faromat-based, string-wise SRS matching.

Example:

EPSG:2180 has a following proj4 representation in QGIS srs.db:

+proj=tmerc +lat_0=0 +lon_0=19 +k=0.999300 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +units=m +no_defs

Against GDAL 1.4.4 QGIS fails to recognize this SRS because GDAL 1.4.4 inteprets EPSG:2180 as:

+proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +units=m +no_defs

Note the difference in k above - 0.999300 against 0.9993 is the cause of string-wise matching failure. The reason of this problem is a change in GDAL http://trac.osgeo.org/gdal/changeset/12625.

Against GDAL > 1.4.4 QGIS fails to recognize this SRS because these GDAL versions intepret EPSG:2180 as:

+proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993000000000001 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +units=m +no_defs

Again, k differ in both cases. This one is due to a bug in GDAL https://trac.osgeo.org/gdal/ticket/2036. It is fixed in GDAL 1.6 trunk but the fix caused side-effects, which have to be taken care of before the fix can be backported to stable 1.5 branch.

Other SRS which do not conatin an explicit k parameter, eg. EPSG:32633, which in proj4 representaion is:

+proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m +no_defs

do not pose problems.

Back to the point - if QGIS fails to recognize the SRS of the added layer, by default it assignes it:

+proj=longlat +ellps=WGS84 +datum=WGS84

Now, when one tries to reproject such layer on the fly, he might come to wrong conclussion that the functionality is broken. However, the real culprit is that the *layer's source SRS is wrong*, so the reprojection cannot work properly. Can you Leonardo and Paolo please verify if this is the case for you - that for Paolo the reprojection seems broken and for Leonardo it's OK?

comment:3 Changed 13 years ago by pcav

This may be related to locale: in LOCALE=it_IT, points are replaced with commas in the description of projections, thus qgis does not understand the projections, and grass plugin crashes. exporting LANG=C solves the problem. Apparently the same as https://trac.osgeo.org/qgis/ticket/1080

Changed 13 years ago by hamish

Attachment: qgis_fly_nodatum.png added

100m offset due to missing datum transform NZ Map Grid - LL WGS84

comment:4 Changed 13 years ago by hamish

From the above linked nabble archive thread:

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.

This bug has just been noticed on the grass-users list: http://thread.gmane.org/gmane.comp.gis.grass.user/23928/focus=23948

I notice with my pet projection (NZ Map Grid epsg:27200) that the datum transform is missing. (see screenshot attached to this bug; those are two GRASS vector layers loaded with the GRASS plugin and taken from both WGS84 LL and NZMG locations)

I am working with QGIS 0.8.1 for Debian/Etch? from backports.org package (latest build available so far). Proj 4.6.0 and GDAL 1.4.4.0 from backports.org too.

I notice that +datum=nzgd49 is missing from the srs.db version of the NZMG projection versus what is in the EPSG file. The above note from Frank explains that(?): there are typically 3 datum transform options used for NZMG- the 3 term, the 7 term, and a NTv2 grid file (grid file distributed with GRASS and PROJ.4).

I tried downloading the latest srs.db from SVN/trunk and replacing the one in /usr/share/qgis/resources/. No change.

I next opened up the new srs.db in sqlitebrowser and edited the entry* and added +towgs84=59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993 which is the standard 7-term transform used for +datum=nzgd49. No change. After that I also threw +datum=nzgd49 into the string with no change. The new terms shows up in the dialog if I go to the layer's "P"roperties projection info, but in the terminal I see:

Debug: /tmp/buildd/qgis-0.8.1/src/gui/qgsproject.cpp:1065 4 properties read
Debug: current properties:
Debug: name: properties
Debug:  key: <SpatialRefSys>  subkey: <SpatialRefSys>
Debug:          name: SpatialRefSys
Debug:                  key: <ProjectSRSProj4String>  value: +proj=nzmg +lat_0=-41 +lon_0=173 +x_0=2510000 +y_0=6023150 +ellps=intl +units=m +no_defs
Debug:                  key: <ProjectionsEnabled>  value: 1
Debug:                  key: <ProjectSRSID>  value: 1555
Debug:  key: <Gui>  subkey: <Gui>
...

ie the binary seems to be pulling the SRS data from somewhere else as well, and that somewhere else is not updated. And what is shown from srs.db is just cosmetic? (at least at runtime)

[*] sqlitebrowser edit: Browse Data tab; Table: tbl_srs; Go to: 1555; double click on parameters; Apply [] bonus: Firefox sqlite DB management GUI plugin:

https://addons.mozilla.org/en-US/firefox/addon/5817

It doesn't solve the general problem, but for NZMG I'd be happy with hardcoding the 7-term transform above until the general problem is solved. It isn't as good as using the grid file, but is a lot better than the current 100m+ shift. I can upload a new srs.db binary to someone with commit rights if it helps. (but is there more places to edit it?)

Plus if this gets fixed I can complain about ArcGIS 9.3's on the fly reprojection ignoring the datum transform again. I feel guilty about doing that while QGIS gets it wrong too. ;)

Hamish

comment:5 Changed 13 years ago by neteler

Cc: neteler added

comment:6 Changed 13 years ago by hamish

Keywords: srs.db datum added

see also bugs #1037 and #1035

comment:7 Changed 13 years ago by hamish

ok, the srs.db file is badly missing +datum= and +towgs84= parameters from many SRS codes. So anything that should do a datum transform won't. It should be regenerated from latest SVN GDAL+PROJ scripts + EPSG db IMO.

see new comments in bugs #1035 and #1037.

Hamish

comment:8 Changed 13 years ago by msieczka

Awaiting user input: set

Guys

An updated srs.db has been committed to SVN trunk. Please verify how the issues you mention in this discussion look now. Let me know if the ticket can be closed.

comment:9 Changed 13 years ago by timlinux

Resolution: fixed
Status: newclosed

Ticket closed as solution has been implemented by msieczka and rduif and is pending user feedback for almost a month. If the issue still exists please reopen and provide fresh info.

comment:10 Changed 13 years ago by leolami

Hi all, the problem seems solved, I tested using a projection like Gauss Boaga standard (EPSG code=3003)

+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl +units=m +no_defs

I try to reproject with a UTM wgs84 fuse 32N layer and it works well.

A little correlate problem is that if I load a layer from a Location of GRASS with this parameters of projection:

+proj=tmerc +lat_0=0 +lon_0=9 +k=0.999600 +x_0=1500000 +y_0=0 +ellps=intl +units=m +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68

when I look the projection associated to this layer I can see that QGIS doesn't know this projection and that it associates to the layer the projection setted as default.

But if I create a custom projection like this and I set it as the default projection when I load the GRASS layer I see that QGIS associates to the layer the standard projection:

+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs

but I remember that before QGIS readed the projection with parameters like the same projection withot them and it associated to the layer the standard Gauss Boaga projection (EPSG code=3003)

Do you think we have to reopen the ticket?

Thank you Leonardo

comment:11 in reply to:  10 ; Changed 13 years ago by neteler

Replying to leolami:

Hi all, the problem seems solved, I tested using a projection like Gauss Boaga standard (EPSG code=3003)

+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl +units=m +no_defs

Note that this string is incomplete. It lacks +towgs84=...

See also #377 and especially #418. The problem persists and needs to be solved.

Markus

comment:12 in reply to:  11 Changed 13 years ago by msieczka

Replying to leolami:

But if I create a custom projection like this and I set it as the default projection when I load the GRASS layer I see that QGIS associates to the layer the standard projection:

+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs

but I remember that before QGIS readed the projection with parameters like the same projection withot them and it associated to the layer the standard Gauss Boaga projection (EPSG code=3003)

Please post a sample GRASS location with a single layer for testing.

Maciek

comment:13 in reply to:  11 Changed 13 years ago by marcopx

Replying to neteler:

Replying to leolami:

Hi all, the problem seems solved, I tested using a projection like Gauss Boaga standard (EPSG code=3003)

+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl +units=m +no_defs

Note that this string is incomplete. It lacks +towgs84=...

See also #377 and especially #418. The problem persists and needs to be solved.

Markus

yes. when I work with GB projections in QGIS I define a custom projection. For example, for Gauss Boaga Roma40 West, peninsular part, I define:

+proj=tmerc +ellps=intl +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +no_defs +a=6378388 +rf=297 +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +to_meter=1

the epsg code 3003 is too generic for that purpose

Marco

Changed 13 years ago by leolami

Attachment: Gauss_Boaga.tar.gz added

Grass Location with towgs84 parameters

comment:14 Changed 13 years ago by leolami

Hi all, I posted a sample GRASS location with towgs84 parameters with a single layer for testing

comment:15 in reply to:  10 Changed 13 years ago by msieczka

Replying to leolami:

A little correlate problem is that if I load a layer from a Location of GRASS with this parameters of projection:

+proj=tmerc +lat_0=0 +lon_0=9 +k=0.999600 +x_0=1500000 +y_0=0 +ellps=intl +units=m +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68

when I look the projection associated to this layer I can see that QGIS doesn't know this projection and that it associates to the layer the projection setted as default.

But if I create a custom projection like this and I set it as the default projection when I load the GRASS layer I see that QGIS associates to the layer the standard projection:

+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs

but I remember that before QGIS readed the projection with parameters like the same projection withot them and it associated to the layer the standard Gauss Boaga projection (EPSG code=3003)

The problem is that QGIS produces an exact, particular proj4 string for your layer, and tries to find a match for it in it's CRS database. In order to let it find it, you need to define a custom CRS using a prj4 exactly the same QGIS qould be looking for.

You can find the string QGIS is looking for in it's terminal output when it's loading the layer. In your case the very string is:

+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +units=m +no_defs

The string *you* quoted is slightly different:

+proj=tmerc +lat_0=0 +lon_0=9 +k=0.999600 +x_0=1500000 +y_0=0 +ellps=intl +units=m +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68

i.e.: different order of parameters, trailing zeros in 'k', missing 'no_defs' - enough for QGIS to make it not recognize it.

As long as QGIS depends on string-wise proj4 definitions matching, we need to keep an eye on such subtle differences.

If you specify your custom CRS the way QGIS expects it, matching should work for you (it does for me).

Maciek

comment:16 Changed 13 years ago by neteler

Resolution: fixed
Status: closedreopened

I confirm that QGIS does not understand data in a GRASS location with towgs parameter:

Warning: QgsCoordinateReferenceSystem::getRecord failed :  select * from tbl_srs where 
parameters='+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl 
+towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +units=m +no_defs'

GRASS 6.4.svn (pat): > g.proj -w
PROJCS["Transverse Mercator",
    GEOGCS["international",
        DATUM["Monte_Mario",
            SPHEROID["International_1924",6378388,297],
            TOWGS84[-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",9],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",1500000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

g.proj -wf > /tmp/gb1.prj
testepsg /tmp/gb1.prj
Validate Succeeds.
WKT[/tmp/gb1.prj] =
PROJCS["Transverse Mercator",
    GEOGCS["international",
        DATUM["Monte_Mario",
            SPHEROID["International_1924",6378388,297],
            TOWGS84[-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",9],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",1500000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

Simplified WKT[/tmp/gb1.prj] =
PROJCS["Transverse Mercator",
    GEOGCS["international",
        DATUM["Monte_Mario",
            SPHEROID["International_1924",6378388,297],
            TOWGS84[-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",9],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",1500000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

Old Style WKT[/tmp/gb1.prj] = PROJCS["Transverse Mercator",GEOGCS["international",DATUM["Monte_Mario",
SPHEROID["International_1924",6378388,297]],PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],
PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",1500000],
PARAMETER["false_northing",0],UNIT["Meter",1]]

ESRI'ified WKT[/tmp/gb1.prj] =
PROJCS["Transverse Mercator",
    GEOGCS["international",
        DATUM["D_Monte_Mario",
            SPHEROID["International_1924",6378388,297]],
        PRIMEM["Greenwich",0],
        UNIT["Degree",0.017453292519943295]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",9],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",1500000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]
PROJ.4 rendering of [/tmp/gb1.prj] = +proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +units=m +no_defs

Since GDAL considers this projection valid, it must be a QGIS problem. I take liberty to reopen the ticket.

Markus

comment:17 Changed 13 years ago by homann

Aha, that explains that my custom projection with a towgs stopped working go the wrong resulta. Presumably the towgs options was ignored? I do not think this has anything to do with GDAL.

comment:18 Changed 13 years ago by neteler

Here another one (S-JTSK_Krovak):

Warning: QgsCoordinateReferenceSystem::getRecord failed : select * from tbl_srs where parameters='+proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813975277778 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +units=m +no_defs'

Not sure why it fails to be detected.

comment:19 in reply to:  16 ; Changed 13 years ago by msieczka

Replying to neteler:

I confirm that QGIS does not understand data in a GRASS location with towgs parameter:

Warning: QgsCoordinateReferenceSystem::getRecord failed :  select * from tbl_srs where 
parameters='+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl 
+towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +units=m +no_defs'
<snip>

QGIS doesn't recognize this CRS, because epsg_tr.py (a GDAL utility, used in the QGIS CRS database creation script) will not create an exactly the same string for any EPSG code. I checked that with all EPSG codes against my GDAL 1.5.2 instalation. Markus, what EPSG code is this proj4 string supposed to represent?

Since GDAL considers this projection valid, it must be a QGIS problem. I take liberty to reopen the ticket.

True, the CRS definition is valid, in general, according to testepsg (another GDAL utility), yet it is not an exact representation of any EPSG code according to GDAL, as checked with epsg_tr.py.

Looks like the bottom line of the problem is that QGIS uses an overly strict CRS matching. QGIS should support any CRS definition that GDAL considers valid, not only those which are exact equivalents of some EPSG codes.

QGIS devs - can it? The testepsg from GDAL seems to provide the required functionality.

comment:20 in reply to:  18 Changed 13 years ago by msieczka

Replying to neteler:

Here another one (S-JTSK_Krovak):

Warning: QgsCoordinateReferenceSystem::getRecord failed : select * from tbl_srs where parameters='+proj=krovak +lat_0=49.5 +lon_0=24.83333333333333 +alpha=30.28813975277778 +k=0.9999 > +x_0=0 +y_0=0 +ellps=bessel +units=m +no_defs'

Not sure why it fails to be detected.

For the same reason as explained in comment:19.

QGIS devs please tell what you think about the idea outlined in the last 2 paragraphs there.

comment:21 in reply to:  19 Changed 13 years ago by neteler

Replying to msieczka:

Replying to neteler:

I confirm that QGIS does not understand data in a GRASS location with towgs parameter:

Warning: QgsCoordinateReferenceSystem::getRecord failed :  select * from tbl_srs where 
parameters='+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl 
+towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +units=m +no_defs'
<snip>

QGIS doesn't recognize this CRS, because epsg_tr.py (a GDAL utility, used in the QGIS CRS database creation script) will not create an exactly the same string for any EPSG code. I checked that with all EPSG codes against my GDAL 1.5.2 instalation. Markus, what EPSG code is this proj4 string supposed to represent?

GRASS 6.4.svn (pat):~ > g.proj -j | tr '\n' ' ' +proj=tmerc +lat_0=0.0000000000 +lon_0=9.0 +k_0=0.9996000000 +x_0=1500000.0000000000 +a=6378388 +rf=297 +no_defs +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +to_meter=1

It is EPSG 3003 + towgs84 (since PROJ4's epsg file still omits towgs84 when multiple datums are available as in many European countries).

Since GDAL considers this projection valid, it must be a QGIS problem. I take liberty to reopen the ticket.

True, the CRS definition is valid, in general, according to testepsg (another GDAL utility), yet it is not an exact representation of any EPSG code according to GDAL, as checked with epsg_tr.py.

Looks like the bottom line of the problem is that QGIS uses an overly strict CRS matching. QGIS should support any CRS definition that GDAL considers valid, not only those which are exact equivalents of some EPSG codes.

Right. Currently it is a showstopper which renders QGIS' on the fly projection unusable as I cannot afford shifts of >100m just due to the omission of towgs84.

QGIS devs - can it? The testepsg from GDAL seems to provide the required functionality.

to compile that:

cd gdal/apps/
make testepsg

comment:22 Changed 12 years ago by homann

What is the status of this bug? Do we need to fix the CRS recognition logic yet?

comment:23 Changed 12 years ago by pcav

Still a serious bug: see also #377

comment:24 Changed 12 years ago by lutra

Milestone: Version 1.0.3Version 1.2.0

comment:25 Changed 12 years ago by pcav

Owner: changed from mhugent to timlinux
Status: reopenednew

comment:26 in reply to:  22 Changed 12 years ago by lutra

Replying to homann:

What is the status of this bug? Do we need to fix the CRS recognition logic yet?


Hi,

I don't know if someone else noticed, but the problems described in this ticket (together with #418) probably makes that the projections of the vectors in the qgis sample dataset are not recognized by qgis itself. This is very puzzling for new users.

I noticed also the following:

*) sample data is declared to be in epsg 2964

http://www.qgis.org/en/download/sample-data.html

but the string I see in the "general" tab after loading a vector, is different from the 2964 one in the qgis internal db.

*) When I try to select 2964 from the list of available projections, it doesn't changes and remain with the original string. This doesn't happens if I choose any other projection from the available list.

*) If I create a custom CRS with the string I see in the "general" tab, then it works and is recognized, but I have to take care to strip the blank space a the end of it, otherwise doesn't works.

comment:27 Changed 12 years ago by homann

Owner: changed from timlinux to homann
Status: newassigned

Pcav promised to attach a test case that I could use. Then I'll have a look. #418 is probably a fetaure extensions and text string change, so I don't think that will happen to 1.2.0.

If timlinux don't mind, I'll reassign it to myself. :-)

comment:28 in reply to:  27 Changed 12 years ago by lutra

Replying to homann:

Pcav promised to attach a test case that I could use.

I may be wrong, but the title of this ticket seems misleading to me. After all qgis do not fails to reproject, fails to recognize (and use?) the right projections. So if this is the case, no particular case is needed to test this behaviour. Just try the qgis sample dataset as I pointed in my previous comment.

comment:29 Changed 12 years ago by homann

I prefer that we keep only one issue per bug ticket, instead of adding everythinhg that seems wrong with projection to one ticket. This ticket has now become very confusing.

comment:30 Changed 12 years ago by homann

Resolution: fixed
Status: assignedclosed

Closing this, as it seems we have finally solved the issue. See #1875.

comment:31 Changed 12 years ago by hamish

see also comments in bugs #418, #1487, and #1875

Note: See TracTickets for help on using tickets.