Inconsistent news content between request based on address and request based on lat lon

[YF]

Hi,

If I am getting news content using the address (e.g. Ottawa, Ontario,
CAN), I am getting the latest data. However, if I use lat and lon for
the same city, the data returned is more close to 10 days old.

Is it a known issue?

Thanks,

[John Cwikla]

This is a known issue - it's due to how we handle attaching default
lat/lng's
to both places and content. Since places like cities are actually
polygons,
having a default lat/lng to represent it is pretty arbitrary. So when
content
comes in, it too gets a lat/lng that represents where we think someone
would
want to put it on a map. Because we are actually mapping many
different
places to a single piece of content (imagine a sports article between
to
teams), returning a list of lat/lng's isn't that useful.

You can however get what you want - if you first send the lat/lng
into
our /location API call, we return to you a hierarchy of where that lat/
lng
lives. You can then take the level you find interesting (city, state,
locality)
and pass that into the content call, which basically emulates a true
polygonal intersection by matching via place type.

So do something like:

http://geoapi.fwix.com/location.xml?api_key=YOUR_API_KEY&lat=37.787647&lng=-122.399338

Then use the <city></city> element and pass that into the content
call.

John Cwikla
VPE
fwix

[YF]

John,

That approach is still very problematic. For example in Ottawa, there
are sub-urban areas such as Kanata and Orlean. Using your location
API, certain lat/lon will resolve to Kanata as the city. That used to
be true in the past until Kanata merged with Ottawa a long time ago.
Now, using Kanata as the city, you will only get limited # of news
bound to Kanata; even though for people living here, they want Ottawa
news.

I would suggest to flag a piece of news with multiple coordinates (to
address your scenario with sport news). Note that user already supply
the radius to limit the area. You can provide a default sorting based
on the city info within the returned data. You can also give the user
option to sort by distance or date.

Thanks,

On Sep 9, 1:20 pm, John Cwikla <cwi...@fwix.com> wrote:
> This is a known issue - it's due to how we handle attaching default
> lat/lng's
> to both places and content.  Since places like cities are actually
> polygons,
> having a default lat/lng to represent it is pretty arbitrary. So when
> content
> comes in, it too gets a lat/lng that represents where we think someone
> would
> want to put it on a map.  Because we are actually mapping many
> different
> places to a single piece of content (imagine a sports article between
> to
> teams), returning a list of lat/lng's isn't that useful.
>
> You can however get what you want -  if you first send the lat/lng
> into
> our /location API call, we return to you a hierarchy of where that lat/
> lng
> lives.  You can then take the level you find interesting (city, state,
> locality)
> and pass that into the content  call, which basically emulates a true
> polygonal intersection by matching via place type.
>
> So do something like:
>

> http://geoapi.fwix.com/location.xml?api_key=YOUR_API_KEY&lat=37.78764...

[John Cwikla]

The problem is mixing of a "near me" solution which is lat/lng and
radius
and a "contained within" solution, which is point in polygon.

If you want to use lat/lng and radius you have no guarantee that you
will
receive all the Ottawan news from inside Kanata unless your radius is
guaranteed
to be as large as the largest distance from Kanata to Ottawa's
borders.
Using a radius is literally a filter - too small and you could not
receive
some news. Too large and you start picking up neighboring city news,
which
may not be a problem for you, so that could work.

If you want a "contained within" solution where we've already done the
work
of determining what's in which area, then my original solution is what
you should
use - convert the lat/lng to it's containing polygon using the
location call.

Note that these two different ways of accessing data will give two
different
streams of data, like you've seen.

The real problem it seems is that our data doesn't reflect the current
hierarchy of Ottawan/Kanatan/Orlean borders. I'll have to bring this
up
with our places team to see what's going on there, and how our data
should
be updated. For now, I'd suggest on your side that after you do the
location
call you map these legacy cities into Ottawa - and when our data gets
updated,
you shouldn't have to change any codes, as our data will start
reporting it
as Ottawa.