[Qgis-user] Re Did scale change outputting to PDF?

[John Antkowiak]

 This issue has been solved. Trying to estimate the scale by taking 
measurements on the paper maps failed despite every advantage that should have 
maximized the precision of the measurements. A distance measured north-south 
yielded a different scale than a distance measured east-west. Averages of ten 
of each yielded different scales in these two orientations. The only thing I 
can think of that would produce that result is that the image was distorted 
differently in height than it was in width.
But the whole issue was resolved when Kinkos agreed to examine the process and 
reprint the job. After one test panel, they told me they figured out what had 
happened (although they didn't tell me what that was). They reprinted the big 
panel and one small parcel map, and they line up perfectly just as I had 
planned. They are in the process of reprinting the rest of the panels at no 
cost to me. For long-story reasons I'm not inclined to share, I didn't think 
they would do that. The rest of the work going forward is going to be SO much 
simpler because of that. 
Thank you all for your help!
- John A. 
  
John,
 
Is it possible to ask Kinkos what scale they printed the base maps?  They don't 
have to actually reprint the maps, just go through the motions.  Open the PDF 
and look at the print options. As Andreas points out, the default is often 
"Fit" and there will be a "zoom" or "scale" percent displayed in the 
application (I use Foxit, and Adobe and both show this).  The page size parcel 
maps will have to be printed at this scale.  If they can guarantee that the 
print scale was 100%, then I would assume some other export discrepancy.
 
  David
 
 
  On 5/27/2021 4:15 AM, Andreas Neumann wrote:
  
 

Hi John,
 
No - the PDF export does not distort the scale. But the printing of the PDF 
file might.
 
It is absolutely important that - when printing the PDF - the setting "Actual 
size" or "Custom Scale at 100%" is used. All other options will change the 
scale.
 
As far as I know, the default option when printing is "Fit", which will often 
shrink the content by some percentage - because some often "invisible" or white 
background might be present in the file that extends right to the edge of the 
page format. Acrobat then thinks that the content goes beyond the "printable 
area" of the printer and will scale down the whole file.
 
Hope that clarifies this potential pit-fall when printing PDF files. It might 
well be a different issue than the one I describe, but this is a very common 
source of error that I know.
 
Andreas
 
On 2021-05-27 10:02, John Antkowiak wrote:
 
  Hi, Jochen. Your suggestion sounds do-able; I'll play around with it and 
see if I can sort it out. I've got some digital calipers around here somewhere 
:)    What I'm hearing is that the process of converting both the base map (and 
yes, I did create it in QGIS) and the parcel maps into PDF will distort the 
scale. (And that a print shop might compound the problem by manually fitting 
the source file to the printable area. Yes?) A question then is why didn't the 
PDF conversion distort them all the same way, to the same degree? The base maps 
are done now and I couldn't afford to do them again no matter what, so they are 
what they are. Going forward, is there an export option in Print Layout that 
will not distort the scale of the parcel maps?   I am so relieved that someone 
has an explanation for this!   - John A.  - Forwarded Message - 
From: j.hu...@post-ist-da.de  To: 
"qgis-user@lists.osgeo.org"  Sent: Thursday, May 27, 
2021, 03:33:12 AM EDT Subject: Re: [Qgis-user] Did scale change outputting to 
PDF?  Hi John,   as I understand it, you created the base map in QGIS. If 
you use the measure tool in QGIS to get the distance between two distinct 
features in the map (e.g. road intersections) and then measure the same 
distance on the printed base map with a ruler, it should be possible to 
calculate the scale. Maybe use two distances, one aligned more or less 
horizontally and one vertically, to check if the scaling is proportional.   As 
Andreas pointed out, it is probably a problem with the settings when the PDF 
was printed. In my experience it is a good idea to go to print shops usually 
working for architects and engineers since they are familiar with the 
importance of scaling (for advertising etc. it is more important that the whole 
content is printed, so that scaling might be used to fit the output to the 
printable area without potential cropping). You can print directly to a plotter 
in QGIS if you have access to the device, avoiding the PDF detour.   EPSG 2264 
should be fine. Units should be US feet.   Regards
 Jochen     Am 27.05.21 um 07:15 schrieb John Antkowiak: 
   Hi. This plan was too simple to fail - but it failed. The charity whose 
project this is needed a large (that is... massive) paper wall map on which to 
plot and rethink its delivery driver assignments. Both drivers and delivery 
add

Re: [Qgis-user] font in Expression box illegible

[Alexandre Neto]

I would start by suggesting you to update your QGIS version to 3.16.

If the problem persists, try creating a new user profile in the settings
menu.

Best regards,

Alexandre Neto
User Support
www.qcooperative.net

A quarta, 9/06/2021, 14:20, Jasper Heinz  escreveu:

> Hi there,
>
> I have problems with the font in expression box and python console etc.
> The font is illegible and on top of each other. I have tried changing the
> font size and font but that doesn't seem to affect the font here. It only
> seems to occur on this one machine and does not occur on other machines
> with the same version.
> Version: QGIS Desktop 3.2.3
>
> It would be really great if someone could help me!
>
> Best regards
> Jasper
>
> ___
> 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] SPLIT POLYGONS INTO 3 PARTS (similar size)

[Azzurra Lentini]

Hi List, I ask you  again the same question  I asked you days ago.
I have several polygons - around 200-  (all different shapes and not
regular geometry) and I need to split every single polygon into 3 parts of
similar size.
I have tried with *Split polygons* but it is working very well only with
regular geometries (square, rectangle etc.) and so I can not use it in this
case.
I have tried  also your suggestions (generate points, kclustering and
voronoi polygons):https://gis.stackexchange.com/questions/321021/how-to-
split-polygon-into-equal-area-polygons-in-qgis-3 and
https://blog.cleverelephant.ca/2018/06/polygon-splitting.html
but I am not able to do it to all 200 polygons at once.. I can do it only
polygon by polygon..

do you have other suggestions? thanks AL

On Wed, 19 May 2021 at 15:49, Azzurra Lentini 
wrote:

> Dear List,
> please I would like to have any suggestion regarding this topic: I have
> several polygons (all different shapes and not regular geometry) and I need
> to split every single polygon into 3 parts of similar size.
> I have tried with *Split polygons* but it is working very well only with
> regular geometries (square, rectangle etc.) and so I can not use it in this
> case.
>
> Do you have any suggestions?
>
> THANK YOU, AZZURRA
> --
> Adjunct Professor University "Roma Tre"
> Gis Applied for Environmental studies
> Risk modelling & Hydrogeology
> Consultant DFID-UK, United Nations, EU projects
> AZZURRA LENTINI
> ++
> Italy Mobile Tel.: **(39) 338 24 40 676
> ++
> SKYPE azzurrahydro
> ++
>
> *azzurralent...@gmail.com *
>
> *azzurra.lent...@uniroma3.it  *
> ++
> *Par respect pour l'environnement,*
>
> *n'imprimez ce mail qu'en cas d'absolue nécessité*
>
>
>
>
>
>

-- 
Adjunct Professor University "Roma Tre"
Gis Applied for Environmental studies
Risk modelling & Hydrogeology
Consultant DFID-UK, United Nations, EU projects
AZZURRA LENTINI
++
Italy Mobile Tel.: **(39) 338 24 40 676
++
SKYPE azzurrahydro
++

*azzurralent...@gmail.com *

*azzurra.lent...@uniroma3.it  *
++
*Par respect pour l'environnement,*

*n'imprimez ce mail qu'en cas d'absolue nécessité*
___
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] QField: Synchronization .. what am I missing?

[Bernd Vogelgesang]

Hi folks,

I am already using QField in die field, but I happen not to get the
point about the synchronization.

When I'm back in the office, I copy my edited gpkg of a simple point
layer into the "import" folder in the QField folder on my computer.

Then I click the button "Synchronize with QField", the path is set to
the import folder,  and ... well .. nothing happens.

There should be new points now, but there aren't.

I simply don't get the point. Of course I could just replace the old
gpkg in my project with the new one, but what is that button good for then?


Any hints 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

Re: [Qgis-user] Compiling messages Qgis 3.18.3

[Richard Duivenvoorde]

On 6/9/21 4:16 PM, APM wrote:

> Do you know, what is wrong? There seems to be something like a sql error?

I think nothing is wrong... I see those also. 

During install QGIS tries to sync your local crs db (in sqlite) with a new list 
from ??? the installer, and SQlite complains about something (maybe that a crs 
already excists and you cannot overwrite it or so)? But for what I know all is 
good after that :-)

Others think different?

Regards,

Richard Duivenvoorde


___
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] Earth, Sun, Moon & Planets Plugin

[C Hamilton]

I should clarify and say that if there were serious interest in using QGIS
for some astronomy related work astropy might be the way to go with perhaps
several other astropy libraries added, but I am not sure if astronomers
could use nor how they would use QGIS for their work other than the types
of things I am doing with the "Earth, Sun, Moon & Planets Plugin," but I am
not an astronomer. For what I visualize as the need of the community
Skyfield would probably do everything that would be needed.

Calvin

On Sat, Jun 5, 2021 at 1:04 PM Tim Sutton  wrote:

> Hi
>
> Wow that looks beautiful! A couple of thoughts:
>
> 1) Rather than implementing your own slider logic I wonder if you could
> hook in to the temporal controller?
> 2) For platform specific components the normal practice is to a)
> communicate with the plugins reviewers about why this is needed so that
> they don't pre-emptively reject your plugin and b) normally pull down the
> platform specific components as a post install step. I expect you will get
> some resistance to adding a new dependency to QGIS core unless that
> dependency is broadly useful, but you may be able to convince Jurgen and
> Peter to bundle it into the Windows and macOS installers respectively.
> 3) For that 100mb blob, similar to our discussion on the timezone work you
> were doing, the preferred approach would be to fetch it as a post-install
> download the first time you use the plugin.
>
> Thanks for making such interesting plugins!
>
> Regards
>
> Tim
>
>
___
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] Compiling messages Qgis 3.18.3

[APM]

Dear All,


on a Debian Bullseye system I compiled Qgis 3.18.3 following
https://github.com/qgis/QGIS/blob/master/INSTALL.md 
.



After a 'make install' I received sevaral similar messages, please see a 
cut below:



Could not execute: INSERT INTO tbl_srs(srs_id, 
description,projection_acronym,ellipsoid_acronym,parameters,srid,auth_name,auth_id,is_geo,deprecated) 
VALUES (63422, 'NAD27 (CRS27)','longlat',NULL,'+proj=longlat 
+datum=NAD27 +no_defs',520003422,'OGC','CRS27',1,0) [NOT NULL constraint 
failed: tbl_srs.ellipsoid_acronym/NOT NULL constraint failed: 
tbl_srs.ellipsoid_acronym]


Could not execute: INSERT INTO tbl_srs(srs_id, 
description,projection_acronym,ellipsoid_acronym,parameters,srid,auth_name,auth_id,is_geo,deprecated) 
VALUES (63423, 'NAD83 (CRS83)','longlat',NULL,'+proj=longlat 
+datum=NAD83 +no_defs',520003423,'OGC','CRS83',1,0) [NOT NULL constraint 
failed: tbl_srs.ellipsoid_acronym/NOT NULL constraint failed: 
tbl_srs.ellipsoid_acronym]



Do you know, what is wrong? There seems to be something like a sql error?


Thank you!



Kind regards


Piet

___
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] Earth, Sun, Moon & Planets Plugin

[C Hamilton]

Tim,

Thanks for the suggestions. I will look into the temporal controller.

As you know I like having the plugins self contained so that they run
immediately. I have struggled with this issue in this case because there
are no astronomical libraries that I can do this with, at least ones that
are highly accurate and use ephemeris data rather than less accurate,
simplified mathematical equations. I try to go for accuracy.

For testing I will release a self contained windows version, but other
users will need to pip install skyfield. In the case of the Date/Time Tools
plugin I made it self contained so that the user didn't need to pip install
anything, but that is what made it so large. It is reasonable for the user
to download the ephemeris data separately. I may be able to extract a small
set of the data that is within the 10 mb limit so that it is shipped with
the plugin so that it works immediately. It just won't have a large date
span, but if they are having to pip install skyfield, it is not going to be
any more difficult to download the ephemeris data.

I think it would be good for QGIS to have some astronomical libraries
included. I've already had people express interest in this capability, but
we will see how much overall interest there is in this plugin. It will get
more acceptance if people do not need to pip install anything.

Astropy is the most active and complex astronomy library. I chose not to
use it because I didn't think it was needed for QGIS. I used Skyfield
instead. It has the necessary functionality that I think is needed for QGIS
projects. It is a modernized version of PyEphem by the same author and is
recommended by the author over PyEphem.

Thanks for your continued support,

Calvin

On Sat, Jun 5, 2021 at 1:04 PM Tim Sutton  wrote:

> Hi
>
> Wow that looks beautiful! A couple of thoughts:
>
> 1) Rather than implementing your own slider logic I wonder if you could
> hook in to the temporal controller?
> 2) For platform specific components the normal practice is to a)
> communicate with the plugins reviewers about why this is needed so that
> they don't pre-emptively reject your plugin and b) normally pull down the
> platform specific components as a post install step. I expect you will get
> some resistance to adding a new dependency to QGIS core unless that
> dependency is broadly useful, but you may be able to convince Jurgen and
> Peter to bundle it into the Windows and macOS installers respectively.
> 3) For that 100mb blob, similar to our discussion on the timezone work you
> were doing, the preferred approach would be to fetch it as a post-install
> download the first time you use the plugin.
>
> Thanks for making such interesting plugins!
>
> Regards
>
> Tim
>
___
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] font in Expression box illegible

[Jasper Heinz]

Hi there,

 


I have problems with the font in _expression_ box and python console etc. The font is illegible and on top of each other. I have tried changing the font size and font but that doesn't seem to affect the font here. It only seems to occur on this one machine and does not occur on other machines with the same version.



Version: QGIS Desktop 3.2.3

 

It would be really great if someone could help me!

 

Best regards
Jasper

 


___
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] How to filter shape or oracle layer

[Dario C]

Hi, is there any way to filter a layer (both shape and oracle) using a
spatial query?
(I would like to load/view only what it is inside a range of value of a
proper "field")

Thanks
___
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] Locale not respected by layouts

[Alessandro Pasotti]

Hi,

can you please file a ticket and assign it to me (elpaso)?

I'm planning to fix this kind of issues in the future.



On Wed, Jun 9, 2021 at 12:50 PM António Pestana 
wrote:

> I'm on QGIS 3.18.3 using the "Portuguese Portugal" (pt_PT) locale. For
> this locale the decimal separator is a comma. However, when creating a
> layout that includes a table having decimal fields, the decimal separator
> used by QGIS becomes a point! How can I prevent this odd behavior?
>
> Use the link
> 
>  to
> load three (very small) files, as follows:
> - "Points", a geopackage consisting of one points layer only, whose
> attribute table has decimal fields;
> - "TableWithCommas", printscreen of the attribute table as displayed by
> the "Open Attribute Table" command (the decimal separator is a comma, as it
> should be);
> - "LayoutWithoutCommas", printscreen of the Print Layout Window after
> adding the attribute table to the layout (the decimal separator is now a
> point).
>
> António
>
> ___
> 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
>


-- 
Alessandro Pasotti
QCooperative:  www.qcooperative.net
ItOpen:   www.itopen.it
___
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] Locale not respected by layouts

[Richard Duivenvoorde]

Hi,

this is currently a "QEP" (which received a grant for 2021), see:
https://github.com/qgis/QGIS-Enhancement-Proposals/issues/210

you could add your example to it?

Regards,

Richard Duivenvoorde

On 6/9/21 12:49 PM, António Pestana wrote:
> I'm on QGIS 3.18.3 using the "Portuguese Portugal" (pt_PT) locale. For this 
> locale the decimal separator is a comma. However, when creating a layout that 
> includes a table having decimal fields, the decimal separator used by QGIS 
> becomes a point! How can I prevent this odd behavior?
> 
> Use the link 
> 
>  to load three (very small) files, as follows:
> - "Points", a geopackage consisting of one points layer only, whose attribute 
> table has decimal fields;
> - "TableWithCommas", printscreen of the attribute table as displayed by the 
> "Open Attribute Table" command (the decimal separator is a comma, as it 
> should be);
> - "LayoutWithoutCommas", printscreen of the Print Layout Window after adding 
> the attribute table to the layout (the decimal separator is now a point).
> 
> António
> 
> 
> ___
> 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] Locale not respected by layouts

[António Pestana]

I'm on QGIS 3.18.3 using the "Portuguese Portugal" (pt_PT) locale. For this
locale the decimal separator is a comma. However, when creating a layout
that includes a table having decimal fields, the decimal separator used by
QGIS becomes a point! How can I prevent this odd behavior?

Use the link

to
load three (very small) files, as follows:
- "Points", a geopackage consisting of one points layer only, whose
attribute table has decimal fields;
- "TableWithCommas", printscreen of the attribute table as displayed by the
"Open Attribute Table" command (the decimal separator is a comma, as it
should be);
- "LayoutWithoutCommas", printscreen of the Print Layout Window after
adding the attribute table to the layout (the decimal separator is now a
point).

António
___
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