Make your own KML (for Google Earth)
I have no real way of knowing just how popular the "Download to Google Earth" option is on our geocoder. This because once you load the home page, you could request KMLs all day and I don't see them as new page views in the logs. I have heard from several people who are using it successfully to create libraries of KMLs, which they then mix and match setting up different colors for different data. (If you want to add your colors, just add a "color" column to your source data and throw in an Hex RGB value for the color.)
KML is pretty cool. It lets you do some amazing things, with a very simple XML based syntax. The great thing about it, is unlike popular GIS formats like an ESRI shapefile, both the data and the rendering information are stored in the KML. This means when you send your KML file to your buddy, he can open it up in Google Earth and immediately visualize it in the same way you do. With classic GIS data, your buddy would need to set up his own rendering parameters, which probably are going to end up different than what you are looking at.
With ESRI's Arc8 suite, there became a concept of the "layer file" and MXD, both store a pointer to the data as well as the rendering information, however neither store the data itself. ESRI gives you ways of storing information, and storing rendering parameters... but never together. There have been attempts to do this in the past, but they never seem to make it into the standard ArcMap. Word on the street is this will be changing in future versions of the Arc9 suite, but its funny its taken so long to get to that point.
Backwards compatibility are other big problems for ESRI data formats and MXDs. If I save an MXD in Arc9, you will not be able to read it in Arc8. Likewise if I have an ArcSDE 9 database, you will not be able to connect to it in Arc8. This presents huge problems for enterprise GIS users, who are forced to upgrade everyone at once or have dual environments for newer and older versions of the software. Unfortunately this seems to be a problem that won't be fixed any time in the near future.
Google got it right the first time, whereas ESRI has been doing it for over 30 years now and they still aren't there. So who is the real map expert?
KML is pretty cool. It lets you do some amazing things, with a very simple XML based syntax. The great thing about it, is unlike popular GIS formats like an ESRI shapefile, both the data and the rendering information are stored in the KML. This means when you send your KML file to your buddy, he can open it up in Google Earth and immediately visualize it in the same way you do. With classic GIS data, your buddy would need to set up his own rendering parameters, which probably are going to end up different than what you are looking at.
With ESRI's Arc8 suite, there became a concept of the "layer file" and MXD, both store a pointer to the data as well as the rendering information, however neither store the data itself. ESRI gives you ways of storing information, and storing rendering parameters... but never together. There have been attempts to do this in the past, but they never seem to make it into the standard ArcMap. Word on the street is this will be changing in future versions of the Arc9 suite, but its funny its taken so long to get to that point.
Backwards compatibility are other big problems for ESRI data formats and MXDs. If I save an MXD in Arc9, you will not be able to read it in Arc8. Likewise if I have an ArcSDE 9 database, you will not be able to connect to it in Arc8. This presents huge problems for enterprise GIS users, who are forced to upgrade everyone at once or have dual environments for newer and older versions of the software. Unfortunately this seems to be a problem that won't be fixed any time in the near future.
Google got it right the first time, whereas ESRI has been doing it for over 30 years now and they still aren't there. So who is the real map expert?
posted by pkh at
8:08 AM
8 Comments:
I'm not exactly an apologist for ESRI, but I think that storing styling with the data is something that is dangerous, and really needs a lot of thought to get it right. It certainly makes sense for data presentation frameworks like Google Earth to be as flexible as possible, but it can wreak havok in the desktop GIS world.
Nothing is worse than going through a MapInfo file that looks great when printed, but which has intelligence similar to an old CAD drawing with line width, style, and colour being used as attributes.
It can be argued that this is the user's fault, but I feel that software should be responsible for making it easier to do things right than it is to do things wrong.
It would be great to be able to include styling information in a Geodatabase, but it should be based on the data model, not arbitrary "make this line 2 point, red, dashed."
Jason
By
Jason Birch, at 2:43 PM
jason - Why not include all the rendering information in the geodatabase? At least as a default?
In my experience most people want to spend less time setting maps up and more time using them. If I could setup before hand the perfect rendering for a map, and then everyone who connects to that map can see it (by default) with my rendering... then I think that saves a lot of people the hassle of setting everything up.
If someone sends you a document, would you rather open it up in Notepad and then format it yourself, or would you want it as a PDF?
Especially things like setting up class break renderers takes forever... Why plague every user opening up the data with doings this?
Of course layer files and MXDs are one solution, but they are seperate from the data. I think the beauty of KMLs is that its all in one package. And yes, if you want, you could still change it.
By
pkh, at 11:12 AM
As a GIS professional I have to agree with Jason on this. How your data is delivered is very dependant upon the audience that you intend to use it. For what I term 'general consumption' pkh is correct no one wants to have to define the line type and colour. However as datasets get more complex having the rendering info interwoven with the actual data will become a nightmare to manage unless it's done correctly. In my mind KML is going down the wrong path.
The world wide web (does anyone still use that term any more?) gives us a great example. When everyone and their dog started setting up their first web pages they put the rendering info directly into the web page with the content. Who would ever want the info without all the fancy tables, images, and animated smiley faces? Of course 2 issues arose from this practice. First if you had a large site and you needed to change the look of your website it was a huge amount of work. Secondly people slowly came to the realization that beauty (and functionality to a lesser extent) was in the eyes of the beholder. Your 'perfectly rendered' website looked awful to many other people. The solution to this was to start publishing websites with their content separate from the rendering info so that users could easily view the website the way they wanted to. With KML how do I simply view the dataset, but without all the mark up and rendering info that doesn't work for me? For example someone posts a KML file of all the hospitals in Houston. When you click on them you get a little picture and bunch of reviews for each one. I don't want the pictures & reviews, all I want to see is the locations. There is simply no easy way to do this. It's not to say you couldn't edit a KML file or re-write some KML import routine to ignore the mark up, but it would take some work.
You mention layer files (*.lyr) and map files (*.mxd / *.mxt) as ESRI's attempt at this, but the purpose of these file types was never intended for 'general consumption'. Sharing data with your department perhaps, but that is about it. ESRI's real attempt at general consumption was ArcReader and it simply never took off (for a multitude of reasons). ESRI is moving to better management of style information in 9.2 (from what I hear Q4 of this year at best), but it still won't be anywhere near complete (although the new cartography tools are amazing). What most people don't understand is just how complicated things can get when you are dealing with more than a simply viewer.
By
Cam, at 11:49 AM
Phillip,
I'm not entirely opposed to storing styling information in the geodatabase; it just needs to be done in a way that discourages ad-hoc stylization.
I think that the best way to do this would be to store "style sheets" in the geodatabase that could be referenced by the source data. You could have multiple style sheets that could be quickly applied to data that implements a given data model.
What I am most concerned about is how KML (and MapInfo, and most CAD packages) allow users to treat style as a surrogate for information. If the only indication that a line is a highway is its colour, this is not good GIS. However, many packages make it much easier to do this than to stylize based on attribute values.
Trying to decipher some of these data sets after the maintainer has moved on is a real nightmare. Sometimes even the maintainer isn't even sure what the data represents if the legend gets lost.
Jason
By
Jason Birch, at 2:14 PM
Good points Jason, I agree with your standpoint on keeping some elements of symbology out of the data. Just wish there was more options for saving a default rendering.
By
pkh, at 7:27 PM
cam is close to a solution, but doesn't come right out and say it. Yes data needs to be cleanly seperated from presentation, and yes x/html+css could be a good model to follow: if you want to set default rendering, it's right there in the data file, but in the header where it's easy to strip out or change, and, you can still distribute the data+presentation as a single package and not worry about losing things (ignoring images & other media, where x/html is not a good model to follow).
By
matt, at 1:53 PM
Please include a country field in your next version
By
David, at 7:42 PM
Thank you very much for the BatchGeocode tool. I used it yesterday for a project with BC Children's Hospital, and it was incredibly useful. I'm new to Geocoding. Have you developed any new tools?
By
TRON, at 10:50 AM
Post a Comment
Links to this post:
Create a Link
<< Home