Re: [Qgis-user] [osgeo4w-dev] QGIS 3.18.0 and QGIS 3.14.4 (LTR) packages released and OSGeo4W reboot
Hi Jürgen! Thanks for all that great work! Are there any instructions on how to use the scripts to build the packages? Did you consider building a python gdal/proj package that could be installed on the normal python distribution as well as on OSGeo4W? Idan On Tue, 23 Feb 2021, 18:36 Jürgen E. Fischer, wrote: > Hi there, > > I'm happy to announce that the QGIS packages of 3.16.4 (LTR) 'Hannover' > and the > our latest release 3.18.0 'Zürich' are ready on > https://qgis.org/de/site/forusers/download.html. This includes Linux, > Mac and > Windows packages. With the availability of a new regular release the > current > long-term release 3.16 replaces the previous long-term release 3.10 in the > long > term package repositories. > > The Windows standalone installer are as usual made from the OSGeo4W > packages. > > In OSGeo4W there has lately been a big effort to reboot it, meaning that > it has > been completely rebuilt using newer source versions of mostly every > package > using a newer compiler. As this happened shortly before the QGIS release > the > new packages are still in a separate repository for testing. > > You can install them using the osgeo4w installer on > http://download.osgeo.org/osgeo4w/testing/osgeo4w-setup.exe (note the > testing - > the old installer will also work, if you point it to the new site, but it > will > default to the old). > > Within the reboot a lot of old packages were dropped (including > dependencies to > old microsoft runtimes), new packages were introduced and also package > names > were revised. > > Long story short: you cannot upgrade from old installs and have to remove > and > reinstall or use a separate directory. As the new OSGeo4W only supports > 64bit > the default root directory was changed to C:\OSGeo4W, which might help with > that if you were on 64bit earlier. > > Also note that it now only has one version of Python - namely 3.9, which > doesn't support Windows 7 anymore. Other updates include Qt 5.15, GDAL > 3.2, > PROJ 7.2 and SAGA 7.8. > > It also has PDAL 2.2 which is required for native support of point clouds > in > QGIS - something that you find lacking in the "old" OSGeo4W repository and > in > turn in the current standalones. > > The new installer also doesn't require administrator privileges anymore. > Unless you run it elevated (ie. as Administrator) the option to create > shortcuts for all users will be unavailable. > > The testing repository will eventually replace the old repository and also > be > used to make standalone installers. As it has grown to exceed the 2GB > limit > of NSIS the standalone installers will then be switched to MSI. > > The package recipes currently reside at https://github.com/jef-n/OSGeo4W. > > Please test and report packaging issues to the OSGeo4W TRAC at > https://trac.osgeo.org/osgeo4w. > > > > Jürgen > > -- > Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 > Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 > Software Engineer D-26506 Norden > https://www.norbit.de > QGIS release manager (PSC) GermanyIRC: jef on FreeNode > ___ > osgeo4w-dev mailing list > osgeo4w-...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/osgeo4w-dev > ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Does QGIS3 freezes more often than QGIS2 ?
Hi David and Kirk, Thanks for your replies! I usually drag and drop Cloud Optimized Geotiffs, so I don't think that the size of the raster is the root of the problem. I had these freezes also when just setting the focus back on QGIS (alt+tab) without drag/drop anything. I've just applied David's suggestion and hid all local drives and network drives from the Browser (I've never even used those anyway). Then I dragged and dropped some 30 large COG rasters and so far no more freezes :) I'll report again in a few days and open a bug report if that was indeed the root of the problem. Idan On Fri, 27 Nov 2020 at 17:41, David Addy wrote: > I used to get a lot of similar freezes on QGIS 3. > It was traced to the browser window being full of files that I never would > use for QGIS. > So if your browser window within QGIS has a lot of irrelevant stuff, you > could try clicking on each one and selecting, "Hide from Browser" option. > This should ensure that QGIS is not wasting time looking through a lot of > directories that you would never be using with QGIS anyway. > > > > -- > Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-User-f4125267.html > ___ > Qgis-user mailing list > Qgis-user@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user > ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
[Qgis-user] Does QGIS3 freezes more often than QGIS2 ?
Hi, I was wondering if I'm the only one who experiences sudden freezes in QGIS3 (on Win10x64) It's hard to pinpoint exactly what triggers these freezes but usually it happens more often when I drag and drop raster files from the file explorer onto the QGIS canvas. Usually after a few seconds it unfreezes and I can continue my work, otherwise I just force close and reopen QGIS. This almost never happens to me with QGIS 2.17 and keeps happening on every QGIS3 version I tested (including the latest). Is there any easy way to debug this? Idan ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Vector with more than xyzm
Thanks for all your replies! On Wed, 7 Nov 2018 at 10:01, Matthias Kuhn wrote: > The closest you can get using a single table is using array typed fields, > but beware of editing data, nothing will prevent you from corrupting the > data and having geometry and attributes out of sync. > > Other approaches are having a separate point layer with the vertices > duplicated or a linear referencing table. > > Cheers > > Matthias > On 11/7/18 5:34 AM, Idan Miara wrote: > > Hi, > Thanks for your response! > Please note that the extra info is per vertex and the features are > multipolylines for instance. Think a file of airplane paths, so you have 6 > dims per vertex and some attributes per path feature. > > On Wed, 7 Nov 2018, 05:34 Nicolas Cadieux wrote: > >> Hi, >> >> Well I believe the simple .csv file is not the fastest but will give you >> the most flexibility if you have a massive amount of data. I have been >> working with hyper spectral cloud data. >> >> Nicolas >> >> > Le 6 nov. 2018 à 21:09, Alex Mandel a >> écrit : >> > >> >> On 11/6/18 12:54, Idan Miara wrote: >> >> Hi, >> >> >> >> What would be the OGR or the portable way for handling vector data with >> >> more than 4 dimensions? >> >> i.e. xyz+time+velocity+acceleration for each vertex. >> >> >> >> Kind regards, >> >> Idan >> >> >> >> >> > >> > Attribute tables. Make XYZ geometries and put all your other stuff into >> > attributes. >> > >> > Enjoy, >> > Alex >> > ___ >> > Qgis-user mailing list >> > Qgis-user@lists.osgeo.org >> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user >> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user >> > > ___ > Qgis-user mailing listqgis-u...@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user > > -- > Matthias Kuhn > matth...@opengis.ch > +41 (0)76 435 67 63 <+41764356763> > [image: OPENGIS.ch Logo] <http://www.opengis.ch> > ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Vector with more than xyzm
Hi, Thanks for your response! Please note that the extra info is per vertex and the features are multipolylines for instance. Think a file of airplane paths, so you have 6 dims per vertex and some attributes per path feature. On Wed, 7 Nov 2018, 05:34 Nicolas Cadieux Hi, > > Well I believe the simple .csv file is not the fastest but will give you > the most flexibility if you have a massive amount of data. I have been > working with hyper spectral cloud data. > > Nicolas > > > Le 6 nov. 2018 à 21:09, Alex Mandel a > écrit : > > > >> On 11/6/18 12:54, Idan Miara wrote: > >> Hi, > >> > >> What would be the OGR or the portable way for handling vector data with > >> more than 4 dimensions? > >> i.e. xyz+time+velocity+acceleration for each vertex. > >> > >> Kind regards, > >> Idan > >> > >> > > > > Attribute tables. Make XYZ geometries and put all your other stuff into > > attributes. > > > > Enjoy, > > Alex > > ___ > > Qgis-user mailing list > > Qgis-user@lists.osgeo.org > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user > ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
[Qgis-user] Vector with more than xyzm
Hi, What would be the OGR or the portable way for handling vector data with more than 4 dimensions? i.e. xyz+time+velocity+acceleration for each vertex. Kind regards, Idan ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Pseudo Mercator(OSM) @ EPSG:4326 bug?
Ok, Thanks for your detailed explanation!
On 5 Mar 2018 15:41, "Kristian Evers" wrote:
It would be nice if the Web Mercator was never introduced to the EPSG
register,
but nothing we can do about that now. The problem has indeed seeped into
PROJ by mistake (will be fixed with 5.0.1). Unfortunately the internal
architecture
in PROJ makes it quite hard to handle both the Web Mercator and treat other
(not so common) transformations with a shift in ellipsoid correctly. Luckily
this is only a problem in the old API. The new API introduced in 5.0.0 is
more
flexible and can handle both correctly. It will be a while before that is
easily
available for downstream projects such as QGIS.
/Kristian
-Oprindelig meddelelse-
Fra: Qgis-user [mailto:qgis-user-boun...@lists.osgeo.org] På vegne af
Benjamin Ducke
Sendt: 5. marts 2018 11:58
Til: qgis-user
Emne: Re: [Qgis-user] Pseudo Mercator(OSM) @ EPSG:4326 bug?
It all boils down to the same fundamental issue:
Google Earth/Maps, etc. _pretend_ that their data
is WGS84, but they do not implement the WGS84
ellipsoid. So when tools like PROJ attempt to
do the _technically correct_ thing and perform
a datum transformation WGS84 <-> Web Mercator, then
data ends up in the wrong place. If they don't,
then people get confused, because the two systems
are different. This confusion is now seeping into
PROJ and from there into higher-level apps like
QGIS. I wish EPSG had never included Web Mercator into
its database. Then we could just ignore all of this,
use EPSG:4326 and live in blissful ignorance.
On 05/03/18 11:42, Idan Miara wrote:
> Thanks for you reply,
> Since the problem exist also in 2.18 I don't think it is related with
> PROJ 5.0, Right?
>
> On 5 Mar 2018 12:39, "Kristian Evers" <mailto:kr...@sdfe.dk>> wrote:
>
> If you are using PROJ 5.0.0 it is likely to be caused by this known
> issue:
>
> https://github.com/OSGeo/proj.4/issues/834
> <https://github.com/OSGeo/proj.4/issues/834>
>
> /Kristian
>
> -Oprindelig meddelelse-
> Fra: Qgis-user [mailto:qgis-user-boun...@lists.osgeo.org
> <mailto:qgis-user-boun...@lists.osgeo.org>] På vegne af Benjamin Ducke
> Sendt: 5. marts 2018 10:18
> Til: qgis-user@lists.osgeo.org <mailto:qgis-user@lists.osgeo.org>
> Emne: Re: [Qgis-user] Pseudo Mercator(OSM) @ EPSG:4326 bug?
>
> Could it be this:
>
> http://proj4.org/faq.html#changing-ellipsoid-why-can-t-
i-convert-from-wgs84-to-google-earth-virtual-globe-mercator
> <http://proj4.org/faq.html#changing-ellipsoid-why-can-t-
i-convert-from-wgs84-to-google-earth-virtual-globe-mercator>
>
> ?
>
> The further you get from the equator, the more
> obvious the discrepancy on the Y axis.
>
> Best,
>
> Ben
>
> On 05/03/18 09:38, Idan Miara wrote:
> > Hi,
> >
> > I might have found a bug related to transformation of layer CRS
> > from EPSG:3857 (Pseudo Mercator) to EPSG:4325 (WGS84 Geo).
> > I'm attaching a few images to demonstrate the issue.
> >
> > Steps to reproduce:
> > I've load OSM in QGIS 2.18.16 (or 3.0,same results)
> > via Tile Server (XYZ):
> > https://a.tile.openstreetmap.org/{z}/{x}/{y}.png
> <https://a.tile.openstreetmap.org/{z}/{x}/{y}.png>
> > <https://a.tile.openstreetmap.org/%7Bz%7D/%7Bx%7D/%7By%7D.png
> <https://a.tile.openstreetmap.org/%7Bz%7D/%7Bx%7D/%7By%7D.png>>
> >
> > Then set the CRS to EPSG:4326 (WGS84 Geo)
> >
> > I've also loaded a global bounds vector layer (EPSG:4326)
> >
> > In scale 1:100,000,000 it seems that the Pseudo Mercator
> transformation
> > to 4326 is flawed, as the OSM and the vectors are not aligned.
> > In scale 1:50,000,000 it seems OK when the extent is the middle of
the
> > map, but if I pan to the south/north it seems distorted again.
> >
> > If I set the project CRS to EPSG:3857 (Pseudo Mercator) as the CRS
of
> > the OSM tiles, so the vector layer would be transformed instead,
then
> > they do align in all scales (picture with the blue vector layer).
> >
> > It doesn't look like a problem of precision of the transformation
from
> > 3857 to 4325 because it's way off.
> > Is that a bug or am I missing something here?
> >
> > Kind regards,
> > Idan.
> >
> >
> >
> > ___
> > Qgis-user mailing list
> > Qgis-user@lists.osgeo.org <mailto:Qgis-user@lists.osgeo.org>
> > List info: https://lists.os
Re: [Qgis-user] Pseudo Mercator(OSM) @ EPSG:4326 bug?
It does, but the problem is when I set the project CRS to 4326, so the
tiles are projected from 3857 to 4326. The vector layer is not projected.
On 5 Mar 2018 13:23, "Andre Joost" wrote:
Am 05.03.18 um 09:38 schrieb Idan Miara:
Hi,
>
> I might have found a bug related to transformation of layer CRS from
> EPSG:3857
> (Pseudo Mercator) to EPSG:4325 (WGS84 Geo).
> I'm attaching a few images to demonstrate the issue.
>
> Steps to reproduce:
> I've load OSM in QGIS 2.18.16 (or 3.0,same results)
> via Tile Server (XYZ):
> https://a.tile.openstreetmap.org/{z}/{x}/{y}.png
>
> Then set the CRS to EPSG:4326 (WGS84 Geo)
>
> I've also loaded a global bounds vector layer (EPSG:4326)
>
>
Does the vector layer contain the north or south pole? EPSG:3857 does not
like that (it would be in infinity). The same might happen if you request
tiles beyond 85°N/S.
HTH,
Andre Joost
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Pseudo Mercator(OSM) @ EPSG:4326 bug?
Forgive me for not understanding the fine details of the flaws in Web
Mercator.
Fast forward back the reality where many tile servers provide tiles in
3857, and 4326 to 3857 seems OK, how can I debug this issue in the inverse
transformation?
I guess I could export the OSM map in 3857 to TIF to rule out the
possibility that the problem in the tile server, so that I can be sure that
QGIS is transforming the raster?
On 5 Mar 2018 12:57, "Benjamin Ducke" wrote:
It all boils down to the same fundamental issue:
Google Earth/Maps, etc. _pretend_ that their data
is WGS84, but they do not implement the WGS84
ellipsoid. So when tools like PROJ attempt to
do the _technically correct_ thing and perform
a datum transformation WGS84 <-> Web Mercator, then
data ends up in the wrong place. If they don't,
then people get confused, because the two systems
are different. This confusion is now seeping into
PROJ and from there into higher-level apps like
QGIS. I wish EPSG had never included Web Mercator into
its database. Then we could just ignore all of this,
use EPSG:4326 and live in blissful ignorance.
On 05/03/18 11:42, Idan Miara wrote:
> Thanks for you reply,
> Since the problem exist also in 2.18 I don't think it is related with
> PROJ 5.0, Right?
>
> On 5 Mar 2018 12:39, "Kristian Evers" <mailto:kr...@sdfe.dk>> wrote:
>
> If you are using PROJ 5.0.0 it is likely to be caused by this known
> issue:
>
> https://github.com/OSGeo/proj.4/issues/834
> <https://github.com/OSGeo/proj.4/issues/834>
>
> /Kristian
>
> -Oprindelig meddelelse-
> Fra: Qgis-user [mailto:qgis-user-boun...@lists.osgeo.org
> <mailto:qgis-user-boun...@lists.osgeo.org>] På vegne af Benjamin Ducke
> Sendt: 5. marts 2018 10:18
> Til: qgis-user@lists.osgeo.org <mailto:qgis-user@lists.osgeo.org>
> Emne: Re: [Qgis-user] Pseudo Mercator(OSM) @ EPSG:4326 bug?
>
> Could it be this:
>
> http://proj4.org/faq.html#changing-ellipsoid-why-can-t-
i-convert-from-wgs84-to-google-earth-virtual-globe-mercator
> <http://proj4.org/faq.html#changing-ellipsoid-why-can-t-
i-convert-from-wgs84-to-google-earth-virtual-globe-mercator>
>
> ?
>
> The further you get from the equator, the more
> obvious the discrepancy on the Y axis.
>
> Best,
>
> Ben
>
> On 05/03/18 09:38, Idan Miara wrote:
> > Hi,
> >
> > I might have found a bug related to transformation of layer CRS
> > from EPSG:3857 (Pseudo Mercator) to EPSG:4325 (WGS84 Geo).
> > I'm attaching a few images to demonstrate the issue.
> >
> > Steps to reproduce:
> > I've load OSM in QGIS 2.18.16 (or 3.0,same results)
> > via Tile Server (XYZ):
> > https://a.tile.openstreetmap.org/{z}/{x}/{y}.png
> <https://a.tile.openstreetmap.org/{z}/{x}/{y}.png>
> > <https://a.tile.openstreetmap.org/%7Bz%7D/%7Bx%7D/%7By%7D.png
> <https://a.tile.openstreetmap.org/%7Bz%7D/%7Bx%7D/%7By%7D.png>>
> >
> > Then set the CRS to EPSG:4326 (WGS84 Geo)
> >
> > I've also loaded a global bounds vector layer (EPSG:4326)
> >
> > In scale 1:100,000,000 it seems that the Pseudo Mercator
> transformation
> > to 4326 is flawed, as the OSM and the vectors are not aligned.
> > In scale 1:50,000,000 it seems OK when the extent is the middle of
the
> > map, but if I pan to the south/north it seems distorted again.
> >
> > If I set the project CRS to EPSG:3857 (Pseudo Mercator) as the CRS
of
> > the OSM tiles, so the vector layer would be transformed instead,
then
> > they do align in all scales (picture with the blue vector layer).
> >
> > It doesn't look like a problem of precision of the transformation
from
> > 3857 to 4325 because it's way off.
> > Is that a bug or am I missing something here?
> >
> > Kind regards,
> > Idan.
> >
> >
> >
> > ___
> > Qgis-user mailing list
> > Qgis-user@lists.osgeo.org <mailto:Qgis-user@lists.osgeo.org>
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> <https://lists.osgeo.org/mailman/listinfo/qgis-user>
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
> <https://lists.osgeo.org/mailman/listinfo/qgis-user>
> >
>
>
>
> --
> Dr. Benjamin Ducke
> Deutsches Archäologisches Institut (DAI)
> Zentrale Berlin, IT-Referat
> * Projekt "Stunde Null" *
>
Re: [Qgis-user] Pseudo Mercator(OSM) @ EPSG:4326 bug?
Thanks for your reply,
How can I check if QGIS is applying the transformation or if it asks the
service to provide the tiles in 4326?
On 5 Mar 2018 11:17, wrote:
> Most likely the service you are using is only able to provide its maptiles
> in 3857 and does not respond to the QGIS request to provide them in 4326
> (or responds, but incorrectly)...
>
>
>
>
>
> --
>
> Barend Köbben
>
>
>
> On 05/03/2018, 09:39, "Qgis-user on behalf of Idan Miara" <
> qgis-user-boun...@lists.osgeo.org on behalf of i...@miara.com> wrote:
>
>
>
> Hi,
>
>
>
> I might have found a bug related to transformation of layer CRS from EPSG:3857
> (Pseudo Mercator) to EPSG:4325 (WGS84 Geo).
>
> I'm attaching a few images to demonstrate the issue.
>
>
>
> Steps to reproduce:
>
> I've load OSM in QGIS 2.18.16 (or 3.0,same results)
>
> via Tile Server (XYZ):
>
> https://a.tile.openstreetmap.org/{z}/{x}/{y}.png
>
>
>
> Then set the CRS to EPSG:4326 (WGS84 Geo)
>
>
>
> I've also loaded a global bounds vector layer (EPSG:4326)
>
>
>
> In scale 1:100,000,000 it seems that the Pseudo Mercator transformation to
> 4326 is flawed, as the OSM and the vectors are not aligned.
>
> In scale 1:50,000,000 it seems OK when the extent is the middle of the
> map, but if I pan to the south/north it seems distorted again.
>
>
>
> If I set the project CRS to EPSG:3857 (Pseudo Mercator) as the CRS of the
> OSM tiles, so the vector layer would be transformed instead, then they do
> align in all scales (picture with the blue vector layer).
>
>
>
> It doesn't look like a problem of precision of the transformation from
> 3857 to 4325 because it's way off.
>
> Is that a bug or am I missing something here?
>
>
>
> Kind regards,
>
> Idan.
>
>
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Pseudo Mercator(OSM) @ EPSG:4326 bug?
Thanks for you reply,
Since the problem exist also in 2.18 I don't think it is related with PROJ
5.0, Right?
On 5 Mar 2018 12:39, "Kristian Evers" wrote:
> If you are using PROJ 5.0.0 it is likely to be caused by this known issue:
>
> https://github.com/OSGeo/proj.4/issues/834
>
> /Kristian
>
> -Oprindelig meddelelse-
> Fra: Qgis-user [mailto:qgis-user-boun...@lists.osgeo.org] På vegne af
> Benjamin Ducke
> Sendt: 5. marts 2018 10:18
> Til: qgis-user@lists.osgeo.org
> Emne: Re: [Qgis-user] Pseudo Mercator(OSM) @ EPSG:4326 bug?
>
> Could it be this:
>
> http://proj4.org/faq.html#changing-ellipsoid-why-can-t-
> i-convert-from-wgs84-to-google-earth-virtual-globe-mercator
>
> ?
>
> The further you get from the equator, the more
> obvious the discrepancy on the Y axis.
>
> Best,
>
> Ben
>
> On 05/03/18 09:38, Idan Miara wrote:
> > Hi,
> >
> > I might have found a bug related to transformation of layer CRS
> > from EPSG:3857 (Pseudo Mercator) to EPSG:4325 (WGS84 Geo).
> > I'm attaching a few images to demonstrate the issue.
> >
> > Steps to reproduce:
> > I've load OSM in QGIS 2.18.16 (or 3.0,same results)
> > via Tile Server (XYZ):
> > https://a.tile.openstreetmap.org/{z}/{x}/{y}.png
> > <https://a.tile.openstreetmap.org/%7Bz%7D/%7Bx%7D/%7By%7D.png>
> >
> > Then set the CRS to EPSG:4326 (WGS84 Geo)
> >
> > I've also loaded a global bounds vector layer (EPSG:4326)
> >
> > In scale 1:100,000,000 it seems that the Pseudo Mercator transformation
> > to 4326 is flawed, as the OSM and the vectors are not aligned.
> > In scale 1:50,000,000 it seems OK when the extent is the middle of the
> > map, but if I pan to the south/north it seems distorted again.
> >
> > If I set the project CRS to EPSG:3857 (Pseudo Mercator) as the CRS of
> > the OSM tiles, so the vector layer would be transformed instead, then
> > they do align in all scales (picture with the blue vector layer).
> >
> > It doesn't look like a problem of precision of the transformation from
> > 3857 to 4325 because it's way off.
> > Is that a bug or am I missing something here?
> >
> > Kind regards,
> > Idan.
> >
> >
> >
> > ___
> > Qgis-user mailing list
> > Qgis-user@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
> >
>
>
>
> --
> Dr. Benjamin Ducke
> Deutsches Archäologisches Institut (DAI)
> Zentrale Berlin, IT-Referat
> * Projekt "Stunde Null" *
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Pseudo Mercator(OSM) @ EPSG:4326 bug?
Hi,
I might have found a bug related to transformation of layer CRS from EPSG:3857
(Pseudo Mercator) to EPSG:4325 (WGS84 Geo).
I'm attaching a few images to demonstrate the issue.
Steps to reproduce:
I've load OSM in QGIS 2.18.16 (or 3.0,same results)
via Tile Server (XYZ):
https://a.tile.openstreetmap.org/{z}/{x}/{y}.png
Then set the CRS to EPSG:4326 (WGS84 Geo)
I've also loaded a global bounds vector layer (EPSG:4326)
In scale 1:100,000,000 it seems that the Pseudo Mercator transformation to
4326 is flawed, as the OSM and the vectors are not aligned.
In scale 1:50,000,000 it seems OK when the extent is the middle of the map,
but if I pan to the south/north it seems distorted again.
If I set the project CRS to EPSG:3857 (Pseudo Mercator) as the CRS of the
OSM tiles, so the vector layer would be transformed instead, then they do
align in all scales (picture with the blue vector layer).
It doesn't look like a problem of precision of the transformation from 3857
to 4325 because it's way off.
Is that a bug or am I missing something here?
Kind regards,
Idan.
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Free/Open Data Maps list
@all Thanks for all the helpful and quick responses! On 27 February 2018 at 11:51, Albin Blaschka < albin.blasc...@standortsanalyse.net> wrote: > Am 27.02.2018 10:30, schrieb Idan Miara: > > Hi, > > I'm looking for different maps (preferably global maps) to use as a > background in QGIS > (Topographic maps, Orthophoto, DTM etc). > Is there a list/plugin with a collection of free/open data maps that I can > use? > > > > For QGIS 2.x there is the Quickmapservices-Plugin for various Background > maps, as far as I know, it is not yet ported to QGIS 3 > > As far as DTMs are concerned, there are different websites, where you can > download such data (ASTER & Co.), a nice compilation is > http://viewfinderpanoramas.org/ > > > HTH, > Albin > > -- > | Dr.rer.nat. Albin Blaschka > | Etrichstrasse 26, A-5020 Salzburg > <https://maps.google.com/?q=Etrichstrasse+26,+A-5020+Salzburg&entry=gmail&source=g> > | * www.standortsanalyse.net * > | * www.researchgate.net/profile/Albin_Blaschka * > | - It's hard to live in the mountains, hard but not hopeless! > ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
[Qgis-user] Free/Open Data Maps list
Hi, I'm looking for different maps (preferably global maps) to use as a background in QGIS (Topographic maps, Orthophoto, DTM etc). Is there a list/plugin with a collection of free/open data maps that I can use? Regards, Idan. ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
[Qgis-user] pcs.csv parameters and Proj4
Hi, I'm trying to decipher pcs.csv (Is there a documentation?): my guess was: PARAMETER_VALUE_1=lat_0 PARAMETER_VALUE_2=lon_0 PARAMETER_VALUE_3=k PARAMETER_VALUE_4=x_0 PARAMETER_VALUE_5=y_0 But apparently that's not exactly the case for parameters 1+2, for instance (EPSG:2036): http://spatialreference.org/ref/epsg/2036/proj4/: (same as in QGIS CRS window) +proj=sterea +lat_0=46.5 +lon_0=-66.5 +k=0.12 +x_0=250 +y_0=750 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs pcs.csv: PARAMETER_VALUE_1=46.3 (not 46.5) PARAMETER_VALUE_2=-66.3 (not -66.5) for other projections I checked there is also difference in parameters 1+2, What am I missing here? Also, Does QGIS "generate" a proj4 definition from the pcs/gcs/datum csv files by EPSG codes? if so, how? Best Regards, Idan ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] QGIS/GDAL 2.0.2 bug (fixed in 2.1)
Answering myself... GDAL 2.1 already on QGIS 2.14.3-2. On 21 June 2016 at 10:01, Idan Miara wrote: > Thanks for the quick answer! > Does it mean that the next official QGIS releases will automatically use > it? > > On 21 June 2016 at 09:56, Jürgen E. wrote: > >> Hi Idan, >> >> On Tue, 21. Jun 2016 at 09:53:54 +0300, Idan Miara wrote: >> > Will QGIS use GDAL 2.1 in the near future ? >> >> GDAL is already at 2.1 in OSGeo4W. >> >> >> Jürgen >> >> -- >> Jürgen E. Fischer norBIT GmbH Tel. >> +49-4931-918175-31 >> Dipl.-Inf. (FH) Rheinstraße 13 Fax. >> +49-4931-918175-50 >> Software Engineer D-26506 Norden >> http://www.norbit.de >> QGIS release manager (PSC) GermanyIRC: jef on >> FreeNode >> >> ___ >> Qgis-user mailing list >> Qgis-user@lists.osgeo.org >> List info: http://lists.osgeo.org/mailman/listinfo/qgis-user >> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user >> > > ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] QGIS/GDAL 2.0.2 bug (fixed in 2.1)
Thanks for the quick answer! Does it mean that the next official QGIS releases will automatically use it? On 21 June 2016 at 09:56, Jürgen E. wrote: > Hi Idan, > > On Tue, 21. Jun 2016 at 09:53:54 +0300, Idan Miara wrote: > > Will QGIS use GDAL 2.1 in the near future ? > > GDAL is already at 2.1 in OSGeo4W. > > > Jürgen > > -- > Jürgen E. Fischer norBIT GmbH Tel. > +49-4931-918175-31 > Dipl.-Inf. (FH) Rheinstraße 13 Fax. > +49-4931-918175-50 > Software Engineer D-26506 Norden > http://www.norbit.de > QGIS release manager (PSC) GermanyIRC: jef on FreeNode > > ___ > Qgis-user mailing list > Qgis-user@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-user > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user > ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
[Qgis-user] QGIS/GDAL 2.0.2 bug (fixed in 2.1)
Hi, I've found a SRS related bug in GDAL 2.0.2 which is bundled with the latest QGIS releases. the bug was fixed in GDAL 2.1.0, which was released a few weeks ago. I can't find any bug report ticket for it and I can't tell if it would be fixed for GDAL 2.0.3. Should I report it? Will QGIS use GDAL 2.1 in the near future ? Idan. ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
