Sunday, December 16, 2007
Summarizing a bit...
Thus far the original concept that I had visualized and what I have been able to produce have not matched as closely as I had hoped. I feel that Google still has a long way to go before it can provide some of the functionality that would seem somewhat intuitive. In comparing the Google Maps product to an ESRI Geodatabase, I feel that for personal use the Google suite could far excel above the features that ESRI can offer. That's not to say that Google Maps is as powerful, but Google has an edge in offering features that people are likely to find useful.
I found it much easier to create routes (through digitizing) in the Google Maps application than what I have experienced in the past with ESRI products. I liked the way that my converted shapefiles snapped right into the Google look and feel and I felt that my map created through Google was more portable and offered a simple graphic appeal that I could relate to.
On the downside. I spent countless hours looking for simple ways to integrate dynamic RSS style feeds into my Google Maps and was unable to come up with any that worked well enough to write home about. The idea is definitely there and perhaps as Web 2.0 integration continues to develop the functionality will follow.
I am determined to continue work on the project if for nothing else than to document what products are out that they can be combined spatially and how they could possibly enhance productivity. Call me sacreligious, but the concepts that drive Google Maps and some of the like products I have discussed bring a low-level of data combination and containerization similar to that of the geodatabase. Further these products do it in such a way that the average person is likely to want to use the service.
The ability to collaborate and share data is also an extremely important selling point of the Google Maps interface. I also like that you can import existing data into your map through a relatively easy process (though I had several instances where this didn't work as intended).
My though process now is that while I like the interface that Google My Maps provides, it might be necessary to move the project in the Google Maps API so that more tools and a wider array of options is available to make the idea feasible.
I found it much easier to create routes (through digitizing) in the Google Maps application than what I have experienced in the past with ESRI products. I liked the way that my converted shapefiles snapped right into the Google look and feel and I felt that my map created through Google was more portable and offered a simple graphic appeal that I could relate to.
On the downside. I spent countless hours looking for simple ways to integrate dynamic RSS style feeds into my Google Maps and was unable to come up with any that worked well enough to write home about. The idea is definitely there and perhaps as Web 2.0 integration continues to develop the functionality will follow.
I am determined to continue work on the project if for nothing else than to document what products are out that they can be combined spatially and how they could possibly enhance productivity. Call me sacreligious, but the concepts that drive Google Maps and some of the like products I have discussed bring a low-level of data combination and containerization similar to that of the geodatabase. Further these products do it in such a way that the average person is likely to want to use the service.
The ability to collaborate and share data is also an extremely important selling point of the Google Maps interface. I also like that you can import existing data into your map through a relatively easy process (though I had several instances where this didn't work as intended).
My though process now is that while I like the interface that Google My Maps provides, it might be necessary to move the project in the Google Maps API so that more tools and a wider array of options is available to make the idea feasible.
And more problems with the Google Maps Interface
One of the things that I felt would be an integral part to my Social Locater project idea was local bus routes (especially those that I used most often). I obtained an ESRI shapefile of Asheville transit information and did a quick conversion to KML. The problem that I quickly discovered is that Google APIs have difficulty in understanding lines which overlap themselves.
After research on the issue I found that the KML work around for this problem is to was to create a series line segments for each route to prevent a single line from overlapping itself. This created another problem when attempting to upload the KML file into Google Maps in that the segments created a situation that was somewhat computationally intense and caused the interface to lock up on occasion. Additionally each segment of a line was considered a separate entity within the map and created a situation where the entire route may not be visible on the map.
The workaround for this issue was to manually edit the KML file and use the tag to make the numerous line segments appear as a single route. This worked extremely well in Google Earth, but the problem continued in Google Maps. I learned from the Google Maps API that the XML/KML parser that drives Google Maps does not understand the tag. If using the Google Maps engine with another parser this problem could be potentially avoided.
The screenshots below capture the problem. Look at the table of contents in the left of each application to see the division of routes.
After research on the issue I found that the KML work around for this problem is to was to create a series line segments for each route to prevent a single line from overlapping itself. This created another problem when attempting to upload the KML file into Google Maps in that the segments created a situation that was somewhat computationally intense and caused the interface to lock up on occasion. Additionally each segment of a line was considered a separate entity within the map and created a situation where the entire route may not be visible on the map.
The workaround for this issue was to manually edit the KML file and use the
The screenshots below capture the problem. Look at the table of contents in the left of each application to see the division of routes.
Mapfacture
One of the problems that seems to be recurrent with the Google Maps application is an inability to handle XML type feeds right out of the box. While the KML editing and sharing tools are remarkable and seem to be improving constantly, I haven't been able to integrate data with Google in a manner that wasn't extremely painful.
Mapfacture is yet another application based on the Google Maps API. Mapfacture is a quasi-social site that allows users to create and share more dynamic map information than Google want's to handle. Additionally Mapfacture will convert a dynamic XML feed (geoRSS and other formats are also supported) into a KML file that can be incorporated into your Google My Maps. Mapfacture can be used as a completely independent mapping interface in and of itself, but needs more work in my opinion. When attempting to use a KML file that originated as an ESRI shapefile as a sort of base for my Mapfacture map I was surprised to find my polygons converted to polylines. My formatting information had also mysteriously disappeared.
My goal as I progress through this project will be to utilize Mapfacture to create KMLs from any XML data that I wish to incorporate into the My Maps interface.
Mapfacture is yet another application based on the Google Maps API. Mapfacture is a quasi-social site that allows users to create and share more dynamic map information than Google want's to handle. Additionally Mapfacture will convert a dynamic XML feed (geoRSS and other formats are also supported) into a KML file that can be incorporated into your Google My Maps. Mapfacture can be used as a completely independent mapping interface in and of itself, but needs more work in my opinion. When attempting to use a KML file that originated as an ESRI shapefile as a sort of base for my Mapfacture map I was surprised to find my polygons converted to polylines. My formatting information had also mysteriously disappeared.
My goal as I progress through this project will be to utilize Mapfacture to create KMLs from any XML data that I wish to incorporate into the My Maps interface.
Saturday, December 15, 2007
Dopplr Redux
Dopplr
It seems the more I dive into the world of Web 2.0 and Social Networking the more services that I find that would provide tons of worthwhile information when integrated, but it just won't happen right out of the box. So, if your the widely traveled jet setter type or if you maintain families in multiple locations and want to clue them in as to when you'll be making your next stop, Dopplr is worth checking out. It's an incredibly easy setup and it works with OpenID (a service intended to finally provide you with one login for the gobs of websites popping up all over the place). Dopplr allows you to easily create a publicly shared travel log of where you'll be going and when. It even throws out an RSS feed. Unfortunately Dopplr is relatively new, and it only goes as far as cities and states when you add an event (and the day not the hour). If you were planning on trying to log your Christmas shopping, it doesn't appear that it's that refined yet. The idea is terrific because it's slightly more map focused than the location feature on Google Calendar and it requires you to validate the location before saving it. Hopefully this site will see some further development in the near future.
Platialthepeoplesatlas
So it turns out that there is a social networking site that revolves around maps. Now granted some of the features on Platial took a huge hit with Google's recent move to make maps collaborative, but it's still an interesting concept. Platial integrates well with some of the existing social networking sites and blogs (including Facebook and Blogger). Unfortunately there is not a method for uploading existing KML into the Platial interface and it really only seems to want to deal with points (as opposed to lines and polygons).
One cool thing about Platial is the ability to integrate the application with Facebook to map photos on your Facebook account. I understand that photo-mapping has long existed with Flickr, but Facebook makes it so easy to run through the photos on your friends accounts and steal them for your own album. The map application can easily be added to your Facebook mainpage. Perhaps not the most useful feature of all time, but it is gives you an even broader ability to show off all the cool places that you've been.
To go a step further, Platial will integrate with Facebook to the extent that you can map the location of all your friends on Facebook... this application has an even greater value if your trying to find a couch to crash on during your next trip.
One cool thing about Platial is the ability to integrate the application with Facebook to map photos on your Facebook account. I understand that photo-mapping has long existed with Flickr, but Facebook makes it so easy to run through the photos on your friends accounts and steal them for your own album. The map application can easily be added to your Facebook mainpage. Perhaps not the most useful feature of all time, but it is gives you an even broader ability to show off all the cool places that you've been.
To go a step further, Platial will integrate with Facebook to the extent that you can map the location of all your friends on Facebook... this application has an even greater value if your trying to find a couch to crash on during your next trip.
Subscribe to:
Posts (Atom)