Performance and the GeoWeb
One of the most frequently raised issues in relation to the GeoWeb is that of performance. Since the GeoWeb builds on XML and Web Services technologies this should bot be too surprising. XML provides redundant description of the content and the structure of the content which is assumed to be known by the creator or the consumer in the case of binary formats. Note further that XML is not a format and hence provides an additional isolation layer from the file structure. None of this comes without a price.
Performance than needs to be looked at in the proper light. We are likely familiar with the nice dataset demos of companies like Navteq - where one zooms from a continential view (USA, Europe) to street level in a second or so. Very impressive. One must ask though, if this is the issue that the GeoWeb is trying to solve. We need to look at that view of performance against another one implicitly expressed by Jack Dangermond in remarks to a HomeLand Security Conference following the Katrina disaster. Here it is not so much as "how fast" but can we do it - or can we do it fast enough (minutes to hours) to be of any use to anyone. In Jack's words:
‘We're not very good at bringing all this together now –we're maybe pretty good at it if you look at it one city at a time. But I have a vision that we could be good at it across the nation at some point in the future.”
’Jack Dangermond, President of ESRI, addressing the company’s Homeland Securities event,
in reference to Hurricane Katrina’s rescue efforts.
So speed is very much a relative matter. This is not something that is easily overcome by narrowly defined binary formats - it requires rich expressiveness and some ability to self document the data - precisely the things that XML and Web Services (hence GML, WFS) are designed to do.
Another way of looking at things - is to see how fast to things change - it is neat if I can send you a big file (note that the file format technologies always lead us in this direction) containing hundreds of thousands of features - and not so neat if I send you the same file tomorrow when only 5-10 of these features have changed. If my technology enables sending only the changes (and does so in a transparent or nearly transparent manner) that may be far more efficient and faster than one that leads us to wholesale file exchange. The GeoWeb is thus more about transactonal synchronization of datasets then copyng them over and over again from one place to another. Seen in this light we see that XML and Web Services (GML, WFS, WRS) offer a route to greatly increased overall performance - in the manner that matters for real business applications.
Performance than needs to be looked at in the proper light. We are likely familiar with the nice dataset demos of companies like Navteq - where one zooms from a continential view (USA, Europe) to street level in a second or so. Very impressive. One must ask though, if this is the issue that the GeoWeb is trying to solve. We need to look at that view of performance against another one implicitly expressed by Jack Dangermond in remarks to a HomeLand Security Conference following the Katrina disaster. Here it is not so much as "how fast" but can we do it - or can we do it fast enough (minutes to hours) to be of any use to anyone. In Jack's words:
‘We're not very good at bringing all this together now –we're maybe pretty good at it if you look at it one city at a time. But I have a vision that we could be good at it across the nation at some point in the future.”
’Jack Dangermond, President of ESRI, addressing the company’s Homeland Securities event,
in reference to Hurricane Katrina’s rescue efforts.
So speed is very much a relative matter. This is not something that is easily overcome by narrowly defined binary formats - it requires rich expressiveness and some ability to self document the data - precisely the things that XML and Web Services (hence GML, WFS) are designed to do.
Another way of looking at things - is to see how fast to things change - it is neat if I can send you a big file (note that the file format technologies always lead us in this direction) containing hundreds of thousands of features - and not so neat if I send you the same file tomorrow when only 5-10 of these features have changed. If my technology enables sending only the changes (and does so in a transparent or nearly transparent manner) that may be far more efficient and faster than one that leads us to wholesale file exchange. The GeoWeb is thus more about transactonal synchronization of datasets then copyng them over and over again from one place to another. Seen in this light we see that XML and Web Services (GML, WFS, WRS) offer a route to greatly increased overall performance - in the manner that matters for real business applications.
