On 20/03/18 07:40, Even Rouault wrote:
> https://trac.osgeo.org/gdal/wiki/rfc71_github_migration
+1
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
On 19 March 2018 at 22:17, Even Rouault wrote:
>>
>> "Most visible Trac wiki documentation will have to be revised to point
>> to GitHub?"
>
> I meant everywhere we mention svn, we should point to git/github.
>
>> I think, this means the content is copied to GitHub wiki.
>
> I've not given any tho
> Perhaps, at some point this could move to gh-pages completely.
>
Possibly, I don't see any emergency for that.
> "Most visible Trac wiki documentation will have to be revised to point
> to GitHub?"
I meant everywhere we mention svn, we should point to git/github.
>
> I think, this means the
On 19 March 2018 at 21:40, Even Rouault wrote:
> Hi,
>
> To follow our processes, I've initiated a RFC related to the migration to
> GitHub
>
> https://trac.osgeo.org/gdal/wiki/rfc71_github_migration
A few comments:
"5. The cron job on the OSGeo server that refreshes the website (...)"
Perhaps,
Hi,
To follow our processes, I've initiated a RFC related to the migration to
GitHub
https://trac.osgeo.org/gdal/wiki/rfc71_github_migration
In the hope to finally go from recuring discussions that have occured during
the past years to a concrete end result, I've clearly simplified the process
Hi Jukka,
> My first vote as PSC member:
>
> +1
I didn't call yet for the formal vote, but thanks for your support.
>
> No doubt the feature will be useful and I trust that RFC is technically
> sound.
>
> I wonder why the list of affected drivers does not include any of the
> JPEG2000 drivers. D
My first vote as PSC member:
+1
No doubt the feature will be useful and I trust that RFC is technically sound.
I wonder why the list of affected drivers does not include any of the
JPEG2000 drivers. Don't they need changes or is metadata handling in
JPEG2000 special in some way? I guess that the
> The reader in the BAG directory is a bare minimum implementation. Out side
> of BAGs there is definitely a need. Pardon my ignorance, but what is CSW?
OGC CSW (Catalog Service Webservice) :
http://www.opengeospatial.org/standards/cat
And there are a few OSGeo related projects around this :
Does that include the upcoming ISO19115-1 ?
Doug
On Wed, Oct 23, 2013 at 10:29 AM, Even Rouault wrote:
> Kurt,
> >
> > I have been trying to think through how an OGR driver for ISO19115 /
> 19139
> > would work.
>
> Do you mean a driver that would read (and/or write) ISO 19139 XML files ?
> D
Still just trying to think it through, but, on the read side, really all I
would expect from such a driver would be that it would get the bounding box and
perhaps pull a few key fields for the GDAL metadata records. So I was thinking
just a single feature.
On Oct 23, 2013, at 7:29 AM, Even Rou
Kurt,
>
> I have been trying to think through how an OGR driver for ISO19115 / 19139
> would work.
Do you mean a driver that would read (and/or write) ISO 19139 XML files ? Do
such documents fit (enough) well with the OGR data model ? Is there a concept
of record/feature ? I'm unfortunately n
Even,
I have been trying to think through how an OGR driver for ISO19115 / 19139
would work. I'm going to work on a band aid to the new BAG tweak to their ISO
metadata, but we definitely could use a bare driver for read / write. The
quest boils down to what is the minimal set of things that
Le dimanche 20 octobre 2013 18:21:23, Frank Warmerdam a écrit :
> Even,
>
> I'm happy with this RFC. It's a bit sad that the list of domains is
> duplicated and has to be freed again by the caller, but it certainly
> avoids any doubts about the lifetime of the returned list.
Hi Frank,
Indeed, f
Even,
I'm happy with this RFC. It's a bit sad that the list of domains is
duplicated and has to be freed again by the caller, but it certainly
avoids any doubts about the lifetime of the returned list.
I have an internal driver here at Planet Labs where I tree any subnode
in our JSON metadata fo
Le dimanche 20 octobre 2013 11:38:24, xavier lhomme a écrit :
> Hi
> Is there a way to export Metadata in a XML form (ISO 19139 XML
> implementation of ISO 19115 ) ?
Xavier,
This is clearly out of the scope of this RFC.
Apart from a few basic items ( raster dimensions, tiling, geotransform/GCP
Hi
Is there a way to export Metadata in a XML form (ISO 19139 XML
implementation of ISO 19115 ) ?
xav
2013/10/19 Even Rouault
> Hi,
>
> This is a call for discussion for "RFC 43
> GDALMajorObject::GetMetadataDomainList()" :
>
> http://trac.osgeo.org/gdal/wiki/rfc43_getmetadatadomainlist
>
>
Hi,
This is a call for discussion for "RFC 43
GDALMajorObject::GetMetadataDomainList()" :
http://trac.osgeo.org/gdal/wiki/rfc43_getmetadatadomainlist
Beginning of the RFC inline :
"""
== Summary ==
This (mini)RFC proposes a new virtual method, GetMetadataDomainList(), in the
GDALMajorObject
2013/10/6 Even Rouault
>
> My rationale was that we have already a few methods that take an approx
> flag
> (e.g. GetFeatureCount(), CreateField() ), but I don't feel very strongly
> for
> one way or the other one.
>
>
Even,
Yes it's not a significant question indeed. I like Jürgen's original
ve
2013/10/6 Jürgen E.
>
> int iDstField = bExactFieldNameMatch?
> poDstFDefn->GetFieldIndex(poSrcFieldDefn->GetNameRef()) :
> poDstLayer->FindFieldIndex(poSrcFieldDefn->GetNameRef());
>
>
Ah yes, this is what I wanted to say. No additional method would be
required.
Tamas
__
Le dimanche 06 octobre 2013 22:21:52, Tamas Szekeres a écrit :
> Hi Jürgen,
>
> The commit you're referring to, doesn't seem contain the handling of the
> bExactMatch parameter at the driver. At the moment I consider this a bit
> redundant if calling OGRLayer::FindFieldIndex with bExactMatch = TRU
Hi Tamas,
On Sun, 06. Oct 2013 at 22:21:52 +0200, Tamas Szekeres wrote:
> The commit you're referring to, doesn't seem contain the handling of theÂ
> bExactMatch parameter at the driver. At the moment I consider this a bit
> redundant if calling OGRLayer::FindFieldIndex with bExactMatch = TRUE doe
Hi Jürgen,
The commit you're referring to, doesn't seem contain the handling of the
bExactMatch parameter at the driver. At the moment I consider this a bit
redundant if calling OGRLayer::FindFieldIndex with bExactMatch = TRUE does
the same as OGRLayer::GetFieldIndex. In this regard I'd be in favo
Hi Tamas,
On Sun, 06. Oct 2013 at 20:05:18 +0200, Tamas Szekeres wrote:
>Looks like a good proposal.
>The only thing I'm uncertain about whether the driver should do something
>different when calling OGRLayer::FindFieldIndex with bExactMatch = TRUE
>than when calling OGRLayer::GetF
Jürgen,
Looks like a good proposal.
The only thing I'm uncertain about whether the driver should do something
different when calling OGRLayer::FindFieldIndex with bExactMatch = TRUE
than when calling OGRLayer::GetFieldIndex? I don't see the driver
implementation in the pull request which would pro
Hi,
This is a call for discussion for "RFC 42: OGR Layer laundered field lookup":
http://trac.osgeo.org/gdal/wiki/rfc42_find_laundered_fields
It proposes a new method in the OGR layer class (and a C API) to lookup indexes
of fields, whose names have been altered by drivers (eg. by LAUNDER in OC
Hi,
I've added the following note in the RFC :
"""
Note: before RFC41, SetGeometry() or SetGeometryDirectly() could work on a
feature whose feature definition had a GetGeomType() == wkbNone (which was
inconsistant). This will be no longer the case since the size of the
papoGeometries array is now
Am Mittwoch, 24. Juli 2013, 16.07:49 schrieb Andreas Neumann:
> I can't comment about the technical issues. But from a user point of
> view there is a need to have more than one geometry representation per
> feature. There could be several generalizations attached to a feature,
> or different state
Le mercredi 24 juillet 2013 18:42:59, Frank Warmerdam a écrit :
> Even,
>
> An excellent proposal!
>
> I'm a bit sad about GetSpatialRef() on the first geometry field not
> necessarily returning the right value for old drivers. I'd suggest we make
> a quick pass through the checked in drivers on
Even,
An excellent proposal!
I'm a bit sad about GetSpatialRef() on the first geometry field not
necessarily returning the right value for old drivers. I'd suggest we make
a quick pass through the checked in drivers once your core work is done to
update them.
I'd be interested in implementing m
Le mercredi 24 juillet 2013 16:07:49, Andreas Neumann a écrit :
> Hi,
>
> I can't comment about the technical issues. But from a user point of
> view there is a need to have more than one geometry representation per
> feature. There could be several generalizations attached to a feature,
> or diff
Hi,
I can't comment about the technical issues. But from a user point of
view there is a need to have more than one geometry representation per
feature. There could be several generalizations attached to a feature,
or different states.
I would welcome such a feature in OGR.
I guess Swisstopo als
On Jul 24, 2013, at 8:47 AM, Even Rouault wrote:
> Too verbose maybe ;-) , since you probably missed the (discrete) mention to
> the OLCCreateGeomField capability (at layer level since CreateGeomField() is
> a
> OGRLayer method)
Indeed. Thanks for a thorough RFC. Now people can move on to arg
> Impressive, logical, complete, and verbose.
>
> The only small addition I might suggest is a driver capabilities flag to
> announce whether or not it has multiple geometry field support. It could
> simply be the driver that has not been updated to support multiple
> geometry fields or the fact t
On Jul 24, 2013, at 7:49 AM, Even Rouault wrote:
> Hi,
>
> This is a call for discussion for "RFC 41 : Support for multiple geometry
> fields in OGR" :
>
> http://trac.osgeo.org/gdal/wiki/rfc41_multiple_geometry_fields
>
> As an introduction, you'll find below the first paragraphs of the RFC
Hi,
This is a call for discussion for "RFC 41 : Support for multiple geometry
fields in OGR" :
http://trac.osgeo.org/gdal/wiki/rfc41_multiple_geometry_fields
As an introduction, you'll find below the first paragraphs of the RFC. Much
more
to read at the above link !
== Summary ==
Add read/w
m: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-
> boun...@lists.osgeo.org] On Behalf Of Frank Warmerdam
> Sent: 14. april 2012 22:40
> To: Even Rouault
> Cc: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] Call for discussion for "RFC38 - OGR Faster Open"
>
>
On Sat, Apr 14, 2012 at 1:36 PM, Even Rouault
wrote:
> Le samedi 14 avril 2012 22:21:53, Frank Warmerdam a écrit :
>> Even,
>>
>> I am generally in favor of this, but I aspire in GDAL 2.0 to migrate
>> OGR to using GDALDriver mechanisms which would include being based
>> around GDALOpenInfo. I am
Le samedi 14 avril 2012 22:21:53, Frank Warmerdam a écrit :
> Even,
>
> I am generally in favor of this, but I aspire in GDAL 2.0 to migrate
> OGR to using GDALDriver mechanisms which would include being based
> around GDALOpenInfo. I am not sure if it is better to make the
> GDALOpenInfo change
Even,
I am generally in favor of this, but I aspire in GDAL 2.0 to migrate
OGR to using GDALDriver mechanisms which would include being based
around GDALOpenInfo. I am not sure if it is better to make the
GDALOpenInfo change as part of that broader effort or as a distinct
RFC and work item.
Best
Hi,
This is a call for discussion for "RFC38 - OGR Faster Open" :
http://trac.osgeo.org/gdal/wiki/rfc38_ogr_faster_open
Summary
---
It is proposed that the OGR datasource opening mechanism relies on the
GDALOpenInfo class, already used by GDAL drivers, to speed-up datasource
openi
40 matches
Mail list logo
