★ 

The Google Maps JavaScript API v3 introduced a new format for geocoding responses that offers a number of improvements over the format used in the v2 API: A flatter response format for address components that is easier to parse The ability to tag an address component with multiple typesBoth full names and abbreviations for countries and states Differentiation between rooftop and interpolated geocoder results Both the bounding box and recommended viewport for each resultWe're happy to now announce a new Geocoding Web Service that adopts these improvements.

The Geocoding Web Service is intended to enable precaching of geocoder results that you know your application will need in the future. For example, if your application displays property listings, you can geocode the address of each property, cache the results on your server, and serve these locations to your API application. This ensures that your application does not need to geocode the address of a property every time it is viewed by a user. However we do ask that you regularly refresh your cache of geocoder results.

Note however that it is a requirement of the Maps API Terms of Service that you use the Geocoding Web Service in conjunction with a Google map. This means that when it comes time to use cached geocoder results in an application, the application must display the results or any data derived from them on a map generated using one of the Google Maps APIs or Google Earth API.

If your application needs to geocode arbitrary addresses that are entered by your users while they wait we recommend that you use the classes in the appropriate client API. This ensures that the requests your application generates reach Google directly from your users, which will improve the performance of your application and ensure it is resilient to unexpected spikes in use. For more details, I highly recommend this excellent blog post by our very own Mano Marks.

In addition to an improved response format you will notice some other changes in the new Geocoding Web Service. Requests no longer require a Maps API key, and Maps API Premier customers must sign their requests. In addition CSV output is not supported because we found that the minimal amount of data in a CSV response makes it is difficult to identify false positive results.

2,500 requests may be sent to the Geocoding Web Service per day from a single IP address. This is independent of any geocoding activity generated by applications using one of the client Maps APIs for geocoding. Maps API Premier quotas remain unchanged.

A forward geocoding request to the new Geocoding Web Service with XML output looks like:

http://maps.google.com/maps/api/geocode/xml?address=sydney&sensor=false

A reverse geocoding request with JSON output looks like:

http://maps.google.com/maps/api/geocode/json?latlng=-33.873038,151.20563&sensor=false

Check out the Geocoding Web Service documentation for more details on the options available for language and biasing of results.

In conjunction with the launch of the new Geocoding Web Service we are also announcing the deprecation of the current service, now retroactively named the "Geocoding V2 Web Service". Existing applications using the V2 Web Service need not worry though. Deprecation indicates that we no longer intend to pursue any further feature development, but we will continue to maintain and support the service in accordance with the deprecation policy set out in the Maps API Terms of Service.

We hope that you find the new Geocoding Web Service easier to use and useful. As always we encourage you to check out the Google Maps API Google Group if you have any questions or comments relating to the APIs. We look forward to adding more great features to the Geocoding Web Service in future.

Posted by Thor Mitchell, Maps API Product Manager

BitTorrent - Dropbox - Transmission - File sharing - ΜTorrent

http://www.engadget.com/2010/03/09/s...n-playstation/

// if this was successful, get the latitude and longitude function(position){ var lat = position.coords.latitude; var lon = position.coords.longitude; }, // if there was an error function(error){ alert('ouch'); }); }Compare the IP and W3C solutions side by side. As you can see, there can be quite a difference in measuring the visitor’s location. The extent of the difference is shown in the following demo:Converting Latitude And Longitude Back Into A NameHaving more information is nice, but we have lost the name of the city and all the other nice data that came with the Maxmind database. Because the location has changed, we cannot just grab that old data; we have to find a way to convert latitude and longitude coordinates into a name. This process is called “reverse geo-coding,” and several services on the Web allow you to do it. Probably the most well-known is the geo-names Web service, but it has a few issues. For starters, the results are very US-centric.One freely available but lesser-known reverse geo-coder that works worldwide comes from a surprising source: Flickr. The flickr.places.findByLatLon service returns a location from a latitude and longitude coordinates. You can try it out in the app explorer, but by far the easiest way to use it is by using the Yahoo Query Language (or YQL). YQL deserves its own article, but let’s just say that, instead of having to authenticate with the Flickr API and read the docs, reverse geo-coding becomes as easy as this:select * from flickr.places where lat=37.416115 and lon=-122.0245671Using the YQL Web service, you can get the result back as XML or JSON. So, to use the service in JavaScript, all you need is the following:<script type="text/javascript" charset="utf-8"> function getPlaceFromFlickr(lat,lon,callback){ // the YQL statement var yql = 'select * from flickr.places where lat='+lat+' and lon='+lon;

// assembling the YQL webservice API var url = 'http://query.yahooapis.com/v1/public/yql?q='+ encodeURIComponent(yql)+'&format=json&diagnostics='+ 'false&callback='+callback;

// create a new script node and add it to the document var s = document.createElement('script'); s.setAttribute('src',url); document.getElementsByTagName('head')[0].appendChild(s); };

// callback in case there is a place found function output(o){ if(typeof(o.query.results.places.place) != 'undefined'){ alert(o.query.results.places.place.name); } }

// call the function with my current lat/lon getPlaceFromFlickr(37.416115,-122.02456,'output'); </script>Combine that with the other services, and we get a more detailed result and can put a name to the coordinates:The Trouble With Latitude And LongitudeWhile latitude and longitude coordinates are a good way to describe a location on Earth, it is also ambiguous. The coordinates could represent either the centre of a city or a point of interest (such as a museum or a pub) in that spot.WOEID to the RescueTo work around the problem, Yahoo and Flickr (and soon will Twitter) support another way to pinpoint a location. The Where On Earth Identifier (or WOEID) is a more granular way to describe locations on Earth. Because Flickr supports it, we can easily get get photos from a particular area:select * from flickr.photos.search where woe_id in ( select place.woeid from flickr.places where lat=37.416115 and lon=-122.02456 )Using this and a few lines of JavaScript, showing geo-located photos is pretty easy:This has also been wrapped in a simple-to-use YQL solution. The following code will display 10 photos of Paris:<script> function photos(o){ var container = document.getElementById('photos'); container[removed] = o.results; } </script> <script src="http://query.yahooapis.com/v1/public/yql?q= select * from flickr.photolist where location="paris,fr " and text="" and amount=10&format=xml& env=store://datatables.org/alltableswithkeys&callback=photos">You can also play with this in the YQL console.Why Not Search For The Location’s Name?The main question about implementations such as the one above is why couldn’t we just do a search on Flickr for the city, instead of doing all the complex geo-lookups? The reason is false positives. Take Paris, for example: if you want to show photos of Paris on a travel website, you don’t want Paris Hilton to show up in there. Same goes for Jack London. You may also want to show photos of London, England, not London, Ontario. Geographic data is full of these kinds of gotchas, and the term for finding the right one is “disambiguation.” See the Wikipedia article on “Victoria” to see just how many geographical contexts this term can have.Turning Text Into Geo-DataFinding a visitor’s geographic location is all well and good, but it doesn’t mean much if you can’t link it to information for that area. This is where it gets tricky. For Flickr (and soon Twitter), this is easy, because both services are able to attach geographical locations to the content you put in them. This is not so for most of the information on the Web, though, and this is when we resort to clever algorithms, machine-learning, pattern-matching and all the other think-tank stuff that computers and the scientists in front of them do.Say you want to identify the geographical locations that a particular text or Web page talks about. Yahoo offers a service for that called Placemaker, and it is pretty easy to use. You need to get a developer key and send this as appid, send a text as documentContent, define the type of the text as documentType and define the type of data you want back as outputType. All of this needs to be sent as a POST to http://wherein.yahooapis.com/v1/document:<form action="http://wherein.yahooapis.com/v1/document" method="post"> <textarea id="text" name="documentContent">Hi there, I am Chris. I live in London, I am currently in Sunnyvale and will soon be in Atlanta and Las Vegas.</textarea> <div><input type="submit" name="sub" value="get locations"></div> <input type="hidden" name="appid" value="{YOUR_APP_ID}"> <input type="hidden" name="documentType" value="text/plain"> <input type="hidden" name="outputType" value="xml"> </form>You can try this out yourself. Using PHP to call the API instead of a simple form, you can even format the output nicely. See it in action here:While developers who have played around with Web services won’t find Placemaker hard to use, the service can be daunting for the average developer. That is why I built GeoMaker some time ago. GeoMaker allows you to enter a text or URL, select the locations you want to include in the final outcome, and get the locations either as a map to copy and paste or as micro-formats.However, because there is also a YQL solution for using PlaceMaker in JavaScript, we can do the same with a few lines of client-side code to enhance an HTML document. Check out the following example:To use this, you need three things: a text with geographical locations in them in an element with an ID, a Google Maps API key (which you can get here) and the following few lines of code:<script src="http://github.com/codepo8/geotoys/raw/master/addmap.js"></script> <script> addmap.config.mapkey = 'COPY YOUR API KEY HERE'; addmap.analyse('content'); </script>This makes it incredibly easy to give your visitors a sense of what part of the world a text is related to.Adding Maps To Your DocumentsOnline maps have been around for a while now (and Google Maps was instrumental in the rise of AJAX), and many providers out there allow you to add maps to your documents. Google is probably the leader, but Yahoo also has maps, as does Microsoft and many more. There is even a fully open map service called Open Street Maps, which has been instrumental in the recent rescue efforts in Haiti.If you want interactive maps, probably the easiest thing to use is Mapstraction, which is a JavaScript library that does away with the discrepancies between the various map providers and gives you a single interface for all of them. 24ways published a good introduction to it three years ago.Probably the simplest way to show a map that supports markers and paths in your document without having to dive into JavaScript is the Google static maps API. It creates maps as images, and all you need to do is provide the map information in the src URI of the image. For example, in the script example above, this would be:http://maps.google.com/maps/api/staticmap? sensor=false &size=200x200 &maptype=roadmap &key=YOUR_MAP_KEY &markers=color:blue|label:1|37.4447,-122.161 &markers=color:blue|label:2|37.3385,-121.886 &markers=color:blue|label:3|37.3716,-122.038 &markers=color:blue|label:4|37.7792,-122.42You can define the size and type of the map. If all you provide is the location of markers, the API will automatically find the right zoom level and area to ensure that all markers are visible. Google’s website even offers a detailed tool to create static maps, including markers and paths.Geo Is A Space To WatchI hope this has given you some insight into all of the things you can do to bring the earth to your product and to put your product on the map. Geo-location and geo-aware services are already huge, and they’ll be even more important this year. There will be more services—some mobile providers are ready to roll out new hardware and software—and now you can be a part of it.What the geo-world needs now is a designer’s eye, and this is where you can help the geo-geeks create apps that matter, that look great and that make a difference in our visitors’ lives. For inspiration, check out Mapumental, which allows you to pinpoint a place to live in London, or see how Google Earth and some 3-D Objects allow you to race a milk truck on real map data.(al)© Christian Heilmann for Smashing Magazine, 2010. | Permalink | 38 comments | Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine Post tags: javascript

I’ve noticed a new trend in Silicon Valley. More and more startups are beginning life as distributed companies, and investors and partners are starting to accept it as normal. Our company Automattic is distributed, and I’m ready to sing the praises of running a business in this way. BTW, I thinkdistributed (“evenly spread throughout an area”) is a better description than the more commonly used virtual (“nearly real or simulated to be real”) for a company that has people working from all over the place instead of a centralized office. In Automattic’s case, we currently have over 50 employees spread across 12 US states and 10 countries. Here are my top 5 reasons why you should consider the distributed model for your company: via toni.org I think that this is indeed the future – the full text follows here As with all good network designs – most of the direct and indirect costs of the organization go away. The capital costs are shed and are taken up by the nodes. People work from their place. With their gear. Huge expenses off the table. Huge potential to have the best gear for the staff. Most of those interruptions go away – who can get any work done at the office these days? Most of those silly meetings go away. With NO Commute – so they get hours of time back a day. Let’s say 2 hours a day. 10 hours a week. 40 hours a month. (That’s a working week). 12 weeks a year! That is a lot of dentist visits, plumber visits, time with kids and spouse, time to nap, time to do whatever. And all this time was pulled out of the air as a result of not commuting. Then of course there are the direct costs of commuting – the car, the transport. It costs $9,000 a year to run a car fully costed. How about coffee and lunch? What do you spend today? $5.0 – $20 a day. That is $1,000 – $4,000 a year for coffee and lunch! How about clothes? I used to buy 2 suits a year as a man. Women can’t get away with that. How much does going to work cost you in clothes? $2,000 – $5,000. Daycare – well you might still want to send your kid off to daycare but now you might be able to do this locally and walk there. You will not have that pressure at the end of the day to juggle that project and getting to daycare on time. If your child is sick, you have options. And with all the money you have saved on the other things, you can afford a good one. They live where they want. Huge choice given back. Not only can you choose what part of town, but what town or even country. Then firm can also hire from a market of 6 billion versus from the local pool – the full talent pool of the planet is open to you. The costs of travel to meet and hang out now and then are tiny compared to what is spent on a conventional organization. The communication tools that connect you all now are all but free as well. The Skype offices have big screens that are ON all the time – so you can look up and call out to a colleague in another city as if she was in the next room – for free! So why not your office? Well if your organization is all about control, then this will never happen. if your organization is all about process and not results, this will never happen. If your organization hires people who don’t have the skills to deliver, this will never happen. If your organization is like this – why are you still there? Posted via web from Rob’s posterous

The Google Maps JavaScript API v3 introduced a new format for geocoding responses that offers a number of improvements over the format used in the v2 API: A flatter response format for address components that is easier to parse The ability to tag an address component with multiple typesBoth full names and abbreviations for countries and states Differentiation between rooftop and interpolated geocoder results Both the bounding box and recommended viewport for each resultWe're happy to now announce a new Geocoding Web Service that adopts these improvements.

The Geocoding Web Service is intended to enable precaching of geocoder results that you know your application will need in future. For example, if your application displays property listings, you can geocode the address of each property, cache the results on your server, and serve these locations to your API application. This ensures that your application does not need to geocode the address of a property every time it is viewed by a user. However we do ask that you regularly refresh your cache of geocoder results.

Note however that it is a requirement of the Maps API Terms of Service that you use the Geocoding Web Service in conjunction with a Google map. This means that when it comes time to use cached geocoder results in an application, the application must display the results or any data derived from them on a map generated using one of the Google Maps APIs or Google Earth API.

If your application needs to geocode arbitrary addresses that are entered by your users while they wait we recommend that you use the classes in the appropriate client API. This ensures that the requests your application generates reach Google directly from your users, which will improve the performance of your application and ensure it is resilient to unexpected spikes in use. For more details, I highly recommend this excellent blog post by our very own Mano Marks.

In addition to an improved response format you will notice some other changes in the new Geocoding Web Service. Requests no longer require a Maps API key, and Maps API Premier customers must sign their requests. In addition CSV output is not supported because we found that the minimal amount of data in a CSV response makes it is difficult to identify false positive results.

2,500 requests may be sent to the Geocoding Web Service per day from a single IP address. This is independent of any geocoding activity generated by applications using one of the client Maps APIs for geocoding. Maps API Premier quotas remain unchanged.

A forward geocoding request to the new Geocoding Web Service with XML output looks like:

http://maps.google.com/maps/api/geocode/xml?address=sydney&sensor=false

A reverse geocoding request with JSON output looks like:

http://maps.google.com/maps/api/geocode/json?latlng=-33.873038,151.20563&sensor=false

Check out the Geocoding Web Service documentation for more details on the options available for language and biasing of results.

In conjunction with the launch of the new Geocoding Web Service we are also announcing the deprecation of the current service, now retroactively named the "Geocoding V2 Web Service". Existing applications using the V2 Web Service need not worry though. Deprecation indicates that we no longer intend to pursue any further feature development, but we will continue to maintain and support the service in accordance with the deprecation policy set out in the Maps API Terms of Service.

We hope that you find the new Geocoding Web Service easier to use and useful. As always we encourage you to check out the Google Maps API Google Group if you have any questions or comments relating to the APIs. We look forward to adding more great features to the Geocoding Web Service in future.

Posted by Thor Mitchell, Maps API Product Manager

The Google Maps JavaScript API v3 introduced a new format for geocoding responses that offers a number of improvements over the format used in the v2 API: A flatter response format for address components that is easier to parse The ability to tag an address component with multiple typesBoth full names and abbreviations for countries and states Differentiation between rooftop and interpolated geocoder results Both the bounding box and recommended viewport for each resultWe're happy to now announce a new Geocoding Web Service that adopts these improvements.

The Geocoding Web Service is intended to enable precaching of geocoder results that you know your application will need in future. For example, if your application displays property listings, you can geocode the address of each property, cache the results on your server, and serve these locations to your API application. This ensures that your application does not need to geocode the address of a property every time it is viewed by a user. However we do ask that you regularly refresh your cache of geocoder results.

Note however that it is a requirement of the Maps API Terms of Service that you use the Geocoding Web Service in conjunction with a Google map. This means that when it comes time to use cached geocoder results in an application, the application must display the results or any data derived from them on a map generated using one of the Google Maps APIs or Google Earth API.

If your application needs to geocode arbitrary addresses that are entered by your users while they wait we recommend that you use the classes in the appropriate client API. This ensures that the requests your application generates reach Google directly from your users, which will improve the performance of your application and ensure it is resilient to unexpected spikes in use. For more details, I highly recommend this excellent blog post by our very own Mano Marks.

In addition to an improved response format you will notice some other changes in the new Geocoding Web Service. Requests no longer require a Maps API key, and Maps API Premier customers must sign their requests. In addition CSV output is not supported because we found that the minimal amount of data in a CSV response makes it is difficult to identify false positive results.

2,500 requests may be sent to the Geocoding Web Service per day from a single IP address. This is independent of any geocoding activity generated by applications using one of the client Maps APIs for geocoding. Maps API Premier quotas remain unchanged.

A forward geocoding request to the new Geocoding Web Service with XML output looks like:

http://maps.google.com/maps/api/geocode/xml?address=sydney&sensor=false

A reverse geocoding request with JSON output looks like:

http://maps.google.com/maps/api/geocode/json?latlng=-33.873038,151.20563&sensor=false

Check out the Geocoding Web Service documentation for more details on the options available for language and biasing of results.

In conjunction with the launch of the new Geocoding Web Service we are also announcing the deprecation of the current service, now retroactively named the "Geocoding V2 Web Service". Existing applications using the V2 Web Service need not worry though. Deprecation indicates that we no longer intend to pursue any further feature development, but we will continue to maintain and support the service in accordance with the deprecation policy set out in the Maps API Terms of Service.

We hope that you find the new Geocoding Web Service easier to use and useful. As always we encourage you to check out the Google Maps API Google Group if you have any questions or comments relating to the APIs. We look forward to adding more great features to the Geocoding Web Service in future.

Posted by Thor Mitchell, Maps API Product Manager

Each of those applications must be registered with a unique app identifier, each one takes up a separate slot when installed on your iPhone's home screen, each application occupies a separate App Store listing, complete with its own screen shots, marketing material, reviews, and so forth. Each one must be managed by you in iTunes, where you must decide which to sync, which to keep, and so forth.

Add to the mix, the possibility that we're likely to see iPad- and iPhone-specific application releases in the near future in addition to the Universal Application solution that Apple has been heavily promoting. That's because iPad applications offer developers the opportunity to re-imagine their interfaces, adding features without the constraints of the iPhone's small screen and modal interaction limitations. An iPad app that adds significant new functionality may branch off and become yet another related app in a single application family.

Together, this means that an application family might include four or more applications: free versions, paid version, device-specific versions, and various upgrade options, all of which offer a single branding and some core overlap of features, despite differences in price and platform.

In my recent write-up, I proposed that Apple might be able to consolidate many versions of an application into a single product using multiple iPhone application files, aka a "multi-ipa" solution. Each component of this family would install to the same application slot and would use the same application identifier, that code that every developer must register with Apple. An application's identifier uniquely identifies each iPhone OS product to the device it lives on and to the App Store ecosystem.

The way I picture this working is this. Each member of a multi-ipa family would have a built in priority, specified in the bundle's Info.plist. That's the file that tells iPhone OS how the application bundle fits into the operating system. It works the same way that Info.plist files work on Mac OS X. In this case, the ipa with the highest priority gets installed. It's iTunes that makes the final call.

So imagine if a person downloads a free, iPhone-only demo version of a game and then later upgrades to a full-featured paid version. The paid version's higher priority wins out against the free versions, so iTunes knows to install the paid ipa into the same slot that the free version currently occupies. Right now, that doesn't happen. You end up using two slots and two application identifiers. Should a person then buy an iPad upgrade to this app (assuming here that it's not a universal application), then iTunes will sync the iPad-specific ipa to their iPad device rather than the iPhone version, eliminating any need to use pixel doubling to play the game.

As I previously wrote, Apple could offer a "Complete my App" feature to allow customers to buy the iPad-specific enhancements only when and if they eventually buy an iPad device. This approach depends on iTunes storing more than one version of the application, i.e. multiple ipa archive files, so that it can sync the best match to each device.

In each of these cases, it's iTunes that decides which ipa to install. The multiple ipa delivery system allows separate versions of the same application to coexist in the iTunes Mobile Applications folder. The latest, best-featured and most device-specific version always wins.

For Apple, for developers, and for consumers, there's pressure to both consolidate these families of apps and, at the same time, there's reasons to keep them separate. Both Apple and consumers win when just one listing and one device slot are dedicated to what is, essentially, a single application with multiple expressions of itself. App Store instantly declutters to a great degree; a single listing now takes care of both free and paid versions.

Developers may resist this. In the case of lite/demo and paid apps, split-personality multiple-listing can be a blessing for developers. Negative reviews for free applications can be mitigated by providing a completely separate product, whose reviews are culled only from paid customers.

That's been a big part of many developers' decisions not to migrate to in-app purchases, where the same app can exist in both demo and paid mode. With in-app purchase, users try out the application and, if they like what they use, can unlock the full version from within the demo app itself. Unless Apple offers some kind of free-version review block, developers will rationally keep picking the latter choice and design separate products for free and full versions. Apple, of course, can change its policy on this practice any time it chooses.

Paid upgrades are, on the other hand, a consolidation win for developers. One thing we do know for sure, Apple is likely to introduce paid upgrades in the near future. Existing customers can upgrade for a small fee; new customers must buy in at the full price. Admittedly, consumers who bought earlier app versions, believing they had bought in "for life" to all future innovations are going to be displeased to realize that a buy once, upgrade forever business model is unsustainable. It's a tempest that App Store is simply going to have to weather. Just don't expect customers to be happy about it.

So what's your take on this? Do you think Apple should go full-out in consolidating apps together? Or should they continue to allow separate trial and paid versions? Do you think the notion of a separate iPhone and iPad purchase has a future? Or will Apple push ahead with a priority on Universal application delivery? What do you think is the direction that App Store will be taking on these issues? Let us know in the comments.

[1] Apple is, even now, in the process of house-cleaning those applications to trim down App Store bloatTUAWiPhone devsugar: The need for multiple ipa delivery originally appeared on The Unofficial Apple Weblog (TUAW) on Mon, 08 Mar 2010 20:00:00 EST. Please see our terms for use of feeds.Read | Permalink | Email this | Comments

AppStore - iPhone - Apple - Unofficial Apple Weblog - iTunes

http://distillstudio.com http://www.stackdb.com