[Geotools-devel] Reminder: GeoTools / GeoServer Meeting at 19:30 UTC on Tuesday

[Ben Caradoc-Davies]

GeoTools / GeoServer committee meeting on Skype at 19:30 UTC on Tuesday:
http://www.timeanddate.com/worldclock/fixedtime.html?msg=GeoTools+%2F+GeoServer+Meeting=2015=10=6=19=30=0=1

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] new repository please test

[Jody Garnett]

Going to try and switch ares over to this mirror, if that goes well we will
update the DNS registry this afternoon.

--
Jody Garnett

On 29 September 2015 at 16:36, Jody Garnett  wrote:

> Sorry, URL corrected below:
>
>   
> 
>   boundlessgeo
>   Boundless Cloud Repository
>   https://boundless.artifactoryonline.com/boundless/main
>   boundless
> 
>   
>
>
> --
> Jody Garnett
>
> On 29 September 2015 at 16:20, Jody Garnett 
> wrote:
>
>> We are setting up a replacement repository (cloud hosting for PMC access).
>>
>> Can I ask geotools developers to try out the repo using the following
>> settings (before we change the DNS entry over):
>>
>> 1. Edit .m2/settings.xml with the following
>>
>>   
>> 
>>   boundlessgeo
>>   Boundless Cloud Repository
>>   
>> https://boundless.artifactoryonline.com/boundless/ext-release-local
>>   boundless
>> 
>>   
>>
>> 2. Rename your .m2/repository cache to repository2 (to force download)
>>
>> 3. Build! And reply to this email thread with pass fail.
>>
>> We have synchronized with repo.boundlessgeo.com so I do not expect
>> trouble.
>> --
>> Jody
>>
>
>
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Build failed in Jenkins: geotools-master #865

[monitor]

See 

--
[...truncated 19523 lines...]
[INFO] ArcSDE plugin
[INFO] ArcSDE dummy api
[INFO] ArcSDE support classes
[INFO] ArcSDE DataStore plugin
[INFO] Dynamic symbolizer module based on JFreeChart and Eastwood
[INFO] Extensions to EPSG authority factory
[INFO] EPSG Authority Service using PostgreSQL database
[INFO] Feature-Pregeneralized
[INFO] grass raster datasource module
[INFO] GTopo30 datasource module
[INFO] WorldImage datasource module
[INFO] JDBC DataStore Plugins
[INFO] H2 DataStore
[INFO] Oracle DataStore
[INFO] PostGIS DataStore
[INFO] Feature transforming feature source wrapper
[INFO] imagemosaic datasource module
[INFO] ImageI/O-Ext based grid coverage readers
[INFO] imagepyramid datasource module
[INFO] imagemosaic-jdbc module
[INFO] DB2 DataStore
[INFO] MySQL DataStore
[INFO] SQL Server DataStore
[INFO] SpatiaLite DataStore
[INFO] Teradata DataStore
[INFO] JP2K based grid coverage readers
[INFO] OGR DataStore Module
[INFO] Core OGR DataStore Module
[INFO] Bridj OGR DataStore Module
[INFO] JNI OGR DataStore Module
[INFO] Vertical coordinate transformations
[INFO] Dynamic symbolizers for SVG symbols
[INFO] Coverage Multidimensional Module
[INFO] API interfaces
[INFO] NetCDF gridcoverage module
[INFO] GRIB gridcoverage module
[INFO] Application Schema Support
[INFO] Application Schema Resolver
[INFO] Complex Features Support
[INFO] Application Schema DataAccess
[INFO] Sample DataAccess
[INFO] Brewer module
[INFO] Vector grids
[INFO] Validation Processor and Framework
[INFO] Web Map Server client
[INFO] KML XML Support
[INFO] WCS XML Support
[INFO] WPS XML Support
[INFO] WMS XML Support
[INFO] CSW XML Support
[INFO] Geotools unsupported
[INFO] Process
[INFO] Swing widgets
[INFO] SWT widgets
[INFO] WFS client module
[INFO] GeoJSON Support
[INFO] GeoPackage Module
[INFO] MBTiles Module
[INFO] WFS client module (NG)
[INFO] Coverage tools
[INFO] ISO 19107 implementation using JTS
[INFO] Geometries
[INFO] Web Processing Service
[INFO] Process Geometry
[INFO] Process Raster
[INFO] Process Feature
[INFO] Application Schema Support (Unsupported Modules)
[INFO] SOLR module
[INFO] Geobuf DataStore
[INFO] Cartographic CSS parser
[INFO] CSVDataStore
[INFO] EPSG Authority Factory for Oracle
[INFO] Next Generation JDBC DataStores
[INFO] VPF Plugin
[INFO] SAS Matlab grid coverage readers
[INFO] Simple Feature Service store
[INFO] Aggregating DataStore
[INFO] MongoDB DataStore
[INFO] GeoTools Documentation
[INFO] 
[INFO] 
[INFO] Building Geotools 15-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- git-commit-id-plugin:2.1.2:revision (default) @ geotools ---
[INFO] 
[INFO] >>> maven-source-plugin:2.2.1:jar (attach-sources) @ geotools >>>
[INFO] 
[INFO] --- git-commit-id-plugin:2.1.2:revision (default) @ geotools ---
[INFO] 
[INFO] <<< maven-source-plugin:2.2.1:jar (attach-sources) @ geotools <<<
[INFO] 
[INFO] --- maven-source-plugin:2.2.1:jar (attach-sources) @ geotools ---
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ geotools ---
[INFO] Installing 
 to 
/var/lib/jenkins/.m2/repository/org/geotools/geotools/15-SNAPSHOT/geotools-15-SNAPSHOT.pom
[INFO] 
[INFO] --- maven-resources-plugin:2.6:copy-resources (copy-resources) @ 
geotools ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] 
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ geotools ---
Downloading: 
http://repo.boundlessgeo.com/main/org/geotools/geotools/15-SNAPSHOT/maven-metadata.xml

[WARNING] Could not transfer metadata 
org.geotools:geotools:15-SNAPSHOT/maven-metadata.xml from/to boundless 
(http://repo.boundlessgeo.com/main): Read timed out
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Geotools .. FAILURE [30:47.213s]
[INFO] Build tools for Geotools 2  SKIPPED
[INFO] Maven plugins for Geotools 2 .. SKIPPED
[INFO] JAR files collector ... SKIPPED
[INFO] Cross-modules javadoc . SKIPPED
[INFO] JJTree and JavaCC compilers plugin  SKIPPED
[INFO] Geotools modules .. SKIPPED
[INFO] Geotools libraries  SKIPPED
[INFO] Sample data module  SKIPPED
[INFO] Open GIS Interfaces ... SKIPPED
[INFO] Metadata .. SKIPPED
[INFO] Referencing services .. SKIPPED
[INFO] API interfaces 

[Geotools-devel] FeatureJSON with complex properties

[Pedro Trujillo Brito]

Hi, I'm trying to read some geoJson features which includes properties with
nested json.

For example:

{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [
100.1,
0.1
]
},
"properties": {
"id": 123,
"otherProp": {
"id": 1
"name": "Name"
}
}
}

But, when parsed with FeatureJSON.readFeature, it simply discard the nested
properties (it appears with a null value).

There is any way to get this working?

Thanks!
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] FeatureJSON with complex properties

[Jody Garnett]

You would need to revisit the code to create a "complex feature", so the
data structure exists but it is not supported by the parser as it stands
now.  Specifically in this case you want to create a ComplexAttribute
"otherProp" to hold the attributes "id" and "name".

I do not know if you always expect "otherProp" to have the same content? If
it is an unstructured Map you may want to record it as a Map
?

--
Jody Garnett

On 5 October 2015 at 00:18, Pedro Trujillo Brito  wrote:

> Hi, I'm trying to read some geoJson features which includes properties
> with nested json.
>
> For example:
>
> {
> "type": "Feature",
> "geometry": {
> "type": "Point",
> "coordinates": [
> 100.1,
> 0.1
> ]
> },
> "properties": {
> "id": 123,
> "otherProp": {
> "id": 1
> "name": "Name"
> }
> }
> }
>
> But, when parsed with FeatureJSON.readFeature, it simply discard the
> nested properties (it appears with a null value).
>
> There is any way to get this working?
>
> Thanks!
>
>
> --
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] FeatureJSON with complex properties

[Pedro Trujillo Brito]

I'm trying to use Feature instead of SimpleFeature, but FeatureJSON.readFeature
only returns a SimpleFeatureImpl (as Jody said).

The complex properties may have different inner properties, so it would be
useful getting them as a Map.

How can I parse the geoJson in a (not simple) Feature?

Thanks!!

2015-10-05 8:25 GMT+01:00 Jody Garnett :

> You would need to revisit the code to create a "complex feature", so the
> data structure exists but it is not supported by the parser as it stands
> now.  Specifically in this case you want to create a ComplexAttribute
> "otherProp" to hold the attributes "id" and "name".
>
> I do not know if you always expect "otherProp" to have the same content?
> If it is an unstructured Map you may want to record it as a
> Map ?
>
> --
> Jody Garnett
>
> On 5 October 2015 at 00:18, Pedro Trujillo Brito 
> wrote:
>
>> Hi, I'm trying to read some geoJson features which includes properties
>> with nested json.
>>
>> For example:
>>
>> {
>> "type": "Feature",
>> "geometry": {
>> "type": "Point",
>> "coordinates": [
>> 100.1,
>> 0.1
>> ]
>> },
>> "properties": {
>> "id": 123,
>> "otherProp": {
>> "id": 1
>> "name": "Name"
>> }
>> }
>> }
>>
>> But, when parsed with FeatureJSON.readFeature, it simply discard the
>> nested properties (it appears with a null value).
>>
>> There is any way to get this working?
>>
>> Thanks!
>>
>>
>> --
>>
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] FeatureJSON with complex properties

[Jody Garnett]

You need to make a copy of the parser and write the code. please contribute
back as it sounds like a useful change :)
On Mon, Oct 5, 2015 at 12:53 AM Pedro Trujillo Brito 
wrote:

> I'm trying to use Feature instead of SimpleFeature, but 
> FeatureJSON.readFeature
> only returns a SimpleFeatureImpl (as Jody said).
>
> The complex properties may have different inner properties, so it would be
> useful getting them as a Map.
>
> How can I parse the geoJson in a (not simple) Feature?
>
> Thanks!!
>
> 2015-10-05 8:25 GMT+01:00 Jody Garnett :
>
>> You would need to revisit the code to create a "complex feature", so the
>> data structure exists but it is not supported by the parser as it stands
>> now.  Specifically in this case you want to create a ComplexAttribute
>> "otherProp" to hold the attributes "id" and "name".
>>
>> I do not know if you always expect "otherProp" to have the same content?
>> If it is an unstructured Map you may want to record it as a
>> Map ?
>>
>> --
>> Jody Garnett
>>
>> On 5 October 2015 at 00:18, Pedro Trujillo Brito 
>> wrote:
>>
>>> Hi, I'm trying to read some geoJson features which includes properties
>>> with nested json.
>>>
>>> For example:
>>>
>>> {
>>> "type": "Feature",
>>> "geometry": {
>>> "type": "Point",
>>> "coordinates": [
>>> 100.1,
>>> 0.1
>>> ]
>>> },
>>> "properties": {
>>> "id": 123,
>>> "otherProp": {
>>> "id": 1
>>> "name": "Name"
>>> }
>>> }
>>> }
>>>
>>> But, when parsed with FeatureJSON.readFeature, it simply discard the
>>> nested properties (it appears with a null value).
>>>
>>> There is any way to get this working?
>>>
>>> Thanks!
>>>
>>>
>>> --
>>>
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>>
>>
>
> --
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
-- 
--
Jody Garnett
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] FeatureJSON with complex properties

[Pedro Trujillo Brito]

Ok. It's not my priority right now, but if I work on that I'll submit the
complex parser.

Thank you so much!

2015-10-05 8:55 GMT+01:00 Jody Garnett :

> You need to make a copy of the parser and write the code. please
> contribute back as it sounds like a useful change :)
>
> On Mon, Oct 5, 2015 at 12:53 AM Pedro Trujillo Brito 
> wrote:
>
>> I'm trying to use Feature instead of SimpleFeature, but 
>> FeatureJSON.readFeature
>> only returns a SimpleFeatureImpl (as Jody said).
>>
>> The complex properties may have different inner properties, so it would
>> be useful getting them as a Map.
>>
>> How can I parse the geoJson in a (not simple) Feature?
>>
>> Thanks!!
>>
>> 2015-10-05 8:25 GMT+01:00 Jody Garnett :
>>
>>> You would need to revisit the code to create a "complex feature", so the
>>> data structure exists but it is not supported by the parser as it stands
>>> now.  Specifically in this case you want to create a ComplexAttribute
>>> "otherProp" to hold the attributes "id" and "name".
>>>
>>> I do not know if you always expect "otherProp" to have the same content?
>>> If it is an unstructured Map you may want to record it as a
>>> Map ?
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 5 October 2015 at 00:18, Pedro Trujillo Brito 
>>> wrote:
>>>
 Hi, I'm trying to read some geoJson features which includes properties
 with nested json.

 For example:

 {
 "type": "Feature",
 "geometry": {
 "type": "Point",
 "coordinates": [
 100.1,
 0.1
 ]
 },
 "properties": {
 "id": 123,
 "otherProp": {
 "id": 1
 "name": "Name"
 }
 }
 }

 But, when parsed with FeatureJSON.readFeature, it simply discard the
 nested properties (it appears with a null value).

 There is any way to get this working?

 Thanks!


 --

 ___
 GeoTools-Devel mailing list
 GeoTools-Devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geotools-devel


>>>
>>
>> --
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
> --
> --
> Jody Garnett
>
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Jenkins build is back to normal : geotools-master #866

[monitor]

See 


--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Handling non-working projections / CRS

[Jody Garnett]

Got an idea (feel free to shoot down). Right now I have a program that
generates the function list  for the
geotools docs, I keep meaning to add that into the maven build (so the docs
are always up to date).

Could we do the same thing for a generated epsg-blacklist.properties? Idea
would be to have each line be an sys code to "skip" and the value would be
the reason why.

EPSG:22300=No transform for classification "Tunisia Mining Grid"

We could use the blacklist to "filter" the contents of the gt-epsh-hsql.jar
to only those that are supportable by our reference implementation.


--
Jody Garnett

On 1 October 2015 at 05:10, Andrea Aime 
wrote:

> On Thu, Oct 1, 2015 at 1:26 PM, Brad Hards  wrote:
>
>> > Not at runtime, but there is an  issue, the data dir used in tests
>> > is destroyed and rebuilt at every test run (for each class, not method).
>> I'm less concerned that tests are slow, but more concerned that
>> GetCapabilities becomes slow in production.
>>
>
> Making tests slower is definitely not an option, they are already too slow,
> we actually have spent code sprints (Vienna, 3 days) and several personal
> hours
> to make them faster in face of the growing system and growing number
> of modules. On my machine GS il building in 12-13 minutes, without all
> that effort we'd be around 20-30 minutes by now.
>
> Presumably those custom plugins work though, so the blacklist (or
>> whitelist by
>> exception) would only apply to those that we "know" about. Are the custom
>> ones
>> in the EPSG namespace?
>>
>
> Sometimes they are, other times not, it's all over the place.
>
>
>>
>> > > Another variation would be to have a whitelist of codes that are
>> expected
>> > > to
>> > > work. That whitelist could be represented in GeoTools by a new
>> function
>> > > (like CRS.getDecodeableCodes(String authority) or similar). That
>> would be
>> > > a maintenance burden, and we'd lose support for things that might
>> work.
>> > >
>> > > Any suggestions?
>> >
>> > Err... I'm not sure I have a good solution... time ago there was this
>> > suggestion
>> > to have the WMS caps only report the list of CRS that are actually in
>> use,
>> > plus some well known ones (e.g., 3857).
>> > This could be a flag in the WMS configuration, enabled by default in the
>> > release
>> > data directory.
>> So the "Limited SRS list" would be the default. We could do a subset with
>> no
>> code changes, just by modifying the data dirs.
>>
>> It would need to cycle through all the layers to find out the CRS that
>> are in
>> use though.
>>
>
> Indeed, it would require two cycles, one to generate the list of CRS, one
> to
> actually produce the caps document.
> Unless the list is gathered once and then cached and maintained up to date
> using catalog listeners.
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result 

[Geotools-devel] Slow inserts in DB

[Patrick Valsecchi]

Hi,

I'm using geogig to import/export data from/to Oracle. As I was a bit
surprised by the slowness of the export operation, I've looked a bit at how
it's done.

Geogig asks geotools to insert one feature at a time. As I was planning to
fix that and gouping the insertions a bit, I've looked at how Geotools is
implemented. Basically, in JDBCDataStore#insert, Geotools will loop over
the features to insert and, for *every* feature, will do that:

   - Create a PreparedStatement with bound variables
   - execute it
   - close the PreparedStatement

That is very inefficient and makes my idea to have Geogig group the
insertions useless. When doing a lot of inserts in JDBC, one should use
addBatch and executeBatch.

Is there any reason for not using batch inserts in JDBCDataStore#insert?
What do you think of changing this area in order to use batch inserts (same
for deletes and updates, too, I guess)?

Thanks for you opinion.
--
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] [JIRA] (GEOT-5240) Transforming feature source does not honor naming convention on FID

[Stefano Costa (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Stefano Costa created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5240 
 
 
 
  Transforming feature source does not honor naming convention on FID  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 14.0 
 
 
 

Assignee:
 
 Stefano Costa 
 
 
 

Components:
 

 data 
 
 
 

Created:
 

 05/Oct/15 3:40 PM 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Stefano Costa 
 
 
 
 
 
 
 
 
 
 
TransformFeatureSource (gt-transform module) should use the transformed type name to generate feature identifiers following the convention . (at least when the original source follows it). 
Currently, it's wrongly using the original type name instead of the transformed one. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
  

[Geotools-devel] [JIRA] (GEOT-5241) support time dimensions with different names across datasets

[Daniele Romagnoli (JIRA)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Daniele Romagnoli created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 GeoTools /  GEOT-5241 
 
 
 
  support time dimensions with different names across datasets  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Improvement 
 
 
 

Affects Versions:
 

 14.0, 15-beta 
 
 
 

Assignee:
 
 Daniele Romagnoli 
 
 
 

Components:
 

 coverage-multidim 
 
 
 

Created:
 

 05/Oct/15 5:14 PM 
 
 
 

Fix Versions:
 

 14.1, 15-beta 
 
 
 

Priority:
 
  Medium 
 
 
 

Reporter:
 
 Daniele Romagnoli 
 
 
 
 
 
 
 
 
 
 
When opening different grib files using UCAR NetCDF Java libs you may get the same variable using different time dimensions across different files. 
As an instance: file1.grib2 dump = air_temperature(time1, lon, lat)  air_temperature_hourly_maximum(time2, lon, lat)  
file2.grib2 dump = air_temperature(time2, lon, lat)  air_temperature_hourly_maximum(time1, lon, lat)  
(see the swapped time1, time2 dimension names). The name depends on the position of a specific GRIB record within the dataset itself. Since GRIB records are "sparse" records within a binary