On 17-1-2010 22:02, Mateusz Loskot wrote:
Does that mean that I can use ogrinfo on a gzipped archive, like
gdalinfo (http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip)?
Yes, it does but...as long as OGR driver performs filesystem
operations using VSI*L API. The problem is that only fe
Jan Hartmann wrote:
> On 16-1-2010 16:03, Mateusz Loskot wrote:
>> Jan Hartmann wrote:
>>
>>> Yes, that is clear, thanks. I see that at the moment only raster files
>>> are supported.
>>> Would it make sense to do this for vector formats too?
>>>
>> The VSI layer is available to all parts
Thanks Frank, I'll try and let you know.
BTW: Perhaps your idea of GML-output for OGR would solve the
Metadata-problem for OGR. Everyone can add whatever data they want to
the GML-file, as long as OGR knows what parts to retrieve to reconstruct
the vector map.
Jan
On 16-Jan-10 21:53, Frank
On 16-1-2010 16:03, Mateusz Loskot wrote:
Jan Hartmann wrote:
Yes, that is clear, thanks. I see that at the moment only raster files
are supported.
Would it make sense to do this for vector formats too?
The VSI layer is available to all parts of GDAL and OGR.
If you scan source code
Jan Hartmann wrote:
> Yes, that is clear, thanks. I see that at the moment only raster files
> are supported.
> Would it make sense to do this for vector formats too?
The VSI layer is available to all parts of GDAL and OGR.
If you scan source code of OGR drivers, you'll find that this feature
is a
Yes, that is clear, thanks. I see that at the moment only raster files
are supported. Would it make sense to do this for vector formats too? I
am thinking of a dump from a large PostGIS database I had to upgrade
from a 32 to a 64 bits server. I didn't like the pgdump format, as I got
in all sor
Jan,
Some GDAL and OGR drivers use a specific API, the VSI File Large API, to
access files. That API mimics the semantics of standard C library IO API :
fopen -> VSIFOpenL
fread -> VSIFReadL
fseek -> VSIFSeekL
Usually that API enables access to large files (> 4 GB) on Unix and
Windows.
Oh, that makes a difference indeed! When I read Frank's long answer,
this was the only point I didn't like. How does this mechanism work?
Jan
On 16-1-2010 12:33, Even Rouault wrote:
I think Frank meant
With Even's work, it is *now* possible for many drivers to to
transparently access compres
On 16-1-2010 3:01, Frank Warmerdam wrote:
Instead, if this is a goal of archiving, I'd suggest archiving
the original data (in a possibly arcane format), and a copy in
a more accessable format likely to still be usable decades later.
That's what we are doing now. It's OK for practical purpose
I think Frank meant
With Even's work, it is *now* possible for many drivers to to
transparently access compressed files using the /vsigzip/ mechanism.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-de
Jan Hartmann wrote:
1) If a map is converted to OGR and converted back, there should be an
option of getting it back byte-identical. Law #1 of archiving: always
make sure that you can get back the original
Jan,
I think this is generally impractical with most OGR formats. In
most cases "ogr2o
Personally, I find GML far too complex to be of practical use (for my
own purposes, mind). The GML 3.1 specification is 595 pages of small
print, almost none of which are part of existing datasets. I just want
to store existing datasets in a system-independent way, and preferably,
to be able to
Jan,
for a vector archival format, surely GML is the nearest equivalent to
Geotiff? That should preserve all information; be vendor neutral; and it be
possible to retrieve all information in the future.
Peter
Jan Hartmann wrote:
I was thinking along the same lines, but more in the direct
I was thinking along the same lines, but more in the direction of OGR as
an archival standard. I have been working with archives and stored maps
all my life and am now busy with lots of digital historical maps. For
raster maps the best storing format is Geotiff, from which all other
formats ca
Dear All,
Mateusz Loskot wrote:
%< Snip
Yes. Also, most applications I've seen using OGR do define their own
data models and translate OGRFeature to features of their own types.
Perhaps it would be interesting to know why they don't use OGRFeature
as a part of their data model, what's missing..
maybe we can check the source codes, and promoted that.
for example: when we get a feature from a layer , not create a new one every
time, just return the same feature, but change the coordinate of features.
___
好玩贺卡等你发，邮箱贺卡全新上线！
Frank Warmerdam wrote:
> Jan Hartmann wrote:
>> On 13-1-2010 21:19, Mateusz Loskot wrote:
>>>
>>> IMHO, it's misunderstanding to consider OGR fully featured data model
>>> and I/O engine to read, write, process and analyse spatial vector data,
>>> especially if performance is a critical factor. IMH
Jan Hartmann wrote:
On 13-1-2010 21:19, Mateusz Loskot wrote:
IMHO, it's misunderstanding to consider OGR fully featured data model
and I/O engine to read, write, process and analyse spatial vector data,
especially if performance is a critical factor. IMHO, there are too many
compromises in O
> > Yes, I see what you mean. But I suggest to the open source community
> > that there is still value in implementing such features, either as
> > part of OGR or another library, even if optimal performance cannot be
> > guaranteed in all scenarios.
>
> Perhaps you'll find these inspiring:
>
> htt
, January 13, 2010 12:53 PM
To: gdal-dev@lists.osgeo.org
Subject: RE: [gdal-dev] Open source vector geoprocessing libraries?
Date: Wed, 13 Jan 2010 10:27:43 -0500
From: "Jason Roberts"
Subject: RE: [gdal-dev] Open source vector geoprocessing libraries?
To: "'Peter J Halls&#
Jan Hartmann wrote:
On 13-1-2010 21:19, Mateusz Loskot wrote:
IMHO, it's misunderstanding to consider OGR fully featured data model
and I/O engine to read, write, process and analyse spatial vector data,
especially if performance is a critical factor. IMHO, there are too many
compromises in OGR
On 13-1-2010 21:19, Mateusz Loskot wrote:
IMHO, it's misunderstanding to consider OGR fully featured data model
and I/O engine to read, write, process and analyse spatial vector data,
especially if performance is a critical factor. IMHO, there are too many
compromises in OGR.
OK, that is
Jason Roberts wrote:
> Mateusz,
>
> Thank you very much for your insight. I have a few more questions I'm
> hoping you could answer.
>
>> Alternative is to try to divide the tasks: 1. Query features from
>> data source using spatial index capability of data source. 2.
>> Having only subject featu
Jan Hartmann wrote:
> On 13-1-2010 2:33, Mateusz Loskot wrote:
>>
>> OGR does not provide any spatial indexing layer common to various
>> vector datasets. For many simple formats it performs the
>> brute-force selection.
>>
> Just curious, would it make sense / be possible to implement indexing
>
> Date: Wed, 13 Jan 2010 10:27:43 -0500
> From: "Jason Roberts"
> Subject: RE: [gdal-dev] Open source vector geoprocessing libraries?
> To: "'Peter J Halls'"
> Cc: 'gdal-dev'
> Message-ID: <008001ca9464$f4059f10$dc10dd...@rober
Jan Hartmann wrote:
Is that so? Reading the OGR API tutorial
(http://www.gdal.org/ogr/ogr_apitut.html), I see that all geometries,
frowm whatever input source, are represented internally as a generic
OGRGeometry pointer, which is a virtual base class for all real geometry
classes (http://www.g
Jason,
Jason Roberts wrote:
Peter,
are you constrained to retaining your data in an ArcGIS compatible format?
We are attempting to build tools that can work with data stored in a variety
of formats. Our current user community uses mostly shapefiles, ArcGIS
personal geodatabases, and ArcGIS
om: Duarte Carreira [mailto:dcarre...@edia.pt]
Sent: Wednesday, January 13, 2010 4:54 AM
To: Jason Roberts
Cc: gdal-dev
Subject: RE: [gdal-dev] Open source vector geoprocessing libraries?
Jason,
Have you looked at GeoKettle [1]? And recently I found GearScape [2], which
seemed very interes
Jan Hartmann wrote:
On 13-1-2010 15:49, Ari Jolma wrote:
Jan Hartmann wrote:
Just curious, would it make sense / be possible to implement
indexing in OGR, something like a
generalized version of Mapserver's shptree, the "quadtree-based
spatial index for a shapefiles"?
http://mapserver.or
GR directly.
At any rate, I'm sure it is nice being able to do all your work in a
spatially-enabled DBMS...
Best,
Jason
-Original Message-
From: Peter J Halls [mailto:p.ha...@york.ac.uk]
Sent: Wednesday, January 13, 2010 2:33 AM
To: Mateusz Loskot
Cc: Jason Roberts; 'gdal-dev&#
On 13-1-2010 15:49, Ari Jolma wrote:
Jan Hartmann wrote:
Just curious, would it make sense / be possible to implement indexing
in OGR, something like a
generalized version of Mapserver's shptree, the "quadtree-based
spatial index for a shapefiles"?
http://mapserver.org/utilities/shptree.
[mailto:mate...@loskot.net]
Sent: Tuesday, January 12, 2010 8:33 PM
To: Jason Roberts
Cc: 'gdal-dev'
Subject: Re: [gdal-dev] Open source vector geoprocessing libraries?
Jason Roberts wrote:
> Mateusz,
>
> I'm not an expert in this area, but I think that big performance
>
Jan Hartmann wrote:
On 13-1-2010 2:33, Mateusz Loskot wrote:
OGR does not provide any spatial indexing layer common to various
vector datasets. For many simple formats it performs the brute-force
selection.
Just curious, would it make sense / be possible to implement indexing
in OGR, some
On 13-1-2010 2:33, Mateusz Loskot wrote:
OGR does not provide any spatial indexing layer common to various
vector datasets. For many simple formats it performs the brute-force
selection.
Just curious, would it make sense / be possible to implement indexing in
OGR, something like a
genera
De: Emilio Mayorga [emiliomayo...@gmail.com]
Enviado: terça-feira, 12 de Janeiro de 2010 18:25
Para: Jason Roberts
Cc: gdal-dev
Assunto: Re: [gdal-dev] Open source vector geoprocessing libraries?
Hi Jason,
This may not be quite what you have in mind, but check out the PySAL
(Open
Jason,
are you constrained to retaining your data in an ArcGIS compatible format?
If so and if you do not have ArcSDE, then what follows may not be much help.
Otherwise, I think it likely that you will find using a DBMS as your data
repository advantageous for many reasons. Apart from the
Jason Roberts wrote:
> Mateusz,
>
> I'm not an expert in this area, but I think that big performance
> gains can be obtained by using a spatial index.
Yes, likely true.
> For example, consider a situation where you want to clip out a study
> region from the full resolution GSHHS shoreline data
ssage-
From: Mateusz Loskot [mailto:mate...@loskot.net]
Sent: Tuesday, January 12, 2010 5:51 PM
To: Jason Roberts
Cc: 'gdal-dev'
Subject: Re: [gdal-dev] Open source vector geoprocessing libraries?
Jason Roberts wrote:
> By integrating with GEOS, OGR can perform various spatia
Jason Roberts wrote:
> By integrating with GEOS, OGR can perform various spatial operations on
> individual geometries, such as buffer, intersection, union, and so on. Is
> there a library that efficiently performs these kinds of operations on
> entire OGRLayers? For example, this library would hav
m/
Jason
*From:* doug_newc...@fws.gov [mailto:doug_newc...@fws.gov]
*Sent:* Tuesday, January 12, 2010 12:29 PM
*To:* Jason Roberts
*Cc:* 'gdal-dev'; gdal-dev-boun...@lists.osgeo.org
*Subject:* Re: [gdal-dev] Open source vector geoprocessing libraries?
Jason,
If you're working with v
hat remains
unresolved.
Best,
Jason
-Original Message-
From: Emilio Mayorga [mailto:emiliomayo...@gmail.com]
Sent: Tuesday, January 12, 2010 1:26 PM
To: Jason Roberts
Cc: gdal-dev
Subject: Re: [gdal-dev] Open source vector geoprocessing libraries?
Hi Jason,
This may not be quite what you h
stGIS appears to provide a richer set of spatial operators.
Jason
From: doug_newc...@fws.gov [mailto:doug_newc...@fws.gov]
Sent: Tuesday, January 12, 2010 12:29 PM
To: Jason Roberts
Cc: 'gdal-dev'; gdal-dev-boun...@lists.osgeo.org
Subject: Re: [gdal-dev] Open source vecto
Hi Jason,
This may not be quite what you have in mind, but check out the PySAL
(Open Source Python Library for Spatial Analytical Functions) project:
http://geodacenter.asu.edu/pysal
I've never used it, and have only looked at a recent presentation
(http://conference.scipy.org/static/wiki/rey_pys
Jason,
If you're working with vector data, why not throw the data into
Postgresql/Postgis, http://postgis.refractions.net, and use the spatial
operators there to select/buffer/intersect the vector geometries as you
describe. http://postgis.refractions.net/documentation/manual-1.4
/ch07.html
Frank,
Thanks for your thoughts on this.
> I'd like to see something along this line happen. I to do it efficiently
> it would be necessary to dig into GEOS past the C interface so that
> a spatial index on a collection of features can be maintained over time
> rather than created and discarded
Jason Roberts wrote:
Dear geospatial software experts,
By integrating with GEOS, OGR can perform various spatial operations on
individual geometries, such as buffer, intersection, union, and so on.
Is there a library that efficiently performs these kinds of operations
on entire OGRLayers?
46 matches
Mail list logo
