Plugin PDOK BAG Geocoder approval by lytrix.
The plugin version "[324] PDOK BAG Geocoder 0.2 Experimental" is now unapproved
Link: http://plugins.qgis.org/plugins/pdokbaggeocoder/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://list
Plugin PDOK BAG Geocoder approval by lytrix.
The plugin version "[324] PDOK BAG Geocoder 0.3 Experimental" is now unapproved
Link: http://plugins.qgis.org/plugins/pdokbaggeocoder/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://list
Hi Steven,
just having a quick look at the data you provided:
- your Munros.shp doesn't have 27700 projection, but some user defined and
only becomes visible when setting to 27700 manually.
- the geojson and the shape file have quite some offset. (75 whatsoevers,
meteres, miles ??)
Apart fr
Thanks for the explanation Martin! I hope here is a way to have
consistency again without necessarily breaking working code.
@Victor: A few comments in the example scripts explaining the issue would
already help a lot I think.
Best wishes,
Anita
Am 19.10.2013, 19:54 Uhr, schrieb Victor Ol
Hi,
Currently we have:
QgsVectorLayer:
* geometryType() returns QGIS geometry type (coarse)
* wkbType() returns WKB type (fine)
QgsVectorDataProvider:
* geometryType() returns WKB type (fine)
Unfortunate indeed.
To not break existing code, a new method geomType() could be
introduced, which
I wasn't aware of that difference that Martin mentions. I guess that,
from the Processing side, the only thing to do is to document clearly
which find of enumeration value is expected, and also how to convert
it in case you have a value corresponding to the other enumeration. I
will try to add that
Hi Anita
looking into the code... the unintuitive part is that these
geometryType() methods return values from different enumerations:
- provider's geometryType() returns value from WKBType enumeration
- layer's geometryType() returns value from GeometryType enumeration
(translated from provider's
Hi Victor,
I've been porting one of my scripts to the new Processing. Everything
seems fine but I'm confused about one issue:
It seems like almost everything can be accessed via the layer now, e.g.
crs(), pendingFields(), etc. However, if I try to use layer.geometryType()
in the VectorWrite
>
> Why not reusing existing SEXTANTE page at plugin website? Maybe
> it is possible to rename it and use for publishing Processing packages?
> If this does not violate plugin site and project policy, maybe Nathan or
> Alessandro can do this (I mean renaming) for us.
I would remove the SEXTANTE pl
2013/10/19 Victor Olaya :
> Regarding releasing a new version, I actually do not know how to do
> it, considering that there is not Processign plugin page, so I cannot
> publish the zip file using the web interface. However, if you Paolo,
> or Alex, want to publish it, I definitely like the idea. W
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 19/10/2013 12:49, Alexander Bruy ha scritto:
>> http://hub.qgis.org/issues/8916
>
> Fixed
thanks a lot
> Try with gdalinfo tool, if raster has projection, this tool will show
You are right:
Coordinate System is:
LOCAL_CS["unnamed",
UNIT["u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 19/10/2013 12:21, Victor Olaya ha scritto:
> You are both wrong :-)
much better then"
> I propose to tag versions using the current QGIS version and an extra
> number, so now we will do 2.0.1.2, then 2.0.1.3and once QGIS 2.0.2
> is out, we mo
2013/10/19 Paolo Cavallini :
>> 2013/10/17 Paolo Cavallini :
>>> * no feedback is given upon completion ("World file written")
>> Agreed, feedback about process completion will be good.
>
> http://hub.qgis.org/issues/8916
Fixed
>>> * the prj is (optionally) created according to the project settin
>>> * the Field calculator is barely usable without a dropdown list of fields
>>> and
>>> functions; on win it does not seem to work (most or all calculations end up
>>> with all
>>> NULLs); unclear if this is due to minor edit issues from users (quite
>>> likely without
>>> the dropdowns)
>> Ma
On Sat, Oct 19, 2013 at 07:55:36AM +0200, Paolo Cavallini wrote:
> ok - should I open tickets then, not to forget for future implementation?
I think it would be useful to open a ticket for each and specify
2.0.2 as the target version of those which are clearly bugs and known
to be fixable in a sa
15 matches
Mail list logo
