Debugging functionality (address points, search results, add address, etc...)
r.richards
1) No address points are showing up? Is this a geoserver config issue
or related to relative/absolute URL'S that we experienced with the wms/
gwc requests? We are getting HTTP 500 on address point requests:
[10/Mar/2011 09:09:32] "GET /search/addressbbox?TYPENAME=SF_MAD
%3Aaddresses&MAXFEATURES=10000&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&SRS=EPSG
%3A900913&BBOX=-13633976.616057,4545124.4922717,-13633701.711479,4545184.2684165&zoomLevel=7HTTP/
1.1" 500 108894
2) The search function is working but there appears to be a problem
with the information below the address candidate. The icon continues
to spin throughout the session. What is expected in the detail panel
below the search candidate?
3) Add Address Point function is available in the right click context.
Clicking a location the form opens up and populates some fields and
then a "Data Retrieval Error" unable to get address location
information.
Thanks for any information on what to look into...
Thanks
Ronnie
Paul McCullough
> [10/Mar/2011 09:09:32] "GET /search/addressbbox?TYPENAME=SF_MAD
> %3Aaddresses&MAXFEATURES=10000&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&SRS=EPSG
> %3A900913&BBOX=-13633976.616057,4545124.4922717,-13633701.711479,4545184.2684165&zoomLevel=7HTTP/
> 1.1" 500 108894
The way to debug this is to grab this url and paste it into a separate
browser tab, and you should be able to see the django debug info -
DEBUG in settings.py (and/or settings_deploy.py) must be set to true.
This is not a geoserver WFS call - its actually calling to django but
openlayers sees it as WFS (I think). This is one of the few pieces I
did not work on so I could be wrong on some of this.
I'll predict its something like a gdal install issue.
> 2) The search function is working but there appears to be a problem
> with the information below the address candidate. The icon continues
> to spin throughout the session. What is expected in the detail panel
> below the search candidate?
Do you mean in the search drop down or in the results panel on the left?
Again, the best way to debug is to capture the URL using firebug and
look at it in a spearate tab.
> 3) Add Address Point function is available in the right click context.
> Clicking a location the form opens up and populates some fields and
> then a "Data Retrieval Error" unable to get address location
> information.
Same as above.
There should be an eas.log (or mad.log) file on the web server that
may be helpful in many of these cases.
It's location is specified in settings.py as I recall.
P
Robert Gaston
> openlayers sees it as WFS (I think). This is one of the few pieces I
> did not work on so I could be wrong on some of this.
That's exactly right. To retrieve address points we are using a bit of custom code that uses GeoDjango... From the client side code's perspective, the service we set up behaves as if it were a proper WFS service (that is, it takes in the same parameters) though I believe the return JSON does not adhere to an OGC standard and we likely wrote a custom OpenLayers format for reading it...
> There should be an eas.log (or mad.log) file on the web server that
> may be helpful in many of these cases.
> It's location is specified in settings.py as I recall.
Without actually cracking open the code (sorry, no time) I believe you are right about the log file's location being specified in settings.py... As I recall it is in the Django settings...
Hope this helps a bit... Apologies for being so brief...
- Rob Gaston
r.richards
2) Yes it is the lower results panel which is not populating yet, or
the address details (when clicking on the address marker on the map)
3) Ok will keep plugging away the mad.log did not contain anything
meaningful (to me). Some recent entries.
2011-03-10 11:26:20,283 - MAD - INFO - AddressInfo() begin
2011-03-10 11:29:08,796 - MAD - INFO - AddressInfo() begin
2011-03-10 11:32:46,950 - MAD - INFO - AddressInfo() begin
2011-03-10 11:36:45,776 - MAD - INFO - AddressInfo() begin
2011-03-10 11:41:03,101 - MAD - INFO - buildApnPickList
2011-03-10 11:41:03,194 - MAD - INFO - geointersectedParcels count: 1
2011-03-10 11:41:03,194 - MAD - INFO - include parcels count: 0
2011-03-10 11:41:03,210 - MAD - INFO - parcel set count: 1
2011-03-10 11:41:03,210 - MAD - INFO - getParcelGeometry
On Mar 10, 9:30 am, Paul McCullough <p.e.mccullo...@gmail.com> wrote:
> > The EAS application is up and running and user can login.
>
> This is great - glad you are making progress.
>
> > [10/Mar/2011 09:09:32] "GET /search/addressbbox?TYPENAME=SF_MAD
> > %3A900913&BBOX=-13633976.616057,4545124.4922717,-13633701.711479,4545184.2684165&zoomLevel=7HTTP/
r.richards
the GDAL installation was incomplete. This was quite a mess on
Windows. GDAL Windows executables did not include proj.dll so had to
go grab the latest windows version of that. http://download.osgeo.org/proj/
2) Is now working with the GDAL fix
3) Add Address Point is still problematic. The server window shows
this error... " failed to load NAD27-83 correction file". Any chance
we are missing custom tranform files?
[10/Mar/2011 12:28:56] "GET /address/proposeAt/
POINT(-13631013.606314%204545584.7865017) HTTP/1.1" 301 0
ERROR 1: failed to load NAD27-83 correction file
No handlers could be found for logger "root"
[10/Mar/2011 12:28:56] "GET /address/proposeAt/POINT
%28-13631013.606314%204545584.7865017%29/ HTTP/1.1" 500 69304
>
> - Show quoted text -
r.richards
cannot create an address here because there are no parcels at this
location.
On Mar 10, 12:34 pm, "r.richards" <rricha...@gmail.com> wrote:
> 1) Success!! Address Points are showing on the map. You were correct
> the GDAL installation was incomplete. This was quite a mess on
> Windows. GDAL Windows executables did not include proj.dll so had to
McCullough, Paul
> failed to load NAD27-83 correction file
This looks to me like a problem with the proj4 install.
We do have custom projection definitions in these locations
http://code.google.com/p/eas/source/browse/#svn%2Ftrunk%2FMedia%2Fjs%2Fproj4js
http://code.google.com/p/eas/source/browse/#svn%2Ftrunk%2Fgeoserver%2Fconfiguration%2Fexamples%2Fuser_projections
and some rows that are already in the DB
select * from spatial_ref_sys where id = 900913;
McCullough, Paul
Right....
So we made a business decision requiring an address point to coincide with a parcel.
The reason being that we want to be able to go from an address to the owner(s)....
Which requires the parcel.
This could be changed with some modifications, and I expect we'll go there eventually because
There are use cases like "service addresses" that won't have a parcel.
Our timeline for that is probably 1 year(ish) (because of the shoestring budget).
Paul
-----Original Message-----
From: eas-d...@googlegroups.com [mailto:eas-d...@googlegroups.com] On Behalf Of r.richards
Sent: Thursday, March 10, 2011 12:37 PM
To: Enterprise Addressing System
Subject: Re: Debugging functionality (address points, search results, add address, etc...)
r.richards
cannot find the parcels layer? I assume parcels are the next layers to
debug... Does this have anything to do with the missing coordinate
system reference?
On Mar 10, 12:46 pm, "McCullough, Paul" <paul.mccullo...@sfgov.org>
wrote:
McCullough, Paul
I assume you can see the parcels on the map.
And I'll also assume you are clicking on a parcel.
Without looking at the code I'd say its related to a faulty proj4 install.
This would be because all the EAS data including the parcels are in epsg:2227.
All or nearly all of the geosever data are in epsg:900913.
We are probably using a geodjango function which I believe uses the python bindings to gdal and proj4.
A side discussion is why this mix of projections....involving:
- performance
- precision degradation from repeated reprojections (which we may still have a an issue with but it should be so trivial as to be irrelevant)
Hope this help!