Re: [Qgis-user] [QGIS-Developer] Geodesic Line Simplification

2019-10-09 Thread Christoph Jung 
Hi Calvin,

Splitting the algorithms would be an improvement for using them in combination 
with other algorithms and/or plugins. 

One question:
Does the calculations in geodesic math need more time than with eukledean math? 
The last months I had some questions about my plugin Offline-MapMatching and 
all had trajectories with a small bounding box, i.e. eukledean math would be 
enough for good results. The distance between following trajectory points are 
not so big. Why do you want to implement the geodesic math (oh, it is a second 
question ^^)?

Sincerely,
Christoph 

> Am 08.10.2019 um 17:41 schrieb C Hamilton :
> 
> I have currently implemented a geodesic decimation processing routine, but I 
> have a question for the community. I am thinking about making 3 algorithms to 
> simplify the process rather than one algorithm with more options where some 
> options would not be applicable to points and other not applicable to lines 
> so would you agree with my reasoning or not? If I break it into 3, these 
> would be the algorithms.
> 
> 1. Geodesic distance and time decimation for point layer.
> This would calculate the distance between consecutive points and if they 
> don't meet the minimum distance then a point would be removed. Additionally, 
> if a time field is selected it would also calculate the difference in time 
> between two points and if it is less then the minimum time then the point 
> would be removed. When both distance and time are selected and either 
> condition is below the minimum, then the point would be removed. This 
> algorithm would include an order field and group by field. There would be the 
> option of preserving the last point despite the fact it might not meet the 
> criteria.
> 
> 2. Geodesic distance decimation for lines and perhaps polygons.
> Time would not be a part of the algorithm because the individual vertices 
> don't have time associated with them. This would calculate the distance 
> between consecutive vertices and if they don't meet the minimum geodesic 
> distance then the vertex would be removed. There would be an option of 
> preserving the final vertex despite it might not meet the criteria.
> 
> 3. Geodesic Simply Algorithm for lines and polygons.
> This would implement geodesic versions of algorithms such the Douglas-Peucker 
> algorithm for lines and polygons. Instead of using Cartesian math it would 
> use geodesic math.
> 
> I have #2 implemented and #1 without time. I think it is probably better to 
> have a separate algorithm for points and another for lines and polygons. 
> Would you agree?
> 
> Thanks,
> 
> Calvin
> 
>> On Wed, Oct 2, 2019 at 7:51 PM Nyall Dawson  wrote:
>> On Wed, 2 Oct 2019 at 01:30, C Hamilton  wrote:
>> >
>> > I am guessing this is working on Cartesian coordinates and not geodesic 
>> > which is fine if you have a local projection. I think I will go ahead and 
>> > implement some similar geodesic algorithms. Thank you for the GRASS link. 
>> > It will help.
>> 
>> Hi Calvin,
>> 
>> I think there's a strong use case for adding this to the c++ API.
>> Would you be willing to put together a proof of concept in Python code
>> and I'll port it to c++ for you?
>> 
>> Nyall
>> 
>> 
>> >
>> > Thanks,
>> >
>> > Calvin
>> >
>> > On Tue, Oct 1, 2019 at 7:45 AM Áron Gergely  
>> > wrote:
>> >>
>> >> Hi Calvin and list,
>> >>
>> >> Have you looked at the GRASS GIS v.generalize tool? 
>> >> https://grass.osgeo.org/grass64/manuals/v.generalize.html
>> >>
>> >> The Douglas-Peucker algorithm is implemented there and I have used that 
>> >> with (topologic)success recently on many touching polygons. Should work 
>> >> for polylines too!
>> >>
>> >> Best regards,
>> >> Aron
>> >>
>> >> On 01/10/2019 08:19, Tim Sutton wrote:
>> >>
>> >> Hi
>> >>
>> >> On 26 Sep 2019, at 17:13, C Hamilton  wrote:
>> >>
>> >> Are there any geodesic QGIS algorithms that simplify lines? "Simplify" 
>> >> just uses the projection units of measure. If there isn't I thought I 
>> >> would add this to the Shape Tools plugin. I could easily implement the 
>> >> Douglas-Peucker algorithm using geodesic math.
>> >>
>> >> For GPS tracks I also see a need to throw out all points that are less 
>> >> than a certain distance or less than a certain time interval. I don't see 
>> >> any simplification algorithms that make use of time. Am I just missing 
>> >> them?
>> >>
>> >>
>> >> No I don’t think we have any time based simplifiers - would be a great 
>> >> addition!
>> >>
>> >> Regards
>> >>
>> >> Tim
>> >>
>> >>
>> >>
>> >>
>> >> Thanks,
>> >>
>> >> Calvin
>> >> ___
>> >> QGIS-Developer mailing list
>> >> qgis-develo...@lists.osgeo.org
>> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >>
>> >>
>> >> —
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Tim Sutton
>> >>
>> >> Co-founder: Kartoza
>> >> Ex Project chair: QGIS.org
>

Re: [Qgis-user] Problem Running v.sample in QGIS 3

2019-10-09 Thread Anita Graser 
On Thu, Oct 3, 2019 at 6:36 PM Anita Graser  wrote:

> I can confirm this error in both QGIS 3.4 and the current dev version 3.9.
>
> Even in the GRASS GUI itself, trying to v.in.ogr shapefiles from the QGIS
> sample data fails if it's not told explicitly to override the projection
> check using the -o flag.
>

To follow up on this issue: The error seems to be somehow specific to the
CRS EPSG:2964 of the QGIS sample data because it disappears if I first
reproject the data to WGS84 ...

Should I open a ticket for this?
>

Could this be related to the new proj?

Regards,
Anita
___
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] [QGIS-Developer] Geodesic Line Simplification

2019-10-09 Thread C Hamilton 
Good question. Geodesic math will take more time to compute. If you are
using a local projection and the area of interest is small then it will be
faster using euclidean math, but if your projection is using degrees
(WGS84) or you are covering a large area then geodesic is a better choice.

Best wishes,

Calvin

On Wed, Oct 9, 2019 at 6:46 AM Christoph Jung  wrote:

> Hi Calvin,
>
> Splitting the algorithms would be an improvement for using them in
> combination with other algorithms and/or plugins.
>
> One question:
> Does the calculations in geodesic math need more time than with eukledean
> math? The last months I had some questions about my plugin
> Offline-MapMatching and all had trajectories with a small bounding box,
> i.e. eukledean math would be enough for good results. The distance between
> following trajectory points are not so big. Why do you want to implement
> the geodesic math (oh, it is a second question ^^)?
>
> Sincerely,
> Christoph
>
>
___
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] GeoPackage deadlocks (Andrea Peri)

2019-10-09 Thread Fernando M. Roxo da Motta 
On Mon, 7 Oct 2019 16:46:29 +0200,  wrote:


> Hi everybody,
> 
>  
> 
> Very interesting thread…
> 
> Does the same apply if we only read data from geopackage (not
> overwrite/edit it) on NFS? I have a situation with deadlocks when
> several users are only trying to read data (without competitive
> writing).
> 
> Can anyone confirm this with his case?
> 

  Competitive reading over NFS should pose no problem, whatever the
file format.  If you are getting deadlocks in readonly access it seems
like you can have some other problems in the software accessing (like
pretend to open readonly but set some update flag),  or in the
server/client configuration. There are a number of inherent issues in
NFS that are independent of the data type or software access.

  If we include writing there is another whole universe of problems
with NFS, most of them shared by others network distributed
filesystems.  One huge problem is in the file locking over NFS, it is
not guaranteed that it will work in any way.  It can work sometimes and
not work in other similar situation. Another huge problem is the
latency of the protocol.  NFS, and many other distributed filesystems
over network, are not atomic, in the sense that an interaction that
changes the file content (writing, deleting, ...) or state (locking) is
not sent immediately to the server, besides the characteristic network
latency.   This can lead to many conflicts and race conditions.

  I would suggest that if you have a base of data, whatever the size,
that must be shared and accessed for edition over network for a number
of workers, independent of the number of competitive access, the best
approach is to store those data in a database with a dedicated server
as PostgreSQL or even MySQL/MariaDB).   Edition of data file content
over network don't look like a smart move to me.

  HTH


>  
> 
> greeting from Poland
> 
> Jarosław Sadowski
> 
>  
> 
> From: Qgis-user  On Behalf Of
> Jonathan Moules Sent: Monday, October 7, 2019 4:17 PM
> To: Tobias Wendorff ; Andrea Peri
>  Cc: qgis-user ; Paul
> Wittle  Subject: Re: [Qgis-user]
> GeoPackage deadlocks (Andrea Peri)
> 
>  
> 
> (A little late).
> 
> TL;DR: at least for QGIS, is - never multi-user edit
> SQLite/SpatiaLite/GeoPackages on network file systems.
> 
> SQLite, (and therefore SpatiaLite and GeoPackage) has quite a few
> caveats when it comes to multiple users trying to edit it at once. 
> 
> https://www2.sqlite.org/howtocorrupt.html
> 
> (my bold)
> 
> "SQLite depends on the underlying filesystem to do locking as the
> documentation says it will. But some filesystems contain bugs in
> their locking logic such that the locks do not always behave as
> advertised. This is especially true of network filesystems and NFS in
> particular. If SQLite is used on a filesystem where the locking
> primitives contain bugs, and if two or more threads or processes try
> to access the same database at the same time, then database
> corruption might result."
> 
> And there's also:
> 
> https://www.sqlite.org/whentouse.html
> 
> Put simply (Note: I'm not an expert): It's fine to edit SQLite
> databases if they're not on a network file system with as many users
> as you want, or if they are on a network and you can guarantee only
> one process is going to write. However if multiple people/processes
> want to write to a network file system, you'll need a piece of
> middleware to manage the process, otherwise there's a good chance of
> corruption as Paul is seeing.
> 
> It may also be that QGIS is doing some of the other things on the
> "how to corrupt" page too. I imagine it will only get worse if you
> use multiple different software packages to edit simultaneously.
> 
> Cheers,
> 
> Jonathan
> 
> On 2019-09-27 09:50, Tobias Wendorff wrote:
> 
> Am 27.09.2019 um 10:24 schrieb Andrea Peri
>  : 
> Have you tried to use spatialite instead of geopackage. ?
> 
>  
> Why not plain SQLite? Nobody needs and uses the spatial functions of
> Spatialite, they are even not part of bloatware GPKG (sorry, the
> created db-files are huge without any compression). The only reason
> is indexing and this could be forked off GPGK and Spatialite. 
> To the topic: I think, it‘s always a bad idea to let multiple users
> work on a single SQLite-based database. It hasn‘t been created for
> this reason.
> 
> 
> 
> 
> 
> ___
> 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
> 








  Roxo

-- 
 Non luctari, ludare ---+ WYSIWYG
Fernando M. Roxo da Motta   | Editor?
Except where explicitly stated I speak on my own behalf.|  VI !!
PU5RXO  | I see text,
 Quis custodiet ipsos custodes?-+ I get text!
 
___

[Qgis-user] Thank you for the Label Toolbar and moveable labels

2019-10-09 Thread Johanna Botman 
So just a quick word to say thank you to everyone who helped develop the 
moveable labels in the 3 Series QGIS.

I've just had the need to use this functionality and it made my task SO easy.

Thank you
Thank you
Thank you



Johanna Botman
Asset & GIS Officer | Melton City Council



***
The information in this message is privileged and confidential, intended only 
for the use of the individual or entity named above. If you are not the 
intended recipient you are hereby notified to delete the message and that any 
dissemination, copying or use of its content is strictly prohibited. If you 
have received this message in error please notify the Melton City Council.
***___
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] [QGIS-Developer] Geodesic Line Simplification

2019-10-09 Thread Christoph Jung 
Thank you very much for your answer. I totally forgot projections with degrees, 
sorry ^^ than geodesic math will be the more general approach. 

Sincerely,
Christoph 

> Am 09.10.2019 um 16:33 schrieb C Hamilton :
> 
> Good question. Geodesic math will take more time to compute. If you are using 
> a local projection and the area of interest is small then it will be faster 
> using euclidean math, but if your projection is using degrees (WGS84) or you 
> are covering a large area then geodesic is a better choice.
> 
> Best wishes,
> 
> Calvin
> 
>> On Wed, Oct 9, 2019 at 6:46 AM Christoph Jung  wrote:
>> Hi Calvin,
>> 
>> Splitting the algorithms would be an improvement for using them in 
>> combination with other algorithms and/or plugins. 
>> 
>> One question:
>> Does the calculations in geodesic math need more time than with eukledean 
>> math? The last months I had some questions about my plugin 
>> Offline-MapMatching and all had trajectories with a small bounding box, i.e. 
>> eukledean math would be enough for good results. The distance between 
>> following trajectory points are not so big. Why do you want to implement the 
>> geodesic math (oh, it is a second question ^^)?
>> 
>> Sincerely,
>> Christoph 
>> 
___
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