Re: [Qgis-user] Reverting to version 2.2 from 2.4

[Andre Joost]

Am 19.08.2014 19:46, schrieb Laura O'Grady:



When I attempted to re-create this process in 2.4 using the instructions
posted here by John I was able to load Open Street Map as the basemap I
could not download the data. I tried loading it from the canvas (link to
screen dump with error):



https://dl.dropboxusercontent.com/u/10032664/error%20map%20canvas.png





It looks like QGIS is attempting to download data in a bbox of mercator 
projected coordinates, while the overpass API is expecting WGS84 degrees.


This is surely a bug of the OSM plugin.

Maybe the plugin uses the project CRS as default for the bbox coordinates.

This might work:
- Create a polygon layer in WGS84 drawing a bbox polygon of the area of 
your interest with EPSG:3857 as project CRS and Openlayers background


- Delete the Openlayers background layer, change project CRS to 
EPSG:4326 and zoom to the extent of your polygon


- Download the OSM data

- Switch project CRS back to EPSG:3857, and load the Openlayers background.

HTH,
André Joost




___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Intended work-flow for joining table to layer?

[Bernd Vogelgesang]

Hi Andreas,

well, I'm not very funny as well, cause dealing with this subject really  
made me crazy.

I agree, QGIS should get rid of shapefiles as soon as possible.

But I can't see a trace of that so far. At least there are no feasible  
solutions for beginners like my colleagues.
Me personally I'm trying to find a work-flow to migrate all my stuff to  
Spatialite, using the DB manager, qspatialite and the Spatialite_GUI cause  
there is no smooth working tool handling everything yet (Or I simply do  
not understand where the searched functions are).


The brilliant Processing Toolbox e.g. produces tons of ... shapefiles. The  
ftools in vector menu exclusively produce ... shapefiles.
So why is the processing of this prominent format crippled that way just  
within the joins???


I do not have the fantasy to imagine what complicated stuff you database  
guys do with the joins function that you need the prefixes there, while  
you could always use sql-magic behind the scenes and do not relate on such  
primitive gui stuff in the layer properties.


But maybe a simple checkbox in the joins dialog that would just use the  
old mechanism without prefixes would be a solution for those handicapped  
that still use ... shapefiles.
Or if it would use the alias for prefixing and leave the field name as it  
is?


Cheers
Bernd





Am 19.08.2014, 21:34 Uhr, schrieb Andreas Neumann :


Hi Bernd,

And for how many centuries should be cripple QGIS just because of these
stupid Shape-file limitations?

I know - I am not very funny. But for the rest of the world, that does
not have to deal with ESRI Shapes the table prefix in the column names
is really very useful.

Maybe there should be a special mechanism in the ESRI shape export
dialog that allows some intelligent magic to shorten field names - not
holding back the rest of QGIS. Something like a regular expression
substitute mechanism for column renames where you can define the rules
for column renames - e.g. replacing prefix names or taking the first 4
and the last 3 characters.

In my opinion this would be much more useful than crippling QGIS into
short column names.

Andreas

Am 19.08.2014 09:44, schrieb Bernd Vogelgesang:

Hi,

since some versions, the once  "trivial" task to join tabular data to a
layer became very annoying and time consuming.

We have a normal point shape and an excel file which we want to join.
Export xls to csv, import through the wizard, no deal.

But using the joins from the properties is changing the field names by
adding the table name in front of the original field name.
This may be intended to prohibit confusion with the origin of the field,
but its causing a lot of work, cause even if you keep your table name as
short as it can be to be still meaningful, the combination with my still
short field names plus the table name completely destroys the field name
when saved as shape again.

table name  = join
field names: FIELDA, FIELDB, FIELDC etc

Result after save:

join_FIELD, join_FIE_1, join_FIE_2

Even with such short names, all information is destroyed, so we have to
go to the table manager (which a lot new user will not know for sure!)
and rewrite the field names completely. For 20+ fields that's no fun at
all.

The second alternative to join data is through the processing toolbox
"Join attribute table".
This works great for combining to layers without that field name
hokuspokus, but at least in V2.0 on Windows (my collegues computer is
not updated yet), you can only select layers, tables can't be selected,
so you can't join them.

I had the very same issue on another dataset with 2000 items some days
ago (on Win7, V2.4): The "normal" join took ages and produced unreadable
field names, the Toolbox join didn't work, so in the end I fiddled
myself into Spatialite to be able to join those darn data sets.

I will stick to the Spatialite approach, but for my collegues, this is
completely beyond the scope.


Can anyone share their work-flows for joining data which is doable by
normal dudes too?


Cheers
Bernd



___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374

Am 19.08.2014, 21:34 Uhr, schrieb Andreas Neumann :


Hi Bernd,

And for how many centuries should be cripple QGIS just because of these
stupid Shape-file limitations?

I know - I am not very funny. But for the rest of the world, that does
not have to deal with ESRI Shapes the table prefix in the column names
is really very useful.

Maybe there should be a special mechanism in the ESRI shape export
dialog that allows some intelligent magic to shorten field names - not
holding back the rest of QGIS. Something like a regular expression
substitute mechanism for column renames where you can define the rules
for column renames - e.g. replacing prefix names or taking the first 4
and the last 3 characters.

Re: [Qgis-user] Segfault when using QgsComposition::exportAsPDF with QGIS 2.4 and python

[Nyall Dawson]

On 20/08/2014 2:58 am, "kimaidou"  wrote:
>
> Hi again,
>
> I have opened an issue in the hub : http://hub.qgis.org/issues/11077
>
> I have not assigned anyone, please assign the adequate dev ;)
>

Does it make any difference if you change:
c = QgsComposition(QgsMapSettings())

To:
ms=QgsMapSettings()
c=QgsComposition(ms)

?
Nyall
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Intended work-flow for joining table to layer?

[Andreas Neumann]

Hi Bernd,

And for how many centuries should be cripple QGIS just because of these
stupid Shape-file limitations?

I know - I am not very funny. But for the rest of the world, that does
not have to deal with ESRI Shapes the table prefix in the column names
is really very useful.

Maybe there should be a special mechanism in the ESRI shape export
dialog that allows some intelligent magic to shorten field names - not
holding back the rest of QGIS. Something like a regular expression
substitute mechanism for column renames where you can define the rules
for column renames - e.g. replacing prefix names or taking the first 4
and the last 3 characters.

In my opinion this would be much more useful than crippling QGIS into
short column names.

Andreas

Am 19.08.2014 09:44, schrieb Bernd Vogelgesang:
> Hi,
> 
> since some versions, the once  "trivial" task to join tabular data to a
> layer became very annoying and time consuming.
> 
> We have a normal point shape and an excel file which we want to join.
> Export xls to csv, import through the wizard, no deal.
> 
> But using the joins from the properties is changing the field names by
> adding the table name in front of the original field name.
> This may be intended to prohibit confusion with the origin of the field,
> but its causing a lot of work, cause even if you keep your table name as
> short as it can be to be still meaningful, the combination with my still
> short field names plus the table name completely destroys the field name
> when saved as shape again.
> 
> table name  = join
> field names: FIELDA, FIELDB, FIELDC etc
> 
> Result after save:
> 
> join_FIELD, join_FIE_1, join_FIE_2
> 
> Even with such short names, all information is destroyed, so we have to
> go to the table manager (which a lot new user will not know for sure!)
> and rewrite the field names completely. For 20+ fields that's no fun at
> all.
> 
> The second alternative to join data is through the processing toolbox
> "Join attribute table".
> This works great for combining to layers without that field name
> hokuspokus, but at least in V2.0 on Windows (my collegues computer is
> not updated yet), you can only select layers, tables can't be selected,
> so you can't join them.
> 
> I had the very same issue on another dataset with 2000 items some days
> ago (on Win7, V2.4): The "normal" join took ages and produced unreadable
> field names, the Toolbox join didn't work, so in the end I fiddled
> myself into Spatialite to be able to join those darn data sets.
> 
> I will stick to the Spatialite approach, but for my collegues, this is
> completely beyond the scope.
> 
> 
> Can anyone share their work-flows for joining data which is doable by
> normal dudes too?
> 
> 
> Cheers
> Bernd
> 

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Reverting to version 2.2 from 2.4

[Laura O'Grady]

Thanks for your response Damien. I need both open layers and OSM to work.
The OSM plugin has just been updated and I upgraded it. I'm not sure from
your response if you have both of these plugins working on 2.4 and what OS
you are using. 

 

I should have added that I already followed the instructions posted earlier
this month on this list by John Harrop. I continue to get errors when using
the open layers/OSM plug-in. It may be because we are using different
operating systems (he's on a Mac and I'm on a PC).

 

If anyone is interested in what happened I'll attempt to recreate what I did
here. 

 

When I was using OSM/Open Layers before in QGIS 2.2 I used the tutorial
posted here: http://www.qgistutorials.com/en/docs/downloading_osm_data.html.

 

I was able to follow it perfectly and download data for the area I was
interested in (Toronto, Ontario, Canada), a database was created and I was
then able to query SpatialLite for specific points/tags for a project I'm
working on with my local OSM community. The files I saved in QGIS 2.2 will
not work in 2.4. When I opened the 2.2 version .qgs file in 2.4 I got an
error message stating that if I saved this project in the new version all
functionality may be lost. I tried it anyway and sure enough it no longer
worked.

 

When I attempted to re-create this process in 2.4 using the instructions
posted here by John I was able to load Open Street Map as the basemap I
could not download the data. I tried loading it from the canvas (link to
screen dump with error):

 

https://dl.dropboxusercontent.com/u/10032664/error%20map%20canvas.png

 

and loading it from the map layer (link to screen dump with error):

 

https://dl.dropboxusercontent.com/u/10032664/error%20from%20layer.png

 

If you look in the bottom left corner of the "Download Open Street Data"
dialogue boxes in both screen dumps you will see that they have "0.0 MB"
already hard coded. I could not remove or adjust this number. I didn't
attempt the manual entry because this same issue regarding the 0.0 MB
appeared again with this option checked off. As I can't get the data
downloaded I cannot move forward with downloading the tags I'm interested
in.

 

Any help on either further troubleshooting the open layers/OSM issue or my
original question about reverted to version 2.2 is appreciated. Thanks.

 

Laura

 

From: Damien Stephens [mailto:damien.steph...@sandfire.com.au] 
Sent: August-19-14 3:04 AM
To: Laura O'Grady; qgis-user@lists.osgeo.org
Subject: RE: [Qgis-user] Reverting to version 2.2 from 2.4

 

Hi if all you want is to get open layers back. Just upgrade the plugin
(plugins\manage and install plugins\   select  open layers plugin then
upgrade.

The layers move to the WEB menu from the PLUGINS menu across the top, but
other than that they are identical, and I think there are improvements in
how the open layers plugin works as well - seems to be more stable. I cant
tell which OSM plugin you need but I guess they will have been upgraded too.

 

cheers

 

From: qgis-user-boun...@lists.osgeo.org

[mailto:qgis-user-boun...@lists.osgeo.org] On Behalf Of Laura O'Grady
Sent: Tuesday, 19 August 2014 6:21 AM
To: qgis-user@lists.osgeo.org  
Subject: [Qgis-user] Reverting to version 2.2 from 2.4

 

Hi all,

 

I'm using a Windows 7 64-bit machine. I downloaded the installer
(osgeo4w-setup-x86_64.exe) in the fall of 2013 when I purchased, "Learning
QGIS 2.0" book in the fall of 2013. I only recently installed it and was
slightly surprised to see version 2.2 install instead of 2.0. I assumed this
would not be an issue for the tutorials I was going to use to teach myself
the program.  

 

I was following one particular QGIS tutorial online through Canvas when I
was required to install a package in order to complete the task. As a result
QGIS upgraded to version 2.4, which broke some plug-ins (specifically open
layers, OSM) that I was using. 

 

I would like to know what is the best method to complete the following
tasks:

 

(1). Remove version 2.4 and ensure there are no hooks remaining on my
computer

(2). Re-install version 2.2 (I'm assuming it would be download it from here:
http://qgis.org/downloads/ , specifically the file
QGIS-OSGeo4W-2.2.0-1-Setup-x86_64.exe, dated February 26, 2014)

(3). Ensure that adding packages in the future doesn't automatically upgrade
my version to 2.2 to 2.X.

 

I can understand the generic installer I was using a few months ago to
install what I thought was 2.0 actually installed 2.2 but I think I should
have been asked/warned about the version change from 2.2 to 2.4. Thanks.

 

Laura

 

 

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Segfault when using QgsComposition::exportAsPDF with QGIS 2.4 and python

[kimaidou]

Hi again,

I have opened an issue in the hub : http://hub.qgis.org/issues/11077

I have not assigned anyone, please assign the adequate dev ;)

Regards
Michael



2014-08-19 18:02 GMT+02:00 kimaidou :

> Hi Nyals,
>
> I have reproduced the bug under Ubuntu 14.04 and QGIS 2.4, with the
> backtrace [1].
> The "core" file is about 1,5 Go (!!) so I cannot send it here.
>
> In the Gist I posted, you may delete the line 21 and add
>
> method0()
>
> at the end to reproduce the bug.
>
> [1] http://paste.ubuntu.com/8090015/
> [2] https://gist.github.com/mdouchin/6d7408980f737959075b
>
>
> Thanks in advance for any feedback
>
> Michael
>
>
>
>
> 2014-07-14 2:27 GMT+02:00 Nyall Dawson :
>
> On 11 July 2014 03:52, kimaidou  wrote:
>> > Hi all,
>> >
>> > Can anyone confirms this bug happened for your either ? If so, I will
>> create
>> > an issue in the hub. I personnaly need this feature to export some data
>> as
>> > PDF from a plugin.
>> >
>>
>> I've just tested and it works fine for me under both Windows and
>> Ubuntu 14.04. I'm not sure what is occurring here...
>>
>> Nyall
>>
>
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Segfault when using QgsComposition::exportAsPDF with QGIS 2.4 and python

[kimaidou]

Hi Nyals,

I have reproduced the bug under Ubuntu 14.04 and QGIS 2.4, with the
backtrace [1].
The "core" file is about 1,5 Go (!!) so I cannot send it here.

In the Gist I posted, you may delete the line 21 and add

method0()

at the end to reproduce the bug.

[1] http://paste.ubuntu.com/8090015/
[2] https://gist.github.com/mdouchin/6d7408980f737959075b


Thanks in advance for any feedback

Michael




2014-07-14 2:27 GMT+02:00 Nyall Dawson :

> On 11 July 2014 03:52, kimaidou  wrote:
> > Hi all,
> >
> > Can anyone confirms this bug happened for your either ? If so, I will
> create
> > an issue in the hub. I personnaly need this feature to export some data
> as
> > PDF from a plugin.
> >
>
> I've just tested and it works fine for me under both Windows and
> Ubuntu 14.04. I'm not sure what is occurring here...
>
> Nyall
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] GDAL translate 16 bit to 8 bit

[Brent Fraser]

Hanlie,
  The GDAL-dev list is the best list for this question.  And it would 
help to post the results of the "gdalinfo" command on your input image.


Best Regards,
Brent Fraser

On 8/18/2014 1:23 AM, Hanlie Pretorius wrote:

Hi,

I'm working with a 16 bit SPOT 6 image that I want to convert from 16
bit pixel depth to 8 but pixel depth.

I've manage to do so on the multispectral image, but the result is poor.

So I split the image into its four bands that is, I now have one image per band.

When I now try to convert to 8 bit, I get a message that says:
"Warning 742327101_R1C1_band1_8bit.TIF not created".

The command I'm using is:
gdal_translate -ot Byte -of GTiff "D:/SPOT
6/EightBit/IMG_SPOT6_MS_201304290812030_ORT_742327101_R1C1_band1.TIF"
742327101_R1C1_band1_8bit.TIF

Does anybody know why this is happening or can anyone perhaps refer me
to a forum/email list where I can be helped? I could only find a GDAL
dev email ist.

Thanks
Hanlie
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user




___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Intended work-flow for joining table to layer?

[Carlos Cerdán]

Hi Bernd

In this case, After charging in QGIS, I change the name of second table
to... nothing (yes, you can have charged a table without name), so the
field name resulting is "_filed1", "_field2", etc.

Attribute tables are DBF tables, and DBF fields are max 10 characters
length, so before union, names must be 9 character lenght.

Regards

Carlos Cerdán




2014-08-19 4:44 GMT-05:00 Bernd Vogelgesang :

> Hi,
>
> since some versions, the once  "trivial" task to join tabular data to a
> layer became very annoying and time consuming.
>
> We have a normal point shape and an excel file which we want to join.
> Export xls to csv, import through the wizard, no deal.
>
> But using the joins from the properties is changing the field names by
> adding the table name in front of the original field name.
> This may be intended to prohibit confusion with the origin of the field,
> but its causing a lot of work, cause even if you keep your table name as
> short as it can be to be still meaningful, the combination with my still
> short field names plus the table name completely destroys the field name
> when saved as shape again.
>
> table name  = join
> field names: FIELDA, FIELDB, FIELDC etc
>
> Result after save:
>
> join_FIELD, join_FIE_1, join_FIE_2
>
> Even with such short names, all information is destroyed, so we have to go
> to the table manager (which a lot new user will not know for sure!) and
> rewrite the field names completely. For 20+ fields that's no fun at all.
>
> The second alternative to join data is through the processing toolbox
> "Join attribute table".
> This works great for combining to layers without that field name
> hokuspokus, but at least in V2.0 on Windows (my collegues computer is not
> updated yet), you can only select layers, tables can't be selected, so you
> can't join them.
>
> I had the very same issue on another dataset with 2000 items some days ago
> (on Win7, V2.4): The "normal" join took ages and produced unreadable field
> names, the Toolbox join didn't work, so in the end I fiddled myself into
> Spatialite to be able to join those darn data sets.
>
> I will stick to the Spatialite approach, but for my collegues, this is
> completely beyond the scope.
>
>
> Can anyone share their work-flows for joining data which is doable by
> normal dudes too?
>
>
> Cheers
> Bernd
>
> --
> Bernd Vogelgesang
> Siedlerstraße 2
> 91083 Baiersdorf/Igelsdorf
> Tel: 09133-825374
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] Intended work-flow for joining table to layer?

[Bernd Vogelgesang]

Hi,

since some versions, the once  "trivial" task to join tabular data to a  
layer became very annoying and time consuming.


We have a normal point shape and an excel file which we want to join.
Export xls to csv, import through the wizard, no deal.

But using the joins from the properties is changing the field names by  
adding the table name in front of the original field name.
This may be intended to prohibit confusion with the origin of the field,  
but its causing a lot of work, cause even if you keep your table name as  
short as it can be to be still meaningful, the combination with my still  
short field names plus the table name completely destroys the field name  
when saved as shape again.


table name  = join
field names: FIELDA, FIELDB, FIELDC etc

Result after save:

join_FIELD, join_FIE_1, join_FIE_2

Even with such short names, all information is destroyed, so we have to go  
to the table manager (which a lot new user will not know for sure!) and  
rewrite the field names completely. For 20+ fields that's no fun at all.


The second alternative to join data is through the processing toolbox  
"Join attribute table".
This works great for combining to layers without that field name  
hokuspokus, but at least in V2.0 on Windows (my collegues computer is not  
updated yet), you can only select layers, tables can't be selected, so you  
can't join them.


I had the very same issue on another dataset with 2000 items some days ago  
(on Win7, V2.4): The "normal" join took ages and produced unreadable field  
names, the Toolbox join didn't work, so in the end I fiddled myself into  
Spatialite to be able to join those darn data sets.


I will stick to the Spatialite approach, but for my collegues, this is  
completely beyond the scope.



Can anyone share their work-flows for joining data which is doable by  
normal dudes too?



Cheers
Bernd

--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] QGIS 2.4.0 Garmin Custom Map Plugin not import Open Layer

[Claudio Rinaldi]

Dears, when I passed from the 2.0 to the new version 2.4.0 I noticed that the 
Open Layer Plug in that I used to crete maps for garmin ar no more imported.
Is this a bug of the new version or I made something wrong?

thank for your help

C.R. ___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Reverting to version 2.2 from 2.4

[Damien Stephens]

Hi if all you want is to get open layers back. Just upgrade the plugin 
(plugins\manage and install plugins\   select  open layers plugin then upgrade.
The layers move to the WEB menu from the PLUGINS menu across the top, but other 
than that they are identical, and I think there are improvements in how the 
open layers plugin works as well - seems to be more stable. I cant tell which 
OSM plugin you need but I guess they will have been upgraded too.

cheers

From: qgis-user-boun...@lists.osgeo.org 
[mailto:qgis-user-boun...@lists.osgeo.org] On Behalf Of Laura O'Grady
Sent: Tuesday, 19 August 2014 6:21 AM
To: qgis-user@lists.osgeo.org
Subject: [Qgis-user] Reverting to version 2.2 from 2.4

Hi all,

I'm using a Windows 7 64-bit machine. I downloaded the installer 
(osgeo4w-setup-x86_64.exe) in the fall of 2013 when I purchased, "Learning QGIS 
2.0" book in the fall of 2013. I only recently installed it and was slightly 
surprised to see version 2.2 install instead of 2.0. I assumed this would not 
be an issue for the tutorials I was going to use to teach myself the program.

I was following one particular QGIS tutorial online through Canvas when I was 
required to install a package in order to complete the task. As a result QGIS 
upgraded to version 2.4, which broke some plug-ins (specifically open layers, 
OSM) that I was using.

I would like to know what is the best method to complete the following tasks:

(1). Remove version 2.4 and ensure there are no hooks remaining on my computer
(2). Re-install version 2.2 (I'm assuming it would be download it from here: 
http://qgis.org/downloads/ , specifically the file 
QGIS-OSGeo4W-2.2.0-1-Setup-x86_64.exe, dated February 26, 2014)
(3). Ensure that adding packages in the future doesn't automatically upgrade my 
version to 2.2 to 2.X.

I can understand the generic installer I was using a few months ago to install 
what I thought was 2.0 actually installed 2.2 but I think I should have been 
asked/warned about the version change from 2.2 to 2.4. Thanks.

Laura


___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user