I am playing with accessing the Overture data dump, which is multiple
files in each S3 bucket. The doco says that as of 3.6 (check!), with
the libarrow_dataset build (check) I should be able to read directory
collections as layers, but no luck thus far:
AWS_REGION=us-west-2
You are playing with Overture data, yes? I am also poking around
there. That error message seems to be on the Parquet read side rather
than the GeoPKG write.
AWS_REGION=us-west-2 AWS_NO_SIGN_REQUEST=YES ./ogrinfo
Thanks so much Dan, it’s been great having you on patrol these last few months,
and the big changes you got through lay a nice foundation for the future of the
library.
P
> On Feb 27, 2023, at 9:02 AM, Howard Butler wrote:
>
>
>
>> On Feb 27, 2023, at 8:32 AM, Daniel Baston wrote:
>>
>>
+1, sounds wonderful. I'm willing to be the liason to the GDAL / NumFocus
administrators for this work.
P
> On Feb 15, 2022, at 10:11 AM, Regina Obe wrote:
>
> GEOS PSC +1
>
>> -Original Message-
>> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
>> Howard
:
- CAPI: GEOSDistanceWithin, GEOSPreparedDistanceWithin
(#1124, Sandro Santilli)
- Output WKT using positional precision with the ryu
library (#868, Paul Ramsey)
- geosop CLI for GEOS (Martin Davis)
- Full doxygen of the C-API (Paul Ramsey)
- GeometryFixer class for validity enforcement (Ma
This would be something we could put our (PostGIS) OSGeo budget to, perhaps, in
lieu of any other activities going on this year.
P
> On Oct 12, 2021, at 3:00 AM, Darafei Komяpa Praliaskouski
> wrote:
>
> Hello,
>
> ISO SQL/MM has chapters for NURBS and other magical geometry types. The
A new question not answered: what is the current specification for SQL
filters in SetAttributeFilter? Has it evolved beyond this spec
(referenced from the GDAL docs)
http://ogdi.sourceforge.net/prop/6.2.CapabilitiesMetadata.html
P.
On Fri, Apr 29, 2016 at 12:19 PM, Paul Ramsey <p
be, which is
pretty amazing. What happens if an OGR table also has a legit field
named "fid"?
P
On Thu, Apr 28, 2016 at 7:21 PM, Paul Ramsey <pram...@cleverelephant.ca> wrote:
> http://www.gdal.org/ogr__api_8h.html#a4000d426bf26ad7cc7d4012634c93f09
>
> So, the reference
http://www.gdal.org/ogr__api_8h.html#a4000d426bf26ad7cc7d4012634c93f09
So, the reference to valid attribute filters points to
http://ogdi.sourceforge.net/prop/6.2.CapabilitiesMetadata.html
And there it says that
@field_name@ = @string_token@
and that
"The @string_token@ starts with a
Hey all,
We've had a client working with dodgy data who would like an option to
avoid incompatible date mangling when reading bad data. Basically, OGR
will consume some funky dates from CSV and Excel, like /00/00, but
it will NULL out others, like 1971/34/34. The net result is that, when
the
This is a non-sequitur "PostgreSQL/PostGIS that has the default
geometry_storage parameter set to st_geometry”. The ST_Geometry type is an ESRI
thing, and you need to have ESRI dll’s installed in your PostgreSQL/ESRI server
in order to create such a column. That’s Problem #1.
Problem #2 is
I have in the past, with other tool sets, not GDAL, approached this by building
out padded tiles as the first step. So for each tile, merge it with it’s
neighbors, then clip out the middle so you get a somewhat larger tile. Give it
a nice thick buffer.
Now all your tiles overlap. Process them
On March 18, 2015 at 9:53:58 AM, Even Rouault (even.roua...@spatialys.com)
wrote:
It certainly is. I think the performance issue appeared with PostGIS 2.0 when
geometry_columns has become a view.
Probably either the query should just use the
system tables alone, and take advantage
We noticed that in databases with lots of tables, OGR throws some pretty crazy
SQL at the database, and things get slow and the source of the problem seems to
be here:
http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/pg/ogrpgdatasource.cpp#L851
Which in addition to being a big
= n.oid
WHERE t.typname = 'geometry'::name
AND c.relkind in ('r'::char, 'v'::char, 'm'::char, 'f'::char)
AND n.nspname != 'pg_catalog' ;
So, seems a worthwhile effort,
P
--
http://postgis.net
http://cleverelephant.ca
On March 18, 2015 at 10:19:16 AM, Paul Ramsey (pram...@cleverelephant.ca
18, 2015 at 10:09:26 AM, Sandro Santilli (s...@keybit.net) wrote:
On Wed, Mar 18, 2015 at 09:58:20AM -0700, Paul Ramsey wrote:
There’s also a couple new relation types, ‘m’ for materialized
views and ‘f’ for… gah! I don’t know.
I think 'f' is for foreign data tables.
It's surprising
for geometry, once for geography) in the UNION. So nearing
half a second. But still… in the context of a batch process… hm.
P.
--
http://postgis.net
http://cleverelephant.ca
On March 18, 2015 at 10:28:58 AM, Paul Ramsey (pram...@cleverelephant.ca) wrote:
OK, yeah, even w/o populating my
You could use the OGR sql query option to wrap your geometry call in a force2d
or force3d function call in PostGIS?
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
On February 11, 2015 at 9:54:07 AM, Duarte Carreira (dncarre...@gmail.com)
wrote:
Hi there.
I’m trying to figure
at 12:39 PM, Even Rouault
even.roua...@spatialys.com wrote:
Selon Paul Ramsey pram...@cleverelephant.ca:
The PgSQL driver is returning TRUE for OLCFastFeatureCount and then running
SELECT Count(*)â to fulfill the request. Since that is actually going to
apply a full table scan, itâ s
for a fast feature
count? Basically instant (the record count resides in header metadata or
something similar)? Or “fast enough for small things”?
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net___
gdal-dev mailing list
gdal-dev
mask for all types.
Of course, I could be wrong, maybe a snaggletooth is better, but it doesn’t
pass the smell test for me
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
On November 5, 2014 at 7:01:32 AM, Even Rouault (even.roua...@spatialys.com)
wrote:
Hi,
This is a call
Super!
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
On November 5, 2014 at 9:57:44 AM, Even Rouault (even.roua...@spatialys.com)
wrote:
Paul,
Thanks for your remarks
My only concern/note here is with regard to the WKB type numbers for
features with a Z. The RFC seems
tables are missing, etc.
Is it OK to make this change in trunk? In 1.12 or 1.11 branch?
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
new to me (multiple geometry columns, e.g.) and I thought that those
kinds of changes might be leading to a GDAL2 release.
P.
On Wed, Dec 18, 2013 at 1:20 AM, Even Rouault
even.roua...@mines-paris.org wrote:
Le mercredi 18 décembre 2013 06:28:16, Paul Ramsey a écrit :
I don't think we should
OK, so hide the ISO types from the outside world. No problem.
Is it OK to have getGeometryType and exportToWkb accept wkbVariant
optional parameters?
P.
On Tue, Dec 17, 2013 at 1:03 AM, Even Rouault
even.roua...@mines-paris.org wrote:
Selon Paul Ramsey pram...@cleverelephant.ca:
Back
at 1:50 PM, Even Rouault
even.roua...@mines-paris.org wrote:
Le mardi 17 décembre 2013 22:38:26, Paul Ramsey a écrit :
OK, so hide the ISO types from the outside world. No problem.
Is it OK to have getGeometryType and exportToWkb accept wkbVariant
optional parameters?
For exportToWkb
Back to this, is it OK? How are we patching back to SVN? I can convert
it into a patch and attach to a ticket, if that's the path.
P.
On Fri, Dec 13, 2013 at 12:00 PM, Paul Ramsey pram...@cleverelephant.ca wrote:
I’ve pushed up some work to do this
https://github.com/pramsey/gdal/tree/isowkb
.
importFromWkb also was changed to ingest the ISO variant if that’s what it’s
fed. No changes to signature required there.
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
On December 12, 2013 at 2:58:05 PM, Even Rouault (even.roua...@mines-paris.org)
wrote:
Le jeudi 12 décembre
-getGeometryType() != wkbLineString
poLine-getGeometryType() != wkbLineString25D) )
and very few unqualified calls to it.
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
On December 13, 2013 at 12:00:34 PM, Paul Ramsey (pram...@cleverelephant.ca)
wrote:
I’ve pushed up some work to do
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
On December 13, 2013 at 1:21:40 PM, Even Rouault (even.roua...@mines-paris.org)
wrote:
Le vendredi 13 décembre 2013 21:51:57, Paul Ramsey a écrit :
Actually, I think changing the contract on getGeometryType to only ever
no support there now, or is
there?
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
starting an isowkb branch on my git repo to hold this piece of work, I
don’t think it’ll be very big.
Then I’ll start asking about ‘m’ dimensions :)
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
On December 12, 2013 at 2:33:41 PM, Even Rouault (even.roua...@mines-paris.org)
wrote
Sounds good to me. Is wkbVariantOGC the variant currently implemented ? Is
our 3D support really compliant with an OGC standard ?
Not really anymore, since SFSQL 1.2 defined OGC into sync with ISO. We’re in
compliance with the old guidance that was passed and promptly forgotten in the
period
.
--
Paul Ramsey | Boundless
http://boundlessgeo.com/support/postgis
2508850632 | @pwramsey
On Wednesday, November 6, 2013 at 10:54 AM, Paul Ramsey wrote:
Darn, I'm not getting good results for either linking or debugging... set the
DYLD_LIBRARY_PATH and PYTHONPATH
.
--
Paul Ramsey | Boundless
http://boundlessgeo.com/support/postgis
2508850632 | @pwramsey
On Wednesday, November 6, 2013 at 11:38 AM, Even Rouault wrote:
Le mercredi 06 novembre 2013 20:35:46, Paul Ramsey a écrit :
Completely getting nothing... even when I install
loaded its own libgdal, regardless of the value of the
DYLD_LIBRARY_PATH.
So, when working with the GDAL python autotest routines: BEWARE any
GDALs that might be in your frameworks directory.
P.
On Wed, Nov 6, 2013 at 11:41 AM, Paul Ramsey pram...@boundlessgeo.com wrote:
It does, though 'otool -L
Hey all,
I'm preparing to do up a GeoPkg driver. In searching the mail history
and the web, the only references I see so far are suggestions as a
summer of code project (which weren't taken up?) which included the
recommendation of wrapping it into the existing sqlite driver.
Couple questions:
PSC / committers / coders,
If you would join the 2014 code sprint at either of the proposed venues, noting
so on the doodle would be must helpful!
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
Forwarded message:
From: Paul Ramsey pram...@cleverelephant.ca
To: Stephan
FOSS4G-NA (April 10-12, in Washington DC) is shaping up to be very
successful: nearly half of our 400 registration slots are already
filled, and lots of sponsors have signed on. Now it's up to you to
bring the magic!
If you are planning to speak at FOSS4G-NA, you must submit a
presentation
On Mon, Sep 19, 2011 at 12:14 AM, Hermann Peifer pei...@gmx.eu wrote:
On 16/09/2011 16:49, Paul Ramsey wrote:
...perhaps in the FGDB driver we can try and
avoid using the WKT at all when we have a WKID available.
I just disabled the generation of the WKT element in my local copy
On Fri, Sep 16, 2011 at 3:16 AM, Hermann Peifer pei...@gmx.eu wrote:
Frank, Even, Paul, et al.:
Could it perhaps make sense if the morphToESRI() function paid more
attention to these string identifiers in order to produce even more
ESRI-friendly WKT?
Yes, probably we will have to. I wonder
Actually, it would be quite wise to check that... I've noticed
(because I happen to have my working area in a Dropbox folder) the
FGDB API creating transient lock files (gah!!) while in operation.
P.
On Sat, Jul 30, 2011 at 12:40 PM, Ragi Burhum r...@burhum.com wrote:
Do any of the APIs that
Thanks Even, et al, great to be part of the team!
P
On Thu, Jul 21, 2011 at 6:57 AM, Even Rouault
even.roua...@mines-paris.org wrote:
Motion: Extend GDAL/OGR Commit Access to Paul Ramsey
I declare this motion passed with support from PSC members AndreyK, DanielM,
EvenR, FrankW, HowardB
On Wed, Jul 20, 2011 at 2:11 PM, Even Rouault
even.roua...@mines-paris.org wrote:
Paul, could you reply to this message indicating your agreement to the
guidelines listed in:
http://trac.osgeo.org/gdal/wiki/rfc3_commiters
I have read and agree to your draconian terms. :)
P.
that describes how ArcGIS
manages its coordinate systems internally. I hope that helps.
- Ragi
Date: Thu, 30 Jun 2011 13:26:21 -0700
From: Paul Ramsey pram...@cleverelephant.ca
Subject: Re: [gdal-dev] Precision Mystery (FGDB)
To: gdal-dev@lists.osgeo.org
Message-ID
In running a round trip from PostGISFGDBPostGIS for a simple table:
3dgeom=# select st_asewkt(g) from points ;
st_asewkt
SRID=4326;POINT(1 2 3)
SRID=4326;POINT(2 3 4)
SRID=4326;POINT(3 4 5)
When I get to FGDB, I've lost my third dimension (still trying to
the 3rd dimension, maybe better use WGS84-3D, EPSG:4329 ?
-Peter
On 06/30/2011 08:45 PM, Paul Ramsey wrote:
In running a round trip from PostGISFGDBPostGIS for a simple table:
3dgeom=# select st_asewkt(g) from points ;
st_asewkt
SRID=4326;POINT(1 2 3
Hi all (Evan!):
In my FGDB project, the participants compared a file I generated with
FGDBPostGISFGDB and noticed that the coordinates had drifted a
little in some cases. Turns out, the PostGIS OGR driver using WKT as
the transit format, so that's allowing occasional coordinate drift.
I'd like to
, Jun 29, 2011 at 1:04 PM, Frank Warmerdam warmer...@pobox.com wrote:
On 11-06-29 03:56 PM, Paul Ramsey wrote:
Hi all (Evan!):
In my FGDB project, the participants compared a file I generated with
FGDBPostGISFGDB and noticed that the coordinates had drifted a
little in some cases. Turns out
So, the FGDB API works with (mostly) UTF16-encoded wide characters (wstring).
What is the GDAL internal standard for string encoding? Looks like
(from the OLCStringsAsUTF8 capability) there is at least a loose
standard that is looking for UTF8 narrow characters. Are there any
existing utilities
Awesome, exactly what I hoped! Thanks Frank.
P
On Thu, Jun 9, 2011 at 11:26 AM, Frank Warmerdam warmer...@pobox.com wrote:
On 11-06-09 10:33 AM, Paul Ramsey wrote:
So, the FGDB API works with (mostly) UTF16-encoded wide characters
(wstring).
What is the GDAL internal standard for string
this be an option? Like yes, consider the dataset
name? Or no, discard dataset name. I can see myself in both situations...
Is the driver read only? If not, what will happen when you try the reverse?
From PgSql to fgdb?
Duarte
-Mensagem original-
De: Paul Ramsey [mailto:pram
Yes, the magic of the configuration option... that makes much sense.
So by default we will emit simple layer names, but we can be
configured to emit qualified names.
On Tue, May 31, 2011 at 1:23 PM, Even Rouault
even.roua...@mines-paris.org wrote:
Le mardi 31 mai 2011 18:43:15, Paul Ramsey
So, my goal is to map information from FGDB to PostGIS and as much
fidelity as possible.
FGDB includes a class called Feature Dataset which is basically a
folder that holds Feature Class objects, which map directly to OGR
layers. So the Feature Dataset then acts a good deal like a schema
in
So, the FGDB driver right now flattens out the GDB hierarchy a little
(as far as I can tell there is not *too* much to flatted out) which
could maybe (?) result in duplicate layer names... I opened up
Michaels test database and printed out the layer names,
basetable_2
basetable
base_table1
Right now LoadLayers is really really over-determined, checking every
node in the database for every possible child type, and then checking
every child for every child type. Based on practice, is it incorrect
to assume that we can only see the following OGR-readable objects in
the database:
So, the end goal of my wanking around with OGR and FGDB is to write a
utility that will convert FGDB into PostGIS and then back again with
as much fidelity as possible. So ideally the output would look much
like the input. FGDB has some fun stuff that doesn't fit into the OGR
model very well.
. They
are relational tables.
Mike
--
Michael Smith
Remote Sensing/GIS Center
US Army Corps of Engineers
On 4/28/11 1:19 PM, Even Rouault even.roua...@mines-paris.org wrote:
Le jeudi 28 avril 2011 02:11:30, Paul Ramsey a écrit :
I assume the failures are relationships we don't handle yet
Fellow members of the C tribe! I hope the holidays find you in good
spirits, and that you'll consider joining your other tribe members at
the New York Code Sprint early next year:
http://wiki.osgeo.org/wiki/New_York_Code_Sprint_2010
All details and planning on the wiki page. If you want to join
GDAL folks might be interested in reviewing this, to ensure it can
support raster goodness well.
P.
-- Forwarded message --
From: strk s...@keybit.net
Date: Wed, Jan 28, 2009 at 3:39 AM
Subject: [postgis-devel] WKTRaster: RFC1: serialized form
To:
I've started with some higher level ideas for an agenda. Individual
teams might want to start breaking out their plans into work-by-day as
we get closer.
http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009_Agenda
P.
http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009
A reminder, if you're interested in joining a winter code sprint in
Toronto, please sign up at the wiki page:
http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009
Knowing tentative numbers will help us plan better. We're also
looking for sponsors to keep the troops fed and watered.
P.
62 matches
Mail list logo
