[gdal-dev] GDAL NuGet Package

[drp33t]

Hi,

I am wondering there are any plans to update the version of the GDAL package
in NuGet? Currently the stable release is at version 1.9 (released
2012-12-20) and there is also a pre-release alpha for 1.10 (last updated
2014-01-08).

It would be very beneficial for my work if either 1.10 or 1.11 were
available through NuGet. I am willing to help update / maintain the NuGet
packages if needed.

Regards,
Peet Whittaker



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/gdal-dev-GDAL-NuGet-Package-tp5201018.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

Re: [gdal-dev] GDAL NuGet Package

[Tamas Szekeres]

I've planned to provide nuget packages from the binaries provided at
http://www.gisinternals.com/ long ago, but I had no time to include this
support so far.

The corresponding ticket can be found here:

https://github.com/gisinternals/buildsystem/issues/9

The key features of the packaging should be:

1. Support multiple Visual Studio versions.
2. Support the selection of x86/x64.
3. Support release versions as well as and daily built updates.
4. Packaging should fit into the automated build process (should be done
using command line tools).


Any help would be appreciated have this setup realized.

Best regards,

Tamas



2015-04-13 10:54 GMT+02:00 drp33t :

> Hi,
>
> I am wondering there are any plans to update the version of the GDAL
> package
> in NuGet? Currently the stable release is at version 1.9 (released
> 2012-12-20) and there is also a pre-release alpha for 1.10 (last updated
> 2014-01-08).
>
> It would be very beneficial for my work if either 1.10 or 1.11 were
> available through NuGet. I am willing to help update / maintain the NuGet
> packages if needed.
>
> Regards,
> Peet Whittaker
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/gdal-dev-GDAL-NuGet-Package-tp5201018.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
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Alternative of GdalBuildVrt.Exe

[Yuta Sato]

Dear GDAL Developers and Users:

Is there alternative of GdalBuildVrt.Exe in order to write a VRT file that
includes the files to be mosaicked directly from Python?

Thanks.

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

[gdal-dev] create GeospatialPDF using Python

[Luca Delucchi]

Hi all,

I'm trying to create a new GeospatialPDF using Python.

I should be able to create GeospatialPDF with vector, raster and both.

For vector it seems quite simple, just writing a new vector and insert
all features but I'm not able to create it, my code [0] is not
returning any error but I cannot find the output file

For raster should I use CreateCopy? I was able to create a PDFand see
it with a PDF viewer but GDAL doesn't identify it as GeospatialPDF
[1].
Should I add a "Creation Options" of GeospatialPDF driver?

To create a GeospatialPDF with raster and vector (on top of raster)
should I use gdal driver and use "Creation Options" to add the other
layers?
How the "Creation Options" should be passed to CreateCopy?

Thanks
Luca

[0] http://pastebin.com/V8aNqWXD
[1] http://pastebin.com/gNu2gbtF

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Alternative of GdalBuildVrt.Exe

[Jukka Rahkonen]

Yuta Sato  gmail.com> writes:

> 
> Dear GDAL Developers and Users:
> Is there alternative of GdalBuildVrt.Exe in order to write a VRT file that
includes the files to be mosaicked directly from Python?

Hi,

I would try what this can do:

 
http://trac.osgeo.org/gdal/browser/branches/1.6/gdal/swig/python/samples/gdal_vrtmerge.py

-Jukka Rahkonen-

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

[gdal-dev] GDAL 2.0 release plans

[Even Rouault]

Hi,

Some time ago, I mentionned my proposal of issuing a first GDAL 2.0 beta 
version for the end of this month (April 30th). Are there objections to 
sticking with that plan ? Does someone need a bit more time to finish an 
ongoing work ?

And if things go well with this beta (and potentially other beta(s) needed), 
we could try a release candidate for end of May. One month of beta phase might 
seem a bit short, but I'm not sure extending the beta testing period more will 
bring significant additional feedback (and things tend to slip, so better aim 
for a tight schedule). Thoughts ?
Anyone using GDAL intensively and/or interesting in 2.0 should already track 
trunk closely ;-)

I can wear the hat of 2.0 release manager, but I'm happy to let it to any 
other volunteer.

Best regards,

Even

-- 
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

Re: [gdal-dev] GDAL 2.0 release plans

[Dmitriy Baryshnikov]

Hi Even,

I was very busy with other projects, but now I have some spare time to do:
1) Integrate GSoC'14 GNM by Mikhail Gusev. He finished most of work, but 
I need to review his code.
2) Add support for ArcGIS Server REST API to WMS driver. It'll be very 
good to add this functionality to GDAL v.2
3) Add support for metadata numerous imagery satellites (Alos, EROS, 
Formosat, Kompsat, Landsat, Pleiades, RepidYey, Spot, Resurs-DK).
All this code is in our reposity on github, and I only need to merge it 
with trunk (also add some tests).


Give me this week, on weekend I can say if I need more time to integrate 
this work to GDAL trunk.


Best regards,
Dmitry

13.04.2015 15:01, Even Rouault пишет:

Hi,

Some time ago, I mentionned my proposal of issuing a first GDAL 2.0 beta
version for the end of this month (April 30th). Are there objections to
sticking with that plan ? Does someone need a bit more time to finish an
ongoing work ?

And if things go well with this beta (and potentially other beta(s) needed),
we could try a release candidate for end of May. One month of beta phase might
seem a bit short, but I'm not sure extending the beta testing period more will
bring significant additional feedback (and things tend to slip, so better aim
for a tight schedule). Thoughts ?
Anyone using GDAL intensively and/or interesting in 2.0 should already track
trunk closely ;-)

I can wear the hat of 2.0 release manager, but I'm happy to let it to any
other volunteer.

Best regards,

Even



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

Re: [gdal-dev] Add Mercator_variant_A method?

[Andre Vautour]

On 2015-04-12 19:51, Even Rouault wrote:

Le samedi 11 avril 2015 15:19:48, Brad Hards a écrit :

On Tue, 7 Apr 2015 07:12:20 AM Jukka Rahkonen wrote:

I felt that document somehow heavy to read but it appears in many places
that "Mercator variant A" is the primary name since October 2010. This
section is from page 34 (of 143)


I am not sure I follow what this has to do with the projection name in 
WKT. The newer WKT specification (ISO 19162) relies solely on the 
identifier to determine which operation method to use to project 
coordinates, but the older WKT tends to follow OGC 01-009 which lists 
explicit names to use for the projections. So regardless of what the 
EPSG registry uses for a name, this is the name that is supposed to be 
used for the OGC WKT as far as I am concerned:

OGC 01-009 (http://www.opengeospatial.org/standards/ct): "Mercator_1SP"

Does someone know of another WKT spec that uses that "Mercator variant 
A" name, or I am missing something?

OK, where do I fix geopackage behaviour - in OGR general, or in geopackage
format handler?
I would ask if this is not a bug in the geopackage itself or whatever 
created that WKT string. After all, it looks like the name used does not 
follow the WKT standard.

It depends on how you want to fix that.

If your intent if to have Mercator_variant_A preserved in the WKT after
importing it from GPKG, you will likely to have to edit several places in the
code base to avoid direct string comparisons with SRS_PT_MERCATOR_1SP as done
currently, but rather use a new
OGRSpatialReference::IsProjectionMethodAliasOf() or something like that.

Otherwise you can add a normalizing method in OGRSpatialReference
("morphFromModernEPSG" ??) and call it from the GPKG driver. In my opinion,
that would be the easiest and less risky way of fixing the issue.
I'm not opposed to mapping that "Mercator variant A" name to 
SRS_PT_MERCATOR_1SP on WKT import, but I think there's a limit to how 
far one should go to support non-standard WKT. I am not sure what modern 
EPSG names have to do with the explicitly named WKT projection strings 
that are defined in the actual specification, even spatialreference.org 
is still using "Mercator_1SP" for the OGC WKT.


I see exposing (exporting) Mercator_variant_A instead of Mercator_1SP as a
potential source of incompatibilities with other software, so if we were going
onto that road, especially using it as the new default name, we should try to
have a clear view of what is going to break outside of the GDAL world.
Although I see GeoTools added a few years ago "Mercator (variant A)" as an
alias :
https://github.com/geotools/geotools/commit/7fb010411eaf4210fb061f1f7dab6672d364830a
Not sure if that's enough to make them recognize "Mercator_variant_A" also.
Perhaps Robert as an idea about that since he was the author of that change ?
And I guess they still use Mercator_1SP as the main name when they export WKT
?
Apparently GvSIG also added "Mercator_(variant_A)" as an alias:
https://redmine.gvsig.net/redmine/issues/2624
Was that for interacting with WKT explicitly, or just for naming the 
projection in general?


http://epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::3395 can 
use a better name, as the WKT is based on ISO 19162 which uses the 
identifier for the operation method. In other words, the name no longer 
is used to determine the method, but 
http://spatialreference.org/ref/epsg/3395/prettywkt/ still uses 
"Mercator_1SP" as, in the OGC standard I listed above, that is what the 
name has to be.




Even


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

Re: [gdal-dev] Add Mercator_variant_A method?

[Even Rouault]

André,

> 
> I am not sure I follow what this has to do with the projection name in
> WKT. The newer WKT specification (ISO 19162) relies solely on the
> identifier to determine which operation method to use to project
> coordinates,

Do you know if there's a publicly available version of ISO 19162 ? I could 
only find this draft on OGC website: 
https://portal.opengeospatial.org/files/?artifact_id=54797 ( accessible from 
http://www.opengeospatial.org/standards/requests/112?utm_source=emailcampaign219&utm_medium=phpList&utm_content=HTMLemail&utm_campaign=The+OGC+requests+comment+on+the+candidate+standard+Geographic+Information+%E2%80%93+Well+Known+Text+for+coordinate+reference+systems
 
)

> but the older WKT tends to follow OGC 01-009 which lists
> explicit names to use for the projections. So regardless of what the
> EPSG registry uses for a name, this is the name that is supposed to be
> used for the OGC WKT as far as I am concerned:
> OGC 01-009 (http://www.opengeospatial.org/standards/ct): "Mercator_1SP"

AFAICS, OGC 01-009 is very light on details unfortunatelly (doesn't mention  
parameters of all projections), and things have more or less crystalized by 
the practice of the various vendors (including GDAL/libgeotiff/proj.4). But 
yes, it does mention "Mercator_1SP", and the geopackage spec mentions OGC 
01-009 as the standard to use for WKT.

> 
> I would ask if this is not a bug in the geopackage itself or whatever
> created that WKT string. 

Not geopackage itself, but the NGA's profile on it. But your point on not 
mixing the old OGC 01-009 with ISO 19162 new practice is good, and should 
likely be submitted back to NGA.

> I'm not opposed to mapping that "Mercator variant A" name to
> SRS_PT_MERCATOR_1SP on WKT import, but I think there's a limit to how
> far one should go to support non-standard WKT.

In an ideal world, everyone would follow standards, and there would not be 
many standards/formats to do the same thing ;-) As this world doesn't exist, 
GDAL is there to fill in the gaps. I'd say that it is OK to have some ad-hoc 
rules to accomodate for data found in the wild (but I'm not sure there has 
been data released with the NGA's profile yet ?)

> even spatialreference.org
> is still using "Mercator_1SP" for the OGC WKT.

spatialreference.org is not really maintained AFAIK, and is partly based on an 
old GDAL version. So I wouldn't consider it as an authoritative source.

Even

-- 
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

Re: [gdal-dev] Add Mercator_variant_A method?

[Pepijn Van Eeckhoudt]

> I am not sure I follow what this has to do with the projection name in WKT. 
> The newer WKT specification (ISO 19162) relies solely on the identifier to 
> determine which operation method to use to project coordinates, but the older 
> WKT tends to follow OGC 01-009 which lists explicit names to use for the 
> projections. So regardless of what the EPSG registry uses for a name, this is 
> the name that is supposed to be used for the OGC WKT as far as I am concerned:
> OGC 01-009 (http://www.opengeospatial.org/standards/ct 
> ): "Mercator_1SP"
> 
> Does someone know of another WKT spec that uses that "Mercator variant A" 
> name, or I am missing something?


When we were defining the GeoPackage spec I had hoped to be able to point 
people to one definitive list of projection names and parameters so we could 
say ‘use this, end of story’. I remember discussing this with the CRS WKT 
people at one of the OGC TCs. IIRC they told me there never was a specification 
that standardised the projection names. The best practice is to use names that 
are used in some registry, the EPSG one being the most commonly used one.

The coordinate transformation service spec isn’t actually relevant for 
GeoPackage and is certainly not some normative reference for WKT projection 
names. I was under the same impression until I again discussed this with the 
relevant OGC members and was told that it is not.
The spec that is relevant for GeoPackage is the simple features common 
architecture one (OGC 06-103r4), section 9. That spec lists a number of 
projection names in annex B, but that annex is informative and non-exhaustive.

So in short there’s, unfortunately, no such thing as ‘standardised’ WKT wrt the 
projection and parameter names.

> I'm not opposed to mapping that "Mercator variant A" name to 
> SRS_PT_MERCATOR_1SP on WKT import, but I think there's a limit to how far one 
> should go to support non-standard WKT. I am not sure what modern EPSG names 
> have to do with the explicitly named WKT projection strings that are defined 
> in the actual specification, even spatialreference.org 
>  is still using "Mercator_1SP" for the OGC WKT.

IIRC spatialreference.org isn’t being actively maintained anymore. If 
http://trac.osgeo.org/metacrs/browser/sr.org 
 is still the source repo, last 
relevant update is from 5 years ago.
Last time I reviewed the source code, the WKT it displays is produced by proj.4 
and the data for it is sourced from proj.4’s extract of the EPSG database so of 
course that’s going to roundtrip well. :)

Since all this data is being source from the EPSG database anyway it seems best 
to use that as authoritative source. The main name for EPSG:9804 

 is 'Mercator (variant A)' now. The 'Mercator (1SP)’ name is still present in 
the database as an alias. The name change dates back to 2010 stating:

> Code: EPSG::2010.058 
> Reporter: Jay Hollingsworth; Schlumberger 
> Request: Review Mercator and Oblique Mercator method names 
> Actions Taken: For methods 9804-05, 9812-13 and 9815, amended name and added 
> alias. For method 9815 also corrected forward formula for az=90deg case. 
> Added method 1044. For projections 12150, 15001, 15031, 19871-72, 19894-95 
> and 19956-58, in remarks updated method names. For CRS 3375, in remarks 
> inserted missing and removed spurious space.

Best regards,

Pepijn___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Add Mercator_variant_A method?

[Andre Vautour]

On 2015-04-13 10:42, Even Rouault wrote:

André,


I am not sure I follow what this has to do with the projection name in
WKT. The newer WKT specification (ISO 19162) relies solely on the
identifier to determine which operation method to use to project
coordinates,

Do you know if there's a publicly available version of ISO 19162 ? I could
only find this draft on OGC website:
https://portal.opengeospatial.org/files/?artifact_id=54797 ( accessible from
http://www.opengeospatial.org/standards/requests/112?utm_source=emailcampaign219&utm_medium=phpList&utm_content=HTMLemail&utm_campaign=The+OGC+requests+comment+on+the+candidate+standard+Geographic+Information+%E2%80%93+Well+Known+Text+for+coordinate+reference+systems
)


but the older WKT tends to follow OGC 01-009 which lists
explicit names to use for the projections. So regardless of what the
EPSG registry uses for a name, this is the name that is supposed to be
used for the OGC WKT as far as I am concerned:
OGC 01-009 (http://www.opengeospatial.org/standards/ct): "Mercator_1SP"

AFAICS, OGC 01-009 is very light on details unfortunatelly (doesn't mention
parameters of all projections), and things have more or less crystalized by
the practice of the various vendors (including GDAL/libgeotiff/proj.4). But
yes, it does mention "Mercator_1SP", and the geopackage spec mentions OGC
01-009 as the standard to use for WKT.
Don't get me wrong, I agree that the OGC WKT is very fragile around the 
projection. The other WKT components can be fully defined in the WKT and 
their name is really just metadata. My point is that if the WKT produced 
by GDAL can use that particular projection name, I expect you are just 
pushing the problem further down the line. That is, that WKT string will 
eventually get passed to something else that will not understand that name.



I would ask if this is not a bug in the geopackage itself or whatever
created that WKT string.

Not geopackage itself, but the NGA's profile on it. But your point on not
mixing the old OGC 01-009 with ISO 19162 new practice is good, and should
likely be submitted back to NGA.


I'm not opposed to mapping that "Mercator variant A" name to
SRS_PT_MERCATOR_1SP on WKT import, but I think there's a limit to how
far one should go to support non-standard WKT.

In an ideal world, everyone would follow standards, and there would not be
many standards/formats to do the same thing ;-) As this world doesn't exist,
GDAL is there to fill in the gaps. I'd say that it is OK to have some ad-hoc
rules to accomodate for data found in the wild (but I'm not sure there has
been data released with the NGA's profile yet ?)
I agree, but a key intention behind standards is to improve 
interoperability between different software components. Do you expect 
other software components to be able to ingest that WKT string with that 
projection name? That is, to be able to read it and use the correct 
operation method? How would a WKT implementer know to map that specific 
name to the Mercator operation method to use the correct formula? Are 
you saying you expect somebody implementing an OGC WKT reader to try to 
match the projection name to an operation method name in the 
EPSG-registry when trying to determine the operation method to create?



even spatialreference.org
is still using "Mercator_1SP" for the OGC WKT.

spatialreference.org is not really maintained AFAIK, and is partly based on an
old GDAL version. So I wouldn't consider it as an authoritative source.
That's fair, but epsg-registry.org more than likely doesn't offer the 
OGC WKT because of these limitations. A better way forward would 
obviously be to use the new ISO WKT, but until then this is 
unfortunately the mess we all have to deal with.


Even



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

Re: [gdal-dev] Add Mercator_variant_A method?

[Andre Vautour]

On 2015-04-13 11:01, Pepijn Van Eeckhoudt wrote:


I am not sure I follow what this has to do with the projection name 
in WKT. The newer WKT specification (ISO 19162) relies solely on the 
identifier to determine which operation method to use to project 
coordinates, but the older WKT tends to follow OGC 01-009 which lists 
explicit names to use for the projections. So regardless of what the 
EPSG registry uses for a name, this is the name that is supposed to 
be used for the OGC WKT as far as I am concerned:

OGC 01-009 (http://www.opengeospatial.org/standards/ct): "Mercator_1SP"

Does someone know of another WKT spec that uses that "Mercator 
variant A" name, or I am missing something?


When we were defining the GeoPackage spec I had hoped to be able to 
point people to one definitive list of projection names and parameters 
so we could say ‘use this, end of story’. I remember discussing this 
with the CRS WKT people at one of the OGC TCs. IIRC they told me there 
never was a specification that standardised the projection names. The 
best practice is to use names that are used in some registry, the EPSG 
one being the most commonly used one.


The coordinate transformation service spec isn’t actually relevant for 
GeoPackage and is certainly not some normative reference for WKT 
projection names. I was under the same impression until I again 
discussed this with the relevant OGC members and was told that it is not.
The spec that is relevant for GeoPackage is the simple features common 
architecture one (OGC 06-103r4), section 9. That spec lists a number 
of projection names in annex B, but that annex is informative and 
non-exhaustive.


So in short there’s, unfortunately, no such thing as ‘standardised’ 
WKT wrt the projection and parameter names.
Thanks Pepijn for these clarifications. I was aware of the simple 
feature specs as well, but did not find that annex when I was drafting 
my original reply.


It might be helpful for the OGC to put out a policy guideline like they 
did for the axis ordering http://www.ogcnetwork.net/axisorder. I've 
looked at several of the WKT specs over the years and would not have 
reached that conclusion.


I'm not opposed to mapping that "Mercator variant A" name to 
SRS_PT_MERCATOR_1SP on WKT import, but I think there's a limit to how 
far one should go to support non-standard WKT. I am not sure what 
modern EPSG names have to do with the explicitly named WKT projection 
strings that are defined in the actual specification, even 
spatialreference.org  is still using 
"Mercator_1SP" for the OGC WKT.


IIRC spatialreference.org  isn’t being 
actively maintained anymore. If 
http://trac.osgeo.org/metacrs/browser/sr.org is still the source repo, 
last relevant update is from 5 years ago.
Last time I reviewed the source code, the WKT it displays is produced 
by proj.4 and the data for it is sourced from proj.4’s extract of the 
EPSG database so of course that’s going to roundtrip well. :)


Since all this data is being source from the EPSG database anyway it 
seems best to use that as authoritative source. The main name for 
EPSG:9804 
 is 
'Mercator (variant A)' now. The 'Mercator (1SP)’ name is still present 
in the database as an alias. The name change dates back to 2010 stating:



Code:
EPSG::2010.058
Reporter:
Jay Hollingsworth; Schlumberger
Request:
Review Mercator and Oblique Mercator method names
Actions Taken:
For methods 9804-05, 9812-13 and 9815, amended name and added alias. 
For method 9815 also corrected forward formula for az=90deg case. 
Added method 1044. For projections 12150, 15001, 15031, 19871-72, 
19894-95 and 19956-58, in remarks updated method names. For CRS 3375, 
in remarks inserted missing and removed spurious space.


Thanks again, that answers the main question of my last reply. If that 
is the case, I'll make sure to fallback to a name-lookup of the EPSG 
registry operation method in our in-house implementation. We do use GDAL 
for the WKT parsing, but we then still have to create an operation 
method in our model from the projection's name.



Best regards,

Pepijn


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

[gdal-dev] define netcdf time dimension

[Dominik Schneider]

Hi -

I have some .mdl files from IDL with .hdr header files that I’d like to
convert to netcdf.
The following code produces a netcdf file with a subdataset for each band
in the mdl file. Is there any way to define the bands as the time
dimension, in this case 4416 hourly timesteps?

Or is there another tool that can convert this?

gdal_translate -of NetCDF swe.mdl swe.nc

Thanks
Dominik​
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] define netcdf time dimension

[Michael Sumner]

On Tue, 14 Apr 2015 at 05:46 Dominik Schneider <
dominik.schnei...@colorado.edu> wrote:

> Hi -
>
> I have some .mdl files from IDL with .hdr header files that I’d like to
> convert to netcdf.
> The following code produces a netcdf file with a subdataset for each band
> in the mdl file. Is there any way to define the bands as the time
> dimension, in this case 4416 hourly timesteps?
>
> Or is there another tool that can convert this?
>
> gdal_translate -of NetCDF swe.mdl swe.nc
>
>
Can you list the metadata printed out by gdalinfo swe.mdl?  What driver is
used?

Does that source file have time-metadata inside it each subdataset or do
you need to assign it?

Generally, the subdatasets are not considered as a time series - they are
more like multiple variables for the same observation (whereas a 3rd and
higher dimension/s are often unrolled into a multi-attributed 2D layer and
the time/z step is stored on each band -  it's a bit of a mix/clash of
worlds).

Can you point to and example file somewhere?  I imagine you'll need a
programmed solution, but it should be pretty easy with R or python or
similar.  If R is of interest you can try this and take your question to
the R community:

library(raster)
r <- stack("swe.mdl")
r <- setZ(r, [whatever the vector of dates should be])  ## pseudocode
writeRaster(r, "swe.nc")

That all assumes quite a lot, including available NetCDF versions and
packages, required structure in the output, interpretation of the data read
in,  - so it's just included as an indication how it might be done.

Cheers, Mike.


> Thanks
> Dominik​
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev