Coordinate Reference System Challenges In GeoScience Modelling
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Title of Series | ||
Number of Parts | 95 | |
Author | ||
License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
Identifiers | 10.5446/15520 (DOI) | |
Publisher | ||
Release Date | ||
Language | ||
Production Place | Nottingham |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
FOSS4G Nottingham 201320 / 95
17
25
29
31
32
34
48
50
56
58
68
69
70
82
89
91
00:00
Model theoryCoordinate systemSystem programmingCharacteristic polynomialNumerical analysisProblemorientierte ProgrammierspracheAlgorithmPressureLevel (video gaming)SummierbarkeitInterpolationResampling (statistics)AreaDistanceWeight functionBilinear mapComputer reservations systemPole (complex analysis)SpheroidShift operatorCellular automatonData type5 (number)Water vaporVector potentialSoftware development kitParametrische ErregungTransformation (genetics)Local GroupArchaeological field surveyMusical ensembleOpen setGeometryExtension (kinesiology)Instance (computer science)Model theorySystem programmingCASE <Informatik>Multiplication signCovering spaceForm (programming)SpacetimeProblemorientierte ProgrammierspracheSet (mathematics)MathematicsMereologyMechanism designWordPhysicalismPulse (signal processing)PhysicistResultantBitGroup actionElectronic mailing listCode3 (number)Presentation of a groupAlphabet (computer science)Disk read-and-write headTerm (mathematics)Uniform boundedness principleDiagramSubject indexingDifferent (Kate Ryan album)Vector potentialNumerical analysisGame controllerMusical ensembleCountingProgrammer (hardware)Uniform resource locatorMoore's lawPolygon meshAreaData managementTransformation (genetics)FreewarePoint (geometry)RoutingAlgorithmMotion captureProjective planeRow (database)Image resolutionPosition operatorPairwise comparisonObservational studyMoment (mathematics)Standard deviationLibrary (computing)Utility softwarePerspective (visual)Functional (mathematics)Latent heatInformationOptical disc driveGroup representationState of matterWeb pageCellular automatonGame theoryMoistureData storage deviceLimit (category theory)ConsistencyMobile WebRight angleKey (cryptography)Bit rateSampling (statistics)INTEGRALNumbering schemeRoundness (object)Configuration spaceComputer virusSuite (music)InterpolationVertex (graph theory)Type theoryComputer configurationOrder (biology)Sound effectNetwork topologyInformation securityProcess (computing)Revision controlDependent and independent variablesCircleEuler anglesQuicksortConnected spaceDampingWindowDirection (geometry)Frame problemComputational scienceStructural loadMassBoiling pointPower (physics)Line (geometry)Pole (complex analysis)Shape (magazine)Coordinate systemOrder of magnitudeComputer simulationSoftware bugStudent's t-testDivisorRotationInversion (music)Resampling (statistics)1 (number)Characteristic polynomialPlotterLevel (video gaming)SoftwareCubeSphereParameter (computer programming)Traffic reportingCodeSupercomputerSurfaceTexture mappingComputer hardwareDegree (graph theory)Phase transitionRaster graphicsRegular graphOperator (mathematics)Logical constantImage warpingoutputGrass (card game)Extension (kinesiology)Square numberDirected graphTranslation (relic)Shared memoryComputer clusterJSONXML
Transcript: English(auto-generated)
00:33
I'll just talk a little bit about the future and I have some questions that I'd be interested in thoughts on.
00:40
So first of all, modellers and model domains. Numerical modellers are very interested in their algorithms and their solvers and they relate their models to the real world but the relation is somewhat interesting. So there's an old tale that I was told when I was a physics student about a physicist who was asked to help a set of farmers
01:01
in their dairy farms and his first response was that they were going to consider a spherical cow and the spherical cow would have a constant input of grass and that was the world and then they could start modelling. So that's the kind of attitude that we work with. So this is an example of a limited area numerical model that we've plotted. This
01:23
is plotting over a standard plaque carry projection and you can see that the model domain is a slightly interesting shape. I've plotted each one of the cells individually on this model and it's quite a coarse model. I'll come back to exactly some more details on this projection in just a moment.
01:41
This is taking the world the other way around. So in this example we're looking at the world on a plaque carry projection and then drawing the model data as best we can over the top of it. This is looking at the model domain and then plotting the coastlines relative to the model space. So these two are exactly the same data, just
02:03
flipping the point of reference around. So while plotting is very important to the people who we work with, another thing that's very important to them is resampling. So some of this is to do with interpolation and people are very interested in the interpolation schemes and what's being used and this can
02:22
have quite an effect on the kinds of modelling that they want to do. And then there are a number of different types of resampling which need to be addressed for some of the more esoteric problems. So the picture I've showed you on here is a global model and if we just zoom in over the UK there is a limited area model nested on top of this. So these
02:41
domains are defined quite differently and for this particular use case what we're looking at is the global model temperature and the limited area model temperature. The global model is a baseline and people want to do an anomaly plot of the difference between the temperature in a particular run and some anomaly set across the globe. So we
03:01
have to do a quite careful resampling of one data set onto the other before we can do the simple numbers one minus the other to do the anomalies. So that's a little bit about the kind of challenges we're facing. I'd like to talk now about the coordinate reference systems themselves. So the first one that we're looking at here is what's called a rotated pole. So they've taken a normal geographic coordinate
03:24
system and then they have moved the North Pole and the reason they've done this is that on a plate carry projection then there are a very large number of squares near the North Pole and near the South Pole which means that they have a very very small area and that upsets the numerical solvers. You get sinks at the place where the cell
03:44
area tends to zero and it really causes them problems. So they have to deal with it in their global models but for the local models they move that to somewhere they don't care about and just look at the part where the grid is nice and square. So here we're looking at the UK and the North Atlantic. So everything is square around us and what
04:03
happens in Central Asia doesn't matter because the solver isn't going to go there. So I picked up a little diagram just to try and show you what we've done. We've taken a geographic coordinate system as Frank was just talking about and then we've added two new parameters to it. One is the location of the North Pole. We've
04:21
one happens to be moved by 90 degrees but different models are moving by different amounts and then some people also do a further rotation of the globe so they can shift the meridian or to give them a nice model space where they want it. So what I've just been looking at are what I would term parameterised
04:42
coordinate systems. We've got a simple set of numbers, we can do a small transformation and everything can be handled by the maths. The other kind of problem that we have is what I've termed a translated coordinate reference system. I don't know if that's a widely used name but in this case these people have
05:01
decided that the most important areas for them are over the Arctic Ocean and the various other oceans around the globe because they happen to be ocean modellers. So to do this they've created two North Poles rather than just one. One over Canada and one over I suppose Central Russia. It's probably a
05:22
little bit south of that but this presents us with quite an interesting domain to work with and as you can see there are areas where the domain simply isn't defined at all and there are areas where there's significant warping taking place. So in this case what we have is that each cell in the
05:41
model domain is defined in terms of its centre and its corners. We also have the area of a cell parameterised. They give us some information about the connectivity, which cells connect to what and perhaps in what direction but this doesn't give us a full picture. So one of my questions and one of the things that we've been puzzling oversight is is this really a
06:02
coordinate reference system? Is it helpful for us to try and treat it as that? Because the kind of work that we want to do with these is very similar to what we do with a rotated pole, is very similar to what we do with a geographic coordinate system or a projected coordinate system. So we can see how the requirements fit together but do we have enough information? Is this a worthwhile approach? I've showed you the ocean model grid which is
06:32
their tripolar grid. There are a whole suite of those for different resolutions for different purposes and that's being used by a lot of climate research and weather forecasting ocean modeling communities now. But the
06:45
thought process about how you're going to build a numerical domain is going on in a lot of other areas and I've got two more examples here of ways of defining a domain which are gaining credence particularly amongst the people who are developing numerical algorithms. One of the reasons
07:00
for this is that as computing power and storage potential increases then the modelers want more. The limiting factor for most of them is time. They have a certain amount of time on a piece of hardware to run a model and the model has to solve. If you want to give a six hour forecast and you're starting at midnight and you want to give a forecast for noon it doesn't
07:22
really help if your forecast returns back at six o'clock in the evening because nobody cares anymore. So windows of time are very important. So every time you give them a new supercomputer with an order of magnitude more processing power they increase the resolution of their grid in time and space by that proportion so it fits into the same model time. As
07:41
they've done that the Platt-Carré projection or sorry the Platt-Carré coordinate reference system has more and more problems particularly around the poles. So they're all wanting to move away from it and I've got a couple of examples here that are being talked about. I quite like the Yin-Yang grid. That's quite pretty. The cube sphere domain stretched
08:04
across onto the globe is heavily researched at the moment and there are some models being run in the Met Office in some experimental configurations using that particular one. The reason I show these is from my perspective these share a lot of characteristics with the ocean
08:20
model grid. The model is just tell us a cell and they give us some information about that cell and that's all you get back from the model. It says here I've got a data value and then they want to plot that on the map. They want to resample that. There's a number of other operations they want to do. As these become more popular they're coming to the tool builders and saying we want you to help us support
08:41
this. So I showed you earlier a nice plot of the rotated pole data in its own domain with the coastlines warped around to give you a nice coastline plot. This is a plot of the ocean model seawater potential temperature. I think it's near the surface. You can see kind of where the world is but because we don't currently treat this
09:04
as a true coordinate reference system we can't use the same tool to plot the coastlines. There are some interesting features particularly around Africa. If you know your African geography then that's not a good representation. I've talked quite a bit
09:24
about transforming coordinate reference systems. That's one of the key requirements that as tool builders we're being presented with. We use Proj4 extensively. We find it a very nice toolkit. We've written a Python library which hooks into Proj4 and connects that to the Python map plot lib plotting library which is what we were making the graphics with and that
09:43
provides a really useful set of tools for handling our rotated pole grids and a number of other requirements that we have. There's an ob-trans function in Proj4 which does everything we need for the rotated poles. But when it comes to what I've called these translated coordinate reference
10:01
systems we're not aware of how to do this. We haven't approached this problem and from one perspective I think that there is an interesting idea that says we should be approaching it in this way and this is the kind of functionality that we want. But I'm not convinced and I haven't seen all of the answers yet. So that's one of the reasons I've come here is to get some more opinions.
10:22
Is this a good idea or is this the whole world of pain that I will come back in a year's time saying I wish we'd never gone down that road. I really really wish. The other requirement that we have as well as the functional processing is about specification. So people are creating data. There's two different perspectives here which I'll
10:43
just touch on very quickly. From the weather forecasters perspective they make a forecast. They'll release it at four o'clock tomorrow morning and it will have a forecast for 12 o'clock and six in the evening 12 o'clock maybe up to five days maybe up to seven days. When they do the same thing 12 hours later the last one doesn't really matter. All that anybody wants is the
11:02
latest information. The climate research are in a very different position because they're looking at doing runs out to one hundred hundred and fifty years managing many many different scenarios. They're very interested in the data archiving problem and they've got requirements to go back to data was created
11:21
10 15 years ago and be able to use that now and compare it to things that they're doing. And there's a huge project called the climate model intercomparison study which has hundreds of terabytes of data from the last 10 years of climate research which is being used for the International Panel on Climate Change report which is just being published at the moment and will be
11:42
all over your newspapers with various opinions around it. So we need to be able to specify these and specifies these to high quality and particularly for the climate researchers we need standards and we need some way that we can trust we'll still be there in 10 years time. The EPSG
12:01
which Frank was talking about earlier we found quite difficult because as the model has come up with new ideas it's been quite hard to work out how you get new coordinate systems in particularly when there's a fast pace and when it comes to the rotated poles and it's a parametric definition. The rotated pole is easy to define but each model wants to be able to give you new parameters and the idea of EPSG codes giving
12:23
you an exact answer doesn't really fit that model for us. We've been looking at well known text and particularly I unpacked the alphabet soup underneath but I had to make it quite small I'm sorry about that but there is a special working group in the OGC looking at revamping the
12:40
coordinate reference system well known text and I'm interested about whether that provides the long term mechanism and whether that's really going to hit what we need. I've started making having discussions with some of those people about giving them the rotated pole use case to say could you please support this because at the moment we can't put that in well known text. One other thing I wanted to mention
13:04
there's a very widely used standard within the climate research community called the Climate and Forecasting Conventions for NetCDF which is shortened to CF, NetCDF. This has been quite domain specific it's been very focused on climate research because of the kind of requirements I've been talking about they've
13:22
come up with their own method for specifying coordinate reference systems and there's been some work recently looking at how they can try and either use another methodology or map that methodology onto another one but this is very heavily in use in our community and it's not clear how that gets out into the geographic communities or how it might be able to be used with GIS software or other such things.
13:47
So I've got some questions so I'd like to take a little bit of time if we've got a little bit left to open up the floor to discussion. I'm going to put my questions up in front of you. I'm very happy to take any other questions you have on what I've talked about but this is one
14:00
of the reasons that I came here I'd like to find out more information about this. So the first question I have is about how do we standardise definition of coordinate reference systems? What's our best approach for this? My second one is, is it useful to treat these translated coordinate reference systems as coordinate reference systems? Should we be trying to push these kinds of definitions into tools
14:23
that we already use, particularly Proj4 which has been very effective in delivering to a lot of our use cases? And as I said, any other questions that you have I'm really happy to try and discuss. Thank you.
14:47
Maybe first some questions from the audience. Question which is also maybe on your second question. If I read it like that, is it just
15:02
to consider translated coordinate systems as true coordinate system? It's a non-secretary. No, of course not, because it's a coordinate system that you translate and translation is already well defined. But I think you mean, I think your term translated coordinate system is a bit confusing. Yeah, I think it's confusing.
15:22
I've tried four or five different terms. I'm yet to find a good one that seems to... You see what the confusion is in this one. If you read it out like this, anybody having to do it with coordinate system would say, no, no, of course not, because it's a coordinate reference system that's been defined and then you translate it. So, and that's...
15:42
What translation? Translation is a perfect legitimate form of another coordinate system. I think it's the same as you could have a transverse coordinate with a false DC ignoring a zero. You can have another one with a different false. Those are both coordinate systems and one's a translation of the other. Clear, but that supposes that then it is not what he means because then it's nothing new or different. Well, I'm not sure. I don't have a good
16:05
answer for that. If I could add a comment, I would like to say that in the raster world, I'm used to having one set of modeling which is how we get from our raster space to some GISC coordinate system space and then we get
16:21
from that coordinate system space to some other coordinate system space. So, I would normally treat these as situations where maybe I have a geolocation array for my raster that passes into the normal coordinate system and then the next stage or RPCs or various different model mechanisms. But I'm used to trying to treat the phase where you go from an irregular raster into a regular
16:42
GISC coordinate system is one distinct operation which I don't try and represent in the same well-known texture. It's actually a completely different thing in my world model because actually they could all be put together but to me, it's easier for me to understand what's going on when I treat that step as distinct from the sort of reprojection step or something like that.
17:01
Yeah. Okay. Interesting. Because I think one of the challenges that we have is that when we get data out of the models using particularly these ocean models, then the data set will give us, if you've got, if you just consider a surface field, you'll have a 2D array of data, you'll have a 2D array of latitudes and a 2D array of
17:21
longitudes and a 2D array of areas and then a two by four array of corners. So for any data value, I can give you a cell in that I can tell you the center, for whatever you mean by center, the four corners which may give you a slightly odd shape and then some parameters about that cell. So I can put that on a map and I can, I can
17:41
do a drawing and I can draw some nice shapes. But if I want to go the other way around and say well okay can you take something that exists in space like a coastline and tell me how that looks in index space, we can't do that. We don't have a methodology for doing that at the moment and that's something that we can do very neatly for the rotated poles because we've got a mathematical transform that gives
18:01
you a rotated pole data set. I'll just draw the coastlines behind it and that works beautifully. So we've shown our ocean model as that bit of functionality and they want oh can we have that and we can went back a couple of months later and said um no not now.
19:07
Okay so you've used GDAL warper for that that's not something that you tried to do with Proj 4 is that correct? Okay.
19:26
I normally only use different things that were somewhat irregular but not interrupted or you know I'm confident the current one would actually fall apart in some of your more interesting cases. It would get lost, it would fail to resolve the inversion but it seems
19:41
like that that's how I would be inclined to approach it. Interesting okay thank you. So I think there's that I'd
20:13
give two answers to that. The first one is if they just want to see some data they just want a picture then I'd resample the data. I'd try and resample
20:21
from the rotated pole on to something that QGIS would understand. And so we've got Python tools which we've written specifically and to meet some of these use cases so I mentioned one called Cartapie. There's another tool that we've written called IRS which is a data management tool but that would give you some tools to do a resampling
20:41
onto a coordinate system that they could work with and if they particularly wanted to use QGIS if they just want a picture then the IRS and Cartapie tools will do that and just give you pictures and it uses a plotting engine. The ones the pictures that I was showing earlier are coming straight out of those tools so I can provide you information about those and those are free and open tools. In
21:01
fact they're on your OSGOCD that you've got from the conference so you can experiment with them on there and have a little play around. And if you are going to go down the route of resampling the data then the people who are doing it do need to be aware that you are changing the data at the point where you're resampling it so that you need to apply a little bit of caution and particularly if
21:20
you're changing the resolution at the same time so don't assume that you're getting exactly the same numbers. It doesn't quite work like that.
21:51
Okay, well thank you very much.