The GeoPDF format seems to be gaining traction these days. I have to admit, when I first heard of this technology I had the same reaction as James Fee - "What's it good for"? But I'm coming round... A live map with rich information content and a true geospatial coordinate system - what's not to like?
My excuse for such scepticism is my finely-honed technical bullsh*t reflex, which uses the logic of "If this is such a good, obvious, simple idea then why hasn't it been implemented ages ago?".
To be fair, there have been lots of SVG mapping demos, which fill the same use case and provide equivalent functionality. Sadly that concept hasn't really caught fire, though (perhaps due to the ongoing SVG "always a bridesmaid, never a bride" conundrum).
Of course, an idea this good is really too important to be bottled up in the murky world of proprietary technology. It seems like this area is ripe for an open standard. SVG is the obvious candidate for the spatial content (sorry, GeoJSON). What it needs is some standards around modelling geospatial coordinate systems and encoding layers of features. It seems like this should be quite doable. The goal would be to standardize the document format so that viewers could easily be developed (either stand-alone, as modules of existing viewers, or as browser-hosted apps). Also, the feature data should be easy to extract from the data file, for use in other applications.
Perhaps there's already an initiative like this out there - if so, I'd love to hear about it.
Showing posts with label geospatial. Show all posts
Showing posts with label geospatial. Show all posts
Monday, June 23, 2008
Friday, April 18, 2008
KML Craziness
Why oh why did KML choose to specify colour values as AGBR ABGR rather than RGBA? Does anyone have a rational explanation for this anomaly?
Monday, March 24, 2008
Time for JSTS?
Like a lot of stuff, spatial functionality is moving out into the browser. Signs of the times:
Take it away, someone - I'm too busy!
- proj4js
- GeoJSON
- This comment: "The DOJO client-side libraries provide support for performing some simple spatial operations like ‘intersection’ on the client-side." (Although I haven't been able to find this functionality in a quick browse of Dojo - can anyone confirm this?)
Take it away, someone - I'm too busy!
Tuesday, March 18, 2008
World Population Cartograms
The Daily Green has some cartograms showing the change in distribution of world population since 1900.
But there's another aspect to this that the original images don't show - the increase in the absolute number of people in the world. So here's the images with that factor applied:
1900 - 1.65 B
2007 - 6.64 B
But there's another aspect to this that the original images don't show - the increase in the absolute number of people in the world. So here's the images with that factor applied:
1900 - 1.65 B
2007 - 6.64 B
2050 - ~ 9 B
Monday, March 3, 2008
Branch-and-Bound algorithms for Nearest Neighbour queries
This paper by Roussopoulos et al is a fine expositions of how to use a Branch-and-Bound algorithm in conjunction with an R-tree index to efficiently perform Nearest-Neighbour queries on a spatial database.
Nearest-neighbour is a pretty standard query for spatial database. Oracle Spatial offers this capability natively. It would be great if PostGIS did too. If the GIST index API offers appropriate access methods, it seems like it might not be too hard to implement the Roussopoulos algorithm. (How about it, Paul, now that you're dedicating your life to becoming a PostGIS coding wizard...)
I'm also thinking that this approach might produce an efficient algorithm for computing distance between Geometrys for JTS. It's always bugged me that the JTS distance algorithm is just plain ol' O(N^2) brute-force. It seems like there has to be a better way, but as usual there seems to be precious little prior art out there in web-land. This should also work well in the "Prepared" paradigm, which means that it will provide an efficient implementation for PostGIS as well. Soon, hopefully...
Nearest-neighbour is a pretty standard query for spatial database. Oracle Spatial offers this capability natively. It would be great if PostGIS did too. If the GIST index API offers appropriate access methods, it seems like it might not be too hard to implement the Roussopoulos algorithm. (How about it, Paul, now that you're dedicating your life to becoming a PostGIS coding wizard...)
I'm also thinking that this approach might produce an efficient algorithm for computing distance between Geometrys for JTS. It's always bugged me that the JTS distance algorithm is just plain ol' O(N^2) brute-force. It seems like there has to be a better way, but as usual there seems to be precious little prior art out there in web-land. This should also work well in the "Prepared" paradigm, which means that it will provide an efficient implementation for PostGIS as well. Soon, hopefully...
Monday, December 3, 2007
Cross-Border issues with Google Maps terrain
So GM now has terrain - yay! But they seem to have short-changed half the continent. Check this screenshot from the border just south of Chilliwack. Notice the American Border Peak - but where's the Canadian one? And what's with that crazy-looking border swathe?
I assure US viewers that Canada isn't normally this blurry. And no, it isn't proof that we really do have a year-round 4 ft snowpack!
Ok, I know - never satisfied. Really, this is a very nice feature. I just hope Google gets their north-of-the-border vision lasered real soon...
I assure US viewers that Canada isn't normally this blurry. And no, it isn't proof that we really do have a year-round 4 ft snowpack!
Ok, I know - never satisfied. Really, this is a very nice feature. I just hope Google gets their north-of-the-border vision lasered real soon...
Wednesday, November 14, 2007
Implementations of Polygon Overlay algorithms
Occasionally people ask about the algorithms used in JTS's overlay operations. I don't have a good answer for this, since I basically made it up (in an informed kind of way), and haven't had time to document it to the level I'd like (thank goodness for self-documenting code... 8^)
I recently came across this web site from back in 1998, which is happily still around. It has a good list of implementations of what it calls Polygon Boolean operations. (This is the same thing as the JTS overlay operations - I chose to use a different term to avoid confusion with the spatial predicates). Perhaps some of these sites have done a better job of documentation! There's also some useful references to academic papers covering aspects of the issue.
I recently came across this web site from back in 1998, which is happily still around. It has a good list of implementations of what it calls Polygon Boolean operations. (This is the same thing as the JTS overlay operations - I chose to use a different term to avoid confusion with the spatial predicates). Perhaps some of these sites have done a better job of documentation! There's also some useful references to academic papers covering aspects of the issue.
Friday, November 9, 2007
The bible of Spatial Indexing
The Bhagavad Gita of Multidimensional Access Methods...
The Koran of Quadtrees...
One of the people I met at ACM GIS 2007 was the conference chair, Hanan Samet. He's published a series of highly useful books on spatial indexing methods, which are certainly the most comprehensive and detailed in this field. His latest work is Foundations of Multidimensional and Metric Data Structures and is surely his magnum opus. It could also be called Everything you wanted to know about Spatial Indexes (but were afraid to code). Recommended reading for spatial geeks, especially if you're looking for some reading to tide you over during your next year off.
His first book on the subject, The Design and Analysis of Spatial Data Structures, is also worth looking at, especially since it's a bit more bite-sized. However, it's out-of-print, and expensive when you do find a copy (local plug: I found mine through ABE) If you really can't find a copy you might try contacting Hanan directly.
Hanan has a clear preference for quadtree structures over R-trees, but both approaches are covered well (including pseudo-code - yay!)
The Koran of Quadtrees...
One of the people I met at ACM GIS 2007 was the conference chair, Hanan Samet. He's published a series of highly useful books on spatial indexing methods, which are certainly the most comprehensive and detailed in this field. His latest work is Foundations of Multidimensional and Metric Data Structures and is surely his magnum opus. It could also be called Everything you wanted to know about Spatial Indexes (but were afraid to code). Recommended reading for spatial geeks, especially if you're looking for some reading to tide you over during your next year off.
His first book on the subject, The Design and Analysis of Spatial Data Structures, is also worth looking at, especially since it's a bit more bite-sized. However, it's out-of-print, and expensive when you do find a copy (local plug: I found mine through ABE) If you really can't find a copy you might try contacting Hanan directly.
Hanan has a clear preference for quadtree structures over R-trees, but both approaches are covered well (including pseudo-code - yay!)
Monday, September 17, 2007
Bursa-Wolf transformations explained
.. courtesy of Adrian Custer on the OpenJUMP mailing list:
> > just one question .. what is this bursa wolf parameter option?
> My impression is that this is scary math I never quite understood.
Well, Bursa was a 9 year old bicyclist from the Alps and...no, no, no, i
lie. Actually it's not particularly scary math and quite easy to
understand. All you really need to remember is that no one has ever been
to the center of the earth.
So everyone started surveying (mostly so the repressive central
governments could exploit taxes from people and have lots of jolly wars
where people could slog through the mud and kill each other so they'd be
blood and suffering for all). Each group started from some random place
on the surface of the earth. Right away, it becomes obvious to everyone
that euclidean rules don't work so well. Some didn't care so much since
taxes are basically arbitrary anyway and getting serious about it means
you'd have to walk through fields and woods and get lots of mud on your
shoes. Others kept at it and resorted to spherical geometry. Once you
start doing that precisely and at continental scales you realize that
doesn't really work either so you decide to try the next hardest thing,
an ellipsoid of rotation. Now how do you know which one to choose? Well
you pick one that minimizes your squared errors. All good and nice but
(1) you are surveying the ground which is anything but an ellipsoid
since it has all those ditches you keep falling into and that keep
getting your clothes covered in mud and (2) you are not perfect
especially with all that mud on your paper. So you have a bunch of
errors. Well everyone that does this comes up with lots of different
ellipsoids that work really nice for their data and everyone is sure
they clearly have found the 'one true ellipsoid' and they decide to use
that for all their work. Then everyone guesses where they actually are
on each of their particular ellipsoids which involves lots of going
outside at night and looking up from the mud at the stars. But then it's
not like the edges of each survey was nice and level on these ellipsoids
either --- think of the eastern USA. You can start nice and clean and
warm and dry at an inn in Boston on the edge of the sea drinking clam
chowder and having a good time but a few months later it will be bitter,
bitter cold in that tiny town of Denver because you are somewhere like a
mile high up in the air and you're wet and covered in mud from slogging
through the plains in a snowstorm. So you've got a pretty good idea that
your data is on a major slant but, well, you'll do your best to make up
for it but it really doesn't help the effort any, especially what with
all that mud that's still itching in your hair. So your errors may be a
wee bit big but hey it's all right: it's good enough to wage lots of
good wars with lots of mud and blood and to keep collecting lots of
taxes so no one cares too much.
Fast forward to more recent times where some people want to talk to lots
of different governments and work with lots of different data. They take
everyone's guess and try to line them up. Well it turns out, when you
try to line everything up, that the center points of all the different
ellipses aren't really the same points and even the orientation of the
three axes are all a bit off because of how everyone guessed where their
were on their ellipsoids. So now, to go from one data set to another so
they line up "the best," you need estimates of how much to rotate each
of the axes and how to shift the center point around; all this beyond
even the obvious stuff of changing between the different definition of
all those "one true" ellipsoids.
When you do this mathematically, you need a bunch of parameters: these
now have the names of the wolf and the bursa. Generally, you can only
come up with good parameters if you have lots of data to compare and
some good software to do the comparing. That's what the EPSG did for
everyone. The guys in the pickup trucks that went out looking for oil
kept falling into ditches along the way and getting mud on their faces
but when they got back to the office they had a good sense of what lined
up with what and could say: "yep, that hill there is the same as this
squiggle here and there's this big ditch right here that cost us our
third flat tire and..." So they collected as much data as they could and
compared it and came up with a database of parameters by which you go
from one data set to another. So that's it. That's why we use their
data; we don't have to fall in any ditches and can avoid getting mud on
our clothes. They give us their parameters and we can mostly line up
data from one survey against data from another. But you do need some
good parameters because the earlier folk had a harder time of the mud
and the data they created don't just line up the way we would like them
to.
Actually doing the math is a bit harder but the concept is pretty
straight forward: geographic data all ultimately gets tied into points
on the earth surface and that requires estimating where the points
really are and how they line up on the estimated ellipsoid being used.
That in turn means none of ellipsoids quite line up and we need
parameters to move between them.
--adrian
> > just one question .. what is this bursa wolf parameter option?
> My impression is that this is scary math I never quite understood.
Well, Bursa was a 9 year old bicyclist from the Alps and...no, no, no, i
lie. Actually it's not particularly scary math and quite easy to
understand. All you really need to remember is that no one has ever been
to the center of the earth.
So everyone started surveying (mostly so the repressive central
governments could exploit taxes from people and have lots of jolly wars
where people could slog through the mud and kill each other so they'd be
blood and suffering for all). Each group started from some random place
on the surface of the earth. Right away, it becomes obvious to everyone
that euclidean rules don't work so well. Some didn't care so much since
taxes are basically arbitrary anyway and getting serious about it means
you'd have to walk through fields and woods and get lots of mud on your
shoes. Others kept at it and resorted to spherical geometry. Once you
start doing that precisely and at continental scales you realize that
doesn't really work either so you decide to try the next hardest thing,
an ellipsoid of rotation. Now how do you know which one to choose? Well
you pick one that minimizes your squared errors. All good and nice but
(1) you are surveying the ground which is anything but an ellipsoid
since it has all those ditches you keep falling into and that keep
getting your clothes covered in mud and (2) you are not perfect
especially with all that mud on your paper. So you have a bunch of
errors. Well everyone that does this comes up with lots of different
ellipsoids that work really nice for their data and everyone is sure
they clearly have found the 'one true ellipsoid' and they decide to use
that for all their work. Then everyone guesses where they actually are
on each of their particular ellipsoids which involves lots of going
outside at night and looking up from the mud at the stars. But then it's
not like the edges of each survey was nice and level on these ellipsoids
either --- think of the eastern USA. You can start nice and clean and
warm and dry at an inn in Boston on the edge of the sea drinking clam
chowder and having a good time but a few months later it will be bitter,
bitter cold in that tiny town of Denver because you are somewhere like a
mile high up in the air and you're wet and covered in mud from slogging
through the plains in a snowstorm. So you've got a pretty good idea that
your data is on a major slant but, well, you'll do your best to make up
for it but it really doesn't help the effort any, especially what with
all that mud that's still itching in your hair. So your errors may be a
wee bit big but hey it's all right: it's good enough to wage lots of
good wars with lots of mud and blood and to keep collecting lots of
taxes so no one cares too much.
Fast forward to more recent times where some people want to talk to lots
of different governments and work with lots of different data. They take
everyone's guess and try to line them up. Well it turns out, when you
try to line everything up, that the center points of all the different
ellipses aren't really the same points and even the orientation of the
three axes are all a bit off because of how everyone guessed where their
were on their ellipsoids. So now, to go from one data set to another so
they line up "the best," you need estimates of how much to rotate each
of the axes and how to shift the center point around; all this beyond
even the obvious stuff of changing between the different definition of
all those "one true" ellipsoids.
When you do this mathematically, you need a bunch of parameters: these
now have the names of the wolf and the bursa. Generally, you can only
come up with good parameters if you have lots of data to compare and
some good software to do the comparing. That's what the EPSG did for
everyone. The guys in the pickup trucks that went out looking for oil
kept falling into ditches along the way and getting mud on their faces
but when they got back to the office they had a good sense of what lined
up with what and could say: "yep, that hill there is the same as this
squiggle here and there's this big ditch right here that cost us our
third flat tire and..." So they collected as much data as they could and
compared it and came up with a database of parameters by which you go
from one data set to another. So that's it. That's why we use their
data; we don't have to fall in any ditches and can avoid getting mud on
our clothes. They give us their parameters and we can mostly line up
data from one survey against data from another. But you do need some
good parameters because the earlier folk had a harder time of the mud
and the data they created don't just line up the way we would like them
to.
Actually doing the math is a bit harder but the concept is pretty
straight forward: geographic data all ultimately gets tied into points
on the earth surface and that requires estimating where the points
really are and how they line up on the estimated ellipsoid being used.
That in turn means none of ellipsoids quite line up and we need
parameters to move between them.
--adrian
Thursday, September 13, 2007
Geodetic data in PostGIS - Spherical indexing schemes
Here at Refractions we're starting to think about how we can provide better support in PostGIS for geodetic data. Geodetic data is data which is defined in a true spherical coordinate system (in particular, of course, the surface of the Earth).
Currently PostGIS provides some geodetic-aware functions (such as distance between two geodetic points). But it's current spatial data model is fundamentally planar, so there are definite limitations to modelling geodetic data (e.g. such as the notorious "line crossing the Date Line" problem). As PostGIS gets used for larger datasets and more ambitious projects, the utility of having a full-function geodetic data model is becoming increasingly obvious.
Handling geodetic data in a correct and efficient way presents quite a few challenges. A major one is: how can geodetic geometry be spatially indexed? Conventional spatial indexes (such as 2D R-trees) all rely on geometry being embedded in a planar space. They don't handle data which can "wrap around", as can occur in a spherical space.
There have been various clever proposals for spherical indexing strategies. Some prominent ones are listed below:
Currently PostGIS provides some geodetic-aware functions (such as distance between two geodetic points). But it's current spatial data model is fundamentally planar, so there are definite limitations to modelling geodetic data (e.g. such as the notorious "line crossing the Date Line" problem). As PostGIS gets used for larger datasets and more ambitious projects, the utility of having a full-function geodetic data model is becoming increasingly obvious.
Handling geodetic data in a correct and efficient way presents quite a few challenges. A major one is: how can geodetic geometry be spatially indexed? Conventional spatial indexes (such as 2D R-trees) all rely on geometry being embedded in a planar space. They don't handle data which can "wrap around", as can occur in a spherical space.
There have been various clever proposals for spherical indexing strategies. Some prominent ones are listed below:
- Hierarchical Triangular Mesh - this is essentially a "quad-tree for the sphere". It has a lot of appeal for use with point data, since it provides a hierarchical key which can be indexed using a conventional B-tree index. (It was co-developed by the late, great Jim Gray in order to index astronomical data). The mathematics to determine the index key for a non-point object would seem to be somewhat complicated. It also seems like HTM would suffer from the usual disadvantage of quadtrees of not being very self-tuning. Another disadvantage from the PostGIS point of view is that this would likely be a brand new index type (i.e. lots of difficult code to write)
- Hipparchus Voronoi-based index. This index can be thought of as a fixed-grid index using a custom Voronoi cell coverage for the globe. IBM's DB/2 Geodetic extension uses this scheme. I must say that this concept, while ingenious, seems a bit baroque to me. This index has the usual disadvantage of fixed-grid indexes of not handling widely-varying data sizes well. And it also requires extremely complex cell coverage structures, which have to be selected specifically for the expected data composition. DB/2 supplies 13 different ones based on various data densities (G7 industrial output, anyone?). I'm not sure what you are supposed to do if your data has some other density distribution - it doesn't seem very feasible to make your own Voronoi grid. And what if you don't know your data distribution, or it changes over time?
- 3D Bounding Box - this is the approach used by the pgSphere project. It's pretty straightforward. The key concept is to embed the sphere in 3-space, so that it is possible to compute 3D bounding boxes for geometries on the embedded sphere. The bounding boxes can then be indexed using a 3D R-tree (exactly analogous to a 2D R-tree spatial index). The GIST index supplied with PostgreSQL can be customized to provide the required 3D R-tree. One possible issue is that apparently R-trees become "less effective" in higher-dimensional spaces. It remains to be seen whether this is truly a serious problem.
Tuesday, August 21, 2007
Streaming Delaunay Triangulation for Huge Datasets
Isenburg, Liu, Shewchuk and Snoeyink have an interesting paper on contructing Delaunay triangulations over huge datasets using a streaming technique.
I'm quite interested in this, because here at Refractions I've just finished working on a project which involved computing a TIN for the province of B.C. using 500 million masspoints. After briefly flirting with the idea of computing a single seamless TIN, I ended up computing it in a piecewise fashion. This probably turned out to be a better approach for other reasons (such as the fact that we could easily parallelize the process). However, it would be very cool to be able to compute a seamless TIN for the entire province. And the approach in this paper sounds very effective - they quote a billion triangle in 48 minutes on a laptop!
It's also exciting to see the emergence of a whole new class of algorithms focussed on dealing with VLSD's (very large spatial datasets). As the same authors point out in another paper, paradoxically, advances in computing technology can make geospatial processing more difficult
because the rate of growth of dataset size far outstrips memory capacity.
Incidentally, these guys are a bit of a dream team for computational geometry algorithms. Shewchuck is the developer of Triangle, one of the best known programs for computing constrained 2D Delaunay triangulations (which is also AFAIK one of the few available systems to seriously address robustness issues - JTS of course being another one!) Snoeyink has done research in all kinds of different areas of CG, including interesting work in computing watershed boundaries on TINs using B.C. data.
The paper also has a nice way of showing the spatial distribution of two related variables, using fill gradients:
I'm quite interested in this, because here at Refractions I've just finished working on a project which involved computing a TIN for the province of B.C. using 500 million masspoints. After briefly flirting with the idea of computing a single seamless TIN, I ended up computing it in a piecewise fashion. This probably turned out to be a better approach for other reasons (such as the fact that we could easily parallelize the process). However, it would be very cool to be able to compute a seamless TIN for the entire province. And the approach in this paper sounds very effective - they quote a billion triangle in 48 minutes on a laptop!
It's also exciting to see the emergence of a whole new class of algorithms focussed on dealing with VLSD's (very large spatial datasets). As the same authors point out in another paper, paradoxically, advances in computing technology can make geospatial processing more difficult
because the rate of growth of dataset size far outstrips memory capacity.
Incidentally, these guys are a bit of a dream team for computational geometry algorithms. Shewchuck is the developer of Triangle, one of the best known programs for computing constrained 2D Delaunay triangulations (which is also AFAIK one of the few available systems to seriously address robustness issues - JTS of course being another one!) Snoeyink has done research in all kinds of different areas of CG, including interesting work in computing watershed boundaries on TINs using B.C. data.
The paper also has a nice way of showing the spatial distribution of two related variables, using fill gradients:
Saturday, June 16, 2007
Presentations at FOSS4G 2007
I'm giving two talks at FOSS4G 2007, which is taking place here in Victoria in September. The abstracts are:
The JTS Topology Suite: Tools, Tips & Techniques
The JTS Topology Suite is one of the most widely used geometry libraries for Java. This talk will review the standard geometry methods in JTS, with an emphasis on their finer details. Some of the additional algorithms and components which the library provides will be discussed. Tips for improving performance and techniques for accomplishing various kinds of geometric processing tasks will be presented. The talk will conclude with an preview of some potential future developments for JTS.
If previous years are anything to go by, this conference should be very informative and energizing. See you there!
The JTS Topology Suite: Tools, Tips & Techniques
The JTS Topology Suite is one of the most widely used geometry libraries for Java. This talk will review the standard geometry methods in JTS, with an emphasis on their finer details. Some of the additional algorithms and components which the library provides will be discussed. Tips for improving performance and techniques for accomplishing various kinds of geometric processing tasks will be presented. The talk will conclude with an preview of some potential future developments for JTS.
Automatic watershed delineation using open source Java
The B.C. Corporate Watershed Base is a large-scale database of hydrographic information built using open source products. This talk discusses the development of an open source system for automated delineation of watershed boundaries based on CWB hydrography and a terrain model.If previous years are anything to go by, this conference should be very informative and energizing. See you there!
Monday, May 14, 2007
GeoTec 2007 presentation on Automated Watershed Boundary Generation
I'm giving a talk at GeoTec 2007 in Calgary entitled "WaterBuG: An Automated Generator for Watershed Boundaries". This covers a project I've been working on for the last year-and-a-half. It's a very cool application of complex large-scale geo-processing, using a whole assortment of nifty geometric structures and algorithms such as:
Here's a couple of screenshots from the talk - I'll post the full presentation sometime soon, somewhere...
- quad-edge subdivisions for modelling
- Triangular Irregular Networks (Delaunay triangulations)Delaunay triangulation refinement
- Medial axis refinement
- Surface modelling with a TIN
- Surface hydrological flow modelling over a TIN
- Flood filling
- Depth- and breadth-first Graph traversal
- Topology-preserving Linestring smoothing
- Discrepancy detection
Here's a couple of screenshots from the talk - I'll post the full presentation sometime soon, somewhere...
Saturday, May 12, 2007
Whither Google Earth?
No question, GE has been wildly succesful. It pretty much single-handedly created the category of "spinny-globe" applications. As usual for Google, it redefined the parameters of what people thought the web was capable of doing (never mind that it was really Keyhole that did this, and skipping lightly over the fact that Google had to release a thick client app to achieve it). The bottom line is that GE has huge mindshare that competitors (WorldWind, MS Virtual Earth, ESRI ArcExplorer) are only just starting to nibble away at.
But can it last?
My prediction (and hope) is - No. Or at least, not in the same category-dominating way.
Reasons?
One is that the spinny globe paradigm is simply too fundamental to the way we want to interact with the virtual world to be left to a single company or application to dominate. Google/Keyhole proved the concept, but WorldWind shows that it can be done more generally and more openly - which in the end I believe has to win out.
Another is that as I've worked a bit more with GE and KML, I am astounded and annoyed by the numerous limitations of the data visualization options they provide. The simplest GIS viewer provides way better visualization options than GE (I know - I wrote one!). This isn't rocket science. My guess is that this reflects the fact that Google is not in the business of providing great visualization - they're in the business of selling ads. Which brings me to my next point...
It is probably contrary to Google's business model to enhance GE's capabilities too far. Make it more powerful and more configurable, and people start using it to do things which are just a distraction to the business of getting eyeballs on ads.
One possible opposing force to this thesis is the rising competition with other SG vendors (most notably of course MS). Perhaps this competition will force the evolution of greater functionality. But I'm not holding my breath - the other vendors all have their own business models which probably don't encourage loading functionality into the tools. The vendor with the most to gain from providing full-spectrum functionality is ESRI - but since they're really in the business of selling software, not data, my guess is that whatever they come up with is not going to be a real happy place to be for many users.
The one great hope IMO is WorldWind. They are ahead in some ways, behind in others, but they alone have no agenda other than making a really great SG application. I only hope they continue to thrive - although their dependence on the bureacratic whims of NASA makes me worry.
To go way out on a limb and look 20 yrs down the road, it may well be that spinny-globe access becomes much like topographic maps today - so essential to individual and business information that they (or at least the data repositories and protocols) are government-sponsored and freely available to all (ok, so topo maps aren't currently 100% free, but even here in behind-the-curve Canada more and more spatial data is being made freely available by Gov't). Maybe the SG app will just become a standard view in whatever is being used as a Web browser, with open formats and data models.
We can only hope...
But can it last?
My prediction (and hope) is - No. Or at least, not in the same category-dominating way.
Reasons?
One is that the spinny globe paradigm is simply too fundamental to the way we want to interact with the virtual world to be left to a single company or application to dominate. Google/Keyhole proved the concept, but WorldWind shows that it can be done more generally and more openly - which in the end I believe has to win out.
Another is that as I've worked a bit more with GE and KML, I am astounded and annoyed by the numerous limitations of the data visualization options they provide. The simplest GIS viewer provides way better visualization options than GE (I know - I wrote one!). This isn't rocket science. My guess is that this reflects the fact that Google is not in the business of providing great visualization - they're in the business of selling ads. Which brings me to my next point...
It is probably contrary to Google's business model to enhance GE's capabilities too far. Make it more powerful and more configurable, and people start using it to do things which are just a distraction to the business of getting eyeballs on ads.
One possible opposing force to this thesis is the rising competition with other SG vendors (most notably of course MS). Perhaps this competition will force the evolution of greater functionality. But I'm not holding my breath - the other vendors all have their own business models which probably don't encourage loading functionality into the tools. The vendor with the most to gain from providing full-spectrum functionality is ESRI - but since they're really in the business of selling software, not data, my guess is that whatever they come up with is not going to be a real happy place to be for many users.
The one great hope IMO is WorldWind. They are ahead in some ways, behind in others, but they alone have no agenda other than making a really great SG application. I only hope they continue to thrive - although their dependence on the bureacratic whims of NASA makes me worry.
To go way out on a limb and look 20 yrs down the road, it may well be that spinny-globe access becomes much like topographic maps today - so essential to individual and business information that they (or at least the data repositories and protocols) are government-sponsored and freely available to all (ok, so topo maps aren't currently 100% free, but even here in behind-the-curve Canada more and more spatial data is being made freely available by Gov't). Maybe the SG app will just become a standard view in whatever is being used as a Web browser, with open formats and data models.
We can only hope...
Friday, May 11, 2007
Limitations of Google Earth as a GIS Viewer
I'm starting to actually try and used Google Earth for viewing geospatial data - and almost immediately I'm hitting my head against the ceiling. It seeems to be sorely missing some very basic GIS functionality (or else I'm not reading the manual closely enough - but the limitations of the "manual" also make my head hurt). Where are things like:
- Line styles (dots and dashes?)
- Labels for lines and polygons (Google roads get cool haloed rotated text - c'mon, I wanna play too!)
- Tooltips for features
- A decent zoom-to-feature
- Decent rendering for polygonal outlines in oblique views (this is a weird one - the outlines seem to get more blocky as the viewpoint gets lower. Linear features render fine, so I presume this is some sort of artifact of a different display pipeline)
- What's with defining colours as ABGR instead of the world-wide standard RGBA? Is someone at Google cixelsyd?
- No extensibility with custom add-ons
- You can't change the terrain model (admittedly not everyone happens to have a DEM lying around - but I do, and I want to use it!)
They did get some stuff right though... The mouse navigation is good - although I think WorldWind's is better. WW's use of the right mouse button is way faster (for me) than using magic disappearing on-screen controls.
And of course KML has created an instant de-facto cartographic standard (I deliberately do not call it a geospatial data standard). Although it's pretty limited as well - SVG is way richer.
So I wonder if and when these shortcomings will be addressed? More on that later...
Subscribe to:
Posts (Atom)
