Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.6.0-beta4
    • Fix Version/s: 1.6.0-RC1
    • Component/s: None
    • Labels:
      None
    • Environment:
      Linux/PostGIS/GS 1.6b4
    • Number of attachments :
      1

      Description

      thanks CodeHaus/Jira for losing my long and descriptive issue description the first time around. please forgive me if this is a bit more terse.

      wms/reflect has issues. to replicate the bug:

      import this shapefile layer: ftp://data.massgis.state.ma.us/pub/shape/cen2000/tracts/census2000tracts_poly.exe with srid = 26986 and name the layer census_tracts in namespace 'aw'

      try this: http://transit.frumin.net:8081/geoserver/wms/reflect?Format=application/openlayers&layers=aw:census_tracts&srs=EPSG:26986
      notice the bounds in the javascript: var bounds = new OpenLayers.Bounds(-180.0,-90.0,180.0,90.0);
      messed up, eh?

      try again, but with EPSG:4326 – same issue, still no STDERR from geoserver

      try again, but for KML: http://transit.frumin.net:8081/geoserver/wms/reflect?Format=kml&layers=aw:census_tracts&srs=EPSG:4326
      and get this over http:

      <?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE ServiceExceptionReport SYSTEM "http://schemas.opengis.net/wms/1.1.1/WMS_exception_1_1_1.dtd"> <ServiceExceptionReport version="1.1.1" > <ServiceException>
      java.io.IOException
      java.io.IOException
      java.io.IOException
      java.io.IOException
      java.io.IOException

      and the attached file on STDERR

      thanks,
      Mike

      1. gsbug.txt
        6 kB
        Michael Frumin

        Activity

        Hide
        Chris Holmes added a comment -

        Hey Mike, any chance you could grab a build of geoserver and try it out? Arne just put in a fix - 7722 that has a pretty decent chance of solving your problem, as it gets the bounds right.

        If the nightly works tonight (08) then you should be able to just test from there: http://traffic.openplans.org/geoserver/trunk/

        Or if you can check out and build.

        Or Arne or I can send you the jar you need.

        Show
        Chris Holmes added a comment - Hey Mike, any chance you could grab a build of geoserver and try it out? Arne just put in a fix - 7722 that has a pretty decent chance of solving your problem, as it gets the bounds right. If the nightly works tonight (08) then you should be able to just test from there: http://traffic.openplans.org/geoserver/trunk/ Or if you can check out and build. Or Arne or I can send you the jar you need.
        Hide
        Arne Kepp added a comment - - edited

        Here is a picture of the default output from the new WMS reflector (EPSG:26986): http://bildr.no/view/120268

        It was generated using http://localhost:8080/geoserver/wms/reflect?layers=topp:census2000tracts_poly&srs=EPSG:26986
        (you need to specify 26986 explicity, else it reverts to 4326)

        With regards to the exception, I think it may be your web browser timing out the request (it is pretty big), closing the TCP connection and Java getting upset that it has nowhere to write the result.

        Show
        Arne Kepp added a comment - - edited Here is a picture of the default output from the new WMS reflector (EPSG:26986): http://bildr.no/view/120268 It was generated using http://localhost:8080/geoserver/wms/reflect?layers=topp:census2000tracts_poly&srs=EPSG:26986 (you need to specify 26986 explicity, else it reverts to 4326) With regards to the exception, I think it may be your web browser timing out the request (it is pretty big), closing the TCP connection and Java getting upset that it has nowhere to write the result.
        Hide
        Michael Frumin added a comment -

        got the trunk from last night and it looks to be working perfectly, at least for the obvious/trivial test cases.

        Arne – no change that the exception was a result of closing the TCP connection since:

        • that IO exception came back right away on a wget fetch of the given URL
        • the geoserver log file included in my bug report specified what the actual error was, and it wasn't anything about the IO connection.

        looks like it's working, thanks again as usual for your total awesomeness.

        -mike

        Show
        Michael Frumin added a comment - got the trunk from last night and it looks to be working perfectly, at least for the obvious/trivial test cases. Arne – no change that the exception was a result of closing the TCP connection since: that IO exception came back right away on a wget fetch of the given URL the geoserver log file included in my bug report specified what the actual error was, and it wasn't anything about the IO connection. looks like it's working, thanks again as usual for your total awesomeness. -mike
        Hide
        Arne Kepp added a comment -

        Okay, great. I'll close the issue so we can keep track of what needs to happen for RC1, I trust you will let us know if the exception returns.

        Show
        Arne Kepp added a comment - Okay, great. I'll close the issue so we can keep track of what needs to happen for RC1, I trust you will let us know if the exception returns.

          People

          • Assignee:
            Arne Kepp
            Reporter:
            Michael Frumin
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: