Hi Luigi,
I think you summed up things right.
For the sake of the thread readability, I re-post Mark's answer that for
some reason was not considered a response to this thread by the mailman
list.
--
Feb 27, 2018; 1:47pm
>> Do you have a link to the issues? Does it ignore them or worse?
Th
I agree about GDLA/OGR, and are the positions already expressed in the Mark's PR
but take into account that:
1) maintainer could be Mark (as for other core plugins e.g.
MetaSearch). I agree that having only a maintainer for a complex core
part can be dangerous for quality of the overall project =
> Not sure if the PSC can help here?
Hi Andreas,
I think we can because it is not a technical decision, but a strategic one
about not dividing workforce, and how to not have such situations occur.
I think Mark (and maybe others) have made huge efforts for the new
spatialite provider, that is not m
Hi all,
Thanks all for the discussion around Geopackages, SpatiaLite, etc.
Not sure if the PSC can help here?
To me it seems like many people would prefer that we invest into OGR to
improve the Geopackage support - right? Isn't there consensus on that
already?
So - it would be a matter of i
Hi
I also think as generally policy supporting OGR is a better way to go where
possible.
Regards
Tim
> On 27 Feb 2018, at 23:29, Régis Haubourg wrote:
>
> Thanks Alessandro and Nyall,
> that said, it means that two reviewers are probably not found of having those
> PR integrated as is. Our
Thanks Alessandro and Nyall,
that said, it means that two reviewers are probably not found of having
those PR integrated as is. Our community is based on consensus I think,
Could we raise that topic up to the PSC level?
Thoughts?
Régis
2018-02-27 22:05 GMT+01:00 Nyall Dawson :
> On 28 February 20
On 28 February 2018 at 06:40, Alessandro Pasotti wrote:
> On Tue, Feb 27, 2018 at 12:21 PM, Luigi Pirelli wrote:
>>
>> >
>> > On 27/02/2018 11:12, Mark Johnson wrote:
>> that we get rid of the current provider and rely on GDAL only.
>> >>
>> >> With the 'current provider' I assume you mean t
On Tue, Feb 27, 2018 at 12:21 PM, Luigi Pirelli wrote:
> >
> > On 27/02/2018 11:12, Mark Johnson wrote:
> that we get rid of the current provider and rely on GDAL only.
> >>
> >> With the 'current provider' I assume you mean the Spatialite-Provider.
> >>
> >> Please remember that the Spatial
>
> On 27/02/2018 11:12, Mark Johnson wrote:
that we get rid of the current provider and rely on GDAL only.
>>
>> With the 'current provider' I assume you mean the Spatialite-Provider.
>>
>> Please remember that the Spatialite-Provider was never designed to
>> support GeoPackage.
>>
>> Please
2018-02-27 11:12 GMT+01:00 Mark Johnson :
> >> that we get rid of the current provider and rely on GDAL only.
>
> With the 'current provider' I assume you mean the Spatialite-Provider.
>
> Please remember that the Spatialite-Provider was never designed to support
> GeoPackage.
>
Hi Mark, I didn't
Hi Mark,
On 27/02/2018 11:12, Mark Johnson wrote:
>>> that we get rid of the current provider and rely on GDAL only.
>
> With the 'current provider' I assume you mean the Spatialite-Provider.
>
> Please remember that the Spatialite-Provider was never designed to
> support GeoPackage.
>
> Please
>> that we get rid of the current provider and rely on GDAL only.
With the 'current provider' I assume you mean the Spatialite-Provider.
Please remember that the Spatialite-Provider was never designed to support
GeoPackage.
Please also remember that Gdal/Ogr does not support all aspects of
Spati
On Tue, Feb 27, 2018 at 8:06 AM, Régis Haubourg
wrote:
> Hi Andreas,
> ok, that's clear. You are right, that feature is only for the postgreSQL
> provider currently.
>
> I didn't see any missing requirement in SQLITE v3 - the requirement for
> GPKG - maybe Matthias knows more about that. We also
Hi Andreas,
ok, that's clear. You are right, that feature is only for the postgreSQL
provider currently.
I didn't see any missing requirement in SQLITE v3 - the requirement for
GPKG - maybe Matthias knows more about that. We also use GDAL provider
here, so we might miss some features there and hav
Hi Régis,
Yes - I mean the "transaction group" support. Meaning that multiple
layers can be edited together. Most important issue for us: ability to
link related tables to newly created features without asking the user to
manually save the parent table first.
This all works for Postgis now, but
Hi Andreas,
by transaction support, you mean "transaction group" support ? The one
that allows to edit all the layers in one unique transaction and evaluate
triggers on the fly?
If not, I'm not sure to understand what is lacking currently for your use
case.
Nothing is planned here however.
Reg
16 matches
Mail list logo