Open311 api spatial query

[Cliff Ingham]

So, we're finally getting to the point where we can support Open311
queries that include a bounding box. It's still early, so nothing's
standardized, yet. However, it's at least possible now.

We have added a bounding box parameter to the Open311 GET Service Requests.
https://bloomington.in.gov/test/open311/v2/requests.xml?bbox=minLat,minLong,maxLat,maxLong

So, for example:
https://bloomington.in.gov/test/open311/v2/requests.json?bbox=39.16327243690854,-86.5504745371399,39.17658093347435,-86.52313746286012

Now, I'm pretty sure we're going to stick with the bounding box, instead
of a center point + radius query. Quan has been working on using this
type of query to dynamically display tickets on a google map.

So, the map only requests tickets that fit inside the viewable bounding
box. Each time the map is moved or scaled, it does a fresh request for
tickets in the bounding box.

For folks that are working on mobile clients that want to try out
displaying existing tickets on the map, this will provide support for that.

But like I said, this is still preliminary, but most likely this will be
the way things will work.


--
Cliff Ingham
http://www.ohloh.net/accounts/inghamn
-------------------------------------
"If debugging is the process of removing software bugs, then programming
must be the process of putting them in."
-- Edsger Dijkstra

[Peter Watkins]

Great, I was just about to ask for this info!

May I suggest documenting this as southLat,westLong,northLat,eastLong
instead of min/max?

The main win is clarity describing boxes that cross 180/-180 longitude,
where west lng is greater than east lng.

FWIW we're using elements named "bottom", "left", "top", and "right" in
our /boundaries.FMT, but that's a "North is up" perspective. Cardinal
directions would be better.

Suggestion: if a client passes in an impossible bounding box, the
server should deliver an error code.

E.G., if you sent us Bloomington's bounding box coordinates, we should
immediately see there's no overlap and return something like a 404
error. (Of course I also think the clients should fetch our
/boundaries.FMT and use it to prevent improper map panning, as our
Open311 web UI does, so this 404 would be a belt-and-suspenders
feature.)

-Peter

[Cliff Ingham]

Right now, the Open311 implementation is very naive. It's just a float
comparison:

case 'bbox':
$bbox = explode(',', $value);
if (count($bbox) == 4) {
$minLat = (float)$bbox[0];
$minLong = (float)$bbox[1];
$maxLat = (float)$bbox[2];
$maxLong = (float)$bbox[3];
$this->select->where('t.latitude is not null and t.longitude is
not null');
$this->select->where('t.latitude > ?', $minLat);
$this->select->where('t.longitude > ?', $minLong);
$this->select->where('t.latitude < ?', $maxLat);
$this->select->where('t.longitude < ?', $maxLong);
}
break;

However, I might end up having the Open311 api use our Solr search
engine to do the lookup, instead of hitting the database directly. We
are beginning to use the Solr search engine to do the spatial queries
for the HTML interface for uReport. At which point we just rely on Solr
developers to handle the bounding box correctly.

http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4

[Peter Watkins]

On 2013-07-31 15:21, Cliff Ingham wrote:
> Right now, the Open311 implementation is very naive. It's just a
> float
> comparison:

> However, I might end up having the Open311 api use our Solr search
> engine to do the lookup, instead of hitting the database directly.
> We
> are beginning to use the Solr search engine to do the spatial queries
> for the HTML interface for uReport. At which point we just rely on
> Solr
> developers to handle the bounding box correctly.
>
> http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4

Ah, and it seems they're aware that their code doesn't handle lng 180
correctly:
http://stackoverflow.com/questions/12653144/geospatial-search-within-a-bounding-box-using-solr
"If you want to handle a dateline cross then it's a little more tricky
as there are two pairs of range queries needed for the longitude."
I.E., you have to split your shapes up to make it work.

I would like to hear your thoughts on my suggestion that the backend
return an error for clearly invalid bounding box values. ISTM there's no
value in the backend playing dumb and saying there are no tickets if
it's clear that none of the specified box is in the jurisdiction
boundaries. Better to basically tell the client they're talking to the
wrong endpoint.

-Peter

> On 07/31/2013 02:29 PM, Peter Watkins wrote:

>> May I suggest documenting this as
>> southLat,westLong,northLat,eastLong
>> instead of min/max?
>>
>> The main win is clarity describing boxes that cross 180/-180
>> longitude,
>> where west lng is greater than east lng.

[Cliff Ingham]

I had been thinking that just returning zero tickets would be best. But
can easily be conviced otherwise.

Right now, we're building mobile and web clients that are requesting
tickets interactively as the user pans and zooms the map. The user
interface really should be as snappy as possible. If the user pans the
map outside of the city limits, I had thought it made sense to just
return zero tickets. That way, on the client side, there's not a
seperate code path to deal with.

[Peter Watkins]

Zero-vs-error: Ideally the backend would detect when the customer was
looking at a section of map that was inside the big jurisdiction
bounding box but not valid. Imagine someone looking at a map of Texas
who pans up to Oklahoma City and zooms in a bit. That map would be in
the overall Texas bounding box, but outside the Texas polygon(s). Your
request for tickets in that map box would give Texas' endpoint a chance
to warn the client that every point it's displaying is invalid even
though some or all of the map is inside the overall Texas bounding box.
That's where I'd suggest sending an error, to differentiate between
having no tickets and the customer looking at space completely outside
jurisdiction boundaries.

(This could be really slick at the level of individual service_code
values; e.g., Texas might see that you're looking at details of a lake
or private development and warn you that the space is not valid for the
Pothole request type you selected. This would require errors with more
structure than GeoReport generally provides, something I'd jot down as a
v.Future feature.)

Regarding snappiness, I definitely think you should support
/boundaries.FMT. If the mobile app knows what jurisdiction it's working
with and that jurisdiction gives you bounding box info, there's no sense
allowing the user to pan outside that box. Panning outside not only
means asking the server for info about tickets that it would never have,
but it also means asking the mapping servers for tile images (or, in
iOS, vector map data???) related to irrelevant locations. In our website
code, we have a GMap v3 "bounds_changed" event handler that looks at the
client-cached jurisdiction coords from /boundaries.FMT and calls
setCenter() on the map if none of the visible map is within our bounding
box. It probably should be more elegant and just re-pan the map enough
to make the edge of our box visible (re-centering in the jurisdiction
center only really works well if you're zoomed out enough to see the
city boundaries on the map), but at least we prevent the browser from
requesting irrelevant tiles over the network, with zero calls back to
our jurisdiction's servers.

[Rajul Bhatnagar]

Does the query with bounded box still support filtering using start and end date because I keep getting empty responses when I use any start and end date.

--
You received this message because you are subscribed to the Google Groups "open311-mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open311-mobil...@googlegroups.com.
To post to this group, send email to open311...@googlegroups.com.
Visit this group at http://groups.google.com/group/open311-mobile.
For more options, visit https://groups.google.com/groups/opt_out.

--
Rajul Bhatnagar
Btech Computer Science & Engineering
VIT University Vellore

[Cliff Ingham]

There does seem to be wierdness with the date parameters. I'll have to
tackle that when I get a chance.