Re: [gdal-dev] GDAL 2.1 release plans

[Sean Gillies]

On Fri, Jan 15, 2016 at 7:11 AM, Even Rouault 
wrote:

> Hi,
>
> As I've received lately a few emails asking me about GDAL 2.1, it's time to
> discuss that publicly.
>
> To keep roughly with our yearly cycle, I think we could probably target a
> beta
> 1 for the beginning of April, with possibly the release happening end
> April/beginning May if things go well (optimistic scenario : 3 weeks for
> betas
> + 1 week RCs).
>
> Opinions ? Any candidate for being release manager ?
>
> Cheers,
>
> Even
>

I wish I could raise my hand for the release manager job, but I'm pretty
tied up with the GeoJSON WG.

I like the time frame you've proposed. There's some work in progress I'd
like to see in 2.1 (https://github.com/OSGeo/gdal/pull/98) and 4 weeks
should be enough to finish it.

-- 
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Feature ID propagation in SQLite data source

[Even Rouault]

Le lundi 29 février 2016 14:33:28, Andre Vautour a écrit :
> Hi all,
> 
> When I execute an SQL query on a SQLite source, I am observing that the
> feature identifiers are changing. This was observed using 1.11.1.

See https://trac.osgeo.org/gdal/ticket/5781

> 
> ogrinfo -geom=NO -fid 1227 test2.sqlite
> OGRFeature(roads):1227
>gml_id (String) = Roads.371c00110746
>arc_flag (String) = T
>line_compilation_status (String) = BACKGROUND
>contour_height (Real) = (null)
>line_description (String) = (null)
>line_feature_code (String) = RRARDUR
>line_key (String) = RD6091
>length (Real) = 253.400783404
>num_points (Real) = 42
>line_source_id (String) = USL
>line_theme_number (Real) = 20100
>line_user_number (Real) = 20100
> 
> ogrinfo -geom=NO -sql "select * from roads where length = 253.400783404"
> -dialect sqlite test2.sqlite
> OGRFeature(SELECT):0
>gml_id (String) = Roads.371c00110746
>arc_flag (String) = T
>line_compilation_status (String) = BACKGROUND
>contour_height (Real) = (null)
>line_description (String) = (null)
>line_feature_code (String) = RRARDUR
>line_key (String) = RD6091
>length (Real) = 253.400783404
>num_points (Real) = 42
>line_source_id (String) = USL
>line_theme_number (Real) = 20100
>line_user_number (Real) = 20100
> 
> Shouldn't the ID of the feature remain unchanged instead of going from
> the original 1227 to 0?
> 
> Thanks,
> André
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Feature ID propagation in SQLite data source

[Andre Vautour]

Hi all,

When I execute an SQL query on a SQLite source, I am observing that the 
feature identifiers are changing. This was observed using 1.11.1.


ogrinfo -geom=NO -fid 1227 test2.sqlite
OGRFeature(roads):1227
  gml_id (String) = Roads.371c00110746
  arc_flag (String) = T
  line_compilation_status (String) = BACKGROUND
  contour_height (Real) = (null)
  line_description (String) = (null)
  line_feature_code (String) = RRARDUR
  line_key (String) = RD6091
  length (Real) = 253.400783404
  num_points (Real) = 42
  line_source_id (String) = USL
  line_theme_number (Real) = 20100
  line_user_number (Real) = 20100

ogrinfo -geom=NO -sql "select * from roads where length = 253.400783404" 
-dialect sqlite test2.sqlite

OGRFeature(SELECT):0
  gml_id (String) = Roads.371c00110746
  arc_flag (String) = T
  line_compilation_status (String) = BACKGROUND
  contour_height (Real) = (null)
  line_description (String) = (null)
  line_feature_code (String) = RRARDUR
  line_key (String) = RD6091
  length (Real) = 253.400783404
  num_points (Real) = 42
  line_source_id (String) = USL
  line_theme_number (Real) = 20100
  line_user_number (Real) = 20100

Shouldn't the ID of the feature remain unchanged instead of going from 
the original 1227 to 0?


Thanks,
André
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Standard GDAL format for HDF5?

[jramm]

I was wondering if there would be any interest in a standard GDAL format for
HDF5 files?

The major problem I have with current formats supported by the HDF5 driver
is that they are very application-specific, with requirements on the
structure of groups and group names. 

What I propose would make no assumptions about the file grouping structure,
but require that some attributes are set on the dataset itself:

- Geotransform
- Projection
- NoDataValue

To read a certain dataset, you would pass the driver the 'posix style' path
to the dataset (as per HDF5 docs). I'm not sure how this would fit with the
driver, but perhaps something similar that is done for postgres  (i.e. all
in one string then the elements parsed out):

"/My/Path/To/file.hdf5/path/to/dataset"

This would allow any file structure and for multiple datasets within a file
to support different projections, geotransforms etc etc

Any thoughts?




--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Standard-GDAL-format-for-HDF5-tp5253334.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev