Finally done with the work and presentations of user conference this year, and I’m very glad to hear some positive feedback of my demo theatre presentation (“Leverage OGC capabilities of ArcGIS Server using Open Source GIS technology”) and technical workshop (“Leverage OGC capabilities of ArcGIS Server”) from users and colleagues. Now it’s time for a little break, then keep working and also look forward to the FOSS4G conference in Denver.
Sunday, July 17, 2011
Monday, June 20, 2011
Google Earth Builder is really coming
Just as many of others, I heard the announcement of Google Earth Builder (GEB) and also watched the informative GEB webinar on Directions Magazine very recently, so Google’s Enterprise Cloud GIS is really coming (Q3, 2011 as mentioned in the webinar).
Here are some of the the highlights I perceived from the the online webinar:
1. Google Earth Builder will have similar functionalities as other existing Cloud GIS solutions, e.g. ArcGIS.com, GeoCommons, SimpleGeo, GloudGIS etc. So basically user can upload and manage their own dataset, style the dataset and mash them up with Google’s basemap layers as well as dataset shared by others, and finally share your mash up maps with others. But it doesn’t mean Google Earth Builder is just another Cloud GIS service at all, a few thing I notice will potential make it outstand.
Supports both vector and raster dataset in their native projections;
Leverage the base map layers and data from Google Maps and Google Earth API;
Google’s superior and reliable cloud infrastructure;
Same user experience of authentication and search as other Google products and services.
2. Support for OGC output
KML is obviously supported and it’s now an OGC standard, but that is just a special case. Now WMS and WMTS are also mentioned to be supported soon which will make it possible for much more non-Google to consume data and map from Google Earth Builder. One thing great to have though is to allow users to upload/import data from various types of OGC services e.g. Web Coverage Service and Web Feature Service.
Things that are missing or unknown to me from the webinar though are:
1. Unknown about Metadata
OGC/ISO 19115/19139 mentioned in Q&A section but I don’t think it will ever be supported.
2. You won’t be able to directly access the data from Google Maps and Google Earth
Finally when Google comes into an area, there is always question regarding whether Google will killer everybody in the same area or not. I don’t know about that but I feel if you’re doing the same thing as Google does, then you’d better be more creative and do it a little better.
Monday, June 13, 2011
Cloud GIS, it’s all about sharing the map
Google Maps
View Trip to Washington D.C. in a larger map
ArcGIS.com
View Larger Map
Geocommons
GISCloud
Wednesday, June 1, 2011
Mashup WMS in GeoCommons
WMS, whether dying or not, still has its place in the world of GIS. Given that many organizations have published their spatial data through WMS, it is a very important data source especially in the era of cloud GIS today. GeoCommon’s is one of the first cloud GIS platform that allows users to add WMS as one type of data sources which can mashup on the base map. Follow the blog post “Adding WMS and Tiles in GeoCommons and GeoIQ” I gave it a try using one public WMS called “StatesCitiesRivers_USA” from ArcGIS Online sample server and another from OSGeo.
After log in, select “Make a Map” and pick whatever base map as you like, which in my case is OSM.
Click “+Add” at top-right corner, and select “Upload” tab and “Add a URL Link” tab, and finally select “Web Map Service” in the format dropdown list, and type in the url to WMS’s capabilities files (the url must point to the capabilities XML file either static or dynamic).
Since ArcGIS Server supports WMS 1.3.0, so I tried this highest version of capabilities file, but unfortunate it doesn’t display the WMS layers on top of base layer although it is able to get the list of layers from that WMS.
Next I switched to version 1.1.1, which actually worked for me.
For the WMS overlay in GeoCommons, users are able to turn and off individual or all layers, and also change the opacity of the whole WMS overlay which obviously happens at client side (because WMS itself doesn’t support opacity). But none of other style or filter options are available to WMS layer. What is also observed is that WMS map is requested from server as multiple tiles instead of a single map image, which may be because GeoCommons platform currently doesn’t support any dynamic mapping service like WMS. Unless those tiles from WMS are cached at client-side, it’s not quite efficient.
One big problem I see, which is also quite obvious from the screenshot , is that GeoCommons requests WMS map in EPSG:4326 even though the base map is Web Mercator (EPSG:3857 or EPSG":900913 for most open source GIS community). This is caused by the fact that the public ArcGIS Server WMS service doesn’t list EPSG:900913 as one of the supported SRS.
I then added the public WMS from OSGeo, which supports EPSG:900913, which is side proof of what happened to ArcGIS Online Sample Server.
Since ArcGIS Server WMS doesn’t support EPSG:900913 (not in the way when it’s named as 900913) at this point, the only workaround is to choose one of the base map marked as (4326).
Now it overlays perfectly.
Conclusion
There are still a lot of data source published as WMS, and in my opinion there will only be more in the near future. So supporting WMS will give huge benefit to today’s Cloud GIS providers. It will be really nice to see similar WMS support in other major Cloud GIS player like ArcGIS.com, Google Maps and so on.
Tuesday, May 31, 2011
World-wide routing, MapQuest + OpenStreetMap
MapQuest was THE first and only web routing service I relied on. But once up on a time, I almost forgot its existence because of Google Maps, Yahoo, and even others. Recently MapQuest seems to be coming back really strong especially with its Open Initiative and integration with OpenStreetMap data. One of the most amazing things I have seen is this Dublin-to-Shanghai world-wide routing:
Although I don’t think it has much practical use to most people except for professional backpacker traveler, it is still amazing and seriously no one else can do it.
Friday, May 27, 2011
Choosing China’s location check-in platform
Like many other Chinese people (I am not talking about the those who were born or grown up here in States) here in Unite States, I’m facing a dilemma when choosing a location check-in game service to share location, pictures and tips with my friends. There seems to be quite a lot options. We have the popular Foursquares, Gowalla, and Facebook, and Google Latitude which jumped in recently, plus Yelp, Booyah, MyTown, and the list can go on and on. However, the problem is that many of my friends are in mainland China who want to see where I have been to and how I felt about those places, but they probably don’t want to install any of those clients on their mobile devices (actually even if they do, they can’t because many social networks applications are blocked in China). For the same reason I can’t see their move and tips either because obviously they don’t share it through any of the location check-in platform above.
The only workaround seems to be choosing one of China’s location check-in platform. Fortunately there is also a long list of those to choose, but none of them made a perfect solution. My top candidate list includes: Jiepang (街旁), Sina (微领地), Sifang (四方), and kaikai (开开). Which one to choose is certainly subjective to each individual person, but here is a list of things (ordered by priority) that I will base my choice on.
1. Size and accuracy of the existing foreign (U.S in this case) venue database;
2. Share check-in with friends on other check-in platform or social networks (Facebooks, Foursquares, Kaixin001, Sina Weibo etc);
3. Being able to add new venue.
To me both #1 and #2 are must for a check-in platform be to usable, and #3 is nice to have but also important.
Venue database
This almost dominates my decision. Sina has its decisive advantage over others in its complete and accurate U.S venue database, which even overcomes its shortage in all other aspects. Just as an example, I live in Rancho Cucamonga, a small size city in southern California, which is not famous and probably unknown to most people in China. No one would expect a Chinese location check-in service to have much venues in this area in its databases. But I was really surprised the first time when I checked in at home, Sina accurately lists closest everything nearby which include a KFC, a RiteAid pharmacy, a Ralphs grocery store, a US Bank (a small local bank I’ve been to), …, and a lot of other small places. None of others have a similar or even close size and accuracy of the venue database as Sina does.
Sharing check-in with others
This is the second most important thing because first I obviously want my check-in to be shared with my friends in other check-in platforms or social networks, and second I obviously don’t want to repeat my check-in on every check-in platform either for my friends in U.S or in China. This seems to be possible in two aspects: either (a) I check-in once on one of them (e.g. Sina) and my check-in will spread out through synchronization to Facebook, Foursquare, Twitter, Kaixin (开心网), Weibo (新浪微博) an so on; or (b) I check in through a 3rd party proxy app which takes my check in and broadcast to all my location check in services. Option #b is only possible when everyone has a free open API for venues and check-in which is NOT true for any of the location check-in platform in China, so it is ruled out. Option a is possible in one direction (China check-in spread to U.S platform), and almost all Chinese location check-in services provide you such capability except for Sina.
Adding new venues
This is also very important to both users and location check-in service providers. I am true believer of the fact that a real complete and accurate venue database can only be evolved from volunteered geographic information from those locals who know where they live well. Unfortunately Sina again doesn’t support this feature while all other check-in platforms supports it which is quite disappointing to me. As latest version of Sina (微领地) goes, users are allowed to create new venue and submit to service provide for reviewing and I guess if it is approved then it will be added into existing venue database. This is a big leap to me and makes Sina (微领地) outstands other options in my particular use case.
Conclusion
No one wins because neither Sina or any other candidates has both #1 and #2, but it provokes some interesting thinking on the current situation in the location check-in services market in China. Sina is close because it is the only one who is either interested in or can afford building a relatively complete and accurate foreign venue database. It is also easy to prove that those venues in sina’s database are not coming from any major open free sources (e.g. OpenStreetMap or Foursquare API etc.) So it’s probably from a commercial provider, which in turns logically explains why there are restrictions on adding new venues or modifying existing ones, and why check-in on vld.sina cannot be spread out to other platforms. Other location check-in platforms in China are still missing a solid venue database to start with, and importing from OpenStreetMap database or relying on the venue API from a popular U.S provider like Foursquares or so seem to be possible solutions.
Wednesday, February 9, 2011
Thoughts on OSM and the Bing automatic vector detect service
In Mike Dobson’s recent blog post OSM vs. the Mechanical Turk – A New Option For Mappers?, he brought a point, which I think is more than reasonable:
“…I guess that when I thought about the term Volunteered Geographic Information, I made the mental leap that these volunteers were providing content in the form of spatial information reflecting the geographic areas in which they lived or with which they were more than casually familiar. It has now occurred to me that there may not always be a direct beneficial relationship between geographical knowledge and Volunteered Geographic Information…”
And then he did an analogous comparison between OSM and Mechanical Turk, in which he points out that:
“…If the majority of OSM contributors to the UK database are spending their time digitizing imagery for the UK portion of the OSM database, as opposed to contributing GPS traces and attributes from paths along which they have traveled or know something about, how likely is it that the OSM effort in the UK benefits from local knowledge to the same extent that it benefits from “free” digitizing?…”
to him, the way how some people contribute to OSM database is similar to a modern version of Mechanical Turk. It looks like the data are contributed with valuable local geographical knowledge, but it is only artificially generated from aerial imagery.
Now this reminds me of another exciting post I came across from Bing, in which Steve Coast announced the experimental service from Bing which can automatically derive street vector data from Bing aerial imagery. I am pretty sure it will boost the popularity of OSM in short term, but in the long run is it really helping?