More thoughts on the state of the GeoWeb
David Troy
Jesse
Sorry, would've replied earlier, but it seems that the delivery from
the google group to my mail account seems to be a little fidgety.
> In a session about Google's current Geo features, the following things
> stood out to me:
> - They have enabled geosearch as a Google Maps feature but *still*
> have no way to do geosearch as a web service
> - Google encourages everyone to publish their GeoRSS & KML, but all
> read access is through their visual interfaces
> - Google is introducing Google Sitemap to enable people to have their
> sites geomapped -- no docs available yet
Sitemaps for a while now, but I'm not sure what benefit you actually
get from including it. There has been a bit of talk about "mapspam"
that some clever SEOs have been able to exploit. Could be from the
KML sitemap?
http://www.localseoguide.com/google-mapspam-hits-too-close-to-home/
> - Google declines to discuss any aspect of their Geosearch ranking
> algorithm
constitutes relevancy in Geosearch? (Maybe this problem is why
mapspam is a reality?)
> Google is doing a lot to advance the geoweb, but not surprisingly they
> seem primarily motivated to get data into their indexers and not so
> worried about ways to share data with the rest of the world.
> Understandable, but it speaks at what the realistic limitations still
> really are.
>
> Some practical points about openlocation.org and what I want to launch
> Wednesday:
> - I have Wordpress and TikiWiki installed and can use both to host
> the conversation
> - Data interchange has been an area of focus; where should we start?
what's worked (ant not) for us: We have tons of GeoRSS and KML
scattered across the pages we could effectively put it for Outalot.
Sometimes the GeoRSS makes sense, sometimes it's just a hack, like RSS
for a single page of data. We haven't bothered with anything like the
meta tag recommendations at geourl.org, yet.
Maybe a microformat similar to hCard would serve us better. All that
we are really trying to do at this point is describe "this specific
piece of content is about this physical place" in the simplest way
possible.
> I will be spending tomorrow finalizing the openlocation.org blog &
> wiki, and I'd love your input about what you would find valuable.
together!
Jesse
Brady Forrest
- They have enabled geosearch as a Google Maps feature but *still*
have no way to do geosearch as a web service
David Troy
> David,
>
> Google announced this on Tuesday during the Jack/John talk:
>
>> - They have enabled geosearch as a Google Maps feature but
>> *still*
>> have no way to do geosearch as a web service
>
Yeah, Brady -- I was hopeful when I saw that but then I learned that
it is only using their Javascript API. It would be awesome to have
that functionality exposed via REST.
I've been looking at ways to scrape that interaction but it's a sorry
testament to the current state of affairs that I should be considering
that. :)
Looking forward to Wherecamp today!
Dave
Brady Forrest
David Troy
Yep, thanks to Pamela Fox at Google today I found the following:
Home Page for Ajax GeoSearch:
http://code.google.com/apis/ajaxsearch/
REST API documentation (Flash and other Non-JavaScript Environments):
http://code.google.com/apis/ajaxsearch/documentation/#fonje
Apparently right now this only returns 8 results at a time (though it
can be paged), and according to Pamela if we request that the result
set be increased to 32 or 50 or something, it might actually happen:
curl -e http://www.my-ajax-site.com \ 'http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=Paris%20Hilton'
Note that it requires no API key and returns fully RESTful results in
KML or JSON format. Cool stuff. Nice to see this actually exists!
Dave
Patrick Ewing
As someone who's pretty new to the Geo community, I'm already
getting a lot out of Dave's "Chicago Problem" as well as this
conversation... both the tools available right now and the gaps in the
open geoweb are all foreign to me. Initially I'll probably be asking
a lot of naive questions, but hopefully your answers (and an outsiders
perspective) will be useful to folks better-versed in this stuff.
Reading the openlocation.org manifesto, I was pleased to see that
"focus on user experience" was first on the list of goals. While
getting more data out of these walled gardens is the right thing to
do, clearly usability is the key to making a successful open
alternative. Reminds me of a blog post by Fred Wilson that I read
today: "It's not the data, it's the flow" http://avc.blogs.com/a_vc/2008/05/its-not-the-dat.html
He argues that data portability is not all-important; a service like
FriendFeed that mashes-up up all of the data out of your walled-
gardens of choice is useless unless it makes that data useful to you.
And that got me thinking about the Chicago Problem, which is more
about usage in a specific context than any one technology or standard.
Specifically, I'm wondering whether proximity is enough. I feel like
an "as the crow flies" distance query is very far removed from my
actual needs when I land. It seems to me that in context of the
problem, routes are just as important as proximity. Whether a place
is 4 miles away means very little to me... I'd be primarily concerned
with how I'm going to get there, and secondarily how long it might
take. Searching with proximity to available routes could open up
parts of the city to me or totally whittle down my choices.
For instance, If I'm a 15 year old student, I'm limited to locations
along public transportation routes. If I'm renting a car, I'm going to
be worried about things like traffic and available parking. I suspect
that straight-up proximity maps work best on a small scale (like I'm
downtown on foot and can intuitively know how far I feel like walking)
or in the great wide open (where there's only one way to get
anywhere). Basically, the opposite of an Airport, which is a pretty
exceptional place- remote, complex, and highly connected.
Please let me know if you think I'm focusing on an unimportant thing,
or if this already exists somewhere. If not I feel like this could be
one of the "100 little projects" Dave suggested: a simple way for
people to share, aggregate and comment on transportation routes.
look forward to talking with you folks!
Patrick
On May 18, 1:10 am, David Troy <davet...@roundhousetech.com> wrote:
> Brady,
>
> Yep, thanks to Pamela Fox at Google today I found the following:
>
> Home Page for Ajax GeoSearch:http://code.google.com/apis/ajaxsearch/
>
> REST API documentation (Flash and other Non-JavaScript Environments):http://code.google.com/apis/ajaxsearch/documentation/#fonje
>
> Apparently right now this only returns 8 results at a time (though it
> can be paged), and according to Pamela if we request that the result
> set be increased to 32 or 50 or something, it might actually happen:
David Troy
I like your thoughts regarding proximity vs. routing and think you
should take a look at some of the routing and transit data available.
Google apparently has a transit API that is gaining traction (http://code.google.com/transit/spec/transit_feed_specification.html
) and there are undoubtedly other sources out there as well.
Take a look and see what might be fun to experiment with re: routing
and see if there is an applicable demo you can put together. Everyone
seems to agree this is the best way to advance the agenda...
Dave
David Troy
I think Google's approach so far is just to encourage people to
publish as much stuff as possible in KML/GeoRSS, then index it,
perform some kind of page ranking, and then sell ads.
I am really interested in how it might be possible to implement
alternative approaches to their completely closed "page rank" on geo
data. I think social-graph aware indexing would be particularly
relevant and would outperform most other algorithms.
This would be a place to check out the Google Friend Connect API. If
there was a way to layer something onto that, it could be really
interesting. Google of course heard this entire discussion last week
and could announce just such a thing at any moment. But, in the
meantime, it would be interesting to see what hacks could be cooked up.
Does anyone have access to Friend Connect yet?
Dave
Brady Forrest
David Troy
to have an account for too, though I really need to study the API in
practice to better figure out the use cases.
I'm particularly interested in how they have integrated with the
Facebook graph.
Dave
Patrick Ewing
webcomic (a personal favorite)
http://xkcd.com/426/
and
http://wiki.xkcd.com/geohashing/Main_Page
A really fun idea, although somewhat of a namespace collision with
what we know as GeoHashing.
-Patrick
David Troy
confusion of this geohash with the other geohash algorithm!
Someone at Wherecamp pointed out that they didn't like the name
"GeoHash" for the Gustavo Niemeyer algorithm, as it implied a one-way
function. Technically it is a one-way function, as it can only be
worked back to a (very accurate) approximation of the original input
coordinates.
However, with XKCD on the trail, maybe it makes sense to consider an
alternative name for this down the road?
Anyway, has anybody considered doing a meetup at their local XKCD
coordinates?
Cheers,
Dave
Andrew Turner @ mapufacture
>
> However, with XKCD on the trail, maybe it makes sense to consider an
> alternative name for this down the road?
>
Seth of FireEagle suggested "GeoCrash"