Conversation with Google Translate for Android

 

Mobile technology and the web have made it easier for people around the world to access information and communicate with each other. But there’s still a daunting obstacle: the language barrier. We’re trying to knock down that barrier so everyone can communicate and connect more easily.

Earlier this year, we launched an update to Google Translate for Android with an experimental feature called Conversation Mode, which enables you to you translate speech back and forth between languages. We began with just English and Spanish, but today we’re expanding to 14 languages, adding Brazilian Portuguese, Czech, Dutch, French, German, Italian, Japanese, Korean, Mandarin Chinese, Polish, Russian and Turkish.

To use Conversation Mode, speak into your phone’s microphone, and the Translate app will translate what you’ve said and read the translation out loud. The person you’re speaking with can then reply in their language, and Conversation Mode will translate what they said and read it back to you.

This technology is still in alpha, so factors like background noise and regional accents may affect accuracy. But since it depends on examples to learn, the quality will improve as people use it more. We wanted to get this early version out to help start the conversation no matter where you are in the world.

We’ve also added some other features to make it easier to speak and read as you translate. For example, if you wanted to say “Where is the train?” but Google Translate recognizes your speech as “Where is the rain?”, you can now correct the text before you translate it. You can also add unrecognized words to your personal dictionary.

When viewing written translation results, you can tap the magnifying glass icon to view the translated text in full screen mode so you can easily show it to someone nearby, or just pinch to zoom in for a close-up view.

 

Tap the magnifying glass icon to view translations full screen.

Finally, we’ve also optimized the app for larger screens like your Android tablet.

While we work to expand full Conversation Mode to even more languages, Google Translate for Android still supports text translation among 63 languages, voice input in 17 of those languages, and text-to-speech in 24 of them.

Download the Google Translate app in Android Market — it’s available for tablets and mobile phones running Android 2.2 and up.

Google Earth: City names in your preferred language

We love to give you options on how to view information in Google Earth, but we also want to make sure we’re organizing that information in a way that is useful and easy to read. We realize that a city may be referenced in different ways, in different languages. Presenting all of these names on the map in a single view can sometimes make the map harder to read, not to mention, may even detract users from other, useful information. In the interest of providing the smoothest browsing experience possible, we’ve updated Google Earth so that each city has just one label in a user’s default language.
 


 

These settings are flexible. If you would like to change the way in which cities are displayed, just follow these instructions to change your default language. If you prefer to see cities in two languages, turn on the ‘Local Place Names’ layer under the ‘More’ folder. This way, if you fly to the capital of Japan, for example, you’ll see both “Tokyo” and “東京“.

Click on “Local Place Names” to turn on a second, local name for each city.

And remember, if you think that there’s a better name for a city in your language, we’d love to hear your feedback via the “Report a Problem” link in the help center.

Tile cutting Raster Imagery and geo referencing

Just as there are many different formats in which vector spatial data may be represented: Well-Known Text (WKT), Well-Known Binary (WKB), Geography Markup Language (GML), and Keyhole Markup Lanuage (KML), to name but a few – so too are there many different formats of raster spatial data.  In fact, almost any image format can be used to encode raster spatial data – since each pixel in an image naturally corresponds to an X,Y location in a raster grid. Any regular BMP, GIF, PNG, JPG, or TIFF image file can therefore be used to store spatial data, so long as the real-world coordinates corresponding to the pixels in each corner of the image are known (and thus the coordinates of each other pixel in the image can be determined). The process of assigning coordinates from a spatial reference system to a raster image is known as geo-referencing.

Some dedicated spatial raster formats, such as GeoTIFF, encode coordinate metadata along with the image data in a single file. However, the raster images used by Open Street Maps, Bing Maps, and Google Maps don’t use GeoTIFFs – they are formed from a series of 256px x 256px tiles saved as regular PNG and JPG images. The metadata describing the geographic extent of each tile is encoded entirely in the filename, which, in Bing Maps, uses the quadkey numbering system as described here.


For example, the following tile shows the Bing Maps road map style tile for quadkey 031311, retrieved from http://ecn.t1.tiles.virtualearth.net/tiles/r031311.png?g=685&mkt=en-us

Knowing nothing but the quadkey number, 031311, and the formulas in the MSDN article linked above, I can calculate that the exact geographic extent of features shown on this tile lie from longitude of –5.625 to 0, and latitude between 52.4827802220782 and 55.7765730186677. Like all Bing Maps tiles, they are projected using the Spherical Mercator projection.

Here’s another tile – this time 120200223:

Once again, I can immediately determine from the quadkey that the extent of this tile has longitude ranging from 0.703125 to 1.40625 and latitude from 52.4827802220782 to 52.9089020477703.

The quadkey system is quite beautiful in its simplicity and efficiency. There are, of course, some limitations with this sort of tiling system – all raster data must be represented using the same projection, and every tile must be regularly-sized, for example, but these limitations are offset by the ease with which it’s possible to place any tile at any zoom level at the correct position on the map with minimum amount of coding.

Preparing Custom Tiles

To get your own raster data into Bing Maps (such as a digitized map or floor plan), you need to prepare a series of individual quadkey tile images following the structure outlined above. Applications such as Safe FME and Microsoft MapCruncher provide the ability to prepare raster images for use as background tile layers in Bing Maps (or Google Maps), or you can write your own script to do so. The process is generally known as “tile-cutting”, and the steps are described below:

1.) First, start out with a source image. Here’s John Snow’s famous map of the Cholera outbreak that occurred in Broad Street in London, 1854:

2.) Georeference the image, by assigning coordinates to corresponding pixel positions in the image. If the image is not already in the correct projection, it might need to be warped to bring features into line with the Mercator projection as used by Bing Maps. The image below shows the interface provided by Mapcruncher for placing reference points in the source image (left hand pane) and Bing Maps (right hand pane):

3.) The geo-referenced, transformed image must then be cut into a series of 256px x 256px tiles at different levels of magnification, numbered according to quadkey. For example, the tile below shows a single tile from zoom level 16 of the above image (quadkey 0313131311122330):

4.) Finally, create a tilelayer that references the set of quadkey tile images. Assuming that the tiles are all saved in the same directory, this is as simple as adding the following lines of javascript. the Bing Maps v7 control will expand the {quadkey} placeholder to the appropriate quadkey filename for each tile request:

The result

Once the tilelayer is added to the map, whenever a part of that tilelayer comes into view Bing Maps will automatically request and stitch together the appropriate tile images and overlay them at the appropriate position on the map.

The screenshot below shows the result of overlaying Jon Snow’s Cholera map onto a modern day map of London using Bing Maps’ default road map style using the steps described above. Notice how well the roads that cross the edges of the tile layer line up – John Snow was not only the father of epidemiology, but also a highly talented cartographer:

The New GeoServer 2.1

GeoServer 2.1 (Major Update)

“GeoServer is a Java-based software server that allows users to view and edit geospatial data. Using open standards set forth by the Open Geospatial Consortium (OGC), GeoServer allows for great flexibility in map creation and data sharing.”


18 months in the making:
WMS Cascading

New Features

Something many users have asked for since the very addition of WMS support is cascading, the ability of GeoServer to proxy for another remote WMS server (be it GeoServer, MapServer, or ArcGIS). This feature has many uses, such as pulling in a remote base layer and overlaying local vector data onto it or securing a locally unsecured map server. Special thanks to the University of Perugia for sponsoring this feature.

Virtual Services

Anyone who has published a large number of layers or feature types with GeoServer has probably at some point been annoyed by the fact that every single layer is published by a single global service. WMS has the ability to group and nest layers but WFS and WCS have no such equivalent. Thanks to virtual services, one can create multiple service endpoints within a single GeoServer instance. Special thanks to Landgate for funding this work.

Layers from SQL

GeoServer has always been good at publishing a flat database table but users often need to do more—such as pre-filter the data in a table, join two tables together, or generate column values on the fly with a function. Before this feature, the recommendation was to create a view, yet views can be a maintenance burden and are at times problematic.

Now one can create a layer directly from an SQL query and query definitions can be parameterized to create dynamic queries on the fly. These parameters can be restricted with regular expressions to prevent an SQL injection security hole.

Special thanks to Andrea Aime for spending much of his personal time on this one and to OBIS for providing the funding for the parametric component of the work.

Web Processing Service (WPS)

With 2.1 and the arrival of WPS we welcome a new OGC service into GeoServer. The Web Processing Service is an OGC service for performing geospatial analysis functions over the web. The specification is extensible in nature and allows for simple processes ranging from buffering a geometry to more complex processes such as image processing.

Historically, GeoServer has been focused on data delivery and did not provide tools for performing analysis on spatial data. WPS fills that gap, making GeoServer a more compete solution for geospatial web services.

Thanks to Refractions Research for the initial contribution of the WPS module and to Andrea once again for taking personal time to bring WPS support to its current state.

Unit of Measure

Support for units in SLD allows one to specify values in measurements other than pixels such as feet or meters. This adds a very powerful capability to SLD that may alleviate the need for multiple scale-dependent rendering rules and may greatly simplify complex SLD documents.

Special thanks to Milton Jonathan for the initial GeoTools work to make unit of measure support possible and to Andrea for working with Milton to improve the initial patch. Note that this feature has also been backported to the stable 2.0.x branch thanks to support from SWECO and Malmö City of Sweden.

DPI Scaling

GeoServer renders images at a resolution of 90 DPI by default. While this is acceptable for most standard screen resolutions, it is unacceptable for higher-resolution printed materials. Now it is possible to supply a format option to a WMS request to control the DPI setting on the fly.

Special thanks again to SWECO and Malmö City of Sweden for sponsoring this work. Note also that this feature has also been backported to the 2.0.x branch.

Graphical File/Directory Chooser

Ever found it difficult to remember the full path when loading a shapefile or GeoTIFF? This new improvement brings an easy graphical file and directory selection tool for browsing the file system on which GeoServer resides. This is definitely a great enhancement to make GeoServer even easier to configure.

Core improvements to support a database-backed catalog

GeoServer’s core catalog interfaces received some tweaks to more easily support different backend storage formats. The current in-memory implementation has a number of drawbacks—the most notable being that it is memory-bound, meaning it cannot scale to accomodate large numbers of layers. Support for specific new storage formats is still only available as a community module but these core improvements make it possible to more easily swap between different backends.

Font Improvements

Adding new fonts to maps should now be much easier, as one can drop font files directly into the GeoServer data directory and have them be recognized by GeoServer. The admin interface will list all fonts that are currently available, including those made available by the Java Virtual Machine.

Upgrade to Spring Security 2.0.6

GeoServer has always had Acegi Security at its core but since that library was absorbed by the Spring community it has been improved and upgraded into Spring Security, the official security module of the Spring portfolio. This brings a number of new security protocols to GeoServer, including OpenID and Windows NTLM. With even more powerful options, it should now be easier to customize the security setup.

WCS Limits

While WFS and WMS have both had the ability to limit what a user can request, now similar controls are in place for WCS calls as well. Thanks to MassGIS for funding this improvement.

WMS 1.3.0

WMS 1.3.0 is the newest version of the Web Map Service protocol. Special thanks to Ordnance Survey, Britain’s national mapping agency, for providing OpenGeo with funding to complete its implementation in GeoServer. With WMS 1.3 mandated by the INSPIRE Initiative, Ordnance Survey opted to fund the GeoServer project so that other organizations in the UK and the rest of Europe could meet their INSPIRE requirements and everyone across the globe could benefit.

SLD 1.1 / SE 1.1 enhancements

Though not every new option is fully-supported, it is now possible to use most SE 1.1 documents in GeoServer. User feedback on which new options should be supported first is greatly appreciated. Also funded by Ordnance Survey is a community module to implement the WMS extensions for INSPIRE View Service compliance—namely the language parameter and several extended capabilities fields.

GeoWebCache Integration

GeoWebCache integration allows clients to enjoy the benefits of tile caching through the regular GeoServer WMS endpoint. This enables GeoWebCache to transparently proxy for the GeoServer WMS without the need for a separate service endpoint. Taking advantage of the recently-added disk quota functionality, GeoWebCache now provides the ability to set limits on the amount of disk space used for storing tiles, allowing users to control and limit the size of the tile cache on disk. Big thanks to Gabriel Roldán of OpenGeo for the great GeoWebCache improvements.

Improvements to RESTConfig

This release also brings some improvements to RESTConfig, which is now shipped with GeoServer by default. Improvements to the API include a file upload operation that now allows for uploading files into an existing data store. This addition allows users to upload a shapefile and have it automatically converted into a PostGIS database and published as a PostGIS layer rather than as a Shapefile layer. The API also supports recursive DELETE operations, making it more convenient to remove resources that contain other resources such as stores or workspaces. Thanks to David Winslow and Justin Deoliveira of OpenGeo for these improvements.

Improved Raster Reprojection Performance

Thanks to some great work from GeoSolutions, raster reprojection performance has been significantly improved by using linear appoximations of transformation functions.

WCS Request Builder

Thanks to Andrea Aime, there is now a Web Coverage Service request builder for graphically building WCS requests to test a coverage service. As clients for WCS have always been sparse, this tool goes a long way towards making the service more usable.

Run multiple GeoServer instances from a single data directory

There now exists a new parameter that will once again allow multiple GeoServer instances to run from a single data directory. This parameter, named “GWC_DISKQUOTA_DISABLED”, will disable the GeoWebCache disk quota module and prevent it from maintaining a lock on the data directory.

Source:
http://blog.geoserver.org/2011/05/12/geoserver-2-1/

The Globalization of Social Search

In 2009 we first introduced Social Search on google.com as an experimental feature designed to help you find more relevant information from your friends and the people you care about. Since then we’ve been making steady improvements to connect you with more people and more relevant web results. Today, we’re bringing Social Search to more users around the globe.

Just like on google.com, social search results in other languages and on other domains are mixed throughout the Google results page based on their relevance. For example, if you’re looking for information about low-light photography and your friend Marcin has written a blog post about it, that post may show up higher in your results with a clear annotation and picture of Marcin:

Social search results can rank anywhere on the page, and you’ll see who shared the result in the annotation underneath.

 


 
Social Search can help you find pages your friends have created, and it can also help you find links your contacts have shared on Twitter and other sites. If someone you’re connected to has publicly shared a link, we may show that link in your results with a clear annotation. So, if you’re looking for information about modern cooking and your colleague Adam shared a link about Modernist Cuisine, you’ll see an annotation and picture of Adam under the result. That way when you see Adam in the office, you’ll know he might be a good person to ask about his favorite modern cooking techniques.

Social Search includes links people share on Twitter and other services.

So how does this all work? Social search results are only visible to you and only appear when you choose to log in to your Google Account. If you’re signed in, Google makes a best guess about whose public content you may want to see in your results, including people from your Google chat buddy list, your Google Contacts, the people you’re following in Google Reader and Buzz, and the networks you’ve linked from your Google profile or Google Account. For public networks like Twitter, Google finds your friends and sees who they’re publicly connected to as well. You can see a complete list of the people included in your social search results in your personal Google Dashboard (this display is private). For an overview of Google Social Search, check out the explanatory video:

Social Search is rolling out globally in 19 languages and should be available in the coming week, with more languages on the way. People around the world will find similar types of social results as people in the U.S., and we plan to introduce the +1 feature as soon as we can. With these changes, we want to help you find the most relevant information from the people who matter to you.