Re: [Qgis-developer] QGIS 3.0: Plans to support librttopo?

[Nyall Dawson]

On 7 March 2017 at 16:31, Mark Johnson  wrote:
>>> I'm confused - what is missing?
>
> The topic here is that when using MapUnits
> - where the MapUnits are degrees
> that a constant value (valid around the world) is not possible.
>
> If you set this to 5 (intended as meters on the map)
> - the further you zoom in, the circle will get bigger always showing an area
> of 5 meters
>
> If the Map is switched to WSG84
> - then you will get 5 degrees and not the desired area of 5 meters
> --> which for my area would be 0.75, at the equator 0,45 and in you
> area something different
>
> Since the source and destination crs are unknown when this attribute value
> is being set
> - one cannot assume that one or the other use meters and therefore cannot be
> used

It might be unknown at the time of setting that value - but it's
certainly known at the time that
QgsRenderContext::convertToPainterUnits or similar is called!

So you add a new QgsUnitTypes::RenderUnit enum value for
MapUnitMeters, and then if that unit is encountered by
QgsRenderContext::convertToPainterUnits you could do the calculation
from metres -> real map units -> painter units then. (The conversion
value could be cached in the render context to avoid multiple
coordinate transforms)

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0: Plans to support librttopo?

[Mark Johnson]

>> I'm confused - what is missing?

The topic here is that when using MapUnits
- where the MapUnits are degrees
that a constant value (valid around the world) is not possible.

If you set this to 5 (intended as meters on the map)
- the further you zoom in, the circle will get bigger always showing an
area of 5 meters

If the Map is switched to WSG84
- then you will get 5 degrees and not the desired area of 5 meters
--> which for my area would be 0.75, at the equator 0,45 and in you
area something different

Since the source and destination crs are unknown when this attribute value
is being set
- one cannot assume that one or the other use meters and therefore cannot
be used

Mark
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0: Plans to support librttopo?

[Nyall Dawson]

On 7 March 2017 at 15:37, Mark Johnson  wrote:
>>> Everything you need should already be encapsulated in QgsRenderContext
>>> (and the QgsMapToPixel member).
>
> For everything but degrees it is.
> But in the case of degrees is is not
> - there the (incorrect) assumption is being made that the world is flat
> The value being used for DEGREE_TO_METER 111319.49079327358
> - is only valid on the Equator
> In my area a degree is around 6,7 meters
> - and this is the value needed
>
>>> This shouldn't be implemented using an external dependency
> I understand the reluctance to adding a further dependency, but GEOS is also
> used
> - and librttopo is an extension of GEOS
>
> Unfortunately there are not many degree based functions that allows the
> combination with a distance as meters.

I'm confused - what is missing? You have the extent, map scale, and
source and destination crs with their corresponding map units. What
more is needed?

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0: Plans to support librttopo?

[Mark Johnson]

>> Everything you need should already be encapsulated in QgsRenderContext
>> (and the QgsMapToPixel member).

For everything but degrees it is.
But in the case of degrees is is not
- there the (incorrect) assumption is being made that the world is flat
The value being used for DEGREE_TO_METER 111319.49079327358
- is only valid on the Equator
In my area a degree is around 6,7 meters
- and this is the value needed

>> This shouldn't be implemented using an external dependency
I understand the reluctance to adding a further dependency, but GEOS is
also used
- and librttopo is an extension of GEOS

Unfortunately there are not many degree based functions that allows the
combination with a distance as meters.

---
Looking at the code yesterday, the following could be a realistic
possiblity to implement this:

QgsMapRenderer:
- add double mMeterAsMapUnit [default 1.0 for meters distance unit]
QgsMapRenderer::setDestinationCrs
// before setExtent is called:
 
mMeterAsMapUnit=QgsUnitTypes::fromUnitToUnitFactor(QGis::Meters,crs.mapUnits());
mRenderContext.setMeterAsMapUnit( mMeterAsMapUnit ) ;

QgsMapRenderer::setExtent

  if ( mSettings.destinationCrs().isGeographic() )
  { // Retrieve realistic MapUnits for a meter based on result of
QgsMapCanvas::center()
   // meterAsMapUnit=
  }

QgsRenderContext
add:
/** 1 meter in Map-Unit*/
double mMeterAsMapUnit;
void setMeterAsMapUnit( double meterAsMapUnit ) {mMeterAsMapUnit =
meterAsMapUnit;}
double meterAsMapUnit() const {return mMeterAsMapUnit;}

QgsSymbolLayerV2Utils::convertToMapUnits:

  switch ( unit )
  {
case QgsSymbolV2::MetersUnit:
{ // Note: must fall through to QgsSymbolV2::MapUnit
 size=size*c.meterAsMapUnit();
}
case QgsSymbolV2::MapUnit:

I will try this out and see if it brings a reasonable result.

Mark Johnson, Berlin Germany
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0: Plans to support librttopo?

[Nyall Dawson]

On 6 March 2017 at 23:45, Mark Johnson  wrote:
> The spatialite function 'ST_Project' is based on the librttopo functionality
> (formally LWGEOM)
> - and is only available when compiled with '--enable-rttopo'
>
> https://git.osgeo.org/gogs/rttopo/librttopo
>
> So if a support for 'Meters as Map units' was desired, in the case of
> degrees
> - the use the librttopo functionality as a part of the 'QgsGeos' would be
> the most effective way to deal with this
>
> This would be a new dependency, but would also offer many other
> functionalities (such as Topology).

Hi Mark,

This shouldn't be implemented using an external dependency -- instead
you'll need to use the existing QGIS classes like
QgsCoordinateTransform. You'd just need to modify:

QgsRenderContext::convertToPainterUnits
QgsRenderContext::convertToMapUnits
QgsRenderContext::convertFromMapUnits

Everything you need should already be encapsulated in QgsRenderContext
(and the QgsMapToPixel member).

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QGIS 3.0: Plans to support librttopo?

[Mark Johnson]

The spatialite function 'ST_Project' is based on the librttopo functionality
(formally LWGEOM)
- and is only available when compiled with '--enable-rttopo'

https://git.osgeo.org/gogs/rttopo/librttopo

So if a support for 'Meters as Map units' was desired, in the case of
degrees
- the use the librttopo functionality as a part of the 'QgsGeos' would be
the most effective way to deal with this

This would be a new dependency, but would also offer many other
functionalities (such as Topology).

Mark Johnson, Berlin Germany
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer