Hi,
I've updated the RFC text with the suggestions made during this discussion,
and added the proposed implementation. If nobody has further remarks, I'll
call soon for a vote for its adoption.
Even
> Hi,
>
> This is a call for discussion on "RFC 60: Improved round-tripping in OGR".
>
> http
Howard, Even,
On Tue, Oct 20, 2015 at 2:59 AM, Even Rouault
wrote:
> Hi Howard,
>
> > I agree about the need for the feature, and I think it is a useful
> > addition, but I'll admit to being a bit concerned about the "native"
> > nomenclature. It allows us to incrementally add capability for st
Hi Howard,
> I agree about the need for the feature, and I think it is a useful
> addition, but I'll admit to being a bit concerned about the "native"
> nomenclature. It allows us to incrementally add capability for stuff like
> GeoJSON extensions without having to disrupt the entire API to suppo
I agree about the need for the feature, and I think it is a useful addition,
but I'll admit to being a bit concerned about the "native" nomenclature. It
allows us to incrementally add capability for stuff like GeoJSON extensions
without having to disrupt the entire API to support it.
Because
Just a quick note to say that I reviewed the RFC and like the idea.
I can see this being used someday by the MapInfo TAB/MIF drivers to
carry the native MapInfo styling info, as well as geometry in some cases
(rectangle, roundedrect, text object, etc.) to maintain them between TAB
and MIF file
Kurt,
On Wed, Oct 14, 2015 at 4:20 PM, Kurt Schwehr wrote:
> Sean got what I was meaning to say. Do we want the output to have some
> record of which mode was used. I think the answer is likely no.
>
I agree, no. Without a larger provenance framework of some kind there's not
much to be done w
Placeholder for we I or anybody else gets time to work on metadata
driver(s).
https://trac.osgeo.org/gdal/ticket/6154
Doug,
If you have any key example files that would work well for test coverage,
feel free to attach them to the ticket. I know we need a pretty wide range
or a driver will just
Kurt,
A driver for writing ISO metadata files would be quite welcome. Anything to
make compiling and writing metadata less painful is always a good thing.
:-)
Doug
On Wed, Oct 14, 2015 at 6:20 PM, Kurt Schwehr wrote:
> Sean got what I was meaning to say. Do we want the output to have some
> re
Sean got what I was meaning to say. Do we want the output to have some
record of which mode was used. I think the answer is likely no. And it
reminds me that I need to think about a driver for writing ISO metadata
files. (bleck) The processing steps would go in an xml iso metadata
sidecar.
Kurt, Even:
thanks for continuing the discussion. A couple of comments below.
On Wed, Oct 14, 2015 at 11:21 AM, Even Rouault
wrote:
> Hi Kurt,
>
> > Just gave RFC 60 a quick look. In general, I think we absolutely need
> > this. Some thoughts:
>
> thanks for the comments (by the way, anyone r
Hi Kurt,
> Just gave RFC 60 a quick look. In general, I think we absolutely need
> this. Some thoughts:
thanks for the comments (by the way, anyone reading this mailing list is
welcomed to comment not just PSC members)
>
> - There are users who need the old behavior. We need an easy way to
Just gave RFC 60 a quick look. In general, I think we absolutely need
this. Some thoughts:
- There are users who need the old behavior. We need an easy way to get
that. I think the default should be the more functional RFC 60 way. I see
the -noNativeData flag, so I think this is well covered.
Dear all,
This feature is a boost for GeoJSON users who are extending the format and
users of those extensions. JSON is a naturally extensible format but the
GeoJSON OGR driver stifles development of extensions by passing only the
fully standardized GeoJSON items.
Let's say I want to use ogr2ogr
Hi,
This is a call for discussion on "RFC 60: Improved round-tripping in OGR".
https://trac.osgeo.org/gdal/wiki/rfc60_improved_roundtripping_in_ogr
This RFC defines how to improve better round-tripping in conversion of vector
formats, in particular for GeoJSON extensions.
Best regards,
Even
14 matches
Mail list logo
