> I imagine it's on some feature request/TODO.
Or maybe not.
Relevant reads:
https://nyalldawson.net/2016/08/how-to-effectively-get-things-changed-in-qgis/
http://nyalldawson.net/2016/08/how-to-effectively-get-things-changed-in-qgis-a-follow-up/
--
Spatialys - Geospatial professional services
Ah -- thanks for clarifying. GMLAS with some regexp worked to parse the GPX
metadata block. Would be interested in seeing metadata block implemented in
the GPX driver. I imagine it's on some feature request/TODO.
Thanks,
Gerard
On Tue, Nov 12, 2019 at 4:01 PM Even Rouault
wrote:
> On mardi 12
> I came across some strange behavior while panning around a VRT in QGIS. The
> VRT consists of several large overlapping TIFs where some TIFs have NODATA
> in areas where other TIFs have data. The behavior is hard to explain, but
> it looks like the data read from the files is corrupted. Panning
Paul,
Your issue might be one of scale. You have specified units in px try
changing it to pt. (units (g, px, pt, mm, cm, in))
See: https://gdal.org/user/ogr_feature_style.html#ogr-feature-style
You can also try named pens like:
Here is the current list of OGR pen ids (this could grow over
+1
Daniel
On 2019-11-13 09:22, Even Rouault wrote:
Hi,
I've updated both the RFC text and candidate implementation with the
provided comments, so I think we are now good to vote on it.
~~
Motion: adopt RFC 76 OGR Python drivers:
Hi,
I am not so worried. The alternative for people possibly interested in
building experimental Python drivers is not to make a new thoroughly tested
C++ plugin into GDAL core. Rather they will make experimental processes by
some other means. I am just discussing with someone who has made
On jeudi 14 novembre 2019 08:11:19 CET Howard Butler wrote:
> +0.
>
> I worry this will rot, and I worry people will start distributing drivers
> based on it and adding a lot of complexity for users. A note stating that
> the project is not going to distribute Python-based drivers as part of its
+0.
I worry this will rot, and I worry people will start distributing drivers
based on it and adding a lot of complexity for users. A note stating that
the project is not going to distribute Python-based drivers as part of its
baseline would make our intentions clear, but that isn't going to
Hey Even,
Actually a "simpler" solution for now for us is to remove the grid from the
docker image we use to run dataset tiling. This way, the projection follows
TOWGS84.
It's suboptimal in term of absolute accuracy of the tiles, but it gives us
consistency in our data which is more important to
Oh, I could gdalwarp the dataset myself to WGS84 and then tile it, so as to
consistently "ignore" grids.
That's an idea indeed.
Thanks for the pointer, I'll take it into consideration
---
Gregory Bataille
On Thu, Nov 14, 2019 at 12:46 PM Even Rouault
wrote:
> On jeudi 14 novembre 2019
On jeudi 14 novembre 2019 05:54:09 CET Grégory Bataille wrote:
> wow, thanks.
>
> I'm not quite sure I'm following it all though. I'm reaching a bit my
> knowledge limit here with those transforms. I'll need to spend a bit more
> time on it to get more understanding and see what I can do, how I
+1
Mateusz
Even Rouault-2 wrote
> Hi,
>
> I've updated both the RFC text and candidate implementation with the
> provided comments, so I think we are now good to vote on it.
>
> ~~
>
> Motion: adopt RFC 76 OGR Python drivers:
>
Even,
Great work, thank you so much!
+1
Raymond
On 13-11-19 15:22, Even Rouault wrote:
Hi,
I've updated both the RFC text and candidate implementation with the
provided comments, so I think we are now good to vote on it.
~~
Motion: adopt RFC 76 OGR Python drivers:
13 matches
Mail list logo
