Posts Tagged ‘bounding box’

Calculating bounding box in ArcMap

Monday, July 12th, 2010


[Editor’s note: I keep returning to this technique for calculating a feature’s extent (minimum bounding rectangle) in ArcGIS using the Field Calculator. Thanks William and Jeff!]

Republished in part from ESRI Forums.
Sample Field Calculator code for computing XMIN appears below.

Information about shape properties appears in the “Geometry Object
” diagram (pdf). All four parameters are Xmin, Xmax, Ymin, and Ymax.

dim Output as double
dim pGeom as IGeometry

set pGeom = [shape]
Output = pGeom.Envelope.XMin

Bounding Boxes for World Countries (Berkeley GADM)

Tuesday, June 23rd, 2009

[Editor’s note: Knowing the longitude-latitude (latLng) bounding box of a feature gives us a clue as to what map scale or zoom level is required to fit the feature into our display area and thus what base map scale set to draw from. While this image does not provide actual coordinates, it visually establishes what such bounding boxes look like (further refinements can be had with respect to crossing the 180° meridian, note New Zealand). ]

Republished from Berkeley GADM (Global Administrative Areas).

Here is a map of all countries and their bounding boxes (when using a lat/long “projection”), highlighting those countries that cross the international date line, and for which these bounding boxes make little sense (this map is provided for diversion only).


Yahoo Woe (Where On Earth, that is) IDs (GeoBloggers)

Tuesday, October 21st, 2008

[Editor’s note: Continuing to work thru a backlog of noteable but past news… I like how this API defines a placename’s location in a bounding box instead of a centroid. Wish it were both, but the bounding box seems more relevant (as a center point can be extracted, and you get the benefit of scale).]

Republished from Posted on by Reverend Dan Catt

Roll up, roll up, roll up, get your WoE IDs here …

… a jolly nice step in the right direction.

Yahoo have opened up their geo database (which is pretty good btw) which is far more awesome than I’m going to make it sound in this blog post. I already did a little bit back here. But a quick call out to these two functions that’ll try and find you WoE IDs based on string input…

… the first API call gives, 36240 as the value for Stoke on Trent in the UK, my old hometown. With that WoeID I can plug it back into these other API calls to get various useful information back …

We use WoE IDs over at Flickr, again you can read a little more about that near the end my terribly long previous blog posts about twitter, APIs and such like. A quick recap is that we have these WoE related APIs …

The ones that probably compliments the APIs over at are flickr.places.findByLatLon, which will turn a Lat/Long into what Flickr believes is there, more on this in a second.

And flickr.places.resolvePlaceId, if you plug the value of 36240 into the API explorer there you’ll get this xml back …

<rsp stat="ok">
	<location name="Stoke on Trent" woeid="36240" place_id="gEXCB1iaB571gw" place_url="/United+Kingdom/England/Stoke+on+Trent">
		<locality place_id="gEXCB1iaB571gw" woeid="36240">Stoke on Trent</locality>
		<county place_id="B_K1Z7iYA5qfCIiHaw" woeid="12602189">Staffordshire</county>
		<region place_id="pn4MsiGbBZlXeplyXg" woeid="24554868">England</region>
		<country place_id="DevLebebApj4RVbtaQ" woeid="23424975">United Kingdom</country>

Where you can see the same woeid, the URL to get to the Places page for Stoke on Trent, and the parent hierarchy flickr uses.

You can also plug the woeid into the to get photos back for just that area. A quick example of why that is useful is California, there’s no way you’d want to find photos for California using the bounding box, as it covers a couple of other states …

… but instead you can use the woeID for California (2347563) which deals with all the bends and kinks of CA. You can also throw that ID into the Places URL, like this …, although you’ll probably want to pass that through flickr.places.resolvePlaceId first if you want a pretty URL.

Differences between Yahoo geo API stuff and Flickr

Over at Flickr, we only use specific ‘levels’ of geo information, such as city, region, state, country, while the APIs over at Yahoo will spit out far more levels in-between the ones Flickr uses, as well as deeper down to neighborhood levels, which Flickr doesn’t do (yet).

Just because you get a WoeID back from Yahoo, doesn’t mean we’ll have photos for that specific area, we’ll probably bounce you up to the next largest places we deal with. So our parent hierarchy will have less steps in it that the ones you get back from Yahoo’s geo stuff. It also means our find by lat/long will only go down to town/city level and not precise neighborhood level.

We also don’t do photos or Places pages for Landmark WoeIDs, taking their example of Sydney Opera House which gives you an ID of 28717584 and throwing that at Places will give you no photos (maybe one day), although you can bounce up to Sydney.

Anyway, it goes beyond photos at Flickr, it’s just a really useful way that you, a developer can key off an ID for a place, that someone else, somewhere else can also key off.

If you use the ID 2347563 for California, and they use the ID 2347563 for California. And one, or both of you, publish your information with that ID, then you, they, or other people know that you’re both talking about the same place and match that data up.

Which is nice.

[Update 1: If you’re coming here from the CNET news article my talk isn’t actually about the location platform, its about Flickr photos and location :)]

[Update 2: For more official stuff about the Location Platform, you should probably see the Yahoo Local & Maps Blog post Abstracting Spatial Relationships with the Yahoo! Internet Location Platform where they use phrases such as “unambiguously”, “permanent” and “language-neutral”, and sum everything up far better than I]

[Update 3: and if you haven’t yet checked it out, I still think its worth reading my blog post “Twitter API updates, FireEagle and new Flickr API fun” as an example of what to do with woe IDs]

ALSO from Read Write Web.

Yahoo! today [in May] released a developer preview of its Yahoo! Internet Location Platform, a collection of in-depth geo-location based APIs. We expect to see location be more smartly used in many applications around the web thanks to this platform.

The gist of what’s being enabled is this: applications can provide the name of one location and then the Yahoo! APIs will report neighboring and “parent” locations. Flickr developer and map lover Dan Catt articulates the potential power of the API very well in a blog post today.

A lot of Ground Covered

Yahoo! explains the breadth and depth of location data it now offers thusly: “The [Platform] contains about six million places. Coverage varies from country-to-country but globally includes several hundred thousand unique administrative areas with half a million variant names; several thousand historical administrative areas; over two million unique settlements and suburbs, and two-and-a-half million unique postcode points covering about 150 countries, plus a significant number of points of interest, Colloquial Regions, Area Codes, Time Zones, and Islands.”

Geolocation is Hot Everywhere

Geolocation is hot, a number of new projects are underway to leverage increasingly sophisticated geographic knowledge to deliver value to end users. See our coverage of Brightkite and of Yahoo!’s own excellent FireEagle, for example.

Flickr developer Catt explains, for example, that Flickr could use the new APIs to offer images of nearby photos on several different levels, with accuracy as granular as Flickr is able to output.

There are a lot of interesting possibilities, not just for mapping but for services that are map aware. What would you like to see turned geo-smart? We’re excited to see what developers come up with. We probably won’t have to wait for long, either, since the Platform was released the day before O’Reilly’s Where 2.0 conference begins in Burlingame, California. Keep your eyes peeled for location savvy apps this week!