Re: [QGIS-Developer] Incremental drawing possible?

[Mark Johnson]

>> QGIS seems to need to draw the entire background in it's head, then
displays it all at once
Yes, this is a problem (it seems) with all of the the Raster rendering.
With a GeoTiff during Panning, the Background blanks out and pops back,
while the Vectors don't.

Hard on the eyes when searching for something.

This started after a commit in 2014. The last version without this problem
was 2014-02-22.

Mark
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Incremental drawing possible?

[Nyall Dawson]

On 11 July 2017 at 13:17, John Abraham  wrote:
> Ok, I overlooked a few features, thanks Nathan for pointing out the refresh
> rate!
>
> I rely on web based tile or WMS backgrounds (OpenStreetMap, NRCan Geogratis,
> etc.).  CityPhi fills in the background as the tiles show up.  QGIS seems to
> need to draw the entire background in it's head, then displays it all at
> once, before it can use the cool multithreaded features on the vectors.  Or
> is there another checkbox for "draw my background as it arrives from the
> tile service, but don't wait around for it to respond"?

How are you adding your web based tile layers?

Since QGIS 2.18 you can add them as "XYZ" tile sources (see
https://www.qgis.org/en/site/forusers/visualchangelog218/index.html#feature-native-support-of-xyz-tile-layers).

If you do this they'll be super-smooth, with tiles being rendered
instantly as they download.

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Incremental drawing possible?

[John Abraham]

n the feature ids.
>> 
>>> Hence in my view such code should really belong
>>> into the OGR provider (or perhaps even ogr itself) and not in the
>>> plugin. Thoughts?
>> 
>> Regarding putting that in OGR itself, there's no such API for that right 
>> now, and I'm not 
>> completely clear of the value to add one (specific use case, for a single 
>> driver)
>> 
>> Perhaps the QGIS OGR provider would be a better place for now.
>> 
>> Even
>> 
>> -- 
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com <http://www.spatialys.com/>
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: 
>> <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170710/138fa822/attachment-0001.html
>>  
>> <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170710/138fa822/attachment-0001.html>>
>> 
>> --
>> 
>> Message: 2
>> Date: Mon, 10 Jul 2017 14:15:46 +0200
>> From: Bernhard Ströbl <bernhard.stro...@jena.de 
>> <mailto:bernhard.stro...@jena.de>>
>> To: qgis-developer <qgis-developer@lists.osgeo.org 
>> <mailto:qgis-developer@lists.osgeo.org>>
>> Subject: Re: [QGIS-Developer] Value entry using comma as decimal
>>  separator?
>> Message-ID: <2f5e52a4-ef66-5cb1-200d-80a1d8d9f...@jena.de 
>> <mailto:2f5e52a4-ef66-5cb1-200d-80a1d8d9f...@jena.de>>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>> 
>> Hi,
>> just my two cents: My users are working in a German administration and 
>> they depend on QGIS having a German UI. They will be puzzled if they are 
>> supposed to use a point instead of the regular komma as decimal 
>> separator. On the other hand they won't expect "5.5" to be a regular 
>> entry into a decimal field either.
>> 
>> Bernhard
>> 
>> Am 08.07.2017 um 09:58 schrieb Richard Duivenvoorde:
>>> On 08-07-17 01:11, Nyall Dawson wrote:
>>> 
>>>> It's a trivial change to make to get the spin boxes to accept the
>>>> local decimal separator, but this would prevent users entering "5.5"
>>>> in those locales.
>>>> 
>>>> Can someone from one of these affected regions let me know what the
>>>> correct behavior should be? I don't want to make the change if it
>>>> breaks entry of 5.5 and that's the standard used in those locales.
>>> 
>>> My personal view:
>>> 
>>> In The Netherlands we also use comma as a decimal separator (don't most
>>> european countries do?), and though I never use the Dutch locale myself,
>>> I know ALL governmental organisations I've been run the Dutch
>>> QGIS/localse just because Windows there is in Dutch (and set the Dutch
>>> locale).
>>> 
>>> I also know in the Spreadsheet world this gives A LOT of trouble because
>>> most average users are not even aware what 'locale' they are using... So
>>> people sending a us-locale spreadsheet to a dutch-locale user is often
>>> in trouble
>>> 
>>> This makes for example so that in modern Banking web applications they
>>> check and you can use both , and . as decimal separator (probably there
>>> is some heuristic in which they check:
>>> - if there is only one type of separator
>>> - if there is one, and it is just 2 position from the end
>>> - it is used as decimal separator
>>> etc etc
>>> But... that is easier when you are only doing currency numbers...
>>> 
>>> I would not try to fight this locale war, or try to be smarter then
>>> Qt/Windows:
>>> IF people use a 'comma'-locale, they should use comma.
>>> IF they do not like that: use us-locale
>>> 
>>> It is the same problem with the character encoding in shapefiles. People
>>> are not aware of what they do, but 'we' as part of the Qt or Windows
>>> should not try to be smarter then that world we are part of.
>>> 
>>> Untill the rest of the world come to their senses and start using the
>>> comma as separator, use 24hr clocks (well preferably 100...), meters,
>>> kilograms etc etc...
>>> 
>>> Regards,
>>> 
>>> Richard Duivenvoorde
>>> ___
>>> QGIS-Developer mailing list
>>> QGIS-Developer@lists.osgeo.org <mailto:QGIS-Developer@lists.osgeo.org>
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer 

Re: [QGIS-Developer] Incremental drawing possible?

[Nathan Woodrow]

Hey John,

QGIS has had multithreaded rendering since 2.0 which allows the map to be
rendered as you pan around so you don't have to wait.  You can also set the
refresh rate in order to draw more features so you get feedback quicker.

Regards,
Nathan

On Tue, Jul 11, 2017 at 2:32 AM, John Abraham <j...@hbaspecto.com> wrote:

> Is incremental drawing possible, especially for web features in the
> background?
>
> I've been playing with some GPU based visualizers lately (in particular
> CityPhi from INRO https://www.inrosoftware.com/en/products/cityphi/ ) and
> switching back to QGIS and waiting for the maps to redraw on every single
> pan or zoom is extremely painful.
>
> GPU-drawn 3D visualizations at 30 frames per second is probably not a
> realistic short-term goal for QGIS. But, what about allowing the graphics
> system to draw the current status of the internal render, before it's
> complete?  For example, if WMS tiles are being downloaded, can the
> background map be updated as data comes in, while the foreground features
> stay on top?  Can layers be shown as they are drawn, instead of popping up
> the entire image after the final layer has been drawn?
>
>
> On Jul 10, 2017, at 9:44 AM, qgis-developer-requ...@lists.osgeo.org wrote:
>
> Send QGIS-Developer mailing list submissions to
> qgis-developer@lists.osgeo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.osgeo.org/mailman/listinfo/qgis-developer
> or, via email, send a message with subject or body 'help' to
> qgis-developer-requ...@lists.osgeo.org
>
> You can reach the person managing the list at
> qgis-developer-ow...@lists.osgeo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of QGIS-Developer digest..."
>
>
> Today's Topics:
>
>   1. Re: QGIS/OGR: FeatureIds reassigned on write to data
>  provider? (Even Rouault)
>   2. Re: Value entry using comma as decimal separator?
>  (Bernhard Ströbl)
>   3. Plugin [1246] go2mapillary approval notification.
>  (nore...@qgis.org)
>   4. Re: QGIS/OGR: FeatureIds reassigned on write to data
>  provider? (Régis Haubourg)
>   5. Re: QGIS/OGR: FeatureIds reassigned on write to data
>  provider? (Even Rouault)
>   6. qgis-bin.exe - Entry Point Not Found (Patrice)
>
>
> --
>
> Message: 1
> Date: Mon, 10 Jul 2017 13:58:57 +0200
> From: Even Rouault <even.roua...@spatialys.com>
> To: qgis-developer@lists.osgeo.org
> Subject: Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write
> to data provider?
> Message-ID: <2643131.9G3uCidT8S@even-i700>
> Content-Type: text/plain; charset="utf-8"
>
> I did some playing around and came up with some FeatureId mapping code
> which is pretty space efficient (basically requiring just
> 3*nDeletedFeatures entries), see below.
>
> The code however assumes that the gaps in the fid-sequence are filled by
> decreasing the fids after the gap, which may be pretty specific to the
> OGR/Shapefile behaviour.
>
>
> This should clearly be restricted to Shapefiles. Other drivers don't have
> this compaction logic
> and will let happily holes in the feature ids.
>
> Hence in my view such code should really belong
> into the OGR provider (or perhaps even ogr itself) and not in the
> plugin. Thoughts?
>
>
> Regarding putting that in OGR itself, there's no such API for that right
> now, and I'm not
> completely clear of the value to add one (specific use case, for a single
> driver)
>
> Perhaps the QGIS OGR provider would be a better place for now.
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> -- next part --
> An HTML attachment was scrubbed...
> URL: <http://lists.osgeo.org/pipermail/qgis-developer/
> attachments/20170710/138fa822/attachment-0001.html>
>
> --
>
> Message: 2
> Date: Mon, 10 Jul 2017 14:15:46 +0200
> From: Bernhard Ströbl <bernhard.stro...@jena.de>
> To: qgis-developer <qgis-developer@lists.osgeo.org>
> Subject: Re: [QGIS-Developer] Value entry using comma as decimal
> separator?
> Message-ID: <2f5e52a4-ef66-5cb1-200d-80a1d8d9f...@jena.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
> just my two cents: My users are working in a German administration and
> they depend on QGIS having a German UI. They will be puzzled if they are
> supposed to use a point instead of the regular komma as decimal
> separator. On the other hand they won't expect "5.5" to be a regular
> entry into a decimal fi

Re: [QGIS-Developer] Debug C++ QGIS plugin with VS

[qdqgisdev]

Hi Jurgen 
thx for your feedback

1°)I will use VS2010 then.
2°)Regarding "RelWithDebInfo" do i need to use Cmake to build ?
I thought CMake was required to build qgis. What we try to do is debugging a
plugin (DLL)
Am I supposed to build the DLL with Cmake ? 

The DLL works fine in release mode but sometimes it crashes and I have no
idea on how to debug step by step.
I'd like to attach to process but when i try to do that i get 
Debug Assertion Failed! Expression: _pFirstBlock == pHead

Upfront THX



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Debug-C-QGIS-plugin-with-VS-tp5324957p5327297.html
Sent from the QGIS - Developer mailing list archive at Nabble.com.
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] rule based style copy+paste bug

[zrx]

Hi Andreas,

Thanks for the answer. I used only one layer with several rule based styles, 
sorry for the bad wording. I copied the styles on the GUI, and when I checked 
the xml file, most of the pasted entities had the same string in their key 
field, which is the id, I guess.

Concerning the bug tracker: thanks for the explanation, I will try the mantra 
thing.

Best regards,
Peter

Andreas Neumann  írta:
>Hi Peter,
>
>How did you copy and paste the layers?
>
>In the QGIS GUI or in the text editor direclty in the XML file? If the 
>latter, then this might be the reason for you troubles. Each layer in 
>QGIS is identified with unique ids. If you copy/paste directly in the 
>XML structure of a .qgs file, you are also duplicating these unique ids, 
>which might explain your troubles.
>
>You know, if all you want is  to filter by year, you don't need a layer 
>for each year, but you can have a single layer and create a rule for 
>each year. Rules can be turned on and off just like layers.
>
>Or you use the QGIS time manager to loop through the years.
>
>--
>
>About bug tracker:
>
>What troubles do you have with the bug tracker? Why is it difficult for 
>you to access? The correct address is https://issues.qgis.org/ - you 
>need an OSGEO login or an OpenID. All information is at 
>http://www.qgis.org/en/site/getinvolved/development/bugreporting.html#qgis-bugreporting
>
>If you don't have an OSGEO account, you first have to ask for a Mantra. 
>This is a measurment against spammers - because OSGEO mailing lists were 
>abused by spammers. You first have to prove that you are really an 
>indiviual person interested in OSGEO.
>
>Please be a bit more precise why you find the QGIS bug tracker difficult 
>to access.
>
>Hope this helps,
>Andreas
>
>On 08.07.2017 15:52, zrx wrote:
>> Hello,
>>
>> Excuse me for posting to the developers list, as I am not a QGIS developer, 
>> but the bug tracker seems to be even more difficult to access.
>>
>> I'd like to call your attention a problem present at least since 2.16, and 
>> which is still there in 2.18.10 :
>>
>> I have an approximately 50 years period of data to be presented 
>> geographically, and each year's corresponding layer should be able to be 
>> turned on/off. I created the first year's layer, then tried to copy+paste 
>> it, and modify the year in each layer's rule. The problem is that the pasted 
>> layers don't seem to be independent. It looks like they are created by some 
>> kind of shallow copy, thus sharing some of their attributes and data fields, 
>> like visibility for example.
>>
>> Please correct this, or give me some hint if I make something wrong. Thanks 
>> in advance,
>> Peter
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>___
>QGIS-Developer mailing list
>QGIS-Developer@lists.osgeo.org
>List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Incremental drawing possible?

[John Abraham]

Is incremental drawing possible, especially for web features in the background?

I've been playing with some GPU based visualizers lately (in particular CityPhi 
from INRO https://www.inrosoftware.com/en/products/cityphi/ 
<https://www.inrosoftware.com/en/products/cityphi/> ) and switching back to 
QGIS and waiting for the maps to redraw on every single pan or zoom is 
extremely painful. 

GPU-drawn 3D visualizations at 30 frames per second is probably not a realistic 
short-term goal for QGIS. But, what about allowing the graphics system to draw 
the current status of the internal render, before it's complete?  For example, 
if WMS tiles are being downloaded, can the background map be updated as data 
comes in, while the foreground features stay on top?  Can layers be shown as 
they are drawn, instead of popping up the entire image after the final layer 
has been drawn?


> On Jul 10, 2017, at 9:44 AM, qgis-developer-requ...@lists.osgeo.org wrote:
> 
> Send QGIS-Developer mailing list submissions to
>   qgis-developer@lists.osgeo.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.osgeo.org/mailman/listinfo/qgis-developer
> or, via email, send a message with subject or body 'help' to
>   qgis-developer-requ...@lists.osgeo.org
> 
> You can reach the person managing the list at
>   qgis-developer-ow...@lists.osgeo.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of QGIS-Developer digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: QGIS/OGR: FeatureIds reassigned on write to  data
>  provider? (Even Rouault)
>   2. Re: Value entry using comma as decimal separator?
>  (Bernhard Ströbl)
>   3. Plugin [1246] go2mapillary approval notification.
>  (nore...@qgis.org)
>   4. Re: QGIS/OGR: FeatureIds reassigned on write to  data
>  provider? (Régis Haubourg)
>   5. Re: QGIS/OGR: FeatureIds reassigned on write to  data
>  provider? (Even Rouault)
>   6. qgis-bin.exe - Entry Point Not Found (Patrice)
> 
> 
> --
> 
> Message: 1
> Date: Mon, 10 Jul 2017 13:58:57 +0200
> From: Even Rouault <even.roua...@spatialys.com>
> To: qgis-developer@lists.osgeo.org
> Subject: Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write
>   to  data provider?
> Message-ID: <2643131.9G3uCidT8S@even-i700>
> Content-Type: text/plain; charset="utf-8"
> 
>> I did some playing around and came up with some FeatureId mapping code
>> which is pretty space efficient (basically requiring just
>> 3*nDeletedFeatures entries), see below.
>> 
>> The code however assumes that the gaps in the fid-sequence are filled by
>> decreasing the fids after the gap, which may be pretty specific to the
>> OGR/Shapefile behaviour. 
> 
> This should clearly be restricted to Shapefiles. Other drivers don't have 
> this compaction logic 
> and will let happily holes in the feature ids.
> 
>> Hence in my view such code should really belong
>> into the OGR provider (or perhaps even ogr itself) and not in the
>> plugin. Thoughts?
> 
> Regarding putting that in OGR itself, there's no such API for that right now, 
> and I'm not 
> completely clear of the value to add one (specific use case, for a single 
> driver)
> 
> Perhaps the QGIS OGR provider would be a better place for now.
> 
> Even
> 
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170710/138fa822/attachment-0001.html>
> 
> --
> 
> Message: 2
> Date: Mon, 10 Jul 2017 14:15:46 +0200
> From: Bernhard Ströbl <bernhard.stro...@jena.de>
> To: qgis-developer <qgis-developer@lists.osgeo.org>
> Subject: Re: [QGIS-Developer] Value entry using comma as decimal
>   separator?
> Message-ID: <2f5e52a4-ef66-5cb1-200d-80a1d8d9f...@jena.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Hi,
> just my two cents: My users are working in a German administration and 
> they depend on QGIS having a German UI. They will be puzzled if they are 
> supposed to use a point instead of the regular komma as decimal 
> separator. On the other hand they won't expect "5.5" to be a regular 
> entry into a decimal field either.
> 
> Bernhard
> 
> Am 08.07.2017 um 09:58 schrieb Richard Duivenvoorde:
>> On 08-07-17 01:11, Nyall Dawson wrote:
>> 
>>> It's a trivial change to make to get the spin boxes to accept the
&g

[QGIS-Developer] qgis-bin.exe - Entry Point Not Found

[Patrice]

I just installed QGIS 2.18.9 on Windows 10 64 bits with the network 
install (64 bits) and I got this error (attached picture).








This was the version I had before formatting my computer and I am still 
using the same OS version as before.


I browsed to the folder and the DLL is indeed there. I have never seen 
that error before.



___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Even Rouault]

On lundi 10 juillet 2017 15:01:56 CEST Régis Haubourg wrote:
> Hi,
> 
> This should clearly be restricted to Shapefiles. Other drivers don't have
> 
> > this compaction logic and will let happily holes in the feature ids.
> 
> What about Mapinfo TAB, which relies on DBF like shapefiles, and dbf files ?

Deleted records are flagged as such in the .dat/.dbf files (with '*' character 
, which is also 
what the Shapefile driver use for non-compacted deleted DBF records) and in the 
.map file. 
There's no compaction logic.

I don't remember of having heard about compatibility issues with MapInfo 
regarding this 
(but my memories can be wrong :-)), so I assume MapInfo does the same

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Régis Haubourg]

Hi,

This should clearly be restricted to Shapefiles. Other drivers don't have
> this compaction logic and will let happily holes in the feature ids.


What about Mapinfo TAB, which relies on DBF like shapefiles, and dbf files?
Just asking, I didn't dig into that in depth.
Régis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [1246] go2mapillary approval notification.

[noreply]

Plugin go2mapillary approval by pcav.
The plugin version "[1246] go2mapillary 1.2" is now approved
Link: http://plugins.qgis.org/plugins/go2mapillary/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Value entry using comma as decimal separator?

[Bernhard Ströbl]

Hi,
just my two cents: My users are working in a German administration and 
they depend on QGIS having a German UI. They will be puzzled if they are 
supposed to use a point instead of the regular komma as decimal 
separator. On the other hand they won't expect "5.5" to be a regular 
entry into a decimal field either.


Bernhard

Am 08.07.2017 um 09:58 schrieb Richard Duivenvoorde:

On 08-07-17 01:11, Nyall Dawson wrote:


It's a trivial change to make to get the spin boxes to accept the
local decimal separator, but this would prevent users entering "5.5"
in those locales.

Can someone from one of these affected regions let me know what the
correct behavior should be? I don't want to make the change if it
breaks entry of 5.5 and that's the standard used in those locales.


My personal view:

In The Netherlands we also use comma as a decimal separator (don't most
european countries do?), and though I never use the Dutch locale myself,
I know ALL governmental organisations I've been run the Dutch
QGIS/localse just because Windows there is in Dutch (and set the Dutch
locale).

I also know in the Spreadsheet world this gives A LOT of trouble because
most average users are not even aware what 'locale' they are using... So
people sending a us-locale spreadsheet to a dutch-locale user is often
in trouble

This makes for example so that in modern Banking web applications they
check and you can use both , and . as decimal separator (probably there
is some heuristic in which they check:
- if there is only one type of separator
- if there is one, and it is just 2 position from the end
- it is used as decimal separator
etc etc
But... that is easier when you are only doing currency numbers...

I would not try to fight this locale war, or try to be smarter then
Qt/Windows:
IF people use a 'comma'-locale, they should use comma.
IF they do not like that: use us-locale

It is the same problem with the character encoding in shapefiles. People
are not aware of what they do, but 'we' as part of the Qt or Windows
should not try to be smarter then that world we are part of.

Untill the rest of the world come to their senses and start using the
comma as separator, use 24hr clocks (well preferably 100...), meters,
kilograms etc etc...

Regards,

Richard Duivenvoorde
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer





__ Information from ESET Mail Security, version of virus signature 
database 15722 (20170710) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Even Rouault]

> I did some playing around and came up with some FeatureId mapping code
> which is pretty space efficient (basically requiring just
> 3*nDeletedFeatures entries), see below.
> 
> The code however assumes that the gaps in the fid-sequence are filled by
> decreasing the fids after the gap, which may be pretty specific to the
> OGR/Shapefile behaviour. 

This should clearly be restricted to Shapefiles. Other drivers don't have this 
compaction logic 
and will let happily holes in the feature ids.

> Hence in my view such code should really belong
> into the OGR provider (or perhaps even ogr itself) and not in the
> plugin. Thoughts?

Regarding putting that in OGR itself, there's no such API for that right now, 
and I'm not 
completely clear of the value to add one (specific use case, for a single 
driver)

Perhaps the QGIS OGR provider would be a better place for now.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write to data provider?

[Sandro Mani]

On 06.07.2017 11:00, Sandro Mani wrote:



On 06.07.2017 10:57, Even Rouault wrote:


On jeudi 6 juillet 2017 10:45:21 CEST Sandro Mani wrote:

> On 05.07.2017 14:56, Sandro Mani wrote:

> >> That could potentially be done using the current OGR API. Basically

> >> in pseudo code, to execute before executing REPACK

> >>

> >> OGR_L_ResetReading(layer)

> >>

> >> char** ignored_fields = CSLAddString(NULL, "OGR_GEOMETRY" );

> >>

> >> OGR_L_SetIgnoredFields( layer, ignored_fields); // for performance.

> >>

> >> CSLDestroy(ignored_fields);

> >>

> >> OGR_L_SetAttributeFilter( layer, NULL )

> >>

> >> OGR_L_SetSpatialFilter( layer, NULL )

> >>

> >> std::map mapOldIdToNewId;

> >>

> >> GIntBig newId = 0;

> >>

> >> while( feature = OGR_L_GetNextFeature(layer) )

> >>

> >> {

> >>

> >> mapOldIdToNewId[OGR_F_GetFID(feature)] = newId;

> >>

> >> newId ++;

> >>

> >> OGR_F_destroy(feature);

> >>

> >> }

> >>

> >> OGR_L_SetIgnoredFields( layer, NULL );

> >

> > Ok cool, that sounds like a plan - I'll give it a shot.

>

> Hmm so while on the provider side it works well, for the geometry

> checker it is turning out to be pretty hard to deal with the changing

> feature ids (just to cite one example: error fixed by merging geometry

> of feature 10 with that of 11, results in {deleted: 10, updated: 11},

> but after the feature id adjustment this would read {deleted: 10,

> updated: 10}, meaning one would need to keep track that deleted: 10

> refers to the old featureid). Not saying that it isn't doable, but the

> complexitiy of properly handling the feature id changes is non-trivial.

>

> So, other suggestion: any objections if I add a method to

> QgsVectorDataProvider to temporarily freeze repacking? I could also add

> a notification informing the user that the shapefile should not be used

> in other applications while repacking is frozen.

My feeling is that QgsOgrDataProvider is already complicated enough 
with its existing tricks. I'm not sure this temporary freeze 
repacking is a right move (how would you decide when you do it ? and 
I'm pretty sure users will not get it, or will have issues if they 
start an algorithm with an external tool that requires packed shapefiles)


It would be something I would call explicitly while the geometry 
checker is active, I think it is safe to assume that users don't 
expect that they can operate on the shapefile while the geometry 
checker is processing it.  It would not add much complexity to the 
provider, just a flag that repacking is frozen, and a setter to set 
that flag. When the flag is set to false, the shapefile is repacked.


I did some playing around and came up with some FeatureId mapping code 
which is pretty space efficient (basically requiring just 
3*nDeletedFeatures entries), see below.


The code however assumes that the gaps in the fid-sequence are filled by 
decreasing the fids after the gap, which may be pretty specific to the 
OGR/Shapefile behaviour. Hence in my view such code should really belong 
into the OGR provider (or perhaps even ogr itself) and not in the 
plugin. Thoughts?


Sandro

---

#include 
#include 
#include 
#include 

typedef int QgsFeatureId;


class FeatureMapping  {

public:
  QgsFeatureId stableToProvider(QgsFeatureId stableId) const
  {
if(mDeletedStableIds.contains(stableId)){
  return -1;
}
// providerId = stableId - nDeletedBeforeStableId
int nDeletedBeforeStableId = std::lower_bound(mDeletedStableIds.begin(), 
mDeletedStableIds.end(), stableId) - mDeletedStableIds.begin();
return stableId - nDeletedBeforeStableId;
  }

  QgsFeatureId providerToStable(QgsFeatureId providerId) const
  {
int i = 0, n = mProviderToStableOffsetKeys.size(), offset = 0;
while(i < n && mProviderToStableOffsetKeys[i] <= providerId) {
  offset += mProviderToStableOffsetValues[i++];
}
return providerId + offset;
  }

  void updateFeatureIdMap(const QList )
  {
for(QgsFeatureId fid : deletedIds) {
  mDeletedStableIds.append(providerToStable(fid));
}
std::sort(mDeletedStableIds.begin(), mDeletedStableIds.end());
int n = mProviderToStableOffsetKeys.size();
for(QgsFeatureId fid : deletedIds) {
  int pos = std::lower_bound(mProviderToStableOffsetKeys.begin(), 
mProviderToStableOffsetKeys.end(), fid) - mProviderToStableOffsetKeys.begin();
  if(pos < n && mProviderToStableOffsetKeys[pos] == fid) {
mProviderToStableOffsetValues[pos] += 1;
  } else {
mProviderToStableOffsetKeys.insert(pos, fid);
mProviderToStableOffsetValues.insert(pos, 1);
++n;
  }
  if(pos + 1 != n && mProviderToStableOffsetKeys[pos+1] -1 == fid) {
mProviderToStableOffsetValues[pos] += 
mProviderToStableOffsetValues[pos+1];
mProviderToStableOffsetKeys.removeAt(pos + 1);
mProviderToStableOffsetValues.removeAt(pos + 1);
--n;
  }
  ++pos;
  while(pos < n) {