Re: [Qgis-user] First steps with 3D Scan Data?

[Priv. Doz. Dr. Maria Shinoto]

Definitely try the Agisoft solution, it is great. We use for recording 
archaeological on site and for artefacts.

Best, 
Maria

> Am 26.03.2021 um 07:17 schrieb David Greenewalt :
> 
> I know nothing of the data you have or the subject in general, but was 
> intrigued a few years ago with software that would generate 3d models from 
> photos ("scans from all angles"?).  Look at 
> https://www.agisoft.com/features/standard-edition/ for example.  May not be 
> helpful or fruitful, but fun (and pretty incredible).
> 
> Good Luck,
> David
> 
> 
> On 3/25/2021 5:07 PM, Bernd Vogelgesang wrote:
>> Hi folks, 
>> 
>> in a project on a former dumpside now to be transformed into a sand 
>> lizard habitat, I saw the chance to get my hands dirty for the first 
>> time on 3D scan data (terrestrial). I received 10GB of stuff, and now 
>> I'm completely lost. 
>> 
>> The data consists of .rwcx files, .tzf files and lots of other stuff. 
>> 
>> Is there any chance that I can process any of this data with an open 
>> source stack? 
>> Or what should be done, to make them digestible? 
>> 
>> Second step: There seem to be 32 different scans of the area form all 
>> angles. In case I succeed to somehow load the data, how do I combine them ? 
>> 
>> For the first steps, I actually "only" would like to generate a decent 
>> DEM from the data to be able to place some features on a map for the 
>> guys in charge to do the habitat stuff. 
>> 
>> Any kind of hints or links to reads about this topic would be appreciated 
>> 
>> Cheers, 
>> 
>> Bernd 
>> 
>> 
>> ___ 
>> 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] z factor

[Priv. Doz. Dr. Maria Shinoto]

Nicolas, 

that would be helpful indeed! Yet I do it manually each time...

Maria



> Am 27.11.2020 um 14:13 schrieb Nicolas Cadieux :
> 
> Hi,
> 
> It's just the Z factor needed when you make a hillshade when the x an y are 
> in degrees and the z is in feet or meters (like SRTM). You can see it if you 
> choose Hillshade under symbology / render type (for a raster layer).  It's 
> basically the length of a degree in meters for latitude.
> 
> https://www.esri.com/arcgis-blog/products/product/imagery/setting-the-z-factor-parameter-correctly/
> 
> Nicolas
> 
> On 2020-11-27 12:08 a.m., Richard Duivenvoorde wrote:
>> On 11/27/20 5:28 AM, Nicolas Cadieux wrote:
>>> I want to learn to make a QGIS plugin and I was wondering if anybody new if 
>>> there is a QGIS plugin or tool that calculates the z factor for a 
>>> particular latitude? I thought this would be an easy project to start with 
>>> but I don't want to duplicate someone else's work.
>> Hi Nicolas,
>> 
>> What do you mean with "calculates the z factor for a particular latitude"?
>> 
>> - z-factor as in x,y,z?
>> - Do you mean based on a crs/datum? So more proj-based?
>> - Or do you mean based on a known dataset with not enough z-info? So more 
>> extra/intrapolation?
>> - Raster? Vector?
>> - Creating a new dataset (processing)? Or just reporting for one lat 
>> (desktop/gui)?
>> 
>> Just trying to get an idea of your idea :-)
>> 
>> Regards,
>> 
>> Richard Duivenvoorde
>> 
>> 
>> 
> -- 
> Nicolas Cadieux
> https://gitlab.com/njacadieux
> 
> ___
> 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] Vote for Lat Lon Tools Default Coordinate Order -, YX or XY

[Priv. Doz. Dr. Maria Shinoto]

Hi, 

the tool is great, thank you so much -- and I can live with the settings as 
they are. 

Maria

> Am 21.11.2020 um 08:44 schrieb Mike Flannigan :
> 
> 
> I too like lat,long, but I can live with anything that is done.
> I'll just set it to lat,long.
> 
> I understand the thinking to change it to X,Y.  Many people
> in the field would agree that is better.  I'm just not one of them.
> 
> I use this tool constantly.  Thank you.
> 
> 
> Mike
> 
> 
> On 11/20/20 2:00 PM, qgis-user-requ...@lists.osgeo.org wrote:
>> It was suggested to me that the default coordinate order in the Lat Lon
>> Tools plugin for coordinate capture and zoom-to tools should be "longitude,
>> latitude" or "X, Y". Originally, Lat Lon Tools was designed to work with
>> on-line maps which are generally "latitude, longitude" order.
>> 
>> You can always go into the plugin settings and specify which order you want
>> and that order will be preserved everytime you launch QGIS. The default
>> order is only applicable the first time you install "Lat Lon Tools" or if
>> you do a reset to defaults in the Lat Lon Tools settings menu,
>> 
>> Who prefers Lat Lon Tools to default to "longitude, latitude" or "X, Y"
>> when the plugin is first installed or reset to default values?
>> 
>> Who prefers Lat Lon Tools to default to "latitude, longitude (Google map
>> order)" or "Y, X" when the plugin is first installed or reset to default
>> values?
>> 
>> I'm just checking to see if I should make this change or not.
>> 
>> Thanks,
>> 
>> Calvin
> 
> 
> ___
> 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] Mac computer configuration

[Priv.-Doz. Dr. Maria Shinoto]

Hi Reiko, 

I am afraid that the RAM is the first problem, 8GB is just not enough. In this 
situation, it may be better to just buy a cheap solution and wait for a cheap 
and great AMD one. I can understand your pain, it was so horrible last year 
with my old MacBook Pro as well. 

Maria

> Am 10.09.2020 um 07:58 schrieb RMG :
> 
> Thanks, Maria,
> 
> Thanks for your suggestions. Everything you are saying makes sense. The main 
> problem is that I can't upgrade the RAM of this Macbook Pro. I am leaning 
> towards a Mac mini with 3.2GHz 6‑core 8th‑generation Intel Core i7, but let 
> me try what you suggest before investing (removing non-GIS stuff off the SSD. 
> Part of the problem may be that all the GIS data are in a non-SSD external 
> drive). And of course, I will wait until the Sept. 15th event for their 
> announcement about anything new.
> 
> Best wishes,
> 
> 
> Reiko Matsuda Goodwin
> Comoé Monkey Project
> Guenon Conservation Community
> 
> 
> 
> 
> On Wed, Sep 9, 2020 at 6:36 PM Priv.-Doz. Dr. Maria Shinoto 
>  wrote:
> Hi, 
> 
> I can only add to Donal's suggestions, which seem reasonable from my 
> experience as well. 
> 
> Until last year, I have been working on a 13 inch MacBook Pro from 2011. I 
> changed the HD to a 500GB SSD and the 8GB RAM to 16GB RAM a few years ago, 
> and there was a jump in performance with all my software, I could have used 
> it some more years. But QGIS got slow though with LiDAR data last year, so I 
> bought a new MacBook Pro with 2GB SSD and 32GB RAM, now everything works 
> smoothly; thanks to large storage and RAM in the first place, I assume.
> 
> At the moment, I would hesitate to either buy a new machine with ARM or Intel 
> processor but rather wait another year or a few months. 
> 
> In your case, I would try to boost RAM to 32GB in the first place (if 32 is 
> possible, otherwise 16GB). If things are still slow, I would delete 
> everything not needed on a daily basis from the main SSD and get the GIS data 
> on the SSD. And then wait for the AMD Macs and look how the reviews are. It 
> seems that everything just gets better then and cheaper. And paying for RAM 
> now is not such a large investment. 
> 
> Best, 
> Maria
> 
> 
>> Am 10.09.2020 um 06:26 schrieb Donal Hunt :
>> 
>> You can compare the CPU ratings of your current machine vs the ratings for 
>> the currently available i5 and i7 models of the mac mini here: 
>> https://www.cpubenchmark.net/compare/Intel-i5-5287U-vs-Intel-i5-8500B-vs-Intel-i7-8700B/2575vs3382vs3388
>> 
>> Additional memory (16gb or 32gb) may also help. You could potentially attach 
>> a fast nvme drive to the thunderbolt 3 port (you can't upgrade the SSD on 
>> the latest generation of mac minis as they are soldered to the logic board).
>> 
>> I would highly recommend profiling where the bottleneck / performance issues 
>> are occurring. Tools such as activity monitor, instruments and sample can 
>> provide more insight. See 
>> https://gist.github.com/loderunner/36724cc9ee8db66db305 for some suggestions.
>> 
>> Hope that helps.
>> 
>> Donal
>> 
>> On Wed, 9 Sep 2020 at 15:04, RMG  wrote:
>> Hello Donal and list,
>> 
>> Many thanks for asking. Below is the info:
>> 
>> Model Name: MacBook Pro
>>  Model Identifier: MacBookPro12,1
>>  Processor Name: Intel Core i5
>>  Processor Speed: 2.9 GHz
>>  Number of Processors: 1
>>  Total Number of Cores: 2
>>  L2 Cache (per Core): 256 KB
>>  L3 Cache: 3 MB
>>  Hyper-Threading Technology: Enabled
>>  Memory: 8 GB
>>  Boot ROM Version: 192.0.0.0.0
>>  SMC Version (system): 2.28f7
>> 
>> Apple SSD Controller:
>> 
>>  Vendor: Apple
>>  Product: SSD Controller
>>  Physical Interconnect: PCI
>>  Link Width: x4
>>  Link Speed: 5.0 GT/s
>>  Description: AHCI Version 1.30 Supported
>> 
>> APPLE SSD SM0512G:
>> 
>>  Capacity: 500.28 GB (500,277,790,720 bytes)
>>  Model: APPLE SSD SM0512G   
>>  Revision: BXW1SA0Q
>>  Native Command Queuing: Yes
>>  Queue Depth: 32
>>  Removable Media: No
>>  Detachable Drive: No
>>  BSD Name: disk0
>>  Medium Type: Solid State
>>  TRIM Support: Yes
>>  Partition Map Type: GPT (GUID Partition Table)
>>  S.M.A.R.T. status: Verified
>> 
>> Best wishes,
>> 
>> Reiko Matsuda Goodwin
>> Comoé Monkey Project
>> Guenon Conservation Community
>> 
>> 
>> 
>> 
>> On Wed, S

Re: [Qgis-user] Mac computer configuration

[Priv.-Doz. Dr. Maria Shinoto]

Hi, 

I can only add to Donal's suggestions, which seem reasonable from my experience 
as well. 

Until last year, I have been working on a 13 inch MacBook Pro from 2011. I 
changed the HD to a 500GB SSD and the 8GB RAM to 16GB RAM a few years ago, and 
there was a jump in performance with all my software, I could have used it some 
more years. But QGIS got slow though with LiDAR data last year, so I bought a 
new MacBook Pro with 2GB SSD and 32GB RAM, now everything works smoothly; 
thanks to large storage and RAM in the first place, I assume.

At the moment, I would hesitate to either buy a new machine with ARM or Intel 
processor but rather wait another year or a few months. 

In your case, I would try to boost RAM to 32GB in the first place (if 32 is 
possible, otherwise 16GB). If things are still slow, I would delete everything 
not needed on a daily basis from the main SSD and get the GIS data on the SSD. 
And then wait for the AMD Macs and look how the reviews are. It seems that 
everything just gets better then and cheaper. And paying for RAM now is not 
such a large investment. 

Best, 
Maria


> Am 10.09.2020 um 06:26 schrieb Donal Hunt :
> 
> You can compare the CPU ratings of your current machine vs the ratings for 
> the currently available i5 and i7 models of the mac mini here: 
> https://www.cpubenchmark.net/compare/Intel-i5-5287U-vs-Intel-i5-8500B-vs-Intel-i7-8700B/2575vs3382vs3388
> 
> Additional memory (16gb or 32gb) may also help. You could potentially attach 
> a fast nvme drive to the thunderbolt 3 port (you can't upgrade the SSD on the 
> latest generation of mac minis as they are soldered to the logic board).
> 
> I would highly recommend profiling where the bottleneck / performance issues 
> are occurring. Tools such as activity monitor, instruments and sample can 
> provide more insight. See 
> https://gist.github.com/loderunner/36724cc9ee8db66db305 for some suggestions.
> 
> Hope that helps.
> 
> Donal
> 
> On Wed, 9 Sep 2020 at 15:04, RMG  wrote:
> Hello Donal and list,
> 
> Many thanks for asking. Below is the info:
> 
> Model Name: MacBook Pro
>   Model Identifier: MacBookPro12,1
>   Processor Name: Intel Core i5
>   Processor Speed: 2.9 GHz
>   Number of Processors: 1
>   Total Number of Cores: 2
>   L2 Cache (per Core): 256 KB
>   L3 Cache: 3 MB
>   Hyper-Threading Technology: Enabled
>   Memory: 8 GB
>   Boot ROM Version: 192.0.0.0.0
>   SMC Version (system): 2.28f7
>   
> Apple SSD Controller:
> 
>   Vendor: Apple
>   Product: SSD Controller
>   Physical Interconnect: PCI
>   Link Width: x4
>   Link Speed: 5.0 GT/s
>   Description: AHCI Version 1.30 Supported
> 
> APPLE SSD SM0512G:
> 
>   Capacity: 500.28 GB (500,277,790,720 bytes)
>   Model: APPLE SSD SM0512G   
>   Revision: BXW1SA0Q
>   Native Command Queuing: Yes
>   Queue Depth: 32
>   Removable Media: No
>   Detachable Drive: No
>   BSD Name: disk0
>   Medium Type: Solid State
>   TRIM Support: Yes
>   Partition Map Type: GPT (GUID Partition Table)
>   S.M.A.R.T. status: Verified
> 
> Best wishes,
> 
> Reiko Matsuda Goodwin
> Comoé Monkey Project
> Guenon Conservation Community
> 
> 
> 
> 
> On Wed, Sep 9, 2020 at 5:05 AM Donal Hunt  wrote:
> Can you provide the following information from the command line (run these 
> commands and paste the output):
> 
> $ system_profiler SPHardwareDataType
> 
> $ system_profiler -detailLevel mini SPSerialATADataType SPParallelATADataType
> 
> * you may want to remove/redact the "Serial Number (system)" and "Hardware 
> UUID" values before emailing.
> 
> That will provide some information on your existing system and disks which 
> will make it easier to determine what appropriate replacements are needed. 
> Normally, I would look at CPU performance, amount of RAM and disk speeds (HDD 
> vs SSD vs NVMe makes a huge difference).
> 
> Hope that helps!
> 
> Donal
> 
> On Wed, 9 Sep 2020 at 02:00, RMG  wrote:
>  Hello QGIS users on Macs,
> 
> I would like advice on purchasing a new Mac. My Mac is 5 years old and cannot 
> handle heavy-duty QGIS procedures. I process many satellite images and some 
> vector files with 30 m grids have millions of features, for example. To 
> process anything is taking too long. I know there has been a discussion on 
> ARMS hardware, but that seems a few years away. So right now, what would you 
> recommend? I plan to partition the hard drive to handle ArcGIS as well. I do 
> not think I can afford a dream machine like Mac Pro, though. Is a Mac mini 
> something that you guys use and recommend?
> 
> Best wishes,
> 
> Reiko Matsuda Goodwin
> Comoé Monkey Project
> Guenon Conservation Community
> 
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: 

Re: [Qgis-user] Looking for a simple (bw or greyscale) basic map

[Priv.-Doz. Dr. Maria Shinoto]

Hi Phil, 

Thank you so much, this is exactly what I needed! 

I do not know why my search was so screwed up. Great help and community, 

problem solved, 

Maria


> Am 04.09.2020 um 17:35 schrieb Phil Wyatt :
> 
> Hi Maria,
> 
> Try grabbing some large scale country data from Natural earth - that should 
> suit your purposes with a bit of quick styling
> 
> https://www.naturalearthdata.com/downloads/
> 
> 
> Cheers - Phil
> -Original Message-----
> From: Qgis-user  On Behalf Of Priv.-Doz. 
> Dr. Maria Shinoto
> Sent: Friday, 4 September 2020 6:10 PM
> To: qgis-user@lists.osgeo.org
> Subject: [Qgis-user] Looking for a simple (bw or greyscale) basic map
> 
> Hi, 
> 
> I need a base map for East asia, best would be greascale or just black lines 
> on white ground, no names and city locations. I am testing QuickPam plugin 
> and several tile providers, but searching takes ages, and yet I did not find 
> anything helpful. 
> 
> Does anybody have an idea where to look or which search phrase to use? 
> 
> When I find a starting point, I can go and try further, thanks!
> 
> Maria
> 
> ___
> 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] Looking for a simple (bw or greyscale) basic map

[Priv.-Doz. Dr. Maria Shinoto]

Hi, 

I need a base map for East asia, best would be greascale or just black lines on 
white ground, no names and city locations. I am testing QuickPam plugin and 
several tile providers, but searching takes ages, and yet I did not find 
anything helpful. 

Does anybody have an idea where to look or which search phrase to use? 

When I find a starting point, I can go and try further, thanks!

Maria

___
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] How to Create These type of Watershed Maps in QGIS

[Priv.-Doz. Dr. Maria Shinoto]

Sorry, just an addendum, 

for creating these watershed maps, you need a DEM, older satellite data should 
suffice for larger maps. I was working on a small scale (16 km2) with a 5m DTM. 

The process is the same: use WangLiu algorithm in the processing toolbox (SAGA 
tools) to fill sinks, then calculate Strahler order (SAGA tools), set a 
threshold for the start of a "stream", then define a point for the upstream 
area. You can vectorize the area and then style the streams (great with the 
order value, you can set the width of the streams) and the drainage basins. 

I am still impressed, it is so helpful and easy. You can do the same with GRASS 
tools as well, although some steps vary a bit. 

Good luck, 
Maria




Hi, 

I just created one yesterday with the book of Hans van der Kwast. So easy! 
(when you are told what to do...)

He has a YouTube channel where you can follow these instructions as well. 

Best,
Maria

> Am 07.08.2020 um 07:13 schrieb C Hamilton :
> 
> I was wondering if anyone had any idea on how one would go about creating 
> these types of maps in QGIS.
> 
> https://www.visualcapitalist.com/maps-worlds-watersheds/ 
> 
> Assume the watershed polygons are available as well as the river data.
> 
> Anyway I think these pictures are stunning.
> 
> Thanks,
> 
> Calvin
> ___
> 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] How to Create These type of Watershed Maps in QGIS

[Priv.-Doz. Dr. Maria Shinoto]

Hi, 

I just created one yesterday with the book of Hans van der Kwast. So easy! 
(when you are told what to do...)

He has a YouTube channel where you can follow these instructions as well. 

Best,
Maria

> Am 07.08.2020 um 07:13 schrieb C Hamilton :
> 
> I was wondering if anyone had any idea on how one would go about creating 
> these types of maps in QGIS.
> 
> https://www.visualcapitalist.com/maps-worlds-watersheds/ 
> 
> Assume the watershed polygons are available as well as the river data.
> 
> Anyway I think these pictures are stunning.
> 
> Thanks,
> 
> Calvin
> ___
> 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] GDAL on newer versions of QGIS for Mac

[Priv.-Doz. Dr. Maria Shinoto]

No problems here. 

Mac OS 10.15.5
QGIS 3.12.3
GDAL 2.4.1

Best, 
Maria



> Am 06.08.2020 um 05:12 schrieb Erich Purpur :
> 
> Hi all-
> 
> This is something I am not clear about, so apologies if I have overlooked 
> something obvious. It seems that GDAL (and most raster processing) tools 
> don't work on more recent versions of QGIS for Mac. I did some investigating 
> and found that this was a known issue: 
> https://github.com/qgis/QGIS-Mac-Packager/issues/28#issuecomment-662988847. 
> There is a workaround detailed in the above mentioned github thread, which I 
> have used and it works for me, but is quite an undertaking for less adept 
> users.
> 
> One of the core developers stated it would be resolved by v3.14, which is 
> currently out but does not provide a fix as far as I can tell after 
> downloading and testing on that version.
> 
> Is this still a known issue?  Is anyone else experiencing this? Thank you for 
> any information.
> 
> -Erich Purpur
> ___
> 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] New Apple Macintosh ARM Chipsets

[Priv.-Doz. Dr. Maria Shinoto]

Hi, 

earlier posts said that a port to ARM architecture should not be too big of a 
problem. 

I do not remember the details, but my conclusion was: Just wait, no problems to 
expect. 

But I have to admit that I own a MacBook Pro from 2019 and do not plan to 
change in the next five or more years. I would hesitate to buy ARM architecture 
in the next 12 months anyway. 

Best, 
Maria

> Am 09.07.2020 um 22:57 schrieb Michael Goldstein 
> :
> 
> 
> I've just joined this email list, so if this has been covered earlier, I 
> apologize.  Also, let me know if I should be directing this question to a 
> different mailing list (Developer list?).
> 
> Do plans exist to port QGIS to the new Apple Mac ARM architecture?
> 
> While I am not technical enough to help with the coding/re-compiling, I am a 
> good documentation writer and would be happy to help document a new Mac 
> release.  How should I volunteer?
> 
> Michael
> ___
> 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] Plugin to show 2 layers at once like with a curtain

[Priv.-Doz. Dr. Maria Shinoto]

Hi, 

Thanks for hinting me to this possibility, it will come in handy when I have 
proceeded a bit more with understanding my are, so, thanks again. 

The beauty of the swipe plugin is not only, that it gives a nice WOW-effect 
when talking, I now see how I can follow the development of a certain 3D 
feature from my LiDAR data on an underlying old areal photo etc., very 
intuitive and easy to follow with the eye. 

Best, 
Maria


> Am 05.07.2020 um 16:47 schrieb Lene Fischer :
> 
> You have also the possibility to use 'View>New map view' First you have to 
> define different 'Themes'. 
> Look at this 
> https://docs.qgis.org/3.10/en/docs/user_manual/introduction/qgis_gui.html#label-mapview
> 
> 
> 
> Lene Fischer
> Associate Professor
> 
> University of Copenhagen
> Department of Geosciences and Natural Resource Management
> Forest and Landscape College
> Nødebovej 77a
> 3480 Fredensborg
> 
> MOB +45 40115084
> l...@ign.ku.dk-----Original Message-
> From: Qgis-user  On Behalf Of Priv.-Doz. 
> Dr. Maria Shinoto
> Sent: 5. juli 2020 04:14
> To: Germán Carrillo 
> Cc: qgis-user@lists.osgeo.org
> Subject: Re: [Qgis-user] Plugin to show 2 layers at once like with a curtain
> 
> This is fantastic! Works vertical and horizontal, has one base layer fixed 
> and I can compare this one spontaneously to any other layer. It really helps 
> understanding the relations. 
> 
> Thanks again, Germán,
> Maria
> 
> 
>> Am 05.07.2020 um 11:07 schrieb Germán Carrillo :
>> 
>> Hi, 
>> 
>> that plugin is called "MapSwipe Tool": 
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplugins.qgis.org%2Fplugins%2Fmapswipetool_plugin%2Fdata=02%7C01%7Clfi%40ign.ku.dk%7C4a9b54ce054a4f794ac808d8208916aa%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C637295120444978865sdata=qd6PnyXI25QBvb93JM%2FopXvNxKqzlyTOCV8kPBNG1jk%3Dreserved=0
>> 
>> A demo GIF: 
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Flmotta%2Fmapswipetool_plugin%2Fqgis3%2Fdoc%2Fmapswipe1.gifdata=02%7C01%7Clfi%40ign.ku.dk%7C4a9b54ce054a4f794ac808d8208916aa%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C637295120444988866sdata=TcA7URiTLsmAnv%2F1N0D5Lx45665j4xCGTJ8vu5EAkMI%3Dreserved=0
>> 
>> Regards, 
>> 
>> Germán
>> 
>> 
>> 
>> El sáb., 4 jul. 2020 a las 21:02, Priv.-Doz. Dr. Maria Shinoto 
>> () escribió:
>> Hi, 
>> 
>> at the moment I am preparing a presentation where I have to show a lot of 
>> comparisons, the lower layer raw data, the top layer with some processed 
>> infos etc. 
>> 
>> It might look good to show them at once with a vertical separator that I can 
>> move in order to show more or less of the bottom layer. 
>> 
>> Unfortunately, I do not find the right words to look for a plugin that does 
>> just this, although I think I have seen a plugin like that. 
>> 
>> 
>> Can somebody help me out with more information or an appropriate plugin? 
>> 
>> 
>> Best, 
>> Maria
>> 
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> List info: 
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fqgis-userdata=02%7C01%7Clfi%40ign.ku.dk%7C4a9b54ce054a4f794ac808d8208916aa%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C637295120444988866sdata=j%2FvtmKBbwMgFtLlgMW555qb%2B0xzn39ZUdhs8Q%2BvWk8Q%3Dreserved=0
>> Unsubscribe: 
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fqgis-userdata=02%7C01%7Clfi%40ign.ku.dk%7C4a9b54ce054a4f794ac808d8208916aa%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C637295120444988866sdata=j%2FvtmKBbwMgFtLlgMW555qb%2B0xzn39ZUdhs8Q%2BvWk8Q%3Dreserved=0
>> 
>> 
>> -- 
>> Grupo de Usuarios QGIS Colombia
>> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fqgisusers.co%2Fdata=02%7C01%7Clfi%40ign.ku.dk%7C4a9b54ce054a4f794ac808d8208916aa%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C637295120444988866sdata=4CrTqQoJ%2BCiwNJyXDHa30F1DLBiDM%2FDpdHduRxzkjKY%3Dreserved=0
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fqgiscolombiadata=02%7C01%7Clfi%40ign.ku.dk%7C4a9b54ce054a4f794ac808d8208916aa%7Ca3927f91cda14696af898c9f1ceffa91%7C0%7C0%7C637295120444988866sdata=hMILa9lBSrXHqz%2BL34DIHRFcRGE7biy9KO2iH1blOVI%3Dreserved=0
>> 
>> 
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: 
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Fli

Re: [Qgis-user] Plugin to show 2 layers at once like with a curtain

[Priv.-Doz. Dr. Maria Shinoto]

This is fantastic! Works vertical and horizontal, has one base layer fixed and 
I can compare this one spontaneously to any other layer. It really helps 
understanding the relations. 

Thanks again, Germán,
Maria


> Am 05.07.2020 um 11:07 schrieb Germán Carrillo :
> 
> Hi, 
> 
> that plugin is called "MapSwipe Tool": 
> https://plugins.qgis.org/plugins/mapswipetool_plugin/
> 
> A demo GIF: 
> https://raw.githubusercontent.com/lmotta/mapswipetool_plugin/qgis3/doc/mapswipe1.gif
> 
> Regards, 
> 
> Germán
> 
> 
> 
> El sáb., 4 jul. 2020 a las 21:02, Priv.-Doz. Dr. Maria Shinoto 
> () escribió:
> Hi, 
> 
> at the moment I am preparing a presentation where I have to show a lot of 
> comparisons, the lower layer raw data, the top layer with some processed 
> infos etc. 
> 
> It might look good to show them at once with a vertical separator that I can 
> move in order to show more or less of the bottom layer. 
> 
> Unfortunately, I do not find the right words to look for a plugin that does 
> just this, although I think I have seen a plugin like that. 
> 
> 
> Can somebody help me out with more information or an appropriate plugin? 
> 
> 
> Best, 
> Maria
> 
> ___
> 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
> 
> 
> -- 
> Grupo de Usuarios QGIS Colombia
> http://qgisusers.co
> https://twitter.com/qgiscolombia
> 
> 

___
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] Plugin to show 2 layers at once like with a curtain

[Priv.-Doz. Dr. Maria Shinoto]

That was quick!

Thanks a lot, I will just check it out. 

Best, 
Maria


> Am 05.07.2020 um 11:07 schrieb Germán Carrillo :
> 
> Hi, 
> 
> that plugin is called "MapSwipe Tool": 
> https://plugins.qgis.org/plugins/mapswipetool_plugin/
> 
> A demo GIF: 
> https://raw.githubusercontent.com/lmotta/mapswipetool_plugin/qgis3/doc/mapswipe1.gif
> 
> Regards, 
> 
> Germán
> 
> 
> 
> El sáb., 4 jul. 2020 a las 21:02, Priv.-Doz. Dr. Maria Shinoto 
> () escribió:
> Hi, 
> 
> at the moment I am preparing a presentation where I have to show a lot of 
> comparisons, the lower layer raw data, the top layer with some processed 
> infos etc. 
> 
> It might look good to show them at once with a vertical separator that I can 
> move in order to show more or less of the bottom layer. 
> 
> Unfortunately, I do not find the right words to look for a plugin that does 
> just this, although I think I have seen a plugin like that. 
> 
> 
> Can somebody help me out with more information or an appropriate plugin? 
> 
> 
> Best, 
> Maria
> 
> ___
> 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
> 
> 
> -- 
> Grupo de Usuarios QGIS Colombia
> http://qgisusers.co
> https://twitter.com/qgiscolombia
> 
> 

___
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] Plugin to show 2 layers at once like with a curtain

[Priv.-Doz. Dr. Maria Shinoto]

Hi, 

at the moment I am preparing a presentation where I have to show a lot of 
comparisons, the lower layer raw data, the top layer with some processed infos 
etc. 

It might look good to show them at once with a vertical separator that I can 
move in order to show more or less of the bottom layer. 

Unfortunately, I do not find the right words to look for a plugin that does 
just this, although I think I have seen a plugin like that. 


Can somebody help me out with more information or an appropriate plugin? 


Best, 
Maria

___
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] Hillshade Rough Blocks for 1m Rasters?

[Priv.-Doz. Dr. Maria Shinoto]

A month ago or so I had exactly the same problem and could solve it with these 
tips from Nicolas. Good luck!

Maria


> Am 30.06.2020 um 07:32 schrieb Nicolas Cadieux :
> 
> Hi,
> 
> If your x and y distance unit is different from the z distance (like long lat 
> degrees for x and y and meters for z), you will need a z Factor, or you need 
> to save the raster in a crs that has x,y,z in the same unit (like meter).
> 
> https://www.esri.com/arcgis-blog/products/product/imagery/setting-the-z-factor-parameter-correctly/
> 
> You can also improve the look in the layer/Symbology/Resampling and select 
> cubic for "zoomed in" and Average for "zoomed out".
> 
> Nicolas
> 
> On 2020-06-29 6:23 p.m., Alister Hood wrote:
>> It does shade the pixel, but it also shades the edges unless the layer is 
>> being reprojected.
>> There is a ticket for this, but you can workaround it by enabling resampling 
>> for that layer.
>>  
>> Date: Mon, 29 Jun 2020 16:57:11 -0400
>> From: 
>> To: 
>> Subject: [Qgis-user] Hillshade Rough Blocks for 1m Rasters?
>> Message-ID: <024601d64e57$dcbddd00$96399700$@graytechsoftware.com>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> If I use a 1m resolution raster on a CRS in meters and render it as a
>> hillshade, it appears to shade the edges of each pixel instead of the pixel
>> itself:
>> 
>> If I use, a raster made in a CRS with ft for units displayed on a CRS in
>> meters, it renders each pixel smoothly:
>> 
>> How do I get the hillshade to render smoothly always, especially in a CRS in
>> meters when using metric units for the raster?
>> 
>> Thank you, Chris
>> 
>> 
>> ___
>> 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] Authentication System: DISABLED. Resources authenticating via the system can not be accessed

[Priv.-Doz. Dr. Maria Shinoto]

Hi, 

I do not recall the exact dialog, but I also get this kind of messages when I 
first opened QGIS 3.10 and 3.12. 

Just go to the security settings like with every other non-App-Store 
application on Mac and set QGIS to open. Just ignore the horrible message and 
open QGIS again, it works. 

Hopefully, this was your problem, 
Maria


> Am 11.06.2020 um 20:56 schrieb Hitanshu Vora :
> 
> 
> Dear All,
> 
> I'm using the MAC operating system. I've installed Python 3.6.8 & QGIS macOS 
> Installer Version 3.10
> 
> I get the message
> 
> Authentication System: DISABLED. Resources authenticating via the system can 
> not be accessed
> 
> 
> Kindly help me to resolve the issue.
> 
> Thank you
> 
> Yours Sincerely
> 
> -- 
> Hitanshu Vora  
> IT Department
> Amrut Mody School of Management
> Phone No : +91 79 61911314  
> 
> 
> This email and any files transmitted with it are confidential and may be 
> privileged and are intended solely for the use of the entity / individual to 
> whom they are addressed. If you have received this email in error or if you 
> are not the intended recipient, please notify the sender immediately and 
> delete this message and any files transmitted along with it. The views 
> presented in the email are solely those of the author and do not necessarily 
> represent those of the organization. While all care has been taken to avoid 
> viruses, the recipient is advised to check this email and attachments for 
> presence of viruses. The university accepts no liability on this account.
> 
> Please consider the environment and only print this e-mail if necessary.
> ___
> 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] wishing for accurate lattitude/longitude from, a cell phone

[Priv.-Doz. Dr. Maria Shinoto]

Hi Jochen,

these are really helpful advices, thank you. I will definitely try the cheapest 
check with the aluminium foil as soon as I can go to the area ;-), but the base 
station - rover or separate antenna solution seems to become a solution that 
needs a bit of testing, will have to apply for the money first. 

As for the total station, yes, we are starting from a ground point and create 
low level ground points walking up the valleys at the moment; but we have to 
consider measurement errors increasing. 

Thanks again, I think I got a lot of really useful input, 
Maria


> Am 28.05.2020 um 14:25 schrieb j.hu...@post-ist-da.de:
> 
> Hi Maria,
> 
> the position of the base station at the entrance of the valley sounds
> good. Before you invest a lot of money, you could rent a system and try
> it out in the field. Most local dealers should have devices available
> for rent or tests.
> 
> The problem with wet conditions could have to do with multipathing
> effects. Probably a choke ring antenna will be better in these
> conditions. You could try an experiment: Put your GPS in a flat box
> which is covered with some conductive material (eg aluminium foil) so
> that it only "sees" signals from above (the visible sky), not from below
> or the lower sides. See if this changes the resulting accuracy.
> 
> Using a GPS antenna mounted on a pole has the advantage that your body
> does not obstruct parts of the visible sky. When measuring near a steep
> slope, be sure to stand on the side of the slope where the GPS can't
> "see" the sky anyway. I know surveyors who use very long poles (like
> 3-4m) to position the antenna above the lower layer of vegetation. You
> get errors due to the lack of verticality but much better reception.
> 
> You can't expect to get cm accuracy in the conditions you describe, at
> least not with short-time measurements. For this you need phase tracking
> which is very sensitive even to short obstructions of a satellite signal
> (canopy).
> 
> Unfortunately it sound like you don't have sight contact on ground level
> either, so a GPS base station as a reference and a total station for
> measuring the individual points won't be an option.
> 
> Regards
> Jochen
> 
> 
> 
> Am 28.05.20 um 01:53 schrieb Priv.-Doz. Dr. Maria Shinoto:
>> Hi fellow archaeologists ;-), 
>> 
>> there is so much precious information in this thread. 
>> 
>> Now one question about precision and accuracy: As I said, we work in a 
>> densely forested area, there is not just the canopy of the trees, but two to 
>> three levels below with dense ground cover and bamboo walls. Still, we get 
>> excellent (precise) results with consumer level handhelds and smartphones. 
>> But the accuracy is not good under certain conditions: Water and muddy 
>> ground seems to be an obstacle for GPS as well as the steep slopes. We get 
>> very precise results in certain places, but they are in certain cases 
>> several meters apart from the "real" place -- which we can test with the 
>> LiDAR DTM. Dry underground and measurement about 10m apart from the slopes 
>> result in accurate positions, but any measurement point closer to the slopes 
>> leads to a consistent error in the measurement -- across devices. 
>> 
>> I still wonder whether these conditions are suitable for any GPS technology 
>> or whether working with a fixed station and a rover would be OK. I could 
>> then think of positioning the station at the entrance of the valley and 
>> walking up narrowing valley with the rover.
>> 
>> Best, 
>> Maria
>> 
>> 
>>> Am 28.05.2020 um 02:17 schrieb Nicolas Cadieux 
>>> :
>>> 
>>> Hi Garth,
>>> 
>>> I am also an archaeologist.  We use a single Sxblue 2 from GENEQ.  The unit 
>>> was upgraded by the company so it’s takes in the Russian constellation now. 
>>>  The unit is very precise. When we go out on the field, we let le unit run 
>>> one a Bench mark for a few hours.  We then process that position  In PPP or 
>>> using nrcan gps tower if we are close to one.  The company give a really 
>>> good service helping with both software support and hardware.  As 
>>> everything in made and designed in Québec, they can take the unit appart 
>>> and change individual parts and chips.  We did that one as the Bluetooth 
>>> chip was now longer capable of working with Windows 10 (more likely the 
>>> other way around). It had been Made for Windows 95.  For a few extra bucks, 
>>> they changed the gps chip also.  The unit is basically a brick (Square and 
>>> heavy) that connects to an external device

Re: [Qgis-user] wishing for accurate lattitude/longitude from, a cell phone

[Priv.-Doz. Dr. Maria Shinoto]

Hi fellow archaeologists ;-), 

there is so much precious information in this thread. 

Now one question about precision and accuracy: As I said, we work in a densely 
forested area, there is not just the canopy of the trees, but two to three 
levels below with dense ground cover and bamboo walls. Still, we get excellent 
(precise) results with consumer level handhelds and smartphones. But the 
accuracy is not good under certain conditions: Water and muddy ground seems to 
be an obstacle for GPS as well as the steep slopes. We get very precise results 
in certain places, but they are in certain cases several meters apart from the 
"real" place -- which we can test with the LiDAR DTM. Dry underground and 
measurement about 10m apart from the slopes result in accurate positions, but 
any measurement point closer to the slopes leads to a consistent error in the 
measurement -- across devices. 

I still wonder whether these conditions are suitable for any GPS technology or 
whether working with a fixed station and a rover would be OK. I could then 
think of positioning the station at the entrance of the valley and walking up 
narrowing valley with the rover.

Best, 
Maria


> Am 28.05.2020 um 02:17 schrieb Nicolas Cadieux :
> 
> Hi Garth,
> 
> I am also an archaeologist.  We use a single Sxblue 2 from GENEQ.  The unit 
> was upgraded by the company so it’s takes in the Russian constellation now.  
> The unit is very precise. When we go out on the field, we let le unit run one 
> a Bench mark for a few hours.  We then process that position  In PPP or using 
> nrcan gps tower if we are close to one.  The company give a really good 
> service helping with both software support and hardware.  As everything in 
> made and designed in Québec, they can take the unit appart and change 
> individual parts and chips.  We did that one as the Bluetooth chip was now 
> longer capable of working with Windows 10 (more likely the other way around). 
> It had been Made for Windows 95.  For a few extra bucks, they changed the gps 
> chip also.  The unit is basically a brick (Square and heavy) that connects to 
> an external device like a laptop or a tablet.  No screens or anywhere fancy.
> 
> https://geneq.com/land-surveying-geomatics/fr/fabricant/sxblue
> 
> Nicolas Cadieux
> Ça va bien aller!
> 
>> Le 27 mai 2020 à 11:19, QGIS.USER  a écrit :
>> 
>> Hi Garth,
>>Thank you for the correction and the additional information. Much 
>> appreciated.
>> 
>> My current thinking is that in the archaeology we do, the intra-site 
>> (relative) measurements are quite good but what is inaccurate is the 
>> absolute measurements. We can set out our grids with cm accuracy but can 
>> only locate them on the ground with 10s of metre accuracy. It would be good 
>> to have a low cost way of establishing the absolute position even if that 
>> took time and/or was off-line.
>> 
>> Ray Carpenter,
>> Chapel Archaeology
>> 
>> -Original Message-
>> From: Garth Fletcher [mailto:ga...@jacqcad.com] 
>> Sent: 27 May 2020 15:25
>> To: QGIS.USER; qgis-user@lists.osgeo.org
>> Subject: Re: [Qgis-user] wishing for accurate lattitude/longitude from, a 
>> cell phone
>> 
>> Hi Ray,
>> 
>> Apologies for the typo - I had typed iGS3, but iG3s is the right number.
>> 
>> iGage 
>> 
>>  iG3s, now replaced by the iG4 which adds Galileo
>> tracking but otherwise seems very similar to the iG3s. $2400 US.
>> 
>> These track satellites from the US GPS, Russian GLONASS, Chinese BeiDou
>> and, with the iG4, European Galileo constellations.
>> 
>> Their sole function is to record from all the satellites they can track.
>> 
>> They produce a RINEX format file which can be sent to a post processing
>> service such as Canada's Geodetic Surveys' CSRS-PPP:
>> 
>> 
>> The longer the observation (recording) duration, the better CSRS-PPP can
>> converge to an accurate location.  In my experience in New Hampshire's
>> heavily wooded environment, a 30 to 45 minute observation time generally
>> gets me to better than ± 1 meter accuracy.  Yesterday a 6 hour long
>> observation in a small field surrounded by forest converged to within 1
>> inch.  Dense forest canopy reduces the number of satellites that can be
>> tracked. Also, some times of day are better than others in terms of the
>> number of satellites and their geometry, see:
>>   
>> 
>> The iG3s was perfect for my specific conditions, but I think it is not
>> optimal where many locations within a site must be accurately me
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: 

Re: [Qgis-user] wishing for accurate lattitude/longitude from a cell phone

[Priv.-Doz. Dr. Maria Shinoto]

g certain apps to average points.
>>>>>>> 
>>>>>>> Where are my quadrats? Positional accuracy in fieldwork - Dodd - 2011 - 
>>>>>>> Methods in Ecology and Evolution - Wiley Online Library
>>>>>>> Introduction. There has been much written about sampling design, 
>>>>>>> spatial scale and the need for permanent plots in ecological long‐term 
>>>>>>> monitoring, for example, the paper on spatial scaling in ecology has 
>>>>>>> been cited over 1500 times, but one frequently ignored issue, 
>>>>>>> intimately associated with sampling design, scale and permanence of 
>>>>>>> plots, is how to locate positions accurately.
>>>>>>> besjournals.onlinelibrary.wiley.com
>>>>>>> 
>>>>>>> From: Qgis-user  on behalf of 
>>>>>>> Nicolas Cadieux 
>>>>>>> Sent: 23 May 2020 16:34
>>>>>>> To: Randal Hale 
>>>>>>> Cc: qgis-user@lists.osgeo.org 
>>>>>>> Subject: Re: [Qgis-user] wishing for accurate lattitude/longitude from 
>>>>>>> a cell phone
>>>>>>>  
>>>>>>> CAUTION: This mail comes from outside the University. Please consider 
>>>>>>> this before opening attachments, clicking links, or acting on the 
>>>>>>> content.
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> This is a very interesting list. It basically confirms what I thought. 
>>>>>>> Consumer Point and shoot deceives are all around 2-6m with no canopy. 
>>>>>>> The average multiple positions basically give you a better idea as a 
>>>>>>> gps may get lucky.  It would be nice to have the full methodology for 
>>>>>>> this and more data (like the number of satellite and the position of 
>>>>>>> the constellation and the gps price list) but it’s very interesting 
>>>>>>> none the less.  I was also happy that the data confirms the precision 
>>>>>>> of the gps Sx-Blue 11. This claims to be sub meter and my tests 
>>>>>>> indicated that on our office unit but it’s nice to see it done 
>>>>>>> elsewhere.  For about 2000$, this gps is pretty good. As for the rest, 
>>>>>>> the difference between 150$ and 1000$ is probably  more a function of 
>>>>>>> the options (like maps and screen size...) and not a question of 
>>>>>>> precision. It would be nice to know what gps chips they are running...
>>>>>>> 
>>>>>>> Interesting thing also is that based on my reviewing the data on my 
>>>>>>> phone (without graph or cross tabulation tables) is that the Glonas 
>>>>>>> Constellation does not seem to help much.  Quick stats on this list 
>>>>>>> would confirm this. Maybe this is just a figment of my imagination 
>>>>>>> because there’s only so much information you can grad without running 
>>>>>>> proper stats.
>>>>>>> 
>>>>>>> Thanks for the post.
>>>>>>> 
>>>>>>> Nicolas Cadieux
>>>>>>> Ça va bien aller!
>>>>>>> 
>>>>>>> > Le 23 mai 2020 à 09:02, Randal Hale  
>>>>>>> > a écrit :
>>>>>>> >
>>>>>>> > One other thing that may or may not be of use but the USDA Forest 
>>>>>>> > Service Publishes a GPS Receiver Report that covers phones - and 
>>>>>>> > that's helped if I've had a client go "Well I have a Apple 
>>>>>>> >  or a Android ". At least I feel slightly better 
>>>>>>> > going "good enough" or "no not good enough".
>>>>>>> >
>>>>>>> > It should be good worldwide (but I will admit I think phones are my 
>>>>>>> > 'tech ceiling' these days) but your mileage may vary.
>>>>>>> >
>>>>>>> > https://www.fs.fed.us/database/gps/mtdcrept/accuracy/index.htm
>>>>>>> >
>>>>>>> > Randy
>>>>>>> >
>>>>>>> >> On 5/22/20 8:55 PM, Priv.-Doz. Dr. Maria Shinoto wrote:
>>>>>>> >> Somehow I did not follow th

Re: [Qgis-user] wishing for accurate lattitude/longitude from a cell phone

[Priv.-Doz. Dr. Maria Shinoto]

This discussion is interesting and very helpful. 

Some remarks from our experiences in a densely forested region with narrow 
valleys and steep slopes, lots of water floating in creeks and abandoned rice 
paddies -- water all around. 


ANTENNA: 
The antenna of Garmin 64 is a lot quicker in receiving signals than that of the 
<100$ Garmin etrex10, but it was not more precise, just a lot quicker, which 
may be due to the chips inside rather than the antenna. The Garmin Oregon, 
which has an antenna similar to the etrex10 was a quick as the 64. We did not 
try smartphones, but a colleague who is doing similar research told us that he 
uses the Oregon and an iPhone with similar results. Therefore, it seems that 
Garmin handhelds are really not necessary. 

SATELLITES:
We receive GLONASS and GPS, max is about 18 satellites, but this gives good 
results where the conditions are good. 

AVERAGE AND LOCATION:
We got very good experiences with averaging. This means, I just measured 
shortly until I got enough satellites and measured after a period of at least 
two hours again. I repeated this on different times on other days, but after 
all, the measurements concentrated in less than one meter, the precision of the 
average as compared to the LiDAR data being under 40cm. 
We had equally "precise" measurements at places beneath slopes and with lots of 
water floating around, but the precision was in the wrong place, about 5 to 10 
meters apart from where it should be. These are, as we were told, systematical 
errors that cannot be overcome, by any GPS.

COMBINATION
Solutions like the https://emlid.com/reachrs/ mentioned in this thread seem to 
help with at lest two receivers working. Can anybody report whether it helps to 
place the base station in a location far from the slopes and the waters of the 
broken paddy fields or creeks and then walk around with the second receiver to 
measure places down at the slopes?

Maria






> Am 24.05.2020 um 04:51 schrieb Garth Fletcher :
> 
> I got involved in a project to locate the actual boundary monuments 
> which delimit our town.  The USGS 7.5' topographic maps appeared to be 
> in error at some locations by several hundred feet.  About 30 monument 
> locations were involved.
> 
> We are in rural NH which is mostly wooded, which results in a lot of 
> satellite signal attenuation, i.e., fewer receivable satellites.
> 
> I did a first effort using a Garmin eTrex 20 (~ $200) which received 
> both the US GPS satellites and the Russian GLONASS satellites. Receiving 
> both is important in our high attenuation environment because it 
> significantly increases the number of receivable satellites.
> 
> Those measurements supported my suspicions about topo errors, but had 
> error bounds in the tens of meters - not accurate enough for my purpose.
> 
> Next I used a Bad Elf Surveyor (~ $600 + Mac iPad) to record 30 minutes 
> of data into RINEX files which were then sent to CSRS-PPP for 
> post-processing.  This somewhat reduced the error bounds, but they were 
> still ~10 meters wide, even for some 60 minute recordings.
> 
> 
> Finally I used an iGage iGS3 receiver (~ $2400) to record US GPS and 
> GLONASS satellites for at least 30 minutes each (up to 1 hour under 
> heavy foliage) into RINEX files sent for post-processing to CSRS-PPP. 
> This approach finally realized the ±1 meter with 95% probability I needed.
> 
> A graph of the error ellipses for the 30 monuments as predicted by 
> CSRS-PPP post-processing, shown on a 1 foot grid, can be seen here:
> 
> Note that almost all are within ± 2 feet.
> 
> 
> GPS satellites broadcast on two frequencies, L1 and L5. A key difference 
> is that the hand-held Garmin units and the Bad Elf Surveyor only use the 
> L1 frequency whereas the iGS3 is a dual frequency receiver (L1 and L5).
> 
> One large source of errors is the variable signal propagation delays in 
> the ionosphere, which have predictable differences between the L1 and L5 
> frequencies. Recording both signals allows a better estimation of, and 
> correction for, the ionospheric delays.
> 
> A word about post-processing.
> 
> I use the Canadian Geodetic Survey's CSRS-PPP processing because they 
> accept data from both US GPS and Russian GLONASS satellites whereas the 
> US Geodetic Survey's OPUS only accepts US GPS satellite data.  In our 
> heavily wooded environment the ability to use both constellations of 
> satellites provides a crucial boost in performance.
> 
> Post-processing services continuously record L1/L5 signals from hundreds 
> of fixed sites.  This allows them to accurately model the time-changing 
> errors in GPS signals, primarily ionospheric delays but also errors in 
> the satellite orbits and their clocks.
> 
> When RINEX data is submitted, the service can look at its 
> contemporaneous data from fixed receivers to model the errors at the 
> time and location of the RINEX recording 

Re: [Qgis-user] wishing for accurate lattitude/longitude from a cell phone

[Priv.-Doz. Dr. Maria Shinoto]

Somehow I did not follow the discussion, but like to add some of our 
experience. 

We are doing field work in a remote region in the southern Japanese mountains, 
archaeological surveys on the ground based on LiDAR data. 

A simple Garmin etrex10 is mostly reliable in an area of 40cm by 40cm around a 
measured point, if used repeatedly at this point and the point is located in 
the middle of a valley. Even cell phones do a good enough job. As soon as we 
get closer to the steep slopes, the accuracy of the Garmin is less than 5 to 10 
meters. We can check this with the detailed LiDAR based map, and geologists 
told us, that even an expensive device could not be more precise under these 
conditions. So we decided to measure traditionally on the ground if precise 
measure is necessary, otherwise note the GPS data and the location as shown in 
the map. 

To sum up, we came to the conclusion not to spend money on an expensive GPS 
that may not work in the shadow of steep slopes -- or in the streets of New 
York. -- I appreciate any additional advice, and hope that this experience can 
save Steve's organisation some money...

Best, 
Maria



> Am 23.05.2020 um 03:54 schrieb Stephen Sacks :
> 
> In order to make widely available some wise advice, I'm sending to this list 
> a message I received from Neil B.  In addition to Neil's message below, I 
> want to mention that Nicolas Cadieux also provided similar information, 
> saying I'd have to pay around $1,000 for equipment that gives consistently 
> accurate location coordinates.  And thanks, also to Falk Huettmann and Bernd 
> Vogelgesang for their replies.  
> 
> 
> Message from Neil B:
> 
> Hello Stephen.
> Glad that you're having success. I would like to start off by saying that it 
> is best to always reply to the mailing list and not directly to the person 
> who submitted the email. Mailing lists work really well in that there is a 
> pool of people out there who may be able to offer advice or may have an 
> alternate method to solve the problem that may turn out to be a better way. 
> On the flip side by maintaining the email chain through the mailing list, the 
> follow up emails that provide information are stored in the archives which 
> benefits anyone searching the internet to have the complete trail of 
> information.
> 
> As far as your results they are acceptable for the device you're using. GPS 
> in phones are never built to precision survey standards and there is no 
> reason for them to be. If you're within 30ft of where the phone thinks you 
> should be then you can easily navigate the rest of the way by visual sight. 
> High end equipment to achieve sub-inch accuracy is probably in the range of 
> thousands of dollars. One thing to keep in mind is there is a difference 
> between the accuracy of a device and to what level of precision they display. 
> While the app on the phone may display 8 decimal places of a lat/long 
> coordinate and tell you if you have moved a foot, it doesn't help that the 
> coordinate it is displaying is out +/- 30 feet. The accuracy of a device can 
> also be affected by the environment where the device is being operated. In 
> regards to cell phones, they use multiple sources to determine location such 
> as GPS, cell phone towers, and wifi points to perform the triangulation. Lack 
> of line of sight to satellites, signals from cell towers bouncing off of 
> surrounding buildings, or someone's wireless router using inaccurate position 
> information can all affect the accuracy of what is being displayed on your 
> phone.
> 
> So the question is how are you determining that the coordinates are wrong? If 
> you have information that you trust to be authoritative then adjust your 
> points to those values and carry on. I have no advice or opinions on 
> inexpensive devices that may help with a more accurate reading.
> 
> Please do not respond directly to me. This email account is not actively 
> monitored and I don't always have the time to follow up with the emails. All 
> the best with your endeavours.
> 
> ~Neil B.
> 
> On Fri, May 15, 2020 at 7:52 PM Stephen Sacks  wrote:
> Hi Neil, 
> 
>With your help, I have successfully brought the corners of our gardens 
> back from Pennsylvania to the Promenade here in Brooklyn Heights, New York.  
> Thank you.
>At the risk of wearing out my welcome, I'm now asking for more advice.  My 
> point features are approximately where they should be but not exactly, some 
> points are just a few feet off and some are 10 or even 30 feet off.  I 
> imported the data trying both EPSG 4326 and 4269.
>I'm now convinced that the problem is due to (1) my Google Pixel 3 
> cellphone, (2) the app I'm using ("Latitude Longitude" published by 
> gps-coordinates), and  especially (3) my less-than-steady hands.  I capture 
> coordinates by standing at spot, waiting for the blue dot to settle, and then 
> touching the blue dot.  Often I don't touch the screen at exactly the right 

Re: [Qgis-user] vector point grid to raster grid -- pixel size does not work SOLVED

[Priv.-Doz. Dr. Maria Shinoto]

Hi, 

I had some intensive learning during the last days, and thanks again for your 
help. 

After all it turns out that it is something Nicolas wrote, it is a matter of 
the projection. The Japanese software just exported to a projected format, but 
the original data seem to be in lat long. I found a way to get the unprojected 
data and now can create a beautiful hillshade in an unprojected lat long layer. 
And it even looks good in a projected project (EPSG:6670) with on the fly 
projection. 

For hydrological analyses I need to use the projected data, but the artifacts 
do not matter here. While binge-watching YouTube videos I realized that these 
artifacts occur with the pros as well when they use the projected layers for 
their analyses. Now everything much better and "in place".

Best, 
Maria


> Am 15.05.2020 um 13:21 schrieb Nicolas Cadieux :
> 
> 
> 
> Nicolas Cadieux
> Ça va bien aller!
> 
>> Le 14 mai 2020 à 23:12, Nicolas Cadieux  a 
>> écrit :
>> 
>> Hi,
>> 
>> 
>> See below for comments.
>> 
>> Nicolas Cadieux
>> Ça va bien aller!
>> 
>>> Le 14 mai 2020 à 22:21, Priv.-Doz. Dr. Maria Shinoto 
>>>  a écrit :
>>> 
>>> Hi again, 
>>> 
>>> and sorry for the ongoing discussion.
>>> 
>>> Today I exported a selection of the DEM data to a shapefile, just 9MB for 
>>> the main file, and this makes testing very fast.
>>> 
>>> (A) TINs did not work. 
>> 
>> TIn interpolation has memory problems with large data sets.  Same problem 
>> since QGIS 2x at least.  It was cool features but is not made to handle 
>> today’s data sets.
>>> 
>>> (B) I tried all steps carefully again, but even the GDAL raster is horrible 
>>> now. 
>>> 
>>> Here are some screenshots with my explanation and the protocol for 
>>> rasterization and filling nodata. 
>>> 
>>> It seems that the artifacts are due to no data fields that evolve during 
>>> rasterization as a pattern. These nodata fields may be due to a slight 
>>> inclination of the grid from the export of the data with the Japanese 
>>> software. 
>>> 
>>> 1) The point grid, one can see the inclination
>>> 
>> <01.jpeg>
>>> 
>>> 
>>> 2) The raster of the same area, one can see the points of the vector point 
>>> grid along the white empty space; this is NODATA.
>>> 
>> <02.jpeg>
>>> 
>>> 
>> I would use gdal_grid not rasterize. Use Gdal grid with a larger search 
>> circle will solve this problem.  Use nearest neighborhood with a search 
>> radius larger than the pixel (like 7m).  That will reduce the no data. Click 
>> on the help or go to the gdal website. That will help you add the missing 
>> parameters like the -txe and -tye. (The extent) and the -outsize for the 
>> number of pixels. 
>> 
>>> I add the protocol
>> <2020-05-15-rasterize-protocol-for-selection.txt>
>>> 
>>> 
>>> 
>>> 3) Using the Fill NODATA from the Raster menu makes a beautiful looking 
>>> raster, there seem to be no flaws.
>>> 
>> <03.jpeg>
>>> 
>>> 
>> 
>> That fixes things but adds new data to the raster. This may be unwanted.
>> 
>>> I add the protocol.
>>> 
>> <2020-05-15-fill-nodata-protocol-for-selection.txt>
>>> 
>>> 
>>> 4) This is the same area as in (3), but instead of a pseudocolor ramp shown 
>>> as hillshade.
>>> 
>> <04.jpeg>
>>> 
>>> 
>> This is normal if you select a bad z factor (probably not the case here).  
>> You will have the same thing if you zoom in and have nearest neighbour in 
>> the “zoomed in” under “resampling“ in the hillshade symbology window.
>>> 
>>> 5) This is the impression from a larger area.
>>> 
>> <05.jpeg>
>>> 
>>> 
>>> 
>>> 6) This is the same small area hillshaded with the GDAL tools. Looks good, 
>>> but suffers from the same artifacts. 
>>> 
>> 
>> No this is way it should look like (Image under).  You can see the pixels 
>> because you are zoomed in.  Again, select the correct z factor (if x,y are 
>> in long -lat and z is in meters or feet.) (probably ok here).
>> 
>> <06.jpeg>
>>> 
>>> 
>>> 
>> Play with the resampling zoomed out parameters in symbology 
>> 
>> 
>>> 7) The larger area from hillshade in GDAL tools. 
>>> 
>> <07.jpeg>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> I sorry to be so insisting on the problem, I think it is not the problem of 
>>> QGIS, but perhaps there are solutions to such a case. -- The projection is 
>>> OK, and the base map fits perfectly. 
>>> 
>>> Best and Thanks to anyone trying to help, 
>>> Maria
>>> 
>>> 
>>> 
>>> 

___
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 point grid to raster grid -- pixel size does not work

[Priv.-Doz. Dr. Maria Shinoto]

Hi, 

I am testing the GDAL tools the way you explained, but I still get artifacts. 
When I say artifacts, I do not mean pixels, I know what pixels are since I 
started using a scanner nearly 30 years ago, I think of sudden jumps in the 
lightness, which leads to lines and grids in the raster image. Now I am 
checking more options, I am working on it and will be back in a day or two. 
Meanwhile, if you have an idea, I will be happy to read about it. 

Best, 
Maria


> Am 15.05.2020 um 13:21 schrieb Nicolas Cadieux :
> 
> 

___
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] Hillshade as layer property vs. Processing Toolbox GDAL hillshade

[Priv.-Doz. Dr. Maria Shinoto]

O no! Everybody who cares is most welcome!  :-))

> Am 15.05.2020 um 09:02 schrieb Alexandre Neto :
> 
> Ah, sorry. I misread it. :-)
> 
> A quinta, 14/05/2020, 23:43, Priv.-Doz. Dr. Maria Shinoto 
>  escreveu:
> Dear Alexander, 
> 
> Thank you for looking into it. As I said, there is no projection on the fly, 
> my layer and the file are in EPSG:6670, as is the project. 
> 
> I will try with a selection from the large layer today!.
> 
> Best, 
> Maria
> 
> 
> > Am 14.05.2020 um 23:15 schrieb Alexandre Neto :
> > 
> > If the project is in one CRS, and the layer is in another, then the raster 
> > is transformed on-the-fly for sure.
> > 
> > Give it a try.
> > 
> > A quinta, 14/05/2020, 08:47, Priv.-Doz. Dr. Maria Shinoto 
> >  escreveu:
> > Hi, 
> > 
> > > So the problem occurs only when creating a Hillshade, from a DEM, using 
> > > the hillshade symbology?  
> > 
> > well, I did not try hillshade in any other case yet, so, yes.
> > 
> > > Have you chosen the correct a factor value?  
> > 
> > What is that? Perhaps there is something I miss?
> > 
> > > Try to use the same projection in the project and in the layer so that 
> > > you have no reprojection going on.
> > 
> > The project is set to EPSG:6670, and the Raster layer is not projected on 
> > the fly, but from a file that is in EPSG:6670. So I think, reprojection is 
> > not the problem here. 
> > 
> > Thanks for checking this up, if you have an explanation about the factor 
> > value, that might help. 
> > 
> > Best, 
> > Maria Shinoto
> > 
> > > 
> > > Nicolas Cadieux
> > > Ça va bien aller!
> > > 
> > >> Le 13 mai 2020 à 04:31, Priv.-Doz. Dr. Maria Shinoto 
> > >>  a écrit :
> > >> 
> > >>  Hi, 
> > >> 
> > >> Today I tried making a hillshade from the raster data you helped me out 
> > >> today -- after filling empty pixels, everything looks great. 
> > >> 
> > >> Now, when trying to set the layer symbology to hillshade, I got 
> > >> artifacts with the default setting and the recommend bilinear with 
> > >> medium. Looking for a solution, I found this conservation about the same 
> > >> issue (I think) from about 3 years ago; it seems to be a problem still 
> > >> today (working with QGIS 3.12).
> > >> 
> > >>   https://github.com/qgis/QGIS/issues/23859
> > >> 
> > >> So I tried the hillshade tool from GDAL in the Processing toolbox with 
> > >> identical setting, and everything looks great. 
> > >> 
> > >> I think that the flawed hillshade in the easily accessible Symbology 
> > >> dialogue needs some work or a hint to the GDAL tool in the Processing 
> > >> toolbox. It is frustrating for someone who is new.
> > >> 
> > >> I add screenshots from the bad results in the Properties > Symbology 
> > >> dialogue and the raster image from which I started. 
> > >> 
> > >> Anyway, it was great to have a solution easily at hand ;-)
> > >> 
> > >> Best,
> > >> Maria
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> ___
> > >> 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] Hillshade as layer property vs. Processing Toolbox GDAL hillshade

[Priv.-Doz. Dr. Maria Shinoto]

Dear Alexander, 

Thank you for looking into it. As I said, there is no projection on the fly, my 
layer and the file are in EPSG:6670, as is the project. 

I will try with a selection from the large layer today!.

Best, 
Maria


> Am 14.05.2020 um 23:15 schrieb Alexandre Neto :
> 
> If the project is in one CRS, and the layer is in another, then the raster is 
> transformed on-the-fly for sure.
> 
> Give it a try.
> 
> A quinta, 14/05/2020, 08:47, Priv.-Doz. Dr. Maria Shinoto 
>  escreveu:
> Hi, 
> 
> > So the problem occurs only when creating a Hillshade, from a DEM, using the 
> > hillshade symbology?  
> 
> well, I did not try hillshade in any other case yet, so, yes.
> 
> > Have you chosen the correct a factor value?  
> 
> What is that? Perhaps there is something I miss?
> 
> > Try to use the same projection in the project and in the layer so that you 
> > have no reprojection going on.
> 
> The project is set to EPSG:6670, and the Raster layer is not projected on the 
> fly, but from a file that is in EPSG:6670. So I think, reprojection is not 
> the problem here. 
> 
> Thanks for checking this up, if you have an explanation about the factor 
> value, that might help. 
> 
> Best, 
> Maria Shinoto
> 
> > 
> > Nicolas Cadieux
> > Ça va bien aller!
> > 
> >> Le 13 mai 2020 à 04:31, Priv.-Doz. Dr. Maria Shinoto 
> >>  a écrit :
> >> 
> >>  Hi, 
> >> 
> >> Today I tried making a hillshade from the raster data you helped me out 
> >> today -- after filling empty pixels, everything looks great. 
> >> 
> >> Now, when trying to set the layer symbology to hillshade, I got artifacts 
> >> with the default setting and the recommend bilinear with medium. Looking 
> >> for a solution, I found this conservation about the same issue (I think) 
> >> from about 3 years ago; it seems to be a problem still today (working with 
> >> QGIS 3.12).
> >> 
> >>   https://github.com/qgis/QGIS/issues/23859
> >> 
> >> So I tried the hillshade tool from GDAL in the Processing toolbox with 
> >> identical setting, and everything looks great. 
> >> 
> >> I think that the flawed hillshade in the easily accessible Symbology 
> >> dialogue needs some work or a hint to the GDAL tool in the Processing 
> >> toolbox. It is frustrating for someone who is new.
> >> 
> >> I add screenshots from the bad results in the Properties > Symbology 
> >> dialogue and the raster image from which I started. 
> >> 
> >> Anyway, it was great to have a solution easily at hand ;-)
> >> 
> >> Best,
> >> Maria
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> ___
> >> 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] vector point grid to raster grid -- pixel size does not work

[Priv.-Doz. Dr. Maria Shinoto]

Hi, 

it seems that my points are too many. I am waiting for the TIN process to 
finish (needs a few hours it seems), then I will select a part of the point I 
am interested in and go on working on that selection. Then I will try your 
suggestions, thank you. 

Some other remarks: 

> You can also correct this 5x5 problem by using gdal grid with Nearest 
> neighbour interpolation. You could use the point data to do this.

So the GDAL tools in the processing toolbox?

> I also post a small presentation that can help go from vector to raster with 
> point data. Sometimes, keeping it simple is better.
> 
> https://www.slideshare.net/shencoop/qgis-raster-to-point

This is the other way round, but I could check that everything went right with 
my .xyz-Data and the creation of the point cloud. 

> If you do decide to make a shapefile with the csv, make sure to store the 
> coordinates in a text field.  Placing the coordinates in a $x and $y object 
> fields will lead to rounding.  Any rounding would corrupt the raster 
> therefore you need to original coordinates for this to work. This may explain 
> your problems also.

I do not really understand, but I think when I try, I will see what you mean. 

> I used this method to change the geoids of a thousands of rasters because the 
> program I was using was designed to change the z value for texte files only 
> and not rasters (NRCAN GPS-H).

Sounds good :-)

I will report tomorrow again, and thanks for taking care, 
Maria


> 
> Nicolas Cadieux
> Ça va bien aller!
> 
>> Le 13 mai 2020 à 11:25, chris hermansen  a écrit :
>> 
>> 
>> Maria and list,
>> 
>> On Tue, May 12, 2020 at 7:00 PM Priv.-Doz. Dr. Maria Shinoto 
>>  wrote:
>> Hi, 
>> 
>> Thanks for helping. -- Thanks to you and Chris Hermansen I got a result, but 
>> it could be better. 
>> 
>> For the records, a short explanation:
>> 
>> *
>> Well, I checked the properties, jgd2011 is in Meters, the raster is said to 
>> be 5m. In the official Japanese viewer, which creates a beautiful raster 
>> image without white pixels, the pixels are exactly 5m*5m. 
>> 
>> Today I tried the export to .xyz since the shapefile looked ugly, and after 
>> realising that the Japanese xyz is indeed yxz, everything looked fine, and I 
>> could store it in a Geopackage. But the grid is now 5,276m * 6,146m. But it 
>> fits well on top of the basemap. The basemap is of the same special Japanese 
>> GML format, but QGIS could read it all without problem. I do not understand 
>> why QGIS does not read the point data from  the GML fille, but that is an 
>> aside, I am amazed by what QGIS actually can do. 
>> 
>> From the Geopackage I could rasterize. It is as Chris Hermansen said, 
>> thanks. Unfortunately, I did not get it done from the shapefiles, they 
>> always looked weird or like nothing, even with identical settings. But the 
>> geopackages from xyz tiles are fine. 
>> 
>> For resolution, I chose georeferenced units as Chris suggested, and since 
>> the measurement tool got some different length, I put it to 5,276m by 
>> 6,146m. A 5m by 5m resolution created a weird layer with horizontally 
>> expanding white pixels.
>> 
>> It seems that tweaking with the resolution might lead to an even better 
>> result, but for the time being, it is OK as it is. 
>> *
>> 
>> 
>> Upon reflection I think the basic problem here is that the point data should 
>> be interpolated to create a raster if you want a precise 5x5m resolution.
>> 
>> For this, rather than use the Raster > Rasterize tool, the approach should 
>> be:
>>  • open the processing toolbox Processing > Toolbox
>>  • in the toolbox open Interpolation > TIN interpolation
>>  • in the TIN Interpolation screen:
>>  • select the Vector layer
>>  • select the Interpolation attribute
>>  • click the + to add to the vector layer panel
>>  • choose the interpolation method - probably best to use cubic
>>  • click on the ... next to extent and set it to the layer extent
>>  • set the pixel size to 5.0 and 5.0
>>  • click Run
>> This way you won't have the odd sizes you mentioned.  This may give you a 
>> smoother surface in the end as well.
>> 
>> 
>> -- 
>> Chris Hermansen · clhermansen "at" gmail "dot" com
>> 
>> C'est ma façon de parler.

___
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] Hillshade as layer property vs. Processing Toolbox GDAL hillshade

[Priv.-Doz. Dr. Maria Shinoto]

Hi, 

> So the problem occurs only when creating a Hillshade, from a DEM, using the 
> hillshade symbology?  

well, I did not try hillshade in any other case yet, so, yes.

> Have you chosen the correct a factor value?  

What is that? Perhaps there is something I miss?

> Try to use the same projection in the project and in the layer so that you 
> have no reprojection going on.

The project is set to EPSG:6670, and the Raster layer is not projected on the 
fly, but from a file that is in EPSG:6670. So I think, reprojection is not the 
problem here. 

Thanks for checking this up, if you have an explanation about the factor value, 
that might help. 

Best, 
Maria Shinoto

> 
> Nicolas Cadieux
> Ça va bien aller!
> 
>> Le 13 mai 2020 à 04:31, Priv.-Doz. Dr. Maria Shinoto 
>>  a écrit :
>> 
>>  Hi, 
>> 
>> Today I tried making a hillshade from the raster data you helped me out 
>> today -- after filling empty pixels, everything looks great. 
>> 
>> Now, when trying to set the layer symbology to hillshade, I got artifacts 
>> with the default setting and the recommend bilinear with medium. Looking for 
>> a solution, I found this conservation about the same issue (I think) from 
>> about 3 years ago; it seems to be a problem still today (working with QGIS 
>> 3.12).
>> 
>>   https://github.com/qgis/QGIS/issues/23859
>> 
>> So I tried the hillshade tool from GDAL in the Processing toolbox with 
>> identical setting, and everything looks great. 
>> 
>> I think that the flawed hillshade in the easily accessible Symbology 
>> dialogue needs some work or a hint to the GDAL tool in the Processing 
>> toolbox. It is frustrating for someone who is new.
>> 
>> I add screenshots from the bad results in the Properties > Symbology 
>> dialogue and the raster image from which I started. 
>> 
>> Anyway, it was great to have a solution easily at hand ;-)
>> 
>> Best,
>> Maria
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] vector point grid to raster grid -- pixel size does not work

[Priv.-Doz. Dr. Maria Shinoto]

Chris, 

Thank you for your ideas. I am trying now, but there are some questions: 

> For this, rather than use the Raster > Rasterize tool, the approach should be:
>   • open the processing toolbox Processing > Toolbox
>   • in the toolbox open Interpolation > TIN interpolation

OK until this point


>   • in the TIN Interpolation screen:
>   • select the Vector layer

OK. 

>   • select the Interpolation attribute

First problem: I stored the vector layer in a Geopackage; so I have an fid from 
the geopackage database, an ID from the original xyz-File in field_1, and the 
x, y, z values in field_2, _3 and _4. 

Which attribute should I choose?  I think only field_2 and field_3?

There is a checkbox for the Z-coordinate, whether I with to use it for 
interpolation. I guess I leave unchecked?

>   • click the + to add to the vector layer panel

So I added the two fields, they are "Points"

>   • choose the interpolation method - probably best to use cubic
>   • click on the ... next to extent and set it to the layer extent

OK

>   • set the pixel size to 5.0 and 5.0

OK

>   • click Run

OK

> This way you won't have the odd sizes you mentioned.  This may give you a 
> smoother surface in the end as well.

I started the prozess, but with more than 11 Million points, it seems to take 
too long, I am stuck at 50%. Will try later again.

Best, 
Maria


> 
> 
> -- 
> Chris Hermansen · clhermansen "at" gmail "dot" com
> 
> C'est ma façon de parler.
___
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] Hillshade as layer property vs. Processing Toolbox GDAL hillshade

[Priv.-Doz. Dr. Maria Shinoto]

Hi,

Today I tried making a hillshade from the raster data you helped me out today 
-- after filling empty pixels, everything looks great.

Now, when trying to set the layer symbology to hillshade, I got artifacts with 
the default setting and the recommend bilinear with medium. Looking for a 
solution, I found this conservation about the same issue (I think) from about 3 
years ago; it seems to be a problem still today (working with QGIS 3.12).

   https://github.com/qgis/QGIS/issues/23859

So I tried the hillshade tool from GDAL in the Processing toolbox with 
identical setting, and everything looks great.

I think that the flawed hillshade in the easily accessible Symbology dialogue 
needs some work or a hint to the GDAL tool in the Processing toolbox. It is 
frustrating for someone who is new.

I add screenshots from the bad results in the Properties > Symbology dialogue 
and the raster image from which I started.

Anyway, it was great to have a solution easily at hand ;-)

Best,
Maria


[cid:087C3227-BD35-4041-B747-B03774EF0B18]

[cid:DAEEFDBE-93EA-43F0-A90E-4A2D40F6CC92]

[cid:651683BC-6B12-45EE-B43C-2E5F6E442A71]





___
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 point grid to raster grid -- pixel size does not work

[Priv.-Doz. Dr. Maria Shinoto]

Chris, 

Thanks for helping me out. Your detailed explanation was really helpful. I 
could not have done without it, thanks for taking so much time. 

A short memo about what I did is in my answer to Nicolas Cadieux. 

Best, 
Maria


> Am 13.05.2020 um 01:36 schrieb chris hermansen :
> 
> Maria and list,
> 
> On Tue, May 12, 2020 at 4:24 AM Priv.-Doz. Dr. Maria Shinoto 
>  wrote:
> Hi, 
> 
> I am having problems to set up the parameters for Raster > Convert > 
> Rasterize Vector to Raster
> 
> My basic map is JGD2011 / Japan Plnae Rectangular CS II, and I downloaded an 
> xml file JPGIS/GML format, that had to be converted to shapefile in a special 
> application. 
> 
> So according to this https://epsg.io/30162 that projection is:
> Coordinate system: Cartesian 2D CS. Axes: northing, easting (X,Y). 
> Orientations: north, east. UoM: m.
> 
> 
> 
> 
> Now I have the points as a grid with approximately 5m distance and want to 
> convert them to Raster, since this is what I want to use as DEM for analyses. 
> 
> Everything works, but the pixel are extremely largen, not 5m.
> 
> I set the units to pixel, and since it is 5m mesh (from 0.2 seconds), I was 
> told to use 0.56 for horizontal and vertical resolution, but I do not 
> know what I am doing there, and I do not find any similar application in 
> tutorials, handbooks and books, the options in QGIS documentation do not 
> really help. 
> 
> This sounds completely incorrect to me.  I believe you should specifically 
> set the following on your Rasterize (Vector to Raster) dialogue:
> 
> Output raster size units: Georeferenced units
> 
> Width/Horizontal resolution: 5.0
> 
> Height/Vertical resolution: 5.0
> 
> Output extent -> use canvas extent
> 
> 
> Can anybody guide me to the correct value? Or to another flaw in my thinking?
> 
> 
> Since your input point data is in a cartesian (ie x-y) projection and in 
> metres (apparently with Tokyo as its zero point), and since you want your 
> output raster in metres in the same reference system, there is no need to be 
> thinking about how many seconds correspond to metres at your latitude, nor 
> pixels, nor anything like that.
> 
> If you refer to the link above describing the Japan Plane Regular CS II 
> projection, you will see it is based on the Bessel 1841 spheroid.  It may be 
> useful for you to set your project properties before doing the vector to 
> raster conversion.
> 
> Select Project > Properties > CRS, then use the filter to find Tokyo / Japan 
> Plane Rectangular CS II EPSG:30162  Select that coordinate reference system 
> and click Apply.  The menu should look like this:
> 
> 
> 
> 
> -- 
> Chris Hermansen · clhermansen "at" gmail "dot" com
> 
> C'est ma façon de parler.

___
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 point grid to raster grid -- pixel size does not work

[Priv.-Doz. Dr. Maria Shinoto]

Hi, 

Thanks for helping. -- Thanks to you and Chris Hermansen I got a result, but it 
could be better. 

For the records, a short explanation:

*
Well, I checked the properties, jgd2011 is in Meters, the raster is said to be 
5m. In the official Japanese viewer, which creates a beautiful raster image 
without white pixels, the pixels are exactly 5m*5m. 

Today I tried the export to .xyz since the shapefile looked ugly, and after 
realising that the Japanese xyz is indeed yxz, everything looked fine, and I 
could store it in a Geopackage. But the grid is now 5,276m * 6,146m. But it 
fits well on top of the basemap. The basemap is of the same special Japanese 
GML format, but QGIS could read it all without problem. I do not understand why 
QGIS does not read the point data from  the GML fille, but that is an aside, I 
am amazed by what QGIS actually can do. 

From the Geopackage I could rasterize. It is as Chris Hermansen said, thanks. 
Unfortunately, I did not get it done from the shapefiles, they always looked 
weird or like nothing, even with identical settings. But the geopackages from 
xyz tiles are fine. 

For resolution, I chose georeferenced units as Chris suggested, and since the 
measurement tool got some different length, I put it to 5,276m by 6,146m. A 5m 
by 5m resolution created a weird layer with horizontally expanding white pixels.

It seems that tweaking with the resolution might lead to an even better result, 
but for the time being, it is OK as it is. 
*

Thanks again, 
Maria






> Am 13.05.2020 um 00:12 schrieb Nicolas Cadieux :
> 
> Hi,
> 
> What is the resolution of the jgd20011 raster?  Look in the layer properties. 
>  Once you are done, use a base map, like something from the quickmap plugin 
> and check the results and the georeferencing.  Pixels will be big if you zoom 
> on them.
> 
> Nicolas Cadieux
> Ça va bien aller!
> 
>> Le 12 mai 2020 à 07:24, Priv.-Doz. Dr. Maria Shinoto 
>>  a écrit :
>> 
>> Hi, 
>> 
>> I am having problems to set up the parameters for Raster > Convert > 
>> Rasterize Vector to Raster
>> 
>> My basic map is JGD2011 / Japan Plnae Rectangular CS II, and I downloaded an 
>> xml file JPGIS/GML format, that had to be converted to shapefile in a 
>> special application. 
>> 
>> Now I have the points as a grid with approximately 5m distance and want to 
>> convert them to Raster, since this is what I want to use as DEM for 
>> analyses. 
>> 
>> Everything works, but the pixel are extremely largen, not 5m.
>> 
>> I set the units to pixel, and since it is 5m mesh (from 0.2 seconds), I was 
>> told to use 0.56 for horizontal and vertical resolution, but I do not 
>> know what I am doing there, and I do not find any similar application in 
>> tutorials, handbooks and books, the options in QGIS documentation do not 
>> really help. 
>> 
>> Can anybody guide me to the correct value? Or to another flaw in my 
>> thinking? 
>> 
>> Thanks a lot, 
>> Maria
>> 
>> ___
>> 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 point grid to raster grid -- pixel size does not work

[Priv.-Doz. Dr. Maria Shinoto]

Hi, 

I am having problems to set up the parameters for Raster > Convert > Rasterize 
Vector to Raster

My basic map is JGD2011 / Japan Plnae Rectangular CS II, and I downloaded an 
xml file JPGIS/GML format, that had to be converted to shapefile in a special 
application. 

Now I have the points as a grid with approximately 5m distance and want to 
convert them to Raster, since this is what I want to use as DEM for analyses. 

Everything works, but the pixel are extremely largen, not 5m.

I set the units to pixel, and since it is 5m mesh (from 0.2 seconds), I was 
told to use 0.56 for horizontal and vertical resolution, but I do not know 
what I am doing there, and I do not find any similar application in tutorials, 
handbooks and books, the options in QGIS documentation do not really help. 

Can anybody guide me to the correct value? Or to another flaw in my thinking? 

Thanks a lot, 
Maria

___
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] Current status: multiple versions on Mac

[Priv.-Doz. Dr. Maria Shinoto]

Hi, 

same here, I am running QGIS 3.4 and 3.10 parallel on Mac OS X 10.15 Catalina 
without any problem. 

Was way better than upgrading from 2.18 to 3.4. 

Best, 
Maria


> Am 06.05.2020 um 01:03 schrieb Peter Petrik 
> :
> 
> Hi, 
> 
> if you use official installer, it creates you different directories for 
> different versions (e.g. /Applications/QGIS3.10, /Applications/QGIS3.12). I 
> have multiple version side-by-side without any problem.
> 
> Kind regards,
> Peter
> 
> On Tue, May 5, 2020 at 5:29 PM Chris  wrote:
> Dear Qgis-user List
> 
> I'm trying to get a project-team all on the same, new version of QGIS 
> LTR (3.10). With windows it's fairly easy to install multiple versions 
> of QGIS, so no discussions there. One user however is on Mac (10.12.6 
> MacOS Sierra). He says it's not possible for him to install multiple 
> parallel versions. For fear of breaking current projects he's reluctant 
> to upgrade.
> 
> I've tried to search forums & this news-list archive, but could not find 
> any recent disussion on that topic.
> 
> Could someone provide me with an update on that topic please? Is it 
> currently easy to have multiple versions of QGIS installed on the same 
> mac, as on windows, or is that still not possible?
> 
> Many thanks!
> Chris
> 
> ___
> 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] CRS Issue

[Priv.-Doz. Dr. Maria Shinoto]

Great, I just opened this issue on github: 

CRS problems: EPSG code not correctly applied in QGIS 3.4 #35395

It is the first ticket that I open at github, if anything went wrong, please 
tell me. 

Best, 
Maria


> Am 27.03.2020 um 09:18 schrieb Nyall Dawson :
> 
> On Fri, 27 Mar 2020 at 09:54, Priv.-Doz. Dr. Maria Shinoto
>  wrote:
>> 
>> Thank you for looking into this. It seems to be related to the CRS problems 
>> I reported twice in the last weeks; here I get a non existent EPSG instead 
>> of the correct 6670; the name (2011 Plane Rectangular II -- for Kyūshū) is 
>> correct though.
>> 
>> If you need material, please tell me.
> 
> Can you open a ticket on
> https://github.com/qgis/QGIS/issues with a sample dataset which shows
> this issue?
> 
>> 
>> Maria
>> 
>> 
>>> Am 27.03.2020 um 07:07 schrieb Nyall Dawson :
>>> 
>>> On Fri, 27 Mar 2020 at 04:33, Tyler Veinot  wrote:
>>>> 
>>>> All;
>>>> For some reason my QGIS thinks all my data is in EPSG 2292 but Esri says 
>>>> it is in EPSG 2954 2954 is the only ESPG we use but QGIS keeps defaulting 
>>>> back to 2292, is there a way I can delete 2292 entirely?
>>> 
>>> I'd like to look into this. Can you open a ticket on
>>> https://github.com/qgis/QGIS/issues with a sample dataset which shows
>>> this issue?
>>> 
>>> Nyall
>>> ___
>>> 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] CRS Issue

[Priv.-Doz. Dr. Maria Shinoto]

Thank you for looking into this. It seems to be related to the CRS problems I 
reported twice in the last weeks; here I get a non existent EPSG instead of the 
correct 6670; the name (2011 Plane Rectangular II -- for Kyūshū) is correct 
though.

If you need material, please tell me. 

Maria


> Am 27.03.2020 um 07:07 schrieb Nyall Dawson :
> 
> On Fri, 27 Mar 2020 at 04:33, Tyler Veinot  wrote:
>> 
>> All;
>> For some reason my QGIS thinks all my data is in EPSG 2292 but Esri says it 
>> is in EPSG 2954 2954 is the only ESPG we use but QGIS keeps defaulting back 
>> to 2292, is there a way I can delete 2292 entirely?
> 
> I'd like to look into this. Can you open a ticket on
> https://github.com/qgis/QGIS/issues with a sample dataset which shows
> this issue?
> 
> Nyall
> ___
> 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] CRS Errors

[Priv.-Doz. Dr. Maria Shinoto]

Hi,

last week I asked a similar question, but I am working with QGIS 3.4. There may 
be a problem with the official Japanese files I downloaded, but it looks 
similar.

My CRS is JGD2011:Plane Rectangular II for Kyūshū, which is EPSG:6670. But I 
get EPSG:102611, which cannot be found in the EPSG database, and the Japanese 
administration told me that it does not exist, but the map is OK and can be 
interpreted as EPSG 6670.

I wonder whether it is a problem with QGIS in my case as well?

Here are the data for one of those layers:

KBS

EPSG:102611 - JGD_2011_Japan_Zone_2 - Projiziert

Ausdehnung

-70895.514234683476,-184658.1692264890589286 : 
-47497.1507370446051937,-166128.1307806141558103


Thanks,
Maria




Am 11.03.2020 um 22:16 schrieb Tyler Veinot 
mailto:tylerkvei...@gmail.com>>:

Has anyone had this issue?
My measurements when using the ellipsoidal measur are in the millions of meters 
for things that are only a few hundred or less meters long. It isn't a unit 
issue because I tried dividing for cm, mm, dm and the measurements don't add 
up. If I go to cartesian the measurements look fine.
Before this was happening my QGIS was also assigning epsg 2292 to my shapfiles 
having an epsg of 2954. I check the file geodatabase they were exported from 
and the proj files and they all reference EPSG 2954 and not EPSG 2292. Also All 
new projects are defaulted to 2954 so no transformations should be necessary.
Since updating to QGIS3 I noticed this transformation section in the settings 
under CRS, is there something here I inadvertently changed?
I do have my own GSB files for coordinate transformations from survey grids but 
I have not figured out how to employ them yet in QGIS3 so I don't think they 
would be an issue.
Anyone else have a similar thing start to happen?
Thanks;
Tyler
___
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] EPSG:102611 and EPSG:6670

[Priv.-Doz. Dr. Maria Shinoto]

I am setting up a new project with the following CRS:

- JGD2011 / Japan Plane Rectangular CS II
- This has the code EPSG:6670

Layers I created from JPGIS files downloaded from the Geospatial Information 
Authority of Japan are imported as "epsg:102611
JGD_2011_Japan_Zone_2".

I could not find any EPSG:102611 information anywhere, can somebody help me 
out? The Japanese officials told me that they do not know about EPSG codes. It 
seems that EPSG:102611 is chosen when the data file does not have informations 
about the dimensions of the zone?


Thanks for any advice. 

Maria



PS

The difference in the layer info and the project info (with the official CRS) 
is: 

epsg:6670
JGD2011 / Japan Plane Rectangular CS II
領域：129.76, 30.18, 132.05, 33.99
Proj4：+proj=tmerc +lat_0=33 +lon_0=131 +k=0. +x_0=0 +y_0=0 +ellps=GRS80 
+units=m +no_defs

epsg:102611
JGD_2011_Japan_Zone_2
領域：範囲が不明です
Proj4：+proj=tmerc +lat_0=33 +lon_0=131 +k=0. +x_0=0 +y_0=0 +ellps=GRS80 
+units=m +no_defs



___
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] Thoughts on QGIS Development and LTR Releases

[Priv.-Doz. Dr. Maria Shinoto]

Hello, 

some remarks from someone who is still learning QGIS, having started in July 
2018. 

I have to deal with very different software in my job, GIS being just a part of 
a larger set, and I cannot dive deep into it every day. This may not be the 
common case, but I can imagine, it is not terribly uncommon either. 

In only 18 months since I started using QGIS I had the pleasure to deal with 
the releases 2.14, 2.18. 3.4, and from now on 3.10 -- already knowing that 3.12 
will be out soon. People I asked for help and tutorials I read or saw on 
YouTube all used different versions. 

I am not yet accustomed to QGIS as a whole, but versions are steadily changing, 
tutorials are changing, it is hard to keep up with it and to separate which 
tutorials are for the version I am dealing with at the moment. Not to speak 
about GRASS or GDAL or OGR issues that somehow turned up during upgrade. And 
there are problems with features that are said here and there to be not 
reliable (like in GeoPackages), but I cannot get hold of whether these problems 
are now solved.

I am impressed with the progress of QGIS, the 3.4 version is definitely a lot 
easier to "get" than the earlier versions. Version 3.10 has some exciting 
features, and tutorials are already leaving version 3.4 behind, so that I just 
decided to upgrade now. -- But then, new versions are already going to be 
deployed soon, and I know I will be outdated when I start to really use 3.10. 

For people like me a change in the LTR cycle to two years would be wonderful. 
Point releases with only bug fixes and nightly builds for preparing the next 
LTR would be most helpful for people like me who are new to the software and 
use it only as one among many tools. This would guarantee that tutorials and 
documentation get complete for a certain version, that features are really 
stable. 

Other users are of course keen on getting new and better features as soon as 
possible. And I see the problem with testing for bugs, for which interim 
versions and nightly builds are helpful. 

This mail is not intended as a complain or a request for changing the LTR cycle 
-- although I would definitely welcome that. I just wanted to explain the point 
of view of a user who is less into the software and who would be glad to have 
less "noise" to separate from the real information. This mailing list is 
exceptionally helpful, tutorials and documentation are very helpful as well. 

All the best and thanks to everybody who is involved in this wonderful software,

M. Shinoto






> Am 01.03.2020 um 13:00 schrieb Alexandre Neto :
> 
> Hello Iain,
> 
> Please notice that LTR versions last for 12 months already. We are now 
> starting a new cycle with 3.10 as LTR and 3.4 receives patch during the last 
> year. Meanwhile, there has been some discussion about making the LTR last for 
> 2 years.
> 
> Regarding documentation, as you said, it's volunteer work. And because our 
> lovely developers never stop adding new features, it's really hard to keep up 
> and we end up delaying the LTR documentation release for some time. I suggest 
> you try using the QGIS testing documentation for now as we are still trying 
> to catch up with all the work done since 3.4 (including some features from 
> 3.10). We still have a bunch of features to document, but we should be 
> releasing Documentation for 3.10 soon.
> 
> https://docs.qgis.org/testing/en/docs/
> 
> Best regards,
> 
> Alexandre Neto
> 
> On Sat, Feb 29, 2020 at 9:56 PM  wrote:
> Maybe because I am an archaeologist, but I have always thought that Long Term 
> is a bit longer than a few months. In practical terms running QGIS in an 
> organisation you want the stability of LTR for at least 12 months so that 
> people can be trained and comfortable in using QGIS. I have found that the 
> documentation and training materials do not keep up with the changes and as a 
> new started it is disconcerting to follow the documentation and see a totally 
> different screen when doing one of the steps. Having the stability of the LTR 
> allows for training and documentation to keep up (especially since this is a 
> voluntary effort) and for users who are using QGIS as a tool simply to get on 
> with their work.
> 
> 
> 
> I would vote for a LRT being defined as not changed for 12 months.
> 
> 
> 
> I would disagree with the point that ArcGIS is better documented than QGIS. 
> My experience with my project team is that they found the various videos and 
> training in QGIS enough to get them going from scratch (i.e. what is this you 
> are doing?) to doing professional maps and limited analysis in QGIS in about 
> a fortnight. I think that the variety of documentation also helps.
> 
> 
> 
> I would also note that although ArcGIS Desktop is updated on a regular basis 
> I have absolutely no idea what actually changes except that I loose all my 
> setups and styles with every upgrade. I suspect most of the ESRI love goes 
> elsewhere or the changes 

Re: [Qgis-user] Thoughts on QGIS Development and LTR Releases

[Priv.-Doz. Dr. Maria Shinoto]

> Am 01.03.2020 um 13:00 schrieb Alexandre Neto :
> 
> Hello Iain,
> 
> Please notice that LTR versions last for 12 months already. We are now 
> starting a new cycle with 3.10 as LTR and 3.4 receives patch during the last 
> year. Meanwhile, there has been some discussion about making the LTR last for 
> 2 years.
> 
> Regarding documentation, as you said, it's volunteer work. And because our 
> lovely developers never stop adding new features, it's really hard to keep up 
> and we end up delaying the LTR documentation release for some time. I suggest 
> you try using the QGIS testing documentation for now as we are still trying 
> to catch up with all the work done since 3.4 (including some features from 
> 3.10). We still have a bunch of features to document, but we should be 
> releasing Documentation for 3.10 soon.
> 
> https://docs.qgis.org/testing/en/docs/
> 
> Best regards,
> 
> Alexandre Neto
> 
> On Sat, Feb 29, 2020 at 9:56 PM  wrote:
> Maybe because I am an archaeologist, but I have always thought that Long Term 
> is a bit longer than a few months. In practical terms running QGIS in an 
> organisation you want the stability of LTR for at least 12 months so that 
> people can be trained and comfortable in using QGIS. I have found that the 
> documentation and training materials do not keep up with the changes and as a 
> new started it is disconcerting to follow the documentation and see a totally 
> different screen when doing one of the steps. Having the stability of the LTR 
> allows for training and documentation to keep up (especially since this is a 
> voluntary effort) and for users who are using QGIS as a tool simply to get on 
> with their work.
> 
>  
> 
> I would vote for a LRT being defined as not changed for 12 months.
> 
>  
> 
> I would disagree with the point that ArcGIS is better documented than QGIS. 
> My experience with my project team is that they found the various videos and 
> training in QGIS enough to get them going from scratch (i.e. what is this you 
> are doing?) to doing professional maps and limited analysis in QGIS in about 
> a fortnight. I think that the variety of documentation also helps.
> 
>  
> 
> I would also note that although ArcGIS Desktop is updated on a regular basis 
> I have absolutely no idea what actually changes except that I loose all my 
> setups and styles with every upgrade. I suspect most of the ESRI love goes 
> elsewhere or the changes are in the various very expensive addons.  
> 
>  
> 
> Dr Iain Stuart
> 
> JCIS Consultants
> 
> P.O. Box 2397
> 
> Burwood North
> 
> NSW, 2134
> 
>  
> 
> (02) 9701 0191
> (0413) 380116 (m)
> 
>  
> 
> ___
> 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