On Mon, Jan 14, 2019 at 7:45 PM James Klassen wrote:
> Have you tried -nlt CONVERT_TO_CURVE ?
>
I hadn't considered converting to curve. The data set contains 146970
linestrings total. 2,329 of those are multicurve. Skipping failures could
give two tables, one multilinestring and one multicurve.
Have you tried -nlt CONVERT_TO_CURVE ?
On Mon, Jan 14, 2019, 20:47 Clifford Snow
>
> On Mon, Jan 14, 2019 at 5:46 PM Simon (SPDBA) Greener <
> si...@spatialdbadvisor.com> wrote:
>
>> Could you not create a table with a generic geometry column without
>> typmodbor constraints? The tell ogr2ogr not
On Mon, Jan 14, 2019 at 5:46 PM Simon (SPDBA) Greener <
si...@spatialdbadvisor.com> wrote:
> Could you not create a table with a generic geometry column without
> typmodbor constraints? The tell ogr2ogr not to overwrite the extant table?
>
The overwrite is just to test importing data. I've tested
Could you not create a table with a generic geometry column without typmodbor
constraints? The tell ogr2ogr not to overwrite the extant table?
Sent from BlueMail
On 15 Jan. 2019, 11:45, at 11:45, Clifford Snow wrote:
>I went back over my efforts to gather all of the Washington State
>countie
I went back over my efforts to gather all of the Washington State counties
road networks into PostGIS. I was mistaken when I said the problem was in
shapefiles, it turns out I'm seeing multicurves in FileGDB. I apologize for
reporting the problem as a shapefile issue. It's a FileGDB issue.
On to F
As others said, indexing time is proportional to table size (actually more
like O( N logN )). So if the number of rows is reduced the index build
time will decrease.
In a recent blog post Paul listed some ideas about how index build
performance could be improved via parallelization [1]. But tha
I've created https://trac.osgeo.org/postgis/ticket/4296
--
Raúl Marín Rodríguez
carto.com
___
postgis-users mailing list
postgis-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-users
On Mon, Jan 14, 2019 at 5:48 PM Raúl Marín Rodríguez
wrote:
> > I don't think we have faced this issue with upgrade in the past...
>
> Before PG11, Postgis didn't need to check the Postgresql release at runtime
> in the SQL code. As a reference, in the function `_postgis_pgsql_version`
> we are d
> I don't think we have faced this issue with upgrade in the past...
Before PG11, Postgis didn't need to check the Postgresql release at runtime
in the SQL code. As a reference, in the function `_postgis_pgsql_version`
we are doing the same pattern matching (`PostgreSQL ([0-9\.]+)`).
I think we s
On Mon, Jan 14, 2019 at 4:57 PM Raúl Marín Rodríguez
wrote:
> > We are testing with EnterpriseDB's version of PG but in PG it would be
> PostgreSQL 10.6.
>
> Does EnterpriseDB's fork change the output of version(). If so, that's
> the issue.
>
That's the string...
EnterpriseDB 10.6.13
I don't
> We are testing with EnterpriseDB's version of PG but in PG it would be
> PostgreSQL 10.6.
Does EnterpriseDB's fork change the output of version(). If so, that's
the issue.
--
Raúl Marín Rodríguez
carto.com
___
postgis-users mailing list
postgis-user
Hi Ashan,
are you able to provide the exact string being reported to 'select
version()'? A screen shot or photo will be good. (rephrased "it's going to
be ..." not.)
пн, 14 янв. 2019 г. в 14:46, Ahsan Hadi :
> On Mon, Jan 14, 2019 at 4:15 PM Raúl Marín Rodríguez <
> rmrodrig...@carto.com> wrote:
On Mon, Jan 14, 2019 at 4:15 PM Raúl Marín Rodríguez
wrote:
> > it is PG 10.6
>
> Can you share the full string? It seems there is an issue with the
> pattern matching.
>
We are testing with EnterpriseDB's version of PG but in PG it would be
PostgreSQL 10.6.
It seems that it is looking for a ca
> it is PG 10.6
Can you share the full string? It seems there is an issue with the
pattern matching.
--
Raúl Marín Rodríguez
carto.com
___
postgis-users mailing list
postgis-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-users
On Mon, Jan 14, 2019 at 3:53 PM Raúl Marín Rodríguez
wrote:
> What does `Select version()` show?
>
it is PG 10.6
>
> On Mon, Jan 14, 2019 at 11:46 AM Ahsan Hadi
> wrote:
> >
> > Select CASE WHEN split_part(s,'.',1)::integer > 9 THEN
> > db1-# split_part(s,'.',1) || '0' ELSE split_part(s,'.',
What does `Select version()` show?
On Mon, Jan 14, 2019 at 11:46 AM Ahsan Hadi wrote:
>
> Select CASE WHEN split_part(s,'.',1)::integer > 9 THEN
> db1-# split_part(s,'.',1) || '0' ELSE split_part(s,'.', 1) ||
> db1-# split_part(s,'.', 2) END AS v
> db1-# FROM substring(version(), 'PostgreSQL ([0-
Select CASE WHEN split_part(s,'.',1)::integer > 9 THEN
db1-# split_part(s,'.',1) || '0' ELSE split_part(s,'.', 1) ||
db1-# split_part(s,'.', 2) END AS v
db1-# FROM substring(version(), 'PostgreSQL ([0-9\.]+)') AS s;
v
---
(1 row)
On Mon, Jan 14, 2019 at 2:35 PM Raúl Marín Rodríguez
wrote:
> Hi
I see, thank you very much for these enlightenments.
I think it would be nice to add this support to PostGIS. I think it is
possible to mix PostGIS Topology and PgRouting to get a similar result so
maybe it does not worth it. I will try such a mix when I have some time.
Thanks again,
Regards,
Adrie
Hi Ahsan,
It seems there is some error with the version detection mechanism as
it's detecting PG11+.
Can you please check what's the output of:
{{{
Select CASE WHEN split_part(s,'.',1)::integer > 9 THEN
split_part(s,'.',1) || '0' ELSE split_part(s,'.', 1) ||
split_part(s,'.', 2) END AS v
FROM sub
Hi,
I have trying to upgrade from postgis 2.4.1 to postgis 2.4.6 for PG 10
sever. I am getting the following error when doing in alter command..
*ALTER EXTENSION postgis_topology UPDATE;*
ERROR: column proc.prokind does not exist
LINE 15: ... = 'e' and e.extname = $1 and c.relname = $2 AND (proc
20 matches
Mail list logo
