[Qgis-developer] Processing params always n meters?

Mark Johnson mj10777 at googlemail.com
Sun Mar 5 02:07:43 PST 2017


Yes, this is a problem I noticed when experimenting with styles for the
version of the georeferencer I am working on.

The goal was to to show a circle of 1 meter around a point
- thus 2 Map-Units

Changing the MapCanvas to a non-metric Unit showed that these was no
dynamic 'switching' being done based on the srid being used.

 I worked out a Spatialite specific solution for this
- retrieving the srid being used by the MapCanvas and extracting the needed
information:

SELECT SridIsGeographic(%1), SridGetUnit(%1)
- found return if degrees and what type (meters,degrees, foot, yard,
chain,link and fathom [international, us, indian])

In the case of degrees, extra work must be done (as mentioned in the
previous post)
- using the center of the MapCanvas extent, calculate the length of a line
for a given meter value [using 1]:

SELECT  ST_Length
(
 MakeLine
 (
  MakePoint(13.3934162138589,52.51751576264239,4326),
  ST_Project
  (
   MakePoint(13.3934162138589,52.51751576264239,4326),1,PI()/2
  )
 )
):

Returns 0.000015 for the above point (in Berlin)
or 0.000009 for Greenwich/Equator.

This value would (for degrees) have to be recalculated each time the
extent/center of MapCanvas has changed.

The when a gui using a MapUnit be being rendered
- it would retrieved this value, multiply by the meter value set and use
the result when rendering.

----
For QGIS 3.0, I believe, implementing such a solution would be a good idea.

Inside a MapCavas, when the srid is set (or changed)
- which srid as number (different deggres type bring different results)
- what type of Unit is it
-- here srs.db could contain the basic values of 1 meter for
--> foot, yard, chain,link and fathom [international, us, indian]
- when degrees, recalculating the value upon extent change

When rendering using MapUnit
- retrieve the 1 meter value
- multiply by the meter value set in the MapUnit property and use that
result

This would be an API break that should be done now.

Mark Johnson, Berlin Germany
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170305/719be768/attachment.html>


More information about the Qgis-developer mailing list