[Qgis-developer] Unknown CRS problem

Marco Hugentobler marco.hugentobler at sourcepole.ch
Fri Jan 7 15:20:59 EST 2011


Hi Martin

> On-th-fly raster reprojection is not (IMHO) very expensive. The
> complexity depends on the desired output quality (e.g. what type of
> interpolation is used) and raster size. I would expect that most of
> the raster rendering time is fetching of source data, the warping
> itself is simple.

Afaik raster reprojection is very expensive (see e.g. 
http://mapserver.org/input/raster.html#raster-warping). And the 2-4 times is 
only with umn mapservers clever linearisation along scanlines. With a normal 
warp, it will be much more.

> > THird: Having OTF automatic still won't help users with data that lacks a
> > CRS.
> 
> No, but at least they can get a notification that a layer has unknown
> CRS and thus can be aligned incorrectly.

I'm concerned that such a warning could scare newbie users who don't know 
about spatial reference systems at all (and it will be one of the first things 
they see if the datasource crs is not recognized. This happens frequently if 
the data comes from a commercial GIS).

A very important use case here is people working with governemental data 
provided by the local GIS department. The GIS dep. provides everything in the 
same meter CRS and the normal user does not need to know about it, since 
everything overlays properly.


Regards,
Marco


Am Freitag, 7. Januar 2011, um 18.44:16 schrieb Martin Dobias:
> On Thu, Jan 6, 2011 at 7:57 PM, Micha Silver <micha at arava.co.il> wrote:
> >> I agree with you that CRS handling should be improved. Having
> >> 'unknown' CRS is more useful than assigning a bogus CRS and then
> >> trying to project it to some other CRS. I think we should remove
> >> on-the-fly projections option and _always_ do the reprojection of
> > 
> > Hmm.... Some thoughts:
> > Won't OTF projection of raster always be a heavy computational process,
> >  slowing down rendering?
> 
> On-th-fly raster reprojection is not (IMHO) very expensive. The
> complexity depends on the desired output quality (e.g. what type of
> interpolation is used) and raster size. I would expect that most of
> the raster rendering time is fetching of source data, the warping
> itself is simple.
> 
> I thought also about adding some kind of unobtrusive feedback from map
> canvas indicating possible problems - similar to how browsers nowadays
> complain about missing plugin or ask whether to save password. This
> feedback could include both errors (e.g. failed to reproject some
> parts of layer) and warnings/suggestions (e.g. raster rendering is
> slow due missing pyramids, layer has unknown CRS). QGIS could also
> suggest the user to reproject his rasters/vectors for faster
> rendering.
> 
> > Second: To which CRS will this automatic OTF reproject to? The situation
> > now is that a new project always starts in EPSG:4326. There's no way
> > AFAIK to cause QGIS to always start in some user chosen CRS (other than
> > creating a default project in your chosen CRS, then change the QGIS
> > shortcut to always start that project.)
> > Suppose I have some big LandSAT rasters in UTM, and vector layers in some
> > other projection. If OTF was always "on" I'd be reprojecting both the
> > LandSAT and all the vectors into Lon/Lat WGS84.
> 
> I think it's reasonable to start new project with unknown CRS by
> default and set CRS from the first loaded layer. Of course an option
> to override the default project CRS would be convenient for some
> people working mostly with one CRS.
> 
> > THird: Having OTF automatic still won't help users with data that lacks a
> > CRS.
> 
> No, but at least they can get a notification that a layer has unknown
> CRS and thus can be aligned incorrectly.
> 
> Regards
> Martin
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
Dr. Marco Hugentobler
Sourcepole - Linux & Open Source Solutions
Churerstr. 22, CH-8808 Pfäffikon SZ, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee


More information about the Qgis-developer mailing list